Clash 新手十问十答:订阅、节点、代理模式一次讲清楚

一、Clash 是节点服务吗，订阅链接从哪里来

Clash、Clash Meta（现通常使用 mihomo 名称）以及各类图形客户端负责读取配置、匹配规则并转发连接。它们本身不提供节点，也不会在安装完成后自动生成订阅。订阅链接需要由你使用的服务提供方创建，通常位于服务后台的「订阅」「一键订阅」或「客户端导入」页面。

一个订阅通常返回 YAML 配置或经过编码的节点列表。完整的 Clash 配置不只包含服务器地址，还可能包含代理组、规则集、DNS 与 TUN 参数。只有单个节点分享链接时，也可以手动导入，但代理组与分流规则需要另外配置。

拿到链接后先检查三件事

确认服务后台提供的是 Clash 或 Clash Meta 格式，而不是仅供其他客户端使用的格式。
复制时保留完整的 https://、路径、查询参数与令牌，不要遗漏末尾字符。
先用浏览器访问服务后台确认账户与订阅仍然有效，不要把登录页地址误当成订阅地址。

二、订阅应该怎么导入，为什么导入后还要更新

不同图形客户端的名称略有差异，操作顺序基本一致。以常见界面为例，进入「订阅」→「新建订阅」，粘贴 URL，填写便于识别的名称，然后选择「保存并更新」。另一类界面会把入口写成「配置」→「新建」→「URL」。导入成功后，应当能看到更新时间、配置文件名称以及代理数量。

“保存”只记录地址，“更新”才会真正请求远端内容。首次导入后节点列表为空，最常见的原因就是只保存了 URL，没有执行更新。建议把自动更新间隔设为服务允许的范围，例如 1,440 分钟一次；频繁设为 5 分钟并不会让线路更稳定，反而可能触发服务端请求限制。

更新失败时按这个顺序排查

查看错误是否为 401 或 403。这通常表示令牌失效、账户状态异常或请求被拒绝。
出现 404 时重新复制订阅地址，重点检查路径和查询参数是否完整。
出现连接超时，先关闭当前代理再更新一次；如果直连无法访问服务端，再尝试启用可用的旧配置更新。
更新完成但节点数量为 0，检查下载到的是不是网页 HTML，而不是 YAML 或节点列表。
配置解析报错时查看日志中的行号。服务端返回了不兼容字段时，需要切换到 Clash Meta 格式或更新 mihomo 内核。

三、订阅导入成功，为什么看不到节点

先区分“订阅存在”和“当前配置已经启用”。很多客户端允许保存多个配置，但同一时刻只加载其中一个。进入「订阅」或「配置」页面，选中刚更新的配置，再执行「启用」「设为当前配置」或「切换」。随后打开「代理」页面，检查策略组中是否出现节点。

如果配置已经启用，仍然没有可选项，可能是配置只定义了规则，没有定义 proxies 或 proxy-providers。也可能是代理提供器尚未完成首次拉取。对于 provider 配置，可以进入「代理提供器」页面手动更新，或者在日志中搜索 provider 名称。

界面现象	常见原因	处理动作
订阅卡片存在，代理页仍是旧节点	新配置未设为当前配置	选中新配置并执行启用或切换
代理组存在，但组内为空	代理提供器未拉取成功	手动更新 provider 并查看日志
更新提示解析失败	YAML 缩进、字段或格式不兼容	切换订阅格式或更新 mihomo 内核
只有 DIRECT 与 REJECT	配置未包含可用代理定义	检查服务后台导出的配置类型

四、节点为什么全部超时，延迟数字怎么看

延迟测试不是对节点服务器做一次简单的网络探测。Clash 通常会通过该节点请求一个测试 URL，并计算建立连接到收到响应所需的时间。因此，“超时”可能发生在本地网络、节点入口、目标测试站点、DNS 解析或 TLS 握手中的任一环节。

可以先单独测试 3 个节点，避免一次对几十条线路发起请求。常见测试 URL 为 https://www.gstatic.com/generate_204，超时值可先设为 5,000 毫秒。若这个地址在当前网络不可达，应换成服务方建议的 HTTP 204 检测地址，否则所有节点可能同时显示超时。

延迟结果的实用判断

50 至 120 毫秒：通常适合网页、即时通信与普通视频连接。
120 至 250 毫秒：可正常使用，但实时语音、远程桌面可能感到响应变慢。
超过 500 毫秒：应换线路再次测试，并观察是否伴随丢包或频繁断开。
固定显示 0 毫秒：通常不是实际结果，可能表示测试未运行或界面尚未刷新。
全部 Timeout：先测试直连网络，再检查系统时间、DNS、内核日志与测试 URL。

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

新手日常使用优先选择规则模式。规则模式会从上到下匹配域名、IP、进程或规则集，再把连接交给指定策略组。国内服务可以直连，需要代理的目标走节点，局域网与特殊地址也能按配置单独处理。

模式	连接处理方式	适用场景
Rule	按规则逐条匹配，命中后使用对应策略	日常使用与长期运行
Global	大部分可代理连接统一交给全局策略组	临时判断是否为分流规则导致访问失败
Direct	连接直接发出，不经过代理节点	暂停代理、测试本地网络或更新订阅

遇到某个网站在规则模式打不开，可以短暂切到全局模式测试。如果全局模式可用，说明节点本身大概率正常，应检查该域名命中了哪条规则；如果全局模式也失败，则继续检查节点、DNS 和目标站点状态。测试完成后切回规则模式，避免所有连接长期挤到同一节点。

日志中的规则命中信息很关键。将日志级别临时设为 info，重新访问目标站点，查看域名最终进入了 DIRECT、REJECT 还是某个代理组。排查结束后不必长期使用 debug，详细日志会快速增加文件体积。

六、系统代理和 TUN 模式有什么区别

系统代理是在操作系统中写入 HTTP 与 SOCKS 代理地址。遵循系统代理设置的浏览器和应用会把连接发送给 Clash，例如本机常用的 mixed 监听地址 127.0.0.1:7890。它配置简单，也便于随时开关，但部分游戏、命令行工具、商店应用和自带网络栈的软件可能忽略系统代理。

TUN 模式会创建虚拟网络接口，并通过路由接管更多 TCP、UDP 与 DNS 流量。它适合无法手动设置代理的应用，但需要操作系统授予创建虚拟网卡和修改路由的权限。Windows 客户端通常需要先安装服务模式；macOS 会请求网络扩展权限；Linux 则需要相应的网络管理能力。

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  strict-route: true
  dns-hijack:
    - any:53

以上是 mihomo 配置中常见的 TUN 结构，实际可用字段取决于内核版本与客户端管理方式。图形客户端已经接管这些参数时，优先通过「设置」→「网络设置」→「TUN 模式」启用，不要同时在界面和订阅覆写中维护两份互相冲突的配置。

新手选择建议

只需要浏览器和常规桌面应用：先启用系统代理。
游戏、终端或特定应用不读取系统代理：再启用 TUN。
启用 TUN 后断网：关闭 TUN，恢复网络，再检查服务模式、路由与 DNS 日志。
系统代理与 TUN 可以由部分客户端协同管理，但不要另外安装多个工具重复接管路由。

七、7890、7891 和 9090 端口分别做什么

端口是本机程序之间连接 Clash 内核的入口。配置中的 mixed-port: 7890 可以同时接受 HTTP 与 SOCKS 代理连接，适合多数桌面客户端。旧配置常把 HTTP 放在 7890、SOCKS 放在 7891。external-controller: 127.0.0.1:9090 则用于图形界面控制内核，不是给普通应用填写的代理端口。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
external-controller: 127.0.0.1:9090

如果应用要求填写代理地址，可使用主机 127.0.0.1 和 mixed 端口 7890。不要把 9090 填进浏览器代理设置。局域网共享代理需要明确启用 allow-lan 并配置监听地址，同时在系统防火墙中限制来源；只在本机使用时保持关闭更容易管理。

启动日志出现 address already in use，表示端口已被其他进程监听。进入「设置」→「参数设置」修改 mixed 端口，例如从 7890 改为 7893，然后重启内核。修改后，手动配置过代理端口的浏览器、终端和其他应用也要同步更新。

八、浏览器能访问，其他应用为什么仍然直连或断网

浏览器能访问只说明浏览器的连接进入了 Clash，不代表整台设备的所有流量都已接管。先确认浏览器是否安装过单独的代理扩展；如果扩展直接指向 127.0.0.1:7890，即使系统代理关闭，浏览器也可能继续使用 Clash，而其他应用仍然直连。

按应用类型检查

普通桌面应用：检查「系统设置」→「网络和 Internet」→「代理」中的地址与端口是否由客户端正确写入。
命令行工具：确认工具是否读取 HTTP_PROXY、HTTPS_PROXY 或 ALL_PROXY 环境变量。
游戏与 UDP 应用：系统 HTTP 代理通常无法覆盖，应使用支持 UDP 的节点并启用 TUN。
Windows 商店应用：部分 UWP 应用受回环限制影响，需要为目标应用配置回环豁免。
虚拟机和容器：其中的 127.0.0.1 指向虚拟环境自身，不能直接代表宿主机地址。

排查时打开客户端的连接列表，然后在目标应用中发起一次新请求。如果列表里完全没有对应域名或进程，说明流量尚未进入内核；如果已经出现连接但结果失败，则查看规则命中、节点与 DNS。这个判断可以避免在“接管问题”和“代理问题”之间反复切换。

九、规则为什么不生效，自定义规则应该放在哪里

Clash 规则按配置中的顺序自上而下匹配，通常在命中第一条规则后停止继续检查。因此，更具体的自定义规则应放在宽泛规则之前，也必须位于最终的 MATCH 规则之前。把规则追加到 MATCH 后面不会产生效果。

rules:
  - DOMAIN,api.example.com,Proxy
  - DOMAIN-SUFFIX,example.com,Proxy
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,Proxy

DOMAIN 只匹配完整域名，DOMAIN-SUFFIX 会匹配该后缀及其子域名。IP-CIDR 用于网段，末尾的 no-resolve 表示匹配时不要为了获得 IP 主动解析域名。规则最后的策略名称必须与 proxy-groups 中的组名完全一致，包括大小写和空格。

订阅更新经常会覆盖原始 YAML，直接编辑订阅文件并不稳妥。支持覆写功能的客户端通常提供「订阅」→「覆写」或「配置」→「合并配置」入口，可把自定义规则插入远端规则之前。保存后重新加载配置，再通过连接日志验证实际命中的规则。

十、怎样确认代理已经生效，退出前要注意什么

确认连接是否生效，不要只看客户端开关。先在直连模式记录一次当前出口信息，再切到规则模式并选择节点，重新打开检测页面。若出口地址和地区发生预期变化，同时客户端连接列表出现对应域名，说明该请求已经经过代理。

接着检查 DNS 与规则。打开客户端日志，访问一个应当直连的国内站点和一个应当代理的目标，确认两者分别命中 DIRECT 与指定代理组。使用 Fake-IP 时，应用看到 198.18.0.0/15 范围的映射地址属于常见工作方式，真实域名仍由内核保存映射并用于规则匹配。

首次使用完成后的检查清单

当前配置已启用，订阅更新时间和节点数量正常。
模式设为 Rule，目标策略组已经选择可用节点。
系统代理或 TUN 至少启用了一个，并与实际应用类型匹配。
连接列表能看到目标请求，规则命中结果符合预期。
内核日志没有持续出现端口冲突、DNS 超时或 provider 更新失败。
关闭客户端时同时恢复系统代理与 TUN 路由，避免系统保留失效的代理地址。

如果关闭 Clash 后网页全部打不开，先到系统代理设置中确认代理开关已经关闭。TUN 使用异常时，退出客户端后重新连接网络，必要时重启系统以恢复路由。再次启动前不要同时运行多个监听 7890 或接管默认路由的代理客户端。

新手排障可以固定使用一个顺序：先检查本地网络，再检查订阅是否更新，然后确认配置已启用、节点可连接、模式与策略组正确，最后检查系统代理或 TUN 是否真正接管应用。每次只改一个变量，并在连接列表和日志中验证结果，通常比反复重装客户端更快。