Shadowrocket 故障排除手冊

01 連線開關無法開啟：先檢查 VPN 設定授權

先區分三種情況：點選開關後出現系統授權提示；開關短暫開啟後又關閉；畫面顯示已開啟，但系統未能穩定建立連線。這三種情況分別可能是授權尚未完成、連線程序中止，或需要重新確認連線狀態。不要一概認定是「伺服器故障」。先中斷其他正在使用的 VPN 連線，回到 Shadowrocket 的 Home，確認已選取有效伺服器，再試一次並記下畫面上的原始提示。

出現授權提示時，完成系統確認

首次連線時，系統會要求允許新增 VPN 設定。此提示用於建立由系統管理的連線設定，不代表伺服器已確認可連線。閱讀提示中的 App 名稱，確認操作是由剛開啟的 Shadowrocket 發起，再依系統要求完成裝置驗證。若先前取消了提示，請回到 App 重新啟動連線；完成驗證前不要反覆切換其他設定，以免無法判斷問題發生在授權前還是授權後。

接著前往系統 Settings，在 VPN 相關頁面確認是否有對應設定。不同系統版本的入口名稱可能有所調整，可在 Settings 搜尋 VPN。設定存在只表示系統已儲存連線入口，無法證明目前伺服器可用。若找不到設定，請再次觸發授權；若裝置受組織管理或相關選項無法使用，應向裝置管理員確認限制，而非嘗試更改伺服器密碼。

開關立即關閉時，區分系統問題與設定問題

先關閉 On Demand，再手動連線一次，觀察是否仍會立即中斷。按需條件可能在網路變動時重新判斷連線狀態；暫時關閉可協助排除自動觸發的干擾。記下目前使用的 Config 名稱，檢查最近是否編輯過無法解析的內容、引用不存在的策略，或留下不完整欄位。優先還原自己儲存的上一份可用設定，不要改用來源不明的整套設定。

若先前一直正常，直到刪除系統 VPN 設定後才出現問題，請先確認已有必要的設定備份，再透過 App 重新發起系統授權。刪除系統設定不是首選步驟；這無法修正錯誤的伺服器參數，也不會還原訂閱資訊。需要重建時，先中斷連線並記錄 On Demand 狀態，再只處理 Shadowrocket 對應的設定，避免誤動其他工作用途的系統項目。

以可觀察的狀態結束本輪排查

完成授權後，讓 App 保持在前景，觀察系統 VPN 狀態是否穩定，再開啟一個先前可正常瀏覽的一般網頁。若開關穩定但網頁無法載入，請前往下一章排查路由與伺服器，不要反覆刪除授權。若開關仍立即關閉，記下錯誤原文、是否所有伺服器都有相同情況，以及重新啟動裝置後能否重現。先正常重新啟動再測試，比反覆強制結束 App 更容易取得明確結果。

也要另外確認系統限制：螢幕使用時間、裝置管理政策或其他網路設定都可能影響 VPN 連線。只檢查與自己裝置相關的授權狀態，不要任意移除組織設定。若裝置的一般網路本身無法使用，應先恢復 Wi-Fi 或行動網路；VPN 授權正常並不能取代基本網路連線。權限提示的詳細說明請參閱新增 VPN 設定提示說明。

02 連線後無法上網：分別檢查路由與基本網路

系統顯示 VPN 已連線，只代表連線延伸功能正在運作，不代表每個要求都已成功抵達目標。先關閉 Shadowrocket，透過相同網路瀏覽一個已知可用的網頁。若關閉後仍無法瀏覽，請優先檢查 Wi-Fi 是否需要網頁認證、行動數據是否可用，以及路由器是否正常連線。在公共 Wi-Fi 上，先完成網路登入或使用條款確認，再建立連線，避免將認證頁面無法開啟誤判為規則錯誤。

透過 Global Routing 對照，判斷故障所在

確認基本網路正常後，記錄目前的 Global Routing，並對相同目標進行短暫對照。Config 模式會依目前規則分流；Proxy 模式適合檢查所選伺服器能否傳送要求；Direct 模式則用來對照不經代理伺服器時的結果。切換模式是診斷方式，不是永久解決方案。每輪測試結束後都要還原原本模式，避免後續 App 要求因暫時設定而走上非預期路徑。

對照測試應使用相同目標，不要在三種模式下分別開啟不同網站。也不要只因某個網站失敗就判定整個連線失效；目標網站本身可能故障，或其內容仰賴其他網域。至少再測試另一個獨立目標，並記錄是完全無法開啟、只有圖片載入失敗，還是登入流程失敗。若 Proxy 可用但 Config 不可用，應檢查要求符合了哪條規則，而不是繼續更換伺服器協定。

規則由上而下比對，先找出實際符合的項目

檢查目前啟用的 Config，不要只看檔案清單中最近編輯的檔案。規則通常由上而下比對，第一個符合的項目會決定處理方式；後方範圍較廣的規則無法修正前面已符合的錯誤策略。特別留意範圍較廣的 DOMAIN-KEYWORD、REJECT 是否誤擋，以及 FINAL 是否符合預期。下方僅示範比對語法與順序，不建議整段取代現有設定。

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

若能查看記錄，請選取剛發出的要求，對照目標網域、符合的規則、最終策略與錯誤結果。不要只看清單中選取的伺服器名稱：規則或策略群組可能會改變實際出口。若要求符合 REJECT，先確認該網域是否原本就應封鎖；若是業務所需網域，只調整對應的窄範圍項目並保留原值。不要為了開啟單一頁面就清空整份規則。

依可重現的結果選擇下一章

若所有模式都失敗，但關閉連線後正常，請繼續檢查 DNS 與連線程序；若只有 Proxy 失敗，請前往伺服器逾時章節；若只有 Config 失敗，請針對規則與策略引用縮小範圍。無法連線至區域網路印表機或路由器管理頁時，也要確認目標位址確實屬於本機網段，以及現有 IP-CIDR 是否涵蓋該位址。不要把範例中的私有網段當成所有家用網路的完整清單。

最後驗證時，應重做原本失敗的操作，而非只確認網頁標題能否顯示。重新載入頁面、送出一次必要的一般要求，並確認系統連線仍穩定。進行登入或付款操作前，先確認網站網址正確，再測試連線；不要透過關閉憑證驗證來處理網頁錯誤。若仍無法判斷，可在FAQ中對照相同症狀，並保留本輪三種模式的測試結果，避免從頭重複測試。

03 伺服器逾時：依序檢查位址、傳輸與驗證

逾時表示在指定時間內未收到預期回應，無法直接指出哪個環節出問題。可能是伺服器網域無法解析、目標連接埠無法連線、協定交握不相符，也可能只是 Connectivity Test 使用的測試目標暫時無法使用。先記錄測試入口、錯誤原文、是否只有單一伺服器失敗，以及一般網頁要求是否也同樣失敗。測試結果只是線索，不能完整證明伺服器狀態。

先核對 Add Server 中的基本欄位

開啟既有伺服器項目，對照自己持有的原始資訊，逐一檢查 Type、Server、Port 與驗證欄位。Server 不要混入不屬於該欄位的路徑、空格或協定前綴；Port 必須與伺服器實際監聽的連接埠一致。手動輸入時，常見錯誤是把顯示名稱當成伺服器位址，或將訂閱網址填入單一伺服器欄位。先確認資訊類型，再修改內容，避免在錯誤入口反覆貼上資料。

若位址使用網域名稱，網域解析失敗會使後續連線無法開始。可先確認相同網路下其他網域是否能正常解析，再前往 DNS 章節。不要自行將網域換成隨機找到的 IP：伺服器可能仰賴 SNI、憑證網域或特定路由運作。只有在掌握伺服器對應關係，並能確認保留正確 TLS 參數時，位址對照測試才有判讀價值。

協定相同，不代表附加參數也相同

Shadowsocks 要核對加密方式與密碼；VMess、VLESS 要核對識別欄位及所用傳輸方式；Trojan 應檢查密碼、TLS 與 SNI；Hysteria2 則要留意目前網路是否支援所需的 UDP 通訊。若使用 WebSocket 等傳輸方式，Host 與 Path 也必須與伺服器端一致。不要只修改 Type 就期待不同協定可以互通，也不要只憑連接埠數字猜測協定類別。

出現憑證相關錯誤時，先檢查裝置日期、SNI 與憑證網域是否相符，再確認伺服器憑證是否有效。不要把 Allow Insecure 當成通用修復開關；略過驗證可能掩蓋位址錯誤或異常憑證。TLS 連上某個連接埠，不代表驗證已成功，也不代表要求已抵達預期伺服器。欄位意義請參閱Trojan 參數與 TLS 核對說明。

透過最少的對照，判斷網路問題所在

條件允許時，保持同一伺服器設定，分別透過 Wi-Fi 與行動網路測試。只有某種網路失敗，應優先檢查連線環境或該路徑，而非重新產生所有驗證資訊。相反地，若同一網路只有某台伺服器失敗，才更值得檢查該項目的位址、連接埠與伺服器狀態。每次切換網路後，等連線狀態穩定再送出相同要求，避免將切換瞬間的中斷誤判為持續故障。

若手動項目可用，但訂閱中的相同項目無法使用，請逐一比較兩者欄位，並留意訂閱更新可能會覆蓋本機修改。若所有既有伺服器都失敗，也不能直接認定用戶端損壞；它們可能共用網域、驗證資訊或同一服務端入口。向自己的服務資訊提供者回報時，提供時間、網路類型、協定與已遮蔽敏感資訊的錯誤內容，不要在公開討論區傳送完整憑證。修正後請重新驗證實際要求，而非只追求測試清單顯示數字。

04 Subscribe 失敗：區分取得、解析與覆寫

訂閱問題至少可分成三個步驟：用戶端能否取得內容、內容能否辨識，以及匯入結果是否如預期顯示在清單中。若錯誤發生在第一步，反覆修改伺服器協定沒有幫助；若內容已匯入但無法連線，則應回到上一章排查。本章以使用者已有自己的訂閱為前提。訂閱連結屬於存取憑證的一部分，即使看起來只是一般網址，也不應出現在截圖、公開記錄或可供他人複製的說明中。

先確認網址完整，再檢查取得方式

在 Config 的 Subscribe 相關入口核對既有網址，確認複製時沒有遺漏查詢參數、截斷尾端或帶入換行符號。若 App 提供訂閱項目的編輯與更新入口，請以目前介面顯示的文字為準；不同入口的名稱與位置應依已安裝的介面確認。不要把服務說明頁、帳戶登入頁或單一伺服器分享內容當成訂閱網址。先向原始資訊提供者確認手上的資訊類型。

更新失敗時，先記錄當下連線是開啟還是關閉。取得訂閱內容本身也需要經過網路路徑；目前伺服器失效可能使更新要求無法送達。在基本網路可用的前提下，可暫時關閉連線後重新更新；若原本必須透過既有的可用路徑才能取得內容，請先選用自己已驗證可用的項目。不要在短時間內連續重試，以免暫時性流量限制與原始故障交疊。

回應成功，不代表內容就是有效訂閱

網路要求收到回應後，回傳內容仍可能是登入頁面、到期提示、驗證頁面或錯誤說明。此時「無法解析」通常不是用戶端需要任意轉換格式，而是內容本身並非預期的伺服器項目。請確認自己的訂閱是否仍有效、網址是否已更換，以及提供者是否調整了回傳格式。不要將未知網頁內容直接覆寫到正在使用的 Config，也不要把訂閱憑證提交至陌生的線上轉換頁面。

若只有部分項目成功匯入，請比較缺少項目的協定類型、欄位完整性及目前 App 的支援情況。不要自行捏造密碼或驗證識別碼，也不要靠反覆修改編碼碰運氣。可使用已遮蔽敏感資訊的欄位名稱與錯誤文字說明情況，而非公開原始回應。完整匯入入口的差異請參閱Subscribe、Add Server、掃描 QR Code 與剪貼簿入口說明。

更新前保護本機編輯內容，更新後檢查選取狀態

訂閱通常代表由遠端管理的一組資訊，更新後可能改變名稱、排序、位址或項目數量。本機暫時修正的參數未必會一直保留。更新前記錄自己修改過哪些欄位，必要時儲存 App 支援的設定備份；更新後先確認原先選取的伺服器項目仍存在，再檢查 Global Routing 與目前使用的 Config。清單更新成功，不代表目前使用的項目已經可用。

更新後若清單變空，請勿立即刪除所有歷史項目。先確認是否選錯更新目標、訂閱是否回傳空內容、帳戶狀態是否變更，以及是否有可還原的本機記錄。若仍有可用的手動項目，可先保留作為驗證基準。只有在確認握有完整原始資訊且能重新取得內容時，才適合刪除後重新新增；這不是解決所有解析錯誤的通用方法。

最後選取更新後的一台伺服器，檢查必要參數，再測試同一個一般網頁。若訂閱更新成功但伺服器逾時，就不要再反覆重試 Subscribe，請改查連線參數。若只有自動更新失敗、手動更新正常，應觀察失敗當下的網路狀態與時間條件，不要先推斷背景機制損壞。用戶端買斷與既有訂閱的有效期限是兩回事，重新購買 App 無法修復失效的訂閱網址。

05 速度緩慢：區分交握、傳輸量與目標服務

「速度慢」可能是網頁開啟前等待很久，也可能是頁面立即回應但大型檔案傳輸緩慢，或只有圖片、影片或特定 App 受到影響。先把症狀描述得可重現：同一目標首次開啟需要多久、再次開啟是否改善、切換網路後是否有變化。不要直接把 Connectivity Test 的結果當成下載速度。短時間要求的往返時間與持續傳輸能力是不同指標；單次測試無法涵蓋壅塞、封包遺失與目標服務負載。

建立可比較的測試條件

使用同一台裝置、同一個網路與同一個目標，盡量在相近時間進行對照。暫停正在進行的雲端同步、大型檔案傳輸或 App 更新，避免其他工作占用網路。記錄目前伺服器與 Global Routing，再分別觀察首次造訪及再次造訪的結果。首次較慢而再次明顯改善，可能與 DNS、TLS 交握或內容快取有關；持續傳輸一直緩慢，則應優先檢查路徑品質、壅塞情況與伺服器實際負載。

不要同時更換伺服器、DNS 與規則後才比較結果，否則即使改善，也無法判斷是哪一項發揮作用。若已有多台自己管理的伺服器，每次只更換一台，並以相同要求重新測試。也不要把切換網路時短暫中斷的狀況列入穩定速度。等 Wi-Fi 或行動網路穩定，確認系統不再要求認證後，才開始下一輪測試，結果才有判讀價值。

只有部分內容緩慢時，檢查網域與策略

單一頁面通常會同時要求主網站、靜態資源、圖片與 API 等多個網域。主頁載入快速、資源卻很慢，可能是資源網域符合了不同策略，或某條範圍過廣的規則改變了出口。查看剛發出的要求記錄，核對載入緩慢的要求實際使用的網域與符合的策略。只調整已確認有誤的網域，不要一律將所有相關網域改成相同處理方式。目標服務也可能依地區、帳戶或快取分發不同內容，不能只憑伺服器測試正常就排除目標端差異。

若 Config 緩慢而 Proxy 表現正常，可檢查策略群組、規則順序與 DNS 查詢路徑；若兩者都慢，但 Direct 連線至同一個可直接連線的目標正常，就應繼續檢查目前的伺服器路徑。不過，Direct 無法連線至某個目標，不能用來證明伺服器較快或較慢，因為兩條路徑可能根本不具備相同的連線能力。對照的前提是兩種方式都能完成相同操作。

不要盲目調整 UDP、MTU 與傳輸參數

即時通訊、部分影音串流與特定協定可能依賴 UDP；一般網頁可用，並不能證明 UDP 路徑正常。若只有這些功能異常，先確認伺服器支援情況與目前網路的限制。對 Hysteria2 等協定，不能用調整頻寬欄位取代基本連線驗證；填入較大的數值也不代表實際傳輸量會提高。請依據自己的伺服器設定說明，保留原值，再進行單一變數測試。

若小型要求正常、大型要求卻卡住，可將路徑 MTU 列為後續調查方向，但不要在沒有證據時反覆修改。類似情況也可能來自封包遺失、目標服務限速或連線重設。先確認問題是否只發生在特定網路、是否與特定協定有關，以及切換至另一個已知可用的伺服器後是否消失。只有確認相關性，且了解如何還原時，才嘗試符合部署情況的參數調整。

裝置發熱也會影響實際使用體驗。長時間高負載傳輸、螢幕持續亮著與背景工作可能同時發生；暫停測試，讓裝置恢復正常狀態後，再以短時間要求重新測試。裝置明顯升溫時，不要連續大量測速。最後仍應依原本的工作需求判斷：網頁能否及時載入、影片是否持續緩衝、檔案是否穩定傳輸，而非只追求測試入口顯示的數字更低。

06 DNS 異常：確認解析來源與要求去向

DNS 會將網域名稱轉換成可用於連線的位址。網域無法解析時，代理交握可能尚未開始；即使網域成功解析，若取得的位址不適用於目前路徑，也可能逾時或連到錯誤位置。常見線索包括多個網域同時失敗、首次開啟需等待很久，或切換網路後部分目標無法使用。不要只因「某個 IP 可以連線」就斷定全部都是 DNS 問題，因為 HTTPS 還涉及網域、SNI 與憑證驗證。

先查看目前的 Config，而不是憑記憶中的設定判斷

開啟目前實際使用的設定，檢查 General 中的 dns-server，以及是否有其他會影響解析的對應設定或規則。以下範例表示使用系統提供的解析來源，只用於說明語法，不保證適用所有網路。修改前先儲存目前的值，尤其不要直接以單一位址覆蓋既有的分流解析安排。系統 DNS 的實際來源可能隨 Wi-Fi、行動網路與裝置管理設定而改變，不能視為固定不變。

[General]
dns-server = system

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

檢查是否有手動 Host 對應或舊位址記錄。這些設定可能繞過正在調查的一般解析路徑，讓更換 dns-server 後看起來毫無變化。若某個網域被固定到已過期的位址，先對照自己的原始設定來源，再決定移除或修正。不要直接將公開討論中提到的位址填入對應設定；網域與位址的關係可能隨地區、服務部署與時間而變動。

加密解析也需要可連線的基本路徑

使用加密 DNS 時，解析服務本身也必須能連線；若必須先建立代理才能連線至該服務，而代理伺服器位址又仰賴同一條解析路徑，就可能在啟動階段形成依賴問題。排查時先確認伺服器網域能否完成首次解析，再檢查後續目標網域。不要同時更換解析服務與代理位址，否則難以判斷問題究竟來自解析恢復，還是伺服器路徑改變。

部分公共 Wi-Fi 可能只允許使用預期的解析與認證流程。完成認證前，更換解析設定未必有幫助。先關閉連線，完成網路登入，再依原本設定重新測試。若問題只出現在某個網路，請在另一個自己可用的網路上使用相同設定進行對照；若設定不變但結果不同，應優先調查網路如何處理解析要求，而非立即改寫所有網域規則。

一併觀察 IPv4、IPv6 與規則比對

同一網域可能回傳 IPv4 與 IPv6 位址，裝置選用的實際路徑會受到網路能力影響。若問題只發生在支援 IPv6 的網路，請記錄解析結果類型、實際連線目標與失敗方式，不要立即全域關閉相關功能。IP-CIDR 與 IP-CIDR6 分別處理不同位址家族，只有前者的本機規則未必能涵蓋後者。網域規則與位址規則的比對時機也不同，調整前應先確認要求實際符合哪條規則。

GEOIP 判斷仰賴位址歸屬資訊，並不等於能精確表示每個網域的業務用途。CDN 位址可能變動，共用位址也可能服務多個網域。針對已確認的少數業務需求，優先檢查能否使用範圍更明確的 DOMAIN 或 DOMAIN-SUFFIX 表示，而非不斷擴大位址範圍。保留易於判讀的 FINAL 作為備用規則，並確認策略符合目前用途。

修改後重新送出原本失敗的要求，並留意 App 或系統可能仍保留快取。可先關閉相關頁面再重新開啟，接著觀察新的要求；若需要重新連線，也要先記錄中斷前後的設定。不要反覆重新啟動所有裝置來取代驗證。成功標準是目標網域取得合理結果、要求符合預期策略並實際完成，而不是某個解析測試單獨顯示成功。關鍵字定義請參閱名詞解釋。

07 耗電、發熱與頻繁重新連線：檢查活動來源

長時間維持 VPN 連線不一定代表耗電異常；真正需要觀察的是傳輸量、重新連線頻率、裝置溫度，以及同期其他 App 的活動。系統電池頁面呈現的是一段時間內的統計，不是單次要求的精確耗電量。先記下異常開始時間、當時使用的網路與 App，再比較相近時長、相似工作下的表現。不要直接把某次統計中較高的占比解讀為用戶端持續滿載運作。

先排除持續傳輸與背景工作

檢查是否正在進行照片同步、大型檔案傳輸、影片播放或 App 更新。這些工作經過連線時，可能讓網路延伸功能持續處理流量；此時應一併檢查業務 App 與連線延伸功能的統計。暫停相關工作，在其他條件不變的情況下觀察一段時間，確認是否仍明顯發熱。測試耗電時不要同時大量執行 Connectivity Test，這些操作本身也會產生連線與資料傳輸。

解讀系統電池頁面上的背景活動時，也要考量實際使用情境。螢幕持續亮著、行動網路訊號較弱、分享個人熱點與高溫環境都可能增加耗電。讓裝置恢復正常溫度並連上穩定網路後再比較，可減少誤判。若關閉連線後仍持續發熱，應先排除裝置與其他 App 的活動，不要把所有問題都歸因於 Shadowrocket 的規則設定。

分開驗證 On Demand 與網路切換

On Demand 會依系統條件觸發連線。若 Wi-Fi 與行動網路頻繁切換，或存取點短暫失聯，可能會反覆建立與中斷連線。先記錄按需條件，再暫時關閉 On Demand，維持同一網路並手動連線，觀察重新連線次數是否減少。若確實減少，請回頭檢查條件是否重疊、目前網路是否穩定，不要長期維持自己也不理解的觸發設定。

裝置從睡眠喚醒、離開 Wi-Fi 覆蓋範圍或經過網路認證時，短暫重建連線可能是環境變動造成的。真正異常的是網路已穩定後仍持續反覆連線。查看記錄，確認是系統觸發連線、伺服器交握失敗，還是業務要求不斷重試。區分這三種情況，才能判斷應調整 On Demand、檢查伺服器，或處理持續送出要求的 App。只觀察狀態圖示閃動並不足夠。

記錄、規則與連線失敗的成本

為了排查而啟用較詳細的記錄後，完成取樣就應恢復平常使用的記錄層級。長時間保留大量詳細記錄會增加儲存與處理負擔，也可能留下隱私資訊。記錄應針對短時間內的一次重現收集，不需要持續保存所有日常要求。分享前遮蔽網域中的身分資訊、伺服器位址與驗證內容，只保留定位問題所需的錯誤資訊。

失效的伺服器也可能使業務要求反覆等待與重試。若目前規則將大量日常流量導向無法使用的策略，表面上看似背景耗電，根本原因卻可能是要求持續失敗。先確認實際使用的伺服器可用，再檢查是否有網域遭到誤擋而不斷重試。規則數量多本身不能證明是耗電原因，應以實際要求、失敗頻率與調整前後的對照結果判斷。

若只有某種協定在目前網路上持續重新連線，請使用自己已有的另一項可用設定進行對照，並維持目標與工作不變。不要同時變更協定、伺服器與工作負載後，就將結果歸因於單一設定。對 WireGuard 等仰賴特定部署參數的項目，也不要任意修改 keepalive 相關值；是否需要以及應設定多少，必須依伺服器與網路環境判斷。

一輪觀察結束後，恢復正常記錄層級，確認 On Demand 已回到預期狀態，並記錄裝置溫度與電量趨勢是否改善。若暫停工作、使用穩定網路與可用伺服器後仍持續異常，再保留已遮蔽敏感資訊的記錄，繼續排查更新後的變化。系統電池資料有統計期間，修改後應等待一段可比較的使用時間；切換開關幾秒鐘，不會立即改變整段歷史占比。

08 更新後與 iPad 異常：還原基準狀態，再檢查差異

異常剛好發生在更新後，不代表更新一定是唯一原因。App 更新、系統更新、訂閱重新整理、伺服器變更與網路切換可能在相近時間發生。先列出最後一次成功連線與第一次失敗之間的變化，再以最少變數重新測試。保留目前的 Config 與原始伺服器資訊，不要立即清除所有資料。還原購買只能恢復 App 的取得資格，不代表使用者自行編輯的所有本機內容也會自動還原。

更新後先確認目前選取項目與系統授權

開啟 Home，檢查選取的伺服器、Global Routing 與系統連線狀態，再確認目前啟用的 Config 是否為預期檔案。若先前使用策略群組，請檢查群組內的選取項目是否有所變更。設定清單中存在某個項目，不代表它正在生效；名稱相似也不代表內容相同。先對照自己儲存的可用基準，確認差異後再修改，不要用全部重設為預設值取代問題定位。

若系統 VPN 設定已移除，或移轉裝置後需要重新授權，請依第一章完成系統提示。若 App 可以開啟但所有連線都失敗，先在目前網路關閉連線以驗證基本瀏覽，再用原本可用的伺服器測試。必要時正常重新啟動裝置後再測試一次，並記錄結果。更新記錄與系統需求請以 App Store 頁面為準，不要依據網路文章中的舊截圖判斷目前介面是否「缺少功能」。

對照 iPad 與 iPhone 時，先統一測試條件

同一個既有訂閱在 iPhone 可用、在 iPad 卻無法使用時，先確認兩台裝置是否真的使用相同伺服器、相同協定參數與相同 Config。訂閱名稱一致，不代表兩台裝置最近更新的內容也一致。還要核對 Global Routing 與 DNS，尤其是其中一台裝置保留了本機編輯內容時。尚未逐項比較前，不要認定是 iPad 專屬的相容性問題。

網路條件也可能不同：iPad 可能只連上 Wi-Fi，而 iPhone 實際上透過行動網路傳輸。先讓兩台裝置連上同一個 Wi-Fi，使用相同目標測試，再分別觀察結果。若只有 iPad 失敗，請檢查其 VPN 授權、裝置管理限制、網路認證狀態與系統日期。若兩台裝置同時失敗，則應檢查共用的伺服器、訂閱或路由器，不必繼續追查平板介面配置。

iPad 的橫向、分割畫面或視窗配置可能改變入口位置，但不會讓同名欄位變成不同的伺服器參數。可依 Home、Config、Settings 等介面文字尋找功能；空間不足時，先恢復成方便操作的完整視窗再檢查。不要因為某個入口沒有出現在手機截圖的位置，就新建重複設定。入門操作仍請參閱入門指南，本頁則用於排查差異與異常。

重新取得 App 前，先確認備份與購買範圍

確實需要重新取得 App 時，請只透過 App Store；先確認原購買帳戶與已購項目，詳細步驟請參閱已購項目還原說明。確認正版資訊時，請核對開發者 Shadow Launch Technology Limited、官方圖示與 App ID 932747118。Shadowrocket 是閉源商業 App；系統需求與裝置購買適用範圍請以 App Store 頁面標示為準，不要根據舊說明推斷所有裝置的適用資格。

重新安裝前，請確認已有訂閱網址、手動伺服器參數與本機 Config 都已妥善保存，且自己能夠還原。備份可能包含密碼、私鑰與存取憑證，應存放在自己可控的位置，不要張貼至公開頁面。App 購買記錄、系統 VPN 設定與使用者自己的連線資料屬於不同層次；能還原前者，不代表後兩者也已還原。重新開啟後，仍應依首次授權與驗證流程檢查。

整理可重現的故障記錄

若完成所有本機排查步驟後問題仍未解決，請準備一份簡短記錄：裝置類型、系統與 App 顯示的資訊、網路類型、失敗的入口、已遮蔽敏感資訊的錯誤原文、最後一次正常操作，以及已完成的對照測試結果。明確指出是開關立即關閉、網域解析失敗、交握失敗，還是特定業務要求逾時。不要只寫「更新後不能用」，也不要一次提交大量不相關截圖，以免淹沒真正失敗的步驟。

若問題涉及伺服器驗證、訂閱有效性或服務端協定參數，應向自己的資訊提供者確認；若涉及系統授權或裝置管理限制，則應檢查裝置設定。確認問題已排除後，再檢查 On Demand、Global Routing、記錄層級與臨時測試規則是否已恢復預期狀態。完整排查的終點不是偶然開啟某個網頁，而是在已記錄的正常設定下，原先失敗的操作也能重複完成。