第一次用 Clash 最常问的十个问题:节点、模式、端口一次讲清

一、Clash 里的节点从哪里来

直接结论：Clash 客户端负责读取配置、执行分流和建立代理连接，本身不生成节点。节点通常来自服务提供方给出的订阅地址，也可以由用户手动写入 YAML 配置。

一个可用配置通常包含代理节点、策略组、规则和 DNS 设置。只有节点列表而没有策略组时，界面可能能看到服务器，却无法按“自动选择”“故障转移”等方式切换；只有规则而没有节点时，代理规则也没有可用出口。

订阅链接和普通网页链接的区别

• 订阅链接通常由服务提供方生成，复制后应粘贴到客户端的配置导入框。
• 订阅链接可能返回 Clash YAML，也可能返回 Base64 节点列表；后者需要客户端支持相应格式或先由可信服务转换。
• 浏览器能打开链接不代表格式一定可被 Clash 识别。若打开后看到登录页、套餐页面或 HTML 报错页，就不是有效配置内容。
• 订阅地址通常带有身份参数，应按账户凭据对待，不要发布到截图、论坛或公开代码仓库。

导入后还要在配置列表中点选刚加入的配置。以 Clash Verge Rev 2.x 的常见界面为例，路径通常是「订阅」→「新建」→粘贴 URL →「保存」，随后返回订阅列表并点击对应配置。不同客户端可能把“订阅”写成 Profiles、配置或配置文件，但过程都是“添加、更新、选中”三步。

二、订阅导入成功后为什么还不能使用

直接结论：“导入成功”只说明客户端拿到了配置，不等于节点已选中，也不等于系统流量已经交给 Clash。新手最容易漏掉后两步。

按这四项逐一确认

1. 配置已激活：配置列表中当前项目应有选中状态，而不是仅出现在历史记录里。
2. 策略组已有选择：进入「代理」或 Proxies 页面，确认主要策略组不是空白，并选中一个可用节点或自动测速组。
3. 运行模式不是直连：排查阶段可先使用规则模式，不要误选 Direct 或直连模式。
4. 流量入口已开启：普通浏览器通常需要开启系统代理；不遵循系统代理的应用则可能需要 TUN。

还可以查看运行日志。若访问网站时完全没有新日志，说明请求没有进入 Clash，应检查系统代理、浏览器独立代理、TUN 或端口设置；若日志里出现请求但显示 timeout、connection refused 或 DNS 错误，才需要继续检查节点、网络和 DNS。

三、规则模式、全局模式和直连模式选哪个

直接结论：日常使用优先选规则模式；全局模式适合临时排查分流问题；直连模式用于暂停代理转发，但通常仍让流量经过 Clash 内核。

规则模式的核心是“自上而下，首条命中”。例如域名先命中 DOMAIN-SUFFIX 规则后，后面的 MATCH 就不会再处理它。配置末尾常见的 MATCH 是兜底规则，用于接住前面未匹配的连接。

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

如果某网站在全局模式下可用、规则模式下不可用，节点本身通常没有问题，重点应放在规则命中结果。打开连接记录，查看目标域名最终走了 DIRECT、某个代理组还是 REJECT，再更新配置或调整对应规则。

四、7890 端口是什么，必须一直保持默认值吗

直接结论：7890 是很多 Clash 配置常用的本地代理端口，但它不是所有客户端强制统一的固定值。它可能被设置为 mixed-port，也可能仅对应 HTTP 代理，实际值应以当前客户端的运行设置和 YAML 配置为准。

9090 不是给浏览器填写的代理端口。把浏览器代理误设为 127.0.0.1:9090，通常只会得到连接失败。使用混合端口时，代理地址一般是 127.0.0.1:7890；若客户端显示的是其他端口，就应使用界面中当前生效的值。

端口被占用时怎么处理

当日志出现 address already in use、bind failed 或“端口占用”，先退出其他代理工具，再重启 Clash。仍有冲突时，可在「设置」→「参数设置」或「设置」→「端口设置」中把混合端口改为 7892、7893 等未占用端口，然后重新开启系统代理。手动给浏览器配置过代理的，还要同步修改浏览器端口。

修改端口后，不要只看开关状态。可在日志中确认本地监听已启动，或检查客户端首页是否显示 HTTP、SOCKS、Mixed 入口的实际端口。系统代理自动设置功能通常会跟随新端口更新，手工配置则不会自动变化。

五、系统代理已经开启，为什么网站还是打不开

直接结论：先判断请求有没有进入 Clash，再判断进入后卡在哪一步。系统代理开关亮起只是起点，节点不可用、规则走直连、DNS 失败和浏览器覆盖系统设置都会造成“开了仍不通”。

五分钟排查流程

1. 打开客户端日志或连接页面，清空当前筛选。
2. 在浏览器访问一个目标网站，观察是否出现对应域名。
3. 没有日志时，关闭浏览器内单独安装的代理扩展，并确认代理地址为 127.0.0.1、端口与客户端一致。
4. 有日志但命中 DIRECT 时，临时切换全局模式进行对照。全局可用说明应检查规则。
5. 日志显示 timeout 时，换一个延迟正常的节点，并测试本地网络能否访问普通网站。
6. 日志显示 DNS error、no such host 或解析超时，再检查 DNS 配置，而不是继续反复切换端口。

Windows 还应留意系统代理是否被其他软件改写。常见检查路径是「设置」→「网络和 Internet」→「代理」。若 Clash 正在自动管理系统代理，手动代理地址一般会指向本机回环地址。退出客户端前应先关闭系统代理，避免操作系统继续把请求发送到已经停止监听的 7890 端口。

macOS 可在「系统设置」→「网络」→当前网络→「详细信息」→「代理」查看状态。通常不需要同时手动勾选多个协议并让客户端再次接管，重复配置可能造成端口不一致。优先让客户端的“设置为系统代理”功能统一管理。

六、节点延迟多少算正常，数字越小就一定越快吗

直接结论：延迟反映测试请求往返所需时间，不直接等于下载速度。日常网页使用中，50 至 150 毫秒通常响应较快，150 至 300 毫秒仍可使用，持续超过 500 毫秒或显示 timeout 才值得优先更换节点。

这些数值不是固定质量线。不同地区、运营商、Wi-Fi 信号和测试地址会显著影响结果。例如同一节点对一个测试 URL 为 92 毫秒，对另一个地址可能是 180 毫秒；晚间高峰也可能从 110 毫秒升到 260 毫秒。应连续测试两到三次，并结合实际打开网页、播放视频和下载文件的表现判断。

延迟低但速度慢的常见原因

• 节点到测速地址的链路短，但到实际目标站点的线路拥堵。
• 服务端可用带宽有限，建立连接很快，持续传输速度却不高。
• 本地 Wi-Fi 丢包，延迟偶尔正常但连接稳定性差。
• 策略组显示的是上一次缓存结果，节点当前状态已经变化。
• UDP、视频分片或大文件传输与普通 HTTP 延迟测试采用的路径不同。

自动选择组通常根据定期 URL 测试挑选延迟较低的节点，故障转移组则更关注当前节点是否可用。前者适合日常选择，后者适合保持连接连续性。不要把测试间隔设得过短；每 300 至 600 秒检查一次通常已经足够，数秒一次会制造额外请求。

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

直接结论：系统代理依赖应用主动读取操作系统的代理设置；TUN 模式通过虚拟网卡接管更多 IP 流量。浏览器和大多数桌面软件常能使用系统代理，游戏、命令行程序、部分商店应用和使用自定义网络栈的软件可能需要 TUN。

第一次使用时建议先让系统代理稳定工作，再考虑 TUN。以采用 Mihomo 1.19.x 配置语义的客户端为例，TUN 常见设置包括 enable、stack、auto-route、auto-detect-interface 和 DNS 劫持。图形客户端通常在「设置」→「系统设置」→「服务模式」安装后台服务，然后在「设置」→「网络」或首页开启 TUN。

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

stack: mixed 是兼顾兼容性的常见选择；若特定系统出现连接问题，可按客户端说明测试 system 或 gVisor。不要在不了解现有配置时整段覆盖订阅中的 TUN 和 DNS 项，因为订阅可能已经提供适配参数。

八、为什么浏览器能用，游戏、终端或商店应用却不走代理

直接结论：这些程序可能没有读取系统代理，或者使用了 UDP、自带 DNS、QUIC 等不同网络方式。浏览器可用已经说明节点和基本代理入口大概率正常，下一步应检查程序流量是否进入 Clash。

命令行工具常有独立代理变量。例如只想让当前终端会话使用本地 HTTP 代理，可以按工具支持情况设置 HTTP_PROXY 和 HTTPS_PROXY；支持 SOCKS5 的程序则可指定 127.0.0.1:7890 或客户端显示的 SOCKS 端口。变量名和代理协议必须与程序文档一致，不能假设所有工具都读取系统设置。

HTTP_PROXY=http://127.0.0.1:7890
HTTPS_PROXY=http://127.0.0.1:7890

游戏和部分商店应用常使用 UDP，普通 HTTP 系统代理无法直接承载这类流量。此时可在确认节点支持相应传输后开启 TUN，并在连接列表中检查目标 IP、协议和命中策略。若 TUN 开启后仍没有记录，应检查虚拟网卡、路由排除项以及应用是否使用了另一张网络接口。

还要注意“全局模式”只决定已经进入 Clash 的连接如何选择出口，不负责把所有程序强制送入内核。因此，把模式从规则改成全局，并不能替代系统代理或 TUN。这是新手最容易混淆的两个层级：流量入口决定“进不进 Clash”，代理模式决定“进入后往哪里走”。

九、订阅更新失败、404 或超时分别怎么处理

直接结论：404 多半与链接本身或账户状态有关，超时更可能是网络路径、服务端响应或代理更新设置导致。先按错误类型处理，不要立即删除当前仍能使用的配置。

看到 404、401 或 403

• 404：订阅路径不存在、链接已更换，或服务端返回了统一错误页。重新从服务提供方控制面板复制最新地址。
• 401：身份参数失效或缺失，应重新登录账户获取订阅。
• 403：服务端拒绝当前请求，可能与账户状态、请求频率或访问来源有关。

看到 timeout 或 connection reset

先用浏览器测试订阅域名是否能建立连接，但不要把完整订阅地址公开。若当前网络无法直连订阅服务器，可在客户端中查找“通过代理更新”“代理订阅更新”一类开关；如果服务端仅允许直连获取，则应关闭该选项。两种方式不要来回快速重试，以免触发服务端频率限制。

自动更新间隔不宜过短。节点信息并不会每分钟变化，常见设置是 1440 分钟更新一次；需要较快同步时可设为 360 分钟。设置成 5 分钟会增加无意义请求，也可能让临时网络波动反复覆盖状态。更新失败时应保留上一次成功配置，再手动重试。

若更新后配置突然为空，先切回上一份本地记录，并检查返回内容是不是 HTML 登录页、错误 JSON 或不兼容格式。客户端提示 YAML parse error 时，可查看错误行号；缩进、冒号后的空格、重复键名以及未闭合引号都可能导致解析失败。

十、第一周怎样设置最稳妥，出现问题又该从哪里恢复

直接结论：保持配置简单，先使用规则模式、一个主要策略组和系统代理；确认浏览器稳定后，再启用自动测速、TUN、自定义 DNS 或脚本。每增加一项功能都做一次实际访问验证。

适合新手的基础状态

• 当前配置明确选中，并保留一份最近可用的本地记录。
• 运行模式使用规则模式，主要代理组手动选择一个已验证节点。
• 混合端口使用客户端自动管理的值，例如 7890。
• 系统代理由客户端开关管理，不在浏览器里重复叠加扩展。
• 自动更新间隔设为 360 至 1440 分钟。
• 日志级别日常使用 information；只有排查时临时切到 debug。
• TUN、脚本覆写和自定义 DNS 在确有需要时逐项开启。

改乱后按这个顺序恢复

1. 关闭 TUN、脚本和手写覆写，只保留原订阅配置。
2. 切换回规则模式，选择一个测试可用的节点。
3. 检查本地混合端口，确认没有端口占用。
4. 重新关闭再开启系统代理，让操作系统刷新代理地址。
5. 用浏览器访问目标站点，同时观察连接日志。
6. 基础访问恢复后，再逐一加回自定义设置，每一步都记录变化。

如果完全退出 Clash 后所有网站都打不开，通常是系统代理残留。重新启动客户端并关闭系统代理，或进入操作系统网络设置取消手动代理即可。若开启 Clash 后普通国内网站也变慢，可检查规则是否把所有请求送到了代理组，以及当前是否误处于全局模式。

第一周不必同时理解所有配置项。先分清四个层次即可：订阅提供配置，节点负责连接出口，系统代理或 TUN 负责接入流量，规则负责选择出口。大多数“开了却不通”的问题，都能沿着这四层逐步定位。