Azure容器应用网关（Application Gateway for Containers）对WebSocket连接返回403错误

看起来你遇到了Azure容器应用网关（AGC）拦截WebSocket（WSS）连接返回403的问题，结合你提到的其他环境正常、请求根本没到应用的情况，大概率是AGC的配置细节没覆盖WebSocket的场景，我来帮你梳理几个排查和修复方向：

• 检查AGC的路由规则是否允许WebSocket协议
  AGC默认不会自动启用WebSocket支持，需要在路由规则里明确放行带有Upgrade: websocket和Connection: Upgrade的请求。很多时候AGC会把这类不符合常规HTTP/HTTPS模式的请求当成非法请求拦截，直接返回403。你可以去AGC的路由配置里，添加针对这两个请求头的匹配规则，允许此类请求转发到后端服务。

• 确认Ingress资源的注解配置
  即使你觉得Ingress没有相关配置，和AGC集成的K8s Ingress控制器通常需要特定注解来开启WebSocket支持。比如，尝试给你的Ingress资源添加appgw.ingress.kubernetes.io/websocket-support: "true"注解，这个注解会告诉AGC要处理WebSocket类型的连接。另外，再核对下Ingress的TLS配置是否正确关联了AGC的证书，确保WSS的TLS终止环节没有异常。

• 查看AGC的访问日志和诊断日志
  既然请求没到达应用，那肯定是AGC这边拦截了，你可以去Azure门户的AGC资源里找到「日志」模块，搜索对应的WSS请求记录，查看403错误的详细原因——比如是路由规则不匹配、协议不允许还是安全策略触发。这些日志信息能帮你精准定位问题点。

• 检查AGC的Web应用防火墙（WAF）规则
  如果你的AGC启用了WAF，默认规则集可能会把WebSocket握手请求识别为潜在威胁并拦截。你可以查看WAF的拦截日志，找到对应的规则ID，然后添加例外规则或者调整该规则的拦截级别，允许WebSocket相关的请求通过。

• 测试直接绕过AGC的连接
  临时把应用服务通过NodePort或者LoadBalancer暴露出来，直接访问WSS端点，确认应用本身能正常处理WebSocket连接。这一步可以彻底排除应用自身的问题，坐实是AGC的配置导致的拦截。

备注：内容来源于stack exchange，提问作者StrangeWill