去年有个做价格监测的朋友找我，说他那个跑了三个月的采集任务突然开始报错，日志里全是 403 和超时。他第一反应是"对方网站又加严了"，折腾了两天才发现，是当时图便宜买的那批"固定IP"里，有三成其实每天都在悄悄换。程序里写死的白名单、会话校验、地域参数，全跟实际出口对不上了。
固定代理IP池这东西，买之前看不出来，用起来才发现。所以接入长期项目之前，有几项验证是省不掉的。下面这四项，是我这几年踩坑踩出来的顺序，照着做一遍，大概率能把问题提前暴露在测试阶段，而不是业务跑起来之后。
一、先把"固定"两个字拆开：它到底固定的是什么
很多人以为固定就是"IP地址不变"，其实对长期项目来说，是三件事同时不变：出口 IP 地址不变、IP 的归属地信息和运营商信息不变、这条链路的可用性不能忽高忽低。前两个决定你的程序逻辑能不能跑通，第三个决定你的项目能不能长期跑下去。
为什么强调归属信息？因为不少项目会把城市维度写进业务参数里，比如做本地生活类公开数据采集，你要的是某个城市的页面内容。如果 IP 显示在A城，实际出口落地却在B城，接口不报错，但拿回来的数据全是错的，这种问题最难查。
所以在选固定代理IP池时，别只问"是不是固定的"，要问清楚是长效静态IP还是短效动态，能不能做到城市级定位。神龙HTTP 这边固定IP代理属于长效静态这一类，300+ 城市级精准定位，归属信息是能对得上的，这点在接入前值得你亲手核一遍。
二、第一项验证：连续观测，看出口IP到底跳不跳
别信一次测速截图。正确做法是写个小脚本，隔一段时间请求一次回显接口，把每次的出口 IP、状态码、耗时都记下来。
下面的脚本可以直接改改就用，每 5 分钟跑一次，一天下来 288 条记录，足够看出问题：
import requests, time, json
from datetime import datetime
PROXY = "http://用户名:密码@固定IP:端口"
CHECK_URL = "https://你的回显接口/ip" # 返回 {"origin": "x.x.x.x"} 的接口
def one_check():
t0 = time.time()
try:
r = requests.get(CHECK_URL, proxies={"http": PROXY, "https": PROXY}, timeout=10)
return {"ts": datetime.now().strftime("%m-%d %H:%M"), "code": r.status_code,
"ms": round((time.time() - t0) * 1000),
"exit_ip": r.json().get("origin")}
except Exception as e:
return {"ts": datetime.now().strftime("%m-%d %H:%M"), "code": "ERR",
"ms": -1, "exit_ip": str(e)[:40]}
rows = []
for i in range(288): # 5 分钟一次，跑满 24 小时
rows.append(one_check())
time.sleep(300)
ok = [x for x in rows if x["code"] == 200]
ips = sorted({x["exit_ip"] for x in ok})
print("成功率:", round(len(ok) / len(rows) * 100, 2), "%")
print("不同出口IP数:", len(ips), ips)
json.dump(rows, open("check_log.json", "w", encoding="utf-8"), ensure_ascii=False)
看结果的时候盯三个数：不同出口 IP 的数量、失败记录集中在什么时段、耗时的波动范围。如果一天里出现两个以上的出口 IP，那这个"固定"就要打问号了，直接去问服务商是链路调度还是资源本身就没锁死。
如果失败集中在凌晨某个固定时段，也别急着退款，先看看是不是你自己的检测频率太高触发了对端限制。把检测间隔拉长到 10 分钟再跑一轮，对比一下就能分清是谁的问题。
三、第二项验证：可用率和并发，把压力提前搬到上线前
连续观测解决的是"稳不稳"，并发压测解决的是"扛不扛得住"。项目上线第一周往往是访问量最高的时候，等那时候才发现代理池撑不住，收拾起来就很被动。
压测不需要多复杂，找一个你业务里最典型的请求，按你能预估的峰值并发往上加。比如平时 50 并发，那就从 50 起，按 100、200、500 往上试，每个档位跑 10 分钟，记录成功率、平均耗时和超时率。
我的经验线是这样：峰值并发下成功率低于 98%，就要重新评估这个池子；平均耗时比单条测试时涨了三倍以上，说明链路已经吃满，扩容空间不大。神龙HTTP 标称的可用率是 99.9%、IP 纯度 99.8%，这类数字适合作为对照参考，但真正做决策的依据还是你自己压出来的那份表。
四、第三项验证：定位与归属，别让数据"看着对其实错"
这一项最容易被跳过，但也最容易出事故。核验方法很土：在业务里加一段校验，把每次请求返回的地区信息和你在代理配置里设定的城市做比对，不匹配就记一条日志。
跑一天，统计不匹配的比例。正常情况下应该是 0。如果有一两个百分点对不上，就要问清楚是定位精度问题还是资源池里的 IP 归属登记不准确。做市场研究和公开数据采集的项目，这个偏差会直接污染分析结果，比报错更麻烦。
顺带说一句，核验的时候把运营商归属也看一眼。国内三大运营商正规授权的资源和来路不明的资源，在归属信息上经常能看出区别——前者登记信息齐全、能对上号，后者常常是模糊的。
五、第四项验证：授权来源和接入透明度
固定IP要用很久，来源不清楚的池子，中途出问题的概率高得多。接入前把这几件事问明白：资源是不是正规授权来的、支持哪些协议（HTTP / HTTPS / SOCKS5 至少要覆盖你用的那种）、有没有资质说明、出问题找谁。
另外一块常被忽略的是"看得见"。长期项目一定要有能查用量和状态的地方，不然你连自己用了多少、什么时候异常都不知道。神龙HTTP 的个人中心里有可视化用量统计和实时监控，能识别异常请求、看使用趋势，这对跑长周期的项目挺关键——出问题的时候，你能在两分钟内判断是代理侧的问题还是自己代码的问题，而不是靠猜。
接入方式上，API 兼容主流爬虫编程语言，官方有文档和示例代码，一般半小时能跑通第一个请求。技术团队是 7×24 小时支持，凌晨出问题也有人接，这点做过线上项目的人都懂它的价值。
六、四项验证对照表，直接抄
| 验证项 | 怎么测 | 建议周期 | 通过线 |
|---|---|---|---|
| IP 是否真固定 | 脚本定时请求回显接口，记录出口 IP | 连续 24 小时，每 5 分钟一次 | 出口 IP 数量为 1，无跳变 |
| 可用率与并发 | 按预估峰值分档加压，记录成功率与耗时 | 3～4 个档位，每档 10 分钟 | 峰值并发成功率 ≥ 98% |
| 定位与归属 | 业务内比对返回地区与配置城市 | 跑满 1 天 | 不匹配比例接近 0 |
| 授权与透明度 | 查资质说明、协议支持、用量统计入口 | 接入前一次性确认 | 信息可查、异常可定位 |
四项做完，基本会得出一个挺清晰的结论：能用的、勉强能用的、别碰的。别嫌麻烦，一轮测试加起来也就两三天，比上线后回滚重来便宜太多。
常见问题
Q：固定代理IP池和短效动态IP，长期项目一定要选固定的吗？
不一定，看你的业务对会话连续性的要求。需要登录态保持、白名单校验、长连接的项目，固定IP更省事；只是做公开数据采集、单次请求独立的场景，短效动态IP成本更低。很多团队的做法是两种都接，主力用固定IP，补充用短效，按需分配。
Q：验证要跑多久才算够？
最少 24 小时，能跑到 72 小时更好。因为很多链路问题是有时间规律的，比如整点调度、凌晨维护。如果你的项目对稳定性要求很高，建议在正式上线前用真实业务脚本再跑三天，用真实请求压，比用测试接口更能暴露问题。
Q：出口IP偶尔变一次，算不算不合格？
要看变化的原因。如果是服务商提前通知的资源维护，且给你换的IP归属地和之前一致，通常可以接受；如果是无通知的频繁跳变，那说明资源本身没有锁死，长期项目用下去风险很大。建议把"IP变化是否有提前通知"写进你的评估标准里。
Q：一个固定IP能撑多大的并发？
没有统一答案，取决于对端站点的限制和你请求的重量。稳妥的做法是先小并发试，观察耗时曲线，找到耗时开始明显上扬的那个拐点，把它当作该IP的舒适区间。超过这个点就增加IP数量或者换个地区的IP做分流，不要硬顶。
