1. WebSocket 连接失败这不是“连不上”的模糊抱怨而是协议层、网络层、代理层、应用层四重关卡的精准排障现场WebSocket 不是 HTTP 的升级版它是 HTTP 的“脱胎换骨”。一次成功的 WebSocket 连接本质是一次精心设计的“握手协议”——客户端先发一个 HTTP GET 请求带上Upgrade: websocket和Connection: Upgrade头服务端如果支持就返回101 Switching Protocols状态码之后双方就彻底脱离 HTTP 协议栈进入全双工、低开销的二进制帧通信模式。这个看似简单的“101”背后横亘着至少四道必须全部通关的关卡协议握手是否合规、TCP 连接是否可达、TLS 加密通道是否成功协商、反向代理是否正确透传升级请求。我见过太多人把ERR_CONNECTION_REFUSED和ERR_CONNECTION_TIMED_OUT当成一回事结果在代码里反复改ws://和wss://却没意识到问题出在 Nginx 配置里少了一行proxy_http_version 1.1也见过开发同学对着400 Bad Request抓耳挠腮最后发现是前端 JavaScript 里new WebSocket(ws://example.com)的 URL 没带端口而服务端监听的是非标准端口 8080。这根本不是“连接失败”这是四个不同层面的“协议失联”。你遇到的每一个错误码、每一条日志、每一次浏览器控制台里的红色报错都是某一层关卡亮起的红灯。本文不讲抽象理论只复盘我在电商实时库存系统、在线教育音视频信令、金融行情推送三个高并发项目中亲手排查、修复、加固过的全部真实故障场景。从最基础的netstat -an | grep :8080到 Nginx 的upstream超时配置从 Chrome DevTools 的 Network → WS → Frames 面板逐帧分析到 Wireshark 抓包看 TLS 握手是否完成再到 Spring Boot 应用层OnOpen方法里加log.info(Handshake success!)打点验证——所有步骤都经过生产环境千次锤炼。如果你正在被WebSocket is closed before the connection is established、Failed to execute send on WebSocket: Still in CONNECTING state或者Error during WebSocket handshake: Unexpected response code: 502困扰那么接下来的内容就是你立刻能抄作业的排障手册。2. 四重关卡深度拆解为什么“连不上”从来不是单一原因2.1 第一关协议握手HTTP Upgrade是否真正启动WebSocket 的生命始于一次 HTTP 请求。它不是一个独立协议而是 HTTP 协议的一个“扩展协商机制”。客户端发送的初始请求必须严格满足 RFC 6455 规范否则服务端直接拒绝连“握手”环节都不会触发。我曾经在一个 Vue 3 项目里踩过坑前端使用socket.io-client但后端没配 Socket.IO 服务只起了一个原生 WebSocket Server。结果浏览器控制台报Error during WebSocket handshake: Unexpected response code: 200。为什么是 200因为socket.io-client默认会先发一个 HTTP GET/socket.io/?EIO4transportpollingt...服务端如果没处理这个路径就返回了默认的 200 HTML 页面而不是101 Switching Protocols。这根本不是 WebSocket 连接失败是客户端和服务器压根没对上“暗号”。核心检查点有三个请求头是否完整且正确必须包含Upgrade: websocket、Connection: Upgrade、Sec-WebSocket-Key由浏览器自动生成无需手动设置、Sec-WebSocket-Version: 13。任何一项缺失或拼写错误比如upgrade写成Upgrade大小写在某些严格中间件里会校验服务端都会返回 400。请求方法必须是 GETPOST、PUT 等其他方法直接被拒绝。URL Scheme 必须匹配后端监听协议前端new WebSocket(ws://host:port/path)对应后端ws://监听new WebSocket(wss://host/path)则要求后端必须是wss://即 TLS 已终止于服务端如 Tomcat 的 SSL Connector或由前置 LB 终止。提示Chrome DevTools 的 Network 面板里找到那个状态码为101的请求点击它切换到 “Headers” 标签页。向下滚动你会看到 “Request Headers” 和 “Response Headers”。重点确认Request Headers里有没有Upgrade和ConnectionResponse Headers里有没有Upgrade: websocket和Connection: Upgrade。如果没有说明第一关就失败了问题一定出在客户端发起请求的环节或者中间某个网关/防火墙主动剥离了这些头。2.2 第二关TCP 连接是否物理可达协议握手再完美如果底层 TCP 连接都建立不了一切归零。这层失败的表现通常是ERR_CONNECTION_REFUSED目标端口无进程监听或ERR_CONNECTION_TIMED_OUT网络路径不通。很多人会下意识认为“服务器 ping 得通所以网络没问题”这是巨大误区。Ping 使用 ICMP 协议而 WebSocket 使用 TCP 协议防火墙可以放行 ICMP却严格封锁特定 TCP 端口。实操排查必须分三步走本地验证在浏览器所在机器或你的开发机上用telnet host port或nc -zv host port命令测试。例如nc -zv echo.websocket.org 80。如果返回Connection refused说明目标主机的该端口没有服务在监听或者被本机防火墙拦截。如果超时则说明网络路径上有设备如公司出口防火墙、云服务商安全组阻止了该端口的入站连接。服务端验证登录到你的 WebSocket 服务器执行netstat -tuln | grep :端口号。例如netstat -tuln | grep :8080。如果没有任何输出说明你的应用根本没有成功绑定到该端口。常见原因包括Spring Boot 的server.port8080配置被覆盖Node.js 的server.listen(8080)被异常中断Docker 容器内应用监听localhost:8080但宿主机映射端口时用了-p 8080:8081导致端口错位。路径验证如果前两步都 OK但外部仍无法访问问题一定在中间网络设备。检查云服务器阿里云、腾讯云、AWS的安全组规则确保入方向Inbound规则放行了你的 WebSocket 端口如 80, 443, 或自定义端口。检查企业内网的出口防火墙策略确认是否允许员工电脑访问该 IP 和端口。一个经典案例某客户将 WebSocket 服务部署在内网前端通过公网域名访问结果 DNS 解析到内网 IP导致员工在外网无法连接——这本质上是 DNS 解析策略错误而非网络不通。注意很多初学者会混淆ws://和wss://的端口。ws://默认走 80 端口wss://默认走 443 端口。但这只是“默认”你可以ws://example.com:9000也可以wss://example.com:8443。关键在于你写的 URL 端口号必须和服务端实际监听的端口号完全一致。2.3 第三关TLS/SSL 加密通道是否成功协商当你使用wss://时你面对的不再是单纯的 WebSocket 协议而是 WebSocket over TLS。这意味着在 HTTP Upgrade 握手开始之前客户端和服务器之间必须先完成一次完整的 TLS 握手Client Hello → Server Hello → Certificate → Key Exchange → Finished。任何一步失败连接就会在 TLS 层断开浏览器会报出NET::ERR_CERT_*或ERR_SSL_PROTOCOL_ERROR等错误。这与后端 WebSocket 逻辑完全无关是纯粹的加密基础设施问题。最常见的三大陷阱证书链不完整Nginx 或 Apache 配置 SSL 时只提供了你的域名证书yourdomain.crt却没有提供中间证书Intermediate CA Certificate。现代浏览器尤其是 Chrome会拒绝这种“不完整链”的证书因为它无法构建一条通往可信根证书的完整信任路径。解决方案是将你的域名证书和中间证书合并成一个.pem文件例如cat yourdomain.crt intermediate.crt fullchain.pem然后在 Nginx 中配置ssl_certificate fullchain.pem;。证书域名不匹配证书是为www.example.com申请的但用户访问的是example.com或api.example.com。单域名证书只对一个精确域名有效。解决方案是申请通配符证书*.example.com或 SANSubject Alternative Name证书将所有需要的域名都列进去。TLS 版本或加密套件不兼容老旧的客户端如某些嵌入式设备、旧版 Android WebView只支持 TLS 1.0/1.1而你的服务器为了安全禁用了它们只启用 TLS 1.2/1.3。或者服务器配置了过于激进的加密套件如仅TLS_AES_128_GCM_SHA256而客户端不支持。解决方案是在 Nginx 的ssl_protocols和ssl_ciphers指令中保留一个足够宽泛的兼容范围例如ssl_protocols TLSv1.2 TLSv1.3;和ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384;。实测心得判断问题是否出在 TLS 层最简单的方法是用openssl s_client -connect host:port -servername yourdomain.com命令。如果能看到Verify return code: 0 (ok)说明证书和 TLS 握手是成功的。如果卡在CONNECTED(00000003)后面或者返回verify error:num20:unable to get local issuer certificate那就明确了是证书链问题。2.4 第四关反向代理Nginx是否正确透传 Upgrade 请求这是生产环境中最高频、最隐蔽、最让人抓狂的失败原因。当你的 WebSocket 服务运行在内网前面架了一台 Nginx 做反向代理和 HTTPS 终结时Nginx 默认会把所有请求都当作普通的 HTTP 请求来处理。它会读取整个 HTTP 请求体然后转发给后端再读取后端的整个响应体最后返回给客户端。但对于 WebSocket 来说这整套流程是致命的——它需要的是一个“长连接隧道”而不是“请求-响应”模型。Nginx 必须被明确告知“这是一个 Upgrade 请求请不要读取它的 body也不要缓存它的 response把它当成一个需要保持的 TCP 连接来透传”一个标准的、能支持 WebSocket 的 Nginx 配置必须包含以下五要素proxy_http_version 1.1;—— 强制 Nginx 使用 HTTP/1.1 协议与后端通信因为 Upgrade 是 HTTP/1.1 的特性。proxy_set_header Upgrade $http_upgrade;—— 将客户端请求头中的Upgrade字段原样传递给后端。proxy_set_header Connection upgrade;—— 将Connection头设置为upgrade这是告诉后端“我要升级协议”的关键信号。proxy_set_header Host $host;—— 保持原始 Host 头避免后端路由错误。proxy_read_timeout 86400;—— 设置极长的读取超时这里设为 24 小时因为 WebSocket 连接可能数小时不发数据Nginx 默认 60 秒超时会主动断开连接。缺少其中任意一项都会导致不同的失败现象缺少proxy_http_version 1.1Nginx 用 HTTP/1.0 转发后端收不到Upgrade头返回 400。缺少proxy_set_header Upgrade $http_upgrade后端收不到Upgrade: websocket头认为这是个普通 GET 请求返回 200 或 404。缺少proxy_set_header Connection upgrade后端收不到Connection: Upgrade头同样无法识别升级意图。proxy_read_timeout过短连接建立后一段时间无数据Nginx 主动断开前端收到close事件状态码为1006。重要提醒Nginx 的location块必须精确匹配 WebSocket 的路径。例如你的前端连接 URL 是wss://example.com/ws/chat那么 Nginx 的location必须是location /ws/chat { ... }或更通用的location /ws/ { ... }。如果写成location / { ... }虽然也能工作但会把所有静态资源请求如/css/app.css也送到 WebSocket 后端造成 404 错误。最佳实践是为 WebSocket 流量单独划分一个路径前缀如/api/ws/并在 Nginx 中为其配置专属的location。3. 全链路实操排障从浏览器控制台到服务器日志的逐级定位3.1 浏览器端Chrome DevTools 的 WebSocket 专项诊断浏览器是你排障的第一线也是信息最丰富的源头。别再只盯着 Console 里的红色错误了要深入 Network 面板。第一步打开 DevToolsF12切换到 Network 标签页然后在左上角的过滤器里输入ws或websocket。刷新页面你会看到一个类型为WS的请求。点击它。Headers 标签页这是黄金信息区。检查Request Headers是否有Upgrade: websocket和Connection: Upgrade。检查Response Headers是否有Upgrade: websocket和Connection: Upgrade以及状态码是否为101。如果 Response Headers 里是200或302说明第一关协议握手失败问题在客户端或 Nginx 配置。Frames 标签页一旦连接建立成功状态变为OPEN这里会显示所有收发的 WebSocket 帧Frame。每一帧都有Opcode操作码如text,binary,ping,pong、Length长度和Data数据内容。你可以在这里看到前端send()发送了什么后端onmessage接收到了什么。如果这里一片空白但连接状态是OPEN说明后端根本没发数据过来问题在应用层逻辑。Preview / Response 标签页对于101响应这里通常为空因为101响应体是空的。但如果看到 HTML 内容那一定是后端返回了错误页面证明 Nginx 的proxy_pass指向了一个错误的 upstream。第二步在 Console 标签页输入WebSocket按回车你会看到浏览器内置的 WebSocket 构造函数。这本身就能证明浏览器支持 WebSocket。然后创建一个测试连接const ws new WebSocket(wss://echo.websocket.org);。如果控制台立刻报错那就是网络或 TLS 层的问题。如果几秒后ws.readyState变成1OPEN说明基础环境是 OK 的你的业务 WebSocket 问题就出在自己的域名、路径或后端服务上。实操技巧在Frames标签页右键点击任意一帧选择 “Save frame as…”可以把原始的 WebSocket 帧数据保存下来用文本编辑器或 Wireshark 进一步分析。这对于排查二进制协议如 protobuf over WebSocket的解析错误非常有用。3.2 Nginx 端日志是真相的唯一来源Nginx 的error.log和access.log是排障的圣杯。默认情况下Nginx 的error.log级别是error这意味着很多关键的调试信息如upstream prematurely closed connection不会被记录。你必须临时将日志级别调高。在 Nginx 配置文件的http块或server块中添加error_log /var/log/nginx/websocket_error.log debug;然后nginx -s reload重载配置。此时websocket_error.log里会记录下每一次请求的详细处理过程包括*1 client sent invalid upgrade request客户端请求头不合法。*1 upstream prematurely closed connection while reading response header from upstream后端服务在发送101响应前就关闭了连接通常是后端崩溃或超时。*1 no resolver defined to resolve ...DNS 解析失败proxy_pass的 upstream 域名无法解析。*1 connect() failed (111: Connection refused) while connecting to upstreamNginx 无法连接到后端服务证明第二关TCP 可达性失败。同时检查access.log。一个成功的 WebSocket 升级请求在 access log 里应该显示为101状态码。如果看到大量400、404、502就对应了不同的失败类型400协议错误请求头缺失或错误。404proxy_pass的路径配置错误Nginx 找不到对应的 upstream。502 Bad GatewayNginx 能连上后端但后端没有返回有效的101响应或者后端进程已死。注意事项debug日志级别会产生海量日志务必在问题定位后立即将其改回error或warn否则磁盘空间会被迅速耗尽。我习惯在error.log里加上if$loggable变量只对特定的location或特定的Host开启 debug 日志这样既能精准捕获又不污染全局日志。3.3 应用服务器端Spring Boot / Node.js 的日志埋点后端是最终的“守门员”它决定是否接受这次升级请求。以 Spring Boot 为例一个标准的 WebSocket 配置如下Configuration EnableWebSocket public class WebSocketConfig implements WebSocketConfigurer { Override public void registerWebSocketHandlers(WebSocketHandlerRegistry registry) { registry.addHandler(myWebSocketHandler(), /ws/**) .setAllowedOrigins(*); // 生产环境请勿用 * } Bean public WebSocketHandler myWebSocketHandler() { return new MyWebSocketHandler(); } }在这个MyWebSocketHandler类里OnOpen、OnMessage、OnError、OnClose四个注解方法是你的“探针”。在OnOpen方法里第一行就加log.info(WebSocket opened for session: {}, session.getId());。如果这条日志从未出现说明101响应根本没到达后端问题一定在 Nginx 或网络层。在OnMessage方法里加log.debug(Received message: {}, message);。如果OnOpen有日志但OnMessage没有说明前端send()了但后端没收到可能是消息格式错误如 JSON 解析失败抛异常导致连接被静默关闭。在OnError方法里加log.error(WebSocket error, cause);。这里会捕获到所有未处理的异常比如NullPointerException、IOException它们是导致连接意外关闭的元凶。对于 Node.js 的ws库同理const wss new WebSocket.Server({ port: 8080 }); wss.on(connection, (ws, req) { console.log(Client connected:, req.socket.remoteAddress); ws.on(message, (data) { console.log(Received:, data.toString()); }); ws.on(error, (err) { console.error(WebSocket error:, err); }); });实操心得在OnOpen里除了打日志还可以主动session.sendMessage(new TextMessage(Welcome!));。如果前端onmessage收到了这条欢迎消息就证明整个链路浏览器 → Nginx → Spring Boot → WebSocket Handler是畅通的。这是一种快速的“端到端”健康检查。3.4 网络层Wireshark 抓包——终极真相审判者当所有日志都指向“未知错误”时Wireshark 就是你的最后一张底牌。它能让你看到网络世界里最原始的字节流。操作步骤在 WebSocket 服务器上用tcpdump抓包sudo tcpdump -i any -w websocket.pcap port 8080将8080替换为你的真实端口。在客户端浏览器发起 WebSocket 连接。等待连接建立或失败后CtrlC停止抓包。将websocket.pcap文件下载到本地用 Wireshark 打开。在过滤栏输入tcp.port 8080聚焦到目标流量。找到第一个 TCPSYN包这是连接建立的起点。然后跟踪 TCP 流右键 → Follow → TCP Stream。你会看到一个清晰的对话客户端发送GET /ws/chat HTTP/1.1\r\nUpgrade: websocket\r\nConnection: Upgrade\r\n...服务器回复HTTP/1.1 101 Switching Protocols\r\nUpgrade: websocket\r\nConnection: Upgrade\r\n...之后所有的数据包都不再是 HTTP 文本而是 WebSocket 的二进制帧Opcode: 1 (TEXT)。如果在这个过程中你看到客户端发了SYN但服务器没回SYN-ACK证明第二关TCP 可达性失败是防火墙或服务未监听。客户端发了完整的 HTTP GET但服务器回了HTTP/1.1 400 Bad Request证明第一关协议握手失败是请求头错误。客户端发了 GET服务器回了HTTP/1.1 200 OK并附带 HTML证明 Nginx 的proxy_pass配置错误流量被导向了错误的 upstream。客户端发了 GET服务器回了HTTP/1.1 101但之后立刻是FIN包证明后端应用在101响应后立即关闭了连接是应用层代码 bug。重要提示Wireshark 抓wss://的包看到的是 TLS 加密后的密文无法直接看到 HTTP 内容。所以对于wss://你应该在 Nginx 和后端服务之间的链路上抓包即 Nginx 作为客户端后端服务作为服务器这样才能看到明文的 HTTP Upgrade 流程。4. 高频问题速查表与独家避坑指南问题现象可能原因快速验证方法解决方案Error during WebSocket handshake: Unexpected response code: 400客户端请求头缺失Upgrade或ConnectionNginx 未配置proxy_http_version 1.1Chrome DevTools → Network → Headers → 查看 Request Headers检查前端代码是否使用了正确的 WebSocket 构造函数检查 Nginx 配置是否包含proxy_http_version 1.1;Error during WebSocket handshake: Unexpected response code: 404Nginx 的location路径与前端连接 URL 不匹配proxy_pass指向的 upstream 名称错误curl -I http://your-nginx-domain/ws/path看返回状态码确保location块的路径与前端new WebSocket(wss://domain/path)中的path完全一致检查upstream块的名称是否与proxy_pass中的一致Error during WebSocket handshake: Unexpected response code: 502 Bad GatewayNginx 能连上后端但后端服务未启动、崩溃或返回了非101响应curl -v http://localhost:8080/ws/path在 Nginx 服务器上执行检查后端服务进程是否存活检查后端日志是否有OnOpen日志检查后端是否监听在0.0.0.0:8080而非127.0.0.1:8080WebSocket connection to wss://... failed: Error in connection establishment: net::ERR_CERT_AUTHORITY_INVALID证书不是由受信任的 CA 签发证书链不完整openssl s_client -connect yourdomain.com:443 -servername yourdomain.com从证书提供商处获取完整的证书链包括中间证书并将其与域名证书合并为fullchain.pemWebSocket is closed before the connection is establishedproxy_read_timeout过短后端服务启动慢Nginx 在等待响应时超时查看 Nginxerror.log搜索upstream timed out将proxy_read_timeout设置为一个很大的值如86400确保后端服务能在 Nginx 超时前完成初始化Failed to execute send on WebSocket: Still in CONNECTING state前端在readyState变为OPEN(1) 前就调用了send()在send()前加if (ws.readyState WebSocket.OPEN) { ws.send(...) }在ws.onopen回调函数里发送第一条消息或使用一个Promise封装连接逻辑确保连接完成后再发送独家避坑指南一永远不要在生产环境使用setAllowedOrigins(*)。这会让任何网站都能连接你的 WebSocket 服务构成严重的安全风险。正确的做法是将你前端应用的域名如https://app.yourcompany.com精确地加入白名单。Spring Boot 2.6 版本还支持setAllowedOrigins(Arrays.asList(https://app.yourcompany.com))并且会自动处理Origin头的校验。独家避坑指南二Nginx 的upstream配置必须使用ip_hash或least_conn而不能只用round_robin。WebSocket 是有状态的长连接round_robin会导致同一个客户端的后续ping/pong帧被负载到不同的后端实例上而那个实例根本没有该客户端的会话上下文从而导致连接异常。ip_hash能保证同一 IP 的请求始终落到同一台后端least_conn则能根据当前连接数做更智能的分配。独家避坑指南三在 Docker 环境中proxy_pass的地址不能写localhost:8080。因为localhost在容器内指的是 Nginx 容器自身而不是宿主机或其他容器。必须使用 Docker 的内部网络别名如backend:8080前提是docker-compose.yml中定义了backend这个 service name或者使用宿主机的 Docker 网桥 IP如172.17.0.1:8080。5. 从“能用”到“稳定”生产环境 WebSocket 的加固清单解决了“连不上”只是万里长征第一步。一个面向百万用户的 WebSocket 服务真正的挑战在于“如何让它永不掉线”。5.1 心跳保活对抗中间设备的无情收割互联网上的 NAT 设备、防火墙、负载均衡器都有一个共同的“洁癖”它们会定期清理长时间没有数据交互的“空闲连接”。一个 WebSocket 连接如果连续几分钟没有text或binary帧就可能被这些设备悄无声息地切断而客户端和服务端都毫无察觉直到下一次send()时才发现连接已死。这就是所谓的“连接假死”。解决方案是实现心跳机制Heartbeat/Ping-Pong。服务端主动 PingSpring Boot 的TextWebSocketHandler有一个sendMessage()方法你可以启动一个定时任务每隔 30 秒向每个活跃连接发送一个PingMessage。客户端主动 Ping前端 JavaScript 可以用setInterval每隔 30 秒调用ws.send(JSON.stringify({ type: ping }))。利用 WebSocket 协议原生 Ping-Pong现代浏览器和ws库都支持原生的 Ping-Pong 帧。你只需要在服务端设置ws.pingTimeout 30000在客户端设置ws.timeout 30000协议层就会自动处理。这是最优雅、最省资源的方式。我的实践在 Spring Boot 中我选择在OnOpen时为每个session启动一个ScheduledExecutorService每 25 秒发送一次PingMessage。OnError和OnClose里记得shutdown()这个定时器避免内存泄漏。5.2 自动重连优雅地应对网络抖动网络不可能 100% 稳定。一次 DNS 解析失败、一次短暂的网络拥塞、一次服务端的滚动更新都可能导致连接断开。用户不应该看到一个“连接已断开”的弹窗然后手动刷新页面。前端必须实现健壮的自动重连逻辑class ReconnectWebSocket { constructor(url, options {}) { this.url url; this.options options; this.reconnectDelay 1000; // 初始重连延迟 1 秒 this.maxReconnectDelay 30000; // 最大延迟 30 秒 this.reconnectAttempts 0; this.ws null; this.connect(); } connect() { this.ws new WebSocket(this.url); this.ws.onopen () { console.log(Connected); this.reconnectAttempts 0; // 成功后重置计数 this.reconnectDelay 1000; }; this.ws.onclose () { console.log(Disconnected, attempting to reconnect...); setTimeout(() this.connect(), this.reconnectDelay); this.reconnectDelay Math.min(this.reconnectDelay * 2, this.maxReconnectDelay); }; this.ws.onerror (error) { console.error(WebSocket error:, error); }; } }这个逻辑的核心是指数退避Exponential Backoff第一次失败后等 1 秒第二次失败后等 2 秒第三次等 4 秒……直到达到最大延迟30 秒避免对服务端造成雪崩式的重连风暴。5.3 连接池与限流保护后端服务的最后防线当你的 WebSocket 服务成为流量入口恶意扫描、DDoS 攻击、客户端 Bug 导致的连接风暴都可能瞬间压垮你的后端。你必须在 Nginx 层就筑起第一道防线。连接数限制在http块中定义一个连接限制区域limit_conn_zone $binary_remote_addr zoneaddr:10m;然后在location块中应用limit_conn addr 100; # 每个 IP 最多 100 个连接请求频率限制防止恶意客户端频繁发起连接请求limit_req_zone $binary_remote_addr zonews_limit:10m rate10r/s; limit_req zonews_limit burst20 nodelay;这表示每个 IP 每秒最多 10 个新连接请求突发最多 20 个超过的请求直接返回503 Service Temporarily Unavailable。最后分享一个小技巧在你的 WebSocket 服务启动时打印出当前 JVM 的最大堆内存-Xmx和可用 CPU 核心数。然后根据经验公式最大并发连接数 ≈ (JVM Heap / 1MB) * 10来预估你的服务容量。例如一个2G堆内存的服务理论最大连接数约为 20,000。这能帮你提前规划好水平扩展的节点数量而不是等到线上报警才手忙脚乱。
