Reverse proxy là gì? Khác forward proxy, load balancer và CDN ra sao

Reverse proxy là gì là câu hỏi gần như ai tự quản lý VPS cũng gặp, nhất là khi chạy app Node.js, Python hay Docker. Hiểu đơn giản, reverse proxy là máy chủ đứng trước ứng dụng của bạn. Nó nhận mọi request từ người dùng, chuyển vào đúng ứng dụng phía sau, rồi trả kết quả về. Bài này giải thích cách hoạt động, lợi ích và sự khác nhau giữa reverse proxy với forward proxy, load balancer và CDN.

Reverse proxy hoạt động thế nào?

Hãy hình dung một tòa nhà văn phòng có quầy lễ tân. Khách không đi thẳng vào từng phòng. Họ đến quầy, lễ tân hỏi việc, rồi dẫn tới đúng phòng. Reverse proxy chính là quầy lễ tân đó.

Luồng xử lý một request thường như sau:

1. Trình duyệt gửi request tới https://example.com. DNS trỏ tên miền về IP của reverse proxy.
2. Reverse proxy nhận kết nối ở cổng 443, giải mã HTTPS.
3. Dựa vào tên miền, đường dẫn hoặc quy tắc khác, nó chuyển request tới backend phù hợp, ví dụ 127.0.0.1:3000.
4. Backend xử lý, trả kết quả cho reverse proxy.
5. Reverse proxy gửi kết quả về trình duyệt.

Người dùng chỉ nói chuyện với reverse proxy. Họ không biết phía sau có bao nhiêu máy chủ, chạy công nghệ gì, ở địa chỉ nào.

Ví dụ cấu hình Nginx đơn giản

Với Nginx, chỉ thị proxy_pass đặt trong khối location là đủ để biến Nginx thành reverse proxy:

server {
    listen 80;
    server_name example.com;

    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-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Theo tài liệu Nginx, mặc định Nginx thay đổi hai header khi chuyển request: Host được đặt bằng biến $proxy_host, còn Connection được đặt là close. Vì vậy ta thường khai báo lại Host để backend biết khách đang truy cập tên miền nào. Các header X-Forwarded-* giúp backend biết IP thật và giao thức gốc của khách. Khi chạy app có WebSocket, cần khai báo thêm header Upgrade và Connection như phần lưu ý bên dưới.

Lợi ích của reverse proxy

Xử lý SSL tập trung

Reverse proxy giữ chứng chỉ SSL và giải mã HTTPS. Ứng dụng phía sau chỉ cần nói HTTP nội bộ. Khi có nhiều app trên một VPS, bạn quản lý chứng chỉ ở một chỗ. Xem thêm về các loại chứng chỉ trong bài chứng chỉ SSL là gì.

Chạy nhiều website, nhiều app trên một IP

Một VPS thường chỉ có một IPv4. Reverse proxy đọc tên miền trong request để chuyển blog.example.com vào WordPress, api.example.com vào Node.js, n8n.example.com vào container n8n. Đây là cách các bài hướng dẫn Docker trên Canh Deal vẫn dùng.

Che giấu và bảo vệ backend

Backend chỉ nghe ở 127.0.0.1 hoặc mạng nội bộ, không mở cổng ra Internet. Kẻ tấn công chỉ thấy reverse proxy. Bạn có thể đặt giới hạn tốc độ, chặn IP, chặn đường dẫn nhạy cảm ngay tại lớp này.

Cache và phục vụ file tĩnh

Reverse proxy có thể tự trả ảnh, CSS, JS mà không cần gọi tới app, hoặc lưu tạm kết quả trả về. Việc này giảm tải cho backend.

Đệm với người dùng mạng chậm

Tài liệu Nginx cho biết buffering bật mặc định: Nginx nhận trọn phản hồi từ backend rồi mới gửi dần cho khách. Backend được giải phóng sớm, không phải chờ người dùng mạng chậm tải xong. Với luồng dữ liệu cần gửi ngay như streaming, bạn có thể tắt bằng proxy_buffering off.

Cân bằng tải

Khi có nhiều backend, reverse proxy có thể chia request cho chúng. Phần này được nói kỹ hơn ở mục load balancer bên dưới.

Reverse proxy khác forward proxy thế nào?

Hai khái niệm này dễ nhầm vì cùng chữ "proxy". Điểm khác nằm ở việc proxy đứng về phía ai.

Proxy bạn mua để nuôi tài khoản, chạy quảng cáo hay đổi IP là forward proxy. Chi tiết xem bài proxy là gì.

Reverse proxy và load balancer

Load balancer chia request cho nhiều máy chủ để không máy nào quá tải. Nhiều reverse proxy như Nginx, HAProxy có sẵn chức năng này. Nói cách khác, cân bằng tải là một việc reverse proxy có thể làm, nhưng không bắt buộc.

Theo tài liệu Nginx, các phương pháp cân bằng tải cơ bản gồm:

• Round-robin (mặc định): lần lượt chia request cho từng máy.
• least_conn: gửi request tới máy đang có ít kết nối nhất, hợp khi có request xử lý lâu.
• ip_hash: cùng một IP khách luôn vào cùng một máy, giúp giữ phiên đăng nhập.

upstream myapp {
    least_conn;
    server 10.0.0.11:3000 max_fails=3 fail_timeout=30s;
    server 10.0.0.12:3000 max_fails=3 fail_timeout=30s;
}

server {
    listen 80;
    location / {
        proxy_pass http://myapp;
    }
}

Với cấu hình trên, máy nào lỗi 3 lần trong 30 giây sẽ bị tạm loại trong 30 giây, sau đó Nginx thử lại. Đây là kiểu kiểm tra sức khỏe thụ động, dựa trên request thật của khách.

Reverse proxy và CDN

CDN là mạng lưới nhiều máy chủ đặt ở nhiều nơi, mỗi máy hoạt động như một reverse proxy có cache. Người dùng ở Hà Nội được phục vụ từ điểm gần Hà Nội, người ở Mỹ được phục vụ từ điểm ở Mỹ. Bạn có thể coi CDN là reverse proxy phân tán trên toàn cầu, do nhà cung cấp vận hành.

Trên thực tế, nhiều website dùng cả hai lớp: Cloudflare (CDN) đứng ngoài cùng, Nginx (reverse proxy) đứng trên VPS, app đứng sau Nginx. Xem thêm bài CDN là gì và hướng dẫn đưa website qua Cloudflare.

Phần mềm reverse proxy phổ biến

• Nginx: phổ biến nhất, nhẹ, tài liệu nhiều. Phù hợp hầu hết VPS.
• Apache: dùng module mod_proxy. Hợp khi máy chủ đã chạy Apache sẵn.
• HAProxy: chuyên cân bằng tải, mạnh ở tầng TCP và HTTP.
• Caddy: cấu hình ngắn gọn, tự xin chứng chỉ HTTPS.
• Traefik: tự nhận cấu hình từ Docker, Kubernetes, hợp với hệ thống container.
• Nginx Proxy Manager: giao diện web quản lý Nginx, tiện cho người mới.

So sánh Nginx với Apache và LiteSpeed ở vai trò web server có trong bài LiteSpeed, Nginx hay Apache.

Khi nào bạn cần reverse proxy?

• Chạy app Node.js, Python, Go, Java trên VPS và muốn dùng tên miền với HTTPS.
• Chạy nhiều website hoặc nhiều container Docker trên một VPS, một IP.
• Muốn ẩn cổng nội bộ, không mở trực tiếp app ra Internet.
• Có từ hai máy chủ ứng dụng trở lên và cần chia tải.

Nếu bạn chỉ dùng shared hosting chạy WordPress, nhà cung cấp đã lo phần này. Reverse proxy trở nên quan trọng khi bạn tự quản lý VPS.

Lưu ý khi dùng reverse proxy

• IP thật của khách: backend sẽ thấy mọi request đến từ 127.0.0.1. Cần truyền X-Forwarded-For và cấu hình app tin tưởng đúng proxy, nếu không log và giới hạn tốc độ sẽ sai.
• Đừng tin header từ bên ngoài: chỉ tin X-Forwarded-* khi request đi qua proxy của bạn, vì client có thể tự gửi header giả.
• WebSocket: cần khai báo thêm header Upgrade và Connection, nếu không kết nối realtime sẽ lỗi.
• Lỗi 502, 504: thường do backend chưa chạy, sai cổng hoặc xử lý quá lâu. Kiểm tra backend trước, rồi mới xem cấu hình proxy.
• Thêm một điểm lỗi: nếu reverse proxy sập, mọi app phía sau cũng không truy cập được. Hãy luôn chạy nginx -t trước khi reload.

Nguồn tham khảo

• NGINX Docs: NGINX Reverse Proxy
• nginx.org: Using nginx as HTTP load balancer
• nginx.org: WebSocket proxying
• Apache HTTP Server: mod_proxy