同一份代码，在本地跑得好好的，部署到云上就报错。这类问题排查起来最费时间，因为两边的代码是一样的，差别全在环境上。代理IP的配置尤其容易出现这种落差：本地的机器上配过一次，自己都忘了；云上的机器是全新的，什么都没有。
差异一般出在哪几处
把本地和云上的环境逐项对一遍，差异通常集中在几处。本地的配置可能是很早以前手工加的，本地网络可能本来就能直连目标，本地的域名解析可能被改过。这些在本地都不显眼，换到云上就全暴露出来。
- 本机系统层配过代理IP，事后忘了
- 本地能直连目标，云上不能
- 本地的域名解析指向和云上不同
- 本地装了证书，云上没装
- 本地跑的端口和云上不一致
这几处的共同点是不写在代码里，也就不会被版本管理记录下来。本地换过机器、重装过系统，这些设置可能早就没了，但印象里还留着，于是误以为把代码搬过去就够。
网络可达性不一样
最常见的一处是可达性。本地网络能访问的目标，云上的机器未必能访问，尤其是境外的资源。这时候表现出来是连接超时，看上去像代理配置写错了，实际是根本没有通路。先测一下最基本的连通性，能省掉很多弯路。
先确认到底能不能通。
怎么定位
定位的办法是把两边的环境逐项对照。先比系统层的设置，再比程序读到的变量，最后比实际访问的结果。顺序上从最容易验证的开始：系统层的设置一条命令就能看到，程序读到的变量需要打印一次，实际访问的结果要跑一个小请求。三步做完，差异基本就锁定了，剩下的只是改哪一边。把两边的差异列成清单一条条对照，比凭印象猜有效得多。
代码一样，环境不一样，问题就在环境上。
对照着查，比反复改代码有效。
本地和云上的差异，几乎全在配置和网络环境上。代理IP的配置容易被忽略，因为它常常是很久以前配好的，没人记得。把两边的设置逐项对照一遍，把差异列出来，问题通常就在那张清单里。两边都对着，才知道差在哪。