用代理ip不能上网了：从客户端设置到服务端状态的排查顺序

先说个很常见的画面：脚本前半小时跑得好好的，突然一片请求全部超时，日志刷得满屏红。第一反应是"IP挂了"，于是重新提取一批，换上去还是红。再换，还是红。四十分钟过去，最后发现是本地代码里端口号写错了一位，或者复制代理地址时尾巴上带了半个空格。

代理IP连不上，原因大概率不在IP本身。想少走弯路，顺序比经验重要：先看客户端，再看IP生命周期，最后才去怀疑服务端。下面这套顺序，照着点一遍，多数情况两三分钟就能定位。

一分钟分诊：是"全都不能用"还是"只有某个不通"

动手改配置之前，先花一分钟做判断。这一步能直接砍掉一半排查工作量。

把现象归到下面对应的一类里：

所有请求全挂。不管是访问A站还是B站，全部超时或者全部返回认证错误，问题基本出在代理链路本身——地址、端口、账号、协议这四项里必有一项不对。

只有某几个站不通，其他正常。代理本身是活的，问题在目标站点那一侧：可能是访问频率太快被限了，也可能是缺少必要的请求头被当成异常流量挡了。

浏览器能打开，脚本里报错。典型的配置不一致。浏览器往往走了系统代理，脚本里却写死了另一个地址；或者脚本没带 User-Agent，被站点直接回绝。

脚本正常，浏览器打不开。反过来，说明系统代理设置这一层有问题，或者浏览器装了插件在抢代理。

判断完再用命令行打一发单独的请求，比在完整业务代码里猜要快得多：

curl -x http://账号:密码@代理地址:端口 -I https://www.example.com --max-time 10 -v

加 -v 是为了看见握手过程。如果卡在 Connected to 代理地址 之后没有下文，链路是通的但转发没成功；如果连 Connected 都没打印出来，那就是地址端口或者网络出口的问题。

客户端：四个地方最容易被自己坑

这一段最枯燥，但命中率最高。四项挨个确认一遍。

第一项，地址和端口。有个特别隐蔽的坑：从后台复制代理地址的时候，行尾容易带一个不可见的空格或换行，肉眼看不出，程序解析的时候就报错。另一个坑是协议与端口错配——后台给的是 SOCKS5 的端口，你当成 HTTP 端口用了，表现就是连得上但一直没响应。建议每次只用鼠标拖选复制，别双击，粘完再看一眼长度对不对。

第二项，认证方式。有的代理是"账号密码"认证，有的是"白名单"认证，也就是只允许指定的出口IP来用。如果你换了一台上网机器，白名单里的地址没更新，那表现就是返回 407，看着像密码错，其实是身份根本没被认出来。另外，如果密码里带 @、#、: 这类符号，写进代理地址前必须做 URL 编码，否则程序会把 @ 当成账号和地址的分隔符，直接解析错位。这一条不知道坑过多少人。

第三项，协议类型。HTTP、HTTPS、SOCKS5 不是互相通用的。要在程序里写清楚是 http:// 还是 socks5://，别指望代理自动识别。还有一点，访问 HTTPS 站点时代理需要支持隧道方式，如果代理只支持普通 HTTP 转发，那 https 开头的地址就会失败，而 http 开头的地址却正常——这类"一半能用一半不能用"的现象，八成就是这个原因。

第四项，生效范围。系统代理、浏览器插件、软件内参数，这是三套互相独立的设置。最常见的是三处填了不同的地址，或者浏览器插件忘了关，流量被插件截走。排查时干脆把插件全停掉，只留一处配置，变量越少越好。

参数都对还是打不开？先确认这个IP还活着

短效动态IP是有寿命的。它的工作方式是：你提取出来一个IP，它就开始倒计时，到点自动失效，之后再用就是连不上或者超时。这不是故障，是正常机制。

所以遇到"刚才还好好的，突然全红"，第一个该问的问题不是"代理坏了没"，而是"我手上这个IP还剩多少时间"。判断方法很简单：拿同一个IP，中间隔几分钟测两次，对比结果。第一次通、第二次不通，就是过期了。

反过来，如果你需要长时间挂着的连接，比如维持登录状态做长时间的页面轮询，那就不要用短效的。这类场景更适合长效静态IP或者固定IP，一个地址能用很久，不用频繁换，连接也不会中途断掉。选错类型，后面怎么调参数都别扭。

另外两个容易忽略的点：一是超时时间设得太短，几百毫秒的阈值，稍微绕一下路就判失败了，看起来像不通，其实只是慢；二是请求节奏太密，同一批IP在极短时间内反复打同一个站点，很容易被对方识别成异常流量，表现也是时通时不通。

服务端视角：三步定位到底是谁的锅

客户端自查完，参数没问题、IP也没过期，那就要从服务端这一侧看。三步，按顺序来。

第一步，重新提取一批，换个城市试试。不是无脑重试，而是有对照地试：原来用的是A城市的IP，这次拿B城市的，测同一个目标站点。如果B城市一测就通，说明A城市的这批IP在那个站点上被限制了；如果B城市同样不通，那大概率是你自己的配置问题，回到上一节再看一遍。

第二步，认真读返回码。很多人一看失败就重试，从来不点开看具体是哪一行报错。407、403、502、超时，这四种的含义完全不同，处理方式也完全不同，下一节给你一张对照表。养成把返回码打进日志的习惯，排查效率至少翻倍。

第三步，查一查用量和并发。套餐的流量用完了、并发数顶到上限了，表现都是"能连上但拿不到数据"，跟配置错误的症状几乎一样。神龙HTTP的个人中心里有可视化的用量统计和实时监控，什么时候跑的、用了多少、哪个时段出现异常，一眼能看出来，比自己翻日志猜快得多。这一点在长期跑采集任务时特别省心。

四类报错，对应四种处理方式

把返回码看懂了，问题基本就定性了。下面这张表可以直接存下来当便签用。

现象	大概率原因	先动哪一步
407 需要代理认证	账号密码写错，或当前出口IP不在白名单里	核对账号密码，把当前上网出口地址加进白名单
403 被拒绝	目标站点识别到异常，限制了这个IP或这次请求	换个城市的IP，补齐请求头，把节奏放慢一点
502 上游异常	代理这一侧转发目标地址失败	重新提取一批，换个端口和协议再测一次
超时无响应	IP已过期，或超时阈值设得太紧	把超时调到10秒以上，同时确认IP是否还在有效期

最后一步：把环境剥到最干净

如果上面全试完还是没头绪，别在业务代码里继续纠缠了，写一个十行的最小脚本：只发一个请求，只带一个代理，只打印状态码和耗时。跑通它，再把业务代码里的东西一样一样加回去，加一样测一次。哪一样加上去就断，问题就在那一样。

import requests

proxies = {
    "http":  "http://账号:密码@代理地址:端口",
    "https": "http://账号:密码@代理地址:端口",
}

r = requests.get("https://www.example.com", proxies=proxies, timeout=10)
print(r.status_code, len(r.text))

注意 http 和 https 两个键都要写，而且值都填 http:// 开头的代理地址——这是很多人漏掉的一行，结果 https 请求根本没走代理，当然"打不开"。

还可以换个对照：同样的脚本，换一台机器、换一个上网环境跑一遍。两边结果一致，问题在服务端或者目标站点；一边通一边不通，问题就在那台不通的机器上。

把排查当常规动作，别当救火

写过一段时间采集脚本的人都会有体会：真正让人崩溃的不是失败本身，而是不知道失败在哪一层。把"客户端参数 → IP有效期 → 服务端状态"这个顺序形成习惯，再配上固定的日志格式（时间、IP、返回码、耗时四项），很多问题看一眼日志就有答案。

如果不想在IP稳定性上反复折腾，选一个靠谱的池子能省掉大把事情。神龙HTTP有3000万+正规授权代理IP储备，可用率99.9%，覆盖300+城市级精准定位，短效动态IP、长效静态IP、固定IP代理都有，按业务场景挑就行。接口兼容主流爬虫编程语言，文档和示例代码齐全，套进现有代码基本是改几行的事；跑起来之后在个人中心看用量曲线和实时监控，哪个环节掉链子一眼能识别。技术团队7×24小时在线，真碰到不好定位的问题，直接找人一起看比一个人硬扛快。