摘要：牢記任何客戶端傳上來的東西都是不可信的當多層代理或使用時，如果代理服務器不把用戶的真實傳遞下去，那么服務器將永遠不可能獲取到用戶的真實。

測試環境微信支付通道提示網絡環境未能通過安全驗證，請稍后再試，出現這種情況一般首要
想到可能是雙方網絡交互中微信方驗參與我們出現不一致，翻了下手冊確定是這類問題開始排查環節

可能獲取真實IP方式錯誤

getenv("HTTP_CLIENT_IP")

getenv("HTTP_X_FORWARDED_FOR")

getenv("REMOTE_ADDR")

filter_var($remote_ip, FILTER_VALIDATE_IP)

已經依次獲取并過濾

固程序沒有任何問題，往上發散

是否反向代理

經過反向代理后，由于在客戶端和web服務器之間增加了中間層，因此web服務器無法直接拿到客戶端的ip，只能通過$remote_addr變量拿到的將是反向代理服務器的ip地址，檢查不存在此類問題，再往上，擅長網絡通信工程的同學表示絕不認輸

可能NAT分配出口IP，或負載均衡服務分發出現異常

先拿到我本地內網外網IP 方便之后問題排查

# 本機IP
ifconfig | grep -A 1 "en" | grep broadcast | cut -d " " -f 2
# 外網IP
curl --silent http://icanhazip.com

檢查與80端口建立連接目標都有誰

 netstat -tn|grep 80|akw "{print $5}"|awk -F "{print $1}" | grep [本地IP]

這里出現問題，竟然沒有我的IP，再以nginx $remote_addr拿到的IP作為參考，這是nginx最后一次握手的IP,$remote_addr = 10.168.0.0/16 段

在nginx處打印$remote_addr，并在server_name添加當前機器ip，分別以負載均衡IP與本地IP做測試，最終確定問題出現在負載均衡服務器出現異常

LNMP棧內PHP所有獲得到的TCP操作信息都是由前面Nginx通過fastcgi傳遞給它的，就比如$_SERVER["REMOTE_ADDR"]由include fastcgi.conf;引進，其等于nginx的$remote_addr

Nginx中的幾個變量：

$remote_addr

代表客戶端的IP，但它的值不是由客戶端提供的，而是服務端根據客戶端的ip指定的，icanhazip的原理也是這樣， 當你的瀏覽器訪問某個網站時，假設中間沒有任何代理，那么網站的web服務器就會把remote_addr設為你在公網暴露的IP，如果你用了某個代理，那么你的瀏覽器會先訪問這個代理，然后再由這個代理轉發到網站，這樣web服務器就會把remote_addr設為這臺代理機器的IP, 除非代理將你的IP附在請求header中一起轉交給web服務器。

$proxy_add_x_forwarded_for

$proxy_add_x_forwarded_for變量包含客戶端請求頭中的"X-Forwarded-For"，與$remote_addr兩部分，他們之間用逗號分開。X-Forwarded-For（簡稱XFF），X-Forwarded-For 是一個 HTTP 擴展頭部。RFC 2616 協議并沒有對它的定義，它最開始是由 Squid 這個緩存代理軟件引入，用來表示 HTTP 請求端真實 IP。如今它已經成為事實上的標準，被各大HTTP 代理、負載均衡等轉發服務廣泛使用，并被寫入 RFC 7239（Forwarded HTTP Extension` 標準之中。

$proxy_set_header

已在排查問題中說明，可設置代理后 header

  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-Real-IP

一般比如X-Real-IP這一個自定義頭部字段，通常被 HTTP 代理用來表示與它產生TCP 連接的設備 IP，這個設備可能是其他代理，也可能是真正的請求端，這個要看經過代理的層級次數或是是否始終將真實IP一路傳下來。（牢記：任何客戶端傳上來的東西都是不可信的）

當多層代理或使用CDN時，如果代理服務器不把用戶的真實IP傳遞下去，那么服務器將永遠不可能獲取到用戶的真實IP。

寬帶供應商提供獨立IP
比如家里電信寬帶上網，電信給分配了公網ip，那么一個請求經過的ip路徑如下：

這種情況下，119.147.19.234 會把得到的116.1.2.3附加到頭信息中傳給10.168.0.0/32,因此這種情況下，我們取得的用戶ip則為:116.1.2.3。
如果119.110.0.0/16沒有把116.1.2.3附加到頭信息中傳給業務服務器，業務服務器就只能取上上一級ip地址

寬帶供應商不能提供獨立IP

寬帶提供商沒有足夠的公網ip，分配的是個內網ip，比如長寬等小的isp。請求路徑則可能如下：

這種情況下得到的用戶ip，就是211.162.78.1。 這種情況下，就可能出現一個ip對應有數十上百個用戶的情況了

手機2g上網

網絡提供商沒法直接提供ip給單個用戶終端，以中國移動cmwap上網為例，因此請求路徑可能為：

這種情況下得到的用戶ip，就是202.96.75.1。2008年的時候整個廣東聯通就三個手機上網的公網ip，因此這種情況下，同一ip出現數十萬用戶也是正常的。

有幾萬或數十萬員工的公司
這種也會出現來自同一ip的超多用戶，可能達到幾萬人，但出口IP可能就那么幾個。

中文意思是網絡地址轉換，它允許一個整體機構以一個公用IP地址出現在Internet上。

NAT在 OSI參考模型的網絡層 (第3層), 它是一種把內部私有網絡地址（IP地址）翻譯成合法網絡IP地址的技術。NAT可以讓那些使用私有地址的內部網絡連接到Internet或其它IP網絡上。NAT路由器在將內部網絡的數據包發送到公用網絡時，在IP包的報頭把私有地址轉換成合法的IP地址。

RFC1918 規定了三塊專有的地址，作為私有的內部組網使用

A類：10.0.0.0 — 10.255.255.255 10.0.0.0/8

B類：172.16.0.0 — 172.31.255.255 172.16.0.0/12

C類：192.168.0.0 — 192.168.255.255 192.168.0.0/16

這三塊私有地址本身是可路由的，只是公網上的路由器不會轉發這三塊私有地址的流量；當一個公司內部配置了這些私有地址后，內部的計算機在和外網通信時，公司的邊界路由會通過NAT或者PAT技術，將內部的私有地址轉換成外網IP，外部看到的源地址是公司邊界路由轉換過的公網IP地址，這在某種意義上也增加了內部網絡的安全性

這個過程是通過NAT中的本地址與全局地址映射條目來實現的，所以事先要在NAT路由器上配置這樣的映射條目。

通過這種方式一個公網 IP 底下可以發私有的 IP 地址。

寫這篇文章的時候看到有個推送，表示阿里全面應用IPV6,這件事的意義還挺重大的

我們知道，一段 IPv4 標準的 IP 地址，一共由 4 X 8 = 32 位二進制數字組成，理論上存在 2^32 個 IP 地址。等于 4,294,967,296 ， 42 億多個 IPv4 的地址。

參考世界互聯網用戶統計報告，全球現在大概有4,208,571,287人在上網，也就是說已經快到ipv4地址設計的最大IP數了

不過不用擔心，前面提到的 NAT，讓 IPv4 公網 IP 哪怕用完了也能湊合過。

到了 IPv6 ，相比 IPv4 最大的提升，就是位數大大增加，變成了 8 個 4 位的十六進制數字。也就是說有 2^128個 IPv6 地址。地球上的每粒沙子都分一個也管夠

存儲2^128字節理論上什么概念呢，在當今的量子水平下，假設計算設備能夠操作在原子一級，每公斤質量可存儲大約10的25次方bits，存儲2的128次方的字節大約需要272 trillion = 2720000億公斤。

最后，周末愉快，北京聯通已經支持ipv6了,我在望京測試，可以拿到 ipv6地址