Shadowrocket 疑難排解
連線、規則與 DNS

一、開關無法啟動：先檢查系統連線權限

先區分開關無法操作、開啟後立即關閉，以及開關維持開啟但請求失敗。這三種現象屬於不同層面。前兩種應優先檢查系統權限、網路延伸功能與設定是否有效；第三種表示連線入口可能已建立，接著應檢查節點、路由與 DNS。不要只憑頂端狀態圖示判斷是否已能瀏覽目標網站，也不要因開關曾關閉一次，就直接認定伺服器無法使用。

保留現況，確認基本網路

先記下目前的網路類型、所選伺服器、Global Routing 的值，以及是否啟用 On Demand。儲存目前的 Config，並記錄最近一次成功連線後變更過的項目。接著關閉 Shadowrocket，以瀏覽器開啟平時可直接瀏覽的網站。如果關閉後同樣無法連線，請先處理 Wi-Fi 登入頁、行動數據權限、路由器或系統網路限制；排查用戶端連線前，裝置本身必須能連上網路。

公共 Wi-Fi 可能需要先完成網頁驗證。連上無線網路不代表驗證已完成，系統也可能保留先前的登入結果。保持用戶端關閉，開啟系統提供的驗證頁面，確認網路可正常使用後再嘗試連線。若裝置安裝了由公司或學校管理的描述檔，請先查看相關網路政策；不要刪除用途不明的管理項目，也不要試圖繞過裝置管理員設定的權限。

檢查 VPN 設定與同時連線情況

1. 返回 Home，確認已選取自己可用的伺服器，而不只是匯入了尚未選取的清單。
2. 啟動連線，留意系統是否顯示新增 VPN 設定的授權提示；依系統指示完成確認。
3. 前往系統設定中的 VPN 管理位置檢查連線記錄，確認沒有其他連線反覆接管。
4. 暫時關閉 On Demand，手動連線一次，分別確認手動連線與自動觸發條件。

如果先前拒絕了授權，重新操作時可能需要先回到系統設定確認狀態。只有在已儲存設定，且明確知道哪個項目屬於 Shadowrocket 時，才考慮移除舊的連線記錄，再由 App 重新建立。移除系統連線記錄與刪除訂閱是不同操作，但仍應先備份，避免同時調整多個位置而無法判斷原因。一開始不要重置整部裝置的網路設定。

開關立即關閉時的檢查順序

先查看是否出現明確的權限或設定錯誤，再觀察開關是在點選後、切換網路後，還是喚醒鎖定畫面後關閉。如果每次啟動都失敗，請檢查目前設定是否能正常讀取，以及必要的伺服器欄位是否空白。如果只在切換網路時發生，暫停自動連線條件，固定使用一種網路重試。每次只觀察同一個操作；連續切換多個節點會掩蓋真正的觸發條件。

伺服器設定錯誤可能導致連線後的請求失敗，但不應把所有開關問題都歸因於協定。記下介面顯示的完整錯誤訊息，優先檢查權限與設定讀取。如果 App 提供相關診斷記錄，只需複製錯誤類別與發生步驟；訂閱網址、驗證欄位與伺服器識別資訊都屬於敏感資料，提供給支援人員前應先遮蔽。也請檢查截圖是否包含 QR Code、完整網址或個人帳號資訊。

如果重啟 App 後仍可穩定重現問題，請先儲存工作，再重新啟動裝置，並使用相同網路與設定驗證一次。重新啟動只用於排除暫時性的系統狀態，並不能直接得出故障原因。重現記錄應能回答「在哪個步驟失敗、出現什麼提示、關閉用戶端後是否恢復」這三個問題；這些事實比「無法連線」這種籠統描述更有助於排查。

二、已連線但無法上網：區分節點與規則

開關維持開啟後，先將問題縮小為所有請求都失敗、只有部分網域失敗，或只有一個 App 失敗。分別選一個可直接瀏覽的網站、一個需要透過既有伺服器連線的目標，以及實際發生問題的 App 進行驗證。測試目標由使用者自行決定，並在測試期間保持不變。頻繁更換網站會混淆目標服務狀態、快取與路由差異，讓結果難以判讀。

使用 Global Routing 建立對照

Global Routing 的設定、代理與直連分別對應 Config、Proxy、Direct。Config 依目前設定中的規則決定路徑；Proxy 用於集中驗證代理路徑；Direct 用於觀察直連路徑。切換模式是診斷手段，不是建議長期使用某種模式。測試期間固定伺服器，關閉舊網頁後重新發出請求，避免已建立的連線繼續沿用先前的路徑。

如果 Proxy 可以存取而 Config 失敗，請優先檢查命中規則、使用的策略與 DNS 結果，不要立刻重建伺服器。如果兩種模式都失敗，接著檢查伺服器驗證、協定參數與網路條件。如果 Direct 可以存取某個網站而 Proxy 失敗，表示該網站在目前直連條件下可連線，但仍不能證明所有代理請求都有問題。每項結論都應限定在當時的網路、目標與模式下。

檢查規則順序與策略目標

進入 Config，確認目前生效的檔案就是剛才修改的檔案。檔案顯示在清單中，不代表已經選用；遠端更新後的副本也可能與手動編輯的副本不同。接著依規則順序檢查目標網域：精確網域、後綴、關鍵字與最終規則可能將請求導向不同策略。通常由優先比對到的規則決定結果；後方正確的規則無法修正前面已發生的錯誤比對。

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

以上僅說明規則語法，並非通用設定建議。第一行會將指定網域及其子網域交由 PROXY 處理；第二行拒絕精確網域；私有網段範例交由 DIRECT 處理；FINAL 則處理先前未命中的請求。複製前請先理解目標範圍，並確認符合自己的網路環境。尤其不要直接將範例中的拒絕規則、地區規則與最終策略替換到正在使用的完整檔案中。

如果規則指向自訂策略群組，還要確認群組內有可用伺服器，而且目前實際選取的項目符合預期。群組名稱正確不代表其中選取的項目也正確；自動選擇與手動選擇也可能得到不同結果。排查時可暫時固定選用自己清單中一個可用節點，減少策略變動造成的干擾。驗證完成後，恢復原本的選擇方式，並記下這次成功的條件。

只有一個 App 失敗時

App 可能重複使用長連線、使用快取位址，或同時請求多個網域。先完全結束該 App 再重新開啟，觀察主畫面、登入與媒體載入是否分別失敗。某個網頁正常，不代表 App 所依賴的所有網域都正常。如果診斷記錄提供請求路徑，請逐一核對失敗網域；不要只為了修復一項資源，就將整份規則改成範圍過廣的關鍵字比對。

區域網路服務還須檢查本地網路權限、裝置是否位於同一網路，以及請求使用的是網域名稱還是私有位址。能上網卻無法開啟印表機或家用儲存裝置，不等於外部伺服器連線失敗。只保留經目標請求驗證有效的修改；如果無法確認是哪條規則生效，請還原備份，從最小差異重新開始，避免累積彼此衝突的暫時規則。

三、節點逾時與速度慢：分開測試連線與傳輸

節點逾時表示某項測試或請求未能在等待時間內完成，不能只憑這個結果斷定伺服器已停止運作。速度慢則可能發生在解析、交握、第一個位元組或持續傳輸階段。先描述具體狀況：是 Connectivity Test 沒有結果、網頁遲遲未載入，還是頁面開啟後下載緩慢。不同階段需要檢查的項目不同，延遲數值也不能直接代表下載速度。

確認伺服器資訊與測試意義

在自己已有的伺服器資訊頁面逐項核對位址、連接埠、協定與驗證欄位。不要只憑節點名稱判斷地區或協定，名稱只是備註。檢查複製時是否包含空格、遺漏字元或錯誤連接埠；如果資訊來自訂閱，先保留原有記錄，避免將手動修改過的節點與下一次訂閱更新的結果混淆。必要時從相同來源重新匯入一筆供對照，不要覆蓋整份清單。

解讀 Connectivity Test 結果時，應一併考量所選的測試方式。某些測試可能只涵蓋連線或特定目標，不能取代實際使用請求。測試逾時但網頁正常時，應檢查測試目標與方式，不必因此刪除可用節點；測試成功但網頁失敗時，則繼續檢查目標路徑、規則與 DNS。測試與實際請求使用的目標不同，結果不一致並不矛盾。

整組核對協定欄位

Shadowsocks 的加密方式與密碼必須和伺服器一致；VMess、VLESS 的驗證資訊與傳輸設定也必須相符；Trojan 的密碼及 TLS 相關條件不能憑經驗填寫。如果設定使用額外傳輸路徑、Host 或 Server Name，這些欄位各有用途，不能因字面相似就互相替換。伺服器位址用於找到連線入口，憑證驗證所用的名稱則可能不同，應以自己既有服務提供的參數為準。

發生憑證或交握錯誤時，先檢查裝置時間、憑證對應名稱，以及參數是否經過手動修改。不要藉由關閉憑證驗證來掩蓋錯誤；這會改變安全條件，也會讓後續結果失去對照基準。Hysteria2 等依賴特定傳輸條件的協定，還須配合目前網路狀況判斷。協定名稱相同，不代表所有伺服器都使用相同的連接埠、驗證格式或傳輸選項。

交叉比對網路與節點

1. 固定相同目標與伺服器，分別透過 Wi-Fi 和行動網路發出新請求，並記錄差異。
2. 保持網路不變，只切換到自己既有清單中的另一個節點，再請求相同目標。
3. 分別觀察首次開啟、頁面資源載入與持續傳輸，不要將三者合併成單一的「速度」。
4. 在相近時間重新測試，關閉背景大型檔案同步，排除裝置本身正在占用頻寬的情況。

如果只有某種網路失敗，應優先調查該網路至伺服器的路徑、無線訊號或存取限制；如果只有某個節點失敗，則應優先檢查該節點及其伺服器端狀態。多個節點同時失敗，也可能是共用同一入口或同一組參數，不能因此認定整個用戶端異常。交叉測試的目的是縮小範圍，不是證明某一方一定有故障。

速度下降時避免毫無依據地調整參數

先比較同一裝置在關閉用戶端時的基本傳輸狀況，再確認代理路徑是否額外變慢。無線干擾、行動網路訊號、伺服器負載、目標網站限速與背景同步都可能造成變化。測試時不要同時進行多項高流量工作，也不要反覆重新整理而產生大量並行請求；這會改變測試條件，也可能使伺服器暫時進入限制狀態。

如果小型網頁正常但大型檔案傳輸停滯，先記錄問題是否會在不同目標重現，再檢查目前網路與協定的傳輸條件。MTU 等參數會影響封包傳輸，但沒有適用所有網路的通用數值；缺乏證據時不應連續嘗試不同數字。需要進一步尋求協助時，提供網路類型、協定類別、失敗階段與已完成的對照測試，不要提供密碼或完整訂閱網址。

更多節點觀察方式請參閱延遲測試、地區與協定類型。結論應記為「在此網路與此節點的組合下，同一目標速度變慢」，而不只是記下一個延遲數值。可重現的條件有助於區分偶發壅塞與持續性的設定問題，也能避免把暫時恢復誤認為某項無關修改生效。

四、訂閱失敗：先檢查回傳內容，再檢查節點

訂閱更新是取得並解析清單的操作；節點連線則是使用清單中某個項目的操作。更新失敗不代表所有已儲存節點立即失效；已有節點仍可連線，也不代表訂閱網址仍能正常使用。先保留現有清單，記下更新提示、失敗時間與當時的網路路徑，不要因一次更新失敗就清空設定。若要還原已刪除的訂閱，可能還需要重新核對來源資訊。

檢查連結完整性與內容類型

從自己使用的服務提供位置重新複製訂閱網址，確認開頭、路徑與查詢參數完整無缺。通訊軟體、換行或手動編輯都可能讓網址少了一段；有些介面只顯示縮短文字，不能把畫面上的省略形式當成完整連結。訂閱網址通常含有驗證資訊，應像密碼一樣妥善保管；不要貼到公開貼文、線上解析頁面或他人提供的檢測工具。

單一分享連結與訂閱網址並不相同。ss://、vmess://、vless://、trojan:// 通常用來表示單一伺服器資訊，訂閱則提供可更新的集合。將單一節點內容放入錯誤的匯入入口，可能導致格式無法辨識或只取得一個項目。兩者的差異請參閱分享連結與訂閱連結格式說明，再回到相應入口操作。

依失敗階段處理

如果有 HTTP 狀態資訊，請保留狀態碼與簡短的錯誤類別。驗證失敗、請求過於頻繁與伺服器端異常需要不同處理方式；只修改用戶端 DNS 無法修正所有回應錯誤。網址能在瀏覽器開啟，也不能證明回傳的是有效清單，因為瀏覽器可能顯示帳號登入頁、說明頁或存取提示。不要將這些頁面儲存後當作節點設定匯入。

處理更新路徑的相依關係

有些訂閱網域在目前的直連網路下無法連線，而用戶端目前選用的節點又已失效，導致更新與連線互相依賴。先確認現有清單中是否還有自己可用的節點，再觀察更新請求實際採用的路徑。不要假設切換 Global Routing 後，所有更新請求都會自動採用相同方式；實際狀況仍須依目前設定、可用的診斷資訊與測試結果確認。

如果清單中沒有可用節點，可以在不洩露網址的情況下，切換到原本就能連線至訂閱來源的網路，或向自己的服務來源確認訂閱狀態。不要尋找來源不明的臨時節點來完成更新。手動重試應間隔一段時間；連續觸發無法修正驗證或格式問題，還可能遇到請求頻率限制，讓原本的故障與新限制同時發生。

更新後仍須驗證清單

更新成功後，先檢查節點數量變化、目前選取項目與協定欄位，再連線至其中一個既有項目，驗證目標請求。服務來源可能會調整名稱、入口或驗證資訊，先前的手動選取可能已不再指向相同項目。單一節點的本機修改也可能在訂閱更新後被取代，因此手動備註、訂閱內容與完整 Config 應分開管理，不要視為同一份備份。

如果訂閱網址已在公開場合外洩，請向原服務來源詢問更換驗證資訊的方法，再更新用戶端儲存的網址。只刪除聊天訊息不代表舊網址已失效。排查記錄只保留必要的網域部分、錯誤類別與操作順序；完整查詢參數不應出現在截圖或共用文件中。確認恢復正常後再安排自動更新，避免原因未明時讓背景反覆發出請求。

五、DNS 問題：檢查解析結果與實際路徑

DNS 會將網域名稱轉換為連線所需的位址。網域無法開啟、首次載入緩慢、只有部分資源失敗，都可能與解析有關，但也可能是 TLS、目標服務或規則問題。先確認錯誤發生在解析前還是解析後：取得位址後仍然逾時，就不應只把注意力放在 DNS 上。解析成功只代表取得候選位址，不能證明該位址在目前網路與路由條件下可連線。

分別記錄網域、位址與規則

記下失敗的完整主機名稱，不要只記網站名稱。同一服務的登入、圖片與介面可能使用不同網域；主頁面能開啟而圖片失敗，可能對應完全不同的請求。如果診斷記錄能顯示解析結果，也請記下位址類型與發生時間。不要公開完整網址中的驗證參數，也不要為了驗證而將私人內部網域送交不受信任的解析服務。

進入目前的 Config，核對是否設定自訂 DNS、網域對應或其他解析相關選項。先確認生效中的檔案，再檢查規則；只編輯未啟用的副本不會改變請求結果。如果使用遠端設定，也應確認更新是否取代了本機設定。比較前保留原始檔案，並且一次只修改一項解析設定，否則即使恢復存取，也無法判斷是哪項變更生效。

了解規則為何可能觸發解析

DOMAIN、DOMAIN-SUFFIX 與 DOMAIN-KEYWORD 會依網域資訊比對；IP-CIDR、IP-CIDR6 與 GEOIP 則涉及位址範圍或位址歸屬。網域請求遇到位址類規則時，在某些設定條件下可能需要先進行解析才能判斷。了解這點有助於說明「規則看起來正確，但首次請求很慢」的現象：等待可能發生在位址判定階段，而不是代理連線階段。

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
FINAL,PROXY

範例中的 no-resolve 表示不要只為了該位址規則主動觸發網域解析；它不會停用所有 DNS，也不會強制所有網域走特定路徑。它無法修復解析伺服器無法連線，也不能保證區域網路名稱可解析。規則範例只說明語法關係；實際部署還須考量既有規則順序、內部網路範圍與目標服務，不宜將整段內容當作萬用修復方案。

IPv4、IPv6 與網路切換

同一網域可能回傳多種位址，而目前網路對 IPv4 與 IPv6 的連線能力可能不同。如果只在某個無線網路下失敗，請記錄該網路的位址環境，再與另一種網路比較。不要因某次停用 IPv6 後恢復存取，就認定所有環境都應停用 IPv6；這只表示位址選擇或相應路徑值得進一步檢查。調整系統網路條件前，應先保存原始值並確認如何還原。

Wi-Fi 與行動網路可能提供不同的解析條件；切換後，快取與既有連線也可能繼續存在。每輪比較都應重新發出請求，必要時先結束目標 App 再重新開啟；連續點選重新整理不一定會觸發新的解析。不要只在網址列輸入某個 IP 取代所有驗證，因為 HTTPS 憑證、虛擬主機與服務路由通常都依賴網域名稱，直接存取 IP 的結果可能造成誤判。

內部網域與快取範圍

家用路由器、公司網路與區域網路服務可能使用只在本地網路有效的名稱解析。改用其他 DNS 後，這些內部名稱可能失去解析來源，即使外部網站正常，本地服務仍可能異常。先確認裝置是否仍在相同區域網路，以及相關網域是否需要本地解析。不要把內部網域失敗簡單歸因於 PROXY 規則不夠廣；代理路徑不一定能存取相應的私有位址。

瀏覽器、App、系統與用戶端都可能保留部分快取。變更設定後，應區分「舊連線仍可使用」與「新請求已恢復」兩種情況。測試完成後，再次連線至先前失敗的目標，並檢查實際命中的路徑。如果只有在某項解析條件下能穩定恢復，請記錄該條件與適用網路，不要將一組解析位址套用到所有裝置。解析設定是否正確，應以目前網路中的實際請求驗證。

六、耗電與流量異常：觀察持續活動的來源

排查耗電增加時，首先需要建立可比較的條件。裝置溫度、螢幕亮度、訊號強度、背景同步與實際傳輸量都會影響電池表現，不能只憑一次電量下降就判定 Shadowrocket 異常。先查看系統電池用量統計中的同一時段活動，再記錄當時是否下載檔案、播放媒體或頻繁切換網路。比較不同日期時，使用時間與工作量不同，也會讓結果無法直接對照。

區分流量歸屬與活動來源

代理連線會承載其他 App 的資料，系統統計的歸屬方式可能讓部分網路活動集中顯示在相關處理程序中。這不代表用戶端自行產生了同等規模的請求。先檢查相片備份、檔案同步、App 更新與媒體自動播放是否正在執行，再觀察暫停這些工作後流量是否下降。只看統計排名，無法判定實際發出請求的 App。

如果介面提供 Data 或連線記錄，可用來觀察活動是否持續，但請留意統計方式、重設時間與系統統計可能有所不同。累計流量、即時速率與某個 App 的背景活動並非相同指標。排查前記錄起始狀態，固定觀察區間後再比較變化；不要把累計數值當成目前瞬時流量，也不要用不同時間範圍的數字證明異常。

檢查重複連線與失敗重試

訊號微弱、頻繁漫遊或節點不穩定，都可能讓 App 反覆嘗試建立連線。表面上沒有成功載入頁面，背景仍可能持續交握、解析與重試。固定使用訊號穩定的網路，選用自己已有的可用節點，再觀察閒置時是否仍有大量重複活動。如果問題只在切換網路時發生，應優先記錄切換順序與自動連線條件，不要立刻修改所有協定設定。

On Demand 用於依條件觸發連線，不代表所有情況都需要維持相同的觸發方式。暫時關閉後手動連線，有助於判斷是否不斷出現觸發、離線、再連線的循環。測試前記錄原有條件，結束後恢復設定；不要長時間反覆開關來下結論，因為開關操作本身會產生額外連線活動，也可能讓背景 App 重新發出請求。

建立可重現的閒置對照

1. 讓裝置完成大型檔案工作，在相近亮度與相同網路下使用，先記錄正常狀態。
2. 儲存設定，使用一個已驗證可用的節點，暫停不必要的手動測試。
3. 鎖定螢幕後，觀察系統統計中的背景活動，並記下是否發生網路切換或大量推播的時段。
4. 接著在關閉用戶端時進行相同觀察，比較現象是否仍然存在；不要將結果推論至其他網路。

對照期間避免同時更新訂閱、切換規則或大量執行 Connectivity Test。測試請求本身會產生網路活動，密集檢測也可能讓裝置不再處於閒置狀態。如果使用自動更新功能，請確認更新間隔符合實際需求；無須為了確認清單有效而持續手動重新整理。若更新失敗，先查明原因；反覆重試可能增加背景活動，卻無法排除問題。

溫度、充電與連線條件

充電、系統還原備份、索引整理與高負載 App 都可能讓裝置發熱。明顯過熱時，應先停止高負載工作，讓裝置恢復正常運作條件後再排查；不要一邊充電、一邊連續下載來比較用戶端耗電。網路訊號微弱時，裝置維持連線也可能更耗電；此時改用穩定網路後有所改善，不應誤記為某條規則的效果。

如果關閉用戶端後仍持續發熱或快速耗電，請繼續檢查系統與其他 App；如果只在某個設定、節點或自動連線條件下重現，請保存這組最小重現條件。不要為了降低統計數值而任意關閉憑證驗證或刪除必要規則。可靠的處理結果應同時符合：正常請求可完成、閒置活動下降，而且恢復原設定後問題能獲得說明。

七、更新後異常：核對變動，不要直接歸因

「更新後發生」只表示時間先後，不代表更新就是原因。App 更新、系統升級、訂閱重新整理、遠端 Config 變更與伺服器調整，可能在相近時間發生。先列出這些變動，標明哪些已確認、哪些只是推測，再檢查最接近故障的操作。不要憑印象填寫版本號或更新時間，也不要把網路偶爾恢復當成已找到問題。

保留更新前狀態與目前狀態

操作前匯出目前設定，保存自己使用的訂閱來源，並記錄目前選取的節點與 Global Routing。備份檔可能包含伺服器驗證資訊，請存放在自己能控管的位置。如果有更新前的備份，先比較規則順序、策略目標、DNS 與協定欄位，不要一開始就覆蓋現有檔案；目前狀態本身也是排查差異的重要證據，覆蓋後可能無法重現。

先驗證基本路徑：關閉用戶端後能否直接上網、手動連線能否維持、Proxy 能否存取固定目標，以及 Config 是否出現不同結果。透過相同的最小測試，重新將更新後的問題歸類至權限、伺服器、規則或解析層面。即使缺少更新前的完整記錄，也能避免只圍繞「新版本異常」反覆猜測，而忽略實際的失敗點。

辨別設定更新與 App 更新

訂閱更新可能取代伺服器參數，遠端 Config 更新則可能調整規則與策略；這兩種變更不需要 App 同時更新。檢查本機手動修改是否被遠端內容覆蓋、目前生效的檔案是否改變，以及原先選取的策略群組是否仍有相同項目。如果只要還原一個節點就能恢復，應繼續比較該節點的資訊，不要以來源不明的內容取代整份設定檔。

系統升級後，還應重新檢查 VPN 權限、網路連線記錄與相關的自動連線條件。如果系統顯示明確的授權要求，請依提示完成；如果只是舊的連線狀態不一致，先中斷連線，再手動連線一次。重新建立系統連線記錄前應先備份，而且只處理確認屬於 Shadowrocket 的項目。刪除所有網路設定會擴大影響範圍，不適合作為第一步檢查。

重新安裝前先確認能否還原

重新安裝不是備份方式。刪除 App 前，請確認能還原 Config、訂閱與必要的伺服器資訊，也要知道哪些內容只儲存在本機。確認匯出的檔案可讀，並記下手動規則與節點備註；尤其不要假設購買記錄會自動還原服務設定。如果只有一個目標網站無法使用，應優先檢查該目標與規則，通常不需要先移除整個 App。

需要取得安裝檔時，請使用下載頁的平台分區。iPhone / iPad 版透過 App Store 取得，系統需求以 App Store 頁面標示為準；Mac、Windows、Android 與 Linux 版請使用本站提供的安裝檔入口。iPhone / iPad 版為 $2.99 一次性付費，其他上述平台免費。請勿將用戶端取得方式與使用者既有線路的服務狀態混為一談。

重新安裝時的系統允許設定

桌面版與 Android 安裝檔沒有程式碼簽章，首次開啟時可能遭系統阻擋。確認檔案來自本站後，Windows 使用者可在 SmartScreen 的「其他資訊」中選擇「仍要執行」；macOS 使用者可在「隱私權與安全性」中確認遭阻擋的項目，並選擇「仍要打開」；Android 使用者可依系統提示允許目前來源安裝未知的 App，完成後可撤銷該來源的安裝權限。不同系統的文字可能略有差異，操作前請確認檔案正確。

macOS 若提示 App 已損毀，請先確認安裝完整且來源正確，再依安裝允許設定說明檢查隔離屬性；Linux 則依發行版與套件格式檢查安裝結果，AppImage 需要執行權限。不要為了啟動單一檔案而全域關閉系統防護，也不要把 App 無法啟動與連線後請求失敗當成同一故障。兩者發生在不同階段，應分別驗證。

整理出可供複查的結論

恢復後重新執行一開始失敗的操作，確認目標請求、規則命中與網路切換都符合預期。記錄真正有效的差異，例如重新選取可用節點、還原遭覆蓋的規則或補上授權，而不是只寫「重新安裝後解決」。如果仍然失敗，將操作整理成幾個可重複的步驟，並附上已遮蔽敏感資訊的錯誤訊息；版本資訊請從 App 實際介面查閱，不要憑記憶補寫。

八、iPad 專項：購買、移轉與橫向畫面檢查

iPad 的連線排查仍依照權限、伺服器、規則與 DNS 的順序進行，但購買項目還原、橫向畫面配置與設定移轉，容易造成額外誤判。先確認裝置已安裝 Shadowrocket，再檢查 Home 中選取的伺服器、目前的 Config 與 Global Routing。另一台裝置可以連線，不代表這台裝置的條件完全相同；網路、權限、設定副本與連線記錄都可能不同。

還原購買項目與還原設定是兩回事

iPhone / iPad 版在 App Store 以 $2.99 一次性付費取得；Mac、Windows、Android、Linux 版免費。已購買 iPhone / iPad 版的使用者，在 App Store 登入原購買帳號後，可於已購項目中尋找並重新下載；實際下載狀態以商店記錄為準。App 的購買資格不代表訂閱、節點與 Config 會自動移轉；安裝完成後仍須檢查本機資料。

在商店中核對開發者 Shadow Launch Technology Limited、官方圖示與 App ID 932747118。系統需求以 App Store 頁面標示為準。如果搜尋不到 App，請先確認帳號的商店地區與已購項目，不要把搜尋結果缺少誤認為用戶端連線故障。同帳號購買與畫面配置的說明，請見iPad 共享購買與橫向介面差異。

橫向分欄時確認實際選取的項目

在橫向或分欄畫面中，清單選取項目與右側詳細資料可能同時顯示。看到某個節點的詳細資料，不一定表示它已成為目前連線使用的節點；開啟某個 Config 的內容，也不一定代表該檔案正在生效。修改後請返回連線入口，重新確認目前選取項目，並以實際請求驗證。不要只根據停留在哪個詳細資料頁面，就推斷連線使用的伺服器或規則檔案。

分割畫面、視窗大小與系統顯示設定都會改變可見區域。找不到按鈕時，先還原為單一 App 全螢幕，確認介面位置後再切回原本的使用方式。操作尚未完成時，不要連續點選清單中的多個項目，尤其編輯、選取與連線可能分別位於不同區域。排查記錄應寫清楚點選了哪個項目、儲存位置，以及最後連線入口顯示的狀態，而非只記下截圖中的某一欄。

依資料類別移轉，並分階段驗證

移轉前分別確認伺服器或訂閱、Config、手動規則與必要備註都已儲存。完整 Config 與單一分享連結涵蓋範圍不同；匯入一個節點不會自動帶入所有規則。優先使用 App 實際提供的匯入、匯出功能，並只在自己能控管的裝置之間傳送；傳輸檔案與 QR Code 可能包含驗證資訊，不應儲存在公開相簿、共用文件或公開聊天記錄中。

在 iPad 上先匯入自己已有的一個可用節點，以 Proxy 驗證固定目標，再啟用準備移轉的 Config。這樣可以區分伺服器可用性與規則問題。如果一開始同時匯入大量設定並啟用自動連線，發生失敗後就很難判斷是哪個環節造成。測試成功後，再補齊其他項目，並確認訂閱更新是否覆蓋剛才的手動修改。

同一 Wi-Fi 下仍須比較網路條件

兩台裝置顯示相同的無線網路名稱，不代表權限相同或使用相同路徑。訪客網路隔離、區域網路存取權限、位址類型與快取都可能不同。無法存取家用儲存裝置或區域網路服務時，先確認裝置所在網路、相關權限與目標位址，再檢查 DIRECT 規則。如果 iPad 不支援行動數據，就不要假設還有另一種網路可供對照；可以改用自己能存取的其他無線網路。

如果鎖定螢幕後喚醒便發生問題，請記錄喚醒時是否切換網路、自動連線是否重新觸發，以及舊的 App 連線是否仍被沿用。先重新發出請求，再檢查系統 VPN 狀態，不要直接刪除移轉後的所有資料。如果只有某個 App 發生問題，返回第二章檢查該 App 依賴的網域；如果所有新請求都失敗，則依第一章與第五章重新檢查權限和解析條件。

如果仍無法判斷原因，請整理一份已遮蔽敏感資訊的記錄：裝置類型、網路類型、失敗步驟、錯誤訊息、關閉用戶端後的狀況，以及已完成的單一變因對照測試。不要附上完整訂閱、QR Code 或密碼。帶著這些資訊回到相關章節重新檢查，通常比重新匯入所有設定更容易縮小範圍；如果尚未完成初次連線流程，可返回使用指南逐步驗證。