如果你已经在 Windows 上打开了 Clash for Windows（CFW），配置文件也能正常载入，接下来最常遇到的操作就是：节点切换、一键测速以及看着延迟数字做延迟排序来选线。本文收窄到这一块——不写下载安装，也不写订阅链接怎么粘贴，只说明在图形界面里如何从策略组点到具体节点、如何解读测速结果，并在规则分流前提下排除「换了节点却没用」的情况。
节点与策略组：先弄清「该去哪里点」
在 CFW 里，节点列表本身来自当前启用的配置文件（订阅合并后的 proxies），但你日常几乎总是在 Proxies（代理）页里操作，因为那里展示的是策略组（proxy-groups），而不是原始 YAML 全文。可以把它理解成两层：
- 底层节点：诸如香港、日本、美国某台服务器的具体线路，每条对应一种传输参数。
- 分组（策略组）：把多条节点或子分组打包成一个可选入口；规则里引用的是分组名称，分组里再决定当前走哪一条。
因此，搜索「CFW 怎么换节点」时，正确答案往往不是「在某个全局列表里随便点一条」，而是：找到规则正在使用的那一个策略组，再在该分组内切换。常见的分组命名包括 PROXY、手动选择、♻️ 自动选择、机场自定义的「套餐」名称等，具体以你的配置为准。
节点切换：手动选择（Selector）怎么用
Selector 类型的策略组在界面上通常表现为单选列表：当前生效节点左侧会有选中标记。操作步骤可以归纳为：
- 侧栏进入 Proxies，在分组列表中找到负责出境流量的那一组（不确定时可从你认识的机场分组名试起）。
- 展开该分组，单击一条节点名称；界面应立即刷新选中状态。
- 若同时开启了系统代理或 TUN（取决于你的环境与版本），浏览器新开标签访问境外站点验证；若仅对部分应用生效，需要在那些应用里确认代理设置是否与系统一致。
有些配置会把 Selector 套娃：外层分组里可选的不是裸节点，而是另一个子分组。此时你在外层选「自动」或某个地区集合，真正决定线路的仍是下一层；这在图形界面上会表现为多级折叠，耐心展开即可。
一键测速：测的是什么、按钮在哪
CFW 在 Proxies 页通常提供批量延迟测试能力（界面常用闪电图标或英文 Delay / Latency 表述，具体随版本略有差异）。其核心作用是：对当前分组内的候选节点依次发起探测，把结果显示为毫秒数或超时（timeout）。
需要建立的认知是：这个数字表示「连通性延迟」的大致排序依据，而不是带宽合同里的「下行速率」。同样的节点，晚高峰与凌晨测出来可能差一截；个别 UDP 友好但对探测目标不放行的线路，也可能出现「延迟好看但实际业务卡顿」的错位。因此一键测速适合快速筛选明显失效或明显偏慢的选项，而不是一次性定论。
- 全超时：优先怀疑 DNS、本地防火墙、其它全局 VPN 抢路由，或节点本身宕机；也可尝试换测速目标（若高级设置或内核允许）。
- 只有个别超时：多为单线路故障，直接在分组里剔除或忽略即可。
- 数值普遍偏大但能上网：可能与探测路径或 ICMP/TCP 探测实现有关，结合真实网页加载判断。
延迟排序：如何把列表按快慢排整齐
完成一键测速后，界面通常会按延迟从低到高或可切换排序方式展示列表（具体交互因版本而异：有的在列标题点击排序，有的在排序菜单中选择）。「延迟排序」的实际用法是：
- 先测一遍，过滤掉超时项；
- 在存活节点中取延迟较低的前几名作为候选；
- 对候选逐个手动切换，用你关心的业务（网页、视频、游戏）二次验证；
- 网络环境变化时再重复上述流程，不必死守上一次的最优。
如果你使用的是带有 URL-Test（自动测速选线）的分组，内核会按间隔自动重测并切换到延迟最低的可用项；这类分组在界面上可能显示当前自动选中的子节点。手动 Selector 与自动 URL-Test 并不冲突——前者给你「强制钉死某条线」的自由，后者给你「懒得盯列表」的省事。
策略组类型速览：你切换时其实在改什么
不会在本文展开 YAML 手写教学，但认清三类最常见的分组有助于减少「为什么我点了没反应」的困惑：
- Selector：纯手动选择；适合明确知道自己要走哪条线路的用户。
- URL-Test：周期性测速并在候选集合里自动切换；适合订阅里节点很多、希望客户端代为择优的场景。
- Fallback：按顺序尝试可用性，更像故障切换而非比延迟谁更小；表现为「当前挂在第一条还能用的」。
不同机场下发的模板命名五花八门，但万变不离其宗：规则引用哪个分组，你在 Proxies 里就要改哪个分组。若你把节点换在了一个根本没有被规则用到的分组里，表面上「切换成功」，流量却不会跟着走。
与规则模式的关系：系统代理开了也不一定走你选的组
在 General 里开启系统代理后，浏览器会征求系统层的 HTTP 代理设置，但Clash 仍按规则决定每个域名走 DIRECT 还是某个 proxy-group。因此可能出现两种典型误判：
- 某站点在国内 CDN，规则判定直连——你在出境分组里换节点不会影响它；
- 规则把某域名指向了另一个分组（例如流媒体专用组），你却在通用 PROXY 组里折腾。
排查时建议配合 Connections 实时视图：看域名对应的 Policy 或链路的最后一跳是不是你期望的分组与节点。这比反复随机切换更高效。
常见问题：测速、切换与感知不一致
延迟低但实际很慢
延迟只刻画「握手有多快」，带宽与丢包才是视频卡顿的关键。可换一个时段复测，或在多条低延迟节点之间择优试用。
切换节点后网页仍然打不开
按优先级检查：系统代理是否开启；规则是否把该站点直连；DNS 是否泄漏或被污染；节点是否封锁目标域名。必要时暂时切到全局模式（若你的配置提供）做对比测试，再退回规则模式。
自动选线分组里我还能手动干预吗
取决于配置：有些模板把自动分组嵌套在手动分组之下，你可以在上一级手动锁定地区或策略；若纯 URL-Test 外层没有 Selector，强行干预的空间可能较小，需要改配置文件或换用机场提供的「手动」分组。
顺带一提：CFW 停更背景下的长期选择
许多用户仍在沿用 Clash for Windows 完成上述操作，界面路径也早已形成肌肉记忆；但需要诚实告知：原版 CFW 已不再活跃维护，新协议与安全模型更多出现在基于 Mihomo（Clash.Meta）内核的现代客户端里。你在本文里学到的「策略组 + 延迟测速 + 规则排查」这一套思维，可以直接迁移到 Clash Verge Rev 等替代品——差异主要在按钮位置与是否默认集成 TUN，而不是底层分流逻辑。
为什么理清「分组—节点—测速」仍然值得
市面上不少代理工具要么把线路选择藏得很深，要么只给一个简单的开关却说不清流量到底走了哪条策略；一旦遇到问题，用户只能在「全网慢」与「反复重装」之间徘徊。Clash 系客户端的长处在于规则与分组的可视化：你能看见自己是手动 Selector 还是自动 URL-Test，也能用延迟探测快速缩小候选范围，再用连接面板核对真实命中路径。
如果你正在寻找仍在积极迭代内核、并在 Windows / macOS / Linux 乃至移动端保持一套相似操作习惯的方案，迁移到基于 Mihomo 的 Clash 客户端会比死守老旧构建更省心：同样的订阅与分流思路可以继续沿用，却不必为新节点格式或证书链变动反复踩坑。本站提供的 Clash 客户端沿同一套开源生态演进，下载与版本说明集中托管，适合作为长期使用的主力工具。