家庭数据中心架构总览：VPS、PVE、NAS 三方分工

摘要

一句话说清这套家庭数据中心的分工：Muse 是大脑，VPS 是咽喉，PVE 是手脚。大脑只做规划和验收，不碰生产数据；咽喉只负责传话和中转，不干重活；手脚在家里，算力和存储都在本地。本文把三方的职责边界、设备清单、三条刻意的设计取舍、典型办公任务的数据流，以及"脑手分离、数据不离家、每活必留痕、安全红线"四项架构原则一次讲透。这是整个系列的总纲，后面讲隧道、VPN、Docker 的文章，都是这张总览图的局部放大。

目录

• 引言：为什么先画一张总览图
• 三方分工：大脑、咽喉、手脚
• 三条刻意的设计取舍
• 设备清单：一张表看全家底
• 典型数据流：一个办公任务走完全程
• 四项架构原则
• 踩坑与注意事项
• 总结

引言：为什么先画一张总览图

折腾 homelab 的人，家里设备一多，最容易犯的毛病就是"哪台机器干了什么，全凭记忆"。今天在 VPS 上装了个脚本，明天在 PVE 里起了个容器，三个月后自己都忘了流量是怎么走的。排查问题的时候，先花半小时回忆架构，再花十分钟修 bug。

所以这套家庭数据中心在动手之前，先定了一份《系统架构-三方分工说明.md》，常驻在 NAS 的"自动化办公"共享根目录，归档副本也在 archive/运维/2026-10-01_架构分工说明/。所有参与者（我、VPS、PVE）都按这份文档分工，职责写死，边界清晰。后面你会看到，这份文档不是摆设：办公任务走 office-relay.sh 中转、隧道走"一机一 client"、管理面板收进 WireGuard，每一项落地都能在这张图里找到位置。

三方分工：大脑、咽喉、手脚

这个模型解决的核心矛盾是：VPS 在公网、算力弱（1 核、约 1 GiB 内存），家里机器算力强但没有公网 IP。让 VPS 干重活，它扛不住；让家里机器直连公网，既没条件也不安全。于是 VPS 只做它擅长的事：当隧道中枢、当文件中转站、当脚本分发点。真正的计算（Word/PPT 处理、PDF 转换、Docker 跑应用）和真正的存储（NAS 磁盘阵列）全部在家里。

大脑的定位也值得说一句：Muse 不直接登录生产机器敲命令，而是通过 VPS 下发指令、收集结果、做验收。每一批操作都有日志可查，账记得清楚，出了问题能回溯。这就是"记账"二字的含义。

三条刻意的设计取舍

分工表看着简单，但每一行背后都是否决过其他方案的。把三个最关键的取舍摊开说：

取舍一：VPS 不干重活。 VPS 是 1 核、约 955 MiB 内存的小机器，远在法兰克福。Word 文档解析、PDF 渲染这种活一旦扔上去，内存分分钟见底，还会影响隧道和网站的稳定性。所以它的工作被严格限定为三类：传话（nps 隧道中枢）、搬运（office-relay.sh 中转文件）、分发（npc.sh、gl、加固脚本经 028000.xyz 对外提供下载）。重活全部下沉到家里：VM1002（4 核 4G）做文档处理，CT702 跑 Docker 应用，NAS 做存储。算力跟着数据走，而不是让数据去追算力。

取舍二：PVE 永不直连公网。 家里是运营商 NAT，没有公网 IP，这是客观限制；但即使有，也不会让 PVE 直接暴露。所有进出都走 nps 隧道：SSH 走 22221 系列端口，Web 管理走 28xxx 段，连黑群晖 DSM 的 HTTPS 都是经隧道中转。管理面（宝塔、nps 后台、s-ui、phpMyAdmin）还被进一步收进 WireGuard VPN，公网连握手都建不上。多一层转发就多一点延迟，但换来的是攻击面收敛到几乎为零。这笔账，安全党都算得清。

取舍三：大脑不碰生产数据。 这是给 AI 助手自己画的红线：Muse 只负责想清楚"做什么、怎么做"，下指令、做验收、写日志，但不直接登录生产机器改数据，不替用户做敏感决策（比如删库、改密码策略）。动生产环境（重启宿主机、改内存、收防火墙）必须先提案、用户点头后再执行，一次性授权只对应当次有效。听起来有点"见外"，但长期看这是信任的基础：每一步都有记录、有回滚、有据可查。

设备清单：一张表看全家底

先看 VPS（一台位于德国法兰克福的 Debian 13 小机器，1 核、约 1 GiB 内存）：

VPS 上跑的服务可以再细一点，因为"咽喉"这个词太抽象了：

再看家里（PVE 宿主机，8 线程、约 15.6 GiB 内存，内网 192.168.0.133）：

停机的是 VM101（win10）、VM105（macOS-BigSur）、VM1001（Debian13），都是用户故意关机，onboot 设为 0，保持不动。CT500（gdrive5t）和 CT703（office-worker，前代办公容器）已经删除，前者有备份留档，后者被 VM1002 取代。

注意一个细节：这张表里的"对外域名"只有 5 个（blog/file/pwd/img/nav 几个子域），而且这是刻意收敛的结果。后面会讲到，用户定了一条规则：新增应用默认纯内网，不配域名、不做外网，除非明确说明需要。

典型数据流：一个办公任务走完全程

理论讲完，看一个真实跑通的例子：用户发来一份 Word 文档，要求把里面的金额从 10,000 改成 12,800，并更新审批状态。这个任务的数据流是这样的：

用户（发文件 + 提需求）
  ↓
VPS（咽喉）：office-relay.sh v2 中转
  · push  把文件推入 NAS inbox/
  · exec  经 22223 隧道直连 VM1002，下发处理指令
  ↓
VM1002（手脚）：文档处理
  · python-docx 改金额、更新审批段落
  · 成品写入 NAS out/
  ↓
NAS（手脚）：/mnt/nas/自动化办公 落盘
  · inbox/ → out/ → logs/（任务日志）→ archive/（按"日期_任务名"归档）
  ↓
VPS：pull 取回成品 → 回传给用户

office-relay.sh 的五个子命令就是这套流程的全部动作：

# 推送文件到 NAS 收件箱
/root/pve-mgmt/office-relay.sh push 合同.docx inbox/

# 在 VM1002 上执行处理命令（经 22223 隧道直连）
/root/pve-mgmt/office-relay.sh exec "python3 /mnt/nas/自动化办公/scripts/fix_amount.py"

# 取回成品
/root/pve-mgmt/office-relay.sh pull out/合同_已处理.docx ./

# 查看目录、记录日志（-c 指定分类：办公/运维）
/root/pve-mgmt/office-relay.sh ls out/
/root/pve-mgmt/office-relay.sh log -c 办公 "金额已更新，审批段落已追加"

看明白这个流程，就看明白了"咽喉"的含义：VPS 全程只做搬运和传话，Word 文件的解析、修改、生成都在家里的 VM1002 里完成，原始文件和成品最终都落在 NAS 上。VPS 的磁盘里不留业务数据。

NAS 上的工作区结构是固定的，所有任务都走同一套目录：

/mnt/nas/自动化办公/
├── inbox/        # 收件箱：用户发来的原始文件
├── out/          # 成品输出：处理好的文件
├── logs/         # 任务日志：logs/办公/ 与 logs/运维/{虚机,网络,存储,系统}/
├── scripts/      # 处理脚本
├── templates/    # 文档模板
├── archive/      # 归档：交付后按"日期_任务名"存放
└── 系统架构-三方分工说明.md   # 本系列总纲文档，常驻于此

四项架构原则

文档里写了四条原则，每一条都是用坑换来的：

1. 脑手分离。 规划和执行分开。大脑（Muse）负责想清楚"做什么、怎么做"，手脚（PVE）负责执行，咽喉（VPS）负责传话。任何一方都不越界：VPS 不直接处理业务数据，PVE 不直接暴露公网，Muse 不跳过用户做敏感决策。动生产环境（重启宿主机、改内存、收防火墙）必须先提案、用户点头后再执行，一次性授权只对应当次有效。

2. 数据不离家。 原始数据和成品只在家里落地：NAS 的磁盘、VM1002 的处理目录。VPS 只是中转站，文件过一下就走，不做持久化。这条原则直接决定了 office-relay.sh 的设计：push 进 inbox、处理完 pull 走，VPS 本地不留档。

3. 每活必留痕。 每个任务都要写日志。办公任务记到 logs/办公/，运维操作记到 logs/运维/ 下对应的子分类（虚机/网络/存储/系统）。交付完成后，用归档脚本按"日期_任务名"收进 archive/。好处很实在：三个月后想查"上次改 Word 模板用的是哪个脚本"，翻日志就行，不用凭记忆。

4. 安全红线。 这是用户亲口定的最高优先级：任何 NAS 文件管理方案必须安全，不能把文件暴露给别人。落实到具体做法：管理面板（宝塔、nps、s-ui、phpMyAdmin）全部收进 WireGuard VPN，公网连不上；文件管理站点不暴露软件指纹；VPN、密钥、证书、Token 这类敏感配置统一归档到 NAS 上独立的"私密配置"共享文件夹，不挂载到任何对外文件服务。

踩坑与注意事项

• 退出码为 0 不代表成功。 pct push/pull 即使失败也可能返回 0，office-relay.sh 在 v2 里改成了操作后检查目标文件是否存在。验收一切以"事后验货"为准，这是这套架构里反复出现的教训。
• 反代验收不能只看状态码。 曾经出现过 nginx 反代到 caddy 时返回 200 空包的情况（Host 头没改对，caddy 静默回空），从此验收反代必须看 body 大小和内容。这个教训已经写进操作手册。
• DSM 的登录接口有保护机制。 短时间内反复调用 auth.cgi 会被限流（表现为超时或空响应），需要冷却约 15 分钟。正确做法是登录一次拿到 sid 后复用到底。
• qemu-guest-agent 可能会卡死。 VM1002 上遇到过：虚机内服务是 active 的，但宿主机侧通道不通。办公中转走的是直连 SSH（经 22223 隧道），不受这个影响，所以业务没断。排查时记住区分"通道层"和"服务层"。
• PVE 重启后，容器可能比 NAS 先起来。 遇到过一次：CT700/CT701 的开机 pre-start hook 失败，因为它们的 bind mount 依赖宿主机上的 NAS 路径，而当时 VM100（黑群晖）还没就绪，挂载点报 No such device。解决办法是等 NAS 可访问后，用 ls 触发 autofs 挂载，再手动 pct start 拉起容器。这个坑已经记进 NAS"私密配置"下的踩坑记录。给虚机/容器设 onboot 时，顺手想一想启动顺序依赖，能省一次半夜爬起来修机器。
• 内存是当前的主要瓶颈。 PVE 宿主机约 15.6 GiB 内存，优化前一度只剩约 1.3 GiB 可用；VPS 约 1 GiB 内存，可用也只有几百 MB。后来做了一轮内存优化（VM1002 从 8G 降到 4G、win10 从 12G 降到 8G、OpenWrt 从 1G 降到 512M），宿主机已用从 14.2G 降到 10.6G，可用回到约 5.3G。加新应用之前，先看内存余量，这是用户的一个好习惯：上新东西之前先盘存储和资源的底子。

总结

这套架构的精髓就三句话：大脑想清楚再动手，咽喉只传话不干活，手脚和数据都放在家里。四项原则（脑手分离、数据不离家、每活必留痕、安全红线）是所有后续决策的标尺：隧道体系要不要"一机一 client"，看它是否符合"每活必留痕"；管理面板要不要收进 VPN，看"安全红线"；新应用要不要给公网域名，看"数据不离家"和最小暴露。

相关阅读：《nps 内网穿透实战：一机一 Client 的隧道管理体系》、《WireGuard 组网实战：把管理面板藏进 VPN》、《PVE 里跑 Docker：LXC 容器 CT702 实战》