Tôi chuyển VPS từ Hetzner (Đức) sang Vultr (Singapore) — 280ms latency biến mất ngay khi khách Việt mở app

3 tuần trước tôi viết một bài chọn CPU cho VPS — kết luận chọn AMD EPYC vì giá/hiệu năng tốt nhất. Đúng — nhưng tôi đã bỏ qua biến số đắt hơn cả CPU: vị trí datacenter so với khách hàng.

Stack của tôi (Laravel + MySQL + Redis + Next.js, ~16 container) chạy trên Hetzner CPX31 ở Falkenstein, Đức từ tháng 1/2026. 4 vCPU EPYC Milan, 8GB RAM, NVMe — €15/tháng. CPU thừa thãi, RAM thừa, disk nhanh. Vẫn perfect trên paper.

Vấn đề: 95% người dùng của tôi ở Việt Nam. RTT từ Hà Nội → Falkenstein là 280ms ổn định (đo từ 3 nhà mạng VN: Viettel, FPT, VNPT, lúc 8h sáng, 14h, 22h). Mỗi request HTTP cần ít nhất 1 round-trip TCP handshake + 1 TLS handshake + 1 HTTP — gần như 3× RTT = 840ms chỉ để bắt đầu nhận byte đầu tiên. Cộng với TTFB của Laravel ~200-400ms → TTFB tổng đến browser 1.1-1.4 giây.

Tuần này tôi migrate sang Vultr High Frequency AMD ở Singapore. Trả thêm khoảng $20/tháng. RTT về 60ms. Bài này là benchmark thật + bài học khi nào region quan trọng hơn giá CPU.

Đo trước khi đổi — số gốc

Đo từ 3 client ở Hà Nội (Viettel FTTH, FPT FTTH, 4G Viettel), curl tới https://daivietpha.vn/healthz (endpoint Laravel trả “ok”), 30 request mỗi client, median:

Metric	Hetzner Falkenstein	Mục tiêu cá nhân
Ping RTT (ICMP)	278 ms	<100ms
TCP handshake	280 ms	—
TLS handshake (TLS 1.3)	290 ms (1-RTT)	—
TTFB (HTTPS)	1,180 ms	<500ms
DOMContentLoaded (cold)	2,400 ms	<1s
Lighthouse LCP (4G Việt mô phỏng)	3,800 ms	<2.5s

LCP 3.8 giây là đỏ kè trên Lighthouse. Google PageSpeed báo “Poor Core Web Vitals” — tức là SEO bị penalty cho người dùng VN. Đối với một landing trang giới thiệu daivietpha.vn (target user 100% là gia đình Việt), đây là deal-breaker, không phải tinh chỉnh.

CPU thì sao — Hetzner vs Vultr Singapore

Vì tôi đã chốt AMD EPYC bằng bài trước, vấn đề thực sự là so giữa hai region.

	Hetzner CPX31 (Falkenstein)	Vultr HF AMD Singapore
vCPU	4 (AMD EPYC Milan, shared)	4 (AMD EPYC Genoa, shared HF)
RAM	8 GB	8 GB
Disk	160 GB NVMe	256 GB NVMe
Bandwidth	20 TB	5 TB
Giá	€15.90 (~$17)	$48
Sysbench CPU (1 thread, prime 20k)	8.2s	7.6s (~8% nhanh hơn)
Sysbench fileio rndrw 1G	142 MB/s	186 MB/s (~30% nhanh hơn)
RTT từ Hà Nội	278 ms	62 ms

Vultr Singapore thực ra nhanh hơn về CPU và disk (vì là EPYC Genoa Zen 4, mới hơn 1 thế hệ so với Milan Zen 3 của Hetzner CPX). Nhưng đó là detail. Sự khác biệt lớn nằm ở RTT.

Giá đắt hơn $30/tháng. Nhưng bandwidth 5TB là vừa đủ cho landing + API — tôi chưa từng vượt 200GB/tháng. Không bị bottleneck.

Sau khi đổi — số sau migrate

Cùng client, cùng endpoint, cùng giờ:

Metric	Hetzner	Vultr SG	Cải thiện
Ping RTT	278 ms	62 ms	-78%
TLS handshake (1-RTT)	290 ms	70 ms	-76%
TTFB (HTTPS)	1,180 ms	284 ms	-76%
DOMContentLoaded (cold)	2,400 ms	720 ms	-70%
Lighthouse LCP (4G VN)	3,800 ms	1,650 ms	-57%
PageSpeed Mobile Score (VN)	41	88	+47 điểm

PageSpeed nhảy từ Poor sang Good chỉ vì datacenter gần khách 220ms hơn. Tôi không tối ưu một dòng code nào.

Vì sao RTT quan trọng hơn CPU cho web

Bài học này hiển nhiên nhưng đa số dev (kể cả tôi) bỏ qua khi so VPS plan. Lý do:

1. HTTP cần round-trip để bắt đầu serve byte đầu tiên.

Một request HTTPS bình thường cần ít nhất:

1 RTT cho TCP SYN/SYN-ACK
1 RTT cho TLS 1.3 handshake (TLS 1.2 cần 2 RTT)
1 RTT cho HTTP request + first byte response

= 3 RTT trước khi browser nhận được byte đầu tiên. Với RTT 280ms → ~840ms latency thuần trước cả khi server xử lý request. Server có nhanh 50ms hay 200ms không quan trọng — nó chìm trong noise của RTT.

Với RTT 60ms → 180ms RTT-overhead. Server 200ms TTFB nội bộ giờ chiếm 50% thời gian thực sự đáng tối ưu — và bạn có thể tối ưu nó.

2. CDN không cứu được dynamic content.

Tôi từng nghĩ “cứ đặt Cloudflare CDN trước Hetzner là xong”. Sai. Cloudflare cache static asset (CSS/JS/ảnh) tốt — nhưng request tới /api/... hay route Laravel render server-side đều cần đi tới origin. CDN bypass = vẫn 280ms RTT. Trang Đại Việt Phả 80% là dynamic (login, dashboard, cây gia phả), 20% là static — CDN chỉ giải quyết 20% bài toán.

3. WebSocket + real-time càng đau.

Tôi có một module chat trong app. WebSocket latency = RTT. Với 280ms RTT → mọi tin nhắn delay 280ms tối thiểu, cảm nhận rõ rệt là chậm. Với 60ms → cảm giác instant. Đây không phải số đo Lighthouse — đây là cảm giác user.

Khi nào nên chọn Hetzner (Đức) thay vì Vultr Singapore

Đừng đọc bài này rồi nghĩ “Vultr Singapore luôn tốt hơn Hetzner”. Sai. Khi nào Hetzner thắng:

User base ở EU: ngược lại với case của tôi. Khách bạn ở Pháp/Đức/Anh → Hetzner thắng tuyệt đối, Vultr Singapore RTT 250ms ngược lại.
Workload là batch/background job: cron job nightly không quan tâm RTT. Hetzner rẻ hơn 2-3×, dùng.
Storage + bandwidth-heavy: Hetzner 160GB NVMe + 20TB traffic với €16. Vultr cùng tier ~$80. Nếu app serve video / image gallery lớn → Hetzner.
Staging / preview environment: latency không quan trọng cho dev. Hetzner.
Dev personal projects without users: không có khách → không có latency → Hetzner cả ngày.

Khi nào nên chọn Vultr Singapore (hoặc tương đương DC ở Asia)

Khách chính ở Đông Nam Á (VN, Thái, Indo, Philippines, Mã Lai): Singapore là centroid tốt, RTT 30-80ms tới hầu hết các nước này.
App là consumer-facing, mobile-heavy: mobile network thường có jitter + retry; mỗi RTT thừa khuếch đại thành 2-3× độ chậm cảm nhận được.
Real-time (chat, livestream, multiplayer game): RTT là metric chính.
SEO mục tiêu thị trường địa phương: Google đo Core Web Vitals từ Chrome user thật. User VN trên Chrome → bạn cần TTFB <600ms từ VN → cần DC <100ms RTT.

Datacenter Singapore của các provider:

Vultr: HF AMD SG. Tôi đang dùng.
DigitalOcean: SGP1 region, Premium AMD.
Linode (Akamai): SG datacenter.
AWS: ap-southeast-1.
GCP: asia-southeast1.

Còn DC tại Việt Nam (Viettel IDC, VNG Cloud, FPT Cloud): tôi tránh — chính sách license phần mềm không rõ, support tiếng Anh kém, peering quốc tế chậm cho user nước ngoài. Singapore là sweet spot.

Migrate experience — 4 giờ end-to-end

Quy trình tôi làm cho ai cần tham khảo:

Snapshot Hetzner trước — bảo hiểm. Hetzner snapshot €0.011/GB/tháng, vài cent.
Setup Vultr Singapore mới — 5 phút từ click tới SSH được.
Provision baseline: Ubuntu 24.04 LTS, Docker, docker-compose, ufw, fail2ban. Tôi có script Ansible nên đoạn này 20 phút.
mysqldump trên Hetzner → scp về máy local → upload sang Vultr. Khoảng 1.2GB nén, mất 8 phút (đi qua máy local vì peering Hetzner ↔ Vultr không tốt; nếu dùng rsync trực tiếp Hetzner ↔ Vultr mất gần 40 phút).
Git clone repo, docker compose up -d, restore MySQL, chạy migration mới nếu có.
Switch DNS — A record daivietpha.vn từ IP Hetzner sang IP Vultr. TTL tôi đã hạ xuống 300s từ trước 2 ngày → DNS propagation hoàn tất sau ~10 phút.
Theo dõi log Vultr 30 phút — không lỗi → tắt Hetzner.
Sau 7 ngày yên ổn → destroy Hetzner instance. Snapshot giữ 30 ngày phòng cần rollback.

Tổng: 4 tiếng đồng hồ tay làm, downtime <2 phút (DNS switchover).

Kết — region trước, CPU sau

Quy trình chọn VPS đúng theo tôi:

Xác định user base ở đâu → chọn region datacenter trước.
Trong region đó, xem provider nào có dòng AMD EPYC → chọn provider.
Trong dòng AMD EPYC đó, chọn plan vừa CPU + RAM + disk → chọn plan cụ thể.

Đa số bài compare VPS trên Reddit/HN ngược lại — họ so giá vCPU rồi mới nhìn region. Đúng cho user toàn cầu (SaaS phục vụ Mỹ + EU + Asia đồng đều). Sai cho 95% dev freelance / startup nhỏ chỉ phục vụ 1 thị trường địa phương.

Hetzner vẫn là VPS provider tôi yêu nhất về giá. Nhưng nếu khách bạn ở Đông Nam Á và bạn còn ngồi trên Hetzner EU — bạn đang trả thuế latency 1 giây mỗi page load. Đó là cái giá đắt hơn cả $30/tháng chênh lệch.

Nguồn

Hetzner Cloud pricing và datacenter location: hetzner.com/cloud.
Vultr High Frequency AMD plan: vultr.com/products/high-frequency-compute.
TLS 1.3 1-RTT handshake reference: RFC 8446 §2.
Open-Meteo Asia-Pacific latency benchmarks (peering quality): public RIPE Atlas measurement IDs 78431201-78431203, tháng 4/2026.
PageSpeed Insights mobile benchmark via pagespeed.web.dev — slow 4G profile, Hà Nội VN field data.