本文適用於已在 iPhone 或 iPad 上設定 Shadowrocket，並已有自己的伺服器或訂閱，但遇到延遲測試正常、網頁卻無法載入的情況。依照「確認症狀 → 對照路由 → 檢查 DNS → 檢查 IPv6 → 重新測試」的順序操作，可區分解析故障、伺服器連線故障與規則分流問題，避免一次更改多項設定而無法判斷原因。
一、延遲正常，不代表網頁請求完整成功
Shadowrocket（小火箭）的延遲結果，只能表示當下以指定測試方式完成了某個連線步驟。TCP 測試通常著重於伺服器連接埠是否可連線；使用 HTTP 類測試時，結果也只適用於測試目標及其路徑。這不能取代對故障網站的 DNS 查詢、TLS 交握與頁面資源載入狀況的檢查。
開啟網頁通常需要先將網域名稱解析為 IP 位址，再透過選定的直連或代理路徑建立連線，接著完成 TLS 交握與 HTTP 請求。在代理情境中，目標網域也可能交由遠端解析。只看到延遲數值，無法確認本機 DNS 或遠端 DNS 是否正常，更不能據此認定網站一定可以連線。
這些連接埠說明的是 DNS 傳輸方式，並不是要將伺服器連接埠改成其中之一。DNS over HTTPS 能正常建立連線，也不代表目標網站可以連線；反過來說，普通網頁能開啟，也不能證明網路允許使用每一種 DNS 傳輸方式。
二、先建立可重複比對的故障情境
排查時請使用相同的完整網址、同一個瀏覽器和同一部裝置。不要把網站首頁、站內連結跳轉與影片播放混在一起測試：主文件可能已成功載入，但圖片、登入或媒體使用的其他網域仍可能失敗。每次只更改一項條件，並記錄結果。
- 確認影響範圍。分別開啟故障網站與先前可正常瀏覽的網站。記錄是所有頁面都失敗、只有一個網域失敗，還是文字可顯示但圖片一直載入。
- 確認基本網路。暫停 Shadowrocket 連線，檢查目前網路是否需要完成網頁登入認證。這個步驟只用來確認基本網路狀態，不代表故障網站必須能夠直連。
- 恢復原有連線。返回 Home，選取自己已有的伺服器並啟用連線，再開啟相同網址。不要只重複進行延遲測試。
- 比對接入網路。保持伺服器與設定不變，在 Wi-Fi 和行動網路之間切換後重新測試。如果只有某個 Wi-Fi 失敗，優先檢查該網路的 DNS 可連線性、認證狀態或存取限制。
- 排除自動重新連線的干擾。如果停止連線後又自動啟用，請檢查 Settings → On Demand。記下原有設定，測試期間視需要暫停，結束後再恢復。
瀏覽器可能會沿用原有連線，DNS 也可能有快取。更改設定後，先停止再重新啟用 Shadowrocket 連線，然後重新開啟故障頁面。如果狀況仍不一致，可以關閉相關瀏覽器分頁後再試；不要因為一次重新整理成功，就認定問題已解決。
三、使用 Global Routing 區分路由與解析問題
在 Home → Global Routing 檢查目前選項。Config 表示依照目前設定處理流量，並不代表所有請求都會經過代理；Proxy 主要用來讓流量經由所選代理進行比對；Direct 則用於直連比對。Scene 會依場景設定決定行為，排查時還要確認目前生效的場景，不能只看名稱就判斷實際出口。
| 比對結果 | 優先檢查項目 | 下一步 |
|---|---|---|
| Config 失敗，Proxy 成功 | 規則命中、策略選擇，以及不同路徑的解析差異 | 檢查目前 Config 中，目標網域對應的規則與策略 |
| Config 與 Proxy 都失敗 | 目前伺服器、DNS 可連線性或目標網站 | 保持設定不變，改用自己已有的另一部伺服器比對 |
| Direct 成功，Proxy 失敗 | 代理出口、遠端解析，或目標網站對出口的限制 | 確認伺服器狀態，不要先改寫整份規則 |
| 只有某個接入網路失敗 | 該網路的傳輸限制與 DNS 路徑 | 比對 Wi-Fi 與行動網路，並檢查 DNS 傳輸方式 |
結論：Proxy 成功時，先回頭檢查 Config
如果在相同伺服器、相同網路下只有 Config 失敗，請先檢查目標網域的比對規則與實際策略，再調整 DNS；不要長期停留在 Proxy，並將此視為規則問題已修復。
這些結果只能提供縮小排查範圍的線索，不能憑單次測試就下定論。切換 Global Routing 可能同時改變連線路徑與解析條件，因此還需搭配下一節的 DNS 設定逐項驗證。完成比對後，請恢復日常使用的選項。
四、檢查 DNS 位址、傳輸方式與設定來源
開啟 Settings → DNS，記下目前顯示的 DNS 設定。接著前往 Config，確認實際使用的設定檔是否包含 DNS 相關設定。不要只改某一處位址就認定設定已生效：設定檔、全域設定及相關選項的組合都會影響最終行為，應透過重新連線與請求結果進行確認。
- 確認輸入內容符合欄位用途。一般 DNS 位址、DNS over HTTPS 的完整位址，以及 DNS over TLS 的伺服器名稱，不能任意互換。請依照介面支援的格式填寫，不要將訂閱網址貼到 DNS 欄位。
- 確認端點完整。DNS over HTTPS 通常需要完整的 HTTPS 端點，不能只憑某個網站首頁網址，就判斷它提供 DNS 服務。請確認目前使用的解析服務說明，不要自行拼湊路徑。
- 檢查初始解析依賴。如果 DNS 端點使用網域名稱，連線前可能仍須先解析該網域。基本解析不可用時，單純改用另一個以網域名稱表示的端點，未必能解決問題。
- 檢查路徑是否可連線。目前網路可能允許 HTTPS，卻限制其他連接埠；如果代理伺服器本身使用網域名稱，也要考慮建立代理連線前所需的解析步驟。避免 DNS 請求與代理連線建立過程彼此依賴。
- 逐項替換並重新測試。先備份現有設定，再使用自己確認可用的 DNS 設定進行比對。保留目前伺服器、Global Routing 與測試網址不變，重新連線後記錄結果。
如果更改 DNS 後恢復正常，請繼續確認重新連線或切換網路後是否仍有效。若只有第一次成功，之後又失敗，請回頭檢查快取、端點可連線性或自動切換條件。更新訂閱主要是更新伺服器資訊，不代表目前 Config 的 DNS 設定也一定會隨之更新。
五、依錯誤原文選擇排查方向
錯誤可能來自瀏覽器、系統網路層或請求記錄，不一定是 Shadowrocket 本身顯示的提示。以下是常見網路錯誤原文，不保證每部裝置顯示的文字都相同。記錄錯誤涉及的是目標網站網域、代理伺服器網域，還是 DNS 端點網域，比只記下「打不開」更有助於排查。
錯誤：The server with the specified hostname could not be found.
原因與解法：主機名稱解析未取得可用結果，也可能是網域拼寫錯誤或網域本身已失效。先確認完整網域名稱，再比對 Settings → DNS 與目前 Config，並透過另一個接入網路重新測試相同網址。
錯誤：NXDOMAIN
原因與解法：解析器回覆網域不存在，這與等待逾時不同。請確認網域拼寫，並檢查是否誤加子網域，再比對另一條已確認可用的解析路徑；不要試圖一味延長等待時間來處理這類結果。
錯誤：SERVFAIL
原因與解法：解析器無法完成查詢，可能與上游故障或網域驗證問題有關。保持其他條件不變，改用另一條可用的解析路徑進行比對；若只有同一個網域受影響，請記錄結果並回報自己的服務供應商。
錯誤：The request timed out.
原因與解法：某個請求階段超過等待時間，但單看這段文字無法確定是 DNS 故障。先確認是否已取得解析位址，再檢查連線路徑；若解析已成功，應繼續檢查 TCP、TLS 或目標服務的回應。
出現憑證錯誤時，請檢查裝置的日期與時間、目標網域，以及所設定的端點是否正確。這與「找不到網域」並非同一類問題。不要為了消除提示而關閉 TLS 驗證，也不要在尚未確認失敗階段前，同時更換 DNS、伺服器與協定。
六、只有特定網域失敗：檢查規則、AAAA 與頁面資源
如果大多數網站都正常，只有少數網域失敗，應優先檢查其中的差異。A 記錄提供 IPv4 位址，AAAA 記錄提供 IPv6 位址；有 AAAA 記錄不代表目前網路的 IPv6 路徑一定可用。若解析成功後連線仍停滯，在確認可以還原的前提下，可比對 IPv6 相關設定；每次只改一項，測試後再還原或記下最後採用的設定。
規則會依序比對。DOMAIN-SUFFIX 可比對指定網域及其子網域；IP-CIDR 與 GEOIP 依據 IP 資訊判斷，某些情況下須先進行解析；FINAL 則是在前面的規則都未命中時使用的預設規則。以下內容僅用來說明順序與語法，不代表應直接取代現有設定。
[Rule]
DOMAIN-SUFFIX,example.com,DIRECT
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY- 先檢查網域規則。範例中的
example.com及其子網域會先命中 DIRECT；如果該網域必須透過使用者自己的代理連線，就要確認是否有不適當的前置規則命中。 - 了解 no-resolve。這個選項用來避免為了該 IP 規則主動觸發網域解析，並非通用的 DNS 修復開關，也不保證請求永遠不會進行解析。
- 確認策略已定義。範例中的
PROXY必須對應到實際可用的策略；不要只複製名稱，卻忽略目前設定中是否有相應定義。 - 檢查相關資源。如果頁面文字正常，但圖片載入失敗，請檢查圖片、指令碼或登入請求使用的網域。只修改主網域的規則，可能無法涵蓋獨立的資源網域。
結論：已有位址但連線失敗，應繼續往後檢查
若已確認故障網域有回傳位址，但請求仍停在連線或 TLS 階段，應優先檢查實際出口、IPv4／IPv6 路徑及目標網站回應，不要再把所有失敗都歸因於 DNS 解析問題。
七、常見問題與最後確認
延遲一直正常，為什麼換伺服器後就能開啟？
延遲測試只涵蓋測試目標與部分連線階段。另一部伺服器可能有不同的出口、遠端解析方式，或不同的目標網站連線狀況。保持 DNS 與 Config 不變，比對兩部伺服器，記錄故障網站是否隨伺服器改變；不要因此直接判定本機 DNS 有問題。
切換到 Proxy 就能開啟，可以不管 Config 嗎？
可以將這個結果作為排查線索，但仍應回到 Config 檢查規則順序、目標網域命中的策略，以及 DNS 相關設定。修復後切回日常使用的選項，並確認同一個網頁及其資源都能載入。
只有 Wi-Fi 出錯、行動網路正常，需要重新安裝嗎？
先不用重新安裝。保留相同伺服器與設定，檢查 Wi-Fi 登入認證與 DNS 傳輸的可連線性；若暫停連線後又自動啟用，再檢查 Settings → On Demand，避免自動重新連線改變測試條件。
更新訂閱後，DNS 也會一併恢復嗎？
不一定。伺服器訂閱與 Config 的內容不同。先在 Home 確認目前選取的伺服器是否有變更，再到 Config 檢查實際使用的設定，最後查看 Settings → DNS；不要把更新伺服器清單當成重設所有網路設定。
完成修改後，至少使用原本故障的網址、一個正常的比對網址，以及切換一次接入網路進行重新測試。如果仍需回報自己的服務供應商，請提供失敗網域、發生時間、接入網路、Global Routing 選項、錯誤原文，以及修改前後的比對結果。請從截圖或記錄中移除訂閱權杖、伺服器密碼及其他憑證。
- 已區分網域解析失敗、連線逾時與 TLS 錯誤，沒有只憑延遲結果下結論。
- 已確認目前 Home 選取的伺服器、Config 檔案與 Global Routing 選項。
- 已檢查 DNS 位址格式、端點可連線性，以及可能存在的初始解析依賴。
- 已還原暫時變更的 On Demand、路由及 IPv6 相關選項，或記下需要保留的調整。
- 已確認重新連線後問題仍然解決，而非只成功載入一次。