SolarHost
NAME
SolarHost - 用太阳能供电的小型自托管服务器实验
SYNOPSIS
SolarHost 不是零成本服务器。
它也不是永续承诺。
它是一组约束：
- 低功耗主机
- 可计算的储能
- 合法且可维护的部署位置
- 可备份的论坛软件
- 不暴露入站端口的网络入口
目标不是摆脱一切依赖。
目标是看清依赖，并把它们压到可以理解的范围内。
DESCRIPTION
原设想是用一套太阳能系统驱动小型服务器，托管一个在线技术社区。
这个想法仍然成立。
但它不能从口号开始。
它应该从负载、电力、网络和维护开始。
所谓“1000 人社区”不是一个工程指标。
它可能表示 1000 个注册用户，也可能表示 1000 个日活用户，甚至表示 1000 个同时在线用户。
这些完全不同。
如果只是小规模文字讨论，低功耗主机可以胜任。
如果有大量图片、搜索、邮件通知、插件、备份和高并发，问题就不再只是 CPU 和内存。
它会变成数据库、存储、带宽、备份和恢复的问题。
LOAD
先定义负载，再谈硬件。
最小可用指标可以是：
- 注册用户数
- 日活用户数
- 同时在线人数
- 每日发帖数
- 附件大小和保留周期
- 是否需要全文搜索
- 是否需要邮件通知
如果这些指标没有定义，1000 人规模 只是一个想象。
想象可以点火。
但不能用来设计电源。
POWER
电力估算从平均功耗开始。
如果主机平均功耗是 15W：
15W * 24h = 360Wh/day
这只是主机本身。
实际系统还要计算：
- 路由器或光猫
- DC-DC 转换损耗
- MPPT 控制器损耗
- 电池可用容量
- 阴雨天冗余
- 冬季日照
- 面板角度和遮挡
- 电池老化
- 低温下 LiFePO4 的充电限制
所以日耗电量不应按 360Wh 设计。
更保守的第一版应该按 450Wh 到 550Wh 设计。
如果要三天无光照续航，需要大约：
450Wh/day * 3 = 1350Wh
550Wh/day * 3 = 1650Wh
一块常见的 12V 100Ah LiFePO4 电池，名义容量大约是 1280Wh。
扣除保留电量、转换损耗和老化余量后，它不足以稳妥支撑三天无光照。
这并不说明方案失败。
它只说明设计目标要变得诚实：
- 降低平均功耗
- 增加电池容量
- 缩短无光照续航目标
- 接受低电量时停机
- 或保留市电兜底
太阳能板也不能只写 200W。
200W 是标准测试条件下的额定功率，不是每天稳定产出的能量。
实际产出取决于地区、季节、天气、角度、温度和遮挡。
这部分应该用 NREL PVWatts 这类工具按地点估算，而不是凭感觉写死。
HARDWARE
主机可以选择二手 Tiny PC、低功耗 Mini PC 或 ARM 单板机。
二手企业小主机的优势是便宜、性能足、维护方便。
但具体型号必须逐台确认：
- CPU 是否可更换
- 是否有 PCIe 扩展
- 待机功耗是多少
- 满载功耗是多少
- 电源输入电压是多少
- BIOS 断电恢复是否可靠
- 风扇和硬盘是否适合长期运行
不要把一个系列写成一个确定结论。
同一品牌、同一外形、不同批次，内部结构也可能不同。
真正有价值的不是型号神话。
而是实测功耗。
第一台机器买回来以后，应该先用功率计记录：
- 空闲功耗
- 构建或压测功耗
- 数据库写入功耗
- 重启峰值功耗
- 24 小时平均功耗
没有这些数据，后面的电池和太阳能板选择都只是猜。
SOFTWARE
论坛软件可以先看两个方向。
Flarum 更轻，适合小型社区和较简单的部署。
但它依赖 PHP、Web server、数据库和 Composer 生态。
Discourse 更完整，包含更多现代社区功能。
但它通常按 Docker 方式部署，也会带来更多后台任务、邮件、搜索和运维复杂度。
两者都不是“装上就结束”。
论坛是有状态服务。
真正要设计的是：
- 数据库备份
- 附件备份
- 恢复演练
- 邮件发送
- 更新策略
- 日志保留
- 管理员登录保护
如果只想验证太阳能服务器本身，可以先运行静态站点、轻量 Wiki 或只读论坛镜像。
等电力和网络稳定后，再迁入真正的社区负载。
NETWORK
Cloudflare Tunnel 适合这个实验。
它可以让本地服务通过 cloudflared 主动连接到 Cloudflare，不需要公开源站 IP，也不需要开放入站端口。
这降低了家庭网络暴露面。
但它不是魔法。
源站仍然可能通过历史 DNS、错误配置、其他服务、邮件头或管理入口泄露。
所以更准确的说法不是“隐身”。
而是：
减少公开入站入口，把 Web 流量收束到 Cloudflare 边界。
如果需要备用网络，可以使用普通 4G/LTE 路由器作为合法的故障转移链路。
它的用途是断网时继续维护。
部署地点必须合法、授权、可进入、可维护。
不应把网络设计写成规避追踪或规避监管的方案。
那既不必要，也会让项目失去技术上的清晰。
OPERATIONS
SolarHost 的难点不是把机器点亮。
难点是它要在无人盯着的时候失败得足够温和。
最低运维要求：
- 低电量自动关机
- 来电后自动启动
- 文件系统抗断电损坏
- 定期离线备份
- 远程健康检查
- 温度监控
- 电池电压监控
- 关键配置可重建
如果这些没有准备好，太阳能只会把普通宕机变成更难排查的宕机。
BILL OF MATERIALS
第一版不应该追求极限。
它应该追求可观察。
一个更稳妥的原型可以是：
| 组件 | 建议 | 说明 |
|---|---|---|
| 主机 | 低功耗 Tiny PC 或 ARM 单板机 | 先测 24 小时平均功耗 |
| 电池 | LiFePO4，容量按目标续航反推 | 三天续航通常不应从 12V 100Ah 起步 |
| 控制器 | MPPT | 支持低压保护和状态读取更好 |
| 太阳能板 | 按地点估算后选择 | 不用额定功率直接推日发电量 |
| DC-DC | 足够功率余量 | 需要考虑启动峰值 |
| 保护 | 保险丝、合适线径、防水盒 | 这是电力系统，不是桌面小玩具 |
预算可以估。
但预算不应该先于功耗和续航目标。
否则便宜只是另一种不可靠。
NOTES
这个项目最有价值的地方，不是宣称摆脱云。
云也是一种基础设施。
太阳能、电池、隧道、域名、DNS、备份介质，也都是基础设施。
区别只在于它们是否被看见。
SolarHost 的意义是把一部分平时被隐藏的依赖重新放到眼前。
当一台服务器必须等待太阳、储存白天、熬过夜晚，它就不再只是一个抽象服务。
它重新变成了一个物。
这也许正是这个实验值得做的地方。
SOURCES
- NREL PVWatts Calculator (external)
- Cloudflare Tunnel documentation (external)
- Flarum installation documentation (external)
- Discourse cloud install guide (external)