network Troubleshooting
curl 使用代理连接超时排查
curl -x 通过 HTTP/SOCKS5 代理访问超时或 Failed to connect to proxy 时，用 curl -v 定位卡在代理还是目标站，区分 http 与 socks5/socks5h 协议、代理端 DNS 解析和 NO_PROXY 环境变量是否排除了目标域名。
先用 curl -v 看连接卡在代理还是目标站点。SOCKS5 代理建议用 socks5h，让 DNS 在代理端解析。
Scenario
这篇文章解决什么问题
适用于 curl 加代理后连接超时、浏览器可用但命令行不可用、同一个代理在不同协议写法下表现不同的场景。重点是确认 curl 连接的是代理失败，还是代理连接目标站点失败。
Symptoms
典型现象
- curl -x 后长时间卡在 Trying、CONNECT 或 TLS handshake。
- HTTP 代理端口被写成 socks5，或 socks5 代理没有使用 socks5h 导致 DNS 在本地解析失败。
- 设置了 HTTP_PROXY/HTTPS_PROXY 后部分内网地址也被错误代理。
- 同一 URL 在浏览器中成功，但命令行使用的是另一套代理或 DNS 策略。
Before Debugging
排查前先确认
- 先判断失败发生在 DNS、TCP、TLS、HTTP、代理还是应用层。
- 从客户端、服务端和中间代理所在机器分别测试，避免只验证了其中一段。
- 记录域名、解析结果、目标 IP、端口、协议和代理配置。
Root Causes
常见根因分层
解析路径不一致
系统 DNS、浏览器 DoH、容器 DNS、代理端解析可能得到不同结果。NXDOMAIN、SERVFAIL 和 timeout 对应不同方向。
- dig 本机和公共 DNS 对比
- 必要时 dig +trace
- 检查 hosts 和容器 DNS
代理协议或解析位置错误
HTTP 代理和 SOCKS5 代理不能混用；socks5 与 socks5h 的 DNS 解析位置不同。
- curl -v 看连接阶段
- 确认代理端口本机监听
- 检查 NO_PROXY
TLS/HTTP 层误判为网络问题
证书、SNI、重定向、HSTS、HTTP/2 和网关错误可能被笼统描述为“连不上”。
- curl -vI 看 TLS 和状态码
- openssl 带 servername
- 记录响应头判断来源
Diagnosis Path
分步诊断流程
1. 固定现场，避免追着变化状态跑
先记录故障时间、影响入口、完整错误和最近一次变更。curl 使用代理连接超时排查 这类问题经常在重启、重试或缓存刷新后短暂消失，没有现场信息会很难复盘。
- 截图或保存完整错误文本
- 记录请求域名/IP/端口/namespace/服务名
- 标出最近发布、配置、证书、镜像或依赖变更
curl -v -x http://127.0.0.1:7890 https://example.com
curl -v -x socks5h://127.0.0.1:7890 https://example.com2. 在故障发生的同一位置复现
很多误判来自测试位置不同：本机通不代表服务器通，容器内通不代表宿主机通，集群外通也不代表 Pod 内通。复现命令要尽量贴近真实流量路径。
- 从报错服务所在机器执行测试
- 必要时加 Host、SNI、namespace 或代理参数
- 把成功路径和失败路径的输出并排比较
curl -v -x socks5h://127.0.0.1:7890 https://example.com
ss -lntp | grep 78903. 读取服务端证据，而不是只看客户端提示
客户端报错通常是结果摘要。真正能区分根因的是服务端日志、内核日志、事件、进程状态或数据库状态。
- 确认代理端口本机可连接。
- 区分 http 代理和 socks5 代理协议。
- 使用 -v 查看卡点。
ss -lntp | grep 78904. 做最小修复并立即回归验证
每次只改一个变量，修复后用同一条复现命令回测，并观察日志是否停止增长。这样可以避免多个临时改动互相掩盖。
- 使用 -v 查看卡点。
- 需要代理端 DNS 时使用 socks5h。
- 检查 NO_PROXY 是否排除了目标域名。
curl -v -x socks5h://127.0.0.1:7890 https://example.com
ss -lntp | grep 7890Commands
排查命令与使用意图
命令 1
用于从指定位置模拟真实请求。加 -v 可以看到 DNS、TCP、TLS、HTTP 头和代理连接过程，是定位链路阶段的关键证据。
curl -v -x http://127.0.0.1:7890 https://example.com命令 2
用于从指定位置模拟真实请求。加 -v 可以看到 DNS、TCP、TLS、HTTP 头和代理连接过程，是定位链路阶段的关键证据。
curl -v -x socks5h://127.0.0.1:7890 https://example.com命令 3
用于确认端口监听状态和连接关系。重点看 LISTEN 行的地址是 127.0.0.1 还是 0.0.0.0，以及 ESTAB 连接数。
ss -lntp | grep 7890Risk Notes
容易踩坑的地方
- 不要把代理变量长期写入全局 shell 配置而不维护 NO_PROXY，否则内网、Docker Registry 或 Git 都可能被误代理。
- 不要只看 curl 最后一行 timeout，要用 -v 判断卡在代理连接、DNS、TLS 还是目标 HTTP 响应。
- 不要混用 http://、socks5://、socks5h://，协议写错时表现常常只是超时。
Verification
修复后怎么确认
- 原始故障现象已经消失，且使用同一入口重新测试 curl 使用代理连接超时 能稳定成功。
- 服务端日志不再出现同类错误，监控中的错误率、重启次数、连接数或延迟回到正常区间。
- 如果做过临时绕过，已经记录恢复计划，例如还原宽松策略、补监控、补限制或提交正式配置。
Prevention
后续预防
- 把常用代理地址、协议和 NO_PROXY 列表写成可审计脚本，不在多个终端手工复制。
- 对内网域名、localhost、容器网段和 Kubernetes 网段显式加入 NO_PROXY。
- 排障文档中保留一组最小 curl -v 命令，分别测试直连、HTTP 代理、SOCKS5 代理和代理端 DNS。
常见问题
socks5 和 socks5h 区别是什么？
socks5 默认可能本地解析 DNS；socks5h 会把域名交给代理端解析。
Long-tail SEO
你可能正在搜索这些报错
下面这些错误原文、场景词和中英文搜索词，都是排查同类问题时常见的入口。
- curl proxy connect timeout
- curl -x 代理超时
- curl socks5 socks5h 区别
- curl 代理 DNS 解析失败
- curl Failed to connect to proxy
- curl proxy tunnel failed
- curl 走代理访问不了 https
- NO_PROXY curl 代理不生效
Need More Help
这个问题还没完全解决？
把你的报错、环境和已经尝试过的步骤发给我，后续会优先补充到排障手册。