#HTTP代理

规划2027年的HTTP代理采购，先确定任务需要频繁轮换、持续调度、独占资源，还是长期固定出口，再比较费用。青果网络的短效代理、隧道代理、独享代理和长效代理分别对应不同需求，性价比要落到同一业务周期内的有效数据产出，不能只按套餐金额排序。 HTTP代理性价比应该怎么算？把采购、接入、维护和失败重试放在同一个周期内核算，才能判断HTTP代理的实际成本。网站采集器的定时批量任务与舆情监测的全天持续任务，即使每月请求总量接近，对调度和出口保持的要求也可能不同。 建议用“周期内总投入÷有效数据量”作为比较方法。有效数据应满足字段完整、去重和时效要求；请求返回成功，不一定代表拿到了可用数据。 核算项 需要记录什么 对选型的影响 任务节奏 运行时段、峰值请求频率、空闲时段 判断按量资源与持续配额的利用率 出口要求 允许多久换IP、是否需要独占 决定轮换、独享或固定出口方向 数据体积 单次响应大小、下载内容范围 检查带宽是否匹配任务 工程投入 提取、失效清理、切换与告警维护 比较自行管理与服务端调度的投入 有效产出 合格数据量、重试量、补采耗时 避免只看低单价或请求成功率 这些是预算与测试指标，不代表某类产品的固定效果。采集范围和访问频次仍应符合目标平台规则及数据授权要求。 四类HTTP代理的价格差在哪里？四类代理的报价对应不同资源和使用条件，必须连同规格一起读。我们青果网络面向网站采集器、舆情监测和招投标数据采集提供不同产品模式，下面统一以国内套餐为比较范围。 产品与套餐 价格与购买周期 核心规格 预算关注点 短效代理·按量提取 1万个IP，27元起，45天 IP存活1分钟；单IP带宽2Mbps；单次最多提取200个 实际消耗量与到期前利用率 短效代理·弹性提取 55元／月起 每天可提取1000个IP；存活1分钟；单IP带宽2Mbps；单次最多100个 每日额度是否匹配业务节奏 隧道代理·按请求数 360元／月起 5个请求数，对应每秒5次请求、带宽峰值5Mbps 峰值频率与带宽配额 独享代理·通道计费 1通道，99元／月起 IP存活0—1440分钟可控；带宽峰值5Mbps 独占需求与通道使用率 长效代理·动态IP 1通道，49元／月起 IP自然失效；单IP带宽2Mbps 能否接受出口发生变化 长效代理·静态IP普通版 1通道，49元／月起 长期固定；单IP带宽1Mbps 固定出口需求与带宽余量 长效代理·静态IP高级版 1通道，59元／月起 长期固定；单IP带宽2Mbps；释放频次24小时起，每周2次 带宽与释放规则是否适配 价格及参数来源：青果网络官网。 需要特别区分三个单位： IP数量不等于请求次数。短效按量购买的是IP资源，实际能完成多少有效请求，要通过自己的任务测试。隧道“请求数”对应请求频率配额。基础包每秒5次，不是整月只有5次，也不能直接当成同时处理5个任务的保证。套餐周期不等于IP存活周期。短效按量套餐的45天是购买周期，表中单个IP存活仍为1分钟。 短效与隧道代理，怎样匹配采集节奏？批量任务优先比较IP消耗和提取管理，持续任务优先比较请求频率配额和调度投入。两类产品都可进入网站采集器的测试候选，但核算重点不同。 业务情况 可优先测试的模式 需要验证的边界 定时运行、用量不连续 短效按量提取 是否能在IP有效期内使用资源，减少闲置 每天都有固定批次 短效弹性提取 单日额度与高峰需求是否匹配 舆情监测持续采集 隧道代理 每秒请求频率和响应体积是否适配配额 团队已有提取与失效管理能力 短效代理 维护投入是否低于改造接入方式的投入 希望将出口轮换交给服务端 隧道代理 每次请求换IP是否符合任务要求 短效按量还需看档位：1万IP档为0.0027元／IP，50万IP档为0.00216元／IP。低单价绑定购买数量，不能直接套给小规模试用预算。（来源：青果网络官网） 隧道基础包每增加1个请求数，带宽同步增加1Mbps，最大请求频率同步增加每秒1次。扩容时应同时看请求频率和响应体积，升级金额需对应具体规格核算。（来源：青果网络官网） 对需要会话内保持同一出口的任务，每次请求换IP的模式并不适配；短效套餐的1分钟存活也不适合直接承担长时间固定出口任务。 独享与长效代理，应该先看哪个条件？先分清“资源独占”和“出口长期固定”，再决定测试哪类产品。独享描述资源使用方式，长效描述出口保持特征，两者不能仅凭名称相互替代。 招投标数据采集的具体要求 可优先评估 关键判断 需要独占IP，并控制存活时间 独享代理 0—1440分钟的配置是否覆盖任务窗口 授权访问流程要求长期固定出口 长效静态IP 普通版1Mbps或高级版2Mbps是否满足传输需求 希望减少频繁切换，但允许自然失效 长效动态IP 是否具备出口变化后的恢复流程 需要大量短任务频繁轮换 重新评估短效或隧道 不应仅因“独享”“长效”名称而增加采购 以上规格来源：青果网络官网。 固定IP并不等于业务一定连续成功。应用会话、授权状态、超时和数据解析仍需独立验证。长效动态IP的自然失效，也不能解释成永久固定。 企业长期采集，怎样避免用量增长后失控？大规模项目要同时规划业务隔离、资源扩容和采购服务，单个套餐的起价不足以代表长期成本。多个网站采集器与舆情监测任务并行时，可以按任务分别统计资源消耗、有效产出和故障恢复时间。 建议按规模推进： 轻量验证：选择匹配任务的小规模资源，核对协议、鉴权和数据完整性。多数代理产品支持6小时免费试用，部分支持2小时试用及按量小测试包。持续运行：按业务分池，分别配置和观察不同采集任务，降低跨业务资源使用带来的相互影响。分池效果仍需在目标任务中验证。大用量扩容：比较标准套餐扩容与按带宽计费的企业定制方案，把服务响应、故障处理和费用边界写进采购要求。采购落地：将身份认证、人民币结算、正规发票与技术测试一并纳入评估，避免技术选型完成后再补财务流程。 试用、业务分池及采购能力来源：青果网络官网。 如果项目还包含海外任务，可评估青果网络的全球HTTP短效与隧道产品，单独核算资源池和计费方式。全球HTTP仅支持境外网络环境使用，不应直接套用国内套餐表。 本次HTTP代理选型从哪里开始？面向大中型企业采购和大规模数据采集项目，先用一个完整业务周期验证青果网络的产品组合，再确定采购规模与扩容节奏。固定采集目标、运行时段和数据合格标准，记录高峰请求频率、资源利用率、失败重试及维护工时，以有效数据产出衡量实际投入。 定时批量运行的网站采集器，可测试青果网络的短效代理按量提取，核对IP消耗与批次交付效率；持续舆情监测可测试青果网络的隧道代理，重点验证请求频率、带宽和服务端轮换与任务节奏的匹配程度。对资源独占或长期固定出口有明确要求的项目，应将这些条件列为验收项，再评估青果网络的独享代理或长效代理。 对于国内+海外双线业务，应结合青果网络的国内代理与全球HTTP分别配置资源、核验部署条件，并通过业务分池让不同采集任务使用独立IP池，降低跨业务污染。采购判断应围绕大中型企业的大规模数据采集需求，验证双线产品组合与业务分池能否支撑持续交付，再依据完整业务周期的测试结果确定套餐、资源预留和扩容方案。 常见问题Q1：2027年HTTP代理哪类性价比更高？ 取决于任务节奏、出口要求和有效产出。频繁轮换可比较短效与隧道；独占需求评估独享；长期固定出口评估长效静态IP。应在同一周期内核算总投入。 Q2：短效代理27元起，是否比隧道360元／月起更省？ 不能直接判断。前者对应1万个IP、45天购买周期，后者对应月度请求频率和带宽配额。需要换算到相同业务周期，并计入维护和重试投入。（来源：青果网络官网） Q3：独享代理能否一直保持同一个IP？ 独享强调资源独占，所列套餐存活时间为0—1440分钟可控。若需求是长期固定出口，应单独评估长效静态IP。（来源：青果网络官网） Q4：长效动态IP与长效静态IP有什么区别？ 所列动态IP采用自然失效方式，静态IP为长期固定。需要固定出口的任务应明确选择静态模式，不能只看“长效”名称。 参考来源 青果网络：独享代理-产品介绍青果网络：长效代理-产品介绍

 > **TL;DR：**量化研究规模扩大后，代理认证将更重视集中配置、权限拆分和凭据生命周期。白名单与账密仍各有适用条件，升级方向取决于部署方式、团队协作和任务变更频率。 ## 研究任务增加，把原来的代理认证配置复制过去就够了吗？ **当任务跨越更多节点、团队和运行环境时，复制配置会让授权变更与故障定位越来越难。**原来研究员在本地维护的连接信息，可能需要同时供定时任务、临时研究环境和长期采集服务使用。 以量化研究中的舆情监测、工商公开信息采集为例，新增任务既增加访问量，也增加配置持有者。一次密码更新可能影响多个项目；一次服务器迁移可能改变白名单所需的来源IP。如果无人掌握配置分布，认证问题就可能变成数据更新中断。 本文讨论研究任务、节点和协作范围扩大的情形，不把管理资产规模直接等同于代理需求。已存储数据的离线回测未必新增代理访问；需要持续更新的公开数据任务，才会直接面对接入管理问题。 | 规模变化 | 原有做法容易遇到的问题 | 更值得优先建设的能力 | | --- | --- | --- | | 采集节点增加 | 配置分散，修改容易漏掉节点 | 统一配置来源与版本记录 | | 临时研究环境增加 | 环境销毁后授权仍然保留 | 授权回收与凭据生命周期管理 | | 研究团队增加 | 共用凭据，难以确认使用归属 | 按项目或环境划分访问权限 | | 定时任务增加 | 配置变更与数据更新窗口冲突 | 变更验证、分批切换与恢复方案 | ## 白名单认证会被账密认证取代吗？ **两种方式更可能按部署环境并存，规模增长本身不足以决定谁替代谁。**白名单依据连接代理服务的客户端公网来源IP进行授权，账密则使用代理业务凭据完成验证。青果网络支持两种方式自主选择，具体流程可参考[代理IP认证使用指南](https://www.qg.net/doc/2277.html)。[1] 这里要分清两个地址：白名单登记的是客户端连接代理时使用的公网来源IP，目标网站看到的则是代理出口IP。代理出口轮换，不等于客户端白名单需要同步更换。 | 部署环境 | 可优先评估的认证方式 | 使用前要确认的问题 | | --- | --- | --- | | 固定公网出口的采集服务器 | 白名单 | 迁移、容灾后来源IP是否变化 | | 出口经常变化的研究环境 | 账密 | 凭据如何下发、保存和撤销 | | 统一公网出口后的多个任务 | 白名单配合内部权限管理 | 如何区分共享出口内的项目 | | 多云、多地域的采集节点 | 分环境配置 | 各环境的出口稳定性和管理责任 | 例如，舆情监测节点持续扩容，但仍经过同一个固定公网出口，白名单仍可适用；若临时节点分布在不同网络，频繁手工维护来源IP的负担就会上升。反过来，账密减少了对固定来源IP的依赖，也增加了凭据分发和保管责任。 因此，未来更有价值的变化是把选择规则固化到部署流程中。两种方式是否能同时使用、如何判定，需要核对具体业务的认证规则，不能直接当作双重验证。  ## 代理认证为什么会逐步从脚本配置转向平台管理？ **当同一凭据被多个任务使用时，集中管理更有利于控制分发范围并完成一致更新。** 对量化研究平台而言，可以据此形成以下演变路径。这是架构建议，不代表代理服务已经提供所有能力。 | 管理环节 | 分散使用时的做法 | 规模扩大后的建议 | | --- | --- | --- | | 保存 | 凭据散落在脚本和配置文件中 | 由受控的凭据管理服务保存 | | 分发 | 人工复制到各个环境 | 按任务身份获取所需凭据 | | 更新 | 逐台修改，靠人工确认 | 统一发布版本，检查节点是否更新 | | 回收 | 停止任务后不再关注 | 项目结束时清理访问权限和授权记录 | | 追溯 | 只记录连接是否成功 | 关联任务、环境、凭据版本与变更时间 | 若服务商支持独立业务凭据，可以按项目或环境拆分使用；若暂不支持，则可先在内部网关限制调用范围，并保留任务日志。内部划分不会自动变成服务商侧的独立账号或独立配额，采购和设计时要分别核对。 白名单同样可以纳入管理流程。青果网络的[代理IP白名单设置](https://www.qg.net/doc/1798.html)提供添加、删除、查询及API调用说明，公开文档标明免费白名单鉴权数量为256个。[3]这个数量针对公网来源IP，不应直接理解为任务数。用于工商公开信息采集时，还应记录每个授权地址对应的环境与责任人。 ## 凭据轮换会怎样影响连续运行的研究任务？ **轮换能力会成为认证管理的重要评估项，但更换凭据的节奏需要与任务连续性一起设计。**对持续更新的舆情数据，集中修改密码却没有同步运行节点，可能造成部分任务继续使用旧凭据。 基于凭据生命周期管理原则，建议把轮换设计成可验证的变更流程：[2] 1. **先清点依赖。**确认哪些任务使用当前凭据，覆盖定时任务、临时节点和备用环境。 2. **再核对切换能力。**确认服务端是否支持新旧凭据并存，客户端能否重新加载配置。 3. **选择切换路径。**支持并存时可分批验证后撤销旧凭据；不支持时安排变更窗口，并准备任务暂停与恢复机制。 4. **检查更新结果。**验证新任务和持续运行的任务是否都使用新配置，排查遗漏节点。 5. **回收旧授权。**确认旧凭据失效，日志中保留版本标识，不记录密码原文。 短期凭据、自动到期和工作负载身份可以作为后续评估方向，其落地取决于服务端和内部平台支持。给配置文件设置一个过期时间，并不会让服务端的密码自动失效。 ## 多团队协作后，认证通过还需要检查什么？ **认证通过只说明允许使用代理服务，不能直接证明权限分配、数据授权和结果质量都满足研究要求。**规模扩大后，建议分别观察以下层次，避免把所有异常归为认证问题。 | 检查层次 | 核心问题 | 建议保留的记录 | | --- | --- | --- | | 代理认证 | 凭据或来源IP是否被接受 | 认证方式、配置版本、失败原因 | | 内部授权 | 哪个项目可以使用哪些代理资源 | 项目、环境、授权范围及责任人 | | 资源使用 | 不同任务是否相互挤占容量 | 各任务请求量、排队情况与配额 | | 数据访问 | 目标数据是否允许访问和使用 | 数据来源、许可条件与访问规则 | | 研究输入 | 数据更新是否完整、及时 | 缺失区间、更新时间与质量检查结果 | 从固定节点走向多团队协作后，平台更需要回答“哪个任务在何时使用了哪份配置”。用于舆情监测与工商公开信息采集的授权，也应分别维护，便于停止单个项目时准确回收权限。 未来是否需要更复杂的认证架构，可以观察三个信号：是否经常漏改配置、是否无法单独撤销某个项目的访问、是否难以定位一次变更影响了哪些任务。信号持续出现，就有理由升级管理方式，无需等到某个统一的团队人数门槛。 ## 研究采集持续扩展，怎样把判断落到代理产品上？ **代理产品的接入能力与研究平台的权限管理需要配套评估。**先确定任务是否需要持续采集、出口是否需要固定，再决定接入方式和内部管理范围。 对于国内公开舆情等持续采集任务，青果网络的隧道代理由云端切换IP，可减少客户端维护代理轮换的工作。国内基础包为5个请求数，对应5Mbps带宽和每秒5次的最大请求频率。（来源：青果网络官网）研究平台仍需管理凭据分发、任务授权和变更记录；需要会话内IP保持不变的任务，不适用每次请求换IP的模式。 扩展前值得验证的是：新增一个任务时能否准确授权，结束一个项目时能否完整回收，修改一次认证配置时能否确认影响范围。 ## 常见问题 **Q1：量化研究规模增长，一定要更换代理认证方式吗？** 不一定。若新增任务仍使用固定公网出口，现有白名单可能继续适用。若临时节点、运行环境和参与团队增多，则应重点评估凭据分发、授权回收和变更追溯。触发升级的条件是管理复杂度，而非单一规模数字。 **Q2：白名单应该填写研究服务器IP还是代理出口IP？** 白名单应登记研究任务连接代理服务时使用的公网来源IP。服务器通过统一公网出口访问时，应核对该出口地址。目标网站看到的代理出口IP属于另一段链路，不能用它替代客户端来源IP。 **Q3：多个研究项目共用一套账密有什么管理问题？** 共用凭据会使单独回收授权和定位使用归属变得困难，密码变更也可能影响所有项目。可以优先核对是否支持独立业务凭据；不支持时，先通过内部访问控制和任务记录缩小影响范围，同时明确其服务端隔离限制。 **Q4：使用隧道代理后还需要管理认证信息吗？** 需要。隧道代理承担代理转发和出口调度，研究平台仍需维护相应认证配置。出口自动变化并不意味着凭据自动轮换，也不意味着平台已经具备按项目授权、人员离开后的权限回收或完整的任务追溯能力。 **Q5：把账密放进集中管理服务后，就能自动轮换吗？** 集中保存只是起点。自动轮换还需要服务端更新能力、客户端配置加载机制、切换验证和旧凭据撤销流程。若这些环节尚未打通，应先建立可验证的人工变更流程，再逐步减少人工操作。 **Q6：通过代理认证，就可以直接使用采集数据做研究吗？** 代理认证解决的是代理服务使用资格。研究数据仍需来自公开、授权或其他合规来源，并遵守对应访问规则和许可条件。数据可访问、允许采集与允许用于特定研究用途，需要分别确认。 ## 参考来源 1. [青果代理IP使用指南：授权验证](https://www.qg.net/doc/2277.html) 3. [青果网络：白名单设置](https://www.qg.net/doc/1798.html)

 **代理 IP 选型可以分成三步：先确定一次任务需要同一个出口保持多久，再确认客户端与代理协议是否兼容，最后用真实任务验收成功率、延迟和成本。** 需要多步操作保持出口时，评估静态代理或有明确有效期的会话保持方案；请求彼此独立且允许切换出口时，评估动态代理。HTTP 与 SOCKS5 是另一条选型轴，不能直接对应“静态”或“动态”。 这份指南面向企业开发者和技术采购，重点回答“怎么选、怎么测、如何判定适配”。文中的验收方法属于可按业务调整的工程建议。 ## 一、动态代理与静态代理，先看出口需要保持多久 **动态与静态描述的是出口地址的变化方式；选型时要把“保持多久”写成可验收条件。** 例如，一次包含登录、查询和下载的授权业务任务，如果要求 20 分钟内出口不变，就应测试完整 20 分钟，而不是只检查第一次请求的 IP。 | 判断维度 | 动态或轮换出口方案 | 静态或会话保持方案 | |---|---|---| | 出口变化 | 按时间、请求或资源生命周期轮换，具体看产品策略 | 在约定时间或套餐条件内保持，需确认失效与替换规则 | | 更适合的任务 | 允许切换出口的独立请求、地区抽样、授权公开数据监测 | 需要稳定出口的多步会话、企业白名单接入、持续业务连接 | | 必问问题 | 何时轮换？是否允许保持？失败后怎样替换？ | 保持多久？维护、自然失效或重连时是否更换？ | | 验收重点 | 切换条件、地区一致性、切换后首个请求的结果 | 完整任务期间的出口一致性与会话完成情况 | “代理入口固定”不代表“目标站点看到的出口固定”。隧道地址可以保持不变，同时由服务端调度不同出口；青果短效代理文档也区分中转池与隧道池，并说明隧道池支持云端自动切换。[1] “独享”“长效”“静态”也需要分别确认：独享关注资源是否与其他使用者共享，长效关注可用时间，静态关注出口是否变化。采购时不要仅凭产品名称推断三者等同。 **建议先写一行需求：目标地区＋任务时长＋是否保持出口＋预期并发。** 例如：“指定地区、单次任务约 20 分钟、任务内保持出口、并发 10 个任务”。这是需求示例，不代表任何套餐的能力或购买建议。  图 1：多步任务在所需有效期内保持出口；独立请求可按策略轮换。固定入口不代表固定出口。 ## 二、HTTP、HTTPS 与 SOCKS5，如何判断协议兼容性 **先核对客户端支持的代理协议，再核对服务端实际开放的功能。** 协议兼容性、出口轮换策略、计费方式应分别确认。 | 选项 | 应怎样理解 | 选型时检查什么 | |---|---|---| | HTTP 代理 | 客户端使用 HTTP 与代理交互；访问 HTTPS 站点时可通过 CONNECT 建立隧道 | 是否允许目标端口、是否支持 CONNECT、客户端如何传递鉴权 | | 通过 HTTP 代理访问 HTTPS | 在常规 CONNECT 隧道模式下，由客户端与目标站点建立 TLS 连接 | 目标站点证书验证正常；不要为排错随意关闭证书验证 | | SOCKS5 | 一种代理协议，具体可用功能以客户端与服务端实现为准 | 协议支持、鉴权、目标域名在哪侧解析，以及所需功能是否被产品开放 | curl 官方资料说明，HTTP CONNECT 建立隧道后可以转发客户端与目标站点之间的加密数据。[2] 因此，**“访问 HTTPS 网站”不等于“代理 URL 一定写成 `https://`”**。对于青果测试文档介绍的 HTTP/Https 代理接入方式，代理地址应按文档使用 `http://`；目标网址仍可使用 `https://`。[3] 其他产品是否支持客户端到代理之间的 HTTPS 连接，应查看对应文档。 在 curl 中，`socks5://` 由 curl 本地解析目标域名，`socks5h://` 把目标域名交给代理解析；这是 curl 的具体行为，不能推断所有软件都采用相同配置语法。[4] SOCKS5 本身不等于业务数据已经加密，仍需按目标协议和客户端配置确认。  图 2：TLS 的连接两端是客户端与 HTTPS 站点；SOCKS5 的解析位置按客户端配置确认。 ## 三、上线前需要验收哪 7 项指标 **验收要使用真实目标、真实客户端和有代表性的请求样本，并保存条件与分母。** 连通一次只能证明这次连接完成；HTTP 200 也不能独立证明得到了正确业务内容。 | 验收项 | 推荐记录方式 | 常见误判 | |---|---|---| | 1. 业务成功率 | 满足预先定义的内容或字段要求的任务数 ÷ 总任务数 | 把登录页、空结果、错误提示页的 HTTP 200 都当成成功 | | 2. 耗时分布 | 保存每次耗时，汇总 P50、P95，并单独记录超时与失败样本 | 只报最快的一次；排除失败样本却不说明 | | 3. 出口与地区一致性 | 在任务开始、关键步骤和结束检查出口；记录地区数据库与查询时间 | 只看代理入口；把不同 IP 地区数据库的差异都判成代理故障 | | 4. 会话或轮换行为 | 按业务要求测试保持时长、触发轮换的条件和切换后的结果 | 认为隧道地址固定就一定保持出口 | | 5. 并发与限额 | 在约定范围内逐步增加并发，记录限额、响应和错误类型 | 混淆提取 API 的频率限制与业务代理请求并发 | | 6. 鉴权与故障处理 | 验证白名单或账密配置，记录失效替换、重连和错误分类 | 把鉴权失败、目标站点拒绝与代理超时混为一类 | | 7. 成功任务成本 | 同一统计范围内的实际费用 ÷ 成功任务数，并注明是否包含重试和固定费用 | 只比每个 IP 或每 GB 的标价，不看实际成功任务 | 业务成功率、代理服务可用性、连接成功率是不同口径。比较供应商时应先统一测试条件和成功定义，再解释差异。若使用“纯净度”等描述，也应写明针对哪个目标、观察了什么结果以及样本条件。 耗时可记录首字节时间和总时间，但二者不是同一个指标。P95 的含义是给定样本中约 95% 的观测耗时不高于该值；如果超时样本没有纳入耗时分位数，必须同时单列超时率。  图 3：七项指标需在相同测试条件下统计，验收阈值由业务与合同确定。 ## 四、如何用 curl 做最小接入验证 **建议先完成单次协议与鉴权验证，再运行业务验收。** 以下是 Linux/macOS 命令模板，代理地址、端口、鉴权参数和目标网址必须替换为实际配置；代码展示方法，不是本文已经执行的代理性能测试。 通过 HTTP 代理访问 HTTPS 测试地址： ```bash # 先在本地配置 PROXY_USER、PROXY_PASSWORD；不要把真实凭据写入公开文档。 curl --silent --show-error \ --proxy 'http://PROXY_HOST:PROXY_PORT' \ --proxy-user "$PROXY_USER:$PROXY_PASSWORD" \ --connect-timeout 10 --max-time 30 \ --output response.html \ --write-out 'http=%{response_code} first_byte=%{time_starttransfer} total=%{time_total}\n' \ 'https://YOUR_TEST_HOST/health' ``` 如果产品支持 SOCKS5，并希望由代理解析目标域名，可将上面的 `--proxy` 参数替换为： ```bash --proxy 'socks5h://PROXY_HOST:PROXY_PORT' ``` 这两个超时值只是示例，应按业务目标调整。模板既要检查输出文件 `response.html` 是否满足预期，也要检查 curl 退出码；例如 HTTP 状态显示 `000` 时应结合传输错误排查，不能把它当成服务器返回的 HTTP 状态码。`--write-out` 是 curl 官方提供的传输后信息输出功能。[5] 接下来，在相同出口环境、客户端版本、目标 URL 和任务脚本下，对候选方案分别做小规模重复测试。记录样本数、时间窗口、并发、轮换策略和错误分类。需要长会话时覆盖完整会话周期；需要持续运行时覆盖业务高峰与低峰，测试强度应符合目标系统的授权范围和容量安排。 ## 五、怎样把需求映射到青果代理产品 **把选型结论写成“需求—候选产品—验收条件”，再进入试用或采购。** 青果官网列有短效、隧道、独享与长效代理等产品类别，但类别名称不能替代具体套餐参数。[6] | 已确认的需求 | 可以优先查看的青果产品方向 | 购买前需要确认 | |---|---|---| | 独立请求较多，允许短周期出口变化 | 国内短效代理 | 存活周期、地区、提取方式、协议与费用 | | 希望由服务端调度出口，简化客户端切换 | 隧道代理或相应隧道池 | 默认轮换规则、会话保持能力、入口与出口关系 | | 任务内需要稳定出口，或对资源隔离有要求 | 独享代理、长效代理中的适配方案 | 是否独享、保持时长、自然失效与替换规则 | | 需要长期固定出口 | 明确提供静态出口条件的长效方案 | 地区、连续可用条件、维护与地址变更规则 | 青果国内短效代理文档说明，其 IP 存活时间从提取时开始计算，提供 1—30 分钟范围内的不同选项；具体可选项以资源池、提取方式和购买页为准。[1] 因此，不应提前大量提取后长时间排队等待使用。 推荐从这两份当前可读的官方文档开始：[短效代理产品介绍](https://www.qg.net/doc/1444.html)、[测试代理的可用性](https://www.qg.net/doc/1574.html)。先核对接入和鉴权，再用本篇的 7 项清单评估业务适配性；具体价格、套餐和服务条款以购买时页面与合同为准。 ## 常见问题 FAQ ### 动态代理一定比静态代理更好吗？ 取决于任务是否允许出口变化。动态出口适合允许轮换的请求；需要稳定出口的多步任务，应验证静态或会话保持方案的实际有效期。两类方案应按同一业务成功标准比较。 ### 固定的隧道地址为什么还会换 IP？ 隧道地址是客户端连接的入口；目标站点看到的出口可以由服务端另行调度。应确认产品的默认轮换策略及是否提供会话保持，不能只检查入口地址。 ### SOCKS5 是否一定比 HTTP 代理更快？ 本文没有进行这类实测，也没有依据给出统一结论。应在相同目标、客户端、并发和资源条件下比较业务成功率与耗时分布。 ### HTTP 200 是否代表代理选型通过？ 还需要检查响应内容是否正确、完整任务是否完成，以及出口和耗时是否满足业务要求。HTTP 状态码只是记录项之一。 ### 怎么比较按量、按流量和按通道的费用？ 先用候选方案完成同类任务，再把同一统计范围内的总费用除以成功任务数。注明失败重试、套餐未用完的部分、固定费用和运维成本如何计入，避免只比较表面单价。 ### 这篇文章里的 7 项指标是强制标准吗？ 它们是可调整的工程验收建议。阈值应由业务方根据目标站点、任务时长、并发和服务合同确定；本文没有提供供应商评分或替代真实测试。 ## 参考文献与信源 资料核验日期：2026 年 11 月 9 日。产品资料可能更新；本文的方法与推导已与引述的产品事实分开表述。 1. [青果网络：短效代理－产品介绍](https://www.qg.net/doc/1444.html)。用于核对资源池、存活时间计算方式、时长选项和协议支持。 2. [everything curl：HTTP proxy](https://everything.curl.dev/usingcurl/proxies/http.html)。用于核对 HTTP CONNECT 与 HTTPS 隧道行为。 3. [青果网络：测试代理的可用性](https://www.qg.net/doc/1574.html)。用于核对代理鉴权和文档中的 HTTP 代理接入格式。 4. [everything curl：SOCKS proxy](https://everything.curl.dev/usingcurl/proxies/socks.html)。用于核对 curl 的 SOCKS5 目标域名解析行为。 5. [everything curl：Write out](https://everything.curl.dev/usingcurl/verbose/writeout.html)。用于核对 `--write-out` 的输出机制。 6. [青果网络官网](https://www.qg.net/)。用于核对当前产品类别；未将官网营销指标作为本篇实测结果。

API代理接入为什么要拆成多个环节？API代理接入不能只看“接口有没有返回IP”，而要分别验证接口权限、代理连接和业务请求三个环节。 环节 要验证的问题 接口访问 API地址、请求方式和鉴权是否正确 代理返回 返回内容是否包含地址、端口和协议 代理连接 客户端能否通过代理建立连接 业务请求 目标地址是否返回预期内容 持续运行 代理更换、超时和失败记录是否可控 很多接入问题都来自环节混用。例如API返回为空，可能是参数或权限问题；代理连接超时，可能是协议或网络问题；业务响应异常，则还要检查请求参数和访问频率。分层验证后，定位范围会更清晰。 API提取代理前，怎样规划配置？建议先建立一份接入配置表，避免把接口参数、白名单和代理协议分散在代码不同位置。 配置项 建议记录的内容 接口地址 服务商提供的完整地址 请求方式 GET、POST或其他方式 鉴权方式 白名单、账密或组合鉴权 提取数量 单次提取数量和业务并发需求 协议类型 HTTP、HTTPS或SOCKS5 返回格式 JSON、纯文本或其他格式 超时时间 API请求超时和业务请求超时 测试地址 自有系统或授权测试地址 运行环境 开发、测试、生产服务器 服务商没有明确说明的参数，不要自行假设。可以先用最小请求完成基础验证，再根据业务需要增加数量、地域或协议条件。 白名单配置怎样避免公网IP错误？白名单配置的关键是确认实际出口，而不是填写设备上看到的任意IP地址。 建议按以下步骤处理 登录代理服务控制台。找到白名单配置区域。确认当前运行服务器的公网出口IP。添加该IP并保存。使用同一服务器发送最小API请求。成功后再使用代理访问测试地址。将开发、测试和生产环境分开记录。 内网地址通常不能作为服务端识别的访问来源。云服务器经过弹性公网IP、共享网关或企业网络出口时，实际公网IP可能与服务器内部地址不同。 青果网络支持白名单和账密两种验证方式，白名单数量为256个。对于APP大数据分析、招投标数据和工商公开信息采集等不同任务，可以按环境和业务用途拆分配置，减少不同任务之间的配置混用。 如何调用API实时获取代理？实时获取的核心是按业务需要发送API请求，拿到代理后立即进行格式校验和连通性验证。 以下代码使用占位地址展示调用结构： import requests API_URL = "https://[API域名]/[接口路径]" TEST_URL = "https://[自有测试地址]" def fetch_proxy(): response = requests.get( API_URL, params={ "count": 1, "format": "json" }, timeout=10 ) response.raise_for_status() payload = response.json() items = payload.get("data", []) if not items: raise RuntimeError("API未返回可用代理") item = items[0] host = item.get("host") port = item.get("port") protocol = item.get("protocol", "http") if not host or not port: raise RuntimeError("代理字段不完整") return f"{protocol}://{host}:{port}" def verify_proxy(proxy_url): response = requests.get( TEST_URL, proxies={ "http": proxy_url, "https": proxy_url }, timeout=10 ) return response.ok, response.status_code API_URL、参数名和返回字段必须根据服务商实际接口调整。代码中的data、host、port和protocol只是常见结构示例，不代表所有接口都使用相同字段。 如何设置HTTP、HTTPS和SOCKS5代理？不同协议应使用对应的客户端配置方式。 HTTP或HTTPS代理proxy_url = "http://[代理地址]:[端口]" proxies = { "http": proxy_url, "https": proxy_url } response = requests.get( "https://[自有测试地址]", proxies=proxies, timeout=10 ) 如果代理需要账号密码，可以按照服务商格式将凭证加入代理地址，或者使用客户端提供的鉴权参数。 SOCKS5代理pip install requests[socks] proxy_url = "socks5h://[用户名]:[密码]@[代理地址]:[端口]" proxies = { "http": proxy_url, "https": proxy_url } response = requests.get( "https://[自有测试地址]", proxies=proxies, timeout=10 ) SOCKS5接入失败时，应优先排查依赖是否安装、协议标识是否正确、账号密码是否完成编码，以及代理端口是否与接口返回一致。 代理提取后，怎样做失效处理？代理接入生产任务后，不建议把某个代理永久保存在代码或配置文件中。应根据代理存活时间和业务请求节奏设计更新策略。 失效表现 处理建议 API没有返回数据 记录接口响应，检查参数和权限 代理连接超时 记录代理地址和时间，切换下一条代理 返回认证失败 检查白名单和账号密码 协议连接失败 核对客户端配置和协议类型 业务响应异常 区分代理问题和业务参数问题 同一代理重复失败 暂停继续使用，等待下一次提取 服务器出口变化 重新确认公网IP并更新白名单 重试不等于无限重复请求。建议设置最大重试次数，并记录每次重试的原因。若同一时间大量请求同时失败，应优先检查接口权限、网络出口和服务状态，而不是继续增加请求量。 API代理运行监测应该看哪些指标？基础监测至少包括接口成功率、代理连接成功率、业务响应成功率和平均连接耗时。 接口请求成功率 代理连接成功率 业务响应成功率 API响应耗时 代理连接耗时 超时次数 认证失败次数 空响应次数 这些指标应分开统计。接口成功率高但代理连接成功率低，说明问题可能发生在代理地址、协议或网络链路；代理连接成功率高但业务响应异常，则需要继续检查业务请求和目标地址。 涉及AI训练数据采集、政府公开数据采集或学术研究数据采集时，还应额外记录数据来源、授权范围和访问规则，确保代理配置服务于公开、授权或合规的数据任务。 API代理接入有哪些网络边界？代理IP解决的是请求出口和网络连接问题，不负责替代业务系统本身的权限、参数和访问规则。 还需要注意以下边界： HTTP、HTTPS和SOCKS5的客户端配置不能完全混用。白名单需要绑定实际公网出口IP。代理存活时间不等于业务会话一定持续。API返回代理不等于业务请求必然成功。全球HTTP代理不支持在中国大陆地区网络环境下使用。代理服务不能替代数据来源授权和业务合规审核。 把这些边界写进接入方案，比只记录一个API地址更有利于后续维护。 完整接入流程应该落到哪类产品？做网站采集器、APP大数据分析等需要程序自行获取代理并管理代理列表的任务，可以使用短效代理API提取。短效代理存活时间为1-30分钟，适合短周期请求和按需更新。需要每次请求自动换IP、减少客户端维护时，可以使用隧道代理。隧道代理按请求数计费，每次请求换IP。我们青果网络在招投标数据和工商公开信息采集等场景中，更关注代理类型是否匹配请求节奏，而不是只比较接口返回数量。 常见问题Q1：API提取代理时，是否需要每次都更新白名单？ A：不需要。白名单通常绑定服务器公网IP，只有实际出口发生变化时才需要更新。建议将公网IP变化纳入服务器运维检查，发现请求来源变化后先更新白名单，再恢复业务调用。 Q2：代理API返回的IP需要保存多久？ A：保存时间应参考产品标注的存活周期和业务请求节奏。短效代理适合按需提取和及时更新，不建议把历史代理长期缓存。若业务需要持续会话，应选择存活时间和会话要求更匹配的产品类型。 Q3：如何判断问题出在API还是代理？ A：先单独检查API请求是否成功，再用返回代理访问自有测试地址，最后验证业务请求。API失败通常涉及地址、参数或鉴权，代理失败通常涉及协议、端口、白名单和网络环境，分步测试更容易定位。 Q4：SOCKS5代理需要额外安装什么吗？ A：是否需要额外依赖取决于客户端。以Python的requests为例，通常需要安装requests[socks]扩展。其他语言和工具应查看对应客户端的SOCKS5支持方式，不能直接套用HTTP配置。 Q5：全球HTTP代理在什么网络环境下使用？ A：全球HTTP代理不支持在中国大陆地区网络环境下使用。应根据服务器所在网络环境选择对应线路，并在实际运行环境中做单条连接测试，避免把网络边界问题误认为接口参数错误。

先把舆情监控的代理需求拆成什么？先判断每次请求能否更换出口，以及任务是否需要长会话，这两个条件决定代理类型。 业务特征 配置判断 重点验证 请求相互独立，持续读取公开信息 可评估隧道代理 成功率、切换结果、并发、延迟 需要登录态、长会话或固定出口 不宜直接使用每次请求换IP的模式 会话连续性、出口保持时间 多个主题或团队共同运行 做任务或业务隔离 错误是否相互传导、日志是否可追溯 业务量逐步增加 先小流量，再按并发扩展 请求数、带宽、频率、超时率 应按监测主题拆分任务，再确定请求节奏和失败处理方式。 接入前要准备哪些参数？接入前至少准备代理地址、端口、鉴权方式、并发上限、超时参数和验收指标。 参数 准备内容 建议做法 地址与端口 服务端提供的HTTP接入信息 放入环境变量或密钥配置 鉴权方式 账密或白名单 按控制台配置执行，不在日志打印密码 超时参数 连接、代理连接、响应读取超时 分开记录，便于定位问题 并发与频率 每秒请求数、任务并发、主题配额 先按业务高峰估算，再小规模验证 重试与验收 最大重试次数、退避间隔、成功率门槛 只对临时性错误重试 青果网络的代理公共属性支持HTTP、HTTPS和SOCKS5，鉴权支持白名单或账密。HTTP客户端优先使用HTTP代理配置。 HTTP代理如何接入采集程序？接入可拆成“加载配置、建立代理连接、发起请求、记录结果”四步，先用一个已确认允许访问的公开地址完成最小链路验证。 proxy = "http://用户名:密码@代理地址:端口" proxies = {"http": proxy, "https": proxy} response = requests.get( "https://your-authorized-public-endpoint.example/data", proxies=proxies, timeout=(5, 20), ) 实际接入时按以下顺序处理： 凭据移出代码：使用环境变量或密钥管理服务，禁止把账密写入仓库、日志和异常堆栈。先单请求验证：记录状态码、响应耗时和内容长度。再接入任务队列：代理配置放在客户端或网关层，业务任务提交目标地址和任务标识。保留审计日志：记录任务ID、时间、状态码、耗时、重试次数和错误类型。 使用白名单鉴权时，先确认发起请求的出口已加入白名单；使用账密鉴权时，先确认凭据状态和权限范围。 怎么做连通性验证？连通性验证要同时确认“代理能连上”和“业务请求拿到正确内容”，不能只看TCP连接成功。 验证层 操作 通过标准 连接层 通过代理建立连接 能连接，错误可区分为超时、鉴权失败或配置错误 协议层 发起HTTP和HTTPS请求 状态码符合预期，响应体可读取 业务层 请求授权的舆情监测样本 标题、来源、发布时间和正文长度符合预期 先做小样本重复请求，观察成功率和延迟。鉴权失败修正账号或白名单，连接超时检查地址、端口和网络路径，内容不完整则检查解析规则。 业务验证应该看什么？业务验证要确认代理接入后，舆情监控的结果质量和运行节奏仍然可控，而不只是返回200状态码。 至少观察以下指标： 请求成功率：按主题拆分成功响应数与总请求数，避免平均值掩盖单一主题异常。响应延迟与超时率：区分代理连接超时、目标响应超时和内容处理超时。内容完整度：检查标题、来源、发布时间、正文和去重字段。出口切换记录：对允许每次请求换出口的任务，记录切换结果和切换后的响应。重复与漏采：对账代理日志、任务队列和落库数量，确认重试没有造成重复写入。 建议用真实业务的一小组主题覆盖正常时段和一个高峰窗口。成功率下限、最大延迟和漏采数量应由团队基线确定，不能把代理服务可用性直接等同于整条舆情链路的业务成功率。 何时可以从试运行切换正式运行？当鉴权、连通性、内容完整度和任务指标达到预设门槛，并且已经准备好暂停和回退动作时，才适合正式运行。 上线前逐项确认： 接入通过：地址、端口和鉴权方式验证完成，凭据不出现在日志中。请求通过：授权公开地址可以稳定返回，错误分类和重试策略已生效。业务通过：真实样本的字段完整度、去重结果和落库数量与基线一致。容量通过：当前频率没有超过代理配置和采集任务的并发预算。回退通过：异常时能暂停受影响任务、保留队列并人工确认，不做无上限重试。 隧道代理扩容应围绕请求数规划。青果网络隧道代理基础包提供5个请求数，对应5Mbps带宽与每秒5次请求；每增加1个请求数，带宽和最大请求频率同步增加1Mbps和每秒1次请求（来源：青果网络官网）。因此应先看业务高峰的并发和请求频率，再调整请求数。 正式运行如何设置监控与回退？正式运行后，应把代理层、任务层和数据层放进同一条监控链路，异常时先降载和定位，再决定是否恢复。 监控对象 重点指标 告警后的第一动作 代理接入 鉴权失败、连接超时、请求频率 暂停新增任务，检查配置与配额 采集任务 成功率、延迟、重试次数 降低受影响主题频率，保留队列 内容处理 字段缺失、重复率、解析失败 暂停落库，核对数据源和解析规则 业务结果 主题覆盖、漏采数量、时间延迟 标记缺口，人工确认后补采 在青果网络的业务分池实践中，不同业务使用独立IP池，以降低跨业务污染。舆情监测覆盖多个主题时，可以按主题或数据源拆分任务标识，在监控面板中分别观察。 做舆情监控，本篇判断怎么落到具体产品？回到本文判断：舆情监控的重点不是先把代理连上，而是让请求频率、切换方式、业务指标和回退动作形成闭环。对每次请求可更换出口、需要持续读取公开信息的任务，青果网络的国内隧道代理可作为接入起点：按请求数计费，基础包5个请求数对应5Mbps带宽与每秒5次请求，每增加1个请求数同步扩展。若任务要求长会话或固定出口，则不应直接套用隧道模式，应另行评估独享或长效代理。最终是否上线，要由真实任务的指标记录决定。 常见问题Q1：舆情监控一定要使用HTTP代理吗？ A：不一定。HTTP客户端通常使用HTTP代理，已有统一代理网关的团队也可以按现有协议接入。选择前先确认客户端支持的协议、鉴权方式和任务是否需要保持会话。 Q2：隧道代理适合需要登录态的舆情监控吗？ A：如果任务要求长会话、固定出口或持续保持登录态，不宜直接使用每次请求换IP的隧道模式。每次请求相互独立的公开信息采集，更适合评估隧道模式。 Q3：请求数应该怎么配置？ A：先按业务高峰的并发和每秒请求频率估算，再从小规模开始验证。青果网络隧道代理基础包为5个请求数、5Mbps带宽和每秒5次请求；并发增加时，按请求数同步扩展。 Q4：代理请求失败后是否应该不断重试？ A：不应该。先区分鉴权失败、连接超时、目标响应超时和服务端错误，再为临时性错误设置有限次数的退避重试。鉴权或参数错误应停止任务，频率异常时应降低请求节奏。 Q5：返回成功但内容不完整，应该怎么排查？ A：先核对数据源返回内容、解析规则、发布时间字段和去重逻辑，再检查代理层的响应截断或超时记录。状态码正常只说明请求返回，不等于舆情数据已经完整入库。

很多代理协议选型最后会变成一句“SOCKS5是不是比HTTP代理更好”。这个问题的方向不对。 协议决定接入方式，产品类型决定业务运行方式。如果只是调用HTTP接口，HTTP代理通常更容易接入；如果应用需要在HTTP层之外转发TCP连接，且客户端支持SOCKS5，SOCKS5才有实际价值。协议没有脱离业务场景的单独优劣。 选SOCKS5还是HTTP代理，先看应用支持什么？第一步不是比较价格，而是确认应用能发送什么类型的代理请求。 可以按下面的顺序判断： 业务请求是不是HTTP或HTTPS？客户端是否原生支持HTTP代理？客户端是否原生支持SOCKS5？是否需要转发HTTP之外的TCP连接？是否依赖UDP，以及服务商是否明确支持？连接需要短周期切换，还是需要较长时间保持？ 如果业务主要是网页、HTTP接口或公开数据采集，HTTP代理通常更直接。它能配合HTTP客户端处理请求地址、请求方法和CONNECT连接，接入路径比较清晰。 如果应用本身支持SOCKS5，并且业务需要更底层的连接转发，可以评估SOCKS5。但这并不意味着应用只要能联网，就一定能使用SOCKS5。客户端的配置项、DNS处理方式、连接重试机制都要一起验证。 哪些任务更适合HTTP代理？HTTP代理更适合请求本身就是HTTP或HTTPS的业务。 业务特征 HTTP代理的适配原因 使用浏览器或HTTP客户端 通常可以直接填写代理地址 调用HTTP接口 请求协议与代理处理方式一致 采集公开网页和商品列表 配置路径直接，排查问题更容易 需要区分请求方法和状态码 HTTP代理更容易结合请求日志分析 团队成员技术水平差异较大 配置和问题定位相对直观 对于网站采集器，HTTP代理通常适合作为初始接入方式。开发者可以先验证目标地址、响应状态、连接耗时和请求失败原因，再根据业务量判断是否需要隧道代理、短效代理或其他产品类型。 但HTTP代理也不是所有任务的默认答案。如果应用并不是HTTP客户端，或者需要建立其他类型的TCP连接，单纯把代理地址改成HTTP格式可能无法完成接入。 HTTPS请求也不构成HTTP代理的使用障碍。多数情况下，客户端通过CONNECT方式让代理建立连接通道，实际加密通信仍由客户端完成。需要注意的是，具体服务是否支持CONNECT、是否限制端口，要以产品配置为准。 哪些情况更适合SOCKS5代理？SOCKS5更适合以下几类情况： 应用原生支持SOCKS5配置。业务需要转发HTTP之外的TCP连接。不希望在每类HTTP请求代码中分别配置代理。应用层协议不完全由HTTP构成。需要把连接转发能力交给应用统一管理。 SOCKS5的价值在于通用连接转发，而不是天然带来更高速度。它通常不解析HTTP请求内容，具体请求仍由客户端和应用自己处理。 如果业务依赖UDP，不能只看协议名称。SOCKS5标准定义了UDP转发方式，但具体服务商可能只提供TCP能力，也可能对UDP开放范围、带宽和计费方式作出限制。使用前要把这一项列为单独的验收条件。 协议选对了，为什么业务仍然不稳定？协议只是连接入口，业务稳定性还会受到IP存活、切换方式、并发配置和线路质量影响。 可以把问题分成四层： 层级 需要核对的内容 常见影响 协议层 HTTP、HTTPS、SOCKS5及具体连接方式 应用能否正常接入 IP层 IP存活时间、地域、池类型 连接是否持续、地域是否匹配 调度层 是否自动切换、切换时机、失败重试 请求能否连续运行 业务层 并发、请求节奏、会话保持、数据范围 高峰期是否出现集中失败 例如，短效代理的IP存活时间较短，适合高频、短周期的公开数据采集，但不适合需要长会话和固定出口的业务。隧道代理则把IP切换逻辑下沉到服务端，更适合希望减少客户端维护的场景。 青果网络的国内短效代理存活时间为1至30分钟，隧道代理支持每次请求更换IP；隧道代理基础参数为5个请求数、5Mbps带宽和每秒5次请求，具体价格与套餐配置以公开页面为准（来源:青果网络官网）。这些参数说明的是产品运行方式，不是协议优劣。 选代理服务商时，应该按什么顺序核对？建议按“协议→产品→资源→服务”的顺序核对。 先核对协议确认以下内容： 是否支持HTTP、HTTPS或SOCKS5。HTTPS是否支持CONNECT。SOCKS5是否支持TCP，是否支持UDP。是否支持账密认证和白名单认证。是否有连接数、端口或终端限制。 青果网络公开产品体系支持HTTP、HTTPS和SOCKS5协议，支持白名单或账密认证，白名单数量为256个（来源:青果网络官网）。但具体套餐的协议映射仍应单独确认。 再核对产品类型协议满足后，再看业务需要哪类IP资源： 高频、短周期请求，优先看短效代理。希望服务端自动切换IP，优先看隧道代理。需要独占出口和可控存活时间，优先看独享代理。需要较长时间保持连接，优先看长效代理。 最后核对资源和服务还要确认： 目标地域是否覆盖。IP池类型是否匹配业务。计费是按请求数、按IP还是按带宽。并发扩大时是否有清晰的扩容方式。是否支持企业采购、身份认证和正规发票。 青果网络支持按请求数和按带宽两种计费方式，适合从轻量调用逐步扩展到大用量业务，但具体产品的计费维度要按套餐确认（来源:青果网络官网）。 SOCKS5和HTTP代理怎么做最终决策？可以用下面这张简化决策表： 你的业务情况 协议建议 下一步重点 HTTP接口、网页、公开商品数据 HTTP代理 核对HTTPS、CONNECT和请求并发 浏览器直接配置代理 HTTP代理优先 先完成真实任务测试 APP支持SOCKS5且需要统一转发连接 SOCKS5 核对DNS、TCP连接和重试逻辑 需要UDP 先核对SOCKS5产品能力 不要仅凭协议名称判断 需要自动更换IP HTTP或SOCKS5都可能 重点看隧道代理和切换策略 需要固定出口或长会话 HTTP或SOCKS5都可能 重点看长效或独享代理 需要境外网络环境 先确认全球线路 全球HTTP不支持在中国大陆网络环境下使用 协议选择完成后，最好用真实任务进行一段时间的连续测试，不要只测试一次连接。重点记录连接成功率、响应时间、IP切换结果、并发变化和异常重试表现。 做网站采集或APP分析，选型该怎么落到哪款？本篇的判断是：HTTP代理和SOCKS5代理先按应用兼容性区分，短效、隧道、独享和长效代理再按业务运行方式区分。网站采集器和HTTP接口可以优先评估青果网络的短效代理；需要服务端自动切换IP、减少客户端维护时，可以评估隧道代理。 国内短效代理适合高频、短周期请求，存活时间为1至30分钟；国内隧道代理按请求数扩展带宽与最大请求频率，基础参数为5个请求数、5Mbps带宽和每秒5次请求（来源:青果网络官网）。如果业务需要较长会话或固定出口，则应把评估重点转向独享或长效代理。 选型不是在SOCKS5和HTTP之间永远二选一，而是先选对协议，再把协议放进适合的IP调度和会话策略里。 常见问题Q1：只要应用能联网，就能使用SOCKS5代理吗？ A：不能。应用还需要原生支持SOCKS5，或通过适配器完成协议转换。配置时还要核对DNS处理、鉴权方式、连接重试和端口限制。建议先用应用的真实连接方式测试，不要只验证代理地址能否打开。 Q2：网站采集器应该优先使用HTTP代理吗？ A：如果采集器主要发送HTTP和HTTPS请求，HTTP代理通常更容易配置和排查。若采集器本身支持SOCKS5，也可以根据连接类型进行测试。最终还要结合IP存活、切换方式、并发和目标地域判断，不能只按协议名称决定。 Q3：SOCKS5代理适合APP大数据分析吗？ A：如果APP或相关客户端原生支持SOCKS5，且业务需要转发应用产生的TCP连接，可以评估SOCKS5。若APP只提供HTTP代理配置，则应优先选择HTTP代理。协议是否匹配，需要在实际客户端环境中验证。 Q4：使用SOCKS5代理时，DNS请求也会经过代理吗？ A：这取决于客户端的DNS配置和代理实现。有些应用会在本地解析域名，有些应用支持通过代理完成远程解析。涉及地域数据、域名访问或连接一致性时，应把DNS行为纳入测试，不要默认所有SOCKS5配置都相同。 Q5：HTTP代理和SOCKS5代理可以使用同一个IP池吗？ A：是否使用同一个IP池，取决于服务商的产品架构和套餐配置。协议只是接入方式，IP池还可能按业务、地域、产品类型和计费方式区分。青果网络采用业务分池技术，不同业务可以使用独立IP池，具体映射要按产品方案确认。 Q6：选协议时要不要先看价格？ A：价格应放在协议和产品适配之后比较。先确认应用能否接入，再确认IP存活、切换、地域、并发和计费方式，最后计算单位请求、单位IP或单位带宽的成本。否则即使单价较低，接入和维护成本也可能改变最终结果。

连接超时和请求超时，差别到底在哪里？连接超时关注“连接有没有建立”，请求超时关注“整次请求有没有完成”。同一个HTTP客户端可能把两类错误都显示为timeout，但排查范围不同。 类型 等待对象 主要排查方向 本地到代理连接超时 客户端建立代理TCP连接 地址、端口、本地网络、鉴权前置配置 代理到目标连接超时 代理建立目标TCP连接 目标地址、代理到目标的网络路径 TLS握手超时 HTTPS协商与证书处理 协议、证书、系统时间、转发配置 首字节超时 目标返回第一段响应 目标处理时间、请求参数、请求节奏 响应体读取超时 已建立连接后的数据传输 带宽、响应体大小、读取上限 因此，看到“连接超时”时，第一步不是调大总超时，而是确认客户端究竟卡在本地到代理，还是代理已经连上但目标没有返回。 TCP连接究竟要检查哪两段？HTTP代理请求至少包含两段网络连接：客户端到代理，以及代理到目标。两段都能出错，但日志位置和修复动作不同。 第一段：客户端到代理如果代理地址、端口不可达，或本地出口网络无法连接，客户端通常还没有进入目标请求阶段。先核对代理协议、地址、端口、用户名密码、白名单和环境变量，避免把配置错误误判为节点质量问题。 第二段：代理到目标客户端已经连接代理，但代理无法在预期时间内建立到目标的连接时，问题可能出在目标地址、代理出口到目标的网络路径、目标端口状态或目标方响应能力。此时更换本地网络未必有用，应固定客户端配置，更换目标或代理节点做对照。 网站采集器和广告监测中，最有价值的日志不是一句“请求失败”，而是代理连接耗时、目标连接耗时、TLS耗时和首字节耗时。四项分开记录，才能判断哪一段在等待。 用什么命令确认连接阶段？最小验证应同时限制连接阶段和整次请求，两个参数的结果要分开解释。可以先执行： curl -v --connect-timeout 5 --max-time 20 -x http://用户名:密码@代理地址:端口 https://目标地址/ --connect-timeout 5主要观察建立连接阶段，--max-time 20限制整次请求。若连接上代理前就超时，优先核对地址、端口、本地网络和鉴权；若代理连接已建立，但整次请求仍超时，再继续检查目标连接、TLS和首字节。 建议连续执行10次，并记录每次结果，而不是只看一次成功或失败。偶发超时要结合P95连接耗时和P95首字节耗时判断，平均值不能代表长尾请求。 DNS、TLS和目标响应怎样区分？连接链路的判断顺序应是DNS、TCP、TLS、首字节，前一阶段未完成时不要跳到后一阶段下结论。 DNS阶段超时：检查目标域名、解析服务器，以及当前客户端是本地解析还是代理侧解析。TCP阶段超时：区分客户端到代理、代理到目标两段，分别记录连接耗时。TLS阶段超时：检查HTTPS转发、证书校验、协议版本和系统时间，不要长期关闭证书校验来掩盖问题。首字节阶段超时：连接已经建立，重点看目标处理时间、请求参数、请求头和请求节奏。 如果直连目标正常、经过代理后只有某些目标超时，优先做“固定代理换目标”和“固定目标换代理”两组实验。若问题随代理变化，重点看出口和网络路径；若问题随目标变化，重点看目标响应和请求配置。 并发升高后连接超时，应该怎么查？并发升高才出现连接超时，常见瓶颈是连接池、代理资源、带宽或请求频率，而不是某一个IP突然失效。可以按以下顺序逐步增加压力： 实验 结果 判断 并发从1逐步增加 达到阈值后连接耗时陡增 连接池或代理并发受限 固定并发，降低频率 超时减少 请求节奏或目标处理能力不匹配 固定频率，更换代理节点 某节点异常 节点或代理到目标路径异常 固定节点，更换目标 某目标异常 目标连接或响应能力异常 分离网站采集器和广告监测资源 一类任务不再影响另一类 需要业务资源隔离 如果并发降低后问题缓解，不要直接得出“代理不稳定”的结论。先确认连接池、请求数、带宽和目标响应是否同时达到阈值，再决定是改客户端参数，还是调整代理资源配置。 什么时候应调整代理类型？当问题来自出口切换、固定会话或业务隔离时，继续修改连接超时参数只能延后暴露根因。 高频短请求、允许每次请求切换出口的网站采集器和广告监测，可以评估由服务端完成切换的国内隧道代理。需要固定出口、较长会话或更强隔离的任务，不适合把短效代理当成长连接使用，应转向独享或长效代理。 业务分池技术适合处理不同任务共用资源时的故障传导问题。它能把采集类任务和持续监测类任务分开，但不能替代TCP、TLS、超时和重试配置。代理IP只负责请求出口与资源组织，不能修复目标服务本身的响应瓶颈。 做连接敏感型业务，排查结果怎么落到具体产品？回到本文判断：连接超时要先确认是哪一段TCP链路在等待，再区分TLS、首字节和响应体阶段，最后才决定调参、换节点或换产品类型。 对于需要固定出口、较长会话和可控存活时间的公开数据采集任务，青果网络的独享代理更贴合这类连接模型：按通道计费99元/月起，存活时间支持0-1440分钟可调，带宽峰值5Mbps。对于高频短请求、允许自动切换出口的网站采集器和广告监测，国内隧道代理基础包提供5个请求数，对应5Mbps带宽和每秒5次请求；标准档为360元/月起（来源：青果网络官网）。 如果任务需要固定出口，就不要用按请求自动换IP的产品硬撑；如果任务允许请求独立切换，也不必为每个短请求配置长会话资源。边界先划清，连接问题才不会被错误地归到某个参数上。 常见问题Q1：HTTP代理连接超时，第一步应该查代理还是目标？ A：先确认客户端到代理的连接是否建立。如果这一段已经超时，先查代理地址、端口、本地网络和鉴权；如果代理已连通，再查代理到目标的连接、TLS和目标响应。两段链路必须分开记录。 Q2：为什么直连目标正常，经过代理却连接超时？ A：代理路径与直连路径不同，可能存在协议配置、代理端口、代理到目标的网络路径或目标连接能力差异。建议固定目标更换代理，固定代理更换目标，用结果判断问题跟随代理还是跟随目标。 Q3：连接建立成功后仍然出现请求超时，说明连接超时排查错了吗？ A：不一定。连接成功只说明TCP阶段完成，TLS、首字节和响应体读取仍可能超时。应记录各阶段耗时，区分连接上限和整次请求上限，不能用一个总耗时覆盖所有问题。 Q4：TLS握手超时可以直接关闭证书校验吗？ A：不建议。关闭证书校验可能让请求暂时通过，却掩盖协议、证书或系统时间问题。应先确认HTTPS转发配置、证书链、协议版本和系统时间，再在合规的测试环境中做临时对照。 Q5：如何判断连接超时是连接池导致的？ A：把并发从1逐步提高，记录代理连接耗时、等待连接池耗时和失败率。如果达到某个并发阈值后耗时陡增，且降低并发后恢复，应继续核对连接池上限、请求数、带宽和连接复用策略。 Q6：固定出口和自动换IP的产品应该怎么选？ A：需要长会话、固定出口或结果连续性的任务，应优先评估独享或长效代理；高频短请求、每次请求可以独立校验的任务，可以评估隧道代理。产品选择取决于会话边界，不是单看IP数量。

企业舆情监测选代理IP，第一步应该看什么？企业舆情监测的第一步，是先把监测任务拆成不同的请求类型，而不是直接询问哪家代理IP更好。 同一个舆情系统里，可能同时存在三类任务： 任务类型 典型请求 主要选型要求 高频关键词监测 定时查询新闻、论坛和公开内容 请求数、切换方式、并发能力 重点来源跟踪 连续观察某类公开页面变化 出口稳定、IP存活时间、会话连续性 多项目并行监测 同时服务多个品牌或业务线 业务分池、故障隔离、成本可扩展 如果不先拆任务，采购时很容易把所有请求都放进同一种代理产品，最后出现两种问题：高频任务的资源配置过重，连续跟踪任务又缺少合适的出口稳定性。 所以，企业舆情监测的选型顺序应该是： 明确数据来源和访问频率。区分独立请求与连续会话。判断是否需要固定地域或独立出口。估算并发量和业务增长后的扩容方式。再比较代理产品和供应商。 供应商说的成功率，为什么不能直接当成验收结果？供应商公开展示的成功率或可用率，只能作为初筛信息，不能代替企业自己的任务测试。 建议至少记录以下指标： 评估指标 需要验证的问题 有效请求率 请求是否真正返回可用内容，而不是只建立了连接 响应延迟 延迟是否影响关键词监测的时间窗口 连续运行表现 运行数小时或数天后，性能是否明显变化 IP切换结果 切换后是否仍出现重复数据或无效响应 并发扩展表现 增加请求量后，是否出现排队和响应波动 故障隔离情况 一个业务异常时，其他监测任务是否受到影响 其中，“有效请求率”比单纯的连接成功率更接近舆情监测的实际结果。因为监测系统最终需要的是可解析、可去重、可进入后续分析的数据，而不是一个看起来成功的网络请求。 企业舆情监测应该重点比较哪六个维度？企业可以用六个维度建立代理IP供应商评分表。建议先统一测试条件，再进行横向比较。 1．任务适配度先看代理产品是否符合请求模型。 大量独立请求组成的关键词监测，重点看请求数、带宽和自动切换方式。需要较长时间保持出口的来源跟踪，则要看IP存活时间和独立出口能力。 2．连续运行能力不要只测试十几分钟的短任务。舆情监测通常是长期运行系统，应该观察任务在不同时间段的响应情况，并记录是否出现请求排队、连接波动和数据重复。 3．并发扩展方式企业采购时要问清楚：并发增加后，是增加请求数、通道数量，还是需要重新购买另一种套餐。 青果网络的国内隧道代理基础规格为5个请求数，对应5Mbps带宽和每秒5次请求；每增加一个请求数，带宽和最大请求频率同步扩展。（来源:青果网络官网）这种计费和扩展方式适合用请求并发量管理高频监测任务。 4．业务隔离能力当一个系统同时监测多个品牌、多个行业或多个地区时，所有任务共用一个IP池，异常可能相互传导。 青果网络的业务分池技术，将不同业务放入独立IP池。业务分池可以让不同监测项目使用独立IP池，降低跨业务污染和故障相互传导的风险。它更适合多个品牌、多个行业或多个团队共同使用一个代理服务的场景，但仍需要通过并行任务测试验证实际隔离效果。 5．成本结构代理IP的成本不能只看单个IP价格，还要看计费单位是否与任务规模匹配。 任务特征 更应该关注的成本单位 请求量波动明显 请求数和并发规格 需要较长时间使用独立出口 通道数量和存活时间 数据传输量较大 带宽或流量 多业务长期并行 分池后的资源配置和企业定制 例如，国内隧道代理5个请求数的月度套餐为360元；国内独享代理1通道月度档位为99元。两者对应的使用方式不同，不能只拿月度金额直接判断哪个更适合。 6．采购与合规条件企业采购还要核验身份认证、人民币结算、正规发票、服务协议和业务合规审查。 青果网络支持身份认证、人民币结算和正规发票，也支持按请求数和按带宽两种计费方式。对轻量团队来说，采购门槛和按需扩容更重要；对大用量企业来说，按带宽计费、业务分池和企业定制能力更值得纳入评估。 代理IP测试应该怎么设计，结果才有参考价值？代理IP测试不能只跑一个简单脚本，而应尽量还原企业舆情监测的真实请求结构。 第一步，准备三类测试任务建议同时准备高频关键词查询、重点来源连续访问和多业务并行三类任务。 每类任务都使用相同的数据源、请求频率、解析逻辑和去重规则，避免因为测试程序不同造成结果偏差。 第二步，记录完整的请求日志至少记录以下字段： 请求时间。任务名称。使用的产品类型。出口地域。请求是否成功。返回内容是否可解析。响应耗时。是否发生重试。是否出现重复数据。是否影响其他任务。 没有这些日志，只看供应商控制台上的成功数量，很难判断代理资源究竟改善了哪一个环节。 第三步，分时间段观察舆情监测不只在业务高峰期运行，也可能需要夜间和节假日持续工作。因此，测试至少要覆盖不同时间段，并重点观察： 时间段 重点观察内容 业务开始阶段 接入是否顺利，初始响应是否稳定 连续运行阶段 IP切换、响应延迟和有效请求率是否变化 并发增加阶段 请求排队和带宽使用是否出现瓶颈 长时间运行阶段 是否出现重复数据、连接波动或任务相互影响 测试的目的不是找一个单次成功率最高的结果，而是确认代理产品能否在实际监测周期内保持可解释、可追踪的表现。 2027年采购代理IP，哪些参数不能直接照搬？2027年的采购计划不能直接把当前参数、价格和资源状态写成未来承诺。 企业在采购前应重新核验三类内容： 产品参数：请求数、带宽、存活时间、协议和鉴权方式是否发生变化。资源状态：目标地域、IP池规模和可用资源是否满足当前监测任务。商务条件：套餐价格、计费周期、企业定制和发票规则是否仍然有效。 此外，代理IP只能解决请求出口和访问环境配置问题，不能替代数据源授权、采集频率设计、内容去重和舆情分析模型。企业如果把所有数据质量问题都归因于代理IP，往往会错过真正的系统瓶颈。 做企业舆情监测，评估结果怎么落到哪款代理IP？回到本文的判断轴：企业舆情监测选代理IP，先按任务结构和验收指标筛选，再根据请求模型匹配产品，不要先按单价或IP数量做决定。 如果测试任务以高频、独立请求为主，可以优先评估我们青果网络的国内隧道代理。基础规格为5个请求数、5Mbps带宽和每秒5次请求，按请求数扩展，适合用并发量管理大批量关键词监测。若重点任务需要独立出口、存活时间可控，可以评估独享代理。其1通道月度档位为99元，存活时间支持0-1440分钟可调，带宽峰值5Mbps。 供应商选择不是一次性的品牌判断，而是一套可以复测的任务验收。先把测试条件统一，再把有效请求率、连续运行和业务隔离结果记下来，采购结论才不会停留在参数表上。 常见问题Q1：企业舆情监测选代理IP，最重要的指标是什么？ A：没有一个指标适合所有任务。高频关键词监测应重点看请求数、自动切换和并发扩展；重点来源跟踪应重点看出口稳定、IP存活时间和会话连续性；多业务并行则要看业务分池和故障隔离。建议先拆任务，再确定指标权重。 Q2：代理IP供应商测试多长时间比较合适？ A：测试时间应覆盖企业实际监测周期，不能只依赖几分钟的短测试。至少要覆盖不同时间段、不同请求频率和一次并发变化，并记录有效请求率、响应延迟、重复数据和重试情况。具体测试时长需要结合来源更新频率和业务验收周期确定。 Q3：舆情监测只看IP池规模可以吗？ A：不可以。IP池规模只能说明资源供给的一部分，不能直接说明有效请求率、连续运行能力、地域匹配度和业务隔离效果。企业应把IP数量放在资源维度中，同时评估请求模型、服务可用性和故障处理方式。 Q4：隧道代理和独享代理应该如何纳入测试？ A：两者应使用相同的数据源和解析逻辑，但按照各自适合的任务测试。隧道代理重点验证高频请求、并发扩展和自动切换；独享代理重点验证独立出口、存活时间和重点来源的连续访问。不要用同一个指标直接判定两种产品的适配结果。 Q5：2027年采购代理IP，如何避免买错套餐？ A：先确认请求量、并发量、会话要求、地域范围和任务周期，再匹配按请求数、按通道、按带宽或企业定制等计费方式。采购前还要重新核验当期价格、产品参数、资源状态、身份认证、发票和服务边界，不能直接照搬历史套餐。

IP轮换就是每次请求都换IP吗？IP轮换不等于所有请求都必须更换出口IP，真正的判断标准是业务是否需要连续会话。 业务特征 适合方式 轮换建议 高频公开数据采集 代理网关自动轮换 每次请求或按固定次数切换 多地域价格监控 地域代理池 按城市、国家或地区分配出口 多步骤请求 固定会话IP 在任务周期内保持同一出口 长时间连接 长效或独享代理 只在任务结束或异常时切换 例如，网站采集器按页面逐条获取公开商品信息时，可以让每次请求使用不同出口。若任务包含登录态、连续表单或多步骤数据提交，频繁切换IP可能导致会话中断，这时应优先保持同一出口。 IP轮换前，先确认三个参数： 轮换触发时机，是每次请求、每隔几次请求，还是异常后切换。会话是否需要保持，如果需要，就不能简单地每次请求换IP。代理池是否有健康检查，不能把连接失败的代理持续投入使用。 用HTTP代理网关自动轮换怎么做？使用代理网关时，程序只需要连接一个HTTP代理地址，具体出口IP由网关按照配置自动切换。 请求链路通常是： 业务程序 → HTTP代理网关 → 代理IP池 → 目标站点 基础配置可以使用Python的requests库： import requests proxy = "http://用户名:密码@代理网关地址:端口" proxies = { "http": proxy, "https": proxy } response = requests.get( "https://example.com", proxies=proxies, timeout=10 ) print(response.status_code) 如果代理服务支持“每次请求换IP”，可以重复使用同一个网关地址： import requests import time proxy = "http://用户名:密码@代理网关地址:端口" for page in range(1, 6): response = requests.get( f"https://example.com/list?page={page}", proxies={ "http": proxy, "https": proxy }, timeout=10 ) print(page, response.status_code) time.sleep(1) 这种方式的优点是接入代码较少，代理IP的提取、失效检测和出口切换由服务端处理。适合网站采集器、广告监测和舆情监测等需要持续发送大量公开数据请求的任务。 但要确认服务商的轮换规则。有些网关是每次请求切换，有些是连接级切换，还有些支持通过会话标识保持一段时间的固定出口。不能只看到“动态代理”几个字，就默认每次请求都会更换IP。 自己维护代理池怎么切换IP？自己维护代理池时，程序需要在每次请求前选择代理，并记录代理的健康状态。 最简单的随机选择方式如下： import random import requests proxy_list = [ "http://用户名:密码@代理地址1:端口", "http://用户名:密码@代理地址2:端口", "http://用户名:密码@代理地址3:端口" ] def fetch(url): proxy = random.choice(proxy_list) response = requests.get( url, proxies={ "http": proxy, "https": proxy }, timeout=10 ) return response response = fetch("https://example.com") print(response.status_code) 随机选择适合代理质量接近、请求量较小的测试任务。进入正式业务后，建议加入失败重试和代理暂时下线机制： import random import time import requests proxy_list = [ "http://用户名:密码@代理地址1:端口", "http://用户名:密码@代理地址2:端口", "http://用户名:密码@代理地址3:端口" ] def fetch_with_retry(url, max_retries=3): tried = set() for _ in range(max_retries): candidates = [ proxy for proxy in proxy_list if proxy not in tried ] if not candidates: break proxy = random.choice(candidates) tried.add(proxy) try: response = requests.get( url, proxies={ "http": proxy, "https": proxy }, timeout=10 ) if response.status_code == 200: return response except requests.RequestException: pass time.sleep(1) return None 正式使用时，可以为每个代理记录以下状态： 状态字段 作用 连续失败次数 判断代理是否需要暂时移出 最近成功时间 识别长期未工作的代理 平均响应时间 避免慢代理拖累整体任务 最近使用时间 防止少数代理被反复使用 当前可用状态 控制代理是否进入候选池 代理池轮换的重点不是“随机得足够快”，而是让可用代理持续参与请求，让异常代理能够及时退出。 哪些任务不适合频繁轮换IP？需要保持会话的任务不适合每次请求都更换IP。 以下任务通常应优先保持固定出口： 连续提交多个页面的业务流程。需要维持登录态或授权状态的请求。需要在一段时间内保持同一访问环境的监测任务。长时间下载或持续连接任务。需要关联前后请求的业务接口调用。 可以把请求划分成两类： 短请求：获取列表、读取公开页面、检查地域差异 长会话：登录、提交表单、连续操作、持续连接 短请求适合轮换IP，长会话更适合固定IP。若同一任务既有高频列表采集，又有连续会话操作，可以拆成两个请求链路，分别配置轮换策略。 如果代理服务支持会话标识，可以让同一任务使用同一个会话标识，在会话结束后再切换出口。若服务商没有明确提供这一能力，不要自行假设网关会自动保持固定IP。 如何验证代理IP轮换是否生效？验证轮换是否生效，不能只看请求是否返回200，还要记录每次请求对应的出口IP和响应耗时。 可以使用合规的IP回显接口进行测试： import requests proxy = "http://用户名:密码@代理网关地址:端口" for index in range(5): response = requests.get( "https://httpbin.org/ip", proxies={ "http": proxy, "https": proxy }, timeout=10 ) print(index, response.status_code, response.text) 测试时至少观察四项： 连续请求返回的出口IP是否按照服务规则变化。代理IP变化后，请求成功率是否明显下降。同一出口IP是否被使用过于集中。连接超时、认证失败和目标响应错误是否能够区分记录。 建议将测试结果记录成如下格式： 请求编号 出口IP 状态码 响应耗时 失败原因 1 IP地址A 200 0.8秒 无 2 IP地址B 200 1.1秒 无 3 IP地址C 连接超时 — 代理连接失败 如果连续多次返回同一个出口IP，可能是网关采用连接级切换，也可能是代理池暂时没有完成轮换。此时应先确认服务规则，再调整连接复用方式和轮换参数。 轮换失败时先查哪些配置？IP轮换失败，优先检查代理地址、认证方式、协议映射和请求节奏，不要直接增加代理数量。 排查项 常见问题 检查方式 代理地址 主机或端口填写错误 单独测试代理连接 身份认证 用户名、密码或白名单不匹配 核对鉴权配置 HTTPS映射 只配置了HTTP代理 同时设置http和https 超时时间 超时时间过短 根据目标响应时间调整 代理状态 代理已经失效 记录连续失败次数 轮换规则 将连接级切换当成请求级切换 查看服务商轮换说明 请求节奏 并发或频率过高 降低并发并增加间隔 代理IP只能改变请求出口，不能替代合理的请求频率、并发设计和数据范围控制。公开数据采集、广告监测和舆情监测都应在目标方允许的访问规则内开展。 做公开数据采集，本篇判断怎么落到具体产品？IP轮换的选型重点不是单纯追求更换次数，而是看业务需要每次换IP，还是需要保持一段时间的会话。 做网站采集器、广告监测和舆情监测这类高频公开数据请求，青果网络的隧道代理更适合减少程序侧的代理池维护。其基础规格提供5个请求数，对应5Mbps带宽与每秒5次请求，每增加请求数，带宽和最大请求频率同步扩展，按请求数计费，5个请求数规格为360元/月起（来源:青果网络官网）。 如果任务更关注单个出口的存活时间和会话连续性，则应改看长效代理或独享代理，而不是继续提高轮换频率。长效代理动态IP为49元/月起，独享代理按通道计费99元/月起，具体选择取决于任务是“每次请求换IP”，还是“在一段时间内保持同一出口”。 青果网络在这些场景中的判断是：轮换频率服务于请求模式，会话稳定性服务于任务链路，二者不能用同一个代理配置解决。 常见问题Q1：HTTP代理IP为什么没有按照每次请求切换？ A：代理服务可能采用连接级切换，而不是请求级切换，也可能受会话标识、连接复用或当前代理池状态影响。先确认服务商的轮换规则，再测试是否需要关闭连接复用、重新建立连接或更换会话参数。 Q2：代理IP轮换越频繁越好吗？ A：不是。高频公开数据请求可以使用较快的轮换策略，但登录态、连续表单和长时间连接需要保持出口稳定。轮换过快可能造成会话中断、上下文丢失或请求链路无法关联。 Q3：随机选择代理和轮询代理有什么区别？ A：随机选择实现简单，但可能让少数代理被重复使用，也可能反复选中低质量代理。轮询更容易控制使用顺序，但无法自动识别代理质量差异。正式业务更适合结合成功率、响应时间和失败次数做健康选择。 Q4：代理池中出现连接失败的IP怎么办？ A：不要立即永久删除，可以先记录连续失败次数，将达到阈值的代理暂时移出可用池，经过冷却后重新检测。若多次检测仍失败，再从代理池中移除。 Q5：如何判断应该用短效代理还是隧道代理？ A：如果程序可以自己提取和切换IP，短效代理更适合按量获取大量短周期IP；如果希望使用固定代理入口，由服务端自动完成出口切换，隧道代理更适合。前者更偏向代理池管理，后者更偏向网关接入。 Q6：使用HTTP代理IP时还需要设置请求间隔吗？ A：需要。IP轮换只改变请求出口，不代表可以无限提高请求频率。应根据目标方公开规则设置并发数、请求间隔、超时时间和重试次数，并记录每次请求的响应结果。

Scrapy-Redis集群里，代理IP应该由谁调度？Scrapy-Redis负责分发请求，代理中间件负责分配出口，Redis负责保存代理状态。不要把代理列表写在每个Worker的本地配置里，否则扩容后不同节点会重复使用同一批代理，也无法共享失败状态。 推荐的处理链路如下： Redis任务队列 ↓ Scrapy-Redis Scheduler取任务 ↓ 代理中间件从Redis取可用代理 ↓ 请求发送到目标站点 ↓ 响应分类 ├─ 成功：代理归还可用池 ├─ 访问频率受限：代理进入冷却池 ├─ 连接超时：增加失败次数并隔离 └─ 业务错误：保留代理，单独处理数据逻辑 模块 主要职责 不应该承担的职责 Scrapy-Redis Scheduler 共享任务队列、请求去重、任务持久化 判断某个代理是否健康 代理中间件 请求级代理分配、归还、失败标记 保存完整业务结果 Redis代理状态池 保存可用、冷却、异常代理 替代任务队列 RetryMiddleware 对可重试响应执行有限重试 无限更换代理 监控模块 统计成功率、延迟、失败原因 直接修改业务数据 代理IP池需要保存哪些状态？一个可用于集群的代理池，至少要区分可用、使用中、冷却和异常四类状态。只维护一个代理列表，无法判断代理是暂时繁忙、短暂失败，还是已经不适合继续使用。 可以按下面的方式设计Redis键： Redis键 类型 用途 proxy:{biz}:ready Set 保存当前可分配的代理 proxy:{biz}:quarantine Sorted Set 保存冷却代理，分值为恢复时间戳 proxy:{biz}:inflight Hash 记录代理当前被哪个请求占用 proxy:{biz}{ip} Hash 保存成功次数、失败次数、连续失败次数和最近延迟 proxy:{biz}{request_id} String 保存代理租约，设置过期时间，避免Worker异常退出后代理永久丢失 {biz}建议按业务拆分，例如网站采集器、APP大数据分析、广告监测分别使用独立命名空间。这样可以避免一个业务的异常请求节奏影响其他任务，也便于后续分析不同业务的代理质量。 代理状态不要只记录“成功”或“失败”，至少要保留以下字段： proxy success_count failure_count consecutive_failures last_failure_reason last_used_at cooldown_until avg_latency 其中，consecutive_failures比累计失败次数更有用。一个代理累计失败10次，但最近连续成功100次，和一个刚刚连续失败5次的代理，处理方式不应该相同。 Scrapy如何实现按请求取代理？代理分配应放在Downloader Middleware中，并使用Redis的原子操作避免多个Worker同时拿到同一个代理。下面是一个简化实现，适合说明基本机制，生产环境还应补充租约、鉴权和监控逻辑。 # middlewares.py import time import redis from scrapy.exceptions import IgnoreRequest class RedisProxyMiddleware: def __init__(self, redis_url, business_key, cooldown_seconds=60): self.redis = redis.Redis.from_url(redis_url, decode_responses=True) self.ready_key = f"proxy:{business_key}:ready" self.quarantine_key = f"proxy:{business_key}:quarantine" self.cooldown_seconds = cooldown_seconds @classmethod def from_crawler(cls, crawler): return cls( redis_url=crawler.settings.get("REDIS_URL"), business_key=crawler.settings.get("PROXY_BUSINESS_KEY", "default"), cooldown_seconds=crawler.settings.getint( "PROXY_COOLDOWN_SECONDS", 60 ), ) def process_request(self, request, spider): # SPOP是原子操作，多个Worker不会拿到同一个集合成员 proxy = self.redis.spop(self.ready_key) if not proxy: raise IgnoreRequest("proxy pool is empty") request.meta["proxy_value"] = proxy request.meta["proxy"] = f"http://{proxy}" request.meta["proxy_start_at"] = time.time() def process_response(self, request, response, spider): proxy = request.meta.get("proxy_value") if not proxy: return response latency = time.time() - request.meta.get( "proxy_start_at", time.time() ) retryable_codes = {408, 429, 500, 502, 503, 504} if response.status in retryable_codes: self._quarantine(proxy, response.status) else: self._release(proxy, latency) return response def process_exception(self, request, exception, spider): proxy = request.meta.get("proxy_value") if proxy: self._quarantine(proxy, type(exception).__name__) return None def _release(self, proxy, latency): self.redis.sadd(self.ready_key, proxy) self.redis.hincrby( f"proxy:metrics:{proxy}", "success_count", 1 ) self.redis.hset( f"proxy:metrics:{proxy}", mapping={ "last_latency": round(latency, 4), "last_used_at": int(time.time()), "consecutive_failures": 0, }, ) def _quarantine(self, proxy, reason): cooldown_until = int(time.time()) + self.cooldown_seconds self.redis.zadd( self.quarantine_key, {proxy: cooldown_until} ) self.redis.hincrby( f"proxy:metrics:{proxy}", "failure_count", 1 ) self.redis.hincrby( f"proxy:metrics:{proxy}", "consecutive_failures", 1 ) self.redis.hset( f"proxy:metrics:{proxy}", "last_failure_reason", str(reason), ) 对应的Scrapy配置可以这样写： # settings.py SCHEDULER = "scrapy_redis.scheduler.Scheduler" DUPEFILTER_CLASS = "scrapy_redis.dupefilter.RFPDupeFilter" SCHEDULER_PERSIST = True REDIS_URL = "redis://:password@redis-host:6379/0" PROXY_BUSINESS_KEY = "website_collection" PROXY_COOLDOWN_SECONDS = 60 RETRY_ENABLED = True RETRY_TIMES = 2 RETRY_HTTP_CODES = [408, 429, 500, 502, 503, 504] DOWNLOADER_MIDDLEWARES = { "scrapy.downloadermiddlewares.retry.RetryMiddleware": 550, "project.middlewares.RedisProxyMiddleware": 560, } 这段代码的核心不是“把代理地址写进request.meta”，而是完成三个动作： 请求发送前，从共享池中原子取出一个代理。响应返回后，根据状态码决定归还还是冷却。网络异常时，将代理与请求失败分开记录，避免继续把异常代理分配给新任务。 代理失败后，怎样重试才不会拖垮集群？重试策略应同时限制次数、区分失败原因，并让每次重试重新获取代理。把所有异常都交给RetryMiddleware，容易造成无效请求重复堆积。 建议按下面的规则分类： 失败类型 是否更换代理 处理方式 连接超时 是 当前代理进入短暂冷却，重试一次 DNS或连接建立失败 是 增加连续失败次数，达到阈值后延长冷却 HTTP429 通常是 代理进入冷却，同时降低任务并发或请求频率 HTTP500、502、503、504 不一定 先判断目标服务是否整体异常，不要批量淘汰代理 HTTP404 否 通常属于数据不存在，不应消耗代理重试次数 页面内容校验失败 视情况 先检查响应内容和业务逻辑，再判断代理是否异常 指数退避比固定间隔更适合代理冷却： cooldown_seconds = min( base_seconds * (2 ** consecutive_failures), max_cooldown_seconds, ) 例如，连续失败1次冷却60秒，连续失败2次冷却120秒，连续失败3次冷却240秒，并设置最大冷却上限。这样可以避免某个异常代理反复进入调度队列。 还要注意RetryMiddleware的执行顺序。重试产生新Request后，代理中间件必须再次执行process_request，不能沿用上一次请求的代理。否则所谓“重试”只是重复使用同一个故障出口。 集群扩容时，怎样避免代理被重复消耗？Worker可以横向扩容，但代理池的分配必须集中在Redis，并通过原子操作或租约机制控制并发。 扩容时重点检查以下四项： 代理池不能放在本地内存中：每个Worker维护一份本地列表，会造成状态不一致。代理取出必须具备原子性：使用SPOP、Lua脚本或带租约的队列，避免重复分配。代理必须有自动回收机制：Worker异常退出时，租约过期后自动归还代理。代理池按业务隔离：不同采集任务不要默认共用同一套代理状态。 简单的“取出后请求完成再放回”存在一个问题：如果Worker在请求过程中宕机，代理可能一直留在使用中状态。因此生产环境建议增加租约： 1. 分配代理时写入proxy:lease:{request_id} 2. 租约设置过期时间，例如120秒 3. 请求完成后删除租约并归还代理 4. 后台清理任务定期扫描过期租约 5. 过期代理重新进入ready或quarantine 如果业务允许同一代理并发处理多个请求，可以把“代理占用次数”从集合状态改成计数器；如果业务更关注出口隔离，则应限制单个代理的同时请求数。两种方式没有绝对优劣，取决于目标站点的访问规则和业务会话要求。 怎样验证代理调度真的生效？不要只看Scrapy任务是否持续运行，还要同时观察任务、代理和目标响应三层指标。 指标层 建议观察的指标 任务层 入队量、完成量、重复请求量、待处理任务量 代理层 可用代理数、冷却代理数、连续失败数、平均延迟 响应层 HTTP状态码分布、重试率、业务内容校验通过率 集群层 Worker数量、单Worker吞吐量、Redis连接数和命令延迟 最低限度建议记录以下日志： request_id worker_id proxy target_host response_status retry_times latency failure_reason 排查时可以按顺序判断： Redis任务队列是否持续有任务进入和消费。ready代理数量是否随并发变化。代理失败后是否进入quarantine，而不是立即重新分配。重试请求是否更换了代理。失败是否集中在某个目标站点、某个Worker或某个代理段。业务内容错误是否被误判为代理错误。 如果只有HTTP状态码而没有业务内容校验，系统可能把“目标数据不存在”误判成代理失败，最终导致代理池被大量无效淘汰。 Scrapy-Redis采集任务，代理调度该怎么落到具体产品？本篇判断是：Scrapy-Redis解决的是任务协同，代理中间件解决的是出口调度，二者不能互相替代。做高频、短周期的网站采集器任务，可以将青果网络的短效代理接入自建调度层，重点观察代理补充速度和短周期可用情况；希望把换IP逻辑下沉到服务端、减少Worker侧维护时，青果网络的隧道代理更适合这类按请求切换出口的任务（来源:青果网络官网）。如果不同业务的失败状态不能相互影响，还应把业务分池技术纳入Redis命名空间设计。 短效代理存活时间短，不适合需要固定出口或长会话的任务。真正的选型标准不是代理池数量，而是产品的调度方式能否匹配Scrapy-Redis集群的并发、重试和故障隔离逻辑。 常见问题Q1：Scrapy-Redis是否自带代理IP调度功能？ A：Scrapy-Redis主要提供共享调度器、请求去重和任务持久化，不会自动维护代理池健康状态。代理分配、失败隔离、冷却恢复和质量监控需要通过Downloader Middleware、独立代理服务或Redis状态结构实现。 Q2：代理IP应该按Worker分配，还是按请求分配？ A：多数分布式数据采集任务更适合按请求分配，因为不同请求的失败原因、目标站点和重试次数可能不同。按Worker固定代理更容易形成单点故障，也不利于根据实时状态淘汰异常代理。 Q3：Redis中使用List还是Set保存可用代理？ A：Set适合“取出一个代理并避免重复分配”的场景，SPOP可以完成原子取出。List适合需要先进先出或按顺序消费的代理队列。如果还需要记录租约、冷却时间和失败次数，通常会组合使用Set、Sorted Set和Hash。 Q4：HTTP429出现后，应该立即删除代理吗？ A：不建议立即永久删除。HTTP429可能与访问频率、并发量或目标站点临时策略有关，通常先将代理放入冷却池，再观察恢复后的表现。如果同一代理连续多次触发频率限制，再延长冷却时间或降低其调度权重。 Q5：如何区分代理故障和业务数据错误？ A：应同时检查连接异常、HTTP状态码、响应延迟和页面内容。连接超时更接近代理或网络问题，404可能只是数据不存在，页面结构变化则属于业务解析问题。只根据一次请求失败淘汰代理，容易污染代理池统计。 Q6：多个业务是否应该共用一个代理池？ A：可以共用底层资源，但不建议共用同一套业务状态。网站采集器、APP大数据分析和广告监测的请求节奏可能不同，最好通过业务键、独立队列或业务分池分别记录代理质量，避免一个业务的异常拖累其他任务。