websocket跨域本质是服务端校验origin头而非cors：浏览器在握手时自动携带origin，服务端需显式验证并决定是否返回101响应；加access-control-allow-origin头无效，nginx需透传upgrade/connection头且慎用origin重写。
WebSocket 本身不走 HTTP 请求流程，所以CORS 对 WebSocket 连接不起作用。很多人误以为给 WebSocket 服务器加 CORS 头就能解决跨域问题，其实这是无效的。真正需要处理的是 WebSocket 握手阶段的 Origin 校验，以及前端连接时的协议和域名一致性。
WebSocket 跨域的本质不是 CORS，而是 Origin 校验
浏览器在发起 WebSocket 连接时，会带上 Origin 请求头（例如 Origin: https://myapp.com）。服务器收到握手请求后，可选择是否接受该来源——这一步才是真正的“跨域控制”。
ws、ws-lib 或 NestJS 的 WebSocket 适配器都支持手动校验 Origin，而不是依赖 CORS 中间件。
- Node.js 原生
ws库中，可在 connection 事件前通过verifyClient钩子拦截并判断 origin - NestJS 的
WebSocketGateway默认不限制 origin，需在@WebSocketServer() server实例上手动配置校验逻辑 - 若用 Nginx 反向代理 WebSocket，需确保转发时保留
Origin头，并配置Upgrade和Connection头
前后端连接 URL 必须协议一致
前端调用 new WebSocket("wss://api.example.com/ws") 时：
• 若网页是 https:// 开头，必须用 wss://（加密）；
• 若网页是 http://（本地开发），可用 ws://，但现代浏览器对混合内容限制变严，建议统一用 HTTPS + WSS。
将一个或多个视频上传至YouTube。当用户想“上传到YouTube”“发YouTube”“批量上传”“upload to YouTube”“post videos to YouTube”或发布到YouTube时使用此技能。
- 开发环境常见错误：前端跑在
http://localhost:5173，却连wss://地址 → 浏览器直接拒绝 - 生产环境典型配置：Nginx 将
/ws路径反向代理到 Node.js WebSocket 服务，并设置proxy_set_header Origin $scheme://$host; - 避免硬编码地址，前端应从环境变量或后端接口动态获取 WebSocket URL
HTTP 接口仍需正常配置 CORS
虽然 WebSocket 不受 CORS 影响，但实际项目中往往同时存在 REST API（如登录、获取历史消息、上传文件等）。这些 HTTP 接口必须正确启用 CORS，否则前端无法调用。
- Express 示例：
app.use(cors({ origin: ["https://myapp.com", "https://admin.myapp.com"] })) - NestJS 示例：全局启用
app.enableCors({ origin: [/^https?:\/\/localhost:\d+$/, "https://myapp.com"] }) - 切勿使用
*通配符配合credentials: true，会导致报错；带 cookie 的请求需明确指定 origin
安全增强：结合 JWT 和连接鉴权
Origin 校验只是第一道防线。真实业务中，应在 WebSocket 连接建立后立即完成身份验证，防止未授权客户端接入。
- 前端在
onopen后立刻发送含 JWT 的认证消息：ws.send(JSON.stringify({ type: "auth", token: "xxx" })) - 服务端收到后解析 token、查用户状态、绑定 socket 与 userId，并存入 Map 或 Redis
- 后续所有消息收发都基于该绑定关系，私聊、房间加入、权限校验才有依据
- 避免把 token 放在 URL 参数里（易泄露、有长度限制、日志风险）
不复杂但容易忽略：WebSocket 的跨域控制靠服务端主动校验 Origin，不是加个 CORS 头就行；前后端协议必须匹配；HTTP 接口和 WebSocket 连接是两套独立的安全机制，要分别加固。
