Django部署报500错误怎么查？DEBUG与日志排查方法

Django生产环境出现500错误却看不到任何堆栈信息？这不是代码缺陷，而是DEBUG=False时框架主动屏蔽异常详情的安全机制——问题根源常被误判为“日志没配置好”，实则可能卡在ALLOWED_HOSTS不匹配、WSGI服务器未捕获异常、中间件静默吞错，甚至Gunicorn启动失败等更底层环节；本文直击要害，教你用LOGGING精准落盘错误、借DEBUG_PROPAGATE_EXCEPTIONS临时透出堆栈、辅以ADMINS邮件兜底，并强调日志轮转、路径权限、格式字段等易踩坑细节，帮你绕过安全设计的“黑箱”，而非粗暴关闭DEBUG，在保障生产安全的前提下实现高效排障。

生产环境500错误看不到堆栈？不是代码写错了，而是DEBUG = False后Django主动吞掉了所有错误细节——这不是bug，是安全设计。你必须绕过它，而不是关掉它。

为什么DEBUG=False后连报错行号都消失了

Django在DEBUG = False时会跳过完整的错误页面渲染流程，直接返回HTTP 500响应体里只有“Server Error (500)”几个字。它甚至不调用django.views.debug.ExceptionReporter，所以堆栈、变量、请求参数全被丢弃。这不是日志没写，是根本没生成。

• 检查settings.py中DEBUG是否真为False（注意字符串'False'不等于布尔False）
• ALLOWED_HOSTS为空或不匹配当前域名，也会触发500且无日志——这是最常被忽略的前置条件
• WSGI服务器（如Gunicorn）若未正确捕获Python异常，可能连stderr都不输出，导致日志文件也为空

用LOGGING配置把错误“捞”进文件

默认的Django日志在DEBUG = False下只记录到stderr，而生产环境通常重定向了stdout/stderr，导致日志丢失。必须显式配置FileHandler并指定level='ERROR'。

• 路径权限问题：确保运行Gunicorn/uWSGI的用户对filename所在目录有写权限，否则日志静默失败
• 别用FileHandler：它不会轮转，单个文件可能撑爆磁盘；改用RotatingFileHandler，设置maxBytes=10485760（10MB）和backupCount=5
• 关键字段不能少：%(asctime)s %(levelname)s %(name)s %(funcName)s %(lineno)d %(message)s，否则查错时不知道哪行出的错

示例最小可用配置：

LOGGING = {
    'version': 1,
    'disable_existing_loggers': False,
    'handlers': {
        'file': {
            'level': 'ERROR',
            'class': 'logging.handlers.RotatingFileHandler',
            'filename': '/var/log/django/error.log',
            'maxBytes': 10485760,
            'backupCount': 5,
            'formatter': 'verbose'
        },
    },
    'formatters': {
        'verbose': {
            'format': '%(asctime)s %(levelname)s %(name)s %(funcName)s %(lineno)d %(message)s'
        },
    },
    'loggers': {
        'django': {
            'handlers': ['file'],
            'level': 'ERROR',
            'propagate': False,
        },
    }
}

临时启用DEBUG_PROPAGATE_EXCEPTIONS看一眼堆栈

这个开关不等于开DEBUG，它只是让Django把未捕获异常原样抛给WSGI服务器——Gunicorn会把它打到stderr，uWSGI则写入uwsgi.log。适合紧急定位，但必须立刻关掉。

• 仅在DEBUG = False前提下生效，设成True时它无效
• Gunicorn需配合--capture-output启动参数，否则stderr仍可能被丢弃
• 切记：该设置会让堆栈出现在进程日志里，如果日志被ELK等系统采集并开放查询，仍有信息泄露风险

用ADMINS邮件接收500详情（但别依赖它）

当DEBUG = False且ADMINS非空时，Django会在500发生后发一封含完整堆栈的邮件。但它依赖整个邮件链路通畅，且只在异常未被任何中间件捕获时触发。

• 必须配置EMAIL_BACKEND（如django.core.mail.backends.smtp.EmailBackend）、EMAIL_HOST、EMAIL_PORT等，缺一不可
• 中间件如django.middleware.common.BrokenLinkEmailsMiddleware或自定义异常处理会提前截断异常，导致邮件不发送
• 邮件延迟高、易被当成垃圾邮件拦截，仅作辅助手段，不能替代实时日志

真正卡住排查进度的，往往不是日志配不配得上，而是错误发生在WSGI层之前（比如Gunicorn启动失败）、或被中间件静默吞掉（比如JWT认证失败没抛出PermissionDenied）。先确认gunicorn --access-logfile - --error-logfile -能否看到原始Python异常，再谈Django日志配置。

本篇关于《Django部署报500错误怎么查？DEBUG与日志排查方法》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于文章的相关知识，请关注golang学习网公众号！