背景：

• 需求1——審計日志需要真實IP：
  安全審計要求記錄訪問服務的最終用戶或設備的真實來源IP地址。這對于追蹤惡意活動、排查問題、滿足合規性要求至關重要。

• 需求2——風控需要真正IP：
  一些活動、風險管理都是需要對客戶的真實IP進行篩選甄別。

解決方案1——HTTP頭記錄

為了實現上述目標，有一些現成的解決辦法，比如在HTTP協議中加入一些參數，這些參數可以記錄IP信息，比如：
X-Forwarded-For標頭，記錄相關源地址信息,
X-Original-To標頭，用來攜帶目的地址的信息。

缺點：

1. 不安全，容易被篡改；

   • 頭部可被篡改：如果請求在到達可信代理前經過不可信節點，攻擊者可偽造請求頭X-Forwarded-For: 1.1.1.1；

2. 遇到代理服務器，相關標頭信息容易被篡改、覆蓋。

   • 代理鏈中若有一個設備未正確傳遞該頭部，信息即丟失；

     # Nginx代理強制覆蓋XFF (安全配置)
     proxy_set_header X-Forwarded-For $remote_addr;  # 覆蓋而非追加
     

為什么后臺Server無法拿到Client真實IP？
以企業WEB服務拓撲圖來分析：

1. 代理行為導致, 如果代理服務器使用覆蓋模式（如Nginx），則后臺服務器就無法獲取到Client的真實IP。

2. 代理/負載均衡的普遍性： 現代Web架構中，客戶端（瀏覽器/App）通常不直接連接最終的應用服務器（如Tomcat, Nginx, Apache）。中間會經過反向代理/負載均衡器 (如Nginx, HAProxy, F5)： 負責SSL終止、負載分發、安全防護等。

   • Web應用防火墻 (WAF)： 提供額外的安全防護層；

   • CDN節點： 緩存內容，加速訪問；

   • SSL/TLS終止： HTTPS的核心是端到端加密。為了檢查內容（如WAF掃描攻擊）、進行負載均衡或優化性能，SSL/TLS解密通常在代理/負載均衡器/WAF/CDN處終止。代理服務器建立與客戶端的加密連接，然后建立一個（通常是未加密的或新加密的）連接到后端應用服務器。

結果： 當請求到達最終的應用服務器時，服務器看到的網絡連接來源IP地址是最后一個代理設備（如Nginx, F5, WAF）的IP地址，而不是原始客戶端的真實IP地址。

其它知識：
篡改XFF不會影響實際的網絡傳輸，網絡傳輸由路由提供服務，路由決策僅依賴網絡層（IP頭），XFF作為應用層數據，對TCP/IP協議棧透明。

解決方案2——proxy protocol協議

Proxy Protocol的出現解決了上述代理丟失IP問題，它允許代理服務器在轉發連接之前，將原始客戶端連接的相關信息封裝在特殊的協議頭部中傳遞給目標服務器。 目標服務器可以解析該頭部信息，獲取客戶端的真實IP和端口等連接信息。

Proxy Protocol的工作原理：
Proxy Protocol使用一種簡單而有效的協議頭部格式來傳遞連接信息。協議頭部被插入到原始客戶端數據之前，以確保目標服務器能夠正確解析它。

流程圖：

優勢：在傳輸層建立連接前明文傳遞IP

• 需雙方支持，雙方選擇Proxy Protocol，表示將客戶端信息插入到TCP Payload字段中攜帶至服務端；
• 僅當服務端支持解析TCP Payload字段時，Proxy Protocol參數設置才有效；

風險：未加密，內網傳輸可接受；

解決方案3——加密 TCP Option

可以簡單理解為加密版proxy protocol協議，但需要在服務器端、邊緣代理端都進行改造，主要是在兩端加入相關功能模塊和設置一個對稱密鑰。

流程圖：

總結

一般Web系統用 Proxy Protocol 或 嚴格配置的XFF；

? 錯誤配置（覆蓋模式）

# 危險：直接覆蓋XFF頭
proxy_set_header X-Forwarded-For $remote_addr;

• 風險：
  • 如果Nginx前有可信代理（如CDN/WAF），此操作會擦除原始客戶端IP，僅保留代理IP。

? 推薦配置（追加模式）

# 安全：追加客戶端IP到XFF鏈
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

金融/政務系統選擇 TCP Option加密方案；