2026 年用 Umami 自建隐私分析：1GB 小机替代 Google Analytics（实测避坑）

2026-08-16 · DevCraft Studio

不想再被 Cookie 横幅烦、又担心 GA 把数据交给别人？这篇手把手教你用一台 1GB 的便宜 VPS 跑起 Umami：Node + Postgres 全套约占 512MB 内存，追踪脚本只有 2KB，无 Cookie 即可合规统计流量。包含 docker-compose 实战、自定义事件、反广告拦截与常见避坑。

延伸阅读

更多相关攻略推荐：【年付性价比 01】年付 VPS 性价比排行 2026：同配置谁最值、【10刀以内VPS系列 01】年付不到70块钱的便宜VPS，到底能用、43 亿个地址怎么就不够用了？IPv4 的设计缺陷与人类“续命”奇技、VirMach 值得买吗？1 刀/月神机还是踩坑重灾区？（避坑）、【美西VPS 01】美国洛杉矶 VPS 推荐 2026：CN2 GI。

为什么是时候甩掉 Google Analytics 了

说句实话，GA4 对普通站长已经越来越不友好了。一方面它默认收集一堆 PII 级别的信号，GDPR、CCPA 下你得挂 Cookie 同意横幅，否则在欧洲就是合规风险;另一方面，那个 45KB 左右的追踪脚本拖慢首屏，用户还经常用广告拦截直接把它屏蔽掉，统计出来的数字本身就失真。

更关键的是数据主权。你的访客行为全在 Google 的服务器上，你只是"借用"了看一眼的权限。2026 年隐私合规和"去 GA 化"已经是明显大势，很多独立开发者、个人博主开始把分析迁回自己手里。Umami 就是这条路上最省心的一个选择：MIT 许可、开源、轻量，跑在自家 VPS 上，数据自己说了算。

Umami 到底是什么，凭什么能替代 GA

Umami 是一个用 Next.js 写的开源网站分析工具，官方支持 PostgreSQL（最低 v12.14，现在常用 postgres:16-alpine）。它的设计哲学是"只收集真正需要的指标"：页面浏览、访客数、来源、设备、国家、停留时长，以及你可以自定义的任意事件。没有 cookie、没有跨站指纹、不收集个人身份信息，因此法律上通常不需要同意横幅。

和另一个热门的隐私分析 Plausible 比，Umami 完全免费、没有付费网络封锁，功能虽然没那么花哨，但对大多数站点已经够用。Plausible 云版要按流量付费，自托管版同样吃资源;Umami 直接写进你已经熟悉的 Postgres，备份就是一条 pg_dump，运维心智负担小很多。这也是它适合便宜小机的核心原因。

选多大机器：1GB 真能跑，但别太抠

先给结论：Umami 本身常驻内存很低，整个容器栈（Umami + Postgres）空闲时大概 200–250MB，跑起来统计时也就 300–400MB。1GB 内存的机器完全能跑，但建议留点余量，别再堆一堆重服务。

如果你预算吃紧，像 RackNerd 那种年付几美元的 1GB 小机、Bandwagon（搬瓦工） 的入门 KVM，或者 CloudCone 的特价 1GB 套餐都够用。我自己的实测是：单站、月 PV 在十万以内，1 vCPU / 1GB RAM / 20GB SSD 非常稳。要是你打算同时挂多个站点、或者长期保留几年历史数据，把内存加到 2GB 会更从容，Postgres 的缓存不会被 OOM killer 盯上。

硬盘方面 20GB 起步即可，访问量大的话记得定期清理或归档 events 表。系统用 Ubuntu 22.04/24.04 或 Debian 12 都行。

如果你的机器只有 1GB 而且还想跟别的服务挤在一起，强烈建议加一块 1GB 的 swap 文件兜底。Postgres 在生成复杂报表时偶尔会瞬时多吃内存，有 swap 就不至于被 OOM killer 直接干掉。命令很简单：fallocate -l 1G /swapfile && chmod 600 /swapfile && mkswap /swapfile && swapon /swapfile，再写进 /etc/fstab 让它开机自动挂。这样哪怕同机还跑着 Caddy、Vaultwarden 之类，Umami 也能稳稳活着，性价比拉满。

docker-compose 实战：十分钟拉起整套

部署前确认你已经装好 Docker 和 Docker Compose V2，并且有一个域名（比如 analytics.example.com）的 A 记录指向这台 VPS 的公网 IP。先生成两个随机串，一个当 APP_SECRET，一个当数据库密码：

openssl rand -hex 32

openssl rand -base64 32

然后创建 /opt/umami 目录，写下面这份 docker-compose.yml（注意把两个随机串填进去）：

services:

umami:

image: ghcr.io/umami-software/umami:postgresql-latest

container_name: umami

restart: unless-stopped

ports: ["3000:3000"]

environment:

DATABASE_URL: postgresql://umami:你的库密码@db:5432/umami

APP_SECRET: 你的随机串

DISABLE_TELEMETRY: 1

depends_on:

db: { condition: service_healthy }

db:

image: postgres:16-alpine

container_name: umami-db

restart: unless-stopped

environment:

POSTGRES_DB: umami

POSTGRES_USER: umami

POSTGRES_PASSWORD: 你的库密码

volumes: ["pgdata:/var/lib/postgresql/data"]

healthcheck:

test: ["CMD-SHELL", "pg_isready -U umami"]

volumes: { pgdata: {} }

保存后一条命令启动：docker compose up -d。等几十秒数据库初始化完，浏览器打开 http://你的IP:3000，用默认账号 admin / umami 登录，第一件事就是把密码改掉。建议同时用 Caddy 或 Nginx 反代到你的子域名并申请 HTTPS，这样追踪请求走加密连接也更稳。

顺带一提，如果你的 VPS 前面已经有 Caddy 在跑别的站点，直接把这个 analytics 子域名加进同一个 Caddyfile 就行，不用再单独起一个 Caddy 容器，省内存也省心。确认 docker compose ps 里两个容器都是 healthy 状态，再继续下一步接入脚本。

接入 2KB 追踪脚本，零横幅合规

登录后进 Settings → Websites → Add website，填好站名和域名，Umami 会给你一段追踪代码，长这样：

<script async src="https://你的域名/script.js" data-website-id="一串ID"></script>

把它放进你站点每个页面的 <head> 里。静态站就加到基础模板，Next.js 可以用 next/script 在根 layout 引入。这段脚本压缩后大约 2KB，比 GA 小了一个数量级，几乎不影响加载速度。上线后等几分钟，Umami 后台就能看到实时访客和页面热力，体验非常顺滑。

关键点来了：Umami 不用 cookie、不做跨站追踪，所以绝大多数司法辖区下你不需要弹同意横幅。当然，真要上线面向欧盟用户的产品，还是建议你让法务或自己核对一下当地法规，别把我的话当法律意见。但至少在技术层面，它已经把"合规"的门槛降到了最低。

自定义事件：不只是看 PV

光看页面浏览太浪费了。Umami 支持任意自定义事件，用来统计按钮点击、注册、付费转化都非常顺手。在页面里任意位置调用：

umami.track('注册按钮点击', { 位置: '首页', 套餐: 'pro' });

或者监听表单提交：

document.getElementById('signup').addEventListener('submit', () => umami.track('表单提交'));

事件名和附带的数据你会直接在 Umami 后台的 Events 栏目看到，做成漏斗、看转化都行。这对独立开发者验证"用户到底点没点我想让他点的东西"特别有用，比 GA 里一堆看不懂的维度清爽太多。

反广告拦截：用自有域名做 first-party

默认情况下，如果你直接用 Umami 官方脚本域名，部分广告拦截插件会把 analytics 请求拦掉，统计就漏了。破解思路很简单：让脚本从你自己的子域名走 first-party 请求。前面我们已经用 Caddy/Nginx 反代到 analytics.example.com，所以那段脚本的 src 本来就是你的域名，天然是 first-party，大多数拦截规则不会碰它。

如果你还想更稳，可以把 script.js 这个路径在反代里单独保留，并确保响应头不被缓存策略误伤。这样哪怕访客开了 uBlock，只要他没专门拉黑你的域名，统计基本都能回来。这点是中文圈很多教程漏讲、但实战里最影响数据完整性的细节。

实测避坑清单（别等翻车才看）

  • APP_SECRET 别每次重生成：它负责给会话令牌签名，升级或迁移时必须保持一致，否则老用户会话全失效，重启后登录态全乱。
  • 默认密码必须改：admin/umami 全网都知道，公网暴露端口等于开门迎客，第一件事就是改密码。
  • 512MB 内存要谨慎：单跑 Umami 勉强，但 Postgres 加别的同机服务很容易触发 OOM。RackNerd、Bandwagon、CloudCone 这几家的 1GB 档才比较稳。
  • 数据库记得备份：一条 pg_dump 就能导出，写个 cron 定时备份到别处，比什么都强。
  • DISABLE_TELEMETRY 建议打开：省点出站请求，也更符合隐私自托管的调性。
  • 别用 latest 漂太高：生产环境可以 pin 一个具体 tag，升级前先备份，避免大版本不兼容。

升级与日常维护：小机也能长期稳

Umami 的升级很简单，但小内存机器上要讲究顺序。先 pg_dump 把 umami 库整个导出来丢到别处，再 docker compose pull 拉新镜像，然后 docker compose up -d 重建容器。Postgres 的数据在命名卷 pgdata 里，只要不动这个卷，升级 Umami 应用层不会丢数据。我习惯在凌晨低峰做，整个切换也就几十秒，访客基本无感。

日常维护上，最该盯的是 Postgres 的体积。流量上来后 events 表会一直涨，久了查询变慢、磁盘告警。两个办法：一是在 Umami 设置里把"数据保留天数"设短一点（比如 365 天），过期的自动清理；二是写个 cron，每周把库 dump 出来压缩归档到对象存储或另一台机器。1GB 的小机磁盘通常只有 20GB，别等满了才处理。

监控方面，同机顺手跑个 Uptime Kuma 或者用 VPS 商家自带的流量/负载面板看着就行。如果你选的是 RackNerd、Bandwagon、CloudCone 这类便宜年付机，它们后台都能看到内存和带宽曲线，配合 Umami 自己的轻量占用，长期挂着基本不用操心。唯一要警惕的是 OOM——一旦发现 Postgres 被系统杀掉，第一时间加 swap 或把内存升一档，比天天手动重启靠谱。