當顧問講解完連線的方式後，Jerry就好奇的詢問，為何使用者的IP會改變了，那要怎麼重新抓取位置呢?

真實IP變了

在既有連線中，不管是伺服主機負載均衡還是WEB主機，都能夠正確的辨識出使用者端的來源IP。

但基於CDN採Reverse Proxy「中間人」架構，會在接收使用者的請求後，然後以它們自己的 IP 位址去向後端伺服器主機發出請求。

此時，服務端主機看到請求的來源就是Proxy主機，而不是真實使用者的IP，這樣機制會導致以下問題:

-存取紀錄不完整:由於來源IP不是真實使用者的IP，對於業務流量分析或是問題診斷與稽核等需求是都會造成問題。

-資安防護:如果服務發現攻擊如DDoS，此時阻擋的方式採IP時，是否就會造成誤檔，對於安全政策判斷的規則有一定程度的影響

X-Forwarded-For標頭就是為了解決這個問題!!

X-Forwarded-For

X-Forwarded-For（XFF）標頭的設計，是用來辨識使用者端透過 HTTP Proxy代理或負載平衡機制時，用來記錄當下主機的IP位置。

每經過一台HTTP Proxy代理或負載平衡，就會新增一個 X-Forwarded-For 標頭，而相關分析或稽核系統就可以利用檢查X-Forwarded-For標頭中的值，來判斷來源IP的資訊。

但問題也在這裡，X-Forwarded-For會把經過的所有IP都記錄起來，所以你會看到一串IP在這個欄位中

X-Forwarded-For: 1.1.1.1,2.2.2.2,3.3.3.3,4.4.4.4

這樣的表達方式，對於人眼辨識可能沒有問題，但於網路設備或是程式，就容易出現抓錯IP的情況。

因此，如果你的主機負載均衡設備對於解讀這個資訊有問題時，很容易發生請求都集中在某一台，或是將電子交易的請求送到其他未連線的主機，導致異常的情況。

True Client IP

為了避免X-Forwarded-For所造成判斷的問題，CDN商都會透過於HTTP標頭中，透過特定的欄位如Ture-Client-IP，將真實使用者的IP資訊放入。

而這個標頭會由CDN商的主機在將請求轉發給後端伺服器時自動添加，允許後端伺服器讀取該值並執行相應的操作。

由於這些都是公開的資訊，顧問提醒Jerry務必要進行調整，因為HTTP標頭是可以進行竄改的，如果有防護機制參考這個欄位進行阻擋，可能就會有問題。

True Client Port

有些金融單位可能會因為要調查詐騙或是異常交易等的需求，要來調閱服務存取IP資訊時，會因為現行電信業者採用的NAT方式，無法明確進行對應。

此時透過IP + Port的方式，警調單位可以透過這個資訊依據時間點，再去跟電信單位調閱當下連線的來源，以進行更精細的追查。

以下介紹如何透過Akamai的平台如何進行設定:

1. 首先要先介紹Akamai Property Manager的變數功能，這個功能在透過使用輸入/輸出資料時提供了更大的靈活性，包含修改傳入請求/回應標頭、修改傳出請求/回應標頭、修改傳出請求路徑、重新導向、設定回應 Cookie等。

那麼Akamai內建那些變數呢? 請參考以下的文章 Built-in variables

2. 理解變數的作用後，就來開始設定吧

首先於平台的Property Variables輸入以下的資料

Variable Name : CLIENT_SRC_PORT
Initial Value : %(AK_TRUE_CLIENT_PORT)

接著在Property Configuration Settings中新增一個Rule，設定的邏輯是，當請求的標頭裡面沒有True-Client-Port存在時，CDN平台會新增一個標頭將該欄位寫入，並將真實使用者的連線Port值一併放入。