Reverse Proxy là gì? Hướng dẫn chi tiết từ nguyên lý đến triển khai với Nginx

Chủ đề: Backend · Networking · DevOps · Docker · Homelab
Đối tượng: Người mới tìm hiểu mạng máy tính, lập trình backend và tự triển khai ứng dụng.

1. Giới thiệu#

Khi triển khai website hoặc ứng dụng web, bạn thường phải xử lý nhiều vấn đề: quản lý domain, HTTPS, định tuyến request, bảo mật, ghi log và đôi khi là cân bằng tải. Nếu từng ứng dụng tự đảm nhiệm tất cả, việc vận hành sẽ phức tạp khi hệ thống có thêm dịch vụ.

Reverse Proxy (proxy ngược) là máy chủ trung gian đặt trước một hoặc nhiều backend. Nó tiếp nhận request từ client, chọn dịch vụ đích theo quy tắc cấu hình, chuyển tiếp request và trả response về client. Người dùng thường chỉ cần biết domain công khai, không cần biết địa chỉ và cổng nội bộ của từng ứng dụng.

Bài viết đi từ khái niệm, sơ đồ hoạt động, so sánh các loại proxy đến ví dụ triển khai Nginx bằng Docker Compose.

2. Reverse Proxy là gì?#

Reverse Proxy là điểm tiếp nhận kết nối ở phía server. Khi trình duyệt gửi request đến https://blog.example.com, DNS phân giải domain tới điểm vào của hệ thống. Reverse Proxy nhận kết nối, đọc thông tin request và chuyển tiếp đến backend phù hợp, chẳng hạn dịch vụ Blog đang chạy ở mạng nội bộ.

Ví dụ, một máy chủ có ba ứng dụng:

Ứng dụng	Địa chỉ nội bộ	Domain công khai
Blog	`192.168.1.10:8081`	`blog.example.com`
Dashboard	`192.168.1.10:3000`	`dashboard.example.com`
API	`192.168.1.10:8080`	`api.example.com`

Thay vì yêu cầu người dùng nhớ từng IP và port, có thể cho cả ba ứng dụng đi qua một Reverse Proxy, thường công khai cổng HTTP 80 và HTTPS 443.

2.1. Sơ đồ kiến trúc tổng quan#

flowchart LR
    U["Người dùng / Browser"] -->|"HTTPS :443"| RP["Reverse Proxy<br/>Nginx / Traefik / Caddy"]
    RP -->|"blog.example.com"| BLOG["Blog<br/>:8081"]
    RP -->|"dashboard.example.com"| DASH["Dashboard<br/>:3000"]
    RP -->|"api.example.com"| API["API<br/>:8080"]
    BLOG --> RP
    DASH --> RP
    API --> RP
    RP --> U

    style RP fill:#2563eb,color:#fff,stroke:#1d4ed8
    style BLOG fill:#e0f2fe,color:#0c4a6e,stroke:#0284c7
    style DASH fill:#e0f2fe,color:#0c4a6e,stroke:#0284c7
    style API fill:#e0f2fe,color:#0c4a6e,stroke:#0284c7

2.2. Luồng xử lý request#

Người dùng nhập https://blog.example.com trên trình duyệt.
DNS phân giải domain thành IP của máy chủ hoặc dịch vụ đang nhận lưu lượng.
Trình duyệt thiết lập kết nối TLS/HTTPS đến Reverse Proxy, thường qua cổng 443.
Proxy tiếp nhận request, xử lý TLS nếu được cấu hình làm TLS termination, sau đó kiểm tra domain, path và các quy tắc định tuyến.
Proxy chuyển request tới backend, ví dụ http://blog:8081 trong Docker network.
Backend xử lý request và gửi response về proxy.
Proxy trả response cho trình duyệt qua kết nối HTTPS ban đầu.

sequenceDiagram
    participant B as Browser
    participant D as DNS
    participant P as Reverse Proxy
    participant A as Blog Backend
    B->>D: Tra cứu blog.example.com
    D-->>B: IP của điểm vào
    B->>P: HTTPS GET /
    Note over B,P: TLS handshake và kết nối mã hóa
    P->>P: Đọc Host và áp dụng routing
    P->>A: HTTP GET / (mạng nội bộ)
    A-->>P: HTTP response
    P-->>B: HTTPS response

Quá trình này gần như trong suốt với người dùng. Họ chỉ thấy domain công khai, không cần biết phía sau có bao nhiêu backend.

3. Phân biệt Forward Proxy và Reverse Proxy#

Cả hai đều là máy chủ trung gian, nhưng đứng ở hai phía khác nhau và phục vụ mục đích khác nhau.

flowchart LR
    subgraph F["Forward Proxy"]
      C1["Client A"] --> FP["Forward Proxy"]
      C2["Client B"] --> FP
      FP --> WEB["Internet / Website"]
    end
    subgraph R["Reverse Proxy"]
      USER["Internet / Client"] --> RP["Reverse Proxy"]
      RP --> S1["Backend A"]
      RP --> S2["Backend B"]
    end

Tiêu chí	Forward Proxy	Reverse Proxy
Vị trí	Phía client	Phía server
Đại diện cho	Client	Backend server
Công dụng phổ biến	Kiểm soát truy cập Internet, lọc nội dung, ghi log	Định tuyến, TLS termination, cân bằng tải, kiểm soát điểm vào
Ví dụ	Squid, proxy doanh nghiệp	Nginx, Caddy, Traefik, HAProxy

Forward Proxy thường được tổ chức để nhiều client đi qua trước khi truy cập website. Reverse Proxy nhận request từ client rồi chuyển tiếp vào hạ tầng backend.

4. Những chức năng chính của Reverse Proxy#

4.1. Định tuyến theo domain hoặc path#

Một proxy HTTP có thể dùng Host hoặc URL path để quyết định backend đích. Ví dụ:

blog.example.com → Blog service.
api.example.com → API service.
example.com/admin → Dashboard hoặc dịch vụ quản trị.

Điều này giúp nhiều ứng dụng dùng chung một địa chỉ IP công khai mà vẫn có endpoint rõ ràng.

4.2. TLS termination và HTTPS tập trung#

Reverse Proxy có thể nhận kết nối HTTPS, giải mã TLS tại proxy rồi chuyển request đến backend. Khi đó, backend trong mạng riêng có thể dùng HTTP nếu mô hình đe dọa và chính sách bảo mật cho phép.

Browser -- HTTPS :443 --> Nginx -- HTTP :8081 --> Blog

TLS termination giúp tập trung cấu hình chứng chỉ và giảm việc lặp lại cấu hình TLS ở từng ứng dụng. Tuy nhiên, nếu mạng nội bộ không hoàn toàn đáng tin cậy hoặc yêu cầu tuân thủ cần mã hóa đầu cuối, nên dùng HTTPS/mTLS hoặc cơ chế bảo vệ thích hợp giữa proxy và backend.

4.3. Cân bằng tải (Load Balancing)#

Khi một ứng dụng có nhiều instance, proxy có thể phân phối request giữa chúng.

flowchart TD
    C["Clients"] --> LB["Reverse Proxy / Load Balancer"]
    LB --> A["Backend 1"]
    LB --> B["Backend 2"]
    LB --> D["Backend 3"]
    A --> DB["Database / Shared Storage"]
    B --> DB
    D --> DB

Một số thuật toán thường gặp:

Round Robin: luân phiên phân phối request qua các backend.
Least Connections: ưu tiên backend có ít kết nối đang hoạt động hơn.
IP Hash: dùng địa chỉ IP client để chọn backend, có thể giúp định tuyến nhất quán trong một số trường hợp.

Cân bằng tải có thể tăng khả năng xử lý đồng thời và hỗ trợ tính sẵn sàng, nhưng hiệu quả còn phụ thuộc vào trạng thái session, dữ liệu dùng chung, health check và năng lực của các thành phần khác.

4.4. Logging và monitoring#

Vì là điểm tập trung của lưu lượng vào, Reverse Proxy có thể ghi access log và error log, hỗ trợ xác định thời điểm request, endpoint, mã trạng thái và lỗi kết nối backend. Cần tránh ghi token, mật khẩu, cookie nhạy cảm hoặc dữ liệu cá nhân không cần thiết.

4.5. Kiểm soát lưu lượng và bảo vệ điểm vào#

Tùy sản phẩm và cấu hình, proxy có thể hỗ trợ giới hạn kích thước request, timeout, allowlist IP hoặc rate limiting. Đây là các lớp bảo vệ bổ sung, không thay thế firewall, xác thực, phân quyền, kiểm tra đầu vào hay bảo mật ở tầng ứng dụng.

5. Reverse Proxy hoạt động ở tầng nào?#

Nginx, Caddy và Traefik thường được dùng như HTTP reverse proxy ở Layer 7 (Application). Chúng có thể đọc thông tin HTTP như:

Host: domain được yêu cầu.
Path: đường dẫn, ví dụ /api/users.
Method: GET, POST, PUT, DELETE.
Headers và một số thuộc tính của request.

Các proxy hoặc load balancer ở Layer 4 (Transport) thường định tuyến dựa trên IP, port và giao thức TCP/UDP mà không cần phân tích nội dung HTTP. Chọn Layer 4 hay Layer 7 tùy yêu cầu giao thức, khả năng định tuyến và đặc tính triển khai.

6. Triển khai Nginx Reverse Proxy bằng Docker Compose#

6.1. Kiến trúc ví dụ#

Giả sử máy chủ Linux chạy Docker và có hai ứng dụng:

Blog backend lắng nghe cổng 8081.
Dashboard Next.js lắng nghe cổng 3000.

Ta muốn công khai:

blog.example.com       -> blog:8081
dashboard.example.com  -> dashboard:3000

Nginx sẽ là dịch vụ duy nhất publish cổng 80 và 443 ra host. Các backend chỉ giao tiếp trong Docker network.

6.2. Cấu trúc thư mục#

reverse-proxy/
├── docker-compose.yml
├── nginx/
│   └── conf.d/
│       └── default.conf
└── certs/
    ├── fullchain.pem
    └── privkey.pem

Thư mục certs chứa chứng chỉ TLS và private key tương ứng. Không commit private key vào Git. Ví dụ này giả định đã có chứng chỉ hợp lệ cho các domain; phần cấp phát và gia hạn tự động cần được cấu hình riêng.

6.3. Docker Compose#

Tạo docker-compose.yml:

services:
  nginx:
    image: nginx:alpine
    container_name: reverse-proxy
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./nginx/conf.d:/etc/nginx/conf.d:ro
      - ./certs:/etc/nginx/certs:ro
    depends_on:
      - blog
      - dashboard
    networks:
      - proxy

  blog:
    image: your-blog-image:latest
    container_name: blog
    restart: unless-stopped
    expose:
      - "8081"
    networks:
      - proxy

  dashboard:
    image: your-dashboard-image:latest
    container_name: dashboard
    restart: unless-stopped
    expose:
      - "3000"
    networks:
      - proxy

networks:
  proxy:
    driver: bridge

Giải thích:

ports publish cổng Nginx ra máy chủ.
expose khai báo cổng nội bộ của backend trong Docker; nó không publish cổng đó ra host như ports.
Các service cùng proxy network có thể truy cập nhau bằng tên service, ví dụ http://blog:8081.
depends_on điều khiển thứ tự khởi chạy cơ bản, nhưng không đảm bảo ứng dụng đã sẵn sàng nhận request. Nên bổ sung healthcheck/retry khi cần.

Thay your-blog-image:latest và your-dashboard-image:latest bằng image thật, đồng thời đảm bảo ứng dụng bind vào 0.0.0.0 bên trong container, không chỉ 127.0.0.1.

6.4. Cấu hình Nginx#

Tạo nginx/conf.d/default.conf:

# HTTP: chuyển hướng sang HTTPS
server {
    listen 80;
    server_name blog.example.com dashboard.example.com;

    location / {
        return 301 https://$host$request_uri;
    }
}

# Reverse Proxy cho Blog
server {
    listen 443 ssl;
    server_name blog.example.com;

    ssl_certificate     /etc/nginx/certs/fullchain.pem;
    ssl_certificate_key /etc/nginx/certs/privkey.pem;
    ssl_protocols TLSv1.2 TLSv1.3;

    location / {
        proxy_pass http://blog:8081;

        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;

        proxy_connect_timeout 5s;
        proxy_read_timeout 60s;
    }
}

# Reverse Proxy cho Dashboard
server {
    listen 443 ssl;
    server_name dashboard.example.com;

    ssl_certificate     /etc/nginx/certs/fullchain.pem;
    ssl_certificate_key /etc/nginx/certs/privkey.pem;
    ssl_protocols TLSv1.2 TLSv1.3;

    location / {
        proxy_pass http://dashboard: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;

        proxy_connect_timeout 5s;
        proxy_read_timeout 60s;
    }
}

Các directive đáng chú ý:

Directive	Tác dụng
`listen 80`	Nhận kết nối HTTP
`listen 443 ssl`	Nhận kết nối HTTPS với TLS
`server_name`	Chọn server block theo domain
`ssl_certificate`	Đường dẫn tới chứng chỉ
`ssl_certificate_key`	Đường dẫn tới private key
`location`	Quy tắc xử lý theo đường dẫn
`proxy_pass`	Chuyển tiếp request đến backend
`proxy_set_header`	Thiết lập HTTP headers gửi tới backend
`proxy_connect_timeout`	Giới hạn thời gian thiết lập kết nối backend
`proxy_read_timeout`	Giới hạn khoảng chờ giữa các lần đọc dữ liệu từ backend

Các header X-Real-IP, X-Forwarded-For và X-Forwarded-Proto giúp backend biết IP client gốc và giao thức bên ngoài. Ứng dụng chỉ nên tin cậy các proxy đã xác định; không nên tin mọi giá trị forwarded header do client gửi.

Về TLS: cấu hình trên giả định chứng chỉ có sẵn cho cả hai domain. Muốn dùng Let’s Encrypt, cần tích hợp Certbot hoặc một cơ chế ACME phù hợp, mount đúng thư mục challenge/chứng chỉ và thiết lập gia hạn tự động. Đoạn cấu hình này chưa tự cấp phát chứng chỉ.

6.5. Khởi chạy và kiểm tra#

# Khởi động dịch vụ

docker compose up -d

# Xem trạng thái container
docker compose ps

# Kiểm tra cú pháp Nginx
docker compose exec nginx nginx -t

# Theo dõi log Nginx
docker compose logs -f nginx

# Thử kết nối backend từ container Nginx
docker compose exec nginx wget -qO- http://blog:8081

Nếu Nginx chạy nhưng không gọi được backend, hãy kiểm tra service name, port thật của ứng dụng, Docker network và địa chỉ bind của ứng dụng. depends_on không thay thế health check.

7. DNS và truy cập từ Internet#

Để domain trỏ tới hệ thống, DNS cần phân giải tên miền về địa chỉ điểm vào công khai. Ví dụ minh họa:

Loại	Tên	Giá trị
A	`blog.example.com`	`203.0.113.10`
A	`dashboard.example.com`	`203.0.113.10`

203.0.113.10 thuộc dải IP dành cho tài liệu minh họa, không phải địa chỉ sử dụng thật. Khi triển khai, thay bằng IP công khai thực tế hoặc cấu hình DNS theo nhà cung cấp tunnel/CDN.

Nếu máy chủ nằm sau router NAT tại nhà, thường cần port forwarding 80 và 443 về máy chạy Nginx, đồng thời cho phép các cổng này qua firewall. Nếu dùng Cloudflare Tunnel hoặc giải pháp tunnel khác, luồng truy cập sẽ khác và có thể không cần mở cổng inbound trên router.

8. Các cấu hình nâng cao thường gặp#

8.1. WebSocket#

Ứng dụng chat, dashboard realtime hoặc một số API có thể sử dụng WebSocket. Nginx cần chuyển tiếp các header nâng cấp kết nối:

location /ws/ {
    proxy_pass http://dashboard:3000;

    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";

    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;

    proxy_read_timeout 3600s;
}

Thời gian timeout cần phù hợp với ứng dụng và chính sách vận hành. Với môi trường production, nên kiểm thử cả trường hợp client mất mạng, backend restart và kết nối lâu không có dữ liệu.

8.2. Rate limiting#

Có thể giới hạn tần suất request theo IP bằng limit_req. Ví dụ sau đặt trong phạm vi cấu hình http của Nginx:

limit_req_zone $binary_remote_addr zone=api_limit:10m rate=10r/s;

Áp dụng trong server/location:

location / {
    limit_req zone=api_limit burst=20 nodelay;
    proxy_pass http://api:8080;
}

Đây chỉ là ví dụ minh họa. Ngưỡng cần căn cứ vào tải thực tế; người dùng cùng đi qua một NAT có thể dùng chung IP nguồn và vô tình bị giới hạn cùng nhau.

8.3. Hạn chế truy cập dashboard#

Với trang quản trị, có thể giới hạn bằng VPN, xác thực bổ sung hoặc allowlist IP. Không nên dựa vào việc “ẩn domain” như một biện pháp bảo mật. Cần giữ xác thực và phân quyền ở tầng ứng dụng.

9. Những lỗi thường gặp#

Lỗi	Nguyên nhân có thể	Hướng kiểm tra
`502 Bad Gateway`	Proxy không kết nối được backend, sai hostname/port hoặc backend chưa sẵn sàng	Kiểm tra `docker compose ps`, log backend, network và `proxy_pass`
`504 Gateway Timeout`	Backend xử lý lâu hoặc kết nối bị treo	Kiểm tra thời gian xử lý, log và timeout; không chỉ tăng timeout một cách máy móc
Domain không truy cập được	DNS sai, NAT/firewall chưa mở, IP thay đổi	Kiểm tra DNS, port forwarding và firewall
HTTPS báo lỗi chứng chỉ	Chứng chỉ sai domain, hết hạn hoặc chain không đầy đủ	Kiểm tra SAN, hạn chứng chỉ và chuỗi chứng chỉ
Backend tạo URL `http://` khi người dùng vào HTTPS	Backend không nhận/không tin cậy forwarded headers	Cấu hình framework nhận proxy headers từ proxy tin cậy
WebSocket bị ngắt	Thiếu upgrade headers hoặc timeout không phù hợp	Kiểm tra cấu hình WebSocket và log kết nối

10. Một số Reverse Proxy phổ biến#

Giải pháp	Đặc điểm	Thường phù hợp với
Nginx	Phổ biến, linh hoạt, cấu hình chi tiết	Website, API, hệ thống cần tùy chỉnh
Caddy	Cấu hình gọn, tự động hóa HTTPS thuận tiện	Homelab, website nhỏ, triển khai nhanh
Traefik	Tích hợp tốt với Docker/Kubernetes, tự khám phá dịch vụ	Nhiều container, microservices
HAProxy	Tập trung vào proxy và cân bằng tải	Hệ thống cần điều khiển lưu lượng chuyên sâu
Envoy	Hướng cloud-native, hỗ trợ observability và service mesh	Hạ tầng microservices/phân tán

Không có lựa chọn phù hợp cho mọi hệ thống. Hãy dựa vào độ phức tạp, cách triển khai, kỹ năng vận hành và yêu cầu về TLS, định tuyến, cân bằng tải cũng như quan sát hệ thống.

11. Reverse Proxy có giống API Gateway không?#

Hai khái niệm có phần giao nhau nhưng trọng tâm khác nhau:

Reverse Proxy chủ yếu tiếp nhận và chuyển tiếp request, định tuyến, TLS termination và có thể cân bằng tải.
API Gateway thường bổ sung các chính sách quản trị API như xác thực, phân quyền, API key, quota, rate limit theo người dùng/ứng dụng, biến đổi request/response và quản lý phiên bản API.

Một Reverse Proxy có thể đảm nhận một số chức năng Gateway thông qua module hoặc cấu hình bổ sung. Với hệ thống API lớn, nhiều nhóm client và chính sách phức tạp, một API Gateway chuyên dụng có thể phù hợp hơn.

12. Khi nào nên dùng Reverse Proxy?#

Reverse Proxy thường hữu ích khi:

Có nhiều ứng dụng trên cùng máy chủ nhưng muốn dùng domain riêng.
Muốn tập trung HTTPS và quản lý chứng chỉ.
Muốn giảm số cổng backend phải công khai.
Cần định tuyến theo domain hoặc path.
Triển khai Docker, homelab, microservices hoặc nhiều ứng dụng nội bộ.
Cần một điểm tập trung để ghi log, điều tiết lưu lượng và quan sát request.

Một ứng dụng nhỏ không bắt buộc phải có Reverse Proxy. Thêm proxy cũng có nghĩa là thêm một thành phần cần cấu hình, cập nhật, giám sát và khắc phục sự cố. Hãy cân nhắc lợi ích so với độ phức tạp vận hành.

13. Kết luận#

Reverse Proxy là thành phần hữu ích trong kiến trúc triển khai ứng dụng web. Nó tạo điểm truy cập thống nhất giữa client và backend, hỗ trợ định tuyến, TLS termination, logging, kiểm soát lưu lượng và cân bằng tải.

Với homelab hoặc hệ thống nhỏ, Nginx, Caddy hay Traefik có thể giúp quản lý nhiều ứng dụng trên cùng máy chủ mà không cần công khai từng cổng backend. Khi hệ thống lớn hơn, Reverse Proxy có thể kết hợp với load balancer, API Gateway, firewall và hệ thống monitoring.

Điểm cần nhớ: Reverse Proxy không tự động làm hệ thống an toàn tuyệt đối hoặc nhanh hơn trong mọi trường hợp. Hiệu quả phụ thuộc vào cấu hình, kiến trúc mạng, backend và quy trình vận hành.

Tóm tắt nhanh#

Reverse Proxy đứng phía server và đại diện cho các backend.
HTTP Reverse Proxy thường định tuyến theo domain, path và HTTP headers.
TLS termination cho phép tập trung xử lý HTTPS tại proxy.
Docker network giúp proxy gọi backend bằng service name mà không cần publish mọi cổng ra host.
Proxy có thể hỗ trợ cân bằng tải, logging và giới hạn lưu lượng.
Firewall, xác thực, phân quyền và bảo vệ ứng dụng vẫn cần được triển khai riêng.