在共享服务器上跑 Wafrn：用 Caddy 同时托管多个服务

想一次发文，多个平台都看到

现在很多人喜欢用去中心化网络（fediverse）。发一条内容，能同时出现在 BlueSky、Mastodon、Lemmy 等多个平台上。Wafrn 就是做这个的——它给你一个统一的管理后台，帮你搞定跨平台发布。

听起来很棒，但实际部署的时候却容易卡住。Wafrn 默认的安装方式，是假设你有一台独立服务器，直接跑 Docker，让 Caddy 全权处理网络和证书。可很多人的 VPS 上已经跑了好几个服务，比如 WordPress、一些小工具，或者老系统，这时候就冲突了。

默认方案为什么不适合你

Wafrn 官方推荐的部署很简单：

1. 用 Docker 跑 Wafrn，里面自带 Caddy 做反向代理
2. 自动用 Let's Encrypt 申请 HTTPS 证书
3. 支持 ATProto 账号（BlueSky 联邦需要）

问题出在：Wafrn 依赖 Caddy 自动生成的证书来验证 ATProto 身份。这不是可选项，是协议要求。ActivityPub 和 ATProto 都会检查证书，确认你真的控制了这个域名。

如果你 VPS 上已经用 Nginx（或其他服务器）占用了 443 端口，就没法再跑一个 Caddy。端口冲突先不说，证书管理也会乱套。

折中方案：让 Caddy 做「副手」

不用换掉你现有的 Nginx，直接在后面加一层 Caddy + Wafrn，专门处理 Wafrn 的需求。

架构大概是这样：

外部请求（BlueSky、Mastodon 等）
    ↓
你的主域名（Nginx 监听 443）
    ↓
内部网络
    ↓
Caddy + Wafrn（负责 ATProto 证书验证）

具体流程：

1. 所有流量先打到你主服务器的 Nginx
2. Nginx 把 Wafrn 相关的路径（比如 /wafrn/*）转发给内部的 Caddy
3. Caddy 自己管理证书，满足 ATProto 的验证要求
4. Wafrn 就能正常和其他平台联邦了

这样既不破坏现有服务，又能让 Wafrn 正常工作。

从 Nginx 换 Caddy，AI 能帮什么忙？

如果你决定把主反向代理从 Nginx 换成 Caddy，AI 工具可以帮你快速转换配置。把 Nginx 的规则翻译成 Caddyfile 格式，AI 基本一次就能搞定。

但涉及到 Wafrn 的混合部署，AI 就容易出错：

• 它不一定懂 ATProto 对证书的具体要求
• 不知道哪些环境变量会影响代理行为
• federation 出问题时，很难定位是哪步配置错了
• 有时还会给出有安全隐患的建议

实用建议：用 AI 做格式转换没问题，但涉及到架构设计，还是自己多验证。尤其是边缘情况，AI 生成的配置往往需要花更多时间调试。

把你的方案写下来

如果你自己摸索出了 workable 的配置，建议记录下来。Wafrn 的官方文档默认假设你用独立服务器，很多共享主机的实际问题都没覆盖到。

把你的配置发到 GitHub、写成教程，或者提交到官方文档，都能帮后面的人省 2-3 小时的试错时间。

几点自托管建议

1. 搞清楚协议要求：ATProto 联邦必须用和域名绑定的有效证书。
2. 别照搬默认方案：独立服务器最简单，但共享 VPS 更常见，也更省钱。
3. 用 Caddy 做独立服务：不要和主服务器抢端口，让它专门处理 Wafrn 的需求。
4. AI 只用来转换配置：别让它直接设计架构。
5. 分享你的方案：既帮了别人，也方便自己以后查。

接下来？

如果你也在共享服务器上跑多个服务，又遇到类似证书或协议限制的问题，Wafrn 的这种「副手代理」模式可以作为参考。很多需要证书控制的联邦应用，都可以用类似思路处理。

想了解更多去中心化工具的自托管方案，或者深入 ATProto 和 ActivityPub 的联邦机制，欢迎在评论区留言。