Official Manual › Settings Reference

Shadowrocket
Settings 設定項目參考

依設定作用範圍、連線路徑與驗證結果查閱。先確認目前設定值，再一次調整一個變數；若無法確認通用預設值，請以應用程式目前顯示為準。

  • 設定說明
  • 核對預設值
  • 設定建議
  • 規則疑難排解

本頁是 Shadowrocket 官方手冊的系統設定查閱篇。若尚未完成首次連線，請先閱讀教學中的快速入門流程，完成既有伺服器或訂閱的匯入、選擇伺服器及連線驗證，再回到本頁查找特定選項。若已能連線，但遇到解析、自動連線、測試或同步問題，可直接依目錄前往相關章節。

本文假設使用者已有自己的訂閱或伺服器資訊。用戶端一次買斷 ≠ 線路方案；本站不提供、不銷售、不推薦節點或訂閱。此應用程式為閉源商業軟體，唯一取得管道為 App Store；購買、相容性與系統需求請參閱正版核驗與下載說明，系統需求以 App Store 頁面標示為準。

Settings、Home、Config 等入口名稱保留英文。部分選項會依目前設定、裝置與應用程式狀態而異；本頁建議僅供疑難排解參考，並非適用所有環境的固定參數。操作前請先儲存目前使用的 Config，並記錄 Global Routing、選取的伺服器及相關開關，以免將原有行為誤認為修改後的結果。

Home › Global Routing

Global Routing 與設定生效範圍

Global Routing 決定連線採用哪種整體處理方式，是查閱 Settings 前應先確認的項目。介面中的 Config、Proxy、Direct 分別代表依設定檔、代理、直連三種模式。它們與頂端的連線開關並非同一回事：開關表示用戶端是否正在連線，Global Routing 則表示連線後如何處理流量。系統顯示 VPN 狀態，也不能單憑此判定特定目標正透過所選伺服器連線。

區分整體模式與個別規則

Config 會依目前啟用設定檔中的規則決定策略，適合需要依目標區分連線路徑的情況。Proxy 以代理方式處理為主，可用來驗證既有伺服器是否能連線至指定目標。Direct 以直連為主，適合用於比對測試。實際保留行為仍須依目前設定檔與應用程式說明確認，不應只憑模式名稱推論所有系統流量都會以相同方式處理。

介面選項說明建議用途
Config依目前設定檔規則選擇策略日常分流與規則命中檢查
Proxy以代理方式處理為主排除規則因素，檢查伺服器連線路徑
Direct以直連方式處理為主比對本地網路與目標可達性

切換至 Proxy 後恢復連線，只能表示整體路徑變更與結果有關，不能立即判定某條規則有誤。還需確認是否同時更換伺服器、沿用舊連線，或未重新解析網域。反之，Direct 下能開啟目標，也不能證明代理參數正確。有效的對照測試應固定目標、網路與伺服器，每次只切換一種模式，並建立新的連線。

確認 Settings、Config 與伺服器設定的範圍

同一現象可能涉及三個層級：Settings 中的應用程式層級選項、Config 中的規則與解析設定，以及伺服器編輯頁中的協定參數。某個設定值出現在一處，不代表它一定會覆蓋其他位置的同名設定。先確認目前實際啟用的 Config，再查看是否包含相關項目；匯入檔案後，原有的應用程式層級選項是否仍生效，應透過實際行為與 Log 驗證，而非僅憑檔案存在與否判斷。

核對預設值也應分層進行。首次安裝時顯示的值、還原資料後的值，以及匯入設定檔後的值，可能各不相同。本手冊對於無法可靠確認通用設定值的項目，均採用「以目前應用程式顯示為準」。建議記錄設定名稱、所在入口、修改前的值與預期影響，例如「只比較解析方式，不更換伺服器」。這比儲存一張缺少情境的局部畫面更容易還原設定。

建立可重複測試的基準

開始排查時，先選擇一部已知正常、由自己維護的伺服器，確認 Home 中的選取標記，再記錄 Global Routing 與目前的 Config。暫停自動訂閱更新及可能觸發重新連線的條件，測試期間保持環境穩定；完成後再恢復原有設定。測試目標可選用自己能確認狀態的頁面，不要混合比較不同網站的連線結果。

每一輪測試都記下操作順序：中斷連線、修改一項設定、重新連線、建立新請求、查看相關記錄。若結果不如預期，先還原上一個狀態並重測，確認問題是否能重現。瀏覽器快取、持續下載與背景長連線都可能沿用舊結果，因此重新整理頁面不一定代表重新建立完整連線。必要時關閉該目標頁面後再開啟，但不必為了一次失敗清除所有應用程式資料。

Settings › DNS

DNS：解析方式與連線路徑

DNS 會將網域名稱轉換為可用於連線的位址。若遇到「網域無法開啟，但直接使用位址時結果不同」，應檢查解析狀況，但不宜因此立即修改所有 DNS 選項。解析請求是否成功、回傳位址是否適用目前網路，以及後續連線採用哪種策略，是三個不同問題。網域解析成功只代表取得回覆，不表示目標連接埠、TLS 交握或頁面內容已能正常存取。

系統 DNS、自訂 DNS 與加密解析

系統 DNS 沿用目前系統與網路提供的解析方式，適合先作為基準。自訂 DNS 會指定其他解析目標，方便控制解析來源，但該目標必須能在目前環境中連線。DNS over HTTPS 透過 HTTPS 傳送解析請求，因此更依賴解析服務位址、憑證與連線路徑。使用此方式不代表後續所有服務流量都會採用相同策略，兩者應分別核對。

建議先使用目前可正常運作的解析方式。若要更換，先記錄既有項目與順序，只替換一個解析來源，重新連線後測試同一個網域。不要同時加入多個來源來「提高成功機率」，因為回傳結果、回應順序與快取都可能讓問題更難重現。若解析入口本身也需要透過網域解析，還須考慮首次連線時能否先取得該入口位址，以免形成相互依賴。

方式需要核對的項目設定建議
系統 DNS目前網路提供的解析是否正常作為初步比對，不視為固定的服務位址
自訂 DNS位址格式、可達性與解析結果使用自己已確認可用的解析目標
DNS over HTTPS完整入口、憑證與存取路徑確有需要時再調整，並保留原值以便還原

檢查設定覆寫、快取與位址類型

Config 可能包含 DNS 相關項目，因此不能只查看 Settings。若修改後完全沒有變化，先檢查已啟用檔案中的相關設定，再確認測試請求是否仍使用快取。不同層級可能各自快取結果，重新開啟網頁不一定會觸發新的解析。觀察 Log 是否出現新的解析記錄，比連續點選重新整理更有參考價值；也不要把一次快取命中誤認為新的解析回覆。

同一個網域可能回傳 IPv4 與 IPv6 位址。若其中一條網路路徑無法連線，可能會等候較久才成功，或只有部分請求失敗。此時應分別查看回傳的位址類型與連線錯誤，而非先認定解析服務有誤。是否啟用相關選項，應依目前網路、伺服器能力與目標狀況決定；預設值以目前應用程式顯示為準。調整後也要檢查原本可存取的目標是否受到影響。

依失敗階段決定下一步

若沒有取得解析回覆，優先核對解析入口格式、網路可達性與設定生效位置。若已取得位址但連線逾時，應檢查路由策略與伺服器。若已建立連線卻出現憑證錯誤，應核對存取網域、裝置時間及伺服器相關參數，不要透過反覆更換 DNS 來掩蓋憑證問題。若網站回傳服務錯誤頁面，網路連線可能已完成，此時繼續修改解析設定通常沒有幫助。

涉及本機裝置名稱或區域網路服務時，也須考慮名稱解析範圍。公共解析來源未必知道家庭或辦公室網路中的內部名稱；將所有解析都交給同一個外部入口，可能改變原本可用的本機存取方式。請保留原始設定，並以一個本機目標和一個一般網域進行成對測試。調整目標是讓解析符合實際需求，而非讓設定中出現更多協定名稱。

Settings › On Demand

On Demand：觸發條件與自動連線

On Demand 可依據已設定的條件觸發連線。它不是伺服器自動修復功能，也不是訂閱更新功能；條件符合只代表系統可以依相關設定嘗試連線，是否能完成仍取決於目前伺服器、設定與網路。手動關閉連線後又自行恢復時，應先檢查此處是否仍有生效條件，而非認定頂端開關故障或應用程式狀態顯示錯誤。

先確認自動化需求

設定前先釐清目標，例如只想在特定類型的網路中觸發，還是希望網路切換後維持連線。接著查看目前應用程式實際提供的條件類型與比對方式，不要直接套用其他介面的欄位名稱。若要依無線網路名稱區分環境，應逐字核對名稱，留意空格與相似字元；同名網路可能出現在不同地點，僅憑名稱無法確認網路身分。

預設開關與初始條件以目前應用程式顯示為準。尚在排查首次連線問題的使用者，建議先暫停 On Demand，手動確認單一伺服器可正常運作，再新增自動條件。否則連線失敗與條件反覆觸發可能交錯發生，Log 中也會出現多筆相似記錄，很難判斷哪次手動操作對應哪個結果。恢復自動化時，每次只新增一項有明確目的的條件。

系統授權與網路切換

首次建立連線時，系統可能會要求允許新增 VPN 設定；請核對應用程式名稱，並依系統提示完成操作。已授權不代表所有自動條件都已啟用；啟用條件也不代表系統授權一定完整。若應用程式顯示已開啟，但系統無法建立連線，應分別檢查授權狀態與連線錯誤。系統需求與裝置相容性以 App Store 頁面標示為準，不應依過往裝置經驗推測目前狀態。

在 Wi-Fi 與行動網路之間切換會改變可達路徑，也可能中斷現有連線。測試 On Demand 時，先固定網路並觀察條件是否觸發，再明確切換一次網路，記錄切換前後的狀態。不要同時更換伺服器與 Config，否則即使連線恢復，也無法證明自動條件設定正確。若網路需要透過網頁登入確認，請先完成網路本身的連線程序，再驗證代理連線。

狀況優先核對下一步
關閉後再次連線是否仍有自動觸發條件暫停條件後，再次手動中斷連線
切換網路後未連線條件是否符合新網路手動測試新網路中的伺服器可達性
反覆嘗試連線伺服器錯誤與網路連線狀態暫停自動化，單獨重現連線失敗

排查自動與手動行為的差異

若手動連線正常、但自動連線不如預期，應優先檢查觸發條件，而非修改協定參數。確認條件是否已儲存、目前網路是否確實符合條件、是否有其他條件產生不同動作，並確認系統設定仍然有效。若手動連線也失敗，則先回頭檢查伺服器與解析。區分這兩種情況，能避免為了解決自動觸發問題而重建所有既有資料。

另一種常見情況是應用程式離開前景後，使用者以為已中斷連線，但系統連線其實仍在執行。應用程式是否顯示於前景，與系統網路延伸功能是否運作，是兩種不同狀態。判斷時應一併查看系統連線狀態及重新開啟應用程式後的顯示，不要把背景應用程式列表當成連線開關。若要停止自動連線，先處理生效中的 On Demand 條件，再中斷連線並確認結果，避免條件立即再次觸發。

長期使用前，至少完成三項驗證：條件符合時能否連線、條件不符合時的行為是否符合預期，以及伺服器無法連線時能否辨識錯誤。自動連線應減少重複操作，不應掩蓋故障。若裝置由組織管理，系統設定可能受到管理限制，應依裝置實際提示判斷；不要反覆刪除並新增設定，以取代對條件與授權的檢查。

Settings › Ping · Connectivity Test

Ping 與 Connectivity Test：測試結果的限制

Ping 與 Connectivity Test 可用來觀察連線狀態，但不同測試方式測量的對象並不相同。伺服器位址有回應，不代表代理協定驗證成功；代理可以連線至測試目標，也不代表所有服務目標都可使用。解讀結果前，先確認目前選用的測試方式、測試目標與受測伺服器，再判讀數值或失敗提示，避免把單一結果擴大解讀為整體網路狀況。

區分網路可達性與代理可用性

Ping 相關設定可能會影響伺服器列表採用的測試方式。可選項目與預設值以目前應用程式顯示為準。以網路層回應為基礎的測試，主要反映位址路徑狀況；以連接埠建立連線的測試，主要反映連接埠是否可連線；透過代理存取目標的測試，則還涉及協定、驗證、解析與目標服務。測試涵蓋的層級越多，可能的失敗原因也越多，不能只憑一個失敗標記判斷是哪一層出了問題。

例如，伺服器位址可連線，但密碼或 TLS 名稱不正確時，簡單的可達性測試可能與實際存取結果不同。反過來說，某些網路不會回應特定探測請求，實際服務請求仍可能成功。遇到這種差異時，請保留兩種結果並繼續查看實際連線記錄，不要為了讓列表全部顯示成功而修改伺服器參數。參數應與使用者既有的伺服器資訊一致，測試結果不能取代設定事實。

選擇穩定且明確的測試目標

測試目標應是自己能確認用途與狀態的位址。若設定允許填入 URL，請確認通訊協定、網域與路徑是否完整；目標重新導向、要求登入或暫時限制存取，都可能影響測試結果。不要把經常變動的服務頁面當成唯一標準。更換測試目標時只修改目標，不要同時調整逾時時間與伺服器，才能判斷結果變化的原因。

逾時值過短，可能會將連線建立較慢但正常的路徑判定為失敗；過長則會增加等待時間，讓批次測試更難判讀。預設值以目前應用程式顯示為準，建議先保留現有設定，只有在多次相同條件測試都接近等待上限時才考慮調整。延長逾時時間無法修正錯誤憑證、錯誤連接埠或失效憑證，也無法讓不可達的目標變得可達，因此應先查看錯誤類型。

觀察結果可說明仍須驗證
位址或連接埠可達某一層連線路徑有回應協定、驗證與實際目標
Connectivity Test 成功在本次測試條件下可存取目標服務請求與規則路徑
測試逾時測試未能在等待時間內完成解析、連線、驗證與目標狀態

確保對照測試具有可比性

建議先單獨測試目前選取的伺服器，再以相同目標比較其他既有伺服器。測試時固定網路、Global Routing 與 Config，避免一邊測試一邊重新整理訂閱。批次測試可能同時送出多筆請求，其負載條件與單筆請求不同；應將它用作初步篩選，再單獨重測異常項目，不要只依一次排序結果頻繁更換設定。

首次連線驗證還應包含一次實際存取：確認 Home 中選取的伺服器，開啟連線開關，再存取目標並查看 Log。列表測試可能針對特定項目執行，但實際連線使用的是目前選取的項目，兩者必須一致。更完整的操作流程請參閱首次連線與 Connectivity Test 驗證。若測試成功但頁面無法載入，應優先比較目標與規則，不要立即重設測試設定。

記錄結果時，只需保留測試方式、目標、網路類型、選取的伺服器與錯誤訊息，不必公開完整訂閱內容。短時間內重複測試只能反映該時段的狀況；網路條件變更後應重新驗證。用測試回答具體問題，例如「此連接埠能否建立連線」，比一味追求更低數值更能協助決定後續操作。

Settings › Log · Data

Log 與 Data：依失敗階段讀取記錄

Log 用於還原連線過程，Data 用於查看流量相關資訊；兩者都必須在明確的時間範圍內解讀。統計總量增加只能表示統計範圍內有資料流動，不能證明某個頁面已成功載入。出現某筆連線記錄，也不代表完整請求已完成。排查時應先確認目標與操作時間，再從記錄中尋找對應的解析、策略選擇、連線建立及錯誤階段。

先縮小記錄範圍，再重現問題

記錄開關、詳細程度與保留方式以目前應用程式顯示為準。建議只在重現問題期間保留足以定位問題的記錄，完成後恢復日常設定。記錄越詳細，越容易混入背景應用程式、頁面附帶資源與重複連線；若未先縮小目標範圍，更多內容反而會降低判斷效率。開始前請暫停無關測試與訂閱更新，記下目前狀態，再只執行一次目標操作。

若介面提供清除記錄的功能，先確認已儲存需要保留的資訊，再清除本次觀察範圍。若不清除，也可記下起始位置或操作時間。接著重新建立目標連線，避免瀏覽器沿用舊連線而沒有新的對應記錄。一次重現問題時不要同時瀏覽多個無關頁面，否則很難區分頁面主要請求與其他資源請求，更不能自動將最接近末尾的錯誤歸因於目前目標。

區分解析、連線、驗證與服務回應

解析階段沒有取得結果，應返回檢查 DNS；取得位址後建立連線逾時，應核對網路、連接埠與選用路徑；出現驗證或交握錯誤，應確認伺服器欄位是否與既有資訊一致。TLS 相關錯誤還應核對名稱、憑證條件與裝置時間。若收到目標服務的拒絕訊息或服務回應，通常表示已通過前面部分網路階段，接下來應針對回應本身分析。

排查規則時，重點不是「記錄中出現這個網域」，而是它命中了哪條規則、選用了哪種策略，以及最後嘗試連線至何處。單一頁面通常涉及多個網域，主要網域正常也不能排除其他資源採用不同策略。應先鎖定確實失敗的請求，再查看其命中結果。若記錄未提供足夠欄位，不要猜測缺少的資訊；可透過單條規則比對與重複測試驗證假設。

失敗階段優先核對避免的誤判
解析DNS 來源與入口可達性直接歸因於伺服器密碼
建立連線位址、連接埠、網路與策略只憑逾時就判定規則語法錯誤
驗證或交握協定欄位、TLS 名稱與時間試圖延長逾時時間來修正欄位不一致
服務回應目標服務與實際請求將所有錯誤頁面都視為連線失敗

流量統計與隱私處理

Data 中的統計範圍、累計起點與顯示單位，應依目前介面說明理解。連線期間其他應用程式也可能產生流量，頁面快取也可能使本次新增流量很少，因此不能直接用總量計算特定請求的完整大小。若要比較，先固定觀察時段，只執行一次明確操作，記錄前後變化；若統計已重設或裝置重新連線，應在結論中註明統計範圍已改變。

記錄可能包含目標網域、位址、伺服器名稱及其他足以反映使用情況的資訊。分享前請移除訂閱網址、驗證欄位、個人識別資訊與無關的存取記錄，只保留定位問題所需的最少片段。即使連結看起來只是一般網址，也可能含有存取憑證；不要將完整匯出檔直接公開。範例與說明可用 example.com 取代實際網域，但應保留錯誤類型與欄位結構。

完成排查後，請還原修改項目，或將其儲存為明確的新基準，並關閉不再需要的詳細記錄。若問題仍無法釐清，請整理「預期行為、實際行為、固定條件、唯一修改、對應錯誤」五項資訊，再繼續縮小範圍。這樣可避免重複嘗試，也能保留足夠情境；單獨一句「無法連線」或一張截斷的錯誤畫面，通常不足以判斷應修改哪個設定。

Settings › Widget · iCloud

Widget、iCloud 同步與既有訂閱管理

Widget 提供便利入口或狀態顯示，iCloud 相關選項則用於在支援範圍內儲存或同步應用程式資料；兩者都不等於連線路徑設定。桌面顯示未即時更新，不能單獨證明系統連線異常；另一部裝置出現設定，也不代表該裝置已選取相同伺服器並採用相同的 Global Routing。便利功能應與實際連線狀態分開驗證。

Widget 顯示與實際連線狀態

Widget 的可用形式、顯示欄位與預設行為，以目前系統與應用程式顯示為準。系統會安排元件更新，顯示內容可能與開啟應用程式後的即時狀態不同。若狀態不一致，先進入 Shadowrocket 查看連線開關、選取的伺服器與目前設定，再核對系統連線狀態。不要因元件仍顯示舊內容就連續操作連線，否則可能讓原本清楚的狀態更難追蹤。

新增或調整 Widget 後，先確認它提供的是開啟應用程式入口、狀態顯示，還是實際操作，再依真實功能使用。若未看到相關設定，應先確認裝置系統支援狀況與應用程式內說明，而非尋找同名設定檔欄位取代。涉及系統需求時，以 App Store 頁面標示為準。元件適合減少尋找入口的步驟，不宜作為判斷特定網域是否經過代理的證據。

同步範圍、衝突與還原順序

iCloud 同步的預設開關與涵蓋範圍，以目前應用程式顯示為準。啟用前先確認系統帳號與應用程式的 iCloud 權限，並保留一份目前可用的設定。同步不等於完整備份，不應假設所有伺服器、歷史記錄、系統授權與連線狀態都會一併轉移。請依照應用程式實際提供的同步項目，分別確認設定檔、伺服器列表及相關選項是否已同步。

多部裝置同時編輯同一份內容時，可能難以判斷更新先後。建議先在一部裝置完成修改，等另一部裝置確認收到後再繼續編輯。若發現舊內容重新出現，先暫停重複修改，分別儲存兩邊需要保留的資訊，比較實際差異後再決定保留哪一份。不要立刻清除其中一部裝置的資料來「強制同步」，因為同步可能繼續傳播刪除或覆寫結果。

行為解決的問題不應推定
iCloud 同步在支援範圍內交換應用程式資料系統授權與連線狀態全部一致
訂閱更新重新取得使用者既有訂閱內容另一部裝置已自動啟用相同項目
手動匯入 Config新增或更新設定檔匯入後已成為目前啟用的設定檔

訂閱更新不等於應用程式資料同步

Subscribe 儲存的使用者既有訂閱，須依其更新方式重新取得內容。iCloud 中出現訂閱項目，不代表訂閱網址目前有效，也不表示內容已更新。手動更新、開啟時自動更新與逐項更新的差異，請參閱訂閱更新方式說明。排查期間建議先更新單一項目，再核對內容變化，避免批次操作掩蓋個別項目的錯誤。

更新成功後，應檢查項目數量與選取狀態是否符合預期，而非只看完成提示。原先選取的伺服器可能已被來源內容取代，名稱相似也不代表參數相同。如果列表為空或顯示解析失敗，先保留現有可用內容，再核對網址完整性、來源狀態與回傳內容；詳細步驟請參閱訂閱解析失敗或列表空白的自我檢查清單，不要反覆刪除並重新新增相同網址。

更換裝置並還原時，先取得應用程式並完成系統授權，再核對同步資料與目前選取項目，最後測試實際連線。App Store 已購項目還原與 iCloud 資料同步是不同流程，購買記錄不能證明應用程式內設定已還原。相關購買步驟請參閱已購項目還原說明。還原完成後再設定自動更新與 On Demand，可減少多項背景行為同時發生而造成的誤判。

Settings › Proxy · Add Server

Proxy 連接埠與伺服器參數：區分本機與遠端

Proxy 相關連接埠首先要區分所在位置。Add Server 中的連接埠屬於使用者既有遠端伺服器參數，必須與對應服務一致；若 Settings 提供本機 Proxy 監聽選項，其連接埠則是裝置上的本機入口。兩者用途不同，即使數值相同也不能互相取代。修改前請記錄入口名稱、位址與使用者，先確認「誰要連線至這個連接埠」，再判斷應調整哪一處。

本機監聽位址、連接埠與開放範圍

本機 HTTP 或 SOCKS5 入口是否提供、是否啟用，以及預設連接埠為何，皆以目前應用程式顯示為準，不預設固定數字。若僅供目前裝置上的程式使用，應優先限制在必要範圍內。允許區域網路存取會改變可連線對象的範圍，必須一併考量驗證方式、網路可信度與實際用途；不要為了排查單一網頁故障而開啟額外監聽，增加無關變數。

連接埠遭占用與連接埠設定錯誤是不同問題。監聽無法啟動時，應檢查是否有其他功能占用該連接埠，以及目前選項是否確實生效；遠端連線失敗則應核對伺服器位址、遠端連接埠與網路路徑。將遠端連接埠改成本機監聽值無法修正伺服器端設定。系統網路環境改變後，可存取的本機位址也可能改變，因此不能只依據上一個網路中的位址判斷入口狀態。

協定欄位應與既有資訊相符

在 Add Server 中先確認協定類型，再檢查該協定實際需要的欄位。Shadowsocks 的加密方式與密碼、VMess 或 VLESS 的識別資訊與傳輸設定、Trojan 的密碼與 TLS 相關欄位，各自代表不同用途。介面中出現名稱相似的欄位，不代表可以互換。請依照使用者既有的伺服器資訊逐項填寫，不要藉由隨機更改協定或複製其他項目的參數來嘗試連線。

伺服器位址、TLS 使用的名稱，以及特定傳輸方式中的 Host，可能是不同欄位。位址決定初始連線目標，名稱相關欄位則參與相應交握或請求處理，應依既有伺服器設定核對。遇到憑證錯誤時，不應將關閉驗證列為一般建議；應先檢查名稱是否相符、裝置時間是否正確、設定來源是否完整，再確認伺服器憑證狀態，以免放寬檢查來掩蓋欄位錯誤。

欄位位置說明設定值來源
本機 Proxy 連接埠裝置上的代理連線入口目前應用程式與本機使用需求
Add Server 連接埠遠端服務的連線入口使用者既有的伺服器資訊
TLS 名稱相關欄位交握與名稱比對所需資訊對應伺服器的實際設定
傳輸路徑與 Host特定傳輸方式使用的請求參數該傳輸方式對應的既有參數

依傳輸能力定位問題

若 TCP 請求正常，但另一類請求失敗，應檢查協定、伺服器與網路是否支援該傳輸方式。網頁能開啟，不代表所有 UDP 或即時服務都能使用。WireGuard、Hysteria2 等協定也各有位址、驗證與傳輸需求，必須依實際欄位核對。本節只說明查閱方式，不提供可用於連線的憑證，也不會代為推定伺服器已啟用特定功能。

匯入訂閱可減少手動輸入，但仍須核對解析後的欄位是否符合原始資訊。編輯由訂閱產生的項目之前，先確認後續更新是否會覆寫本機修改；需要測試時，應保留原項目並明確區分測試副本，避免下次更新後誤以為應用程式未儲存設定。手動新增的完整步驟請參閱Add Server 教學，匯入既有訂閱請參閱Subscribe 教學。

有效的驗證順序為位址與連接埠、協定與驗證、TLS 與傳輸欄位，最後才是實際存取目標。每完成一個層級的檢查，都應使用新連線重新測試，並查看 Log 中的失敗階段是否改變。錯誤從逾時變為驗證失敗，表示觀察到的階段已有變化，但尚不能宣告問題已解決。只有參數與既有資訊一致，且實際請求完成後，才適合將該項目作為後續規則排查的基準。

Config › Rule

Config 規則與逐項疑難排解流程

Config 將規則與相關設定整合在一起。匯入檔案、選取並啟用檔案，以及讓新連線使用該檔案，是需要分別確認的步驟。排查前先在 Config 確認實際啟用的項目，再返回 Home 確認 Global Routing 設為 Config。若目前採用 Proxy 或 Direct，整體模式已改變，不能繼續以規則中的預期策略解釋所有存取結果；應先確認條件一致，再檢查個別規則。

規則由上而下比對，先命中者生效

規則順序會影響結果。範圍較廣的規則若排在前面，可能讓後方較精確的規則無法命中。DOMAIN 用於指定網域，DOMAIN-SUFFIX 用於比對網域後綴及其範圍，DOMAIN-KEYWORD 依網域中的關鍵字比對；IP-CIDR 與 IP-CIDR6 用於描述位址區段，GEOIP 依據位址歸屬資料，FINAL 則處理未命中前述規則的連線。選擇規則類型前，應先確認要比對的是網域還是位址。

關鍵字比對對象檢查重點
DOMAIN指定網域網域拼寫與實際請求是否一致
DOMAIN-SUFFIX網域後綴範圍範圍是否過廣，以及前置規則
DOMAIN-KEYWORD網域中的關鍵字是否誤含其他目標
IP-CIDR / IP-CIDR6對應位址區段位址類型、網段與解析結果
GEOIP位址歸屬分類使用的資料與實際位址
FINAL未命中前述規則的連線是否位於規則末尾，以及策略是否正確

使用最小規則片段驗證策略

以下是規則語法範例，並非適用所有環境的完整設定。example.com 是示例網域；PROXY、DIRECT、REJECT 是策略關鍵字，不是伺服器協定。使用前請先複製目前可用的 Config，在副本中調整並保留原始檔案。不要直接用片段覆蓋包含其他必要內容的設定，也不要因範例含有 GEOIP 就認為必須採用該分流方案。

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

逐行閱讀時，先看比對類型，再看比對值，最後看策略。DIRECT 代表直接連線至目標，PROXY 代表交由相應代理路徑處理，REJECT 代表拒絕符合條件的連線。若要測試某個網域的策略，應將範圍明確的測試規則放在可能攔截它的廣泛規則之前，並透過新連線查看命中結果。測試後請恢復原有順序，避免臨時規則長期改變其他存取行為。

GEOIP 與位址區段規則依據目標位址；網域規則則依賴請求中的網域資訊。不同請求形式與解析階段可能影響可用於比對的資訊，因此「同一個網站」不一定每次存取都留下相同記錄。若看到位址規則命中，應搭配 DNS 回傳值解讀；若關鍵字規則誤命中，應縮小至 DOMAIN 或適當的後綴規則，而不是不斷新增範圍廣泛的例外。

將設定修改整理為可驗證的結論

完整排查應從描述問題開始：明確指出失敗目標、目前網路、選取的伺服器、Global Routing 與啟用的 Config。接著判斷故障發生在解析、連線、驗證或規則階段，只修改最有依據的一項設定。重新連線並建立新請求，觀察結果是否穩定改變；若沒有變化，請還原原值並檢查設定是否確實生效，而不是繼續疊加第二項、第三項無關修改。

驗證成功後，還要檢查一個原本正常的目標與一種本機存取情境，確認修復沒有擴大影響範圍。將最後保留的設定與原因記錄在自己的設定說明中，移除測試副本中的敏感資訊，並恢復需要的訂閱更新與 On Demand。日後再次遇到問題時，優先與這份基準比較，而不是重新從所有 Settings 開始嘗試。應用程式更新與訂閱更新也要分開記錄其影響。

常見問題可依本頁章節查找：解析異常看 DNS，自動連線異常看 On Demand，測試與存取結果不一致看 Ping，狀態依據看 Log，資料不一致看同步，交握失敗看伺服器參數，策略不符看規則順序。購買與還原問題請參閱價格與買斷說明及已購項目還原，不要用網路設定操作處理商店購買流程。