Shadowrocket（小火箭）的延遲數值，無法證明網頁存取路徑完整。已有服務商與訂閱的使用者，應先固定網路、目標網址和出站項目，再檢查 DNS 解析、Global Routing 全域路由與連線錯誤。本文依照可重現的順序，說明如何分辨解析失敗、規則選錯和出站連線失敗；每次只變更一項，避免反覆更換 DNS 掩蓋真正原因。
一、延遲正常，只代表測試涉及的環節有回應
開啟網頁需要經過網域解析、建立連線、TLS 交握和內容請求。DNS 的作用是將網域解析為 IP 位址；取得位址後，連線仍可能遭目標埠、網路路徑、憑證或伺服器狀態阻擋。延遲測試使用的目標和測試方式不同，涵蓋的環節也不同，不能只憑一個毫秒數判定網頁是否可用。
這個流程用於定位問題，不表示所有請求都嚴格依照相同順序解析。網域規則可能在取得 IP 之前命中，部分出站方式也可能將網域交由遠端處理。應以目前的設定和請求記錄為準，不要假設所有網域都由同一台 DNS 伺服器解析。
- 伺服器位址可連線：只能表示測試涵蓋的位址和埠有回應，不代表任何網站都能成功存取。
- 某個測試網址可存取：只能表示該目標當時可用，其他網域可能套用不同規則或使用不同位址類型。
- 網頁持續載入：原因可能是 DNS 等待，也可能是連線、交握或某項頁面資源逾時，必須進一步查看錯誤訊息。
二、先看懂 DNS 設定，別把埠號和解析器混為一談
先在 Config 設定中確認目前選用的設定檔，再查看其中的 DNS 設定。設定檔的 [General] 區段可以包含 dns-server；system 代表使用系統 DNS。如果設定中已填入其他解析器，修改前請先保存原值，不要直接覆蓋整個區段。
[General]
dns-server = system這段內容只用來辨識欄位，不是完整設定，也不是要求所有網路都改成 system。系統 DNS 會受目前連線的網路影響；自訂 DNS 則需要確保相應位址和傳輸路徑可連通。加密 DNS 保護的是查詢傳輸過程，不代表目標網站一定能建立連線。
以上數字是協定常用埠號，不是需要依序填入 Add Server 新增伺服器頁面的參數。出站伺服器的 Port 埠號必須與服務商提供的參數一致。DoH 使用 HTTPS 請求路徑，不能把只有 IP 位址的字串直接當成完整的 DoH 位址。
結論：先檢查解析結果，再決定是否更換 DNS
如果同一次請求已取得目標 IP，之後才出現連線逾時，應先檢查出站路徑與目標埠；只有在有查詢失敗、回傳異常位址或位址類型差異等證據時，才需要繼續從 DNS 方向排查。
三、用五個步驟建立可重現的排查記錄
先選一個平常可存取、目前又能穩定重現問題的網址。記錄完整網域、測試時間、連線的網路和錯誤訊息。不要同時切換網路、出站項目、DNS 和規則；否則即使頁面恢復，也無法判斷是哪個項目造成影響。
- 確認網路已完成連線。在可信任的網路中完成可能出現的網頁認證。分別記錄關閉和開啟連線開關後的結果；這項對照只用來判斷問題範圍，不代表所有目標在兩種狀態下都必須可用。
- 確認目前的出站項目。返回 Home 首頁，確認連線開關與選取的項目。如果項目來自 Subscribe 訂閱，請向你的服務商取得連結。確認訂閱狀態和項目參數；更新成功不代表伺服器一定可連線。
- 記錄路由模式。開啟 Home 首頁 → Global Routing 全域路由，記下目前選用的是 Config 設定、Proxy 代理、Direct 直連還是 Scene 情境。Scene 情境還需要確認生效條件，不能只憑名稱判斷實際路徑。
- 在相同條件下送出一次請求。前往同一個網址，檢查可用的請求記錄或日誌，查看網域、解析位址、命中規則、出站策略和錯誤訊息。未記錄的欄位應標記為未知，不要自行推測。
- 每次只變更一項，再重新測試。例如保留其他條件不變，比較 Config 設定與 Proxy 代理，或比較目前 DNS 與已確認可連通的解析方式。每輪都記錄結果；若沒有改善，先還原原值，再驗證下一個假設。
四、依錯誤訊息分辨解析、連線與憑證問題
以下列出的是網路日誌中常見的錯誤原文片段，不保證每個介面都會顯示這些字串。同一個問題可能顯示為瀏覽器提示、請求記錄中的簡短錯誤，或更底層的日誌。判斷時要一併確認錯誤所屬的網域：出錯的對象可能是目標網站，也可能是出站伺服器或 DNS 端點。
錯誤：no such host
原因：目前的解析程序無法取得所需的主機位址，也可能是網域拼寫錯誤。
處理方式：先核對錯誤訊息中的網域，再檢查目前 DNS 是否可連通；若出錯的是出站伺服器網域，應先處理該網域的解析問題，而不是修改目標網站規則。
錯誤：i/o timeout
原因：某次網路讀取或寫入超過等待時間，可能發生在 DNS 查詢、建立連線或後續傳輸。
處理方式：查看錯誤前面的位址和操作階段；查詢逾時時檢查解析器路徑，連線逾時時則核對出站位址、Port 埠號和目前網路。
錯誤：connection refused
原因：該連線嘗試收到拒絕回應，常見原因是目標埠沒有服務正在監聽，或網路設備主動拒絕連線。
處理方式：確認遭拒絕的是網站還是出站伺服器，並核對相應埠號；若使用的是服務商提供的出站參數，請向自己的服務商確認狀態。
錯誤：certificate has expired or is not yet valid
原因：憑證有效期限與目前時間不符，可能與裝置時間、網站憑證或出站 TLS 端點有關。
處理方式：先核對系統日期和時間，再確認錯誤所屬的網域；保留憑證驗證，不要以關閉驗證取代問題修復。
如果網站已回傳 HTTP 403 或 HTTP 404，通常表示該請求已到達某個 HTTP 服務，不應再把這項回應視為單純的 DNS 查無結果。此時應檢查目標位址是否正確、網站存取條件和伺服器狀態；若懷疑解析到錯誤的服務，再核對 DNS 回傳值。
五、解析成功後，繼續檢查規則與 IPv6 路徑
在 Config 設定模式下，請求會受到目前設定檔中規則的影響。DOMAIN-SUFFIX 網域後綴規則與 IP-CIDR 位址範圍規則適用的對象不同；GEOIP 位址歸屬規則依據 IP 判斷；FINAL 是最後的兜底規則。已有解析結果，不代表請求一定會經過預期的出站路徑。
[Rule]
DOMAIN-SUFFIX,example.com,DIRECT
FINAL,PROXY以上只用來說明規則順序：example.com 及其子網域符合 DIRECT 直連，其餘請求則由 FINAL 使用 PROXY 代理策略兜底。這不是完整設定，也不是適用於所有使用者的建議規則。如果網域先命中前面的 REJECT 拒絕規則，通常無法透過更換 DNS 改變匹配結果。
| 對照現象 | 優先檢查 | 下一步 |
|---|---|---|
| Proxy 可存取，Config 無法存取 | 目前設定中的規則、策略與相關覆寫設定 | 查看該網域命中的規則和實際出站路徑，不要直接歸因於 DNS。 |
| 同一設定在不同網路下表現不同 | 網路認證、解析器連線狀態、UDP 與位址類型路徑 | 保留網址和出站項目，只切換連線的網路並記錄差異。 |
| 回傳 A 與 AAAA，但部分連線逾時 | IPv4 與 IPv6 的實際連線狀況 | 檢查失敗連線使用的位址類型，再進行單一變數對照。 |
| 主頁面可開啟，圖片或登入失敗 | 資源子網域及其規則、解析與出站路徑 | 記錄失敗資源的網域，逐一檢查，不要只測試主網站的網域。 |
A 記錄提供 IPv4 位址，AAAA 記錄提供 IPv6 位址。DNS 正確回傳 AAAA，不代表目前網路具備可用的 IPv6 路徑；同樣地，出現 IPv6 位址也不代表問題一定由它造成。只有在對照結果顯示與位址類型差異有關時，才檢查相關 IPv6 設定，並保留還原方式。
另一個容易忽略的環節是快取。瀏覽器、系統和中間解析器可能保留結果；變更 DNS 後重新整理一次，不一定代表重新執行了查詢。可以先重新建立連線並重新開啟頁面，再根據新的請求記錄判斷；不要一開始就清除所有瀏覽資料。
六、常見問題與還原檢查
延遲只有幾十毫秒，為什麼還要檢查出站連線？
延遲數值無法涵蓋任意網站的完整請求。返回 Home 首頁確認選取的項目，再記錄失敗網址的連線階段；測試目標可連線，但目標網站的 443 埠無法連線，這兩種情況可能同時發生。
把網址換成 IP 位址，就能確認是不是 DNS 問題嗎？
不能直接這樣判斷。HTTPS 需要透過網域進行憑證驗證和虛擬主機選擇；直接存取 IP 可能出現憑證錯誤或連到其他網站。應查看解析和連線記錄，不要把 IP 存取失敗當成 DNS 問題的結論。
換了 DNS 還是打不開，還要繼續換嗎？
先確認是否已取得位址。若取得位址後才逾時，請還原原有 DNS，繼續核對 Global Routing 全域路由、實際出站路徑與 Port 埠號；若是查詢本身逾時，再檢查解析器的傳輸路徑。
只有訂閱更新失敗、網頁正常，需要修改 DNS 嗎？
先分辨是訂閱網域解析失敗，還是 HTTP 狀態錯誤。連結請向你的服務商取得，並確認內容完整且仍有效；網頁正常不代表訂閱網址正常，但也不足以證明整體 DNS 有問題。
問題排除後，應恢復日常使用的 Config 設定與預期策略，還原原有的 On Demand 隨需連線條件，再重新測試主頁面、圖片、登入等必要資源。如果只有暫時切換到 Proxy 代理時成功，應繼續調整規則，不要把暫時對照的結果當成已找到 DNS 問題。
- 保留一份已驗證可用的設定備份，並記錄最後只變更了哪一項。
- 向服務商說明問題時，提供發生時間、網路類型、協定、目標網域和錯誤訊息。
- 分享日誌前，請遮蔽訂閱 token、UUID、密碼和完整憑證；不必公開完整的訂閱連結。