部署于Azure Kubernetes Service的.NET Core应用（集成Azure SignalR免费层）与Angular前端WebSocket连接失败及CORS问题排查求助

看起来你在部署.NET Core+Angular应用到AKS时，碰到了WebSocket连接失败和CORS跨域的双重问题，结合你给出的配置和错误日志，咱们一步步来梳理解决思路：

一、先搞定CORS跨域问题 #

从浏览器的CORS错误信息来看，核心问题是后端返回的Access-Control-Allow-Origin和实际请求的Origin不匹配：

• 你后端CORS策略里只允许了https://somebackendserver.com，但实际请求的Origin是https://XXXX.dev.XXXXXX.com，而且响应头返回的是https://portal.api.dev.XXXX.com——这说明要么是你配置的允许Origin不对，要么是Kong网关在转发时修改了请求/响应头。

1. 修正后端CORS配置 #

首先把前端实际的域名加入到允许列表里，同时注意CORS中间件的顺序（必须放在路由之后、端点之前）：

services.AddCors(options => options.AddPolicy("testing", builder => { 
    // 替换成你实际的前端域名，多个的话用逗号分隔
    builder.WithOrigins("https://XXXX.dev.XXXXXX.com", "https://somebackendserver.com"); 
    builder.AllowCredentials(); 
    builder.AllowAnyHeader(); 
    builder.AllowAnyMethod(); 
    // 如果Kong转发时会篡改Origin，测试环境可以临时用这个（生产不建议）
    // builder.SetIsOriginAllowed(origin => true);
}));

// 注意顺序：UseRouting -> UseCors -> UseEndpoints
app.UseRouting();
app.UseCors("testing"); 
app.UseEndpoints(configure => { configure.MapHub<GenerationNotificationHub>("/hub"); });

2. 检查Kong网关的CORS插件 #

如果Kong也配置了CORS插件，它很可能会覆盖后端返回的CORS头。建议：

• 先临时禁用Kong的CORS插件，测试是否还出现Origin不匹配的问题；
• 如果必须保留Kong的CORS插件，确保插件里配置的allowed_origins包含前端的实际域名，并且和后端配置保持一致。

二、排查WebSocket连接失败问题 #

本地正常但AKS部署后失败，结合Kong和Azure SignalR的场景，从这几个方向入手：

1. 确保Kong支持WebSocket转发 #

Kong默认不会自动处理WebSocket连接，需要在路由配置里开启支持：

• 把Kong路由的protocols设置为["http", "https", "ws", "wss"]；
• 确保Kong没有拦截WebSocket的关键请求头：Upgrade、Connection、Sec-WebSocket-Key、Sec-WebSocket-Version，这些头是WebSocket握手必须的。

2. 调整前端SignalR连接配置 #

你当前的代码强制跳过了协商（skipNegotiation: true）并指定WebSocket传输，但结合Azure SignalR的工作方式，这可能有问题：

• 当后端用AddAzureSignalR()时，客户端需要先和后端完成协商，才能由Azure SignalR接管连接。跳过协商会导致连接无法正确路由到Azure的服务。
• 建议先移除这两个配置，让SignalR自动选择传输方式，同时开启日志方便排查：

public createConnection = (): void => { 
    this.hubConnection = new signalR.HubConnectionBuilder() 
        .configureLogging(signalR.LogLevel.Information) // 改成Info级，方便看连接过程
        .withUrl(`https://somebackendserver.com/hub`, { 
            accessTokenFactory: () => this.sessionService.get(SignalrNotificationService.accessTokenStorageKey), 
            // 移除skipNegotiation和强制transport的配置
        }) 
        .withAutomaticReconnect() 
        .build(); 
    this.hubConnection.start()
        .then(() => console.log("SignalR连接成功！"))
        .catch(err => console.error("连接失败：", err)); 
}

3. 检查后端Pod到Azure SignalR的连通性 #

服务端日志显示Unable to connect to the remote server. Received an unexpected EOF，说明后端Pod无法连接到Azure SignalR Service：

• 先验证connectionStringSignalR是否正确，确认Endpoint和Access Key没有写错；
• 检查AKS集群的出站规则：确保允许Pod访问*.service.signalr.net的443端口，如果用了Network Policy，要添加出站允许规则；
• 可以在AKS Pod里执行curl -v https://xxx.service.signalr.net测试连通性，看是否能正常建立SSL连接。

4. AKS服务与Ingress配置检查 #

如果用了Ingress（比如NGINX Ingress），需要配置支持WebSocket：

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    # 指定支持WebSocket的后端服务
    nginx.ingress.kubernetes.io/websocket-services: "你的后端服务名称"
    # 延长超时时间，避免WebSocket连接被主动断开
    nginx.ingress.kubernetes.io/proxy-read-timeout: "3600"
    nginx.ingress.kubernetes.io/proxy-send-timeout: "3600"

三、Postman测试小技巧 #

用Postman测试WebSocket时，注意这几点：

• 用wss://somebackendserver.com/hub作为URL（是wss不是https）；
• 如果需要AccessToken，在请求头里加上Authorization: Bearer <你的令牌>；
• 先解决CORS问题再测试，否则跨域错误会干扰WebSocket连接测试。

最后建议的排查顺序：先跳过Kong，直接在AKS内部访问后端Pod的IP测试SignalR连接，确认后端和Azure SignalR的连通性正常，再加入Kong网关测试，这样能快速定位是后端配置问题还是网关的问题。

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