Clash 与 Mihomo relay 代理链多跳 YAML 配置与策略组挂接逐步排查

文章目录

一、relay 代理链在 Clash / Mihomo 里是什么

在 Clash Premium、Clash Meta 以及基于 Meta 的 Mihomo 等分支里，proxy-groups 除了常见的 select、url-test、fallback、load-balance 之外，还可以声明 type: relay。它的作用是把多条已定义的 proxies 串成固定顺序的代理链（多跳、proxy chain）：本地应用先把流量交给 Clash，Clash 再按列表依次把连接递交给链上的每一跳，直到最后一跳去访问目标站点或服务。

这和你在 GUI 里手动「选了一个节点」不同：relay 是配置层面的绑定，不依赖你在面板里点哪一行。它适合这几类诉求：需要前置跳板（例如先进一台内网或低风控入口，再出公网）、希望某几条业务流量固定走同一串出口、或在测试时强制经过指定多跳路径以便抓包对照。若你只是想让策略组自动选延迟最低的节点，应优先用 url-test，而不是把很多节点硬塞进 relay；二者也可以组合——例如 url-test 在若干「单跳策略组」里选节点，再由 relay 引用这些组名（见第四节）。

阅读日志时，链式连接往往在时间上呈分段：先看到连向第一跳地址，再看到经第二跳访问目标。若你同时开了详细日志，请把同一域名或同一连接 ID相邻的几行一起看，避免把「第一跳的 dial 失败」误判成「网站本身打不开」。下文会把典型报错与检查项对应起来。

小贴士：relay 里的每一项必须是已存在的代理名（在 proxies: 或 proxy-providers 展开后的名字），拼写与大小写要与引用处完全一致；订阅合并后名字被改写时，最常见的就是「配置校验通过但运行时找不到 proxy」。

二、YAML 最小写法与 proxies 引用

下面是一段示意配置（字段名与缩进需与你的完整配置一致；片段仅说明 relay 结构，省略了 port、dns、rules 等全局段）。思路是：先在 proxies 里定义两跳真实节点，再声明一个 relay 组把名字按顺序列出来。

proxies:
  - name: "hop-entry"
    type: ss
    server: entry.example.com
    port: 8388
    cipher: aes-128-gcm
    password: "secret"
  - name: "hop-exit"
    type: vmess
    server: exit.example.com
    port: 443
    uuid: 00000000-0000-0000-0000-000000000000
    alterId: 0
    cipher: auto
    tls: true

proxy-groups:
  - name: "CHAIN-RELAY"
    type: relay
    proxies:
      - hop-entry
      - hop-exit

要点有三条。第一，proxies 列表里的每一项 name 必须唯一。第二，relay 下的 proxies: 是有序列表：写在前面的先接本地出口，写在后面的承接上一跳的转发；这与部分人直觉里「先写出口」相反，第三节会画图说明。第三，链上每一跳的协议能力要真的能转发 TCP（以及你业务需要的 UDP）；若某一跳是仅适合浏览器插件的畸形节点或已被服务端禁止二级连接，会在 dial 或 TLS 阶段失败。

若节点来自 proxy-providers，只要合并后的名字在运行时可解析，同样可以写进 relay；更新订阅后若名字变化，要同步改 relay 列表。建议在改完 YAML 后使用客户端自带的配置校验或命令行 dry-run（视发行版而定），再重载，避免半份错误配置让全表策略组失效。

三、多跳顺序：流量到底怎么走

对 type: relay 而言，Clash 的约定可以记成一句话：列表从上到下，就是流量从「靠近你」到「靠近目标站」的方向。以上面示例为例，应用 → Clash → hop-entry → hop-exit → 互联网目标。若你把两行对调，实质就变成先连 exit 再连 entry，往往立刻出现无法建立第二跳或认证失败，因为服务端期望的连接方向已经反了。

把顺序写反是最常见的「配置语法没错但怎么也通不了」的原因之一。核对方法很简单：在脑中画一条箭头，从本机指向网站；箭头上的第一个中继必须是你能直接 dial 通的那台（或那组策略），最后一个必须是能访问公网目标的那台。若中间还要再嵌套公司代理、堡垒机之类，就继续往列表里加，但每加一跳，延迟与失败面都会放大，日志也更容易让人看花眼。

和「嵌套 selector」的区分

有人会把 relay 与「在规则里先 MATCH 到 A 组再 MATCH 到 B 组」混为一谈。规则多次命中仍然是单次出站选择；relay 则是在同一出站实体内部完成多跳转发。若你需要「入口固定、出口在多个节点里自动选」，常见做法是：relay 的第二段引用一个 url-test 或 select 组名（若你的内核版本与文档允许该组合），或拆成两条业务规则分别实验；具体以你所用内核文档为准，改完务必用实际访问验证。

四、挂进 selector、url-test 与规则

声明好 CHAIN-RELAY 之后，它可以像普通策略组一样出现在别处：例如总开关 select 的 proxies 列表里多一行 CHAIN-RELAY，或在 rules: 末尾之前用 DOMAIN-SUFFIX,example.com,CHAIN-RELAY 让特定域名强制走链。关键是规则命中的名字必须与你 proxy-groups 里的 name 一致；GUI 若显示本地化别名，以导出的 YAML 为准。

若全局 url-test 总在切换节点，而你希望某域名稳定走 relay，应为该域名写更高优先级的 DOMAIN / GEOSITE 规则，再让默认组继续 url-test。关于 interval、容差与懒切换，可参考《Clash 策略组 url-test 总跳到慢节点？interval 与容差逐步调优》，避免 relay 与自动选组逻辑打架。

调试阶段建议先在面板里手动选中 relay 组，确认浏览器访问正常，再把规则写死；这样一旦失败，你可以确定问题在链本身而不是规则优先级。需要对照 Web 面板端口、secret 与监听地址时，可配合《Clash 外部控制器打不开？核对 bind-address 与 secret 逐步操作》，避免边改链路边连不上 Dashboard。

注意：不要让 relay 的 proxies 列表在间接意义上引用回包含自身的 selector，否则容易形成循环依赖；内核会报循环引用类错误或在重载时拒绝配置。设计组结构时先画依赖图再写 YAML。

五、常见报错与日志对照表

不同客户端对同一内核错误的文案可能略有差异，下列关键词用于在日志里「按图索骥」。若你看到的是 TLS 阶段卡住，还可对照《Clash 日志出现 TLS Handshake Timeout？按节点、SNI 与规则逐步定位》，把「链上某一跳」单独抽出来当作单节点问题分析。

日志或现象线索	优先检查
proxy not found / 找不到代理	`relay` 列表中的名字是否在 `proxies` 或 provider 合并结果里存在；订阅更新后是否改名；YAML 缩进是否把组归到了错误层级
circular reference / loop	selector 与 relay 是否互相引用；是否让 relay 包含了会指回自己的组
dial tcp / connect: connection refused / timeout	第一跳地址与端口是否可达；是否把「应先连的跳」写反；防火墙或运营商是否阻断出站；该跳是否允许二级代理连接
EOF、reset by peer、i/o timeout	链上中间跳是否主动断开；是否触发了服务端并发或协议限制；尝试缩短链或更换中间协议（如 TLS 与 WS 组合）
TLS / handshake / certificate	单独测每一跳的 TLS；`sni` 与证书是否匹配；是否只有某一跳需要额外 `skip-cert-verify`（谨慎使用）
配置重载失败但旧配置仍运行	导出当前运行配置对比；检查 relay 是否引用了尚未加载的 provider；查看完整报错栈而非仅 GUI 弹窗

排错时请坚持每次只改一个变量：先验证两跳各自单独作为出站是否可用，再合并为 relay；若合并后失败而单跳均正常，则重点查顺序、循环引用与中间跳是否允许转发。把失败时前后若干行日志保存成文本，比在论坛口述「打不开」更能快速定位。

六、验证步骤与和单节点对照

推荐按下面顺序自测，全部做完通常不超过十几分钟。第一步，在策略组中仅选第一跳节点访问一个稳定 HTTPS 站点，确认单跳正常。第二步，仅选第二跳重复同样测试。第三步，启用 relay 再测同一站点，若第三步失败而前两步成功，几乎可以肯定问题在链路与顺序而非网站本身。第四步，打开详细日志，标出失败发生在第几跳的 dial，回到第五节表格替换检查项。

若你在桌面使用系统代理或 TUN，请确认没有第二个软件在同一进程路径上再次嵌套代理，否则日志里会出现「看似多跳、实际重复封装」的混乱。更系统的 DNS、fake-ip 与规则优先级说明见本站配置文档；当 relay 与复杂规则表叠在一起时，先简化规则再扩链，能节省大量时间。

Mihomo 与各 GUI 发行版对 relay 的语法一致，但面板展示可能对链式连接做折叠显示；以日志与导出 YAML 为准。若你使用仅支持subset 的旧内核，请先升级或改用文档标明支持 relay 的版本，否则配置会被静默忽略或降级成首跳。

七、小结

Clash relay 代理链用 type: relay 与有序 proxies 列表，把多跳路径写进同一条出站实体；理解从上到下即从你到目标的顺序，是避免「配了却全红」的第一步。把 relay 挂进 selector 或 url-test、再用规则精确分流，可以实现前置出口与固定链路；日志里出现 dial、TLS 或循环引用时，按本文表格逐项核对，并配合单跳对照实验，通常能快速收敛原因。

相比其他同类工具，Clash / Mihomo 在规则与组类型上的组合更灵活；把 relay 与测速组、域名规则分层使用，既保留自动选路，又能给关键流量加一层可控的多跳。若你正在本地搭验证环境，建议从最短两跳开始，稳定后再加第三跳，以免一次变量过多难以归因。

→ 立即免费下载 Clash，开启流畅上网新体验