Clash 常见问题

Clash 是代理工具生态中常见的名称；mihomo 是兼容 Clash 配置体系、持续演进的代理内核，负责连接处理、DNS 与规则匹配；图形客户端则提供订阅管理、策略选择、日志查看和系统代理入口。界面相似并不代表内核版本或功能相同，排查时应同时记录客户端名称、客户端版本与内核版本。配置中的协议或字段能否使用，应以实际运行内核的支持情况为准，不能只凭客户端名称判断。

客户端负责执行配置，本身不等于可用的代理服务。订阅通常提供代理节点、策略组和规则等内容，也可能只提供节点，需要与客户端的配置模板组合使用。导入前先确认来源可信、服务仍在有效期内，并确认输出格式适用于当前内核。导入后还要启用对应配置、选择策略组和代理模式，单纯保存链接不会改变网络路径。请勿在截图、公开工单或聊天记录中展示完整订阅地址，其中的访问凭据可能被他人使用。

规则模式按 rules 的排列顺序匹配，并把连接交给命中的策略，适合日常按域名或网络范围分流；全局模式把进入内核的连接交给全局策略，适合临时判断问题是否来自规则；直连模式则让进入内核的连接直接访问目标。全局不等于所有应用都会经过客户端，未接入系统代理或 TUN 的流量可能根本没有进入内核。切换模式后应新建连接再验证，已有长连接可能继续沿用先前的处理路径。

系统代理是向操作系统登记代理地址，主要影响愿意读取这项设置的应用；TUN 通过虚拟网络接口和路由接入流量，常用于处理不遵循系统代理的程序。两者并非必须同时开启，初次使用建议先验证系统代理，再按应用需求启用 TUN。TUN 还涉及权限、路由、DNS 与其他网络软件的兼容性，开启后若出现断网，应先关闭 TUN 对照测试，而不是反复更换订阅。具体组合方式以客户端的实现与说明为准。

先查看配置页的更新错误，再区分链接访问失败与内容解析失败。出现 401 或 403 时，检查订阅是否到期、凭据是否重置及服务端是否限制访问；出现 404 时，向订阅提供方确认链接是否已更换。若返回登录页、网页验证或格式错误，说明收到的内容未必是配置文件。访问超时则检查本地网络，以及客户端拉取订阅时使用直连还是代理。更新成功前保留上一份可用配置，不要把重装客户端当作订阅失效的首选处理方式。

先复制原文件，再根据日志提供的行号检查附近内容。YAML 层级使用空格缩进，避免混入制表符；列表项的短横线、冒号后的空格，以及包含特殊字符的字符串都需要留意。语法通过后，还要检查规则目标是否存在、策略组引用的节点名称是否完全一致，以及当前内核是否支持所用字段。行号有时指向解析停止处，真正错误可能在上一行。每次只修改一小段并重新检查，确认加载成功后再启用，便于出现问题时恢复。

先确认内核能够正常启动，再检查客户端要求的服务模式、辅助程序或管理员授权是否完成。Windows 客户端可能需要安装并启动服务，macOS 可能需要确认辅助程序权限，Linux 则可能涉及虚拟接口访问权限与网络管理能力。不要直接给来源不明的程序提升权限，应先核对安装来源及客户端说明。授权完成后重新启动客户端，并从日志检查接口创建和路由设置是否成功；若设备受组织策略管理，应由管理员确认权限范围，不要绕过管理限制。

部分 Windows 打包应用受 AppContainer 网络隔离影响，访问本机代理地址时可能需要回环豁免，但并非所有商店应用的问题都由此引起。先确认浏览器通过同一系统代理可以访问，再查看目标应用是否产生连接记录。若客户端提供回环豁免工具，仅为确有需要且可信的应用启用；也可由管理员使用系统工具检查对应应用包的豁免状态。修改后彻底退出并重新打开应用。回环权限只解决本机访问限制，不会修复订阅、DNS 或远端连接故障。

先对照系统代理地址和端口与客户端实际监听值，确认内核正在运行；默认示例中的 7890 不代表当前配置一定使用该端口。随后检查应用是否有独立代理设置、是否忽略系统代理，以及系统的绕过列表是否包含目标地址。可在应用中发起一次新请求，同时观察客户端连接页或日志；完全没有记录时，应优先排查流量接入路径，而不是调整分流规则。还要检查其他代理软件或网络管理工具是否覆盖系统设置，必要时只保留一个工具进行对照。

许多命令行工具不会自动读取桌面系统代理，需要按工具说明配置 HTTP、HTTPS 或 SOCKS 代理。使用 mixed-port 时，可为支持 HTTP 代理的工具填写本机地址及该端口；不要误填 external-controller，后者是控制接口而非流量入口。终端环境变量只影响读取它们的程序，变量名称和生效方式也因工具而异，修改后应在同一终端启动新进程测试。先做当前会话的临时配置，确认有效再持久化，关闭客户端后同步取消，避免残留代理设置造成连接失败。

客户端测速通常是通过指定地址发起探测，结果只反映该探测当时的连接情况，不等于所有网站都可访问，也不能直接代表下载速度。先检查当前策略组实际选中的节点是否与测试对象一致，再确认网页连接命中了哪个策略。若只是一类网站失败，应检查域名解析、规则归属及目标服务的访问限制；若全部目标失败，再检查节点有效性和本地网络。测试地址本身不可达也会造成误判，因此应结合日志与实际访问结果判断，不要只按延迟数值频繁切换节点。

订阅文件更新时通常会被重新下载，直接编辑其中的内容可能被覆盖。需要长期保留的设置，应使用客户端支持的覆写、合并或脚本机制，并先了解它对列表采用追加、前置还是整体替换。自定义 rules 的位置尤其重要：具体规则应放在可能提前命中的宽泛规则之前，MATCH 作为兜底通常放在末尾。修改后查看最终生效配置，确认策略名引用仍然有效。不同客户端的覆写格式未必通用，迁移时应重新检查，而不是直接复制另一客户端的覆写文件。

先关闭客户端代理，确认本地网络本身可以访问正常的直连目标，再检查订阅有效期、节点是否被正确加载以及设备时间是否准确。随后选一个节点发起实际访问，结合日志区分域名解析失败、连接超时、认证失败与证书错误。全部节点失败可能来自共享的网络路径或订阅问题，不能直接认定每个节点都已失效。条件允许时用另一条可信网络对照；若只有测速失败，还应检查探测地址。提交问题时提供脱敏错误与操作步骤，避免公开节点密码和订阅凭据。

先从日志确认异常域名是否解析成功，并检查连接是否进入正确策略。Fake-IP 使用映射地址协助分流，部分应用或网络环境可能不适配，但仅凭打不开页面不能断定是它导致。可在保留原配置后，用客户端支持的方式临时切换解析模式作对照；若确认仅少数域名不兼容，再按内核文档评估 fake-ip-filter，而不是把所有域名都排除。调整后需要重新建立连接，必要时刷新系统或应用的 DNS 缓存，并检查浏览器安全 DNS 是否绕过预期的解析路径。

先检查是否重复启动了客户端，或同时运行了其他代理工具。Windows 可用 netstat 查找监听端口与对应进程，macOS 和 Linux 可用 lsof 或 ss 查看；确认进程用途后再决定退出哪个程序，不要直接结束不认识的系统进程。若需要保留原进程，可把 mixed-port 改成空闲端口，并同步修改系统代理、浏览器独立代理及终端设置。还要分清报错的是代理端口还是控制端口，两者不能互相替代。修改后确认内核成功监听，再发起新连接验证。

先检查系统代理是否仍指向已经停止监听的本机端口，并移除浏览器或终端里单独设置的代理。若此前启用了 TUN，优先重新打开客户端，用正常关闭流程停用 TUN、关闭系统代理后再退出，观察虚拟接口与路由是否恢复。仍有异常时检查系统 DNS 是否被手动改成了当前不可达的地址，并重新连接网络。操作前记录原有网络设置，尤其是在公司网络或固定地址环境中；不要一开始就重置全部网络参数，以免同时丢失原本需要的配置。