Shadowrocket疑難排解大全

連線開關無法開啟與 VPN 設定權限

開關剛開啟就回到關閉狀態時，請先檢查系統是否允許建立 VPN 設定，而不是立刻更換訂閱。伺服器無法連線通常發生在連線建立後的請求階段；如果系統尚未核准設定，即使伺服器參數正確，也無法正常轉送流量。先中斷連線，確認裝置本身可以瀏覽一般網頁，再重新開啟開關，留意是否出現系統授權、身分驗證或管理限制提示，並記下完整訊息。

首次授權與誤按拒絕後的處理方式

在 iPhone 或 iPad 上，首次啟動連線時可能會出現新增 VPN 設定的系統提示。確認提示是在剛開啟 Shadowrocket 後出現，再允許新增，並依系統要求完成裝置身分驗證。允許新增只代表系統同意建立網路延伸功能設定，不表示訂閱有效，也不保證伺服器在線。若先前按了拒絕，請返回 App 再試一次；如果不再出現提示，請到系統設定中的 VPN 管理位置，確認是否已有對應設定。

系統設定的選單層級可能隨系統版本調整，可使用設定搜尋 VPN。確認設定名稱與所屬 App，避免把其他用途的設定誤認為 Shadowrocket。若對應項目已損毀或重複，請先儲存 App 內的設定並中斷連線，再移除確認屬於 Shadowrocket 的失效項目，返回 App 重新授權。不要一併刪除由學校、公司或裝置管理機制安裝的設定；這類項目可能受管理政策控制，應先確認裝置使用權限。

開關自動關閉、自動重新連線與設定衝突

如果完成授權後開關仍立即關閉，請檢查是否有其他 VPN 連線正在接管網路，包括具有 VPN 介面的網路過濾工具。暫時停止其他連線後再測試，先不要同時變更 DNS 與規則。若開關關閉後又自行開啟，請優先檢查 On Demand 與系統中相應的隨選連線設定；這可能是連線觸發條件與手動操作重疊所致，不能只憑開關變化就判定 App 當機。

受管理的裝置可能禁止新增 VPN 或修改網路延伸功能。此時反覆重新安裝無法解除政策，還可能遺失現有設定。先查看系統是否顯示管理描述檔，再請裝置管理員確認限制提示。一般個人裝置則可在儲存設定後重新啟動一次，排除網路延伸功能暫時未釋放的狀況。重新啟動後，先用最精簡的設定和一個既有伺服器測試，確認開關維持開啟，再恢復 On Demand 等自動化條件。

分辨權限問題與 App 閃退

App 切換至背景不代表連線已停止，應以系統 VPN 狀態和實際請求為準；但如果開啟特定設定就閃退，請另外保留該設定的副本，檢查近期新增的規則、外部資源與異常冗長的設定內容。不要反覆匯入同一個檔案，造成更多副本。可以先選用先前正常的設定重新測試：舊設定正常而新設定異常，表示應繼續比對設定差異，不必先處理帳號或訂閱效期。

桌面版與 Android 遇到首次啟動遭封鎖時，請先依下載頁的安裝允許說明完成系統確認，再回頭診斷連線。Mac 可在「隱私權與安全性」查看「仍要打開」；Windows 在確認安裝檔來源後，可查看 SmartScreen 的更多資訊；Android 則需允許實際執行安裝的 App 安裝未知的應用程式。安裝階段無法啟動與連線階段無法上網是兩種不同問題，應分別記錄，避免把允許安裝誤當成網路修復。

顯示已連線卻無法上網：先分辨分流模式

系統顯示 VPN 已連線，只代表網路延伸功能正在運作，不能證明所有請求都成功抵達目標。若所有網頁都無法開啟，先關閉 Shadowrocket，使用相同網路瀏覽先前可以直接連線的頁面。關閉後仍無法上網，應先處理 Wi-Fi、行動數據、網路登入驗證或系統時間；關閉後恢復正常，則針對所選伺服器、Global Routing 與 DNS 進行比對。每次測試都使用相同目標，避免受到網站本身變化影響。

用三種模式進行比對

Global Routing 的 Config 會依目前設定處理流量；Proxy 用來將適用的請求交由代理路徑處理；Direct 則用於直接連線比對。排查時可暫時切換，但應先記下原本的模式與所選設定。若 Proxy 正常而 Config 失敗，優先檢查規則命中、策略指向與設定資源；若 Proxy 失敗而 Direct 正常，優先檢查伺服器或代理路徑；若兩者都失敗，則應回頭檢查基礎網路、DNS 與目標服務。

以上結果只能提供排查線索，並非絕對證明。某些目標本身無法透過目前的直接連線路徑存取，此時 Direct 失敗就沒有比較意義；App 也可能沿用已建立的連線，使剛切換模式後的請求仍走舊路徑。切換後請關閉目標 App 中的舊頁面，再發出新的請求；必要時中斷並重新連線 Shadowrocket。不要只重新整理一個開啟很久的頁面就下結論，也不要用 VPN 圖示取代實際連線測試。

檢查規則順序與最終策略

在 Config 中確認目前實際選取的檔案，而不只是查看檔案列表裡剛匯入的名稱。規則通常依序比對，較廣泛的條目若排在前面，可能會先命中；最後的 FINAL 則決定先前未命中的請求要如何處理。以下是語法範例，不是可直接取代現有設定的完整檔案。範例網域僅供說明；修改前請先確認設定中的 PROXY 與 DIRECT 分別代表什麼處理方式。

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

若只有特定網站無法使用，請檢查是否有針對該網站的 DOMAIN、DOMAIN-SUFFIX 或 REJECT 條目，並查看該請求實際命中的規則。網站可能會呼叫多個不同網域的登入、圖片與 API 服務，首頁能開啟不代表所有相依服務都套用了正確策略。先從失敗請求的網域查起，不要直接刪除整份規則檔。若命中的策略引用了不存在的策略名稱或無法使用的伺服器，請修正引用關係後再測試。

有明確依據時才修改設定

保留一份原始設定，再建立只包含必要規則的測試副本，使用同一個既有伺服器進行比較。測試副本恢復正常，問題較可能出在複雜規則、資源引用或附加設定；兩份都失敗，則應回頭檢查伺服器與 DNS 解析。不要同時更換設定、訂閱與系統網路設定，否則即使恢復正常，也無法確認原因。若要了解三種模式的適用情境，請參閱Global Routing 三種模式說明。

修復後切回日常使用的 Config，並再次測試先前失敗的頁面、一般直接連線頁面與常用 App。暫時切換 Proxy 測試成功，不代表分流問題已修好。記錄最後修改的是哪一條規則、哪個策略或哪項解析設定，再移除測試用的暫時條目。保留這組最精簡的重現步驟，下次遇到相同症狀時就能直接比對，不必重新猜測整份設定。

伺服器逾時與協定參數不符

伺服器逾時應拆成「位址解析、連接埠連線、協定交握、目標請求」四個階段判斷。Connectivity Test 沒有回傳結果，不一定代表伺服器完全離線；測試目標無法連線、測試方式不適用或協定交握失敗，都可能出現類似情況。先記下是單一伺服器還是整組伺服器失敗，以及是否只在特定網路發生。伺服器資訊應以向你的服務商取得的最新資料為準，不要只憑名稱推斷協定。

先確認位址與連接埠是否可連線

在伺服器詳細資訊中確認位址沒有混入空格、換行或協定前綴，並確認連接埠與伺服器端一致。位址欄通常應填入主機名稱或 IP，不要直接貼上完整網頁網址。使用網域名稱時，先確認能否正常解析；使用 IP 時，仍可能需要另外填寫 TLS 使用的伺服器名稱。若只有特定 Wi-Fi 連線失敗，而行動網路正常，請檢查該網路的登入驗證、UDP 條件或出口限制，不要立刻重設所有伺服器。

整組伺服器都逾時時，也應檢查它們是否來自同一個網域、同一份訂閱或同一個網路出口。名稱看似不同的伺服器，實際上可能共用相同的基礎位址。先用已知先前可用的項目進行比對，再確認伺服器端是否正在維護、授權是否仍有效。不要無止盡地重複測試：同時進行大量探測會增加網路負擔，也可能觸發伺服器端限制。等上一輪測試完成，保留少數具代表性的項目，通常更容易看出規律。

逐一核對交握條件

連接埠可連線但實際請求失敗時，請優先檢查身分驗證、加密方式與傳輸設定。Shadowsocks 的加密方式與密碼必須相符；VMess、VLESS 的使用者識別碼與傳輸設定須與伺服器端一致；Trojan 則要核對密碼與 TLS 條件。不要只因伺服器位址相同就沿用舊欄位。訂閱更新可能改變傳輸方式，而手動建立的項目不會自動套用這些變更，應逐項比對最新資料。

出現憑證錯誤時，先檢查裝置日期、時間與時區，再核對伺服器名稱是否與憑證相符。不要把略過憑證驗證當成一般修復方式；這會降低連線身分驗證的安全性，也無法解決位址錯誤或伺服器憑證過期問題。WebSocket 情境還應區分連線位址、Host 與路徑各自的用途；即使某個欄位看似重複，也不要任意刪除。錯誤訊息中的交握、驗證或憑證提示，比籠統的逾時結果更有診斷價值。

交叉比對測試結果與實際連線

延遲測試只能反映特定測試方式下的回應，不代表網頁載入、持續下載與影片播放都正常。若測試失敗但實際連線正常，先檢查測試目標與方式；若測試正常但網頁無法使用，則繼續檢查 DNS、規則與目標服務。使用同一網路、同一目標與同一設定比較多個既有伺服器，才能縮小變因。伺服器選擇方式請參閱延遲測試、地區與協定類型說明。

需要向服務商回報時，請提供協定類型、失敗時使用的網路、錯誤發生的大致時間、是否所有伺服器都受影響，以及已遮蔽敏感資訊的錯誤內容。不要傳送完整訂閱連結、使用者識別碼、密碼或私鑰。用戶端可以檢查欄位是否一致與問題範圍，但無法取代伺服器端記錄；若不同網路都在相同交握階段失敗，應請伺服器端確認驗證、監聽連接埠與憑證，而不是持續修改本機無關參數。

Subscribe 更新失敗、清單空白與重複項目

Subscribe 取得失敗與訂閱中的伺服器無法使用，是兩種不同問題。前者發生在下載、授權或解析訂閱內容時；後者則發生在已匯入項目的連線階段。先保留舊清單，記下更新時的完整錯誤訊息，再確認是無法連線至訂閱網址、回應狀態異常，還是內容無法解析。不要因為一次更新失敗就刪除仍可使用的舊項目；刪除後重新新增，可能連原本可供比對的設定差異也一併遺失。

檢查連結完整性與連線路徑

訂閱連結請向你的服務商取得，複製時須包含完整查詢參數。聊天 App 自動換行、末尾標點、前後空格，或把字元實體當成原始符號貼上，都會改變連結。範例中的 token 僅用來說明格式，不能用於實際更新。不要在公開截圖、問題標題或瀏覽器分享記錄中顯示真實連結；連結通常含有可讀取你個人伺服器清單的授權資訊。

https://example.com/sub?token=xxxx

若錯誤與主機名稱解析、TLS 或逾時有關，先中斷連線，確認基礎網路可用並檢查裝置時間。接著確認目前的更新請求是否依賴已失效的代理路徑；如果只有開啟代理時更新失敗，請先記下原設定，再暫時改用可用的網路路徑重試。不要假設訂閱更新一定會依循某種 Global Routing 行為，應以目前設定、請求記錄與實際測試結果為準。

分辨授權失敗與內容格式錯誤

回傳未授權、禁止存取或網址不存在時，先根據服務商提供的資訊確認連結是否已撤銷、重設或過期。反覆重新整理無法修復失效的授權。若回傳的是登入頁面、網路驗證頁面或錯誤文字，即使網路請求成功，也不是用戶端可直接匯入的伺服器資料。公共 Wi-Fi 尚未完成驗證時尤其容易發生這種情況，請先在中斷連線的狀態下完成網路登入，再重新取得訂閱。

請求完成但匯入後清單為空時，檢查來源提供的格式是否適用於目前的匯入方式。Subscribe、單一伺服器連結、QR Code 與 Config 檔案用途不同，不應互相取代。不要只憑副檔名判斷內容，也不要把網頁說明頁網址當成訂閱網址。若資料包含多種格式，請依服務商標示選擇適用於 Shadowrocket 的內容；若缺少說明，先詢問格式，不要用同一個網址逐一嘗試所有匯入方式。

處理更新後項目消失、重複與手動修改

更新後伺服器數量改變，可能是遠端清單調整、篩選條件變動或原項目遭取代，不能直接認定是用戶端誤刪。先查看 Subscribe 對應的群組，再確認是否將手動項目與訂閱項目混在同一個檢視畫面。訂閱管理的欄位可能在下次更新時被遠端內容覆蓋；若需保留個別修改，先確認管理方式，必要時建立名稱清楚的手動副本，並記下它不會再自動跟隨訂閱更新。

重複項目通常來自同一連結重複新增、不同訂閱包含相同伺服器，或手動副本與自動更新清單同時存在。清理前先核對各組的來源與更新時間記錄，不要只看顯示名稱就刪除。保留一個確認有效的 Subscribe 項目，再逐步移除重複來源。若新清單覆蓋舊參數後開始無法連線，可比對尚未刪除的副本，查看位址、連接埠、TLS 與傳輸欄位，再將明確差異交由服務商確認。

恢復正常後，建議避免不必要的手動連續重新整理，依實際需求更新，並保留最近一次有效設定的副本。準備重新匯入前，請先閱讀Subscribe 匯入步驟，確認使用正確入口與格式；QR Code 的來源則請參閱Scan QR Code 操作說明。若懷疑授權連結已外洩，請向你的服務商申請重設授權，再更新用戶端記錄，而不是只修改本機顯示名稱。

速度慢、網頁卡頓與連線中斷

排查速度慢之前，先釐清「慢」指的是哪種情況：首次開啟等待很久、圖片持續載入緩慢、大型檔案傳輸速率偏低，還是使用一段時間後中斷。這些情況可能分別與 DNS、交握、持續頻寬、封包遺失或網路切換有關。記下發生時使用的網路、目標、所選伺服器與其他下載活動，再與關閉 Shadowrocket 時的相同操作比較。不要用單次延遲數值推斷整條連線的吞吐量，也不要把目標網站限速當成用戶端效能問題。

建立可重複的測試條件

優先選擇平常穩定使用的目標，在相同地點與網路中重複測試。測試時暫停系統更新、雲端同步與其他大量傳輸工作，避免把頻寬競爭誤認為代理造成的損失。Wi-Fi 訊號格數不完全代表傳輸品質；無線環境壅塞、路由器負載過高或上傳頻寬占滿，都可能造成等待。先比較靠近路由器與原位置的狀況，再比較 Wi-Fi 與行動網路，有助於區分區域網路因素與遠端連線因素。

比較多個既有伺服器時，盡可能維持相同目標、協定使用方式與測試時段。伺服器名稱中的地理位置不能直接反映路徑長短，延遲低也不代表尖峰時段有足夠可用頻寬。至少觀察首次回應與持續傳輸兩個階段：前者慢而後者穩定，適合檢查解析與交握；前者快但後續持續停頓，則應留意封包遺失、伺服器負載或目標限制。測試結果只適用於當下條件，不宜據此製作固定排名。

檢查分流與連線重用造成的誤判

網頁的不同資源可能命中不同規則，其中一組請求失敗就可能拖慢整個頁面。先檢查卡住的網域，不要只測試首頁網域。Config 失敗但暫時切換 Proxy 後正常，請回頭檢查規則與策略；兩者都慢，再比較伺服器與基礎網路。切換伺服器後，已存在的長連線可能仍沿用原本路徑，因此應關閉相關連線並重新發出請求。只有新連線的結果，才適合用來判斷切換是否生效。

若問題表現為通話、遊戲或其他即時 App 中斷，請另外確認該 App 是否需要 UDP，以及目前協定與網路是否允許相關流量。網頁能開啟不代表 UDP 正常；使用 UDP 的協定也可能無法在特定 Wi-Fi 上建立連線。不要隨意修改 MTU 或傳輸參數，先確認問題只發生在特定類型的封包或某種網路。確實需要調整時，應以伺服器端建議為依據，保留原始值並逐項重新測試，避免一個問題變成多個問題。

透過 Data 與請求記錄縮小範圍

查看 Data 時，先確認統計範圍、時間區間與目前連線狀態。某個伺服器的流量增加，表示有資料經由該項目處理，但不能證明目標內容已全部載入。依 App 觀察時，也要考慮系統服務、背景重新整理與快取；從快取開啟頁面也不能用來測試實際速度。可以先記下基準數值，執行一次明確的請求，再確認流量增量與請求記錄是否相符。讀數詳細說明請參閱Data 頁面流量統計說明。

若連線只有在螢幕關閉、離開 Wi-Fi 或切換至行動網路後才中斷，請先將它記錄為網路切換問題。重新連線後若立即恢復，請檢查 On Demand 條件與原有連線是否已失效，不要接著更換所有伺服器。行動環境中網路位址變動很常見，有些長連線需要重新建立；與其看舊連線能否維持，不如確認是否能成功發出新的請求。也可在固定環境中重新測試，排除移動造成的干擾。

確認問題後，移除測試時加入的暫時規則與特殊參數，恢復日常設定，再測試瀏覽、持續傳輸與網路切換三種情境。不要長期保留多組彼此重疊的「最佳化」設定；額外設定本身也會提高排查成本。能明確說明哪項修改解決了哪種症狀，才算留下可重複使用的修復記錄，而不是只在某次測試中偶然變快。

DNS 解析失敗與規則命中異常

DNS 問題常見症狀包括網域無法開啟、首次造訪等待很久、部分資源載入失敗，或同一網站在不同網路上的結果不同。排查重點是解析是否完成、回傳位址是否可連線，以及解析請求走了哪條路徑。不要把「網域連不上、直接輸入 IP 卻可以」當成唯一判斷依據，因為 HTTPS 憑證、虛擬主機與網站路由常仰賴網域名稱，直接連線至 IP 可能取得完全不同的服務，無法作為可靠比對。

分辨解析逾時與解析後連線失敗

先查看請求記錄中的錯誤階段。若尚未取得位址就逾時，請檢查 DNS 伺服器是否可連線及請求使用的路徑；若已取得位址但連線失敗，則應檢查目標連線、規則或 IPv6 路徑。多個不同網域同時異常時，應優先檢查 DNS 解析路徑；只有單一網域異常時，也要考慮該網域本身的記錄、憑證或服務狀態。記下失敗的完整主機名稱，避免把 API 子網域與首頁網域混為一談。

裝置可能同時受到系統 DNS、Wi-Fi 手動 DNS、App 內設定與其他網路過濾設定影響。先記下各層原始值，再確認目前實際生效的來源。不要同時在系統與 App 中連續更換多組位址，否則測試結果將難以判讀。使用加密 DNS 時，也要確認其主機名稱本身可以解析且 TLS 能夠建立；將一種解析協定換成另一種，不會自動排除裝置到解析伺服器之間的網路問題。

檢查 DNS 與分流是否互相依賴

有些設定需要先解析伺服器網域名稱才能建立代理，但又把解析請求安排到尚未建立的代理路徑上，可能形成依賴循環。若啟動階段就解析失敗，應檢查伺服器位址的解析路徑，而不只是網頁網域。比對先前正常的設定，確認哪些請求使用系統解析，哪些使用設定內的解析方式。修改時先恢復可啟動的最精簡路徑，待伺服器連線建立後，再逐步恢復其他 DNS 條件。

以網域為基礎的規則與以位址為基礎的規則，處理對象並不相同。DOMAIN-SUFFIX 可比對指定網域及其子網域；IP-CIDR、IP-CIDR6 與 GEOIP 則與位址有關。新增含有 no-resolve 的位址規則時，通常表示不會為了比對該規則而主動觸發網域解析，並不代表整個用戶端關閉 DNS。以下僅示範規則結構：文件保留位址與 example.com 都是教學素材，不代表你的區域網路範圍或實際業務需求。

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
IP-CIDR6,2001:db8::/32,DIRECT,no-resolve
FINAL,PROXY

IPv6、快取與區域網路範圍

網域同時回傳 IPv4 與 IPv6 時，兩種路徑的連線狀況可能不同。若只有特定網路會長時間等待，請檢查是否優先嘗試了無法使用的位址路徑。儲存原始設定後，可暫時調整相關 IPv6 選項進行比對，但不要因此就認定應永久停用 IPv6。測試時應確認新的請求是否恢復，並在其他網路重新驗證；否則可能只是暫時繞過某種網路問題，掩蓋設定與實際網路能力不符的情況。

修改 DNS 後，舊快取與已建立的連線可能仍然有效。請中斷並重新連線，再重新開啟目標請求；必要時重新啟動目標 App，不要反覆重新安裝 Shadowrocket 來清除快取。區域網路裝置名稱、印表機服務或公司內部網域可能依賴本機解析，全部改由遠端解析反而會造成失敗。應為確有需要的本機名稱與網路保留正確路徑，並只在可信任的網路中測試內部位址，避免在公開回報中揭露敏感名稱。

最終驗證應涵蓋一般網域、原先失敗的網域，以及必要的本機服務。確認規則命中與解析結果符合預期後，再移除暫時的比對設定。若能穩定重現「某個網路解析逾時，另一個網路正常」，請保留這組差異並回報給相關網路或伺服器維護人員；單獨一張網頁錯誤截圖，通常無法判斷問題出在解析、交握還是目標回應階段。

耗電異常、發熱與背景反覆連線

判斷耗電狀況時，應先看使用情境與觀察時段，不要只看系統電池清單中的百分比。VPN 相關處理也可能包含其他 App 經由網路延伸功能所產生的工作量；某項耗電占比上升，也可能只是同一時段其他 App 的耗電量下降。先記錄是否持續傳輸、是否處於訊號微弱的環境、裝置是否正在充電，以及問題從哪次設定變更後開始。系統剛更新、還原資料或執行雲端同步時，不宜立即將短暫發熱歸因於代理連線。

分辨持續運作與異常重試

在網路穩定、裝置溫度正常的條件下，分別觀察開啟連線但少量使用、持續下載，以及關閉連線的相同時段。盡量維持螢幕亮度、前景 App 與網路條件一致，才有意義進行比對。若只有大量傳輸時耗電增加，可能主要來自無線通訊與加密處理；若幾乎沒有主動操作卻持續發熱，則應檢查背景 App、連線重試、記錄寫入與自動更新工作，而不是先修改協定參數。

在請求記錄中尋找密集重複的失敗：同一主機持續逾時、訂閱反覆重新整理、伺服器驗證不斷失敗，都可能讓裝置持續重建連線。先修復最早出現的錯誤，後續重試通常也會減少。不要把縮短所有逾時時間當成省電方法；等待時間過短反而可能造成更多重新連線。也不要頻繁手動執行整組 Connectivity Test；大量探測本身就是額外的網路活動，會影響耗電觀察。

檢查 On Demand 與網路切換

On Demand 設定應符合實際使用環境。Wi-Fi 訊號邊緣、行動網路切換或網路名稱條件設定不當，都可能讓連線反覆啟動與停止。先記下觸發條件，再暫時關閉自動觸發，改以手動連線一段時間作為比對。若耗電與頻繁重新連線同時減少，請逐項恢復條件，找出造成觸發循環的項目。不要只關閉 App 介面就認為背景連線已停止，應查看系統 VPN 狀態。

若裝置經常在兩個 Wi-Fi 網路之間移動，或休眠後重新連上網路，既有連線可能失效並重新建立。應先觀察重新連線後是否很快恢復穩定，不要把每次重新建立連線都視為異常。真正需要留意的是持續失敗、短時間內反覆切換，或裝置沒有網路活動時仍長時間運作。可在固定位置與單一網路中重新測試；固定環境正常、移動時才異常，應優先處理無線訊號涵蓋、網路切換與隨選條件。

降低排查期間的額外負擔

為排查而開啟的詳細記錄、長時間流量統計與大量測試，取得必要資訊後應恢復日常設定。保留少量能重現問題的記錄即可，不必持續累積所有請求。若設定中還有排程更新或其他週期性工作，請逐項檢查執行頻率與失敗重試狀況，先停用非必要項目進行比對。每次只變更一個工作，觀察相同情境下的溫度與電池變化，避免一次停用所有功能後，無法判斷真正原因。

不同協定、傳輸方式與網路品質都可能影響處理負擔，但不能不顧伺服器端條件任意切換。先確認使用的參數有效且連線穩定，再比較其他既有可用伺服器的表現。訊號微弱時反覆傳送、封包遺失後重傳，以及大量小型請求，都可能比協定名稱本身更影響耗電。不要追求缺乏使用情境的固定耗電數字；電池健康度、螢幕使用情況與環境溫度都會改變結果，應以同一裝置前後比對為主。

若關閉 Shadowrocket 後，同樣情境仍有異常，應繼續檢查系統電池記錄、背景同步與網路訊號，不要反覆重新匯入訂閱。若異常只在某份設定下發生，請保留原始檔案並以最精簡的測試設定重現，重點比對自動工作、連線觸發與失敗重試。修復後至少測試一次靜置與一次正常使用情境，確認沒有持續重新連線；系統電池統計有時間區間，修改後不會立即完整反映變化。

回報耗電問題時，請說明裝置類型、系統環境、使用的網路、連線時間與主要操作，並附上已遮蔽敏感資訊的失敗記錄。不要只提供一張電池耗電占比截圖，因為其中缺少網路使用量與觀察時段。也可記下 Data 的流量增量，讓協助排查的人分辨「傳輸大量資料」與「只有少量流量卻持續重試」這兩種情況，進而選擇不同的檢查方向。

更新後異常與 iPad 專項檢查

更新後發生問題，先確認變動來自用戶端、系統、設定還是訂閱，不要只因時間接近就認定兩者有因果關係。記下最後一次正常使用時的網路與設定，再於目前環境中重現問題。用戶端更新通常無法修復已失效的伺服器端授權；同樣地，訂閱恰好在更新後變更參數，也可能被誤認為是 App 更新造成。優先保留現有檔案、群組與必要截圖，再考慮還原或重新安裝，避免失去用來比對差異的資料。

依問題來源還原，不要先清除所有設定

iPhone / iPad 版透過 App Store 取得與更新，系統需求以 App Store 頁面標示為準。iPhone / iPad 版於 App Store 售價 $2.99，一次付費；Mac（Apple 晶片與 Intel）、Windows、Android、Linux 版免費，其他平台的安裝檔請從本站下載頁取得，並使用本站 /dl/ 路徑。用戶端一次買斷 ≠ 連線服務方案；重新取得用戶端不會自動恢復服務商已撤銷的訂閱授權。

確認 iPhone / iPad App 時，請核對開發者 Shadow Launch Technology Limited、官方圖示與 App ID 932747118。更換裝置或重新安裝後，請使用原購買帳號查找已購項目，詳細操作請參閱已購項目還原說明。還原 App 後仍須檢查訂閱、伺服器與 Config 是否完整；系統備份不能證明目前的設定都已還原，密碼、私鑰與授權資訊也不宜只儲存在單一裝置中。

更新後先進行三項基本檢查：系統基礎網路是否正常、VPN 設定是否仍獲授權，以及一個既有伺服器能否在精簡設定下正常運作。若舊設定失敗但精簡設定正常，請逐項恢復規則與外部資源；若所有設定都失敗，則回頭檢查權限、DNS 與伺服器參數。先不要重新儲存所有設定，無差別修改可能會覆蓋原始線索。確認 App 確實發生閃退時，請記錄觸發的操作，而不是只寫「更新後不能用」。

iPad 的 Wi-Fi、個人熱點與多視窗情境

僅支援 Wi-Fi 的 iPad，應先分辨路由器問題與代理問題；可使用另一個可用網路或個人熱點進行比對。支援行動網路的機型則分別測試 Wi-Fi 與行動網路。學校、公司與公共 Wi-Fi 可能需要網頁登入驗證，請先中斷連線並完成驗證，再開啟 Shadowrocket。iPhone 正常但 iPad 失敗時，不要直接認定是訂閱問題；兩台裝置可能使用不同 DNS、不同 Config 或不同系統 VPN 設定。

分割畫面或多視窗操作容易混淆「目前檢視的設定」與「目前生效的設定」。返回 Shadowrocket 確認選取的伺服器、Global Routing 與 Config，再重新開啟目標 App 發出請求。不要只根據兩台裝置上相同的顯示名稱進行比較；名稱相同的項目仍可能有不同的連接埠、TLS 或傳輸欄位。逐項核對實際參數，比清除整台裝置的設定後重試更容易找出問題，也能保留正常 App 的網路狀態。

使用外接鍵盤貼上訂閱或伺服器資訊時，請留意開頭與結尾的空格、智慧標點與換行；透過跨裝置剪貼簿傳送時，也要確認複製的是最新內容。使用 Scan QR Code 匯入後，應查看解析出的項目類型，不要因為掃描成功就省略欄位檢查。iPad 螢幕關閉後恢復使用，但頁面仍停留在舊狀態時，先重新發出請求，再判斷連線是否失效；舊頁面與長連線不能代表恢復後的實際網路狀態。

還原日常設定並完成問題記錄

若必須重新安裝，先儲存可安全還原的 Config 與伺服器資訊，並確認能向你的服務商重新取得訂閱連結。匯出的內容可能包含敏感參數，請存放在受控位置，不要透過公開檔案分享。電腦與 Android 重新取得安裝檔後若遇到系統封鎖，請依下載頁的安裝允許說明處理；Mac 的「仍要打開」、Windows 的「更多資訊」與 Android 的安裝權限只解決啟動問題，完成後仍須重新驗證連線與規則。

排查完成後，恢復日常使用的 Global Routing、On Demand 與必要規則，並移除暫時的 DNS 設定與測試項目。至少驗證原先失敗的操作、一般網路請求，以及螢幕關閉或網路切換後的新請求。最後記錄問題範圍、根本原因、實際修改與重新測試結果；若仍未解決，請帶著這些可重現資訊繼續回報，而不只是描述裝置型號。首次設定遺漏的步驟可回到快速入門教學逐項確認。