Many buyers already know what to look for on China Telecom: CN2 GIA, CTGNet, AS4809, AS23764. They may also know China Unicom Premium through AS9929 and AS10099. China Mobile has its own premium path, and the signal to look for is CMIN2 / AS58807.

For China Mobile users, the route question is simple:

Does traffic move from China Mobile AS9808 into CMIN2 / AS58807,
or does it fall back to ordinary CMI / AS58453 and standard international transit?

For Riven Cloud Tokyo, the optimized China Mobile path in the June 29, 2026 sample was:

China Mobile access / regional network
-> China Mobile domestic backbone / AS9808
-> CMIN2 / China Mobile International N2 / AS58807
-> Riven Cloud Tokyo / AS3258

The ordinary SoftBank transit baseline from the same comparison set looked different:

China Mobile access / regional network
-> China Mobile AS9808
-> ordinary CMI / AS58453
-> SoftBank AS17676
-> AS3258 Tokyo endpoint

That difference matters. A VPS can be in Japan and still take the wrong carrier path for China Mobile users.

The China Mobile networks customers should know

China Mobile routing has several layers. For VPS buyers, four ASNs are worth knowing.

Hurricane Electric’s BGP Toolkit lists AS9808 as China Mobile Communications Group Co., Ltd.. That is the domestic China Mobile backbone side. A user may start from a provincial or regional China Mobile network first, then enter AS9808.

PeeringDB lists AS58807 as China Mobile International - NII, with CMIN2 as its also-known-as value. The same PeeringDB record shows AS58807 at Tokyo, Singapore, Hong Kong, Frankfurt, and other interconnection points. BGP.tools also lists AS58807 as China Mobile International Limited, with prefix descriptions such as Japan N2 Network, Singapore N2 Network, and Germany N2 Network.

Hurricane Electric’s BGP Toolkit lists AS58453 as China Mobile International Limited. In the baseline route below, AS58453 appears as the ordinary CMI international side before SoftBank AS17676. PeeringDB lists AS17676 as SoftBank Corp., and AS3258 as xTom Tokyo.

Use this practical map:

• China Mobile regional or access networks: where many broadband, enterprise, or mobile users begin.
• AS9808: China Mobile’s domestic backbone.
• AS58807: CMIN2 / China Mobile International N2, the premium international path.
• AS58453: ordinary China Mobile International / CMI, commonly seen on standard China Mobile international routes.
• AS17676: SoftBank, used in the standard transit baseline.
• AS3258: the Tokyo network used by the test endpoints.

AS9808 is the domestic side. AS58807 is the premium CMIN2 international side. A strong China Mobile optimized route should show traffic moving from AS9808 into AS58807 before it reaches the VPS provider.

What CMIN2 means

CMIN2 means China Mobile International N2. In the VPS market, it is the premium China Mobile path customers should look for when evaluating China Mobile optimized connectivity.

It plays a similar customer-facing role for China Mobile users as CN2 GIA does for China Telecom users or CUP / AS9929 does for China Unicom users. It is not the same network and should not be described as the same product. The useful comparison is functional: it gives China Mobile traffic a carrier-matched premium path instead of pushing it through ordinary international transit.

For Riven Cloud, the shorthand is:

China Mobile traffic from mainland China
-> AS9808 domestically
-> CMIN2 / AS58807 internationally
-> Riven Cloud Tokyo / AS3258

The old habit of checking only Telecom and Unicom is incomplete. If your users are on China Mobile broadband or China Mobile 5G, AS58807 is the route signal to check.

CMIN2 / AS58807 and ordinary CMI / AS58453 are not the same route

CMIN2 and ordinary CMI are related to China Mobile International, but they should not be treated as interchangeable.

AS58807 is the CMIN2 / N2 premium path. It is the AS Riven Cloud peers with for China Mobile optimized routing, and it is the desired path for China Mobile users accessing the Riven Cloud Tokyo optimized node.

AS58453 is the ordinary CMI path seen in the baseline route. It can be useful for general Internet traffic, but in this China Mobile to Tokyo sample it then handed traffic to SoftBank AS17676 before reaching AS3258.

That is the operational split:

Optimized:
AS9808 -> CMIN2 / AS58807 -> AS3258

Standard transit baseline:
AS9808 -> ordinary CMI / AS58453 -> SoftBank AS17676 -> AS3258

The names sound close enough to confuse people. The routes are visibly different.

The Riven Cloud China Mobile CMIN2 path

The optimized path for China Mobile users is:

China Mobile user
-> China Mobile regional/access network
-> China Mobile domestic backbone / AS9808
-> CMIN2 / China Mobile International N2 / AS58807
-> Riven Cloud Tokyo / AS3258

Each part has a job:

• The user may start from a regional China Mobile access network, such as a provincial CMNET segment.
• AS9808 is the China Mobile domestic backbone.
• AS58807 is CMIN2 / China Mobile International N2.
• AS3258 is the Tokyo network used by the Riven Cloud optimized test node.

Riven Cloud peers with China Mobile through CMIN2 / AS58807. China Mobile traffic from mainland China uses AS9808 domestically before reaching CMIN2 / AS58807, then Riven Cloud.

Optimized route MTR sample

The optimized mainland China to Tokyo sample came from a third-party MTR-style capture with 20 probes. The return MTR from Tokyo to mainland China started at 2026-06-29T10:34:03+0000 and used 10 probes.

The forward sample showed a China Mobile regional access side, AS9808, CMIN2 / AS58807, and the final Riven Cloud endpoint on AS3258. The return sample showed AS3258, then AS58807, then AS9808, then the China Mobile access endpoint.

The optimized route shows the expected China Mobile premium structure in both directions. Traffic moves between AS9808 and CMIN2 / AS58807, instead of using ordinary CMI and standard transit.

Standard SoftBank transit comparison

The same June 29, 2026 comparison set included a standard SoftBank transit baseline to an AS3258 Tokyo endpoint. It was not the same destination IP as the Riven Cloud optimized node, so treat it as a route-pattern baseline rather than a same-host A/B test.

The baseline path was:

China Mobile user
-> China Mobile regional/access network
-> China Mobile AS9808
-> ordinary CMI / AS58453
-> SoftBank AS17676
-> AS3258 Tokyo endpoint

Cleaned final-hop results from that baseline were:

This does not mean SoftBank or ordinary CMI is bad. They can be fine for many general routes. For this China Mobile to Tokyo sample, the standard transit path had much higher average RTT than the CMIN2 optimized path.

Side-by-side results

The CMIN2 optimized path reduced average RTT in both directions.

The latency reduction is useful. The path evidence is the bigger point: the optimized route used AS58807, the intended China Mobile premium path, instead of ordinary CMI / AS58453 and standard international transit.

For China Mobile customers, this is the missing piece in many route comparisons. Telecom may have CN2/CTGNet. Unicom may have AS9929/AS10099. Mobile needs its own premium path too.

Why CMIN2 matters for China Mobile users

China Mobile users were often the weak spot in older “China optimized” VPS offers. A provider might optimize for China Telecom and China Unicom, then leave China Mobile to ordinary international routing.

CMIN2 changes the checklist. China Mobile users can now look for a premium path of their own: AS9808 on the domestic side, AS58807 on the international side, then the provider network.

In practical terms, that can mean:

• Lower latency for China Mobile users.
• More responsive SSH sessions.
• Faster website loading from China Mobile networks.
• Better API response times from mainland China.
• Smoother control panel or remote desktop access.
• Less dependence on ordinary transit paths.
• Better carrier matching for services with China Mobile users.

The route does not make every application fast. It removes one common source of delay: sending China Mobile traffic through a less suitable international path.

How to check whether a route is really CMIN2

A CMIN2 route should usually show:

• AS9808 on the mainland China domestic side.
• AS58807 on the China Mobile International N2 side.
• The provider AS after AS58807.

For Riven Cloud Tokyo, the expected optimized pattern is:

China to Tokyo:
China Mobile access -> AS9808 -> AS58807 -> AS3258

Tokyo to China:
AS3258 -> AS58807 -> AS9808 -> China Mobile access

The ordinary baseline pattern may look like this:

China Mobile access -> AS9808 -> AS58453 -> AS17676 -> AS3258

Router IPs and city codes can change. The AS-level pattern is the part to check first.

How to read MTR without chasing noise

MTR is useful, but it is not a packet-loss oracle.

Intermediate routers may rate-limit ICMP, ignore probes, or show strange control-plane latency while still forwarding customer traffic normally. A 100% non-response on an intermediate hop does not prove end-to-end packet loss when later hops and the final destination continue to respond.

The optimized return sample is a good example. Several early AS3258 intermediate hops reported high latency or loss-like behavior, but later AS58807, AS9808, and final access-network hops were normal. The final destination showed 44.7 ms average RTT, 44.6 ms best RTT, and 0.0% packet loss.

When checking CMIN2 routes, focus on:

• Final-hop average RTT.
• Final-hop packet loss.
• Whether the path shows AS9808 and AS58807.
• Whether the return direction also uses AS58807 and AS9808.
• Whether intermediate loss continues to the final destination.

Short MTR samples are useful route evidence. They are not an SLA for every province, every hour, or every future routing change.

What CMIN2 cannot guarantee

CMIN2 gives China Mobile traffic a better path. It does not make every last-mile network perfect.

Performance can still depend on province, local China Mobile access quality, home broadband or 5G conditions, time of day, carrier routing changes, international cable incidents, firewall behavior, application protocol, customer-side Wi-Fi, and router quality.

CMIN2 also cannot make all mobile networks behave like fiber broadband. A phone on a congested cell, a home router with poor Wi-Fi, or an application with bad retry behavior can still feel slow.

Treat the route as one part of the deployment decision, alongside CPU, RAM, NVMe storage, monthly transfer, backup policy, and application design.

Conclusion

For China Mobile users, Riven Cloud’s optimized Tokyo route is designed around the CMIN2 premium path:

China Mobile access / regional network
-> AS9808 domestic backbone
-> CMIN2 / China Mobile International N2 / AS58807
-> Riven Cloud Tokyo / AS3258

In the June 29, 2026 samples, that path delivered 40.0 ms average RTT from mainland China to Tokyo and 44.7 ms average RTT from Tokyo back to mainland China, both with 0.0% final-hop packet loss.

The standard SoftBank transit baseline averaged 72.2 ms from mainland China to Tokyo and 70.0 ms in the return direction. The cleaner result came from the path choice: AS9808 into CMIN2 / AS58807 instead of AS58453 and SoftBank transit.

For the full three-network view, read What are China-optimized routes? CTGNet/CN2 GIA, CUP, and CMIN2 explained. For the other carrier-specific articles, see China Telecom premium routing and China Unicom Premium routing.

If your users are on China Mobile in mainland China, test the path from the Tokyo Looking Glass and compare it with your current route. If the CMIN2 path fits your users, view the Riven Cloud VPS plans and deploy a Tokyo server built for China Mobile traffic to take the right carrier path before it reaches your application.

For China Telecom users, the useful question is whether traffic uses the premium China Telecom route in both directions: the China Telecom access network, the CN2/AS4809 premium segment, the current CTGNet/AS23764 international delivery path, and then the VPS provider network.

For Riven Cloud Tokyo, the optimized China Telecom path is:

China Telecom access network / AS4134
-> CN2 premium segment / AS4809 / 59.43
-> CTGNet international edge / AS23764
-> Riven Cloud Tokyo / AS3258

That is materially different from a normal international transit path such as:

China Telecom AS4134
-> SoftBank AS17676
-> Riven Cloud Tokyo / AS3258

The MTR samples in this article were collected on June 29, 2026. They are short samples, not an SLA. They are useful because they show both the visible AS path and the final-hop behavior for the optimized China Telecom route, then compare it with a standard SoftBank transit baseline from the same test set.

China Telecom routing has several moving parts

China Telecom routing is easy to oversimplify because several related names show up in the same conversation.

China Telecom’s Global Internet Access page says the service offers access to ChinaNet (AS4134) and CN2 (AS4809). Public PeeringDB records list CTGNet as AS23764 with the IRR as-set AS-CTGNET, and China Telecom / CN2 as AS4809 with the IRR as-set AS-CN2.

For VPS buyers, the practical map looks like this:

• AS4134: ChinaNet / China Telecom’s large public Internet backbone and access network.
• AS4809: CN2 / China Telecom’s premium backbone segment, commonly associated with CN2 GIA in the VPS market.
• AS23764: CTGNet / China Telecom Global’s international network used for peering and international delivery.

A China Telecom broadband user may begin in AS4134 or a regional access network. A premium route should move the traffic into the CN2/AS4809 segment and then use CTGNet/AS23764 for the international handoff.

That last point is where many route descriptions get sloppy. CTGNet and CN2 GIA are related in how customers experience the route, but they are not interchangeable terms.

What CN2 GIA means in practice

CN2 GIA is market shorthand for China Telecom’s premium global Internet access route. VPS buyers usually associate it with the CN2/AS4809 backbone, lower latency, less congestion, and more predictable cross-border performance than ordinary ChinaNet routes.

The label alone does not prove much. A useful route check asks two questions:

• Does the route show the premium CN2 segment, often visible as 59.43 hops or AS4809?
• Does the international handoff avoid ordinary transit and land on the intended China Telecom Global path?

In practice, customers should look less at the label and more at the path. A trace that says “CN2” somewhere in the middle is weaker evidence than a clean path showing China Telecom access, CN2/AS4809, CTGNet/AS23764, and the provider network in both directions.

What CTGNet means in this route

CTGNet is the China Telecom Global international network associated with AS23764. In the Riven Cloud Tokyo route, CTGNet is the peer-facing international side of the China Telecom path.

CN2/AS4809 is the premium China Telecom segment that mainland China users have historically associated with CN2 GIA. CTGNet/AS23764 is the international delivery and interconnection side used in the current route.

Riven Cloud peers with China Telecom through CTGNet / AS23764. China Telecom traffic from mainland China uses the CN2 / AS4809 premium segment before reaching CTGNet / AS23764, where it is handed to Riven Cloud’s Tokyo network on AS3258. PeeringDB lists AS3258 as xTom Tokyo, which matches the Tokyo network context for this service.

The clean shorthand is:

AS4134 access
-> CN2 / AS4809 / 59.43
-> CTGNet / AS23764
-> Riven Cloud Tokyo / AS3258

The Riven Cloud China Telecom path

The optimized path from a China Telecom user to Riven Cloud Tokyo should show the China Telecom access side first, then the premium CN2 segment, then CTGNet, then the Riven Cloud endpoint.

China Telecom user
-> China Telecom access network / AS4134
-> CN2 premium segment / AS4809 / 59.43
-> CTGNet international edge / AS23764
-> Riven Cloud Tokyo / AS3258

Each part has a job:

• AS4134 is where many ordinary China Telecom users begin.
• The 59.43 hops indicate the CN2 premium segment.
• CTGNet / AS23764 is the international handoff and China Telecom peer path.
• AS3258 is the Tokyo network used by the Riven Cloud test node.

The reverse direction matters as much as the forward direction. A route can look good from China to Tokyo and still return through a different, less suitable path. The Riven Cloud sample below showed the expected CTGNet and CN2 path in both directions.

Optimized route MTR sample

The optimized MTR samples were collected on June 29, 2026 at 2026-06-29T10:22:04+0000 for mainland China to Tokyo and 2026-06-29T10:23:28+0000 for Tokyo to mainland China. Each sample used 10 probes.

The raw output showed China Telecom AS4134 near the access side, multiple 59.43 hops on the CN2 segment, CTGNet hostnames such as ct163.jp.tyo.ctgnet and jp.tyo.ctgnet, and the final Riven Cloud Tokyo endpoint on AS3258.

The optimized route shows the expected premium China Telecom path in both directions. Traffic does not simply exit China Telecom through ordinary international transit. It uses the CN2/59.43 segment and CTGNet/AS23764 before reaching the Riven Cloud Tokyo network.

Standard SoftBank transit comparison

SoftBank is a normal international transit path. PeeringDB lists SoftBank Corp. as AS17676. There is nothing inherently wrong with using SoftBank for general Internet traffic.

For this China Telecom to Tokyo comparison, the baseline path was less suitable:

China Telecom user
-> China Telecom AS4134
-> SoftBank AS17676
-> Riven Cloud Tokyo / AS3258

The standard transit baseline from the same June 29, 2026 test set showed higher final-hop RTT than the CTGNet/CN2 optimized path.

This sample does not prove that SoftBank is bad. It shows the difference between a generic international transit path and a China Telecom matched premium path for this specific Tokyo VPS use case.

Side-by-side results

The RTT gap was large in both directions.

In this sample, the CTGNet/CN2 optimized route reduced average RTT by more than 40 ms in the China-to-Tokyo direction and more than 30 ms in the return direction. The path itself is the more important signal: the optimized route used the intended China Telecom premium network instead of ordinary international transit.

That route choice is what customers should evaluate when they compare CN2 GIA VPS offers. A low number in one ping test is useful. A clean premium carrier path in both directions is better evidence.

What customers feel

Most customers do not buy AS paths for their own sake. They care whether a server feels usable from mainland China.

For China Telecom users, a better matched route can show up in practical ways:

• SSH sessions feel more responsive.
• Control panels and dashboards spend less time waiting on the network.
• API calls from mainland China have lower round-trip delay.
• Websites load faster for China Telecom users.
• Real-time applications have less room for jitter to become visible.
• Evening peak is less likely to be dominated by ordinary international transit congestion.

The word “likely” matters. Route optimization improves the path. It does not make every application fast, and it does not remove every local access problem.

How to read MTR without fooling yourself

MTR is useful, but it is easy to overread.

Focus on the final destination, the overall RTT pattern, and the visible AS path. Intermediate packet loss can be caused by ICMP rate limiting, router control-plane protection, or devices that simply do not answer probes. A 100% non-response on an intermediate hop does not prove end-to-end loss when later hops and the final destination still respond normally.

For this comparison, the important checks are:

• Final-hop average RTT.
• Final-hop packet loss.
• Whether the visible path uses CN2/59.43/AS4809.
• Whether the international handoff uses CTGNet/AS23764.
• Whether the return path also uses the premium China Telecom route.

Short MTR samples are useful route evidence. They are not a guarantee for every province, every hour, or every future carrier policy change.

What CTGNet/CN2 cannot guarantee

Premium China Telecom routing gives traffic a better path. It does not suspend the laws of the Internet.

Performance can still depend on the user’s province, local access network, time of day, submarine cable events, carrier routing changes, firewall behavior, application protocol, customer-side Wi-Fi, and last-mile conditions.

A clean CTGNet/CN2 path reduces dependence on ordinary international transit. It cannot control every hop before the user reaches China Telecom’s backbone, and it cannot guarantee that every application will use the network efficiently.

Treat route optimization as one important part of a deployment decision, alongside CPU, RAM, NVMe storage, transfer quota, backup policy, and application design.

Conclusion

For China Telecom users, Riven Cloud’s optimized Tokyo route is built around the premium China Telecom path:

AS4134 access network
-> CN2 / AS4809 premium segment
-> CTGNet / AS23764 international delivery
-> Riven Cloud Tokyo / AS3258

The June 29, 2026 sample showed much lower average RTT than ordinary SoftBank transit in both directions: 36.3 ms versus 78.1 ms from mainland China to Tokyo, and 41.6 ms versus 74.1 ms from Tokyo back to mainland China.

CTGNet and CN2 should be read as parts of the current China Telecom premium routing path, not as interchangeable words. The useful question is whether the actual path shows the premium China Telecom network in both directions.

For a broader carrier view, read What are China-optimized routes? CTGNet/CN2 GIA, CUP, and CMIN2 explained. For the other carrier-specific articles, see China Unicom Premium routing and China Mobile CMIN2 routing. To test from Riven Cloud’s Tokyo location, use the Tokyo Looking Glass.

China Unicom Premium, often called CUP in the VPS market, is better understood as a two-part premium path:

China Unicom access / AS4837
-> China Unicom Premium / AS9929
-> China Unicom Global / AS10099
-> Riven Cloud Tokyo / AS3258

The value of the route is in that structure. A good China Unicom Premium path should move traffic from the normal AS4837 access or regional side into AS9929, then use China Unicom Global AS10099 for international delivery before reaching Riven Cloud.

For Riven Cloud Tokyo, the optimized Unicom path in the June 29, 2026 MTR samples was:

Mainland China to Tokyo:
AS4837 -> AS9929 -> AS10099 -> AS3258

Tokyo to mainland China:
AS3258 -> AS10099 -> AS9929 -> AS4837

Those two directions matter. A route that shows AS9929 in one direction and ordinary transit in the other direction is not the same operational result.

The China Unicom networks customers should know

China Unicom routing usually involves three ASNs in this discussion.

China Unicom Global’s DIA page describes AS4837 as China Unicom’s backbone Internet network and says its mainland China DIA service can use the premium bearer network AS9929. The same page describes AS9929 as light loaded and better performing for premium DIA. Its IPT & peering page describes AS10099 as China Unicom’s international network for flexible usage patterns and customized routes.

Public PeeringDB records also match the ASN identities: AS10099 is China Unicom Global, AS9929 is China Unicom Industrial Internet Backbone, and AS3258 is xTom Tokyo.

For route analysis, use this practical map:

• AS4837: China Unicom’s common public Internet backbone and access or regional network.
• AS9929: the premium Unicom bearer segment, usually the part VPS buyers look for when checking a CUP route.
• AS10099: China Unicom Global’s international network and the peer-facing side for Riven Cloud.
• AS3258: the Tokyo network used by the Riven Cloud test node.

AS4837 at the beginning of a trace is not a red flag by itself. Many Unicom users begin there. The route becomes interesting when traffic moves from AS4837 into AS9929, then reaches AS10099 before the provider network.

What China Unicom Premium means in practice

China Unicom Premium is the market name commonly used for the premium Unicom cross-border route. In practice, a strong CUP route usually means AS9929 on the mainland China side and China Unicom Global AS10099 on the international side.

The name alone does not prove much. The path should show how the access network, premium Unicom segment, international network, and provider network connect.

China Unicom user
-> China Unicom access / AS4837
-> China Unicom Premium / AS9929
-> China Unicom Global / AS10099
-> Riven Cloud Tokyo / AS3258

Riven Cloud peers with China Unicom Global through AS10099. China Unicom traffic from mainland China enters the premium AS9929 segment before reaching AS10099 and Riven Cloud.

AS9929 and AS10099 are different parts of the route

AS9929 and AS10099 are not interchangeable.

AS9929 is the premium Unicom segment customers usually see on the mainland China side. It often appears after AS4837 access or regional hops. In the sample route below, traffic starts on AS4837, then enters AS9929 at hop 8 in the mainland China to Tokyo direction.

AS10099 is China Unicom Global’s international network. It is the AS Riven Cloud peers with for China Unicom Premium, and it handles the international side before traffic reaches Riven Cloud’s Tokyo network.

A useful CUP check looks for both parts. Seeing only one ASN is weaker evidence than seeing the full AS4837 -> AS9929 -> AS10099 -> AS3258 pattern, with the reverse direction matching the same structure.

The Riven Cloud China Unicom Premium path

The optimized China Unicom path for Riven Cloud Tokyo is:

China Unicom user
-> China Unicom AS4837 access / regional network
-> China Unicom Premium AS9929
-> China Unicom Global AS10099
-> Riven Cloud Tokyo AS3258

Each part has a role:

• AS4837 may appear because many users start from ordinary China Unicom access or regional networks.
• AS9929 is the premium Unicom segment.
• AS10099 is the China Unicom Global international side.
• AS3258 is the Riven Cloud Tokyo test network.

AS4837 near the access side does not mean the route failed to use premium Unicom routing. The next step is the useful part: whether the path moves into AS9929 and then AS10099.

Optimized route MTR sample

The optimized MTR samples below were collected on June 29, 2026. The mainland China to Tokyo sample started at 2026-06-29T10:20:30+0000. The Tokyo to mainland China sample started at 2026-06-29T10:20:36+0000. Each MTR used 10 probes.

The visible AS path matched the expected China Unicom Premium structure in both directions.

The mainland China to Tokyo MTR showed AS4837 on the access side, then AS9929, then AS10099, and the final Riven Cloud Tokyo endpoint on AS3258. The return MTR showed AS3258 first, then AS10099, then AS9929, and the final China Unicom endpoint on AS4837.

That is the important production signal: the route uses AS9929 and AS10099 in both directions, instead of leaving China Unicom through a generic international transit path.

Standard SoftBank transit comparison

The same June 29, 2026 comparison set also included a standard SoftBank transit baseline. SoftBank AS17676 is a normal international transit network. The point of the comparison is route matching for China Unicom users, not a claim that SoftBank is a bad network.

The baseline path was:

China Unicom user
-> China Unicom AS4837
-> SoftBank AS17676
-> Riven Cloud Tokyo AS3258

Cleaned final-hop results from that baseline were:

For this Unicom to Tokyo sample, the standard transit path had higher average RTT than the China Unicom Premium route in both directions.

Side-by-side results

The optimized path reduced average RTT in both directions.

The RTT reduction is useful, but the cleaner route structure is the bigger signal. The optimized route used the intended China Unicom premium path rather than ordinary international transit.

For customers comparing AS9929 VPS or CUP VPS offers, this is the check that matters: AS4837 access, AS9929 premium segment, China Unicom Global AS10099, and the provider AS in both directions.

Why this matters for VPS users

Most customers do not care about AS paths until the network starts wasting their time.

For China Unicom users, a carrier-matched path can improve ordinary daily work:

• SSH sessions feel more responsive.
• Websites load faster for users on China Unicom.
• API calls from mainland China spend less time waiting on the network.
• Control panels and remote desktop sessions feel less sticky.
• Latency-sensitive applications get a cleaner path to Tokyo.
• The service depends less on ordinary international transit during busy hours.

The result still depends on the user’s local line and application behavior. Route optimization gives the traffic a better path. It does not make every last-mile network perfect.

How to check whether a route is really China Unicom Premium

A good Unicom premium route often shows this pattern:

• AS4837 near the access side.
• AS9929 as the premium Unicom segment.
• AS10099 as the China Unicom Global international network.
• The provider AS after AS10099.

For Riven Cloud Tokyo, the expected optimized pattern is:

China to Tokyo:
AS4837 -> AS9929 -> AS10099 -> AS3258

Tokyo to China:
AS3258 -> AS10099 -> AS9929 -> AS4837

Exact router IPs, hostnames, and city codes may change. The AS-level pattern is the part to check first.

How to read MTR without chasing the wrong problem

MTR is useful, but intermediate hops can mislead.

Routers may rate-limit ICMP, deprioritize control-plane replies, or ignore probes while still forwarding customer traffic normally. A 100% non-response on an intermediate hop does not prove end-to-end packet loss when later hops and the final destination continue to respond.

The Tokyo to mainland China sample shows why this matters. Hop 5 reported 50.0% loss and a very high average latency, but later hops returned to normal and the final destination showed 36.6 ms average RTT with 0.0% packet loss. Treat that kind of isolated intermediate behavior as a diagnostic clue, not as final proof of customer traffic loss.

When checking CUP routes, focus on:

• Final-hop average RTT.
• Final-hop packet loss.
• Whether the path shows AS9929 and AS10099.
• Whether the return direction also uses AS10099 and AS9929.
• Whether the same loss pattern continues to the final destination.

Short MTR samples are useful route evidence. They are not an SLA for every province, every hour, or every future routing change.

What China Unicom Premium cannot guarantee

China Unicom Premium gives traffic a better path. It does not make every last-mile network perfect.

Performance can still depend on province, local broadband quality, office or residential network conditions, last-mile congestion, time of day, carrier routing changes, international cable incidents, application protocol, customer-side Wi-Fi, and customer router behavior.

CUP reduces dependence on ordinary international transit for China Unicom users. It cannot control every access network before AS4837, and it cannot fix an application that handles latency poorly.

Treat the route as one part of the deployment decision, alongside CPU, RAM, NVMe storage, monthly transfer, backup policy, and application design.

Conclusion

For China Unicom users, Riven Cloud’s optimized Tokyo route is designed around the real China Unicom Premium path:

AS4837 access / regional network
-> AS9929 premium segment
-> China Unicom Global AS10099
-> Riven Cloud Tokyo AS3258

In the June 29, 2026 MTR samples, that path delivered 37.4 ms average RTT from mainland China to Tokyo and 36.6 ms average RTT from Tokyo back to mainland China, both with 0.0% final-hop packet loss.

The same-day standard SoftBank transit baseline averaged 53.1 ms from mainland China to Tokyo and 57.0 ms in the return direction. The lower RTT helps, but the route evidence is the real point: the optimized route shows the expected AS9929 and AS10099 path in both directions.

For a broader carrier view, read What are China-optimized routes? CTGNet/CN2 GIA, CUP, and CMIN2 explained. For the other carrier-specific articles, see China Telecom premium routing and China Mobile CMIN2 routing. To test from Riven Cloud’s Tokyo location, use the Tokyo Looking Glass.

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.

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.

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.

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.