CHINANET SHAANXI province Cloud Base network sells hosted capacity that still depends on racks, transit and repair windows

Summary

• APNIC RDAP lists AS134768 as CHINANET-SHAANXI-CLOUD-BASE, with the descriptive name CHINANET SHAANXI province Cloud Base network, country CN, registration in 2015 and a Chinanet hostmaster contact.
• Current route visibility is strong. RIPEstat's AS overview reports AS134768 as announced, while RIPEstat routing status shows 86 IPv4 prefixes, 39 IPv6 prefixes and 11 observed neighbours in the checked public window.
• The topology is still parent-dependent. APNIC-derived whois data lists imports from AS4134 and AS4809, but current public neighbour views from RIPEstat, bgp.tools, Hurricane Electric's BGP page and IPinfo all make AS4134, China Telecom Backbone, the visible upstream.
• Public address evidence is mixed in a way that matters for hosted capacity. Many originated prefixes are Shaanxi Chinanet resources, but public BGP views also show routed space described as IDC and cloud service, leased line, Baidu, Zhejiang, Guangdong and Sichuan Xiaoteyun address blocks, so a customer cannot infer workload ownership or rack location from the AS number alone.
• Public facility signals point to a real Xi'an/Xixian cloud-computing base. A 2025 Northwest University visit report describes the China Telecom Cloud Computing Shaanxi Base as a large western China cloud and big-data centre with more than 10,000 racks, T4-standard rooms, PUE as low as 1.25, high-density rack options and a role in provincial government cloud operations.
• The evidence grade is Medium, not Strong. The network is visibly alive and large, but public sources do not publish a current, product-specific map of rack ownership, power feeds, upstream failover, restore tests, data-portability limits or support escalation for customers buying hosted capacity through this cloud-base network.

A live route table is only the first proof

A hosted-capacity provider can look reliable in two very different ways. One proof is the route table: routes are visible, prefixes are authorized, packets have a path, and the AS appears under a known carrier. The other proof is operational: the racks have power, the cooling system has headroom, the hypervisors have spare capacity, the backup copy is restorable, the support desk can reach the right engineer, and the customer can move data out when the relationship ends. CHINANET SHAANXI province Cloud Base network has a strong first proof and a thinner public second proof.

The official identity is straightforward. APNIC RDAP for AS134768 names the AS CHINANET-SHAANXI-CLOUD-BASE and describes it as CHINANET SHAANXI province Cloud Base network. The record places it in China, shows registration on 27 October 2015, and lists Chinanet hostmaster contacts. RIPEstat's whois view repeats the same AS name and description, and adds route-policy lines importing from AS4134 and AS4809 and exporting AS134768 to those networks. That is enough to treat the network as a real China Telecom Shaanxi routing subject, not a vague cloud slogan.

The current route state is also material. RIPEstat's routing status showed AS134768 visible to nearly all RIS peers in both IPv4 and IPv6 in the checked July 2026 window. It counted 86 IPv4 prefixes, 39 IPv6 prefixes, 184,576 IPv4 addresses and 12,576 IPv6 /48 equivalents. RIPEstat's announced-prefixes view listed 125 current prefix entries across IPv4 and IPv6. Hurricane Electric's BGP page reported a similar scale, with 184,576 originated IPv4 addresses and no originated invalid RPKI routes in its current view. Those are not the signs of a dormant ASN.

But a route table does not show the whole service. It does not say whether a virtual machine is running in a China Telecom-owned hall, a customer-owned rack inside the hall, a partner-operated cabinet, a Tianyi Cloud region, a government-cloud pool, a leased-line environment or a third-party colocation arrangement. It does not reveal whether the advertised space is attached to production servers, edge gateways, customer routers, hosting nodes, content platforms or private business links. It does not tell the buyer how long a failed server takes to replace or whether an overloaded support queue can delay a migration.

That difference is the article's central dependency. AS134768 sells the impression of networked cloud capacity, and the public BGP evidence supports the existence of a large, active China Telecom Shaanxi edge. The buyer still has to test the physical and contractual layer behind that edge.

In hosting, the most damaging outage is often not "the internet disappeared." It is the smaller, harder failure: a rack loses one feed and the remaining feed is already loaded, an upstream change exposes a route leak, a storage pool has backups but no fast restore path, a billing hold blocks export during a migration, or a maintenance window is treated as outside the availability promise.

What public routing proves

Public routing proves that AS134768 is visible and important enough to monitor. RIPEstat's AS overview identifies the holder as CHINANET-SHAANXI-CLOUD-BASE, with the same descriptive name used by APNIC. RIPEstat's current routing status shows broad IPv4 and IPv6 visibility, not a fringe route seen by a few collectors. The same status page reports first-seen activity in January 2017 and a last-seen item on 12 July 2026. The route history therefore supports continuity: the public internet has seen this ASN for years, and it was not merely registered and abandoned.

Third-party aggregators line up with that picture. bgp.tools classifies the network as active under APNIC, labels the network type as content, shows China Telecom Backbone as the upstream, and reports 75 IPv4 and 39 IPv6 originated prefixes in its visible view. Hurricane Electric's AS134768 page reports 127 originated prefixes in total, 88 IPv4 and 39 IPv6, plus 11 observed BGP peers. IPinfo describes the ASN as hosting-oriented, lists China as the country, shows tens of thousands of hosted domains on addresses in the ASN, and names AS4134 as the upstream in its visible summary.

There are differences in the counters because public BGP collectors use different vantage points, filtering choices and update times. RIPEstat counted 86 IPv4 prefixes in the routing-status view, while bgp.tools showed 75 originated IPv4 prefixes and Hurricane Electric showed 88. That variation should not be overread as a contradiction. The common signal is more important than the exact number: AS134768 has a large routed surface, a strong China Telecom parent path and a large mix of IPv4 and IPv6 resources.

The route-origin evidence also looks better than many small hosting networks. RIPEstat route-origin validation for representative Shaanxi IPv4 blocks such as 36.41.64.0/20, 113.142.128.0/17 and 117.34.124.0/23 returned valid status for AS134768 in the checked results. The same is true for sample IPv6 cloud and network blocks such as 240e:982:4500::/40 and 240e:108:1140::/48. Valid ROAs do not guarantee service quality, but they reduce one class of route-origin risk.

The operational conclusion is therefore not "weak network." It is "strong public routing, incomplete customer evidence." A customer can reasonably believe AS134768 is active. It should not, from that alone, believe its hosted workload has multi-site protection, two independent power paths, tested backup recovery or easy data portability. BGP answers the reachability question. Hosted capacity requires several other answers.

The upstream story is narrower than the registry policy suggests

AS134768's APNIC-derived whois record names two imports: AS4134 and AS4809. AS4134 is China Telecom Backbone. AS4809 is China Telecom's CN2 network, often associated with premium backbone paths. If both paths were actively and independently carrying customer workloads, that would be useful diversity. The public route views do not prove that stronger reading.

RIPEstat's ASN neighbours view showed 11 observed neighbours in the checked window. The left-side neighbour was AS4134 with high visibility in IPv4 and IPv6. The right-side neighbours were a set of Shaanxi China Telecom 5G city networks, including AS138387 for Xi'an, AS138409 for Tongchuan, AS138436 for Baoji, AS138513 for Weinan, AS138514 for Xianyang and others visible mainly in IPv6. IPinfo's summary also counted one upstream, AS4134. bgp.tools similarly presented AS4134 as the upstream. Hurricane Electric showed AS4134 as the IPv4 peer and also the named IPv6 peer in the visible table.

The gap is not fatal. A large operator may keep route-policy records that reflect internal engineering, planned paths or private interconnection that public collectors do not expose fully. AS4809 may still matter for some services even if AS4134 is the visible public upstream in the sampled views. But a customer buying hosted capacity should not treat the AS4809 line in whois as proof of a live, customer-affecting failover path.

The test is current, product-specific evidence: which upstream carries this service, what fails over to what, how route policy is filtered, how RPKI is enforced, and whether the backup path has enough committed capacity during peak load.

This is especially important because all the visible paths sit inside the wider China Telecom family. Parent-network resilience can be excellent, but it is not the same thing as commercial or physical independence. A true diversity claim would separate at least four layers: BGP path diversity, carrier or backbone diversity, physical path diversity, and spare capacity after failover. If both routes depend on the same metro fibre trench, the same cloud-base core switch, the same building entrance or the same China Telecom control plane, the second AS line may not protect the customer from the failure it cares about.

The right procurement language is not hostile. A buyer can ask: "For the service we are purchasing, which origin AS, upstream ASNs, prefixes, availability zones and physical data halls are in scope? Which path is primary? Which path is tested? Which path is merely available to the operator elsewhere in the network?" That distinction keeps a strong China Telecom network from being over-sold as full multi-provider resilience.

The prefix mix shows hosting, access and partner surfaces together

The public prefix list is broad enough to suggest more than one business surface. Many visible prefixes are straightforward Shaanxi Chinanet network space. APNIC RDAP for 36.41.64.0/20 resolves to a larger CHINANET-SN allocation, and the administrative contact label places the data-communication bureau in Xi'an. APNIC RDAP for 113.142.128.0/17 similarly resolves to a CHINANET-SN allocation. Those blocks support the case that AS134768 carries Shaanxi China Telecom address resources, even though some legacy descriptions use the "Shanxi(SN)" spelling in ways that can confuse Shaanxi with Shanxi. The Xi'an contact context is the practical anchor.

Other routed resources make the operating boundary more complicated. bgp.tools lists several 103.236.0.0/22-style blocks with descriptions for Sichuan Xiaoteyun Technology. APNIC RDAP for 103.236.88.0/22 identifies XIAOTEYUN as the registered resource name and a Chengdu, Sichuan contact, while RIPEstat's prefix overview shows AS134768 as the current origin in the checked route view. bgp.tools also shows some Baidu-described and non-Shaanxi Chinanet-described prefixes under the AS134768 page. The presence of those resources is not evidence of wrongdoing. It is evidence that origin AS, customer, resource holder and facility placement can diverge.

That divergence is normal in large networks. An operator may originate customer PI space, DDoS-protected space, cloud addresses, leased-line networks, content delivery blocks, government cloud segments or partner allocations. The customer risk is that the AS name alone cannot tell the buyer which operating arrangement applies. A VPS running on China Telecom cloud infrastructure is not the same as a customer router whose prefix is originated by AS134768, and neither is the same as a website hosted on an IP address counted by IPinfo's hosted-domain data.

IPinfo illustrates why this matters. It reports more than 23,000 domains hosted across addresses in the ASN and highlights 103.236.90.151 as an address with thousands of domains. That is a useful market signal: the ASN appears to host domain-dense web traffic. It cannot prove the contractual owner of those sites, the location of the racks, the backup policy, or whether the address belongs to a reseller, a shared hosting platform, a CDN layer or a customer-managed environment.

For customers, the address map should be part of onboarding. Which prefix will be assigned to the service? Is it China Telecom Shaanxi space, customer space, partner space or Tianyi Cloud shared space? Who controls reverse DNS, abuse handling, ROA creation, firewall policy and emergency null-routing? If the service is migrated, does the IP move with the workload or does the customer receive new addresses? Those questions turn a large route table into an actual dependency map.

The cloud-base label points to physical capacity

Public facility signals make the "Cloud Base" name more than decorative. A 2025 Northwest University School of Economics and Management visit report describes the China Telecom Cloud Computing Shaanxi Base as having started construction in 2013 and entered formal operation in 2015. The same report describes it as a large western China cloud-computing and big-data centre, with T4-standard computer rooms, PUE as low as 1.25, more than 10,000 racks, 5 kW, 8 kW, 12 kW and higher-power liquid-cooled cabinet options, a 22T export-bandwidth display claim and a role as one of China Telecom's core IDC backbone nodes. It also says students were shown cooling, power distribution, security capabilities, and the provincial government-cloud architecture.

That is stronger than a vague product page because it describes physical attributes: racks, power density, cooling design, fire protection, bandwidth and a campus role. It also lines up historically with a 2015 Data Center Dynamics report on China Telecom's Xi'an cloud computing base, which described the opening of a western-region cloud base and noted China Telecom's wider regional cloud-node strategy. Secondary and partner pages, including Fenghuoyun's node description and a 2018 Shaanxi Phoenix article about Tianyi entrepreneurship cloud services, also locate the Shaanxi cloud base in Xixian New Area's Fengxi New City and discuss IDC, cloud and colocation-style capacity.

Those public facility descriptions help, but they still have to be read as facility-level context rather than customer-specific proof. The Northwest University page is a site-visit report, not a service contract. The Fenghuoyun and Phoenix pages are partner or media-style descriptions, not neutral audits. Design capacity is not the same as usable capacity. A rack count is not a statement about empty rack availability, power headroom, spare switches, hardware inventory, customer migration windows or the current split between cloud, government workloads, internet access, leased-line and partner services.

The most useful conclusion is physical specificity with a caveat. Customers should assume there is a significant China Telecom cloud and IDC campus associated with the Shaanxi cloud-base story. They should not assume that any service routed through AS134768 is physically in one named hall, backed by the whole campus, or protected by every redundancy feature described in a public tour. A cloud base can host several logically separate environments. Some may have two-site disaster recovery. Some may be single-zone. Some may be partner racks. Some may be public cloud zones. Some may be customer colocation.

The buyer should therefore ask for the actual placement statement: campus, building, room class, rack or availability-zone mapping, power feed design, cooling class, cross-connect path, maintenance-policy scope and whether the service is in a shared platform or a dedicated rack. The answer matters more than the base's total scale.

Installed capacity is not usable capacity

The public cloud-base material emphasizes scale, and scale is useful. A campus with thousands of racks, high-density cabinet options and a large China Telecom backbone relationship can absorb more demand than a small office-hosted provider. It also has more layers where the customer's service can depend on the operator's internal allocation choices.

Installed capacity is what has been built or can be shown in a public plan. Usable capacity is what the customer's workload can consume without violating power, cooling, storage, network or support constraints. Recoverable capacity is what remains available after a fault. A rack count says little about the second and third categories. If all spare high-density capacity is reserved for government cloud workloads, a commercial hosted server may not benefit. If the backup storage pool is large but restore bandwidth is narrow, a customer may have a backup without a recovery path.

If the cloud base has 22T of displayed export bandwidth but the customer's product tier is rate-limited or single-homed within a service segment, the headline bandwidth does not define the customer's failure mode.

Tianyi Cloud's own public documentation reinforces this layered view. The Tianyi Cloud homepage presents the brand around cloud-network integration, security, dedicated customization and multiple cloud forms, including public, private, dedicated, hybrid, edge and full-stack cloud services. Its ECS documentation for regions and availability zones explains an availability zone as one or more physical data centres within a region, with independent power and network, and says the goal is fault isolation except for large disasters or major power failures. That is a sensible architecture statement. It also means the customer has to know whether the purchased workload actually spans zones, or whether it is simply in one local resource pool.

The same is true of bare-metal, VPS, colocation and managed-service capacity. A customer buying a cabinet wants spare power, remote hands, cross-connect lead time, replacement hardware and maintenance windows. A customer buying virtual machines wants hypervisor cluster size, storage replication, snapshot isolation, image export and failure-domain placement. A customer buying public-sector cloud wants policy compliance, backup location, identity controls and tested disaster recovery. AS134768 may carry traffic for all of those surfaces, but each one has a different definition of usable capacity.

The practical test is to ask for a capacity statement under fault. How much compute, storage, bandwidth and support remains if a rack, host, switch, storage shelf, power feed or upstream route fails? Can the remaining pool carry normal customer load, or only keep priority customers online? Does the customer need to buy a second availability zone or a separate disaster-recovery product to receive that protection? Without that answer, "cloud base" remains a facility label, not a resilience guarantee.

Power, cooling and repair windows decide the outage

Data-centre pages often present power and cooling as engineering pride. Customers should read them as outage determinants. The Northwest University visit report says the Shaanxi base has T4-standard rooms, low PUE, high-density rack options and advanced cooling and security capabilities. Fenghuoyun's page describes backup power systems, colocation-style services, core switching and security certification claims. A 2018 Shaanxi Phoenix article says the base had large planned rack capacity and promoted network and power continuity service levels. These are positive public signals, but not a substitute for customer-specific service terms.

Power redundancy has several layers. Utility feeds may be diverse, but switchgear can still be common. UPS systems may be redundant, but battery duration can be short. Generators may be available, but fuel logistics, generator start reliability and maintenance state decide the real endurance. Rack PDUs may have A and B feeds, but a customer can accidentally plug both supplies into one side. A high-density liquid-cooled rack may be powerful, but it adds coolant and facility-support dependencies that do not exist for ordinary low-density servers.

Cooling redundancy also has layers. A low PUE is valuable, but it is not an uptime metric. It says something about efficiency and design. It does not say whether a given row has enough cooling headroom after a chiller, pump or air-handling unit fails. It does not say whether high-density liquid-cooled cabinets can keep running through maintenance. It does not tell the customer whether a temporary derating event will force workloads to move.

Repair windows are where the customer sees the truth. A rack fault may require remote hands. A server fault may require replacement parts. A routing fault may need an engineer authorized to change BGP. A storage fault may require vendor escalation. A hypervisor fault may require evacuation space. A backup fault may require someone to make a restore decision while the primary service is down. The size of China Telecom does not remove these steps; it gives the operator more resources to manage them if the process is prepared.

The customer should ask for the incident path in plain terms. Who opens the internal ticket? Who can enter the room? Which parts are stocked onsite? Which changes require a maintenance window? How are customers notified if planned maintenance affects a cloud edge, power feed, storage plane or IP route? Does the SLA exclude scheduled maintenance? Which services are credited and which are merely supported on best effort? Those details are less glamorous than a rack count, but they determine whether a failure becomes a short event or a long migration.

Hosted-domain signals need careful handling

IPinfo's hosted-domain counts make AS134768 look like a hosting network, and that is useful market evidence. It reports more than 23,000 hosted domains across the ASN, with concentrations on a small set of IPs. bgp.tools also labels the network type as content. Tianyi Cloud's public product estate includes elastic cloud hosts, application cloud hosts, physical-machine services, storage, backup, disaster recovery and other infrastructure offerings. Together, these signals support the central premise: the cloud-base network is part of a customer-facing hosted-capacity surface.

They do not prove the exact service behind any one hosted domain. A domain can point to shared hosting, a reseller platform, an application firewall, a reverse proxy, customer equipment in colocation, a legacy server, an internal government application, or a business customer using static IP service. IP address concentration is not the same as cloud account concentration. A large number of domains on 103.236.90.151, for example, may indicate shared hosting or a platform address, but APNIC RDAP for the underlying 103.236.88.0/22 allocation identifies XIAOTEYUN as the registered resource name.

That makes the operational chain more complicated than "China Telecom Shaanxi owns every site on the IP."

This distinction matters during a failure. If a customer is on a shared hosting IP, an abuse event by another tenant can affect reputation, mail deliverability or filtering. If a customer is on routed partner address space, the route-origin and abuse contacts may not map neatly to the contract. If a customer is on a virtual private cloud with an elastic IP, migration may require DNS changes and endpoint cutover. If a customer is on colocation with a customer-owned router, the provider may be responsible for power and cross-connects but not the customer's operating system or application.

The article therefore treats hosted-domain counts as an unofficial market signal, not a final capacity proof. They suggest AS134768 is used for customer-facing web and infrastructure traffic. They cannot establish who owns the servers, whether workloads are backed up, whether tenancy is isolated, whether there is a tested restore path, or whether the customer can export a VM image, database dump, mailbox archive or full cPanel-like account during stress.

The settling evidence would be product documentation tied to the actual service: address allocation, tenant isolation design, backup and snapshot scope, export formats, abuse handling, DDoS controls, reverse-DNS control, mail reputation policy and migration support. Without those details, hosted-domain scale is a reason to ask better questions, not a reason to relax.

Data locality is a selling point and a constraint

The region field for this profile is CN, and the public evidence supports a China-based operating surface. APNIC lists the AS in China. The Shaanxi cloud-base reports place the physical campus in the Xi'an/Xixian area. Tianyi Cloud's product pages and service documents are China-facing. This local presence can be valuable for Chinese public-sector, regulated and latency-sensitive workloads. It can also limit how a customer designs backups, support access and exit paths.

China's legal environment makes data placement more than a procurement preference. The Cybersecurity Law translation hosted by DigiChina describes a localization requirement for personal information and important data collected or produced by critical information infrastructure operators in mainland China. The Data Security Law establishes a national data-security framework. The Personal Information Protection Law, summarized by Hong Kong's PCPD and translated by sources such as China Law Translate, adds personal-information processing and cross-border-transfer obligations. The exact duties depend on the customer, data type and service arrangement, but the direction is clear: location, access and transfer rules matter.

For AS134768 customers, locality has three practical dimensions. The first is production locality: where the compute, storage and network endpoints actually sit. The second is backup locality: where snapshots, archives, disaster-recovery replicas and logs are stored. The third is administrative locality: who can access the systems, from where, under which legal entity and support process. A service may be locally hosted but use remote management, external security tools or cross-region backup. A service may advertise a Shaanxi cloud base but provide disaster recovery in another province. That may be good architecture, but it must be explicit.

Data locality also affects migration. If a customer needs to leave, can it export data to another China-based provider, another China Telecom region, an on-premises system or an overseas platform? Are there legal, technical or contractual limits on transferring logs, personal information, government data, encryption keys or backups? Does the provider support bulk export without throttling? How long after termination does the customer retain access? What happens if the account is suspended for billing while the customer still needs data retrieval?

The safest reading is that China-local infrastructure is a feature when the customer's compliance and latency needs match the platform, and a constraint when the customer needs cross-border redundancy or rapid exit. AS134768's route table cannot answer those questions. Only the service terms and data-processing arrangement can.

The service contract decides what the cloud does not cover

Cloud customers often confuse availability language with full operational responsibility. Tianyi Cloud's SLA index lists service-level agreements across compute, storage, backup and disaster-recovery products. Its ECS SLA page points users to the elastic cloud host service-level terms. Tianyi Cloud's product documents also distinguish availability zones, instance types, GPU services, cloud disks, backup products and disaster-recovery products. That structure tells customers something important: resilience is assembled from specific services, not automatically inherited from the parent brand.

In practice, a buyer should expect exclusions. Most cloud SLAs exclude scheduled maintenance, customer-side configuration failures, account and payment issues, force-majeure events, and failures outside the provider's defined service boundary. Some products have credits rather than restoration guarantees. Some high-performance or specialty instances may follow a different SLA. Some disaster-recovery products protect only the data or configuration selected by the customer. None of this is unusual. It is why reading the service-specific agreement matters.

For AS134768, the contract boundary should be tested against the main failure paths. If the upstream route fails, is that covered by network availability or excluded as backbone maintenance? If a rack loses power, does the customer receive service credit, restore support, or both? If a customer-managed VM is misconfigured after failover, where does provider responsibility end? If a DDoS mitigation action null-routes a customer IP, what is the escalation path? If a government-cloud workload has different security controls from commercial cloud, which support team acts?

Billing and account state deserve attention. Hosted capacity can fail administratively. An unpaid invoice, contract renewal delay, real-name verification issue, domain filing issue, abuse complaint or customer-identity mismatch can suspend service or block migration as effectively as a broken router. Customers buying critical capacity should ask whether a billing dispute can affect data export, how long data is retained after suspension, and who can authorize emergency access.

The best cloud contract makes the invisible dependencies visible. It states the service boundary, availability metric, maintenance notice, data retention, backup responsibility, export method, support severity, response target and customer obligations. If AS134768 is the route surface and Tianyi Cloud or a China Telecom Shaanxi unit is the service provider, the customer needs both the route facts and the contract facts in the same file.

Main failure paths to test

The first failure path is rack or facility failure. This includes rack power, row cooling, PDU errors, top-of-rack switches, cross-connects, fibre panels, physical access and maintenance mistakes. The public cloud-base reports suggest a substantial facility, but facility scale does not remove local failure. Customers need to know whether their service is single-rack, single-room, single-building, multi-zone or two-site.

The second path is upstream or backbone failure. Current public views show AS4134 as the visible upstream. The whois policy mentions AS4809, but the route collectors do not make it a proven customer failover path. Customers need the active upstream map, the failover test, the route filters, the RPKI state and the expected behaviour if AS4134 has a regional or national issue.

The third path is hardware-stock failure. A hosted platform can identify a failed server quickly and still wait on a replacement. High-density GPU, liquid-cooled or specialized compute adds more inventory risk. A customer should ask which parts are stocked locally, which require vendor dispatch, and whether the operator can live-migrate or restore to different hardware while parts are in transit.

The fourth path is support failure. The cloud-base network sits inside a large carrier organization, which can be a strength if escalation is mature. It can also create handoff risk among local operations, backbone operations, cloud operations, customer support, billing, security and partner teams. The customer should know which desk owns each incident type and which severity level triggers 24-hour escalation.

The fifth path is backup and restore failure. Backups that exist but are slow, incomplete or controlled by the wrong account do not solve an outage. Customers should demand restore evidence, not just backup product names. For a VM, that means booting a restored image. For a database, that means consistency and recovery-point evidence. For object storage, that means versioning, deletion protection and account separation. For colocation, it may mean the provider does not back up the customer's data at all.

The sixth path is migration failure. Customers often leave a platform during stress, when an application is unstable or the business has lost confidence. That is the worst time to discover that IP addresses cannot move, images cannot be exported, snapshots are proprietary, bandwidth is throttled, or support will not assist until invoices are settled. Migration should be rehearsed when the service is healthy.

These tests do not require distrust. They are ordinary due diligence for any hosted-capacity provider whose public network evidence is stronger than its public service-boundary evidence.

What would raise the evidence grade

AS134768 earns a Medium network evidence grade because it has strong public routing, official APNIC identity and plausible physical-cloud context. To reach Strong, the public or contract evidence would need to connect the route table to the customer service more directly.

The first improvement would be a current topology statement. It should name the active origin AS, upstream ASNs, product prefixes, region and availability-zone mapping. It should explain whether AS4809 is live for the service or only appears in route policy. It should identify whether customer workloads use China Telecom Shaanxi space, Tianyi Cloud shared space, customer PI space or partner address blocks. It should state who maintains ROAs and who responds to abuse or route-leak events.

The second improvement would be facility-boundary evidence. Customers do not need a public floor plan, but they do need to know whether their workload sits in the Xixian/Fengxi cloud base, another Shaanxi data centre, a Tianyi Cloud regional pool, a partner rack or a customer-owned cabinet. The statement should include power class, rack-density assumptions, maintenance-window policy, spare-parts plan and whether the service is single-zone or multi-zone.

The third improvement would be recovery evidence. A strong provider can show restore drills, not only backup products. It can describe recent VM restore, storage restore, database restore, network failover and customer export tests. It can say which failures are covered by automated failover and which require a manual ticket. It can also state realistic recovery-time and recovery-point objectives by product.

The fourth improvement would be data-locality and exit evidence. The provider should describe production location, backup location, log location, subcontractor access, encryption-key control, export formats, retention after termination and cross-border-transfer constraints. For government or regulated workloads, it should distinguish statutory compliance from commercial convenience.

The fifth improvement would be incident evidence. A status page, incident-history summary, maintenance calendar, support-severity matrix and post-incident report template would make the difference between a large route table and a dependable customer service. Large carriers sometimes keep this information behind customer portals, which is fine for customers under contract. Public absence still means an outside reader should not assume it.

If those items are produced, the story changes from "large live China Telecom Shaanxi routed surface with plausible cloud-base facility backing" to "verified hosted-capacity platform with known failure domains and recovery paths." That is the difference between network scale and infrastructure trust.

The conclusion: strong routes, conditional resilience

CHINANET SHAANXI province Cloud Base network is an active infrastructure subject. APNIC, RIPEstat, bgp.tools, Hurricane Electric and IPinfo all support the same core fact: AS134768 is a live China Telecom Shaanxi cloud-base network with a substantial IPv4 and IPv6 footprint. Representative route-origin checks are valid. Current visibility is high. The network is not a dormant shell.

The operating caution is equally clear. Public BGP shows reachability, not rack ownership. APNIC address records show resource holders and contacts, not customer workloads. Hosted-domain counts suggest web and hosting use, not backup quality. Cloud-base visit reports and partner pages point to a real Xi'an-area data-centre and cloud campus, but they do not tell a customer which product is single-zone, which is multi-zone, which path uses AS4809, which rack has spare power, or which support team restores a failed server at 2 a.m.

For a buyer, the practical stance is disciplined confidence. Treat the network as live. Treat the China Telecom Shaanxi cloud-base context as meaningful. Then ask for the evidence that actually decides outages: product prefix, availability zone, upstream path, ROA ownership, rack power, cooling headroom, spare hardware, backup scope, restore proof, support escalation, maintenance exclusions, billing-continuity rules and data-export terms.

Hosted capacity is not weightless. In Shaanxi, as elsewhere, it is routers, fibres, power rooms, cooling loops, switch ports, support queues and contracts. AS134768 makes that capacity visible to the internet. It does not remove the need to verify the physical and operational chain underneath it.