How to Put a Tokyo VPS in Front of a US or European Origin Server to Speed Up China Visitors
Your application runs on a server in Virginia or Frankfurt. It’s fast for everyone except visitors in mainland China, who see pages crawl in at peak hours and sometimes time out entirely.
Moving the whole stack to Asia is one answer, but it’s often not practical. The database, the deployment pipeline, the rest of your users, and maybe a compliance requirement all keep the origin where it is.
There’s a well-worn middle path: put a Tokyo VPS with premium China routing in front of your origin, acting as a reverse proxy and cache for Chinese visitors. This guide explains why that works, what it can and can’t fix, and how to set it up with Nginx.
Why a direct connection to a distant origin struggles
A visitor in Shanghai connecting directly to a server in the US crosses the Chinese international gateways on whatever path their carrier and your provider’s upstreams happen to choose. For many hosts, that’s the standard backbone, such as China Telecom’s 163 network (AS4134), which is heavily congested at evening peak.
Distance makes it worse. A round trip from Shanghai to the US East Coast is often 200 milliseconds or more on a good day, and every step of a new HTTPS connection costs at least one round trip. With TCP, TLS, and the first request, a single connection can take most of a second before any content arrives, and packet loss on the congested leg turns that into multiple seconds.
The two problems compound. A long path through a congested gateway means high latency and high loss at the same time, which is the worst combination for TCP.
How a Tokyo relay changes the path
With a Tokyo reverse proxy in place, the visitor’s connection ends in Tokyo. If the Tokyo server has premium routing back to China, such as CTGNet, CUP, and CMIN2, that leg is short, typically tens of milliseconds to eastern China, and it avoids the congested standard gateways.
The proxy then talks to your origin over a separate connection. That leg, Tokyo to the US or Europe, runs over ordinary international transit between well-provisioned networks, which is far less congested than the China gateways at peak.
Three things improve. TLS terminates in Tokyo, so the expensive handshake round trips happen over the short leg. The proxy keeps a pool of persistent connections open to the origin, so most requests don’t pay for a new handshake on the long leg at all. And cacheable content, such as images, CSS, JavaScript, and fonts, can be served straight from Tokyo without touching the origin.
What it can and can’t fix
A Tokyo relay fixes most of the connection setup cost and the congestion on the China leg. For a typical website, where a large share of the bytes are static assets, caching in Tokyo can make the bulk of a page load as fast as if the site were hosted there.
It can’t remove the distance for dynamic requests. A logged-in page, an API call, or a checkout still has to go from Tokyo to your origin and back. That leg is cleaner than the direct path, but it’s still 100 to 250 milliseconds depending on where your origin is.
Write-heavy and latency-sensitive applications benefit least. If every interaction hits the database and nothing can be cached, the relay mainly removes the handshake and congestion penalties. That’s still worthwhile, but don’t expect it to feel like a local server.
Before you start
You’ll need a Tokyo VPS with premium China routing, root access, and a domain where you can control DNS. On V.PS, the Tokyo Performance KVM VPS Gen 2 carries CTGNet, CUP, and CMIN2 routes to all three major Chinese carriers.
Check the route before you build on it. Run traceroutes from the V.PS looking glass to test addresses on China Telecom, China Unicom, and China Mobile, and look for premium networks rather than the standard backbones. Our explainer on China-optimized routes covers what to look for.
Also, think about bandwidth. Traffic through a proxy is counted on the way in from your origin and on the way out to your visitors, and V.PS counts transfer in both directions. Caching reduces origin traffic substantially, but size the plan with that in mind.
How to set up the Tokyo reverse proxy with Nginx
Install Nginx on your Tokyo VPS from your distribution’s packages or the official Nginx repository. Then configure a cache, an upstream pointing at your origin, and a server block for your domain.
Here’s a starting point for Nginx 1.25.1 or newer, with the HTTP/2 module available. Put these directives inside the http context, for example in an included site file. Install a valid certificate on Tokyo first and set the upstream hostname/IP to an origin address that won’t resolve back to the relay. The CA-bundle path below is for Debian/Ubuntu; adapt it on other distributions.
proxy_cache_path /var/cache/nginx/edge levels=1:2 keys_zone=edge:50m
max_size=10g inactive=7d use_temp_path=off;
upstream origin {
server origin.example.com:443;
keepalive 32;
}
server {
listen 443 ssl;
http2 on;
server_name example.com;
ssl_certificate /etc/ssl/example/fullchain.pem;
ssl_certificate_key /etc/ssl/example/privkey.pem;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_session_cache shared:SSL:20m;
location / {
proxy_pass https://origin;
proxy_http_version 1.1;
proxy_set_header Connection "";
proxy_set_header Host example.com;
proxy_ssl_server_name on;
proxy_ssl_name example.com;
proxy_ssl_verify on;
proxy_ssl_trusted_certificate /etc/ssl/certs/ca-certificates.crt;
proxy_ssl_verify_depth 3;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto https;
proxy_cache edge;
proxy_cache_bypass $http_authorization $http_cookie;
proxy_no_cache $http_authorization $http_cookie;
proxy_cache_use_stale error timeout updating http_502 http_503;
proxy_cache_lock on;
}
}The keepalive 32 line in the upstream, combined with proxy_http_version 1.1 and the empty Connection header, is what keeps persistent connections to the origin open. Without those, Nginx opens a new connection, and does a new TLS handshake over the long leg, for every request.
Nginx caching follows its proxy cache rules, not a guarantee that every response is safe to share. This example bypasses caching for requests with authorization headers or cookies. Make sure static assets are served with sensible Cache-Control headers, and that personalized pages send Cache-Control: private or no-store, so the proxy never serves one user’s page to another.
Tune the long leg
Enable BBR congestion control on the Tokyo server. BBR can help some long or lossy paths, but measure the result. On Tokyo it controls TCP data sent by Tokyo, including responses to China; it does not change the origin server’s congestion control for data sent toward Tokyo. Check that the kernel provides BBR and that the active qdisc is suitable before applying these settings:
echo "net.core.default_qdisc=fq" | sudo tee -a /etc/sysctl.d/99-bbr.conf
echo "net.ipv4.tcp_congestion_control=bbr" | sudo tee -a /etc/sysctl.d/99-bbr.conf
sudo sysctl --systemIf your origin is behind a firewall, consider a WireGuard tunnel between Tokyo and the origin. It gives you a private, encrypted path, lets you lock the origin’s web ports down to the tunnel only, and adds very little overhead.
Preserve visitor IPs and protect the origin
Your origin will now see every Chinese request as coming from the Tokyo server. To log and rate-limit by real visitor IP, configure the origin to trust the X-Forwarded-For header from your proxy’s address only. In Nginx on the origin, that’s set_real_ip_from with the Tokyo IP and real_ip_header X-Forwarded-For.
Then restrict the origin. If Chinese visitors are meant to go through Tokyo, there’s no reason to leave the origin wide open to everyone; at minimum, make sure it trusts forwarded headers only from the proxy, so nobody can spoof their IP by sending the header themselves.
Route only Chinese visitors through Tokyo
You don’t have to send all your traffic through Tokyo. GeoDNS lets you answer DNS queries from mainland China with the Tokyo IP and everyone else with your origin or existing CDN. Many DNS providers support location-based answers, and some let you target specific Chinese carriers.
Use a suitably low TTL to reduce DNS caching delays. Resolver caches, existing connections, and session state mean a cutover or rollback still won’t be instantaneous. A single VPS is a single failure domain, so for anything business-critical, add a second relay in Singapore and fail over between them with health-checked DNS.
Test the result from China
Measure before and after from inside China, on all three carriers, at evening peak. Use curl’s timing output to separate connection setup from content transfer:
curl -o /dev/null -s -w "tcp: %{time_connect}\ntls: %{time_appconnect}\nttfb: %{time_starttransfer}\ntotal: %{time_total}\n" https://example.com/You should see TCP and TLS times drop sharply, since those now happen over the short Tokyo leg. TTFB on cached content should fall close to the Tokyo round trip; on uncached dynamic pages, it’ll include the origin leg. Check Nginx’s cache hit ratio with the $upstream_cache_status variable in your logs to see how much is being served from Tokyo.
Wrapping up
A Tokyo reverse proxy is one of the most effective ways to speed up a US or European site for visitors in mainland China without moving your origin. It terminates TLS close to your users, keeps persistent connections to the origin, caches static content, and replaces a congested direct path with a premium China leg plus a clean international one.
It won’t make dynamic, uncacheable requests feel local, and it adds a server you have to run. But for most websites, it closes a large share of the gap for the cost of one VPS.
Thanks for reading! If you’re setting up a relay for Chinese visitors, V.PS runs KVM VPS on its own networks in 11 cities across 3 continents, and the Performance KVM VPS in Tokyo and Singapore carries CTGNet, CUP, and CMIN2 routing to all three major Chinese carriers, with a public looking glass so you can test before you buy.
Ready to get started? Deploy a server or contact our team if you need help choosing a plan.
Frequently asked questions about using a Tokyo VPS as a reverse proxy for China
Does a Tokyo reverse proxy really speed up a website for Chinese visitors?
For most websites, yes. TLS terminates over the short Tokyo leg, connections to the origin are reused, and static assets are served from the Tokyo cache, which removes most of the connection setup and congestion penalties of a direct connection.
Do I need an ICP license to run a reverse proxy in Tokyo?
No. ICP filing applies to sites hosted on servers inside mainland China. A server in Tokyo, including one acting as a reverse proxy, doesn’t need one.
Will dynamic pages be faster through a Tokyo proxy?
Usually somewhat faster, since the handshake happens close to the user and the origin connection is reused and avoids congested China gateways. They still have to travel from Tokyo to your origin and back, so they won’t feel as fast as cached content.
Should I use a reverse proxy or move my whole server to Tokyo?
If most of your users are in or near China and your stack can move, hosting in Tokyo directly is simpler and faster. If your origin needs to stay in the US or Europe for other users, data, or compliance, a Tokyo relay is the practical middle ground.
How do I keep the real visitor IP addresses on my origin?
Have the Tokyo proxy send X-Forwarded-For, and configure the origin to trust that header only from the proxy’s IP, using set_real_ip_from and real_ip_header in Nginx.
Does proxied traffic count against my bandwidth twice?
Traffic from the origin to the proxy and from the proxy to visitors both count, and V.PS measures transfer in both directions. Caching static content in Tokyo reduces the origin side significantly.
Share