一、Clash Meta、mihomo 和客户端是什么关系？

Clash Meta 是在 Clash 基础上发展的内核项目，后续使用 mihomo 名称。内核负责读取配置、处理代理协议、执行规则分流与 DNS 解析；桌面窗口、订阅管理、托盘菜单和系统代理开关，通常由图形客户端提供。下载了客户端，不等于已经获得可连接的代理节点。

排查问题时需要分别记录客户端版本、内核版本、操作系统版本。只说“Clash 最新版”无法判断配置兼容性。同一个客户端也可能在不同版本中集成不同版本的 mihomo。

  • 图形界面位置：先查看「设置」→「关于」中的客户端版本，再查看内核信息或启动日志。不同客户端的菜单命名可能不同。
  • 命令行位置：在 mihomo 可执行文件所在目录运行 mihomo -v；Windows PowerShell 可用 .\mihomo.exe -v。
  • 兼容性判断：出现“未知字段”或“不支持的代理类型”，先核对实际运行的内核，而不是反复重新导入订阅。

二、订阅从哪里来，为什么安装后没有节点？

订阅是由服务提供方或配置维护者提供的配置入口，常见形式是包含访问令牌的 HTTPS URL。客户端通过这个地址获取节点或完整配置。客户端本身负责加载与使用配置，不会自动分配服务器、账号或流量。

操作位置：到所使用服务的账户页面查找「订阅」或「Clash / Clash Meta」格式入口，再回到客户端的「订阅」或「配置」页面。优先使用明确支持 mihomo 的配置格式，避免把仅包含其他协议链接的文本直接当作完整 YAML。

订阅失效与节点连接失败不是同一种问题。前者发生在下载配置时，后者发生在配置已加载后的代理连接阶段。先确认客户端是否成功获得配置，再检查节点状态。

三、订阅怎样导入，更新后为什么没变化？

以 Clash Verge Rev 一类桌面客户端为例，常见流程是「订阅」→「新建」→选择远程订阅类型→填写 URL→保存。也有版本直接在订阅页提供链接输入框。关键不是按钮名称，而是完成下载、选中、应用三个动作。

  1. 复制完整订阅地址，检查前后是否混入空格或换行。
  2. 新建远程订阅并下载，确认没有 HTTP 错误或 YAML 解析错误。
  3. 选中刚导入的配置，切换到「代理」页面检查代理组是否出现。
  4. 手动更新一次，查看更新时间与日志；确认当前启用的不是另一份旧配置。

如果下载返回 401 或 403，检查令牌、账户状态和服务方限制；如果返回网页而不是配置，可能复制了登录页面地址。解析错误提示的行号对应下载结果，不一定对应本地覆写文件。

更新边界：直接修改订阅缓存中的节点或规则，下一次更新可能被覆盖。长期调整应放进客户端提供的覆写、合并配置或脚本功能，并检查最终生成的运行配置。

四、规则、全局、直连模式应该选哪个？

日常使用先选规则模式。配置中的 rules 按顺序匹配，命中后把连接交给对应策略。全局模式把进入内核的连接交给全局策略；直连模式则让进入内核的连接直接连接目标。这里的前提都是“流量已经进入内核”。

模式适用场景检查位置
规则 rule按域名、IP 等条件分流代理页面的规则目标组、连接详情
全局 global临时判断是否为分流规则问题全局策略当前选中的节点
直连 direct对照目标是否可以直接访问连接详情与目标网络可达性

操作位置：打开客户端「代理」页面或托盘菜单中的模式选择。切换全局后仍需给全局策略选择可用节点；若选中的是 DIRECT，连接仍然直连。全局模式也不等于所有应用都会自动经过代理。

五、7890 端口是什么，和节点端口有何区别？

7890 是配置示例中常用的本地代理监听端口，不是强制值，也不是远端服务器端口。配置为 mixed-port: 7890 时，同一个本地端口可接受 HTTP 代理和 SOCKS 代理连接。实际端口应以客户端运行配置为准。

本地监听配置片段
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

操作位置：查看客户端设置中的「端口」或「混合端口」，或在当前运行配置中搜索 mixed-port。不要把外部控制器端口当作代理端口；external-controller 提供管理接口，不能直接填到浏览器的 HTTP 代理地址中。

在 Windows 中可运行下面的命令查看本机是否有进程监听 7890。出现结果只证明有监听者，不代表它一定是当前客户端，需要继续核对 PID。

Windows PowerShell
netstat -ano | findstr ":7890"

若启动日志出现 address already in use，先退出其他代理进程，或修改本地监听端口，再同步修改依赖该端口的应用设置。

六、开了系统代理，为什么终端或游戏仍然不走代理？

系统代理是操作系统提供给应用的一组代理设置，不是强制流量接管。是否读取它，由应用自身决定。浏览器通常能够使用系统代理；命令行工具可能读取环境变量，也可能只接受自己的代理参数；部分游戏主要使用 UDP，不能仅靠普通 HTTP 系统代理解决。

操作位置：先开启客户端的「系统代理」，在 Windows 11 的「设置」→「网络和 Internet」→「代理」查看本地代理地址，再到客户端「连接」页面观察目标应用发起的连接。macOS 可在「系统设置」→「网络」→当前网络服务→「详细信息」→「代理」检查。

对终端先做单次显式测试，避免立即修改全局环境变量。下面的命令假定混合端口确实为 7890；Windows 使用 curl.exe 可避免部分 PowerShell 环境中的命令别名差异。

显式指定 HTTP 代理
curl.exe --proxy http://127.0.0.1:7890 --connect-timeout 10 -I https://example.com

macOS 或 Linux 将命令中的 curl.exe 换成 curl。如果显式指定成功、普通访问失败，优先检查应用是否读取代理设置，而不是重装内核。

七、TUN 模式什么时候需要开启？

TUN 通过虚拟网络接口与路由设置接入流量，适合不读取系统代理的程序，以及需要处理更多网络流量的场景。它不是节点加速开关，也不会自动修复订阅失效、服务器故障或错误分流。

操作位置：在客户端「设置」中的「TUN 模式」或「虚拟网卡」入口启用。Windows 客户端可能要求先安装服务模式或取得管理员权限；Android 通常通过系统 VPN 授权接入，不能直接照搬桌面菜单。

  1. 先在不开 TUN 的情况下，用显式代理确认节点可用。
  2. 记录当前系统代理、DNS 与其他 VPN 状态，再启用 TUN。
  3. 测试一个目标应用，并在「连接」中确认有对应记录。
  4. 若本地网络或公司 VPN 异常，先关闭 TUN 做对照，再检查路由冲突与绕过范围。

八、DNS 和 fake-ip 是什么，需要手动改吗？

DNS 负责把域名解析成地址。mihomo 的 DNS 模块还会参与域名与连接的关联。在 fake-ip 模式下，内核向应用返回虚拟地址，并保留它与域名的映射；这些地址并不是目标服务器的真实公网地址。

常见配置使用 198.18.0.1/16 作为 fake-ip 范围。看到该范围的地址，不应立刻判定节点被污染或服务器地址错误。应先确认当前是否启用了 enhanced-mode: fake-ip。

操作位置：查看当前运行配置的 dns 段，以及客户端的 DNS 覆写设置。浏览器单独启用的加密 DNS、系统 DNS 与内核 DNS 不一定是同一路径，因此仅看一次系统解析结果不能证明应用实际采用了哪个解析器。

  • 只有个别域名异常时，先查看连接日志里的域名、命中规则和解析错误。
  • 依赖真实地址的局域网服务，可按实际域名评估 fake-ip-filter，不要一次加入过大的排除范围。
  • 修改 DNS 后重新建立应用连接；旧连接或应用缓存可能继续保留此前结果。

九、自定义规则放哪里，为什么没有命中？

规则通常按从上到下的顺序匹配，MATCH 常作为最终兜底。下面是规则片段，不是可以单独启动的完整配置。它让示例域名直连，其余连接交给名为「代理选择」的策略；这个策略必须已在 proxy-groups 中定义。

规则配置片段
rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,代理选择

操作位置：在客户端的配置覆写入口添加规则，再查看合并后的运行配置，确认新规则位于兜底规则之前。编辑后重新加载配置，在「连接」页面检查规则类型、策略链和实际出口。

若始终不命中，依次检查三件事：当前是否处于规则模式；应用实际连接的域名是否与预期一致；流量是否进入了这个客户端。IP 连接、应用自己的解析行为，以及已有长连接，都可能影响观察结果。

使用 rule-providers 时，还要确认规则集已成功下载，并且 rules 中存在对应的 RULE-SET 引用。声明规则集来源本身，不代表它已经参与匹配。

十、节点延迟正常却打不开网页，按什么顺序排查？

延迟测试通常只访问配置或客户端指定的测试地址。它能说明一条特定请求的结果，不能证明所有网站、UDP 或登录流程都正常。排查应沿着“配置→入口→规则→节点→目标”的顺序推进。

  1. 确认加载成功：查看「日志」，排除 YAML 解析失败、缺失策略组和端口占用。命令行用户可运行 mihomo -t -f config.yaml 检查配置；检查通过仍不等于远端节点可达。
  2. 确认流量进入：使用显式代理请求，再查看「连接」。若没有目标记录，检查应用代理地址、实际监听端口与 TUN 接管情况。
  3. 确认规则出口：查看连接命中的规则与最终节点。临时切换全局模式并明确选择同一个节点，比较结果。
  4. 确认目标差异：用同一节点测试两个不同网站。只有单个网站失败时，关注目标服务限制、DNS 与出口可达性。
  5. 保留有效证据：记录客户端与内核版本、错误时间、模式、目标域名和脱敏日志。完成一次测试后再修改下一项。

需要继续核对操作流程，可查看入门指南；需要按错误现象定位，可使用故障排查。反馈前先移除订阅令牌、节点认证信息和控制接口密钥。