某雲負載均衡真實IP的問題，我們這邊已經遇到過兩次了。而且每次和售後溝通的時候都大費周折，主要是要給售後說明白目前文檔的獲取真實IP是有問題的，他們覺得文檔上說明的肯定沒問題，售後要是不明白，他們不會給LB部門上報，這個事就沒法推進。
我們這邊的簡單的網絡架構設這樣的。
DNS->負載均衡->web機組
按照文檔說明獲取客戶端真實IP
七層負載均衡（HTTP或HTTPS協議）服務需要對應用服務器進行配置，然後使用X-Forwarded-For的方式獲取客戶端的真實源IP地址。真實的客戶端源IP存放在HTTP頭部的X-Forwarded-For字段，格式如下：
X-Forwarded-For: 用戶真實IP, 代理服務器1-IP， 代理服務器2-IP，...
當使用此方式獲取客戶端真實IP時，獲取的第一個地址就是客戶端真實IP。
我們第一版的獲取IP就是按照文檔的要求這麼寫的。
被僞造IP攻擊了
某一天，網站接口不停被打，一看攻擊IP地址都是一樣的，首先想到的是封IP，封了之後還是被打，真實服了，以爲代碼有問題，檢查很多遍確定不是代碼的問題，發現攻擊IP不停變，又想到會不會購買什麼動態IP的服務，user-agent是固定，而且IP地址是按數字累加的，比如剛開始是1.1.1.1，後來是1.1.1.2，再後來1.1.1.3，而且X-Forwarded-For這個頭，比正常訪問多了一層IP。
然後仔細分析了一下，首先覺得X-Forwarded-For獲取IP的方式是有漏銅的，因爲所有的請求頭都是可以在客戶端僞造的，所以我們測試了一下，
curl https://www.aaa.com -H"X-Forwarded-For:1.1.1.1"
通過這種方式，確實拿到了錯誤的真實ip。
真實IP只有負載均衡知道，因爲建立連接的時候可以通過remote_addr拿到真實的IP，只有這種是可信的，如果這個IP錯誤的話，就無法三次握手建立連接。
沒辦法，提工單找售後，答覆只這樣的
您好，目前七層監聽都是基於X-Forwarded-For 來獲取客戶端真實ip 信息的，或者您可以考慮下使用slb 四層監聽。
覺得這樣簡單的東西肯定有啊，一個公有云怎麼會沒有真實IP。自己在上游服務抓包觀察了一下，發現有一個這樣的頭 RemoteIp，我發現我不管怎麼僞造X-Forwarded-For，RemoteIp都是正確的IP。然後找售後確定一下我們的猜測，果然是這個。
您好，RemoteIp也是真實ip，是LB防止 x_forwarded_for 僞造。
改完代碼，一切順利
IP地址又錯了
IP地址好幾年沒出問題了，上個月有用戶反饋，IP地址錯了，我們網站按照要求，評論需要展示所在地理位置，我TM在蘇州啊，怎麼給我整到西安去了，沒去過啊。
沒辦法，只能去提工單了。
然後售後說是我們不能使用RemoteIp，應該按照文檔說明使用 x_forwarded_for，爲了說明 x_forwarded_for 沒問題，給我做了各種實驗，x_forwarded_for 這個問題從週五下午一直給售後扳扯到週六，說不通了，還貼出了幾年前的諮詢工單，最後售後大哥終於說了一句，我跟LB部門反饋一下。
大概過了半個小時就有結果了，結果是因爲我們開了waf防火牆。售後給的答覆。
1、Client -- WAF -- LB -- 上游服務 這種架構 ，那麼就得取 X-Real-IP 或X-True-IP 字段獲取客戶端真實IP。
2、Client -- LB -- 上游服務 這種架構 ，那麼就得取 RemoteIp 獲取客戶端真實IP。
然後改了一下代碼，先檢查頭裏面有沒有X-True-IP，如果有就使用X-True-IP，如果沒有就使用RemoteIp。