Shadowrocket 故障排除指南

連線開關無法開啟：先檢查系統授權

本章適用於 Home 中的連線開關無法維持開啟、剛開啟就返回關閉，或首次連線時卡在系統授權的情況。先區分「隧道尚未建立」與「隧道已建立但無法存取」：前者優先檢查系統權限及設定是否能載入，後者再檢查路由與伺服器。僅憑頂端是否顯示 VPN 標誌，無法判斷所有請求都已成功。

確認系統提示與目前操作

首次建立連線時，系統可能會要求允許加入 VPN 設定，並透過裝置密碼或生物辨識確認。這是系統儲存網路設定的授權流程，不是訂閱驗證。確認提示用途後再完成授權；如果先前取消，請回到 Shadowrocket 重新發起連線並觀察。提示尚未處理時不要反覆點按開關，以免難以判斷哪次操作生效。

若沒有提示且開關立即返回關閉，請進入系統 Settings，尋找 VPN 與裝置管理相關項目，確認是否有 Shadowrocket 對應的記錄。系統項目名稱可能因系統語言與版面而異，請以裝置實際顯示為準。先記下現有項目，不要直接大量刪除；受管理裝置的網路限制應由裝置管理員確認，不要反覆重建設定試圖繞過限制。

排除設定載入問題與連線衝突

返回 Home，確認 SERVER 中確實有可選的伺服器，並確認目前選取的不是已刪除的訂閱項目。匯入成功只代表資訊已儲存，不代表參數一定完整。特別是在替換訂閱、刪除群組或重新匯入 Config 後，請再次確認所選項目仍有效。如果問題剛好發生在某次編輯後，先還原編輯前的備份再測試。

接著確認是否同時存在其他作用中的 VPN 設定，或有系統管理政策正在重新建立連線。多個接管網路的設定可能彼此取代，表現為開關閃退或連線狀態不斷變化。對自己有權管理的設定，先停止其他連線，再單獨測試 Shadowrocket。不要一併關閉系統中所有網路相關設定，以免引入新的變數。

也要檢查 On Demand。它可能依據網路條件自動觸發連線，讓人感覺「手動關閉後又自行開啟」。排查期間先記下原有條件，暫時停用自動觸發，再以手動開關重複測試。若手動連線穩定，只有恢復自動條件後才出現異常，應集中檢查條件比對，而非繼續修改伺服器密碼或協定欄位。

以最少變更驗證復原方式

確認目前的基本網路能正常瀏覽一般網頁後，完全關閉連線，返回系統主畫面，再重新開啟 App 測試。仍不正常時，可重新啟動裝置，以排除短暫的系統網路狀態異常。每次測試都應等待介面完成狀態變更；連續快速開關無法縮短交握時間，還可能讓記錄留下多次人為中斷，掩蓋真正的失敗原因。

如果最近編輯過 Config，先保留副本，再切換至自己先前確認可用的設定。設定解析錯誤與遠端連線錯誤並非同一層問題：前者可能在建立隧道前就中止，後者通常發生在隧道啟動後。查看 App 提供的相關提示，優先處理具體錯誤；不要只因為「連不上」就同時重寫規則與 DNS。

只有在完成備份，並確認不是受管理政策限制後，才考慮移除屬於 Shadowrocket 的舊 VPN 設定，再由 App 重新請求系統授權。這項操作處理的是系統設定記錄，無法修復過期訂閱或錯誤的伺服器參數。訂閱網址、憑證與手動項目是否另有備份，應在操作前逐項確認；重新授權不等於完整的資料復原。

本章的完成標準是：開關能維持開啟，系統不再反覆要求授權，而且手動關閉能正常結束連線。若符合這些條件但網頁仍無法開啟，請前往下一章。若系統始終拒絕儲存設定，請記下完整提示、裝置是否受管理及重新啟動後的結果，再依常見問題中的權限說明繼續檢查。

已連線但無法上網：區分路由與遠端故障

連線開關維持開啟，只能表示本機隧道正在運作；個別請求仍須經過規則比對、名稱解析與遠端連線。先關閉 Shadowrocket，以目前網路瀏覽兩個平時可正常開啟的網站。若關閉後也無法存取，應優先處理 Wi-Fi 認證、行動數據權限或基本網路問題，而不是更換 Config。完成基本比對後，再開啟連線重測相同目標。

先用 Global Routing 建立比對

記下原本的 Global Routing，再視需要以 Config、Proxy、Direct 短暫比對。中文說明分別對應設定、代理、直連，但實際介面名稱仍以英文為準。這些模式用於改變請求的路徑選擇，並非改善所有網路問題的通用開關。測試結束後應恢復原本需要的模式，避免長期保留臨時驗證設定。

如果 Proxy 可以存取而 Config 失敗，請優先檢查失敗請求符合的規則、策略指向，以及設定是否確實啟用。如果 Direct 可以存取而 Proxy 失敗，請優先檢查目前伺服器與遠端連線路徑。如果只有關閉隧道後才恢復，不能立刻判定是伺服器故障，還要檢查隧道內的 DNS、系統權限與其他網路設定是否互相影響。

檢查規則順序，不要整份替換

規則通常依設定中的順序判斷；範圍較廣的條件若放得太前面，可能先符合原本應套用其他策略的請求。檢查時先找出特定網域對應的規則，再檢視後續的預設策略。以下片段僅用於說明比對順序，並非適用於所有環境的完整設定；實際使用前，還要確認現有設定中的策略名稱與執行環境相符。

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

範例中，第一條處理指定網域及其子網域，第二條依地理位置判斷，最後一條則處理前面都未符合的請求。若將範圍很大的規則放在前面，後續更具體的條件可能就沒有機會參與判斷。修改時先複製目前的 Config，只在副本中調整一條相關規則，再用相同請求驗證，避免一次替換整份設定而無法還原。

如果某個網站首頁能開啟，但圖片或登入失敗，應將這些請求視為不同目標。頁面可能同時連線至主網域、靜態資源網域及身分驗證網域；只為首頁網域設定規則，無法保證相關資源走相同路徑。觀察相關請求的網域與實際策略，再補上確有需要的條件。不要為了修復單一資源，就直接將所有流量改走另一條路徑。

將規則判斷與服務回應分開看

若 App 提供連線記錄，可在重現一次問題後，核對目標網域、符合的規則、所選策略及錯誤類型。先確認記錄對應本次操作，而不是背景重新整理產生的其他請求。HTTP 狀態、認證失敗或網站拒絕存取，與底層無法連線不同；能收到遠端服務回應，通常表示問題已進入應用程式層，應依回應內容繼續判斷。

規則為 REJECT 時，主動拒絕請求可能正是設定的預期結果。遇到網頁元素缺失，先確認對應資源是否符合這類規則，而非直接判定伺服器失效。若確實需要允許通過，只調整相關條件並記下原因。同時，名稱解析失敗可能影響後續依地址進行的判斷，遇到這類情況也請參閱 DNS 章節。

本章的完成標準是能清楚說明「哪個目標、在何種模式下、經由哪條策略失敗」。記下這項結論，比保存一張籠統的連線狀態截圖更有用。若 Proxy 下所有目標都逾時，請前往伺服器逾時章節；若只有 Config 異常，繼續檢查規則；若所有路徑都出現名稱解析錯誤，優先檢查 DNS，不要重複調整已確認正確的伺服器資訊。

伺服器逾時：分層檢查伺服器與協定參數

Connectivity Test 逾時，表示測試未能在指定條件內取得預期結果，不代表所有實際請求都一定失敗。不同測試方式可能涉及不同目標與協定，因此也應觀察實際網頁瀏覽情況。先記下是單一項目逾時、同一訂閱中的多個項目逾時，還是所有既有項目都失敗；故障範圍不同，後續檢查方向也不同，不能只憑一個數字比較可用性。

依網路範圍判斷檢查方向

先在目前網路測試一個自己先前確認可用的目標，再於允許使用的另一種網路下重複測試。若相同伺服器在行動數據下正常、在某個 Wi-Fi 下失敗，請檢查該網路的認證狀態、存取限制與出口條件。若所有網路都失敗，則應優先核對伺服器是否仍在運作、連接埠是否正確、帳戶是否有效，以及伺服器端設定是否已變更。

不要以連續大量測試取代故障定位。先選一個項目，確認測試完成後再觀察實際存取情況，避免大量並行請求影響結果或觸發遠端限制。記下時間與網路類型，有助於區分持續故障與偶發波動。若只有特定時段失敗，請保留該時段的重複測試結果，不要因一次成功就認定設定已完全復原。

依伺服器原始資訊逐欄核對

伺服器位址與連接埠應與自己的伺服器資訊一致。位址前後多出的空格、複製時混入的換行或錯誤連接埠，都可能導致無法建立連線。連接埠不能任意嘗試，必須是伺服器實際監聽的連接埠。使用網域名稱時，也要確認解析結果正確；暫以位址比對時，則須保留原本需要的 TLS 主機名稱語意。

包含傳輸層設定的項目，也應對照伺服器端檢查傳輸類型、路徑及相關主機欄位。位址用來找到伺服器，TLS 主機名稱用來驗證對端身分，某些傳輸的主機欄位則用於請求路由，這些概念不一定相同。只有伺服器端明確要求一致時才填入相同內容；不要因為看到多個網域欄位，就機械式複製同一個值。

憑證錯誤通常會有比「逾時」更明確的提示，請核對裝置日期與時間、憑證有效性及名稱是否相符。不要把關閉憑證驗證當成一般解法，這會改變安全界線，卻無法修正伺服器端憑證設定本身。若由自己管理伺服器，請修正相應憑證與服務設定；若使用既有服務資訊，則依有效參數核對，不要猜測欄位組合。

辨別傳輸限制與伺服器端問題

部分協定或功能需要 UDP；網路能瀏覽一般網頁，不代表相關流量也一定可通。若某種傳輸只在特定網路下失敗，請一併檢查網路差異與伺服器端要求。不要盲目調整 MTU、保活或逾時參數；除非有分片、路徑或閒置連線方面的證據，否則容易讓單一故障變成多個設定變數疊加。

若伺服器由自己管理，可核對服務是否運作、監聽連接埠、防火牆及同一時段的伺服器端記錄。客戶端顯示連線已關閉，可能是遠端主動結束，也可能是中間網路中斷，單一提示無法確認原因。應比對客戶端與伺服器端的時間，再判斷請求是否抵達及停在哪個階段；排查記錄不需要貼上完整認證資訊。

若更新訂閱後舊項目消失或位址變更，請依目前有效資訊重新選取項目，不要繼續測試已停止維護的本機項目。訂閱中的顯示名稱只是識別標籤，名稱相同不代表底層參數也相同。復原後保存必要的核對結論：失敗的網路、錯誤階段、修正欄位與實際存取結果；若訂閱仍無法更新，再依下一章檢查取得與解析流程。

Subscribe 失敗：區分取得、解析與項目變更

訂閱更新包含幾個獨立步驟：請求位址、取得回應、解析內容、寫入項目。任何一步都可能失敗。先保留原本有效的項目，不要先刪除再嘗試更新；否則一次暫時性的請求失敗，就可能連可用的本機資訊也一併清除。排查時記下具體提示，區分連線逾時、狀態異常、格式不支援，以及更新成功但項目數量有變化等情況。

先保護位址，再核對完整性

訂閱位址可能包含存取憑證，應視為敏感資訊保存。複製時確認參數後段是否遺漏，是否混入空格、標點或通訊 App 加上的換行。不要將完整位址貼到公開討論區，也不要使用來源不明的網頁代為轉換內容。若要向他人說明格式，只保留網域類型與參數名稱，並遮蔽可識別帳戶的值。

瀏覽器能開啟某個位址，不代表回傳內容就是可匯入格式。瀏覽器可能已處於登入狀態，也可能顯示網頁、驗證頁面或存取錯誤說明。請依 App 提示及自己的訂閱說明判斷回應類型。若查看原始回應，只需核對內容是否為預期格式，不要將可能包含認證資訊的整段文字貼到公開位置。

區分網路故障與內容錯誤

請求逾時或網域解析失敗，先檢查網路與 DNS；若明確顯示認證失敗，則核對位址是否失效、帳戶狀態及憑證是否變更。若提示請求過於頻繁，請停止反覆重新整理，依回應要求等候後再試。反覆刪除再新增通常無法恢復存取權限，還可能讓伺服器收到更多重複請求，增加判斷難度。

若訂閱取得作業需要目前的代理，而目前代理又來自已失效的訂閱，就可能形成更新依賴。應先判斷該位址能否透過目前網路直接存取，以及 App 目前如何處理更新請求。若有其他已確認可用的路徑，可用來比對一次；若沒有，應先恢復基本連線條件，不能期待一次更新就自動修復所有網路層問題。

格式錯誤時，請核對伺服器端提供的內容是否為 Shadowrocket 目前支援的匯入格式。網頁連結、設定檔位址與伺服器分享資訊並非相同類型的資料，不能只因為都能複製，就放進同一個入口。依自己的原始資訊選擇 Subscribe 或相應的匯入操作；首次使用時不確定入口，可返回快速入門確認操作流程。

確認「更新成功」後的項目狀態

更新成功但清單變空時，請確認回傳內容是否確實包含有效項目，或是否經過篩選。項目減少也可能是伺服器端正常移除項目，不宜直接判定為客戶端遺失資料。先保存目前結果，與自己持有的訂閱說明比對，再確認是否有名稱篩選、群組差異或暫時性的回應異常。原因未查明前，不要多次覆寫唯一的本機備份。

手動編輯訂閱產生的項目後，下次更新可能會重新寫入伺服器端資訊。因此，試驗用參數最好另存為清楚標示的手動項目，並保留原訂閱作為比對。兩者名稱應能區分，避免以為修改沒有生效，實際測試的卻是另一個項目。排查結束後整理臨時副本，避免日後繼續選用過期的測試資訊。

匯入項目與啟用 Config 也應分開確認。Subscribe 用於更新伺服器資訊，不會自動確保所有規則、DNS 與策略都適合目前網路。即使新項目已出現在 Home，仍須選取有效伺服器、核對 Global Routing，並實際測試存取情況。如果清單更新成功但無法連線，請前往伺服器逾時章節，不要反覆匯入相同位址。

建立可復原的更新習慣

進行較大幅度調整前，先備份自己需要保留的手動資訊與 Config，並確認備份涵蓋哪些內容。不同匯出方式所包含的資料可能不同，不能把「已有一個檔案」視為所有資訊都已儲存。將敏感備份存放在自己掌控的安全位置；說明問題時，只提供錯誤類型、發生時間及已移除憑證的必要結構。

本章的完成標準不只是清單曾出現項目，而是能重複更新、項目內容符合預期，且選取的項目能實際使用。若位址本身已失效，請依自己既有服務的管理方式更新資訊；App 購買與訂閱有效性是兩件獨立的事。購買或已購項目復原問題，請前往已購項目復原說明處理，不要反覆購買客戶端來修復訂閱。

速度慢：分別測量回應時間、傳輸量與穩定性

「速度慢」至少包括首次開啟等待時間長、開始傳輸後吞吐量低、播放時反覆停頓，以及切換網路後短暫中斷。先具體記下現象，再決定測量項目。Connectivity Test 的回應結果只涵蓋特定測試條件，不能直接代表大型檔案的傳輸速度，更不能代表所有網站的表現。單次測試時間偏長，也無法排除後續封包遺失或遠端壅塞。

建立可比較的測試條件

選擇一個平時可存取的固定目標，在相同裝置、相同網路及相近時段下比較。先測試關閉連線時的基本存取，再測目前設定，最後才更換自己已有的其他有效項目。每輪只調整一個條件，並盡量讓其他 App 的下載與同步狀態保持一致。若同時更換網路、伺服器和規則，就無法判斷改善來自哪個變更，也難以穩定重現。

觀察速度慢發生在哪個階段。輸入位址後長時間沒有開始，可能與名稱解析、建立連線或交握有關；已開始持續傳輸但速度偏低，則更應檢查連線容量、封包遺失及伺服器負載；單一頁面的某些資源遲遲無法載入，則可能是相關網域套用了不同策略。判斷階段比只記下「開啟等了很久」更能縮小排查範圍。

排除本機網路與目標差異

Wi-Fi 訊號格數無法完整反映網路品質。距離、干擾、無線基地台負載及寬頻出口都可能影響傳輸。先靠近基地台測試，並確認同一網路沒有大量背景傳輸，再與行動數據比對。若只有某個 Wi-Fi 表現不佳，優先檢查該網路。若行動數據也同樣異常，再確認裝置是否處於低數據模式，或 App 網路權限是否受限。

同一個代理項目存取不同目標，速度可能差異很大，因為遠端出口至目標網站的路徑並不相同。目標本身的負載、資源派送節點及帳戶端限制也可能影響結果。應使用不只一個目標確認影響範圍，但不必大量並行測速。單一網站存取緩慢，不足以證明客戶端整體效能異常，也不適合作為修改所有設定的依據。

核對規則、重試與背景負載

Config 中有些資源若被 REJECT 或導向不可用的策略，網頁可能等待重試後才繼續，讓人感覺網速變慢。先查看失敗請求是否集中於同一網域或同一策略，再檢查規則順序。若 Proxy 下頁面完整，Config 下卻明顯延遲，可針對相關規則局部比對，不必為了排查而長期改變所有請求的路徑。

同時檢查是否正在頻繁更新訂閱、大量測試連線或收集大量診斷記錄。這些活動未必是根本原因，但會占用網路與處理資源，干擾測試。排查時先停止不必要的重複操作，只保留目前需要觀察的項目。不要為了取得更多資訊而無限期保留詳細記錄；找到可重現的條件後，保存必要片段即可，接著恢復日常設定。

傳輸參數應以既有伺服器要求為準。任意提高並行數、反覆縮短逾時時間或修改 MTU，不能保證改善速度，反而可能造成更多連線重建與重傳。只有證據指向特定問題時，才測試相關參數，例如某種網路下大封包傳輸異常、小型請求卻正常。測試前保存原值，並明確定義何種結果才算改善、何時需要還原。

以實際使用情境驗證改善

若更換自己已有的有效項目後恢復，應在相同條件下再次確認原項目是否仍然緩慢，避免把時間變化誤認為伺服器差異。若所有項目在同一網路下都慢，換另一個網路卻正常，請繼續追查本機出口。若所有網路都只對某個目標很慢，則檢查目標服務與存取路徑。每項結論至少應重複比對一次，而非只憑偶然成功。

測試時也要考慮裝置溫度與背景工作。剛完成系統更新、照片同步或大量內容索引時，裝置可能同時處理多項工作，網頁顯示緩慢也容易被誤認為傳輸速度慢。請分開觀察「內容下載完成」與「頁面顯示完成」的時間；裝置明顯發熱時，先暫停高負載工作再測試，不要一邊持續充電一邊高負載運作，還拿細微差異來比較。

最後以原先出問題的使用情境驗收：連續瀏覽是否穩定、播放是否仍會停頓、切換網路後能否恢復，而非只追求某次測試數字更小。保留兩三筆最有參考價值的記錄即可。若等待主要發生在網域首次解析階段，請前往下一章；若速度問題伴隨明顯耗電，再參照耗電章節檢查背景重新連線與診斷活動。

DNS 問題：檢查解析路徑與快取

DNS 負責將網域名稱轉換為後續連線所需的位址。名稱解析成功不代表服務一定可連線，解析失敗也不等於伺服器認證出錯。常見現象包括部分網域無法開啟、首次存取明顯等待、切換網路後短暫異常，以及同一網域經不同路徑取得不同結果。先記下目標網域與具體錯誤，再確認問題是否確實發生在解析階段。

區分系統 DNS、自訂 DNS 與加密解析

系統 DNS 通常由目前網路提供，自訂 DNS 則會變更解析請求所使用的服務。DNS over HTTPS 透過 HTTPS 傳送解析請求，但仍依賴底層網路可達、憑證驗證正確及服務位址可用，並非填入後就能修復所有連線問題。選擇方式時應考量目前網路條件，而非只依形式判斷可靠程度。

若某個加密解析服務以網域名稱作為入口，還需考慮初始連線如何取得該位址，以及請求本身會經過哪條路徑。既有代理完全無法使用時，依賴該代理才能連線的解析服務也可能失敗。先釐清這項依賴，再決定用哪種可達方式進行比對；不要同時替換 DNS、伺服器與所有規則，讓錯誤鏈更難追查。

以單一網域進行可重複檢查

挑選一個反覆失敗的網域，在同一網路下分別觀察關閉連線與開啟連線後的結果。若只有開啟後失敗，請核對目前 Config 的 DNS 設定與解析請求路徑；若兩種狀態都失敗，則檢查網路端解析及目標本身的狀態。測試時務必使用完全相同的網域，不要把首頁網域與圖片資源網域的不同結果當成同一次比對。

不要把「直接存取某個位址成功」當成網域問題的唯一證據。HTTPS 服務可能依賴 TLS 主機名稱與虛擬主機路由，直接輸入位址會改變請求語意，結果不能直接比較。較穩妥的方式是結合解析記錄、錯誤階段與實際連線記錄判斷；若需指定位址測試，也應保留服務要求的主機名稱，而不是關閉驗證。

了解規則與解析之間的影響

DOMAIN、DOMAIN-SUFFIX 與 DOMAIN-KEYWORD 依網域條件判斷；IP-CIDR、IP-CIDR6 與 GEOIP 則涉及位址條件。是否需要先解析、解析後取得哪些位址，以及後續如何比對，都取決於實際規則與設定。排查時不要假設所有請求都只會比對一次網域規則，應查看失敗請求實際如何處理。

[Rule]
DOMAIN,example.com,PROXY
DOMAIN-SUFFIX,example.org,DIRECT
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
FINAL,PROXY

上方的位址區段僅為文件範例，不能據此設定自己的實際網路。no-resolve 表示該位址規則不會主動為了比對而觸發網域解析，不代表全域停止 DNS。理解這項差異，才能避免為了少一次解析而改變整份設定的行為。將範例用於學習後，請回到既有設定檢查相關規則，而非直接覆蓋目前使用的內容。

也要留意 IPv4 與 IPv6。某個網路能回傳 IPv6 位址，不代表一定有穩定可用的對應路徑，可能導致部分請求等待後才改用其他位址。先比較不同網路的結果，再核對位址家族與連線記錄。沒有證據時不要直接關閉所有 IPv6 相關設定；變更位址選擇可能影響其他請求，務必保留還原方式。

處理快取與設定覆寫

修改解析設定後，既有連線、App 快取或系統快取可能讓短時間內的結果與預期不同。先停止目前連線，重新建立後測試新的請求；必要時結束目標 App 的舊工作階段再存取。只有確有需要時才重新啟動裝置，不要把每次重新啟動後偶然恢復當作最終修復。記錄變更是否持續，才能判斷是快取影響，還是問題本來就間歇發生。

也要檢查裝置是否啟用其他 DNS 設定描述檔，以及目前 Config 是否覆寫 App 中另一個入口的設定。設定頁顯示已填入某個值，不代表本次請求實際使用該值。請以生效設定與記錄為準，逐項排除覆寫關係；受管理裝置不應自行移除組織提供的網路設定，應先確認管理要求與操作權限。

本章的完成標準是：目標網域能取得合理的解析結果、後續連線能繼續，且切換網路後仍能重現正常狀態。更完整的設定方式請參閱Shadowrocket DNS 設定詳解。若解析正常但交握失敗，請回頭檢查伺服器參數；若只有個別資源遭拒，則返回規則章節，不要繼續更換已確認可用的 DNS。

耗電與更新後異常：檢查背景活動與設定變更

耗電增加與更新後異常常被一起描述，但兩者需要分別蒐集證據。前者要檢查觀察時段內的實際活動，後者則要確認究竟發生了什麼變更。連線維持開啟不代表一直有大量傳輸，系統電池統計中的 App 占比也不能證明所有耗電都由該 App 單獨造成。先建立可比較的使用條件，再判斷是否有持續異常。

讓電池觀察具備可比性

在系統 Settings 的電池統計中檢視時長相近的使用區間，同時記錄螢幕開啟時間、訊號狀況、是否充電及主要工作。弱訊號、影片播放、個人熱點分享與背景同步都可能增加整機耗電。如果一段時間主要待機，另一段時間持續傳輸，兩個百分比不能直接比較；應盡量在相似工作情境下觀察趨勢。

網路延伸功能會承載其他 App 經由隧道的通訊，系統統計的歸屬需要配合總流量判讀。可參照 Data 中的活動情況，確認是否有自己未預期的大量傳輸；但不要只憑統計歸屬就認定某個處理程序在空轉。先找出當時是否有照片同步、內容下載或其他背景請求，再決定是否需要調整 Shadowrocket 設定。

檢查反覆重新連線與診斷負載

持續失敗後反覆重試，可能比穩定維持連線帶來更多交握與網路喚醒。請檢查是否在訊號不穩時頻繁重建連線、是否有過密的測試，以及 On Demand 條件是否反覆觸發。先保存原設定，暫時停止不必要的自動測試與診斷，再以相同時長觀察。不要只為省電就盲目更改伺服器要求的保活設定，否則可能造成閒置後斷線。

詳細記錄適合短時間重現問題，不適合沒有目標地長期收集。記錄中也可能包含網域、位址與其他使用資訊，因此排查完成後應恢復日常設定，並視需要清除敏感記錄。若裝置明顯發熱，先停止高負載工作，待狀態穩定後再繼續比對；若溫度異常持續，還應檢查裝置與系統層面的其他原因。

確認是哪一層發生變更

App 更新、系統更新、訂閱重新整理與遠端 Config 更新是不同類型的變更。回想上次正常使用後進行過哪些操作，並分別記下。App 更新請透過 App Store 核對；系統需求以 App Store 頁面標示為準。訂閱或遠端設定可能獨立於 App 更新而變更，不能只因時間接近，就認定所有異常都是 App 更新造成。

先進行最小幅度的複測：保留目前資料，使用先前確認有效的伺服器與設定，手動建立連線，再存取固定目標。若伺服器未變而 Config 已變更，優先比較規則、DNS 與策略引用；若只有訂閱項目變更，就重新核對欄位。若所有資訊都未變，但系統權限狀態不同，請回到連線開關章節檢查授權與系統記錄。

比較設定時，應聚焦實際欄位差異，而非只看檔案名稱。名稱相同的遠端檔案可能已更新；名稱不同的本機副本也可能內容完全一致。還原先前的副本有助於定位問題，但不代表應長期忽略必要調整。確認某項差異導致故障後，先了解其用途，再決定修正或還原，不要一概刪除所有新設定。

重新安裝不是第一步

重新安裝前，應確認備份範圍、訂閱位址與手動項目的保存位置，並核對 App Store 購買帳戶。App 能重新取得，不代表本機設定會自動完整還原。購買復原請參閱已購項目復原；此流程處理的是 App 取得權，不負責還原自己的服務資訊，也不會改變遠端伺服器的可用性。

若確實需要重新建立環境，應分階段還原：先驗證授權與基本連線，再還原自己已有的有效伺服器，最後才恢復完整規則與其他設定。如此才能找出異常在哪個步驟再次出現。若一次匯入所有備份後直接測試，只能知道問題仍在，無法判斷是舊設定、網路條件或背景行為造成。

本章的完成標準是異常活動減少、常用工作正常，並能在相近使用條件下重複觀察。向他人描述問題時，可提供系統類型、網路類型、變更類別，以及已移除敏感資訊的錯誤片段，不必公開所有備份。若只有 iPad 出現異常，而相同資訊在自己的其他裝置上正常，請繼續閱讀下一章，從裝置網路與設定差異著手。

iPad 專項：檢查網路權限與設定一致性

iPad 與 iPhone 可使用同類型的伺服器資訊，但裝置網路條件不一定相同。常見差異包括只有 Wi-Fi、可使用行動數據、透過個人熱點上網，以及使用受管理的網路設定。不要因為同一個訂閱在一台裝置上正常，就認定另一台裝置的 App 已損壞；先確認兩台裝置實際使用的網路、所選項目與生效 Config，再進行比較。

先確認基本網路確實可用

連上公共 Wi-Fi 後，可能還需完成網路提供的認證頁面。此時狀態列顯示已連線，不代表已能存取外部目標。先關閉連線，完成網路要求的正常認證，並瀏覽一般網頁確認；基本網路恢復後再開啟 Shadowrocket。若認證工作階段已過期，應先重新登入網路，反覆更新訂閱通常無法解決這類問題。

使用行動數據的裝置，應在系統 Settings 中確認 App 是否獲准使用行動數據，以及是否啟用了會限制背景活動的設定。只有 Wi-Fi 的裝置不必尋找不存在的行動數據選項。系統需求與適用裝置以 App Store 頁面標示為準；首次取得與授權步驟可參照iPad 取得說明，不必依另一台裝置的選單位置推測。

名稱相同不代表設定相同

比較兩台裝置時，請逐項確認伺服器位址、連接埠、協定、TLS 與傳輸欄位，而非只比較顯示名稱。訂閱可能在不同時間更新，清單中的同名項目也可能已變更。接著確認 Global Routing 與 Config 的實際選擇；一台使用 Proxy，另一台使用 Config，存取結果不同本來就可能是規則所致，而非裝置效能差異。

大螢幕介面可能以不同方式呈現清單與詳細資料。進入某個設定的詳細頁，不一定代表已將它選為目前使用項目；編輯某個伺服器，也不一定會變更正在使用的另一個項目。編輯完成後，返回實際選取介面並確認生效項目。不熟悉介面名稱時，可閱讀Home、Config 與 Settings 介面名稱對照。

匯入備份後，也要確認實際還原了哪些內容。伺服器、訂閱位址、規則檔案與系統 VPN 授權是不同層的資訊，不能假設複製一個檔案就完成所有步驟。首次連線仍可能需要系統確認。請依「資料存在、已選取項目、設定生效、系統授權、實際存取」的順序驗收，每一步都有明確結果後再繼續。

個人熱點、網路切換與受管理裝置

iPad 透過其他裝置的個人熱點上網時，其網路路徑不一定與熱點提供裝置本身的 App 流量相同。不要把熱點提供裝置的連線狀態，直接當成 iPad 請求也走相同路徑的證明。請在 iPad 上獨立檢查目前網路與連線結果；熱點訊號不穩、提供裝置進入省電狀態或上游網路變更，都可能造成間歇性斷線。

在 Wi-Fi 與行動數據之間切換後，既有連線可能需要重新建立，解析結果也可能暫時沿用舊狀態。先等候切換完成，再發出新的請求；若仍持續失敗，請停止連線後重新建立，並與持續連接同一網路時的結果比較。也要核對 On Demand 條件，避免切換網路時重複觸發，或在預期之外重新連線。

由學校或組織管理的 iPad 可能受到網路政策、憑證、設定描述檔及 VPN 使用規則限制。請先確認裝置管理要求，不要刪除自己無權管理的設定。若同一裝置只有在組織網路下失敗，請記下該網路的情況並交由管理員檢查。伺服器參數、系統權限與組織政策應分別處理，不能以修改認證欄位取代權限確認。

完成交叉驗證並保留還原方式

需要交叉測試時，可讓兩台自己的裝置連上同一個允許使用的網路，使用各自保存的相同有效資訊，依序而非大量並行地存取同一目標。結果不同時，繼續檢查裝置設定；結果相同但更換網路後有變化，則較可能是網路路徑差異。也請留意自己已有服務的並行連線限制，避免測試方式本身觸發遠端限制，造成錯誤結論。

最後依平時的實際使用方式驗證前景存取、短暫鎖定螢幕後的復原，以及正常網路切換。不要只以一次 Connectivity Test 成功作為排查結束。安全保存可用 Config 副本，並記下修正的是權限、參數、規則還是網路條件；日後再次遇到問題時，就能從變更之處開始檢查，不必重做所有步驟。