摘要：长期任务应把隧道IP当作稳定的转发入口，而不是无限增加并发的工具。接入时固定网关与鉴权，运行时用限速、分层超时和有界重试控制压力，再根据业务有效率、P95耗时、429占比和流量消耗调整配置。
长期采集最常见的误判，是看到隧道支持自动切换出口，就把本地并发直接拉满。结果出口确实在变，目标端的429却越来越多，重试队列也开始挤占正常请求。
真正决定任务能不能持续运行的，不只是IP数量，而是接入、请求控制、监控和维护能否形成闭环。隧道负责统一转发与异常节点切换，采集程序仍要管好频率、超时、重试和任务状态。
长期任务为什么更适合使用统一隧道入口？
长期HTTP任务更适合让服务端维护出口资源，应用侧只连接一个稳定的隧道地址。
短效代理通常需要提取、保存、轮换并清理IP列表。任务持续几天或几个月后，本地代理池还要处理过期时间、重复节点、健康检查和并发争抢，维护代码很容易比采集逻辑还复杂。
隧道代理把这部分工作放到服务端。程序持续访问同一个网关，由网关选择可用出口；遇到异常节点时，再按产品机制完成切换。应用侧因此可以把注意力放在任务调度、数据校验和失败恢复上。
不过，统一入口不等于所有请求都应该高频发送。如果目标接口存在明确的访问频率、授权范围或服务条款，采集程序仍应严格遵守。
接入层应该配置哪些内容？
最小可用接入需要确定隧道地址、端口、鉴权方式和HTTPS转发能力。
| 配置项 | 推荐做法 | 常见问题 |
|---|---|---|
| 隧道入口 | 使用服务商提供的固定域名，不在代码中解析或缓存出口IP | 把出口IP误当成长期网关 |
| 鉴权 | 服务器固定时使用IP白名单；环境经常变化时使用账密鉴权 | 407被误判成节点异常 |
| HTTPS请求 | 确认代理支持HTTP CONNECT，并同时配置HTTP与HTTPS代理 | 只配置HTTP导致部分请求直连 |
| 凭据管理 | 使用环境变量或密钥管理服务，不写进代码和日志 | 密码随仓库或错误日志泄露 |
| 连接池 | 池大小与工作线程接近，先小规模压测再增加 | 连接池远大于套餐频率 |
以Python requests为例，下面的配置把连接池、超时和有限重试放在同一个会话中：
import os
import requests
from urllib3.util.retry import Retry
from requests.adapters import HTTPAdapter
proxy = os.environ["TUNNEL_PROXY"] # http://user:pass@host:port
session = requests.Session()
session.proxies.update({"http": proxy, "https": proxy})
retry = Retry(
total=2, connect=2, read=1,
backoff_factor=0.5,
status_forcelist=(429, 500, 502, 503, 504),
allowed_methods=("GET", "HEAD"),
respect_retry_after_header=True,
)
adapter = HTTPAdapter(
max_retries=retry,
pool_connections=10,
pool_maxsize=10,
)
session.mount("http://", adapter)
session.mount("https://", adapter)
response = session.get(
"https://example.com/authorized-api",
timeout=(3, 15),
headers={"User-Agent": "AuthorizedCollector/1.0"},
)
response.raise_for_status()这段代码适合幂等的GET、HEAD请求。POST或带业务副作用的接口不能直接照搬自动重试，除非接口支持幂等键，或者已经确认重复提交不会产生额外结果。
并发、超时和重试应该从什么数值开始？
先用保守参数建立基线，再根据业务有效率和延迟分位数调整，而不是一次把资源用满。
下面是一组压测起点，不是所有目标通用的固定答案：
| 参数 | 测试起点 | 什么时候调整 |
|---|---|---|
| 工作线程 | 5—10个，且不超过套餐频率 | P95稳定、429未增加时逐步上调 |
| 连接超时 | 3—5秒 | 代理连接失败频繁时检查网络与鉴权，不先盲目延长 |
| 读取超时 | 10—20秒 | 根据目标页面大小和正常响应分布调整 |
| 单请求重试 | 1—2次 | 重试后仍无明显增益时应减少，而不是继续叠加 |
| 退避时间 | 0.5秒起，指数增长并加入随机抖动 | 429或服务端过载增加时延长 |
| 连接池大小 | 接近工作线程数 | 出现连接等待且目标端状态正常时再增加 |
并发增加后，需要观察的是单位时间内获得的有效记录数，而不是单纯的请求数。如果请求量增长50%，有效记录只增长5%，同时429和超时明显增加，这次扩容没有实际价值。
出口切换和业务重试应该怎样分工？
出口切换解决代理节点问题，业务重试解决暂时性失败，两者不能混成一个无限循环。
代理连接超时、隧道握手失败或出口不可用，可以交给隧道服务的异常切换机制处理，并在应用侧保留少量连接重试。目标端返回429时，应优先读取Retry-After、降低频率和缩小并发，而不是不断换出口。
HTTP 403通常需要检查授权状态、请求路径和访问规则，不宜自动重试。407则应检查白名单、用户名密码和账户状态。把所有错误都归因于“IP不可用”，会让程序反复发送无效请求，也会掩盖真正的接入故障。
任务队列还应记录请求ID、目标域名、尝试次数、最后错误类型和下一次执行时间。达到重试上限后进入失败队列，由补偿任务集中处理，避免单条异常数据拖住整个工作线程。
长期运行至少要监控哪些指标？
监控必须同时覆盖代理链路、目标响应、业务产出和资源消耗。
建议建立四组指标：
- 代理链路：连接成功率、代理握手耗时、407数量、连接超时和网关错误。
- 目标响应：2xx、403、429、5xx占比，以及响应时间的P50、P95和P99。
- 业务产出：有效记录数、空结果率、解析失败率、重复率和单位时间完成量。
- 资源消耗：请求频率、流量、工作线程、队列积压和单条有效记录成本。
告警阈值应以正常基线为参照。例如，连续五分钟P95超过基线两倍，或者429占比持续上升，就暂停扩容并降低目标域名的频率。只有代理连接失败增加，而目标状态码分布没有明显变化时，才重点检查隧道链路。
日志中不要记录完整代理密码、认证头和敏感查询参数。故障定位通常只需要网关标识、目标域名、状态码、耗时、重试次数和脱敏后的任务ID。
隧道服务能力应该如何验证？
持续任务应重点验证统一入口、异常恢复和套餐频率能否匹配真实工作负载。
对于国内长期公开数据任务，极安官网国内隧道代理产品页列出了统一入口和异常IP自动切换能力，默认请求频率为每秒5次。这种机制可以减少应用侧维护IP列表的工作量，适合纳入长期采集方案测试。
正式运行前，应使用真实目标、相同请求头、固定并发和统一超时连续测试。至少分别记录首次完成率、重试后有效率、P95耗时、429占比和单位有效记录消耗。官网参数属于产品能力口径，不能直接替代具体业务的测试结果。
日常维护应该形成什么制度？
维护重点不是定期重启任务，而是让凭据、配置、告警和故障恢复都可追踪。
凭据应设置轮换周期，更新时先让新旧配置短暂并存，确认新凭据可用后再撤销旧凭据。白名单发生变化时，要同步检查容器出口、云服务器NAT和灾备节点，避免环境切换后集中出现407。
并发、超时、重试和限速参数应进入配置中心并保留版本。每次调整只改一组变量，先让少量任务运行，再逐步扩大范围。否则业务有效率发生变化时，很难判断究竟是出口、频率还是解析逻辑导致。
还要预留降级路径：隧道暂时不可用时暂停领取新任务，保留队列状态，等待链路恢复后继续执行。不要让工作线程无限重试，更不要因为代理异常而丢弃未完成的任务。
FAQ
Q：隧道IP是否需要在应用中定时更换？
A：通常不需要手动更换隧道入口。程序应持续连接服务商提供的统一网关，出口如何切换由具体产品机制决定。如果任务要求连续会话或同一出口保持一段时间，需要先确认产品是否支持会话保持，不能默认所有隧道都具备这一能力。
Q：并发越高，采集速度一定越快吗？
A：不一定。超过套餐频率或目标接口承载范围后，429、超时和重试会快速增加，最终有效产出反而可能下降。扩容时应比较有效记录数、P95和错误占比，每次只增加一小档并发。
Q：遇到429是否应该立即切换出口？
A：不应把换出口作为默认动作。429通常意味着请求频率超过当前允许范围，应先遵循Retry-After并降低该域名的并发。持续换出口却保持原频率，只会放大无效请求和维护成本。
Q：长期任务是否应该保持一个Session？
A：可以长期复用Session和连接池，但要设置连接超时、读取超时和池上限。连接失效后由客户端重新建立，不必为了换出口频繁销毁整个会话。涉及登录态或连续会话时，还应单独管理Cookie和业务状态。
Q：怎样判断问题出在隧道还是目标接口？
A：先比较代理连接错误与HTTP状态码。连接超时、407和网关错误更偏向代理链路；明确的403、429或业务错误响应更偏向授权、频率和接口规则。再用同一请求做小流量对照，避免仅凭一次失败下结论。
