Settings 設定項目參考

01 · Settings 與預設狀態確認

排查設定時，起點不是將所有項目恢復預設值，而是建立一組可重複驗證的基準。先在 Home 確認目前選取的伺服器，再查看 Global Routing 狀態，以及 Config 中實際啟用的設定檔。只有放在這些條件下，Settings 中的變更才有意義：相同的 DNS 值，在不同網路、規則或伺服器下，結果可能不同。記下這三項後，再前往要修改的設定頁，並保留原值、修改原因與測試結果。

預設值、目前值與建議值並不相同

預設值是 App 在特定初始條件下採用的值；目前值則可能來自手動修改、匯入設定或先前還原的資料。已使用一段時間的裝置，不能只憑某個開關的位置推斷出廠預設狀態。本手冊不會將無法在每台裝置上確認的數字列為統一預設值；涉及開關、連接埠與測試方式時，請先查看本機顯示。建議值是適合目前用途的選擇，不代表在所有網路環境下都會更快。

若要確認預設行為，請優先閱讀 App 內對應項目的說明，再檢查目前啟用的設定檔是否包含相關指令。不要只為了取得「乾淨狀態」就直接刪除所有設定。刪除可能同時移除可供復原的伺服器記錄、規則與群組資訊。較穩妥的做法是先備份現有內容，複製一份設定供測試，並在記錄中註明與日常設定的差異。

先分清 Global Routing 的三種模式

Config 會依目前設定中的規則決定請求去向；Proxy 會透過該模式的代理路徑處理流量；Direct 則直接連線。三者是不同的流量處理模式，並非速度等級。日常需要規則分流時，通常從 Config 開始；需要排除規則影響時，可暫時切換並比較同一目標，但測試後應恢復原本模式。切換模式也無法補正錯誤的伺服器參數。

一次只變更一個變數

建議固定一個可重複操作的目標頁面，記錄網路類型、連線狀態與失敗情況。修改一項設定後，視需要重新連線，再重新送出請求；若同時更換伺服器、DNS 與規則，即使恢復存取，也無法判斷是哪一項生效。需要復原時，依修改順序逐項還原，不要繼續疊加新設定。測試結果應記錄「哪個步驟成功」，不要只寫「感覺正常」。

也要區分 App 範圍與設定檔範圍。Settings 中的全域項目、Config 檔案中的指令，以及個別伺服器的參數，不一定屬於同一層。若某項修改未達預期，先確認修改的是目前正在使用的項目，再查看 App 內說明所述的適用範圍。不要假設所有同名設定都採用簡單的覆寫關係，也不要把另一份未啟用設定檔的內容視為目前執行狀態。

若入口名稱與本文略有不同，請依功能及 App 內說明確認，不要只憑相似名稱直接修改。完整的首次操作順序請參閱教學；依症狀尋找排查方向，則可前往疑難排解。以下章節皆依「確認現況、最小幅度修改、實際驗證、失敗時復原」的順序說明。

02 · DNS：解析路徑與規則檢查

DNS 負責將網域名稱解析為可供連線使用的位址。網域解析成功，不代表後續連線一定成功；連線成功，也無法單獨證明使用了預期的解析路徑。因此排查 DNS 時，需一併檢視網域、解析結果與後續策略。先確認目前 Config 是否包含 DNS 相關指令，再查看 Settings 中實際可用的 DNS 項目及其說明；不要只憑瀏覽器的一句錯誤訊息就更換所有解析設定。

從目前可用的設定開始，不要直接替換

本機目前顯示的值是排查基準，不應直接稱為預設值。不同設定可能指定不同的解析伺服器、查詢方式或網域處理條件。日常使用既有設定且解析正常時，建議維持現狀；只有遇到可重現的解析失敗、回傳位址不符預期，或必須符合明確網路條件時，再針對問題修改。手動填入的位址越多，不代表可靠性越高。

在校園、辦公室或其他受管理的網路中，內部網域可能需要使用該網路提供的解析資訊。若將所有請求一律改交其他解析位址，內部網站可能因此無法使用。反之，若目前網路無法連線至某個解析位址，也可能拖慢請求。請先分辨「無法連線至解析伺服器」和「伺服器回傳的結果不符預期」；兩者的處理方式不同，不能只依等待時間判斷。

網域規則與位址規則處理的是不同問題

DOMAIN-SUFFIX 依網域後綴比對；GEOIP 則根據位址的地理資訊判斷。兩者依據不同，不能完全互相取代。規則通常會依序檢查，因此較明確的網域規則應放在適當位置，並將 FINAL 作為末尾的最終策略。以下片段用於說明順序，並非可直接取代個人設定的完整檔案；其中 PROXY 必須是目前設定可辨識的策略參照。

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
GEOIP,CN,DIRECT
FINAL,PROXY

此例會先處理 example.com 及其子網域，再檢查位址條件，剩餘請求則交由末尾策略處理。實際選用 DIRECT 或 PROXY，應依自己的存取需求與既有設定決定。複製片段不能保證特定網站一定能存取，也不應將所有網域都歸入同一策略來掩蓋解析問題。若只想讓指定網站走代理，可繼續閱讀DOMAIN-SUFFIX 設定與驗證。

分階段驗證，減少快取干擾

先用同一個網域重現問題，再查看請求記錄中是否取得位址、符合哪條規則，以及連線在哪個步驟發生。修改 DNS 後，請重新送出請求；既有連線可能繼續使用先前的解析結果，瀏覽器或系統也可能保留快取。必要時關閉相關頁面後重新開啟，並依 App 提供的方式重新建立連線。不要把重新整理一次頁面，當成所有快取都已清除的證明。

若只有一個網域無法使用，先檢查拼字、網域規則及目標本身；若多數網域都無法解析，再檢查解析位址是否可連線及網路狀態。若已取得位址，卻在建立連線時失敗，應轉而排查伺服器、TLS、路由或目標服務，而非持續更換 DNS。直接使用位址存取也不一定適合作為對照，因為 HTTPS 網站可能需要正確網域與憑證驗證。

建議保留一組成功與失敗的對照：使用相同網路、相同伺服器與相同網域，只變更要確認的解析設定。若必須跨網路測試，請另外記錄網路變更。內部網域出現異常時，優先恢復原解析條件進行驗證；若大範圍失敗，先還原最後一次修改。將結果與 Log 中的時間對照，比反覆切換多個位址更容易找出原因。

03 · On Demand：依條件連線與手動控制

On Demand 用來依照系統支援的條件觸發或管理 VPN 連線行為。它處理的是何時嘗試連線，不負責決定特定網站應採用哪條分流規則，也不會自動修正無法使用的伺服器。準備使用此功能前，先完成一次穩定的手動連線：匯入自己的設定、確認目前伺服器可用、檢查 Global Routing，並驗證實際存取。手動連線仍失敗時，不宜先啟用自動觸發，以免增加變數。

啟用前先確認目前狀態與條件

進入對應設定後，先記錄總開關及已有條件，再查看各條件的適用範圍。目前狀態可能沿用先前的設定，不能只因重新開啟 App 就認為已恢復預設值。若介面提供依網路或條件細分的項目，請逐項確認；未顯示的功能，不要根據其他裝置的截圖推測。建議從最少條件開始，只涵蓋確實需要自動連線的情境。

觸發條件與實際連線成功之間還有多個步驟：系統必須辨識條件、允許相關連線、建立網路通道，再由用戶端連線至伺服器。若目前網路尚未取得可用位址，或需要先完成網路登入，自動嘗試也可能暫時失敗。啟用 On Demand 不代表連線必定成功，也不能保證任何請求都會如預期完成。

切換網路時如何觀察

建議先在已知可用的 Wi-Fi 環境中驗證，再切換至另一個可用網路，觀察 VPN 狀態與 App 內的連線狀態是否符合條件。每次切換後，請預留網路連線所需時間，並送出新的存取請求。既有連線可能中斷後重新建立，背景 App 也可能維持舊狀態，因此應以新的請求及目前記錄為依據，不要只看切換前已開啟的頁面是否仍然顯示。

若設定涉及 Wi-Fi 名稱，請確認名稱完全一致，尤其留意大小寫、空格與相似字元。名稱相同不代表處於相同的可信任網路環境，因此名稱條件只能作為連線邏輯的一部分，不能視為身分驗證。裝置上的其他 VPN 設定或管理政策也可能影響連線結果；若發生設定互相切換的情況，先確認目前由哪個設定接管連線。

分清中斷連線與自動觸發

啟用 On Demand 後，手動中斷連線與之後再次符合條件，是兩個不同事件。若中斷後又重新連線，請先檢查 On Demand 條件，不要直接認定開關失效。需要明確排查離線狀態時，可先停用相關按需行為，再手動中斷連線，接著確認系統與 App 狀態。排查完成後，依原記錄還原設定，避免忘記曾暫時變更自動連線邏輯。

系統權限、裝置管理限制及目前網路狀態，都可能影響按需行為。若介面提示需要處理 VPN 設定，請先閱讀系統提示再操作；來源不明時，不要反覆按下確認。首次授權與日後自動連線是兩回事，設定已存在也不代表所有條件都有效。無法確認目前狀態時，先回到手動連線流程，驗證基礎網路與伺服器資訊。

建議設定取決於是否需要自動觸發，並非一律都要開啟。經常手動測試規則的使用者，可暫時採手動控制以減少干擾；已有穩定設定且明確需要依條件連線時，再啟用並逐項驗證。不要為了減少操作次數而一次新增大量條件。新增每項條件時，都應清楚說明適用情境，以及意外連線時如何取消。

若連線時斷時續，請記錄發生前是否鎖定螢幕、切換網路或完成網路登入，再與 Log 診斷對照。反覆點按連線只會增加觀察干擾。先停用自動觸發，重現一次手動連線，通常更容易將問題分成網路、伺服器與觸發條件三條明確的排查方向。

04 · Ping 與 Connectivity Test：測量範圍

Ping 與 Connectivity Test 用來觀察不同層面的連線狀況，測試結果不能保證所有實際存取都正常。首先確認目前使用的測試方式、測試目標與逾時設定，再解讀結果。名稱相似的測試可能檢查不同環節：有些著重主機或連接埠是否可達，有些則會經由代理路徑送出請求。請務必閱讀裝置上的項目說明，不要將所有顯示的毫秒數都視為同一種延遲。

先確認測量目標，再比較數值

一次測量通常只涵蓋特定網路與目標條件。對伺服器位址進行測試，與透過伺服器存取目標網頁，涵蓋範圍並不相同。前者成功，只能說明該路徑上的部分環節可連線；後者還可能受到網域解析、協定交握與目標服務影響。測試方式或目標不同時，不宜直接比較結果，更不應將較小的數字視為所有 App 都會更快。

本手冊不列出統一的預設逾時值或測試目標，因為目前設定可能已被修改，實際可用項目也應以 App 顯示為準。建議先保留目前可用的方式，以重複測試建立基準。需要調整時，一次只修改一個條件，例如固定同一目標並更換網路，或固定同一網路並比較測試方式。逾時時間過短，可能將較慢但能完成的連線判定為失敗；過長則會延後發現無法連線的狀態。

如何進行有參考價值的測試

先確認伺服器資訊屬於自己有權使用的設定，並核對位址、連接埠與協定。接著在相同網路下進行少量連續測試，記錄成功與失敗的情況，不要只保留最好的一次結果。若結果波動明顯，先排除網路切換、訊號變化及裝置正在大量傳輸等因素。不要同時執行多個測試工作，避免網路資源彼此競爭而難以比較。

接著建立連線，存取一個可重複驗證的目標，確認實際請求是否完成。頁面成功開啟後，也應依用途測試後續操作，例如繼續載入資源或完成一般互動。首次回應快速不代表持續傳輸穩定，單次下載表現也不能直接代表小型請求的延遲。測量應用於排查目前遇到的狀況，而不是只為了取得看起來更好的數字。

逾時不一定代表伺服器無法使用

部分網路會限制特定探測方式，伺服器也可能不回應某類探測。因此，Ping 逾時不等於實際代理請求失敗。若實際存取正常但探測失敗，可保留可用設定，並確認是否有更適合目前環境的測試方式。反過來說，連接埠可達也不代表驗證參數正確；密碼、UUID 或 TLS 參數錯誤，可能要到後續交握階段才會顯現。

若所有既有伺服器同時出現類似失敗，先檢查本機網路是否正常連線，再檢查共用的解析或測試目標條件。若只有一個項目異常，優先確認該項目的參數與服務狀態。批次測試失敗不足以證明所有伺服器都同時故障，尤其是測試共用同一目標時，目標本身就可能是共同影響因素。

TLS 類連線應保留憑證驗證，不要為了讓測試通過而任意修改安全相關選項。測試失敗時，先確認伺服器位址、連接埠、網域與裝置時間，再檢查服務端要求。延長逾時無法修正協定參數錯誤；若要了解具體填寫項目，可參閱Trojan 參數說明，但仍須以自己的實際設定為準。

最後應選擇「能穩定完成所需請求」的設定，而不是一味追求最低測試值。簡要記錄測試時間、網路類型與結果，再到 Log 中查找同一時間的失敗階段。如此可分辨測量方式不適用、基礎連線失敗或目標存取失敗，避免在錯誤的層面反覆修改。

05 · Log 與 Data：從記錄定位失敗階段

Log 的用途是說明一次實際請求經歷了什麼，不是只看到某個英文詞就判定故障。開始排查前，先記下目前時間、目標網域、網路類型、Global Routing 與已選取的伺服器；再送出一次可重複的請求，尋找時間相近的記錄。多個 App 可能同時在背景連線，因此只看清單最上方的一行，很容易把無關請求誤當成目前問題。

依解析、規則、連線與回應分層查看

第一層檢查網域是否完成解析並取得位址；第二層檢查請求符合哪類規則、採用哪種策略；第三層檢查是否成功連線至目標或伺服器；最後才查看後續交握與資料傳輸。記錄的具體欄位以 App 實際顯示為準，並非每種請求都會提供相同細節。缺少某項記錄也不一定代表該步驟未發生，應一併考量記錄範圍與目前設定。

例如，記錄中看得到網域與位址，但後續發生逾時，表示應繼續檢查連線路徑，而非只修改 DNS。若請求持續符合不符預期的規則，先檢查 Config 與規則順序；若策略正確但驗證失敗，則應著重檢查伺服器參數。只有將現象放回完整流程中，才能避免因看到熟悉的錯誤字詞，就跳過真正出問題的環節。

如何選擇記錄詳細程度與保留範圍

先查看目前與記錄相關的選項及 App 內說明，不要將本機目前狀態當成統一預設值。日常使用時，建議保留足以檢視必要資訊的範圍；需要重現問題時，再暫時增加相關記錄。較詳細的記錄可能增加儲存與處理負擔，也可能包含更多存取情境資訊。診斷完成後應恢復日常設定，不必長期保留每次測試產生的所有內容。

尚未保存有用資訊前，不要立刻清除記錄。較合適的順序是先記錄現象與時間、保存必要片段、確認已有復原依據，再視需要清理。重新連線可能改變記錄時間軸，因此要標記每次連線與中斷的時間。若問題偶爾發生，記下「何時開始、持續多久、是否切換網路」，通常比累積大量缺乏情境的記錄更有用。

Data 統計不能直接視為帳單數據

Data 用於查看 App 能夠統計的流量資訊。檢視時，先確認統計範圍、方向、時間區間，以及是否曾經清除數據。App 計數與系統、網路業者或連線服務的計數方式可能不同；協定額外負載、計量起訖點與更新時間也可能有差異。因此，Data 適合用來判斷某次測試是否有傳輸，不宜直接作為其他系統的計費依據。

若數值持續增加，先檢查前景下載、媒體載入與背景工作，不要立即認定某項設定異常。連線已建立但數據沒有明顯變化，也可能只是尚未產生新的請求。建議先進行一次簡短、可重複的存取，再觀察變化；不要為了驗證統計而反覆進行大量傳輸。若要長期比較，請先統一統計區間與清除數據的時間點。

分享前先移除敏感情境資訊

訂閱連結、驗證資訊、存取位址與伺服器識別資訊，都可能出現在診斷內容中。公開討論前，請檢查完整文字，而不只是遮住畫面中央的密碼。保留錯誤類型、時間順序與必要欄位名稱，並替換可識別個人帳戶或連線資源的值。若只需討論規則問題，通常不必提供完整訂閱或整份設定。

最後將「觀察到的事實」與「個人推測」分開記錄：事實是請求何時失敗、符合哪項策略；推測則是可能由哪個設定造成。帶著這份精簡記錄查看疑難排解，更容易找到正確的排查方向。排查完成後，請關閉暫時啟用的詳細記錄，並確認日常使用的仍是原先選定的設定。

06 · Widget：快速入口與狀態確認

Widget 適合作為日常查看狀態或前往操作的快速入口，不應取代 Home 中的完整確認。系統會管理元件的更新與互動方式，因此元件顯示的內容不一定是此刻最新的連線結果。若 Widget 顯示與 App 內狀態不同，先開啟 Shadowrocket，查看目前伺服器、Global Routing 與連線狀態，再送出實際請求。不要只憑元件上過時的文字判斷連線一直正常。

先分清元件顯示與實際控制

不同裝置環境可提供的元件樣式與互動項目可能不同，請以系統新增元件時顯示的選項及 App 內說明為準。部分操作可能需要開啟 App 或經過系統確認；不能因點按後畫面沒有立即變化，就判定功能失效。新增後先做一次明確驗證：分別觀察從中斷到連線、從連線到中斷的過程中，App 內狀態與元件何時更新。

Settings 中與 Widget 相關的項目，應先查看目前值，再決定是否修改。本手冊不指定通用的預設樣式，因為元件版面與系統支援範圍會影響實際呈現。建議只保留有助於日常判斷的資訊，避免過多相似入口造成誤操作。需要修改伺服器、協定參數或複雜規則時，仍應回到 App 內相應頁面完整確認。

元件內容延遲更新時如何排查

先確認 App 內的狀態是否已變更，再等待系統更新並重新查看元件。若 App 內仍在連線，應先排查連線過程，而不是重新建立元件。若 App 內與實際存取都正常，只有元件資訊未更新，可依系統提供的方式重新設定或新增元件。此時不要同時重設 Config、DNS 與伺服器記錄，它們通常不是顯示問題的優先檢查項目。

網路切換、鎖定螢幕與背景狀態都可能改變觀察結果。請記錄問題發生前做了什麼，並區分「元件未更新」、「點按後操作未完成」與「連線建立失敗」三種狀況。前兩者屬於顯示或互動流程；第三種才需要搭配 Ping 與 Log 檢查網路。將三種問題混在一起處理，容易反覆修改原本正常的連線參數。

搭配 On Demand 使用時留意操作順序

若已啟用 On Demand，元件觸發手動中斷後，條件再次成立時可能會重新嘗試連線。這不一定表示元件按鈕沒有反應。驗證時先暫時停用按需行為，再單獨測試快速操作；確認正常後，恢復 On Demand 設定並測試兩者搭配的結果。每次測試都應以 App 內的實際狀態為準，而非只比較圖示外觀。

快速入口也可能沿用 App 中原先選取的伺服器與設定，因此操作前應確認最後停留在哪個狀態。暫時測試結束後，若未恢復日常設定，下次透過 Widget 連線時可能仍會使用測試條件。建議每次規則排查結束時，都按固定順序收尾：恢復設定、恢復 Global Routing、確認伺服器，再檢查快速入口的狀態。

控管資訊顯示範圍

元件可能顯示在旁人容易看見的位置。若可設定顯示內容，請考量伺服器名稱與狀態資訊是否適合公開顯示。為個人項目命名時，也不宜將完整帳號、訂閱網址或其他驗證資訊寫入名稱。名稱只要方便辨識即可，詳細參數應保留在相應設定中；這樣既方便日常選取，也能降低截圖或展示螢幕時洩漏情境資訊的風險。

若元件顯示的流量來自 App 統計，也應搭配 Data 的計量範圍理解，不要只憑元件上的數值判斷所有裝置流量。系統更新頻率與 App 統計區間都可能影響顯示。若要比較一次存取前後的變化，先在 App 內確認統計範圍，再進行可控測試；不要直接將不同時間截取的兩個元件數值相減。

建議將 Widget 維持為簡單的快速入口，複雜修改則在 App 內完成。若元件持續異常，但 App 與實際存取正常，先按顯示問題處理；若三者都異常，再回到基礎連線檢查。如此既保留快速操作的便利，也能避免以反覆重設連線設定的方式處理單純的顯示延遲。

07 · iCloud：同步、備份與換機還原

iCloud 同步與匯出備份的用途不同。同步是在支援範圍內傳遞內容變更；備份則是保留特定時間點的副本。同步不等於擁有可隨時回到任意歷史狀態的封存檔。開始整理或換機前，先確認 App 實際提供哪些 iCloud 項目、目前開關狀態及可匯出的內容，再另行保存副本。尚未確認資料前，不要同時修改多台裝置。

先確認同步範圍，不要假設所有內容都會複製

請逐項確認伺服器記錄、Config 檔案與 App 設定各自採用的儲存或同步方式。不同內容可能有不同處理方式，不能因其中一份設定已出現，就推斷所有密碼、選取狀態與統計記錄都已完成轉移。實際涵蓋範圍以 App 內說明及操作結果為準。建議先用一項容易辨識且不含敏感資訊的內容進行驗證，再決定是否大幅整理。

在系統設定中確認目前的 iCloud 帳號及相關存取權限，並檢查可用空間與網路狀態。App 內的開關已開啟，只是同步條件之一，並非資料已完成儲存至雲端的證明。內容未更新時，先檢查這些基本條件，再觀察另一台裝置能否讀取；不要反覆切換開關或重複匯入同一份檔案來催促同步，以免產生重複且難以辨認的副本。

換機依序進行安裝、確認、還原與驗證

先從 App Store 取得 Shadowrocket；購買項目與已購項目確認方式請參閱還原說明。App 購買記錄與個人連線設定是不同類型的資料，還原已購 App 不代表伺服器資訊也已還原。安裝完成後，先確認 iCloud 條件，再依既有備份還原所需內容。最後重新確認目前伺服器、Config、Global Routing 與必要的系統授權。

首次還原後，建議先手動連線，暫時不要立即啟用複雜的 On Demand 條件。選擇一個熟悉的目標完成實際請求，再檢查 DNS 與規則是否符合預期。若內容已還原但連線失敗，請繼續檢查伺服器參數與目前網路，不要直接將故障歸因於同步。舊裝置上的可用狀態可作為對照，但不要同時在兩台裝置上進行彼此矛盾的修改。

處理差異與衝突時，保留兩份依據

兩台裝置都修改過相同內容時，不要假設系統一定會保留自己想要的版本。先分別保存本機副本，確認準備繼續使用哪一份作為基準，再依 App 提供的方式處理。比對時至少檢查規則順序、最終策略、伺服器參照與必要參數。檔名相同不代表內容相同，顯示時間較近也不能取代實際確認。

若出現重複項目，先確認內容是否不同或只是重複匯入，再刪除多餘項目。不要只依名稱批次清理，因為同名伺服器也可能有不同連接埠或傳輸參數。整理後先在一台裝置上完成驗證，再檢查另一台裝置的結果。涉及同步刪除時尤其要謹慎：確認影響範圍前，保留可獨立還原的副本比讓清單整齊更重要。

備份同樣需要存取控管

匯出的設定可能包含位址、密碼、UUID 或訂閱連結，不能因檔名看起來普通，就把它當作可公開的資料。請儲存在自己能控管存取範圍的位置，分享前逐項檢查；若只需討論規則，可另做一份移除個人參數的精簡範例。備份成功不只是「檔案存在」，也要能讀取並辨認其中保存的內容。

日常使用時，建議在重要修改前保留一份已知可用的副本，並記錄用途；不必將每次無意義的測試都當成長期備份。完整換機流程與還原檢查，請參閱設定備份與 iCloud 遷移。完成遷移後，再恢復自動連線與快速入口，最後確認舊的測試副本不會被誤選為日常設定。

08 · Proxy 連接埠：本機監聽與存取範圍

Proxy 相關連接埠，首先要分清本機監聽連接埠與遠端伺服器連接埠。Add Server 中的連接埠用於連線至自己的伺服器；本機代理監聽連接埠則讓支援相應代理方式的請求連上裝置上的監聽服務。兩者的位置、用途與存取路徑都不同。修改本機連接埠不會變更遠端服務實際使用的連接埠，也無法修正驗證資訊錯誤，更不能取代已失效的連線服務。

先確認協定、位址與連接埠三項條件

若 App 提供相應的監聽設定，請閱讀畫面顯示的協定類型、監聽位址與連接埠說明。HTTP 與 SOCKS5 是不同的代理連線方式，呼叫端必須選擇相符類型。位址指定請求應連往何處，連接埠則指定監聽入口；即使數字正確，只要協定或位址錯誤，仍然無法使用。不要照搬其他裝置範例，將常見數字當成本機一定採用的預設值。

建議只在確實有連線需求時啟用相關功能，並記錄本機原值。若目前只使用 Shadowrocket 的一般 VPN 連線與規則分流，通常應先完成這些主要流程的驗證，不必為了「設定完整」而額外變更監聽項目。不同入口可能有不同適用條件，請以 App 內說明為準；介面沒有提供的監聽或存取控制功能，不應靠猜測設定欄位來假定存在。

回送位址與區域網路位址不同

回送位址代表提出請求的裝置本身。另一台裝置若填入回送位址，指向的是那台裝置自身，而不是執行 Shadowrocket 的裝置。若用途確實涉及其他裝置，先確認 App 是否支援相應的存取方式，再檢查監聽範圍、所處網路與必要的存取控制。只擴大監聽範圍，並不代表請求一定能跨裝置連線。

擴大監聽範圍代表更多網路來源可能嘗試存取該入口，應優先採用符合需求的最小範圍。若介面提供驗證或存取限制，請依用途確認；若無法確定存取邊界，不宜將監聽服務開放至不受信任的網路。網路切換後，裝置位址可能變更，原先填入的位址也可能不再適用。使用完畢後，請取消不再需要的存取設定。

分別處理連線遭拒、逾時與驗證失敗

連線遭拒時，先確認相應的監聽是否已啟用、App 狀態是否符合要求，以及連接埠是否填寫正確。逾時則還需檢查位址、網路可達性與存取範圍。若已連線但出現驗證或協定錯誤，應檢查呼叫端採用的協定類型及雙方要求。尚未確認失敗層級前，不要連續更換多個連接埠，以免呼叫端與監聽端的記錄無法對照。

測試時，先保留一般 VPN 路徑作為對照，再單獨驗證監聽入口。若呼叫端支援代理設定，只修改必要欄位，並在測試結束後還原；否則後續其他 App 出現異常，可能只是仍在使用已關閉的監聽位址。某個 App 能透過代理存取，不代表裝置上的所有 App 都會自動採用相同設定，必須依實際請求範圍確認。

將連接埠驗證納入完整檢查

本機入口可用後，還需確認請求最後採用的策略與伺服器。監聽成功只代表請求抵達入口，不能取代後續解析、規則與連線驗證。可查看 Log 中同一時間的請求，再確認目標是否有回應。若找不到相應記錄，先確認呼叫端是否真的使用剛才填入的代理設定，而不是繼續修改遠端伺服器參數。

最後依固定順序完成收尾：恢復日常 Config 與 Global Routing，確認已選取的伺服器，還原暫時修改的 DNS 與記錄設定，確認 On Demand，再檢查 Widget。若要保留修改，請先更新自己的備份記錄。仍無法找出問題時，可依疑難排解繼續排查，或回到教學重新完成最基本的連線流程；不要用更多無關開關掩蓋尚未釐清的狀況。