Clash 常见问题

客户端负责配置导入、模式切换和连接展示，内核负责解析配置、匹配规则与建立代理连接。Clash Meta 是扩展内核的旧称，后续项目使用 mihomo 名称；原版 Clash 与它的协议支持、配置字段并不完全相同。排查前应在客户端的关于或内核信息中记录二者名称，不能仅凭窗口标题判断兼容性。教程中的菜单位置也可能随客户端不同而变化。

客户端是连接与分流工具，安装程序本身不等于获得可用的代理服务。需要导入自行管理的服务端配置，或由服务提供方交付的有效订阅，再激活对应配置。若已导入但列表仍为空，检查该配置是否只有规则、是否引用尚未加载的代理提供器，以及配置是否真正处于使用状态。不要把来源不明的公开配置直接设为默认配置。

日常使用通常先选规则模式，让连接按规则交给直连或代理策略；全局模式把进入内核的连接交给全局策略，适合短时对照测试；直连模式则让进入内核的连接尝试直接连接目标。三者改变的是内核内的处理方式，不会自动接管未进入客户端的应用流量。全局模式也不表示系统所有程序都已被代理，仍需检查系统代理或 TUN 入口。

延迟测试通常只检查指定测试地址的一次请求，不能覆盖目标网站的解析、规则命中、登录接口和持续传输。先打开连接面板，确认访问目标时是否出现连接，再看它命中的规则与最终出口。若测试成功但业务失败，用同一节点访问不同目标，并对比直连结果。不要仅凭一个延迟数字判断节点整体可用，也不要把较低延迟等同于较高下载速度。

部分基础配置仍可能被新客户端使用，但兼容程度取决于目标内核，而不是配置文件的扩展名。迁移前备份原配置与自定义规则，优先在独立配置中试运行，检查协议类型、代理组引用、规则集路径及 DNS 字段。Clash for Windows 已停止维护，不宜把旧版作为长期更新方案；选择替代客户端时，应同时确认维护状态和现有订阅格式。

先区分请求失败与配置解析失败：超时多与访问路径有关，401 或 403 可能涉及授权、请求限制或链接失效，解析错误则要看返回内容是否为网页或不兼容配置。检查订阅是否过期、链接是否完整，以及是否误带空格。仅在服务方说明支持时调整请求方式；浏览器能打开不代表客户端请求必然成功。反馈问题时隐藏完整订阅地址和其中的授权信息。

先记录错误行号、协议名称与当前内核名称，再核对订阅提供方要求的格式。面向 mihomo 的配置不一定能被原版 Clash 或其他客户端直接读取，同名协议的扩展参数也可能有版本要求。优先重新获取适配目标客户端的订阅，而不是逐项删除报错字段。涉及订阅转换时，先确认转换服务的可信度，因为转换端可能接触订阅内容与访问凭据。

TUN 需要创建虚拟网络接口并设置路由，通常依赖客户端的服务模式、系统授权或管理员权限。先检查内核是否正常运行，再按客户端说明安装或修复服务，并确认系统没有拦截相关组件。若仍失败，记录日志中的网卡或路由错误，检查是否与其他 VPN、虚拟网卡工具冲突。不要反复修改多项网络设置；每次只调整一处，并保留关闭 TUN 后的对照结果。

Windows 可在系统信息中查看处理器与系统类型，常见 Intel 或 AMD 桌面设备使用 x64，ARM 设备则需核对客户端是否提供原生包或支持兼容运行。macOS 在关于本机中区分 Apple 芯片与 Intel；Android 按设备支持的 ABI 选择，不能只凭系统位数猜测。先到下载页确认实际提供的构建，再核对项目的系统要求，不要把某个平台的包改名后用于另一平台。

先从日志确认被占用的是代理端口、混合端口还是控制接口端口，再定位监听进程。如果是另一个仍在运行的代理客户端，正常退出它比强制结束未知进程更稳妥。确需改端口时，应在实际生效的配置或客户端覆盖设置中修改，并同步更新浏览器、终端与系统代理的对应地址。修改后重启相关连接，确认旧端口不再被使用，避免只改界面但内核仍读取旧配置。

打开连接面板后，在目标应用中发起一次新的网络请求，观察是否出现对应域名、目标地址或进程记录，再核对命中规则和出口。已有长连接可能不会因切换节点立即重建，因此需要刷新页面或重启该应用的连接。仅看到系统代理开关开启，不能证明所有应用都遵循该设置；遇到没有记录的应用，应先查它的代理入口，而不是先调整节点或规则。

规则通常从上到下匹配，先命中的条目决定策略，较靠后的精确规则可能被前面的宽泛规则遮住。检查当前是否处于规则模式、自定义规则是否进入最终配置、策略名称是否与代理组完全一致，再在连接面板查看实际命中项。若客户端支持覆写，应确认覆写的合并顺序；直接编辑远程订阅生成的文件，下一次更新可能被覆盖，适合长期维护的修改应放在持久化覆写中。

其他设备需要把代理服务器设为运行客户端的设备在局域网中的地址，并填写实际代理端口，而不是填写 127.0.0.1。还要确认监听地址允许局域网访问、系统防火墙放行对应端口，且路由器没有启用客户端隔离。只在可信网络中开启此功能，按需要设置认证与访问限制。不要把代理端口或控制接口暴露到公网；系统代理接入也不会自动覆盖另一台设备的全部应用。

代理组选择通常影响后续新建连接，已经建立的下载、视频和即时通信连接可能继续使用原出口。先核对目标连接所属的策略组，再按需关闭该连接或在应用中重新发起请求。配置可能包含多个策略组，只切换默认组不一定影响特定网站。浏览器页面显示的出口还可能受缓存或后台连接影响，判断时应结合连接面板，而不是反复点击节点测试。

保留客户端名称、内核信息、操作系统、故障时间、复现步骤，以及同一时刻附近的错误日志；说明是否启用 TUN、系统代理和其他 VPN。日志级别只在复现期间临时提高，完成后恢复日常级别。分享前隐藏订阅链接、授权参数、节点密码、控制接口密钥和个人访问域名。优先提交最小可复现片段，完整配置不应直接贴到公开讨论区，也不要上传未经检查的截图。

先关闭代理确认基础网络可用，再检查订阅是否过期、系统时间是否正确，以及内核日志是否出现解析或握手错误。使用同一配置分别在当前网络与另一可信网络测试，有助于缩小范围；若只有一个节点失败，优先检查该节点状态。所有节点同时超时也可能是测试地址不可达，不能直接断定服务端全部故障。每轮测试固定配置和测试目标，避免同时改 DNS、模式与节点。

先看系统代理地址和端口是否指向当前内核，并检查浏览器扩展、应用自己的代理设置或绕过列表是否覆盖了系统设置。部分终端工具不读取系统代理，需要单独设置代理参数或环境变量；已有进程也可能保留旧设置。若连接面板完全没有记录，优先解决流量入口。不要把全局模式当作接管开关，它只能处理已经进入内核的连接，不能强制所有应用使用系统代理。

部分受应用容器隔离的 Windows 应用默认不能访问本机回环地址，因此浏览器可用而某个商店应用失败。先确认应用确实使用系统代理，且代理端口可用，再使用客户端提供的回环豁免工具或 Windows 的 CheckNetIsolation 工具检查对应应用包。只对需要的应用设置豁免，不建议批量放开全部应用。若启用 TUN 后恢复，也应记录两种入口的差异，而不是把所有连接失败都归因于回环限制。

先明确希望由谁解析域名，再检查应用自带的安全 DNS、系统解析器、客户端 DNS 与 TUN 的 DNS 接管是否符合预期。浏览器测试站显示的解析出口只是线索，不能单独证明全部应用的解析路径；不同域名还可能受分流策略影响。结合内核日志、连接记录和可控域名测试逐项验证。不要直接复制整段 DNS 配置，尤其要核对上游解析服务的可达性与代理节点域名的引导解析。

不应直接忽略，也不要安装来源不明的根证书。常规代理转发并不要求解密浏览器的 HTTPS 内容；证书错误需要检查系统时间、目标域名、证书链，以及是否存在安全软件的 HTTPS 检查、门户登录页或异常解析。对比关闭代理、切换可信节点和访问其他网站的结果，记录浏览器错误代码。若涉及账号或支付页面，应先停止提交敏感信息，再按错误类型逐步定位。