Clash 常见问题

客户端负责配置导入、系统代理开关和连接记录等界面操作；mihomo 内核负责协议连接、DNS 解析与规则执行；订阅则是由服务提供方交付的配置或节点数据。安装客户端不会自动获得可用节点，也不会创建服务账户。排查时先区分界面问题、内核运行问题和服务问题：内核无法启动查日志，配置无法导入查格式，账户到期或节点停用则向订阅提供方确认。

Clash for Windows 已停止维护，迁移时应选择仍在维护且适配当前系统的客户端。先记录订阅地址、端口、规则模式与本地覆写内容，关闭旧客户端的系统代理并退出，再启动新客户端导入订阅。不要同时运行两个客户端接管网络，也不要直接复制旧程序目录覆盖新程序。迁移后先验证单个节点和常用应用，再逐项恢复自定义规则；旧配置中的实验字段应按新内核文档重新确认。

日常使用通常选择规则模式，让已进入内核的连接按规则顺序交给对应策略处理。全局模式把这些连接交给全局策略，适合短时对照排查；直连模式则让这些连接直接访问目标。模式不等于接管方式，切到全局也不会自动接管所有应用。先确认系统代理或 TUN 已覆盖目标应用，再比较模式差异。若全局可用而规则模式失败，应检查命中的规则和策略组，而不是直接重装客户端。

系统代理只影响遵循系统代理设置的应用，不能保证覆盖游戏、部分命令行工具或自行建立连接的软件。有些浏览器扩展还会覆盖系统代理。先在客户端连接记录中查找目标应用的新请求；看不到记录时，优先检查应用内代理、扩展设置与接管方式，而不是更换节点。需要更广的流量覆盖时可评估 TUN，但仍要检查路由、排除项和平台限制。连接进入内核后，也可能因规则选择而直接访问。

在客户端的配置或订阅页面使用 URL 导入入口，粘贴服务提供方给出的完整地址，保存后等待下载和解析完成。导入成功不一定代表已切换使用，还应把该配置设为当前配置，确认策略组出现并选择可用策略。随后开启一种接管方式，访问目标网站并查看连接记录。订阅地址可能包含账户凭据，不应发布到截图、公开日志或群聊中；如果地址已泄露，应到提供方后台重置后重新导入。

完整 Clash YAML、节点集合与 Base64 编码的分享链接列表不是同一种格式。完整配置通常包含代理、策略组和规则；单独的节点列表可能需要作为代理集合引用，不能直接当主配置加载。Base64 仅是一种编码方式，不代表内容天然兼容当前客户端。优先向订阅提供方索取适配 Clash 或 mihomo 的配置地址，并确认协议支持情况。不要把带账户信息的订阅交给不明转换网站，格式报错也不应通过反复更换端口处理。

先确认内核正常运行，再按客户端提示安装或启动服务模式，并完成系统授权。Windows 通常需要管理员权限或已正确安装的后台服务；macOS 需要按提示授权相关网络组件；Linux 通常需要访问 TUN 设备并具备网络管理权限。检查是否被安全软件拦截，以及其他 VPN 是否正在接管路由。不要给来源不明的程序提权，也不要长期关闭系统防护。授权完成后重启相关服务；仍失败时记录创建网卡阶段的日志再排查。

部分处于 AppContainer 沙箱中的应用受本地回环限制，无法直接访问客户端监听的本机代理端口。先确认浏览器能通过同一代理访问，再判断是否只有特定应用失败。若客户端提供回环豁免工具，可在了解用途后只为目标应用启用豁免，并按提示完成管理员授权；没有该工具时可查阅 Windows 的 CheckNetIsolation 用法。并非所有商店应用都受同样限制，若已启用 TUN，应先查看连接记录与路由，不要重复添加无关豁免。

先确认当前配置加载成功、内核正在运行，再查看系统代理是否指向正确的本机地址和监听端口。端口应与客户端实际生效的 mixed-port 或 HTTP 端口一致，不应填写 SOCKS 专用端口作为 HTTP 代理。检查浏览器扩展、应用内独立代理和系统绕过列表，然后重新发起请求观察连接记录。若记录显示 DIRECT，说明请求可能已进入内核但被规则分配为直连，应检查命中规则；若完全没有记录，再继续检查接管设置。

规则按从上到下的顺序匹配，具体规则应放在兜底 MATCH 之前，并指向当前配置中真实存在的策略组或内置策略。优先使用客户端提供的覆写、合并或持久化规则入口，直接改订阅生成的文件可能在更新后丢失。保存后重载配置，再通过连接记录检查实际命中的规则。已有连接可能继续使用旧策略，必要时仅关闭目标连接后重试。若使用域名规则，还应确认该连接的目标域名能够被内核识别。

客户端常见的延迟测试主要反映到指定测试地址的一次连通情况，不等同于下载速度，也不保证所有网站可用。先确认测试地址本身能够访问，再对同一批节点使用相同条件测试，避免同时运行大量测速影响结果。日常选择应结合目标网站访问、连接稳定性与服务提供方的流量限制。延迟较低但业务失败时，检查目标网站限制与协议兼容性；测试超时而实际访问正常时，则应先排查测试地址和超时参数。

修改 DNS 字段后应重载配置，并确认客户端没有用界面设置或覆写内容覆盖这些字段。检查日志是否存在上游解析失败，再按客户端支持的方式清理 DNS 缓存并重新建立目标连接。更新 GeoIP 或其他地理数据时，应使用当前内核支持的数据格式和配置路径，完成后确认加载成功。GeoIP 影响的是相关 IP 规则，不会自动修复域名解析。若问题只出现在特定域名，应同时检查 DNS 结果、匹配规则与策略选择。

先保留仍可用的当前配置，避免反复删除后失去排查依据。401 或 403 通常与授权、地址凭据或访问限制有关；404 可能表示地址已变更，但应以提供方说明为准。若返回 HTML，常见原因是复制了登录页面地址，或请求遇到网页验证。到提供方后台重新复制专用订阅地址，核对账户期限和流量，再尝试手动更新。不要公开完整响应和订阅地址；若只是网络超时，应先检查更新请求所走的网络路径。

先确认关闭接管后基础网络可用，再检查设备时间、账户状态和订阅更新结果。随后只选一个节点，发起一次目标请求并查看同一时段的日志：区分域名解析失败、连接拒绝、握手失败与测试地址超时。若全部节点来自同一服务，可向提供方确认服务状态；若仅一种协议失败，应检查内核是否支持及参数是否完整。不要同时改 DNS、端口和规则，否则难以定位原因。分享日志前删除订阅凭据、节点密码及其他账户信息。

先在日志中确认是监听失败，再用 Windows 的 netstat 或 macOS、Linux 的 lsof 查看 7890 的占用进程，避免直接结束未知系统进程。若是旧客户端仍在运行，先正常退出；若端口确需保留，可在当前客户端的端口设置或有效配置中修改 mixed-port，选择未占用的端口后重载。订阅文件可能受覆写控制，应以实际运行值为准。修改后同步调整系统代理、浏览器和命令行工具中的端口，确认日志不再出现监听错误。

常见原因是系统仍指向已停止监听的本机代理。优先重新打开客户端，关闭系统代理与 TUN 后正常退出，再检查系统网络设置是否残留手动代理。如果应用设置了独立代理或命令行配置了代理环境变量，也要分别恢复。使用过 TUN、手动 DNS 或其他 VPN 时，应核对路由与 DNS 是否恢复，必要时重新连接网络。不要一开始就执行网络重置或删除全部网卡；先保留当前设置记录，按代理、DNS、路由的顺序逐项排除。