www.apple.com 为伪装地址，前端警告消失

vps-xray/README.md

@@ -163,6 +163,36 @@ bash deploy.sh --redetect
 
 > ⚠️ 换完后 SNI 变了，**所有客户端都必须用新的分享链接重新配置**。脚本会在更换时打印醒目提示。
 
+#### 自定义伪装目标时的两个硬条件
+
+在 `.env` 里手动指定 `REALITY_DEST` / `REALITY_SNI` 前，必须确认新域名同时满足：
+
+**1. 技术条件** — TLS 1.3，且证书链总长 < 8192 字节。上限是 `xtls/reality` 里的硬编码值，超出会直接握手失败（见 [XTLS/Xray-core#6356](https://github.com/XTLS/Xray-core/issues/6356)，`www.microsoft.com` 的 8273 字节即触发）。在服务器上自查：
+
+```bash
+xray tls ping www.apple.com     # 只看「Pinging with SNI」那一段
+```
+
+**2. 客户端路由条件** — 该域名必须会被客户端判成「直连」。
+
+这条不直观。TUN 模式下客户端偶尔会把「连接本代理服务器」这件事本身也抓进代理（v2rayN 的 sing-box + xray 双核心靠进程嗅探防回环，Windows 上存在竞态）。这种回环连接的去向完全由 SNI 决定：
+
+| SNI 被判为 | 结果 |
+|---|---|
+| 直连 | 连接真的到达本服务器，REALITY 握手成功，**用户无感** |
+| 走代理 | 进隧道 → 服务器替客户端连了真正的伪装站 → 客户端收到真证书 → 刷屏 `REALITY: received real certificate` |
+
+实测（v2rayN 默认规则模板，`geosite:google → proxy` 排在 `geosite:cn → direct` 之前）：
+
+| 域名 | 命中规则 | 可用性 |
+|---|---|---|
+| `www.apple.com`、`*.apple.com` | `geosite:cn` | ✅ 安全 |
+| `dl.google.com` | `geosite:google` | ❌ 不安全 |
+| `www.microsoft.com` | 都不命中 → `final:proxy` | ❌ 不安全 |
+| `www.amazon.com` | 都不命中 → `final:proxy` | ❌ 不安全 |
+
+脚本的候选列表因此只保留 Apple 系域名。
+
 ### 查看状态 / 日志
 
 ```bash