部署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,然后重启服务。
配置 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的stdout日志是排查问题的关键。如果使用systemd管理服务,日志由journald收集,查看命令:
journalctl -u mksaas -f如果使用Docker部署:
docker logs -f mksaas-container对于生产环境,建议将stdout日志转发到统一日志平台,但这是后续优化;当前先保证能在本地看到实时日志。注意两个命令都不会覆盖应用代码,只是读取标准输出。
按日志排查 502 和连接超时
出现502时,按以下顺序检查,每步都有明确结论:
- 进程存活:用
ps aux | grep mksaas确认进程没有退出。如果进程反复重启,日志会显示崩溃原因。 - 端口监听:用
lsof -i :3000确认监听地址是0.0.0.0还是127.0.0.1。如果被防火墙或本地回环限制,Nginx即使代理也连不上。 - 代理转发目标:在Nginx所在机器执行
curl -v http://127.0.0.1:3000/,看能否拿到MkSaaS的响应。如果curl能通而Nginx返回502,问题在Nginx配置,比如proxy_pass写错或Upgrade头缺失。 - 上游超时设置:如果日志显示MkSaaS收到请求但处理时间很长,Nginx在等响应期间返回504,则需要调整proxy_read_timeout和proxy_connect_timeout。如果日志没有显示收到请求,说明请求根本没到MkSaaS,查防火墙或Nginx转发规则。
连接超时通常表现为前端报WebSocket连接失败。此时日志里会有“upstream timed out”或“read timed out”,直接对应Nginx的timeout参数。修改后重试,观察MkSaaS的stdout日志是否出现连接建立记录。