為什麼要用 relay？雙跳在解決什麼？
一般「單一節點」策略是：連線命中規則後，直接送到某個 proxy 名稱所代表的節點。relay 則把多個已存在的節點串成鏈：資料會依序經過清單中的節點，形成雙跳（兩節點）或更多跳數。實務上常見動機有三類：（1）落地——希望最後一段出口落在特定區域；（2）解鎖——第一段負責穩定連線、第二段負責對應服務的區域判定；（3）隱私／分層——把「誰看得到您連到哪裡」與「對外顯示的來源 IP」拆開理解（但仍需搭配 TLS、DNS 與應用程式行為，避免誤以為雙跳就自動匿名）。
與「在單一節點上設定 dialer-proxy（用另一個節點去撥號連線）」類的進階寫法相比，proxy-groups 的 relay 更直覺：讀設定的人一眼就能看到鏈路順序，也方便在圖形介面裡選「策略組」而非深層節點欄位。本文以 relay 為主軸，避免把兩種機制混用時造成混淆。
1proxy-groups：relay 的標準寫法
在 proxies（或訂閱合併後的節點表）裡，您必須先有兩個可被引用的節點名稱。接著新增一個策略組，type 設為 relay，並在 proxies 陣列中依序列出要串接的節點名稱。順序非常關鍵：第一個名稱通常是入口側先接觸的節點，之後再轉發到第二個；若您把順序顛倒，體感會變成「出口 IP／延遲」完全不如預期。
# Snippet — relay group; proxy names must exist under proxies
proxy-groups:
- name: RELAY-CHAIN
type: relay
proxies:
- NODE-A
- NODE-B
接著，在 rules 裡把需要走這條鏈的流量，策略欄位寫成策略組名（上例即 RELAY-CHAIN），而不是只寫其中一個節點。若您仍把規則指向 NODE-B，核心就不會自動幫您套用 relay，這是最常見的「我以為有雙跳」的誤會。
小結：relay 的本體是一個策略組名稱；規則要指到這個名稱，雙跳才會生效。
2與 select／url-test 並存時怎麼接？
許多使用者習慣把「最終出口」放在 select 或 url-test 組裡。當 relay 需要「可選」的第二跳時，常見做法是：先定義純節點，再用 relay 組合；或把 relay 組本身再放進外層 select 的候選清單。重點是名稱引用鏈不得循環（A 組包含 B，B 又反過來包含 A），否則載入會失敗或行為未定義。
實務上建議維持扁平、可讀：中繼與出口各自是明確節點，relay 組只負責串順序；需要切換時，優先切換外層 select 或替換 relay 清單中的第二個名稱，而不是在訂閱自動產生的深層結構裡硬塞。
3規則順序：為什麼「已寫 relay 卻沒走到」？
Clash 系規則是由上而下、先命中先贏。若您有一條很寬鬆的 MATCH 或其他策略組先攔截了流量，後面針對特定網域寫的「走 relay」可能永遠輪不到。這與 GEOIP／GEOSITE 分流 裡常見的「順序錯置」是同一類問題，只是策略從 DIRECT／PROXY 換成了 RELAY-CHAIN。
另一個高頻原因是：HTTPS 場景下，規則引擎在決策時只有 IP、沒有域名，導致 DOMAIN／GEOSITE 類規則不生效，流量落到後段的 IP 規則或 MATCH 上——於是您看到「怎麼走都像沒走我寫的 relay」。此時應回到 Sniffer 與 DNS 設定，確認日誌裡能出現主機名，讓域名規則有材料可用。
4DNS、FakeIP 與「分流看起來對、鏈路卻怪」
當您使用 FakeIP 或較複雜的 dns 分流時，常見症狀是：瀏覽器顯示連線成功，但實際命中規則與您想的不同，或解析路徑與 rules 預期不一致。relay 不會 magically 修復 DNS；它只是在「已經決定要走的策略組」之後，把連線依序轉交。若 DNS 階段把域名解析到「另一個出口語意」的結果，後面規則再怎麼寫都可能對不起來。
建議把 DNS 教學 裡的「fake-ip、nameserver-policy、fallback」與本設定一起對照，並用連線日誌確認：第一條命中規則、策略名稱、以及實際節點是否為 relay 展開後的兩段。一次只改一個變因，避免 DNS 與 relay 同時調整導致無法歸因。
5UDP、雙跳與協議限制
需要 UDP 的應用（常見如遊戲、部分語音、QUIC）在 relay 鏈上會比單節點更敏感：若第一段或第二段節點／協議對 UDP 支援不完整，整條鏈就可能失敗或退回非預期行為。排查時請先確認兩個節點各自單獨使用時 UDP 是否正常，再啟用 relay；若單跳都會掉，雙跳不會自動變好。
另外，某些傳輸在「被中繼」時會有額外延遲或 MTU 相關問題；這屬於網路路徑特性，不是單靠改 YAML 就能保證。若您只關心網頁／TCP，優先驗證 TCP 路徑與規則命中即可。
建議的故障排查順序（可當檢查清單）
- 規則命中：在日誌確認第一條命中的規則是否把流量指向您的 relay 策略組名稱，而不是指到別的組或
DIRECT。 - 策略組名稱：確認
rules內拼字與proxy-groups的name完全一致（大小寫、底線、訂閱覆寫後是否改名）。 - relay 成員：確認
relay的proxies清單內，兩個名稱都真的存在於proxies、且順序符合您要的入口／出口語意。 - HTTPS 域名：若域名規則長期不觸發，檢查 Sniffer、DNS 與
rules前段是否有更寬鬆的 IP 規則先命中。 - DNS 行為：對照 FakeIP／DoH 設定，避免解析與規則「各說各話」。
- UDP／協議：針對需要 UDP 的程式，分別驗證兩節點與整條 relay。
提醒：代理與路由設定須符合所在地法規與服務條款；教學僅供合法合規的網路除錯與自用學習。
可照抄的最小骨架（請再合併訂閱與節點區塊）
下列片段示範 relay 策略組 與 規則銜接 的相對位置；註解使用英文以利部分解析器相容。請與您的 proxies、dns、tun 合併，並以實際節點名稱替換 RELAY-UP／RELAY-DOWN。
# Minimal skeleton — merge with your proxies, dns, tun
mode: rule
log-level: info
proxies:
- name: RELAY-UP
type: ss
server: 198.51.100.10
port: 8388
cipher: aes-256-gcm
password: "REPLACE_ME"
- name: RELAY-DOWN
type: vmess
server: 203.0.113.20
port: 443
uuid: 00000000-0000-0000-0000-000000000000
alterId: 0
cipher: auto
proxy-groups:
- name: RELAY-CHAIN
type: relay
proxies:
- RELAY-UP
- RELAY-DOWN
- name: PROXY
type: select
proxies:
- RELAY-CHAIN
- RELAY-DOWN
rules:
- DOMAIN-SUFFIX,example.com,RELAY-CHAIN
- MATCH,PROXY
上例中，example.com 走雙跳；其餘流量進入 PROXY 這個選擇組，您可自行決定是否把 RELAY-CHAIN 當預設。若您希望「全站預設就雙跳」，把 MATCH 直接指向 RELAY-CHAIN 即可，但請務必評估延遲與節點穩定性。
開源資訊與安裝包取得方式
Mihomo 上游以開源方式維護，查閱版本變更與 Issue 時適合前往公開程式庫。日常安裝或更新圖形客戶端，建議優先使用 本站 Clash 下載頁，並搭配 設定說明文件；將「取得安裝包」與「閱讀原始碼」分開，可避免誤以為必須自行從 Release 頁拼裝環境。
結語
relay 的本質很單純：在 proxy-groups 裡用 type: relay 定義鏈式代理，並讓 rules 明確指向這個策略組名稱。真正耗時間的，多半是規則順序、HTTPS 域名是否可得（Sniffer／DNS），以及UDP 與協議是否在兩段節點上都成立。把排查固定成「先命中、再 DNS、再節點能力」，通常比反覆改訂閱更快定位。
相較於在介面裡只切換單一節點卻期待出現雙跳，直接把 relay 寫成可選策略組，並用日誌驗證策略名稱與鏈路順序，長期維護成本會低很多。這也是 Clash Meta／Mihomo 在進階場景裡值得掌握的寫法。