为什么需要 relay，而不是再套一层「全局」
双跳的本质，是把「出口 A → 出口 B」写成可引用的策略组，让规则只负责决定「哪些域名走这条链」，链路由 relay 固定顺序完成。相比临时把客户端改成全局再手动换节点，relay 的好处是可复现、可对照日志：连接日志里能看到流量最终落在哪条策略上，你也更容易判断问题是第一跳不稳还是第二跳被墙或握手失败。若你尚未在本机装好订阅与图形界面，可先完成 Windows 下 Clash Verge Rev 安装与导入，再回来改 YAML 或覆写。
relay 在 Meta / Mihomo 里是什么意思
在 Clash Meta 系配置中，proxy-groups 下的 type: relay 表示按列表顺序串联多条已存在的代理：流量从本机发出后，依次经过 proxies 数组中的第一项、第二项……直到最后一项再去访问目标。顺序颠倒会直接改变「谁先接触你的设备、谁面向网站」，因此同一组节点交换顺序，语义完全不同。不要把 relay 与单条节点上的 dialer-proxy（为某一节点单独指定「拨号」用的上游）混为一谈：前者是策略组级别的显式链，后者常用于解决「某个节点本身连不上其面板地址」这类单点问题。
1前置条件：proxies 里必须先有两条可用节点
relay 组里只能引用已经在 proxies: 段声明过名称的条目，或引用其它策略组（视你的客户端与配置复杂度而定，入门场景建议只引用具体节点，排错更简单）。名称必须与列表里完全一致，包含大小写、空格与 emoji；引用名写错时，配置往往无法加载，或该策略组在面板里显示异常。若你从订阅导入节点，建议先在面板里确认两条节点的延迟与稳定性，再写入链中，避免把「本身超时」的节点串进 双跳 放大故障。
2可复制骨架：proxy-groups 的 relay 写法
下面是一段示意 YAML，请将 HOP1、HOP2 换成你配置里真实存在的节点名，将 RELAY-CHAIN 换成你想在规则里引用的策略组名。保持顺序即链路方向：列表自上而下为第一跳至最后一跳。
# Example — replace HOP1/HOP2 with real proxy names from your proxies: section
proxy-groups:
- name: RELAY-CHAIN
type: relay
proxies:
- HOP1
- HOP2
rules:
- DOMAIN-SUFFIX,example.com,RELAY-CHAIN
- MATCH,DIRECT
在 rules 里，把需要走双跳的域名或规则指向 RELAY-CHAIN，而不是指向其中某一跳单独的名字。若你同时使用 GEOIP / GEOSITE 分流，请注意规则顺序：更具体的域名规则应出现在过于宽泛的 GEOIP,CN,DIRECT 或 MATCH 之前，否则流量可能在到达 relay 组之前就被其它条目截走。
典型用途：落地、解锁与隐私（思路层面）
实务上，读者常把第一跳放在更接近自己网络的位置以降低丢包，把第二跳放在目标业务所需地区；也有人反过来的需求，取决于你的节点质量与风控策略。本文不评价哪种拓扑更「正确」，只强调：先想清楚你希望网站看到的出口是哪一跳，再把那一跳放在链的最外侧（通常是最靠近目标站点的最后一跳）。涉及账号风控、支付与地区检测的场景，双跳并不能保证绕过平台规则，仍需自行评估合规与条款。
3relay「不生效」时，先查规则有没有真的指向该组
最常见的误判，是改了 YAML 却在连接日志里看到流量仍走 DIRECT 或别的策略组。请按顺序核对：① 当前模式是否为规则模式；② 命中的究竟是哪一条 rules（含 Rule Provider 展开后的顺序）；③ 该条目的目标是否为你在面板里看到的 relay 组名。若 HTTPS 仍显示为 IP，可结合 Sniffer 嗅探 与域名规则，避免「想按域名分流却只能匹配到 IP」。
4DNS 与 FakeIP：为什么「链对了」仍像走错路
即便 relay 组配置正确，若 DNS 解析路径与 Clash 的 FakeIP、fake-ip-filter 不一致，仍会出现规则看似命中、实际连接目标与预期不符的现象。系统浏览器 DoH、系统缓存与 Clash 内置 DNS 混用时尤甚。建议系统阅读 Meta 内核 DNS 防泄漏指南，把「谁负责解析、谁持有 FakeIP 映射」梳理清楚后，再回头确认 relay 是否被错误结论误导。
5UDP、QUIC 与游戏语音：双跳下的额外变量
部分协议与应用强依赖 UDP（如 QUIC、部分游戏与语音）。链式代理中，任一一跳对 UDP 支持不佳，都会表现为「网页能开、视频通话卡顿」或「TCP 正常、UDP 全挂」。排查时可在可控环境下暂时关闭 HTTP/3 / QUIC 做对比，或改用对 UDP 更友好的节点；若需进程级统一接管，可配合 Clash Verge Rev TUN 模式，避免部分应用绕过系统代理导致你以为走了 relay、实际未进内核。
推荐排查顺序：规则命中 → DNS → 节点与 UDP
为减少无效折腾，建议固定顺序：第一步在连接日志中确认当前连接对应的策略组是否为预期的 relay 组，以及规则条目是否符合域名或进程预期；第二步核对 DNS、FakeIP 与 DoH 是否与规则决策一致；第三步再分别对链中第一跳、第二跳做单跳测试（临时用普通 select 或 url-test 组对比），定位是某一跳不稳定还是 UDP 路径问题。多数「配置了 relay 却感觉不到」的案例，会在前两步发现根因。
常见配置误区速查
名称不一致： relay 组引用的字符串与 proxies 中名称有任何差异都会导致加载失败或静默回退，务必复制粘贴核对。
规则指向了子节点而非 relay 组： 只把其中一跳写进规则，自然不会形成双跳语义。
过度嵌套： 在复杂订阅里把多个策略组互相引用，排错难度陡增；入门阶段尽量保持「relay 组 → 两个实体节点」的扁平结构。
合规提醒：请仅在法律与网络使用政策允许的范围内使用代理与加密隧道；勿将本文用于绕过合法监管要求的场景。
关于下载：开源内核与客户端的源码可在 GitHub 查阅；日常获取安装包请优先使用 本站下载页，与仓库发行页区分使用。
小结
在 Clash Meta / Mihomo 中配置链式代理，核心就是在 proxy-groups 里声明 type: relay，并用 proxies 列表明确双跳顺序，再在 rules 里把目标流量指向该组名。若relay表现异常，优先用日志确认规则是否真的命中该组，其次对齐 DNS 与 FakeIP，最后再拆链检查各跳与 UDP 能力。把本文与站内 GEOIP、Sniffer、DNS 与 TUN 教程串联，你可以在同一套客户端里既做细粒度分流，又能在需要时叠加可控的多跳出口。
相比在多个独立工具间手动切换线路，在同一套图形客户端里维护订阅与覆写，长期更可复盘；当你需要为特定业务固定一条可验证的双跳路径时，relay 是最直接的结构化手段之一。