使用Nginx做反向代理时，改Host头还是传X-Forwarded-Host？

核心区别：改写Host头 vs X-Forwarded-Host #

• 改写Host头是直接修改发送给上游服务器的Host字段，上游会默认认为这个值就是原始请求的Host，无需额外处理。
• X-Forwarded-Host是通过自定义头传递原始请求的Host信息，需要上游的ForwardedHeadersMiddleware主动读取并覆盖HttpContext.Request.Host，属于代理场景下的标准传递方式。

三种配置的场景分析 #

1. 仅改写Host头 #

适合上游未启用ForwardedHeadersMiddleware的场景，对已启用中间件的ASP.NET Core来说，虽然最终HttpContext.Request.Host能得到正确值，但这种方式跳过了标准的代理头传递逻辑，更像是临时兼容方案，无法保留完整的请求链路信息。

2. 仅设置X-Forwarded-Host头 #

这是符合代理规范的最优方案：它保留了代理到上游的原始Host（比如Nginx配置的localhost:5000），同时通过标准头传递客户端真实请求的Host。ASP.NET Core的中间件会自动读取该头并修正HttpContext.Request.Host，还能完整保留代理链路的所有信息，便于日志排查和业务逻辑处理。

3. 同时设置两者 #

完全冗余且无必要。ForwardedHeadersMiddleware会优先读取X-Forwarded-Host的值覆盖HttpContext.Request.Host，改写的Host头会被忽略，反而可能造成配置混淆。

正确做法 #

对于已注册ForwardedHeadersMiddleware的ASP.NET Core应用，*仅设置X-Forwarded-Host（配合另外两个X-Forwarded-头）是标准且推荐的配置，原因如下：

• 遵循HTTP代理转发的规范，通过专用头传递原始请求信息，不修改请求核心字段。
• 保留完整的请求链路上下文，上游可区分代理自身的Host和客户端原始Host，适配更多业务场景。
• 配置更稳定，后续代理或上游地址变更时，无需调整Host改写规则，仅需保证X-Forwarded-Host正确传递即可。

对应Nginx配置示例 #

location / {
    proxy_pass http://your-aspnet-core-upstream;
    proxy_set_header X-Forwarded-Host $host;
    proxy_set_header X-Forwarded-For $remote_addr;
    proxy_set_header X-Forwarded-Proto $scheme;
}

ASP.NET Core中间件配置示例 #

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddForwardedHeaders(options =>
{
    options.ForwardedHeaders = ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto | ForwardedHeaders.XForwardedHost;
    // 若Nginx与ASP.NET Core在同一服务器，添加Nginx的IP到信任列表
    options.KnownProxies.Add(IPAddress.Parse("127.0.0.1"));
});

var app = builder.Build();

// 必须在其他中间件之前启用ForwardedHeaders
app.UseForwardedHeaders();

// 后续业务中间件配置
app.Run();

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