What are China-optimized routes? CTGNet/CN2 GIA, CUP, and CMIN2 explained
Many VPS providers use “China optimized” to mean any route that reaches mainland China reasonably well. For Tokyo, that is too vague.
A China Telecom home connection, a China Unicom office line, and a China Mobile phone can take different international paths to the same VPS. A route that looks fine for one carrier may be the wrong path for another.
In the mainland China VPS market, “three-network optimization” means treating the three major carrier networks separately:
- China Telecom
- China Unicom
- China Mobile
Riven Cloud’s optimized Tokyo routing is built around that model. China Telecom traffic uses the CN2/AS4809 domestic premium path and reaches Riven Cloud through CTGNet/AS23764. China Unicom traffic uses AS9929 on the mainland China side and reaches Riven Cloud through China Unicom Global AS10099. China Mobile traffic uses AS9808 domestically and reaches Riven Cloud through CMIN2/AS58807.
Lower latency is part of the story, but carrier matching matters just as much. A good China route should avoid pushing all three carriers through the same ordinary transit path and hoping the result holds during peak hours.
The comparison data below comes from cleaned MTR samples collected on June 29, 2026. Exact customer endpoints, VPS addresses, router IPs, private IPs, and hostnames have been redacted. The article keeps the parts that matter for route analysis: carrier labels, ASNs, direction, final-hop average RTT, final-hop packet loss, and visible AS-level paths.
What are the three networks in China?
China Telecom, China Unicom, and China Mobile are the three carrier networks most VPS buyers care about when serving users in mainland China.
That matters because a “China route” is not a single path. A user in Shanghai on China Telecom, a developer in Beijing on China Unicom, and a phone on China Mobile can take very different routes to the same VPS in Tokyo. A path that works well for one carrier may be ordinary, indirect, or congested for another.
A China-optimized route needs to be carrier-specific. One decent international transit provider is not the same thing as three-network optimization.
Why ordinary international transit is not enough
Standard global transit can be good for general international traffic. For users in North America, Europe, Japan, Singapore, and many other markets, a well-connected transit blend may be perfectly reasonable.
Mainland China traffic is different. The route depends heavily on carrier-specific international gateways, domestic backbone policy, handoff points, and the relationship between the overseas network and each Chinese carrier.
Ordinary transit may enter China through a less ideal carrier path. It may take a detour through another region. It may work acceptably at one time of day and become inconsistent during evening peak. It may also be asymmetric: the route from China to Tokyo can look different from the route from Tokyo back to China.
Bandwidth is only one part of network quality. For many applications, latency, packet loss, jitter, and route consistency matter more than a large port number on a plan page. A 1 Gbps port does not help much if packets reach the wrong international gateway or bounce through a congested carrier path.
China Telecom: CTGNet and CN2 GIA
China Telecom is the easiest one to mislabel.
CTGNet is China Telecom’s newer premium international network, associated with AS23764. CN2, commonly discussed in the VPS market as CN2 GIA, is tied to the premium China Telecom backbone segment associated with AS4809. These are related in the customer experience, but they are not the same phrase with two names.
Riven Cloud’s path should not be described as “CTGNet equals CN2 GIA.” The domestic premium segment and the international delivery path are different parts of the route. In this setup, China Telecom traffic uses the CN2/AS4809 domestic premium segment and reaches Riven Cloud through CTGNet/AS23764.
Riven Cloud peers with China Telecom through CTGNet AS23764. On the mainland China side, traffic can traverse the CN2/59.43 segment associated with AS4809 before it reaches the CTGNet AS23764 edge and then Riven Cloud’s Tokyo network.
As of June 29, 2026, PeeringDB lists CTGNet as AS23764. That public record matches the peer-facing ASN discussed here.
In our sample MTR tests, the optimized China Telecom route showed an average final-hop RTT of 36.3 ms from a China Telecom access sample to the Riven Cloud Tokyo optimized test node, with 36.1 ms best RTT and 0.0% final-hop packet loss. In the reverse direction, from Tokyo back to the China Telecom access sample, the optimized route showed 41.6 ms average final-hop RTT, 41.6 ms best RTT, and 0.0% final-hop packet loss.
The ordinary SoftBank transit baseline for the same carrier sample used AS4134 -> SoftBank AS17676 -> Riven Cloud AS3258 in the China-to-Tokyo direction, and Riven Cloud AS3258 -> SoftBank AS17676 -> AS4134 in the return direction. The final hop averaged 78.1 ms with 30.0% packet loss from China to Tokyo, and 74.1 ms with 10.0% packet loss from Tokyo back to China.
| Measurement | Ordinary SoftBank transit | CTGNet/CN2 optimized route |
|---|---|---|
| China to Tokyo AS path | AS4134 -> SoftBank AS17676 -> Riven Cloud AS3258 | AS4134 access -> CN2/AS4809 -> CTGNet/AS23764 -> Riven Cloud AS3258 |
| China to Tokyo final hop | 78.1 ms avg / 69.6 ms best / 30.0% loss | 36.3 ms avg / 36.1 ms best / 0.0% loss |
| Tokyo to China AS path | Riven Cloud AS3258 -> SoftBank AS17676 -> AS4134 | Riven Cloud AS3258 -> CTGNet/AS23764 -> CN2/AS4809 -> AS4134 |
| Tokyo to China final hop | 74.1 ms avg / 63.1 ms best / 10.0% loss | 41.6 ms avg / 41.6 ms best / 0.0% loss |
| Result in this sample | Standard transit was 41.8 ms slower China to Tokyo and 32.5 ms slower Tokyo to China | The optimized path was about 54% lower RTT China to Tokyo and 44% lower RTT Tokyo to China |
This does not mean every China Telecom user will always see those exact numbers. It does show the route difference clearly: CN2/AS4809 and CTGNet/AS23764 on the optimized path, compared with ordinary SoftBank transit on the baseline path.
For the carrier-specific breakdown, read What is CTGNet / CN2 GIA? China Telecom premium routing explained.
China Unicom: CUP and China Unicom Premium
CUP means China Unicom Premium.
For Riven Cloud’s optimized China Unicom path, the mainland China side uses AS9929 as the premium backbone and international exit segment. Riven Cloud peers with China Unicom Global through AS10099. AS4837 may still appear before traffic enters AS9929, because AS4837 is commonly seen as an ordinary China Unicom regional or access network.
The accurate shorthand is:
China Unicom traffic uses AS9929 on the mainland China side and reaches Riven Cloud through China Unicom Global AS10099.
As of June 29, 2026, PeeringDB lists China Unicom Global as AS10099. In the optimized sample, the visible AS path from mainland China to Tokyo was AS4837 -> AS9929 -> AS10099 -> Riven Cloud AS3258. The return direction showed Riven Cloud AS3258 -> AS10099 -> AS9929 -> AS4837.
The useful part is where AS9929 appears. AS4837 may still show up near the access side, but the cross-border segment moves onto the premium Unicom path through AS9929 and AS10099.
In our sample, the optimized China Unicom route averaged 37.4 ms from China to Tokyo, with 37.1 ms best RTT and 0.0% final-hop packet loss. The return direction averaged 36.6 ms, with 36.6 ms best RTT and 0.0% final-hop packet loss.
The ordinary SoftBank transit baseline used AS4837 -> SoftBank AS17676 -> Riven Cloud AS3258 from China to Tokyo, and Riven Cloud AS3258 -> SoftBank AS17676 -> AS4837 in the return direction. It averaged 53.1 ms from China to Tokyo and 57.0 ms from Tokyo back to China, both with 0.0% final-hop packet loss.
| Measurement | Ordinary SoftBank transit | CUP/AS9929 optimized route |
|---|---|---|
| China to Tokyo AS path | AS4837 -> SoftBank AS17676 -> Riven Cloud AS3258 | AS4837 -> AS9929 -> China Unicom Global AS10099 -> Riven Cloud AS3258 |
| China to Tokyo final hop | 53.1 ms avg / 41.1 ms best / 0.0% loss | 37.4 ms avg / 37.1 ms best / 0.0% loss |
| Tokyo to China AS path | Riven Cloud AS3258 -> SoftBank AS17676 -> AS4837 | Riven Cloud AS3258 -> China Unicom Global AS10099 -> AS9929 -> AS4837 |
| Tokyo to China final hop | 57.0 ms avg / 47.8 ms best / 0.0% loss | 36.6 ms avg / 36.6 ms best / 0.0% loss |
| Result in this sample | Standard transit was 15.7 ms slower China to Tokyo and 20.4 ms slower Tokyo to China | The optimized path was about 30% lower RTT China to Tokyo and 36% lower RTT Tokyo to China |
For the carrier-specific breakdown, read What is China Unicom Premium? CUP, AS9929, and AS10099 explained.
China Mobile: CMIN2
CMIN2 means China Mobile International N2. It is the important path to look for when evaluating optimized China Mobile routing.
Riven Cloud peers with CMIN2 through AS58807. Mainland China traffic uses AS9808 domestically before reaching AS58807. In contrast, ordinary China Mobile international routes may use older CMI paths such as AS58453, often with additional transit such as SoftBank AS17676 in the baseline route.
The accurate shorthand is:
China Mobile traffic uses AS9808 domestically and reaches Riven Cloud through CMIN2/AS58807.
As of June 29, 2026, PeeringDB lists China Mobile International - NII as AS58807, with CMIN2 as its listed aka.
In our optimized sample, the visible AS path from mainland China to Tokyo was China Mobile regional/access network -> AS9808 -> CMIN2 AS58807 -> Riven Cloud AS3258. The return direction showed Riven Cloud AS3258 -> CMIN2 AS58807 -> AS9808 -> China Mobile regional/access network.
The optimized route averaged 40.0 ms from China to Tokyo, with 39.8 ms best RTT and 0.0% final-hop packet loss. The return direction averaged 44.7 ms, with 44.6 ms best RTT and 0.0% final-hop packet loss.
The ordinary SoftBank transit baseline used China Mobile regional/access network -> AS9808 -> ordinary CMI AS58453 -> SoftBank AS17676 -> Riven Cloud AS3258 from China to Tokyo, and the same general chain in reverse from Tokyo back to China. It averaged 72.2 ms from China to Tokyo and 70.0 ms from Tokyo back to China, both with 0.0% final-hop packet loss.
| Measurement | Ordinary SoftBank transit | CMIN2 optimized route |
|---|---|---|
| China to Tokyo AS path | China Mobile regional/access -> AS9808 -> ordinary CMI AS58453 -> SoftBank AS17676 -> Riven Cloud AS3258 | China Mobile regional/access -> AS9808 -> CMIN2 AS58807 -> Riven Cloud AS3258 |
| China to Tokyo final hop | 72.2 ms avg / 72.0 ms best / 0.0% loss | 40.0 ms avg / 39.8 ms best / 0.0% loss |
| Tokyo to China AS path | Riven Cloud AS3258 -> SoftBank AS17676 -> ordinary CMI AS58453 -> AS9808 -> China Mobile regional/access | Riven Cloud AS3258 -> CMIN2 AS58807 -> AS9808 -> China Mobile regional/access |
| Tokyo to China final hop | 70.0 ms avg / 69.9 ms best / 0.0% loss | 44.7 ms avg / 44.6 ms best / 0.0% loss |
| Result in this sample | Standard transit was 32.2 ms slower China to Tokyo and 25.3 ms slower Tokyo to China | The optimized path was about 45% lower RTT China to Tokyo and 36% lower RTT Tokyo to China |
For China Mobile customers, AS58807 is the signal to look for. The optimized sample uses CMIN2 instead of the ordinary AS58453/SoftBank transit path.
For the carrier-specific breakdown, read What is CMIN2? China Mobile International N2 and AS58807 explained.
How to read these MTR samples
The carrier sections above use cleaned sample MTR results collected on June 29, 2026. We publish carrier names, AS-level paths, direction, final-hop average RTT, and final-hop packet loss. We do not publish customer IP addresses, VPS IP addresses, router IPs, private IPs, hostnames, or full raw MTR output.
Treat these as point-in-time samples, not universal guarantees. The useful checks are simple: final-hop RTT, final-hop packet loss, visible AS path, and whether the route lands on the expected carrier network. In these samples, the optimized route had lower average final-hop RTT in both directions for all three carriers. The optimized samples also showed 0.0% final-hop packet loss, while the ordinary China Telecom baseline showed final-hop loss in this short sample.
Intermediate MTR packet loss, including 100% non-response on an intermediate hop, does not automatically mean real end-to-end packet loss. Many routers rate-limit or ignore ICMP while still forwarding customer traffic normally.
Use the ordinary SoftBank examples as a standard international transit baseline. SoftBank AS17676 is a major network. For this Tokyo-to-mainland-China use case, the carrier-specific premium paths fit better than a general transit path.
What customers actually feel
Most customers do not buy a route table. They buy a VPS because they want a website, API, control panel, game server, proxy service, development box, or internal tool to feel usable from mainland China.
The difference usually shows up in boring places: SSH stops feeling sticky, admin panels load without the first click hanging, and API calls from mainland China spend less time waiting on the network. It will not make every app fast, but it removes one common source of delay.
Peak-hour consistency is often the bigger win. A route that looks acceptable in the afternoon can become a problem in the evening if it depends on a congested international path. Matching China Telecom, China Unicom, and China Mobile to their own premium paths reduces that risk.
It does not remove every risk or guarantee the same latency for every province, office, mobile network, or residential line. Packet loss can still happen. The VPS starts from a better network position.
What China-optimized routing cannot guarantee
China-optimized routing improves path selection. It is not a physics exemption or a replacement for operational monitoring.
Performance can still depend on province, local ISP, last-mile quality, time of day, cross-border congestion, cable incidents, carrier routing changes, and the application itself. A user on weak Wi-Fi behind an overloaded local access network can still have a poor experience even if the international route is excellent.
MTR is a useful diagnostic tool, but it is not a full SLA. It shows a path sample at a point in time. That sample is valuable when it confirms the expected AS path and final-hop behavior, but it should not be treated as absolute proof that every future flow will behave identically.
The practical goal is better route selection: China Telecom through CN2/AS4809 and CTGNet/AS23764, China Unicom through AS9929 and China Unicom Global AS10099, and China Mobile through AS9808 and CMIN2/AS58807.
Choosing a Tokyo VPS for mainland China users
For a normal VPS buyer, CPU, RAM, NVMe storage, and transfer quota still matter. A busy application needs enough compute and disk performance. A high-traffic service needs a plan with enough monthly transfer. A production system needs backups and sensible operations.
For mainland China users, the network path can matter just as much.
A generic Japan VPS may be physically close to China, but physical distance is only one part of the route. The carrier path decides whether traffic enters the right Chinese backbone, whether the return direction is sensible, and whether the route remains stable when ordinary international transit gets busy.
Riven Cloud’s China-optimized Tokyo VPS routing is designed for customers who need that carrier-aware path: CTGNet/CN2 GIA for China Telecom, CUP for China Unicom, and CMIN2 for China Mobile.
Conclusion
China-optimized routing means matching each major mainland China carrier with its own premium path.
For Riven Cloud’s optimized Tokyo route, that means China Telecom traffic uses CN2/AS4809 domestically and CTGNet/AS23764 internationally, China Unicom traffic uses AS9929 and China Unicom Global AS10099, and China Mobile traffic uses AS9808 and CMIN2/AS58807.
That is what “three-network optimization” should mean in practice. It is not a slogan and it is not one generic overseas route. It is separate carrier engineering for China Telecom, China Unicom, and China Mobile.
If your users are in mainland China, the route can matter as much as CPU, RAM, and storage. Riven Cloud’s Tokyo route is built around that reality: China Telecom, China Unicom, and China Mobile each need their own path.
If you need a VPS with three-network optimized routing, you can order one at sa.net.
Share