Spring WebSocket用80端口握手失败（400错误），8080正常求助

这个问题我之前帮不少开发者排查过，80端口作为默认HTTP特权端口，经常会因为环境或配置的特殊要求导致WebSocket握手异常，结合你在多台Tomcat服务器上都复现的情况，给你几个优先级从高到低的排查方向：

1. 先排查客户端URL的低级错误 #

浏览器报错里的ws//..明显格式有误，正确的WebSocket URL应该是ws://xxx（少了一个冒号）。先检查前端代码里的WebSocket连接地址，切换到80端口后是否没有正确拼接URL，比如把ws://localhost:80/ws写成了ws//localhost:80/ws——这种小问题很容易被忽略，但却是400错误的常见诱因。

2. 端口权限与系统级拦截检查 #

80端口是系统特权端口，在Linux/Unix类系统中，普通用户启动的Tomcat可能无法绑定80端口，导致实际监听失败。

• 查看Tomcat启动日志，确认是否有Address already in use或Permission denied这类绑定80端口失败的提示；
• 如果是云服务器，检查安全组、防火墙（比如iptables、ufw）是否允许80端口的WebSocket流量（本质是HTTP GET升级请求）通过。

3. 反向代理/负载均衡的WebSocket配置问题 #

如果你的Tomcat前面部署了Nginx、Apache这类反向代理，80端口的请求会先经过代理再转发到Tomcat，此时代理很可能没有正确处理WebSocket的升级协议：

• 以Nginx为例，需要在对应location块中添加WebSocket支持配置：

location /ws {
    proxy_pass http://your-tomcat-addr:8080;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_set_header Host $host;
}

确保代理没有过滤掉Upgrade和Connection这两个WebSocket握手的核心请求头。

4. Spring Security的CSRF与跨域配置调整 #

Spring Security默认会对WebSocket请求做CSRF校验，切换到80端口后，可能因域名/端口变化导致CSRF Token不匹配：

• 在Spring Security配置中，放行WebSocket端点的CSRF校验：

@Override
protected void configure(HttpSecurity http) throws Exception {
    http.csrf(csrf -> csrf.ignoringRequestMatchers("/ws/**")); // 替换为你的实际WebSocket端点路径
}

• 同时确认跨域（CORS）配置允许WebSocket的请求方法和头信息，避免因跨域规则拦截握手请求。

5. Tomcat的WebSocket支持配置检查 #

虽然Tomcat默认支持WebSocket，但自定义Connector配置可能漏掉关键设置：

• 检查server.xml中80端口的Connector，确保使用NIO协议（WebSocket依赖非阻塞IO）：

<Connector port="80" protocol="org.apache.coyote.http11.Http11NioProtocol"
           connectionTimeout="20000"
           redirectPort="443" />

• 排查web.xml中是否有自定义过滤器拦截了WebSocket的升级请求，比如某些安全过滤器可能把WebSocket请求当成普通HTTP请求处理，导致握手失败。

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