Umami 部署教程：VPS 上用开源统计替代 Google Analytics

如果你的站点主要面向大陆访客，却还在用 Google Analytics（谷歌分析），大概率遇到过统计后台加载缓慢甚至直接打不开的问题。这篇文章教你如何在一台 VPS（虚拟专用服务器）上部署开源统计工具 Umami，把数据所有权收回自己手里。整个流程用 Docker 完成，一台最低配置的小鸡就够跑，前后大约二十分钟。

先说结论：Umami 是一个 MIT 协议的开源网站统计项目，部署后只占两三百兆内存，前端统计脚本只有约 2KB，对页面加载速度几乎无感。对个人站长和中小团队来说，它是替代 GA 最现实的方案之一。

为什么站长开始换掉 Google Analytics

在我的测试环境和周围站长的反馈里，换掉 GA 的理由集中在三个：

一是访问问题。GA 的统计脚本和后台都依赖境内访问不畅的域名，晚高峰时段 script 加载失败率明显上升，统计出来的数据本身就失真——你看不到一部分真实访客。自托管方案把采集端和后台都放在自己的服务器上，访客浏览器直接请求你的域名，不存在被墙的环节。

二是数据合规。GA 采集的是用户级数据并传输到境外服务器，对有合规要求的业务来说是个隐患。Umami 默认只记录匿名化数据，不设 Cookie、不采集个人身份信息，这一点对欧盟访客为主的站点尤其友好（GDPR 即欧盟通用数据保护条例）。

三是界面效率。GA 4 的报告层级深、加载慢，查一个”昨天哪个页面 PV（页面浏览量）最高”要点四五层菜单。Umami 的仪表盘打开就是访问趋势、来源国家、热门页面，一两秒出结果，日常看数据效率高得多。

当然它也不是全能替代：GA 的用户行为流、跨设备归因、与 Ads 的联动，Umami 目前没有。如果你重度依赖广告投放归因，可以两者并行；如果只是看流量、来源和内容表现，Umami 完全够用。顺带一提，决定自托管之后，VPS 本身的线路质量会直接影响统计脚本加载速度，相关因素可以参考这篇影响美国 VPS 服务器速度的核心因素与优化指南。

部署前的环境准备

一台能跑 Docker 的 VPS 就行。我用的测试机是 1 核 1G 内存的入门款，实测部署后内存占用约 280MB，加上系统占用还有余量，所以最低 1G 内存即可，建议 2G 更稳妥。如果你还没选定服务器，可以先看这份美国 VPS 选购指南：五大核心指标一次看懂，带宽（服务器的数据传输吞吐能力）、内存和线路是跑统计服务最需要关注的三项。

系统方面推荐 Ubuntu 22.04 或 Debian 12。需要准备的东西只有三样：一个解析到服务器 IP 的域名（用于后台访问和 HTTPS）、Docker 环境、以及一个 MySQL 或 PostgreSQL 数据库。Umami 支持 SQLite 免数据库运行，但生产环境不推荐——备份和升级都麻烦，PostgreSQL（一种开源关系型数据库）是更省心的选择。

如果 VPS 上还没有 Docker，先装上：

curl -fsSL https://get.docker.com | sh
systemctl enable --now docker

数据库可以用官方镜像快速起一个 PostgreSQL：

docker run -d --name umami-db \
  -e POSTGRES_DB=umami \
  -e POSTGRES_USER=umami \
  -e POSTGRES_PASSWORD=换成强密码 \
  -v umami-db-data:/var/lib/postgresql/data \
  --restart unless-stopped \
  postgres:16-alpine

数据通过命名卷 umami-db-data 落盘，重建容器不会丢统计数据。这里建议顺手在数据库容器上加一段定期备份，后面细说。

Docker Compose 部署 Umami 主程序

容器之间通信用一个自定义网络更干净，先建网络，再用 Compose 拉起主程序。官方镜像 ghcr.io/umami-software/umami 每次更新都会重新构建，跟随最新 tag 即可拿到新版本。

新建 docker-compose.yml，内容如下：

services:
  umami:
    image: ghcr.io/umami-software/umami:postgresql-latest
    ports:
      - "127.0.0.1:3000:3000"
    environment:
      DATABASE_URL: postgresql://umami:换成强密码@umami-db:5432/umami
      DATABASE_TYPE: postgresql
      HASH_SALT: 随机字符串
    depends_on:
      - umami-db
    restart: unless-stopped
    networks:
      - umami-net

networks:
  umami-net:
    external: true

两个细节值得注意。第一，端口映射写成了 127.0.0.1:3000:3000，只监听本机回环，公网无法直接访问 3000 端口，后面由 Nginx 反代并套 HTTPS，这比裸奔安全得多。第二，HASH_SALT 用于数据匿名化哈希，随便一串长随机字符即可，一旦上线不要再改，否则历史访客去重数据会错乱。

启动并初始化：

docker network create umami-net
docker compose up -d
docker compose logs -f

看到 “Waiting for init…..Ok” 之后服务就绪，用默认账号 admin / umami 登录 http://服务器IP:3000，第一件事是改密码。如果你像上面那样只监听了 127.0.0.1，本地验证可以用 curl 测试：

curl -I http://127.0.0.1:3000

返回 HTTP/1.1 200 OK 即正常。在我的 1 核 1G 测试机上，首次启动到就绪耗时约 40 秒，之后内存稳定在 280MB 左右，CPU 日常几乎为 0，晚高峰采集时也只有个位数占用，小鸡跑起来毫无压力。

Nginx 反代与 HTTPS 收尾

服务本体就绪后，还差对外这一层。把域名 A 记录指到 VPS 的 IP，再用 Nginx 做反向代理（把外部请求转发给内部服务的一种方式），并签发一张 Let’s Encrypt 免费证书：

apt install -y nginx certbot python3-certbot-nginx
certbot --nginx -d stats.example.com

certbot 会自动改写 Nginx 配置并加好 80 端口跳转 HTTPS。剩余的反代部分手动补全，站点配置核心只有 proxy_pass 一段：

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;
}

其中 X-Forwarded-For 这行不要省：Umami 依赖它识别访客真实 IP 做去重统计，缺了它所有访客都会被记成同一个来源。如果你的站点套了 CDN（内容分发网络），还需要在 Umami 后台 “设置-IP 地址头” 里改成 CDN 传递真实 IP 的请求头，否则地区统计会全部指向 CDN 节点。

最后到目标网站的页面源码里加一行统计脚本：

<script defer src="https://stats.example.com/script.js" data-website-id="你的站点ID"></script>

脚本只有约 2KB，defer 异步加载不阻塞渲染。上线后打开自己站点几个页面，回到 Umami 仪表盘确认实时访问开始跳动，整条链路就打通了。

数据备份与日常维护

自托管最容易被忽略的就是备份。统计数据的备份策略很简单：每天导出一次数据库即可，PostgreSQL 一行命令搞定：

docker exec umami-db pg_dump -U umami umami | gzip > /backup/umami-$(date +%F).sql.gz

把它丢进 crontab 每天凌晨 3 点执行，再配一条 find 命令清理 30 天前的旧备份。备份文件建议同步一份到另一台机器，单机备份扛不住磁盘故障。

升级也很轻量，官方镜像持续更新，一般每月跟随一次：

docker compose pull
docker compose up -d

Umami 启动时会自动跑数据库迁移，实测升级窗口约 10 秒，统计脚本请求会短暂失败但浏览器端无感知。升级前务必先确认当天备份已完成。

安全层面再补两条：一是上面已经做的 127.0.0.1 监听加反代，后台不暴露公网明文端口；二是建议在 Nginx 层给 /login 路径加访问频率限制，或者干脆用 Umami 自带的共享链接功能把只读报表分享出去，后台账号只留给自己。ufw（Ubuntu 默认防火墙）上只需要放行 80 和 443，3000 端口保持对外关闭。

写在最后：要不要迁移到 Umami

总结一下。Umami 解决的是”数据在自己手里 + 大陆访问无障碍 + 资源开销极低”这三件事，一台 1G 内存的小鸡就能长期稳定运行，运维成本接近于零。它的短板在深度行为分析和广告归因，这部分需求强烈的站点可以 GA 与 Umami 并行跑一段时间，对比两边数据后再决定是否完全切换。

如果你正在选服务器，跑统计这类常驻小服务，优先挑带 CN2 GIA 或对大陆友好的线路，访客打开统计脚本才更快，这类方案可以了解下 Hostease 的美国 VPS 产品线。可以参考这篇海外 VPS 与境内 VPS 性能对比：速度、稳定性与安全性全解来选型，个人博客类站点也可以看看2025年最值得选择的海外 VPS 推荐榜单（附购买建议）。建议你现在就起一台测试机按上面的步骤跑一遍，二十分钟后你会得到一个完全属于自己的统计后台；如果你需要多站点统一管理或团队协作功能，Umami 的团队版（Open 协议部分）也能覆盖。