ASP.NET Core Forwarded Headers仅在最小API生效问题排查

核心原因 #

两种模式的差异在于代理信任配置的默认行为：

• 最小API的WebApplication.CreateBuilder在启用ASPNETCORE_FORWARDEDHEADERS_ENABLED=true时，会自动识别IIS反向代理的IP并添加到信任列表，确保X-Forwarded-Proto头被正确解析。
• 传统Program+Startup模式下，手动配置的ForwardedHeadersOptions仅指定了要转发的头类型，但未明确信任负载均衡器的IP/网络。默认情况下，ForwardedHeaders中间件只会信任环回地址，因此会忽略来自负载均衡器的X-Forwarded-Proto头，导致HttpContext.Request.Scheme仍为http。

解决方案 #

1. 明确配置信任的代理IP/网段 #

在Startup.ConfigureServices中，将负载均衡器的IP添加到信任列表：

services.Configure<ForwardedHeadersOptions>(options =>
{
    options.ForwardedHeaders = ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto;
    // 替换为你的负载均衡器实际IP
    options.KnownProxies.Add(IPAddress.Parse("192.168.1.100"));
    // 如果负载均衡器使用网段，可添加网络范围
    // options.KnownNetworks.Add(new IPNetwork(IPAddress.Parse("192.168.1.0"), 24));
});

2. （可选）放宽信任限制（仅适用于完全可信的环境） #

如果能确保所有请求都来自可信的负载均衡器，可以临时放宽限制（不推荐在不可信环境使用）：

services.Configure<ForwardedHeadersOptions>(options =>
{
    options.ForwardedHeaders = ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto;
    options.ForwardLimit = null; // 取消转发次数限制
    options.RequireHeaderSymmetry = false; // 允许仅发送X-Forwarded-Proto头
});

3. 确认中间件顺序 #

确保app.UseForwardedHeaders()在所有依赖请求Scheme的中间件之前执行（比如UseStaticFiles、UseRouting、UseHttpsRedirection），你的现有代码顺序是正确的，无需调整。

验证 #

修改后重新部署应用，检查HttpContext.Request.Scheme是否变为https，同时验证生成的链接是否使用https://前缀。

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