如何用 curl 测试代理连接？拆分 DNS、连接、TLS 与首字节耗时

浏览器打不开网页，节点延迟却很低；测速能跑起来，某个网站仍然转圈。与其只看客户端的延迟数字，不如让 curl 发出一次可控的 HTTPS 请求，记录它在哪个阶段等得最久。本文从本地代理端口出发，提供 Windows、macOS 与 Linux 可复用的测试方法。

阅读导航：准备测试 · 可复制命令 · 计时含义 · 差值示例 · DNS 对照 · 失败排查 · 节点对比

一、先确认 curl 连的是哪个代理端口

本地代理软件通常会提供 HTTP、SOCKS 或混合端口。本文以 127.0.0.1:7890 举例，它不是所有客户端的默认配置。先在客户端设置中确认实际监听端口及支持的协议，再替换示例。订阅链接、节点服务器端口与本地代理端口不是同一个东西。

curl.exe --version

Windows PowerShell 使用 curl.exe，避免某些版本中 curl 被解释成其他命令的别名；macOS / Linux 使用 curl --version。下文把选项放进配置文件，可以减少不同终端对引号、百分号和空参数的处理差异。

固定一个你确实要访问的 HTTPS 地址，最好是响应体较小、无需登录、没有跳转的页面。示例用 https://example.com/ 演示命令，请根据实际问题替换。一次请求只对应一个目标，不能代表全部网站。

二、直接复制：输出状态码、连接信息和阶段计时

新建纯文本文件 curl-test.conf，复制以下内容。建议保存为 UTF-8 无 BOM，避免记事本把扩展名变成 .conf.txt。

url = "https://example.com/"
proxy = "http://127.0.0.1:7890"
noproxy = ""
http1.1
connect-timeout = 10
max-time = 30
silent
show-error
output = "curl-body.tmp"
write-out = "@curl-format.txt"

同一目录再新建 curl-format.txt，复制下面的输出模板。

http=%{http_code}
connect_http=%{http_connect}
peer=%{remote_ip}:%{remote_port}
dns=%{time_namelookup}
connect=%{time_connect}
appconnect=%{time_appconnect}
pretransfer=%{time_pretransfer}
starttransfer=%{time_starttransfer}
total=%{time_total}
bytes=%{size_download}
speed_Bps=%{speed_download}
redirects=%{num_redirects}

Windows PowerShell：切换到这两个文件所在的目录，再执行。

curl.exe -q --config .\curl-test.conf
$LASTEXITCODE

macOS / Linux：同样在文件目录内执行。

curl -q --config ./curl-test.conf
echo $?

-q 放在第一个选项，避免默认 curl 配置文件混入额外设置；noproxy = "" 清空代理绕过名单。测试固定 HTTP/1.1，不自动跟随跳转、不自动重试，便于比较一次请求。响应体保存在当前目录的 curl-body.tmp，每次会覆盖，排查 403 或错误页时可以打开确认。

连接阶段最多等待 10 秒，整个请求最多 30 秒。连接超时范围不只是 TCP，也涉及 DNS 与建立连接所需的握手。这个超时是为了避免排查一直挂着，不是合格线路的速度标准。选项用法参见 curl 官方命令手册。

成功要看两个层面：终端退出码反映传输是否完成，http 反映服务器给了什么响应。本文没有启用 --fail，因此 HTTP 403、404、500 仍可能伴随退出码 0；不能把“curl 执行完了”当成“业务访问正常”。

connect_http 是 HTTP 代理 CONNECT 请求的响应码，HTTPS 目标经 HTTP 代理建立隧道时通常期待 200；它不是目标网站状态码。直连或 SOCKS 测试时显示 000 可以是正常的。

三、这些时间是“到哪一步”，不是“每一步花多久”

下表按本文的单次 HTTPS 请求解释，单位均为秒。先看累计时间点，再算差值。变量输出方式可查 curl 的 write-out 说明。

最重要的是 time_connect 的对象。curl 官方定义明确包含“远端主机或代理”。如果 peer=127.0.0.1:7890，curl 看到的连接对端就是本地代理；它不会因此获得海外入口、出口和目标网站每一跳的独立计时。参见 连接时间定义。

因此，remote_ip 也不能直接当作机场出口 IP。要知道网站看到的来源地址，应通过同一代理请求返回客户端 IP 的服务，并确认分流规则没有改变路径。入口、出口与数据库地区的区别可以结合本站的 入口 IP 与出口 IP 判断指南 理解。

四、用一组数字拆分耗时，但不要拆出不存在的精度

下面是演示数据，不是任何节点或品牌的实测。假设请求通过本地 HTTP 代理访问 HTTPS 页面，成功返回 200，没有重定向。

dns=0.000040
connect=0.000800
appconnect=0.420000
pretransfer=0.420200
starttransfer=0.680000
total=0.700000

在直接连接 HTTPS、单次新建连接的简单场景，appconnect − connect 可以近似帮助观察 TLS 建立耗时。经 HTTP 代理时，它还可能包含 CONNECT 隧道准备；经 SOCKS 时也可能包含代理协商及代理侧连接过程，不能统一命名为“纯 TLS 耗时”。HTTPS 代理自身还有一层 TLS，更不能按单层握手解释。参见 握手完成时间定义。

starttransfer − pretransfer 也不是服务器纯计算耗时。请求发送、网络往返、代理转发、服务端排队与处理，都可能影响这一段；没有服务端日志或配合测量，客户端不能把它们逐项扣出来。首字节时间定义 包含传输前准备及服务器产生响应所需的时间。

上述差值只适合请求成功且阶段确实发生的情况。握手失败、连接复用、多次跳转或其他协议会改变含义；字段为 0 不一定代表“这一段极快”，也可能是该阶段未发生或未完成。

五、SOCKS5 与 socks5h：究竟由谁解析目标域名

保持其他配置不变，只修改 proxy 一行。端口仍需替换成客户端实际支持 SOCKS 的端口。

proxy = "socks5://127.0.0.1:7890"

socks5:// 让 curl 在本地解析目标域名，再把目标地址交给 SOCKS 代理。

proxy = "socks5h://127.0.0.1:7890"

socks5h:// 把目标域名交给 SOCKS 代理解析。这里的 h 指代理处理主机名，不表示开启了某种加密 DNS。如果 SOCKS 端点是本机代理软件，最终使用本机、远端还是 Fake-IP 机制，仍取决于客户端配置。参见 curl 的 SOCKS 代理说明。

两种方式表现不同，说明名称解析路径或由此选择的目标地址值得检查；还不能直接证明“本地 DNS 被污染”。不同解析器可能选到不同 CDN 地址，也可能走不同地址族。对照时结合客户端连接日志与 DNS 日志，确认实际目的地址。

使用 socks5h 时，即使 time_namelookup 很小，也不能据此说目标域名解析很快：curl 不会把代理内部 DNS 查询单独回传成这个字段。HTTP 代理访问 HTTPS 域名时，同样要注意隧道建立阶段可能包含代理侧的解析与连接。

六、直连对照怎么做，哪些错误先排查

测试应用层直连时，把配置中的代理行改为下面这样；其他条件保持一致，重新运行同一条命令。

proxy = ""

这会禁用 curl 显式使用的代理，包括环境变量给出的代理；它不会绕过系统 TUN、VPN、路由器透明代理或其他网络层接管。所以“curl 没指定代理”和“完全走运营商原始路径”不能直接画等号。

如果请求失败，先在原命令末尾加 --verbose，查看它停在连接代理、CONNECT 响应、TLS 握手还是 HTTP 响应。详细日志可能包含地址、请求头和认证信息，分享前先脱敏。

curl.exe -q --config .\curl-test.conf --verbose

如果确实要观察带跳转的完整过程，可以另做一轮 --location 测试，但不要与本文单请求结果混算。curl 跟随跳转后，相关计时会累计多个请求；应先明确自己比较的是首个响应还是整条跳转链。

七、怎样把结果用于节点对比，而不是只挑最好的一次

固定目标 URL、代理协议、客户端规则与测试网络。每个节点分别运行 5～10 次独立 curl 进程，间隔几秒，交替测试 A、B 两个节点。记录失败次数、TTFB 与总耗时的中位数，再看较慢的几次是否频繁出现。这个次数适合初步排查，不足以代表全天稳定性。

每次重新启动 curl，可以避免同一 curl 进程复用目标连接，但操作系统 DNS 缓存、代理软件连接池与上游隧道仍可能复用。因此这里比较的是日常环境下独立请求的表现，不是严格清空所有缓存后的冷启动实验。

小页面适合观察建立连接和首字节，不适合测线路最大吞吐。输出中的 speed_Bps 是这次传输的平均下载速度，单位为字节/秒；小响应受连接准备影响很大。要看持续下载，应另用大小固定、允许测试的文件，并记录体积、状态码和是否完整下载，避免把错误页当成测速文件。

curl 也不会像浏览器一样加载页面里的 CSS、脚本、图片并执行渲染。即使首页请求很快，页面引用的另一个域名仍可能卡住。关于延迟、吞吐和单连接表现之间的区别，可继续阅读 节点延迟低为什么还是慢？

常见问题

curl 连通了，就能证明节点是 IEPL 或 IPLC 吗？
不能。curl 看到的是应用请求及部分连接阶段，无法证明服务商内部链路的交付类型。线路结构可以参考 专线、IEPL、IPLC 与中转的区别，购买判断仍要结合可验证的服务表现。

为什么 connect 很小，网页却等了一秒？
你可能只是在极短时间内连上了本地代理，实际出站连接、隧道、TLS 与目标响应发生在后面。先看 appconnect、starttransfer 与日志，不要只截取 connect。

测到 DNS 为 0，需要换 DNS 吗？
先确认解析发生在哪里，以及是否命中缓存、使用 IP 地址或由代理解析。字段为 0 本身不是调整 DNS 的理由。

能直接拿这个结果给机场排名吗？
单个网站、单个时段只能说明这组条件下的体验。若多个目标都在相似阶段变慢，再结合高峰期重复测试和失败率，才更有依据讨论线路表现。