拳力向前1. 为什么生产级Headscale必须换掉SQLite
1.1 我的Headscale"卡死"事故
先说一个让人印象深刻的真实场景。我刚开始自建Headscale服务时，图省事直接用默认配置，数据库用的是SQLite。当时想着节点数不多，SQLite这种零维护的方案足够用了。结果在某个工作日的下午，整个内网穿透服务直接卡死，所有已连接的设备纷纷断线，新节点的注册请求也全部超时。
查看Headscale日志，发现大量database is locked和SQLITE_BUSY报错。当时同时有几十个节点在批量同步状态，再加上几个节点的网络抖动触发了重连风暴，SQLite的单写者模型根本扛不住这种并发。更麻烦的是，当我尝试用headscale nodes list查看节点状态时，命令也卡住了，因为SQLite的文件锁被一个异常进程占住，整个控制面都失去了响应。
这次事故之后，我才意识到一个核心问题：Headscale这种网络控制平面，本质上是一个实时状态同步系统，所有节点的在线状态、路由信息、密钥轮换都要频繁写入数据库。SQLite作为嵌入式数据库，在几百个节点、频繁状态变更的场景下，写入锁竞争会越来越严重，最终演变成整个服务不可用。
1.2 SQLite在Headscale场景的三个结构性瓶颈
第一个瓶颈是写锁粒度太大。SQLite使用数据库级写锁，同一时刻只允许一个写事务。当节点数量增多，每个节点的心跳、状态更新、路由广播都要抢这把锁，其他写入只能排队等待。在节点数超过200、心跳间隔较短的场景下，锁等待时间会成倍增长。
第二个瓶颈是数据可靠性。SQLite的WAL模式虽然能缓解读写冲突，但本质上还是一个单文件数据库。磁盘损坏、进程被kill、容器重启，都有可能导致数据库文件损坏。Headscale的节点注册信息、用户认证数据、路由配置全部丢失，而备用的恢复手段又非常有限。我的实测经验是，SQLite文件一旦超过100MB，损坏后的修复成功率会明显下降。
第三个瓶颈是水平扩展能力。Headscale想要做高可用，至少要让数据库支持主从复制或共享存储。SQLite单文件模式天然不支持网络共享，即使把数据库文件放到NFS上，也会因为文件锁机制导致更严重的冲突。
1.3 生产级网络对数据库的真实诉求
生产级网络和数据中心内部网络、远程办公组网不同，它对数据库的要求非常高，具体可以拆成四个维度：
- 并发写入能力：节点上线、下线、路由变更，都要实时更新数据库。生产环境期望同一时间支持数百节点的状态变更，不能因为写入并发高就丢状态。
- 数据一致性与持久性：节点密钥、用户信息、ACL策略这些核心数据，必须保证事务提交后不丢失。PostgreSQL的WAL机制在这一点上做得非常扎实。
- 查询效率：Headscale管理界面、节点列表、路由查询，都需要快速返回结果。PostgreSQL对索引、复杂查询的支持远超SQLite。
- 可运维性：生产环境需要备份、恢复、监控、迁移、高可用，这些都是PostgreSQL这种企业级数据库的原生能力。
在我切换数据库之后，这种对比更加明显。以前SQLite模式下，节点一多管理命令都卡，现在PostgreSQL模式下headscale nodes list基本是毫秒级返回，哪怕节点数上百也一样流畅。所以结论很直接：如果你只是在自己电脑上跑个试验，SQLite没什么问题；但一旦要当生产基础设施用，就必须换PostgreSQL。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. PostgreSQL数据库的安装与初始化要点
2.1 从包管理器安装：两条主流路径
PostgreSQL的安装方式主要看你的服务器系统。我在实践中主要用到两种方式，直接分享最顺手的路径。
Debian/Ubuntu系，直接用apt安装，简单可靠：
bash复制sudo apt update
sudo apt install -y postgresql postgresql-contrib
安装完成后，PostgreSQL默认会创建一个postgres系统用户和一个同名的超级数据库用户。这里有个细节，很多人第一次用psql连接时，发现提示没有密码，因为默认的postgres用户认证方式是peer，即只能通过系统用户postgres登录。所以必须先用sudo -i -u postgres psql切换到系统用户，再设置数据库密码。
**CentOS/RH