salmonstill/server
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
0b3fdf45c2b6be1d3cd70267ca312a0a3f9701a2
server/VPS流量转发架构说明.md
T

16 KiB
Raw Blame History

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
Reference in New Issue View Git Blame Copy Permalink