一、YAML 結構與設定入口
先分清三項內容:訂閱連結是取得設定的網址,Profile 是客戶端管理的設定檔記錄,而核心實際讀取的才是生效設定。遠端 Profile 通常還會經過客戶端設定、覆寫或指令碼處理。因此,訂閱原文出現某個欄位,不代表核心實際使用的值也相同。排查問題時,先找出客戶端的執行設定預覽,再回頭追蹤欄位來源,通常比反覆編輯訂閱檔更有效。
從頂層結構了解引用關係
以下是一份可用來檢查載入流程的直連基準設定,包含混合連接埠、模式、空節點清單、一個手動策略組與兜底規則;所有請求最後都會直連,不具備遠端代理功能。先確認這份基準設定能順利載入,再逐項加入服務商提供的節點。這樣能區分結構錯誤與遠端連線錯誤,避免一開始就同時處理多個變因。
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
ipv6: false
proxies: []
proxy-groups:
- name: "出口選擇"
type: select
proxies:
- DIRECT
rules:
- MATCH,出口選擇
proxies 定義具體的遠端連線,proxy-groups 將節點或其他組織成可選目標,rules 則決定請求要交給哪個目標。規則引用的是名稱,不是節點在檔案中的順序;名稱必須完全相符,空格、大小寫與全形標點都可能造成差異。建議先寫節點,再寫組,最後寫規則,主要是為了方便閱讀,並不表示 YAML 頂層欄位必須依此順序排列。
縮排、清單與字串格式
YAML 以縮排表示從屬關係。請統一使用兩個空格,不要使用定位字元;同一層級的欄位必須對齊。清單項目以連字號加空格開頭,項目內的屬性再縮排一層。冒號後通常要加空格,才能構成鍵值結構。節點名稱、密碼,以及包含冒號或井字號的文字,建議加上引號;尤其是純數字密碼,應寫成字串,避免解析器將其視為數值。
井字號位於引號外時,通常代表註解。若直接將含特殊字元的密碼貼入未加引號的欄位,後半段可能會被當成註解;檔案雖然仍能解析,連線驗證卻會失敗。布林值請使用 true 和 false,連接埠使用整數,空清單寫成 []。不要把介面複製出的中文冒號貼進設定檔;外觀看起來相似,卻不能作為 YAML 鍵值分隔符。
| 型態 | 寫法範例 | 檢查重點 |
|---|---|---|
| 映射 | mode: rule | 確認鍵名及冒號後的空格 |
| 清單 | - MATCH,DIRECT | 連字號後要加空格 |
| 字串 | name: "出口選擇" | 引號成對,名稱一致 |
| 布林值 | allow-lan: false | 不要寫成加上引號的文字 |
單一檔案與多筆設定記錄
多個 Profile 通常是彼此切換,不會自動疊加。客戶端會以目前選取的設定作為主要來源;全域覆寫是否仍會套用,則取決於客戶端的作用範圍設定。直接拼接兩份完整訂閱,容易重複定義頂層鍵,也可能互相覆蓋同名節點。需要組合多個來源時,應明確使用代理集合或客戶端提供的合併流程,不要依賴重複欄位的解析結果。
遠端設定更新後,手動修改過的原始檔可能會被重新下載的內容取代。想長期保留的個人規則,建議放進獨立覆寫;臨時測試則先複製成另一份本機 Profile,並取個容易辨識的名稱。匯入、刪除及切換記錄的操作方式,請參閱Profile 與多設定管理方法。本頁後續內容皆以「最終設定只保留一套明確結構」為前提。
二、連接埠、模式與執行欄位
通用欄位決定客戶端在哪裡接收請求、採用哪種代理模式,以及記錄多少日誌。修改前先確認請求從哪裡進入:瀏覽器使用系統代理、命令列單獨指定代理,還是透過 TUN 接管整台裝置的流量。這三種入口可以同時存在,但並非同一個開關。連接埠正在監聽,只代表核心可以接收連線;若應用程式沒有將請求送到該連接埠,就不會建立代理連線。
port、socks-port 與 mixed-port
port 提供 HTTP 代理入口,socks-port 提供 SOCKS 入口,mixed-port 則在同一個連接埠接受這兩類連線。一般桌面使用通常只需要混合連接埠,不必為了讓設定「看起來完整」而開啟所有入口。連接埠號碼可以自行更改,但客戶端的系統代理設定、瀏覽器擴充功能與命令列環境變數也必須一併更新。
mixed-port: 7890
allow-lan: false
bind-address: "127.0.0.1"
mode: rule
log-level: info
ipv6: false
profile:
store-selected: true
此範例只接受本機請求。若要讓同一個區域網路中的其他裝置連線,必須一併檢查 allow-lan、監聽位址與系統防火牆,不能只把開關設為 true。監聽所有網路介面會擴大可存取範圍,不應直接暴露在不受信任的網路中。暫時分享結束後,請恢復本機監聽,並檢查路由器是否設定了連接埠轉送;不需要的轉送也應一併關閉。
| 欄位 | 用途 | 常見檢查方式 |
|---|---|---|
mixed-port | HTTP 與 SOCKS 混合入口 | 確認應用程式使用的代理連接埠 |
allow-lan | 允許區域網路存取代理入口 | 搭配監聽位址與防火牆檢查 |
mode | 選擇規則、全域或直連模式 | 查看執行介面顯示的目前模式 |
log-level | 控制日誌詳細程度 | 排錯時暫用 debug,完成後恢復 |
模式負責流量分流,不會啟用系統代理
rule 代表依規則決定流量去向,global 代表一般請求使用全域策略,direct 則代表一般請求直接連線。這裡的全域模式不代表裝置上的每個應用程式都會自動交由核心接管;未進入核心的流量仍不受控制。日常使用建議先採用規則模式;排查特定網站時,可短暫切換全域模式,比較問題是否來自分流。比較後請切回規則模式,避免將原本應直連的請求全部交給遠端。
profile.store-selected 用來保存策略組的選擇狀態,方便重新啟動後還原,但不等於儲存整份 YAML 修改。組名變更、節點刪除或快取重設,都可能影響還原結果。切換訂閱後若選項與預期不同,請先確認策略組目前有哪些成員,不要只根據上次點選的記錄判斷。三種模式的使用情境請參閱規則、全域與直連模式說明。
TUN 是另一種流量入口
TUN 透過虛擬網卡與路由接收流量,適合無法遵循系統代理設定的程式。以下提供常見結構,但啟用前仍須確認客戶端已安裝必要服務並取得系統權限。桌面客戶端可能會透過介面接管這些欄位;若介面已關閉 TUN,直接編輯來源檔不一定會改變執行狀態。行動裝置通常使用系統 VPN 介面,不應套用桌面版的服務安裝步驟。
tun:
enable: true
stack: mixed
auto-route: true
auto-detect-interface: true
dns-hijack:
- any:53
stack 用來選擇通訊協定堆疊實作,可用值與支援狀況應以目前的 mihomo 核心為準,不要把更換堆疊當成所有網路問題的通用解法。auto-route 會建立路由,auto-detect-interface 則會嘗試偵測出口;多張網卡、其他 VPN 與虛擬機網路都可能影響判斷。DNS 劫持主要處理符合條件的一般 DNS 請求,不能因此推斷所有應用程式內的加密 DNS 都已被接管。
三、DNS、fake-ip 與解析路徑
DNS 會將網域名稱解析為 IP 位址;在代理設定中,也會影響規則判斷、節點伺服器解析與連線路徑。先區分兩類網域:瀏覽網站時需要解析目標網域,建立代理連線時也可能需要解析節點伺服器的網域。若後者必須依賴尚未連線的代理,就會形成循環依賴。若所有節點同時連線失敗,應先確認節點伺服器是否能解析,而不是立刻更換網站規則。
先建立簡單、容易判讀的 DNS 設定
以下使用 fake-ip,並指定上游解析器與節點網域解析器。範例未設定監聽連接埠,以免與本機 DNS 服務衝突;系統請求如何進入核心 DNS,應透過客戶端的 TUN 或 DNS 整合設定確認。範例中的公共解析服務是否可用,取決於目前的網路環境。實際部署前,請先在本機網路測試連線,再決定是否採用;解析器位址並非適用所有地區的固定解答。
dns:
enable: true
ipv6: false
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.1/16
fake-ip-filter:
- "*.lan"
- "*.local"
default-nameserver:
- 223.5.5.5
proxy-server-nameserver:
- 223.5.5.5
nameserver:
- https://dns.alidns.com/dns-query
default-nameserver 用來解析 DNS 上游伺服器本身的網域,通常稱為引導解析;它不只是一般網站解析的備用伺服器。nameserver 是一般查詢使用的上游解析器。proxy-server-nameserver 用於解析代理伺服器網域,讓建立代理所需的解析路徑更明確。如果節點使用網域名稱,而上游解析器又必須透過該節點才能連線,就應優先檢查這一層是否形成依賴循環。
fake-ip 回傳的是虛擬位址,不是節點位址
fake-ip 模式會先向應用程式回傳虛擬位址,再由核心保存網域對應並處理後續連線。看到 198.18 網段的位址,不代表網站真的位於該網段,也不能直接據此判斷 DNS 回應遭到竄改。關鍵在於後續連線是否仍經過同一個核心,以及對應資料是否有效。如果應用程式繞過核心,直接連線至這個虛擬位址,連線自然會失敗;因此啟用 fake-ip 時,也要確認流量接管是否完整。
fake-ip-filter 用來排除需要取得真實位址的網域,避免回傳虛擬位址。區域網路裝置探索、部分遊戲或特殊驗證程式可能需要個別處理,但不要一遇到問題就排除所有網域。先從日誌確認實際網域,再加入範圍盡可能小的篩選條目,清除相關快取後重試。*.lan 和 *.local 只是範例,不能取代對實際區域網路網域的確認。
| 欄位 | 處理的問題 | 容易混淆之處 |
|---|---|---|
default-nameserver | 解析上游伺服器的網域 | 不是一般請求的唯一出口 |
nameserver | 處理一般網域查詢 | 加密傳輸不代表流量經過代理 |
proxy-server-nameserver | 解析節點伺服器網域 | 避免依賴尚未建立的代理連線 |
nameserver-policy | 為指定網域選擇上游解析器 | 只選擇解析器,不決定服務流量的出口 |
網域策略、路由策略與快取分別處理
若只有內部網域需要交由內部 DNS 解析,可以使用 nameserver-policy 個別指定解析器。但「使用哪個 DNS」與「網站連線經過哪個節點」是兩回事;後者仍由規則決定。加密 DNS 使用 HTTPS 位址,只代表傳輸方式,並不能保證查詢會經過代理。啟用 DNS 遵循規則的相關選項前,請先安排好節點網域與上游解析器本身的解析方式,避免形成循環依賴。
IPv6 也需要沿著連線路徑逐層確認。頂層 ipv6、DNS 是否回傳 AAAA 記錄、節點是否支援對應的目的位址,以及系統是否有可用路由,彼此相關但並不相同。切換解析模式後,作業系統、瀏覽器與應用程式可能仍在使用舊快取;請關閉相關連線並清除必要快取,再測試同一個網域。瀏覽器沿用舊連線成功,不代表新設定的解析路徑已正確。
四、代理節點欄位與代理集合
代理節點描述建立一次遠端連線所需的參數,不負責決定哪些網站使用該節點。常見的共用欄位包括名稱、通訊協定類型、伺服器位址、連接埠,以及該協定所需的驗證與傳輸設定。服務商提供的 URI、QR Code 或訂閱可能包含額外參數;手動重建時不能只複製位址與密碼。應先確認通訊協定,再依相同協定核對欄位,不要把不同教學的參數混在同一個節點設定中。
先了解共用欄位,再查看各協定專用欄位
以下是 Shadowsocks 結構範例。網域與密碼僅供教學使用,無法實際連線;請取得服務商提供的真實參數後再填入。name 只供本機引用,可改成容易辨識的名稱;server 必須是可解析的主機名稱或正確 IP,不可包含網頁路徑;port 是遠端服務的連接埠,不是本機混合代理的連接埠。
proxies:
- name: "範例 SS"
type: ss
server: proxy.example.com
port: 8388
cipher: aes-128-gcm
password: "your-password"
udp: true
cipher 必須與伺服器端設定一致,不要只為了看起來比較新就自行替換;不同加密方式對密碼格式也可能有不同要求。udp: true 代表允許節點處理相應的 UDP 流量,但仍取決於協定、伺服器與網路路徑是否支援。瀏覽器可以開啟網頁,但遊戲或語音連線失敗時,反覆啟用此欄位未必能解決問題;還應檢查該類流量是否進入核心,以及遠端是否開放相關服務。
| 欄位 | 填寫依據 | 錯誤情況 |
|---|---|---|
name | 本機定義,名稱須唯一 | 策略組引用失敗或難以辨識 |
type | 服務商的協定說明 | 欄位無法辨識或交握失敗 |
server / port | 遠端連線參數 | 解析錯誤、連線遭拒或逾時 |
| 驗證欄位 | 密碼、使用者識別等協定參數 | 驗證失敗,不能用本機連接埠代替 |
TLS、SNI 與傳輸參數不可互相取代
使用 TLS 的協定中,伺服器位址與 TLS 驗證名稱可能不同。以 Trojan 為例,sni 會參與 TLS 名稱協商,通常應符合伺服器憑證與設定要求。它不是可任意填寫的加速網域,也不一定等於實際連線的 IP。WebSocket 路徑、HTTP Host 或其他傳輸參數則屬於額外設定,必須逐項相符;填入 SNI 不會自動補齊這些設定。
proxies:
- name: "範例 Trojan"
type: trojan
server: proxy.example.com
port: 443
password: "your-password"
sni: proxy.example.com
skip-cert-verify: false
udp: true
遇到憑證錯誤時,應先檢查系統時間、SNI、伺服器憑證與連線目標。不要長期關閉驗證;這會略過重要的身分檢查,也可能掩蓋參數填錯的問題。若服務商要求特殊憑證或額外公鑰參數,請依照協定說明設定,不要將其他協定的欄位直接加到目前的節點。舊版客戶端即使能匯入 YAML,也未必支援新版核心的所有協定;必要時可先到安裝檔下載頁面選擇合適的客戶端。
proxy-providers 管理節點,rule-providers 管理規則
代理集合可將節點來源獨立管理,策略組再透過 use 引用集合名稱。以下使用本機檔案,適合用來理解結構;相對路徑以設定工作目錄為基準,不一定是下載資料夾。檔案內容應包含 proxies 清單,而不是一整份含連接埠與規則的設定檔。HTTP 集合還需要有效的下載網址、更新間隔與可寫入的快取路徑,且服務商連結必須符合該集合的格式。
proxy-providers:
本機節點:
type: file
path: ./providers/local.yaml
proxy-groups:
- name: "訂閱出口"
type: select
use:
- 本機節點
遠端來源更新時,請妥善保護訂閱網址,因為其中可能包含帳戶存取憑證。分享設定前,請移除完整連結與密碼,不要只遮住節點名稱。集合載入失敗時,先檢查路徑與格式,再檢查網路下載,最後確認策略組引用是否正確。若沒有可用成員,即使策略組存在,也無法提供預期的出口;因此應分別確認匯入成功、節點存在,以及實際連線能否建立。
五、策略組類型與引用關係
策略組位於規則與節點之間,是最適合維持名稱穩定的一層。規則可以一直指向「代理出口」,組內節點則隨訂閱更新而變動。如此一來,更換節點時就不必每次修改規則。策略組不會建立新的通訊協定,也不能讓不支援 UDP 的節點變成支援 UDP;它只負責決定可選目標,以及何時允許重新選擇。
select 負責手動選擇,自動組負責挑選候選項
select 是手動選擇組,適合並列顯示自動組、直連與數個固定節點。url-test 會定期測試候選項並依測試結果選擇,fallback 則偏重依照設定順序使用可用候選項。測試結果只代表對指定位址的探測狀況,不代表所有網站都會更快,也不能用來推估頻寬。選擇組類型前,先想清楚需要的是「固定偏好」還是「依測試結果調整」。
proxy-groups:
- name: "代理出口"
type: select
proxies:
- 自動選擇
- DIRECT
- name: "自動選擇"
type: url-test
use:
- 本機節點
url: https://www.gstatic.com/generate_204
interval: 300
tolerance: 50
rules:
- MATCH,代理出口
這裡沿用上一章的「本機節點」集合;若單獨複製本段,必須先補上對應的定義。interval 以秒為單位設定測試間隔,tolerance 則用來減少小幅差異造成的頻繁切換。探測位址應穩定,並符合實際網路環境;若該位址受到特定路徑限制,測試結果可能失真。範例使用實際探測用途的位址,但部署前仍須確認在目前環境中可以連線。
| 型態 | 選擇方式 | 適用情境 |
|---|---|---|
select | 由使用者手動指定成員 | 總入口、固定服務出口 |
url-test | 依探測結果選擇 | 可接受自動調整的一般瀏覽需求 |
fallback | 依序選擇可用成員 | 主備線路與明確優先順序 |
load-balance | 依策略分配連線 | 了解工作階段限制後的多出口需求 |
流量分配不會合併單一連線的頻寬
load-balance 可將不同連線分配給不同候選項,但通常無法將單一下載連線拆分至多個節點並加總頻寬。服務也可能要求出口 IP 維持一致,例如帳戶登入、付款或某些長連線服務。若沒有明確需求,先使用手動組或自動選擇組,通常更容易判讀連線去向;了解分配策略與工作階段限制後,再考慮使用負載平衡。
自動組測試成功,不代表既有連線會立即切換到新節點。連線建立後通常會繼續使用原本的出口,新的連線才會採用策略組的新選擇。排查時先查看連線記錄中的實際路徑,再重新發出請求;不要只看組介面目前反白的選項,就認定所有流量都已切換。重新啟動核心可以清除連線,但會中斷現有服務,通常不必在每次切換後都這麼做。
以穩定的組名隔離訂閱變動
建議建立一層名稱穩定的服務組,例如「代理出口」與「工作存取」,讓規則引用這些名稱,再由組內連接節點集合或自動組。層級維持簡單即可:規則指向服務組、服務組指向候選組、候選組指向節點。組與組之間互相引用沒有意義,也可能導致設定無法載入;例如甲包含乙,而乙又包含甲,就應改為單向關係。
也要處理名稱衝突。節點與策略組盡量不要使用相同名稱,否則查看執行連線路徑時很難分辨。集合更新後,成員名稱可能改變,手動選取狀態也可能無法還原;使用集合引用可降低靜態節點名稱失效的影響,但仍須確認集合內有可用成員。正規表示式篩選應從簡單條件開始,先觀察結果再逐步縮小範圍,避免一次設定得太嚴格,導致所有候選項都被排除。
行動裝置也要留意探測頻率。多個自動組與多個代理集合同時執行健康檢查,可能產生重複請求;縮短間隔不一定能帶來更穩定的體驗。建議先精簡重複測試,保留實際會使用的候選範圍,再觀察背景執行情況。若耗電量偏高,可接著查看手機背景執行與省電排查,不要只憑一次電量變化就判斷核心故障。
六、規則順序、語法與規則集
規則模式會由上而下依序比對,命中後就交由對應策略處理,不會繼續尋找後面「更精確」的規則。因此,例外通常放在前面,範圍較大的規則放在後面,最後以 MATCH 處理剩餘請求。規則名稱相似,不代表比對範圍相同;若要比對特定網域、其子網域或某段文字,必須選用不同類型的規則。
分清網域規則與位址規則
DOMAIN 比對完整網域;DOMAIN-SUFFIX 比對網域本身及其子網域;DOMAIN-KEYWORD 則依關鍵字比對,範圍較廣,也更容易誤判。若要指定明確網站的流量去向,優先使用完整網域或網域後綴,不要只因為關鍵字較短就選用它。規則中的網域不要加上通訊協定前綴或網頁路徑;通常無法單靠網域規則區分同一網址中的特定頁面。
rules:
- DOMAIN,internal.example.com,DIRECT
- DOMAIN-SUFFIX,example.com,代理出口
- IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
- IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
- IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
- MATCH,代理出口
範例先讓內部網站直連,再將其他 example.com 請求交給代理組。若把前兩條規則對調,內部網站就會先符合範圍較大的後綴規則。IP-CIDR 用來比對位址範圍,IPv6 則可使用對應的 IP-CIDR6。no-resolve 表示不會只為了判斷這條 IP 規則而主動觸發網域解析,並不代表整個請求不需要 DNS;若目標本身已有位址,仍可依位址進行比對。
| 規則類型 | 比對對象 | 使用提醒 |
|---|---|---|
DOMAIN | 完整網域 | 適合少數明確例外 |
DOMAIN-SUFFIX | 網域及其子網域 | 不要填入網址路徑 |
IP-CIDR | IPv4 位址範圍 | 區分觸發解析與位址比對 |
RULE-SET | 外部規則集合 | 確認集合名稱與內容格式 |
MATCH | 所有剩餘請求 | 通常放在規則清單末尾 |
規則集的 behavior 必須符合檔案內容
規則集合適合獨立管理較長的網域清單。domain 用於網域集合,ipcidr 用於位址範圍集合,classical 則用於包含規則類型的傳統規則集合。完整的 Clash 設定檔不能當成規則集使用,代理訂閱網址也不能填入規則集來源。以下使用本機 domain 集合;主設定檔負責指定流量去向,集合檔只負責列出比對範圍。
# 主設定檔中的片段
rule-providers:
工作網域:
type: file
behavior: domain
format: yaml
path: ./rules/work.yaml
rules:
- RULE-SET,工作網域,代理出口
- MATCH,DIRECT
# ./rules/work.yaml
payload:
- "example.com"
- "+.example.org"
本例以 example.com 表示明確的網域項目,+.example.org 則表示該網域及其子網域範圍。傳統規則集合可以寫入 DOMAIN-SUFFIX,example.org 等含規則類型的項目,但不要在項目中再次指定策略目標;請由主設定檔的 RULE-SET 指定去向。HTTP 規則集也需要設定更新間隔與快取路徑;首次下載失敗時,應確認是否已有可用快取,不要假設更新失敗就一定會讓所有規則失效。
查看連線記錄,確認實際命中的規則
修改規則後,請重新發出目標請求,並在連線頁面確認網域、命中規則與策略鏈。瀏覽器頁面可能同時連線至登入、圖片、API 等多個網域,只修改網址列中的主網域不一定足夠。先找出真正失敗的請求,再新增範圍最小的規則;不要直接使用範圍寬泛的關鍵字,將所有流量導向同一個出口。應用程式內的加密 DNS、連線重用,或僅透過 IP 建立連線,也可能影響網域資訊的可見度。
進程規則可用於桌面應用程式分流,但核心必須能取得進程資訊,且不同作業系統的權限與流量入口可能有不同表現。請先在自己的平台確認可用,再使用這類規則;進程名稱並非跨平台通用識別方式。GEOIP 或地理分類規則也需要相應資料檔與更新狀態。先用幾條明確的網域規則確認分流流程正常,再加入較大的規則集合,排查時會更容易判讀。
七、覆寫、合併與訂閱更新
覆寫的目的,是讓個人設定獨立於遠端訂閱,而不是另外維護一份內容幾乎相同的大型檔案。常見需求包括固定本機連接埠、為內部網站新增例外、建立名稱穩定的策略組,以及修改 DNS。不同客戶端的覆寫格式與執行順序並不一致,必須先確認介面提供的是欄位替換、遞迴合併、規則前置,還是指令碼處理;不要把某個客戶端的控制鍵當成 mihomo 原生欄位。
先確認要修改的來源與套用範圍
一般可將處理流程理解為:取得遠端內容、套用客戶端的轉換或擴充、執行個人覆寫,再交由核心處理。實際順序可能還包含全域設定與執行時修改,應以客戶端顯示的生效設定為準。只有單一訂閱需要的例外,優先綁定至對應的 Profile;所有設定都需要的本機項目,才考慮設為全域。套用範圍過大,可能使另一份訂閱引用到不存在的策略組。
新增覆寫前,先複製原始設定,記下目前模式、策略組選擇與可重現的測試目標。接著一次只修改一類欄位,例如先固定 DNS,不要同時調整節點與規則。載入成功後,比較來源檔與最終設定:欄位值是否如預期變更、原有清單是否仍在、目標策略組是否被移除。確認結果後再進行下一步;這比看到「儲存成功」就一次加入所有修改更可靠。
純量覆蓋與清單合併並不相同
像 mode 這類純量通常會由後寫的值覆蓋前面的值;像 dns 這類映射可能會遞迴合併,也可能整體取代;像 rules 這類清單尤其容易整段被取代。即使兩個客戶端都將功能稱為「合併」,實際行為也可能不同。以下展示的是概念上的前後對照,不是可直接貼入所有客戶端的覆寫語法。
訂閱中的原始規則
rules:
- DOMAIN-SUFFIX,example.org,代理出口
- MATCH,代理出口
預期的最終規則
rules:
- DOMAIN,intranet.example.com,DIRECT
- DOMAIN-SUFFIX,example.org,代理出口
- MATCH,代理出口
此處的需求是將一條例外規則移到前面,同時保留原有規則。如果客戶端只支援清單替換,就必須明確建立完整結果;若有規則前置功能,使用該功能會更合適。單純在檔案末尾新增另一個 rules 鍵,不會自動將規則移到前面。也不要依賴 YAML 錨點跨檔案拼接清單:錨點主要用於同一份文件中的引用,不能取代客戶端的設定合併流程。
| 修改項目 | 需要確認的行為 | 檢查結果 |
|---|---|---|
| 連接埠、模式 | 是否再次由介面接管 | 最終值與執行狀態一致 |
| DNS 映射 | 遞迴合併或整體替換 | 必要的解析器欄位仍存在 |
| 規則清單 | 前置、後置或替換 | 例外在前,兜底在後 |
| 策略組清單 | 依名稱合併或重新建立 | 引用目標有效,成員沒有遺失 |
同名策略組與動態節點都要納入考量
訂閱中的組名可能變動。如果個人規則長期引用某個服務商的組名,更新後就可能找不到目標。可以自行建立名稱穩定的服務組,再讓它引用代理集合;也可以透過客戶端明確支援的指令碼,依條件建立成員。指令碼應處理空節點清單與名稱衝突,不能假設每次下載都會有相同節點;找不到候選項時,更不能在沒有確認的情況下悄悄選擇其他出口。
個人覆寫中盡量不要重複儲存服務商憑證,這樣訂閱更新密碼時就不必維護兩份。如果必須同時使用手動節點與訂閱節點,請使用不同名稱並標明來源。排查合併失敗時,先停用個人擴充功能,確認原訂閱可以載入,再逐項恢復;若原始訂閱本身已損壞,應先處理來源問題。頂層結構的補充說明請參閱config.yaml 逐段解析。
八、設定驗證、排查與還原
驗證可分為三個層次:檔案能否解析、核心是否接受設定,以及請求是否依預期運作。YAML 語法正確只通過第一層;欄位不受支援、策略組名稱不存在或規則集格式不符,仍可能遭核心拒絕。核心成功啟動也不代表所有遠端資源都能連線。依這三個層次逐一檢查,可以避免把啟動錯誤誤認為網路問題,也能減少不必要地反覆重新安裝客戶端。
先做靜態檢查,再測試執行連線
若已安裝 mihomo 命令列核心,可在設定檔所在目錄執行測試命令。Windows 請使用對應的可執行檔名稱,其他系統則依實際安裝路徑呼叫;以下假設目前目錄已放置可執行核心與 config.yaml。命令會檢查設定,但無法證明服務商帳戶有效、所有遠端資源都能下載,或每條服務規則皆符合預期。桌面客戶端使用者也可透過介面提供的設定檢查功能進行確認。
# Linux / macOS:在測試目錄內執行
./mihomo -t -d . -f ./config.yaml
# Windows PowerShell:在測試目錄內執行
.\mihomo.exe -t -d . -f .\config.yaml
相對路徑問題,優先透過指定明確的工作目錄解決。-d . 會將目前目錄設為設定工作目錄,規則集與代理集合引用的檔案也必須放在對應位置。不要為了通過測試而任意搬動正在執行的客戶端資料目錄。獨立測試時,將必要檔案複製到另一個目錄,既方便確認路徑,也能避免除錯影響主要設定與快取。
| 狀況 | 優先檢查 | 下一步 |
|---|---|---|
| 顯示行號或解析失敗 | 縮排、引號、冒號與重複鍵 | 查看錯誤行與前一段內容 |
| 找不到代理或策略組 | 名稱與集合引用 | 檢查最終設定中的實際定義 |
| 無法監聽連接埠 | 連接埠占用、位址與權限 | 關閉衝突程式或統一更換入口 |
| 連線逾時或交握失敗 | DNS、遠端位址與協定參數 | 分別測試解析與建立連線 |
| 只有部分網站無法連線 | 命中規則、實際出口與相關網域 | 比較直連與代理的連線路徑 |
閱讀日誌時,一次只追查一個可重現的請求
需要詳細日誌時,可暫時將 log-level 設為 debug,關閉不相關的應用程式,再連線至一個明確的目標。先確認請求是否進入核心,再查看命中規則與策略鏈,最後檢查連線階段的錯誤。如果完全沒有請求記錄,問題可能出在系統代理、應用程式代理設定或 TUN 接管,不應先修改遠端節點。若策略鏈正確,再檢查解析、驗證與 TLS。
不要把每一筆錯誤日誌都當成同一種故障。背景更新規則集失敗,與目前網頁透過現有快取正常瀏覽,可以同時發生。單一測試位址連線失敗,也不代表所有服務請求都失敗。分享日誌時,保留錯誤上下文與時間順序,但請刪除訂閱網址、存取憑證,以及不想公開的網域。只截取一句「逾時」,通常無法判斷問題出在解析、連線還是交握階段。
透過對照測試確認修復,不要只憑感覺判斷
可透過明確指定 HTTP 代理來測試連接埠入口,例如以下命令只會確認請求能否經由本機混合連接埠送出。這不能證明整台系統已被接管,也不會自動測試 UDP。執行命令前,請確認核心正在監聽指定的連接埠;若連線遭拒,先檢查本機服務與連接埠,不必立刻更換訂閱。測試目標也應選擇目前網路中結果明確可預期的網站。
curl -I --proxy http://127.0.0.1:7890 https://example.com
接著分別連線至預期直連與預期代理的目標,並在連線頁面確認結果。修改規則後要建立新連線,修改 DNS 後要考慮舊快取,切換策略組後則要檢查實際連線路徑。每次記下「修改了什麼、測試什麼、觀察到什麼」,只保留能說明效果的修改。若問題仍無法定位,可依照節點逾時排查順序繼續縮小範圍,或到幫助中心查找相關情況。
還原步驟與後續維護
還原時,先停用新增的覆寫,再切回已驗證的 Profile;若問題仍在,請確認系統代理與 TUN 是否留下不相容的入口。不要一次刪除所有設定、快取與日誌,以免失去比對依據。挑選客戶端時可優先考慮 Clash Plus,再依作業系統與功能需求比較其他選項;安裝入口統一位於客戶端下載頁。舊版客戶端缺少欄位支援時,應先確認核心功能,而不是反覆調整縮排。
設定穩定後,請將除錯日誌恢復為平常使用的層級,移除無效的測試項目,並保留簡短的修改說明。備份內容應同時包含個人覆寫與必要的本機集合檔;只保存訂閱網址無法還原所有個人規則。之後每次更新只抽查幾個固定情境,就能較快發現規則順序、策略組成員或 DNS 路徑的變化。需要重新走一遍連線流程時,請回到快速入門教學;本頁則可繼續作為欄位查閱入口。