Clash 常见问题

Clash 通常指代理工具生态，也可能特指较早的内核项目；mihomo 是从 Clash Meta 演进而来的内核，负责解析配置、处理 DNS、匹配规则并建立出站连接。客户端则提供订阅管理、策略选择和系统代理等操作界面。排查问题时，应分别记录客户端名称与内核信息，不能只说安装了 Clash。相同的界面不代表使用相同内核，配置字段是否受支持，需要以实际运行的内核文档和启动日志为准。

客户端是管理连接和执行分流的工具，安装完成不等于已经具备可用的代理出站。通常还需要自行准备有效的订阅链接，或填写有权使用的节点参数。订阅可能包含节点、策略组和规则，也可能只提供节点列表，导入前应确认服务方提供的格式。订阅地址中的访问令牌应按凭据保管，截图、日志分享与在线转换时都要遮盖完整链接。本站提供客户端下载与配置说明，不签发订阅，也不能恢复服务方停用的账户。

日常使用优先从规则模式开始：连接按照 rules 的顺序匹配，第一条命中的规则决定出站策略。全局模式通常把已进入内核的连接交给统一的全局策略，适合短时对照测试；直连模式则让这些连接尝试直接访问。这里的全局描述出站决策，不表示所有应用流量都会自动进入客户端。应用是否被接管，仍取决于系统代理、应用代理设置或 TUN。切换模式后应新建连接再测试，已经建立的长连接可能继续沿用原来的出站。

新安装可以先查看 Clash Plus，再对照 Clash Verge Rev、FlClash 等客户端的系统支持与操作方式；需要特定功能时，应检查当前发行说明，而不是只按旧教程中的名称选择。迁移前备份订阅地址、自己添加的规则和必要的偏好设置，随后在新客户端重新导入配置。旧客户端的数据库、服务组件和界面设置不一定能直接复制。迁移过程中一次只保留一个客户端接管系统代理或 TUN，确认新配置可用后再清理旧服务。

先在系统信息中确认操作系统版本和处理器架构，再查看下载卡片的适用说明。Windows 的 x64 与 ARM64、macOS 的 Intel 与 Apple Silicon、Android 的 arm64 与 arm 不能仅凭设备外观判断。Linux 还需区分发行版的软件包格式和运行依赖。安装器提示不兼容时，先核对这些条件，不要通过随意改文件后缀来尝试安装。最低系统要求以该客户端当前发行说明为准；较旧系统即使能启动程序，也可能缺少系统代理或虚拟网卡所需组件。

先区分下载失败与内容解析失败。下载失败时检查订阅是否到期、令牌是否被重置，以及更新请求采用直连还是代理；如果代理本身尚不可用，可在客户端允许的情况下改用直连更新。下载成功却没有节点时，检查是否取到了登录网页、错误提示或不兼容格式，并确认订阅需要的是完整配置还是代理集合入口。不要把私有订阅贴到公开转换站。确认地址正确后仍返回拒绝访问或账户错误，应向订阅服务方处理，反复重装客户端通常不能解决。

远程订阅更新可能重新生成整份配置，直接编辑生成文件的内容就会被覆盖。先确认客户端实际加载的文件，再使用该客户端支持的覆写、合并或配置扩展功能保存本地修改。规则数组可能被整体替换，也可能按指定位置插入，具体取决于客户端实现；新增规则还必须引用存在的策略组。修改后检查最终生效配置与内核日志，不能只看编辑器中的源片段。建议先备份原配置，每次只改一类字段，再更新一次订阅验证修改是否仍然保留。

TUN 需要创建虚拟网络接口并可能修改路由，通常需要客户端的服务组件或系统授权。先根据当前客户端说明安装并启动服务，再检查系统弹出的网络扩展、VPN 或管理员授权是否完成；Linux 还需检查 TUN 设备和进程所需权限。不要为了消除提示而长期关闭防火墙或扩大所有文件的权限。授权后若仍失败，查看日志中首次出现的错误，并排除其他 VPN 正在接管路由。TUN 只决定流量如何进入内核，开启后仍需有可用节点和正确规则。

策略组的选择只影响最终指向该组的连接，不会自动覆盖全部规则。先在连接面板确认目标连接是否进入内核，再查看命中的规则和最终出站；如果规则指向 DIRECT，修改另一个代理组不会改变结果。规则通常由上到下匹配，宽泛的前置规则可能遮住后面的精确规则。还要检查嵌套策略组是否继续指向其他组，以及应用是否绕过系统代理。调整后关闭原连接并重试，比连续切换多个节点更容易判断是哪一处配置产生了影响。

自定义规则通常应放在可能提前命中的宽泛规则之前，并通过客户端的持久覆写入口加入配置。DOMAIN 匹配指定域名，DOMAIN-SUFFIX 用于域名后缀匹配；二者都应填写域名而不是完整网址，不包含协议、路径和查询参数。规则末尾的策略名称必须与已有节点、策略组或内置策略一致。MATCH 是没有其他条件的兜底规则，通常放在规则列表最后；如果放得过早，后面的规则就没有匹配机会。保存后用新连接检查命中记录，确认规则既被加载又实际生效。

Fake-IP 模式向应用返回保留地址段中的映射地址，由内核保存它与域名的对应关系，再根据域名处理实际连接；它不会修改网站权威 DNS 中的真实记录。部分局域网发现、设备控制或直接依赖真实解析结果的应用可能需要加入 fake-ip-filter。过滤项只影响解析行为，不等于把该域名的访问策略改为直连。遇到兼容问题时先缩小到具体域名，添加最少的过滤项，再清理相关 DNS 缓存并重建连接，避免直接过滤所有域名掩盖真正的原因。

部分受 AppContainer 隔离的 Windows 应用不能直接访问本机回环地址，而本地代理通常监听在回环地址上，因此浏览器可用时，这些应用仍可能连接失败。先确认目标应用确实受此限制，再使用客户端提供的 UWP 回环工具，或系统的 CheckNetIsolation 工具，仅为需要的应用添加回环豁免。操作可能需要管理员权限，完成后应重启目标应用。并非所有商店应用都是 UWP，也不是所有连接失败都由回环限制引起；若日志中已有连接记录，应继续检查规则与节点，而不是反复添加豁免。

先确认本机基础网络能正常访问，再查看日志中失败的是节点服务器解析、到服务器的连接，还是测速目标请求。测速超时只说明该测试请求未在期限内完成，不能单凭它判断节点永久失效。可以使用另一条已知可用的出站和同一目标作对照，同时检查设备时间、订阅有效期、服务器端口与协议参数。如果全部节点同时失败，优先检查本地网络和配置公共项；如果只有个别节点失败，再向服务方确认状态。只有看到明确的解析错误时，才针对 DNS 调整。

先记录失败的域名、错误时间与所用解析器，区分节点服务器域名无法解析和目标网站域名无法解析。检查配置中的 DNS 上游是否可达，以及加密 DNS 上游本身的域名是否具备可用的引导解析路径。使用 TUN 时，还要确认系统 DNS 请求是否按预期进入内核，避免与其他 DNS 工具互相接管。每次只更换一个上游或一项路由设置，清理缓存后重试，并保留对照日志。不要同时开启多个 DNS 接管功能，否则即使短时恢复，也难以判断是哪一项设置解决了问题。

系统代理是供应用读取的代理设置，并不强制所有程序使用；部分命令行工具、游戏或自带网络栈的应用会忽略它。先核对系统中的代理地址和端口是否与客户端监听值一致，再查看连接面板有没有目标应用的请求。没有记录时，检查应用自己的代理设置、代理环境变量和绕过列表，必要时在确认权限后使用 TUN。已有记录时，应沿规则和出站方向排查。测试期间关闭其他代理客户端，避免互相覆盖系统设置；也不要把 TUN 和全局出站模式当作同一个开关。

端口占用表示所需监听地址已被其他进程使用，先检查是否重复启动了客户端，或旧的后台内核与服务仍在运行。确认进程用途后再正常停止，不能直接结束不认识的系统进程。也可以更换本地监听端口，但必须同步更新系统代理和应用内手动填写的端口。退出后网络异常时，先检查系统是否残留指向已停止客户端的代理设置，再检查其他 VPN、路由和 DNS 状态。优先通过客户端正常关闭接管功能并退出；只有常规恢复无效时，才考虑系统网络重置，并提前记录原有网络配置。