背景

       Web項目開發中，我們經常需要獲取到客戶端的真實ip，通過ip進行限流，防止接口被惡意用戶大量調用，影響系統性能甚至搞垮整個系統。

在Java中，獲取客戶端IP最直接的方式就是使用request.getRemoteAddr()。這種方式能獲取到連接服務器的客戶端IP，在中間沒有代理的情況下，的確是最簡單有效的方式。但是目前互聯網Web應用很少會將應用服務器直接對外提供服務，一般都會有一層 Nginx 做反向代理和負載均衡，有的甚至可能有多層代理。在有反向代理的情況下，直接使用request.getRemoteAddr()獲取到的IP是Nginx所在服務器的IP，而不是客戶端的 IP。

X-Forwarded-For

       為了獲取到客戶端的真實ip，我們需要用到X-Forwarded-For 。X-Forwarded-For 是一個 HTTP 擴展頭部。HTTP/1.1（RFC 2616）協議并沒有對它的定義，它最開始是由 Squid 這個緩存代理軟件引入，用來表示 HTTP 請求端真實 IP。如今它已經成為事實上的標準，被各大 HTTP 代理、負載均衡等轉發服務廣泛使用，并被寫入 RFC 7239（Forwarded HTTP Extension）標準之中。

X-Forwarded-For 請求頭格式非常簡單，就這樣：

X-Forwarded-For: client, proxy1, proxy2

可以看到，XFF 的內容由「英文逗號 + 空格」隔開的多個部分組成，最開始的是離服務端最遠的設備 IP，然后是每一級代理設備的 IP。

如果一個 HTTP 請求到達服務器之前，經過了三個代理 Proxy1、Proxy2、Proxy3，IP 分別為 IP1、IP2、IP3，用戶真實 IP 為 IP0，那么按照 XFF 標準，服務端最終會收到以下信息：

X-Forwarded-For: IP0, IP1, IP2

Proxy3 直連服務器，它會給 XFF 追加 IP2，表示它是在幫 Proxy2 轉發請求。列表中并沒有 IP3，IP3 可以在服務端通過 Remote Address 字段獲得。我們知道 HTTP 連接基于 TCP 連接，HTTP 協議中沒有 IP 的概念，Remote Address 來自 TCP 連接，表示與服務端建立 TCP 連接的設備 IP，在這個例子里就是 IP3。Remote Address 無法偽造，因為建立 TCP 連接需要三次握手，如果偽造了源 IP，無法建立 TCP 連接，更不會有后面的 HTTP 請求。

如何利用X-Forwarded-For請求頭偽造客戶端ip

       X-Forwarded-For缺點就是客戶端可以偽造。X-Forwarded-For一般的客戶端（例如瀏覽器）發送HTTP請求是沒有X-Forwarded-For頭的，當請求到達第一個代理服務器時，代理服務器會加上X-Forwarded-For請求頭，并將值設為客戶端的IP（也就是最左邊第一個值），后面如果還有多個代理，會依次將IP追加到X-Forwarded-For頭最右邊，最終請求到達Web應用服務器，應用通過獲取X-Forwarded-For頭取左邊第一個IP即為客戶端真實IP。

但是如果客戶端在發起請求時，請求頭上帶上一個偽造的X-Forwarded-For，由于后續每層代理只會追加而不會覆蓋，那么最終到達應用服務器時，獲取的左邊第一個IP將會是客戶端偽造的IP。

如何防范ip偽造

在直接對外的 Nginx配置：

proxy_set_header X-Forwarded-For $remote_addr;

$remote_addr是獲取的是直接TCP連接的客戶端IP（類似于Java中的request.getRemoteAddr()），這個是無法偽造的，即使客戶端偽造也會被覆蓋掉，而不是追加。