Nginx proxy_pass下如何用Django Request获取真实域名并实现子域名重定向
解决方案:Nginx反向代理下域名重定向问题
问题根源
你的Django代码无法获取真实域名,是因为Nginx反向代理时默认未将客户端请求的Host头传递给后端服务,导致request.get_host()返回上游服务名称app,而非真实的客户端请求域名。
方案一:直接在Nginx层面处理重定向(推荐)
无需经过Django,直接在Nginx中配置规则,将非prod.开头的域名请求重定向到prod.example.com,效率更高。
修改后的完整Nginx配置:
upstream app { server web:8000; # appserver_ip:ws_port } # 捕获所有非prod.example.com的请求,直接重定向 server { listen 80 default_server; server_name _; # 匹配所有未被其他server块覆盖的域名 return 301 https://prod.example.com$request_uri; } server { server_name prod.example.com; listen 80; client_max_body_size 250M; add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always; add_header Permissions-Policy "autoplay=(), encrypted-media=(), fullscreen=(), geolocation=(), microphone=(), browsing-topics=(), midi=()" always; location / { proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; # 传递真实Host头给后端(若后续需Django处理域名逻辑) proxy_set_header Host $host; proxy_pass http://app; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_redirect off; proxy_headers_hash_max_size 512; proxy_headers_hash_bucket_size 128; } }
方案二:修复Django获取真实域名的问题(保留原Django逻辑)
若要继续使用原有Django代码处理重定向,需完成两步配置:
步骤1:修改Nginx,传递真实Host头
在location /块中添加以下配置:
proxy_set_header Host $host; proxy_set_header X-Forwarded-Host $host;
修改后的location段:
location / { proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header Host $host; proxy_set_header X-Forwarded-Host $host; proxy_pass http://app; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_redirect off; proxy_headers_hash_max_size 512; proxy_headers_hash_bucket_size 128; }
步骤2:配置Django信任反向代理
在Django的settings.py中添加:
ALLOWED_HOSTS = ['prod.example.com', '其他需要允许的域名'] # 信任Nginx作为反向代理 SECURE_PROXY_SSL_HEADER = ('HTTP_X_FORWARDED_PROTO', 'https') USE_X_FORWARDED_HOST = True USE_X_FORWARDED_PORT = True
配置完成后,Django即可通过request.get_host()获取真实客户端域名,原有重定向代码恢复正常。
注意事项
- 若使用Cloudflare处理HTTPS,需确保Nginx与Cloudflare的转发协议、域名配置一致,避免不匹配问题
- 测试阶段可先用302临时重定向验证逻辑,确认无误后再改为301永久重定向
内容的提问来源于stack exchange,提问作者ViaTech
相关产品推荐
相关产品推荐

