如何阻止外部用户非法连接站点的wss协议websocket服务？

你当前使用的ReCAPTCHA校验属于基础人机防护方案，可通过分层防护的组合策略进一步提升安全性，同时降低正常用户的使用成本，具体可落地的方案如下：

1. 替换单次ReCAPTCHA令牌为短时效一次性连接令牌 #

用户在前端完成人机校验/登录后，由后端生成有效期5分钟内、与当前用户IP、UA信息绑定、仅可使用一次的JWT连接令牌。
用户发起Socket.IO连接时，必须将该令牌放在auth参数中携带，后端在校验时只要发现令牌过期、绑定信息不匹配、已被使用过的情况，直接拒绝连接请求，避免ReCAPTCHA令牌被抓包复用的风险。
示例连接代码：

const {io} = require("socket.io-client");
const socket = io("wss://example.com", {
  auth: {
    token: "后端下发的短时效一次性令牌"
  }
});

2. 接入层前置拦截恶意请求 #

在Nginx/CDN等接入层提前做规则拦截，降低后端服务的压力：

• 限制单个IP 1分钟内的Socket.IO连接请求次数不超过5次，超过阈值直接拉黑该IP 1小时
• 校验请求的Origin头，仅允许你自有站点域名的请求通过，非法来源直接返回403
• 要求请求必须携带你自定义的站点标识请求头，无该头的请求直接拦截，提升攻击者的伪造成本

3. 连接成功后做细粒度权限与流控 #

不要在连接成功后直接放开所有接口权限：

• 每个事件触发时都做权限校验，匿名用户仅允许调用公开事件，敏感操作事件必须绑定已登录的用户态才可调用
• 对单个连接的事件发送频率做限流，比如1秒内最多允许发送10次事件，超过阈值直接主动断开连接

4. 传输内容自定义混淆 #

前后端约定一套非对称/对称加密规则，对Socket.IO传输的事件名、请求参数做加密处理，后端解密后再做业务处理，攻击者即使能发起连接，也不知道要传输的内容格式，大幅降低被批量滥用的风险

如果你的站点本身需要用户登录才可使用，可直接取消登录用户的ReCAPTCHA校验，直接用登录态生成的短令牌做校验即可，在提升安全性的同时还能优化正常用户的使用体验。

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