ASP.NET Core 2.0应用IIS托管下，局域网服务能否直连Kestrel？

针对你的场景，答案是可行的——你完全可以让局域网内的服务直接连接由IIS托管的Kestrel实例，同时保留IIS的运维管理能力，还能享受到Kestrel的性能优势。下面分点拆解细节：

一、为什么默认直接连Kestrel会被拒绝？ #

你提到的MS-ASPNETCORE-TOKEN头是ASP.NET Core Module（ANCM，也就是IIS和Kestrel之间的桥梁）用来验证请求来源的机制：当IIS托管Kestrel时，ANCM会自动给每个转发到Kestrel的请求添加这个令牌，Kestrel会检查令牌有效性，只处理来自ANCM的请求，拒绝其他直接访问的请求。这是默认的安全机制，防止Kestrel被未经授权的外部请求直接访问。

二、如何实现同时支持IIS转发和局域网直接访问？ #

要达成目标，需要调整两个关键配置：监听局域网IP，以及调整令牌验证规则。

1. 配置Kestrel监听局域网IP #

默认情况下，ANCM会让Kestrel只监听127.0.0.1（本地回环）的端口，所以局域网内的其他机器无法访问。你需要修改Kestrel的监听配置，让它监听局域网IP或者所有网络接口：

方式1：通过Program.cs代码配置

public static IWebHost BuildWebHost(string[] args) =>
    WebHost.CreateDefaultBuilder(args)
        .UseKestrel(options =>
        {
            // 监听所有网络接口的5000端口（也可以指定具体局域网IP，比如192.168.1.100）
            options.Listen(IPAddress.Any, 5000);
        })
        .UseIISIntegration()
        .UseStartup<Startup>()
        .Build();

方式2：通过appsettings.json配置

"Kestrel": {
  "EndPoints": {
    "Http": {
      "Url": "http://0.0.0.0:5000"
    }
  }
}

2. 调整令牌验证策略 #

现在Kestrel能被局域网访问了，但还需要处理令牌验证的问题，有两种选择：

选项A：仅允许局域网IP跳过令牌验证（推荐，更安全）

保留ANCM的令牌验证，同时添加自定义中间件，让来自局域网IP的请求不需要携带MS-ASPNETCORE-TOKEN头：

// 在Startup.cs的Configure方法中添加这个中间件（要放在其他中间件之前）
app.Use(async (context, next) =>
{
    // 自定义判断是否为局域网IP的逻辑，示例：检查是否在192.168.x.x或10.x.x.x网段
    bool isLocalNetworkRequest = false;
    var remoteIp = context.Connection.RemoteIpAddress;
    if (remoteIp != null)
    {
        if (remoteIp.IsIPv4MappedToIPv6)
            remoteIp = remoteIp.MapToIPv4();
        isLocalNetworkRequest = remoteIp.ToString().StartsWith("192.168.") || remoteIp.ToString().StartsWith("10.");
    }

    // 要么有合法的ANCM令牌，要么是局域网请求，才允许继续
    if (context.Request.Headers.ContainsKey("MS-ASPNETCORE-TOKEN") || isLocalNetworkRequest)
    {
        await next();
    }
    else
    {
        context.Response.StatusCode = StatusCodes.Status403Forbidden;
        await context.Response.WriteAsync("Forbidden: Only IIS or local network requests are allowed.");
    }
});

选项B：完全禁用令牌验证（简单但需注意安全）

如果能确保Kestrel的端口不会暴露到公网（通过防火墙规则限制仅局域网访问），可以直接禁用ANCM的令牌验证：

public static IWebHost BuildWebHost(string[] args) =>
    WebHost.CreateDefaultBuilder(args)
        .UseKestrel(options =>
        {
            options.Listen(IPAddress.Any, 5000);
        })
        .UseIISIntegration(options =>
        {
            // 禁用令牌验证，Kestrel会接受所有请求
            options.DisableTokenValidation = true;
        })
        .UseStartup<Startup>()
        .Build();

三、能否同时通过IIS和直接连接Kestrel？ #

完全可以！只要配置正确：

• IIS依然通过ANCM转发请求到Kestrel的本地回环端口（默认是随机端口，由ANCM管理），这些请求会携带MS-ASPNETCORE-TOKEN，能正常被处理；
• 局域网内的服务直接访问Kestrel监听的局域网IP:端口，只要符合你设置的验证规则（要么是局域网IP，要么禁用了验证），也能正常处理请求。
  两者互不干扰，同时工作。

四、是否值得实施？ #

从你的场景（大量小请求，追求性能）来看，非常值得：

• 性能提升：跳过IIS的反向代理环节，Kestrel直接处理请求，对于高并发小请求来说，能显著减少延迟和资源开销，Kestrel的性能优势在这种场景下会体现得很明显；
• 运维不变：应用依然由IIS托管，你还是可以通过IIS管理器进行启动、停止、日志查看等操作，不需要切换到自托管模式，运维负担没有增加；
• 唯一需要注意的是安全：一定要通过防火墙限制Kestrel的端口仅对局域网开放，避免被公网访问带来安全风险。如果你的应用依赖IIS的某些特性（比如URL重写、IIS内置认证），需要确保这些逻辑已经迁移到ASP.NET Core应用内部，因为直接访问Kestrel时无法使用IIS的这些模块。

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