Django防暴力破解，axes锁定异常IP

本文深入解析了 Django 项目中使用 django-axes 防御暴力破解的关键实践与常见陷阱：从中间件的严格位置要求（必须置于 AuthenticationMiddleware 之后、CommonMiddleware 之前）、INSTALLED_APPS 和数据库迁移等基础配置，到 AXES_FAILURE_LIMIT、AXES_LOCK_OUT_BY_COMBINATION_USER_AND_IP 等核心参数的精准设置；同时揭示了登录逻辑绕过 axes 的典型原因（如未调用 authenticate、使用 DRF TokenAuthentication 或 django-allauth 时未正确集成），并详解了锁定响应定制、AJAX 兼容处理、DEBUG 模式下的失效风险、多进程缓存一致性、日志清理及与 Nginx/WAF 的协同防御策略——帮你避开线上“看似生效实则失效”的致命坑，真正构建可靠、可维护、生产就绪的登录安全防线。

django-axes 安装和基础配置为什么必须加 MIDDLEWARE 且顺序不能错

不加中间件或放错位置，django-axes 根本不会拦截登录请求。它依赖 AuthenticationMiddleware 之后、视图执行前的时机做访问审计，所以必须放在 AuthenticationMiddleware 之后、CommonMiddleware 之前（官方推荐顺序）。常见错误是把它塞到最底下，结果所有登录失败都绕过了锁定逻辑。

安装后需在 INSTALLED_APPS 中添加 'axes'，并在 MIDDLEWARE 中插入 'axes.middleware.AxesMiddleware'。同时确保数据库已迁移：python manage.py migrate axes。

• AXES_FAILURE_LIMIT = 5：连续 5 次失败即锁定
• AXES_LOCK_OUT_BY_COMBINATION_USER_AND_IP = True：按「用户+IP」组合计数，避免封错人（比如公司共用出口 IP）
• AXES_ONLY_USER_FAILURES = False：默认统计所有失败登录（含不存在的用户名），设为 True 则只统计真实用户密码错

登录视图没走 axes 是因为没调用 authenticate() 或用了自定义后端

django-axes 的检测逻辑绑定在 django.contrib.auth.authenticate 调用上。如果你手写登录逻辑、跳过 authenticate()，或者用了第三方认证后端（如 django-allauth 的 login_by_token），axes 就收不到事件。

检查你的登录视图是否最终调用了 authenticate(request, username=..., password=...)。如果用了 django-allauth，需要额外启用 AXES_ENABLED = True 并确认其登录流程仍触发了标准认证钩子；否则得手动在表单验证失败时调用 axes.signals.user_login_failed.send(...)。

• 自定义登录？务必在 if not user: 分支里补上 user_login_failed.send(...)
• 用了 django-rest-framework 的 TokenAuthentication？它不走 authenticate() 主路径，需单独集成
• AXES_RESET_ON_SUCCESS = True 可选：成功登录后清空该 IP/用户的失败计数

AXES_LOCKOUT_TEMPLATE 和重定向行为容易被忽略的两个细节

锁定后默认返回 HTTP 429，前端可能直接报错而不展示友好提示。想自定义页面，得配 AXES_LOCKOUT_TEMPLATE = 'axes_lockout.html'，但这个模板**不会自动传入被锁 IP 或剩余时间**——要手动在视图里查 AccessLog 或用 axes.get_lockout_response(request) 获取上下文。

另一个坑是：如果登录接口是 AJAX 请求，429 响应可能被前端静默吞掉。建议配合 AXES_COOLOFF_TIME = 60 * 15（15 分钟冷却）和前端明确提示「IP 已被临时限制，请稍后再试」。

• 模板里可通过 {{ request.axes_locked_out }} 判断是否被锁（需开启 AXES_HANDLER = 'axes.handlers.database.AxesDatabaseHandler'）
• AXES_LOCKOUT_URL = '/locked/' 可强制重定向，但会丢失原始请求方法（POST 变 GET），不适合 API 场景
• 调试时用 python manage.py showmigrations axes 确认表结构正常，再查 django_axes_accesslog 表确认记录写入

生产环境必须关掉 DEBUG=True 否则 axes 的日志和锁定可能失效

django-axes 在 DEBUG=True 下会跳过部分缓存和数据库写入优化，导致失败计数不持久、锁定不生效。更隐蔽的问题是：开发时看到「锁定成功」，上线后却完全没反应——大概率是 DEBUG 没关，或 ALLOWED_HOSTS 配置错误导致中间件被跳过。

还要注意缓存后端。如果用了 LocMemCache，多进程部署时各 worker 的计数不共享，应换用 RedisCache 并配 AXES_CACHE = 'default'。数据库模式虽可靠，但高频登录场景下写入压力大，建议用缓存 + 数据库双写（AXES_HANDLER = 'axes.handlers.cache.AxesCacheHandler'）。

• AXES_VERBOSE = False 上线前务必关闭，否则每条失败都打 DEBUG 日志，撑爆磁盘
• 定期清理旧日志：python manage.py axes_reset 或配 cron 清理 AccessLog 表
• 别把 axes 当防火墙用——它防不了代理池或低频慢速爆破，得配合 Nginx 限速或 WAF

以上就是《Django防暴力破解，axes锁定异常IP》的详细内容，更多关于的资料请关注golang学习网公众号！