三年级的 icebear 看着每个月 35 的云服务器账单不禁头疼。我一直很想要一台在自己家里的服务器，然而遗憾的是我的经济条件不允许，于是这个愿望飘了很久。而这一切，在我高中毕业后的那个暑假悄然改变。
开始之前
这篇博客的故事的时间主要是在 2026 年，然而我的第一台小主机其实是 2024 年购买的。有的读者可能好奇，那为什么不讲讲之前小主机的故事呢？
原因其实比较复杂。上一台小主机是 i7-5500U + 128G 石头盘 SATA + 16G 的配置，虽然乍看还行，但是对于稍微重一些的负载就显得非常羸弱。哪怕我单独为这个小主机配置了一个局域网网段和 OpenWRT, 绝大多数服务和操作也只是在这个 PVE 上的一个 LXC 里面完成的。再加上当时我对 PVE 的不耐烦，我其实并没有用它做什么，因此也并没有什么值得拿出来讲讲的东西。
而且，可能因为电源，这个小主机的稳定性并不好：长时间运行 Minecraft 服务器的时候会突然断电重启、长时间不重启会导致网卡出问题断连、重启的时候会卡在不知道什么地方导致需要人工干预、128G 的石头盘在 PVE 下本来就不够用（我本来都不想装 PVE，被骗入坑了）结果写出缓存之后还会特别慢…等等理由都开始让我逐渐疏远这台小主机，于是才有了接下来的故事。
不过值得一提的是那台小主机现在到我宿舍里服役了，主要的用途是旁路网关，只不过还是跑着 PVE。
在阅读这篇博客时，你可能会对我的一些决定感到迷惑。这是因为出于决定时认知的局限和懒惰，我的决定并不总是最优解。这篇博客主要是我的折腾经历而不是一篇教学性质的文章，因此我不担保接下来的内容里有什么参考价值，因为我只是在玩。
不过通常来说我在行文过程中都会顺便提一嘴我当时没想到的或者不打算做的方法，然而如果你觉得有一些特别值得指出的，我没有注意到的方面也欢迎在评论区友善讨论。
这篇博客并没有去深究很多实现上的细节，因此大体上阅读起来应该是比较流畅的。然而如果你对一些软件和概念不是很熟悉，则可能会读起来比较吃力。为了观感，本文不会在解释名词上费太多笔墨。
装机
故事的转机发生在 2026 年初。跟一位群友在外面吃饭的时候，他突然提到他们那里有很多淘汰下来的小主机，而且有 5600/5800 + 32 + 1t 还送个 IPMI，价格只要 800 CNY。
相信有关注过硬件价格的读者都知道，25 年下旬开始硬件价格被AI推的水涨船高，其中增长速度最快的就是内存和储存了。恰好，早在很早之前我就有了更换掉家里云的想法，但我了解到的物价配一套能跑 Minecraft 服务端的主机都得上一两千（我不是装机佬）。因此，当我听到这个价格的时候果断下了单（虽然我钱包大出血了…），然后开始期待这台新的小主机可以重振我的家里云事业。
只不过这个购买的过程说不上顺利。因为种种原因，小主机直到快开学了才成功借助另外买的一块磁盘装机，甚至送到我手里的时候是 4800 而不是 5800 了。而且因为另一个群友想要我手上的 2240 规格 M.2 的缘故，我为了换硬盘（跟他一起买的，对换一下他的 2280）又额外等了一段时间，甚至直到另一半内存和硬盘送齐已经是开学后一两周的事了（甚至更糟糕的是，因为物流原因"寄丢"了一条 1T，因此我的 1T 缩水成了 512G）。不过我也早有准备，多花了一些钱跟其他群友收下了 350 一条的致钛 TiPlus 5000, 才在开学前成功装机。
最后的总开销是 800 + 350 = 1150，感觉还不错。并且我又从老笔记本电脑拆了一块 1T 的 HDD 出来，当尿袋挂在外面用。
操作系统
考虑到我上一台小主机装 PVE 用的并不是很愉快，所以在装这台新机之前我想了很久。我的选项有两个：
- 安装 Proxmox VE (PVE).
PVE 是一个虚拟机管理平台，使用它有很多好处。比如我可以开一个 OpenWRT 然后把一大堆 LXC/KVM 纳入 OWRT 管理的子网，再通过在主路由器配置静态路由来从局域网（和VPN）用独立 IP 直接访问这些虚拟机，可能还可以给朋友开小鸡；我当时还管理了两台国内外的独立服务器，可能还有机会组成 PVE Cluster 然后玩一下 (Live) Migration 之类的高级玩意。但是到头来我还是不太喜欢 PVE 这样复杂的，跟系统里各种乱七八糟的配置耦合的软件，因为你需要对构成 PVE 的许多组件有比较好的理解才能确保折腾的时候游刃有余，而我显然不具备这样的知识储量。不过我上次折腾 PVE 不愉快的点最主要还是因为资源太少了，根本不值得启 PVE，而这次新机器的规格有足足 32+1t (和 1t hdd), 理应来说我可以用的更愉快一些。
- 安装 Fedora 42.
其实换成别的发行版也无异，只是那时候我刚刚接触 Fedora 而且开始对 RHEL 系列比较有好感。这个方案相比 1/PVE 主要是如果我要玩虚拟机就要自己折腾很多东西。比如如果我想要运行 Windows VM 那么很不幸的我需要自己配置桥接网卡，把 QEMU 跑起来，然后可能还要写个 systemd unit 来管理开机启动。不过好处也非常明显：没有 PVE 的包袱、更低的资源占用、我的机器上没有黑箱、等等。
其实关于到底选什么操作系统这个问题从我下单服务器后的第一天我就开始想了。这段时间里，我也去研究了一下 VM 的在线迁移是怎么做的，然后我意识到：既然 Live Migration 是 QEMU 自己就能做到的事情，我何苦要为了一点点虚拟化需求逼着我自己去用一整套虚拟化平台呢？
直接把 VM 发配到德国去听起来很好玩，但我对 PVE 没什么兴趣，而且我可以自己做。最后我选择了裸机 Fedora, yeeeeeeeeeeeeee! 一想到少了一层虚拟化或者 Nested LXC 感觉心里洁癖都舒服了不少，起码到现在我也没有后悔这个决定。
后注：完全没考虑 Windows 呢
文件系统
装一台新机就不得不提文件系统选什么。虽然我不是对文件系统狂热的那种人，但是我觉得如果能够充分的利用文件系统给予的特性是一件好事。我考虑的主要有这些：
- XFS. XFS 是 RHEL 推荐的文件系统。我把它看作 ext4 的上位替代，尽管它无法缩小容量，但是服务器场景里并没有太多这样的需求。
- LVM. 它并不是一种文件系统（全程 Logical Volume Manager），我觉得它是一种对块设备的抽象。如果我以后想要添加更多硬盘的话，LVM + 任意文件系统似乎都是一个好选择，但是是不是不应该跟 HDD 拼一块？
- BTRFS. 比较新一点的 CoW 文件系统。虽然名声不太好但是似乎除了 BTRFS RAID 之外都还算比较稳定，而且特性也很多：可以 snapshot, 分 subvol, 透明压缩和对 ssd 优化等等。
- ZFS. 老牌 CoW 文件系统，也有很多特性，缺点是内存似乎要求比较多（ARC）
虽然我对文件系统的了解主要都是道听途说，但是也不妨碍我就这么将就用下去。
最后是在 XFS 和 BTRFS 里面选。首先，LVM 对于多盘才有用，我的小主机里似乎只有一个盘位，且我当时短期内也没有考虑加盘（M.2, 不考虑外挂尿袋）的计划，因此并不是很想用 LVM。其次，我考虑 ZFS 的时候我的主机只有 16gb 的内存（另外一条 16gb 是开学后才到的），而我当时对 ZFS 有一些错误的刻板印象（ZFS 的缓存常被人误认为是把内存占用掉了），导致我最后还是选择了 btrfs，虽然我现在有点后悔这个决定。如果让我重新选一次，我恐怕会选 XFS.
在系统和文件系统都决定好之后，基本上这台服务器就装机完成了。
科学上网
想让这台服务器发挥作用，不得不品的一环就是国情网络。
由于一些特殊原因，我只能用 sing-box。其次，我有很多服务器以及需要使用他们的设备，而有时候我会经常修改 sing-box 的配置文件来诊断或者调整一些流量路由行为，一个个复制配置文件很麻烦，需要一个负责分发配置文件的工具。
而且，我要根据情景调整配置文件。假设我们有一个完整的配置文件：它有完整的分流规则，有 tun, mixed-in 两种 inbound, 以及作为 endpoint 接入了我的 tailnet。对于手机来说，这个配置文件特别理想，因为你（没有 root）不能同时启动两个 VPN，因此流量全部转交给 sing-box 处理是一件很自然的事情。然而，我的电脑不这么想：它已经安装了 tailscaled，也并不打算使用 sing-box 来管理前往 tailnet 的流量（实际上 sing-box 内的 tailscale 似乎有性能问题，而且会导致我无法使用 Funnel 这样的高级特性）。不仅如此，它甚至还要对配置文件做一些修改：启用管理 api, 调整 mixed-in 的监听端口甚至有必要的时候彻底关掉 tun inbound，等等。而服务器的要求更多：主路由器已经接入了 tailscale，它要求 sing-box 删除 tailnet 接入的配置，修改 tun-inbound 里的路由以绕过一些特定的目标 IP，固定自己使用对当前网络来说最优的线路而不是延迟最佳的线路，等等。
借着装机的机会，我打算解决一下这些问题。我最后 fork 了 sing-box，解法如下：
配置文件：分发与适配
配置文件的分发和适配是一起解决的。一个很自然的思路是写一个 serverless 脚本负责根据 URL Param 实现鉴权和按需要修改配置文件。由此，我们就可以在设备上通过调整 URL 参数来适配不同的使用场景。这样还有一个好处就是当你分发所谓的订阅连接给朋友的时候，他们也可以通过修改 URL 删除不需要的部分。(iceBear67/sing-dist)
比如：
手机: universal.json?passkey=&ts-auth-key=&ts-subnet-router=xxxx/32,xxxx/32,10.1.0.0/16&auto_route=true
解释：因为大部分设备都不需要 sing-box 来接管 tailscale 的配置，因此我把 tailscale 做成了可选项。这样，手机就可以通过 URL 参数设置 tailscale endpoint，然后通过 sing-box 接入我的 tailnet (App 会在 auth-key 缺失的时候提示用户登录来获取登录态)。
电脑: universal.json?passkey=&log=info&auto_route=true&clash_api=&route-exclude=10.0.0.0/8,192.168.1.1/24,100.64.0.0/10&default=smart-direct-out"
解释：因为 tailscaled 本身就会在本地广播 tailnet 的路由，因此通过 route-exclude 让 sing-box 设置 tun 路由时绕过本机已有 tailnet 路由和其他 wireguard 接口需要的路由（192.168.1.1/24）。
然后是 sing-box 本身。我不喜欢用那些 WebView GUI, 所以我的 sing-box 基本上都是裸核运行（配合 clash_api 和 yacd 做管理）。因此，我为 sing-box 添加了从环境变量中获取 URL 并下载加载配置的功能：
add: read config from subscription link for `run` command
diff --git a/cmd/sing-box/cmd_run.go b/cmd/sing-box/cmd_run.go
index 7f46da00..1199a64b 100644
--- a/cmd/sing-box/cmd_run.go
+++ b/cmd/sing-box/cmd_run.go
@@ -51,15 +51,28 @@ func readConfigAt(path string) (*OptionsEntry, error) {
err error
)
subscriptionLink := os.Getenv("SING_SUBSCRIPTION_LINK")
+ subscriptionCache := os.Getenv("SING_SUBSCRIPTION_CACHE")
if path == "stdin" {
configContent, err = io.ReadAll(os.Stdin)
} else if path == "env" && subscriptionLink != "" {
configContentResponse, err := http.Get(subscriptionLink)
- if err != nil {
- return nil, E.Cause(err, "failed to GET subscription link")
+ if err != nil || configContentResponse.StatusCode != 200 {
+ if subscriptionCache != "" {
+ log.Info("using previous subscription cache")
+ configContent, err = os.ReadFile(subscriptionCache)
+ } else {
+ return nil, E.Cause(err, "failed to GET subscription link")
+ }
+ } else {
+ defer configContentResponse.Body.Close()
+ configContent, err = io.ReadAll(configContentResponse.Body)
+ if err == nil && subscriptionCache != "" {
+ _err := os.WriteFile(subscriptionCache, configContent, 0600)
+ if _err != nil {
+ log.Error(E.Cause(_err, "failed to cache subscription file"))
+ }
+ }
}
- defer configContentResponse.Body.Close()
- configContent, err = io.ReadAll(configContentResponse.Body)
} else {
configContent, err = os.ReadFile(path)
}
.
配合 crontab，我只要在本地 git push 就可以部署到服务器和设备上。
配置文件：自定义代价的 URLTest
sing-box 的 urltest 让我很不满意的一点就是我不能配置测试回落或者每个节点的权重，有时候更快的线路不一定是好线路，因此我也将这个功能实现到了我的 fork 中：
feat: Add costs field to URLTestOutboundOptions and update NewURLTestGroup
diff --git a/option/group.go b/option/group.go
index 02b3a5ec..d0d1aa1d 100644
--- a/option/group.go
+++ b/option/group.go
@@ -10,6 +10,7 @@ type SelectorOutboundOptions struct {
type URLTestOutboundOptions struct {
Outbounds []string `json:"outbounds"`
+ Costs map[string]uint16 `json:"costs,omitempty"`
URL string `json:"url,omitempty"`
Interval badoption.Duration `json:"interval,omitempty"`
Tolerance uint16 `json:"tolerance,omitempty"`
diff --git a/protocol/group/urltest.go b/protocol/group/urltest.go
index 26967279..da064e21 100644
--- a/protocol/group/urltest.go
+++ b/protocol/group/urltest.go
@@ -39,6 +39,7 @@ type URLTest struct {
connection adapter.ConnectionManager
logger log.ContextLogger
tags []string
+ costs map[string]uint16
link string
interval time.Duration
tolerance uint16
@@ -61,6 +62,7 @@ func NewURLTest(ctx context.Context, router adapter.Router, logger log.ContextLo
tolerance: options.Tolerance,
idleTimeout: time.Duration(options.IdleTimeout),
interruptExternalConnections: options.InterruptExistConnections,
+ costs: options.Costs,
}
if len(outbound.tags) == 0 {
return nil, E.New("missing tags")
@@ -77,7 +79,7 @@ func (s *URLTest) Start() error {
}
outbounds = append(outbounds, detour)
}
- group, err := NewURLTestGroup(s.ctx, s.outbound, s.logger, outbounds, s.link, s.interval, s.tolerance, s.idleTimeout, s.interruptExternalConnections)
+ group, err := NewURLTestGroup(s.ctx, s.outbound, s.logger, outbounds, s.costs, s.link, s.interval, s.tolerance, s.idleTimeout, s.interruptExternalConnections)
if err != nil {
return err
}
@@ -194,6 +196,7 @@ type URLTestGroup struct {
pauseCallback *list.Element[pause.Callback]
logger log.Logger
outbounds []adapter.Outbound
+ costs map[string]uint16
link string
interval time.Duration
tolerance uint16
@@ -211,7 +214,7 @@ type URLTestGroup struct {
lastActive common.TypedValue[time.Time]
}
-func NewURLTestGroup(ctx context.Context, outboundManager adapter.OutboundManager, logger log.Logger, outbounds []adapter.Outbound, link string, interval time.Duration, tolerance uint16, idleTimeout time.Duration, interruptExternalConnections bool) (*URLTestGroup, error) {
+func NewURLTestGroup(ctx context.Context, outboundManager adapter.OutboundManager, logger log.Logger, outbounds []adapter.Outbound, costs map[string]uint16, link string, interval time.Duration, tolerance uint16, idleTimeout time.Duration, interruptExternalConnections bool) (*URLTestGroup, error) {
if interval == 0 {
interval = C.DefaultURLTestInterval
}
@@ -221,6 +224,9 @@ func NewURLTestGroup(ctx context.Context, outboundManager adapter.OutboundManage
if idleTimeout == 0 {
idleTimeout = C.DefaultURLTestIdleTimeout
}
+ if costs == nil {
+ costs = map[string]uint16{}
+ }
if interval > idleTimeout {
return nil, E.New("interval must be less or equal than idle_timeout")
}
@@ -237,6 +243,7 @@ func NewURLTestGroup(ctx context.Context, outboundManager adapter.OutboundManage
outbound: outboundManager,
logger: logger,
outbounds: outbounds,
+ costs: costs,
link: link,
interval: interval,
tolerance: tolerance,
@@ -398,7 +405,11 @@ func (g *URLTestGroup) urlTest(ctx context.Context, force bool) (map[string]uint
Delay: t,
})
resultAccess.Lock()
- result[tag] = t
+ add_latency, exist := g.costs[tag]
+ if !exist {
+ add_latency = 0
+ }
+ result[tag] = t + add_latency
resultAccess.Unlock()
}
return nil, nil
通过给 URLTest 加延迟的做法是从 daeuniverse/dae 中学来的。由此一来，sing-box 困扰我的两个问题就解决了，只不过还需要配置针对 SFA 的 CI，算不上特别舒服的过程…
解析，重构与 Debug
sing-box 的配置经常有 breaking changes, 而且写错了之后都得等到运行时才能检查。对于这个问题，我后来发现了 jiang-zhexin/typebox，这样一来就可以用 TypeScript 操作/合成/检查配置文件了。 （尽管我的用法是错的
以及平时用 sing-box 难免要做一些排障相关的工作，但是又因为配置多变，有的设备上也难以测试 sing-box 规则的效果，所以我让 Claude 写了一个小工具，可以解析 sing-box 路由规则、规则集以及按照不同的 inbound 来模拟路由规则执行结果：(iceBear67/sing-vis)
虽然不是 100% 准确但是还是有参考价值的。
公网访问
我在新服务器上搭建起 gitea 后的第一个问题就是，我要怎么从公网访问它？我不想狼狈的使用 ip+端口 或者子路径来访问 gitea，那样很难用，所以我选择了配置域名+反代。
我的公网反代配置很简单：本地配置一个 Caddy, 识别到 git.sfclub.cc 就分流到 compose 网络组里的 web-gitea-1:3000。服务器配置一个 Caddy, 负责申请 ACME 证书以及转发请求通过 tailscale 回我家，然后把域名解析到服务器：
家：
http://git.sfclub.cc { # 注意是 http, 否则会自动申请 HTTPS 证书
reverse_proxy http://web-gitea-1:3000 {
}
}
服务器:
git.sfclub.cc {
reverse_proxy http://10.0.0.233:80 {
header_up Host git.sfclub.cc
}
}
这其实并非完美，因为这样做虽然对于外部访问者来说没有什么问题，但我访问内网要绕一圈公网。所以我尝试在路由器上配置 hosts 将 git.sfclub.cc 覆写到我服务器的内网 IP。这个方案一开始能工作，然而在未来的某个时候他就突然失效了，排查发现是因为当你在局域网之外的环境访问到 http://git.sfclub.cc 时，Caddy 会给你发一个 308 Permanent Redirect 直接把你送回 https 去，而这样做就导致你在局域网里使用 http 时浏览器会一直尝试把你纠正到 https 上。又因为家里云上的 Caddy 没有配置 HTTPS 证书，你最终会打不开。
我不想牺牲任何东西：HTTPS 是必要的，公网访问也是必要的，我也不想把流量绕出去。怎么做呢？
HAProxy 与 L4 嗅探分流
阻挡我们的主要障碍是内网的服务没有证书。所以，要么我们让代理与内网 Caddy 都拥有同一份证书，要么流量都往同一个 Caddy 走。考虑到我不想让一个域名的证书同时出现在两个地方，于是我选择了后者，让内网的 Caddy 自己去申请证书，而公网的服务器只负责原样转发。
用于自动申请证书的 ACME 协议支持两种（tls-alpn与http-01情况类似）办法，分别是通过 HTTP 访问检查 (http-01) 和 DNS 记录检查域名所属权 (dns-01)。而HTTP 检查的流程大致如下：
flowchart LR
A[ACME Client] --> B["部署文件到<br/>/.well-known/acme-challenge/{token}"]
B --> C[CA 发起 HTTP 请求]
C --> D{内容正确?}
D -->|是| E[验证通过]
D -->|否| F[验证失败]
简单的说，申请证书的时候 CA 会让我们在 HTTP 服务器的某个路径里面放一串随机数，然后他来访问这个文件之后就可以鉴定这个域名解析到的站点由我们所控制，从而证明我们对域名的归属权。清楚过程，思路就变得清晰了：让 https 和 http 都直接转发到家里云上，这样就可以让家里云的 Caddy 顺利通过 http-01 流程申请证书，再让 HTTPS 流量转发会家里云 terminate，做到对内外统一的 HTTPS 支持。
考虑到公网的服务器上还有其他服务，而且需要同时处理 HTTP 和 HTTPS 两种协议，我使用 HAProxy 来做这件事。Caddy L4 也可行，但是写起来配置略啰嗦。
当你的浏览器访问站点的时候，在 HTTP 头里会有一个 Host 字段。而当你通过 HTTPS 访问时，最外层的 TLS 协议在协议握手时通常会发送一个叫 Server Name Indicator 的属性，它的值通常就是站点域名。
... 无关细节被省略
frontend fe_http
bind :::80 v4v6
mode http
option httplog
acl is_group_home hdr(host) -i -f /usr/local/etc/haproxy/home.list
use_backend backend_home if is_group_home
default_backend backend_local
frontend fe_https
bind :::443 v4v6
mode tcp
option tcplog
tcp-request inspect-delay 5s
tcp-request content accept if { req_ssl_hello_type 1 }
acl is_group_home req.ssl_sni -i -f /usr/local/etc/haproxy/home.list
use_backend backend_home_tcp if is_group_home
default_backend backend_local_tcp
... 无关细节被省略
由此一来，就连内网的 Caddy 也可以向 CA 通过 http-01 自动申请 HTTPS 证书了，就仿佛他在公网上一般。不过其实我当时还有一条多余的 IPv4 没用，虽然最后也没分给家里云用就是了。
Split DNS
在上文，我们已经用局域网的路由器实现了一个简易的 Split DNS: 对于内网的请求，返回内网的地址。对于公网的请求…哪来的公网请求（）公网请求走公网 DNS 当然是得到公网 IP, 然后再通过公网 HAProxy 回流回来啦～
graph TD
clientA["公网用户"] --> publicDNS["公网 DNS, 比如 223.5.5.5"]
clientB["内网用户"] --> router["局域网路由器"]
router --> check["检查是否匹配覆写规则"]
check --"是，覆写内网地址"--> clientB
check -- "并非, 请求上游" --> publicDNS但是，如果我不在家呢？公网入口在国外，我不想穿越 GFW 两次，所以我想使用 tailscale 作 P2P VPN。然而如果要达成 P2P，我自然需要让域名返回内网 IP 的结果，也就是说我在公网的条件下需要得到内网的 IP，如何做？这其实就是 Split DNS.
其实，tailscale 已经给了我们一个 Split DNS 的选项：
但是由于博主扭曲的 sing-box 和 tailscale 在各个机器上的情况不一致，会出现一些问题，比如：为了防止 sing-box 的 DNS 拦截和 tailscale 的 MagicDNS 有冲突，我把 MagicDNS 关了，DNS 全权由 sing-box 处理。但是又因为机器上已经有了 tailscale, sing-box 的配置里不会再负责接入 tailnet，也就无法让 sing-box 通过 tailscale 解析内网域名。而直接转发给 100.100.100.100（tailscaled 本地开的 MagicDNS 地址）可能会导致递归回环。并且，就算转发到 100.100.100.100 能解析，像 Android 的客户端也得去屏蔽这个 dns outbound 并且改写成往另一个 outbound 发，增加分发的复杂度。
况且，PC 上如果全权交给 sing-box 里的 tsnet 接管我就用不到 funnel 这样好用的功能了，我全都要。
所以它的作用属于虽有但不多，我最终决定自建一个 AdGuard Home 专门提供这类特殊域名的 DoH 服务。而且又因为我的所有设备上都有 sing-box 和访问 tailnet 的网络条件，通过 sing-box 配置来为所有设备覆盖听起来也很可取。我的 sing-box 配置总是通过加密查询 DNS 记录，就算我在家里路由器也未必能直接挟持，因此总的来说都是要修改 sing-box 配置的。
compose:
services:
adguard:
image: adguard/adguardhome
restart: unless-stopped
volumes:
- ./adguard/work:/opt/adguardhome/work
- ./adguard/conf:/opt/adguardhome/conf
caddy:
image: caddy:latest
volumes:
- "./caddy:/etc/caddy"
- "./caddy/data:/data"
- "./caddy/config:/config"
restart: unless-stopped
Caddyfile:
some.domain {
# 小巧思，相信有的读者能猜到这里省略了一块什么配置
handle /dns-query* {
respond "Not here" 404
}
handle {
reverse_proxy https://adguard:443 {
transport http {
# AdGuard 的 DoH 强制要求使用 HTTPS, 因此让他上个自签然后跳过检查
tls_insecure_skip_verify
}
}
}
}
DNS 和 Uptime 检查单独放了一个服务器，防止他们被其他服务拖累突然暴毙。
最后是 sing-box 配置：
const newConfig = () => createTypebox({
dns: {
strategy: "prefer_ipv4",
servers: [
{
type: "https",
tag: "dns-split",
domain_resolver: "dns-direct",
detour: "selector-out"
},
],
rules: [
{
domain_suffix: ["sfclub.cc", ".ice", ".ts.net"],
server: "dns-split",
strategy: "prefer_ipv4"
}
]
}
})
这样，所有 sing-box 客户端在处理如上所述的三个域名后缀时，都会往我的 doh 服务器发送处理。而不希望这么做的客户端也可以使用我们早已实现的 URL Param 来删掉有关 dns-split 这个 tag 的规则。
但是还有一个问题：如果每修改一个域名我就要跑一趟 Vercel 然后再跑一趟 AdGuard 改 Override 岂不是很麻烦？这时候就该 dnscontrol 登场了。
DNSControl
我是在 Sukka’s Blog 里发现 DNSControl 的：用代码和 Git 管理 DNS 记录 —— DNSControl 和 GitHub Actions CI/CD 实践，非常感谢他的分享，也建议感兴趣的读者也看看他的这篇文章。
简单来说，DNSControl 可以让你以编写 JavaScript 来操控你的 DNS 记录，他会自动计算 DIFF 并且把你的域名同步到你脚本中描述的状态。之所以选择 AdGuard Home 也是因为它是 dnscontrol 支持的控制目标，并且不需要过多的复杂配置。不妨用我自己的一小段代码来举例：
var aliases = {
"cn-hkg-1": ["example"],
}
var regions = {
"cn-hkg-1": {
v4: "...",
v6: "..."
},
}
D("sfclub.cc", REGISTAR_PORKBUN, DnsProvider(PROVIDER_VERCEL),
DefaultTTL(60),
MX("@", 20, "mx2.zoho.com."),
MX("@", 30, "mx3.zoho.com."),
MX("@", 10, "mx.zoho.com."),
// Create A records for all regions that have IPv4 addresses
regions.filter(it => it[1].v4).map(it => A(it[0], it[1].v4)),
// Create AAAA records for all regions that have IPv6 addresses
regions.filter(it => it[1].v6).map(it => AAAA(it[0], it[1].v6 ?? "impossible")),
// Create CNAME aliases for each region, mapping all aliases to that region's subdomain
aliases.flatMap(region => region[1].map(alias => CNAME(alias, region[0] + ".sfclub.cc."))),
// ...
)
这段代码示例里会自动生成 A/AAAA cn-hkg-1.sfclub.cc 和 CNAME example.sfclub.cc。使用 dnscontrol 的好处主要有二：
-
代码直观。借助 JavaScript 闭包你可以像这个例子一样用对象描述你的域名结构，然后再用几个表达式直接生成出来所有需要的记录。
-
方便协作。dnsconfig 文件可以托管在 git 仓库里由团队维护，部署过程可以交给 CI/CD 来做，没有人知道 secret 是什么，操作也更透明。
由于 DnsProvider 和 Registar 都是方法的参数，于是我们通过在下方加入这样的代码来解决 Split DNS 管理的难题：
var localOnlyServices = ["bt", "memo", "ai"]
var homelabServices = {
"git": "cn-hkg-1",
"media": "cn-hkg-1",
"drive": "cn-hkg-1"
}
// 把 homelab 的服务挂到公网代理去。
objectEntries(homelabServices).forEach(entry => {
aliases[entry[1]].push(entry[0])
});
D("sfclub.cc!clearnet", .......) // 省略
// merge homelabServices -> localOnly
// Combine local-only services with homelab services to create a complete list
// of all services that should point to the homelab IP
var _finalServices = localOnlyServices.concat(homelabServices.map(it => it[0]))
D("sfclub.cc!sbns", NONE, DnsProvider(DSP_ADGUARD),
_finalServices.map(it => A(it, HOMELAB_IP))
)
一下就解决了域名需要内外分别解析，而且外域名需要绑定到某个节点上的问题，非常自然。
在配置好各个 DNS Provider 和 sing-box 后，Split DNS 到这里就结束了，最后解释一下上面的代码：对于我的 Adguard Home，他会根据 DNSControl 设置的 override 规则为 _finalServices 里计算出来的所有结果返回 homelab 的 IP, 从而走 VPN/内网 路径。而公网的解析者会去查询 Vercel DNS 命中由 aliases 和 regions 组合出的结果，进入公网流量路径。还有一个值得提的大概是从 Sukka 那里借鉴来的一个 GitHub Workflow，在每个修改了 DNSControl 脚本的 Commit 下面打印结果：
graph TD
clientB["公网访问者"]
subgraph Tailscale
clientA["内网访问者"]
subgraph 家里云
intnSrv["各种内部服务"]
intnCaddy["Caddy"]
end
subgraph 公网服务器
HAProxy
Caddy
end
end
subgraph DNS
adguard["Adguard Home"]
vercel["公网 DNS"]
end
clientA --"(1) 查询 Split 域"--> adguard
clientA -- "(2) 直接访问" --> intnCaddy
adguard --"回落"--> vercel
intnCaddy --"反代分流"--> intnSrv
clientB -- "*1 查询 Split 域" --> vercel
clientB -- "*2 访问公网网关" --> HAProxy
HAProxy -- "Not Split" --> Caddy
HAProxy -- ":80 HTTP" --> intnCaddy
HAProxy -- ":443 HTTPS" --> intnCaddy
CA -- "作为" --> clientB
adguard --"被更新"--> DNSControl
vercel --"被更新"--> DNSControl至此，我们已经达成了以下目标：
-
靠
git push可以做到修改所有域名的 DNS 和各个服务器/客户端上 sing-box 的最新配置。 -
域名的所有 DNS 记录都可以被程序计算出来，这在后文有大用。
-
实现了 Split DNS, 流量总是能经过最优的路线抵达服务。
在这三板斧之后，家里云已经接近完整可用。但是我们是不是漏掉了什么？
tailscale, 崛起
虽然我们上文已经讲了非常多关于争取 Gitea 能够通过公网 HTTPS 访问的方法，但从来没有提及过 Git over SSH 的事情。其实不仅 Gitea，像是 Minecraft 这样非 HTTPS 的软件也有一样的问题：要么他们已经有了像是 Caddy 这样的分流方案，要么给他们在 Host 上分配端口再通过 Docker 的端口映射暴露出去。这个事情其实对于少数几个服务来说算不上问题，但我的 Homelab 上不止有一个 Gitea 也不止有一个 Minecraft 服务器，所以我并不是很想搞一大堆需要专门记忆的端口然后把防火墙穿的和筛子一样难看。
有没有一种办法能够让用户直接接触到这些容器呢？
“发布” 应用程序路由
一个很自然的想法是用 VPN 来做到这件事，而我用的 VPN 是 tailscale。
曾经，我会在 PVE 里跑一个 OpenWRT 然后在上面配置防火墙，再从我的主路由器写一条静态路由。这么一来，我就可以给我的所有 LXC 和 KVM 都分配上他们自己的 IP，再配置路由就可以把这个 IP 段"广播"到整个 VPN 了，VPN 里的所有用户都能直接访问它们。
虽然这个设计在 PVE 上听起来很简单，但我现在用的是 Docker, 这些容器可不是 PVE 上的 LXC/KVM。但是考虑到每个容器确实也会被 Docker 分配一个 IP 并且通过桥接上网，没准我们也可以试试看。
首先，我们通过 sudo docker inspect lucky-database 来看他的 IP:
然后，我们尝试一下在主路由器上配置 172.25.0.0/24 的静态路由：
之后开始 PING:
$ ping 172.25.0.3
PING 172.25.0.3 (172.25.0.3) 56(84) 字节的数据。
来自 10.0.0.1 icmp_seq=1 目标主机不可达
来自 10.0.0.1 icmp_seq=2 目标主机不可达
来自 10.0.0.1 icmp_seq=3 目标主机不可达
^C
--- 172.25.0.3 ping 统计 ---
已发送 5 个包， 已接收 0 个包, +3 错误, 100% packet loss, time 4123ms
想法失败了，因为 nftables 防火墙会挡住这些数据包。更糟糕的是，Docker 生成的 nftables 规则集合长度高达几个 MB，即使是 LLM 也不太可能去分析而且找到一个稳定的解决方案来绕过 Docker 设下的限制。归根结底，太脏了。
但是或许我们可以换个思路：从外面不能访问，难道还不能从里面访问吗？所以我们其实可以配置一个 tailscale 的容器再让他作为 subnet router 发布一个 Docker 的内网段，然后再在里面配置 serve 来转发 Docker DNS…. 这太麻烦了。但是有反转，tailscale 有一门绝招：我们可以通过 tsnet 直接在任意 golang 程序内获得一部分 tailscale 的能力。这样我们就可以编写程序并做一个容器，利用 tsnet 的 subnet router 功能来广播 Docker 的内网段，然后再在他的用户态网络栈上面直接实现一个 DNS 服务器。这样一来，流量就可以通过这个容器访问 Docker 内网里的其他容器了。
于是我设计出了 tsdns，它的工作原理如下：
首先，tsdns 会通过 tsnet 注册并进入你的 Tailnet 中，然后他同时开始承担 DNS 服务器与子网路由的职责：
-
对于域名解析 我的 SplitDNS 会将关于
homelab.ice的域名（如：gitea.web.homelab.ice）发往 tailscale 网络内的对应 tsdns 来处理，而 tsdns 又会将这个域名翻译成 Docker 认识的web-gitea-1形式交给 Docker DNS，最后得到 Docker 网络组内的 IP 沿路返回给用户。 -
对于 IP 路由 用户应该如何访问容器的内网 IP 呢？这主要是依靠与 Docker 网络组的一个特性：在同一个网络组内的所有容器，都会有一个新网卡绑定他在那个网络组 IP 段下分配到的 IP。也就是说，能通过一个 Docker 网络里访问到的所有容器必然是符合你创建网络组时设定的网络基础信息的（网段等）。这样我们就可以通过配置文件指定一个特殊的 Docker 网络组，提前配置好他的网段，再让这个网段以子网路由的形式发布到 Tailnet 中。这样前往容器的流量也会被自动路由到 tsdns 进行处理。
sequenceDiagram
participant uzer as 用户
participant tsdns as tsdns
participant service as 目标容器
uzer->>tsdns: 查询 DNS 记录
tsdns->>uzer: 返回网络组内 IP
uzer->>service: 经过 tsdns 来访问目标 IP（Subnet Router）这样就做好了流量的完美闭环。值得一提的是，tsdns 的 split dns 能力是 tailscale 直接提供的（尽管仍然需要自己配置）：
这次直接使用 tailscale split dns 而不是配置到 AdGuard Home 上的一个原因主要是因为我们之前已经用 Adguard Home 和 sing-box 解决过一些设备上吃不到 tailscale split dns 的问题了——他们可以经过 Adguard Home 的上游（也就是 tailscale）来获取正确的解析结果。并且，tsdns 与靠它联系的服务处于同样的网络环境，如果你要访问那些服务那么直接从 tsdns 开始第一次沟通是一个好的选择（tailscale 需要时间在网络间建立稳定连接）。
而对于只有 tailscale 而没有 sing-box 的服务器，只需要用 --accept-dns=true 就可以实现互通了。
因为这个 TLD 真没什么人用，而且不会跟搜索域/mDNS的 .lan / .local 发生冲突。
再会 “公网访问”
在运营了一段时间之后，我的 Homelab 上已有三个常驻运行的 Minecraft 服务器，我要如何为玩家提供服务呢？
虽然我家里有 IPv6 公网但是我不考虑 DDNS. 一方面是因为这样做风险比较大，你不知道运营商允许什么不允许什么，而且服务放在公网上比较危险。另一方面是这样做又会重新引入被 tsdns 解决的问题。综合来看，使用 tailscale 并且让它有一个好的 P2P 条件就够了。
FRP
说到真正的公网访问，一个很自然的想法是 fatedier/frp。
不出例外，我当然也用过一段时间，但是你知道的，接下来将要登场的是2026年二月申国国家队最高的墙、全球第一分布式DPI审查体系、手握大量流量样本、分布式接入所有机房和省网关、与政绩考核直接挂钩，是所有加密/伪装/对称流量最严厉的父亲，在新年上演大斩杀，一个月内把所有机场的国内中转拔的一干二净，一己之力踢爆整个陕西电信的海外互联，甚至踹飞部分地区 eSIM 流量漫游。那一夜，机场为它颤抖，就连 Minecraft 服务器都得掂量一下自己正版验证该不该关掉；春风若有怜花意，可否许我再少年，这个时代，能排在申国DPI前面的只有滚木；偏我来时不逢春，纵使现在D狗队友不给力，防火墙也没有输，全场只有它真正想赢。它是真正的横空出世，天下谁能不识君，亦是当世政治价值最高的科技之一….。这件事对于 FRP 最主要的影响是 FRP 也很符合转发对称加密流量的特征，而且有的地区直接禁止使用 FRP（FRP 无论使用何种 transport 特征都十分明显，甚至 QUIC Transport 时 ALPN 里直接写的就是 FRP），导致我当时也因拔线丢了两台机器😭。
像是 Sakura Frp 那样的服务对我的服务器来说不是很够用，价格也算不上很低。因此，frp，卒。（虽然我当时对 frp 做了一些特色改造，但是在 tsdns 出现之后 frp 就直接被斩杀了）
公网 nftables 转发
反正有 tsdns 可以直达了，既然 FRP 用不了就直接用 nftables + tailscale 吧。但是，考虑到我的阿里云被封了，国内的大带宽服务器留给我的选择并不多。
由于国情原因，国内大带宽的服务器价格十分昂贵，所以我们只能从按量计费和不保证带宽（竞技场）这两种情况搜索。好在我混迹🐔圈几个月，稍微找到点门道：
- 阿里云 200M
通过一些办法，你可以用非常低的价格拿下半年的阿里云 200M。但是缺点也很明显：
- 因为门槛比较低，跟你抢带宽的人会很多。
- 阿里云奇怪的限速策略能做到把你限速到 3Mbps. 这对于 MC 服务器来说是远远不够的（下载地图的时候能爆发到 10Mbps, 对于一些命令方块地图来说可以爆发到 30Mbps）。
- 这个渠道在不断收缩，现在估计很难做到这么低的价格了。
而且我的阿里云已经因为上一台机器的原因被 BAN 了，所以我也不考虑这个。
- 阿里云竞价实例
竞价实例的成本很低，大概可以做到每个月光机器的费用约 15 元（前提是不被回收），而且竞价实例不会有恶心你的带宽池设定。阿里云为国内的竞价实例每个用户免费赠送 20GB 的双向流量，使得它对于 MC 服务器来说可能也是可以考虑的选项。
不过其实我后来发现 20GB 也不是很够。我当时还写了个自动部署流程，结果部署被阿里云风控拦截了我才发现原来我号被 ban 了。
- 天翼云
天翼云由于是电信直营，只有单线，但是流量成本是最低的（0.36/gb，国内 BGP 价格 0.8/gb）。缺点也是只有单线，而且天翼云的机器很贵，只有活动时的新用户可以拿下。如果能拿下的话应该是最便宜的方案，活动 VPS 价格20多一年+0.36/gb的计费其实很可观。 国内硬件跟网络比和白菜似的
不过考虑到跨省跨网的情况，现在看来单线十分不值得。
- 腾讯云
其实如果我钱够的话，腾讯云的 200M 毋庸置疑是最佳选择。找代理的最低价格大概是 30/月，无忧云听说能做到 15/月，而且没有阿里云那么变态的限速，是一个值得考虑的备选。
而他的竞价实例相比就显得一般，但是如果是腾讯云大客户的话可以联系他们客户经理拿到静态单线的IP，价格大概是 0.4 左右。
- 华为云
华为也有云业务，而且其实做的挺大的，我记得他们接入的 POP 好像比腾讯和阿里还多。华为云最吸引我的是他的网络有两档：静态 BGP 和动态 BGP，前者可以做到 0.58/GB, 相当于 -27% OFF. 如果是大客户的话还可以半价消费就更便宜了。而且考虑到是 BGP 线路，性价比其实比天翼云还高。
我最终是选择了华为云。因为那个时候刚好有活动，我就入了一台 36/年的 Flexus L 实例，可惜他只有 2M 和捆绑 100GB 的动态 BGP 流量包，但这对我来说并不算什么难题。总所周知，云的一大特点就是 pay for what you use，资源是可以动态增删改的，网络资源也是如此。所以，我们的思路大概就是创建一个 EIP (Elastic IP, 弹性 IP) 然后想办法把它绑定到服务器上。
幸运的是，EIP 本身是不计费的，他只会在闲置的情况下收取保有费，因此多绑定一个 EIP 也不会为我们添加负担。
（0.58/gb是流量包的价格）可见我们确实可以拉到 300Mbps 而不需要额外花费任何代价。接下来是把 EIP 绑定到云服务器上：
糟糕了，这是为什么？因为 Flexus L 是捆绑售卖，你不能给他绑一个新的网卡然后吃他的流量包。（是的，动态BGP也不行）。那怎么办？钱都交了。到处走走，又能发现ENI（Elastic Network Interface, 弹性网卡）的一个特性：
辅助弹性网卡是一种基于弹性网卡的衍生资源，用于解决单个云服务器实例挂载的弹性网卡超出上限，不满足用户使用需要的问题。辅助弹性网卡通过VLAN子接口挂载在弹性网卡上，您可以通过创建辅助弹性网卡，使单个云服务器实例挂载更多网卡，实现灵活、高可用的网络方案配置。(辅助弹性网卡概述)
说人话就是，虽然你的服务器不支持直接多加一个网卡，但是你可以在已经有的那个网卡插一个 “辅助弹性网卡” 然后在主网卡上面搞 VLAN 切一块出来用！所以，按照这个思路把刚刚购买的静态 BGP EIP 作为辅助弹性网卡绑定到主网卡上，然后配置网络接口(ifupdown):
auto eth0.1024
iface eth0.1024 inet static
address a.b.c.d/20 # 辅助网卡的内网 IP
vlan-raw-device eth0
hwaddress ether zz:yy:xx:aa:bb:cc # 辅助网卡的 MAC
post-up ip route add default via 172.31.0.1 dev eth0.1024 table 1024
# 添加策略路由：根据源IP判定 (用于本机主动发信)
post-up ip rule add from a.b.c.d lookup 1024
# 添加策略路由：根据防火墙标记判定 (用于DNAT回包正确原路返回)
post-up ip rule add fwmark 1024 lookup 1024
# 清理规则
pre-down ip rule del fwmark 1024 lookup 1024
pre-down ip rule del from a.b.c.d lookup 1024
pre-down ip route del default via 172.31.0.1 dev eth0.1024 table 1024
这样一来，我们就可以通过两个网卡正常上网了。然而，流量计费并不便宜，哪怕华为只计费单向也是如此（流量转发无论如何都会全部计到，如果单双都计费那就更变态了）：
有的 MC 地图（特别是命令方块多的）一天就能烧掉差不多 3G，差不多一个月要20G往上走，这还只是一个服务器的情况。当初选择按量计费是为了比腾讯云更省钱，而我们现在来拿 30 算一笔账：
- 服务器费用：每个月3块钱
- 流量费用：按 10G 流量包买，27 % 5.8 = 3.8, 那么就是 (27 - 3.8) / 5.8 = 4 (10GB), 而多余出来 3.8 元按照 0.64/gb 的价格处理则是 ~6GB. 46GB.
这样看来，如果流量比较多的情况下还是不要碰流量计费比较好，只不过这个方案对于 L4D2 那样的游戏来说其实性价比比腾讯高是绰绰有余的。
TSLink
公网那么贵，于是也尽量移步到 P2P 上找办法。说到 P2P，就不得不提 tailscale，那都说到 tailscale 了，不带 tsdns 玩怎么行呢？其实玩家如果想加入我的服务器，最简单的办法大概就是直接安装 tailscale 客户端了。
tailscale 的一大卖点就是 P2P，在网络条件良好的情况下他不需要中继服务器并且理论上具有最低的延迟。然而，这个方案的缺点就是安装麻烦（因为 tailnet 免费版本限制非常少的用户数，一般加入我网络的用户都是作为机器注册的。也就是说他们得发个登陆连接给我自己登录），而且如果有的玩家自己也是 tailscale 用户的话也不太方便，这也是主要的困难。好在后来 @wyapx 开发了一个基于 tsnet 的集成式 tailscale 客户端，不需要配置 TUN 和发登陆连接就能自动接入 tailnet，很方便。后来我把它修改成了从网络下载配置文件并加载，并且也添加了针对 tailscale split dns 的支持，这样他就可以直接联动 tsdns 已有的功能。最重要的是，玩家只需要双击就可使用。（saltedfishclub/tslink）
tslink 的配置很直白：
[core]
auth_key = "..."
control_url = "https://controlplane.tailscale.com"
ephemeral = true
[dns]
# 有的玩家网络环境很奇怪，就连纯用户态的 tsnet 都会被路由器上的 fakeip 配置污染，导致无法解析到正确结果。
# 因此干脆提供了一个 DoH 的保底机制
doh_servers = ["..."]
[[connect.sfcraft]]
protocol = "minecraft"
local_port=25566
dst_addr="sfcraft.mc.homelab.ice:25565"
lan_enable=true
lan_motd="SFCraft Vanilla | 原版生电Carpet 1.21.8"
[[connect.mcp2]]
protocol = "minecraft"
local_port=25579
dst_addr="mcp2.mc.homelab.ice:25560"
lan_enable=true
lan_motd="活动服务器 | Minecraft Party 2 (MCP2)"
[[connect.l4d2_udp]]
protocol = "udp"
local_port = 27015
dst_addr = "server.l4d2.homelab.ice:27015"
[[connect.l4d2_tcp]]
protocol = "tcp"
local_port = 27015
dst_addr = "server.l4d2.homelab.ice:27015"
简单的说，tslink 会通过一个 authKey 来验证身份并加入我的 tailnet, 加入后这个程序 自己 就可以直接访问 “内网IP”，并且不需要在用户的电脑上设置虚拟网卡，因为流量主要都是通过用户态网络栈 gVisor 从 L4 跟 L3 互相转换处理的。然后，它会在本地启动一些端口并把流量转向配置文件中设置的目的地，并且也实现了 Minecraft 的局域网广播协议，进一步降低了使用门槛。
Tailscale 的 Ephemeral 并不是完全免费的，只是有每个月几千分钟的额度，通常够用。另外，由于 authKey 外泄，一定要严格配置好 ACL 以免未经授权的访问！
只不过有的玩家网络情况仍然特殊，所以在后来我又为 TSLink 加入了 GUI 以及网络情况探测功能（Claude 的手笔，用 gioui 做的原生，没有用任何组件库），只不过不是很好看。截至行文时还没有被合并到主线，因为我太懒了:
到此，昂贵的国内公网中继 + best-effort P2P 的方法就确定下来了。如果玩家不在国内，他们也可以经过我的海外服务器回流回我家来玩 :3
P2P 的局限与赛博鸡蛋
tslink 在刚发明出来的那段时间效果好到令人难以置信：广州联通 到 深圳移动 这样典型的跨网延迟比经过广州腾讯云 BGP 中转还快。但是在大约今年（2026）五月份的时候发生了一件事，这件事使得 TSLink 的有效范围只剩下半个中国大陆，它就是省间结算涨价。
现在，TSLink 几乎只适合同省份或者就近的省份使用了。更糟糕的是，tsnet 在建立直连后基本上不愿意走公网 DERP Relay，而且 tailscale 基于 wireguard 协议本就容易被 QoS，雪上加霜。本来在这个时候，我原本的计划是调研 EasyTier 好利用他们的 QUIC/KCP 支持看看 P2P 情况会不会更好，但是引来了一个转机：
——偶然了解到某些江苏BGP单端口NAT不限上下行才六块钱一个月。
只不过这么好的事情也不是没有代价：只有一个端口，而且不能跑 tailscale。不过这根本难不倒我，我为此专门设计了一个程序来实现一端口多用的反向代理，工作原理如下：
flowchart LR
P["Player<br/>vanilla client"]
H["Hub (Java)<br/>public IP"]
C["Client (Go)<br/>behind NAT"]
MC["Real MC server<br/>localhost"]
P -->|"MC"| H
H ==>|"Worker Conn (mux)<br/>encrypted, pooled"| C
C -->|"MC"| MC
H -.->|"Control Session<br/>pattern registration + control requests"| C简单的说，这个程序会在一个端口上同时接受来自 MC 客户端 和 代理客户端 的连接：Minecraft 客户端连接服务器的时候会顺便发送他所用的服务器IP (Server Addresses)，通过利用这个性质，代理客户端可以向服务器注册一个 Pattern 匹配客户端发来的 IP。当匹配命中时，服务端会提醒代理客户端创建一个 Worker 流来把原先玩家的流量桥接到代理客户段，而代理客户端又会将桥过来的流量转发到 MC 服务器，完成流量闭环。(saltedfishclub/redapricot)
这个思路其实就比较像很常见的那种 HTTP VHost 分流，Velocity 以前也有类似的功能，现在不知道是我找不到了还是被删了。
由于 redapricot 的代码没有比较严格的人工监管，代码的质量会有问题，包括但不限于在连接长时间运行一段时间后可能会突然断开。对于某些服务器来说，这可能是不可接受的。
有了这么个好东西之后，只要随便配置 SRV Record 就可以让 MC 自动进入不同的服务器了，对吗？其实并非如此，仔细看 wiki 上的介绍可以发现：
Hostname or IP, e.g. localhost or 127.0.0.1, that was used to connect. The vanilla server does not use this information. This is the name obtained after SRV record resolution, except in 1.17 (and no older or newer version) and during server list ping (MC-278651), where it is the host portion of the address specified by the user directly. In 1.17.1 and later if a literal IP address is specified by the user, reverse DNS lookup is attempted, and the result is used as the value of this field if successful. (Java Edition protocol/Packets#Handshake)
结合具体的情况，这句话的意思可以被解读如下：
- 当 MC 在服务器列表中 Ping 服务器获取 MOTD 时，他发送的
Server Address字段为玩家在服务器列表里面编写的域名，即解析最外层 SRV 记录的域名。 - 而当玩家双击尝试连接时，客户端会使用经过 SRV 解析后的域名作为
Server Address。
也就是说，如果你想要 sfcraft.mc.sfclub.cc 能够被这个程序正确处理对应上具体的服务器，你需要两个域名：一个是 flatten.sfcraft.mc.sfclub.cc，本质上是那个服务器的域名的 ALIAS；另一个则是 sfcraft.mc.sfclub.cc，即你用来隐藏端口的 SRV 记录。而我有三个服务器，这就意味着我要创建六条记录。
不仅如此，考虑给 N 个海外玩家和国内部分地区备用的海外线路，M 个服务器，你需要创建 N * 2M 个域名，显然这维护起来很麻烦，我的手会断的。不过，还记得我们上文提到过的 DNSControl 吗？其实这就是 DNSControl 第二次大展身手的地方了，让我们用代码自动生成所有的记录！
var minecraftNames = [ // 其实不止三个呢
"party", "vanilla", "mayday", "newsteam", "drehmal", "fp"
]
var minecraftRelays = {
"jp": "jp-tyo-1.sfclub.cc:25565",
"hk": "cn-hkg-1.sfclub.cc:25565",
"": "some.china.servers.domain:11451",
"gd": "another.china.servers.domain:25565"
}
minecraftRelays = objectEntries(minecraftRelays).map(it => {
var hostport = it[1].split(":")
return [it[0], hostport[0], parseInt(hostport[1])]
})
mcRecords = []
mcRoot = "sfclub.cc."
for (var sIdx in minecraftNames) {
var server = minecraftNames[sIdx]
// 可能是因为 dnscontrol 用的 JS 引擎特别老的原因，objectEntries 得我自己写，但是这玩意好像还会把上面那个 array 对象的函数给导出来，代码凑合看。。。
if(typeof server === "function") continue
for (var index in minecraftRelays) {
var entry=minecraftRelays[index]
if (typeof entry != "object") continue;
var region = entry[0]
if (region != "") {
region += "."
}
var host = entry[1]
var port = entry[2]
if (port == 25565) {
mcRecords.push(ALIAS(region + server + ".mc", host + "."))
} else {
var aliased = "flatten." + region + server + ".mc"
mcRecords.push(ALIAS(aliased, host + "."))
mcRecords.push(SRV("_minecraft._tcp."+region+server+".mc", 10, 50, port, aliased+"."+mcRoot))
}
}
}
这样一来，我就可以非常轻松的添加新的或者旧的公网中继了，并且玩家还可以加个前缀来调整使用什么节点。
你可能听不懂，那么来举两个例子：
-
sfcraft.mc.sfclub.cc->flatten.sfcraft.mc.sfclub.ccand11451->ALIAS some.china.servers.domain,11451(解析 ALIAS 记录等价于直接解析被 ALIAS 的目标的 A 记录) -
jp.sfcraft.mc.sfclub.cc->flatten.jp.sfcraft.mc.sfclub.ccand25565->ALIAS jp-tyo-1.sfclub.cc,25565
不过因为一些原因，海外的线路我还懒得配置基于 Server Address 的分流规则，所以他们全部等价于连接到一个小游戏地图服务器里
接着是 redapricot 的配置：
{
"server": "",
"psk": "", // 实际上有简单的连接加密用于验证
"maxConn": 4, // 多路复用连接数量
"pingIntervalMs": 20000,
"mappings": [
{
"pattern": "(flatten\\.)?vanilla\\.mc\\.sfclub\\.cc",
"destination": "mc-sfcraft-1:25565",
"proxyProtocol": false
},
{
"pattern": "(flatten\\.)?mayday\\.mc\\.sfclub\\.cc",
"destination": "mc-mayday-1:25565",
"proxyProtocol": false
},
{
"pattern": "(flatten\\.)?party\\.mc\\.sfclub\\.cc",
"destination": "mc-mcp2-1:25560",
"proxyProtocol": false
}
]
}
proxyProtocol 启用的是 HAProxy PROXY v2 的协议头，主要是为了后面接 velocity 做准备（限制不多的公网服务器直接 HAProxy 转发回来更方便）。
这个方案对于我的 Minecraft 服务器来说非常管用，极大程度的降低了公网访问的成本，而且 Server List Ping 也可以正常显示。在大陆北方或者网络条件不佳的玩家可以使用我的江苏中继，而在南方或者 P2P 条件不错的玩家则可以使用 TSLink 来追求最低的延迟，非常好。
可观测性设施
关于 o11y 的内容其实能讲的并不多，主题上可能值得单独开一篇博客仔细讲一下，不过我比较懒（两年才更这篇呢！），所以打算在这里简单说一下就算了，不展开说。
大概今年年初的时候，我开了一个 Mod 服。而和很多 Mod 服一样，这个服到后期就一直在炸….
我平时自己的事情也比较多，不太可能一直盯着群里看，所以这个时候差不多就感觉需要一些基建来辅助我查看服务器的性能情况。
而我想到的第一个就是 Grafana.
Grafana
Grafana 是个开源的监控数据可视化面板。通过配合 Prometheus 和 Prometheus Exporter Mod, 我就可以自动记录服务器的性能数据情况，并且可能在图表中根据时间关系发掘出来引发 TPS 曲线下跌的规律。
（图片源自官网）
本着鸡蛋不在一个篮子里的原则，我的 Grafana 和 Prometheus 放在云服务器上。借助 Grafana, 也是比较顺利的发现了最近几次自动重启的主要原因无一例外是内存泄漏：
（骗你的，其实线程也漏了，但是我没截图了）
如果我想研究内存泄漏，我要知道服务器什么时候漏了然后上去看看（我这个时候还没折腾 Pyroscope，debug 主要靠自己上容器用命令行），那么 Grafana 怎么通过告警通知我呢？
sbmail
Grafana 其实可以直接配置 IMBot webhook。但是其实不光 Grafana，Gitea 和未来可能加入的服务也面临着同样的问题，比如说如果我想让 Gitea 加个人进来都得我自己去后台手动注册然后告诉他密码是什么，很麻烦。而且假如不用 SMTP，像 Grafana 告警之类的也都得让我每次去创建个 Bot 然后拿个 bot token 回来。这些接入 IM 平台的软件对于多用户来说很不方便，屁大点事都要拉个群，等等，总之想开个坑。如果自己做一个邮局，允许多用户注册再允许站内发信（其实也有站外支持）岂不美哉？
具体一点，我想要的功能如下：
- 我可以在这个邮局里创建许多子账号，每个账号都可以分别配置发送权限，而且有账号级别的密码。这是为了分发给不同的服务使用，且避免一个 Key 泄漏导致全部都得换的问题。
- 这个邮箱不仅我能注册，其他人也能注册。虽然他们注册了之后未必能往站外发信，但是可以收到站内 Bot 或者用户通过 SMTP / Telegram Bot 发送的信件。
- 有基本的垃圾邮件审查。
- 可以通过 MXRoute / Resend 的 API 发信，而不是要我自己养 IP
虽然市面上已经有很多开源软件声称自己做到了某些方面，但他们要么功能缺要么是玩具。寻觅一番无果后我打算自己做一个：
配合 Telegram Web App 还顺便做了 Webhook 管理和邮件查看的 UI：
图中是我用于接收各发行版 Security Announce 的 Webhook 邮箱，它会把邮件转发到我的 n8n workflow 上进行自动分类处理，最后通过我分配给 workflow 的 SMTP 凭据发回来一份分析报告。（还在调
我也顺便做了点 QoL，比如当这个 Bot 接收到附件时，也会自动上传 < 20M (BotAPI 限制) 的文件到对话中。后续我可能还会为这个邮箱加入 MCP 支持，这样就可以让 Agent 自由收发邮件了。未来有一天我会开源这个程序，现在你可以在 Telegram 上使用它（尽管没有可用性担保） (@anothermailbot)
我的沙盒工作站
有时候我会有一些脏活，比如跨多语言编译的项目，或者是测试某些软件等等，但我又不想在自己的电脑上做，所以我开发了一个 SSH 服务器。这个 SSH 服务器实现了每当我连接都会根据我的 SSH 用户名分配到对应的 Docker 容器中，从而起到进入沙盒的效果。这样，我就可以快速腾出一块干净的环境干活了！ (iceBear67/bubble)
这个沙盒对于我自己来说差不多够了，但是我自己用不能发挥出沙盒的最大价值。所以现在让我们来考虑多用户的情况：每个用户都拥有自己的容器，然而这些容器都共享系统的资源。如果尝试为每个容器（或者按用户）都设置一个硬资源限制，那么会导致沙盒空闲的资源不能被完全的利用，从而也限制了沙盒的作用。
但是如果直接让沙盒跟容器直接运行在我自己的系统上，恐怕安全性不佳，因为容器可能被逃逸。综合这两个问题，我打算搞一个虚拟机，然后再在上面运行 Docker 来托管这些沙盒，这样大家就加入了一个共享资源池，也能分层隔离威胁范围。但是因为 VM 配置起来比较复杂（以及懒惰）等原因一直没有动工。（实际上，近几个月不断涌出的高危 Linux LPE 也的确印证了这么做的必要性）
恰好在这个想法冒出来不久后，一个群友跟我介绍了 Firecracker, AWS Serverless 运行时的基础，从而了解到了 microVM 的概念。简单的说，microVM 与传统的虚拟机相比，有意的通过裁剪启动流程（抛弃 UEFI 固件，Direct Kernel Boot等）、精简驱动（只提供 virtio 驱动）、配合一个自定义的 init 来把启动虚拟机的时间压缩到极致，于是你不仅能享受到一般容器的启动时间，还能同时享受 KVM 虚拟化的安全性（microVM 最早应该是用在 Serverless 领域的，对冷启动时间有着非常高的要求）。
对于我的场景来说，其实启动速度并没有那么重要，不过在我读 Firecracker 那篇论文的时候我想到一个问题：既然 microVM 启动这么快，我不是可以把它打包成 OCI 镜像跑吗再来跑沙盒环境？其实的确有这样的方案，那就是 Kata Containers. 只可惜我感觉 Kata Containers 配置起来比较麻烦，不像是适合我用的。
然后我又想：microVM，容器，沙盒，可复现构建，！？Dockerfile？！
顺着这个思路走，我打算秉着当初装机时抛弃 PVE 的精神设计一套对于我没有黑箱的方案，并且还要可复现，想法如下：
- 整个系统的初始状态被 Dockerfile 构建出来。
- 好在，关于 “构建一个系统” 这块的工具已经很多了，而我选择的是 Alpine 的
alpine-make-vm-image。这个脚本接受一个 image overlay（相当于模板）然后它会 chroot 这个 overlay 来运行一些安装脚本，最后导出成一个完整的 VM 镜像。
- 好在，关于 “构建一个系统” 这块的工具已经很多了，而我选择的是 Alpine 的
- 虚拟机的 Hypervisor 我选择了 cloud-hypervisor，典型的搞 microVM 的 hv。只不过配置起来挺坑人的，主要还是某种出于对 rust 内存安全的执念比较多
- 我希望这个 VM 可以自己 DHCP 一下从路由器拿 IP，因为我不想再要一层 NAT 了。而且这样做可以让被主路由器的 subnet router 直接访问，不需要再额外配置。
本来到这里就差不多了，但是近几个月真的冒出来非常多 Linux LPE，因此也冒出了裁剪内核的想法。出于提升启动速度和安全性的考究，我最后选择了在 VM 内使用 Alpine 针对虚拟化场景裁剪的 linux-virt 内核。（只不过连 io_uring 都被裁剪掉了；倒是后来发现因为没 AF_RXRPC 确实成功阻断 Dirty Frag 的一条利用链）
大致确定了技术路线之后就开工了，其实 VM 的启动速度还是很理想的：
一秒内就进入 userspace 了，不过这还不是最快的，我觉得如果要更快一点应该可以想办法去掉 initrd，然后再裁一下内核或者调整一下文件系统, 不过我懒得试了。现在的启动速度还是很理想的，瓶颈主要在 Alpine Init 加载的各种东西上，但一分钟以内也足够初始化完所有的服务。
那么现在就来回顾一下，我都经历了什么。
用 Dockerfile 来构建 VM
其实这个做法很简单：先用 Dockerfile 跑 alpine-make-vm-image 把 VM 的镜像构建出来，再构建一个用 cloud-hypervisor 的镜像包含 VM disk 就够了。这样你就可以带着整个 hypervisor 把你的虚拟机发布出去，配合 watchtower 还可以自动更新。不过我后来发现这个做法有点浪费地方，于是改成了写个 Makefile 先各自构建, 最后通过 Docker 的 Bind mount 来把磁盘镜像挂载进去运行。
只不过，光这个坑就不少… 我记得刚开始做这个方案那几天我踩了好多坑：
alpine-make-vm-image需要一个有特权的 builder.
因为这个脚本（下面简称 a.m.v.i ）操作 VM 磁盘镜像的主要方式还是通过 qemu-nbd 那一套工具，而这玩意在非特权的容器里无法正常使用。我折腾了很多办法基本上都败下阵来——无一例外要特权。
那怎么办呢，投降了。。给 builder 开了特权。
vm: confirm secrets builder
@echo "BUILDING VM DISK IMAGE"
docker build \
--builder bearcloud \
--allow security.insecure \
-f vm.Dockerfile \
--build-context host-modules=/lib/modules \
--target export \
--output type=local,dest=./data \
$(VM_OPTS) .
- 构建脚本没写好，cloud-hypervisor 没法把系统镜像拉起来
调试了半天发现镜像里面 TMD 是空的，因为 a.m.v.i fail 之后我的容器构建进程没有及时中断导致出现了一个静默损坏的 vm 磁盘镜像，爆。
- cloud-hypervisor 没
CAP_SYS_ADMIN不干活
为啥一个 HV 要这个 CAP 呢？？后来调查半天发现一个很奇怪的事情，cloud-hypervisor 在容器内给自己上 seccomp 的时候不知道怎么回事导致 clone3() 直接炸 ENOSYS 了，然而容器本身的 Seccomp 也没有禁止用 clone3()。最后的解决方法还是给了 CAP_SYS_ADMIN, 因为 cloud-hypervisor 自己会 drop privilege。另一个解法可能是让他自己 --seccomp false, 不过我觉得这更危险，因为显然只有 cloud-hypervisor 自己最清楚自己要 drop 哪些，保留哪些特权。
qemu-nbd突然又罢工了
提示找不到 nbd 对应的内核模块。调试半天发现是自己刚刚滚了包, 导致正在运行的内核版本略低，而 /lib/modules/(一串包含版本的目录名) 下的模块是为了新内核准备的。
- 导出的
vm.raw无论怎么调试都是 128M
不知道哪里来的缓存可把我害惨了，128M导致安装的时候一直爆炸，忘了怎么修的了。
- musl 的 Happy Eyeball 算法对我的错误 sing-box 配置零容忍
Happy Eyeballs（快乐眼球），亦被称作 Fast Fallback（快速回退），是一个由 IETF 发布的算法。支持该算法的程序会尝试同时使用 IPv4 和 IPv6 协议进行连接，若两者皆可连通则首选 IPv6，使得同时支持 IPv4 和 IPv6 的双栈应用程序对用户的响应更加灵敏，从而最大限度地减少 IPv6 连接或设置不完善的用户遇到的常见问题。 “快乐眼球”一词源自行内术语“眼球”，用于描述互联网上那些代表人类用户（而不是服务器）的端点。
由于许多互联网用户尚无法访问 IPv6 互联网，当这些用户的应用程序尝试访问 IPv6 网络时，这些应用程序会进入无响应状态，从而影响用户体验。Happy Eyeballs 以并行的方式尝试使用两种协议发起连接，来判断使用哪种协议更为合适，而并行的运用意味着该判断过程的延迟和普通连接几乎一致，因而解决了这个问题。使用的地址通常是通过循环算法从 DNS 中选择的。 (Wikipedia)
我因为嫌弃 IPv6 代理的各种问题索性对所有的 AAAA 记录都返回了 NXDOMAIN，结果 glibc 能工作 musl 不工作。当时只觉得奇怪，而答案是我在很久之后才注意到的：如果域名没有 AAAA 记录应该返回 NOERROR 而！不！是！NXDOMAIN！！！
真没想到 glibc, msvc 还有没念到名字的dns实现默默吃下了这么多，musl 真是不吃苦仙人
- 被 ChatGPT 的幻觉坑了
我的 VM 的数据盘是单独挂载的，而我不是很熟悉 Alpine 用 fstab 是否要启用什么服务，于是我就问 ChatGPT，他说有一个叫 mount 的服务。
Alpine 加载 fstab 不需要一个叫 mount 的服务，操。
udhcpc: socket(AF_PACKET,2,8): Address family not supported by protocol
这是来自 Guest VM 启动时的报错。最后排查出来是因为我用 Hypervisor 的内核来启动 Guest, 然而这两个版本不同步导致应用程序加载内核模块的时候就出问题了。
之所以这么设计是想要更新 Hypervisor 就做到更换 Guest 内核的效果，现在看来泡汤了，下次再说吧。
- 我的 Daemon 写的比较蠢
虽然我的服务要联网，但无论是 systemd 还是 openrc 都没有提供一个保证自己已经联网的 target/service（虽然也能理解…）。虽然 alpine 上有一个叫 network 的服务，但是它启动也只是把 udhcpc 当作后台进程运行，所以你也不能依赖于 network，因为你不知道 udhcpc 到底好了没。
而且更无语的是如果你在 prestart 钩子里面写等待网络会卡住整个 init 流程甚至都没有任何 log…所以我的解决方案也就只有用 supervise-daemon 反复重启那些因为无法联网崩溃的服务，然后期望 DHCP 早日抵达 ;w;
其实可能可以在 network target 之后用 ping loop wait 一下？写到这里才想起来，我是🐖
- 观测性不好
本来尝试用 Alloy 采集数据上传到 Loki，结果发现装了 Allay 之后 512M 的 rootfs 一直在炸。
为什么呢，因为 Alloy 的二进制文件足足有他妈的 400MB+。
在解决各种坑之后，我的 VM 总算是能跑起来了！而且用这个办法有一个额外的好处就是 VM 的修改也可以做到可回滚，且新构建出来的 VM 几乎总是具有最新的软件包。
只不过但是距离完成还差一些距离。
沙盒的基础镜像托管在哪
如果你认真的读完了上文，你应该知道我有一个叫 bubble 的软件能够自动为 SSH 连接分配沙盒。但是沙盒需要一个基础镜像，从哪来呢？或者说，我应该把构建出来的沙盒镜像推到 GitHub 还是我建个什么 Image Registry 再推过去。
我选择了后者。其实我也不想建一个 Harbor 或者别的什么，但是我偶然注意到 Gitea 还在发力：
Starting with Gitea 1.17, the Package Registry can be used as a public or private registry for common package managers. (Gitea)
也就是说 Gitea 自身就可以作为一个 Image Registry，那不是巧了吗！所以我干脆在家里云里配置了 CI，然后发布到 Gitea Packages 上：
name: Build and Publish Docker Image
on: [push]
jobs:
build:
runs-on: ubuntu-latest
steps:
- name: Login to Gitea Registry
uses: docker/login-action@v4
with:
registry: git.sfclub.cc
username: ${{ secrets.REGISTRY_USER }}
password: ${{ secrets.REGISTRY_TOKEN}}
- name: Setup buildx
uses: docker/setup-buildx-action@v4
- name: Build and push
uses: docker/build-push-action@v7
with:
push: true
tags: ${{ vars.REGISTRY }}/cloud/workspace-image:latest
不用类似 Job Token 的东西主要是没跑通，懒得折腾就直接把自己账号写 secrets 里了。不要学
得助于 Split DNS，我的 VM 可以直接走内网拷这个镜像过去，比走公网快很多。（其实我怀疑可能是本地回环，因为 VM 的网关设置的就是 Host 自己，不知道会不会抄捷径）
Bubble 如何鉴权？
如果我要提供给多个用户使用我的沙盒，我的程序要怎么检查他们的身份（公钥，我讨厌密码登录）？首先这些公钥不会在构建的时候才被包含，因为我不希望天天重启或者构建 VM；其次我也不想重新写一个什么控制面来管理这些 Identity，那太囊肿了。
我后来发现了一个很好的做法：Gitea！什么东西能够处理用户注册，用户登录，上传 SSH 公钥呢？那当然就是它。所以，我在 bubble 的基础上加之改造扩展了一个 auth-server 协议：当有用户尝试登录的时候就把公钥拿去某个 HTTP API 鉴权来看是不是本人。之后，我又写了一个 gitea-auth 跟 bubble 一起运行在 VM 中，他会负责爬取我 Gitea 上某个组织的某个 team 里的所有人的公钥，认识公钥则返回对应的用户信息来放行。
这样，用户就只需要 注册 -> 上传 -> 进组织 就可以用我的沙盒了。
沙盒如何科学上网？
我选择让宿主本身来当旁网关。因为 sing-box 在启用 tun 的情况下也会自动处理 IP 转发的流量，再经过 Grafana Loki 的加持就可以很自然的导出一个审计日志了。
其实也可以直接给 VM 本身配置一个 sing-box, 但是我觉得必要性并不大。
在这一切完成后，我的沙盒已经可以工作了。意外的是，虽然这个沙盒原先是设计给人类使用的，但是反而在 Agent 的加持下这个沙盒更好用了。举几个例子：
- 沙盒里配置了不需要密码的 sudo 权限，Agent 可以根据需要直接调用 sudo 安装软件包达成目标。（我们平时都是直接
--dangerously-skip-permissions，非常快）。 - 沙盒被 Docker LXC(有一套严格的 seccomp 规则)+KVM 双重保护，而且配置了严格的防火墙，即使沙盒被 Agent 不小心运行的恶意软件入侵损失也能降到最低。
- 由于沙盒的资源常常闲置，用户之间靠 fair-share 就可以确保沙盒计算资源的充分利用，不会有浪费或者哪个容器没得吃的情况。
- 沙盒用完了就直接销毁，再也不用担心 agent 配环境在本地拉一坨大的。
- …网络环境更稳定，之类的。
也正是在这个沙盒里我让 Claude 孵化出了很多新项目。它可以 24 小时执行他的 Goal 而不用担心被中转站投毒造成我电脑上的意外损失之类的问题，而且也不用担心我笔记本网络不稳定之类的情况。也是因为如此，我有时候晚上睡觉之前都会先给他安排一个任务，早上起来就可以收菜了。
沙盒 VM 的所有代码托管在我的 Gitea 上：https://git.sfclub.cc/icybear/bearnet
遗憾
如果你去看了我的 bearnet 仓库，不难注意到一个事实：secrets 和参数是构建过程中硬编码进 VM 实现的。总的来说，需要一个我懒得写的控制面。
不过，针对这个问题，我已经想到了一个更好的解决办法，但这个解决办法姑且需要先卖个关子，在下篇你会见到它 :3
End
这篇博客真的是我有史以来写过最长的，花的时间（无论是写文章还是我在文章里做的事情）最长的。我很早以前就想写了，但是我的想法越来越多，做的东西也越来越多，以至于文章也在不断往后拖。直到我的暑假的尾声，被焦虑折磨的我总算放下了点东西，才下定决心把这篇文章写了出来。
我觉得我的家里云其实有很多可以改进的地方，也就是我所说的 “重构”。我想重构这个 VM 框架让他处于一个更优雅，更完美的状态；我想写个 Tailscale 交换机来做到让我的朋友也能享受到 tsdns 的快乐（目前为止 tailscale 不能跨网络分享 Subnet Router）；针对 Agent 沙盒的工作流，我还有一个巨大的野心…不过这些，都要等到下次再说了。
由于我肝不动了的原因，这篇文章可能有一些写的不太好的地方，而且有一些角色（比如我的云服务器们）被一笔带过了。不过总的来说这毕竟还是 Homelab 的文章，所以也是尽可能的聚焦在 Homelab 以及他的网络设施上。如果你对文章里的一些细节感兴趣，也欢迎在评论区里提问，直接问我也可以。
希望你坚持读完这篇文章之后可以激起你折腾 Homelab 的兴趣。无论如何，感谢你的观看！
iceBear67, aka 艾斯贝尔.
2026/08/12. 完稿于 2026/08/15 01:47