AT&T 线路丢包根治：Xray VLESS Reverse 反向隧道搭建教程

本文介绍一套更进阶的双服务器结构：把稳定公网入口放在服务器 A，把 AT&T 住宅/商宽出口放在服务器 B，两台之间用 Xray 原生的 VLESS Reverse（反向代理） 连接，由 B 主动拨向 A。它是

《住宅 VPS 链式中转搭建教程》

的升级版，专门用来根治「线路用着用着就大面积丢包」的问题，同时让出口机的 IP 可以随时变化而不用改任何配置。

本教程仅适用于合法、合规且获得授权的网络用途。请遵守所在地法律法规、云服务商条款及平台规则，不要将服务器用于任何违法用途。

一、这套架构解决什么问题

先看整体数据流向：

四个角色各司其职：

角色	位置	职责
用户设备	你自己	用任意支持 VLESS+REALITY+XHTTP 的 Xray 客户端连 A
服务器 A	稳定公网（境外好线路）	唯一的用户入口，跑 REALITY+XHTTP，443 端口；反代门户
服务器 B	AT&T 住宅/商宽线路	主动连 A，负责最终公网出口；对外不开任何入口
Internet	目标站点	看到的是 B 的实时住宅 IP

和链式中转最大的不同在于方向：这里是 B 主动去连 A，而不是别人来连 B。这一个方向的改变，正是它能改善丢包、又能扛住 B 的 IP 变化的根本原因。

二、为什么它能改善丢包

要理解这一点，先记住 AT&T 家宽/商宽网关（BGW 系列）最核心的那条限制：

网关对每秒新建的入站连接数有一个写死在固件里的上限（约 50/s、突发 100），超出的部分被直接随机丢弃。这个限制只掐「从外面进入线路的新连接」，对已经建立好的连接、以及机器主动往外发起的连接都不生效。

它是整条线路上所有 VM 共享的一份预算。谁在线路上瞬间发起大量入站新连接，所有人的连接建立都会跟着开始随机失败——表现就是 ping 通、老连接不断，但新连接连不上。

对照两种结构就能看清区别：

关键点在于：反向隧道结构下，用户从来不直接连 B。

• 用户的所有并发都落在 A 上，在 A 这一侧收敛。A 在境外好线路上，没有这个网关限制。
• B 到 A 只有一条连接，而且是 B 主动往外拨的。出站新连接不吃入站预算，建立一次之后长期保持，几乎不再产生新的入站计数。
• B 代表用户去访问互联网，走的也是出站方向，同样不占入站预算。

于是那份被打爆的「入站新建连接预算」在 B 这一侧几乎降到零。丢包问题的根子——入站新连接被网关随机丢弃——从结构上被绕开了。这不是调参，是把最吃预算的那部分流量整个搬离了受限线路。

干杯Cloud官网：

https://usvps24.com/

三、和「3x-ui 导入出站」方案有什么不同

链式中转教程

里，是中转机主动去连住宅机（入站到住宅机），配置简单，适合大多数人。但如果你的出口机满足下面任意一条，反向隧道会明显更合适：

对比项	3x-ui 导入出站	本文：VLESS Reverse
连接方向	A（中转）连 B（住宅），入站到 B	B 主动连 A，B 无任何入站
B 的公网 IP 变化	要改 A 的出站地址	无需改任何配置，自动重连
B 上要开放端口	要开入站端口并放行防火墙	不开任何入口，防火墙可全关入站
B 暴露面	有一个对外端口	对外只剩改过端口的 SSH
入站限速压力	仍有少量入站到 B	B 入站接近零
配置复杂度	面板点几下	需手写 Xray 配置

一句话：出口机 IP 会变、或者你想让出口机对外零暴露，就用反向隧道。 代价是配置要手写（REALITY + XHTTP + Reverse 目前 3x-ui 面板支持不完整，本教程用 Xray 原生配置）。

四、开始前的检查清单

动手前逐条确认，能省掉后面九成的排错：

• A 有稳定公网 IP，最好再挂一个域名（B 的反向出站连域名比连 IP 更稳）

• A 的 443 端口未被占用（ss -ltnp | grep :443）

• 域名已正确解析到 A（dig +short A_DOMAIN）

• 两台都装最新版 Xray-core（xray version，需支持 XHTTP 与 Reverse）

• 选定的 REALITY 回落域名支持 TLS 1.3 与 X25519（如

  www.microsoft.com

  、

  www.apple.com

  ）

• 准备好一个足够长的随机 XHTTP path、有效的 shortId

• 明确节点数量与命名（下文以前缀 node + 序号为例）

安全约定（和整个文档中心一致）：REALITY 私钥、SSH 私钥、VLESS Encryption 私密材料绝不外发、不截图。交付给客户端的只有公钥、UUID、shortId 和分享链接。

五、服务器 B：先把 SSH 搬到高位端口

这一步必须最先做，而且要按「不锁死自己」的顺序来。全程保留你当前这个已登录的 SSH 会话，不要关。

① 先查现状——记下当前 sshd 配置、云厂商安全组、系统防火墙：

sshd -T | grep -Ei '^(port|passwordauthentication|pubkeyauthentication|permitrootlogin)'
ss -ltnp | grep sshd
# 云安全组在厂商控制台看；系统防火墙：
ufw status 2>/dev/null || nft list ruleset 2>/dev/null | head

② 先放行新端口（示例用 NEW_PORT，选一个 20000–60000 的高位端口）：在云厂商安全组里放行 NEW_PORT/tcp；系统防火墙同步放行：

ufw allow NEW_PORT/tcp    # 用 ufw 的情况；nftables 则加对应 accept 规则

③ 让 sshd 同时监听旧端口和新端口（先并存，别急着删 22）：

④ 用一个全新的 SSH 会话实测新端口（不要关旧会话）：

ssh -p NEW_PORT root@B_IP -i 你的密钥

⑤ 新端口确认能登录后，再停掉 22：把 drop-in 改成只留新端口：

⑥ 收尾：确认新会话仍在、云安全组回收 22/tcp、系统防火墙 ufw delete allow 22/tcp。

⑦ 验证重启后仍生效：systemctl restart ssh 再新开会话连一次；有条件重启整机再连一次，确认新端口开机自启。

全程不改密钥认证方式、不开密码登录。PasswordAuthentication no 和 PubkeyAuthentication yes 保持不动。

六、服务器 A：用户入口 + 反代门户

A 上要跑三样东西：面向用户的 VLESS+REALITY+XHTTP 入站、接收 B 反向隧道的反代监听入站、以及把两者绑起来的反代门户 + 路由。

6.1 安装 Xray 并生成密钥材料

bash -c “$(curl -L

https://github.com/XTLS/Xray-install/raw/main/install-release.sh

)” @ install xray x25519 # 生成 REALITY 公私钥对（记下 Private/Public key） xray uuid # 每个节点一个，生成 N 个 openssl rand -hex 8 # 生成 shortId xray vlessenc # 生成 A↔B 反向链路用的 VLESS Encryption（decryption/encryption 一对）

xray x25519 输出里的 Private key 只写进 A 的配置，永不外发；Public key 才是交给客户端的。

6.2 A 的配置骨架

下面是示例，把 大写占位符 换成你自己生成的值。用户入口走 REALITY+XHTTP，反代监听口 REVERSE_PORT 用裸 RAW（不套 TLS/XHTTP），用 VLESS Encryption 保护：

{
  "log": { "loglevel": "warning" },
  "reverse": {
    "portals": [ { "tag": "portal", "domain": "reverse.internal" } ]
  },
  "inbounds": [
    {
      "tag": "user-in",
      "listen": "0.0.0.0",
      "port": 443,
      "protocol": "vless",
      "settings": {
        "clients": [
          { "id": "UUID_1", "email": "node1" },
          { "id": "UUID_2", "email": "node2" }
        ],
        "decryption": "none"
      },
      "streamSettings": {
        "network": "xhttp",
        "security": "reality",
        "xhttpSettings": { "path": "/LONG_RANDOM_PATH", "mode": "auto" },
        "realitySettings": {
          "target": "www.microsoft.com:443",
          "serverNames": [ "www.microsoft.com" ],
          "privateKey": "REALITY_PRIVATE_KEY",
          "shortIds": [ "SHORT_ID" ]
        }
      }
    },
    {
      "tag": "reverse-in",
      "listen": "0.0.0.0",
      "port": 12345,
      "protocol": "vless",
      "settings": {
        "clients": [ { "id": "BRIDGE_UUID" } ],
        "decryption": "VLESS_ENC_DECRYPTION"
      },
      "streamSettings": { "network": "raw" }
    }
  ],
  "outbounds": [
    { "tag": "portal", "protocol": "vless", "settings": {} }
  ],
  "routing": {
    "rules": [
      { "type": "field", "inboundTag": [ "reverse-in" ], "domain": [ "full:reverse.internal" ], "outboundTag": "portal" },
      { "type": "field", "user": [ "node1", "node2" ], "outboundTag": "portal" }
    ]
  }
}

要点：

• reverse.portals.domain 与路由里的 full:reverse.internal 是内部约定的虚拟域名，A、B 两边必须完全一致，随便起一个即可，不用真实解析。
• 反代监听口这里示例 12345（正文用 REVERSE_PORT 指代），在指定端口监听 B 的主动连接，不写死 B 的任何 IP。
• 路由用 user（即 email） 把每个节点的流量送进 portal —— 这满足「按 email/user 发送到反向出口」。email 字段与节点名称完全一致。

6.3 防火墙（关键：不依赖 B 的 IP）

A 只放行两个入站端口，都不按 B 的 IP 设白名单（B 的 IP 会变）：

ufw allow 443/tcp # 用户入口 ufw allow REVERSE_PORT/tcp # B 反向隧道的落点

反代监听口的安全，靠 VLESS Encryption + BRIDGE_UUID 鉴权，而不是 IP 白名单——这样 B 换 IP 也能连上。

七、服务器 B：反向出口

B 上只有一件事：把一条隧道主动拨向 A，并把隧道里的流量放行到公网。B 不开任何用户入口。

7.1 B 的配置骨架

{ “log”: { “loglevel”: “warning” }, “reverse”: { “bridges”: [ { “tag”: “bridge”, “domain”: “reverse.internal” } ] }, “inbounds”: [], “outbounds”: [ { “tag”: “tunnel”, “protocol”: “vless”, “settings”: { “vnext”: [ { “address”: “A_DOMAIN”, “port”: 12345, “users”: [ { “id”: “BRIDGE_UUID”, “encryption”: “VLESS_ENC_ENCRYPTION” } ] } ] }, “streamSettings”: { “network”: “raw” } }, { “tag”: “freedom”, “protocol”: “freedom” } ], “routing”: { “rules”: [ { “type”: “field”, “inboundTag”: [ “bridge” ], “domain”: [ “full:reverse.internal” ], “outboundTag”: “tunnel” }, { “type”: “field”, “inboundTag”: [ “bridge” ], “outboundTag”: “freedom” } ] } }

要点：

• tunnel 出站的 address 填 A 的域名或稳定 IP（推荐域名）。这是 B 唯一主动连接的目标。
• inbounds 是空的——B 不监听任何用户端口，公网上扫不到 Xray。
• 第一条路由把「域名等于 reverse.internal 的控制流量」送回 tunnel（即拨向 A）；第二条把「真正要出网的用户流量」交给 freedom，由 B 直接出公网。这样 B 就是最终出口。

7.2 systemd：开机自启 + 故障自愈 + 换 IP 自动重连

官方安装脚本已经装了 xray.service。确认它启用了自启和自动重启：

systemctl enable –now xray systemctl show xray -p Restart -p RestartSec # 期望 Restart=on-failure（或 always）

如需更激进的自愈，可加 drop-in：

mkdir -p /etc/systemd/system/xray.service.d printf ‘[Service]\nRestart=always\nRestartSec=5\n’ > /etc/systemd/system/xray.service.d/restart.conf systemctl daemon-reload && systemctl restart xray

B 的公网 IP 变化时不需要任何人工操作：隧道是 B 主动外拨到 A 的域名/稳定 IP 的，链路断开后 Xray 会自动重新拨号连回 A。A 侧不写死 B 的 IP、防火墙也不按 B 的 IP 放行，所以 B 换 IP 对 A 完全透明。

八、多节点 / 多用户

默认在 A 上建 1 个用户即可；只有当你需要多个节点时才按下面扩展。规则很简单：

• 所有节点共用同一个 VLESS+REALITY+XHTTP 入口（同一 443、同一 REALITY 公钥、同一 path）
• 每个节点用不同的 UUID
• 每个节点的 email 与节点名称完全一致（如 node1…nodeN）
• 全部节点都通过同一条 B→A 反向隧道从 B 出口
• 路由规则里把这些 user（email）统一送进 portal
• 不保留任何重复、测试或多余节点

也就是在 6.2 的 clients 里多加几行不同 UUID + 不同 email，再把这些 email 全列进路由的 user 数组。B 侧完全不用动——所有节点复用同一条隧道。

九、部署后必须实际验证

配置改完不等于成功，逐条实测：

#	验证项	怎么查
1	A、B 的 Xray 都是 active	两台各跑systemctl is-active xray
2	B 到 A 反代口有 established 连接	B 上ss -tnp
3	A 没有主动连 B 的配置	检查 A 的outbounds，只有portal，无任何指向 B 的地址
4	A 配置/防火墙不依赖 B 的 IP	全文grepB 的 IP，A 侧应为零命中
5	B 上没有公开用户入口	B 上ss -ltnp，除改过端口的 SSH 外无对外监听
6	每个节点真实客户端能连	用 Xray 客户端逐个导入、逐个连
7	每个节点能查到出口 IP	连上后访问 IP 查询站
8	出口 IP = B 的实时公网 IP	第 7 步显示的 IP 应等于此刻 B 的公网 IP
9	TCP / DNS / HTTPS 分别可用	各测一次：curl网站、nslookup域名、打开 HTTPS 站点
10	重启 B 的 Xray 能自动重连	B 上systemctl restart xray，30 秒内第 2 项的 ESTAB 重新出现

第 8 项是这套架构的成败判据：客户端显示的出口 IP 必须等于服务器 B 的实时公网 IP。如果显示的是 A 的 IP，说明路由没把用户流量送进 portal，回到 6.2 检查 user/路由。

十、交付与回滚

交付给客户端的每个节点，一条 vless:// 分享链接即可包含全部参数：

vless://UUID_1@A_DOMAIN:443?encryption=none&security=reality&type=xhttp&path=%2FLONG_RANDOM_PATH&mode=auto&sni=

www.microsoft.com

&fp=chrome&pbk=REALITY_PUBLIC_KEY&sid=SHORT_ID#node1

• fp=chrome（uTLS 指纹）、type=xhttp、mode=auto、security=reality 都要带上；pbk 是 REALITY 公钥（不是私钥）。
• 把每个节点的链接各生成一个二维码，客户端扫码导入。多个节点的二维码载荷必须互不相同（UUID 不同），生成后务必用扫码工具反解一次，核对名称与 UUID 无误。
• 把所有节点链接汇总保存成一个 UTF-8 文本文件留档。

改动与回滚原则：改前备份相关文件并记下路径时间；所有 JSON 写入走临时文件 + 原子替换；写入后先 xray -test -config 配置 跑通再重启；重启失败立即用备份还原。

cp /usr/local/etc/xray/config.json /usr/local/etc/xray/config.json.bak-$(date +%Y%m%d%H%M) # 写新配置到

config.json.new

… xray -test -config /usr/local/etc/xray/config.json.new \ && mv /usr/local/etc/xray/config.json.new /usr/local/etc/xray/config.json \ && systemctl restart xray \ || echo “测试未通过，保留原配置”

十一、安全、合规与残余风险

• 只在你自己的两台机器之间搭建，B 不对外提供公开代理入口。 把住宅出口做成公开代理，会很快被扫描挂进公开代理库，IP 价值不可逆地损失，也可能被他人行为连累。
• REALITY 私钥、SSH 私钥、VLESS Encryption 私密材料只留在服务器上，不进聊天、不截图、不外发。
• 非空白环境先停手：如果 A 或 B 上已经跑着别的服务、占用了 443 或反代端口，先报告现有监听与冲突，不要覆盖或停掉未知服务。
• 未验证 / 需你自己确认的点：具体 Xray 版本对 XHTTP mode=auto 与 Reverse 的支持以实际 xray version 为准；REALITY 回落域名的可用性随时间变化，部署前用 openssl s_client -connect 域名:443 -tls1_3 确认；不同云厂商安全组的操作路径不同，需按自己厂商控制台执行。

搭好之后，B 这条 AT&T 线路上「入站新连接被网关随机丢弃」的问题会从结构上消失——因为最吃入站预算的用户并发，已经全部搬到 A 上收敛了。