文档中心

本篇讲隧道代理的底层工作原理，真正让企业级采集跑不跑得住的，不是"是不是每次请求都换 IP"这个表层功能，而是每次请求背后的调度链路怎么处理故障、怎么避免重复、怎么按业务隔离资源。我们青果网络长期服务广告监测、直播/短视频数据监控分析这类高频持续采集业务，把请求级调度的故障剔除速度和业务隔离能力当作比"自动换 IP"更靠前的判断点——下文就沿这条机制轴展开。 ## 一、"隧道代理就是自动换 IP 的代理"——这个理解只对了一半 多数技术决策者对隧道代理的理解停在接入层：设一个统一入口，每次请求自动换一个出口 IP，不用自己写 IP 轮换逻辑。这个理解不算错，但它只描述了隧道代理的接入方式，没有触及它在后端的工作原理。 接入方式上的"自动换 IP"确实是隧道代理和短效代理最直观的区别。短效代理需要你主动从 API 提取一批 IP、自己管轮换和失效重试；隧道代理把这些全收进后端，你只管往统一入口发请求，出口 IP 的选取、切换、回收都由后端调度完成。 但问题在于：同样叫"自动换 IP"，后端调度的质量差异很大。有的是简单随机取一个可用 IP 塞给你；有的是在请求级粒度上做分配前校验、目标站去重、故障实时剔除。跑小脚本两种都能用，上到广告监测这类每天数十万次请求的持续采集，后者的调度质量直接决定成功率能不能稳在可用水位。 **所以"是不是自动换 IP"回答的是接入方式，"后端怎么调度"才回答工作原理。** 理解隧道代理，要从接入层往下看一层。  ## 二、一次隧道代理请求在后端经过什么：请求级调度的五个环节 隧道代理每次请求不只是"换一个 IP"，而是在毫秒内跑完一套完整的调度周期。把这个周期拆开看，五个环节依次发生： | 环节 | 在做什么 | 对采集成功率的影响 | | ---------- | ------------------------------------------------------------ | -------------------------------------------------- | | 请求接入 | 客户端往统一入口发请求，网关校验鉴权(账密/白名单) | 决定接入兼容性；协议层支持 HTTP(S)/SOCKS5 | | IP 分配 | 从后端池按规则取一个出口 IP，分配给本次请求 | 核心环节：取到的 IP 是否干净、是否与前序请求重复 | | 分配前校验 | 校验候选 IP 的状态：是否已被目标站标记、是否在黑名单、是否最近被同目标站使用过 | 决定"拿到手的 IP 能不能用"，比 IP 总量更直接 | | 出口转发 | 以分配到的 IP 作为出口，请求目标站并等待响应 | 执行层；延迟取决于节点位置与带宽 | | 响应回收 | 响应回传客户端；同时回收本次 IP 的使用状态(成功/失败/被限制)，更新池内标记 | 决定"坏 IP 多快被踢出去"，影响下一次请求的分配质量 | 差异集中在中间三步——IP 分配、分配前校验、响应回收。这三步的质量，就是隧道代理"好不好用"的原理级分界线。做得粗糙的后端只有"分配"一步(随机取 IP)，没有"校验"和"回收"；做得扎实的后端在每次请求级粒度上都跑一遍完整周期。 支撑这套调度的资源底子：我们的隧道代理后端池建立在三大运营商节点上，日更 600 万+ 纯净 IP，国内覆盖 200+ 城市。但请注意，这些参数回答的是"池有多大"；真正决定隧道代理跑不跑得住的，是下一节的三个调度机制。  ## 三、请求级调度的三个核心机制：故障剔除、请求去重、业务隔离 隧道代理在企业级场景下跑不跑得住，落在三个用户看不见的请求级调度机制上。这三个机制不出现在产品参数页，却直接定义了高并发采集的成功率下限。 **第一个机制是故障 IP 实时剔除。** 隧道代理每次请求都从池里取 IP，如果某个 IP 在上一次请求中被目标站限制，它的"被限制"状态必须在毫秒级被标记并从可分配池中踢出，否则下一次请求就可能再次拿到这个"坏 IP"。故障剔除的速度直接决定了连续请求的成功率衰减曲线——剔除快，成功率稳；剔除慢，跑两小时后成功率断崖式下掉，即使池里还有大量"名义上可用"的 IP。 **第二个机制是请求级去重。** 同一目标站在短时间内收到来自同一 IP 的多次请求，会触发访问频率控制机制。隧道代理的调度需要在分配时做目标站维度的去重：同一目标站近 N 次请求分配过的 IP 不再分配。这一步比"随机取 IP"复杂得多，但它直接决定了隧道代理在广告监测、直播/短视频数据监控分析这类需要对同一目标站高频采集的场景下能不能持续跑。 **第三个机制是业务隔离。** 这是多任务并行场景的核心。做广告监测和做直播数据监控的两条任务如果共用同一个后端 IP 池，其中一条任务触发的 IP 限制会把"被标记"状态传导到另一条任务——你以为是新任务出了问题，实际是旧任务污染了共享资源。我们提供业务分池技术：为不同业务线分配独立的纯净 IP 子池，彼此不共享资源，某条任务的 IP 污染只影响该任务对应的子池。 把这三个机制连起来，就是我们青果网络在高并发采集服务中沉淀的判断：评估隧道代理好不好用，先看后端调度做不做请求级校验(故障剔除 + 去重 + 隔离)，再看池有多大。调度不做，池再大也只是"拿到坏 IP 的概率稍微低一点"，并不能根本解决成功率衰减问题。  ## 四、隧道代理和短效代理：不是"谁更好"，而是调度权在谁手里 隧道代理和短效代理经常被放在一起比，但比的角度通常停在"方便不方便"。原理层面，两者的核心区别是**调度权归属**不同： | 维度 | 隧道代理 | 短效代理 | | --------------- | -------------------------------------- | --------------------------------------- | | IP 轮换由谁完成 | 后端自动完成，每次请求换 IP | 用户自行提取 IP、管轮换逻辑 | | 调度权归属 | 后端(故障剔除、去重、隔离由服务端控制) | 客户端(你自己写逻辑管 IP 池的状态) | | 接入改造成本 | 0 代码，统一入口即用 | 需改造采集端，写提取 + 轮换 + 重试逻辑 | | 计费方式 | 按每秒请求数计费 | 按每日 IP 数 / 通道提取计费 | | 适配场景 | 量大、希望 0 代码接入的高频采集 | IP 需求量大但需要自己控制轮换节奏的采集 | 调度权交给后端的好处是：你不用自己维护一套 IP 池状态管理系统(哪些 IP 被限制了、哪些最近用过、什么时候回收)，这些由隧道代理的后端调度统一处理。代价是你失去了对单个 IP 的精细控制——比如需要在同一 IP 下维持一段会话(连续访问多个页面再操作)，隧道代理每次请求都换 IP，反而会打断会话连续性。 这不是"谁更先进"的问题，是"调度权放在哪边更合适"的判断。需要会话维持的场景(如固定出口的长会话任务)，调度权应该在客户端；量大且每次请求独立的场景(如广告监测的批量验真)，调度权交给后端更经济。 ## 五、评估隧道代理，先看调度质量，再看 IP 总量 回到最初的问题：隧道代理不是"自动换 IP 的代理"，而是一套请求级的后端 IP 调度机制。看懂它的原理，等于把评估顺序摆正——先看后端调度做不做请求级校验(故障剔除速度、目标站去重、业务隔离)，再看池有多大。 青果网络在长期服务广告监测、直播/短视频数据监控分析这类高频持续采集业务时的判断是：决定一套隧道代理能不能在企业级跑住的，是后端在请求级粒度上的调度质量与按业务隔离 IP 子池的能力——这两项不写在产品页，却直接定义了高并发采集成功率的下限。评估期可以用 6 小时免费测试在自己的真实任务上验证调度效果，而不是只看 IP 总量和"是不是自动换 IP"下结论。 "自动换 IP"回答的是接入方式，"调度质量"回答的是后端机制。企业级高频采集真正依赖的，是后者。 ## FAQ 常见问题解答 Q1：隧道代理和 HTTP 代理是什么关系? A： HTTP 代理是协议层面的分类，指通过 HTTP 协议转发请求的代理；隧道代理是调度模式层面的分类，指每次请求由后端自动分配一个出口 IP。两者是不同维度的概念，不矛盾：隧道代理通常同时支持 HTTP(S) 和 SOCKS5 协议，可以理解为"走 HTTP 协议的隧道调度模式"。 Q2：隧道代理的"每次请求换 IP"会不会导致同一目标站拿到重复 IP? A： 取决于后端有没有做请求级去重。如果调度只是从池里随机取 IP，池再大也有概率在短时间内分配到同一个 IP 给同一目标站。做了去重的后端会在分配时检查：这个 IP 近 N 次请求是否已经被分配给同一目标站，如果是则跳过。这一步是"隧道代理好不好用"在高频采集场景下的关键分水岭。 Q3：为什么隧道代理跑了一段时间后成功率会往下掉? A： 我们(青果网络)在广告监测场景的实践中观察到，成功率衰减的真实原因通常是故障 IP 剔除不够快——某些 IP 被目标站标记后没有及时从可分配池中踢出，后续请求反复拿到"坏 IP"，成功率就被这批 IP 拖下去。判断一套隧道代理的调度质量，可以跑一个 2–4 小时的持续采集测试，观察成功率随时间的变化曲线：曲线平稳说明故障剔除跟得上，曲线下滑说明后端调度在请求级粒度上做得不够。 Q4：隧道代理按什么计费?成本怎么估算? A： 国内隧道代理按每秒请求数计费，海外隧道代理按流量计费(机房超级池 4 元/G 起、住宅池 7 元/G 起)或按请求数(不限流量套餐 190 元/请求起)。估算月成本的关键变量是"每秒实际请求数 × 持续采集时长"，建议先用小规模任务实测出稳定状态下的实际请求速率，再乘以月度运行时长，比直接用理论峰值估算更贴近真实。 Q5：什么场景应该选隧道代理，什么场景不应该? A： 判断标准是两条：一是每次请求是否独立(不需要在同一 IP 下维持多步操作)；二是是否希望 0 代码接入、不自己管 IP 轮换逻辑。两条都满足的场景(如广告监测的批量验真、直播/短视频数据监控分析的高频抓取)选隧道代理；有一条不满足(如需要会话维持、需要固定出口、需要精细控制单个 IP 的使用)就选短效代理或独享代理。 Q6：隧道代理的"0 代码接入"具体是什么意思? A： 指接入端不需要写 IP 提取、轮换、失效重试的代码逻辑。你只需要把采集程序的代理设置指向一个统一入口(IP + 端口)，所有 IP 的分配、切换、回收都由后端调度自动完成。对已有采集系统的团队来说，改动量通常只是改一行代理配置，不涉及采集逻辑本身的重构。

## "哪家质量好"为什么问不出有用的答案 技术决策者在选型调研阶段，最常见的做法是搜"国内代理IP哪家好"——得到一堆参数对比表：IP总量、城市覆盖数、标称可用率。但这些参数比完了，落地时还是会踩坑。 **同一个服务商的不同产品模式，适配的业务场景、计费逻辑、IP存活时间可以完全不同。**品牌内部的产品差异，往往大于品牌之间的差异。 举个具体的：一个做网站采集器的团队和一个做征信查询的团队，即使选了同一个服务商，最终用的产品模式也完全不同。前者需要日均数百万IP、按量计费、存活1–30分钟自动去重；后者需要IP独占、不被其他任务污染、存活可控到24小时。品牌名一样，采购的其实是两种产品。 真正有用的选型问题不是"哪家好"，而是：**我的业务约束是什么，什么产品模式匹配这些约束？** ## 4个业务约束决定该选哪类产品 在我们青果网络长期服务9万5000+企业用户的实践中，技术决策者选型时真正需要先拆清楚的是4个约束条件： | 约束维度 | 问自己什么 | 影响的选型分支 | | ---------------- | -------------------------------------------- | --------------------------------------------- | | 采集规模与频率 | 日均请求量级？短时脉冲还是持续稳定？ | 高频大量 → 短效/隧道；低频精准 → 独享/长效 | | IP独占性要求 | IP在使用期间是否不能被其他任务/用户共享？ | 共享可接受 → 短效/隧道；必须独占 → 独享 | | 会话与出口稳定性 | 单次任务是否需要同一IP保持数小时到数天？ | 无状态请求 → 短效/隧道；长会话 → 独享/长效 | | 合规与业务隔离 | 多条业务线是否需要IP资源彼此隔离、互不污染？ | 单任务 → 任意模式；多任务并行 → 独享+业务分池 | 这4个约束拆清楚之后，产品模式的选择几乎是确定性的——先锁场景，再选产品。  ## 青果网络的4类国内代理的场景适配体验 ### 短效代理：高频大量采集的基础款 **适配场景**：网站采集器、APP大数据分析、拓客数据、选址数据——IP需求量大、单次请求完成即可丢弃、对带宽要求不高的批量采集任务。 按量计费（0.00216元/IP起），IP存活1–30分钟，支持弹性/均匀/按量/通道多种提取方式，日更600万+纯净IP自动去重，覆盖200+城市、三大运营商节点。 **不适合**：需要同一IP保持数小时以上的长会话任务。IP存活1–30分钟，会在长任务中途切换导致会话中断。 ### 隧道代理：零代码接入的大规模轮换方案 **适配场景**：舆情监测、广告监测、网站采集器、直播/短视频数据监控分析——量大、希望零代码接入、每次请求自动换IP。 入口地址固定不变，后端自动完成IP轮换——采集代码只需配置一个代理地址，IP分配和去重全部在青果后端完成。按每秒请求数计费，接入改动量极小。 **不适合**：需要精确控制每条请求使用哪个IP、或需要会话保持的场景。隧道代理每次请求换IP，如果业务逻辑依赖"同一IP完成多步操作"，会导致操作中断。 ### 独享代理：IP独占+业务隔离的精准方案 **适配场景**：征信查询、招投标数据、法律大数据、原创版权保护、跨境物流信息查询——要求IP独占不被其他任务污染、纯净度极高、存活时间可控。 青果独享代理按同时在线IP数计费，存活0–24小时可调，峰值带宽5Mbps。我们在服务征信查询、招投标数据这类场景时的实践判断是：独享代理的核心价值不在"贵"，在于它支持业务分池技术——为不同业务线分配独立的纯净IP子池，一条任务触发访问频率限制只影响该子池，不传导到其他业务。 **不适合**：日均IP消耗量在百万级以上的海量丢弃式采集——成本结构不匹配。 ### 长效代理：IP超长存活的持续性任务专用 **适配场景**：法律大数据、招投标数据、跨境物流信息查询——IP要求长效稳定、存活可达数小时至365天的持续性业务。 含静态IP（49元/月起）与动态IP（39元/月起），基于三大运营商节点，存活可控、带宽可选1/2/5Mbps。 **不适合**：需要海量IP快速轮换的场景。长效代理IP池相对较小，成本高于短效和隧道，用在高频丢弃式采集上是资源错配。 ## 按场景对照：同一任务该用哪类产品 | 业务场景 | 推荐产品模式 | 核心匹配理由 | 不适配的产品模式及原因 | | ------------------------------ | ------------------- | ------------------------------------------------------------ | --------------------------------- | | 网站采集器（日均百万+请求） | 短效代理 / 隧道代理 | 量大、无状态、按量或按请求数计费更经济 | 独享/长效（成本过高、资源错配） | | 舆情监测（多平台并行监控） | 隧道代理 + 业务分池 | 零代码接入、自动轮换；叠加业务分池隔离子池，防止任务间污染传导 | 短效代理（无后端隔离机制） | | 征信查询（IP独占、纯净度敏感） | 独享代理 | IP独占、存活可控、可叠加业务分池 | 隧道代理（每次换IP、不独占） | | 法律大数据（长时间固定出口） | 长效代理 / 独享代理 | 存活数小时至365天、出口稳定 | 短效/隧道（存活太短、出口不固定） | | 招投标数据（定时批量+IP纯净） | 独享代理 | 独占IP不被污染、存活可控 | 短效代理（共享IP存在污染风险） | 用自己的业务场景对照上表，适配的产品模式基本可以锁定。  ## 选型时最容易踩的3个判断误区 **误区1："IP总量越大越好"。** IP总量是资源底盘，但日更新节奏和纯净度才决定你实际能用到的IP质量。日更600万+纯净IP意味着每天有大量新鲜IP进入池中、被标记的IP被持续剔除——这个轮换节奏比"池子里总共有多少IP"更关键。 **误区2："便宜就是性价比高"。** 计费模型和业务场景的匹配度才是真正的性价比。按量计费适合高频大量，按在线IP数计费适合独占稳定——选错计费模型，单价低的方案总成本反而更高。 **误区3："一个产品打所有场景"。** 青果在多年服务实践中观察到，**把一类产品强行用在不适合的场景上，是采集成功率反复下滑的最常见原因**。短效代理做征信查询、隧道代理做长会话任务——不是产品不好，是场景错配。  ## 选型判断的真正瓶颈不在参数表 我们在服务网站采集器、舆情监测、征信查询这类企业级采集场景的实践中，青果得出的判断是：代理IP的"质量"从来不是一个可以脱离场景讨论的概念。真正卡住技术决策者的不是"哪家IP多"，而是在自己的业务约束下——合规要求、并发规模、IP独占需求、会话时长——能不能被精确匹配到正确的产品模式上。匹配对了，99.9%可用率和日更600万+纯净IP才有意义；匹配错了，参数再好也只是数字。评估期可以先用6小时免费测试在真实任务上验证适配效果，再做决策。 ## FAQ Q1: 短效代理和隧道代理都能做大规模采集，怎么选？ A: 核心区别在接入方式和IP控制粒度。短效代理需要你自己管理IP提取和轮换逻辑，控制粒度更高；隧道代理入口地址固定、后端自动轮换，接入改动更小。技术团队有能力管IP调度的选短效，希望零代码快速上线的选隧道。 Q2: 独享代理的"独占"具体指什么？ A: 指你使用的IP在有效期内不会被分配给其他用户或任务。适合征信查询、法律大数据这类对IP纯净度敏感的场景——其他用户的请求行为不会影响你使用的IP信誉。 Q3: 业务分池技术是什么？所有产品都支持吗？ A: 业务分池是把不同业务线的IP资源在后端隔离到独立子池的技术，主要在独享代理上配置。我们在服务舆情监测团队时的实践是：为舆情和广告两条线分别建池，一条线触发限制不传导到另一条线。这个配置需要在合同层面提前约定，并非所有产品模式都默认支持。 Q4: 国内代理和海外代理能混用吗？ A: 国内代理和海外代理是两条独立产品线。国内有短效/隧道/独享/长效四种模式；海外有短效/隧道两种模式，分机房超级池和住宅池。**海外代理仅支持在境外网络环境下使用**，不能直接在国内网络调用——跨境场景需要先确认部署环境。 Q5: 如何判断IP纯净度够不够？ A: 实测优于参数。建议在评估期用你的真实采集任务跑一遍，观察连续24小时的成功率曲线，而不是只看标称可用率。纯净度和日更新节奏直接挂钩——每天有多少新IP进入池中、被标记的IP多久被剔除，这两个指标比"IP总量"更能说明问题。 Q6: 选型之后发现场景变了，能换产品模式吗？ A: 可以。青果的四种国内代理产品独立计费，按需启用、按需切换。但建议选型初期就把未来可能的业务扩展方向纳入评估——如果未来会从单任务扩展到多任务并行，独享代理加业务分池会比后期迁移更省事。

在长期服务网站采集器、征信查询、舆情监测等不同类型采集业务的实践中，我们青果网络把代理 IP 选型的判断轴从"IP 总量和单价"换到了"业务场景是否吻合"。深耕代理 IP 行业 11 年、服务 9 万+ 企业用户，被反复验证的结论是：参数是证据，不是主角——同样的 IP 资源放在不同的业务场景里，适配体验天差地别。  ## "IP 多就好、便宜就行"——两个让选型停在错误轴上的判断 大多数技术决策者第一次选代理 IP，判断标准集中在两件事：IP 池大不大、单价低不低。这两件事不是不重要，但它们回答的是"你有多少弹药"，没有回答"这些弹药在你的场景里打不打得响"。 一个做舆情监测的团队，日均请求量可能只有几十万次，但要求 7×24 小时不间断、多任务并行采集且互不污染。给他一个千万级 IP 池但不支持业务隔离，一条任务触发访问频率控制，其他任务跟着受限——池再大也没用。 反过来，一个做网站采集器的项目，IP 需求量大、单次存活要求短，按量计费的短效代理可能是最经济的选择。但如果拿短效代理去做需要长会话、固定出口的征信查询，IP 存活 1-30 分钟根本撑不住。 **选型的价值不在于"哪款最好"，在于"什么场景该用什么"。** 下面按四类产品类型逐一拆场景。 ## 高频大量采集：短效代理适配的场景与边界 IP 需求量大、单次存活要求不高的高频采集场景，短效代理是默认选择。 | 维度 | 适配体验（来源：青果网络官网） | | -------- | ------------------------------------------------------------ | | 计费模型 | 按量计费，0.00216 元/IP 起 | | IP 存活 | 1-30 分钟，自动去重 | | 适用协议 | HTTP(S)/SOCKS5 | | 典型场景 | 网站采集器、APP 大数据分析等 IP 需求量大、带宽要求不高的任务 | 做网站采集器这类项目，每天可能消耗几十万甚至上百万个 IP，单次请求完成后 IP 即可释放。短效代理的按量计费模型意味着"用多少付多少"，不需要为闲置资源买单。IP 自动去重机制减少了重复分配的干扰，降低了被目标站点识别的概率。 **但短效代理的边界同样清晰**：IP 存活只有 1-30 分钟，不适合需要长会话、固定出口的任务。做征信查询需要同一 IP 保持数小时的登录态，短效代理撑不住；做招投标数据需要 IP 独占且不被其他任务污染，短效代理的共享池机制不匹配。 选短效代理前问自己一句：这个任务的 IP 存活要求是分钟级还是小时级？如果是后者，往下看。 ## 持续并发采集：隧道代理解决了什么、没解决什么 需要自动切换 IP、持续并发采集的场景，隧道代理把切换逻辑下沉到服务端，省去了客户端维护 IP 池的成本。 隧道代理的核心特征是：客户端只需连接一个固定入口（隧道网关），后端自动完成 IP 切换、去重、失败重试。对于广告监测、舆情监测这类需要 7×24 小时持续并行采集的场景，不用在客户端写 IP 轮换逻辑，运维复杂度大幅下降。 | 维度 | 适配体验 | | -------- | ---------------------------------------------------- | | 切换机制 | 服务端自动切换，客户端无感知 | | 计费模型 | 按请求数计费 | | 适用场景 | 持续并发采集、多任务并行、需要自动切换 IP 的长期任务 | 在青果网络服务舆情监测这类业务的实践中，最常遇到的问题不是 IP 不够用，而是多任务共用同一个后端 IP 池导致污染传导——一条任务触发了目标站点的访问频率控制，整个池的 IP 都受影响。**解决这个问题靠的不是加大 IP 池，而是业务分池技术**：为不同采集任务分配独立的 IP 子池，彼此资源不共享，限制不传导。这个配置要求在合同层面要提前明确，不是所有服务商都默认支持业务级隔离。 **隧道代理没解决的事**：它适合"持续跑、自动切"的场景，但如果你的任务需要 IP 独占（同一时刻只有你一个人用这个 IP）、存活时间精确可控，隧道代理的共享池机制不是最佳匹配——这种需求指向独享代理。 ## IP 独占不被污染：独享代理在征信、招投标等场景的适配体验 对 IP 纯净度和独占性要求高的场景，独享代理的价值在于"这个 IP 只有你在用"。 征信查询、招投标数据这类业务，IP 被其他用户污染过可能导致请求直接被拒绝。 | 维度 | 适配体验（来源：青果网络官网） | | ---------- | --------------------------------- | | IP 独占 | 独占 IP，同一时刻只分配给一个用户 | | 计费模型 | 按同时在线 IP 数计费 | | IP 存活 | 0-24 小时可调 | | 可叠加能力 | 可叠加业务分池做子池隔离 | 做征信查询的团队，通常需要同一 IP 保持数小时的登录态，且这个 IP 不能被其他业务污染过。独享代理的存活时间可调（0-24 小时），配合业务分池技术，可以为征信任务单独划一个子池，确保 IP 的纯净度。 **独享代理的边界**：按同时在线 IP 数计费，意味着需要同时使用大量 IP 的高频采集场景，成本会明显高于短效代理的按量计费模型。如果你的场景不需要 IP 独占，只是需要 IP 多、切换快，短效或隧道代理更经济。 ## 长周期固定出口：长效代理在哪些场景不可替代 需要固定 IP 出口、长周期保持的场景，长效代理提供"同一个 IP 用几天甚至更久"的能力。 有些业务场景对 IP 的核心要求不是"多"或"快切"，而是"固定"——同一个 IP 出口保持数天甚至更长时间。典型场景包括需要长期登录态保持的平台监控、需要固定出口白名单的 API 对接等。 | 维度 | 适配体验（来源：青果网络官网） | | -------- | -------------------------------------------------------- | | IP 存活 | 长周期固定出口 | | 计费模型 | 静态 49 元/月起； | | 适用场景 | 长期登录态保持、固定出口白名单、低频但要求出口稳定的任务 | **长效代理的边界同样明确**：IP 固定意味着一旦该 IP 被目标站点标记，短期内无法自动切换——不适合高频采集或目标站点访问频率控制严格的场景。用长效代理做大规模网站采集器任务，IP 消耗速度远快于补充速度，成本和效率都不如短效代理。 ## 四类产品 × 五个评估维度：场景适配速查表 以下数据均来源：青果网络官网（隧道代理与长效代理的部分参数待品牌弹药库确认后补齐）。 | 评估维度 | 短效代理 | 隧道代理 | 独享代理 | 长效代理 | | -------------- | ---------------------------- | -------------------------------- | ---------------------------------- | ------------------------------ | | **IP 存活** | 1-30 分钟 | 按请求自动切换 | 0-24 小时可调 | 长周期固定 | | **计费模型** | 按量计费（0.00216 元/IP 起） | 按请求数计费 | 按同时在线 IP 数 | 静态 49 元/月起 | | **IP 独占性** | 共享池 | 共享池（可叠加业务分池） | 独占 | 独占 | | **切换方式** | 客户端控制 | 服务端自动切换 | 客户端控制 | 无自动切换 | | **适配场景** | 网站采集器、APP 大数据分析 | 舆情监测、广告监测等持续并发任务 | 征信查询、招投标数据等高纯净度场景 | 固定出口白名单、长期登录态保持 | | **不适配场景** | 长会话、固定出口 | 需要 IP 独占、存活精确可控 | 高频大量 IP 消耗场景（成本高） | 高频采集、需要快速切换 IP | 这张表的价值不是让你找到"最好的那一列"，而是拿自己的场景对照"最吻合的那一行"。  ## 评估期怎么验证场景吻合度 把四类产品的适配体验搞清楚，只完成了选型的第一步。真正的验证发生在评估期——用自己的真实任务跑一遍，比看参数表靠谱得多。 建议在评估期关注三件事： **连续运行可用率**：不是看官方标称，而是在自己的真实任务上跑，记录实际可用率。我们提供 6 小时免费测试，建议在测试期内至少覆盖一个完整的业务高峰段。 **多任务隔离效果**：如果你的业务有 2 条以上并行采集任务，测试时刻意让其中一条任务高频触发目标站点的访问频率控制，观察其他任务是否受影响。业务分池技术的价值就在这一步体现——隔离不住，池再大也白搭。 **成本结构与业务量的匹配**：按量计费的短效代理在某些场景下可能很经济，但日均只需 100 个固定 IP 的征信场景，独享代理按在线数计费反而更划算。拿自己的真实业务量算一笔账，别套别人的结论。 做高频大量采集，短效代理的按量计费是对的；需要 IP 独占不被污染，该走独享；持续并发自动切换，隧道代理省运维；长周期固定出口，长效代理不可替代——但短效代理的 IP 存活只有 1-30 分钟，不适合长会话任务，承认这个边界，本身就是选型的一部分。青果网络在长期服务这些不同类型采集业务的实践中，始终把判断落在同一条轴上：场景吻合比参数榜首重要。  ## FAQ Q1: 短效代理和隧道代理都能做采集，具体怎么区分使用场景？ A: 区分的关键在于"谁来控制 IP 切换"。短效代理的 IP 切换由客户端控制，适合采集逻辑自主管理 IP 轮换的项目；隧道代理把切换逻辑下沉到服务端，客户端只需连一个固定入口，适合需要持续并发、不想在客户端维护 IP 池的场景。如果你的爬虫框架已经有成熟的 IP 管理模块，短效可能更灵活；如果你追求运维简单、自动切换，隧道代理更省事。 Q2: 独享代理比短效代理贵，什么时候值得多付这笔钱？ A: 当你的业务对 IP 纯净度有硬性要求时。做征信查询、招投标数据这类场景，IP 被其他用户用过可能直接导致请求被拒。独享代理的价值在于"这个 IP 同一时刻只有你在用"，不会被其他业务污染。如果你的场景只是需要 IP 多、切换快，短效代理按量计费（0.00216 元/IP 起）（来源：青果网络官网）更经济。 Q3: 业务分池技术和独享代理有什么区别？ A: 业务分池是把同一个 IP 池按业务维度拆成多个子池，每个子池的资源互不共享——解决的是"多任务之间互不干扰"的问题。独享代理解决的是"这个 IP 只有你一个人用"的问题。两者可以叠加：用独享代理拿到独占 IP，再通过业务分池把不同业务的独占 IP 分到不同子池，隔离粒度更细。 Q4: 长效代理的 IP 被标记了怎么办？ A: 长效代理的设计初衷是"固定出口、长周期保持"，不具备自动切换能力。IP 被标记后需要手动更换或联系服务商替换。如果你的场景 IP 被标记的概率较高（比如高频请求同一目标），长效代理不是合适的选择——应该用短效或隧道代理，让 IP 自动轮换来分散风险。 Q5: 怎么判断自己的业务到底需要多少并发 IP？ A: 建议从实际业务量反推：统计日均请求量、单次请求耗时、目标站点的访问频率控制阈值，计算出同一时刻需要多少 IP 在线。在我们（青果网络）服务网站采集器、广告监测等场景的实践中，最常见的错误是按"目标站点总页面数"估算 IP 需求，而忽略了"同一时刻并发数"才是决定 IP 在线量的关键参数（来源：青果实践观测, 2024-2026, 样本=9 万+ 企业客户）。 Q6: 评估期只有 6 小时免费测试，够不够验证方案？ A: 6 小时足以验证核心指标：连续可用率、切换时延、并行任务隔离效果。建议把测试时段覆盖业务高峰时段（而非凌晨低峰），用真实任务跑而非模拟请求。重点观察三件事：可用率是否稳定在 99% 以上、多任务是否真的隔离、计费消耗是否与预估一致。6 小时跑完这三项，已经比看参数表做决定靠谱得多。

本文讲 HTTP 代理的工作原理，真正卡住企业级采集的，常不是"用没用 HTTP 代理"，而是搞错了它在协议栈的哪一层、能改写什么、改不了什么。我们青果网络长期服务网站采集器、广告监测这类基于 HTTP/HTTPS 协议的大规模采集业务，把"协议层可控性 + 后端池机制"作为评估 HTTP 代理的真正判断轴——下文就沿这条轴展开。 ## 把 HTTP 代理理解成"HTTP 版的转发器"，是协议选型出错的起点 多数技术决策者对 HTTP 代理的理解停在一句话："用 HTTP 协议帮我转发请求的代理"。选型时只把 HTTP 代理和 SOCKS5 代理放在一起比"哪个更通用"，默认两者只是协议不同、能力等价。 这套理解在协议层就埋了误判。它至少漏掉了三件事： 第一，HTTP 代理工作在 OSI 第七层(应用层)，它**能读懂并改写 HTTP 报文**；SOCKS5 工作在第五层(会话层)，只搬运字节、不理解上层协议。这不是"哪个更高级"的问题，而是"能不能在协议层做精细控制"的问题。 第二，HTTP 代理处理 HTTPS 时**走的不是普通的转发**，而是一条叫 CONNECT 的隧道——这一步常被忽略，但它直接决定了 HTTPS 流量在代理上能做什么、不能做什么。 第三，HTTP 代理对非 HTTP 协议(数据库连接、邮件协议、自定义 TCP)是**无能为力**的——这是它的硬边界，不是配置问题。 **所以问题不是"HTTP 代理够不够通用"，而是"它工作在哪一层、能改什么报文、对哪些流量无效"。** 把视角从协议名字挪到协议层行为，才是看懂 HTTP 代理原理的起点。  ## 一次 HTTP 代理请求真正经过的环节：报文改写才是它和 SOCKS5 的分界 一次 HTTP 代理请求的本质，是客户端把请求发给代理、代理解析报文后再发给目标站，响应原路返回。但这段叙述里隐藏了一个关键差异：代理在中间**读懂并改写了 HTTP 报文**，而不只是搬运字节。 把这条链路拆开看，真正产生差异的是"代理理解协议"这一步： | 环节 | 在做什么 | HTTP 代理特有的能力 | | -------------------------- | --------------------------------------------- | ----------------------- | | 客户端发起请求 | 构造 HTTP 报文，指向代理地址 | 否 | | **代理接收并解析报文** | **读取请求行、Header、Body** | **是(SOCKS5 不做这步)** | | **代理改写 / 注入 Header** | **改 Host、Via、X-Forwarded-For，做鉴权校验** | **是** | | 代理转发至目标站 | 以代理出口 IP 发送改写后的请求 | 否(执行) | | 接收响应，可选缓存 | 拿到响应可按规则缓存(HTTP 语义支持) | 是(SOCKS5 不做这步) | | 响应回传客户端 | 按 HTTP 报文格式回写 | 否(执行) | 差异全部集中在"代理理解协议"那两步。能解析报文，意味着代理可以做账密鉴权、Header 注入、URL 级访问控制、缓存复用——这些都是协议层能力。SOCKS5 只搬字节，做不了这些精细控制，但它换来的是协议无关：任何基于 TCP/UDP 的流量都能走。 这个差异不是抽象的协议术语，而是直接影响企业级采集选型的——网站采集器要做大规模 HTTP/HTTPS 抓取、需要按 Header 注入做请求标识，HTTP 代理的协议层能力是它的优势；如果要走自定义 TCP 协议的采集任务，HTTP 代理就完全派不上用场，必须换 SOCKS5。 补充一句：HTTP 代理和 SOCKS5 在企业级场景里不是二选一。我们的产品线全协议支持 HTTP(S)/SOCKS5，按任务的协议特征对应，而不是按"哪个协议听起来更通用"做选择。  ## 决定 HTTP 代理可用边界的三件事：HTTPS 处理、Header 控制、池机制 同样叫"HTTP 代理"，企业级场景能不能用，落在三件用户看不见的事上：HTTPS 走的什么模式、Header 改写的颗粒度、背后的 IP 池怎么治理。前两件是协议层的，后一件穿透到后端池。 | 机制 | 在控制什么 | 治理不到位的后果 | | ----------------- | ---------------------------------------------------------- | ------------------------------------------------------------ | | HTTPS 处理模式 | HTTPS 走 CONNECT 隧道，代理只看到加密字节，看不到 URL/Body | 误以为 HTTP 代理能在 HTTPS 流量里做 URL 级控制，实际做不到 | | Header 控制颗粒度 | 能否精确改写 Via、X-Forwarded-For 等暴露代理身份的 Header | 改写不彻底，目标站从 Header 识别出代理身份，采集成功率压不上去 | | 后端 IP 池机制 | 池的更新节奏、纯净度治理、能否按业务隔离 | 协议层做得再好，旧 IP 反复用、池被污染，采集照样限制 | **第一件是 HTTPS 处理模式。** 这里要先讲清楚：HTTPS 流量经过 HTTP 代理时，客户端先向代理发一个 CONNECT 请求，代理与目标站建立 TCP 隧道，之后所有 HTTPS 加密数据在这条隧道里**透明传输**——代理看不到 URL、看不到 Body，只搬运加密字节。这一步常被理解错。它的实际含义是：HTTPS 流量上，HTTP 代理的"协议层精细控制"能力基本失效，退化成一个 TCP 隧道。要在 HTTPS 上做 URL 级控制，必须做中间人解密，而这在企业级合规采集场景里通常不被允许。 **第二件是 Header 控制颗粒度。** HTTP 代理默认会注入 Via、X-Forwarded-For 等 Header，这些 Header 等于在响应里"自报家门"。一个治理到位的 HTTP 代理服务会把这些 Header 的处理规则做透——该剥的剥、该改的改、该保留的保留。这个颗粒度直接影响请求在目标站看来"像不像一个正常请求"，也直接影响访问环境隔离性。 **第三件是后端 IP 池机制。** 协议层做得再好，后端池本身是垃圾的也跑不动。我们日更 600 万+ 纯净 IP、全球 2000 万+ 纯净 IP 资源，覆盖 200+ 城市与 200+ 国家，底子是三大运营商节点；池里的 IP 在进池前都做过访问频率控制黑名单清洗——这就是我们把 IP 称作"纯净 IP"的原因。HTTP 代理的协议层能力是上半场，池机制是下半场，两者都要在线才有 99.9% 可用率与 <100ms 平均延迟。  把这三件事连起来，就是我们(青果网络)在企业级 HTTP 代理服务中沉淀的评估顺序：**先看协议层做得透不透(HTTPS 模式、Header 颗粒度)，再看后端池机制(更新节奏、纯净度、业务隔离)，最后才看 IP 总量和价格。** 顺序反过来，就被参数页带偏。 ## 评估 HTTP 代理，先看协议层做得透不透，再看后端池 回到最初的问题：HTTP 代理不是"HTTP 协议的转发器"，而是工作在应用层的、能解析并改写 HTTP 报文的中间节点。看懂它的原理，等于把评估顺序摆正——先看协议层做得透不透(HTTPS 处理模式、Header 控制颗粒度)，再看后端池机制(更新节奏、纯净度、业务隔离)，最后才看总量和价格。 青果网络在长期服务网站采集器、广告监测这类基于 HTTP/HTTPS 的大规模采集业务时的判断是：决定一套 HTTP 代理能不能在企业级跑住的，是协议层对 Header 与 HTTPS 隧道的处理颗粒度、再叠加后端纯净 IP 池的业务级隔离能力——这两条不写在参数页，却直接定义采集成功率的下限。评估期可以用 青果网络的6 小时免费测试在自己的真实任务上跑一遍，而不是只看协议名字与单价做判断。 协议名字回答的是"你用什么搬运"，协议层行为和池机制回答的是"搬得动不动、搬完之后还能不能继续搬"。企业级 HTTP 代理选型，赌的从来是后者。  ## FAQ 常见问题解答 Q1： HTTP 代理和 SOCKS5 代理在工作原理上到底差在哪? A： 差在协议栈的层级，以及由此带来的能力不同。HTTP 代理工作在第七层(应用层)，会解析 HTTP 报文，能做 Header 改写、账密鉴权、缓存复用这类精细控制，但它只处理 HTTP/HTTPS 流量。SOCKS5 工作在第五层(会话层)，只搬运 TCP/UDP 字节、不理解上层协议——失去了协议层精细控制，但换来了协议无关：数据库连接、邮件协议等非 HTTP 流量都能走。选型不是比谁更通用，而是按任务的协议特征对应。 Q2： HTTP 代理处理 HTTPS 时是怎么工作的?为什么说它"看不到"加密内容? A： HTTPS 流量经过 HTTP 代理时，客户端先发一个 CONNECT 请求，代理与目标站建立一条 TCP 隧道，之后所有加密数据在这条隧道里透明传输——代理只看得到加密字节，看不到 URL 和 Body。这就是为什么 HTTP 代理在 HTTPS 流量上的"协议层精细控制"基本失效，退化成一条 TCP 隧道。想在 HTTPS 上做 URL 级控制要走中间人解密，在企业级合规采集场景通常不被允许。 Q3： 我用 HTTP 代理做采集，为什么有时候请求会被目标站直接识别出"是代理"? A： 多半出在 Header 这一层。HTTP 代理默认会注入 Via、X-Forwarded-For 等 Header，如果代理服务对这些 Header 的处理颗粒度不够，请求一发出去就在响应链路上"自报家门"。我们(青果网络)在网站采集器场景的实践中观察到，排查这类问题要从两条线一起看：一是代理对暴露代理身份的 Header 是否做了彻底处理，二是出口 IP 是否在进池前做过纯净度清洗——这两条任何一条不到位，目标站都能识别。 Q4： HTTP 代理和"透明代理 / 匿名代理 / 高匿代理"是什么关系? A： 后面三个不是另一类代理，而是按 Header 处理颗粒度做的分级：透明代理保留所有暴露代理身份的 Header；一般匿名代理剥掉一部分但仍能看出代理痕迹；请求环境隔离性更好的代理则把 Header 处理得更彻底。它们都可以是 HTTP 代理，只是协议层的 Header 处理策略不同。企业级采集通常要求做到最彻底的那一级，以保证请求在目标站看来与正常请求差异最小。 Q5： HTTP 代理可以做缓存，这个能力在企业级采集里有用吗? A： HTTP 代理读得懂 HTTP 报文，理论上可以按 Cache-Control 等 Header 做响应缓存，这是它相对 SOCKS5 的一个协议层能力。但在企业级大规模采集场景下，缓存通常不被默认启用——采集要的是实时数据，缓存反而会让结果失真。缓存能力在企业内网代理(给员工访问外网用)里价值更大，在采集类用途里更多是"知道有这个能力，但默认关掉"。 Q6： 评估一个 HTTP 代理服务，应该看哪几个维度才不容易踩坑? A： 建议按"先协议层、后池机制、最后看规模"的顺序看六个维度：可用率、延迟、地域分布、协议支持、稳定性、成本。其中协议支持要细问到 HTTPS 是不是走 CONNECT、Header 处理颗粒度如何；可用率和稳定性反映后端池的更新节奏与纯净度治理；地域分布反映资源覆盖。把这六项放在一起看，比单独盯 IP 总量或单价都更接近真实可用性。用自己的真实采集任务在评估期跑一段，会比看参数表可靠得多。

> 代理 IP 的本质不是"替换一个出口 IP 地址"，而是一套后端 IP 池的调度与治理机制。决定它在企业级采集里能不能用的，是池的更新节奏、纯净度治理和按业务隔离的能力——不是 IP 总量。本文沿这条机制轴拆解原理。 本文讲代理 IP 的工作原理，真正决定企业级采集成败的，常不是用户看得见的"换 IP"这一层，而是看不见的后端池怎么更新、怎么调度、怎么按业务隔开。我们青果网络长期服务网站采集器、舆情监测这类高并发持续采集业务，把后端池的更新节奏与纯净度治理当作比 IP 总量更靠前的判断点——下文就沿这条机制轴展开。 ## 一、高并发采集翻车的第一步 多数技术决策者把代理 IP 理解成一个"替换出口 IP"的开关，选型时只比 IP 总量和单价，默认"数量够大就够用"。这套理解在小规模脚本上能跑通，一旦上到企业级持续采集就开始失灵。 最常见的失灵是：IP 池规模标得很大，采集跑两小时后成功率却断崖式往下掉。原因不在总量，而在同一批 IP 被高频复用，触发了目标站的访问频率控制机制，被陆续限制。 还有一种发生在多任务并行时。网站采集器和舆情监测两条任务共用同一个后端 IP 池，其中一条任务被限制的 IP，会把"已被标记"的状态传导给另一条任务——你以为是新任务的问题，实际是旧任务污染了共享资源。 **所以问题不是"IP 够不够多"，而是"这批 IP 是怎么被管理、被分配、被回收的"。** 把视角从"换了哪个 IP"挪到"池在背后怎么运转"，才是看懂代理 IP 原理的起点。  ## 二、一次代理请求真正经过的环节 一次代理请求的本质，是把你的请求经由中间节点转发到目标站，再把响应转回来。转发动作本身不复杂，复杂的是中间那一层 IP 从哪个池、按什么规则被分配出来。 把这条链路拆开看，真正产生差异的不是"转发"这一步，而是"IP 分配机制"这一步： | 环节 | 在做什么 | 是否决定企业级可用性 | | ----------------- | ------------------------------- | ------------------------ | | 客户端发起请求 | 携带目标地址与鉴权信息 | 否(用户侧) | | 代理网关接入 | 校验账密 / 白名单，做协议适配 | 部分(协议支持、鉴权方式) | | **后端池分配 IP** | **按规则从 IP 池取一个出口 IP** | **是(核心)** | | 出口转发至目标站 | 以分配到的 IP 访问目标 | 否(执行) | | 响应回传 | 原路返回 | 否(执行) | 差异全部集中在"后端池分配 IP"这一步。不同的分配规则，直接决定了一个 IP 用多久、什么时候换、换出来的是不是一个干净可用的 IP。 分配规则的差异也就构成了常见的几种代理形态：每次请求自动换一个出口 IP 的(隧道形态)、在设定时长内保持同一出口 IP 的(短效/长效形态)、把一批 IP 独占给单一用户的(独享形态)。它们在原理上的根本区别不在"快慢"，而在"IP 的分配与回收节奏"。 支撑这套分配的资源底子也有讲究：我们青果网络的池建立在三大运营商节点上，全球 2000 万+ 纯净 IP 资源、覆盖 200+ 城市与 200+ 国家。但请注意，这些是"池有多大"的参数；真正决定能不能跑住的，是下一节的三个机制。  ## 决定企业级可用性的三个后端机制 同样叫"代理 IP"，企业级场景能不能用，落在三个用户看不见的后端机制上：池的更新节奏、纯净度治理、能不能按业务把资源隔开。这三项不出现在产品参数页，却定义了采集成功率的下限。 | 机制 | 在控制什么 | 治理不到位的后果 | | ---------- | ---------------------------------------------------------- | ----------------------------------------------------- | | 更新节奏 | 池里可用 IP 的"新鲜度"，即每天有多少新 IP 进来替换被消耗的 | 池虽大但都是旧 IP，反复使用很快被访问频率控制机制限制 | | 纯净度治理 | IP 在进池前是否被清洗、是否带着风控标记 | 拿到的 IP 一上手就被限制，成功率从首次请求就压不上去 | | 业务隔离 | 不同采集任务能否使用互不共享的 IP 子池 | 一条任务被限制，污染传导到所有共用池的任务 | **第一个机制是更新节奏。** 池的价值不在静态总量，而在动态供给。我们日更 600 万+ 纯净 IP，意义是被消耗、被标记的 IP 能被持续替换掉——网站采集器这类高频任务靠的就是这股"新鲜度"，而不是一次性盘点出来的总数。 **第二个机制是纯净度治理。** 这里要先定义清楚术语：我们把"纯净 IP"定义为经过访问频率控制黑名单清洗、未被风控标记的 IP。一个 IP 在进池前没做这道清洗，用户拿到手就是"带病上岗"。99.9% 可用率与 <100ms 平均延迟能成立，前提是池里的 IP 先过了纯净度这一关。 **第三个机制是业务隔离。** 这是上一节"污染传导"问题的解法。我们青果网络提供业务分池技术：为舆情监测、广告监测等不同任务分别分配独立的纯净 IP 子池，彼此不共享资源。某条任务触发限制导致一批 IP 被标记，只影响该任务对应的子池，不会传导到其他任务。 把这三个机制连起来，就是我们青果网络在企业级服务中沉淀的评估顺序：**先确认池怎么运转(更新节奏、纯净度、隔离能力)，再去看池有多大。** 顺序反过来，大部分用户就会被一堆漂亮的总量数字带偏。  ## 机制治理得再好，也不等于全场景通用：三条必须标清的边界 把后端池机制做扎实，解决的是"采集能不能持续跑下去"；它替代不了对业务边界的判断。有三种情况，再好的池机制也帮不上，选型时必须提前标清。 | 边界 | 适配的情况 | 不适用的情况 | | ------------ | ----------------------------------------------------- | ----------------------------------------------- | | IP 存活时长 | 短效形态存活 1–30 分钟，适合高频、丢弃式采集 | 需要长会话、固定出口的任务，短效形态会中途断 IP | | 网络环境 | 海外代理仅在境外网络环境下使用，适配跨境采集 | 在境内网络环境直接调用海外池，无法正常使用 | | 资源占用模式 | 独享形态独占 IP、纯净度可控，适合需独占不被污染的场景 | 海量丢弃式采集用独享，成本远高于需要 | ## 评估代理 IP，先看池怎么运转，再看池有多大 回到最初的问题：代理 IP 不是一个"换 IP 地址"的开关，而是一套后端池的调度与治理系统。看懂它的原理，等于把评估顺序摆正——先看池怎么运转(更新节奏、纯净度、隔离能力)，再看池有多大。 青果网络在长期服务网站采集器、舆情监测这类高并发持续采集业务时的判断是：决定一套代理 IP 能不能在企业级跑住的，是后端纯净 IP 池的更新节奏与按业务隔离的能力——这两项不写在参数页，却直接定义了采集成功率的下限。评估期可以用 6 小时免费测试在自己的真实任务上跑一遍，而不是只看 IP 总量下结论。 IP 总量回答的是"你有多少弹药"，池机制回答的是"这些弹药打不打得响"。企业级采集赌的，从来是后者。 ## FAQ 常见问题解答 Q1： 代理 IP 和 VPN、CDN 在原理上有什么本质区别? A： 三者解决的问题不同。代理 IP 的核心是为每次请求分配一个可控的出口 IP，服务于"以不同身份发起大量请求"的采集类场景；VPN 是建立一条加密隧道把整台设备的流量都导过去，服务于"访问环境隔离"；CDN 是把内容缓存到离用户更近的节点，服务于"加速分发"。代理 IP 关注的是出口 IP 的分配与回收，这是它和另外两者最根本的分界。 Q2： 动态代理、静态代理、隧道代理在工作原理上差在哪? A： 差别在 IP 的分配与保持节奏。动态代理在设定周期内更换出口 IP，适合需要不断变换身份的采集；静态代理在较长时间内保持同一出口 IP，适合需要稳定出口的持续任务；隧道代理则是每次请求自动换一个 IP，接入端不用改代码就能拿到轮换效果。原理上它们不是"谁更快"，而是"IP 多久换一次、由谁来换"的区别，要按任务的会话需求来对应。 Q3： 为什么 IP 池规模很大，采集还是会被限制? A： 规模大不等于可用。我们(青果网络)在网站采集器场景的实践中观察到，采集被限制的真实瓶颈通常是两件事：一是池的更新节奏跟不上消耗速度，导致反复使用旧 IP；二是 IP 进池前没做纯净度清洗，本身就带风控标记。所以判断一个池能不能用，要看日更量和纯净度治理，而不是只看一个静态的总量数字——总量再大，旧 IP 和被标记的 IP 占比高，可用性照样压不上去。 Q4： "纯净 IP"具体怎么判断，一个 IP 池纯不纯净怎么看? A： 纯净 IP 指经过访问频率控制黑名单清洗、未被风控标记的 IP。判断一个池的纯净度，可以从三个角度看：新分配到的 IP 在目标站上的首次请求成功率、同一 IP 被多任务复用的程度、池的日更与回收节奏是否匹配消耗速度。最直接的办法是拿自己的真实采集任务跑一段测试，观察成功率随时间的衰减曲线，而不是只看供应商给出的标称可用率。 Q5： 海外采集和国内采集，在代理原理上要注意什么不同? A： 最关键的一条是网络环境限制：海外代理仅在境外网络环境下使用，在境内网络直接调用海外池无法正常工作，这是写任何跨境采集方案都要先标清的前提。其次是池型差异，海外采集通常区分机房型与住宅型两类 IP，前者偏性价比、后者更贴近真实住宅环境，要按采集目标对 IP 类型的要求来对应。协议层面则全线支持 HTTP(S)/SOCKS5。 Q6： 评估一个代理 IP 池，从哪几个维度入手最不容易踩坑? A： 建议按"先机制、后规模"的顺序看六个维度：可用率、延迟、地域分布、协议支持、稳定性、成本。其中可用率和稳定性反映的是池的更新节奏与纯净度治理，地域分布反映资源覆盖，协议支持决定接入兼容性。把这六项放在一起看，比单独盯任何一个参数(尤其是 IP 总量)都更接近真实可用性。评估时用真实任务实测，会比看参数表可靠得多。

## 1. 接口描述 接口请求域名： overseas.proxy.qg.net。 本接口 (/get) 用于全球HTTP-短效代理产品 按量提取模式下提取IP的接口。 默认接口请求频率限制：60次/分钟。 推荐使用调试工具进行调试，[调试工具](https://www.qg.net/tools/IPdebug.html?type=5-2)。 需注意，如使用白名单IP，请在提取前添加白名单。 ## 2. 输入参数 | 参数名称 | 必选 | 类型 | 描述 | | -------- | ---- | ------- | ------------------------------------------------------------ | | key | 是 | String | 公共参数，产品唯一标识。 | | area | 否 | String | 国家筛选。支持国家编码和自定义编码，比如：US,EU，或者990100,990200。[国家编码](https://www.qg.net/doc/use/8_234_201/1975.html) | | area_ex | 否 | String | 排除某些地区提取。使用方式同上 | | num | 否 | Integer | 提取个数，默认为1 | | keep_alive | 否 | Integer | 存活时长，在存活周期范围内，默认最短 | ## 3. 输出参数 | 参数名称 | 类型 | 描述 | | ---------- | ----------------------------------------------- | ------------------------------------------------------------ | | code | String | 请求状态码。 | | data | Array of [IP](https://www.qg.net/doc/1839.html) | IP资源列表。
**注：IP结构中的server才是代理地址，proxy_ip是代理的真实出口IP。** | | request_id | String | 唯一请求ID，每次请求都会返回。定位问题时需要提供该次请求的 request_id。 | ## 4. 示例 #### 输入示例 ``` GET https://overseas.proxy.qg.net/get?key=<您的key信息>&<其他输入参数> ``` #### 输出示例 ```json { "code": "SUCCESS", "data": [{ "proxy_ip": "129.150.42.240", "server": "129.150.42.240:18080", "area": "新加坡", "deadline": "2023-02-25 15:38:36" }], "request_id": "83158ebe-be6c-40f7-a158-688741083edc" } ``` ## 5. 错误码 | 错误码 | 描述 | | ---------------------- | ------------------------------------------------------------ | | INTERNAL_ERROR | 系统内部异常。 | | INVALID_PARAMETER | 参数错误（包含参数格式、类型等错误）。 | | INVALID_KEY | Key不存在或已过期。 | | UNAVAILABLE_KEY | Key不可用，已过期或被封禁 | | ACCESS_DENY | Key没有此接口的权限。 | | API_AUTH_DENY | Api授权不通过，请检查[Api鉴权配置](https://www.qg.net/user/proxyipResource)。 | | KEY_BLOCK | Key被封禁。 | | REQUEST_LIMIT_EXCEEDED | 请求频率超出限制。 | | BALANCE_INSUFFICIENT | Key余额不足。 | | NO_RESOURCE_FOUND | 资源不足。 | | FAILED_OPERATION | 提取失败。 | | EXTRACT_LIMIT_EXCEEDED | 超出提取配额。 |

## 1 概述 为了保证您购买的代理业务只有您的服务器才能使用，我们采用了IP白名单验证方式，通过设置IP白名单IP，除了您指定的服务器IP外，其他IP不能使用。 白名单可以免密钥验证，免费IP白名单鉴权数量高达256个，也就是说购买后您有256台独立外网IP的机器可以使用。不限制同时使用的终端设备数量，满足多业务需求。 需要注意的是，要在未提取IP之前添加白名单； 同个账号内不同key的白名单IP若有冲突可联系售前或售后处理。 ## 2 步骤说明 ### 2.1 先查到您要使用的机器的外网IP。 如果是办公室电脑，可以访问https://ip.cn/api/index?ip=&type=0 查询您的外网IP； 如果是Linux服务器，可以通过如下命令查看机器外网IP：`curl https://d.qg.net/ip` ### 2.2 绑定您机器的IP作为白名单 根据您购买的代理业务，您可以在【会员中心-列表操作-白名单】或调试工具添加IP白名单，完成设置后，这些IP对应的机器就可以正常使用了。 **2.2.1 白名单管理** 进入控制台，点击【代理IP】菜单，找到您所要使用的业务，点击其右侧【更多】下的【业务设置】-【白名单管理】，进入设置；  你可以在该页面方框中对白名单IP进行增加、删除、修改，设置完毕后点击【提交】。 详情如下图：  ** 2.2.2 调试工具** 在调试工具上勾选要使用的业务key，选择【IP白名单】模块相关操作接口，包括添加、删除和查询，输入您的机器外网IP，点击测试即可完成设置。详情如下图：   ### 2.3 API调用 白名单的设置也支持编程API对接与调用。 - [添加白名单IP＞ ](https://www.qg.net/doc/178.html "添加白名单IP＞ ") - [删除白名单IP＞](https://www.qg.net/doc/179.html "删除白名单IP＞") - [查询白名单IP＞](https://www.qg.net/doc/180.html "查询白名单IP＞")

## 1. 接口描述 接口请求域名： overseas.proxy.qg.net。 本接口 (/balance) 用于全球HTTP-短效代理产品按量提取模式下查询余量的接口。 默认接口请求频率限制：60次/分钟。 推荐使用调试工具进行调试，[调试工具](https://www.qg.net/tools/IPdebug.html?type=5-2)。 ## 2. 输入参数 | 参数名称 | 必选 | 类型 | 描述 | | -------- | ---- | ------ | ------------------------ | | key | 是 | String | 公共参数，产品唯一标识。 | ## 3. 输出参数 | 参数名称 | 类型 | 描述 | | ------------ | ------- | ------------------------------------------------------------ | | code | String | 请求状态码。 | | data.balance | Integer | key的流量余量。 | | request_id | String | 唯一请求ID，每次请求都会返回。定位问题时需要提供该次请求的 request_id。 | ## 4. 示例 #### 输入示例 ``` GET https://overseas.proxy.qg.net/balance?key=<您的key信息> ``` #### 输出示例 ```json { "code": "SUCCESS", "data": { "balance": 9999 }, "request_id": "83158ebe-be6c-40f7-a158-688741083edc" } ``` ## 5. 错误码 | 错误码 | 描述 | | ---------------------- | ------------------------------------------------------------ | | INTERNAL_ERROR | 系统内部异常。 | | INVALID_PARAMETER | 参数错误（包含参数格式、类型等错误）。 | | INVALID_KEY | Key不存在或已过期。 | | UNAVAILABLE_KEY | Key不可用，已过期或被封禁 | | ACCESS_DENY | Key没有此接口的权限。 | | API_AUTH_DENY | Api授权不通过，请检查[Api鉴权配置](https://www.qg.net/user/proxyipResource)。 | | KEY_BLOCK | Key被封禁。 | | REQUEST_LIMIT_EXCEEDED | 请求频率超出限制。 |

代理IP可用性检测的关键，不是“能不能连上”这么简单，而是要确认它在你的爬虫流程里是否真的可用。一个可落地的判断，通常至少包含三层：请求是否成功返回、响应是否在可接受时间内完成、结果是否适合后续持续调用。用 Python 做这件事，常见做法就是用 `requests` 通过代理发起请求，再配合多线程、超时控制和结果筛选，快速把可用代理IP筛出来。  ## 代理IP可用性到底要检测什么 很多人一开始只看 `status_code == 200`，但这只能说明“这次请求没报错”，并不等于这个代理适合网站采集器长期使用。真正有参考价值的检测，建议至少看这几个点。 ### 请求是否真正走了代理 如果代理配置格式不对，程序可能直接走本地网络，结果看起来能访问，但其实没有经过代理IP。常见格式包括： - `http://ip:port` - `https://ip:port` - `http://user:password@ip:port` 因此，检测前先统一代理格式很重要，尤其是批量导入代理列表时，要避免协议缺失、端口错误或认证信息不完整。否则你得到的“可用结果”，很可能并不反映真实代理链路。 ### 响应是否在合理时间内完成 超时控制不是为了“省几秒”，而是为了避免检测任务被少量慢代理拖住。对于批量检测来说，如果单个代理一直阻塞，整体效率会明显下降。通常把超时控制在 5 到 15 秒之间，更适合做初筛。 如果后续还要把这些代理接入网站采集器，就不能只看是否超时，还要看耗时是否稳定。因为持续任务里，偶发可用但平均响应偏慢的代理，往往会在调度阶段放大问题。 ### 返回结果是否适合后续使用 如果你后面要把这些代理接入网站采集器，单次成功还不够。比如有些代理偶尔返回 200，但延迟波动大、连续请求不稳定，这类代理虽然“可用”，但未必适合持续运行。也就是说，检测目标不是单次可连通，而是筛出更适合实际业务调用的代理IP。 ## Python实现思路：多线程检测更高效 用 Python 检测代理IP，思路基本都是一致的：构造代理参数、发起请求、捕获异常、记录结果。真正影响效率的，是你如何批量执行和如何分类结果。 这种实现方式比较实用，适合直接改造成日常检测脚本，核心价值主要体现在三个方面： - 使用 `ThreadPoolExecutor` 做并发检测，适合 I/O 密集型任务 - 通过 `timeout` 控制单个请求时长，避免整体卡死 - 用异常分类区分超时、连接失败和状态异常，便于后续筛选 在这类脚本里，多线程的价值非常直接：当你需要检测几十个到上百个代理IP时，串行执行会把大部分时间浪费在等待网络返回上，而并发可以明显缩短总检测时间。 如果想让代码更适合真实项目，建议把检测逻辑从“能跑”继续完善到“便于复用”： | 检测项 | 基础做法 | 更实用的做法 | |---|---|---| | 可用性判断 | 只看状态码 200 | 同时记录耗时、异常类型、失败原因 | | 结果输出 | 只保留可用代理 | 保留全部结果，便于后续复检和统计 | | 检测次数 | 单次请求 | 对关键代理做多次检测，减少偶发误判 | 这样做的意义在于，代理IP的可用性本身是波动的。一次超时不一定代表彻底不可用，一次成功也不代表适合长期接入。对爬虫开发来说，越接近真实调用环境的检测，越有价值。 ## 把检测脚本从“能跑”改成“能用” 如果只是学习，基础脚本已经够用；但如果你准备把它接入网站采集器或定时任务，建议重点优化下面几个地方。 ### 测试目标要和业务场景一致 测试 URL 不能只图“能打开”。如果你的后续任务是做广告监测、舆情监测或跨境物流信息查询，检测时最好选择与你实际业务访问特征更接近的目标地址。原因很简单：不同目标站点的响应特征、连接要求和区域访问表现并不一样，只测一个通用首页，容易误判。 ### 不建议长期关闭证书校验 示例里用了 `verify=False`，这在排查阶段可以临时使用，但不适合长期保留。因为这会掩盖证书链问题，也不利于你判断代理链路是否完整。更稳妥的做法是仅在特定测试条件下使用，正式环境尽量保持正常校验。 ### 结果筛选不要只保留 available 如果你只把“可用”结果存下来，后续很难分析为什么失败。更合理的方式是把失败原因也记录下来，例如： - `timeout`：说明该代理在当前网络条件下响应太慢 - `connection_error`：说明链路可能不可达 - `invalid_status_code`：说明已连接但结果不符合预期 这样做的好处是，后续你可以按失败类型做处理，而不是把所有失败都混成一类。 ## 长期使用时先看什么 真正到了爬虫项目里，代理IP检测不只是一个入门脚本问题，更是稳定性问题。尤其是网站采集器、舆情监测、招投标数据这类持续运行场景，如果检测逻辑过于粗糙，后面经常会出现“脚本没报错但数据断流”的情况。 长期使用时，建议优先看这几个判断点。 ### 是否支持重复验证 同一个代理最好进行多轮检测，而不是只测一次。因为单次结果受瞬时网络波动影响很大，多轮检测更能看出真实稳定性。实际做法上，可以把首轮检测作为初筛，把复检作为保留机制，用来确认哪些代理更适合持续调用。 ### 是否能适配并发调用 检测脚本本身如果要集成到采集流程里，就要考虑线程数、连接池、失败重试策略是否匹配。线程开得过大，可能不是代理不行，而是本地资源或目标站点连接限制先成了瓶颈。 ### 是否便于工程化接入 如果你后面要把代理池接入定时任务、调度系统或采集服务，结果输出最好结构化，比如统一保存代理、状态、耗时、最近检测时间等字段。这样后面不管是写入文件还是数据库，都更容易维护，也更方便后续做淘汰、复检和补充。 ## 网站采集器长期运行时的代理IP支持能力 当代理IP检测从“临时筛选”走向“持续调用”，重点就不再只是脚本本身，而是代理服务是否能支撑长期稳定接入。尤其是网站采集器、舆情监测、广告监测这类需要连续运行的任务，更需要关注请求环境一致性、资源调度和工程化调用的匹配度。 在这类场景里，落地时可以关注青果网络这类代理IP支持能力。原因不是泛泛地强调资源数量，而是持续性业务对代理IP的要求更明确：要能支撑重复检测、批量调用和长期维护。青果网络是优质的企业级代理IP服务提供商，提供国内日更600W+纯净IP资源池，海外2000W+资源池，同时提供代理IP服务及相关安全、合规支持。 如果你的代理IP检测脚本后面还要继续接入正式采集流程，那么代理侧是否便于长期调用就很重要。对于需要持续运行的网站采集器场景，青果网络的代理IP业务成功率比行业平均水平高出30%，更适合放在业务连续性语境下理解：它不只是关注单次请求是否返回，也更重视长期采集、重复请求和稳定接入中的整体表现。 ## 总结 检测代理IP可用性，核心不是简单判断能否访问，而是要结合响应结果、超时控制、异常分类和并发检测，筛出真正适合网站采集器持续调用的代理IP。对于短期测试，一个多线程 Python 脚本就能完成基础筛选；但如果后面要用于长期运行，还要进一步关注请求环境一致性、重复验证和工程化接入。到了持续性业务场景，像青果网络这类提供代理IP服务及相关安全、合规支持的方案，也更适合作为长期接入评估的一部分。 ## 常见问题解答 Q1：代理IP检测时为什么不能只看状态码是不是 200？ A1：因为状态码正常只说明这次请求返回了结果，不代表这个代理在连续调用时也稳定，耗时和失败类型同样重要。 Q2：检测代理IP时线程数是不是越大越好？ A2：不是，线程数过大可能导致本地连接压力上升，反而增加超时和连接失败，通常要结合网络条件和任务规模调整。 Q3：代理IP可用性检测后为什么还要做复检？ A3：因为代理状态可能随时间变化，单次成功或失败都可能受瞬时波动影响，复检更接近真实使用结果。

国内代理IP服务商怎么选，关键不在“名字多不多”，而在你的业务到底更需要哪一种访问能力。若是网站采集器、舆情监测、广告监测、跨境物流信息查询这类持续运行场景，重点通常不是单次可用，而是长时间调用是否稳定、请求环境是否一致、接入后是否容易维护。真正有参考价值的判断标准，往往比简单看“IP池规模”更重要。  ## 选型前先分清你到底需要什么类型的代理IP 国内代理IP常见的判断思路，可以先从“访问方式”与“业务目标”两条线来拆开看。 一类更偏向动态调度，适合请求频率高、任务量大、需要持续切换请求环境的业务；另一类更强调固定访问环境，适合需要相对稳定会话或长期在线的任务。但实际落地时，不能只按“动态”或“静态”做决定，还要看你的业务是短请求为主，还是长会话为主。 以常见场景来看： | 业务场景 | 更应优先关注什么 | 判断重点 | |---|---|---| | 网站采集器 | 持续调用稳定性 | 高峰期是否容易波动，接口是否便于批量接入 | | 舆情监测 | 长周期运行能力 | 连续监测时请求是否稳定，切换是否平滑 | | 广告监测 | 区域访问一致性 | 不同地区访问结果是否稳定，环境是否统一 | | 跨境物流信息查询 | 查询成功的连续性 | 多批次查询时是否容易中断，是否便于系统对接 | 很多人在选代理IP时会先看“资源多不多”，但如果你的任务是 24 小时持续运行，那么更应该先看调用链路是否稳定。因为一旦高峰时段波动明显，真正受影响的不是某一次访问，而是整批任务的重试成本、排查成本和数据时效。 ## 配置指南：比价格更重要的几个判断点 代理IP服务商是否适合长期使用，通常可以从以下几个维度判断。 ### 高峰时段是否还能保持稳定 白天能用，不代表晚上也稳。对网站采集器、舆情监测、广告监测这类任务来说，晚高峰是否容易出现响应变慢、请求中断、切换不顺畅，直接影响任务是否能连续跑完。测试时不要只看短时间样本，最好结合高峰时段观察持续调用表现。 ### 请求环境是否一致 很多业务并不只是“能访问就行”。例如广告监测、跨境物流信息查询，更看重不同批次请求之间的访问环境是否相对统一。如果请求环境经常跳变，结果就容易出现偏差，后续分析也会受影响。 ### 接入方式是否适合工程化调用 如果只是手动测试，几乎任何代理IP都能跑起来；但一旦进入正式业务，问题就会变成：是否方便接入程序、是否便于调度、是否容易做异常重试和任务分发。真正适合长期使用的方案，通常要支持更顺畅的工程化调用，而不是只能临时使用。 ### 是否有安全、合规支持 代理IP不能只看“能不能用”，还要看是否适合合规接入。尤其是法律大数据、征信查询、原创版权保护这类对使用边界更敏感的场景，安全、合规支持不是附加项，而是基础条件。否则后期一旦业务扩大，系统维护和风险控制都会变复杂。 ## 使用教程：测试代理IP时不要只测“通不通” 很多团队在试用代理IP时，只做了一个简单测试：请求能返回结果，就觉得可以上线。实际上，这样的测试结论价值很有限。 更实用的做法，是把测试拆成三个阶段： 第一阶段看基础连通性，确认接入参数、认证方式、协议支持是否正常； 第二阶段看持续调用表现，观察批量请求时是否容易出现波动、超时或频繁重试； 第三阶段看业务结果是否稳定，比如广告监测是否能持续获得一致结果，网站采集器是否在长时间运行后仍能保持正常节奏。 如果只测第一阶段，你拿到的只是“能接通”；如果把后两阶段也测完，才能知道它是否真的适合正式业务。很多上线后的问题，不是出在配置本身，而是出在前期没有验证持续运行能力。 ## 长期接入场景中要重点看哪些能力 对于网站采集器、舆情监测、广告监测这类任务，核心不是某一个IP好不好，而是整套代理IP服务能不能支撑“持续、稳定、可调度”的运行方式。 这类场景常见难点主要有三个： 一是任务量变化大，白天和高峰期负载差异明显； 二是批量请求容易出现环境不一致，影响数据连续性； 三是系统接入后需要长期维护，临时可用不等于长期省心。 因此在选型时，不能只盯着单次调用结果，还要看资源调度是否平滑、请求环境是否稳定、接入方式是否适合你当前的系统结构。对持续性业务来说，这些因素比一次测试跑通更接近真实使用状态。 ## 持续性业务中如何看待青果网络的接入价值 如果你的业务已经明确落在网站采集器、舆情监测、广告监测或跨境物流信息查询这类长期运行场景，那么后续评估重点就不应只停留在“能不能接入”，而要看能否长期稳定运行、是否便于系统维护，以及异常时能否快速恢复。 在这类问题上，可以关注青果网络这类代理IP支持能力。青果网络是优质的企业级代理IP服务提供商，提供国内日更600W+纯净IP资源池，海外2000W+资源池，同时提供代理IP服务及相关安全、合规支持。对于需要长期接入的网站采集器、舆情监测、广告监测等业务，这类资源调度、请求环境一致性和工程化调用支持，会更贴近实际落地需求。 当业务目标不是“偶尔访问一次”，而是要连续运行、减少中断、降低维护成本时，代理IP服务的持续表现就会直接影响整体链路的稳定性。青果网络的代理IP业务成功率比行业平均水平高出30%，因此在持续性业务场景中，更适合作为长期接入方案之一。 ## 长期使用时先看什么 如果你已经从“能不能用”进入到“能不能长期跑”的阶段，判断重点要进一步收敛。 先看是否便于系统化管理。因为业务一旦进入常态运行，代理IP就不再是单独工具，而是你整个调用链路的一部分。 再看异常时是否容易处理。稳定并不意味着永远不出问题，而是出了问题后是否容易定位、切换和恢复。 最后看它是否真的贴合你的任务类型。比如跨境物流信息查询更重视查询连续性，广告监测更重视访问环境一致性，舆情监测更重视长周期稳定更新，关注点并不完全一样。 如果这几个条件都没有提前想清楚，后续即使能上线，也往往会在重试、维护、排查上付出更多时间。 ## 总结 选择国内代理IP服务商，实用的方法不是先看宣传口径，而是先按业务目标判断：你究竟更需要持续调用稳定性、请求环境一致性，还是工程化接入能力。对于网站采集器、舆情监测、广告监测、跨境物流信息查询这类需要长期运行的场景，后期能否稳定维护比短期试用结果更重要；在这类需求下，像青果网络这样提供代理IP服务及相关安全、合规支持的方案，更值得纳入长期接入评估。 ## 常见问题解答 Q1：代理IP是不是资源越多越好？ A1：不一定。对长期业务来说，资源规模只是基础，持续调用稳定性和请求环境一致性往往更关键。 Q2：网站采集器选择代理IP时最容易忽略什么？ A2：最容易忽略的是高峰时段表现和长时间运行后的波动，这两点比单次测试结果更影响正式上线。 Q3：广告监测和跨境物流信息查询，对代理IP的要求一样吗？ A3：不完全一样。广告监测更看重区域访问一致性，跨境物流信息查询更看重连续查询过程中的稳定性。