Cấu hình Nginx reverse proxy trên VPS Singapore cho API: luồng request và log

Lưu ý: Các lệnh và chỉ số trong bài để tham khảo, cần thử trong môi trường phù hợp và xác minh tính năng thực tế theo gói dịch vụ. Không sử dụng để truy cập hệ thống không được phép.

Một API đặt trên VPS Singapore thường gồm hai lớp: ứng dụng chạy trên cổng nội bộ và máy chủ web đứng ở phía ngoài. Với mô hình này, Nginx reverse proxy giúp kết thúc kết nối HTTPS, chuyển request tới ứng dụng và gom log tại một điểm. Nginx không tự làm API nhanh hơn; lợi ích chính là kiểm soát đường vào, chuyển tiếp header và tách cấu hình mạng khỏi mã nguồn ứng dụng.

Bài viết dùng ví dụ API lắng nghe ở 127.0.0.1:3000 trên chính VPS. Hãy thử trên môi trường staging trước. Nếu API đặt ở máy khác, cần thay địa chỉ upstream và áp dụng kiểm soát firewall tương ứng.

Sơ đồ một request đi qua Nginx

Trình duyệt hoặc client gọi https://api.example.com. DNS đưa yêu cầu tới IP VPS, Nginx nhận kết nối trên cổng 443, sau đó chuyển HTTP request vào ứng dụng nội bộ. Phản hồi đi ngược qua Nginx về client. Cách thiết kế này cho phép đóng cổng ứng dụng với Internet và chỉ công khai 80/443 nếu thực sự cần.

Nếu có CDN hoặc load balancer phía trước, chuỗi có thêm một lớp. Khi đó địa chỉ IP client có thể nằm trong các header do proxy đáng tin cậy đặt vào. Không nên tin tùy ý một giá trị X-Forwarded-For từ Internet để phân quyền, chống gian lận hoặc giới hạn tốc độ.

Cấu hình tối thiểu cần hiểu trước khi triển khai

Ví dụ dưới đây minh họa phần location trong một server block đã cấu hình HTTPS. Không sao chép nguyên cấu hình vào production khi chưa có chứng chỉ và domain phù hợp.

location / {
    proxy_pass http://127.0.0.1:3000;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_connect_timeout 5s;
    proxy_read_timeout 60s;
}

proxy_pass không có dấu / sau cổng sẽ giữ nguyên URI trong trường hợp cấu hình phổ biến này. Nếu bạn thêm đường dẫn vào proxy_pass, cách thay thế URI có thể khác. Đây là nguyên nhân thường gặp khiến route /api/v1/... bị chuyển nhầm thành /v1/... hoặc ngược lại.

Test trước và sau khi reload

Trước hết, xác nhận ứng dụng trả về 200 tại endpoint health check nội bộ, chẳng hạn curl -I http://127.0.0.1:3000/health. Kiểm tra cú pháp bằng sudo nginx -t; chỉ khi lệnh trả về thành công mới sudo systemctl reload nginx. Reload thường không yêu cầu ngắt các kết nối hiện tại như dừng rồi khởi động lại service, nhưng vẫn cần giám sát lỗi thực tế.

Dùng curl -I https://api.example.com/health từ ít nhất một mạng bên ngoài. Kiểm tra log truy cập và log lỗi ở vị trí cấu hình Nginx của bạn. Một HTTP 502 thường có nghĩa Nginx không kết nối được upstream hoặc upstream trả về phản hồi không hợp lệ; HTTP 504 thường liên quan thời gian chờ, chứ không chứng minh VPS thiếu RAM.

Timeout, request body và WebSocket

API tải tệp lớn có thể cần điều chỉnh client_max_body_size; tăng vô hạn tạo thêm rủi ro lạm dụng băng thông và ổ đĩa. Đối với long-polling hoặc công việc chạy lâu, hãy đo độ dài request rồi đặt proxy_read_timeout phù hợp, tránh dùng timeout cực lớn để che việc thiết kế API đồng bộ quá tải.

Nếu dùng WebSocket, cần bổ sung cấu hình Upgrade và Connection đúng loại kết nối. Không nên mặc định rằng một cấu hình reverse proxy HTTP thông thường sẽ xử lý tất cả giao thức realtime giống nhau.

Đo trải nghiệm khách hàng Việt Nam khi origin ở Singapore

Từ mạng Việt Nam, đo cả thời gian bắt tay TCP/TLS lẫn thời gian xử lý API. Một request chậm có thể do tuyến quốc tế, truy vấn database ở vùng khác, hoặc ứng dụng phải gọi thêm API thứ ba. Đừng nâng CPU chỉ vì tổng time_total tăng: hãy so sánh với log thời gian xử lý backend.

Tập trung vào tỷ lệ lỗi 5xx, p95 latency và số lượng request mỗi giây ở cùng điều kiện tải. Sau mỗi thay đổi, giữ lại bản cấu hình cũ để rollback. Nếu Nginx và API cùng máy, hãy chắc chắn firewall không cho bên ngoài kết nối trực tiếp cổng 3000.

Những lỗi cần xử lý theo thứ tự

Khi chọn vị trí máy chủ cho API hướng khách Đông Nam Á, trang VPS Singapore là nơi đối chiếu cấu hình và thông tin gói hiện hành. Bài này là hướng dẫn kiến trúc, không phải bảng giá hay cam kết về tốc độ.

Đọc tiếp trong cùng chủ đề

Xem thêm: Đo độ trễ Việt Nam–Singapore cho VPS: ping, MTR và TTFB. Đối chiếu nhu cầu thực tế với trang VPS Singapore và thông tin gói đang bán.