Shadowrocket（小火箭）的延遲測試結果，只能證明測試目標當下可連線，無法證明網頁網域已成功解析。本文假設你已有自己的服務資訊與訂閱，依序檢查基本網路、DNS 回應、Global Routing、IPv6 與設定覆蓋問題。先保留原設定，每次只調整一個變數，再以相同網域重新測試。
一、為什麼延遲正常，網頁仍然無法開啟
瀏覽網頁不只是測一次延遲。瀏覽器通常會先將網域解析為 IP 位址，再建立連線、完成 TLS 握手，最後載入頁面內容。如果測試只探測伺服器位址或特定測試目標，就不會涵蓋目標網頁使用的 DNS、分流規則與憑證驗證流程。即使測試顯示延遲只有幾毫秒，也不能據此排除解析問題。
這個流程可用來判斷問題發生在哪個階段，但不代表 DNS 查詢與網頁請求一定走相同的連線路徑。設定可能會指定 DNS 的傳送方式，部分連線也可能在遠端處理網域。因此，「節點延遲正常」與「本機 DNS 正常」是兩回事。
- 所有網站都無法開啟：先檢查基本網路、隧道狀態，以及 DNS 上游是否可連線，不要急著修改單一網站的規則。
- 只有一個網域無法開啟：檢查網域拼字、DNS 回應與命中的規則；也可能是網站本身發生問題。
- 首頁可開啟，但圖片或登入失敗：記下失敗資源實際使用的網域，不要只測試網址列中的主網域。
- 出現憑證警告或 HTTP 403：問題已進入其他故障階段，不能只因「頁面沒開啟」就判定是 DNS 解析失敗。
二、先建立可重現的排查基準
開始前，先在 Home 記下目前選取的連線，在 Config 記下正在使用的設定，並另存一份副本。後續測試都使用同一個完整網址，並記錄網路類型、時間、Global Routing 模式與錯誤狀況。不要同時更新訂閱、更換連線、修改 DNS 和規則，否則無法判斷是哪項變更造成影響。
- 檢查基本網路：暫時中斷 Shadowrocket，開啟平常可正常瀏覽的網站。若公共 Wi-Fi 需要網頁認證，請先完成認證；基本網路無法連線時，優先處理 Wi-Fi 或行動網路問題。
- 控制自動重新連線：前往 Settings → On Demand，檢查是否啟用了自動觸發。為了進行中斷連線的對照測試，可暫時停用相關觸發條件，排查完成後再恢復，避免誤將自動重新連線當成手動中斷測試。
- 重現一次故障：重新連線後開啟故障網址，記錄是長時間等待、網域錯誤、連線逾時，還是 TLS 錯誤。瀏覽器籠統的錯誤訊息無法取代 DNS 查詢結果。
- 切換網路重新測試：情況許可時，讓同一台裝置從 Wi-Fi 切換至行動網路，連線與設定維持不變。若只有特定網路發生問題，再著重檢查該網路能否傳送 DNS 或連線至目標位址。
- 查看相關記錄：搭配 Shadowrocket 的連線記錄、DNS 查詢結果或目前可用的診斷工具，核對故障網域、回傳位址與實際套用的策略；實際操作入口以目前介面為準。
不要把「直接開啟網站 IP」當成通用驗證方式。HTTPS 網站可能依賴網域對應的 SNI、憑證與虛擬主機；直接連線 IP 失敗，並不能證明網路不通。
三、區分 DNS 回傳錯誤與查詢無回應
DNS 故障大致分為兩類：伺服器明確回傳錯誤，或查詢一直沒有收到有效回應。兩者的處理方式不同。以下列出的是 DNS 協定中的實際狀態名稱，不保證 Shadowrocket 或瀏覽器會逐字顯示這些訊息；有些記錄只會籠統標示解析失敗或逾時。
錯誤：NXDOMAIN
原因：回應表示查詢的名稱不存在，也可能是本機對應設定錯誤，或上游回傳異常。處理方式：先核對完整網域，再透過另一條已知可用的解析路徑查詢相同記錄；名稱不存在時，延長等待時間並無幫助。
錯誤：SERVFAIL
原因：解析器未能完成查詢，可能與上游權威伺服器、驗證流程或暫時性服務故障有關。處理方式：用同一個解析器查詢另一個正常網域，再交叉查詢故障網域，以區分解析器整體故障與單一網域問題。
錯誤：REFUSED
原因：伺服器拒絕處理查詢，常見原因包括存取控制，或不允許目前來源進行遞迴查詢。處理方式：確認 DNS 服務的適用範圍，改用目前網路或既有設定允許使用的解析器。
如果完全沒有收到回應，請優先檢查 DNS 伺服器位址、傳輸方式與連線路徑。請注意，NOERROR 不代表一定取得可用位址：查詢成功但對應記錄類型不存在時，答案區仍可能為空。若只有 AAAA 查不到、A 記錄正常，並不代表整個網域解析失敗。
- A：回傳 IPv4 位址，用來確認 IPv4 解析是否正常。
- AAAA：回傳 IPv6 位址；取得位址後，還要確認目前網路具備可用的 IPv6 路徑。
- CNAME：表示別名，後續仍須解析其指向的名稱；主網域有回應，不代表整條別名鏈都正常。
四、各項 DNS 設定的用途
Shadowrocket 實際採用的 DNS 行為，需依目前設定判斷。請在 Config 檢查目前啟用的設定及其 General 項目；若以文字檢視，對應的是 [General] 等相關設定區段。不要只憑另一份未啟用設定中的數值判斷目前狀態，也不要把服務資訊中的伺服器位址誤填為 DNS 伺服器。
| 設定或概念 | 用途 | 調整時機與注意事項 |
|---|---|---|
dns-server |
指定 DNS 上游；支援的位址格式與傳輸方式，請依目前應用程式設定說明填寫。 | 確認目前使用的上游無法連線或回應異常後，再進行調整。填入多個位址，不代表一定會固定逐一依序嘗試。 |
system |
在支援此設定值的 DNS 設定中，使用目前系統網路提供的解析器。 | 可用於恢復原設定作對照；實際使用的伺服器可能隨 Wi-Fi、行動網路或網路管理設定而變動。 |
fallback-dns-server |
設定備用解析上游，作為主要解析流程之外的補充。 | 實際啟用條件依目前設定機制而定，不能視為所有失敗的查詢都會自動修復。 |
ipv6 |
影響 IPv6 相關處理；需配合系統、隧道與實際網路能力判斷。 | 若 AAAA 正常回應但 IPv6 連線失敗，可透過單一變數對照測試；不要把停用此設定當成所有 DNS 故障的通用解法。 |
[Host] |
設定本地域名對應，可能影響特定網域最後使用的位址。 | 只有少數網域異常時才檢查舊對應。網站位址可能變動，不宜長期以臨時 IP 取代正常解析。 |
若使用以網域名稱指定的加密 DNS 端點，還得先解決端點本身的名稱解析與連線問題。端點無法建立連線時，只把一般 DNS 改成加密 DNS，並不會自動恢復存取；還要檢查憑證驗證、裝置時間及端點使用的連線路徑。
結論：先確認上游可連線，再調整解析方式
連接埠號只能協助辨認傳輸類型，無法證明端點可用。如果目前網路無法連線至同一個上游，請先恢復已驗證可用的設定，再分別測試一般 DNS 與加密 DNS，保留實際能回傳正確答案的方案。
五、利用 Global Routing 判斷解析或分流問題
前往 Home → Global Routing 確認目前模式。日常使用規則設定時，通常需留意 Config；暫時切換至 Proxy 或 Direct 可作為對照，但無法保證涵蓋所有獨立的 DNS 設定。Scene 涉及情境選擇，不應視為固定的直連或代理策略。
| 模式 | 排查用途 | 結果判讀 |
|---|---|---|
| Config | 依目前設定檢查請求命中的規則與策略。 | 只有此模式無法連線時，請優先檢查規則順序、策略群組選擇及設定中的 DNS 項目。 |
| Proxy | 暫時對照經由代理路徑能否連線至目標網站。 | 恢復存取表示值得檢查連線路徑，但不能單獨證明 DNS 已修復。 |
| Direct | 暫時觀察直接連線至目標的結果。 | 只有在目標本身允許且能夠直接連線時，這項對照才有參考價值。 |
| Scene | 確認目前情境實際選用的設定與行為。 | 先確認情境內容，避免將切換情境造成的差異，誤判為隨機 DNS 故障。 |
如果已取得正確 IP，但連線仍逾時，請繼續檢查連線策略。網域規則與 IP 規則並不相同：DOMAIN-SUFFIX 比對網域後綴，IP-CIDR 比對位址網段，GEOIP 依據位址歸屬資料庫，FINAL 處理前面未比對到的請求。需要目標 IP 才能比對的流程可能涉及解析；使用 no-resolve 時，不應期待規則為了比對而主動發起解析。
[Rule]
DOMAIN-SUFFIX,example.com,DIRECT
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY以上僅為規則語法範例，不建議直接取代目前設定。example.com 是示範網域，PROXY 也必須在目前設定中代表可用的策略。診斷時先查看實際命中記錄：若上方較廣泛的規則已命中，後續修正規則便不會再生效；FINAL 應置於末尾。
六、解析成功仍無法連線：檢查 IPv6、快取與設定覆蓋
DNS 回傳位址只是完成第一步。若 A 與 AAAA 都有結果，但某個網路的 IPv6 路徑異常，瀏覽器可能先等待失敗的路徑，再嘗試另一條路徑，造成畫面長時間載入或時好時壞。此時應確認連線使用的位址類型，不要繼續反覆更換 DNS。
- 比對位址類型：記錄故障連線使用 IPv4 還是 IPv6。必要時可在設定副本中調整 IPv6 相關選項進行測試；保留原設定，並依測試結果決定是否還原。
- 排除快取影響：修改設定後，重新建立連線並再次載入網頁。瀏覽器、系統與解析器可能各自保留快取，單次重新整理不一定會觸發新的 DNS 查詢。
- 確認目前生效的設定：返回 Config，確認啟用的仍是剛才修改的那份設定。修改了副本卻沒有啟用，經常會讓人以為「修改沒有作用」。
- 區分兩種更新：Home 中既有的 Subscribe 更新，主要用於重新整理相關服務資訊；遠端 Config 更新則可能覆蓋設定內容。不要把重新整理訂閱當成修復 DNS 參數的必要步驟。
- 確認變更是否遭覆蓋：如果每次更新遠端設定後都再次發生故障，請比對更新前後的 DNS、Host 與 Rule 內容，確認本機修改是否遭到取代。
不要將完整訂閱連結、認證資訊或未處理的記錄檔傳給他人。尋求協助時，提供錯誤類型、目標網域、網路類型與策略名稱即可；請先刪除帳號與權杖等敏感資訊。
七、依據證據判斷：何時可以停止修改 DNS
完成排查後，應能指出問題屬於「查詢無回應」、「明確錯誤回應」、「回傳錯誤位址」，還是「位址正確但連線失敗」。如果每次查詢都能回傳預期位址，而記錄顯示故障發生在建立連線或 TLS 握手階段，就應停止修改 DNS，改查既有服務的連線狀態、目標網站、裝置時間與策略路徑。
- 可確認與 DNS 有關：同一網域透過原上游查詢失敗，改用另一條已驗證可用的解析路徑後成功；其他條件維持不變時，網頁也恢復正常。
- 較像分流問題：DNS 結果相同，只有 Config 模式無法連線；調整實際命中的規則後恢復正常。
- 較像網路路徑問題：設定不變，Wi-Fi 無法連線但行動網路正常，或只有某個位址類型無法連線。
- 較像目標端問題：只有一個網站異常，解析正常，而其他網站在相同連線與策略下都能開啟。
向自己的服務提供者回報時，提供發生時間、使用 Wi-Fi 或行動網路、故障網域、DNS 回應狀態、回傳的位址類型，以及 Config 與暫時對照模式的差異。回報「網域查詢回傳 SERVFAIL」比只說「延遲正常但無法使用」更有助於定位問題。完成後，請恢復暫時停用的 On Demand，並保留最終可用設定的副本。