Angular访问.NET Core 5 API请求互堵、预检耗时高如何排查？

核心请求阻塞问题排查（已排除预检直接影响） #

首先针对跨页面请求排队阻塞的现象，优先排查以下几个方向：

• 服务端会话锁限制：ASP.NET Core默认启用Session时会对同一用户的Session加读写互斥锁，同一会话的所有请求会串行执行，刚好匹配你描述的同浏览器两个页面（共享同一份SessionCookie）的阻塞场景。如果你的项目中启用了app.UseSession()中间件，可以对不需要修改Session的接口添加只读Session特性，避免占用写锁，或者临时注释Session中间件测试阻塞是否消失。
• 浏览器同域名并发连接限制：主流浏览器对同一个域名的并发TCP连接数默认限制为6~8个，如果重负载页面单次发起超过该数量的请求，会占满所有可用连接，轻量页面的请求会进入浏览器等待队列。可以打开F12网络面板查看阻塞请求的Timing字段，如果Queueing或Stalled阶段耗时极高，即可确认是该问题，可通过接口合并、域名分片、HTTP/2协议升级解决。
• .NET线程池扩容延迟：.NET 5默认最小线程池数量较低，高并发场景下线程池扩容速度跟不上请求量，会导致服务端内部请求排队。可以在服务启动入口添加ThreadPool.SetMinThreads(100, 100);测试，观察阻塞是否缓解。
• Kestrel并发连接限制：Kestrel默认的最大并发连接数配置如果不匹配业务量级，也会导致请求在服务端TCP队列排队，可显式调整配置：

builder.WebHost.ConfigureKestrel(serverOptions =>
{
    serverOptions.Limits.MaxConcurrentConnections = 1000;
    serverOptions.Limits.MaxConcurrentUpgradedConnections = 1000;
});

预检请求耗时高的常见原因 #

• CORS中间件顺序错误：CORS中间件必须放在app.UseRouting()之后，app.UseAuthorization()之前，放置位置错误会导致OPTIONS请求需要走完所有前置中间件才返回，额外增加耗时。
• 未启用预检缓存：可在CORS配置中添加SetPreflightMaxAge(TimeSpan.FromMinutes(10))，让同域名的预检请求在缓存有效期内不会重复发起，大幅降低预检请求数量。
• 中间链路安全校验拦截：如果服务端前有WAF、CDN、反向代理等组件，这类组件会优先校验OPTIONS请求的合法性，额外增加耗时，可以本地直连服务端测试预检耗时，排除中间链路影响。

进一步排查操作步骤 #

1. 抓取浏览器网络日志，分析阻塞请求各阶段的耗时分布，明确耗时出现在浏览器排队、网络链路还是服务端处理环节
2. 服务端添加全链路日志，记录每个请求（含OPTIONS）的进入时间和返回时间，确认耗时是否发生在服务端内部
3. 使用匿名模式/两个不同浏览器打开两个测试页面，若阻塞消失则可定位为同Session/同域名连接限制问题
4. 用压测工具绕开前端直接并发调用服务端接口，若接口本身出现排队耗时，则可确定是服务端并发配置问题

已知相关问题 #

• .NET 5存在已知的线程池冷启动问题，低负载下最小线程数不足时，首次高并发请求会出现明显的排队延迟
• 若使用Nginx等反向代理，默认的worker_connections、keepalive_requests配置过低，也会导致连接排队，需要同步调整代理侧的并发参数

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