反向代理是所有外部流量進來的第一道門。TLS 掛在這裡、路由分在這裡、限流做在這裡。如果你沒有這層，每個服務各自為政，安全標頭有的加有的不加，限流每個人實作不同——那不叫微服務，叫微混亂。
先講結論
反向代理不是「裝一個 Nginx」這麼簡單。它是你的入口治理中樞：TLS 終止、L7 路由、安全標頭、限流、觀測——全部在這一層統一處理。後端服務只需要專注商業邏輯。
反向代理 vs 正向代理：搞清楚方向
正向代理替「使用者」去存取外部（想像公司的上網代理）。反向代理替「服務」接收外部請求。方向相反，角色完全不同。
你家裡的服務只要對外提供 API，就需要反向代理。不是選項，是必需品。
TLS 終止：憑證集中管，服務輕鬆跑
TLS termination 的意思是：加密連線在反向代理層就解開，後端服務拿到的是明文 HTTP。
這樣做的好處很明顯——憑證只需要在一個地方管理，不用每個服務各自搞一份 cert。壞處是內部流量走明文，如果你的內網不可信（例如零信任架構），就需要 mTLS。
但說真的，大部分團隊的威脅模型還沒到需要 mTLS 的程度。先把 TLS termination 做好，比什麼都沒有強一百倍。
最小可用的 Nginx 設定
server {
listen 443 ssl http2;
server_name api.example.com;
ssl_certificate /etc/ssl/certs/fullchain.pem;
ssl_certificate_key /etc/ssl/private/privkey.pem;
# 安全標頭：統一在入口加，後端不用管
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
add_header X-Content-Type-Options nosniff always;
location / {
proxy_pass http://api_upstream;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $remote_addr;
proxy_set_header X-Forwarded-Proto $scheme;
}
}
upstream api_upstream {
server 10.0.16.10:8080;
server 10.0.16.11:8080;
}注意 X-Forwarded-For 和 X-Forwarded-Proto——少了這兩個 header，後端不知道 client 的真實 IP，也不知道原始請求是 HTTP 還是 HTTPS。很多「重導向迴圈」的 bug 都是因為沒傳 X-Forwarded-Proto。
限流：入口是最好的位置
限流放在每個服務裡？那你有 10 個服務就要設定 10 次，而且標準不一致。放在反向代理層，一次搞定。
常見策略：IP rate limit（防爬蟲）、Token rate limit（防濫用）、Burst + Sustained（允許短期突發但長期限制）。
憑證不是設定完就不管了
Let’s Encrypt 的免費憑證 90 天就過期。你以為 certbot auto-renew 很穩？我遇過 crontab 權限問題導致續期失敗，整個站直接掛掉的。
必做三件事：自動續期、監控到期時間（至少 14 天前告警）、續期後能自動 reload。然後祈禱 Let’s Encrypt 不要改 API。
遷移：入口是高風險區
換反向代理不是改個設定檔重啟就好。建議流程：
- 新入口先起來，用測試流量驗證
- 灰度導流 5% → 20% → 50%
- 全程盯著延遲和錯誤率
- 切完保留舊入口至少一週
我看過有人直接把 DNS 指向新的反向代理，然後 TLS cipher 不相容，老客戶端全部 handshake 失敗。那天晚上很精彩。
反向代理就像門衛。你可以不設門衛，但你會發現每個房間都需要自己鎖門、自己查證件、自己趕人——最後沒有一個做得好。