Shadowrocket 故障排除指南

02　已連線卻無法上網：拆解模式與規則

VPN 標記表示裝置已建立本機通道，不代表每個連線都已成功送達目標。App 選取的伺服器、Global Routing 模式、目前的 Config 與 DNS 都會影響結果。先準備兩個原本應可存取的測試目標：一個用來檢查本機網路，另一個用來檢查既有伺服器的轉送。兩者都應使用熟悉的一般網頁，不要只測試單一 App 的內容載入。

先固定伺服器，再比較三種模式

返回 Home，確認 SERVER 中實際選取的項目。項目顯示在清單中不代表已被選取，訂閱更新後項目排序改變也可能造成誤判。先對選取的項目執行 Connectivity Test，再記錄結果。測試有數值只表示該測試路徑收到回應，不能據此認定所有網站、傳輸方式與 DNS 查詢都正常。

接著查看 Global Routing。Config 模式依目前設定決定流量去向；Proxy 模式用來檢查經由目前伺服器存取的情況；Direct 模式則用來比對本機網路路徑。暫時切換模式只為了定位問題，不是長期修復方式。切換前記錄原模式，每次使用相同測試目標，測試結束後恢復原設定。

如果 Proxy 可以存取，但 Config 無法存取，重點就不應再放在密碼上。前往 Config 確認目前啟用的檔案，檢查目標是否命中 REJECT，或被指向不存在或設定錯誤的策略。如果 Direct 正常而 Proxy 失敗，也不能立刻斷定是規則錯誤，請繼續查看伺服器逾時與 DNS 兩個章節，進一步區分原因。

從實際命中情況回頭檢查規則順序

規則通常依序比對，較前面的寬泛規則可能先處理連線。DOMAIN-SUFFIX 涵蓋指定網域及其子網域，IP-CIDR 用於位址網段，FINAL 則處理前面未命中的連線。排查時應查看實際目標與命中結果，不要只因在檔案中找到一條看似相關的規則就下結論。一個網頁也可能載入多個子網域，主頁成功不代表圖片與登入介面也正常。

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

以上為規則順序範例，不是適用於所有網路的完整設定。較具體的 ads.example.com 應放在較寬泛的 example.com 之前，才不會先被前面的後綴規則處理。GEOIP 依賴位址歸屬資訊，不能取代所有網域規則。不要將整份範例覆寫到目前使用的 Config；請先複製設定，再只修改已確認有問題的規則。

區分 App 問題與網路問題

如果 Safari 可以存取，只有某個 App 失敗，請先檢查該 App 是否使用獨立網域、即時通訊或其他傳輸方式。重新開啟 App 可以觸發新連線，但不要立即清除登入資料。如果頁面內容來自快取，看到舊內容也不算驗證成功；請重新整理並確認新請求確實完成，再查看連線記錄中的時間與目標。

每修改一條規則，就重新送出相同請求，確認錯誤是否消失。如果切換網路後才恢復，請保留這項條件，繼續檢查本機網路與解析，不要把偶然恢復歸因於最後一次無關的修改。更精簡的操作清單請見開關已開啟卻無法上網的逐項排查；首次連線步驟請返回使用說明。

04　訂閱更新失敗：區分取得內容與解析內容

匯入訂閱至少包含兩個步驟：取得網址回傳的內容，再將內容解析為伺服器項目。網址可以開啟，不代表回傳的是可用訂閱；成功匯入項目，也不代表這些項目目前都能連線。先判斷失敗發生在讀取網址、取得回傳內容、解析項目，還是連線伺服器的階段。既有伺服器無法使用時，不要預設問題一定出在訂閱更新。

先檢查網址與帳戶狀態

從使用者自己的服務供應商處重新複製訂閱網址，檢查開頭、結尾與查詢參數是否完整。有些網址包含用於識別帳戶的憑證，少一個字元就可能遭拒絕存取。複製時不要把說明文字、引號或尾端標點一併貼入網址欄位，也不要擅自刪除看起來很長的查詢參數。請在私密環境核對長網址，不要貼到公開討論區。

如果頁面要求先登入，或回傳帳戶提示，這就不是可直接讀取訂閱內容的入口。應使用服務供應商明確提供給用戶端的訂閱網址，而非後台管理頁面。訂閱內容可能採用不同編碼或格式，不能只因瀏覽器顯示一串文字就判定有誤，也不能將網頁內文儲存後當作設定檔匯入。

也要檢查使用者既有服務的有效狀態與使用限制。用戶端一次性購買與遠端服務分開計算，用戶端一次買斷 ≠ 線路方案。App 購買成功不會自動產生伺服器資訊。本站只說明匯入與檢查方法，不提供訂閱網址；帳戶狀態或網址失效時，應由使用者向自己的服務供應商確認。

依回傳結果決定下一步

更新時若發生網路逾時，先確認基礎網路正常，再檢查訂閱網域的解析與存取路徑。若出現驗證類錯誤，優先檢查網址是否失效、憑證是否已重設。若解析失敗，則應確認回傳內容是否為訂閱格式，還是已變成登入頁、提示頁或空白內容。不要把所有錯誤都解讀成「節點故障」，有些失敗甚至尚未取得伺服器清單。

已有可用連線時，訂閱請求可能受到目前連線狀態、路由與解析的影響。保持網址不變，分別在中斷連線與目前可用連線時各測試一次，並記錄差異。測試目的是確認網址的取得路徑，不是要求長期依賴某種模式。若兩種狀態都失敗，再切換基礎網路重新測試，避免以連續重新整理取代比對。

短時間內頻繁更新可能觸發遠端請求限制。出現限制提示後，應依服務供應商提供的條件等待，不要不斷刪除再新增同一網址。若重新匯入前需要修改訂閱記錄，先儲存原記錄名稱與必要設定，並確認舊項目是否被其他設定引用。貿然清除會同時破壞原本可用的選取關係。

匯入成功後，確認清單與選取項目

更新完成後，查看項目數量與名稱是否符合預期，再確認目前選取的 SERVER。舊項目遭刪除或重新命名後，原本的選取可能不再對應想使用的入口。選取一個使用者已有的項目執行 Connectivity Test，再測試實際網頁。只有清單更新、選取正確、連線成功三個環節都通過，才能判定這次更新達到使用目的。

手動修改由訂閱產生的項目時，應留意下次更新可能會覆蓋這些變更。需要保留的差異應另外記錄，必要時在不影響原訂閱的副本中測試。訂閱通常用於維護伺服器資訊，Config 則用於控制規則與其他設定，兩者不能直接互相取代。匯入伺服器後，仍須確認 Config 與 Global Routing 是否符合原本的使用方式。

06　DNS 異常：分開驗證解析與連線

DNS 會將網域轉換成位址。若伺服器延遲測試有結果，但網頁顯示找不到主機、等待很久或部分資源未顯示，就需要將解析作為獨立環節檢查。也要注意，瀏覽器顯示的憑證錯誤與網域解析失敗是不同問題。先記錄具體網域、錯誤文字與發生時的連線模式，再確認請求是否取得位址，以及取得哪一類位址。

先確認目前設定與查詢路徑

前往 Config 確認實際啟用的檔案，查找其中影響 DNS 的設定。修改未啟用的檔案不會改變實際行為。如果有自訂解析服務、Host 對應或其他解析相關覆寫，先記錄原值，釐清目前請求由哪一層處理。系統、路由器與 App 內的設定可能共同參與，不應假設每次查詢都直接使用同一個解析來源。

選取一個發生問題的完整網域，與另一個正常網域比較。使用 App 內可用的診斷工具與連線記錄，觀察是否取得解析結果、是否逾時，以及後續連線是否繼續。如果網域已取得位址，但 TCP 或 TLS 接著失敗，問題重點已轉向網路與交握；此時反覆更換 DNS 可能只會改變目標位址，並未修復真正的故障。

自訂 DNS 服務本身也必須能連線。如果其位址仍依賴一個尚未完成的解析程序，可能會在啟動階段產生依賴問題。檢查設定中的解析請求實際送往何處，以及連線建立前後的表現是否不同。不要同時更換解析服務、修改 Global Routing 並清除規則，否則無法判斷是哪一步改變了解析路徑。

檢查 Host、IPv6 與網路差異

過期的 Host 對應可能會將網域固定到舊位址，掩蓋一般 DNS 的變化。先在設定副本中停用與故障網域相關的對應，再重新送出請求。仰賴內容傳遞的網站，固定位址也可能無法再提供適合目前網路的位置。不要將偶然可用的位址長期固定，也不要以直接存取位址的結果取代完整的網域存取測試。

有些網路能回傳 IPv6 位址，但未必具備穩定的 IPv6 連線能力。若問題只在特定網路發生，請查看失敗連線實際使用 IPv4 還是 IPv6，再配合基礎網路測試判斷。不要只因回傳某類位址就認定解析錯誤。暫時調整位址類型相關設定時，務必記下原值，並在切換網路後再次確認，避免修復一種環境卻影響另一種環境。

區域網路裝置名稱、內部網域與公開網域可能需要不同的解析路徑。公開解析服務未必知道本機裝置名稱；公司或家庭內部資源可能依賴所在網路提供的解析資訊。如果只有內部資源無法使用，先確認本機網路與存取路徑，再檢查這些網域是否被錯誤送往遠端。不能將「所有網域都交給同一個解析服務」當作通用解法。

了解網域規則與位址規則的適用範圍

DOMAIN 與 DOMAIN-SUFFIX 直接針對網域，IP-CIDR 與 GEOIP 則適用於位址。部分位址規則的判斷涉及解析結果，因此規則命中與 DNS 並非完全獨立。排查時先用具體網域規則確認策略，再查看位址規則是否改變結果。尚未確認目標網域前，不要不斷新增寬泛的關鍵字規則，以免影響無關請求。

[Rule]
DOMAIN,portal.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,10.0.0.0/8,DIRECT
FINAL,PROXY

此範例說明具體規則應先於寬泛規則，不能取代實際網路方案。portal.example.com 是教學用網域，不是真實服務入口。修改後應重新送出請求，讓新連線使用新的結果；系統與 App 快取可能會讓舊結果保留一段時間。不要因為「儲存後沒有立即變化」就斷定設定未生效。

解析成功應同時符合以下條件：網域取得合理位址、請求採用預期策略，且實際頁面完成載入。更多細節請參閱DNS 設定與解析失敗檢查。若不熟悉相關術語，可先查閱概念速查，再回到目前故障網域繼續確認，不必一次重寫整份 DNS 設定。

08　更新後異常與 iPad：還原裝置差異

更新後發生問題，先確認變化出在哪個層級：App 更新、系統更新、訂閱重新整理、Config 替換，或裝置切換網路。這些事情可能在同一天發生，但不能只因時間接近就認定原因相同。記下最後一次正常使用時的伺服器、模式與網路，再與目前狀態比較。排查目標是找出行為差異，不是尋找未經驗證的舊設定來覆蓋所有設定。

先保留資料，再進行最小範圍測試

先儲存目前的 Config、自訂規則與必要的伺服器資訊。確認哪些資料來自訂閱、哪些是手動輸入，避免重建後無法還原。接著重新啟動 App，使用現有設定測試；必要時重新啟動裝置，讓系統網路狀態重新建立。如果問題仍存在，建立設定副本，只保留必要規則與一個使用者已有的伺服器作為比對，不要先清除正常資料。

如果最小設定正常、原設定失敗，應分組還原原有規則與設定，逐步找出差異。每次還原後都使用相同目標重新測試，不要一次全部加回去。如果兩者都失敗，再檢查系統 VPN 授權、基礎網路與伺服器參數。若錯誤提示指向設定語法，先檢查提示附近的分隔符號、策略名稱與欄位，不要只關注剛修改的那一行。

更新紀錄與系統需求請以 App Store 頁面標示為準。需要核對 App 時，請參閱正版驗證說明，確認開發者 Shadow Launch Technology Limited、官方圖示與 App ID 932747118。Shadowrocket 是 Apple 平台上的閉源商業 App，更新與重新取得都透過 App Store；不要把重新購買當成修復網路設定的方法。

逐項確認 iPad 與 iPhone 的差異

同一份伺服器資訊在 iPhone 可用、在 iPad 不可用時，先確認兩台裝置實際連接的是同一個網路。iPhone 可能正在使用行動數據，而 iPad 仍連接 Wi-Fi；網路名稱相似也不能取代確認。若 iPad 只有 Wi-Fi 功能，請改用另一個可用網路測試，避免套用不適用於目前裝置的行動數據檢查步驟。

App 購買記錄不會自動證明所有本機設定都一致。請檢查兩台裝置選取的 SERVER、Global Routing、啟用的 Config、DNS 相關項目與 On Demand 條件。手動輸入的欄位尤其需要逐項比對；複製設定時也要確認複製的是目前使用的檔案，而非先前儲存的舊檔案。只比較項目名稱並不足夠，同名項目的位址與參數可能已不同。

iPad 上的版面可能因橫向或直向、視窗大小或多工狀態而改變。部分清單與編輯區可能同時顯示，請根據 Home、Config、Settings 等介面文字確認所在區域，不要只依按鈕位於畫面左側或右側來尋找。輸入長網址時，請檢查鍵盤的自動處理是否帶入空格或標點，並在儲存前再次核對內容。

睡眠喚醒、區域網路與重新安裝的適用範圍

如果只在 iPad 長時間待機後失效，先觀察喚醒後網路是否已恢復，再手動中斷並重新連線一次。如果重新連線後恢復，請記錄是否伴隨網路切換或 On Demand 條件變化，繼續檢查重新連線與解析。不要把每次喚醒後重建所有設定當成固定操作；這會掩蓋真正的恢復時序問題，也容易遺失排查證據。

只有區域網路裝置、家庭內部頁面或列印功能失效時，請檢查相關系統權限，以及目標流量是否依預期採用 Direct。內部位址區段、內部網域與公共網際網路目標的處理條件不同，應依實際位址與解析結果判斷。不要為了解決單一本機目標而將所有流量長期改為 Direct，也不要新增涵蓋範圍過廣的位址規則，以免影響其他連線。

確定要重新安裝前，先確認設定備份可讀取、手動項目可還原，且使用者知道自己的訂閱網址儲存在哪裡。已購項目復原與一般購買適用性請以 App Store 頁面標示為準，詳見iPad 取得說明與換機復原說明。購買項目復原只處理 App 取得，不會自動重建使用者原有的伺服器與規則。