Clash 設定教學

一、核心概念與連線路徑

區分用戶端、核心與伺服器

先區分這三個層次。Clash Plus、Clash Verge Rev、FlClash 等名稱通常指供使用者操作的用戶端；介面負責匯入設定、顯示策略組、切換開關及管理背景程序。mihomo 是負責處理代理連線、規則比對及網域名稱解析的核心。伺服器位於遠端，負責接收用戶端轉送的連線。安裝介面不代表已取得可用的伺服器，用戶端下載入口也不是訂閱購買入口。

了解一次連線的路徑，比記住所有設定名稱更重要。應用程式會先解析目標或發出連線，再透過系統代理、手動代理或虛擬網卡進入核心；核心讀取目標網域、位址及規則，決定直連、拒絕，或交由某個策略組處理；策略組最後選擇實際出口。網頁無法開啟時，任何一個環節都可能出問題，不能只因用戶端圖示亮起，就認定整條連線正常。

區分訂閱、節點與策略組

訂閱連結是取得設定或節點資料的入口，通常含有存取憑證，應妥善保管，如同密碼。節點描述一條遠端連線，包括伺服器位址、連接埠、協定及驗證參數；策略組則將多個節點或其他群組整合起來，提供手動選擇、故障切換等功能。同一節點可供多個群組使用，但群組名稱不代表實際地理位置，也不保證一定能存取特定網站。

設定檔也可能包含 DNS、監聽連接埠、規則集合及遠端資源網址。有些訂閱只提供節點清單，需要透過用戶端範本或合併機制補上其他內容；另一些則直接提供完整設定。這兩種格式不能混為一談。匯入成功只代表用戶端接受了資源，不代表設定已啟用、核心已載入，也不代表遠端帳號仍在有效期限內。

建立逐層驗證的方法

本機監聽連接埠是應用程式進入核心的入口，不是遠端伺服器的連接埠。以 mixed-port 為例，同一個監聽連接埠可接受 HTTP 與 SOCKS 代理要求。Windows 常見的本機位址是 127.0.0.1，僅代表目前這台裝置。手動設定代理時，應複製用戶端實際顯示的位址與連接埠，不要照抄截圖中的數字，更別把訂閱網址填入代理伺服器欄位。

連線驗證分成四個層次：先確認核心正在執行，再確認流量有進入，接著查看規則選擇，最後判斷出口是否有回應。連線清單完全沒有紀錄時，優先檢查應用程式是否遵循系統代理；有紀錄但顯示拒絕，則查看命中的規則；已使用預期策略卻逾時，再檢查節點、遠端服務及目標網站。依照這個順序排查，可減少反覆重裝，也避免把 DNS 問題誤認為訂閱問題。

也要區分傳輸加密與存取安全。用戶端支援某種協定，不代表設定來源可信；將流量交給遠端出口，也不會自動防止帳號遭釣魚網站竊取。只匯入可信來源的設定；瀏覽器出現憑證異常時，請停止操作，也不要為了解決連線問題安裝來源不明的根憑證。可接著閱讀Clash、mihomo 與 Clash Verge Rev 的關係整理，了解專案沿革與分工。

二、選擇用戶端與裝置架構

先依使用平台縮小範圍

初次選擇用戶端時，先確認裝置平台、處理器架構與所需功能，再比較介面操作習慣。Windows 使用者建議先從 Clash Plus 開始，並在Windows 下載頁面查看安裝需求；若需要參照本手冊中的服務模式、日誌及規則範例，也可選擇 Clash Verge Rev。後續操作會以它常見的介面名稱說明；其他用戶端則請尋找功能相同的設定、代理與選項入口。

Windows 也可選擇 FlClash 或 Clash Nyanpasu。測試時不要同時啟動多個用戶端，否則監聽連接埠、系統代理與虛擬網卡可能互相干擾。切換用戶端前，先關閉舊用戶端的系統代理與 TUN，再完全結束舊程序。保留舊設定備份即可，不必為了比較介面而讓所有程式都在開機時啟動；排除問題時，只保留一個明確的流量入口。

確認處理器架構，別只看作業系統名稱

開啟 Windows 的「設定 → 系統 → 關於」，查看「系統類型」。採用 x64 架構的處理器通常應選擇 x64 或 AMD64 安裝套件；這兩個標示在此指相同架構，並非僅適用於某個處理器品牌。ARM64 裝置應先確認下載頁是否提供相應版本，以及用戶端是否支援目前的 Windows 環境；不要把核心壓縮檔誤當成圖形介面用戶端安裝程式。

macOS 須區分 Apple Silicon 與 Intel；Android 應依裝置架構選擇通用套件或對應架構套件；Linux 則還要考量套件管理方式。能下載套件，不代表一定能安裝在任何系統上。桌面用戶端所需的圖形環境、權限與系統元件，和命令列核心不同。伺服器或路由器使用者才需要進一步研究獨立 mihomo 核心的執行方式與服務管理。

依維護狀態與功能需求選擇

Clash for Windows 與 ClashX Meta 已停止維護，適合查閱舊操作紀錄，不建議新使用者以此為首選。舊用戶端可能缺少新設定欄位、協定功能或系統相容性。匯入失敗時，先確認設定需求，再考慮改用仍在維護的用戶端；不要把刪除錯誤欄位當成通用解法，因為被刪除的內容可能正是訂閱正常運作所需的設定。

不同用戶端即使使用相近的核心，設定儲存方式、增強腳本與服務安裝流程也可能不同。遷移時，優先重新匯入訂閱，再逐項移轉必要規則，不要直接複製整個程式資料夾。尤其不要把某個用戶端產生的執行設定當成長期來源檔案：其中可能包含臨時連接埠、控制介面位址、絕對路徑，以及僅適用於原環境的覆寫欄位。

最後確認日常需求。若主要使用瀏覽器，通常先使用系統代理；若要接管不遵循系統代理的應用程式，再評估 TUN；若要依網域區分出口，則著重規則與策略組管理。功能多不代表初次設定就更合適。先建立最基本的可用連線，再一次新增一項需求並驗證，後續遇到問題時才有明確的回復點。

三、安裝用戶端與初次檢查

安裝前排除衝突入口

前往下載中心，依作業系統與架構選擇安裝套件。請將檔案存放在容易找到的本機資料夾，避免反覆從暫存壓縮資料夾啟動程式。安裝前先結束其他正在執行的代理用戶端，並記下原有代理連接埠及 TUN 狀態。若裝置由組織管理，先確認網路政策是否允許安裝虛擬網卡與背景服務，不要透過修改系統政策繞過管理限制。

執行安裝程式時，請查看系統顯示的發行者資訊與權限要求。需要系統管理員權限的步驟，應與安裝目錄、服務或網路元件有關；若來源、檔案類型或提示與預期不符，請暫停安裝。Windows 安全性提示不一定是誤判，也不應為了安裝用戶端而長期關閉防護。請先重新確認下載來源、裝置架構與系統需求，再決定後續操作。

先檢查核心，再啟用系統代理

初次啟動後，先前往設定頁確認核心是否正在執行、監聽連接埠是否已建立。此時若尚未匯入訂閱，代理頁面可能沒有可選節點，這是正常情況，不必立即重裝。暫時關閉系統代理與 TUN，先完成基本設定及匯入訂閱。若核心啟動失敗，請開啟日誌，找出最早出現的設定解析錯誤、位址衝突或權限錯誤，不要只看最後一則結束提示。

連接埠衝突常見原因是舊用戶端尚未結束，或同一個程式重複啟動。確認是哪個程序占用後再處理，不要隨意結束系統程序。以下用連接埠 7897 示範查詢；實際操作時，請換成設定頁顯示的連接埠。命令列出的程序編號僅供進一步確認程式身分，不表示該程序一定有問題；檢查完畢後，優先透過對應軟體的正常結束方式釋放連接埠。

netstat -ano | findstr ":7897"
tasklist /FI "PID eq 1234"

第二行的 1234 是示範程序編號，執行前請換成第一行查到的實際編號。如果連接埠確實由其他必要程式使用，可以在用戶端設定中改用尚未占用的連接埠，再確認依賴該連接埠的工具也同步更新。不要只修改 Windows 系統代理的連接埠，卻不修改核心監聽設定；兩者不一致時，應用程式就會將要求送往沒有服務監聽的位置。

依需求安裝服務模式

Clash Verge Rev 的服務模式可讓背景服務執行需要相應權限的核心操作，常用於 TUN 情境。開啟「設定」，找到「服務模式」相關選項並執行安裝，再依照系統提示授權；不同介面版本的選項文字可能略有不同。安裝後請檢查服務狀態，再依用戶端指示重新啟動相關元件。服務安裝完成不代表 TUN 已啟用，兩者是不同的狀態。

安全性軟體或組織權限限制可能導致服務安裝失敗。請記下具體錯誤，並在 Windows 的服務管理工具中確認服務是否存在、能否啟動。不要只憑開關顏色判斷安裝成功，也不要反覆執行來源不明的修復命令。若一般系統代理可正常使用，但服務安裝失敗，先保留系統代理方案，再單獨排查服務權限，避免連同可用的網路路徑一起破壞。

安裝檢查的目標是：用戶端可正常開啟、核心日誌沒有持續的啟動失敗、連接埠符合預期，且結束與重新開啟的行為可控。確認連線正常後，再啟用開機自動啟動，並區分「啟動介面」、「啟動背景服務」與「自動還原系統代理」。若想了解設定頁、代理頁與日誌頁，可參考Clash Verge Rev 介面快速導覽。

四、匯入訂閱與套用設定

匯入後明確啟用設定

先向服務提供者取得適用於目前用戶端或 mihomo 的訂閱連結。完整複製網址，避免一併複製聊天軟體附加的標點、空格或換行。開啟用戶端的「設定檔」頁面，在訂閱網址欄位貼上連結並點選「匯入」；有些介面會將此頁稱為「訂閱」。下載完成後，確認新增項目，並明確選取或啟用；清單中出現設定檔卡片，不代表已成功切換。

載入目前使用的設定後，前往「代理」頁查看策略組是否出現。若只看到節點，卻沒有預期的規則與群組，先確認訂閱提供的是節點資源還是完整設定。有些用戶端可透過範本建立群組與規則，另一些則需要匯入完整 YAML。請使用服務提供者指定的入口，不要將訂閱連結提交到不熟悉的線上轉換網站；轉換過程可能會洩露連結中的驗證資訊。

區分下載失敗與解析失敗

訂閱下載失敗時，先確認目前網路能否連上訂閱網域，再查看日誌中的 HTTP 狀態碼與連線錯誤。驗證失敗可能表示連結已過期或帳號狀態有變；連線逾時則可能與 DNS、網路限制或服務提供者故障有關。瀏覽器能開啟某個網頁，不代表用戶端一定能成功取得訂閱，因為兩者的代理路徑、憑證環境及要求方式可能不同。

下載完成但解析失敗時，通常要檢查回傳內容與設定格式。伺服器可能回傳登入頁面、錯誤訊息或不相容欄位，而非預期的 YAML。請查看錯誤涉及的欄位與行號，並向訂閱提供者確認支援範圍。不要將含個人憑證的完整設定貼到公開問答區；求助時，只提供已移除伺服器、驗證參數與訂閱網址的錯誤內容。

區分來源設定、覆寫與執行設定

更新訂閱會重新取得遠端內容。直接修改已下載的檔案，可能在下次更新時被覆蓋；直接修改執行時合成的設定，也可能在切換設定檔或重新啟動核心後消失。長期自訂內容應放在用戶端支援的覆寫、合併或腳本機制中，並了解其執行順序。先儲存一項小幅修改，重新載入核心並檢查最終設定，再確認更新訂閱後修改是否仍保留。

YAML 對縮排與資料型別很敏感。請使用空格縮排，不要混用定位字元；列表項目保留連字號，字串含特殊字元時要正確加上引號。重複出現相同鍵名不代表「追加」，不同解析器可能會報錯，或只保留其中一項。不要直接拼接兩份完整設定；節點、策略組、規則與 DNS 都需要依各自結構合併，並確認所有引用的群組名稱都存在。

自動更新間隔應配合服務提供者的建議，不必設得太頻繁。更新前請保留可還原的設定與本機覆寫；更新後檢查原先選用的節點是否仍存在。節點名稱變更時，舊選項可能失效，導致群組恢復預設選項或出口改變。重要使用情境應再次檢查規則命中與出口，而不只是確認畫面顯示更新成功。

訂閱匯入階段的驗收標準是：目前使用的設定明確、核心成功載入、策略組可見，且至少能選取一個可用出口。若要從本機檔案移轉，請確認檔案來自可信裝置，並保留必要的驗證參數；透過雲端硬碟或聊天工具傳送前，先考量可能的外洩範圍。設定可讀取不代表可公開分享，節點密碼、控制介面金鑰與訂閱連結都不應出現在截圖中。

五、代理模式與連線驗證

區分流量入口與出口選擇

系統代理處理的是「應用程式如何將要求送進核心」；規則、全域與直連模式處理的是「進入核心後如何選擇路徑」。這兩組設定不能互相取代。啟用全域模式不會自動接管所有 Windows 應用程式；啟用系統代理，也不代表所有要求一定會經由遠端節點。先確認目前調整的是入口還是路由，再觀察連線紀錄，才能了解開關實際造成的變化。

日常使用建議先選擇「規則」模式，讓核心依設定規則比對要求。選擇「全域」模式時，進入核心的要求通常會交由全域策略組處理，仍須在該群組中選擇合適出口；若選到直連選項，流量仍可能直接連線。「直連」模式則會讓進入核心的連線直接送出。任何模式都無法補救未進入核心的流量，也不能取代對遠端帳號與節點有效性的檢查。

啟用系統代理並確認應用程式行為

確認設定與節點都已就緒後，在用戶端啟用「系統代理」。前往 Windows「設定 → 網路和網際網路 → Proxy」檢查目前狀態，確認位址與連接埠指向正在執行的本機監聽。用戶端可能透過不同方式管理代理設定，組織政策也可能覆寫此項；發現狀態不一致時，先關閉其他代理軟體，不要在多個地方反覆搶著修改設定。

瀏覽器通常會使用系統代理，但擴充功能、自訂代理設定或管理政策都可能改變行為。關閉既有連線後重新開啟測試頁面，同時觀察用戶端的連線頁。只重新整理頁面可能沿用舊連線或本機快取，不能證明新設定已生效。測試時請選擇能明確辨識的新要求，核對網域、策略鏈與連線狀態，不要只憑網頁右下角的提示判斷。

命令列工具不一定會自動遵循 Windows 系統代理。若要單獨驗證本機 HTTP 入口，可明確指定代理位址。以下使用 7897 示範混合連接埠；執行前請換成目前實際使用的連接埠。這個命令用於觀察目標回應，不保證任何公開網站在所有網路環境下都可連線，也不能證明所有應用程式都已被接管。

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

若收到 HTTP 回應，代表這次要求已完成與目標之間的往返，但仍需在用戶端確認實際使用的策略。若無法連上本機連接埠，先檢查核心與監聽狀態；若本機已收到要求但遠端逾時，請檢查出口；若出現憑證問題，檢查裝置時間與可信任的憑證環境，不要直接加入忽略憑證的參數。依錯誤所在層次處理，比不斷切換節點和重新整理更有效。

正確解讀測速結果與全域排查

節點測速通常會連線至用戶端設定的測試網址，結果受測試目標、網路路徑與協定實作影響。測試成功不代表其他網站都能存取，測試失敗也不一定表示節點完全無法使用。遇到實際問題時，應連線至真正的目標，並查看是否發生網域解析失敗、規則比對錯誤或目標拒絕連線。比較節點時應保持測試條件一致，不要用不同時間的單次數值判斷長期品質。

結束用戶端前，先關閉系統代理，尤其是尚未確認程式是否會自動還原設定時。若程式異常結束後瀏覽器無法連線，請前往 Windows 代理設定，確認是否仍指向已停止的本機連接埠。恢復網路後再重新啟動用戶端；不要為了解決殘留的系統代理，立刻重設所有網卡。若系統代理已能滿足主要需求，可先維持這個方案，下一章再深入設定出口選擇。

六、規則分流與自訂設定

依順序理解規則比對

規則模式通常會由上而下比對，命中後套用對應策略。較明確的規則應放在較寬泛的規則之前，最後的兜底規則 MATCH 則放在末尾。新增規則後，必須確認要求實際帶有規則所需的資訊：網域規則需要可辨識的網域，位址範圍規則用於目標 IP，程序規則則取決於平台權限與核心取得程序資訊的能力；不能只看應用程式名稱，就認定一定會命中。

常見的 DOMAIN 會比對完整網域，DOMAIN-SUFFIX 會比對網域及其子網域，IP-CIDR 則會比對位址範圍。內建策略 DIRECT 代表直連，REJECT 代表拒絕；其他策略名稱通常會引用現有代理群組或節點。名稱必須完全一致，包括大小寫與空格；若引用不存在的群組，可能導致載入失敗或路由結果不如預期。

先建立一條可驗證的小型規則

以下是規則寫法範例，示範讓指定網域、回送位址與區域網路位址直連。這不是完整設定，未包含節點與策略組，也不能直接取代遠端訂閱。若要使用本機規則覆寫，請將需要的項目插入現有規則清單的適當位置，並保留原本末尾的策略。區域網路位址是否都應直連，仍須依裝置所在網路與實際安全範圍判斷。

rules:
  - DOMAIN,example.com,DIRECT
  - IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
  - 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

no-resolve 可避免只為判斷這條位址規則而主動解析網域，不代表關閉整套 DNS。若網域要求已命中前面的網域規則，後續位址規則就不會再參與選擇。排查時先開啟連線詳細資料，查看實際命中的規則，再確認該規則在清單中的位置。不要為了「提高優先順序」就把所有位址規則都移到最前面，這可能改變原有的網域分流結果。

以規則集合管理大量規則

規則數量較多時，可透過 rule-providers 管理遠端或本機集合，再以 RULE-SET 引用。集合的 behavior、格式與內容必須相符；網域清單不能不經轉換，就直接當成完整的傳統規則清單使用。資源取得失敗時，請檢查下載路徑、快取檔案與日誌。用戶端能更新訂閱，不代表每個遠端規則資源也都已成功更新。

選擇規則來源時，應考量維護範圍與更新方式，不要一次匯入大量來源。多個規則集可能重複涵蓋同一目標，最終結果仍取決於引用順序。為工作應用程式、付款頁面或區域網路裝置新增例外時，請記錄原因與驗證日期，避免日後忘記規則用途。來源設定更新後，也要檢查自訂規則是否合併到預期位置。

驗證分流時，應先結束舊連線再發出新要求，因為已建立的連線通常不會在規則修改後立即切換出口。瀏覽器與桌面應用程式可能同時連線多個網域，頁面的主網域規則未必涵蓋圖片、驗證與 API 網域。請先觀察缺少的要求，再補上精確規則，不要用過於寬泛的關鍵字規則，讓大量無關服務一起改道。

最後要將路由與 DNS 分開檢查。規則會決定出口，但網域解析可能在本機、核心或遠端進行；位址規則也可能受解析結果影響。發生解析異常時，不要不斷新增規則來掩蓋問題。先確認 DNS 回應與連線目標，再決定是否調整解析策略。每次都保留一筆能重現問題的連線紀錄，後續設定 TUN 與 Fake-IP 時才有可靠的比較基準。

七、TUN 模式與 DNS 檢查

確認是否需要虛擬網卡接管

TUN 模式透過虛擬網卡與路由接管流量，適合處理不遵循系統代理的應用程式，但接管範圍會受到作業系統、路由、排除設定及用戶端實作影響。它不是「解決所有問題的強化開關」。若瀏覽器正常、只有某個應用程式出錯，請先確認該程式實際使用的網路介面與協定，再判斷是否需要 TUN；若問題出在節點驗證或規則錯誤，切換流量入口也無法修復出口。

啟用前先關閉其他 VPN、虛擬網卡代理或類似的流量接管工具，並記下目前系統代理狀態。在 Clash Verge Rev 中確認服務模式已安裝且正常運作後，再開啟 TUN。初次測試時可暫時關閉系統代理，讓要求來源更明確；若用戶端要求特定設定組合，請依照其說明操作。啟用後，先檢查一般網站、區域網路資源與必要的工作應用程式，不要只測試一個網頁就長期維持開啟。

了解常見 TUN 欄位

以下展示 mihomo 設定中的 TUN 區段，僅用來說明欄位結構，並非可直接執行的完整設定。用戶端可能會透過介面產生同一段內容，建議優先採用一種管理方式，避免介面設定與手動編輯互相覆蓋。欄位支援情況取決於實際使用的核心；載入失敗時請查閱對應文件，不要為了強行啟用而刪除所有報錯欄位，造成接管行為不明。

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

enable 控制是否啟用，stack 用來選擇網路堆疊實作，auto-route 用來自動設定路由，auto-detect-interface 則用來識別輸出介面。dns-hijack 中的範例用於接管相應的一般 DNS 流量；它不會自動涵蓋應用程式透過 HTTPS 或其他加密通道傳送的所有解析要求，也不能取代完整的核心 DNS 設定。

單獨驗證 DNS 路徑

Fake-IP 模式會使用保留位址對應網域，讓核心在後續連線中還原目標網域並參與路由；這些位址不是目標伺服器的實際公網位址。若解析結果落在 Fake-IP 位址範圍內，不要立即判定為 DNS 污染。請結合核心日誌、連線詳細資料與最終回應判斷。若應用程式需要真實位址，或遇到相容性問題，再考慮有針對性地加入 fake-ip-filter。

更換 DNS 模式後，系統與應用程式快取可能仍保留舊結果。可先關閉受影響的應用程式，再視需要清除系統 DNS 快取，並重新建立連線。以下 Windows 命令用於清除系統解析快取，不會清除所有瀏覽器的內部快取，也無法修復遠端服務異常。執行後仍應觀察新要求，不要將命令回報成功視為網路問題已解決。

ipconfig /flushdns

公司網路、校園網路、虛擬機器與多網卡環境尤其要留意路由範圍。預設介面變更、Wi-Fi 與有線網路切換，都可能使自動識別結果不如預期；區域網路印表機、共享資料夾或內部網域也可能需要保留原有路徑。遇到這類問題時，先關閉 TUN 確認是否恢復，再檢查路由與解析；避免直接刪除網卡或執行系統層級的網路重設。

Windows UWP 應用程式另有回送連線限制。使用本機系統代理時，應用程式可能因沙箱限制而無法存取回送位址，這與一般桌面瀏覽器不同。可依照UWP 回送豁免說明檢查特定應用程式，不要一次修改所有應用程式的權限。更深入的解析流程與相容性範圍，請參閱Fake-IP 與 redir-host 的差異；先了解位址對應方式，再擴充篩選清單。

八、日常維護與故障排除

保存可還原的設定狀態

穩定使用後，將維護項目分成用戶端、核心、訂閱與本機覆寫四類。升級用戶端可能同時變更介面或隨附核心；更新訂閱會變更節點與規則；修改覆寫則會影響最終執行設定。每次只變更一類，並記錄操作前後的狀態。如此一來，發生問題時就能還原到明確的步驟，不必猜測究竟是哪次更新造成連線變化。

備份應涵蓋訂閱入口的安全存放資訊、本機自訂規則、覆寫腳本與必要設定，但不必把所有日誌與暫存快取都當成設定備份。執行設定可能含有敏感憑證與本機路徑，移轉到新裝置後也未必能直接使用。請將備份存放於加密儲存空間或受控位置，並確認同步軟體不會讓其他成員存取檔案；備份本身同樣需要限制存取權限。

依故障層次查看日誌

發生斷線時，先記下發生時間、所在網路、受影響的應用程式與最近一次變更。確認核心仍在執行後，再檢查系統代理或 TUN 是否處於預期狀態。若只有某個網站無法使用，不要立刻重新啟動整部系統；先用其他應用程式或目標交叉測試。若所有應用程式都無法使用，再檢查本機監聽、網路介面、DNS 與服務狀態，逐層縮小問題範圍。

日誌中的設定解析錯誤，應回頭檢查欄位與縮排；本機連接埠綁定失敗，應檢查是否已被占用；網域解析失敗，應檢查 DNS；遠端交握或驗證失敗，則應檢查協定參數與服務提供者狀態。逾時本身不足以說明問題，只能表示某個步驟未在等待時間內完成。請依上下文判斷問題出在訂閱下載、目標連線、規則資源更新還是節點測試階段，避免採用無關的修復方式。

暫時提高日誌詳細程度有助於重現問題，但不要長期保留大量偵錯日誌。詳細輸出可能記錄存取網域、目標位址與策略選擇，分享前請先移除敏感資訊。回報問題時提供系統類型、用戶端名稱、使用的功能、錯誤時間與最小重現步驟即可；不要提供原始訂閱連結、節點驗證資訊或完整控制介面設定。截圖也要檢查網址列、側邊欄與通知內容是否含有個人資訊。

建立可執行的復原順序

若修改規則後發生問題，先撤回最後一組規則並重新載入；若更新訂閱後出錯，先檢查群組選項與新增欄位，再考慮還原先前備份；若啟用 TUN 後出錯，先關閉 TUN 並確認系統代理路徑是否正常；若用戶端異常結束後無法上網，先檢查 Windows 是否仍保留本機代理設定。復原的目標是回到先前已驗證的狀態，不是隨機關閉所有安全功能。

確認運作穩定後，再啟用開機自動啟動。重新啟動裝置並完整驗證一次，確認服務、介面與代理設定的啟動順序符合預期；若系統代理先恢復、核心尚未開始監聽，啟動初期可能會短暫無法連線。也應分別測試從睡眠喚醒與切換網路，因為網路介面及路由可能改變。若問題只在喚醒後出現，保留當時的日誌會比反覆重裝更有幫助。

不要把頻繁切換節點當成日常維護。先確認規則與出口是否正確，再考慮更換可用節點；也不要只因一次測速結果就移除所有選項。需要進一步排除問題時，可依照幫助中心的分類搜尋相關症狀，再附上已移除敏感資訊的錯誤內容。維護的目標是減少不確定的變更，讓「最後一次可正常使用的狀態」始終能說明並還原。

九、進階設定與學習路線

先讀懂最終執行設定

完成前八章後，進階設定的第一步不是增加更多欄位，而是讀懂用戶端提交給核心的最終設定。對照來源訂閱、本機覆寫與執行結果，找出監聽連接埠、代理群組、規則及 DNS 各自的來源。先儲存一項最小變更，觀察它在合成結果中的位置，再驗證實際行為。若無法說明某個欄位由誰產生，就先不要讓它負責關鍵業務。

第二步是了解策略組的運作方式。手動選擇群組適合明確指定出口；自動測試或故障切換群組則會依測試條件決定選項。測試網址、間隔、容差與惰性檢測都會影響結果，不能把群組名稱中的「自動」解讀為適合所有業務。先在一種非關鍵流量上驗證，再決定是否擴大使用範圍；保留一個可手動切換的選項組，有助於排查自動策略造成的變化。

接著拆解資源與解析策略

第三步再研究 proxy-providers 與 rule-providers。前者管理代理資源，後者管理規則資源，兩者的引用關係與更新機制不同。拆分資源能減少重複設定，但也增加路徑、快取與遠端下載的相依項目。請檢查每項資源失敗時的行為，並確認首次啟動、沒有快取時是否仍可完成載入；不要只在本機已有快取的情況下判斷方案可靠。

第四步是深入了解 DNS。整理系統、瀏覽器、核心與遠端分別在哪個階段解析，並確認應用程式是否自帶加密 DNS。接著學習依網域選擇解析器、直連網域解析與代理伺服器位址解析等設定。不同欄位可能彼此相依，錯誤組合可能造成解析循環：例如取得代理伺服器位址需要先連上代理，但連線前又必須先解析該位址。

遇到循環解析時，優先回到已驗證的解析路徑，再逐項新增策略。不要隨意將許多公開解析器位址混成一長串，數量多不代表相容性好。內部網域通常需要組織提供的解析環境，公共解析服務不一定知道其記錄。規則出口、DNS 選擇與區域網路存取應一併驗證，避免網頁可以開啟，工作資源卻在不知情下失效。

最後評估介面、腳本與區域網路分享

控制介面供用戶端或管理工具與核心互動使用，不是一般應用程式的代理連接埠。設定 external-controller 時，請先限制為僅本機可存取，了解驗證方式與監聽範圍後，再考慮擴大使用。不要為了方便管理而直接暴露到公網，也不要將控制介面連接埠當成 HTTP 代理連接埠填入瀏覽器。任何可修改設定的介面，都應視為管理入口，而非一般網頁。

區域網路分享還涉及 allow-lan、繫結位址與 Windows 防火牆。只啟用一個開關不保證其他裝置就能使用，也可能意外擴大存取範圍。需要分享時，先限制可信任網路、來源裝置與連接埠，再用另一台裝置測試。公共 Wi-Fi、訪客網路與組織網路都不適合任意開放監聽；測試結束後請恢復最小暴露範圍，避免留下忘記關閉的入口。

增強腳本與設定覆寫適合用來減少重複工作，但腳本屬於可執行邏輯，應先審查來源與修改範圍。確認腳本只調整目標欄位，不會意外刪除策略組、改寫 DNS 或擴大控制介面的監聽範圍。更換訂閱後要再次驗證，因為腳本可能依賴特定群組名稱；即使群組名稱變更後腳本仍能執行，也不代表產生的結果正確。請保留一份不含腳本的基準設定供比較。

最後建立完整的學習循環：透過入門指南複習最短連線流程，用本手冊理解運作方式，透過日誌與連線頁驗證假設，再將長期需要的調整寫入易於維護的覆寫。一般桌面使用者不必立刻改用獨立核心部署；只有確實需要伺服器、路由器或自動化管理時，再學習服務管理、檔案權限與網路範圍。設定越複雜，越應保留簡單、已驗證且可還原的連線路徑。