最近在專案對外聯調過程中，發現了關於XFF的問題，這裡簡單介紹下，大部分是貼維基百科中的詞條：https://zh.wikipedia.org/wiki/X-Forwarded-For
    專案場景：由於工程在自家伺服器中，但業務需求呼叫另一家的服務介面，因為伺服器只對內網開放，故實現事通過代理進行訪問外部介面，但header中的X-Forwarded-For暴露了正是的內網IP，而內網IP並不在另家服務中的白名單（另家的白名單中配置的是我們的外網IP），故聯調時出現未支援訪問請求異常。

    解決方式

 $header[] = "x-forwarded-for:" . 'IP';
 $header[] = "HTTP_X_FORWARDED_FOR:" . 'IP';
 $header[] = "REMOTE_ADDR:" . 'IP';

    這種方案其實是：這就是xff欺騙的方式，ORP官方不支援，如果大家有好的方式可以留言，相互交流。
     另外補充：對外IP最好是一組或多組網段，這樣減少網路擁堵，減少異常事故的風險。

    x-forwarded-for：是用來識別通過HTTP代理或負載均衡方式連線到Web伺服器的客戶端最原始的IP地址的HTTP請求頭欄位。

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

    X-Forwarded-For格式:X-Forwarded-For: client1, proxy1, proxy2 ；其中的值通過一個 逗號+空格 把多個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地址, 這通常是一個比較可靠的資訊來源。