关键在于Nginx需在location块中显式设置proxy_set_header Host，优先用$host透传客户端域名（不含端口），避免用$proxy_host；须匹配后端虚拟主机要求，并验证Host头是否正确抵达。
关键在于让后端服务识别出请求本应归属的域名，而不是 Nginx 代理节点的 IP 或默认 host。当后端是基于名称的虚拟主机（如 Apache 的 NameVirtualHost、Nginx 的 server_name、或 Spring Boot/Django 中依赖 Host 构建绝对 URL 的场景），若 Host 头缺失、为空或被误设为内网地址，路由就会失败或返回默认站点。
明确后端依赖的 Host 值
先确认后端服务实际校验的是什么：
- 是否严格匹配
example.com，还是接受example.com:443或带端口形式 - 是否区分大小写（HTTP/1.1 规范中 Host 不区分大小写，但某些框架实现可能敏感）
- 是否要求 HTTPS 场景下 Host 必须不含端口（即只认
example.com，不认example.com:443）
在 location 中精准设置 Host 头
不要仅靠全局或 server 级配置，应在具体转发路径的 location 块里显式控制：
WebChat Voice Proxy
下载
⚠️ 已弃用 — 该技能已拆分为两个独立技能，以提升模块化程度：**webchat-https-proxy**（HTTPS/WSS 反向代理）和 **webchat-voi...**
- 用
proxy_set_header Host $host;—— 透传客户端原始 Host（不含端口），适用于大多数标准 HTTPS 站点 - 用
proxy_set_header Host $http_host;—— 保留原始 Host 全貌（含端口和大小写），适合需要端口信息的后端 - 避免用
$proxy_host—— 它取自proxy_pass目标地址，通常是内网 IP 或 upstream 名，后端无法据此路由虚拟主机
配合 proxy_pass 的路径处理逻辑
Host 头生效的前提是请求真正抵达后端且路径正确：
- 若
proxy_pass http://backend/;（结尾有/），Nginx 会剥离 location 前缀再转发，此时 Host 应与后端期望的域名一致 - 若
proxy_pass http://backend;（无结尾/），Nginx 会原样拼接路径，容易导致重复前缀（如/api/api/user），间接影响后端路由判断 - upstream 定义中不要混用域名和 IP：统一用域名（如
backend.internal）并确保 DNS 可解析，再配合proxy_set_header Host backend.internal;硬编码，可规避客户端 Host 不可控的问题
验证 Host 是否按预期到达后端
最直接的方式是在后端加一行日志输出 Host 值：
- Node.js：
console.log('Host:', req.headers.host); - Python Flask：
print(f"Host: {request.headers.get('Host')}") - 或临时用
nc -l 8080拦截请求，查看原始 HTTP 请求行和头 - 注意检查是否被其他 location 块覆盖——Nginx 按最长前缀匹配，高优先级 location 若漏配
proxy_set_header Host，会导致继承上层空值
