雨云 VPS 搭 Flarum：1Panel 邮件、扩展与备份

给小型开源项目建一个讨论区，Flarum 的页面比较集中，主题和回复都容易找到。真正需要花时间的地方是版本选择、注册邮件与扩展维护：论坛首页能打开，只完成了开站的一部分。

这篇围绕 1Panel 的 Flarum 容器模板，按小型社区说明配置与维护。先把登录、发帖和恢复做可靠，再考虑增加上传、社交登录等功能。

先看版本，不把 1.8 与 2.0 混起来

2026 年 10 月 6 日，查看的 1Panel 模板使用 crazymax/flarum:1.8.19。Flarum 官方 2.0 文档仍标注为 release candidate，也就是候选版；1.x 已进入以关键与安全修复为主的维护阶段。

已经准备使用 1.8 模板，就查 1.x 文档与兼容扩展，不直接复制 2.x 的数据库和 PHP 要求。新社区也要把后续升级算进去：如果依赖的扩展还没有可用的 2.x 版本，先做测试副本，确定迁移路径后再长期运营，不能因候选版编号更大就直接覆盖正式论坛。

1Panel 这份模板选择 MySQL 或 MariaDB，PHP 运行环境在应用镜像中。它与在面板里另建 PHP 网站的部署方式不同，不要同时搭两套运行环境，把代理目标弄混。

VPS 先月付，数据库与图片都要留空间

内容简单、扩展少的论坛可以先观察 2 核 2GB，同机数据库和其他应用较多时，更建议 2 核 4GB。附件上传与图片尺寸也会影响磁盘和出站带宽，开站时就设置合理上传限制。

从雨云入口注册，优惠码填 KuZhuJi。香港机型可选“中国香港 → 极速三网[三区] → AMD EPYC → 流量不限型”，使用默认 40GB SSD 云盘和一个普通独立 IPv4。

2026 年 10 月 6 日，不使用账户优惠券时，2 核 2GB、5Mbps 上传、10Mbps 下载的月付报价为 38 元，消费返利 7.6 元；年付七折 319.2 元，返利 63.8 元。2 核 4GB、8Mbps 上传、15Mbps 下载的月付报价为 53 元，返利 10.6 元；年付七折 445.2 元，返利 89 元。

消费返利以积分发放，可用于续费，或按平台规则兑换、提现。规格、时长和优惠改变时，返利也会变化，以“立即购买”下方显示为准。先月付完成安装、邮件和扩展测试，再考虑购买更长时间。

初始化先限制访问，立即修改默认账号

准备数据库及专用用户，在 1Panel 安装 Flarum，填写数据库连接、表前缀和正式外部访问地址。模板把外部地址传给 FLARUM_BASE_URL，例如 https://forum.example.com；内部 HTTP 端口是 8000，宿主机端口按安装时的映射。

创建域名反向代理和 HTTPS，初始化时只允许自己访问。crazymax/flarum 镜像说明中的初始管理员账号和密码都是 flarum，第一次进入后台就修改密码与邮箱，确认自己的账号能重新登录后，再开放访问。不要把公开默认口令留到开始有人注册以后。

模板将 ./data 挂到 /data，应用文件的写入权限需要符合镜像的用户与组设置。目录写不进去时检查实际 UID、GID 和挂载，不要为了解决报错给整站设成 777。

邮件先测试注册与找回密码

在后台的邮件设置中选择合适驱动，使用外部 SMTP 时填写服务商给出的主机、端口、加密方式、账号和密码。发件域名完成邮件商要求的验证记录，论坛地址使用正式 HTTPS 域名。

保存后发送测试邮件，检查收件箱和垃圾邮件。Log 驱动只记录邮件，不会实际发送，不能用它开放需要邮箱验证的注册。

接着退出管理员账号，使用普通邮箱走完注册和验证，再测试忘记密码。测试邮件能收到但注册失败时，看应用日志和邮件商的投递结果，检查链接是否用了错误的域名、端口或协议。正式开站前就修好，否则读者会卡在无法激活的账号上。

扩展要能在容器重建后留下

先用内置标签组织“安装排错”“使用讨论”“版本公告”等内容。扩展一次添加一个，核对对当前 Flarum 核心的支持，观察权限和页面变化。插件名字相同，也可能只支持某个主版本。

这类容器镜像的扩展持久化方式，要按镜像维护者文档处理。当前 crazymax/flarum 文档将额外 Composer 依赖记录在 /data/extensions/list，启动时据此重新安装；它并不把容器里整个 vendor 目录当成持久数据。不同镜像版本的行为需要对照，不能在临时容器里装完扩展就认为以后都在。

保存扩展清单与版本约束，在测试副本上重建一次，确认扩展仍能加载。需要上传附件的扩展，还要检查它实际写入的位置和文件访问权限，避免数据库恢复了，附件却没有备份。

用管理员、普通成员和未登录窗口分别看公告区、私有标签以及上传内容。版主需要管理帖子，不一定需要安装任意 Composer 包的权限；赋予扩展管理权之前，应确认对方是否应该具备修改应用代码的能力。

升级前留一套能恢复的副本

停写后备份数据库与 /data 的实际主机目录，保存当前镜像、扩展清单及部署配置。备份放在 VPS 之外，恢复到隔离域名，关闭邮件，检查旧主题、回复、用户、头像和附件。

1.8 升级到 2.x 涉及核心、PHP 环境与扩展兼容，按对应主版本升级文档单独安排。先验证必要扩展是否能迁移，再测试数据库升级，不要在正式站用一个无约束的更新命令碰运气。

如果升级已经修改了数据库结构，回退时一起恢复升级前的数据库和文件。论坛开始有真实用户以后，维护窗口、备份与恢复检查应成为固定操作，不能等到某次扩展更新失败才第一次导出数据库。