How to Serve Large File Downloads to Mainland China From a Tokyo VPS

Your Tokyo server pings Shanghai in under 50 milliseconds. Web pages load quickly. Then you publish a 4 GB file, and users in China report downloads stuck at a few hundred kilobytes per second, failing halfway, and restarting from zero.

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.

Why latency and throughput aren’t the same thing

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.

What makes China routes hard for big transfers

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.

Start with the route

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.

Enable BBR and size your TCP buffers

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 --system

The 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.

Make every download resumable

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.

Split big files into chunks

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.

Parallel connections, used sensibly

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.

Tune Nginx for large static files

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.

Plan for bandwidth and storage

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.

When a VPS is enough and when you need more

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.

Wrapping up

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.

Frequently asked questions about serving large downloads to China

Why are downloads from my server to China slow when ping is low?

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.

Does BBR help with downloads to China?

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.

How do I make large downloads resumable?

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.

Should I split large files into chunks?

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.

Do I need a CDN to serve downloads in China?

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.

How much bandwidth will large file downloads use?

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.