日志只写一行“timeout”，很难判断问题出在代理节点、目标网站还是应用本身。一次代理请求至少可能经历DNS解析、连接代理、代理认证、代理连接目标、TLS握手、发送请求、等待首字节和读取正文。每个阶段都能超时，处理方向完全不同。
常见超时阶段对照
| 阶段 | 超时含义 | 优先检查 |
|---|---|---|
| DNS超时 | 代理或目标域名没有及时解析 | DNS路径、DoH/远程DNS和内部域名 |
| 连接代理超时 | 客户端未与代理完成TCP连接 | 代理IP端口、路由、防火墙、节点状态 |
| 代理认证超时 | 连接建立但认证协商没有完成 | 认证方式、代理负载和客户端实现 |
| 代理连目标超时 | 代理无法及时连接目标服务器 | 代理出口路由、目标端口和目标状态 |
| TLS握手超时 | CONNECT后TLS未按时完成 | SNI、版本、丢包、证书链与检查设备 |
| 首字节超时 | 请求已发出，目标迟迟未开始响应 | 目标处理、回源、队列和应用负载 |
| 读取超时 | 响应开始后数据长时间没有继续 | 带宽、服务端流式输出、连接中断 |
| 总超时 | 整个请求超过预算 | 各阶段耗时累计，不等同某一层故障 |
连接超时和连接被拒绝不是一回事
连接超时通常表示SYN没有得到及时响应，可能被防火墙静默丢弃、路由不可达或节点离线；“connection refused”则常说明目标可达，但该端口没有监听或设备主动拒绝。两种错误应分别记录，不能都写成节点不通。
TLS超时也不等于证书错误
证书过期、域名不匹配通常会在握手中返回明确验证错误，而不是必然等待到超时。TLS超时可能来自：
- CONNECT并未真正成功，客户端错误地进入TLS阶段；
- 路径丢包或MTU问题导致握手报文无法完整到达；
- SNI对应服务没有响应；
- 代理HTTPS检查设备负载过高；
- 协议或加密套件协商异常；
- 目标服务器接受TCP后没有继续处理。
应记录CONNECT响应、TLS开始与结束时间、证书是否收到，而不是把“TLS阶段”直接写成“证书问题”。
读取超时为什么最容易误判
读取超时表示连接和部分业务可能已经成功，只是在规定时间内没有收到更多数据。长轮询、流式下载、AI生成、事件流和大文件本来就可能长时间保持连接，通用的短读取超时不适合所有业务。
反之，接口设计承诺2秒返回，却20秒没有首字节，更可能是目标应用、数据库、队列或CDN回源慢。需要服务器端请求ID和阶段日志配合。
超时参数应该怎样设计
| 参数 | 设计考虑 |
|---|---|
| DNS超时 | 解析服务正常响应范围和备用策略 |
| 连接超时 | 网络距离、失败快速切换与误杀风险 |
| TLS超时 | 握手、证书检查和移动网络质量 |
| 首字节超时 | 目标接口正常处理上限 |
| 读取空闲超时 | 流式业务允许多久没有新数据 |
| 总截止时间 | 用户请求或任务可接受的总体预算 |
不要单纯把所有超时调大。这样只会让故障更慢暴露并占用连接池。应按业务SLA和阶段预算设置，再对可重试错误使用有限、带抖动的指数退避。
重试为什么可能放大故障
连接超时后立即并发重试，可能让故障节点和目标服务负载更高。非幂等请求重试还可能造成重复订单、重复提交或状态不一致。客户端应：
- 仅对明确安全且可重试的错误执行有限重试；
- 使用指数退避和随机抖动；
- 为写操作使用幂等键或业务去重；
- 设置熔断、并发上限和整体截止时间；
- 记录每次尝试，而不是只记录最终失败。
直连与代理如何做公平对照
- 使用同一目标域名、请求方法、请求体和相近时间；
- 记录本地DNS与代理远程DNS得到的地址；
- 分别测直连和单一代理，不叠加PAC、多跳和扩展；
- 记录每个阶段耗时、状态码、出口与目标请求ID；
- 从另一条合法网络做对照，判断是否为本地运营商路径；
- 查看目标服务是否在相同时间出现全局延迟。
如果直连与多个代理都在等待首字节，目标服务问题概率更高；只有一个节点连接代理阶段超时，则优先查该节点或到它的路径。
日志至少要记录哪些字段
建议记录时间、请求ID、客户端版本、代理节点标识、目标主机的脱敏标识、DNS耗时、连接代理耗时、CONNECT或SOCKS阶段、TLS耗时、首字节、总耗时、错误类型和重试次数。
不要记录代理密码、Authorization、Cookie、完整查询参数和业务正文。日志访问、留存和删除应按用途控制。
一份可执行的结论
“请求超时”应改写成类似：“客户端在3秒内无法连接节点A，DNS耗时20毫秒，TCP未建立；直连和节点B正常。”这条结论能直接指向节点或路径，而不是让所有团队同时排查。
需要连通、路由和基础测速工具时，可以从极跃圈网址导航选择。最终以分阶段日志和可复现请求为准，单次ping或总耗时无法代替。
