在 DMIT 部署 VLESS-Reality

这篇记录在 DMIT Debian 12 实例上部署 Xray VLESS-TCP-Reality，以及一次“客户端断连、TCP port 可达、但 Xray 没有入站日志”的排查过程。

环境：

项目	配置
Provider	DMIT
OS	Debian 12
Xray core	v26.3.27
Protocol	VLESS-TCP-Reality
Flow	`xtls-rprx-vision`

配置示例中的 IP、UUID、private key、public key 和 shortId 都必须替换为自己的值。Private key 和访问参数不得写入公开 repository。

SSH 登录与基础环境

DMIT 使用 private key 登录时，在 Windows PowerShell 指定 .pem：

ssh -i "D:\dmit\id_rsa.pem" root@<SERVER_IP>

若 OpenSSH 报 UNPROTECTED PRIVATE KEY FILE，说明 Windows file ACL 允许了过多用户读取。应在文件属性的 Security 设置中移除继承，只保留当前用户需要的读取权限，而不是复制 key 内容或关闭 SSH 检查。

更新系统并安装基础工具：

apt update
apt upgrade -y
apt install curl wget nano -y

安装 provider 推荐的 guest components：

apt install -y qemu-guest-agent cloud-init
systemctl enable --now qemu-guest-agent

它们帮助 provider panel 完成 graceful shutdown 和 instance network configuration；是否需要由当前 image 与 provider documentation 决定。

启用 BBR 与 fq

查看当前设置：

sysctl net.ipv4.tcp_congestion_control
sysctl net.core.default_qdisc

写入独立 configuration file，避免反复向 /etc/sysctl.conf 追加重复行：

cat > /etc/sysctl.d/99-network-tuning.conf <<'EOF'
net.core.default_qdisc=fq
net.ipv4.tcp_congestion_control=bbr
EOF

sysctl --system

再次确认：

sysctl net.ipv4.tcp_congestion_control
sysctl net.core.default_qdisc

BBR 影响 congestion control，不会修复配置错误、packet loss、routing 绕行或被中断的 application handshake。

安装 Xray

bash <(curl -L https://raw.githubusercontent.com/XTLS/Xray-install/main/install-release.sh)

记录版本并检查 service：

xray version
systemctl status xray

如果下载 .dgst 或 release files 时遇到 HTTP 502，先确认 GitHub endpoint 是否临时不可用，再重试；不要在来源不明的镜像间随意切换 installation script。

生成 Reality 参数

xray uuid
xray x25519
openssl rand -hex 8

分别得到：

参数	使用位置
UUID	server client ID 与客户端 ID
Private key	只保存在服务器 Reality settings
Public key	客户端配置
shortId	server allowlist 与客户端配置

将参数保存在受保护的 password manager 或 secret storage 中。不要把 private key 发给客户端，也不要把真实配置粘贴到公开问题报告。

配置 VLESS-Reality

备份并编辑：

mkdir -p /usr/local/etc/xray/
cp /usr/local/etc/xray/config.json /usr/local/etc/xray/config.json.backup
nano /usr/local/etc/xray/config.json

{
  "inbounds": [
    {
      "port": 443,
      "listen": "0.0.0.0",
      "protocol": "vless",
      "settings": {
        "clients": [
          {
            "id": "<UUID>",
            "flow": "xtls-rprx-vision"
          }
        ],
        "decryption": "none"
      },
      "streamSettings": {
        "network": "tcp",
        "security": "reality",
        "realitySettings": {
          "dest": "gateway.icloud.com:443",
          "serverNames": [
            "gateway.icloud.com",
            "icloud.com"
          ],
          "privateKey": "<PRIVATE_KEY>",
          "shortIds": [
            "<SHORT_ID>"
          ]
        }
      }
    }
  ],
  "outbounds": [
    {
      "protocol": "freedom"
    }
  ]
}

这里的 target host 是这次记录使用的配置。它应与 serverNames、客户端 SNI 和 Reality requirements 相互匹配，不能只因为某个域名知名就任意替换。

验证并重启：

xray run -test -config /usr/local/etc/xray/config.json
systemctl restart xray
systemctl status xray
ss -lntp | grep ':443'

如果 provider 另有 network firewall，还需要在控制面板允许 TCP 443。主机使用 UFW 时也要检查本机规则。

客户端对应参数

V2RayN、Shadowrocket 或兼容客户端至少需要：

字段	来源
Address	VPS IP 或配置使用的入口地址
Port	`443`
Protocol	VLESS
UUID	`xray uuid` 的结果
Flow	`xtls-rprx-vision`
Security	Reality
Public key	`xray x25519` 的 public key
shortId	server config 中允许的 shortId
SNI / server name	与 Reality target configuration 匹配

Server 保存 private key，client 使用 public key。两者不可互换。

一次连接中断的排查

现象是 Windows V2RayN 与 iOS Shadowrocket 同时断连，client 只显示泛化错误。排查目标不是立刻猜原因，而是确认连接在哪一层消失。

1. 服务是否运行

systemctl status xray

active (running) 只说明 process 存活，不代表 config、监听端口和 application handshake 正常。

2. 时间是否明显偏移

date
timedatectl status

Reality handshake 对时间一致性有要求。比较 server 与 client 时间，并确认 NTP synchronization 状态。

3. TCP port 是否可达

Windows：

Test-NetConnection -ComputerName <SERVER_IP> -Port 443

TcpTestSucceeded : True 表示 TCP connection 可以建立，但不证明 Reality handshake 完成，也不证明请求已经被 Xray 正常处理。

4. Xray 是否看到入站

journalctl -u xray -f

保持日志窗口打开，再从 client 发起连接。

有新日志：连接已到 Xray，继续检查 UUID、flow、public key、shortId、SNI 与 target；
没有新日志：继续检查监听地址、host firewall、provider firewall、NAT/routing，以及链路是否在 application data 到达前被中断。

同时查看监听：

ss -lntp | grep ':443'

5. 检查配置变化

原记录将 Reality target 从 www.microsoft.com 调整为 gateway.icloud.com，同步修改 client 后连接恢复。

这个结果支持“问题与原 Reality target、SNI 或链路对该流量的处理有关”的推断，但不能单凭一次恢复证明存在特定形式的 TCP hijacking。其他可能性还包括 target availability、client/server fields 未同步、routing change、provider filtering 或短暂网络故障。

排障记录应保留修改前后的唯一变量、时间、client logs 与 server logs，才能逐步缩小原因。

迁移与备份

重装或更换 VPS 前保存：

Xray version；
去除 secrets 的 configuration template；
provider firewall rules；
BBR/sysctl configuration；
client fields 对照；
真实 secrets 的安全备份；
已验证的排障命令。

新实例应生成新的 UUID 与 Reality key pair，避免旧凭据在服务器销毁后继续复用。

02在 DMIT 部署 VLESS-Reality