Clash 設定檔
完整指南

01 · YAML 結構與設定入口

Clash 設定檔通常採用 YAML。它不是逐行執行的指令碼，而是具有層級結構的資料：頂層鍵描述核心行為，巢狀映射儲存功能參數，清單則列出多個節點、策略組或規則。閱讀時先找與左側邊界對齊的欄位，再往下確認所屬內容。不能只因兩行距離很近，就認定它們有從屬關係。

映射、清單與縮排

映射以冒號分隔鍵和值，冒號後通常留一個空格；清單項目以連字號開頭。縮排必須使用空格，不要混用定位字元。本文統一採用兩格縮排，這是方便維護的慣例，並非欄位名稱的一部分。同一層級必須對齊，尤其要分清節點清單中的第二個節點，以及第一個節點內的附加參數。

mixed-port: 7890
mode: rule
allow-lan: false

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,PROXY

這裡的 proxy-groups 是清單，第一個項目包含名稱、類型與可選的出站；其中的 proxies 又是另一份清單。頂層的 proxies 用來定義代理節點，群組內同名欄位則表示要引用哪些出站，意義取決於所在層級。若把群組內的引用誤放在頂層，即使文字仍可解析，也可能造成類型或引用錯誤。

字串、布林值與重複鍵

連接埠通常寫成整數，開關通常寫成 true 或 false。密碼、網域、節點名稱等會視為字串；若內容包含井字號、冒號後接空格，或其他容易造成歧義的字元，建議加上引號。井字號在適當位置代表註解，未加引號的密碼可能會被截斷。雙引號會處理跳脫字元；一般文字可優先使用單引號，減少反斜線造成的誤解。

同一個映射中不要重複定義相同的鍵。例如在檔案開頭寫一段 dns，末尾再補一段 dns，不代表兩段內容一定會合併。解析器可能拒絕重複鍵，也可能只保留其中一個值。需要新增子欄位時，應回到原本的區塊修改。清單可以逐行書寫，也能使用方括號格式；不過排錯時，逐行書寫較容易看清楚項目所屬。

來源檔案與執行檔案的差異

桌面版用戶端通常同時存在訂閱原始檔、編輯副本、覆寫規則，以及交給核心執行的設定檔。在編輯器中成功儲存，只能代表檔案已寫入；是否真正生效，還要看用戶端是否採用該檔案，以及後續產生設定的流程會不會覆蓋修改。排錯時先確認目前啟用的設定檔名稱，再檢查執行設定或核心記錄，避免一直修改未被選用的副本。

以命令列執行 mihomo 時，可使用 mihomo -t -f ./config.yaml 測試設定。命令中的執行檔名稱與路徑需依實際安裝位置調整。測試通過主要表示結構與部分引用可被接受，不代表遠端伺服器可連線，也不代表所有規則都符合預期。用戶端內建的測試功能與終端機命令使用的核心也可能不同，請確認實際載入的設定。

建立可還原的基準設定很重要：保留原始檔案，每次只修改一個功能區塊，並記錄修改目的。遇到錯誤時，先還原這次變更，再逐項加回。不要同時調整 DNS、TUN 和規則順序，否則連線失敗時可能有多種原因。若只是要完成首次匯入，請先依照匯入訂閱步驟完成流程，再回頭擴充設定。

02 · 連接埠、模式與通用欄位

通用欄位會控制核心如何接收連線、向哪些裝置開放入口，以及以哪種模式選擇出站。這些欄位屬於頂層設定，通常不會因為寫在檔案前段或後段而改變意義。初次調整時，建議先維持最小監聽範圍，只讓本機應用程式使用代理；確認連線正常後，再考慮區域網路存取、控制介面或其他連線方式。啟用的功能越多，排錯時就越需要確認各項界線。

代理連接埠與監聽位址

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

上例適用於本機使用。應用程式手動設定代理時，位址可填 127.0.0.1，連接埠則填相應數值。若出現位址已被使用的錯誤，先確認是否啟動了第二個用戶端或另一個核心程序，再決定關閉衝突程式或更改連接埠。單純反覆重新啟動通常無法解決連接埠占用，還可能讓多個背景程序更難辨認。

allow-lan 與 bind-address 應一併理解。前者控制是否允許區域網路存取，後者控制監聽位址；此外也會受到作業系統防火牆影響。只設定為允許區域網路，不代表其他裝置一定能連線。若確實需要共用，還要設定適當的驗證方式與存取範圍，避免將原本只供可信任網路使用的代理入口暴露在公用網路上。

規則、全域與直連模式

mode: rule 代表依規則清單決定出站；全域模式使用全域選取的出站；直連模式則不會依一般代理規則選擇遠端代理。全域模式不等於接管裝置的所有流量，只會影響已進入核心的連線。沒有設定系統代理、未另外設定應用程式代理，也未由 TUN 接管的程式，仍可能完全不經過核心。

用戶端介面的模式按鈕可能透過控制介面即時變更執行狀態，但來源檔案中的 mode 仍保留原值。因此，修改檔案後若看到介面仍處於全域模式，請確認用戶端是否還原上次選擇，或是否有獨立設定項目優先生效。在排查規則未命中之前，先確認目前實際執行的是規則模式，避免在錯誤前提下調整整份規則清單。

記錄、控制介面與持續狀態

log-level 一般使用 info，需要查明細節時再暫時調高為 debug。詳細記錄可能包含存取網域、節點名稱與本機位址，分享前應刪除敏感內容。控制介面與代理連接埠用途不同：前者用來管理核心，後者用來轉送應用程式連線。不要把管理連接埠填入瀏覽器的 HTTP 代理設定，也不要為了解決連線失敗而擴大管理介面的監聽範圍。

若需要控制介面，建議限制在回送位址，並設定強度足夠的 secret；真實密鑰只保存在自己的裝置上。有些用戶端會自行產生並管理這些欄位，手動覆寫可能導致介面無法連上核心。若設定同時涉及用戶端偏好與核心檔案，應優先使用用戶端提供的設定入口，再從執行設定確認結果。

持續保存選擇的設定也會影響觀察結果。例如啟用保存策略組選擇後，重新載入設定時可能恢復先前選過的節點，而非群組清單中的第一項。判斷設定是否生效，應同時確認執行模式、策略組目前選擇與連線記錄，不能只看檔案中最前面的名稱。連接埠占用、系統代理殘留等問題，可繼續參考說明中心。

03 · DNS、Fake-IP 與解析路徑

DNS 設定會決定網域如何轉換為位址，也會影響核心能否保留網域資訊供規則比對。請分別釐清三件事：應用程式將查詢傳給誰、核心收到查詢後使用哪個上游解析，以及連線到遠端節點時由誰解析節點伺服器的網域。這三條路徑可能不同，因此瀏覽器能查到網站位址，不代表代理伺服器的網域也已成功解析。

基本欄位與上游解析器的用途

dns.enable 用來啟用內建 DNS，listen 用來指定監聽位址與連接埠。成功監聽不代表作業系統已開始使用它；用戶端或系統網路設定仍須將查詢送到這個入口。本文以回送位址上的非特權連接埠為例，方便與系統既有 DNS 服務區分；是否採用此連接埠，應依實際接管方式與權限條件決定。

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
  nameserver:
    - https://dns.alidns.com/dns-query
  proxy-server-nameserver:
    - 223.5.5.5
  fake-ip-filter:
    - '*.lan'
    - '*.local'

nameserver 是一般解析用的上游，可設定一般 DNS 或支援的加密 DNS 位址。若加密上游本身使用網域，核心必須先取得該網域的位址，default-nameserver 可用來進行這類前置解析。不要把前置解析器也設為必須依賴同一條尚未建立的連線才能存取的位址，否則容易形成先有代理還是先有解析的循環。

proxy-server-nameserver 用來解析代理伺服器網域，適合將節點位址解析與一般網頁解析分開設定。設定後仍須確認解析器能從目前網路連線。如果記錄顯示無法解析節點伺服器，應先檢查節點網域與此處的上游，不要直接在網頁網域過濾清單中新增項目。解析目標不同，應修改的位置也不同。

Fake-IP 與真實位址解析

Fake-IP 模式會為網域指派保留位址，並在核心中保存網域與位址的對應關係。應用程式連線至這個位址時，核心可以找回原本的網域，再依規則決定出站。這個保留位址不是遠端網站的真實公用位址；看到它不代表網站 DNS 被錯誤修改。了解這點，就能避免將正常的映射結果誤判為解析異常。

相較之下，redir-host 更接近回傳實際解析位址給應用程式的方式，但能否完整關聯網域資訊，仍取決於連線進入核心的路徑與其他識別機制。兩種模式沒有適用所有環境的絕對優劣。有些區域網路服務、依賴真實位址探索的應用程式，或特殊網路偵測機制，可能需要真實位址回應；此時可針對問題調整，不必一律更換所有上游。

過濾、分流與故障排除

過濾項目應針對已確認的問題新增。範例中的區域網路網域後綴只是常見做法，不一定適合每個網路；若路由器使用自己的內部網域，還須讓查詢送到能回覆這些紀錄的本機解析器。只把內部網域加入過濾清單，不會讓公用 DNS 自動認得這些紀錄。排查時應同時確認過濾結果與實際使用的上游。

若要依網域指定上游，可研究 nameserver-policy；若希望 DNS 連線遵循路由規則，可搭配 respect-rules 與節點網域解析設定評估。這些設定改變的是解析流量路徑，不只是查詢結果。啟用前先梳理依賴關係，尤其要避免取得代理連線所需的解析，反過來依賴尚未建立的代理連線。

測試 DNS 時，先區分「沒有回應」、「有回傳位址但連線失敗」以及「只有特定應用程式失敗」。第一種情況檢查監聽、接管與上游可連線性；第二種接著檢查規則、出站與 IPv6；第三種則檢查應用程式快取、內建加密 DNS，或其他繞過系統 DNS 的路徑。變更映射方式後，舊連線與快取可能仍沿用舊結果，應重新建立測試連線再觀察。

頂層的 ipv6 與 dns.ipv6 不應混為一談，兩者分別涉及核心整體的 IPv6 行為，以及 DNS 對 IPv6 回應的處理。關閉其中一項，不代表系統所有 IPv6 流量都已妥善處理。關於保留位址映射與過濾範圍，可繼續閱讀Fake-IP 模式詳解，再依實際網路選擇設定。

04 · 代理節點欄位與提供器

代理節點定義描述核心如何連線至遠端服務，與策略組不同：節點保存協定、伺服器與驗證參數，策略組則負責整理及選擇出站。節點設定即使通過語法測試，也可能因憑證不符、伺服器無法連線或傳輸參數錯誤而無法建立連線。排查時應先確認單一節點可用，再將它加入複雜的策略組，避免選擇邏輯干擾判斷。

名稱、協定與伺服器參數

常見的共用欄位包括 name、type、server 和 port。名稱供群組與規則引用，建議使用唯一且容易辨認的名稱；協定類型必須與伺服器端一致；伺服器可以是位址或網域；連接埠則必須是遠端服務實際監聽的連接埠。本機混合代理連接埠與遠端節點連接埠分屬兩端，不應只因數值不同就硬改成相同。

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

這是欄位格式範例，網域與密碼都是教學用假資料，不能直接用來連線至遠端。實際參數應取自有權使用的伺服器設定。不要因為網頁能正常瀏覽，就推斷代理連接埠也可用；也不要只因某個連接埠常用於 HTTPS，就自行加上 TLS。加密方式、密碼與協定類型必須彼此相符，任一欄位錯誤都可能造成逾時或交握失敗。

支援的欄位範圍由實際核心決定，不是單看用戶端名稱。同一款介面產品在不同版本中，可能具備不同的核心功能；舊設定中的協定也未必與較新的範例相容。遇到未知協定或欄位時，先確認目前執行的核心及其文件，再修改設定。各分支的差異可參考mihomo 與原版功能差異。

TLS、傳輸層與 UDP

使用 TLS 的協定中，伺服器位址、憑證驗證名稱與傳輸層主機欄位可能各有不同用途。servername 通常與 TLS 交握中的名稱有關，WebSocket 的路徑與請求標頭則屬於傳輸層。不要把訂閱中的所有網域都替換成同一個值，也不要只因欄位看起來重複就刪除。應依伺服器端的實際設定逐項核對。

不要把略過憑證驗證當成通用解法。遇到憑證錯誤，應先檢查裝置時間、伺服器名稱、憑證有效性，以及是否連到錯誤的連接埠。關閉驗證會改變安全範圍，也可能暫時掩蓋連到錯誤伺服器或設定不符的問題。只有在了解測試環境與風險時，才應考慮這類設定；日常設定應維持合理的驗證流程。

udp: true 表示允許該節點處理相應的 UDP 請求，不代表伺服器端、協定實作與整條網路路徑都支援 UDP。透過 HTTP 代理連線的一般瀏覽器請求，也不能取代 UDP 測試。語音、遊戲或部分 DNS 請求異常時，應檢查應用程式如何連入核心、節點是否支援所需傳輸方式，以及伺服器防火牆是否放行，而不是只確認開關已啟用。

代理提供器與健康檢查

proxy-providers 可將節點清單從主要設定檔中分離。本機檔案提供器會讀取本機檔案，HTTP 提供器則從指定網址取得內容；主設定檔中的策略組透過 use 引用提供器。這樣更新節點時，不必修改整套規則；但提供器檔案有自己的結構要求，不能把包含模式、規則與 DNS 的完整訂閱直接當成任一提供器格式使用。

proxy-providers:
  local-nodes:
    type: file
    path: ./providers/local-nodes.yaml

proxy-groups:
  - name: PROXY
    type: select
    use:
      - local-nodes

上例依賴實際存在的本機檔案，內容應包含 proxies 清單及有效節點。相對路徑是依核心工作目錄解析，不一定是編輯器目前開啟檔案的目錄。若記錄顯示找不到檔案，先確認用戶端使用的工作目錄與存取權限，再調整路徑；不必因此將所有節點手動複製到主要設定檔，以免掩蓋原本的路徑問題。

健康檢查需要透過所選出站連線至測試網址；它評估的是該路徑到測試目標的表現，不能保證整個網際網路都正常。檢查失敗可能是目標限制、DNS、逾時或節點問題。訂閱網址通常也包含存取憑證，不要將完整連結貼到公開記錄或截圖。分享設定前應保留結構，並替換密碼、訂閱參數及其他可識別資訊。

05 · 策略組、引用與選擇狀態

策略組會將多個出站整理成可供規則引用的名稱。規則將連線交給群組後，群組再依目前選擇或測試邏輯決定實際節點。群組名稱叫 PROXY，不代表一定會經過遠端代理；名為 DIRECT 的一般自訂群組，也不應與內建直連出站混淆。設定時應根據引用關係判斷行為，而非從名稱字面推測。

手動選擇與完整引用

select 是手動選擇群組，適合讓使用者自行決定。群組內的 proxies 可列出既有節點、其他群組與支援的內建出站，use 則用來引用提供器。名稱必須完全一致，請留意空格、大小寫與中文標點。更改節點名稱時，也要同步檢查所有引用位置；否則可能出現檔案語法正確，但核心找不到目標的錯誤。

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - DIRECT

  - name: MEDIA
    type: select
    proxies:
      - PROXY
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,MEDIA
  - MATCH,PROXY

這段設定只使用直連與群組間引用，用來示範結構，不包含真實代理節點。連線至範例網域時會先進入 MEDIA；若 MEDIA 選擇 PROXY，就會繼續使用 PROXY 目前選擇的出站。群組可以建立層級，但必須避免循環。例如甲群組引用乙群組，乙群組又引用甲群組，會破壞出站決策鏈，不能用來實作所謂的雙向備援。

自動測試與故障轉移

url-test 會依測試結果選擇出站，常用於自動選擇；fallback 著重依候選順序尋找可用項目；load-balance 則依支援的策略分配連線。三者不是同義寫法。若需要穩定的優先順序，故障轉移群組通常比不斷追逐測試結果更容易理解；若要手動固定特定服務的出口，可在外層再加入選擇群組。

自動群組通常需要設定測試網址、檢查間隔等參數。使用者應依網路環境選擇網址，並確認回應穩定。測試結果只代表到該目標的路徑，不應當成所有服務的速度排名。有些節點連到測試網站表現良好，卻未必適合長時間連線、影音串流或其他目的地，因此應將自動測試與實際使用體驗一併評估。

檢查間隔也不是越短越好。間隔太短會增加請求次數與裝置喚醒頻率，尤其要考量行動裝置的背景執行限制。部分檢查機制支援依需求測試，長時間未使用的群組未必會持續更新結果。看到舊的測試狀態時，先確認該群組是否實際執行過檢查，再判斷節點是否異常，避免把快取的觀察結果當成即時狀況。

選擇持續保存與業務群組

可依用途建立影音、開發工具或其他群組，再讓不同規則引用。這種分層能將「哪些請求屬於哪一類」與「這類請求使用哪個出口」分開，更新節點時不必重寫所有網域規則。群組不宜拆得太細，否則使用者得維護大量選擇狀態，排查單次連線也要追查多層引用，反而不夠清楚。

profile:
  store-selected: true

保存選擇後，重新啟動或載入設定時可能會恢復先前狀態。節點順序變更不一定會改變目前選擇，但群組名稱變更可能導致舊狀態無法對應。測試新的預設順序時，應同時確認持續保存的記錄，以及用戶端是否另行儲存選擇。不要以為將某個節點移到第一項，就能確保所有已安裝用戶端下次都會使用它。

策略組顯示異常時，建議依序檢查名稱定義、引用來源、候選清單與目前選擇。提供器尚未載入可能導致候選清單不完整，篩選條件過嚴也可能把所有節點都排除。遇到空群組時，先確認提供器更新記錄與篩選運算式，不要立刻將規則目標改成另一個群組，以免只繞過錯誤，沒有解決來源問題。

也要區分「目前選擇存在」與「目前選擇可連線」。手動群組可能保留已失效的節點，自動群組也可能因所有候選項都無法使用而無法正常連線。確認群組結構無誤後，再從單一節點的連線記錄檢查伺服器、協定與 DNS。關於用戶端介面的差異，可搭配選擇指南，挑選適合自己的設定管理方式。

06 · 規則語法、順序與規則集

在規則模式下，連線會依規則清單由上而下比對，通常由第一條符合的規則決定目標出站。規則不會彙整所有符合項目進行投票，也不會因後方有更明確的規則就自動回頭重新選擇。因此，閱讀設定時應先看順序，再確認單條運算式是否正確。若把最寬泛的兜底條件放在最上方，後面大多數規則就會失去作用。

網域、位址與最終兜底

DOMAIN 比對指定網域，DOMAIN-SUFFIX 比對網域及其子網域，DOMAIN-KEYWORD 則依關鍵字判斷。網域後綴規則通常比範圍寬泛的關鍵字更容易控制。網域規則比對的是主機名稱，不是完整網址；不要把通訊協定前綴、路徑或查詢參數填入網域欄位，否則即使網址複製正確，實際上仍可能無法比對。

rules:
  - DOMAIN,router.example.com,DIRECT
  - DOMAIN-SUFFIX,example.com,PROXY
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - MATCH,PROXY

此處的精確網域直連規則位於後綴代理規則之前，因此可作為例外生效。區域網路網段請依實際網路補充；範例並未涵蓋所有位址範圍，也無法取代完整的網路邊界規劃。MATCH 不需要比對內容，用來兜底處理其餘連線；後面的欄位是出站名稱。若該名稱不存在，兜底規則也無法正常決定出站。

位址類規則遇到網域目標時，可能需要先解析才能判斷。no-resolve 用來避免為這條位址規則主動觸發網域解析，但不代表停用所有 DNS，也不保證該連線從未解析過。連線目標已是位址時，仍可依位址比對。除錯時應搭配記錄中的網域與目標位址，確認核心實際取得了哪些資訊。

程序規則與流量進入核心的方式

部分環境支援依程序名稱或路徑比對，但能否取得程序資訊，取決於作業系統、權限與連線接入方式。來自區域網路其他裝置的連線，通常無法像本機連線一樣對應到遠端應用程式的程序。規則未命中時，應先確認程序識別條件是否成立，再檢查名稱；不要不斷增加同義的程序規則，試圖補足原本缺少的中繼資料。

沒有進入核心的連線也無法套用規則。某個程式若忽略系統代理，即使設定精確的程序規則，也可能完全沒有比對機會。先查看連線記錄中是否出現請求；若沒有，檢查應用程式代理設定或 TUN 接管路徑。若有記錄但目標群組不正確，再檢查目前模式、規則順序與網域資訊。這樣才能區分流量入口問題與規則運算式問題。

規則提供器與格式對應

rule-providers 將規則內容放在獨立檔案或遠端資源中，主規則清單則透過 RULE-SET 引用。behavior 描述內容語意，例如網域、位址區段或傳統規則；format 描述檔案格式。兩者都必須符合實際資源。不能只看副檔名，就把一般網頁、完整設定檔與規則清單互相替用。

rule-providers:
  local-domains:
    type: file
    behavior: domain
    format: yaml
    path: ./rules/local-domains.yaml

rules:
  - RULE-SET,local-domains,DIRECT
  - MATCH,PROXY

相應的網域規則檔案可以採用下方結構。檔案內容與主設定檔中的提供器定義，會共同決定能否正確載入；只檢查主檔而不查看資源內容，容易漏掉格式不符的問題。檔案路徑同樣依核心工作目錄解析，首次使用時應先確認資源存在、可讀取且已載入，再測試網域是否命中。

payload:
  - '+.example.com'
  - 'router.example.net'

訂閱更新與規則集更新是兩條獨立流程。節點能更新，不代表規則資源也成功更新；舊快取可能仍在使用。若只有某一類網站分流異常，可先查看相應提供器的載入記錄，再針對特定網域追蹤命中結果。不要用不斷擴大關鍵字範圍來取代資源排錯，以免造成不易察覺的誤比對。

最後驗證時應建立新連線。既有長連線可能繼續使用原本的出站，瀏覽器重複使用連線也會讓規則修改看起來沒有生效。記下一個明確的測試網域，關閉相關舊連線，重新瀏覽後確認命中規則、策略組與最終節點。記錄欄位的閱讀方式請見執行記錄排錯方法。

07 · TUN、路由與接管範圍

TUN 會透過虛擬網路介面，將符合路由條件的流量送進核心，適合處理不遵循系統代理設定的應用程式。TUN 與規則模式屬於不同層次：TUN 負責流量如何進入，規則則決定進入後要從哪裡出去。啟用 TUN 不代表所有請求都要經過遠端代理；規則仍可將區域網路或指定服務交給 DIRECT，也能拒絕特定連線。

基本結構與權限條件

桌面系統通常需要管理員權限、服務模式或相應的網路權限；行動系統則透過平台提供的 VPN 介面接管流量。各平台的用戶端是否提供圖形開關、是否會自動安裝服務，實作方式各不相同。啟用失敗時，應先查看虛擬介面與權限相關記錄；不能只因介面開關顯示為開啟，就認定流量已進入 TUN。

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

這是常見欄位組合，不是適用所有裝置的通用成品。auto-route 用來自動設定相關路由，auto-detect-interface 協助選擇出站介面；同時使用多張網卡、遠端桌面、容器或其他隧道時，自動偵測結果仍可能不如預期。修改路由前應先保留還原方式，尤其不要在唯一的遠端連線上，直接測試尚未驗證的接管方案。

網路協定堆疊、DNS 劫持與實際效果

stack 可依核心支援範圍選擇 system、gvisor 或 mixed 等實作。它們在系統相容性、處理方式與資源消耗上各有差異；mixed 採用混合處理方式，不代表「越新越快」。建議先使用用戶端推薦值，再針對已確認的相容性問題調整，避免同時更動協定堆疊、路由與 DNS 模式，失去比較依據。

dns-hijack 會將符合條件的傳統 DNS 請求導向核心的 DNS 處理機制。範例中的連接埠比對不代表能辨識並重新導向所有加密 DNS；應用程式透過 HTTPS 傳送的查詢，與一般網頁連線使用相同的傳輸入口，不能簡單依傳統 DNS 連接埠處理。瀏覽器內建的解析機制也可能影響網域可見性，測試時應先確認應用程式使用哪條解析路徑。

啟用 TUN 後，仍須確保內建 DNS 正常運作。若接管了查詢卻沒有可用上游，應用程式可能長時間等待解析；若查詢繞過預期路徑，某些網域規則也可能缺少必要資訊。因此，排查順序宜先檢查虛擬介面、路由、DNS、節點與規則，不要只反覆切換 Fake-IP 與真實位址模式。

區域網路、其他隧道與排錯

區域網路存取同時受路由與分流影響。為私有網段設定 DIRECT 規則，只能決定已進入核心的連線要從哪裡出去，不一定能解決所有系統路由衝突。若印表機、共享資料夾或內部管理頁面在啟用 TUN 後失效，應比較啟用前後的路由、目標位址與連線記錄，再考慮適當的路由排除，不要直接放行所有流量。

與企業 VPN 或其他網路隧道同時使用時，預設路由、DNS 與介面優先順序可能互相影響。最有效的基準測試方式，是一次只保留一套流量接管，再分別驗證解析與目標連線；確認各自運作正常後，再研究如何劃分路由。不要排除或接管所有網路介面，這類極端調整很容易讓核心無法建立自己的出站連線。

關閉 TUN 後若網路仍異常，請確認用戶端是否已正常清除介面、路由與系統代理，再檢查其他網路工具是否仍在執行。可先還原用戶端中的相關設定並正常退出，不要直接刪除不熟悉的系統路由。啟用步驟、權限與協定堆疊的進一步說明，請見TUN 模式設定教學。

08 · 覆寫、合併與設定驗證

訂閱設定通常需要定期更新，而本機連接埠、DNS 與個人分流規則則希望長期保留。覆寫機制會在來源設定之外保存這些差異，再由用戶端產生執行設定。這不是 YAML 內建的統一功能；不同用戶端的合併順序、清單處理方式與指令碼功能都可能不同。因此，比起記住某個介面按鈕的名稱，了解最後產生的結果更重要。

分清取代、遞迴合併與附加

覆寫單一純量欄位通常較直覺，例如修改 mixed-port。映射可能採遞迴合併，也可能整份取代；清單的處理方式更容易不同，可能覆蓋原清單、附加到末尾，或透過專用入口插入最前面。不能因為兩份檔案都有 rules，就假設用戶端會自動保留兩邊的所有規則。

# 覆寫片段：具體合併方式由用戶端決定
mixed-port: 7890

dns:
  enable: true
  enhanced-mode: fake-ip

profile:
  store-selected: true

若用戶端會整個取代 dns 區塊，上例可能會移除訂閱原有的上游；若採遞迴合併，則可能保留未出現的子欄位。只看這段文字，無法判定實際結果。儲存後應開啟執行設定，檢查上游、監聽與過濾清單是否完整，再測試解析。若不確定合併方式，先用可還原的測試副本驗證。

規則位置與訂閱更新

個人例外規則通常要放在範圍較廣的規則之前，尤其要排在最終兜底之前。若用戶端只將新規則附加在既有的 MATCH 後面，這些規則雖然出現在檔案中，幾乎不會有比對機會。因此，設定介面中的「前置規則」、「後置規則」與「取代規則」不能混用，必須依照希望改變的優先順序選擇。

直接編輯訂閱原始檔，可能在下次更新時被覆蓋。較穩妥的方式是分層管理節點來源、業務規則與本機環境設定，並使用用戶端明確支援的覆寫或設定組合功能。若用戶端沒有所需機制，可另存為手動設定並接受自行維護的成本；不要一方面依賴自動更新，一方面又認為手動修改永遠不會消失。

節點名稱與策略組名稱變更也是更新風險。若個人規則引用訂閱中的某個群組名稱，更新後該群組改名，即使個人規則本身沒有變更，也會失效。盡可能使用自行維護且名稱穩定的業務群組，再讓它引用可更新的節點來源。更新後應特別檢查所有自訂目標是否仍存在，不要只看用戶端是否顯示訂閱更新成功。

以執行設定建立驗證流程

完整驗證分為四個層次：檔案可解析、引用可解析、外部資源可載入，以及連線行為符合預期。前兩項可透過設定測試確認，第三項查看提供器與節點相關記錄，第四項則需實際發送請求並檢查連線記錄。通過其中一層，不能取代其他層的驗證。尤其是測試命令回報成功，不代表伺服器憑證有效，也不代表規則一定選到預期的出站。

mihomo -t -f ./config.yaml

用戶端產生的執行檔，應盡量使用用戶端實際採用的核心進行測試。獨立安裝的命令列工具可能支援不同欄位，造成本機測試結果與介面不一致。執行檔中也可能包含自動產生的控制位址、介面名稱或快取路徑，不建議不加區分地複製到其他裝置；遷移時應帶上需要的邏輯設定，再依新環境重新產生檔案。

變更記錄與安全分享

每次修改只需記錄三件事：為什麼修改、改了哪個層級，以及如何確認有效。保留可還原的舊設定，比保存大量沒有說明的副本更有價值。遇到問題時，先回復到最近一次可用狀態，再逐項重做變更；若同時升級用戶端與調整規則，應分開驗證，以免將核心差異與設定錯誤混為一談。

尋求協助時，請提供錯誤發生時間、簡化後的相關片段、實際執行模式與重現步驟，並替換訂閱憑證、密碼及管理密鑰。公開截圖也應檢查節點備註、內網位址與存取記錄。若要再次確認安裝、匯入與連線流程，可返回使用指南；若要判斷常見錯誤類型，可前往說明中心，不必每次遇到異常都重寫整份設定。