Shadowrocket 完整使用手冊:從 App Store 取得至日常維護

Shadowrocket 是 App Store 上的付費應用程式,沒有第二種取得途徑。這一章說明三件事:怎麼在商店裡確認自己點開的是正版、一次性買斷到底買到了什麼,以及在哪些裝置上能安裝。

Shadowrocket(中文圈常稱小火箭)在 App Store 搜尋時,結果中會出現若干名稱相近的應用程式。判斷方法不是看名稱,而是看商店頁上的三處資訊:開發者欄位寫的是 Shadow Launch Technology Limited;應用程式圖示是白底、藍紫漸層描邊的火箭圖形;商店頁網址帶有應用程式 ID 932747118。三處都相符,才是需要購買的那個應用程式。

應用程式 ID 為什麼值得單獨記

應用程式 ID 是 App Store 裡每個應用程式唯一的編號。本站所有指向商店的連結都寫成 https://apps.apple.com/tw/app/shadowrocket/id932747118 這一個,你在網址列看到的 id932747118 與商店頁資訊裡的應用程式 ID 是同一件事。如果某個頁面給出的連結是別的編號,它指向的就不是 Shadowrocket。

一次性買斷,買的是什麼

Shadowrocket 採用一次性買斷的付費方式。美國區定價約 2.99 美元,其他店面依當地貨幣顯示,實際金額以你打開商店頁時看到的標示為準。買斷的是用戶端本身,也就是執行在 iPhone、iPad 上的這個應用程式;購買之後沒有按月訂閱費,也不需要為了解鎖功能再次付費。

裝置範圍與系統需求

Shadowrocket 以 iPhone 與 iPad 為主,同時也出現在同一個 App Store 商店頁的相容性欄位中,涵蓋 Mac、Apple TV 與 Apple Vision。某台裝置能不能安裝,取決於它登入的 Apple ID 是否已經購買過這個應用程式,以及商店頁目前標示的相容性。系統版本需求一律以 App Store 頁面標示為準——應用程式會隨系統迭代調整最低版本,寫死在教學裡的數字很快就會過期。

買完之後:已購項目與更新

購買完成後,應用程式會進入該 Apple ID 的已購項目。換機或重新安裝時,用同一個 Apple ID 在 App Store 的已購項目中重新下載即可,不需要再次付費。家人共享是否適用於這個應用程式,同樣以商店頁標示為準。

更新由 App Store 統一派送,應用程式內沒有獨立的更新通道,也不需要手動替換任何檔案。保持 App Store 的自動更新開啟,或偶爾到帳號頁手動點一次更新就夠了。本站不會、也不能提供任何安裝檔——任何聲稱提供安裝檔的來源,都與正版無關。

購買前先準備好兩樣東西

在按下購買按鈕之前,建議先備好兩樣東西:一是你的伺服器資訊或訂閱連結(向你的服務商取得),二是確認裝置上登入的 Apple ID 是你常用的那一個。前者決定買完之後能不能立刻用起來,後者決定日後換機時能不能順利找回。如果只是想先熟悉介面,應用程式在沒有任何伺服器的情況下也能開啟,只是連線開關無法建立通道。

第一次打開 Shadowrocket,系統會連續彈出幾個授權視窗。它們各自管什麼、該不該允許、誤按了怎麼補救,是這一章的內容;順帶把主介面的幾個標籤頁認一遍。

首次啟動時,最先出現的通常是 VPN 設定授權彈窗。iOS 會明確寫出請求方名稱,並詢問是否允許加入 VPN 設定。選擇允許之後,系統會為 Shadowrocket 建立一筆本機通道設定,後續的連線開關都基於這筆設定運作。

為什麼需要 VPN 設定權限

在 iPhone 與 iPad 上,應用程式要讓流量經過自己的處理邏輯,必須借助系統提供的網路擴充功能框架。Shadowrocket 把伺服器參數與規則轉換成一筆系統層級的 VPN 設定,流量從系統進入這條通道,由應用程式依規則決定走代理還是直連,再交還給系統送出。這也是為什麼在系統的「設定」裡能看到一筆對應的 VPN 設定項目——它是系統層級真實存在的項目,而不是應用程式內部的模擬開關。

三個彈窗分別對應什麼

• VPN 設定授權(Add VPN Configurations):功能必需。拒絕之後,連線開關無法生效。
• 通知權限:用於顯示連線狀態變化一類的提示。允許與否不影響代理功能。
• 本機網路(Local Network):只在需要讓同一區域網路內的其他裝置存取本機代理埠時才會用到,不需要這項用法可以拒絕。

三個彈窗裡只有第一個是必需的。誤按了「不允許」也不必解除安裝重裝:再次撥動連線開關時,系統會重新詢問;如果始終沒有彈窗,到系統「設定」的 VPN 欄位檢查是否已經存在相關設定項目。

主介面的幾個標籤頁

Shadowrocket 的主介面由底部標籤頁組成,後續所有操作都從這裡進入:

• Home:伺服器列表與連線開關。頂端顯示目前的 Global Routing 模式,中間是節點列表,底部是主開關。
• Config:設定檔與規則。匯入的 .conf 檔案、規則列表都在這裡檢視與編輯。
• Data:流量統計。分為依伺服器與依應用程式兩組讀數,第 7 章說明。
• Settings:全域設定。On Demand、DNS、訂閱自動更新等選項都在這裡,第 8 章說明。

介面用詞保持英文原文:Home、Config、Data、Settings、Add Server、Subscribe、Global Routing、On Demand。繁體中文說明裡出現這些詞時,指的就是介面上那個具體的按鈕或標籤;保留原文是為了讓你一一對上,而不是換成含義相近的中文詞。

建議的初始化順序

第一次設定時,依下面的順序走一遍,比隨手點開關更容易定位問題:

1. 先在 Settings 裡確認 Global Routing 的模式,預設停在 Config 即可。
2. 回到 Home,用 Add Server 或 Subscribe 把伺服器資訊填進去。
3. 對節點做一次延遲測試,確認參數填對了。
4. 最後再打開主開關,並用 Connectivity Test 驗證一次。

順序背後的邏輯是:開關只負責「建立通道」,通道裡能不能通,取決於伺服器參數與規則是否已經就位。先填資訊再開開關,失敗時就能把問題縮小到參數或網路,而不是同時懷疑權限、參數與規則三件事。另外,首次開啟不需要設定語言或外觀——介面跟隨系統語言與深色模式,沒有獨立的主題選項。

把伺服器資訊放進 Shadowrocket 有兩條路徑:Add Server 手動填單筆,Subscribe 匯入一整份訂閱。兩條路徑可以並存,這一章分別說明欄位含義、更新方式與容易填錯的地方。

Add Server:手動新增單筆伺服器

在 Home 頁點擊 Add Server 進入參數表單。第一項是 Type,它決定後面要填哪些欄位:

表格只是常見組合的示意。欄位會隨 Type 與所選傳輸方式變化,服務商給你什麼就填什麼;多填、少填,或照著別的介面上的名稱猜著填,都是連線失敗最常見的來源。儲存之後,節點會出現在 Home 的列表裡。

Type 之外還有幾處容易忽略:備註(Remark)只影響顯示名稱,填成方便辨識的即可;TLS 開關與 SNI、Path、Host 等欄位只在服務商明確給出時才需要填;如果服務商提供的是分享連結或 QR Code,直接用 Scan QR Code 掃碼匯入,比手抄一遍更不容易出錯。

Subscribe:匯入訂閱

訂閱是服務商把一批伺服器打包成一個連結,由用戶端定期拉取。入口在 Home 頁的 Subscribe:把訂閱連結貼進去、寫一個備註,儲存後點 Update 完成第一次拉取。拉取成功後,節點會以群組的形式出現在列表裡。

訂閱連結向你的服務商取得,形如 https://example.com/sub?token=xxxx 這樣的網址。它通常帶有身分識別,等同於帳號憑證,不要貼到公開場合,也不要轉傳給不相關的人。本站不提供任何訂閱連結,文中出現的網址都是示範用的假值。

訂閱與手動新增的差別在更新方式:訂閱可以整體重新整理,服務商調整節點後你只需再點一次 Update;手動新增的單筆節點不會自動變化,服務商換了位址就得自己改。兩種方式可以同時存在,常見做法是把常用節點手動置頂,把訂閱群組留在下面。

訂閱的更新時機

更新訂閱有兩個時機:手動更新,以及在 Settings 裡開啟的自動更新。手動更新的入口在訂閱群組上,點開群組詳情即可看到 Update;自動更新適合訂閱內容經常變動的使用者,代價是每次啟動應用程式會多一次網路請求。

更新失敗時,先分清是「拉不到」還是「拉到了但用不了」:前者通常是連結失效、token 變更,或目前網路連不到訂閱網域;後者代表訂閱內容本身有變化,需要看服務商的通知。完整的排查順序在第 9 章。

從檔案匯入設定

除了逐筆填寫,Shadowrocket 也支援匯入設定檔:拿到 .conf 檔案後,透過系統分享選單選擇 Shadowrocket,即可匯入到 Config 頁。設定檔裡可以同時包含伺服器列表、規則與一般參數,適合已經有一份完整設定的使用者。匯入後請留意 Config 頁頂端的選取狀態——同時存在多份設定時,只有被選中的那一份生效。

另有一個 Import from Cloud JSON 入口,用於從雲端 JSON 還原設定。它讀取的是你自己儲存的設定內容,與節點訂閱是兩件不同的事。

延遲測試與節點選擇

節點列表裡每個項目會顯示延遲讀數,點一下即可重新測試。這個數字是一次探測往返的耗時,只能用來橫向比較同一時刻的節點,不能代表實際速度——它不測頻寬,也不測長時間穩定性。Connectivity Test 會做更完整的一輪檢查,結果會區分解析、連線等環節。

列表支援排序與置頂。日常使用建議把兩三個穩定節點放在最上面,避免每次都在長列表裡翻找。

Global Routing 決定通道裡的流量「預設往哪走」,是 Shadowrocket 裡最容易設錯、也最值得先弄懂的一項。它只有三種模式:Config、Proxy、Direct。

三者的關係可以這樣理解:主開關決定「通道開不開」,Global Routing 決定「通道裡怎麼走」。切到 Direct 不會斷網,只是不再有流量經過代理伺服器;切到 Proxy 也不會影響系統本身,Bypass 名單裡的區域網路位址仍然直連。

Config 模式:規則說了算

Config 是日常使用唯一需要長期保持的模式。在這個模式下,Shadowrocket 由上而下讀取 Config 頁裡的規則,第一條命中的規則決定這條連線走 PROXY、DIRECT 還是 REJECT,後續規則不再參與。規則的寫法與順序在第 5 章說明。

切到 Config 模式之前,先確認 Config 頁裡有一份被選取的設定。沒有設定檔、或設定檔裡沒有規則時,Config 模式下的行為會完全交給備援規則,結果往往與預期不符——這也是「明明開了代理,某個網站卻打不開」的常見原因之一。

Proxy 與 Direct:兩個臨時模式

Proxy 模式適合「今天就是要全部走代理」的情境:所有未被 Bypass 的流量都從目前選取的伺服器出去,規則不參與判斷。它的副作用也很直接——原本該直連的區域網路存取、原本該省流量的近端請求,都會繞一圈,速度與流量開銷都會改變。

Direct 模式可以理解為一個「帶設定的關閉狀態」:通道仍然建立,但沒有任何流量進入代理。它適合需要臨時停用代理、又不希望丟掉目前節點選擇的場合。用完記得切回 Config,否則下一次連線會繼續沿用 Direct。

與 On Demand 的分工

On Demand(按需連線)管的是「什麼時候自動開、什麼時候自動關」,Global Routing 管的是「開了以後怎麼走」。兩者是正交的:你可以讓 On Demand 在行動網路下自動連線,同時讓 Global Routing 停在 Config 模式依規則分流。把這兩項混在一起調,是設定越調越亂的常見起點。

怎麼確認目前模式

Home 頁頂端會顯示目前的 Global Routing 模式。打開主開關後,狀態列出現 VPN 圖示只代表通道建立了,不代表流量一定走了代理——是否真的走了代理,要在 Data 頁的讀數裡看(第 7 章)。

一個實用的自我檢查習慣:每次調整 Global Routing 或規則之後,打開一個明確寫在規則裡的網域,回到 Data 頁看它的流量落在哪一組讀數上,再決定要不要繼續改。

三個常見的誤設

• 把 Direct 當成「關閉應用程式」長期掛著,結果訂閱更新與節點測速都出現異常。
• 把 Proxy 當成「更徹底的分流」,實際上它繞過了全部規則。
• 在 Config 模式下沒有備援規則,未命中任何規則的流量走向變得難以預測。

規則寫在 Config 頁的設定檔裡,格式統一為「類型,參數,策略」三段。這一章說明每種類型比對什麼、順序為什麼重要,並給出可以直接照抄的最小片段。

一條規則由什麼組成

規則的基本結構是 類型,參數,策略。類型決定拿什麼去比對,參數是比對的依據,策略決定命中之後怎麼走。策略有三種:PROXY 走代理,DIRECT 直接連線,REJECT 攔截。舉例來說,DOMAIN-SUFFIX,example.com,PROXY 的意思是:凡是 example.com 及其子網域的請求,都走代理。

常用規則類型對照

DOMAIN 與 DOMAIN-SUFFIX 的差別值得單獨記:前者只比對寫出來的那一個網域,後者連同它的所有子網域一起比對。example.com 與 www.example.com 在 DOMAIN-SUFFIX 下由一條規則涵蓋,在 DOMAIN 下則需要寫兩行。

順序:由上而下,先命中先生效

規則列表是有序的。Shadowrocket 從第一行開始逐條比對,第一條命中的規則決定這條連線的走向,之後的規則不再參與。由此得出兩條實務原則:一是把具體的規則放在寬泛的規則前面,例如 DOMAIN 放在 DOMAIN-KEYWORD 之前;二是備援規則 FINAL 必須放在最後一行,否則它會把後面所有規則都擋掉。

GEOIP 規則需要先取得目標 IP 才能判斷歸屬,所以它通常排在網域類規則之後——網域能判斷的先判斷,判斷不了的再交給 IP 層。這是規則順序裡最常被問到的一點。

一份可以直接照抄的最小片段

[Rule]
DOMAIN,api.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN-KEYWORD,example,DIRECT
IP-CIDR,203.0.113.0/24,DIRECT
IP-CIDR6,2001:db8::/32,DIRECT
USER-AGENT,Example*,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXY

這段設定表達的策略是:example.com 及其子網域走代理,其中 api.example.com 與帶 example 關鍵字的請求例外直連;兩個示範網段直連;中國大陸 IP 直連;其餘全部走代理。把網域與網段換成你自己的目標即可,格式不用改。

如果只想代理少數目標、其餘全部直連,把最後一行改成 FINAL,DIRECT,並在前面列出需要代理的網域:

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN-KEYWORD,example,DIRECT
GEOIP,CN,DIRECT
FINAL,DIRECT

兩種思路沒有優劣,取決於使用習慣:前者是「預設走代理、例外直連」,後者是「預設直連、例外走代理」。選定一種之後,規則列表會清晰很多。

REJECT 與攔截的邊界

REJECT 策略會讓命中的連線被攔下,常用於封鎖特定網域。需要明確它的邊界:它只對能比對到的網域或 IP 生效;HTTPS 連線被攔下之後,表現為連線失敗或載入逾時,而不是「內容被過濾」;應用程式自行發起的請求、使用了網域前置或自建解析的請求,可能完全繞過規則。因此不要把 REJECT 當成通用的封鎖方案,它只是一個規則層面的開關。更細的說明在本站部落格《Shadowrocket REJECT 策略:封鎖原理與攔截邊界》裡。

修改規則之後

規則改動儲存後,需要讓設定重新載入:切一次 Global Routing,或中斷再打開主開關即可。改動量大時,建議先在小範圍內驗證一條新規則,確認命中之後再批次新增——一次寫幾十行再回頭排查,成本會高很多。

資訊填完、規則就位之後,連線與驗證是最後一步。這一章說明開關與狀態怎麼看、Connectivity Test 檢查什麼,以及連不上時依什麼順序排查。

打開連線與狀態指示

Home 頁底部的開關就是主開關。打開之後,系統狀態列會出現 VPN 標示,應用程式內的開關會變為開啟狀態。這兩個指示只代表通道建立了,不代表流量是否走了代理——後者要看 Data 頁的讀數與目前模式。

節點選擇在列表裡完成:點選節點列或它前面的圓點,目前節點會有明顯標記。切換節點不需要重新開關,通道會依新節點重建。

Connectivity Test 檢查什麼

Connectivity Test 會依序檢查幾件事:網域解析是否正常、能否連線到所選伺服器,以及經由伺服器存取外部位址是否成功。結果裡會分別列出各環節的狀態,失敗時會停在第一個出問題的環節。

看結果的方法是從上往下讀:解析失敗代表 DNS 環節有問題;連線失敗代表伺服器位址、埠或協定參數對不上;解析與連線都成功但外部存取失敗,則更可能是伺服器端的狀態問題,以服務商提供的資訊為準。

怎麼驗證分流真的生效

驗證分流不需要額外工具,用 Data 頁就能完成:

1. 打開一個明確寫了 PROXY 的網域,回到 Data 頁,看流量是否落在目前伺服器的讀數上。
2. 打開一個明確寫了 DIRECT 的網域,確認它沒有增加伺服器的讀數。
3. 如果第 2 步的讀數也在增加,回到 Config 頁檢查規則順序,確認沒有更前面的規則搶先命中。

這個三步自我檢查能涵蓋絕大多數「規則看起來寫了卻不生效」的情況。

連線失敗時的排查順序

連不上時,依下面的順序逐項排除,比反覆重新安裝應用程式有效得多:

1. 權限:確認 VPN 設定授權沒有被拒絕,系統「設定」的 VPN 欄位裡存在對應設定。
2. 參數:逐字核對 Address、Port、Password 或 UUID 與服務商給的資訊是否一致,注意大小寫與多餘空格。
3. 協定細節:檢查 Type 是否選對,TLS、SNI、Path、Host 等欄位是否依服務商說明填寫。
4. 時間:裝置時間明顯偏差會影響 TLS 握手,把時間設定改為自動。
5. 模式:確認 Global Routing 沒有停在 Direct。
6. 訂閱狀態:如果節點來自訂閱,先更新一次訂閱再判斷。
7. 網路環境:換一個網路(例如從 Wi-Fi 切到行動網路)再試,排除目前網路對 VPN 的限制。

七步裡前四步涵蓋了大部分失敗案例。如果全部走完仍不通,把 Connectivity Test 的結果與服務商核對,問題多半在伺服器端或帳號狀態,已經超出用戶端能處理的範圍。

間歇性斷流

能連上但時不時斷流,通常與網路切換、節點負載或規則衝突有關。可以先觀察斷流出現的時機:切換 Wi-Fi 與行動網路時斷,多半是網路切換導致通道重建;固定時段斷,可能是節點端的問題;只在存取特定應用程式時斷,則回到規則裡找那條應用程式的網域是否被 REJECT,或被錯誤地指向了直連。

Data 頁把經過通道的流量依兩個維度統計:依伺服器、依應用程式。這一章說明兩組讀數各自統計什麼、為什麼與系統統計對不上,以及用它定位異常流量的順序。

兩組讀數分別是什麼

依伺服器一組,統計每個節點承載的上行與下行流量,用途是判斷「流量從哪條線路出去」,在多個節點之間取捨時最直觀。依應用程式一組,統計每個應用程式產生的流量,用途是判斷「是誰在用流量」。

兩組讀數的單位是 B、KB、MB、GB,依 1024 進位換算,介面上通常把上行與下行分列顯示。需要留意的是,這裡統計的是經過 Shadowrocket 通道的流量,而不是裝置網卡上的全部收發。

為什麼與系統統計對不上

系統「設定」裡的行動網路統計與 Data 頁的讀數經常不相等,原因有三個:

• 計算基準不同:系統統計的是網卡層的收發,包含所有直連流量與系統自身請求;Data 頁只統計進入通道的部分。
• 時間區間不同:系統統計依計費週期或手動重置的區間累計,Data 頁的計數從你上次重置或安裝時開始。
• 處理方式不同:部分協定會對流量做額外封裝,通道內的計數與實際網卡計數之間存在正常差異。

三者疊加,兩組數字不一致是常態,不需要據此判斷「統計壞了」。要判斷方案用量,以服務商面板上的讀數為準——Data 頁更適合用來做相對比較。

用它定位異常流量的順序

發現流量消耗異常時,依「總量 → 伺服器 → 應用程式 → 規則」的順序看:

1. 先看總量增速,確認異常是持續出現的,還是集中在某一段時間。
2. 再看依伺服器讀數,找出承載流量最多的那個節點。
3. 接著看依應用程式讀數,定位到具體應用程式。
4. 最後回到 Config 頁,檢查這個應用程式的網域是否原本該走 DIRECT,卻被前面的規則帶到了代理。

第 4 步是最容易被跳過、也最容易出結果的一步:很多「流量莫名增加」的情況,根源是某條寬泛的規則把原本該直連的請求引到了代理上。相關讀數的更多解釋在本站部落格《Shadowrocket Data 頁流量統計怎麼看》裡。

重置與記錄

Data 頁提供重置入口,重置後計數從零開始。建議在調整規則前後各重置一次,用兩段讀數做對照,比盯著累計數字更容易看出改動是否生效。

最後提醒一點:Data 頁的流量統計與你的線路方案用量是兩件事。方案餘量、計費週期、超量策略都由服務商決定,以服務商面板為準;用戶端這邊只能看到經過自己的那部分。

Settings 頁集中了不隨節點變動的全域選項。這一章挑出日常真正會動的幾項,說明它們各自解決什麼問題、什麼時候才需要改。

On Demand:按需連線

On Demand 決定應用程式在什麼網路條件下自動連線與中斷,觸發條件分三類:

• Wi-Fi:依目前連線的 Wi-Fi 名稱比對,可以指定某些網路自動連線、某些網路自動中斷。
• 行動網路:在行動數據下自動連線,常用於「出門自動開」的用法。
• 網域:存取特定網域時觸發連線,適合依目標而不是依網路判斷的情境。

三類條件可以組合,組合之後是「或」的關係:任意一條滿足即觸發。常見的誤設是把條件寫成互相矛盾的兩條,例如 Wi-Fi 下要求中斷、同時又依網域要求連線,結果表現為連線狀態反覆切換。設定完成後,建議在真實的網路切換情境裡驗證一次。更細的參數說明見本站部落格《Shadowrocket On Demand 按需連線:Wi-Fi、行動網路與網域觸發怎麼設》。

DNS

DNS 設定決定網域解析走哪條路徑。預設跟隨系統即可滿足大多數情境;需要指定解析伺服器時,可以在這一項裡填入位址。改動 DNS 會直接影響網域類規則的判斷結果,改完之後依第 6 章的三步自我檢查確認一次。

要提醒的是,DNS 與分流是兩層邏輯:先解析出網域對應的位址,再依規則決定這條連線怎麼走。解析環節出問題,規則寫得再對也不會生效。

Bypass 與區域網路

Bypass 名單裡的位址永遠不進入通道,常見的例子是區域網路網段與本機位址。預設值已經涵蓋常用的私有網段,除非有明確的區域網路服務需要存取,否則不需要改動。把公網位址誤加進 Bypass,會讓原本該走代理的流量直接出去。

訂閱自動更新

這一項控制訂閱的重新整理時機:打開時自動更新、依週期自動更新。訂閱內容經常變動的使用者建議開啟;訂閱穩定的使用者可以關掉,減少每次啟動的網路請求。無論開關如何,手動 Update 始終可用。

代理埠與區域網路共享

Shadowrocket 可以在本機監聽一個代理埠,供同一區域網路內的其他裝置使用。開啟後需要允許本機網路權限(第 2 章提到的第三個彈窗)。這是一項有明確使用情境的功能:只在確實需要給其他裝置提供代理時開啟,用完關閉。

記錄與診斷

記錄開關用於記錄連線過程。排查疑難問題時打開、重現一次、再關閉,把記錄內容與服務商核對。日常保持關閉即可,長期開啟只會占用空間。

iCloud 同步與備份

設定可以透過 iCloud 在裝置之間同步。開啟後,換機時不需要重新整理規則;不開也不影響使用,只是需要手動匯出匯入。兩種方式都可以,關鍵是選定一種並保持一致,避免兩台裝置上的規則版本互相覆蓋。

不需要動的項目

Settings 裡還有一批與外觀、提示、實驗性功能相關的開關。它們大多有合理的預設值,在沒有明確需求時保持預設,是讓設定保持可預測的最簡單方法。每改一項之前,先想一下「它解決什麼問題」;想不出答案的改動,通常會在幾週後變成新的困惑。

最後一章講日常維護:訂閱更新失敗怎麼查、節點失效怎麼處理、換機怎麼移轉,以及哪些操作其實不需要做。

訂閱更新失敗的排查順序

1. 連結本身:確認訂閱連結沒有缺字元、沒有過期,與服務商目前提供的一致。
2. 網路可達:訂閱網域本身可能需要經過代理才能存取,先連線一個可用節點再更新。
3. 回傳格式:更新成功但節點列表為空,代表回傳內容不是用戶端能辨識的格式,與服務商核對。
4. 帳號狀態:以服務商面板上的狀態為準,用戶端看不到帳號端的資訊。

四步之後仍失敗,把更新時看到的提示原樣傳給服務商,比描述「用不了」有效得多。相關的常見原因在本站部落格《Shadowrocket 訂閱更新:手動更新、開啟時自動更新與失敗原因》裡有更細的展開。

節點失效與切換

單一節點連不上時,先測一次延遲,再換一個節點對照。如果同一訂閱下的多個節點同時失效,優先懷疑訂閱需要更新或帳號狀態變化,而不是逐個排查節點參數。頻繁在多個節點之間來回切換並不能改善穩定性,固定兩三個可用節點、其餘留作備用,是更省事的狀態。

規則與設定的維護

規則是設定裡最容易累積冗餘的部分。建議每隔一段時間做一次清理:刪掉已經不再存取的網域規則,把重複的項目合併,確認備援規則仍在最後一行。改動前先匯出目前設定留一份副本——設定檔本身很小,備份成本幾乎為零。

如果規則引用了遠端列表,留意列表本身的更新頻率;遠端內容無法存取時,本機既有的規則會繼續運作,不會導致連線中斷。規則寫法的系統說明見本站部落格《Shadowrocket 規則寫法:DOMAIN、GEOIP、IP-CIDR 與 FINAL 各比對什麼》。

換機與重新安裝

換到新裝置時,先在新裝置上用同一個 Apple ID 從 App Store 的已購項目重新下載 Shadowrocket,再從 iCloud 同步或匯入先前備份的設定,最後重新填一次訂閱連結(訂閱連結屬於帳號憑證,同步範圍依你自己的備份方式而定)。

重新安裝應用程式之前,先確認設定已經匯出。解除安裝會連同本機設定一起清掉,這一步沒有後悔的餘地。

應用程式更新與系統升級

應用程式更新走 App Store,與一般應用程式沒有差別。系統大版本升級之後,如果連線行為出現變化,先檢查 VPN 設定授權是否仍然有效,再依第 6 章的七步順序排查一次——升級後權限重置是常見的現象,不是應用程式出了問題。

三個常見誤區

• 把用戶端當成線路:買斷應用程式不等於取得任何流量,節點與訂閱始終來自你的服務商。
• 把「連線成功」當成「線路可用」:狀態列圖示只代表通道建立了,實際能不能通要看驗證結果。
• 把規則當成萬用開關:規則只能決定流量怎麼走,不能改變伺服器端的狀態,也不能取代服務商提供的服務。

接下來看什麼

本頁涵蓋的是完整流程。如果只想快速跑通,回到使用教學的五步主線;遇到具體問題,常見問題頁依「正版核驗與購買 / 安裝與首次開啟 / 訂閱與節點匯入 / 規則分流與疑難排查」四類整理了問答;想深入某個主題,可以到日誌裡找專題文章。