Proxy Network — Mạng Proxy toàn tập Phần 10

Kiểm chứng — chạy thật, đừng suy đoán

-w với %{time_appconnect} là công cụ chẩn đoán tốt nhất trong danh sách này.

Nó tách một con số "chậm" mơ hồ thành bốn giai đoạn cụ thể. DNS chậm, bắt tay TCP chậm, bắt tay TLS chậm và upstream chậm là bốn sự cố khác nhau, cần bốn cách sửa khác nhau — nhưng trên dashboard chúng trông y hệt nhau.

15.3 Thực hành 30 phút

Mục tiêu: dựng nginx trước cmd/api, rồi tự tay chứng minh ba điều — client IP đúng, XFF giả bị chặn, upstream chậm trả 504. Toàn bộ chạy trên Docker, không đụng vào máy thật.

Bước 1 — endpoint để quan sát (5 phút)

Thêm hai route tạm vào router chi của cmd/api. Chúng chỉ tồn tại trong bài thực hành này — xoá đi khi xong.

// GET /whoami trả về đúng những gì tầng dưới NHÌN THẤY, không suy diễn.
// Đây là công cụ chẩn đoán quan trọng nhất khi có proxy ở giữa.
r.Get("/whoami", func(w http.ResponseWriter, req *http.Request) {
	out := map[string]any{
		"remote_addr": req.RemoteAddr,
		// Values chứ không phải Get: client gửi được NHIỀU dòng XFF.
		"x_forwarded_for":   req.Header.Values("X-Forwarded-For"),
		"x_forwarded_proto": req.Header.Get("X-Forwarded-Proto"),
		"host":              req.Host,
	}
	w.Header().Set("Content-Type", "application/json")
	_ = json.NewEncoder(w).Encode(out)
})

// GET /slow cố tình chậm hơn proxy_read_timeout để ép ra 504.
r.Get("/slow", func(w http.ResponseWriter, req *http.Request) {
	select {
	case <-time.After(10 * time.Second):
		_, _ = w.Write([]byte("xong\n"))
	case <-req.Context().Done():
		// nginx đã bỏ đi. Ghi lại để về sau phân biệt được
		// "upstream chậm" với "upstream lỗi" khi đọc log.
		slog.Warn("client huỷ request", "path", req.URL.Path)
	}
})

Bước 2 — cấu hình nginx (10 phút)

deployments/proxy-lab/nginx.conf:

worker_processes 1;
events { worker_connections 1024; }

http {
    # ut = thời gian upstream xử lý, rt = thời gian tổng tính cả client.
    # Chênh lệch giữa hai con số này là phần mạng phía client — tách được
    # ra thì mới trả lời được câu "chậm ở đâu".
    log_format edge '$remote_addr -> $upstream_addr '
                    'status=$status ut=$upstream_response_time rt=$request_time '
                    'rid=$request_id';
    access_log /dev/stdout edge;

    upstream api {
        server api:8000;
        keepalive 32;          # giữ sẵn connection, tránh bắt tay TCP mỗi request
    }

    server {
        listen 8080 default_server;
        server_name _;

        location / {
            proxy_pass http://api;

            # Hai dòng này đi CÙNG NHAU với keepalive ở khối trên.
            # Thiếu proxy_http_version 1.1 thì nginx nói HTTP/1.0 với upstream
            # và toàn bộ khai báo keepalive trở thành vô nghĩa.
            proxy_http_version 1.1;
            proxy_set_header Connection "";

            proxy_set_header Host              $host;
            # $remote_addr chứ KHÔNG phải $proxy_add_x_forwarded_for:
            # đây là hop ngoài cùng, mọi giá trị client gửi lên đều phải bỏ.
            proxy_set_header X-Forwarded-For   $remote_addr;
            proxy_set_header X-Forwarded-Proto $scheme;
            proxy_set_header X-Request-Id      $request_id;

            proxy_connect_timeout 2s;
            proxy_send_timeout    5s;
            proxy_read_timeout    3s;   # cố tình ngắn để bước 5 quan sát được

            proxy_next_upstream error timeout;   # KHÔNG thêm non_idempotent
        }
    }
}

deployments/proxy-lab/compose.yml:

name: proxy-lab
services:
  api:
    build:
      context: ../..
      dockerfile: deployments/proxy-lab/Dockerfile
    expose: ["8000"]          # expose, KHÔNG ports — chỉ nginx vào được

  edge:
    image: nginx:1.27-alpine
    depends_on: [api]
    ports: ["8080:8080"]
    volumes:
      - ./nginx.conf:/etc/nginx/nginx.conf:ro

Vì sao expose chứ không phải ports cho api?

ports mở cổng ra máy host, và lúc đó ứng dụng có hai đường vào: qua nginx và trực tiếp. Mọi thứ bạn cấu hình ở nginx — allowlist Host, rate limit, xoá header nội bộ — đều bị đường thứ hai đi vòng qua. Đây chính là bẫy số 12 ở dạng thu nhỏ, và trên production nó lộ ra dưới dạng "sao có traffic không xuất hiện trong log của LB".

Khởi động:

docker compose -f deployments/proxy-lab/compose.yml up -d --build

Bước 3 — xác nhận client IP đúng (5 phút)

curl -s http://localhost:8080/whoami

Kết quả trên một môi trường Docker mặc định:

{
  "host": "localhost",
  "remote_addr": "172.20.0.3:59836",
  "x_forwarded_for": ["172.20.0.1"],
  "x_forwarded_proto": "http"
}

Hai chi tiết cần đọc kỹ:

• remote_addr là container nginx (172.20.0.3), không phải bạn. Đây là bằng chứng cụ thể cho việc r.RemoteAddr vô dụng khi có proxy ở giữa.
• x_forwarded_for là 172.20.0.1 — gateway của bridge network, tức máy host. Đó mới là "client".

Địa chỉ cụ thể sẽ khác trên máy bạn vì Docker cấp subnet khác nhau; thứ cần khớp là quan hệ giữa hai giá trị, không phải con số.

Bước 4 — xác nhận giả mạo XFF bị chặn (5 phút)

curl -s -H "X-Forwarded-For: 1.2.3.4" http://localhost:8080/whoami

x_forwarded_for vẫn phải là ["172.20.0.1"]. Giá trị 1.2.3.4 biến mất hoàn toàn — đúng như thiết kế.

Giờ đổi một dòng trong nginx.conf để tận mắt thấy phía sai:

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

docker compose -f deployments/proxy-lab/compose.yml restart edge

curl -s -H "X-Forwarded-For: 1.2.3.4" http://localhost:8080/whoami
# {"x_forwarded_for":["1.2.3.4, 172.20.0.1"], ...}

Giá trị giả nằm ở vị trí đầu tiên. Mọi đoạn code lấy strings.Split(xff, ",")[0] — và có rất nhiều thư viện làm đúng như vậy — sẽ tin 1.2.3.4. Đổi lại dòng cũ trước khi sang bước tiếp theo.

Bước 5 — xác nhận 504 khi upstream chậm (5 phút)

curl -s -o /dev/null -w "http=%{http_code} time=%{time_total}\n" http://localhost:8080/slow
# http=504 time=3.016747

proxy_read_timeout 3s cắt request ở giây thứ 3, dù handler cần 10 giây. Log của nginx nói rõ nguyên nhân:

[error] upstream timed out (110: Connection timed out) while reading response header
        from upstream, client: 172.20.0.1, request: "GET /slow HTTP/1.1"
172.20.0.1 -> 172.20.0.2:8000 status=504 ut=3.003 rt=3.003 rid=1f0b0f7c5f5f4a2e9a6a3d4b8c1e7f02

Ba điều rút ra:

1. 504 là kết luận của proxy, không phải của ứng dụng. Ứng dụng không hề trả 504 — nó vẫn đang chạy bình thường. Đi tìm "chỗ nào trả 504" trong code Go là đi tìm thứ không tồn tại.
2. ut=3.003 trùng khít proxy_read_timeout. Khi upstream_response_time bám sát một giá trị tròn trịa nào đó, thủ phạm gần như luôn là timeout chứ không phải upstream.
3. Handler nhận được r.Context().Done() và ghi log huỷ. Không xử lý tín hiệu này thì công vẫn tiếp tục tiêu tài nguyên cho một response không ai còn chờ — và dưới tải cao, đó là cách một sự cố nhỏ biến thành sập dây chuyền.

Dọn dẹp:

docker compose -f deployments/proxy-lab/compose.yml down -v

15.4 Phụ lục A — Thuật ngữ Anh–Việt

15.5 Phụ lục B — RFC và spec liên quan

15.6 Phụ lục C — Công cụ

15.7 Phụ lục D — Đọc thêm

Chỉ những nguồn chính chủ. Với tài liệu sống, hãy đọc bản trên trang gốc thay vì bài blog chép lại — directive và giá trị mặc định thay đổi theo phiên bản.

Một thói quen đáng hình thành

Mỗi khi định viết một directive vào file cấu hình production, mở trang tài liệu của chính directive đó và đọc dòng "Default". Phần lớn sự cố proxy không đến từ thứ bạn cấu hình sai, mà từ thứ bạn không cấu hình và mặc định lại không phải cái bạn tưởng — bẫy số 2 và số 10 ở §15.1 đều thuộc dạng đó.