Nginx 反向代理的優缺點#

1. 高效能與高併發處理#

• Nginx 採用非阻塞事件循環（event loop）與 worker-process 架構，善於處理大量短連線與高併發請求，能以較少資源維持高吞吐。

• 對靜態資源、簡單代理請求的效能通常優於同功能的傳統阻塞式伺服器（例如舊版 Apache in prefork）。

2. 負載平衡（多種策略）#

• 支援輪詢（round-robin）、最少連線（least_conn）、IP hash、加權（weight）等策略。

• 可搭配健康檢查（active/passive health checks）或第三方模組實現更精細的健康檢測（注意：部分健康檢查需商業或第三方模組）。

3. 快取（proxy_cache）#

• Nginx 支援 proxy_cache，可在反向代理層快取後端回應以減少後端負載、降低延遲。

• 支援快取過期策略、快取鍵（cache key）自訂、快取控制標頭（Cache-Control、Expires）等。

4. SSL/TLS 終止（SSL termination）#

• 反向代理可在前端終止 TLS，後端伺服器可用內部 HTTP 通信，減少後端負擔並統一證書管理。

• 可配合 OCSP stapling、HTTP/2 與 TLS 參數調校提升安全性與效能。

5. 安全性提升#

• 可用作 Web Application Firewall（WAF）規則前置（例如 ModSecurity + nginx connector），過濾惡意請求、阻擋常見攻擊。

• 隱藏後端 IP 與架構細節，降低直接攻擊後端的風險。

• 支援 rate limiting、connection limiting、限制 request body 大小、限制 header 長度等防護措施。

6. 請求路由與 URL 重寫#

• 可以根據路徑、主機名稱、標頭，或正則式路由到不同後端服務，適合多服務或微服務架構。

• 支援 rewrite、redirect 與 internal location 等機制來調整 URL 與路由邏輯。

7. 動態擴展與灰度部署支援#

• 搭配後端服務的動態註冊（如服務發現）與 Nginx 重載或 API（nginx-plus、有第三方模組）可無痛新增/移除後端進行滾動更新或灰度發布。

• 配合 upstream 的權重可做流量分流，方便 A/B test 或漸進釋出。

8. 支援多種協議與功能（WebSocket、gRPC、HTTP/2）#

• 新版 Nginx 支援 WebSocket proxy、HTTP/2、gRPC 等現代協議（在某些情況需啟用相應模組或編譯選項）。

• 能在反向代理層解決跨域、長連線代理等問題。

9. 配置靈活且生態豐富#

• Nginx 配置語法清晰，社群模組豐富（cache、auth、rewrite、lua 等）。

• 有 Nginx Plus（商業版）提供更多企業級特性，例如動態上游、活躍健康檢查、監控 API 等。

1. 單點故障（Single Point of Failure）#

• 若只有一台 Nginx 作為反向代理，該節點故障則整個服務不可用。必須搭配多個反向代理節點與負載分擔（例如 DNS Round Robin、L4 負載均衡器、Anycast、云供應商的 Load Balancer）或 HA 解決方案（keepalived + VRRP）來避免單點故障。

2. 配置錯誤風險高（安全與邏輯漏洞）#

• Nginx 配置錯誤（例如錯誤的 proxy_set_header、漏掉 proxy_redirect、緩存鍵設定不當）會導致安全風險（洩漏 headers、host header 欺騙）、緩存污染或功能錯誤。複雜路由/快取邏輯會增加維運難度。

3. SSL/TLS 管理負擔#

• 雖然 TLS 終止集中化方便，但證書數量多或需要自動更新（Let’s Encrypt）時，仍需管理 ACME 自動化、Renew failure 的監控。大規模多域名（SNI）情況也需注意性能與記憶體消耗。

4. 動態內容處理不是最佳場所#

• Nginx 本身適合靜態與代理，對複雜動態處理（例如應用層邏輯、長時間運行的同步計算）仍應交給後端應用伺服器。若將過多邏輯塞在 Nginx（使用 Lua、embedded scripts）會增加複雜性與 debug 成本。

5. WebSocket / 長連線限制與調校#

• 雖然支援 WebSocket，但若未正確設定 proxy_buffering、timeout、keepalive 參數，會遭遇延遲、連線中斷或資源耗盡問題。長連線大量存在時，Nginx 要妥善調整 worker_connections、ulimit 等系統參數。

6. 快取一致性與過期控制複雜#

• 代理快取若未正確處理 Cache-Control、Vary、Cookie、副本失效（cache purge）等問題，會導致舊內容被回傳或不當的私人資料被快取。實務上需要設計快取鍵、過期策略與歸檔/失效機制（purge）來避免資料一致性風險。

7. 資源瓶頸（記憶體與 I/O）#

• 在高吞吐且啟用大量緩存/SSL 的環境，Nginx 的記憶體與 I/O 使用會顯著上升。尤其是 proxy buffering 與 SSL session cache，需監控與調校。

8. 監控與可觀測性較原始#

• 開源 Nginx 的監控界面較簡陋（相比 nginx-plus 的 API），需要依靠日誌（access/error）、第三方 exporter（如 nginx-exporter）與外部監控系統（Prometheus/Grafana）來觀察狀況。排查問題時通常需要綜合 log 與 system metrics 分析。

9. 部分進階功能需商業版或第三方模組#

• 像動態 upstream（無需 reload）或高級健康檢查、基於指標的流量控制、API 可視化等功能在 Nginx 開源版有限，需要 Nginx Plus 或第三方模組來補足。

情境 A：靜態站 + 高併發#

• 優點：Nginx 能直接提供靜態檔案、使用 gzip、HTTP/2，大幅降低延遲與後端負載。proxy_cache 可減少動態請求，效能優。

• 缺點：需設計正確的快取策略與 purge 流程。若缺乏 CDN，單機仍可能成為瓶頸。

情境 B：微服務 API Gateway#

• 優點：統一定義路由、認證、速率限制、SSL 終止，方便管理與安全性提升。

• 缺點：API Gateway 會成為關鍵路徑，需要高可用設計與監控，配置錯誤會導致整體系統故障。部分高級流量控制可能需外部系統（如 envoy、kong）來補強。

情境 C：WebSocket 即時應用#

• 優點：Nginx 支援 proxying WebSocket，可以作為入口節點。

• 缺點：需正確設定 proxy_buffering off、proxy_read_timeout 與系統資源，以免大量長連線造成 connection 泄漏或 worker 被阻塞。

1. 最基本的反向代理#

server { listen 80; server_name example.com; location / { proxy_pass http://127.0.0.1:8080; 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_set_header 保留原始 header 資訊給後端。

• proxy_pass 指向後端 HTTP 服務。

2. 加入快取（proxy_cache）#

proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=my_cache:10m max_size=1g inactive=60m use_temp_path=off; server { listen 80; server_name example.com; location /api/ { proxy_pass http://backend_pool; proxy_cache my_cache; proxy_cache_valid 200 302 10m; proxy_cache_valid 404 1m; proxy_cache_key "$scheme$request_method$host$request_uri"; add_header X-Cache-Status $upstream_cache_status; proxy_set_header Host $host; } } 說明：

• proxy_cache_path 定義快取空間與大小。

• proxy_cache_key 自訂快取鍵避免衝突。

• add_header X-Cache-Status 可在回應看到命中情況（HIT/MISS/BYPASS）。

3. SSL 終止與反向代理#

server { listen 80; server_name example.com; return 301 https://$host$request_uri; } server { listen 443 ssl http2; server_name example.com; ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem; ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers HIGH:!aNULL:!MD5; ssl_prefer_server_ciphers on; ssl_session_cache shared:SSL:10m; ssl_session_timeout 10m; location / { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Forwarded-Proto https; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_buffering off; } } 說明：

• TLS 終止在 Nginx；後端以 HTTP 溝通（或用內部 mTLS 若需保護）。

• proxy_buffering off 若處理即時流或 SSE 可能需要關閉。

4. 負載平衡（upstream）#

upstream backend_pool { least_conn; server 10.0.0.11:8080 max_fails=3 fail_timeout=30s; server 10.0.0.12:8080 max_fails=3 fail_timeout=30s; server 10.0.0.13:8080 max_fails=3 fail_timeout=30s; } server { listen 80; server_name api.example.com; location / { proxy_pass http://backend_pool; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } } 說明：

• least_conn 讓連線較少的後端優先分配，適合長連線情況。

5. WebSocket 代理#

server { listen 80; server_name ws.example.com; location /ws/ { proxy_pass http://127.0.0.1:9000; 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_read_timeout 3600s; proxy_send_timeout 3600s; } } 說明：

• 必要的 Upgrade 與 Connection header 用於 WebSocket 握手。

• 延長 timeout 以避免長連線被切斷。

監控指標（建議納入監控系統）#

• Nginx access log metrics：requests per second、4xx/5xx 比例、latency（request time）。

• Worker connections / active connections / accepted / handled。

• upstream 5xx、連線錯誤率。

• proxy_cache hit ratio。

• CPU、memory、network I/O、disk I/O（若使用本地 cache）。

• SSL/TLS 鍵協商失敗率（handshake errors）。

• 系統層級：ulimit（open files）、file descriptors、tcp_tw_reuse、somaxconn。

調校建議#

• worker_processes 設為 auto（或等於 CPU 核心數），worker_connections 設為能支撐的最大連線數。理論最大並發 = worker_processes × worker_connections。

• 調整系統參數 fs.file-max、ulimit -n、net.core.somaxconn、net.ipv4.tcp_tw_reuse 等，以支援大量連線。

• 若使用 proxy_cache，啟用 use_temp_path=off 可以減少 I/O 頻繁操作（但視情況而定）。

• SSL：啟用 HTTP/2、使用 Nagle 相關設置與 TLSv1.3 優先，並合理配置 session cache。

• 在 WebSocket 或長連線場景關閉 proxy_buffering。

適合使用 Nginx 反向代理的場景#

• 需要高效處理大量短連線與靜態資源的系統。

• 需要集中進行 TLS 終止、統一安全策略、速率限制、簡單的負載平衡與快取。

• 希望用較低資源達到高效能（尤其是與 proxy_cache 結合）。

需謹慎評估的點（或考慮替代方案）#

• 若反向代理承擔多項企業級流量控制與動態 upstream 管理，且需無縫動態調整，可能需要 Nginx Plus 或 Envoy、Kong 等更專業方案。

• 長連線或大量 WebSocket 時需特別調校或考慮專門的即時通訊架構（如基於專門的長連線伺服器或使用 L4 負載均衡）。

• 若系統要求極高的可用性，必須設計多個反向代理節點與高可用（VRRP、雲端 LB）層級來避免單點故障。