我的 HomeLab 配置（一）：基础设施篇
内容提要
作者曾因维护成本高而放弃自建HomeLab，但发现AI让部署运维变得简单，于是全面复活。他使用Tailscale和自建Headscale实现设备互联，在PVE上运行多个VM，通过AdGuard Home管理DNS，用Caddy提供HTTPS，并设置统一代理。所有配置开源，强调AI辅助的“Vibe Deploying”方式，让复杂操作变得轻松。
延伸解读
AI 如何改变 HomeLab 运维
作者曾因维护成本高而放弃自建，但 AI 让部署和运维变得简单，甚至称这是“HomeLab 玩家最好的时代”。他通过 AI 辅助完成配置，无需手写代码，体现了 AI 在降低技术门槛方面的潜力。但这也意味着对 AI 的依赖，读者需注意 AI 生成配置的准确性和安全性，仍需基本的技术判断力。
Tailscale 与 Headscale 的选型考量
作者选择 Tailscale 和自建 Headscale，是因为官方节点在境内使用不便，自建可优化连接和 DERP 中继。通过 OIDC 集成账号系统，简化设备接入。这提示读者，在类似场景下，自建控制服务器可提升体验，但需考虑维护成本和安全性，且 OIDC 配置需谨慎管理权限。
内网 DNS 与证书方案的风险
作者选择 AdGuard Home 作为唯一 DNS，管理所有查询，以保留控制权，但承认存在单点故障和 relay 延迟风险。同时，使用自签证书和 Caddy 作为 ACME server 实现 HTTPS，但需在所有客户端安装信任根证书。读者应权衡控制与可用性，并注意证书信任带来的安全风险。
统一代理与透明代理的实践
作者通过 Proxy VM 运行 Mihomo，提供统一代理，并配置透明代理，使 Tailscale 流量经 Mihomo 分流，实现 iOS 设备无感代理。这简化了多设备代理配置，但依赖 exit node 和网络稳定性，且透明代理可能影响所有流量，需确保规则正确，避免隐私泄露。
Q&A
作者为什么重新开始自建HomeLab？
作者之前因为维护成本高而放弃自建HomeLab，但后来发现AI让部署和运维变得简单，只需几句话就能实现想要的功能，因此全面复活了HomeLab。
作者如何实现设备之间的互联？
作者使用Tailscale和自建的Headscale实现设备互联，所有设备24小时在同一个Tailscale网络中，通过Headscale的OIDC配置，新设备只需指定vpn.skywt.cn并登录skywt.net账号即可加入网络。
作者为什么选择自建Headscale而不是直接用Tailscale官方服务？
因为Tailscale官方节点在境内使用不方便，自建Headscale在国内主机上体验更好，且Headscale内置DERP服务器，在无法打洞时中转流量，自建比用境外DERP体验好。
作者在PVE上划分了哪些虚拟机？分别有什么用途？
作者在PVE上划分了四个VM：Lab（Debian，纯容器化，用Docker跑各种服务，是HomeLab主要部分）、Dev（Debian，开发空间，用PM2管理dev server）、Nas（OpenMediaVault，直通2T移动硬盘，通过NFS和Samba共享）、Proxy（Debian，统一网络代理基础设施）。
作者如何实现内网域名访问？
作者使用自定义TLD .skywt，在Lab上运行AdGuard Home作为DNS服务器，配置*.lab.skywt解析到Lab，*.dev.skywt解析到Dev等，并通过Headscale下发DNS配置，使Tailscale网络内的设备自动使用该DNS。
作者如何为内网服务提供HTTPS？
作者使用Caddy作为反向代理，并利用Caddy的自签证书功能，从Lab上的Caddy导出根证书，在所有客户端安装信任。对于Dev上的服务，通过Lab的Caddy作为ACME server为Dev签发证书，实现统一根证书。
作者如何实现统一的网络代理？
作者专门开了一个Proxy VM，运行Mihomo，配置路由分流规则，每五分钟benchmark机场节点并择优，暴露HTTP/SOCKS代理端口10810。同时配置透明代理，让Tailscale进入Proxy的流量通过Mihomo分流出口，这样任何设备将Proxy设为exit node即可无感使用代理。
作者为什么选择AdGuard Home作为DNS服务器？
作者选择AdGuard Home作为DNS服务器，因为它可以管理所有DNS查询，提供统计分析、隐私保护、对抗DNS污染、广告屏蔽等功能，并且能通过Headscale下发配置，实现统一管理。
