Clash 常见问题

客户端负责订阅管理、模式切换和系统集成；内核负责解析配置、匹配规则并建立连接。mihomo 是从 Clash Meta 延续而来的内核项目，界面名称与内核名称不一定相同。订阅则是配置内容的远程来源，通常由服务提供方维护。安装客户端不会自动获得可用订阅，遇到问题时应先确认是界面操作、内核报错还是订阅内容异常。

订阅链接用于重新获取远程内容，本地 YAML 是保存在设备上的配置快照。远程订阅更新后可能替换原有代理条目、代理组或规则；本地文件通常需要手动修改或重新导入。有些链接只返回代理条目，需要作为代理提供者接入完整配置，不能直接当作完整 Profile 使用。导入前应确认客户端要求的格式，并保留当前能正常使用的配置副本。

日常使用通常先选规则模式，让连接按当前配置的规则进入对应策略。全局模式把进入内核的连接交给全局策略组处理，仍需在该组选择可用出口；直连模式则让进入内核的连接直接访问目标。模式只影响已被客户端接管的流量，不代表设备上的所有应用都已接入。排查时可短暂切换全局模式作对照，确认后恢复规则模式，避免误把规则问题当成节点故障。

系统代理向操作系统登记 HTTP 或 SOCKS 代理入口，主要服务于遵循该设置的应用。TUN 模式通过虚拟网络接口接管符合路由条件的流量，更适合不读取系统代理的程序，但需要相应权限、路由和 DNS 配合。首次配置建议先只启用系统代理验证，再按实际需求测试 TUN。两者可以在部分客户端中同时开启，但并非必需，排查时应分开测试以减少变量。

Fake-IP 模式会向应用返回配置地址池中的映射地址，内核再借助映射记录识别域名并处理连接，因此 DNS 查询结果可能不是目标的真实地址。这本身不表示解析失败。少数局域网服务或依赖真实地址的程序可能不兼容，应针对相关域名配置例外，而不是直接扩大排除范围。修改 DNS 模式后需按客户端要求重新加载，并处理系统和应用保留的旧 DNS 缓存。

在配置或订阅页面确认新条目已经下载成功，再执行选择、启用或设为当前配置；不同客户端的按钮名称可能不同。保存订阅地址不等于内核已经加载该配置。随后查看日志中的加载结果和代理组页面。如果下载成功却没有代理组，检查内容是否只有代理条目，或者格式与客户端不兼容。先保留旧配置，不要连续重复导入同一地址，以免混淆当前启用的条目。

先检查设备时间、普通网络连接和订阅地址是否完整，尤其注意复制时附带的空格或换行。再查看更新日志：401 或 403 常与授权或访问策略有关，404 可能是地址失效，超时则需要检查访问路径。状态码只能作为线索，应以提供方说明为准。若客户端支持订阅下载代理，可分别测试直连与已有可用代理；仍失败时向提供方确认链接状态，不要把含凭据的完整地址公开。

先记录日志指出的字段、代理类型和行号，再确认客户端实际运行的内核及版本。较新的配置可能使用旧内核不支持的协议或参数，界面更新也不一定代表内核同步更新。若是手动编辑，检查 YAML 缩进、冒号后的空格和列表层级，避免使用制表符。优先让订阅提供方输出兼容格式，或选择支持该配置的客户端，不要盲目删除报错字段后直接覆盖原文件。

先查看客户端是否要求安装或启动服务模式，并通过操作系统的正常授权流程授予所需权限。Windows 常需确认后台服务状态，macOS 需留意系统授权提示，Linux 则要检查客户端文档中的权限与虚拟接口要求。随后查看日志是否出现权限不足、接口创建失败或路由冲突。不要把长期使用最高权限当作通用修复；应先关闭其他 VPN 或 TUN 程序，再按客户端文档恢复服务。

迁移前分别保存订阅来源、本地 YAML 和客户端覆写内容，必要时记录代理组选择与端口设置。先退出旧客户端并关闭其系统代理和 TUN，再在新客户端导入副本，确认所用内核支持配置里的协议与字段。不要直接复制整个应用数据目录，因为界面设置和数据库格式可能不同。新客户端完成配置加载、连接测试和重启验证后，再决定是否移除旧程序与旧配置。

在订阅条目的设置中查看自动更新开关和更新间隔，按照提供方建议安排频率；过于频繁的请求可能触发访问限制。远程订阅通常会重新下载内容，因此直接编辑下载文件存在被替换的风险。需要长期保留的规则或 DNS 调整，应优先放进客户端支持的覆写、合并或扩展配置中。更新后检查最终生效配置与日志，确认自定义内容仍然存在，而不只检查编辑页面。

手动选择组通常对应 select，由用户指定当前出口；自动测试组通常对应 url-test，按配置中的测试地址、间隔和容差进行选择。fallback 则侧重按顺序使用可用出口，不能简单理解为始终选择最快线路。测试结果反映的是到指定地址的探测情况，不等同于所有业务的实际体验。切换后应以新建连接验证，原有长连接可能仍保留之前的出口。

先在客户端确认允许局域网连接、监听地址和混合端口设置，再让同一可信网络中的设备填写电脑的局域网地址及对应端口。还需检查系统防火墙是否允许来自该网络的连接。只开启局域网监听并不会自动让其他设备使用代理，访问设备仍需配置代理或采用明确的网关方案。不要将代理端口暴露到公网，使用完毕应按需要关闭局域网访问并清理防火墙例外。

许多命令行程序只读取自身参数或 HTTP_PROXY、HTTPS_PROXY、ALL_PROXY 等环境变量，并不读取桌面的系统代理设置。先确认客户端本地监听地址与端口，再查所用工具支持的变量、代理协议和大小写约定；HTTPS_PROXY 的值也不一定使用 https 协议头。建议先在当前终端会话测试，不要立即写入全局启动文件。测试结束后移除临时变量，避免客户端退出后终端仍指向旧端口。

记录操作系统、客户端名称、内核版本、出错时间和可复现步骤，再截取对应时间段的加载或连接错误即可。分享前删除订阅完整地址、访问令牌、账号密码、私人域名及其他可识别信息。日志级别可临时提高以定位问题，完成后恢复常用级别。不要直接上传整个配置目录或未经检查的诊断压缩包；若需要展示 YAML，保留字段结构并把敏感值改成明确的教学假值。

先关闭代理确认基础网络可用，再检查订阅是否更新成功、当前代理组是否选择了有效出口。使用同一出口访问不同目标，并在条件允许时换一个网络作对照。日志若显示域名解析失败，应先查 DNS；若连接在建立阶段超时，则检查节点地址、端口和访问路径。内置测试只代表测试目标的结果，单个节点超时也不代表全部订阅失效，不宜一开始就重置所有设置。

先核对系统登记的代理地址、端口与客户端实际监听值是否一致，并确认内核正常运行。随后检查浏览器代理扩展、独立代理设置、PAC 和绕过列表，必要时在临时浏览器配置中作对照。打开客户端连接记录并发起一个新请求：完全没有记录时优先检查接管路径；有记录却走直连时再看命中规则。不要仅凭页面能否打开判断代理是否生效，也不要同时修改所有 DNS 与路由设置。

部分采用 AppContainer 隔离的 Windows 应用不能直接访问本机回环代理，因而会出现浏览器正常、特定应用失败的情况。先确认受影响应用确实使用本地代理，再查看客户端是否提供 UWP 回环或回环豁免工具。仅对需要的应用设置豁免，并按工具要求授权；也可按微软文档使用 CheckNetIsolation 检查。并非所有商店应用都受同一限制，若仍失败，还需继续检查账号、系统网络与防火墙。

先关闭 TUN 作对照，确认问题确实与虚拟接口或路由接管有关。再检查另一个 VPN、虚拟机网络或安全软件是否同时修改路由，并查看目标服务是否依赖局域网发现或专用 DNS。确有需要时，按所用内核与客户端文档为特定网段、接口或域名设置绕过，不要一次排除过大的地址范围。每次只调整一个项目并测试，工作网络的设置应先遵循网络管理员要求。

先检查操作系统是否仍保留指向本地端口的手动代理或 PAC 地址，并关闭已经失效的代理设置。若之前开启 TUN，可重新启动原客户端，先关闭 TUN 和系统代理，再正常退出，让程序执行清理。随后检查其他 VPN、终端代理变量和 DNS 设置是否仍在生效。不要直接删除网卡或重置全部网络；若基础网络仍异常，再依据系统诊断结果处理，并保留修改前的设置记录。