先分清：网页打开慢，还是持续下载慢
Clash 显示节点延迟正常，不代表下载速度一定正常。列表中的测速通常是通过节点请求一个测试 URL，结果受连接建立、目标站点响应、连接复用及客户端测速实现影响。它不是带宽测试，也不能直接代表视频站点或文件服务器的体验。
排查前先固定一个发生问题的网站、一台设备和一个节点。暂时停止云盘同步、系统更新与其他下载，使用规则模式，在连接列表中确认目标请求确实进入了预期策略组。若请求实际命中 DIRECT，更换代理节点并不能验证这条连接。
| 可见症状 | 优先检查 | 下一步动作 |
|---|---|---|
| 首次打开等几秒，随后正常 | DNS、连接建立、目标站响应 | 比较解析与首字节耗时 |
| 文件下载始终低速 | 节点带宽、线路拥堵、源站限速 | 固定文件并更换节点对照 |
| 只有一个应用缓慢 | 代理接管、分流规则、应用协议 | 查看该应用的新建连接 |
| 每天晚间明显变慢 | 本地宽带、运营商路径、节点负载 | 保留晚间与非高峰记录 |
| 开 TUN 后才慢 | 路由冲突、DNS 接管、MTU | 与仅系统代理状态比较 |
建立测速基线：固定入口、节点与目标
确认代理端口与实际出口
下面用本机混合端口 7890 举例。它不是所有客户端的固定默认值，应先在客户端的端口设置或当前生效配置中确认 mixed-port。HTTP 代理请求可使用该端口；控制面板的 API 端口不是业务代理端口，不能互换。
在 Windows PowerShell 中可执行下列命令。它显式通过本机代理访问一个小页面，适合比较建连和响应，不用于测满下载带宽。macOS 或 Linux 将 curl.exe 改为 curl 即可。
curl.exe --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 30 --output NUL --silent --show-error --write-out "connect=%{time_connect} tls=%{time_appconnect} first=%{time_starttransfer} total=%{time_total}\n" https://example.com/macOS、Linux 同时把 NUL 改为 /dev/null。这些时间均以秒计，且是从请求开始累计的时间点。使用 HTTP 代理时，time_connect 主要表示连接本机代理的耗时；time_appconnect 还会包含代理隧道建立与 TLS 握手的等待，不能把它直接解释为节点往返延迟。域名通常交由代理链路解析，因此这条命令也不能单独证明本地 DNS 快慢。
带宽测试另选持续传输
- 选择自己有权访问、大小至少约 100 MB 的固定文件，确保每次请求的资源一致。
- 先用单连接下载，观察稳定传输 30 至 60 秒后的速度，再测试下载器的多连接模式。
- 固定同一节点；若策略组会自动切换，临时手动选定节点，并重新建立测试连接。
- 记录测试时间、接入网络、规则命中、节点、速度单位与客户端内核信息。
注意单位换算：8 Mbps ≈ 1 MB/s，而标称 100 Mbps 宽带的理论上限约为 12.5 MB/s，实际可用速度还受协议开销影响。不要把测速网站的 Mbps 与下载器的 MB/s 直接比较。
第一层：判断节点质量与目标适配
节点层先解决“是否只有这个节点慢”。选同一区域的两个节点，访问同一个目标，各测试 3 次。优先保持地区一致，避免跨洲距离、出口区域和内容分发位置同时变化。如果订阅标明两条不同线路，可进一步对照；名称不同不保证底层入口、服务器或出口不同。
低延迟节点未必有更高吞吐
下面是判读演示数据，不是本站实测或节点推荐。假设同一文件、同一时段的结果为：节点 A 测试延迟 65 ms，下载 0.8 MB/s；节点 B 延迟 140 ms，下载 8 MB/s。持续下载可以优先选择 B，交互场景则还要比较首字节时间与稳定性。只按延迟数字排序，会漏掉节点限速和繁忙程度。
- 某节点访问多个站点都慢：优先怀疑该节点的负载、限速或到入口的路径。
- 同节点只有一个站点慢：检查目标站点限速、出口区域和 CDN 分配，不能据此判定节点整体失效。
- 所有节点都慢：进入线路与本机层，特别检查家庭网络占用和是否实际选中了不同出口。
切换策略后，已经建立的下载连接可能仍走旧节点。应取消测试任务并重新开始，或只关闭连接列表中对应的测试连接，再核对新的连接链路。不要用切换前后同一条长连接的速度作为对照。
自动策略组也会影响结果。url-test 依据配置的测试目标选择节点；fallback 注重按顺序选择可用节点；load-balance 分配连接，不等于把单条文件下载的带宽叠加。要评估一个节点，应先把自动选择因素排除。
第二层：区分线路拥堵与本地接入瓶颈
线路层使用“两种网络、两个时段”的对照法。保持电脑、客户端配置、节点及目标不变，先测家庭宽带，再测手机热点；之后在非高峰时段复测。热点会改变运营商路径，也可能改变 IPv4、IPv6 与 NAT 环境，因此结果用于缩小范围，而不是直接证明某家运营商存在特定限制。
| 对照结果 | 更值得检查的方向 | 补充验证 |
|---|---|---|
| 家庭网络慢，热点正常 | Wi-Fi、路由器、宽带到节点路径 | 电脑改用网线直连路由器 |
| 两种网络均只在晚间慢 | 共享节点负载或共同的远端瓶颈 | 换不同线路入口的节点 |
| 代理与境内直连同时变慢 | 本地带宽占用、无线干扰、路由器负载 | 暂停上传并检查其他设备 |
| 不同节点访问同一资源均慢 | 源站或内容分发路径 | 换另一个可靠资源对照 |
先排除上传占满和无线链路
上行带宽被备份、直播或同步任务占满时，下载确认包和交互请求也可能排队。Windows 11 可打开「任务管理器」→「性能」→当前使用的「以太网」或「Wi-Fi」，观察发送、接收速率；再在「进程」页按网络占用排序。先暂停高占用任务，等待约 30 秒后复测。
无线环境中先靠近路由器，再对照网线连接。5 GHz 不一定在隔墙条件下优于 2.4 GHz，关键是实际信号和干扰。若有线恢复正常，继续修改 Clash DNS 通常不是优先方向。
路由追踪只能作为辅助证据。中间路由器可能降低 ICMP 响应优先级，某一跳显示超时或丢包，不代表转发业务流量同样丢包。应结合最终目标表现、持续下载曲线及跨网络对照判断。
第三层：检查系统代理、规则与 TUN 接管
先确认慢的应用有没有经过 Clash
系统代理主要影响遵循系统代理设置的应用，不会自动接管所有流量。Windows 11 的系统入口是「设置」→「网络和 Internet」→「代理」；客户端开启系统代理后，可检查这里显示的地址和端口是否与客户端一致。浏览器扩展、应用自己的代理配置仍可能覆盖系统设置。
打开客户端连接列表，重新发起一次请求，查看目标域名或 IP、命中的规则、策略链和上传下载量。若没有对应记录，先排查接管；若记录显示直连，先排查规则顺序。规则通常自上而下匹配，过早出现的宽泛规则或 MATCH 会改变后续规则的作用。
TUN 对照测试保持变量单一
- 保留当前配置备份，退出其他 VPN 和会创建虚拟网卡的代理工具。
- 关闭 TUN，仅开启系统代理，用浏览器测试同一目标并记录结果。
- 关闭系统代理，再开启 TUN，确认客户端具备所需权限且流量确实进入连接列表。
- 比较相同节点下的结果，并检查日志中的路由、DNS 与连接错误。
以上步骤是定位问题的对照方法，不是要求日常必须二选一。不同客户端对 TUN 的路由安装和 DNS 接管处理不同；需要以当前版本的实际设置为准。启用 TUN 本身不等于提升节点带宽，它主要解决透明接管问题。
DNS 调整：针对解析等待，不替代带宽排查
DNS 主要影响域名解析、地址选择和部分分流判断。若连接建立后能稳定高速下载，但第一次打开域名总要等待，DNS 才是优先检查项。相反，持续传输稳定在低速，通常不能靠更换解析服务器直接解决。
检查当前生效配置，不只看订阅原文
- 确认客户端有没有通过覆写或合并功能修改
dns，实际运行配置可能不同于订阅文件。 - 确认 DNS 上游可达；使用加密 DNS 时，也要检查其连接是否超时。
- 使用 mihomo 的
respect-rules等选项时，核对 DNS 请求如何分流，以及代理服务器域名能否独立解析，避免形成依赖循环。 - 若使用
fake-ip，某些应用拿到映射地址属于预期行为；切换模式后应重启测试应用，避免旧缓存干扰。
Windows 可在终端运行 ipconfig /flushdns 清理系统 DNS 缓存，但它不会同步清空浏览器缓存与内核自身的 DNS 缓存。刷新后首次请求变慢也可能只是重新解析，不能只比较这一次请求。
IPv6 同样需要对照，而不是直接永久关闭。若日志显示 IPv6 连接反复超时而 IPv4 正常，可临时限制 IPv6 解析或连接进行验证；操作系统、客户端和 DNS 层的相关开关并非同一个设置。验证完成后恢复原状，再针对实际故障修正配置。
并发设置：区分连接竞速与多线程下载
mihomo 的 tcp-concurrent 用于对域名解析得到的多个地址进行 TCP 连接竞速。它可能改善部分目标的建连等待，不会把节点的带宽上限成倍提高，也不等同于增加文件下载线程。旧版 Clash 或其他内核不一定支持同名选项，应先核对客户端显示的内核与对应文档。
# mihomo 顶层配置片段，需合并到现有配置
tcp-concurrent: true这不是完整配置。只在确认内核支持、并怀疑多地址建连等待时进行 A/B 测试。订阅由远端维护时，优先使用客户端提供的持久化覆写入口；直接编辑订阅缓存，下一次更新可能恢复原值。应用后查看日志，确认字段被接受，再比较首次响应时间。
下载器线程数从低到高验证
对允许分段下载的资源，可依次测试 1、4、8 个连接。若单连接 1 MB/s、4 连接合计约 4 MB/s，说明并发缓解了单连接限制，但仍不能确定限制来自源站、线路还是节点。若 8 连接比 4 连接更慢，或网页响应明显变差，就应回退，不必继续堆线程。
同时观察设备资源。Windows 11 可在「任务管理器」→「详细信息」中查看代理内核进程，macOS 可在「活动监视器」检查 CPU 与网络。测速时内核 CPU 持续吃满、设备发热或路由器负载过高，都可能形成吞吐瓶颈；低 CPU 占用则不能单独证明线路正常。
收敛结论：保留能重复验证的设置
完成排查后，结论应落到具体条件，例如“同节点在热点正常、家庭有线网络晚间慢”，而不是“Clash 不稳定”。前者能继续定位线路，后者无法指导下一步操作。
- 只有个别节点慢：保留同目标的对照结果，换到表现稳定的节点，并向订阅提供方反馈时间和线路名称。
- 同一网络整体慢：先处理上传占用、无线接入与路由器负载，再评估运营商路径。
- 只有 TUN 慢：围绕路由冲突、DNS 接管和 MTU 逐项测试，不同时改多个参数。
- 仅首次打开慢：优先查解析与建连；持续下载慢则回到节点、线路和源站对照。
- 配置修改没有稳定收益：恢复原值，删除临时调试项，保留最少且可解释的改动。
反馈问题时附上客户端版本、内核名称与版本、操作系统、网络类型、发生时段、代理模式和三次测试结果。日志只保留必要片段，隐藏订阅链接、访问令牌、节点密码及其他凭据。端口与接管方式可继续参照端口排查说明；初次配置则从系统代理设置步骤开始核对。