01 / Subscribe
Subscribe:建立可更新的訂閱
訂閱是一個可重複請求的遠端網址,回傳的內容會用來建立伺服器項目。它不同於單一伺服器的分享連結,也不等同於 Config 中決定連線流向的設定檔。匯入前,先確認手上的資料屬於哪一類:若是用來取得整組伺服器的網址,請使用 Subscribe;若是以協定名稱開頭的單一分享連結,則應以伺服器方式匯入。將網頁網址、帳戶頁面或說明頁面填入 Subscribe,即使網址可以開啟,也不代表回傳內容能夠解析。
儲存前確認 URL 與備註
在 Home 使用新增入口進入 Add Server,將 Type 設為 Subscribe,再填入訂閱 URL。不同介面配置可能會將類型選項放在清單中;請確認儲存的項目確實是 Subscribe,而非任意伺服器協定。備註應說明訂閱用途,例如「個人常用」或「備用測試」,不要將完整憑據寫進備註。貼上後,仔細檢查開頭、結尾、問號與連接符號,確認沒有多出聊天引用符號、換行或句末標點,再儲存並等候首次取得完成。
https://example.com/sub?token=xxxx
上方網址僅用來說明結構,不提供實際服務。路徑用來定位資源,問號後方則是查詢參數;參數名稱與值都應完整保留,不要照著範例自行改寫自己的網址。訂閱 URL 通常具有存取憑據的作用,能讀取網址的人可能取得相應的伺服器資訊。請勿將完整網址放進公開截圖、筆記標題或問題回報內容;說明網址結構時,請改用範例網域與假值,只保留標點位置。
首次取得後要檢查什麼
儲存成功與取得成功是兩種不同狀態。先確認訂閱下方是否出現伺服器,再檢查項目類型、備註與數量變化是否符合預期;數量僅供本機核對,不代表品質。若畫面顯示錯誤,請記下錯誤原文,不要反覆建立相同訂閱。看得到伺服器也不代表已連線:還需在 Home 選取預設伺服器、檢查 Global Routing,並透過實際請求確認。首次連線的完整步驟請回到入門指南逐項操作。
若取得失敗,請依序檢查網址、網路與回應內容。先比對原始網址,確認憑據未過期或遭替換;接著確認目前網路能否存取訂閱網址;最後判斷回傳的是伺服器資料、登入頁面還是錯誤頁面。不要為了驗證而將網址提交給陌生的線上解析工具。若只有這份訂閱失敗,請保留錯誤文字與發生條件;若所有網路請求都異常,應先排除裝置網路問題,避免將同一個網路問題誤判為多份訂閱同時失效。
分開管理訂閱與連線狀態
更新訂閱會重新讀取伺服器資訊,但不代表目前的伺服器仍可使用,也不應將更新視為解決所有連線問題的按鈕。某個伺服器失效時,先用同一份訂閱中的另一個項目交叉比對,再決定是否更新。訂閱儲存的是遠端清單入口,伺服器儲存的是連線參數,Global Routing 則決定請求如何使用這些參數;將三個層次分開,才能判斷該修改網址、切換伺服器,還是檢查設定規則。
02 / Add Server
Add Server:逐欄核對手動輸入的資料
手動輸入適用於已有完整伺服器參數、需要核對匯入結果,或只管理少量獨立項目的情況。先在 Add Server 選擇正確的 Type,再填寫該類型顯示的欄位。類型決定參數意義,不能先將資料填入任意表單,再靠修改名稱來改變協定。開始前,將位址、連接埠、驗證資訊、TLS 與傳輸需求分開記錄;資料不完整時應先補齊,不要以「常見預設值」代替缺漏欄位,否則即使儲存成功,也可能無法完成交握。
通用欄位與驗證欄位
Address 填入主機名稱或 IP 位址,Port 填入對應連接埠。不要將整段分享連結貼進 Address,也不要在主機名稱後重複加上連接埠。若資料提供的是含協定前綴的 URL,應先判斷它是分享連結還是欄位說明。備註僅供識別項目,不會參與連線。驗證欄位則依 Type 而異:有些使用 Password,有些使用 UUID,另有些涉及使用者名稱或金鑰。複製驗證值時請保留大小寫與連接符號,並檢查前後空格;不要縮短值來試錯。
| Type | 重點核對 | 不可混淆的內容 |
|---|---|---|
| Shadowsocks | Address、Port、Method、Password | Method 必須符合伺服器要求 |
| VMess / VLESS | UUID、TLS、傳輸方式及相關欄位 | UUID 不能取代傳輸與 TLS 參數 |
| Trojan | Password、TLS、伺服器名稱 | 連線位址與憑證名稱可能不同 |
| HTTP / SOCKS5 | 位址、連接埠、所需驗證資訊 | 是否需要驗證,依已有資料而定 |
| WireGuard | 金鑰、位址、Endpoint、Allowed IPs | 本機金鑰與對端公開金鑰用途不同 |
分別檢查 TLS 與傳輸方式
TLS 負責相關連線層的加密與身分驗證,傳輸方式則說明資料如何承載,兩者不能互相取代。已有資料要求使用 TLS 時,應核對伺服器名稱等相關欄位,而不是只開啟開關。使用 WebSocket 等傳輸方式時,也需核對 Path 與 Host;Path 開頭的斜線及 Host 的拼法都可能影響請求。某些參數只有選定相應類型後才會顯示,未顯示的欄位不應隨意填入備註、位址或密碼欄。
Address、TLS 的伺服器名稱,以及傳輸層 Host,可能分別負責網路連線、憑證驗證與請求路由,不一定使用相同文字。匯入後發現這些欄位不同,不要立即將它們統一成同一個網域。只有在現有資料明確要求時才修改,並且一次只改一個欄位。遇到憑證錯誤,優先核對名稱、裝置時間與參數是否完整,不要將放寬驗證當成一般修復方式;否則可能掩蓋填寫錯誤,也會降低身分驗證的作用。
儲存後的驗證順序
建議先以清楚的備註儲存一筆測試記錄,選取後再連線。儲存只代表表單已被接受,不能證明位址可連線、驗證通過或傳輸方式相符。先查看 Connectivity Test,再發出實際請求,並觀察是否只有部分目標失敗。如果基本連線正常,但特定網站失敗,應改查規則、DNS 或目標存取條件,不要反覆更換驗證值。若同類型的其他項目運作正常,可逐項比較欄位,但不要在公開回報中展示完整密碼或 UUID。
VMess 與 VLESS 的欄位差異,請參閱UUID、加密與傳輸方式說明;WireGuard 參數較多,另請參閱Private Key、Endpoint 與 MTU 說明。本機手動輸入的項目通常應視為獨立項目管理,不要預期它會隨某份訂閱同步變更。需要長期保留的手動記錄,應在驗證通過後儘快備份,並註明哪些欄位來自原始資料,哪些是之後在本機調整的。
03 / Scan QR Code
掃描 QR Code 與剪貼簿:先辨識內容再匯入
QR Code 和剪貼簿只是傳遞文字的方式,並非獨立的伺服器協定。同一個 QR Code 可能包含單一伺服器分享連結、訂閱 URL,甚至只是一般網頁網址。使用 Scan QR Code 或從剪貼簿匯入前,應先確認要匯入的項目類型,再依結果核對。操作省去了手動輸入,不代表可以省略內容辨識、權限確認與連線測試;只有來源明確且內容完整時,才適合直接交由客戶端解析。
Scan QR Code 操作檢查
從應用程式內的 Scan QR Code 入口啟用相機,依系統提示允許相機權限,並將完整 QR Code 放入取景範圍。保持邊緣完整、對焦清晰並避免反光;若辨識失敗,先調整距離,不要立刻認定 QR Code 已失效。若先前拒絕相機權限,請前往裝置的系統設定,檢查 Shadowrocket 的相機存取狀態,再返回重試。透過系統相機辨識出的普通文字或網頁提示,不代表已在 Shadowrocket 中建立伺服器記錄。
QR Code 顯示在另一部裝置上時,可以直接掃描;若儲存在目前使用的裝置,只有在目前入口明確支援圖片辨識時,才從圖片匯入。不要將其他系統功能的行為視為應用程式的承諾。QR Code 密度過高、經過壓縮或邊緣遭裁切時,可能無法辨識;建議改用原始清晰圖片,或直接複製原始文字。請勿將含個人憑據的 QR Code 上傳至公開辨識網站,也不要為了提高辨識率而反覆轉傳給無關人士。
剪貼簿匯入的內容範圍
複製時請盡量只選取連結本身,不要包含「伺服器位址:」之類的標籤、程式碼區塊或說明段落。返回應用程式使用相應的匯入入口;若系統詢問是否允許貼上,請確認這是你主動進行的操作,再選擇允許。若沒有出現項目,先回到原始文字檢查是否複製完整;剪貼簿內容可能已被後續複製取代,系統未授予權限也可能導致讀取失敗。不要只憑複製成功的提示,就認定匯入已完成。
多行文字應先確認每一行都是完整項目,而且目前的匯入方式支援批次處理。如果只是畫面顯示時自動換行,通常不需要自行插入換行;實際插入的空格或斷行則可能破壞 URI。若一批內容只有部分項目匯入成功,先保留失敗項目的原文,在本機逐一核對結構,不要為了找出遺漏項目而重複匯入整批內容。這樣可避免成功項目越積越多,最後難以分辨哪些是新匯入、哪些是舊記錄。
匯入後核對項目與欄位
匯入完成後,先確認結果出現在哪裡:若新增的是 Subscribe,應可管理訂閱網址及後續更新;若新增的是單一 SERVER,則應可開啟其協定參數。接著核對 Type、Address、Port、備註,以及 TLS 和傳輸相關內容。備註可能由連結片段產生,只供識別,不能代表項目已通過測試。同名記錄應檢查欄位差異,不要只憑清單標題就覆寫舊項目;最好等新記錄驗證通過後,再處理原有可用記錄。
發生辨識失敗時,將問題分成三個層次:相機或貼上權限是否可用、原始文字是否完整,以及文字格式是否受目前入口支援。若能取得文字卻無法解析,請繼續閱讀下一章的分享連結結構;若可以解析但無法連線,請回到 Add Server 檢查欄位。回報時只需記錄操作入口、是否出現系統授權提示、匯入結果與錯誤文字。QR Code 原圖與完整 URI 都應視為敏感資料,請勿在回報時一併公開。
05 / Update
更新方式:控制變更並保留可用狀態
更新訂閱會再次請求原本的遠端網址,並依回傳內容調整本機訂閱項目。更新可能新增伺服器、移除舊項目,或變更同名項目的連線參數;不只是重新整理名稱。更新前應確認目前使用哪份訂閱、哪個伺服器,以及是否曾在訂閱項目上進行本機修改。需要保留的個別調整,應先透過應用程式提供的匯出或備份功能留存,不要預設遠端更新一定會保留本機編輯。
以手動更新作為排查基準
首次使用、網址變更後,或懷疑內容過期時,先手動更新一次並觀察結果。記錄操作前是否已連線、使用的網路及目前項目狀態;完成後檢查是否出現明確錯誤、伺服器是否變動,以及原先選取的項目是否仍存在。不要同時修改網址、切換網路並反覆更新,否則即使恢復正常,也無法判斷原因。一次操作對應一次觀察,才能區分取得成功、解析成功與連線成功三個階段。
自動更新適合已確認能穩定取得資料的訂閱。若目前介面提供更新開關或週期選項,請依實際使用頻率選擇,不要預設更新越頻繁越好。更新行為可能受裝置網路、系統背景排程及應用程式狀態影響,不應承諾精確到某個時間。長時間未開啟應用程式後,若懷疑本機內容已過期,可以主動檢查並手動更新一次,再進行連線驗證;不要只因自動更新選項已開啟,就認為目前清單一定是最新結果。
區分網址錯誤與取得路徑問題
更新失敗時,先確認 URL 是否仍是自己持有且有效的網址,尤其是憑據重設後是否還在使用舊網址。接著檢查目前網路能否取得訂閱回應。若只有開啟連線時失敗,或只有關閉連線時失敗,請分別記錄兩種條件,並檢查是否依賴特定的取得路徑;不要一概認定更新必須始終透過某種方式進行。設定規則與目前伺服器狀態都可能影響請求路徑,排查應依據實際結果,而不是套用固定的開關組合。
錯誤回應也應分層理解:連線逾時表示未能在目前條件下完成請求;驗證失敗通常需要核對存取憑據;解析失敗則表示取得的內容不符合預期格式。單次失敗不代表已儲存的伺服器全數失效,也不應立即刪除整份訂閱。若舊項目仍可正常連線,可以先保留,將更新問題分開處理。若錯誤頁面含有個人資料,只需記錄錯誤類型,不要直接公開完整回應。
更新後重新確認選取項目與規則
更新完成後,原先選取的伺服器可能已更名、遭替換或移除。請返回 Home 確認預設選取項目,重新測試常用項目,再觀察實際請求。名稱相同不代表參數相同,延遲正常也不代表所有目標都能存取。若本機設定引用了特定名稱,也應檢查名稱變更是否影響引用。重要用途不宜在即將開始使用前才批次調整;請預留驗證時間,再清理舊記錄。
更新訂閱與更新應用程式也應分開看待:前者會重新取得既有訂閱回傳的伺服器資料,後者則由 App Store 管理應用程式本身。購買、恢復與相容性說明請參閱正版核驗頁;系統需求以 App Store 頁面標示為準。不要將所有連線問題都歸因於應用程式需要更新,也不要把一次訂閱更新當成應用程式行為改變的證據;先確認變更對象,再比較更新前後的具體欄位與請求狀況。
06 / Organize
多份訂閱整理:命名、去重與使用範圍
多份訂閱並存時,管理重點不是盡量縮短清單,而是讓每筆記錄的來源、用途與維護方式都清楚可辨。先分開訂閱產生的項目與本機手動輸入的項目,再為訂閱設定穩定的備註。建議依用途命名,例如「日常」、「臨時測試」或「個人裝置」;不要將密碼、完整網域清單或訂閱憑據放進標題。備註可協助選取,但不能取代欄位記錄;發生名稱重複或更新時,仍應能找到確切的訂閱。
建立兩層命名習慣
第一層是訂閱備註,用來回答「這批伺服器由哪個已儲存的入口維護」;第二層是伺服器備註,用來回答「目前選取的是哪筆記錄」。遠端清單本身可能有命名規則,大量修改本機名稱前,應先考慮下次更新是否會重新產生名稱。若要保留自己的說明,優先在私密記錄中維護用途對照,或使用目前介面明確提供的備註功能;不要依靠在遠端欄位加入額外文字,長期保存管理資訊。
臨時測試的獨立項目可以明確加上「測試」及用途說明,驗證後再決定是否保留。不要將所有項目都命名為「常用」,也不要只用連續數字編號;更新插入新項目後,編號很難反映實際關係。整理時先維持目前可用的伺服器不變,逐份檢查訂閱,不要在同一次操作中重新命名所有項目、刪除重複項並切換預設選取。分批處理能讓錯誤回復到明確的步驟。
判斷重複項目不能只看名稱
兩筆同名項目可能使用不同的連接埠、驗證資訊或傳輸參數;名稱不同的項目也可能指向完全相同的連線設定。判斷是否重複時,應在本機比較 Type、Address、Port、驗證、TLS 與傳輸欄位。比較時不要將敏感值複製到公開試算表。若欄位相同但來源是兩份不同訂閱,它們的更新歸屬也不同;刪除其中一筆不代表下次更新不會再次出現。請先確認要保留哪份訂閱的維護關係。
若重複項目出現在訂閱內,先確認它是否來自回傳內容;若每次更新都再次出現,單純在本機刪除只能暫時改變清單。若是重複匯入同一份訂閱,請核對完整網址與管理用途,再決定保留哪一份;不要只因備註相同就刪除。清理前,確認預設伺服器不屬於即將移除的項目,並準備一個已測試的替代選項。若目前介面沒有明確的批次清理功能,逐項處理會比嘗試含義不明的批次操作更可控。
分開看待顯示順序與實際路由
排序能提高查找效率,但不代表排在第一位的伺服器會自動成為預設,也不保證應用程式在故障時會自動切換。調整顯示順序後,仍需透過 Home 的選取狀態確認實際使用的項目。若使用設定中的策略群組,也要了解該群組本身的選取規則,不能將伺服器清單順序視為策略群組的運作方式。建議將穩定的常用項目放在容易找到的位置,並清楚標示臨時測試項目,避免連線前匆忙選到尚未驗證的記錄。
可以建立一份不含憑據的私密管理清單,只記錄訂閱備註、用途、是否有本機修改,以及最近一次操作結果。這裡的「結果」應記錄親自觀察到的事實,例如「已驗證實際請求」或「待核對傳輸欄位」,不要只憑名稱推測是否可用。更完整的操作步驟請參閱多份訂閱的分組、排序與重複項目整理。整理完成後,回到常用情境測試一次,確認管理清單更清楚的同時,連線狀態也仍然容易判讀。
07 / Connectivity Test
延遲測試與排序:了解結果的適用範圍
延遲測試用來觀察目前網路與測試方式下,某次特定連線操作是否完成及所需時間。它不等於持續傳輸速度,也不能直接證明某個網站或應用程式可用。判讀結果前,先確認測試方式、目標與目前網路條件;不同方式測得的數值不應直接比較排名。測試逾時也只是一次觀察,不能單獨證明伺服器永久失效;應搭配重複測試、實際請求及其他項目交叉比對。
固定條件後再比較
比較多個伺服器時,盡量使用相同網路、相同測試方式,並在相近時間進行,避免一個在行動網路測試,另一個在 Wi-Fi 測試。測試期間減少大型檔案傳輸等明顯的競爭流量,先測目前常用項目,再測備用項目。若介面提供多種測試方式,應了解它們涵蓋的連線階段可能不同:基本連線成功,不代表驗證、TLS、傳輸層與目標請求都已完成。越接近實際請求的測試方式,通常涵蓋的環節越多,但也越容易受到測試目標影響。
| 觀察結果 | 可說明 | 下一步 |
|---|---|---|
| 測試取得耗時結果 | 本次測試已依選定方式完成 | 繼續驗證實際目標請求 |
| 單一項目逾時 | 該項目在目前條件下未能完成測試 | 重新測試並核對位址、連接埠與參數 |
| 全部失敗 | 可能是共通的網路或目標問題 | 檢查裝置網路與測試條件 |
| 測試正常,但部分請求失敗 | 基本測試結果與實際存取結果不一致 | 檢查規則、DNS 與目標條件 |
Connectivity Test 與實際存取結果可互相參照
選取伺服器並開啟連線後,使用 Connectivity Test 觀察連線狀況,再開啟實際需要使用的頁面或應用程式。若測試成功但目標存取失敗,應檢查 Global Routing 是否符合預期、目標是否符合相應規則,以及 DNS 解析是否正常。不要在沒有證據時將問題全歸咎於伺服器。反過來說,若目標可以存取但某項測試失敗,也應考慮測試目標本身的回應條件,避免只因一次測試就刪除正常運作的記錄。
Global Routing 設為 Config 時,會依目前設定處理請求;Proxy 使用代理處理方式,Direct 則使用直接連線方式。進行對照測試時,先記下原本狀態,一次只變更一個條件,測試後再恢復所需設定。模式變更會影響結果的意義:Direct 模式下能開啟頁面,不能證明目前選取的伺服器可用;Config 模式下存取正常,也可能是該請求符合 DIRECT。因此,驗證伺服器時,請確認測試請求確實經過預期路徑。
依結果排序後再次確認
依延遲排序只會依當次測試結果重新排列項目;數值較小的項目不一定長時間使用時更穩定,也不一定有較高的傳輸能力。不要因為一次測得最低值就頻繁切換。可優先選用多次測試結果一致、實際使用正常的項目,再保留一個已驗證的備用項目。排序後重新確認預設選取狀態,尤其是在清單很長或有同名項目時,不要將視覺上排第一的項目誤認為應用程式已選取並正在使用的項目。
若同一個伺服器在不同網路下表現差異明顯,應將網路條件納入記錄,不要繼續修改密碼。若更新後突然只有部分項目失敗,請回頭檢查欄位是否變動;若所有項目同時異常,先檢查共通條件。故障記錄可包含測試方式、網路類型、Global Routing、錯誤原文及實際目標的狀況,但不要包含完整訂閱 URL。首次連線的檢查順序另請參閱預設伺服器、連線開關與 Connectivity Test 檢查表,避免遺漏基本步驟。
08 / Backup & Remove
刪除與備份:確認範圍後再操作
刪除前先確認對象:單一伺服器、整份 Subscribe、Config 中的設定檔,以及應用程式本身,屬於不同層級的操作,所需的復原資料也不同。刪除伺服器不代表撤銷訂閱存取憑據;刪除訂閱也不代表遠端資源已取消。備份的目的,是在妥善保護驗證資訊的前提下,復原所需的本機狀態,而不是將所有內容隨意複製到容易公開存取的位置。
依復原目標建立備份
若只需要復原訂閱產生的清單,保存有效的訂閱網址與必要說明,通常比逐筆抄寫更直接,但也應考慮網址日後可能變更。若要復原手動輸入的伺服器,則需要保留完整協定參數,或使用應用程式提供的伺服器分享或匯出功能。若也要復原流量分流方式,則必須另外保存相應的 Config;只有伺服器連結無法自動還原規則。使用目前介面提供的備份功能時,請閱讀範圍說明,不要預設單一入口一定涵蓋所有設定。
備份內容可能包含訂閱憑據、密碼、UUID 或金鑰,應採取與原始資料相同的保護措施。建議儲存在自己掌控且有存取保護的位置,並清楚區分「僅含備註的清單」與「包含完整憑據的備份」。不要以公開分享連結取代長期備份,也不要在問題回報中附上完整伺服器資料。用來說明結構的副本應換成範例值;供實際復原使用的副本則必須保持完整,不可混用。
刪除單一項目與整份訂閱的差異
刪除單一由訂閱產生的項目前,應先考慮下次更新是否會重新產生;若要徹底移除這批本機伺服器,則需查看整份訂閱的刪除範圍。刪除整份訂閱時,請仔細閱讀確認提示,判斷是否會一併移除相關項目。不同對象的操作不能互相取代:只刪除一筆顯示項目,無法確保訂閱停止更新;只清除本機資料,也不能讓已外洩的遠端存取憑據失效。
刪除目前選取的伺服器前,先切換到另一筆已驗證的記錄,確認所需連線仍可正常運作,再處理舊項目。若清單中只有這一筆,請先準備好復原資料,不要抱著「刪除後再想辦法」的心態操作。批次清理時,先小範圍測試並核對結果,再繼續操作,避免一併移除同名但參數不同的項目。Config 也應個別備份;伺服器仍在,不代表原有規則與策略設定得以保留。
復原順序與備份驗證
復原前先確認應用程式已從 App Store 取得;找回已購項目的方法請參閱換機與重新安裝的復原說明。恢復購買記錄只能恢復取得應用程式的資格,不代表伺服器與設定會自動復原。接著復原訂閱或手動輸入的項目,檢查欄位與預設選取項目,再復原需要的 Config,最後核對 Global Routing。依照這個順序操作,有助於連線異常時找出問題所在層級,避免一次匯入所有備份後無法辨識衝突。
備份完成後,應確認內容確實可讀取:檢查匯出內容是否為空、訂閱網址是否完整、獨立項目是否包含必要欄位,以及 Config 是否為預計保留的版本。驗證不必先刪除原始資料,可透過查看範圍、核對項目或在受控情況下匯入來完成。若受控匯入產生重複記錄,請先確認復原資料有效,再清除測試副本。定期確認儲存位置仍可存取,比只記得「以前備份過」更可靠。
若發現憑據曾經公開,只刪除截圖、連結或本機記錄,仍不足以排除存取風險。請依自己使用的服務管理方式更換或撤銷相關憑據,再更新應用程式中的網址與備份。日常維護可依固定順序進行:修改前保存基準狀態,修改後驗證連線,驗證完成後整理重複項目,最後更新備份。若只需重新走過連線流程,請返回入門指南;若有常見操作疑問,可參閱連線開關、Global Routing、訂閱更新與已購項目恢復問答,不必為了局部問題重建所有資料。