HTTP tunnels for China — temporary, not production edge

An HTTP tunnel for China can unblock a demo; it should not be your China access strategy. Teams under launch pressure often stand up a reverse proxy, SSH reverse tunnel, or a commercial relay (the same class as ngrok-style temporary tunnels and “China acceleration” boxes) so Mainland China stakeholders can “see the site.” That buys hours, not a product. Production access needs a stable, auditable ingress path — usually filed Mainland China hosting or CDN — with tunnels demoted to temporary engineering tools. A relay runbook is not a China launch plan.

Preconditions

Before you open port 443 on a relay, lock these answers. Missing any of them turns a demo aid into shadow IT.

Precondition	Why DIY stalls
User type named (employee, partner, or customer)	Wrong tool: ZTNA vs public edge vs break-glass
Expiry date + replacement project on a calendar	“Temporary” without a kill date becomes production
Blast radius if the relay is compromised written down	Open reverse tunnels expose admin UIs
TLS / logging / auth model understood	Re-encrypt proxies break apps; open relays become free proxies
Real China edge path funded or escalated	Tunnel without a successor is architecture by accident

Chinese-language provider consoles, ICP-aligned hosting decisions, and Mainland China vantage measurement are not optional if customers are the audience. Your team usually cannot graduate from a hobby relay to filed public ingress from overseas DIY alone.

Core path

Situation	Prefer	Avoid
Investor demo next day	Time-boxed HTTP/SSH tunnel (or ngrok-class relay) + watermark “temporary”	Selling the tunnel as architecture
China employees need admin UI	VPN / ZTNA / private interconnect	Public SSH reverse tunnel on :443
Customers in Mainland China	China edge/host + clean dependencies	Single overseas VPS relay
Migrating origins	Controlled cutover with dual run	Endless “temporary” tunnel
CI reaching China-only service	Private link or allowlisted jump	Developer laptops as relays

If a tunnel must exist tonight

1. Name an expiry (≤14 days unless platform approves extension) and a replacement epic.
2. Terminate TLS sanely — know passthrough vs re-encrypt; avoid random self-signed public endpoints.
3. Lock source access — SSO or strong auth, IP allowlists when possible; no open relay.
4. Log and rate-limit like other production ingress.
5. Keep customer PII off hobby tunnels without security review.
6. Monitor the relay host (disk, CPU, conntrack).
7. Decommission on the expiry date — calendar invite with a kill ticket.

Production replacement (the real path)

Public hostname strategy for China users → Mainland China termination or accepted overseas trade-offs → ICP / traffic alignment when hosting in-country → dependency audit → China vantage SLOs → on-call ownership that is not “whoever started ssh -R.”

Migration off a tunnel (once the edge exists)

1. Stand up the real China hostname/edge in parallel.
2. Move a canary path (one app route or one customer).
3. Compare logs and error budgets.
4. Flip DNS / app config.
5. Keep the tunnel in deny mode briefly for rollback.
6. Destroy the relay and revoke credentials — do not leave sleeper reverse shells.

A composite pattern from many launches: a reverse tunnel wins a Mainland China prospect demo; sales asks to “keep it for pilots”; months later the relay is the only path for design partners, certificates expire, and the only engineer with the SSH key is on leave. The postmortem always recommends a real China hostname — obvious on day one.

Linked reasoning

Demo success → sales “keep it for pilots” → production by default. Without an expiry and replacement project, the temporary EC2 becomes the China front door for a year.

Tunnel ≠ lawful public China service. A relay does not create an ICP-aligned hosting story. If you need filed Mainland China ingress, the tunnel is orthogonal — and sometimes contradictory — to that goal.

Employee ZTNA success ≠ customer checkout. Identity-aware access for your China team proves nothing about Mainland China customer ISP paths.

TLS re-encrypt → app breakage. Certificate pinning, sticky sessions, and WebSockets fail; mobile apps are especially unforgiving.

Vendor “China acceleration” without filing clarity → same bounce risk. Some products are private relays; others are licensed CDN. Read termination location, logging, and filing story — not the invoice branding.

Split-brain DNS after cutover → users stuck on the tunnel hostname. Drain DNS and HSTS carefully when the real China edge launches.

Difficulty and blockers

• Single-person knowledge — systemd unit + SSH key owned by one engineer on leave is a recurring outage class.
• Security exposure — reverse tunnels that expose internal admin UIs to the public internet. Prefer identity-aware access for humans; keep customer traffic on proper edges.
• Compliance theater — performance claims with no Mainland China ISP methodology; contracts that lock per-GB relay pricing with no path to CDN/hosting.
• Shadow tunnels during launches — without “no new public tunnels without security + platform approval,” every launch invents a worse relay.
• Migration without drain — stand up the real China hostname in parallel, canary one route, compare error budgets, flip DNS, keep the tunnel in deny mode briefly for rollback, then destroy credentials.

Language for stakeholders: replace “we tunneled China” with “we used a temporary relay for demo access; production China access is project X with date Y.” Clear language prevents procurement from buying a second tunnel when you needed a CDN/filing workstream.

A managed commercial tunnel can be a valid bridge during migration; it still needs a date when customer traffic moves to the long-term China edge design. Evaluate managed SKUs with the same questions as DIY: termination location, logging, filing story, SLA, and exit plan.

Red flags in vendor calls: “no filing needed for public China users at scale” without a clear legal basis; refusal to say where packets terminate; performance claims with no Mainland China ISP methodology; contracts that lock per-GB relay pricing with no path to CDN/hosting.

Add “no new public tunnels without security + platform approval” to engineering standards. Make the approved break-glass path easy so people stop inventing worse ones. No controls, no tunnel — even for demos.

China landing partner

Most product teams need a China landing partner to exit the relay — Mainland China edge, filing alignment, dependency hygiene, and operable on-call — not another SSH tutorial. Your team still owns the expiry decision; the partner path makes the production ingress executable when China-side rails are not already in-house.

What we can offer?

HTTP tunnels can unblock a demo or employee path overnight; they are not production China edge. Chinaready helps you use them as break-glass only and replace them with operable ingress before they calcify:

1. China Readiness Assessment — Classify tonight’s need (employee access, partner demo, or customer traffic) and name the replacement path and exit date before the relay becomes “architecture.”
2. China Access Acceleration — Build the Mainland China edge and dependency cleanup that demotes tunnels to emergency use only.
3. China Product Hosting — Place origins on filed, auditable Mainland China termination when that is the real production design your stakeholders need.
4. Mobile App Distribution — Keep app deep links and API hosts on the same China-reachable plan so a web tunnel exit does not leave the mobile journey broken.

Contact us when a tunnel is the only thing keeping China stakeholders online and you need the exit plan.