取得與正版核驗：先確認 App，再準備連線資料
Shadowrocket 是 Apple 平台的付費用戶端，主要使用情境為 iPhone 與 iPad。唯一取得管道是 App Store；Mac、Apple TV 與 Apple Vision 的相容性資訊也可在同一產品頁查看，系統需求與一般購買條件請以 App Store 頁面標示為準。本手冊後續操作以 iPhone 與 iPad 為主，不會將其他裝置的介面配置直接套用到行動裝置。購買前，請先確認目標裝置能開啟相應商店頁面，再查看相容性與購買資訊，避免混淆帳號問題與連線設定問題。
核對開發者、圖示與 App ID
請透過下載指南中的正版核驗說明進行核對。App 名稱應為 Shadowrocket，開發者應為 Shadow Launch Technology Limited，App ID 為 932747118。圖示應與本站頁首所用的官方圖示一致。名稱只能作為初步辨識依據，搜尋結果中的相似名稱不能取代開發者與 App ID 的核對；可從產品連結末尾的 id932747118 確認 App ID。若商店搜尋結果不明確，請返回下載指南，透過產品頁入口前往；不要只因名稱相似就繼續購買。
進入產品詳情頁後，也要區分產品資訊與帳號目前狀態。價格按鈕、重新下載圖示和相容性提示分別代表不同資訊：價格與購買相關，重新下載與既有購買紀錄相關，相容性則說明目前裝置是否符合條件。其中一項顯示異常，不能據此推斷另外兩項也有問題。例如已有購買紀錄卻暫時無法安裝，應先查看裝置與帳號提示，而不是反覆尋找另一個同名產品。購買前可記下開發者與 App ID，換裝置核對時仍使用同一組資訊。
購買的是用戶端，不是連線服務
Shadowrocket 採一次買斷制，美國商店定價約為 2.99 美元，各商店會以當地貨幣顯示，實際價格與購買條件請以 App Store 頁面標示為準。付款取得的是 App 使用資格，不會因此自動取得伺服器位址、驗證資訊或訂閱連結。用戶端一次買斷 ≠ 連線方案。訂閱請向你的服務商取得，並確認其提供的匯入方式適用於 Shadowrocket。若尚未備妥這些資料，仍可完成安裝並熟悉介面，但不應將空白的伺服器列表視為購買失敗。
分別確認裝置與帳號條件
在 iPhone 上先確認系統需求，再完成商店購買與安裝。iPad 使用同一購買帳號時，能否直接重新下載及適用的購買範圍，請以 App Store 頁面標示為準；不要因兩台裝置的介面配置不同，就重新建立一套未經核對的參數。商店頁面是否可見、付款方式與購買紀錄，都取決於目前商店帳號的狀態。若產品頁暫時無法使用，先閱讀系統提示，確認目前商店與帳號是否支援該項購買，再決定下一步；反覆切換設定並非通用解法。
換機或重新安裝時，先到 App Store 的帳號與已購項目中尋找 Shadowrocket，並確認目前使用的是購買項目時所用的帳號。App 下載回來後，原有伺服器、訂閱與設定是否隨裝置還原，是另一項需要確認的事項。不要以為 App 重新出現，就代表所有連線資料也已還原。開啟 App 後，分別檢查伺服器列表、目前設定與路由模式，確認內容完整後再進行首次連線測試；購買項目還原流程請參閱已購項目還原說明。
進入下一章前，建議準備一份僅供自己查閱的資料清單：訂閱來源、伺服器協定、驗證方式、設定來源，以及需要設定的裝置。清單不必記下完整密碼，只要標示資料存放位置即可。不確定的參數先留白並向資料提供者確認，比猜填看似常見的數值可靠。之後無論匯入、更新或排查，都應回頭確認這份資料的來源；App 能安裝只代表取得流程完成，不代表連線資料有效。
首次啟動與權限：了解 VPN 設定與 Home 入口
首次開啟 Shadowrocket 時，先查看 Home，不必急著開啟連線開關。Home 是主要連線操作入口，其中的連線狀態、Global Routing、Connectivity Test 與 SERVER 列表，分別用於顯示狀態、選擇路由、測試連線能力及選擇伺服器。這些項目各自代表不同事項：列表中有伺服器不代表已選取，已選取不代表已建立連線，系統顯示 VPN 狀態也不代表所有目標都能存取。先釐清這些狀態，便不會只靠頂端開關判斷連線是否成功。
允許新增 VPN 設定代表什麼
首次嘗試建立連線等需要建立系統設定的操作，可能會觸發系統詢問是否允許新增 VPN 設定。確認提示是由剛才在 Shadowrocket 中執行的操作觸發後，再依系統要求授權；系統可能要求輸入裝置密碼或進行其他身分驗證。此步驟讓 App 能透過系統提供的網路延伸功能處理相關流量，不代表某個伺服器已自動設為信任，也不會代你填入驗證資訊。授權後仍須備妥正確的伺服器、路由與設定，才能實際通訊。
若先前拒絕了提示，可返回 App 再次執行連線操作，並依系統重新顯示的提示處理。若沒有出現預期提示，先查看系統設定中的 VPN 設定狀態，確認設定是否已存在，不要連續反覆點擊開關。受管理的裝置可能受到組織政策限制，無法建立設定或使用網路延伸功能；此類限制應向裝置管理者確認。不要任意刪除其他用途的系統設定，尤其是工作或學習用裝置；刪除前應先確認其用途與還原方式。
依 Home 的操作邏輯檢查四個位置
- 先看 SERVER，確認是否已有準備使用的伺服器，並檢查選取標記。
- 再看 Global Routing，確認目前是 Config、Proxy 還是 Direct。
- 開啟頂端連線開關後，留意狀態是否完成切換，不要剛點下就離開 App。
- 使用 Connectivity Test，並進一步驗證一項明確的實際請求。
尚未建立連線時，可能會顯示 Not Connected。此狀態只說明目前的連線情況，無法單獨指出失敗原因。伺服器列表空白、驗證錯誤、系統設定尚未授權或網路無法使用等情況，都需要分別從各自層面檢查。反過來說，頂端狀態已切換，只代表連線機制開始運作；伺服器能否轉送流量、網域能否解析，以及規則是否選到預期策略，仍須另外驗證。詳細介面說明請參閱首次開啟與 Home 頁面區塊說明。
其他權限依實際操作授予
使用 Scan QR Code 時，App 需要相機權限；若先前拒絕，可到系統設定檢查相應權限，再返回掃描。只手動輸入或透過連結匯入時，不必為了日後可能使用而預先開啟相機權限。透過檔案選擇器匯入設定時，請確認所選檔案的來源與內容；透過剪貼簿讀取資訊時，請確認剪貼簿中確實是剛複製的連線資料。權限提示只說明 App 準備存取哪類系統資源，不能取代對資料來源的判斷。
首次操作時，建議一次只完成一個步驟：先匯入一筆已知資料，再確認列表內容，最後連線。權限提示尚未處理完畢時，不要同時切換網路、更新訂閱或更改路由，否則發生異常後難以判斷是哪一步造成。若系統提示需要重新授權，先記下當時的操作與提示文字，再確認既有 VPN 設定是否對應目前的 App。只因一次連線失敗就刪除 App，可能造成尚未備份的本機資料遺失，也會增加重新授權與重新匯入的工作。
此階段也應確認裝置本身已連上網路。開啟原本可存取的頁面，檢查是否需要先完成目前網路的登入或確認程序。App 無法替尚未連上網際網路的裝置建立基礎連線；遇到公共網路的登入頁面時，先完成網路要求，再測試 Shadowrocket。若裝置上還有其他會接管網路的功能，先釐清各自用途，並在可控條件下逐項比較。完成這些檢查後，下一章的匯入結果才有穩定的測試環境。
伺服器與訂閱：區分單筆參數、Subscribe 和 Config
匯入前先辨認手上的資料類型。單筆伺服器資訊描述一個連線端點，通常包含協定、位址、連接埠與驗證欄位；訂閱連結用於取得並更新一組伺服器；Config 設定檔主要包含規則與相關設定，也可能引用策略名稱。這三種資料不能只靠連結外觀互相替代。訂閱請向你的服務商取得；若不確定格式，先確認該資料應使用哪個入口匯入，再進行操作。不要把服務說明頁面的網址直接當成訂閱網址。
透過 Add Server 手動新增
進入 Add Server 後，先選擇與現有資料相符的協定，再填寫該協定要求的欄位。位址只填實際伺服器網域或位址，連接埠依資料提供的值輸入；驗證方式可能使用 Password、UUID 或金鑰，彼此不可互換。留意輸入法是否加入空格、全形標點或換行，也要檢查複製內容前後是否有空白。顯示名稱可用來辨識伺服器，但不是連線參數；更改名稱無法修正錯誤的位址、驗證資訊或傳輸設定。
| 協定 | 重點核對項目 | 不可憑經驗自行填寫的項目 |
|---|---|---|
| Shadowsocks | 位址、連接埠、Method、Password | Method 必須與伺服器端一致。 |
| VMess / VLESS | 位址、連接埠、UUID、傳輸方式與 TLS | 傳輸路徑、Host、SNI 依資料設定。 |
| Trojan | 位址、連接埠、Password、TLS | 分別核對憑證名稱與連線網域。 |
| Hysteria2 | 位址、連接埠、驗證與 TLS 參數 | 附加參數以伺服器端要求為準。 |
| WireGuard | 金鑰、端點、位址與路由範圍 | 不可套用其他協定的金鑰與位址。 |
同一協定也可能採用不同傳輸方式，因此「協定名稱相同」只是必要條件之一。以需要 TLS 的連線為例，實際連線位址和憑證驗證名稱可能不同，Host 與 SNI 也各有用途；不要把所有網域欄位都改成同一個值來試錯。若資料沒有說明某個欄位，先保留預設值或向提供者確認。協定簡介請參閱支援協定與參數概覽；實際填寫仍應以你的伺服器資訊為準。
透過 Subscribe 匯入與更新
新增訂閱時，在相應的 Subscribe 入口輸入完整連結並儲存，再執行更新。連結中的路徑與查詢參數可能用於驗證，少了任何一段都可能得到錯誤頁面或空白結果。不要為了縮短網址而刪除參數，也不要在公開提問中貼出憑據。更新後返回 SERVER，確認是否產生預期項目，再選取其中一項連線。訂閱名稱可自行整理，但應保留足以辨識來源的資訊，方便日後確認需要更新哪一組內容。
訂閱更新成功只代表本次內容已成功取得並解析，不保證每台伺服器目前都能使用。更新失敗也不一定表示所有伺服器都已失效；應分別檢查目前的基礎網路、連結是否完整、驗證是否仍有效，以及回傳內容格式是否正確。若原本已有可用列表，先保留列表並記下失敗提示，再處理問題，不要先刪除整個訂閱群組。部分訂閱更新會新增、移除或重新命名項目；更新後也要再次確認目前選取的伺服器是否仍然存在。
掃描、連結與設定檔的適用範圍
Scan QR Code 適合匯入可辨識的連線資料，但 QR Code 只是資訊載體，不能證明資料有效。掃描後先核對協定與位址，再儲存；若結果只是一般網頁，請返回資料來源確認 QR Code 是否正確。透過剪貼簿或檔案匯入也應遵循相同原則：匯入後檢查實際建立的項目，不要只看是否出現成功提示。至於 Import from Cloud JSON 等特定入口，只有在現有資料明確要求時才使用，不要將不相符的檔案反覆交給不同入口嘗試。
Config 與訂閱應分開維護。更新伺服器列表通常不會自動替你建立所需規則；切換設定也不能取代更新訂閱。規則若引用自訂策略名稱，必須確認目前環境能辨識這些名稱。先保留原始資料，再進行本機調整，並記下修改的是單筆伺服器、訂閱群組還是設定檔。釐清這些項目的差異後，即使列表內容有所變動，也能準確判斷應重新匯入、更新訂閱，還是只修改目前設定。
Global Routing：Config、Proxy、Direct 與規則順序
Global Routing 決定目前採用哪種整體路由模式。配置對應 Config，代理對應 Proxy，直連對應 Direct；實際介面會顯示英文原文。三者不是伺服器協定，也不是連線速度等級。Config 依目前設定中的規則選擇處理策略；Proxy 將目前連線可處理的請求交由所選代理策略處理；Direct 則直接連線。開始排查前務必先確認這項設定，因為相同伺服器在不同路由模式下，實際請求可能經過完全不同的處理路徑。
先依路由模式縮小問題範圍
| 介面用語 | 主要意義 | 常見檢查用途 |
|---|---|---|
| Config | 依目前設定中的規則決定策略。 | 確認網域、位址與預設規則是否符合預期。 |
| Proxy | 主要使用所選代理策略處理請求。 | 暫時減少分流差異，以檢查伺服器連線路徑。 |
| Direct | 採用直接連線。 | 比較基礎網路與代理路徑的表現。 |
若同一請求在 Proxy 下可以完成，在 Config 下卻失敗，應優先檢查規則命中與策略引用，不要立即更換驗證資訊。若兩種模式都失敗，再繼續檢查基礎網路、伺服器與解析。Direct 的結果僅供比較直接連線路徑，不能證明代理路徑正常。測試結束後記得恢復日常需要的模式，尤其不要在診斷後長期保留臨時設定，否則之後的統計與存取行為可能不符合原先預期。
規則由上而下比對，具體條件應放前面
規則的關鍵在於條件、策略與順序。一般會由上而下尋找符合條件的項目，由第一條命中的規則決定處理方式；因此，較具體的例外應放在較寬泛的條件之前，並將 FINAL 放在末尾作為預設規則。DOMAIN 比對完整網域，DOMAIN-SUFFIX 比對網域後綴，DOMAIN-KEYWORD 依網域中的關鍵字比對；IP-CIDR 與 IP-CIDR6 分別用於位址範圍，GEOIP 則依賴位址歸屬資料。不要只因關鍵字看起來熟悉就直接複製，必須先確認目標請求是否提供該規則所需的比對資訊。
[Rule]
DOMAIN,portal.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXY這段範例先讓某個完整網域直接連線，再讓相同後綴下的其他符合項目使用 PROXY；私有位址範圍採用 DIRECT，接著依 GEOIP 處理位址歸屬，最後由 FINAL 作為預設規則。範例只示範語法與順序，不代表適用於所有網路。尤其 GEOIP 規則不能取代網域規則，也無法保證每次請求都有可用的位址資訊。將範例用於實際設定前，請先檢查既有規則、策略定義與本地網路需求，避免直接用範例覆蓋整份設定檔。
不要混淆策略名稱與介面模式
規則中的 PROXY、DIRECT、REJECT 是處理策略關鍵字，與 Global Routing 中的 Proxy、Direct 屬於不同概念層次。設定也可能引用已定義的策略群組或特定名稱，拼寫與引用必須一致。單條規則語法正確，不代表其指向的策略一定存在；策略存在，也不代表其中選取的伺服器可用。因此檢查設定時，應依序確認「命中哪條規則、規則指向什麼、該策略最後選了什麼」，而不是只看規則條件。
複雜頁面可能會發出多項請求。一個頁面可能同時存取頁面網域、資源網域與 API 網域，各自命中的規則可能不同。若頁面可以開啟但部分內容缺失，先確認失敗請求的實際目標，再判斷是否需要新增規則。DOMAIN-KEYWORD 過於寬泛時可能影響無關網域，應優先採用能精確描述目標範圍的條件。每次只新增少量規則，並為本地例外加上一句用途說明，之後訂閱或設定更新時才容易確認是否仍有需要。
匯入設定後，應確認已選取目前要使用的檔案；編輯某份檔案不代表它已生效。儲存後檢查設定是否可用，必要時重新建立連線，排除舊連線造成的影響，再以相同目標重測。對於尚未結束的長連線，只重新開啟頁面可能不足以觀察新策略；應依測試 App 的實際行為重新發出請求。把設定選取、規則順序與請求生命週期一併考量，才能正確理解「規則已修改，結果卻沒變」的情況。
連線與驗證：從選取伺服器到定位失敗層面
連線前先返回 Home，確認 SERVER 中確實選取了預期伺服器，而不只是進入過該伺服器的編輯頁面。確認 Global Routing 符合本次測試目的後，再開啟頂端開關。留意系統與 App 的狀態變化，等待連線程序完成後再進行測試。首次驗證宜選擇一台資料明確的伺服器與一個固定目標，不要同時更新訂閱、修改規則並進行多項測試。可重複的測試條件，比偶然成功一次更有參考價值。
將連線成功分為三個層面
第一層是系統連線狀態，表示網路延伸功能是否開始運作；第二層是伺服器連線路徑，表示目前端點能否建立所需通訊；第三層是實際服務請求，涉及目標網域、解析、規則與目標服務本身。三個層面可能呈現不同結果。例如系統狀態正常但頁面無法載入，並不矛盾；伺服器連接埠有回應，也不代表驗證與後續轉送都成功。排查時應記下具體在哪一層失敗，避免用「連不上」概括所有現象。
Connectivity Test 可用於快速檢查，但測試結果取決於測試方式、目標與目前網路條件。某次測試的數值只代表當下特定路徑，不能直接當作日常存取品質的排名。先執行測試，再開啟一個明確的實際目標，確認頁面或請求是否完整完成。若測試結果與實際表現不同，應比較兩者使用的目標、協定與策略，不要將其中任一項視為絕對結論。操作流程請參閱選取伺服器與 Connectivity Test 驗證。
依序檢查基礎網路、端點、解析與規則
- 確認裝置的基礎網路可用，且已完成目前網路的登入或確認程序。
- 核對所選伺服器的位址、連接埠、驗證資訊與必要的傳輸參數。
- 確認網域解析正常，並區分位址無法連線與名稱解析失敗。
- 檢查路由模式、目前設定及失敗請求實際採用的策略。
- 最後檢查目標服務本身的回應與帳號條件。
發生逾時時，可先比較另一台你已備妥且確認可用的伺服器，再比較另一種可控制的網路。比較時維持目標與設定不變，才能判斷差異來源。若切換網路後相同端點恢復正常，應進一步檢查原網路限制、連線狀態或路徑條件；若所有網路中只有一個端點失敗，則優先核對該端點資料與服務狀態。沒有明確依據時，不要同時修改連接埠、密碼、TLS 與 DNS，否則即使恢復也無法得知真正原因。
出現驗證或 TLS 相關提示時，請逐字核對原始資料。驗證失敗通常無法靠新增規則解決；憑證名稱不相符，也不應透過任意放寬驗證來掩蓋。檢查裝置日期與時間是否正確，確認 SNI、連線網域與憑證要求之間的關係，並向資料提供者確認預期參數。若錯誤提示指向內容格式，先修正匯入資料，不要繼續測試同一筆錯誤項目。保留提示原文，有助於區分驗證、交握與目標回應階段。
只有部分請求失敗時，檢查請求本身
若只有某個頁面或 App 功能失敗，先確認其他目標在相同條件下是否正常。接著檢查失敗目標是否使用其他網域、不同傳輸方式或持續連線。瀏覽器快取、App 內快取與舊連線都可能保留先前結果；修改規則後應重新發出請求再比較。目標服務的登入狀態、地區設定或帳號條件也可能影響回應，不能一概歸因於用戶端故障。只有先縮小失敗範圍，才容易理解記錄中的資訊。
需要參考記錄時，只擷取足以重現問題的一小段時間。先記下測試時間、目標、目前伺服器與路由模式，再執行一次請求，接著查看相關記錄。分享前移除訂閱連結、驗證欄位、完整金鑰及與問題無關的存取內容。可提供錯誤類型、協定名稱與已進行的對照測試，但不要公開完整連線資料。常見狀態的解讀與處理方式請繼續參閱FAQ。
驗證通過後，至少重複一次相同請求，並確認設定與伺服器選擇沒有因更新操作而改變。對於需要長期使用的情境，也應觀察網路切換後的行為，但不要將網路切換測試與首次連線混在同一輪。建立簡短的基準紀錄：使用哪個網路、哪台伺服器、何種模式，以及哪個目標可以正常完成。下次發生異常時先重現這組基準，通常比從頭重填所有參數更快，也較不會破壞原本可用的設定。
Data 流量：先了解統計範圍，再判斷請求去向
Data 用於檢視 App 記錄的流量，不是獨立的網路品質結論。查看數值前，先確認目前顯示的統計範圍、對象與時間區間。依伺服器檢視時，關注不同連線端點承載的流量；依 App 檢視時，關注可歸屬至 App 的通訊。不同檢視方式的歸屬方法與涵蓋範圍可能不同，不能因兩處數值不一致就推斷統計錯誤。先閱讀目前檢視頁的標籤，再將數據與剛才執行的操作對照。
上行與下行分別代表什麼
上行是從裝置送出的資料，下行則是裝置接收的資料。開啟頁面通常以下行流量為主，但請求標頭、驗證、確認與控制通訊同樣會產生上行流量；上傳內容時則可能明顯增加上行流量。數值大小取決於使用的服務，不能只因某個方向的數值成長較慢就判定發生故障。維持連線、重試與背景活動也可能產生流量，即使前景沒有主動開啟頁面，統計仍可能變動。縮短測試時間，會更容易辨認目標操作所帶來的增量。
總量與速率也要分開理解。累計總量表示所選統計區間內的資料量，瞬間或短期速率則描述某段時間的傳輸變化。過去累積的總量不會因目前連線停止而自動消失，因此不能以總量仍存在來證明連線仍在運作。反過來說，短暫看不到速率，也可能只是請求已完成。觀察一次完整操作時，應記錄開始前與結束後的變化，不要只截取某一刻的數值。
以增量驗證，不要靠總量推測
- 確認目前伺服器、Global Routing 與設定，暫停無關的大量流量操作。
- 記下目標統計項目的目前數值，確認是否屬於本次觀察範圍。
- 只執行一次可重複的目標操作，等待完成或出現明確錯誤。
- 返回 Data 查看變化，再對照請求記錄確認所用策略。
若某台伺服器的統計增加，只能說明有通訊流量被計入該項目，不一定全都來自剛才開啟的頁面。背景同步、通知或其他 App 活動都可能同時發生。若數值沒有增加，也應檢查請求是否命中 DIRECT、是否沿用舊連線、是否直接讀取快取，以及目前是否選對檢視對象。Data 可提供觀察線索；要確認實際命中的規則，仍應對照目前設定與相關請求記錄，不能要求統計數據表達它無法直接呈現的資訊。
交叉查看伺服器與 App 統計
伺服器檢視適合確認更換端點後是否開始出現新的通訊，也可檢查某個原本不再使用的項目是否仍有活動。App 檢視則適合觀察某項 App 操作是否伴隨流量增加，但顯示方式會受到目前系統與 App 可取得資訊的影響。無法準確歸屬的內容不應勉強算到某個 App 名下。兩種檢視可協助縮小問題範圍，但不應視為數值必定相等的兩份帳單；統計口徑不同，直接相加或相減可能沒有意義。
使用 Config 時，部分請求會依規則直接連線，部分則使用 PROXY，因此伺服器流量與裝置整體用量通常不是同一概念。目前服務商顯示的用量也可能採用自訂計量方式、結算週期或流量處理規則。即使 App 統計、系統網路統計與伺服器端統計都有資料，也可能因起訖時間、協定額外負載與歸屬範圍而不同。比較前應先對齊時間與對象，不要只憑一次差異就判定資料異常。
統計清除與長期觀察
若目前介面提供清除統計的操作，執行前先確認影響的對象與範圍。清除本機統計不等於重設服務商用量，也不會刪除伺服器或取代訂閱更新。若需保留歷史資料以便比較，先記下相關結果，再開始新的測試週期。長期觀察宜採用固定條件，例如相同類型的操作、相近的網路與相同的路由模式；條件差異較大時，應分開記錄，不要硬放在同一趨勢中解讀。
統計數據與實際使用情況不一致時，回到上一章依層面排查：有流量但頁面失敗，可能是驗證後的目標請求、資源網域或回應內容出了問題；頁面正常但目標伺服器統計沒有變化，則可能是命中直連或使用快取。保留這些可能性，比立即清除統計或反覆切換伺服器更有幫助。更詳細的檢視說明請參閱Data 頁依伺服器與 App 檢視數值說明；閱讀時仍應以目前介面的實際標籤為準。
Settings 常用項目：On Demand、DNS 與診斷範圍
調整 Settings 中的選項時，應以明確需求為依據，不要一次開啟所有開關。有些設定會影響系統何時觸發連線，有些影響解析或記錄，另一些行為則由目前的 Config 決定。修改前先確認設定的影響範圍：只影響目前伺服器、目前設定，還是整個 App 的行為。介面編排可能隨 App 更新調整；查找時請以英文項目名稱與實際說明為準。若目前介面沒有某項設定，不要依照其他裝置的截圖硬找相同位置。
On Demand：連線觸發條件不同於規則分流
On Demand 用於依照已設定的條件觸發連線。它處理的是何時要求建立連線，而不是決定某個網域要使用哪種策略。規則分流仍由 Global Routing 與目前設定決定；兩者可以搭配使用，但不能互相取代。啟用前先確認手動連線穩定，否則自動觸發只會讓尚未解決的問題更難觀察。需要自動化行為時，先明確列出哪些網路條件應觸發連線、哪些條件應保持中斷，再逐項設定與測試。
測試 On Demand 時，應觀察一次完整的網路變化流程。記下變化前的連線狀態，觸發預期條件後，查看系統是否開始連線，以及實際請求是否成功。不要只因開關已開啟，就認定條件設定正確。手動中斷後又重新連線，可能是既有觸發條件所致，不一定代表 App 無法關閉。若要暫時停止自動連線，先檢查 On Demand 狀態與條件，再手動中斷；之後依原本需求恢復設定。
On Demand
Global Routing
Config
Connectivity Test此處列出的是核對項目名稱，不是可匯入的設定。排查自動連線時先看 On Demand；排查請求去向時再看 Global Routing 與 Config；排查實際連線能力時則使用 Connectivity Test，並發出實際服務請求。分開記錄不同設定，可避免用修改規則來處理自動重新連線，或用關閉自動觸發來處理特定網域的策略錯誤。每項變更都應能回答一個明確問題。
DNS：先判斷是否為解析問題，再修改設定
DNS 負責將網域轉換為後續連線所需的位址資訊，解析結果可能影響位址類規則與連線流程。若網域無法存取而其他請求正常，DNS 解析是其中一項檢查方向，但不是唯一原因。先比較同一網域在目前設定下能否取得解析結果，再依連線錯誤判斷下一步。不同設定可能已包含解析相關項目，同時修改多個位置容易弄不清楚設定如何互相覆蓋。請先確認目前生效的設定並記下既有值，再進行單項比較。
不要把任意解析服務位址當成通用修正值。解析路徑、伺服器可達性、加密方式與規則都需要一併考量；某個數值在一種網路可用，不代表適用於所有網路。修改後應重新發出請求，必要時排除舊解析結果與舊連線的影響，再比較相同目標。若結果沒有改善，請還原原設定並繼續檢查，不要逐層疊加嘗試過的數值。私有網路中的名稱也可能依賴本地解析條件，調整時應保留這項需求。
記錄、憑證與按需啟用的功能
診斷記錄應依問題需求開啟，取得足夠資訊後再評估是否繼續保留。詳細記錄可能包含存取網域、時間與連線資訊，匯出或傳送前應先移除敏感內容。對於會改變加密流量處理方式的憑證相關功能，應先了解信任範圍、適用目標與還原步驟。一般伺服器連線與規則分流的入門流程，不需要為了「設定齊全」而預先安裝額外憑證。只有在有明確除錯需求時才進行操作，並確認相關 App 與服務允許這種方式。
涉及 UDP、IPv6 等行為時，也應先確認伺服器協定與目前網路是否支援，不要只調整用戶端一側。若某項服務依賴特定傳輸方式，可在其他條件不變的情況下測試相應功能；伺服器端不支援的能力，無法靠任意開關補足。IPv6 位址規則應使用相應類型，並一併檢查實際解析結果。若問題只在某種網路出現，先比較網路能力與路徑差異，再決定是否需要修改設定。
完成設定後重新檢查 Home：目前伺服器是否正確、Global Routing 是否已恢復預期模式、設定是否仍為目標檔案。接著分別測試一般請求與需要特殊設定的請求。這樣收尾可及早發現「某項功能修好了，日常連線卻被臨時設定改變」的情況。長期穩定使用不取決於設定項目多寡，而在於每個啟用項目都有明確用途、可驗證的結果與已知的還原方式；沒有實際需求的項目可以維持原狀。
日常維護：更新、備份、換機與可重複的排查流程
穩定使用後，維護重點會從「如何連線」轉為「如何追蹤變更」。App 更新、訂閱更新、設定更新與伺服器選擇是不同操作，應分別記錄。App 透過 App Store 更新；訂閱更新會取得伺服器資料；設定更新會變更規則或相關項目；選擇伺服器只會更改目前使用的對象。不要因其中一項更新成功，就假設其他內容也已同步。發生問題時先確認最近變更的是哪個層面，通常能大幅縮小排查範圍。
更新前保留基準，更新後核對項目
更新訂閱前，先確認目前連結的來源與既有可用項目，必要時記下正在使用的伺服器名稱。更新後檢查列表是否新增、移除或重新命名，以及目前選取項目是否仍指向預期對象。若列表變動導致自訂策略引用失效，可能需要修正规則或策略關係，不一定要重新匯入 App 的所有資料。訂閱驗證、有效期限或回傳內容若有問題，請向你的服務商確認；本手冊只說明如何匯入與維護既有資料。
更新設定前先保留可還原的副本，並區分遠端內容與本機修改。若在可能遭更新覆蓋的設定中加入個人化規則，請記下這些規則的用途與位置，更新後逐項確認是否仍存在。不要未經檢查就把舊設定的所有內容貼回新檔案，以免恢復已不適用的項目。較穩妥的做法是先驗證更新後的基本行為，再依需求補回少量本機例外，每新增一項就用固定目標重新測試。
備份應涵蓋彼此關聯的項目，不只儲存一個檔案
實用的備份說明應包含伺服器或訂閱來源、目前設定名稱、Global Routing 模式、必要的本機規則與重要設定。只儲存設定檔不一定包含所有驗證資料；只儲存訂閱連結，也不一定包含本機編輯內容與系統權限狀態。使用 App 目前提供的匯出或備份功能時，先確認實際包含哪些項目，再決定是否需要另外記錄。備份檔可能包含敏感資訊，應存放在由自己控制且有存取保護的位置。
備份完成後應確認內容可讀，不要等到換機時才發現檔案遺失。可先檢查檔案是否存在、格式是否正確，以及重要項目是否齊全；驗證時不需要覆蓋目前正在使用的環境。金鑰、密碼與完整訂閱網址不宜直接寫入公開筆記或截圖。需要記錄排查過程時，可用資料名稱或存放位置取代完整憑據。若發現敏感連結曾經公開，請向資料提供者確認如何更換或撤銷，再同步更新本機引用。
換機時依取得、匯入、權限、驗證流程重新操作
新裝置上先從 App Store 重新取得 Shadowrocket，再確認備份或裝置還原帶回了哪些內容。伺服器列表、設定檔與系統 VPN 授權都需要分別核對，不要假設舊裝置的系統狀態可以原樣轉移。匯入資料後，先完成手動連線並驗證固定目標，再恢復 On Demand 等自動功能。iPhone 與 iPad 的使用差異，重點在於核對目前頁面與選取項目，不要照著舊裝置的螢幕位置機械式點選；系統需求與購買範圍仍以 App Store 頁面標示為準。
新裝置完成驗證前，可暫時保留舊裝置以便對照參數，但要避免在比對時誤改兩邊的資料。確認新裝置可正常使用後，再依個人需求處理舊裝置上的驗證資料、訂閱與備份檔案。重新安裝 App 不應成為一般故障排查的第一步，因為可能清除本機設定，並增加額外授權工作。只有確認需要重建環境且資料可以還原時，才考慮重新安裝；購買項目還原問題請參閱已購項目還原章節。
建立精簡的排查紀錄
長期維護時可保留簡短紀錄：發生時間、網路類型、目標請求、伺服器、路由模式、設定名稱、錯誤原文，以及最近一次有效變更。紀錄不必包含存取內容與驗證資訊，只要能重現當時條件即可。每次異常先嘗試已知基準，再比較最近變動；一次只修改一項，明確訂出成功標準，測試後還原無效變更。這類紀錄比「已經試過很多方法」更容易重複使用，也能減少下次遇到相同問題時的重複工作。
需要快速重新走過連線流程時，請使用快速上手教程；需要查詢特定問題時，請前往FAQ；需要核對購買與 App 身分時，請返回App Store 下載指南。本頁章節順序也可作為維護清單：先確認 App 與資料來源，再核對權限與匯入，接著檢查路由與驗證，最後解讀統計與設定。釐清這些層面，日常調整就能依據實際狀況進行，而不是反覆重設或猜測。