Clash 常见问题

客户端负责导入配置、切换策略和设置系统代理；内核负责解析配置、建立连接与执行分流；订阅则是服务提供方交付节点或配置的入口。安装客户端并不等于已经获得可用线路，仍需导入自己有权使用的配置。Clash 生态中不同客户端可能使用不同内核，mihomo 是其中持续发展的内核之一。遇到功能不支持时，应同时记录客户端名称和实际内核版本，而不是只根据应用名称判断。本站提供下载与配置知识，不签发订阅，也不能恢复服务方账户。

日常使用通常先选 Rule，让已接管的连接按配置中的规则分流；Global 将已接管的连接交给全局策略处理，仍要确认该策略选中了可用节点；Direct 则让已接管的连接直接访问。切换模式不会自动扩大流量接管范围，也不能让一个不遵循系统代理的程序突然走代理。排查时可短暂用 Global 对比同一网址：若 Global 正常而 Rule 异常，优先查规则命中与策略选择；若两种模式都失败，再查节点、解析和接管链路，测试后恢复原模式。

延迟测试成功只说明节点在当时能够完成客户端设定的探测请求，不代表所有网站、协议和出口都可用。先查看测试使用的网址，再确认目标网站的连接实际命中了哪个策略组，避免把另一个节点的测试结果当成当前连接结果。随后对比普通网页与目标网页，并查看日志中的解析失败、握手失败或远端拒绝信息。目标站可能限制出口地址，某些应用还依赖 UDP。不要单凭一个延迟数值反复换配置，应先区分接管失败、节点不可用与目标站自身限制。

不能仅凭 YAML 扩展名判断兼容性。客户端使用的内核、支持的协议、规则类型和覆写方式可能不同，旧内核尤其可能无法识别新字段。迁移前先保留原配置，再检查目标客户端的内核说明；导入后先执行配置检查，阅读第一条明确的解析错误，不要一次删除多段配置。移动端还可能通过系统 VPN 接口接管流量，设置入口与桌面端不同。若订阅方提供多个格式，应选择与目标内核匹配的格式；转换配置时注意订阅地址包含访问凭据，不要随意提交给陌生转换服务。

先区分下载失败与配置解析失败。连接超时、证书错误或 HTTP 状态异常属于下载阶段；能够下载但提示字段、缩进或代理类型错误，则属于内容解析阶段。核对复制的地址是否完整，是否误带空格、换行，或把账户网页地址当成订阅地址。若当前网络访问不了订阅域名，可在已有可用连接下尝试更新，但不要反复切换多个网络设置。若返回的是登录页或错误说明，应到服务方账户核实链接状态。提交错误截图时遮住完整订阅地址、账户信息和节点凭据。

先保留当前配置和更新错误，再到服务方账户查看订阅有效期、流量额度、链接是否被重置，以及服务公告。HTTP 401 或 403 常见于鉴权或访问限制，但最终原因仍要以服务方返回内容为准；不要把每一次更新失败都判断成账户到期。若新配置为空或节点名称改变，策略组可能仍引用旧名称，需要检查实际选项。恢复旧配置只能找回本地设置，不能延长服务有效期。确认服务方要求更换地址后再替换，并移除失效入口，避免定时更新持续覆盖可用配置。

先在系统信息中确认操作系统版本与处理器架构，再返回下载页选择对应安装包。x64 与 ARM64 不是同一种架构，macOS 的 Apple Silicon 与 Intel 也应分别核对；Linux 还需区分 deb、rpm 等发行版包格式。若提示系统版本不支持，应查该客户端的最低要求，不要通过改文件名或关闭系统防护强行安装。安装后无法启动时，记录完整报错，并排查旧进程占用、所需运行环境和安全软件拦截。更新前备份配置与本地覆写，避免卸载操作同时清除排查所需的信息。

先关闭 TUN，确认普通系统代理能够正常连接，再单独排查虚拟网卡层。桌面客户端通常需要安装或启动服务、获得管理员权限，macOS 还可能要求批准相关系统权限，具体以客户端提示为准。检查日志是否指向服务未运行、网卡创建失败或路由冲突；不要只反复点击开关。暂时退出其他 VPN、加速器和同类 TUN 工具后重试，避免同时修改路由。若开启后整机断网，先关闭 TUN 恢复网络，保留错误信息，再检查网卡、默认路由和 DNS，不要批量删除不认识的系统网卡。

先检查客户端内核是否运行，再核对系统代理指向的本机地址与端口是否对应当前监听端口。浏览器可能使用扩展、自定义代理或独立网络设置，从而覆盖系统设置；暂停相关扩展并用遵循系统代理的浏览器窗口对比。访问目标网址时同时查看连接列表：没有新记录，优先查接管入口；有记录但显示 DIRECT，则查规则与模式；已走节点仍失败，再查节点和目标站。不要把修改系统代理等同于开启 TUN，也不要仅凭网站页面语言判断是否经过代理。

许多命令行程序不会自动读取桌面系统代理，需要单独设置代理参数或环境变量。可先用 curl --proxy http://127.0.0.1:7890 https://example.com 做一次显式测试，其中 7890 只是示例，必须换成客户端实际提供 HTTP 或 mixed 服务的端口。测试成功后，再按所用终端设置 http_proxy、https_proxy，并检查 no_proxy 是否把目标排除。Git、包管理器和容器还可能有自己的代理配置。注意 WSL 或容器中的 127.0.0.1 不一定是宿主机，跨环境连接需另查网络边界，不能直接照搬本机地址。

先查看内核实际加载的配置，而不是只检查编辑器里保存的文件。规则通常按顺序匹配，过早出现的宽泛规则或 MATCH 可能使后面的规则没有机会命中；目标策略组名称也必须真实存在且完全一致。使用 DOMAIN 匹配完整域名，使用 DOMAIN-SUFFIX 匹配域名后缀时，应确认没有把网址协议和路径一起写进去。保存后按客户端要求重新加载配置，再建立新的连接核对日志，旧连接可能继续沿用原路径。订阅更新会覆盖远程内容时，应使用客户端提供的本地覆写或合并机制。

部分使用 AppContainer 隔离的应用不能直接访问本机回环代理，因此浏览器正常而某些商店应用失败时，可以检查回环限制，但并非所有商店应用都是 UWP。先确认该应用是否使用系统代理，以及客户端是否提供回环豁免工具；需要授权时，仅对相关应用启用。手动操作可先以管理员身份运行 CheckNetIsolation LoopbackExempt -s 查看现有列表，再依据应用实际包标识调整，不能把显示名称当作包标识。企业设备若受策略管理，应先咨询管理员；若连接已有日志记录，则还要查规则和节点，不能只归因于回环。

先关闭代理确认基础网络能正常访问，再检查订阅账户和配置是否仍有效。挑一个节点发起真实请求，并查看同一时刻的日志，区分域名解析失败、TCP 连接超时、认证失败和 TLS 握手错误；这些问题的处理方向不同。随后只改变一个变量，例如换一个网络或换一个已知可用节点，观察结果是否一致。若仅延迟探测失败而真实访问正常，应检查探测网址是否可达。若多个节点共用同一入口域名或服务方，它们同时失败也不一定是本机故障；记录发生时间与错误类型后再向服务方反馈。

先确认当前使用的是系统 DNS、内核 DNS，还是浏览器的加密 DNS，避免同时修改三处导致结果无法比较。检查上游解析器能否通过当前网络到达；如果节点服务器本身使用域名，还要确认建立代理前就能完成必要的解析。Fake-IP 返回虚拟地址本身是正常机制，不能看到虚拟网段就判定解析错误。对仅少数域名异常的情况，先查日志和兼容性，再按所用内核支持的过滤方式做最小调整。修改后清理相关缓存并重建连接；涉及局域网设备名称时，还要保留适合本地网络的解析路径。

优先检查系统是否仍把代理指向已经停止监听的本机端口。在系统网络设置中关闭手动代理；如果此前使用了自动代理脚本，也要检查对应设置。接着确认 TUN 已关闭、相关服务和虚拟网卡状态正常，并检查是否遗留手动配置的 DNS。终端程序还应清除本次设置的代理环境变量，或打开新的终端重新测试。按顺序恢复后再判断是否需要重启网络连接，不要一开始就重置全部网络设置。企业设备可能原本就依赖单位代理，修改前记录原值，避免误删组织要求的网络配置。

先用同一个浏览器、同一个检测页面对比开启前后的结果，并同时查看客户端中这次请求的连接记录。出口 IP 只是证据之一：检测站可能被规则设为直连，缓存页面也可能造成误判。若浏览器有记录而目标应用没有记录，应检查应用是否支持系统代理、是否使用 UDP 或独立网络配置，再判断是否需要 TUN。IPv4 与 IPv6 也可能走不同路径，需分别核对实际连接，而不是一看到地址不同就修改全局设置。TUN 能扩大接管范围，但仍受路由与规则控制，不能保证所有连接自动采用同一个出口。