獲取用戶真正的ip地址

最新 07-11

我在用百度ip地址定位介面時，當把封裝的ip定位的介面打war包放在伺服器上時，出現獲取的地址為伺服器所在地的地址，

百度ip地址定位介面是可以根據你輸入的ip來定位，需要用戶輸入ip地址是不可能的，用戶也不知道他的ip地址是多少。

X-Forwarded-For

X-Forwarded-For:簡稱XFF頭，它代表客戶端，也就是HTTP的請求端真實的IP，只有在通過了HTTP 代理或者負載均衡伺服器時才會添加該項。它不是RFC中定義的標準請求頭信息，在squid緩存代理伺服器開發文檔中可以找到該項的詳細介紹。標準格式如下：X-Forwarded-For: client1, proxy1, proxy2。

產生背景

X-Forwarded-For(XFF)是用來識別通過HTTP代理或負載均衡方式連接到Web伺服器的客戶端最原始的IP地址的HTTP請求頭欄位。 Squid 緩存代理伺服器的開發人員最早引入了這一HTTP頭欄位，並由IETF在Forwarded-For HTTP頭欄位標準化草案中正式提出。

當今多數緩存伺服器的使用者為大型ISP，為了通過緩存的方式來降低他們的外部帶寬，他們常常通過鼓勵或強制用戶使用代理伺服器來接入互聯網。有些情況下, 這些代理伺服器是透明代理, 用戶甚至不知道自己正在使用代理上網。

如果沒有XFF或者另外一種相似的技術，所有通過代理伺服器的連接只會顯示代理伺服器的IP地址(而非連接發起的原始IP地址), 這樣的代理伺服器實際上充當了匿名服務提供者的角色, 如果連接的原始IP地址不可得，惡意訪問的檢測與預防的難度將大大增加。XFF的有效性依賴於代理伺服器提供的連接原始IP地址的真實性，因此, XFF的有效使用應該保證代理伺服器是可信的, 比如可以通過建立可信伺服器白名單的方式。

格式

這一HTTP頭一般格式如下:

X-Forwarded-For: client1, proxy1, proxy2, proxy3

其中的值通過一個逗號+空格把多個IP地址區分開, 最左邊(client1)是最原始客戶端的IP地址, 代理伺服器每成功收到一個請求，就把請求來源IP地址添加到右邊。在上面這個例子中，這個請求成功通過了三台代理伺服器：proxy1, proxy2 及 proxy3。請求由client1發出，到達了proxy3(proxy3可能是請求的終點)。請求剛從client1中發出時，XFF是空的，請求被發往proxy1；通過proxy1的時候，client1被添加到XFF中，之後請求被發往proxy2;通過proxy2的時候，proxy1被添加到XFF中，之後請求被發往proxy3；通過proxy3時，proxy2被添加到XFF中，之後請求的的去向不明，如果proxy3不是請求終點，請求會被繼續轉發。

鑒於偽造這一欄位非常容易，應該謹慎使用X-Forwarded-For欄位。正常情況下XFF中最後一個IP地址是最後一個代理伺服器的IP地址, 這通常是一個比較可靠的信息來源。

使用

在代理轉發及反向代理中經常使用X-Forwarded-For 欄位。

代理轉發

在代理轉發的場景中，你可以通過內部代理鏈以及記錄在網關設備上的IP地址追蹤到網路中客戶端的IP地址。處於安全考慮，網關設備在把請求發送到外網（網際網路）前，應該去除 X-Forwarded-For 欄位里的所有信息。這種情況下所有的信息都是在你的內部網路內生成，因此X-Forwarded-For欄位中的信息應該是可靠的。

反向代理

在反向代理的情況下，你可以追蹤到互聯網上連接到你的伺服器的客戶端的IP地址, 即使你的網路伺服器和互聯網在路由上是不可達的。這種情況下你不應該信任所有X-Forwarded-For信息，其中有部分可能是偽造的。因此需要建立一個信任白名單來確保X-Forwarded-For中哪些IP地址對你是可信的。

最後一次代理伺服器的地址並沒有記錄在代理鏈中，因此只記錄 X-Forwarded-For 欄位是不夠的。完整起見，Web伺服器應該記錄請求來源的IP地址以及X-Forwarded-For 欄位信息。

Web日誌

大多數Web伺服器可以通過配置在日誌中記錄X-Forwarded-For。 Apache中可以非常簡單地修改配置來實現，但MS IIS 6及以下的版本需要第三方軟體支持來實現。IIS7用戶可以從IIS官方網站獲得免費的IIS相關組件來實現。

java中使用X-Forwarded-For獲取用戶真正ip地址

String ipS = null;

String ipFor = request.getHeader("x-forwarded-for");