由于前段时间再次开始运营给群里老哥们玩的Minecraft服务器，顺带着把相关的网络基础架构(以下就用我暂定了很久的代号“NIC”称呼了)也一同翻新了一下。这次翻新主要有以下目的：
- 通过一系列转发实现更合理的回国线路，降低连回家的延迟
- 将自托管服务器上的服务——包括但不限于游戏和网站，稳定且安全地发布到公网
- 更新NIC中的各个基础软件
1. FRP翻新
最先得到翻新的就是FRP。我知道不少人都对FRP嗤之以鼻，但就我尝试过的选项来看，FRP暂时还是比较好的反代+转发方案。
这次翻新将全部frps和frpc均替换为自行编译的v0.60.0版本。自行编译主要是想绕过云服务器的文件扫描(就不说是哪家了)，经过实验发现虽然自编译版本与GitHub上发行版校验和不同，但能直接原位替换且两个版本之间也能正常通信。因为笔记本要带出去上课，就把源码丢在公寓的树莓派上跑交叉编译了，Golang支持多平台原生二进制发行的好处这就体现出来了。需要注意的是通过APT安装的Golang版本严重过时，需要自行去官网下载新版本手动安装，否则编译时会找不到后续版本改动后的标准库。
几台稍微有些古老的VM上跑的还是用.ini配置文件的FRP，顺便也一起修改了，注意.toml的配置文件有些关键字跟.ini不一致，需要参考新文档对照检查。迁移到新版本过程中遇到FRP起不来大多是配置文件关键字没改干净。
传输协议也要跟上时代了，全部QUIC走起，TLS默认开启不用特意配置，不知道是不是错觉，但似乎能感受到连回家的速度更快更稳定了，在自己网站上写东西也更少遇到断连了。
2. 线路优化
在澳洲直连境内的NIC节点基本都要从旧金山或者圣何塞绕路，跨太平洋绕一圈延迟和丢包都上去了。但到香港节点可以不绕路，追踪了下路由感觉是走的直连的海底光缆；接着从香港连回境内也自然不用绕路。这样一来可以把时常400ms+还丢包的线路优化成不到200ms，RDP基本上跟手可用，甚至可以直接连回家里NAS看视频，即便晚上用网高峰也能稳定2MB/s的传输流。根据情况选择了FRP和SSH隧道结合的方式，将需要连回国的设备经过一系列转发，都能使用这条较优的线路了。
接下来就是优化将自托管的服务通过Cloudflare发布的线路了。之前就已经提到过境内连接Cloudflare Tunnel并不稳定，但没在博客写的情况是：经过几番调整仍然无法稳定连接到Cloudflare，于是先通过FRP转发至香港节点后，再将其连接至Cloudflare。这样“相对稳定”的运行了一年多，但写博客的时候时不时断连导致丢进度还是很难受，于是痛下——好吧其实之前是懒得弄，实际上通过FRP进行两次转发，经过自托管服务器-国内某云节点-香港节点-Cloudflare就能提供稳定连接了。看来有时候还是得破财消灾，云服务商能搞到的线路自然不是我等能及的。
顺便再点艹一下哔哩哔哩，你家海外路线优化做的跟墨索李倪的亲马一样几乎不存在，合着就指望用户自己找较优线路连你家服务器是吧？
3. 服务发布
其实上面已经提到一部分了，也就是网站服务；更多的归根结底也无非还是网站，唯一跟Web不沾边的就是Minecraft服务器了。为了方便也都用的FRP转发，总共发布到华东、华南、香港共三个节点，方便现在天南地北的老哥就近进入。华东节点是大学期间用的上一代NIC的主节点，闲置了挺久现在终于又能在到期前发挥下余热了。
4. 简单小结
其实也没啥好总结了，也就感叹下为了自己“上网”方便每年要多花多少钱。打引号是因为上的大多也不是公共互联网，而是自家私有网络，这些云服务器啊公网节点啊充当的也仅仅有“转发”这一功能了，实际的计算和重要数据存储大多还是发生在我自己的设备上。目前难以摆脱掉的一是沟通工具，二是内容发布平台，三是大模型：前两者在于自建的话根本不会有除了自己以外的人愿意用，只能被迫随潮流；后者在于个人能拥有的算力天花板就在那里了，客观条件限制，跑不起来的就是跑不起来。
想不出来啥很NB的话来总结全文了，就这样。