最近墙又高了一些，对于在国内的转发机器，特别明显，基本上转发机场都死翘翘了，反正都逃不过长城的嗅探，我把我的搭设给Gemini查看了下，他说我在裸奔，然后给我了一个方案，纯技术层面探讨。
原来方案
广州 (独立 VPS) -> 福州-台湾专线iepl> 台湾家宽ss协议
专线（IEPL）免疫墙，但国内段在“裸奔”IEPL（国际以太网专线）本质上是二层/三层的物理或逻辑直连，确实不过公网的 GFW（防火长城），这是它的核心优势。但数据在进入福州 IEPL 入口之前，需要经过：你 -> 广州腾讯云 -> 福州 这个漫长的国内公网链路。
致命弱点： 国内公网虽然没有 GFW 的墙外阻断机制，但国内各大云服务商（特别是大厂）内部有着极其严苛的 DPI（深度包检测）风控系统。他们要查的不是你有没有爬墙，而是“这台服务器是否被当作非法的流量中转站”。
Shadowsocks协议在现代 DPI 面前毫无伪装能力
SS 协议的设计初衷是加密（Encryption），而不是混淆（Obfuscation）。它的纯随机字节流特征和特定的握手包长度，在如今基于机器学习的流量审计模型中比明文还要显眼，极易受到主动探测（Active Probing）。
当你的 SS 流量从广州流向福州时，广州机房的安全系统看到的是一条长时间保持活跃、流量上下行高度对称、且没有任何标准应用层协议（如 HTTP/TLS）特征的未知加密数据流。这相当于你在国内公网上直接拉响了“我在做代理中继”的警报。
流量多次转发
转发了2次，普通的“端口转发”（TCP/UDP 盲转）：这意味着广州和福州节点只是充当了“传话筒”。你最初的 SS 协议流量的明文指纹、包大小、时序特征，会一字不落地暴露在广州和福州的云防火墙面前。两次转发，等于让国内云厂商的 DPI 探头看了两遍高清无码的非法特征。
gost性能差
每经过一次 GOST 转发，数据包都要经历：网卡 -> 内核态 -> 用户态 (GOST) -> 内核态 -> 网卡 的极其漫长且消耗 CPU 的上下文切换过程。 你搞了“广州 -> 福州”两次转发，这意味着这套沉重的流程要翻倍。这会导致极高的网络延迟（Latency Jitter）、TCP 拥塞控制混乱，以及潜在的 MTU（最大传输单元）碎片化问题。直白点说：机器 CPU 跑满了，网速却卡成了 PPT。
新的方案
用 WireGuard 在广州和福州之间拉一条纯内网的 UDP 隧道，然后通过 Linux 原生的 iptables 把你的流量“塞”进去。Udp2raw 巧妙在使用 FakeTCP（伪造 TCP） 模式进行流量封装。
第一阶段：系统网络基建（两台机器都要执行）
在台湾和广州的两台机器上，分别执行：
# 开启 IPv4 和 IPv6 的内核转发
echo "net.ipv4.ip_forward = 1" | sudo tee -a /etc/sysctl.conf
echo "net.ipv6.conf.all.forwarding = 1" | sudo tee -a /etc/sysctl.conf
sudo sysctl -p
# 安装原生 WireGuard
sudo apt update && sudo apt install wireguard -y第二阶段：生成加密秘钥（两台机器都要执行）
WireGuard 采用非对称加密，不需要账号密码，全靠公私钥对认门。 在台湾和广州的两台机器上，分别执行以下命令生成秘钥，并用记事本把输出的结果记下来，绝不能搞混！
# 进入配置目录并生成秘钥
cd /etc/wireguard/
umask 077
wg genkey | tee privatekey | wg pubkey > publickey
# 查看并记录台湾/广州的私钥 (Private Key)
cat privatekey
# 查看并记录台湾/广州的公钥 (Public Key)
cat publickey第三阶段：配置台湾节点（作为隧道核心服务端）
既然台湾是直通的，我们就让它安静地监听端口等待连接。 在台湾机器上，编辑配置文件：sudo nano /etc/wireguard/wg0.conf 填入以下内容（请注意替换中文标记的部分）：
[Interface]
# 填入【台湾机器】自己的私钥
PrivateKey = 填入台湾的privatekey
# 咱们自定义的内网 IP
Address = 10.13.13.1/24
# 监听端口，随便挑一个不冲突的，这里用 51820。WireGuard 会自动同时监听 IPv4 和 IPv6
ListenPort = 51820
[Peer]
# 填入【广州机器】的公钥！认准了，别填错！
PublicKey = 填入广州的publickey
# 只允许广州的内网 IP 接入
AllowedIPs = 10.13.13.2/32保存退出（Ctrl+O -> Enter -> Ctrl+X）。 启动台湾端：
sudo systemctl enable --now wg-quick@wg0第四阶段：配置广州节点（流量劫持与转发点）
这是最核心的一步。我们不仅要连上台湾，还要把广州收到的流量“塞”进隧道。 假设你最终要代理的业务端口是 8388（无论是你的 SS、VLESS 还是正常的 Web 网站端口，这个服务必须已经在台湾机器上运行并监听 0.0.0.0:8388）。
在广州机器上，编辑配置文件：sudo nano /etc/wireguard/wg0.conf
[Interface]
# 填入【广州机器】自己的私钥
PrivateKey = 填入广州的privatekey
Address = 10.13.13.2/24
# 极其关键：防止 MTU 爆炸导致断流
MTU = 1360
# --- 下面是黑科技：内核级流量劫持 ---
# 逻辑：把外网访问广州公网 8388 端口的 TCP 和 UDP 流量，统统 DNAT 转发给内网的台湾机器 (10.13.13.1:8388)
PostUp = iptables -t nat -A PREROUTING -p tcp --dport 8388 -j DNAT --to-destination 10.13.13.1:8388
PostUp = iptables -t nat -A PREROUTING -p udp --dport 8388 -j DNAT --to-destination 10.13.13.1:8388
# 将出去的流量伪装为 wg0 接口发出的
PostUp = iptables -t nat -A POSTROUTING -o wg0 -j MASQUERADE
# 关闭隧道时自动清理这些规则
PostDown = iptables -t nat -D PREROUTING -p tcp --dport 8388 -j DNAT --to-destination 10.13.13.1:8388
PostDown = iptables -t nat -D PREROUTING -p udp --dport 8388 -j DNAT --to-destination 10.13.13.1:8388
PostDown = iptables -t nat -D POSTROUTING -o wg0 -j MASQUERADE
[Peer]
# 填入【台湾机器】的公钥！
PublicKey = 填入台湾的publickey
# 核心火力覆盖：瞄准福州的 IPv6 直通入口！(注意方括号必须保留)
Endpoint = [0000:0000:0000:59:38d5:ce03:dedb:ff3f]:51820
# 把内网网段划入路由表
AllowedIPs = 10.13.13.0/24
# 防止 NAT 超时断流，每 25 秒发个心跳保活
PersistentKeepalive = 25保存退出。启动广州端：
sudo systemctl enable --now wg-quick@wg0第五阶段：终极验证
ping 10.13.13.1 -c 4如果能收到回复，且延迟极低，恭喜你，你的专属 IPv6 内网高速公路已通车！ 现在，你只需要把本地客户端（你的电脑/手机）指向 广州的公网 IPv4 地址 和 8388 端口，流量就会以内核级的极限速度，被瞬间“传送”到台湾。
引入 Realm 动态转发
为了解决动态域名解析的问题，同时保持极低的性能损耗，我们需要在台湾机器上部署一个用 Rust 编写的极简四层转发工具 —— Realm。它专为这种场景设计，支持 TCP/UDP 同步转发，且具备自动重新解析 DDNS 的能力，性能远超你之前用的 GOST。
部署实操（仅在台湾机器上执行）：
1. 下载并安装 Realm
# 下载编译好的极简二进制程序
wget https://github.com/zhboner/realm/releases/download/v2.6.0/realm-x86_64-unknown-linux-musl.tar.gz
# 解压并赋予执行权限
tar -xvf realm-*.tar.gz
chmod +x realm
# 移动到系统路径
sudo mv realm /usr/local/bin/2. 编写 Realm 转发配置文件
创建一个配置文件：sudo nano /etc/realm.toml，填入以下内容：
[network]
no_tcp_delay = true # 开启 TCP_NODELAY，极大降低延迟
keep_alive = 30 # 保持连接活跃
[[endpoints]]
# 监听台湾本机的 8388 端口（也就是广州 wg0 隧道砸过来的那个端口）
listen = "0.0.0.0:8388"
# 目标指向你的家宽 SS 域名和端口
remote = "twsn3.uzuma.ru:20345"3. 创建 Systemd 守护进程守护它
创建一个后台服务：sudo nano /etc/systemd/system/realm.service
[Unit]
Description=Realm Port Forwarding
After=network-online.target
Wants=network-online.target
[Service]
Type=simple
User=root
# 指定配置文件运行
ExecStart=/usr/local/bin/realm -c /etc/realm.toml
Restart=on-failure
RestartSec=5s
[Install]
WantedBy=multi-user.target4.启动转发服务
sudo systemctl daemon-reload
sudo systemctl enable --now realm
sudo systemctl status realm至此，架构完美闭环。 广州收到的流量 -> 塞进 wg0 隧道 -> 台湾机 8388 端口接收 -> Realm 瞬间接管并实时解析 twsn3.uzuma.ru -> 精准投递到台湾家宽 SS。
这种“把 UDP 强行封装进 TCP/TLS 中传输”的做法虽然隐蔽性无敌，但会引入网络工程界臭名昭著的 “TCP over TCP” (TCP 灾难/TCP Meltdown) 问题——当物理链路出现轻微丢包时，内外两层 TCP 的重传机制会发生严重冲突，导致网速断崖式下跌。
WSTunnel伪装
国内公网（广州 -> 福州 IPv6）跑的不再是 WG 的 UDP 乱码，而是一条标准的 HTTPS 加密长连接。在腾讯云的安全探头看来，这台广州服务器只是在和福州的一个节点进行“非常合规的 Web API 交互”或者“看网页视频”。
第一步：在两端安装 WSTunnel 神器
在台湾和广州的机器上，分别下载并解压 WSTunnel：
# 下载编译好的二进制文件
wget https://github.com/erebe/wstunnel/releases/download/v9.2.1/wstunnel_9.2.1_linux_amd64.tar.gz
# 解压
tar -xvf wstunnel_*.tar.gz
# 移动到系统执行目录并赋予权限
sudo mv wstunnel /usr/local/bin/
sudo chmod +x /usr/local/bin/wstunnel第二步：台湾节点（接应点）披上伪装
台湾机器的 WireGuard 依然在安静地监听 51820 (UDP)。我们现在要让 WSTunnel 站在它前面，挡住外面的视线。
在台湾机器上，创建一个服务：sudo nano /etc/systemd/system/wstunnel-server.service
[Unit]
Description=WSTunnel Server
After=network.target wg-quick@wg0.service
[Service]
Type=simple
User=root
# WSTunnel 监听 [::]:51821 (确保福州 IPv6 也能直通这个端口)
# --restrictTo 限制它解包后只能把流量发给本地的 WireGuard (51820 端口)
ExecStart=/usr/local/bin/wstunnel server ws://[::]:51821 --restrict-to 127.0.0.1:51820
Restart=always
[Install]
WantedBy=multi-user.target启动它：
sudo systemctl daemon-reload && sudo systemctl enable --now wstunnel-server第三步：广州节点（发送点）打包流量
广州机器需要把本地发出的 WireGuard UDP 包，塞进 HTTPS 管道里，射向福州的 IPv6。
先配置广州的 WSTunnel 客户端： 创建服务：
sudo nano /etc/systemd/system/wstunnel-client.service[Unit]
Description=WSTunnel Client
After=network.target
[Service]
Type=simple
User=root
# 监听本地 51821 端口接收 UDP，然后打包成 wss 发给福州的 IPv6
ExecStart=/usr/local/bin/wstunnel client -L udp://127.0.0.1:51821:127.0.0.1:51820 ws://[2408:8748:a100:59:38d5:ce03:dedb:ff3f]:51821
Restart=always
[Install]
WantedBy=multi-user.target启动它
sudo systemctl daemon-reload && sudo systemctl enable --now wstunnel-client最后，修改广州的 WireGuard 配置： 打开 sudo nano /etc/wireguard/wg0.conf，找到 [Peer] 下面的 Endpoint。 不要再把枪口对准公网了，把它改成射向本地的 WSTunnel：
[Peer]
PublicKey = (台湾的公钥)
# 瞄准本地 WSTunnel 的监听端口！
Endpoint = 127.0.0.1:51821
AllowedIPs = 10.13.13.0/24
PersistentKeepalive = 25重启广州的 WireGuard：
sudo systemctl restart wg-quick@wg0如果不通，诊断
在我们这个复杂的架构里，流量要经过：小火箭 -> 广州iptables -> 广州WG -> 广州WSTunnel -> 台湾WSTunnel -> 台湾WG -> 台湾Realm -> 家宽SS。 任何一个环节断了，都会超时。不要瞎猜，我们直接用工程师思维，从外到内、一层层做“X光透视”。
在广州机器上执行：
sudo journalctl -u wstunnel-client -n 20 --no-pager第二步：检查“内层核心”
sudo wg第三步：检查“致命的 MTU 陷阱”
第四步：检查“最后一公里”
在广州机器上执行
ping 10.13.13.1 -c 4大概就是这样。