Đặt edge server tại Tokyo nghĩa là dùng một VPS nhỏ đứng giữa người dùng Đông Á và máy chủ gốc (origin) đặt ở nơi khác, thường là châu Âu hoặc Mỹ. Máy này bắt tay TLS ngay gần người dùng, giữ sẵn kết nối tới origin để dùng lại, và trả thẳng các phản hồi có thể cache từ Tokyo. Bạn có được một phần những gì CDN làm, nhưng toàn quyền kiểm soát quy tắc, trên một máy chủ bạn SSH vào được. Bài này giải thích khi nào mô hình này đáng làm, cấu hình Nginx có cache chạy được, phương án Caddy đơn giản hơn, và cách kiểm tra mọi thứ hoạt động đúng như bạn nghĩ.
Edge node đứng trước origin hoạt động thế nào
Khi chưa có edge, một người dùng ở Tokyo hay Seoul phải mở kết nối TCP và bắt tay TLS với origin ở châu lục khác. Mỗi lần bắt tay là một lượt đi về qua quãng đường dài trước khi byte đầu tiên của trang tới nơi.
Khi có edge ở Tokyo:
- Người dùng kết nối tới VPS Tokyo, việc bắt tay TCP và TLS diễn ra trên đường mạng ngắn trong khu vực.
- Nếu phản hồi đã nằm trong cache, Tokyo trả lời ngay và không cần hỏi origin.
- Nếu chưa có, edge chuyển request qua kết nối tới origin đã mở sẵn và được giữ sống, nên mỗi request chỉ đi qua quãng đường dài một lần thay vì vài lần.
Origin vẫn chạy ứng dụng và database như cũ. Edge không giữ trạng thái gì ngoài cache, nên dựng lại rất dễ.
Khi nào nên đặt edge server tại Tokyo
Mô hình này hữu ích khi:
- Một phần đáng kể người dùng ở Nhật, Hàn, Đài Loan hoặc lân cận, còn origin ở xa.
- Nhiều phản hồi có thể cache: trang sản phẩm, tài liệu, hình ảnh, API trả cùng kết quả cho mọi người.
- Bạn cần quyền kiểm soát mà gói CDN không cho: cache key tùy chỉnh, một IP ra cố định để đưa vào allowlist, hoặc log nằm trên ổ đĩa của chính bạn.
Ít hữu ích, thậm chí không giúp gì, khi:
- Gần như mọi request đều cá nhân hóa và không cache được. Bạn vẫn tiết kiệm thời gian bắt tay, nhưng request nào cũng phải đi đường dài.
- Người dùng rải khắp thế giới. Một edge duy nhất ở Tokyo khiến khách ở châu Âu phải đi vòng qua Nhật. Khi đó cần GeoDNS để chỉ đưa khách Đông Á vào Tokyo, hoặc dùng CDN đầy đủ.
- Cách đúng là chuyển luôn origin. Nếu phần lớn người dùng ở Đông Á, chạy ứng dụng ngay tại Tokyo đơn giản hơn; bài VPS Nhật Bản tốt nhất phân tích lựa chọn đó.
Nếu đang phân vân giữa các thành phố châu Á, bài so sánh VPS Singapore, Hồng Kông và Tokyo sẽ giúp bạn, còn hướng dẫn VPS châu Á nhìn rộng hơn toàn khu vực. Với người dùng Việt Nam và Đông Nam Á, có thể đặt thêm một edge ở Singapore song song với Tokyo, giống cách người ta đặt bot giao dịch crypto ở Singapore gần các hệ thống mà nó làm việc cùng.
Chọn cấu hình VPS Tokyo
Reverse proxy ở edge tốn ít CPU, RAM chủ yếu dành cho chỉ mục cache và page cache của hệ điều hành. Một gói general purpose nhỏ là điểm khởi đầu hợp lý; tại Tokyo, Cloudj có 30 gói dựng sẵn từ 1 vCPU, 1 GB RAM, 20 GB ổ đĩa, hoặc bạn tự phối vCPU, RAM, ổ đĩa. Hãy để ổ đĩa đủ rộng cho cache.
Cần để ý băng thông. Mọi byte edge trả cho người dùng đều đi ra từ Tokyo, và các lần cache miss còn kéo dữ liệu từ origin về. Gói tháng tại Tokyo có sẵn 1 TB băng thông; khi tính giờ, băng thông được tính theo GB. Xem trang VPS Nhật Bản và giá trực tiếp trên trang bảng giá.
Cấu hình Nginx reverse proxy kèm cache
Giả định bạn dùng Ubuntu hoặc Debian đã cài Nginx, DNS của www.example.com trỏ về VPS Tokyo, và origin truy cập được qua origin.example.com, đồng thời phục vụ www.example.com với chứng chỉ hợp lệ. Lấy chứng chỉ cho edge trước bằng Certbot (sudo certbot certonly --nginx -d www.example.com), như hướng dẫn trong bài Nginx reverse proxy kèm SSL.
Tạo file /etc/nginx/conf.d/edge.conf:
proxy_cache_path /var/cache/nginx/edge levels=1:2 keys_zone=edge:50m
max_size=10g inactive=7d use_temp_path=off;
upstream origin {
server origin.example.com:443;
keepalive 16;
}
server {
listen 443 ssl;
server_name www.example.com;
ssl_certificate /etc/letsencrypt/live/www.example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/www.example.com/privkey.pem;
location / {
proxy_pass https://origin;
proxy_http_version 1.1;
proxy_set_header Connection "";
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto https;
proxy_ssl_server_name on;
proxy_ssl_name $host;
proxy_ssl_verify on;
proxy_ssl_trusted_certificate /etc/ssl/certs/ca-certificates.crt;
proxy_cache edge;
proxy_cache_valid 200 301 10m;
proxy_cache_valid 404 1m;
proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504;
proxy_cache_background_update on;
proxy_cache_lock on;
proxy_cache_bypass $cookie_session;
proxy_no_cache $cookie_session;
add_header X-Cache-Status $upstream_cache_status always;
}
}Ý nghĩa của các dòng quan trọng:
keepalive 16cùngproxy_http_version 1.1và headerConnectionrỗng giữ kết nối tới origin luôn mở; phần lớn lợi ích với request không cache đến từ đây.proxy_ssl_server_namevàproxy_ssl_name $hostgửi đúng SNI để origin trả đúng chứng chỉ, cònproxy_ssl_verifykiểm tra chứng chỉ đó.proxy_cache_use_staletiếp tục trả trang trong cache nếu origin tạm thời không truy cập được.- Hai dòng
$cookie_sessionbỏ qua cache với người dùng đã đăng nhập; hãy đổisessionthành tên cookie phiên của ứng dụng bạn.
Nginx cũng tôn trọng header Cache-Control từ origin và không cache phản hồi có đặt cookie, nên origin vẫn quyết định cái gì được cache. Lưu ý Nginx phân giải origin.example.com lúc khởi động; nếu IP của origin đổi, hãy reload Nginx. Áp dụng cấu hình bằng sudo nginx -t && sudo systemctl reload nginx. Chi tiết từng directive có trong tài liệu module proxy của Nginx.
Trên origin, chỉ cho phép lưu lượng web từ IP của edge (và các edge khác nếu có) để không ai đi vòng qua cache, đồng thời ghi log X-Forwarded-For để giữ IP thật của người truy cập.
Phương án đơn giản hơn: Caddy
Nếu bạn muốn HTTPS tự động gần như không cần cấu hình và không cần cache, Caddy là lựa chọn hợp lý. Caddyfile tối thiểu cho origin chỉ nhận đúng tên miền của chính nó:
www.example.com {
reverse_proxy https://origin.example.com {
header_up Host {upstream_hostport}
}
}Caddy tự lấy và gia hạn chứng chỉ. Bản Caddy tiêu chuẩn không có HTTP cache, nên phương án này tiết kiệm thời gian bắt tay nhưng không trả trang từ Tokyo. Khi cache là yếu tố quan trọng, hãy chọn Nginx.
Kiểm tra và xử lý sự cố
Gọi cùng một URL hai lần và đọc header cache:
curl -sI https://www.example.com/ | grep -i x-cache-statusLần đầu nên thấy MISS, lần sau thấy HIT. Để so thời gian, chạy curl -o /dev/null -s -w "%{time_starttransfer}\n" https://www.example.com/ từ một máy trong khu vực, lần lượt với edge và origin. Muốn kiểm tra ở tầng mạng, bài đo độ trễ VPS bằng ping và mtr hướng dẫn cách đọc đường đi.
| Hiện tượng | Nguyên nhân thường gặp | Cách xử lý |
|---|---|---|
Luôn MISS | Origin gửi Cache-Control: private hoặc no-store, hoặc đặt cookie | Sửa header của origin cho trang công khai |
Ai cũng BYPASS | Cookie dùng để bypass được đặt cho mọi khách | Chỉ bypass theo cookie đăng nhập |
| Lỗi 502 | SNI hoặc chứng chỉ không khớp khi gọi origin | Kiểm tra proxy_ssl_name và chứng chỉ của origin |
| Người khác thấy trang cá nhân | Trang cá nhân bị cache | Thêm quy tắc proxy_no_cache cho các đường dẫn đó |
Câu hỏi thường gặp
Cách này có thay được CDN không?
Không hoàn toàn. Bạn có một điểm cache đặt đúng chỗ và nằm trong tay mình, còn CDN cho nhiều vị trí cùng lúc. Nhiều team dùng cả hai.
Sau này có thêm edge khác được không?
Được. Lưu máy Tokyo đã cấu hình thành custom image, triển khai ở vị trí khác rồi điều hướng người dùng bằng GeoDNS.
Edge có cần nhiều CPU không?
Thường là không. TLS và proxy khá nhẹ; ổ đĩa và băng thông thường quan trọng hơn. Hãy theo dõi số liệu trong console sau khi chạy.
Dựng edge Tokyo của bạn
Triển khai một máy chủ Tokyo nhỏ trong console Cloudj, áp dụng cấu hình Nginx ở trên và trỏ một hostname thử nghiệm vào trước khi đổi DNS production. Theo dõi header cache và biểu đồ băng thông trong một tuần, rồi quyết định giữ nguyên, nâng cấu hình hay thêm edge thứ hai. Người dùng tại Việt Nam có thể nạp số dư bằng chuyển khoản ngân hàng bằng VND.