Shadowrocket 設定選項參考

ENTRY 01 / SCOPE & BASELINE

設定範圍與修改基準

Settings、Config 與伺服器參數

Settings 是應用程式層級選項的入口，通常涵蓋測試、記錄、自動連線與介面輔助功能；Config 用來管理設定檔及其中的規則與相關參數；Home 中的伺服器編輯頁則儲存個別連線項目的位址、連接埠與協定欄位。三者都會影響請求處理，但作用範圍不同。預設狀態請以目前 App 顯示為準。建議先判斷問題屬於哪一層，再前往相應位置調整，不要只因名稱相似就同時修改。

全域行為與單一伺服器的設定也要分開看。修改某台伺服器的 TLS 參數，通常無法修復另一台伺服器；修改目前 Config 的規則，則會影響使用該檔案時的請求選擇。訂閱更新可能替換訂閱內部分項目欄位，遠端設定更新也可能重新載入檔案內容。操作前記下項目名稱、來源與目前選用的設定檔，避免把「剛剛改過」誤認為「目前正在使用」。

先記錄 Global Routing

Global Routing 決定整體的流量處理方式。Config 依目前設定檔處理請求；Proxy 讓請求經由代理路徑處理；Direct 則採直連。具體例外仍應參考 App 說明與實際記錄。日常使用建議選用已驗證的 Config；暫時切換至 Proxy 或 Direct 僅供比對，測試後請恢復原設定，避免將排查用的臨時狀態留作長期設定。

建立可重複驗證的基準

基準是一組修改前的條件，不是某個速度數字。至少記錄目前使用 Wi-Fi 或行動網路、Home 選用的伺服器、Global Routing、目前 Config、DNS 原設定與 On Demand 狀態。接著選擇一個允許存取且容易重複請求的目標，記下問題發生在解析、建立連線或載入內容哪個階段。前後比較時，建議使用相同目標與相同網路，避免同時更換網路、伺服器及規則後無法判斷原因。

每次只修改一個變數。先複製要編輯的設定檔，或在自己可控的位置記錄原值；完成一次修改後重新建立連線，並對同一目標送出請求。部分設定不會立即影響既有連線，舊頁面也可能顯示快取結果，因此驗證時請發出新請求。若狀況沒有改善，先還原原值再檢查下一項；連續疊加多項未經驗證的修改，容易讓原本可復原的小問題變成難以追查的複合問題。

系統權限與商店資訊

首次建立連線時，系統可能會要求允許新增 VPN 設定。這是系統管理網路設定的授權步驟，不是驗證伺服器帳號。若尚未允許，請先依系統提示完成授權，再排查協定問題。系統需求請以 App Store 頁面標示為準。本文主要說明 iPhone 與 iPad 的操作；其他 Apple 裝置的相容性與通用購買適用性，也請查閱商店資訊，不要直接將一台裝置的選項配置套用到另一台。

核對 App 時，請確認官方圖示、開發者 Shadow Launch Technology Limited 與 App ID 932747118。購買 App 只取得使用用戶端的資格，連線所需的訂閱或伺服器資訊仍須由使用者自行準備。若尚未完成安裝與首次連線，請回到教學依序操作。本頁的選項調整以基本設定可辨識、來源可確認為前提，不能取代帳號與參數核對。

ENTRY 02 / NAME RESOLUTION

DNS 設定與解析路徑

DNS 的用途

DNS 用來將網域名稱解析為位址。App 請求網域時，可能會先查詢位址，再據此建立連線；代理路徑也可能由遠端處理部分解析。因此，網頁無法開啟不一定代表 DNS 故障；DNS 成功回傳，也不代表後續連線可用。預設解析設定請以目前 App 與目前 Config 顯示為準。建議先保留可正常運作的解析路徑，再針對明確失敗的目標檢查，不要一遇到問題就先更換 DNS 伺服器。

Settings 中的 DNS 相關選項與 Config 內的 DNS 參數需要一併核對。實際生效的來源可能受目前檔案與功能開關影響，不能只查看其中一處。操作前先確認正在使用的 Config，記錄其中已有的解析項目，再查看 App 內的 DNS 設定說明。若兩處都有設定，請依目前介面說明的作用範圍逐項驗證；不要自行推斷固定優先順序，也不要一次填入多組未確認的位址。

一般 DNS 與加密 DNS

一般 DNS 與加密 DNS 的主要差異在於查詢傳輸方式。DoH 通常以 HTTPS URL 表示解析端點；DoT 通常透過 TLS 連線至解析服務。兩者都需要用戶端先能連上相應端點。加密傳輸不會自動決定出口策略，也不能取代憑證驗證。建議只使用自己了解且目前網路可連線的解析服務，並依輸入欄位要求的格式填寫；一般位址欄與完整 URL 欄不可混用，也不要只因字串看起來相似就互相複製。

若加密解析端點本身使用網域名稱，還要考慮如何取得該端點的位址。基礎解析不可用時，只填入網域形式的端點可能無法建立首次連線。此時請檢查端點是否可連線、系統時間是否正確、目前網路是否需要先完成登入，以及 App 內相應解析路徑是否可用。建議先還原原本可用的 DNS 作為比較，再決定是否繼續排查該端點；不要同時關閉多項驗證來迴避錯誤。

網域規則與位址規則

網域規則可直接依請求中的網域名稱比對；位址規則則依目標位址處理。若需取得位址才能判斷，解析結果可能影響後續選擇。以下片段展示 Config 的常見寫法，不是 DNS 服務位址，也不應貼入 DNS 輸入欄位。範例中的 example.com 僅供說明；GEOIP 的結果取決於 App 使用的資料。閱讀記錄時，請分清「解析出什麼」與「規則選擇什麼」是兩個不同問題。

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

用於位址規則時，no-resolve 可避免只為比對該規則而主動執行網域解析；但不代表整個請求過程都不會使用 DNS。建議只有在了解比對目的時才加入。若預期直連的網域進入代理路徑，請檢查排在前面的規則與最終策略，而不是立即判定為解析錯誤；若回傳位址與預期不同，再配合快取、網路切換與實際解析服務進行排查。

驗證與還原順序

驗證 DNS 時，先在相同網路下重複請求同一網域，觀察失敗是否穩定，再查看 Log 中可用的解析或連線資訊。若已取得位址但建立連線逾時，接著檢查路由與伺服器；若解析本身逾時，則優先確認解析服務是否可連線及填寫格式是否正確。若只有某個 App 發生問題，也要考慮該 App 自己的快取或解析方式；單一 App 的結果不能代表所有系統請求。

修改 DNS 後，依 App 提供的方式重新建立連線；若需要清除快取，只使用目前介面明確提供的功能。接著重新請求目標並比較記錄。還原原值後問題消失，才能說明該修改與現象有關；若仍然失敗，請繼續檢查目前網路、Config 與協定欄位。建議保留一組已驗證的基準，避免每次網路變動都新增 DNS 項目，最後無法判斷哪些設定仍有必要。

ENTRY 03 / AUTOMATION

On Demand 按需連線

連線觸發與選擇策略

On Demand 是依條件要求系統建立或處理 VPN 連線的機制，不是另一種分流規則。它決定何時連線，Config 則決定連線後如何處理請求。預設開關與現有條件請以目前 App 顯示為準。建議先確認手動連線穩定，再啟用最少量的按需條件；若手動連線尚未成功，自動觸發只會反覆失敗，無法補上伺服器缺少的參數。

設定前先定義希望達到的結果：在特定 Wi-Fi 下連線、使用行動網路時連線，或只在特定網域條件下觸發。不同條件可能對應連線、略過或其他系統行為，實際可選動作請以介面顯示為準。不要將「不觸發新連線」直接理解為「立即中斷現有連線」，也不要把手動關閉後短暫中斷誤認為規則已停用；下次網路變動時仍可能再次觸發。

Wi-Fi 與 SSID 條件

SSID 是無線網路名稱，不是路由器管理位址。填寫時請依介面要求保留實際名稱中的大小寫、空格與符號，避免多複製換行字元。建議先新增一個可在現場驗證的網路條件，連上該網路時檢查系統 VPN 狀態，離開後再觀察變化。同一個 SSID 可能由家中多個基地台使用，名稱相同不代表網路環境相同，也不能當作存取服務的可信憑證。

若設定了排除特定 Wi-Fi 的條件，也要檢查是否另有涵蓋範圍更廣的 Wi-Fi 條件。條件排列、比對範圍與動作都可能影響結果，請依目前編輯頁顯示的順序與說明判斷。若遇到「仍連線至排除的網路」情況，先確認是否有既存連線，再檢查其他條件是否符合，最後確認系統設定是否已儲存；不要只刪除一項條件，就認定所有自動連線都已停止。

行動網路切換與網域觸發

行動網路條件適用於裝置使用行動網路時的按需行為，與特定 SSID 條件並不相同。測試時請確認裝置確實已離開 Wi-Fi，並檢查 App 是否取得使用行動數據的系統權限。建議分別測試「建立新連線」與「既有連線切換網路」兩種情況，因為後者可能需要重建工作階段。網路切換時短暫中斷不一定代表規則錯誤，需配合觸發時間與連線記錄判斷。

網域條件用於判斷是否依特定網域觸發，不代表該網域的所有請求都必然採用某一代理策略。系統快取、既有連線與 App 的請求方式都可能影響觀察結果。填寫時請遵循目前輸入欄位支援的網域格式，不要任意將完整網頁網址與路徑當成網域條件。建議使用一個自己可以存取且能重複請求的網域進行測試；連線建立後，還要另外確認 Config 是否採用預期策略。

自動重新連線與暫停排查

若手動關閉後又自動連線，先檢查 On Demand 及其條件，再確認系統中對應的 VPN 設定狀態。排查時建議暫時關閉 App 內的按需功能並確認已儲存，再手動中斷連線，觀察是否仍會重新連線。不要同時反覆刪除系統設定、重新匯入訂閱與修改規則；這些操作會破壞觸發前後的比較條件，讓「系統重新觸發」與「使用者重新安裝設定」混在一起。

恢復自動連線前，先清除測試時留下的重複條件，逐項確認用途，並在 Wi-Fi、行動網路及鎖定螢幕後重新使用等情境中驗證。背景執行的預期應以系統實際允許的方式為準，不要把單次測試結果視為持續運作的保證。更多情境說明請參閱On Demand 依 Wi-Fi、行動網路與網域觸發說明；若日常只需手動連線，也可以保留已驗證的手動流程。

ENTRY 04 / CONNECTIVITY TEST

Ping 與 Connectivity Test

測試結果的適用範圍

Ping 與 Connectivity Test 用來觀察特定探測方式下的連線可達性或耗時，不能保證完整的實際服務請求一定成功。測試可能針對伺服器入口，也可能透過指定路徑存取測試目標，具體含義取決於目前選用的測試方式。預設方式、目標與逾時值請以目前 App 顯示為準。建議先閱讀測試項目說明，確認測試的是哪一段路徑，再比較數值；不同測試方法的結果不能放在一起排序。

入口可連線只代表當時探測到的位址與連接埠有回應。協定驗證、TLS 協商、遠端解析與目標服務仍可能失敗。反過來，某些探測方式沒有收到回應，也不一定表示一般請求無法完成，因為伺服器可能限制特定探測。建議將測試結果視為縮小排查範圍的線索，再對自己可存取的目標發出新請求確認；不要把單次成功狀態或逾時視為定論。

測試目標與逾時時間

測試目標應選擇自己可以存取、回應穩定且用途明確的位址。若 App 要求完整 URL，請依該格式填寫；若只需要主機或連接埠，就不要貼上整段網頁網址。目標重新導向、要求登入或限制請求頻率，都可能使結果與實際使用狀況不同。建議先確認目標本身可用，再用來比較不同伺服器；不要在所有項目都逾時時逐一修改協定密碼。

逾時值設定的是等待結果的上限，不會直接提升網路效能。時間太短可能把較慢但可用的連線判定為失敗；時間太長則會讓批次測試等候更久。建議先保留原值，確認網路較慢且請求最終能完成後，再謹慎調整。變更逾時值後請記錄新設定，並比較同一項目多次測試的結果；若只是為了得到「成功」而一再延長等待，就失去發現異常的意義。

比較時維持條件一致

至少要使用相同網路、測試方式、測試目標與大致相近的測試時間，才能進行橫向比較。Wi-Fi 與行動網路的結果，以及前景操作與網路切換過程中的結果，不適合直接混在一起比較。建議先測試目前實際準備使用的伺服器，再與其他既有項目比對；批次測試會同時送出請求，結果可能受瞬間壅塞與裝置狀態影響。不要因一次排序變動就持續自動切換，反而增加連線重建次數。

耗時較短不代表傳輸量較大，也不代表 App 使用體驗一定更好。小型請求較接近建立連線或收到回應的某個階段；大型檔案傳輸、影片緩衝與長時間工作階段則會受到不同因素影響。評估日常可用性時，應一併觀察實際請求能否完成、失敗是否反覆發生，以及網路切換後能否恢復。建議適度重複測試以排除偶發值，而非高頻探測來追求固定不變的數字。

依失敗階段定位

若所有既有項目在同一時間都失敗，優先檢查本機網路、測試目標、系統時間，以及目前是否需要先登入網路。若只有某個項目失敗，再檢查該項目是否已過期、位址能否解析、連接埠是否正確，以及協定欄位是否完整。測試成功但瀏覽器仍無法使用時，請繼續檢查目前的 Global Routing、Config、DNS 與目標本身，不要反覆執行相同測試，期待實際服務自動恢復。

協定欄位應依據使用者自己的伺服器資訊核對。Shadowsocks 的加密方式與密碼、VMess 或 VLESS 的識別欄位、Trojan 的驗證與 TLS 資訊，以及 WireGuard 的金鑰與位址範圍，各有不同用途；不能因介面中都有「連接埠」就互相套用。若測試結果無法直接證明某個欄位是否正確，就不要根據延遲高低猜測設定值。建議逐欄與原始資訊比對，並保留可還原的原始記錄。

完成調整後，先停止不必要的批次測試，再重新連線並存取實際目標，避免探測流量干擾觀察。若問題仍在，記錄測試方式、失敗時段、網路類型與已去除敏感資訊的錯誤類別。可依連線逾時排查順序繼續定位；提供資料時不必附上完整訂閱連結、驗證資訊或整份設定檔，只要能說明失敗階段即可。

ENTRY 05 / OBSERVABILITY

Log 與 Data 診斷記錄

Log 與流量統計的用途

Log 用來查看 App 記錄的連線事件、錯誤與請求處理線索；Data 則用來查看 App 提供的流量統計。兩者都不是完整的網路稽核，也不能取代目標服務的回應結果。預設記錄狀態、保留範圍與統計週期請以目前 App 顯示為準。建議在重現問題前先查看相關選項說明，只開啟目前需要的診斷範圍，並記下開始觀察的時間，避免在大量歷史記錄中搜尋無關事件。

解讀統計數值前，先確認統計範圍。頁面可能顯示目前工作階段、某台伺服器或累計資料，不能把不同範圍的數字相加後當成電信帳單用量。重新啟動、重設、切換項目及同步也可能改變顯示基準。建議在一次可控請求前後查看同一個統計頁，確認計算方式；若要核對裝置整體用量，應另行參考系統提供的統計，不要用 App 內單一計數推算所有網路活動。

透過一次重現建立時間軸

有效的問題重現應盡可能簡短。先確認目前網路、伺服器、Global Routing 與 Config，再開啟診斷頁面並記下時間，接著只執行一項失敗操作。回到 Log 後，優先查看相近時間的事件，依解析、連線、協商與回應階段理解記錄。若同時開啟多個 App、更新訂閱並執行批次測試，記錄中會混入大量無關請求，難以判斷哪個錯誤真正對應剛才的狀況。

閱讀錯誤時應保留前後文。連線逾時表示某個階段未能在等待期限內完成，不代表遠端永久無法使用；連線遭拒時通常應檢查目標連接埠與服務狀態；遇到憑證錯誤，應核對時間、網域與 TLS 參數，而非直接關閉驗證。不同協定與請求的錯誤文字可能不同，建議根據目前記錄中的原文定位，不要假定本頁的錯誤類別一定會逐字出現在介面上。

從記錄確認規則選擇

若目前介面提供相應資訊，可查看請求網域、目標位址、命中規則與採用策略。若某個請求使用了非預期路徑，先確認它是否確實使用目前的 Config，再檢查前面的規則是否已命中。若記錄只顯示位址而沒有網域，不要自行推定網域規則一定參與判斷；請求可能已由 App 解析，或使用不同連線方式，應依可見資訊謹慎判斷。

記錄中的敏感資訊

Log、訂閱位址與設定檔可能包含存取網域、伺服器位址、使用者識別資訊與驗證資料。匯出或截圖前，請先在自己可控的位置檢查並去除敏感資訊，尤其留意 URL 查詢參數及包含憑證的整行文字。建議只保留錯誤附近必要的片段，隱去可識別帳號的內容。去除敏感資訊後仍須保留事件順序與錯誤類型，否則雖然隱藏了資訊，也可能失去排查依據。

診斷完成後，依目前 App 提供的功能關閉臨時增加的詳細記錄，必要時清除不再需要的本機記錄。長期保留大量歷史內容會增加搜尋負擔，也可能留下額外的存取軌跡。關閉 Log 不代表舊記錄已刪除；清除 Data 也不代表訂閱或伺服器已清除。各項操作的對象不同，請閱讀確認提示後再執行，以免誤刪設定。

最終結論應能對應一條證據鏈：使用什麼網路與項目、執行什麼請求、出現什麼記錄，以及修改後有何變化。若無法建立這種對應關係，建議回到最小可重現情境重新觀察，而不是繼續擴大記錄範圍。涉及系統設定、目前設定檔與請求本身的交叉問題，可搭配 DNS、Config 兩章查閱；若已有明確錯誤類別，也可利用文末的常見排錯問答快速回查。

ENTRY 06 / WIDGET & ICLOUD

Widget、iCloud 同步與設定儲存

Widget 的用途範圍

Widget 是系統提供的 App 資訊顯示或快速操作入口，實際顯示內容與互動功能取決於裝置系統及目前 App 的實作。是否預設新增、顯示哪些項目，請以系統與 App 目前介面為準。建議先在 App 內完成一次正常連線，再新增需要的 Widget；桌面出現元件不代表 VPN 已連線，元件尚未更新也不代表伺服器已中斷。

新增 Widget 時，可透過系統的元件編輯流程找到 Shadowrocket，並選擇目前提供的樣式。若 Settings 中有相關顯示選項，再依用途調整。元件更新會受系統排程影響，App 內狀態與桌面顯示可能不會同步變動。重要操作後建議開啟 Home，確認連線狀態與目前伺服器，特別是在剛切換網路、修改設定或結束測試時；不要只依賴可能尚未更新的快捷顯示。

快速操作與自動連線的關係

Widget 中的操作只是啟動動作的入口，不會改變伺服器驗證與 Config 的基本要求。若尚未完成首次系統授權、所選項目參數不完整，或 On Demand 仍有觸發條件，快速操作的結果可能不如預期。建議先在 App 內排除這些問題，再回到元件驗證。若點擊後狀態反覆變動，應一併檢查 On Demand，不要一直重新新增元件來嘗試修復連線邏輯。

iCloud 同步不等於訂閱更新

iCloud 同步用於同步目前功能明確支援的資料，不代表會向使用者自己的服務商取得最新訂閱，也不保證所有系統授權與暫時狀態都會同步到其他裝置。預設開關與同步項目請以目前 App 說明為準。建議先確認兩台裝置使用的帳號、iCloud 權限與網路狀態，再查看 App 支援同步的具體項目；不要因另一台裝置已安裝 App，就假定所有連線項目都已自動準備完成。

訂閱更新、遠端 Config 更新與 iCloud 同步是不同操作。訂閱更新可能變更訂閱中的伺服器清單；設定更新可能替換規則內容；同步則可能將已儲存的資料傳送至另一台裝置。若遇到「修改後又恢復原狀」，應先確認是哪一類操作發生，而不是把所有變化都歸因於同步故障。建議記錄各項目的來源，並避免在多台裝置上同時編輯同一項目，尤其不要一邊更新遠端內容、一邊覆寫本機副本。

同步衝突與刪除同步

同步衝突是指不同裝置上的同一筆資料有不同修改，實際保留方式應以目前 App 的行為為準，不能假定最新看到的內容一定是唯一正確版本。處理前，先在自己可控的位置保存兩台裝置上仍有價值的設定，決定要保留哪一份，再逐項合併或重新匯入。若不清楚同步方向，不要反覆切換功能或連續刪除項目來強制更新；刪除操作本身也可能同步到其他裝置。

儲存副本時，應區分伺服器資訊、訂閱來源與 Config 檔案，不要將三者混成無法辨識的匯出檔。檔名可標示用途與個人修改說明，但不要寫入密碼或完整訂閱位址。建議將含驗證資訊的資料存放在自己可控的位置，匯入後檢查項目數量與重要欄位是否完整；備份成功的標準是能夠還原並完成驗證，而不是只看到檔案已建立。

換機後的驗證順序

換機時，先從 App Store 取得 Shadowrocket；已購 App 的重新下載與購買適用性請參閱換機與重新安裝說明。接著核對同步或匯入的資料，再完成裝置所需的系統授權。VPN 權限、Widget 版面與目前網路環境不能直接視為另一台裝置的複本。建議先手動連線至一台已確認參數完整的伺服器，成功後再恢復 On Demand 與輔助顯示設定。

最後確認兩台裝置是否都在使用預期的 Config，並檢查訂閱更新後本機修改是否仍然存在。重要規則的調整建議保留修改原因，方便更新後重新核對。若只有一台裝置發生問題，優先比較該裝置的權限、網路與目前選取項目，不要立即刪除另一台裝置上仍可使用的設定。依照「取得 App、還原資料、手動驗證、恢復自動化」的順序處理，較容易保留可用基準。

ENTRY 07 / PROXY & PROTOCOL

Proxy 連接埠與伺服器協定參數

本機連接埠與遠端連接埠

Proxy 相關連接埠首先要分清方向：本機監聽連接埠供明確設定使用該入口的請求連線；伺服器連接埠則是使用者自己的遠端服務入口。兩者不是同一個數值，也不能互相替代。預設連接埠、監聽範圍與功能狀態請以目前 App 顯示為準。若沒有明確用途，建議保留原值；只有確實需要本機代理入口，且了解請求如何連至該入口時，再修改相關設定。

修改本機連接埠時，應檢查輸入範圍與目前功能是否啟用，避免與其他監聽服務衝突。連接埠變更後，明確指定舊連接埠的請求不會自動改用新值，需一併更新其連線設定。若介面提供允許其他裝置存取之類的選項，也應確認監聽範圍與所在網路的存取條件。建議只開放確有需要的範圍；允許存取不是提升速度的開關，App 移至背景後也不代表入口必定持續可用。

協定欄位不可交叉套用

編輯遠端伺服器時，應依據使用者已有的完整參數。Shadowsocks 通常涉及加密方式與密碼；VMess、VLESS 涉及相應的識別欄位與傳輸設定；Trojan 通常需要驗證與 TLS 相關資訊；Hysteria2、WireGuard 則各有不同的驗證、金鑰與位址欄位。建議先確認協定類型，再核對目前介面顯示的必填欄位，不要把某個協定的密碼填入另一個協定的識別欄位來嘗試。

透過 Subscribe 匯入的項目也可能有欄位缺漏、格式不符或資訊已變更的情況。匯入成功只表示 App 能辨識並儲存某種內容，不代表遠端驗證已通過。若手動修改訂閱中的項目，也要留意下次更新可能會覆寫變更。建議先保存要比對的原始資訊，並在確認自己有權使用該設定的前提下逐欄核對；不要隨意更換協定類型來試探伺服器。

TLS、SNI 與系統時間

TLS 用於建立受憑證驗證保護的加密連線；SNI 通常在交握時用來指定對應的伺服器名稱。位址、憑證網域與 App 中的相關欄位可能不完全相同，填寫方式應依據使用者自己的伺服器資訊。建議保留憑證驗證，並核對網域拼寫、裝置時間與必要的中介設定。發生憑證錯誤時，不應填入無關網域或關閉驗證來掩蓋問題，否則會改變連線驗證的前提。

傳輸層欄位同樣必須精確。路徑可能區分大小寫；Host 可能與連線位址扮演不同角色；多餘空格也可能造成請求不相符。建議編輯前先複製原值作為比對，修改後重新建立連線，觀察錯誤是否從入口連線階段進展到協定協商或回應階段。若錯誤完全相同且沒有更明確的證據，請還原原值；反覆修改多個欄位只會逐漸失去原始可用資訊。

遠端設定與本機功能的界線

部分功能需要遠端支援，不能只靠本機開關新增。連接埠可連線不代表遠端已啟用所選協定，測試成功也不代表所有傳輸方式都可用。WireGuard 的位址範圍與路由用途必須符合既有設定；其他協定的驗證與傳輸設定也需要相互配合。建議將伺服器提供的資訊視為一組互相關聯的參數，而非可任意組合的候選值。

完成核對後，先在不修改規則的情況下驗證單一伺服器，再回到 Config 檢查目標請求採用的策略。若目標仍然失敗，應判斷請求是未經所選伺服器，還是經過伺服器後無法完成回應。本機 Proxy 入口、遠端連線與目標請求是連續但不同的環節，各自都需要證據。若不需要本機監聽功能，就不必為了排查遠端驗證問題而修改本機連接埠。

ENTRY 08 / CONFIG & VERIFICATION

Config 規則、修改驗證與回復

規則順序與最終策略

Config 用來儲存處理請求所需的設定內容，規則依序參與比對，先符合的適用規則會決定相應策略；FINAL 則處理前面規則都未符合的請求。預設規則集以目前選用的檔案為準，建議先了解現有檔案的用途，再新增必要規則。只編輯未選用的檔案，不會讓目前請求立即採用其中內容；驗證前請回到 Config 確認使用的項目，並檢查 Global Routing 是否設為 Config。

規則關鍵字決定比對條件，策略則決定符合後的處理方式。DOMAIN 用於比對完整網域，DOMAIN-SUFFIX 用於比對網域後綴，DOMAIN-KEYWORD 用於比對包含指定關鍵字的網域；IP-CIDR、IP-CIDR6 用於比對位址範圍，GEOIP 則使用地理位址資料。PROXY、DIRECT、REJECT 表示不同策略，不能將關鍵字與策略的位置互換。建議優先使用範圍明確的條件，避免過於寬泛的關鍵字誤比對無關請求。

[Rule]
DOMAIN,api.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
IP-CIDR6,fc00::/7,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

在此片段中，api.example.com 會先符合完整網域規則；其餘符合 example.com 後綴的網域則採用後續策略。位址範圍規則表達的是範例中的直連意圖，不保證所有網路都使用相同的本機位址配置。此片段僅供理解語法與順序，不是適用於所有人的完整設定。建議將需要的規則逐條加入已備份的檔案進行測試，不要直接用這幾行覆蓋原有內容。

遠端更新與自訂修改

遠端 Config 更新可能載入新的規則內容，本機修改是否保留，需依目前 App 的儲存與更新方式確認。建議將原始遠端檔案與個人測試副本分開，並在修改紀錄中註明「新增原因」及「驗證目標」。訂閱中的伺服器清單與 Config 的規則來源也應分別記錄；更新前者不等於更新後者。若內容有變動，先確認實際更新的是哪個項目，避免將伺服器名稱變更誤認為規則順序變動。

若請求未符合預期規則，請依序核對：是否採用 Config 模式、目前檔案是否正確、前面是否有範圍更廣的規則、實際請求是否仍使用原網域，以及最終策略是否已先行套用。部分 App 的請求可能只有位址，或經重新導向後改用另一個網域，因此最初看到的網域不一定涵蓋整個請求過程。建議依 Log 中可見的資訊確認比對對象，再決定要新增網域規則或位址規則。

完成一次完整的驗證流程

一次完整的修改應包含修改前基準、單項變更、重新建立連線、對同一目標發出請求，以及記錄結果。成功與否不在於開關是否維持開啟，而在於目標是否透過預期路徑完成操作，且其他必要請求未受影響。建議先在相同網路下驗證，再檢查另一種常用網路情境。若同時使用 On Demand，也要確認自動連線觸發後仍採用預期 Config，而不只驗證手動連線時的狀態。

還原時只需恢復剛才修改的項目，不必立即重設整個 App。規則錯誤就先還原檔案，DNS 錯誤就先還原解析設定，協定錯誤則先還原相應的伺服器欄位。只有在無法辨識目前狀態且已保存重要資料時，才考慮大範圍重建。還原後也要重複相同請求，確認基準已恢復；若還原後仍然失敗，表示網路或遠端狀態可能已改變，需依目前條件重新建立基準。

常見問題與排錯

若尚未完成首次匯入，請回到快速入門教學依照主要流程操作；若要確認規則範圍與 FINAL 的位置，可繼續閱讀自訂規則與最終策略說明。本頁的使用方式是依失敗階段查閱對應章節，保留原值、少量修改並根據記錄驗證，而非一次啟用所有設定。