用 HTTP 代理访问 HTTPS 网站时，不少同学遇到过这个报错：
curl: (56) CONNECT tunnel failed, response 6xx
先说结论：这个报错说明请求在 CONNECT 阶段就被代理网关拒绝了，请求根本没到目标网站。问题几乎都出在代理侧，不是你的代码写错了。
一、先读懂这个报错
curl 通过 HTTP 代理访问 HTTPS 时，会先向代理发一条 CONNECT 请求建立隧道，代理确认后才在隧道里跑 TLS。如果代理在这一步返回失败，curl 就报 "CONNECT tunnel failed"。
注意 response 后面的 6xx：这不是 HTTP 标准状态码（标准码只有 1xx~5xx），是代理平台自定义的业务返回码。所以看到 6xx，基本可以断定：请求已到达代理网关、由代理侧返回，优先排查代理侧。
二、四大常见根因（按概率排序）
-
鉴权失败（最高频）：白名单 IP 变动失效（家宽/办公网出口 IP 一变就挂）、账号密码或 token 错/过期、未实名或认证未生效。
-
目标域名被平台风控限制：该域名不在合规采集范围或触发平台风控。
-
出口节点不可用：你选的城市/线路刚好故障或维护中。
-
并发超购：并发超过套餐上限，超出的请求被网关直接拒绝。
三、逐项排查步骤
- 加 -v 看握手细节：curl -v -x http://账密@入口:端口 https://目标站
重点看 CONNECT 的返回体和失败阶段，把完整输出截图。
-
换目标站对照测试：同一个代理、换一个正常大站（如 baidu.com）。如果换站就通，问题在目标域名；换站也报同样的 6xx，问题在代理侧（白名单/认证/出口/并发）。
-
降并发测试：把并发降到 1 再跑一次。通 → 并发超购；仍报 → 查白名单和认证。
-
核对账号状态：套餐是否到期、余额是否不足、实名是否生效。
四、一个容易被忽略的坑
客户口里说的错误码，和堆栈里实际的码可能不一致（比如口头说 631、实际 643）。排查一律以堆栈/响应里的实际数字为准，不要凭口头描述猜。
五、给客服报问题的正确姿势
一次说清这三样，客服秒懂：
-
平台 + 错误码（以实际输出为准）
-
完整返回 body / curl -v 输出
-
复现命令（含代理地址与目标站）
最后提醒：报错先别慌，按"白名单/认证 → 目标站限制 → 出口/并发"的顺序查，80% 的 6xx 都在前两步能定位。搞不定的，把完整报错发我，我帮你看是哪一类。