Shadowrocket 訂閱與伺服器管理手冊

一、Subscribe 訂閱入口與首次匯入

訂閱會將遠端網址提供的伺服器集合匯入用戶端，並保留後續更新的關聯。單一伺服器項目則只描述一個連線目標；兩者都能「新增」，不代表可以混為一談。匯入前先確認收到的是訂閱網址、單一分享連結，還是完整設定文字。網頁標題和檔案副檔名只能作為線索，最後仍應以服務商提供的用途說明為準。

先區分訂閱、伺服器與設定

訂閱用於管理伺服器集合，伺服器項目保存連線參數，Config（設定）則負責規則等設定內容。成功匯入訂閱，不代表已替換 Config（設定）中的規則；匯入設定檔，也不能據此認定伺服器憑證已齊備。先記下這次要變更的是哪一層，操作後只檢查該層結果，避免把參數缺漏誤判為分流問題。

準備匯入時，請向你的服務商取得完整訂閱連結。不要把說明頁、登入頁，或瀏覽器網址列中經過轉址的頁面直接當成訂閱網址。連結可能在問號後帶有識別參數，複製時必須包含完整內容。聊天工具中的省略顯示不一定代表複製結果完整，建議在本機受保護的文字檔中核對開頭、結尾，以及是否混入換行。

在 Add Server 中選擇 Subscribe

1. 進入 Home（首頁），使用新增入口開啟 Add Server（新增伺服器）。
2. 在 Type（類型）中選擇 Subscribe（訂閱），不要在一般協定類型下貼上完整訂閱網址。
3. 將完整網址填入 URL（網址）欄位，設定方便辨識且不含憑證的備註，然後儲存。
4. 等待請求與解析完成，返回 Home（首頁），檢查訂閱群組及其下屬伺服器是否出現。

不同介面配置下，新增按鈕的位置可能不同，但判斷依據始終是類型已切換為 Subscribe（訂閱），網址已填入專用的訂閱欄位。儲存前先檢查是否多了引號、空格或說明文字；不要為了「修正格式」任意刪除問號後的參數，也不要把網址改成看起來比較整齊的形式。

https://example.com/sub?token=xxxx

上例只說明「網址加查詢參數」的結構。實際使用時，路徑、參數名稱與憑證都應保留收到時的完整內容。這個網址與訂閱回傳的伺服器網址並非同一概念：前者用於取得清單，後者才是連線目標。因此，訂閱請求失敗與伺服器連線失敗應分開檢查，不能以其中一項測試取代另一項。

首次匯入後的確認與失敗處理

匯入後至少核對三項結果：群組備註是否正確、清單是否包含預期項目，以及任選一個項目的協定與網址是否合理。伺服器數量只能協助發現明顯異常，不能單憑數量判斷訂閱品質或連線狀態。先選一個項目進行後續連線驗證，再決定是否需要調整規則；此時不要同時開啟多個自動連線選項，以免難以辨認實際使用的項目。

如果儲存後清單仍是空的，先保留錯誤訊息並重新檢查原始網址。返回登入頁、提示憑證失效，或回傳無法解析的本文，都屬於訂閱回應問題；已出現項目但連線失敗，則是後續連線問題。不要連續新增相同訂閱來嘗試重新整理，否則只會增加重複群組。請依照訂閱更新失敗與空清單自我檢查清單逐項排查，確認問題所在層級後再重試。

若裝置上已有其他訂閱，首次匯入前也要記下原先選取的伺服器與目前的路由狀態。新增集合不應成為刪除舊集合的理由；只有新集合完成驗證後，才進入整理階段。如此一來，即使匯入結果不如預期，也能回到原本可核對的狀態，不必從頭重建所有設定。

二、Add Server 手動填寫欄位與協定核對

手動填寫適用於已有完整參數、只需新增少量伺服器，或需要逐項比對分享連結匯入差異的情況。進入 Add Server（新增伺服器）後，先選擇正確的 Type（類型），再填寫該類型實際顯示的欄位。選錯協定時，即使欄位名稱相同，含義也未必相同；不要先填完網址和密碼，再憑經驗切換類型。

先確保共用欄位填寫一致

Address（地址）填寫伺服器網域或指定地址，不是訂閱網址，也不是帶有登入路徑的網頁。Port（連接埠）是伺服器端監聽的連接埠，不能因為啟用 TLS 就自行認定為某個固定值。Remarks（備註）供本機辨識，不參與身分驗證。手動填寫前，請將原始參數與介面並排核對，尤其留意數字零與字母、半形符號，以及複製時附帶的空格。

上表用於說明欄位類別，不代表所有協定都會顯示相同選項。若某個欄位沒有顯示，先確認類型與傳輸方式，不要改填到另一個名稱相近的輸入框。服務商未提供的參數，應先確認是否需要；不要拿網路上的通用範例補齊，拼成看似完整的設定。

分層填寫身分、傳輸與 TLS

Shadowsocks 需核對加密方式與密碼；VMess 需核對 UUID，以及參數中明確提供的相關選項；VLESS 需核對 UUID、傳輸與安全設定；Trojan 需核對密碼及 TLS 相關參數。名稱相似不代表可以互相替代。若要了解 VMess 與 VLESS 的欄位差異，可先閱讀手動填寫欄位對照說明，再回到實際參數逐項檢查。

傳輸方式與協定類型屬於不同層級。例如使用 WebSocket 時，Host（主機）與 Path（路徑）可能都是必要資訊；路徑中的斜線、大小寫與查詢部分都應保留原值。TLS 的 Server Name（伺服器名稱）用於相關名稱驗證，可能與 Address（地址）不同。連線目標、傳輸請求中的主機資訊與憑證名稱各有用途，不應只因為看起來都是網域就一律修改。

遇到憑證錯誤時，不要把略過驗證當成一般修復方式。先核對裝置時間、憑證名稱與服務商要求，再檢查參數是否遭到改寫。如果錯誤來自伺服器端的憑證設定，反覆更換用戶端密碼也無法解決。排查時記錄錯誤發生的階段，比只寫「不能用」更有幫助，也能避免在不相關欄位間反覆嘗試。

特殊協定與儲存後核對

WireGuard 的金鑰、對端資訊、地址與路由參數需要整體理解，不能簡化成「地址加密碼」。Hysteria2 還涉及以 UDP 為基礎的傳輸條件，單次一般連線測試無法涵蓋所有要求。使用這些協定時，應依收到的完整參數說明填寫；沒有明確依據時，不要為了提高速度而更動頻寬、路由或底層傳輸選項。

儲存後重新開啟剛新增的項目，檢查類型、地址、連接埠與傳輸選項是否仍與原始內容一致。密碼欄位可能會遮蔽內容，不要為了方便截圖而完整顯示敏感資訊。如果另有一筆透過分享連結匯入的項目，可用來輔助比較欄位對應方式，但不要假定匯入結果必然正確；最後仍應以完整的伺服器端參數為準。

排查手動填寫錯誤時，一次只修改一個欄位，修改前記下舊值，修改後使用相同方式驗證。若連續更改地址、連接埠與 TLS 設定，即使連線恢復，也無從得知真正原因。成功後，將必要差異記在私人紀錄中，並在備註中標明用途；不要把密碼、UUID 或完整金鑰寫進備註，以免從清單截圖中洩漏。

三、Scan QR Code 掃描與剪貼簿匯入

掃描 QR Code 與使用剪貼簿只是將文字送入用戶端的不同方式，不會改變文字本身的用途。QR Code 可以包含單一伺服器分享連結，也可以包含訂閱網址；剪貼簿同樣可能是網址、設定片段或多行內容。匯入前先確認預期取得的是單一項目還是一組項目，再依辨識結果選擇處理方式，避免把辨識成功誤認為匯入對象正確。

掃描前先確認內容範圍

使用 Scan QR Code（掃描 QR Code）時，讓 QR Code 完整進入取景範圍，保持邊緣清晰，避免反光或過度縮放。系統要求相機權限時，請依本次掃描需要決定是否允許；若先前拒絕過，可到系統相應的權限設定中檢查。相機權限只關係到掃描入口，不會取代 VPN 設定授權，也不能證明連線是否可用。

QR Code 顯示在另一部裝置上時，可直接掃描；若儲存在目前裝置的照片中，只有在掃描入口確實提供圖片辨識功能時才使用該功能。介面沒有這個選項時，請改用服務商同時提供的原始文字，不要反覆拍攝螢幕，或透過不明轉換頁面處理。QR Code 圖片本身可能含有憑證，儲存、傳輸與展示時都應視為敏感資訊。

辨識後先查看結果摘要：是開啟 Add Server（新增伺服器），還是辨識為 Subscribe（訂閱）網址；地址與備註是否符合預期；是否要求跳轉至無關頁面。若辨識出的對象與預期不同，先取消並返回原始說明確認。成功解碼只代表圖片中的字元已讀取，不代表這些字元適用於目前的匯入入口。

剪貼簿匯入時檢查內容是否完整

複製分享文字後，使用用戶端實際提供的剪貼簿匯入入口；若系統詢問是否允許貼上，請依本次操作授權。完成複製與成功貼上是兩個步驟：剪貼簿內容可能被後續複製覆蓋，也可能只保存了可見標題，而不是實際連結。匯入沒有反應時，先確認目前剪貼簿中的內容類型，不要立刻重新安裝用戶端。

多行文字尤其容易出現範圍問題。單一分享連結通常必須保持完整，畫面上的自動換行也不等於文字中真的有換行字元。若複製內容夾帶說明段落、清單編號或引號，先取出明確的連結主體；若內容本來就是需要整份匯入的設定，就不能擅自刪除段落。不同對象需要不同的整理方式，不能用同一套刪減規則處理所有文字。

1. 核對原始內容說明，確認它是訂閱、單一分享連結，還是設定。
2. 複製完整主體，避免一併複製段落說明。
3. 使用相符的匯入入口，查看辨識結果後再確認儲存。
4. 返回清單檢查新增對象，確認沒有重複加入原有項目。

分別處理辨識失敗與權限問題

若掃描失敗但原始文字可以匯入，通常應優先檢查圖片清晰度與 QR Code 完整性；若原始文字也無法辨識，再檢查連結前綴、字元截斷與協定支援情況。不要裁掉 QR Code 的角落後繼續嘗試，因為圖案留白與定位結構都會影響辨識。一次只改變圖片條件或文字內容中的一項因素，才能判斷哪個步驟有所變化。

若貼上入口讀取不到內容，先確認是否已完成系統授權，以及複製後是否進行了其他會改寫剪貼簿的操作。若能辨識但儲存後失敗，就繼續檢查參數與回應，不要停留在權限層面。權限解決的是「能不能讀取」，參數解決的是「讀取的內容能不能使用」，兩者應分別確認。

匯入完成後，可以複製一段一般文字覆蓋目前剪貼簿，降低之後誤貼的機會，但這不代表所有歷史紀錄或跨裝置副本都已刪除。暫存圖片、聊天附件與其他裝置上的副本仍須分別管理。若內容已公開傳播，只清空剪貼簿無法撤銷存取；請向你的服務商詢問憑證處理方式，再確認舊憑證的狀態。

四、分享連結格式與設定語法界線

分享連結會將伺服器參數編碼成一段文字，再由匯入器將參數對應至相應欄位。不同協定採用不同結構，因此「看起來都是一長串字元」不代表內部格式相同。排查時先看前綴，再看主體與參數；不要對所有連結一律解碼、重新編碼或替換符號，以免破壞原本有效的內容。

依結構閱讀，不以長度判斷

vless://[email protected]:443?security=tls&type=ws&host=example.com&path=%2Fws#Example

這是一條用來說明欄位的範例。前綴標示 VLESS，使用者名稱位置放置範例 UUID，網域與連接埠描述連線目標，問號後是安全與傳輸參數，井號後的片段通常用來顯示備註。這裡的假資料不是可用憑證。理解結構有助於找出遺漏項目，但不能因此把任意伺服器拼成可用連結。

範例中的 %2F 表示編碼後的斜線。傳遞連結時，部分字元需要編碼，以免被誤認為分隔符號；而在 Add Server（新增伺服器）的獨立欄位中，通常應看到對應的實際欄位值。不要將整段連結參數原樣貼進路徑欄位，也不要再次解碼已正確解碼的值。核對時應查看最終欄位，不要只看連結文字是否相似。

不同前綴對應不同讀取方式

Shadowsocks 的分享格式可能包含編碼後的身分資訊；VMess 常見格式需先解析編碼內容才能看到內部欄位；Trojan 與 VLESS 外觀可能相近，但身分欄位與安全要求不同。不能只更換前綴，就把一種協定轉換成另一種。遇到無法辨識的內容時，應先確認原始格式與用戶端支援情況，不要自行猜測轉換規則。

訂閱網址通常用於請求一組伺服器。外觀可能像一般網頁網址，但回應內容必須符合用戶端可辨識的訂閱格式。網址以安全連線開頭，並不能證明回傳的一定是訂閱；登入頁面或錯誤頁面也可能正常顯示。此時要根據匯入結果與錯誤訊息判斷，不要在公開場合展示完整請求網址詢問格式。

分享連結不等於 Config 規則文字

Config（設定）中的規則用來描述流量比對與策略，不是單一伺服器的分享連結。以下片段展示先比對特定網域，再比對地址範圍，最後由兜底規則決定其餘流量的處理方式。這只是設定中的規則部分，不能單獨取代完整設定，也不會自動提供名為 PROXY 的實際連線目標。

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

規則依序比對，命中較早的規則後，不會因為後面有一條更符合個人預期的規則而重新選擇。PROXY 與 DIRECT 是策略關鍵字，不可任意改寫成中文。設定中的策略指向何處、目前選取哪個伺服器，以及 Global Routing（全域路由）處於哪種狀態，都需要分別核對；成功匯入清單只解決其中一部分。

遇到「伺服器測試有回應，但特定網頁的流量走向不對」時，先確認使用的是哪份設定及哪條規則，而不是重新產生分享連結。若問題涉及 REJECT，可閱讀REJECT 規則與比對範圍。將連結解析問題與規則比對問題分開，才能避免無關地修改有效的身分參數。

保留原始連結時，也應記錄它代表單一伺服器還是訂閱入口，以及用途與取得來源。不要只靠備註判斷，因為備註可能重複，也可能在更新時變更。需要比較兩個連結時，優先在本機檢視差異，並隱藏敏感欄位後再記錄結論；不要將原始內容當成一般筆記分享。

五、訂閱更新策略與失敗復原

更新訂閱會再次請求原始網址，並依據回傳內容調整該訂閱關聯的伺服器集合。這不是重新整理整個用戶端，也不是更新 App Store 中的應用程式。先分清要更新的是伺服器清單、Config（設定）內容，還是應用程式本身，再前往對應入口；這三種對象的更新時間與失敗原因並不相同。

更新前保留可供比較的狀態

手動更新前，記下目前的訂閱備註、選取項目與清單大致結構。若正在使用其中一台伺服器，也要留意更新可能刪除或重新命名該項目，讓原本的選取不再對應相同對象。重要操作前保存有效資訊的私人副本，比更新失敗後憑記憶重建更穩妥；但備份不應只有一張看不見完整欄位的清單截圖。

更新入口應用於既有訂閱，不必每次重新新增相同的 URL（網址）。完成後檢查錯誤訊息、項目變化與目前選取項目，不要只看介面短暫出現的更新動畫。即使清單看起來相同，也可能是遠端內容沒有變化；這本身無法證明請求失敗。反過來，項目數量改變也不代表所有參數都符合預期。

依請求、回應、解析三個層面排查

第一層確認請求能否到達訂閱網址，包括目前網路、網域解析與連線是否正常。第二層確認回傳的是不是預期內容，而非登入提示、存取錯誤或憑證失效說明。第三層才是解析：內容是否為空、格式是否受支援、文字是否遭截斷。分層處理可避免一看到「更新失敗」就直接修改伺服器密碼；後者通常不會影響訂閱請求本身。

若只在某種網路環境下失敗，條件允許時先改用另一個既有網路驗證，再比較錯誤階段。不要將完整訂閱網址貼到公開檢測工具，因為查詢參數可能就是存取憑證。瀏覽器能顯示本文，只能證明瀏覽器這次取得了內容，不能保證用戶端請求使用完全相同的網路條件與回應格式。

若提示與帳戶狀態或憑證有關，請向你的服務商取得目前有效資訊，確認是否需要更換訂閱網址。不要透過刪除查詢參數、縮短路徑或調整大小寫來試探。若必須更換網址，先記錄原有群組與目前選取項目，修改後核對新清單，再處理重複內容。原網址失效與新網址可用，是兩項需要分別確認的結果。

自動更新以便於追蹤為原則

若設定中提供訂閱自動更新選項，先閱讀觸發條件，再依實際需要啟用。系統在背景執行會受到裝置狀態與系統排程影響，不能把自動更新當成嚴格準時執行的工作。長時間未開啟應用程式、網路切換或背景執行受限時，都應以實際清單與手動檢查結果為準，不要根據預設時間推斷更新已成功。

也不必為了「保持最新」而頻繁重複請求。過密的嘗試會讓前後狀態難以比較，也可能遇到遠端請求限制。排查時先停止重複操作，保存一次完整錯誤資訊，檢查後再進行一次可追蹤的重試。恢復正常後，選一個項目進行連線驗證，確認更新沒有改變原本依賴的參數或選取關係。

若更新後清單變成空白，先停止繼續整理與刪除，保留仍可使用的原有資訊。空清單可能是遠端實際回傳空內容，也可能是格式或身分問題；不能只憑介面空白判斷。請依照五步自我檢查清單逐項檢查，復原後再比較更新前後的項目。詳細錯誤分類也可參閱常見問題。

最後為更新建立簡單紀錄：執行原因、是否成功、清單是否變動，以及是否重新測試連線。紀錄不必包含憑證，也不應編造固定更新週期。它的作用是在下次發生異常時提供可比較的起點，而不是把每次變化都歸因於用戶端設定。

六、多訂閱整理與設定關係

管理多個訂閱的重點，不是把所有項目混成一張更長的清單，而是保留來源區隔、明確目前選取項目，並讓更新與刪除都有可追蹤的歸屬。整理前先區分訂閱管理的項目與手動新增的項目；名稱相同不代表屬於同一集合，網址相同也不能單獨證明兩筆紀錄完全相同。

備註記錄用途，不記錄秘密

訂閱備註適合使用自己看得懂的用途與編號，例如「日常連線 A」、「備用測試 B」。不必在備註中堆疊所有協定欄位，也不要加入密碼、完整訂閱網址或身分參數。伺服器顯示名稱可能由遠端內容決定，並隨更新改變，因此本機管理紀錄應著重「屬於哪個訂閱、用於什麼任務」，而不是只記住某個項目的名稱。

重複項目通常來自重複匯入、同時保留手動與訂閱副本，或不同集合恰好包含相同連線目標。判斷是否重複時，至少比較協定、地址、連接埠、身分與傳輸設定；兩筆紀錄可能只差一個路徑或憑證名稱，卻足以影響能否連線。不要因清單名稱相同就批次刪除，也不要為了讓清單整齊而改寫遠端提供的參數。

若要保留手動副本，請清楚標示用途，並記錄它不會隨原訂閱自動更新。若要清理重複訂閱，先確認哪一組有有效更新網址、目前選取項目屬於哪一組，以及另一組是否保存了獨有項目。確認後再刪除多餘對象，並在下次更新後重新檢查，避免重複項目只是暫時隱藏，實際上並未消除。

伺服器集合與 Global Routing 分開管理

Global Routing（全域路由）決定流量採用哪種整體處理模式，無法取代訂閱管理。新增訂閱不會自動將它設為目前連線目標，也不會自動改寫規則。排查時先確認模式，再確認選取的伺服器與設定，最後才分析個別規則；若混淆這些層級，容易誤以為「已切換訂閱但沒有變化」。

表格描述的是路由模式，並非對所有系統流量細節的絕對保證；實際處理方式也與系統及相關設定有關。若在 Direct（直連）模式下存取正常，不能據此認定剛匯入的伺服器可用。若在 Config（設定）模式下，某個目標使用 DIRECT，也不能把這次存取當成代理連線測試。驗證時必須確認流量實際採用的策略。

也要核對設定引用與自動連線

若設定中依名稱引用伺服器或策略群組，更新導致名稱變更時，就需要重新核對引用關係。不要假設新項目會自動承接舊名稱的所有用途。編輯設定前先備份，再檢查引用、規則順序與兜底策略；一次只調整一處，避免同時更換設定與整個訂閱後，無法比較結果。

On Demand（依需求連線）是依系統條件觸發連線的相關設定，不是訂閱更新工具。整理或切換時，若連線自動重新建立，也應檢查是否啟用了此功能，不要把現象歸因於清單儲存失敗。需要進行可重複測試時，先確認自動連線狀態，測試結束後再恢復原本設定，避免留下與日常使用不同的行為。

建議依序整理：先命名，再核對歸屬，接著驗證目前選取項目，最後刪除確定不需要的對象。每完成一個階段，就返回 Home（首頁）檢查結果。即使某個群組失效，也只需處理對應集合，不會因一次清理動作而破壞所有手動紀錄與設定引用。

多部裝置之間也應使用一致的用途說明，但不要假設它們的清單、選取項目與設定已經同步。若要在 iPhone 與 iPad 上重現相同結果，應分別核對訂閱、目前項目與路由模式。系統需求與裝置相容性以 App Store 頁面標示為準，取得方式請參閱iPad 下載與首次開啟。

七、Connectivity Test 延遲測試與排序

Connectivity Test（連線測試）的結果只描述特定測試方式在某次條件下的表現，不代表所有網站、所有協定流量或持續傳輸都正常。測試前先確認測試對象、方法與目前網路，測試後再實際瀏覽驗證。清單中的數值適合用來輔助篩選，不適合當成長期穩定性或傳輸速度的保證。

先釐清測試涵蓋哪個層面

連線目標能回應，表示部分網路路徑可能可達；透過代理完成一項請求，則還涉及身分、加密、傳輸與目標存取。不同測試方法涵蓋的層面不同，不能直接把某種測試成功套用到其他條件。若測試介面允許選擇方法，先了解目前使用的方法，再以相同方法比較同一組項目，不要把不同條件下的結果混在同一次排序中。

某個項目逾時，也不必立刻刪除。可能是該目標暫時沒有回應、目前網路限制了相關傳輸、解析失敗，或測試請求本身無法代表實際使用情境。先在相同網路下重新測試一個狀態已知的項目作為參照，再檢查失敗是否集中於某類協定。確認共同條件後，再回到 Add Server（新增伺服器）逐項核對參數。

建立可重複的比較流程

1. 記錄目前網路與 Global Routing（全域路由）模式，確認期間沒有更新清單。
2. 使用相同的測試方法檢查要比較的項目，測試期間避免切換網路。
3. 針對異常結果重新測試，觀察是否持續發生，不要只保留最好的一次。
4. 選取一個項目建立連線，再透過實際使用情境確認解析與存取結果。

比較時盡量減少變因：不要一邊下載大量內容，一邊把數值變化歸因於伺服器；也不要在 Wi-Fi 與行動網路之間切換後，繼續沿用同一張比較表。數值會隨時段、壅塞狀況與目標而變，記錄測試條件比保存單一數值更有用。排查時應追求結果可解釋，而非追求畫面上最低的數值。

對於 Hysteria2 等涉及 UDP 的協定，一般連線回應無法涵蓋所有傳輸條件；採用不同傳輸方式的項目，也不能只憑同一項簡單測試判斷優劣。若想了解協定設計與適用範圍，可閱讀Hysteria2 與 QUIC 基礎說明。管理決策應參考實際用途與重複觀察，而非根據協定名稱預先下結論。

排序只會改變瀏覽順序

介面若提供依測試結果排序，先確認排序範圍是目前群組還是全部項目。排序後重新確認選取標記，不要自動把清單第一項當成目前連線對象。訂閱再次更新也可能改變清單順序或顯示名稱，因此日常使用應明確選取，不要只記得「上次排在最上面的是哪一個」。

數值較低只代表該次測試完成得較快，不代表大型檔案傳輸更快，也不表示長時間連線更穩定。需要完成某項工作時，先確認實際存取正常，再觀察是否持續中斷。頻繁切換項目會同時改變路徑與連線狀態，反而不利於排查；少量候選逐一驗證，比不斷對全部項目排序更容易得出可靠結論。

延遲正常但網頁無法開啟

此時先檢查是否真的選取了受測項目、Global Routing（全域路由）是否符合測試目的，以及相關目標是否在 Config（設定）中採用了其他策略。接著區分網域解析失敗、連線逾時與憑證錯誤。錯誤發生階段不同，處理方向也不同；不要因清單顯示數值，就略過 DNS 與規則檢查，直接重新填寫所有身分參數。

若只有網域無法存取，可依照DNS 設定與網頁無法開啟的排查順序檢查，但不建議把暫時改用地址存取當成長期解決方式，因為憑證、目標分流與應用程式請求仍可能依賴網域。若所有實際存取都失敗，就回頭逐層核對協定、傳輸與網路條件；沒有證據時不要反覆切換路由規則。

向他人描述異常時，提供測試方法、發生條件、錯誤階段與已完成的檢查即可。隱藏地址與憑證後，仍然可以說明「訂閱能更新、項目能測試、某類存取失敗」這條證據鏈。這樣的紀錄比只有延遲數值的截圖更有助於縮小問題範圍。

八、刪除、備份與重新匯入後的確認

刪除前先確認對象層級：刪除單一伺服器、刪除一個訂閱集合、移除某份 Config（設定），以及刪除應用程式，都不是同一項操作。先查看確認提示所描述的對象與範圍，再決定是否繼續。不要把「重新新增很快」當成備份，因為遠端網址可能失效，手動修改也未必能從訂閱重新取得。

依復原目標準備備份

若只要復原伺服器集合，通常需要有效的訂閱網址或完整伺服器參數；若要復原規則行為，也需要目前使用的設定與相關引用；若要復原手動修改，則需要原始值、修改後的值及修改原因。清單截圖只能協助辨認名稱，不能取代可用於復原的欄位資料。備份前先確認希望復原到什麼狀態，再收集所需內容，而不是只保存一個看似完整的檔案。

若用戶端提供對應對象的匯出或分享功能，先確認匯出內容的範圍，再儲存至自己掌控且有保護的位置。匯出伺服器不一定包含規則，匯出設定也不一定包含所有本機設定。無法確認涵蓋範圍的選項，應另外記錄必要狀態，例如目前的設定名稱、Global Routing（全域路由）模式，以及 On Demand（依需求連線）是否已啟用。

備份可能包含完整存取憑證，應限制可見範圍，不要放在公開筆記、共享相簿或公開附件中。即使只是訂閱網址，也應視為秘密。檔名與備註使用用途標記，不要直接寫入密碼。更新備份後，檢查儲存位置與存取權限，避免主要檔案受到保護，暫存副本卻散落在其他位置。

刪除前檢查引用關係與目前選取項目

準備刪除單一伺服器時，先確認它是否由訂閱管理；若是，後續更新可能會再次加入。準備刪除整個訂閱時，檢查其中是否包含目前連線對象、獨有的手動修改或設定引用。不要假設刪除後所有關聯都會自動修復；完成後仍應分別檢查清單與設定。

若只是暫時不使用某個集合，先判斷是否真的必須刪除；保留清楚的備註與有效備份，可能比立即清空更容易復原。確定刪除時逐一處理對象，不要在範圍未確認前連續批次操作。若結果與預期不符，立即停止後續清理，利用剛保存的資訊復原，避免將可復原的問題擴大成所有狀態遺失。

重新匯入不代表復原已完成

1. 先復原訂閱或手動新增的伺服器，核對類型、地址與傳輸欄位。
2. 再復原需要的 Config（設定），檢查策略引用與規則順序。
3. 確認 Global Routing（全域路由）模式，並明確選取一個有效項目。
4. 進行連線測試與實際存取驗證，最後再恢復自動連線相關設定。

這套順序的目的是讓每個步驟都有獨立的確認結果。若先開啟自動連線，再批次匯入設定與訂閱，連線狀態可能在操作期間改變，錯誤也難以判斷來源。復原時保留原始備份，不要因為第一次匯入成功就立即覆蓋；確認日常工作正常後，再將新的有效狀態另存為後續復原起點。

更換裝置或重新取得應用程式時，App Store 的已購項目紀錄可用來找回應用程式，但不代表訂閱、伺服器與規則都必然會一併復原。取得應用程式與復原資料是兩回事。購買與裝置條件以 App Store 頁面標示為準，請先閱讀已購項目復原說明，再依自己的備份復原內容，不要依賴未經確認的同步假設。

憑證變更與舊副本處理

若重新匯入是因為連結或憑證已變更，請確認新內容確實生效，並找出舊項目是否仍留在其他群組中。刪除本機副本不會撤銷遠端憑證，遠端憑證失效也不會自動清除所有備份。兩者應分開處理：向你的服務商確認存取有效性，完成復原後再依保留需求清理本機副本。

結尾時檢查三件事：能否明確辨認目前的連線對象、使用的設定與路由模式是否符合預期，以及備份是否包含復原所需的完整資訊。也應清理暫存剪貼簿、QR Code 圖片與不再需要的匯出副本，但不要誤刪唯一有效的備份。管理目標不是讓清單最短，而是確保下次更新、排查與復原時都有明確起點。

完成整理後，可返回入門指南依照完整流程重新驗證一次。若仍有異常，請在常見問題中依「匯入、更新、連線」等階段查閱；記下已確認的事實與尚未確認的條件，避免重複修改已知正確的設定。