本稿で扱う範囲と典型ユースケース
relay を使う動機は環境ごとに違いますが、コミュニティでよく聞くのは次のようなものです。プライバシーのため、まず信頼できる中継へ載せてから別地域のランディングノードへ出したい。地域制限の解除のため、まず安定した入口を確保し、二段目で目的の国・ASN に寄せたい。運用面では、フェイルオーバーや URL テスト付きのグループとは別軸で、意図的に二ホップ固定にしたい場合もあります。いずれも単一の select ノードでは表現できず、チェーン型の proxy-groups が役に立ちます。逆に、レイテンシを最優先する用途ではホップが増える分だけ不利になるため、速度勝負のゲームやリアルタイム通話では二段化を避けるか、対象アプリだけ別ポリシーに逃がす設計が無難です。
type: relay が表すもの
Mihomo／Clash Meta 系の設定では、proxy-groups に type: relay を指定したエントリがチェーンプロキシを表します。proxies: 配列に並べた名前は、通常先頭から順にトラフィックが流れ、最終的にリストの末尾側に近いノードがインターネット側の出口に相当するイメージで捉えると説明しやすいです（実装の細部はバージョンのリリースノートを参照してください）。ここで重要なのは、単なる url-test や fallback の束ね方とは別物だという点です。relay は順路を固定して積み上げるため、名前の綴りや参照ミスがそのまま「チェーンが組めない」エラーや、意図しない単一ノード利用につながります。
整理：proxies セクションに定義したノード名を relay グループの proxies: に並べます。存在しない名前や、購読のマージ結果で重複・改名が起きていると、GUI 上では見えていても実体が解決できないことがあります。
コピペ用スケッチ：proxies と proxy-groups
以下は説明用の骨子です。実際のプロトコル行（server・port・uuid 等）は、利用中の購読または自前ノードに合わせてください。HOP1 を入口、HOP2 を出口寄りと読み替えると理解しやすいです。
# Sketch — replace node names with your profile; align keys with core version
proxies:
- name: HOP1
type: ss
server: example-hop1.example
port: 8388
cipher: aes-256-gcm
password: "REPLACE_ME"
- name: HOP2
type: vmess
server: example-hop2.example
port: 443
uuid: 00000000-0000-0000-0000-000000000000
alterId: 0
cipher: auto
tls: true
proxy-groups:
- name: RELAY-CHAIN
type: relay
proxies:
- HOP1
- HOP2
- name: PROXY
type: select
proxies:
- RELAY-CHAIN
- HOP2
- DIRECT
上では PROXY というよくある名前の選択型グループから RELAY-CHAIN を選べるようにしています。実際のプロファイルでは GLOBAL や購読側の ♻️ 自動选择 など、ルールが最終的に指しているポリシー名と整合させる必要があります。relay グループ自体をルールで直接指すのではなく、上位の select に載せてから選ぶ構成もよく見られます。
ルール側が別のポリシーを指していないか
「relay を書いたのに効かない」という相談の多くは、ルールがそもそもそのグループを経由していないケースです。例えば MATCH より上に GEOIP,CN,DIRECT のような行があり、対象トラフィックが先に DIRECT に落ちていると、チェーンは使われません。また DOMAIN-SUFFIX が別のポリシー名を指している、より上の行で既に決着している、といったルール順の問題も典型です。国情報やドメイン集合を使う場合は GEOIP／GEOSITE 分流ガイド の「評価順」と no-resolve の扱いを併せて確認してください。HTTPS が IP 表示のままでドメインルールに乗らないときは、Sniffer によるドメイン復元が必要になることがあります。
DNS：名前解決がチェーンの外で起きていないか
トラフィックは relay に載ったつもりでも、DNS クエリだけ OS やブラウザの経路で処理されていると、見かけ上の「出口」と実際の接続先が食い違います。特に FakeIP とルールの組み合わせでは、どの段階の名前解決がルール評価に使われるかをログで確認するのが近道です。Meta コア DNS リーク防止ガイド で述べているとおり、nameserver-policy や DoH の向き先が意図とズレていると、分流が一貫しません。切り分けでは「接続ログに出るターゲットが期待どおりか」「ルールに使われたドメイン／IPがどこで解決されたか」をセットで見ます。
UDP と QUIC：ノード能力とプロトコル
二段の UDP 転送は、単一ノードのときより失敗しやすい場面があります。中継とランディングの両方が UDP を扱えること、クライアント側で QUIC が意図せず直結していないこと、ゲームや VoIP が プロキシをバイパスしていないことを確認します。ブラウザが HTTP/3（QUIC）で別経路を使う場合、見かけ上「relay したつもりのドメインだけ遅い」こともあります。切り分けとしては、問題のアプリで一時的に HTTP/2 優先にする、対象を TUN で覆う、などを検討します（TUN 全般は各クライアントのガイドへ）。
効かないときの確認順（おすすめ）
- コアの読み込みエラーがないか：YAML の文法、
relayが参照する名前がproxiesに存在するか。 - GUI で実際に選ばれているポリシー：
RELAY-CHAINではなく別ノードが選択されていないか。 - ルール命中：対象トラフィックが
MATCHまで届く前に別ポリシー（例：DIRECT）になっていないか。 - DNS 整合：FakeIP／DoH／OS 解決のどれが使われているか、ルール評価と矛盾していないか。
- UDP／QUIC：該当アプリが TCP だけrelayに載り、UDP が別経路になっていないか。
- 片側ノードの健全性：一段目だけ遅延が悪い、片方がブロックされている、などを個別に切り分ける。
注意：二段プロキシは利用規約と法律の両方に抵触しないことを確認してください。職場・学校・サービス利用契約で禁止されている場合は設定しないでください。
他記事との棲み分け
本稿は relay 型 proxy-groups に焦点を当てています。GEOSITE や GEOIP でどこを切るかは GEOIP／GEOSITE 記事、DNS リークや FakeIP は DNS ガイド、HTTPS のドメインが見えない問題は Sniffer 記事が主役です。必要に応じて併読し、チェーン本体の YAMLと分流・名前解決の両方を同じ作業セッションで揃えると、再現性の高い構成に近づきます。
ドキュメントとクライアント入手
relay の詳細や追加キーは、利用中の Mihomo バージョンの公式ドキュメントが最終判断基準です。日々のクライアント入手は 公式ダウンロードページ を第一にし、用語の整理は ドキュメント・チュートリアル も活用してください。ソースコードや Issue は GitHub で公開されていることが多いですが、インストーラの取得先と混同しないよう、配布物はサイト側を正とするのがおすすめです。
まとめ
Clash Meta／Mihomo で双跳を実現するには、proxy-groups に type: relay を置き、proxies に定義したノード名を意図した順序で並べます。あわせて、ルールがそのチェーンを指しているか、DNS が分流と矛盾していないか、UDP／QUIC が別経路に逃げていないかを、上から順に潰していくと原因が切り分けしやすいです。分流の地図だけ整えても、チェーン名のタイポ一つで「効いていない」ように見えるのがこの種の設定の難しさです。ログと YAML を突き合わせながら、一段ずつ確認するのが2026年現在もっとも確実です。
GUI クライアントではポリシー名が階層化されやすく、購読更新で名前が変わると relay の参照が静かに壊れることもあります。安定運用では、自分で命名したチェーンとルールで参照する名前を一箇所にコメントでメモしておくと、数か月後の自分への親切になります。同様に、他ツールよりルールとプロファイルの見通しが良いのが Clash エコシステムの強みです。