Clash 网速慢排查

先区分：打开慢、下载慢，还是连接中断

FlClash 使用 Clash Meta（mihomo）内核处理代理连接。一次网页访问可能经过域名解析、规则匹配、节点连接、远端请求和内容传输。任何一段变慢，都可能表现为“Clash 网速慢”，但对应的处理方法不同。先记录症状，再改设置，能避免把线路问题误判成 DNS 问题。

先暂停云盘同步、系统更新和其他下载。固定一台设备、一个网络、一个目标文件，保持测试条件一致。家用宽带标注通常是 Mbps，下载工具可能显示 MB/s；100 Mbps 的理论换算约为 12.5 MB/s，实际应用吞吐还会受协议开销、无线信号和远端限制影响，不能直接把两个数字比较。

节点层：固定策略组，做同目标对照

延迟测试低，不代表下载一定快。客户端的延迟检测通常测量到指定地址的一次请求耗时，它受测试地址、缓存和连接建立过程影响，不能直接代表持续带宽。一个显示 60 ms 的节点可能拥挤，一个显示 160 ms 的节点也可能保持较高下载速度。

按 A → B → A 的顺序测试

1. 打开策略组，临时手动选择节点 A。若使用自动选择或故障转移组，先确认测试期间不会自动切换出站。
2. 访问同一个目标，下载同一个允许测试的文件。每轮观察约 30 秒，分别记录开始等待时间和稳定后的速率。
3. 切换到节点 B，关闭测试页或停止下载后重新发起连接，再重复一次。最后切回 A，检查第一次低速是否只是偶发。
4. 在 FlClash 的连接记录中核对域名、规则和出站链。已有长连接可能继续使用原节点，切换策略组不会把所有旧连接即时迁移。

例如，记录中 A 两轮均约为 1.2 MB/s，B 为 8 MB/s，只能先判断“在这个目标和时段下，B 的路径表现更好”。这些是示例读数，不是本站实测结果。A 的出口到该站点绕路、远端按出口限速、节点共享带宽不足，都可能形成相同现象；还应换第二个目标确认。

规则模式下，同一网页的主文档、图片和视频可能使用不同策略组。不要只看页面右上角选中的节点。可短暂用全局模式与规则模式对照，但必须确认全局策略组实际选中了同一个节点。若全局正常而规则模式慢，重点检查慢请求是否走了直连、其他节点或不合适的规则顺序。规则匹配细节可结合进阶配置中的规则说明核对。

线路层：比较时间、网络和目标站

多个节点一起慢，也不一定是本机配置出错。节点可能共享入口、出口或上游链路；名称不同并不代表网络路径独立。需要加入第二种网络或另一个时段，才能缩小故障范围。

• 时间对照：使用同一节点和目标，在 10:00、20:00、23:00 各测一组。若只有晚间持续下降，记录连续两三天的趋势，再判断是否存在高峰拥堵。
• 接入对照：同一台电脑从家庭 Wi-Fi 切到手机热点。注意流量费用，使用短时测试即可。热点恢复而宽带持续低速，优先检查本地路由器、宽带接入和相关互联路径。
• 目标对照：至少测试两个不同站点的合法下载资源。只有某一站点慢，可能与该站的 CDN 调度、账户限速或出口地址有关。
• 局域网对照：有条件时改用网线或靠近路由器测试。若直连和代理下载都慢，先排查无线干扰与本地带宽占用。

Ping 丢包只能作为线索。路由器可能对 ICMP 限速，中间跳不响应也不等于实际业务中断。代理协议、UDP 转发和普通 Ping 还可能走不同路径。不要依据某一跳出现星号就更改整个配置，应结合真实下载是否停顿、连接日志是否重试来判断。

本机层：系统代理与其他网络工具

系统代理通常只影响愿意读取该设置的应用，并不接管全部流量。TUN 模式则通过虚拟网卡与路由接管符合条件的 IP 流量。浏览器能访问，不等于游戏或命令行已经走代理；反过来，终端里的代理环境变量也可能把请求送到旧客户端端口。

先建立一条可核对的代理路径

1. 暂停其他代理客户端与非必要 VPN，记录它们原先的状态。企业设备不要擅自关闭组织要求的安全组件，应先确认管理策略。
2. 在 FlClash 当前运行配置中确认实际监听端口，不要把示例端口当成固定默认值。检查浏览器扩展是否另外指定了代理。
3. Windows 可在「设置」→「网络和 Internet」→「代理」核对系统代理；macOS 可在「系统设置」→「网络」→当前网络→「详细信息」→「代理」检查。系统版本不同，名称可能略有变化。
4. 关闭 TUN，仅保留系统代理，用一个明确支持系统代理的浏览器复测。随后关闭系统代理，再单独测试 TUN，避免两套入口同时变化。

以本机 HTTP 或 mixed 监听端口确实为 7890 为例，下面的命令能让这一次请求明确使用该入口。Windows PowerShell 中可使用 curl.exe，macOS 与 Linux 通常使用 curl。端口不同必须先修改命令；目标地址只用于观察请求阶段，不是带宽测速资源。

curl --proxy http://127.0.0.1:7890 --output /dev/null --silent --show-error --write-out "connect=%{time_connect}s first_byte=%{time_starttransfer}s total=%{time_total}s\n" https://example.com/

Windows 使用时将 /dev/null 改为 NUL。通过本地 HTTP 代理访问 HTTPS 时，time_connect 主要反映连接本地代理入口，不能当成远端节点延迟；首字节时间则包含代理隧道建立、TLS 和远端响应等多个阶段。此命令适合比较前后变化，不适合凭单个数字断定是 DNS 故障。

TUN 层：先看接管与资源，再换栈

如果系统代理速度正常，只有 TUN 模式明显慢，先确认虚拟网卡已成功创建，且内核具备所需权限。Windows、macOS 与 Linux 的权限与服务机制不同；Android 则使用系统 VPN 授权，同一用户空间中的其他 VPN 通常不能与其同时工作。

建议按这个顺序检查

• 看实际连接：应用发出请求后，确认 FlClash 中能看到对应连接。没有记录时，先查路由接管与应用绕过设置，而不是先换节点。
• 看 CPU：观察下载过程中内核进程的 CPU 占用。如果某个核心持续繁忙，同时吞吐到达固定上限，才有必要调查设备性能和数据处理开销。
• 换 TUN 栈：mihomo 常见栈选项包括 system、gvisor、mixed，具体可用项取决于平台、内核和客户端版本。一次只换一个选项，按界面要求重新启用 TUN 后复测；不存在所有平台都最快的固定答案。
• 最后查 MTU：若小请求正常、大下载停顿，或特定网络下 TLS 连接反复卡住，再调查路径 MTU。不要把修改 MTU 当成通用提速步骤。

确有 MTU 相关证据时，可以在配置支持的前提下，以 1400 作为一次诊断性对照值，记录原值后测试，未改善便恢复。降低 MTU 会增加单位数据的包数量，不保证带宽更高。涉及服务模式、虚拟网卡和路由修改时，可先阅读TUN 配置说明，避免留下影响其他网络的设置。

DNS 层：解析耗时不等于传输带宽

DNS 更常影响第一次打开网站、连接建立与地址选择。连接已经建立后，持续大文件下载仍然很慢，通常不能仅靠更换 DNS 解决。判断 DNS 是否相关，应观察首次请求与重复请求的差别，并结合日志中的超时、解析失败和实际目的地址。

Fake-IP 与 real-ip 该怎样判断

fake-ip 会向应用返回用于映射的虚拟地址，再由内核关联域名处理连接；redir-host 则使用真实解析地址。看到 198.18.0.0/16 范围内的地址并不自动代表异常，实际使用范围应以运行配置为准。不要因为地址看起来陌生就切换模式，也不要把两种模式简单等同为“快”和“慢”。

1. 查看当前生效的 DNS 配置，而不只查看订阅原文。客户端覆写、补丁或配置合并可能改变最终的 dns 段。
2. 核对浏览器是否启用了独立的安全 DNS。浏览器通过自己的 DoH 请求解析时，系统 DNS 测试不一定反映浏览器实际路径。
3. 检查加密 DNS 上游本身是否可达，以及 DNS 服务器域名的初始解析是否依赖不可用的链路。配置不当可能形成解析依赖或持续等待。
4. 修改解析设置后，按客户端能力清理 DNS 缓存，并重启测试应用。只刷新网页可能仍然复用连接或应用缓存。

不要直接复制陌生的 DNS 列表覆盖全部配置。更换解析器可能改变 CDN 地址与 IPv4、IPv6 选择，短时间变快并不能证明解析器本身更快。若日志显示 IPv6 连接反复失败，而 IPv4 稳定，应单独测试 IPv6 路径；暂时调整相关设置可以验证假设，但长期方案仍是修复路由或按实际网络条件配置地址族。

形成记录：把结论落到一层

排查结束时，应能用一句话描述复现条件，例如：“家庭宽带晚间使用节点 A，两个目标都低速；手机热点相同设置正常。”这比“所有节点都不行”更有价值。向订阅服务提供方或客户端项目反馈时，附上经过脱敏的时间段、系统版本、FlClash 与内核版本，以及对照步骤即可。

日志只截取复现前后必要的几十秒。订阅地址、节点密码、认证令牌和私人访问域名应先移除。完整订阅链接往往包含访问凭据，不能作为公开排查材料。测试完成后恢复临时更改的模式、策略组与系统代理状态，保留确认有效的调整。

如果客户端能稳定复现问题，再考虑更新到项目正式发布的版本，并保存更新前后的版本信息与测试结果。更新不是替代定位的第一步；同一节点、同一目标、单一变量的对照，才是判断改善来自哪里的依据。订阅导入或出站模式尚未确认时，可先按配置教程建立可用基线，再继续测速。