代理速度慢怎么排查：先关代理，再查 DNS、TUN 和节点

更新于 2026-10-24 · getssrdog.top

简答：代理速度慢先关闭代理测本地基准，再固定同一节点，只改一个变量，依次检查 DNS、系统代理、TUN、规则、MTU、IPv6 和持续吞吐，最后再比较节点与网络时段。

定义：代理速度慢是指网页首屏、文件下载、视频播放或连接稳定性明显低于关闭代理时的表现，不能只用一次延迟测试判断。

先试这一步：用症状表确定排查方向

如果你遇到的是“已经连接但网页首屏慢、下载速度低、视频频繁卡顿”，先关闭系统代理、TUN 或 VPN 接管，使用同一个目标建立本地网络基准。随后固定一个节点，每次只改变一个条件，避免同时换节点、DNS、规则和协议。

症状	优先检查	先做什么	结果怎么判断
网页首屏慢	DNS、规则、TLS 建连	对比系统 DNS 与客户端 DNS，查看 TTFB	解析或首字节时间明显增加，优先查 DNS 和规则
下载慢但延迟低	吞吐、丢包、节点负载、MTU	用 curl 记录 speed_download，固定节点重复测试	低延迟但持续速度低，不能据此认定线路正常
视频卡顿或断流	抖动、丢包、Wi-Fi、节点拥塞	持续 ping 或 pathping，并切换手机热点	仅某网络或某时段出现，优先查本地链路或拥塞
开启 TUN 后全部变慢	虚拟网卡、权限、DNS 接管、IPv6、MTU	关闭 TUN，只保留系统代理测试	关闭 TUN 后恢复，问题集中在 TUN 接管链路
只有一个网站慢	目标网站、地域调度、规则	换目标网站和节点地区	其他网站正常时，不要直接判断所有节点都慢

Microsoft 的 ping 文档说明，ping 可观察 IP 层连通性和往返时间，但不能单独证明应用层下载速度正常，因此还要结合 curl、DNS 和客户端日志。

单变量排查记录卡

固定条件	本次只改动	记录结果
目标、节点、时间、网络保持不变	关闭或开启 TUN	首屏、TTFB、speed_download、是否断流
目标、节点、模式保持不变	系统 DNS 或客户端 DNS	Query time、返回地址、是否超时
目标、客户端保持不变	Wi-Fi 改手机热点	丢包、抖动、持续吞吐

第一层：关闭代理，确认本地网络是否拖慢

关闭系统代理、TUN、VPN 和浏览器独立代理，只保留普通 Wi-Fi、网线或蜂窝网络。
选择一个实际访问较慢的目标。下面的 example.com 必须替换成你有权限访问的域名。
记录网页首屏、持续下载速度、是否超时或断流。
再切换手机热点或网线复测。若换网络后明显恢复，优先检查路由器、局域网干扰、运营商链路或本地安全软件。

Windows 命令如下，工具由系统提供：

ping /n 20 example.com

tracert /d example.com

pathping /n /q 30 example.com

tracert 文档用于查看逐跳路径和往返时间；pathping 文档用于在多个跳点持续探测并统计丢包。某一跳不响应不一定代表故障，应重点看目标端、后续链路和是否反复出现。

macOS/Linux 可使用：

ping -c 20 example.com

traceroute example.com

mtr -rwzc 30 example.com

mtr需要系统已安装；如果提示命令不存在，先安装系统对应的软件包。Linux 还可检查路由和接口：

ip route

ip addr show

resolvectl status

重点看默认路由、TUN 接口是否存在、DNS 服务器是否符合当前设置。没有 TUN 时不要把“没有虚拟接口”当成故障。

第二层：检查 DNS 解析耗时、返回地址和 DNS 接管

DNS 主要影响域名解析和首次连接，不等于完整下载速度。Windows 的 nslookup适合快速查看指定 DNS 返回什么，但它本身不提供稳定的查询耗时。Windows PowerShell 可运行：

(Measure-Command { Resolve-DnsName -Name example.com -Server 1.1.1.1 -DnsOnly }).TotalMilliseconds

把域名和 DNS 地址替换为实际目标；Microsoft DNS 排查文档给出了用 Measure-Command 测量解析耗时的方法，并说明低于 1 秒通常可视为可接受的经验范围，但本文不把它当作所有网络的硬标准。也可运行：

nslookup example.com

nslookup example.com 1.1.1.1

nslookup -type=A+AAAA example.com

macOS/Linux 使用 dig：

dig example.com @1.1.1.1

dig example.com @1.1.1.1 A

dig example.com @1.1.1.1 AAAA

查看输出中的 Query time、是否返回 A/AAAA、是否超时，以及不同 DNS 返回地址是否差异明显。Microsoft DNS 排查资料将 Resolve-DnsName、nslookup和 dig分别用于可控查询、快速查询和更详细的解析检查。

如果使用 mihomo，DNS 配置应就近核对mihomo DNS 文档中的 enhanced-mode、fake-ip-range、nameserver、fallback和 dns-hijack。不要把其他内核的字段直接复制进 mihomo。若使用 TUN，还要查看mihomo TUN 文档中的 dns-mode和 dns-hijack行为。

浏览器安全 DNS、系统 DNS、客户端内置 DNS 和 TUN DNS 接管应分开测试。一次只改变其中一项，否则无法判断是解析服务器、浏览器还是客户端接管造成变化。

第三层：固定节点，分别对比系统代理、TUN 和规则

系统代理：关闭 TUN，只打开客户端的系统代理，测试同一网页和同一下载目标。
TUN：关闭系统代理，只打开 TUN；确认客户端是否要求管理员权限、服务模式或 VPN 权限。
全局模式：临时切换到全局，用来判断规则是否把目标错误地直连或分流。
规则模式：恢复规则模式，查看连接日志，确认目标域名是否真正进入代理节点。
固定节点：不要在同一轮测试中同时切换节点、协议和 DNS。

sing-box 的官方 TUN 文档列出了 address、mtu、auto_route、strict_route、dns_mode和 dns_address等字段。其中文档明确标注 dns_mode和 dns_address为 sing-box 1.14.0 起支持；官方变更记录也记录了这一变化。若当前客户端使用旧版本，不能直接假设这些字段可用，应以该版本文档和启动日志为准。

Clash Verge Rev 的界面通常把 System Proxy 与 TUN Mode分开；其公开设置文件说明，TUN 是虚拟网卡模式，启用后通常不需要再启用系统代理，并可在设置中打开日志目录。不同版本的菜单名称可能变化，优先寻找“系统代理、TUN、日志、核心日志、服务模式”等同义项。Clash Verge Rev 的公开界面字段可用于核对这些名称。

v2rayN 可在主界面查看核心日志，界面操作、设置和测速相关日志通常位于 guiLogs目录；具体路径应以当前安装方式为准。可参考其官方 FAQ。如果日志只显示 TUN 启动失败、权限错误、虚拟网卡错误或 DNS 解析失败，先处理这些基础问题，再比较节点速度。

第四层：用 curl 分开看 DNS、建连、首字节和持续吞吐

先确认 curl 版本：

curl.exe --version

Windows PowerShell 统一使用 curl.exe，避免 curl被 PowerShell 5.1 解释为 Invoke-WebRequest别名。Windows 不经过代理：

curl.exe -L -o NUL -w "DNS:%{time_namelookup} CONNECT:%{time_connect} TLS:%{time_appconnect} TTFB:%{time_starttransfer} TOTAL:%{time_total} SPEED:%{speed_download}\n" --max-time 30 https://example.com/

macOS/Linux 不经过代理：

curl -L -o /dev/null -w 'DNS:%{time_namelookup} CONNECT:%{time_connect} TLS:%{time_appconnect} TTFB:%{time_starttransfer} TOTAL:%{time_total} SPEED:%{speed_download}\n' --max-time 30 https://example.com/

使用 HTTP 代理时，Windows：

curl.exe -x http://127.0.0.1:7890 -L -o NUL -w "TTFB:%{time_starttransfer} TOTAL:%{time_total} SPEED:%{speed_download}\n" --max-time 30 https://example.com/

macOS/Linux：

curl -x http://127.0.0.1:7890 -L -o /dev/null -w 'TTFB:%{time_starttransfer} TOTAL:%{time_total} SPEED:%{speed_download}\n' --max-time 30 https://example.com/

使用 SOCKS5 并让代理解析域名时，Windows：

curl.exe --socks5-hostname 127.0.0.1:7891 -L -o NUL -w "TTFB:%{time_starttransfer} TOTAL:%{time_total} SPEED:%{speed_download}\n" --max-time 30 https://example.com/

macOS/Linux：

curl --socks5-hostname 127.0.0.1:7891 -L -o /dev/null -w 'TTFB:%{time_starttransfer} TOTAL:%{time_total} SPEED:%{speed_download}\n' --max-time 30 https://example.com/

端口必须替换为客户端实际监听端口；如果立即拒绝连接，先查端口和客户端日志。curl 官方手册说明，time_namelookup表示解析耗时，time_connect表示 TCP 建连耗时，time_appconnect包含 TLS 等连接阶段，time_starttransfer表示收到首字节的时间，speed_download是完整传输的平均下载速度。网页太小只能参考首字节，持续吞吐应使用较大的、合法可访问的测试文件。

第五层：检查 MTU、IPv6、虚拟网卡和双重接管

MTU 测试要找“仍能通过的最大数据长度”，再用数据长度加 28 字节估算 IPv4 路径 MTU。这个估算只适用于相应的 IPv4 不分片测试，不能直接当成 TUN 必须设置的值。

Windows：

ping /f /l 1472 example.com

macOS：

ping -D -s 1472 example.com

Linux：

ping -M do -s 1472 example.com

目标域名必须替换为会响应 ICMP 的地址；若不响应，换本地网关或其他可测试目标。逐步降低数值，例如 1464、1452、1400，找到可以稳定返回的最大值，再加 28 作为参考。Microsoft ping 文档说明，Windows 的 /f用于设置 IPv4 不分片标志。

若 TUN 配置提供 mtu字段，应先保留默认值；只有在对照测试显示 MTU 相关问题时，才按当前内核文档或客户端界面修改。不要把路径 MTU 的估算值直接复制到所有设备和所有协议。

IPv6 可做单独对照：

ping /6 example.com

ping6 -c 20 example.com

如果只有 IPv6 路径超时或波动，可临时关闭客户端 IPv6 接管，再用同一目标复测。该步骤用于定位，不代表所有环境都应永久关闭 IPv6。

检查是否同时运行两个 VPN/TUN 客户端、企业 VPN、容器网络或安全软件。Windows 查看网络适配器和防火墙权限；macOS 在“系统设置→网络”中查看 Wi-Fi、以太网、VPN 和虚拟接口；Android 检查系统 VPN 与私人 DNS。mihomo 文档指出，Android 开启私人 DNS 时，DNS 请求可能无法被自动劫持，因此私人 DNS 要与客户端 DNS 分开对照。

移动端和桌面端的最短路径

平台	操作路径或命令	重点判断
Windows	关闭 TUN，保留系统代理；运行 Resolve-DnsName、ping、tracert、curl.exe	管理员权限、虚拟网卡、防火墙、IPv4/IPv6、代理是否被其他软件覆盖
macOS	系统设置→网络查看代理、VPN、虚拟接口；运行 dig、traceroute、curl	VPN 冲突、utun 接口、DNS、MTU 和系统代理状态
Linux	运行 ip route、ip addr show、resolvectl status、mtr、curl	默认路由、TUN 接口、auto_route、auto_redirect、nftables 和 DNS 接管
iOS	确认只有一个 VPN 或代理配置在运行，切换 Wi-Fi 与蜂窝网络	VPN 权限、应用分流、网络类型和是否仅某个应用变慢
Android	设置→网络和互联网→VPN；设置→网络和互联网→私人 DNS；切换 Wi-Fi 与热点	始终开启 VPN、私人 DNS、应用分流和后台限制

移动端通常没有桌面端完整的 traceroute、mtr 或 curl 环境，因此优先采用“单一 VPN 接管、切换网络、固定节点、查看客户端日志”的对照法。Android 的官方VPN 设置说明可用于确认当前 VPN 状态；私人 DNS 只影响 DNS 查询，不等同于完整的网络接管。

把结果记录成可复现表格

项目	示例记录
日期与时间	填写本地时间，必要时分别记录白天和晚间
设备与网络	Windows；Wi-Fi；随后用手机热点复测
客户端模式	系统代理、TUN、全局或规则
固定节点	记录节点地区或名称，不只写“某节点”
DNS	系统 DNS、客户端 DNS、Fake-IP 或 DNS 接管状态
指标	Query time、TTFB、TOTAL、SPEED、丢包、是否断流
单变量变化	本轮只关闭 TUN，其他条件不变

判断顺序可以简化为：所有节点和所有目标都慢，先查本地网络、客户端和日志；只有一个节点慢，优先做节点对照；只有一个网站慢，优先查目标网站、规则和地域路径；低延迟但下载慢，继续看持续吞吐、丢包、抖动和节点负载。

本文是第三方使用指南，与相关项目及开发者无隶属关系。关于具体服务状态、价格、线路等级和可用性，本文未核实，相关信息应以对应官方资料为准。

结论：低延迟不等于高吞吐

延迟只表示一次往返等待时间，持续下载还会受到丢包、抖动、并发连接、节点负载、协议处理、MTU、目标网站和本地 Wi-Fi 影响。因此至少同时记录首屏或首字节时间，以及持续下载速度和断流情况。

最稳妥的顺序是：关闭代理确认本地网络→检查 DNS→固定节点→分别对比系统代理与 TUN→查看日志确认规则→测试 MTU、IPv6 和虚拟网卡→最后比较节点与时段。每次只改一个变量，才有机会定位真正原因。

常见问题

代理速度慢，应该先换节点还是先改 DNS？

先关闭代理确认本地网络，再固定一个节点测试 DNS、TTFB 和持续吞吐。只有多个目标都能正常解析，且系统代理、TUN 和规则没有明显异常后，才适合比较其他节点。

Windows PowerShell 中 curl 命令应该怎么写？

Windows PowerShell 统一写 curl.exe，输出目标使用 NUL；macOS/Linux 写 curl，输出目标使用 /dev/null。Windows PowerShell 5.1 中 curl 可能是 Invoke-WebRequest 别名，直接照搬 curl 参数会报错。

nslookup 能直接看 DNS 查询耗时吗？

不建议用 nslookup 判断稳定的查询耗时。Windows 可用 Measure-Command { Resolve-DnsName example.com -Server 1.1.1.1 -DnsOnly }，macOS/Linux 可用 dig example.com @1.1.1.1，并查看 Query time。

延迟只有几十毫秒，为什么下载仍然很慢？

延迟只表示往返等待时间，不能代表持续吞吐。丢包、抖动、节点负载、MTU、并发连接和目标网站都会影响下载，应使用 curl 的 speed_download 或合法大文件的持续下载结果判断。

开启 TUN 后网页变慢，应该永久关闭 TUN 吗？

先关闭 TUN、只保留系统代理做对照。如果速度恢复，再检查权限、虚拟网卡、防火墙、DNS 接管、IPv6、MTU 和是否存在第二个 VPN。一次对照不能证明 TUN 在所有环境中都有问题。

手机上怎么排查代理变慢？

iOS 和 Android 先确认只有一个 VPN 或代理应用接管流量，再切换 Wi-Fi、蜂窝网络或手机热点。Android 还要单独检查私人 DNS；若只有某个应用变慢，优先查看应用分流和客户端日志。

MTU 测试得到最大数据长度后怎么处理？

对 IPv4 不分片测试，找到仍能稳定通过的最大数据长度后加 28 字节，作为路径 MTU 的参考值。不要直接把它当成所有 TUN 的固定设置，修改前应以当前客户端或内核文档为准。