Where the time actually goes
A user in Shanghai opening a page hosted in Virginia is not waiting on your application. They are waiting on a path. Every request crosses the international gateway, and that hop is shared by all traffic entering and leaving the mainland. It behaves well for most of the day and degrades predictably in the evening peak, when latency climbs and packet loss appears.
- Round trips cost 150-300 ms, so a page that needs eight of them pays over a second before your application does any work.
- Packet loss is more damaging than latency. One lost packet stalls the whole TCP stream until it is retransmitted, which is why these sites feel unpredictable rather than merely slow.
- TLS handshakes are the first thing to fail. When a connection is reset mid-handshake the user gets an error page, not a slow page.
- DNS adds round trips of its own, and answers pointing at distant addresses make everything downstream worse.
The result is a pattern most teams recognise: fine in the morning, unusable at 21:00, with error rates that never show up in your own monitoring, because your monitoring sits next to the origin.
Four patterns for serving China
| Pattern | What it is | Filing | Best for |
|---|---|---|---|
| Overseas origin, direct | Users connect to your existing origin | None | Low-traffic sites where China is not a real market |
| Overseas origin behind a near-shore edge | Requests terminate on edge nodes close to the mainland, which fetch from your origin | None | Marketing sites, APIs, and SaaS with a China audience |
| Mainland origin, filed | Servers inside the mainland with an ICP filing on the domain | Required | Mainland customers, or data that must stay in-country |
| Near-shore edge now, mainland later | Start on the edge, then move the same hostname onto mainland infrastructure when a filing completes | Later | Teams that expect to need mainland presence eventually |
These are not mutually exclusive. The last row is a migration path rather than an architecture, and it is the one most teams end up wanting: serve users today, keep the option open.
Reference architecture: overseas origin behind a near-shore edge
- Users resolve your existing hostname. Nothing in the URL changes.
- Requests terminate on edge nodes close to the mainland, so the long-haul hop moves from user-to-origin to edge-to-origin.
- Static assets and cacheable responses are served from the edge and never cross the border.
- Dynamic requests are forwarded over a warm, established connection instead of a cold one opened by every user.
- TLS terminates at the edge against a certificate for your own hostname.
The effect is that most requests stop crossing the border at all, and the requests that do cross do so once, on a connection that is already warm.
What the edge has to do beyond caching
Caching is the visible half. The rest is what decides whether the architecture holds up under load:
- Protocol optimisation. Persistent connections, modern congestion control, and HTTP/2 or HTTP/3 multiplexing cut the number of round trips that cross the border.
- TLS handling. Issuance and renewal, modern ciphers, and session resumption. Handshake failure is the dominant error mode on a poor cross-border path.
- Origin protection. The edge absorbs retries and spikes, so the origin sees steadier, lower-volume traffic.
- Cache-hit ratio. The single biggest lever on perceived speed: a response that never leaves the edge is a response that never experiences cross-border loss.
- User-side observability. Origin-side monitoring cannot see the cross-border hop, so you need measurements from the regions your users are actually in.
Choosing between them
| If this is true | Start here |
|---|---|
| China is a small share of traffic and nobody is complaining | Overseas origin, direct |
| Chinese users are a real segment and you cannot or will not file | Overseas origin behind a near-shore edge |
| Data must stay inside the mainland, or you serve mainland consumers at scale | Mainland origin with an ICP filing |
| You will need mainland infrastructure, but not today | Near-shore edge now, with a migration plan that keeps the hostname |
Making a later move to the mainland cheap
The expensive part of moving into the mainland is not the servers. It is rebuilding everything around a new hostname, reissuing certificates, and asking users to change what they type.
- Keep one hostname. Point it at the edge first and at mainland infrastructure later; users never see the change.
- Keep the DNS record simple. A single CNAME is a five-minute change and an equally fast rollback.
- Keep certificates on one track. If your provider issues and renews them, the migration does not turn into a certificate project.
- Keep the origin where it is until the last moment. The edge can keep serving everyone outside the mainland while mainland users move first.
Checklist before you commit
- Measure from mainland cities, not from your office, using regional probes or real user monitoring rather than a single ping from HQ.
- Measure during the evening peak as well as the morning.
- Track error rates separately from latency. They have different causes.
- Know your cache-hit ratio before and after. If it does not move, the edge is not earning its place.
- Confirm what your provider serves when the origin is unhealthy. A cached error page is worse than a slow one.
- Decide now whether you will ever need a mainland filing, because that decision changes the architecture.