Summary

  • APNIC identifies Haruzakura Cloud with AS153458 in Wuhan and records an IPv6 /44 allocation plus a separate /48 assignment. On 15 July 2026, public collectors saw only 2406:840:feac::/48 originated by AS153458, RPKI-valid and reached through one observed immediate adjacent network, AS139317.
  • HiChina's own registrar RDAP response places the privacy-redacted domain registrant in Hubei, while APNIC gives the network organisation a Wuhan contact address. Both are administrative geography; neither locates a router, rack, server or customer workload.
  • No reproducible public page established a multi-country service footprint, and no public record disclosed Haruzakura's facilities, rack count, power, server inventory, sold capacity, backup design or failover capacity. The defensible region is therefore Asia-Pacific, while exact operating sites remain unknown.

The discrepancy is the story

The public network attached to Haruzakura Cloud is small enough to describe precisely. APNIC has registered an autonomous system, an IPv6 /44 allocation and a separate IPv6 /48 assignment in the company's name. The global route table did not mirror that full registration on 15 July 2026. RIPEstat's announced-prefix response returned one current origin: 2406:840:feac::/48. Hurricane Electric's AS page independently showed zero originated IPv4 prefixes, one originated IPv6 prefix and one observed IPv6 peer.

That difference is not a defect by itself. An address allocation can be reserved, subdivided, delegated, held for later use or announced only intermittently. Nor does one route mean one server, one rack or one customer. It does, however, establish the outer boundary of what public routing observers could attribute to AS153458 at the research date. Any claim about a larger service estate needs a second chain of evidence linking products to host ASNs, facilities, suppliers and operating contracts. That chain is not publicly available.

The contrast becomes sharper in Haruzakura's PeeringDB profile. The profile reports 24 IPv4 prefixes, 42 IPv6 prefixes and a 1-5 Gbps traffic band. Yet the current public origin count was zero IPv4 and one IPv6. PeeringDB also returned no public exchange connection and no facility row. The result is an unusually asymmetric evidence set: the registry identity and one active route are strong; the claimed scale, physical location and usable customer capacity are weakly documented.

This article therefore starts with what can be reproduced and stops where the public record stops. It does not convert address space into compute, an ASN country into a data-centre coordinate, an AS path into a fibre diagram, or an industry-directory field into measured capacity. Haruzakura may operate more than the public route view reveals. It may also rely on other networks for services sold under its name. The decisive question is not which possibility sounds plausible, but which layer a customer can verify and which party has authority when that layer fails.

Identity records converge on Hubei, but only administratively

The identity chain begins with two domain-registration views that must not be conflated. The .com registry's Verisign RDAP response records haruzakura.com as created on 15 October 2023, registered through Alibaba Cloud Computing Ltd. doing business as HiChina, delegated to dns17.hichina.com and dns18.hichina.com, and unsigned with DNSSEC at the delegation. Verisign does not expose a registrant province. It supplies a related link to the registrar's own record.

The HiChina registrar RDAP response, queried on 15 July 2026, is the correct source for the province field. Its privacy-redacted registrant entity contains an address whose region is 湖北省, or Hubei Province, and country is CN. The administrative and technical entities carry the same region while personal and organisation names remain redacted. That record supports a narrow claim about domain-registration geography. It does not identify the legal company behind the domain, prove ownership of any network asset or locate the web server.

APNIC supplies the stronger bridge to the network identity. Its AS153458 record uses the name HARUZAKURA-AS-AP, describes Haruzakura Cloud, and gives an address at 628 Wuluo Road in Wuchang District, Wuhan, Hubei. The linked organisation entity names Haruzakura Cloud, places the organisation in China and classifies it as OTHER. The linked contact entity names Zhou Xuhao in the administrative and technical roles. These records connect a named operator, a person, an ASN and number resources in the APNIC system.

They remain registry entities, not a national corporate extract or a property title. OTHER is not evidence that Haruzakura owns a facility. The Wuhan address may be an office, correspondence point, residence, service address or something else; public facility evidence does not resolve it. The Hubei region in HiChina and the Wuhan address in APNIC corroborate an administrative base, but two administrative records do not become a data-centre record merely because they agree geographically.

That distinction also sets the article's regional classification. China is within the Asia-Pacific branch used by the site's existing category taxonomy, and multiple network records place Haruzakura in China. No reproducible first-party capture was available to substantiate a broader operating footprint. The company is therefore classified here as an Asia-Pacific cloud-service company, with customer service locations and physical operating sites recorded as unknown rather than global by assumption.

An unavailable website cannot carry an infrastructure map

The website address published in APNIC, PeeringDB and several route directories was not a dependable evidence surface on 15 July. Public DNS returned an address, but connections to the HTTP and HTTPS services were refused from the observation point. A single observation cannot establish a general outage: filtering, maintenance, source-address policy or a short-lived server condition could cause the same result. It does establish that the page body could not be independently recovered from that endpoint at that time.

Archival availability matters because a product-location claim should survive beyond a transient search index. An Archive.today lookup for the exact homepage URL returned no saved snapshot on the research date, and a June 2026 Common Crawl index query likewise returned no capture. Search-result fragments are not a substitute for a page that a reader can open and inspect. Accordingly, this article does not use unpreserved location labels, prices, package specifications, support promises or supplier names as facts.

This is a conservative evidentiary choice, not a conclusion that the company has no products or customers. A website can be temporarily inaccessible while services continue. A small provider can also use private portals, social channels or direct sales. The absence of a recoverable catalogue simply means that product scope, delivery location and terms cannot be established from the public materials available here. They remain questions for the contracting document and the delivered instance.

One unofficial signal does show that the Haruzakura name has circulated in a customer-facing context. A public NodeSeek channel repost from June 2024 labelled a giveaway under the Haruzakura Cloud name and referred to small server configurations. That may indicate promotion to hosting users. It cannot prove fulfilment, current operation, legal identity, location, inventory, ownership or service quality. It is best treated as a lead for further verification, not as the foundation of an operating-footprint claim.

AS153458 proves a real route identity, not a full hosting estate

APNIC registered AS153458 on 14 November 2024 under the name HARUZAKURA-AS-AP. The record names Haruzakura Cloud, places the organisation in China and links it to the same Wuhan contact context. APNIC separately records 2406:840:e2c0::/44 as an active non-portable allocation described as Haruzakura Cloud and records 2406:840:feac::/48 as an active non-portable assignment with the same description. The /44 contains sixteen /48-sized blocks, while the separate feac block is another /48. That arithmetic describes address space, not machines or customers.

Route collectors show that the address holdings and the active announcement are not identical. RIPEstat's routing-status response reported zero IPv4 announced prefixes, one IPv6 announced /48, one observed neighbour and a latest observation at 08:00 UTC on 15 July 2026. Its first-seen field points to 2406:840:e2c6::/48 in November 2024. The more detailed routing-history response shows that AS153458 has originated several /48 choices over time, including e2c6, e2cb, e2cf and feac. Only feac was current in the July 15 announced-prefix snapshot.

That history is evidence of an operating routing identity rather than a dormant registration. The current route also has sound origin authorisation. RIPEstat's RPKI validation returned valid for a route-origin authorisation that permits AS153458 to originate 2406:840:feac::/48 at a maximum length of /48. RPKI-valid status reduces one class of origin error. It does not provide a second path, protect the server, prove the route's physical location or guarantee that a wholesale contract will remain in force.

The route's immediate public dependency is unusually clear. RIPEstat's BGP-state paths consistently place AS139317 immediately before AS153458 in the collected paths. BGP.tools and Hurricane Electric identify AS139317 as Ningbo Dahuamao Information Technology Co., Ltd. Public collectors may miss private links or a standby session that is not announcing the prefix. Within the observable global table, however, the Haruzakura origin has one adjacent AS. That is logical single-upstream evidence at the BGP layer.

The sponsor and upstream boundary is part of the service risk

APNIC's registry data adds an administrative relationship to the observed adjacency. The AS153458 APNIC Whois record identifies Ningbo Dahuamao's ORG-NDIT1-AP as sponsoring-org and places MAINT-NBDHM-CN in mnt-lower and mnt-routes. The AS139317 Whois record classifies Ningbo Dahuamao's organisation as a local internet registry. This is a documented administrative relationship alongside the observed route adjacency, not proof of ownership, corporate control or the private contract.

The practical issue is authority during an incident. Haruzakura may operate its router and originate its prefix while depending on Ningbo Dahuamao for sponsorship, route-object maintenance and upstream propagation. If a filter changes, a payment dispute occurs, a route object needs correction or the sponsor's upstream connectivity fails, restoration may require action outside Haruzakura's direct staff. Customers need to know who can make those changes at 03:00, which party owns the relevant portal credentials and how escalation crosses company boundaries.

Logical path diversity also must not be confused with physical diversity. A BGP path ending 139317 153458 says which autonomous systems advertised the route. It does not reveal whether two sessions use different routers, cross-connects, conduits, metro paths or power feeds. Four prepended appearances of AS139317 in some collector paths are traffic-engineering syntax, not four separate upstreams. Likewise, the many distant AS numbers seen earlier in the path are networks carrying the route after AS139317; they are not Haruzakura's direct providers.

The public record therefore supports a narrow statement: AS153458 has one currently visible IPv6 origin and one observed adjacent AS, and that adjacent organisation is also recorded in APNIC's sponsorship and maintenance fields. It does not support the statement that Haruzakura has only one physical cable, nor does it support a claim of physical redundancy. Both remain unknown. A buyer should request router-level diagrams, circuit providers, demarcation points and failover tests before relying on the ASN as a resilient production path.

PeeringDB's 42-prefix claim collides with the routing table

Haruzakura's PeeringDB profile is the most striking piece of self-reported network data. Updated on 10 March 2026, it identifies AS153458, selects an Educational/Research network type, reports a traffic level of 1-5 Gbps, and lists 24 IPv4 prefixes and 42 IPv6 prefixes. At the same time, the profile provides no public exchange connection and no facility row. Its geographic scope is not disclosed.

Those figures do not align with the public route table on 15 July. The observed origin count was zero IPv4 and one IPv6 /48, not 24 and 42. The mismatch could have several benign explanations: the PeeringDB fields may describe planned capacity, downstream or internal networks, prefixes not currently originated by AS153458, a stale configuration, or a simple data-entry error. Public evidence does not decide among them. What it does decide is that the PeeringDB prefix counts cannot be presented as current globally visible origin counts.

The traffic band requires the same caution. 1-5 Gbps is a range chosen in an industry directory, not a metered chart, committed transit rate or usable customer capacity figure. It could describe aggregate traffic at a point in time, a target, a port class or an operator estimate. Without a timestamped utilisation series, port inventory and failure-state test, it cannot show concurrent customer headroom, protection capacity or whether the route remains usable when a link is withdrawn.

The absence of PeeringDB facility and exchange rows is meaningful only as absence of public disclosure. It does not prove that Haruzakura has no racks, no colocation and no peering. Small networks often use private transit without listing a facility. Conversely, a facility row would not prove that customer compute sits there. The correct evidence grade is therefore stronger for network identity than for topology: the ASN, prefix and upstream are visible; the ports, exchanges, racks and buildings are not.

The public website sits outside AS153458

The domain provides a useful example of why a company website is not a map of its operating estate. On 15 July 2026, the Google Public DNS response returned 36.50.226.119 for www.haruzakura.com. APNIC's record for that address places it inside 36.50.226.0/23, an allocation registered to Hunan Yumiyun Data Technology Co., Ltd. RIPEstat's prefix overview placed the covering 36.50.226.0/24 behind AS4837, China Unicom's China169 backbone. It was not an address originated by AS153458.

This is neither suspicious nor unusual. Organisations routinely place public websites, email, billing and support systems on third-party infrastructure. The observation establishes only a control-plane separation: the public web address and the Haruzakura-originated IPv6 route were in different registered address and origin contexts. It does not show who owned the server, which reseller supplied it, where the machine stood or whether customer workloads used the same host.

The separation creates several possible outage patterns. AS153458 could disappear from public BGP while the website remained reachable through AS4837. The web endpoint could fail while the /48 continued to route. Domain or authoritative-DNS trouble could prevent customers from finding a portal even if underlying machines were healthy. Conversely, a functioning homepage would not prove that a hosted workload, storage system or customer route was available. Status monitoring must therefore observe each dependency directly rather than treating the corporate domain as a universal heartbeat.

The July connection refusals are a time-bounded signal, not an outage verdict. They justify marking public web availability as unconfirmed from that vantage and make an independently hosted status and published contact points more important. They do not justify saying that Haruzakura had ceased operating. A status conclusion would require multiple networks, repeated observations, customer endpoints and direct operator confirmation.

Domain continuity is likewise separate from service continuity. Verisign's record showed an October 2026 expiration date and unsigned DNS delegation at the research snapshot. Neither fact predicts an imminent failure. They are still governance dependencies worth separating from a hosted workload: a customer should control its own domain, keep recovery contacts outside the provider's portal and ensure that a provider-account dispute cannot also remove DNS, monitoring and backup credentials.

Registered geography is not physical location

The strongest geographic facts are administrative. HiChina places the domain registrant in Hubei. APNIC places Haruzakura Cloud and its named contact at a Wuhan address and assigns country code CN to the ASN and IPv6 resources. BGP.tools also labels AS153458's operating country as China, while Cloudflare Radar's routing page places the network under China in its hierarchy. These records support Asia-Pacific classification and a China-based registry context.

They do not place a router or server. RIR country fields are administrative attributes, and contact addresses are where registry correspondence points, not where packets necessarily terminate. A domain registrant's province says nothing about the location of the web server. The Hunan-registered IPv4 allocation used by the website does not prove that its machine was in Hunan. Even an IP-geolocation product that returns a city would be an estimate, not a building record.

Physical evidence would look different. It would name a data-centre operator and site, or provide a service order, colocation contract, cross-connect record, equipment inventory, utility connection, commissioning document or a public facility entry attributable to the network. Haruzakura's PeeringDB facility API returned no row, and its exchange-connection API likewise returned no public connection. Those empty results mean no facility or exchange was disclosed in that profile. They do not mean no facility or private transit exists.

The map that public evidence permits is therefore deliberately sparse. It has an administrative marker in Wuhan, a domain-registration region in Hubei, a China country attribute for the number resources, a logical origin labelled AS153458, and a separate logical website route through AS4837. It has no verified data-centre coordinate, rack location, carrier entrance, power feed, cross-connect, fibre route or inter-site link. Precision must not be manufactured by placing the Wuhan contact pin on a facility map.

This distinction is material for customers. A contract can be governed by one jurisdiction, a support team can work in another, a registered IP block can carry a country code, and data can still reside somewhere else. Without a product-specific schedule for primary data, replicas, backups, logs and support access, the physical and legal geography of a workload is unknown. Asia-Pacific is the supported editorial region for the company; it is not a claim that every asset sits within one particular city or country.

Address space is not installed or usable capacity

APNIC's record for 2406:840:e2c0::/44 establishes one active non-portable allocation described as Haruzakura Cloud. A /44 can be divided into sixteen /48-sized blocks. APNIC separately records 2406:840:feac::/48 as an active non-portable assignment with the same description. That is a clear statement about registered number resources.

It is not a count of hosts or subscribers. A single IPv6 /48 conventionally contains 65,536 /64 subnets, but IPv6 addressing is intentionally abundant. The number does not imply 65,536 servers, racks, customers or saleable units. An address can be registered without being routed, routed without answering traffic, assigned internally without hosting a public service, or originated by a network that relies entirely on leased infrastructure.

The current route view narrows the lit public surface. RIPEstat returned the separate feac /48, not the whole /44, as the one announced prefix on 15 July. Historical data showed several /48s from the allocation at different times, but a historical announcement is not standby capacity. It does not reveal whether prefixes moved between routers, represented tests, supported customers, or were withdrawn during normal renumbering. It cannot be counted as simultaneous failover inventory without overlap and purpose evidence.

PeeringDB's 24 IPv4 and 42 IPv6 fields are also address-inventory claims, not proof of globally originated routes. The zero-versus-one collector result makes that limitation visible. A useful reconciliation would list every prefix, whether Haruzakura originates it, whether it is delegated to a downstream, whether it is reserved, and when it was last seen. Until such a schedule exists, the PeeringDB numbers should not enter a capacity calculation.

No public figure disclosed the count of servers, hypervisors, physical cores, memory, disks, storage pools, racks, cabinets, power feeds, transit commits, cross-connects or spare parts attributable to Haruzakura. No figure separated design capacity from installed, energised, commissioned, operational, sold, reserved, immediately available or failure-state usable capacity. Every one of those values is unknown. Unknown does not mean zero; it means that neither a buyer nor an analyst can compute headroom from the published evidence.

The operational question is not how many addresses fit inside the allocation. It is what remains usable after a defined failure. If one router disappears, can the /48 be announced through another path? If a host fails, is there powered compute and storage elsewhere? If an account or contract is suspended, can the customer recover data without the affected intermediary? Those tests require physical inventory, contractual authority and measured recovery, none of which follows from prefix length.

One current route is evidence of operation, within limits

AS153458 is not merely a reserved number in a registry. RIPEstat's routing-history response records origin windows beginning in November 2024 and continuing through the research date, while the current-prefix history shows the feac block repeatedly originated by AS153458. The visibility response shows the route appearing across public collectors. Those are meaningful operating signals.

They support a narrow conclusion: network operators configured AS153458 to originate the prefix, at least one adjacent network propagated it, and collectors in multiple places learned it. This is stronger than a website claim or a registry status alone. It is still not proof that a particular customer service answered, that packets reached a healthy application, or that the route remained within a latency or loss target. BGP can converge on a prefix whose hosts are unavailable.

The historical changes also need restrained interpretation. The ASN has been associated with e2c6, e2cb, e2cf and feac /48s in collector data. That can reflect testing, staged address use, renumbering, route-policy changes or different workloads. It does not automatically demonstrate four sites or a failover system. Establishing failover would require a timeline showing an intended primary route, a fault, an alternate route becoming active, and customer traffic recovering within a measured period.

The distinction matters when assessing status. The route was operationally visible on 15 July, so describing the ASN as wholly dormant would be wrong. Physical compute status is still unknown because no public server endpoint was tied to the /48, no facility was named, and no service-level telemetry was available. The network layer is active; the broader service layer cannot be inferred from it.

Cloudflare Radar and BGP.tools provide useful independent cross-checks, but neither changes that boundary. Dynamic traffic panels may indicate observations associated with an ASN, and route aggregators can display peers and prefixes. They do not disclose contracts, physical circuits, customer inventory or spare capacity. The authoritative APNIC records and timestamped RIPEstat responses remain the basis for the exact claims.

RPKI validates the origin, not the service

The current /48 had a valid route-origin authorisation in RIPEstat's RPKI response. The authorisation permits AS153458 to originate 2406:840:feac::/48 with a maximum length of /48. For networks performing route-origin validation, that makes the observed announcement valid rather than unknown or invalid.

This is a positive control. It reduces the risk that an accidental or unauthorised origin announcement will be accepted by networks that enforce validation policy. It also shows that someone with authority over the resource established a matching cryptographic entity. Buyers and peers should prefer this state to an invalid route.

RPKI does not authenticate the entire AS path. It does not prove that AS139317 is the intended transit, prevent a leak after a valid origin, or encrypt traffic. It does not keep a router powered, maintain a cross-connect, repair fibre, preserve a commercial contract or restore a virtual machine. If the only observed adjacent network stops propagating the route, the ROA remains valid while the prefix can still become unreachable.

Nor is a valid ROA permanent. A prefix change, origin change, expired certificate or mismatched maximum length can alter validation. A resilient operating procedure therefore includes monitoring validation state, testing proposed route changes before deployment and ensuring that more than one authorised person can update the resource. The operational guidance in RFC 7454 provides broader context for filtering and routing hygiene, but the public record does not show which of those practices Haruzakura applies internally.

The practical reading is simple: origin security is the best-documented part of Haruzakura's current route. It deserves credit as a control, but it cannot be used as shorthand for uptime, physical resilience or product quality.

Redundancy has logical, physical and organisational layers

Public AS paths consistently place AS139317 immediately before AS153458. The Hurricane Electric peer table and BGP.tools profile agree with RIPEstat that this is the one observed adjacency. The AS153458 Whois entity separately names Ningbo Dahuamao's organisation as sponsor and its maintainer in mnt-lower and mnt-routes. This convergence is stronger than a single collector inference.

It remains a logical dependency. BGP's protocol definition in RFC 4271 explains how AS paths carry routing information, but an AS hop does not expose the physical implementation beneath it. One adjacent ASN might be reached through two routers and diverse circuits, or through one port and one cross-connect. Two BGP sessions could share the same conduit and power system. Public path data cannot distinguish those cases.

The inverse is also true. A route table showing only one active neighbour does not exclude a private, cold or non-announcing standby arrangement. Such a backup would not protect current traffic until activated, and no public test establishes that it exists or works. The correct finding is therefore one observed immediate adjacent AS, with physical and dormant backup paths unknown. It is not a claim of one cable.

Facility redundancy is a separate question. No public PeeringDB facility or exchange row means there is no named building, cross-connect or public peering port from which to calculate common failure domains. Power-feed diversity, generator autonomy, cooling topology, fire zones, remote hands and carrier entrances are unknown. A second ASN would not answer those questions, just as a second power feed would not solve a route-maintenance error.

Organisational redundancy adds another layer. The APNIC entities show Haruzakura and Ningbo Dahuamao occupying different roles, but public records do not show how many people hold credentials, who can contact upstreams, who can update RPKI or DNS, or what happens if a commercial account is suspended. A service can have physically diverse hardware and still fail because one individual or one supplier account controls recovery. Buyers need role and escalation evidence alongside topology.

The main failure paths cross company boundaries

The first failure path is the observed AS153458-to-AS139317 relationship. A failed session, route filter, maintenance-entity error, upstream outage or commercial interruption could remove the only visible /48. RPKI validity would not keep the route online; it would only validate an announcement that still existed. The decisive evidence would be a controlled withdrawal and alternate propagation test, or at least a current diagram and accepted routes from a second independent provider.

The second path is routing authority. The AS153458 APNIC Whois entity names Haruzakura in the aut-num record while its sponsor and route-maintenance fields point to Ningbo Dahuamao. The division of labour is private. During an incident, recovery could depend on access held by Haruzakura, the sponsor, or both. A customer should know who can change route objects, filters, ROAs and upstream sessions outside normal hours.

The third path is the separate web and DNS control plane. HiChina is the registrar and authoritative-DNS provider, while the observed web address sits in another registered allocation and route. A registrar lockout, expired domain, DNS misconfiguration or web-host failure can disrupt discovery and support independently of AS153458. Conversely, domain continuity does not protect the Haruzakura-originated prefix. Independent monitoring and out-of-band contacts are required to tell these incidents apart.

The fourth path is physical hosting, whose implementation is unknown. A router, server, storage array, rack, power feed, cooling system or facility can fail even when BGP remains present. Without an asset-to-site map and available headroom, there is no basis to estimate evacuation capacity or recovery time. Generic cloud architecture assumptions cannot fill a company-specific evidence gap.

The fifth path is contractual control over any infrastructure not owned directly by Haruzakura. The public record does not identify wholesale providers, colocation contracts or account hierarchies, so this risk is a question rather than a finding. If a supplier account exists, technical health may be irrelevant when renewal, credit, verification or acceptable-use action suspends it. Customer portability depends on whether data and credentials can be recovered without the affected account owner.

The sixth path is human operations. APNIC gives a named contact and a validated incident-response mailbox, but a registry contact is not a staffing roster or response-time promise. A widespread incident can exhaust a small team, while a credential or knowledge concentrated in one person can delay repair. Public evidence does not disclose Haruzakura's staffing or escalation capacity, so those values remain unknown rather than assumed small.

Who carries the impact when something breaks

The public evidence does not identify which customer services, if any, use the Haruzakura-originated /48. Impact analysis must therefore begin conditionally. A route withdrawal would affect endpoints addressed from 2406:840:feac::/48; it would not automatically affect every service sold under the Haruzakura name. Services using other providers' addresses could remain available, while an application inside the /48 could fail even if unrelated web or billing systems stayed online.

Partial failures are especially likely in a fragmented control plane. An AS153458 routing incident can be separate from the AS4837-routed website. A registrar or DNS incident can make a service hard to find while its IP address still responds. A physical host can fail while BGP remains healthy. A support channel can disappear while customer traffic continues. Monitoring only the company domain or only the ASN will miss some of these states.

Recovery can create secondary damage. Moving an endpoint may change its IP address, reverse DNS, allowlist position or mail reputation. Rebuilding without a current backup may restore software but lose data. A route repair may restore reachability while an application remains inconsistent. Customers need to define success at the application level, including data integrity and external dependencies, rather than treating a green BGP view as full recovery.

Haruzakura also bears reputational and operational impact when its suppliers or maintainers fail. Public records make one sponsor and adjacent network visible, but they do not reveal the private contract or allocation of responsibility. Customers may contact Haruzakura even when another party must change a filter or repair a circuit. Clear incident ownership and escalation are therefore part of the service, not administrative detail.

The proportionate response is to keep the blast radius bounded until the missing facts are supplied. Workloads should be rebuildable, backups should be independently controlled, credentials should not exist only in the provider portal, and external monitoring should distinguish DNS, route, TCP and application states. Higher-consequence systems require stronger proof of topology, recovery and organisational authority before concentration.

Data locality cannot be read from Hubei or CN

The HiChina Hubei field and APNIC China fields are useful identity and classification evidence. They are not a data-residency schedule. A registrant can administer a domain from one province while the domain's server, customer compute, backups and logs reside elsewhere. An ASN registered in China can announce a prefix over infrastructure in another jurisdiction. A contact address can remain unchanged while equipment moves.

Residency also has more than one copy. A primary virtual disk may sit in one facility while snapshots, entity backups, monitoring logs, support attachments and billing data sit elsewhere. Remote administrators may access systems across borders. Disaster recovery may create another copy only during an incident. None of these locations is disclosed for Haruzakura in the public records reviewed here.

A customer with contractual or regulatory requirements should obtain a written schedule covering primary data, replicas, backups, logs, telemetry, support access and deletion. It should name the legal entity responsible for each layer and state how location changes are notified. A country label without the facility operator and subprocessor chain is too coarse for sensitive workloads; a facility name without backup and support geography is incomplete.

The schedule should also distinguish normal operation from recovery. A provider may keep primary data in an approved location but restore from, or temporarily fail over to, a different jurisdiction. If that is possible, the contract should state the trigger, maximum duration, approval process and deletion of temporary copies. If no cross-border movement is permitted, the provider should demonstrate how recovery works within that constraint.

Network registration can help test the delivered service, but only after the customer has an address. The customer can identify the observed origin ASN and compare it with the promised host network. It can monitor route changes and ask why a prefix moved. That is a useful control against silent infrastructure substitution. It still cannot locate storage or administrative access by itself.

For this reason, the Asia-Pacific region in the Overview is a company classification anchored in China-based registry evidence. It is not a promise that customer data remains in Asia-Pacific, and it is not an assertion of a multi-country footprint. Exact data and facility geography remain unknown until Haruzakura supplies product-specific evidence.

What a serious buyer should request

The first request should be a product-to-infrastructure schedule for the exact service being considered. Haruzakura should name the contracting entity, operator, host ASN, address provider, facility city, data jurisdiction and party responsible for hardware repair. It should state whether it owns hardware, leases a whole server, rents virtual capacity, uses colocation or resells another provider. The public ASN should appear in this schedule only where it actually carries the product.

The second request should be a current network statement for AS153458. It should list active and reserved prefixes, direct upstreams, route-origin authorisations, route objects, port speeds, router count, configured standby paths and the people or companies authorised to change each item. It should reconcile PeeringDB's 24 IPv4 and 42 IPv6 fields with the zero IPv4 and one IPv6 prefixes visible in the July snapshot. Planned, delegated and dormant resources can be legitimate, but they should be labelled as such.

The third request should cover physical resilience. Which site, rack, power, cooling, router, storage and carrier failures can the service tolerate? Are redundant power supplies actually connected to independent feeds? Do diverse circuits use different carrier entrances and conduits? What powered compute and storage remain for evacuation after a host or rack loss? Who supplies remote hands, and what is the response target outside local business hours? None of these answers can be inferred from the APNIC address or AS path.

The fourth request should cover backup and recovery without presuming that either exists. Ask whether backups are automatic, what they include, how often they run, how long versions are retained and whether a copy sits in a separate failure domain and account. Obtain measured recovery-point and recovery-time results for a full restore. A snapshot inside the same storage system is not equivalent to an independently controlled backup.

The fifth request should cover service operations. Ask for incident-response targets, escalation paths, maintenance notice, status communications, security and abuse contacts, account-suspension rules and deletion timelines. The APNIC incident-response entity is a useful registry contact, but it is not a customer support commitment. A buyer needs a channel that remains reachable when the main website is unavailable and a clear handoff to Ningbo Dahuamao where routing authority requires it.

The sixth request should cover data location and subprocessors. For every data class, identify the primary location, replica and backup locations, log storage, support-access jurisdiction and any company that can process the data. Require notice before those facts change. If Haruzakura cannot name a building publicly for security reasons, it can still provide contractual city, operator and failure-domain information privately.

The seventh request should cover exit. Can the customer export disks, databases, configurations, logs and encryption keys without a support ticket? Which open formats are available, how long does export remain possible after cancellation, and what happens after account suspension? Can IP addresses move, or must the workload be renumbered? Who controls reverse DNS? A rehearsed exit converts supplier dependence from an open-ended risk into a bounded recovery problem.

Evidence that would change the assessment

Confidence in the network would rise if a second immediate upstream became visible for the active prefix and Haruzakura documented that the two paths use separate physical infrastructure. It would rise if PeeringDB gained current facility and exchange entries that matched measurement, and if the 24/42 prefix fields were reconciled with actual announcements. A public looking glass, route policy and status history would make changes easier to verify.

Confidence in capacity would rise with dated, product-specific evidence: node and storage architecture, available versus sold resources, backup retention, restore tests, spare hardware, power and cooling boundaries, and measured failover headroom. A facility contract or operator confirmation, accompanied by an inventory that distinguishes installed, powered, operational and available resources, would convert unknowns into auditable facts. Haruzakura should also distinguish its own guarantees from those of any supplier.

Confidence in data locality would rise with a clear schedule linking every product to primary data, snapshots, backups, logs and support-access locations. Confidence in recovery would rise with customer-visible export tools and a test showing a workload restored into an independent provider. These disclosures need not reveal sensitive rack coordinates or supplier pricing. They need to define failure domains and authority.

Confidence in company identity would rise with an accessible official company page or corporate-registry extract that identifies the contracting entity and connects it to the domain and network. A durable, dated copy of first-party service terms would establish what was offered and where, while an operator statement could connect those offers to actual host ASNs and facilities. Until such material exists, search-result fragments should not expand the footprint.

The assessment would weaken if the visible route disappeared for sustained periods, if RPKI became invalid, if registry contacts lapsed, or if the website remained inaccessible without an alternate channel. It would also weaken if a delivered service could not be reconciled with its invoice, operator, IP assignment and actual host ASN. Those would be observable changes, not inferences from silence.

One visible /48 defines the current public boundary

Haruzakura Cloud has more public substance than a name in an address list. APNIC records an organisation, a named contact, AS153458, an IPv6 /44 allocation and a separate /48 assignment. HiChina's registrar record adds a Hubei administrative region for the domain registrant. Public collectors show a current route, and the route has valid origin authorisation. Those are meaningful, reproducible signs of network activity and administrative continuity.

The evidence is nevertheless asymmetric. The route layer is measurable; the physical and commercial layers are mostly opaque. AS153458 exposed one IPv6 /48 through one observed adjacent network on 15 July. PeeringDB's 24 IPv4, 42 IPv6 and 1-5 Gbps fields are self-reported and do not match current origin counts. No public facility, exchange, rack, power, server inventory, sold-capacity or failover record closes the gap. The company website's observed address was registered to another provider and routed by another ASN, reinforcing the need to measure each control-plane component separately.

The final network evidence grade is Medium for identity and current route presence, and Weak for physical topology, redundancy and customer-ready capacity. That grade is not a claim that a service is unusable. It is a limit on what can be responsibly inferred. Haruzakura may operate equipment or deliver services beyond its public ASN, but no reproducible source links such a broader estate to locations, facilities or suppliers. The supported public boundary is the active /48, its valid ROA, and the observed AS139317 dependency.

Until a product-by-product explanation is supplied, prudent use is bounded. Keep the domain and DNS outside the hosting account. Keep restorable backups under independent control. Verify the ASN, facility, operator and jurisdiction for the exact instance delivered. Test the exit before the workload becomes important. Resilience exists only where contracts, routes, hardware, people and recovery capacity have been named and tested; neither an administrative address nor a BGP path can stand in for the missing layers.