Clash 常见问题

客户端负责配置导入、策略选择和系统代理等界面操作，内核负责实际的连接、解析与规则匹配。Clash Meta 是相关内核项目曾使用的名称，mihomo 是其后续名称；旧教程中的 Meta 字样不一定指独立客户端。不同客户端集成的内核版本和配置管理方式可能不同，排查时应同时记录客户端名称与内核版本，不能仅凭界面相似判断字段是否受支持。

安装客户端只是准备了流量处理工具，还需要可用的代理配置或订阅，以及能够访问对应服务器的网络环境。导入后先检查配置是否包含代理节点和策略组，再选择一个节点测试，最后开启系统代理或按需启用 TUN。客户端显示运行中只代表内核已启动，不代表订阅有效、节点可达或目标网站一定能打开；这几个环节需要分别确认。

日常使用通常从规则模式开始，让连接按照配置中的规则进入对应策略。全局模式将内核接收到的连接交给全局策略，适合短时间对照排查，但不会自动接管所有应用流量。直连模式主要用于确认本地网络是否正常。切换模式后要新建连接再测试，已有长连接可能继续沿用原策略；全局模式恢复正常也只能说明规则或分组值得检查，不能据此判定具体故障。

已有安装可能仍能运行，但归档客户端不会持续获得兼容性修复与安全更新，新配置字段和新协议也可能无法识别。准备迁移时先备份订阅来源、策略选择和本地规则，再在受维护的客户端中逐项导入。不要直接覆盖整个旧程序目录，也不要同时启动两个客户端接管网络。首次迁移先验证系统代理与基本连接，再恢复 TUN、覆写和其他自定义设置。

订阅地址常携带访问凭据，获得完整链接的人可能读取节点信息或消耗对应服务资源。提交截图和日志前，应遮盖订阅路径、查询参数、节点密码及控制接口密钥，不要只隐藏账户名称。需要转换订阅时优先使用服务方提供的兼容格式，或在可信的本地环境处理；向陌生转换站提交链接等同于交出配置访问权。链接泄露后应到服务方后台重置，而不只是删除公开消息。

先确认账户套餐、到期时间和流量余额，再从服务方后台重新复制完整链接，排除空格、换行及链接截断。查看错误属于请求超时、访问被拒绝还是配置解析失败：访问被拒绝通常要检查授权，返回网页则可能是登录页或错误页。若链接只能通过代理访问，可在已有可用连接下更新，或使用服务方允许的替代入口。不要反复高频请求，以免触发限流。

先在系统信息中查看处理器架构和系统版本，再选择下载项。常见的 x64 或 AMD64 面向常规英特尔、AMD 桌面处理器，ARM64 面向对应的 ARM 设备；macOS 还需区分 Apple Silicon 与 Intel。安装提示格式不支持时，先核对平台与架构，而不是反复修改文件后缀。系统最低版本、依赖组件和服务安装要求由具体客户端决定，应以下载页说明及安装提示为准。

先关闭 TUN，确认系统代理下基本连接可用，再按客户端说明安装服务模式或授予创建虚拟网卡所需权限。Windows 可能需要管理员授权，Linux 可能涉及服务权限或网络能力，移动端通常需要确认系统 VPN 请求。授权后检查服务是否真正运行，并查看内核日志中的具体错误。若设备受单位策略管理，不应绕过限制；也不要长期用高权限运行所有无关程序来代替正确的服务配置。

mixed-port 用于接收 HTTP 与 SOCKS 代理连接，external-controller 则供管理界面调用，两者用途不同。给浏览器或终端设置代理时，应使用实际生效的混合端口，不能填写控制端口。先在客户端检查监听地址和端口，再到应用中填写相同值；仅本机使用时优先监听回环地址。修改后需让内核重新加载配置，并同步更新手动设置过代理的应用，避免仍连接旧端口。

订阅文件通常由远端内容整体更新，直接编辑下载得到的配置可能在刷新时被覆盖。应使用客户端提供的覆写、合并或本地规则功能，把个人调整与订阅主体分开管理；这些功能的字段和合并顺序因客户端而异。保存后检查运行中的最终配置，而不只看编辑器内容。建议先加一条容易验证的规则，确认位置和目标策略正确，再逐步迁移其余设置，并保留可恢复的备份。

延迟测试通常只反映到指定测试地址的一次请求耗时，不能等同于持续带宽。实际速度还受线路拥塞、服务器负载、目标站限制和本地无线网络影响。比较节点时应在相近时间访问相同目标，分别观察网页响应和持续传输表现，避免同时运行多个测速任务。若只有某个站点慢，应先检查该站点的规则命中与连接路径；不要仅按最低毫秒数判断节点适合所有用途。

打开客户端的连接列表或日志，重新访问目标网站，按域名筛选新连接，再查看命中的规则、策略组和最终出站。规则通常自上而下匹配，前面的宽泛规则可能先于后面的精确规则生效。修改后关闭对应旧连接或重新启动测试应用，避免复用原连接造成误判。一个网页可能请求多个域名，主站可访问但图片失败时，需要继续检查静态资源和登录接口各自的匹配结果。

部分客户端支持同时开启，但首次配置时最好先只验证一种接管方式。系统代理主要影响遵守系统代理设置的应用，TUN 通过虚拟网卡与路由接管符合条件的流量，两者并不等同。组合使用时需要检查路由、DNS 劫持和其他 VPN 是否冲突，避免循环转发。切换前记录原设置，先确认单独开启时的表现；出现异常后回到已验证的单一方式，比同时调整多个开关更容易定位原因。

更新前记录当前配置名称、策略组选择和本地覆写，并备份需要保留的文件。订阅更新与规则库更新是不同操作：前者可能更换节点或策略组，后者主要改变匹配数据。更新后先确认配置加载成功，再检查常用网站和本地服务；若节点被更名，原策略选择未必能恢复。自动更新间隔应结合服务方建议，不必设置得过密。出现问题时保留报错和更新时间，再决定是否恢复备份。

出口 IP 只能说明某次连接的出站位置，不能证明 DNS 查询采用相同路径。先检查运行配置中的 DNS 服务、上游解析与路由设置，再留意浏览器安全 DNS、系统加密 DNS 和其他 VPN 是否另建解析通道。测试网站显示的解析器位置也不一定等于真实查询路径，应结合日志和必要的抓包分析。调整后清理相关缓存并建立新连接，避免把旧解析结果误认为当前配置仍有问题。

先关闭代理确认基础网络可用，再核对订阅是否过期、节点是否实际加载以及系统时间是否准确。随后选择少量节点手动测试，观察日志是域名解析失败、连接被拒绝还是握手超时。若只有统一的测试地址不可达，测试超时不一定代表所有目标都不可访问，可用实际网站交叉验证。若不同网络下仍全部失败，应向服务方核实节点状态，避免同时修改 DNS、规则和端口导致证据混乱。

先核对系统代理地址与客户端实际监听端口，确认内核正在运行，再检查浏览器是否启用了独立代理扩展、手动设置或组织策略。观察访问时是否出现新连接：没有记录通常应先查流量是否进入客户端，有记录则继续检查命中策略和节点。终端、游戏等应用可能不读取系统代理，需要单独设置或使用 TUN。排查时一次只保留一个代理工具，防止其他程序反复覆盖系统设置。

部分 UWP 应用受到应用容器回环限制，可能无法连接监听在本机回环地址的代理。先确认普通浏览器可用，并核实该应用确实使用这条代理路径，再按客户端文档对指定应用添加回环豁免；操作可能需要管理员权限。不要为所有应用批量放开，也不要仅凭应用来自商店就认定原因相同。若应用根本不读取系统代理，还需检查其网络机制，或在权限允许时用 TUN 进行对照测试。

先确认冲突的是混合代理端口还是控制接口端口。Windows 可用 netstat -ano 查监听与进程编号，Linux 可用 ss -lntp 查看，具体进程信息可能需要额外权限。识别占用者后再决定关闭重复客户端，或为当前配置选择空闲端口；不要直接结束不认识的系统进程。修改后重新加载配置，并同步应用代理地址。若每次启动都冲突，还应检查旧服务和开机启动项是否仍在后台运行。

连接期间先按订阅、节点、模式、流量接管、DNS 的顺序检查，用连接记录区分请求未进入内核和进入后失败。退出后断网则优先检查系统代理是否仍指向已停止的本机端口，以及 TUN 或其他 VPN 是否留下路由影响。先通过客户端正常关闭代理与 TUN，再检查系统网络设置；必要时重启相关应用。保留日志后再做重置，避免一开始清空全部配置，使原本可定位的问题失去线索。