Shadowrocket 完整使用手冊

01 / 取得

App Store 正版與購買範圍

先核對產品，再確認購買

Shadowrocket 是 Apple 平台的付費用戶端，請透過 App Store 取得。進入商店後，先查看產品詳情，不要只憑搜尋結果中的名稱決定購買。核對開發者是否為 Shadow Launch Technology Limited、圖示是否與本站頁首的官方圖示一致，再確認產品連結中的 App ID 為 932747118。以上三項可共同確認產品，名稱相似不能取代這些核對步驟。詳細操作請見下載指南的正版核驗。

商店頁面也可用來確認價格、相容性與購買條件。先確認目前使用的裝置列於相容性說明中，再查看實際付款金額。系統需求與購買適用條件均以 App Store 頁面標示為準。iPhone 與 iPad 是本手冊的主要操作裝置；Mac / Apple TV 也可在同一商店取得，但請勿直接將行動裝置上的按鈕位置視為其他裝置的操作說明。

用戶端買斷與連線資料分開準備

用戶端一次性買斷 ≠ 線路方案。購買取得的是用戶端使用資格，不會因此自動提供可用伺服器。連線需要使用者已有的伺服器資訊或訂閱，相關資料請向你的服務供應商取得。操作前至少確認資料類型、適用協定與有效狀態。只有伺服器位址通常不足以完成連線，連接埠、身分憑證與傳輸設定也必須相符。

美國商店的標價以商店頁面為準，各地商店會以當地貨幣顯示，最終金額以購買確認頁為準。請勿將用戶端價格視為網路服務費用，也不要根據手冊範例推定實際連線條件。本網站提供官方手冊，不提供節點服務。若伺服器已到期、憑證已變更或服務端正在維護，請核對現有服務資料；重複購買用戶端無法解決這些問題。

安裝完成後的準備順序

在商店完成購買後，請等候 App 下載完成，再從裝置主畫面開啟。若圖示仍顯示等待中，先檢查裝置網路、可用儲存空間及商店提示，暫時不要開始排查代理設定。此時用戶端尚未負責網路連線，安裝階段與連線階段是不同的問題。購買與下載狀態的處理方式，可參考App Store 正版下載流程逐項確認。

開啟前先整理現有資料，區分單一伺服器連結、訂閱網址與設定檔。單一伺服器資料描述一條連線；訂閱用來取得並維護一組伺服器；設定檔主要包含規則與相關設定。三者可能以文字或連結形式提供，但用途不同。不要因為內容都能複製，就把訂閱網址貼到伺服器位址欄，或把設定檔當成訂閱來更新。

已購紀錄與本機設定的區別

更換裝置時，先在 App Store 查看購買紀錄，並使用完成購買時所用的 Apple 帳號尋找 App。能否重新下載、是否適用「家人共享」，均以 App Store 頁面標示為準。若商店仍顯示購買價格，先確認帳號與已購項目，不要急著再次付款。App 取得資格與用戶端內儲存的資料是兩回事；還原已購項目不等於還原伺服器與規則。

因此，舊裝置仍可使用時，就應規劃設定移轉。記下目前使用的訂閱名稱、設定名稱與必要設定，並妥善保管原始資料。訂閱網址與密碼都屬於敏感資訊，不要放在公開筆記或截圖中。完成購買的判準是 App 能正常開啟，且正版資訊已核對；接下來才是授權系統網路設定，並將現有資料匯入用戶端。

02 / 初始化

首次啟動與系統權限

了解新增 VPN 設定的系統提示

首次建立連線時，系統可能會詢問是否允許 Shadowrocket 新增 VPN 設定。這是用戶端接管裝置網路要求所需的系統授權，不是伺服器帳號，也不代表訂閱已生效。確認提示來自目前操作的用戶端後，再依系統要求完成認證。授權成功只表示系統允許建立相關網路設定，遠端伺服器是否可連線仍須進一步驗證。

如果當時選擇拒絕，先回到用戶端重新發起連線，確認提示是否再次出現；必要時前往系統設定中的 VPN 相關項目查看設定狀態。不同系統的入口名稱與層級可能不同，請以裝置實際顯示為準。不要為了解決一次提示就清除所有網路設定。先判斷是尚未授予權限，還是已授權但連線失敗，再決定後續處理方式。

透過 Home 確認操作項目

進入 Home 後，先辨認連線開關、Global Routing、Connectivity Test 與 SERVER 清單。連線開關用來啟動或停止目前連線；Global Routing 決定要求採用哪種路由方式；SERVER 清單顯示已新增的伺服器；Connectivity Test 則用於輔助測試。各區域用途不同，清單中有伺服器不代表已連線，測試有結果也不代表規則符合預期。

SERVER 清單仍為空白時，先完成下一章的匯入，不要反覆操作連線開關。若已有項目，請檢查名稱、類型與預設選取項目，避免將舊資料誤認為新匯入的資料。介面配置會隨裝置尺寸與 App 調整而異；本手冊以介面詞彙定位功能，不依賴固定座標。各區域的入門說明請參閱首次開啟與 Home 頁面說明。

依實際操作授予其他權限

使用 Scan QR Code 時，相機權限用於辨識 QR Code；若從照片選取 QR Code，系統可能會另外要求存取照片。只有在需要該操作時才授予相應權限。手動輸入伺服器資料與掃描 QR Code 是不同入口；未授予相機權限不代表網路連線權限遭拒。掃描失敗時，應先確認是權限未開啟、影像不清晰，還是目前入口無法辨識內容類型。

QR Code 與剪貼簿內容可能包含完整憑證。操作前請確認內容來自現有服務資料，辨識後先檢查匯入預覽，再儲存。不要直接匯入收到的任意圖片，也不要公開分享含有 QR Code 的完整頁面。複製後若未出現匯入提示，可返回新增入口，依資料類型操作；不要為了觸發提示而連續複製多份不同內容，以免混淆來源。

連線前排除系統層級的干擾

若裝置上有其他正在運作的 VPN 設定，請先了解其用途與管理要求。測試 Shadowrocket 時，盡量一次只保留一個明確的網路接管對象，避免系統狀態反覆變動。受組織管理的裝置可能受到管理政策限制；若遇到無法修改的開關或系統限制提示，請依裝置管理要求處理，不要反覆重建用戶端設定。

此外，連線至公共網路時，可能需要先完成網路本身的登入或確認。先停止用戶端連線，以裝置原始網路確認是否能正常存取，再開始設定。系統時間應保持正確，時間錯誤可能影響安全連線中的憑證判斷。初始化完成後，記下已授予及尚未使用的權限；日後發生異常時，便能區分權限問題與伺服器問題。

03 / 匯入

伺服器、Subscribe 與協定參數

依資料類型選擇入口

單一伺服器資料可透過 Add Server 手動填寫，或使用用戶端支援的分享內容匯入；需要持續更新的一組伺服器通常透過 Subscribe 管理。請先確認收到的是哪種資料，再選擇相應入口。現有訂閱請向你的服務供應商取得，完整網址可能包含身分憑證。貼上時請檢查開頭、結尾與換行，避免聊天軟體附加的標點符號成為網址的一部分。

儲存後返回 Home，確認新增內容所在的群組、名稱是否適當，以及伺服器類型是否與原始資料一致。出現項目表示用戶端已讀取內容，不代表遠端憑證有效。若匯入結果為空，先確認回傳內容是否為用戶端可辨識的伺服器資料，而不是登入頁面或提示文字。不要藉由重複建立多個同名訂閱來掩蓋更新失敗。

逐項核對協定參數

協定名稱決定欄位的意義。Shadowsocks、VMess、VLESS、Trojan、Hysteria2 與 WireGuard 的填寫方式各不相同。先選擇正確類型，再依原始資料填入位址、連接埠及該協定要求的身分欄位。名稱只是本機識別標籤，重新命名無法修復伺服器連線；連接埠與憑證則會直接影響通訊，應逐字核對，尤其留意複製時的空格與大小寫。

啟用 TLS 的連線也可能涉及 Server Name 等欄位，這些欄位不一定與填寫的連線位址完全相同。使用特定傳輸方式時，Path、Host 等欄位也須與伺服器端相符。不要依欄位名稱自行猜測，缺少的內容應回到原始資料確認。關閉憑證驗證不是一般的修復方法，還會削弱遠端身分判斷；請先檢查名稱、系統時間與資料是否過期。

分開處理訂閱更新與本機編輯

儲存訂閱後執行更新，再查看伺服器數量、名稱與群組變化。更新失敗可能發生於取得網址、網路存取或內容解析階段，不代表所有伺服器同時失效。先保留目前可用的清單，檢查訂閱網址是否變更、是否需要確認續期，以及目前網路能否取得內容。不要立即刪除整個群組，否則會失去比較依據，也可能中斷原本可用的連線。

訂閱管理的伺服器在後續更新時可能重新產生或遭到覆寫。若要暫時驗證某個欄位，先記下原值，並了解用戶端如何處理訂閱項目的編輯。長期修正應依據伺服器端提供的正確資料，不要依賴每次更新後重新手動修改。更新成功後也要再次確認預設伺服器，因為名稱變更、項目替換或移除都可能影響原有選擇。

判斷手動新增、掃描與重複項目

資料完整且需要逐項核對時，適合手動新增；已有相容 QR Code 時，可使用 Scan QR Code。掃描只是輸入方式，不會提高伺服器的可用性。辨識後先核對類型與主要欄位，再儲存並測試。若多個項目名稱相似，請比較協定、位址與連接埠，不要只依名稱批次刪除；不同傳輸設定也可能刻意使用相近名稱。

完成匯入後，選擇一台資料來源明確的伺服器作為初步測試對象。先不要加入複雜規則，也不要一次修改多種協定欄位。只要能說明「這筆資料來自哪裡、最後核對了哪些欄位、為何設為預設」，就具備進一步排錯的基礎。訂閱只負責維護資料，實際要求如何選擇路徑則由 Global Routing 與設定檔決定，下一章將分別說明。

04 / 分流

Global Routing 與設定檔

先分清 Config、Proxy、Direct

Global Routing 中的設定、代理、直連分別對應 Config、Proxy、Direct。Config 依目前設定中的規則決定要求去向；Proxy 讓要求以代理模式處理；Direct 則以直連模式處理。模式選擇會改變路由判斷方式，不會自動修復錯誤憑證。發生異常時，先確認目前模式，避免將規則導致的直連誤判為伺服器無法運作。

排錯時可短暫切換模式進行比較，但每次都要記錄切換目的。Proxy 可用、Config 異常時，優先檢查規則與策略；兩種模式都異常，則繼續核對伺服器、解析與目前網路。Direct 能存取某個目標，只能表示該目標目前可透過直連路徑連線。不同目標的網路條件各異，不能根據單一頁面的結果推論所有連線狀況。

設定檔的區段與用途

Config 頁面用來管理設定檔，Global Routing 中的 Config 則是路由模式，名稱相近但操作對象不同。設定檔可包含 General、Rule、Host 等區段，分別負責一般設定、規則與主機對應等用途。編輯前請確認目前實際使用的是哪一份檔案，並另存可用副本。檔案出現在清單中，不代表連線時已啟用該設定檔。

[General]
bypass-system = true
dns-server = system

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

此範例用於說明結構，不是適用於所有網路的完整設定。example.com 是示例網域；PROXY 代表代理策略，DIRECT 代表直連策略。實際代理去向還須配合目前選取的伺服器或已定義的策略。保留原設定中已驗證的項目，只替換需要測試的部分。不要將不同來源的多份檔案整份拼接，以免區段重複或策略引用失去對應。

規則依序比對

規則通常依序判斷，具體條件宜排在廣泛條件之前。DOMAIN 比對指定網域，DOMAIN-SUFFIX 用於網域後綴，DOMAIN-KEYWORD 用於網域中的關鍵字；IP-CIDR 與 IP-CIDR6 適用於位址範圍；GEOIP 依位址歸屬資料庫判斷。FINAL 用來處理前面規則都未命中的要求，應放在規則末尾。若前面的廣泛規則已命中，後續更精確的規則就無法如預期發揮作用。

網域規則與位址規則依賴的資訊不同。特定要求能否套用網域條件，取決於用戶端實際取得的要求資訊；位址歸屬結果也不等於服務的業務歸屬。不要只因名稱含有某個詞，就為所有相關要求設定廣泛的關鍵字規則。單一頁面可能存取多個網域，請依實際紀錄逐步補上必要條件，避免擴大修改範圍。

驗證修改，不要只確認已儲存

儲存後確認設定仍可辨識，再建立新的要求檢查命中結果。編輯成功只表示文字已儲存；規則是否生效，還取決於目前啟用的檔案、路由模式與要求比對資訊。長連線可能持續使用既有路徑，驗證時應重新發起要求。修改後若發生異常，先還原剛修改的一組規則，比連續新增更多條件更容易找出原因。

設定與訂閱應分開維護：訂閱更新伺服器資料，設定則控制路由與相關行為。規則中的策略名稱必須有相應定義，引用不存在的名稱無法靠增加伺服器數量解決。暫時不理解某段設定時，先保留可用副本，不要只憑註解猜測後就刪除。遇到具體異常可前往故障排查，但請先記下目前檔案、模式與目標要求。

05 / 驗證

預設伺服器、連線與測試

建立變因明確的測試起點

返回 Home，在 SERVER 清單中確認預設伺服器，並留意 DOT 標記指向的項目。開啟編輯頁面與選取預設伺服器是不同操作，應以清單中的實際選取狀態為準。初次測試請選擇資料來源明確、協定參數已核對的伺服器。暫時不要同時啟用複雜的自動選取條件，否則連線變化時難以判斷是網路狀況還是選取邏輯所致。

接著確認 Global Routing，記下目前的設定名稱，再開啟連線開關。若系統要求新增 VPN 設定，請依前文完成授權。待狀態穩定後再開始測試，不要快速連續開關。頻繁重新連線會混淆多次嘗試的紀錄，也可能在系統狀態尚未更新時就開始下一輪操作。若系統明確顯示錯誤，先保留提示文字，再停止操作並分類判斷。

將測試結果分層判斷

Connectivity Test 用於輔助判斷連線狀況，實際測試方式與目標以目前用戶端設定為準。測試結果會受到本機網路、伺服器回應、測試目標與協定條件共同影響。數值較小不代表所有服務要求都正常，出現逾時也不能立即證明身分憑證錯誤。先確認測試的伺服器與方式，再對照實際存取結果。

驗證應包含三個層次：系統允許建立連線、用戶端能與所選伺服器通訊，以及目標要求依預期策略收到回應。依序檢查這三層，便能避免將「開關已開啟」視為成功。連線完成後，請存取一個平時能判斷結果的目標，並確認其使用的策略；接著再測試另一類要求，避免因單一頁面快取而誤以為連線正常。

依網路、參數、規則的順序排查

連線失敗時，先停止用戶端並確認裝置原始網路是否可用。若原始網路也異常，先處理網路登入、訊號或路由器問題；若原始網路正常，再核對預設伺服器與協定參數。位址無法解析、連接埠無法連線、身分驗證失敗與憑證判斷失敗，分屬不同階段；應根據提示與紀錄區分，不要一概歸因為「節點逾時」。

接著暫時切換模式，以比較方式排除規則因素。若代理模式能完成相同的目標要求，但設定模式不行，請檢查目前檔案與命中策略；若兩者皆失敗，再檢查伺服器資料與網路條件。每次只修改一個欄位或一種模式，並重新發起相同要求。具體步驟也可參考節點逾時排查說明，排查時不要同時更換所有條件。

連線成功但部分內容異常

網頁主體載入正常，但圖片、登入或其他資源失敗時，通常需要分別檢查不同要求。同一頁面可能連線至多個網域、命中不同規則，也可能使用持續連線。記錄失敗資源對應的網域、策略與錯誤階段，再決定是否調整。不要只將網頁網址加入規則，就認為所有資源都會改走相同路徑；也不要長期將所有要求改為同一種策略。

若只有某個 App 發生異常，先比較該 App 與瀏覽器是否要求相同目標，再考慮快取、解析與連線重複使用的影響。必要時完全結束相關 App 後再試，並保留調整前後的結果。若涉及安全連線錯誤，先檢查系統時間與伺服器名稱。不要為了讓單次測試通過而略過身分驗證，否則會失去原本應保留的連線安全界線。

結束測試並恢復日常狀態

每次驗證結束後，將臨時使用的路由模式改回日常設定，並確認預設伺服器未因測試操作而變更。記錄可用設定、測試網路與主要結論，不必記錄不斷變動的瞬時數值。有效的結論應說明「在什麼條件下，哪個要求透過什麼策略完成」，而不只是寫「連線正常」。如此一來，下次發生異常時才有可比較的基準。

首次完成連線後，可參考首次連線與 Connectivity Test檢查是否有遺漏。若仍需排查，保留必要資訊即可：伺服器類型、模式、錯誤文字與重現步驟。請勿公開密碼、訂閱網址、私鑰與完整分享內容。之後使用 Data 觀察要求時，也應採用相同的分層判斷方式。

06 / 觀察

Data 流量與要求判斷

將統計視為現象，不要當成結論

Data 用來查看用戶端提供的流量與連線相關資訊，實際項目以介面顯示為準。流量增加表示有資料經過相應統計範圍，不代表要求最終完成，也不代表所有流量都經過同一個遠端。反之，暫時沒有明顯變化，也可能是快取、統計更新或尚未發出要求所致。先確認觀察對象再解讀數字，避免以總量取代特定要求的結果。

查看資料前，確認連線正在運作、預設伺服器正確，且測試期間沒有大量背景工作。若一邊同步照片，一邊排查單一網頁，彙總流量就很難對應到目標操作。請盡量縮短觀察時間，只執行一次可重現的要求，再查看新增紀錄。如此便能按時間順序對照「頁面開啟」、「產生要求」與「命中策略」這三件事。

從目標要求追查所用策略

若用戶端目前提供要求紀錄或連線詳細資訊，先找到與重現時間相符的目標，再查看可用的網域、位址、策略與錯誤資訊。不同協定與要求類型可顯示的資訊可能不同，不要假設每筆紀錄都包含完整網址或內容。應優先釐清要求送往何處、符合哪項判斷、停在哪個階段，而不是試圖從單筆紀錄推測整個 App 的所有行為。

在 Config 模式下，尤其要核對預期策略與實際策略。若預期使用 PROXY，實際卻為 DIRECT，先檢查較前面的規則與目前啟用的檔案；若策略符合預期但要求仍失敗，則繼續檢查相應伺服器與目標的可達性。規則命中只能證明選擇流程正常，不能證明遠端服務已正確回應。區分策略層與傳輸層，可減少無效修改。

區分解析、建立連線與傳輸資料

網域要求通常會先進行解析，再向選定位址建立連線，之後才交換 App 資料。解析失敗時，更換密碼沒有幫助；若已確定位址但無法建立連線，應檢查網路、連接埠與伺服器端；建立連線後若發生安全交握問題，則檢查憑證名稱、時間與相關參數。不同階段可能顯示不同錯誤文字，請根據上下文判讀並保留原文，不要一概改寫成相同描述。

看到網域對應多個位址時，不要立即認為設定混亂。服務可能依網路、時間或地理位置回傳不同結果，因此位址規則也可能有不同命中結果。先重複相同要求，確認現象後，再比較直連與代理路徑的解析條件。未經驗證前，不要將某次取得的位址永久寫入 Host；固定位址可能很快不再適用，並引發新的故障。

統計範圍可能與服務端紀錄不同

用戶端統計、裝置系統統計與服務端統計的範圍可能不同。它們可能分別計算不同方向、連線額外負荷或時間區間，因此不必然每個數值都一致。若要判斷異常用量，先統一觀察時段、暫停明顯的背景工作，再查看變化趨勢。不要將短時間內一次差值直接視為計費錯誤，也不要把某個總量當成所有 App 的完整使用紀錄。

重設統計前，先保存需要比較的結論，並確認重設會影響哪些項目。清除本機顯示通常不會改變服務端使用紀錄，也無法修復連線問題。排錯時，特定要求對應的狀態變化比不斷清除後反覆觀察更有參考價值。若用戶端提供不同統計檢視，先查看其標籤與範圍說明，再決定適合用於哪種判斷。

分享紀錄前先刪除非必要資訊

要求紀錄可能包含存取目標、伺服器位址及其他識別資訊。匯出或截圖前先檢查畫面內容，只保留解決問題所需部分。訂閱連結中的查詢參數、伺服器密碼、UUID 與私鑰都不應隨紀錄公開。即使只分享 QR Code，也可能等同公開完整連線資料；遮住名稱並不代表敏感資訊已隱藏。

整理排錯資料時，可記下重現操作、發生階段、使用的協定與策略，再摘錄不含憑證的錯誤原文。完整紀錄留在本機供自己比對，對外只提供最精簡的片段。若問題已確認與伺服器端參數有關，核對原始資料即可，不必繼續收集無關要求。觀察結束後請恢復日常模式，避免長期保留為測試而開啟的額外紀錄。

07 / 設定

Settings 常用項目與修改界線

先確認設定影響的層級

Settings 中的選項並非都控制同一項目。有些影響用戶端整體行為，有些影響連線過程，有些只是顯示與測試偏好；伺服器編輯頁中的參數則可能只套用於單一項目。修改前先確認作用範圍，並檢查設定檔是否也定義了相關行為。不要把單一伺服器的傳輸參數當成全域網路設定，也不要假設位於不同位置的同名選項具有相同優先順序。

本章依用途說明設定，不代表每台裝置都會顯示完全相同的項目。介面名稱與可用選項以目前用戶端為準。遇到不熟悉的選項，先記錄目前值與要解決的具體問題，再查閱相關說明。若目前連線正常，保留預設行為通常比批次啟用進階選項更容易維護；沒有明確目標的調整難以驗證，發生問題後也不易還原。

先手動連線，再設定 On Demand

On Demand 用於依條件觸發連線相關行為。啟用前先完成手動連線與目標要求驗證，否則自動觸發只會讓尚未解決的問題更難觀察。進入相關設定後，仔細確認啟用狀態與適用條件，再於實際環境中測試一次。不要將「已開啟」理解為任何情況下都會維持連線，最終行為仍受系統、網路條件與設定影響。

測試按需連線時，分別觀察預期會觸發與不會觸發的情況。例如切換網路後，先等候系統狀態穩定，再查看連線狀態與要求結果。若出現反覆連線，先暫時關閉 On Demand，以手動方式確認基本連線仍可使用，再檢查觸發條件。也要留意受管理裝置上的限制，避免用戶端條件與系統管理要求互相影響而難以判斷。

DNS 調整須有可重現的問題

DNS 會影響網域轉換為位址的解析，也可能影響部分規則判斷。只有確認解析階段異常或結果不符合預期後，才調整相關設定。記錄原本的解析方式、測試網域與錯誤現象，每次只修改一項。不要將切換 DNS 當成處理所有連線故障的第一步；錯誤連接埠、失效憑證與不相符的傳輸參數，不會因更改解析方式而自動修復。

設定範例中的 dns-server = system 表示使用與系統相關的解析設定，不保證適用於所有網路。若採用其他解析方式，應了解其存取路徑與適用條件，避免解析服務本身依賴尚未建立的連線。修改後重新發出要求，並考量快取影響再比較結果。測試結束後，請確認最終保留哪種方式，不要讓臨時修改長期累積。

測試、逾時與網路切換

Connectivity Test 的相關設定會決定測試執行方式；更改測試方式也會影響結果的可比較性。比較兩台伺服器時，應使用相同方法與目標，避免直接排列不同測試條件下的結果。逾時設定也須有合理範圍：時間過短可能將正常但較慢的回應判為失敗；時間過長則會延遲故障回報。先了解目前網路狀況，再考慮調整，不要只為了追求好看的結果而修改。

切換網路後若短暫發生異常，先等候系統完成切換，再建立新的要求。舊連線可能無法沿新路徑繼續，部分 App 也會自動重試。若問題只在切換時發生，應與固定網路下持續失敗分開記錄。檢查 On Demand、預設伺服器與新網路的可用性，比同時重設所有設定更有效，也能保留原本穩定的設定。

明確使用安全相關選項

涉及憑證、HTTPS 或要求處理的進階選項，應先了解用途與影響範圍。一般伺服器匯入與首次連線，不需要延伸成一整套額外的憑證操作。若有特定功能需求，請另存設定檔並依其說明驗證，不要將測試條件混入日常設定。任何降低遠端身分驗證要求的修改，都應先重新核對原始參數，不應當作通用的排錯捷徑。

設定變更紀錄可保持簡單：原值、修改原因、測試結果與是否保留。只要能還原到上一個可用狀態，就比依賴零散記憶可靠。若修改沒有解決問題，請及時還原，不要只因為「已經改過」就繼續保留。最後確認目前設定、Global Routing 與預設伺服器，再實際存取一次，讓設定調整以可觀察的結果作結。

08 / 維護

更新、備份與日常排錯

維持可還原的工作狀態

日常維護的重點不是頻繁修改，而是清楚了解目前設定為何可用。保留一份已驗證的設定，記錄預設伺服器、Global Routing 與必要的全域設定。修改前另存副本，檔名可依用途區分，不必堆疊難以辨認的編號。每次只修改一組相關內容，驗證後再決定是否取代日常設定，發生異常時便能依最近一次修改還原。

備份範圍應包含自行編輯的規則與必要設定，但敏感資料須另外保護。伺服器密碼、私鑰與訂閱網址，不應與一般文件一同公開存放。使用用戶端目前提供的匯出、備份或還原功能時，先確認包含哪些資料，再儲存至自己能妥善管理的位置。備份完成不代表還原一定可靠；必要時使用副本確認檔案能否讀取，並保留原始資料。

區分 App 更新與訂閱更新

App 更新透過 App Store 完成；訂閱更新則在用戶端內維護伺服器資料，兩者彼此獨立。更新 App 不會替使用者補齊過期憑證，更新訂閱也不會變更商店的購買狀態。更新 App 前，先保存重要設定並閱讀商店說明；更新完成後，檢查目前檔案、預設伺服器與連線狀態，不要只因 App 能開啟就視為驗證完成。

訂閱更新後，請重點檢查群組、項目與預設選擇。若服務端移除了某台伺服器，原本依賴該項目的選擇可能需要重新確認。名稱相同不代表內部參數沒有變動，發生異常時應對照現有資料。更新失敗時先保留可用內容，判斷是取得失敗還是解析失敗，再決定是否重試。不要同時執行 App 與訂閱更新，之後才開始追查是哪項變更影響連線。

依三個層次還原裝置或重新安裝

還原時，先取得 App，再還原伺服器資料，最後還原設定檔與設定。第一層透過 App Store 已購項目確認；第二層使用自己妥善保管的訂閱或伺服器資訊；第三層匯入備份並核對其作用範圍。依序完成這三層，可避免 App 已安裝卻沒有伺服器，或伺服器已匯入但仍使用空白規則的情況。

在新裝置上重新確認系統授權與相容性；系統需求以 App Store 頁面標示為準。不要假設舊裝置的權限會完整移轉，也不要把購買項目還原視為本機資料還原。還原後，先驗證一台伺服器與一個目標，再啟用按需連線及其他附加條件。完成移轉驗證前，保留舊裝置的可用狀態，才能進行最直接的比較。

依故障階段逐步縮小範圍，勿全面重設

發生異常時，先明確記下現象：無法啟動連線、測試逾時、部分要求失敗，還是規則去向不符。接著確認近期變更，包括網路切換、訂閱更新、規則編輯與系統設定調整。優先檢查與變更直接相關的層級。全面重設會一併清除線索與可用設定；只有在清楚了解影響且已有備份時，才考慮大範圍還原。

若需要進一步查閱，購買與還原問題請前往下載指南，基本操作請前往快速上手，常見異常請前往故障排查。查詢時保留介面原詞與錯誤原文，有助於準確找到相應功能。若服務端資訊不完整，請核對現有服務資料；反覆切換規則無法補足缺少的協定欄位。

用精簡紀錄完成日常檢查

一份維護紀錄只需回答四個問題：目前使用哪份設定、預設伺服器是哪一台、最近修改了什麼，以及驗證結果如何。記錄異常發生時的網路與重現步驟，比保存大量未整理的截圖更有價值。問題解決後，補上真正原因與還原方法，並刪除公開副本中的憑證。下次發生類似現象時，可先確認原因是否相同，而不是直接套用上次所有修改。

最後回到實際使用情境檢查：目前模式符合預期、目標要求能順利完成、規則去向合理，且臨時測試選項已還原。連線可用後，不必繼續疊加設定。維持一份清楚、可驗證且可還原的設定，比累積許多用途不明的檔案更容易維護。本手冊的八個階段可重複使用：先定位問題所屬層級，再檢查輸入資料，最後用相同要求驗證結果。