先搞清楚：为什么"全国覆盖"这句话没有参考价值
很多服务商在介绍节点时，喜欢写一句"覆盖全国200+城市"。听起来很唬人，但真正跑起业务来你会发现：同样是"覆盖"，有的服务商在你的目标城市只有几十个IP，两小时就用完了；有的服务商能稳定给你几百个可用IP，跑一周都不重复。
代理IP的节点覆盖，本质上要回答三个问题：
第一，有没有——你的目标城市在不在它的节点列表里；
第二，有多少——这个城市里真正能用的IP有多少个，不是总量，是可用量；
第三，稳不稳——这些IP的延迟是多少，掉线率多高，高峰期会不会集体抽风。
只看第一条，等于只看了广告文案。真正要做评估，必须下沉到城市级节点和延迟分布这两个维度。
第一层：城市级节点覆盖，从四个角度拆开看
"城市级"是代理IP行业里一个很关键的概念。它意味着你不仅能选"华东""华南"这种大区，还能精确指定到具体城市提取IP。对于本地生活服务比价、区域门店数据核对、本地搜索结果验证这类业务，大区级定位根本不够用，必须精确到市。
评估一个服务商的城市级覆盖，建议按下面四个维度逐条打分：
1. 覆盖城市数要看"可提城市"而不是宣传城市
直接问客服要一份可提取城市清单，然后拿你自己的目标城市去试提。很多服务商宣传100个城市，实际能稳定提取的可能只有四五十个。测试方法很简单：连续三天，每天固定时间提取一次，看目标城市是否每次都能出IP。
2. 单城IP池要看可用率
一个城市有1万个IP，但可用率只有30%，实际能用的只有3000个，还不如一个5000IP、可用率90%的城市。评估时要算的是单城有效IP量 = 池子总量 × 可用率。
3. 三网覆盖要分开测
移动、联通、电信的线路在同一个城市里的表现差别很大。有些服务商的某城市节点其实只有电信线路，你拿去做移动端业务测试就会失真。评估时要分别指定运营商线路提取，逐个验证。
4. 节点可用率要连续取样
单次测试碰到的可能是最好的一批IP。建议连续7天，每天在早中晚各测一次，统计每个城市的提取成功率和请求成功率，这样得出的覆盖结论才站得住脚。
第二层：延迟分布，比平均延迟重要十倍
说到延迟，最常见的错误是看"平均延迟50ms"这种数字。平均值会骗人——如果一个城市的IP里，80%是30ms，20%是400ms，平均值算下来是104ms，看起来还行；但实际跑到那20%的时候，你的请求就直接超时了。
所以评估延迟，一定要看分布，而不是一个孤零零的平均数。
看P95和P99，而不是平均值
P95延迟的意思是：95%的请求都快于这个值。业务体验由尾部决定，P95和P99才是你真正要关心的数字。一个节点平均40ms、P95是350ms，另一个平均60ms、P95是120ms，后者才是更稳的选择。
按城市分别统计
全国平均延迟没有意义。你在广州跑业务，就要看广州节点的延迟；在上海跑业务，就看上海节点的延迟。把每个城市单独拉一列数据，才能知道哪个城市的节点真的能用。
跨运营商单独测
你的服务器在电信机房，调用的却是移动的代理IP，中间要绕一次互联互通，延迟天然会高一截。评估时要按"本网"和"跨网"分开统计，不要混在一起算平均。
分时段复测
晚上8点到11点是网络高峰，延迟普遍上浮。如果只在上午测试，得到的延迟数据会明显偏乐观。建议在业务真实运行的时段测一遍。
动手实测：三步跑出你的节点覆盖与延迟分布
下面这段代码可以作为评估脚本的骨架。核心思路是：按城市批量提取IP，对每个IP发起一次真实请求，记录耗时、成功与否，最后按城市统计P95和失败率。
import time
import requests
# 提取链接从天启HTTP后台生成，把地区参数替换成目标城市即可
EXTRACT_URL = "你的API提取链接&area=目标城市代码&num={n}"
TARGET = "http://你的目标站点" # 用真实业务页面测试更有意义
def fetch_ips(n=30):
"""按城市批量提取IP，返回 ip:port 列表"""
resp = requests.get(EXTRACT_URL.format(n=n), timeout=10)
return [line.strip() for line in resp.text.splitlines() if line.strip()]
def test_one(proxy, timeout=8):
"""单次请求测试，返回毫秒数，失败返回 None"""
proxies = {"http": f"http://{proxy}", "https": f"http://{proxy}"}
t0 = time.time()
try:
requests.get(TARGET, proxies=proxies, timeout=timeout)
return round((time.time() - t0) * 1000)
except Exception:
return None
def p95(values):
"""计算95分位延迟"""
if not values:
return None
values = sorted(values)
idx = min(int(len(values) * 0.95), len(values) - 1)
return values[idx]
cities = ["目标城市A", "目标城市B", "目标城市C"]
for city in cities:
ips = fetch_ips(30)
ok, fail = [], 0
for ip in ips:
cost = test_one(ip)
if cost is None:
fail += 1
else:
ok.append(cost)
total = len(ips) or 1
print(f"{city} | 提取{total}个 | 成功{len(ok)}个 | "
f"失败率{fail/total:.0%} | 均值{sum(ok)//len(ok) if ok else '-'}ms | "
f"P95 {p95(ok)}ms")跑完之后，你会得到一张按城市排列的表。真正有价值的判断，就在这张表里：失败率超过20%的城市，说明节点池质量不过关；P95超过均值3倍的城市，说明尾部延迟有问题，业务跑起来会卡顿。
一份对照表：看得懂覆盖，才选得对节点
把上面的方法落到纸面上，评估时可以对照下面这张表逐项打分：
| 评估维度 | 常见宣传说法 | 实际该看的数据 | 参考标准 |
|---|---|---|---|
| 城市级定位 | 覆盖全国多个城市 | 可提城市清单 + 实测出IP率 | 目标城市连续3天可提 |
| IP池规模 | 全国IP总量 | 单城有效IP量 = 总量 × 可用率 | 可用率 ≥ 85% |
| 运营商覆盖 | 三网全覆盖 | 移动/联通/电信分别实测 | 目标线路可单独指定 |
| 延迟水平 | 平均延迟 50ms | P95 / P99 延迟 | P95 与均值差距不超过 3 倍 |
| 稳定性 | 超高可用率 | 连续7天请求成功率 | 请求成功 ≥ 95% |
选节点时，天启HTTP能提供什么
如果你不想从零搭测试环境，可以直接用天启HTTP来做城市级节点评估。它是国内的代理IP服务商，产品线覆盖动态短效、长效静态、独享代理等几类，比较适合做节点覆盖与延迟分布的实测：
城市级定位提取——提取接口支持按地区、城市筛选，你可以把同一个业务脚本的城市参数换掉，就能快速对比不同城市的节点表现，不用为每个城市单独买一套。
三网线路可区分——移动、联通、电信线路可以分别指定，方便你把"本网"和"跨网"的延迟分开统计，避免数据混在一起失真。
API 提取 + 协议齐全——支持 HTTP/HTTPS/SOCKS5 三种协议，API 提取可以直接嵌入上面的测试脚本，配合批量提取做多城市并行的延迟采样。
独享资源选项——对于延迟敏感的业务，独享代理可以避免和其他用户争抢同一个城市的IP资源，延迟曲线会平稳很多，P95 波动明显更小。
需要提醒的是，天启HTTP提供的是国内代理IP资源，适合国内业务的城市级测试与数据采集；如果需要境外节点，这个方向不在它的服务范围内。评估时先把业务的地域范围定清楚，再谈节点覆盖，才不会白测一场。
常见问题
Q：城市级节点和普通节点有什么本质区别？
普通节点通常只精确到大区，比如"华东""华南"，你无法指定到具体城市；城市级节点可以精确到市提取IP。做本地生活、区域比价、本地搜索结果核验这类业务时，城市级定位是刚需，大区级定位会让数据整体偏掉。
Q：平均延迟看着很好，为什么业务还是卡？
因为平均值掩盖了长尾。可能80%的请求是30ms，20%的请求到了400ms，平均下来数字不难看，但那20%的请求会直接拖垮业务体验。评估时一定要看 P95 和 P99，并且按城市、按运营商分开统计。
Q：每个城市测多少个IP才够？
建议每个城市单次至少测30到50个IP，并且连续测3到7天。样本太少容易被个别优质IP误导，单次测试也容易碰上服务商刚补充的资源。天数拉长之后，覆盖率和延迟分布才接近真实水平。
Q：失败率多少算合格？
一般业务场景下，请求成功率在95%以上比较理想；如果某个城市的失败率长期超过20%，说明这个城市的节点池质量或者线路存在问题，建议换城市节点或改用独享资源再测一轮。
Q：评估完发现某个城市不好用，怎么办？
先确认是定位精度问题还是线路问题。可以试着换成同城不同运营商的线路复测一次，如果依然不理想，就说明该城市的节点池偏小。这种情况更适合把该城市的任务拆到相邻城市节点，或者直接改用独享代理保证稳定性。
