WebSocket安全白名单必须在服务端握手阶段实现，通过校验Origin头、URL中的Token及客户端IP，并结合动态策略管理与日志审计，确保非法连接在Upgrade前被拒绝。
WebSocket 本身不内置白名单机制，安全白名单需在服务端（而非客户端）实现，核心是在握手阶段（HTTP Upgrade 请求）校验来源、域名、Token 或 IP，拒绝非法连接请求。
校验 Origin 头防止跨站滥用
浏览器发起 WebSocket 连接时会自动带上 Origin 请求头（如 Origin: https://admin.example.com），服务端可比对预设的可信域名列表。注意：Origin 可被非浏览器客户端伪造，仅适用于防范普通 Web 页面的误连或恶意页面调用，不能作为唯一验证手段。
- Node.js（ws 库）示例：
- 在
verifyClient钩子中读取info.origin - 匹配白名单数组（如
['https://app.example.com', 'https://dashboard.example.com']） - 不匹配则返回
callback(false)拒绝握手
结合 Token 或 Session 鉴权
单纯依赖 Origin 不够安全，建议在 URL 中传递一次性 Token（如 ws://example.com/ws?token=abc123），服务端在握手时验证其有效性、时效性和绑定关系（如关联用户 ID 或设备指纹）。
- Token 应由后端签发，带签名和过期时间（如 JWT）
- 验证通过后，可将用户身份信息挂载到 WebSocket 实例上（如
ws.userId = 123） - 避免在前端硬编码长期有效的 Token
限制 IP 或网络段（适用于内网/可信环境）
若 WebSocket 服务部署在受控网络（如企业内网），可在握手前获取客户端真实 IP（注意代理场景需解析 X-Forwarded-For），并与白名单 IP 段比对。
立即学习“Java免费学习笔记（深入）”；
- 使用
info.req.socket.remoteAddress获取原始 IP - 对公网服务慎用纯 IP 白名单（NAT、CDN 会掩盖真实 IP）
- 配合反向代理（如 Nginx）做前置过滤更可靠
服务端统一入口 + 动态策略管理
把白名单逻辑抽离为可配置模块，支持运行时更新（如从数据库或配置中心加载），避免重启服务。例如：维护一张 ws_whitelist 表，字段含 domain、allowed_paths、is_active。
- 每次握手都触发策略检查，支持按域名、路径、Token 类型组合判断
- 记录拒绝日志（含 Origin、IP、时间戳），便于审计和告警
- 对高频拒绝请求可临时加入黑名单（如 5 分钟内同一 IP 多次失败）
不复杂但容易忽略：所有校验必须发生在 WebSocket 握手完成前，一旦连接建立，后续通信不再经过 HTTP 层，无法再拦截或中断连接。所以白名单必须守住 Upgrade 这一道门。
