Clash 新手常见问题：订阅导入、节点选择与连接异常十问

第一次打开 Clash Verge Rev 时，界面里的订阅、配置、代理组、系统代理、规则模式和 TUN 模式容易被理解成同一种“连接开关”。实际上，它们位于不同层级：订阅提供配置来源，配置决定节点与规则，策略组决定可选出口，系统代理或 TUN 模式负责让应用流量进入内核，规则再决定每条连接走直连、代理还是拒绝。

下面用十个常见问题串起完整使用流程。排查时建议一次只改变一个设置，并记录改变前后的结果。这样可以判断故障发生在订阅、节点、流量接管、规则匹配还是目标网站一侧，而不是反复切换所有开关。

Subscription

订阅与配置导入

一、订阅链接为什么不能直接当作节点使用？

订阅链接是一个远程配置入口，不等于某个具体代理节点。客户端访问该地址后，会取得节点列表、策略组、规则、规则提供器以及 DNS 等配置内容。导入成功后，应当在配置页面看到对应配置，并在代理页面看到可供选择的策略组和节点。

常见导入方式是复制服务提供方给出的 Clash 或 Mihomo 订阅地址，在客户端的订阅或配置页面粘贴并下载。普通网页地址、账户后台地址以及只适用于其他客户端的订阅格式，未必能被当前内核解析。如果导入后提示格式错误，应先确认链接类型，而不是立即修改端口或开启 TUN。

二、订阅导入后为什么看不到节点？

首先确认新配置是否已经下载并被设为当前配置。部分客户端允许同时保存多份配置，成功添加订阅并不一定意味着已经切换过去。其次检查代理页面中是否只有策略组名称；节点往往位于“节点选择”“手动选择”或服务方自定义名称的策略组内部，不一定直接铺在首页。

如果配置已启用但节点数量仍为零，可以查看客户端日志或配置错误提示。常见原因包括订阅已过期、远程服务器暂时不可达、返回内容为空、订阅格式与内核不兼容，或 YAML 缩进和字段结构存在问题。手工配置至少需要形成节点、策略组和规则之间的有效引用关系。例如，策略组引用的节点名称必须与节点定义完全一致：

proxies:
  - name: "示例节点"
    type: socks5
    server: 127.0.0.1
    port: 1080

proxy-groups:
  - name: "节点选择"
    type: select
    proxies:
      - "示例节点"
      - DIRECT

rules:
  - MATCH,节点选择

这段内容只用于说明引用结构，并不是可直接连接外部网络的完整配置。实际节点参数应来自可信的配置来源。

三、更新订阅会不会覆盖已经做出的选择？

订阅更新通常会重新获取远程配置。节点增删、策略组结构、规则和 DNS 设置是否变化，取决于服务端返回的新内容。客户端对策略组选择的记忆方式各不相同：当策略组名称和节点名称保持不变时，之前的选择可能继续生效；节点被删除或改名后，则需要重新选择。

直接编辑订阅下载得到的 YAML 也要谨慎。下一次更新可能用远程版本替换本地内容，使手工修改消失。需要长期维护自定义规则时，更合适的做法是使用客户端支持的覆写、合并配置或脚本功能，并保留一份独立备份。更新后应检查当前配置、主要策略组和规则模式，不要仅以“更新成功”提示判断连接状态。

Selection

节点、策略组与代理模式

四、节点延迟最低，实际速度就一定最快吗？

延迟测试只反映客户端到测试目标的一次或多次短连接耗时，不能完整代表持续下载、视频播放或跨区域访问的表现。节点速度还受到线路拥塞、出口带宽、丢包率、目标网站位置、传输协议和本地网络质量影响。一个延迟略高但丢包较少的节点，实际使用可能比低延迟拥塞节点稳定。

选择节点时可以先做延迟测试，再用真实目标验证。网页访问关注首包和连续打开是否稳定，视频关注一段时间内能否持续缓冲，下载任务则关注稳定速率而不是瞬时峰值。如果多个节点都超时，应先检查订阅、网络和内核状态；如果只有单个节点超时，更可能是该节点暂时不可用。

五、规则、全局和直连模式应该选哪一个？

规则模式按照配置中的规则自上而下匹配。域名、IP、进程或规则集命中后，连接会被交给指定策略组、DIRECT 或 REJECT。它适合日常使用，也便于让本地服务和常用国内站点直连，让特定目标使用代理。

全局模式通常把进入内核的连接统一交给全局策略组。它适合短时间验证代理节点是否工作，或者在规则未覆盖某个目标时进行对照测试。全局模式不等于所有设备、所有进程都会自动进入 Clash；是否被接管仍取决于系统代理、TUN 或应用自身代理设置。

直连模式让被接管的流量直接连接目标，不经过代理节点。它可用于判断异常是否与代理链路相关。日常建议从规则模式开始，需要诊断时再短暂切换全局或直连进行比较。

模式	流量处理	常见用途
规则	按规则顺序选择出口	日常分流
全局	统一交给全局策略组	节点验证、临时测试
直连	直接访问目标	对照排查

六、已经选中节点，为什么流量还是没有经过代理？

选中节点只确定了某个策略组的出口，并不会自动让应用流量进入 Clash。还需要至少一种流量接管方式：开启系统代理、开启 TUN 模式，或者在具体应用中手动填写 Clash 的 HTTP 或 SOCKS 监听地址。

还要确认规则实际使用了刚才操作的策略组。配置中可能同时存在“节点选择”“自动选择”“媒体服务”和“漏网之鱼”等多个组。即使在“节点选择”里更换了节点，某条规则也可能指向另一个策略组。遇到这种情况，可以打开连接记录或日志，查找目标域名对应的命中规则、策略组和最终节点。

Traffic Capture

系统代理与 TUN 模式

七、系统代理已经开启，为什么有些应用仍然直连？

系统代理主要影响愿意读取操作系统代理设置的应用，例如多数浏览器和部分桌面软件。某些游戏、命令行工具、独立更新器或自行实现网络栈的程序可能忽略系统代理，因此不会经过 Clash。应用也可能在自身设置中指定了“直连”或另一套代理，覆盖系统配置。

先用浏览器访问目标并观察连接记录。如果浏览器流量能够出现，而特定应用没有任何记录，问题通常位于应用是否遵循系统代理这一层。可以检查应用自身的代理选项，或在确有需要时使用 TUN 模式。若所有应用都没有记录，则应检查客户端内核是否启动、系统代理是否成功写入，以及监听端口是否被其他程序占用。

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

TUN 模式通过虚拟网络接口接管更广泛的 IP 流量，适合不读取系统代理的程序，也能减少逐个应用设置代理的工作。它并不是安装后必须立即开启的选项。若浏览器和常用软件通过系统代理已经正常工作，保留较简单的系统代理方案更便于理解和排错。

开启 TUN 往往需要系统权限，并可能与其他 VPN、虚拟网卡、安全软件或企业网络客户端产生路由冲突。出现无法联网时，应检查 TUN 是否成功启动、默认路由是否正确、DNS 是否可用，以及系统中是否同时运行了其他接管网络的工具。关闭其他网络接管软件后重新测试，可以帮助定位冲突来源。

TUN 负责把流量送入内核，最终是否代理仍由当前模式和规则决定。因此，开启 TUN 后看到某些连接走 DIRECT 并不必然是故障；它可能正好命中了直连规则。诊断时应结合连接详情中的规则名称与最终链路，而不是只看 TUN 开关状态。

Troubleshooting

连接异常的基础排查

九、节点测试正常，网页却打不开，应该检查什么？

节点延迟可测只说明某个测试请求获得了响应，不代表目标网页的完整访问链路一定正常。可以按照以下顺序检查：

确认流量是否进入内核。打开连接页面或实时日志，再访问目标网站。如果没有新增记录，优先检查系统代理、TUN 或应用代理设置。
确认规则命中结果。查看目标域名最终走 DIRECT、PROXY 还是 REJECT，并确认对应策略组已经选中可用节点。
切换节点进行对照。只更换同一策略组中的节点，不同时修改 DNS、模式和配置。若另一个节点正常，原节点或其出口线路更值得怀疑。
比较规则与全局模式。全局模式正常而规则模式异常，通常表示规则命中、策略组引用或规则集更新需要检查。
检查 DNS。域名解析失败、返回异常地址或解析链路与代理规则不一致，都可能表现为网页打不开。可以比较域名访问与已知 IP 连接的差异，但不要把临时 IP 当作长期解决方法。
检查目标服务状态。仅一个网站异常时，也可能是目标站维护、地区限制、账户状态或出口 IP 被目标服务拒绝。

如果日志中出现超时，需进一步区分是连接代理服务器超时、DNS 查询超时，还是代理服务器连接目标超时。三者位于不同阶段，处理方向也不同。只看浏览器最后显示的错误页，通常不足以确定原因。

十、重启后无法连接，怎样快速恢复？

先检查客户端是否已启动内核，而不是只确认窗口已经打开。随后确认当前配置仍然存在且处于启用状态，订阅没有变成空配置，主要策略组中也有可用节点。系统重启后，系统代理可能未自动启用；如果依赖 TUN，则应确认权限请求、服务组件和虚拟网卡状态正常。

可以使用“最小变量”方法恢复：暂时关闭 TUN，只开启系统代理；选择一份最近确认可用的配置；使用规则模式；在主要策略组中手动选择一个可用节点；最后用浏览器测试并查看连接记录。这个组合正常后，再逐项恢复自动选择、TUN、自定义 DNS 或覆写配置。

若客户端无法启动内核，应查看错误日志中是否出现端口占用、配置解析失败或权限不足。端口占用时，不要随意反复修改多个监听端口，可以先退出其他代理软件并重新启动。配置解析失败时，应切换回可用配置或撤销最近一次覆写修改。权限问题则应按照操作系统提示处理 TUN 服务或网络扩展授权。

Checklist

首次使用检查清单

完成安装与订阅导入后，可以按下面的顺序确认。前一项未通过时，先不要跳到更复杂的 DNS 或路由调整：

客户端内核处于运行状态，没有配置解析错误。
订阅已经下载，并且对应配置被设为当前配置。
代理页面能够看到策略组，策略组内存在节点。
至少选择一个能够完成延迟测试或实际连接的节点。
日常模式先使用规则模式，确认主要策略组的选择。
开启系统代理，并用浏览器进行第一次连接测试。
在连接记录中确认目标域名、命中规则和最终出口。
只有在应用忽略系统代理时，再评估是否开启 TUN。
订阅更新后复查策略组，避免节点改名后选择失效。
发生异常时保存关键日志，并按接管、规则、节点、DNS、目标服务的顺序定位。

理解这些层级后，多数“节点已选但没有效果”“浏览器正常但游戏不通”“全局可用而规则模式失败”等问题，都能被拆成可验证的步骤。Clash 的核心不是单一开关，而是一条由配置来源、流量入口、规则匹配和出口节点组成的处理链。观察连接记录并逐层验证，比频繁重装客户端更容易找到真正原因。