Papa Labs

A China office can't reach an overseas system: rule out the server before anything else

3 min read #networking#china#vpn#troubleshooting 中文

An internally-hosted system (on a VPS) suddenly stopped opening from a China office: the browser threw a “connection isn’t private” certificate error, and remote desktop wouldn’t connect either. The first instinct is “the server broke” — but the investigation quickly has to run the other way.

First, confirm: is it really the server?

Three checks ruled out the server side:

  1. Access the same system from the Singapore headquarters — worked perfectly, certificate and connection both fine;
  2. Check the server’s own health — CPU, memory, processes all normal, no crash signs;
  3. Check DNS resolution — returned the expected IP correctly.

Conclusion: server, certificate, and DNS are all fine. Only access from mainland China fails — the problem space instantly narrows to the path between China and the outside world.

The overseas server is fine; the problem sits on the path between mainland China and the outside

All three things checked come back clean — the problem can only live in the middle

The right framework for this class of problem

Cross-border access failures (especially China-office-to-self-hosted-overseas-system) commonly trace back to:

  • Carrier-level filtering on the cross-border link: certain overseas IPs/domains become intermittently unreachable, sometimes due to link quality swings, sometimes due to content-filtering policy shifts (usually with zero notice — it just changes);
  • DNS poisoning: the domain resolves to a wrong IP within mainland China (ruled out this time, but worth keeping on the checklist);
  • Certificate trust-chain interference: if some intermediate node intercepts the path, the browser’s certificate validation fails with exactly the “not private” warning seen here.

What to actually do about it

For this class of problem, “fixing it” is usually outside your own control (not your server, not your network). What you can do is give affected users a working alternative path:

  1. Confirm the blast radius: test the same system through an overseas VPN/jump host to confirm it really is China-only, and every other region is fine;
  2. Give affected users an interim route: switch to whatever compliant cross-border network solution the company already has (e.g. an SD-WAN circuit) to move the traffic off the ordinary public internet path;
  3. Long-term evaluation: if this recurs, it signals that “relying on the plain public internet to reach overseas systems from mainland China” is itself an architectural risk, and key systems may need a path better suited to cross-border access.

Lessons

  1. Cross-border network problems are easily misdiagnosed as “the server is broken.” Testing from an overseas point first rules out the server side and saves a lot of wasted investigation time;
  2. This class of problem is often neither caused by your infrastructure nor fixable unilaterally by you — the goal shifts from “solve it” to “route around it”;
  3. Recurring cross-border access failures are the best evidence for justifying an investment in a leased line/SD-WAN — quantify it before deciding whether it’s worth the spend.
← All posts