QCFNET Quantum Cloud New Media Technologies Co.Ltd sells hosted capacity that still depends on racks, transit and repair windows

Summary

• The strongest QCFNET evidence is registry and licence evidence, not current service evidence. APNIC RDAP records AS63587 as active under QCFNET, country CN, with the description Quantum Cloud New Media Technologies Co.Ltd and a Wuxi, Jiangsu address; APNIC RDAP also records 103.192.4.0/22 as allocated portable address space for the same name.
• The current routing evidence is weak. RIPEstat's AS overview, routing-status, announced-prefixes and routing-history views checked on 12 July 2026 report AS63587 as not announced, with no visible prefixes and no visible routing history in the RIS data set.
• The associated IPv4 block does not settle the customer-cloud question. RIPEstat's whois view for 103.192.4.0/22 reproduces the QCFNET allocation but also shows an APNIC IRR route for 103.192.4.0/23 originated by AS4837, China Unicom's CHINA169 Jiangsu network. RIPEstat's prefix overview shows the /22 itself as unannounced.
• The operating downgrade is explicit: QCFNET may still have licence history, leased racks, a local customer base or provider-hosted capacity, but public evidence does not prove a live independent cloud edge, multi-site capacity, backup independence, hardware stock, support escalation or customer migration paths. Buyers should require written proof before placing production workloads on the service.

The record identifies a company, but not a full operating cloud

QCFNET is not an empty name in a routing table. The official network registry still carries the identity. APNIC's RDAP record for AS63587 gives the autonomous-system name as QCFNET, describes the holder as Quantum Cloud New Media Technologies Co.Ltd, places it in China and records registration on 24 March 2016 with a last changed date of 16 June 2021. APNIC's RDAP record for 103.192.4.0/22 gives the same QCFNET name, the same Wuxi, Jiangsu address and an allocated-portable IPv4 block running from 103.192.4.0 through 103.192.7.255.

That is meaningful. An autonomous-system number and a portable allocation are not advertising copy. They are resources a network holder can use to present routes, coordinate address use and create a more portable infrastructure footprint than an ordinary retail hosting account. If QCFNET once operated a media-cloud or render-cloud service, these records are consistent with a company that sought the minimum number-resource base for such a service.

There is also a licence trail. The 51MIIT telecommunications-licence archive page for Wuxi Quantum Cloud Digital New Media Technology Co., Ltd. lists licence number Su B1.B2-20160474, company registration on 21 April 2014, registered capital of 10 million yuan, continuing status, the Wuxi National Digital Film Industrial Park address, internet information-service and internet-access service categories, and a business scope that includes internet data-centre service in the first category of value-added telecommunications business. It also lists the website domain lzycloud.cn and ICP record Su ICP Bei 17061852-1. Because this is a third-party archive rather than a direct live regulator result, it should be read as corroborating public record, not as a substitute for a current MIIT verification.

The MIIT ICP filing portal and the MIIT value-added telecommunications licensing portal are therefore part of the buyer's work. A licence archive helps find the record; it does not prove that the permission remains adequate for the exact service a customer is buying today. The buyer still has to confirm the legal name, licence status, permitted service class, permitted region, domain ownership and whether the contracted service sits inside the same legal entity.

The company-specific public record points toward a local Chinese new-media and infrastructure business, not toward a hyperscale cloud. The address is a film and digital-media park location in Wuxi. The licence scope mentions digital visual technology, network technology, computer and auxiliary equipment sales, e-commerce technical consulting and internet data-centre business. That mix fits a company that could support rendering, media operations, hosting, access or local cloud-like infrastructure for customers.

It does not by itself prove the present existence of data-centre halls, owned racks, active upstream sessions, customer virtual-machine inventory or 24-hour recovery staffing.

The distinction matters because a hosted-capacity customer buys operations, not merely incorporation. A registry record can stay alive after a network has stopped announcing. A domain can stay filed after the original service portal has faded. A licence can show that a company was allowed to provide certain services while leaving unanswered whether it still has the facility contracts, hardware inventory, route policy, support desk and customer base to deliver them. QCFNET must therefore be assessed in two layers: the identity layer is visible; the operating layer is not visible enough.

That is why this article uses a downgrade rather than a deletion of the company from consideration. The evidence does not say QCFNET cannot operate capacity. It says public evidence is limited public evidence to treat QCFNET as a verified, currently routed, independently resilient cloud provider. For non-critical experiments, that distinction may be acceptable. For production media rendering, customer websites, databases, archives or compliance-sensitive storage, it is not.

The network record is the weak part of the story

The most important public-network test is simple: does the autonomous system still appear to be carrying routes? RIPEstat's AS overview for AS63587 reported the holder as QCFNET - Quantum Cloud New Media Technologies Co.Ltd and marked the AS as not announced at the query time on 12 July 2026. RIPEstat's routing-status view showed zero IPv4 RIS peers and zero IPv6 RIS peers seeing AS63587, with no announced space and no observed neighbours. The announced-prefixes view returned an empty prefix list, and the routing-history view returned no origins in the visible RIS history.

That does not prove there is no private connectivity, reseller arrangement or customer traffic anywhere. Public BGP measurement has limits. It can miss private interconnects, domestic-only arrangements or prefixes carried under another operator's origin. But for a company whose directory card raises cloud, hosting, VPS, bare-metal or managed-service capacity, the absence of visible AS63587 routing is a material warning. A customer cannot rely on the company's own AS as a sign of current independent network operation unless the provider shows current route advertisements, upstream sessions and customer-specific placement.

The IPv4 allocation adds a second caution. The RIPEstat whois view for 103.192.4.0/22 reproduces the APNIC allocation to QCFNET, but the same view also shows an APNIC IRR route object for 103.192.4.0/23 with description "CHINAUNICOM CHINA169 Jiangsu Province Network" and origin AS4837. That route object was last modified in 2017. RIPEstat's prefix-overview view marked the /22 itself as not announced, with no related announced prefixes at the query time. Its routing-status view for 103.192.4.0/22 likewise showed no origins, no less-specifics and no more-specifics.

The safest interpretation is not that China Unicom is a QCFNET customer or that QCFNET is a China Unicom cloud. The APNIC route object only proves that a QCFNET address range had a route object through China Unicom's Jiangsu network for part of the block. It may represent upstream carriage, historical use, a delegated arrangement or a stale routing entry. What it cannot prove is an independently operating QCFNET edge. It also cannot prove that customers can move those addresses elsewhere if a facility, upstream or commercial relationship fails.

For cloud buyers, the difference between registry ownership and route control is practical. If QCFNET announces customer services through its own AS, the buyer can ask about upstream diversity, peering, RPKI, route objects, DDoS policy and failover at QCFNET's edge. If QCFNET relies on another carrier to originate the addresses, the buyer needs to know whose router policy controls reachability, who changes advertisements during an incident, who receives abuse reports, who can add a route, and whether addresses can be moved to another path.

If the address space is not currently visible, the buyer must ask whether the service is inactive, private, renumbered or operating under another provider's resources.

The stale-contact issue also belongs in this section. APNIC RDAP includes an abuse entity for CNNIC with remarks that the listed mailbox is invalid and that CNNIC is not empowered to investigate complaints for the network holder. The article does not need to reproduce personal contact details from the record. It is enough to say the public abuse path in the registry is not a reliable customer-support path. A buyer should ask for a current network operations contact, an incident escalation channel, a maintenance-notification process and a named person or role that can act during routing trouble.

This is the network downgrade. QCFNET has number resources. QCFNET does not, in public measurement checked here, show an active autonomous-system edge. That means public routing evidence cannot carry the same confidence as it would for a provider with visible prefixes, peers, routing history and current network-status data. Any claim about hosted capacity must therefore be tested at the provider-contract level.

The Wuxi footprint has to be converted into rack-level evidence

The Wuxi address is helpful because it places the company in a plausible digital-media cluster. A business located in a film and digital-media park could reasonably sell rendering, hosting, media asset processing, application hosting or managed infrastructure to local production and technology customers. The licence archive's business scope also names internet data-centre activity, which is closer to infrastructure than ordinary software consulting.

But a registered address is not a data-centre map. It does not say whether QCFNET owns racks, leases racks, uses a carrier hotel, resells another provider's cloud, operates in a campus data room, or only retains historical rights connected to an older product. It does not identify power feeds, cooling capacity, fire controls, cross-connect availability, security access, remote-hands coverage, spare hardware or the operator that ultimately controls the building systems.

This distinction is often missed with smaller cloud suppliers. A cloud brand can sit on top of several physical arrangements. One model is owned servers in a leased cabinet inside a carrier-neutral or carrier-operated data centre. Another is dedicated hardware leased from a larger provider. Another is a reseller account where the smaller company sells managed service, billing, application support or local-language operations while a larger carrier supplies compute and network. Another is an old licence and domain attached to a service that is no longer actively sold. Each model has a different failure path.

If QCFNET is selling customer-facing cloud, hosting, VPS, bare-metal or managed-service capacity, the first due-diligence request should be a location schedule. It should state where production workloads run, which entity operates the facility, whether the customer can choose a locality, whether there is a second site, whether the second site is active or only available after an order, and whether backups, logs and management systems use the same facility. A buyer should not accept "Wuxi" or "Jiangsu" as a substitute for rack, hall and carrier-boundary evidence.

Power evidence has the same shape. The customer needs to know whether the equipment uses dual power supplies, whether both cords land on independent rack power distribution, whether the rack has redundant upstream feeds, whether there is generator capacity, how maintenance windows are handled and whether power events have been tested. A cloud console may hide these details, but a local provider's real recovery time is still shaped by them.

Cooling and hardware density matter if the service involves rendering or media workloads. Render farms and GPU or CPU-heavy systems have different heat and power profiles from ordinary web hosting. A provider can have enough nominal rack space while lacking usable high-density headroom during summer cooling stress or maintenance. The buyer should ask about installed capacity versus usable capacity: how much compute is physically installed, how much is reserved for failure, how much is already committed, and how much spare headroom exists at the recovery site.

The route boundary has to be attached to the same map. If the active network path is China Unicom, the customer needs to know whether QCFNET controls routing policy or requests changes through the carrier. If the customer receives provider IP addresses, the customer needs to know whether those addresses are in 103.192.4.0/22, another QCFNET block, a carrier block or a cloud-provider block. If the customer brings its own address space, it needs written confirmation that QCFNET can originate it, maintain route objects and support withdrawal during migration.

Without this rack-level evidence, QCFNET remains a registered infrastructure-capable entity rather than a verified current cloud facility. That may sound severe, but it is the right standard for hosting economics. Buyers do not get resilience from a company name; they get it from physical separation, power reserve, route control, working backups and people who can act when something breaks.

Hosted capacity is an economic promise, not magic elasticity

The assignment question is about hosted capacity that still depends on racks, transit and repair windows. QCFNET is a clean example because the public record supplies the frame but not the proof. The company has network resources and a licence trail consistent with cloud or data-centre activity. Public measurement does not prove current operation. The buyer's job is to turn that gap into a contract and test plan.

The first economic question is capacity reserve. A provider can sell CPU, storage and bandwidth at attractive prices by keeping utilisation high. That is normal. It becomes risky when customers assume there is unused capacity waiting for failover. A virtual machine may fit during ordinary operation, but a rack failure, upstream failure, storage shelf failure or maintenance window requires spare capacity somewhere else. Spare capacity costs money before it is used. If the customer did not buy it, it may not exist.

The second question is hardware stock. Bare-metal or render-oriented services depend on exact parts: drives, power supplies, NICs, optics, controller cards, GPU boards, RAM modules and compatible server chassis. A failed disk is simple if the provider has the right disk in stock and an engineer on site. A failed controller, switch line card or GPU node is not simple if replacement parts must be ordered, shipped, cleared or scheduled through another party. The public QCFNET record says nothing about spare inventory.

Customers should ask for the hardware-replacement policy and whether the provider holds local spares for the contracted service class.

The third question is transit reserve. A route object through China Unicom, if it reflects real service dependency, may be entirely reasonable for a Jiangsu-focused provider. China Unicom's network is large and important. But a single upstream arrangement is not the same as transit diversity. If QCFNET claims multi-carrier connectivity, the buyer should ask for the active upstream list, physical handoff locations, route policy, traffic-engineering rules, failover test evidence and incident notices from recent maintenance. If the provider cannot supply those facts, the buyer should assume the network dependency is concentrated.

The fourth question is support labour. Small infrastructure providers can be very capable when the right engineer is available and very slow when the same engineer is off shift, busy with another incident or dependent on a carrier ticket. The buyer should ask who watches alerts, who can enter the facility, who can reboot or replace hardware, who can modify route policy, who can unlock the customer account, and who can approve emergency migration. A phone number is not an escalation model.

The fifth question is billing and administrative continuity. Some cloud outages are not power outages. They are unpaid invoices, expired domains, blocked accounts, missing renewal authority, failed compliance checks, suspended reseller relationships or disputes over who owns the data. If QCFNET is an intermediary over another facility or carrier, the buyer needs protection against upstream commercial failure. The contract should state what happens if the provider's own upstream account, lease, licence or payment channel fails.

This is why the economics topic is not separate from engineering. A low-price hosting arrangement can be fine for staging workloads, burst rendering or non-critical media processing. It is risky for production archives, regulated records, customer identity systems or public services unless the buyer pays for the evidence and reserves that resilience requires. QCFNET's thin current public footprint means the buyer cannot infer those reserves from reputation alone.

The support boundary is where customers lose time

When a hosted service fails, the first hour is often spent discovering who has authority. Is the failure inside the customer's application, QCFNET's virtualisation layer, a storage array, a cabinet, a carrier link, a DNS zone, a domain filing, a licensing server, or a facility system? The public QCFNET record does not answer that question. That absence is not unusual for a small provider, but it is a risk that must be priced.

The APNIC and RIPEstat records can help frame the boundary. APNIC identifies QCFNET as the holder of AS63587 and the 103.192.4.0/22 allocation. RIPEstat shows no current AS63587 visibility. The APNIC IRR route object for 103.192.4.0/23 points to China Unicom's AS4837. That combination means a customer should ask a very practical support question: if traffic stops, who can tell whether the problem is QCFNET, China Unicom, another upstream, a facility switch, a firewall, a stale route object, a BGP filter, a DDoS policy or the customer's own DNS?

The answer should not be a sales sentence. It should be a runbook. For a routing incident, the runbook should name monitoring sources, NOC contacts, upstream ticket channels, route-object owners, RPKI state if used, emergency withdrawal steps and the customer notification process. For a rack incident, it should name on-site access rights, remote-hands scope, spare-part location, vendor support status and expected replacement times. For a storage incident, it should name snapshot frequency, backup separation, restore authority and whether the customer can retrieve a copy without the failed portal.

For a billing incident, it should name who can prevent suspension while a disputed invoice or compliance review is resolved.

The public abuse-contact weakness reinforces the need for private escalation evidence. APNIC's RDAP abuse entity is not a customer-support desk, and its remarks indicate the public mailbox should not be treated as a working operator abuse path. That is tolerable if the provider has a clear commercial support channel. It is dangerous if the only public network contacts are stale registry fields and a historical domain.

Customers also need to know whether QCFNET is the legal service operator or an integration layer over another provider. If QCFNET sells managed cloud built on leased infrastructure, the customer may only have contractual rights against QCFNET while the physical operator controls hands, power and cross-connects. If QCFNET sells access over China Unicom, the customer may not be able to call China Unicom directly. If QCFNET uses another hosting platform, the customer may not own the account credentials needed to export disks or snapshots. These boundaries are normal, but they must be explicit.

The affected parties can be wider than the buyer's infrastructure team. A media-production customer can miss delivery windows if render jobs cannot start. A public website can lose orders. A database customer can lose access to regulated records. A school, studio, agency or software firm can find that its downstream customers blame it for a failure whose root cause sits in another provider's rack. This is why the contract should map business impact to technical escalation rather than treating all outages as generic tickets.

For QCFNET, the support verdict is conditional. The company may have local staff, known customers and useful relationships. Public evidence does not show that. Until it does, customers should assume slower escalation and require a named operational path before placing critical services there.

Locality helps only if the data boundary is explicit

QCFNET's region is China, and locality may be its real commercial value. A Wuxi-based infrastructure company with an internet data-centre licence trail could be useful for customers that need domestic hosting, Chinese-language support, local procurement, Jiangsu connectivity or alignment with Chinese filing and data-location requirements. For media, rendering and digital-visual workloads, local infrastructure can reduce latency, simplify data movement and keep production material close to the team that uses it.

But locality is not the same as sovereignty proof. A buyer needs to know where production data sits, where backups sit, where logs sit, where administrator access originates, where monitoring data is stored and which entities can access each layer. If QCFNET uses a carrier facility, a third-party cloud or an integration partner, the customer needs to know whether data leaves the named region, whether support personnel from another entity can access systems and whether backups are stored under the same legal and technical controls as production.

Data locality is also a recovery tradeoff. Keeping all production and backup copies in one Wuxi or Jiangsu environment may simplify compliance and latency, but it can concentrate risk. A second domestic site can improve resilience, but only if it has independent power, route, storage and support. A cross-region or foreign backup can improve escape options, but it may trigger data-export, privacy, contractual or customer-notice questions. The buyer has to choose the right failure boundary for the data, not merely the nearest location.

General cloud guidance makes this point in different words. NIST's cloud synopsis and recommendations treats service agreements, data transfer, reliability, security and portability as connected cloud-buying questions. Microsoft's reliability and sovereignty guidance explains that redundancy choices interact with jurisdiction, key placement and operator access. The same logic applies to a smaller Chinese provider: a locality claim is useful only when the customer can see the legal entity, the facility boundary, the backup boundary and the operator-access boundary.

For QCFNET, the public evidence supports a China-local record but not a complete data-locality architecture. APNIC and the licence archive place the company in China. They do not show the present facility, storage replication design, backup location, encryption-key custody or access-control model. That means customers should request a data-location schedule and attach it to the contract. The schedule should cover primary storage, replicas, snapshots, long-term backups, logs, monitoring, support exports and deletion procedures.

The same schedule should cover portability. Data sovereignty can trap a customer if it is used only as a reason not to move data. A resilient domestic hosting design should still let the customer retrieve its own records, application images, databases, logs and keys in a format it can restore elsewhere. If QCFNET cannot prove portable export, then locality becomes a dependency rather than a protection.

Backup and disaster recovery need a restore outside the failed path

The public QCFNET record does not show backup products, recovery tiers or restore tests. That means the buyer has to build the recovery requirement from first principles. NIST's contingency planning guide treats business-impact analysis, recovery strategies, testing and plan maintenance as core controls. NIST's storage security guidance distinguishes backups, snapshots, replication, archive and restoration assurance. Those distinctions matter for a provider whose current public service surface is not clear.

The first test is whether backup copies are independent of the failure being tested. A snapshot on the same storage system can help after accidental deletion but may not help after a storage-array failure. A backup in the same rack can help after file corruption but may not help after power or cooling trouble. A copy inside the same provider account can help after an application mistake but may not help if the account is suspended, the portal is unavailable or the provider relationship is in dispute. A backup is only a continuity control after it has survived the failure path that took production down.

The second test is whether the customer can restore without heroic provider action. AWS's disaster-recovery guidance describes different recovery patterns from backup-and-restore through warm standby and active-active designs. Google Cloud's DR planning guide asks teams to consider bandwidth, facilities, support, power, network infrastructure and end-to-end testing. Those frameworks are not evidence that QCFNET uses AWS or Google. They are useful because they force the right questions: how much capacity is reserved, who performs the restore, how traffic moves, what dependencies are shared and how often the test is repeated.

For a QCFNET customer, a proper restore report should name the workload, the backup source, the recovery location, the data-loss point, the elapsed restoration time, the network changes made, the people involved, the applications tested and the business owner who accepted the result. If the workload is a render queue, the report should show whether input assets, render nodes, output storage and licences all returned. If the workload is a web application, it should show whether DNS, certificates, database state, file storage and background jobs returned.

If the workload is an archive, it should show whether older versions and metadata were preserved.

Recovery should also be tested outside QCFNET's normal path. If the provider's own AS is not visible and the address block is not clearly announced by QCFNET, the customer should not rely on provider-controlled routing as the only recovery route. The buyer should keep independent DNS control, current configuration exports, database dumps, VM images where available, encryption keys, licence records and a tested destination outside the QCFNET account. This is not a hostile stance. It is normal operational hygiene when public evidence of provider resilience is thin.

Migration is the last recovery control. A hosted-capacity contract should state how the customer can leave: data formats, export bandwidth, lead time, fees, deletion certificates, retained backups, IP address ownership, domain control, SSL certificates, logs, managed database dumps and application configuration. If the customer uses provider-managed systems, it should know which pieces can be exported and which must be rebuilt. If the customer uses QCFNET for local compliance, it should also know the compliant destination before an incident begins.

The most dangerous design is production and recovery inside the same opaque provider boundary. If primary servers, backups, monitoring, DNS, support, billing and data export all depend on one portal or one small support team, the buyer has bought convenience, not redundancy. QCFNET may be able to support a better design, but public evidence does not prove it. The buyer has to ask, test and document.

What would change the verdict

QCFNET's public evidence grade could improve quickly if the company or a customer supplied current operating proof. The first proof would be live routing: current BGP advertisements for AS63587, a list of originated prefixes, route objects that match actual announcements, upstream and peering relationships, RPKI status where used, and a NOC process for route changes. If QCFNET intentionally operates through another AS, the provider should explain whose AS originates customer traffic and what rights QCFNET and the customer have during an incident.

The second proof would be facility evidence. A credible response would identify the data centre or centres used, the operator boundary, the rack or cage arrangement, power feed design, cooling limits, fire and access controls, carrier handoffs, remote-hands process and maintenance policy. It would separate owned infrastructure from leased infrastructure and reseller services. It would also show which legal entity signs the customer contract and which entity controls the physical environment.

The third proof would be capacity and restore evidence. A provider can claim cloud, VPS, bare metal or managed service, but resilience starts with spare capacity, backup independence and tested recovery. QCFNET could improve confidence with recent restore-test summaries, customer-selectable backup locations, documented RPO and RTO options, hardware-stock policy, support severity tables, migration procedures and export formats. The strongest proof would be a customer-specific test, not a general brochure.

The fourth proof would be current service surface. A working official product site, current service terms, status page, support channel, domain filing verification, pricing or service descriptions would not prove resilience by themselves, but they would show that the company is still presenting services to customers. The archived lzycloud.cn filing is not enough. A buyer should ask for present service documentation and compare it with the licence and network records.

The fifth proof would be customer-level dependency disclosure. If QCFNET is now primarily a managed-service wrapper, the customer should know the underlying facility, carrier and platform. If it operates only selected private projects rather than a public cloud storefront, the customer should know the access model, support window and reason public routing is absent. If the historical address space is dormant while newer capacity sits under another provider's addresses, the customer should know whether that design was chosen for simplicity, cost, compliance or because QCFNET no longer controls an edge network.

Each explanation can be legitimate. None should be left implicit when the workload matters.

Until those proofs exist, QCFNET belongs in a due-diligence bucket rather than a production-approved bucket. It may be a valid local provider for low-risk use cases, historical workloads or a tightly managed relationship where the customer has private evidence. It should not be treated as a verified resilient cloud just because APNIC and a licence archive still contain the name.

The verdict: real registry identity, weak current operating evidence

QCFNET Quantum Cloud New Media Technologies Co.Ltd has enough public evidence to justify an infrastructure-company article, but not enough to justify operational confidence. The company is visible in APNIC as AS63587 and as holder of 103.192.4.0/22. A telecommunications-licence archive links the Chinese company name to internet information-service, internet-access and internet data-centre scope, a Wuxi address, a historical domain and corporate registration details. Those facts make QCFNET a real directory subject.

The current network evidence is the limiting factor. RIPEstat marks AS63587 as not announced, shows no AS63587 prefixes, no visible AS63587 routing status and no visible routing history. The QCFNET IPv4 allocation is visible as a registry entity, but public measurement does not show the /22 announced, and the APNIC IRR route for part of the block points to China Unicom AS4837 rather than QCFNET. That is not a fatal fact for every business model, but it is a direct challenge to any claim of independently controlled cloud connectivity.

The practical buyer answer is strict but fair. Use QCFNET only after the provider proves the physical and operational boundary: where the workload runs, who controls the racks, how power and cooling are protected, which AS originates traffic, which upstreams are active, how backups are separated, who can repair hardware, who can act after hours, what happens if the carrier path fails, and how the customer exits with its data. Without those answers, the advertised or implied cloud capacity remains a hypothesis.

QCFNET's safest current grade is therefore weak operating evidence with a sharper network warning. The company may still support hosted services, but public records checked here do not prove live independent routing, customer-facing capacity, multi-site resilience, backup recovery or migration rights. The buyer should buy evidence before buying uptime.