我有一个(基于 Python、DRF 的)API,作为 Uvicorn 服务在 Debian 服务器上的 8002 端口上运行。它运行时没有明显问题,因为当我这样做时curl http://127.0.0.1:8002/videos/
,我得到了预期的 API 响应(我在 Heroku 上部署时也测试过它,没有问题)。
我需要使用 Nginx 公开提供它,因此我配置了一个新的 Nginx vhost 作为反向代理,如下所示:
upstream my_api {
server 127.0.0.1:8002;
}
server {
server_name example.com;
location / {
# Pass to Uvicorn/Gunicorn web server service
proxy_pass http://my_api;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}
error_log /home/www/mydomain.log info;
在浏览器上,我收到 400 Bad Request 错误,无论是开启http://example.com/videos/
还是http://example.com/
开启http://example.com/whatever
。
当我跟踪/home/www/example.log
Nginx vhost 日志文件时,我没有得到任何相关信息,或者来自其他 vhost 的日志,如下所示:
2021/07/09 12:05:49 [info] 24698#24698: *233765 client 55.36.148.206 closed keepalive connection
2021/07/09 12:06:12 [info] 24698#24698: *233772 client 217.244.66.202 closed keepalive connection
2021/07/09 12:06:13 [info] 24698#24698: *233775 client closed connection while waiting for request, client: 63.210.40.102, server: 0.0.0.0:80
(注意:唯一端点适用于/videos/
路线但不适用于/videos
路线 - 这将在稍后修复但无论如何这不应该干扰问题。)
知道如何调试/了解这个 400 错误来自哪里吗?
答案1
感谢 Michael Hampton 的评论,看起来 400 错误不是出在 Nginx 端,而是出在由 Gunicorn/Uvicorn 提供服务的 Python 应用程序端,尽管 curl 在本地运行正常。
因此,只需要显示 Gunicorn 日志来调试它,通过在调试日志打开的情况下手动启动它,如下所示:
gunicorn -k uvicorn.workers.UvicornWorker --bind "0.0.0.0:8002" --log-level debug my_api.asgi:application