Requests 的 Tunnel 400：请求还没到接口，改 JSON 为什么没用？

遇到 requests代理Tunnel connection failed 400错误，先看 400 出现在哪里。如果它位于 ProxyError 异常链里的 Tunnel connection failed: 400 Bad Request，失败的是建立代理隧道的步骤；它不等同于拿到 Response 后发现 response.status_code == 400。前一种情况下，修改接口的 JSON 字段通常不会改变这次隧道拒绝。

两个 400，发生在不同的请求上

访问 HTTPS 接口时，常见的 HTTP 代理链路是：客户端连接代理，向代理发出 CONNECT，请求为目标主机及端口建立隧道；隧道成功后，客户端才与目标进行 TLS 握手并发送业务请求。urllib3 官方说明区分了 HTTP 代理与 HTTPS 代理：后者还会先与代理建立一层 TLS。

因此，异常里的 Tunnel 400 说明隧道建立收到非成功响应，但单凭这几个字不能断定是密码错误、目标封禁或某家产品的固定策略。也不能仅凭它认定响应一定来自最终目标，代理链或中间网关都需要结合日志确认。

相反，如果 Requests 已返回 Response，HTTP 400 应结合响应来源和接口文档分析：参数格式、必填字段或网关校验才进入排查范围。不要把两种错误共用一套“改请求体、加重试”的处理。

https 字典键不是要求使用 HTTPS 代理

下面是演示配置，不是可直接连接的真实入口：

proxies = {
    "https": "http://proxy.example.com:8080",
}

键 https 对应目标 URL 的协议；值里的 http:// 描述如何连接代理入口。目标接口为 HTTPS，并不要求把代理值也改成 https://。只有交付的入口确实支持 TLS 代理时才使用后者。Requests 要求代理 URL 带协议前缀，见其代理配置说明。

还应确认填写的是代理接入地址，而非提取 IP 的 API 地址或后台管理网址。端口能返回 HTTP 页面，不代表它能处理 CONNECT。协议与证书两层的详细区别可参考curl 代理 HTTPS 访问；其中链路原理可用于理解这里的异常，命令行参数则不能直接照搬到 Requests。

把“异常”与“响应状态”分别输出

以下示例只向你有权访问的健康检查地址发起一次 GET，不打印原始异常串、代理 URL 或响应体。将占位地址替换成授权目标，并通过受控配置预先提供 PROXY_URL。环境变量不是秘密保险箱，仍须限制进程与日志访问权限。

import os
import requests

proxy = os.environ["PROXY_URL"]
try:
    with requests.get(
        "https://service.example.com/health",
        proxies={"https": proxy},
        timeout=(5, 15),
        allow_redirects=False,
        stream=True,
    ) as response:
        print("response_status", response.status_code)
except requests.exceptions.ProxyError:
    print("proxy_error: 在受限环境核对脱敏后的异常链")
except requests.exceptions.SSLError:
    print("tls_error: 核对证书与发生层次")
except requests.exceptions.RequestException:
    print("transport_error: 需要进一步分类")

这里没有调用 raise_for_status()，所以返回的 HTTP 400 会进入 response_status 分支，不会被混进传输异常。ProxyError 并不专指 Tunnel 400，仍需在受限环境确认完整异常链后再分类。超时元组分别控制连接和读取等待，不是整次操作的绝对总时限；stream=True 则让这次检查不主动下载完整响应体。

仍然是 Tunnel 400 时，下一条证据是什么？

如果入口协议和接入地址已核实，保留失败时间、Requests/urllib3 版本、目标主机与端口的受控记录，请代理管理员对照 CONNECT 日志判断请求格式或策略拒绝原因。不要提交含账号密码的完整代理字符串，也不要把接口 Token 填成代理密码。

可以使用同一入口访问另一个已获授权、已知可用的 HTTPS 健康页做一次对照：两者都失败，更值得核查入口配置；只有特定目标失败，则核对该目标及端口是否在允许范围。这只能缩小范围，不能替代服务端证据。

不要用 verify=False 修复 Tunnel 400：跳过证书验证不能让代理接受已被拒绝的 CONNECT。也不要因报错就无限换 IP 或重放写入请求。先让隧道问题与业务响应分开，才知道下一步该查代理入口，还是查接口参数。