我用以下方法解决了这个问题：
python manage.py runserver --http_timeout 120

mod_wsgi WSGIDaemonProcess指令中有几个超时选项（检查请求超时）：
https://modwsgi.readthedocs.io/en/develop/configuration-directives/WSGIDaemonProcess.html

非活动超时=sss（2.0+）

定义当后台进程进入空闲状态时，在后台进程关闭并重新启动之前允许经过的最大秒数。对于该选项，空闲意味着没有接收到新请求，或者在所定义的时间段内当前请求没有尝试读取请求内容或生成响应内容。此选项允许重新启动在守护进程中运行的不常用的应用程序，从而允许回收正在使用的内存，进程大小降回到加载任何应用程序或处理任何请求之前的初始启动大小。

请求超时=sss

定义在重新启动守护程序进程之前允许请求运行的最大秒数。这可用于从请求无限期阻塞的情况中恢复，如果以这种方式使用所有请求线程，则会导致整个WSGI应用程序进程被阻塞。
根据守护进程是只使用一个线程还是使用多个线程来处理请求（由threads选项设置），此选项的行为方式会有所不同。
如果只有一个线程，则进程一次只能处理一个请求，一旦超时，将启动进程的重新启动。
如果有一个以上的系缐，则要求逾时会套用至所有系缐中任何要求的平均执行时间。这表示要求的执行时间可能会超过要求逾时。这样做是为了降低中断其他执行中要求以及让使用者看到失败的可能性。因此，如果仍有容量可行程更多要求，则会尽可能延迟重新启动行程作业。

死锁超时=sss（2.0+）

定义在检测到Python GIL上的潜在死锁后，在守护进程关闭并重新启动之前允许经过的最大秒数。默认值为300秒。这个选项的存在是为了解决守护进程冻结的问题，这是由于一个粗糙的Python C扩展模块在进入阻塞或长时间运行的操作时没有正确释放Python GIL造成的。

关闭超时=sss

定义由于达到最大请求数或非活动超时而等待后台进程正常关闭时允许经过的最大秒数，或者当一个用户启动的SIGINT信号被发送到一个守护进程时。当这个超时已经到达时，守护进程将被强制退出，即使仍然有活动的请求或者它仍然在运行Python退出函数。如果未定义此选项，则关闭逾时会设为5秒。请注意，此选项不会变更Apache本身停止或重新启动时，套用至协助程式行程作业的关闭逾时。Apache内部会将该逾时值定义为3秒，且无法覆写。
...
关于WSGIDaemonProcess的文档：
使用mod_wsgi守护程序模式
定义流程组