本文適用於已在 Shadowrocket（小火箭）匯入自有服務、連線開關運作正常，但無法存取網域的情況。請依序檢查伺服器連線、Global Routing、DNS、規則與網路環境，並透過單一變因測試，區分解析失敗、連線失敗與網站本身故障。文中的設定片段僅說明排查方法，不提供節點或訂閱。
一、延遲正常為何不代表網頁一定能開啟
延遲測試只反映該測試方法涵蓋的連線路徑。如果測試僅確認是否能連上伺服器連接埠，就無法證明目標網域能成功解析，也無法證明伺服器連往目標網站的連線正常。即使使用 HTTP 測試，結果也只適用於測試網址及當下的連線路徑，不能取代對實際故障網站的檢查。
瀏覽器開啟 HTTPS 網頁時，通常需要依序完成網域解析、連線至目標位址、TLS 交涉和 HTTP 請求。DNS 負責提供網域對應的位址；它無法修復已過期的伺服器憑證，也無法解除網站的存取限制。看到「連線正常」後，仍須確認請求在哪個階段停住。
| 觀察到的狀況 | 可能代表什麼 | 下一步檢查 |
|---|---|---|
| 伺服器延遲測試有結果 | 測試涵蓋的連線路徑可正常回應 | 目標網域解析與實際請求 |
| 網域查詢返回 A 或 AAAA | 已取得 IPv4 或 IPv6 位址 | 檢查位址是否可連線，以及 TLS 是否成功 |
| 網頁返回 HTTP 403 | 請求已到達可回應的 HTTP 服務 | 網站存取政策與出口限制 |
| 只有一個網站無法開啟 | 故障可能僅限於該網域或路徑 | 檢查相關規則、解析結果與網站狀態 |
結論：先確認故障發生在哪個階段
記下故障網域與原始錯誤訊息；若已有 HTTP 狀態碼，先檢查網站回應，不要一開始就更換 DNS。
二、先建立可重複的排查基準
開始前，先在 Config 備份目前的設定，並記下 Home 中目前選取的伺服器與 Global Routing 狀態。若最近更新過自有訂閱，也請記下更新後伺服器位址、連接埠及認證資訊是否有變動。訂閱能更新，只表示取得訂閱內容的請求成功，不代表其中每個服務項目都能使用。
-
記錄故障範例
選一個無法開啟的網域和一個平時可正常存取的網域，記下完整錯誤訊息、發生時間，以及目前使用的 Wi-Fi 或行動網路。後續每一輪都測試相同頁面，避免更換測試對象而造成誤判。
-
確認伺服器
在 Home 確認選取的伺服器，並執行目前可用的延遲或連線測試。如果伺服器本身無法連線，請先依自有服務的資料核對位址、連接埠及認證資訊，不要先嘗試修改 DNS 參數。
-
記錄路由模式
開啟 Home → Global Routing，記下目前使用 Proxy、Direct、Config 還是 Scene。排查期間固定模式；若使用 Scene，先確認實際生效的場景，避免網路切換時路由行為也跟著改變。
-
排除自動重新連線
檢查 Settings → On Demand。若要比較關閉與開啟連線的差異，請先記下原設定，再暫時停用自動觸發，以免關閉連線後又自動重新建立；排查完成後請還原原設定。
-
一次修改一項再測試
每次只修改一項設定，儲存後重新建立連線，再造訪相同的網域。記下結果後再決定保留或還原，不要同時更換伺服器、DNS 和整份設定。
三、DNS 設定須區分系統解析與設定覆寫
在 Config 開啟目前使用的設定，進入編輯畫面，檢查 [General] 中是否設有 dns-server。不要只查看其他未啟用的設定檔。若還使用其他 DNS 相關設定，也請一併記錄，避免修改的欄位被其他生效中的設定覆寫。
system 代表使用系統提供的 DNS，適合用來建立比較基準，但不表示所有網路都會取得相同的解析結果：Wi-Fi、行動網路及裝置上的 DNS 設定都可能影響系統解析。手動指定解析器時，則須確認目前的網路能連線至該解析器，而不只是確認位址填寫正確。
# 僅展示相關欄位；請勿使用此片段覆寫整份設定。
[General]
dns-server = system上方片段用來說明欄位位置。實際測試時，請在現有的 [General] 中修改對應行，保留其他設定，避免重複新增多個同名區段或欄位。先記下原值再儲存，重新建立連線並重測；若問題未改善，請還原原值，再檢查下一個階段。
| 項目 | 說明 | 排查重點 |
|---|---|---|
| A | 網域對應的 IPv4 位址記錄 | 取得結果後，檢查該 IPv4 路徑是否可連線 |
| AAAA | 網域對應的 IPv6 位址記錄 | 確認取得位址不代表 IPv6 連線路徑可用 |
| 傳統 DNS | 通常使用 UDP 53，必要時使用 TCP 53 | 確認目前網路是否限制查詢，或回傳異常結果 |
| DNS over HTTPS | 透過 HTTPS 傳送 DNS 查詢，通常使用 TCP 443 | 確認解析端點是否可連線，以及端點網域如何完成初始解析 |
| 解析快取 | 在有效期間內重複使用先前的結果 | 修改設定後，是否仍在使用舊連線或舊解析結果 |
加密 DNS 改變的是查詢傳輸方式，不代表能自動修復所有解析問題。若解析端點本身無法連線，或端點網域的初始解析失敗，同樣可能逾時。若瀏覽器或其他 App 使用自己的解析方式，結果也可能與 Shadowrocket 設定不同；測試時請固定使用同一個 App。
四、依錯誤訊息區分無記錄、伺服器失敗與逾時
以下是 DNS 診斷中常見的原始狀態或錯誤字串，不代表 Shadowrocket 在所有畫面都會原樣顯示。瀏覽器可能只顯示概略錯誤；請搭配目前可查看的記錄、請求紀錄或查詢結果判斷，不要只憑「網頁無法開啟」推測原因。
錯誤：NXDOMAIN
原因：回應端表示查詢的網域不存在；拼字錯誤、網域過期或解析回應異常都可能造成此結果。
解決方法：先確認完整網域名稱，再切換至另一個網路進行比較；若只有一種解析路徑出現此狀況，請記錄兩邊的結果，並檢查目前的 DNS 來源及本機覆寫設定。
錯誤：SERVFAIL
原因：解析器未能完成查詢，可能涉及上游查詢失敗、網域權威服務異常或驗證問題；這不等同於網域不存在。
解決方法：使用其他已知正常的網域，判斷是否為單一網域故障；接著保持路由不變，切換至已確認可連線的解析方式再次測試。
錯誤：connection timed out
原因：指定操作未能在時限內完成；只有確認逾時發生在 DNS 查詢階段，才能判定為解析逾時。
解決方法：先確認逾時的對象是解析器、伺服器還是目標網站，再檢查相應的連接埠與網路路徑，避免把目標網站的 TCP 逾時誤判為 DNS 故障。
沒有 AAAA 記錄不一定是錯誤：有些網域只提供 A 記錄。同樣地，查詢成功但沒有所要求類型的記錄，也不同於 NXDOMAIN。請一併記錄查詢名稱、記錄類型及回傳狀態，不要只記下「沒有 IP」。
五、解析成功後檢查 Global Routing 與規則
Global Routing 的 Proxy、Direct、Config、Scene 是路由運作方式，不是 DNS 伺服器選項。Proxy 用於代理路由，Direct 用於直接連線，Config 依目前設定處理，Scene 則依目前場景設定運作。切換模式可用來比較，但不能因此認定某種模式必定在本機或遠端完成所有解析。
若同一網域在 Proxy 下可正常存取、在 Config 下失敗，下一步應檢查 Config 中實際命中的規則。若 Direct 下可存取、Proxy 下失敗，則還須檢查伺服器連往目標網站的路徑。這兩種情況都不足以單獨證明 DNS 有問題。
# 僅說明規則語法與順序，不可直接用來替換完整設定。
[Rule]
DOMAIN-SUFFIX,example.com,DIRECT
IP-CIDR,192.0.2.0/24,REJECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXYDOMAIN-SUFFIX,example.com,DIRECT會比對該網域及其子網域。請檢查故障網域是否提早命中非預期的策略。IP-CIDR用於比對位址範圍；範例中的192.0.2.0/24是文件專用網段，並非實際服務位址。no-resolve用來避免為比對該 IP 規則而主動進行網域解析；這不代表整份設定停用 DNS，也不會阻止請求在其他階段取得位址。GEOIP依 IP 所屬地區進行比對；網域請求是否需要解析，須配合現有位址與規則參數判斷。FINAL放在規則末尾，用來處理前面都未命中的請求。請確認預設策略指向預期路徑，不要只檢查單一網域規則。
結論：已有位址仍無法連線時，接著檢查實際命中的策略
保持 DNS 不變，只比較 Proxy 與 Config 的存取結果；若差異持續出現，請優先找出命中的規則及其選用的出口，不要繼續疊加 DNS 修改。
六、Wi-Fi、行動網路與 IPv6 的比較方法
相同設定在 Wi-Fi 下失敗、在行動網路下成功，表示網路環境是重要變因，但不能直接斷定 Wi-Fi 的 DNS 出錯。網路也可能限制伺服器連接埠、影響 IPv6 路由，或要求先完成登入驗證。切換網路後請重新建立連線，並確認 Global Routing 與伺服器選擇沒有隨場景改變。
- 先完成網路驗證：若公共 Wi-Fi 要求登入，請先完成驗證流程，再測試 Shadowrocket。驗證前的重新導向或連線阻擋，可能導致多個網站同時無法開啟。
- 比較相同網域：在兩種網路下造訪相同頁面，記錄 DNS 是否取得結果、連線是否逾時，以及是否出現 HTTP 狀態碼；不要只比較延遲數值。
- 檢查 IPv6 路徑：若網域回傳 AAAA，但目前網路的 IPv6 連線無法使用，可能會出現載入停滯或部分資源失敗。請先確認故障請求實際使用的位址類型，再進行暫時比較，不要把停用 IPv6 當成通用解法。
- 排除快取影響：重新建立連線並重新開啟測試頁面。App 可能保留自己的 DNS 快取或連線池；必要時請結束並重新開啟該 App。重新連線不保證會清除所有 App 快取。
七、常見問題與排查完成條件
延遲一直正常，只要更換 DNS 嗎？
先在 Home 確認伺服器與 Global Routing，再檢查故障網域是否取得位址。若已收到 HTTP 錯誤或 TLS 錯誤，應轉而檢查相應階段；只有解析階段失敗時，才將 DNS 列為主要變因。
修改 dns-server 後，為什麼結果沒有變化？
在 Config 確認修改的是目前啟用的設定，並檢查是否有重複欄位或其他生效中的設定。儲存後重新建立連線、重新開啟測試 App，並以相同網域再次測試；也請留意 App 自行使用的 DNS 與快取。
只有一個網站無法開啟，需要重新建立設定嗎？
先確認網域拼字、該網域的解析結果，以及 Config 下實際命中的規則，再比較 Proxy 與 Direct 的結果。保留其他正常網站作為對照，不要只因一個網域就直接替換整份設定。
訂閱更新成功，為什麼網頁還是無法開啟？
訂閱更新與網頁存取是不同的請求。回到 Home 確認目前實際選取的伺服器，依自有服務的資料核對參數，再按照本文順序檢查目標網域、路由與 DNS；更新成功不能取代連線測試。
結束排查前，請分別以原先故障的網域和正常的對照網域再測試一次，並還原暫時停用的 On Demand 及原有場景設定。只保留能解釋改善原因的最少修改，撤銷無效的測試項目。若需要向自有服務的支援管道回報，請提供故障時間、網路類型、相關錯誤及已移除敏感資訊的設定片段，並刪除訂閱權杖、密碼及其他認證資訊。