# Đặt edge server tại Tokyo làm reverse proxy trước máy chủ gốc

URL: https://cloudj.net/vi/blog/tokyo-edge-reverse-proxy
Published: 2026-11-11 · Updated: 2026-11-11

> Cách đặt edge server tại Tokyo trước máy chủ gốc ở nơi khác: khi nào đáng làm, cấu hình Nginx reverse proxy kèm cache, phương án Caddy và cách kiểm tra cache.

Đặ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:

1. 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.
2. Nếu phản hồi đã nằm trong cache, Tokyo trả lời ngay và không cần hỏi origin.
3. 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](https://cloudj.net/vi/blog/best-vps-japan) 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](https://cloudj.net/vi/blog/singapore-vs-hong-kong-vs-tokyo-vps) sẽ giúp bạn, còn [hướng dẫn VPS châu Á](https://cloudj.net/vi/blog/asia-vps-guide) 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](https://cloudj.net/vi/blog/crypto-trading-bot-vps-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](https://cloudj.net/vi/cloud-servers/japan) và giá trực tiếp trên [trang bảng giá](https://cloudj.net/vi/pricing).

## 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](https://cloudj.net/vi/blog/nginx-reverse-proxy-ssl-vps).

Tạo file `/etc/nginx/conf.d/edge.conf`:

```nginx
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 16` cùng `proxy_http_version 1.1` và header `Connection` rỗ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_name` và `proxy_ssl_name $host` gửi đúng SNI để origin trả đúng chứng chỉ, còn `proxy_ssl_verify` kiểm tra chứng chỉ đó.
- `proxy_cache_use_stale` tiếp tục trả trang trong cache nếu origin tạm thời không truy cập được.
- Hai dòng `$cookie_session` bỏ qua cache với người dùng đã đăng nhập; hãy đổi `session` thà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](https://nginx.org/en/docs/http/ngx_http_proxy_module.html).

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ó:

```text
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:

```bash
curl -sI https://www.example.com/ | grep -i x-cache-status
```

Lầ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](https://cloudj.net/vi/blog/test-vps-latency-ping-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](https://app.cloudj.net), á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.