django-request 常见问题排查清单：10 个高频错误与解决方案

django-request 常见问题排查清单：10 个高频错误与解决方案

【免费下载链接】django-requestdjango-request is a statistics module for django. It stores requests in a database for admins to see, it can also be used to get statistics on who is online etc.项目地址: https://gitcode.com/gh_mirrors/dj/django-request

django-request 是一个开源的 Django 请求统计模块，它会把每一次 HTTP 请求写入数据库，让管理员在后台直接查看流量走势、在线用户、来源页面、搜索引擎关键词和错误页面等数据。然而新手在安装配置 django-request 时，经常碰到"请求不记录""表不存在""IP 全是 1.1.1.1"之类的问题。这份 django-request 常见问题排查清单，整理了 10 个最高频的错误现象、根因和解决方案，帮你少走弯路。

一、10 个高频错误速查表

二、10 个高频错误详解

1. 安装后没有任何请求被记录

这是最常见的问题：数据表建好了，后台也有菜单，但一条记录都没有。

原因通常是漏掉了中间件。django-request 依赖中间件在每次响应后写入数据，仅加入INSTALLED_APPS是不够的。

在settings.py中确认包含：

• INSTALLED_APPS里加入'request'；
• MIDDLEWARE里加入'request.middleware.RequestMiddleware'；
• 并且已执行过manage.py migrate。

2. ProgrammingError: relation "request_request" does not exist

页面直接报数据库表不存在，本质是没有执行迁移。request应用自带多份迁移文件（位于request/migrations/），安装后必须执行：

python manage.py migrate

如果依然报错，检查INSTALLED_APPS中的应用名是否写成了别的（例如django-request），Django 只认request。

3. 记录里 user 字段永远是空的

日志能看到请求，但登录用户那一列始终是空值。这通常是中间件顺序错误：RequestMiddleware被放在了django.contrib.auth.middleware.AuthenticationMiddleware之前，此时request.user还没被注入。

正确的顺序是：

MIDDLEWARE = [ # ... "django.contrib.auth.middleware.AuthenticationMiddleware", "request.middleware.RequestMiddleware", # ... ]

4. 404 页面全部被记录成错误页

如果项目使用了django.contrib.flatpages（扁平页），你会看到大量本应正常返回的页面被标记为 404 错误。原因是FlatpageFallbackMiddleware会先把请求"吃掉"再重新返回，导致状态码判断错位。

解法是让RequestMiddleware排在FlatpageFallbackMiddleware之前，让请求先被记录、再交给 flatpages 处理。

5. ModuleNotFoundError: No module named 'dateutil'

启动或迁移时抛出找不到dateutil，是因为缺少核心依赖python-dateutil。request/managers.py中的按年、按月、按周统计都依赖它。

安装方式：

pip install python-dateutil

如果是源码部署，也建议用pip install -e .让依赖自动补齐；或直接通过 GitCode 克隆仓库后本地安装：

git clone https://gitcode.com/gh_mirrors/dj/django-request cd django-request && pip install -e .

6. 所有 IP 都显示为 1.1.1.1

日志里 IP 清一色是1.1.1.1，大概率不是 bug，而是隐私脱敏配置生效了。相关开关集中在request/settings.py：

• REQUEST_LOG_IP = False：不记录真实 IP，统一替换为REQUEST_IP_DUMMY（默认1.1.1.1）；
• REQUEST_ANONYMOUS_IP = True：把 IP 最后一段置为 1，例如192.168.1.1变成192.168.1.1之外的*.*.*.1形式。

按需关闭或调整这两个配置即可。若你希望完全符合 GDPR 等隐私规范，保留匿名化反而是推荐做法。

7. 站内跳转被当成外链，统计严重失真

"外部来源"和"独立访问"数字虚高，原因是没有设置REQUEST_BASE_URL。该值用于判断 referer 是否来自本站，默认取django.contrib.sites的当前站点域名；如果站点用了 HTTPS、多域名或未启用 sites 框架，判断就会失效。

在settings.py中显式指定：

REQUEST_BASE_URL = "https://www.example.com/"

这样unique_visits()等方法才能正确排除站内来源。

8. 数据库膨胀、后台列表越来越慢

django-request 会记录每一次请求，高流量站点一个月就能攒下几十万行，导致后台变卡、备份变慢。官方提供了清理命令purgerequests，逻辑见request/management/commands/purgerequests.py。

用法示例（删除 30 天前的记录，跳过确认）：

python manage.py purgerequests 30 days --noinput

支持hours、days、weeks、months、years五种单位，建议配合 cron 定时执行。

9. 只想记录错误请求，结果全部请求都被存下来了

如果只是想用 django-request 当"错误监控"，把全部请求入库既浪费存储又淹没重点。开启错误过滤即可：

REQUEST_ONLY_ERRORS = True

开启后只有返回状态码 ≥ 400 的响应会被记录（判断逻辑见request/middleware.py）。同理，REQUEST_VALID_METHOD_NAMES可以限定只记录 GET/POST 等指定方法，过滤掉 OPTIONS、TRACE 等噪音。

10. active_users 在线用户列表永远是空的

模板里用了active_users标签却拿不到数据，常见原因有三个：

1. 忘记{% load request_tag %}，导致标签未注册；
2. 用户未登录：该功能只统计user非空的记录，匿名访客不算在线；
3. 时间窗口太短：默认只统计最近 15 分钟，可这样调整：

{% load request_tag %} {% active_users in 30 minutes as online_users %} {% for user in online_users %}{{ user.get_username }}{% endfor %}

标签实现见request/templatetags/request_tag.py，对应管理器方法为Request.objects.active_users(minutes=30)（位于request/managers.py）。

三、常用配置速查

完整的配置说明可查阅仓库内docs/settings.txt，模型字段与存储逻辑见request/models.py。

结语

django-request 的坑大多集中在安装三件套（应用注册、迁移、中间件顺序）和统计口径配置上。把上面 10 条逐个对照检查，大部分问题都能在五分钟内解决。如果排查后仍有异常，优先检查 Django 日志中的request.security.middleware警告，它能直接告诉你哪些请求因校验失败被丢弃。祝你顺利跑通自己的流量统计面板 🚀

【免费下载链接】django-requestdjango-request is a statistics module for django. It stores requests in a database for admins to see, it can also be used to get statistics on who is online etc.项目地址: https://gitcode.com/gh_mirrors/dj/django-request