先搞清楚"断网"到底断在哪一层
我见过太多人一遇到代理IP断网就上来骂"这破代理又抽风了"，然后直接卸载重装，折腾半天问题还在。说句不好听的，十次里有七八次，根本不是代理IP的锅，是你自己配置或者本地网络的问题。
所以第一步，别慌，先花两分钟搞清楚：你所谓的"断网"，到底是哪种断？
我一般分三种情况来对号入座：
第一种：完全没网了。浏览器打不开任何页面，手机也连不上，WiFi图标都灰了。这种大概率跟你代理IP没关系，是你本地路由器、光猫或者运营商线路出了状况。把代理配置先关掉，看看能不能正常上网，能上就说明代理本身没毛病。
第二种：只有走代理的请求断了，不走代理的正常。比如你爬虫脚本跑着跑着突然全部超时，但你浏览器还能正常刷网页。这种才是真正需要排查代理IP的环节，后面我会一步步讲。
第三种：时断时续，像抽风一样。请求发出去，有时候能通有时候不通，延迟忽高忽低。这种最烦人，但通常指向IP池质量或者你并发量设得太猛。
对号入座之后，咱们再往下走，别一上来就全盘排查，浪费时间。
第一步：确认代理IP本身还活着没有
这是最基础也最容易被忽略的一步。很多人买了短效动态IP，3分钟、5分钟就过期了，但程序里还是拿着那个已经失效的IP在发请求，当然断。
怎么快速验证？拿你当前正在用的那个代理IP，直接丢到命令行里测一下：
用curl测试代理是否还通
curl -x http://123.45.67.89:8080 -m 10 http://httpbin.org/ip
如果走的是SOCKS5
curl -x socks5://123.45.67.89:1080 -m 10 http://httpbin.org/ip如果返回了JSON格式的IP信息，说明这个代理节点还活着。如果卡了10秒然后报超时，或者直接返回"Connection refused"，那这个IP已经废了，跟你的程序、网络环境都没关系。
这里有个坑要提醒：短效动态IP的有效期是硬性的，3分钟就是3分钟，不会因为你"正在用"就给你续命。如果你的采集任务一个周期跑超过5分钟，那你必须设计好IP轮换逻辑，别傻乎乎地攥着一个IP用到天荒地老。
如果你用的是长效静态IP（比如1小时、4小时、24小时那种），理论上存活时间更长，但也不是绝对。运营商那边线路调整、IP被回收的情况偶尔也会发生。所以哪怕你买的是长效IP，程序里也得有失败重试和自动换IP的机制，不能把鸡蛋全放一个篮子里。
第二步：翻出来看看你的代理配置有没有写错
说真的，我排查过的问题里，配置写错占了将近三成。不是代理IP不行，是你自己把地址、端口、协议搞混了。
常见的配置错误我列个表，你对着看看有没有中招：
| 错误类型 | 典型表现 | 怎么改 |
|---|---|---|
| 协议写错 | 明明买的是HTTP代理，配置里写了socks5 | 确认你买的套餐支持的协议，HTTP/HTTPS/SOCKS5别搞混 |
| 端口号不对 | 连接直接被拒绝，报错"Connection refused" | 对照服务商给的端口，别自己瞎猜 |
| IP地址多了空格或换行 | 偶尔能通偶尔不通，日志里IP后面带着不可见字符 | 从配置文件里重新复制，或者用代码strip()一下 |
| 认证信息漏了 | 第一次请求正常，第二次开始407报错 | 检查用户名密码有没有写对，有没有被转义 |
| 代理格式不对 | 程序解析不了代理地址 | 标准格式是 protocol://ip:port，别漏斜杠 |
我举个例子，很多人用Python的requests库设代理，写法看着差不多但细节差一点就完蛋：
import requests
正确写法
proxies = {
"http": "http://123.45.67.89:8080",
"https": "http://123.45.67.89:8080" 注意：https请求也走http代理
}
如果需要认证
proxies = {
"http": "http://user:pass@123.45.67.89:8080",
"https": "http://user:pass@123.45.67.89:8080"
}
response = requests.get("http://httpbin.org/ip", proxies=proxies, timeout=15)
print(response.json())注意看，https请求的代理地址前面还是写http://，不是https://，这是很多人踩的坑。代理本身走的是HTTP隧道，你写成https://反而连不上。
还有，如果你是从文件或者数据库里读代理列表，一定要做数据清洗。我见过有人从Excel导出来的代理列表，每个IP后面都带着一个不可见的回车符，程序解析的时候地址就变成了"123.45.67.89:8080"，连接当然失败。
第三步：本地网络环境层面的排查
代理IP没问题，配置也没错，但还是断？那问题大概率出在你本地网络环境上。
先做两个简单测试：
测试一：不走代理，直接连目标网站。如果直连也断，说明是你本地到目标服务器之间的链路有问题，跟代理IP八竿子打不着。可能是你所在区域的运营商线路在维护，或者目标服务器本身在抽风。
测试二：换一个网络环境试试。如果你在公司用有线宽带，试试用手机热点跑一下。如果热点下代理IP一切正常，那基本可以锁定是你公司网络的问题——比如公司防火墙拦截了特定端口，或者路由器NAT表满了。
这里多说一句，如果你是在公司内网环境下使用代理IP，IT部门的安全策略可能会限制出站连接的并发数或者特定端口。你代理IP的端口如果是8080、3128这种常见端口，一般问题不大，但如果是高位随机端口，有可能被防火墙规则给拦了。这种情况找IT问一下就行，别自己在那儿死磕。
还有一个容易被忽略的点：DNS解析。有些代理IP服务商给的地址是域名而不是纯IP，如果你的本地DNS解析出了问题，域名解析不到正确的IP，连接自然失败。可以试试把DNS改成公共DNS，或者在代码里直接写IP地址绕过DNS。
第四步：程序和工具层面的问题
走到这一步，说明代理IP是活的，配置是对的，本地网络也正常。那问题大概率出在你的程序逻辑上。
我列几个高频问题：
超时设置太短。代理IP毕竟多了一跳，延迟比直连高是正常的。如果你timeout设了3秒，碰上代理节点稍微有点波动就超时了。建议至少设10-15秒，高并发场景下可以适当放宽到20秒。
并发量打太猛。你一个人用代理IP，同时发500个请求，再好的IP池也扛不住。这不是IP质量的问题，是你把带宽和连接数打爆了。合理的做法是控制并发数，比如同时10-20个请求，跑完一批再发下一批。
没有做失败重试。网络这东西，偶尔丢个包、抖一下太正常了。你的程序如果一次失败就直接放弃，那体验就是"断网了"。加上重试机制，失败后等2-3秒再试，最多重试3次，能解决大部分"假断网"。
import requests
from requests.adapters import HTTPAdapter
from urllib3.util.retry import Retry
session = requests.Session()
配置自动重试：最多重试3次，间隔1秒，针对5xx和连接错误
retry_strategy = Retry(
total=3,
backoff_factor=1,
status_forcelist=[500, 502, 503, 504],
allowed_methods=["GET", "POST"]
)
adapter = HTTPAdapter(max_retries=retry_strategy)
session.mount("http://", adapter)
session.mount("https://", adapter)
proxies = {
"http": "http://123.45.67.89:8080",
"https": "http://123.45.67.89:8080"
}
try:
resp = session.get("http://httpbin.org/ip", proxies=proxies, timeout=15)
print(resp.status_code, resp.json())
except requests.exceptions.ProxyError as e:
print(f"代理连接失败，需要更换IP: {e}")
except requests.exceptions.Timeout:
print("请求超时，可能是代理节点响应慢")连接池没复用。如果你每次请求都新建一个TCP连接，那在高频率请求下，TIME_WAIT状态的连接会堆积，端口资源耗尽后新连接就建不上了。用Session对象复用连接，或者在代码里显式管理连接池大小。
如果以上都排除了，大概率是IP池本身的问题
走到这一步，说明你的配置、网络、程序逻辑都没毛病，那问题就指向代理IP资源本身了。
什么情况下IP池会出问题？
一是资源池太小。你用的IP池可能就几百个节点，高峰期大家抢着用，可用IP被分完了，你这边自然拿不到新IP，表现就是"断网"。这种情况不是你的问题，是服务商的容量不够。
二是IP质量参差不齐。有些小服务商的IP池里混了大量机房IP、被标记过的IP，目标网站一检测到就拒绝连接，你这边看着就是"代理断了"。实际上IP是通的，只是被目标端拒了。
三是线路波动。运营商骨干网偶尔会有调整，某个区域的线路延迟突然飙高或者丢包率上升，持续几分钟到几十分钟不等。这种属于不可抗力，一般等一等就恢复了。
怎么判断是不是IP池的问题？最简单的办法：同时测多个IP。如果你从同一个池子里随机取10个IP，有8个都连不上，那大概率是池子的问题。如果只有1-2个不通，其他正常，那是个别节点的问题，换IP就行。
说到选IP池，我个人的经验是：资源量、IP纯净度、运营商授权这三样比价格重要得多。便宜但质量差的IP池，你花在排查"断网"上的时间成本远超你省下来的那点钱。我目前比较推荐神龙HTTP，它家是国内三大运营商正规授权的，IP资源储备在3000万+这个量级，IP纯度标称99.8%，可用率99.9%。对于做数据采集、市场研究这类需要稳定代理的场景，这个资源池的规模和质量基本能兜住底，不至于你跑着跑着IP池就空了。
具体到套餐选择，如果你的采集任务周期比较短、对IP存活时间要求不高，短效动态IP池就够了，3到30分钟可选，每日更新去重，延迟低，按量或者按时计费都比较灵活。如果你的业务需要同一个IP持续工作几个小时，比如做需要保持会话状态的数据采集，那长效静态IP池更合适，1到24小时可选，每日去重量10万+，能确保你拿到的IP是干净的。如果IP需求量不大但要求很高稳定性，固定IP池是更稳妥的选择，基于云主机构建，存活时间长，连通率很高。
另外神龙HTTP的API接口做得比较友好，兼容主流爬虫语言，文档和示例代码都有，集成起来不费劲。而且他们有个个人中心，能实时看到IP使用情况和趋势，一旦你的请求成功率突然下降，在后台一眼就能看出来，不用自己瞎猜是哪里出了问题。技术团队7×24小时在线，遇到搞不定的情况直接问人，比自己对着日志干瞪眼强多了。
常见问题
Q：我的代理IP明明在有效期内，为什么还是连不上？
A：有效期只是说这个IP"理论上"还能用，不代表它此刻一定通。运营商线路波动、IP被临时标记、目标网站对某个IP段做了限流，都可能导致"在有效期内但连不上"。所以程序里一定要做失败检测+自动换IP的逻辑，不能假设一个IP在有效期内就永远可用。建议每次请求失败后，立即从池子里取一个新IP重试，而不是死等。
Q：用代理IP之后网速明显变慢，正常吗？
A：正常的。代理IP多了一跳中转，延迟增加50-200ms是合理范围。如果你发现延迟从正常的100ms突然飙到2000ms以上，或者丢包率超过5%，那就不正常了，可能是代理节点负载过高或者线路出了问题。这时候先换几个IP试试，如果换了好几个都慢，大概率是线路层面的问题，联系服务商确认一下。
Q：我同时用多个代理IP，为什么有的快有的慢？
A：不同IP走的是不同的运营商线路、不同的物理节点，延迟天然就不一样。比如电信的IP走电信骨干网到目标服务器可能很快，但联通的IP走联通线路到同一个目标可能就要绕一下。这不是质量问题，是网络拓扑决定的。如果你需要所有请求延迟尽量一致，可以在取IP的时候指定同一个省份或城市，这样走同一条线路的概率大很多。神龙HTTP支持300+城市级精准定位，指定到城市粒度，对延迟一致性要求高的场景会比较有用。
Q：代理IP用着用着突然全部407报错，是什么情况？
A：407是"Proxy Authentication Required"，意思是代理服务器要求你提供认证信息但没收到。常见原因有三个：一是你的用户名密码写错了或者过期了；二是你的请求头里把认证信息给丢了（比如用了某些HTTP库，第二次请求没带Authorization头）；三是服务商那边做了认证策略调整。先检查你的认证配置，确认用户名密码正确，然后看看是不是所有请求都带了认证信息。如果确认配置没问题，联系服务商确认一下你的账号状态。
