Shadowrocket 故障排查指南

開關無法啟用：先檢查系統連線環節

在 Home 開啟開關後立即跳回關閉狀態，表示連線建立程序尚未完成；這與開關維持開啟、但網頁無法瀏覽是不同的故障。先觀察系統是否跳出新增 VPN 設定的授權提示、是否顯示具體錯誤，以及開關在點選後哪個階段跳回。不要只憑狀態列圖示判斷是否成功，部分裝置的圖示位置會隨系統版面配置而改變。請同時確認 Home 狀態並保留錯誤原文，不要反覆快速切換開關。

分辨未授權、設定衝突與連線失敗

首次啟用時，系統會要求確認新增 VPN 設定。若先前取消授權，請返回 Shadowrocket 再試一次，並依系統提示完成授權；裝置密碼由系統介面處理。接著前往系統 Settings，確認 VPN 設定是否存在，以及目前啟用的是哪一項。裝置上保留多個 VPN 設定不一定有問題，但同時啟動其他連線可能中斷目前連線。請先停止其他正在運作的 VPN，再單獨測試 Shadowrocket，不要直接刪除所有網路設定。

若裝置由學校或公司管理，授權開關無法操作、無法新增設定，或系統明確提示受到管理限制，請聯絡裝置管理員確認政策。刪除 App 通常無法解除這類限制，也可能遺失本機設定。個人裝置則先檢查是否有自動啟動的連線規則：手動停止後立即再次開啟，不一定是按鈕失效，也可能是 On Demand 正在觸發。請先記下觸發條件，再暫時停用相關自動連線行為，詳見耗電與 On Demand章節。

以最精簡設定判斷問題範圍

在 Home 確認已有一個參數完整的伺服器，並明確選取為預設伺服器；只匯入清單而未選取預設項目，無法構成完整的測試條件。暫時將 Global Routing 設為 Proxy 再嘗試啟動，以減少規則檔對判斷的干擾。如果仍立即跳回，應優先檢查授權、系統網路延伸功能狀態或伺服器欄位錯誤；如果可以維持開啟，則應進一步檢查原有 Config 設定或策略引用。測試結束後請恢復原本的路由模式。

儲存目前的 .conf 檔案與必要伺服器資訊後，可先正常關閉 App 連線，再重新開啟 App 測試。若異常發生在切換網路後，先確認目前 Wi-Fi 已完成登入驗證，或行動數據可直接瀏覽一般網頁。系統要求登入網路時，代理連線可能在登入完成前就已失敗。可先中斷連線並完成驗證，再啟動 Shadowrocket；不要將登入頁無法開啟直接解讀為伺服器失效，也不要在不明提示中輸入訂閱憑證。

何時才需要重建系統設定

只有在網路正常、預設伺服器明確，且授權流程仍持續異常時，才考慮重建 Shadowrocket 對應的系統 VPN 設定。操作前先確認 App 內設定已備份，並停止連線、關閉 On Demand，再到系統設定中辨認正確項目。移除該項目後，返回 App 重新發起連線，讓系統再次要求授權。此操作只處理系統連線設定，不會修正錯誤的位址、連接埠或密碼，因此不應將其視為所有故障的固定第一步。

若系統升級後首次出現開關跳回，先重新啟動裝置並以最精簡設定複測，不要連續重新安裝。記錄「是否顯示授權提示、是否建立設定、是否維持連線」三項結果，方便後續定位。恢復正常後，再逐項啟用原有規則、自動連線與附加設定。每恢復一項就測試一次；若啟用某項後再次跳回，請保留這項線索，並檢查其相依設定與內容。常見授權問題也可在FAQ查閱。

已連線但無法上網：依四個環節逐步排除

連線開關維持開啟，只能表示系統連線處於運作狀態，無法證明目前伺服器能轉送流量。先中斷 Shadowrocket，以相同網路瀏覽平時可連線的網頁，確認基礎網路、無線網路驗證與行動數據權限正常。接著重新連線，依序檢查預設伺服器、Global Routing、DNS 與規則命中情況。每一步都使用相同目標，並記錄失敗狀況是等待逾時、名稱解析失敗、憑證提示，或服務端回傳錯誤；不同狀況的排查方向也不同。

先檢查伺服器，再比較三種路由模式

在 Home 確認預設伺服器仍指向預期項目，尤其是在訂閱更新、刪除舊項目或切換群組之後。使用 Connectivity Test 查看連線結果，但不要將單一測試數值視為所有服務都能正常使用的保證。測試成功但目標無法開啟時，仍可能與目標路徑、DNS 或協定傳輸差異有關。若另有其他可用伺服器，可只更換預設項目進行比較；切換後請重新建立連線，避免將舊連線的狀況誤認為新伺服器的結果。

測試三種模式並不是要長期使用其中某一種，而是建立可比較的條件。如果 Direct 可用、Proxy 不可用，應檢查伺服器參數及其網路連線能力；如果 Proxy 可用、Config 不可用，則應檢查規則順序、策略名稱與目前啟用的檔案。如果三種模式都不正常，先檢查基礎網路與 DNS，不要直接新增更多規則。定位完成後，請恢復符合實際用途的 Config，並確認其中引用的是已存在的策略。

依規則命中順序檢查，不要只搜尋關鍵字

[Rule] 通常依序判斷，前面的寬泛規則可能先於後面的精確規則命中。以下片段僅用來說明順序；example.com 是示範網域，不能直接取代你的完整設定。DOMAIN-SUFFIX 涵蓋該網域及其子網域；GEOIP 依目標 IP 所屬資訊判斷；FINAL 則在前面的規則都未命中時作為備用規則。還需要一併考量解析結果、規則涵蓋範圍與實際策略，不能只因檔案中有 PROXY，就認定請求一定經過代理。

[General]
bypass-system = true
dns-server = system

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

若原設定使用自訂策略群組，請檢查群組名稱是否拼寫一致、群組內是否仍有可用項目，以及目前選取項目是否因訂閱更新而改變。修改檔案前請另存一份，避免同時失去可復原的基準設定。只有特定網站無法使用時，可先用一條針對該網域的暫時規則確認方向；測試後再決定是否納入正式設定。不要用寬泛的 DOMAIN-KEYWORD 規則掩蓋問題，也不要將 FINAL 移到前面而蓋過後續規則。

分開檢查瀏覽器快取與系統狀態

瀏覽器可能保留舊頁面、既有連線或先前的解析結果，因此切換模式後應重新發出請求，不要只觀察原本的載入動畫。關閉失敗頁面後重新開啟，必要時改用先前未造訪的測試目標，並與另一個 App 的結果比較。若只有一個網站異常，先檢查該網站本身的狀態與憑證，不要因此重設所有連線。若多個網域都失敗，但既有連線仍可運作，請接著檢查 DNS，判斷方式詳見DNS 專章。

伺服器逾時：核對參數與傳輸路徑

逾時表示在等待期限內未收到預期回應，不代表密碼一定錯誤，也不代表伺服器一定停止運作。連線可能卡在網域名稱解析、位址連線、連接埠建立、TLS 交握或協定驗證等任一階段。先保留測試類型與錯誤原文，確認是 Connectivity Test 逾時，還是實際網頁逾時。部分伺服器不會回應特定探測方式，因此探測失敗應搭配實際請求確認，不能只憑清單中的單一狀態刪除既有設定。

先逐欄核對既有伺服器資訊

開啟 Add Server 對應項目，與服務提供者給你的資訊逐項核對。伺服器位址不可混入路徑、空格或協定前綴；連接埠應符合該入口的設定。密碼、UUID 等驗證欄位應完整保留大小寫與字元，複製時尤其注意末尾換行。不要因欄位看起來相似就互相替代，也不要將訂閱網址直接填入伺服器位址欄。以 QR Code 匯入後，仍須檢查協定類型與重要參數；成功匯入只代表內容已被辨識，不代表參數在目前網路環境下有效。

表格提供的是核對方向，不是通用填寫範本。各欄位是否需要填寫，必須依據既有伺服器的實際設定。更多協定說明請見協定與參數概覽。若伺服器資訊來自訂閱，請先正常更新並比較欄位，再決定是否手動編輯；直接修改訂閱產生的項目，可能在下次更新時被覆寫，導致暫時修正的參數再次變更。

分開判斷 TLS、傳輸類型與 UDP

若錯誤涉及 TLS 交握或憑證，請檢查裝置日期與時間是否正確，以及伺服器名稱是否符合服務端提供的資訊。連線位址與憑證驗證名稱可能不同，但只能依實際設定填寫。不要長期關閉憑證驗證來規避錯誤，這可能掩蓋名稱錯誤、憑證過期或連線對象不正確等問題。若使用特定傳輸方式，Host、路徑等參數也必須與服務端一致；只核對位址與驗證欄位並不足以完成診斷。

一般網頁只能證明相應的網頁路徑可用，無法涵蓋所有 UDP 情境。若同一項目瀏覽網頁正常，但即時通訊或依賴 UDP 的功能異常，應檢查協定能力、伺服器端條件及目前網路是否允許相關傳輸。使用另一個已知可用的設定進行比較時，一次只更改一個變數。例如在同一網路更換伺服器，或在同一伺服器更換網路；若同時更換協定、網路與 DNS，即使恢復正常也無法確認真正原因。

透過網路比較釐清問題範圍

若 Wi-Fi 下逾時、行動數據正常，問題可能與目前 Wi-Fi 的解析、連接埠或傳輸條件有關；但也可能是兩種網路選用了不同位址。先核對解析結果與連線目標，再判斷原因。若多個網路都只有同一伺服器失敗，而其他既有伺服器正常，應向自己的服務提供者確認該入口是否已變更。提供協定類型、錯誤原文與重現條件即可，不要傳送完整密碼、金鑰、訂閱權杖或包含所有欄位的 QR Code。

確認服務端參數正確後，再進行本機測試：選定預設項目、暫時使用 Proxy、中斷後重新連線，再開啟相同目標。如果恢復正常，再逐項恢復 Config 與自動連線。若仍然失敗，保留「基礎網路可用、其他伺服器可用、該伺服器在兩種網路下都逾時」這項結論，比一味延長逾時等待更有診斷價值。單純延長等待時間只會改變錯誤出現的時間，無法修正無法連線的位址、錯誤連接埠或不相符的傳輸參數。

訂閱更新失敗：分辨下載與解析問題

訂閱更新至少包含兩個步驟：先取得遠端內容，再將內容解析為伺服器項目。無法連線至訂閱網址、驗證失效與內容格式不相符，應分別處理。開始前請保留目前可用的項目與設定，記下錯誤原文、原有項目是否仍在，以及失敗發生於手動更新還是自動更新。不要為了重試而先刪除整份訂閱；遠端暫時無法連線時，刪除本機內容反而會失去最後一個可用的連線條件。

核對連結完整性與取得條件

訂閱網址應向自己的服務提供者取得，並確認這是供用戶端匯入的網址，而非登入頁面、說明頁面或帳戶中心網址。複製時請核對開頭、路徑與查詢參數，避免只複製畫面上可見的一部分。訂閱權杖可用於存取內容，不應貼入搜尋欄、公開筆記或公開截圖。網址換行顯示不一定有問題，但複製時加入實際空格、漏掉參數或連標點一起複製，都可能導致失敗。

若取得的是登入頁、存取確認頁或一般網頁，表示收到的內容並非預期的訂閱內容。此時應核對服務提供者給的匯入方式與帳戶狀態，而不是在 Shadowrocket 中反覆切換協定。若顯示驗證錯誤，也請先確認連結是否已重設或失效；用戶端無法替遠端服務還原已撤銷的權杖。如需聯絡服務提供者，提供錯誤狀態與發生的大致時間即可，避免將完整存取網址貼到公開討論區。

確認更新是否需要目前的連線

某些訂閱網址無法透過目前的基礎網路直接存取，但可透過使用者已有的有效連線取得內容。請比較中斷連線與連線後的更新結果，並記下當時使用的預設伺服器。若只有連線後才能更新，問題在於訂閱的下載路徑；若只有中斷連線後才能更新，則可能是代理路徑或其解析方式影響下載。不要據此推論所有訂閱都必須使用相同方式，應以該網址在目前網路下的實際狀況為準。

遇到循環依賴時尤其要謹慎：遠端訂閱暫時無法取得，而本機所有項目都已失效時，反覆點選更新不會產生新的可用資訊。應以自己已有的伺服器資料還原明確有效的項目，或向原服務提供者確認存取條件。Shadowrocket 用來使用既有資訊，不提供線路。設定更新策略前，先確認手動更新可正常運作，再檢查自動更新的觸發條件；自動更新失敗不代表訂閱內容整體損毀。

下載成功但清單不正確時，檢查格式

若已取得內容，卻顯示無法解析、項目清單為空或協定欄位缺漏，請確認訂閱格式是否符合匯入入口。伺服器訂閱與 .conf 設定檔用途不同；前者主要提供伺服器資料，後者還可能包含路由、DNS 與其他設定。不要將兩者視為可互換，也不要只因副檔名相似就選錯入口。手動檢視內容時請留意其中可能含有驗證資訊；必要時只檢查結構，不要將完整內容複製到外部工具。

更新後項目數量或名稱改變，不一定表示故障，遠端內容可能已調整。請先確認新清單中是否有需要的項目，再檢查預設伺服器與自訂策略群組是否仍有效。若規則引用的名稱已不存在，可能會出現更新成功卻無法上網的情況；此時請改查路由問題，而不是繼續重複下載。先記下更新前後的差異，再修復有效引用，避免將先後發生的兩個問題誤認為同一個錯誤。

修復完成後，保留一份可復原的設定檔，並妥善記錄自己的訂閱來源說明。備份應存放於受保護的位置，避免與公開文件混放。若曾公開完整訂閱網址，請聯絡原服務提供者處理權杖變更，再更新用戶端中的網址；只刪除公開截圖，無法確保舊憑證失效。完整匯入流程請見使用教學；本章僅處理下載、解析與引用之間的故障。

速度慢與間歇性中斷：先建立可比較的條件

速度慢可能是首次開啟等待時間長、持續下載速度低、影片反覆緩衝，或切換網路時短暫中斷。這些情況並不相同，請先描述具體狀況，再選擇測試方式。Connectivity Test 的延遲不能直接代表大型檔案的傳輸速度；網頁開啟快速，也不保證長連線穩定。建議固定一個可合法存取的測試目標，在相近條件下比較；不要混用不同時間、網站與網路的結果來判斷伺服器優劣。

分別檢查本機網路、伺服器與目標網站

中斷連線後，先觀察目前 Wi-Fi 或行動網路是否也明顯卡頓。Wi-Fi 訊號格數只反映部分無線狀態，不能代表上傳頻寬、壅塞與封包遺失都正常。可移近無線基地台並暫停其他裝置的大量傳輸，再以相同目標複測。若直連已經很慢，應先處理本機網路；此時切換代理協定或修改規則，通常無法解決無線干擾、基礎頻寬不足或尚未完成網路登入的問題。

確認基礎網路正常後，維持網路與目標不變，只切換到使用者已有的另一台有效伺服器。若只有一台伺服器速度慢，應優先檢查該伺服器路徑、負載或服務端限制；若所有伺服器連線至同一目標都很慢，問題可能在目標本身或共同路徑。向自己的服務提供者回報時，說明網路類型、目標類別，以及是否只有單一入口異常即可，不必提供完整驗證資訊。不要一次進行大量並行測試，測試本身也會占用頻寬並影響結果。

分辨解析等待、交握等待與持續傳輸

首次開啟很慢、第二次明顯變快，可能與 DNS 快取、連線重用或目標快取有關，不能立即判定為頻寬問題。觀察延遲主要發生在開啟前，還是頁面開始載入後。若多個新網域都在載入初期停頓，應檢查 DNS；若名稱解析後仍等待很久，則應檢查伺服器連線建立與 TLS。若載入開始很快但持續傳輸緩慢，才較適合檢查壅塞、服務端傳輸能力與目標限制。

比較 Config 與 Proxy 也有助於定位。在 Proxy 下正常、Config 下特定目標變慢，可能是規則將請求導向不同路徑，或自訂策略群組選用了另一個項目。請查看目前使用的檔案與策略引用，不要只確認預設伺服器名稱相同。若目標命中 DIRECT 規則，清單中選取的代理伺服器未必會用於該次請求。比較時請重新發出請求，避免既有長連線仍沿用先前路徑而造成誤判。

處理網路切換與長連線中斷

從 Wi-Fi 切換至行動數據時，裝置位址與網路路徑可能改變，既有長連線不一定能繼續使用。請分開判斷短暫恢復過程與持續無法重新連線的狀況。若切換後新網頁可開啟、舊連線仍卡住，可先重新建立該連線；若所有請求都停止，再中斷並重新連線 Shadowrocket。記錄每次切換網路是否都會重現問題，並檢查 On Demand 條件是否在兩種網路之間反覆觸發。

若只有即時通訊、遊戲或其他特定服務中斷，請檢查該服務是否依賴 UDP，以及伺服器、協定與目前網路是否符合相關條件。不要因為網頁瀏覽正常就排除傳輸差異，也不要任意修改 MTU 或其他底層參數。確有依據需要調整時，先記下原值，每次只改一項，再以相同服務複測；若無法確認有改善，請恢復原值，避免留下影響其他情境的長期副作用。

測試最後應整理成一句明確結論，例如「同一 Wi-Fi、同一目標下，只有伺服器 A 的持續傳輸異常」，或「新網域首次造訪等待較久，但建立連線後速度正常」。這類結論能直接指出下一步。只記錄最快的一次數值意義有限，也應觀察多次測試是否穩定、是否伴隨重新連線，以及是否受背景工作影響。測試完成後請關閉暫時啟用的探測，並恢復原本的 Config，避免診斷流量持續影響日常使用。

DNS 問題：從解析與連線的界線判斷

DNS 會將網域名稱轉換為連線所需的位址。伺服器本身可能使用網域名稱，目標網站也可能使用網域名稱，因此解析失敗可能導致代理伺服器無法連線，也可能只影響部分網站。常見狀況包括新網域無法開啟、既有連線仍可使用，以及同一伺服器在不同網路下結果不同。瀏覽器錯誤提示可作為線索，但不能只憑「無法開啟」就認定是 DNS 問題；應先排除基礎網路與伺服器連接埠無法連線的情況。

先建立明確的解析基準

修改前先儲存目前設定，並記下 [General] 中與 DNS 有關的原始設定。以下範例以系統解析作為診斷起點，不代表適用於所有網路，也不保證符合每個網域的需求。先確認系統解析在目前網路下是否正常，再決定是否繼續使用。不要同時加入多組未確認的解析設定；設定越複雜，就越難判斷請求實際經過哪一條路徑，以及錯誤來自解析器本身或連往解析器的連線。

[General]
bypass-system = true
dns-server = system

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
FINAL,PROXY

若原設定還包含遠端解析、加密解析或特殊網域處理，還原時請留意這些設定之間的相依性。只改一行未必能真正回復基準，因為其他段落可能仍會影響結果。對不熟悉的選項，請先複製檔案並另建測試設定，再逐項刪除或還原。設定檔結構可參考.conf 檔案分段說明；不了解作用範圍時，不要直接拼接多個來源的片段。

不要只用瀏覽器直接開啟 IP 作為判斷依據

HTTPS 網站通常需要正確的網域名稱、憑證名稱與請求資訊。直接在瀏覽器輸入 IP，即使無法開啟，也不能單獨證明 DNS 正常或異常；即使某個 IP 可以開啟，也不代表原網域解析一定正確。較妥善的方式是搭配 App 中可查看的請求或診斷資訊，分辨名稱解析錯誤與連線建立錯誤，並交叉檢查多個目標。操作時請留意記錄檔可能包含存取網域，分享前視需要遮蔽。

同一網域可能會回傳多個 IPv4 或 IPv6 位址，不同網路也可能取得不同結果。若只有某種網路持續失敗，請記錄實際使用的位址類型與連線結果，再檢查相應路徑。不要看到 IPv6 就直接認定是原因，也不要將全域停用某類位址當成固定步驟。診斷性調整應有比較結果與還原記錄；若只有單一目標的某個位址無法連線，應優先處理局部路徑，而非改變所有請求的行為。

檢查 Host 覆寫、規則與快取影響

[Host] 中的靜態對應可能使特定網域持續使用舊位址，即使外部 DNS 已更新也不會自動跟隨。若只有少數固定網域異常，請檢查是否有相關對應，並確認其來源與用途。不要為了繞過一次故障就任意加入永久 IP 對應；目標位址可能改變，憑證與服務路由也可能受到影響。暫時移除對應前請先備份，複測確認改善後再決定是否永久調整。

規則也會改變解析後的連線路徑。DOMAIN 類規則依網域比對，GEOIP 與 IP-CIDR 類規則則依位址相關資訊判斷，兩者的命中條件不同。若網域解析到非預期的位址範圍，後續策略也可能改變。因此應同時檢查「解析到什麼位址」與「最後採用哪個策略」。不要只因存在一條 GEOIP 規則，就推斷所有目標都會以相同方式分流；更不要用寬泛規則掩蓋尚未釐清的解析問題。

調整後應發出新的請求進行驗證，既有連線或快取可能暫時沿用舊結果。可重新連線、重新開啟測試頁面，並比較一個先前未造訪的網域；不必每次都重設整台裝置的網路設定。確認新請求穩定後，再恢復必要的自訂 DNS 選項。最後保留數量最少且用途明確的設定，並記下每項設定解決的問題，避免下次移轉設定時一併帶入已失效的歷史修補。

耗電與 On Demand：檢查持續活動的來源

系統電池用量顯示 Shadowrocket 有活動，不一定代表 App 持續執行異常工作。代理連線期間，其他 App 產生的網路流量也需要經過相應處理，因此應一併考量使用時間、流量大小、網路訊號與連線是否反覆重建。先記下耗電發生於待機、播放影片、傳輸檔案或切換網路期間，再與相近條件比較。不同日期的使用情境差異很大，單看電池占比無法直接計算 App 增加的耗電量。

先檢查重新連線、探測與高流量工作

若裝置在訊號微弱的網路中頻繁重新連線，連線建立、重新解析與工作階段復原可能反覆發生。先觀察連線是否穩定，再考慮最佳化規則。比較時選擇訊號穩定的網路，使用同一台既有伺服器，暫停非必要下載與雲端同步，並關閉診斷期間啟用的連續探測。不要為了觀察耗電而同時執行大量速度測試；測試會產生實際流量，反過來改變觀察條件，因此結果無法代表日常待機狀況。

持續記錄日誌、頻繁進行連線測試，以及大量失敗重試，也值得檢查。若先前為排錯而提高記錄頻率，定位完成後應恢復日常設定，並妥善處理含有敏感內容的記錄。觀察是否有某個 App 在背景持續請求失敗的網域，或某項同步工作因連線不穩而反覆上傳。此時應先修復相應的網路問題，而不是簡單歸咎於代理開關。只有將請求來源與活動時間對照，才能判斷應調整哪個環節。

On Demand 與手動開關的關係

On Demand 會依條件觸發連線行為。若手動關閉後很快又自動開啟，應先檢查是否仍符合觸發條件，不要直接認定開關故障。記下目前規則涉及的網路條件，以及裝置是否正處於頻繁切換網路的狀態。為了比較，可暫時關閉 On Demand，維持其他設定不變，觀察手動連線是否穩定。測試後請視需要恢復，避免排錯結束後忘記自動連線已停用。

需要重新設定條件時，請從簡單且容易判斷的規則開始，確認它會在目標網路觸發、在非目標條件下不觸發，再加入其他條件。規則彼此重疊時，使用者的預期可能與系統實際判斷不同。不要同時調整網路名稱、觸發行為與伺服器選擇，否則無法確認是哪一項帶來改善。若裝置由學校或公司管理，也應確認管理政策，避免將系統強制行為與個人 On Demand 設定混為一談。

進行一次可重現的耗電比較

選擇相近的觀察時段，盡量維持螢幕使用時間、網路類型、伺服器與背景工作一致，分別記錄連線穩定性、是否發熱，以及系統顯示的活動情況。比較重點是相同模式是否反覆出現，而不是追求適用於所有裝置的百分比。若只有某個伺服器導致頻繁重新連線，請依伺服器逾時章節處理；若只在切換 Wi-Fi 時發生，則檢查網路切換與自動連線，不必先更換所有設定。

規則過於寬泛，可能使原本可直接完成的請求也經過遠端路徑，但調整前必須先了解原有用途。可檢查常用服務的命中情況並修正明顯錯誤的分流，不要為了降低流量就任意將所有請求改為 DIRECT。對有隱私或存取路徑需求的服務，應維持符合自身需求的策略。效能調整的目標是減少無意義的重試與錯誤路徑，而不是犧牲正確性，換取暫時好看的統計數字。

若中斷連線後仍持續明顯發熱或耗電，問題可能與系統更新工作、其他 App 活動或電池狀態有關，應回到系統層繼續檢查。Shadowrocket 開關與耗電同時出現，不能單獨證明兩者存在因果關係。反之，若在網路穩定、流量低且關閉診斷探測的條件下，仍可重複重現異常，請保留發生條件與去除敏感資訊的記錄，再依最後一章回復設定。一次可重現的比較，比多次沒有記錄的重新安裝更有價值。

更新後異常與 iPad：保留基準再逐步復原

「更新後開始出問題」描述的是發生順序，不一定代表更新本身就是原因。同一期間也可能發生訂閱更新、系統升級、預設伺服器變更或網路切換。先列出實際變更，保留目前設定與錯誤原文，再以最精簡設定複測。沒有備份時不要直接刪除 App：本機伺服器、設定與個人化選項可能因此遺失，重新安裝後也未必能復原。復原流程應從可逆操作開始，最後才考慮重新安裝。

分開檢查 App、系統與設定變更

先確認基礎網路正常，重新選取一台已知有效的伺服器，暫時使用 Proxy 並發出實際請求。若最精簡條件可正常運作，再逐項恢復 Config、自訂策略、DNS 與 On Demand；哪個步驟恢復後再次出現異常，就優先檢查該項。若最精簡條件仍無法運作，則依本頁前面的授權、逾時與 DNS 分支繼續排查。不要立刻整份套用舊設定，否則尚未查明的問題可能再次出現。

iPhone / iPad 版 App 更新請在 App Store 中處理，系統需求以 App Store 頁面標示為準。需要重新取得時，請確認開發者為 Shadow Launch Technology Limited、官方圖示與 App ID 932747118。iPhone / iPad 版在 App Store 一次性付費 $2.99；Mac / Windows / Android / Linux 版免費。已購項目的復原方式與各平台下載方法請見已購項目復原說明；請分別確認購買狀態與本機設定備份。

桌面版與 Android 版復原時的系統允許設定

Mac、Windows、Android 與 Linux 需要重新取得安裝檔時，請前往全平台下載頁選擇裝置；安裝檔由本站的 /dl/shadowrocket/ 路徑提供。Mac 使用者應先在「關於這台 Mac」確認晶片類型，區分 Apple 晶片與 Intel，不要依外觀判斷。重新取得前請保留原有設定，並確認下載來源與目標檔案後再操作；尚未完成參數排查前，不要把更換安裝檔當成修復伺服器問題的方法。

這些平台的安裝檔沒有程式碼簽署，首次開啟時可能會遭系統阻擋。Windows 顯示 SmartScreen 時，確認檔案來自本站後，選擇「更多資訊 → 仍要執行」；Mac 可在「隱私權與安全性」中選擇對該 App「仍要打開」。Android 只需允許實際用於安裝的 App「安裝未知的應用程式」，完成後即可收回權限。Linux AppImage 需要執行權限。更完整的提示與指令請見安裝允許設定表；不要為了處理單一檔案的提示而全域關閉系統防護。

iPad 橫向畫面、購買狀態與設定移轉

iPad 橫向分欄畫面可能同時顯示清單與詳細資料。請先確認目前編輯的項目與預設伺服器是否一致：開啟某個項目的詳細資料，不代表它已被選為預設伺服器。切換直向與橫向畫面後，仍應以 Home 中實際選取的項目與連線狀態為準，不要依據詳細資料停留在哪個項目來推斷連線對象。若版面變更後找不到操作入口，可先返回清單，再依快速入門流程逐項確認。

若已在 iPhone 購買，請在 iPad 使用原購買時所用的 Apple ID，檢查 App Store 的已購項目。復原 App 購買不等於自動移轉所有伺服器與 .conf 檔案；兩台裝置能否連線，應分別檢查既有訂閱、預設伺服器、路由模式與系統授權。不要因另一台裝置正常，就略過本機的授權與網路排查。移轉時先匯入必要內容並測試連線，再恢復附加設定，避免一次帶入太多未知差異。

若 iPad 與 iPhone 在同一 Wi-Fi 下結果不同，先比較兩台裝置實際使用的設定與解析選項，再檢查是否啟用行動數據、不同的自動連線條件或系統管理政策。確認設定一致後，以相同目標和同一台伺服器複測。移轉檔案與 QR Code 都可能含有憑證，請使用受保護的個人傳輸方式，完成後清除暫存副本。版面與購買細節可繼續參閱iPad 使用與設定移轉說明。