代理速度慢怎么排查是节点还是 DNS 问题？
简答：先固定同一设备、同一目标网站和同一时间，分别做直连、当前节点、其他节点三组测试；再用 nslookup 或 dig 看解析耗时，用 curl 的分段计时区分 DNS、TCP、TLS、首字节和下载阶段。只有更换 DNS 后解析阶段明显改善，才更像 DNS 问题；如果 DNS 很快但换节点后连接、首包或下载明显改善，优先排查节点、出口线路或拥堵。
定义：这里的“代理速度慢”不是单一指标，而是要拆成 DNS 解析、TCP 连接、TLS 握手、首字节响应、完整下载和丢包抖动等阶段分别判断。
先试这一步：用三组对照判断问题范围
不要一开始同时更换节点、DNS、客户端模式和浏览器，否则无法知道是哪一项产生了变化。先记录同一设备、同一网络、同一目标地址和同一时间段的结果，再只改变一个变量。
| 测试组 | 保持不变 | 只改变的变量 | 重点观察 | 初步判断 |
|---|---|---|---|---|
| 直连基线 | 设备、网络、目标地址、时间 | 关闭代理 | 解析、连接、首包、总耗时 | 确认本地网络和目标站的基础表现 |
| 当前节点 | 其他条件不变 | 开启当前节点 | 连接、首包、下载、丢包 | 判断代理链路是否增加主要耗时 |
| 其他节点 | 设备、网络、目标地址、时间 | 只更换节点 | 同一命令重复测试 | 若差异明显，优先排查单节点或出口线路 |
| 其他 DNS | 节点和目标地址不变 | 只更换解析器或 DNS 模式 | 解析耗时、解析结果、首次访问 | 若只改善解析阶段，才支持 DNS 是主要原因 |
建议每组至少重复 3 次，并记录时间、节点地区或名称、客户端模式、IPv4/IPv6 情况和目标地址。不要把一次偶然的快慢直接当成结论。
如果所有网站都慢，先检查本地网络、设备负载、后台下载和代理模式；如果只有一个网站慢，不能仅凭现象断定节点故障，还要考虑目标站响应或该域名解析结果变化。
第二步：先测 DNS，区分本地解析与代理端解析
DNS 问题常见表现是：第一次打开域名明显慢、域名访问慢而已知 IP 访问较快、换解析器后解析阶段缩短，或者某个域名间歇性解析失败。但这些现象只能作为线索，仍应通过命令确认。
Windows：用 nslookup 对比 DNS 服务器
在 Windows 命令提示符中执行。下面的域名仅作占位，请替换成你有权访问且能够稳定重复测试的目标域名。
nslookup example.com这条命令使用系统当前配置的 DNS 服务器。再指定另一个 DNS 服务器进行对比：
nslookup example.com 1.1.1.1微软文档说明，nslookup 可以直接指定 DNS 服务器，也可以通过 -type=A 或 -type=AAAA 分别查询 IPv4 和 IPv6 记录。可继续执行：
nslookup -type=A example.com
nslookup -type=AAAA example.com如果默认 DNS 多次超时，而指定服务器能够稳定返回结果，说明本地配置的 DNS 链路值得继续检查；如果两者都很快，但代理访问仍慢，问题更可能在节点、目标站或连接阶段。nslookup 的用途和错误含义可参考微软 nslookup 文档。
macOS 或 Linux：用 dig 记录查询时间
dig example.com
dig @1.1.1.1 example.com
dig A example.com
dig AAAA example.com重点比较输出中的查询耗时、返回的 A/AAAA 地址以及是否出现超时。不要因为两个 DNS 返回的 IP 不同就直接认定其中一个有问题；CDN、区域和缓存都可能导致返回结果变化。需要结合后面的 curl 分段计时和节点对照。
检查客户端究竟使用哪种 DNS
代理客户端可能存在系统 DNS、客户端内置 DNS、远程解析、Fake-IP 或 Redir-Host 等不同处理方式，不能把系统命令的结果直接等同于代理流量实际使用的解析结果。以 Mihomo 配置为例，官方文档将 enhanced-mode 列为 fake-ip 或 redir-host，并提供 IPv6 开关等 DNS 配置项，具体行为取决于当前配置和客户端实现，可查看Mihomo DNS 配置文档。
在客户端中搜索“DNS”“enhanced-mode”“fake-ip”“redir-host”“IPv6”“nameserver”“proxy-server-nameserver”等关键词，记录当前值。若启用了 TUN，还要确认系统 DNS 请求是否被客户端接管；否则你测试到的可能只是系统解析，而不是代理端解析。
第三步：用 curl 把“慢”拆成 DNS、连接、首包和下载
浏览器只告诉你页面加载慢，无法直接说明慢在哪一段。curl 的 -w 参数可以输出多个时间字段，包括 DNS 查询、TCP 连接、TLS 握手、首字节和总耗时。curl 官方文档对这些字段有明确说明，可参考curl 命令手册。
直连测试
在 Windows PowerShell、macOS Terminal 或 Linux Shell 中执行：
curl -o /dev/null -sS -w "code=%{response_code}\nnamelookup=%{time_namelookup}\nconnect=%{time_connect}\nappconnect=%{time_appconnect}\nstarttransfer=%{time_starttransfer}\ntotal=%{time_total}\nspeed=%{speed_download}\n" https://example.com/Windows PowerShell 如果不方便使用 /dev/null，可以改为：
curl.exe -o NUL -sS -w "code=%{response_code}`nnamelookup=%{time_namelookup}`nconnect=%{time_connect}`nappconnect=%{time_appconnect}`nstarttransfer=%{time_starttransfer}`ntotal=%{time_total}`nspeed=%{speed_download}`n" https://example.com/通过本地代理端口测试
将 127.0.0.1:7890 替换为你自己的客户端 HTTP 代理端口；不要把订阅链接、Token、Cookie 或账号密码写进命令和文章。
curl -x http://127.0.0.1:7890 -o /dev/null -sS -w "code=%{response_code}\nnamelookup=%{time_namelookup}\nconnect=%{time_connect}\nappconnect=%{time_appconnect}\nstarttransfer=%{time_starttransfer}\ntotal=%{time_total}\nspeed=%{speed_download}\n" https://example.com/如果客户端只提供 SOCKS5 端口，可使用：
curl --socks5-hostname 127.0.0.1:7891 -o /dev/null -sS -w "code=%{response_code}\nnamelookup=%{time_namelookup}\nconnect=%{time_connect}\nappconnect=%{time_appconnect}\nstarttransfer=%{time_starttransfer}\ntotal=%{time_total}\nspeed=%{speed_download}\n" https://example.com/--socks5-hostname 会让域名通过 SOCKS5 代理解析；如果改用普通的 --socks5，解析路径不同，因此不要混用两种结果来做直接比较。
如何读结果
- namelookup 高：解析阶段耗时明显，优先对比系统 DNS、客户端 DNS、远程解析和 IPv6；但若代理模式改变了解析位置，命令输出仍需结合客户端日志判断。
- connect 高：TCP 建连慢，可能与节点距离、链路绕行、丢包或节点拥堵有关。
- appconnect 高：HTTPS/TLS 握手阶段耗时增加，可能与代理链路、协议协商、丢包或目标站响应有关。
- starttransfer 减去 appconnect 或 pretransfer 后仍很高：请求发出后到首字节等待较久，不能简单归咎于 DNS。
- total 高但前面各阶段正常：完整下载慢，重点查看节点带宽、拥堵、目标站限速和本地后台流量。
curl 官方字段是从请求开始累计的时间，不是每一段的独立耗时。例如要估算某一阶段，应使用后一个累计值减去前一个累计值，不能把 time_starttransfer 直接当成纯服务器处理时间。
第四步：只换节点，判断是单节点、出口还是本地网络
完成 DNS 对照后，保持 DNS、客户端模式、目标地址和测试时间不变，只更换节点。至少比较当前节点与另外两个不同地区或不同线路的节点，并重复相同的 curl 命令。
| 现象 | 更可能的方向 | 下一步 |
|---|---|---|
| 只有一个节点连接和首包明显慢 | 单节点负载、出口线路或节点侧异常 | 保留 DNS 不变，换同地区其他节点复测 |
| 同一地区节点都慢，其他地区正常 | 地区出口、路由或目标站区域响应 | 对比不同地区并记录 IPv4/IPv6 和时间段 |
| 所有节点都慢，直连也慢 | 本地网络、Wi-Fi、运营商链路或设备负载 | 关闭后台同步，改用有线或另一网络复测 |
| 白天正常、特定时段变慢 | 高峰拥堵或目标站时段性响应变化 | 至少在两个时间段重复测试，避免一次性结论 |
| curl 很快但浏览器慢 | 浏览器扩展、缓存、并发请求或规则匹配 | 无痕窗口测试，并检查客户端规则命中日志 |
延迟、带宽和丢包要分开看。可以使用系统自带命令观察基础连通性：
ping example.com
tracert example.commacOS 或 Linux 可使用：
ping -c 10 example.com
traceroute example.com这些命令只能帮助观察基础路径和丢包线索，不能代替真实代理下载测试。若代理使用的是远程出口，直连的 ping 路径也不一定等于代理流量路径，因此应把它作为辅助证据。
第五步：检查 IPv6、DNS 泄漏和客户端规则
如果 A 记录访问正常、AAAA 记录访问异常，或者启用 IPv6 后才出现连接超时，可能是 IPv6 路径、节点支持或本地网络配置不完整。可以分别测试：
curl -4 -o /dev/null -sS -w "total=%{time_total}\n" https://example.com/
curl -6 -o /dev/null -sS -w "total=%{time_total}\n" https://example.com/如果 -6 失败而 -4 正常，不代表 DNS 一定有问题；它可能只是 IPv6 路径不可用。此时可在客户端 DNS 设置中临时关闭 IPv6 解析作为验证，记录变化，并在确认网络具备稳定 IPv6 后再恢复。
DNS 泄漏检查应关注“实际 DNS 请求从哪里发出”，而不是只看配置文件里写了哪个服务器。检查客户端日志、系统 DNS 设置和 TUN 接管状态；如果启用了 Fake-IP，还要确认日志中的域名请求、Fake-IP 映射和最终规则命中是否一致。修改前先导出配置，测试失败时恢复原配置，再重新载入。
规则模式也会影响结论：同一个域名可能在规则模式下直连，在全局模式下经过代理。测试时记录模式，并查看日志确认目标请求确实命中了预期的代理或直连规则。
一张可填写的排查记录表
建议把以下字段复制到笔记中，每次只改变一个变量。记录 3 次以上，取中位数或至少标注最大、最小值。
| 时间 | 模式 | 节点 | DNS/解析模式 | IPv4/IPv6 | 解析耗时 | 连接耗时 | 首字节 | 总耗时 | 结果 |
|---|---|---|---|---|---|---|---|---|---|
| 填写日期和时刻 | 直连/规则/全局 | 节点名称或地区 | 系统/客户端/远程 | 4/6 | 填写秒数 | 填写秒数 | 填写秒数 | 填写秒数 | 正常/超时/慢 |
最终结论最好写成条件句，例如：“在同一设备和同一时间，两个节点的 DNS 查询都低于直连测试，但节点 A 的 TCP 连接和首字节明显高于节点 B，因此更偏向节点或出口线路问题。”不要写成没有测试依据的绝对结论。
第三方使用指南说明
本文是第三方使用指南，不代表任何客户端或网络服务的官方页面。客户端菜单、字段名称和 DNS 行为可能随版本、系统权限和配置变化；涉及具体服务状态、价格、线路或可用性的信息，本文未作推断，请以对应服务的官方资料为准。
常见问题
代理速度慢，换 DNS 还是换节点？
先用 nslookup 或 dig 测 DNS，再用 curl 查看分段时间。如果 DNS 查询耗时高且更换解析器后明显改善，优先处理 DNS；如果 DNS 很快但 TCP、TLS、首字节或下载阶段随节点变化明显，优先排查节点或出口线路。
为什么 nslookup 很快，浏览器打开网页还是慢？
nslookup 通常测试的是系统配置的 DNS，而浏览器或代理客户端可能使用自己的 DNS、远程解析、Fake-IP 或其他模式。还要检查 TCP 连接、TLS、首字节、规则命中、IPv6 和浏览器扩展，不能只用 DNS 结果解释整个页面加载时间。
域名访问慢，但直接访问 IP 很快，能确定是 DNS 问题吗？
不能直接确定。域名访问还包含 TLS 主机名、目标站路由、CDN 调度和证书校验等环节。应对比 nslookup/dig 的解析耗时、curl 的 namelookup 和连接阶段，并确认 IP 访问使用了正确的 Host 和 HTTPS 条件。
更换节点后速度变快，是否说明原节点一定故障？
只能说明在这次测试条件下，两个节点的表现存在差异，可能与节点负载、出口地区、路由、时段或目标站区域响应有关。建议在同一时间重复多次，并比较不同目标站，避免把一次测试写成永久性结论。
开启 TUN 后速度变慢，应该先检查什么？
先确认 TUN 是否接管了系统流量和 DNS，再检查规则模式、Fake-IP 或 Redir-Host、IPv6、日志中的规则命中以及是否出现多层代理。修改前备份配置，逐项恢复或关闭单个功能进行对照测试。
相关阅读
参考资料
- curl 官方命令手册：-w 时间字段与代理参数（curl.se）
- Microsoft Learn：nslookup 命令
- Microsoft Learn：DNS 客户端排查
- Mihomo 官方文档：DNS 配置与 enhanced-mode