Ubuntu生产环境Flask（Gunicorn+Nginx）POST请求报过载及内部服务器错误

按照“从高概率、低耗时到低概率、高耗时”的顺序排查，不要对着泛化的报错信息瞎改代码：

先抓真实错误栈，定位错误到底抛在哪一层 #

生产环境Flask默认关闭debug模式，页面显示的“内部服务器错误”“服务器过载”都是通用提示，看不到真实原因，挨个查三层日志：

• Gunicorn应用日志：执行journalctl -u 你的Flask服务名 -f实时跟踪，POST请求触发的真实Traceback都会存在这里，是最直接的判断依据
• Nginx错误日志：默认存放在/var/log/nginx/error.log，如果POST请求根本没转发到Gunicorn，拦截记录会写在这里
• MongoDB运行日志：默认存放在/var/log/mongodb/mongod.log，确认数据库有没有收到写请求、有没有抛权限不足/超时的错误

优先排除Nginx层的拦截问题 #

GET请求无请求体、路径简单，基本不会被Nginx默认配置卡；带请求体的POST请求十有八九是被Nginx默认规则拦截：

• 检查client_max_body_size配置：Nginx默认最大请求体限制是1M，只要POST传的内容超过这个值，会直接返回泛化错误，根本不把请求转给后端。如果日志里出现“client intended to send too large body”，在站点server块里把这个值改成符合业务需要的大小，执行nginx -t && systemctl reload nginx就生效
• 检查代理超时配置：Nginx默认读后端响应的超时是60秒，如果MongoDB写操作因为磁盘IO卡、建索引慢超过这个时间，Nginx会直接断连给用户返回服务器过载，后端Gunicorn这边可能还在正常执行。碰到这类记录的话，按业务实际耗时调整超时值就行

再排查Gunicorn配置的常见坑 #

开发模式运行的是Flask自带的单进程调试服务器，和生产环境Gunicorn的运行环境差异很大，很多问题都是这类环境差导致的：

• 检查进程工作目录：如果systemd服务文件里没写WorkingDirectory=项目根路径，Gunicorn默认的工作目录是系统根目录/。这种情况下GET请求因为不触发本地文件读写、配置加载逻辑，能正常跑；一旦涉及写操作、相对路径的文件读写，就会因为路径不对抛500。改完服务配置记得执行systemctl daemon-reload && systemctl restart 你的服务名生效
• 检查进程运行权限：Gunicorn一般是用专用服务用户运行的，要确认这个用户对项目目录、上传临时目录有读写权限；同时要确认连接MongoDB用的账号具备对应库的readWrite权限，不然insert操作会被数据库直接拒绝
• 检查worker配置：如果worker数配的太少（比如只开1个），还用默认的sync同步模式，每个worker同一时间只能处理1个请求，一旦MongoDB写操作卡一下，连续的POST请求很快就把所有worker占满，直接触发过载。可以临时把启动参数改成-k gevent --worker-connections 100用异步模式测试，要是切换模式后POST请求恢复正常，说明就是同步阻塞把worker占满了，按业务量调整worker数和模式即可

最后排查应用本身的生产配置差异 #

开发的时候为了图方便一般会关闭一堆安全校验，生产环境开启后没适配的话很容易出问题：

• 检查CSRF校验：如果生产环境开启了Flask-WTF的CSRF保护，但是POST接口没带合法的CSRF token，Flask会直接抛500。要是日志里有“CSRF token missing or incorrect”的报错，要么给对应接口加豁免规则，要么适配前端传参逻辑
• 检查数据库连接配置：确认生产环境的MongoDB连接字符串和实际部署的数据库配置匹配，不要漏了认证参数、不要把只读账号当成读写账号使用

内容的提问来源于stack exchange，提问作者Dinesh D