Clash 常见问题.

Clash 是代理内核及其配置生态的名称；原版内核已停止维护。Clash Meta 在原版基础上扩展了协议和分流能力，后来更名为 mihomo。Clash Verge Rev 等图形客户端提供订阅管理、托盘和系统设置界面，实际连接通常由内核处理。排查兼容性时，应同时记录客户端名称与内核版本，不能只看窗口标题里有没有 Clash。旧配置通常可以迁移，但新增协议、DNS 字段和 TUN 设置仍需按目标内核的文档核对。

日常使用先选规则模式，让连接按配置中的规则决定走直连还是代理。全局模式把内核接收到的连接交给全局策略组，适合短时间确认问题是否与规则有关；它并不表示系统里所有应用都已被接管。直连模式让内核处理的连接直接访问目标，可用于对照测试。切换模式后还要检查相应策略组选中了什么，因为全局组也可能选中 DIRECT。已有连接可能继续沿用原路径，测试时应重新建立连接。

系统代理把本地代理地址写入桌面环境或操作系统设置，主要影响愿意读取这些设置的应用，一般不需要创建虚拟网卡。TUN 通过虚拟接口和路由接管更多连接，适合不遵循系统代理的程序，但通常需要服务组件或额外授权。两者都不能保证所有流量必然经过代理，具体还受路由、排除项和应用行为影响。建议先用系统代理确认订阅和节点可用，再按实际需要启用 TUN，避免同时改动多个环节后难以定位问题。

订阅链接通常包含账户标识或访问凭据，持有链接的人可能读取节点信息，因此不适合直接贴到论坛、聊天群或公开截图里。需要协助时，提供客户端名称、内核版本、报错时间和经过遮盖的日志即可；节点密码、订阅地址及控制接口密钥也应隐藏。客户端本身不提供节点账户，订阅有效期、流量和服务状态需要向订阅提供方确认。若链接已经公开，应在提供方后台重置地址，再更新客户端中的订阅记录。

打开客户端的配置或订阅页面，选择通过链接新建配置，粘贴提供方给出的完整地址，下载成功后再将该配置设为当前使用。各客户端按钮名称可能不同，关键是区分下载配置与启用配置这两个动作。若提示缺少字段或解析失败，先确认提供方提供的是 Clash 或 mihomo 兼容格式，而不是网页登录地址或其他客户端专用格式。优先索取匹配格式；确需转换时，先了解转换服务能否读取完整订阅，避免将私人链接交给来源不明的在线服务。

先确认客户端已经按自身说明安装并启动服务组件，再查看日志中是否出现虚拟接口创建失败或权限被拒绝。Linux 通常还需要可用的 TUN 设备，可检查 /dev/net/tun 是否存在；容器和受限虚拟环境可能没有开放设备或相应网络权限。不要直接把整个图形客户端长期以管理员身份运行，也不要随意放宽设备权限。服务状态正常后再启用 TUN，若仍失败，记录发行版、安装格式和错误原文，按该客户端的授权流程逐项核对。

先确认软件包与发行版、处理器架构相符：DEB 通常用于 Debian、Ubuntu 系列，RPM 通常用于 Fedora 等发行版，不能只按文件名里有 Linux 就安装。查看 uname -m 的结果，区分 x86_64 与 aarch64。启动失败时从终端运行客户端，保留缺失依赖或沙盒相关的错误信息。便携格式还可能依赖系统运行组件，具体以项目说明为准。不要先关闭系统安全机制；优先使用发行版适配的包，并通过下载页确认当前提供的安装格式。

部分运行在 AppContainer 中的 Windows 应用受回环访问限制，即使系统代理已指向本机端口，也可能无法访问本地代理服务。这时可使用客户端提供的回环豁免工具，只为确实需要的应用添加授权；执行过程可能要求管理员确认。并不是所有商店应用都属于同一种运行模型，也不是所有连接失败都由回环限制引起。操作前先确认普通浏览器能使用代理、目标应用确实读取系统代理；若采用 TUN 接管，也应重新测试，而不是一律批量放开全部应用。

延迟测试通常只是向指定测试地址发出请求，反映某一时刻的响应情况，不等于持续下载速度，也不能代表所有网站的表现。先确认测试地址和实际目标是否相近，再固定一个节点，用同一网站、同一网络进行对照。网页加载还受 DNS、目标服务器、丢包和连接复用影响；频繁批量测速本身也会增加连接负担。选择节点时可以先看延迟是否稳定，再观察实际页面加载与文件传输，不必只追求列表里最低的一个数字。

规则通常自上而下匹配，先检查客户端当前是否处于规则模式，再查看连接记录里实际命中的规则与策略组。自定义规则应位于会提前匹配的宽泛规则之前，尤其不要放在 MATCH 后面。随后确认使用的是域名规则还是 IP 规则，以及内核是否拿到了域名信息。修改配置后重新加载，并重建目标连接；旧连接不一定改变路径。若订阅更新会覆盖编辑内容，应使用客户端支持的覆写或合并功能保存本地规则，而不是反复改下载得到的原始文件。

先区分远程订阅文件与客户端提供的本地覆写层：前者更新时可能整体替换，后者才适合保存端口、规则和个人策略调整。设置自动更新前，确认客户端是否支持覆写合并，以及列表字段是追加还是替换。笔记本休眠或客户端未运行时，定时任务可能无法准时执行，恢复后是否补更也取决于实现。更新后检查当前配置、策略组选择和日志，确认加载成功。备份时保留覆写文件与配置关系，同时妥善存放包含私人订阅地址的备份。

很多命令行工具不会自动读取桌面系统代理，需要单独配置代理环境变量或工具自身的代理选项。先在客户端确认本地监听地址和实际端口，再在当前终端临时设置 HTTP_PROXY、HTTPS_PROXY 或工具支持的 ALL_PROXY；不要照搬其他人的端口。不同工具对变量大小写、SOCKS 和域名解析位置的支持存在差异，应按工具文档选择。测试成功后再考虑持久化配置，若取消代理也要清理旧变量和 Git 专用设置，避免客户端退出后终端仍访问失效的本地端口。

先记录报错类型，再确认系统时间、当前网络和订阅提供方的账户状态。401 或 403 常与访问授权、链接状态或提供方限制有关，404 可能是路径变更，不能单凭状态码断定原因；超时和 TLS 错误则需要继续检查网络、证书与设备时间。若返回内容变成登录页面，说明拿到的不是配置文件。对照客户端是否设置了通过代理更新订阅，避免更新依赖一个已经失效的节点。不要立即删除最后一份可用配置，先保留备份，再向提供方确认地址是否需要重置。

先关闭代理验证基础网络，再检查订阅是否有效、设备时间是否正确，以及当前配置是否真正加载。选一个节点查看连接日志，区分域名解析失败、连接超时、握手失败和认证失败；这些错误对应的处理方向不同。若仅测速超时而实际网站能访问，先更换测试地址再判断。若多个节点都无法建立连接，可换一个网络进行对照，并暂时退出其他 VPN 或网络过滤工具，避免路由冲突。保留一条具体错误比反复重装更有帮助，也不要同时更改 DNS、TUN 栈与节点协议。

先确认内核正在运行、本地代理端口与系统设置一致，再在客户端连接记录中观察目标应用是否出现。没有记录时，应用可能不读取系统代理，或保留了自己的代理设置；有记录但走直连时，应检查命中的规则和策略选择。Linux 的不同桌面环境、浏览器与终端对代理设置的读取方式并不相同。客户端异常退出后，还可能留下指向已关闭端口的系统代理，此时先关闭系统代理恢复网络，再重新启动客户端。只有确认应用接管范围不足时，再考虑 TUN，而不是同时叠加多个代理工具。

这通常提示解析链路值得检查，但直接访问 IP 与访问域名可能使用不同的证书和虚拟主机，因此不能仅凭一次测试下结论。先用系统解析工具查看目标域名能否解析，再对照内核日志中的 DNS 请求和错误。检查是否同时启用了浏览器安全 DNS、系统加密 DNS及客户端 DNS 接管，确认每个环节实际使用哪条路径。修改配置后清理相关缓存并重新连接；使用 fake-ip 时尤其不要混入来源不明的设置。先恢复客户端默认 DNS 配置做对照，再逐项加回自定义项。