Serving mobile users on Vietnamese carriers: a network primer

If your application targets users in Vietnam, you are building for a mobile-first market. Over 90% of internet access in the country happens through a smartphone, and the three dominant mobile carriers, Viettel, VNPT (Vinaphone), and MobiFone (with a smaller share from Vietnamobile), handle nearly all of that traffic. A fourth fixed-line operator, FPT Telecom, runs its own broadband and backbone but is not a mobile carrier. There is also CMC Telecom, a major enterprise-focused infrastructure provider that interconnects with the others. What this means for you: if your VPS or origin server sits outside Vietnam, your users on 4G or 5G will see wildly different latency and throughput depending on which tower they are on, which carrier they use, and whether the network is doing Carrier-Grade NAT (CGNAT). The number that matters most is TTFB (Time To First Byte) on 4G, the time between the user clicking a link and your server sending the first byte of response. This guide explains why, and how to set up your infrastructure correctly from the start.

越南移动网络主导，优化 4G TTFB 是服务越南用户的关键。

Vietnam's mobile-dominant network means optimizing 4G TTFB is the key to serving users well.

Why Vietnam's mobile network is different

In many Western markets, mobile connectivity is a complement to fixed broadband. In Vietnam, it is the primary (and often the only) connection type for a large share of the population. The three carriers operate their own independent backbones and interconnections:

• Viettel, the largest mobile operator and also the largest internet service provider by subscriber count. It owns its own submarine cable system (AAE-1), extensive domestic fiber, and a Tier 3 data center footprint. Its mobile IP ranges are often distinct from its fixed broadband ranges.
• VNPT (Vinaphone), the second largest, operates a dense domestic network and part-owns other submarine cables including IA and APG. Also operates a fixed broadband business.
• MobiFone, smaller but still significant mobile-only operator, relies heavily on interconnect with Viettel and VNPT.
• FPT Telecom, fixed-line broadband and enterprise services, no mobile network of its own but a major transit and BGP player.
• CMC Telecom, enterprise-focused hosting and connectivity, operates Tier 3 data centers and is a major partner for cross-carrier peering.

These carriers do not all interconnect at the same exchange points, and peering between them can be inconsistent. A mobile user on Viettel accessing a server connected through VNPT may see noticeably higher latency than a Viettel user on a Viettel-connected server. The key takeaway: your server needs to be inside Vietnam's domestic network and ideally peered with multiple carriers to avoid these cross-carrier hops.

Carrier-Grade NAT (CGNAT) and IPv4

The vast majority of mobile users in Vietnam sit behind Carrier-Grade NAT (CGNAT). This means they share a public IPv4 address with hundreds or thousands of other subscribers. For your server, the mobile user's connection appears to come from the carrier's NAT gateway, not the device itself.

What CGNAT breaks:

1. Rate limiting by IP, blocking a "bad" IP can block an entire carrier's worth of users.
2. Geo-location by source IP, all Viettel mobile users appear to come from the same few gateways, often in Hanoi or HCMC even if the user is physically elsewhere.
3. Persistent connections, NAT bindings time out faster on mobile networks, so long-lived idle TCP connections may drop.
4. HTTP/2 and QUIC, CGNAT can interfere with connection coalescing. TCP fast open may also behave unpredictably.

What works: HTTPS, HTTP/2 over TLS, WebSocket over TLS with proper keepalive, and QUIC (HTTP/3) are all fine through CGNAT as long as your server handles connection resets gracefully.

For your application, the practical consequence is that you cannot reliably rate-limit or geo-block by mobile IP. You should use other signals (User-Agent, session, account-level flags) for any IP-based logic. Also, your server should accept keepalive values of 30 seconds or less on mobile connections to prevent NAT timeouts from killing idle sockets.

TTFB on 4G, the one metric that predicts everything

TTFB measures how long it takes from the user's request leaving the device to the first byte of response arriving back. On a wired connection in Vietnam, TTFB to a local server should be under 20 ms. To a server in Singapore it may be 30-60 ms. To a server in the US, 180-280 ms.

On 4G, the numbers are different:

These numbers assume the server uses a Vietnam-based IPv4 that routes through the carrier's domestic infrastructure. A server in Singapore may have lower absolute ping to a Viettel gateway in Hanoi, but the 4G radio access network adds its own latency, typically 20-40 ms on the last hop, and the cell tower scheduling adds jitter.

Your goal: keep the server-to-gateway TTFB under 30 ms. Once the server is inside Vietnam, the added radio latency is out of your hands, but the server side will not be the bottleneck.

Choosing a VPS for the Vietnam mobile audience

If your users are in Vietnam, your server should be in Vietnam. A Vietnam VPS hosting arrangement means you get a dedicated IPv4 from the Vietnam range, which is recognized by Vietnamese carriers as a domestic address. The carriers then route your traffic through their domestic network, which is internally fast, rather than through international transit.

A Linux VPS with the specs below is sufficient for most web applications serving a mobile audience. The key is not the raw RAM or CPU but the network path. You want a server that peers directly or through an exchange with all three mobile carriers.

At thueVPS, the infrastructure operates on NVMe storage with full root access (SSH for Linux, RDP for Windows Server). The domestic bandwidth runs at 100 Mbps on a 1 Gbps port, the port can burst above 100 Mbps, but the committed domestic speed is 100 Mbps. International bandwidth uses a shared pool (roughly 4 to 10 Mbps depending on load). A dedicated IPv4 from the Vietnam range is part of the service. Monthly billed VPS plans start at 2 GB RAM and scale up to 16 GB, with no long-term contract.

The plan sizes that work for most mobile-serving applications: 2 GB RAM (VNLite) for a lightweight API or static site, 4 GB (VNx2) for a small database-backed application, 8 GB (VNx4) for a mid-traffic WordPress or next.js app, and 16 GB (VNx8) for heavier workloads like video transcoding or large e-commerce.

Windows Server VPS RDP is also available if your application stack runs on .NET or needs a GUI environment, though for serving mobile users Linux is overwhelmingly more common and cost-effective.

Optimizations that matter for mobile traffic

Once your server is in the right location, these network-level changes improve TTFB and overall reliability for mobile users:

1. Enable TCP fast open and BBR

TCP Fast Open (TFO) lets the client send data in the SYN packet, saving one round trip on repeat connections. BBR (Bottleneck Bandwidth and Round-trip propagation time) congestion control improves throughput on variable-latency links like 4G. Enable both in your kernel:

# Check if BBR is available
sysctl net.ipv4.tcp_congestion_control
# Set BBR as the congestion control algorithm
echo "net.ipv4.tcp_congestion_control=bbr" >> /etc/sysctl.conf
# Enable TCP Fast Open
echo "net.ipv4.tcp_fastopen=3" >> /etc/sysctl.conf
sysctl -p

2. Tune keepalive for mobile NAT

Mobile CGNAT timeouts vary by carrier, but 30 seconds is a safe minimum. Reduce your web server's keepalive timeout to 25-30 seconds instead of the default 60-120:

# Nginx: in http block
keepalive_timeout 30;
keepalive_requests 100;

3. Serve HTTP/2 or HTTP/3

HTTP/3 (QUIC) runs over UDP, which avoids TCP head-of-line blocking and is generally more resilient through CGNAT. If your CDN or server supports it, enable it. HTTP/2 over TLS is the next best option.

# Nginx: enable HTTP/2 (TLS required)
listen 443 ssl http2;
# For HTTP/3, use a separate listen directive
listen 443 quic reuseport;

4. Compress aggressively with Brotli and Gzip

Mobile connections are constrained. Brotli compresses text assets ~20% more than Gzip. Nginx with the Brotli module:

brotli on;
brotli_static on;
brotli_comp_level 6;
brotli_types text/plain text/css application/json application/javascript text/xml application/xml+rss application/octet-stream image/svg+xml;

5. Configure TLS session resumption

Mobile users often reconnect to the same server. Enable TLS session resumption (both session cache and session tickets) to avoid a full TLS handshake on each connection:

ssl_session_cache shared:SSL:10m;
ssl_session_timeout 10m;
ssl_session_tickets on;

Verifying your setup

Test TTFB from Vietnam mobile: Use a monitoring service that has nodes inside Vietnam on actual mobile networks. curl from a VPS inside the country to your server is a baseline test:

# From a Vietnam-based VPS
curl -o /dev/null -w "TCP handshake: %{time_connect}s\nTTFB: %{time_starttransfer}s\nTotal: %{time_total}s\n" https://your-server.com

Expected output: TTFB should be under 40 ms if both endpoints are inside Vietnam. If TTFB is over 100 ms, check carrier peering, you may be routing through an international exchange.

Monitor jitter and packet loss: Mobile networks are noisier than fiber. Use mtr from a Vietnam-based VPS to your server and look for packet loss above 0.5% on any hop:

mtr -r -c 100 your-server.com

A clean path shows 0% loss on final hops. If you see loss on the carrier gateway, that is often a sign of congestion on that Carrier's network.

Troubleshooting common mobile-network issues

Problem: High TTFB even though your server is in Vietnam

Check which carrier path your server uses. If all your traffic routes through one carrier (e.g., Viettel) and a user on MobiFone is experiencing high TTFB, the issue is inter-carrier peering. The fix: choose a VPS provider that has BGP sessions with multiple Vietnamese carriers or peering at a major exchange like VNIX.

Problem: Connections drop after a few seconds of inactivity

This is almost certainly CGNAT timeout. Reduce your keepalive timeout (as above) and consider enabling TCP keepalive at the application layer with a 15-second interval. WebSocket users should implement a 10-15 second ping/pong loop.

Problem: Your geo-blocking by IP stops working

As discussed, mobile IP ranges are shared through CGNAT. Do not rely on IP-based geo-blocking for mobile traffic. Use application-level authentication instead.

Conclusion

Vietnam is a mobile-first market dominated by Viettel, VNPT, and MobiFone. The single most important technical decision you can make for serving these users is to place your server inside Vietnam with a dedicated IPv4 from the Vietnam range. TTFB on 4G becomes the metric that defines user experience, and once your server is inside the domestic network, you can tune TCP, TLS, and HTTP settings to make that TTFB as low as possible. Cross-carrier peering, CGNAT behavior, and radio access latency are real factors, but none of them matter if your server is 200 ms away on the other side of a Pacific cable.

Choose a Vietnam-based VPS, optimize for 4G TTFB, and your mobile users will thank you with faster page loads and fewer timeouts.

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?
• 10 cheap VPS Vietnam must-read before buy 2026 guide