sing-box 节点速度慢如何优化？4 步定位本地、节点还是配置

更新于 2026-10-25 · 96110.buzz

简答：sing-box 节点速度慢，先关闭 TUN 和系统代理测裸网，再用明确的 HTTP/SOCKS 代理命令复测；每组交替测试 5 次取中位数，最后检查规则、DNS、TUN、MTU、IPv4/IPv6 和设备负载。

定义：sing-box 节点速度优化，是通过对比裸网、代理链路、多个节点和客户端配置，定位瓶颈后只调整对应环节。

先看四步速查卡：不要同时改一堆参数

Ping 只有几十毫秒，视频却卡、下载速度却低，不一定只是节点问题。先把本地网络、代理链路、节点差异和配置因素拆开验证，一次只改变一个条件。

本文是独立使用指南，不代表任何客户端或节点服务的官方页面。sing-box 配置结构可参考官方配置文档。

第一步：建立可复现的裸网与代理基线

1. 先关闭 TUN 和系统代理。Windows 检查“设置→网络和 Internet→代理”；macOS 检查“系统设置→网络→当前连接→代理”；Linux 检查桌面代理设置以及 http_proxy、https_proxy、ALL_PROXY；移动设备先停止其他 VPN 或代理应用。
2. 确认环境变量没有残留代理。Windows 可执行 set http_proxy、set https_proxy、set ALL_PROXY；macOS 或 Linux 可执行 env | grep -i proxy。如果仍有代理变量，先清除或在新终端中测试。
3. 使用同一个固定 HTTPS 文件或页面。不要每次更换地址。大文件可能受到 CDN 缓存、服务端限速或目标站波动影响，因此测试结果只用于相对比较。

curl.exe -L -o NUL -sS -w "code=%{http_code} dns=%{time_namelookup} connect=%{time_connect} appconnect=%{time_appconnect} starttransfer=%{time_starttransfer} total=%{time_total} speed_download=%{speed_download}\n" https://<固定测试地址>

Windows 使用 curl.exe 和 NUL；macOS、Linux 将 -o NUL 改为 -o /dev/null。这里的 time_appconnect 用于观察 TLS 握手完成时间，speed_download 用于记录下载速度。

1. 代理测试必须明确指定本地代理。curl 不会因为你打开了系统代理就必然读取系统代理设置。HTTP 代理示例：

curl.exe -L -o NUL -sS -x http://127.0.0.1:<端口> -w "code=%{http_code} connect=%{time_connect} appconnect=%{time_appconnect} starttransfer=%{time_starttransfer} total=%{time_total} speed_download=%{speed_download}\n" https://<固定测试地址>

SOCKS5 代理并让代理端解析域名的示例：

curl.exe -L -o NUL -sS --proxy socks5h://127.0.0.1:<端口> -w "code=%{http_code} connect=%{time_connect} appconnect=%{time_appconnect} starttransfer=%{time_starttransfer} total=%{time_total} speed_download=%{speed_download}\n" https://<固定测试地址>

Windows 使用 NUL，macOS、Linux 使用 -o /dev/null。<端口>必须替换为客户端设置页显示的本地 HTTP 或 SOCKS 端口，不要照抄固定值。

代理模式下，time_connect通常只是 curl 连接本机代理入口的时间，不代表到远端节点的 TCP 建连时间；使用 socks5h 时，time_namelookup也不能直接代表远端 DNS 解析速度。time_starttransfer通常包含隧道建立、TLS 和目标服务端处理时间，不能单独归因于某一环节。

1. 每组交替测试 5 次。不要先连续测完一个节点再测另一个节点。建议按“裸网、节点 A、节点 B、节点 C”交替执行，每组取 5 次结果的中位数，并记录最大值与最小值。

第二步：判断是本地网络、单个节点还是所有节点慢

不要把 Ping 当成代理链路测速。直接执行的 Ping 通常是裸网 ICMP 结果，不等于代理出站的丢包和抖动；开启 TUN 后，ICMP 还可能受到路由接管和平台实现影响。代理链路应使用同一个 HTTPS 目标重复请求，比较总耗时中位数、最大值、最小值和下载速度波动。

如果测速网站或固定文件被规则送往 DIRECT，结果就不是节点速度。检查 sing-box 连接记录或日志中的出站标签，确认测试目标确实使用目标节点。涉及路由规则时，可对照官方 Route 文档。

第三步：比较节点和 URLTest，但不要把延迟当带宽

URLTest 会在指定出站之间测试，并根据测试地址和容差选择出站。官方文档说明，outbounds是待测试的出站标签，url是测试地址，interval是测试间隔，tolerance是毫秒容差；以下数值只是结构示例，按客户端和实际需求调整，字段以官方 URLTest 文档为准。

{
  "type": "urltest",
  "tag": "auto",
  "outbounds": ["proxy-a", "proxy-b", "proxy-c"],
  "url": "https://www.gstatic.com/generate_204",
  "interval": "3m",
  "tolerance": 50,
  "idle_timeout": "30m"
}

proxy-a、proxy-b、proxy-c必须替换成配置中真实存在的出站标签。URLTest 组只放要比较的代理出站，不要把 DIRECT 混入同一组，否则测试结果会失去可比性。

URLTest 的结果主要反映指定测试地址下的相对表现，不等于所有网站、视频或下载业务的实际带宽。正确做法是：先用 URLTest 初筛，再手动固定节点，用相同文件和相同网络交替测试 5 次。如果 URLTest 选出的节点下载仍慢，优先查看实际出站标签、目标地址和测试时段。

第四步：只改一项排查 DNS、TUN、MTU、IPv4/IPv6 和设备负载

规则与 DNS

如果只有部分网站或应用慢，先查看目标域名匹配了哪条规则、最终使用哪个出站。DNS 配置涉及服务器、默认服务器、策略和缓存等内容，字段说明见官方 DNS 文档。首开慢、重复打开明显变快时，优先观察 DNS 是否超时，并分别比较 IPv4 与 IPv6，不要同时更换多个 DNS。

TUN 与 MTU

当前 TUN 文档包含 mtu、auto_route、strict_route、stack、address 等字段。dns_mode和dns_address属于较新文档中的 TUN 字段，是否可用取决于客户端和版本，不能脱离实际版本照抄。完整字段说明见官方 TUN 文档。

1. 关闭 TUN，只用明确指定的 HTTP 或 SOCKS 代理测试。
2. 重新开启 TUN，保持原有 MTU，不修改其他项。
3. 如果只在 TUN 下变慢，再单独对比 MTU；每次修改后重复同一 HTTPS 请求 5 次。
4. 检查 auto_route、strict_route 与虚拟网卡、虚拟机、防火墙的冲突。

不要把“Ping 变低”作为 MTU 调整成功的唯一标准，应同时观察固定文件的下载速度、HTTPS 总耗时和是否出现断流。

stack 只作为旧配置的对照项

官方迁移说明显示，1.15.0 起 sing-tun 使用自有 TCP/IP 栈，stack已被标记为弃用，后续应逐步移除。当前配置不要为了追求速度盲目新增 system、gvisor 或 mixed；如果旧配置已经存在该字段，可在确认客户端支持的前提下只做一次对照测试，再以官方迁移说明和官方 TUN 文档为准。

IPv4、IPv6 与设备负载

如果开启 IPv6 后首开或 TLS 明显变慢，可分别测试 IPv4 和 IPv6 路径；不要把 prefer_ipv4 或 prefer_ipv6 当成所有网络的固定答案。Windows、macOS、Linux 和移动设备还应观察 CPU、内存、温度、后台同步及其他设备是否占用上行带宽。排查完成后再恢复常规日志级别。

按平台执行的最短检查清单

• Windows：关闭 TUN 和系统代理，检查“设置→网络和 Internet→代理”，再用 curl.exe 加 -x 测试；开启 TUN 后若部分程序异常，检查 strict_route、虚拟网卡和防火墙。
• macOS：检查“系统设置→网络→当前连接→代理”，确认没有其他 VPN 或代理占用；分别记录 Wi-Fi、有线网络和手机热点下的 5 次中位数。
• Linux：检查 env | grep -i proxy、systemd 服务环境、路由表，以及 iptables 或 nftables 是否与 auto_route、auto_redirect 冲突。具体规则以系统和客户端配置为准。
• Android：确认没有其他 VPN 占用，检查电池策略是否限制后台运行，并分别测试 Wi-Fi 与移动网络；Android 客户端对部分 TUN 字段的支持情况应以官方平台说明为准，可参考官方 Android 功能说明。
• iOS：检查系统 VPN 配置、网络切换和应用是否被排除在代理范围外；Apple 平台 TUN 字段支持存在差异，应参考官方 Apple 平台功能说明。

测试记录表与最终处理顺序

处理顺序可以归纳为：裸网也慢，先处理本地网络；只有一个节点慢，优先换节点并比较时段；同地区多个节点慢，比较其他地区或网络；所有节点都慢，先确认代理和规则是否生效，再检查 DNS、TUN、MTU、IPv4/IPv6 和设备负载。服务端负载、带宽限制或跨境线路拥塞如果没有可核验资料，只能写“未核实”。

如果测试显示线路本身是主要变量，可在确认需求后了解线路方案，以官网为准。

常见问题

sing-box 节点速度慢，应该先改 DNS 还是先换节点？

先关闭 TUN 和系统代理建立裸网基线，再用 -x 明确指定代理测试。如果只有一个节点慢，先比较其他节点；如果所有节点都慢，再检查规则、DNS、TUN、IPv4/IPv6 和设备负载。

为什么 Ping 很低，sing-box 下载速度还是慢？

Ping 通常只反映 ICMP 往返时间，不能代表 TCP、TLS、代理隧道和目标服务端处理速度。应使用同一个 HTTPS 地址测试 5 次，比较总耗时中位数、波动和下载速度。

curl 通过 sing-box 代理时，time_connect 很高是不是节点 TCP 慢？

不一定。使用本地 HTTP 或 SOCKS 代理时，time_connect 主要反映 curl 连接本地代理入口的时间，不等于远端节点连接时间；还应结合 time_appconnect、time_starttransfer 和多次总耗时判断。

开启 TUN 后速度变慢，应该马上修改 MTU 吗？

不应马上修改。先对比关闭 TUN、开启 TUN但保持原配置，以及只调整 MTU 的结果，同时检查 auto_route、strict_route、DNS 接管、IPv4/IPv6 和虚拟网卡冲突。

sing-box URLTest 选出的节点为什么不一定下载最快？

URLTest 基于指定测试地址和测试条件进行相对选择，结果不等于所有网站、视频或下载业务的实际带宽。应把 URLTest 作为初筛，再用固定文件和相同网络比较多个节点。

为什么只开了系统代理，curl 测出来却还是裸网？

curl 不一定读取系统代理设置。应使用 http_proxy、https_proxy、ALL_PROXY 环境变量，或在命令中加入 -x http://127.0.0.1:<端口>、--proxy socks5h://127.0.0.1:<端口>，端口以客户端设置页为准。

相关阅读

• v2rayN 连接失败怎么排查？先看日志、端口和代理模式
• Shadowrocket 规则不生效或 TUN 断网？先按这条链排查
• 最新排查指南

参考资料

1. sing-box 官方配置文档
2. sing-box 官方 TUN 文档
3. sing-box 官方 URLTest 文档
4. sing-box 官方 Route 文档
5. sing-box 官方 DNS 文档
6. sing-box 官方迁移说明
7. sing-box 官方 Android 功能说明
8. sing-box 官方 Apple 平台功能说明