.NET Core+Docker端口映射后HTTPS重定向异常问题咨询

首先直接给结论：这种情况是完全正常的行为，但它确实暴露了.NET Core的HTTPS重定向中间件在容器化环境下的默认局限性。下面我会详细拆解原因，再给你更灵活的优化方案。

为什么默认配置会踩坑？ #

说白了，.NET Core的AddHttpsRedirection中间件“活在自己的世界里”——它默认只会看你Kestrel配置的内部监听端口（也就是容器里的443），完全不知道你在Docker里把这个端口映射到了宿主机的5001。

当用户访问宿主机的5000端口时，请求先进到容器的80端口，中间件一看“这是HTTP请求，得重定向到HTTPS”，于是就按照自己知道的443端口生成重定向地址，也就是https://你的主机:443。但你宿主机根本没开443端口对外，自然就访问失败了。

你手动设置options.HttpsPort = 5001后恢复正常，本质上就是“告诉”中间件：别用你默认的443了，重定向的时候用5001这个端口，这样就刚好对上了宿主机的映射端口。

这是正常行为吗？ #

绝对是正常的。中间件的设计逻辑就是这样：它只关心当前应用自身的监听配置，不会自动穿透容器的网络隔离去感知外部的端口映射——毕竟容器里的应用和宿主机是两个独立的网络环境，应用本身没法直接获取Docker的端口映射规则。

如何实现“自动适配”端口映射？ #

如果你不想每次改Docker端口都去改代码里的硬编码，可以用环境变量来动态配置，这也是容器化应用的最佳实践：

步骤1：修改代码，读取环境变量 #

把AddHttpsRedirection的配置改成从环境变量读取HTTPS端口，没有的话再 fallback到默认的443：

services.AddHttpsRedirection(options =>
{
    options.RedirectStatusCode = StatusCodes.Status308PermanentRedirect;
    // 从环境变量获取HTTPS端口，灵活适配不同的部署场景
    if (int.TryParse(Environment.GetEnvironmentVariable("HTTPS_PORT"), out var httpsPort))
    {
        options.HttpsPort = httpsPort;
    }
});

步骤2：运行容器时传入环境变量 #

之后不管你把宿主机的HTTPS端口改成什么（比如5002、8443），只要在docker run的时候用-e参数传入对应的环境变量就行：

docker run -p 5000:80 -p 5001:443 -e HTTPS_PORT=5001 core

进阶方案：用反向代理传递转发头 #

如果你的部署场景里有反向代理（比如Nginx、Traefik），还可以让反向代理传递X-Forwarded-Proto和X-Forwarded-Port这两个HTTP头，然后在.NET Core里启用转发头支持：

// 在Startup.cs的Configure方法里添加（要放在UseHttpsRedirection之前）
app.UseForwardedHeaders(new ForwardedHeadersOptions
{
    ForwardedHeaders = ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto | ForwardedHeaders.XForwardedPort
});

这样中间件就能根据反向代理传递的信息自动生成正确的重定向地址，完全不用手动配置端口，适合更复杂的集群部署场景。

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