能上网，不等于代理真的在干活
代理配好了，很多人第一反应是打开个网页，能刷出来就当成功了。这个习惯坑过不少人：有位做数据采集的朋友跟我吐槽，任务跑了整整一晚上，第二天核对日志才发现，请求全是从本机真实IP发出去的，代理从头到尾在空转。程序框架里常有"代理连不上就自动直连"的容错设计，表面一切正常，实际上代理是个摆设。
所以拿到一个新代理，先别急着上业务，花两分钟把三关过一遍：出口IP变了没有、流量走没走代理、表现稳不稳定。三关全过才算真的生效。下面按顺序拆开讲，每一步都给你能直接上手的操作。
第一步：对比出口IP，最直观的判定方法
原理很简单：代理生效后，目标网站看到的应该是代理服务器的IP，而不是你本机的IP。验证动作就是"查两次、比一下"。
不挂代理时，在浏览器里搜"IP查询"，随便挑一个查询网站，记下显示的IP和归属地；挂上代理后刷新同一个页面再看。IP变了、地区和你选的节点对得上，说明基本生效；IP纹丝不动，要么代理没配上，要么程序在悄悄走直连。
习惯用命令行的，两条命令更利索：
# 先记录本机真实IP（地址可换成任意IP查询网站的接口）
curl myip.example-check.com
# 通过代理再查一次，-x 后面跟代理地址和授权信息
curl -x http://用户名:密码@代理地址:端口 myip.example-check.com读结果时注意两点：一是IP确实换了，二是归属地要和节点一致。有人IP换了但显示的地区对不上，多半是资源池里混了别的地区，做和地区相关的业务时就会出岔子，遇到这种情况直接重新提取一批新的IP再验。
第二步：确认流量真的走了代理，而不是直连兜底
这是最容易踩坑的一关，三个办法可以查。
办法一：查环境变量。命令行工具大多认这几个变量，看看它们是否指向你的代理：
echo $http_proxy $https_proxy
# 输出类似 http://127.0.0.1:7890 才算配置上了，为空说明命令行根本没走代理办法二：程序里显式指定，别依赖全局配置。以 Python 为例，把代理直接写进请求参数，作用范围清清楚楚：
import requests
proxies = {
"http": "http://用户名:密码@代理地址:端口",
"https": "http://用户名:密码@代理地址:端口",
}
# 地址换成你常用的IP查询接口
resp = requests.get("http://ip.example-check.com",
proxies=proxies, timeout=10)
print(resp.text) # 返回的是代理IP，说明这条请求确实走了代理办法三：看用量对不对得上。本地发100个请求，就去服务商后台看有没有100条对应的记录。如果后台统计的请求量和你实际发起的差得远，基本可以断定有一部分流量绕过了代理，回头检查配置就行。
第三步：测稳定性和匿名度，别被"半生效"坑了
IP变了、流量也走了代理，还不算完。短时测试通过、长跑就掉链子的代理比比皆是，上业务前建议再做两件事。
一是连续请求测试。写个十来行的循环脚本，用同一个代理连续请求二三十次，统计成功率和平均耗时：
import requests, time
ok, total, cost = 0, 30, []
proxies = {"http": "http://用户名:密码@代理地址:端口"}
for i in range(total):
try:
t0 = time.time()
requests.get("http://ip.example-check.com",
proxies=proxies, timeout=8)
ok += 1
cost.append(time.time() - t0)
except Exception:
pass
print(f"成功率 {ok/total:.0%}，平均耗时 {sum(cost)/len(cost):.2f}s")成功率低于九成就要留个心眼；平均耗时比直连高出太多，也会拖慢整体任务进度。
二是查匿名程度。代理分三档：透明代理会让目标端看到你的真实IP，等于白换；匿名代理知道你用了代理但看不到真实IP；高匿代理则完全看不出中间多了层转发。验证方法是把请求发到一个能回显请求头的接口，检查返回内容里有没有你本机的真实IP。做公开数据采集这类对稳定性要求高的活儿，尽量用高匿资源，请求头也保持干净统一。
把三步整理成一张表，检测时逐项打勾就行：
| 检测项 | 操作方法 | 合格标准 |
|---|---|---|
| 出口IP变更 | 挂代理前后各查一次IP | IP变化且归属地与节点一致 |
| 流量走向 | 查环境变量、核对后台用量 | 后台记录与本地请求量吻合 |
| 连接稳定性 | 连续请求30次统计成功率 | 成功率90%以上、延迟平稳 |
| 匿名程度 | 回显请求头查真实IP | 返回中不含本机真实IP |
上线前的五步检查清单
最后把整套流程压缩成五条，新代理拿到手按顺序过一遍，两分钟出结论：
1. 不挂代理先查一次本机IP，留作对照；
2. 挂上代理再查一次，确认IP和地区都换了；
3. 程序内显式指定代理，跑通一个最小请求；
4. 连续请求二三十次，成功率和延迟达标再上业务；
5. 上线后头一小时盯着服务商后台的监控曲线，发现异常及时获取新的IP。
这五步里最省心的是第5步。如果服务商后台能直接看到实时监控和异常提醒，你甚至不用自己搭检测脚本。像神龙HTTP的个人中心就带可视化用量统计与实时监控，能直接识别异常请求、看清使用趋势，配合99.9%的可用率，多数代理拿到手验证一次就能通过。代理这件事，验证做在前面，业务才能跑得踏实。
常见问题
Q: 挂了代理后IP没变化，先查哪里？
按顺序排查三处：代理地址和端口有没有填错、账号密码或授权方式是否正确、程序是否真的读取了代理配置。命令行下先看环境变量是否为空，浏览器下确认代理设置是不是只对某一个浏览器生效。都正常但还是直连的话，把代理信息填进 curl -x 里单独测一次，能通就说明问题出在程序配置上。
Q: IP确实变了，目标网站还是能识别出我的真实信息，为什么？
大概率是用到了透明代理，或者请求头里带了本机特征。先用回显请求头的方式确认有没有泄露真实IP，再检查程序里有没有自定义请求头把原始信息带了出去。换成高匿代理并保持请求头干净统一，识别问题基本就解决了。
Q: 代理时好时坏，一会儿能用一会儿超时，正常吗？
短效动态IP本身有生命周期，到期失效属于正常现象，重新提取新的IP就行。但如果刚提取就频繁超时，要看是不是并发超出了套餐限制，或者本地网络到代理节点的链路不稳。可以在后台监控里对比失败请求的时间分布，集中在某个时段多半是节点问题，及时联系服务商调整。
Q: 能不能让程序自动验证代理，不合格的自动剔除？
可以，思路就是把第三步的测试脚本封装成函数：提取一批IP后先逐个发测试请求，成功率达标的才放进业务池，跑挂的自动剔除并补充新资源。再配合带实时监控的服务商后台，异常IP能更快被发现，整个采集任务的连续性会好很多。
