server/VPS流量转发架构说明.md

VPS流量转发架构说明

---

总览

这套架构基于 Xray + Nginx SNI 分流 + Mihomo 透明代理 + WireGuard，实现：

1. 反向代理内网服务到公网（无需公网 IPv6/端口映射）
2. 异地多 VPS 链路中转代理（Mihomo 客户端接入 → 东京出口）
3. 统一公网入口流量管理（所有流量走 443 端口，无额外端口暴露）
4. qBittorrent 透明代理 + 入站端口转发（NAS PT 下载走北京 VPS 出口，支持 BT 入站连接）
5. Minecraft 基岩版 UDP 转发（独立 WireGuard 隧道 + socat 方案）

---

设备清单

设备	IP / 域名	系统 / 型号	角色
北京 VPS	salmonstill.cn / 49.232.242.90	Ubuntu 22.04	公网入口节点，Nginx + Xray + socat + WireGuard
东京 VPS	tokyo.salmonstill.cn / 43.165.178.10	-	代理出口节点，Xray Reality 出站
旁路由	192.168.1.199 / WG: 10.0.0.2	ImmortalWrt 24.10 (GL-MT2500)	内网反向代理 + 透明代理核心
NAS	192.168.1.188	绿联云 UGOS	内网存储服务（思源笔记、绿联云管理）
qBittorrent	192.168.1.200 (macvlan)	Docker (linuxserver/qbittorrent)	PT 下载专用，独立 IP
Windows 台式机	192.168.1.177	Windows + WSL	内网办公设备，SSH 服务

---

核心组件说明

1. 北京 VPS（公网入口节点）

1.1 Nginx Stream SNI 分流层

配置文件: beijing-vps-stream.conf

Nginx stream 模块监听 443/tcp（IPv4 + IPv6），通过 ssl_preread 在 SSL 握手阶段提取 ClientHello 中的 SNI 字段，按域名分流到不同后端：

SNI 域名	后端	端口	用途
www.apple.com	upstream xray	:9443	旁路由反向代理隧道
www.microsoft.com	upstream mihomo	:9444	Mihomo 客户端代理入口 → 东京出口
news.apple.com	upstream xray_lan	:9445	旁路由 Mihomo 北京直连代理
drive.salmonstill.cn	upstream nas	:38653	绿联云 NAS 服务直接转发
其他域名	upstream npm	:8443	Nginx Proxy Manager 常规 Web 管理

1.2 Xray 服务层

配置文件: xray-北京vps-config.json

入站（共 15 个）：

Reality 入站（3 个） — 均监听 127.0.0.1，由 Nginx 转发过来：

Tag	端口	SNI	Reality target	用途
interconn	9443	www.apple.com	www.apple.com:443	接收旁路由反向代理桥接
mihomo_in	9444	www.microsoft.com	www.microsoft.com:443	接收外部 Mihomo 代理流量
proxy_from_lan	9445	news.apple.com	www.apple.com:443	接收旁路由直连代理流量

dokodemo-door 入站（11 个） — 监听 0.0.0.0，反向代理内网服务：

Tag	端口	路由
external	38653	→ portal → NAS 1.188:9443
external_siyuan	38654	→ portal → NAS 1.188:5005
external_minecraft	39132	→ portal → 旁路由 127.0.0.1:39132
external_wsl	38655	→ portal → Windows 1.177:22
external_nas_ssh	38656	→ portal → NAS 1.188:22
external_router_ssh	38657	→ portal → 旁路由 1.199:22
external_qbit	51413	→ portal → qBittorrent 1.200:51413
external_router_web	39766	→ portal → 旁路由 1.199:80
external_tmp	8501	→ portal → Windows 1.177:8501
external_3000	3000	→ portal → NAS 1.188:3000
external_222	222	→ portal → NAS 1.188:222

Mixed 入站（1 个）：

Tag	端口	用途
proxy_in	10809	SOCKS5/HTTP 混合代理（→ 东京出口）

组件 - Portal:

"reverse": {
  "portals": [
    { "tag": "portal", "domain": "reverse-proxy.xray.internal" }
  ]
}

与旁路由 Bridge 建立永久反向隧道，所有 external_* 入站的流量通过 portal 送入隧道。

出站（2 个）：

Tag	协议	用途
direct	freedom	北京 VPS 直连出网
to_tokyo	VLESS+Reality → us.salmonstill.cn:443	转发到东京 VPS 出口

路由规则：

• 所有 external_* 入站 → portal（送入反向隧道）
• interconn → portal（隧道本身维持）
• mihomo_in + proxy_in → to_tokyo（到东京出口）
• proxy_from_lan → direct（北京直连）

---

2. 东京 VPS（代理出口节点）

配置文件: tokyo-vps-config.json

极简配置：

inbounds: [{
  port: 9443,
  protocol: "vless",
  streamSettings: { security: "reality", serverNames: ["www.microsoft.com"] }
}]
outbounds: [{ protocol: "freedom", tag: "direct" }]

Nginx Stream 层 (东京-vps-stream.conf)：

www.microsoft.com → Xray :9443
default → NPM :8443

• 入站：VLESS+Reality，监听 127.0.0.1:9443，SNI=www.microsoft.com
• 出站：freedom 自由网络出口
• 仅做流量出口转发，无其他逻辑

---

3. 旁路由（内网核心枢纽）

3.1 Xray 反向代理桥接

配置文件: xray-旁路由-config.json

组件 — Bridge:

"reverse": {
  "bridges": [{ "tag": "bridge", "domain": "reverse-proxy.xray.internal" }]
}

与北京 VPS 的 Portal 建立永久 TCP 隧道。来自公网的请求通过该隧道进入内网。

入站（1 个）：

Tag	端口	协议
socks-lan	1080	SOCKS5（备用）

出站（12 个） — 按端口/服务映射内网目标：

Tag	目标	用途
to_nas	192.168.1.188:9443	NAS 管理界面
to_siyuan	192.168.1.188:5005	思源笔记
to_wsl	192.168.1.177:22	WSL SSH
to_nas_ssh	192.168.1.188:22	NAS SSH
to_router_ssh	192.168.1.199:22	旁路由 SSH
to_router_web	192.168.1.199:80	旁路由 Web 管理
to_minecraft	127.0.0.1:39132	Minecraft 服务
to_tmp	192.168.1.177:8501	临时服务
to_3000	192.168.1.188:3000	Web 服务
to_222	192.168.1.188:222	备用服务
to_qbit	192.168.1.200:51413	qBittorrent 入站
interconn	VLESS+Reality → salmonstill.cn:443 (SNI=www.apple.com)	与北京 VPS 的隧道连接
to_beijing_direct	VLESS+Reality → salmonstill.cn:443 (SNI=news.apple.com)	北京直连代理
direct	freedom	直连

路由规则（从 bridge 入站的流量按端口匹配）：

• 38653 → to_nas
• 38654 → to_siyuan
• 38655 → to_wsl
• 38656 → to_nas_ssh
• 38657 → to_router_ssh
• 8501 → to_tmp
• 39766 → to_router_web
• 3000 → to_3000
• 222 → to_222
• 39132 → to_minecraft
• 51413 → to_qbit
• 默认 → to_nas
• socks-lan 入站 → to_beijing_direct

3.2 Mihomo TPROXY 透明代理

配置文件: 旁路由的mihomo config.yaml

专为 qBittorrent PT 流量设计的透明代理方案。

TPROXY 端口: 7893

代理节点（2 个）：

• Xray-Real — VLESS+Reality，SNI=www.microsoft.com，经北京到东京出口
• Beijing-Direct — VLESS+Reality，SNI=news.apple.com，北京直连（skip-cert-verify: true — 因 Reality 返回的是 target www.apple.com 的证书）

策略组（11 个）：

• 国内 → 直连
• 国外 → [Xray-Real, 直连]
• Steam / Microsoft / AI / Stream Media / GitHub / Crypto → 按规则选
• PT-BT → [Beijing-Direct, 直连]（核心策略）

关键路由规则：

SRC-IP-CIDR,192.168.1.200/32,PT-BT,no-resolve  ← qBittorrent 全部走 PT-BT
DOMAIN-SUFFIX,salmonstill.cn,直连
DOMAIN-SUFFIX,volces.com,直连
DOMAIN-KEYWORD,raylink,直连
IP-CIDR,49.232.242.90/32,直连  ← 北京 VPS 防死循环
IP-CIDR,43.165.178.10/32,直连  ← 东京 VPS 防死循环

nftables TPROXY 劫持 (/etc/nftables.d/50-mihomo-tproxy.nft)：

ip saddr 192.168.1.200 meta mark set 1 tproxy to :7893 accept

• 仅劫持来源 192.168.1.200 的流量
• 排除本地/私有地址和 VPS IP（防死循环）

策略路由 (/etc/rc.local)：

ip rule add fwmark 1 table 100
ip route add local 0.0.0.0/0 dev lo table 100

额外监听器：

• :7891 — 全局代理（强制走 Xray-Real → 东京出口）
• :7892 — 强制直连

---

4. qBittorrent PT 下载节点

4.1 网络架构

qBittorrent (192.168.1.200, macvlan)
  └── 网关: 192.168.1.199 (旁路由)

Docker macvlan 网络创建命令：

docker network create -d macvlan \
  --subnet=192.168.1.0/24 \
  --gateway=192.168.1.199 \
  --ip-range=192.168.1.200/32 \
  -o parent=eth0 \
  qbit_macvlan

4.2 流量路径

出站（透明代理）：

qBittorrent → nftables TPROXY劫持 → Mihomo :7893
  → SRC-IP-CIDR 匹配 → PT-BT 策略组 → Beijing-Direct
  → VLESS+Reality (SNI=news.apple.com) → 北京VPS :443
  → Nginx 分流 → proxy_from_lan :9445 → direct → 互联网

入站（端口转发）：

BT Peer → 北京VPS :51413 → external_qbit → portal
  → 反向隧道 → bridge → to_qbit → 192.168.1.200:51413

4.3 qBittorrent 设置

设置	值
监听端口	51413
UPnP/NAT-PMP	禁用
SOCKS5 代理	清空（不使用）
连接协议	仅 TCP（关闭 μTP）
DHT	可选（建议开）
PEX	可选（建议开）

μTP(UDP) 必须关闭 — Xray portal 反向代理不支持 UDP。

4.4 定时做种调度（crontab）

0 1 * * * curl -s -X POST "http://192.168.1.200:8888/api/v2/torrents/start" --data "hashes=all"
0 7 * * * curl -s -X POST "http://192.168.1.200:8888/api/v2/torrents/stop"  --data "hashes=all"

夜间 01:00-07:00 做种，白天暂停节省带宽。

---

5. Minecraft 基岩版 UDP 转发

独立于 Xray 体系的另一套方案，使用 WireGuard + socat 实现 UDP 转发。

5.1 架构

公网玩家 UDP :19132 → 北京VPS socat → WireGuard 隧道
  → 旁路由 10.0.0.2 → 端口转发 + SNAT → NAS 192.168.1.188:19132
  → Docker 容器 (itzg/minecraft-bedrock-server, host 网络)

5.2 北京 VPS 配置

WireGuard (/etc/wireguard/wg0.conf)：

[Interface]
Address = 10.0.0.1/24
ListenPort = 51820
PostUp = iptables -t nat -A POSTROUTING -s 10.0.0.0/24 -o eth0 -j MASQUERADE

[Peer]
PublicKey = 9jPlaUhx2Dc+C5ZqJx6Iu8GtNMig3cFIoqfHg8PZbCA=
AllowedIPs = 10.0.0.2/32
PersistentKeepalive = 25

socat systemd service (/etc/systemd/system/mc-forward.service)：

ExecStart=/usr/bin/socat UDP4-LISTEN:19132,fork,reuseaddr UDP4:10.0.0.2:19132

防火墙：

ufw allow 51820/udp  # WireGuard
ufw allow 19132/udp  # Minecraft

5.3 旁路由配置

WireGuard 接口：

• IP: 10.0.0.2/24
• Peer 端点: salmonstill.cn:51820
• AllowedIPs: 0.0.0.0/0（必须，否则丢弃公网来源包）
• 防火墙区域: wan

端口转发：UDP wan:19132 → lan:192.168.1.188:19132

SNAT 规则：目标 1.188:19132 UDP → 源 IP 重写为 192.168.1.199

确保 NAS 回包发给旁路由而非主路由，避免非对称路由问题。

5.4 NAS Docker 配置

services:
  bedrock:
    image: itzg/minecraft-bedrock-server:2026.2.1
    container_name: mc-bedrock
    network_mode: host
    environment:
      EULA: "TRUE"
      VERSION: "1.26.14.1"
      OPS: "2535472561115036"
    volumes:
      - /volume2/ProgramsV2/minecraft:/data
    restart: unless-stopped

---

6. macOS 客户端配置

配置文件: mac 的mihomo config.yaml

备用客户端配置，与旁路由的 Mihomo 共享相同架构理念：

• 混合端口: 7890
• 监听器: 7891（全局代理→东京出口）、7892（强制直连）
• 单节点: Xray-Real (VLESS+Reality, SNI=www.microsoft.com)
• 完整 rule-providers 规则集（广告、国内、GFW、流媒体、AI、GitHub、Steam 等）
• subscribe.yaml — 与 Mac 配置结构相同，作为通用订阅配置模板
• subscribe-7891-only.yaml — 精简版，全局走 7891 代理代理，适合快速切换

---

流量路径总览

路径 1：内网服务反向代理访问

用户 → salmonstill.cn:443 → Nginx SNI 匹配 → dokodemo-door 入站
  → Xray portal → 反向隧道 → 旁路由 bridge
  → 按端口匹配出站 → 内网目标 → 原路返回

路径 2：代理翻墙（东京出口）

Mihomo 客户端 → salmonstill.cn:443 → Nginx SNI `www.microsoft.com`
  → mihomo_in :9444 → to_tokyo → 东京 VPS → freedom → 互联网

路径 3：北京直连代理（qBittorrent）

qBittorrent → nftables TPROXY → Mihomo :7893
  → PT-BT → Beijing-Direct → salmonstill.cn:443
  → Nginx SNI `news.apple.com` → proxy_from_lan :9445 → direct → 互联网

路径 4：BT 入站

BT Peer → salmonstill.cn:51413 → external_qbit → portal
  → 反向隧道 → bridge → to_qbit → 192.168.1.200:51413

路径 5：Minecraft UDP

公网玩家 → salmonstill.cn:19132 → socat → WireGuard 隧道
  → 旁路由 10.0.0.2 → 端口转发 + SNAT → NAS :19132 → Docker 容器

---

关键配置要点

Reality 密钥体系

位置	用途	Public Key	Private Key
北京 VPS（3个入站共用）	interconn / mihomo_in / proxy_from_lan	62y5gDjPrdeuePGl-D2IW4Cw9Kb8_bSBBTmArvL7Nhs(客户端用）	GGT9LfN_2JdQG68cwrULgUK-adfT6wIokLzWjaB0fXs
东京 VPS	to_tokyo 出口	客户端 to_tokyo 配置中的 password	iBlu3eH1VLf1S5Qw87m_1w0TGYUktDwHAzgpQ2aKuGI

Reality 客户端必须使用 public-key，服务端使用 privateKey，且 serverNames 必须与 Nginx 分流 SNI 严格一致。

防死循环 IP

以下 IP 在旁路由的 Mihomo 规则中必须直连：

• 49.232.242.90 — 北京 VPS
• 43.165.178.10 — 东京 VPS

skip-cert-verify

Beijing-Direct 节点必须设置 skip-cert-verify: true，因为 Reality 返回的是 target（www.apple.com）的证书，但 SNI 是 news.apple.com，TLS 的 SAN 校验会失败。

---

文件清单

文件	目标设备	部署路径
beijing-vps-stream.conf	北京 VPS	/etc/nginx/stream.conf.d/
xray-北京vps-config.json	北京 VPS	/usr/local/etc/xray/config.json
东京-vps-stream.conf	东京 VPS	/etc/nginx/stream.conf.d/
tokyo-vps-config.json	东京 VPS	/usr/local/etc/xray/config.json
旁路由的mihomo config.yaml	旁路由	/opt/mihomo/config.yaml
xray-旁路由-config.json	旁路由	/etc/xray/config.json
mac 的mihomo config.yaml	macOS	本地运行
subscribe.yaml	通用	订阅模板
subscribe-7891-only.yaml	通用	精简版模板
旁路由备份 backup-*.tar.gz	旁路由	ImmortalWrt 系统备份

---

架构优势

1. 极致伪装：所有流量走 443 端口 HTTPS，通过 SNI 区分，无特征被封
2. 零额外端口暴露：除 443 外无公网端口（Minecraft 19132 和 WireGuard 51820 除外）
3. 内网零暴露：NAS/Windows/qBittorrent 无需公网 IP 和端口映射
4. 高可用隧道：Xray portal/bridge 反向代理永久在线
5. 低延迟：Xray Reality 协议性能优异，中转延迟增加 < 10ms
6. 易扩展：新增内网服务只需在旁路由添加路由规则，无需改公网配置

---

部署顺序（标准流程）

1. 腾讯云防火墙开放所需端口（443, 51413/tcp, 51820/udp, 19132/udp）
2. 北京 VPS: 部署 Nginx stream 配置 → nginx -t && systemctl reload nginx
3. 北京 VPS: 部署 Xray 配置 → systemctl restart xray
4. 北京 VPS: 部署 WireGuard → wg-quick@wg0
5. 北京 VPS: 部署 socat → systemctl start mc-forward
6. 东京 VPS: 部署 Nginx + Xray 配置
7. 旁路由: 部署 Xray 配置 → /etc/init.d/xray restart
8. 旁路由: 部署 Mihomo 配置 → /etc/init.d/mihomo restart
9. 旁路由: 部署 nftables 规则 → fw4 reload
10. 旁路由: 配置 WireGuard 接口 + 端口转发 + SNAT（LuCI）
11. NAS: 创建 macvlan 网络 → 启动 qBittorrent 容器
12. NAS: 启动 Minecraft 容器

---

验证命令速查

# 北京 VPS 健康检查
ss -tlnp | grep -E '944[345]|3865[3-7]|51413|10809'
systemctl status nginx xray wg-quick@wg0 mc-forward

# 东京 VPS 健康检查
ss -tlnp | grep 9443
systemctl status nginx xray

# 旁路由
nft list chain inet mihomo_tproxy prerouting | grep 192.168
ip rule show | grep "fwmark 1"
ss -tlnp | grep -E '789[0-3]|1080'
wg show

# qBittorrent 连通性验证
docker exec qbittorrent curl -s https://ip.sb   # 应返回北京 VPS IP

# Minecraft 连通性
systemctl status mc-forward
tcpdump -i wg0 udp port 19132 -n