Shadowrocket（小火箭）顯示延遲，不代表目標網頁已完成 DNS 解析。本文適合已備妥自有服務商與設定檔的使用者：先固定測試條件，再確認目前的 Config、DNS 上游與規則命中情況，最後判斷是解析失敗、連線失敗，還是網站本身異常。每次只變更一項設定，並保留可還原的原始設定。
一、先分清延遲測試與網頁連線
延遲測試只能表示測試方式涵蓋的連線路徑當時有收到回應。測試不一定連到出錯的網站，也不一定經過瀏覽器此次請求所需的所有解析與連線步驟。因此，即使顯示延遲數值，仍可能在網域解析、策略選擇、TLS 交握或網頁資源載入時失敗。
先記下明確的失敗網域、發生時間、目前使用的網路，以及 Home 中的 Global Routing。不要只記錄「所有網頁都無法開啟」：同一頁面可能同時載入主站、圖片網域與登入介面，主頁正常但部分資源失敗，和主網域完全無法解析，是兩種不同問題。
結論：先找出失敗環節
如果已取得目標 IP，之後才發生連線逾時，應先檢查目標連線與策略；如果同一網域一直沒有解析結果，再檢查 DNS。連接埠號碼只代表協定慣例，不表示目前的網路一定允許相關請求通過。
二、固定 Home、Config 與 On Demand 的測試條件
開始排查前，先儲存目前設定的副本或匯出備份，並記下原本的 Global Routing。本文以 Config 作為主要排查環境，因為需要查看設定檔中的規則。Proxy 與 Direct 可短暫用於比較，但單靠這兩種模式無法證明 DNS 正常或異常；Scene 也不適合在條件未記錄的情況下作為對照，應先確認目前場景的行為。
-
記錄目前狀態
前往 Home → Global Routing，記下目前使用的是 Config、Proxy、Direct 還是 Scene，並記下目前選取的既有伺服器。測試期間不要同時更換伺服器與 DNS。
-
確認使用中的設定檔
前往 Config，確認目前選取的設定檔。點選該檔案右側的資訊按鈕，進入 Edit Plain Text，核對實際儲存的
[General]與[Rule]內容，而不是只查看尚未啟用的檔案。 -
確認自動連線設定
前往 Settings → On Demand，記錄是否已啟用及目前設定的條件。如果關閉連線後又自動連線，請先檢查這裡；若要暫時停用，先記下原本狀態，測試結束後再恢復。
-
一次只變更一項
固定使用同一個 Wi-Fi 或行動網路，在 Home → Global Routing → Config 下重複連線至同一網域。每次修改並儲存後，重新連線再發出新的請求，並記錄結果。
如果問題只在某個 Wi-Fi 發生，先確認該網路是否需要登入網頁完成驗證。尚未完成驗證時，DNS 請求與 HTTPS 連線都可能受到限制；反覆編輯規則無法取代網路驗證。如果切換網路進行比較，請將其視為獨立測試，不要與其他設定變更混在一起。
三、DNS 設定要檢查哪些項目
DNS 上游負責回覆網域對應的 IP 位址；規則負責選擇請求使用的策略，兩者不可混為一談。在目前設定檔的 [General] 中，dns-server 用來指定 DNS 伺服器。先確認實際設定值、位址格式與連線狀況，再考慮更換；不要因為某個位址看起來熟悉，就假設它在目前的網路中可用。
| 檢查項目 | 說明 | 排查重點 |
|---|---|---|
dns-server |
設定檔中的 DNS 上游清單 | 檢查是否有拼字錯誤、已失效的位址，或與目前網路不相容的上游。 |
system |
使用系統提供的 DNS 伺服器 | 切換 Wi-Fi 與行動網路後，系統提供的解析條件可能不同。 |
| DNS over HTTPS | 透過 HTTPS 傳送 DNS 查詢 | 確認完整 URL、路徑、憑證與上游連線；只有主機名稱並不代表查詢端點有效。 |
| A / AAAA | 分別回傳 IPv4 / IPv6 位址 | 取得 AAAA 記錄，不代表目前網路具備可用的 IPv6 對外連線。 |
| 伺服器網域名稱 | 既有伺服器位址本身也可能需要解析 | 分清伺服器網域解析失敗與目標網站網域解析失敗。 |
以下是用來理解欄位位置的最小範例，不能取代整份設定檔。此範例將 DNS 上游設為系統提供的伺服器，可作為明確的比較條件，但不保證適用於每個網路。編輯時請修改現有欄位、保留其他設定，也不要重複加入多個同名項目。
[General]
dns-server = system使用網域名稱形式的加密 DNS 端點時，也要考慮上游網域如何先行解析，以及端點是否連得上。加密只會改變查詢的傳輸方式，不保證解析結果正確，也不保證網站連線成功。如果上游連線本身失敗，應先處理上游的可連線性，而不是繼續新增更多位址來掩蓋問題。
- 只修改目前使用的設定檔；遠端設定檔更新後，請確認本機修改是否仍保留。
- 不要將網站 URL、訂閱連結或伺服器連線參數填入
dns-server。 - IPv6 問題應透過相同網路下的比較來定位，不要把永久停用 IPv6 當成所有解析問題的通用解法。
四、透過規則命中情況區分 DNS 與分流問題
當 Global Routing 設為 Config 時，規則順序會影響最後採用的策略。一般應先檢查較精確的網域規則，再檢查位址規則與最後的 FINAL。網域可能已正確解析，但請求卻被分配到無法使用的出口；遇到這種情況，修改 DNS 無法直接修正策略錯誤。
以下範例只展示規則語法，示例網域與文件保留位址不代表任何服務。不要整段貼上來取代現有規則；請在自己的設定檔中尋找類似項目，並參照連線記錄確認命中情況。特別是 FINAL,DIRECT，只代表此範例採用的最終策略，不是通用建議值。
[Rule]
DOMAIN-SUFFIX,example.com,DIRECT
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,DIRECT| 關鍵字 | 比對依據 | 與排查的關聯 |
|---|---|---|
DOMAIN-SUFFIX |
網域後綴 | 檢查目標網域是否被較前面的規則套用到非預期策略。 |
IP-CIDR |
IP 位址範圍 | 目標只有網域名稱時，位址比對可能涉及解析；no-resolve 用來避免此位址規則主動觸發解析。 |
GEOIP |
IP 位址地理位置資料庫 | 這是位址分類方式，不保證網站網域或實際服務所在位置。 |
FINAL |
前面的規則都未命中 | 確認最後採用的策略，不要將兜底策略放在具體規則之前。 |
結論：先比對策略，再調整解析
如果同一目標在 Proxy 下可以連線、在 Config 下卻失敗，應優先比對命中的規則與使用的出口；這只能作為縮小排查範圍的線索，不能單憑此現象判定是 DNS 故障。切回 Config 後，再逐項檢查相關規則。
五、依實際錯誤選擇下一步
閱讀錯誤訊息時，必須先確認它是在哪個環節產生。以下列出的內容可能出現在 DNS 回應或網路記錄中，並非 Shadowrocket 每次故障時都會顯示的固定提示。只有實際記錄出現相應文字時，才套用對應判斷；瀏覽器籠統顯示「無法開啟網頁」，不能直接等同於 NXDOMAIN。
錯誤：NXDOMAIN
原因與處理方式：DNS 回覆查詢的名稱不存在——先確認完整網域名稱與拼字，再以相同網域比較不同上游的結果；如果結果不一致，記下回應來源後再進一步調查。
錯誤：SERVFAIL
原因與處理方式：DNS 伺服器無法完成查詢，可能與上游故障或驗證失敗有關——先確認是否只有單一網域受影響，再使用已確認可連線的上游進行比較，不要直接判定目標網站已關閉。
錯誤：connection timed out
原因與處理方式：某次連線未能在等待時間內完成，單憑這段文字無法判定是 DNS 問題——確認逾時的對象是 DNS 上游、既有伺服器還是網站位址，再檢查相應的連線路徑。
如果出現憑證錯誤，應優先檢查裝置時間、連線網域、憑證名稱與 HTTPS 連線環境。不要透過忽略憑證驗證來「修復 DNS」。如果網頁正文可以顯示，但圖片載入失敗，請分別檢查資源網域的規則與解析，不要只反覆測試主站。
- 只有一個網域失敗：檢查拼字、該網域的解析回應與專屬規則，再確認是否為網站本身異常。
- 同一網路普遍失敗：檢查網路驗證狀態、系統 DNS 與上游連線狀況；切換網路時，其他條件維持不變。
- 解析成功但連線失敗：檢查位址是否可連線、IPv4 / IPv6 路徑、策略與 TLS，不要持續更換解析位址。
- 修改後偶爾恢復：分辨快取到期、重新連線與設定變更各自的影響；只成功一次不足以證明根本原因。
六、重新測試、還原設定並整理排查記錄
修改 DNS 後，既有連線不一定會立即重新解析，瀏覽器與系統也可能保留快取。儲存設定並重新連線後，再發起新的連線；必要時關閉原頁面後重新開啟。不要以不斷重新整理舊頁面取代獨立測試，也不要假設重新連線就會清除所有 App 的快取。
恢復連線後，請逐項還原暫時變更，只保留經多次比較確認有效的設定。尤其要恢復原本的 On Demand 狀態與 Global Routing，避免排查結束後長期停留在暫時使用的 Proxy 或 Direct。若設定檔之後有更新，再確認使用中的檔案與相關欄位是否變動。
| 記錄項目 | 應記錄的內容 |
|---|---|
| 網路與時間 | 發生時間、使用 Wi-Fi 或行動網路，以及切換網路後是否再次發生。 |
| 使用中的設定檔 | 目前的設定檔名稱、Global Routing、DNS 上游類型與相關規則。 |
| 請求結果 | 失敗的網域、DNS 回應或錯誤原文、是否已取得 IP，以及最後採用的策略。 |
| 單項比較 | 變更了哪一項、重新連線後的結果，以及還原原值後問題是否再次發生。 |
將記錄提供給自己的服務商或支援管道前，請隱藏完整訂閱連結、token、UUID、密碼及其他憑證。不要直接公開整份設定檔。本文只說明客戶端排查方式，不提供、不販售、不推薦節點或訂閱；買斷客戶端不等於購買線路方案。