关于Django的ALLOWED_HOSTS与CSRF_TRUSTED_ORIGINS配置疑问及Nginx反向代理咨询

一、配置差异的原因 #

先明确你的部署场景：Django服务运行在127.0.0.1:8001，Nginx作为反向代理监听80端口，接收外部请求后转发给Django。

1. ALLOWED_HOSTS的作用与当前配置逻辑 #

ALLOWED_HOSTS是Django用来验证请求头中的Host字段的白名单，只有请求的Host值在这个列表里，Django才会处理请求，否则直接返回400错误。
你的Nginx配置里没有添加proxy_set_header Host $host;，默认情况下，Nginx转发给Django的请求会把Host头设为127.0.0.1:8001（也就是proxy_pass的目标地址）。所以Django的ALLOWED_HOSTS必须包含127.0.0.1才能通过验证——这就是你用ALLOWED_HOSTS = ["example.com"]无效的原因，因为此时请求的Host头是127.0.0.1，不在白名单里。

2. CSRF_TRUSTED_ORIGINS的作用与当前配置逻辑 #

CSRF_TRUSTED_ORIGINS是Django用来验证**请求来源（Origin或Referer头）**的白名单，防止跨站请求伪造。
你实际访问的域名是https://example.com，浏览器发送请求时会带上Origin头为https://example.com，所以这个值必须出现在CSRF_TRUSTED_ORIGINS里才能通过CSRF验证——这就是你用CSRF_TRUSTED_ORIGINS = ["http://127.0.0.1"]无效的原因，因为实际请求的来源和白名单不匹配。

补充：优化配置的方法 #

如果想让ALLOWED_HOSTS使用example.com，只需在Nginx的location /块中添加一行配置：

proxy_set_header Host $host;

这样Nginx会把客户端请求的Host头（比如example.com）原样转发给Django，此时ALLOWED_HOSTS就可以设为["example.com"]，CSRF_TRUSTED_ORIGINS依然保持["https://example.com"]即可。

二、Nginx反向代理的一般工作原理 #

反向代理是一种服务器端的代理机制，核心是替后端应用服务器接收外部请求并转发，具体流程如下：

• 步骤1：客户端发起请求：用户通过浏览器等工具向example.com（对应Nginx的80端口）发送请求。
• 步骤2：Nginx匹配请求规则：Nginx根据配置中的location块匹配请求路径：
  • 如果请求路径以/static开头，直接从配置的STATIC_ROOT目录读取静态文件并返回给客户端，无需转发给Django。
  • 其他路径的请求，Nginx会将请求转发给后端的Django服务（http://127.0.0.1:8001）。
• 步骤3：后端处理请求：Django接收Nginx转发的请求，处理完成后生成响应返回给Nginx。
• 步骤4：Nginx返回响应：Nginx将Django的响应转发给客户端，完成整个请求流程。

反向代理的核心价值包括：分担后端服务器的请求压力、统一处理静态资源、实现SSL加密、负载均衡等。

内容的提问来源于stack exchange，提问作者lustfully