Shadowrocket 疑難排解手冊

01 · 系統授權與連線生命週期

開關無法啟用，或啟用後立即關閉

先觀察開關在哪個階段失敗：點按後毫無反應、出現系統授權提示但未完成，或短暫連線後立即中斷。這三種情況的檢查方向不同。開關代表系統網路延伸功能的啟動流程，不等於伺服器已能轉送流量。必須先讓連線維持啟用，後續的伺服器測試和網頁驗證才有明確意義。排查時暫時停用 On Demand，避免自動觸發連線干擾手動觀察。

先完成系統授權，再檢查設定

首次啟用時，系統可能會詢問是否允許加入 VPN 設定。請確認目前操作是從剛開啟的 Shadowrocket 發起，再依系統提示完成授權及裝置身分驗證。若先前取消提示，請返回 App 再次啟用，觀察是否重新出現提示。若裝置由學校或公司管理，相關權限可能受到管理政策限制；這類限制無法透過修改伺服器參數解決，應先確認裝置是否允許加入及執行相關網路設定。

進入系統 Settings，尋找 VPN 相關設定，確認是否有 Shadowrocket 對應的設定，並留意目前是否有其他網路連線處於啟用狀態。先停止其他連線，再返回 Shadowrocket 嘗試，避免同時變更多個網路元件。不要只憑狀態列是否顯示圖示判斷是否成功：不同裝置和顯示情境可能會隱藏部分狀態資訊，請一併確認 App 內的連線狀態和系統 VPN 頁面。

區分設定載入失敗與伺服器通訊失敗

如果系統授權已完成，但開關仍立即關閉，請檢查 Config 中目前選取的設定是否能正常開啟。特別留意剛手動編輯的欄位、尚未完成的設定匯入，以及引用的策略名稱是否仍存在。先還原到修改前儲存的副本，不要繼續疊加新設定。若還原後連線可以維持，排查重點應放在設定差異，不要立刻刪除 App 或重建所有伺服器記錄。

同時確認 Home 中有可用的伺服器記錄，且在需要使用代理的模式下已選取目標。伺服器列表為空、群組選項引用失效，或設定指向已刪除的名稱，都可能使後續連線行為不如預期。可以暫時選取一筆已自行核實參數的記錄，進行最基本的測試。這裡的「基本」是減少設定依賴，不是要求關閉憑證驗證，也不是把所有流量永久改用同一種策略。

依可復原的順序處理系統問題

先正常關閉連線，離開目前的編輯頁面，再重新開啟 App 嘗試一次；若仍失敗，請重新啟動裝置，讓系統網路延伸功能重新初始化。重新啟動前，請儲存尚未寫入的設定修改。若問題只在切換網路後出現，先在穩定的 Wi-Fi 下驗證，再單獨檢查行動網路權限。裝置儲存空間不足時，也應先釋出必要空間，避免設定儲存及診斷記錄寫入受阻，但請勿未經確認就刪除設定檔。

只有在設定已備份、已有伺服器資訊可重新匯入，且確認系統設定確實損毀時，才考慮移除系統中對應的 VPN 設定，再由 App 重新建立。操作前請關閉 On Demand 並停止連線，避免移除後受到自動觸發流程干擾。不要把「重置所有網路設定」當作第一步；這會影響裝置上的其他網路記錄，而且未必能修正參數錯誤。重新授權成功後，先測試開關能否穩定維持啟用，再進入下一章驗證實際通訊。

02 · 基礎網路、模式與規則

顯示已連線，但網頁或 App 無法上網

先關閉 Shadowrocket，嘗試開啟平時可直接瀏覽的網頁，確認裝置本身已連上網路。公共 Wi-Fi 可能需要先完成網路登入；路由器也可能只連上區域網路，沒有可用的外部連線。基礎網路尚未恢復時，修改代理參數無法解決問題。完成登入或修復網路後，再啟用 Shadowrocket，使用同一個網頁重新測試，並盡量維持相近的測試對象和時間。

透過 Global Routing 縮小問題範圍

Global Routing 中的 Config、Proxy、Direct 是診斷時最實用的區分方式。Config 依目前設定中的規則選擇策略；Proxy 用來檢查目前的代理路徑；Direct 用來觀察直接連線的情況。它們不是網路品質等級，也不保證所有目標都能存取。測試前記錄原本的模式，每次只變更這一項，並確認自己正在驗證哪條路徑，避免測試結束後忘記還原。

若 Direct 能開啟測試網頁，但 Proxy 失敗，請先檢查所選伺服器，不要立刻修改所有規則。若 Proxy 正常而 Config 失敗，請查看目標在 Config 下命中了哪項策略：可能是過早比對到 REJECT，也可能是需要代理的目標被導向 DIRECT。若三種模式都異常，也應回頭檢查基礎網路、DNS 和系統連線，不宜只憑一次網頁測試失敗就認定訂閱無法使用。

檢查規則順序與實際目標

規則通常依序比對，前面的寬泛規則可能會蓋過後面的精確規則。以下片段用來說明先比對具體條件，最後使用 FINAL 的結構，並非建議直接覆蓋現有設定。PROXY 必須在目前設定中有可用的策略引用；若現有設定使用其他策略名稱，請依實際定義核對。先在副本中編輯，再透過記錄確認比對結果，避免只看檔案文字就推測實際連線路徑。

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

網頁通常不只會向一個網域發出請求。頁面主體、圖片、登入介面和媒體內容可能分別連線至不同目標，因此「首頁能開啟但無法登入」仍可能是分流不一致。請查看發生故障時的連線記錄，找出實際失敗的網域及命中策略，再判斷是否需要調整規則。不要為了省事就把大量無關網域全改成同一策略，也不要依據網頁標題推斷所有請求都使用同一個位址。

排除 App 本身的工作階段與區域網路影響

切換模式後，原有長連線可能仍在使用先前的工作階段。請離開測試 App 的相關頁面，重新發出請求；必要時正常關閉再重新連線，然後比較結果。若問題只出現在某個 App，請同時用瀏覽器測試同一服務，區分 App 快取、登入狀態及網路路徑。單一服務維護、驗證失敗或存取限制，也可能造成載入停滯；不能只因「其他網頁正常」就斷定規則一定沒有問題。

存取路由器管理頁、區域網路裝置或家庭儲存設備時，請優先檢查區域網路網段是否被錯誤導向代理。不要直接套用範例網段，請以目前網路的位址配置為準。若連線記錄顯示規則正確，但網域始終解析失敗，請前往 DNS 章節；若網域已取得位址，但無法建立伺服器路徑，請前往伺服器逾時章節。保留這種分流判斷，可避免在規則、訂閱與系統設定間反覆修改。

03 · 端點、認證與傳輸

伺服器逾時，或 Connectivity Test 失敗

逾時只表示某項測試未能在指定時間內完成，不能直接指出哪個欄位有誤。應先辨別測試類型：連接埠連線、代理後的網頁請求、DNS 查詢，以及 App 內的 Connectivity Test，驗證的層級各不相同。連接埠能建立連線，不代表認證和資料轉送一定成功；網頁測試失敗，也可能是測試目標暫時無法連線。記下測試對象和錯誤內容，比反覆點按測試更有助於定位問題。

先核對伺服器位址與連接埠

開啟對應的伺服器記錄，對照服務商提供的資訊檢查 Address 和 Port。Address 通常填寫主機名稱或位址，不要把完整網頁網址、路徑和多餘空格一併貼上。Port 應與伺服器實際監聽的連接埠一致，不能依協定名稱推測。若位址是網域，請先確認解析是否成功；若連解析都未完成，繼續修改 Password 或傳輸設定通常沒有意義。

接著核對協定類型與認證欄位。Trojan 的 Password、VMess 或 VLESS 的身分欄位，以及 Shadowsocks 的加密方式和密碼，各自用途不同，不能互相套用。匯入成功只表示文字已被辨識，不代表遠端參數已通過驗證。尤其是手動填寫時，應檢查複製內容是否包含換行、前後空格或全形標點；修改後先儲存，再重新選取該記錄，確認測試確實針對剛編輯的項目。

TLS 與傳輸參數應分開檢查

使用 TLS 時，Address 與 SNI 不一定相同：前者決定連線至哪個端點，後者用於伺服器名稱指示及憑證驗證。請依現有伺服器的實際設定填寫，不要在 SNI 中填入任意網域。檢查系統日期、時間和時區是否正確；時間偏差可能導致憑證驗證失敗。若記錄提示憑證名稱不符或憑證過期，請核對遠端部署，不要把略過驗證當成長期解決方式。

若伺服器另有傳輸層要求，也需核對對應的 Host、Path 和傳輸類型。Path 開頭的斜線、大小寫及附加內容都可能影響路由，不能只看是否「大致相同」。Hysteria2 等使用 UDP 的連線，也應考量目前網路是否允許相關流量；TCP 網頁可以存取，不代表 UDP 路徑也正常。改用另一個自己有權使用的網路進行比對，比同時修改多個協定欄位更容易得出結論。

透過交叉測試區分本機與遠端問題

使用同一筆伺服器記錄，分別在 Wi-Fi 與行動網路測試；接著維持同一網路，測試另一筆自己已有且確認可用的記錄。前一組有助於判斷網路差異，後一組則有助於判斷個別端點是否異常。不要同時更換網路、伺服器和設定，否則即使恢復，也無法確認原因。若同一端點在不同網路都失敗，而其他現有端點正常，請向原服務商確認端點狀態及參數是否有變更。

向服務商說明問題時，提供已去除敏感資訊的錯誤類型、網路環境和測試時間即可，請勿公開完整認證資訊。如果連接埠連線成功，但實際網頁請求失敗，請繼續檢查認證、傳輸和目標回應；若所有現有端點都只在某個網路下失敗，應先排查該網路及路由器。Trojan 欄位的逐項說明請參閱Trojan 參數說明，避免以試填取代參數核對。

04 · 取得內容、解析與本機列表

訂閱無法更新，或匯入後沒有伺服器

訂閱更新包含多個獨立階段：連線至訂閱網址、取得回應、辨識內容、解析記錄，以及更新本機列表。列表為空不一定表示網址無法連線，也可能是伺服器回傳登入頁面、錯誤說明，或目前入口無法辨識的內容。請先記錄更新時顯示的錯誤，再檢查網址及回應層級。不要連續刪除原有列表，舊記錄可能仍可使用，也是判斷這次更新差異的重要參照。

先區分訂閱網址與單一節點分享連結

向自己的服務商核對完整訂閱網址，確認複製時沒有遺漏查詢參數、末尾字元或必要的認證部分。訂閱網址與單一節點分享連結用途不同：前者通常用來取得一組可更新的記錄，後者則描述單一連線。把單一節點內容貼到訂閱更新入口，或把設定檔網址當成伺服器訂閱，都可能造成辨識失敗。請依內容類型選擇入口，不要只因網址看起來很長，就認定它是訂閱。

也請檢查複製內容是否包含說明文字、引號、空格或換行。某些分享操作會連同標題和網址一起複製，請只保留實際網址。訂閱中的認證資訊屬於敏感內容，不應貼到公開的網址檢查頁面，也不要直接發到討論區請他人代測。需要描述問題時，可以說明錯誤類別，並完整移除網址中的身分資訊，而不是只遮住幾個字元。

判斷是請求失敗，還是回傳內容不正確

若錯誤涉及主機解析、連線逾時或 TLS，請先檢查訂閱網域的解析和請求路徑。訂閱更新是否經過代理可能受設定與配置影響，不能因為網頁可以開啟，就推斷更新也走相同路徑。若目前伺服器已無法使用，而訂閱請求又依賴該伺服器，就可能形成更新失敗的循環。請在允許且可用的網路環境中驗證請求，並保留原設定，避免把「更換線路」和「重新取得訂閱」混成同一個動作。

若錯誤顯示存取遭拒或資源不存在，請優先核對網址是否已由服務商更換、認證是否失效，以及帳戶狀態是否允許讀取。若出現重新導向，也要確認最終回應確實是訂閱內容，而不是需要登入的網頁。即使瀏覽器顯示頁面成功，也可能只是呈現錯誤說明；反過來說，瀏覽器能下載或顯示文字，也不代表其中每筆伺服器記錄都能被目前的匯入入口正確辨識。

列表為空時，檢查篩選、解析與覆蓋情況

收到內容後仍看不到記錄，請先清除 Home 中可能設定的搜尋條件，展開對應群組，並確認目前查看的是剛更新的訂閱。比較更新前後的項目數量和名稱，判斷是完全未解析，還是只有部分協定或欄位未被辨識。若訂閱本身包含篩選條件，請確認是否因此排除了所有記錄；不要只因某個群組為空就反覆匯入同一網址，以免產生難以辨識的重複項目。

訂閱更新可能會重新產生由訂閱管理的伺服器記錄；手動修改這些記錄後，再次更新時，修改可能會被覆蓋。因此，若要長期保留個人調整，請先確認管理方式並留存副本。若要區分內容問題與網路問題，可以用自己已有的一筆完整伺服器資訊手動新增測試：若手動記錄正常，但相同來源的訂閱持續無法解析，排查重點就在訂閱格式與回應內容，而非反覆修改系統 VPN 授權。

若需要重新整理匯入方式，請參閱訂閱與單一節點匯入方式；若不確定內容類型，請查看分享連結格式說明。復原後保留一次成功更新的觀察結果，再設定合適的更新頻率；不要以高頻重試掩蓋持續發生的請求錯誤，也不要把更新按鈕當成伺服器連線測試。

05 · 等待階段與持續傳輸

連線可用，但開啟速度慢或傳輸不穩定

應先把「慢」分成等待首次回應、網頁資源載入和持續傳輸三個階段。點按後長時間沒有回應，通常與解析、建立連線或交握有關；頁面先出現文字，但圖片遲遲未載入完整，可能涉及多個目標的路徑差異；若一開始正常，持續傳輸時卻越來越慢，則還需考量壅塞、封包遺失和伺服器負載。釐清變慢發生在哪個步驟，比只看某個延遲數字更有助於診斷。

建立條件一致的對照測試

選一個能穩定重現問題的目標，在相近時間、同一網路、同一裝置和同一伺服器下重複兩三次即可。測試期間，暫停系統大型檔案同步、其他裝置的大量傳輸及不相關的背景工作。網頁內容本身也會變動，因此應盡量使用相同頁面和操作。不要同時執行多項高流量測試，它們會爭用同一條連線，最後測得的是彼此干擾後的結果，而非平時使用時的速度。

接著分別比較 Wi-Fi 和行動網路，或比較自己已有的其他伺服器，每次只更換一個條件。若所有伺服器只在同一 Wi-Fi 下變慢，請檢查路由器、無線訊號和目前網路負載；若只有某一台伺服器變慢，請優先留意該端點及其通往目標的路徑。若只有單一目標變慢，應考量目標服務本身的回應及資源分發，不要直接歸因於用戶端整體效能問題。

延遲、頻寬與實際體驗是不同指標

低延遲通常有利於互動和短時間請求，但不代表持續下載一定更快；延遲較高也不一定代表頻寬不足。App 內的測試還會受到測試網址、請求類型及逾時門檻影響。判斷是否可用，應以實際工作為準，例如能否完成登入、影片是否持續緩衝、檔案傳輸是否中斷。不要因一次測試結果就頻繁切換伺服器，切換本身可能中斷部分工作階段，並增加新的交握成本。

Global Routing 也會影響結果。Config 下可能只有部分資源經過代理，Proxy 下則會把更多請求送入所選路徑；兩次觀察若未記錄模式，就不是嚴謹的對照。請檢查連線記錄中是否有反覆失敗的資源，尤其是登入介面、媒體分段和解析請求。若某項請求不斷重試，整個頁面看起來就會很慢，但真正需要修正的可能只有一條規則或一個無法存取的網域。

依連線特徵處理，不要盲目調整參數

Wi-Fi 訊號較弱或裝置頻繁在不同存取點之間切換時，可能造成傳輸量下降和重新建立連線。請先靠近存取點測試，並確認裝置沒有在多個網路間自動切換。若目前網路需要登入，登入工作階段到期也可能使背景連線反覆失敗。使用 UDP 的協定應另外比較目前網路是否明顯受限或有封包遺失；其他協定能正常使用，只能表示另一條傳輸路徑可用，不能證明所有流量條件都相同。

沒有依據時，不要修改 MTU、並行連線或協定進階參數。MTU 不相符確實可能影響傳輸，但類似症狀也可能來自目標服務、無線連線或遠端壅塞。只有在問題可穩定重現、已有明確部署要求，且已儲存原始值時，才逐項調整並比較。變更後若未穩定改善，請還原原值，避免留下多項互相掩蓋的設定，增加下次排查的難度。

最後檢查裝置溫度、電量狀態和本機儲存空間負擔。長時間傳輸、螢幕錄影與其他運算工作同時進行時，裝置整體效能變化也會影響使用體驗。先停止無關工作，讓裝置恢復正常狀態，再重測相同操作。若主要是第一次開啟時變慢、後續存取正常，可以繼續檢查 DNS 快取和連線重用；若只有持續傳輸不穩，則應著重檢查網路波動、遠端狀態和工作階段中斷記錄。

06 · 名稱解析與連線路徑

DNS 解析失敗，或只有部分網域無法開啟

DNS 負責將網域轉換為連線所需的位址；它與「連線至哪台伺服器」及「使用什麼分流策略」有關，但並非同一個環節。網域無法解析時，請求可能尚未進入目標連線階段；取得位址後，仍可能因路由、連接埠或目標回應而失敗。排查時先查看記錄中的錯誤屬於解析、建立連線還是 TLS，避免把所有網頁無法開啟的情況都歸因於 DNS，也不要只因解析有結果就排除 DNS 相關差異。

分別檢查伺服器網域與目標網域

至少要區分三類名稱：代理伺服器的網域、訂閱網址的網域，以及要瀏覽的網站網域。代理伺服器網域若無法解析，連線本身就可能無法建立；訂閱網域解析失敗會影響更新，但不一定影響現有記錄；目標網域解析失敗則可能只造成部分服務異常。這三類請求可能使用不同的設定和路徑，請分別觀察，不要因為訂閱可以更新就斷定所有解析都正常。

系統 DNS 取決於目前網路提供或裝置指定的解析設定；自訂 DNS 則使用設定中的解析端點；DNS over HTTPS 透過 HTTPS 傳送查詢。加密傳輸改變的是查詢通道，並不會自動確保端點可連線，也不代表它適用於目前網路。若 DNS over HTTPS 的端點使用網域，還要考量端點本身如何完成初始解析，避免讓解析請求依賴尚未建立的連線。

先閱讀現有設定，再逐項替換

開啟目前生效的設定，確認是否有 dns-server 等相關項目，並檢查是否在多個位置留有先前的修改。以下片段僅展示 [General] 與規則段落的組織方式，其中 system 表示使用系統解析來源，並非適用於所有網路的通用建議。不要直接將它附加到現有檔案末尾，造成重複段落；請先了解現有設定，再於副本中修改對應欄位。

[General]
dns-server = system

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

修改後重新發出測試請求，並留意快取的影響。某個 App 可能保留舊的解析結果或既有連線，即使設定已變更，介面上的狀況也不會立即改變。請先關閉相關頁面再重新開啟；必要時正常重新連線 Shadowrocket，再比較記錄。不要靠不斷更換解析伺服器碰運氣：應保留可供判斷的基準，並確認每次修改改變的是解析來源還是請求路徑。

留意位址類型、區域網路與分流一致性

同一網域可能會回傳 IPv4 和 IPv6 位址。如果目前網路對其中一種位址類型的連線不穩定，可能出現時好時壞，或等待一段時間才成功的情況。應根據失敗記錄中的實際目標位址分析，而不是把「回傳多個位址」當成異常。不要長期關閉某種位址類型來掩蓋未知問題；若確實需要暫時比對，請記錄原始設定，測試結束後還原，並檢查所用伺服器與網路是否支援相應路徑。

區域網路名稱也可能仰賴路由器或特定的本機探索機制。改用遠端解析來源後，家庭裝置名稱可能無法解析，但直接連線到正確的區域網路位址仍可使用。遇到這種情況，應檢查區域網路解析與 DIRECT 規則是否搭配，而不是把區域網路裝置也導向代理。另一方面，目標解析出的位址與最終連線路徑不一致時，也可能影響存取結果，需一併核對命中規則和解析來源。

若只有單一網域失敗，請先比較它在不同網路下的情況，並檢查目標是否已更換網域、憑證或服務入口。不要只憑一次解析結果判斷內容服務的狀態。若大量網域都失敗，但伺服器端點仍可連線，應著重檢查解析端點的可達性及設定依賴。更完整的欄位說明請參閱DNS 設定說明；修復後至少重新測試一般網頁、原本失敗的目標及需要使用的區域網路資源，確認不只修好其中一類。

07 · 背景工作與重複連線

耗電增加、裝置發熱或背景活動偏多

先區分「電池頁面將流量處理歸在 Shadowrocket 名下」和「裝置確實額外耗電」。網路延伸功能會持續處理經過的流量，系統統計可能將部分相關活動計入其使用記錄；這不代表每次耗電變化都是由用戶端設定造成。應同時比較總電量下降、實際使用工作、螢幕開啟時間和網路狀況，不能只看某個 App 在列表中的占比就下結論。

在相近工作情境下建立電量基準

選擇一段日常可重複的使用流程，記錄所用網路、螢幕狀態和主要工作。連續播放影片、同步檔案和待機的流量差異很大，不能直接比較。裝置溫度、充電狀態和無線訊號也會改變耗電情況；行動網路訊號較弱時，通訊本身可能增加能耗。先在訊號穩定、裝置溫度正常的環境中觀察，再判斷異常是否與 Shadowrocket 連線同時出現。

排查時不要一開始就關閉所有功能。先查看是否有持續的大量流量工作，包括照片同步、檔案傳輸和其他 App 的背景請求。即使前景沒有操作，這些工作仍可能經過目前的連線。暫停與測試無關的工作後，觀察網路活動是否明顯減少；若有減少，排查重點應放在流量來源及工作安排，而不是把正常的資料轉送誤認為連線閒置時仍大量耗電。

找出失敗重試與自動觸發循環

若裝置幾乎沒有使用時仍持續發熱，請檢查連線記錄是否出現重複解析、反覆交握或短時間內大量失敗。失效的伺服器、無法連線的訂閱網址，以及某個 App 不斷重試的介面，都可能造成額外活動。先找出最常失敗的目標，再修正對應問題。不要透過永久隱藏錯誤記錄來處理，因為記錄變少不代表背景重試已停止，只是失去觀察依據。

On Demand 應優先檢查觸發條件是否與日常網路變化衝突。裝置在 Wi-Fi 和行動網路間切換，或網路登入狀態變更時，可能反覆觸發連線。先記錄目前條件，暫時關閉自動觸發，以手動連線觀察相同工作一段時間；若循環消失，再逐項恢復條件。不要把「自動連線頻繁」直接解讀為功能異常，它也可能只是照常執行了過於寬泛或會交替符合的條件。

減少不必要的工作，而非犧牲診斷能力

檢查是否設定了過於頻繁的訂閱更新或批次測試。自動更新和測試都會消耗網路資源，已有內容不必每次切換頁面時都重新取得。依使用需求安排更新，排查期間避免連續測試整份列表。若只需驗證某台伺服器，單獨測試即可。診斷結束後，將暫時開啟的詳細記錄恢復為日常所需層級，並處理不再需要的診斷檔案，避免長期保留大量敏感記錄。

連線保活、逾時和協定相關參數，應依照現有伺服器的要求設定，不建議為了省電任意設成極端值。逾時過短可能造成反覆建立連線，保活過於頻繁也可能增加背景通訊；但參數效果同時受協定、遠端伺服器和網路環境影響，不能照搬固定數值。修改前保留原值，修改後觀察實際工作和待機狀況，不要只看幾分鐘內的電池百分比是否變化。

若耗電變化與系統更新、裝置移轉或大量檔案同步同時發生，也應等相關背景工作結束後再比較。重新啟動裝置可排除部分暫時狀態，但不能取代持續觀察。裝置明顯過熱時，先停止高負載工作，等溫度恢復後再測試；不要讓長時間測速成為新的發熱來源。若在相同工作、穩定網路且關閉重複測試後仍持續異常，請整理連線頻率和失敗類別，進一步核對設定與系統狀態。

08 · 設定差異與可復原操作

App 或系統更新後出現異常

故障發生在更新之後，不代表更新一定是原因。同一時間也可能發生訂閱內容變更、網路切換、伺服器維護或設定自動重新整理。先記錄「最後一次正常使用」和「第一次出現異常」之間做過哪些操作，區分 App 更新、系統更新與設定更新。保留舊設定和目前設定的差異，比立即重新安裝更有價值，也能避免修復過程中遺失唯一可用的記錄。

先核對取得來源與相容性

Shadowrocket 是閉源商業 App，只能透過 App Store 取得和更新。購買與正版資訊請參閱下載頁的核驗章節，重點核對開發者 Shadow Launch Technology Limited、官方圖示及 App ID 932747118。系統需求以 App Store 頁面標示為準。不要依據舊文章中的系統需求判斷目前裝置是否相容，也不要混淆 App 購買記錄與本機設定是否已儲存。

若 App 可以開啟，請先檢查 Home 中選取的伺服器、Global Routing 模式，以及 Config 中生效的設定是否與之前一致。更新後若出現提示，應先閱讀具體內容再操作；某些問題只是原先選取的記錄已被訂閱更新取代。確認設定存在後，正常中斷再重新連線一次，接著使用原本的測試目標驗證。尚未確認目前狀態前，不要連續匯入多份備份，以免檔案和策略名稱更加混亂。

依系統、App、設定三個層級逐一比對

先在關閉連線的狀態下驗證基礎網路，再測試系統連線能否維持，最後測試代理後的實際存取。如此可將系統授權問題與規則問題分開。若開關立即關閉，請回到第一章處理；若連線能維持但只有 Config 失敗，優先比對設定；若某一台伺服器在相關模式的所有測試中都失敗，請檢查它是否剛好在同一時間變更參數或停止服務。

比較設定時，著重檢查最近修改的 DNS、規則順序、策略名稱和遠端引用，無須從頭重寫整份檔案。舊副本可供比對，但不應未經判斷就覆蓋所有新內容。遠端設定即使檔名未變，實際內容也可能已更新，因此應儲存可供閱讀的本機副本。若還原某個欄位後問題消失，請確認結果能重現，避免把網路恰好恢復誤認為欄位修改有效。

重建或重新安裝前，先確認備份範圍

還原 App 購買項目、還原伺服器記錄和還原設定是三件不同的事。App Store 可協助找回已購買的 App，但不代表所有本機記錄、認證資訊和手動修改都會自動恢復。決定重新安裝前，請確認現有訂閱網址仍可取得、手動伺服器參數已有安全備份、設定副本可以開啟，並了解哪些資料仰賴同步。不要在唯一保留完整設定的裝置上，未經檢查就執行刪除。

使用 iCloud 或檔案匯出備份時，請實際確認目標裝置或備份檔案，而不只查看同步開關是否已啟用。認證資訊和訂閱網址具有敏感性，匯出檔案應存放在受控位置。移轉步驟請參閱設定備份與換機復原。若需要重建系統 VPN 設定，請先依第一章處理，通常不必一併清除所有 App 資料。

復原後依固定順序驗收：確認 App 可開啟、系統授權已完成、設定已選取、現有伺服器可用，再測試訂閱更新和日常目標。每個步驟通過後，才恢復自動工作，避免多項背景操作同時發生。若異常仍可重現，請記錄系統環境、App 內可見的相關設定、最簡化的重現步驟及已去除敏感資訊的錯誤；不要公開完整設定來證明問題。記錄應說明操作和結果，而非只寫「更新後就壞了」。

09 · 獨立裝置、共用設定與區域網路

iPad 發生異常，但 iPhone 使用正常

請把 iPad 當成獨立裝置檢查，不要直接套用 iPhone 的成功結果。兩台裝置可能連上不同的 Wi-Fi、使用不同的解析來源，或選取了不同的設定和伺服器。即使顯示相同的訂閱名稱，最後更新時間和內容也可能不同。先讓兩台裝置連上同一網路，再逐項比較可見設定，確認差異來自裝置環境還是設定本身。

確認購買、權限與裝置網路條件

iPad 的取得說明請參閱iPad 購買與首次開啟。已購 App 的重新取得方式與適用範圍，以 App Store 頁面標示為準；系統需求亦以 App Store 頁面標示為準。App 已安裝不代表系統 VPN 授權已完成；在 iPhone 上完成的授權不會自動取代 iPad 的本機授權。請先檢查 iPad 的系統 VPN 頁面，再測試開關能否維持啟用。

在受管理的 iPad 上，還要確認裝置政策是否允許相關連線。行動網路機型與僅使用 Wi-Fi 的裝置，可用的測試路徑也不同；若沒有另一條獨立網路，不應把無法進行交叉測試誤判為某個參數已正確。可在獲准使用的另一個 Wi-Fi 下進行比對，並留意公共網路是否需要每台裝置分別登入。iPhone 已完成登入，不代表 iPad 的網路工作階段也已完成。

逐項比較，不要整份覆蓋

先比較 Global Routing、目前的 Config 和所選伺服器，再比較協定欄位、DNS 和規則。訂閱名稱相同但伺服器列表不同，可能只是其中一台尚未成功更新；項目名稱相同但認證欄位不同，也可能是手動修改所致。比較時不要透過聊天工具傳送完整憑據，可在各自裝置上對照原服務商提供的資訊。確認差異後只修正對應項目，避免把 iPhone 的區域網路專用規則直接覆蓋到不同的網路環境。

橫向、分割畫面和視窗大小變化可能改變導覽介面的呈現方式，但不會改變 Config、Home 或 Settings 的設定意義。若某個按鈕不在熟悉的位置，請先退出搜尋、關閉編輯狀態並確認目前所在的區域，不要反覆匯入相同內容。列表過長時，也應檢查篩選條件和群組是否已展開。介面位置變動與伺服器通訊失敗應分開處理，不能因為找不到入口就認定設定遺失。

檢查休眠後恢復、網路切換與區域網路存取

若問題只在喚醒後發生，請先記錄裝置休眠前後的網路是否相同，以及 On Demand 是否重新觸發連線。開啟新的網頁請求，比查看先前停留的頁面更可靠，因為舊頁面可能保留已中斷的工作階段。若重新連線後恢復，請繼續檢查網路變化和自動觸發條件，不要只靠延長螢幕常亮時間掩蓋問題。待機狀況也應配合耗電章節檢查是否反覆重新連線，而不只是查看前景開關狀態。

iPad 常用於存取家庭儲存設備、投放裝置或其他區域網路服務。連線後這些功能異常時，請先檢查它們使用的實際位址和本機網路權限，並核對對應網段是否走 DIRECT。裝置探索可能仰賴廣播或本機探索機制，單一網域規則不一定涵蓋整個流程。先確認能否直接存取已知的區域網路位址，再區分名稱探索、App 權限和網路轉送問題，不要把所有相關功能都歸因於 DNS。

設定同步也需要單獨驗收。檔案已出現在另一台裝置，不代表它已成為目前生效的 Config；伺服器記錄存在，也不代表已選取。移轉後請在 iPad 上重新執行一次完整但精簡的驗證：選取設定、選取現有伺服器、確認模式、啟用連線，並存取原本的測試目標。全部通過後再恢復自動更新與 On Demand，這樣問題若重現，就能判斷是哪個步驟引入了新條件。

最後用相同目標比對兩台裝置，並記錄仍有差異的設定。若 iPhone 正常，但 iPad 在同一網路和相同參數下仍失敗，請繼續檢查 iPad 本機的系統授權、解析結果和錯誤階段；若兩台裝置都失敗，則將重點轉回共用的網路、伺服器或訂閱。若不熟悉日常操作，請返回使用說明；若不清楚欄位含義，請查閱術語手冊，不必為了解決單一局部問題而重建整套設定。