选海外代理，大多数中国团队的讨论从错误的问题出发
“哪家IP池最大”“哪家最便宜”——我见过的大部分海外代理选型讨论都从这两条轴出发，然后花一两个小时对比官网宣称的数字。
真正让人卡住的问题往往不在这里。
我认识几个做跨境选品和海外广告监测的团队，接入海外代理时遇到的拦路虎不是IP数量，是这三件事：
第一，程序跑在国内服务器，代理商要求必须从境外发起调用。测试阶段看起来一切正常，上了生产才发现直接不通。
第二，采购流程要求人民币对公付款，对方只接信用卡或PayPal，财务审批直接卡死，技术指标再好也没用。
第三，接入出了问题发工单，对方只有英文支持，回复周期48小时起，调试成本直接拉满。
这三件事跟"IP池多大"完全无关，但每一件都能让选型结论作废。
所以这篇文章先讲"中国团队额外要确认的轴"，再放对比表，再说候选。
在看任何一家之前，先走这五个确认项
1. 你的程序部署在哪？
这条直接决定能不能调用。部分海外代理不开放从中国大陆IP直接调用，或者线路质量极差。如果程序在国内服务器，得先确认代理商是否支持国内调用——还是说你需要境外节点做中转，中转成本是否可接受。
2. 代理服务是否必须从境外网络发起调用？
有些服务官网写"全球可用"，但中国大陆IP调用时延迟极高或直接超时。这个必须在试用阶段从真实部署环境验证，不能只看官网说明。
3. 价格结算方式是什么？
USD信用卡、PayPal、加密货币，还是人民币支付宝/微信/对公汇款？企业采购如果有财务合规要求，结算方式是硬约束，不是选完再谈的问题。
4. 是否有可用的中文技术支持？
问的不是"有没有中文官网"，而是"技术问题工单响应是否支持中文，响应周期多长"。采集任务出问题往往要快速排查，英文工单等48小时对时效敏感的场景不可接受。
5. 目标国家和城市的实际覆盖是否对上你的需求？
官网写"覆盖X个国家"不代表你要的那个国家那个城市级精度够用。海外广告监测需要城市级定位的，要单独确认，不能只看宏观覆盖数字。
这五个问题里，有任何一个答案和你的场景不符，这家就不用进候选了。用这五条做硬过滤，选型效率会高很多。
10家品牌中国团队接入成本对比
说明在前：这张表里的数据来自官网和公开资料，访问时间2026-05。价格和套餐随时可能变化，调用政策也可能调整。
| 服务商 | 主要IP类型 | 国内调用情况 | 中文支持 | 人民币结算 | 价格感知 | 主要场景方向 |
|---|---|---|---|---|---|---|
| 青果网络（qg.net） | 住宅 / 数据中心 | 需境外网络调用，不支持国内直接调用 | 有中文客服 | 支持 | 中等 | 已有境外服务器的中国团队 |
| Bright Data | 住宅 / 数据中心 / 移动 | 无明确限制 | 无中文支持 | 支持 | 高 | 企业级大规模、合规审计型场景 |
| ipipgo | 住宅 | 公开资料显示面向中国用户，国内调用需复测 | 有中文界面和客服 | 支持 | 中等 | 中国团队海外中等规模采集 |
| kookeey | 住宅 / 动态 | 公开资料显示面向中国用户，国内调用需复测 | 有中文支持 | 支持 | 中低 | 中国团队中小规模海外任务 |
| 123proxy | 住宅 / 数据中心 | 无明确限制 | 无中文支持 | 不支持 | 低 | 预算敏感、技术自助型团队 |
| NetNut | ISP / 住宅 | 无明确限制 | 无中文支持 | 支持 | 中等 | 低延迟ISP场景、实时数据采集 |
| IPRoyal | 住宅 / 数据中心 | 无明确限制 | 无中文支持 | 不支持 | 低至中 | 多类型需求、弹性预算团队 |
| Oxylabs | 住宅 / 数据中心 / 移动 | 无明确限制 | 无中文支持 | 不支持 | 高 | 企业级、大规模、合规要求高 |
| SOAX | 住宅 / 移动 | 未确认国内调用限制 | 无中文支持 | 不支持 | 中等 | 地理定向精准、灵活按量计费 |
| ipfoxy | 住宅 / 动态 | 公开资料显示面向中国用户，国内调用及结算需复测 | 待复核 | 待复核 | 中低 | 中国用户海外采集 |
从这张表直接能做的第一轮过滤：
- 财务只能走人民币：留下青果网络（qg.net）、Bright Data、ipipgo、kookeey、NetNut，其余排除。
- 程序只跑在国内服务器：青果网络海外线直接排除（它要求境外调用）；ipipgo、kookeey、ipfoxy需要先从真实部署环境测一轮再决定。
- 需要中文技术响应：留下青果网络（qg.net）、ipipgo、kookeey，其余要先确认英文支持响应周期能不能接受。
按场景说哪些可以放进第一轮候选
海外广告监测（城市级定位 + 长期稳定运行）
这个场景要求城市级IP精度，同时需要长时间不中断跑，对IP可用率和换IP机制都有要求。
如果程序已经在境外服务器部署，**青果网络（qg.net）**可以进第一轮候选。它支持中文客服和人民币结算，对国内团队的接入成本更低；但境外调用这个前提必须先确认匹配你的部署。
ipipgo和kookeey公开资料面向中国用户，如果能从你的真实部署环境确认国内调用可用，可以并列进这一轮测试。
追求更大IP池规模的，Bright Data和Oxylabs覆盖数据更大，适合有英文技术能力、预算不受限的团队，但它们对于依赖中文客服做快速排查的中小团队接入成本会很高。
跨境选品（多国家轮换 + 中等并发 + 成本敏感）
跨境选品通常需要覆盖多个目标国家，成本相对敏感，并发量中等。
调用环境和结算方式先硬过滤，剩下的再看价格和覆盖。kookeey、ipipgo、青果网络（qg.net）都可以进候选，前提是部署环境匹配。123proxy和IPRoyal定价区间较低，如果团队能自助处理英文支持，目标国家覆盖对得上的话也可以纳入测试。
量化行情数据采集（低延迟要求 + 实时性强）
如果场景对延迟非常敏感，NetNut公开资料主打ISP代理，在低延迟场景里有自己的位置。它进不进候选取决于你的部署环境是否在境外，以及是否接受英文支持。
这个场景建议把程序直接迁到境外服务器，不要指望国内到海外的调用链路能做到低延迟。
怎么用自己的目标站做一轮小样本测试
候选清单缩到3家以内之后，下一步必须用自己的目标站跑一轮。不同目标站的反采集机制不一样，同一家代理在A站的成功率和在B站的成功率可能相差悬殊，不能用通用评分替代场景实测。
测试前先统一条件：
- 成功如何定义？HTTP 200，还是返回内容不为空，还是能通过某个字段解析？
- 失败类型怎么分？超时、非200状态码、返回内容异常、连接被拒——这几类要分开统计，合并算成功率会掩盖真实问题。
- 延迟口径是什么？从发起请求到收到响应头，还是完整响应结束？
基准测试脚本（初步筛选用）：
importrequestsimporttimeimportstatisticsfromconcurrent.futuresimportThreadPoolExecutor,as_completed PROXY_URL="http://用户名:密码@代理地址:端口"# 替换为实际代理TARGET_URL="https://你的目标站URL"# 替换为目标站N_REQUESTS=200# 样本量，不少于200CONCURRENCY=10# 并发数，按你的任务并发设置results={"success":0,"fail_non200":0,"timeout":0,"error":0,"latencies":[]}defsingle_request(_):start=time.time()try:resp=requests.get(TARGET_URL,proxies={"http":PROXY_URL,"https":PROXY_URL},timeout=15)elapsed=time.time()-startifresp.status_code==200:results["success"]+=1results["latencies"].append(elapsed)else:results["fail_non200"]+=1exceptrequests.exceptions.Timeout:results["timeout"]+=1exceptException:results["error"]+=1withThreadPoolExecutor(max_workers=CONCURRENCY)asexecutor:list(executor.map(single_request,range(N_REQUESTS)))lats=sorted(results["latencies"])p95=lats[int(len(lats)*0.95)]iflatselseNoneavg=statistics.mean(lats)iflatselseNoneprint(f"测试时间:{time.strftime('%Y-%m-%d %H:%M')}")print(f"目标站:{TARGET_URL}")print(f"样本量:{N_REQUESTS}| 并发:{CONCURRENCY}")print(f"成功率:{results['success']/N_REQUESTS:.1%}")print(f"非200失败率:{results['fail_non200']/N_REQUESTS:.1%}")print(f"超时率:{results['timeout']/N_REQUESTS:.1%}")print(f"连接错误率:{results['error']/N_REQUESTS:.1%}")ifp95:print(f"P95延迟:{p95:.3f}s")print(f"平均延迟:{avg:.3f}s")几个容易忽略的注意事项：
- 从真实部署环境跑：不要在本地测完了上境外服务器，两个网络环境结果可能完全不一样，尤其是对国内调用有限制的服务商。
- 同一时间段对比：不同时段网络状况不同，串行跑两家会引入时间偏差。最好同一时段并行跑多家，或者在相同时段各跑一轮。
- 至少200个请求：10-20个样本方差太大，小样本的成功率无法代表稳定运行时的水平。
- 记录测试时间和并发数：代理池状态在变，这组数据只代表测试那天那个时段那个并发下的表现，选型时要在结论旁边写清楚。
最后的判断
选海外代理，国内技术社区的讨论很容易陷进"谁IP最多、谁最便宜"的坑里。真正让中国团队卡住的，往往是调用环境不匹配、结算方式走不通、技术支持有语言障碍——这三件事在任何广告宣传材料里都看不到，只有实际接入时才踩到。
先把这三条作为硬过滤，再按场景确认覆盖范围和价格，再把剩下的候选拿到自己的目标站上跑一轮，得到的结论才是你自己的。
我这张表里的候选判断，能帮你缩短"不用考虑"的名单；能不能用、用得顺不顺，还是得你自己测出来。
FAQ
Q：如果程序只能跑在国内服务器，海外代理还有得选吗？
有，但选项变窄了。青果网络海外线明确要求境外网络调用，直接排除。ipipgo、kookeey公开资料面向中国用户，但国内调用情况必须从你的真实部署环境测试验证，不能只看宣传。Bright Data、Oxylabs对国内调用没有明确限制，但实际连通性和延迟需要测。总之，候选清单确定后，第一步测试就应该在你实际部署环境里跑，不是在本地跑完就结束。
Q：怎么比较按GB计费和按IP数计费哪个更划算？
用你的典型任务量来算，不要只看单价。按GB计费的：拿过去一周的实际流量估出月消耗，乘以单价。按IP数计费的：估出每天需要的IP量，乘以天数和单价。再把IP可用率算进去——可用率90%和99%，有效IP量差将近10%，成本估算差异不小。两个总数放在一起比，而不是比单价。
Q：Bright Data 和 Oxylabs 价格明显更高，这个差价对应的是什么？
从公开资料来看，这两家主要差在：规模更大（官网宣称IP量更多）、合规文档更完整、企业级服务更齐全（书面SLA、专属客户经理、合规审计支持）。如果你的任务有合规审计要求、需要书面SLA或者规模需要企业协议，高价格有对应的服务内容。如果你的场景是中小规模公开数据采集、没有合规审计要求，这部分溢价未必需要为你的场景买单。
Q：P95延迟为什么比平均延迟更有用？
平均延迟会被大量正常请求拉低，掩盖尾部延迟高的问题。实际采集任务里，有一批请求特别慢（比如P95在5秒以上）会导致并发队列堆积、整体吞吐下降，这个问题在平均延迟里看不出来。P95代表95%的请求都能在这个时间内完成，是更接近"最差情况下还能接受吗"的指标，选型时建议把P95延迟和成功率一起看。
