Clash规则怎么选择代理节点？先分清规则、策略组和节点
简答：Clash中，规则决定流量交给哪个策略组，策略组再决定使用哪条代理节点。日常优先使用Rule模式，先在对应策略组中选择手动节点或自动策略，再通过连接日志和实际访问结果验证；不要只按一次延迟测试判断节点好坏。
定义：Clash规则是流量分流条件，策略组是节点选择入口，具体代理节点则是最终承载连接的线路。
先试这一步：确认流量到底走了哪个策略组
如果你已经导入配置，但不知道该选哪条节点，先不要在所有节点之间反复切换。打开 Clash 兼容客户端的代理或策略组页面，找到当前规则命中的策略组，再查看该组当前使用的节点。不同客户端的菜单名称可能不同，但判断顺序基本一致：当前模式 → 命中的规则 → 对应策略组 → 当前节点。
| 现象 | 先检查什么 | 处理动作 | 验证边界 |
|---|---|---|---|
| 所有网站都不通 | 系统代理、TUN或本地端口 | 确认客户端已运行，并检查系统代理或TUN是否按需开启 | 客户端显示运行不等于浏览器流量已接管 |
| 只有某个网站打不开 | 规则命中和对应策略组 | 查看连接日志，确认域名没有被送到DIRECT或错误分组 | 换节点前先排除规则匹配错误 |
| 策略组中节点很多 | 策略组类型和健康检查结果 | 手动组用实际场景筛选，自动组看测试结果并复测 | 健康检查只代表测试地址可达 |
| 低延迟但使用仍卡 | 丢包、稳定性和业务兼容性 | 连续观察并用目标网站或应用验证 | 单次延迟不代表长期体验 |
mihomo 文档将代理节点和代理组分别列出；策略组可以引用具体出站代理，也可以引用其他策略组。Clash Verge Rev 是基于 mihomo 内核的图形客户端之一，但不同版本的界面名称可能不同，可先以当前客户端显示为准。查看 mihomo 代理组配置说明 查看 Clash Verge Rev 项目说明
规则、模式、策略组和节点分别负责什么
规则：决定流量交给谁
规则通常根据域名、IP、网络类型或规则集判断一条连接应该进入哪个处理分支。规则本身一般不等于某一条具体节点；规则的结果通常是DIRECT、REJECT或某个代理策略组。mihomo 支持通过规则集维护一批匹配条件，规则提供者的行为类型需要与文件内容相匹配。查看 mihomo rule-provider 官方文档
代理模式：决定规则是否参与分流
| 模式 | 主要作用 | 适合场景 | 不适合用来判断什么 |
|---|---|---|---|
| Rule | 按配置中的规则分流 | 日常浏览、不同网站使用不同策略组 | 不能直接说明某个节点一定可用 |
| Global | 将需要代理的流量统一交给全局策略组 | 临时测试统一出口、排查规则是否匹配错误 | 不能证明原有规则已经正确 |
| Direct | 尽量不经过代理策略组 | 对比本地网络、确认问题是否来自代理链路 | 不能作为代理连接成功的证明 |
策略组：决定使用哪条节点
策略组是用户真正选择节点的入口。常见类型包括手动选择、自动测试、故障转移和负载均衡。规则把请求交给某个组后，组再根据自身类型选择节点。因此，规则不生效时换节点通常没有用；策略组选择错误时，测速最快的节点也可能不会承载目标流量。
节点：实际建立连接的出站代理
节点是具体的代理出站配置。它可能包含服务器地址、端口、协议和其他传输参数。节点延迟、连接稳定性、出口地区和目标业务兼容性都可能影响体验，单看名称或一次测试结果无法完成判断。查看 mihomo 代理节点字段说明
进入代理页后，按这套顺序选择节点
- 先选Rule模式。日常使用时，Rule通常更适合验证原有分流配置。若你正在排查规则问题，可短时间切换Global做对照；测试结束后记得切回原模式。
- 打开代理或策略组页面。找到日志中显示的目标策略组，例如默认代理组、办公组或某个业务专用组。不要只在首页选择一个节点后就认为所有请求都会使用它。
- 判断策略组类型。如果是select或手动选择组，需要你明确点选节点；如果是URLTest或类似自动测试组，客户端会按照健康检查结果选择；fallback更偏向在当前节点超时后按顺序寻找可用节点；load-balance则按配置的算法在成员之间分配连接。官方文档明确区分了这些策略组行为。查看手动选择组 查看故障转移组 查看代理组配置示例
- 先筛掉明显异常节点。优先排除连续超时、频繁失败、延迟测试没有结果或连接日志反复报错的节点。不要因为某个节点名称带有特定地区，就推断它一定适合目标网站或应用。
- 用目标业务验证。办公网站、视频、游戏和普通网页对连接持续性、UDP、出口地区及并发情况的要求可能不同。打开实际要使用的页面或应用，观察是否能完成登录、加载和持续操作；这一步比单次延迟更接近真实结果。
停止条件是：已经确认目标请求命中了正确策略组，并且至少有一条节点能完成实际业务访问。此时不要继续为了更低的数字反复切换，否则容易把规则问题、节点问题和本地网络问题混在一起。
手动选择、自动选择、故障转移和负载均衡怎么取舍
| 策略组类型 | 选择逻辑 | 适合 | 注意事项 |
|---|---|---|---|
| 手动选择 | 由用户固定选择一个节点 | 需要稳定出口、正在排查问题、想明确知道当前使用哪条线路 | 节点失效后通常需要手动更换 |
| 自动测试 | 根据测试地址和测试周期筛选或选择 | 节点较多、希望减少手动切换 | 测试地址可达不等于目标网站一定可用 |
| 故障转移 | 当前节点超时后按顺序尝试其他成员 | 更看重连续可用和自动切换 | 切换后出口可能变化，固定地区业务需复核 |
| 负载均衡 | 按配置算法在多个成员间分配 | 需要分散连接或多节点共同承载 | 同一业务的出口可能不固定，排查问题更复杂 |
mihomo 的代理组文档提供了健康检查地址、检查间隔、超时和失败次数等字段；健康检查的结果只反映指定测试请求，不应被扩大解释为所有网站、所有时段都可用。查看代理组健康检查字段
不同用途如何筛选节点：先看稳定性，再看地区
| 用途 | 优先观察 | 建议选择方式 | 验证方法 |
|---|---|---|---|
| 日常网页和跨境办公 | 连续连接稳定、登录和页面加载正常 | 先用手动组固定一条表现稳定的节点 | 连续打开多个页面并完成实际办公操作 |
| 流媒体 | 目标服务的地区识别和持续播放 | 按目标服务需要尝试对应地区，再用实际播放验证 | 观察登录、播放、清晰度切换是否正常 |
| 游戏或实时业务 | 延迟波动、丢包和UDP兼容性 | 不要只看最低延迟，优先比较连续稳定性 | 在相同时间段进行多次连接观察 |
| 下载或大文件传输 | 持续吞吐、连接是否中断 | 先选稳定节点，再比较长时间传输表现 | 观察一段完整传输过程，而非只看开始速度 |
地区名称只能作为筛选线索，不能直接证明线路质量。延迟低可能只是测试地址距离较近；实际网站还会受到出口路由、拥塞、丢包、服务端限制和本地网络影响。若需要比较节点，尽量保持测试时间、目标地址和客户端设置一致。
规则模式下打不开网站，按顺序排查
- 确认客户端真的接管流量。检查系统代理、应用代理或TUN状态。客户端显示已运行，不代表目标应用一定使用了它。
- 查看连接日志。确认目标域名是否出现，并记录它命中了哪条规则、进入了哪个策略组、最终使用了哪条节点。若日志中没有请求，优先排查应用代理范围或本地网络。
- 检查规则结果。如果目标请求被送到DIRECT，先不要换节点，应检查规则顺序、域名匹配和规则集更新状态。规则通常按配置顺序匹配，兜底规则可能接收前面未命中的请求。
- 检查策略组当前节点。如果规则命中了正确的代理组，再确认组内当前节点没有超时、连接失败或协议错误。
- 用Global做短时对照。将请求临时交给一个明确可用的代理组。如果Global能打开而Rule不能，问题更可能在规则或策略组；如果Global也打不开，则继续检查节点、本地网络、DNS或客户端核心日志。
每次只改一个变量，并在修改前记录原来的模式、策略组和节点。验证完成后恢复配置，避免把临时测试状态当成最终设置。
订阅更新后节点或规则选择发生变化怎么办
如果订阅更新后策略组名称、节点名称或规则结果变化，先保存当前配置和日志，再确认远程配置是否覆盖了本地修改。Clash Verge Rev 的隐私说明指出，远程配置会从用户提供的订阅地址更新，配置、凭据和日志保存在本地；因此订阅地址和备份文件都应按敏感配置处理。查看 Clash Verge Rev 隐私说明
- 需要长期保留的自定义规则，优先使用客户端支持的覆写、合并或扩展配置，不要只改远程订阅原文。
- 更新后先检查策略组是否仍存在，再检查规则命中和当前节点。
- 如果只有一个节点或一个策略组异常，先回滚到最近一次可用配置，确认问题是否由更新引起。
- 不要把订阅能成功下载等同于节点一定可用；下载成功只说明配置请求完成，仍需通过日志和实际业务验证。
常见问题
Clash规则会自动帮我选择最快节点吗？
不一定。规则通常负责把请求交给某个策略组，是否自动测试和如何选择节点取决于该策略组的类型与配置。手动选择组不会因为规则命中就自动换到最快节点；自动测试组也只会依据其测试地址和检查条件工作。
为什么我选了一个节点，但某个网站仍然没有走它？
常见原因是当前请求命中了另一个规则或策略组，或者应用没有使用系统代理。先看连接日志中的规则、策略组和最终节点，再决定是否更换节点。
延迟最低的节点是不是最适合？
不是。延迟只是某次测试请求的结果，不能代表丢包、波动、持续吞吐、出口地区或目标业务兼容性。应使用目标网站或应用进行实际验证，并观察一段时间的稳定性。
Rule和Global应该怎么选？
日常通常先用Rule，让配置按规则分流；Global适合临时统一出口或排查规则是否匹配错误。测试结束后恢复Rule，并再次确认目标请求的命中结果。
故障转移是不是一定比手动选择更好？
不是。故障转移更适合优先保证连接不中断的场景，但切换后可能改变出口节点。需要固定地区或便于复现问题时，手动选择通常更容易定位。
总结：用三层逻辑选节点
Clash选择代理节点时，最重要的不是先找一个延迟最低的节点，而是按顺序确认：规则把请求交给哪个策略组，策略组采用什么选择逻辑，最终节点能否完成实际业务。日常使用优先从Rule模式开始；遇到单个网站异常，先查日志和规则命中，再查策略组和节点；只有在规则与节点都确认后，才进一步比较延迟、稳定性和地区差异。
本文为第三方使用指南，具体菜单名称、内核版本和配置能力请以当前客户端及其官方文档为准。
常见问题
Clash规则会自动帮我选择最快节点吗？
不一定。规则负责选择分流结果，具体是否自动选节点取决于策略组类型和配置。
为什么选了节点，网站仍然没有走它？
先查看连接日志，确认请求命中的规则、策略组和最终节点，并检查应用是否使用系统代理。
延迟最低的节点是不是最适合？
不是。还要结合稳定性、丢包、出口地区和目标业务的实际访问结果。
Rule和Global怎么选？
日常优先Rule；Global适合临时统一出口或排查规则问题，测试后应恢复Rule。