Clash 設定檔參考

YAML 結構與設定入口

設定檔的核心，是描述監聽入口、解析方式、可用的輸出連線，以及分流順序。檔案能通過 YAML 解析，只代表格式正確，不代表節點能連線，也不代表目前使用的核心支援所有欄位。排查時應依序區分語法錯誤、欄位語意錯誤與執行環境問題，避免把網路逾時歸咎於縮排，或把策略組名稱錯誤誤認為訂閱失效。

頂層映射與巢狀層級

常見頂層欄位包括 mixed-port、mode、dns、proxies、proxy-groups 和 rules。頂層鍵從行首開始，子欄位則依固定空格數縮排。通常統一使用兩個空格，不可用定位字元代替。清單項目以連字號和空格開頭；同一節點的名稱、協定、位址與連接埠必須屬於同一個清單項目。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

proxies: []

proxy-groups:
  - name: 預設出口
    type: select
    proxies:
      - DIRECT

rules:
  - MATCH,預設出口

以上是用於驗證直連的最小設定，不包含遠端代理服務。適合確認監聽、策略引用與規則載入流程是否正常，但不能據此判斷遠端節點是否可用。proxies: [] 表示節點清單為空；策略組引用內建出口 DIRECT，最後一條規則則引用已定義的組名。實際加入節點時，應先新增節點，再將名稱加入組內。

字串、清單與布林值

連接埠、間隔等數值通常不加引號，開關則使用 true 或 false。節點密碼、含特殊字元的名稱、規則字串與 URL 可以加上引號，減少冒號、井字號或解析器差異造成的歧義。井字號在適當位置代表註解，因此密碼包含井字號時，更應明確寫成字串。單引號字串中的單引號要寫成兩個；雙引號中的反斜線則可能觸發跳脫。

區塊清單與行內清單都是合法的 YAML 寫法，但維護長篇設定時，區塊清單更容易逐行檢視。節點也能寫成大括號形式，不過欄位較多時仍建議展開。請勿為了縮短行數混用多種風格，也不要在鍵名與分隔符之間放入中文冒號、全形逗號或從網頁複製而來的不換行空格。

檔案位置與有效設定

用戶端介面中的訂閱原文、編輯器裡的本機檔案，以及核心最後載入的設定，可能是三個不同的項目。訂閱更新後，用戶端也可能會加入監聽連接埠、控制介面及覆寫規則。查閱檔案前，請先確認目前啟用的設定名稱、更新時間，以及是否存在合併指令碼，再透過用戶端提供的執行中設定檢視入口核對最終結果。

同一層級不要重複定義相同的鍵。有些解析器會拒絕重複鍵，另一些則保留後出現的值，結果難以預測。需要新增規則時，應修改原有清單，或使用用戶端明確支援的合併入口，而不是在檔案末尾再寫一段 rules。不同設定也不會只靠複製貼上就自動完成語意合併。

儲存檔案時請使用 UTF-8 編碼，並確認副檔名確實是 .yaml 或用戶端接受的格式，而不是隱藏了額外的文字副檔名。發生解析錯誤時，先查看記錄指出的那一行及其前面的清單內容；問題常出在上一行缺少引號、縮排不一致，或清單項目未正確結束。

連接埠、模式與流量接管範圍

監聽連接埠決定應用程式將連線交給哪裡，運作模式決定核心如何選擇出口，系統代理與 TUN 則決定流量如何進入核心。三者彼此相關，但不能互相取代。只修改 mode 不會讓所有應用程式自動使用代理；只啟用系統代理，也不能保證不讀取系統代理設定的程式會進入核心。

HTTP、SOCKS 與混合連接埠

port 用於 HTTP 代理監聽，socks-port 用於 SOCKS 代理監聽，mixed-port 則在同一個連接埠接受 HTTP 與 SOCKS 要求。一般桌面使用通常保留混合連接埠即可；確實需要為應用程式分開設定時，再新增獨立監聽。多個監聽不可綁定到相同位址上的同一個連接埠，否則會發生連接埠占用衝突。

mixed-port: 7890
allow-lan: false
bind-address: "127.0.0.1"
mode: rule
log-level: info
ipv6: false

連接埠遭占用時，應先確認占用的程序是舊用戶端、另一套代理工具，還是系統服務。不要直接結束不熟悉的程序。變更連接埠後，還要同步修改系統代理、瀏覽器擴充功能、終端機環境變數，以及應用程式中手動填寫的代理位址。詳細操作請參閱7890 連接埠衝突排查與 mixed-port 修改步驟。

規則模式與全域模式

rule 會依規則清單由上而下比對，通常適合作為日常設定；global 使用全域策略選擇，適合暫時驗證出口；direct 則使用直連出口。切換模式只會改變已進入核心的連線如何處理，不會改變作業系統的路由機制。用戶端介面上的模式按鈕也可能覆蓋檔案欄位，請以執行狀態為準。

啟用區域網路共享時，必須允許區域網路連線，並讓監聽位址涵蓋對應網路介面卡，例如依實際環境設定 bind-address: "*"。這會擴大代理服務的可存取範圍，因此也應限制防火牆允許的來源、視需要設定代理驗證，並避免將連接埠轉發到公網。只把其他裝置的代理位址填成主機 IP，不會自動開放監聽。

系統代理與 TUN

系統代理仰賴應用程式遵循系統代理設定，涵蓋範圍明確，適合作為首次連線的驗證方式。TUN 透過虛擬網路介面接管流量，通常需要管理員權限、修改路由並配合 DNS。若應用程式已設定代理，又啟用 TUN，可能造成重複接管；請先記錄現況，再一次只變更一種接管方式。

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

這段 TUN 設定用來說明欄位之間的關係，不應直接在遠端管理伺服器上啟用。自動路由可能影響遠端工作階段、容器網路及企業 VPN。dns-hijack 會處理進入接管範圍的相關 DNS 流量，不代表所有加密 DNS 都會被接管；實際情況也會受系統路由、應用程式行為及核心支援程度影響。

頂層的 ipv6 與 DNS 中同名欄位的作用範圍不同，不能只關閉其中一處，就認定裝置上的所有 IPv6 流量都已停止。需要使用 IPv6 時，應一併確認上游網路、節點能力與接管路由。進一步比較請參閱TUN 模式與系統代理的運作方式。

DNS 解析與位址映射

設定 DNS 時，應先確保解析鏈能獨立啟動，再處理分流與增強模式。要求逾時不一定是節點問題：解析伺服器無法連線、加密 DNS 網域無法透過引導解析，或節點伺服器的網域解析形成循環，都可能使連線尚未建立就失敗。排查時先區分目標網域解析、代理伺服器解析，以及 DNS 服務自身的網域解析。

常用欄位與啟動解析流程

enable 用來啟用內建 DNS，listen 則指定其監聽位址。只有應用程式實際向該監聽送出要求，或要求被接管至內建 DNS，相關設定才會生效。default-nameserver 可用於引導解析加密解析服務的網域；上游應使用核心支援的 IP 格式，避免再依賴尚未建立的網域解析。

dns:
  enable: true
  listen: "127.0.0.1:1053"
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver:
    - 223.5.5.5
    - 119.29.29.29
  nameserver:
    - https://dns.alidns.com/dns-query
  proxy-server-nameserver:
    - 223.5.5.5
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "localhost"

此範例展示本機監聽、引導解析與節點網域解析各自的用途；列出的上游是否適合目前的網路，仍需實際測試。1053 不是作業系統預設的 DNS 連接埠，不能只寫入檔案，就期待所有系統要求自動轉送至此。若改用標準連接埠，也應檢查權限、是否已有服務占用，以及系統設定解析位址的方式。

fake-ip 與真實位址解析

fake-ip 會為網域指派映射位址，讓核心保留網域脈絡，再於建立連線時選擇實際出口。這有利於依網域分流，但某些區域網路探索、位址比對，或只接受真實 IP 的程式可能需要例外。範例網段用於內部映射，不是遠端代理伺服器位址，也不應直接用作其他裝置的閘道。

fake-ip-filter 用於讓特定網域略過此映射流程。匹配方式應依目前核心文件核對，請勿與路由規則中的 DOMAIN-SUFFIX 寫法混淆。遇到相容性問題時，先針對確切網域新增小範圍例外，再觀察應用程式是否恢復正常。排除所有網域會讓所選的增強模式失去原有作用。

redir-host 會回傳真實解析位址，方便某些依賴真實 IP 的應用程式使用，但網域與 IP 的關聯可能受快取、應用程式內建解析及要求路徑影響。兩種模式並非速度排名，應依接管方式與應用程式相容性選擇。切換後請重新建立連線，並清除作業系統與應用程式中保留的舊解析快取。

依網域選擇上游

nameserver-policy 用於為指定網域選擇解析伺服器。企業內部網域通常需要使用企業 DNS，不應交由公共解析服務處理；區域網路裝置名稱也可能只有路由器查得到。以下以保留網域說明設定方式，內網位址必須替換為目前網路中確實存在且可連線的 DNS 服務。

dns:
  nameserver-policy:
    "+.corp.example":
      - 192.168.50.1

這段設定應合併至原有的 dns 映射中，並非另一個頂層 DNS 宣告。設定 respect-rules 讓 DNS 連線遵循路由規則時，必須特別避免依賴循環，並明確安排代理伺服器網域的解析路徑。尚未確認引導解析與出口依賴前，不建議強制將所有解析要求送入代理組。

如果一般應用程式運作正常，但啟用安全 DNS 的瀏覽器表現不同，請檢查瀏覽器是否直接使用自己的加密解析服務。這條路徑可能繞過預期的系統 DNS 設定。先在單一測試應用程式中確認解析路徑，再決定是否調整應用程式設定或接管策略，避免同時變更多個變因。

代理節點與協定欄位

proxies 用來描述可用的遠端出口，不負責定義何時選用它們。每個節點至少需要唯一名稱、正確的協定類型、伺服器位址，以及協定要求的驗證與傳輸參數。伺服器位址與密碼正確，不代表設定已完整；傳輸方式、TLS、伺服器名稱與路徑不一致，都可能導致交握失敗。

基本欄位與名稱引用

name 是設定內部的引用識別，也會做為策略組與介面中的顯示名稱，應保持唯一且固定。server 填入伺服器 IP 或網域，不可填入含路徑的網頁網址；port 填入伺服器端的監聽連接埠，不是本機混合連接埠。type 決定其他欄位的解讀方式，不能只改類型就把一種協定轉換成另一種。

proxies:
  - name: SS 範例
    type: ss
    server: proxy.example.com
    port: 443
    cipher: aes-128-gcm
    password: "your-password"
    udp: true

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

範例網域與密碼僅用於展示欄位結構，不能用來實際連線。Shadowsocks 的 cipher 與密碼必須和伺服器端一致；Trojan 的密碼、伺服器名稱與憑證設定也必須相符。不要根據用戶端名稱猜測協定參數，應以服務提供者提供的原始連線資料或相容訂閱為準。

TLS 與傳輸參數

TLS 伺服器名稱不一定等於連線位址，但必須符合服務端部署與憑證要求。不同協定可能使用 sni 或 servername，不可一律直接替換。遇到憑證錯誤，應先檢查裝置時間、網域拼寫、憑證涵蓋範圍與伺服器設定；關閉憑證驗證會降低身分驗證能力，不應做為一般修復方式。

WebSocket 節點也可能要求特定路徑與 Host 要求標頭，gRPC 節點則可能要求服務名稱。這些參數不是可任意調整的最佳化選項，而是交握流程的一部分。節點資料若指定傳輸方式，也應一併核對相應的巢狀選項。即使位址和密碼相同，複製另一個節點的路徑仍可能收到拒絕回應。

協定相容性與分層排錯

mihomo 與較早期的 Clash 核心，在協定及擴充欄位支援方面並不完全相同。訂閱能在一個用戶端匯入，不代表換用其他核心後仍能辨識所有節點。選擇時先確認核心能力，再確認用戶端是否保留並正確傳遞欄位；需要安裝用戶端時，請前往用戶端下載頁，一般使用者可優先從 Clash Plus 開始設定。

排錯時應依序檢查網域解析、TCP 或 UDP 是否可連線、協定交握、驗證，以及目標要求。解析失敗先查 DNS，連線遭拒先查連接埠與服務狀態，TLS 錯誤先查名稱與憑證，驗證失敗再核對密碼或識別碼。不要每次都刪除並重建整個節點，否則容易遺失有助於定位問題的記錄線索。

udp: true 只代表允許相應節點嘗試處理 UDP，不會讓所有接管方式自動支援 UDP。應用程式透過 HTTP 代理傳送的要求，與 TUN 接收的 UDP 資料路徑並不相同；伺服器端、協定實作及網路防火牆也可能限制流量。測試時應先確認應用程式實際使用的協定，不要只根據頁面連線成功就判定 UDP 可用。

策略組類型與選路邏輯

proxy-groups 會將節點整理成可選擇的出口集合。規則通常指向固定的組名，再由組別決定實際使用的節點，更新訂閱後就不必逐條修改規則。理解策略組時，應將手動選擇、健康檢查與實際業務要求分開看待：檢測成功只代表符合某項測試條件，不代表所有目標都能正常存取。

手動選擇與自動選擇

select 提供手動選擇，適合用於頂層出口或明確指定用途。url-test 會根據定期探測結果選擇候選項目，tolerance 可減少微小差異造成的頻繁切換。fallback 依清單優先順序使用可用項目，不會優先選擇探測耗時最短的項目。若要固定首選線路，應先考量這項優先順序的差異。

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

  - name: 故障切換
    type: fallback
    proxies:
      - SS 範例
      - Trojan 範例
    url: https://www.gstatic.com/generate_204
    interval: 300

  - name: 預設出口
    type: select
    proxies:
      - 自動選擇
      - 故障切換
      - DIRECT

範例引用上一章定義的節點名稱；若節點尚未匯入，請先補上或改用現有名稱。測試 URL 是執行時的探測目標，不是頁面相依資源；請確認它適用於目前網路與各個出口。不同目標的回應狀況各異，修改測試位址後，原有的探測結果也不能直接互相比較。

檢測間隔與可用性的意義

interval 通常以秒為單位；在相應的自動測試組中，tolerance 通常以毫秒表示切換容差。縮短間隔會增加探測要求與網路活動，不一定能提升業務穩定性。行動裝置還應考量背景執行與耗電問題。建議先使用合理的間隔觀察，再依實際故障復原需求調整，不要把所有數值都設得太小。

lazy 可依支援情況減少未使用組別的主動檢測，因此剛開啟介面時沒有新的探測結果，不一定代表節點故障。組別檢測、資源提供者健康檢查，以及使用者點擊節點後觸發的速度測試，可能由不同機制啟動。查看結果時，請確認檢測對象、最近執行時間與測試位址，避免把單一結果誤認為整體狀態。

負載分配與巢狀引用

load-balance 用於分配多個連線，可依具體策略維持一定程度的目標一致性，或輪流使用候選出口。它不會將單一下載連線拆成多條線路來疊加速度。對來源位址敏感的登入、付款或長時間連線服務，頻繁更換出口可能觸發額外驗證，建議使用較穩定的組別或個別規則處理。

策略組可以引用其他組別，但應保持結構簡潔，避免形成循環引用。例如，預設出口可以引用自動選擇組，自動選擇組則不應再引用預設出口。命名時也不要讓組名與節點名稱重複，否則檢視設定與定位記錄時容易產生歧義。變更名稱後，應一併搜尋規則、巢狀組別與覆寫指令碼中的舊引用。

如果介面仍保留先前的手動選擇，請檢查用戶端是否儲存組別選擇狀態，以及設定中的 profile.store-selected 是否會還原選擇。檔案中的第一個候選項，不一定就是目前實際使用的項目。完整類型比較與設定方式請參閱url-test、fallback 與 load-balance 設定說明。

規則順序與匹配語法

rules 通常依序由上而下比對，第一條符合的規則會決定出口。設定正確卻走錯線路時，優先檢查前面是否有範圍過廣的規則，而不只是確認目標規則存在。最後的兜底通常使用 MATCH；它會接收前面未命中的要求，因此放在清單中間時，後面的普通規則便不會有機會執行。

網域規則與位址規則

DOMAIN 會比對指定網域，DOMAIN-SUFFIX 會比對該網域及其子網域，DOMAIN-KEYWORD 則依網域中的關鍵字比對。關鍵字規則的範圍較廣，不適合取代已明確掌握的網域清單。規則目標可以是內建出口、節點名稱或策略組名稱；實際維護時通常使用組名，日後更換線路就不必修改分流邏輯。

rules:
  - DOMAIN,router.lan,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
  - IP-CIDR6,fc00::/7,DIRECT,no-resolve
  - MATCH,預設出口

範例會將幾個常見的私有位址範圍設為直連，其餘要求則交給預設出口。這不是適用於所有裝置的完整區域網路規則：企業網路、虛擬網段與特殊路由可能還需要額外處理。example.com 是示範網域；實際分流應依據真實目標及其相依網域逐步補齊，不宜直接套用範圍過大的關鍵字。

no-resolve 與網域脈絡

no-resolve 表示此位址類型的規則不會主動觸發網域解析來完成比對。如果連線已有可用的目標 IP，仍可能符合相應的位址規則；這個選項並非停用 DNS。遇到網域要求時，是否加入此選項會影響比對流程與解析負擔，因此不應將它視為每條規則都必須加上的固定後綴。

GEOIP 會依據位址資料庫判斷目標 IP 所屬區域，GEOSITE 則仰賴相應的網域分類資料與核心支援。資料庫分類不等於服務實際營運範圍，也不保證同一網站的所有相依項目都屬於相同集合。設定引用相關資料後，應確認檔案存在、來源適用且更新成功；不能只因欄位被接受，就認定資料已載入。

程序規則與接管範圍

程序名稱或路徑規則必須由目前的平台與接管機制提供程序資訊。路由器通常無法得知區域網路另一台裝置上是哪個應用程式發出要求；某些行動作業系統也有權限限制。使用這類規則前，請先在連線詳細資訊中確認是否看得到程序欄位，再決定要比對名稱還是完整路徑，不要只根據應用程式視窗標題填寫。

規則只能處理已進入核心的要求。若連線清單中完全沒有某個程式的記錄，應先檢查系統代理、應用程式代理設定或 TUN 路由，而不是繼續新增網域規則。如果清單中看得到要求，請核對目標網域、目標 IP、命中規則與最終出口；沿著這四項逐一定位，通常比反覆更換節點有效。

以最小範圍驗證規則

驗證單條規則時，先暫時縮小至單一網域與明確出口，確認命中後再擴大至後綴或規則集。網頁通常會同時要求靜態資源、API 與身分驗證網域；如果只將主網域設為代理，部分資源仍可能走其他出口。請依連線記錄補上必要的相依項目，而不是把所有未知網域都加入範圍過廣的比對規則。

修改規則後重新載入設定，再建立新的測試連線。既有 HTTP 連線重用、下載工作與即時通訊工作階段可能會繼續使用舊出口，不適合做為驗證新規則的唯一依據。常見連線問題可繼續參閱常見問題與故障排除；接管方式的操作順序則請參照使用教學。

資源提供者與更新機制

資源提供者會將經常更新的節點或規則從主要設定中分離，讓主檔案保留穩定結構。proxy-providers 管理節點資源，rule-providers 管理規則資源，兩者的內容格式與引用位置不同。提供者下載成功只代表取得檔案；還需確認內容格式正確、已由組別或規則引用，並且在目前設定中實際生效。

節點資源與訂閱格式

節點提供者使用的 YAML 資源通常以 proxies 做為主要結構。完整 Clash 設定、獨立節點資源與 Base64 編碼的節點連結清單並不相同。有些用戶端支援匯入轉換，不代表核心的 HTTP 提供者也能直接解析相同的原始內容。匯入前可參閱訂閱 URL、本機 YAML 與 Base64 格式說明，辨識資源類型。

proxy-providers:
  遠端節點：
    type: http
    url: "https://subscription.example.com/nodes.yaml"
    path: ./providers/nodes.yaml
    interval: 3600
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 300

proxy-groups:
  - name: 訂閱選擇
    type: select
    use:
      - 遠端節點

範例位址需要替換成服務提供者提供的相容資源。path 是本機快取位置，相對路徑通常以核心工作目錄或用戶端指定的資料目錄為基準，不是網頁所在目錄。目錄不可寫入，或多個提供者共用同一路徑，都可能造成更新或快取異常。為不同資源使用獨立檔名，可減少檔案誤覆寫及排查成本。

外層的 interval 控制資源更新週期，health-check.interval 控制節點探測週期；兩者通常都以秒為單位，但用途不同。訂閱尚未更新，不代表健康檢查沒有執行；健康檢查成功，也不代表訂閱內容已刷新。請分別核對介面上的更新時間與探測結果，不能用其中一項推斷另一項。

規則資源與 behavior

規則提供者的內容格式、format 與 behavior 必須彼此相符。domain 適用於網域集合，ipcidr 適用於位址區段集合，classical 則適合包含規則類型的項目。不要只為了配合任意檔案而修改行為名稱；資源實際內容不同時，必須正確轉換或選用相應格式。

rule-providers:
  本機直連：
    type: file
    behavior: classical
    format: yaml
    path: ./rules/local-direct.yaml

rules:
  - RULE-SET,本機直連,DIRECT
  - MATCH,預設出口

對應的 local-direct.yaml 只存放比對條件，不必在每個項目後重複寫出出口；出口由主設定中的 RULE-SET 行指定。以下檔案展示 classical YAML 的基本結構，必須實際儲存至宣告的路徑。規則集內的排列順序與主設定中的引用位置都應保持清楚。

payload:
  - DOMAIN,router.lan
  - IP-CIDR,192.168.0.0/16,no-resolve

更新相依項目與離線快取

遠端資源更新本身也需要可用的解析與網路路徑。首次啟動時，如果下載資源必須依賴尚未取得的節點，可能形成啟動依賴循環。應保留可連線的更新路徑或有效快取，並依用戶端與核心的支援情況安排下載出口。尚未確認遠端資源可取得前，不要刪除唯一可用的本機節點與快取檔案。

更新失敗時，應分別檢查 HTTP 狀態、回應內容類型、解析錯誤與本機寫入權限。伺服器回傳登入頁面或錯誤頁時，檔案或許仍會下載，但內容並非有效的節點或規則資源。訂閱連結含有存取憑證，請只在可信任的用戶端或受控環境中使用，不要提交給來源不明的線上轉換服務。

覆寫、合併與生效驗證

訂閱負責提供遠端內容，覆寫則用來保留本機設定意圖，兩者應盡量分開處理。直接修改訂閱產生的檔案，往往會在下次更新時遺失；複製成完全獨立的本機設定，則必須自行維護節點變動。建議先明確劃分哪些欄位由訂閱管理、哪些由本機設定接管，再檢查最終執行中的設定是否符合預期。

欄位歸屬與合併順序

用戶端可能先讀取訂閱，再合併介面設定，最後套用規則修補或指令碼；實際順序並不一致。不要假設所有用戶端都支援相同的覆寫檔案，也不要將其他用戶端的指令碼語法直接放入 YAML。Clash Plus、Clash Verge Rev 等用戶端的設定入口應以實際介面為準；核心本身不會替用戶端解讀所有合併擴充功能。

純量、映射與清單需要分別處理。連接埠這類純量通常會由後寫入的值取代；DNS 映射可能依鍵合併，也可能整段取代；規則與策略組清單則可能遭覆蓋、附加或前置。若合併工具沒有明確保證，就不能推斷陣列會自動去重，更不能假設同名節點會依名稱安全合併。

前置規則與穩定引用

自訂規則通常需要插入訂閱兜底規則之前，而不是直接加到檔案末尾。若用戶端提供前置規則入口，可用以下兩行表達區域網路直連的意圖；這兩行是規則清單項目，不是通用的覆寫檔案格式。外層結構應依目前用戶端的合併機制填寫。

- DOMAIN,router.lan,DIRECT
- IP-CIDR,192.168.0.0/16,DIRECT,no-resolve

本機規則應盡量引用穩定的組名。訂閱更新後若刪除或重新命名某個組別，原有規則可能無法載入；若將規則直接綁定在容易變動的節點名稱上，維護成本會更高。需要固定的本機入口時，可在用戶端支援的覆寫層建立自訂組別，再引用訂閱提供者；但也要確保提供者名稱有穩定來源。

儲存、檢查與重新載入

套用修改前，請先儲存目前可用的設定及覆寫設定副本。一次只調整一個功能範圍，例如先修改連接埠並完成驗證，再調整 DNS。若能使用核心命令列環境，可透過測試模式檢查設定；桌面用戶端也可能提供內建檢查功能。以下命令的工作目錄，應與資源相對路徑實際採用的基準一致。

mihomo -t -d ./profile -f ./profile/config.yaml

測試通過只代表目前的測試環境接受該設定，不代表所有遠端服務都已成功連線，也不代表用戶端執行時不會再次覆蓋欄位。若設定依賴外部資源，應確認檔案位置與可用性。接著回到用戶端重新載入設定、查看啟動記錄，核對連接埠監聽、DNS 初始化與提供者載入是否有錯誤，再發出新的業務連線。

回復與問題記錄

重新載入設定失敗時，用戶端可能仍以舊設定繼續運作。介面仍能連網，不代表新檔案已生效；請檢查錯誤通知與目前啟用狀態。若無法確認問題來源，先還原最近可用的副本，再逐項重新套用修改。涉及 TUN、系統代理或 DNS 時，也要確認回復後的系統層設定是否一併還原，避免檔案已回復但網路接管仍維持新狀態。

有效的問題記錄應包含所用的用戶端與核心名稱、接管方式、出問題的欄位片段、記錄中的第一條相關錯誤，以及重現前後的變化。不要只描述無法連線，也不要提交完整且含敏感資訊的訂閱。一般問題請先對照常見問題；需要重新完成安裝與匯入流程時，請回到快速入門教學，排錯不必反覆重裝整個環境。