故障排查 预计阅读 12 分钟

Clash 在 Mac 上网速慢：节点、线路、本地设置三层定位

按节点质量、出口线路、本机设置三层逐级排查，覆盖 DNS 模式、TUN 栈选择与 Wi-Fi 省电干扰，快速锁定 macOS 上的瓶颈。

排查起点：区分打开慢、下载慢与间歇断流

Clash 显示的节点延迟，不等于文件下载速度。打开网页需要经过域名解析、连接建立、TLS 握手和内容传输；其中任何一段等待，都可能表现为“网速慢”。先确定症状，再按节点、线路、本机设置依次缩小范围，比同时修改 DNS、规则和 TUN 更容易得到结论。

可见症状优先检查对照方法
首次打开停顿，随后加载正常DNS、连接与 TLS 阶段比较同一地址首次与重复请求的耗时
页面能开，大文件持续低速节点带宽、出口拥塞、目标限速固定文件，切换两个不同出口节点
每隔一段时间卡顿自动策略切换、网络漫游、资源占用固定节点，记录卡顿时刻和连接日志
浏览器正常，终端很慢或失败终端是否使用代理用显式代理参数测试同一地址
只有启用 TUN 后变慢路由、DNS 接管、其他网络扩展关闭 TUN，仅保留显式 HTTP 代理对照

建立一次可重复的测试

  1. 暂停云盘同步、系统更新和其他下载，保留同一台 Mac、同一个网络、同一个目标文件。
  2. 将目标请求实际使用的策略组改为手动选择，固定一个节点，避免测试期间自动切换。
  3. 每组测试连续执行 3 次，记录时间、节点、网络类型、代理方式和结果。首轮可能受到缓存影响，应单独标记。
  4. 每次只改一个变量。测试结束恢复原配置，确认结果是否能够重复。

第一层：节点质量与实际代理出口

先打开客户端的连接列表，找到正在访问的域名，查看命中的规则、策略组和最终节点。界面中选中了某个节点，不代表每个请求都会经过它：规则可能指向另一个策略组，也可能命中 DIRECT。客户端界面的名称和入口各不相同，应以当前客户端提供的连接详情为准。

固定节点，排除自动切换

url-test 会按照配置的探测结果选择节点，fallback 侧重按顺序选择可用节点，load-balance 则按策略分配连接。排查时先使用手动选择组，让测试请求保持相同出口。切换节点通常不会把已经建立的长连接迁移到新节点，因此应重新发起请求；必要时只关闭目标应用对应的旧连接。

  • 只有一个节点慢：优先考虑该节点负载、带宽限制或其上游路径，换节点复测。
  • 同一地区多个节点都慢：继续比较不同地区、不同入口或不同供应路径，不能只按节点名称判断线路独立性。
  • 全部节点只对某个网站慢：检查目标站点限速、CDN 分配、账号状态和出口 IP 的访问限制。

区分延迟与吞吐量

低延迟有利于交互，但持续下载还取决于拥塞、丢包、可用带宽和远端服务能力。一个延迟更低的节点，下载大文件仍可能更慢。测试时使用同一个合法可访问的文件源，不要把不同站点的下载结果直接比较，也不要用只有几 KB 的网页判断带宽上限。

同时留意单位：下载工具中的 MB/s 与宽带标称的 Mbps 不同。按十进制单位换算，10 MB/s 约为 80 Mbps，实际应用还会受到协议开销影响。这是单位换算，不是节点速度承诺。

第二层：本地网络到节点、节点到目标的线路

代理连接至少包含两段路径：Mac 到代理入口，以及代理出口到目标服务。切换节点会同时改变其中的一部分，因此还需要更换本地接入网络做交叉验证。保持节点和目标不变，用手机热点进行短时对照；如果热点明显改善，问题更可能位于原来的 Wi-Fi、路由器或接入运营商路径。

用 curl 确认请求确实经过代理

终端工具不一定读取 macOS 系统代理。下面命令显式指定本机 HTTP 或混合端口，并输出阶段计时。示例使用 127.0.0.1:7890，执行前先核对客户端当前监听端口。输入地址应为允许下载、大小适中的 HTTPS 文件地址；签名链接和订阅链接不要粘贴到公开日志中。

printf '请输入测试文件的 HTTPS 地址：'
read -r TEST_URL
curl --proxy http://127.0.0.1:7890 --noproxy "" \
  --location --output /dev/null --silent --show-error \
  --connect-timeout 10 --max-time 60 \
  --write-out 'status=%{http_code}\nconnect=%{time_connect}s\ntls=%{time_appconnect}s\nfirst_byte=%{time_starttransfer}s\ntotal=%{time_total}s\nbytes=%{size_download}\nspeed=%{speed_download} B/s\n' \
  "$TEST_URL"

speed_download 的单位是字节每秒。time_starttransfer 是从请求开始到收到首字节的累计时间，并非单独的服务器处理时间。通过本地 HTTP 代理访问 HTTPS 时，time_connect 主要反映连上本地代理的时间，不能把它当作到远端节点的延迟；后续代理隧道和 TLS 阶段还包含远端路径的影响。

若目标本身允许直连，可以把代理选项替换为 --proxy "" --noproxy "*" 再做一轮对照。不过，这只绕过 curl 的显式代理；启用 TUN 时，请求仍可能被路由接管。需要真正比较直连时，应先关闭 TUN，并确认其他 VPN 没有接管该流量。

按时间窗口判断拥塞

同一节点在白天正常、晚间持续变慢，且有线连接与 Wi-Fi 表现接近，通常更值得检查共享链路拥塞。分别记录两个时间窗口的 3 次结果，比一次测速更有参考价值。对代理服务器执行 ping 只能提供有限线索：服务器可能限制 ICMP，ICMP 的路径和优先级也不一定代表实际代理连接。

第三层：系统代理、规则与本机负载

在较新的 macOS 中，可从「系统设置」→「网络」→ 当前网络服务 →「详细信息」→「代理」查看 HTTP、HTTPS 和 SOCKS 设置。不同系统版本的文字可能略有差异。先确认代理地址为本机监听地址，端口与客户端一致，再检查是否残留旧客户端的设置。

networksetup -listallnetworkservices
networksetup -getwebproxy "Wi-Fi"
networksetup -getsecurewebproxy "Wi-Fi"
scutil --proxy

如果网络服务被重命名，或当前使用的是 USB 以太网，应把命令中的 Wi-Fi 换成第一条命令列出的实际服务名称。检查输出中的启用状态、服务器地址和端口，不要仅凭客户端开关的颜色判断系统设置是否已经写入。

检查重复代理与规则误命中

  • 浏览器代理扩展可能覆盖系统代理。测试时先停用扩展，或明确记录扩展使用的出口。
  • 同时运行两个带 TUN、VPN 或流量过滤能力的工具，可能造成路由冲突。一次只保留一套接管方式进行验证。
  • 如果只有特定域名慢，在连接列表核对它是否误入远端代理，或本应代理却被直连规则截获。
  • 打开「活动监视器」，观察 CPU 与网络。若客户端或其他进程持续占用资源，先停止后台重任务，再复测相同请求。

Clash 是内核与客户端生态中的名称，并非所有图形客户端都有相同的覆写、日志或服务模式。使用 mihomo 的客户端也可能采用不同的权限管理和配置合并方式。修改前应查看实际生效配置，而不只是订阅文件中原始的 YAML。字段含义可结合YAML 手册查阅。

DNS 模式：定位首次打开慢与解析异常

DNS 问题常表现为首次打开慢、部分域名失败，或浏览器与命令行结果不一致。mihomo 的 fake-ip 模式会为域名分配映射地址，redir-host 模式则使用真实解析结果。两者不是简单的“快”和“慢”：适配性取决于应用、路由接管方式与 DNS 配置。

先确认解析走哪条路径

  1. 执行 scutil --dns，查看系统当前解析器及其作用域。VPN 和不同网络接口可能各自提供解析器。
  2. 核对浏览器是否启用了独立的安全 DNS。浏览器解析正常，不代表系统解析和客户端内置 DNS 同样正常。
  3. 在客户端日志中检查解析超时、上游不可达或重复重试。若上游 DNS 自身依赖尚未建立的代理，可能出现启动依赖问题。
  4. 仅对一个受影响域名做重复测试，再比较切换网络前后的结果，不要同时更换所有上游和模式。

使用 HTTP 代理访问 HTTPS 时，目标域名通常可交给代理端处理，因此 curl 的本地解析耗时不能直接说明目标域名的 DNS 性能。类似地，dig 默认测试的解析路径也未必等同于浏览器、系统解析 API 或 mihomo 的内部解析路径。

TUN 栈与 Wi-Fi 省电：按单变量验证

TUN 栈选择与路由检查

TUN 通过虚拟网络接口接管 IP 流量；它不直接增加节点带宽。mihomo 提供的栈选项包括 system、gvisor 和 mixed，具体可用性和默认值以客户端所带内核及其文档为准。不同栈会影响协议处理方式、兼容性和资源开销，没有适用于所有 Mac 的固定最优项。

先记录当前栈，然后只切换栈选项，按客户端要求重新启用 TUN 或重启内核，复测同一个请求。下面仅展示要比较的字段，不是一份完整配置；不要用它覆盖已有的 TUN、DNS、路由或权限设置。

tun:
  enable: true
  stack: system

如果显式 HTTP 代理正常、TUN 下异常，应重点检查路由循环、DNS 接管和其他网络扩展。不要一开始就随意调整 MTU。只有出现特定目标的大包传输停滞、握手后卡住等证据时，再按内核文档做单项对照。开启自动路由前也应确认局域网设备和工作 VPN 的访问需求。

区分 Wi-Fi 干扰与低电量模式

Mac 的低电量模式不是“代理限速开关”，不能据此认定 Clash 下载慢。它可作为测试变量：在「系统设置」→「电池」中查看低电量模式，接通电源，在相同位置、同一节点下分别记录结果。选项名称和可用范围会因机型、系统而异，不能通过一次变化就认定因果。

  • 按住 Option 点击菜单栏 Wi-Fi 图标，可查看系统提供的信号、噪声和传输速率信息；这些是无线链路指标，不等于互联网下载速度。
  • 靠近路由器复测，并在条件允许时比较有线连接。若有线正常而 Wi-Fi 异常，优先处理信号、干扰和漫游。
  • 分别测试 5 GHz 与 2.4 GHz 网络。前者不一定在隔墙较多时更稳定，应以当前位置的重复结果判断。
  • 若睡眠唤醒后才变慢，重新连接 Wi-Fi，再检查客户端的代理与 TUN 状态；不要长期靠反复重装来掩盖问题。

结果归类与配置恢复

排查的终点应是一条可以复现的结论，而不是“调过很多设置”。例如：“固定同一节点和文件时，有线正常、Wi-Fi 持续低速”，足以把重点转向无线网络；“关闭 TUN 后显式代理正常”，则把范围缩小到本机接管链路。结论越具体，后续处理越少依赖猜测。

  1. 节点问题：更换出口，并向服务提供方提交时间、节点和目标信息，隐藏账号、订阅地址及认证参数。
  2. 线路问题：保留不同接入网络与不同时段的对照结果，区分本地接入拥塞和出口到目标的异常。
  3. 本机问题：只保留已经验证有效的修改，恢复临时更改的栈、DNS、策略组与省电设置。
  4. 仍无法定位：提供客户端名称、内核类型、macOS 环境、代理方式和脱敏日志，避免仅提交一张延迟截图。

更换客户端可以帮助验证 GUI 配置或权限差异，但不会自动改变订阅节点的容量。先确认瓶颈所在，再决定调整规则、修复本地设置，还是更换出口线路。

下载Clash