自托管网站统计 Umami：个人博客接入实时数据后，用 cpolar 临时给运营/客户查看访问面板-酒店常州论坛

自托管网站统计 Umami：个人博客接入实时数据后，用 cpolar 临时给运营/客户查看访问面板

个人博客上线以后，最容易被忽略的一件事不是页面是否够漂亮，而是有没有人真的打开过。文章发出去后，站长会关心访问量、访问来源、热门页面；运营同事会关心活动链接有没有流量；客户验收落地页时，也经常会问一句：现在能不能看一下实时访问数据？

如果只是做个人站、活动页、小型官网，完全可以把网站统计系统放在自己机器或 NAS 上跑。Umami 是一个轻量的开源网站统计工具，支持实时访客、页面浏览、来源、设备、地域等常用指标。本文演示用 Docker 在本地部署 Umami，把统计脚本接入一个简单 HTML 页面，再用 cpolar 临时开放一个 HTTPS 地址，让运营或客户远程查看访问面板。验收结束后关闭隧道，数据仍然留在本地。

本文只使用演示数据。后台账号请设置强密码；cpolar 只在验收窗口短时开放；数据库端口不暴露；不要公开 Docker socket；演示结束后关闭隧道并修改演示账号密码。

一、准备环境与目录

本文使用一台已经安装 Docker 和 Docker Compose 的本地机器。Umami 面板只监听本机地址，避免直接暴露到局域网或公网。目录结构如下：

mkdir -p ~/umami-demo cd ~/umami-demo

新建.env文件，用来放数据库密码和应用密钥。这里写占位值，实际部署时请替换成随机强密码和随机字符串，不要复用截图、教程或团队聊天里出现过的内容。

cat > .env <<'EOF' POSTGRES_PASSWORD=replace_with_a_strong_database_password DATABASE_URL=postgresql://umami:replace_with_a_strong_database_password@db:5432/umami APP_SECRET=replace_with_a_long_random_app_secret EOF

接着创建docker-compose.yml。注意umami服务的端口绑定是127.0.0.1:3000:3000，数据库服务没有ports字段，因此 PostgreSQL 只在 Docker 内部网络中供 Umami 访问，不会被直接暴露出来。

services: db: image: postgres:15-alpine container_name: umami-db restart: unless-stopped environment: POSTGRES_DB: umami POSTGRES_USER: umami POSTGRES_PASSWORD: ${POSTGRES_PASSWORD} volumes: - umami-db-data:/var/lib/postgresql/data healthcheck: test: ["CMD-SHELL", "pg_isready -U umami -d umami"] interval: 10s timeout: 5s retries: 5 umami: image: ghcr.io/umami-software/umami:postgresql-latest container_name: umami-web restart: unless-stopped depends_on: db: condition: service_healthy environment: DATABASE_URL: ${DATABASE_URL} DATABASE_TYPE: postgresql APP_SECRET: ${APP_SECRET} ports: - "127.0.0.1:3000:3000" volumes: umami-db-data:

启动服务：

docker compose up -d

查看容器状态：

docker compose ps

浏览器打开：

http://127.0.0.1:3000

进入后台后，第一件事是完成管理员账号初始化或修改初始密码。不要把后台账号写进脚本，也不要把账号密码发给无关人员。后面给运营或客户看面板时，建议创建一个临时演示账号，只授予查看所需站点数据的权限。

二、在 Umami 中添加个人博客站点

Name：My Blog Demo
Domain：blog.example.local
Timezone：选择站点主要受众所在时区

保存后，Umami 会生成一段 tracking script。脚本形式类似下面这样，其中data-website-id是每个站点独有的 ID，请以后台实际生成的值为准。

<script defer src="http://127.0.0.1:3000/script.js">
三、创建一个简单 HTML 页面并接入统计脚本
为了让流程更直观，我们用一个简单页面模拟个人博客文章页。新建site目录：
mkdir -p site cat > site/index.html <<'EOF' <!doctype html> <html lang="zh-CN"> <head> <meta charset="utf-8"> <meta name="viewport" content="width=device-width, initial-scale=1"> <title>我的博客演示页</title> <script defer src="http://127.0.0.1:3000/script.js">cd site python3 -m http.server 8080 --bind 127.0.0.1
浏览器访问：
http://127.0.0.1:8080/index.html
多刷新几次首页，再打开关于页。回到 Umami 面板，可以看到页面浏览数据开始出现。实时页面里会显示当前访问；统计页里能看到页面路径、Referrer、浏览器、操作系统、设备类型、国家和地区等信息。对于个人博客，这些指标已经足够判断一篇文章有没有被打开、用户从哪里来、哪些页面更受关注。
如果你想演示来源统计，可以从另一个本地页面放一个链接跳转到博客页，或在浏览器地址栏追加 UTM 参数，例如：
http://127.0.0.1:8080/index.html?utm_source=demo&utm_medium=review&utm_campaign=umami
这样在 Umami 中查看来源和活动参数时，运营同事能直接看到演示访问是从哪个渠道进入的。演示时建议使用清晰的测试命名，例如demo、review、client_check，不要混入真实客户名称、真实投放渠道或生产数据。
四、用 cpolar 临时开放 Umami 面板
本地部署完成后，运营或客户如果不在同一台机器上，就无法直接打开127.0.0.1:3000。这时可以用 cpolar 建一个临时 HTTPS 隧道，只把 Umami Web 面板转发出去。数据库仍然不暴露，Docker socket 也不暴露。
先确认本机 Umami 正常：
curl -I http://127.0.0.1:3000
启动 cpolar 隧道：
cpolar http 3000
cpolar 会生成一个临时公网 HTTPS 地址。把这个地址发给运营或客户前，先用无痕窗口打开，确认进入的是 Umami 登录页，而不是其他本地服务。然后提供临时演示账号，让对方只查看本次演示站点的数据。
验收时可以按这个顺序讲解：
打开实时页面，现场刷新博客页，观察实时访客变化。
打开页面统计，查看/index.html与/about.html的浏览量。
查看来源、设备、浏览器、地域分布，说明这些都是演示访问数据。
打开时间范围筛选，切换今天、最近 24 小时或自定义时间段。
如果客户只关心结果，不需要进入设置页，就不要展示站点配置和账号管理页面。
这里要特别注意：cpolar 开放的是 Umami 面板，不是数据库端口，也不是 Docker 管理端口。不要把5432、Docker API、SSH、NAS 管理后台一起暴露出去。隧道只服务于一次验收；讲解结束后立即关闭。
五、运营/客户验收时怎么讲得清楚
很多站长在演示统计系统时，会陷入技术细节：脚本怎么加载、容器怎么编排、数据库怎么存储。对运营或客户来说，更重要的是数据能回答什么问题。可以围绕下面几个点演示：
实时访问：现在是否有人打开页面，刷新后数据是否更新。
页面浏览：哪篇文章、哪个落地页被访问得更多。
访问来源：用户从直接访问、外部链接、活动参数中的哪个入口进入。
地域与设备：访问者大致来自哪些地区，主要使用桌面端还是移动端。
时间筛选：今天、最近几天、活动期间的数据是否能分开查看。
如果对方只需要验收截图，可以在本地生成截图后发送；如果对方需要自己点开筛选，就使用临时账号加 cpolar 短时开放。不要为了方便把管理员账号长期共享出去，也不要把隧道地址贴到公开群、文章评论区或工单附件里。
六、正式使用前的落地建议
演示跑通以后，如果准备把 Umami 用在长期博客或小型官网上，建议把“演示环境”和“正式环境”分开处理。演示环境只用于给运营、客户看流程，数据命名保持简单；正式环境则需要配置稳定域名、HTTPS、备份策略和账号权限。这样做的好处是边界清楚：演示时产生的刷新、测试点击、验收访问不会污染正式报表，正式报表也不会因为一次远程讲解而暴露给无关人员。
对于个人博客，最实用的做法是把 tracking script 放到主题模板的公共头部或底部，例如head.html、footer.html、layout.html这类文件。这样新增文章时不需要每篇手工粘贴脚本，后续如果要停用统计，也只需要从模板里删除一次。对于临时活动页，则可以单独建一个 Website，活动结束后保留报表截图和导出数据，再停用页面脚本。
数据解读也要克制。Umami 能帮助你看到访问趋势、热门页面和来源分布，但不要把一次短时间演示里的刷新量当成正式效果。给客户验收时，可以明确说明：当前面板展示的是演示访问，用来确认统计链路已经打通；正式上线后的效果评估，以真实投放周期和生产页面数据为准。
七、常见问题处理
1. 页面刷新了，但 Umami 没有数据
先检查 HTML 里的data-website-id是否替换成后台生成的站点 ID，再打开浏览器开发者工具，看script.js是否加载成功。演示环境中，博客页面和 Umami 都跑在本机，脚本地址应保持为http://127.0.0.1:3000/script.js。
2. cpolar 地址打开后访问不到面板
确认 Umami 容器正在运行，并且本机可以打开http://127.0.0.1:3000。如果本机都打不开，先处理 Docker 服务；如果本机能打开，再重启 cpolar 隧道并复制新的 HTTPS 地址。
3. 不想让客户看到管理设置
创建临时演示账号，只给需要查看的站点权限。演示结束后改密码或删除账号。客户只需要看统计结果时，不要使用管理员账号进行远程演示。
4. 演示页面后续不用统计了
从 HTML 或博客模板中移除 tracking script，重新部署页面。Umami 中保留历史演示数据即可，后续页面不会继续上报访问。
临时开放后的收尾清单
关闭 cpolar 隧道，确认临时 HTTPS 地址已经无法访问 Umami 面板。
修改临时演示账号密码，或直接删除演示账号。
确认 Umami 后台管理员账号使用强密码，并且没有共享给外部人员。
确认 PostgreSQL 没有ports暴露配置，数据库端口没有对外开放。
确认没有公开 Docker socket、SSH 或 NAS 管理后台。
确认统计脚本可移除：如果演示页面不再需要统计，从 HTML 或博客模板删除 tracking script。
清理演示数据命名，避免把真实客户名称、真实渠道和生产访问混在演示站点里。
用 Umami 做个人博客统计的价值在于：部署轻、数据在自己手里、面板足够直观。再配合 cpolar 的短时访问能力，远程验收不需要临时搭公网服务器，也不需要把数据库或后台管理口暴露出去。流程跑通以后，个人站长可以用它观察文章访问，小团队也可以用它给运营和客户做清晰、可控的流量说明。

企业官网建设流程全解析