yunnysunny

@firefox12 两种入口都有：
1. SOCKS5 入口：PC 或手机把 socks5 指到路由器，走 VLESS 出去。
2. 透明代理入口：路由器上用 nftables 的 redirect 规则，把命中 IP 集合的 TCP 连接 DNAT 到 zray 监听的端口。zray 用 SO_ORIGINAL_DST 取回原始目标地址，再开一条 VLESS 连接出去。
你说的两个问题，我的看法：
**TCP 流会断。**如果你是 socks5 之后直接 AES-GCM 裸流出去，有可能不是程序的问题，"全随机字节、没有任何协议特征"的流量本身就是 2023 年以后 GFW 重点识别的对象，表现就是跑着跑着被 RST 或者端口被封一段时间。
**UDP 。**我根本没让 UDP 以 UDP 的形态出去。SOCKS5 的 UDP ASSOCIATE 收到的包被封成 XUDP （ Mux.Cool ）帧，塞进同一条 TCP/TLS 隧道里，服务端再还原成 UDP 发出去，full-cone 。从运营商和 GFW 的角度看，这台路由器对外一个 UDP 包都没有，所以不存在"一个端口几个包就被限"的问题。代价也很明确：UDP 走在 TCP 里会有队头阻塞，而且我这边实测载荷超过 600 字节左右容易被服务端出口丢，所以 DNS 、游戏这类小包没问题，QUIC 基本不通。

@lnbiuc zig 中自己实现的 tls 协议

@zengxs 我原本没抱期望，Vision 反倒带来意外惊喜：它避开了二次加密。访问 HTTPS 站点时，数据本身已是浏览器与网站之间的 TLS 密文，Vision 只对握手阶段的包做外层加密，等识别到内层握手完成、后续全是密文，就通知服务器切到“直拷”，原样复制进隧道，不再过一遍 AES-GCM 。此时 zray 只是在两个 socket 间搬运字节，CPU 占用极低，速度完全由链路决定。

@momooc openwrt 就属于软路由了，不过平常咱们用的软路由，很多性能是过剩的，用社区的集成解决方案更省事。

@xiaoxiannv 我一开始的想法也是 7986 ，不过做完这个项目后，我的想法是新三年旧三年，缝缝补补又三年。作为一个负资产的人，还是适应要多适应一下消费降级的生活 😂

@Quarry 800Mhz 的 CPU 频率，120MB 的运行内存，如果硬要用 golang 稳定的运行起来 xray ，我水平还不够，还请大神直言。

@bkmi AI 不会猜到我的个人经历吧，我就是将自己的经历记录下来，就是自己折腾的过程。

最终我选择了独自来应对，没有请律师。但是最近两天我犯了一个严重的错误，交证据的时候，我记错时间了，结果仲裁委现在已经拒绝我提交证据了。

nestjs ，因为用的人多，资料丰富，加之项目组多年经验都是构建在 nestjs 上的，所以不会轻易更换。