凌晨一点，脚本跑了三个小时，报错日志里全是 Connection refused。第一反应通常是"代理挂了"，然后就去后台换一条。但说实话，我踩过太多次坑之后发现，十次里大概有六七次，问题根本不在代理本身——是本地网络、认证写法、端口被拦，或者干脆那条IP的时效已经过了。
这篇就把我自己的排查顺序写下来。从最贴近身边的一层开始，一层一层往外推，多数情况走到第三步就能定位。
第一层：先确认本地网络本身是通的
这一步听起来很蠢，但漏掉的人最多。尤其在公司、咖啡厅、酒店这类网络环境里，你连"关掉代理能不能正常上网"都没验证，就开始怀疑IP，纯属浪费时间。
最直接的做法：把代理配置暂时停掉，浏览器打开一个普通网页。能打开，说明本地出口没问题，继续往下查；打不开，那问题从路由、Wi-Fi 到 DNS 都有可能，跟代理没关系。
命令行更干脆，一条命令就能看到返回码：
# 不走代理，直接访问，看能不能通
curl -sS -o /dev/null -w "%{http_code}\n" https://www.example.com
# 返回 200 说明本地出口正常
# 返回 000 或者卡住不动，就是本地网络的问题
再顺手看一下本机有没有奇怪的环境变量在捣乱。很多工具会偷偷读 http_proxy 和 https_proxy，你以为没设代理，其实早被环境变量接管了：
# Linux / macOS
env | grep -i proxy
# 如果里面有一条早就失效的旧地址，先清掉再测
unset http_proxy https_proxy all_proxy
还有一种很隐蔽的情况：本地 127.0.0.1 上有个旧的代理客户端还在后台跑着，端口被它占住，你的新配置根本连不出去。换成手机热点试一次，如果一下就通了，那基本可以确定是原来的网络环境里有东西在拦。
第二层：认证过不去，九成是这四个地方
报错里出现 407 Proxy Authentication Required，或者提示账号密码错误、未授权，都属于认证环节。别看提示只有一句，真实原因一般就四种。
第一，账号密码里有特殊字符没转义。密码里带 @、#、: 这类符号的时候，直接拼进地址会解析错位。比如密码是 abc@123，写成 http://user:abc@123@gateway:8080，工具会把 abc 当密码、123@gateway 当主机名，然后报一堆看不懂的错。正确写法是做 URL 编码，@ 换成 %40，# 换成 %23。
第二，绑定了终端 IP 白名单。不少服务商会要求先在后台把你的公网出口 IP 加进白名单，只有名单里的机器才能用。你换了个 Wi-Fi、或者家里宽带重新拨号换了出口地址，认证就会失败。这种情况不是账号坏了，是"你不认识它了"。
第三，协议选错了。手上拿到的是 SOCKS5 的地址和端口，却填在 HTTP 代理的输入框里，握手阶段就对不上。这个错误特别常见，因为两个地址长得差不多。
第四，时效已经到期。短效的IP是按小时计的，脚本挂在后台跑了一整夜，第二天接着用同一批地址，当然连不上。养成习惯：批量任务开始前先确认剩余时效，跑长途的分批取用。
用 curl 分别测一次 HTTP 和 SOCKS5，一眼就能看出是哪边的问题：
# HTTP / HTTPS 代理
curl -x http://用户名:密码@gateway.example.com:8080 -v https://www.example.com
# SOCKS5 代理（socks5h 表示域名交给代理解析）
curl -x socks5h://用户名:密码@gateway.example.com:1080 -v https://www.example.com
加 -v 是为了看到握手细节。连不上和认证失败，日志里的表现完全不同，一个是卡在 TCP 连接，一个是能连上但被拒绝。
第三层：端口被拦住了，换网络比换IP更快
如果 curl 的输出一直停在 Trying xxx.xxx.xxx.xxx...，好几十秒都不动，最后超时，那基本不是账号问题，是端口层面的连接根本建立不起来。
原因通常有三个方向，按概率排：
公司或校园网的出站规则。很多内网只放行 80 和 443 这类常用端口，8080、1080 这种直接在网关就被丢了。你在自己的电脑上怎么折腾都没用，因为包根本没出去。
本地防火墙或安全软件。Windows 防火墙、第三方安全工具会拦截陌生程序的出站连接。表现是浏览器手动配置能用，脚本一跑就失败——因为浏览器早就被允许过，而你的脚本是第一次运行。
运营商或公共 Wi-Fi 的限制。酒店、机场这类网络对非常用端口普遍不友好，偶尔连上了也不稳定。
判断方法很土但管用：把电脑连到手机热点上，用同样的地址、同样的端口再测一次。热点通了，说明原网络在拦；热点也不通，才轮到怀疑服务端。
确实需要在受限网络里跑，解决办法是问服务商有没有 443 端口的入口，或者走支持加密隧道的协议。神龙IP 这边支持 IKEv2、PPTP、L2TP、SSTP、SOCKS5 几种方式，数据传输全程加密，遇到端口受限的环境，换一种接入方式往往比死磕同一个端口省事得多。
第四层：配置写法里那些不容易发现的小错
代码里出问题，八成是把参数写错了位置。这个环节没什么技巧，对照着看一眼就行。
import requests
# 错误示范：只给了 http，https 请求仍然直连
proxies = {"http": "http://用户名:密码@gateway.example.com:8080"}
# 正确写法：http 和 https 都要给
proxies = {
"http": "http://用户名:密码@gateway.example.com:8080",
"https": "http://用户名:密码@gateway.example.com:8080",
}
r = requests.get("https://www.example.com", proxies=proxies, timeout=10)
print(r.status_code, r.text[:80])
几个高频的坑，顺手列一下：
· 超时时间没设，程序卡在那里看着像"代理坏了"，其实是永远在等。
· 忘记 timeout 参数，requests 默认会一直等下去。
· 目标站点返回 403，你以为是代理失效，其实是对方识别出了访问行为，跟IP质量有关，跟配置无关。
· 并发开太高，把套餐带宽打满，表现就是"时快时慢、偶尔连不上"。峰值带宽是有上限的，跑之前先算一下同时发起的请求数。
下面这张表是我自己常备的对照，看到报错先扫一眼：
| 报错 / 现象 | 最可能的原因 | 第一步做什么 |
|---|---|---|
| 407 Proxy Authentication Required | 账号密码错误、特殊字符未转义、白名单缺失 | 核对密码是否含 @ # 等符号，检查白名单 |
| Connection refused | 端口写错、协议不匹配 | 确认拿到的是 HTTP 还是 SOCKS5 端口 |
| 一直卡在 Trying... 后超时 | 端口被网络环境拦截 | 换手机热点复测一次 |
| 时而能连时而不能 | IP 时效到期、并发超带宽 | 检查剩余时效、降低并发 |
| 能连但返回 403 | 目标站点的访问策略 | 调整访问节奏，不是配置问题 |
排完之后，什么样的服务商值得留着
把上面四层走完还是不通，就属于该找服务商的范畴了。这时候你会发现，同样是找客服，有的平台让你反复截图、反复测试，有的平台后台一看就知道是哪条线路的问题——差别就在于对方是不是自营资源。
做个对比参考：神龙IP 覆盖 200+ 城市，可做精准定位，资源池 1000万+ 纯净IP，响应在 30ms 量级，带宽 6-15M 可定制。这些数字落到实际排障上意味着什么？意味着你在写脚本之前就能按城市挑好出口，不用靠随机分配碰运气；意味着响应稳定在几十毫秒，超时报警不会天天响。
它家的动态独享套餐峰值 10Mbps，时效 2-360 小时可选，适合需要固定出口跑一段时间的任务，比如连续几天的数据采集或者服务器压力测试；静态高级则是长期固定IP，走运营商合作资源，适合需要长期保持同一个身份的场景，比如自媒体账号的独立防关联。选的时候不要一上来就买最贵的，先想清楚你的任务是"短时间大量取用"还是"长时间保持不变"，答案很不一样。
常见问题
Q：账号密码明明没输错，为什么一直提示认证失败？
先看密码里有没有 @、#、: 这类字符，有的话必须做 URL 编码，否则地址会被解析错位。其次看后台有没有绑定终端白名单，换了网络之后出口 IP 变了，原来的白名单就不认你了。最后确认协议类型和端口是一对一的，SOCKS5 的端口填进 HTTP 输入框同样会认证失败。
Q：同一条IP，浏览器能用，脚本一跑就挂？
大概率是本地防火墙只放行了浏览器，没放行你的解释器或脚本程序。也可能是代码里只给 http 配了代理、https 还是直连，或者干脆忘了设 timeout，卡住之后看起来像失败。把代理同时写到 http 和 https 两个键上，再跑一次就能确认。
Q：在家能用，公司就用不了，是IP被封了吗？
多数不是。公司内网普遍只放行 80、443 这类端口，你用的 8080 或 1080 在网关就被丢掉了，所以 curl 会一直卡在连接阶段直到超时。拿手机热点测一次，如果立刻通了，说明是网络环境在拦，和服务商没关系。这种情况下换一个走 443 的接入方式最省事。
Q：早上跑得好好的，下午全部连不上，怎么回事？
先看时效。短效IP是按小时计费的，2 到 360 小时不等，到期后地址会回收，你手上那批自然就用不了了。再看并发，峰值带宽是有限制的，请求开太多把带宽占满，表现就是时快时慢甚至连不上。把并发降到原来的一半再试，如果能恢复，那就是带宽打满了，不是IP出了问题。
