Clash 新手第一周最常问的十个问题：从订阅导入到系统代理一次讲清

一、客户端怎么选，Clash、Clash Meta 和 mihomo 是什么关系

问题 1：应该下载哪个 Clash 客户端

直接答案是：先按操作系统选择仍在维护、带图形界面的客户端，再确认其内核支持当前订阅使用的协议。Windows 与 macOS 新手优先选择能管理配置、系统代理和 TUN 模式的桌面客户端；Android 选择提供配置导入与按应用分流的客户端。首次使用不必同时安装多个客户端，同一台设备运行两个代理程序反而容易造成端口冲突。

“Clash”可能指原始 Clash 内核，也可能泛指采用 Clash 配置格式的客户端。原始项目已经停止更新，当前常见的新客户端多采用 mihomo 内核。mihomo 曾以 Clash Meta 为名称，配置结构延续 Clash YAML，并扩展了协议、规则集、DNS 和透明代理能力。看到“Meta 内核”或“mihomo 内核”时，可以将其理解为同一技术路线不同时期的名称。

• 只需要基本网页代理：图形客户端、规则模式、系统代理即可完成大部分操作。
• 需要游戏启动器、命令行或商店应用：选择支持 TUN 模式的客户端。
• 需要导入既有 YAML：确认客户端支持本地配置文件，而不只是订阅链接。
• 设备架构不同：Windows 常见为 x64 与 arm64，Apple Silicon Mac 应选择 arm64，Intel Mac 选择 x64。

二、订阅链接从哪里来，怎样正确导入

问题 2：客户端安装完成后为什么没有节点

Clash 客户端本身通常只负责读取配置、执行规则和转发连接，不会自动生成可用节点。节点信息来自用户自己的服务配置、组织内部配置，或网络服务提供方生成的订阅地址。订阅地址一般是一条以 HTTPS 开头的专用 URL，其中可能包含访问令牌，应按照账号凭据管理，不要发布在截图、论坛或公开代码仓库中。

典型导入路径是「配置」→「新建配置」→「从 URL 导入」，部分客户端使用「Profiles」→「New Profile」→「URL」。粘贴订阅地址后先执行下载，再将新配置设为当前配置。仅看到配置出现在列表里并不代表已经启用，还要确认该配置旁边出现“当前”“已选择”或选中标记。

1. 复制完整订阅地址，检查开头是否为 https://。
2. 进入客户端的「配置」或「Profiles」页面。
3. 选择「从 URL 导入」，粘贴地址并下载。
4. 选中新下载的配置，等待代理组与节点列表出现。
5. 进入「代理」页面，在目标策略组中选定节点。
6. 回到首页，开启「系统代理」，再进行浏览器访问测试。

问题 3：订阅导入失败或更新失败怎么处理

先区分“地址无法下载”和“下载后无法解析”。前者通常表现为超时、HTTP 401、403 或 404；后者通常会显示 YAML 解析错误、字段类型错误或配置校验失败。401 与 403 多半意味着令牌失效、账号状态变化或服务端限制，404 可能是地址已更换。解析错误则要检查订阅是否输出了 Clash 或 mihomo 可识别的配置格式。

首次导入时不要同时开启自动更新、配置覆写和脚本处理。先确认原始配置可以加载，再逐项增加功能。如果浏览器直接打开订阅地址后得到登录页面或 HTML 错误页，客户端同样无法把它当作 YAML 解析。订阅地址有效但客户端仍报错时，可以在「设置」→「日志」中把日志等级临时调到 debug，复现一次后查看具体失败阶段，排查结束再改回 info。

三、规则、全局与直连模式应该选哪个

问题 4：Rule、Global、Direct 有什么区别

Rule 规则模式按配置中的规则逐条匹配域名、IP、进程或规则集，再把连接交给指定策略组。它适合日常使用，也是多数订阅配置的默认模式。国内站点可以直连，需要代理的目标进入代理策略，局域网地址通常保持直连。

Global 全局模式把大部分连接交给名为 GLOBAL 的策略组，适合临时验证某个节点能否建立连接。它不等于所有流量一定离开本地网络，局域网、保留地址和客户端自身连接仍可能按内核规则处理。长期使用全局模式会绕过订阅设计好的分流逻辑。

Direct 直连模式让连接直接访问目标，不经过代理节点。它适合确认故障是否由代理链路引起，也适合临时停用转发。Direct 不是退出客户端；如果系统代理仍然指向本机端口，流量仍会先到客户端，再由客户端直连。

1. 日常使用选择「模式」→「规则」。
2. 进入「代理」→目标策略组，选一个延迟测试可用的节点。
3. 某个网站异常时，临时切换全局模式做对照。
4. 全局可用而规则模式失败，重点检查规则命中结果和策略组选择。
5. 全局也失败，重点检查节点、网络、端口和 DNS。

怎样确认一条连接命中了哪条规则

打开「连接」或「Connections」页面，重新访问目标网站，然后按域名筛选。记录中通常会显示目标主机、目标端口、上传下载量、命中的规则和实际策略链。例如记录显示 DOMAIN-SUFFIX 命中 Proxy，而 Proxy 当前选择某个节点，就能确认分流路径。若显示 MATCH → DIRECT，说明末尾兜底规则把连接交给了直连。

四、系统代理已经开启，为什么浏览器仍然不通

问题 5：系统代理开关到底做了什么

系统代理开关通常只是把操作系统的 HTTP 与 HTTPS 代理地址写成 127.0.0.1 加本地端口。例如配置使用 mixed-port: 7890，系统代理会指向 127.0.0.1:7890。应用是否遵循该设置，由应用自身决定。主流浏览器通常读取系统代理，部分游戏、终端程序、商店应用和自带网络栈的软件可能忽略它。

按以下顺序检查，避免反复切换节点掩盖真正原因：

1. 在客户端首页确认内核状态为运行中，而不是仅启动了界面。
2. 进入「设置」→「端口设置」，记录 Mixed Port 的实际值。
3. 确认系统代理地址与该端口一致，例如 127.0.0.1:7890。
4. 打开「连接」页面，再刷新浏览器，看是否出现新连接。
5. 有连接但访问失败，检查规则命中、节点和 DNS。
6. 完全没有连接，检查浏览器代理扩展、系统代理覆盖和应用自身设置。

浏览器里同时安装代理扩展时，扩展可能覆盖系统代理。排查期间应将扩展切换为“使用系统代理”或暂时停用。命令行工具也可能读取环境变量，Windows PowerShell 可检查 HTTP_PROXY 与 HTTPS_PROXY，macOS 或 Linux 终端可执行 env | grep -i proxy。旧变量如果仍指向另一个端口，就会造成浏览器正常、终端失败的分裂现象。

问题 6：什么时候需要开启 TUN 模式

TUN 模式通过虚拟网络接口接收更多系统流量，适用于忽略系统代理的应用、UDP 流量、部分游戏启动器和需要统一接管的命令行程序。它不是“速度增强”开关。只使用浏览器与普通桌面应用时，系统代理通常更容易维护；明确发现目标应用不读取系统代理，再启用 TUN 更合适。

常见路径为「设置」→「网络设置」→「TUN 模式」，首次开启可能要求管理员权限并安装虚拟网络组件。开启后检查客户端是否显示 TUN 正常运行，同时确认系统中没有另一个 VPN、虚拟网卡工具或旧客户端争用路由。Windows 上若启用失败，可先完全退出客户端，再以管理员权限启动一次完成服务安装；后续是否持续需要管理员权限取决于客户端的服务实现。

五、节点显示超时，端口冲突和 DNS 应该怎么查

问题 7：延迟测试显示 Timeout，是否代表节点一定不可用

不一定。延迟测试通常请求配置指定的测试 URL，并设置固定超时时间。测试地址不可达、节点不允许访问该目标、DNS 解析失败或本地网络丢包，都可能显示 Timeout。应至少做三项交叉验证：更新配置、切换两个不同地区节点、用浏览器访问一个明确支持 HTTPS 的目标。

延迟数值也不是下载速度。一次测试得到 80 ms，只表示该测试请求在当时约 80 毫秒完成，不能推出持续吞吐能力。连续三次分别为 85 ms、92 ms、410 ms，说明链路抖动较大；稳定的 140 ms 节点在视频与普通网页场景中，可能比频繁跳到 400 ms 的低延迟节点更可用。

• 所有节点同时超时：先检查订阅状态、本地网络、DNS 和客户端日志。
• 只有一个节点超时：切换同组其他节点，稍后再次测试。
• 延迟测试正常但网页失败：检查规则命中、浏览器代理与目标站点限制。
• TCP 页面正常但游戏失败：检查客户端是否接管 UDP，以及 TUN 配置是否生效。

问题 8：出现“端口 7890 被占用”怎么办

这表示另一个进程已经监听相同端口。常见原因是旧客户端仍在后台运行、同一客户端启动了两个实例，或其他网络工具也使用 7890。不要直接连续更换端口，先找出占用进程。Windows 可在命令提示符执行以下命令：

netstat -ano | findstr :7890
tasklist /fi "PID eq 进程编号"

macOS 与 Linux 可使用：

lsof -nP -iTCP:7890 -sTCP:LISTEN
lsof -nP -iUDP:7890

确认是旧实例后正常退出该进程，再重启当前客户端。如果端口确实被其他必要程序使用，可进入「设置」→「端口设置」把 Mixed Port 改为 7891 或其他未占用端口。修改后必须同步刷新系统代理，使其指向新端口。手工维护 YAML 时，对应配置可写为：

mixed-port: 7891
allow-lan: false
mode: rule
log-level: info

allow-lan: false 表示不向局域网设备提供代理入口。如果确实需要让手机通过电脑代理，再开启局域网访问，并配合操作系统防火墙和可信网络范围设置，不应只改监听端口。

问题 9：网页能打开，但域名解析慢或出现 DNS 异常怎么办

Clash 或 mihomo 的 DNS 模块负责在规则匹配与连接建立之间协调域名解析。常见增强模式包括 fake-ip 与 redir-host。fake-ip 会先返回保留地址映射，再由内核恢复原始域名，规则匹配效率较高，也更适合 TUN 接管；某些局域网设备、企业软件或依赖真实 IP 的程序可能需要加入 fake-ip-filter。

不要在尚未确认问题来源时堆叠大量 DNS 服务器。先使用两条稳定解析线路，观察日志中是否有超时。一个基础结构如下，实际配置仍应服从当前客户端和订阅要求：

dns:
  enable: true
  ipv6: false
  enhanced-mode: fake-ip
  nameserver:
    - https://dns.alidns.com/dns-query
    - https://doh.pub/dns-query
  fake-ip-filter:
    - "*.lan"
    - "localhost.ptlogin2.qq.com"
    - "+.stun.*.*"

配置改动后应执行「配置」→「重新载入」，再清理应用自身缓存并重新测试。Windows 可运行 ipconfig /flushdns 清理系统 DNS 缓存，macOS 可关闭并重新打开目标应用。若客户端日志持续出现 DNS timeout，应先测试当前网络能否连接所填的解析服务器，而不是继续增加 fallback 数量。

六、配置更新、自动选择与故障恢复

问题 10：第一周结束前应该保留哪些设置

先保留最小可复现状态：一个有效订阅、一份当前配置、规则模式、一个确认可用的节点、正确的本地端口，以及明确选择的系统代理或 TUN 接管方式。不要同时开启多个自动选择脚本、远程规则覆写和实验性 DNS 选项。基础链路稳定后，再增加自动更新、延迟测试和规则集功能。

订阅自动更新间隔不宜过短。节点信息通常不需要每分钟刷新，设置为 6 小时、12 小时或 24 小时更便于观察。客户端休眠后恢复网络时，可以手动更新一次配置；若更新失败，不要立即删除当前可用配置，因为旧配置仍可能维持连接。先查看日志中的 HTTP 状态码，再决定是否重新取得订阅地址。

建议记录的六项信息

• 客户端名称、版本号与系统架构，例如 Windows 11 x64。
• 内核名称与版本，例如 mihomo 1.19.x。
• 当前模式：Rule、Global 或 Direct。
• 流量入口：系统代理、TUN，或应用内手工代理。
• Mixed Port 实际值，例如 7890 或 7891。
• 故障发生时间、日志错误行和命中的策略组。

这六项比“连不上”更容易定位问题。例如：Windows 11 x64、mihomo 1.19.x、规则模式、系统代理、mixed-port 7890、浏览器连接命中 Proxy 但日志显示 connection timeout。根据这些信息，可以直接把范围缩小到节点链路，而不必反复重装客户端。

一套固定的五分钟排查顺序

1. 看内核：确认运行状态与日志里没有配置加载失败。
2. 看入口：确认系统代理端口或 TUN 接管状态。
3. 看连接：刷新目标应用，观察 Connections 是否出现记录。
4. 看规则：确认记录命中的规则、策略组与最终节点。
5. 看出口：切换另一个节点，比较全局模式和规则模式结果。

如果 Direct 可以访问、Rule 失败，而 Connections 显示请求进入了错误策略组，应修正规则或策略组选择；如果 Direct 与代理都失败，应回到本地网络和 DNS；如果浏览器有连接记录而目标应用完全没有记录，则应检查该应用是否读取系统代理，并决定是否使用 TUN。按入口、规则、出口分层排查，比删除配置重新安装更容易保留有效线索。