Azure上ASP.NET Core 2.0 SignalR的WebSocket并发连接限制问题

嘿，针对你遇到的ASP.NET Core 2.0 SignalR部署到Azure后并发连接被限制在5个的问题，我来给你梳理几个关键的解决方向——毕竟ASP.NET Core确实不用传统的web.config，咱们得用Core的方式来调整，同时还要注意Azure平台本身的限制：

1. 先排查Azure App Service的层级限制 #

免费层（F1）、共享层（D1）的并发连接数本身就有严格的平台硬限制，F1默认刚好就是5个左右的并发连接，这和你的代码无关。如果你的应用部署在这些层级，优先考虑升级到基本层（B1/B2/B3）或者标准层（S1/S2/S3），这些层级不仅并发连接数上限高很多，还能完整支持SignalR依赖的WebSocket传输功能。

2. 配置Kestrel服务器的连接参数 #

ASP.NET Core用Kestrel作为内部服务器，你可以在Program.cs里直接调整它的并发连接限制：

public static IWebHost BuildWebHost(string[] args) =>
    WebHost.CreateDefaultBuilder(args)
        .UseStartup<Startup>()
        .UseKestrel(options =>
        {
            options.Limits.MaxConcurrentConnections = 1000; // 按需调整总并发数
            options.Limits.MaxConcurrentUpgradedConnections = 1000; // 重点！控制WebSocket这类升级后的连接数
        })
        .Build();

这里的MaxConcurrentUpgradedConnections特别关键，因为SignalR使用WebSocket时是通过HTTP升级协议建立的连接，这个参数专门管控这类连接的上限。

3. 优化SignalR的传输配置 #

确保SignalR优先使用效率最高的WebSocket传输，在Startup.cs的ConfigureServices里配置：

services.AddSignalR(options =>
{
    options.EnableDetailedErrors = true; // 排查问题时开启，生产环境可关闭
    options.MaximumReceiveMessageSize = 102400; // 根据你的消息大小调整
})
.AddWebSocketTransport(); // 显式启用WebSocket传输

客户端连接时也可以指定只使用WebSocket，避免 fallback 到效率较低的轮询方式：

const connection = new signalR.HubConnectionBuilder()
    .withUrl("/yourHubPath", { transport: signalR.HttpTransportType.WebSockets })
    .build();

4. 开启Azure App Service的WebSocket支持 #

在Azure门户里找到你的App Service，进入配置 > 常规设置，确保WebSocket选项是开启的——低层级的App Service默认可能关闭这个选项，会导致SignalR无法使用WebSocket，间接限制了并发数。

5. 高并发场景推荐用Azure SignalR Service #

如果你的并发需求很高（比如上千甚至上万连接），直接用App Service部署SignalR不是最优解。推荐使用Azure SignalR Service，这是微软托管的专门处理高并发SignalR连接的服务，和ASP.NET Core SignalR无缝集成，只需要少量配置：

• 安装NuGet包Microsoft.Azure.SignalR
• 在Startup.cs里替换SignalR服务：

services.AddSignalR()
    .AddAzureSignalR(Configuration["Azure:SignalR:ConnectionString"]);

所有连接都会由Azure SignalR Service处理，彻底避开App Service本身的连接限制，性能和可靠性也会大幅提升。

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