Guess too low and you hit your limit mid-month, right when a campaign or release is driving traffic. Guess too high and you pay for premium capacity you never use.
This guide walks through how to estimate monthly bandwidth for a China-facing site, with worked examples for four common workloads, and covers the hidden traffic that catches people out.
These terms get mixed up, so it helps to separate them. Port speed, such as 1 Gbps, is how fast data can move at any instant. Monthly transfer, often called bandwidth on plan pages, is the total amount of data that moves over the month, measured in gigabytes or terabytes.
A fast port doesn’t mean a large transfer allowance. A 1 Gbps port running flat out would move over 300 TB in a month, far more than most plans include. What you need to estimate is total monthly transfer, then check that the port can handle your busiest moments.
Also check how your provider counts traffic. On V.PS, listed transfer counts both directions, inbound and outbound combined. Most web traffic is outbound, but uploads, backups pulled in, and proxy traffic all count.
For most sites, monthly transfer comes down to a simple multiplication: the average data sent per visit or request, times the number of visits or requests per month, plus overhead for everything that isn’t a real user.
The tricky part is the average. A first-time visitor downloads every image, script, stylesheet, and font. A returning visitor with a warm browser cache may download only the HTML. Your real average sits somewhere between the full page weight and the HTML-only weight, depending on how many visitors come back and how well your caching headers work.
You can find your full page weight in your browser’s developer tools. Open the Network tab, disable the cache, reload, and look at the total transferred.
Say a Chinese-language blog gets 30,000 pageviews a month. A full page load, with images and fonts, is 1.5 MB. About half of pageviews come from returning visitors whose browsers have cached most assets, so they transfer about 300 KB each.
The average works out to roughly 0.9 MB per pageview, so 30,000 pageviews comes to about 27 GB. Add 30% for crawlers, bots, feed readers, and other automated traffic, and you’re at around 35 GB a month.
That’s small. A content site rarely runs into transfer limits unless it serves large images without optimization or embeds self-hosted video.
A cross-border store gets 100,000 pageviews a month. Product pages are image-heavy, at around 3 MB for a first visit, and shoppers browse multiple products per session, so caching helps less with product images than with site-wide assets. Call the average 2 MB per pageview.
That’s 200 GB from pageviews. Add 25% for bots and crawlers, plus traffic from the admin panel, product image uploads, and order notifications, and the estimate lands around 260 to 280 GB a month.
Images are the lever here. Converting product photos to WebP or AVIF and serving correctly sized versions for mobile can cut the image share of that number by half or more.
A mobile app has 20,000 daily active users in China, each making about 150 API calls a day with an average response of 4 KB, and requests averaging 1 KB.
Responses come to 20,000 × 150 × 4 KB, or about 12 GB a day. Requests add about 3 GB a day. Over a 30-day month, that’s around 450 GB. If the app also serves images or media from the same server, add those separately.
APIs grow quietly. A new feature that polls every 30 seconds, or a response that starts including a large nested object, can increase transfer substantially. Enable gzip or Brotli where supported and measure the actual wire size; savings depend on the payload.
A software company distributes a 500 MB installer to customers in China, with about 3,000 downloads a month, plus updates.
That’s 1.5 TB from the installer alone. Failed and retried downloads, people downloading on multiple devices, and update packages can add 20% to 50% on top. For a 20% to 50% overhead range, budget approximately 1.8 to 2.25 TB a month.
Downloads dominate everything else. If you serve large files, estimate them separately and add the rest of the site on top. Our guide to serving large file downloads to mainland China covers how to make those transfers efficient.
Bots and crawlers are the biggest. Search engines, SEO tools, AI crawlers, uptime monitors, and vulnerability scanners can easily account for a quarter or more of all requests on a public site. Check your logs before assuming your traffic is all human.
Backups count if they leave the server. A nightly 10 GB backup pushed to off-site storage is 300 GB of outbound transfer a month. Incremental backups with tools like restic or borg cut that dramatically.
Reverse proxies count twice. If your server sits in front of an origin elsewhere, every uncached byte comes in from the origin and goes out to the visitor, and both directions count.
Then there’s the smaller stuff that adds up: package updates, Docker image pulls, log shipping to an external service, replication to a second server, and images hotlinked by other sites.
Sometimes you know your traffic as a rate rather than a total. A useful rule of thumb: 1 Mbps sustained around the clock for a 30-day month is about 324 GB.
So a server averaging 10 Mbps outbound over the month moves about 3.2 TB. Averages hide peaks, though, so check the busiest hours separately against your port speed. A China-facing site often has a sharp evening peak several times its daily average.
If the site already exists, measure it. vnStat is a lightweight tool that records interface traffic over time:
sudo apt install vnstat
vnstat -mAfter a few days, vnstat -m shows monthly totals and vnstat -d shows daily ones. Your web server logs tell you which content drives the traffic. For Nginx’s default combined log format, this sums response body bytes in the current log file. It excludes headers, inbound traffic, and rotated logs, so it is not the provider’s billing total:
awk '{sum += $10} END {printf "%.2f GiB\n", sum/1024/1024/1024}' /var/log/nginx/access.logBreak it down by file type or URL path, and you’ll usually find a small number of files responsible for most of the transfer.
Caching headers come first. Long cache lifetimes on versioned static assets mean returning visitors don’t download them again. Compress text responses with gzip or Brotli. Convert images to modern formats and serve responsive sizes.
Separate traffic by audience. Premium China routing is valuable for Chinese visitors but wasted on bots and visitors elsewhere. Serving non-Chinese traffic from a standard server, using GeoDNS to send only mainland visitors to your China-optimized server, keeps premium transfer for the users who need it.
Block or rate-limit abusive crawlers, and make sure large media files can’t be hotlinked by other sites.
Once you have an estimate, add 30% to 50% headroom. Traffic grows, campaigns happen, and you don’t want your busiest week to be the one where you hit your limit.
Check what happens when you exceed the limit. On V.PS, the Performance KVM VPS line, along with Nano and Storage, applies a port speed limit once transfer is used up, while other lines suspend service until the next month. Both are worth avoiding, but they affect your site very differently.
Finally, review usage monthly for the first few months. Real traffic is the best correction to any estimate.
Estimating bandwidth for a China-facing site comes down to average transfer per visit or request, multiplied by volume, plus overhead for bots, backups, and everything else. A blog might use tens of gigabytes a month, a store a few hundred, an API several hundred, and a download mirror terabytes.
Measure if you can, reduce what you can, keep premium routing for the traffic that needs it, and add headroom before you pick a plan.
Thanks for reading! If you’re sizing a server 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.
A small content site with tens of thousands of pageviews usually uses tens of gigabytes a month. Image-heavy sites, stores, APIs, and file downloads use far more.
Port speed is how fast data can move at any moment, such as 1 Gbps. Monthly bandwidth or transfer is the total amount of data moved over the month. You need enough of both, but they’re sized separately.
Yes. Listed transfer on V.PS plans counts both directions combined, so uploads, incoming backups, and proxy traffic count alongside outbound traffic.
About 324 GB, assuming 1 Mbps sustained continuously for a 30-day month.
It depends on the plan. On V.PS, Performance, Nano, and Storage plans apply a port speed limit, while other lines suspend service until the next month. Check your plan’s terms before you need them.
Premium carrier routes like CTGNet, CUP, and CMIN2 cost providers much more per gigabyte than ordinary transit. Plans with premium China routing usually include less transfer than standard plans at a similar price.
]]>Large file downloads stress a China route in a completely different way from web pages. A page load is dozens of short exchanges where latency dominates. A multi-gigabyte download is one long transfer where throughput dominates, and throughput on a long path is extremely sensitive to even small amounts of packet loss.
This guide explains what slows large file downloads to mainland China and how to configure a Tokyo VPS for more reliable transfers. The same principles apply across file types, including software releases, media archives, and backups.
TCP sends data in windows and waits for acknowledgments before sending more. The amount of data “in flight” at once, divided by the round-trip time, sets the maximum speed of a single connection. The longer the round trip, the more data you need in flight to fill the link.
That’s the bandwidth-delay product. To push 500 Mbps over an 80-millisecond path, a connection needs about 5 MB in flight at any moment. If the sender’s or receiver’s buffers are smaller than that, the connection can’t reach full speed no matter how fast the port is.
Loss is the bigger problem. Traditional congestion control, including Linux’s default CUBIC, treats every lost packet as a sign of congestion and cuts its sending rate. A well-known approximation, the Mathis formula, puts a single loss-based TCP connection’s throughput at roughly the segment size divided by the round-trip time, times 1.22 divided by the square root of the loss rate.
Plug in realistic numbers. With a 1,460-byte segment and an 80-millisecond round trip, the Reno-style approximation gives roughly 5.6 Mbps at 0.1% loss and 1.8 Mbps at 1% loss. These are illustrative estimates, not CUBIC throughput limits; CUBIC uses a different window-growth model. That’s why a route that feels perfectly fine for browsing can be painful for a big download.
China routes add exactly the conditions that hurt throughput. Standard international backbones into China see heavy congestion at evening peak, with loss rates that can climb into double digits. Even premium routes see some variation, and the domestic last mile adds its own.
Downloads also tend to happen at the worst time. Players download patches when they get home in the evening; offices pull datasets during the working day, and consumer releases often land right at peak. If your release goes out at 8 p.m. Beijing time, every user starts downloading during the most congested hours.
Long transfers also amplify connection drops. A 30-minute download has many more chances to hit a reset or timeout than a two-second page load, and without resume support, every failure means starting again.
Server tuning can make a good route faster; it can’t make a bad route good. Before anything else, check that your Tokyo server has premium routing to all three Chinese carriers and look at loss at evening peak.
Run traceroutes and sustained loss tests from the V.PS looking glass to addresses on China Telecom, China Unicom, and China Mobile. Aim for near-zero sustained loss at the destination under representative load. A few percent loss is already serious for a bulk TCP transfer; loss reported only by an intermediate router may instead be ICMP rate limiting. Our article on why packet loss predicts a bad China route covers how to read those results.
BBR is a congestion control algorithm developed at Google that estimates available bandwidth and round-trip time instead of reacting to every lost packet. On long paths with random loss, it typically sustains far higher throughput than CUBIC. Congestion control runs at the sender, so enabling it on your download server can help that direction. Results depend on the kernel, BBR version, bottleneck, and competing traffic; compare before and after.
Enable it with fq queuing:
cat <<'EOF' | sudo tee /etc/sysctl.d/99-downloads.conf
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr
net.core.wmem_max = 67108864
net.core.rmem_max = 67108864
net.ipv4.tcp_wmem = 4096 65536 67108864
net.ipv4.tcp_rmem = 4096 131072 67108864
EOF
sudo sysctl --systemThe buffer settings let each connection grow its window large enough to fill the path. The kernel still autotunes within those limits, so you’re raising the ceiling, not forcing every connection to use 64 MB.
First check that your kernel supports BBR, loading tcp_bbr if available, and inspect sysctl net.ipv4.tcp_available_congestion_control. Confirm the selected algorithm with sysctl net.ipv4.tcp_congestion_control. A changed default qdisc setting may not replace an existing interface qdisc, so inspect the active queue too. Then compare a download from China before and after; on a route with some loss, the difference is often dramatic.
Resume support is the single most important feature for large files. HTTP range requests let a client ask for “bytes 2,000,000,000 onward,” so a dropped connection picks up where it stopped instead of starting over.
Nginx supports range requests for static files out of the box. Make sure nothing in your setup breaks them: don’t serve large files through an application that ignores the Range header, don’t apply on-the-fly gzip to already-compressed archives, and make sure any proxy or cache in front passes ranges through.
Pair resume with integrity checks. Publish a SHA-256 checksum for every file, or a manifest of checksums for every chunk, so clients can verify what they downloaded and re-fetch only the parts that don’t match.
For a download system you control, split large files into chunks of a few megabytes to a few dozen, and publish a manifest listing each chunk and its hash.
Chunking has several benefits on a China route. Each chunk is a short transfer, so a failure costs a few megabytes rather than gigabytes. Clients can fetch several chunks in parallel, which spreads the impact of loss across multiple connections. And when you release an update, clients only download the chunks that changed.
For frequently updated files, delta transfers can reduce traffic further by sending only the differences between versions. Game patches and software updaters are common examples.
Because a single connection’s speed is limited by round-trip time and loss, several connections in parallel can achieve much more combined throughput. Download managers like aria2 and most game launchers do this by fetching different ranges or chunks at the same time.
Keep it reasonable. Four to eight connections per client usually captures most of the benefit. Dozens of connections per user can overwhelm your server’s port and are unfair to other traffic. If you control the client, set a sensible default; if you don’t, use Nginx’s limit_conn to cap connections per IP.
A few Nginx settings help with large files:
location /downloads/ {
root /srv;
sendfile on;
tcp_nopush on;
aio threads;
limit_conn perip 8;
limit_rate_after 100m;
limit_rate 25m;
add_header Cache-Control "public, max-age=31536000, immutable";
}sendfile lets the kernel copy files straight to the socket, and tcp_nopush sends full packets. aio threads stops large disk reads from blocking Nginx’s worker processes. The perip zone needs a matching limit_conn_zone $binary_remote_addr zone=perip:10m; in the http block.
The rate limit settings are optional. limit_rate_after 100m lets each connection run at full speed for the first 100 MB, then caps it at 25 MB per second. These limits apply per request, not per user. Several parallel requests can each receive the allowance, and customers behind carrier-grade NAT can share an IP. Use an aggregate bandwidth policy if you need a total cap; per-IP connection limits are only a rough guardrail.
Use versioned filenames, like patch-1.4.2.pak, with long cache headers. If you put a cache or CDN in front later, immutable files cache perfectly.
Large files use transfer quickly. A 4 GB file downloaded by 1,000 users is 4 TB of outbound traffic. Check your plan’s included transfer, and remember that V.PS counts transfer in both directions, so uploads to the server count too.
On the Performance KVM VPS line, exceeding your transfer limit slows the port rather than suspending the server, but a slowed port during a release is still a bad outcome. Estimate demand before launch and size up if needed.
Storage matters as well. Performance plans use NVMe sized for applications rather than archives, so if you keep many versions, plan a cleanup policy or keep older builds elsewhere.
A single Tokyo VPS with good routing and the tuning above can handle steady, moderate download demand. The practical limits are concurrent transfers, disk throughput, port capacity, and monthly transfer allowance, rather than the type of file being served.
It struggles with sudden, massive demand. If tens of thousands of users download the same release at the same moment, one 1 Gbps port becomes the bottleneck. At that point, look at multiple servers behind DNS, for example Tokyo plus Singapore, or a CDN. CDNs with nodes inside mainland China generally require an ICP filing for your domain, while offshore CDNs face the same international routing issues your server does.
Large file downloads to mainland China slow down because single TCP connections on long, lossy paths are throughput-limited, not because the server is slow. Start with a route that holds up at peak, enable BBR and larger TCP buffers, make every download resumable, split big releases into chunks with checksums, allow a sensible number of parallel connections, and plan bandwidth before launch.
With that in place, a single Tokyo VPS can deliver multi-gigabyte files to users across China far more reliably than default settings suggest.
Thanks for reading! If you’re distributing files to users in China, V.PS runs KVM VPS on its own networks in 11 cities across 3 continents, and the Tokyo Performance KVM VPS Gen 2 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.
A single TCP connection’s speed depends on round-trip time and packet loss, not just latency. Even small amounts of loss on a long path can cap a connection at a few megabits per second with default congestion control.
Usually, yes. BBR doesn’t treat every lost packet as congestion, so it sustains much higher throughput than CUBIC on long paths with some loss. It only needs to be enabled on the server sending the data.
Serve files as static files through a web server that supports HTTP range requests, such as Nginx, and make sure nothing in front of it strips the Range header. Publish a whole-file checksum to verify the completed download, or per-chunk checksums to verify individual partial downloads.
For files over a few hundred megabytes, yes. Chunks make failures cheaper, allow parallel downloads, and let update systems send only the parts that changed.
Not for steady, moderate demand; a well-routed, tuned VPS handles that well. For very large simultaneous releases, multiple servers or a CDN help, though CDNs with mainland China nodes generally require an ICP filing.
Multiply the file size by the number of downloads. A 4 GB file downloaded 1,000 times is about 4 TB of transfer, before retries, so check your plan’s included transfer before release day.
]]>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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
]]>Two days later, the complaints are back. Users say the site is still slow, sometimes doesn’t load at all, and the screenshots they send don’t look anything like your test results.
The test probes may use different networks, run at quieter hours, or measure only part of the page load. Real-user timings help show where those tests miss a problem.
Most multi-location China speed test services run their probes in data centers. A probe labeled “Shanghai Telecom” is usually a server in a Shanghai IDC, connected close to China Telecom’s backbone with business-grade connectivity.
Your users aren’t in data centers. They’re on home broadband or mobile networks, in apartments and offices, behind carrier-grade NAT, shared last-mile links, and Wi-Fi. The path from a residential connection to the carrier backbone adds latency, loss, and congestion that a data center probe never sees.
That last mile is often where the worst of the evening congestion happens, and it’s outside your control and outside most speed tests. A probe can tell you the route to the carrier’s backbone is clean; it can’t tell you what happens between that backbone and someone’s living room.
Most people run speed tests during their own working hours. If you’re in Europe or the US, that can miss the busiest Chinese hours; the exact overlap depends on your time zone and season, when networks are quiet.
Chinese consumer traffic peaks in the evening, roughly 8 p.m. to 11 p.m. local time, when international links on standard backbones are most congested. A route that shows 1% loss at 10 a.m. can show 15% at 9 p.m. A test at the wrong hour doesn’t measure the experience that’s generating complaints.
The fix is simple but easy to forget: schedule tests across a full day, and pay most attention to evening peak in China. Our piece on why packet loss predicts a bad China route covers why loss at peak tells you more than any average.
China’s three major carriers run separate networks, and routing quality differs a lot between them. A server with excellent routing to China Telecom can have mediocre routing to China Mobile, and vice versa.
If your test focuses on China Telecom probes, or a dashboard averages all three into one number, a poor route to one carrier disappears. China Mobile has the largest subscriber base of the three, especially on mobile, so a weak China Mobile path can affect a big share of your users while the averaged test looks fine.
Always break results out by carrier. Our article on why carrier routing matters more than location explains why one server can behave like three different servers depending on who’s connecting.
Many quick tests report ping. Ping uses ICMP, which routers and filtering equipment often handle differently from real web traffic, so a clean ping doesn’t guarantee clean TCP. It also only measures one round trip, not the dozens a real page load needs.
Throughput tests have their own blind spot. Many speed tests use multiple parallel connections, which can fill a link even when individual connections are struggling with loss. A browser loading your site opens a handful of connections, and each one feels the loss directly.
What users experience is the full page: DNS lookup, TCP and TLS handshakes, the HTML, then every image, script, stylesheet, and font. A test that fetches only the HTML, or only pings the server, measures a small slice of that.
This is often the biggest single cause of the gap. Your speed test checks your server, but your pages load resources from other servers too, and some of them are blocked or extremely slow from mainland China.
Google Fonts, Google Analytics, Google Tag Manager, reCAPTCHA, YouTube embeds, Facebook and X pixels, and many CDN-hosted libraries fall into this category. When a browser can’t reach one of them, it doesn’t fail instantly. It waits for a connection timeout, and if that resource blocks rendering, such as a font or a script in the page head, the whole page waits with it.
The result is a server that responds in 80 milliseconds and a page that takes 20 seconds to become usable. No server-side test will show that. Audit every external domain your pages load, and self-host or replace anything that doesn’t load reliably from China.
Your test probe may resolve your domain differently from your users. Many Chinese users rely on their carrier’s DNS resolvers, and if you use GeoDNS or a CDN, different resolvers can get different answers. DNS responses for some foreign domains can also be tampered with or slow inside China.
Caching skews results too. Repeated tests hit warm caches at the CDN, at the server, and sometimes in the test tool itself. A first-time visitor on a slow connection downloads everything cold.
The answer is real user monitoring, or RUM: collecting timing data from actual visitors’ browsers. Every modern browser exposes detailed timings through the Navigation Timing and Resource Timing APIs, including DNS, connection, TLS, time to first byte, and load milestones. Reused connections can show zero connection timings; cross-origin resource details require appropriate Timing-Allow-Origin headers. A load-event beacon also misses visitors whose page never loads or who leave early.
Because many common analytics tools load poorly from China, the most reliable approach is a small self-hosted beacon that sends timing data to your own server. Here’s a minimal version:
window.addEventListener('load', () => {
setTimeout(() => {
const t = performance.getEntriesByType('navigation')[0];
if (!t) return;
navigator.sendBeacon('/rum', JSON.stringify({
dns: t.domainLookupEnd - t.domainLookupStart,
tcp: (t.secureConnectionStart > 0 ? t.secureConnectionStart : t.connectEnd) - t.connectStart,
tls: t.secureConnectionStart > 0 ? t.connectEnd - t.secureConnectionStart : 0,
ttfb: t.responseStart - t.requestStart,
load: t.loadEventStart,
page: location.pathname
}));
}, 0);
});On the server, validate and rate-limit the beacon endpoint. If you use IPs to infer carrier, minimize retention and avoid logging sensitive URL paths; performance monitoring still needs an appropriate privacy basis and notice. Derive the carrier and discard or truncate the raw address where practical. Mapping IPs to their autonomous system tells you which carrier each visitor is on, so you can split results into China Telecom, China Unicom, and China Mobile. Record the hour too.
Look at percentiles, not averages. The median tells you what a typical visit feels like; the 90th and 95th percentiles tell you what your unhappiest users are experiencing, and that’s usually where complaints come from.
Synthetic tests are still useful, as long as you design them to match reality. Test at evening peak in China, not just your own working hours. Break results down by carrier and by region, including inland provinces, not just Beijing, Shanghai, and Guangzhou.
Test full page loads, not just pings or single requests. Some China-based testing services, such as ITDOG and 17CE, offer full-page or multi-step tests from many carrier and province combinations, which gets closer to real experience than a ping map.
When possible, add a real device. A phone on a Chinese mobile network, or a colleague or partner willing to share screenshots and timings, is often more revealing than another round of data center probes.
Once you know where the gap comes from, the fixes are usually clear. If third-party resources are the problem, self-host fonts and scripts and remove anything blocked. If one carrier is weak, look for a server with premium routing on that carrier, such as CMIN2 for China Mobile. If evening loss is the problem, the route itself is likely using a congested standard backbone.
Server location and routing set the floor. A China-optimized route on all three carriers can reduce international congestion, but still needs testing at peak, and everything else, from handshake tuning to asset trimming, builds on top of that.
A great China speed test and unhappy users can both be true at the same time. Probes sit in data centers, tests run at quiet hours, carriers get averaged together, ping isn’t page load, and blocked third-party resources hide behind a fast server response.
Measure real users with a self-hosted beacon, split results by carrier and hour, look at percentiles, and make synthetic tests match how your visitors actually connect. That’s how you find out what’s really slow.
Thanks for reading! If your measurements point to the route itself, 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. Every location has 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.
Speed test probes usually run in data centers, at times that may not match Chinese peak hours, and often only measure ping or a single request. Real users face last-mile congestion, evening peaks, carrier-specific routing, and third-party resources that may be blocked in China.
Test across a full day, with extra attention to evening peak in China, roughly 8 p.m. to 11 p.m. local time. That’s when standard international routes are most congested.
Many Google services are blocked or unreliable from mainland China. A browser waits for those requests to time out, and if they block rendering, the whole page waits. Self-hosting fonts and scripts removes the problem.
Real user monitoring collects performance data from actual visitors’ browsers using APIs like Navigation Timing. It shows what users experience on their own networks, rather than what a test server sees.
Yes. The three carriers run separate networks with different routing quality, and averaging them together can hide a poor route to one carrier that affects many of your users.
Not on its own. Ping uses ICMP, which can be handled differently from web traffic, and measures a single round trip. A page load involves many round trips and resources, so full page timing is more useful.
]]>China’s major national holidays produce some of the most predictable network congestion anywhere. Hundreds of millions of people travel, switch to leisure usage, and shift onto mobile networks at the same time, and domestic infrastructure provisioned for an ordinary weekday absorbs all of it at once.
The useful part is that this is schedulable. Unlike most performance problems, you know the dates in advance, which means the work is planning rather than firefighting.
Golden Week most commonly refers to the National Day holiday beginning October 1st, which runs about a week and is one of the two longest holiday periods in the Chinese calendar. Domestic travel volumes during it are enormous, and leisure internet use rises sharply across streaming, gaming, and social platforms.
Spring Festival, better known outside China as Chinese New Year, is the other major one. Its dates shift with the lunar calendar, generally falling in late January or February, and the surrounding travel period is longer than Golden Week’s. It’s frequently described as the largest annual movement of people in the world, and the network effects last well beyond the official holiday days.
The Labor Day holiday in early May is the third, shorter but still enough to show up in performance data. That gives you three predictable windows a year where China route performance runs measurably worse than baseline, though how much worse varies between them and from year to year.
The mechanism is ordinary congestion at unusual scale. Video streaming, mobile gaming, social media, and e-commerce traffic all spike simultaneously, competing for domestic capacity sized around typical weekday demand rather than holiday peaks.
The mobile shift matters more than people expect. Travelers move off home broadband and onto mobile networks, often in locations that don’t normally carry that load, so congestion doesn’t just increase, it relocates. A route that performs well to a first-tier city can degrade toward smaller cities and towns that suddenly have far more connected people than usual.
Crucially, most of this lands in the last mile rather than on your international leg. Your traffic still crosses into China on the same carrier path with roughly the same performance; the bottleneck moves to the shared domestic segment between the carrier’s network and the user’s connection. That’s why a well-optimized premium route can still deliver a worse experience during these weeks, and why the fix isn’t “buy a better route.”
The three national holidays are National Day, the week-long break usually called Golden Week, in early October, Spring Festival in late January or February, and Labor Day in early May. Those are the windows where the congestion is broad and consumer-driven, and the exact dates shift year to year, so it’s worth checking the schedule the State Council publishes each year rather than assuming last year’s dates.
Two commercial events deserve separate mention because they affect a different kind of business. Singles’ Day on November 11th and the mid-year 618 event on June 18th aren’t national holidays, but they generate enormous e-commerce and payment traffic. If you run a storefront, a payment integration, or anything transactional aimed at Chinese consumers, these matter more to you than Labor Day does.
It’s worth noting the asymmetry: the national holidays hit general consumer internet usage, while the shopping festivals hit transaction processing and checkout flows specifically. Which set you care about depends on what your service does.
The first implication is measurement discipline. Benchmarking your route during an ordinary week and treating that as your expected performance produces a number you can’t hold during the periods that matter most. Any capacity or SLA planning should account for the holiday windows explicitly rather than averaging them away.
The second is scheduling. Avoid launching, migrating, or making significant infrastructure changes during these windows if you have the choice. Not because the changes are riskier in themselves, but because diagnosing anything is harder when baseline conditions are already abnormal, and you’ll spend time separating your change from the congestion.
The third is staffing and communication. If your support team fields performance complaints, they should know these dates and have a short explanation ready, because the complaints will arrive and “we’re investigating” is a worse answer than an accurate one. Letting customers know in advance that a known congestion period is coming also converts a surprise into an expectation.
It’s worth being precise about what routing can and can’t do here. A premium carrier path raises your baseline, so you start the holiday from a better position than a generic route would, and fewer congested handoffs on the international leg means less compounding on top. What it can’t do is reduce the holiday delta itself, because that congestion lives in the shared domestic segment every service is competing for. Expect a better floor, not an exemption.
Monitoring through the windows is the highest-value practical step. Capture latency, jitter, and loss during Golden Week and Spring Festival, and keep that data, since year-over-year comparison for the same period is far more informative than comparing a holiday week against a normal one. After two years you have a genuine baseline for what to expect.
On the application side, a few adjustments absorb variance rather than fighting it. More generous timeouts and retry logic during known windows prevent a slow response from becoming a failed one, aggressive caching of static assets reduces how many round trips depend on the congested path at all, and deferring non-essential background sync work away from peak hours frees capacity for what users are actually waiting on.
Golden Week, Spring Festival, and China’s major shopping events are recurring, predictable windows where domestic network congestion rises and China-facing performance drops. None of it is an anomaly, and none of it indicates something is broken.
Plan for the dates, measure through them so you know your own numbers, and set your application’s timeouts and your team’s expectations accordingly. That turns three annual periods of unexplained incidents into three periods of known, communicated variance.
Thanks for reading! Whether you’re planning around a holiday window in advance or working out what happened after the fact, recognizing congestion for what it is keeps you from chasing the wrong fix. If you’re looking for fast, no-nonsense infrastructure, V.PS runs KVM VPS on its own networks in 11 cities across 4 continents, with a public looking glass so you can test before you buy. For China-facing workloads specifically, the Performance KVM VPS in Singapore and Tokyo Gen 2 carries CTGNet, CUP, and CMIN2 routing to all three major mainland carriers.
Ready to get started? Deploy a server or contact our team if you need help choosing a plan.
Mostly the domestic last mile. Your international leg into China typically performs close to normal, but the shared segment between the carrier’s network and the end user carries far more load, which is what users experience.
Roughly the length of the holiday, so about a week for Golden Week, and longer for Spring Festival given its extended travel period on both sides of the official dates.
Not quite. They’re commercial shopping events rather than national holidays, and they concentrate on e-commerce and payment traffic. They matter most for transactional services rather than general consumer applications.
Generally yes, where you have the choice. The risk isn’t that deployments are inherently more dangerous, it’s that separating a problem caused by your change from a problem caused by congestion is much harder when the baseline is abnormal.
No. It reduces exposure by keeping traffic on better-provisioned infrastructure for more of the journey, but the domestic congestion during these windows is a shared-capacity issue that no single route can route around.
Check whether the timing lines up with a known holiday window first, then compare against your own data from the same period in a previous year if you have it. A degradation that starts and ends with the holiday and affects the last-mile hops is a congestion pattern, not a routing change.
]]>For services with significant traffic from mainland China, that outcome is more likely than most default configurations account for, and the cause is structural rather than a tuning mistake. The assumption underneath per-IP rate limiting doesn’t hold as well there.
This piece covers why that assumption breaks, how the resulting failure looks from the support queue, and what to change so abuse protection keeps working without catching real users in the same net.
Per-IP rate limiting encodes an assumption: one IP address corresponds roughly to one user, or at most one household. Under that assumption, a threshold like a hundred requests per minute per IP is a reasonable proxy for “one client behaving unreasonably.”
The assumption is approximately true in places where IPv4 addresses are relatively plentiful relative to population, and it’s considerably less true in mainland China. There, the ratio of subscribers to available IPv4 addresses is far less favorable, and the network architecture built in response means shared addressing is the norm rather than an exception.
Once the assumption breaks, the meaning of your threshold changes without you changing anything. A limit that was measuring one user’s behavior starts measuring the aggregate behavior of an unknown number of unrelated users who happen to share an exit point.
Carrier-grade NAT, usually shortened to CGNAT, is the mechanism. Rather than assigning each subscriber a unique public IPv4 address, a carrier routes many subscribers through a shared pool of public addresses, translating between the private addresses used internally and the public ones seen from outside. It’s a standardized arrangement rather than an improvisation: RFC 6598 set aside dedicated address space for it, and RFC 6888 documents the behavior operators are expected to implement.
The practical consequence is that your server may see hundreds or thousands of distinct users arriving from a small set of addresses. Worse for rate limiting purposes, the mapping isn’t stable: a single user’s requests can appear from different addresses in the pool over time, while simultaneously other users appear from the address you just saw.
This is particularly relevant for China because internet use there skews heavily mobile, and mobile carriers are among the most aggressive users of CGNAT. Corporate networks, university campuses, and public Wi-Fi produce shared-IP traffic of their own through ordinary NAT, and can sit behind carrier NAT as well. The mobile carrier case is the one most likely to dominate your traffic mix, in a market where reaching those users well is already a routing problem before it becomes a rate-limiting one.
The failure is quiet, which is what makes it expensive. Your limiter is working exactly as configured; it’s the interpretation of the input that’s wrong. A hundred requests per minute from an address representing four hundred users is completely normal traffic that looks, to the limiter, like a single client hammering an endpoint.
From the support queue it presents as confusing reports: users describing entirely ordinary usage who are seeing 429 responses, throttling, or CAPTCHA challenges. Because each individual user’s behavior is unremarkable, investigating any one report finds nothing wrong, which is how this often goes unresolved for a long time.
It also concentrates during peak hours, when the largest number of users behind a given address are simultaneously active. So the periods where your service most needs to work well are precisely the periods where legitimate users are most likely to be caught, which is a bad pattern for a consumer-facing product.
The highest-value change is moving your limits off raw IP wherever an identity is available. Authenticated user IDs, session tokens, and API keys all identify the actual client making requests, so a limit keyed on them measures the thing you meant to measure regardless of how many users share a network path. For any authenticated endpoint, this is straightforwardly the right approach.
For unauthenticated endpoints where you have no identity to key on, IP-based limiting is unavoidable, so the goal becomes making it less blunt. Set thresholds high enough to accommodate a shared exit point rather than a single household, and treat request pattern as the primary abuse signal rather than volume, so that a suspicious shape is enough to act on while high volume alone is not.
That distinction is the conceptual core of it. High volume from one address is expected behind CGNAT and tells you very little, while an unusual shape indicates automation even at modest volume. Identical request bodies, a perfectly regular interval, and sequential enumeration of IDs are all good signals. Login attempts spread across many accounts is weaker than it looks, since hundreds of unrelated people signing into their own accounts from one CGNAT address produce exactly that pattern; what distinguishes an attack there is the failure rate per account, not the number of accounts touched.
It’s also worth separating your responses by severity. Blocking outright is the harshest option; tar pitting, progressive delays, or a challenge page degrade gracefully and give a legitimate user behind a busy CGNAT address a path forward rather than a wall.
The same dynamics make blunt IP range blocking more costly than it appears. Blocking a single address in a region with heavy CGNAT can silently cut off a large number of unrelated users, and blocking a range can affect a disproportionate share of a country’s mobile subscribers.
This shows up in a specific and avoidable way: an automated abuse-mitigation rule blocks an address after detecting a burst of bad requests, and the collateral effect is that a large group of legitimate users on the same carrier lose access with no explanation. If your mitigation tooling escalates to range blocks automatically, it’s worth reviewing what those rules can actually reach in a CGNAT-heavy region.
A more proportionate approach is to keep automated blocks short-lived, log what they caught so you can review whether the decision was sound, and require human review before anything wider than a single address gets blocked for an extended period.
Per-IP rate limiting works well when one address means one user. In mainland China, where CGNAT is widespread and usage is heavily mobile, that mapping is much weaker, and a threshold that looks reasonable can end up measuring a crowd instead of an individual.
Shift to authenticated, per-user limits wherever an identity exists, raise and supplement IP-based limits where it doesn’t, and treat request patterns rather than raw volume as your abuse signal. That keeps the protection meaningful while avoiding the quiet failure of blocking the users you were trying to serve.
Thanks for reading! Whether you’re protecting an API or a login form, limits that account for shared addressing hold up far better than limits that assume one address means one person. If you’re looking for fast, no-nonsense infrastructure, V.PS runs KVM VPS on its own networks in 11 cities across 4 continents, with a public looking glass so you can test before you buy. For China-facing workloads specifically, the Performance KVM VPS in Singapore and Tokyo Gen 2 carries CTGNet, CUP, and CMIN2 routing to all three major mainland carriers.
Ready to get started? Deploy a server or contact our team if you need help choosing a plan.
It’s an arrangement where a carrier routes many subscribers through a shared pool of public IP addresses instead of giving each one its own, translating between internal private addresses and the public ones your server sees. The result is that many unrelated users appear to come from the same address.
Internet use in China skews heavily mobile, and mobile carriers there make extensive use of CGNAT given the ratio of subscribers to available IPv4 addresses. A meaningful share of legitimate traffic can therefore arrive from a small number of shared addresses.
For endpoints where a user is logged in or presenting an API key, yes, because it measures the actual client rather than the network path. IP-based limiting remains necessary for unauthenticated endpoints, where the goal is making it less blunt rather than removing it.
Look for support reports describing normal usage alongside throttling or block responses, and check whether the flagged addresses belong to mobile carrier ranges. Blocks that cluster during peak hours, when more users share each address, are another strong indicator.
Raising thresholds helps, but on its own it weakens abuse protection. Pairing a higher IP threshold with a pattern-based signal keeps protection meaningful, since automated abuse is usually identifiable by request shape rather than by volume alone.
No, CGNAT is used by carriers worldwide and the same dynamics apply anywhere shared addressing is common. It’s simply most pronounced for services with a substantial mainland China user base, which is why it’s worth reviewing specifically in that context.
]]>The metric that explains the difference is jitter, and it’s routinely left out of the comparison when people evaluate a China route. Average latency is easy to measure and easy to quote, which is exactly why it ends up on marketing pages while the more revealing number doesn’t.
This piece covers what jitter actually is, why China routes generate more of it than most paths, which workloads it breaks first, and how to measure it properly rather than inferring it from a ping average.
Latency is how long one packet takes to make the trip. Jitter is how much that duration varies from packet to packet.
A route averaging 150 milliseconds where nearly every packet lands between 145 and 155 is predictable, and applications can plan around it. A route averaging 100 milliseconds where packets arrive anywhere between 60 and 300 is unpredictable, and the better average is cold comfort for anything that needs a steady stream.
The reason this matters mechanically is that real-time protocols buffer. A receiver playing back audio or video holds a small amount of data to smooth out arrival variance, and that buffer is sized for expected jitter. When variance exceeds what the buffer absorbs, the application either stalls waiting for a late packet or discards it and plays a gap. Either way the user notices, and the average latency never showed it coming.
Averaging is lossy by design. It compresses a distribution into one number, and two very different distributions can produce identical averages, which is precisely the situation that catches people out.
There’s a second problem specific to how latency usually gets measured. A quick ping run sends a handful of packets over a few seconds, which is a small sample from a narrow time window. Congestion on China routes tends to arrive in waves rather than as a constant offset, so a ten-packet sample can easily land entirely inside a calm stretch and report a number you can’t reproduce an hour later.
The combination is why a route can test well and perform badly. You measured a smooth moment, summarized it into an average, and then deployed an application whose experience depends on the rough moments you didn’t sample.
Three things stack up here. The first is path length and hop count: a route from a Tokyo or Singapore server into a Chinese provincial network passes through more distinct networks than a domestic route would, and each handoff between differently-loaded networks is a place where queuing delay gets introduced independently.
The second is congestion timing. Domestic Chinese networks see pronounced daily peaks, and congestion that comes and goes produces variance rather than a flat penalty. A link running near capacity doesn’t slow every packet equally; it queues some and not others, which is jitter by definition.
The third is the inspection layer at the border. Traffic crossing into China passes through filtering infrastructure, and processing that isn’t uniformly instantaneous adds another source of variable delay on top of the ordinary queuing.
None of these are exotic failures. They’re the normal operating characteristics of the path, which is why jitter on a China route is something to measure and plan around rather than treat as a fault to be eliminated.
Voice and video calls are the most sensitive. Jitter above roughly 30 milliseconds starts becoming audible as choppiness or sync drift, because a packet that misses the buffer’s playback deadline gets discarded even though it arrived. Running over UDP means there’s no retransmission to fall back on either, so a packet that never arrives is simply gone.
Live multiplayer games are next. Inconsistent arrival times cause position updates to land irregularly, which surfaces as rubber-banding and inconsistent hit registration. Players tolerate a consistently high ping far better than an erratic one, which is why a game can feel worse on the route with the better average.
Streaming and any continuous data feed sit in a similar category: live video buffers can underrun, and real-time bidding or market data can arrive stale enough to be useless even though it arrived.
The contrast case is worth stating too, because it explains why some teams never notice jitter at all. A standard page load or a batch API call is a short exchange where one late packet costs a few milliseconds of total completion time and nothing visible happens. If your workload is entirely request-response, jitter matters much less than average latency and loss do.
Use a sustained sample rather than a quick ping. Several minutes of continuous measurement gives you a distribution instead of a snapshot, and the useful outputs are the standard deviation of round-trip time and the spread between your best and worst measurements, not the mean. Real-time media tooling measures this more formally, using the interarrival jitter calculation defined in RFC 3550, the standard behind RTP.
MTR is the practical tool for this, because it reports per-hop statistics over a running sample. Watching where variance first appears along the path tells you whether jitter is entering on the international leg or in the final domestic hops, and those two findings lead to different responses.
One caveat applies here just as it does to packet loss: many routers deprioritize replying to probe packets while forwarding real traffic normally, so variance at a single intermediate hop is often an artifact. Trust it when it persists through every hop after it, not when it appears at one hop and vanishes at the next.
Test at more than one time of day. Given that congestion on these paths is strongly time-dependent, a single sustained test still only characterizes one window, so the one that matters is whenever your own users are actually online. For a consumer service that’s usually evening peak; for a B2B or API-facing service it’s Chinese business hours, which behave differently.
If you want a starting point without setting anything up, V.PS publishes a looking glass for every location, which covers ping and traceroute from the server side. Treat any single reading as one data point, since the whole argument of this article is that one sample doesn’t characterize a variable path.
Fewer handoffs is the main lever. A carrier-optimized route keeps traffic on a single carrier’s backbone for a longer stretch of the path, which removes transitions between differently-congested networks, and each transition removed is one less independent source of variance. This is the structural reason premium carrier routing helps with consistency and not just with raw speed.
Matching the route to the carrier your users are actually on matters for the same reason. China Telecom, China Unicom, and China Mobile run separate networks, and a premium path on one of them does nothing for a user sitting on another, who ends up taking a generic path with more handoffs.
Location choice contributes as well. A server genuinely close to your user base involves fewer hops overall. Beyond the network, your application can also absorb variance: increasing a jitter buffer slightly, using connection reuse so you’re not paying handshake costs repeatedly, and preferring fewer round trips all reduce how much a variable path shows through to the user.
Average latency tells you how fast a route is. Jitter tells you how consistent it is, and for anything real-time, consistency is what users actually perceive.
If a China-facing application feels unreliable despite a route that looks acceptable on paper, measure the spread rather than the mean, do it over several minutes, and do it at the time of day your users are online. That’s usually where the missing explanation is.
Thanks for reading! Whether you’re serving real-time media or a straightforward web app, how consistent a route is matters as much as how fast it looks on average. If you’re looking for fast, no-nonsense infrastructure, V.PS runs KVM VPS on its own networks in 11 cities across 4 continents, with a public looking glass so you can test before you buy. For China-facing workloads specifically, the Performance KVM VPS in Singapore and Tokyo Gen 2 carries CTGNet, CUP, and CMIN2 routing to all three major mainland carriers.
Ready to get started? Deploy a server or contact our team if you need help choosing a plan.
No. Latency is how long a packet takes to arrive, and jitter is how much that time varies between packets. They move independently, which is why a route can have a good average and poor consistency at the same time.
Yes, and on congested China paths it’s a common combination. It’s also the worst case for real-time traffic, because the attractive average encourages you to deploy on a path that can’t hold a steady stream.
Under roughly 30 milliseconds is generally considered good for real-time voice and video. The practical threshold depends on how much buffering the application does, since a larger jitter buffer absorbs more variance at the cost of added delay.
Run a sustained MTR or ping sample over several minutes and look at the standard deviation and the spread between best and worst results rather than the average. Repeat it at different times of day, since congestion on these paths is strongly time-dependent.
It improves consistency meaningfully by reducing the number of network handoffs along the path, but it can’t control the final domestic hops inside China. Those remain outside any foreign host’s reach regardless of how good the international leg is.
A page load is a short request-response exchange where one late packet adds a few milliseconds and nothing visible happens. Real-time media depends on packets arriving at steady intervals, so variance translates directly into audible or visible artifacts.
]]>Packet loss is the better predictor, and it’s frequently the metric that’s missing when someone says a route “tested fine” and then disappointed in production. The reason is mechanical rather than a matter of opinion: loss and latency interact on long paths in a way that makes a small loss percentage far more expensive than it looks.
This piece covers what loss actually does to throughput, why China routes generate it in specific places, what thresholds are worth acting on, and how to measure it in a way that catches intermittent patterns.
Packet loss is the proportion of packets that never arrive, or that arrive so late they’re treated as lost. It’s a different measurement from latency, which is how long successful packets take, and from jitter, which is how much that duration varies.
The three metrics can move independently, and a route can look healthy on one while failing on another. That independence is exactly why checking only the most quotable one produces surprises.
Loss also has a dominant cause worth keeping in mind: routers under load drop packets when their queues fill. That makes most loss a capacity signal rather than random degradation, which is part of why it predicts trouble better than latency creeping upward does.
The first reason is selection. Latency figures from ping and traceroute describe the packets that completed a round trip. Packets that vanished contribute nothing to the average, so a route dropping eight percent of traffic can report a very similar average latency to one dropping none, because you’re measuring the survivors either way.
The second reason is the one that actually matters for throughput. TCP recovers from loss by retransmitting, and a retransmission costs a full additional round trip. On a domestic path with 15 milliseconds of latency, recovering a lost packet is nearly free. On a path to China at 150 milliseconds, every recovery costs 150 milliseconds or more, so the same loss percentage produces roughly ten times the practical penalty.
TCP’s congestion control compounds it further. Loss is interpreted as a congestion signal, so the sending rate backs off and then rebuilds gradually. A route with steady low-level loss keeps triggering that backoff, which means throughput settles well below what the available bandwidth would suggest. This is why a 1 Gbps port can deliver disappointing transfer speeds to China on a lossy path: the bottleneck is the loss, not the port.
The most common source is congestion at domestic peering and handoff points. These are shared, heavily used links, and during peak hours their queues fill, which produces exactly the kind of loss that’s worst for long-haul TCP.
The last-mile segment inside China contributes as well, particularly on mobile networks where conditions vary by cell load and signal quality. This portion sits outside the reach of any foreign host, which is why a genuinely excellent international leg can still terminate in a lossy final hop.
The border inspection layer adds a third possibility. Traffic crossing into China passes through filtering infrastructure, and under load that processing can drop rather than merely delay, especially for traffic patterns that draw extra scrutiny.
Worth noting: loss on a China route is often intermittent rather than constant, appearing in bursts aligned with congestion peaks. That burstiness is precisely what a short test misses.
MTR is the right tool, because it runs continuously and reports loss per hop rather than only end to end. That per-hop view is what localizes the problem: if loss appears at hop twelve and persists through the remaining hops, something at hop twelve is dropping packets, and you now know whether it’s on your side of the border or theirs.
One caveat that trips people up constantly: isolated loss at a single intermediate hop, with zero loss at hops after it, is usually not real. Many routers deprioritize responding to the probe packets MTR uses while forwarding actual traffic normally, so they report loss that traffic never experiences. Loss that matters shows up at a hop and continues through every hop after it.
Run for several minutes rather than a few seconds, and repeat at different times of day. Given how bursty loss is on these paths, a thirty-second sample can easily land between bursts and report a clean result you can’t reproduce. V.PS publishes a looking glass at every location for ping and traceroute from the server side, which is a good starting point as long as you treat one reading as a single sample rather than a characterization.
Below about half a percent, loss is largely unremarkable and most applications won’t show it. Between one and two percent, real-time traffic starts degrading noticeably and bulk transfer throughput drops more than the number intuitively suggests, for the retransmission reasons above.
Above roughly three percent on a sustained basis, you’re looking at a route with a genuine problem rather than normal internet behavior, and it’s worth investigating or changing rather than accepting. Real-time media is the least tolerant, since UDP-based voice and video don’t retransmit at all and a lost packet becomes an audible gap.
Pattern matters as much as magnitude. Brief loss spikes during known peak hours are normal for China routes and mostly a capacity-planning matter. Steady loss present even during quiet overnight windows suggests something structural in the path, and that’s the case where changing carrier route or location is likely to actually help.
The main lever is reducing exposure to congested shared links. A named, carrier-optimized route keeps traffic on a premium backbone for more of the path, which means fewer of the oversubscribed handoff points where queue-drop loss occurs. Matching that route to the carrier your users are actually on, China Telecom, China Unicom, or China Mobile, matters for the same reason, since a premium path on the wrong carrier leaves those users on a generic one.
Testing before committing is the other half, and it’s the part that’s easy to skip. Run a real sustained MTR against a provider’s looking glass rather than relying on a one-line ping figure from a sales page, and do it at the hours your users will actually be online.
On the application side, a few things reduce how much loss hurts even when you can’t remove it. Enabling modern TCP congestion control designed for lossy long-haul paths helps throughput hold up better under intermittent loss, connection reuse avoids repeatedly paying handshake costs on a path where a lost handshake packet is expensive, and reducing the total number of round trips a page or API interaction requires shrinks the number of opportunities for loss to bite.
Latency tells you how fast a route feels when it’s working. Packet loss tells you how often it isn’t working, and on a long path that distinction drives far more of the real experience than the average latency does.
If a China route feels unreliable despite acceptable-looking latency, run a sustained MTR, read the per-hop loss column, and check whether the loss persists through subsequent hops. That single measurement usually explains what the latency average was hiding.
Thanks for reading! Whether you’re testing a new location or re-checking one you’ve run for years, sustained loss tells you more about a route than a single latency figure ever will. If you’re looking for fast, no-nonsense infrastructure, V.PS runs KVM VPS on its own networks in 11 cities across 4 continents, with a public looking glass so you can test before you buy. For China-facing workloads specifically, the Performance KVM VPS in Singapore and Tokyo Gen 2 carries CTGNet, CUP, and CMIN2 routing to all three major mainland carriers.
Ready to get started? Deploy a server or contact our team if you need help choosing a plan.
Under about half a percent is common and rarely noticeable. Between one and two percent starts affecting real-time traffic and bulk throughput, and sustained loss above roughly three percent indicates a route problem rather than ordinary internet behavior.
Yes, and it’s the case that catches people out. Latency statistics only describe packets that completed the trip, so lost packets are invisible in the average, and a lossy route can report the same latency as a clean one.
Because every retransmission costs a full round trip. Recovering a lost packet on a 15 millisecond domestic path is negligible; on a 150 millisecond path to China it costs ten times as much, and TCP’s congestion backoff reduces throughput on top of that.
Run a sustained MTR for several minutes and read the per-hop loss figures, repeating at different times of day. Ignore loss that appears at one hop and disappears at later hops, since that usually reflects a router deprioritizing probe replies rather than actually dropping traffic.
No, but it reduces the number of congested shared handoff points traffic has to cross, which is where most avoidable loss occurs. The final domestic hops inside China remain outside any foreign provider’s control.
They answer different questions, so neither replaces the other. Loss is usually the better early warning for a route that will disappoint in production, while latency is the better predictor of how responsive a working route will feel.
]]>Standard international transit to and from mainland China tends to route through congested peering points, often bouncing through several intermediary networks before reaching its destination. For any service with a real audience in or connected to mainland China, whether that’s a website, a game server, or an application backend, this shows up as elevated and inconsistent latency that a fast server and a well-optimized application can’t fix on their own, since the bottleneck sits in the network path, not on either endpoint.
Performance KVM VPS in Tokyo and Singapore now includes routing designed specifically to minimize that bottleneck across all three major Chinese carriers: CTGNet for China Telecom, CUP for China Unicom, and CMIN2 for China Mobile. In practical terms, this means traffic on these optimized routes stays on well-connected carrier backbones for a longer portion of the journey, avoiding the peering points that cause the worst congestion on standard international routes. The result is lower, more consistent latency for China-facing traffic, particularly noticeable during periods that would otherwise see congestion-driven slowdowns on a standard route.
Both locations were already strong choices for Asia-Pacific hosting generally, well-connected, low-latency to a broad regional audience, and each offers a genuinely different profile worth understanding rather than treating as interchangeable.
Tokyo’s network runs on AS3258 with direct upstream relationships to China Telecom, China Unicom, and China Mobile, the same CTGNet, CUP, and CMIN2 routes covered above, alongside peering at BBIX Tokyo, JPNAP Tokyo, and Equinix IX, giving it strong, direct paths into all three major Chinese carrier networks.
Singapore brings a different advantage: proximity to China combined with a jurisdiction outside mainland Chinese regulatory reach, plus dense connectivity to the rest of Southeast Asia for services with a broader regional audience beyond China specifically.
Having the option to route through either location gives customers flexibility to choose based on their specific latency needs, regulatory preferences, or broader regional audience, rather than a one-size-fits-all answer.
This update matters most if your service has a meaningful volume of users, players, or traffic connecting from mainland China, or connecting through Chinese carrier networks more broadly. If China-facing traffic is a small or occasional part of your overall audience, the benefit will be proportionally smaller, though it costs nothing extra to have access to the improved routing where it’s available.
Existing customers on our Singapore or Tokyo Gen 2 Performance KVM VPS already have CTGNet, CUP, and CMIN2 routing active, nothing to enable. New customers can order either Performance plan directly and get the same routing from day one.
We want to be direct about scope here: optimized routing improves the network path, it doesn’t change the underlying physics of distance entirely, and it won’t deliver identical performance to every region within mainland China equally, since route quality can vary by specific destination even on a well-optimized path.
It also doesn’t substitute for adequate server resources on your end. A well-routed but underpowered instance will still perform poorly for reasons unrelated to the network path. We’d rather you go in with an accurate picture of what this update does than an inflated one.
Rather than asking you to take our word for it, we’d encourage testing this directly. Run a traceroute from a Chinese IP address, or use a public looking glass tool if you have access to one, and compare the results against what you’d expect from standard international transit to the same destination. A genuinely optimized route should show fewer hops and more consistent latency, particularly during periods that would typically see the worst congestion on a standard path.
This update is aimed squarely at customers who’ve felt the specific pain of poor China-facing network performance and haven’t had a straightforward way to address it without adding complexity to their infrastructure. If that’s you, it’s worth testing the improved routing directly rather than assuming based on this announcement alone, and our team is available to help confirm it’s active and answer any questions about how it applies to your specific setup.
Ready to see the difference? V.PS’s Performance KVM VPS includes CTGNet, CUP, and CMIN2 routing in both Singapore and Tokyo Gen 2, with transparent specs and no oversold resources.
No. The routing improvement happens at the network level and is already active on every Performance KVM VPS in Tokyo and Singapore, nothing to enable in your server’s configuration.
No, it’s specific to our Performance KVM VPS line in Tokyo and Singapore. Other plan tiers in those cities, and all other locations, aren’t part of this rollout, since the optimized routing depends on carrier relationships and infrastructure specific to the Performance line in these two cities.
No, it’s included on every Performance KVM VPS plan in Tokyo and Singapore, not billed as a separate add-on.
It depends heavily on how much of your traffic is China-facing and what your baseline performance looked like before. Services with a substantial China-based audience tend to see the most noticeable improvement.
Yes, reach out to our team about a trial or test IP, and we can also point you to relevant looking glass or testing resources to verify performance independently.
Not identically. Each carrier operates a largely separate network, so CTGNet (China Telecom), CUP (China Unicom), and CMIN2 (China Mobile) each behave a little differently, though every Performance KVM VPS in Tokyo and Singapore includes all three routes so your traffic gets a direct path regardless of which carrier your audience is on.
Not specifically, this update is targeted at improving the network path to and from mainland China. Users elsewhere in Asia-Pacific were already served well by Tokyo and Singapore’s existing connectivity and shouldn’t see a meaningful change either way.
]]>As covered in more detail elsewhere on our blog, physical distance to mainland China is a weaker predictor of actual performance than carrier routing quality. A server in Hong Kong isn’t automatically faster for Chinese users than a server in Tokyo just because it’s closer on a map, since what actually matters is whether that server’s network has a direct, optimized relationship with the specific Chinese carrier its users are on. With that in mind, here’s what each location brings independent of raw distance.
Tokyo offers strong, verifiable network infrastructure for China-facing traffic. Our Tokyo network runs on AS3258 with direct upstream relationships to China Telecom, China Unicom, and China Mobile, meaning traffic to and from all three major Chinese carriers has a direct path rather than routing through unrelated intermediary networks. Tokyo also peers at major regional exchanges, including BBIX Tokyo, JPNAP Tokyo, and Equinix IX, which strengthens connectivity to the broader Asia-Pacific region beyond just China-facing traffic specifically.
Japan sits outside mainland Chinese jurisdiction entirely, and its overall internet infrastructure is mature and stable, backed by a well-developed domestic network ecosystem. The trade-off is that Tokyo is physically farther from mainland China than Hong Kong or Singapore, though as covered above, that raw distance matters less than the quality of the carrier routing itself.
Singapore combines reasonable physical proximity to China with a jurisdiction entirely outside mainland Chinese regulatory reach, plus dense connectivity to the rest of Southeast Asia, which matters if your audience extends beyond China specifically into the broader region. Singapore has built itself into a major international connectivity hub over the past several decades, with substantial international network infrastructure passing through it.
The consideration to weigh here is the same one that applies everywhere in this comparison: proximity alone doesn’t guarantee good Chinese-carrier routing, so it’s worth verifying a specific provider’s actual carrier relationships and route quality from a Singapore location rather than assuming proximity translates directly to performance.
Hong Kong is often the first location people think of for China-facing hosting, given its geographic and historical proximity to mainland China. It operates under its own distinct legal and regulatory framework, separate from mainland China’s, which matters for some businesses’ jurisdiction preferences, while still offering a genuinely close physical location to Chinese users.
As with the other two locations, the deciding factor isn’t Hong Kong’s proximity itself, it’s whether a given provider’s network in Hong Kong actually has strong, direct routing to the Chinese carrier networks your specific audience uses, since proximity without matching route quality doesn’t automatically deliver a better experience than a farther location with better-engineered routing.
If carrier routing quality is comparable across your options, jurisdiction and broader regional connectivity become the more relevant deciding factors, and this is where Tokyo’s regional exchange peering, Singapore’s Southeast Asia connectivity, and Hong Kong’s specific regulatory environment each offer a different profile worth matching to your business’s specific needs.
If you’re unsure about routing quality, verify it directly rather than assuming based on location. A traceroute from or to a Chinese IP address, or a public looking glass tool, tells you far more about actual performance than geographic proximity does.
If your audience extends beyond mainland China, into broader Southeast Asia or the wider Asia-Pacific region, factor that into the decision too, since a location optimized purely for China-facing performance might not be the best fit if a meaningful part of your audience is elsewhere in the region.
If jurisdiction matters to your business for regulatory or legal reasons independent of network performance, that’s a legitimate factor to weight directly, since all three locations sit outside mainland Chinese jurisdiction but under genuinely different legal frameworks from each other.
Regardless of which location you’re leaning toward, test it directly before committing to a long-term plan. Request a trial or test IP, run a traceroute to confirm the network path actually reflects a well-optimized route to the Chinese carrier your audience uses, and test at multiple times of day to check for peak-hour degradation. Marketing claims about “China-optimized” infrastructure are only as good as what they hold up to under an actual test.
None of these three locations is universally “the best” for China-facing hosting, each has a genuinely different profile in carrier routing strength, jurisdiction, and regional connectivity, and the right choice depends on which of those factors matters most for your specific audience and business needs. What matters more than the location name on a pricing page is verifying the actual carrier routing quality behind it, since that’s what determines real-world performance far more than physical proximity does.
Ready to compare for yourself? V.PS’s Performance KVM VPS includes CTGNet, CUP, and CMIN2 routing in both Singapore and Tokyo Gen 2, with transparent specs and verifiable carrier routing.
Not necessarily. Physical proximity is a weaker predictor of actual performance than carrier routing quality, so a farther location with better-optimized routing can outperform a closer one with only standard transit.
Not as much as you’d expect, since Tokyo’s network can have direct, optimized upstream relationships with all three major Chinese carriers, which matters more for actual performance than the raw physical distance involved.
Singapore’s dense regional connectivity makes it a strong choice for a broader Southeast Asian audience alongside China-facing traffic, though it’s worth weighing against your specific carrier routing needs too.
Yes, all three operate under their own distinct legal frameworks separate from mainland China’s, though the specific regulatory environment differs meaningfully between them, which may matter for your business independent of network performance.
Test directly with a trial or test IP, running a traceroute from or to a Chinese IP address to confirm real routing quality, rather than relying on assumptions based on geographic proximity alone.
It depends on your business. For most services, performance (verified through actual testing) should carry the most weight, but if your business has specific regulatory or legal requirements, jurisdiction may need to be weighted more heavily even if it means a small performance trade-off.
]]>The internet doesn’t move data in a straight line between two points. It routes traffic through a chain of networks based on peering agreements and business relationships between those networks, not physical distance.
For traffic to and from mainland China, that chain often passes through a limited set of congested peering points, and each additional hop adds latency, while congestion at those peering points adds further, unpredictable delay during high-traffic periods.
A server that’s otherwise well-specified and well-located can still deliver a poor experience to China-based users if the network path between them is bad, and no amount of server-side optimization fixes a problem that’s happening in the network in between.
A China-optimized route is a network path specifically engineered to minimize that problem, typically by staying on a well-connected carrier’s own backbone for a longer stretch of the journey rather than handing off early to congested, general-purpose transit. Each of China’s three major carriers, China Telecom, China Unicom, and China Mobile, operates a largely separate network with its own international gateways, so each has built its own version of this premium product rather than there being one universal “China-optimized” route.
China Telecom: CTGNet. Formerly marketed as CN2 GIA (Global Internet Access) and still often called that, CTGNet (AS23764, AS4809) is China Telecom’s premium backbone and the most well-known of the three, since China Telecom is the largest of the carriers and covers the broadest geographic footprint. The value is straightforward: traffic stays on China Telecom’s own network for a longer stretch of the route instead of handing off early to congested general-purpose transit, which shows up as fewer hops on a traceroute and lower, more consistent latency for China Telecom users specifically.
China Unicom: CUP (China Unicom Premium, AS9929/AS10099) does the same job for China Unicom’s network, keeping traffic off the standard, more congested paths and on Unicom’s own premium backbone instead. If your audience skews toward China Unicom rather than China Telecom, a CUP route will generally outperform CTGNet for those specific users, even though CTGNet gets more attention in general hosting discussions.
China Mobile: CMIN2 (China Mobile International N2, AS58807) is China Mobile’s premium route and the newest of the three to become widely available in commercial hosting. It delivers the same core benefit, fewer hops and more consistent throughput, for traffic reaching China Mobile’s network specifically, which matters given how much of China Mobile’s user base connects over mobile data rather than fixed broadband.
It’s worth being clear that “optimized route” is a real, verifiable technical claim when it’s genuine, not an abstract quality descriptor. A specific route either does or doesn’t stay on a premium carrier backbone for a meaningful portion of its path, and that’s checkable through a traceroute, which shows the actual sequence of networks traffic passes through to reach its destination. This is different from vaguer marketing terms like “fast” or “reliable,” which don’t point to anything specific you can independently verify.
Uniform performance across all of mainland China. Route quality can vary by specific region, since the physical backbone infrastructure doesn’t reach every area with equal strength, and a route can perform excellently to one major city while only being average to a more remote province.
Equal benefit across all three carriers. A route optimized for China Telecom traffic doesn’t automatically deliver the same benefit to a user on China Unicom or China Mobile’s network, since these are genuinely separate networks with separate peering arrangements.
Immunity to congestion entirely. Even a well-optimized route can degrade during unusually high demand periods if a provider hasn’t provisioned adequate capacity on that specific route, which is why testing at different times of day tells you more than a single test.
Compensation for underpowered hardware. A well-routed but resource-constrained server will still perform poorly, since routing addresses the network path, not what happens once traffic reaches the server itself.
Ask which specific carrier route is involved by name (CTGNet, still often marketed as CN2 GIA, for China Telecom; CUP; or CMIN2), rather than accepting a generic “China-optimized” label without detail. Run a traceroute from or to a Chinese IP address, or use a public looking glass tool, and look for the traffic staying on the relevant carrier’s backbone for a meaningful portion of the path.
Test at more than one time of day, since peak-hour performance is often the more revealing test of whether a route is genuinely well-provisioned or just performs well when demand is low.
China-optimized routing is a specific, checkable technical claim about how a network path is engineered, not a vague marketing descriptor, and understanding the mechanics behind it makes it much easier to tell a genuine implementation from a loosely used label. The core idea is straightforward: keep traffic on a well-connected carrier’s own backbone for as much of the journey as possible, avoiding the congestion points that make standard transit to and from China unpredictable.
Curious what a real optimized route looks like? V.PS’s Performance KVM VPS in Singapore and Tokyo Gen 2 includes CTGNet, CUP, and CMIN2 routing by default, verifiable through your own traceroute testing.
CTGNet, formerly marketed as CN2 GIA and still often called that, is one specific example, tied to China Telecom. China-optimized routing is the broader category, which also includes equivalent products for China Unicom (CUP) and China Mobile (CMIN2).
Yes. A traceroute from or to a Chinese IP address, or a public looking glass tool, will show the actual path traffic takes, letting you check whether it stays on a premium carrier backbone or routes through standard, more congested transit.
No. Each carrier, China Telecom, China Unicom, and China Mobile, operates a largely separate network, so a route optimized for one doesn’t automatically deliver the same benefit to users on a different carrier.
It addresses the network path specifically, which is often the biggest factor, but server resources, application efficiency, and the specific region within China your users are in can all still affect overall performance.
It varies by provider, since it requires specific carrier agreements and infrastructure investment beyond standard international transit. Whether it’s worth the added cost depends on how much of your traffic is genuinely China-facing.
Not necessarily. Carrier relationships, peering agreements, and provisioned capacity can all change, which is part of why periodic re-testing, not just a one-time check at signup, is worth doing if China-facing performance matters to your service long-term.
]]>The internet routes traffic based on the specific path of networks and peering agreements between them, not the physical distance a signal has to travel.
A server in Hong Kong, geographically close to mainland China, can still have a slow, congested connection to Chinese users if the network path between Hong Kong and the relevant Chinese carrier isn’t well optimized. Meanwhile, a server in Tokyo, considerably farther away in kilometers, can outperform that closer Hong Kong server if Tokyo’s network has a direct, well-optimized route into the same Chinese carrier’s backbone.
Distance sets a physical floor on latency, but for most real-world cases, the network path adds far more delay than the raw distance does, which is exactly why carrier routing ends up mattering just as much, if not more, than location in practice.
China’s internet infrastructure is split across three major carriers, China Telecom, China Unicom, and China Mobile, each operating largely separate networks with their own international gateways and peering arrangements. Whether a given server has a good connection to Chinese users depends on whether that server’s network has a direct, optimized relationship with the specific carrier those users are on, not simply on how many kilometers separate the two locations.
A server with strong upstream relationships to all three major carriers will generally outperform a geographically closer server that only has standard, unoptimized transit, regardless of the raw distance involved.
Take two hypothetical servers: one in Hong Kong with only standard international transit, and one in Tokyo with direct upstream relationships to China Telecom, China Unicom, and China Mobile, plus peering at major regional exchanges.
Despite Hong Kong’s proximity advantage on a map, the Tokyo server’s traffic to a China Telecom user could easily show fewer hops and lower, more consistent latency than the Hong Kong server’s, simply because the network path is better engineered, even though the physical distance is considerably longer.
This isn’t a hypothetical edge case, it’s a pattern that shows up consistently enough that experienced infrastructure teams evaluate routing quality before location whenever China-facing performance actually matters.
This doesn’t mean location is irrelevant, just that it’s not the primary variable for China-facing traffic specifically. Location still affects latency to non-China audiences in the broader region, matters for jurisdiction and regulatory considerations (a Singapore-based server sits outside mainland Chinese legal jurisdiction, for instance, which matters for some businesses independent of network performance), and affects the baseline physical floor on latency once carrier routing is equally good between two options.
If you’re choosing between two providers with genuinely comparable routing quality, location becomes the relevant tiebreaker. It’s only not the primary decision factor when routing quality varies significantly between the options, which, in this space, it usually does.
Ask which specific carrier routes are supported, by name, CTGNet (CN2 GIA) for China Telecom, CUP for China Unicom, CMIN2 for China Mobile, rather than accepting a vague “optimized for China” claim without detail.
Check which carriers the provider’s network has direct upstream relationships with, not just which exchanges it peers at generally, since direct upstream relationships to Chinese carriers specifically are what actually shortens the path.
Run your own traceroute test from or to a Chinese IP address rather than relying on a provider’s marketing claims, and compare the hop count and consistency against what you’d expect from a genuinely optimized route.
Test at multiple times of day, since peak-hour congestion reveals whether a route is genuinely well-provisioned or only performs well under light demand.
For a China-facing service, evaluating providers primarily by physical proximity to China is a reasonable-sounding instinct that leads to worse decisions than evaluating by carrier routing quality directly. The question that actually predicts performance isn’t “how close is this server to China,” it’s “does this server’s network have a direct, optimized relationship with the specific Chinese carrier my users are on.” Once you’re comparing providers with genuinely similar routing quality, location becomes a sensible tiebreaker, but it shouldn’t be the first filter.
Want to see how routing quality compares to raw distance for yourself? V.PS’s Performance KVM VPS in Singapore and Tokyo Gen 2 includes CTGNet, CUP, and CMIN2 routing by default, and Tokyo runs on AS3258 with direct upstream relationships to all three major Chinese carriers.
Not necessarily. Network routing quality, specifically whether a server’s network has a direct, optimized path into a Chinese carrier’s backbone, tends to matter just as much, if not more, than raw physical distance for China-facing traffic.
No, location still matters for jurisdiction considerations, for latency to non-China regional audiences, and as a tiebreaker once you’re comparing providers with genuinely comparable routing quality.
Ask which specific Chinese carrier routes are supported by name, and verify independently with a traceroute from or to a Chinese IP address rather than relying solely on marketing claims.
China Telecom, China Unicom, and China Mobile operate largely separate physical networks with their own international gateways, so an optimized route built for one doesn’t automatically carry the same benefit to users on a different carrier’s network.
Yes, this is common. A well-routed server with direct upstream carrier relationships can outperform a geographically closer server that only has standard, unoptimized international transit.
Not entirely, but it shouldn’t be your first filter. Evaluate carrier routing quality first, then use location as a tiebreaker among providers with comparable routing, or as a factor for jurisdiction and non-China regional latency needs.
]]>We rebuilt it as a static Astro site. Pages are pre-rendered as HTML; JavaScript handles the theme switcher, navigation and live chat. Shipping the site this way felt like the least a hosting company could do.
High contrast and one Sunlight Yellow accent do most of the visual work. IBM Plex Sans handles the text, while Space Mono is reserved for prices, specs, airport codes and hostnames. Dark mode follows your system setting, with a switch in the header. The brand page has the downloadable logos and full palette.
Each of our 11 locations now has its own page. It names the facility, ASN, upstreams and internet exchanges, then lists every current plan with a direct cart link. Each page also points to a public Looking Glass, so you can test the network before ordering.
The VPS range is organized into six families, from the flagship Performance line to the yearly Nano plans. Each family has a page showing its cities, specs and current prices.
The site also has dedicated sections for cPanel shared hosting in San Jose, domain registration with free DNS, and SSL certificates. The pricing page brings the whole catalog together, and the listed price is also the renewal price.
The header now has Products and Locations menus, and the FAQ is grouped by topic. If you would rather ask someone, live chat sits in the lower-right corner.
Product news, new location announcements and maintenance notes will appear here first. Shorter updates will continue on Telegram, Mastodon and Bluesky. You can also subscribe through RSS or Atom.
Plans, prices, the client area and the 99.9% SLA are unchanged. Existing public URLs remain in place, so saved links should continue to work.
If a saved link does not work, tell us.
]]>