Clash 常见问题

Clash Meta 是 Clash 衍生内核的历史名称，该项目后来更名为 mihomo。内核负责协议连接、规则匹配与 DNS 处理；图形客户端负责订阅导入、策略组选择、系统代理开关等操作界面。同样使用 mihomo 的客户端，菜单位置和配置覆盖方式也可能不同。排查问题时应同时记录客户端名称与内核版本，不要仅凭窗口上的 Clash 字样判断支持能力。更换客户端前，先导出配置并记录自定义设置，再核对新客户端的内核说明。

客户端是运行配置的工具，安装完成并不代表已经具备可用的远程代理服务。通常需要导入有权使用的订阅链接，或加载包含出站、策略组与规则的本地配置。订阅的有效期、用量限制和服务器状态由对应服务提供方管理，不能通过重装客户端重置。首次使用时先确认配置来源，再检查是否成功生成策略组；如果只有直连选项，应检查配置内容与导入日志，而不是反复切换系统代理。订阅地址可能包含访问凭据，不要公开分享。

订阅链接是获取远程内容的入口；Profile 通常指客户端中保存的一份配置记录；YAML 是常见的配置文件格式。订阅返回的内容可能是完整的 Clash 配置，也可能只是节点列表，后者需要客户端支持相应导入方式或通过可信工具转换。导入成功后，应确认策略组、规则与 DNS 设置是否齐全。远程更新通常会替换订阅生成的内容，因此长期保留的自定义规则宜放入客户端提供的覆写或合并配置中，避免直接修改更新时会被覆盖的文件。

规则模式根据配置中的规则为连接选择出站，适合日常按目标分流。全局模式把交给内核处理的连接统一交给全局策略，适合临时对照测试，但不等于接管设备上所有应用。直连模式通常让内核处理的连接直接访问目标，适合排除代理出站问题。三种模式都以流量确实进入内核为前提；应用绕过系统代理时，切换模式可能没有效果。修改后应新建连接并查看连接记录，已有长连接可能仍使用原先的出站。

先选操作系统，再确认处理器架构与安装格式。Windows 可在系统的关于页面查看系统类型；macOS 可在关于本机中区分 Apple 芯片与 Intel；Linux 可通过 uname -m 查看架构，再按发行版选择软件包。Android 优先查看设备与客户端的架构要求，不应把桌面安装包或内核压缩包当作手机应用。安装失败时记录系统版本和完整提示，先排除架构不匹配、系统版本过低与旧安装冲突，不要连续尝试来源不明的修改包。

在配置或 Profiles 页面粘贴完整订阅地址，执行导入后，确认对应记录已被选为当前配置。有些客户端将下载配置与启用配置分为两个操作，列表中出现记录并不表示内核已经加载。随后检查策略组是否显示预期选项，并在日志中确认没有 YAML 解析错误或不支持的字段。若导入的是本地文件，保留原文件副本，并核对外部规则集与代理集合是否能够获取。最后选择一个可用出站，建立新的访问连接，再查看命中的规则与策略。

TUN 模式需要创建虚拟网络接口并调整路由，通常比系统代理需要更高权限。Windows 先检查客户端服务模式是否安装并运行，再按提示完成权限授权；macOS 检查系统网络扩展或辅助服务的授权；Linux 按客户端文档确认 TUN 设备与所需权限。Android 和 iOS 通常需要批准 VPN 配置。不要仅为排错长期关闭系统安全机制。若仍失败，先退出其他 VPN 或网络接管工具，再查看具体接口、路由或权限报错；共享日志前移除订阅地址与凭据。

iOS 客户端通常通过系统网络扩展承载流量，因此首次连接时会申请添加 VPN 配置。先确认授权提示来自刚安装的客户端，再按系统流程批准，之后回到应用导入配置并启动连接。系统显示 VPN 标识只能说明隧道已启用，不能证明所选远程出站可用，仍需结合客户端记录验证。若设备由组织管理，相关权限可能受到策略限制，应联系设备管理员。使用 Clash Plus 时可从下载页进入 App Store，产品信息可在 clashplus.io 查看。

手动选择组由用户固定选择一个出站；自动测试组通常根据指定测试地址的探测结果挑选出站；故障转移组则按配置顺序与可用性处理。测试结果只代表当时访问该测试目标的情况，不是所有网站的实际体验，也不等于下载带宽。排查某个站点时，可先改用手动选择组固定同一个节点，减少自动切换带来的干扰。还要检查策略组是否嵌套其他组，最终出站可能不是当前页面直接显示的那一层。切换后用新连接验证结果。

规则通常自上而下匹配，首个命中项决定出站。自定义规则应放在可能提前匹配的宽泛规则之前，且目标策略名称必须与实际策略组一致。如果客户端提供覆写或合并功能，应优先在那里维护，并确认规则被插入的位置；直接编辑远程配置可能在订阅更新后丢失。保存后重新加载配置，在连接记录中核对命中规则。域名规则需要内核能够识别域名，连接复用和已有长连接也可能影响观察，测试前宜关闭旧连接再重新访问。

Fake-IP 为域名分配虚拟地址，内核再利用映射关系识别目标并分流；redir-host 通常向应用返回真实解析地址。选择时应结合客户端的 DNS 接管方式和应用兼容性，而不是只看模式名称。若个别局域网服务或应用异常，先确认问题域名，再考虑通过 fake-ip-filter 排除相关域名，避免一次放行过大的范围。切换模式后可能需要清理系统与应用的 DNS 缓存并重建连接。应用自行使用加密 DNS 时，也应检查其解析是否绕过当前配置。

允许局域网连接用于让同一受信任网络中的其他设备使用本机代理端口。除了开启开关，还需要确认监听地址、实际端口和系统防火墙规则；其他设备填写的是客户端所在设备的局域网地址，而不是自身的回环地址。只向必要的网络与设备开放，公共网络中应保持关闭，并按客户端能力设置访问认证。不要把代理端口或控制接口通过路由器映射到公网。若连接失败，依次检查网络隔离、防火墙、端口监听和认证信息，不能仅凭开关状态判断可用。

先看更新日志中的具体错误，再决定下一步。HTTP 401 或 403 通常需要检查授权与服务状态，404 可能表示地址失效或路径改变，429 应等待后再试；超时、域名解析失败和 TLS 错误则优先检查网络、系统时间与证书环境。若下载成功但解析失败，返回内容可能是登录页、错误页或不兼容的订阅格式。保留当前可用配置，确认客户端更新订阅时使用直连还是代理，再测试另一种获取路径。不要把含凭据的完整链接粘贴到公开检测网站。

通常先检查单个出站，不急于重装。固定选择出问题的节点，查看日志属于域名解析失败、连接被拒绝、握手失败还是探测超时，再核对订阅是否过期及服务器参数是否有变更。部分测试目标不可达时，测试超时也不一定代表所有实际访问都失败，应结合真实请求判断。可切换受信任的网络重复测试，区分当前网络路径与服务器故障。如果只有依赖 UDP 的协议异常，还应确认网络是否支持相关流量；不要为了消除报错随意关闭证书验证。

系统代理只影响遵循对应系统设置的应用，命令行工具、部分浏览器设置和应用内置网络栈可能使用独立代理配置。先核对系统中的代理地址与端口是否对应当前客户端，再检查是否存在其他软件反复修改设置。访问一个新页面并观察客户端连接记录：完全没有记录时优先检查流量入口；有记录但命中直连时检查模式与规则；已命中代理却失败时检查出站。确需接管更多应用时可评估 TUN 模式，但应先确认权限和路由环境，避免同时运行多个接管工具。

部分 UWP 应用受到 AppContainer 的回环访问限制，可能无法连接客户端监听的本机代理端口。先确认普通桌面应用可以使用相同代理，并核对目标应用是否确实受到此限制，不要将所有商店安装的程序都视为 UWP。可使用客户端提供的回环豁免工具，或按 Windows 的 CheckNetIsolation 工具说明为目标包添加豁免；操作通常需要管理员权限。添加后完全退出并重新启动应用，再查看连接记录。仅对确有需要的应用设置，停用时可移除对应豁免。