代理连接失败或超时怎么排查

本文处理“代理根本没有回应”的情况：连接被拒绝，或者一直等到超时。只要代理回了任何东西，哪怕是错误码，您到代理这一跳的通路就是好的，问题在别处：407 是认证问题，见代理返回 407 怎么办；目标网站的 403 是对方拒绝，不是连接问题；代理到目标网站那一段是另一条路径，代理可达不等于它也能到达目标。一次代理 HTTPS 请求分四层建立：域名解析、TCP 连接、CONNECT 隧道、TLS 握手。从下往上测，最先出错的那一层就是答案。本文的每条命令都带 --connect-timeout 和 --max-time，不会一直挂着，退出码按阶段解读。

准备工作

  • 控制台“我的代理”页面上该产品的代理地址和端口，重新复制一份，不要用旧配置里的。
  • 有 curl 的命令行：Windows 的 PowerShell 里用 curl.exe，macOS 和 Linux 用 curl。
  • 一个备用网络用来对比，例如手机热点。很多“代理不通”其实是当前网络拦截了代理端口。

操作步骤

  1. 先跑一次带 -v 的请求，看停在哪一行

    把 USERNAME、PASSWORD、HOST、PORT 换成您的值：

    curl -v --connect-timeout 10 --max-time 30 -x http://USERNAME:PASSWORD@HOST:PORT https://api.ipify.org

    输出里最先出错的那一行对应一层：Could not resolve proxy（退出码 5）是域名解析失败（第 2 步）；Connection refused（退出码 7）是对方机器拒绝了连接，通常地址或端口不对（第 3 步）；还没打印 Established connection 或 Connected to 就以 Time-out 结束（退出码 28），是数据包发出去没有回来，常见于防火墙拦截（第 3 步和第 4 步）；发出 CONNECT 后收到错误，是代理可达但拒绝了隧道，或者中间有设备拦截（第 5 步）；打印 TLS handshake, Client hello 后再无输出直到超时，MTU 是需要排查的原因之一，丢包、拦截和目标网站自身的 TLS 问题也会这样（第 6 步）；打印 407，不是连接问题，见代理返回 407 怎么办。

  2. 第 1 层：域名要能解析

    这一层只涉及网关地址（gw-*.node4.io）。固定 IP 产品在控制台里直接列出 IP，没有域名可解析，直接看第 3 步。用本机的解析器查一次：

    nslookup gw-rotating_datacenter.node4.io

    解析失败的三个常见原因：公司网络的解析器只回答内部域名；容器里的 resolv.conf 为空或过期；hosts 文件里有一条旧记录覆盖了这个域名。用 --resolve 把 DNS 排除出去，证明只是解析问题：

    curl -v --connect-timeout 10 --max-time 30 --resolve HOST:PORT:IP_ADDRESS -x http://USERNAME:PASSWORD@HOST:PORT https://api.ipify.org

    这条能通、原命令不通，修解析器，不要改代理配置。旧配置里的 gw-rotating_shared.node4.io 是动态数据中心网关的旧名字，仍然可以解析和使用，新配置请用 gw-rotating_datacenter.node4.io。

  3. 第 2 层：端口要能接受连接

    不带 HTTP，只测 TCP 能不能连上：

    curl -v telnet://HOST:PORT --connect-timeout 5 --max-time 10

    这条命令连上之后什么都不发，代理也不会先开口，所以看 -v 的输出而不是只看退出码：打印了 Established connection to（旧版本写 Connected to）就说明端口接受了连接，之后等到 --max-time 到期以 Time-out 结束（退出码 28）是这条探测命令的正常结局，不是故障；没有 Established 行就超时，才是数据包没有到达（见下文）；Connection refused 是被拒绝（退出码 7）。--connect-timeout 只限制建立连接的阶段，连上以后的等待靠 --max-time 收尾，少了它命令会一直挂着。

    被拒绝（refused）：对照控制台逐字核对地址和端口。动态数据中心网关的 HTTP 端口是 8083，住宅网关是 8082，每个网关的 SOCKS5 端口又不同（动态 1083，住宅 1082）；从旧配置复制的地址最容易出这种问题。协议和端口不匹配的表现不一样，因为端口是能连上的：把 HTTP 请求发到 SOCKS5 端口会被立刻关闭（curl 显示空回复或连接重置，不是拒绝），把 SOCKS5 发到 HTTP 端口则会挂住。

    没有 Established 行就超时：换一个网络再跑同一条命令，最简单的是手机热点。热点能通、平时的网络不通，说明您的电脑、账号和代理都没问题，是当前网络在过滤。

  4. 公司网络和云平台的出站过滤

    代理端口不是网页端口，很多网络策略只放行出站 80 和 443。办公室、学校、酒店、公共 Wi-Fi、云平台默认的安全组都可能这样。特征很明确：正常上网没问题，连代理超时，热点测试通过。

    这种拦截在您控制不了的设备上，客户端没有绕过的办法。请网络管理员放行到该地址和端口的出站 TCP；云平台在实例的出站规则里添加目标；Kubernetes 检查命名空间上的出站 NetworkPolicy，它能让一个命名空间不通而宿主机正常。

  5. 第 3 层：CONNECT 隧道

    访问 HTTPS 目标时，客户端先向代理发 CONNECT example.com:443，代理回 HTTP/1.1 200 Connection established，然后才开始 TLS。-v 输出里应该能看到这两行。

    这一步出错，说明代理（或者冒充代理的东西）可达但拒绝了隧道。407 属于认证问题。看到一个 HTML 拦截页、一个颁发者（issuer）不认识的 TLS 签发方、或者一个跳转，通常是您网络里的设备截获了 CONNECT：企业的 TLS 检查设备会这样做，-v 打印的 TLS 信息里颁发者是公司安全厂商而不是公共 CA，就是被截获了。

  6. 第 4 层：TLS 握手卡住，先排查 MTU

    前面都成功，Client hello 发出后再无动静，直到超时，没有拒绝、没有重置、没有错误。这个现象本身不能确定原因，先缩小范围：换一个目标网站再跑一次（目标自身的 TLS 问题只影响这一个网站），换一个网络再跑一次（丢包和拦截通常跟着网络走）。CONNECT 成功而所有目标在当前网络都卡在这一步，MTU 是需要重点排查的原因：小包都能过（所以 DNS、TCP、CONNECT 都正常），TLS 握手交换的是满大小的包，路径上某一段（VPN、PPPoE 家庭宽带、容器 overlay 网络）的最大包长更小，而“需要分片”的信号又被拦掉了，这些包就无声无息地丢了。用不允许分片的 ping 收集线索：

    ping -M do -s 1472 HOST（Linux）或 ping -D -s 1472 HOST（macOS）

    1472 失败、1300 这样的小值成功，说明路径 MTU 偏小，和上面的现象对得上；但 ping 走的是 ICMP，有的网络单独限制 ICMP 大包，所以它是线索而不是定论。处理顺序：在 VPN 或路由器上开启 MSS clamping；只在当前机器上验证时，可以临时把该网卡的 MTU 降到 1400 看握手是否恢复，恢复了再决定是否长期保留。路径 MTU 正常而握手仍卡住，按丢包和拦截继续排查（traceroute HOST、换网络对比）。

决策树

1. 跑带 --connect-timeout 和 --max-time 的 curl -v，记下最先出错的那一行和退出码。 2. 域名解析不了：用 --resolve 测。能通就修 DNS（解析器配置、容器的 resolv.conf、hosts 文件旧记录）。 3. 被拒绝：对照控制台核对地址和端口。连上就断或挂住，确认没有把 HTTP 发到 SOCKS5 端口或反过来。 4. 没有连上就超时：热点测试。别的网络能通，是出站过滤，找网络管理员或改安全组；哪里都不通，提交工单，附 -v 输出和 traceroute HOST 的结果。 5. CONNECT 返回错误：407 走认证排查；不认识的 TLS 签发方或拦截页是本地截获。 6. TLS 卡住：先换目标网站和网络对比，再做不允许分片的 ping 测试；路径 MTU 偏小就修 VPN 或路由器的 MSS clamping，否则按丢包和拦截继续查。 7. curl 能通、程序不通：网络没问题，是程序传递代理设置的方式。见Python 设置代理和Node.js 设置代理。

出口地区不对，和连接问题怎么区分

检测工具显示的地区和预期不同，但请求是成功的，这不是连接问题。先分清三个地方：网关地址解析到 Node4 的美国节点，是您的程序连接的地方；出口 IP 是目标网站看到的地址，动态和住宅代理由用户名参数决定；您自己在哪里对出口没有影响。检测工具显示的是出口 IP。

出口国家和参数不符：用不带参数和带参数的用户名各查一次，确认参数生效（白名单方式连接没有用户名，也就没有参数）；确认程序没有从环境变量读到另一个代理。参数生效却仍显示错误国家，提交工单。城市显示在相邻的区或郊区，是各家归属地数据库之间的正常差异，不是故障。写法见住宅代理如何指定国家、城市和会话参数。

慢但能通，也不是连接问题。用 curl 的 -w 参数把一次请求拆成 DNS、TCP、TLS、首字节几个阶段计时，先直连跑几次取中位数作基线，再走代理跑几次，两者的差才是代理这一程的代价；目标网站本身慢，走不走代理都慢。单个请求不慢、整个任务慢，通常是程序串行发请求，解决办法是并发而不是换代理。

常见问题

从国内直接连接 Node4 的代理可以吗？

可以直接连接美国节点使用；国内到美国的线路延迟和稳定性受运营商和时段影响，Node4 没有国内节点，也不对国内线路的表现作承诺。建议先领取免费套餐，在您实际使用的网络和时段用本文的方法测一轮，记下延迟和失败率，再决定购买。

昨天还好，今天突然连不上，代码没改过？

按顺序看：当前网络是否变了（换了办公室、Wi-Fi、VPN）；白名单方式的话公网 IP 是否变了（这时表现是 407 而不是超时）；套餐是否到期或流量用完（也是 407）；状态页有没有异常。用热点跑一次 curl -v 能很快把“我的网络”和“代理”分开。

浏览器里连不上，curl 却能通？

网络和代理都没问题，是浏览器或程序没有把设置用对。指纹浏览器检查代理类型和端口是否对应（HTTP 端口选 HTTP，SOCKS5 端口选 SOCKS5），四个字段有没有多余空格。Python 和 Node.js 的常见问题是环境变量覆盖了代码里的代理，或者只给 https 设了代理没给 http 设，见对应的教程。

报 SSL 或 wrong version number 错误是代理坏了吗？

多半是把代理地址写成了 https:// 开头。Node4 的代理地址以 http:// 开头，访问 HTTPS 网站也一样，由代理建立 CONNECT 隧道，TLS 校验仍由您的程序对目标网站完成。写成 https:// 会让程序对一个明文端口做 TLS 握手，于是报错。不要用关闭 TLS 校验来绕过它，改回 http:// 即可。

容器里不通，宿主机能通？

先在容器里用 curlimages/curl 镜像跑同一条命令。常见差异：镜像里继承的 HTTP_PROXY 或 NO_PROXY 变量覆盖了配置；容器 DNS 指向了不可用的地址（用 --dns 1.1.1.1 测）；overlay 网络的 MTU 更小，TLS 卡住只在集群里重现时，先按第 6 步排查 MTU。

提交工单要带什么？

带 -v 的完整 curl 输出（删掉 Proxy-Authorization 一行，密码换回 PASSWORD）、您从哪些网络测过、连接的代理地址和端口、发生时间；超时的话再加一份 traceroute HOST 的结果。这几项通常一次就能定位，省去来回询问。