MkSaaS 生产部署后的反向代理与日志排查

文章导读
部署MkSaaS后出现502 Bad Gateway或前端连不上,先不要反复改Nginx配置。大多数情况下,问题出在应用监听地址没有被确认、反向代理没有转发WebSocket升级头、以及日志没有统一收集导致看不到真实错误。下面按排查顺序给出配置文件骨架和日志命令。
📋 目录
  1. 一 确认 MkSaaS 服务监听地址与端口
  2. 二 配置 Nginx 反向代理与 Upgrade 头
  3. 三 收集应用日志到统一位置
  4. 四 按日志排查 502 和连接超时
A A

部署MkSaaS后出现502 Bad Gateway或前端连不上,先不要反复改Nginx配置。大多数情况下,问题出在应用监听地址没有被确认、反向代理没有转发WebSocket升级头、以及日志没有统一收集导致看不到真实错误。下面按排查顺序给出配置文件骨架和日志命令。

处理MkSaaS的502与连接超时,建议先检查应用是否监听0.0.0.0:3000,再确认Nginx的proxy_pass指向同一端口,并配置proxy_http_version 1.1与Upgrade头。日志统一从stdout收集,systemd环境用journalctl,容器环境用docker logs。适用于单机或容器部署,具体端口需结合启动配置确认。

确认 MkSaaS 服务监听地址与端口

MkSaaS启动时会在日志中输出监听地址。如果服务由systemd启动,直接查看服务日志;由Docker启动则查看容器日志。日志中通常包含类似这样的行:

MkSaaS server listening on 0.0.0.0:3000

如果日志被轮转或没有显示,用系统工具确认端口占用:

lsof -i :3000

输出中应有一个进程绑定到0.0.0.0:3000。如果看到127.0.0.1:3000,那么只有本机能访问,外部Nginx转发时如果不在同一网络会直接拒绝。此时需要修改服务启动参数,将监听地址改为0.0.0.0,然后重启服务。

MkSaaS 生产部署后的反向代理与日志排查

配置 Nginx 反向代理与 Upgrade 头

Nginx反向代理需要同时支持普通HTTP请求和WebSocket协议。下面是一个最小可用的server块,放在/etc/nginx/conf.d/ 下,文件名可以是mksaas.conf:

server {
    listen 80;
    server_name your.domain.com;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

注意这里没有写connect_timeout和proxy_read_timeout,如果MkSaaS有长时间连接(如WebSocket或SSE),默认超时可能中断连接。建议根据业务需要设置proxy_read_timeout,例如60s或更长时间。但不要盲目拉大,要结合应用场景确认。

改完配置后执行nginx -t检查语法,再systemctl reload nginx生效。

MkSaaS 生产部署后的反向代理与日志排查

收集应用日志到统一位置

MkSaaS的stdout日志是排查问题的关键。如果使用systemd管理服务,日志由journald收集,查看命令:

journalctl -u mksaas -f

如果使用Docker部署:

MkSaaS 生产部署后的反向代理与日志排查
docker logs -f mksaas-container

对于生产环境,建议将stdout日志转发到统一日志平台,但这是后续优化;当前先保证能在本地看到实时日志。注意两个命令都不会覆盖应用代码,只是读取标准输出。

按日志排查 502 和连接超时

出现502时,按以下顺序检查,每步都有明确结论:

  1. 进程存活:用ps aux | grep mksaas确认进程没有退出。如果进程反复重启,日志会显示崩溃原因。
  2. 端口监听:用lsof -i :3000确认监听地址是0.0.0.0还是127.0.0.1。如果被防火墙或本地回环限制,Nginx即使代理也连不上。
  3. 代理转发目标:在Nginx所在机器执行curl -v http://127.0.0.1:3000/,看能否拿到MkSaaS的响应。如果curl能通而Nginx返回502,问题在Nginx配置,比如proxy_pass写错或Upgrade头缺失。
  4. 上游超时设置:如果日志显示MkSaaS收到请求但处理时间很长,Nginx在等响应期间返回504,则需要调整proxy_read_timeout和proxy_connect_timeout。如果日志没有显示收到请求,说明请求根本没到MkSaaS,查防火墙或Nginx转发规则。

连接超时通常表现为前端报WebSocket连接失败。此时日志里会有“upstream timed out”或“read timed out”,直接对应Nginx的timeout参数。修改后重试,观察MkSaaS的stdout日志是否出现连接建立记录。