If you have ever used an overseas VPS with a standard network connection, you have likely experienced this scenario: everything runs smoothly during the day—webpages load instantly, SSH connections are fluid, and file transfers are stable. However, after 8 PM, latency creeps up from 150ms to over 300ms, packet loss spikes from 0% to double digits, webpages hang while loading, and SSH commands take several seconds to register.
This isn't due to insufficient server specs, nor is the provider secretly throttling your speed at night. The problem lies in the "path" your data packets take.
Traffic for standard-connection VPS instances travels via public backbone networks like 163 or 4837. These routes carry massive volumes of consumer broadband traffic and become completely jammed during evening peak hours. Your data packets are forced to queue alongside the traffic of countless users streaming videos and browsing the web, inevitably leading to skyrocketing latency and packet loss.
"Triple-network optimized" VPS plans aim to solve this by ensuring data packets avoid that congested route. But how exactly do they achieve this? Is it truly effective, or just marketing hype?
The Root of the Issue: Three Carriers, Three Independent Paths
To understand triple-network optimization, one must first grasp a fundamental fact about the internet in mainland China: China Telecom, China Unicom, and China Mobile each operate their own independent backbone networks and international gateways, with no centralized control linking them.
Data packets originate from the respective networks of the user's carrier—Telecom, Unicom, or Mobile. Each carrier has limited international gateway bandwidth; when the surge of consumer broadband traffic hits these gateways during evening peak hours, congestion occurs.
An even more troublesome issue is "cross-network" traffic. If an overseas server is optimized only for China Telecom's network (e.g., connected solely via CN2 GIA), data packets from China Unicom users must "cross over" from Unicom's network to Telecom's. Because the bandwidth at the interconnection points between these networks is limited, the connection might actually be slower than using Unicom's own standard routes.
This creates an awkward situation: for the very same server, China Telecom users report high speeds, China Unicom users report slowness, and China Mobile users find it too laggy to use. The server isn't broken; rather, users from the three carriers are traveling along paths of vastly different quality.
The workflow of "Three-Network Optimization": Moving from "each taking their own path" to "each taking their own *fast* path."
The core concept of three-network optimization is not to funnel all traffic onto a single "best" route, but to ensure that users of each carrier travel along the "fast path" specific to their own provider.
Step 1: BGP Multi-Homing
To implement three-network optimization, a data center must first ensure connectivity with all three carriers at the network level. Specifically, the data center requests BGP peering with China Telecom, China Unicom, and China Mobile, broadcasting its IP address blocks to all three carriers via the BGP protocol.
The significance of this broadcast is that each carrier's routers perceive a valid path to these IP blocks: a China Telecom router sees a path pointing to its own optimized line; a China Unicom router sees a path pointing to its own optimized line; and the same applies to China Mobile.
For the same server and the same IP address, each of the three carriers independently determines that "the best path to reach it is via our own network." Users do not need to manually select a "Telecom entry point" or a "Unicom entry point"; their routers automatically route data packets to their own carrier's network.
Step 2: Matching with Premium Routes
While BGP multi-homing solves the issue of "entry point selection," mere connectivity is not enough. The key to "three-network optimization" lies in ensuring that the path taken by each carrier is a premium route rather than a standard one.
For China Telecom, traffic travels via CN2 GIA (AS4809). This is Telecom's highest-tier international carrier network; both provincial and international egress points utilize dedicated CN2 lines, bypassing the congested nodes of the standard 163 backbone network.
For China Unicom, traffic travels via AS9929 (CUII). This is Unicom's premium international route, characterized by low load and minimal packet loss, maintaining relatively stable transmission quality even during evening peak hours.
For China Mobile, traffic travels via CMIN2 (AS58807). This is Mobile's premium international network; it features an independent international backbone, avoiding the congestion associated with the AS9808 path used by standard mobile subscribers. Real-world testing shows that CMIN2 latency is 40 to 70 milliseconds lower than that of standard Mobile international routes.
Users from the three carriers utilize three distinct premium routes, operating independently without mutual interference. This is the core logic behind "three-network optimization."
Step 3: Intelligent Routing and Failover
Even premium routes are not immune to issues. A specific route might experience localized congestion due to traffic spikes or temporary instability caused by carrier adjustments.
The "intelligence" of the optimization facility lies in its ability to continuously monitor the real-time quality of each route; if a route's performance degrades, traffic is automatically rerouted to a better-performing path.
This routing management is implemented using SD-WAN or BGP attribute manipulation. A routing controller at the facility collects real-time data on latency and packet loss for each route. When a route's metrics exceed defined thresholds, the system adjusts BGP local preference or community attributes to steer subsequent traffic away from that route.
Users remain completely unaware of this process. He simply noticed that performance was "decent during the evening rush hour," unaware that the system had quietly switched routing paths in the background.
Does it really work? Real-world performance based on test data
Now that the underlying mechanism has been explained, what about the actual performance?
Test data regarding direct connectivity to major carriers (China Telecom, Unicom, and Mobile) for a Hong Kong VPS provides a valuable point of comparison. The test compared two configurations—"standard multi-line BGP" and "optimized BGP with direct carrier connectivity"—based on data collected over seven consecutive days:
Metrics | Standard Multi-Line BGP | Optimized Direct Carrier Connectivity
| index | Standard Multi-line BGP | Optimization for Networks |
|---|---|---|
| Average latency | 60-90ms | 30-55ms |
| P90 Latency | 120ms | 75ms |
| P99 Latency | 200ms+ | 90ms |
| Packet loss rate during peak periods | Reaching 3% | <0.5% |
Reducing P99 latency from over 200ms to under 90ms represents a substantial improvement. P99 represents "worst-case latency"—on standard lines, 1% of requests exceed 200ms, which users perceive as "occasional lag"; with "three-network optimization" (optimized routing for China's three major carriers), the worst-case latency is kept under 90ms, effectively eliminating that "occasional stutter."
Another test conducted on US West (Los Angeles) VPS instances with three-network optimization showed that during evening peak hours (20:00–23:00), across 100 consecutive ping tests, the packet loss rate for China Unicom lines was kept around 1%, while rates for China Telecom and China Mobile remained stable at under 3%. For a US West server communicating across the Pacific, this level of stability approaches the physical limit.
The Limits of Three-Network Optimization: What It Cannot Do
While three-network optimization significantly improves the user experience during evening peak hours, it is not a cure-all.
It optimizes the path *to* mainland China. If your user base is primarily located in Europe, the Americas, or Southeast Asia, the value of three-network optimization is limited. When these users access your server, they utilize international routing paths that are unaffected by "three-network optimization."
It cannot overcome the constraints of physical distance. The physical lower limit for latency between a US West server and locations in China is roughly 130–160ms. Three-network optimization aims to bring actual latency *close* to this physical limit, not to push it *below* that limit.
Its costs are far higher than those of standard lines. The bandwidth procurement costs for premium routes like CN2 GIA, AS9929, and CMIN2 are several times higher than those for standard 163 or 4837 lines. The price premium for these VPS instances is essentially the cost of paying for "reliability during evening peak hours."
A "three-network optimization" label does not guarantee actual performance. There are many VPS offerings on the market labeled as having "three-network optimization" that actually only optimize the return path or suffer from severe oversubscription of premium line resources. You can verify the legitimacy of these claims by testing the return routing: check whether China Telecom's return path uses the 59.43 node, China Unicom uses AS9929, and China Mobile uses AS58807.
EN
CN