隧道代理连接失败怎么办?常见报错和解决方案

隧道代理连接失败怎么办?常见报错和解决方案 凌晨两点被告警吵醒采集脚本全线飘红这种体验相信跑过舆情监测、广告监测的兄弟都懂。折腾多了发现一个事实隧道代理突然连不上九成不是服务挂了而是配置、并发或者目标网站策略在某个环节踩了坑。这篇把常见报错按类型拆开每类给自查路径。目标是出问题时别瞎猜照着查多数10分钟内能定位。建议收藏出事的时候翻出来对着看。先分诊什么报错先查跟医院急诊一样先看影响面全量失败优先其次局部失败最后是成功但内容不对。现象优先级大方向100%请求失败高鉴权、欠费、白名单没生效大批量超时高并发超限、入口不可达、出站被拦部分407/403中账密错、个别白名单IP变了200但返回验证码/空内容中目标站限频、IP质量、区域限制偶发5xx低目标站抽风、网络瞬时抖动记一句话就够全量报错查代理侧配置局部报错查目标站策略成功但内容异常查请求节奏和IP质量。方向对了剩下就是体力活。报错关键字速查表拿到报错先对表别上来就翻代码关键字大概率原因先查什么Connection refused代理入口不通域名/端口、DNS解析Connection timeout网络不可达或防火墙出站规则、入口延迟407 Proxy Auth Required鉴权没过账密、白名单IP502 Bad Gateway代理后端异常换出口IP、看服务商公告503 Service Unavailable过载或维护降并发、等待504 Gateway Timeout目标响应超时目标站慢、调大超时SSL certificate verify failed证书校验失败系统时间、CA证书200 空内容/验证码目标站限制降频、加延迟、换城市下面挑几个高频的展开。超时先搞清楚是连不上代理还是通过代理连不上目标这两个问题长得像病根完全不同处理路径也不同。判断方法很简单两条curl# 测代理入口本身是否可达 curl -v --connect-timeout 5 -x http://user:passproxy.example.com:8000 http://httpbin.org/ip ​ # 上面通了再测目标站 curl -v --connect-timeout 5 --max-time 15 -x http://user:passproxy.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( total5, backoff_factor1, # 间隔 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, proxiesproxies, verifyFalse, timeout10)但说好了verifyFalse只许调试用。见过生产环境带着它跑了半年的项目安全上等于裸奔别学。返回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:passproxy.example.com:8000 https://httpbin.org/ip ​ # 第三步走代理打目标站看具体报错第二步返回的IP跟第一步一样代理压根没生效回去查配置。第二步返回代理IP、第三步也通、但业务还是失败问题在应用侧——请求头、Cookie、频率控制跟代理无关。第二步就挂代理配置或代理服务的问题。就这么一个简单的二分法能省掉大量无头苍蝇式排查。