同服务器部署下Angular与Spring WebSocket的CORS问题咨询

问题背景 #

你的Angular前端与Spring Boot后端同服务器部署，但未配置Spring WebSocket的CORS规则时，前端WebSocket连接失败（关闭状态码1006），Postman却能正常连接，配置setAllowedOrigins后问题解决。下面解释这种现象的核心原因：

1. 浏览器同源策略的判断逻辑：并非仅看服务器是否相同 #

浏览器的同源策略是基于「协议+域名+端口」三者完全匹配来判断的，哪怕前端和后端部署在同一物理服务器上，只要满足以下任一情况，就会被判定为跨源：

• 前端与后端的访问端口不同（比如前端通过服务器80/443端口访问，后端实际监听8080端口，通过反向代理对外暴露）
• 前端的访问域名（比如https://yourdomain.com）与后端服务的实际地址（比如容器内部的http://backend:8080）不匹配

你的Angular代码中使用wss://${window.location.host}/websocket，意味着浏览器发送WebSocket握手请求时，Origin头会被设置为前端页面的访问地址（比如https://yourdomain.com），如果Spring Boot后端未将该地址加入允许列表，就会触发CORS拦截。

2. WebSocket握手阶段依赖HTTP请求，受CORS规则约束 #

WebSocket连接的建立并非直接建立TCP连接，而是先发送一个HTTP握手请求（通常是GET请求，携带Upgrade: websocket等头信息），这个握手请求必须符合浏览器的CORS规则：

• 后端必须返回允许该Origin的响应头，否则浏览器会直接终止握手流程，最终导致WebSocket连接异常关闭（状态码1006正是表示连接无正常关闭帧的异常中断）
• Postman等非浏览器工具不受同源策略限制，无需校验Origin头，因此可以正常完成握手并建立连接

3. Docker多阶段部署的端口映射/反向代理可能隐藏跨源场景 #

在Docker多阶段部署中，前端和后端通常运行在各自的容器内，即使最终通过Nginx等反向代理统一对外暴露域名，浏览器感知到的Origin是用户访问的前端地址，而后端服务的实际地址是容器内部的网络地址（比如http://websocket-service:8080），两者的Origin不匹配，就会触发Spring WebSocket的CORS拦截逻辑。

结合你的代码验证 #

你的Spring Boot配置中，setAllowedOrigins(hostUrl)指定了允许的Origin地址，这个地址正是前端页面的访问地址，因此握手请求通过校验，WebSocket连接正常建立。如果未配置该规则，Spring WebSocket默认会拒绝所有跨源的Origin请求，导致浏览器端连接失败。

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