趁熱記錄下，給未來的自己

說到查自己主機在公網上的IP，你的第一反應是用什麼： ifconfig？ curl ip。sb？ 百度/谷歌我的ip？這些方法都對，也都不對。下面從我們一個實際開發的業務場景來逐步抽絲剝繭這個過程吧。

我們在使用雲端資料庫的時候，本地需要連線資料庫進行開發管理。

預設情況下，從安全形度考慮，雲端的資料庫是禁止外網訪問的。如果需要外網訪問，可以透過設定IP白名單進行過濾。因此，我們可以將單位的出口IP新增到資料庫連線的白名單中，這樣開發同學在單位的網路環境下，就可以本地連線雲端資料庫了。

按照這個思路走，首先需要獲取單位的出口IP是什麼。用curl ip。gs得到出口IP是：IP_A， 然後將這個IP_A加入到了資料庫訪問的白名單中， 然後本地訪問資料庫，發現連線不上，telnet 資料庫的埠也顯示無法連線。

連線不上，排查的思路有2個：

雲端資料庫的白名單機制有問題

IP_A有問題

第一個排查思路，雲端這個SaaS服務出問題的機率基本很小，而且比較難以從使用者的角度去直接證明。第二個排查思路，比較好處理，而且如果這個排查思路被證實/證偽，那麼可以間接去證明第一個排查思路。

如果IP_A有問題，說明這個IP並不是真正連線資料庫的IP，那麼真正連線資料庫的IP是否可以獲得呢？答案是可以的：

先放開資料庫連線白名單，也就是允許所有的外部連線都可訪問該資料庫。

本地連線資料庫

mysql -hRDS連線地址 -u賬戶 -p密碼 -P3306

進入資料庫檢視程序資訊：

show processlist；

找到Info是show processlist的這一列，發現IP果然不是IP_A， 而是IP_B

然後把IP_B新增到資料庫訪問的白名單之後，就可以正常訪問資料庫了。

其實到這裡，就會有個問題出現：

為什麼我透過curl ip.gs 或者google查詢我的IP顯示的都是IP_A，而資料庫連線後，顯示我的IP是IP_B呢？

因為單位的網路是（合法地）支援科學上網的，會根據請求的目的地地址，自動判斷走國內的網路還是走境外的代理。在獲取IP_A的時候，其實請求的目的地地址都在境外，所以返回的公網IP自然也是境外代理的IP，也就是IP_A。如果用curl cip.cc 或者 baidu查詢我的IP顯示的就是IP_B，這個是走的國內的網路。

以上。