Shadowrocket
疑難排解指南

01 / 建立連線

開關無法啟動

先確認問題是發生在建立系統連線之前，還是連線建立後立即中斷。前者常見原因包括系統授權未完成、設定未儲存或裝置受到管理限制；後者則需要查看錯誤訊息與連線記錄。不要把所有開關問題都歸因於伺服器故障：遠端無法連線通常會影響要求，不一定會阻止本機連線啟動。記下點擊後的狀況，比連續反覆點擊更有助於判斷。

先完成系統授權

首次在 iPhone 或 iPad 上啟用時，系統會要求允許新增 VPN 設定檔。確認提示是由目前操作觸發，再依系統流程授權；若取消提示，請返回 Shadowrocket 再試一次，並完成裝置身分驗證。接著到系統設定的 VPN 管理位置，確認是否已出現相應設定檔。不同系統版本的設定層級可能不同，可直接在設定中搜尋 VPN，不必依賴固定的選單位置。

若裝置由學校或組織管理，新增網路設定可能受管理政策限制。此時請查閱裝置管理說明，並向管理員確認是否允許使用相關功能，不要反覆刪除設定檔。系統限制、家長監護與組織設定都不是伺服器參數問題。若裝置上還有其他網路連線設定，請先正常中斷目前使用中的連線，再啟動 Shadowrocket，避免混淆兩個服務的狀態。

檢查本機設定與衝突

返回 Home，確認已有可選用的伺服器，且不是只新增了備註、卻漏掉必要參數。接著到 Config 確認目前啟用的檔案確實存在，並檢查最近是否修改過內容。設定語法錯誤、引用不存在的策略名稱或匯入檔案不完整，都可能導致啟動時出現錯誤。優先還原修改前的副本；若沒有副本，請保留原檔，再用內容較精簡的設定進行驗證，不要直接清除所有資料。

若開關短暫開啟後又關閉，先查看錯誤原文，再判斷是設定載入失敗、系統服務啟動失敗，還是外部連線條件造成中斷。暫時停用 On Demand，以手動啟動方式複測，可減少自動條件造成的干擾。測試結束後再還原原有條件。不要一邊開啟自動連線，一邊刪除系統設定，否則設定可能再次出現，讓人誤以為刪除沒有生效。

重建系統連線設定應先備份。先關閉連線，確認訂閱、手動伺服器與 Config 都有可還原的副本，再從系統設定中移除已確認屬於 Shadowrocket 的舊連線設定。重新開啟 App，依提示授權並測試。只處理已確認的項目，不要刪除組織管理資料，也不要把重置所有網路設定當成第一步，因為這可能一併移除已儲存的網路資訊。

電腦與 Android 的啟動流程

若問題其實是 App 無法開啟，請先依安裝與開啟說明處理，而不是進行連線排查。Mac 請先確認 Apple 晶片版或 Intel 安裝檔是否符合裝置規格；若出現無法驗證開發者的提示，請在「隱私權與安全性」中確認來源後選擇「仍要打開」。Windows 遇到 SmartScreen 時，確認檔案來自本站後，前往「更多資訊」並選擇「仍要執行」，不要關閉整體系統防護。

Android 安裝時，請依系統提示允許目前使用的下載工具安裝未知應用程式；安裝完成後可撤銷此權限。這與連線時的 VPN 授權是兩個不同步驟。Linux 若 App 尚未啟動，請先檢查安裝格式、執行權限與桌面環境錯誤訊息。各平台安裝檔均由下載頁透過本站 /dl/shadowrocket/ 提供，請勿以不明檔案取代現有程式。

02 / 要求路徑

連線後無法上網

先進行中斷連線的基準測試。關閉 Shadowrocket，用瀏覽器開啟平常可直接瀏覽的網頁；若仍無法開啟，請先處理 Wi-Fi 登入驗證、行動數據權限或路由器連線。公共網路有時需要先在驗證頁面完成確認，否則其他要求也會失敗。只有基礎網路可用，後續比較 Config、Proxy 與 Direct 才有意義，否則可能把底層網路中斷誤判為規則問題。

透過三種模式縮小範圍

保持網路、裝置、伺服器與目標一致，依序比較 Global Routing 的三種模式。每次切換後重新送出要求，必要時完全關閉目標 App 再開啟，避免沿用既有連線。測試只用來找出差異，不代表某種模式適合長期用於所有情境。尤其是目標原本就無法直接瀏覽時，Direct 失敗本身不能證明基礎網路有問題。

若 Proxy 可以瀏覽、Config 卻不行，請先找出目標網域在 Rule 中命中了哪條規則，不要立刻修改伺服器。常見情況是較前方有涵蓋範圍較廣的 DIRECT 或 REJECT 規則，蓋過後面更精確的項目。規則通常由上而下比對，精確例外應放在較廣泛的規則之前。修改前請確認目前啟用的 Config，避免編輯到未啟用的檔案，之後誤以為規則變更沒有作用。

核對策略與比對順序

以下規則片段用來說明比對順序，不是完整設定檔，也不會建立伺服器。範例網域僅供解釋語法，應依實際目標與現有設定調整。不要為了測試而直接覆蓋整份檔案，尤其要保留原有策略群組與其他必要設定。實際使用的策略也受目前設定結構影響；檢查規則時，請同時確認對應策略確實存在，並指向可用伺服器。

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

DOMAIN-SUFFIX 比對網域後綴，IP-CIDR 比對位址範圍，GEOIP 依位址歸屬判斷，FINAL 則處理前面未命中的要求。這些規則檢查的對象不同，不能只憑規則名稱推斷某項要求一定會命中。目標 App 可能同時連線至登入、資源與內容傳遞網域；只處理首頁網域，不一定涵蓋登入或圖片要求。請從失敗的要求確認目標，再決定要補充的規則範圍。

若所有模式都失敗，但中斷連線後可以正常瀏覽，請檢查連線中使用的 DNS、系統連線衝突，以及 Config 的一般設定。先還原最近可用的副本，並暫停其他同時接管網路的服務後再測試。不要一次修改 DNS、路由與伺服器三個項目，否則即使恢復正常也無法判斷原因。網域解析的獨立驗證方式，請參閱DNS 問題一章。

區分整體問題與單一 App 問題

瀏覽器正常、只有某個 App 失敗時，通常需要另外觀察該 App 的登入、媒體或即時通訊要求。先檢查 App 是否允許使用目前網路，再完全結束後重新開啟。若只有登入失敗，請留意裝置時間、系統憑證錯誤與帳號狀態；若只有區域網路裝置無法使用，請檢查是否有規則將本機位址錯誤送往遠端。不要直接將整份設定改為 Direct 來掩蓋問題。

驗證修復時，至少重做一開始失敗的操作，不要只看連線圖示。能開啟網頁首頁，不代表圖片、登入與檔案傳輸都已恢復；同樣地，一次成功也可能只是命中快取。記下最後有效的設定變更，並撤銷排查時與問題無關的暫時設定。規則類型的進一步說明，請參閱DOMAIN-SUFFIX、GEOIP 與 FINAL 詳解。

03 / 遠端連線

伺服器逾時

逾時表示某次測試未能在等待期限內完成，但無法直接判斷問題發生在哪一層。DNS 解析、連線至伺服器連接埠、協定交握，以及存取測試目標，都可能耗用等待時間。先記下錯誤出現在 Connectivity Test，還是實際 App 要求中，再比較同一伺服器在不同網路下的表現。只看到「逾時」就重新匯入所有訂閱，往往會破壞原本有用的比對條件。

先核對位址與協定欄位

開啟對應伺服器的編輯資訊，逐項比對使用者既有服務提供的原始參數。伺服器位址不要包含網頁路徑、空格或多餘的協定前綴，連接埠應與伺服器端設定一致。QR Code 與分享連結可能包含額外欄位，手動抄寫時尤其容易遺漏。備註只是本機名稱，兩個備註相同的項目也可能指向不同位址；排查時應比較實際參數，而不只是顯示名稱。

協定類型必須與伺服器端一致，不要為了讓測試通過而任意互換。Shadowsocks 的加密方式與密碼、VMess 或 VLESS 的身分欄位、Trojan 的密碼與 TLS 條件，各有不同用途。WireGuard 也涉及金鑰、位址與對端設定；Hysteria2 則須留意驗證與傳輸條件。若欄位缺漏，請向既有服務的維護方確認，不要從其他項目拼湊一組看似完整的參數。

再進行網路交叉測試

保持伺服器參數不變，分別在可用的 Wi-Fi 與行動網路測試。若只有某個網路失敗，應先考慮該網路的驗證狀態、連接埠可達性與傳輸條件，不要立刻認定帳號失效。若同一網路中使用者既有的其他伺服器正常，問題範圍就更可能是單一遠端服務；若所有伺服器都失敗，則應回到基礎網路、系統授權與 DNS 分支繼續確認。

Connectivity Test 的結果只代表所選的測試方法與目標。連接埠連線成功，不代表協定驗證也成功；測試網頁回應正常，也不代表其他目標網站都能正常瀏覽。測試失敗但實際 App 正常時，可能是測試目標無法連線，或測試方法不適用於目前服務。請先用明確的實際要求複核，不要只為了讓清單中的測試結果好看而反覆修改既有伺服器。

伺服器名稱與連線位址可以不同，但兩者都必須符合原始設定。使用 IP 連線時，TLS 仍可能需要指定正確的伺服器名稱；直接將網域換成 IP，可能造成憑證不符。裝置日期與時間錯誤也會影響憑證有效性判斷。遇到憑證相關錯誤時，請先校正時間並核對名稱，不要把略過驗證當成一般修復方式。

判斷後續應由誰處理

若同一筆記錄在多個可用網路下持續失敗，而其他既有記錄正常，請向原有服務的維護方確認位址、連接埠、驗證狀態與服務運作情況。提供已遮蔽的錯誤原文與重現條件即可，不要公開完整分享連結或訂閱網址。若遠端近期更換過參數，請更新對應項目；更新後確認實際選取的是新項目，避免繼續使用清單中的舊記錄。

若網頁能開啟，但大型檔案或特定 App 持續中斷，不要簡單歸類為伺服器逾時。這類狀況也可能與傳輸路徑、UDP 支援或分段條件有關，應在穩定網路下以相同操作比較。進階網路參數應以伺服器端要求為依據，先備份，再逐項調整。沒有明確證據時，不建議同時修改傳輸方式與多項底層參數，以免引入新的相容性問題。

04 / 內容取得

Subscribe 更新失敗

訂閱失敗應拆解為三個問題：網址能否取得、回傳內容能否解析，以及匯入結果是否正確使用。三者的處理方式不同。更新按鈕出現錯誤時，請先保留原有可用項目，不要立刻刪除訂閱。既有伺服器仍能連線，只能證明該連線仍有效，不能保證訂閱介面也能存取；反過來，訂閱更新成功，也不代表其中每一台伺服器目前都能建立連線。

檢查網址與存取條件

從使用者既有服務的管理頁面重新複製完整訂閱網址，確認沒有複製到網頁標題、說明文字或遭截斷的連結。網址中的查詢參數可能包含存取憑證，遺漏一段就可能失效。複製後留意開頭與結尾的空格及換行，不要為了讓網址看起來較短而手動刪除參數。訂閱網址屬於敏感連線資訊，不應貼在公開留言或截圖中。

比較更新時的網路路徑。若中斷連線後可以更新、連線後卻失敗，可能是目前要求路徑或 DNS 條件不適合存取訂閱介面；若情況相反，可先透過使用者既有的可用連線完成更新。測試時只改變連線狀態，並保留同一個訂閱網址，才能確認差異來自路徑。頻繁重複點擊無法修復網址錯誤，還可能觸發介面的存取頻率限制。

若出現與身分驗證、權限或存取頻率相關的錯誤，請回到原有服務頁面確認連結狀態與存取限制。網頁能開啟不代表訂閱介面有權限，管理頁面與訂閱入口也可能使用不同的驗證方式。透過瀏覽器驗證只能協助判斷是否收到回應，不要將回傳頁面轉傳給他人。若頁面要求登入，將網頁網址貼到 Subscribe 通常無法取代真正的訂閱網址。

區分取得成功與解析成功

收到內容後仍匯入失敗時，請檢查回傳內容是否為用戶端支援的訂閱資料，而不是登入頁面、錯誤說明或完整設定檔。有些介面失效時仍會回傳一段可顯示的網頁，因此瀏覽器中看得到文字，不代表格式正確。請依錯誤原文確認問題屬於內容格式、結果為空或欄位缺漏，再向既有服務的維護方說明，不要自行猜測編碼方式。

Subscribe 管理的伺服器清單與 Config 管理的規則設定不是同一類內容。把完整規則檔當成伺服器訂閱匯入，或把伺服器分享資訊當成設定檔啟用，都可能造成解析失敗。請先確認手上的資料用途，再選擇相應入口。匯入完成後，檢查項目是否出現在預期群組、數量是否明顯異常，以及原本手動新增的記錄是否仍然保留。

1. 保留舊訂閱與目前可用的伺服器，並記下這次更新的錯誤原文。
2. 重新複製完整網址，在相同網路下只嘗試一次，確認錯誤是否一致。
3. 依取得、驗證與解析三個階段，選擇相應分支繼續處理。
4. 成功後核對群組與實際參數，重新選取要使用的伺服器並測試要求。

處理更新後的清單變化

更新後出現名稱重複的項目時，先查看所屬訂閱與實際位址，不要依備註批次刪除。不同訂閱可能使用相同命名方式，手動記錄也可能與訂閱記錄同名。清理前請確認目前選取的項目來自哪裡，以及 Config 中的策略是否仍引用有效項目。伺服器端移除某筆記錄後，舊的選取狀態不一定還能用於新連線，請重新明確選取可用項目。

若更新成功卻仍使用舊參數，先核對是否更新了正確的訂閱項目，再確認目前選取的伺服器是否為另一個手動副本。不要反覆匯入同一個連結來判斷問題，這會增加重複來源。較穩妥的方式是保留可辨識的來源說明，每次更新一個訂閱，再比對位址或欄位的變化。任何刪除動作都應等到確認新記錄可用之後再進行。

訂閱與線路的使用條件由使用者既有服務決定，用戶端本身不會取代這些條件。用戶端一次性買斷 ≠ 線路方案。本站不提供、不銷售、不推薦伺服器或訂閱，只說明既有資料的匯入與排錯。若要重新了解正確的匯入順序，請返回快速入門教學；概念與操作上的簡短問題可參閱常見問題。

05 / 效能比對

連線速度緩慢

先把「速度慢」描述成可重現的狀況：網頁首次開啟等待較久、圖片逐張載入、檔案傳輸持續緩慢，還是影片間歇停頓。這些狀況涉及的階段並不相同。首次開啟較慢、之後正常時，優先考慮解析與連線建立；長時間傳輸都很慢時，則需要比較基礎網路、遠端出口與目標服務。不要只憑一次 Connectivity Test 的結果推斷所有使用情境的速度。

建立公平的比對條件

在同一台裝置、同一地點及相近時間，以相同目標進行比對。先關閉其他大量傳輸工作，暫停系統更新與雲端同步，避免把背景流量算進目前要求。接著記錄中斷連線時的表現，再比較使用者既有伺服器之間的差異。目標檔案、App 操作與網路類型都應保持一致，否則一次快、一次慢可能只是內容傳遞節點或快取狀態不同。

Wi-Fi 訊號顯示良好，也不代表連線穩定。距離、同頻干擾、路由器負載與上行頻寬占用都會影響實際表現。可在路由器附近再次測試，再用行動網路交叉比對；若切換網路後同一台伺服器明顯恢復，應優先檢查本機網路。測試時留意行動數據用量，不必反覆下載大型檔案，能重現原問題的最小操作通常已足夠。

比較多台既有伺服器時，也要保持測試方法一致。連線建立時間短，不代表持續傳輸能力一定較好；某個目標回應快，也不代表所有目標都一樣。先選擇兩筆參數明確、可以正常連線的既有記錄，逐一完成相同操作。若所有記錄都只在單一目標上速度緩慢，應優先檢查目標服務本身與對應的要求路徑。

判斷是規則還是傳輸問題

比較 Config 與 Proxy，觀察是否只有依規則處理時才變慢。若 Proxy 正常、Config 卻緩慢，請檢查目標要求是否誤走 Direct、是否引用了與預期不同的策略，以及相關資源網域是否採用不同路徑。一個頁面可能同時送出多個網域要求；主文件正常但圖片緩慢，不能直接推論整台伺服器速度慢，應先找出真正延遲的資源。

若所有要求首次開啟都很慢、之後又恢復正常，可查看連線記錄，確認時間主要耗在解析、交握還是等待目標回應。不要同時更換 DNS 與伺服器來嘗試提速；先固定伺服器，只比對解析條件，再還原原狀測試另一項。某項調整對單一目標有效，不代表適用於整份設定；請保留比對結果，並避免累積來源不明的「最佳化參數」。

即時通訊、部分遊戲或其他使用 UDP 的 App，需求可能與一般網頁不同。網頁能開啟，不代表相關傳輸也已成功。請先確認使用者既有服務是否支援相應傳輸，再檢查用戶端項目與 Config 的相關條件。不要把協定名稱當成速度保證，也不要任意修改 MTU 等底層設定；這類調整需要明確症狀與可重複的測試作為依據。

以最少改動恢復

若伺服器端提供特定傳輸參數，請逐項比對目前記錄，不要參考其他不同服務的設定。若 TLS 或其他交握明顯耗時，先檢查裝置時間、伺服器名稱與網路穩定性。略過憑證檢查不能當成效能調整方式。若目標 App 在網路切換後一直很慢，可結束 App 再重新開啟，排除舊連線仍沿用切換前路徑的可能。

長時間傳輸時若出現週期性停頓，也要觀察裝置是否進入省電狀態、背景活動是否受限，以及無線網路是否切換。電腦透過系統代理連線時，也應確認目標 App 實際採用該路徑，不要只看用戶端是否正在執行。測試結論應寫明「在某網路、某目標、某模式下恢復」，不要籠統認定某項設定在所有裝置上都更快。

06 / 網域解析

DNS 問題

DNS 排查的目標是確認網域是否取得可用位址，以及要求是否採用預期的解析路徑。網域無法開啟不一定是 DNS 故障，後續連線、TLS 與規則也可能造成失敗。先確認錯誤發生在解析階段還是連線階段，再比較系統網路與連線內的狀況。只換成一個看似常見的 DNS 位址，無法證明原因，也可能讓原本可用的區域網路名稱失效。

區分伺服器網域與目標網域

需要解析的對象至少有兩類：代理伺服器本身的網域，以及瀏覽器或 App 正在存取的目標網域。前者失敗可能導致所有代理要求都無法建立；後者失敗則可能只影響部分網站。先確認錯誤指向哪個名稱，不要看到目標網頁失敗就修改伺服器位址。檢查拼寫時請保留完整網域，避免把訂閱網址中的路徑誤認為伺服器名稱。

在基礎網路可用時，先驗證伺服器網域能否解析，再檢查連線內目標網域的解析結果。即使伺服器位址使用 IP，仍可能涉及 TLS 名稱驗證，因此不能單純用 IP 取代網域來繞過所有問題。直接連線至網站 IP 也不是通用的測試方式：許多網站依賴正確的主機名稱與憑證，連線 IP 失敗可能完全正常，不能據此判定網路無法連線。

以下 General 片段示範使用系統 DNS 的設定方式，僅用於說明基準，不是適用於所有網路的完整設定。修改前請檢查目前檔案是否已有同名設定，避免加入互相衝突的定義。保留原始副本後，只調整要比對的項目，再重新建立要求。若實際網路要求特定解析方式，請依該網路與使用者既有服務的說明操作。

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

搭配規則檢查解析結果

以網域為比對對象的規則與以位址為對象的規則，所需的判斷條件不同。DOMAIN、DOMAIN-SUFFIX 與 DOMAIN-KEYWORD 檢查名稱；IP-CIDR、IP-CIDR6 與 GEOIP 則檢查位址。不要把所有失敗都歸因於規則順序，也不要因為有網域規則就認定解析無關。請查看實際要求記錄，確認最終目標、命中規則與採用策略，再決定要檢查哪一層。

若只有特定 Wi-Fi 下的內部名稱或本機裝置無法使用，先確認該網路是否依賴自己的 DNS。將所有解析改走外部路徑，可能會無法識別本機名稱。若要使用印表機、儲存裝置等區域網路資源，請同時確認位址範圍、網路隔離與相應 DIRECT 規則。能找到裝置卻無法連線至服務，也可能是連接埠或裝置權限問題，不要只繼續修改 DNS。

IPv4 與 IPv6 可用性不一致時，解析可能已正常回傳位址，但後續某條路徑仍無法連線。先比對問題是否只出現在特定網路、目標或位址類型，不要在沒有證據時全域停用其中一種位址。網路切換、路由器設定與遠端服務都可能影響結果。排查時請保留系統預設狀態作為對照，再依明確的失敗情境進行有限調整。

處理快取與重複驗證

修改設定後，瀏覽器、目標 App、系統與遠端都可能仍保留舊結果。先結束舊要求，關閉並重新開啟目標 App；必要時中斷後重新連線，再查看新的記錄。只重新整理一次頁面可能仍沿用既有連線，無法確認新的 DNS 設定是否生效。也不要用反覆重新啟動裝置取代判斷：重啟或許能暫時清除狀態，卻無法說明是哪項設定造成問題。

若同一網域只在一台裝置上失敗，先比對裝置時間、系統網路設定與目前的 Config，不要立刻修改整台路由器。若同一網路的多台裝置都出現相同問題，應優先檢查網路提供的解析條件。記錄結果時應包含網路類型、目標名稱、錯誤階段與使用模式，但不必公開完整訂閱或驗證資訊。涉及內部名稱的記錄也應適當遮蔽。

07 / 背景執行

耗電與背景執行異常

先區分耗電統計中的占比與裝置實際耗電量。某個 App 的占比提高，可能只是其他 App 使用減少，不一定代表它的耗電突然增加。請在亮度、訊號、使用時間與網路條件相近的情況下比較，同時留意裝置溫度、背景工作與系統更新。連線承載其他 App 的網路要求時，相關活動也可能出現在統計中，不要只憑單一百分比就認定用戶端異常。

找出持續重新連線與背景要求

連線不穩時反覆建立工作階段，可能增加無線通訊與處理負載。先觀察是否頻繁中斷、切換網路或驗證失敗，再用穩定網路進行比對。若同一台伺服器在固定網路下仍不斷重新連線，應先處理遠端連線問題；此時降低測試頻率只能減少額外活動，無法修復造成重新連線的根本原因。裝置位於訊號微弱的區域時，也應另外記錄。

On Demand 可能在符合條件時自動建立連線，因此手動關閉後又重新連線，不一定代表開關失效。請檢查是否設定了與目前網路相關的條件，以及是否有多個彼此重疊的自動規則。排查時先記下原有條件，再暫停自動連線，以手動方式比對。確認觸發規律後，只還原需要的條件；不要一邊要求持續自動連線，一邊把每次重新建立連線都視為異常。

檢查是否有 App 持續上傳照片、同步檔案、更新訊息或下載離線內容。即使使用者沒有開啟瀏覽器，其他 App 的背景要求仍可能讓連線保持活躍。可暫停這些工作，在相同網路下觀察待機狀態，再逐一恢復。不要一次關閉大量系統功能後就宣稱問題已解決，否則無法判斷真正受影響的是哪個項目，也可能影響日常通知與同步。

減少排查工具本身的干擾

Connectivity Test、持續重新整理與詳細記錄本身也會產生額外要求與寫入。排查完成後，請停止不再需要的重複測試，並依 App 實際提供的選項還原一般記錄層級。若需要保留記錄，請限定重現時段，清楚記下開始與結束操作，再擷取必要片段。長時間累積的記錄不但更難查閱，也可能包含不宜公開的存取目標與連線資訊。

判斷耗電時，盡量選用能涵蓋相似操作的一段觀察時間，不要在剛開啟連線後就比較瞬間變化。充電、裝置發熱與系統背景整理都會干擾結果。可先完成一般使用情境的比對，再觀察待機狀態；若只有高負載傳輸時耗電增加，應一併考量實際傳輸量。若在幾乎沒有要求時仍持續異常，則應著重檢查重新連線、背景工作與診斷活動。

Android 的電池管理可能會在背景限制 App 執行，表現為鎖定畫面一段時間後連線中斷、解鎖後又恢復。先查看系統是否限制 Shadowrocket 的背景活動，再依裝置實際需求調整相關設定，不必一開始就放寬所有 App 的限制。不同系統的選項名稱可能不同，請依目前裝置的說明操作。調整後應比對通知、待機與連線連續性，不要只測試前景網頁。

分別處理溫度與休眠問題

電腦從睡眠狀態喚醒後，網路可能尚未恢復，連線也可能暫時重新建立。先等待系統網路就緒，再重新送出原本的要求，觀察問題是否只在喚醒後發生。若每次睡眠後都必須重新開啟 App，請記錄休眠前後的網路類型與錯誤，並檢查網路介面是否更換。不要長期禁止裝置進入睡眠來掩蓋問題，這會改變耗電基準，也不代表修復了連線恢復流程。

裝置明顯發熱時，先停止高負載傳輸，讓裝置恢復正常溫度後再判斷效能。溫度管理會影響處理速度，速度變慢與耗電增加可能是同一負載的不同表現。若中斷連線後仍持續發熱，請檢查系統與其他 App 的活動，而不是繼續修改規則。電池健康度、充電環境與無線訊號也會影響結果，應與用戶端設定分開考量。

08 / 更新後復原

更新後異常

更新後出現問題，不一定代表 App 更新是唯一原因。同期也可能發生訂閱內容變更、Config 更新、系統升級或網路切換。先列出最近一次正常使用到首次失敗之間發生的變更，再決定排查順序。不要同時刪除 App、清空訂閱並重置網路，這會失去可供比對的原始狀態，也可能讓局部問題變成需要重新設定的複雜狀況。

先保留資料，再確認問題範圍

備份目前的 Config、手動伺服器與必要的訂閱資訊，並確認副本已儲存在本機可找到的位置。備份檔案可能包含密碼、身分欄位或完整訂閱網址，請存放在安全的位置，不要公開上傳。接著確認問題是 App 無法啟動、連線立即中斷、所有要求都失敗，還是只有特定目標失敗。不同範圍分別對應啟動、授權、連線與規則等排查分支，不應一律靠重新安裝解決。

若更新 App 後首次啟動出現新的系統授權提示，請先確認提示來源並完成必要授權，再次測試。系統更新可能改變原有權限狀態，即使連線設定仍在，也不代表權限條件完全相同。若只有某個 Config 無法載入，請保留原始錯誤，並嘗試啟用最近可用的本機副本；若副本可正常執行，應優先比對設定內容，不要繼續更換伺服器。

若 Subscribe 與 App 最近都更新過，先核對目前選取伺服器的實際參數是否變更，再確認 Config 中的策略引用是否仍有效。舊名稱遭移除、群組變更或項目替換，都可能看起來像更新後的連線故障。使用一筆使用者既有且參數明確的項目測試，可減少清單變更造成的影響，但不要在沒有備份時刪除整個訂閱來源。

依平台檢查安裝與開啟權限

iPhone 與 iPad 的 App 更新透過 App Store 完成，系統需求以 App Store 頁面標示為準。重新安裝前，請先確認備份與原購買帳號；刪除 App 可能同時移除本機設定，商店中的已購記錄不等於設定備份。核對正版時，請確認官方圖示、開發者 Shadow Launch Technology Limited 與 App ID 932747118，詳細步驟請參閱正版核對。

Mac、Windows、Android 與 Linux 的新版安裝檔請從本站下載頁取得，頁面中的動態入口會指向 /dl/shadowrocket/。Mac 請先在「關於這台 Mac」確認 Apple 晶片或 Intel；Windows 依頁面說明選擇安裝檔；Linux 則依發行版選擇相應格式。更新遇到問題時，不要混用其他架構或來源不明的檔案，以免引入獨立的啟動問題。

首次開啟遭到阻擋時，Mac 可確認來源後前往「隱私權與安全性」選擇「仍要打開」；Windows 則在 SmartScreen 的「更多資訊」中確認後選擇「仍要執行」；Android 依提示允許目前使用的下載工具安裝未知應用程式，完成後再視需要撤銷權限。若 Mac 提示 App 已損壞，請先確認下載完整且來源正確，再參閱安裝頁中針對此提示的處理方式，不要關閉整體安全設定。

xattr -cr /Applications/Shadowrocket.app

上方命令僅適用於已確認檔案來源且 App 位於該路徑時，用來處理 Mac 檔案擴充屬性，並非修復所有啟動錯誤的通用命令。操作前應先關閉 App，並確認路徑與實際安裝位置相符。Linux 的 AppImage 還需要執行權限；deb 與 rpm 則應透過相應的套件管理流程檢查相依項目。完成安裝階段的處理後，再回到連線與要求測試，不要混淆兩類問題。

驗證復原並整理回報內容

完成一次變更後，重新執行最初失敗的操作，並與更新前可用的副本比較。若只有新增設定失敗，保留差異即可；若所有設定在同一網路下都失敗，再檢查系統網路與權限變更。不要只因主畫面能開啟就認定已恢復，仍應測試連線、解析與目標 App。修復後請區分暫時排查檔案與正式啟用檔案，避免下次誤選測試副本。

回報內容應包含裝置系統、安裝來源、問題發生階段、錯誤原文與最精簡的重現步驟。若需提供版本資訊，請從目前 App 實際顯示的位置讀取，不要依舊截圖猜測。遮蔽伺服器憑證與訂閱連結後，再提供必要記錄。Mac 與 Windows 的晶片版本選擇及首次開啟流程，請繼續閱讀電腦安裝與系統開啟權限說明。

09 / 裝置專項

iPad 專項排查

iPad 排查仍依照網路、伺服器、設定與要求的順序，但還需要區分僅支援 Wi-Fi 的機型、支援行動網路的機型，以及多工狀態下的 App 行為。不要因為 iPhone 上備註相同的項目能連線，就直接判定是 iPad 故障；兩台裝置可能使用不同網路、不同 Config 或不同實際參數。先統一測試條件，再比較裝置差異，才能避免把環境差異誤認為平台問題。

讓兩台裝置具備可比較的條件

若要與 iPhone 比較，請先讓兩台裝置連接同一個可用 Wi-Fi，選取參數一致的既有伺服器，確認啟用的 Config 內容相同，並使用相同的 Global Routing。接著在瀏覽器中送出相同要求。只比對伺服器名稱並不足夠，因為同名項目可能來自不同訂閱或更新批次；只比對設定檔名稱也不夠，還應核對實際規則內容與最近的修改狀況。

僅支援 Wi-Fi 的 iPad 無法直接關閉 Wi-Fi 來比對行動網路，可在條件允許時改連另一個已知可用的網路。若使用手機熱點，請注意這是新的網路路徑，不是對原 Wi-Fi 的重複測試。支援行動網路的機型也應檢查數據服務是否正常，以及目標 App 是否允許使用相應網路。所有比對都應先確認基礎網路可用，再啟動連線。

分割畫面或其他多工狀態下，目標 App 可能仍維持先前的工作階段。切換 Global Routing 後，請先結束進行中的要求，再重新開啟目標頁面；必要時結束 App 後重試。不要因為分割畫面中的舊頁面仍顯示內容，就認定網路正常，那可能只是快取。反過來說，背景 App 暫時沒有更新，也不一定代表連線中斷，應送出新的實際要求確認。

處理鎖定畫面與網路切換

若問題只在鎖定畫面後出現，請記錄解鎖時系統網路是否已恢復、用戶端連線是否仍存在，以及重新開啟目標 App 後能否恢復。部分 App 在背景停止活動，與系統連線是否可用是兩回事。先用瀏覽器建立新要求，再判斷是否只是單一 App 的工作階段復原問題。反覆點擊開關可能讓仍在復原中的連線重新建立，反而中斷原本即將完成的復原流程。

校園、辦公室或公共 Wi-Fi 可能要求定期重新驗證，也可能逐台裝置授權。iPhone 已完成驗證，不代表 iPad 自動具備相同條件。中斷連線後試著開啟驗證頁面，確認網路使用權限，再重新連線 Shadowrocket。受組織管理的 iPad 也可能限制 VPN 設定或網路行為，請向管理員確認允許的使用方式，不要刪除無法辨認的管理資料。

若要使用本機印表機、儲存裝置或其他區域網路服務，請確認 iPad 與目標裝置位於允許互通的網路，再檢查 Config 對本機位址的處理方式。區域網路權限、網路隔離與規則路徑都可能影響結果。先確認中斷連線時能否使用，再比較 Config 與 Direct；不要為了讓一台本機裝置恢復使用，就把所有要求永久改為直連，精確調整更容易維護。

購買項目還原與資料移轉

iPhone / iPad 版在 App Store 售價為 $2.99，採一次性付費；兩種裝置可使用同一個購買帳號還原已購 App。Mac、Windows、Android 與 Linux 版免費。請分開理解不同平台的價格與取得方式，電腦版不屬於行動商店的購買流程。iPad 的系統需求以 App Store 產品頁標示為準，不要依另一台裝置能否安裝來推斷。

更換裝置或重新安裝時，請先確認登入的是原購買帳號，再從已購項目尋找 App。還原 App 不會自動補齊所有手動設定，移轉前仍需保存使用者既有的訂閱資訊與 Config。若 App 已還原但清單是空的，應按資料移轉問題處理，而不是再次購買。詳細步驟請參閱已購項目還原說明；首次重新匯入則依教學完成。

最後依原本情境驗收：連線後建立新的網頁要求、開啟原先失敗的 App、鎖定畫面後解鎖再測試，並在需要時驗證區域網路服務。記下哪一步恢復、哪些條件仍會觸發問題，比只說「iPad 不能用」更容易繼續定位。若只有概念上的疑問，可查看常見問題；若有明確錯誤，則返回本頁對應章節，沿著相同證據繼續排查，不要重新清除所有設定。