websocket跨域握手被origin拦截本质是服务端在http upgrade阶段校验origin头失败，需后端显式白名单放行（如spring设setallowedoriginpatterns("*")）、nginx透传origin头，而非添加cors响应头。
WebSocket 跨域握手被 Origin 拦截，本质不是 WebSocket 协议本身限制，而是服务端在 HTTP 握手阶段（即 Upgrade 请求）校验了请求头中的 Origin，并拒绝了非白名单来源——这属于服务端主动拦截，浏览器不会报 CORS 错，而是直接断开连接、控制台显示类似 WebSocket connection to 'ws://...' failed: Error during WebSocket handshake。
服务端必须显式允许 Origin（关键）
WebSocket 握手是基于 HTTP 的，服务端（如 Node.js 的 ws、socket.io，或 Java 的 Spring WebSocket）默认通常不自动信任任意 Origin。你必须在服务端代码中明确检查并响应 Origin 头：
- 使用
ws库时，在new WebSocket.Server({ verifyClient })中手动验证info.origin，合法则调用callback(true)；不校验或校验失败就调用callback(false)，握手即失败 - Spring WebSocket 需在配置中设置
setAllowedOrigins(Arrays.asList("https://your-domain.com", "http://localhost:3000"))，不能写*（除非不带凭证） - 若服务端用了反向代理（如 Nginx），确保它透传了
Origin头（添加proxy_set_header Origin $http_origin;）
前端创建时 Origin 无法伪造，但可确认是否匹配
浏览器自动发送当前页面的 Origin（协议 + 域名 + 端口），前端无法修改它。你只需确保：
- 前端页面 URL 和 WebSocket 构造函数里的 URL 协议一致（比如页面是
https://a.com，就别连ws://b.com；应改用wss://b.com） - 开发时本地服务（如
http://localhost:3000）需被后端明确加入允许列表，不能只配生产域名 - 避免在非 web 环境（如 Electron、React Native）中误用浏览器 API；这些环境可能 Origin 不标准，需服务端兼容处理
不带凭证时可放宽 Origin（谨慎使用）
如果 WebSocket 连接不涉及 Cookie 或 HTTP 认证，且服务端未要求凭证，部分框架允许设 allowedOrigins = ["*"]。但注意：
-
ws库不支持"*"通配符，必须显式列出或写逻辑放行 - Spring 中
setAllowedOrigins("*")仅在withCredentials = false时生效；若前端设置了websocket.binaryType = "arraybuffer"等不影响凭证，但只要服务端启用了凭证校验，"*"就非法 - 生产环境强烈建议精确配置 Origin，而非开放
"*"
调试技巧：抓包看真实 Origin 头
浏览器开发者工具的 Network 标签页默认不显示 WebSocket 握手的请求头。可用以下方式确认实际发出的 Origin：
- 用 Chrome 启动时加参数：
chrome --unsafely-treat-insecure-origin-as-secure="http://localhost:8080" --user-data-dir=/tmp/chrome-test，再配合 F12 查看 WS 握手的 Headers - 用 Wireshark 或
tcpdump抓包，过滤http.request.uri contains "upgrade"，查看原始 HTTP 请求头 - 在服务端
verifyClient或拦截器里打印info.origin，直观看浏览器传了什么
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
