第一层：先建立可重复的速度基线

Clash 显示的节点延迟、网页打开时间和下载速度是三种不同指标。延迟测试通常只测量一次 HTTP 请求或 TCP 连接的响应时间，能够反映节点是否可达，却不能直接代表持续吞吐量。一个延迟为 80 毫秒的节点可能带宽不足；另一个延迟为 180 毫秒的节点，也可能在大文件下载时保持更高速度。因此，排查开始时不要只盯着节点列表中的毫秒数。

先固定设备、网络和测试目标。关闭正在同步文件、更新系统、下载游戏或上传照片的程序，再选择一个稳定的网站和一个体积足够大的测试文件。每轮测试持续至少几十秒，并记录首屏加载时间、稳定下载速度以及是否出现中途停顿。短时间测速容易受到缓存、连接预热和服务端限速影响。

  1. 暂时关闭 Clash 的系统代理或 TUN 模式，测量当前网络的直连表现。
  2. 开启 Clash，固定一个节点和一种代理模式，使用相同目标重新测试。
  3. 更换同一地区的另一个节点，再执行一轮相同测试。
  4. 分别记录延迟、下载速度、上传速度、丢包现象和网页解析时间。

如果直连本身已经明显变慢，应先检查本地宽带、移动网络或 Wi-Fi，而不是立即修改 Clash 配置。如果只有代理连接慢，则继续定位节点、入口线路、出口线路和客户端设置。若仅某个网站慢，而其他代理流量正常，问题还可能位于目标网站、路由策略或该网站对出口地址的连接质量。

第二层：区分节点延迟、带宽与负载

节点是最常见的速度瓶颈，但“节点可用”只表示连接能够建立。节点的实际速度还取决于服务器带宽、同时在线负载、协议实现、运营商入口质量以及出口到目标网站的路由。高峰时段变慢、凌晨恢复，通常更接近负载或线路拥塞；全天稳定地慢，则需要检查节点限速、路径质量和设备处理能力。

不要把延迟测试当作完整测速

Clash 客户端常用一个测试地址计算节点延迟。该结果受测试地址、连接复用、DNS 缓存和超时设置影响。延迟低但吞吐量低，可能是节点带宽不足；延迟偶尔跳高，可能是链路抖动；大量节点同时显示超时，则应检查订阅、网络权限、DNS 或服务端状态，而不是逐个节点反复点击。

选择节点时，可以先按地区分组，再在同一地区比较至少三个节点。测试需要覆盖网页、小文件和持续下载。视频播放还要观察缓冲是否稳定，因为瞬时峰值很高并不等于长时间传输稳定。若客户端支持 URL Test、Fallback 或负载均衡策略组，也应理解它们的选择依据：URL Test 倾向选择测试响应较快的节点，Fallback 侧重故障切换，负载均衡则可能让不同连接经过不同节点。

检查策略组是否真的选中了目标节点

配置中常有多层策略组，例如应用规则先进入“国外网站”，该组再引用“自动选择”，最终才指向具体节点。界面上切换了某个组，不代表当前请求一定经过它。打开连接记录或日志，确认目标域名命中了哪条规则、进入哪个策略组、最终使用哪个节点。

目标域名 → 规则匹配 → 策略组 → 子策略组 → 具体节点

如果流量命中了 DIRECT，测速结果实际上是直连；如果命中了 REJECT，请求会被主动拒绝；如果命中了一个自动策略组，客户端可能在后台重新选择节点。排查期间可暂时固定策略组中的具体节点，避免自动切换干扰结果。完成测试后再恢复原有策略。

第三层：判断入口线路与出口线路是否拥塞

代理连接至少包含三段路径：设备到本地运营商、运营商到代理节点、代理节点到目标网站。任意一段都可能造成速度下降。节点距离较近，只能说明地理位置可能更接近，不能保证运营商之间的互联路径更短。不同宽带或移动网络访问同一节点时，表现可能完全不同。

最实用的判断方法是交叉测试。保持节点不变，将设备从家庭 Wi-Fi 切换到手机热点；或者保持网络不变，切换到另一个地区、另一个入口类型的节点。如果换网络后同一节点恢复，问题更可能位于本地运营商到节点的路径；如果换节点后恢复，则原节点的负载或路由更可疑。

  • 白天正常、晚间变慢：优先考虑高峰拥塞、共享带宽负载和运营商互联压力。
  • 网页快、下载慢：检查节点持续带宽、目标站限速和单连接性能。
  • 下载快、视频频繁缓冲：检查流媒体目标的出口路由、策略匹配和连接稳定性。
  • 首次打开慢、打开后正常：重点检查 DNS、TLS 建连和首次路由选择。
  • 速度周期性掉到零：检查丢包、无线干扰、节点重启、连接切换和设备休眠策略。

命令行中的 ping 只能提供有限参考。一些服务器会降低 ICMP 响应优先级，甚至完全不回应，但 TCP 和 UDP 业务仍能工作。路由跟踪可以帮助观察路径在哪一段发生明显变化，却不能仅凭某一跳不响应就判定故障。更可靠的结论来自多时段、多网络和多节点的对照结果。

第四层：检查 DNS 解析与连接等待

DNS 问题经常被误认为网速慢。典型表现是输入网址后长时间空白，但页面开始加载后速度正常；某些域名能打开，另一些域名持续超时；切换网络后立即恢复。此时瓶颈可能发生在域名解析阶段，而不是代理节点的数据传输阶段。

Clash 或 mihomo 配置可以接管 DNS，并根据运行模式使用普通 DNS、加密 DNS、Fake IP 或 Redir Host 等机制。不同客户端展示的开关名称可能不同，最终行为仍由内核配置和客户端生成的配置共同决定。修改前应先查看当前配置是否启用了 DNS、监听地址、默认解析器和上游服务器。

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  nameserver:
    - https://dns.example/dns-query

上面的片段只用于说明字段关系，示例地址不能直接视为可用服务。实际排查时，应使用能够稳定访问的解析器，并确认系统或路由器没有把 DNS 请求强制转发到其他位置。若上游加密 DNS 本身需要先解析域名，还要确保 bootstrap 或默认解析路径能够正常工作。

Fake IP 模式下的常见误判

Fake IP 会为域名返回保留地址，再由内核把该地址映射回原域名并执行规则匹配。这种方式有利于统一接管域名流量，但部分局域网设备、特殊应用或依赖真实地址的服务可能需要加入过滤列表。若只有打印机、路由器管理页、局域网存储或少量应用异常，应检查 fake-ip-filter 与局域网绕过规则，而不是直接认定节点变慢。

系统中还可能残留旧 DNS 缓存。切换配置后，可以重启相关应用，必要时清理系统 DNS 缓存，再重新测试。浏览器也可能启用自己的安全 DNS，使浏览器和其他程序使用不同解析路径。排查时应确认系统、浏览器和 Clash 分别由谁负责解析，避免多个组件同时改写 DNS。

第五层：对照系统代理、规则模式与 TUN 模式

系统代理通常通过操作系统的代理设置通知应用把 HTTP 或 HTTPS 请求交给 Clash。遵循系统代理的浏览器和桌面程序能够被接管，但部分游戏、命令行程序、商店应用以及自行实现网络栈的软件可能忽略该设置。TUN 模式则创建虚拟网络接口，在更低层接管更多 TCP、UDP 和 DNS 流量，覆盖范围更广，同时也更依赖权限、路由表和操作系统网络组件。

如果浏览器速度正常，而游戏、终端下载工具或特定应用很慢，先确认该应用是否进入代理。可以在 Clash 的连接列表中观察请求是否出现，并查看目标地址、协议、规则与最终节点。连接列表没有记录，通常意味着流量没有进入内核；有记录但使用 DIRECT，则说明规则选择了直连；有记录且经过节点，才适合继续分析节点和线路。

规则模式与全局模式的对照方法

规则模式根据域名、IP、进程或规则集决定 DIRECT、REJECT 或某个策略组。全局模式通常把大多数流量交给指定代理策略。排查某个网站时，可以短暂切换到全局模式进行对照：如果全局模式恢复，而规则模式很慢，应检查规则命中、策略组和 DNS；如果两种模式都慢，节点或线路更值得怀疑。

全局模式只适合临时定位，不应代替规则修复。测试结束后恢复规则模式，并在日志中找到造成差异的具体规则。还要留意配置底部的 MATCH 规则，因为没有被前面规则命中的请求最终会落到这里。

TUN 模式速度下降时检查什么

  • 确认客户端具备创建虚拟网卡和修改路由所需的系统权限。
  • 检查其他 VPN、虚拟机网卡、游戏加速工具和安全软件是否同时修改路由。
  • 确认 MTU 设置是否适合当前网络，过大的数据包可能触发分片或丢弃。
  • 观察 UDP 是否稳定；部分网络环境对 UDP 的限制会影响 QUIC、游戏和实时通信。
  • 比较关闭 TUN、仅启用系统代理后的速度，判断问题是否与虚拟接口有关。

部分浏览器会优先使用基于 UDP 的 HTTP/3。若线路对 UDP 支持不稳定，可能出现网页建立连接慢、视频抖动或测速结果波动。可以通过连接日志确认协议，再进行短时对照测试。不要一次性永久关闭多个网络特性；先确认哪个变化真正影响结果。

第六层：排除设备性能、无线网络与后台程序

代理内核需要执行加密、解密、规则匹配、DNS 处理和连接转发。现代桌面设备通常能够承担日常流量，但低功耗路由器、旧手机、资源受限的服务器或同时承载大量连接的设备，可能出现 CPU 占用接近上限的情况。此时更换节点未必改善速度，因为瓶颈位于本地处理能力。

测速期间打开任务管理器或系统监视工具，观察 Clash 客户端、内核进程、浏览器和安全软件的 CPU、内存、磁盘与网络占用。若速度下降时某个核心持续满载，可以减少不必要的复杂规则、关闭过量日志、减少并发连接，或在性能更充足的设备上进行对照。

Wi-Fi 也是常见变量。2.4 GHz 频段容易受到邻居网络、蓝牙设备和家用电器干扰；距离路由器较远时，设备可能不断重传数据。优先使用网线或稳定的 5 GHz、6 GHz 网络进行基线测试。如果有线正常、无线慢，应先调整信道、距离和路由器位置，而不是修改代理协议。

后台程序会占用上行带宽，上行饱和又会推高下载延迟。云盘同步、照片备份、视频会议和种子上传都可能造成这种情况。即使下载带宽仍有余量，排队延迟也会让网页和交互请求显得迟缓。暂停后台任务后等待一段时间，再执行相同测试。

配置规模与日志级别

大型规则集和频繁更新的订阅会增加载入时间，但正常配置不应让每个请求都产生明显延迟。如果客户端启动后长时间卡顿，检查规则集是否重复、配置是否多次引用同一资源，以及日志级别是否设置得过高。调试日志适合短时定位，持续记录大量连接信息会增加磁盘写入和界面渲染压力。

订阅更新后突然变慢，还要核对策略组名称和节点名称是否发生变化。客户端可能回退到策略组默认项，自动测试也可能选择了另一个节点。更新前后分别查看最终配置与当前选中项，比反复导入订阅更容易发现差异。

按顺序执行的十分钟排查流程

速度问题适合从外到内逐层缩小范围。以下流程不要求立即修改 YAML，先通过对照确定问题属于哪一层，再处理对应设置。

  1. 测直连：关闭代理后测试当前网络，确认基础网络没有明显异常。
  2. 固定节点：关闭自动选择，指定一个节点并记录延迟和持续下载速度。
  3. 更换节点：选择同地区与不同地区节点各一个，比较高峰和非高峰表现。
  4. 查看连接：确认目标请求进入 Clash，并记录命中规则、策略组和最终节点。
  5. 切换网络：用手机热点或另一条宽带测试同一节点，判断入口线路问题。
  6. 检查 DNS：观察慢在解析阶段还是传输阶段，核对系统与客户端解析路径。
  7. 对照模式：比较规则模式与全局模式、系统代理与 TUN 模式的结果。
  8. 检查资源：观察 CPU、内存、无线信号和后台上传是否成为瓶颈。
  9. 重载配置：确认配置解析成功，策略组选择和订阅更新结果符合预期。
  10. 恢复设置：撤销仅用于测试的全局模式、调试日志和临时 DNS 改动。

最终记录应包含测试时间、网络类型、客户端版本、内核类型、代理模式、节点名称、目标网站和速度结果。若需要向节点服务方或客户端项目提交问题，这些信息比“感觉很慢”更有诊断价值。涉及配置内容时，应先移除订阅地址、认证信息、节点凭据和个人网络信息。

排查结论：先定位慢在哪一段

Clash 速度慢并不等同于节点延迟高。完整连接由本地网络、DNS、规则匹配、代理入口、节点处理、出口路由和目标网站共同组成。先测直连基线，再固定节点，随后用换网络、换节点、换模式的方式逐层对照，通常能够快速区分节点负载、运营商线路、DNS 等待和设备瓶颈。

如果所有节点在同一网络下都慢，而切换网络后恢复，优先处理本地网络与运营商路径；如果只有少数节点慢，重点检查节点负载和出口线路；如果网页首次打开慢但下载稳定，检查 DNS；如果只有特定应用异常，确认系统代理或 TUN 是否真正接管流量。按层记录、单项修改、完成后恢复临时设置，能够避免把一个简单问题扩大成多项配置冲突。

选择对应平台安装包

进入下载中心核对操作系统与架构，再按使用文档完成安装、订阅导入和基础连接检查。

去下载页 看教程