Shadowrocket 使用說明

選擇 Global Routing 模式

伺服器記錄決定代理連線使用哪些參數，Global Routing 則決定請求如何選擇路徑。這兩項需要分別確認：清單中選取了伺服器，不代表所有請求都會經過該伺服器。返回 Home，點選 Global Routing，查看目前選項，並依本次測試目標選擇設定(Config)、代理(Proxy)或直連(Direct)。修改後返回 Home，再確認一次模式名稱，避免只開啟選單卻沒有完成選擇。

設定(Config)：依目前設定處理請求

日常依規則分流時使用設定(Config)。它會讀取目前啟用的設定，依照規則的比對順序決定請求要交由代理、直接連線或執行其他動作。因此，選取 Config 前，應進入 Config 確認目前使用的是哪一份設定，而不只是確認清單中「有一份檔案」。剛匯入的檔案與正在啟用的檔案可能不同，修改錯誤的檔案不會改變目前的連線行為。

如果已有自己的設定，啟用前先保留備份，不要將網路上零散的規則直接堆在檔案末尾。像 DOMAIN-SUFFIX、GEOIP、FINAL 這類規則關鍵字的比對範圍各不相同，前面的規則可能已處理請求，後面的規則便不會繼續比對。本頁只需確認啟用狀態與基本路徑；詳細語法與概念請前往術語手冊閱讀。

代理(Proxy)與直連(Direct)：用於明確比對路徑

代理(Proxy)適合暫時檢查所選代理路徑是否可用，不會依靠一般規則逐條決定去向。這不代表伺服器一定可連線，也不保證每種 App 行為都會以相同方式運作。直連(Direct)會讓請求走直接連線路徑，適合比較本地網路結果；選擇 Direct 後，不能將「App 開關已開啟」理解為「請求正在使用代理」。

初次排查時，可先使用 Proxy 比對一個明確目標；確認代理路徑可用後，再切回 Config 驗證分流。不要長期將暫時的排查模式當作已完成的規則設定。每次切換模式後，都用同一個頁面重新測試並記錄差異，這樣之後遇到問題時，才能分辨是伺服器本身不可用，還是規則選擇了不同路徑。

開啟連線開關並完成系統授權

確認 Home 中選取了預期伺服器，且 Global Routing 符合本次目標後，開啟 Home 頂端的連線開關。首次連線時，iPhone / iPad 可能會顯示新增 VPN 設定的系統提示。確認提示由 Shadowrocket 發起後，允許新增，並依照系統要求使用裝置密碼或身分驗證完成操作。系統授權是建立連線所需的權限，不是購買確認，也不會替現有伺服器補上缺漏欄位。

完成授權後返回 Shadowrocket，檢查開關是否維持開啟。如果開關立即關閉、持續停留在連線中，或再次出現權限提示，先停止反覆點選。查看提示文字，確認上次系統授權是否確實完成；若先前曾取消，重新發起連線並完成授權即可。不了解用途時，不要刪除裝置上的設定，尤其是由工作單位或學校管理的裝置，應先確認其管理限制。

進行連線測試期間，先停止其他可能占用系統 VPN 連線的服務，再單獨啟用 Shadowrocket，減少相互切換造成的干擾。若系統設定顯示的連線狀態與 App 不同步，可先在 App 內關閉連線，等待狀態恢復後再重新開啟。每次操作之間留出狀態切換時間；連續快速切換開關，通常只會讓故障位置更難辨認。

系統的 VPN 標示只能說明相應網路連線已建立，無法單獨證明目標網頁已依預期規則通行。不同裝置的版面配置可能會讓狀態標示的位置與顯示方式有所不同，不必為了尋找圖示而反覆重新連線。接下來應使用 App 測試與實際請求交叉確認，而不是只看開關顏色。

首次驗證時，暫時不要額外調整 On Demand。它會依條件觸發連線，無法修正伺服器位址、驗證資訊或規則錯誤。先確認手動開啟、手動關閉的流程正常，再依自己的網路使用習慣設定自動觸發條件。之後若出現自動連線問題，也能直接與已驗證的手動流程比較。

使用 Connectivity Test 與實際請求驗證

保持連線開啟，在 Home 使用 Connectivity Test 檢查所選伺服器的基本連線狀況。測試結果有助於發現明顯的故障，但測試方式、測試目標與實際 App 的存取方式並不完全相同。因此，測試成功不代表所有網站都能開啟；測試失敗也需要配合實際請求判斷，不能只憑結果就刪除整組訂閱。

接著開啟瀏覽器，造訪一個平常會使用、且能明確判斷是否載入完成的頁面。先確認頁面主體是否出現，再嘗試站內導覽或重新載入，避免只看到快取內容就認定連線成功。如果測試目標本身正在維護，換一個已知可用的目標重新測試；不要使用來源不明的檢測網頁，也不要向檢測服務提交訂閱連結或伺服器憑證。

需要驗證規則分流時，切回 Config，確認目前啟用的設定，再發起一次新的請求。搭配 App 中可查看的請求記錄，核對目標網域、命中的規則以及實際處理去向。預期直連的請求應與 DIRECT 處理結果一致，預期代理的請求則應與目前設定中的代理動作一致。若規則引用了策略，也要核對策略最後選擇的項目，而不只看規則名稱。

可以依照「關閉連線時的本地結果、Proxy 下的結果、Config 下的結果」進行簡單比對。每次只變更一個條件，並保持相同裝置、相同網路和相同測試目標。若 Proxy 正常而 Config 失敗，優先檢查規則與設定；若兩者都失敗，先檢查伺服器參數與網路，不要繼續增加規則。完成比對後，恢復日常需要的模式。

最後再驗證一次關閉與重新開啟：先關閉連線，確認本地網路仍正常，再重新啟用並重複實際存取。如果只有第一次開啟正常，切換網路後便失敗，記錄問題發生於 Wi-Fi 還是行動網路。速度與穩定性需要依使用情境判斷，Connectivity Test 的單次結果不能直接換算為下載速度，更不能作為長期穩定性的結論。

依故障位置排查，避免同時變更多項設定

排查順序應從本地網路開始，而不是先重新安裝 App。關閉 Shadowrocket 連線，確認裝置本身能正常連網；如果 Wi-Fi 尚未完成網路驗證，先完成驗證頁面，再重新連線。如果本地連線已經失敗，修改伺服器密碼、規則或 DNS 通常無法解決根本問題。在允許使用行動網路的情況下，可切換一次網路進行比對，但要留意行動數據用量。

匯入失敗：檢查內容與更新結果

如果 Subscribe 儲存後沒有伺服器，重新檢查連結是否遭截斷、是否混入空格，以及服務狀態是否允許更新。現有群組中的舊項目仍然顯示，不代表這次更新成功；應查看更新提示並確認內容是否符合預期。如果連結傳回的是登入頁面或錯誤文字，先處理連結的存取條件。向服務提供者反映時，描述錯誤與發生時間，不要在公開位置附上完整的私人 URL。

連線失敗：先比對欄位，再檢查網路

若某一台伺服器連線失敗，開啟其記錄，比對現有資訊中的協定、位址、連接埠、密碼或其他驗證欄位。涉及 TLS 時，也要核對伺服器要求的相關名稱與傳輸選項，不要為了嘗試而開啟所有選項。如果同一訂閱中的多個項目同時失敗，先比對不同本地網路的結果，再判斷是否需要向現有服務提供者反映；不要只因單次測試失敗就反覆刪除並重新新增項目。

開關已開啟但頁面無法載入：區分規則與 DNS

先確認 Global Routing 不是 Direct，再比較 Proxy 與 Config 的表現。只有 Config 失敗時，檢查目前設定是否正確啟用、目標是否已被較前面的規則處理，以及引用的策略是否可用。如果狀況是網域無法解析，應檢查目前的 DNS 設定與網路條件，而不是隨意填入多個位址。調整前先儲存原值，每次只變更一項；還原後能否重現問題，也是判斷修改是否有效的重要依據。

如果瀏覽器正常、但某個 App 失敗，還需考慮該 App 自身的快取、連線重用、服務狀態與存取要求。先完全結束並重新開啟目標 App，再發起新的請求，不要直接推斷整體連線失效。相反地，如果所有目標都失敗，應回頭檢查伺服器、系統授權與本地網路這三項基本條件，避免只在單一 App 設定中反覆嘗試。

保留可重現的資訊，再繼續深入排查

有效的排查記錄應包括：使用 Wi-Fi 還是行動網路、目前的 Global Routing、故障發生於匯入還是實際存取、是否所有伺服器都一樣，以及最近變更了哪一項設定。分享記錄前，請遮蔽訂閱驗證資訊、密碼和可辨識個人的資訊。錯誤提示的進一步說明請見疑難排解；需要整理多組訂閱、安排更新與備份時，請前往訂閱指南繼續操作。

完成這五個步驟後，應能明確說出目前選取的伺服器、使用的模式、系統連線是否已建立，以及實際請求是否符合預期。之後修改設定或更新訂閱，也依照相同順序重新測試即可。先儲存一份已驗證可用的設定，再進行更細緻的規則調整，比同時變更多項設定更容易保留穩定的參考狀態。