为什么要搞这么多机器
一开始只是想有个稳定的梯子。后来慢慢变成了:一台机器干一件事,每件事都有备份方案。
现在手里有 7 台机器,分布在日本、香港、美国、杭州。它们不是"越多越好",而是各司其职 —— 有的负责入口,有的负责出口,有的只做控制面。
分工
| 角色 | 位置 | 职责 |
|---|---|---|
| 控制节点 | 杭州(阿里云) | frp 中转、WebDAV、EasyTier 引导、RustDesk 中继 |
| 主入口 | 香港 | hysteria2(TCP+UDP 有公网映射) |
| 备用入口 | 香港(另一家) | vless + xhttp + REALITY |
| 美国出口 | 洛杉矶 | hysteria2(带宽大,延迟高) |
| 美国出口 2 | 美西 | vless + xhttp + REALITY |
| 家庭节点 | 厦门 | OpenWrt 路由器 + 一台 i5 小主机 |
这个架构的几个原则
1. 控制面和数据面分离
阿里云只做"介绍人"和"中转",不承载代理流量。原因是:
- 国内 VPS 带宽贵(按流量计费)
- 让它跑代理等于把自己的流量成本翻几倍
- 控制面挂了不影响上网
2. 每个入口都要有备份
香港那台是主入口,但如果它挂了,还有另一家的 vless 备用。切换成本 = 在路由器面板点一下。
3. 节点协议要混搭
| 协议 | 优点 | 缺点 |
|---|---|---|
| hysteria2 | 快,QUIC 抗丢包 | UDP 容易被 QoS |
| vless + xhttp + REALITY | 伪装强,TCP 稳定 | 比 hy2 慢一点 |
两条腿走路,一条断了还有另一条。
踩过的坑
坑 1:hy2 的 up/down 填错会直接卡死
hysteria2 的客户端配置里可以写 up: 50 Mbps / down: 200 Mbps。这两个值是给 BBR 流控用的。
如果实际带宽只有 10Mbps 而你写了 200Mbps,hy2 会按 200Mbps 疯狂发包 → 链路拥塞 → 丢包 → 握手直接超时。
教训:不确定就留空,让它自适应。
坑 2:廉价 VPS 的 IPv4 回程可能是黑洞
某台美国 VPS,内地 ping 得通、TCP 能握手,但一传数据就断。
抓包发现:SYN 到了服务器,SYN-ACK 也发出去了,但客户端收不到。
原因:那家机房的上游是 Cogent,而 Cogent 对中国电信的 peering 极差。包进了 Cogent 的网就出不来。
教训:买 VPS 前先 traceroute 看回程落在哪。Cogent 的 IPv4 对中国基本是废的。
坑 3:路由器的 memguard 会偷偷重启 OpenClash
路由器只有 377MB 内存,跑着 OpenClash + 一堆服务,可用内存长期在 15MB 徘徊。
memguard 脚本的逻辑是:可用内存 < 12MB 就重启 OpenClash。
表现就是:每隔几小时,代理会断 20 秒,面板也打不开。
解决:停掉用不上的服务(RustDesk 中继、ttyd)+ 加 512MB swap,可用内存直接翻倍。
现在的状态
阿里云 1608MB 内存 / 40G 盘 / 84 个服务
路由器 377MB 内存 / 2 条默认路由 / OpenClash
家庭节点 i5-10400 / 32G 内存 / KDE
全都在 EasyTier 的虚拟网里,10.126.126.0/24,节点之间都是 P2P 直连。
小结
这套架构的核心不是"技术多先进",而是:
- 每层都有备份
- 控制面和数据面分开
- 出问题能快速定位(抓包 + traceroute + API)
如果你也想搞一套,建议从一台机器 + 一个协议开始,跑稳了再加。