Clash 常见问题

Clash 最初指代理内核及其配置生态；Clash Meta 是衍生内核项目的旧名称，后续以 mihomo 名称维护。图形客户端负责订阅导入、策略组选择、系统代理和日志展示，内核负责解析配置、匹配规则与建立连接。客户端名称相近，不代表内核和支持协议完全相同。排查前先到关于页面记录客户端名称、版本与内核版本，再按对应项目的设置项操作，不能直接套用另一款客户端的截图。

客户端提供运行界面和网络处理能力，配置文件则定义代理服务器、策略组、规则与 DNS 设置。仅安装客户端，不会自动获得可连接的代理服务器。已有配置时，在配置页面选择 URL 导入或本地文件导入，启用后检查策略组是否出现可用选项。订阅通常含有访问凭据，应只从可信来源获取，不要把完整链接粘贴到公开论坛、在线转换页面或问题截图中。

日常使用先选规则模式，由 rules 自上而下决定连接走 DIRECT、代理策略组或 REJECT。全局模式把已进入内核的连接交给全局策略，适合短时对比规则是否影响结果；直连模式让已接管连接直接访问目标。模式选择不等于接管开关，应用没有使用系统代理、显式代理或 TUN 时，改成全局也不会自动接管该应用。测试结束后恢复规则模式，并重新建立待测连接。

系统代理把代理地址写入操作系统设置，主要服务于遵循该设置的应用；TUN 通过虚拟网络接口与路由接管符合条件的流量，适用于忽略系统代理的程序。两者不必为了生效而同时开启。先用系统代理验证浏览器，再按应用需求启用 TUN，避免一次修改多个变量。TUN 的实际接管范围还取决于路由、排除项和 DNS 配置，不能仅凭开关亮起就认定全部流量已经接管。

通常可以复用代理服务器、策略组和常见规则，但前提是目标客户端的内核支持相同语法与协议。涉及网卡名、文件路径、脚本、外部控制接口和 TUN 的部分，往往需要按系统调整。迁移时先导入原始配置并查看解析结果，再单独启用接管功能；不要直接复制旧设备的运行目录覆盖新安装。订阅更新也可能覆盖本地修改，长期调整优先放在客户端支持的覆写或合并设置中。

先在配置页面读取完整报错。超时通常应检查网络可达性及更新是否依赖当前代理；HTTP 401 或 403 应确认订阅授权与链接是否失效；证书错误先校准系统时间，再检查证书链和网络环境，不要直接关闭证书验证。解析报错则确认返回内容是 Clash YAML，而不是网页、登录提示或其他格式的节点列表。重新复制链接时去掉首尾空格，保留完整参数，并避免在公开日志中暴露链接。

先使用客户端提供的配置检查功能，按报错行定位缩进、字段或引用问题。YAML 层级使用空格，避免制表符；策略组引用的节点名、规则指向的策略组名必须与定义一致，包括大小写。出现不支持的代理类型或字段时，核对内核兼容性，而不是反复重新安装。修改前保留原文件，每次只调整一项并重新检查。能够导入只代表文件被读取，仍需启用配置并确认内核成功启动。

先确认内核正在运行，再到系统代理设置核对监听地址与端口是否和客户端一致。7890 是常见混合端口示例，不代表每款客户端的当前端口。检查浏览器代理扩展、手动代理设置和系统绕过列表，避免其他配置覆盖客户端。随后打开连接页面，用新标签页访问目标，观察是否出现对应连接及命中规则。若完全没有记录，优先查接管路径；若记录为 DIRECT，则继续查规则与策略，而不是只切换节点。

Windows 上先关闭 TUN，查看客户端是否提供服务模式的安装或修复入口，按提示授权后重新启动客户端；部分客户端也支持以管理员权限运行完成相关操作。macOS 和 Linux 按项目文档授权网络扩展、辅助服务或所需能力，不能照搬 Windows 的步骤。如果服务启动失败，先读日志中的具体错误，再检查安全软件拦截、虚拟网卡和其他 VPN 冲突。权限问题解决后再开启 TUN，不要持续重复安装。

先确认当前启用的是刚导入的配置，而不是另一个同名配置。若使用 proxy-providers，检查提供者资源是否下载成功，以及策略组的 use、filter 或 exclude-filter 是否把所有条目排除了。配置里写了代理定义，并不代表每个策略组都会自动显示它们。订阅返回内容不完整、套餐到期或内核不支持协议，也可能造成条目缺失。保留原始配置并查看更新错误，暂时关闭自定义覆写有助于区分订阅问题和本地合并问题。

在配置页面打开对应订阅的编辑或更新设置，查找自动更新间隔及更新代理选项；不同客户端的单位和名称可能不同，应以界面提示为准。间隔按提供方要求设置，避免过于频繁触发请求限制。直连更新失败但现有代理仍可用时，可以尝试通过代理更新；若订阅必须先更新才能连接，选择依赖失效代理的更新路径会形成循环。确认手动更新成功后，再检查自动更新记录是否按预期执行。

规则按顺序匹配，命中后通常不再继续检查后续规则。把更具体的域名规则放在宽泛规则之前，并把 MATCH 兜底留在末尾。例如 DOMAIN-SUFFIX,github.com,Proxy 需要配置中确实存在名为 Proxy 的策略组。优先通过客户端的规则覆写功能追加或前置规则，避免订阅更新覆盖改动。保存后重新载入配置，并用新建连接查看实际命中项；已有长连接一般不会因为规则修改而立即改走新出口。

打开连接页面，按目标域名、进程名或目标地址筛选，再检查命中规则、策略链和最终选择的代理。策略组名称只是选择入口，不一定就是最终出口；嵌套策略组需要沿策略链继续查看。测试前关闭目标应用的旧连接，再发起一次新请求，减少连接复用造成的干扰。单独查看浏览器显示的出口地址，只能说明那次请求的结果，不能证明其他应用、UDP 或所有域名都采用相同路径。

先在客户端开启允许局域网访问，并确认监听地址不再仅限本机回环；再在其他设备上填写运行客户端那台电脑的局域网地址及实际端口。allow-lan: false 表示不允许局域网访问，具体默认值以当前配置为准。放行防火墙时只对可信的专用网络和必要地址开放，按内核能力设置认证，不要把代理端口映射到公网。测试结束后关闭不再需要的共享，同时检查外部控制接口没有被一并暴露。

保留客户端与内核版本、操作系统版本、发生时间、操作顺序和完整错误类型。日志级别通常先用 info，只在复现问题时短时提高，完成后恢复，避免持续产生大量记录。分享前遮去订阅 URL、认证参数、密码、控制接口密钥，以及不希望公开的访问域名和地址。不要直接上传整个配置目录；优先提供与故障相关的少量日志和已脱敏配置片段，同时注明系统代理与 TUN 的开启状态。

节点测试只是内核对指定测试地址的一次请求，超时可能来自测试地址不可达、解析失败或服务器连接失败，不能单独等同于全部连接失效。先确认能打开的网页是否命中了代理，而不是走 DIRECT 或缓存；再使用同一节点访问不同目标，并查看错误发生在解析、握手还是传输阶段。所有目标都失败时再检查服务器状态、订阅有效期和本机网络。测试地址可按客户端文档调整，不要仅凭一次测试结果删除配置。

先关闭 TUN，确认基础网络恢复，再保留一个接管工具进行测试。其他 VPN、虚拟机网卡和安全软件可能同时修改默认路由或 DNS，导致流量绕行、回环或解析失败。检查日志中的网卡创建、路由添加与 DNS 监听错误，按顺序核对服务权限、端口占用和自动路由设置。不要直接删除全部系统路由。需要同时使用企业 VPN 时，应按其网络要求配置排除网段，不能假设两套自动路由能够直接兼容。

先明确预期：哪些域名应由哪个解析路径处理，以及解析连接应直连还是经过代理。DNS 检测页面显示的是解析器出口，不能仅凭地区不同就认定泄漏。浏览器安全 DNS、系统加密 DNS、IPv6 与 TUN 的 DNS 劫持配置，都可能让解析绕过客户端。测试时逐项记录这些设置，清理相关缓存后重新查询，并结合客户端日志确认请求路径。不要同时随机修改 fake-ip、nameserver 与系统 DNS，否则难以定位真正变化。

部分受应用容器限制的 Windows 应用不能直接访问本机回环代理，即使浏览器正常也可能连接失败。先确认问题应用确实使用系统代理，再检查客户端是否提供 UWP 回环豁免入口。需要手动处理时，以管理员权限打开终端，用 CheckNetIsolation LoopbackExempt -s 查看现有豁免，再按应用实际包族名设置，不要照抄其他应用的名称。只为可信且确有需要的应用授权，并遵守设备管理策略；回环豁免不能修复节点或规则错误。

退出后无法联网，先检查系统代理是否仍指向已停止监听的本机端口，关闭残留的手动代理后重试；若启用过 TUN，再确认辅助服务或虚拟接口是否仍在运行。端口占用时，先查是否同时启动了两份客户端，正常退出重复实例，不要直接结束不明系统进程。确需更换 mixed-port 时，同步更新系统代理和手动填写该端口的应用。恢复后采用客户端的正常退出流程，避免反复强制结束进程留下设置。