01 · Subscribe：建立可更新的訂閱記錄
訂閱的用途，是將遠端清單儲存為可重複更新的入口，而非只新增幾台伺服器一次。匯入成功後，應同時檢查訂閱記錄及其展開的伺服器項目：前者保存網址與更新關係，後者供選擇連線。清單變長不代表訂閱關係正確；只儲存網址，也不代表已成功讀取遠端內容。先分清這兩個層次，後續較容易判斷問題出在更新還是連線階段。
匯入前：辨識輸入內容
現有訂閱應向你使用的服務提供者取得。先確認這是供 Shadowrocket 使用的訂閱網址，而非帳戶管理頁面、說明頁面或單一伺服器分享連結。訂閱網址通常屬於個人憑證，即使看起來只是一般網頁網址，也可能直接授權讀取伺服器清單。請勿將完整網址貼到公開筆記、聊天室或問題截圖中；自行核對時，也應避免螢幕錄影或剪貼簿同步洩漏其中的存取參數。
匯入前先保留一份原始文字，檢查開頭、結尾和中間是否混入空格、換行或中文標點。特別留意通訊軟體自動加上的句號，以及除了複製按鈕內容之外一併選取的說明文字。不要自行刪除查詢參數，也不要將不熟悉的字元換成看起來較熟悉的形式。網址中的大小寫、路徑與參數可能用於識別；整理顯示名稱和修改實際網址，是完全不同的操作。
在 Add Server 中選擇 Subscribe
在 Home 開啟新增入口，進入 Add Server 後，將 Type 設為 Subscribe，再填入完整網址，並以容易辨識的備註儲存。介面配置可能因裝置而異，請以目前 App 顯示為準。第一次操作只新增一筆訂閱，儲存後確認是否出現相應清單，再處理下一筆；同時匯入多個網址會讓錯誤來源難以區分，也容易把重複記錄誤認為更新產生的新內容。
儲存後返回 Home，核對訂閱名稱、展開的項目及預期伺服器是否相符。不要把清單中的說明項目直接當成可連線的伺服器；若名稱含有狀態提示，請搭配項目類型及詳細資料判斷。接著選擇一台已確認參數完整的伺服器進行連線測試。匯入與連線是兩個獨立結果：前者取決於網址存取與內容解析，後者還取決於伺服器可連線性、驗證及傳輸設定。
失敗時：分層檢查存取、內容與結果
如果儲存後沒有項目，先檢查網址是否完整，再確認目前網路能否連上訂閱所在的主機。瀏覽器能開啟某個頁面，不代表該頁面回傳的是可供匯入的清單；登入頁、提示頁或存取錯誤都可能以網頁形式呈現。不要把這些頁面的文字當成伺服器資料繼續手動填寫。向服務提供者確認時，只需說明匯入入口、錯誤文字與發生階段；提供截圖前，請先遮蔽網址中的個人存取參數。
如果現有訂閱更新失敗，先保留舊記錄，不要馬上刪除重建。比較失敗前後伺服器是否仍存在、選取項目是否變更，以及是否只有某筆記錄無法使用。若訂閱網址已更換，先新增記錄並確認可用，再處理舊記錄。這樣能保留復原方式，也能區分網址失效與伺服器本身故障。若要重新走過最簡單的連線流程，可回到使用說明；尚未找出原因前，不要反覆修改所有設定。
02 · Add Server：依協定核對手動填寫欄位
手動新增適用於已取得單台伺服器完整參數的情況。進入 Add Server 後，先確認 Type，再填寫位址、連接埠與驗證資料。不同協定的欄位並非只換個名稱、參數就相同：同樣稱為密碼的內容，不能代替其他協定所需的 UUID、金鑰或驗證字串。若缺少欄位，請回頭核對原始說明，不要憑名稱相似自行推斷，更不要複製另一台可用伺服器的驗證資料。
先核對通用欄位，再處理協定差異
伺服器位址填入主機名稱或位址本身，不要把整段網頁連結貼進位址欄；連接埠則依提供的資料分開填寫。備註只供辨識，不參與連線驗證，可以用「用途、來源、傳輸特徵」組合命名，但不要把密碼放進名稱。位址相同、連接埠不同，可能代表完全不同的服務。反過來說，兩筆記錄名稱不同，實際上也可能使用相同連線參數，因此查重時必須查看詳細資料。
驗證欄位應逐字核對，特別留意複製時混入空格、相似字元，或長字串被通訊軟體截斷。填寫密碼時，不要因介面以圓點顯示，就認定複製內容一定完整；如有疑問，請從自己的原始記錄重新貼上。UUID 也不應當作一般備註重新排版。確認位址、連接埠及驗證資料後，再檢查 TLS 與傳輸層，避免一次修改太多項目而失去排錯依據。
| Type | 核對重點 | 常見混淆 |
|---|---|---|
| Shadowsocks | 位址、連接埠、密碼、加密方法 | 加密方法必須與伺服器設定相符 |
| VMess / VLESS | UUID、傳輸方式、TLS 及相關參數 | 不能只修改 Type 就完成協定轉換 |
| Trojan | 密碼、TLS、伺服器名稱 | 連線位址不一定等於 TLS 驗證名稱 |
| HTTP / SOCKS5 | 位址、連接埠、驗證需求 | 是否需要驗證，依伺服器設定而定 |
| WireGuard | 金鑰、位址、對端及路由參數 | 金鑰不能以一般密碼代替 |
| Hysteria2 | 驗證、TLS 與 UDP 可連線性 | 本地網路限制可能影響連線 |
TLS 與傳輸層：名稱相近不代表意思相同
連線位址用來找到伺服器；TLS 伺服器名稱用於握手與憑證驗證；HTTP 傳輸中的 Host 則可能用於應用層路由。某些設定中這些值相同，但不能因此認定永遠可以互換。若服務資料指定了獨立名稱、路徑或傳輸方式，請分別填入對應欄位。路徑開頭的斜線、大小寫及查詢部分也可能影響伺服器端識別，不宜為了方便閱讀自行簡化。
出現憑證錯誤時，先檢查伺服器名稱、裝置時間及伺服器端憑證狀態，不要把略過驗證當成一般解法。憑證驗證失敗與密碼錯誤的處理方向不同：前者通常要檢查握手身分，後者才需核對驗證資料。如果目前網路連伺服器連接埠都無法到達，繼續切換驗證欄位也不會改善結果。依序檢查網路、握手、驗證及實際請求，比反覆嘗試無關的開關更能保留有效線索。
儲存後的驗證與修改範圍
儲存前再次確認 Type 與原始資料相符；儲存後只測試這台伺服器，不要同時切換 Config 檔案和本地網路。如果剛新增的項目來自訂閱，應優先考慮透過更新訂閱取得修正內容；直接修改由訂閱產生的欄位，後續更新時可能會被覆蓋。如需進行對照測試，可另外保留一筆手動記錄，並在備註中標明是臨時核對項目，避免日後把測試結果誤認為訂閱原始參數。
手動填寫不會自動補上未知參數，也不會驗證伺服器端是否接受這些組合。儲存成功只能表示 App 接受了輸入格式。連線失敗時，記下具體階段與錯誤，再判斷是否需要補充欄位。UUID、傳輸層與 TLS 的關係可搭配VMess 與 VLESS 參數說明閱讀；若只是要辨識協定名稱，查閱術語手冊即可，不必先調整整份設定。
03 · Scan QR Code 與剪貼簿：減少複製錯誤
掃描 QR Code 和剪貼簿只是輸入方式，不會決定輸入內容屬於訂閱、伺服器還是設定檔。一個 QR Code 可能包含單一伺服器連結，也可能只是一般網頁網址；剪貼簿中的文字亦然。匯入前先辨識來源與用途，匯入後再檢查產生的記錄。看到成功提示不代表參數適合目前網路，也不能取代對位址、驗證及傳輸設定的核對。
掃描前：確認 QR Code 中的內容
準備掃描時，先確認 QR Code 來自你已有的伺服器資料，並與相關說明相符。使用 Scan QR Code 時，依系統提示授予相機存取權限；若無法開啟相機，先到系統設定檢查權限，再返回 App 重試。QR Code 顯示在另一台裝置上時，調整亮度與距離，確保四周邊界完整。反光、裁切、過度壓縮或模糊縮放都會影響辨識，不應透過修改伺服器參數來解決影像辨識問題。
若 QR Code 位於目前裝置的圖片中，先查看 App 目前是否提供從圖片辨識的選項；若沒有顯示，不必尋找與目前介面不符的固定按鈕。可以使用相關資料提供的文字連結，透過剪貼簿匯入，並在儲存後逐項核對。不要因圖片難以辨識就把 QR Code 上傳到公開辨識網站；其中可能包含密碼、金鑰或完整訂閱網址，公開圖片與公開文字有相近的外洩風險。
剪貼簿匯入：一次只保留一種內容
複製時盡量使用原始資料提供的完整複製功能，避免手動拖曳選取時漏掉開頭或結尾。返回 Shadowrocket 後，使用目前介面提供的剪貼簿匯入入口，並依系統提示決定是否允許讀取。如果沒有出現預期提示，先確認剪貼簿仍是剛複製的內容：切換 App 後再次複製其他文字、使用跨裝置剪貼簿或複製圖片，都可能取代原本的文字。
批次文字特別容易混入編號、項目符號和介紹段落。第一次建議只匯入一筆已確認的連結，確認欄位正確後再處理其餘內容。如果整段文字無法辨識，先檢查是否含有程式碼區塊、引號或訊息引用符號，不要直接改寫連結中的符號。不同格式對換行的解讀可能不同；若無法確認，請回到原始資料取得清楚的單筆連結，不要強行把多行內容拼成一個網址。
匯入後的三項核對
第一項核對記錄類型：預期匯入訂閱，就檢查是否有可更新的訂閱記錄；預期匯入單台伺服器，就檢查是否出現相應伺服器。第二項核對關鍵欄位，至少確認 Type、位址與連接埠，再檢查驗證和傳輸設定是否完整。第三項核對清單歸屬，確認項目沒有混入另一組訂閱或重複測試記錄。名稱相同不代表匯入結果完全相同，名稱不同也不一定代表新增了不同伺服器。
如果重複掃描後出現多筆記錄，先保留其中已確認可用的一筆，逐項比較其他記錄後再決定是否清理。尚未驗證前，不要刪除所有原有記錄。若掃描產生了項目卻無法連線，應轉而排查欄位與網路，不要持續掃描同一個 QR Code。QR Code 辨識、連結解析和建立連線是三個階段；反覆執行第一階段，通常無法修復第三階段的問題。
權限也應依用途管理。相機用於掃描，剪貼簿用於讀取你主動複製的內容，兩者與系統 VPN 設定授權並非同一項權限。匯入完成後若要收緊權限，可在系統設定中調整；下次使用相關入口時再重新確認。初次連線與授權提示的順序請參閱使用說明；若已取得記錄但無法使用，請依連線排查步驟定位問題，不必反覆重設權限。
05 · 更新策略：先保留復原方式再修改
訂閱更新會重新讀取遠端內容，並據此調整本機清單；它不是逐台修復伺服器，也不保證目前使用的伺服器會繼續保留。安排更新前，應先確認目前選取哪筆記錄、它隸屬哪個訂閱，以及是否有設定依賴該名稱。把更新視為受控的資料變更，先核對結果再清理舊項，比連線異常時連續重新整理更容易找出問題。
哪些情況適合手動更新
服務資料明確變更、清單缺少預期項目，或需要確認訂閱是否仍可讀取時，可以手動更新。更新前記下訂閱名稱與目前選取項目；更新後檢查清單是否新增、刪除或變更名稱。如果 App 提供自動更新相關設定，請依實際入口選擇，不要把固定更新間隔當成適用於所有人的要求。更新頻率也應考量網址使用規則與個人使用習慣。
頻繁更新不代表連線更穩定。遠端清單沒有變化時，重複讀取通常只會得到相同內容；某台伺服器連接埠無法連線時，更新也未必能改變結果。先判斷故障是否與清單過期有關，再決定是否更新。手動建立的伺服器沒有訂閱關係，不能期待透過更新另一個訂閱來同步修正。如果原始資料中的參數已更換，應依資料對應的管理方式處理，而非對所有清單重複操作。
更新失敗：先查看錯誤，再選擇存取路徑
更新取決於目前連往訂閱主機的網路路徑。有時本地網路可以直接連線，有時目前的連線狀態會影響存取結果。遇到失敗時，先記錄是否有解析錯誤、連線逾時、驗證失敗或內容無法辨識，再檢查相應環節。不要只看到「更新失敗」就切換所有路由設定；調整存取路徑時也應一次只改一項，重試後確認結果，才能判斷究竟是哪個步驟造成影響。
若網址可存取，但回傳登入提示、存取限制或空內容，問題不一定出在 App 解析。訂閱網址中的個人存取參數可能已變更，遠端也可能暫時回傳錯誤頁面。此時應保留原網址的私密副本，並向自己的服務提供者確認狀態。不要把錯誤頁面存成 Config 檔案，也不要拿頁面中看起來像網址的文字來建立伺服器。內容類型不正確時，繼續修改伺服器連接埠沒有幫助。
處理覆寫、重新命名與清單異常清空
訂閱產生的記錄應盡量維持與遠端一致。直接修改這類記錄的驗證、傳輸或備註，更新後可能被重新寫入，也可能造成難以辨識的差異。需要長期保留的獨立測試，建議建立清楚標示的手動記錄，並與原訂閱分開。如此一來，更新後的變化仍能追溯至遠端內容，不會把本機臨時修改誤認為服務提供者下發的參數。
如果更新後清單明顯縮減或只剩說明文字，先停止進一步清理。檢查原訂閱是否仍在、目前選取項目是否消失，以及更新結果是否符合服務資料。不要為了讓清單看起來正常就立即刪除整個訂閱，這會一併失去網址與歸屬線索。若確實需要更換網址，先建立新記錄，確認清單展開和連線結果，再決定是否保留舊記錄；舊憑證失效時，也應在自己的備份中同步註記。
請分開理解 App 更新、訂閱更新與 Config 更新。App 透過 App Store 更新；訂閱更新會讀取伺服器清單；Config 的變更則影響規則及相關設定。三者可能在相近時間發生，但不能因此認定其中一項會自動完成另外兩項。排錯時寫清楚「更新了什麼、更新前狀況、更新後狀況」，比籠統地說「更新後不能用」更有助定位問題。App 取得與更新入口請參閱App Store 下載指南。
06 · 多訂閱整理：先保留來源，再處理重名
管理多個訂閱的首要目標，是讓每台伺服器都有清楚來源，而非盡量縮短清單。名稱相同、地區說明相同或延遲接近，都不能證明兩筆記錄重複。同一訂閱中的多台伺服器也可能共用位址，卻使用不同連接埠、驗證或傳輸設定。清理前應先查看訂閱歸屬，再比較連線參數，避免誤刪仍有不同用途的記錄。
建立便於長期使用的命名方式
訂閱備註可使用穩定的內部標籤，例如「日常」、「備用」、「測試」，再加上自己能辨識的來源簡稱。名稱應協助區分用途，不應包含密碼、完整訂閱網址或私人身分資訊。伺服器名稱通常由遠端提供，更新後可能變更，因此不要只靠名稱記住重要記錄。對常用伺服器，另外記下所屬訂閱及關鍵連線特徵，移轉時會更容易核對。
不要為了整齊而反覆重新命名訂閱產生的所有項目。這些變更可能在更新時被覆蓋，也可能破壞依賴名稱的設定關係。較容易掌控的做法是先整理訂閱層級，再保留原始伺服器名稱；需要測試時，以獨立手動記錄附上臨時說明。名稱中的地區或線路文字只能視為提供者的標示，不能據此認定伺服器實際位置、效能或目前可用性。
查重時應比較哪些資訊
先比較 Type、位址和連接埠，再檢查驗證、TLS 名稱、傳輸方式及相關參數。所有欄位都相同的記錄可能只是重複匯入，但仍須確認是否隸屬不同的更新關係。若兩個訂閱恰好包含同一台伺服器，刪除其中一個訂閱可能同時失去該來源未來的變更資訊。應依自己的管理需求決定保留哪個，而非只看目前清單是否重複。
處理重名時，不要先批次刪除，再憑印象重建。可以一次選擇一個訂閱，記錄其項目特徵，核對完成後再處理下一個。若記錄已失效但仍需追查原因，先保留私密備註，再決定是否刪除。清單中的狀態說明也應另外辨識：它們可能用於傳達帳戶或使用狀態，不能一概視為「無法連線的伺服器」，更不應據此推論所有實際伺服器都無法使用。
| 觀察到的情況 | 先核對 | 再決定 |
|---|---|---|
| 名稱完全相同 | 歸屬、Type、位址與連接埠 | 是否為不同伺服器 |
| 參數看起來相同 | 驗證、傳輸與更新關係 | 是否需要保留兩個來源 |
| 更新後出現重名 | 遠端變更與舊手動記錄 | 是否清理測試副本 |
| 某筆測試失敗 | 測試方式與網路條件 | 是否暫時保留而非刪除 |
整理清單不等於變更路由
調整順序、修改備註或刪除重複項目，主要影響管理方式；實際請求如何處理，仍受 Global Routing 與目前 Config 影響。某台伺服器排在最前面，不代表所有請求都會使用它。使用 Config 時，符合 DIRECT 的請求仍依規則直連；選擇 Proxy 時，也要確認目前選取的伺服器正是準備使用的那一台。整理清單後，至少再次確認選取狀態。
多個訂閱並存，不代表 App 會自動從所有項目中挑選最佳伺服器。是否具備自動選擇或切換功能，需視目前設定及實際使用的相關功能而定，不能從清單數量推斷。為了得到可判讀的結果，先以明確選取的一台伺服器進行測試，再考慮更複雜的選擇邏輯。不要把測試失敗的項目不斷複製到不同訂閱中；這只會增加重複記錄，不會改變伺服器端狀態。
每次整理完成後，簡單檢查一次：訂閱網址仍已儲存、重要伺服器容易辨識、目前選取項目正確，獨立測試記錄也有清楚標籤。若準備更換裝置，再記錄需要的 Config 與更新關係。少量分批整理通常比一次大規模清空更容易復原。若不清楚詞彙意思，先查閱術語手冊；若有初次連線相關疑問，請查看使用說明中的排查章節，不要以刪除取代理解。
07 · Connectivity Test：了解延遲與排序結果
延遲測試適合初步比較伺服器回應，不適合單獨用來判斷實際傳輸速度、長期穩定性或特定網站的存取結果。不同測試方式測量的階段各異，有些著重位址或連接埠是否可連線，有些則包含更多請求流程。查看 Connectivity Test 目前的設定，先確認測量對象，再解讀結果。數值較低不代表驗證正確，也不保證後續傳輸能持續完成。
測試前固定條件，測試後保留背景資訊
比較多台伺服器時，盡量使用相同的本地網路、測試方式及相近時段。測試途中從 Wi-Fi 切換到行動網路，會讓結果混入網路連線變化。裝置背景工作、訊號波動與網路壅塞也會影響結果。第一次測試可先選少數候選伺服器，重複觀察後再擴大範圍，避免把一次性的結果當成永久排名；也不要為了得到更低數值而不斷修改無關設定。
批次測試會同時產生多個請求；本地網路或遠端處理能力有限時，結果可能比單筆測試更不穩定。如果同一台伺服器單獨測試正常，批次測試卻偶爾失敗，先縮小測試範圍再確認。若所有記錄同時失敗，優先檢查裝置是否正常連網、測試目標是否適合目前環境，以及測試方式是否受限，不要立即認定所有伺服器都已失效。
區分逾時、驗證失敗與實際請求異常
逾時表示本次測試未能在指定等待時間內得到預期結果，但不能直接說明失敗原因。問題可能出在位址解析、連接埠存取、傳輸握手或測試目標回應。若出現明確的驗證錯誤，才應優先核對密碼、UUID 或其他驗證資料。若伺服器已建立連線，但某個網站無法開啟，還要檢查規則比對、目標網域、DNS 及 TLS 等環節，不能只繼續調整延遲測試。
測試實際使用情況時，選擇自己熟悉且允許存取的一般網頁，分別觀察頁面是否完整載入、連續請求是否穩定，以及問題是否只出現在特定目標。不要只看到系統顯示已連線就結束檢查；系統狀態主要表示本機連線機制已啟用，不代表每個遠端請求都成功。也不要只憑單一頁面的快取內容就認定網路正常，應搭配新的請求及 App 可見的連線資訊判斷。
排序用於篩選，不能取代選擇與驗證
依延遲排序後，先確認排序套用在哪個清單，以及目前選取項目是否改變。排列位置變動不一定代表連線對象改變；同樣地，排在最上方的項目也不一定適合所有請求。可以從回應穩定的少數候選中選一台進行實際測試，再保留一筆備用記錄。記錄當時的網路條件，比把某個結果標記為固定效能更有參考價值。
Global Routing 也會影響如何解讀存取結果。使用 Config 時，目標可能符合 DIRECT，因此頁面正常並不能單獨證明所選伺服器可用。若要確認特定 Proxy 連線，還要確認測試目標實際採用的策略。切換路由模式只是為了明確測試範圍；測試完成後，請恢復所需設定，避免忘記臨時設定而改變後續所有請求的處理方式。
速度慢與延遲高有關，但兩者並非同一個問題。小型請求回應迅速，持續傳輸仍可能受線路壅塞、封包遺失、伺服器負載或本地網路影響。排查時先重新確認單台伺服器，再比較不同時段與網路，最後檢查協定及傳輸設定；每個步驟都保留上一輪結果。更完整的分層方法請參閱Shadowrocket 速度慢的四層排查。不要用持續重新整理訂閱取代這套驗證流程。
08 · 刪除與備份：確認可復原的範圍
刪除前先確認對象是單台伺服器、整個訂閱，還是 Config 檔案。三者影響範圍不同：刪除單台伺服器可能只影響目前清單；刪除訂閱則可能連同管理關係一起移除；刪除 Config 則可能影響規則選擇。具體關聯行為請以 App 目前的操作提示為準。沒有備份和確認前，不要連續刪除多個層級，也不要把清空清單當成處理所有連線問題的通用方法。
建立備份清單，不要只留一張截圖
備份至少應涵蓋你需要還原的訂閱網址、獨立手動伺服器參數、目前使用的 Config，以及重要偏好設定的說明。截圖可協助辨識介面，但通常看不到完整密碼、金鑰與長網址，不能取代原始資料。訂閱方面，保留可用網址有助於重新讀取清單；手動伺服器方面，則須確保驗證與傳輸細節完整，否則只記得名稱和連接埠仍無法還原。
若 App 目前提供相應的匯出或備份入口，先核對匯出對象與包含範圍，再儲存至自己管理的私密位置。不要假設檔名寫著備份就一定包含所有資料，也不要認定系統裝置備份必然涵蓋所有需要項目。較可靠的做法是在不破壞現有可用環境的前提下，檢查檔案內容或進行受控的還原測試，確認重要的訂閱關係與獨立記錄確實能找回。
刪除後的項目為何可能再次出現
由訂閱產生的伺服器由遠端清單管理；單獨刪除其中一筆後，下次更新可能再次產生相同記錄。這不一定表示刪除失敗，而是更新重新同步了遠端內容。若不再需要某個訂閱，先確認其網址已妥善保留，且目前連線不再依賴它，再處理訂閱記錄本身。若只是暫時不想使用某台伺服器，切換選取項目與刪除記錄的效果不同，不必為了停止使用就立刻清理。
刪除前也要檢查目前使用的 Config 是否依賴某些伺服器名稱或相關選擇關係。移除一筆記錄後，原有規則邏輯不一定會自動取得等效替代。刪除後重新核對 Global Routing、目前 Config 及選取的伺服器，再測試實際請求。若清單突然異常，先停止後續操作，確認是否有本機備份或原始訂閱可供還原，避免在同一輪排錯中連其他線索也一併清除。
換機還原：先少量驗證，再補齊資料
在新的 iPhone 或 iPad 上，先透過 App Store 還原 App，再檢查所需的系統授權；系統要求與購買適用性以 App Store 頁面標註為準。已購 App 的還原與訂閱、伺服器、Config 的還原是不同工作；找回 App 不代表所有連線資料也已出現。具體取得步驟請參閱已購項目還原說明。準備移轉時不要先清除舊裝置，保留它作為欄位核對與復原依據。
還原資料時，先匯入一個訂閱並確認展開結果；接著還原獨立手動記錄，最後選擇需要的 Config 並核對 Global Routing。完成一輪實際連線後，再補齊其他訂閱與偏好設定。這個順序有助於發生錯誤時找出是哪個環節引入變化。如果一開始就還原所有資料、調整網路並修改規則，雖然操作較快，卻很難判斷問題究竟來自備份內容還是新裝置環境。
還原完成後，檢查選取項目、訂閱更新、測試方式與實際請求，再決定如何處理舊資料。若懷疑訂閱網址或驗證資料曾遭公開，請向自己的服務提供者取得更新後的資料，並同步更新備份；刪除本機副本無法讓已外洩的憑證失效。最後保留一份簡潔的私密還原說明，只記錄資料類別與還原順序，不要在公開筆記中儲存敏感值。下次需要快速重新連線時，依使用說明確認主要流程；本頁則繼續供查閱欄位與管理細節。