一、relay（多跳の proxy chain）で何を実現するか
単一の proxies 定義は「自端末から最初に張る 1 本の暗号化トンネル」に過ぎません。配信者や利用規約、レイテンシ、可用性の都合で「安価な中継地から一度入り、最終的には別国の静かな 出口に出したい」という要望に、type: relay の連鎖型プロキシ（いわゆる proxy chain、日本語圏でよく言う 多跳）が向きます。Clash コアの中では Mihomo／Clash Meta 系がこの手の拡張に強いとされ、YAML 上の名前解決の規則も含め、GUI が背後で生成する設定と食い違うと一気に不具合が出ます。まず「どの層のプロキシ名が、どの proxy-groups に載っているか」をダッシュボードの一覧と食い合わせ、必要な型名は ドキュメント索引で自ビルドに合わせてから、relay を足してください。
二、YAML 最低限：proxy-groups の type: relay
実装差は排除できないため、下の抜粋は骨格と捉え、実際のキー名は 公式ドキュメント索引に合わせてください。proxies 配列に並べた既存のプロキシ名を、先頭から順に連結します。ここに書く名前は、トップレベル proxies・proxy-providers 取り込み後に有効化済みの識別子と一字一句揃えます。サンプル名は仮想です。
# relay skeleton — adjust to your Clash / Mihomo build
proxy-groups:
- name: CHAIN-JP-US
type: relay
proxies:
- tokyo-hopp # 1st: client → this hop
- seattle-exit # 2nd: first hop → this exit
- name: PROXY-SELECT
type: select
proxies: [DIRECT, CHAIN-JP-US, another-node]CHAIN-JP-US 自体を別の relay の内側に戻し込まない限り、通常は 2〜3 ホップ程度までが扱いやすいです。Provider が遅延ロードのとき、名簿が空の瞬間にだけ「存在しないプロキシ名」を参照し、起動直後のログに not found が出る点にも注意が必要です。
三、ホップ順を取り違えない
多くの実装で、proxies の上から順に「自端末側 → 中継 → … → 最終出口」へと積み上がります。いま得たいのが「最終的にどの国の公網 IP でサイトを開きたいか」なら、配列の最後にその出口候補を置く、という合わせ方が多いです。逆順にしてしまうと、遅延が二重に乗るだけでなく、審査ロジックの厳しいサービスで不自然な TCP 断片のように扱われ、TLS ハンドシェイク付近のログに現れることがあります。試験時は一時的に select グループで第 1 ホップだけ・最終出口だけ、と単体で張れるか先に切り出すと、原因が中継か出口か分離しやすいです。
relay を敷き詰めず、select や url-test 側に候補をまとめた方がメンテしやすい場面が多いです（次章）。
四、策略グループ（select 等）と ルールへ載せる
CHAIN-… のような relay 名は、最終的に rules から到達する proxy-group（例：手動 select、url-test、fallback）の proxies リストに含めます。忘れがちなのは「ルールが指している最上位のグループ名」と「ダッシュボードで触っている表示名」が、GUI 再生成で毎回上書きされることです。テスト中は一時的に GLOBAL 系やメイン select へ直接 relay を指させ、期待どおり 2 段の dial がログに出るか確認してから、細かい rule-providers に戻すと安全です。外部コントローラ経由で REST から proxies 一覧を取る場合も、relay が1 行の仮想プロキシとして見える点を押さえてください（内訳の各ホップは下位参照になっているため、単体「遅延」表示だけでは足りないことがあります）。
五、典型の設定ミスと循環
よくあるのは、proxies 欄の綴りがトップレベル定義と 1 文字違い、proxy-groups 名同士の自己参照（relay の中に、自分自身を含む上位 select 名を入れてしまう等）、relay 名と同名の rule-providers タグを人間が混同する、の三つです。これらは起動直後のログに「スキームが解釈できない」「プロキシが存在しない」といった文面で現れ、ブラウザ側では真っ黒な connection reset になりがちです。長い relay 列は一方向にだけ流れているか、GUI のノード図（ある場合）で戻り矢印が生じていないかを見直してください。さらに、fake-ip モードで中継ホップ向けの名前解決が想定外のゾーンに飛び、第 1 ホップの dial から失敗する例も忘れがちなので、DNS を通常モードに切り替えた対照試験を挟む価値があります。
六、dial 系ログの読み方（多跳のどこで落ちたか）
ログの dial、connect、read tcp といった行は、単一トンネルでも読みづらいのに、relay では層が積まれる分、見かけ上「同じ文面の繰り返し」に見えます。多くの場合、時刻の近い 最初の失敗行が第 1 ホップ、続く 到達先 IP:ポート の変化が第 2 ホップ、という層取りができます。いきなり最終出口の timeout だけ出るのに実際は中継で詰まっている、という取り違いを防ぐには、relay を一時的に外し、候補ノードを単体の select へ直結して比較するのが最速です。TLS 以降の失敗に見える事象は SNI やハンドシェイク、UDP を伴う帯域では TUN や端末差の TUN／ファイアウォールの記事も併用してください。Linux 常駐なら systemd 再起動直後だけ Provider が遅れ、一瞬だけ中継名が not found というパターンも珍しくありません。
ログ行をメモに写すときのコツ
スクリーンショットではなく、テキストで抜粋する習慣をつけると、コミュニティに状況を聞きに行く際も重宝します。まず 時刻と、失敗行に出てくる IP アドレスとポートを抜き出し、つづけてその直前に proxy 名が出ていないかを探してください。中継・出口の どちらのホストに向いている dial なのかが分かると、いま持っている relay の配列順と即座に照合できます。GUI の「接続一覧」に表示される宛先と、裏で実際に張られているチェーンのホップ数が食い違うときは、compatibility 系のオプションや旧式クライアントの混在、あるいはルール上別グループに逃げている疑いを立て、一時的に GLOBAL 相当へ固定して relay 名だけ通す、という小さな実験に落とし込めます。どうしても層が読めないときは、まず 2 ホップに圧縮して挙動を切り、あとから 1 本だけ足す段階的なやり方が安全です。
七、url-test や測速との関係
url-test は、グループ内の候補を個別に測ります。ここに relay 名を混ぜると、「鏈の全体レイテンシ」として解釈されるのか「末段ノードのスコア」に偏るのか、体感と測定のズレが生じることがあります。まず interval・tolerance の整理を終え、次に relay の各ホップを一本ずつ select へ戻し、遅延の主因が中継か出口か数値化します。MCP 等の長接続文脈は MCP 記事と重なるため、relay を維持しつつルール分離をしたい場面の参考にしてください。Android では画面が狭く設定が圧縮されがちなので、Clash Meta for Android 側の購読取り込み直後にだけ構文が崩れないか、PC で開いた 同一 YAML の差分も見ておくのが安全です。
八、関連リンク集
本稿の内部リンクを箇条書きで再掲します。
九、まとめ
Clash／Mihomo で relay による 多跳を組む作業は、YAML 上の名前一貫性、proxy-groups への正しい組み込み、dial ログの層に読み、という三段に分解できます。中継と出口の役割を紙に書き、テスト中は一時的に relay を外して単体 select へ戻し、戻し込みのたびにログを 1 回だけ鮮明に残す。こういう作業日誌型の方針は、策略グループ内で 測速を回しているときの混乱も減らします。安定した GUI とログを一緒に揃えたい方は、まず 配布ページのクライアントで現行ビルドを当て、再現手順のスクリーンショット付きで Issue を出せる体制にすると、コミュニティの助言も得やすくなります。ソース追跡が必要なら各プロダクト名に従い、公式の GitHub 等の案内先を併用してください（インストール包の主な入手先は同じ ダウンロードページとします）。