标签：umami

快速查阅如何加载 Umami、追踪按钮触发的自定义事件，以及确认 `window.umami` 已可用。

我想给博客加上第一方访问分析，又不想把流量数据交给 SaaS 厂商。Umami 完全符合需求：开源、可自托管、尊重隐私。我本来就有一台全天在线的小型 VPS，分出一点资源给 Umami，感觉正合适。

关掉常见的追踪器后，访问分析就成了盲区。我需要一个这样的方案：

Umami + Ansible 那篇文章，我在脑子里酝酿了很久，但它涉及三个不同的仓库和一大堆代码片段。做得来，却也确实繁琐，所以一直被往待办列表后面推。完成后的文章在这里：用 Umami、Docker Compose 和 Ansible 搭建私有分析服务。

最终推动它落地的想法很简单：何不让 GPT（Codex）负责繁重工作，由我把握方向？

最近，我在 VPS 上用 Docker 和 Nginx 配好 Umami 几小时后，发现一个配置错误把管理后台暴露到了公网。幸好没有立即造成危险。我在创建 Umami 的 Docker 实例后就马上修改了管理员用户名和密码，也在出事之前收紧了访问权限。不过，这仍然让我紧张了一阵：部署时的小失误，后果可能很大。

下面说说事情的经过，以及我从中学到的东西。

今天大半天，我都在让 Umami 统计与一个经过 Cloudflare 和 Nginx 代理的静态博客配合起来。追踪脚本在 Safari 中有 CORS 问题，而在 Firefox 中，开发者工具的 Network 标签页什么也看不到。

这篇记录了我如何沿着线索，从神秘重定向追到幽灵般的 CORS 问题，最后找到 Firefox 隐身的 sendBeacon API。