Shadowrocket
Settings 設定項目指南

Shadowrocket 的實際運作並非由 Settings 中的單一開關決定。系統網路權限、目前選取的伺服器、Global Routing、正在使用的 Config，以及伺服器本身的協定參數都會影響結果。遇到「變更設定卻沒有作用」時，應先確認觀察的是哪一層，而非繼續疊加選項。本手冊以使用者已有自己的訂閱或伺服器資訊為前提；訂閱連結請向服務商取得，匯入後仍須確認目前選取的伺服器與設定是否正確。

初始狀態不等於統一的預設值

「預設值」須區分三種來源：新安裝時 App 提供的初始狀態、匯入設定中明確指定的值，以及從裝置備份或同步還原的舊值。三者可能不同。介面也可能隨 App 更新而調整，因此本頁不會把未經確認的連接埠號碼、測試網址或逾時秒數寫成固定出廠值。查閱設定時，請一併記錄目前介面顯示內容與目前設定檔；介面未顯示的值，不應根據他人的截圖推測。

開始調整前，先保留目前 Config 的副本，並記下 Global Routing、所選伺服器、網路類型及待解決的問題。記錄應描述可重現的現象，例如「同一網域在目前 Wi-Fi 下首次載入失敗」，而非只寫「網路很慢」。接著維持伺服器、網路與存取目標不變，只修改一項相關設定。即使結果變差，也能回到明確的起點，不必靠記憶逐一猜測原本的開關狀態。

三種模式決定規則是否生效

Global Routing 的 Config 模式會依目前設定處理請求；Proxy 模式以代理連線為主要處理方式；Direct 模式則以直接連線為主。這些模式是排查時的重要對照，但不代表網路必定可連通。系統保留流量、App 內的特殊處理方式與伺服器可用性仍會造成影響。尤其在 Proxy 模式下驗證規則變更，不能據此判斷 Config 中的規則順序是否正確。

日常建議是在了解目前規則的前提下使用 Config，而非一律切換至 Proxy。排查期間可暫時切換模式，測試後再恢復原本選項。既有的長連線未必會立即重新建立，因此請重新發送目標請求；必要時在適當時機中斷後重新連線。請勿在語音通話、檔案上傳或其他無法中斷的工作進行時反覆切換，以免把測試造成的中斷誤認為服務故障。

將規則檔視為另一組輸入

以下片段用於理解處理順序，不是完整可用的設定，也不會建立伺服器。PROXY、DIRECT、REJECT 是規則策略，不可與介面中的 Proxy、Direct 混為一談。範例網域僅供說明。規則由上而下比對，FINAL 應作為最後的預設規則；若將它放在前面，後續規則可能沒有機會處理請求。修改前請確認編輯的是目前啟用的檔案，而非同名備份。

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN,ads.example.net,REJECT
IP-CIDR,192.168.0.0/16,DIRECT
FINAL,PROXY

建議並列比對「預期行為」與「實際記錄」：預期某個網域使用 PROXY，就在請求記錄中確認目標網域、符合的規則與最終策略，而非只查看首頁的連線開關。若規則涉及解析後的位址，請回到 DNS 章節檢查解析路徑。購買與安裝相關問題請參閱正版驗證說明。用戶端一次買斷 ≠ 連線方案；調整設定無法取代服務商提供的有效連線資訊。

DNS 的作用是將網域解析為連線所需的位址。解析成功不代表目標服務可連線；解析失敗也不一定是伺服器故障。一次存取通常包含網域查詢、規則判斷、建立連線及應用程式層級的互動，任何環節都可能失敗。檢查 DNS 時，請先記下完整目標網域，並區分瀏覽器顯示的頁面錯誤與 Shadowrocket 記錄中的解析錯誤，避免把憑證問題、目標拒絕連線或回應逾時都當成 DNS 問題。

DNS 設定值的來源

App 介面中的 DNS 相關設定，須與 Config 中的解析設定一併理解。若檔案明確指定解析來源，只修改系統 Wi-Fi 頁面的 DNS，不一定會改變目前通道內的解析方式。反之，設定未指定某些選項時，也不能假設 App 一定使用某個公用解析服務。建議先檢查目前檔案是否有相關項目，再記錄 Settings 顯示的內容；測試還原時，也應清楚知道自己撤銷的是哪一層的變更。

使用系統解析來源通常適合作為排查起點，因為便於與裝置目前的網路行為比對；這不代表適用於所有網路的效能建議。企業、校園或家用網路中的內部網域，可能只有相應網路的解析服務能回應。若將解析來源一律改為外部位址，內部網域可能無法使用。若目前設定來自服務商，請先了解其 DNS 設計再決定是否覆寫，避免混用多組彼此關係不明的設定。

以下片段僅示範如何在設定中宣告使用系統解析來源。這不代表可以刪除檔案的其他部分，也不保證能套用至所有請求情境。編輯前請保留現有檔案，並確認同一節中是否已有相同鍵名，以免重複項目造成判讀困難。對於未在目前介面或檔案說明中確認的進階參數，建議維持原狀，不要依相似拼法自行新增。

[General]
dns-server = system

IPv4、IPv6 與網域規則

同一網域可能回傳 IPv4 或 IPv6 位址。裝置取得 IPv6 位址，不代表代理伺服器、目標網站與目前網路之間的完整連線路徑都支援相同的連線方式。若某個目標只在特定網路上失敗，請比較解析結果的位址類型與後續連線錯誤，再決定是否調整相關選項。不要把停用 IPv6 當成通用最佳化：這會改變其他存取路徑，也可能掩蓋真正的路由或伺服器參數問題。

DOMAIN、DOMAIN-SUFFIX 等規則直接以網域為判斷依據；IP-CIDR、GEOIP 等規則則涉及位址判斷。解析結果改變時，依賴位址的規則可能命中不同項目，因此「同一個網址採用不同策略」時，須一併檢查網域、解析位址與規則順序。若設定啟用了特定解析或映射機制，記錄中的位址也須配合該機制解讀，不應只憑位址外觀就斷定請求已透過某條路徑送出。

快取與可重現的驗證

修改 DNS 後立即重新載入頁面，仍可能使用舊結果。系統、App 與網頁本身都可能保留快取或既有連線。建議重新發送一個明確的目標請求，再查看是否出現新的查詢記錄；必要時重新建立連線並重新開啟目標 App。不要為了清除快取而連續修改多個開關，否則即使問題暫時消失，也無法判斷是解析來源、重新建立連線還是目標快取變動所致。

排查順序可固定為：重試同一目標、查看解析錯誤、比較目前網路與另一個已知可用的網路、檢查設定中的 DNS 項目、單獨調整解析來源、重新建立連線後複測。每一步都記錄結果。若只有內部網域失效，優先檢查本機解析需求；若所有網域都失敗，再確認目前網路是否已完成登入或驗證。網路本身尚未連通時，繼續更換 DNS 通常無法建立有效的對照條件。

若使用加密 DNS，還須考慮如何解析 DNS 服務本身的位址、連線是否經過目前策略，以及憑證驗證是否成功。多個解析位址不代表查詢一定更快，也不保證回傳結果完全一致。建議值應符合以下原則：在目前網路中穩定、路徑明確且可以還原。驗證成功後，只保留必要的變更，並註明原因，方便下次更換網路時判斷是否仍適用。

On Demand 可依系統識別的條件觸發隨選連線。它影響的是何時嘗試建立連線，不會決定網域最終採用哪種策略，也不會讓 App 持續顯示在前景。了解這一點很重要：On Demand 看似已觸發，但某個目標仍無法開啟，可能是伺服器、DNS 或規則問題；反過來說，手動連線正常，換網後卻沒有自動連線，才較應檢查條件是否符合或系統設定是否正確。

先建立手動連線基準，再新增條件

建議先關閉自動化設定，完成一次穩定的手動連線測試。確認 VPN 設定已依系統提示允許加入、目前伺服器有效，且目標請求在預期策略下可正常使用，再啟用 On Demand。否則手動與自動兩條路徑同時有問題，就難以判斷故障發生在觸發階段還是連線階段。初次設定的實際位置與可用條件，請以目前 App 介面為準；不要假定舊版介面的選項名稱適用於所有裝置。

預設狀態應以本機介面顯示為準，尤其是曾還原系統備份或已有 VPN 設定的裝置。即使重新開啟 App，系統儲存的隨選連線行為也不一定等同全新安裝。修改前請記錄 On Demand 是否啟用、現有條件的順序及對應網路。若只是暫時排查，可保留條件內容並暫停相關自動行為；不要直接刪除所有設定，以免遺失之後還原工作網路規則所需的資訊。

若目前介面提供依 Wi-Fi、行動網路或特定網路名稱設定條件，請先從一項容易驗證的條件開始，不要一次加入大量例外。網路名稱的拼字、空格與大小寫應依實際顯示核對；名稱相同的網路也不一定具有相同環境。網路名稱只是條件輸入，不能證明網路可信。存取組織內部資源時，請遵循該網路的連線規範，不要以自動條件取代必要的存取管理。

自動重新連線與手動中斷的界線

使用者手動關閉連線後，若隨選條件仍符合，系統可能在出現新的網路請求時再次嘗試連線。此時應先確認是否需要暫停 On Demand，而非連續點按連線開關。若想暫時保持中斷，應明確結束自動觸發條件，再查看系統 VPN 狀態。測試結束後請還原原設定，避免忘記重新啟用，誤以為 App 已失去自動連線能力。此行為應與伺服器連線失敗後重試分開記錄。

網路切換並非瞬間完成。裝置可能先離開 Wi-Fi，接著連上行動網路，再處理新的解析與連線；既有長連線可能中斷，而新請求會使用新的網路路徑。因此，驗證自動連線時應確認「切換後能否重新發送請求」，不只觀察切換時圖示是否閃動。測試時請預留合理的連線時間，不要在幾秒內反覆切換網路；頻繁切換會增加變因，也會讓記錄中出現大量難以關聯的失敗項目。

依網路情境建立測試表

建議分別驗證三種情境：在目前網路手動連線、從另一個網路切換後自動連線，以及暫停自動行為後手動中斷。每次都記錄觸發條件、系統狀態與一次實際請求結果。若只在某個 Wi-Fi 失敗，請檢查該網路是否要求先開啟登入頁面；網路驗證尚未完成時，自動連線可能與驗證流程互相影響。此時應先完成網路登入，再重新測試，不要誤改協定參數。

若裝置由組織管理，系統可能另有網路策略或設定限制。請先確認系統設定中實際生效的 VPN 設定，以及是否有管理要求，再判斷 App 條件是否有問題。不要反覆刪除系統設定來試錯，因為刪除可能同時移除權限、隨選條件與原有設定。建議先暫停自動行為、保留記錄並單獨驗證手動連線；只有確認設定失效時，才依系統流程重新授權。

日常建議依使用習慣決定：若需要明確掌控連線時間，手動連線較容易理解；若希望依網路條件觸發，再逐項啟用 On Demand。不要為了表面上的「永遠連線」狀態，疊加無法解釋的條件。設定完成後，請鎖定螢幕再喚醒、切換一次網路並重新發送目標請求，確認整個連線週期符合預期。若要回顧初次授權與連線順序，可返回快速入門指南確認操作流程。

Ping、連線測試與實際載入頁面並非同一件事。測試可能著重伺服器位址的回應、連接埠連線，或透過指定路徑存取測試目標；實際涵義取決於目前選用的測試方式。較低的時間數字不代表目標網站一定載入快速，逾時也不能單獨證明伺服器完全無法使用。開始比較結果前，請先確認測試類型、測試目標與當時的網路條件，確保比較的是相同測量方式。

測試方式與測量範圍

若測試只檢查基本網路回應，通常無法完整驗證應用程式協定的驗證與後續傳輸。連接埠可連線，也不代表密碼、TLS、SNI 等參數都正確。透過完整代理路徑存取目標的測試涵蓋較多環節，但也會受到測試網站本身狀態影響。建議先用基本測試判斷位址或連接埠是否可連通，再以實際請求驗證完整連線；不要因第一步通過就直接認定「所有設定正常」。

測試目標與逾時選項的初始值，請以目前介面為準。既有設定與歷史選項可能保留舊值，因此不同裝置的結果不能只按數字排序。建議先保留 App 目前可用的初始設定作為基準；確實需要更換測試目標時，請選擇用途明確且目前環境可連線的目標。一次只修改測試目標或逾時其中一項，避免把測量方式改變誤當成伺服器效能變化。

測試目標應盡可能穩定、回應內容簡單，並符合驗證目的。若目標需要登入、會重新導向、設有存取頻率限制，或對不同網路回傳不同內容，結果就可能受到其他條件影響。不要在清單中快速重複測試大量伺服器，並把短暫排隊或限流誤認為持續故障。使用既有訂閱時，只需針對自己實際使用的少數項目建立對照，不必追求清單中每一列都顯示相近數字。

逾時時間較短不代表結果較準確

等待時間太短時，首次解析、建立連線與加密交握可能尚未完成，測試便被判定逾時；等待時間太長則會延遲故障回報。建議先保留目前設定，少量重複測試以觀察穩定性，再依實際使用需求調整。持續增加逾時時間只會延長等待，不會修復位址錯誤或驗證失敗。若數次結果差異很大，應檢查網路負載與切換狀況，而非立即採用最低的一次結果。

延遲主要反映某次互動所需時間；吞吐量、封包遺失、壅塞與目標伺服器回應，也會影響實際體驗。小型頁面可以開啟但大型檔案中斷，或文字訊息正常但音訊與視訊不穩定，都需要更貼近實際用途的驗證方式。建議使用同一裝置、同一網路、相近時間與相同測試目標進行比較，再以實際工作情境複核。不同時間或不同測試方式得到的數字，只能作為各自情境的記錄。

從異常數值回頭檢查具體參數

若只有一台伺服器失敗，請先確認其位址、連接埠、協定與服務商提供的資訊；若同一網路下所有項目都同時失敗，先確認網路已連線且測試目標可用。若基本測試成功但實際連線失敗，再檢查密碼、TLS、SNI、系統時間與憑證驗證。不要為了取得成功結果而停用憑證驗證；這會改變安全界線，也無法證明原本的參數正確。請依服務商提供的正確參數修復。

測試前後也應留意流量用量與裝置狀態。大量測試會產生額外連線，使用行動網路時也會計入流量。若背景正在同步或下載，測試結果可能與裝置閒置時不同，因此記錄應包含「裝置是否有其他傳輸」這項條件。建議在相對穩定的環境中重複測試幾次，觀察結果範圍與失敗模式，而不是把偶然出現的最低值當成長期結論；測試排序更不能保證伺服器品質。

相關排查可繼續閱讀伺服器連線逾時排查順序；若想了解數值與實際體驗的差異，請參閱延遲、地區與協定選擇說明。本章建議維持測量條件一致，把數值作為線索，再以實際請求驗證。伺服器參數變更後，應重新建立基準，而非沿用舊測試結果判斷新設定。

Log 有助於定位連線過程中的錯誤，Data 可用來查看相關資料與請求資訊；實際入口與顯示欄位請以目前介面為準。它們的用途不是讓所有數字持續增加，而是將某次失敗與當時的目標、策略及錯誤階段連結起來。排查時應先寫下明確問題，再查看相關記錄。若只是瀏覽大量歷史項目，很容易把背景 App 的失敗請求誤認為目前頁面出錯的原因。

從單次請求建立時間軸

開始前記下本機時間、網路類型、Global Routing、目前 Config 與所選伺服器。接著只重現一次目標操作，例如開啟指定頁面，並立即查看同一時段的記錄。優先確認目標網域是否出現、是否取得解析結果、符合哪一條規則、採用何種策略，以及最後發生什麼錯誤。不同 App 可能同時存取多個網域，因此主要網域成功，不代表所有頁面資源都成功。

Log 層級、記錄開關與保留方式，不能假定在所有裝置上都有相同的初始值。建議日常保留符合使用需求的記錄範圍，只有排查問題時才暫時增加細節。較詳細的記錄可能增加儲存與處理負擔，也會包含更多瀏覽資訊。啟用記錄後，請確認它確實產生與目標操作相關的內容；不能只因「開關已開啟」就認為診斷已完成。

若目前介面支援清除記錄，清除前請先確認是否仍需保留故障前後的脈絡。可先保存必要資訊，再建立一段較乾淨的重現時段。不要一邊清除 Log 一邊持續重新連線，讓真正的首次錯誤被後續重試覆蓋。對於偶發問題，保留網路切換前後的少量記錄，通常比截取單一錯誤訊息更有幫助，因為後者可能只是前一次失敗引發的連鎖結果。

依階段解讀錯誤

解析錯誤優先檢查 DNS；連線遭拒時優先確認目標連接埠與服務狀態；等待逾時時檢查網路路徑、等待時間與對端回應；TLS 或憑證相關錯誤則須確認 SNI、系統時間與憑證條件。錯誤訊息應盡量保留原文，因為中文摘要可能遺失階段資訊。同一現象可能由不同原因造成；看到 timeout 時，不要同時修改 DNS、連接埠與規則，以免下一輪記錄失去對照意義。

診斷規則時，也須區分「預期命中」與「實際命中」。例如，預期某個網域使用 DIRECT，但記錄顯示符合 FINAL，可能是規則比對對象不符、順序錯誤，或實際請求使用了另一個子網域。此時應使用實際目標進行比對，不要繼續為猜測的網域新增規則。關於由上而下的比對方式與預設規則位置，請參閱自訂規則優先順序說明，再回到目前 Config 驗證。

流量數值與記錄範圍

Data 中的流量統計須依統計對象與時間範圍解讀。App 記錄的傳輸量不一定與服務商帳單完全相同；協定額外負擔、計費方式、重傳與統計重設都可能造成差異。不要直接把某個累計數值解讀為本月剩餘用量。若要核對服務用量，請以服務商提供的計費說明為準，並記下本機統計的起始時間，而非反覆重設數值來推測扣款情況。

請求記錄也有觀察上的限制。App 快取、既有長連線、系統行為與記錄層級都會影響顯示內容。沒有看到某筆記錄，不足以單獨證明請求未發生；看到連線項目，也不代表服務互動已成功。建議將用戶端記錄與目標 App 的實際結果並列判斷，必要時重新建立連線再觀察。對於加密通訊，記錄可說明的範圍也不等於完整的 App 內容。

排查結束後，請將暫時提高的 Log 層級恢復原狀，視需要清除含敏感內容的副本，並留下簡短結論：發生了什麼錯誤、修改哪一項、如何複測，以及是否已還原原值。不要長期保留未整理的大量記錄，也不要將完整設定與所有瀏覽記錄一併傳送。可重複使用的排錯筆記應記錄操作與結果，而不是秘密；下次遇到相似問題時，才能重現處理方法，而不必暴露舊憑證。

Widget 是從系統提供的位置查看狀態或前往操作的快速入口，不是獨立的連線服務。它需要先完成 App 設定、系統授權，並依賴系統安排的重新整理時機。使用前請先在 Shadowrocket 中完成一次手動連線，再新增或設定 Widget。若尚未完成首次授權，直接從快速入口操作，可能仍須返回 App 或確認系統提示；這與伺服器參數是否有效是兩件不同的事。

先完成主要設定，再新增入口

建議先確認要顯示或操作的內容：查看目前狀態，或快速進入 App 處理連線。系統提供的 Widget 尺寸、可用位置與互動功能可能因裝置環境而異，請以本機新增介面為準。本手冊不會將特定尺寸、按鈕或固定版面描述成所有裝置都具備的功能。若系統目前沒有顯示某項內容，請先確認 App 與系統的支援情況，不要反覆修改伺服器參數來尋找該入口。

Widget 的初始狀態也不能直接視為連線預設值。新增時可能先顯示快取、尚未載入的內容，或上一個連線階段的資訊。建議新增後先開啟主 App，確認目前伺服器與連線狀態，再返回查看。若可選擇顯示內容，先用最簡單的版面建立對照；複雜顯示中的某個項目未及時更新，不代表整個連線失效，更不應作為自動切換伺服器的唯一依據。

整理裝置主畫面時，應考慮哪些資訊會直接顯示給他人。伺服器備註可能包含用途、組織或個人識別資訊，即使沒有密碼，也可能暴露使用習慣。建議使用不含敏感內容的備註，並依裝置共用與鎖定畫面顯示情況決定擺放位置。使用 Widget 的便利性也須與資訊可見性一併考量；是否允許在鎖定畫面存取或顯示，請依系統實際提供的控制選項確認，不要根據其他裝置的截圖推測。

分開判斷顯示更新與連線狀態

系統會管理 Widget 的重新整理時機，因此顯示內容可能晚於主 App 的實際狀態。若兩處顯示不一致，請先開啟 Shadowrocket 查看目前連線，再檢查系統 VPN 狀態並發送一次實際請求。不要為了強制同步而連續點按 Widget；短時間重複操作可能使連線與中斷交替發生，反而造成新的失敗。若問題只是文字更新延遲，應按顯示問題處理，不要立即重建所有設定。

使用快速操作後，請等待連線流程完成再判斷結果。伺服器驗證、解析與通道建立都需要時間；在 Widget 上點按一次，不代表目標網站已可使用。若操作會開啟 App，請先查看是否有系統授權或錯誤提示，再檢查相關 Log。建議以固定目標完成一次驗證，確認此入口最後執行了預期操作。不要只憑圖示外觀變化就當成完整網路測試，它只能提供有限的狀態線索。

與 On Demand 的互動

啟用 On Demand 後，從 Widget 手動中斷連線，不代表之後會一直保持中斷。只要觸發條件仍符合，系統就可能再次嘗試連線。因此，若要暫時停止自動連線，應先處理 On Demand 條件，再使用快速入口操作。若只在 Widget 上反覆關閉，可能會誤以為按鈕故障。建議測試時分別記錄「點按操作是否執行」與「之後是否自動觸發」，不要把兩個階段合併成同一個結論。

更換伺服器、修改 Config 或還原備份後，也應重新確認 Widget 顯示的資訊。舊備註與舊狀態可能暫時保留，不能據此確認實際請求仍使用舊伺服器。請進入主 App 確認選取項目，再重新發送請求並透過記錄核對處理路徑。若主 App 操作正常，但 Widget 長時間沒有更新，可依系統流程移除後重新新增入口；這只會處理顯示，不應同時刪除 App 內的設定。

日常使用時，建議將 Widget 作為減少進入 App 步驟的輔助工具，重要變更則留在主 App 中完成。涉及訂閱更新、規則編輯或協定參數調整時，請查看完整介面與必要提示。排查結束後，恢復適合自己的顯示方式、保留清楚的備註，並確認系統隱私設定符合使用情境。如此既能善用快速入口，也不會讓一小塊可能延遲更新的區域負責完整診斷與狀態證明。

iCloud 相關功能可在支援範圍內儲存或同步 App 資料，但「已啟用 iCloud」不代表所有伺服器、Config、歷史記錄與系統授權都已完整同步。實際涵蓋範圍應依目前介面與還原結果確認。購買記錄、App 資料同步與系統 VPN 設定是不同事項：可從 App Store 重新取得已購 App，不代表連線資訊已還原；資料已出現，也不代表可以略過系統權限確認。

同步前確認範圍並保留原始副本

開始同步前，請先確認裝置登入的 iCloud 帳戶、系統是否允許相關 App 使用 iCloud，以及雲端空間與網路狀態。不要將 App Store 購買帳戶與 iCloud 資料帳戶混為一談，兩者用途不同。App 能正常安裝，不代表同步帳戶相同。建議先以不含敏感資訊、容易辨識的設定備註驗證同步流程，再處理重要資料，避免一開始就依賴尚未驗證的完整還原。

同步開關的初始值，以及哪些項目會參與同步，請在本機查看；本頁不假設所有裝置都預設啟用或停用。啟用前請保留一份由自己掌控的設定備份，並確認副本確實可以讀取。備份也可能包含伺服器憑據，請謹慎選擇儲存位置與存取權限。不能把裝置上的所有檔案都視為安全備份；若備份與正在編輯的項目其實是同一份檔案，誤改後便無法用它獨立還原。

建議先指定主要編輯裝置。多台裝置同時修改同名 Config，可能產生內容差異、延遲或衝突；實際處理結果取決於同步機制。不要假設最後開啟 App 的裝置一定會保留正確版本。一台裝置完成修改後，請等待另一台顯示相應內容，再逐項核對重要規則。檔名相同只代表名稱一致，不代表規則內容、伺服器參照與修改結果也完全相同。

更換裝置後逐層還原

還原時可分四個階段檢查：先從 App Store 取得已購 App，再確認 App 資料是否出現，接著核對目前伺服器與 Config，最後依系統提示完成連線授權。每個階段都應分別驗證。若資料已同步但連線失敗，請先檢查參數與權限，不要立即清空雲端資料重來。已購項目還原與相容性相關資訊，請參閱更換裝置與重新安裝說明；系統需求以 App Store 頁面標示為準。

若使用訂閱，還原清單後仍應確認更新是否成功，以及伺服器備註與參數是否符合服務商目前提供的資訊。同步可能還原舊清單，但訂閱內容已經變更。訂閱連結請向服務商取得並妥善保護；不要將連結放在公開備註、截圖或共用文件中。若只有某台伺服器缺少特定參數，請確認該項目的來源，不要反覆切換 iCloud 來修復協定內容。

同步內容不一致時的排查順序

若兩台裝置的內容不同，請先檢查帳戶、App 的 iCloud 權限、網路與可用空間，再確認比對的是同一個項目。等待合理的同步時間後重新開啟 App，查看是否有錯誤或衝突提示。不要同時在兩端連續修改、刪除並重建同名檔案，否則更難判斷差異來源。建議先暫停編輯，分別保存兩端內容，再決定要保留哪個版本；判斷依據應是實際內容，而非檔名。

離線裝置重新連上網路後，也要留意舊內容可能再次參與同步。還原重要設定前，請先確認哪些裝置仍保留舊副本，並在它們連線後檢查結果。不要把刪除一端資料當成必然只清除「本機」內容，除非目前介面已明確說明影響範圍。處理敏感資料時，也應分開確認本機檔案與雲端副本，避免以為清除一個頁面就已刪除所有副本。

日常建議採用「同步方便使用、獨立備份方便還原」的雙層方式。備份保留必要的 Config 與還原說明，移除無關的歷史記錄，並註明哪些權限仍須在新裝置上重新確認。請在可中斷的時段進行還原演練，成功後再清除暫存副本。iPad 的版面與設定移轉資訊，可繼續閱讀iPad 使用重點；無論使用哪種裝置，都應以實際還原結果為準。

討論 Proxy 連接埠時，首先要區分遠端伺服器連接埠與本機代理監聽連接埠。Add Server 中填寫的連接埠用於連線至服務商提供的遠端服務；本機監聽連接埠則用來接收符合相應代理方式的連線。兩者不是同一欄位，也不需要為了「保持一致」而設定成相同數字。修改本機連接埠不會改變遠端服務正在監聽的位置；修改遠端連接埠也無法解決本機連接埠衝突。

連接埠必須與協定相符

HTTP 與 SOCKS5 是不同的代理通訊方式，用戶端送出的請求須與接收端支援的方式一致。只填入數字不足以建立正確連線，還需要正確的位址、協定與必要的驗證。相關入口是否可用、是否允許區域網路存取，以及欄位名稱，請以目前 Settings 介面為準。若介面未提供某種監聽功能，不應根據其他軟體的使用習慣，推測 Shadowrocket 一定有相同選項。

本機連接埠的初始值請直接查看本機介面，不要把常見數字當成 App 固定的預設值。沒有接入需求時，建議維持原狀；確有需求時，再選擇有效且未被占用的連接埠，並讓請求端填入完全相同的值。變更後應確認是否成功監聽，而不只確認設定已儲存。若顯示連接埠已被占用，請先查明用途，再改用其他連接埠；不要反覆重新啟動來掩蓋持續存在的衝突。

迴路位址與區域網路位址也不同。某台裝置上的迴路位址指向該裝置本身，另一台裝置無法透過填寫自己的迴路位址來存取它。區域網路存取需要網路可連通、裝置位址正確，並明確允許相應的監聽範圍。裝置位址可能隨網路變動，因此某次設定可用，不代表換網後仍然有效。不要只複製舊位址；請先確認兩端位於可互通的網路環境，再測試連接埠。

監聽範圍是存取界線

若目前功能支援開放給區域網路，應將其視為新增的存取入口，而非一般效能開關。建議只有確有需要時才啟用，並檢查可用的驗證與存取限制。請勿在公用網路中任意擴大監聽範圍；使用完畢後應關閉暫時入口。其他網路裝置能否存取，還取決於網路隔離與系統行為；不能因一次測試失敗就認定入口未暴露，應從設定範圍本身檢視風險。

測試時先確認本機連線正常，再驗證請求端能否連至監聽位址，接著核對代理類型與驗證，最後查看目標請求是否出現在記錄中。若本機存取已失敗，繼續調整監聽連接埠通常沒有幫助。若本機正常，但請求端完全沒有記錄，應優先檢查位址、連接埠與網路隔離；若請求已出現但回傳錯誤，再依 Log 區分驗證、解析、規則與遠端連線問題，並保持排查順序清楚。

以最小變更記錄作結

完成本頁任何設定調整後，都應進行完整驗證：重新發送目標請求、核對實際處理策略、檢查是否出現新錯誤，再確認其他常用工作未受影響。若變更連接埠或監聽範圍，也要確認暫時開放的入口已依計畫關閉。不要只留下「問題已解決」的結論；也應記錄原值、新值與驗證條件，方便網路環境改變後判斷是否需要還原，而非繼續疊加新的例外。

以下是適合寫入個人排錯筆記的記錄格式，並非可匯入的設定。記錄中不需要密碼、訂閱連結或金鑰；WireGuard 等協定欄位的用途，可另行參閱WireGuard 參數說明。先確認參數屬於伺服器協定、通道位址或本機監聽，再修改相應層級，避免把名稱相似但用途不同的選項混在同一輪測試中。

觀察目標：example.com
網路條件：目前 Wi-Fi
Global Routing：Config
變更範圍：單一設定項目
原值記錄：修改前儲存於本機
驗證方式：建立新請求並檢查 Log
還原方式：撤銷本次變更後重新測試

若問題仍無法定位，建議回到最小基準：已有有效伺服器、明確的 Config、可用網路、必要的系統授權，以及盡可能少的自訂設定。接著依 DNS、連線、規則與 App 互動的順序逐層增加條件，而不是重設所有資料。購買問題請參閱價格與買斷說明；首次連線請返回快速入門指南。本頁說明設定與驗證方式，不提供連線服務，也不能取代服務商對伺服器狀態與參數的確認。