本文適合已在 Shadowrocket（小火箭）中匯入自己的設定檔的使用者。從延遲測試的限制開始，依序檢查 Global Routing、目前的 Config、DNS 回應結果與 IPv6 路徑，分辨解析失敗與解析後的連線失敗。排查時保留原設定，每次只調整一個項目，並以同一個網域重新測試。
一、延遲正常不代表網域解析正常
Home 顯示的延遲數值，只能表示該次測試所用的目標、協定與路徑有收到回應。不同測試涵蓋的環節不盡相同：連接埠可連通不代表網頁能完成 TLS 交握，一次 HTTP 測試成功也不代表所有網站都能存取。要判斷 DNS 是否異常，應查看發生問題的網域解析結果，而非只看延遲顏色。
瀏覽器開啟網站時，通常會先將網域解析為 IP 位址，再依實際路由建立連線，接著完成 TLS 與 HTTP 請求。代理協定、網域規則與遠端解析可能改變各步驟的執行位置，因此以下提供的是診斷順序，並非每個請求都會完全遵循相同的資料流程。
如果記錄中沒有位址回應，請優先檢查 DNS；如果已取得 A 或 AAAA 位址，但連線階段逾時，則應接著檢查實際出站、目標連接埠與網路路徑。若憑證驗證失敗，還要檢查裝置時間、目標網域與憑證資訊，不應直接歸因於 DNS。
不要把直接開啟 IP 位址當成完整驗證。許多 HTTPS 網站會依網域選擇憑證與網站內容。將網址列中的網域換成 IP 後無法開啟，不能據此證明該位址無法連線，也不能證明 DNS 正常。
二、先確認 Home、Config 與連線狀態
只有在實際生效的設定與路徑下，DNS 設定才有判讀意義。先確認 Home 目前使用哪個連線項目，再核對 Global Routing。Proxy、Direct、Config、Scene 代表不同的路由狀態，不能只根據其中一種狀態下的成功或失敗，就判定 DNS 伺服器有問題。Scene 的實際結果也取決於已設定的場景條件。
-
記錄基準狀態
在 Home 記下目前選取的連線項目與 Global Routing 值，並記錄目前使用 Wi-Fi 還是行動網路。選定一個確實無法開啟的網域作為固定測試對象，避免每次更換網站。
-
確認設定
前往 Config，確認目前選取的設定檔。開啟該檔案的編輯入口，先保留一份原始內容，再檢查
[General]與[Rule]。只修改未選取的其他檔案，不會改變目前連線的行為。 -
暫停自動連線
前往 Settings → On Demand，記下原本的狀態。若要手動中斷連線進行比較，可暫時關閉 On Demand，避免系統依條件重新建立連線；測試結束後請還原設定。
-
逐項重新測試
儲存一項變更後，返回 Home 中斷連線再重新連線，接著重新請求同一個網域。必要時開啟新的瀏覽器分頁；舊頁面、系統快取與瀏覽器快取都可能讓結果暫時沒有變化。
若要比較不同的 Global Routing 狀態，請先記下原值，短暫測試後立即還原。Direct 會讓目標流量採用直接連線路徑，Proxy 則會改變出站選擇；這種比較或許能找出網路路徑差異，但不是通用的正式設定修正方式。若涉及敏感業務，請先評估切換路徑可能造成的影響。
三、如何理解 DNS 設定項目
檢查目前 Config 的文字內容時，先找出 [General] 底下的 dns-server。此項目用來指定 DNS 解析器；system 表示使用系統提供的 DNS。若設定中還有其他 DNS 選項，請依目前 App 的參數說明逐項確認，不要將不同用途的位址都放進同一個欄位。
| 項目 | 說明 | 檢查重點 |
|---|---|---|
dns-server | 設定使用的 DNS 解析器 | 位址是否正確、目前的網路是否可連線、目前的 Config 是否已啟用 |
system | 使用系統提供的 DNS | 切換 Wi-Fi 與行動網路後，系統解析器與存取條件可能不同 |
A | 網域的 IPv4 位址記錄 | 是否取得回應，以及回傳的位址是否能建立連線 |
AAAA | 網域的 IPv6 位址記錄 | 取得位址不代表目前的 IPv6 路徑可用 |
TTL | DNS 記錄的快取有效時間 | 變更設定後，舊結果可能仍會快取一段時間 |
以下是用來辨識設定結構的最小片段，並非完整 Config，也不應覆蓋原始檔案。若要以系統解析器進行一次比較，只需調整現有 [General] 中對應的鍵，避免新增重複的區段或鍵。
[General]
dns-server = system連接埠號只能說明傳輸方式，無法保證連線可用。一般 DNS 請求可能在目前網路逾時；DoH 也需要建立 HTTPS 連線，而且以網域表示的 DoH 端點還需要先進行初始位址解析。是否採用某個解析器，應考量使用者既有設定的需求、網路可連線性與資料處理需求，而不是將加密傳輸視為必然更快。
四、依回應結果區分三種 DNS 故障
查看 App 內的請求或診斷記錄時，請留意發生問題的網域、查詢類型、回應狀態與後續連線結果。以下列出的是 DNS 回應碼或常見逾時文字，不代表 Shadowrocket 的每個介面都會逐字顯示這些字串。瀏覽器可能只顯示中文提示，請保留原始提示，不要自行補上某個錯誤碼。
NXDOMAIN
原因：解析器回覆該網域不存在；可能是網域拼寫錯誤、網域已失效，或目前的解析器回傳否定回應。
處理方式：先確認完整主機名稱，再以已知有效的網域進行比較；若只有該網域持續異常，請向該網站管理者確認，不要只是一味延長等待時間。
SERVFAIL
原因：解析器未能完成查詢，可能與上游回應、權威伺服器或驗證程序有關；這不代表網域不存在。
處理方式：保留原值後，改用另一個既有且可連線的解析器進行一次比較；若只有一個網域受到影響，請保留查詢時間與回應碼，供網站管理者排查。
timeout
原因：請求在等待期限內未收到回應，問題可能出在連往解析器的路徑，也可能發生在解析完成後的目標連線。
處理方式：先確認逾時發生在哪個階段；如果沒有 DNS 回應，請檢查解析器位址與網路連線狀態；如果已取得位址，則改查出站與目標連接埠。
單次失敗不足以判定原因。請對同一網域重複發出請求，再以另一個已知有效的網域進行比較：全部失敗較可能是共用的解析路徑異常，只有單一網域失敗則應優先檢查該網域及其權威解析。記錄時請保留查詢類型，不能把一次沒有 AAAA 記錄的正常回應，誤判為整個網域都無法解析。
- 沒有位址回應：先檢查拼寫、回應碼與解析器連線路徑。
- 有 A 位址但連線逾時：檢查該請求實際套用的規則與出站，不要繼續反覆更換 DNS。
- 只有 AAAA 路徑失敗：比較 IPv4 與 IPv6 的連線結果，再決定是否調整與位址系列相關的設定。
- 首頁能開啟，但部分資源載入失敗：檢查載入失敗資源所用的獨立網域；同一頁面可能會使用多個網域。
五、規則與 IPv6 為何會讓問題看起來像 DNS 故障
Global Routing 使用 Config 時，規則會參與出站選擇。DOMAIN-SUFFIX 依網域後綴比對，IP-CIDR 和 GEOIP 依位址相關條件判斷，FINAL 則處理前面的規則都未符合的請求。規則順序、是否需要解析，以及解析發生的位置，都會影響最後觀察到的行為。
以下為規則語法範例，僅用來說明比對對象。example.com 和 192.0.2.0/24 都是文件範例值，不是需要新增的網站或線路。不要將整段內容直接加到現有規則的末尾；現有的 FINAL 及其上方規則，可能會使新增內容不起作用。
[Rule]
DOMAIN-SUFFIX,example.com,DIRECT
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
FINAL,PROXYno-resolve 表示不會為符合這條 IP 規則而主動觸發網域解析；這不代表禁止所有 DNS，也不是修復解析失敗的開關。若網域規則命中後採用不適當的路徑，即使 DNS 正常，頁面仍可能無法開啟；應搭配請求記錄確認實際命中的項目，而非只檢視設定文字。
排查 IPv6 時必須有對照。取得 AAAA 記錄只代表解析器回傳了 IPv6 位址。若目前網路的 IPv6 連線不完整，可能會出現等待或回退情況。先記錄目前設定中的 IPv6 相關選項，再短暫進行單一項目的比較；不要同時變更 DNS、Global Routing 與 IPv6，否則無法判斷是哪一項影響結果。
六、常見問題與可重現的排查記錄
更換 DNS 後，為什麼結果還是一樣？
先在 Config 確認修改的是目前選取的檔案，儲存後返回 Home 重新連線，再開啟新分頁請求同一個網域。系統、瀏覽器與 App 都可能保留快取；不要把連續重新整理舊頁面當成已使用新解析器的證據。
Wi-Fi 無法開啟，行動網路卻可以，該怎麼辦？
維持相同的連線項目、Global Routing 與 Config，只切換網路進行比較。差異可能來自網路提供的 DNS、解析器的連線狀態或 IPv6 路徑；若目前使用 system，尤其要記錄切換網路這項變因。
延遲正常，但更新既有訂閱失敗，也是 DNS 的問題嗎？
先分辨是訂閱主機名稱解析失敗、連線逾時，還是 HTTP 回應錯誤。解析成功後若仍收到 401 或 403，請向自己的服務供應商確認授權與連結是否有效；修改 DNS 無法修復存取憑證。
切換成 Proxy 後可以開啟，就代表 DNS 修好了嗎？
不代表。將 Global Routing 改為 Proxy 可能同時改變出站與解析相關路徑。請還原原值，檢查 Config 中失敗請求命中的規則與回傳位址，再只針對已確認的異常調整設定。
若需要進一步尋求協助，提供可重現的條件比提供一張延遲截圖更有幫助。以下資訊應在同一輪測試中收集；請先移除記錄中的訂閱憑證、帳戶資訊與完整連線設定，只保留判斷問題所需的欄位。
- 入口：iPhone 或 iPad、Wi-Fi 或行動網路、是否啟用 On Demand。
- 狀態：Home 中的 Global Routing 值、目前的 Config 名稱、是否剛重新連線。
- 請求：失敗的網域、發生時間、A 或 AAAA 查詢結果、DNS 回應碼或原始錯誤訊息。
- 後續：已取得位址時的命中規則、出站選擇，以及問題發生於連線、TLS 還是 HTTP 階段。
- 比較：每次只變更的一個設定、變更前後的現象，以及還原原值後是否再次發生。
排查是否完成，不是看延遲數值有沒有降低，而是確認同一個網域能穩定解析、請求依預期規則出站，並收到頁面回應。若確認只有某個網域或某條網路路徑異常，保留有效的比較結果即可，不必繼續變更其他正常設定。