官方手冊 / Settings 設定項目參考
Shadowrocket
Settings 設定項目與設定依據
依用途查閱 DNS、On Demand、Proxy、Ping、Log、Widget 與 iCloud 同步，先確認設定的作用範圍，再決定是否調整。
Shadowrocket 是僅於 Apple 平台發行的付費用戶端，唯一取得管道為 App Store。開發者為 Shadow Launch Technology Limited，App ID 為 932747118；裝置相容性與系統需求請以 App Store 頁面標示為準。購買前可閱讀App Store 正版核對說明。
本頁是設定查閱手冊，不取代首次連線流程。若尚未完成匯入與授權，請先依入門指南完成主要步驟；若已能連線，只是想了解某個選項，再回到本頁查閱。下文均以使用者已有自己的訂閱或伺服器資訊為前提。用戶端一次買斷 ≠ 線路方案。
01 / 作用範圍與目前狀態
Settings 設定基準與調整順序
區分 App 設定、設定檔與伺服器參數
Settings（設定）主要管理用戶端的行為選項，但連線狀況並非只由此處決定。Home（首頁）選取的伺服器、Global Routing（全域路由）模式、Config（設定檔）中啟用的檔案，以及系統授予的 VPN 權限，都會影響要求的處理方式。排除問題前應先判斷問題屬於哪個層面，否則容易在 DNS 中尋找認證錯誤的原因，或藉由切換伺服器掩蓋規則比對問題。
伺服器位址、連接埠、認證資料與協定傳輸參數屬於連線資料，應逐項與使用者已有的資訊核對。規則順序、目標策略及部分解析行為可能由設定檔決定。Widget（小工具）和日誌主要用於操作與觀察，不負責修復伺服器資料。分別記錄這幾類資訊，有助於確認修改是否真正觸及故障原因，也方便測試後只還原相關部分。
本手冊不會將某部裝置目前顯示的開關狀態，視為所有安裝環境的固定預設值。首次安裝、還原資料、匯入設定及跨裝置同步，都可能形成不同的初始狀態。預設值應在未主動修改的實際環境中核對；已有資料的裝置則應稱為「目前值」。若介面沒有顯示某個項目，請勿為了比照文章而建立不存在的入口或參數。
Global Routing 的三種模式
| 模式 | 主要用途 | 檢查重點 |
|---|---|---|
| Config（設定檔） | 依目前設定檔中的規則分流。 | 作用中的設定檔、規則順序與策略指向。 |
| Proxy（代理） | 將符合條件的流量交由選取的代理處理。 | 伺服器連線與目標要求是否成功。 |
| Direct（直連） | 以直連方式處理符合條件的流量。 | 目前網路本身的存取與解析狀況。 |
三種模式不是三種速度，也不會改變遠端服務的能力。日常需要依規則分流時，前提是了解並妥善維護 Config；Proxy 和 Direct 可用於短時間對照，但測試後應恢復原本的使用模式。Direct 表示路由處理方式，不代表系統 VPN 已關閉。判斷連線是否中斷時，應同時檢查 App 連線狀態與系統中的 VPN 狀態。
建立可還原的修改紀錄
- 記錄目前的網路類型、連線狀態、伺服器備註、Global Routing 模式與作用中的設定檔名稱；不要在紀錄中寫入完整訂閱網址。
- 記下準備修改的設定項目、目前值、修改原因與預期觀察結果，接著只調整這一項。
- 結束舊要求；需要重新建立連線的設定，應先中斷連線再重新連線，並以相同目標驗證。
- 若結果沒有改善，先還原原值再檢查下一項；不要把多項未經驗證的調整一直疊加。
建議值應以明確需求為優先，而不是把所有開關都打開。若沒有特定解析需求，保留已驗證可用的 DNS 設定；若尚未了解自動觸發條件，先手動連線；排除問題後，再將詳細日誌調回日常所需程度。這些建議說明的是調整原則，不取代目前介面顯示的實際預設狀態，也不要求已穩定運作的使用者重新設定。
若連首次系統授權都尚未完成，應先回到入門流程，而非繼續微調進階選項。若只有特定目標異常，可保留目前連線並從要求記錄著手；若所有目標都同時失敗，則先檢查基礎網路與伺服器連線。更多狀況分類請參閱常見問題，再依相關章節繼續查閱。
02 / 網域解析
DNS 設定與解析路徑
解析成功不代表要求成功
DNS（網域名稱系統）會將網域名稱轉換成可連線的位址，但取得位址不代表目標服務已可使用。要求可能依序經過本機解析、規則判斷、代理連線與目標回應；不同設定下，解析與規則判斷的先後順序及執行位置也可能不同。遇到網頁無法開啟時，應先確認問題發生在哪個環節；不能因為更換 DNS 後偶爾恢復，就將所有問題歸咎於解析。
請區分伺服器網域與目標網域。前者用於建立到代理伺服器的連線，若無法解析，連線可能在抵達代理前就失敗；後者則是瀏覽器或其他 App 要求的位址。兩者可能採用不同路徑。記錄錯誤時應說明是「伺服器位址解析失敗」還是「連線後目標網域失敗」，不要籠統地寫成 DNS 無法使用，因為這會直接影響後續排除方向。
核對目前 DNS 設定時，先確認作用中的 Config 是否也包含解析相關內容，再檢查 Settings 顯示的選項。不要同時在多個入口加入不同解析位址，然後只依介面上最後修改的項目判斷實際行為。若無法確認設定的覆蓋關係，可先儲存現有設定，在可還原的副本中減少重複設定，再透過 Log（日誌）觀察新要求。
判斷預設值與建議值的依據
本手冊不指定通用的公共解析位址，也不會將某個位址視為適用所有網路的建議答案。若沒有明確需求，保留目前已驗證的解析方式；若需要存取區域網路名稱，先確認目前網路提供的解析能否辨識這些名稱。將所有解析交由外部解析器處理，可能導致內部網域無法取得對應結果，因此「能解析公共網域」不代表適合整個使用情境。
若介面提供加密 DNS 方式，應核對完整位址格式、憑證驗證與連線條件。加密描述的是解析傳輸的保護方式，不代表解析結果必然適合目前網路。解析器本身也必須可連線；若其連線依賴尚未建立的代理，而代理伺服器網域又依賴該解析器，就可能形成啟動相依問題。應先恢復能在連線前獨立完成解析的路徑。
| 狀況 | 優先核對 | 不宜直接推斷 |
|---|---|---|
| 連線前就失敗 | 伺服器網域解析與基礎網路。 | 不能直接判定目標網站故障。 |
| 只有內部名稱失敗 | 網路提供的解析與內部網域處理。 | 不能只比較公共網域的結果。 |
| 切換網路後出現異常 | 新網路的可連線性、快取與重新建立連線。 | 不能只看切換前的成功紀錄。 |
| 只有部分位址失敗 | 位址類型、規則路徑與目標連線狀況。 | 不能判定所有解析都失敗。 |
IPv6、快取與重複驗證
同一個網域可能回傳不同位址類型的紀錄，也可能依網路位置回傳不同位址。IPv6 相關選項應依目前網路與伺服器路徑是否支援來判斷，不宜只因單次存取失敗就長期關閉。若同一網域在不同網路上的表現不同，應比較實際使用的位址類型、規則策略與連線錯誤。解析紀錄存在，只代表取得候選位址，不代表對應路徑能完成通訊。
修改解析設定後，舊連線與快取可能仍會影響結果。先結束目標 App 中的舊要求，必要時重新建立 Shadowrocket 連線，再發出新的存取要求；若目前介面提供清除相關快取的操作，可先記錄原狀態再使用。不要把不斷重新整理同一頁面當成獨立測試，因為它可能沿用既有連線，甚至只讀取頁面快取而沒有發出新的網路要求。
可重複驗證的順序如下：確認基礎網路可存取、核對伺服器網域可解析、建立連線，再存取固定目標並檢查對應紀錄。接著只修改一項 DNS 相關選項，重新建立必要連線，再重複相同步驟。前後紀錄應維持相同網路與相同路由模式；若途中更換網路，就應視為另一組測試，不要直接比較。
排除問題後，移除或還原暫時新增但未證實有效的解析項目，並保留最終選擇的理由。長期設定應能說明適用條件，例如保留內部網域解析、符合已知網路需求，或修復已重現的相依問題，而不只是記得某個位址「以前有效」。
03 / 自動連線與系統權限
On Demand 的觸發與停止
按需連線不會持續產生網路要求
On Demand（按需連線）可讓系統依照已設定的條件管理連線觸發。它處理的是何時嘗試連線，而非為目標存取選擇規則策略。開啟後仍需要有效的伺服器資料、可用網路與相應系統權限；若認證資訊已失效，自動觸發只會再次遇到相同錯誤，不會自行修正伺服器參數或補齊訂閱內容。
查看此項設定時，應區分 App 內設定、系統儲存的 VPN 設定檔與目前連線狀態。App 介面退到背景，不一定代表系統連線已結束；手動中斷一次，也不一定表示之後符合條件時不會再次觸發連線。判斷行為時，應說明是在關閉自動觸發前中斷，還是在關閉後仍重新連線，這兩種狀況的排除順序不同。
首次連線時可能出現新增 VPN 設定檔的系統提示，這是 Apple 系統授權 App 建立相關網路連線的流程。請先確認提示來自正在操作的 Shadowrocket，再依系統要求完成驗證。若拒絕授權，即使後續設定正確，也可能無法建立連線。可在系統「設定 › 一般 › VPN 與裝置管理」核對相關項目；實際路徑請以裝置顯示為準。
先手動驗證，再啟用條件
- 暫時不依賴自動觸發，使用目前的伺服器與 Config 手動連線，並確認固定目標可存取。
- 進入 Settings 尋找 On Demand，記錄目前開關狀態與既有條件；條件名稱與可選範圍請以目前介面為準。
- 只啟用需要的一組條件，中斷連線後重新進入對應網路情境，觀察系統是否如預期觸發。
- 再進入不應觸發的情境，檢查是否維持預期狀態；最後驗證手動停止的完整流程。
建議從最少條件開始，而非一次涵蓋所有網路。若只希望在特定網路條件下連線，應先確認目前介面是否提供相應條件，以及條件的比對與例外關係。網路名稱相近不代表是同一個網路；空格、大小寫或重新命名也可能影響辨識。記錄時應使用自己能辨認的備註，但不要公開家庭網路的完整識別資訊。
不要將「已開啟自動連線」寫成「始終保持連線」。網路切換、系統排程、伺服器無法連線、裝置休眠與授權變更，都可能影響實際狀態。若要判斷功能是否正常，應搭配連線指示與實際要求，不要只看 On Demand 開關。若裝置長時間沒有網路要求，未觀察到新日誌也不一定代表自動觸發失效。
處理反覆連線與網路切換
若連線中斷後反覆恢復，先關閉 On Demand，再手動中斷連線，接著觀察系統狀態。若異常仍在，檢查是否有其他自行設定的自動化行為或重複 VPN 項目，逐一確認用途後再處理。不要一開始就刪除所有網路設定，因為這會同時遺失其他必要資訊，也讓原本可重現的觸發條件難以追蹤。
在需要先透過網頁完成登入的 Wi-Fi 網路中，應優先完成該網路的連線流程。若自動連線導致登入頁面難以開啟，可暫時關閉 On Demand 並中斷連線，再依網路要求完成驗證。接入完成後，還原原有設定並重新測試。這是在處理基礎網路尚未具備存取條件的情況，不應透過永久放寬憑證驗證或長期修改代理參數來解決。
從 Wi-Fi 切換到行動網路後，原連線可能需要重新建立。應觀察新的連線紀錄，不要沿用切換前的成功判斷。若只有某一種網路會失敗，請分別手動測試並記錄結果，再決定是否為該網路調整觸發條件。自動連線設定應建立在兩種網路各自都能正常運作的基礎上，否則自動化只會反覆呈現基礎故障。
若誤刪或拒絕授權，可先確認 App 仍是從 App Store 正常安裝，再回到連線操作，檢查系統是否會重新要求授權。關於系統項目的辨識與還原，請參閱新增 VPN 設定檔提示說明。不要混淆刪除系統設定與刪除訂閱，兩者管理的是不同層級的資料。
04 / 連線參數與本機監聽
Proxy、協定與連接埠的作用範圍
遠端伺服器連接埠與本機連接埠
Proxy（代理）相關內容最容易混淆的是兩種連接埠：伺服器資料中的連接埠指向遠端服務，本機監聽連接埠則用於接收以相應方式傳入的要求。兩者即使剛好數值相同，也不必維持一致。修改本機連接埠無法修復遠端認證失敗；修改遠端連接埠也不會讓其他裝置自動取得本機代理存取能力。
先確認目前編輯的是 Add Server（新增伺服器）中的連線資料，還是 Settings 中目前裝置提供的監聽相關選項。遠端連接埠必須與使用者已有的伺服器資訊一致，不要根據「常用連接埠」猜測。若資料來自 Subscribe（訂閱），也要確認之後更新是否會覆寫手動修改的欄位；必要時另外記錄備註，避免下次更新後誤以為設定自行失效。
本機連接埠只有在相應監聽功能啟用且接入方式相符時才有作用。連接埠號碼相同，不代表 HTTP 與 SOCKS5 自動相通；呼叫端必須使用監聽端實際支援的協定。一般在裝置內使用，不代表需要主動開放本機監聽；若沒有明確的接入需求，請保留目前已驗證的狀態，不要為了排除網頁問題而擴大監聽範圍。
連接埠設定與存取範圍
若目前介面提供本機連接埠編輯，先記錄原值與監聽範圍，再確認該連接埠未被其他服務占用。連接埠號碼在有效範圍內只是基本條件，能否成功繫結還受系統權限與執行環境影響。因此本手冊不指定適用所有裝置的預設連接埠，也不建議為了方便記憶，將多個不同服務設為相同的監聽位址與連接埠組合。
| 欄位所在層級 | 意義 | 設定依據 |
|---|---|---|
| 遠端伺服器連接埠 | 連線至遠端服務的目標連接埠。 | 已有的伺服器資料。 |
| 本機監聽連接埠 | 接收相應代理協定要求的入口。 | 實際接入需求與可用連接埠。 |
| 監聽位址或範圍 | 哪些網路介面可以接入。 | 最小必要存取範圍。 |
| 認證與傳輸欄位 | 連線身分與傳輸約定。 | 伺服器端設定的對應參數。 |
若介面支援區域網路接入，應先確認目前網路可信任，且接入端確實需要此功能。可供其他裝置存取的監聽，不能視為「僅供本機使用」；其他裝置能否連線，也會受到網路隔離與系統限制影響。若提供存取認證，應依實際需求設定並妥善保護憑證；使用完畢後恢復最小必要範圍，避免將臨時測試變成長期開放。
不要用用戶端監聽連接埠取代路由器中的網路概念，也不要將繫結失敗等同於伺服器離線。若出現繫結錯誤，優先還原原連接埠、停止重複監聽或重新啟動相關連線，再觀察錯誤是否消失。只有成功建立本機入口後，才繼續檢查要求是否經過正確的伺服器與規則路徑，否則多種故障會疊加在同一次測試中。
協定參數應依資料逐項對應
Shadowsocks、VMess、VLESS、Trojan、WireGuard 與 Hysteria2 是不同的協定或連線方式名稱，不能任意互換。伺服器位址與連接埠相同，不代表其他認證與傳輸欄位也能沿用。先確認協定類型，再核對目前介面顯示的必要欄位；不要為了減少輸入而將沒有依據的值填入憑證、伺服器名稱或傳輸相關選項。
連線資料要求 TLS 時，應確保憑證驗證與伺服器身分資訊一致。位址用來指定連線目標，伺服器名稱可能參與身分驗證，兩者用途不一定相同。若出現憑證錯誤，應核對裝置時間、現有資料中的名稱與憑證狀態，不要將關閉驗證視為長期建議設定。成功建立加密連線與確認連線到預期伺服器，是必須分別滿足的條件。
UDP 相關功能也取決於協定、遠端服務與目前網路，不能只根據一個開關推斷所有要求都能傳輸。網頁存取成功，不足以證明其他類型的要求正常；反之，某種業務失敗也不代表整個代理無法使用。應使用符合故障業務的驗證方式，並配合 Log 區分本機接入失敗、遠端連線失敗與目標回應失敗。
05 / 測量對象與對照方式
Ping 與 Connectivity Test
先確認測試實際測量哪一段
Ping（延遲測試）顯示特定測試條件下的回應狀況，並不能完整判斷線路品質。介面使用 Ping 這個名稱，也不代表底層一定採用某一種探測方式。若目前版本提供測試方式選擇，應先閱讀說明，確認測試對象是伺服器位址、連線建立流程還是特定目標要求，再判斷結果的意義。
Connectivity Test（連線測試）與實際業務存取也需要分開看待。測試成功可能只代表測試目標有回應；業務 App 仍可能受到 DNS、規則、認證、目標限制或連線重用影響。測試失敗也可能是探測方式不適用於目前網路，而伺服器仍能正常處理實際業務。因此測試結果只能作為佐證之一，不應作為唯一的可用性判斷。
比較延遲數值時，必須維持相同的測量條件。同一台伺服器在不同網路、不同時間或不同測試目標下得到的結果，不能直接排序。即使數值較低，也不代表持續傳輸、封包遺失情形或長連線穩定性較佳。選擇日常使用的連線時，應結合實際存取情境，優先關注可重複的成功與失敗，而非單次測量的最低值。
測試目標、逾時與並行數的設定依據
若 Settings 提供測試目標或逾時等選項，預設值請以目前介面顯示為準。沒有排除問題的需求時，保留已驗證可用的設定；需要更換目標時，選擇自己有權存取、行為穩定且能確認回應意義的目標。不要為了取得漂亮結果，選用只在特定網路可達、經常重新導向或需要登入的位址，再將其當成所有存取情境的代表。
逾時設定過短，可能將正常但回應較慢的連線判定為失敗；設定過長則會延後發現故障。設定值應符合測試目的，不是一味越小越好。若目前介面沒有對應選項，就不必依其他資料尋找同名欄位。調整後應先用已知可正常運作的連線驗證測試本身，再測試可疑連線，避免錯誤的測量設定影響所有結果。
一次觸發大量測試會增加瞬間連線與網路負擔，結果也可能互相影響。管理多個已有訂閱時，可先依群組縮小範圍，再測試需要比較的項目。不要在更新訂閱、切換網路與重新建立連線的同時連續測量，因為這些動作會同時改變測試條件，很難判斷差異來自測試對象，還是裝置當時的狀態。
一組可重複的測試紀錄
- 固定網路與 Global Routing 模式，記錄目前的伺服器備註與測試方式，不記錄認證欄位。
- 先存取一個已知可正常使用的目標，確認裝置基礎網路與測試目標本身都可用。
- 對同一項目間隔重複測試，觀察結果是否穩定成功，而非只保存數值最低的一次結果。
- 接著使用實際業務發出新要求，核對 Log 中的策略與連線結果，最後還原臨時測試設定。
若測試全部逾時，先檢查測試目標與基礎網路，不要立即刪除整份訂閱。若只有單一項目失敗，核對該項目的伺服器資訊，以及最近一次更新是否完整；若測試成功但業務失敗，檢查業務要求是否實際使用同一台伺服器，以及 Config 是否將目標分配到不同策略。分層檢查可減少不必要的全域修改。
若測試只在 Wi-Fi 或行動網路其中一種環境下失敗，應分別為兩種網路建立紀錄。不要把切換網路前保留的數值當成新網路的結果，也不要依據舊排序直接判斷目前最合適的項目。必要時等待基礎網路穩定，再重新建立連線並測試；面對經常變動的環境，應優先分析失敗模式，而非維持固定排名。
看到空白、未測試或失敗標記時，應依照介面上的意義記錄，不要自行換算成延遲數值。區分「測量未完成」與「測得結果較慢」，可避免誤讀排序。若結果長期互相矛盾，可暫停批次測試，改用固定目標與單一連線，並配合下一章的日誌方法建立最小可重現情境。
06 / 觀察證據與資訊保護
Log 的判讀與故障排除
用一項新要求建立時間線
Log（日誌）的用途是對照操作與結果，不是累積越多紀錄越好。開始排除問題前，先記下目前網路、Global Routing 模式、作用中的 Config 與選取的伺服器，再發出一項新的目標要求。接著依時間順序尋找相關紀錄，區分網域解析、規則比對、連線建立與目標回應，避免將背景 App 產生的要求誤認為正在測試的存取。
若目前介面提供日誌開關或詳細程度選擇，日常使用時保留足以觀察的層級；重現故障時，再暫時提高必要的詳細程度。實際預設狀態請以裝置目前顯示為準，不要假設所有安裝環境都會持續記錄相同內容。較詳細的日誌可能增加儲存與處理負擔，也可能包含更多存取相關資訊，因此排除問題後應恢復日常所需狀態。
沒有新日誌，不一定代表用戶端沒有運作。目標 App 可能重用既有連線、讀取本機快取，或相關流量不在目前記錄範圍內。先確認測試是否真的發出了新要求，再檢查連線狀態與日誌設定。反覆切換多個開關只會改變觀察條件；使用固定目標、一次明確操作與一段短時間的紀錄，更容易建立可靠的因果關係。
依故障層級判讀紀錄
| 觀察層級 | 主要問題 | 下一步 |
|---|---|---|
| 解析 | 網域是否取得可用位址。 | 區分伺服器網域與目標網域。 |
| 規則 | 要求符合了哪條規則與策略。 | 檢查作用中的設定檔與前置規則。 |
| 連線 | 是否已建立至遠端的連線。 | 核對伺服器、認證與網路。 |
| 目標回應 | 連線後，目標是否傳回預期內容。 | 檢查業務本身與回應意義。 |
若紀錄顯示要求走了 DIRECT，而預期應使用 PROXY，應先檢查規則與作用中的設定檔，不必急著更換伺服器。若確實使用預期策略但遠端連線失敗，再核對伺服器資料。若已建立連線，目標卻傳回業務錯誤，則應繼續檢查回應內容。日誌中的某個「成功」通常只代表其中一個階段，不能直接等同整個業務流程已完成。
檢查規則比對時，應留意第一條實際生效的條件。後面有一條看似正確的規則，不代表要求一定會比對到它。也要留意目標是否透過不同子網域要求資源，或使用新的連線路徑。若頁面主體能開啟但部分資源失敗，可分別尋找這些資源的紀錄，不要將頁面中的所有要求都視為同一個網域。
描述連線失敗時也應具體。逾時、認證不符與憑證驗證錯誤分別指向不同問題，不要一概歸類為「速度慢」。核對裝置時間、伺服器位址、連接埠與協定參數後，再決定是否需要向自己的服務商確認資料狀態。對外說明時，可提供錯誤類別與發生條件，不必提供認證內容或完整訂閱網址。
保留最少必要證據，避免擴大資訊暴露
日誌可能包含存取網域、目標位址、伺服器備註與其他情境資訊。分享前先檢查內容，只保留與故障相關的短片段，並移除訂閱網址中的敏感部分、認證欄位與個人網路識別資訊。截圖也要檢查狀態列、清單備註與相鄰紀錄；遮住一個欄位不代表整張圖片就適合公開，應重新檢視所有可見內容。
建議整理成簡短說明：使用什麼網路、採用哪種路由模式、對哪個目標進行什麼操作、預期與實際結果分別為何，以及還原原設定後是否有變化。搭配整理過的錯誤片段，這類描述比完整匯出長時間日誌更容易重現問題。若無法判斷哪些欄位屬於敏感資訊，優先以文字概述錯誤類型，不要直接傳送原始檔案。
排除問題後，保存最終有效的設定差異與還原步驟，再視需要清理不再使用的本機紀錄。清理日誌不會修復導致錯誤的設定，也不等於刪除訂閱；兩者應分開處理。若同類問題再次發生，可先對照上次的網路條件與故障層級，不必從頭嘗試所有設定。
07 / 快速操作與跨裝置資料
Widget 與 iCloud 同步範圍
Widget 是操作入口，不是獨立的連線設定
Widget（小工具）提供系統允許的快速檢視或操作入口，具體內容請以裝置可加入的小工具為準。它通常依賴 App 已完成的設定，不能取代首次匯入、VPN 授權與手動連線驗證。加入小工具前，應先在 Shadowrocket 中確認目前伺服器與設定檔可正常使用，再檢查小工具顯示的狀態是否與 App 內一致。
小工具的顯示可能受系統更新排程影響，不要將尚未更新的畫面當成即時連線證據。若要確認操作是否生效，請進入 App 檢查目前連線並發出新的目標要求。若小工具操作後沒有預期變化，先核對 App 是否需要完成授權、連線資料是否有效，以及系統是否允許相關操作，不要立刻修改 DNS 或伺服器參數。
建議將小工具用於已熟悉的常用操作，不要在不了解目前狀態時連續點按。快速重複操作可能使連線處於建立或中斷的過渡階段，畫面與實際狀態暫時不一致。先等一次操作完成再執行下一次；若需要停止自動重新連線，仍應依 On Demand 章節的順序處理，不要只依賴小工具上的一次中斷操作。
iCloud 同步不等於完整複製裝置
若 Settings 提供 iCloud Sync（iCloud 同步）或相關入口，應先確認裝置已依系統要求登入，並允許 App 使用 iCloud。哪些資料可同步、是否需要手動觸發，以及是否有獨立的匯入匯出入口，均請以目前介面說明為準。不要預設所有伺服器、設定檔、開關、日誌與系統權限都會自動同步，也不要將一次同步成功視為長期備份保證。
App Store 購買帳號與裝置使用的 iCloud 帳號用途不同。恢復購買是為了取回 App 使用資格，iCloud 同步則是傳遞受支援的資料，兩者不能互相取代。換機後能重新下載 App，不代表舊裝置的所有連線資料都已存在；反過來，看到同步資料也不代表目前裝置已完成所需的 VPN 授權。
啟用前先保留可還原的資料，並確認哪些內容只儲存在本機。若目前介面提供匯出功能，應檢查匯出範圍與檔案內容，妥善保管可能包含的認證資訊。備份應存放在自己能控制且可還原的位置，不要將完整資料放入公開文件。判斷同步的預設狀態時，也應以目前裝置為準，不要依據另一部裝置的狀態推斷。
兩部裝置出現差異時的處理順序
- 分別記錄兩部裝置的作用中 Config、伺服器備註與最近一次手動修改，先不要同時編輯同一份資料。
- 核對系統中的 iCloud 使用條件與 App 實際提供的同步範圍，確認兩端檢查的是同一類資料。
- 確定要保留哪一份內容，並在確保可還原後，再執行介面提供的同步或匯入操作。
- 逐一驗證各裝置的清單、設定檔選擇與實際連線，不要以檔名相同取代內容核對。
若兩端都修改過同一項內容，不要假設最近開啟 App 的裝置一定會覆寫另一端，也不要連續操作期待自動正確合併。先保存兩份差異，再依 App 實際顯示的衝突處理方式選擇要保留的內容。若介面沒有說明合併規則，通常由單一裝置完成修改、其他裝置驗證結果，會比同時編輯更容易追蹤。
同一設定檔在 iPhone 與 iPad 上呈現不同版面，不代表資料有差異。應比較具體欄位與作用中狀態，而不是只看清單寬度或按鈕位置。iPad 的購買恢復與版面說明請參閱iPad 購買與介面說明；共享購買、裝置相容性與系統需求請以 App Store 頁面標示為準，不要從同步結果反推適用範圍。
同步後若出現舊伺服器或重複項目，先辨認它是來自訂閱更新、手動匯入還是同步資料，再決定要清理哪個項目。刪除前先保留需要的備註與本機修改，避免連仍在使用的來源一併刪除。小工具只提供操作入口，同步只傳遞受支援的資料；最後仍須依本機作用中的設定檔與實際存取結果，確認設定是否正確。
08 / 設定檔協作與還原檢查
Config、Subscribe 與設定還原
更新伺服器資料不等於更新所有設定
Subscribe（訂閱）通常用於管理使用者已有的伺服器資料，Config（設定檔）用於存放規則與相關設定內容，Settings 則管理用戶端提供的行為選項。更新訂閱後看到新項目，不代表目前作用中的規則也隨之變更；編輯一份設定檔，也不代表它已被選取使用。每次變更後，都應核對清單內容、作用中選項與實際要求是否一致。
同時使用多個訂閱時，先以自己能辨認的備註區分來源，再處理排序與重複項目。名稱相同不一定代表參數相同，參數相近也不一定需要同時保留。不要只根據顯示名稱批次刪除，更不要將完整訂閱網址放進備註以便區分。關於分組、重複項目與刪除順序，可繼續閱讀多個訂閱連結管理說明。
手動修改既有訂閱項目的參數前，應確認後續更新是否會覆寫修改內容。若需要保留特殊調整，先記錄差異，並使用目前介面支援的方式建立獨立且容易辨認的資料。更新後若連線狀況改變，優先比對伺服器欄位與選取項目，不必立即重設所有 Settings。只有證據顯示故障來自用戶端選項時，才進入對應章節調整。
規則範例與比對順序
以下是 Shadowrocket .conf 中的規則片段，用於說明關鍵字、目標與策略之間的關係。這不是完整設定，也不包含伺服器資料；套用到自己的設定檔前，必須確認對應策略能如預期運作。範例主機僅使用 example.com，不代表任何實際業務都應照抄到相同路徑。
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
GEOIP,CN,DIRECT
FINAL,PROXYDOMAIN-SUFFIX 依網域後綴比對，適合描述特定網域及其子網域；GEOIP 依位址所屬地區資料比對，結果會受到位址與資料內容影響；FINAL 負責處理前面都未比對成功的要求。規則通常依順序檢查，因此較具體的需求應放在可能影響它的寬泛規則之前，收尾規則則應放在最後。
| 關鍵字 | 比對依據 | 注意事項 |
|---|---|---|
| DOMAIN | 完整網域。 | 不等同於所有子網域。 |
| DOMAIN-SUFFIX | 網域後綴。 | 檢查是否涵蓋過大的範圍。 |
| IP-CIDR / IP-CIDR6 | 對應位址類型的網段。 | 網域要求也可能涉及解析。 |
| FINAL | 先前未比對成功的要求。 | 檢查最終策略是否符合預期。 |
不要只因文字中存在正確規則，就認定它已生效。應確認目前 Global Routing 為 Config、作用中的檔案確實包含該片段，再從 Log 查看新要求的比對結果。若目前使用 Proxy 或 Direct 模式，應先恢復正確的測試條件。規則測試結束後，也應移除僅供實驗新增的項目，避免臨時比對長期影響其他業務。
從最小範圍還原，而非全部重設
故障發生後，先回想最後一項已確認的修改。若更換 DNS 後出現異常，還原原解析設定並重新建立連線；若編輯規則後出現異常，回到已儲存的設定檔副本；若訂閱更新後出現異常，核對更新內容與目前伺服器。這種還原方式只變更一個層面，容易驗證，也能保留其他正常運作的設定，避免問題與資料損失同時發生。
若無法確認修改來源，可建立最小檢查流程：確認基礎網路可用、伺服器資料完整、手動連線成功、固定目標可存取，再逐步恢復 Config、On Demand、Widget 與同步。每恢復一項就驗證一次，不要在同一次操作中重新匯入所有內容並啟用所有功能。最小檢查流程的目的是找出相依關係，不代表日常應長期使用簡化設定。
完成還原後，最後檢查日常路由模式、自動觸發條件、日誌詳細程度與同步狀態，並保存最終有效的差異紀錄。若需要重新完成整套操作，請返回入門指南；若要依狀況尋找原因，請閱讀常見問題。本手冊的目標不是套用一組統一參數，而是讓每項設定都有明確用途、可驗證的結果與可執行的還原步驟。