云主机和容器里的代理IP问题，表现都差不多：任务连不上、来源不对、跑一会儿就断。原因却分布在不同层次上，从机器本身一直排到代码里面。按固定的顺序过一遍，比东试一下西试一下省时间。
按顺序过一遍
顺序按影响范围从大到小排。先确认最基本的通路，再确认配置有没有被读到，最后确认程序的行为是否符合预期。这个顺序的好处是每过一步都能排除一批可能，不会在原地打转。最外层的通路问题一旦确认，后面几步就可以跳过去；反过来，通路没问题而配置没生效，方向就转到了配置落在哪一层上。
- 先确认能不能通 从机器上直接访问目标，排除最基本的不通
- 再看配置有没有被读到 用另一个程序试，判断配置落在哪一层
- 然后看凭据和端口 格式有没有写错，端口对不对
- 最后看程序本身 它是不是没读那份配置，自己另开了一条连接
前两步没查出来怎么办
前两步都没问题，说明基本通路和配置位置是对的，问题往后移。这时候要看凭据是否过期、端口是否被占用，以及程序有没有缓存了旧的连接。重启程序、重新建立连接，很多时候问题就消失了。还有一类情况是程序自己另开了一条连接，根本没读那份配置，判断办法是换一个普通浏览器试一次，两边表现不一样就能确认。
还有一类问题只出现在容器里，和容器自己的网络隔离有关。宿主机上配好的东西容器读不到，容器重建之后写在内部的配置又会丢，这两点最容易让人误判为配置本身写错了。
- 容器的网络和宿主机隔着一层，配置要单独带进去
- 容器重建之后配置可能丢失，检查是否写在了持久的地方
- 多台机器上配置不一致，逐台对一遍
- 临时环境的配置改动没人记录，事后查不到
顺序固定下来，每次都从同一处开始。
查的时候一次只改一处。
云与容器环境里的代理IP问题，多数落在配置层次和容器隔离这两处。代理IP的设置在机器、容器、程序三个层次上都可能存在，逐层确认比整体重来有效。查的过程里一次只改一处，每次改动都留下一条结论，下次遇到同类问题就能直接跳过。顺序和记录，比经验更靠得住。