凌晨两点被告警吵醒，采集脚本全线飘红，这种体验相信跑过舆情监测、广告监测的兄弟都懂。折腾多了发现一个事实：隧道代理"突然连不上"，九成不是服务挂了，而是配置、并发或者目标网站策略在某个环节踩了坑。
这篇把常见报错按类型拆开，每类给自查路径。目标是：出问题时别瞎猜，照着查，多数10分钟内能定位。建议收藏，出事的时候翻出来对着看。
先分诊：什么报错先查？
跟医院急诊一样，先看影响面，全量失败优先，其次局部失败，最后是"成功但内容不对"。
| 现象 | 优先级 | 大方向 |
|---|---|---|
| 100%请求失败 | 高 | 鉴权、欠费、白名单没生效 |
| 大批量超时 | 高 | 并发超限、入口不可达、出站被拦 |
| 部分407/403 | 中 | 账密错、个别白名单IP变了 |
| 200但返回验证码/空内容 | 中 | 目标站限频、IP质量、区域限制 |
| 偶发5xx | 低 | 目标站抽风、网络瞬时抖动 |
记一句话就够：全量报错查代理侧配置，局部报错查目标站策略，成功但内容异常查请求节奏和IP质量。 方向对了，剩下就是体力活。
报错关键字速查表
拿到报错先对表，别上来就翻代码：
| 关键字 | 大概率原因 | 先查什么 |
|---|---|---|
| Connection refused | 代理入口不通 | 域名/端口、DNS解析 |
| Connection timeout | 网络不可达或防火墙 | 出站规则、入口延迟 |
| 407 Proxy Auth Required | 鉴权没过 | 账密、白名单IP |
| 502 Bad Gateway | 代理后端异常 | 换出口IP、看服务商公告 |
| 503 Service Unavailable | 过载或维护 | 降并发、等待 |
| 504 Gateway Timeout | 目标响应超时 | 目标站慢、调大超时 |
| SSL certificate verify failed | 证书校验失败 | 系统时间、CA证书 |
| 200 + 空内容/验证码 | 目标站限制 | 降频、加延迟、换城市 |
下面挑几个高频的展开。
超时：先搞清楚是"连不上代理"还是"通过代理连不上目标"
这两个问题长得像，病根完全不同，处理路径也不同。判断方法很简单，两条curl：
# 测代理入口本身是否可达
curl -v --connect-timeout 5 -x http://user:pass@proxy.example.com:8000 http://httpbin.org/ip
# 上面通了，再测目标站
curl -v --connect-timeout 5 --max-time 15 -x http://user:pass@proxy.example.com:8000 https://your-target.example.com/
第一条就挂——代理入口不通，往这几个方向查：入口域名/端口抄错了（比想象中常见）、服务器出站防火墙拦了代理端口、DNS解析失败（先ping一下入口域名）、服务商入口临时波动（看状态页）。
第一条通、第二条超时——代理没问题，问题在代理到目标这段：目标站本身响应慢，超时从10秒调到20-30秒试试；隧道并发超限触发云端节流，降并发；出口IP到目标站的路由质量差，换IP或换城市。
说到并发超限，提醒一个容易忽略的点：隧道套餐一般有默认吞吐上限，比如我们用的极安隧道默认每秒5个请求、5M带宽，超了就节流，表现为"偶发超时、时好时坏"。这种症状最有迷惑性，看着像网络抖动，其实是自己撞了限流。上量之前先去控制台把并发申请调大。
407：鉴权没过，两种方式分开查
账密认证的坑基本是这几个：
- 用户名密码跟控制台不一致——注意隐藏空格、大小写、特殊字符
- 特殊字符没做URL-encode，
@要写成%40，这个坑我见人踩过不止一次 - 账号欠费或过期
- 密码被人重置了（多人共用账号的团队请自查）
白名单认证的坑更隐蔽：
- 服务器公网IP变了没同步——云主机重启、弹性IP切换都会变
- 白名单加了但没点保存
- 走了多层NAT，真实出口IP不是你以为的那个。
curl ifconfig.me查一下，跟白名单对比，经常有惊喜 - 白名单条目到套餐上限了，新加的静默失败
另外有些服务商支持两种鉴权同时启用，客户端得正确指定用哪种，去控制台核对一下鉴权模式设置。
分清是代理端的锅还是目标站的锅
看响应头，带Via或X-Proxy标识的是代理端返回的：
- 502：出口IP连目标失败。隧道会自动换IP重试，偶发不用管；长时间大量502，可能目标站封了某类节点，联系服务商换城市或换池
- 503：代理服务维护或过载，看状态页，降频等着
- 504：代理端等目标响应超时，把超时调大到20-30秒
目标站返回的5xx跟代理没关系。验证方法：关掉代理直连一次（前提目标允许直连），直连也5xx就是目标自己的问题，等它恢复。
应对偶发5xx，指数退避是标准姿势：
from urllib3.util.retry import Retry
retry = Retry(
total=5,
backoff_factor=1, # 间隔 1s, 2s, 4s, 8s, 16s
status_forcelist=[500, 502, 503, 504],
allowed_methods=["GET", "POST"]
)
SSL报错：三个原因常见原因
系统时间不准。HTTPS证书校验依赖系统时间，时钟偏移超过几分钟就全线校验失败。新开的服务器NTP没同步，栽在这上面的人排队能绕机房一圈。ntpdate或chrony同步一下。
根证书过期。老服务器CA证书没更新，遇到新颁发的证书就挂。apt update && apt install ca-certificates。
中间人拦截。企业内网、某些云环境会做SSL中间人，证书链异常。这个要在内网层面解决，跟代理没关系。
调试时可以临时跳过校验：
response = requests.get(url, proxies=proxies, verify=False, timeout=10)
但说好了，verify=False只许调试用。见过生产环境带着它跑了半年的项目，安全上等于裸奔，别学。
返回200，但内容是验证码
HTTP 200不代表业务成功，这句话值得刻在显示器上。目标站完全可能给你返回200，内容却是"访问频率过快"、验证码页面、或者一个空列表。日志里一片200，数据库里一片空，这类问题最难第一时间发现。
病根不在代理，在请求节奏和IP质量。按这个顺序调：
- 降频：单IP请求间隔拉到3-5秒，加随机延迟，别让请求有规律性
- 看IP质量：被大量团队用烂的IP，目标站早标记了。选IP来源合规、走运营商正规节点的服务商
- 换城市/出口：有的站按地域返回不同内容或限制某些城市
- 对齐请求头：User-Agent、Referer、Accept-Language模拟正常浏览器
- 补Cookie/Session：有些站要先访问首页拿Cookie才给内容
- 降并发：从每秒几十降到每秒几个，看是否恢复
IP质量这块多说一句：像极安这种走三大运营商节点、日更300万+IP的池子，"IP被重复用烂"的问题会少一些。但别指望换个好IP池就万事大吉——请求节奏和请求头对目标站的接受度影响更大，该做的伪装一样都不能省。
万能三步测试法：2分钟定位问题在哪一侧
不管什么疑难杂症，先跑这三步，把问题锁定在代理侧还是应用侧：
# 第一步：不走代理，确认服务器能上外网
curl https://httpbin.org/ip
# 第二步：走代理，看返回的IP是不是代理出口IP
curl -x http://user:pass@proxy.example.com:8000 https://httpbin.org/ip
# 第三步：走代理打目标站，看具体报错
第二步返回的IP跟第一步一样？代理压根没生效，回去查配置。第二步返回代理IP、第三步也通、但业务还是失败？问题在应用侧——请求头、Cookie、频率控制，跟代理无关。第二步就挂？代理配置或代理服务的问题。
就这么一个简单的二分法，能省掉大量无头苍蝇式排查。
