一、何時用 relay 代理鏈？
若你的目標是「從本機出發，固定先連到 A，再從 A 所處的網路環境連到 B，最後才連向網站」，便是在做多跳。典型動機包括：內部網路必須先接某台可 SSH／VMess 的中繼、再把第二段掛在機場的節點、或實驗兩層加密的串接效果。relay 在設定檔裡是一條與 ss、vmess 等平行的邏輯節點，本身不佔一個實體遠端，而是引用既有的節點名稱並規定先後順序。相對地，單一出口節點就能完成的需求，不應硬搬 relay，否則延遲與斷線點都會變兩倍，除錯時也更難判斷是第一跳還是第二跳出問題。若你完全沒有寫鏈的經驗，建議先確保兩條實體節點在普通策略裡分別能獨立連通，再合併成 relay；若單一節點就連不上，可平行參考 訂閱與節點解析 或 TLS 與 SNI 相關日誌 的專文，那裡的檢查步驟與鏈式情境可交錯使用。
二、流量實際經過哪幾跳？
在主流 Clash Meta／Mihomo 行為中，type: relay 的 proxies 陣列自上而下解讀為連線的串接順序：本機把連線遞交給清單中的第一個成員，再依內部實作把後續段落在下一層轉出。實務上可記一句話：越上面越靠近你、越下面越接近目標。若你反過來寫，外表可能仍能載入某種設定，但實際路徑顛倒，出口 IP 也會變成你預期外的組合。教學或社群截圖裡的節點名稱若與你訂閱內的 name 不同，逐字比對永遠比憑印象貼上可靠；圖形介面有時會顯示別名，匯出 YAML 卻是另一套名稱。若你改過訂閱內的顯示名，記得回到完整設定檔檢查 proxies 陣列裡的 name 欄位。
三、YAML：proxies 與 type relay
以下為教學用示意，參數請全部換成你環境可連通的節點。先宣告兩段一般節點，再宣告第三段 relay 把它們串起來；縮排與鍵名需與你實際核心版本說明一致。程式碼註解使用英文，方便貼上後仍被各版工具接受。
proxies:
- name: front-hop
type: ss
server: 198.51.100.10
port: 8388
cipher: aes-128-gcm
password: "REDACTED"
- name: exit-hop
type: vmess
server: 203.0.113.20
port: 443
uuid: 00000000-0000-0000-0000-000000000000
alterId: 0
cipher: auto
- name: my-chain
type: relay
proxies:
- front-hop
- exit-hop重點有三：第一，front-hop 與 exit-hop 必須在 relay 之前已出現於同一層的 proxies，或使用訂閱匯入後在檔內實際存在的名稱。第二，my-chain 下面的 proxies 是只含名稱的列表，不要再重複寫 type。第三，若你從圖形客戶端合併多份訂閱，確認鏈式節點沒有落在被關閉的 provider 內。更多關於檔案結構與一般鍵的說明，可一併閱讀 站內說明文件 的基礎章節，以免與 proxy-groups 的縮排層次混淆。
四、在策略組裡掛上鏈條
寫好 my-chain 之後，在任意 select 或 url-test 策略組的 proxies 陣列裡直接填鏈名，與普通節點並列即可。圖形介面若顯示樹狀，只要核心已載入，列表裡就會多出一行與 name: my-chain 對應的選項。你若是透過 規則 把某幾條目指向特定策略組，也別忘了該策略組的預設選中項是否還在 DIRECT；多人在這裡檢查半天，才發現規則沒有走到含 relay 的那個組。
當 url-test 與 多跳同時出現在一個專案裡，常見的困惑是測得的分數變大或變不穩。因為測速請求一樣要經完整鏈，任何一跳抖動都會顯在結果上。此時不應再盲目壓 interval，而要先確認兩段基礎節點的單跳延遲，再讀我們在 Clash 策略組 url-test 與容差 文裡提到的 tolerance 邏輯。若兩則內文搭配閱讀，較不會在「多跳＋自動選」的組合中誤以為是核心 bug。
五、日誌與「dial」常見意義
在文字日誌裡，dial 通常指核心嘗試向某層遠端建立連線的階段，而不是瀏覽器已顯示的網頁錯誤。鏈路越長，越容易看到先後兩次與兩個位址有關的訊息；第一跳失敗時，有時不會再浪費時間打第二跳。閱讀日誌時，建議從最靠近時間戳記的前幾行先找出究竟指向哪一個 server 或哪一個節點 name，再回 YAML 比對。若你開了除錯級別，訊息量會暴增，可先在圖形介面切回較高層級，只針對重現問題的那幾分鐘匯出。
六、常見報錯與對照處理
下表以抽象描述整理，實際字串依核心版本與日誌語言可能略有差異。遇到時請依序核對名稱、單節點、再核對整鏈。
| 你較常看到的線索 | 建議的下一步 |
|---|---|
| 找不到 proxy 名稱（parse 或 not found 類訊息） | 比對 relay 清單與實際 name 是否完全相等；中間是否多了空白或不可見字元。若節點在 provider 內，確認該段訂閱已載入。 |
| 第一跳 timeout、dial 指向第一個 server 後沒有後續 | 在策略組內單獨只選第一跳測試；若仍失敗，錯在網路或節點本體，與第二跳尚無關。必要時可換第一跳的埠或通訊協定實測。 |
| 第二跳才失敗 | 單獨測第二跳，並留意是否必須從第一跳的出口 IP 白名單才能被接受；少數雙層服務有來源限制。 |
| TLS 或憑證相關（與 SNI 有關） | 參考 TLS Handshake 專文 檢查 servername 與實際節點地區，並暫停猜測「一定是鏈的順序寫顛倒」而忽略 SNI 本身。 |
| UDP 應用異常（遊戲、語音等） | 兩段節點都需支援你使用的 UDP 轉送語意，部分鏈在第二段不允許特定協定。這類排錯常需回到各提供商文件，而非單看 Clash 本身。 |
還有一類讓人困惑的現象，是圖上顯示的延遲變成兩段之和或跳動極大。多跳本來就會在數字上疊加，屬預期行為；只有當你確認單段都穩、鏈卻不穩時，才要懷疑名稱或供應商策略。相較之下，若你想做的是「A 用來連 B 的管理通道」，而不是嚴格意義的應用流量代理鏈，有時在原生設計上會改用 dialer-proxy 類的單點參數；下一節會用很短的篇幅區隔兩者，避免你在搜尋「proxy chain」關鍵字時，把兩份文件讀成同一個意思。
七、與 dialer-proxy、DIRECT 的邊界
在較新分支裡，部分單一遠端節點可設定 dialer-proxy 指定「建立這一條連線時，先走哪個邏輯節點」；而 relay 則是獨一條名義上的多跳實體，給策略組用同一個 name 去選。兩者能組合的場景取決於核心版本，錯讀舊文容易半套貼上。至於在鏈的哪一層寫 DIRECT，有時會有預期外的語意，因為 DIRECT 代表由本核心直接對外撥出，不經上層代理，是否真能放在鏈中第二段、能不能達成你想要的「兩層遠端」效果，要逐版確認；遇阻時，先還原成兩個純遠端節點的 relay 比較單純。若你同時有訂閱合併、快取、或手動 proxy-providers，可回到 訂閱與快取專文 確認最終載入的 proxies 陣列裡，名稱沒有因重複而遭覆寫。
RULE 臨時指向只含該策略組、其他流量 DIRECT，在瀏覽器開一個顯示出口 IP 的測試頁，觀察是否與第二跳地區一致，再還原完整規則。這能避免你在大量規則中誤以為已切到鏈、實際卻沒有命中。
八、可列印排錯清單
- 兩段基礎節點在不經 relay 時，各自在策略裡能獨立連通。
type: relay的proxies內，每個名稱在檔內實際存在，且沒有打錯字、多餘空白、或全形括號。- 策略組當中確實包含鏈的
name，且你目前手動或規則選中的是正確的組合。 - 日誌先釐清第幾跳失敗，再針對該跳的 server、埠、防火牆與 TLS 檢查。
- 變更訂閱或重新命名節點後，重新載入 設定並再次匯出 YAML 做一次全文搜尋，避免舊名殘留。
九、小結
Clash 的 relay 讓 代理鏈 在設定檔裡有明確落點，只要掌握「先定義、後引用」與跳序方向，再搭配日誌裡的 dial 線索，多數多跳相關問題都能從名稱與單段連通性收斂。相較於在社群貼大段圖卻不附 YAML 鍵名，能自己維護一份乾淨的 YAML 通常省時得多；若你習慣圖形介面，也建議學會在變更後讀回文字檔，作為最終真相。相較於同類工具在鏈與 策略組 的分散做法，Mihomo 系譜在文件與社群範例上相對可複製。若你尚未使用能穩定重載、清楚顯示當前生效檔的客戶端，可先從本站整理的下載管線取得安裝包，再回頭實作 relay。