ASP.NET Core SignalR Hub队列滞留引发消息推送异常咨询

该类问题在SignalR生产环境部署中十分常见，绝大多数场景下并非网络断连或上游数据突增导致，而是消息发送链路存在阻塞点，消息在缓冲区堆积到阈值或阻塞解除后才会批量下发，可按以下优先级定位解决：

高概率根因排查（覆盖90%同类场景） #

• 检查runtime service的发送代码是否存在同步阻塞异步方法的写法：如果调用IHubContext.Clients.SendAsync()时使用了.Result、.Wait()做同步等待，会直接占用阻塞线程池线程，当线程池工作线程被耗尽时，所有发送请求会进入队列排队，直到线程池按算法补充新的工作线程后才会批量执行，排队时间正好对应1-2分钟的无数据窗口。
• 检查反向代理配置：如果服务端前置了Nginx、IIS、云厂商负载均衡，默认开启的响应缓冲机制会攒够一定大小的响应包才会转发给客户端，小体量实时消息很容易在代理层攒几十秒到数分钟，凑够批量后一次性推给客户端。
• 核对保活时间配置：SignalR默认的WebSocket保活间隔为2分钟，和描述的无数据时间窗口完全吻合。如果代理层的空闲连接超时小于2分钟，TCP连接不会断开，但应用层转发会被代理暂停，直到保活探测包触发链路恢复后，堆积的消息才会一次性下发。

次高概率问题排查 #

• 检查SignalR服务端默认缓冲区配置：框架默认DefaultMessageBufferSize值为32，单连接待发送消息超过阈值后，新消息会进入排队等待，不会立刻下发。
• 检查消息发送逻辑是否配置了同步等待回执：如果发送代码中要求客户端逐帧返回ACK才会发送下一条消息，一旦某条消息的应用层ACK丢包（TCP层连接稳定不代表应用层消息不丢包），后续所有消息会卡在发送队列，直到ACK等待超时后才会继续发送。
• 检查生命周期注册是否错位：如果runtime service注册为单例（Singleton），不要直接在服务构造函数中获取IHubContext实例，避免Scoped生命周期的Hub上下文被单例服务持有导致的发送锁问题。
• 检查序列化逻辑：如果消息体存在循环引用、超大嵌套对象，序列化过程会长时间占用线程，导致后续发送任务排队。

可直接落地的修复方案 #

• 修正所有发送逻辑的异步写法：全程使用await调用SendAsync()，禁止使用.Result、.Wait()做同步阻塞，调用时传入合理的CancellationToken，避免单个发送任务长期占用线程。
• 调整SignalR服务端基础配置，在AddSignalR注册段修改默认参数：

builder.Services.AddSignalR(options =>
{
    // 根据单连接消息峰值调大缓冲区，常规业务设置128即可
    options.DefaultMessageBufferSize = 128;
    // 保活间隔调整为30秒，避开代理层默认的90秒空闲超时阈值
    options.KeepAliveInterval = TimeSpan.FromSeconds(30);
    options.ClientTimeoutInterval = TimeSpan.FromSeconds(60);
});

• 关闭反向代理层的响应缓冲，以Nginx为例，在SignalR路由对应的配置段添加以下参数：

# 关闭代理缓冲
proxy_buffering off;
proxy_cache off;
# 调整长连接超时
proxy_read_timeout 300s;
proxy_send_timeout 300s;
# 开启WebSocket协议升级支持
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";

• 给发送链路加简单埋点：记录每次SendAsync的执行耗时，如果耗时突增到秒级，即可确认是发送链路阻塞，无需排查上游数据生产环节。

排查时优先看同步阻塞代码和Nginx缓冲配置，这两个原因占同类问题的90%以上，基本可以快速定位修复。

内容的提问来源于stack exchange，提问作者Khoa trần