Clash 常见问题

Clash 是代理内核及其配置生态的常用称呼；mihomo 是由 Clash.Meta 延续发展的内核，负责连接、规则匹配与 DNS 处理。Clash Plus、Clash Verge Rev 等客户端提供图形界面，管理配置、系统代理和内核进程。同一份配置能否使用，要看客户端实际搭载的内核与版本，不能只看软件名称里有没有 Clash。

客户端负责执行配置，不会因为完成安装就自动获得远程代理服务。订阅通常提供服务器信息、代理组和分流规则，也可以使用自行维护的 YAML 配置。导入前确认来源可信、服务仍有效，并核对订阅格式。订阅地址可能包含访问凭据，提交截图或求助日志时应遮住完整链接，不能把它当成普通网页地址公开分享。

日常通常使用规则模式，由配置中的规则按顺序决定连接走向。全局模式把进入内核的连接交给全局代理组，适合短时排查规则是否影响访问；直连模式则让进入内核的连接直接访问目标。运行模式只决定已经进入内核的流量如何处理，全局模式不等于接管整台设备，也不能代替系统代理或 TUN。

新安装可先从下载页的 Clash Plus 看起，再按界面习惯比较 Clash Verge Rev、FlClash 和 Clash Nyanpasu。Clash for Windows 已停止维护，迁移时先备份配置与自定义规则，再导入新客户端。旧客户端的界面设置未必能直接搬过去，混合端口、服务模式、TUN 和 DNS 覆写需要逐项确认；两个客户端不要同时接管系统代理。

节点测速通常是内核请求某个测试地址得到的耗时，不等于下载带宽、视频吞吐或游戏表现。测试地址、超时时间、服务器负载以及目标站点所在网络都会影响结果。比较节点时保持同一测试地址和同一网络，再用实际应用验证。某个节点显示超时，也可能只是测试地址不可达，先看日志，不要只凭一个结果删除节点。

在服务提供方页面选择明确标注为 Clash 或 mihomo 的订阅地址，进入客户端的配置或订阅页面，使用从 URL 导入一类入口粘贴并保存，然后把该配置设为当前使用。账户登录页、订单页和二维码图片地址通常不是订阅。若只拿到 Base64 节点列表或 SIP008 数据，先确认客户端是否支持，不能仅把文件后缀改成 YAML。

先检查客户端内核是否正常运行，再按平台处理权限。Windows 通常需要安装并启动客户端提供的服务模式；macOS 可能要求安装辅助程序并授权；Linux 需要客户端支持的提权或服务配置；Android 需要确认系统 VPN 连接请求。完成后重新开启 TUN，并检查日志。不要长期靠反复提权掩盖服务安装失败，也不要同时开启另一个 VPN 应用。

不一定，7890 只是常见设置。混合端口可在同一个监听端口接收 HTTP 与 SOCKS5 代理连接，实际值以当前客户端为准。在浏览器扩展或其他应用里手动填写代理时，本机地址通常使用 127.0.0.1，端口要与客户端一致。若提示端口占用，先退出旧客户端或找到占用进程；更换端口后，所有手动填写过的应用也要同步修改。

系统代理只是向应用提供代理设置，不会强制所有程序遵守。先用会读取系统代理的浏览器测试，再查看客户端连接页是否出现该请求。命令行工具、游戏或自带网络栈的应用可能需要单独填写代理、设置进程环境变量，或改用 TUN。若连接已经出现在客户端但仍走 DIRECT，应检查规则命中结果，而不是继续反复切换系统代理。

让设备接入同一个可信局域网，在电脑客户端开启允许局域网连接，并确认监听地址不只限于回环地址。设备的手动 HTTP 代理填写电脑的局域网 IP 和混合端口，不要填写 127.0.0.1，也不要把电脑地址误填成路由器网关。电脑防火墙只对所需专用网络放行该端口；普通 HTTP 代理也不代表能接管设备全部应用或 UDP 流量。

订阅更新会重新下载远程配置，直接编辑生成文件的改动可能被覆盖。优先使用客户端提供的覆写、合并、扩展配置或脚本功能，把个人规则与远程订阅分开管理。不同客户端的合并顺序不一样，添加规则后要检查最终生效配置，并在连接页验证命中结果。切换客户端时也要重新配置覆写，不能假定它会随订阅地址一起迁移。

保持规则模式，在自定义规则中添加该网站的域名匹配，并把它放在可能提前命中的宽泛规则和 MATCH 兜底规则之前。例如 DOMAIN-SUFFIX,example.com,DIRECT 表示匹配该域名及其子域名。实际网站可能还请求独立的登录、图片或接口域名，应从连接日志补齐必要项，不要为了一个网站直接放行整个大型共享服务域名。

Fake-IP 会先向应用返回映射地址，内核再把连接关联回域名，以便进行规则判断和后续解析。它不是远程服务器的真实 IP。部分依赖真实解析结果、局域网发现或特殊认证流程的应用可能不兼容。先查明受影响域名，再按当前内核支持的 fake-ip-filter 语义添加例外；修改后重启相关应用，必要时清理 DNS 缓存，再判断是否需要换 DNS 模式。

先明确预期：哪些域名应由哪个解析器处理，再检查客户端 DNS 设置、TUN 的 DNS 接管，以及浏览器的安全 DNS 是否另走独立路径。测试网站显示的解析器名称或地区只能作为线索，不能单独下结论。结合内核日志、系统 DNS 设置和必要的抓包核对实际请求；规则允许直连时出现本地解析，也不一定违背配置预期。

先等待网络重新连接，再重试一个新请求。切网后旧 TCP 连接、DNS 缓存和 TUN 路由可能短时失效，可以依次尝试关闭旧连接、重新测速、重新启用当前代理接管方式，最后再重启客户端。局域网共享还要确认电脑 IP 是否变化。若每次休眠都复现，记录系统版本、内核日志与恢复时间，便于区分网络驱动问题和客户端状态恢复问题。

先看更新日志中的状态：401 或 403 常与授权、链接撤销或访问策略有关，404 可能是地址变化，超时则要检查网络与订阅域名解析。不要仅凭状态码认定服务到期，还应登录提供方页面核对。若订阅下载依赖当前不可用节点，可在确认来源后尝试直连更新，或先切换可用配置。避免把完整订阅链接提交给陌生转换服务。

先暂时关闭客户端的代理接管，确认普通网络能访问原本可直连的网站，再检查内核是否启动、订阅是否有效、系统时间是否准确。接着只选一个节点测试，并查看日志区分 DNS 解析失败、连接被拒绝、握手失败与测试地址超时。不要同时改 DNS、端口和运行模式；每次只改一项并复测。问题未定位前，保留原配置备份，避免重装后丢失线索。

部分使用 AppContainer 的应用受网络隔离限制，不能直接访问本机回环代理。先确认普通浏览器使用同一代理正常，再查看客户端是否提供 UWP 回环豁免入口，只为确有需要的应用授权。该操作通常需要管理员权限，应用重新安装后可能需要重新检查。并非所有商店应用都属于 UWP；若使用 TUN，也应单独验证接管情况，不要把所有失败都归为回环问题。

先到系统网络代理设置中关闭残留的手动代理或自动配置脚本，因为原来的本机监听端口可能已经停止服务。若此前开启 TUN，重新打开客户端并正常关闭 TUN，等待路由恢复，再检查网络适配器的 DNS 是否仍被手动指定。受单位管理的设备不要擅自清除管理配置。恢复后再次测试直连，必要时重连网络，避免一开始就执行会影响其他软件的全量网络重置。

先备份现有配置并查看启动日志。配置解析失败时重点核对 YAML 缩进、重复键、代理组引用和内核不支持的字段；打开就退出还要检查端口占用、内核文件是否完整，以及系统权限与运行库。可用一份此前正常的配置交叉测试，但不要直接删除整个数据目录。需要求助时提供客户端名称、系统架构和脱敏后的错误片段，不要附上节点密码或订阅凭据。