設定範圍與預設狀態
先辨別設定所屬層級，再判斷應在哪裡修改。Settings 是應用程式的設定入口，但一次連線也會受到 Home 中的伺服器選擇、Global Routing 模式、Config 中的規則及系統網路環境共同影響。只看到某個開關已開啟，並不能證明請求已按預期處理。查閱時應一併記錄目前伺服器、目前設定檔及連線狀態，避免把不同層級的問題歸咎於同一項設定。
應用程式設定、設定檔與伺服器參數
應用程式設定通常管理測試方式、顯示、記錄及系統整合等行為；Config 儲存規則及相關網路設定；伺服器項目則包含協定、位址、連接埠及驗證參數。同一個「連接埠」出現在不同位置時，意義可能完全不同：Add Server 中的 Port 指向遠端服務，本機 Proxy 監聽連接埠則是裝置上的服務入口。修改前先確認所在頁面，不要只因中文說明相似就互相填入。
匯入自己已有的訂閱，主要是取得伺服器項目及其更新來源，不應直接推斷目前的規則檔也會一併更換。更新應用程式、重新匯入設定及切換伺服器也是不同操作。若某個值在更新後改變，應先確認更新的是哪一類項目，再追查它是否被匯入內容覆蓋。盲目重複匯入可能使原有項目與新項目混在一起，反而更難找出問題。
| 位置或項目 | 主要作用 | 驗證依據 |
|---|---|---|
| Settings | 應用程式行為、測試與系統整合 | 對應功能的實際表現 |
| Config | 規則及設定檔中的網路設定 | 目前啟用的檔案與請求記錄 |
| Add Server | 遠端伺服器連線參數 | 原始伺服器資訊與連線結果 |
| Global Routing | 選擇設定、代理或直連模式 | 實際請求的處理路徑 |
預設值並非所有裝置共用的固定答案
本手冊不會把某次裝置顯示的數值視為永久不變的出廠值。初次安裝、從舊裝置移轉，以及匯入設定後的狀態都可能不同；部分選項也會隨系統能力與應用程式實作調整。這裡所說的預設狀態核對，是指修改前查看目前欄位、說明文字及目前設定，並保留可供復原的紀錄。沒有明確需求時，建議保留現值，不必為了符合某份清單而逐項改寫。
記錄時至少寫明選項名稱、修改前後的值，以及修改目的。若欄位為空，不要直接解讀為已關閉或無效；空值可能表示使用系統提供的資訊，也可能表示由設定層處理，實際意義應以該欄位說明為準。若無法確認空值的意義，先保留現狀，再透過受控測試觀察，不要憑猜測填入公共位址或數字，硬把所有空欄補滿。
建立可重複的修改與復原流程
建議先在穩定網路下完成一次基準測試：確認能建立連線、開啟常用頁面，並記錄 Global Routing 與目前的 Config。接著一次只修改一個變數，再用相同頁面及相同網路複測。若同時修改 DNS、伺服器與規則，即使結果改善，也無法判斷是哪一項生效；若結果變差，也難以確認該復原哪一處。逐項修改比反覆重設更有助於診斷。
若變更涉及連線核心參數，且介面提示需要重新連線，請依提示操作；若沒有明確提示，儲存後也可主動中斷再重新連線，避免仍使用舊工作階段。不要因為舊連線還能使用，就認定新值已通過驗證。復原時還原原欄位與原設定，再重複相同測試；若還原後仍失敗，表示還需要檢查網路切換、伺服器狀態或系統層級的變化。
DNS 與網域名稱解析
DNS 的作用是將網域名稱解析為後續連線所需的位址。它與規則判斷有關，但不能取代規則，也無法修復伺服器驗證失敗。排查前先釐清問題發生在哪個階段：網域解析錯誤、已取得位址但連線逾時、連線成功但頁面內容不完整，分別是不同情況。只有第一種直接指向解析流程；後兩種仍須配合路由、傳輸及伺服器回應判斷，不能一概歸為 DNS 問題。
確認解析設定的來源
先查看目前啟用的 Config 是否包含 DNS 相關內容，再查看 Settings 中可用的 DNS 選項及說明。若介面與檔案中都出現相關欄位，不應只憑所在位置就認定其中一方必定覆蓋另一方；應確認該選項屬於全域行為、設定補充，還是某種解析模式的參數。不同欄位可能負責不同階段，名稱都含 DNS 不代表功能重複。修改後應以新請求驗證，而非只確認是否儲存成功。
對於目前仍可正常使用的設定，建議保留現有解析方式。只有在能重現解析失敗、需要使用自有解析服務，或現有設定明確要求特定處理方式時，才調整相關欄位。填入位址前，先確認介面接受的是單一位址、清單，還是含協定的位址格式；不要把瀏覽器中的完整網頁網址當成解析伺服器位址。協定前綴、連接埠與路徑也須符合該欄位支援的格式。
解析服務本身也需要能夠連線。若採用加密傳輸的解析方式，其服務名稱可能仍須先取得位址，憑證驗證也仰賴正確的名稱與系統時間。因此，「改用加密解析」不代表此前所有網路條件都不再重要。若出現循環依賴或連線失敗，應先還原原本的解析方式，確認基本網路恢復，再核對新方案的可連線性與設定意義，不要接連加入更多解析位址。
網域規則與位址規則的差異
DOMAIN 與 DOMAIN-SUFFIX 可直接依據請求中的網域判斷；IP-CIDR、IP-CIDR6、GEOIP 則依據位址條件運作。在需要位址資訊的情況下，解析結果會影響後續判斷；但請求是否保留網域、是否已符合前面的規則，也會影響處理流程。因此排查規則時應由上而下閱讀，先確認符合哪一條，再判斷 DNS 是否參與，不要只盯著清單末端的位址規則。
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXY上述片段只說明規則順序，並非完整的連線設定，也不要求取代現有檔案。example.com 是示範網域；私有位址規則用來展示位址區段比對；FINAL 負責處理前面都未符合的請求。加入自己的設定前，應檢查現有規則、策略名稱及預期路徑。不要因為範例片段能儲存，就認定它適用於所有網路；尤其要留意區域網路資源及原有業務規則是否受到影響。
快取、網路切換與建議驗證順序
修改 DNS 後，瀏覽器、應用程式或既有連線可能仍保留先前的結果。先關閉正在測試的頁面或應用程式工作階段，再視需要重新連線，並以相同網域發出新請求。不要要求解析結果必須固定回傳某個位址：相同服務可能依網路與負載回傳不同位址。診斷重點是解析是否成功、請求路徑是否符合規則，以及連線結果能否穩定重現，而不是位址文字是否與他人相同。
若只有在某個 Wi-Fi 網路下失敗，先確認該網路已完成必要的網頁認證，再檢查區域網路解析與目前 DNS 設定是否衝突。若只有切換網路後短暫失敗，應分辨是快取尚未更新，還是隧道尚未恢復。還原原設定後若問題消失，再逐項核對新增欄位；如果原設定也失敗，就繼續檢查基本網路與目前伺服器，不要在同一處反覆更換解析位址。
On Demand 隨選連線
On Demand 管理的是系統在符合條件時如何觸發或維持連線，不是依網域選擇代理或直連的規則清單。前者回答「何時建立連線」，後者回答「連線建立後如何處理請求」。若將兩者混為一談，就容易設定了網域規則，卻期待系統自動開啟連線；或設定網路條件後，以為所有請求都必定經過某台伺服器。
先確認手動連線，再新增自動條件
首次設定時，建議先保留目前的 On Demand 狀態，透過 Home 手動建立連線，確認既有伺服器資訊、Config 與 Global Routing 都能正常運作。手動連線穩定後，自動觸發才有明確的驗證基礎。若手動連線本身失敗，應先修復基本連線，再設定隨選條件；自動觸發只能啟動相同的連線流程，無法補足失效的驗證參數或無法連線的遠端位址。
查看 On Demand 頁面時，應逐項核對介面提供的網路類型、網路名稱或其他比對條件，並確認儲存後的實際規則。不要假設自己的裝置一定有別人截圖中的所有選項。網路名稱應依實際顯示填寫，相近名稱不代表同一個網路；若有多個條件，先閱讀介面對符合條件與例外狀況的說明，再決定是否組合使用，避免規則涵蓋範圍超出預期。
沒有明確的自動連線需求時，建議維持手動控制；確有需求時，從一個可反覆驗證的條件開始。例如只針對自己常用的某種網路狀態進行測試，觀察進入與離開該狀態時的行為，確認後再增加其他情況。不要一次涵蓋所有網路，否則任何異常都會影響日常連線，也難以判斷是條件比對問題，還是連線建立階段出了問題。
系統授權與網路切換的界線
首次建立連線時，系統可能會要求允許加入 VPN 設定。此授權是讓系統建立相應的網路連線設定，不代表訂閱內容或伺服器參數已通過驗證。授權後仍須進行實際連線測試。若先前拒絕授權，應依系統目前的提示重新允許；不要把反覆切換 On Demand 當成重新取得權限的固定方法，也不要碰運氣刪除其他用途的系統設定。
從 Wi-Fi 切換至行動網路時，舊連線可能中斷，新連線須在新的網路條件下重新建立。此時頁面短暫等待，不必立刻判定隨選規則失效。先確認系統實際網路已切換，再查看 Shadowrocket 的連線狀態，最後發出新請求。若網路仍在認證、訊號不穩，或目前伺服器在新網路上無法連線，即使自動觸發成功，也無法保證目標請求立即完成。
系統允許的背景行為與前景應用程式行為並不完全相同。不能因為「離開應用程式後畫面不再即時更新」就認定隧道一定中斷，也不能因狀態圖示仍顯示就認定所有請求都成功。驗證時應結合目前連線狀態與實際存取結果。若還有其他系統網路管理設定參與連線，應先釐清各自用途，避免不了解影響範圍就同時調整多組自動連線條件。
停止連線、復原與異常排查
啟用隨選連線後，手動中斷又重新連線，可能是系統再次符合觸發條件，不一定是按鈕沒有作用。若要持續停止，先檢查 On Demand 是否仍要求連線，再依目前介面停用相關觸發規則，最後中斷連線。操作後等待狀態穩定，再發出一般請求確認；不要快速連續切換開關，否則建立與中斷流程可能交錯，難以判斷最終狀態。
排查可依固定順序進行：先暫時停用隨選條件並驗證手動連線，再只恢復一項條件，觀察是否觸發；觸發成功後，再核對請求路徑。若完全沒有觸發，檢查條件與系統授權；若能觸發但無法存取，檢查伺服器、DNS 與規則；若頻繁重新連線，記錄發生時的網路類型與切換過程，而不是先擴大自動比對範圍。
Ping 與 Connectivity Test
測試數值只能反映某種測試方式在特定時間的結果，不能直接代表所有服務都可用。Settings 中與 Ping 相關的選項用來調整測試行為；Home 中的 Connectivity Test 則用來執行相應檢查。查看結果前，先確認測試方式、測試目標，以及是否透過所選伺服器進行。不同方式涵蓋的網路階段不同，混在一起比較，所得排序往往沒有實際意義。
不同測試方式各自能證明什麼
若介面提供 TCP 測試，主要檢查能否與指定位址及連接埠建立連線。連接埠可連線，不代表協定驗證、加密交涉及目標存取都已完成。若提供 HTTP 測試，還須確認目標位址及請求是否經由代理路徑；取得回應通常涵蓋更多環節，但仍只代表該目標與該次請求。測試名稱相近，也不能省略對路徑與條件的核對。
發生逾時時，先判斷逾時是在測試目標，還是在連線至伺服器的階段。遠端伺服器可能可連線，但測試目標暫時沒有回應；目標也可能正常，然而目前網路無法連到伺服器。不要把一次失敗直接等同於伺服器永久失效。先用相同方式重複測試，再核對基本網路與測試目標，並比對一次實際請求，才能區分偶發現象與持續故障。
| 觀察結果 | 可以說明 | 不能單獨證明 |
|---|---|---|
| 連接埠連線成功 | 該次傳輸層連線可以建立 | 協定驗證與頁面存取都成功 |
| 測試目標有回應 | 該次測試路徑取得回應 | 所有目標與所有協定都可用 |
| 測試逾時 | 在規定時間內未完成該次測試 | 故障必定發生在伺服器端 |
如何選擇目標、逾時時間與重複次數
測試位址建議保留目前可驗證的設定，或使用自己能穩定存取且用途明確的目標。不要為了讓數值看起來更小而不斷更換目標，這樣會失去前後比較的基準。若測試目標使用網域，解析也可能成為整個測試的一部分；若頁面發生重新導向或要求認證，最終行為也可能與預想的簡單回應不同。應先確認該目標適合目前的測試方式。
逾時時間沒有適用所有網路的單一最佳數值。設定過短，可能把延遲較高但仍可用的連線判定為失敗；設定過長，則會延後發現明顯無法使用的路徑。首次排查建議保留目前值，先在穩定網路中觀察，再依實際失敗情況調整。若請求經常接近逾時門檻，應先檢查網路與伺服器，而不是只靠延長逾時來掩蓋持續性問題。
重複測試時應維持相同間隔與條件，避免在裝置大量上傳、下載或切換網路時進行排序。短時間內密集測試多個項目也可能增加並行負載，使結果偏離日常使用情況。較有意義的做法是挑選少數既有項目，在相同網路下重複觀察，並以實際服務是否穩定作為補充。一次較小的數值，不足以成為長期優先選擇的理由。
測試通過但實際存取失敗
先核對實際請求使用的 Global Routing。測試某台伺服器，不代表目前的服務請求一定使用它；在 Config 模式下，請求可能符合 DIRECT，也可能交由其他策略處理。接著查看 Config 中與目標相關的規則，再檢查網域解析與請求記錄。若只切換伺服器而未確認符合哪條規則，可能一直在比較一個根本未參與該請求的項目。
協定參數也可能造成「基本測試正常、應用程式請求失敗」的差異。例如涉及 TLS 的連線，還需要正確的服務名稱與憑證驗證；涉及 UDP 的服務，不能只憑一次 TCP 連線結果判斷。應依原始資訊核對既有伺服器參數，不要為了讓測試通過而任意關閉驗證。Trojan 欄位的具體說明請參閱Password、SNI 與 Allow Insecure 填寫說明。
還原測試設定時，應將目標、方式與逾時時間一併還原為記錄值，再重新測試同一項目。若還原後結果仍有變化，表示網路狀態或遠端回應也在變動，不能把所有差異都歸因於剛才的設定。最後保留簡短紀錄：網路類型、測試方式、是否成功及實際請求結果。這類紀錄比一張缺少條件說明的數值截圖更有助於後續排查。
Log 與 Data 診斷
Log 用來查看事件與錯誤，Data 用來查看流量統計，兩者應相互補充，不能彼此取代。統計數值增加，只能表示有資料依照該統計方式經過，不能保證某個頁面完整載入；記錄顯示連線已建立，也不能保證後續服務回應成功。診斷前先提出明確問題，例如「這個網域是否符合直連規則」，再收集相關記錄，避免沒有目的地長時間啟用詳細記錄。
記錄範圍與建議啟用方式
先在 Settings 查看 Log 相關選項，確認目前是否啟用、記錄詳細程度及可檢視的內容。實際可用項目以介面為準，不要把某台裝置的記錄等級視為所有裝置的預設值。平時建議維持足以基本排查的目前狀態；遇到可重現的問題時，再暫時增加所需記錄。排查完成後恢復原狀，以減少額外記錄量及不必要的本機敏感資訊留存。
重現問題前，先記下目前時間與準備存取的目標，然後只執行一組明確操作，例如開啟一個頁面並等待結果。若記錄量較大，可先依介面支援的方式清除舊記錄，再開始測試；若需要保留證據，應先製作去識別化備份。不要一邊批次測試伺服器，一邊重現單一頁面故障，否則測試請求和實際請求會交錯，難以判斷哪一筆錯誤屬於目標操作。
查看錯誤時，應依發生順序閱讀，而不是只搜尋最後一則失敗訊息。解析失敗可能導致後續連線無法開始；驗證失敗可能發生在傳輸建立之後；遠端關閉也可能是更早錯誤造成的結果。若記錄只顯示簡短分類，應配合前後事件理解，不要把所有相似錯誤都歸因於同一欄位。修改後的複測也應維持相同操作順序。
使用 Data 比對請求路徑
Data 中的上傳與下載通常可用來觀察一段時間內的活動，但讀數必須配合目前檢視畫面、統計範圍及重設狀態解讀。不同檢視畫面的分類方式未必完全相同，不能直接將其中兩項相減，當作精確結論。測試前先記下基準值，接著只發出目標請求，再觀察相關讀數是否變化；這比對照已累積很久的總量更容易判斷。
裝置上的其他應用程式可能同時同步資料、接收訊息或在背景存取網路，因此測試期間總流量增加，不一定來自剛才開啟的頁面。若要確認某台伺服器是否參與，應查看能與該伺服器關聯的統計或請求記錄，再比對規則符合情況。只憑總流量增加，既不能證明目標使用了代理，也不能證明某條規則已按預期生效。
頁面載入失敗但仍有少量流量增加，兩者並不矛盾。建立連線、驗證交換、失敗回應及重試都可能產生流量；是否完整傳回內容則是另一回事。反過來，若頁面是從本機快取顯示，畫面看似已開啟，卻可能沒有新的網路請求。驗證規則時應確認確實發出了新請求；必要時改用可控的頁面路徑，而不是反覆重新載入同一份快取內容。
去識別化、分享與診斷流程
記錄與設定可能包含訂閱網址、驗證參數、伺服器位址、存取網域及查詢內容。分享前應刪除完整憑證與不必要的個人資訊，尤其要留意連結的查詢部分可能帶有驗證資訊。不要以為只遮住密碼欄位就足夠，也不要直接公開整份設定檔。若需展示結構，可將業務網域替換為 example.com，並保留錯誤類別、規則類型等必要脈絡。
有效的排錯說明應包含：預期行為、實際狀況、網路類型、Global Routing、目前 Config，以及已進行的一次單項修改。可附上去識別化後的相關記錄，不必提供所有歷史內容。若問題涉及應用程式取得或系統相容性，應回到 App Store 頁面核對；若涉及遠端帳戶效期，則應透過自己既有服務的管理資訊確認，不要只從記錄推測權限。
Widget 與系統入口
Widget 是用來查看狀態或快速存取常用操作的系統入口，具體形式取決於應用程式提供的元件及系統目前支援的功能。它不是獨立的代理設定，也不會取代 Home 中的伺服器與 Global Routing。首次使用前，應先在應用程式中完成連線驗證，再加入元件；如此遇到差異時，才能區分是元件顯示問題，還是連線本身出了問題，避免在多個入口之間反覆修改相同狀態。
元件設定與系統加入是兩回事
若 Settings 中出現 Widget 相關選項，應先了解它影響的是元件內容、顯示方式，還是快速操作。即使已在應用程式內設定相關內容，仍須依照系統提供的流程，將對應元件加入支援的位置。反過來說，系統中已顯示元件，也不代表其中所有操作都已完成初始化；首次使用前應開啟應用程式，確認目前設定與系統授權都可正常使用。
不同系統介面中的入口名稱不一定永遠固定。系統可能提供不同尺寸或位置的元件，顯示資訊量與可互動方式也可能不同。選擇時應以目前裝置可加入的項目為準，優先採用符合日常查看需求的簡單版面。若裝置上沒有出現某個選項，不要試圖修改網路參數找出它；先確認系統相容性及應用程式中的實際功能入口。
建議先保留預設顯示內容，再依需求減少不必要資訊。若元件位於容易被他人看到的位置，應留意伺服器名稱、狀態文字或統計資訊是否會暴露使用習慣。自訂名稱有助於辨識，但不要將密碼、訂閱網址或驗證資訊寫入項目名稱。顯示欄位是為了方便存取，不應用來儲存敏感連線參數。
如何核對狀態更新與操作結果
系統元件的顯示更新不一定與應用程式前景畫面完全同步。網路切換、建立連線及系統排程期間，元件可能暫時顯示較舊的狀態。若顯示不一致，先開啟 Shadowrocket，查看 Home 中的實際連線狀態，再發出請求進行驗證。不要只憑元件文字判斷連線已成功，也不要因元件尚未更新就連續執行相反操作，以免狀態反覆變動。
從元件執行操作後，系統可能需要開啟應用程式或顯示確認畫面；請依目前提示完成操作，不要把中間畫面當成失敗。操作是否完成，應以實際連線結果判斷。若目前 On Demand 仍要求連線，元件執行中斷後也可能再次觸發連線。此時應檢查隨選規則，而不是反覆刪除並重新加入元件，因為後者不會改變觸發條件。
若元件沒有顯示預期內容，先確認加入的是正確元件及尺寸，再核對應用程式中的 Widget 設定。接著開啟應用程式，等待初始化完成，並依系統方式重新載入元件。只有應用程式內的連線本身異常時，才進一步排查 DNS、伺服器與規則。將顯示問題與網路問題分開處理，才能避免為了修正畫面讀數，誤改原本正常運作的連線參數。
背景執行、耗電與系統權限的界線
元件存在、應用程式留在背景，以及系統網路連線正在運作，是三種不同狀態。不能因應用程式畫面離開前景就斷定連線已停止，也不必為了讓元件更新而不斷重建連線。系統會自行安排背景更新；應用程式內的網路記錄則反映實際請求。若要確認某段時間發生的情況，應參考 Log 與 Data，而不是只看螢幕上是否仍顯示應用程式。
耗電情況也不能只歸因於某個開關。頻繁重新連線、大量請求、網路訊號不佳及詳細記錄，都可能增加運作負載。比較前先固定網路與使用方式，再一次只變更一個條件。不要在網路持續切換、背景同步繁忙時，就對元件或 Ping 設定下耗電結論。若修改後發生異常，應先還原該變更並重新測試，再判斷是否有穩定關聯。
iCloud 同步與 Config
同步、備份、匯入與訂閱更新應分開理解。同步是讓支援同步的內容在裝置間傳遞；備份是保留可供復原的副本；匯入是將外部內容加入目前的應用程式；訂閱更新則依既有來源更新相關項目。這些功能可能出現在相近的入口，卻不代表會覆寫相同資料。換機前先列出需要保留的伺服器、設定與本機設定，再選擇相應方式。
先確認同步範圍與系統條件
使用 iCloud 相關功能前，應確認裝置已登入預期的 Apple 帳號、系統允許應用程式使用相關雲端功能，且目前網路能正常完成同步。接著閱讀 Shadowrocket 目前入口對同步範圍的說明。不要假定所有 Settings 值、連線狀態、系統 VPN 授權與歷史記錄都會同步；未明確列入範圍的內容，應在新裝置上逐項核對。
同步開關目前的狀態，不代表最新內容已儲存至雲端。修改後應留出時間讓系統完成傳送，再到另一台裝置確認相應項目是否出現且內容一致。若系統提示儲存空間或網路有問題，應先解決這些條件，不要重複匯入同一份檔案。重複匯入與同步同時進行，可能產生同名項目，讓人難以判斷哪一份最新、哪一份準備使用。
大量編輯前，建議先保留一份名稱清楚的備份，並註明用途及備份時的設定狀態。同步無法自動取代歷史備份，因為誤刪或誤改也可能同步到其他裝置。若備份包含憑證，應存放在自己能控管的位置，避免透過公開連結分享；檔名也不要包含完整訂閱網址。測試復原時最好先從少量項目開始，確認結構與內容正確後再繼續。
Config 檔案選擇與匯入後核對
匯入 Config 後，先檢查檔案是否完整、規則是否可讀、策略引用是否符合目前環境，再確認它是否已真正選為目前使用的檔案。檔案出現在清單中，不代表已啟用。若要還原舊裝置的行為，還應確認 Global Routing 是否處於 Config 模式；否則即使選取相同檔案，實際請求也可能繞過原本的規則判斷。
閱讀設定時，先掌握整體結構，再深入細節；先看規則順序與最終處理方式，再看網域、位址區段及相關網路設定。不要把從其他地方摘錄的一行直接加到檔案末尾，因為它可能位於 FINAL 之後，無法達到預期效果。編輯前複製原檔以便復原；編輯後儲存並確認啟用的是修改後的副本，避免在同名檔案之間切換，卻誤以為修改沒有生效。
[Rule]
DOMAIN,example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
FINAL,PROXY此範例展示將較具體的規則放在前面：example.com 本身先符合 DOMAIN，相關子網域再由 DOMAIN-SUFFIX 處理，其餘請求交由 FINAL。這只是規則片段，不能取代完整的伺服器資訊。實際使用時應明確了解每條規則的用途，並核對現有策略與網域範圍。若設定來自自己已有的來源，也應先閱讀變更內容再決定是否套用，不要只憑檔名判斷用途。
多裝置衝突與復原順序
兩台裝置同時編輯相同內容時，應先決定以哪一份為準，再等待同步穩定。不要在兩邊持續修改的情況下反覆刪除重建，否則更難辨認最後結果。可先暫停其他裝置上的編輯，在其中一台確認內容，再到另一台核對。復原時尤其要檢查同名伺服器的位址與協定參數，不要只憑顯示名稱就認定內容完全相同。
建議依照「取得應用程式、還原資料、核對目前設定、完成系統授權、實際測試」的順序換機。應用程式購買資格與設定資料是不同項目：前者依 App Store 的已購項目與相容性處理，後者則依實際備份或同步範圍還原。還原後仍須檢查本機 Settings 與 On Demand，不要假定舊裝置的所有行為都已複製。已購項目的還原步驟請參閱已購項目還原說明。
訂閱更新後項目有所變動時，先確認更新來源與項目歸屬，再檢查自訂編輯是否仍保留。不要把遠端項目更新誤認為 iCloud 衝突，也不要為了保留本機名稱就任意更改驗證參數。若需要整理，先備份並釐清哪些內容由既有訂閱管理、哪些由自己維護，保持分工清楚，才能在下次更新後持續追蹤變更。
Proxy 連接埠與驗證流程
Proxy 連接埠首先要區分本機與遠端。伺服器項目中的 Port 是連線至遠端服務的目標連接埠，必須與自己已有的伺服器資訊一致；Settings 若出現本機 HTTP 或 SOCKS5 服務的連接埠，則是裝置提供本機代理服務時的監聽入口。兩者不必相同，也不能互相取代。若不需要本機代理服務，建議維持相關功能的現狀，不要為了「提升速度」而任意啟用額外的監聽服務。
監聽位址、連接埠與存取範圍
連接埠必須與監聽位址一併理解。僅允許本機存取的入口，與允許區域網路其他裝置存取的入口，暴露範圍不同。設定前先閱讀介面對繫結範圍與存取權限的說明，確認是否確實需要讓其他裝置連線。不要只因知道連接埠數字，就認為其他裝置一定能存取；網路隔離、位址變更、系統限制及服務是否正在執行都會影響結果。
若需要手動填寫本機連接埠，應選擇介面允許且未被其他服務占用的值，並記錄原值。不要把遠端伺服器的 Port 直接複製到此處，也不要用隨機更改數字的方式解決所有連線錯誤。儲存後先確認服務能啟動，再由預定使用者以正確協定連線。HTTP 入口與 SOCKS5 入口使用不同協定，單純交換連接埠，無法讓使用端自動相容。
測試本機服務時，應先從最小存取範圍開始，確認運作正常後，再評估是否需要擴大範圍。若裝置的網路位址變更，使用端儲存的位址也可能失效。不要把位址變更誤判為伺服器故障，更不要在不清楚存取控制的情況下，將服務開放至不受信任的網路。停止使用後，應從實際入口關閉服務，並確認是否仍有其他裝置持續嘗試連線。
Global Routing 決定後續請求的處理方式
本機代理入口能接受連線，不代表後續請求一定經由所選的遠端伺服器。最終還須核對 Global Routing 與目前設定。Config、Proxy、Direct 是三種不同模式：設定、代理、直連。日常需要分流時，通常應在確認規則正確後使用 Config；Proxy 與 Direct 則較適合在明確了解影響範圍的情況下，用於需要統一路徑的場景或暫時診斷。
| 介面詞彙 | 中文說明 | 核對重點 |
|---|---|---|
| Config | 設定模式，依目前設定處理請求 | 已啟用的檔案、規則順序與策略引用 |
| Proxy | 代理模式，透過代理路徑處理請求 | 所選伺服器與實際連線結果 |
| Direct | 直連模式，不經所選代理伺服器轉送 | 目前網路能否直接連至目標 |
排查特定網域時，可先保留原狀，再暫時以 Direct 與 Proxy 分別比較，之後回到 Config 檢查規則。不過這種比較只能協助縮小範圍：直連成功、代理失敗，仍須檢查代理路徑上的解析、驗證與目標回應；兩者都失敗，則還要考慮目標本身及目前的基本網路。測試結束後務必還原原模式，避免把暫時診斷狀態誤當成日常分流設定。
按階段定位，不要同時修改所有參數
先判斷連線是否建立，再確認網域是否解析，接著檢查規則是否符合，最後查看目標回應。若無法連線至伺服器，優先核對 Address、Port、協定及驗證資訊；若已連線但只有部分網域失敗，再檢查 DNS 與規則；若只有特定服務失敗，則配合傳輸類型與伺服器要求判斷。WireGuard 欄位不能套用一般密碼型協定的方式解讀，請參閱Private Key、Peer 與 MTU 參數說明。
涉及 MTU、UDP 或特殊傳輸參數時，建議保留既有設定提供的值；只有在問題特徵明確且具備比較條件時才調整。數值愈小或開關愈多，不代表自然會更穩定。每次變更都應對應一個可檢驗的假設，例如是否只有某類請求在特定網路下失敗。若驗證後沒有改善，就還原原值；不要讓多次嘗試留下難以說明來源的設定組合。
修改完成後，進行一次涵蓋日常需求的最後檢查：確認目前伺服器與 Config，核對 Global Routing、On Demand 及暫時調整的記錄狀態，再分別測試常用頁面、必要的區域網路資源及網路切換。保留有效結論與復原紀錄，刪除不需要的暫存副本。若問題仍未解決，請帶著去識別化後的現象與測試條件參閱分流規則與連線排查常見問題，不要反覆重設來掩蓋尚未找出的原因。