Shadowrocket（小火箭）顯示延遲正常，不代表網頁請求的整個流程都正常。請先區分 DNS 解析失敗、規則選錯出站與連線交握失敗，再檢查目前 Config 的 DNS 設定；每次只修改一項，並用同一個網域重新測試。本文適合已有服務商與訂閱、可以連線但無法正常瀏覽網頁的使用者，重點在找出故障環節，而非反覆更改設定。
一、延遲正常，為什麼網頁還是無法開啟？
延遲測試結果取決於測試方式：可能只確認與伺服器的連線，也可能連線至指定的測試網址。即使測試成功，也無法證明所有網站的網域都能解析、所有規則都能正確比對，或目標網站的 TLS 交握一定成功。因此，「顯示延遲數值」只能證明部分連線路徑可用。
這個流程是排查模型，並非固定的內部執行順序。網域規則可能在解析前命中；IP 類規則可能需要先取得位址；代理出站也可能由遠端解析目標網域。若伺服器位址本身使用網域，還需先解析伺服器位址，之後才有機會建立代理連線。
- 所有網域都無法使用：優先檢查 DNS 服務是否可連線、目前設定是否生效，以及基礎網路是否需要登入認證。
- 只有特定網域無法使用：檢查對應的解析結果與命中規則，不要直接重設所有網路設定。
- 文字有顯示，圖片卻無法載入：頁面資源可能來自其他網域，請分別檢查載入失敗的資源請求。
- 已取得位址但仍逾時：接著檢查出站、IPv6 路徑與目標服務，不要直接判定是 DNS 故障。
二、先做基本比對：逐項確認網路、模式與設定
先記下目前使用的網路、Home 中選取的伺服器、Global Routing 的設定，以及 Config 中正在使用的設定檔。保留這些紀錄，才能在測試後還原原本狀態。請勿在同一次測試中同時更新訂閱、切換伺服器並修改 DNS，否則無法判斷是哪個步驟造成變化。
- 檢查基礎網路。暫時中斷 Shadowrocket 連線，在目前的 Wi-Fi 或行動網路下開啟平常可直接連線的網站。若公共 Wi-Fi 顯示認證頁面，請先完成認證；基礎網路無法使用時，修改 DNS 通常無法解決問題。
- 重新連線並重現問題。返回 Home，確認使用的是自己的有效連線設定，再開啟同一個無法連線的網域。記下發生時間，方便在請求紀錄或日誌中找到對應項目。
- 確認 Global Routing。日常使用規則設定時選擇 Config。暫時切換至 Proxy，可協助判斷故障是否與分流有關；Direct 則用來比對目前網路的直連情況。測試完成後請還原原本模式。
- 確認實際使用的設定。進入 Config，確認選取的是要檢查的設定，而不是只編輯了另一個未啟用的檔案。若正在使用 Scene，請先確認該場景對應的模式與設定，避免場景變更影響測試條件。
- 固定測試目標。分別記錄「開啟首頁」、「重新載入無法開啟的頁面」及「前往另一個網域」的結果。某個網域恢復正常，不代表所有問題都已解決。
三、DNS 設定項目：先了解用途，再修改目前的 Config
進入 Config，開啟目前使用的設定並進入編輯畫面，檢查 DNS 相關項目；若使用文字設定，請特別檢查 [General] 下的 dns-server。畫面項目會依實際設定與 App 介面而異，請勿將系統 Wi-Fi 的 DNS、設定中的 DNS 與瀏覽器自己的加密 DNS 當成同一個入口。
| 項目或概念 | 實際用途 | 排查重點 |
|---|---|---|
dns-server | 設定所使用的 DNS 伺服器來源；支援的格式請以 App 目前的說明為準。 | 確認拼寫、位址格式與連線狀態，勿一次輸入大量未經驗證的位址。 |
system | 使用系統提供的 DNS 來源。 | 適合用來比對；若目前網路的 DNS 有問題，使用系統來源也可能無法連線。 |
| DNS over HTTPS | 透過 HTTPS 傳送 DNS 查詢，通常使用 TCP 443。 | 需要完整且正確的服務端點；其主機名稱解析、TLS 與網路連線都必須正常。 |
| DNS over TLS | 透過 TLS 傳送 DNS 查詢，標準服務通常使用 TCP 853。 | 確認網路是否允許連線至對應連接埠，以及憑證所屬的主機名稱是否正確。 |
| IPv6 與 AAAA | AAAA 記錄提供 IPv6 位址；取得位址與能夠連線是兩回事。 | 若取得 AAAA 結果但 IPv6 路徑異常，網頁可能會等到逾時後才嘗試其他位址。 |
| Fallback | 符合對應條件時，使用備用解析來源。 | 先確認觸發條件，不要假定所有備用來源都會同時查詢，或自動回傳最快的結果。 |
若要進行基本比對，可先儲存原設定的副本，再只將 DNS 來源改為系統來源。以下是文字設定中相關項目的範例，並非完整設定，也不應覆蓋現有檔案的其他內容：
[General]
dns-server = system儲存後，確認該設定仍處於啟用狀態，再中斷並重新連線進行測試。如果系統來源可用，但原本的加密 DNS 無法使用，請接著檢查原端點的連線路徑。加密 DNS 的主機名稱本身可能需要預先解析；若無法建立連線，反覆重新載入網頁也無法繞過這個前提。
四、檢查規則命中情形：解析成功也可能走錯出口
在 Home 將 Global Routing 暫時從 Config 改為 Proxy 後，若同一個網頁恢復正常，表示故障可能與規則選擇、直連路徑，或不同出站下的解析行為有關，但這不足以單獨證明原本的 DNS 有問題。請切回 Config，繼續檢查請求實際命中的規則。
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY以上僅用於說明語法：example.com 與 192.0.2.0/24 是文件範例，不代表要造訪的服務或應照抄的分流策略。實際規則依設定順序由上而下比對，命中第一條後即停止；FINAL 放在最後處理其餘請求。
DOMAIN-SUFFIX：比對網域後綴。檢查是否將目標網域或其資源網域提前導向不適用的出站。IP-CIDR：比對目標 IP 網段。範例中的no-resolve用來避免只為比對這條規則而主動解析網域；這不代表 App 存取目標時永遠不需要 DNS。GEOIP：依位址所屬地區資料庫比對。網域請求是否需要先解析，取決於比對流程與相關設定，不能只憑規則名稱下結論。FINAL：處理前面未命中的請求。若最終出站無法使用，即使 DNS 已回傳位址，仍然無法連線。
結論：先找出失敗請求命中的規則，再決定要修改 DNS 或出站
Proxy 可用但 Config 不可用時，請先切回 Config 並查看該網域的請求紀錄；只有證據顯示解析逾時或回傳錯誤位址時，才修改 DNS。若紀錄已顯示目標位址並進入連線階段，應優先檢查命中規則與出站。
五、從日誌區分解析失敗、逾時與 TLS 錯誤
在 App 的請求紀錄或日誌中，依照剛才無法連線的時間與網域尋找項目。不同網路層回傳的用語可能不同，以下列出的是可能出現在日誌中的錯誤片段，並非所有介面都會顯示相同文字。判斷時應一併確認錯誤發生在哪個位址、哪個階段。
錯誤：no such host
原因：解析階段未取得可用的主機位址；可能是網域錯誤、記錄不存在，或上游回傳否定結果。
解決方式：先確認網域拼寫，再在相同網路下使用另一個解析來源比對；若只有服務商提供的伺服器網域無法解析，請向自己的服務商確認位址是否有效。
錯誤：i/o timeout
原因：某項網路操作未能在時限內完成；可能發生於 DNS 查詢，也可能發生於出站連線，不能只憑這幾個字判定原因。
解決方式：檢查前後日誌，確認指向的是 DNS 伺服器、網站或代理伺服器；只有逾時發生在 DNS 查詢階段時，才測試其他解析來源。
錯誤：connection refused
原因：連線目標明確拒絕請求，通常應檢查目標服務與連接埠，而非繼續等待解析。
解決方式：確認實際連線的位址與連接埠；若遭拒絕的是加密 DNS 端點，請檢查該服務是否正在對應連接埠上監聽。
錯誤：certificate verify failed
原因：TLS 憑證驗證未通過，可能與裝置時間、端點主機名稱或憑證鏈有關。
解決方式：檢查系統日期與時間及端點位址，並向相關服務商確認設定；不要藉由停用憑證驗證來掩蓋問題。
若日誌已顯示解析出的 IP，接著卻出現連線或 TLS 錯誤，排查重點就應移至相應階段。也不要直接在瀏覽器網址列輸入網站 IP 來測試 HTTPS：憑證名稱、SNI 與虛擬主機選擇都可能因此改變，這並不等同於使用網域連線。
六、修改後的驗證順序與常見問題
每次修改後都應儲存、確認目前的 Config、重新連線，再造訪相同網域。瀏覽器快取與既有連線可能讓舊結果暫時保留，可先關閉該頁面再重新開啟。先完成這類影響較小的操作，再考慮調整範圍更大的系統設定。
- 先在原本的網路測試無法連線的網域，以及一個平常正常的網域，並記錄兩者是否取得解析結果。
- 保持伺服器、Global Routing 與 Config 不變，只切換 Wi-Fi 和行動網路進行比對；請留意行動數據可能產生流量費用。
- 若只有一種網路無法使用，請著重檢查該網路的 DNS 連線狀態、認證狀態與連接埠限制。
- 還原原本的 Config 模式與 On Demand 條件，確認日常規則、頁面資源與其他 App 都能正常使用。
有延遲數值，就能排除服務商連線問題嗎？
不能。返回 Home，使用同一台伺服器造訪無法連線的網域，再查看請求紀錄是否在連線階段出錯。測試網址成功，不代表目標網站也能正常使用；若需確認訂閱或伺服器參數，請向自己的服務商取得有效資訊。
將 DNS 改成加密 DNS，就一定能恢復嗎？
不一定。先在 Config 儲存原設定，再單獨修改 DNS 來源進行比對。DNS over HTTPS 和 DNS over TLS 也需要可連線的端點與正常的 TLS；若故障實際發生在規則出站，改用其他解析器無法解決根本原因。
只有 Wi-Fi 無法開啟網頁，行動網路正常，該檢查哪裡？
先保持 Shadowrocket 設定不變，檢查 Wi-Fi 是否需要認證，以及系統 Wi-Fi 詳細資訊中的 DNS 是否為手動設定。若使用加密 DNS，請再確認該網路能否連線至對應連接埠，不要同時修改多個設定項目。
更新訂閱後還是無法開啟網頁，需要一直重新整理嗎？
不需要。更新訂閱是為了取得連線項目，不代表能修復目前 Config 的 DNS 或規則。先確認 Home 中實際選取的項目，再返回 Config 檢查設定；若訂閱更新本身失敗，可參閱訂閱手冊中的更新說明。
關閉 IPv6 後恢復正常，以後都應該關閉嗎？
這只能表示值得繼續檢查位址類型或相關路徑。記錄原本設定，比對 A 與 AAAA 結果及連線日誌；確認網路的 IPv6 路徑是否正常後，再決定保留哪種設定，不要將單次比對結果套用到所有網路。
若需進一步找出問題，請向自己的服務商說明無法連線的網域、發生時間、目前網路、Global Routing 與錯誤階段。分享日誌前，請先移除訂閱網址、token、密碼及其他認證資訊。更多基本操作請參閱使用說明中的問題排查；訂閱更新操作請參閱Subscribe 更新說明。