一名自托管爱好者近日公开了他的个人网站方案：zero.btxx.org 运行在一台 Raspberry Pi Zero v1.3 上，系统采用 Alpine Linux 的 diskless 模式，根文件系统挂载在 tmpfs/ramfs 中，网页由 darkhttpd 或 nginx 提供服务，公网访问和 TLS 则交给外部低配 VPS、socat 与 HAProxy/边缘服务转发处理。

这不是一篇“用 512MB 内存打败云厂商”的故事。更准确的判断是：对低流量静态网站，这种极简自托管可行；对动态业务、高并发访问或低运维容忍度场景，它并不合适。它真正展示的是资源约束下的工程取舍，而不是廉价硬件的奇迹。

Pi Zero 跑网站，关键在把任务切得足够小

Raspberry Pi Zero v1.3 是这套方案的硬件核心，只有 512MB 内存。作者称 Alpine Linux 本身大约占用 40MB，剩下资源足以承载一个小型静态站点。网站服务可选 nginx，但作者更偏向 darkhttpd，因为它更轻，功能也更少，正适合只返回静态文件的场景。

这里的边界很重要。Pi Zero 负责的是“把 HTML、CSS、图片文件吐出去”，不是跑数据库、应用框架、评论系统或后端 API。和常见的 DigitalOcean、Hetzner、Linode 低配 VPS 相比，它省下的是云主机月费，换来的是家庭网络、供电、备份和安全配置的长期维护。

路线适合内容主要收益主要代价
Pi Zero + Alpine diskless小流量静态站成本低、可控性强、能学习系统细节家宽、端口、备份都要自己管
普通低配 VPS静态站、小型服务公网 IP、TLS、稳定性更省心持续付费，平台依赖更高
GitHub Pages / Cloudflare Pages纯静态发布几乎免运维，全球 CDN控制权较少，不是本地自托管

对自托管玩家和想用低成本设备练手的开发者，这类方案有现实意义。它能让人重新理解 Web 服务的最小形态：一个稳定供电的小板子、一个 HTTP 服务、一个转发入口，再加一套可恢复的备份。

“运行在内存中”不等于不需要 microSD

这套方案最容易被误读的地方，是“diskless”。它不是整台机器完全脱离存储介质。Pi Zero 仍然需要 microSD 用于启动、保存配置和 APK 缓存；只是系统启动后，根文件系统主要跑在 RAM 中。

Alpine Linux 的 lbu 是这里的关键工具。安装软件、修改配置、更新网站文件后，都要通过 lbu commit 把变化持久化到 microSD，否则重启或断电后就会丢失。作者还建议使用小容量 microSD，比如 512MB 级别卡片，原因不是性能，而是做镜像备份时体积更小。

这种设计有一个朴素好处：减少日常写卡，降低存储磨损，也让系统状态更容易回滚。代价也很直接：运维习惯必须改变。对习惯了普通 Linux 服务器的人来说，“改完配置还要提交一次”很容易漏掉。

备份方式同样偏手工。作者使用 dd 克隆整张 microSD，得到字节级镜像；换卡时写回镜像即可恢复。这对个人站点够用，但不等于企业级容灾。卡坏、配置漏提交、家庭断网，都会让站点不可用。

TLS 和公网入口外包后，复杂度只是换了位置

作者没有让 Pi Zero 直接处理 TLS，而是把 HTTPS 终止放到外部 VPS 或边缘 HAProxy 服务上。原文中使用的是 TierHive，一台低配 VPS 参数为 Alpine Linux、128MB RAM、1GB NVMe 存储、1 vCPU，价格约 4 美元/年；也可以换成其他 VPS 或类似 Cloudflare 的服务。

链路大致是：用户访问域名，流量先到 HAProxy/边缘服务完成 TLS，再到 VPS，经 socat 转发到家庭网络端口，最后落到 Pi Zero。这样做减轻了 Pi Zero 的负担，也绕开了家用设备直接暴露 HTTPS 的复杂配置。

但这条链路增加了新的故障点。家宽动态 IP 需要 DDNS；路由器要做端口转发；公网入口、VPS、HAProxy、家庭网络任一环节出问题，网站都会受影响。安全性也不能被夸大，开放端口、SSH、转发规则和证书托管，都需要基本的运维纪律。

接下来最该观察的不是它能不能承受“很多访问”，而是三个变量：实际访问量上升后 Pi Zero 和家庭上行带宽是否稳定；外部 VPS 或边缘服务是否可靠续费和续证；维护者能否长期坚持备份、更新和端口安全检查。对个人微站，这是一门好手艺；对严肃业务，它仍是旁门而非正道。