自己搭建科学上网:VLESS + TCP + REALITY 完整教程

26 年 8 月 5 日 星期三
5238 字
27 分钟

这篇文章记录一套已经实际搭建并验证成功的方案:

text
海外 Ubuntu 服务器 + Xray + VLESS + TCP + REALITY + Clash Verge Rev

它不需要购买域名,也不需要申请 TLS 证书。服务端只要有一个公网 IP,客户端保存好 UUID、REALITY 密钥和 shortId 即可连接。

本文仅用于合法的远程访问、开发调试与网络技术学习。请遵守服务器所在地和使用所在地的法律法规,以及云服务商的使用条款。

前置提醒:REALITY 伪装站使用 www.bing.com

本文所有服务端和客户端配置统一使用:

text
target: www.bing.com:443
serverNames: [www.bing.com]
servername: www.bing.com

不要把本文中的 www.bing.com 换成 www.microsoft.com

我在 Xray 26.3.27 上遇到过一个真实问题:Xray 处理 www.microsoft.com 返回的 8273 字节证书记录时超过 REALITY 的限制,导致客户端无法建立连接。服务器端口、UUID、密钥和防火墙当时都没有问题。将 REALITY 的伪装目标、允许的 SNI 和客户端 SNI 一起改成证书记录更小的 www.bing.com 后,连接立即恢复。

这个在最后还会再提一次。

方案原理

VLESS、TCP 与 REALITY 的访问链路
客户端通过 VLESS、TCP 和 REALITY 连接海外服务器,再由服务器访问目标网站

一次请求大致经历下面几层:

  1. Clash Verge Rev 接管需要代理的流量;
  2. Mihomo 内核使用 VLESS 和 UUID 完成客户端身份校验;
  3. 数据通过 TCP 传输;
  4. REALITY 让握手在外观上接近访问 www.bing.com 的普通 TLS 流量;
  5. 海外服务器上的 Xray 解封装后,代替客户端访问目标网站;
  6. 返回数据沿原连接回到客户端。

这套方案中几个容易混淆的概念如下:

名称作用是否需要保密
服务器公网 IP客户端连接的真实服务器地址否,但不应随意公开
UUIDVLESS 用户身份凭证
REALITY 私钥只保存在服务器必须保密
REALITY 公钥客户端用于验证服务器
shortIdREALITY 的附加识别值建议保密
www.bing.comREALITY 的伪装目标和 SNI

REALITY 并不是把流量转发给 Bing。合法的 REALITY 客户端通过认证后,Xray 会正常代理其请求;未通过认证的探测流量才可能被转发至 target

一、选择服务器

Xray 本身占用的资源很少,个人使用无需购买高配置服务器。更值得关注的是服务器位置、跨境线路、月流量和晚高峰丢包。

建议从下面的规格开始:

text
系统:Ubuntu 24.04 LTS
CPU:1 核或以上
内存:512MB 可运行,建议 1GB 或以上
硬盘:10GB 或以上
网络:独立公网 IPv4
流量:按自己的下载、视频和开发需求选择

机房可以优先考虑东京、新加坡、洛杉矶、圣何塞或西雅图。地理距离近不等于线路一定好,最好先按月购买,分别在白天、晚高峰和周末测试,再决定是否长期续费。

轻量应用服务器通常比同厂商的通用云服务器便宜,也足够运行本方案。如果使用 NAT VPS,需要把本文的 443 改成服务商分配给你的公网映射端口,并确认公网端口正确映射到 Xray 的监听端口。

二、创建服务器并准备登录

创建实例时建议选择:

text
镜像:Ubuntu 24.04 LTS
登录方式:SSH 密钥
公网地址:独立 IPv4
自动续费:先关闭,测试稳定后再决定

假设服务器公网 IP 为 <SERVER_IP>,本机私钥为 ~/.ssh/id_ed25519

bash
ssh -i ~/.ssh/id_ed25519 ubuntu@<SERVER_IP>

不同厂商的默认用户可能是 ubunturoot 或其他名称,以控制台提示为准。

如果创建时只能设置密码,先在本机生成密钥并上传公钥:

bash
ssh-keygen -t ed25519 -a 64
ssh-copy-id ubuntu@<SERVER_IP>

新开一个终端确认密钥可以正常登录后,再考虑关闭密码登录。不要在当前唯一的 SSH 会话里直接禁用密码,否则配置错误时可能把自己锁在服务器外。

三、初始化 Ubuntu

登录服务器后,先更新系统并安装本文所需工具:

bash
sudo apt update
sudo apt full-upgrade -y
sudo apt install -y curl openssl ufw ca-certificates
sudo timedatectl set-timezone Asia/Shanghai
timedatectl status

REALITY 对时间偏差有校验,正常的系统时间很重要。Ubuntu 通常已经启用时间同步,可检查:

bash
timedatectl show -p NTPSynchronized

期望看到:

text
NTPSynchronized=yes

可选:加固 SSH

先确认公钥登录成功,再创建单独的 SSH 配置片段:

bash
sudo nano /etc/ssh/sshd_config.d/99-hardening.conf

写入:

text
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes

检查配置并平滑重载:

bash
sudo sshd -t
sudo systemctl reload ssh

保持原会话不要关闭,再从新终端登录一次。新会话确认正常后,才算加固完成。

四、放行云安全组和 UFW

这里有两层防火墙:

  1. 云厂商控制台中的安全组或轻量服务器防火墙;
  2. Ubuntu 本机的 UFW。

云控制台至少添加下面两条入站规则:

协议端口来源用途
TCP22建议限制为自己的公网 IP;不固定时可暂用 0.0.0.0/0SSH
TCP4430.0.0.0/0VLESS + REALITY

如果 SSH 使用了自定义端口,请相应替换 22。

然后配置 UFW。顺序不能反:先允许 SSH,再启用防火墙。

bash
sudo ufw allow OpenSSH
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose

五、使用官方脚本安装 Xray

使用 XTLS 官方维护的安装脚本:

bash
sudo bash -c "$(curl -L https://github.com/XTLS/Xray-install/raw/main/install-release.sh)" @ install

安装完成后检查版本和文件位置:

bash
/usr/local/bin/xray version
systemctl cat xray

官方脚本通常会安装到:

text
程序:/usr/local/bin/xray
配置:/usr/local/etc/xray/config.json
服务:/etc/systemd/system/xray.service

六、生成 UUID、X25519 密钥和 shortId

1. 生成 UUID

bash
/usr/local/bin/xray uuid

保存输出,后文用 <UUID> 表示。

2. 生成 REALITY X25519 密钥对

bash
/usr/local/bin/xray x25519

不同 Xray 版本的输出名称可能不同,常见形式是:

text
PrivateKey: <REALITY_PRIVATE_KEY>
Password: <REALITY_PUBLIC_KEY>

旧版本可能把第二行显示为 PublicKey。它们的对应关系不变:

Xray 输出填写位置
PrivateKey服务端 privateKey
Password 或旧版 PublicKeyClash 的 reality-opts.public-key

私钥只能留在服务器。不要把私钥填进 Clash,也不要把它截图或提交到 Git 仓库。

3. 生成 shortId

bash
openssl rand -hex 8

这会生成 16 个十六进制字符,也就是 8 字节,例如:

text
6f1a2b3c4d5e7f80

后文用 <SHORT_ID> 表示。shortId 必须只包含 0-9a-f,字符数必须为偶数,最长 16 个字符。

4. 先整理好四个值

text
<SERVER_IP>          服务器公网 IP
<UUID>               xray uuid 的输出
<REALITY_PRIVATE_KEY> xray x25519 的 PrivateKey
<REALITY_PUBLIC_KEY>  xray x25519 的 Password 或 PublicKey
<SHORT_ID>            openssl rand -hex 8 的输出

七、编写 Xray 服务端配置

先备份安装脚本生成的默认配置:

bash
sudo cp /usr/local/etc/xray/config.json /usr/local/etc/xray/config.json.bak
sudo nano /usr/local/etc/xray/config.json

完整替换为下面的内容,只替换尖括号占位符:

json
{
  "log": {
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "tag": "vless-reality-in",
      "listen": "0.0.0.0",
      "port": 443,
      "protocol": "vless",
      "settings": {
        "clients": [
          {
            "id": "<UUID>",
            "flow": "xtls-rprx-vision",
            "email": "my-device"
          }
        ],
        "decryption": "none"
      },
      "streamSettings": {
        "network": "raw",
        "security": "reality",
        "realitySettings": {
          "show": false,
          "target": "www.bing.com:443",
          "xver": 0,
          "serverNames": ["www.bing.com"],
          "privateKey": "<REALITY_PRIVATE_KEY>",
          "shortIds": ["<SHORT_ID>"]
        }
      },
      "sniffing": {
        "enabled": true,
        "destOverride": ["http", "tls"]
      }
    }
  ],
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom"
    },
    {
      "tag": "block",
      "protocol": "blackhole"
    }
  ],
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "block"
      }
    ]
  }
}

sniffing 让 Xray 从 TLS 握手里读出客户端真正要访问的域名。基础方案不依赖它,但后文按域名分流(第十六节)必须有它,建议一开始就打开。

这里使用的是 Xray 新版文档中的 network: "raw"。它表示原始 TCP 字节流,也就是本文方案中的 TCP;在旧版教程里经常能看到 network: "tcp"。客户端 Mihomo 配置仍然写 network: tcp

再次检查三个 Bing 字段:

text
服务端 target      = www.bing.com:443
服务端 serverNames = www.bing.com
客户端 servername  = www.bing.com

八、测试配置并启动 systemd 服务

先只检查配置,不要急着重启:

bash
sudo /usr/local/bin/xray run -test -config /usr/local/etc/xray/config.json

看到类似下面的内容表示语法检查通过:

text
Configuration OK.

然后启动并设为开机自启:

bash
sudo systemctl enable --now xray
sudo systemctl restart xray
sudo systemctl status xray --no-pager -l

确认 443 正在监听:

bash
sudo ss -lntp | grep ':443'

查看最近日志:

bash
sudo journalctl -u xray -n 100 --no-pager

如果服务启动失败,优先执行:

bash
sudo /usr/local/bin/xray run -test -config /usr/local/etc/xray/config.json
sudo journalctl -u xray -n 200 --no-pager

不要反复盲目重装。配置检查和 systemd 日志通常会直接指出 JSON、字段名、端口占用或权限问题。

九、编写 Clash Verge Rev 配置

在自己的电脑上新建一个文件,例如 my-vless.yaml,写入下面的完整配置:

yaml
mixed-port: 7897
allow-lan: false
mode: rule
log-level: info
ipv6: false

proxies:
  - name: '我的-REALITY'
    type: vless
    server: <SERVER_IP>
    port: 443
    uuid: <UUID>
    network: tcp
    tls: true
    udp: true
    flow: xtls-rprx-vision
    servername: www.bing.com
    client-fingerprint: chrome
    reality-opts:
      public-key: <REALITY_PUBLIC_KEY>
      short-id: <SHORT_ID>

proxy-groups:
  - name: '节点选择'
    type: select
    proxies:
      - '我的-REALITY'
      - DIRECT

rules:
  - GEOIP,CN,DIRECT
  - MATCH,节点选择

YAML 对缩进敏感,请使用空格,不要使用 Tab。下面这些值必须和服务端对应:

Clash 字段服务端来源
server服务器公网 IP
portXray 入站端口 443
uuidVLESS 客户 UUID
servername服务端 serverNames 中的 www.bing.com
public-keyX25519 的 Password 或旧版 PublicKey
short-id服务端 shortIds 中的值

public-key 一定不能填服务端私钥。

十、在 Clash Verge Rev 中导入并启用

不同版本的界面名称可能略有差异,操作顺序基本相同:

  1. 打开 Clash Verge Rev;
  2. 进入“订阅”或“配置”;
  3. 选择“新建”或“导入本地配置”;
  4. 导入刚才的 my-vless.yaml
  5. 选中并启用这份配置;
  6. 在“代理”页面选择“节点选择”中的“我的-REALITY”;
  7. 打开“系统代理”;
  8. 需要接管更多应用流量时,再按需启用 TUN 模式。

建议先只打开系统代理验证。系统代理工作正常后,再配置 TUN,这样出现问题时更容易判断是节点本身还是本机接管规则的问题。

十一、连通性测试

1. 在本机测试服务器端口

macOS 或 Linux:

bash
nc -vz <SERVER_IP> 443

如果显示连接成功,说明公网 IP、云安全组、UFW 和 Xray 监听至少已经打通。

端口通不代表 REALITY 参数一定正确;UUID、密钥、shortId 或 SNI 错误时,TCP 仍可能连通,但代理不可用。

2. 测试代理出口

启用 Clash Verge Rev 后执行:

bash
curl -x http://127.0.0.1:7897 https://api.ipify.org
echo

如果输出的是服务器公网 IP,说明代理链路已经工作。

再测试普通 HTTPS:

bash
curl -I -x http://127.0.0.1:7897 https://www.google.com

3. 同时观察服务端日志

服务器执行:

bash
sudo journalctl -u xray -f

然后在客户端重新发起请求。测试结束按 Ctrl+C 退出日志跟踪。

十二、故障排查流程

VLESS REALITY 故障排查流程
从服务状态、端口、防火墙、客户端参数到 REALITY 目标站逐层排查

排查时按层次进行,速度会比反复修改配置快得多。

1. Xray 服务是否正常

bash
sudo systemctl is-active xray
sudo systemctl status xray --no-pager -l
sudo /usr/local/bin/xray run -test -config /usr/local/etc/xray/config.json

如果不是 active,先修服务端配置,不要继续折腾 Clash。

2. 443 是否被监听

bash
sudo ss -lntp | grep ':443'

没有输出:Xray 没启动、配置没有生效,或监听了其他端口。

如果提示端口被占用:

bash
sudo ss -lntp '( sport = :443 )'

确认是哪个程序占用端口,再决定修改 Xray 端口还是调整现有服务。不要直接结束不认识的进程。

3. 两层防火墙是否都放行

bash
sudo ufw status verbose

同时到云厂商控制台检查 TCP 443 入站规则。只改 UFW、不改云安全组,外部仍然无法连接。

4. 六个客户端参数是否逐字一致

重点核对:

text
服务器 IP
端口
UUID
REALITY 公钥
shortId
servername = www.bing.com

常见复制问题包括:值前后带空格、把私钥当成公钥、shortId 少一个字符、YAML 缩进错误、UUID 复制不完整。

5. 真实故障:Microsoft 证书记录超过 REALITY 限制

这次部署最隐蔽的问题发生在 REALITY 目标站。

当时使用:

text
target: www.microsoft.com:443
serverNames: [www.microsoft.com]
servername: www.microsoft.com

在 Xray 26.3.27 中,www.microsoft.com 返回了 8273 字节证书记录,处理时超过 REALITY 的限制。表现为:

  • Xray 服务可以正常启动;
  • 443 端口可以连接;
  • 云安全组和 UFW 都已放行;
  • UUID、公私钥和 shortId 也一致;
  • 但客户端 REALITY 握手失败,服务端日志指向证书记录或 REALITY 处理异常。

最终修复方式是同时修改服务端和客户端:

text
服务端 target      → www.bing.com:443
服务端 serverNames → [www.bing.com]
客户端 servername  → www.bing.com

切换到证书记录更小的 www.bing.com 后恢复正常。

如果以后更换伪装目标,不能只看“浏览器能否打开”,还应实际验证 Xray 日志和 REALITY 握手。目标站的 TLS 行为、证书链和网络可达性都可能变化。

十三、常见错误速查

现象常见原因处理方式
xray 启动失败JSON 逗号、引号或字段写错先执行 xray run -test
443 连接超时云安全组或 UFW 未放行同时检查两层防火墙
443 拒绝连接Xray 未监听或端口错误检查 systemd 与 ss -lntp
TCP 能连接但代理失败UUID、密钥、shortId、SNI 不一致逐项比对客户端与服务端
invalid shortId非十六进制、奇数长度或超过 16 字符重新执行 openssl rand -hex 8
REALITY 验证失败把私钥填到了 ClashClash 必须使用 Password/PublicKey
YAML 导入失败缩进、Tab 或冒号后缺空格使用纯空格并检查层级
有些应用不走代理只开启系统代理,应用不遵循系统设置确认规则,必要时启用 TUN
浏览器能用但命令行不行终端没有使用系统代理curl -x 显式测试
握手在目标站阶段失败目标站 TLS 或证书记录不兼容固定使用本文验证过的 www.bing.com
某些网站反复弹 Cloudflare 人机验证服务器 IP 或整个网段信誉偏低见第十六节,为这些域名加 WARP 出口

十四、迁移到更便宜的服务器

迁移时不要直接删除旧服务器,建议并行验证:

  1. 创建新的 Ubuntu 服务器;
  2. 按本文安装 Xray;
  3. 可以沿用原 UUID,也可以生成新 UUID;
  4. 建议为新服务器重新生成 X25519 密钥和 shortId
  5. 复制配置,但替换新服务器的私钥;
  6. 在 Clash 中复制原节点,修改 IP、公钥和 shortId;
  7. 新节点连续测试几天;
  8. 确认稳定并备份必要信息后,再释放旧服务器。

迁移后如果服务器 IP 变化,Clash 的 server 必须更新。若重新生成密钥,public-key 也必须更新。

十五、安全与维护建议

密钥管理

  • 不要在博客、聊天截图、代码仓库中公开 UUID、私钥和 shortId;
  • 每台服务器使用独立的 X25519 密钥;
  • 每台设备可以使用独立 UUID,方便单独吊销;
  • 怀疑配置泄露时,重新生成 UUID、密钥和 shortId,而不是只改节点名称。

系统维护

定期更新 Ubuntu:

bash
sudo apt update
sudo apt full-upgrade -y

更新 Xray 前先备份配置:

bash
sudo cp /usr/local/etc/xray/config.json /usr/local/etc/xray/config.json.$(date +%F).bak
sudo bash -c "$(curl -L https://github.com/XTLS/Xray-install/raw/main/install-release.sh)" @ install
sudo /usr/local/bin/xray run -test -config /usr/local/etc/xray/config.json
sudo systemctl restart xray

升级后立即检查版本、服务状态和连接:

bash
/usr/local/bin/xray version
sudo systemctl status xray --no-pager -l
sudo journalctl -u xray -n 100 --no-pager

控制暴露面

  • SSH 优先限制来源 IP,并使用密钥登录;
  • 公网只开放实际需要的 TCP 端口;
  • 不要开放 Xray 本地管理接口;
  • 定期查看云服务器流量和账单告警;
  • REALITY 会把未通过认证的流量转发给 target,应关注异常出站流量;
  • 不要在同一个 443 端口上同时启动 Nginx、Caddy 和 Xray,除非已经设计好端口复用或前置转发。

十六、真实故障:Cloudflare 人机验证死循环与 WARP 分流

服务器正常用了一个月后,出现了另一个和 Xray 本身无关的问题:打开 claude.ai 这类挂在 Cloudflare 后面的网站时,页面停在“正在进行安全验证”,自动检测跑不过,退化成手动勾选“请验证您是真人”,勾了之后又跳回验证页,无限循环。

当时逐项排除过的方向:

  • 换浏览器、开无痕、清 Cookie:没用;
  • 切到手机热点等其他网络:立刻正常;
  • 在腾讯云控制台更换弹性公网 IP:换成同一网段的新 IP 后仍然被拦。

结论是问题出在出口 IP 的信誉上,而不是浏览器或 Xray 配置。

1. 为什么会被拦

Cloudflare 的人机验证并不只看单个 IP,而是综合 IP 所属的 ASN、所在网段、历史滥用记录和近期请求模式打分。云厂商的机房网段本身就被视为高风险来源,43.153.x.x、43.167.x.x 这类腾讯云国际网段又被大量代理服务共用,整段的信誉都不好。再加上一个月里持续通过这个出口跑 Claude Code 等高频工具,从 Cloudflare 的角度看和自动化流量没有区别,分数一路下降,最终跌破阈值。

这也解释了为什么在同一家厂商内换 IP 没有效果:新 IP 还在同一个 ASN 和相邻网段里,评分基本不变。

在服务器上可以直接验证:

bash
curl -sI https://claude.ai | grep -iE "cf-mitigated|^HTTP"

看到 cf-mitigated: challenge 说明 Cloudflare 正在对这个 IP 发起挑战。curl 的默认 UA 本身也容易触发挑战,因此这条只能作为辅助证据,浏览器反复循环才是关键现象。

2. 解决思路:只给被拦的域名换出口

思路不是换服务器,而是在 Xray 里再加一个出口:Cloudflare 自家的 WARP。WARP 是 Cloudflare 免费提供的 WireGuard 隧道服务,从 WARP 出去的流量在 Cloudflare 眼里来自它自己的网络,不会被人机验证拦截。

改造后的链路:

text
Clash Verge Rev → 服务器 Xray ─┬─ 普通流量 → direct(原出口)
                             └─ claude.ai / anthropic.com 等 → WARP → 目标站

Clash 端和 REALITY 入站完全不用改,只在服务端加一个 wireguard 类型的 outbound,再用路由规则把指定域名指过去。

3. 注册 WARP 并取出密钥

wgcf 注册一个免费账号:

bash
cd ~
curl -fsSL -o wgcf "$(curl -fsSL https://api.github.com/repos/ViRb3/wgcf/releases/latest | grep browser_download_url | grep linux_amd64 | cut -d'"' -f4)"
chmod +x wgcf
./wgcf register --accept-tos
./wgcf generate
cat wgcf-profile.conf

wgcf-profile.conf 里需要三个值:

text
PrivateKey  → 服务端 secretKey,后文记为 <WARP_PRIVATE_KEY>
Address     → 两行地址,v4 固定是 172.16.0.2/32,v6 记为 <WARP_IPV6>
PublicKey   → 固定为 bmXOC+F1FxEMF9dyiK2H5/1SUtzH0JuVo51h2wPfgyo=

Xray 的 WireGuard 出口连接 WARP 时还需要一组 reserved,它来自账号的 client_id。新版 wgcf 不会把它写进 wgcf-account.toml,可以拿 access_tokendevice_id 直接向 Cloudflare 接口查询:

bash
TOKEN=$(grep access_token wgcf-account.toml | cut -d"'" -f2)
DEVICE=$(grep device_id wgcf-account.toml | cut -d"'" -f2)
curl -s -H "Authorization: Bearer $TOKEN" \
  "https://api.cloudflareclient.com/v0a2158/reg/$DEVICE" \
  | grep -o '"client_id":"[^"]*"' | cut -d'"' -f4 | base64 -d | od -An -tu1

会输出三个 0 到 255 之间的数字,例如 140 169 74,后文记为 <RESERVED>

wgcf-account.toml 里的 access_tokenprivate_key 同样属于凭据,不要公开。

4. 修改 Xray 配置

确认第七节的 sniffing 已经打开,然后把 outboundsrouting 改成:

json
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom"
    },
    {
      "tag": "warp",
      "protocol": "wireguard",
      "settings": {
        "secretKey": "<WARP_PRIVATE_KEY>",
        "address": ["172.16.0.2/32", "<WARP_IPV6>/128"],
        "peers": [
          {
            "publicKey": "bmXOC+F1FxEMF9dyiK2H5/1SUtzH0JuVo51h2wPfgyo=",
            "endpoint": "engage.cloudflareclient.com:2408"
          }
        ],
        "reserved": [<RESERVED>],
        "mtu": 1280
      }
    },
    {
      "tag": "block",
      "protocol": "blackhole"
    }
  ],
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "domain": [
          "domain:claude.ai",
          "domain:claude.com",
          "domain:anthropic.com",
          "domain:cloudflare.com"
        ],
        "outboundTag": "warp"
      },
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "block"
      }
    ]
  }

reserved 写成 [140, 169, 74] 这种数组形式。domain:cloudflare.com 要一起加上:人机验证脚本从 challenges.cloudflare.com 加载,如果它还从原 IP 出去,验证依旧可能失败。以后其他网站出现同样问题,往这个数组里追加域名即可。

检查并重启:

bash
sudo /usr/local/bin/xray run -test -config /usr/local/etc/xray/config.json
sudo systemctl restart xray
sudo systemctl status xray --no-pager -l

5. 验证分流是否生效

服务端日志会直接显示每条连接走了哪个出口:

bash
sudo journalctl -u xray -n 30 --no-pager

期望看到类似:

text
accepted tcp:claude.ai:443 [vless-reality-in -> warp]
accepted tcp:www.github.com:443 [vless-reality-in >> direct]

客户端再确认目标站不再返回挑战:

bash
curl -x http://127.0.0.1:7897 -sI https://claude.ai | grep -iE "^HTTP|cf-mitigated"

没有 cf-mitigated: challenge 即成功。也可以查看 WARP 状态,因为 cloudflare.com 已在规则里:

bash
curl -x http://127.0.0.1:7897 -s https://www.cloudflare.com/cdn-cgi/trace | grep -E "^(warp|ip)="

期望 warp=on,且 ip 不再是服务器公网 IP。

6. 遇到的坑

  • 刚重启后走 WARP 的域名短暂打不开:WireGuard 握手需要几秒,第一批请求可能超时,等待片刻后恢复。此时 githubyoutube 等走 direct 的站点仍然正常,可以据此判断不是 Xray 挂了。
  • 规则不命中、全部走 direct:多半是入站没开 sniffing,Xray 只拿到 IP 拿不到域名。
  • WARP 一直握手失败:部分线路会限制 UDP 2408,可以把 endpoint 的端口换成 500450017018854 之一再试。
  • 想看更详细的日志:把 loglevel 临时改为 debug,排查完记得改回 warning,否则日志刷得很快。

参考资料

文章标题:自己搭建科学上网:VLESS + TCP + REALITY 完整教程

文章作者:梦幻の风

文章链接:https://www.hstudent.xyz/posts/%E5%B7%A5%E5%85%B7/%E8%87%AA%E5%B7%B1%E6%90%AD%E5%BB%BA%E7%A7%91%E5%AD%A6%E4%B8%8A%E7%BD%91[复制]

最后修改时间:


梦幻の风 梦幻の风

商业转载请联系站长获得授权,非商业转载请注明本文出处及文章链接,您可以自由地在任何媒体以任何形式复制和分发作品,也可以修改和创作,但是分发衍生作品时必须采用相同的许可协议。
本文采用CC BY-NC-SA 4.0进行许可。