说到查自己主机在公网上的IP，你的第一反应是用什么: ifconfig? curl ip.sb? 百度/谷歌我的ip？这些方法都对，也都不对。下面从我们一个实际开发的业务场景来逐步抽丝剥茧这个过程吧。
我们在使用云端数据库的时候，本地需要连接数据库进行开发管理。
默认情况下，从安全角度考虑，云端的数据库是禁止外网访问的。如果需要外网访问，可以通过设置IP白名单进行过滤。因此，我们可以将单位的出口IP添加到数据库连接的白名单中，这样开发同学在单位的网络环境下，就可以本地连接云端数据库了。
按照这个思路走，首先需要获取单位的出口IP是什么。用curl ip.gs得到出口IP是：IP_A, 然后将这个IP_A加入到了数据库访问的白名单中, 然后本地访问数据库，发现连接不上，te.NET 数据库的端口也显示无法连接。
连接不上，排查的思路有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，这个是走的国内的网络。
以上。
