Clash 常见问题

Clash 是代理内核及其配置生态的常用名称；Clash Meta 是相关衍生内核曾使用的名称，后续以 mihomo 名称继续发展。客户端则提供配置导入、系统代理、连接查看等图形功能。判断功能是否可用，应查看客户端实际携带的内核及其版本，不能只看应用名称。旧教程里的字段也需要对照当前内核文档，避免把不同内核的配置直接混用。

客户端负责加载配置并运行内核，不会因安装完成就自动获得可用的远程代理服务。订阅通常提供代理连接参数、策略组与规则，手写配置也可以实现相同目的。先确认配置来自可信来源，再检查是否成功载入以及策略组是否有可选项。订阅地址往往包含访问凭据，不应贴到公开评论、截图或在线转换页面；排查时只提供脱敏后的报错信息。

规则模式按 rules 顺序为已进入内核的连接选择策略，适合日常分流；全局模式让这些连接使用全局策略，适合临时对比某条代理链路；直连模式则让这些连接直接访问目标。模式只决定内核收到流量后的处理方式，不等于改变系统接管范围。切换模式后，应新建连接并查看连接记录，浏览器已有的长连接可能继续沿用原来的出站路径。

系统代理通过操作系统设置引导愿意遵循该设置的应用连接本地代理端口；TUN 通过虚拟网络接口与路由接管流量，可覆盖部分不读取系统代理的程序。初次配置建议先用系统代理验证，再按实际需求启用 TUN，不必直接叠加两者。TUN 的覆盖范围仍受路由、排除项、权限与平台限制影响，不能仅凭开关状态判断所有应用都已进入内核。

不能仅凭配置文件能导入就认定所有字段都会生效。移动端客户端对订阅格式、规则语法、扩展字段和网络接管方式的支持可能与桌面端不同。选择客户端后，应先确认其支持的配置格式，再查看导入提示与连接记录。Clash Plus 可从下载页的 iOS 分类进入 App Store，官网为 clashplus.io；桌面端的服务安装与系统代理操作不适用于 iOS。

先检查设备时间、当前网络和订阅账户状态，再核对地址是否复制完整，是否混入空格、换行或已过期的访问参数。记录客户端给出的 HTTP 状态码：401、403 常与授权或访问限制有关，404 可能是地址变更，超时则需要继续检查网络路径。若客户端提供订阅更新的代理设置，可分别测试直连与代理获取；不要反复删除仍可用的旧配置，也不要公开完整订阅地址。

先阅读错误中的行号和字段名，再检查该行及其上一段的缩进、冒号与列表符号。YAML 缩进应使用空格，中文冒号和制表符容易导致解析失败。若语法通过但内核仍拒绝加载，继续检查策略引用是否存在，以及当前内核是否支持相关字段。保留原文件，在副本中逐段回退最近的修改；不要把带有订阅凭据或代理密码的完整文件提交到公共在线检查工具。

mixed-port 在同一端口接受 HTTP 与 SOCKS 代理连接，7890 是常见配置值，不是所有客户端都必须使用的固定端口。修改后先重载配置，确认内核实际监听新端口，再同步修改系统代理、浏览器扩展及命令行环境变量。使用客户端覆写设置时，还应检查它是否覆盖了订阅里的端口字段。只改配置文件而保留系统里的旧端口，会出现客户端运行正常但应用无法连接的情况。

先看日志区分权限不足、虚拟接口创建失败和路由写入失败。Windows 客户端可能需要安装并启动后台服务，或按客户端说明使用管理员权限；macOS 需要批准相应的网络权限；Linux 通常涉及 TUN 设备与网络管理权限。服务模式是 GUI 客户端的运行机制，并非通用的 YAML 字段。授权或安装服务后重新启动内核，再确认虚拟接口和路由，避免长期以高权限运行无关程序。

不要直接把长期维护的规则写进会被订阅更新替换的缓存文件。优先使用客户端提供的覆写、合并或脚本功能，把个人规则和 DNS 调整保存在独立位置。先确认该客户端的合并方式：列表可能被替换，也可能被追加，规则顺序也可能改变。完成更新后检查最终生效配置，而不是只看编辑器里的本地文件；升级客户端前备份覆写文件，并记录策略组名称的依赖关系。

select 适合手动固定出口；url-test 根据指定测试地址的探测结果选择成员；fallback 通常按成员顺序选择可用项。自动探测只反映测试目标与测试时刻的情况，不能代表所有网站和协议。可以用 select 包含一个自动组，保留临时手动切换的入口。排查时先固定一个已确认可用的成员，并新建连接，避免自动切换让同一次测试混入不同出口的结果。

打开客户端的连接列表，再重新访问目标网站，按域名或进程筛选，查看匹配规则、目标策略和实际出站链路。规则一般从上到下检查，首个命中项生效，因此新增规则必须放在会提前截获它的宽泛规则之前。若只看到 IP 而没有域名，要继续核对 DNS 路径与嗅探条件。修改后关闭该站点的旧连接再测试，不能仅根据网页是否打开推断规则已经生效。

启用 Fake-IP 后，内核可向应用返回映射地址，再利用映射关系恢复域名并执行分流。若配置使用 fake-ip-range: 198.18.0.1/16，看到该范围的解析结果本身不代表故障。关键是后续连接是否回到维护映射的内核。遇到局域网设备发现或特定应用兼容问题时，再为确有需要的域名配置 fake-ip-filter；不要因看到映射地址就整体关闭 DNS 功能。

先确认两台设备在可互访的网络中，再检查 allow-lan、监听地址及主机防火墙。其他设备的代理服务器应填写运行客户端的局域网 IP，而不是 127.0.0.1，并使用实际监听的 mixed-port。放行范围应限定为可信局域网，必要时配置认证，不要把代理端口通过路由器映射到公网。主机 IP 变化、访客网络隔离和无线接入点隔离，都可能导致连接失败。

选择一个需要验证的目标，先清理该目标的旧连接，再观察客户端连接列表是否出现对应请求，以及策略链是否符合预期。需要隔离浏览器设置影响时，可在终端使用 curl -I -x http://127.0.0.1:7890 https://example.com 测试显式 HTTP 代理；端口应替换为实际值。该命令只验证这次请求的代理路径，不代表系统代理、UDP 或所有应用都已正常接管。

先比较多个成员与不同网络的结果。只有一个成员失败时，检查该成员参数、服务状态和协议支持；全部失败时，优先检查设备时间、网络连通性、DNS 与配置是否载入。再核对测试地址能否访问，测试端点故障也会造成集体超时。探测成功不代表实际业务一定正常，探测失败也不足以单独证明服务失效；应结合真实请求与日志里的握手、解析或连接错误判断。

先核对系统代理指向的地址和端口是否与内核监听一致，再检查浏览器扩展、代理绕过列表以及其他代理软件是否改写设置。终端程序不一定读取操作系统代理，可能需要单独设置 HTTP_PROXY、HTTPS_PROXY 或使用程序的显式代理参数。用显式代理请求与普通请求进行对照，并查看连接记录。若显式代理正常而普通请求不进入内核，重点检查应用的代理读取方式，而非反复更换节点。

先确认请求确实进入内核，再查看日志是否出现解析失败、DNS 查询超时或上游连接失败。检查 nameserver 是否可达，使用加密 DNS 时还要确认解析其服务器域名的引导路径。TUN 场景需核对 dns-hijack 与应用自带安全 DNS 是否影响预期路径。每次只调整一个环节，重载配置并按需清理系统 DNS 缓存、重建连接；不要同时替换所有 DNS 字段，否则难以确定故障来源。

部分使用 AppContainer 的应用受回环访问限制，无法像普通桌面程序一样连接本机代理。先确认具体应用是否属于此类，再优先使用客户端提供的回环豁免功能，只授权确有需要的应用。也可用管理员终端运行 CheckNetIsolation LoopbackExempt -s 查看已有豁免，再按系统文档为指定包配置。不要批量放开所有应用；设置后重新启动目标应用，并在连接列表中确认请求路径。

先检查系统代理是否仍指向已经停止监听的本地端口，关闭残留设置或重新启动客户端后正常退出。若使用 TUN，再检查后台服务、虚拟接口和路由是否已恢复，避免同时结束多个网络程序导致状态难以判断。必要时按操作系统设置恢复自动 DNS，并重建网络连接。不要直接删除未知网卡或清空全部路由；保留出错前后的设置与日志，恢复后再逐项重启相关功能。