X-Forwarded-For 是一個 HTTP 擴展頭部，主要是為了讓 Web 服務器獲取訪問用戶的真實 IP 地址（其實這個真實未必是真實的，后面會說到）。
那為什么 Web 服務器只有通過 X-Forwarded-For 頭才能獲取真實的 IP？
這里用 PHP 語言來說明，不明白原理的開發者為了獲取客戶 IP，會使用 $_SERVER['REMOTE_ADDR'] 變量，這個服務器變量表示和 Web 服務器握手的 IP 是什么（這個不能偽造）。
但是很多用戶都通過代理來訪問服務器的，那么假如使用該全局變量，PHP獲取到的 IP 就是代理服務器的 IP（不是用戶的）。
可能很多人看的暈乎乎的，那么看看一個請求可能經過的路徑：
客戶端=>（正向代理=>透明代理=>服務器反向代理=>）Web服務器其中正向代理、透明代理、服務器反向代理這三個環節並不一定存在。
- 什么是正向代理呢，很多企業會在自己的出口網關上設置代理（主要是為了加速和節省流量）。
- 透明代理可能是用戶自己設置的代理（比如為了翻牆，這樣也繞開了公司的正向代理）。
- 服務器反向代理是部署在 Web 服務器前面的，主要原因是為了負載均衡和安全考慮。
現在假設幾種情況：
- 假如客戶端直接連接 Web 服務器（假設 Web 服務器有公網地址），則 $_SERVER['REMOTE_ADDR'] 獲取到的是客戶端的真實 IP 。
- 假設 Web 服務器前部署了反向代理（比如 Nginx），則 $_SERVER['REMOTE_ADDR'] 獲取到的是反向代理設備的 IP（Nginx）。
- 假設客戶端通過正向代理直接連接 Web 服務器（假設 Web 服務器有公網地址），則 $_SERVER['REMOTE_ADDR'] 獲取到的正向代理設備的 IP 。
其實這里的知識點很多，記住一點就行了，$_SERVER['REMOTE_ADDR'] 獲取到的 IP 是 Web 服務器 TCP 連接的 IP（這個不能偽造，一般 Web 服務器也不會修改這個頭）。
X-Forwarded-For
從上面大家也看出來了，因為有了各種代理，才會導致 REMOTE_ADDR 這個全局變量產生了一定的歧義，為了讓 Web 服務器獲取到真實的客戶端 IP，X-Forwarded-For 出現了，這個協議頭也是由 Squid 起草的（Squid 應該是最早的代理軟件之一）。
這個協議頭的格式：
X-Forwarded-For: client, proxy1, proxy2client 表示用戶的真實 IP，每經過一次代理服務器，代理服務器會在這個頭增加用戶的 IP（有點拗口）。
注意最后一個代理服務器請求 Web 服務器的時候是不會將自己的 IP 附加到 X-Forwarded-For 頭上的，最后一個代理服務器的 IP 地址應該通過$_SERVER['REMOTE_ADDR']獲取。
舉個例子：
用戶的 IP 為（A）,分別經過兩個代理服務器（B，C），最后到達 Web 服務器，那么Web 服務器接收到的 X-Forwarded-For 就是 A,B。
那么 PHP 如何獲取真實客戶端 IP 呢？
$ip = isset($_SERVER['HTTP_X_FORWARDED_FOR']) ? trim($_SERVER['HTTP_X_FORWARDED_FOR']) : ''; if (!$ip) { $ip = isset($_SERVER['REMOTE_ADDR']) ? trim($_SERVER['REMOTE_ADDR']) : ''; } $a = explode('|', str_replace(',', '|', $ip)); $ip = trim($a[0]);這里預先說明下，假設這兩個代理服務器都是好的代理服務器，沒有偽造 HTTP_X_FORWARDED_FOR。
配置反向代理
上面一直在說代理，大家可能覺得這到底有啥用？不同類型的代理有不同的目的，對於正向代理來說主要是為了加速並且讓局域網的用戶有一個真實的 IP 地址，而透明代理則主要是為了一些其他的目的（比如就是不想讓別人知道我的 IP），而反向代理主要是企業內部安全和負載均衡考慮，這里主要說下如何配置反向代理。
現在只要是具備一定規模的網站（Web 服務器大於 1 台），為了安全和負載均衡考慮都會在 Web 服務器前面部署反向代理，反向代理有 HAproxy，Nginx，Apache 等等。
這里通過 Nginx 來部署反向代理：
proxy_set_header Host $http_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;簡單的解釋下：
- X-Forwarded-For 表示 Nginx 接收到的頭，原樣的轉發過來（假如不轉發，Web 服務器就不能獲取這個頭）。
- X-Real-IP，這是一個內部協議頭（就是反向代理服務器和 Web 服務器約定的），這個頭表示連接反向代理服務器的 IP 地址（這個地址不能偽造），其實個人覺得為了讓 PHP 代碼保持無二義性，不應該這樣設置，可以修改為
proxy_set_header REMOTE_ADDR $remote_addr;
Apache WEB 服務器的 Access 日志如何獲取 X-Forwarded-For 頭
其實寫這篇文章主要是因為自己在 Apache Web 服務器上獲取不到 X-Forwarded-For（上層的負載均衡設備確定傳遞了），搜索了下（在 Apache 官方文檔並沒有找到解決方案），解決如下：
LogFormat "%{X-Forwarded-For}i %a %h %A %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combinedX-Forwarded-For 安全性
那么很多同學會說，通過 X-Forwarded-For 就能獲取到用戶的真實 IP，是不是萬事大吉了，對於 Web 服務器來說，安全有兩個緯度，第一個緯度是 REMOTE_ADDR 這個頭，這個頭不能偽造。第二個緯度就是 X-Forwarded-For，但是這個頭是可以偽造的。
那么誰在偽造呢？，我們分別看下：
正向代理一般是公司加速使用的，假如沒有特殊的目的，不應該傳遞 X-Forwarded-For 頭，因為它的上層連接是內部 IP，不應該暴露出去，當然它也可以透明的傳遞這個頭的值（而這個值用戶可以偽造）。
透明代理，這個可能是用戶自己搭建的（比如翻牆），而且在一個用戶的請求中，可能有多個透明代理，這時候透明代理就抓瞎了，為了讓自己盡量的正確，也會透明的傳遞這個頭的值（而這個值用戶可以偽造），當然一些不法企業或者人員，為了一些目的，會改下這個頭的值（比如來自世界各地的 IP 地址）。
反向代理，Web 服務器前的反向代理服務器是不會偽造的（同一個公司的），一般會原樣傳遞這個頭的值。
那么對應用程序來說，既然這個值不能完全相信，該怎么辦呢？這取決於應用的性質：
假如提供的服務可能就是一些非機密服務，也不需要知道用戶的真實 IP，那么建議應用程序或者 Web 服務器對 REMOTE_ADDR 做一些限制，比如進行限速等等，也可以放行一些白名單的代理 IP，但是這些白名單 IP 就太難衡量了。
假設你的服務很重要，比如抽獎（一個 IP 只能一次抽獎），這時候你可能想通過 X-Forwarded-For 來獲取用戶的真實 IP（假如使用 REMOTE_ADDR 則會誤殺一片），但是由於 X-Forwarded-For 可能會偽造，所以其實並沒有什么好的辦法，只能在應用層進行處理了。