Clash 常见问题
配置与连接排障
先确认流量是否进入内核，再检查规则与出站。按问题现象定位，避免把订阅、节点和系统设置混在一起处理。
Clash 客户端、Clash.Meta 与 mihomo 内核是什么关系？
客户端负责订阅管理、界面操作和系统集成，内核负责协议连接、DNS 处理与规则匹配。Clash.Meta 是在 Clash 生态中发展的内核分支，后续以 mihomo 名称维护；原版 Clash 与 mihomo 不能视为同一套功能集合。判断协议是否可用，应先查看客户端实际调用的内核及其支持列表，而不是只看应用名称。相同 YAML 在不同内核中可能有不同结果，迁移前应备份配置，并留意日志中的未知字段和不支持协议提示。
Clash for Windows 停止维护后，替代客户端怎么选？
新安装可先比较 Clash Plus、Clash Verge Rev、FlClash 与 Clash Nyanpasu 的系统支持、内核更新方式和服务模式，再按使用习惯选择。Clash for Windows 已停止维护，旧版本能启动不代表能识别新协议或适应后续系统变化。迁移时先导出订阅地址与自行添加的规则，在新客户端中重新导入；端口、TUN 和开机自启应重新检查，不建议直接覆盖整个程序目录。确认新客户端能正常连接后，再关闭旧客户端的自启与后台服务，避免两个代理同时接管网络。
规则、全局和直连模式分别适合什么情况？
规则模式按配置中的匹配顺序决定连接走向，适合日常使用；全局模式把进入内核的连接交给全局策略，适合临时确认某个问题是否来自分流规则；直连模式让进入内核的连接直接出站，适合对照测试。全局模式不等于接管设备上的所有流量，未进入系统代理或 TUN 的应用仍可能绕过内核。排障时可比较规则与全局模式的结果，再查看连接记录中的命中规则。切回规则模式后，仍需确认目标策略组选择了可用节点。
系统代理与 TUN 模式需要一起开启吗？
系统代理向操作系统登记本地代理地址，通常由遵循该设置的浏览器和应用使用；TUN 通过虚拟网卡与路由接管符合条件的流量，可以覆盖部分不读取系统代理的程序。两者并非必须同时开启，具体组合取决于客户端实现与应用需求。首次配置可先用系统代理验证订阅和节点，再按需启用 TUN。切换后若出现重复接管或连接异常，应一次只保留一种入口进行对照，并检查其他 VPN、虚拟网卡和安全软件是否修改了同一组路由。
首次安装后，怎样导入订阅并确认配置已启用？
在客户端的订阅或配置页面选择从链接导入，粘贴服务提供方给出的完整地址，下载成功后把该配置设为当前配置。订阅列表出现一条记录，只说明链接已保存，不一定表示内核已经加载。接着检查代理组中是否有节点、内核日志是否报告解析失败，再选择节点并开启需要的代理入口。不同客户端的按钮名称略有差异，应以当前界面为准。订阅地址通常包含访问凭据，不应放进公开截图、问题讨论区或不可信的在线转换服务。
订阅更新失败、链接失效或返回空内容，应该先检查什么？
先查看更新日志中的 HTTP 状态与错误类型。401 或 403 可能与授权、链接有效期或服务端访问策略有关，404 应核对地址是否变更；超时则先确认本机能否访问订阅服务器。部分客户端支持选择订阅更新走直连还是代理，可在已有可用连接时做对照测试。下载成功但无法解析，可能是返回了登录页面、错误提示或不兼容格式，应向提供方确认适用的 Clash 或 mihomo 订阅。保留可用配置备份，不要在失败后立即删除原配置，也不要连续高频刷新。
TUN 开启失败，提示权限不足或服务未安装怎么办？
先确认当前客户端与系统支持其所用的 TUN 实现，再按客户端说明安装服务组件或授予所需权限。Windows 常见方式是启用客户端提供的服务模式；macOS 可能需要管理员授权或批准相关网络组件；Android 首次开启通常需要确认 VPN 连接请求；Linux 则取决于服务权限和虚拟网卡设备是否可用。授权完成后重新启动内核并查看日志，不要只反复点击开关。如果设备已有其他 VPN 正在运行，应先停止冲突连接；受管理设备需遵守管理员的权限策略。
设置了 Clash 开机自启，为什么登录后仍不能连接？
开机自启、启动内核和开启系统代理是不同设置，应用启动不一定会自动启用代理入口。先确认客户端自启任务没有被系统启动项管理禁用，再检查当前配置是否保留、代理组是否仍指向有效节点。依赖服务模式的 TUN 还需确认后台服务正常启动。若问题只出现在刚登录时，可能是网络尚未就绪或其他 VPN 随后改写路由，可等网络稳定后手动重试并比较日志。迁移客户端后应清理旧程序的自启任务，避免旧端口或代理设置被再次写回。
手动选择、自动测速和故障转移代理组有什么区别？
select 由用户明确选择一个成员；url-test 根据配置的探测地址与测试结果选择成员；fallback 通常按成员顺序选择可用项。自动策略的结果取决于测试目标、间隔、容差和节点可用性，不代表所有业务访问都会更快。组内还可能引用其他代理组，排查时应沿引用关系确认最终出站节点。需要固定出口的登录或会话场景可优先手动选择，避免策略变化带来出口切换。修改组类型或成员前先保存配置，并确认订阅更新是否会覆盖本地修改。
Clash 节点延迟很低，为什么网页或下载仍然慢？
延迟测试通常只测到指定地址的一次请求耗时，具体是否包含连接建立与 TLS 协商取决于实现；它不能直接代表带宽、持续吞吐或目标网站的响应速度。节点到测试地址与实际业务站点的路径也可能不同。应先确认浏览器连接确实命中了该节点，再用同一目标、同一网络与相近时间比较多个节点。下载慢还可能受服务端限速、丢包、拥塞或本地网络影响。不要仅凭一次测试淘汰节点，也不要把超时直接解释为节点永久失效，应结合连接日志与重复测试判断。
规则为什么没有命中，GEOIP 的 no-resolve 应该放在哪里？
规则一般按从上到下的顺序匹配，前面的宽泛规则命中后，后面的具体规则就不会再决定该连接。先在连接记录中核对域名、目标 IP、命中规则与最终策略，注意应用可能直连 IP 或复用旧连接。no-resolve 可用于支持该参数的 IP 类规则，例如 GEOIP,CN,DIRECT,no-resolve，用来避免仅为匹配该规则主动解析域名；它并不是关闭整个 DNS 系统。具体域名规则应放在宽泛规则前，MATCH 兜底放在最后。修改后应重新建立连接再观察结果。
Windows 浏览器能连接，但 UWP 应用不能使用系统代理怎么办？
部分运行于 AppContainer 的 Windows 应用默认限制访问本地回环地址，因而无法连接监听在 127.0.0.1 的代理端口；但并非所有商店应用都属于这种情况。先检查应用是否遵循系统代理，以及内核中是否出现它的连接记录。确认属于回环限制后，可使用客户端提供的回环豁免功能，仅为需要的应用授予权限，并按提示以管理员权限操作。不要为全部应用批量放开限制。若改用 TUN，应重新验证该应用是否被路由接管，不能把回环豁免当作所有连接问题的通用修复。
系统代理显示已开启，但浏览器仍未走代理，如何定位？
先确认内核正在运行，再比较系统代理中的地址与端口是否和客户端监听设置一致。其他代理工具、浏览器扩展或企业网络策略可能覆盖系统设置，浏览器自身也可能使用独立代理配置。打开目标页面并观察客户端连接记录：完全没有记录时，优先检查流量入口、代理绕过列表和端口占用；有记录但走 DIRECT 时，应检查出站模式与命中规则，而不是继续切换系统代理开关。可重启浏览器以清除旧连接，再逐项停用冲突设置，不要同时运行多个接管系统代理的客户端。
节点全部超时或只有一个节点超时，检查顺序有什么不同？
全部节点超时时，先确认设备本身能正常联网、系统时间正确、订阅授权有效，再检查防火墙是否拦截客户端及测试目标是否可达。只有一个节点失败时，应对照其他节点，重点检查该节点的服务器状态、地址、端口与协议支持；涉及 QUIC 的协议还要确认当前网络是否允许所需的 UDP 通信。测试地址不可用也会造成批量失败，因此应结合实际访问和日志中的连接阶段判断。不要一开始就重装客户端，先区分名称解析失败、连接被拒绝与连接等待超时，才能缩小范围。
开启代理后部分域名打不开，怎样区分 DNS 与节点问题？
先在日志中查找解析失败、上游 DNS 超时或连接目标异常，再确认该请求是否进入内核，以及 DNS 查询由系统还是客户端处理。若只换节点就恢复，可能与节点到目标的路径有关；若换多个节点仍在解析阶段失败，应检查 DNS 上游地址、访问路径和配置兼容性。使用 fake-ip 时，部分局域网服务或应用可能需要按文档设置过滤规则。不要随意叠加多套 DNS 劫持设置，也不要长期用直接访问 IP 替代域名测试，HTTPS 证书与虚拟主机可能因此产生新的错误。
退出客户端后无法上网，应该如何恢复网络？
先检查系统是否仍指向客户端的本地代理端口；程序异常退出后，监听已停止但系统代理设置可能残留。可重新打开客户端，关闭系统代理与 TUN 后再正常退出，也可在系统网络设置中关闭不再使用的手动代理。若仍然异常，再检查后台服务、VPN 连接及 DNS 是否被其他工具接管。使用手动 DNS 的设备应恢复到之前记录的设置，不要直接删除不认识的虚拟网卡或路由。完成后重新连接网络并测试普通网站，只有常规恢复无效时，再按系统文档考虑网络重置。