Clash 常见问题

Clash 是代理内核及其配置生态的常用名称，mihomo 是这一生态中持续发展的内核项目。Clash Verge Rev、FlClash 等客户端提供图形界面，负责配置导入、系统代理和内核进程管理；真正解析规则、建立连接的是内核。排查时先在「关于」或「内核」页分别记录客户端名称与内核版本。相似的界面不代表支持相同配置，尤其是 TUN、DNS 和协议字段。下载时应按设备系统选择客户端，修改配置前再确认当前运行的内核，而不是只看安装包名称。

需要可用的代理配置。客户端负责读取配置和转发请求，安装本身不会生成可用的远程代理服务。通常从已有服务的账户页面获取 Clash 或 mihomo 格式订阅，再到「配置」页导入；也可以导入自行维护的 YAML 文件。导入后检查配置是否被选中、代理页是否出现策略组，以及所选组是否有可用出口。订阅地址常包含账户标识，应按敏感信息保管，分享截图时遮住完整地址。不要把来源不明的配置直接用于重要账户，也不要把单条节点链接误当作完整配置文件。

日常先用「规则」，让请求按 rules 自上而下匹配并交给对应策略组。「全局」让进入内核的请求统一交给全局策略组，适合临时验证规则是否导致异常，但仍需在该组选择有效出口。「直连」让进入内核的请求直接连接，适合对照测试。模式只决定内核收到请求后的处理方式，不能替代系统代理或 TUN，也不会自动接管所有应用。切到全局仍打不开网页时，先查请求是否进入日志，再查出口连接；不要连续切换模式后同时修改 DNS，否则难以判断哪项设置起作用。

系统代理通过操作系统的代理设置，引导遵循该设置的应用连接本地监听端口；TUN 使用虚拟网络接口接收被路由到其中的 IP 流量，更适合不遵循系统代理的程序。两者都不等于所有流量必然经过代理，实际结果还受路由、应用行为和规则影响。首次配置先只开系统代理，确认浏览器可用后，再按需要启用 TUN，并遵循客户端对组合开关的建议。不要为了排错一次开启多个代理客户端、VPN 和虚拟网卡接管功能。先保留一条明确的接管路径，比叠加开关更容易定位问题。

在「配置」页选择「从 URL 导入」或「新建订阅」，粘贴服务提供的 Clash 格式地址并保存，等待下载完成后点击该配置使其成为当前配置。随后到「代理」页确认策略组已加载，再在「日志」页查看是否有解析错误。列表里出现一个文件，只能说明配置已保存，不代表已经启用。若出现 yaml: unmarshal errors，先核对订阅格式与内核兼容性，不要直接删除陌生字段。最后开启系统代理，访问目标网站并观察连接记录；记录中的规则、策略组和出口，才是判断实际生效情况的依据。

先查系统的处理器架构，再选安装包。Windows 可在「设置 → 系统 → 系统信息」查看系统类型；macOS 在「关于本机」查看芯片，Apple Silicon 通常选 ARM64，Intel 机型选 x64。Android 多数较新设备使用 arm64-v8a，但仍应以设备和安装包支持范围为准；Linux 可运行 uname -m，x86_64 通常对应 AMD64，aarch64 通常对应 ARM64。架构匹配后还要确认最低系统要求。遇到无法安装或无法启动，保留错误原文，先排除架构与系统版本不符，不要反复更换订阅来处理安装阶段的问题。

「开机自启」通常只表示启动客户端，不保证内核、系统代理和 TUN 都恢复。先注销并重新登录，检查托盘图标是否出现，再看内核状态、当前配置和接管开关。Windows 还要检查「启动应用」是否禁用该程序；使用 TUN 时确认客户端所需的服务已安装并能启动。不要把管理员权限启动项与普通用户启动项重复配置。若只是刚登录时订阅更新失败，可等网络就绪后手动更新，或使用客户端提供的延迟启动选项。逐项验证启动过程，不要只凭任务管理器里存在一个进程就判断连接已经恢复。

先确认提示来自服务安装、虚拟接口创建，还是网络扩展授权。Windows 客户端若提供「服务模式」或「安装服务」，按其提示授权安装，再重新开启 TUN；不要长期靠重复提权启动掩盖服务故障。macOS 根据实际弹窗在系统设置中允许对应网络扩展或 VPN 配置，不同客户端实现可能不同。Linux 通常需要访问 /dev/net/tun，并具备相应网络管理权限，应采用项目推荐的服务配置。授权后查看日志是否成功创建接口。若随后仍无法联网，应继续查路由和 DNS，而不是反复授予与网络无关的磁盘权限。

延迟测试主要反映测试地址的连通性和响应时间，不代表持续带宽，也不保证目标网站使用同一路径。先固定一个出口和同一个下载地址，查看连接记录，确认实际请求没有被规则送往其他策略组。再对比直连与代理、不同出口和不同时段，区分本地网络、远端线路及目标站限速。测试时暂停其他设备的大量传输，避免同时测速和下载造成竞争。若只有某个应用慢，检查该应用的代理设置及并发连接限制。不要仅按延迟最小值选节点，也不要把一次测速结果当作长期速度承诺。

先在「连接」页查看该请求命中的规则与策略组，确认修改的是实际使用的组，而不是名称相近的另一个组。select 组允许手动选择，url-test 等自动组则可能根据检测结果重新选择；嵌套组还需要沿选择链逐层检查。已有长连接通常不会因为改选节点立即迁移，应先关闭对应连接或重启发起请求的应用，再建立新连接验证。订阅更新也可能改变组结构或恢复选择，具体取决于客户端是否保存选择状态。排查时只改一个组，记录新连接的出口，不要用仍在复用的旧页面连接判断切换是否成功。

mixed-port 是接收 HTTP 与 SOCKS 代理请求的混合监听端口，应用的手动代理设置应指向它；external-controller 是管理内核的 API 地址，不能当作上网代理端口。7890 和 127.0.0.1:9090 是常见示例值，实际值以当前客户端为准。若日志出现 bind: address already in use，先退出其他代理程序，再检查端口占用；修改 mixed-port 后也要同步更新应用中的手动代理。管理接口优先绑定回环地址，确需开放时再配置访问控制。不要为了让本机应用连接成功，就直接把管理接口暴露到局域网或公网。

先确认受影响的是采用应用容器隔离的 UWP 应用，而不是所有 Windows 程序。部分应用默认不能访问本机回环代理，可能出现浏览器正常、商店应用失败的情况。客户端若提供「UWP 回环豁免」，以所需权限打开工具，仅为需要的应用启用豁免，再重启该应用测试。豁免只是允许访问回环地址，不会自动配置代理，也不能修复无效节点。没有相关工具时，可按微软文档使用 CheckNetIsolation 管理指定应用的回环豁免，不要直接对全部应用批量放开。仍失败时检查该应用是否遵循系统代理，以及连接日志是否收到请求。

先区分 HTTP 错误与网络错误。401、403 常与地址失效、访问限制或账户状态有关，应回到账户页面确认服务状态，并重新复制完整的 Clash 订阅地址；404 则先检查路径是否复制完整。若返回的是 HTML 登录页，而不是 YAML 配置，也会导致导入解析失败。i/o timeout 则应检查当前网络和订阅域名的可达性。客户端若允许选择更新时是否经过代理，可分别测试直连和一个已确认可用的代理出口，避免订阅依赖尚未更新成功的配置。分享错误时只保留状态码与域名，删除地址中的账户标识和查询参数。

先看完整错误，不要把 dial tcp 本身当作原因，它只是建立 TCP 连接的上下文。后接 i/o timeout 通常表示连接未在期限内完成；connection refused 更偏向目标端口未监听或被明确拒绝；no such host 则先查域名解析。确认订阅仍有效、节点地址和端口已更新，再换一个出口对照，并临时关闭其他 VPN 避免路由冲突。所有节点同时失败时，优先查本地网络、DNS 与客户端接管状态；只有一个节点失败时，再联系对应服务方。不要通过无限增加超时时间或关闭防火墙整体防护来代替定位。

先打开「连接」页刷新目标网站。如果完全没有新请求，问题更可能在流量接管，而不是分流规则。检查操作系统中的代理地址与端口是否对应当前 mixed-port，再检查浏览器是否使用自己的代理扩展或独立网络设置；Firefox 等应用可能不直接沿用系统设置。退出其他代理客户端，防止它们覆盖系统代理。若请求已进入内核却显示 DIRECT，应检查命中的规则与模式，而不是继续重开系统代理。退出客户端前先关闭系统代理；如果关闭程序后全网断开，回到系统代理设置移除仍指向本机端口的手动代理。

先区分节点域名解析失败与目标网站解析失败，日志中的域名能帮助定位。记录当前 dns 配置，只调整一个环节：确认所用解析器可达、解析器域名本身能完成引导解析，并检查 DNS 请求是否被其他 VPN 或安全软件接管。使用 fake-ip 时，还要确认虚拟地址流量能被正确接管；仅清空缓存不能修复错误路由。浏览器开启独立的安全 DNS 时，可临时改为跟随系统做对照测试。修正配置后再清理系统与应用缓存并重建连接。不要从多份教程拼接整段 DNS 配置，尤其不要混用不受当前内核支持的字段。