Reverse proxy cho API: header, timeout, body size và cache

Proxy là lớp vận hành quan trọng#

Trong production, request hiếm khi đi thẳng từ browser tới app. Nó thường đi qua CDN, load balancer hoặc reverse proxy như Nginx. Proxy có thể terminate TLS, route request, set header, giới hạn body size, timeout upstream, nén response và cache nội dung public. Nếu proxy cấu hình sai, app đúng vẫn có thể lỗi.

Developer backend nên hiểu proxy ở mức đủ để debug. Khi upload lỗi 413, redirect loop, log toàn IP nội bộ hoặc request chậm bị cắt ngang, nguyên nhân thường nằm ở lớp proxy.

Header chuyển tiếp phải nhất quán#

App thường cần biết host gốc, scheme gốc và IP client. Proxy cần chuyển các header phù hợp như Host, X-Forwarded-Proto và X-Forwarded-For. Đồng thời app phải được cấu hình tin proxy đáng tin cậy, tránh tin bừa header do client tự gửi.

location / {
  proxy_pass http://app:3000;
  proxy_set_header Host $host;
  proxy_set_header X-Forwarded-Proto $scheme;
  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
  proxy_set_header X-Request-Id $request_id;
}

X-Request-Id hoặc correlation id giúp lần theo một request qua proxy, app, worker và log. Nếu hệ thống có nhiều service, id này là một trong những công cụ debug rẻ nhất.

Timeout nên được thiết kế theo dependency#

Timeout quá thấp gây lỗi giả trong giờ cao điểm. Timeout vô hạn làm request treo, chiếm connection và che giấu sự cố upstream. Cần đặt timeout ở nhiều lớp: client, CDN/proxy, app server, HTTP client nội bộ, database và queue worker.

Nguyên tắc thực tế là timeout phía ngoài nên lớn hơn một chút so với timeout phía trong. Nếu app gọi service ngoài với timeout 8 giây, proxy timeout 5 giây sẽ cắt request trước khi app xử lý xong. Ngược lại, nếu app không có timeout nhưng proxy chờ 60 giây, hệ thống có thể bị cạn tài nguyên khi dependency bị treo.

Body size và upload#

API upload cần giới hạn body size rõ. Không giới hạn có thể bị abuse; giới hạn quá thấp gây lỗi upload hợp lệ. Nếu upload file lớn, cân nhắc upload trực tiếp lên object storage bằng signed URL, sau đó app chỉ nhận metadata. Cách này giảm tải app server và proxy.

Cache ở proxy cần phân biệt public và private#

Không phải response nào cũng nên cache. Bài blog public, asset tĩnh và RSS có thể cache. Dashboard admin, API có dữ liệu user, response chứa cookie hoặc authorization thì không nên cache public. Header Cache-Control phải thể hiện đúng ý định.

• public: response có thể được cache bởi shared cache nếu phù hợp.
• private: chỉ cache ở browser người dùng, không cache ở shared proxy.
• no-store: không lưu response.
• s-maxage: TTL dành cho shared cache như CDN.

Checklist proxy cho API#

• Header Host, scheme và client IP được chuyển đúng.
• App chỉ tin proxy/header từ nguồn đáng tin.
• Timeout ở proxy và app không mâu thuẫn nhau.
• Body size limit phù hợp từng endpoint.
• Public cache không áp vào route có dữ liệu cá nhân.
• Request id được tạo hoặc giữ xuyên suốt hệ thống.
• Log proxy có method, path, status, upstream time và request id.

Nguồn tham khảo chính#

• NGINX Docs: HTTP proxy module
• MDN: Cache-Control
• MDN: X-Forwarded-For