適合已能連上節點,但遇到部分網域無法開啟或解析結果異常的使用者。先確認應用程式是否將網域交由核心處理,再分別設定解析器、DNS 查詢的連線出口,以及網站流量路由。本文提供適用於 Xray 核心的設定範例,說明境內 DNS、代理 DoH、geosite 與 FakeDNS 各自負責的環節,並介紹逐步驗證方法。
先釐清解析器選擇、DNS 出站與網站出站
「DNS 分流」至少包含兩個獨立判斷:網域要交給哪個解析器,以及連往解析器的查詢要走哪個出站。網站連線還有第三個判斷。將境外 DNS 位址填入設定,不代表查詢已透過代理傳送;將網站路由設為代理,也不代表瀏覽器先前在本機進行的解析會自動改由核心處理。
V2Ray/Xray 的 dns 物件用來設定內建解析器;routing 則決定連線走哪個出站。geosite:cn 是網域規則集,geoip:cn 是 IP 位址規則集,兩者不能互換。若應用程式沒有將網域交給核心,只有 IP 位址的連線就無法直接依網域規則集比對;流量嗅探有時能找回網域資訊,但不能把它當成適用於所有協定的補救方式。
境內 DNS 與遠端 DoH:先釐清各自用途
以下以 223.5.5.5 解析境內網域,並以 https://1.1.1.1/dns-query 處理其他查詢。這些是可替換的公共解析器範例,並非適用於所有網路的固定最佳選擇。前者通常使用 UDP 53,後者使用 HTTPS 443;加密保護的是用戶端與解析器之間的查詢傳輸,解析器仍看得到所處理的網域。
境內網域解析
- address
223.5.5.5- domains
geosite:cn- skipFallback
true- 查詢出站
direct
優先處理符合條件的境內網域,不將不相關網域加入一般回退佇列。
其他網域解析
- address
https://1.1.1.1/dns-query- 傳輸連接埠
443- 查詢出站
proxy- queryStrategy
UseIPv4
作為預設解析器,並讓 HTTPS 查詢連線經由代理節點傳送。
UseIPv4 可在第一輪排查時限制使用 IPv4,避免同時處理 IPv6 路由問題;這不代表建議長期停用 IPv6。網路與節點都支援 IPv6 時,可在基礎設定確認正常後改用 UseIP,再分別檢查 A 與 AAAA 記錄。DNS 查詢類型策略也不能取代系統層級的 IPv6 路由設定。
dns.servers 範例:網域比對與回退行為
以下是核心設定片段,並非可單獨匯入的完整節點設定。範例適用於 v2rayNG 使用的 Xray 核心;使用 v2rayN 時,也應先確認目前選用的核心。修改前請先備份設定;使用用戶端產生設定時,應在對應的 DNS 設定或自訂設定入口修改,不要編輯下次啟動時就會被覆寫的暫存執行檔。
{
"dns": {
"tag": "dns-internal",
"queryStrategy": "UseIPv4",
"servers": [
{
"address": "223.5.5.5",
"domains": [
"geosite:cn"
],
"skipFallback": true
},
"https://1.1.1.1/dns-query"
]
}
}
domains可為符合條件的網域指定優先使用的解析器,並不是限制「該解析器只能解析這些網域」的存取控制規則。skipFallback: true表示該伺服器不會參與一般回退,不代表「伺服器失敗時禁止嘗試其他伺服器」。- 沒有
domains限制的 DoH 伺服器會作為預設解析器。依照上述設定,境內解析失敗時仍可能回退至該伺服器,因此這是具有回退機制的分流方案,而非嚴格隔離方案。 tag可用來識別內建 DNS 發出的查詢,作為路由判斷依據;它不是監聽本機 53 連接埠的 DNS 服務。
若要嚴格限制符合條件的網域只能使用指定伺服器,可評估 Xray 的 disableFallbackIfMatch。啟用前請先確認目前核心支援此欄位,並了解指定解析器故障時,解析也會失敗。請勿同時大幅調整回退、快取與 IPv6 策略,否則發生故障時會有多種可能原因。
routing 範例:確保遠端 DNS 確實透過代理
以下片段假設現有設定已包含標籤為 proxy 的可用代理出站,以及標籤為 direct 的直連出站。標籤必須與實際的 outbounds[].tag 完全一致。此範例沒有最後的全域比對規則,未符合規則的連線會使用第一個出站,因此也要求第一個出站為 proxy。若現有設定採用其他預設策略,請依原有結構調整,不要直接覆寫。
{
"routing": {
"domainStrategy": "IPIfNonMatch",
"rules": [
{
"type": "field",
"inboundTag": [
"dns-internal"
],
"ip": [
"223.5.5.5"
],
"port": "53",
"outboundTag": "direct"
},
{
"type": "field",
"inboundTag": [
"dns-internal"
],
"ip": [
"1.1.1.1"
],
"port": "443",
"outboundTag": "proxy"
},
{
"type": "field",
"domain": [
"geosite:cn"
],
"outboundTag": "direct"
},
{
"type": "field",
"ip": [
"geoip:private",
"geoip:cn"
],
"outboundTag": "direct"
}
]
}
}
前兩條只比對內建 DNS 查詢,避免把使用者直接連往相同 IP 的其他連線也當成解析請求。後兩條則處理網站連線。IPIfNonMatch 的意思是:網域連線未符合現有規則時,再嘗試解析 IP 並比對 IP 規則;它不會決定使用哪台 DNS,也不會自動將 DNS 查詢送入代理。
| 設定位置 | 範例值 | 實際控制的項目 |
|---|---|---|
dns.servers[].domains | geosite:cn | 網域優先交由哪個解析器處理 |
dns.queryStrategy | UseIPv4 | 內建 DNS 的位址查詢策略 |
routing.domainStrategy | IPIfNonMatch | 路由比對時何時解析網域 |
routing.rules[].outboundTag | proxy | 符合規則的連線使用哪個出站 |
結論:先確認解析連線,再調整網站規則
重新啟動核心後,先確認連往 1.1.1.1:443 的內建 DNS 查詢是否命中 proxy。若這一步未成功,繼續新增境外網站網域規則,也無法確保解析路徑不受本機網路干擾。
DoH 與 FakeDNS:加密查詢和虛擬位址並非同一回事
DoH 將 DNS 訊息放在 HTTPS 連線中傳送,主要用來保護查詢傳輸。FakeDNS 則會向應用程式傳回虛擬 IP,並維護網域與虛擬位址的對應關係,讓後續連線仍能依網域處理。FakeDNS 不會將真實網站部署在虛擬位址上,也不代表「已完成遠端真實解析」。
| 方案 | 傳回內容 | 檢查重點 | 建議使用時機 |
|---|---|---|---|
| 一般 DNS | 真實的 A 或 AAAA 記錄 | UDP/TCP 53 的出站與連線狀況 | 境內解析基準 |
| DoH | 真實的 A 或 AAAA 記錄 | HTTPS 443、憑證與路由 | 遠端加密解析 |
| FakeDNS | 虛擬位址池中的 IP | 對應關係還原、入站流量擷取與嗅探 | 基礎分流穩定後再評估 |
例如使用 198.18.0.0/15 作為 FakeDNS IPv4 位址池時,系統必須將連往該位址池的連線送回核心,並由核心還原對應網域。若連線繞過 VPN 或 TUN 路徑,虛擬 IP 就無法像真實公網位址一樣連線。啟用後只有部分應用程式無法使用時,應先檢查個別應用程式的代理設定、流量擷取範圍與對應處理,不要直接更換節點。
- 一般 DNS 分流尚未確認正常:先不要啟用 FakeDNS,保留真實位址作為排查基準。
- 應用程式只提供目標 IP,導致網域規則難以生效:再評估 FakeDNS 與目前入站及嗅探設定的配合情況。
- 關閉 FakeDNS 後仍出現虛擬位址:清除相關應用程式與系統快取,並重新建立連線,避免繼續使用舊的對應資料。
在 v2rayN 與 v2rayNG 中逐項驗證
用戶端介面與核心設定分屬不同層。同一個「遠端 DNS」輸入欄位,在不同用戶端版本中可能會產生不同的設定結構;應以最後載入的核心設定為準。在 v2rayN 中,可前往「設定」→「參數設定」檢查記錄相關選項,再到主視窗的記錄區查看啟動結果。DNS 編輯入口的名稱可能隨版本變更,請勿將一般單行位址欄位當成完整 JSON 編輯器。
- 記錄目前設定。記下節點、目前的路由模式、DNS 位址,以及系統代理或 VPN 狀態。在 v2rayNG 的「設定」中檢查 DNS 相關項目;修改後停止並重新啟動服務,確認記錄中沒有設定解析錯誤。
- 檢查啟動錯誤。先處理未知欄位、找不到出站標籤、讀取 geosite 資料失敗等問題。核心未正常啟動時,測試網頁只會得到誤導性的結果。
- 確認應用程式是否提交網域。桌面環境可使用支援遠端解析的 SOCKS 請求進行測試。以下命令假設本機 SOCKS 連接埠為
10808;若執行中的設定不同,請改用實際連接埠。 - 確認路由規則命中情況。暫時啟用較詳細的記錄,分別造訪境內與境外網域,確認 DNS 查詢和網站連線所使用的出站。驗證完成後,請恢復常用記錄層級,避免長期記錄不必要的瀏覽細節。
- 排除快取影響。重新啟動核心並關閉舊連線後再測試。在 Windows 上可執行
ipconfig /flushdns清除系統快取,但瀏覽器或應用程式自己的快取可能仍需另外清除。
curl --proxy socks5h://127.0.0.1:10808 --head --max-time 15 https://www.example.com/
socks5h 會將網域交給 SOCKS 代理解析;改用 socks5 時,通常會先在本機解析,兩種測試路徑並不相同。這個命令只能確認網域是否進入代理路徑,不足以單獨證明所有 DNS 都已依預期分流。另一個常見誤區是只執行 nslookup www.example.com 223.5.5.5:這會直接查詢指定解析器,可用來確認該解析器是否連得上,卻不能證明內建 DNS 規則已生效。
常見問題:解析逾時、位址異常與設定未生效
改用 DoH 後所有網頁都逾時,應先檢查什麼?
先確認核心是否成功啟動,再檢查 1.1.1.1:443 是否使用可用的 proxy 出站。確認裝置時間正確,並查看記錄中是否有 TLS 憑證或交握錯誤。暫時恢復原本的 DNS 有助於判斷變更影響範圍,但不要靠停用憑證驗證來掩蓋問題。
境內網站變慢,是不是都改用遠端 DNS 解析了?
先確認 geosite:cn 資料是否成功載入,再檢查特定網域是否屬於該規則集。對明確需要境內解析的網域,可在境內解析器的 domains 中加入 domain:example.cn 這類明確規則,同時確認網站連線是否走直連。網站主網域與其圖片、影片網域可能適用不同規則。
兩個 DNS 傳回不同 IP,就能判定遭到污染嗎?
不能。CDN 調度、快取時間、解析器位置,以及 IPv4/IPv6 差異,都可能造成不同結果。應綜合檢查異常位址、憑證不符、持續連線失敗,以及多種可信解析路徑的比較結果。只因兩次回傳值不同,不能直接判定 DNS 遭到污染。
修改 DNS 後瀏覽器沒有變化,但其他應用程式正常?
先檢查瀏覽器是否啟用了自己的安全 DNS,再確認瀏覽器是否遵循系統代理。排查時可暫時統一解析路徑、清除瀏覽器 DNS 快取並關閉舊連線,再重新測試。若使用個別應用程式代理,也要確認瀏覽器沒有被排除在 VPN 流量擷取範圍之外。
最後應保留一份能清楚說明的設定:哪些網域使用境內解析、預設查詢交給哪個解析器、解析連線走哪個出站,以及未符合規則的網站如何處理。每次只調整一個變數,並透過啟動記錄與連線結果確認,比一次加入多個公共 DNS 更容易找出問題。
用戶端安裝與 DNS 設定入口
依作業系統選擇 v2rayNG 或 v2rayN,先匯入節點並確認基本連線正常,再調整 DNS 分流。初次設定可先閱讀入門指南。