01 / APP STORE
App Store 正版購買與付款確認
先確認應用程式，再完成購買
Shadowrocket 是僅於 Apple 平台發行的付費用戶端，唯一取得管道是 App Store。購買前，請先開啟本站的App Store 正版核對頁，確認應用程式名稱、開發者與 App ID，再前往商店完成購買。不要只憑搜尋結果中的名稱判斷應用程式身分；名稱相近或圖示相似，都不能取代產品頁資訊。商店中的介紹、相容性、價格與購買確認畫面，才是目前購買條件的依據。
核對正版時，請同時檢查三項資訊：開發者為 Shadow Launch Technology Limited，App ID 為 932747118，圖示須與本站使用的官方圖示一致。可從產品頁網址末尾的 id932747118 辨認 App ID。請在商店產品頁確認開發者名稱，不要以搜尋摘要或其他頁面的描述代替。完成核對後，再確認目前登入的購買帳號，以及付款確認畫面顯示的金額，避免混淆應用程式辨識與帳號核對。
了解一次買斷的適用範圍
用戶端一次買斷 ≠ 連線方案。購買 Shadowrocket 取得的是用戶端使用資格；連線仍需使用者已有的訂閱或伺服器資訊。本手冊只說明匯入、設定與排錯，不提供、銷售或推薦節點或訂閱。用戶端負責讀取參數、建立連線並執行分流規則；遠端伺服器是否可用、授權是否有效、連線容量如何，則屬於其他條件，不能據此推定「已購買應用程式」就能連線。
美國商店的價格約為 2.99 美元，採一次性付費；實際金額、幣別與購買條件請以 App Store 頁面標示為準。商店地區不同，顯示價格與商品可見性也可能不同，付款前請以自己帳號目前商店的確認畫面為準。不要將訂閱連結的有效期限與用戶端購買混為一談：前者代表遠端存取授權，後者則與應用程式購買記錄相關。兩者應分別保存記錄，也應分開判斷問題。
確認裝置相容性與商店地區
本手冊主要以 iPhone、iPad 為操作裝置。Mac、Apple TV、Apple Vision 的相容性也可在同一個 App Store 產品頁的相容性欄確認；系統需求與購買適用範圍一律以 App Store 頁面標示為準。不要只因使用同一個 Apple ID，就假設所有裝置與系統組合都符合條件。準備換裝置時，請先在目標裝置查看產品頁是否顯示相容，再確認購買記錄是否屬於目前用於商店購買的帳號。
搜尋不到應用程式時，先分辨是「搜尋沒有結果」，還是「產品頁提示目前商店無法使用」。請檢查帳號所屬商店，重新開啟正確的產品頁，並記下提示文字；反覆修改網路設定通常無法解決商店地區問題。帳號的商店地區與裝置語言是不同設定，變更介面語言不等於變更購買商店。詳細核對方式請參閱App Store 地區與商店可見性說明。
安裝完成後的檢查項目
安裝完成後，請先確認能否正常開啟應用程式，再設定權限與連線。完成購買不代表已匯入訂閱，也不代表系統已建立連線；這些是後續要分別完成的步驟。應用程式更新由 App Store 管理，更新記錄也應在商店中查閱。初次使用不必急著調整大量設定，先保留初始狀態，分別確認商店取得、應用程式啟動、匯入伺服器與實際連線，之後發生問題才能判斷是哪個環節出錯。
02 / PERMISSIONS
首次啟動與系統連線權限
區分應用程式開關與系統授權
首次啟動後，先查看 Home 中是否已有伺服器記錄。清單空白代表尚未匯入資訊，屬於正常狀態，不能據此判定應用程式異常。Shadowrocket 建立系統層級連線時，需要使用系統提供的 VPN 設定功能；首次嘗試連線時，系統可能會顯示新增 VPN 設定的確認畫面。這項確認是允許應用程式在裝置上建立網路通道，並非遠端伺服器登入畫面，也不代表已取得可用的伺服器或訂閱。
出現系統確認畫面時，請核對提示是否與目前使用的 Shadowrocket 相關，再依裝置要求完成確認或身分驗證。系統密碼、生物辨識與伺服器密碼用途不同，不應混用。若先前拒絕授權，請回到應用程式重新執行連線操作，查看系統是否再次提示；如需檢查既有設定，可在系統設定中尋找 VPN 相關項目。實際路徑會隨系統介面變動，請以裝置上顯示的內容為準。
權限失敗時，先確認問題發生在哪個環節
如果應用程式開關一開啟就立即跳回，請先檢查是否有尚未完成的系統確認、裝置管理限制，或其他正在建立的 VPN 連線。不要直接認定是訂閱失效，因為此時可能尚未連線至遠端伺服器。受管理裝置的網路權限可能由管理政策決定，遇到限制時應先確認裝置政策。不要連續點擊開關強制重試；請先結束目前的連線要求，等系統狀態穩定後，再記錄具體提示。
如果系統中已有設定，但應用程式仍提示授權問題，可先中斷連線，查看系統中的對應設定是否仍屬於 Shadowrocket，並確認沒有誤選其他設定。修改或移除系統設定前，請先保存自己的伺服器與設定資料，並了解移除後需要重新授權。刪除整個應用程式不是排查權限問題的第一步，因為應用程式本機資料與系統設定的生命週期不同；貿然重新安裝，可能讓單純的授權問題變成資料復原問題。
依操作需求授予其他權限
使用 Scan QR Code 時，系統可能會要求相機存取權限；只有透過掃描方式匯入時才需要處理這項權限。若先前拒絕相機存取，可到系統的應用程式權限設定中檢查，不必反覆掃描。掃描相簿中的圖片與直接使用相機，可能會出現不同的存取提示，請依目前操作需求處理。QR Code 通常包含完整連線參數，確認來源後再匯入；排錯時不要公開傳送原始 QR Code。
貼上訂閱連結時，系統可能會顯示剪貼簿相關提示。請確認剪貼簿內容是自己準備匯入的資料，避免複製到聊天文字、換行或多餘標點。若需讀取本機或雲端檔案，請先在系統檔案選擇畫面找到目標檔案，再核對匯入結果。授權只代表允許存取相應資源，不能驗證檔案內容是否正確；授權成功後，仍應檢查伺服器數量、名稱與重要參數是否符合預期。
首次使用時建立清楚的基準
第一次設定建議在穩定的本地網路下進行，暫時不要同時啟用複雜的 On Demand 條件或大量修改 DNS。先完成一筆容易辨識的伺服器項目，再選擇 Global Routing，最後嘗試連線。如此可分開處理「無法匯入」、「無法建立系統連線」與「連線後請求失敗」。如果裝置已有網路過濾或其他 VPN 設定，也請記錄目前狀態，並在測試期間只保留本次需要確認的連線條件。
授權完成後，重點不在系統是否顯示某個固定圖示，而是應用程式連線狀態、系統 VPN 狀態與實際請求結果是否一致。不同裝置顯示狀態的方式可能不同，不應只憑狀態列沒有常駐圖示就判定失敗。請記下此時的網路類型、所選伺服器與授權結果；下一章匯入更多資料後，仍可回頭對照這組基準，判斷變化來自新增資料還是系統層級設定。
03 / SERVER & SUBSCRIBE
新增伺服器與匯入既有訂閱
先判斷手邊資料的類型
開始匯入前，先確認自己已有的資料是單一伺服器參數、分享連結、QR Code，還是可回傳多筆伺服器項目的訂閱連結。這些格式不能只憑外觀相似就互相替代：伺服器位址描述連線目標，訂閱位址用來取得項目清單，而設定檔也可能包含規則與其他設定。如果把訂閱位址填入伺服器位址欄，即使資料完整也無法如預期運作。若不確定資料用途，應先核對原始說明，不要逐一嘗試每個輸入欄位。
使用 Add Server 手動新增時，先選擇與既有資料相符的協定類型，再填寫對應欄位。位址通常只填主機名稱或 IP，連接埠請另填，不要把網頁路徑一起貼進位址。密碼、UUID、加密方式與其他選項應逐項核對，留意大小寫、前後空格與輸入法標點。為項目設定容易區分用途的名稱，避免多筆同名記錄造成選取錯誤；名稱只能協助辨識，無法修正錯誤的連線參數。
依協定核對必要參數
協定類型決定欄位的解讀方式。同一個連接埠號碼或同一組密碼，不代表可直接套用到不同協定。Shadowsocks 需要符合加密方式與密碼；VMess、VLESS 的身分欄位與傳輸條件須一併核對；Trojan 的密碼則與 TLS 條件相關。HTTP、SOCKS5 的驗證資訊應依既有資料填寫，不能套用其他協定的欄位意義。遇到 WireGuard、Hysteria2 等類型時，也應以完整原始參數為準，不要自行猜測預設值。
匯入 Subscribe 並檢查結果
匯入既有訂閱時，請在新增介面選擇 Subscribe，填入完整訂閱位址並儲存，接著更新訂閱，確認是否產生預期的伺服器項目。訂閱位址中的查詢參數通常是存取憑證的一部分，不要任意刪除、重新排序或替換。複製時特別留意末尾字元是否遺失、通訊軟體是否截斷連結，以及開頭或結尾是否混入說明文字。匯入成功後，請先選擇其中一個項目測試，不要只因清單出現就認定所有項目都已驗證。
訂閱更新失敗時，先分辨是位址無法存取、回傳內容無法辨識，還是遠端授權已失效。保留錯誤提示並核對完整連結，再比較目前網路是否能取得訂閱內容。有時既有伺服器仍可連線，但訂閱暫時無法更新，這表示更新請求與既有項目的連線是不同流程。不要立刻刪除整個群組；先保留可運作的項目，再檢查訂閱取得條件，避免同時失去可用連線與排錯依據。
掃描、更新與資料保護
透過 Scan QR Code 匯入後，仍須檢查協定、位址、連接埠與驗證欄位；QR Code 辨識成功只代表讀取到文字，不代表內容完整或仍然有效。訂閱更新可能改變項目名稱、數量或順序，因此不宜只靠清單位置記住常用伺服器。若需手動調整項目，請先確認下次訂閱更新是否會覆蓋變更；必要時保存獨立副本並清楚命名，避免誤以為臨時修改已永久改變訂閱來源。
訂閱連結、分享連結與 QR Code 都可能包含存取授權，應視為憑證妥善保管。排錯時可以描述協定、錯誤類型與發生階段，但不要公開完整密碼、UUID 或訂閱查詢參數。匯入完成的最低檢查條件是：清單項目來源清楚、重要參數能與原始資料對應，且至少選取一個目標。接著再設定 Global Routing；若只需要完整操作示範，請前往快速入門中的 Subscribe 匯入說明。
04 / GLOBAL ROUTING
Global Routing 三種模式與規則順序
先選擇模式，再檢查命中結果
Global Routing 決定如何處理請求，介面中的三種模式是 Config、Proxy、Direct，分別代表依設定、代理、直連。Config 依目前設定中的規則選擇策略；Proxy 會將納入處理範圍的請求交由目前選取的伺服器處理；Direct 則直接連線。三者代表請求處理方式，不是三組伺服器，也不會改變遠端帳號本身。排錯時務必先記下目前模式，否則同一條規則在不同模式下可能看起來像是沒有生效。
日常使用 Config 時，應先確認目前啟用的是哪份設定，而不只是確認 Config 清單中有檔案。儲存檔案、編輯檔案與啟用檔案是不同操作。修改規則後，請依應用程式提供的方式儲存並套用，再發出新的測試請求；既有連線可能仍沿用先前狀態。Proxy 可協助隔離部分規則問題，但測試結束後應恢復原本需要的模式，避免長期保留臨時排錯狀態。
規則依序判斷，最後一條規則負責兜底
一般規則會依設定中的順序逐一判斷，較具體的目標應排在較寬泛的規則之前。DOMAIN 用於完整網域，DOMAIN-SUFFIX 用於網域後綴及其子網域，DOMAIN-KEYWORD 依網域中的關鍵字判斷。IP-CIDR、IP-CIDR6 用於處理位址範圍，GEOIP 則依 IP 地理分類資料判斷。規則類型決定比對對象，最後的策略決定命中後如何處理，兩者不可混為一談。
[Rule]
DOMAIN,api.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXY
上述片段僅用來說明規則順序，不是適用所有網路的完整設定。存取 api.example.com 時，第一條規則已命中，後面的網域後綴規則不會再決定該請求；其他屬於 example.com 的目標則可能由第二條規則處理。最後的 FINAL 表示前面都未命中時採用的策略，應放在末尾。範例網域僅供教學使用，複製前請先確認實際需要處理的目標，不要把範例當成已驗證的業務規則。
了解策略、解析與規則適用範圍
PROXY、DIRECT、REJECT 是常見的處理策略，規則中也可能引用設定內已定義的策略群組。引用名稱必須與實際定義一致；只填入不存在的名稱，不會自動建立策略群組。若要拒絕某個目標，請先縮小比對範圍，並確認該目標是否同時承載登入、驗證或其他資源，避免寬泛規則影響正常功能。排錯時優先使用具體網域，不要急著擴大到關鍵字或整段位址範圍。
網域規則與位址規則依賴的資訊不同。請求帶有網域時，可依網域判斷；只有位址資訊時，則可能進入位址相關判斷；部分規則也可能涉及額外解析。DNS 回傳位址、快取與請求類型都會影響觀察結果，因此不能只看目標名稱就推斷一定會命中哪條規則。USER-AGENT 等條件也有適用範圍，不要假設所有加密請求都會提供相同的應用程式層欄位。
設定越複雜，越需要保留可復原的基本檔案。建議每次只新增一組規則，記錄預期命中的目標與實際策略，再決定是否繼續新增。發生異常時，先檢查檔案是否已啟用、規則順序是否正確、策略名稱是否有效，最後再考慮擴大修改範圍。能說明一項請求為何命中某條規則，比單純累積大量規則更有助於維護。
05 / CONNECT & VERIFY
建立連線與分層驗證
建立可重複的測試
連線前先固定三項條件：所選伺服器、Global Routing 模式與目前的本地網路。確認伺服器來自自己持有的有效資料，選擇明確模式，再開啟連線開關，並完成尚未處理的系統授權。測試期間不要同時切換伺服器、更新訂閱及修改 DNS，否則即使請求恢復，也難以判斷是哪個步驟發揮作用。先用少量且可重複的請求建立基準，後續比較才有實際意義。
完整驗證至少包含三個層次：系統連線是否建立、目標請求能否完成，以及實際處理策略是否符合預期。系統顯示已連線，只代表本機通道處於運作狀態，不能證明遠端伺服器能完成驗證或存取目標。網頁能開啟，也不一定代表流量經由所選伺服器；在 Config 模式下，請求可能命中 DIRECT。因此驗證結果應同時記錄「能否存取」與「採用何種策略」，不能只留下成功或失敗的結論。
如何運用 Connectivity Test 結果
Connectivity Test 可協助比較各項目的基本連通情況，但應先確認選用的測試方法。不同方法可能只檢查連線建立、特定目標的回應或部分協定階段，測試結果不應直接等同於日常下載速度。單次測試逾時，也可能與測試目標、網路短暫變化或伺服器處理測試方式有關。建議在相同網路與測試條件下少量重複測試，再搭配實際請求判斷。
低延遲不代表高傳輸量，成功建立連線也不代表所有業務請求都正常。若基本測試正常但某個頁面失敗，應繼續檢查目標網域、規則、DNS 與相關資源，不要立即否定整台伺服器。反之，若多個互不相關的目標都失敗，且在 Proxy 模式下也無法完成請求，就應優先核對位址、連接埠、驗證資訊與遠端狀態。測試工具能提供線索，不能取代對失敗階段的判斷。
依失敗現象選擇下一步
無法上網時，可先在中斷連線的狀態下確認本地網路能否正常完成請求，再使用同一台伺服器重新連線比較。如果本地網路需要網頁驗證，請先完成驗證。比較 Proxy 與 Config 時，只改變模式：Proxy 正常但 Config 異常，應優先檢查規則、策略引用及設定是否啟用；兩者都異常，再檢查伺服器與連線條件。這種對照無法涵蓋所有原因，但能有效縮小排查範圍。
區分「速度慢」與「連線失敗」
速度問題應在連線已可使用的前提下分析。先固定測試內容與時段，再區分遠端伺服器、本地網路、傳輸條件與目標服務本身的限制。傳輸大型檔案與短暫網頁請求關注的指標不同，不能用小型請求的回應時間推斷持續傳輸能力。比較時盡量避免其他裝置或應用程式同時占用網路，測量期間也不要反覆更改協定選項，以免失去比較基準。
驗證完成後，記錄最後使用的伺服器、模式、設定名稱與網路類型，還原日常所需設定，並重新發出一次請求。若需深入排查，請參閱已連線卻無法上網的逐項檢查；若持續遇到速度不足，可參考節點、線路、協定與本地網路的分層判斷。記錄應包含現象與條件，不要包含完整存取憑證。
06 / DATA
Data 流量與請求記錄的判讀方式
先確認統計範圍與時間區間
Data 用於查看應用程式實際提供的流量與連線資訊。查看數字前，先確認目前介面顯示的是本次連線、特定時間範圍或累計資料，並查看是否有重設操作。不同統計口徑不能直接相減比較，重新連線後的變化也不一定代表所有歷史記錄已清除。應用程式介面的實際欄目以畫面顯示為準，不要根據其他裝置的截圖推斷自己一定有相同的統計畫面或記錄保留方式。
上行與下行描述資料傳輸方向，不等於上傳檔案與下載檔案兩種操作。開啟網頁同樣需要送出請求，傳送檔案也會收到確認與回應。協定封裝、重傳、連線維持與名稱解析都可能產生流量，因此介面統計值未必與檔案大小相同。若要估算某項操作帶來的變化，可在其他活動較少時記錄操作前後的數據，但應視為近似觀察，而不是精確的遠端計費依據。
用戶端統計不能取代遠端帳戶記錄
Shadowrocket 中的統計反映用戶端可觀察到的活動，遠端訂閱的計費與用量可能採用不同口徑。如果裝置還有其他直接連線、多人共用同一個遠端帳戶，或統計時間不同，兩邊的數字更不能直接對照。訂閱顯示的剩餘流量也可能來自遠端回傳資訊，其更新頻率與用戶端即時計數不同。遇到差異時，先比較時間區間與裝置範圍，再判斷數據是否異常。
若要確認某個應用程式是否採用預期策略，應同時查看請求目標與規則命中資訊，不要只看總流量增加。總量變化只能表示發生了網路活動，不能直接歸因於某項前景操作。系統背景同步、頁面預載與其他應用程式更新都可能同時發生。為減少干擾，可先停止不必要的活動，再進行一次短而明確的操作並記下時間，之後查看該時段附近的請求與策略。
透過請求資訊定位規則與解析問題
若目前介面提供連線或請求詳細資訊，可優先查看目標網域或位址、使用的策略、相關伺服器與錯誤階段。網域與位址是不同類型的線索：前者有助於判斷網域規則，後者有助於核對位址範圍與解析結果。一個頁面通常會存取多個目標，主文件載入成功不代表圖片、登入驗證與其他資源都採用相同路徑。若只有部分內容無法載入，應找出失敗的具體資源，而不只是新增頁面主網域。
修改規則後，應重新發出請求再觀察結果。瀏覽器既有連線、應用程式快取與 DNS 快取都可能保留舊狀態，讓人誤以為新規則沒有生效。先結束目前的測試操作，必要時關閉並重新發出相應請求，再檢查新記錄。清除記錄前，請先保存有價值的錯誤階段與時間資訊；若直接清空後重試，而問題暫時消失，就可能失去唯一能說明故障的線索。
排查流量增加與背景活動
發現背景流量持續增加時，先確認連線持續時間、裝置上的同步工作與 On Demand 條件。常駐連線可能包含維持連線的通訊，但不能只憑總量增加就判定設定有問題。將觀察時段縮短至容易重現的範圍，比較螢幕使用、背景同步與網路切換是否和流量變化一致。耗電也不能只用流量數字解釋，還與連線喚醒、無線網路狀態及裝置工作有關，應分開記錄。
需要向他人描述問題時，優先提供整理過的時間、目標類型、策略與錯誤文字。請求記錄可能包含使用習慣、完整位址、查詢參數，甚至驗證資料；分享前應刪除不相關內容。不要為了方便就一併傳送所有記錄與訂閱資料。完成診斷後，請將額外開啟的詳細記錄恢復至日常所需範圍，既方便後續閱讀，也能減少不必要的資訊累積。
07 / SETTINGS
Settings、DNS 與 On Demand 設定
先釐清設定影響的層級
Settings 中的選項並非都作用於同一範圍。有些影響應用程式行為，有些與目前連線相關，另一些則由 Config 檔案或個別伺服器項目決定。修改前先確認設定對象，並記下原本的值。如果某份設定中已有相關內容，不要直接假設介面其他位置的設定一定會覆蓋它；請先查閱目前選項說明，再透過實際請求驗證。維持可正常運作的基準，比一次啟用許多看似有用的選項更重要。
建議將設定分成三組處理：先完成連線必要項目，再調整按需連線與名稱解析，最後才考慮特定網路相關的進階選項。每次只修改一組邏輯相關的設定，儲存後測試相同目標。若結果變差，請還原該組原值，不要再新增其他修改來補救。對於尚不了解用途的開關，保留目前可用設定通常比猜測性調整更容易維護。
DNS 影響名稱解析，不會取代連線驗證
DNS 的基本作用是將網域解析為請求所需的位址。解析失敗、回傳位址不符預期，或解析服務本身無法連線，都可能造成網頁無法開啟，但這與伺服器密碼錯誤屬於不同階段。排查時先確認問題發生在解析之前還是之後，再決定要修改哪個層面。某個 IP 能建立連線，不代表該服務的所有網域請求都正常；許多服務也依賴名稱、憑證與多個資源網域，不能只用位址存取取代完整測試。
選擇或修改 DNS 時，需同時考慮解析服務能否在目前連線條件下連線，以及設定如何安排解析請求。不要只替換位址而不檢查存取路徑，也不要不斷加入來源不明的多個位址。測試時應記錄網域、回傳結果與時間，並維持其他條件不變。啟用加密解析不代表所有請求都會採用相同出口；解析路徑與業務請求策略仍須分別驗證，不能只憑一項設定推斷整條連線路徑。
On Demand 依條件觸發連線
On Demand 會依設定條件決定何時建立或維持連線，並非自動修復遠端伺服器的功能。設定前，請先明確寫下所需行為：進入特定網路時是否連線、離開後是否維持連線，以及哪些情況應直接使用本地網路。可用條件請以應用程式目前介面為準，並逐項核對條件順序與比對範圍。網路名稱相似不代表條件相同，儲存後務必在實際切換網路時驗證。
關閉開關後又自動連線時，先檢查 On Demand 是否仍在生效，不要立即認定手動開關失靈。按需規則可能在新的網路請求或網路變更時重新觸發連線。排錯期間可暫時停用相關條件，完成手動連線驗證後再逐項恢復。對於需要網頁驗證的網路，尤其應先完成本地驗證，再確認按需條件是否合適，避免連線觸發時機干擾初次接入。
連線方式的取捨與進階選項
按需連線與持續連線在使用體驗、背景活動與網路切換後的恢復方式上各有取捨，沒有適用所有裝置的統一答案。頻繁進出觸發條件，也可能增加建立連線的次數。判斷耗電情況時，應比較相近的使用時間與網路環境，不要只看單次系統統計。若需要更完整的比較方式，可閱讀On Demand 與背景耗電的設定取捨，再依自己的實際使用方式決定。
涉及 IPv6、UDP、連線逾時或其他網路參數時，先確認症狀確實與該選項相關。只有單一請求失敗，不足以證明需要全域停用某項功能；修改範圍越大，越可能影響原本正常的請求。優先進行小範圍測試，並保存修改前後的結果。設定完成後，至少驗證一次重新連線與一次網路切換，確保不是只有目前尚未結束的連線看起來正常。
08 / MAINTENANCE
日常維護、換機與故障記錄
分開維護應用程式、訂閱與設定
日常維護應分別處理應用程式更新、訂閱更新與 Config 檔案修改。應用程式更新由 App Store 提供；訂閱更新會從使用者已有的位址取得伺服器項目；設定修改則會變更規則與相關行為。三者變動時可能互相影響，但不是同一項操作。為方便定位問題，盡量不要在同一次測試前同時完成所有更新；先確認目前連線可用並記錄狀態，再分階段操作，每個步驟完成後都做一次簡短驗證。
訂閱更新後，請核對項目數量、常用伺服器是否仍在，以及目前選取項目是否變更。不要只因名稱相同就認為參數沒有變，也不要因清單順序改變就誤以為項目遺失。若某項目由訂閱維護，手動修改可能會在後續更新時被覆蓋，應區分臨時測試與日常使用項目。可定期清理重複、失效且已確認不再需要的記錄，但問題尚未定位前，不宜大量刪除資料。
保留可復原的設定與資料
修改 Config 前，請先保存一份可正常運作的副本，名稱標明用途即可，不必堆疊難以區分的「最終版」標記。備份不只要包含規則文字，也應註明哪些參數來自伺服器項目、哪些由訂閱更新提供。密碼、UUID 與完整訂閱位址等資料應存放於受保護的位置，避免放入公開筆記。復原時先確認內容適用範圍，不要不加判斷就將某部裝置上的所有設定套用到另一部裝置。
換機前，請分別確認應用程式購買帳號、既有伺服器資料與設定檔是否能重新取得。復原 App Store 購買與還原應用程式內部資料是兩件不同的事：前者關係到能否重新取得用戶端，後者則決定能否找回原有連線條件。請使用原購買帳號，在 App Store 的已購項目中尋找 Shadowrocket；系統需求與購買適用範圍請以 App Store 頁面標示為準。詳細步驟請參閱已購項目復原說明。
重新安裝前，先建立精簡的排錯記錄
遇到故障時，先記錄發生時間、裝置網路類型、Global Routing 模式、設定名稱、伺服器協定與錯誤階段。說明問題是訂閱無法更新、系統連線無法建立，還是連線後特定目標失敗。先將問題縮小為一項可重複的操作，再進行對照測試，會比「全部重設後再看看」更容易得到有用結論。記錄中可用自訂代號代稱伺服器，避免洩露實際位址與驗證欄位。
重新安裝不是一般排錯的第一步。移除應用程式可能導致本機資料、記錄與已保存的除錯線索無法繼續使用，而遠端驗證錯誤、網路條件或規則邏輯問題不一定會因此改變。請先嘗試還原最近一次可用的設定、停用臨時新增的條件，並依連線章節的順序逐項檢查。確實需要重新安裝時，應先確認所有必要資料都能重新取得，再進行操作；不要把「商店仍可下載」誤當成「應用程式內部設定已備份」。
建立可重複執行的維護流程
每次維護可依固定順序進行：確認基準、保存資料、執行一項變更、測試代表性目標、檢查實際策略，最後記錄結果。代表性目標應涵蓋自己確實需要的幾類存取，不必一次開啟大量無關頁面。正常結果也值得簡短記錄，因為下次發生異常時，需要知道上次正常使用時的條件。若測試時暫切至 Proxy，結束後記得恢復日常模式，並確認 On Demand 條件符合原先規劃。
分享排錯資訊前，請再次檢查截圖、記錄與複製文字中是否包含敏感資料，尤其是訂閱查詢參數、驗證欄位與存取記錄。對方通常只需要知道錯誤階段與重現條件，不需要完整帳戶資料。換機或重新安裝後找不到購買記錄，可繼續閱讀換機或重新安裝後的已購項目復原方式；初次重新設定則返回快速入門教學，依單一流程建立可用連線，再逐項還原個人化設定。