SignalR Service经Azure Function连接：CORS部分机器正常部分失败求助

我的Web应用通过Azure Function连接Serverless SignalR Service时，大部分机器均可正常连接，但在某台工作机器上，仅发送了针对function-url.com/negotiate?negotiateVersion=1的初始OPTIONS请求，却未紧接着发送第二个针对signalr-service-url.com/client/negotiate?hub=roomfunctions&negotiateVersion=1的OPTIONS请求。尽管SignalR服务默认允许所有域，但缺少该请求会导致连接失败——所有正常工作的机器都会发送第二个OPTIONS请求。

客户端连接逻辑简单明确，且在几乎所有机器上都能正常运行；另有一个架构和配置几乎相同的SignalR应用，在这台故障机器上却能正常工作。

故障机器请求截图：

正常机器请求截图：

客户端连接代码：

let conn = new signalR.HubConnectionBuilder()
  .withAutomaticReconnect()
  .withUrl(url, {
    headers: {
      'x-ms-signalr-user-id': user.id,
    },
  })
  .build()

conn.onclose(() => {
  console.log('signalr connection closed')
})

conn.onreconnecting(() => {
  console.log('signalr reconnecting')
})

conn.onreconnected(() => {
  console.log('signalr reconnected')
})

await conn.start()

排查方向建议 #

• 浏览器扩展/缓存干扰：清除浏览器缓存，禁用所有扩展后重试。广告拦截、隐私保护类扩展可能拦截跨域请求，尤其是SignalR服务相关的请求。
• 企业网络规则限制：工作机器处于内网时，代理或防火墙可能拦截了第二个OPTIONS请求。对比正常机器的网络配置，联系IT确认是否存在针对signalr-service-url.com的拦截规则。
• 浏览器版本兼容性：检查故障机器的浏览器版本，尝试升级到最新稳定版。不同版本的浏览器对SignalR客户端的支持可能存在差异。
• CORS响应缓存问题：在浏览器开发者工具中勾选「Disable cache」后重新测试，避免旧的CORS响应缓存导致请求被拦截。
• SignalR客户端版本差异：确认故障机器加载的@microsoft/signalr版本与正常机器一致，不同版本的协商流程可能存在差异。
• 初始请求响应分析：查看第一个OPTIONS请求的响应头，重点检查Access-Control-Allow-Origin、Access-Control-Allow-Methods等CORS字段是否存在异常，这可能导致客户端终止后续请求。

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