Should your CDN origin sit inside Vietnam

You front your application with a CDN, so the origin can sit anywhere, right? That assumption works until you look at what actually crosses the cable: dynamic API calls, uncacheable POST requests, cache misses on first visits, WebSocket upgrades, and certificate validation back to the origin. Every one of those trips pays the full latency between the edge node and your origin server. If a meaningful share of your users are inside Vietnam, the question of whether to place your CDN origin inside Vietnam stops being academic and becomes a measurable performance decision.

What a CDN actually shields, and what it does not

A CDN caches static assets and edge-renderable responses. After the first hit, images, CSS, JavaScript bundles, and even full HTML pages can be served from a node close to the user. The origin is off the hot path for those requests, and that is where the latency saving comes from.

But the origin stays on the critical path for:

• Cache misses (first visits, purged content). The edge has to fetch from origin before it can serve the response.
• All dynamic and uncacheable traffic. POST, PUT, DELETE, authentication, checkout flows, real-time data endpoints, these cannot be cached at the edge. Every one hits the origin.
• SSL/TLS revalidation. Depending on your setup, the CDN may revalidate the origin certificate at regular intervals.
• WebSocket and long-poll connections. These bypass the CDN cache layer entirely and establish a direct or proxied connection to the origin.

If a large share of your traffic falls into those piles, the distance between the CDN edge and the origin becomes the bottleneck. The edge nodes closest to Vietnam (Hong Kong, Singapore, Tokyo) maintain excellent peering to Vietnam, but the final hop from those nodes into the country still crosses international transit, typically 60 to 120 milliseconds round-trip, depending on the route and time of day.

Domestic bandwidth vs international bandwidth: knowing the limits

Before deciding where to place an origin server, you need to understand how bandwidth works inside Vietnam. The country is served by four major carriers: Viettel (military-owned, largest subscriber base), VNPT (state-owned incumbent, formerly Vietnam Posts and Telecommunications), FPT Telecom (private, strong in business and residential), and CMC Telecom (enterprise-focused, fewer residential users). All four operate their own domestic backbone and exchange traffic through the VNIX (Vietnam National Internet Exchange).

Domestic traffic flows within each carrier's backbone at relatively low cost and high throughput. For a VPS with an origin workload inside Vietnam, domestic bandwidth runs at 100 Mbps by default on a 1 Gbps port. That is the actual speed, the port can burst to 1 Gbps, but the committed domestic throughput is 100 Mbps. International bandwidth is a shared pool that typically delivers roughly 4 to 10 Mbps per VPS, depending on the provider and the carrier's remaining capacity on the submarine cables (APCN-2, AAG, SMW-5, and the newer ADC). For an origin server that primarily serves CDN edge nodes (most of which sit outside Vietnam), the international pool is the relevant constraint.

CDN 节点回源越南源服务器时，跨越的是国际链路；源站设在越南境内不会加快缓存命中，但会极大减少每一次未命中请求的延迟。

When CDN edge nodes fetch from an origin inside Vietnam, they cross international links every time. Placing the origin inside the country does not accelerate cache hits, but it significantly reduces the latency of every cache miss.

This architecture trade-off is straightforward: if the majority of your uncacheable traffic originates from Vietnamese users, a local origin removes one international hop from those requests. The CDN edge nodes in Hong Kong or Singapore still make an international fetch to the origin, but the response to the end user is delivered from an edge close to them. If, instead, your users are global and only a fraction are in Vietnam, the international bandwidth pool on the origin becomes the limiting factor, you might saturate 10 Mbps faster than you expect on a busy day.

Why uncacheable requests reveal the origin location cost

Consider an e-commerce checkout flow. The user selects a product, enters shipping details, and clicks "Place Order." That POST request cannot be cached at the edge. It goes from the user to the CDN edge, then from the edge to the origin. If the edge is in Hong Kong and the origin is in Singapore, the latency is roughly 35 ms. If the edge is in Hong Kong and the origin is inside Vietnam, that leg jumps to 80 to 100 ms (depends on the carrier and time of day). The user feels the extra 50 to 60 milliseconds as part of the "order submitted" response.

Now multiply that by every dynamic request during a session: page load API calls, stock lookups, address validation, payment gateway handshakes. The accumulated latency from the origin's location can push page loads 200 to 300 ms slower for users inside Vietnam, even with a CDN in front. That number is measurable in conversion rate, Amazon's published work on latency shows that every 100 milliseconds of extra load time costs 1% in revenue (internal study, 2019; revalidated by Akamai research).

For a buy VPS Vietnam datacenter setup where the origin is placed in Vietnam's domestic network, the uncacheable request overhead drops to exactly the latency between the local edge node and the origin inside the same country, typically under 5 ms within Viettel's backbone. The trade-off is that international cache misses (users outside Asia hitting the Vietnamese origin) add latency on those specific fetches. You are optimising for the traffic distribution that matters to your application.

CDN edge coverage in Southeast Asia and its interaction with Vietnam

All major CDNs, Cloudflare, Akamai, Fastly, CloudFront, have edge nodes in Hong Kong, Singapore, and Tokyo. Some also have nodes in Manila and Bangkok. Vietnam itself is served from those nodes, not from a local point of presence (the regulatory environment and infrastructure costs have kept local edge deployments rare, though Cloudflare does have two PoPs in Vietnam since late 2023).

The practical effect: a user in Hanoi connects to the nearest Cloudflare edge somewhere in Hong Kong or Singapore (whichever is fastest via BGP), then that edge fetches from the origin. The user-to-edge latency is around 30 to 50 ms. The edge-to-origin latency depends on where the origin sits. If the origin is in Singapore, the user sees roughly 30 ms (to edge) + 35 ms (edge to origin) + processing time. If the origin is inside Vietnam, the user sees roughly 30 ms (to edge) + 80 to 100 ms (edge to origin, crossing the international link). The user-to-edge leg improves when the CDN deploys a local node, but the overall impact on dynamic requests still depends on the edge-to-origin leg.

The correct architecture for global audiences is to keep the origin outside Vietnam and rely on the CDN's edge caching for speed. The correct architecture for applications with a predominantly Vietnamese user base and a high proportion of dynamic requests is to place the origin inside Vietnam and accept the international leg for cache misses from global users, because the local users' dynamic traffic is what matters for your business.

Bandwidth provisioning: what a Vietnam origin can actually handle

A Linux VPS with an origin workload placed inside Vietnam operates under domestic bandwidth provisioning. The domestic pool is 100 Mbps on a 1 Gbps port. International bandwidth is shared and typically delivers 4 to 10 Mbps per instance. For an origin server, the constraint is not domestic speed but international capacity when the CDN edges fetch from it. Every cache miss, every uncacheable POST, every WebSocket connection from an edge outside Vietnam consumes from that international pool.

If your application serves 50 MB per dynamic response and you expect 10 uncacheable requests per second from CDN edges in Hong Kong and Singapore, you are moving 500 MB per second across the international link. At 10 Mbps, that is 1.25 MB per second, you saturate the international link in less than three seconds. The practical response: reduce response sizes (compress, prune unused data), increase cache hit ratios, or upgrade the plan to get more of the shared international pool.

What you do not do is assume the origin can serve international traffic at domestic speeds. The 100 Mbps domestic number applies only when the client is inside Vietnam. CDN edges sit outside Vietnam, so they count as international traffic regardless of which carrier they peer through.

Choosing between a local origin and a regional origin

The decision comes down to a single metric: the ratio of domestic-to-international traffic. If less than 30% of your users are inside Vietnam, a regional origin in Singapore or Hong Kong serves both Vietnamese and global users better, because the international-to-Vietnam leg is short and symmetrical. If more than 50% of your users are inside Vietnam and a large fraction of requests are uncacheable, a local origin removes the cross-border hop for those requests and measurably improves load times for the majority of your audience.

There is a middle ground: run dual origins. One origin inside Vietnam for traffic from domestic users (routed through a CDN rule that sends Vietnamese-origin requests to the local origin), and one in Singapore for the rest of the world. This adds operational complexity, you maintain two stacks, two databases (or a cross-region replica), and two failover plans, but it solves the bandwidth and latency trade-offs without compromising either audience.

Another middle ground: use the CDN's origin shield feature (Cloudflare's "Argo Smart Routing" or "Cache Reserve", Fastly's "Shield") to aggregate requests from multiple edge nodes into one shielded fetch to the origin. This reduces the number of international fetches, but does not eliminate the latency for the ones that still reach Vietnam.

Practical checklist for evaluating a Vietnam origin

Before placing your origin inside Vietnam, measure these values over a week of production traffic:

• Percentage of uncacheable requests from Vietnam. If it is under 20%, the origin location matters less than reducing TTFB through server-side tuning (PHP-FPM pools, database query caching, HTTP/2 or QUIC termination).
• Average response size of dynamic requests. Over 100 KB per response becomes expensive across a 10 Mbps international link. Compress before sending or move those responses to the cacheable path.
• CDN cache hit ratio. Below 70% means your origin is doing more work than it should. Increase cache-control headers and consider edge-side includes for partial cacheability.
• Peak concurrent connections from CDN edges. A single persistent connection from each edge node can saturate the origin's connection pool faster than a shared 10 Mbps link may be the bottleneck, measure both.

When a Vietnam origin is the wrong choice

If your application is an API-first service for global mobile clients, placing the origin inside Vietnam introduces unnecessary international hops for every API call made by users outside Southeast Asia. The CDN cannot cache API responses that carry per-user data. Every call hits the origin, and every call crosses the international link in both directions. The dynamic request latency for a user in Germany or Brazil becomes 400 to 500 ms round-trip just for the leg into Vietnam, before any processing happens.

Similarly, if your workload is predominantly read-heavy and cacheable (a static site generator, a brochure site, a blog), the origin location barely matters after the first composite cache fill. The CDN serves everything from edge nodes. The origin only wakes up during cache purges or content deploys. For those workloads, place the origin wherever it is operationally convenient, the latency savings from a local origin will not move your metrics.

FAQ

Related articles

• Vietnam VPS vs Singapore VPS for serving Vietnamese users
• Why a Vietnam IPv4 matters when your users are in Vietnam
• Should your CDN origin sit inside Vietnam
• Configure DNS records for your domain: A, CNAME, MX, TXT