Break "Slow" Apart First
"Slow" isn't one problem — it's a label covering several distinct ones. High latency, packet loss, slow only in the evening, specific services unreachable: these four symptoms have entirely different causes and entirely different fixes. Discussing them as one thing produces the unactionable conclusion that "Chinese networks are just like that."
Before optimising anything, establish which one you actually have. The table below maps four common symptoms to their causes and how to identify them. Most teams discover they have more than one at once.
| Symptom | Usual cause | How to identify it |
|---|---|---|
| High but stable latency | Physical distance and route detours | Run traceroute; check hop count and path |
| Fine by day, slow at night | Congested interconnect or international gateway | Test at off-peak and evening peak, then compare |
| Latency OK but noticeable packet loss | Poor return-path route quality | Test outbound and return paths separately |
| A specific domain won't load at all | Domain- or IP-level access restriction | Test the same host via a different domain or IP |
Worth stating up front: of these four, only the last is directly related to content filtering. The first three are purely questions of network capacity and routing — and they're what the rest of this article unpacks, because they're also the ones you have a realistic chance of improving.
The Three Real Structural Causes
None of the following relates to content filtering. They're consequences of network capacity and commercial settlement — and they account for most cross-border connection problems:
- Bottlenecks between the three carriers China Telecom, Unicom, and Mobile each run independent networks and must exchange traffic at national or provincial interconnection points. Those points have finite bandwidth, and when traffic surges — evening peak, a popular video platform ramping up — they saturate and cross-network access slows immediately. This is why the same server can feel fine to a Telecom user and slow to a Unicom one. The problem isn't your server; it's the segment in between.
- Highly concentrated international gateways On China Telecom's ChinaNet backbone, the country's international traffic ultimately funnels through three gateways: Beijing, Shanghai, and Guangzhou. Whether a user sits in Chengdu or Shenyang, outbound international traffic detours through one of those three. That structural concentration makes the international egress a natural peak-hour bottleneck — and not one you can solve by buying more bandwidth on your own side.
- Return-path route quality Traffic from China to overseas (the outbound leg) and from overseas back into China (the return leg) may take entirely different paths, and return quality is usually what determines what users actually feel. Different route tiers behave very differently at peak, which the next section covers in detail.
Route Tiers: 163, CN2 GT, and CN2 GIA
Any discussion of cross-border quality into China runs into China Telecom's route tiers. The traditional one is the 163 backbone, whose route nodes typically begin with 202.97. It carries the overwhelming majority of international traffic, which is exactly why it congests hardest at evening peak — showing up as latency spikes and pronounced packet loss.
CN2 (ChinaNet Next Carrying Network) is China Telecom's later-generation carrying network, with nodes beginning 59.43. It comes in two forms. CN2 GT routes the international leg over CN2 but returns to 163 for the domestic leg, so the international link improves while the domestic segment can still congest. CN2 GIA keeps both outbound and return legs entirely on CN2 without dropping back to 163, with the fewest hops, the highest QoS priority, and deliberately lighter loading.
Practically, this means that when comparing facilities or CDN providers, "is there a CN2 GIA return path?" often determines the real experience for users in China more than raw bandwidth does. It's also the kind of thing that doesn't appear on a spec sheet, so it's worth asking about directly.
So How Much Is the Firewall?
Content filtering exists and does cause connection problems, but it operates differently from the three factors above: it tends to make specific targets unreachable or unstable rather than making everything uniformly slower. If your own service isn't within scope of any restriction, the slowness users report is still most likely one of the three structural causes.
Put another way: if your site "loads but is slow" in China, that's usually a capacity and routing problem and architecture changes can improve it. If it "won't load at all, on any network," that's when it's worth investigating access restrictions. Separating those two cases first is what stops you spending effort in the wrong place.
Three Practical Directions for Improvement
Against the structural problems above, there are three layers you can work on:
1. Move content closer to users
The most direct approach is caching static content at edge nodes nearer to users in China, reducing how much traffic has to cross the international gateways at all. Nodes in Hong Kong and around China help somewhat; genuinely landing content on nodes inside the mainland requires completing ICP filing — a regulatory process that takes time and paperwork, so it's worth assessing early.
2. Choose the right return route
When selecting a facility or CDN provider, ask specifically which return route is used rather than comparing bandwidth figures alone. At the same monthly cost, the difference between a CN2 GIA return path and an ordinary 163 one at evening peak is often more noticeable than doubling your bandwidth.
3. Reduce the number of round trips
Once per-round-trip latency can't be reduced further, reduce how many round trips you need. Enabling HTTP/2 or HTTP/3 to multiplex connections, consolidating and trimming resource requests, and preloading critical assets — these front-end optimisations have amplified benefit in high-latency conditions, far more than they do on a low-latency network.
Three Things to Do When Diagnosing
Before raising the issue with a provider or evaluating a fix, gather these three things — your judgement will be considerably more accurate:
- Test across time windows, not once Cover at least off-peak and evening peak. A large gap between them points strongly at interconnect or gateway congestion rather than your server's performance.
- Test all three carriers separately Telecom, Unicom, and Mobile results often differ substantially. Concluding from one carrier alone easily misreads a single-network issue as universal, or misses one entirely.
- Separate outbound from return Test from your side toward China and from China toward your server. As noted above, the paths are frequently asymmetric, and one-directional testing yields misleading conclusions.
In Summary
Slow access from China is rarely down to a single cause, and the firewall usually isn't the dominant one. Capacity limits at inter-carrier interconnection points, international egress concentrated in Beijing, Shanghai, and Guangzhou, and differences in return-route tier together explain most of the latency and packet loss seen in practice — and all three can be improved through architectural choices. That's the value of separating the causes properly.
If you want to see how your service currently performs across China's three carriers, our speed test platform gives you per-carrier measured data, so you can decide which direction to tackle first.