Clash 常见问题

客户端负责订阅管理、系统代理开关和连接界面，内核负责协议连接、DNS 处理与规则匹配。Clash Meta 是基于原版 Clash 延伸的内核分支，后来更名为 mihomo；客户端名称包含 Clash，不代表使用相同内核。判断配置能否运行，应先在关于或内核设置中确认实际内核，再查其支持的字段与协议。迁移时保留原配置备份，不要只根据界面相似程度判断兼容性。

安装客户端只完成本机软件部署，通常还需要导入有效订阅或自行维护的配置。订阅提供节点地址、认证信息和策略组等内容，客户端本身不会自动产生这些连接资源。导入后应确认配置已启用、策略组有可选项，再选择节点测试访问。若页面显示空列表，先检查订阅响应内容与格式，不要把系统代理开关反复切换当作修复手段。订阅的有效期和额度由提供方决定。

旧配置可能仍能运行，但客户端已停止维护，不能据此推断它支持后来新增的协议与字段。迁移到 Clash Verge Rev 等客户端前，先记录订阅地址、策略组选择、端口和自定义规则，再逐项导入验证。新客户端能解析文件，不等于所有行为都与旧环境相同，尤其要检查 DNS、TUN 和覆写设置。确认新环境正常后再关闭旧客户端，避免两个代理进程同时修改系统设置。

规则模式按配置中的规则顺序决定连接去向；全局模式通常把进入内核的连接交给全局策略组；直连模式则让进入内核的连接直接访问目标。三者改变的是内核收到连接后的处理方式，不会自动让所有应用都把流量送进内核。初次使用建议选择规则模式，并在连接页面核对命中的规则。排查时可短暂切到全局模式作对照，但测试结束后应恢复原模式，避免改变其他应用的访问路径。

iOS 可从下载页进入 Clash Plus 的 App Store 页面，并通过其官网 clashplus.io 查看产品说明。订阅是否通用取决于客户端支持的协议与配置格式，不能仅凭订阅名称判断。导入前确认提供方给出的链接类型，导入后检查节点和策略组是否完整。桌面端的脚本、文件路径和部分 TUN 字段不适合直接搬到手机；如提示字段不支持，应按移动端文档调整，而不是连续重复导入。

先确认设备时间正确、订阅地址完整，并检查账户是否到期或额度耗尽。查看客户端的更新错误：认证失败通常要核对链接凭据，超时要检查到订阅服务器的网络路径，格式错误则要确认返回的是配置而非登录页。若更新依赖当前已失效的代理，可在客户端允许的情况下改用直连更新。订阅地址可能包含访问凭据，不要提交给公开转换站或贴进截图；持续失败时向提供方询问服务状态。

先在操作系统的设备信息中确认处理器架构，再选择对应安装包。常见 Intel 与 AMD 桌面处理器通常使用 x64，ARM 设备应优先选 ARM64；Apple Silicon 与 Intel Mac 也应分别选择。Linux 还需区分发行版的软件包体系，不能只看处理器架构。安装提示系统不支持时，核对客户端发行说明中的最低系统要求，不要用更名文件扩展名或强行解压替代正常安装流程。

TUN 需要创建虚拟网卡并配置路由，桌面客户端通常通过服务模式或提权操作完成。先关闭 TUN，在客户端设置中检查服务是否已安装并运行，再按该客户端说明授权；Linux 的服务与权限配置应以发行方式为准。企业设备可能限制驱动和路由修改，此时需要管理员确认策略。不要长期关闭防火墙来绕过错误，也不要同时启动多个接管路由的工具；记录具体报错后再决定是否重装服务。

系统代理只是向遵循该设置的应用提供代理地址，部分程序使用自己的代理配置，已有连接也可能继续复用。先核对系统设置中的地址和端口是否与客户端混合端口一致，再重启目标应用，并在客户端连接页面观察是否有新请求。浏览器扩展、命令行环境变量或其他代理工具可能覆盖系统设置。若应用确实不遵循系统代理，可评估 TUN；不要在未确认流量入口前直接修改节点或分流规则。

部分使用 AppContainer 隔离的 Windows 应用默认不能访问本机回环地址，因此可能无法连接监听在本机的代理端口。先确认受影响的是这类应用，并检查客户端是否提供回环豁免管理；按需为目标应用启用，而不是批量放开全部应用。并非所有商店安装的程序都属于同一隔离模型，普通桌面程序不应套用此结论。若选择通过 TUN 接管，也要重新核对连接记录，确认请求确实进入内核。

打开客户端的连接页面，再从目标应用发起一次新请求，按域名或进程定位连接，查看规则、策略组和实际出口。已有长连接可能保留原策略，因此修改规则后应重新建立连接再判断。规则通常按顺序匹配，靠前的宽泛规则可能覆盖后面的精细规则；还要确认当前确实处于规则模式。日志中仅出现域名解析记录不代表业务连接已走代理，应结合连接详情与应用访问结果一起判断。

订阅更新通常会重新下载并替换配置，直接编辑下载文件的修改不一定被保留。需要长期使用的规则、DNS 设置和策略组调整，应放到客户端支持的覆写或配置合并功能中，并确认合并顺序。不同客户端对数组追加、字段覆盖和脚本执行的处理可能不同，不能照搬其他软件的写法。先用少量规则测试，再查看合并后的有效配置；迁移客户端时同时备份覆写内容，而不只是复制订阅链接。

Fake-IP 先向应用返回虚拟地址，再由内核根据映射恢复域名并建立连接，有助于保留域名信息参与分流。某些局域网服务或依赖真实地址的应用可能不适合这种响应，应按实际故障把相关域名加入适当的过滤配置，而不是把全部域名排除。修改后需要让应用重新解析域名并重建连接。具体过滤行为取决于内核版本与过滤模式，复制配置前先阅读对应版本说明，避免反向理解匹配结果。

延迟测试通常只反映到特定测试地址的一次请求耗时，不等于大文件吞吐量，也不能代表所有目标网站。先使用同一设备、同一目标和相近时间比较不同节点，再看是否只有某条线路或某个应用变慢。随后检查丢包、服务器负载、策略组出口与本机网络占用。测速期间暂停其他大流量任务，避免并发测试相互干扰；若直连同样缓慢，应先排查本地无线网络或接入线路，而不是只调整客户端。

先观察中断是否稳定发生在锁屏或切换网络之后。Android 可检查客户端的后台运行权限、电池优化策略和系统 VPN 设置；不同厂商还可能有额外的后台限制。iOS 应检查客户端的 VPN 状态和日志，不要把所有中断都归因于后台进程。若亮屏时也失败，再检查订阅有效期和节点连接。协议保活、重连频率及网络质量都会影响耗电，不能只依据协议名称判断某个配置一定更省电。

不一定。测试地址不可达、DNS 异常、本机时间错误或内核未正常运行，都可能造成统一超时。先确认普通网络可用，再检查日志中的错误类型，选择一个节点进行实际访问对照。若只有延迟测试失败而网页正常，可核对测试地址与测试方式；若实际连接也失败，再检查认证、账户状态和服务器地址。不要一次更改 DNS、TUN 和规则，否则难以定位原因；每次只改一项并保留原值。

先确认没有旧客户端或重复实例仍在后台运行，再查看应用日志、服务日志或系统事件记录。端口占用时应查明监听进程，关闭重复代理或改用空闲端口，并同步更新系统代理和相关应用设置。若怀疑配置损坏，先备份配置目录，再按客户端说明临时使用新配置测试，不要直接删除全部资料。运行库或系统兼容性错误应按发行说明处理；提交通用报错截图时，遮盖订阅地址与认证信息。

先关闭 TUN 做对照，确认故障确实与路由接管有关。检查本地网段、企业 VPN 路由和虚拟网卡地址是否冲突，再根据内核与客户端支持的方式设置路由排除；仅添加直连规则不一定能解决流量进入错误网卡的问题。企业网络还可能需要内部 DNS，应同时核对名称解析路径。不要盲目照抄他人的网段排除列表，也不要同时开启多个自动路由工具；调整后分别验证公网、局域网和企业资源。

先明确预期：哪些域名需要由哪个解析器处理、请求应经直连还是代理，再结合内核日志与检测结果确认实际路径。检测页面显示的解析器地区或名称只能提供线索，不能单独证明泄漏。浏览器安全 DNS、系统加密 DNS 和其他 VPN 可能绕过客户端的 DNS 设置。TUN 的 DNS 接管也不等于自动接管所有加密解析流量；应分别检查应用设置、DNS 路由和代理出口，修改后重建连接再测。

先检查系统是否仍保留指向本机的代理地址；如果代理进程已经退出，该地址会成为不可用入口，应关闭残留系统代理。随后检查 TUN 或 VPN 是否仍连接，以及其他应用是否保留手动代理和环境变量。优先重新打开原客户端，关闭系统代理和 TUN 后正常退出，避免直接强制结束进程。仍有异常时再查看路由与 DNS 状态；不要把重置全部网络设置作为第一步，以免丢失企业网络和静态地址配置。