Clash 新手常见问题：订阅导入、模式选择与连接检查十问

客户端与内核怎么选

一、下载 Clash 时，应该先看客户端名称还是系统版本？

先看操作系统和处理器架构，再看客户端使用的内核。Clash 是一套代理配置与规则体系的常用统称，实际使用时还需要图形客户端或命令行程序承载。Windows、macOS、Android、iOS 与 Linux 的安装方式不同，同名安装包也可能区分 x64、ARM64 等架构。

Windows 常见电脑通常使用 x64 安装包，采用 ARM 处理器的设备需要 ARM64 版本。macOS 还要区分 Intel 与 Apple 芯片；选择不匹配的包，可能表现为无法安装、启动后立即退出，或者必须经过额外的兼容转换。无法判断架构时，应先在系统信息中查看“系统类型”或“芯片”，不要根据设备上市年份猜测。

内核方面，仍在维护的客户端通常采用 Mihomo，也就是由 Clash Meta 延续发展的内核。它兼容常见 Clash 配置结构，并扩展了代理协议、规则、DNS 与 TUN 能力。客户端界面和内核不是同一层：界面负责订阅管理、开关与日志展示，内核负责建立连接、执行规则和处理流量。因此，比较客户端时应同时确认内核版本、更新状态和配置兼容范围。

二、安装完成后，为什么还不能直接访问网络？

客户端安装完成只代表程序可以运行，并不等于代理链路已经建立。至少还需要一份有效配置、一个可连接的节点，以及让应用流量进入 Clash 的接入方式。最常见的完整流程是：导入订阅或本地配置、更新配置、选择代理节点、开启系统代理，然后用浏览器进行测试。

如果界面中只有空白配置页，或者策略组中没有任何节点，客户端就没有可用的远端出口。若已经选中节点但系统代理未开启，浏览器仍可能直接连接。部分应用还会忽略操作系统代理设置，此时普通系统代理无法接管其流量，需要应用内单独填写代理地址，或者在确认需求后启用 TUN 模式。

订阅导入与更新怎么判断

三、订阅链接应该粘贴到浏览器，还是导入客户端？

订阅地址应添加到客户端的配置、订阅或 Profiles 页面。浏览器打开链接只能用于判断服务器是否返回了内容，不能代替客户端导入。不同服务返回的内容可能是 YAML 配置、编码后的节点列表，或者需要经过服务端转换的专用格式；客户端必须能够识别对应结构，才能生成节点和策略组。

导入时应复制完整地址，避免带入前后空格、换行或聊天软件附加的标点。订阅链接通常带有用于识别账户的参数，应按敏感凭据处理，不要发布到公开页面、截图或日志中。若服务提供专门的 Clash 或 Mihomo 订阅入口，优先使用该入口，而不是把其他客户端格式直接粘贴进来。

导入成功后应检查三个结果：配置条目是否出现更新时间，策略组中是否有节点，日志是否报告解析错误。只看到“下载成功”并不足以证明配置可以加载；下载阶段成功但 YAML 结构不兼容时，内核仍可能拒绝启用。

四、订阅更新失败，或者更新后节点没有变化，先查什么？

先区分“请求没有拿到内容”和“拿到内容但没有生效”。前者常见表现是超时、连接失败、HTTP 状态异常；后者常见表现是配置解析错误、策略组为空，或者当前活动配置仍是旧版本。可以按以下顺序检查：

1. 确认设备本身可以访问订阅服务器，并检查系统日期、时间与时区是否准确。
2. 重新复制完整订阅地址，确认账户状态和订阅有效期没有变化。
3. 查看客户端日志，判断错误发生在下载、解析还是配置切换阶段。
4. 更新完成后确认新配置已经被设为当前活动配置，而不是仅保存到列表。
5. 检查策略组选择。配置更新可能重建节点列表，但策略组仍保留原选择或回到默认项。

自动更新周期由客户端或配置中的订阅提供器参数决定，并非所有客户端都会在启动时立即刷新。手动更新时也不要连续快速点击，因为并发请求可能触发服务端限制。更新后的节点名称看起来相同，也不代表内容没有改变，服务器地址、端口和传输参数都可能在名称不变的情况下更新。

若使用的是完整远程配置，更新可能覆盖本地直接编辑的规则。需要长期保留的自定义规则，应使用客户端支持的覆写、合并或脚本功能，并在修改前保留可回退的原配置。不同客户端对覆写语法的实现并不完全相同，迁移客户端时要重新验证。

Rule、Global、Direct 与 TUN 怎么用

五、Rule、Global 和 Direct 三种模式有什么区别？

日常使用通常选择 Rule，也就是规则模式。内核会从上到下检查规则，命中后把连接交给指定策略组、直接连接或拒绝处理。规则可以依据域名、域名后缀、IP 网段、进程等条件匹配，具体能力取决于内核和客户端。规则列表末尾通常有兜底项，用于处理前面未命中的请求。

Global 是全局模式。进入 Clash 的连接会统一交给全局策略组，但局域网地址、内核保留连接等仍可能受配置和实现限制，因此“全局”不应理解为绕过所有规则边界。它适合临时判断某个网站是否因规则分流错误而连接失败，也适合短时间统一切换出口，不建议把它当作排查所有问题的唯一手段。

Direct 是直连模式。进入内核的连接通常不再交给远端代理，而是由本地网络直接访问。它可用于快速验证故障是否与代理节点有关。若 Direct 也无法访问，问题更可能位于本地网络、DNS、目标服务或应用本身；若 Direct 正常而 Rule 异常，则应继续检查规则命中与策略组。

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

先使用系统代理，只有应用不读取系统代理、需要接管更多类型流量，或者需要统一处理多个程序时，再考虑 TUN。系统代理主要向遵循操作系统代理设置的应用提供 HTTP 或 SOCKS 接入；TUN 则通过虚拟网络接口接收 IP 流量，覆盖范围通常更广，也会引入路由、DNS、权限与防火墙方面的额外变量。

开启 TUN 前，应先确认普通节点测试可用、Rule 模式能够正常处理浏览器连接。否则直接启用 TUN 会把“节点故障”和“虚拟网卡故障”叠加在一起。Windows 上可能需要管理员权限或安装服务，macOS 可能弹出网络扩展授权，Linux 则涉及网络设备权限和路由规则。权限未授予时，界面开关可能打开，但实际接口没有成功建立。

TUN 与其他 VPN、虚拟机网络、容器网络或安全软件同时运行时，可能产生路由优先级冲突。出现全网断开、局域网设备不可达或关闭客户端后仍异常时，应先关闭 TUN，退出其他虚拟网络程序，再恢复系统网络测试。不要同时修改大量 DNS 和路由参数；每次只调整一项，才能判断是哪一层影响了结果。

节点、系统代理、DNS 与日志排查

七、节点延迟显示正常，为什么网页仍然打不开？

延迟测试只证明客户端在特定测试方式下获得了响应，不能完整代表目标网站连接。不同客户端可能使用 TCP 握手、HTTP 请求或指定测试地址测量延迟。测试成功后，实际访问仍可能受到节点出口、目标网站、DNS 解析、规则分流和传输协议状态影响。

先观察访问时日志中是否出现对应域名。如果完全没有日志，流量大概率没有进入 Clash，应检查系统代理、浏览器代理、TUN 状态或应用自身网络设置。如果日志中出现域名但被分配到意外策略组，问题位于规则或策略选择。如果日志显示超时、握手失败或连接被拒绝，则应切换同一策略组中的其他节点，比较是否为单节点故障。

延迟数值也不能直接等同于带宽和稳定性。低延迟节点可能拥塞，高延迟节点也可能在持续传输时更稳定。选择节点时应结合连接成功率、连续访问表现和下载速度，而不是只选列表中数字最小的一项。

八、开启系统代理后仍然没有流量，应该检查哪些端口？

先确认客户端配置中的代理监听端口，与操作系统当前填写的端口一致。常见配置会提供 HTTP 端口、SOCKS 端口，或者同时接受两类流量的 mixed-port。控制器端口用于客户端界面与内核通信，不是提供给浏览器的代理端口，不能混用。

例如，下面的配置表示本机应用可以连接到 7890 混合端口；是否允许局域网设备接入，则由 allow-lan 和监听地址共同决定：

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

只在本机使用时，应保持监听范围收敛，不需要为了排查而开放局域网访问。若端口被其他程序占用，内核日志通常会出现 bind、listen 或 address already in use 一类错误。此时应退出占用程序或更换端口，并同步更新系统代理设置。仅修改 YAML 而没有重新加载配置，也不会改变正在运行的监听端口。

浏览器扩展、开发工具和其他代理软件可能覆盖系统设置。排查时应临时停用额外代理入口，只保留一种接入方式。否则浏览器可能连接到旧端口，或形成“浏览器代理指向另一个代理程序，再转回 Clash”的循环。

九、什么现象通常与 DNS 有关？

能够通过 IP 访问服务但域名失败、部分域名持续解析到异常地址、切换网络后旧结果仍保留，通常需要检查 DNS。Clash 配置可以让内核处理 DNS，并根据规则配合 fake-ip 或 redir-host 等模式工作；具体字段和行为取决于内核版本。新手不应直接复制来源不明的大段 DNS 配置，因为监听地址、上游类型和增强模式必须与当前接入方式配套。

排查时先看日志中的域名是否成功解析，再确认操作系统 DNS 请求是否进入 Clash。系统代理主要处理应用建立的代理连接，不保证所有独立 DNS 请求都会被接管；TUN 模式下则还要检查 DNS 劫持与虚拟地址路由。若关闭 Clash 后解析仍异常，可以清理操作系统 DNS 缓存、重启网络连接，并确认路由器或本地网络提供的 DNS 是否正常。

使用 fake-ip 时，应用看到的是保留地址段中的虚拟结果，内核再把该地址映射回域名进行规则匹配。这些虚拟地址不应被当成真实服务器地址用于长期记录。某些局域网服务、游戏或依赖特殊 DNS 行为的程序可能需要加入兼容列表，但应根据日志和实际故障逐项添加，而不是一次排除大量域名。

十、完全无法连接时，最有效的检查顺序是什么？

有效排查依赖分层，而不是反复重装客户端。建议从最少变量的状态开始，把问题定位到配置、节点、流量接入、规则或系统网络中的某一层：

1. 确认本地网络：切换到 Direct 或暂时关闭代理，检查常规网站是否可以直连。若基础网络已经中断，先恢复 Wi-Fi、网线或移动网络。
2. 确认配置加载：查看当前活动配置名称和更新时间，检查日志中是否有 YAML 解析、字段不支持或文件读取错误。
3. 确认节点连接：选择一个明确存在于当前策略组的节点，执行延迟测试，并在访问网页时观察实时日志。
4. 确认流量进入：开启系统代理后检查操作系统代理地址与端口。没有任何请求日志时，优先处理接入问题。
5. 确认规则结果：使用 Rule 模式查看目标域名命中了哪条规则、交给了哪个策略组，再核对该组当前选项。
6. 对照 Global 与 Direct：Global 可帮助判断规则是否选错出口，Direct 可帮助判断本地网络是否能够直接访问。
7. 最后检查 TUN 与 DNS：只有基础代理链路可用后，再启用 TUN、DNS 增强和应用级兼容设置。

日志级别使用 info 通常足以完成初步判断。需要进一步定位时可以短时间提高日志详细度，但日志可能包含访问域名、节点名称、服务器地址和本地网络信息，分享前应删除账户参数与敏感配置。排查结束后恢复常规日志级别，避免长期产生大量记录。

如果修改后出现新问题，回到最近一次可工作的配置，比继续叠加设置更高效。订阅、覆写规则、DNS 与 TUN 应分别验证：先确认原始订阅能加载，再添加本地覆写；先确认系统代理可用，再启用 TUN。通过这种顺序，绝大多数“导入成功但无法连接”的问题都能被定位到具体环节。