网站统计分析开源系统：新手最容易卡在部署

装这类东西的人，最后大多不是被系统本身难住的。卡你的往往是旁边那一圈：数据库、反向代理、证书，还有那条要粘到页面里的脚本。网站统计分析开源系统——Matomo、Umami、Plausible、GoAccess 这些——代码本身不复杂，难的是把它塞进一台已经跑了别的服务的机器里，还得让它安安静静地收数据。

网站统计分析开源系统，为什么偏偏栽在部署这步

它天生是个全家桶。要写数据库、要跑定时任务、要开一个上报接口、还要跨域接收来自别的站点的请求。你在本机一条 docker compose up 跑起来觉得挺顺，换成公网机器，端口、安全组、域名解析、HTTPS、防火墙规则一起压上来，随便哪一环没对齐就起不来。而且它不像博客，博客挂了顶多打不开，统计系统挂了你是看不到数据，还容易以为是系统坏了，转头去重装。

另一个锅得算在教程头上。网上搜到的部署步骤，十篇里有八篇的前置条件跟你的机器不一样——人家是全新系统，你是跑着别的站的；人家的机器内存宽裕，你是一台小配置。照抄命令，报错自然就来了，然后你开始怀疑自己手笨，其实不是。

容器还是源码，第一天就得定下来

新手我一般建议先走容器。省事，依赖不用管，卸载也干净。但容器有个必须先想清楚的事——数据往哪放。数据库、上传目录、配置文件，这三样没挂到宿主机上，容器一重建就全清零了。compose 文件里那几个 volumes，看着不起眼，出事的时候就是命。

源码装适合愿意折腾的人，好处是所有文件路径你都看得见，改配置、看日志不用先 docker exec 钻进去。坏处是依赖版本会整你，尤其 PHP 那一套扩展，缺一个页面就是白屏。要是连 SSH 都不太熟，这条路先别选。

还有个小地方容易漏：容器里的端口要映射出来，宿主机的防火墙也要放行，云厂商那边还有一层安全组。三层里少开一层，浏览器就是连不上，报的还是超时，看不出到底是哪层拦的。

数据库这一步，别凭感觉挑

这几个项目挑的库完全不一样：Matomo 走 MySQL 或 MariaDB，Umami 要 PostgreSQL，Plausible 挂在 ClickHouse 上。看到有人写 ClickHouse 查询快就往小机器上装，内存被吃干净，机器连 SSH 都卡。选库的标准不是快，是你的机器扛不扛得住，还有你熟不熟。文档里写的最低配置，一般指能跑起来，不是你放上真实流量之后还能跑。拿不准就按官方文档的推荐配置来，别按别人博客里的来。

反向代理这一段，抄错一个斜杠就白干

Nginx 反代是最多人翻车的地方。proxy_pass 后面带不带斜杠，路径完全不同；Host 头没传过去，应用就不知道自己被哪个域名访问，生成的链接全是内网地址；上报接口是 POST，body 大小被 client_max_body_size 的默认值卡住，表现就是偶尔丢数据，很难查。还有 WebSocket，实时面板那块不 upgrade 就一直转圈。

HTTPS 别忘了自动续期。证书过期那天你会发现统计断了一段，还以为是程序崩了，其实是浏览器直接把请求拦了。

统计脚本放哪，比装系统更容易被漏掉

系统装好只是第一步，真正决定有没有数据的是那段几行的脚本。它得放进全站公共的模板里，比如页脚那块，不是只贴首页。有缓存插件的站，记得清一次缓存，不然老访客拿到的还是没脚本的旧页面。开了 CSP 的站，要把上报域名加到允许列表里，不然控制台一屏红字，数据一条不来。

还有一种情况：数据天然偏低。不少访客装了拦截插件，统计请求直接就被拦住了。这不是你装错了，换哪家都差不多，别为了追这个数字去折腾。

面板一片空白，先别急着重装

顺序应该是这样：先在浏览器网络面板里看那条脚本请求发出去没有、返回什么状态码；再看服务端的访问日志里有没有这条请求，报的什么错；然后去数据库里看有没有记录写进去。三步走下来问题基本就定位了。上来就重装，等于把线索全删了，第二遍还是同一个坑。

机器小的话，这几样可以先砍

报告预生成关掉，改成打开时按需算；日志保留天数缩短；定时任务挪到深夜；采样率调低一点。历史数据要留就别堆在本机上，扔对象存储去。这些做完，一台不大的机器跑一个中小站的统计是够的，没必要一上来就追高配。

多站点和子域名，提前想一步

手里不止一个站的，部署时就把多站点模式想好。后面再加一个域名，往往要回头改配置、重新生成脚本、重新走一遍证书流程，比一开始就规划好多花不少时间。子域名也是一样，主域名和 www 在统计里默认算两个来源，要不要合并成一个站点，装之前定，装完再改就得动历史数据了。

最后提醒一句：部署完当天最好别急着关终端。让它跑上一两天，看看内存曲线、看看日志有没有反复报错、看看统计后台的数字和你服务器访问日志对不对得上。这一步花的时间，比装系统本身值。