这次的目标并不只是让客户端第一次显示“已连接”，而是搭出一个职责清楚、能够排错、以后也敢继续维护的个人节点。日常交流里经常把它叫作 VPN，但更准确地说，它是由 Xray 提供的代理节点。本文只记录本人设备的合法远程访问与网络技术学习，请遵守所在地法律和服务商条款。
客户端 → 节点域名 → 美国 VPS → Xray Core → 美国出口 IP
本文公开的是架构、配置原则和排错方法。真实 VPS IP、面板路径、用户 UUID、订阅 ID、REALITY 私钥和 Short ID 均不展示；示例统一使用 sub.example.com 和占位符。
先把每个入口的职责分开
最终我把根域名和 www 留给个人网站，节点只使用一个独立子域名。客户端负责使用配置，3x-ui 只负责管理配置，真正处理连接的是 Xray Core。
- 个人网站：根域名与
www，部署在 Cloudflare Pages； - 节点域名：
sub.example.com，直接解析到 VPS，保持 DNS only； - 管理面板：只监听
127.0.0.1，通过 SSH 隧道访问； - 数据入口：Xray 在公网
443/tcp接收连接； - 订阅服务：作为独立的 HTTPS 服务处理，不和节点数据通道混为一谈。
关于 DNS 的一个误判
我先在 Cloudflare 创建节点子域名的 A 记录，让它指向美国 VPS。这里必须使用 DNS only。Cloudflare 的普通代理面向 HTTP/HTTPS，不能直接代理这条原生 REALITY TCP 连接。
第一次执行 DNS 查询时，结果却是 198.18.2.16。这并不是域名绑定错误，而是本地代理的 Fake-IP 机制返回了保留地址。关闭代理后，再用公共解析器查询，域名才显示真实 VPS IP。
排查 DNS 时要区分“系统实际使用的代理 DNS”和“公网权威解析结果”。看到 198.18.0.0/15 一类地址时，应先想到 Fake-IP，而不是立刻修改 Cloudflare 记录。
3x-ui 面板不直接暴露公网
安装 3x-ui 后，我修改了面板端口、用户名、密码和 Base URI，并把面板绑定到 127.0.0.1。这意味着面板本身虽然提供 HTTP，公网却无法直接访问它。
Mac 通过 SSH 本地端口转发进入面板：
ssh -L LOCAL_PORT:127.0.0.1:PANEL_PORT root@VPS_PUBLIC_IP浏览器访问的是本机 127.0.0.1，真正跨越公网的部分由 SSH 加密。安装完成后，使用 x-ui status 和 systemctl status x-ui --no-pager 确认 3x-ui 与 Xray 都处于运行状态。
建立 VLESS REALITY 入站
数据入口最终使用 VLESS、TCP/RAW、REALITY 与 Vision。关键配置可以概括为：
- 协议为 VLESS，解密和加密均为
none； - 监听地址留空，使 Xray 监听公网；端口使用
443； - 传输使用 TCP/RAW，Header 为
none； - 安全选择 REALITY，客户端指纹使用
chrome； - 目标地址与 SNI 保持一致；
- 生成 X25519 密钥对，私钥只留在服务器；
- 客户端 flow 使用
xtls-rprx-vision，并填写匹配的 Short ID。
第一次导出分享链接为空，是因为入站的 clients 数组还是空的。入站协议配置完成不等于已经有可用用户；还必须新增客户端、生成 UUID，并保存入站。
REALITY 私钥、UUID、订阅 ID 和面板路径都属于凭据。公开截图或求助后，应立即轮换已经暴露的值。
端口可达不代表协议正确
使用 nc -vz -G 5 sub.example.com 443 可以确认 TCP 三次握手成功。这个结果证明 DNS、路由和端口基本可达，但不能证明 REALITY 的公钥、SNI、Short ID、UUID 与 flow 全部匹配。
实际排查顺序应当是：
- 确认公网 DNS 指向正确 VPS，并排除 Fake-IP 干扰；
- 确认服务器确实监听
443/tcp，外部端口可以建立连接； - 逐项核对 UUID、公钥、SNI、Short ID、Vision flow 和客户端指纹；
- 检查 Xray 与 3x-ui 日志，观察连接在哪一步失败；
- 最后用真实网页、下载和 DNS 查询验证，而不只看客户端延迟数字。
节点链接和订阅不是一回事
单条 VLESS 链接可以直接导入支持它的客户端。客户端显示“本地节点”，通常只表示配置由用户在本机导入，并不代表服务器位于本机。面板最初显示的订阅地址是 http://127.0.0.1:SUB_PORT/sub/TOKEN，这个地址只对服务器本机有效，外部客户端当然无法访问。
要提供订阅，就要单独准备公网 HTTPS 地址、证书和正确的响应格式。完成测试后，应删除失败的测试客户端，并重新生成曾经暴露过的订阅 ID。
SSH 免密是管理入口的一部分
将本机 SSH 公钥加入 VPS 的 authorized_keys 后，应保留原会话，再开一个新终端验证密钥登录；只有确认新入口可靠，才考虑关闭密码登录。这样即使面板不可用，服务器仍然有一条独立、可审计的管理路径。
真正完成的是运维闭环
节点能用只是起点。最终我把以下事项作为完成标准：
- 面板仅监听回环地址，通过 SSH 密钥和本地隧道管理；
- 公网只开放必要端口，节点域名保持 DNS only；
- 定期更新 3x-ui 与 Xray，并在变更前备份配置数据库；
- 证书能够自动续期，订阅凭据和客户端 UUID 可以随时轮换；
- 保留服务状态、监听端口、客户端实测和日志四层检查方法；
- 根域名与节点子域名职责独立，网站部署不会影响代理入口。
这次部署最大的收获不是记住某几个表单值，而是建立了一个可以复述的模型：DNS 决定去哪里，防火墙决定能不能到，REALITY 参数决定能不能握手，客户端与订阅决定配置如何分发，日志和真实流量则决定它是否真的可用。