Shadowrocket 故障排查大全

建立排查基準：開關無法開啟或立即復位

先區分「開關失敗」與「伺服器連線失敗」

Shadowrocket 的 Home 開關負責要求系統建立 VPN 設定。開關無法維持開啟，通常發生在流量尚未抵達伺服器之前；伺服器逾時則表示系統通道已建立，但後續連線伺服器的程序未完成。兩者的處理路徑不同。觀察時不要只看網頁能否開啟，也應同時記錄 Home 開關狀態、系統狀態列中的 VPN 標記、目前選取的伺服器，以及 Global Routing 顯示的模式。若點選開關後立即復位，先檢查系統授權與設定衝突；若開關維持開啟但網頁失敗，再進入下一章檢查伺服器、DNS 與規則。

首次開啟或系統重新確認權限時，裝置可能顯示加入 VPN 設定的授權視窗。完成裝置身分驗證後，Shadowrocket 才能讓系統建立對應設定。若先前拒絕授權，可進入系統 Settings 查看是否存在 VPN 設定，再返回 Shadowrocket 重試。此時不需要反覆刪除應用程式；先確認權限鏈結，可避免把系統授權問題誤判為伺服器問題。裝置受到組織管理、內容限制或家長控制時，也可能限制 VPN 設定變更，此時應查看系統提供的明確提示，並由裝置管理方確認政策。

清理同時發生的連線競爭

Apple 平台在同一時間只能讓符合系統條件的網路延伸功能接管對應流量。若系統 Settings 中存在其他正在連線或反覆自動喚起的 VPN 設定，Shadowrocket 的開關可能停留在「連線中」後復位。排查時先關閉其他 VPN 設定，再暫時關閉 Shadowrocket 的 On Demand，手動操作一次 Home 開關。若 On Demand 的觸發條件與目前 Wi-Fi、行動網路或網域條件不一致，也可能造成剛關閉連線後系統又重新發起，或手動開啟後被條件重新評估的情況。

關閉 On Demand 只用於建立排查基準，並不代表該功能本身異常。手動連線恢復後，應逐一檢查觸發條件：目前網路名稱是否歸入正確分支、行動網路條件是否符合預期、條件之間使用的是「同時符合」還是「任一符合」，以及規則是否引用已刪除的設定。每修改一項後切換一次網路或等待系統重新評估，不要同時修改多項條件，否則無法判斷是哪一項使連線恢復。

使用最小變數法恢復連線

基準測試只應保留一個資訊完整且已知可用的伺服器，關閉 On Demand，暫時不要修改協定參數，並先在穩定的 Wi-Fi 下連線。若失敗，再切換至行動網路進行一次對照。同一設定在兩種本地網路上的結果不同，表示問題較可能位於路由器、網路接入或 DNS 環境；兩種網路都失敗，才繼續檢查伺服器位址、連接埠、驗證資訊與協定參數。不要在一次測試中同時更換伺服器、DNS、Global Routing 與規則檔案，因為多個變數同時變化會掩蓋真正原因。

如果需要重新核對 App Store 中的購買紀錄、應用程式 ID 或開發者資訊，可前往正版核驗三要素。Shadowrocket 是一次買斷的用戶端，但用戶端一次買斷 ≠ 線路方案；連線所需的訂閱或伺服器資訊應由使用者既有的服務來源提供，應用程式購買狀態不會決定某台伺服器是否可用。

開關已開啟，但網頁與應用程式無法上網

先用三種 Global Routing 模式劃定範圍

Global Routing 的 Config、Proxy、Direct 是定位「連線成功但沒有網路」的主要分界。Config 依 Config 中的規則順序決定每個請求的去向；Proxy 讓流量統一經過目前伺服器；Direct 讓流量直接存取。測試時先記住原本的模式，再短時間切換至 Direct。若 Direct 也無法存取，問題可能位於系統通道、本地網路或 DNS，而非代理伺服器。若 Direct 正常、Proxy 失敗，應檢查伺服器可達性與參數。若 Proxy 正常、Config 失敗，重點檢查規則順序、策略名稱與 FINAL 結果。

切換模式只用於診斷，不應長期以 Proxy 取代修復規則問題。若 Config 異常，應回到規則本身處理。規則會由上至下匹配，命中第一條後便停止繼續判斷，因此範圍較窄的 DOMAIN、DOMAIN-SUFFIX、IP-CIDR 通常應放在較寬泛的規則之前，FINAL 則放在末尾。過早出現的 REJECT、DIRECT 或廣泛的 DOMAIN-SUFFIX，都可能讓後續預期規則永遠沒有命中機會。

建立一份易讀的最小規則集

以下片段示範規則順序，不代表真實服務資訊。策略名稱必須與 Config 中現有策略或應用程式支援的結果名稱一致。測試時可使用自己既有設定中的正確策略名稱替換 PROXY，並確保 FINAL 位於最後。區域網路位址使用 DIRECT，可避免存取路由器或本地裝置時繞行；明確的網域規則放在 GEOIP 和 FINAL 之前，方便從 Data 或請求紀錄核對命中結果。

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

若匯入 Config 檔案後出現找不到策略、規則無效或整組流量失敗，應核對逗號分隔欄位是否完整、策略名稱大小寫是否一致、是否混入不可見字元，以及引用的策略組是否確實存在。不要只因檔案能夠匯入就判斷設定有效；匯入只表示文字已被接受，不能證明其中每個伺服器、策略組與規則都能執行。可先保留少量規則進行驗證，再逐段恢復複雜規則。

檢查系統時間、網路登入頁面與 IPv6 差異

裝置日期與時間明顯不準時，TLS 憑證驗證可能失敗，表現為多數 HTTPS 頁面無法開啟，但少量本地頁面仍可存取。應在系統 Settings 中啟用自動設定日期與時間，再重新連線。飯店、校園或公共 Wi-Fi 常要求先完成網路登入頁面驗證；連線 Shadowrocket 前可暫時關閉開關，使用瀏覽器存取一般頁面以觸發登入，完成後再開啟。若 Wi-Fi 正常而行動網路失敗，或反之，應分別檢查兩種網路下的 DNS 與 IPv6 可達性，不要把單一接入網路的限制歸咎於所有伺服器都不可用。

某些應用程式會快取舊連線。修改 Config、DNS 或伺服器後，先在 Shadowrocket 中斷開再重新連線，然後完全結束出現問題的應用程式並重新開啟。仍然失敗時，可切換一次飛航模式，讓系統重建網路介面。重新啟動裝置應放在權限、模式、規則、DNS 與網路對照之後；它能清除暫時狀態，但無法修復錯誤的伺服器參數或規則順序。

如果問題只發生在「開關已開啟」的情況，可繼續閱讀伺服器狀態、Global Routing、DNS 與規則逐項排查，其中提供更精簡的現場檢查清單。

伺服器逾時、握手失敗與 Connectivity Test 異常

把「逾時」拆分為位址、連接埠與協定三個階段

逾時並非單一原因。首先需要將伺服器位址解析為 IP，其次建立至連接埠的傳輸連線，最後依 Shadowsocks、VMess、VLESS、Trojan、HTTP、SOCKS5、WireGuard 或 Hysteria2 等協定完成驗證與握手。前一階段失敗，後一階段便不會發生。Connectivity Test 的結果適合用來比較同一時間、同一本地網路中的多台既有伺服器，但一次失敗不能證明伺服器永久不可用；本地網路波動、DNS 暫時失敗、伺服器維護或參數不一致，都可能產生相似結果。

先核對 Add Server 或既有項目中的 SERVER、連接埠、密碼或識別資訊、協定類型及傳輸相關欄位。複製資訊時常見的錯誤包括位址前後多出空格、遺漏連接埠、大小寫改變、把備註當成伺服器位址，以及 QR Code 或剪貼簿內容已經過期。參數應與使用者既有服務來源提供的資訊逐項一致，不應憑經驗替換加密方式、傳輸類型或 TLS 相關值。協定名稱相同，也不表示參數可以互換。

用網路對照判斷是本地阻斷還是遠端異常

在 Wi-Fi 下逾時時，先中斷 Shadowrocket，確認一般網頁可以存取，再切換行動網路測試同一台伺服器；之後也可使用另一個已確認可用的 Wi-Fi 複測。如果同一台伺服器只在某個接入網路中失敗，優先檢查路由器 DNS、IPv6、訪客網路隔離、機構網路政策或需要登入的網路入口網站。如果在不同接入網路下都逾時，而同一訂閱中的其他伺服器正常，則更可能是該伺服器位址、連接埠或遠端狀態異常。若所有伺服器在所有網路中同時失敗，應回頭檢查訂閱內容、系統時間、DNS 與設定是否被整體替換。

測試順序應固定：先測試目前伺服器，再測試同一設定中的另一台伺服器，然後更換本地網路，最後才修改協定參數。如此可形成兩個維度的對照。只更換伺服器後恢復，表示系統通道與應用程式權限基本正常；只更換本地網路後恢復，表示伺服器至少在另一個網路中可達；所有組合都失敗，則需要檢查共同因素，例如錯誤 DNS、過期設定、系統 VPN 狀態或服務來源的整體變更。

理解延遲測試與實際可用性的界線

延遲數值只是特定測試請求在當時網路條件下的往返表現，不等同於網頁載入、影片傳輸或大型檔案的吞吐量。某台伺服器能夠回傳測試結果，也不代表所有目標網域都能依目前規則存取；反過來，測試請求受到遠端限制時，實際業務連線仍可能有回應。因此應將 Connectivity Test 與真實請求紀錄結合：查看請求是否發出、命中了哪個策略、回傳的是逾時、拒絕連線還是名稱解析失敗。不同錯誤提示對應不同層級，不能一律用「更換伺服器」處理。

WireGuard 與 Hysteria2 等協定還可能依賴更具體的金鑰、位址、MTU 或傳輸參數。出現能連線但部分頁面卡住時，不要先任意調高或調低所有參數；應先確認服務來源提供的完整欄位，再使用預設值或明確指定的值測試。MTU 不合適可能表現為小型請求正常、大型回應停滯，但相同症狀也可能來自 DNS、路徑品質或伺服器端限制，因此需要透過切換本地網路和比較其他伺服器交叉驗證。

若確認伺服器資訊已由服務來源變更，應依其最新資訊更新既有項目或訂閱。本說明站只解釋用戶端中的匯入、測試與排查方法，不提供伺服器或訂閱內容。

Subscribe 匯入或更新失敗

區分位址無法存取、內容無效與更新未生效

訂閱失敗至少可分為三類。第一類是 Subscribe 位址無法存取，常見表現為逾時、DNS 失敗或 HTTP 狀態異常；第二類是位址能夠回傳內容，但格式不是 Shadowrocket 可識別的資料；第三類是介面提示更新完成，但伺服器清單沒有預期變化。排查時需要先確認失敗發生在哪一步，而不是反覆刪除再重新加入。使用者應使用自己既有服務來源提供的完整訂閱位址，並注意連結中的查詢參數通常屬於位址的一部分，複製時不能截斷。

可先在 Subscribe 項目中核對位址首尾是否多出空格、協定標頭是否完整、字元是否被聊天軟體換行，以及連結是否已由服務來源替換。範例位址只能用來理解結構，不能產生真實伺服器：

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

若同一位址先前能夠更新、現在突然失敗，應先更換本地網路測試，再確認系統日期與 DNS。公共 Wi-Fi 的登入頁面、路由器過濾或暫時性的解析異常，都可能影響訂閱請求。若位址在不同網路下都回傳明確錯誤，應聯絡原服務來源確認位址狀態；不要透過不明頁面轉換訂閱內容，也不要把包含存取憑據的連結提交給陌生工具。

檢查更新策略與本地項目的關係

訂閱更新可能新增、修改或移除由該訂閱管理的伺服器。使用者手動建立的 Add Server 項目與 Subscribe 管理的項目，排查時應分開觀察，避免把本地手動項目誤認為訂閱更新結果。更新前記下訂閱群組中的伺服器數量，並不是可靠的長期驗證方式，因為服務來源可能調整內容；更有效的做法是記錄一個明確的伺服器名稱或更新時間提示，更新後查看該訂閱項目的狀態，並確認目前選取的伺服器是否仍然存在。

如果更新後 Home 仍選取已被移除或參數已變更的舊項目，應重新選擇訂閱中的有效伺服器，再執行 Connectivity Test。若 Config 中的策略組依伺服器名稱引用項目，名稱變更也可能造成策略缺漏。此時不僅要看伺服器清單，也要檢查 Config 的策略組成員與規則結果。訂閱更新成功只代表資料已寫入，不代表原本 Config 對新資料的引用仍然有效。

格式錯誤與局部資料問題的處理

當回傳內容中只有個別項目的欄位異常時，應用程式可能略過部分內容，或使整個匯入結果不符合預期。不要自行猜測缺少的欄位。先保留原 Subscribe 項目與目前可用的設定，向原服務來源核對其提供的格式是否適用於 Shadowrocket。若服務來源同時提供 QR Code，可使用 Scan QR Code 匯入，但 QR Code 只是另一種傳遞方式，掃描結果仍應核對伺服器位址、協定與備註，不能把「能夠掃描」視為「參數一定正確」。

Import from Cloud JSON 適合匯入使用者自行保存的相應資料，但雲端檔案可能早於目前設定。匯入前要區分還原備份與更新訂閱：備份會將某個時間點的本地結構帶回裝置，訂閱更新則從原位址取得目前內容。使用舊備份覆蓋現有資料後，應重新檢查 Subscribe 位址、伺服器選擇、Config 與 On Demand 條件，不要只確認伺服器清單是否出現。

訂閱不是 Shadowrocket 的購買內容。用戶端一次買斷 ≠ 線路方案；App Store 購買用於取得用戶端，Subscribe 中的資料由使用者既有的服務來源負責。若要遷移至新裝置，可搭配閱讀設定備份與換機還原步驟，先還原應用程式購買，再核對本地設定與訂閱狀態。

速度慢、載入停頓與不同應用程式表現不一致

依本地網路、伺服器、線路與協定逐層測量

速度慢需要先定義具體現象：是首次開啟頁面時等待很久、持續傳輸速度低、只有圖片或影片卡頓，還是只有某個應用程式異常。不同表現對應 DNS、連線建立、吞吐量、封包遺失與規則命中等不同層級。排查前先關閉正在進行的大量同步或下載，固定一個測試目標與時間段，先在 Shadowrocket 關閉時測量本地網路，再開啟並測試目前伺服器。只比較不同時間、不同網站的主觀感受，無法得出可靠結論。

第一層是本地 Wi-Fi 或行動網路。若關閉 Shadowrocket 後本地網路本身就有明顯封包遺失、頻繁切換網路或訊號微弱，後續連線會放大波動。靠近路由器、關閉品質較差的 Wi-Fi 後改用行動網路，或在另一個穩定網路下複測，可以判斷基礎接入是否為主要原因。第二層是目前伺服器與路徑。使用 Connectivity Test 比較使用者既有設定中的多台伺服器，並實際開啟同一個目標頁面；不要只依一次延遲結果選擇，因為低延遲不等於持續吞吐量穩定。

第三層是協定與參數。不同協定在不同網路條件下的表現可能不同，但參數必須來自既有伺服器資訊，不能為追求速度而任意改變驗證、傳輸或 TLS 設定。若服務來源提供多個適用項目，可以在相同網路、相同時間、相同目標下進行對照。第四層是規則：同一應用程式的網域可能被分配到不同策略，頁面主體走 PROXY，而圖片網域走 DIRECT 或 REJECT，就會出現文字先顯示、資源長時間空白的情況。

從請求紀錄識別規則分流

在 Data 或相應的請求紀錄中，觀察問題發生時的網域、命中規則與最終策略。重點查看主網域、靜態資源網域、登入網域與內容分發網域是否走向一致。若某些網域被 DOMAIN-KEYWORD 過度寬泛地匹配，應改為更精確的 DOMAIN 或 DOMAIN-SUFFIX；若 GEOIP 提前命中導致結果與預期不同，可將明確的網域規則放在它之前。修改規則後中斷並重新連線，同時重新開啟目標應用程式，避免舊連線繼續沿用先前路徑。

速度問題不宜透過長期將所有流量切換至 Proxy 來掩蓋。Proxy 可用於確認「規則是否參與問題」，一旦確認 Proxy 正常、Config 緩慢，應回到 Config 修正規則。若兩者都慢，而 Direct 正常，則檢查伺服器與路徑；若三種模式都慢，應先檢查本地網路、DNS 與裝置狀態。這個三模式對照與第二章相同，但本章關注的是可用連線中的效能差異，而非完全無法存取。

處理大型回應停頓與 MTU 線索

小型網頁正常、大型圖片或持續傳輸容易停頓時，可以將 MTU 或路徑分片問題列為候選，但不能直接認定。先比較不同本地網路與不同伺服器：只有某個網路組合出現，表示路徑特徵較明顯；所有組合都出現，則還要檢查協定參數、裝置省電狀態與目標服務。對於明確提供 MTU 設定的配置，應以使用者既有服務資訊或協定要求為基準，一次只調整一個值，並記錄調整前後相同的測試結果。盲目反覆更改只會造成更多不穩定。

測試至少應涵蓋兩個時間點，避免將短暫壅塞當作穩定結論。記錄本地網路類型、伺服器名稱、Global Routing、目標應用程式與現象發生階段，再比較結果。若同一台伺服器在不同時間的表現差異很大，可能與遠端負載或路徑變化有關；若所有伺服器只在某個 Wi-Fi 下變慢，應優先處理路由器與接入網路。更完整的四層檢查可參閱伺服器、線路、協定與本地網路逐級排查。

DNS 解析失敗、結果異常與部分網域無法開啟

辨識 DNS 故障，不要籠統歸類為斷網

DNS 負責將網域名稱轉換為可連線的位址。典型 DNS 故障包括：輸入網域無法開啟，但直接存取已知 IP 有回應；部分網域持續提示找不到伺服器；切換 Wi-Fi 後同一網域恢復；首次請求很慢，之後在快取期間正常。TLS、規則 REJECT、伺服器逾時也可能產生近似表現，因此需要結合請求紀錄中的錯誤類型判斷。若紀錄顯示網域解析失敗，應先處理 DNS；若已取得目標 IP 但連線逾時，則應轉到伺服器或路徑層排查。

Shadowrocket 中 DNS 的實際行為會受到 Config、系統網路、IPv4、IPv6 以及規則設定影響。排查時先記錄目前的 DNS 設定，不要直接清空所有欄位。暫時使用已確認適合目前設定的 DNS 方案進行測試，並分別在 Wi-Fi 與行動網路下觀察。若只在特定 Wi-Fi 下失敗，路由器下發的 DNS、網路登入頁面或區域網路劫持可能參與問題；若所有網路都失敗，應核對 Config 是否引用不可達位址、格式錯誤的設定，或與目前規則不一致的解析路徑。

理解 no-resolve 與 IP 規則的關係

IP-CIDR、IP-CIDR6 和 GEOIP 會根據目標 IP 判斷。某些規則帶有 no-resolve 時，表示不要為執行該規則額外觸發網域解析；這可減少不必要的查詢，但也代表只有在已有 IP 資訊時規則才能匹配。若誤以為所有 IP 規則都會主動解析網域，就可能錯誤判斷規則為何未命中。DOMAIN、DOMAIN-SUFFIX 與 DOMAIN-KEYWORD 直接依網域匹配，通常應放在需要精確分流的 IP 類規則之前。

[Rule]
DOMAIN,api.example.com,PROXY
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
GEOIP,CN,DIRECT
FINAL,PROXY

上述區域網路規則用於說明匹配方式。若裝置需要存取區域網路中的路由器、儲存裝置或列印服務，DIRECT 通常可避免流量被送往遠端，但實際存取仍受 Wi-Fi 隔離與區域網路權限影響。區域網路 IP 無法存取不一定是 DNS 問題，因為直接使用 IP 時並未進行網域解析。應先區分存取目標是網域還是 IP，再看失敗發生在哪一層。

處理快取、IPv6 與加密 DNS 的交互影響

修改 DNS 後，舊結果可能仍存在於應用程式、系統或連線快取中。應中斷 Shadowrocket，重新連線，再完全關閉目標應用程式並重新開啟；必要時切換一次飛航模式。不要連續更換多個 DNS 後立即下結論，因為快取會使前後結果混在一起。若某網域同時提供 IPv4 與 IPv6，而目前網路的 IPv6 路徑不穩定，可能出現解析成功但連線緩慢或逾時。此時應比較不同接入網路，並查看失敗請求使用的位址類型，而不是簡單認為 DNS 沒有回傳結果。

設定加密 DNS 時，還要考慮其伺服器網域如何首次解析，以及存取該 DNS 端點的路徑是否受到目前規則影響。如果 DNS 端點本身只能透過尚未建立的路徑存取，就可能形成啟動依賴。排查時可暫時恢復到設定明確支援的基礎方案，確認一般解析正常，再逐步加回加密 DNS 設定。每次變更後測試一個先前穩定失敗的網域和一個正常網域，才能判斷是整體解析故障還是單一網域結果異常。

耗電異常、背景活動與更新後異常

判斷耗電來自持續流量還是連線重試

Shadowrocket 處於連線狀態時，需要處理經過系統網路延伸功能的流量；耗電會受到裝置訊號、傳輸量、協定、規則複雜度、日誌記錄與連線穩定性共同影響。先進入系統 Settings 的電池用量頁面，比較觀察時段內 Shadowrocket 的前景與背景活動，同時檢查是否有照片同步、雲端備份、媒體播放或其他應用程式持續傳輸。網路流量由其他應用程式產生時，Shadowrocket 可能因處理這些連線而顯示背景活動，因此不能只看到占比就判斷用戶端本身異常。

若裝置發熱並伴隨伺服器反覆逾時、Home 狀態頻繁切換或 On Demand 不斷觸發，應重點檢查連線重試。先關閉 On Demand，選擇一台已確認可用的伺服器，在穩定 Wi-Fi 下手動連線並觀察。恢復正常後，再檢查 On Demand 條件是否在 Wi-Fi 與行動網路切換時互相衝突。訊號較弱時，行動網路為維持連線會增加耗電；同一設定在穩定 Wi-Fi 下正常、弱訊號環境下明顯發熱，表示接入網路也是重要變數。

縮小日誌、規則與背景工作的影響

排查期間可減少不必要的長時間詳細記錄，並查看 Data 中是否有某個應用程式持續產生大量請求。異常重試的網域可能每隔很短時間重複出現，既增加流量，也會持續喚醒網路。此時應先確定請求來自哪個應用程式、命中了哪條規則、回傳何種錯誤，再處理規則或目標應用程式的背景行為。不要直接使用寬泛的 REJECT 阻斷所有相似網域，因為過寬的 DOMAIN-KEYWORD 可能影響正常功能並產生新的重試。

複雜規則檔案本身通常不是唯一的耗電原因，但大量重複、互相覆蓋或順序不合理的規則會增加診斷難度。可複製目前的 Config，建立精簡版本，只保留必要的區域網路規則、明確網域規則、GEOIP 與 FINAL，觀察相同時段的連線穩定性。如果精簡後問題消失，再分段加入原有規則，定位引發重複請求或錯誤分流的部分。這種方法比一次刪除全部設定更安全，也保留了還原路徑。

更新後先檢查狀態遷移，不要立即重建全部設定

透過 App Store 更新後若出現開關失敗、伺服器無法選取、規則行為改變或介面狀態異常，先重新啟動 Shadowrocket 的連線：關閉 Home，等待系統 VPN 標記消失，再重新開啟。接著確認目前伺服器、Global Routing、Config、DNS 與 On Demand 是否仍是更新前使用的項目。系統更新也可能重新評估網路延伸功能權限，因此應查看系統 Settings 中的 VPN 設定是否存在且可用。系統要求與相容範圍以 App Store 頁面標註為準。

如果設定內容仍在，但只有某個訂閱或伺服器失敗，應依訂閱與逾時章節處理，不要把所有問題都歸因於應用程式更新。若所有設定都出現相同問題，可先匯出或記錄目前重要設定，再重新啟動裝置與網路。只有在確認本地資料已有可還原的備份、購買紀錄可從 App Store 找回、訂閱位址也仍由使用者保存時，才考慮大範圍重建。貿然清除資料會把暫時的系統狀態問題變成設定還原問題。

Shadowrocket 唯一的取得入口是 App Store 產品頁。可在頁面中核對開發者 Shadow Launch Technology Limited 與應用程式 ID 932747118；應用程式更新也由 App Store 管理，不應以網路上的版本描述取代商店頁面資訊。

iPad 專項：分割畫面、鍵盤、區域網路與換機還原

先確認 iPad 上的購買與設定來源

iPad 上的 Shadowrocket 與 iPhone 使用相同的 App Store 產品頁。同一個 Apple ID 已購買時，可在 App Store 的已購項目中尋找並還原，具體相容範圍與系統要求以 App Store 頁面標註為準。首次開啟仍需要系統授權加入 VPN 設定。若 iPhone 正常而 iPad 開關無法開啟，應分別檢查 iPad 的 VPN 權限、裝置管理政策、On Demand 條件與目前網路，不要假定兩台裝置的系統網路狀態完全相同。

透過 iCloud、Config 匯出或 Import from Cloud JSON 還原設定後，應將「檔案已出現」與「設定可以連線」分開驗證。先核對伺服器項目與 Subscribe 位址，再選擇目前伺服器，檢查 Global Routing 和 DNS，最後開啟 Home。若備份時間較早，訂閱管理的項目可能需要重新更新；若策略組引用的伺服器名稱已經變更，也要同步檢查 Config。完整順序可參閱設定備份與換機遷移說明，其中同樣適用於從舊裝置遷移至 iPad 的核對流程。

處理分割畫面、多視窗與鍵盤造成的介面差異

iPadOS 的分割畫面與多視窗會改變可用寬度，Home、Config、Settings 或 Data 的清單與詳細資訊可能採用不同排列。看不到某個按鈕時，先退出較窄的分割畫面狀態或展開側欄，不要依照 iPhone 的固定位置尋找。連線狀態由系統網路延伸功能維持，關閉某個 Shadowrocket 視窗不等於中斷 Home；應回到應用程式或系統 VPN 狀態確認。多個視窗同時開啟時，修改 Config 後要確認目前查看的是同一份設定與最新狀態。

使用外接鍵盤貼上 Subscribe 位址、SERVER、密碼或規則時，注意全形標點、智慧引號、自動空格與換行。規則語法需要英文逗號，策略名稱必須與現有名稱一致。長按複製的內容若來自帶格式文字，可能夾帶不可見字元；出現看似完全相同卻無法連線的情況，可在純文字環境中重新核對，再逐欄位輸入。Scan QR Code 匯入後也應檢查結果，不應只看掃描過程是否完成。

區域網路裝置存取與 Wi-Fi 情境

iPad 常用於存取區域網路儲存裝置、列印設備或家庭服務。若開啟 Shadowrocket 後區域網路資源失效，先使用 IP 位址測試，區分名稱解析與網路可達性。確保常見區域網路網段存在 DIRECT 規則，並放在 FINAL 之前；若 IP 可存取而本地域名失敗，應檢查路由器 DNS 或本地名稱解析。若 IP 也無法存取，檢查 Wi-Fi 是否啟用訪客隔離、裝置是否位於同一子網路，以及目標裝置是否允許目前網路存取。

[Rule]
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
DOMAIN-SUFFIX,example.com,PROXY
GEOIP,CN,DIRECT
FINAL,PROXY

在學校、會議場所或飯店 Wi-Fi 中，iPad 可能需要先完成登入頁面驗證。先關閉 Home，開啟瀏覽器觸發網路登入，確認一般頁面可以存取後再連線。若分割畫面中的瀏覽器沒有出現登入頁面，可暫時全螢幕開啟，或在系統 Wi-Fi 詳細資訊中重新加入網路。登入狀態到期後，可能表現為 Shadowrocket 仍顯示已連線，但所有請求都失敗，此時應再次檢查網路入口網站，而不是立即修改伺服器參數。

建立 iPhone 與 iPad 的獨立對照

同一設定在 iPhone 正常、iPad 異常時，應讓兩台裝置連線至同一個 Wi-Fi，選擇同一台伺服器、同一份 Config 與相同的 Global Routing，再比較結果。若只有 iPad 失敗，檢查其系統時間、DNS、VPN 設定、裝置管理與私有網路相關設定；若兩台裝置同時失敗，更可能是伺服器、訂閱或目前 Wi-Fi 的共同問題。對照時不要讓一台使用行動網路、另一台使用 Wi-Fi，否則結論會同時受到接入網路影響。

若 iPad 具備行動網路功能，還應分別測試 Wi-Fi 與行動網路，並注意 On Demand 條件是否針對兩種網路設定了不同動作。切換網路後，等待系統狀態穩定再測試，不要在 VPN 標記仍變化時連續點選 Home。只有 Wi-Fi 失敗時，檢查路由器和登入頁面；只有行動網路失敗時，檢查行動訊號、行動數據權限與對應的 On Demand 條件；兩者都失敗時，再回到伺服器參數、DNS 和系統 VPN 設定。

若需要重新核對 iPad 的 App Store 取得、已購項目還原與首次授權步驟，請查看iPad 取得說明。Mac、Apple TV 與 Apple Vision 的相容資訊也以同一個 App Store 頁面標註為準；本頁的操作重點仍是 iPhone 與 iPad 上的故障定位。