Google Cloud负载均衡与Windows VM的SignalR CORS连接问题

核心原因分析 #

你的问题大概率出在负载均衡对OPTIONS预请求的处理上，而非SignalR服务本身的CORS配置：

• 前端发起SignalR协商请求时，浏览器会先发送OPTIONS预请求验证CORS权限
• 你在负载均衡添加的自定义响应头没生效，很可能是负载均衡没有把OPTIONS请求转发到后端VM，导致预请求的响应完全由负载均衡生成（而负载均衡默认不会正确处理CORS的预请求逻辑）
• 跳过协商能正常连接，是因为跳过了预请求环节，直接建立WebSocket连接，绕开了CORS校验

具体排查与修复步骤 #

1. 检查负载均衡的路由规则是否包含OPTIONS方法 #

GCP的HTTP(S)负载均衡默认不会自动转发OPTIONS请求到后端，需要手动配置：

• 进入GCP控制台的负载均衡页面，找到你的负载均衡器
• 编辑后端服务的主机和路径规则，确保规则允许的HTTP方法包含OPTIONS（默认可能只包含GET、POST等）
• 保存配置后，测试预请求是否能到达VM的SignalR服务

2. 验证VM上的SignalR服务是否正确处理OPTIONS请求 #

虽然之前直接访问正常，但负载均衡转发的OPTIONS请求可能因为路径前缀（/abc）的问题，导致SignalR的CORS中间件没有捕获到：

• 在VM上启用请求日志，查看是否收到来自负载均衡的OPTIONS请求
• 确认SignalR的CORS配置是否包含了完整的请求路径匹配，或者是否正确处理了带前缀的路由（因为负载均衡把/abc路由到VM的SignalR服务，需要确保CORS中间件对/abc/*路径生效）

3. 调整负载均衡的CORS配置（替代方案） #

如果不想修改后端服务，可在GCP负载均衡中配置完整的CORS策略，而非仅添加单个响应头：

• 进入负载均衡的边缘服务配置，找到CORS设置
• 配置允许的源为http://localhost:3000，允许的方法包含GET, POST, OPTIONS，允许的头包含SignalR需要的Content-Type, X-Requested-With等
• 确保配置中开启了处理预请求的选项，让负载均衡自动生成符合要求的预请求响应

4. 确认SSL终止后的协议问题 #

负载均衡做了SSL终止，转发到VM的是HTTP请求，需要确保SignalR服务的CORS配置中，允许的源是http://localhost:3000（而非HTTPS，因为前端是HTTP本地服务），同时服务端的CORS中间件要正确识别转发后的请求源（如果负载均衡添加了X-Forwarded-For等头，需要配置SignalR信任这些转发头）

关键验证点 #

用curl发送OPTIONS预请求测试：

curl -X OPTIONS https://api.example.com/abc/negotiate?negotiateVersion=1 -H "Origin: http://localhost:3000" -v

查看响应头是否包含Access-Control-Allow-Origin: http://localhost:3000，如果没有，说明预请求没有被正确处理。

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