先把“速度慢”拆成可测量的问题
Clash 页面显示的延迟、网页打开时间和文件下载速度不是同一个指标。延迟测试通常只请求一个很小的 HTTP 资源，用来观察连接建立与响应所需时间；下载速度还会受到目标服务器带宽、跨境线路、TCP 拥塞控制、协议开销和本地无线网络影响。一个节点显示 68 ms，不代表它一定能跑满带宽；另一个节点显示 145 ms，也不代表观看视频必然卡顿。
排查前先固定变量。不要一边切节点、一边改 DNS、同时打开 TUN，再根据一次测速下结论。建议先记录当前网络、代理模式、节点名称和测试时间，然后按照“直连基线—单节点延迟—单连接下载—多连接下载”的顺序测试。每项至少测试 3 次，取中位数，而不是只看最高值。
建立一组可复现的基线数据
- 暂停 Clash 的系统代理与 TUN 模式，在同一设备上测试直连网络。若 500 Mbps 宽带直连只能达到 35 Mbps，应先检查 Wi-Fi、网线或运营商网络。
- 重新开启 Clash，选择“规则”模式，并固定一个节点，不要使用会自动切换成员的策略组。
- 关闭云盘同步、系统更新、游戏平台下载和浏览器后台视频，避免它们占用带宽。
- 分别在 09:00、20:00 和 23:00 测试。晚高峰显著下降通常更接近线路拥堵，而不是客户端设置错误。
- 记录延迟、下载速度、上传速度、丢包表现和目标站点。只有同一测试目标下的数据才适合横向比较。
| 测试项 | 示例结果 | 主要用于判断 |
|---|---|---|
| 直连下载 | 468 Mbps | 本地接入网络是否正常 |
| 节点延迟 | 82 / 86 / 80 ms | 连接稳定性与基础往返时间 |
| 代理单连接下载 | 6.8 MB/s | 单条连接的线路质量 |
| 代理多连接下载 | 22.4 MB/s | 节点总带宽与并发能力 |
第一层:检查节点质量与协议开销
完成基线后，先处理最容易替换的节点层。订阅里的地区名称只是标签，“香港 01”和“日本 02”无法直接说明入口位置、出口运营商或晚高峰容量。真正有用的是连续测试结果、不同时间段表现，以及该节点访问目标站点时走过的实际线路。
延迟要看稳定性，不只看最低值
在客户端的代理或策略页面执行延迟测试时，连续测 3 至 5 次。若结果为 75、79、81 ms，稳定性通常优于 42、180、超时、96 ms 的节点。后者虽然出现过 42 ms，实际使用中却可能频繁重传或断流。测试 URL 也会影响结果，应保持客户端默认地址或固定使用可稳定返回小文件的 HTTPS 地址，不要在比较过程中反复更换。
- 低于 80 ms：通常适合网页、即时通信和对延迟敏感的交互，但仍需验证带宽。
- 80 至 180 ms：跨境连接中的常见区间，视频与下载是否流畅主要取决于线路稳定性。
- 高于 250 ms：网页首包、远程终端和实时操作可能明显迟缓。
- 频繁超时：优先视为节点不可达、测试目标不可达或链路不稳定，而不是单纯“延迟高”。
倍率影响流量计费，不直接代表速度
节点名称中的“0.5×”“1×”“2×”通常表示订阅服务的流量计费倍率。下载 1 GB 数据，2× 节点可能计入 2 GB 用量，但倍率本身不保证速度更高。高倍率节点有时对应更昂贵的线路，有时只是资源分组方式，最终仍应以同一时间、同一目标的实测结果为准。
协议与加密会占用 CPU
在现代桌面处理器上，常见代理协议的处理开销通常不是第一瓶颈；但旧款路由器、低功耗迷你主机和入门 Android 设备可能在高速传输时出现单核满载。测速期间打开系统任务管理器或活动监视器：如果 mihomo、Clash 或客户端核心持续接近一个 CPU 核心的上限，同时速度不再增长，就需要考虑设备性能、协议参数和加密开销。
- 关闭重复运行的代理核心，确认系统中只有当前客户端监听代理端口。
- 桌面端优先使用当前客户端支持的稳定版 mihomo 核心，不要混用来源不明的旧核心文件。
- 在路由器上运行时，将相同订阅导入桌面端复测。桌面端快、路由器慢，通常说明瓶颈位于路由器 CPU、内存或网络接口。
- 不要为了测速随意修改订阅下发的协议字段，例如传输层、服务器名称或 Reality 参数；这些字段必须与服务端一致。
第二层:判断入口、出口与晚高峰线路拥堵
节点本身可用，不代表从当前运营商到节点入口的线路始终顺畅。家庭宽带到代理入口、入口到出口、出口到目标站点是三段不同链路。任意一段发生拥堵，都可能表现为延迟正常但下载速度低，或白天正常、晚上明显变慢。
用时间和网络交叉测试定位拥堵
最有效的方法不是连续切换几十个节点，而是做小规模对照。选择同地区的 2 个节点、不同地区的 2 个节点，在固定测试目标上分别记录结果。随后将电脑从家庭 Wi-Fi 切换到手机热点，再测同一节点。如果家庭宽带只有 3 MB/s，而手机热点达到 14 MB/s，问题更可能与本地运营商到入口的路径有关；如果两种接入网络都慢，则应继续观察节点容量或出口质量。
| 现象 | 更可能的原因 | 下一步 |
|---|---|---|
| 白天 18 MB/s，晚间 2 MB/s | 晚高峰线路或节点容量拥堵 | 换入口线路或错峰复测 |
| 延迟稳定，单连接慢，多连接快 | 单连接受限或跨境丢包 | 更换线路并测试实际应用 |
| 所有节点同时变慢 | 本地网络、订阅入口或上游故障 | 测试直连与手机热点 |
| 只有一个目标站点慢 | 目标站点出口、分流或 CDN 路径 | 核对规则命中与出口地区 |
地区距离不是唯一标准
物理距离较近通常有利于降低延迟，但线路质量可能改变结果。上海用户连接香港节点未必总比东京节点快；某条东京线路如果拥有更稳定的运营商互联，晚高峰表现可能更好。选择地区时还要考虑目标服务的 CDN 调度和访问限制。用于软件仓库下载、视频播放和远程办公的最优节点可能不同，因此可以分别建立策略组，而不是让所有流量长期挤在一个节点。
第三层:核对分流规则、代理端口与 TUN 模式
节点与线路没有明显异常后，再检查本地配置。常见问题并不是代理核心“限速”，而是目标流量没有走预期策略、应用绕过系统代理、多个代理程序互相覆盖，或者 TUN 与安全软件同时处理数据包。
先看连接记录中的规则命中
打开客户端的“连接”或“日志”页面，访问速度异常的网站，确认域名、规则名称和最终策略。不同客户端菜单名称略有差异，常见路径是「连接」→ 选择请求 → 查看“规则”与“代理链”，或「日志」→ 将级别调整为 Info 后重新请求。目标站点如果命中 DIRECT，说明它没有经过代理；如果命中一个自动策略组，还要继续确认该组当前选择了哪个节点。
Clash 规则按从上到下的顺序匹配，先命中的规则生效。过于宽泛的规则放在前面，可能覆盖后面的精确规则。例如将局域网与国内规则放在代理规则之前通常合理，但自定义的 DOMAIN-SUFFIX 如果位置错误，就可能让目标域名走错策略。
rules:
- DOMAIN-SUFFIX,example.com,Proxy
- DOMAIN-KEYWORD,example,Proxy
- GEOIP,CN,DIRECT
- MATCH,Proxy修改规则后应重新加载配置，并在连接页面关闭旧连接再测试。现有 TCP 连接通常不会因为策略变化自动迁移到新节点。浏览器中的长连接、HTTP/2 与 HTTP/3 会让旧路径继续存在，因此必要时可完全退出浏览器后重开。
确认端口没有被重复转发
常见本地端口包括 HTTP 代理 7890、SOCKS5 代理 7891，以及将两者合并的 mixed-port: 7890。实际端口以当前配置为准。浏览器扩展、下载工具和终端环境变量应指向正在监听的端口，避免出现“应用代理到旧客户端，旧客户端再转发到新客户端”的链式代理。
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info在客户端中可沿「设置」→「参数设置」查找混合端口、系统代理与局域网连接选项。若界面路径不同，则直接查看当前配置中的 mixed-port。仅在确实需要其他设备接入时开启局域网连接，并确认操作系统防火墙规则与监听地址匹配。
TUN 模式只在需要接管更多流量时启用
系统代理主要影响遵守操作系统代理设置的应用，部分游戏、命令行程序和自带网络栈的软件会绕过它。TUN 模式通过虚拟网络接口接管更多流量，能解决“浏览器正常、其他应用直连”的问题，但它不会天然提高节点速度。相反，驱动冲突、错误路由、MTU 不合适或重复接管可能降低吞吐。
- 先关闭 TUN，只开启系统代理测速；再关闭系统代理、单独开启 TUN 复测，避免两种路径难以区分。
- 若 TUN 开启后网页正常但大文件卡住，可检查 MTU。常见测试范围为 1280 至 1500，但应依据接入网络逐步调整，不宜直接照搬他人参数。
- 临时退出其他 VPN、网络加速器、抓包工具和虚拟网卡软件，排除路由优先级冲突。
- 修改 TUN 设置后重启核心，并确认系统路由表与 DNS 劫持功能已经按客户端提示生效。
DNS 设置:解决解析慢、污染与错误分流
DNS 通常不会决定大文件传输的持续速度，但会影响首个页面打开时间、CDN 地址选择和基于域名的分流。典型症状包括：第一次打开网站要等待数秒，刷新后变快；同一节点访问域名很慢，直接访问已知 IP 却正常；连接记录里只出现 IP，域名规则没有命中。
避免系统 DNS 与代理 DNS 互相打架
使用 mihomo 内核时，DNS 配置可能包含 nameserver、proxy-server-nameserver、fallback、fake-ip 等项目。nameserver 用于常规查询，代理服务器域名本身需要由可用的解析器先解析；如果这个步骤依赖尚未建立的代理，就可能形成解析循环。订阅已经提供完整 DNS 配置时，应先验证原配置，而不是一次加入大量公共解析器。
dns:
enable: true
ipv6: false
enhanced-mode: fake-ip
nameserver:
- 223.5.5.5
- 119.29.29.29
proxy-server-nameserver:
- 223.5.5.5这段配置只是结构示例，不适合直接覆盖所有订阅。若网络支持 IPv6，但代理节点或规则没有正确处理 IPv6，应用可能优先尝试不可用地址并等待超时。排查时可以暂时设置 ipv6: false 做对照；确认问题后，再根据实际网络能力决定是否恢复，而不是长期依赖试错开关。
Fake-IP 模式下检查排除项
fake-ip 会为域名返回保留地址，并由内核在连接阶段还原域名，从而提高规则匹配能力。局域网设备发现、打印机、部分游戏登录和依赖真实 DNS 答案的应用可能需要加入排除列表。若只有某个应用启动慢，可先查看日志中是否出现重复 DNS 查询、连接重试或局域网域名被代理，再补充精确排除项，避免把整个顶级域名都排除。
本地设备与网络:排除 Wi-Fi、浏览器和后台任务
如果所有节点都达不到直连基线，需要回到设备层。2.4 GHz Wi-Fi 在拥挤环境中可能只能提供几十 Mbps 的稳定吞吐，信号格数满也不代表干扰少。条件允许时使用网线或 5 GHz、6 GHz Wi-Fi 对照测试，并将设备移到路由器附近。若网线达到 460 Mbps，而原位置 Wi-Fi 只有 72 Mbps，继续更换节点不会解决问题。
用系统监控确认瓶颈位置
- CPU：代理核心单核持续满载，速度随 CPU 占用封顶，优先检查设备性能与协议处理。
- 内存：系统频繁交换内存时，浏览器、下载工具和代理核心都会出现停顿。
- 磁盘：下载到机械硬盘、加密容器或实时同步目录时，写入速度可能成为瓶颈。
- 后台流量：操作系统更新、照片备份和游戏平台可能占满上行，进而拖慢下载确认包与网页响应。
- 浏览器扩展：代理扩展如果另设规则或端口，会覆盖系统代理。可使用全新浏览器配置文件做一次对照。
测速时还应关闭浏览器的并行下载实验选项和第三方下载扩展，先用默认设置获得基线。若只有一个浏览器慢，而系统下载工具与其他浏览器正常，问题通常位于扩展、缓存、HTTP/3 或浏览器代理覆盖，而不是 Clash 核心。
按症状执行的十分钟排查顺序
- 第 1 分钟：关闭系统代理和 TUN，测试直连速度，确认本地宽带基线。
- 第 2 分钟：退出其他 VPN、代理客户端和网络加速工具，只保留一个 Clash 客户端。
- 第 3 分钟：开启规则模式，固定单个节点，连续测试 3 次延迟并记录波动。
- 第 4 分钟：用同一目标测试单连接与多连接下载，区分延迟问题和吞吐问题。
- 第 5 分钟：选择另一个地区、另一个入口的节点复测，不要只换同组相邻编号。
- 第 6 分钟：打开连接记录，确认目标域名命中的规则、策略组与实际节点。
- 第 7 分钟：核对应用代理端口与
mixed-port，清理旧客户端留下的代理设置。 - 第 8 分钟：分别测试系统代理和 TUN，观察是否只有 TUN 路径变慢。
- 第 9 分钟：检查 DNS 日志、IPv6 与 Fake-IP 排除项，关注首次连接是否长时间等待。
- 第 10 分钟：切换手机热点或有线网络复测，用不同接入网络判断运营商路径与 Wi-Fi 问题。
最终记录应至少包括测试日期、时间、接入网络、客户端核心、代理模式、节点、延迟、下载速度和规则命中。若白天稳定、晚间下降，优先处理线路；若所有节点都慢，优先处理本地网络和配置；若只有一个应用慢，优先检查该应用的代理方式、DNS 与连接协议。按照三层顺序保留对照数据，比反复更新订阅或随机切换节点更容易找到真正瓶颈。