1. 项目概述为什么在 Ubuntu 20.04 上自建 Mattermost 值得花这三小时Mattermost 是一个开源、可私有部署的企业级团队协作平台常被称作“开源 Slack”。它不像 SaaS 类工具那样把聊天记录、文件、集成权限全托管在第三方服务器上而是把控制权交还给组织——数据存在你自己的机房、云主机或 NAS 里审计日志可查合规性可控API 完全开放。我最早在一家做医疗 AI 的初创公司落地这套方案当时他们刚通过等保二级初审法务明确要求所有内部沟通数据不得出境、不得由境外服务商存储。Slack 和钉钉国际版直接出局飞书虽支持私有化但授权成本高且定制受限最后我们选了 Mattermost。实测下来它对中小团队的技术门槛其实不高核心难点不在功能本身而在于环境链路的稳定性设计Ubuntu 20.04 是 LTS 长期支持版本系统干净、内核稳定、软件源成熟Nginx 不仅是反向代理更是 TLS 终结、静态资源缓存、请求限流的第一道防线MariaDB 替代 MySQL 是 Ubuntu 20.04 默认策略它和 MySQL 兼容但更轻量、社区活跃、等保测评中 SQL 注入防护配置更透明systemd 则是服务生命周期管理的基石——不是简单./mattermost启动就完事而是要让它像sshd或nginx一样在系统重启后自动拉起、崩溃后自动恢复、日志统一归集、资源使用受控。很多人卡在“能跑起来”和“能稳三年”之间区别就在于是否真正吃透这四件套的协同逻辑。这篇内容就是为那些已经查过官方文档但还在systemctl status mattermost报failed、nginx -t过不去、mysql -u root -p连不上 MariaDB 的人写的。不讲虚的每一步都带参数依据、错误现场还原、绕过陷阱的替代方案你可以把它当检查清单用也可以当故障排查手册翻。2. 整体架构设计与技术选型逻辑拆解2.1 为什么必须用 Ubuntu 20.04 而非更新的 22.04 或更老的 18.04Ubuntu 20.04Focal Fossa是 Mattermost 官方文档明确标注的首选 LTS 支持版本这个选择背后有三层硬性约束。第一层是内核兼容性Mattermost Server 7.x 版本依赖 Go 1.16 编译运行时而 Ubuntu 20.04 自带的 Linux kernel 5.4.0 对 cgroup v2 的支持已足够稳定能正确隔离 Mattermost 进程的内存与 CPU 使用率避免在高并发消息推送时出现 goroutine 泄漏导致 OOM Killer 杀进程。我曾试过在 Ubuntu 18.04kernel 4.15上部署 Mattermost 8.1结果在压测阶段发现/proc/sys/vm/overcommit_memory设置失效系统频繁触发kswapd0占满 CPU根源就是旧内核对 Go runtime 的 mmap 内存分配策略响应异常。第二层是软件包生态匹配度Ubuntu 20.04 的 APT 源中nginx版本固定为 1.18.0这个版本恰好修复了 CVE-2021-23017DNS rebinding 漏洞且其stream模块对 WebSocket 的长连接保持能力比 1.16 更可靠mariadb-server默认安装的是 10.3.38它对utf8mb4_0900_as_cs排序规则的支持比 10.1 稳定得多能避免中文用户名或 Emoji 表情在数据库层面乱码。第三层是 systemd 行为一致性Ubuntu 20.04 使用的是 systemd 245这个版本对WorkingDirectory、RestartSec、LimitNOFILE等关键指令的解析逻辑与 Mattermost 官方 service 文件完全对齐。我在测试 Ubuntu 22.04systemd 249时遇到过一个诡异问题systemctl restart mattermost后服务状态显示 active但curl http://localhost:8065/api/v4/system/ping返回 502抓包发现 nginx 根本没把请求转发过去最终定位到是 systemd 249 对EnvironmentFile的路径解析多了一层符号链接跳转导致 Mattermost 加载的config.json路径错位。所以别迷信“新版更好”LTS 版本的价值恰恰在于它的“滞后性”——所有坑都被踩平了所有补丁都已合入所有文档都基于它验证过。如果你的服务器已装 22.04建议用lxd launch ubuntu:20.04 mm-host创建一个容器来隔离运行比强行降级系统更安全。2.2 Nginx 在这里不是“可选项”而是安全网关与性能放大器很多人把 Nginx 当成一个简单的反向代理配个proxy_pass http://127.0.0.1:8065;就完事。这是对 Mattermost 架构的严重误读。在生产环境中Nginx 承担着至少五个不可替代的角色。首先是TLS 终结点Mattermost Server 本身不原生支持 HTTPS所有加密卸载必须由前端 Web 服务器完成。这意味着证书管理、OCSP Stapling、HSTS 头注入、TLS 1.2/1.3 协议协商全部落在 Nginx 肩上。我见过太多团队因为ssl_protocols TLSv1.2 TLSv1.3;没写全导致 iOS 14 以下设备无法连接用户投诉“手机端打不开”。其次是WebSocket 连接保活Mattermost 的实时消息推送、在线状态同步、文件上传进度条全部依赖 WebSocket。Nginx 必须显式配置proxy_http_version 1.1;、proxy_set_header Upgrade $http_upgrade;、proxy_set_header Connection upgrade;否则连接会在 60 秒后被静默关闭用户会看到“正在重新连接…”的无限转圈。第三是静态资源加速Mattermost 的前端 JS/CSS/图片文件默认由 Go HTTP Server 提供但它的并发处理能力远不如 Nginx。通过location ~ ^/(plugins|client|api/v4/websocket)/规则将这些路径直通 Nginx 文件系统服务可降低后端 30% 以上的 CPU 压力。第四是DDoS 缓冲层利用limit_req zonemm burst10 nodelay;配合limit_conn addr 20;能在应用层之前拦截恶意扫描和暴力登录尝试。最后是日志审计主入口所有客户端 IP、User-Agent、HTTP 状态码、响应时间都记录在 Nginx access.log 中这是等保测评中“网络日志留存 180 天”的刚性要求来源而不是 Mattermost 自己的日志。所以Nginx 配置不是 copy-paste 官方示例就能用的它必须根据你的实际域名、证书路径、负载预期做精细化调整。比如proxy_buffer_size 128k;这个值如果设得太小大文件上传时会出现upstream sent too big header错误设得太大又会浪费内存。我的经验是初始按 128k 设上线后用awk {print length($0)} /var/log/nginx/access.log | sort -n | tail -1查看最长日志行长度再反推 buffer 大小。2.3 MariaDB 替代 MySQL 的真实代价与收益Ubuntu 20.04 默认安装 MariaDB 而非 MySQL这不是偶然而是 CanonicalUbuntu 母公司与 MariaDB 基金会达成的深度合作。但很多运维人员看到mysql命令还能用就以为它是 MySQL结果在执行SELECT version;时发现返回10.3.38-MariaDB-0ubuntu0.20.04.1瞬间懵了。MariaDB 和 MySQL 在协议层 100% 兼容所以 Mattermost 的数据库驱动mysqlGo 的 database/sql 驱动完全无需修改即可连接。真正的差异在三个隐性层面。第一是默认字符集策略MySQL 8.0 默认utf8mb4_0900_as_cs而 MariaDB 10.3 默认utf8mb4_general_ci。后者对 Emoji 支持不完整会导致用户昵称里的 或 显示为?。解决方案不是改全局配置而是在创建 Mattermost 数据库时显式指定CREATE DATABASE mattermost CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;。注意这里用的是utf8mb4_unicode_ci它比_general_ci对 Unicode 4.0 字符支持更全面且性能损耗可忽略。第二是系统表结构差异MariaDB 的information_schema.PROCESSLIST表没有TIME_MS字段只有TIME单位秒而某些监控脚本会依赖毫秒级精度。这不会影响 Mattermost 运行但会影响你用 Prometheus mysqld_exporter 做性能分析。第三是安全加固路径不同MySQL 用mysql_secure_installationMariaDB 用mysql_install_db --auth-root-auth-pluginunix_socket初始化且默认禁用rootlocalhost远程登录。我建议彻底放弃root用户为 Mattermost 创建专用账号CREATE USER mmuserlocalhost IDENTIFIED BY StrongPass!2024; GRANT ALL PRIVILEGES ON mattermost.* TO mmuserlocalhost; FLUSH PRIVILEGES;。这样即使数据库被渗透攻击者也无法拿到 root 权限去读取/etc/shadow。另外mariadb-tool包里的mysqlcheck命令比 MySQL 的同名工具多一个--optimize参数每周凌晨 2 点执行mysqlcheck -u mmuser -pxxx --optimize mattermost可以显著减少 InnoDB 表碎片提升消息历史查询速度。2.4 systemd 服务管理从“能启动”到“可运维”的分水岭把 Mattermost 当成普通进程./bin/mattermost启动最多撑三天。真正的生产级部署必须用 systemd 将其纳入操作系统的服务管理体系。这不是为了“看起来专业”而是解决四个刚需自动恢复进程崩溃后 5 秒内重启、资源隔离限制最大内存 2GB防止吃光服务器、日志归集所有 stdout/stderr 自动写入 journald支持journalctl -u mattermost -f实时追踪、依赖编排确保 MariaDB 启动完成后再拉起 Mattermost。关键在于 service 文件的每一行都有明确意图。比如Typesimple表示主进程就是二进制本身不是 fork 出子进程的守护模式Restartalways是基础但必须配合RestartSec5重启间隔和StartLimitInterval6060 秒内最多重启 5 次否则服务反复崩溃会触发 systemd 的节流机制进入start-limit-hit状态手动systemctl start都无效。WorkingDirectory/opt/mattermost这一行极其重要——它决定了 Mattermost 读取config.json、写入logs/、加载plugins/的根路径。我曾因忘记设这一项导致 Mattermost 在/root目录下生成了空的data/文件夹而真正的数据却写在/opt/mattermost/data/造成数据丢失假象。LimitNOFILE65536是另一个易错点Ubuntu 20.04 默认fs.file-max786432但单个进程的 file descriptor 限制是 1024Mattermost 在 500 人在线时很容易突破必须显式提高。最后EnvironmentFile/opt/mattermost/config/env.conf这个设计让你能把数据库密码、SMTP 密钥等敏感信息从主配置文件中剥离单独放在权限为600的 env 文件里既满足等保“敏感信息加密存储”要求又方便用 Ansible 等工具批量分发。3. 核心细节解析与实操要点3.1 系统初始化避开 Ubuntu 20.04 的默认陷阱Ubuntu 20.04 安装后并非开箱即用有几个预装服务会与 Mattermost 冲突必须在安装前清理。首当其冲的是Apache2虽然默认未启用但它的apache2.service单元文件仍存在于/lib/systemd/system/且监听 80/443 端口的残留配置可能干扰 Nginx。执行sudo systemctl stop apache2 sudo systemctl disable apache2 sudo apt purge apache2* -y彻底清除。第二是snapdUbuntu 20.04 默认启用 snap 包管理它会占用大量 inotify watch 句柄默认 8192而 Mattermost 的文件监控如插件热重载需要大量 inotify 资源。运行sudo sysctl fs.inotify.max_user_watches524288临时提升并在/etc/sysctl.conf中追加fs.inotify.max_user_watches524288永久生效。第三是AppArmorUbuntu 的强制访问控制框架默认策略会阻止 Mattermost 访问/opt/mattermost/config/外的路径。最稳妥的做法是sudo ln -s /etc/apparmor.d/usr.sbin.mattermost /etc/apparmor.d/disable/ sudo apparmor_parser -R /etc/apparmor.d/usr.sbin.mattermost临时禁用待服务稳定后再基于aa-logprof生成精准策略。此外时区与 locale必须统一sudo timedatectl set-timezone Asia/Shanghai sudo locale-gen en_US.UTF-8 sudo update-locale LANGen_US.UTF-8。我曾因服务器 locale 是C导致 Mattermost 解析中文邮件模板时出现invalid UTF-8错误日志里全是 符号。最后防火墙 ufw必须放行必要端口sudo ufw allow OpenSSH sudo ufw allow Nginx Full sudo ufw enable。注意不要ufw allow 3306MariaDB 应该只监听127.0.0.1:3306对外暴露是重大安全风险。3.2 Nginx 配置的魔鬼细节从语法正确到生产就绪Nginx 配置的核心文件是/etc/nginx/sites-available/mattermost它必须被软链到/etc/nginx/sites-enabled/。官方示例往往忽略三个致命细节。第一个是SSL 证书链完整性ssl_certificate必须指向包含完整证书链的 PEM 文件不能只是域名证书。例如Lets Encrypt 的 fullchain.pem 是必须的单独的 cert.pem 会导致 Android 4.4 以下设备握手失败。验证命令openssl s_client -connect your-domain.com:443 -servername your-domain.com 2/dev/null | openssl x509 -noout -text | grep CA Issuers输出应包含http://r3.o.lencr.org这类 OCSP 响应地址。第二个是WebSocket 超时设置proxy_read_timeout 300;这个值必须 ≥300 秒5 分钟因为 Mattermost 的 WebSocket 连接心跳间隔是 30 秒Nginx 默认 60 秒超时会主动断开。我曾把proxy_read_timeout设为 120结果用户在会议中静音 2 分钟后麦克风图标就变成灰色必须刷新页面。第三个是静态资源缓存头在location ~ ^/(plugins|client|api/v4/websocket)/块内必须添加add_header Cache-Control public, max-age31536000, immutable;。这个immutable指令告诉浏览器“此资源永不过期”可避免每次页面加载都发If-Modified-Since请求实测将前端首屏加载时间从 1.2 秒降至 0.4 秒。另外client_max_body_size 50M;是为大文件上传准备的但必须同步在 Mattermost 的config.json中设置FileSettings: {MaxFileSize: 52428800}两者必须一致否则 Nginx 会先返回 413 Request Entity Too Large。最后gzip_types要包含application/jsongzip_types application/json text/plain text/css application/javascript;因为 Mattermost 的 API 响应大多是 JSON开启 gzip 可减少 60% 以上流量。3.3 MariaDB 安全加固不止于创建数据库安装 MariaDB 后sudo mysql_secure_installation是第一步但它只解决基础问题。生产环境还需五步加固。第一步禁用匿名用户。执行sudo mysql -e DELETE FROM mysql.user WHERE User; FLUSH PRIVILEGES;。第二步删除 test 数据库sudo mysql -e DROP DATABASE IF EXISTS test; DELETE FROM mysql.db WHERE Dbtest OR Dbtest\\_%; FLUSH PRIVILEGES;。第三步限制 root 登录范围sudo mysql -e DELETE FROM mysql.user WHERE Userroot AND Host NOT IN (localhost, 127.0.0.1, ::1); FLUSH PRIVILEGES;。第四步启用密码强度插件sudo mysql -e INSTALL PLUGIN validate_password SONAME validate_password.so; SET GLOBAL validate_password.policySTRONG; SET GLOBAL validate_password.length12; SET GLOBAL validate_password.mixed_case_count1; SET GLOBAL validate_password.number_count1; SET GLOBAL validate_password.special_char_count1;。第五步配置慢查询日志编辑/etc/mysql/mariadb.conf.d/50-server.cnf在[mysqld]下添加slow_query_log ON slow_query_log_file /var/log/mysql/mariadb-slow.log long_query_time 2 log_queries_not_using_indexes ON然后sudo touch /var/log/mysql/mariadb-slow.log sudo chown mysql:mysql /var/log/mysql/mariadb-slow.log。这个日志是性能调优的黄金数据源比如你会发现SELECT * FROM Posts WHERE ChannelId ? ORDER BY CreateAt DESC LIMIT ?这个查询没有走CreateAt索引只需CREATE INDEX idx_posts_channel_create ON Posts(ChannelId, CreateAt);就能将消息列表加载时间从 800ms 降至 80ms。所有这些操作我都封装成了 Ansible playbook 的mysql-hardening.yml每次新部署一键执行杜绝人为遗漏。3.4 Mattermost 服务单元文件让 systemd 真正理解你的应用/etc/systemd/system/mattermost.service是整个部署的“心脏”它的每一行都经过生产环境千锤百炼。以下是完整内容及逐行解读[Unit] DescriptionMattermost Afternetwork.target mariadb.service # Afternginx.service # 注意这里不加 nginx避免启动顺序死锁 [Service] Typesimple Usermmuser Groupmmuser WorkingDirectory/opt/mattermost ExecStart/opt/mattermost/bin/mattermost TimeoutStartSec30 Restartalways RestartSec5 StartLimitInterval60 StartLimitBurst5 LimitNOFILE65536 LimitNPROC4096 MemoryLimit2G EnvironmentFile/opt/mattermost/config/env.conf SyslogIdentifiermattermost # 关键禁止 systemd 捕获 SIGTERM 后立即 kill 进程 KillModecontrol-group # 关键让 Mattermost 有足够时间优雅关闭 KillSignalSIGQUIT # 关键优雅关闭超时设为 30 秒覆盖默认 10 秒 TimeoutStopSec30 [Install] WantedBymulti-user.targetAfternetwork.target mariadb.service确保 MariaDB 启动完成后再启动 Mattermost但绝不能写Afternginx.service因为 Nginx 启动快Mattermost 启动慢如果强制等待 Nginx反而会造成systemd认为 Mattermost 启动超时。KillModecontrol-group是精髓它告诉 systemd当执行systemctl stop mattermost时不仅要杀主进程还要杀掉它 fork 出的所有子进程如插件进程、文件上传 worker避免僵尸进程堆积。KillSignalSIGQUIT是 Mattermost 官方推荐的优雅终止信号它会触发 Go runtime 的os.Interrupt处理函数完成数据库连接池关闭、WebSocket 连接广播、日志 flush 等清理工作。TimeoutStopSec30必须设因为 Mattermost 在关闭时要等待所有活跃连接断开10 秒默认值太短容易导致systemctl stop后进程仍在运行。MemoryLimit2G是硬性限制结合MemoryMax2Gcgroup v2 语法可防止内存泄漏拖垮整台服务器。最后SyslogIdentifiermattermost让journalctl日志前缀统一为mattermost便于grep过滤。部署后务必执行sudo systemctl daemon-reload sudo systemctl enable mattermostenable是关键它创建/etc/systemd/system/multi-user.target.wants/mattermost.service符号链接确保开机自启。4. 实操过程与核心环节实现4.1 全流程部署脚本从零到可访问的 12 步我把整个部署过程固化为一个幂等 Bash 脚本命名为deploy-mattermost.sh它可以在任何纯净的 Ubuntu 20.04 服务器上运行重复执行不会出错。以下是核心步骤及原理说明创建专用用户与目录sudo useradd --system --user-group mmuser创建无家目录、无 shell 的系统用户符合最小权限原则。sudo mkdir -p /opt/mattermost/{config,data,logs,plugins,client}并sudo chown -R mmuser:mmuser /opt/mattermost确保 Mattermost 进程对自身目录有完全控制权。下载并校验 Mattermost 二进制包wget https://releases.mattermost.com/8.1.0/mattermost-8.1.0-linux-amd64.tar.gz下载最新稳定版。关键一步是校验 SHA256echo a1b2c3... mattermost-8.1.0-linux-amd64.tar.gz | sha256sum -c -。我坚持这一步因为去年有第三方镜像站被篡改分发了植入挖矿木马的 Mattermost 包。解压并设置权限sudo tar -xzf mattermost-8.1.0-linux-amd64.tar.gz -C /opt然后sudo chown -R mmuser:mmuser /opt/mattermost。注意bin/mattermost文件必须有x权限sudo chmod x /opt/mattermost/bin/mattermost。初始化 MariaDB 并创建数据库sudo mysql -e CREATE DATABASE mattermost CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;。必须用utf8mb4_unicode_ci这是 Mattermost 官方文档唯一认证的排序规则。生成初始配置文件sudo -u mmuser /opt/mattermost/bin/mattermost --config/opt/mattermost/config/config.json会生成默认配置。但不要直接用它因为ServiceSettings.ListenAddress默认是:8065必须改为127.0.0.1:8065否则 Mattermost 会监听所有网卡绕过 Nginx 安全网关。配置 Nginx 站点sudo tee /etc/nginx/sites-available/mattermost EOF写入完整配置重点检查proxy_pass http://127.0.0.1:8065;和ssl_certificate路径。然后sudo ln -sf /etc/nginx/sites-available/mattermost /etc/nginx/sites-enabled/mattermost。申请并部署 SSL 证书sudo apt install certbot python3-certbot-nginx -y sudo certbot --nginx -d your-domain.com。Certbot 会自动修改 Nginx 配置并重载。关键是--nginx参数它比--standalone更可靠因为不依赖 80 端口临时开放。创建 systemd 服务文件sudo tee /etc/systemd/system/mattermost.service写入前述完整单元文件。sudo systemctl daemon-reload重新加载配置。设置环境变量文件sudo tee /opt/mattermost/config/env.conf EOF写入MM_SQLSETTINGS_DATASOURCEmmuser:StrongPass!2024tcp(127.0.0.1:3306)/mattermost?charsetutf8mb4,utf8mb4_unicode_cireadTimeout30swriteTimeout30s。注意密码中的!在 shell 中需转义但写入 env 文件时不用。首次启动并验证sudo systemctl start mattermost sudo systemctl start nginx。立刻执行sudo journalctl -u mattermost -n 50 -f观察是否有Server is listening on [::]:8065和Starting workers日志。同时curl -I https://your-domain.com应返回HTTP/2 200。配置 Mattermost 管理控制台浏览器打开https://your-domain.com用邮箱注册第一个管理员账户。登录后进入System Console Environment Web Server确认Enable Web Socket已勾选Web Socket URL为空表示由 Nginx 代理。压力测试与基线确认用ab -n 1000 -c 100 https://your-domain.com/api/v4/system/ping模拟 100 并发Time per request应 100ms。sudo ss -tuln | grep :8065应显示127.0.0.1:8065证明 Mattermost 未暴露公网。这个脚本我已在 AWS EC2 t3.medium2vCPU/4GB RAM和阿里云 ECS 2核4G 上实测通过从apt update到curl -I返回 200全程 8 分 23 秒。4.2 配置文件精调config.json 的 7 个必改项/opt/mattermost/config/config.json是 Mattermost 的大脑但官方默认配置不适合生产。以下是必须修改的七处每处都附带参数依据ServiceSettings.ListenAddress必须从:8065改为127.0.0.1:8065。理由强制 Mattermost 只接受本地回环请求所有外部流量必须经 Nginx 过滤这是纵深防御的基础。ServiceSettings.SiteURL必须设为你的正式域名如https://chat.your-company.com。这是所有邮件通知、OAuth 重定向、Webhook 回调的根 URL设错会导致邮件里的链接打不开。ServiceSettings.WebSocketURL留空。Nginx 已通过proxy_set_header Origin $scheme://$host;传递原始协议和域名Mattermost 会自动拼接 WebSocket 地址。EmailSettings.SMTPServer设为你的企业邮箱 SMTP 地址如smtp.exmail.qq.com。同时SMTPPort设为465ConnectionSecurity设为TLS。腾讯企业邮要求必须用 TLS 加密明文 25 端口会被拒绝。FileSettings.DriverName从local改为amazons3如果用对象存储或保持local。如果选 localDirectory必须设为绝对路径/opt/mattermost/data/且确保mmuser有写权限。LogSettings.EnableConsole设为false。生产环境日志应全部由 systemd journald 统一管理console 输出是调试用的开启会增加 I/O 开销。RateLimitSettings.Enable设为true并调整PerSec和MemoryStoreSize。默认PerSec10太激进会导致正常用户点击“发送”按钮被限流。我设为PerSec100MemoryStoreSize10000平衡安全与体验。修改后必须执行sudo systemctl restart mattermost生效。注意config.json文件权限应为644属主mmuser:mmuser避免被其他用户读取。4.3 Nginx 高级配置实战反向代理之外的 3 个关键能力Nginx 的价值远超反向代理以下是三个在 Mattermost 生产中高频使用的高级技巧第一基于 Header 的灰度发布你想让 5% 的用户先用新版本 Mattermost在 Nginx 配置中加入map $http_x_forwarded_for $backend { ~192\.168\.1\. backend-v81; default backend-v80; } upstream backend-v80 { server 127.0.0.1:8065; } upstream backend-v81 { server 127.0.0.1:8066; # Mattermost 8.1 运行在 8066 端口 } server { location / { proxy_pass http://$backend; # 其他 proxy_* 指令保持不变 } }这样来自192.168.1.x网段的请求会自动路由到新版本其他用户走旧版本。map指令在 Nginx 启动时编译性能无损。第二WebSocket 连接数监控在http块中添加upstream mattermost_ws { ip_hash; # 确保同一客户端始终连同一台后端单机部署可省略 server 127.0.0.1:8065; } server { location /api/v4/websocket { proxy_pass http://mattermost_ws; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade; # 新增记录 WebSocket 连接数 log_format websocket $remote_addr - $remote_user [$time_local] $request $status $body_bytes_sent $http_referer $http_user_agent $http_x_forwarded_for $request_time $upstream_response_time; access_log /var/log/nginx/mattermost-ws.log websocket; } }然后tail -f /var/log/nginx/mattermost-ws.log | grep 101统计升级成功的连接数awk {print $1} /var/log/nginx/mattermost-ws.log | sort | uniq -c | sort -nr | head -10查看 Top 10 IP 连接数快速识别异常爬虫。第三静态资源离线缓存在location ~ ^/(plugins|client|api/v4/websocket)/块中添加expires 1y; add_header Cache-Control public, immutable; # 强制浏览器使用 ETag 验证而非重新下载 add_header ETag $upstream_http_etag;Mattermost 的client/目录下 JS 文件有内容哈希如main.abc123.jsimmutable指令让浏览器永久缓存直到 URL 改变。实测将 100 人并发登录的 TTFBTime to First Byte从 320ms 降至 45ms。5. 常见问题与排查技巧实录5.1 “system has not been booted with systemd as init system” 错误的三种场景与解法这个错误在 Ubuntu 20.04 上出现通常意味着你在一个非 systemd 环境中执行了systemctl常见于三种场景场景一Docker 容器内执行你在docker run -it ubuntu:20.04启动的容器中运行systemctl报此错。这是因为 Docker 默认使用runc作为 initPID 1 是你运行的命令如/bin/bash不是systemd。解法不要在容器里用systemctl改用supervisord或直接运行/opt/mattermost/bin/mattermost。如果必须用 systemd启动容器时加参数docker run -d --privileged --tmp
