本文揭示 signalr 在 windows 10 iis 环境下因系统级并发连接限制（默认仅 10 路）引发的连锁问题：多用户场景下 signalr 连接失败、axios 请求长期处于 pending 状态，最终通过迁移至无限制的 vm os 服务器彻底解决。
本文揭示 signalr 在 windows 10 iis 环境下因系统级并发连接限制（默认仅 10 路）引发的连锁问题：多用户场景下 signalr 连接失败、axios 请求长期处于 pending 状态，最终通过迁移至无限制的 vm os 服务器彻底解决。
在基于 SignalR 构建实时竞价系统的实践中，一个看似前端的问题——“Axios 请求持续 pending”——往往并非代码逻辑缺陷，而是后端部署环境的硬性约束所致。您提供的 React 代码中，hubConnectionBuilder.start().then(...) 内嵌 axios.get(...) 的写法虽无语法错误，但其阻塞现象的根本原因在于：SignalR Hub 所依赖的底层 HTTP 服务器（IIS on Windows 10）存在严格的并发连接数上限。
Windows 10 自带的 IIS Express 或桌面版 IIS 默认仅允许 最多 10 个并发 TCP 连接（部分版本甚至限制为 3–5 个），且该限制作用于整个 HTTP 服务实例，而非单个应用。当多个用户同时建立 SignalR 长连接（每个连接占用至少 1–2 个持久化 HTTP 连接），服务器连接池迅速耗尽。此时，后续请求（包括您的 axios.get）将无法获取可用连接句柄，直接进入浏览器的 pending 队列，直至已有连接释放——这正是您观察到“刷新页面后 API 挂起，需等待其他用户刷新才恢复”的典型表现。
✅ 正确解法并非修改前端代码，而是升级部署架构：
立即规避方案：将 SignalR Hub 后端（.NET Core/.NET 5+）部署至 Linux VM、Windows Server 或云平台（如 Azure App Service、AWS EC2）。这些环境无原生连接数限制，可轻松支撑数千并发。
-
验证方式：在目标服务器上运行
dotnet publish后部署，并通过ab -n 100 -c 50 http://your-api/health压测接口，确认无 pending 积压。 -
前端优化建议（辅助提升健壮性）：
// 避免在 SignalR 连接回调内紧耦合调用 axios hubConnectionBuilder.on("SendUpcomingLots", (data: any) => { setUpcomingLots(data); }); // 将 axios 调用移出 SignalR 启动链，改用独立加载逻辑 useEffect(() => { const fetchInitialData = async () => { setLoading(true); try { await axios.get(`${APIURL}?auctionId=${ID}&customerId=${customerId}`); } catch (err) { console.error("Initial data fetch failed:", err); } finally { setLoading(false); } }; fetchInitialData(); }, [ID, customerId]); // SignalR 连接启动单独管理 useEffect(() => { const startHub = async () => { const connection = new signalR.HubConnectionBuilder() .withUrl(HUBURL, { withCredentials: true, // 若需鉴权，启用凭证（注意 CORS 配置） headers: { "X-Requested-With": "XMLHttpRequest" } }) .withAutomaticReconnect() .build(); try { await connection.start(); console.log("SignalR connected"); } catch (err) { console.error("SignalR connection failed:", err); } }; startHub(); }, []);
⚠️ 注意事项：
- 不要尝试通过
maxConnections注册表项强行突破 Windows 10 IIS 限制——该操作违反系统许可协议，且不可靠； - 确保生产环境 SignalR 配置启用
WebSockets作为首选传输协议（.withOptions({ transport: signalR.HttpTransportType.WebSockets })），避免轮询加重连接负担； - 前端应实现连接状态监控（如监听
onclose,onreconnecting），避免因重连风暴触发浏览器连接复用机制异常。
归根结底，实时系统的设计必须匹配基础设施能力。将 SignalR 后端从开发机（Windows 10 + IIS）迁移至专业服务器环境，是解决此类“伪前端问题”的关键一步——它不仅消除 pending 瓶颈，更为高并发拍卖场景提供了可伸缩、可运维的坚实基础。
