Shadowrocket
完整使用手冊

02 / 首次啟動

首次啟動與系統權限

先確認操作項目，再開始連線

首次開啟 Shadowrocket 時，請先確認 Home 中是否已有伺服器項目，再查看目前的 Global Routing 與 Config。伺服器項目決定連線目的地，Global Routing 決定流量的處理方式，Config 則提供設定模式下的具體規則。主開關只負責啟動或停止連線，不會替使用者補齊這些前提。若清單為空、未選取項目或匯入失敗，請先回到新增步驟；此時反覆切換主開關，通常無法讓缺少的連線資訊自動出現。

開始前可暫時停止其他正在接管系統網路的連線，減少設定之間的相互影響。這麼做不是要刪除既有設定，而是建立清楚的測試環境：確認目前由哪個設定運作、何時開始連線，以及關閉後網路是否恢復。若裝置由學校或組織管理，系統可能限制新增或修改網路設定，請遵守裝置管理規範。不了解用途時，請勿移除組織部署的設定，也不要把管理限制誤判為伺服器參數錯誤。

了解新增 VPN 設定時的系統確認

首次嘗試啟動連線時，系統可能要求允許 Shadowrocket 新增 VPN 設定，並以裝置密碼或系統驗證進行確認。這項設定讓應用程式透過 Apple 提供的網路機制處理流量，是連線功能的一部分；它不代表已向服務提供者購買連線權限，也不表示伺服器已通過驗證。確認提示是由目前主動執行的操作所觸發，且應用程式身分正確後，再依系統流程授權。授權成功後，仍須測試伺服器是否可連線。

若先前選擇取消，請返回應用程式，確認目前項目完整後，再次嘗試啟動，以重新觸發所需的授權流程。必要時可在系統 Settings 中查看 VPN 相關項目；名稱與路徑可能因裝置系統而異，請以實際畫面為準。檢查時，請確認是否存在對應設定、是否允許啟用，以及是否有其他連線同時運作。不要為了再次顯示提示而一次刪除所有網路設定，這會擴大變更範圍，也不利於找出原本的失敗原因。

系統顯示 VPN 狀態，只表示網路設定正在運作，不等於伺服器驗證成功，更不代表特定網站一定會依預期路徑存取。設定可能已啟動，但所選伺服器無法連線；也可能伺服器運作正常，而目前規則將目標導向 DIRECT。判斷時請分別記錄系統狀態、用戶端測試結果與實際存取結果。日後遇到「開關已開啟但無法存取」時，才能判斷問題出在授權、傳輸或分流階段。

依實際功能授予存取權限

使用 Scan QR Code 時，應用程式需要存取相機，才能讀取使用者已有的設定 QR Code。若不想使用相機，可選擇符合現有資料的其他匯入方式；若先前已拒絕，可在系統 Settings 中確認相機權限。使用複製連結匯入時，系統也可能詢問剪貼簿相關權限，請確認剪貼簿內容確實是準備匯入的資料。不要混淆相機授權與主要連線授權：前者影響掃描輸入，不直接代表伺服器連線能力。

QR Code、剪貼簿與設定文字都可能包含驗證資訊。掃描前請確認來源與用途；匯入後檢查項目類型、位址與連接埠，不要因為讀取成功就認定參數正確。若 QR Code 來自自己的另一台裝置，也要確認它代表的是單一伺服器、訂閱網址，還是整份設定。不同項目的後續維護方式不同；選錯匯入入口可能導致內容無法辨識，或項目位置與預期不符，但不代表所有資訊都已失效。

首次設定的合理目標不是「開啟所有權限」，而是只授予目前操作所需的權限，並能說明各項權限的用途。完成系統網路授權後，保留一個明確的伺服器項目供測試，先各手動連線與中斷一次。暫時不要啟用自動連線條件，方便觀察狀態變化。確認手動流程可以重現後，再到 Settings 章節設定 On Demand，避免自動觸發掩蓋手動連線時已存在的問題。

03 / 輸入連線資訊

新增伺服器與匯入既有訂閱

Add Server：逐項核對連線參數

新增前先區分手邊資料：單一分享連結描述一台伺服器，訂閱網址用於取得一組可更新的項目，設定檔則可能同時包含規則與其他設定。不能只因它們看起來都是一段文字，就互相替代。資料應來自使用者自己的服務提供者或原有設定。若只有網域名稱和密碼，卻不清楚協定、連接埠或傳輸方式，請先確認完整參數；嘗試不同類型直到項目能儲存，並不能證明它可連線。

在 Home 使用 Add Server，先選擇與原始資訊相符的類型，再填入位址、連接埠與驗證欄位。位址欄通常填寫主機名稱或 IP，而不是帶有網頁路徑的網址；連接埠必須與伺服器端的監聽連接埠一致。顯示名稱僅供辨識，不參與驗證。填寫完成後請逐項複核，特別留意複製內容前後的空格、全形標點與遭截斷的字串。能夠儲存只表示輸入通過本機檢查，仍須進行連線測試才能確認是否可用。

Shadowsocks、VMess、VLESS、Trojan 等類型的欄位不盡相同，不能將某種協定的填寫方式直接套用到另一種。若原始資訊包含 TLS、Server Name、Host 或 Path，請依對應欄位保留。Server Name 可能與連線位址不同，Path 也可能區分大小寫。請勿將停用憑證檢查當成通用修復方式；若憑證名稱不符，應先核對時間、名稱與原始參數，避免繞過真正需要處理的設定問題。

Subscribe：匯入與更新是兩個階段

匯入既有訂閱時，請依訂閱類型操作。訂閱網址通常用來取得伺服器清單，而不是直接當成單一伺服器的主機名稱。匯入前請完整複製網址，特別留意問號後的參數是否保留，其中可能包含可識別使用者的敏感資訊。匯入後確認是否產生預期項目、群組是否清楚、項目數量是否合理，再選取一台伺服器測試。訂閱請求成功只表示已取得清單，不代表清單中的每台伺服器都能透過目前網路連線。

更新時會重新讀取訂閱端傳回的內容，因此由訂閱管理的項目不宜當成長期手動編輯的副本。若需暫時調整某個項目，請先保留原始資訊；必要時另存為獨立的測試項目，再觀察後續更新是否會覆蓋修改。發現重複項目時，先確認是同一訂閱匯入多次，還是手動副本與訂閱項目同時存在。未確認來源前請勿批次刪除，以免連唯一保留的有效設定也一併移除。

更新失敗時，依請求流程逐步檢查

訂閱更新失敗時，請先確認裝置的基本網路正常，再檢查網址是否完整、目前的存取路徑與伺服器端回應狀態。目前的伺服器無法使用時，透過它請求訂閱也可能失敗；了解影響後，可切換到能存取訂閱網址的路徑，再重試一次。若提示驗證或權限問題，請確認原網址是否已變更；若已取得內容但無法解析，則應確認傳回的是受支援的訂閱內容，而非登入頁面、錯誤頁面或一般說明網頁。

匯入完成後，請分別記下項目來源、目前選取項目與更新結果。單一連結與訂閱的結構差異，請參閱分享連結與訂閱網址說明。後續驗證請針對一個明確項目進行，不要同時更新整組訂閱、修改規則又調整 DNS；保持輸入資訊不變，才能判斷接下來 Global Routing 的變化實際影響了什麼。

04 / 決定流量路徑

Global Routing 三種模式與規則比對

Config、Proxy、Direct 分別控制什麼

Global Routing 是連線測試前必須確認的狀態之一。Config 依目前啟用設定中的規則處理請求；Proxy 將符合條件的流量導向代理路徑；Direct 則使用直連路徑。三種模式控制的是路徑選擇，不會變更伺服器本身的驗證資訊。若相同目標在不同模式下表現不同，請優先檢查分流路徑，而非立即重新建立伺服器。也要區分模式名稱與規則中的大寫策略關鍵字：前者是介面選項，後者是設定文字。

排查時可暫時使用 Proxy 測試所選伺服器，測試結束後應恢復預期模式。若 Proxy 可用而 Config 不可用，至少表示有規則差異值得檢查，不能直接判定訂閱損壞。Direct 可用來比較目前網路的直接存取情況，但並非所有目標都應能透過直連存取。測試結論必須註明目標與模式，單說「可用」或「無法使用」範圍不明，也無法指引下一步設定調整。

規則由上而下比對，具體條件應置於前方

Config 中的規則通常依由上而下的順序檢查，命中後採用相應策略。DOMAIN 比對完整網域；DOMAIN-SUFFIX 比對指定網域及其子網域；DOMAIN-KEYWORD 依網域中的關鍵字比對；IP-CIDR 與 IP-CIDR6 用於位址網段；GEOIP 依位址歸屬資料判斷；FINAL 則處理先前未命中的請求。規則條件範圍越廣，越容易提前攔截後續請求，因此應先安排具體條件，再安排範圍較大的條件與最終兜底規則。

以下僅為教學用的 .conf 規則片段，不能取代現有的完整設定。網域使用示例值，PROXY 則要求目前有可用的代理路徑。套用範例前，請先複製原設定，在副本中修改相應部分，並確認已啟用所選設定。只將文字儲存至檔案，不代表目前連線已讀取該內容；切換設定後，還要發出新的請求來檢查規則結果。

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN-KEYWORD,example,PROXY
IP-CIDR,192.168.0.0/16,DIRECT
GEOIP,CN,DIRECT
FINAL,DIRECT

在這段範例中，example.com 及其子網域會優先導向 PROXY；網域包含 example 的其他請求則可能由第二條規則處理。兩條規則並非同義寫法，後者的比對範圍更廣。接著依序檢查私有網段與 GEOIP 條件，剩餘流量則由 FINAL,DIRECT 處理。若將 FINAL 放在最前面，後續的具體條件便無法發揮預期作用。若將最終策略改為 FINAL,PROXY，未列出的流量路徑也會改變，不能只把它當成格式替換。

以最小幅度修改驗證分流設定

若只想讓指定網站使用代理，可保留目標 DOMAIN-SUFFIX 規則，並以 FINAL,DIRECT 收尾。不過，一個網頁可能會請求多個網域，主網域命中不代表圖片、登入或 API 請求也會採用相同路徑。若頁面只載入部分內容，請查看實際失敗的請求，再判斷是否需要新增明確的網域條件。不要以無限制擴大的關鍵字規則掩蓋問題，否則可能連原本預期直連的其他請求也一併改變。

驗證規則時應發出新請求，必要時重新建立連線，避免舊連線沿用先前路徑而造成誤判。IP 相關條件也可能受到解析結果影響，GEOIP 更無法保證精確反映特定網站的業務歸屬。更詳細的比對說明請參閱規則關鍵字說明；指定網站的設定流程請參閱白名單分流範例。每次修改後記錄「目標、命中規則、最終策略」，比只觀察連線圖示更能協助判斷。

05 / 建立連線

連線測試與故障排查順序

建立可重現的測試條件

開始連線前，請確認裝置本身可以存取已知正常的網頁、目前選取的伺服器項目明確，且 Global Routing 已設為準備測試的模式。首次驗證時，盡量固定使用同一個 Wi-Fi 或行動網路，不要在測試期間同時切換網路、更新訂閱或修改規則。記錄測試目標也很重要：網頁首頁、登入 API 與應用程式內請求可能使用不同網域，不能將其中一項成功存取的結果套用到所有網路活動。

選取伺服器後，可執行 Connectivity Test，再開啟主連線並發出實際請求。測試結果只能反映該測試方式下的可連線性與耗時，不能直接代表所有協定、所有目標或長連線情境。某些網路對測試請求與實際業務請求的處理方式不同，因此測試失敗不一定代表業務完全無法使用；反過來，測試有回應也不能證明驗證、TLS 或目標網站存取一定成功。請綜合兩種證據判斷。

分別確認「已啟動」與「可存取」

開啟主開關後，先確認系統連線狀態是否維持，再於瀏覽器發出一次新的存取請求。若開關很快自動關閉，請優先檢查系統授權、設定是否載入及錯誤提示；若狀態維持但目標仍無法存取，則繼續檢查伺服器、路由、DNS 與請求細節。不要將系統 VPN 標示視為最終驗收結果，它反映的是本機網路設定狀態；實際請求還要經過解析、連線、驗證與目標回應等環節。

頁面可以開啟時，也應確認是否符合預期路徑。在 Config 模式下，需查看個別請求所套用的規則與策略；在 Proxy 模式下，則要確認目前選取的伺服器正是準備測試的項目。若頁面內容來自快取，重新整理也可能無法證明新路徑是否正常。可改發新的明確請求，或重新開啟目標頁面。測試結束後，請恢復日常模式並再次測試，避免為排查而暫時採用的全域設定留在裝置上。

依故障層級決定下一步

第一層是目前網路：關閉連線後仍無法存取正常目標，應先處理 Wi-Fi、行動數據、入口網站驗證或裝置網路限制。第二層是伺服器：核對位址、連接埠、驗證欄位與服務狀態；在相同條件下改用另一個自己已有的項目，有助判斷是否只有單一伺服器故障。第三層是路由：若 Proxy 可存取而 Config 失敗，請檢查目前啟用的設定、目標規則與最終策略。每一層都應先得出結論，再進入下一層。

第四層是 DNS 與目標請求。若主機名稱解析失敗，連線尚未進入預期的伺服器通訊階段；若已完成解析但出現逾時，則要進一步區分連線建立、驗證或等待回應的問題。憑證錯誤應核對裝置時間、Server Name 與憑證是否相符，不宜直接停用檢查。若只有一個網站失敗，也要考慮目標本身的狀態、登入狀態與附屬網域，不應立即判定整份設定都不可用。

每次只改一項，並保留還原方式

排查時最容易失去線索的情況，是一次更換多個參數後終於「恢復正常」，卻不知道是哪項修改產生作用。建議依時間記錄原值、修改內容與結果，每次只調整一個能清楚說明的條件。若修改沒有幫助，還原原值後再進行下一步；若結果改善，則以相同測試再次確認。這也有助於辨識偶發的網路波動，避免將短暫恢復錯誤歸因於無關的開關。

需要進一步查閱時，可依連線開關已開啟但無法存取的檢查清單逐項操作。回報問題時，保留裝置網路類型、Global Routing、錯誤類別與重現步驟即可，不必附上完整驗證資訊。清楚的重現描述應說明「使用什麼網路、採用什麼模式、存取哪個目標、出現什麼結果」，而不是只提供開關截圖；這些紀錄也能作為下一章判讀 Data 的基礎。

06 / 閱讀診斷資訊

判讀 Data 流量與請求結果

先確認統計範圍與觀察時段

Data 可用來查看應用程式提供的流量與連線資訊，實際顯示項目以目前介面為準。閱讀時先確認統計範圍是目前工作階段、特定時段還是累計紀錄，再判斷它能回答什麼問題。不同頁面的數字可能採用不同範圍，不能直接互相相減。應用程式本機紀錄與服務提供者的計費方式也可能不同，因此不能據此認定服務流量額度增減了相同數值；額度請查閱使用者既有服務的相關紀錄。

為了讓變化有跡可循，先記下觀察起點，再只開啟一個待測目標，查看新增紀錄與流量變化。裝置的背景同步、通知、圖片預載與其他應用程式請求，也可能在連線開啟時產生流量。上傳或下載數字增加，只能表示有資料經過處理，不能單獨證明待測網頁已成功載入。反之，頁面顯示失敗時也可能產生少量流量，因為解析、交握、重試或錯誤回應本身都需要通訊。

一併查看網域、策略與錯誤

若目前介面提供請求詳細資訊，請優先核對目標網域、使用的策略與結果，而非只看合計數。Config 模式下，某個請求採用 DIRECT，可能是命中直連規則，也可能是由最後的 FINAL 規則處理；請依具體命中資訊判斷。若目前紀錄沒有顯示命中規則，可透過設定順序與受控測試逐步縮小範圍，不要只憑某個 IP 位址猜測一定命中了哪條網域規則。

觀察到解析錯誤時，先檢查 DNS 路徑與目標名稱；連線逾時則要進一步區分伺服器無法連線、目標無法連線或等待回應。驗證失敗時，請回到伺服器項目核對身分欄位。相似的外在表現可能有不同原因，例如頁面一直載入，可能是 API 網域被導向錯誤路徑，也可能是伺服器回應延遲。錯誤資訊的用途是縮小問題範圍，而不是看到某個詞就立刻套用固定的修改方式。

透過受控對照解讀異常變化

若懷疑某個頁面造成持續流量，可先關閉該頁面與相關應用程式，觀察是否仍有同類請求；再單獨開啟該頁，比較新增紀錄。測試期間維持伺服器、Global Routing 與網路類型不變，減少其他變因。若關閉頁面後流量仍持續，也應考慮背景工作或長連線尚未立即結束，不必立刻認定應用程式行為異常。稍作等待並重複觀察，比清除所有資料後重新猜測更能保留有效線索。

若懷疑規則未生效，請先確認觀察的是修改後新建的請求。已建立的連線可能繼續沿用舊路徑，導致 Data 中同時出現不同時間的結果。可結束待測頁面的連線，再以相同方式重新存取；必要時，在了解影響後重新建立用戶端連線。比較時請明確區分新舊紀錄，不要因清單中仍有先前的策略，就判定剛儲存的規則完全無效。

流量突然增加時，先檢查照片同步、媒體播放、應用程式更新等實際使用情況，再查看是否有大量失敗重試。同一目標反覆出現錯誤，可能表示應用程式不斷重試，而非成功下載大量內容。此時應根據失敗時間與錯誤類型，回到連線章節排查。不要將所有異常都歸咎於伺服器速度，也不要只憑短時間觀察就調整整份設定；先找出哪類請求在什麼條件下發生變化。

保留有用紀錄，避免外流敏感資訊

需要保存診斷資訊時，記錄發生時間、模式、目標類別與錯誤摘要，通常比保存完整網路內容更適合日常維護。網域、請求路徑與存取時間本身也可能涉及個人資訊；分享截圖前，請確認是否露出訂閱網址、驗證參數或私人存取內容。用來說明問題的資料只應保留必要部分，不能因為是技術紀錄就假設其中不含敏感資訊。

清除歷史紀錄前，先保存目前排查所需的最少證據，再確認介面中清除操作實際涵蓋的範圍。清除診斷紀錄不等於刪除伺服器，刪除項目也不等於重設系統授權，操作前請確認目標。Data 最適合用來進行驗證與對照，連結「預期如何運作」與「實際發生什麼」。它無法取代服務狀態確認，也不能只憑一個彙總數字證明所有請求都走過相同路徑。

07 / 調整常用設定

Settings、DNS 與 On Demand

先釐清設定的影響範圍

調整 Settings 前，先確認問題屬於應用程式層級行為、目前 Config、單一伺服器參數，還是系統網路權限。名稱相近的選項可能位於不同層級，不能只看關鍵字就認定它們控制同一件事。例如，伺服器中的 TLS 欄位會影響該伺服器連線，設定中的 DNS 條件會影響解析路徑，而 On Demand 負責自動觸發。實際行為取決於目前介面與啟用中的設定；修改前請記下原本的位置與值，避免在錯誤層級反覆調整。

對於已穩定運作的設定，調整時應以明確目標為準，例如減少手動連線步驟、修正特定網域的解析失敗，或測試特定網路下的行為。網路上的某組設定不一定適用所有情況，因為伺服器條件、網路環境與規則目標都可能不同。若介面選項與參考資料不一致，請以應用程式目前實際顯示的內容為準；不確定用途的項目先保留原值，透過小範圍測試了解影響後再決定是否採用。

DNS：解析結果會影響後續連線與比對

DNS 會將網域名稱轉換成位址，但「取得一個位址」並非唯一的判斷標準。解析請求使用哪條路徑、回傳結果是否適合目前網路，以及後續請求如何連線，都可能影響存取結果。系統 DNS、自訂 DNS 與 DNS over HTTPS 的差異，首先在於解析請求如何傳送及由誰回應，不應只看名稱就判定哪種方式一定較快。新增自訂解析方式前，請先釐清原本的問題究竟是解析失敗，還是解析成功後連線失敗。

DNS over HTTPS 必須能存取相應的解析端點；若存取端點本身依賴尚未正常運作的代理路徑，就可能產生啟動階段的依賴問題。同樣地，伺服器位址若是網域名稱，也必須先取得可用的解析結果才能建立連線。修改後應分別測試伺服器連線與目標網域存取，不能只開啟已快取的頁面就判定一切恢復。若修改沒有幫助，請還原原設定，再檢查其他環節。

DNS 結果也可能影響 IP-CIDR 與 GEOIP 等位址相關規則，但網域規則與位址規則的適用條件並不完全相同。網站可能回傳多個位址，不同請求也可能使用不同紀錄，因此單次解析結果無法代表全部流量。更具體的選擇與測試方式請參閱DNS 設定說明。排查時請記錄修改前後的目標、解析結果與存取狀況，避免將快取變化誤認為設定必然有所改善。

On Demand：手動連線正常後再設定自動觸發

On Demand 會依設定條件觸發連線，不負責修正錯誤的伺服器參數。啟用前，請先確認手動連線、中斷與重新連線都能正常完成，再逐一設定自動觸發條件。若目前介面允許依網路環境設定規則，請分別測試進入、離開或切換該環境時的行為。每次只新增一類條件，觀察系統是否在預期時間啟動連線，避免多個條件重疊，導致無法判斷自動重新連線的原因。

啟用後若手動關閉連線卻很快再次啟動，可能是自動觸發條件仍符合，請先檢查 On Demand，而非反覆刪除 VPN 設定。需要進行直連基準測試時，請先暫停相關自動觸發，再關閉連線，否則測試期間可能自動重新連線。排查完成後再恢復原條件，並確認不會影響日常所需的連線行為。自動化設定應建立在已驗證的流程上，而不是用來掩蓋不穩定的連線。

以保守方式測試進階選項

遇到區域網路資源、UDP 服務或特定傳輸異常時，請先確認伺服器與目前協定是否支援相應需求，再查看相關設定。單純開啟某個選項，不會讓伺服器具備原本沒有的能力。一般網頁故障時，也不要一次調整多項底層參數；這會增加變因，讓原本清楚的問題更難重現。若既有設定包含特殊 DNS 或路由安排，請先了解其用途並保留原文，再於副本中測試。

連線恢復正常後，最重要的不是繼續增加設定，而是確認設定內容清楚可解釋，且變更能夠還原。保留伺服器、Config 與應用程式層級設定之間的界線，有助於在網路變化時只調整真正相關的層級。日常使用前，請再次確認 Global Routing 與 On Demand 的最終狀態，避免測試設定長期留在裝置上；下一章將整理成可重複執行的維護流程。

08 / 確保設定可還原

備份、更新與日常維護

備份應涵蓋多個獨立項目

應用程式、伺服器項目、訂閱網址、Config 與系統權限是不同項目，不能假設儲存其中一項就能還原整個環境。維護前先列出自己依賴的內容：哪些項目由訂閱產生、哪些是手動新增、目前啟用哪份設定，以及是否修改過規則。使用目前介面提供的儲存或匯出功能時，請確認實際涵蓋範圍。若只能保存部分內容，就分別保留所需資訊，不要把某個檔名當成完整還原能力的證明。

備份檔案可能包含伺服器驗證資訊或訂閱憑據，應存放在只有自己或明確授權的人員才能存取的位置。公開筆記、共享相簿與公開存取的檔案目錄，都不適合保存這些原始內容。為方便辨識，可在自己的紀錄中註明用途、來源與本機維護時間，但不要將密碼直接寫在檔名中。備份是否有用，最終取決於能否理解並還原所需項目，而不只是曾經按過儲存。

修改前先複製，修改後保留測試結果

編輯 Config 前，先保留一份目前可用的副本，並記下這次要解決的問題。每次變更盡量只針對同一個目的，例如新增一條網域規則，而不是同時重排所有規則、替換 DNS 並更換伺服器。儲存後確認啟用的是新副本，再依連線章節的方法建立新請求。若結果不如預期，切回舊設定重新測試；若舊副本在相同條件下正常，就更有理由繼續檢查本次修改，而非將問題歸咎於外部網路。

維護紀錄不必很複雜，可依序記下問題、原值、修改位置、測試目標與結果。規則調整還應記錄預期策略與實際觀察；伺服器參數則記錄重新核對的來源，切勿將敏感資訊寫入可公開的文件。下次遇到相同現象時，就能確認哪些處理方式已驗證過。長期累積後，也能分辨「偶然恢復」與「相同條件下可重複解決」的修改，減少反覆試錯。

分開安排應用程式與訂閱更新

Shadowrocket 的應用程式更新透過 App Store 處理，目前版本資訊與更新內容以商店頁面為準。Subscribe 更新則會重新讀取使用者既有訂閱的內容，兩者是不同流程。為方便找出問題，盡量不要在同一輪測試中同時更新應用程式、更新訂閱並替換整份設定。更新後先確認既有連線與常用目標正常，再安排下一項變更；若介面位置變動，先找到對應項目，不要立刻重複匯入而造成清單混亂。

訂閱更新後，請確認先前選取的伺服器是否仍存在、名稱或群組是否變更，以及手動修改是否遭到覆蓋。舊項目消失可能是訂閱端調整了內容，不一定代表本機儲存失敗。先查看更新結果與項目來源，再決定是否需要重新選取伺服器。若更新失敗但舊清單仍存在，也要確認目前測試使用的是先前儲存的資料；舊項目仍可連線，不代表這次更新已成功。

更換裝置與重新安裝後的還原順序

更換裝置時，先在 App Store 確認應用程式購買紀錄與相容性，再還原自己的伺服器與 Config，最後重新確認系統權限及自動觸發條件。應用程式可重新取得，不代表本機項目會自動出現；系統網路授權也應依新裝置的實際提示處理。還原後先選取一個明確項目手動測試，再檢查規則與 DNS，最後設定 On Demand。依此順序操作，可避免尚未確認設定有效時就被自動連線反覆觸發。

還原後若看到重複內容，請勿立刻批次清除。先辨認哪些來自備份，哪些是重新匯入的訂閱，再選擇要保留的來源。刪除訂閱群組前，也應確認是否會連帶移除由該群組管理的項目。任何涉及多個項目的清理操作，都應先保留可還原資訊，再逐步執行。已購項目的還原檢查請參閱已購項目還原說明，不要混淆購買紀錄與設定備份的用途。

建立簡短固定的日常檢查流程

日常遇到問題時，依固定順序檢查：目前網路是否正常、所選伺服器是否正確、Global Routing 是否符合用途、Config 是否為預期副本，以及最近一次訂閱更新是否成功。接著再深入檢查 DNS、規則與個別請求。確認來源後，可清理長期不用的測試項目；仍需使用的設定則保留清楚名稱。每次排查結束後，請還原暫時設定，並以常用目標再次測試，避免修正一種情境卻造成新的路徑變化。

首次操作仍可回到快速入門依主要步驟進行；需要了解問題現象時，再從本頁目錄找到相應階段。完整維護流程的目標，是讓每項變更都有來源、每次測試都有範圍、每項修改都能還原。不要將一次成功連線視為所有情境都能永久正常，也不必在使用穩定時頻繁重建整份設定。保留必要紀錄並分層檢查，通常比不斷疊加設定更容易得到清楚且可重現的結果。