Clash 常见问题

客户端负责配置导入、系统代理和界面操作，内核负责解析配置、匹配规则并建立连接。Clash Meta 是基于原版 Clash 发展出的分支，mihomo 延续了这一内核路线；客户端名称中带有 Clash，并不表示使用相同内核。遇到协议不支持或字段报错时，应在客户端关于页面确认内核名称，再查对应版本的字段说明，不能只按界面名称判断兼容性。

客户端是网络工具，安装包本身不等于可用的代理服务。通常需要导入有权使用的订阅地址，或填写自己管理的服务器参数。先检查配置页面是否存在配置文件、该文件是否已激活，再查看策略组是否引用了代理或代理集合。只有 DIRECT 的配置可以用于直连分流，但不会自动生成代理节点；下载客户端与获取服务器连接参数是两个独立环节。

规则模式按 rules 从上到下匹配，首个命中的规则决定出口，适合日常分流；全局模式将进入内核的连接交给全局策略选择；直连模式让进入内核的连接直接访问目标。建议先使用规则模式，再通过连接记录确认命中了哪条规则。全局模式不会让原本未进入内核的程序自动使用代理，也不能替代系统代理或 TUN 的流量接入设置。

两者是不同的流量接入方式，不必为了正常使用而一律同时开启。系统代理主要服务于遵循操作系统代理设置的应用；TUN 通过虚拟网络接口接入流量，通常能覆盖更多程序，并可能需要管理员权限。首次配置建议只开系统代理，确认节点与规则正常后，再按应用需求启用 TUN。两者并用时应遵循客户端说明，出现异常先关闭其中一个以缩小排查范围。

不是同一个角色。内核项目维护网络处理代码，客户端项目维护图形界面和系统集成，订阅提供方负责服务器连接参数及服务状态。Clash配置教程提供客户端入口和配置说明，不签发订阅，也不能恢复过期账户。搜索 Clash 官网或 Clash 免费节点时，应先辨认页面所属项目和用途，不要把订阅密钥提交到来历不明的转换页面或反馈表单。

Ubuntu 桌面用户可先选择支持 Linux 的图形客户端，便于导入订阅、切换策略与查看日志；没有桌面的服务器更适合直接运行 mihomo，并用 systemd 管理进程。下载前用 uname -m 确认处理器架构，再核对安装包类型。桌面客户端与独立内核不要同时占用同一代理端口；迁移到服务运行时，还要重新确认服务账户、配置目录和配置文件读取权限。

先确认复制的是完整订阅链接，而不是账户后台网页地址，并检查链接前后是否混入空格或换行。随后查看更新日志：401 或 403 通常需要核对访问授权，404 应确认地址是否变更，超时则检查当前网络与更新时使用的出口。若能获取内容却报解析错误，可能返回了登录页面或不兼容格式。向提供方反馈时只提供状态码和报错摘要，不公开完整订阅地址。

先备份当前可用文件，再按日志中的行号检查附近内容；报错位置有时是上一行缩进或引号未闭合造成的。YAML 缩进使用空格，不用 Tab；列表项的短横线与同级字段应对齐。general 是教程里的基础设置分段名，不应直接写成顶层键，mixed-port 等字段应位于根层级。语法修正后若仍提示未知协议或字段，再核对内核支持情况，而不是反复调整缩进。

先查看日志，区分创建虚拟网卡失败、修改路由失败与缺少设备等问题。Windows 可按客户端说明安装服务模式并授权；Linux 应检查 /dev/net/tun 是否存在，以及进程是否具备所需网络管理权限；容器环境还需要宿主机显式提供设备与权限。不要用放宽全部目录权限来处理网络权限问题。修正后重新启动内核，并确认虚拟接口、路由和 DNS 接入是否实际生效。

如果直接编辑了远程订阅生成的配置文件，下次更新可能用远端内容覆盖本地修改。应优先使用客户端提供的覆写、合并或扩展配置功能，把自定义规则与订阅源分开保存。合并后查看最终生效配置，确认规则位置和策略组名称都正确；需要优先匹配的规则通常放在兜底规则之前。不同客户端的合并语义并不相同，迁移时不能只复制覆写文件而不检查结果。

先确定需要匹配单个域名还是整个域名后缀。DOMAIN 用于精确域名，DOMAIN-SUFFIX 用于该域名及其子域名；后者影响范围更大。规则目标必须是现有代理、策略组或 DIRECT 等有效出口，并放在可能先命中的宽泛规则和 MATCH 之前。保存并重新加载后，关闭旧连接再访问目标，从连接记录检查命中的规则；已有长连接通常不会因修改规则自动改走新出口。

部分命令行程序只读取自己的参数或代理环境变量，不读取桌面代理设置。可先用 curl --proxy http://127.0.0.1:7890 https://example.com 做单次测试，端口应替换为实际 mixed-port。若单次测试成功，再按工具文档配置 HTTP_PROXY、HTTPS_PROXY 或 ALL_PROXY，并检查 NO_PROXY 是否排除了目标。终端中的变量不会自动传给已运行的后台服务，systemd 服务需要单独配置运行环境。

先确认 dns.enable 已启用，再区分应用请求、系统 DNS 和内核上游解析三个环节。仅开启内核 DNS，并不会自动接管所有系统查询；浏览器自带的加密 DNS 也可能走独立路径。结合日志、系统解析器设置及 TUN 的 DNS 接入配置逐项核对，必要时临时关闭浏览器自定义 DNS 做对照。DNS 检测页面显示某个解析器的位置，单凭这一点还不足以判断发生了泄漏。

先在客户端中允许局域网访问，再核对内核监听地址及防火墙是否允许所用端口。其他设备应填写运行客户端那台机器的局域网地址，而不是 127.0.0.1；后者始终指向设备自身。建议只对可信局域网开放，并根据客户端能力配置访问认证与来源限制。不要在路由器上把代理端口直接映射到公网，也不要为了共享而开放 external-controller 管理接口。

测速通常只检测指定地址的一次请求，不能代表所有网站、协议和出口都可用。先查看访问目标时是否产生连接记录，再确认实际命中的策略组与测速使用的是同一节点。随后分别测试域名解析、目标网站和其他网站，判断是 DNS、特定站点还是节点链路问题。不要只根据一个延迟数字连续切换节点；保留失败时的错误类型与规则记录，更有助于定位问题。

先确认内核已经运行，系统代理指向的地址和端口与 mixed-port 一致，再访问目标并查看连接记录。没有记录时，应检查应用是否忽略系统代理、浏览器扩展是否覆盖设置，以及系统是否仍使用其他软件留下的 PAC 地址。有记录但显示 DIRECT 时，应检查模式和规则，而不是继续改系统代理。对确实不支持系统代理的应用，可在确认基础配置可用后再尝试 TUN。

先关闭代理测试基础网络，再确认订阅尚在有效期、节点列表确实更新。恢复内核后检查系统时间、服务器域名解析及日志中的握手错误；仅某种协议失败时，还要核对内核支持与当前网络对 UDP 的可达性。若所有节点同时失败，优先检查共同依赖，例如 DNS、错误的出站接口或另一代理工具。可以换一个网络做对照，但不要以测速超时直接认定所有服务器离线。

先退出重复启动的客户端，检查后台是否还运行着独立内核或 systemd 服务。Ubuntu 可用 ss -ltnp 查看 TCP 监听情况，并结合进程信息确认占用者，不要直接终止不明系统进程。若两个服务都需要保留，可修改 mixed-port，并同步更新系统代理、浏览器设置和终端环境变量。还要区分代理端口与 external-controller 管理端口，修改管理端口并不能解决代理监听冲突。

部分采用 UWP 沙箱的应用受到回环访问限制，可能无法连接 127.0.0.1 上的代理，但并非所有商店应用都属于这种情况。先确认浏览器可正常使用同一代理，再查看目标应用是否产生连接记录。确属回环限制时，可使用客户端提供的豁免工具，或以管理员权限通过 CheckNetIsolation 为对应包添加豁免；记录修改对象，便于撤销。也可评估 TUN，但不必对所有应用批量解除限制。

不应直接忽略，也不要通过关闭证书验证来恢复访问。先检查系统时间与时区，再确认警告中的域名、证书颁发者和有效期是否符合目标网站。随后关闭抓包工具或其他网络过滤软件，并对比直连、其他节点与其他网络。普通代理转发并不要求安装陌生根证书；若只有某一出口出现异常，应停止通过该出口提交账户或支付信息，保留错误提示后继续排查。