Clash 設定檔
參考手冊

01 YAML 結構與引用關係

Clash 設定不是一串依序執行的命令，而是一份描述網路行為的資料。檔案頂層通常會放置監聽連接埠、執行模式、DNS 設定、節點清單、策略群組與規則。核心讀取檔案後，會先建立這些物件，再依連線符合的規則選擇出口。因此，檔案能儲存不代表節點連得上；語法正確，也不代表所有名稱都引用無誤。

縮排決定欄位的所屬層級

YAML 以空格縮排表示階層，建議統一使用兩個空格，避免混用定位字元。冒號後接一般值時留一個空格；清單項目則以連字號加空格開頭。同一層的欄位必須對齊。在編輯器中看似只差一格，實際上可能讓頂層規則清單被放進 DNS 物件，造成欄位遭忽略或型別錯誤。開啟空白字元顯示，比憑肉眼猜縮排可靠。

# 可獨立載入的最小直連設定，不含代理節點
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 223.5.5.5

proxies: []
proxy-groups: []

rules:
  - MATCH,DIRECT

上例可用來確認設定是否正常載入，但所有連線都會直連，不會使用代理出口。空清單寫作 []，表示目前沒有項目，並不代表缺少整個欄位。若要排查編輯器或目錄權限問題，先用這份最小設定確認載入流程，再逐步加入自己的節點和策略群組。不要一開始就同時加入完整訂閱、外部規則與覆寫腳本。

字串、布林值與清單

布林值建議寫成 true 或 false，連接埠使用整數，節點名稱和規則字串則視需要加上引號。名稱包含冒號、井字號或特殊符號時尤其要留意：井字號可能被視為註解，冒號後接空格則可能被視為映射分隔符。密碼即使只有數字，也建議加上引號，明確保留為字串，避免讀取後型別改變。

多行區塊較容易閱讀，使用大括號包住的行內映射則更精簡；兩者都能表示相同物件。本頁優先採用多行寫法，讓每個欄位的歸屬一目瞭然。不要在 YAML 外再包一層 Markdown 程式碼區塊；網頁中的範例標記不是設定內容。複製時只取程式碼本文，檔案應儲存為一般文字，而非文書編輯器產生的文件。

名稱會串成一條引用鏈

節點的 name 會被策略群組引用，而策略群組的 name 又會被規則引用。引用時必須完全符合名稱，空格、大小寫和標點都要一致。若重新命名策略群組，卻沒同步修改規則中的目標，載入時可能會提示找不到代理。排查這類錯誤時，從規則目標往回查：先找同名策略群組，再確認群組中的每個成員確實存在。

頂層不要重複設定同名鍵。兩個 rules 不會自動串接，兩個 dns 也不會自動合併；不同解析器可能拒絕重複鍵，或只保留其中一個。要新增規則，請修改既有清單；要保留訂閱結構，請使用用戶端明確支援的覆寫機制。YAML 本身不會替使用者理解「把這兩段接在一起」的意圖。

處理訂閱時，也要分清原始內容與執行中的設定。訂閱下載後，用戶端可能再套用連接埠覆寫、DNS 覆寫或規則合併。在 Profiles 中編輯來源檔卻看不到效果，不一定是核心沒有讀取，也可能是後續設定再次覆蓋了變更。先記下目前啟用的設定名稱與來源，之後每次修改都以實際執行設定和日誌為準。

02 連接埠、模式與存取界線

連接埠欄位描述用戶端在本機哪裡接收連線，並非遠端伺服器的連接埠。瀏覽器或命令列工具將要求送到這個入口後，核心才有機會依規則分流。修改連接埠後，使用舊連接埠的程式不會自動同步更新；Windows 系統代理、獨立瀏覽器設定和終端機環境變數可能各自保存了位址，需要逐一確認。

分開監聽與混合監聽

# 本機使用的通用欄位片段
mixed-port: 7890
allow-lan: false
bind-address: 127.0.0.1
mode: rule
log-level: info
ipv6: false

不需要區域網路分享時，可維持僅限本機存取。上例的監聽位址和存取開關都以本機使用為主。若要提供手機或另一台電腦連線，不能只開啟 Allow LAN：還須讓監聽位址涵蓋對應網卡，在防火牆中允許信任的網路存取，並在另一台裝置填入這台電腦的區域網路位址，而非該裝置自己的迴路位址。

監聽失敗常見原因是連接埠已被占用。先關閉重複啟動的用戶端，再檢查占用中的處理程序；不要連續更換幾個連接埠後，忘記同步更新應用程式設定。在 Windows 終端機執行下方命令，可查看該連接埠的監聽項目和處理程序編號。這只能協助找出占用者，看到編號不代表應直接結束處理程序；請先在工作管理員確認程式名稱和用途。

netstat -ano | findstr :7890

規則、全域與直連模式

mode: rule 表示依規則順序決定出口，適合日常分流。全域模式會將連線交由全域策略選擇，但前提仍是流量已進入核心。直連模式則讓已接管的連線直接連至目標。模式不是系統層級的流量接管開關；把規則模式切換成全域，不會讓完全忽略系統代理的程式突然開始使用代理。

General 中的 System Proxy 是用戶端設定 Windows 系統代理的功能，與 YAML 的執行模式並非同一回事。它通常會影響遵循系統代理設定的程式；TUN 則透過虛擬網卡和路由接管流量，需要相應核心、權限與服務支援。舊版 Clash for Windows 的 Service Mode、TUN Mode，不能直接套用目前 Mihomo 用戶端的按鈕位置與實作方式來理解。

日誌與控制介面不可混用

log-level 日常使用設為 info 即可，排查問題時可暫時提高至 debug。除錯日誌可能包含目標網域、連線資訊和設定路徑，分享前請刪除訂閱網址、認證資訊與個人瀏覽紀錄。日誌越多不代表越容易找到問題；重現一次後依時間順序查看相關連線，比長時間收集所有輸出更有效。

外部控制介面供用戶端介面或儀表板管理核心使用，並非應用程式連網的代理入口。需要設定 external-controller 時，建議優先綁定迴路位址；若確實需要遠端存取，應另行規劃驗證與存取限制。不要把控制介面的連接埠填入瀏覽器代理設定，也不要為了讓區域網路裝置上網，就順手把管理介面暴露給整個網路。

頂層的 ipv6 與 DNS 模組中的 IPv6 選項，作用範圍並不相同。關閉其中一個欄位，不代表系統網卡已停用 IPv6，也不代表所有應用程式的解析路徑都已改變。遇到特定目標只在某些網路環境下連線失敗，應檢查系統位址、DNS 回應、規則命中情況與出口連線，不要把所有問題都歸咎於連接埠或單一代理開關。

修改本章欄位後，先確認核心是否成功監聽，再檢查應用程式的代理位址，最後驗證模式與出口。依序檢查能區分「入口無法連線」與「遠端連線失敗」。更多操作方式請參閱系統代理使用說明；退出用戶端後仍無法上網，可前往常見問題查看系統代理殘留的排查方式。

03 DNS 與網域解析路徑

DNS 負責將網域名稱轉換為位址，但在代理設定中，解析不一定都發生在同一處。可能由系統先解析、應用程式使用內建解析器、核心接管要求，或由遠端代理負責最後解析。判斷 DNS 設定是否生效時，先確認「這次查詢從哪裡進入、由誰回覆」，不要只看檔案裡是否填了幾個眼熟的伺服器。

本機監聽不代表自動接管

# 基礎 DNS 片段；本機測試入口使用非特權連接埠
dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "localhost"
  nameserver:
    - 223.5.5.5
    - 119.29.29.29

enable 會啟用核心的 DNS 模組，listen 則指定服務監聽位址。上例使用迴路位址和非特權連接埠，方便測試，但不會自動修改 Windows 的所有 DNS 要求。系統網卡的一般 DNS 設定通常只接受伺服器位址，不能直接填入包含自訂連接埠的字串；要完整接管，還需要用戶端或 TUN 的相關設定。

nameserver 是解析上游清單，不應簡單理解為嚴格的主要與備用順序。不同核心的並行、快取與選擇方式可能各異。設定多個服務後，失敗原因也不一定是「第一個項目有問題」。測試時先減少變因，使用一個目前網路可連線的上游確認基本功能，再加入加密解析或依網域分流的設定。

Fake IP 與真實位址

Fake IP 模式會先回傳對應的映射位址給應用程式，核心保留位址與網域的對應關係，待連線進入核心後再依網域處理。這有助於保留網域資訊，但查詢和連線必須經過同一套接管路徑。若應用程式取得映射位址後，繞過核心直接連線，就可能無法存取。關閉用戶端前若仍保留舊快取，也可能暫時造成連線失敗。

fake-ip-filter 可讓部分網域不取得映射位址。區域網路探索、某些裝置服務，或必須取得真實位址的程式，可能需要加入例外，但清單並非越長越好。排除所有常用網域，會改變原先預期的解析路徑。請針對已重現的問題新增最少量的例外，修改後清除相關應用程式快取，再觀察實際結果。

Redir Host 通常會回傳真實位址，適用於部分無法接受映射位址的情境，但不代表所有應用程式相容性問題都會消失。網域資訊能否完整保留、要求是否先經系統解析，以及目標位址是否改變，都會影響規則行為。選擇模式時應依目前的應用程式與接管方式測試，不要將兩種模式視為固定的速度排名。

Mihomo 的網域解析策略

# Mihomo 局部範例：加入既有 dns 物件，不要再建立第二個 dns
dns:
  nameserver-policy:
    "+.example.com":
      - 223.5.5.5
  proxy-server-nameserver:
    - 223.5.5.5

nameserver-policy 可為指定網域安排解析上游；範例只展示欄位層級，不代表這個保留網域需要特殊處理。Mihomo 的 proxy-server-nameserver 用於解析代理伺服器網域。兩者處理的對象不同：一個是要存取的網站網域，另一個是節點伺服器網域，不能只因為都叫「網域」就當成同一個解析步驟。

節點伺服器若使用網域名稱，建立連線時本身就可能需要 DNS。若解析該節點也必須先經過這個節點，就會形成啟動依賴循環。排查時先確認伺服器網域能透過獨立可用的路徑解析，再檢查網站解析是否經過代理。加密 DNS 上游使用網域名稱時，也要留意引導解析和連線路徑，不能只更換一個位址就認定循環已經解決。

DNS 洩漏測試反映的是特定測試條件下觀察到的解析出口，不能代表所有流量都採用相同路徑。瀏覽器安全 DNS、應用程式內建 DoH、系統快取和區域網路 DNS 都可能繞過預期路徑。驗證時應分別檢查瀏覽器設定、核心 DNS 日誌和 TUN 接管狀態；只做一次網頁測試，無法取代對實際解析鏈路的確認。

04 代理節點欄位與協定界線

proxies 清單用來保存各個代理出口的參數。每個項目至少要能辨識協定、伺服器位址與連接埠，認證欄位則依協定而異。用戶端顯示的節點名稱只是本機標籤，不能取代認證資訊。將節點改成好記的名稱，不會改變伺服器位置，也不會讓伺服器具備原本不支援的協定能力。

先核對位址，再核對認證資訊

# 教學用節點片段：保留網域與假密碼不可用於實際連線
proxies:
  - name: "範例 SS"
    type: ss
    server: ss.example.com
    port: 443
    cipher: aes-128-gcm
    password: "your-password"
    udp: true

  - name: "範例 Trojan"
    type: trojan
    server: trojan.example.com
    port: 443
    password: "your-password"
    sni: trojan.example.com
    skip-cert-verify: false
    udp: true

server 應填入主機名稱或 IP 位址，不要把包含協定前綴、路徑和查詢參數的整個網址貼進去。port 是伺服器端的監聽連接埠，與本機的 mixed-port 不需要相同。服務提供者給什麼就填什麼；不能因為網頁常用某個連接埠，就認為所有節點都該改成相同值。

Shadowsocks 的 cipher 和 password 必須與伺服器設定相符。加密方式不是可任意挑選的效能選項，名稱拼錯或核心不支援都會造成連線失敗。不同世代的協定也可能使用不同金鑰格式，不能只改協定名稱而保留其他欄位。訂閱若已提供可用節點，請優先保留原始參數，不要憑印象刪掉看不懂的欄位。

TLS、SNI 與憑證驗證

TLS 節點通常還會用到伺服器名稱、憑證和傳輸層參數。SNI 是 TLS 握手中的伺服器名稱指示，未必與直連時填入的 IP 相同，應以伺服器端的實際部署為準。憑證錯誤不一定是密碼有誤，也可能是系統時間不準、名稱不符或網路中間遭到干擾。先確認日誌中的錯誤類型，再決定要檢查哪些欄位。

skip-cert-verify: false 表示保留憑證驗證。遇到握手失敗，不應把關閉驗證當成一般修復方式，否則可能掩蓋伺服器名稱或憑證設定問題。先校正系統時間，再檢查 SNI 與服務提供者的說明；如果訂閱突然出現大量憑證錯誤，也要確認是否載入錯誤檔案，或是否經過需要驗證的網路入口。

VMess、VLESS、Trojan、Shadowsocks 等協定的認證欄位並不通用。有些協定需要使用者識別碼，有些需要密碼，也有些對傳輸方式和安全參數另有要求。本頁不提供混合所有欄位的「萬用節點」，因為多餘欄位可能遭忽略，反而讓人誤以為問題已修復。請依協定選用完整且相符的節點定義。

傳輸能力須由兩端共同支援

udp: true 只是表示設定允許對應節點使用 UDP；最終能否傳輸，還取決於協定、伺服器、網路和入口接管方式。常見的系統代理 HTTP 入口無法自動接管所有應用程式的 UDP。遊戲或語音程式連線失敗時，先確認流量是否進入核心，再檢查節點是否支援 UDP，不要只在 YAML 裡反覆切換這一行。

使用 WebSocket、gRPC 或其他傳輸層時，路徑、主機標頭和服務名稱都必須與伺服器端相符。網頁可以開啟，不代表代理服務的握手參數正確；伺服器連接埠能建立 TCP 連線，也不代表協定認證成功。日誌中的連線逾時、認證失敗和握手中斷分別指向不同階段，依階段排查，比一次更換所有參數更容易找到問題。

新協定或擴充欄位必須受目前核心支援。Clash for Windows 的舊核心無法只靠新增幾行 Mihomo 設定就補足功能。遷移時可先比較 Clash Plus、Clash Verge Rev、FlClash 等用戶端實際支援的範圍，詳細資訊請見用戶端比較。介面能匯入檔案，也不代表執行中的核心接受其中每一種節點。

最後要注意節點名稱是否唯一。同名節點可能造成引用目標不明，訂閱更新也可能改變名稱和順序。手動維護時，名稱只需說明用途，不要放入密碼、完整訂閱網址或個人帳號。分享故障設定前，請移除認證值與私人伺服器資訊；保留欄位結構和錯誤訊息，通常就足以判斷是格式問題還是協定支援界線。

05 策略群組選擇與健康檢查

策略群組介於規則與節點之間。規則將連線交給固定的群組名稱，再由群組決定使用哪個出口。更換節點時，就不必重寫每一條規則。先理解這層間接關係，再設計分組：一組負責手動選擇，一組負責自動測試；特定用途可另外建組，但不必為每個網站都複製一份相同成員清單。

分開設定手動選擇與自動選擇

# 使用上一章定義的兩個教學節點
proxy-groups:
  - name: "代理選擇"
    type: select
    proxies:
      - "自動選擇"
      - "範例 SS"
      - "範例 Trojan"
      - DIRECT

  - name: "自動選擇"
    type: url-test
    proxies:
      - "範例 SS"
      - "範例 Trojan"
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

select 是手動選擇群組，用戶端介面通常可直接切換成員。成員可以是節點、其他策略群組，或 DIRECT 這類內建出口。上例將自動群組也列為可選成員，因此日常可選擇自動測試，也能暫時固定使用某個節點。名稱僅供示範，修改時記得同步更新規則中的引用。

url-test 會透過測試要求比較候選出口，interval 是檢查間隔，通常以秒為單位；tolerance 則用來減少微小差異造成的頻繁切換，其意義與單位應以目前核心文件為準。常見實作中，上例的容差以毫秒表示。不要為了讓介面不斷更新而把檢查間隔設得過短；健康檢查同樣會產生連線與流量。

測試成功不代表實際服務可用

測試網址回應成功，只能表示當時透過該出口前往這個網址的要求順利完成，不代表影音、下載、遊戲和辦公系統都會有相同表現。延遲數值可能受到建立連線、握手和要求回應時間影響，卻無法直接反映持續傳輸速度。測試結果較快的節點，也可能因壅塞、封包遺失或目標網站限制，在實際使用時表現不佳。

因此，測試網址應選擇穩定且能正確回應的目標，並配合實際用途驗證。若所有節點都測試失敗，先檢查測試目標是否可連線、解析是否異常，不要立刻斷定所有伺服器都失效。數值與實際體驗的差異，請參閱節點延遲測試原理。

故障切換與負載平衡

fallback 通常依候選順序選擇可用出口，適合設定主要與備援線路；它不是另一種自動挑選最低延遲出口的方式。load-balance 則依實作支援的策略分配連線，不會把多個節點的頻寬直接加總成單一連線的速度。網站若會檢查登入工作階段或出口位址，還須評估分配方式是否影響工作階段穩定性。

策略群組的巢狀引用應保持方向清楚。可以讓「辦公」引用「代理選擇」，再由「代理選擇」引用具體節點；不要讓兩個群組互相引用而形成循環。遇到群組不存在或循環依賴錯誤時，先畫出從規則到節點的單向鏈路，並展開間接引用。群組越多越難排查，初始設定宜控制在少數能清楚說明用途的群組。

是否將 DIRECT 加入自動測試群組，應依使用目的決定。直連也可能通過測試並被選中，但此時連線走的是直連路徑，不再使用代理出口。若群組的目的在於固定使用代理，就不該只因直連測試數值較低而讓它參與選擇。候選範圍對最終行為的影響，通常比微調測試間隔更大。

用戶端可能會記住策略群組的選擇結果，重新載入後不一定會回到清單第一項。若規則命中正確，連線卻走了非預期出口，請展開群組查看實際選擇，並沿著巢狀關係一路追到最終節點。只看最外層群組名稱，無法判斷目前的連線路徑；切換訂閱後同名群組如何還原選擇，也須搭配用戶端的持久化設定確認。

透過提供器引入節點時，策略群組也可用 use 引用節點集合，詳細結構請見第七章。此時節點健康檢查和群組測試可能同時執行，應避免重複設定過於頻繁的檢查。修改群組結構後，除了確認設定能載入，也要在介面手動切換一次，再查看新連線的實際出口，確保引用沒有指向非預期的成員。

06 規則語法與比對順序

在規則模式下，通常會由上而下檢查規則；連線符合可用規則後，就交由指定的目標策略處理。較具體的例外應放前面，涵蓋範圍較廣的規則放後面，兜底規則則置於最後。規則清單不會自動計算「最精確的比對」：若前面的廣泛規則已符合條件，後面的細部規則就沒有機會處理這次連線。

先列明確例外，再列兜底規則

# 需要已存在的「代理選擇」策略群組
rules:
  - DOMAIN,portal.example.com,DIRECT
  - DOMAIN-SUFFIX,example.com,代理選擇
  - DOMAIN-KEYWORD,example,代理選擇
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,代理選擇

DOMAIN 精確比對指定網域，DOMAIN-SUFFIX 比對該網域及其子網域，DOMAIN-KEYWORD 則判斷網域名稱是否包含關鍵字。關鍵字比對範圍往往比預期更廣，可能連名稱相似、用途完全不同的服務都一併符合。若已知目標網域，優先使用精確或後綴規則，避免為了少寫幾行而犧牲可讀性。

範例將入口網站的直連例外放在網域後綴規則之前，因此連線到該入口網站時不會交給代理選擇。若交換兩行，後綴規則會先符合，例外就失效。排查「明明寫了規則卻沒作用」時，第一步應往上檢查是否有更早符合的規則，而不是不斷在清單底部加入相同規則。

網域規則與位址規則

IP-CIDR 用來判斷目標位址是否屬於指定網段。末尾的 no-resolve 表示不要為了這條位址規則主動將網域解析成 IP；若連線本身已帶有目標位址，仍可能進行位址比對。它不是「關閉所有 DNS」的開關，也不會讓網域規則失效。區域網路位址例外常會使用這個選項，以減少不必要的解析。

GEOIP 依據位址資料庫判斷目標 IP 所屬地區，不是根據網域註冊地、網頁語言或服務公司的所在地。網站使用跨地區 CDN 時，同一個網域可能回傳不同地區的位址。若業務需要明確走特定路徑，應使用清楚的網域規則，不要期待地理位址資料庫能完全取代業務分類。

MATCH 是最後的兜底規則，通常應放在清單末尾，讓前面都未處理的連線仍有明確出口。若在清單中段加入兜底，後面的規則通常就不會再生效。兜底要選代理還是直連，取決於使用目的；範例選擇「代理選擇」，但不代表所有網路環境都適合相同的預設行為。

檢查規則命中時要觀察新連線

修改規則後，已建立的長連線可能繼續沿用原本的出口，網頁也可能重複使用連線或快取資源。驗證時請重新發出要求，必要時關閉相關舊連線，再到 Connections 或日誌中檢查命中規則、策略群組與最終出口。不要只重新整理一次頁面就憑體感判斷規則無效，也不要只看群組名稱而忽略群組目前選取的節點。

程序規則取決於作業系統和核心能否辨識程序。Windows 上可能受到權限、接管方式與應用程式結構影響；瀏覽器子程序或系統服務也會讓程序名稱不如預期直觀。使用前先觀察連線紀錄中的實際程序資訊，再依目前核心支援的語法撰寫。跨平台共用設定時，網域規則通常比硬編碼本機路徑更容易維護。

規則過多時，先依用途整理，再考慮交由外部規則集維護。區域網路例外、特定服務例外、一般分流和最終兜底應各自保持清楚界線；不要為了追求完整，就直接串接多份來源不明的規則。清單變長不代表涵蓋更準確，衝突與重複反而會讓每次命中更難解讀。

若規則只在某個應用程式中失效，也要回頭檢查流量入口。核心未收到連線，再正確的規則也無法處理；應用程式若事先把網域解析成位址，網域比對也可能受到影響。將入口、解析、比對和出口分開檢查，通常比新增更多模糊規則更快找到原因。

07 節點訂閱與外部規則集

提供器會將經常變動的內容從主設定中分離。節點提供器管理一組節點，規則提供器管理一組比對條件；主設定只保留引用關係與策略安排。如此一來，更新節點時不必重寫本機用途分組，更新規則時也不必重新下載整份設定。不過，這會增加下載、解析、快取與引用等依賴，不能只因主設定載入成功，就認定所有內容都已可用。

完整訂閱與節點提供器並不相同

# 本機節點提供器範例；請先建立對應檔案
proxy-providers:
  local-nodes:
    type: file
    path: ./providers/local-nodes.yaml
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 600

proxy-groups:
  - name: "訂閱選擇"
    type: select
    use:
      - local-nodes

上例使用本機檔案，避免在教學範例中寫入私人訂閱網址。該檔案必須能由目前核心讀取，並包含節點提供器所需的資料結構。相對路徑通常以載入目錄或工作目錄為基準；用戶端也可能設定自己的工作目錄。請透過日誌和檔案管理入口確認實際位置，不要只根據主設定在磁碟上的位置推測。

# providers/local-nodes.yaml 的內容範例
proxies:
  - name: "本機範例 SS"
    type: ss
    server: ss.example.com
    port: 443
    cipher: aes-128-gcm
    password: "your-password"

完整訂閱可能包含連接埠、DNS、策略群組和規則；節點提供器通常只需要節點集合。不能把任何訂閱網址原樣放進 proxy-providers，就假設核心一定看得懂。先確認服務提供者輸出的格式及目前核心支援的內容，再決定要匯入整份設定，還是將其作為節點集合引用。格式不符時，有時會呈現為提供器清單為空，而非主設定直接報錯。

依行為類型整理規則提供器

# Mihomo 本機規則提供器片段
rule-providers:
  local-direct:
    type: file
    behavior: classical
    format: yaml
    path: ./rules/local-direct.yaml

rules:
  - RULE-SET,local-direct,DIRECT
  - MATCH,訂閱選擇

# rules/local-direct.yaml 的內容範例
payload:
  - DOMAIN-SUFFIX,example.com
  - IP-CIDR,192.168.0.0/16,no-resolve

這份規則檔使用 payload 包裝規則項目，實際出口由主設定中的 RULE-SET 決定。不要將一般的 rules 清單原封不動放入，也不要在每個項目後重複加入策略群組。規則集負責描述比對對象，主設定負責將它連接至出口；這樣的分工才方便在不同環境重複使用同一份規則。

behavior 必須與規則內容相符。網域集合、位址集合和經典規則項目不是相同格式；把經典規則當成純網域清單，可能導致解析錯誤或比對結果完全不同。Mihomo 還支援其他規則格式，但舊核心未必支援。準備共用設定時，應選擇目標核心確實接受的共同格式，而不是只在自己的用戶端測試一次。

分四個層次排查更新失敗

遠端提供器還需要可連線的下載網址、更新間隔與快取路徑。第一層確認網路要求是否成功，第二層確認回應是否為預期的 YAML 或規則資料，第三層確認核心是否能解析，第四層確認策略群組或規則是否確實引用該資料。網頁若回傳登入頁、訂閱額度提示或錯誤訊息，即使 HTTP 要求有收到回應，也不代表取得了可用設定。

更新間隔通常以秒設定，不應把頻繁重新整理當成修復方式。服務端可能限制要求次數，多個用戶端同時更新也可能觸發限制。先保留可用快取，再手動更新一次並查看錯誤；不清楚失敗原因時不要清空所有快取，以免暫時的下載問題變成完全沒有可用節點。

訂閱網址通常包含私人授權資訊，應像密碼一樣妥善保管。螢幕截圖、日誌和匯出的執行設定都可能洩漏完整網址。需要求助時，請以保留網域取代網址，並保留回應狀態、解析錯誤和相關欄位結構。不要把私人訂閱交給來源不明的線上轉換工具，也不要把他人的訂閱網址放進公開設定範例。

節點集合更新後，名稱變動可能影響手動選擇或篩選條件。確認提供器項目數量符合預期、策略群組仍有候選成員，再檢查新連線的出口。若出現「下載成功，但群組裡沒有節點」，請優先檢查引用名稱、資料格式和篩選條件。具體錯誤提示可搭配訂閱更新相關常見問題逐項排查。

08 覆寫、合併與執行驗證

訂閱負責更新遠端內容，本機覆寫則用來保留個人設定。兩者的界線必須明確，否則更新訂閱時可能遺失規則，或修改來源檔後又被介面設定覆蓋。先找到用戶端提供的設定管理入口，確認目前檔案是訂閱來源、覆寫片段還是最終執行檔，再決定要修改哪裡。Clash for Windows 的 Mixin，不能直接和其他用戶端的合併或腳本功能視為同一回事。

合併規則必須由實作明確定義

YAML 只描述資料，不會規定多個檔案如何合併。用戶端可能遞迴合併映射、直接取代清單，也可能提供專門的前置或後置規則機制。不同工具中名稱相似的「合併」按鈕，不保證語意相同。套用簡短的 rules 清單前，應先確認它是附加到原規則，還是取代整份規則；否則可能只剩下自己的兩條規則。

# 覆寫意圖片段：僅在用戶端支援相應合併方式時使用
mixed-port: 7890
allow-lan: false
log-level: info

dns:
  ipv6: false

上例表示固定的本機入口和部分解析選項，不是一份完整的執行設定。若將它當成獨立檔案載入，會缺少其他網路結構；若透過淺層合併取代整個 DNS 物件，則可能意外移除既有上游。正確做法是先在副本中套用，再檢視產生的結果，確認 nameserver、節點、策略群組或規則等原有內容都還在。

需要新增個人規則時，優先使用用戶端明確提供的規則插入位置。用途例外通常放在前面，最終兜底仍留在末尾；將新增規則接在既有 MATCH 後面不會得到預期效果。若用戶端沒有穩定的清單合併功能，可考慮由本地主設定引用節點提供器，而非持續修改整份訂閱產生的規則清單。

分辨檔案、介面與執行狀態

設定來源可能經過多個處理步驟：下載訂閱、套用本機片段、執行腳本、寫入執行檔，再通知核心重新載入。實際順序由用戶端決定，未經確認不能假定介面設定總是最後生效。遇到「儲存成功卻沒有變化」，先檢查最終執行設定，再確認重新載入是否成功，最後檢查舊連線是否仍沿用先前狀態。

若使用 Mihomo 命令列程式，可透過下方測試命令檢查設定。命令中的檔名應替換成實際檔案，工作目錄也須包含相關提供器檔案。測試通過主要表示核心能接受這份設定，不保證節點認證、遠端下載和實際服務存取都會成功。舊環境應查看相應核心的說明確認參數，不要直接照搬程式名稱。

mihomo -t -f config.yaml

驗證時逐層進行：先檢查語法與引用，再確認入口監聽，接著檢查 DNS 和提供器，最後驗證實際連線。若錯誤訊息指出行號，也應一併檢查該行上方的縮排、引號和清單邊界，因為解析器指出的錯誤位置不一定就是最早出錯的地方。修正一處後重新測試，不要把多項推測性的修改一次套用到正在使用的設定。

先保留復原點，再檢查實際要求

正式修改前，先匯出目前可用的設定，並記下已啟用的覆寫項目與策略群組選擇。保留一份可還原的本機副本，不要只依賴可能持續變動的訂閱網址。修改後若網路中斷，先還原到最後一個可用狀態，不必在失去連線時繼續新增欄位。備份也可能包含私人認證資訊，請存放在受控位置，不要上傳至公開空間。

驗證連接埠時，可使用支援代理參數的工具發出要求，但要分辨是連上入口，還是已成功存取目標。在 Windows 上執行下例時，使用 curl.exe 明確呼叫程式，避免部分終端機中的同名別名造成干擾。目標使用保留的範例網站；若目前網路無法連線，應依回傳錯誤判斷問題階段，不能只憑命令的結束結果就判定所有節點。

curl.exe -I --proxy http://127.0.0.1:7890 https://example.com/

接著查看連線紀錄中的目標、命中規則和最終出口，並分別測試需要直連與代理的服務。驗證 TUN 時，也應使用不會自行讀取系統代理的應用程式，確認接管範圍符合預期。不要同時執行多個用戶端，以免它們爭用系統代理、虛擬網卡或監聽連接埠；遇到不穩定時，先只保留一條明確啟用的網路接管路徑。

一份容易維護的設定，應能回答四個問題：流量從哪裡進入、網域在哪裡解析、由哪條規則做出選擇，以及最後使用哪個出口。每次變更都聚焦其中一個層次，留下用途註解，並刪除已失效的臨時例外。如此一來，訂閱更新、系統切換或更換用戶端後，仍能沿著同一條鏈路找出問題，而不必從頭堆出更長的設定。