Nine Cloud says it has 40 POPs and 2.9T of backbone, but the public Internet shows two /24s

Summary

• Nine Cloud's own website claims more than 40 self-operated POP data-centre nodes, more than 2.9T of fully interconnected backbone private lines and customer bandwidth products from 1M to 100G. Those figures describe the offer, but no public facility schedule, circuit inventory, power design or independent test demonstrates installed or usable capacity.
• AS131495 is active and originated two IPv4 /24s on 15 July 2026. One was a China-registered block with one visible adjacent network; the other was half of a Hong Kong company's /23 and was seen through two adjacent networks. That is evidence of live routing, not proof of 40 physically diverse POPs.
• Licence history, an active company website, a live latency tool and a 2024 public-procurement candidacy support continued commercial activity. They do not settle current asset ownership, data-centre operating responsibility, power resilience, customer load, available headroom or recovery performance.

Two views of the same network

The number at the centre of Nine Cloud's public presentation is not an autonomous-system number. It is "2.9T+", displayed on the company's home page beside "40+" POP data-centre nodes, 15-minute incident notifications and 99.95 per cent backbone private-line availability. Farther down the page, the company says those POPs are self-operated, cover most of China's first- and second-tier cities, and can deliver bandwidth from 1M to 100G. It offers point-to-point, hub-and-spoke and full-mesh enterprise private networking, connections between public clouds and customer premises, physical or virtual servers, and an "IDC Plus" service for customised data-centre requirements.

The number visible from the public Internet is smaller: two /24 IPv4 routes, or 512 addresses in total, originated by AS131495 in a RIPEstat snapshot for 15 July 2026. No IPv6 route was visible. One /24, 123.58.18.0/24, sits inside address space registered to the Beijing company. The other, 103.175.197.0/24, sits inside a /23 registered to HK JIUYUN INFINITE TRADE LIMITED. Route collectors saw three immediate neighbouring networks across the two prefixes, but not all three on each prefix.

These numbers are not mutually exclusive. A private-line operator can lease wavelengths, Ethernet circuits, rack space and last-mile access without announcing every customer-facing circuit in BGP. A POP can contain a router and cross-connects while using addresses originated elsewhere. A 2.9T commercial inventory may sum contracted bearer rates rather than public Internet transit. Equally, a national node map can overstate independence if many nodes share the same carrier, facility provider, duct, power utility, control system or upstream contract. The point is not that BGP should display 2.9 terabits.

It is that the public record does not bridge the gap between the marketing total and the physical system that would have to carry it.

That gap changes the due-diligence question. Nine Cloud has enough evidence to be treated as a live network-service business, not as a name attached only to an old registration. It does not have enough public evidence to treat every claimed node, route or unit of capacity as installed, powered, operational, unsold and recoverable. For a customer putting branch connectivity, cloud access, disaster recovery or hosted equipment on the platform, the missing bridge matters more than the headline total.

The company behind the name

The legal and operating history begins with a useful warning about continuity. A 2015 Shanghai Stock Exchange inquiry into another company's acquisition of Beijing Senhua Yiteng asked why Senhua had transferred its wholly owned Nine Cloud subsidiary to Hong Lei just before the transaction. The published response reproduced in Securities Times said Senhua established Nine Cloud in July 2013, that Hong Lei was its legal representative, and that it had not actually conducted business by the end of 2014. Senhua transferred the shares to Hong in January 2015 for no cash consideration, while offsetting an intercompany balance, to provide a platform for his future development after he left Senhua.

Nine Cloud's own development history begins commercial operation in April 2015 with version 1.0 of its EDPN product. It then claims a sequence of IDC, ISP, ICP, VPN and fixed-data qualifications; an independent autonomous-system number; a multi-line BGP product; a CDN licence; a Hong Kong company; nationwide monitoring; edge servers; a Hangzhou exchange connection; dual-carrier protection; a Shenzhen branch; and eventually a second backbone route. Read together, the stock-exchange disclosure and company timeline describe a business that was dormant under its original parent, separated in 2015 and then built an operating identity of its own.

That separation is important. The revenue, facilities, customer contracts and operational history attributed to Senhua Yiteng in the 2015 transaction cannot simply be assigned to Nine Cloud. The response explicitly distinguished the companies and said Nine Cloud had not conducted business before the transfer. Any later capacity must therefore be supported by Nine Cloud's own contracts, equipment, leases, licences and routes. The public record offers some of those layers, but not a complete asset trail.

A commercial-registry aggregator currently lists the Chinese company as established on 2 July 2013, with unified social credit code 91110108071674731C and registered capital of RMB30 million. It also reports a Beijing registration and broad telecom-related business scope. That aggregator record is useful for discovery but not a substitute for a fresh certified company extract. Public pages disagree about the current legal representative and exact registered suite. Nine Cloud's own contact page gives a Beijing headquarters office at rooms 325-331 in Enji Xiyuan and a Shenzhen office in Honglong Century Plaza. Office addresses identify places to contact the supplier; they are not data-centre addresses or proof of equipment ownership.

There are signs of more recent activity. Beijing's 2023 list of proposed technology-based small and medium enterprises includes the company in Haidian district. In September 2024, a CNOOC procurement notice ranked Nine Cloud second among three candidates for international-company IT communications network maintenance and technical support, with a bid of RMB4,375,680 and a score of 56.22. Being a qualified candidate supports the proposition that it was tendering for enterprise network work. It does not show that it won the contract, delivered the service, owned the relevant infrastructure or met a particular availability result.

A broad permission set is not an asset register

Nine Cloud's licensing history is substantial. An official Ministry of Industry and Information Technology list at the end of 2017 recorded the company under licence A2.B1-20170249 for content-distribution-network service in Beijing and Shandong. Industry reports said that in 2018 it obtained both CDN and cloud-service permissions. Public reproductions of later licensing notices show a scope change, a renewal in 2021 and a legal-representative change in 2023.

The official historic entry and the later notices support continuity of a cross-regional telecom licence, although the currently effective service schedule, geographical scope and expiry date should be obtained directly from the regulator or the company before a purchase.

The distinction between permission and implementation is explicit in Chinese telecom rules. MIIT's 2015 service-classification catalogue defines IDC service as using appropriate computer-room facilities to house, maintain and manage customer equipment, rent servers and storage, and arrange communications lines and outbound bandwidth. It defines cloud-like internet resource collaboration as using equipment and resources installed in data centres. It defines CDN service around distributed node server groups. A licence indicates that a company may conduct specified activities under specified conditions; it does not reveal which buildings it uses, whether it owns or leases them, how much IT load is powered, or how much capacity is already committed.

MIIT's 2017 market-clean-up notice sharpens the point. It targeted unlicensed and out-of-scope IDC, ISP and CDN activity, unauthorised resource use and multi-layer reselling. It required infrastructure, IP addresses and bandwidth to come from appropriately licensed providers and restricted unauthorised cross-border channels. The regulatory model therefore anticipates a supply chain: an enterprise service provider may combine its own network elements with facilities and circuits obtained from basic carriers and other licensed operators.

Nine Cloud's website describes exactly such a blended offer. It says it can provide China Telecom, China Unicom, China Mobile and BGP Internet bandwidth, physical server hosting, virtual machines, city access and long-haul private lines. That language does not identify the owner of each rack, optical span or power system. Nor should "self-operated POP" automatically be read as proof of data-centre ownership.

A self-operated router in leased rack space, inside a third-party facility and connected by leased carrier circuits, can be operationally meaningful while leaving critical physical dependencies outside Nine Cloud's control.

This is also why the article's region field says Asia-Pacific. The company says its Hong Kong business expanded into more than ten overseas areas and worked with international carriers. The Hong Kong address block and international adjacencies support some cross-border reach. They do not establish a global fleet of company-controlled facilities or local operating teams. Global reachability may be delivered through upstreams or partners; it is not evidence of a global physical operating footprint.

The documented physical operating area remains principally a Chinese city network with a Hong Kong routing component, and even within that area exact facility control is largely unknown.

What AS131495 proves

The strongest independent evidence is the network identity. APNIC's RDAP record for AS131495 names "Nine-cloud", describes Beijing Nine Cloud Infinite Network Technology and places the registration in China. The number was registered on 26 April 2017, remains marked active, and was last changed on 28 November 2023. The administrative and technical contact is Hong Lei, whose entity was last changed in 2017. Those records establish delegated control of an autonomous-system number and link it directly to the Beijing company. They do not show who currently configures the routers or signs carrier contracts.

The current routing table shows two different resource stories. APNIC's 123.58.16.0/21 record names Nine-cloud, describes the Beijing company and marks the block active in China. AS131495 currently originates one /24 from it, 123.58.18.0/24. The other visible route, 103.175.197.0/24, is one half of 103.175.196.0/23, an active Hong Kong allocation registered to HK JIUYUN INFINITE TRADE LIMITED. The common jywx.com contact domain and shared "Jiuyun" name suggest a commercial connection, but the public records reviewed do not provide a corporate-ownership document linking the Hong Kong company to the Beijing company. The safe statement is that the Beijing ASN originates address space registered to the Hong Kong entity.

Route-origin authorisation is also split. RIPEstat's RPKI validation result for 103.175.197.0/24 is valid for AS131495. The equivalent result for 123.58.18.0/24 is "unknown", meaning the validator found no applicable route-origin authorisation. Unknown is not invalid: networks that reject RPKI-invalid routes should not reject an unknown route merely for that status. Still, a customer evaluating route security would want to know whether Nine Cloud intends to create a valid authorisation for the China route and how it maintains route objects across registries.

The two prefixes also have different histories. RIPEstat's routing history shows AS131495 originating the full 123.58.16.0/21 during part of 2020, then intermittently announcing 123.58.18.0/24 from 2022 and again continuously in the observed period beginning April 2026. The Hong Kong /24 was originated by AS136897 in 2023 and early 2024, before AS131495 became the origin in February 2024 and remained visible through 15 July 2026. That history demonstrates change in routing control. It does not explain whether equipment moved, whether a customer or partner arrangement changed, or whether the physical hosting location stayed the same.

A live route is evidence of reachability, but it is a poor capacity meter. A /24 can sit behind a 1Gbps port or many larger circuits. It can host a small service or carry traffic for network functions that do not require many public addresses. Conversely, a private-line business can carry large volumes that never appear as customer routes originated by its own ASN. The defensible conclusion is narrow: AS131495 is active, has a small visible IPv4 origin footprint, and shows no visible IPv6 origin. Nothing in that conclusion validates or disproves the company's 2.9T private-backbone figure.

Three neighbours do not equal three diverse paths

RIPEstat's BGP-state snapshot showed a clear separation by prefix. For 123.58.18.0/24, collector paths placed AS24138, China TieTong Telecommunications Corporation, immediately before AS131495. For 103.175.197.0/24, paths placed either AS984, Octopus Web Solution, or AS136897, EnjoyVC Cloud Group, immediately before AS131495. Hurricane Electric's AS131495 summary independently listed the same three observed peers and the same two originated /24s.

This is useful evidence of logical diversity for the Hong Kong route. At the BGP policy layer, more than one external AS can propagate 103.175.197.0/24. It does not show two building entrances, two meet-me rooms, two fibre owners, two submarine systems, two power grids or even two routers. AS984 and AS136897 could enter the same facility, share a cross-connect provider or converge on a common upstream farther away. The public AS paths suggest different higher-level paths in many views, but a path string contains administrative identifiers, not a map of ducts and equipment.

The China /24 has a different limitation. Only AS24138 appeared immediately adjacent in the snapshot. The broader 123.58.16.0/20 covering route was originated by AS23724, China Telecom's Beijing IDC network. Nine Cloud's website resolves to 123.58.16.244, an address inside the company-registered /21 but outside the more-specific /24. RIPEstat therefore maps the website address to the China Telecom covering route rather than AS131495. This is a legitimate routing arrangement. It also illustrates why address registration, route origin, web hosting and physical server location must not be collapsed into one concept.

No public evidence reviewed establishes automatic failover between the China and Hong Kong prefixes. They are different address ranges with different adjacent networks and likely different use cases. A customer service on one range does not automatically become reachable on the other after a failure. Such recovery would require application replication, DNS or anycast policy, state synchronisation, tested routing changes and sufficient spare capacity.

The company's site describes disaster-recovery and multi-active designs as products, but it does not publish a status page, failover report or recovery test demonstrating those mechanisms for its own control systems.

The practical question is therefore service-specific. A buyer should ask which exact prefix, carrier and facility serve its primary circuit; which different prefix, carrier, building entrance and power domain serve the backup; and whether the secondary path has been tested while the primary is physically disconnected. A diagram with two carrier names answers only the first part. A traceroute collected while both links are healthy does not prove that either link can carry the full load alone.

The one public exchange port

Nine Cloud has a PeeringDB profile for AS131495. The network record identifies the Beijing company, applies a selective peering policy and lists one operational connection at NNIX in Hangzhou. The port is recorded as IPv4 address 103.164.64.125 at 1,000Mbps. No IPv6 address, route-server participation or facility record is listed. The exchange connection was last updated on 4 January 2022, while the overall network record was last updated on 26 October 2022.

That is specific evidence, but it has strict limits. PeeringDB is entity-maintained, the record is stale, and the "operational" flag is not a live telemetry feed. The associated NNIX exchange record places the exchange in Hangzhou but lists no facility set and no public entity-feed URL. A 1Gbps exchange port also cannot validate 2.9T of backbone capacity. It may be a small peering interface, a legacy entry, a management path or one edge among many private interconnections.

The company's development page says it joined a Hangzhou national exchange centre and became a member of a national interconnection committee. The PeeringDB entry corroborates participation at an exchange called NNIX, but not the broader institutional wording. It does not prove the location of Nine Cloud's router within Hangzhou, the owner of the rack, the cross-connect path, the traffic level or current port state. PeeringDB reports no disclosed traffic level, no looking glass, no route server, no IRR set and no interconnection facilities.

This thin profile makes the absence of IPv6 more consequential. Nine Cloud sells enterprise connectivity, cloud links, hosting and CDN-related services, all of which increasingly encounter dual-stack requirements. The public ASN currently originates no IPv6 prefix, and its listed NNIX interface has no IPv6 address. Customers may still receive IPv6 through another carrier or service ASN, but the public material does not say. A procurement specification should require an explicit answer: native dual stack, tunnelled service, upstream-provided IPv6, or IPv4 only; address allocation size; route security; and failover behaviour.

Forty dots are a commercial map, not a route survey

Nine Cloud operates a separate EDPN latency tool. On 15 July 2026 it returned a long selectable list of "core POP" cities, including Beijing, Shijiazhuang, Zhengzhou, Wuhan, Changsha, Guangzhou, Shenzhen, Xiamen, Fuzhou, Ningbo, Hangzhou, Shanghai, Nanjing, Chengdu, Chongqing, Shenyang, Harbin, Kunming, Nanning, Qingdao, Huizhou, Zhanjiang and Haikou. It also named several Beijing and Shanghai data-centre labels. The company home page displayed reference delays for city pairs, such as Beijing-Tianjin, Shanghai-Hangzhou and Guangzhou-Shenzhen.

This is better than a decorative map. The tool is live, the node selectors are machine-readable, and the city-pair table exposes testable latency claims. It supports the conclusion that Nine Cloud has built or commissioned a system intended to measure a multi-city service. It still does not reveal the probe IPs, test frequency, packet size, direction, percentile, loss, sample window, carrier, facility coordinates or whether each selected endpoint is customer-available today. A label called "core POP" is not an engineering acceptance certificate.

The geography is city-level. No public map reviewed provides fibre polylines, duct owners, long-haul circuit IDs, landing stations, building entrances or meet-me-room coordinates. The named data-centre entries may identify possible service locations, but the tool does not state whether Nine Cloud owns equipment there, resells another provider's service, keeps spare ports there or merely has a quoted access product. The office map on the contact page is even less relevant to physical network geography: headquarters and branch offices are not automatically POPs.

The company says its city network combines protected metropolitan access with protected long-haul backbone links. It offers bare fibre, OTN wavelengths, Layer 2 circuits, Layer 3 routed circuits, SDH and MSTP, with different handoff interfaces. Those product types require very different control boundaries. Bare fibre may leave optical equipment to the customer; an OTN service depends on the carrier's line system; an Ethernet private line can hide several shared transport layers; an Internet service depends on BGP policy and transit. A single map cannot describe redundancy for all of them.

For each purchased route, useful map evidence would include the A and Z sites, facility operator, meet-me room, demarcation, local access carrier, long-haul carrier, protected-path class, shared-risk link groups, optical or packet layer, restoration target and last acceptance-test date. Without those fields, the 40-node map is a service-availability hypothesis. It is commercially informative and geographically suggestive, but it cannot establish physical route diversity.

What 2.9T could mean

The homepage label reads "2.9T+ backbone private-line full interconnection" without defining the unit. In this context, terabits per second is the natural interpretation, but the page does not say whether 2.9T is lit interface capacity, contracted carrier capacity, sum of node-to-node bearers, theoretical switching throughput, peak traffic, billable customer bandwidth or a double-counted aggregate across both ends of circuits. It gives no as-of date beside the number and no utilisation figure.

Each interpretation has a different operational meaning. A router with several 100Gbps ports has installed port capacity even if the upstream circuits behind them are smaller. A 100Gbps wavelength is lit capacity after optical equipment and carrier acceptance, but only part may be reserved for Nine Cloud. A full-mesh sum can count the same underlying long-haul span in several marketed paths. Sold customer commitments reduce available capacity, and oversubscription means headline bandwidth cannot necessarily be used simultaneously. None of those conditions can be derived from the website total.

The 1M-100G product range is likewise an orderable granularity, not proof of immediate delivery at every POP. Nine Cloud says existing resources enable rapid delivery and that bandwidth can be adjusted as often as daily. To turn that into usable capacity, a buyer needs a service address, access method, committed information rate, burst policy, 95th-percentile calculation, installation lead time, port inventory and augmentation procedure. The site mentions 95th-percentile billing, but not sampling exclusions, inbound-versus-outbound calculation or whether the committed base remains available during protection switching.

Availability figures need the same discipline. The homepage displays 99.95 per cent for backbone private lines while the service section says customer-specific contractual promises can reach 99.99 per cent. The development history says a second backbone route raised network availability to 99.99 per cent. These statements could all be consistent if they cover different products, periods or measurement boundaries. They are not interchangeable. Over a non-leap year, 99.95 per cent allows roughly four hours and 23 minutes of unavailability, while 99.99 per cent allows about 53 minutes.

Maintenance exclusions, packet-loss thresholds, latency thresholds, force majeure, access tails and customer equipment can change the result substantially.

No public capacity figure was found for racks, cabinets, server count, CPU, memory, storage, IT megawatts, utility megawatts, UPS, generator runtime, cooling, fuel, spares, occupied ports or remaining headroom. No public figure shows sold or reserved capacity. The company's cloud and IDC offer may be supplied through partners, but the partner facilities and allocation terms are not disclosed. For hosted-compute resilience, 2.9T of network cannot substitute for a powered rack, spare hardware, recoverable data and a tested migration path.

The physical layer remains mostly unknown

The largest evidence deficit is not routing. It is the built environment. Nine Cloud names cities and some facility labels, but does not publish a facility inventory tied to legal owner, operator, leaseholder or equipment custodian. There is no public record reviewed of land, building or data-hall ownership. There is no rack schedule showing where Nine Cloud routers and servers are installed. There is no list of carrier meet-me rooms or cross-connects. The defensible assumption is neither ownership nor absence; it is unknown.

Power is equally opaque. A POP router needs utility supply, switchgear, UPS or DC plant, batteries, generator backup, cooling and environmental monitoring. A hosted server fleet adds much more load and thermal dependency. Nine Cloud publishes no power-feed count, substation, generator topology, runtime, refuelling contract, load bank test, PUE, rack density or recent outage test. China's green-data-centre programme sets efficiency expectations for large facilities, and MIIT's sector plan targeted PUE below 1.3 for new large and hyperscale data centres by 2025.

Those policy targets are context, not evidence that any Nine Cloud site meets them.

Facility ownership and operating responsibility must also be separated. A data-centre landlord may own the building and power plant. A licensed IDC provider may lease halls or racks. Nine Cloud may own routers and servers inside those racks, lease them, or resell capacity. A carrier may own the fibre, while another provider handles the local loop and a third controls the cloud on-ramp. Each party has a different maintenance window and escalation path. A customer contract that names only Nine Cloud can still depend on all of them.

The website's claim is 40+ "self-operated POP computer rooms". Operation does not establish ownership: even if every node contains equipment controlled by Nine Cloud, the public material does not identify who owns the rooms, buildings, power systems or connecting circuits. The named Beijing and Shanghai facilities in the latency tool appear to be third-party data-centre brands or location labels, which points toward colocation or interconnected access. That is common and not inherently weak. It becomes a risk when the protection design, lease term, access rights and supplier concentration are not disclosed.

Physical resilience should therefore be assessed route by route and site by site. Two routers in one room do not protect against a room outage. Two rooms in one building do not protect against a building utility failure. Two buildings on one campus may share a substation or fibre entrance. Two carriers can share a duct or long-haul cable. Two cities can still depend on one network operations team or one configuration system. The public record does not resolve any of these shared-risk questions.

Failure path one: access and backbone

For an enterprise branch, the first failure may occur before traffic reaches a Nine Cloud backbone node. Building access depends on landlord permission, riser space, a local-loop carrier, street ducts and a handoff device. Nine Cloud advertises experience coordinating building entry and last-mile fibre. That is operationally valuable, but it also confirms that delivery relies on local physical and contractual conditions. A cut duct, failed access switch or expired property agreement can isolate a customer even while every backbone route remains healthy.

Inside the backbone, failure modes include optical loss, amplifier or transponder faults, line-card failure, router software defects, exhausted ports, route leaks, traffic-engineering mistakes and maintenance errors. Protected transport only works if the protection path is disjoint and has enough capacity. The company's reference latency map does not reveal shared-risk groups, and its public BGP view covers only Internet-facing prefixes. Private Layer 2 and optical paths cannot be reconstructed from those routes.

The split upstream picture creates service-specific exposure. Traffic to the China /24 currently reaches AS131495 through one visible adjacent AS. A fault or policy withdrawal at that boundary could remove the more-specific route even though the covering China Telecom route remains. Whether customer services would still be reachable depends on address use and routing configuration. The Hong Kong /24 has two visible adjacent networks, but their physical independence is unknown. Neither arrangement proves that a purchased private line has equivalent protection.

Congestion is another failure state. A path can remain up while latency, jitter or packet loss makes it unusable for voice, live video, replication or interactive applications. Nine Cloud's city-pair latency references are point values, not percentile distributions under load. A meaningful service objective should state delay, jitter and loss thresholds; test points; measurement intervals; exclusions; and remedy. It should also say whether protection switching preserves those thresholds or merely restores basic reachability.

The people affected depend on the product. A branch-network failure can stop authentication, ERP access, payment, voice and video. A cloud-link failure can strand applications from offices or separate active systems from databases. A CDN or acceleration failure can slow public services across a region. A data-centre uplink failure can isolate many hosted customers at once. The broader Nine Cloud's aggregation, the more important transparent fault domains and customer communications become.

Failure path two: racks, power and hardware

Hosted capacity creates a different chain. A virtual machine advertised by Nine Cloud ultimately runs on a physical server with processors, memory, storage, network interfaces and firmware. That server sits in a rack with power distribution, top-of-rack switching and cooling. The rack sits in a room whose utility, UPS, generator, fire protection, access control and operating staff may belong to another company. A service can fail at any layer while the public ASN continues announcing routes.

Hardware inventory determines recovery time. If a power supply, disk, line card or server fails, a provider needs compatible spares, access authority and a technician who can reach the site. The company site says it offers one-to-one technical groups, but its contact page advertises 5-by-8 remote support and a weekday national hotline. It does not publish a 24-hour on-site response target, spare-parts locations or remote-hands contract. A customer requiring continuous operations should reconcile those support descriptions in writing.

Power failure deserves explicit treatment because network marketing often hides it. Dual utility feeds may come from one substation. Dual UPS systems may enter one static switch. Generators may have limited fuel or shared capacity. Cooling can fail independently of electrical supply. A maintenance bypass can remove redundancy without a public outage. No Nine Cloud material reviewed identifies these designs, so no power-resilience rating can be assigned to its POPs or hosted services.

Recovery also depends on data. A second data centre is not a backup unless data is replicated at an appropriate recovery point, the application can start there, dependencies are reachable and staff can execute the plan. Nine Cloud markets two-site, three-centre and local dual-active designs, including a claimed three-route, four-line topology and up to 99.99 per cent service assurance. Those are solution patterns. The company does not publish an executed failover test, recovery-time result, recovery-point result or customer data-portability procedure.

For customers, the contract should name the primary and recovery locations, data replication method, encryption, backup ownership, export format, deletion process and migration assistance. It should say who pays for egress, cross-connects and temporary parallel running. Without that information, moving away after a provider or facility failure may be slower than restoring the original service. The failure of a supplier contract can become a technical outage even when all equipment still works.

Failure path three: control, support and commercial dependencies

Network resilience is also a control-plane and organisational property. Configuration systems, authentication, monitoring, ticketing, billing and customer portals can create common failure domains across many sites. Nine Cloud says incidents are reported every 15 minutes and promotes a dedicated technical group for each customer. It does not expose a public status history, maintenance calendar, incident archive or service-credit record. Customers cannot judge from the outside how quickly the company detects, escalates and explains faults.

The public website itself illustrates an operational boundary. jywx.com resolves to 123.58.16.244 and serves a current Nuxt site over HTTP, but an HTTPS connection failed during checks on 15 July 2026. The site is reached through China Telecom's covering route rather than AS131495's current more-specific routes. This does not show that customer network services lack encryption or availability. It does show that the company's public information service has a different routing dependency from its ASN and lacks the ordinary HTTPS front door expected for a modern commercial site.

Commercial concentration can be more important than router count. If many POPs use one carrier master agreement, one data-centre group, one hardware vendor or one operations contractor, a payment dispute, licence issue, supplier insolvency or support termination can affect several cities. The website names many partners and customer brands, but the customer-case page consists largely of names without scope, dates, contract values, service descriptions or independently confirmed outcomes. Those logos are market signals, not capacity reservations or performance references.

The 2024 CNOOC candidacy offers a more concrete signal because it comes from the buyer's procurement system. Yet even there, Nine Cloud ranked second rather than first, and the notice concerns IT communications maintenance and technical support, not ownership of a national backbone. A buyer should ask for recent references matching the exact product: a private line is not a hosted cloud, and a maintenance contract is not a disaster-recovery service.

Licensing is a further dependency. Public notices indicate the cross-regional licence was renewed and later amended, but customers should obtain the current original, service categories and approved regions. Cross-border connectivity and data placement require particular attention. MIIT's rules restrict unauthorised cross-border channels, while a Hong Kong-registered address block is originated by the Beijing ASN. That routing fact does not establish where customer data is stored, where traffic is inspected, or which contract entity supplies the service.

Data locality cannot be inferred from an IP label

The Hong Kong prefix makes locality questions concrete. APNIC marks 103.175.196.0/23 as a Hong Kong resource and names a Hong Kong registrant. IP geolocation services also tend to place the visible /24 in Hong Kong. Neither registry country nor geolocation proves the building that contains a server. Addresses can be announced remotely, tunnelled, used for anycast or reassigned within a network. Conversely, a China-registered address can carry traffic to infrastructure elsewhere.

Nine Cloud's service material describes hybrid-cloud links, multi-cloud distribution, disaster recovery and overseas edge services. Each can move or replicate data across administrative and geographic boundaries. A customer concerned with sovereignty needs an asset and data-flow schedule, not an IP-country assumption. The schedule should identify storage location, processing location, backup location, support access, log location, encryption-key control, subcontractors and lawful-transfer basis.

The same rule applies to claims of global service reach. International upstreams can provide global reachability from one Hong Kong rack. They do not create local capacity in every market. A partner can deliver a last mile abroad without Nine Cloud owning that circuit. Neither model is inherently inferior, but outage responsibility and data handling differ. The contract should identify the supplier entity in each jurisdiction and the escalation path when a subcontractor fails.

Route security affects locality indirectly. The valid RPKI authorisation for the Hong Kong /24 helps networks reject an unauthorised origin, while the China /24 remains unprotected by a validating authorisation. RPKI does not prevent path leaks after the authorised origin, protect DNS, encrypt traffic or prove physical location. It is one control in a larger chain. Customers should ask for route filters, maximum-prefix limits, IRR maintenance, DNS security, DDoS arrangements and change approval as separate controls.

The lack of public IPv6 also deserves a locality question. If a customer needs IPv6 but Nine Cloud obtains it from a partner ASN, traffic may take a different route and fall under a different operational boundary than IPv4. The address provider, route origin, exit location and failover design should be documented for both protocols. A dual-stack application is only as resilient as the weaker family.

What a buyer should require before relying on the 40-POP claim

The first request should be a dated service-specific topology. It should mark the exact POPs used by the customer, not every city on a sales map. Each node should name the facility operator, room or meet-me area, Nine Cloud equipment, rack-power arrangement, local access carrier, backbone carrier, handoff and responsible maintenance party. Routes should show shared-risk groups rather than decorative straight lines. Sensitive details can be disclosed under a confidentiality agreement; the absence of any verifiable schedule is the concern.

The second request should reconcile capacity. For each relevant circuit and port, the buyer should see design rate, installed rate, carrier-accepted rate, currently lit rate, committed customer load, protection reservation and available headroom. The 2.9T total should come with a definition and date. A 100G product should be tied to a specific deliverable interface and lead time. For hosted capacity, the same table should include racks, IT power, server inventory, storage, backup and spare hardware.

The third request should prove recovery. A test should fail the real primary access path, not only change a route preference in software. Results should record detection, switching, packet loss, capacity after switching, application recovery and restoration. Data-centre tests should include power and cooling scenarios within the facility operator's safety rules. Cloud and hosted services should demonstrate restore from backup and export to another provider. The report should identify failed steps and remediation, not just a pass label.

The fourth request should align support with risk. Nine Cloud's public contact page says 5-by-8 remote support, while its products serve applications that may run continuously. The customer should obtain 24-hour severity-one contacts if required, on-site response times, spare-parts coverage, carrier escalation, notification intervals, root-cause deadlines and service credits. It should verify that the people named in APNIC, PeeringDB, the licence and the contract are current or have defined successors.

The fifth request should settle legal and data boundaries. The company should provide a current certified registration, telecom licence and scope; identify the relationship with HK JIUYUN INFINITE TRADE LIMITED; name subcontractors; and state where customer data, logs and backups reside. It should explain how a customer exits, receives its data and moves circuits if a facility lease or provider contract ends.

None of these requests assumes that Nine Cloud's claims are false. They translate broad network language into evidence that can be priced and enforced. A small public BGP footprint can support a valuable private network. A leased national backbone can be resilient. A 1Gbps exchange port can coexist with much larger private circuits. But each proposition requires the right document, test and control boundary.

An operating network with an evidence discount

Nine Cloud is more than a dormant company shell. It has a live autonomous-system registration, current routes, a valid RPKI authorisation for one prefix, a entity-maintained exchange record, an active company website, a functioning multi-city latency tool, licence history and a recent enterprise procurement signal. Those facts support a medium-confidence conclusion that it continues to operate and market network services.

The confidence falls sharply at the physical and capacity layers. No public evidence reviewed verifies 40 current POP installations, their ownership, their power state or their shared-risk separation. No public evidence defines the 2.9T total, reports utilisation, identifies sold capacity or demonstrates recovery under failure. The two public /24s and three observed adjacent networks show reachability and some logical diversity, not a national physical topology. The 1Gbps NNIX record is specific but stale and far too narrow to validate the aggregate claim.

That produces an evidence discount, not a verdict of non-operation. Buyers should value the service on the facilities, circuits, support terms and tests Nine Cloud can document for their route. They should not price it as a 40-site, 2.9-terabit, 99.99-per-cent platform merely because those numbers share a page. Nor should they dismiss it because only 512 IPv4 addresses are visible behind its ASN. Public Internet scale and private transport scale measure different things.

The decisive evidence would be straightforward: a dated POP and facility inventory, carrier and power boundaries, installed and usable capacity, customer-specific protection paths, current licences, route-security completion, and witnessed failover results. Until those appear, the best-supported description is precise. Nine Cloud operates a small visible Internet edge around AS131495 and markets a much larger Chinese private-network and hosting fabric. The edge is observable. The fabric remains a claim that must be verified one circuit, rack and recovery test at a time.