Surge + UniFi 的 DoH DNS 防泄露配置实践

一、DNS 泄露是怎样产生的#

假设设备当前通过香港、新加坡等境外代理访问网络，正常的网页流量路径是：

1
设备
2
  ↓
3
Surge
4
  ↓
5
香港 / 新加坡代理节点
6
  ↓
7
Internet

但如果 DNS 仍然从本地网络直连出去，路径就会变成：

1
设备
2
  ↓
3
DNS 请求
4
  ↓
5
DIRECT
6
  ↓
7
本地运营商网络

此时 DNS Leak Test 可能同时看到：

1
网页出口：香港 / 新加坡
2
DNS Resolver：中国大陆

这通常会被判断为 DNS 泄露。

这里需要区分两个概念：

• DoH 解决的是 DNS 查询内容在传输过程中是否加密；
• 代理 DoH 解决的是 DNS 请求从哪个网络出口发出。

因此：

1
使用 DoH ≠ DNS 一定不会泄露出口信息

例如：

1
Surge
2
  ↓
3
AliDNS DoH
4
  ↓
5
DIRECT

虽然 DNS 查询已经通过 HTTPS 加密，但访问 AliDNS 的连接仍然从真实网络出口发出。如果网页流量正在使用香港代理，DNS Leak Test 仍可能看到真实网络侧对应的 DNS Resolver。

我期望的结构是：

1
设备
2
  ↓
3
Surge
4
  ↓
5
DoH
6
  ↓
7
代理节点
8
  ↓
9
DNS Resolver

“泄露”的具体含义

DNS Leak Test 主要用于比较网页出口与解析器出口是否一致。测试结果中出现某个地区或运营商，并不等于 DNS 查询内容一定以明文传输；DoH 是否加密与 DoH 从哪个出口连接，是两个不同的问题。

二、未开启本地代理：由 UniFi 提供加密 DNS#

如果电脑、手机等设备没有运行 Surge、Loon、Clash 等会接管 DNS 的代理程序，最简单的方案就是让 UniFi 统一负责 DNS：

1
电脑 / 手机 / 平板
2
        ↓
3
      UniFi
4
        ↓
5
  Encrypted DNS
6
        ↓
7
 AliDNS / DNSPod

这样整个局域网只需要在 UniFi 上配置一次，无须在每台设备中重复设置 DoH。

1
设置
2
→ CyberSecure
3
→ 加密 DNS

1
预定义

1
Alidns-doh
2
Dnspod

1
客户端
2
  ↓
3
UniFi Gateway
4
  ↓
5
AliDNS / DNSPod DoH

三、为什么开启 Surge 后，UniFi 的 DNS 看起来“不生效”#

当 Surge 开启 Enhanced Mode 或 DNS 接管后，DNS 路径会发生变化。

原本的路径是：

1
Mac
2
  ↓
3
UniFi
4
  ↓
5
Encrypted DNS

开启 Surge 后则会变成：

1
Mac
2
  ↓
3
Surge
4
  ↓
5
Surge 自己的 DNS

这并不代表 UniFi 的加密 DNS 失效，而是这台设备的 DNS 已经在到达 UniFi DNS 之前被 Surge 接管。

因此可能出现以下现象：

1
UniFi 已正确配置 Encrypted DNS
2
+
3
Surge 已开启
4
  ↓
5
DNS Leak Test 仍显示异常

彻底关闭 Surge 后，路径重新回到：

1
Mac
2
  ↓
3
UniFi
4
  ↓
5
Encrypted DNS

如果此时 DNS Leak Test 恢复正常，真正需要调整的就是 Surge 的 DNS 配置，而不是继续修改 UniFi。

四、Surge 中仅配置 DoH 还不够#

这是我在实际测试中最重要的发现。

我分别测试了境内和境外的 DoH 服务：

测试结果如下：

这说明决定测试结果的关键并不是：

1
境内 DNS vs. 境外 DNS

而是：

1
DoH → DIRECT
2
vs.
3
DoH → Proxy

经过代理后，无论是 AliDNS、DNSPod，还是 Cloudflare、Google，都可以在我的环境中正常作为 DoH 使用。因此我最终准备了四个端点，并让它们全部通过 Surge 的代理策略发送：

1
https://dns.alidns.com/dns-query
2
https://doh.pub/dns-query
3
https://cloudflare-dns.com/dns-query
4
https://dns.google/dns-query

五、Surge 的最终 DNS 配置#

在 Surge 配置文件的 [General] 中加入：

1
[General]
2

3
dns-server = 223.5.5.5, 119.29.29.29
4
encrypted-dns-server = https://dns.alidns.com/dns-query, https://doh.pub/dns-query, https://cloudflare-dns.com/dns-query, https://dns.google/dns-query
5
encrypted-dns-follow-outbound-mode = true
6
hijack-dns = *:53

其中最关键的是：

1
encrypted-dns-follow-outbound-mode = true

启用后，加密 DNS 请求可以遵循 Surge 的出站模式并进入规则系统。然后在 [Rule] 中加入：

1
[Rule]
2

3
PROTOCOL,DOH,你的代理策略

例如：

1
PROTOCOL,DOH,⚡ 自动选择

这样，DoH 请求会交给指定的代理策略：

1
AliDNS ────────┐
2
DNSPod ────────┤
3
Cloudflare ────┤
4
Google ────────┘
5
        ↓
6
      Surge
7
        ↓
8
     代理策略
9
        ↓
10
     代理节点
11
        ↓
12
  DNS Resolver

这是我目前在 Surge 上实际验证可以消除上述 DNS 出口不一致问题的配置。

替换策略名称

你的代理策略 和 ⚡ 自动选择 都只是示例。请替换为配置文件中真实存在且可用的策略组名称，否则规则无法按预期工作。

六、dns-server 与 encrypted-dns-server 的区别#

配置中同时存在：

1
dns-server = 223.5.5.5, 119.29.29.29

以及：

1
encrypted-dns-server = ...

两者并不冲突。

正常的域名解析主要交给 encrypted-dns-server，也就是前面配置的四个 DoH；普通的 dns-server 则保留用于基础解析、引导等用途。

这一点很重要，因为代理节点本身也可能依赖 DNS。例如代理服务器填写的是：

1
node.example.com

Surge 必须先得到该域名对应的 IP，才能连接代理节点。如果所有 DNS 都要求先经过代理，就可能形成循环依赖：

1
建立代理
2
  ↓
3
需要先解析节点域名
4

5
使用 DoH
6
  ↓
7
又要求代理已经建立

因此，保留普通 DNS 可以为代理初始化和 DoH 引导解析提供一条基础路径。

普通 DNS 的边界

保留 dns-server 是为了处理引导和基础解析，不代表所有正常查询都会绕过 encrypted-dns-server。实际行为还会受到 Surge 版本、运行模式、缓存和具体配置影响。

七、代理 DoH 的启动依赖问题#

即使已经配置：

1
dns-server = 223.5.5.5, 119.29.29.29
2
encrypted-dns-follow-outbound-mode = true

并使用：

1
PROTOCOL,DOH,你的代理策略

在切换 Surge 配置文件时，我仍然偶尔会遇到：

1
配置刚切换
2
  ↓
3
所有节点超时
4
  ↓
5
网页完全无法访问

这通常与配置重新加载阶段的启动依赖有关：

1
DNS 需要代理
2
+
3
代理初始化又需要 DNS

我的临时处理方法是：

1
切换配置
2
  ↓
3
如果所有节点超时
4
  ↓
5
将 DoH 策略临时切换为 DIRECT
6
  ↓
7
等待代理节点恢复
8
  ↓
9
再将 DoH 切回 Proxy

Surge 正常运行后，让 DoH 全部经过代理可以稳定工作。这里需要区分：启动阶段的循环依赖与正常运行时的 DNS 防泄露是两个问题。

如果这个问题频繁出现，也应检查代理节点域名能否通过基础 DNS 正常解析、策略组是否可用，以及当前 Surge 版本是否改变了加密 DNS 的初始化行为。

八、hijack-dns = *:53 的作用#

我在 Surge 中保留了：

1
hijack-dns = *:53

它的作用不是阻止 DNS，而是将传统 DNS 请求接管到 Surge：

1
应用
2
  ↓
3
8.8.8.8:53
4
  ↓
5
Surge Hijack
6
  ↓
7
Surge DNS
8
  ↓
9
DoH
10
  ↓
11
代理

这与在防火墙中阻止 TCP/UDP 53 完全不同：

对于由 Surge 负责 DNS 的设备，DNS Hijack 可以减少应用绕过系统 DNS、直接查询传统 DNS 服务器的情况。

它不能接管所有加密 DNS

hijack-dns = *:53 针对传统 53 端口 DNS。应用自带的 DoH、DoT、私有 VPN DNS 或其他非 53 端口解析，不一定会被这项配置接管。

九、境内与境外 DoH 应该怎样选择#

我的最终配置同时使用：

• AliDNS；
• DNSPod；
• Cloudflare；
• Google。

AliDNS 和 DNSPod 在中国大陆网络中通常具有较好的直连可达性；Cloudflare 和 Google 则提供另外两组独立的解析来源。

不过，在开启 Surge 后，我不会让其中任何一个 DoH 使用 DIRECT，而是统一交给代理策略：

1
AliDNS     → Proxy
2
DNSPod     → Proxy
3
Cloudflare → Proxy
4
Google     → Proxy

因此，“境内还是境外”不再是最关键的问题。更重要的是同时确认：

1
DNS 查询是否加密
2
+
3
DoH 请求是否经过预期的代理出口

需要注意，多配置几个 DoH 端点并不自动等于更快或更可靠。最终效果仍取决于 Surge 的选择逻辑、代理节点质量、解析器响应，以及具体网络环境。

十、最终推荐架构#

整个方案可以简化成两种状态。

1
设备
2
  ↓
3
UniFi
4
  ↓
5
CyberSecure
6
  ↓
7
Encrypted DNS
8
  ↓
9
AliDNS / DNSPod

1
CyberSecure
2
→ 加密 DNS
3
→ 预定义
4
→ Alidns-doh
5
→ Dnspod

1
设备
2
  ↓
3
Surge
4
  ↓
5
DoH
6
  ↓
7
Proxy
8
  ↓
9
DNS Resolver

1
[General]
2

3
dns-server = 223.5.5.5, 119.29.29.29
4
encrypted-dns-server = https://dns.alidns.com/dns-query, https://doh.pub/dns-query, https://cloudflare-dns.com/dns-query, https://dns.google/dns-query
5
encrypted-dns-follow-outbound-mode = true
6
hijack-dns = *:53

1
[Rule]
2

3
PROTOCOL,DOH,你的代理策略

1
PROTOCOL,DOH,⚡ 自动选择

1
AliDNS ────────┐
2
DNSPod ────────┤
3
Cloudflare ────┤
4
Google ────────┘
5
        ↓
6
      Proxy

十一、如何判断问题在 UniFi 还是 Surge#

实际排查时，最有效的方法之一就是做简单的对照测试。

先保持 Surge 开启，运行 DNS Leak Test；如果结果异常，再彻底关闭 Surge 并重新测试。

如果结果是：

1
Surge 开启 → DNS 出口异常
2
Surge 关闭 → DNS 恢复正常

基本可以判断：

1
UniFi 的加密 DNS 路径可以工作
2
问题更可能在 Surge 的 DNS 配置或出站策略

因为关闭 Surge 后，DNS 已经重新回到：

1
设备
2
  ↓
3
UniFi
4
  ↓
5
Encrypted DNS

反过来，如果关闭 Surge 后仍然异常，再去检查 UniFi 的 Encrypted DNS 是否正确启用。

总结#

这套配置最终可以归结为一个原则：

1
谁接管 DNS，就在谁那里解决 DNS 防泄露。

没有本地代理时：

1
UniFi 接管 DNS
2
→ 使用 CyberSecure Encrypted DNS

开启 Surge 时：

1
Surge 接管 DNS
2
→ 使用 DoH
3
→ DoH 本身也经过代理

在我的实际测试中：

1
AliDNS / DNSPod
2
→ DIRECT
3
→ 可以正常解析，但 DNS Leak Test 显示真实网络侧的解析器
4

5
Cloudflare / Google
6
→ DIRECT
7
→ 在当前网络环境中可能无法正常使用
8

9
AliDNS / DNSPod / Cloudflare / Google
10
→ 全部交给 Proxy
11
→ DNS Leak Test 正常

所以我最终使用的架构是：

1
没有 Surge：
2
UniFi → AliDNS / DNSPod DoH
3

4
开启 Surge：
5
Surge → AliDNS + DNSPod + Cloudflare + Google DoH
6
      → 全部经过代理

相比在操作系统、路由器和代理客户端之间同时堆叠大量 DNS 设置，这种分工更容易理解，也更容易定位问题。