所以，自己公司DevOps搭建負載均衡服務器的時候，壹定要考慮這個問題，如何獲得發起請求的客戶端的真實IP，這個大多數情況下並不能獲得；但是如果沒有，就是偽負載均衡，只是對反向代理最前面壹層進行了負載均衡，並沒有對源ip進行負載均衡。
從上面看到實際上 Remote Address 就是反向代理服務器的地址, 是HTTP請求的遠程/源地址；三次握手就是用的這個地址，ACK時候也是；如果forgery這個那麽HTTP響應報文不能收到，所以這個偽造沒有任何意義，即 Remote Address 默認防偽造；而只有 Remote Address 用戶的真實IP地址將被丟失，因此有了HTTP擴展頭部 X-Forward-For . 反向代理服務器轉發用戶的HTTP請求時，需要將用戶的真實IP地址寫入到 X-Forward-For 中，以便後端服務能夠使用。由於 X-Forward-For 是可修改的，所以 X-Forward-For 中的地址在某種程度上不可信。在進行與安全有關的操作時，只能通過 Remote Address 獲取用戶的IP地址，不能相信任何請求頭
X-Forwarded-For 在Wikipedia的解釋: X-Forwarded-For
也就是LB和代理壹般是為了降低外部帶寬, 壹般我們都用了反向代理，屬於transparent proxy;
註:
X-Forward-For 跟 Referer 和 User-Agent 壹樣，都是 HTTP 中的頭域。HTTP/1.1 的 RFC 文檔編號為 2616，在 2616 中並未提及 X-Forward-For ，也就是說 HTTP/1.1 出現的時候 X-Forward-For 還沒出生。真正提出 X-Forward-For 的是2014 年的 RFC7239（詳見 https://www.rfc-editor.org/rfc/rfc7239.txt X-Forward-For 作為HTTP 擴展出現;
RFC7239 很長，實際上跟我們相關的只有幾個部分，例如： 1. Abstract ; 7.5. Example Usage
Abstract 是本文章的摘要，它描述了 RFC7239 的作用：
從這裏我們了解到 X-Forward-For 的正向用途是便於服務端識別原始 IP，並根據原始 IP 作出動態處理。例如服務端按照 IP 地址進行負載均衡時，如果能夠看破 IP 代理，取得原始 IP 地址，那麽就能夠作出有效的負載。否則有可能造成資源分配不均，導致假負載均衡的情況出現。
Example Usage 給了壹個例子:
X-Forwarded-For 格式:
如果壹個 HTTP 請求到達服務器之前，經過了三個代理 Proxy1、Proxy2、Proxy3，IP 分別為 IP1、IP2、IP3，用戶真實 IP 為 IP0，那麽按照 XFF 標準，服務端最終會收到以下信息：
所以，不論是從代理服務器第壹層還是最後壹層，都需要收集真實的IP才能進行真正的負載均衡