本文適合 Shadowrocket（小火箭）已能連線、節點延遲測試也有結果，但網頁顯示找不到伺服器、部分網域長時間轉圈或訂閱更新失敗的情況。排查時先區分連線與解析，再核對 Settings → DNS、Global Routing 和目前的 config，最後利用 Log 判斷請求停在 DNS、規則比對還是代理出站。
延遲正常不代表 DNS 已可使用
Shadowrocket 對節點執行延遲測試時，測試目標、連線方式與網頁存取流程並不完全相同。延遲數值只能表示用戶端當下能以既有伺服器位址建立連線或進行探測，不能證明任意網域都能正確解析。存取網頁還要經過網域查詢、規則比對、建立 TCP 或 QUIC 連線、TLS 交握與內容傳輸，其中任何一步失敗，都可能呈現為頁面空白或持續載入。
DNS 的工作是將網域轉換為 IP 位址。若網域沒有取得結果，後續的 DOMAIN-SUFFIX、GEOIP、IP-CIDR 與 FINAL 規則可能無法依預期完成整個處理流程。若取得錯誤位址，用戶端也可能成功比對規則，卻連線至無法使用的目標。因此，「節點顯示 80 ms，但網頁打不開」不能直接歸因於節點速度。
連接埠數字僅用於理解查詢路徑，不表示需要手動開放或逐項填寫。現有的 config、服務商說明或目前網路可能指定不同的解析方式。排查時應先記錄原始設定，再一次只修改一個項目；同時更改 DNS、節點、Global Routing 和 config，會讓結果失去可比性。
Settings → DNS 各項設定如何理解
進入 Shadowrocket 的 Settings，再開啟 DNS 相關頁面。實際顯示的項目會受到目前設定與 config 影響，應以裝置上顯示的英文標籤為準。常見的 DNS Server 用於主要查詢，Fallback DNS Server 用於主要解析路徑失敗後的備援處理，Bootstrap DNS 用於先解析加密 DNS 服務本身的網域。Bootstrap DNS 不能取代所有一般查詢，它處理的是「要存取 DNS 服務，必須先知道該服務位址」這個起始問題。
System 或 system 表示採用系統提供的解析路徑。未主動填寫自訂位址，也未由 config 覆寫時，應保留用戶端目前顯示的初始狀態，不要只根據其他裝置的截圖照抄。匯入 config 後，[General] 中的 dns-server、fallback-dns-server 與 ipv6 等欄位可能改變實際行為，因此必須一併核對 Settings 頁面與目前的 config。
| 項目 | 作用 | 排查時的判斷 |
|---|---|---|
| DNS Server | 負責主要網域查詢 | 所有網域都沒有結果時，先檢查此項是否可連線、格式是否完整 |
| Fallback DNS Server | 主要查詢失敗時提供備援結果 | 主要解析偶爾逾時時，可暫時核對備援路徑是否也遭目前網路阻擋 |
| Bootstrap DNS | 解析 DoH 或 DoT 服務本身的主機名稱 | 加密 DNS 位址使用網域且在啟動階段失敗時，應優先檢查 |
| IPv6 | 控制或影響 AAAA 查詢與 IPv6 連線 | 網路僅部分支援 IPv6 時，可能先回傳 AAAA，但連線卻逾時 |
如果目前的 config 明確寫有 DNS 欄位，應以該 config 的處理邏輯為重點。以下是用來辨識語法的範例，不是要求照抄的公開設定；位址採用文件範例網段，不能作為實際 DNS 服務使用。
[General]
dns-server = system, 192.0.2.53
fallback-dns-server = system
ipv6 = false
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
GEOIP,CN,DIRECT
IP-CIDR,198.51.100.0/24,DIRECT
FINAL,PROXY結論：先確認誰在控制 DNS
Settings 與目前的 config 同時存在 DNS 設定時，不要只盯著其中一個頁面。先記錄目前啟用的 config，再檢查其中的 [General]，即可避免反覆切換 DNS Server 卻看不到變化。
依固定順序排查所有網域都打不開
所有網頁都顯示找不到伺服器時，先保持目前的節點與 config 不變，以便確認修改 DNS 前後的差異。排查過程中每完成一步，都使用同一個常用網域重新測試；重新開啟前先完全關閉先前失敗的頁面，避免瀏覽器繼續顯示舊錯誤。
確認連線狀態
返回 Home，確認頂端連線開關處於啟用狀態，目前節點名稱與 config 也都是預期項目。若開關立即彈回，先處理連線問題，不要進行 DNS 調整。
切換 Routing
在 Home 檢查 Global Routing。短暫改為 Proxy 測試一次，再改為 Direct 測試一次，最後恢復原本的 Config 或 Scene。只有 Config 失敗時，才應檢查規則與 config；多種模式都失敗時，再集中檢查 DNS 或本地網路。
核對 DNS
開啟 Settings → DNS，記錄 DNS Server、Fallback DNS Server、Bootstrap DNS 與 IPv6 的目前值。刪除剛才手動加入且來源不明的重複項目，保留應用程式原本狀態或使用者已確認可用的設定。
重建連線
回到 Home，關閉連線，等待數秒後再重新開啟。DNS 設定變更後應重建通道，單純重新整理網頁可能仍使用先前的工作階段或快取結果。
更換網路
在 Wi-Fi 與行動網路之間切換後，重複相同測試。僅某個網路失敗，表示排查重點應轉向該網路的解析可達性、IPv6 支援或存取限制，而不是持續更換 Shadowrocket 節點。
查看 Log
進入 Data 或 Settings 中可用的 Log 入口，重新開啟一個失敗網域，觀察是否出現 resolve、DNS、timeout、hostname 等相關記錄，並記下發生時間。
Global Routing 的四種常見模式可用來縮小範圍。Proxy 會讓支援的請求統一採用代理策略，Direct 會讓請求直接連線，Config 會依規則逐條比對，Scene 則依設定的使用情境選擇行為。暫時切換僅用於定位，測試完成後應恢復原本設定。若 Proxy 能開啟而 Config 無法開啟，優先核對 DOMAIN-SUFFIX、GEOIP、IP-CIDR 和 FINAL 的順序，不要繼續修改 DNS 位址。
錯誤：A server with the specified hostname could not be found.
原因與解法：系統沒有取得該主機名稱的可用位址，或取得的結果無法用於目前連線——先核對 Settings → DNS，再重建 Shadowrocket 連線，並查看 Log 是否有查詢逾時。
錯誤：The Internet connection appears to be offline.
原因與解法：連線鏈中的 DNS、路由或網路介面未完成請求——先確認 Home 開關保持穩定，再分別使用 Proxy 與 Direct 測試，判斷問題是否只出現在某種模式。
錯誤：Failed to load subscription
原因與解法：訂閱網域解析失敗、連結失效，或使用者自己的服務商限制了存取——使用原訂閱連結核對格式與有效性，例如 https://example.com/sub?token=xxxx 僅為格式範例，確認後再於 Home 下拉重新整理。
只有部分網域失敗時檢查規則與 IPv6
部分網站正常、只有少數網域失敗，通常表示主要 DNS 路徑並未完全中斷。此時需要判斷失敗網域是否被某條規則提前比對。例如 DOMAIN-SUFFIX,example.com,DIRECT 會讓該後綴走 Direct；如果目標只能透過代理路徑存取，就會呈現其他網站正常、該網域逾時。規則會依由上到下的順序比對，較具體的規則應放在較寬泛的規則之前，FINAL 負責承接前面未比對的請求。
GEOIP 會依據已解析出的目標 IP 判斷策略，IP-CIDR 則直接依位址段比對。如果 DNS 回傳與預期不同的位址，GEOIP 的結果也可能改變。排查時可在 Log 中找到失敗網域對應的解析結果、命中的規則關鍵字與最終策略，再回到 Config 檢查相關行，不要只根據網域所屬地區推測。
- DOMAIN-SUFFIX：檢查後綴是否完整，是否有更前面的 DOMAIN 或 DOMAIN-KEYWORD 規則先命中。
- GEOIP：檢查 DNS 是否先回傳可用 IP，以及規則選用的策略是否符合目前 config 的設計。
- IP-CIDR：檢查位址段與遮罩長度，例如 /24 與 /32 的比對範圍明顯不同。
- FINAL：檢查未命中前面規則的請求最後進入 PROXY、DIRECT 或其他策略群組。
- IPv6：若 Log 顯示 AAAA 結果後長時間等待，可在記錄原值後測試目前網路的 IPv6 可用性，並恢復與 config 一致的設定。
On Demand 也可能造成「換到某個網路才失敗」。開啟 Settings → On Demand，檢查是否依 Wi-Fi SSID、介面類型或網域條件啟用了不同的連線動作。若離開某個 Wi-Fi 後 Shadowrocket 未依預期連線，網頁錯誤看起來像 DNS 問題，實際原因可能是 On Demand 條件未觸發。測試時可先記錄規則，再暫時停用 On Demand，手動連線並重複測試同一網域。
更換 DNS 後仍失敗，如何繼續定位
更換 DNS Server 後沒有變化，不代表故障一定與 DNS 無關。舊的查詢結果可能仍保留在應用程式、系統或網頁程序中；加密 DNS 自身的網域也可能因 Bootstrap DNS 無法連線而無法啟動。正確做法是重建 Shadowrocket 連線、重新開啟測試頁面，並在同一時間查看 Log，而不是連續填入多個解析位址。
協定層也要與 DNS 層分開判斷。Shadowsocks、VMess、VLESS、Trojan、Hysteria2 與 WireGuard 的連線參數由使用者現有的服務設定決定。若 Log 已顯示網域成功解析並命中預期策略，但接著出現連線逾時或交握失敗，排查重點應從 DNS 轉向目前節點、協定參數、網路封包遺失或伺服器端狀態。DNS 只負責取得位址，無法修復後續傳輸問題。
錯誤：DNS request timed out
原因與解法：查詢已送出，但在限定時間內沒有回應——切換 Wi-Fi 與行動網路進行對照，檢查傳統 DNS 的 53 連接埠，或加密 DNS 使用的 443、853 路徑是否能在目前網路連線。
錯誤：Could not connect to the server.
原因與解法：如果前面的 Log 已記錄解析結果，這通常屬於解析後的連線階段——核對命中策略、目前節點狀態與協定參數，不要再反覆切換 DNS。
- 記錄失敗時間、網路類型、Global Routing 模式、目前 config 與節點名稱。
- 在 Log 中確認是否出現網域查詢，以及查詢是否回傳 A 或 AAAA 位址。
- 有位址時，繼續確認命中的 DOMAIN-SUFFIX、GEOIP、IP-CIDR 或 FINAL 規則。
- 規則正確但連線逾時時，再檢查節點連線、協定參數與使用者自己的服務狀態。
- 訂閱更新單獨失敗時，核對訂閱網域、連結有效性與服務商提供的更新要求。
結論：以 Log 中最後成功的一步劃分責任層
沒有解析結果就處理 DNS；已有 IP 但策略不正確就處理 Config；策略正確但交握失敗就處理節點與協定。依最後成功的步驟向後排查，比反覆更換 DNS Server 更有效率。
恢復穩定設定並保留排查記錄
完成定位後，應將暫時使用的 Global Routing 恢復為原本的 Config、Proxy、Direct 或 Scene，將 On Demand 恢復到測試前狀態，並刪除僅為排錯而加入的重複 DNS 項目。若問題來自 config 中的規則，只修改已確認有誤的行；若問題來自目前網路，則保留另一網路的對照結果，方便之後重現。
向使用者自己的服務商回報時，提供故障發生時間、使用的網路類型、失敗網域、Shadowrocket Log 中與該請求相鄰的幾行，以及是否能在 Direct 和 Proxy 下重現。訂閱內容與存取憑證屬於敏感資訊，截圖前應遮蓋 token、伺服器位址中的驗證資訊與 WireGuard 私鑰。
Shadowrocket 是 Apple 平台的付費商業應用程式，iPhone 與 iPad 是主要使用裝置，Mac、Apple TV 和 Apple Vision 的相容性及系統要求以 App Store 頁面標示為準。唯一取得入口是 App Store，開發者應顯示為 Shadow Launch Technology Limited，應用程式 ID 為 932747118。用戶端一次買斷與線路服務是兩項獨立內容，購買用戶端不代表取得節點或訂閱。