给网站做访问统计，很多人第一反应是接入第三方服务，但数据放在别人手里总归不踏实，而且免费额度往往有限制。其实用 Docker 在自己的服务器上跑一套开源统计系统，十分钟就能搞定，数据完全自己掌控。本文以轻量级统计工具 Umami 为例，完整走一遍部署流程，并顺带讲清楚持久化、反向代理这些容易被忽略的细节。
为什么网站统计适合用 Docker 来部署
统计类应用通常由多个组件构成：一个 Web 服务负责接收打点请求和展示报表，一个数据库负责存储访问记录。如果按传统方式安装，你得手动装 Node.js、装 PostgreSQL 或者 MySQL、配置环境变量、设置开机自启，步骤繁琐且容易出错。而 Docker 把这些统统打包成镜像，一条命令就能把整套环境跑起来。
更重要的是隔离性。统计服务的数据库版本、依赖库不会和服务器上其他应用冲突。以后想升级，拉取新镜像重建容器即可，回滚也只是切回旧版本镜像的事。对于跑着多个站点、多个服务的小型服务器来说，这种干净利落的运维方式能省下不少维护成本。
另外，统计系统天然存在流量波动。突发流量打过来时，容器的资源限制功能可以保证统计服务不会吃光整机内存，把主站拖垮。这一点在低配 VPS 上尤其有价值。
用 docker-compose 部署 Umami 统计服务
Umami 是一款开源的隐私友好型统计工具，不使用 Cookie、不收集个人信息，界面清爽，自部署后不限网站数量和流量。官方提供了 Docker 镜像，配合 docker-compose 可以一次拉起应用和数据库两个容器。
先在服务器上创建一个工作目录，例如 /opt/umami，然后编写 docker-compose.yml 文件：
version: '3'
services:
umami:
image: docker.umami.is/umami-software/umami:latest
ports:
- "3000:3000"
environment:
DATABASE_URL: postgresql://umami:umami@db:5432/umami
DATABASE_TYPE: postgresql
APP_SECRET: 换成你自己的随机字符串
depends_on:
- db
restart: always
db:
image: postgres:15-alpine
environment:
POSTGRES_DB: umami
POSTGRES_USER: umami
POSTGRES_PASSWORD: umami
volumes:
- ./data:/var/lib/postgresql/data
restart: always几个关键点值得说明。APP_SECRET 用于加密会话，生成方式可以用 openssl rand -base64 32 随机产生一段。数据库密码不要照抄示例，改成自己的强密码，并且和 DATABASE_URL 中的连接串保持一致。volumes 那行把 PostgreSQL 的数据目录映射到了宿主机的 ./data 目录，这样即使容器被删除重建，历史统计数据也不会丢失——这是数据持久化的关键，漏掉的话每次重建容器数据都会归零。
写好配置后在目录里执行：
docker compose up -d docker compose logs -f umami
日志里看到服务监听在 3000 端口后，浏览器访问 http://服务器IP:3000，用默认账号 admin 和密码 umami 登录，第一件事就是改掉默认密码。接着在后台添加你的网站，系统会生成一段类似下面的统计脚本：
<script async defer src="https://统计域名/script.js" data-website-id="你的网站ID"> </script>
把这段代码放到目标网站每个页面的 <head> 标签内，稍等片刻访问一次页面，后台报表里就会出现数据了。
反向代理与 HTTPS 配置
直接暴露 3000 端口能用，但不规范。统计脚本要嵌到正式网站上，最好给它配一个独立域名并启用 HTTPS，否则部分浏览器的混合内容策略会导致打点请求被拦截。常见做法是用 Nginx 做反向代理，把域名请求转发到容器端口。
下面是一份可直接使用的 Nginx 配置，假设统计服务的域名为 stats.ipipp.com：
server {
listen 80;
server_name stats.ipipp.com;
location / {
proxy_pass http://127.0.0.1:3000;
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;
}
}配好后用 certbot 申请证书即可：certbot --nginx -d stats.ipipp.com，证书会自动续期。这里有一个高频踩坑点：如果后台报表里看到的访客 IP 全是 127.0.0.1 或者 Nginx 所在机器的内网地址，说明容器没有拿到真实 IP。原因是代理转发时丢失了客户端信息，解决办法就是确保上面的 X-Forwarded-For 头正确传递，同时在 Umami 的环境变量里加上一条 CLIENT_IP_HEADER: x-forwarded-for，让它从这个请求头里读取真实访客地址。
如果不想在宿主机直接装 Nginx，也可以把 Nginx 本身做成一个容器加进同一个 compose 文件里，或者使用 Nginx Proxy Manager 这类带网页面板的方案，证书申请和续期都可视化操作，对不熟悉 Nginx 配置的人更友好。
常见问题排查与日常维护
部署完成后难免遇到问题，这里列出几个最常见的情况。第一类是容器反复重启，多半是数据库连接失败，用 docker compose logs db 查看数据库日志，检查用户名、密码、连接串是否一致。第二类是页面嵌入脚本后没有数据，先打开浏览器开发者工具的 Network 面板，看打点请求 /api/send 是否发出、返回状态码是否为 200，再检查脚本里的域名和 data-website-id 是否填对。
第三类是时区问题。容器默认使用 UTC 时间，报表时间可能和实际差八个小时。解决办法是在 compose 文件中给容器加环境变量 TZ: Asia/Shanghai，或者干脆在 Nginx 展示层自行换算。数据库容器同样建议加上这条，避免两边时间基准不一致。
日常维护方面，建议定期备份 ./data 目录， PostgreSQL 的数据都在里面，打包压缩即可完成全量备份。升级时先 docker compose pull 拉取新镜像，再 docker compose up -d 重建容器，由于数据在宿主机卷里，升级过程不会丢数据。有条件的话，升级前还是先停掉容器做一次数据备份，稳妥一点总没坏处。
整套方案跑通之后，你会得到一个不限量、无广告、数据完全归自己所有的统计平台。同样的思路也可以迁移到 Matomo、Plausible 等其他开源统计工具上，区别只在镜像名和环境变量，整体流程基本一致。