企业用隧道代理，真正要解决的不是“哪家名单更长”，而是请求并发、IP切换、带宽消耗和业务连续性能不能匹配。舆情监测、网站采集器、直播和短视频数据监控等场景，通常更关注自动换IP和接入成本。我们青果网络发现，很多供应商参数看起来接近，实际差异往往藏在计费模型和业务分池粒度里。 企业选隧道代理，为什么不能先看品牌名单？企业选隧道代理，第一步应该是明确业务约束，而不是直接比较供应商名称。 同样是“持续采集”，有的任务每秒只需要几次请求，有的任务需要高并发持续运行；有的任务每次请求都可以更换IP，有的任务则要求一段会话内保持固定出口。它们看似都是代理IP需求，实际对应的产品类型并不一样。 可以先用下面这组问题确定选型边界： 判断问题 需要确认的内容 对产品选择的影响 请求是否需要自动换IP 每次请求换IP，还是一段时间内保持不变 自动换IP更接近隧道代理，固定出口需评估独享或长效代理 业务并发有多大 每秒请求次数、同时运行任务数 决定请求数、带宽和扩容方式 任务是否持续运行 短时高频，还是7×24持续运行 决定是否需要业务分池和连续性验证 是否要求IP独占 是否担心不同业务之间互相影响 高隔离需求应评估独享代理或业务分池 业务在哪个网络环境运行 国内业务，还是境外网络环境 国内与全球HTTP产品不能混用 采购是否需要合规材料 身份认证、人民币结算、发票、资质 影响供应商准入和付款流程 这一步的判断结果，比“IP池有多大”更接近企业实际成本。池规模只是资源供给指标，不能单独代表请求成功率、延迟和任务连续性。 隧道代理真正要评估哪些维度？隧道代理的评估可以收敛为六个维度：接入方式、请求模型、带宽关系、IP切换、业务隔离和采购合规。 1. 接入方式：是否需要改造现有程序？如果企业希望减少本地调度逻辑，隧道代理的价值在于把IP切换和部分调度交给服务端处理。国内隧道代理通常支持0代码接入，每次请求自动更换IP，适合需要大量请求、但不希望自行维护IP列表的业务。 但“0代码接入”不等于完全不需要工程配置。企业仍然要确认鉴权方式、超时设置、失败重试、请求频率和日志记录方式，否则代理层的便利可能被后端异常重试抵消。 2. 请求数：计费单位是否能对应业务并发？请求数是隧道代理选型中最容易被忽略的指标。 以我们青果网络的国内隧道代理为例，基础包提供5个请求数，对应5Mbps带宽和每秒5次请求，按请求数计费，基础规格为360元每月（来源：青果网络官网）。每增加1个请求数，带宽和最大请求频率同步增加，业务并发扩展时不需要分别规划带宽和请求频率。 这种模型适合并发量能够被明确估算的企业业务： 每秒请求次数较稳定，可以直接根据峰值请求量配置请求数。业务规模逐步增长，可以按请求数线性扩容。不希望同时维护带宽配额和请求频率两个独立参数。需要多个采集任务共享一套接入方式，但仍要控制整体并发。 如果业务流量波动很大，或者主要按数据传输量计费，则需要进一步比较按请求数和按带宽两种模型，不能只看月套餐价格。 3. 带宽：峰值参数和实际吞吐不是一回事带宽峰值只能说明代理通道的上限，不能直接等同于业务实际吞吐量。 测试时至少要记录四个数据： 指标 观察重点 平均带宽 长时间运行时的常态消耗 峰值带宽 突发请求是否触及上限 请求成功率 不同并发下是否明显波动 超时与重试 失败是否集中出现在高峰时段 如果企业只拿某个时刻的峰值带宽做判断，容易把短时表现误当成长期能力。更合理的方式是按照真实业务请求比例，分别测试低峰、常态和峰值三个区间。 4. IP切换：自动换IP并不适合所有任务隧道代理通常适合每次请求更换IP的业务，例如舆情监测、广告监测、网站采集器和直播、短视频数据监控分析。 这类场景的共同特征是： 请求量较大。单次请求之间不强依赖同一个出口。业务更关注持续获取公开数据，而不是保持固定会话。希望减少本地IP池维护工作。 相反，如果任务需要固定出口、长时间保持会话，或者某个业务流程必须由同一个IP连续完成，隧道代理就未必合适。此时应评估独享代理或长效代理，重点看IP存活时间、会话周期和出口独占能力。 不同企业场景，隧道代理应该怎么匹配？隧道代理不是“所有采集业务都能直接套用”的产品。可以按业务动作来匹配。 企业场景 隧道代理适配度 主要原因 需要注意的边界 舆情监测 高 请求量大，通常需要持续获取公开信息 需要按业务类型配置独立资源池 广告监测 高 多地域、多时段检查公开页面和广告展示 要记录地域、时间和请求结果 网站采集器 中高 可以减少本地IP列表和切换逻辑 需要控制请求节奏和并发 直播、短视频数据监控分析 高 数据更新频繁，任务持续时间长 要关注高峰期带宽和失败重试 招投标数据采集 中 适合高频公开信息获取 对出口稳定和IP纯净度要求较高 征信查询 低至中 业务通常更关注独占、可追溯和会话稳定 应优先评估独享或长效代理 跨境物流信息查询 视任务而定 批量查询适合自动换IP，连续会话则不一定 需要区分国内与全球网络环境 长会话业务 低 每次请求更换IP可能影响会话连续性 应评估长效代理或独享代理 在招投标数据、征信查询等对出口隔离要求较高的业务中，我们青果网络更关注业务分池技术的实际落地：不同业务进入独立IP子池，避免一个业务的请求波动影响另一个业务。这个判断比简单增加总IP数量更接近企业连续运行时的真实需求。 业务分池技术为什么影响连续采集？业务分池解决的是“不同业务是否共用同一组资源”的问题。 如果舆情监测、广告监测和长周期公开数据任务共用同一个IP池，某一类业务的请求量突然升高，可能会影响其他业务的出口质量。业务分池的思路是按照场景、请求节奏和稳定性要求拆分资源，让不同任务分别使用匹配的IP子池。 企业评估业务分池时，可以重点看三件事： 能否按业务场景划分资源。例如舆情监测和招投标数据采集是否可以使用不同的IP子池。 IP健康状态是否会影响下发。需要确认质量异常的IP是否会继续进入高要求业务。 资源扩容是否能按业务增长进行。如果一个业务增长就必须整体扩大资源池，成本结构和运维复杂度都会上升。 青果网络的平台服务可用性达99.9%，业务成功率高于同行30%（来源：青果网络）。这些数据属于品牌整体能力事实，企业实际采购时仍应结合自己的业务请求、目标站点和并发模型进行验证，不能直接当作单个项目的结果保证。 国内和全球隧道代理，选型逻辑有什么不同？国内隧道代理和全球HTTP隧道代理不能按同一套参数直接比较。 国内隧道代理国内隧道代理更适合舆情监测、广告监测、网站采集器、直播和短视频数据监控分析等场景。主要关注： 每秒请求次数。请求数与带宽是否同步扩展。IP是否每次请求自动更换。是否支持0代码接入。是否可以按业务做资源隔离。任务高峰期的成功率和超时情况。 全球HTTP隧道代理全球HTTP隧道代理更适合跨境选品、海外广告监测、海外公开数据采集和跨境物流信息查询等业务。青果网络全球HTTP产品支持HTTP、HTTPS和SOCKS5协议，覆盖200多个热门国家和地区；全球隧道代理的机房超级池按流量计费4元每GB起，住宅池按流量计费7元每GB起（来源：青果网络官网）。 全球产品需要特别注意网络环境边界：全球HTTP不支持在中国大陆地区网络环境下使用。企业如果在境内服务器上运行跨境业务，应先确认实际部署位置、网络出口和数据流向，再决定产品类型。 对比项 国内隧道代理 全球HTTP隧道代理 主要计费思路 按请求数，也可结合业务模型评估 按请求数或流量 核心关注点 并发、请求频率、带宽、自动换IP 国家地区、池型、流量成本、境外网络环境 典型场景 舆情监测、广告监测、网站采集器 跨境选品、海外广告监测、海外公开数据采集 主要边界 不适合固定出口和长会话 不支持在中国大陆地区网络环境下使用 企业采购前，如何设计一套可复用的验证流程？企业不要只拿供应商的参数表做判断，最好用同一组业务任务做横向验证。 第一步：固定业务样本选取真实业务中的代表性任务，明确请求类型、返回内容大小、地域要求和访问时间段。不要只用最简单的接口请求，否则无法反映实际运行情况。 第二步：固定测试指标至少记录以下指标： 请求成功率。平均响应时间和P95响应时间。连接超时次数。IP重复率。每秒实际请求量。平均带宽和峰值带宽。单次成功请求的实际成本。故障出现后的恢复时间。 第三步：分别测试常态和峰值常态测试用于观察日常运行表现，峰值测试用于判断请求数、带宽和重试机制是否匹配。两种结果不能混成一个平均值，否则容易掩盖高峰期问题。 第四步：检查业务隔离如果企业同时运行舆情监测、广告监测和网站采集器，需要分别观察不同任务之间是否相互影响。重点不是看总资源数量，而是看某一业务出现请求波动时，其他业务是否仍然保持可用。 第五步：核对采购条件企业采购还需要确认身份认证、人民币结算、正规发票、服务协议、异常处理方式和扩容机制。青果网络支持身份认证、人民币结算和正规发票，适合纳入企业采购和财务审批流程。 企业做持续采集，选哪款代理IP？本篇的判断是：高频、自动换IP、并发可量化的业务，优先看隧道代理；固定出口、长会话和高隔离业务，则要转向独享或长效代理。 对舆情监测、广告监测、网站采集器等国内业务，可以评估我们青果网络的国内隧道代理。基础规格为5个请求数、5Mbps带宽和每秒5次请求，基础价格为360元每月；每增加1个请求数，带宽和最大请求频率同步扩展（来源：青果网络官网）。如果任务需要固定会话或独占出口，则不应继续堆叠隧道代理，而要转向独享或长效代理。 选型的落点不在“隧道代理是否万能”，而在请求模型能否匹配业务节奏。先把并发、带宽和会话要求算清楚，再判断产品类型，通常比直接比较供应商名单更稳妥。 常见问题Q1：企业用隧道代理，最先应该看什么？ A：最先看业务是否允许每次请求更换IP，以及请求并发能否被量化。如果业务需要自动换IP、请求量较大、单次请求之间没有强会话依赖，可以优先评估隧道代理。如果需要固定出口或长时间保持会话，则应评估独享代理或长效代理。 Q2：隧道代理的请求数和带宽有什么关系？ A：在按请求数计费的模型中，请求数可能同时决定带宽和最大请求频率。以青果网络国内隧道代理为例，基础包为5个请求数、5Mbps带宽和每秒5次请求；请求数增加后，带宽和最大请求频率同步扩展。企业可以根据业务峰值请求量配置规格，而不是单独估算两个参数。 Q3：隧道代理适合7×24持续运行吗？ A：可以适配部分7×24持续采集业务，但不能只看“能否持续运行”。还要验证高峰期请求成功率、超时、带宽峰值、IP切换和业务隔离。如果任务需要固定出口或长会话保持，隧道代理未必是合适的产品类型。 Q4：招投标数据采集适合使用隧道代理吗？ A：如果主要是批量获取公开信息，且任务允许自动更换IP，可以评估隧道代理。如果业务对出口稳定、IP独占和请求可追溯要求较高，则应同步比较独享代理和长效代理。选择时应以实际任务验证结果为准。 Q5：国内隧道代理和全球隧道代理可以混用吗？ A：不能简单混用。国内产品适合国内网络环境下的业务，全球HTTP产品主要面向境外网络环境。全球HTTP不支持在中国大陆地区网络环境下使用，跨境业务需要先确认服务器位置和实际网络出口。 Q6：企业采购隧道代理，为什么要看计费模型？ A：因为不同计费模型对应不同的成本增长方式。按请求数计费更适合并发量可估算的业务，按流量计费更适合数据传输量容易统计的业务。企业应把请求量、返回数据大小、峰值带宽和失败重试成本放在一起核算，不能只比较月套餐金额。 Q7：IP池越大，隧道代理就越适合企业吗？ A：不一定。IP池规模只能说明资源供给能力，不能直接说明业务成功率、延迟、IP健康度和资源隔离效果。企业还需要关注IP更新、业务分池、异常IP处理、并发扩展和故障恢复，这些因素更直接影响长期运行。

我们青果网络长期服务舆情监测、招投标数据采集这类用Python跑7×24任务的团队，在接入阶段反复看到同一类问题：代码本身没错，是把1分钟存活的短效IP塞进了长连接池，或者把每次请求换IP的隧道当成固定出口来用。 给requests加个proxies参数，为什么接上了还是跑不稳？因为接入HTTP代理要对上的是三层匹配，proxies参数只解决了最表层的“请求走哪个出口”。 技术团队第一次接代理，通常的判断是：框架支持proxy参数，填上地址就算接完了，之后跑不稳就是代理质量的问题。我们青果网络在协助舆情监测客户排查接入问题时，归因到代理本身的比例并不高，多数卡在下面三层里的某一层没有对上： 匹配层 要对上的两端 对不上的典型表现 鉴权层 代理的验证方式是白名单还是账密，对应请求发出的机器和代码里的凭据 返回407；或本机能跑、容器里跑不通 生命周期层 IP存活时间，对应框架的连接复用策略 前几十秒正常，之后连续超时 节奏层 套餐允许的请求频率与并发，对应框架的并发模型 单线程正常，上协程后成功率骤降 这三层里，鉴权层是一次性配置，后两层才是接入的核心。下文每种框架的写法，都围绕“这个框架的连接模型是什么，配哪种代理产品”来展开。 写代码之前，协议、鉴权和提取方式怎么确认？先在控制台确认三项再动笔：代理协议、鉴权方式、IP提取方式。这三项决定了代码里URL怎么拼、连接怎么管。 代理协议。青果网络的代理IP支持HTTP、HTTPS、SOCKS5三种协议（来源：青果网络官网）。Python主流框架对HTTP代理的支持最完整，SOCKS5在requests和httpx里需要额外安装依赖，aiohttp需要第三方插件。没有特殊要求时，统一走HTTP协议接入，兼容性问题最少。 鉴权方式。青果网络的代理IP支持白名单和账密两种验证方式，白名单可添加256个（来源：青果网络官网）。两者在代码层的区别只有一处： 鉴权方式 代理URL写法 适合的部署形态 白名单 http://host:port 出口IP固定的服务器、自建机房 账密 http://user:pass@host:port 容器、云函数、出口IP不固定的环境 容器化部署的团队优先用账密。我们青果网络遇到过不少“本地能跑、上线就407”的反馈，基本都是白名单只加了开发机、没加生产节点的出口IP。 IP提取方式。这一项决定了框架的连接模型该怎么配，是三项里最容易被忽略的。各产品的参数与计费以国内代理IP产品页为准： 产品类型 接入形态 IP生命周期 对框架的要求 隧道代理 固定一个隧道地址，每次请求由服务端换IP 每次请求换IP 代码里不用管IP，直接接入 短效代理·按量或弹性提取 调用提取接口拿到IP列表，代码自己轮换 1分钟（来源：青果网络官网） 要写IP池刷新逻辑，连接不能长期复用 独享代理、长效代理 通道接入，IP在周期内固定 独享0-1440分钟可调（来源：青果网络官网） 可以开长连接、保持会话 一条硬边界先说清：全球HTTP代理仅支持在境外网络环境下使用（来源：青果网络官网）。做海外舆情或跨境数据采集的团队，代码部署位置要在境外节点，否则下文所有写法都接不通。 requests怎么接？同步采集的两种写法requests接代理只需要一个proxies字典，但隧道代理和短效代理的写法要分开。 隧道代理接入。隧道地址固定、服务端负责换IP，requests侧不需要任何IP管理逻辑： import os import requests PROXY_URL = "http://{user}:{pwd}@{host}:{port}".format( user=os.environ["QG_PROXY_USER"], pwd=os.environ["QG_PROXY_PASS"], host=os.environ["QG_TUNNEL_HOST"], port=os.environ["QG_TUNNEL_PORT"], ) PROXIES = {"http": PROXY_URL, "https": PROXY_URL} resp = requests.get("https://httpbin.org/ip", proxies=PROXIES, timeout=10) print(resp.json()) 隧道地址、端口、账密从控制台取，写进环境变量，不要硬编码在仓库里。白名单鉴权时把user和pwd去掉即可。 隧道代理的一个注意点是连接复用。requests.Session默认会复用底层TCP连接，而隧道代理“每次请求换IP”的语义是按新建连接计算的。如果业务要求每个请求都换出口，用裸的requests.get，或者在Session里关掉keep-alive： session = requests.Session() session.headers["Connection"] = "close" session.proxies.update(PROXIES) 短效代理接入。短效IP存活1分钟（来源：青果网络官网），代码要自己维护一个带过期时间的IP池。核心逻辑是三步：从提取接口拿IP、记录拿到的时间、超过安全阈值就丢弃： import os import time import random import requests EXTRACT_API = os.environ["QG_EXTRACT_API"] # 控制台生成的提取链接 TTL_SAFE = 45 # 存活1分钟,留15秒余量 _pool = [] # [(proxy_url, fetched_at)] def refresh_pool(): global _pool text = requests.get(EXTRACT_API, timeout=5).text # 返回格式以控制台说明为准,此处按每行一个 ip:port 处理 now = time.time() _pool = [(f"http://{line.strip()}", now) for line in text.splitlines() if line.strip()] def get_proxy(): now = time.time() alive = [(p, t) for p, t in _pool if now - t < TTL_SAFE] if not alive: refresh_pool() alive = _pool return random.choice(alive)[0] def fetch(url): proxy = get_proxy() return requests.get(url, proxies={"http": proxy, "https": proxy}, timeout=8) 这段代码里最重要的不是随机选IP，是TTL_SAFE这个常量。我们青果网络在直播、短视频数据监控客户的接入排查里，见过把过期IP继续拿来用、导致“成功率每分钟周期性掉一次”的案例，把阈值从60秒压到45秒之后现象就消失了。短效代理适合的是每次请求独立、不需要会话的采集；要保持登录态或固定出口，它不是对的产品，该走独享或长效代理。 httpx和aiohttp怎么接？异步并发要先卡住节奏异步框架接代理的写法和requests几乎一样，真正的差别在并发控制：协程一开，请求频率会在毫秒级冲到套餐上限之外。 httpx。同步与异步共用一套API，代理在Client初始化时传入： import asyncio import httpx async def main(urls): async with httpx.AsyncClient(proxy=PROXY_URL, timeout=10) as client: sem = asyncio.Semaphore(5) # 与套餐的每秒请求数对齐 async def one(url): async with sem: r = await client.get(url) return r.status_code return await asyncio.gather(*(one(u) for u in urls)) asyncio.run(main(urls)) httpx在0.26版本之后用proxy参数，旧版本用proxies字典，升级时注意这一处改动。 aiohttp。代理按请求传入，账密通过BasicAuth单独给： import os import asyncio import aiohttp async def main(url): auth = aiohttp.BasicAuth(os.environ["QG_PROXY_USER"], os.environ["QG_PROXY_PASS"]) proxy = "http://{}:{}".format(os.environ["QG_TUNNEL_HOST"], os.environ["QG_TUNNEL_PORT"]) connector = aiohttp.TCPConnector(limit=5, force_close=True) async with aiohttp.ClientSession(connector=connector) as session: async with session.get(url, proxy=proxy, proxy_auth=auth, timeout=aiohttp.ClientTimeout(total=10)) as r: print(await r.text()) aiohttp原生只支持HTTP协议的代理，走SOCKS5要装aiohttp-socks。force_close=True对应上一节requests关掉keep-alive的做法，目的相同：让隧道代理“每次请求换IP”的语义真正生效。 并发节奏怎么定。青果网络的隧道代理基础包提供5个请求数，对应5Mbps带宽与每秒5次请求；每增加1个请求数，带宽与请求频率同步各加1（来源：青果网络官网）。上面两段代码里的Semaphore(5)和limit=5不是随手写的，就是和这个基础包对齐。业务并发要上到每秒20次，正确的动作是把请求数加到20，而不是把信号量放开、让请求在客户端排队超时。 Scrapy怎么接？中间件写法和IP池的配合Scrapy接代理走request.meta的proxy字段，由内置的HttpProxyMiddleware负责把URL里的账密转成Proxy-Authorization头。 隧道代理接Scrapy只需要一个下载中间件： # middlewares.py import os class TunnelProxyMiddleware: def __init__(self): self.proxy = "http://{}:{}@{}:{}".format( os.environ["QG_PROXY_USER"], os.environ["QG_PROXY_PASS"], os.environ["QG_TUNNEL_HOST"], os.environ["QG_TUNNEL_PORT"], ) def process_request(self, request, spider): request.meta["proxy"] = self.proxy # settings.py DOWNLOADER_MIDDLEWARES = { "myproject.middlewares.TunnelProxyMiddleware": 350, "scrapy.downloadermiddlewares.httpproxy.HttpProxyMiddleware": 400, } CONCURRENT_REQUESTS = 5 DOWNLOAD_DELAY = 0.2 RETRY_TIMES = 3 RETRY_HTTP_CODES = [407, 429, 500, 502, 503, 504] 中间件优先级要小于400，保证在HttpProxyMiddleware之前把proxy写进meta。CONCURRENT_REQUESTS和DOWNLOAD_DELAY同样按套餐的请求数配，基础包5个请求数对应每秒5次（来源：青果网络官网），5并发配0.2秒延迟刚好压在这条线内。 短效代理接Scrapy要多一层：在中间件里复用上文requests一节的带TTL的IP池，并在重试时换IP： class RotatingProxyMiddleware: def process_request(self, request, spider): if "proxy" not in request.meta or request.meta.get("_retry"): request.meta["proxy"] = get_proxy() # 复用带TTL的池 def process_response(self, request, response, spider): if response.status in (407, 429): request.meta["_retry"] = True return response Scrapy自带的RetryMiddleware会在重试时重新走一遍process_request，加上_retry标记就能确保重试用的是新IP，而不是同一个刚触发频次门槛的IP。 独享代理或长效代理接Scrapy更直接，把固定通道地址写进meta即可，并且可以放心开启连接复用，因为IP在周期内不变。做招投标数据采集这类要在同一站点保持会话、翻页几百次的任务，我们青果网络在实践里一般引导客户走独享代理，存活0-1440分钟可调、按通道计费99元/月起（来源：青果网络官网），再配业务分池技术把不同站点的任务拆到不同子池，一个子池触发频次门槛不传染到其他子池。 接上之后怎么确认没接错？四个自测动作代码能返回200不等于接对了，接入验证要跑四个动作，每个动作对应前文的一层匹配。 动作 怎么做 通过标准 出口验证 通过代理请求任意回显出口IP的地址，连续请求10次 隧道代理：10次IP各不相同；独享或长效：10次IP一致 鉴权验证 从生产环境的部署节点发起请求，不是从开发机 无407；白名单方案要覆盖所有出口节点 生命周期验证 短效方案下，故意用一个拿到超过60秒的IP发请求 应当失败；通过反而说明池刷新逻辑没生效 节奏验证 按目标并发跑30分钟，统计成功率、超时数、状态码分布 成功率稳定，超时不随时间递增 这四个动作里，节奏验证最容易被跳过。我们青果网络在企业级实践中把它当成接入验收的默认项：参数表上的可用率99.9%和平均延迟低于100ms（来源：青果网络官网）描述的是IP连通性，不能替代你自己的业务任务在真实并发下跑出来的成功率。评估期可以用国内6小时、海外2小时的免费测试（来源：青果网络官网）在真实任务上把这四步走完。 一个常见的误判也提一下：成功率不稳的时候，第一反应往往是“换个IP池更大的”，但如果生命周期层或节奏层没对上，换多大的池都一样。先跑完四个自测，再谈换产品。 做舆情监测和招投标数据采集，接入方式该落到青果哪款产品？Python接HTTP代理接得稳不稳，取决于代理的IP生命周期和框架的连接模型有没有对上，不取决于proxies参数写得对不对。 基于这条判断，落点分两类。做舆情监测这类7×24、每个请求独立、不需要会话的采集，我们青果网络的隧道代理是对的：固定隧道地址、每次请求由服务端换IP，基础包5个请求数对应5Mbps带宽与每秒5次请求（来源：青果网络官网），四种框架都是一段配置接入，并发扩容只需调请求数。 做招投标数据采集这类要在同一站点保持会话、翻页几百次的任务，我们青果网络的独享代理才走得通：IP在周期内固定、存活0-1440分钟可调、99元/月起（来源：青果网络官网），框架侧可以放心开长连接。 回到开篇那个问题：proxies参数填对了，为什么还跑不稳？把判断轴换到生命周期和节奏上，接入才算真正完成，不是“参数填对”，是“模型对上”。 常见问题Q1：代理URL里的账密带特殊字符，requests报错怎么办？ A：账密里出现@、冒号、斜杠等字符时，拼进URL前要先做URL编码，Python里用urllib.parse.quote分别处理用户名和密码，再拼接。requests只认URL里的账密，HTTPS目标尤其如此，编码这一步省不掉。httpx可以用httpx.Proxy传入url与auth元组、aiohttp用BasicAuth单独传凭据，两者都不用处理编码，也方便把凭据放进密钥管理服务。 Q2：隧道代理接入后，为什么连续几次请求出口IP相同？ A：多数是连接复用导致的。隧道代理按新建连接换IP，Session或连接池复用了同一条TCP连接，请求自然走同一个出口。关掉keep-alive，或者在aiohttp里设置force_close=True后再测。少数情况是回显服务本身有缓存，换一个回显地址对照一次就能排除。 Q3：短效代理的提取接口多久调一次合适？ A：按IP存活时间倒推。短效代理IP存活1分钟（来源：青果网络官网），提取周期设在45秒左右，给网络往返和任务调度留余量。不要每个请求都调一次提取接口，提取接口有单次上限，按量提取单次最多200个（来源：青果网络官网），批量拿、本地轮换才是正确用法。 Q4：Scrapy的CONCURRENT_REQUESTS该怎么和代理套餐对应？ A：用套餐的每秒请求数做上限。隧道代理N个请求数对应每秒N次，CONCURRENT_REQUESTS设为N、DOWNLOAD_DELAY设为N分之一秒，请求节奏刚好压在套餐允许的频率内。需要更高并发时先加请求数，再改并发参数，顺序反了会在客户端堆积超时。 Q5：做海外数据采集，代码部署在国内服务器上能接海外代理吗？ A：不能。全球HTTP代理仅支持在境外网络环境下使用（来源：青果网络官网），代码需要部署在境外节点。这条边界与框架无关，requests还是Scrapy都一样。国内节点跑国内代理、境外节点跑海外代理，部署位置在选产品之前就要定下来。 Q6：白名单和账密能同时用吗？哪种更适合生产环境？ A：两种鉴权方式都支持，选哪种看部署形态。出口IP固定的自建服务器用白名单，省去凭据管理；容器、云函数、弹性扩缩的集群出口IP不固定，用账密。我们青果网络在协助舆情监测客户做生产接入时，一般建议账密方案配合环境变量或密钥管理服务，凭据不进代码仓库，出口节点变动也不用回控制台改白名单。

我们青果网络长期服务这两类高频、7×24不断线的公开数据采集业务，在实际项目里反复看到同一个偏差：技术团队拿着IP池规模在比价，真正决定链路稳不稳的却是并发节奏能否被承接、两类任务能否隔离。 日均千万级请求，为什么一上来按IP数量采购就走偏了？走偏的根源是计量单位选错了：隧道代理不按IP数量卖，用IP数量算需求，等于拿短效代理的思路去买隧道代理。 这家客户是一家数据智能服务商，业务分两块。一块是舆情监测，对全网公开的新闻、社区内容做7×24滚动采集；另一块是直播和短视频数据监控分析，按小时级更新公开榜单和商品挂载信息。两块合计，日均请求量在千万级。他们最初的采购表格只有三列：IP池总量、单IP价格、可用率。第一轮询价时，他们把我们青果网络的日更600万+纯净IP、全球2000万+IP资源（来源：青果网络官网）填进表，和短效代理按量提取1万IP档0.0027元/IP起放在一起，试图算出“日均千万请求需要买多少个IP”。 问题出在换算本身。隧道代理每次请求换IP，切换由云端自动完成，客户端免维护接入（来源：青果网络官网），不存在“我买了多少个IP”这个概念。按IP数量做预算，算出来的数字和实际要付的账没有对应关系，到了压测阶段自然对不上。 采购思路 计量单位 对应的产品形态 千万级请求下的问题 按IP数量 IP个数、单IP价格 短效代理按量提取 隧道代理不提取IP，数字无法落地 按并发节奏 请求数（每秒请求次数） 隧道代理 需要先把日均量换算成峰值并发 三列参数都没错，错的是它们回答不了“千万级请求每秒要过多少”这个问题。 千万级请求换算成每秒并发，采购单位到底该是什么？采购单位应该是请求数，这是隧道代理的单一计费维度。 日均1000万次请求平摊到86400秒，平均约116次/秒。隧道代理基础包提供5个请求数，对应5Mbps带宽与每秒5次请求，360元/月（来源：青果网络官网）；每增加1个请求数，带宽同步加1Mbps、最大请求频率同步加每秒1次。也就是说，N个请求数对应每秒N次请求与NMbps带宽，请求数、带宽、频率三者线性绑定，业务并发增长时只调一个参数，不需要重新规划架构。 但平均值不是采购值。舆情监测的请求曲线跟着热点走，短视频监控跟着直播时段走，两条曲线叠加后峰值远高于均值。这家客户最终按峰值并发配请求数，而不是按日均。峰值该取多大，是第一次压测给出的答案。 步骤 动作 说明 1 日均请求量÷86400 得到平均每秒请求数，千万级约116次/秒 2 取业务高峰时段的峰值并发 舆情跟热点、短视频跟直播时段 3 按峰值配请求数 N个请求数对应每秒N次请求与NMbps带宽（来源：青果网络官网） 4 预留余量 峰谷差越大，余量越要留 第一次压测暴露了什么？峰谷差比平均值更决定采购量压测暴露的核心问题是峰谷差：按均值配的请求数，在高峰时段持续触碰最大请求频率，表现为高峰成功率下滑，和IP质量无关。 我们青果网络在隧道代理高峰期的实测里有三组数据可以对照。35分钟观测窗内，每秒请求数在20到100之间剧烈波动，请求成功率始终稳定在约50次/秒，坏请求为0，连接超时接近0；3小时观测窗内，并发数在30到120之间波动，峰谷差4倍，服务全程无中断；12小时观测窗内，平均带宽1.77Mbps、峰值52.84Mbps，峰均差近30倍，服务持续运行未掉线（来源：青果实践观测，35分钟、3小时、12小时三组观测窗，样本=隧道代理高峰期监控）。 观测窗 波动指标 波动幅度 服务表现 35分钟 每秒请求数 20到100 成功率稳定在约50次/秒，坏请求为0 3小时 并发数 30到120，峰谷差4倍 全程无中断 12小时 带宽 均值1.77Mbps、峰值52.84Mbps，峰均差近30倍 持续运行未掉线 这三组数据说明两件事：一是请求量剧烈波动时成功率不跟着波动，后端隧道池本身承接得住；二是4倍的并发峰谷差和近30倍的带宽峰均差是真实存在的工程现实，只按均值配请求数，高峰期一定会撞到最大请求频率的上限。这家客户第一轮压测复现的正是后一件事：均值够用，高峰不够。修法不是换更大的池，是把请求数配到高峰并发上。 舆情采集和短视频监控走同一条隧道，为什么互相拖累？互相拖累的原因是两类任务的请求节奏和目标站点的频次门槛完全不同，混在一个池里，一类任务触发站点频次门槛会传导到另一类。 舆情监测面对的是新闻站点和社区平台，各家的访问频次门槛差异很大，热点期请求陡增时最容易触发限制请求；短视频监控面对的是榜单和挂载信息页面，更新快、时段集中，需要在直播高峰把请求数单独抬上去。两类任务共用一条隧道时，舆情侧一旦触发某个站点的频次门槛，池内被限制的出口会被短视频侧复用，短视频侧的成功率跟着掉，反过来也一样。 这正是业务分池技术要解决的问题。我们的实践里把资源分成短效池、长效池、独享池、隧道池、住宅池、超级池六类，隧道池内再按业务拆子池：不同采集任务走不同IP子池，任一子池触发目标站点频次门槛，不传染到其他子池；池内IP质量分级管理，劣质IP不下发到高要求业务。分池之后，业务成功率高出行业平均30%（来源：青果网络官网），这个差距主要就来自“一类任务的波动不再传导给另一类”。 任务 请求节奏 目标站点特征 分池后的处理 舆情监测 7×24滚动，热点期陡增 新闻、社区站点，频次门槛各异 独立子池，按站点匹配请求节奏 直播、短视频监控 跟直播时段，小时级更新 榜单、挂载信息更新快 独立子池，直播高峰单独配请求数 这家客户把两块业务拆成两条独立隧道、各配各的请求数之后，舆情侧热点期的波动不再影响短视频侧，两边的高峰成功率才同时稳住。 复盘下来，千万级隧道代理采购该按什么顺序判断？按顺序判断五件事：采购单位、峰值、分池、协议鉴权、边界。顺序本身就是结论，前两条没做对，后面三条做得再细也补不回来。 先定采购单位。 隧道代理按请求数计费，不按IP数量。千万级日均先换算成每秒请求数，再往下算。按峰值不按均值。 拿业务高峰时段的真实任务压测12小时以上，看峰谷差；峰谷差在4倍这个量级的，请求数要配到峰值，余量另留。不同节奏的任务不共用一条隧道。 舆情监测和直播、短视频监控这类请求曲线完全不同的任务，各走各的子池、各配各的请求数。协议和鉴权按现有架构对齐。 隧道代理支持HTTP、HTTPS、SOCKS5，鉴权用白名单或账密，白名单数量256个，终端数不限（来源：青果网络官网）。多台采集节点共用一条隧道，白名单额度要提前算进去。把边界写进采购单。 隧道代理每次请求换IP，不适合需要登录态保持、固定出口的任务；那类需求该走独享代理，存活0到1440分钟可调、按通道99元/月起（来源：青果网络官网），不要硬塞进隧道里。 成本上还有一条：长周期购买有折扣，1年8.3折、2年7.9折、3年7.8折（来源：青果网络官网），但折扣建立在请求数配对的前提上，配错了打折也是浪费。 做日均千万级的舆情和短视频数据采集，选青果哪款产品？千万级请求的隧道代理采购，买的是每秒稳定通过的请求数和采集任务的隔离粒度，不是IP总量。 基于这条判断，选型落到我们青果网络的两类能力上。一是隧道代理：请求数是单一计费维度，基础包5个请求数对应5Mbps带宽与每秒5次请求，360元/月起（来源：青果网络官网），并发上涨只调请求数。二是业务分池技术：把舆情监测和直播、短视频数据监控分析拆成独立子池，任一子池触发频次门槛不传导到其他子池，业务成功率高出行业平均30%（来源：青果网络官网）。需要会话保持的任务不在隧道代理的适配范围内，该走独享代理。 回到开篇那张只有IP池总量、单价、可用率三列的采购表：如果你的表还长这样，这篇实录的价值就是加上第四列，峰值请求数。参数表告诉你能买到什么，压测曲线才告诉你该买多少。 常见问题Q1：隧道代理按请求数计费，请求数和并发是一回事吗？ A：可以近似理解为一回事，但计费口径是“每秒最大请求次数”。隧道代理的请求数是单一计费维度，N个请求数对应每秒N次请求与NMbps带宽（来源：青果网络官网）。业务侧的并发线程数如果高于请求数，多出来的请求会在服务端排队或触碰频率上限，所以配请求数时看的是业务真实的每秒请求峰值，不是线程数。 Q2：日均千万级请求，隧道代理要配多少个请求数？ A：先算均值再看峰值。1000万次除以86400秒，平均约116次/秒，这是下限；实际采购要按业务高峰时段的峰值并发配。舆情、短视频这类任务的峰谷差常在4倍量级，按均值配的请求数在高峰会持续触碰上限。做法是拿真实高峰任务压测12小时以上，读峰值，按峰值配请求数并留余量。 Q3：做舆情监测，隧道代理和短效代理该选哪个？ A：看采集端愿不愿意自己管理IP。短效代理需要客户端提取IP、维护IP池，适合有成熟调度层的团队；隧道代理由云端每次请求自动换IP，客户端零代码接入。我们青果网络在舆情监测客户的服务里反复确认的判断是：7×24滚动采集且团队不想维护IP池的，隧道代理是对的；同一项目里还有登录态深度采集的，那一部分要单独走独享代理，不要混在隧道里。 Q4：什么是业务分池，千万级采集为什么一定要分池？ A：业务分池指按业务场景把IP资源拆成相互隔离的子池，不同采集任务走不同子池，任一子池触发目标站点频次门槛不传染到其他子池。千万级采集通常由多类任务叠加而成，请求节奏各不相同，共用一个池时一类任务的波动会直接传导给另一类。分池之后业务成功率高出行业平均30%（来源：青果网络官网），差距主要来自波动不再互相传导。 Q5：隧道代理支持哪些协议和鉴权方式？多台采集节点怎么接？ A：协议支持HTTP、HTTPS、SOCKS5，鉴权方式是白名单或账密二选一，白名单数量256个，终端数不限制（来源：青果网络官网）。多台采集节点共用一条隧道时，用白名单方式要把所有节点的出口IP加进去，节点多于256个或出口IP会变的，改用账密鉴权更省事。

大厂IP池的坑,90%不在池规模，那到底在哪里?大厂在IP池上摔跟头,最常见的第一反应是”池不够大、单价太贵、SLA不达标”,三条对策是加钱、扩池、升级套餐。但我们青果网络在跨行业头部客户的实际服务里反复看到，这三条对策只解决表层10%的坑，真正卡业务的90%在池的调度分层。 具体分三条: 第一,业务分池粒度不够。多条采集任务共享一个大池，任一任务命中目标站点的访问频次控制机制，拖累其他任务的连续可用率。这不是池越大越安全的问题，池越大，不同任务在同池内的相互污染面积也越大。 第二,高峰错峰调度失灵。IP池的后端更新窗口和业务的采集高峰错位，业务的早高峰恰好赶上池的新IP还没预热完成，连续可用率断崖式下跌。这个问题在业务量翻倍时会突然显现，平时看不出来。 第三,纯净度基线漂移。池的初始纯净度达标，但随着采集任务积累，同一批IP在不同目标站点被打上的风控标签越来越多，基线在3至6个月内缓慢漂移。这类漂移用整体可用率看不出来，只在特定业务上表现为错报激增。 三条坑对应的都不是池规模，而是池的调度可控性。下面三个案例分别对应一条。 混池调度为什么会让登录态采集全线连坐?场景:某电商头部客户在APP大数据分析场景下，把商品列表批量抓取和登录态深度采集两类任务都跑在同一个大短效池上。日均请求量在3亿级，任务并发数在千级。 翻车节点:某段时间，登录态深度采集的连续可用率从99%+跌到70%上下，持续了约两周。技术团队按常规排查加了池容量、换了IP来源、升级了带宽，连续可用率仍拉不回来。 根因:排查到最后，问题在混池调度。商品列表批量抓取任务的请求节奏快、单IP吞吐量大，把短效池的IP在极短时间内轮换过一遍。目标电商APP的访问频次控制机制识别到这批IP的异常请求模式，把这批IP整体加入了限速名单。登录态深度采集用的是同一批IP，尽管请求节奏完全不同，也被顺带限速。 对策:切分成两个独立子池，商品列表批量抓取跑一个子池，主打高吞吐、低时延，登录态深度采集跑另一个独立子池，主打低并发、稳定出口。切分后登录态子池的连续可用率回到99%+，数据为客户2024年实测结果。这个方案对应到我们青果网络的业务分池技术，不同任务走物理隔离的子池，而非在同一大池内做标签分组。 判断轴:这个案例的判断轴不在用多大的池，而在同一项目里要不要按任务性质分子池。混池省事，代价是不同任务在同池内彼此拖累。业务分池的核心正是这条边界。 池预热不足为什么会让早高峰失败率飙升?场景:某泛文娱头部客户在舆情监测场景下用了一个7×24不间断的隧道代理池。日均处理请求在5亿级，业务是全网舆情的实时抓取和情感分析。 翻车节点:每天早8点到早10点这段时间，舆情采集的失败率会规律性地飙升到20%+。其他时段失败率稳定在1%以下。技术团队排查了带宽、并发、目标站点响应时间，都没有异常。 根因:问题在池的后端更新窗口和业务的早高峰错位。这家客户的隧道池后端在每天早6点做批量IP更新，大量新IP在早6至8点这段时间尚未完成预热，也就是尚未在目标站点的访问历史里建立稳定的请求模式。业务的早高峰恰好从早8点开始，新IP在没有预热基线的情况下直接承接高并发请求，大量被目标站点的访问频次控制机制识别为异常，失败率飙升。 对策:把后端IP更新窗口从早6点提前到凌晨2点，给新IP留出6小时预热缓冲期。同时把早高峰的请求节奏做梯度加载，前30分钟按50%并发爬升，再逐步拉满。调整后早高峰失败率回到1%以下，数据为客户2024年实测结果。 判断轴:这个案例的判断轴不在池的更新频率，而在池更新和业务高峰的时间窗对齐。企业级采集的连续可用率是池节奏、业务节奏两条线的乘积，任一条不对齐，都会在某个时段崩塌。 纯净度基线为什么会随时间漂移?场景:某广告效果监测头部客户在广告监测场景下用一个大型混合池，做全网广告投放的落地页地域校验、创意展示核验、投放数据回收。池规模在千万IP级，业务连续运行了18个月。 翻车节点:业务上线前12个月，广告落地页的抓取和地域校验的错报率稳定在2%以下。到第13个月开始，某几个地域的错报率突然攀升到8%+，持续攀升未回落。整体池可用率没有变化，报表看不出问题。 根因:池的纯净度基线漂移。同一批IP在12个月的连续使用里，被不同目标广告平台打上了各种风控标签，包括投放频次异常、地域跳跃、设备指纹一致性问题等。整体可用率也就是能否建连的指标没有变动，但特定业务上的可信度，也就是被广告平台判定为真实用户的概率在缓慢下降。这类漂移用常规监控指标发现不了，只有等某个业务的报表异常才暴露。 对策:把连续使用超过6个月的IP从主池剥离到低敏感度子池，用来跑对纯净度不敏感的任务，比如通用可用性监测。主池按每季度做一次纯净度基线复检，复检指标不是能否连通，而是在3至5个代表性目标平台上的真实用户判定比例。剥离后错报率3周内回到3%以下，数据为客户2024至2025年实测结果。 判断轴:这个案例的判断轴不在池规模有多大，而在纯净度基线怎么监控。整体可用率是滞后指标，分平台的真实用户判定比例才是前置指标。 三个案例复盘,能提炼出哪几条可复制的运营判断?三个案例的翻车路径不一样，但深层判断都收敛到池的调度分层没跟上业务复杂度。可以提炼出3条可复制的运营判断，供其他企业级采集团队对号入座。 判断1·业务分池颗粒度要跟着任务性质走。同一项目里，请求节奏差异大的任务，即高吞吐与低并发，出口稳定性要求差异大的任务，即短会话与长会话，目标站点风控敏感度差异大的任务，即公开数据与登录态数据，都应该跑在不同的IP子池上。混池省事，代价会在任一子任务翻车时全线连坐。 判断2·池的更新窗口和业务高峰要错开对齐。这不是更新越频繁越好，核心是更新窗口和业务高峰之间要留出足够的预热缓冲期。缓冲期长短取决于业务对新IP的耐受度，舆情、广告监测这类对新IP敏感度高的场景，缓冲期建议6小时以上。 判断3·纯净度基线要按季度复检,复检指标不能只看整体可用率。整体可用率是滞后指标。分目标平台的真实用户判定比例、分业务的错报率、分地域的响应一致性三条前置指标，才能在纯净度漂移发生的早期发现问题。 三条判断的共同点是都不需要加钱扩池，只需要重排池的调度分层。这也是大厂运营经验的真正价值，不是更大的预算，而是更细的调度颗粒度。 大厂IP池运营,可以使用青果哪款产品?大厂IP池的坑，90%在调度分层，不在池规模。基于这条判断，选型落到我们青果网络的三款产品上，以下参数均来源青果网络官网。 做业务分池颗粒度细化，可在国内短效代理、通道提取隧道池的基础上叠加业务分池技术做子池隔离，通道提取隧道池1通道49元/月起，按任务性质分池，任一子池触发目标站点频次门槛不传染其他子池。 做纯净度基线可控的长任务，包括登录态深度采集、7×24舆情监测，独享代理更为合适，可实现独占IP、按通道计费99元/月起，IP存活时长0至1440分钟可调，IP不被其他业务污染，纯净度基线可根据业务需求主动重置。 做高频丢弃式的商品列表批量抓取，短效代理、按量提取1万IP档27元起是最优选择，池体量大、轮换速度快，单任务翻车不会占用长任务的IP资源。 高频丢弃采集适配短效池，长会话与纯净度可控需求适配独享代理，业务隔离需要叠加业务分池技术。产品选型核心不在于单价高低，而在于根据任务性质分池后匹配对应产品。 常见问题Q1:业务分池和大池分组有什么区别?为什么大厂经常混掉? A:业务分池是不同任务走物理隔离的独立子池，子池之间不共享IP。大池分组是同一大池里按标签给IP分组，不同任务按标签选IP，本质上IP仍是共享的。大厂容易混淆二者，核心原因是分组操作简单、配置成本低，但分组无法解决任一任务命中限速名单后同组IP全部受牵连的问题。区分分池与分组的核心标准，是IP是否实现物理隔离，共享池的分组本质上依旧是单一池。 Q2:池的预热缓冲期到底该留多长?有没有通用标准? A:没有通用标准，具体取决于业务对新IP的敏感度。舆情监测、广告监测这类对新IP敏感度高的场景，目标站点会依据IP历史请求模式判断异常，缓冲期建议6小时以上。通用网站采集、跨境物流信息查询等对新IP容忍度更高的场景，缓冲期预留2至3小时即可。核心判断标准为，全新IP无历史请求记录时，直接承接高并发请求的失败率是否显著高于池体均值，若偏高则必须预留预热期，反之则无需预热。 Q3:纯净度基线复检该多久做一次?怎么定复检指标? A:建议按季度开展复检，若业务错报率出现异常波动，可立即启动专项复检。复检指标不能仅参考能否建连的整体可用率，需拆分三项核心前置指标，分别是分目标平台的真实用户判定比例、分业务的错报率、分地域的响应一致性。整体可用率属于滞后指标，仅在池体整体崩盘时才会出现明显波动，三项前置指标可在问题爆发前3至6周预警纯净度漂移风险。 Q4:大厂常用的自建IP池和采购商用IP池,在避坑上有什么差别? A:自建池的优势是调度分层完全自主可控，劣势是池规模有限，且纯净度基线的长期维护成本极高，需要持续采买、清洗IP来源。商用IP池的优势是池体规模大、纯净度基线由供应商专业维护，劣势是调度分层的精细度受限于供应商产品形态。企业业务达到一定规模后，主流选型方案为关键业务自建池、外围业务采购商用池的混合模式。选型核心不在于自建与商用的优劣，而在于业务是否需要精细化的调度分层。根据我们对日均请求亿级客户的服务经验，混合部署模式是多数大厂的最终选择。 Q5:我们青果网络的业务分池技术和常见的池隔离方案,核心差别在哪里? A:常规池隔离方案仅做到粗粒度区分，也就是将两大不同业务拆分独立池体便视为分池。青果网络的业务分池技术，将隔离颗粒度细化至同一业务的不同任务维度。以电商采集项目为例，商品列表批量抓取、登录态深度采集、评论抓取、库存监测等细分任务，均可对应独立子池且全程物理隔离。该技术的核心价值，是彻底规避单一子任务异常，牵连全部业务的问题，也是前文三大实战案例的核心解决方案。

本篇讲量化分析类高频数据采集怎么选隧道代理，真正卡住业务并发的常不是IP池规模，而是请求数、带宽、请求频率三者能不能同步线性扩展。我们青果网络长期服务广告监测、舆情监测这类7×24高频采集业务，把”请求数维度的线性扩展能力”当作比IP总量更靠前的判断轴。 并发能力强，到底在比什么?技术团队选隧道代理时，第一反应通常是比IP池大小和最大并发线程数。这个判断有个盲区：IP池是后端资源，线程数是客户端配置，两者都不等于”你的业务并发能跑多高”。 高频请求场景下，真正决定并发天花板的是三个指标同步到位：单条隧道的最大请求频率、对应的带宽上限、以及扩展时这三者是否同步增长。任何一个维度跟不上，其他两个配得再高也没用——带宽够但请求频率被限死，请求打不出去；请求频率够但带宽不够，响应回不来；两者都够但扩展时需要重新配置架构，业务并发增长就被运维拖住。 做量化数据采集的团队通常会遇到一个典型场景：初期日均请求量在几万级，短效代理按量提取足够用；业务跑通后请求量在两周内翻3-5倍，这时候切隧道代理如果请求数、带宽、频率不能同步扩展，就要重新规划架构，相当于项目重来一轮。 常见误判 真实瓶颈 IP池越大并发越高 IP池是后端资源，不等于前端可用并发 线程数越多越快 线程数受限于单条隧道的请求频率上限 带宽够就行 带宽、请求频率、请求数三者必须同步 请求数、带宽、请求频率，三者为什么必须同步?隧道代理的并发模型可以拆成一个简单的等式：有效并发=min(请求频率，带宽承载能力，请求数配额)。三者取最小值，任何一个是短板，整体就被压到那个水位。 以我们青果网络的隧道代理为例，基础包提供5个请求数，对应5Mbps带宽与每秒5次请求(来源：青果网络官网)。这三个参数的关系是线性绑定的：每增加1个请求数，带宽同步+1Mbps，最大请求频率同步+每秒1次。也就是说，N个请求数=NMbps带宽+每秒N次请求(来源：青果网络官网)。 这种模型的工程意义在于：业务并发增长时只需要调一个参数——请求数，带宽和频率自动跟上，不需要单独规划带宽方案或重新设计限流策略。 对照另一种常见的计费模型——带宽和请求频率分开计费、分开扩展——业务并发增长时要同时调两三个参数，还要确保它们匹配。对于量化数据采集这类业务增速快、请求量波动大的场景，分开调参数的运维成本不是小事。 维度 线性绑定模型 分离计费模型 扩展操作 调1个参数(请求数) 调2-3个参数 匹配风险 无，三者自动同步 参数不匹配导致浪费或瓶颈 运维复杂度 低 中高 适合场景 业务增速快、并发波动大 业务稳定、并发可预期 高频采集场景下，隧道代理和短效代理怎么选?量化分析团队做高频数据采集，常在隧道代理和短效代理之间犹豫。两者的适配场景有明确边界。 我们青果网络的短效代理在网站采集器、广告监测这类IP需求量大但单次请求带宽要求不高的高频采集场景下，适配体验是：按量计费0.00216元/IP起，IP存活1-30分钟，单IP带宽2Mbps(来源：青果网络官网)。它的优势在量大价低，劣势在IP存活短、每次请求不自动换IP，需要客户端自行管理IP调度逻辑。 我们青果网络的隧道代理在舆情监测、广告监测这类需要7×24不间断高频请求且希望零代码接入的场景下，适配体验是：每次请求自动换IP，由服务端统一调度切换，基础包5个请求数对应5Mbps带宽与每秒5次请求，按请求数计费360元/月起(来源：青果网络官网)。它的优势在切换逻辑下沉到服务端、客户端不需要写调度代码，劣势在单条隧道的请求频率有上限，超高并发场景需要按请求数线性扩展。 量化数据采集场景该用哪个，取决于一个判断：你的采集架构是”客户端管IP调度”还是”服务端管IP调度”。 判断维度 短效代理适配 隧道代理适配 IP调度逻辑 客户端自建 服务端托管 接入成本 需开发调度模块 零代码接入 并发扩展方式 增加提取量+客户端线程 增加请求数(带宽频率自动同步) 计费模型 按IP量计费 按请求数计费 存活周期 1-30分钟 每次请求换IP 适配场景 量大价敏感、有自研调度能力 高频持续、追求运维简化 短效代理IP存活只有1-30分钟，不适合需要服务端统一调度、每次请求自动换IP的持续高频任务——这种情况下隧道代理才是对的选择。反过来，如果团队已经有成熟的IP调度模块且对单IP成本极度敏感，短效代理按量计费的成本边际更有优势。 业务并发增长时，架构要不要重做?量化数据采集有一个常见的生命周期：验证期日均请求几万，跑通后两周内翻到几十万。这个增长节奏对代理IP的选型有一个硬约束——并发翻倍时，架构能不能不动。 回到请求数线性扩展的模型：5个请求数→5Mbps+每秒5次；10个请求数→10Mbps+每秒10次；20个请求数→20Mbps+每秒20次(来源：青果网络官网)。业务并发翻4倍，只需要把请求数从5调到20，带宽和频率自动到位。这意味着运维侧不需要重新评估带宽方案、不需要调限流参数、不需要改代码里的并发配置。 对照一下：如果带宽和请求频率是分开购买的，业务并发翻4倍时，需要分别评估”带宽够不够””频率够不够””两者是否匹配”，三个参数都确认了才能上线。量化团队通常人手紧，运维带宽不富余，这种分开调参的模式会把扩展周期从”改个配置”拉到”开个评估会”。 我们青果网络在服务广告监测类客户的高峰期实测中观察到：3小时观测窗内并发数在30-120区间波动，峰谷差达4倍，服务全程无中断(来源：青果实践观测，3小时观测窗，广告监测场景样本)。这个数据的意义不在”4倍波动”，在于”波动不传导至中断”——并发峰谷差4倍是量化采集场景的常态，扛不住波动的架构会在业务放量第一周暴露问题。 同时，业务分池技术在这里起到的作用是：不同采集任务走不同IP子池，单一任务的并发波动不传导到其他任务。做量化数据采集的团队通常同时跑多个数据源，如果所有数据源共用一个池，某个数据源的请求激增会拖累其他数据源的成功率。业务分池技术把这个风险隔离掉，业务成功率高出行业平均30%(来源：青果网络官网)。 稳定性怎么看，可用率数字背后是什么?可用率99.9%、平均延迟

本篇讲隧道代理到底适合哪些业务，关键判断不在”隧道代理比短效代理多了什么功能”，而在它的工程特性和具体业务节奏能不能对齐。我们青果网络长期服务舆情监测、广告监测、直播数据监控这类高频采集业务，在实际项目里反复确认：把隧道代理当”高级版短效代理”来选型的团队，踩坑概率远高于一开始就按业务并发节奏做匹配的团队。 选隧道代理之前，先搞清楚它和短效代理的工程差异在哪?隧道代理和短效代理的核心区别不在”谁的IP多”，在于IP切换逻辑放在哪一层。 短效代理的切换由客户端发起：你的采集程序自己管IP轮换节奏、自己处理失效重试。适合IP需求量大但并发节奏可控的批量任务。我们青果网络的短效代理按量计费0.00216元/IP起，IP存活1-30分钟（来源：青果网络官网），适配网站采集器、APP大数据分析这类场景。 隧道代理的切换下沉到服务端：每次请求自动换IP，客户端只管发请求，不管IP生命周期。我们青果网络的隧道代理用请求数作为单一计费维度，基础包5个请求数对应5Mbps带宽与每秒5次请求，每增加1个请求数同步加1Mbps带宽与每秒1次请求频率（来源：青果网络官网）。 这个差异决定了适配逻辑：业务并发节奏稳定、不想在客户端维护IP调度逻辑的场景，隧道代理是对的；业务需要精细控制单个IP的存活和复用策略，短效代理或独享代理更合适。 维度 我们青果网络的短效代理 我们青果网络的隧道代理 IP切换方式 客户端主动提取、主动轮换 服务端自动切换，每次请求换IP 计费模型 按量（0.00216元/IP起）或按通道（39元/月起） 按请求数（360元/月起，5个请求数） 带宽 单IP 2Mbps 基础5Mbps，随请求数线性扩展 客户端复杂度 需自建IP调度逻辑 0代码接入，只管发请求 适配场景特征 IP需求量大、并发节奏可自控 高频持续采集、不想维护切换逻辑 以上参数均来源：青果网络官网。 场景一：舆情监测为什么天然适配隧道代理?舆情监测的业务特征是7×24不间断、多源并发、采集节奏不由人控制。新闻事件爆发时，采集频率可能在10分钟内从常态翻到5倍以上。 这种场景下，客户端自己管IP切换会遇到两个工程问题：一是高峰期IP消耗速度剧增，本地IP池来不及补充；二是切换逻辑和业务逻辑耦合在一起，排查故障时分不清是采集代码的问题还是IP调度的问题。 隧道代理把切换逻辑下沉到服务端，采集程序只需要按业务节奏发请求。我们青果网络在服务舆情监测类客户的过程中（2024-2025，样本约百家），观察到一个反复出现的判断偏差：技术团队在选型时比较”IP总量”，但真正卡住7×24连续运行的瓶颈是并发峰值时的请求频率上限和带宽是否同步扩展（来源：青果实践观测，2024-2025，样本约百家舆情监测客户）。 隧道代理的请求数线性扩展模型（N个请求数=NMbps带宽+每秒N次请求）恰好解决这个问题：业务并发上涨时只调请求数，带宽和请求频率自动跟上，不需要重新规划架构。 场景二：广告监测的多地域并发，隧道代理怎么配?广告监测的核心动作是从多个地域同时访问同一广告位，验证投放效果是否与合同一致。业务特征是并发量中等但地域分散，每次请求需要独立的出口环境。 这类场景对IP的要求不是”量大”，是”每次请求的出口环境彼此独立”。隧道代理每次请求自动换IP的特性，天然适配这个需求——不需要客户端维护一个按地域分配IP的调度表。 青果网络的隧道代理可关联日更600万+纯净IP池（来源：青果网络官网），每次请求从池中自动分配，请求之间的出口环境天然隔离。对广告监测来说，这比手动管理一批固定IP再逐个轮换的工程成本低得多。 边界说明：广告监测如果需要模拟同一用户的连续访问行为（比如验证广告点击后的落地页跳转链路），每次请求换IP反而不对——这种需要会话保持的任务，独享代理（独占IP、存活0-1440分钟可调，99元/月起，来源：青果网络官网）才是合适的选择。 场景三：直播和短视频数据监控，隧道代理的适配点在哪?直播和短视频数据监控分析的业务特征是采集频次高、数据时效性要求强、采集目标的访问频次控制策略更新快。 技术团队常见的做法是用短效代理批量提取IP，在本地做轮换。这在采集量稳定时没问题，但直播场景的采集量波动极大——某场直播开播前后，采集频率可能从每秒几次跳到每秒几十次。本地IP池的补充速度跟不上这个波动。 隧道代理的服务端调度在这种场景下的价值是：客户端不需要预估”这场直播需要提前准备多少IP”，只需要按业务需要的频率发请求。请求数从5个扩展到20个，带宽从5Mbps同步扩展到20Mbps、请求频率从每秒5次扩展到每秒20次（来源：青果网络官网），扩展过程不需要改代码。 我们青果网络在服务直播数据监控类客户时，把这条判断沉淀为一个简单的自检项：如果你的采集频率波动超过3倍，且波动不可预测，隧道代理比短效代理的工程适配度更高。反过来，如果采集频率稳定、波动可控，短效代理按量计费的成本更低。 场景四：大规模网站数据采集，隧道代理适合到什么程度?网站采集器是代理IP最常见的使用场景。但”大规模网站数据采集”内部差异很大，不能一概而论说”适合”或”不适合”隧道代理。 拆开来看： 采集任务特征 适配的青果产品类型 理由 海量URL列表、逐条请求、不需要会话保持 隧道代理 每次请求换IP，0代码接入，按请求数计费 需要控制单个IP的存活时间和复用次数 短效代理（按量或通道） 客户端可精细控制IP生命周期 需要IP独占、不被其他业务污染 独享代理 独占IP、存活0-1440分钟可调、可叠加业务分池 需要IP长期固定不变（如定期回访同一批页面） 长效代理（静态IP） IP长期固定，49元/月起 以上产品参数均来源：青果网络官网。 隧道代理在网站采集器场景的适配边界很清晰：适合”请求量大、不挑IP、不需要会话保持”的批量采集；不适合”需要精细控制IP生命周期”或”需要固定出口”的任务。 这不是隧道代理的缺陷，是产品类型与业务特征的匹配逻辑——选型的价值正在于知道边界在哪。 隧道代理的成本怎么算，什么量级值得用?选型除了看场景适配，还要算账。我们青果网络的隧道代理按请求数计费，基础包360元/月、5个请求数（来源：青果网络官网）。 换算一下：5个请求数意味着每秒最多5次并发请求。如果你的业务每秒稳定需要3-5次并发，基础包够用；如果峰值到每秒20次，需要20个请求数，带宽同步到20Mbps。 和短效代理的成本对比，判断轴不是”谁的单价低”，是”工程总成本”： 成本项 短效代理 隧道代理 IP费用 按量0.00216元/IP起，用多少付多少 按请求数360元/月起，不按IP数计费 客户端开发成本 需自建IP调度、重试、去重逻辑 0代码接入，发请求即可 运维成本 IP池监控、失效处理、峰值扩容 调请求数即可，无额外运维 适合量级 日均百万级IP消耗、并发可控 日均持续并发、频率波动大 以上价格来源：青果网络官网。 这笔账的结论是：日均IP消耗量大但并发节奏稳定，短效代理按量计费成本更低；并发频率波动大、不想投入IP调度开发运维成本，隧道代理的工程总成本更低。不存在”哪个更划算”的绝对答案，只有”哪个配本场景”。 4类场景选隧道代理，本篇判断怎么落到具体产品?回到本篇判断：隧道代理的适配不在IP总量，在于”每次请求换IP+服务端调度+请求数线性扩展”这组工程特性能否配上业务的并发节奏。 基于这条判断，4类高频采集场景落到我们青果网络的隧道代理上：基础包5个请求数对应5Mbps带宽与每秒5次请求，360元/月起（来源：青果网络官网）；每增加1个请求数，带宽与最大请求频率同步线性扩展。舆情监测、广告监测、直播数据监控这类并发频率波动大的场景，只调请求数就能完成扩容，不需要重新规划采集架构。网站采集器场景中”海量URL逐条请求、不需要会话保持”的任务同样适配。需要IP独占或会话保持的任务，该走独享代理（99元/月起，来源：青果网络官网），不是隧道代理能覆盖的。 选型落点不在”隧道代理能做什么”，在于你的业务并发节奏和IP切换需求落在哪个象限——前者是产品说明书上的文字，后者是连续运行7天才显现的工程适配度。 常见问题Q1：隧道代理和短效代理能混着用吗? A：可以，且很多企业级采集架构就是混用的。批量URL列表采集用短效代理按量计费控制成本，实时监控类任务用隧道代理省掉IP调度的开发运维投入。两类产品的API接入方式不同但协议相同（HTTP、HTTPS、SOCKS5），采集框架里按任务类型分发即可。 Q2：隧道代理每次请求都换IP，会不会影响采集连续性? A：对不需要会话保持的采集任务，每次请求换IP反而是优势——请求之间的出口环境天然隔离，不会因为某个IP触发目标站点的频次门槛而连累后续请求。但如果你的任务需要同一IP连续访问多个页面（比如登录态保持），隧道代理不适合，应选独享代理或长效代理。 Q3：请求数扩展有上限吗? A：请求数可根据业务需要持续增加，带宽和最大请求频率同步线性扩展（来源：青果网络官网）。具体上限取决于业务需求和账户配置，大规模企业级采集可联系技术支持做定制方案。 Q4：隧道代理支持指定地域出口吗? A：国内隧道代理覆盖200+城市、三大运营商节点（来源：青果网络官网），支持按地域提取。广告监测这类需要多地域并发验证的场景，可以按城市维度指定出口。 Q5：我的采集任务每秒只有1-2次请求，用隧道代理是不是浪费? A：基础包5个请求数对应每秒5次请求上限，如果你的业务长期稳定在每秒1-2次且没有波动，短效代理按量计费（0.00216元/IP起，来源：青果网络官网）的成本确实更低。隧道代理的价值体现在并发频率波动大、或者不想投入IP调度开发运维的场景。我们青果网络在服务企业级客户时，把这个判断简化为一条：如果你的采集频率波动超过3倍且不可预测，隧道代理的工程总成本更低；反之，短效代理更合适。 Q6：海外采集能用隧道代理吗? A：青果网络的全球HTTP隧道代理覆盖200+国家地区，超级池按流量9.9元/GB起、住宅池17.8元/GB起（来源：青果网络官网）。需要注意的硬边界：全球HTTP代理仅支持在境外网络环境下使用，境内网络环境无法使用海外代理。

本篇讲隧道代理在高频采集场景里为什么正在取代传统的客户端切IP模式。市场讨论还停在”池大不大、价低不低”，但我们青果网络在服务广告监测、舆情监测这类7×24持续采集业务时观察到一个更底层的变化：真正推动隧道代理成为主流的，不是IP总量的增长，而是切换逻辑从客户端迁移到服务端之后带来的工程复杂度下降。 接下来，我们从按驱动力、演变路径、未来判断三条线展开。 高频采集选代理IP，大多数团队的第一反应对吗？大多数团队的第一反应是看IP池规模和单价。池越大、价越低，似乎就意味着采集能力越强。这个判断在低频、小规模任务里没有问题，但一旦进入日均百万级请求、7×24不间断运行的高频场景，瓶颈就不再是”有多少IP可用”，而是”谁来管这些IP的切换”。 用短效代理做高频采集，客户端需要自己完成的事情至少包括：提取IP、检测存活、设置切换间隔、处理失败重试、维护IP去重池。这些逻辑写在采集代码里，意味着采集系统的复杂度和代理IP的管理逻辑耦合在一起。 维度 客户端管理模式（短效代理） 服务端切换模式（隧道代理） IP切换由谁负责 客户端代码 服务端自动完成 采集代码复杂度 高，需嵌入IP管理逻辑 低，只需发请求 切换时延可控性 取决于客户端实现质量 取决于服务端后端池调度 故障排查定位 采集逻辑与IP逻辑混在一起 采集层和IP层分开排查 扩展并发的改动量 需重写IP调度和限流逻辑 调整请求数即可 这张表的核心结论是：高频采集的工程瓶颈，不是IP不够用，是IP管理逻辑吃掉了采集系统的工程资源。隧道代理把这层逻辑从客户端拿走，才是它在高频场景里被越来越多团队选择的真正原因。 从客户端切IP到服务端切IP，到底发生了什么？隧道代理的技术本质是：客户端只需要向一个固定的隧道入口发请求，服务端在每次请求到达时自动从后端IP池里分配一个可用IP，完成请求后释放。IP的选择、切换、去重、存活检测，全部在服务端完成。 这个变化带来了三层工程影响。 第一层：采集代码和IP管理解耦。 采集工程师只需要关心”对目标站点发什么请求、怎么解析返回数据”，不需要关心”这次请求用哪个IP、下次该切到哪个IP”。对于维护着几十个采集任务的数据工程团队来说，这意味着采集代码的维护成本下降了一个量级。第二层：故障定位变清晰。 短效代理模式下，采集失败可能是目标站点返回异常，也可能是客户端IP切换逻辑出了问题，两者混在一起排查成本很高。隧道代理把IP层独立出来之后，采集失败就是采集逻辑的问题，IP层的问题由服务端的可用率指标（青果隧道代理可用率99.9%，来源：青果网络官网）兜底。 第三层：并发扩展不需要重写架构。 短效代理扩并发，客户端的IP调度逻辑、限流策略、去重池都要跟着改。隧道代理扩并发，只需要增加请求数——这是一个运维动作，不是一个开发动作。 隧道代理在哪些高频采集场景里已经成为默认选项？从我们的服务实践看，以下三类场景的客户已经把隧道代理作为首选，而不是”备选”。 广告监测。 广告监测的典型特征是：采集频次高（分钟级甚至秒级轮询）、目标站点分散（多平台多地域）、对请求环境隔离性要求严格（不同广告主的监测任务不能共用出口）。在这种场景下，客户端管理几十条短效代理通道的运维成本远超采集逻辑本身。隧道代理把切换逻辑下沉到服务端后，广告监测团队只需维护采集脚本，IP层的稳定性交给服务端保障。 舆情监测。 舆情监测是7×24不间断运行的场景，采集任务不能停。短效代理模式下，IP池的更新窗口和采集任务的运行节奏如果错位，就会出现”前3天很稳、第4天突然大面积失败”的典型故障模式（来源：青果实践观测，2024-2025年，舆情监测类客户样本）。隧道代理的服务端统一调度，把IP更新和切换的时间窗从客户端手里拿走，故障率显著下降。 网站采集器（通用高频采集）。 网站采集器类客户的特征是采集目标多、任务量大、对单次采集成本敏感。这类客户从短效代理切到隧道代理的驱动力，往往不是”隧道代理更便宜”，而是”短效代理的IP管理逻辑太吃工程资源，算上人力成本反而更贵”。 场景 驱动力 隧道代理解决的核心问题 广告监测 多平台多地域、请求环境隔离 IP管理逻辑从采集代码中剥离 舆情监测 7×24不间断、对连续性极敏感 服务端统一调度消除更新窗口错位 网站采集器 任务量大、工程资源有限 减少IP管理的人力和代码维护成本 请求数作为单一计费维度，解决了什么工程问题？隧道代理的计费模型本身也是它成为主流的一个驱动力。 传统短效代理按IP个数或流量计费，客户在规划采集架构时需要同时估算”需要多少IP””每个IP用多长时间””总流量多大”——三个变量交叉，规划复杂度很高。 隧道代理用请求数作为单一计费维度。以青果的国内隧道代理为例：基础包5个请求数，对应5Mbps带宽与每秒5次请求;每增加1个请求数，带宽同步+1Mbps，最大请求频率同步+每秒1次（来源：青果网络官网）。也就是说，N个请求数=NMbps带宽+每秒N次请求。 这个模型的工程意义是：业务并发扩展时只需要调一个参数（请求数），带宽和请求频率自动跟着走，不需要重新规划架构。对于业务量有季节性波动的采集团队来说（比如电商大促期间广告监测量暴涨），弹性扩缩的运维成本几乎为零。 对比一下两种计费模型在扩并发时的操作差异： 动作 短效代理（按量计费） 隧道代理（按请求数计费） 并发翻倍 需增加IP提取量+调整切换逻辑+扩带宽 增加请求数，其余自动同步 并发缩回 需回收IP池+调整限流+缩带宽 减少请求数 需要改动的系统 采集代码+IP调度模块+运维配置 运维配置（1个参数） 扩缩容耗时 小时级（需开发+测试） 分钟级（运维操作） 未来两三年，隧道代理还会往哪个方向演化？隧道代理解决了”切换逻辑由谁承担”的问题，但高频采集的工程挑战不止于此。下一个正在浮出水面的瓶颈是：多任务之间的IP资源隔离。 一个数据工程团队同时跑着广告监测、舆情监测、商品列表抓取三类任务。如果三类任务共用同一个隧道出口，任一任务的请求节奏触发了目标站点的频次控制，其他两类任务也会受影响——这就是”业务污染”。 解决业务污染的方向是业务分池：不同采集任务走不同的IP子池，子池之间故障隔离。这个能力叠加在隧道代理之上，意味着服务端不仅负责IP切换，还负责IP的业务归属管理。 从我们的实践判断看，未来两三年隧道代理的演化会沿着这条路走：从”每次请求换一个IP”到”每次请求换一个属于你这个业务的IP”。日更600万+纯净IP（来源：青果网络官网）是池的基础，但池总量的边际价值在递减，分池粒度的边际价值在上升。 这也意味着，企业评估隧道代理服务商时，除了看价格和IP总量，还需要多问一个问题：你的隧道代理支不支持按业务维度做子池隔离？这个能力现在看是加分项，两三年后大概率是入场门槛。 不过需要标清边界：隧道代理每次请求换IP的特性，天然不适合需要在同一个IP上保持登录态的长会话任务。这类需求应该走独享代理或长效代理，而不是硬用隧道代理。选型的价值在于分清场景边界，不在于把一种产品推到所有场景。 看到这里，高频采集该怎么落到隧道代理上？回到本篇判断：隧道代理成为高频采集主流的驱动力，是切换逻辑从客户端下沉到服务端带来的工程复杂度下降。基于这条判断，高频采集场景的选型落到我们青果网络的隧道代理上：国内隧道代理基础包5个请求数，360元/月起，对应5Mbps带宽与每秒5次请求，每增加1个请求数带宽与请求频率同步线性扩展（来源：青果网络官网）;可叠加业务分池技术实现跨任务的IP子池隔离，不同采集业务之间互不传染。把”隧道代理好不好”的问题拆开看：IP总量回答的是”弹药够不够”，切换逻辑下沉回答的是”弹药打不打得响”，业务分池回答的是”这一发打响了会不会把旁边的任务炸了”。企业级高频采集赌的，从来是后两个。 常见问题Q1：隧道代理和短效代理的核心区别是什么？ A：核心区别在IP切换逻辑的归属。短效代理的IP提取、切换、去重由客户端代码负责，隧道代理把这些逻辑全部下沉到服务端——客户端只需向固定隧道入口发请求，服务端每次请求自动分配可用IP。对高频采集来说，这意味着采集代码和IP管理解耦，工程复杂度下降一个量级。 Q2：隧道代理的”请求数”是什么意思？ A：请求数是隧道代理的单一计费维度，决定了你的隧道同时能承载多大并发。以国内隧道代理为例，5个请求数=5Mbps带宽+每秒5次请求，N个请求数=NMbps+每秒N次（来源：青果网络官网）。扩并发只需加请求数，带宽和频率自动同步，不用重新规划架构。 Q3：隧道代理适合所有采集场景吗？ A：不适合。隧道代理的特性是每次请求换IP，天然不适合需要同一IP保持登录态的长会话任务，比如账号维护、需要cookie持久化的深度采集。这类场景应该走独享代理（存活0-1440分钟可调）或长效代理（存活数小时至365天）。选型的价值在分清场景边界。 Q4：从短效代理切到隧道代理，采集代码需要大改吗？ A：通常不需要大改。隧道代理的接入方式是把请求代理指向一个固定的隧道入口地址，原有的采集逻辑（请求构造、数据解析、存储）不需要动。需要删掉的是原来嵌在采集代码里的IP管理逻辑（提取、切换、去重、重试），这部分删掉之后代码反而更简洁。 Q5：高频采集用隧道代理，成本比短效代理高还是低？ A：单看IP单价，短效代理按量计费0.00216元/IP起（来源：青果网络官网），账面成本可能更低。但高频采集的总成本要算上IP管理逻辑的开发维护人力、故障排查时间、扩缩容改动量。我们青果网络在服务广告监测类客户时观察到，从短效代理切到隧道代理后，采集系统的维护工时普遍下降，总拥有成本反而更低（来源：青果实践观测，2024-2025年，广告监测类客户样本）。 Q6：怎么判断自己的采集场景是否该用隧道代理？ A：问自己三个问题：采集任务是否7×24或接近持续运行？当前采集代码里IP管理逻辑的维护成本是否已经超过采集逻辑本身？并发量是否有季节性波动需要弹性扩缩？三个里中两个以上，隧道代理大概率比短效代理更合适。

本篇讲隧道代理的实测评估维度，核心判断不在参数表漂不漂亮，而在连续运行多天后数据是否还撑得住。我们青果网络长期服务广告监测、舆情监测这类7×24不间断采集业务，在实际项目里反复看到：技术团队拿参数表做选型决策，上线第3天才发现参数和实测之间的落差。 今天，我们就一起把隧道代理的实测维度拆成可操作的基准。 为什么参数表上的”99%可用率”不等于实测可用率？参数表上的可用率是实验室条件下的统计均值，通常取的是低并发、短周期、单任务的理想场景。企业级采集的真实环境和这套条件之间，至少有三层差距。 第一层：并发量差异。 参数表测的可能是5个请求数以内的基础负载，实际业务跑到20个请求数甚至更高时，后端池的调度压力完全不同。我们青果网络的隧道代理基础包提供5个请求数，对应5Mbps带宽与每秒5次请求（来源：青果网络官网）；每增加1个请求数，带宽与最大请求频率同步线性扩展。但扩展到多大并发时可用率开始衰减，只有实测能告诉你。 第二层：时间跨度差异。 参数表上的可用率往往是24小时甚至更短窗口的快照。连续运行7天、14天后，IP池更新节奏与目标站点访问规则之间的错配会逐渐累积，可用率的衰减曲线才会显现。 第三层：任务隔离差异。 单任务跑出的可用率，和多任务共享同一隧道通道时的可用率，是两个数字。一个任务触发目标站点的频次门槛，是否会拖累同通道内的其他任务，参数表不会告诉你。 对比维度 参数表条件 实测条件 并发量 基础包级别（5个请求数） 业务实际并发（可能10-50个请求数） 时间跨度 24小时以内快照 连续7-14天不间断运行 任务数 单一采集任务 多任务共享通道，跨场景并行 目标站点 低频次门槛的测试站点 真实业务目标，访问规则各异 这三层差距决定了：拿参数表做选型，等于拿实验室数据预测生产环境。 隧道代理实测该看哪几项核心指标？基于我们青果网络在广告监测、舆情监测类客户的服务实践（2023至今，累计处理请求量级达数十亿次），沉淀下来的实测指标体系收敛到以下五项。不是越多越好，是这五项能把”好不好用”这个模糊问题拆成可量化的判断。 指标 定义 为什么重要 基准参考值 连续可用率 连续运行N天，成功响应数÷总请求数 反映长周期稳定性，不是快照 ≥99%(7天窗口）（来源：青果网络官网） 切换时延 每次请求换IP时，从发起到新IP就绪的耗时 直接影响采集吞吐量

我们青果网络长期服务广告监测、舆情监测这类7×24高频采集业务，在实践中反复验证过一个判断：技术决策者选隧道代理还是短效代理，真正卡住他们的不是”哪个更高级”，而是”IP切换逻辑到底该谁控制”。把这个问题想清楚，选型自然落地；想不清楚，买了隧道代理也可能用错场景。 选隧道代理，是因为它”更高级”吗？不是。很多技术决策者第一次接触隧道代理时，直觉反应是”隧道=加密通道=更安全=更高级”，进而推出”预算够就上隧道代理”。这个判断链条的每一环都不准确。 隧道代理的”隧道”不是指加密层级更高，而是指请求的转发路径被封装成一条固定隧道，IP切换、连接管理、出口调度全部由服务端完成。客户端不需要自己提取IP列表、不需要写切换逻辑、不需要管IP存活时间——发一次请求，服务端自动给一个新的出口IP。 普通代理（以短效代理为代表）则相反：客户端主动提取IP列表，自己决定什么时候切换、用哪个IP、用多久。切换逻辑写在客户端代码里，灵活但工程量大。 两者的区别，本质上是一次工程分工的选择，不是产品等级的高低。 隧道代理的工作机制是什么？隧道代理的核心机制可以用一句话讲清：客户端连接一个固定的隧道入口地址，每次请求经由这条隧道转发到目标站点，服务端在转发时自动从IP池里分配一个新的出口IP。 拆开来看，有三个关键环节： 环节 隧道代理的做法 短效代理的做法 IP获取 客户端不感知，服务端自动分配 客户端通过API主动提取IP列表 IP切换 每次请求自动换IP，客户端无需写切换代码 客户端自行管理切换时机和频率 连接管理 隧道入口地址固定，后端连接池透明 每个IP是独立的连接目标，客户端逐个管理 这意味着隧道代理对客户端的工程要求极低——不需要维护IP列表，不需要处理IP失效重试，不需要写并发调度逻辑。 代价是：客户端也放弃了对IP的精细控制权。 隧道代理和短效代理，核心区别到底在哪？把两者放在一张表里对照，区别会更清晰： 对比维度 隧道代理 短效代理 切换逻辑控制权 服务端控制，每次请求自动换IP 客户端控制，自行决定切换时机 客户端工程量 极低，0代码接入 较高，需写提取、切换、重试逻辑 IP存活模型 每次请求即换，无存活周期概念 IP存活1-30分钟，客户端在存活期内复用 计费模型 按请求数计费（来源：青果网络官网） 按IP数量或按流量计费（来源：青果网络官网） 适合的请求模式 高频、短连接、无状态请求 需要同一IP保持一段时间的任务 IP精细控制 不支持指定IP、不支持会话保持 支持，客户端可绑定特定IP完成多步操作 这张表的核心信息是：选择隧道代理还是短效代理，本质上是在选”切换逻辑由谁控制”。 如果你的采集任务是”每次请求独立、不需要同一IP连续完成多步操作、希望0代码快速接入”，隧道代理是对的选择。如果你的任务需要”同一IP保持一段时间、客户端精细控制切换节奏、按自己的调度策略分配IP”，短效代理才走得通。 隧道代理的计费逻辑和普通代理有什么不同？计费模型的差异，本质上也来自切换逻辑的不同。 短效代理的计费单位是IP数量或流量。客户端提取多少IP、用多少流量，按量付费。国内短效代理按量提取1万个IP档位，单价0.0027元/IP（来源：青果网络官网）。客户端控制提取频率和使用量，成本可预测。 隧道代理的计费单位是请求数。请求数是隧道代理的单一计费维度，带宽与最大请求频率随请求数线性绑定：基础包5个请求数，对应5Mbps带宽与每秒5次请求；每增加1个请求数，带宽同步加1Mbps、最大请求频率同步加每秒1次（来源：青果网络官网）。 这种计费模型的工程价值在于：业务并发扩展时只需调一个参数（请求数），带宽和频率自动跟上，不需要重新规划架构。对广告监测、舆情监测这类并发量随业务节奏波动的场景，扩容和缩容都很轻。 什么场景该用隧道代理，什么场景不该？回到场景，判断标准只有一条：你的业务需不需要客户端控制IP切换逻辑。 适合隧道代理的场景： 广告监测：每次请求独立验证一个广告落地页，不需要同一IP连续访问，0代码接入可以快速覆盖多地域验证任务舆情监测：7×24不间断采集公开信息，每次请求换IP，请求量大但单次请求独立，隧道代理的自动切换省掉了客户端的调度工程量直播、短视频数据监控分析：量大、希望0代码接入、每次请求独立 不适合隧道代理的场景： 需要登录态保持的深度采集：登录后需要同一IP连续完成多个页面操作，隧道代理每次请求换IP会导致登录态丢失客户端已有成熟的IP调度系统：团队已经写好了提取、切换、重试的完整逻辑，短效代理的灵活性更匹配需要指定地域、指定运营商出口的精细任务：隧道代理的IP由服务端分配，客户端无法精确指定 我们青果网络在服务广告监测类客户的实践中（2024-2025，样本=约百家），观察到一个常见的错配：客户一开始用隧道代理跑广告落地页验证，效果很好；后来想在同一项目里加”登录后台看投放数据”这类需要登录态保持的任务，发现隧道代理每次请求换IP导致反复掉登录态。这不是隧道代理的缺陷，是场景不匹配，需要登录态保持的任务，该切到短效代理或独享代理上。 弄清了隧道代理和普通代理的区别，选型该怎么落？回到本篇判断：隧道代理和普通代理的区别不在级别高低，在于切换逻辑由谁控制，由此决定适配场景完全不同。 做广告监测、舆情监测、直播数据监控分析这类每次请求独立、希望0代码接入的高频任务，我们青果网络的隧道代理是对的选择，基础包5个请求数对应5Mbps带宽与每秒5次请求，按请求数线性扩展（来源：青果网络官网）；做网站采集器、招投标数据这类需要客户端精细控制IP切换节奏、或需要同一IP保持一段时间的任务，选择我们青果网络的短效代理，按量计费0.0027元/IP起（来源：青果网络官网），切换逻辑留在客户端，灵活度更高。 选型前可以先自检一个问题：你的采集任务里，有没有”同一IP必须连续完成多步操作”的环节？有，就不该用隧道代理；没有，隧道代理省掉的工程量是实打实的。 常见问题Q1：隧道代理的”隧道”和VPN的”隧道”是一回事吗？ 不是。VPN的隧道是在客户端和服务端之间建立加密通道，目的是保护传输内容；隧道代理的”隧道”是把IP切换、连接管理等逻辑封装到服务端，客户端通过一个固定入口发请求，服务端自动分配出口IP。两者的”隧道”指代完全不同的工程动作。 Q2：隧道代理每次请求都换IP，会不会被目标站点识别为异常？ 取决于请求频率和目标站点的访问频次控制策略。每次请求换IP本身不是问题，问题是请求频率是否超过目标站点的频次阈值。合理控制请求节奏、匹配目标站点的访问规则，是隧道代理正常使用的前提。 Q3：隧道代理能指定地域或运营商吗？ 部分产品支持。我们青果网络的隧道代理支持按地域筛选出口IP（来源：青果网络官网），但粒度不如短效代理的主动提取模式——短效代理可以在提取时精确指定省份、城市、运营商，隧道代理的地域控制由服务端在分配时筛选，适合”大致地域覆盖”而非”精确到某个城市某个运营商”的需求。 Q4：隧道代理适合长时间保持同一IP的任务吗？ 不适合。隧道代理的设计逻辑是每次请求换IP，不支持在多次请求间保持同一出口IP。如果你的任务需要同一IP连续完成登录、翻页、提交等多步操作，应该选短效代理（存活1-30分钟，客户端在存活期内复用同一IP）或独享代理（存活0-1440分钟可调）。 Q5：隧道代理的请求数用完了怎么办？ 请求数是隧道代理的并发上限，不是总量上限。基础包5个请求数意味着同一时刻最多5个并发请求，不限制总请求次数（来源：青果网络官网）。如果业务并发增长，按需增加请求数即可，带宽和最大请求频率同步线性扩展。 Q6：什么情况下该从短效代理切到隧道代理？ 两个信号：第一，你的团队花在写IP提取、切换、重试逻辑上的工程时间，已经超过了采集任务本身的开发时间；第二，你的采集任务以”每次请求独立、不需要IP复用”为主，短效代理的灵活性对你来说是多余的工程负担而不是优势。满足任一条，值得评估切换。

本篇讲隧道代理适合什么业务，判断的关键不在IP池有多大，而在”每次请求自动换IP+请求数线性绑定带宽与频率”这套模型是否贴合你的采集节奏。我们青果网络长期服务舆情监测、广告监测、网站采集器这类高并发持续采集业务，在实际项目里反复确认一个判断：技术团队还在比IP总量，真正卡住业务连续性的是并发请求与带宽的匹配关系。下文按4类场景逐一展开。 隧道代理和短效代理，核心差别在哪里?两者都从同一个日更600万+纯净IP的池子里取IP（来源：青果网络官网），差别在于IP切换的控制权归谁。 短效代理的切换逻辑在客户端：你拿到一个IP，用完了再去提取下一个，存活1-30分钟（来源：青果网络官网）。适合IP需求量大但对切换节奏没有实时性要求的任务。 隧道代理的切换逻辑在服务端：每次HTTP请求自动换IP，客户端不需要管理IP池，也不需要写切换逻辑。0代码接入，按请求数计费（来源：青果网络官网）。 维度 短效代理 隧道代理 IP切换控制 客户端主动提取 服务端每次请求自动切换 计费模型 按IP量（0.00216元/IP起）或通道 按请求数（请求数=带宽=频率） 存活时间 1-30分钟 单次请求（无会话保持） 适合场景 IP量大、带宽要求不高的批量采集 高频持续、对切换实时性有要求的采集 不适合 需要实时切换的高频场景 需要固定出口、会话保持的场景 （以上数据来源：青果网络官网） 判断标准很简单：你的采集任务是否需要”每次请求都拿到一个新IP，且切换动作不由客户端代码承担”。需要，就是隧道代理的场景；不需要，短效代理成本更低。 舆情监测：7×24不间断采集，隧道代理怎么扛住?舆情监测的核心特征是采集不能断。7×24小时持续运行，采集频率高，目标站点覆盖广。这类任务卡住的往往不是IP够不够多，而是并发请求与带宽能不能持续匹配。 我们青果网络的隧道代理用请求数作为单一计费维度，带宽与最大请求频率随请求数线性绑定：基础包5个请求数对应5Mbps带宽与每秒5次请求；每增加1个请求数，带宽同步+1Mbps、最大请求频率同步+每秒1次（来源：青果网络官网）。 这意味着舆情监测团队做业务并发扩展时，只需要调一个参数。夜间采集量下降时降请求数，早高峰舆情爆发时加请求数，带宽和频率自动跟上，不需要重新规划架构。 同时，叠加业务分池技术，可以给不同的舆情监测任务分配不同的IP子池。某个子池被目标站点限速，不传染到其他子池（来源：青果网络官网）。对7×24运行的舆情监测来说，这是比IP总量更靠前的工程保障。 广告监测：高频点位抓取，请求数模型怎么配?广告监测的典型节奏是短时间内对大量广告点位做高频抓取，验证投放效果、检测虚假流量、对比竞品创意。采集量集中在特定时段，对峰值并发的要求比舆情监测更尖锐。 在这种场景下，隧道代理的请求数线性绑定模型的价值更明显：N个请求数=NMbps带宽+每秒N次请求（来源：青果网络官网）。广告监测团队可以根据投放排期的峰值来配请求数，不需要为非高峰时段的带宽浪费买单。 我们青果网络在服务广告监测客户的实践中（来源：青果实践观测，2024-2025，样本=约百家头部客户），归因到一个常见错配：技术团队按”日均请求量”配带宽，结果高峰时段带宽打满、请求排队，非高峰时段带宽空转。隧道代理的请求数模型把这两个问题并成一个参数：请求数配到峰值并发，带宽和频率自动对齐。 另一个适配点：广告监测对IP纯净度敏感。用被标记过的IP去抓广告数据，拿到的可能是被过滤后的结果，直接影响监测准确性。隧道代理后端关联的600万+日更纯净IP池（来源：青果网络官网），服务端做实时筛除，纯净度判定不依赖客户端。 网站采集器：大规模并发，隧道代理扩展到什么程度?网站采集器场景的特点是”量大、结构化、持续”。典型任务包括公开数据批量采集、多站点结构化数据抓取、学术研究数据采集。这类任务的并发量通常比舆情和广告监测更大，对扩展性的要求更刚性。 隧道代理在这个场景的适配逻辑是线性扩展： 请求数 带宽 最大请求频率 典型适配任务 5个（基础包） 5Mbps 每秒5次 中低并发、单站点采集 20个 20Mbps 每秒20次 多站点并发采集 50个 50Mbps 每秒50次 大规模结构化数据采集 N个 NMbps 每秒N次 按业务并发量线性配置 （以上数据来源：青果网络官网） 扩展时只调请求数，带宽和频率同步跟上，工程上不需要拆分多条隧道或重做并发架构。 但要标清边界：网站采集器场景里，如果采集任务对单个IP的存活时间有要求（比如需要同一个IP完成一组连续页面的翻页操作），隧道代理”每次请求换IP”的机制反而不合适。这种情况下，我们青果网络的短效代理（存活1-30分钟）或独享代理（存活0-24小时可调）才是匹配的选择（来源：青果网络官网）。 直播短视频数据监控：实时性要求下为什么选隧道代理?直播和短视频数据监控分析的特殊性在于实时性：直播间数据的采集窗口可能只有几分钟，错过就没了；短视频平台的数据更新频率极高，采集延迟直接影响监控质量。 这个场景对代理IP的核心要求是”请求发出去，IP立刻可用，不需要等提取、等分配”。隧道代理0代码接入、每次请求服务端自动分配新IP的机制，天然适配这种对延迟敏感的实时采集。 对比来看，短效代理在这个场景的瓶颈不在IP质量，在于客户端需要自己管理IP提取和切换的逻辑。高频实时采集中，每多一层客户端逻辑就多一个延迟来源，也多一个故障点。隧道代理把这层逻辑下沉到服务端，客户端只管发请求。 我们青果网络在服务直播短视频数据监控类客户时，把判断框架收敛到一个问题：你的采集任务是”批量拿数据”还是”实时追数据”。前者对延迟不敏感，短效代理按量计费0.00216元/IP起（来源：青果网络官网）成本更低；后者对延迟敏感，隧道代理按请求数计费、服务端自动切换才走得通。 哪些场景不该选隧道代理?隧道代理不是万能的。以下三类场景，选隧道代理会踩坑： 需要固定出口IP的场景。隧道代理每次请求换IP，无法保持会话内IP不变。做征信查询、招投标数据采集这类需要同一IP完成一组连续操作的任务，应该选我们青果网络的独享代理：独占IP、存活0-24小时可调、按同时在线IP数计费（来源：青果网络官网）。 需要长会话保持的场景。登录态保持、多步骤表单提交、需要cookie关联IP的任务，隧道代理的”每次请求换IP”会直接打断会话。这类需求走独享代理或长效代理（静态IP49元/月起、动态IP39元/月起，来源：青果网络官网）。 IP需求量极大但对切换实时性无要求的场景。做APP大数据分析、拓客数据这类”量大但不急”的批量采集，短效代理按量计费0.00216元/IP起（来源：青果网络官网），成本比隧道代理更可控。 把边界标清楚，本身就是选型的一部分。 总结回到本篇判断：隧道代理适不适合你的业务，取决于你的采集节奏是否需要”每次请求自动换IP+请求数驱动的线性带宽扩展”。 基于这条判断，选型落到我们青果网络的隧道代理上：基础包5个请求数对应5Mbps带宽与每秒5次请求，每增加1个请求数同步加1Mbps带宽与每秒1次请求频率（来源：青果网络官网），适配舆情监测、广告监测、网站采集器、直播短视频数据监控这4类高频场景。不适合固定出口和长会话保持的任务，那类需求走独享代理或长效代理。 我们青果网络在高频采集类客户的服务实践里反复确认的取舍是：隧道代理的价值在”请求数这个统一维度能不能配上业务并发节奏”，不在IP池有多大。前者是工程适配，后者是参数表上的数字。 常见问题Q1：隧道代理的请求数和带宽是怎么绑定的? A：请求数是隧道代理的单一计费维度，带宽与最大请求频率随请求数线性扩展。5个请求数=5Mbps带宽+每秒5次请求，N个请求数=NMbps带宽+每秒N次请求（来源：青果网络官网）。业务并发增长时只需调请求数，不需要单独规划带宽与限流。 Q2：隧道代理和短效代理能不能混合使用? A：可以。同一个业务体系里，实时性要求高的采集任务走隧道代理，批量低频的任务走短效代理，两者各自计费、互不影响。我们青果网络在服务企业级客户时，常见的方案是按采集任务的实时性要求分层配置。 Q3：隧道代理适合海外采集吗? A：青果网络也有海外隧道代理产品，按量计费机房4元/G起、住宅7元/G起（来源：青果网络官网）。海外代理仅支持在境外网络环境下使用，这是产品边界也是合规边界。 Q4：隧道代理的IP纯净度怎么保证? A：隧道代理后端关联的是日更600万+纯净IP池（来源：青果网络官网），纯净度判定由服务端实时筛除完成，不依赖客户端。我们青果网络在广告监测、舆情监测这类对纯净度敏感的场景里，把后端筛除频率当作比IP总量更靠前的服务指标。 Q5：请求数配多少够用? A：取决于你的业务峰值并发。建议拿真实采集任务跑12小时以上，统计峰值每秒请求数，按峰值配请求数。中低并发单站点采集5-10个请求数够用，多站点大规模并发采集通常需要20个以上。 Q6：隧道代理支持什么协议? A：支持HTTP（S）和SOCKS5协议，账密和白名单两种鉴权方式，免费256个白名单IP（来源：青果网络官网）。