我为什么自己跑了一个 Mastodon 实例

我那台服务器上跑的东西已经够多了：博客、Wiki、几个 Docker 服务、一堆定时脚本。按理说不该再往里塞一个 Mastodon。

但我还是装了，现在是 为什么我选择自建博客 之外，我花时间最多的一个自托管服务。

先说为什么不安心当个用户

长毛象上现成的大站不少，注册只要三十秒。我不去注册的原因很具体，不是什么理念。

第一是账号归属。 在别人的实例上，我的账号是 @gjcloak@某个域名。哪天站长不想干了、域名忘了续费、或者单纯看我不顺眼，这个身份就没了。迁移功能有是有，用过的人都知道那体验有多勉强。而在自己的实例上，账号是 @gjcloak@x.lzplus.top，只要我的域名还在，这个身份就在。

第二是我想改界面。 我想给它做朋友圈那种九宫格图片布局——就是微信里发九张图排成三乘三的样子。这事在别人的实例上做不到，你连 CSS 都碰不到。在自己的实例上，改主题就是改几个文件的事。

第三是数据在自己手里。 我看得到数据库里有什么，能自己备份，能决定跟谁联邦、不跟谁联邦。

这三个理由都不高尚，全是实用的。

部署时真正卡住我的三个点

安装文档写得挺全，照着走大体能通。但下面这三件事，文档里要么没写，要么写得你不会当回事——我是一个个撞上去才记住的。

数据库连接必须用 TCP，不能用 socket

这是第一个坑，也是最莫名其妙的一个。

我习惯性地在配置里填 localhost，结果连不上。换成 127.0.0.1 就好了。原因是我这台机器上 MySQL 的 socket 文件路径和 Mastodon 预期的对不上，走 TCP 显式指定主机和端口反而稳定。

# 能连通
mysql -h 127.0.0.1 -P 3306 -u mastodon -p

# 连不上，报 socket 相关错误
mysql -u mastodon -p

这事小到不值一提，但它卡了我二十分钟——因为你本能地觉得 localhost 和 127.0.0.1 是一回事。在大部分地方它们确实是一回事，在这里不是。

机器人要单独开账号

我在这台服务器上跑了一个 RSS 转发机器人，还有个 monitor.py 做服务监控，异常了要发通知。

一开始图省事，让它们都用我的主账号 @gjcloak 发。结果是我打开时间线，满屏都是自己服务器发的机器消息——转发的新闻、监控的告警——真正想看的人说话被挤到下面去了。

后来开了个专门的「巡检机器人」账号，所有自动化内容走它，主账号只发人话。这个改动很小，对使用体验的影响比我想的大：时间线终于又是时间线了。

Cloudflare 挡在前面，真实 IP 要处理

我的所有站点都在 Cloudflare 后面，Mastodon 也一样。好处是防扫描、省带宽，代价是应用看到的来访 IP 全是 Cloudflare 的节点 IP。

这对 Mastodon 影响比较直接：限流、封禁、日志都会失准，你封的可能是一整段 Cloudflare 节点。需要在 Nginx 那一层把 CF-Connecting-IP 还原成真实来源，不然后台那些 IP 相关的功能基本是摆设。

一个人维护一个实例，成本在哪

装完那天挺高兴的。真正的问题是装完之后。

升级不能拖。 Mastodon 版本迭代不算慢，安全更新出来了得跟上。但每次升级都是一次小型运维——要跑数据库迁移、要重启 Sidekiq、要预编译资源。我一般会先备份再动手。

备份要自己想着。 大站的实例有别人替你备份，自己的实例没有。数据库、用户上传的媒体文件、Redis 里的队列，都得进备份计划。我在这台机器上有一套备份策略，Mastodon 只是加了进去——但如果当初没有现成的策略，光是为了它我也得建一套。

它挂了没人知道，除非你盯着。 所以我把 Mastodon 并进了 monitor.py 的巡检范围，跟其他服务一起探活。这也是为什么前面说机器人账号要分开——告警走机器人，不占我的时间线。

新服务器到手，我做的第一件事不是装 Docker 里我写过，服务器上的每个服务都是一笔长期负债。Mastodon 是其中比较重的一笔。

值不值

值不值要看你拿它当什么。

如果你只是想有个地方发长毛象，那完全没必要自建，找个口碑好的实例注册就行，省下来的时间够你写几十条内容。

我是把它当自己的一块地在经营。自托管工具盘点：我用 Docker 跑的 7 个服务 那些服务解决的是具体问题，Mastodon 不太一样——它更像一个我说了算的公共空间。想改九宫格就改九宫格，想调整联邦策略就调整，不用跟任何人商量。

代价就是它不会自己照顾自己。