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