如何选择 SNI 伪装目标

摘要：在 VLESS+Reality 的配置中，dest（也叫 SNI 伪装目标）是一个看似简单但极为重要的参数。它决定了 GFW 观察到的 TLS 连接”看起来是在访问哪个网站”。选错 dest 可能让你的节点在伪装效果上大打折扣，甚至增加被检测的风险。本文详细解释 dest 的工作原理、选择标准，并提供经过验证的推荐列表。

什么是 dest / SNI 伪装目标

Reality 协议的核心机制

要理解 dest 的作用，首先需要理解 Reality 协议的工作方式。

传统的 TLS 代理方案（如 VLESS+TLS+WebSocket）需要你拥有一个域名并申请 TLS 证书。GFW 在 TLS 握手阶段可以看到你的 SNI（Server Name Indication，即你声称要访问的域名），然后通过主动探测来验证这个域名对应的服务器是否真的运行着一个网站。如果探测发现 SNI 所指向的服务器不像一个正常网站，代理特征就暴露了。

Reality 的创新在于：它不使用自己的证书，而是”借用”一个真实网站的 TLS 连接。当 GFW 看到你的连接时，TLS 握手中的 Server Hello 和证书都来自那个真实网站——因为 Reality 确实是在与那个真实网站交互。GFW 无法区分这个连接和正常访问该网站的连接。

而 dest 参数，就是你指定的那个”真实网站”。

dest 在配置中的位置

在 Xray-core 的服务端配置中，dest 出现在 Reality 的相关设置中：

1
2
3
4
5
6
7
8
9
10
11
12

{
  "inbounds": [{
    "streamSettings": {
      "security": "reality",
      "realitySettings": {
        "dest": "www.apple.com:443",
        "serverNames": ["www.apple.com"],
        "shortIds": ["abcdef1234567890"]
      }
    }
  }]
}

dest 指定了当非代理客户端（包括 GFW 的探测器）连接到你的服务器时，Reality 将连接转发到的目标网站。serverNames 是客户端配置中需要匹配的 SNI 值，通常与 dest 的域名一致。

GFW 视角下的连接

从 GFW 的角度来看，使用 Reality 的连接经历如下过程：

1. 客户端向你的服务器 IP 发起 TLS 连接，SNI 为 www.apple.com
2. 服务器返回的 Server Hello 和证书确实来自 www.apple.com
3. GFW 如果进行主动探测（即自己也连接你的服务器），得到的同样是真实的 Apple 网站响应

这就是 Reality 的伪装力——GFW 看到的一切都与正常访问 Apple 网站一致。但如果你的 dest 选择不当，这种伪装效果会被削弱。

选择标准

一个合格的 dest 目标需要同时满足以下条件。

必须条件

1. 支持 TLS 1.3

Reality 要求 dest 目标支持 TLS 1.3。这是技术层面的硬性要求——如果目标网站只支持 TLS 1.2 或更低版本，Reality 无法正常工作。

2. 支持 HTTP/2（H2）

dest 目标需要支持 HTTP/2 协议。这是因为 Reality 在伪装层使用了 H2 的特性来实现多路复用。

3. 网站本身未被 GFW 封锁

如果 dest 目标域名在中国大陆已被封锁（DNS 污染或 IP 封锁），那么 GFW 看到你”访问”一个被封锁的网站反而会引起怀疑。dest 必须是一个从中国大陆可以正常访问的网站。

加分条件

4. 高流量站点

选择全球流量排名靠前的大型网站作为 dest。道理很简单：如果你的 SNI 是 apple.com，GFW 每天看到数百万个 SNI 为 apple.com 的连接，你的连接就淹没在正常流量中。但如果你选择一个日均访问量只有几千的小网站，而你的服务器上产生了数 TB 的”访问”流量，这种流量异常本身就是一个检测信号。

5. 服务器地理位置相近

理想情况下，dest 目标的服务器应与你的代理服务器在同一个或相近的网络中。这样可以降低因跨网络访问 dest 带来的延迟。如果你的服务器在东京，选择在东京有 CDN 节点的 dest（如大型跨国网站）比选择只有欧洲服务器的 dest 更合适。

6. 稳定的 TLS 配置

dest 目标的 TLS 配置不应频繁变更。一些网站会定期轮换证书、更新 TLS 参数，这可能导致 Reality 连接出现间歇性问题。选择 TLS 配置稳定的大型企业网站可以降低这种风险。

推荐列表

推荐使用的 dest

以下网站经过社区验证，满足上述选择标准：

具体选择建议：

• 通用推荐：www.apple.com 和 www.microsoft.com 是最安全的选择，流量大、稳定性高、全球 CDN 覆盖
• 日本节点：可以额外考虑 .jp 域名的大型网站
• 美国节点：dl.google.com 是优秀选择，在美国有大量服务器且流量极高

不推荐的 dest

以下类型的网站应当避免作为 dest：

小型网站：访问量低的个人博客、小型企业站。你的代理流量会在该网站的正常流量中显得异常突出。

已被封锁的网站：如果目标域名的 DNS 已被中国大陆污染，选它做 dest 等于在 SNI 中暴露你在访问一个被封锁的站点。

TLS 配置异常的网站：某些网站使用非标准的 TLS 扩展或不寻常的证书链，这可能导致 Reality 握手异常。

CDN 共享域名：一些网站使用共享的 CDN 域名（如 Cloudflare 的共享证书），多个网站共用同一个证书。这会导致证书中的域名列表与你的 SNI 不完全匹配，可能引起检测系统的注意。

频繁变更 TLS 配置的网站：如果目标网站经常更换证书颁发商、更新 TLS 参数，可能导致 Reality 连接不稳定。

如何测试 dest 是否可用

在确定 dest 之前，应该对目标网站进行技术验证。

验证 TLS 1.3 和 H2 支持

使用 curl 命令检测目标是否支持 TLS 1.3 和 HTTP/2：

1

curl -I --http2 -v --tlsv1.3 https://www.apple.com 2>&1 | grep -E "SSL connection|ALPN|HTTP/2"

期望看到的输出应包含：

• SSL connection using TLSv1.3（确认 TLS 1.3 支持）
• ALPN: server accepted h2（确认 H2 支持）

如果没有看到 TLS 1.3 或 H2 的字样，说明该目标不满足 Reality 的基本要求。

从中国大陆验证可达性

确保 dest 域名没有被 GFW 封锁：

1
2
3
4
5

# 使用国内 DNS 解析，检查是否被污染
nslookup www.apple.com 114.114.114.114

# 从国内服务器测试连通性
curl -o /dev/null -s -w "%{http_code}" https://www.apple.com

如果 DNS 解析返回异常 IP 或连接超时，说明该域名不适合用作 dest。

检查证书信息

查看目标网站的证书详情，确认证书链完整且非共享证书：

1

openssl s_client -connect www.apple.com:443 -servername www.apple.com < /dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates

重点关注证书的 Common Name 和 Subject Alternative Names 是否与目标域名匹配，以及证书的有效期是否充足。

监控 dest 可用性

选定 dest 后，需要持续监控其可用性。dest 目标虽然是大型网站，但也可能发生变更。

定期检测 TLS 配置

编写脚本定期检测 dest 的 TLS 版本和 ALPN 支持是否正常：

1
2
3
4
5
6
7
8
9
10
11
12

#!/bin/bash
# check_dest.sh - 定期检测 dest 可用性

DEST="www.apple.com"

# 检测 TLS 1.3 支持
tls_version=$(curl -I --tlsv1.3 -s -o /dev/null -w "%{ssl_version}" https://$DEST 2>/dev/null)

if [ "$tls_version" != "TLSv1.3" ]; then
    echo "警告：$DEST 的 TLS 版本异常 ($tls_version)"
    # 发送告警
fi

监控 GFW 封锁状态

如果 dest 目标被 GFW 新增封锁（虽然概率很低，但像 Google 的部分域名就经历过封锁范围变化），你需要及时更换 dest。建议从国内的监控节点定期检测 dest 域名的可达性。

dest 被封后的应对

虽然概率极低，但如果你选择的 dest 目标被 GFW 封锁了，需要知道如何应对。

影响范围

dest 被封后，你的 Reality 节点不会立即不可用——因为 Reality 并不真的需要客户端能访问 dest。但 GFW 看到你的连接 SNI 指向一个被封锁的域名，这本身就是一个异常信号，会增加你的节点被重点审查的概率。

更换流程

1. 服务端：在 Xray 配置中修改 dest 和 serverNames 为新的目标域名，然后重启 Xray 服务
2. 客户端：更新所有客户端配置中的 serverName 参数，使其与新的 dest 匹配
3. 面板更新：如果通过面板分发节点，需要同步更新面板中的节点配置

更换 dest 不需要更换服务器 IP，整个过程可以在几分钟内完成。

预防措施

• 选择被封风险极低的 dest（如苹果、微软等大型企业站点）
• 准备一个备用 dest 列表，在需要时快速切换
• 避免选择与政治敏感内容相关的网站作为 dest

高级话题：同一服务器多个 dest

一台服务器可以配置多个 Reality 入站，每个使用不同的 dest。这在以下场景中有价值：

• 分散风险：不同用户组使用不同的 dest，避免所有用户因单一 dest 问题而受影响
• 按需选择：不同地区的用户可以使用延迟最低的 dest
• A/B 测试：对比不同 dest 的抗封锁效果

配置方式是在 Xray 的 inbounds 中添加多个监听不同端口的入站，每个入站使用独立的 Reality 设置和不同的 dest。

常见问题（FAQ）

dest 选同一台服务器上的网站会怎样？

如果你的服务器上真的运行了一个网站，并且将 dest 指向这个网站的域名，技术上可行。但这样做实际上失去了 Reality 的核心优势——GFW 可以通过主动探测判断这个”网站”是你自己搭建的，而非一个高流量的真实商业网站。

所有人都用 apple.com 作为 dest 会不会被针对？

理论上存在这个风险。如果 GFW 发现大量非苹果 CDN 的 IP 地址上的 TLS 连接都声称在访问 apple.com，这确实是一个统计异常。但目前没有证据表明 GFW 在进行这种级别的统计分析。apple.com 的正常流量基数足够大，短期内不太可能因此被针对。

Reality 的 dest 和传统方案的 SNI 有什么本质区别？

传统 TLS 方案中的 SNI 只是一个声明——你声称在访问这个域名，但服务器返回的是自己的证书。GFW 可以通过探测发现 SNI 与实际证书不匹配。Reality 的 dest 则是真正的转发目标——GFW 探测时得到的证书确实来自该网站，伪装更彻底。

可以使用 IP 地址作为 dest 吗？

不推荐。使用 IP 地址意味着 SNI 也要设为 IP 地址，而正常的 TLS 连接几乎都使用域名 SNI。IP 地址作为 SNI 本身就是一个显著的异常特征。

dest 目标更换证书会影响我的节点吗？

大型网站定期轮换证书是正常行为，Reality 对此有容错能力。证书轮换不会导致现有代理连接中断，因为 Reality 会动态获取目标网站的最新证书。但如果目标网站在轮换过程中短暂出现 TLS 配置异常，可能导致新连接建立失败。

如何判断我当前的 dest 效果好不好？

最直接的指标是节点的存活时间。如果节点长期稳定运行（数月不被封），说明 dest 选择和整体配置都没有问题。如果节点频繁被封，在排除其他因素（如协议指纹、流量模式等）后，可以尝试更换 dest。

外部参考

• REALITY 项目 — Reality 协议源码和文档
• Xray-core 官方文档 — Xray 配置参考
• VLESS+Reality 深度解析 — 本站详细技术解读