自托管网站统计：Plausible Analytics部署与Nginx反向代理实战

1. 项目概述为什么要在自己的服务器上跑一套网站统计先聊个背景。最近本地部署这个词在开发者圈子里几乎天天刷屏从大模型到各种 AI 工具大家越来越习惯把第三方服务搬到自己的机器上。而我今天想聊的是另一个同样值得自托管的场景网站访问统计分析。具体项目是把开源的Plausible Analytics部署到自己的一台服务器上再通过域名让它对外提供访问服务。Plausible Analytics 是一款主打轻量、隐私友好、开源可自托管的网站统计工具。和 Google Analytics 这类老牌产品相比它没有几十个功能按钮堆出来的复杂界面也不搞 Cookie 弹窗、广告追踪而是用一张极简的 Dashboard 展示浏览量、访客数、来源渠道、落地页面、设备类型这些核心指标。对于博客、小型产品官网、独立开发者工具站来说完全够用而且数据存在自己手里合规压力小很多。这个项目的价值主要有几点一是数据自主可控不依赖第三方统计服务二是部署门槛不算高官方提供了 Docker Compose 编排文件照着改一改配置就能跑起来三是对外访问通过标准域名和 Nginx 反向代理实现链路清晰方便后续加 HTTPS、加访问控制。适合对数据有隐私要求的站长、独立开发者以及想学习多服务编排 反代部署这套经典架构的人参考。我这次全程实操走了一遍从环境准备到容器启动再到域名解析和 HTTPS 配置把每一步都记录了下来其中也踩了几个坑。下面按项目拆解的顺序把核心思路、操作过程和排错经验完整展开。2. 核心设计思路与技术栈拆解2.1 Plausible 为什么是Elixir ClickHouse的组合Plausible 的后端主服务用Elixir / Phoenix编写数据存储则交给ClickHouse另外搭配一个标准的PostgreSQL负责元数据、用户账号等关系型数据。这个组合初看有点混搭其实分工很清晰。Elixir 基于 Erlang 虚拟机擅长处理大量并发连接非常适合统计服务这种每个页面请求都要上报一条事件的场景。ClickHouse 是列式分析型数据库写入吞吐高、聚合查询快聚合看板需要频繁按时间维度汇总数据用 ClickHouse 比用普通关系库跑聚合高效得多。PostgreSQL 则只用它存用户、站点配置这类低频变化的数据。我自己的理解是这套架构把热路径和冷路径分开了。每个访客产生的原始事件进 ClickHouse统计数据看板直接查 ClickHouse 的聚合结果而登录、创建站点、修改站点域名这些操作走 PostgreSQL。两边的数据量级和查询特性完全不同拆开各自用最合适的存储比硬塞进一个数据库里更合理。2.2 官方 Docker Compose 里到底启动了哪几个服务Plausible 官方推荐用 Docker Compose 部署这一点很省心。打开https://github.com/plausible/analytics仓库的docker-compose.yml你会发现它编排了这六个服务plausible主应用服务承担 Web 界面、事件接收、统计查询全部逻辑。clickhouse用于写入和查询统计事件。clickhouse-backend另一个 ClickHouse 节点负责后端聚合任务。postgres存储账号、站点信息等元数据。geoip按 MaxMind GeoLite2 数据库解析访客地理位置定期刷新 IP 库。mail内置的 SMTP 邮件容器用于发送密码重置邮件等。如果你在浏览器里访问的是官方云版本这些组件是分散托管在云端的。自托管就是把所有组件拉到同一台机器上通过 Docker 网络互通。理解这个架构有个好处以后排查问题时你能一眼判断是哪个容器出了问题而不是对着一个整体瞎猜。3. 本地部署实操全流程记录3.1 环境准备一台干净的 Linux 服务器先说明部署环境。我使用的是 Ubuntu 22.04 LTS2 核 4G 内存40G 磁盘。这个配置跑 Plausible 是绰绰有余的因为它本身占用的资源很轻。如果你手头只有 1 核 2G 的机器也能跑但 ClickHouse 吃到内存会比较紧张建议不要同时再跑其他重负载服务。建议先执行系统更新再安装 Docker 和 Docker Compose 插件sudo apt update sudo apt upgrade -y curl -fsSL https://get.docker.com | bash - sudo systemctl enable --now docker sudo apt install -y docker-compose-plugin安装完成后验证一下docker --version docker compose version从现在开始所有容器操作都需要 root 权限或把当前用户加入 docker 用户组。我这里直接在 root 用户下操作省去sudo前缀。生产环境如果担心安全问题可以把部署用户加入 docker 组再执行。3.2 获取官方配置并调整关键参数我习惯把 Plausible 相关文件放在/opt/plausible下下载官方 release 里的 Docker Compose 模板mkdir -p /opt/plausible cd /opt/plausible curl -L -o docker-compose.yml https://raw.githubusercontent.com/plausible/analytics/master/docker-compose.yml curl -L -o clickhouse-init.d/init.sql https://raw.githubusercontent.com/plausible/analytics/master/clickhouse-init.d/init.sql curl -L -o plausible-conf.env https://raw.githubusercontent.com/plausible/analytics/master/plausible-conf.env这里有个细节直接下载 master 分支的模板通常是最新版本的但如果你有长期稳定部署的需求我更建议去 Releases 页面下载对应版本标签的文件避免后续某次升级引入不兼容变动。官方模板假设你跑在http://localhost:8000我们部署时要做两处关键改动BASE_URL和SECRET_KEY_BASE。打开plausible-conf.env把BASE_URL改成未来对外访问的完整地址BASE_URLhttps://stats.example.com SECRET_KEY_BASEyour-64-character-random-string注意这里不要随意填一个短字符串这个 secret 用于加密 Cookie 和敏感数据规则是至少 64 字节。生成方法有很多我比较常用openssl rand -base64 48这条命令会输出 48 字节的随机值符合要求。3.3 启动容器、执行数据库迁移、创建管理员账号第一次启动我建议先构建并后台运行然后立刻看日志docker compose up -d如果一切正常继续执行数据库迁移docker compose run --rm plausible /app/plausible eval Plausible.Release.migrate()官方模板在服务启动时也会自动尝试执行一些初始化任务但手动执行一次迁移更稳妥尤其在把旧数据迁移到新环境时这一步是必须的。数据库迁移完成后进入主容器创建管理员docker exec -it plausible-plausible-1 /app/plausible admin create-user \ --email adminexample.com \ --name admin \ --password your-password创建完成后用这个账号登录后台新建一个站点拿到一段统计脚本。这段脚本通常长这样script defer>server { listen 80; listen [::]:80; server_name stats.example.com; location / { proxy_pass http://127.0.0.1:8000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } }这里几个proxy_set_header头不能省。Plausible 会根据X-Forwarded-For来识别真实访客 IP如果没有这个头所有访问都会显示为 127.0.0.1统计就失真了。X-Forwarded-Proto则用于在 HTTPS 部署下生成正确的链接和重定向。启用配置并测试ln -s /etc/nginx/sites-available/plausible /etc/nginx/sites-enabled/ nginx -t systemctl reload nginx这一步做完访问http://stats.example.com就能看到 Plausible 的登录页了。4.3 HTTPS 证书申请与自动续期没有 HTTPS 的统计工具在现代浏览器里会被标成不安全而且 Plausible 的官方脚本也建议用 HTTPS 部署。申请证书我推荐 certbotsudo apt install -y certbot python3-certbot-nginx sudo certbot --nginx -d stats.example.com第一次执行会引导你输入邮箱并同意条款之后 certbot 会自动修改 Nginx 配置加上 SSL 相关指令。关键是续期建议配置 systemd timer 或 cronsudo certbot renew --dry-run实测中只要stats.example.com的 DNS 解析始终指向这台服务器注销前 nginx 配置完整自动续期基本不会出问题。如果你发现证书没续上先检查 80 端口是否被防火墙挡住certbot 的 HTTP-01 验证就是从 80 端口访问的。4.4 安全加固防火墙、访问白名单与后台保护反代配好、HTTPS 通之后我还会花额外的精力做几件加固操作这一步容易被新手忽略。限制服务器入方向端口只保留 22、80、443 三个端口。用 ufw 简单配置sudo ufw allow 22/tcp sudo ufw allow 80/tcp sudo ufw allow 443/tcp sudo ufw enable8000 端口不需要对外暴露让它继续监听在 Nginx 的转发链路上即可。如果你用的云服务商还需要去安全组里同步调整云厂商的安全组和本机防火墙是两层都要设置。后台访问加一层 Basic AuthPlausible 后台本身有登录机制但加一层 HTTP Basic Auth 可以把陌生人挡在登录页之前。额外的好处是少了大量被扫描的日志噪音。修改 Nginx 配置在location /里加auth_basic Restricted; auth_basic_user_file /etc/nginx/conf.d/stats_passwd;然后用 htpasswd 生成密码文件sudo apt install -y apache2-utils sudo htpasswd -c /etc/nginx/conf.d/stats_passwd admin这样访问https://stats.example.com会先弹系统级认证框通过后才看到 Plausible 登录页。注意这个方案对/js/script.js同样生效如果你的网站后台有轮询脚本也要考虑这一点。实践中我更推荐只给/stats后台路径加认证统计脚本路径保持公开。5. 常见问题、避坑指南与运维实录5.1 启动失败类问题速查部署过程中最常遇到的我整理成了一个小速查表现象可能原因处理办法容器一直处于 restart 状态数据库尚未就绪主应用启动过早docker compose logs plausible看具体报错等 postgres/clickhouse healthy 后再重启主服务输出大量 invalid secretSECRET_KEY_BASE长度或格式不对重新生成 64 字节随机值改完后必须删除容器重建docker compose down -v不可乱用建议只重启受影响容器访问后台报 500数据库迁移没执行执行docker compose run --rm plausible /app/plausible eval Plausible.Release.migrate()数据看板时间显示不对服务器时区非 UTC在plausible-conf.env中设置TZ或保持默认 UTC 并在用户层面适应邮件发送失败SMTP 配置缺失填好SMTP_HOST、SMTP_PORT、SMTP_USER、SMTP_PASS或先忽略邮件功能我这次实际踩过最坑的是忘记修改SECRET_KEY_BASE就启动了服务导致登录 Cookie 失效怎么登都是报 401。后来直接把容器删掉重建才解决。如果你只是改配置建议执行docker compose up -d --force-recreate它会用新配置重建容器。5.2 数据增长、备份与升级策略ClickHouse 和 PostgreSQL 都会持续落盘备份是必须考虑的。Plausible 官方文档提供了备份脚本核心思路是pg_dump导出 PostgreSQL 的账号和站点配置ClickHouse 数据则是复制它的数据目录。后者比前者体积大得多但胜在可以做定时快照。我的习惯是写一个 cron 任务每天早上 4 点执行0 4 * * * /opt/plausible/backup.sh /dev/null 21备份脚本里做三件事导出 PostgreSQL 数据、压缩 ClickHouse 数据目录、把产物同步到另一台存储机器或对象存储桶。恢复流程也要定期演练别等到服务器硬盘坏了才发现备份文件不可用。升级就比较简单了。先备份再修改docker-compose.yml里的镜像 tag 到最新版本号最后依次执行docker compose pull docker compose up -d docker compose run --rm plausible /app/plausible eval Plausible.Release.migrate()升级后立刻去后台点开几个报表确认数据正常显示。我遇到过升级后聚合缓存未刷新导致看板空白的情况重启一下主容器就恢复了。5.3 域名或端口调整后的注意事项如果你一开始用http://localhost:8000测试之后才改成正式域名有件事容易漏Plausible 后台里的站点设置、统计脚本地址都是跟着BASE_URL生成的。改域名后旧脚本里的src还指向旧地址必须重新从后台复制最新的统计脚本替换到网站里。同时如果你已经在旧域名下积累了一些历史数据它们会按旧域名记录。改BASE_URL不会自动迁移这些历史数据迁移数据需要在 ClickHouse 里执行简单的 UPDATE 操作把旧域名批量替换成新域名。这个操作要谨慎改之前先备份 ClickHouse 目录。6. 部署完成后的实际体验与个人建议整套部署完成之后我实际用了一周感受最明显的一点就是轻。打开 Dashboard 几乎是秒开服务端资源占用也一直很低。和之前用第三方统计工具相比最大的心理变化是踏实数据在自己手里导出、删除、迁移都不用看任何人的脸色。如果你正在评估自建统计方案我建议先想清楚自己的核心诉求。如果只是给个人博客看个访问量趋势那 Plausible 完全够用如果需要事件分析、漏斗转化、用户分群这些复杂分析功能那它确实不如 Matomo 或 GA 全面。工具选型没有绝对优劣匹配需求才最重要。最后分享一个小技巧Plausible 的 API 是开放的部署完成之后可以用它的统计 API 拉数据做定时周报或者接到企业微信群和钉钉机器人上。我自己就写了个简单的定时任务每周日晚上把上周的访问数据汇总成一条消息发到团队群。这下不仅网站统计自托管了连数据消费都自动化了整个链路跑通之后非常舒服。希望这份实操记录能帮你少走一点弯路。