問題背景

Nginx 反向代理多台後端應用伺服器時，預設輪詢調度導致同一用戶請求分散到不同後端，造成 Session 不一致（登入失效、購物車丟失等）。

方案對比總覽

方案	原理	優點	缺點	適用場景
應用層共享	Session 存 Redis/Memcached/DB	高可用、跨機房、無單點	延遲較高、架構複雜	嚴格一致性要求、請求量中等
Cookie 改造	將 Session ID 存 Client Cookie	無伺服器狀態、擴展性最強	安全風險、大小限制、改造成本高	新系統設計、無狀態微服務
ip_hash	客戶端 IP 雜湊固定後端	配置簡單、無額外元件	IP 不均勻、NAT/代理失效、後端掛掉 Session 丟失	簡單集群、無前置代理
upstream_hash	自定義鍵（Header/Cookie/IP）雜湊	靈活支援 X-Forwarded-For、Cookie、JSESSIONID	需編譯第三方模組、後端異常仍丟失 Session	有前置代理、需 Cookie 親和性

方案一：ip_hash（內建、最簡單）

upstream backend {
    server 127.0.0.1:8001;
    server 127.0.0.1:8002;
    ip_hash;
}

限制條件（必讀）

1. Nginx 必須是最前端進入點（否則拿到的是上游代理 IP）
2. 後端不能再有其他負載均衡層，否則親和性斷裂
3. 大量用戶共用出口 IP（企業 NAT、CDN）會導致極度不均勻
4. 後端節點下線，該 IP 群組 Session 全部失效

方案二：upstream_hash 模組（靈活、解決前置代理問題）

需編譯第三方模組 ngx_http_upstream_consistent_hash 或 nginx-upstream-hash。

基於 X-Forwarded-For（前置 Squid/代理場景）

upstream backend {
    server 127.0.0.1:8001;
    server 127.0.0.1:8002;
    hash $http_x_forwarded_for consistent;
}

基於 Cookie（如 JSESSIONID、PHPSESSID）

upstream backend {
    server 127.0.0.1:8001;
    server 127.0.0.1:8002;
    hash $cookie_JSESSIONID consistent;
}

關鍵參數 consistent： 使用一致性雜湊演算法，節點增減時僅影響極少數鍵的映射，大幅減少 Session 遷移。

方案三：應用層 Session 共享（根治、生產首選）

PHP 範例（Redis）

; php.ini 或 php-fpm pool 配置
session.save_handler = redis
session.save_path = "tcp://127.0.0.1:6379?auth=password&database=0"
; 或多節點
session.save_path = "tcp://redis1:6379?weight=1, tcp://redis2:6379?weight=1"

Java Spring Boot 範例

# application.yml
spring:
  session:
    store-type: redis
  redis:
    host: localhost
    port: 6379

依賴 spring-session-data-redis，自動將 Session 同步至 Redis。

Python Django 範例

# settings.py
SESSION_ENGINE = "django.contrib.sessions.backends.cache"
SESSION_CACHE_ALIAS = "default"
CACHES = {
    "default": {
        "BACKEND": "django_redis.cache.RedisCache",
        "LOCATION": "redis://127.0.0.1:6379/1",
    }
}

方案四：Sticky Session + 健康檢查折中方案

若暫時無法改造應用層，可結合：

• Nginx upstream 設定 health_check 快速踢除故障節點
• 應用層啟用 Session 複寫（如 Tomcat DeltaManager、PHP session.save_handler=memcached）
• 前端 CDN/SSL 卸載層透傳 X-Forwarded-For 供 upstream_hash 使用

選型決策樹

1. 能改應用程式碼？→ 是 → 上 Redis/Memcached 共享 Session（最穩健）
2. 不能改代碼，且無前置代理？→ ip_hash（最省事）
3. 不能改代碼，有前置代理？→ upstream_hash + $http_x_forwarded_for
4. 需支援 Session 不丟失且後端可擴縮容？→ 一致性雜湊 + 應用層共享雙重保障

Session 共享無銀彈，根據業務容忍度、架構複雜度與團隊能力選擇最合適的組合策略。