What is CMIN2? China Mobile International N2 and AS58807 explained

China Mobile is often the least understood part of China-optimized VPS routing.

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.

Direction	Visible premium path	Final-hop avg RTT	Best RTT	Final-hop packet loss
Mainland China to Tokyo	China Mobile access -> AS9808 -> CMIN2/AS58807 -> AS3258	40.0 ms	39.8 ms	0.0%
Tokyo to mainland China	AS3258 -> CMIN2/AS58807 -> AS9808 -> China Mobile access	44.7 ms	44.6 ms	0.0%

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:

Direction	Standard transit path	Final-hop avg RTT	Best RTT	Final-hop packet loss
Mainland China to Tokyo	AS9808 -> ordinary CMI/AS58453 -> SoftBank/AS17676 -> AS3258	72.2 ms	72.0 ms	0.0%
Tokyo to mainland China	AS3258 -> SoftBank/AS17676 -> ordinary CMI/AS58453 -> AS9808	70.0 ms	69.9 ms	0.0%

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.

Direction	Standard transit avg RTT	CMIN2 optimized avg RTT	Reduction	Optimized path
Mainland China to Tokyo	72.2 ms	40.0 ms	32.2 ms lower / about 45% lower	AS9808 -> CMIN2/AS58807
Tokyo to mainland China	70.0 ms	44.7 ms	25.3 ms lower / about 36% lower	CMIN2/AS58807 -> AS9808

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.