Gunicorn部署Django 3.2.16返回500错误且无详细信息求助

可能的原因排查 #

• ALLOWED_HOSTS 配置遗漏
  即便 DEBUG = True，如果 ALLOWED_HOSTS 未包含当前访问的主机（如 localhost、127.0.0.1），Django 仍会返回 500 错误。默认情况下 DEBUG=True 时 ALLOWED_HOSTS 会自动包含本地地址，但如果手动设置了该参数为空或未覆盖访问主机，就会触发问题。可临时设置 ALLOWED_HOSTS = ['*'] 测试，或明确添加访问地址。

• 静态/媒体文件处理异常
  Gunicorn 本身不负责静态文件托管，虽然 DEBUG=True 时 Django 会自动处理静态文件，但如果 STATIC_ROOT、STATIC_URL 配置错误，或页面引用了不存在的静态资源，可能触发 500 错误。可尝试访问一个不含静态资源的纯文本视图（如自定义返回 HttpResponse("test") 的视图），验证是否仍报错。

• 配置文件加载不一致
  可能 Gunicorn 运行时加载的不是你修改的 settings 文件——比如误指定了生产环境配置、DJANGO_SETTINGS_MODULE 环境变量未正确设置。可在 wsgi.py 中添加打印确认：

  print(settings.__file__)
  

  查看输出的文件路径是否指向你修改的 settings.py。

• 运行环境依赖差异
  虽然 runserver 正常，但 Gunicorn 所在的虚拟环境可能存在依赖缺失或版本冲突。可分别导出两个环境的依赖列表对比：

  # runserver 环境
  pip freeze > dev_requirements.txt
  # Gunicorn 运行环境
  pip freeze > gunicorn_requirements.txt
  

  检查是否有依赖版本不一致或缺失的情况。

获取详细错误输出的方法 #

• 调整 Django 日志配置
  修改 settings.py 中的 LOGGING，让错误日志输出到控制台：

  LOGGING = {
      'version': 1,
      'disable_existing_loggers': False,
      'handlers': {
          'console': {
              'class': 'logging.StreamHandler',
          },
      },
      'root': {
          'handlers': ['console'],
          'level': 'DEBUG',
      },
  }
  

  重启 Gunicorn 后，控制台会输出 Django 产生的所有错误日志。

• 捕获 Gunicorn Worker 错误
  启动 Gunicorn 时指定日志级别，并将错误输出重定向到文件：

  gunicorn your_project.wsgi:application --log-level debug 2> gunicorn_errors.log
  

  查看 gunicorn_errors.log 文件，可获取 Worker 进程产生的详细错误信息。

• 在 WSGI 层捕获异常
  修改 wsgi.py，添加全局异常捕获并打印堆栈：

  import traceback
  from django.core.wsgi import get_wsgi_application
  
  application = get_wsgi_application()
  
  def wrapper_app(environ, start_response):
      try:
          return application(environ, start_response)
      except Exception:
          traceback.print_exc()
          raise
  
  application = wrapper_app
  

  请求触发错误时，控制台会打印完整的异常堆栈信息。

内容的提问来源于stack exchange，提问作者K.H.