Mihomo
新手到進階指南

核心概念：核心、客戶端與連線路徑

Mihomo 是網路代理核心，負責讀取設定、接收連線、比對規則並選擇出站。Clash Meta 是了解其發展背景時常見的名稱。桌面或手機上的圖形化客戶端則負責匯入設定、選擇節點、申請權限及顯示執行狀態。介面能開啟，不代表核心已啟動；核心啟動，也不代表應用程式的流量已進入代理。釐清這兩個層面的差異，是後續排錯的起點。

先分清四種元件

客戶端是操作介面，核心是實際處理網路請求的程式，設定檔是核心執行的依據，代理伺服器則是遠端出站。訂閱通常用來發送節點或完整設定，但它本身不是代理軟體。安裝客戶端不會自動取得可用伺服器；節點能建立連線，也不代表其頻寬、出口地區或協定能力符合目前用途。

一份設定可能同時包含監聽連接埠、DNS、代理節點、策略群組、規則及遠端規則集。策略群組會將多個出站組成可選擇的目標，再由規則引用該目標。介面上的節點選擇只是其中一環：如果請求最後符合直連規則，切換代理群組中的節點也不會改變該請求的路徑。

沿著請求方向理解分流

瀏覽器造訪網域時，必須先取得 IP 位址，再建立連線。請求可以透過系統代理設定進入本機監聽連接埠，也可以由 TUN 虛擬網卡接管。請求進入核心後，規則會依網域、目標位址或其他條件決定使用哪個出站。遠端伺服器是否可連線、目標網站是否有回應，都是這條路徑後段的問題，不能只靠介面上的連線狀態判斷。

系統代理通常只是向支援此設定的應用程式提供代理入口。部分遊戲、命令列程式及自行管理網路的應用程式不會讀取這項設定。TUN 的接管範圍較廣，但會牽涉路由、DNS 和權限。兩種方式各有適用情境，不能簡單認定啟用 TUN 一定比較快，也不必因為系統代理無法使用就重裝客戶端。

認識協定、傳輸方式與設定格式

Shadowsocks、Trojan、VLESS、Hysteria2、TUIC 和 WireGuard 等名稱，代表不同的協定能力。支援清單不代表任意節點都能使用這些協定，還須確認伺服器提供的參數、客戶端使用的核心及其編譯功能。UDP 轉發也需要入口、出站協定與遠端服務共同支援；網頁能開啟，只能證明相關網頁連線可用。

YAML 是結構化文字。相同縮排代表同一層級，冒號後通常要加空格，清單項目使用連字號。縮排應使用空格，不要使用定位字元。中文說明可以寫在註解中，但不可在欄位語法中混用全形冒號或彎引號。編輯後先使用客戶端提供的設定檢查功能，再套用至正在執行的核心。

學習時準備一個穩定的測試頁面、一份已知可用的設定，以及明確的復原方式。記錄目前使用系統代理或 TUN、所選模式及策略群組。遇到問題時，每次只變更一個變數。如需查詢名詞，可先查看術語表，再回到本章的連線路徑，判斷問題出在哪個層面。

選擇與安裝：平台、架構與權限

先在下載中心選擇作業系統，再確認處理器架構。本網站優先推薦 Clash Plus；桌面版也可依使用習慣選擇 Clash Verge Rev 或 FlClash。Windows 另有 Clash Nyanpasu。各客戶端的介面與設定合併方式不盡相同，先選一款完成基本驗證，比同時安裝多款並啟用網路接管更容易管理。

依系統與維護狀態選擇

macOS 可選擇 Clash Plus、Clash Verge Rev 或 FlClash。Android 可選擇 Clash Plus、Clash Meta for Android、FlClash 或 Surfboard；但 Surfboard 使用不同的設定體系，不能預設它可直接匯入 Mihomo YAML。iOS 版 Clash Plus 可從 App Store 安裝，官方網站為 clashplus.io。轉換客戶端時，應先確認訂閱輸出格式，不要只比較副檔名。

Linux 下載區提供 Clash Verge Rev 與 FlClash，安裝前請確認發行版使用的套件格式。Clash for Windows 和 ClashX Meta 已停止維護，屬於封存選項，不適合作為新手的預設選擇。Mihomo 核心套件適合能自行管理設定與程序的使用者；一般桌面使用者建議優先選擇圖形化客戶端。

完成基本安裝

安裝前先退出其他代理或 VPN 程式，並關閉其自動接管選項。桌面安裝套件依照系統流程安裝；可攜版則放在具有寫入權限的固定資料夾，不要一直從壓縮檔內執行。首次開啟後，先找到設定、代理、記錄檔和偏好設定等功能入口，暫時不要啟用開機啟動、區域網路分享或複雜的自動更新工作。

在 Windows 中，使用系統代理與安裝 TUN 服務可能需要不同權限。只有安裝程式或已確認的客戶端明確要求時才授權。在 macOS 中，先確認下載來源，再依系統提示處理應用程式與輔助服務的權限；不要為了解決單一應用程式的啟動問題而關閉整體安全機制。授權後仍須回到客戶端，確認核心是否確實執行。

Android 啟用網路接管時，通常會出現系統 VPN 授權視窗。允許後，系統狀態列可能會顯示 VPN 圖示，但這仍不能證明遠端節點可用。同一系統中的其他 VPN 服務可能會爭用接管位置。先只讓一項服務執行，確認成功後再處理省電排除清單與背景常駐，避免將權限問題和節點問題混為一談。

安裝後驗收與退出

先匯入一份可信的設定並查看核心記錄檔。若出現連接埠占用，確認是否有舊客戶端或殘留程序正在監聽相同連接埠，不要隨意終止不熟悉的系統程序。更換連接埠後，引用該連接埠的應用程式代理設定也必須同步修改。如果記錄顯示語法錯誤，應回到設定檔處理；反覆重裝程式通常無法修復錯誤欄位。

最後測試正常退出：先關閉系統代理或 TUN，再退出客戶端，確認瀏覽器仍可透過原本的網路連線。若退出後整體網路異常，檢查系統是否仍保留指向本機連接埠的代理設定。完成這個步驟，才算建立可控的安裝環境。系統權限的進一步處理可參閱常見問題，不必立刻安裝第二個客戶端來取代現有環境。

訂閱與設定：匯入、更新及本機覆寫

訂閱網址是分發設定的入口，可能包含帳戶識別資料或存取憑證，應像密碼一樣妥善保存。只向可信的服務提供者取得連結，不要在公開聊天室、截圖或問題回報中公開完整內容。匯入前先確認提供的是完整 Clash 設定、節點清單，還是特定格式；不同內容必須透過客戶端對應的匯入功能處理。

從匯入到實際啟用

開啟設定管理頁面，使用新增遠端設定或匯入訂閱功能，貼上完整網址並儲存。下載完成後，檢查設定名稱、更新時間和解析提示，再將它設為目前使用的設定。部分客戶端會將下載、選取和套用分成不同操作，因此清單中出現檔案，不代表執行中的核心已使用該檔案。

匯入失敗時，先確認錯誤發生在哪個步驟。網路逾時表示請求未能正常完成；驗證失敗可能是連結已失效；回傳網頁可能是網址指向登入頁或說明頁；解析錯誤通常代表內容格式不符。不要將任意網頁連結交給訂閱轉換工具，也不要為了除錯而把私人連結上傳到來源不明的線上工具。

成功啟用後，檢查是否出現可選的策略群組，選擇一個明確的出站，再開啟測試頁面。如果節點清單是空的，確認設定是否透過遠端代理集合載入節點，以及相關資源是否已下載。主設定解析成功與遠端資源下載成功是兩回事，應分別確認錯誤提示和記錄檔。

區分遠端檔案與執行中的設定

圖形化客戶端通常會將遠端訂閱、本機覆寫和介面設定合併成最終設定。訂閱檔寫入某個連接埠，但實際執行時使用不同連接埠，可能是介面選項覆寫的結果。排錯時應查看客戶端提供的執行設定或合併結果，並留意其中可能包含敏感資訊；不要只根據下載檔案推斷目前的運作方式。

需要長期保留的自訂規則，優先放在客戶端支援的覆寫、合併或擴充設定中。直接編輯遠端下載檔案，下一次更新可能會覆蓋修改。不同客戶端的合併規則不完全相同，尤其要確認清單項目是附加還是整份取代。先新增一條容易觀察的測試規則，確認位置與結果正確後，再移植正式規則。

# 規則片段：合併至現有設定的 rules 清單前端
# example.com 是保留作示範用途的網域
rules:
  - DOMAIN-SUFFIX,example.com,DIRECT

這段片段只示範一條規則，不包含節點或完整網路設定。不要用它覆蓋整份訂閱；如果已有 rules，應依客戶端的合併方式新增清單項目，而不是在同一個 YAML 對映中再次寫入同名欄位。是否命中規則，應透過連線詳細資料確認，不能只根據編輯器成功儲存來判斷。

安排更新與備份順序

更新間隔取決於服務提供者的建議和客戶端功能。將間隔設得很短不會讓節點更穩定，反而可能觸發伺服器的頻率限制。可先從每天檢查一次開始，重要操作前手動更新並確認結果。節點訂閱、遠端規則集和客戶端程式各有更新週期，不應把其中一項更新成功視為所有元件都已更新。

更新前保留上一份可用設定，並記錄目前選取的策略群組。有些設定更新會移除或重新命名節點，導致原本的選擇失效。更新後先確認設定能否解析，再測試常用網站和需要 UDP 的應用程式。如果出現異常，先還原舊設定並確認網路恢復，再比對差異，避免同時修改 DNS 和重裝程式。

多部裝置共用同一個連結時，也應確認服務是否限制裝置數量，以及客戶端格式是否相容。設定備份不只包含訂閱網址，也可能包含本機覆寫、策略群組選擇和排程工作。同步方式請參閱多裝置設定同步說明；同步前先釐清哪些內容由遠端管理，哪些只適用於目前裝置。

代理模式：規則、全域與直連的驗證

代理模式決定已進入核心的請求如何選擇出站，但不負責確保請求進入核心。系統代理或 TUN 是入口；規則、全域和直連則是後續的決策方式。先確認應用程式已接入，再切換模式觀察差異。如果請求從未出現在連線清單中，改變模式通常無法解決入口以外的問題。

三種模式各自改變什麼

規則模式會依照設定中的規則順序決定處理方式，適合將不同目標交由不同策略處理。全域模式通常會將進入核心的請求交給全域策略群組，適合暫時縮小排錯範圍。直連模式則讓進入核心的請求直接連線至目標。直連不等於退出客戶端；TUN 和本機監聽仍可能保持運作，DNS 行為也不能只靠模式名稱判斷。

剛開始使用時，先在規則模式下選擇一個明確的節點，不要立刻依賴自動測速群組選路。如果頁面無法開啟，可暫時切換到全域模式，並確認全域群組確實選用了該節點。全域模式可連線、規則模式卻不行時，優先檢查規則命中和策略群組引用；兩種模式都失敗時，再檢查節點、DNS 與本機網路。

將系統代理設定與模式分開確認

啟用系統代理後，先使用遵循系統設定的瀏覽器測試。瀏覽器擴充功能、自訂代理設定和獨立設定檔可能會覆蓋系統選擇。命令列工具也可能讀取代理環境變數，而非系統代理面板，因此瀏覽器連線成功不代表終端機已接入。每種應用程式都要確認入口，不能只看客戶端的總開關。

如需驗證本機 HTTP 代理，請先確認混合連接埠為 7890，再執行下列命令。若連接埠不同，請改用實際值。此命令只會讓目前請求明確使用代理，不會替其他程式設定全域環境，也不會設定 UDP 接管。目標使用示範網域，回傳結果仍取決於目前網路和所選出站。

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

執行後同步查看連線詳細資料。如果請求有出現，且顯示明確的出站，表示入口鏈路已建立；若連線遭拒，先檢查監聽連接埠與核心執行狀態。如果代理入口可連線但遠端逾時，就繼續檢查出站記錄檔。不要把終端機中的所有錯誤都歸咎於節點失效；憑證、系統時間和網域解析也可能各自出錯。

測試時固定條件

測試時固定應用程式、目標位址和節點，每次只更換模式，並記錄最終出站。瀏覽器快取或已建立的長連線，可能讓舊路徑繼續生效；必要時關閉相關頁面或中斷連線，再重新發出請求。不要在同一次測試中同時切換節點、更換 DNS、啟用 TUN，否則即使恢復連線，也無法判斷是哪項設定生效。

節點延遲測試只是針對特定測試目標的一次測量，不代表所有網站的整體速度。測得延遲值不代表目標服務可用，更不能證明 UDP 轉發成功。大型下載、影片連線和即時遊戲的網路特性不同，應使用對應應用程式驗證，並留意伺服器限制、出口策略和本機網路變化。

完成排錯後，恢復規則模式，再確認常用網站是否進入預期的策略群組。需要本機存取的印表機、路由器管理頁面和開發服務，也應列入測試清單。保留明確的關閉步驟：先關閉系統代理或 TUN，再退出程式。建立可重複的測試流程，能作為下一章調整規則的基準；不能只憑網頁偶爾開啟，就判定設定正確。

規則分流：比對順序、策略群組與規則集

在規則模式下，Mihomo 會由上而下檢查規則，由第一條符合的規則決定處理目標。規則數量多不代表分流更準確，順序與範圍才是關鍵。排在前面的寬泛網域規則，可能讓後續的精確規則永遠沒有機會執行。調整前先釐清需求：哪個應用程式要存取哪個目標、希望使用哪種出站，以及要用什麼現象驗證。

從少量、容易觀察的規則開始

DOMAIN 用於比對完整網域，DOMAIN-SUFFIX 用於比對網域後綴及其子網域，DOMAIN-KEYWORD 則依網域中的關鍵字比對。關鍵字規則的範圍容易過大，新手建議優先使用明確的網域或後綴規則。不要把完整網頁網址直接填入網域欄位；規則通常不包含通訊協定、路徑和查詢參數。

位址規則如 IP-CIDR，用於比對目標位址區段。GEOIP 依賴對應資料，比對依據是目標 IP 在資料庫中的歸屬地，而非公司註冊地。MATCH 是預設兜底規則，應放在清單末尾；若放得太前面，後續項目就不會生效。撰寫位址規則時，也要留意是否會觸發網域解析，避免為了比對位址而新增額外 DNS 請求。

# 學習範例：示範精確項目、位址項目與兜底規則的順序
# 此範例全部直連，不提供遠端代理功能
rules:
  - DOMAIN,example.com,DIRECT
  - DOMAIN-SUFFIX,example.org,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,DIRECT

no-resolve 用來避免該位址規則主動觸發網域解析；它不代表關閉整份設定的 DNS，也不保證所有區域網路流量都符合這個位址區段。家庭、辦公室和容器網路使用的網段可能不同，新增前應先查看實際路由。範例末尾使用直連是為了示範語法，不應直接取代需要代理出站的完整設定。

讓規則引用穩定的策略目標

規則最後一個欄位可以是內建動作，也可以是現有策略群組名稱。引用的群組名稱必須與設定完全一致，包括空格和大小寫。通常讓規則指向穩定的策略群組，再到群組中更換節點，比讓許多規則直接綁定單一節點更容易維護。訂閱更新移除節點時，穩定的群組名稱也能減少需要同步修改的位置。

手動選擇群組適合確認出站；自動測試群組則適合在既定候選項目中依測試結果選擇。兩者並非單純的優劣之分。自動群組使用的測試網址、測試間隔和候選範圍都會影響結果；策略群組也可能引用其他群組，因此連線詳細資料中的群組名稱未必就是最終遠端節點。排錯時應繼續追查群組的選擇。

了解遠端規則集的適用範圍

規則集透過 rule-providers 宣告，再由規則中的 RULE-SET 引用。其行為類型必須與檔案內容相符；網域清單、位址清單和傳統規則格式不能任意混用。下載失敗、路徑無法寫入或內容格式錯誤，都可能導致載入失敗；看到規則集名稱，不代表其中的項目已可使用。

大型規則集適合依用途管理，但匯入前應先了解維護來源、更新頻率和涵蓋範圍。先保留少量重要的本機規則，再新增一個遠端集合，檢查記錄檔和命中結果。不要一次疊加多組高度重疊的規則後才開始排錯，否則很難釐清是前面的規則攔截、集合內容變更，還是最終策略群組選錯。

驗證規則時，開啟目標頁面並查看連線中的網域、規則和出站。網頁通常還會要求載入圖片、登入和 API 等多個網域；主要網域命中正確，不代表所有資源的路徑都一致。如果只有部分內容無法載入，應從失敗的請求反查對應網域，不要立刻長期將整個應用程式切換到全域模式。

維護規則時，為本機修改加上簡短註解，說明目標和原因，不要只重述欄位名稱。每次更新設定後，確認自訂規則仍位於預期位置。DNS 相關異常可接著參閱DNS 設定小節；如果核心看不到網域，單靠新增網域規則通常無法解決問題，應先檢查請求入口與解析鏈路。

TUN 接管：路由、DNS 與 UDP 的適用範圍

TUN 透過虛擬網路介面接收流量，再交由核心處理，適合不遵循系統代理設定的應用程式。它改變的是接管方式，不會取代節點、規則或遠端能力。啟用前，先確認系統代理下已有可用設定，並記錄目前的 DNS、其他 VPN 和虛擬網卡狀態。有了這個基準，才能將新出現的問題限定在接管層。

先安裝所需服務，再啟用功能

桌面客戶端可能透過服務模式或輔助程序，取得建立介面與修改路由所需的權限；實際操作位置依客戶端而異。先依介面指示安裝服務，確認狀態正常後再啟用 TUN。Android 通常透過系統 VPN 授權建立接管。不要把所有客戶端都視為使用相同的權限機制，也不要只因開關可以點選，就認定底層介面已建立。

首次啟用時保留預設網路堆疊選項，不要同時加入嚴格路由、複雜排除清單和多個 DNS 上游。先測試一般網頁，再測試原本無法透過系統代理連線的應用程式。如果核心記錄顯示權限不足或介面建立失敗，應先處理服務與系統授權；這時切換節點無法修復虛擬介面問題。

# TUN 設定片段，須合併至現有可用設定
tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  strict-route: false
  dns-hijack:
    - any:53

此片段示範常見欄位，不保證適用於所有系統。客戶端介面可能會覆寫這些設定，套用後應查看實際執行設定。auto-route 用於自動設定相關路由，auto-detect-interface 協助選擇出站介面；多網卡、虛擬機器和特殊撥號環境仍可能需要額外確認。網路堆疊的可用性與實際行為，取決於平台支援。

了解自動路由與嚴格路由

自動路由會讓符合條件的請求進入 TUN，但不代表裝置上的所有連線都一定會被接管。路由優先順序、排除項目、應用程式綁定介面及其他 VPN 都可能影響結果。嚴格路由用於收緊接管範圍，在不同系統上會有相應的路由或限制行為；它不是加速選項，也不應作為所有故障的預設修復方式。

啟用嚴格路由前，先測試區域網路存取、系統網路連線檢查，以及辦公網路所需的連線。如果印表機失聯或企業服務無法存取，先關閉最近新增的路由選項，觀察問題是否消失，再依實際網段設定例外。不要憑經驗排除大量位址區段，否則可能連原本希望接管的流量也一起繞過。

分別驗證 DNS 與 UDP

dns-hijack 會將符合條件的傳統 DNS 請求送入核心的 DNS 處理流程；範例針對連接埠 53 的請求，不會自動解密應用程式自行使用的加密 DNS。瀏覽器的安全 DNS 或應用程式內建解析，可能會走不同路徑。啟用後若出現網域存取異常，應分開檢查 DNS 入口與連線入口，而非只查看 TUN 開關。

應使用實際需要 UDP 的應用程式進行驗證。節點設定允許 UDP，不代表伺服器和中間網路都支援所需的傳輸方式。遊戲無法連線時，應檢查連線是否進入核心、規則是否選到支援相應功能的出站，以及遠端是否有回應。網頁和延遲測試成功不能取代這些驗證，也不能證明即時服務一定穩定。

裝置從睡眠中恢復、切換無線網路或插入有線網卡後，出站介面和預設路由可能改變。如果只有切換網路後才失敗，先重新啟動接管，或依客戶端的方式重建介面，再比對記錄檔。確認 TUN 在常用網路中能穩定啟用和停用後，再考慮開機啟動。路由器與伺服器部署涉及轉發、防火牆和回程路徑，應視為獨立專案處理，不能直接照搬桌面設定片段。

日常維護：更新、記錄檔與故障復原

穩定使用仰賴可追溯的變更，而非頻繁重建環境。至少保留一份可用設定、必要的本機覆寫，以及目前接管方式的記錄。客戶端、核心、訂閱、規則集和地理資料是不同的更新項目，可能由不同入口管理。某個更新按鈕執行成功，不代表所有元件都已變更，更不代表設定行為完全相同。

建立有順序的更新流程

更新客戶端前先閱讀變更說明，確認系統相容性和設定遷移提示。匯出或備份設定後，正常關閉網路接管，再執行安裝。更新後先檢查原設定能否載入、監聽連接埠是否維持一致，再驗證系統代理和 TUN。如果客戶端提供獨立的核心更新功能，請避免在同一輪測試中同時更換程式與核心。

更新訂閱後檢查節點和群組名稱是否變動；更新規則集後，檢查重要目標的命中結果。設定中的遠端資源可能下載成功，但內容不符合預期；也可能因路徑權限問題而繼續使用舊資料。應一併查看記錄檔和更新時間。重要業務開始前，不宜一次升級多個元件；預留驗證與復原時間，比追求同步更新更實際。

依序檢查入口、解析、規則與出站

先確認一般網路可以連線至預期可達的目標，再確認核心程序和本機監聽狀態。接著查看失敗的請求是否出現在連線清單中：完全沒有記錄時，檢查應用程式代理或 TUN；有記錄時，查看網域解析、規則命中和所選出站。最後檢查遠端交握及目標服務回應。依此方向排錯，可避免將系統代理殘留誤判為伺服器故障。

記錄檔中的「連線遭拒」通常表示目標連接埠未接受連線；「逾時」表示未能在期限內完成操作；解析失敗則指向網域處理環節。仍須根據錯誤中的位址、連接埠和發生階段判斷具體原因。憑證錯誤也可能與系統時間或伺服器名稱有關。不要只複製最後一行錯誤，應保留同一時段前後的相關記錄。

排錯時可暫時提高記錄詳細程度，完成後再恢復常用層級，減少持續記錄造成的儲存與隱私負擔。分享記錄檔前，移除訂閱網址、驗證欄位、控制介面憑證及可識別個人身分的資訊。截圖也可能洩漏完整節點位址和帳戶資料；需要說明問題時，優先保留錯誤類型、時間和必要的網路階段。

透過復原確認變更的影響

更新後出現異常時，先還原上一份設定；必要時也還原先前的接管設定。網路恢復後，再逐項比對差異；若還原後仍然失敗，原因可能是本機網路、伺服器或其他外部變化。復原不是最終結論，而是用來判斷問題是否與本次變更有關。比對設定檔的文字差異，比靠記憶尋找欄位更可靠。

手機背景連線中斷時，應區分系統回收程序、網路切換和遠端逾時。如果返回應用程式後立即恢復，才較需要檢查背景限制與省電策略。桌面裝置從睡眠中恢復後失效，則應檢查介面、DNS 和路由是否恢復。測試時記下裝置狀態與發生時間，不要把所有間歇性故障都歸因於同一個參數。

尋求協助時，請說明平台、客戶端名稱、接管方式、失敗目標類型、最近的變更及已完成的測試。不要只說無法上網。可依照已連線但網頁無法開啟的排錯清單補齊資訊，再到常見問題查找相關項目。能重現問題的最小案例，通常比整份私人設定更適合用來交流。

DNS 與進階設定：解析鏈路、控制介面與部署方式

完成前面各章後，再將 DNS 和自動化當作獨立主題學習。DNS 不只是查詢網域的 IP 位址，也會影響規則可取得的資訊、連線目標和網路路徑。調整前先記錄系統 DNS、瀏覽器安全 DNS、客戶端 DNS 及 TUN 劫持設定，釐清請求由誰接收、向誰查詢，避免多層解析彼此繞行。

Fake-IP 與上游解析的分工

fake-ip 模式會向應用程式回傳映射位址，讓核心據此將網域與後續連線關聯起來；這不代表真實目標不存在，也不是遠端伺服器的位址。redir-host 則會向應用程式回傳實際解析結果。兩者在相容性和規則可取得的資訊上有所不同，應依應用程式與接管方式進行驗證，不要將某一種模式視為所有裝置的固定答案。

以下是合併至現有設定的 DNS 片段。迴路監聽用於限制本機監聽範圍；若 TUN 或客戶端使用自己的 DNS 接入機制，應保留所需設定，不要強行覆寫。範例使用的上游仍須能從目前網路連線。先確認解析請求可順利完成，再設定分流與備用策略。

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://1.1.1.1/dns-query
    - https://8.8.8.8/dns-query

nameserver 是一般解析的上游清單，不應將填入多個位址簡單理解為依序切換。使用網域形式的加密 DNS 時，還須考慮解析上游網域所需的引導鏈路。節點伺服器位址若是網域，也必須先解析才能連線；不可讓負責解析節點的請求，反過來依賴尚未建立的節點連線。

fallback 和 fallback-filter 用於設定備用解析及結果篩選條件，不等於任意請求失敗時都會自動換用其他位址。應依實際解析需求設計，不要複製多組上游堆疊。某些區域網路網域或特定應用程式不適合使用映射位址，可進一步了解 fake-ip-filter；但應先確認故障確實由解析模式造成，再新增範圍明確的例外。

切換模式後，應用程式可能仍快取舊位址，瀏覽器也可能維持既有連線。應重新發出請求，並依系統和客戶端提供的方式處理相關快取，避免把舊狀態誤認為新設定的結果。更完整的參數關係請參閱nameserver、fallback 與 DNS 劫持說明；每次只新增一個解析分支。

控制介面與區域網路存取

外部控制介面可以讀取狀態並執行管理操作，預設應限制在本機；設定存取憑證後，再考慮遠端管理。不要將控制連接埠直接公開至網際網路。若要讓其他裝置使用本機代理，也應檢查監聽位址、驗證機制和系統防火牆。允許區域網路存取不只是一個開關，還必須確認哪些來源實際上能夠連線。

設定、記錄檔和備份都可能包含敏感欄位，私人儲存庫也需要適當的存取控制。自動同步前，排除不應共用的裝置設定，避免混用不同裝置的連接埠、路由和權限設定。自動化工作應能回報失敗並保留上一份可用狀態，不能在下載到錯誤網頁時直接覆蓋正在使用的設定。

依用途選擇下一步學習方向

桌面使用者可接著學習策略群組與規則集維護；行動裝置使用者應優先處理網路切換和背景穩定性；伺服器或路由器使用者則可進一步了解服務管理、轉發與防火牆。後者還須確認回程路徑和接管範圍，不能只把桌面設定複製過去就當作完成部署。使用核心命令列前，先查看目前程式的說明，並執行設定檢查。

每個進階目標都應有驗收條件：能從連線詳細資料解釋規則，能說明 DNS 解析鏈路，TUN 可穩定啟用與停用，更新後也能還原舊設定。達成這些條件後，再新增自動選路或遠端管理。需要重新建立基本流程時，返回快速入門教學；需要更換客戶端時，前往下載中心，讓學習路線與實際操作保持一致。