Reverse proxy và load balancer là hai cái tên xuất hiện trong gần như mọi sơ đồ hạ tầng web, và cũng là hai cái tên bị dùng lẫn lộn nhiều nhất. Càng rối hơn khi cùng một phần mềm như Nginx hay HAProxy làm được cả hai việc. Bài này đi từ gốc: proxy là gì, reverse proxy làm những việc gì, load balancer chia tải ra sao, rồi chỉ ra chính xác chỗ hai khái niệm giao nhau và chỗ chúng tách rời.
Proxy thường và reverse proxy: cùng là người trung gian, đứng ở hai phía
Proxy là một máy đứng giữa, nhận yêu cầu thay cho bên này rồi chuyển tiếp sang bên kia. Điểm khác nhau giữa các loại proxy nằm ở chỗ nó làm việc cho ai.
Forward proxy (proxy thường) đứng về phía người dùng. Máy tính trong công ty hay trường học được cấu hình đi Internet qua một proxy; proxy thay mặt máy bạn gửi yêu cầu ra ngoài. Website ở đầu kia chỉ thấy địa chỉ IP của proxy, không thấy IP thật của bạn. Công ty dùng forward proxy để lọc nội dung, ghi log truy cập, hoặc tiết kiệm băng thông bằng cách lưu đệm những trang hay được mở.
Reverse proxy thì ngược lại: nó đứng về phía máy chủ. Người dùng gửi yêu cầu tới một địa chỉ duy nhất, ví dụ example.com, và không hề biết phía sau có một hay mười máy chủ. Reverse proxy nhận yêu cầu, chuyển vào máy chủ phù hợp ở mạng nội bộ, lấy kết quả rồi trả về như thể chính nó tạo ra câu trả lời.
Một cách nhớ đơn giản: forward proxy giấu người dùng khỏi máy chủ, reverse proxy giấu máy chủ khỏi người dùng.
| Forward proxy | Reverse proxy | |
|---|---|---|
| Đứng về phía | Người dùng | Máy chủ |
| Ai cấu hình | Người dùng hoặc quản trị mạng nội bộ | Chủ website |
| Giấu đi | IP của người dùng | IP và cấu trúc máy chủ |
| Ví dụ | Proxy công ty, Squid | Nginx, HAProxy, Caddy, Traefik |
Bốn việc chính của một reverse proxy
Reverse proxy không chỉ chuyển tiếp yêu cầu cho có. Giá trị của nó nằm ở những việc nó làm thay cho máy chủ phía sau.
1. Giải mã HTTPS (TLS termination)
Mỗi kết nối HTTPS đều cần bắt tay TLS, kiểm tra chứng chỉ và mã hoá, giải mã từng gói dữ liệu. Nếu có năm máy chủ ứng dụng, bạn phải cài và gia hạn chứng chỉ trên cả năm máy. Đặt reverse proxy phía trước thì chỉ nó giữ chứng chỉ và gánh hết phần mã hoá; máy chủ phía sau nhận HTTP thường trong mạng nội bộ, chỉ việc xử lý logic và trả dữ liệu. Quản lý chứng chỉ cũng gọn hơn hẳn vì chỉ còn một chỗ.
2. Lưu bộ nhớ đệm (caching)
Ảnh, file CSS, JavaScript và những trang ít thay đổi có thể được giữ sẵn ngay tại reverse proxy. Khi một nghìn người cùng xin một tấm ảnh, máy chủ ứng dụng chỉ phải trả đúng một lần, 999 lần còn lại reverse proxy tự trả từ bộ nhớ đệm. Reverse proxy cũng thường kiêm luôn việc nén gzip hoặc Brotli trước khi gửi về trình duyệt.
3. Định tuyến theo đường dẫn hoặc tên miền
Yêu cầu tới /api/ đi vào máy chủ ứng dụng Node.js, yêu cầu tới /blog/ đi vào máy chủ WordPress, còn /static/ lấy thẳng từ ổ đĩa. Bên ngoài chỉ thấy một tên miền duy nhất, bên trong là nhiều hệ thống viết bằng công nghệ khác nhau. Đây cũng là cách nhiều đội chuyển dần từ hệ thống cũ sang hệ thống mới: đổi từng đường dẫn một mà người dùng không nhận ra.
4. Che chắn và bảo vệ
Địa chỉ IP thật của máy chủ được giấu kín, kẻ tấn công chỉ chạm được tới reverse proxy. Tại đây có thể giới hạn tốc độ (rate limit) theo IP, chặn yêu cầu bất thường, giới hạn kích thước request, gắn tường lửa ứng dụng web (WAF) để lọc các kiểu tấn công phổ biến như SQL injection.
Cả bốn việc trên đều không cần tới máy chủ thứ hai. Một VPS duy nhất chạy Nginx phía trước ứng dụng vẫn được giải mã HTTPS, nén, lưu đệm và giới hạn tốc độ. Đây là điểm khác biệt quan trọng nhất so với load balancer.
Load balancer: chỉ có một mục tiêu là chia tải
Load balancer, hay bộ cân bằng tải, sinh ra để giải một bài toán duy nhất: chia yêu cầu cho nhiều máy chủ giống hệt nhau để không máy nào bị quá tải. Nếu website nhận mười nghìn yêu cầu mỗi giây và có ba máy chủ, mỗi máy chỉ phải gánh khoảng ba nghìn ba trăm.
Chia tải mang lại hai lợi ích song song:
- Mở rộng theo chiều ngang: thay vì mua một máy thật mạnh (và đắt), bạn thêm máy bình thường vào nhóm.
- Chịu lỗi: một máy hỏng, các máy còn lại vẫn phục vụ. Không còn điểm chết duy nhất ở tầng ứng dụng.
Điều kiện đi kèm: các máy trong nhóm phải chạy cùng một phiên bản ứng dụng và trả kết quả giống nhau, bất kể yêu cầu rơi vào máy nào.
Các thuật toán chia tải phổ biến
Round robin (xoay vòng) là cách đơn giản nhất: yêu cầu một vào máy A, yêu cầu hai vào máy B, yêu cầu ba vào máy C, rồi lại quay về máy A, đều đặn như chia bài. Đây là thuật toán mặc định của Nginx khi bạn khai báo một nhóm upstream.
Vấn đề của xoay vòng là nó không quan tâm yêu cầu nặng hay nhẹ. Nếu máy A tình cờ nhận vài yêu cầu xuất báo cáo tốn mấy chục giây, nó vẫn bị chia thêm việc như các máy đang rảnh.
Least connections (ít kết nối nhất) khắc phục điều đó: yêu cầu mới được gửi vào máy đang có ít kết nối mở nhất, tức máy đang rảnh nhất.
Có trọng số (weighted) dùng khi các máy không đều nhau: máy 16 nhân đặt trọng số 2, máy 8 nhân đặt trọng số 1, máy mạnh sẽ nhận phần nhiều gấp đôi.
Hash theo IP hoặc theo khoá luôn đưa cùng một nguồn vào cùng một máy, liên quan trực tiếp tới vấn đề phiên đăng nhập bên dưới.
Kiểm tra sức khoẻ và phiên đăng nhập
Health check: loại máy hỏng trước khi người dùng thấy lỗi
Load balancer liên tục kiểm tra sức khoẻ các máy chủ, thường vài giây một lần, bằng cách gửi một yêu cầu tới đường dẫn kiểm tra như /health. Máy nào không phản hồi, hoặc trả mã lỗi, bị loại khỏi danh sách ngay; yêu cầu mới chỉ đi vào các máy còn khoẻ. Khi máy đó sống lại và vượt qua vài lần kiểm tra liên tiếp, nó được đưa vào lại.
Có hai kiểu kiểm tra. Chủ động là load balancer tự gửi yêu cầu thăm dò định kỳ. Thụ động là theo dõi lưu lượng thật: máy nào lỗi liên tiếp nhiều lần thì tạm loại. Bản Nginx mã nguồn mở dùng kiểu thụ động qua tham số max_fails và fail_timeout; kiểm tra chủ động có sẵn trong HAProxy và các load balancer của nhà cung cấp đám mây.
Một /health chỉ trả về "OK" cho biết tiến trình còn chạy, nhưng không cho biết máy đó có kết nối được cơ sở dữ liệu hay không. Kiểm tra nhanh các phụ thuộc quan trọng (database, cache) giúp load balancer loại đúng máy đang hỏng thật sự. Đừng làm nó quá nặng, vì nó được gọi liên tục.
Sticky session: khi người dùng bị "đá" ra ngoài
Bạn đăng nhập ở máy A, phiên đăng nhập lưu trong bộ nhớ của máy A. Yêu cầu tiếp theo bị chia sang máy B, máy B không biết bạn là ai, thế là bạn bị đăng xuất. Đây là lỗi kinh điển khi mới thêm load balancer vào hệ thống.
Có hai cách xử lý:
- Sticky session: load balancer gắn một cookie hoặc dùng hash IP để giữ một người dùng luôn đi vào cùng một máy. Nhanh, nhưng chia tải kém đều hơn và máy đó chết thì phiên vẫn mất.
- Phiên dùng chung: lưu phiên vào Redis hoặc cơ sở dữ liệu, hoặc dùng token tự chứa thông tin như JWT. Máy nào cũng đọc được phiên, mọi máy trở nên thật sự giống hệt nhau. Đây là cách bền vững hơn.
Sticky session che giấu vấn đề chứ không giải quyết nó. Khi cần cập nhật ứng dụng lần lượt từng máy, hay một máy tự động bị thay thế, người dùng gắn với máy đó vẫn mất phiên.
Tầng 4 và tầng 7: chỗ hai khái niệm giao nhau
Load balancer chia làm hai loại theo tầng của mô hình OSI mà nó "nhìn" vào.
Tầng 4 (transport) chỉ nhìn địa chỉ IP và cổng TCP/UDP. Nó không đọc nội dung, chỉ chuyển gói tin tới máy đích, nên cực nhanh và tốn rất ít tài nguyên. Đổi lại, nó không biết yêu cầu là trang chủ hay API, không đọc được cookie.
Tầng 7 (application) đọc được toàn bộ nội dung HTTP: đường dẫn, header, cookie. Vì vậy nó chia được theo đường dẫn, giữ sticky session bằng cookie, viết lại header. Cái giá là phải giải mã HTTPS và phân tích từng request, nên tốn tài nguyên hơn.
Để ý kỹ: một load balancer tầng 7 phải nhận request, giải mã, đọc nội dung, rồi gửi request mới tới máy chủ phía sau. Đó chính xác là định nghĩa của reverse proxy. Nói cách khác, load balancer tầng 7 thực chất là một reverse proxy có thêm khả năng chia tải. Đó là lý do Nginx, HAProxy hay Traefik được gọi bằng cả hai tên.
Reverse proxy trả lời câu hỏi "yêu cầu này xử lý thế nào". Load balancer trả lời câu hỏi "yêu cầu này gửi cho máy nào".
| Tiêu chí | Reverse proxy | Load balancer |
|---|---|---|
| Câu hỏi trả lời | Xử lý yêu cầu thế nào? | Gửi yêu cầu cho máy nào? |
| Số máy chủ phía sau | Một là đủ | Cần từ hai trở lên mới có ý nghĩa |
| Việc chính | TLS, cache, nén, định tuyến, bảo vệ | Phân phối, health check, chịu lỗi |
| Tầng hoạt động | Tầng 7 | Tầng 4 hoặc tầng 7 |
| Có đọc nội dung HTTP | Có | Tầng 7 có, tầng 4 không |
Trong thực tế: hệ thống lớn dùng cả hai
Hai khái niệm không loại trừ nhau mà xếp thành lớp. Một kiến trúc phổ biến:
- Lớp ngoài cùng: load balancer của nhà cung cấp như Cloudflare Load Balancing, AWS Network Load Balancer (tầng 4) hay Application Load Balancer (tầng 7) nhận lưu lượng từ Internet và chia cho nhiều máy.
- Lớp giữa: trên mỗi máy, Nginx đứng làm reverse proxy, giải mã, nén, lưu đệm, giới hạn tốc độ.
- Lớp trong: ứng dụng thật (Node.js, PHP-FPM, Python...) chỉ việc xử lý logic.
Với hệ thống nhỏ, một Nginx duy nhất có thể kiêm cả hai vai. Cấu hình dưới đây vừa chia tải cho ba máy ứng dụng, vừa giải mã HTTPS và định tuyến theo đường dẫn:
upstream app_servers {
least_conn;
server 10.0.0.11:3000 weight=2;
server 10.0.0.12:3000 max_fails=3 fail_timeout=30s;
server 10.0.0.13:3000 max_fails=3 fail_timeout=30s;
}
server {
listen 443 ssl;
server_name example.com;
ssl_certificate /etc/ssl/example.com.crt;
ssl_certificate_key /etc/ssl/example.com.key;
location /api/ {
proxy_pass http://app_servers;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
location /blog/ {
proxy_pass http://10.0.0.20:8080;
}
}
Khối upstream là phần load balancer, còn ssl_certificate và các location là phần reverse proxy. Sau khi sửa, luôn kiểm tra cú pháp trước khi nạp lại:
sudo nginx -t
sudo systemctl reload nginx
Đứng sau reverse proxy, ứng dụng sẽ thấy mọi request đến từ IP của proxy. Header X-Forwarded-For mang IP thật của người dùng vào trong; ứng dụng cần được cấu hình tin header này (chỉ khi request đến từ proxy của bạn) để log và rate limit đúng người.
Chọn nhanh theo nhu cầu:
- [ ]Chỉ có một máy chủ, cần HTTPS, cache, giấu IP: dùng reverse proxy.
- [ ]Có nhiều máy chạy cùng ứng dụng, cần chịu lỗi: thêm load balancer.
- [ ]Cần chia theo đường dẫn hoặc cookie: chọn load balancer tầng 7.
- [ ]Lưu lượng TCP/UDP thuần, cần tốc độ tối đa: chọn load balancer tầng 4.
Tóm tắt nhanh
- Forward proxy giấu người dùng, reverse proxy giấu máy chủ.
- Reverse proxy lo xử lý: giải mã HTTPS, lưu đệm, định tuyến, che chắn; có ích ngay cả khi chỉ có một máy.
- Load balancer lo phân phối: chia yêu cầu cho nhiều máy giống nhau, kiểm tra sức khoẻ, loại máy hỏng; vô nghĩa nếu chỉ có một máy.
- Load balancer tầng 7 chính là reverse proxy có thêm chức năng chia tải; tầng 4 thì chỉ nhìn IP và cổng.
- Hệ thống lớn xếp lớp: load balancer ngoài cùng, reverse proxy ở giữa, ứng dụng bên trong.
Câu hỏi thường gặp
Nginx là reverse proxy hay load balancer?
Cả hai. Nginx là một reverse proxy, và khi bạn khai báo khối upstream với nhiều máy chủ, nó đóng thêm vai load balancer tầng 7. Nó cũng có module stream để chia tải tầng 4 cho TCP/UDP.
Có một VPS thì có cần load balancer không?
Không. Load balancer chỉ có ý nghĩa khi có từ hai máy chủ chạy cùng ứng dụng trở lên. Với một VPS, một reverse proxy như Nginx hoặc Caddy phía trước ứng dụng là đủ.
Cloudflare là reverse proxy hay load balancer?
Khi bật chế độ proxy cho bản ghi DNS, Cloudflare đóng vai reverse proxy: giấu IP máy chủ, giải mã HTTPS, lưu đệm, lọc tấn công. Tính năng Load Balancing là dịch vụ riêng, dùng khi bạn muốn chia tải giữa nhiều máy chủ gốc.
Vì sao thêm load balancer xong người dùng hay bị đăng xuất?
Vì phiên đăng nhập đang lưu trong bộ nhớ từng máy, request sau rơi vào máy khác không có phiên. Cách nhanh là bật sticky session; cách bền vững là lưu phiên vào Redis hoặc dùng token để máy nào cũng đọc được.
