Django生产环境(Gunicorn)重启后前10-20次请求报Internal Server Error（请求为None）

1. 强化日志采集 #

• 开启Gunicorn详细日志，配置--access-logfile -和--error-logfile -，设置日志级别为DEBUG，记录每个请求的worker进程ID，排查是否特定worker出问题。
• 在Django的settings.py里配置LOGGING，给中间件的process_request、process_view、process_response方法加日志，打印request对象状态（是否为None）和当前进程ID。
• 在视图、中间件、allauth回调等可能报错的地方加try-except，捕获request is None的异常并打印完整调用栈，定位具体出错代码行。

2. 定位中间件问题 #

• 临时注释所有自定义中间件，只保留Django默认中间件和allauth必需的中间件，重启Gunicorn测试。如果问题消失，再逐个恢复自定义中间件，找出触发问题的那个。
• 对可疑中间件，检查其process_request方法是否修改了request对象，或者有没有异步操作导致request被提前释放（比如用了非阻塞IO但没正确处理请求上下文）。

3. 检查Gunicorn配置与进程初始化 #

• 查看Gunicorn的worker配置：比如--workers数量是否过多，有没有用异步worker（gevent/eventlet）。如果是异步worker，排查代码是否兼容异步环境（比如依赖threadlocal的代码可能出问题）。
• 添加worker预热逻辑：用--preload参数预加载应用代码，或者自定义on_starting、post_fork钩子函数，在worker启动时提前初始化数据库连接、缓存连接等资源。
• 切换到同步worker（Gunicorn默认的sync类型）测试，排除异步worker带来的上下文管理问题。

4. 排查依赖包变更 #

• 对比2个月前的依赖清单（requirements.txt/pyproject.toml），找出期间更新的核心包（Django、django-allauth、gunicorn优先）。
• 回退到2个月前的依赖版本测试，若问题消失，再逐步升级依赖，定位到具体哪个版本引入的问题。
• 检查allauth的配置，确认是否某次更新后修改了回调URL或登录流程配置，导致跳转时request对象丢失。

5. 代码层面检查请求对象使用 #

• 搜索代码中所有直接用request的地方，重点排查请求上下文外的场景：比如信号处理、模型方法、后台任务，这些地方可能在请求未完全初始化时就访问request，导致其为None。
• 检查是否用了自定义threadlocal存储request（比如_thread_locals = local(); get_request()这类实现），异步worker或进程fork时，这种方式可能导致request未正确绑定。
• 查看allauth的登录回调视图，检查自定义信号或钩子是否在登录完成后执行，这些代码有没有正确处理request对象。

6. 缓存与连接池检查 #

• 检查数据库连接池配置，确认worker启动时是否正确初始化连接，避免前几次请求因未建立连接导致request处理异常。
• 若用了进程内缓存（比如LocMemCache），重启worker后缓存为空可能引发依赖缓存的逻辑出错，间接导致request为None。可临时切换到Redis等分布式缓存测试。

临时缓解方案 #

• 部署完成后，用脚本自动向站点关键URL发送10-20次请求，提前完成系统初始化，避免用户遇到错误。
• 采用Gunicorn滚动重启：每次只重启一个worker，保证其他worker正常处理请求，减少停机时间。

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