HTTP代理测试失败，首先应该检查什么？
先保留一次完整失败记录，再修改配置。没有原始条件，换地址、调超时与改鉴权后就难以解释结果为什么变化。
以招投标公开公告查询为例，至少保留目标列表页或详情页的地址类别、发生时间、请求方法、状态码和错误阶段。页面中的凭据、Cookie及敏感参数应在共享前删除。
| 必要记录 | 具体内容 | 用于判断什么？ |
|---|---|---|
| 代理参数 | 协议、入口、端口、内部编号 | 是否连对服务？ |
| 鉴权方式 | 账号鉴权或出口白名单 | 凭据是否用于正确环节？ |
| 目标条件 | 协议、主机、端口、方法 | 是否只有特定目标失败？ |
| 客户端条件 | 工具版本、网络出口、超时 | 是否存在环境差异？ |
| 原始结果 | 异常类、响应头、脱敏正文 | 失败发生在哪一段？ |
排查期间一次只改变一个主要条件。先确认地址格式和鉴权，再比较目标或网络，最后调整负载；同时改动多个条件容易让问题暂时消失，却无法确认原因。
没有收到HTTP响应时，应该查哪一段？
先检查客户端到代理入口的连接，再分析转发阶段。没有状态码不代表所有错误都发生在入口，客户端可能把后续错误包装为连接异常。
| 表现 | 优先检查 | 不能直接认定的结论 |
|---|---|---|
| 代理主机解析失败 | 入口拼写、客户端DNS、网络配置 | 目标站点不可用 |
| 连接被拒绝 | 地址与端口、服务监听、网络策略 | 凭据一定错误 |
| 连接超时 | 入口可达性、网络路径、等待设置 | 延长超时必然有效 |
| 读取超时 | 目标响应、代理转发、读取等待 | 代理入口无法连接 |
| ProxyError | 脱敏异常链、CONNECT响应、鉴权 | 一定是同一个底层原因 |
Requests遇到网络问题可抛出ConnectionError，超时可表现为Timeout相关异常。[1]具体分类还受请求阶段和底层包装影响，异常名称只能作为排查入口。
建议执行三个动作：
- 核对客户端实际使用的代理参数，排除环境变量与显式配置不一致。
- 使用相同入口访问自有小页面，减少响应体与业务逻辑影响。
- 对照失败时间的客户端、代理或自有目标日志，确认最后成功的阶段。
只做端口连接检测，仍然无法验证目标转发与正文读取。端口可达后，应继续执行真实请求。
返回407时，为什么要先查代理鉴权？
407表示缺少有效的代理鉴权凭据。响应通常通过Proxy-Authenticate说明所需鉴权方式，客户端应据此修正代理凭据。[2]
| 检查项 | 建议动作 |
|---|---|
| 用户名与密码 | 检查是否过期、复制了多余空格或使用了错误账号 |
| 凭据放置位置 | 确认用于代理鉴权，而非目标网站登录 |
| URL中的特殊字符 | 按URL规则编码用户名与密码 |
| 白名单模式 | 确认当前程序运行机器的公网出口被允许 |
| 接入方式 | 对照服务要求确认账号与白名单的使用条件 |
代理鉴权与目标站点鉴权是两件事。即使代理允许转发，目标页面仍可能要求合法登录；修改代理密码不能解决目标账号权限不足。
HTTPS请求的代理鉴权失败还可能出现在CONNECT阶段，并被客户端包装成代理异常。此时不能仅因结果表没有407，就排除鉴权问题；应检查脱敏后的隧道错误信息。
HTTP成功而HTTPS失败，应该如何定位？
先区分隧道建立失败与TLS验证失败。通过HTTP代理访问HTTPS目标时，curl通常先使用CONNECT建立隧道，然后进行加密通信。[3]
| 阶段 | 可观察线索 | 下一步 |
|---|---|---|
| 连接代理 | 是否连到指定入口 | 核对协议与端口 |
| 建立隧道 | CONNECT是否被接受 | 检查鉴权与目标端口许可 |
| TLS握手 | 证书或握手异常 | 核对目标主机名、时间与信任链 |
| 目标响应 | 已有目标HTTP状态 | 转入目标与内容排查 |
可使用以下诊断命令，域名需替换成实际地址：
curl --proxy "http://proxy.example:8080" \
--noproxy "" --connect-timeout 5 --max-time 15 \
--verbose --dump-header headers.txt \
--output body.txt "https://probe.example/health"5秒与15秒是演示设置。调试输出应先脱敏再共享，不把完整凭据写进工单。
若出现证书验证错误，应检查证书是否过期、主机名是否匹配，以及客户端是否信任正确的证书链。Requests默认启用证书验证，验证失败会抛出SSLError。[4]需要内部CA时应配置经过确认的证书文件，不能将关闭验证后的请求作为正式验收结果。
返回错误状态码或错误内容时，怎么继续查？
先确认响应来自哪一层，再解释状态与正文。代理、目标服务及中间网关都可能产生响应，仅凭一个状态码不一定能确定责任方。
| 结果 | 排查动作 |
|---|---|
| 403 | 核对访问权限、请求方法与响应阶段，必要时联系服务管理方 |
| 429 | 检查限流提示，降低发送速率并按要求等待 |
| 5xx | 结合响应头、请求标识与日志定位产生响应的节点 |
| 3xx | 检查跳转目的地，确认是否为登录或地址迁移 |
| 200但内容不符 | 校验内容类型、字段与目标页面标识 |
| 内容被截断 | 检查读取异常、响应长度与传输记录 |
429表示一定时间内发送请求过多，响应可能包含Retry-After，说明再次请求前应等待多久。[5]收到此类响应后，应先控制请求频率；继续密集重试会让测试条件更加混乱。
公告列表页正常、详情页失败时，应对照详情请求的权限、参数和内容规则。若所有页面同时失败，再优先检查共同依赖的入口、网络与鉴权条件。
如何用对照测试缩小故障范围？
固定其余条件，只替换一个变量。每次对照都保留时间与请求标识，并尽量让样本发生在相近时段。
| 对照方式 | 有助于判断的范围 | 注意事项 |
|---|---|---|
| 同一目标，直连与代理分别测试 | 是否与代理路径有关 | 直连成功也不能单独证明代理故障 |
| 同一代理，自有页面与业务页面分别测试 | 是否与特定目标有关 | 两种页面的权限与内容不同 |
| 同一配置，不同运行环境测试 | 是否与本机或出口有关 | 先确认新出口的鉴权条件 |
| 同一条件，低负载与业务负载比较 | 是否随负载增加而退化 | 同时观察客户端与目标容量 |
问题修正后，先复现原失败请求，再补测同类业务样本。只测新的简单页面，无法证明原问题已解决。原始失败与修正后结果应同时保留，形成明确的处理记录。
FAQ
Q：连接超时后是否只需增大超时值？
不一定。地址错误、入口不可达或网络策略限制都可能导致等待失败。先确认请求停在哪个阶段，再按业务允许时间调整。更长等待只能改变容忍范围，不能自动修正连接条件。
Q：407和目标网站登录失败是一回事吗？
不是。407指向代理鉴权，目标网站登录属于另一段权限检查。排查时应分别记录代理凭据与目标会话是否生效，避免把目标账号放进代理参数，或用修改代理密码解决站点权限问题。
Q：直连成功、代理失败能证明代理损坏吗？
只能说明两条路径的结果不同，还需检查代理鉴权、目标端口限制、出口差异和目标服务策略。应结合自有页面测试与连接日志定位，不能仅凭一次对照确定故障责任。
Q：为什么同一个错误在脚本里显示不同异常？
客户端库、协议路径和失败阶段会影响异常包装。尤其是HTTPS隧道建立期间的错误，可能显示为代理异常。保留异常类别和脱敏后的原因链，通常比仅保存“请求失败”更有排查价值。
Q：修正后成功一次，可以结束排查吗？
一次成功可以确认该次请求已恢复，但持续性问题还需按原负载与业务流程复测。应覆盖原先失败的页面和条件，观察错误是否再次出现，再给出与测试范围一致的恢复结论。
总结：HTTP代理测试失败应按入口、鉴权、隧道、TLS、目标响应与内容校验逐层定位。保留原始证据，用单变量对照验证修正，才能得到可复现的排查结论。
