航旅票价监测成功率下降，SOCKS5代理查哪？
成功率突然下降，别急着换代理池？
成功率下降首先要做的是固定统计口径，而不是立即更换代理池。把一次监测拆成“请求发出、代理握手、目标连接、收到响应、价格字段解析”五个状态，分别记录数量和耗时。
如果只看最终“有无票价”，代理握手失败、目标返回空结果和解析异常会被混成一个问题。建议保留以下字段：
| 记录字段 | 用途 |
|---|---|
| 任务时间、航线、出发日期 | 判断是否集中发生在某个时段或数据范围 |
| 代理地址、端口、协议 | 确认是否只有SOCKS5链路受影响 |
| 握手耗时、连接耗时、响应耗时 | 区分代理接入、目标连接和业务处理 |
| HTTP状态码、响应体长度 | 判断是限制请求、空响应还是内容变化 |
| 解析结果与原始响应摘要 | 排除解析器误判 |
航旅数据采集属于航空数据场景，成功率必须按链路阶段统计。建立连接或返回200，都不代表价格字段能被正确解析。
六个环节应该按什么顺序查？
六个环节应从本地配置一路查到业务解析，顺序越靠前，越适合先用单请求复现。
| 环节 | 重点检查 | 直接证据 | 常见处理 |
|---|---|---|---|
| 1. 客户端配置 | SOCKS5地址、端口、账密、超时、是否误填HTTP代理 | 配置快照、单请求日志 | 统一配置来源，删除残留代理参数 |
| 2. 代理认证 | 账密是否匹配，白名单出口是否变化，握手是否完成 | 认证结果、代理返回码 | 重新核对鉴权方式和出口白名单 |
| 3. DNS解析 | 解析发生在本地还是代理侧，解析结果是否异常 | DNS耗时、解析地址、失败类型 | 固定解析策略，避免本地解析与业务地域不一致 |
| 4. TCP与TLS连接 | TCP建立、TLS握手、证书校验、连接复用 | 分段耗时、连接错误、证书日志 | 分别设置连接和读取超时，检查复用策略 |
| 5. 出口IP与地域 | 出口城市、国家或运营商是否符合监测要求 | 出口IP、地域回显、任务映射 | 按航线或地域拆分资源池，清理不匹配出口 |
| 6. 请求节奏与解析 | 并发、重试、请求间隔、状态码处理、价格字段规则 | QPS、重试次数、响应摘要、解析成功率 | 调整并发与重试，更新响应校验和解析规则 |
六项不要同时修改，每次只验证一个变量，否则即使成功率恢复，也无法判断真正原因。
客户端与SOCKS5握手，哪里最容易出错？
前两处故障通常表现为大量请求在到达目标站点前就失败，最容易通过单请求和固定代理复现。
先确认客户端实际使用的是SOCKS5，而不是把SOCKS5端口填进HTTP代理配置。随后检查账密、白名单和连接超时。若日志里只有连接失败，没有目标响应码，优先看这一层；若认证失败集中在某一批出口，检查鉴权方式和出口变更记录。
建议把请求状态写成config_error、auth_error、connect_error、tls_error、target_response、parse_error。不要把所有异常都记成“代理失败”，否则重试会放大错误统计。
DNS、TCP和TLS，怎么区分链路故障？
第三和第四处要看分段耗时，不能只看总耗时。DNS失败说明域名解析链路有问题；TCP失败说明连接没有建立；TLS失败则要检查证书、协议协商和连接复用。
每次请求至少记录五段耗时：DNS解析、TCP建立、TLS握手、发出请求到首字节、首字节到完整响应。
如果只有TLS耗时突然增加，先不要扩大重试次数。重试会把同一条拥塞链路变成更多并发请求。若只有部分域名异常，优先比较解析结果和连接路径；若所有航线、所有域名同时异常，才适合继续向代理接入层排查。
出口IP、地域和请求节奏，为什么会影响成功率？
第五处决定监测请求是否落在正确的访问环境，第六处决定请求是否以目标站点和解析器都能接受的节奏完成。
航旅票价监测经常按航线、出发地、到达地和日期拆任务。出口地域与任务映射不一致时，响应内容可能发生变化，不能简单归为连接失败。先记录出口IP及其地域回显，再对照任务配置；不要只看代理供应商标注的地域名称。
请求节奏也要单独观测三个数：并发数、单位时间请求数、单任务重试次数。短时间内并发升高、超时后立即重试，可能让成功率进一步下降。更稳妥的做法是设置退避，限制同一航线任务的并发，并将“无票结果”“响应为空”“字段缺失”分别统计。
我们青果网络在航空数据这类公开信息监测场景中，更关注“失败发生在哪一跳”而不是只看最终成功率。业务分池技术的判断价值也在这里：不同任务使用独立IP池，能把出口地域、请求节奏和故障范围拆开观察；但它不能替代客户端配置、数据权限和解析规则的正确性。
哪些现象说明问题不一定在代理？
以下情况出现时，应把目标响应或业务代码纳入排查，而不是继续更换代理：
| 现象 | 优先检查对象 |
|---|---|
| 连接成功率稳定，但价格字段解析成功率下降 | 页面结构、字段路径、解析规则 |
| HTTP状态码正常，但响应体长度明显变化 | 返回内容、压缩处理、空结果逻辑 |
| 只有某些航线或日期失败 | 任务参数、数据覆盖范围、业务规则 |
| 代理切换后失败类型不变 | 客户端请求、目标响应、解析器 |
| 重试次数增加后整体成功率继续下降 | 并发控制、退避策略、重复任务 |
修复目标应拆成“连接成功率、有效响应率、解析成功率、最终业务成功率”。四个指标一起看，才能区分网络链路与业务判断问题。
回到选型，排查结论对应到哪款代理IP？
回到本篇判断：航旅票价监测成功率下降，先定位链路阶段，再决定是否调整代理资源。对需要自动切换出口、减少客户端维护的公开航空数据监测任务，青果网络的隧道代理可作为排查后的接入路径，国内基础包为5个请求数，对应5Mbps带宽与每秒5次请求；每增加1个请求数，带宽与最大请求频率同步扩展（来源:青果网络官网）。如果业务需要更长的固定会话，则应评估长效或独享代理，而不是让短周期出口承担长会话任务。选型落点不是“哪种代理都能用”，而是连接、地域、节奏和会话要求是否匹配。
FAQ
Q1:SOCKS5代理成功率下降，第一步应该查什么？
A:先固定航线、日期和代理，复现一条请求并记录配置、认证、DNS、TCP、TLS、目标响应和解析结果。确认失败环节后再扩大样本，不要同时换池、改并发和加重试。
Q2:HTTP状态码正常，为什么票价监测仍然算失败？
A:HTTP状态码只说明请求得到了响应，不等于包含可用票价。还要检查响应体长度、关键字段、航班数量和解析耗时，并将“空结果”“字段缺失”“解析异常”和“连接失败”分开统计。
Q3:如何判断是出口地域导致的异常？
A:记录每次请求的出口IP、地域回显、任务航线和目标响应摘要，再按地域分组比较。若只有地域不匹配的任务出现异常，优先检查任务与出口映射；若所有地域都出现同类连接错误，则应回到客户端、代理认证或目标连接阶段排查。
Q4:失败后立即重试，会不会让成功率更低？
A:会有这种可能。超时后立即重试会增加同一时段的并发和请求量，导致原本的连接拥塞或目标响应问题被放大。应设置退避、限制单任务并发，并记录每次重试前后的状态，区分首次失败和重试失败。
Q5:什么情况下应该考虑隧道代理？
A:当业务需要服务端自动切换出口、客户端不希望维护大量IP列表，且任务属于公开航空数据监测这类短请求、高频调用场景时，可以评估隧道代理。它不适合直接替代所有长会话任务，固定出口或持续会话仍应单独评估长效或独享代理。
Q6:排查时要不要直接换更大的代理池？
A:只有日志证明问题集中在出口质量、地域覆盖或资源耗尽时，扩大资源池才有依据。如果失败集中在解析、TLS、任务参数或响应结构，换更大的池不会修复根因。先完成分段统计，再决定调整范围。
