网站通过Nginx反向代理访问时，页面能打开，登录后却跳到错误域名，或者后端返回不属于当前站点的内容。问题未必出在重写规则，应用收到的Host请求头也值得检查。
代理入口域名与上游实际收到的Host可能不同。多站点应用和按域名识别租户的服务对此尤其敏感。
先确认哪一层生成错误地址
记录浏览器访问域名、响应中的Location跳转地址以及应用日志里的请求主机。用nginx -T检查实际生效配置，留意同一server内的多个location和上层继承设置。
不要只看浏览器地址栏。需要确认错误地址是上游应用生成，还是Nginx自身返回。
Nginx默认会传什么Host
Nginx官方代理模块文档说明，默认代理请求不会原样传递客户端的Host，而会设置为$proxy_host。因此proxy_pass指向内部主机名时，后端可能看到内部名称而非用户访问的域名。
需要保留客户端域名时，可在对应代理位置配置proxy_set_header Host $host;。这里传递的是Nginx规范化后的请求主机，不等同于所有场景都应透传。
选择合适的请求头值
若上游按公开域名区分站点，通常先核对$host是否符合应用配置；若上游要求固定虚拟主机，则明确写入该后端域名。官方文档还说明$http_host保留原始Host字段，但客户端未提供该字段时可能为空。
不能把外部任意Host直接当成可信业务域名。涉及回调地址、密码重置链接和多租户路由时，应同时在应用侧配置允许的主机名。
检查配置继承和重载
在当前层定义了任何proxy_set_header后，上层同类指令的继承规则会变化。对照nginx -T完整检查需要的转发头，不要只改一行就假设其他头仍在。
执行nginx -t确认语法后再平滑重载，并保留配置备份。语法检查通过只证明配置可解析，不代表上游已按预期识别域名。
验证实际请求
使用受控测试域名请求受影响路径，检查返回码、跳转地址和应用日志中的主机字段。可以先在萤光云或LightNode的独立环境验证多域名代理，再把同样的配置变更部署到业务VPS。
验收标准是每个入口域名都路由到正确站点，登录与跳转地址也保持一致。
FAQ
问：一律配置Host $host就够了吗？答：不一定。上游也可能要求固定域名，需以应用的虚拟主机配置为准。
问：改完仍跳错域名怎么办？答：继续检查应用的站点URL、可信代理和绝对地址配置。
温馨提示
温馨提示：多域名代理变更要逐个入口验收。不要在尚未核对应用允许主机列表时放宽Host处理。
