1. 项目概述为什么非得用 wss 连 Stomp这不只是加个 s 的事Stomp 以 wss 方式连接 WebSocket这个标题看似只是协议前缀的微小变更——从ws://换成wss://但背后牵动的是整个通信链路的安全基线、部署架构的合规逻辑以及前端工程中那些“明明本地跑得好好的一上生产就报错 Connection refused”的深夜排查现场。我带过的几个前后端协作项目里至少有三例核心实时功能消息通知、设备状态推送、协同编辑光标同步在测试环境一切正常上线后突然中断最终定位到的根因90% 都卡在wss这一层没打通。它不是可选项而是现代 Web 应用上线前必须跨过的硬性门槛。简单说wss是 WebSocket 的加密隧道版本就像 HTTP 和 HTTPS 的关系——ws是明文裸奔wss是全程 TLS 加密。浏览器强制策略早已明确任何通过 HTTPS 页面发起的 JavaScript 连接都禁止降级到非加密的ws协议。这意味着如果你的网站地址是https://example.com而前端代码里写的是new WebSocket(ws://api.example.com:8080/ws)现代 Chrome、Firefox、Safari 会直接拦截并抛出Mixed Content错误控制台里只有一行冰冷的Failed to construct WebSocket: An insecure WebSocket connection may not be initiated from a page loaded over HTTPS.。你连握手阶段都进不去更别提后续的 Stomp 帧交换了。这个限制不是浏览器厂商故意刁难而是安全演进的必然结果。想象一下一个用户正在银行页面HTTPS上操作如果此时页面还能随意建立明文 WebSocket 连接攻击者就能在中间网络层截获所有实时交易状态、账户余额变动甚至操作指令。wss强制要求服务端提供有效的 TLS 证书由可信 CA 签发或至少是自签名证书被浏览器手动信任确保从客户端到服务端的每一帧数据都经过加密、防篡改、防重放。Stomp 协议本身不处理加密它只是定义了CONNECT、SUBSCRIBE、SEND这些语义化的帧格式真正的信道安全必须由底层的wss来兜底。所以“Stomp 以 wss 方式连接 WebSocket”这个动作本质是一次安全契约的签署前端承诺只走加密通道后端必须提供合法凭证并正确配置 TLS 终止点。它解决的不是“能不能通”的问题而是“敢不敢通”、“合不合规矩”的问题。适合谁来读后端开发需要理解如何配置 Spring Boot 的 WebSocket TLS前端工程师必须掌握Stomp.over()的初始化细节和错误捕获逻辑运维同学得清楚 Nginx 或云负载均衡器上 TLS 证书的挂载位置与 SNI 配置就连测试同学也该知道用wscat -c wss://...而不是wscat -c ws://...来做基础连通性验证。这不是某个角色的专属技能而是全链路交付的共同语言。2. 核心设计思路拆解为什么不能只改 URLTLS 终止点在哪决定成败很多人拿到需求的第一反应是“哦把前端代码里的ws://改成wss://就完事了”——这是最典型的认知偏差。协议前缀的修改只是冰山露出水面的一角水下庞大的结构才是决定项目成败的关键。真正需要系统性设计的是TLS 终止点TLS Termination Point的位置选择。它决定了证书由谁管理、加密发生在哪一层、以及 Stomp 握手流程是否会被意外中断。目前主流有三种架构每一种都有其不可替代的适用场景和必须规避的坑。2.1 方案一反向代理层终止 TLS推荐给绝大多数生产环境这是目前最成熟、最可控的方案。典型拓扑是浏览器 ←(wss)→ Nginx/ALB/CLB ←(ws)→ Spring Boot 应用。Nginx 作为反向代理接收来自浏览器的wss请求完成 TLS 握手、证书校验、HTTP/2 升级协商然后将解密后的纯ws流量即未加密的 WebSocket Upgrade 请求转发给后端应用服务器。Spring Boot 应用本身完全不需要感知 TLS它只看到一个标准的ws://localhost:8080/ws连接。为什么这是首选安全责任分离清晰Nginx 专精于 TLS 处理拥有成熟的 OCSP Stapling、HSTS、TLS 1.3 优化等能力Spring Boot 专注业务逻辑避免引入复杂的 SSLContext 配置和证书热更新难题。运维友好证书更新只需在 Nginx 层操作无需重启 Java 应用零停机。兼容性强无论后端是 Spring Boot、Node.js 还是 Go只要支持标准 WebSocket都能无缝接入。性能优势TLS 加解密是 CPU 密集型操作由 Nginx 这类 C 语言编写的高性能代理承担比 JVM 层处理更高效。提示Nginx 配置中proxy_pass必须指向http://地址而非ws://。因为 Nginx 1.3.13 版本对 WebSocket 的代理支持是通过Upgrade和Connection头透传实现的它本身并不“理解” WebSocket 协议只是智能地转发升级请求。若错误地写成proxy_pass ws://backend;Nginx 会尝试解析 WebSocket 帧导致握手失败。2.2 方案二应用服务器层终止 TLS适合开发调试或极简部署即让 Spring Boot 应用自身监听443端口并直接处理wss请求。这需要在application.yml中配置server.ssl.*参数指定key-store和key-store-password。前端 URL 直接指向wss://yourdomain.com:443/ws。它的价值在于“所见即所得”的调试便利性。本地开发时你可以用keytool生成一个自签名证书快速验证整个wss Stomp流程是否通畅无需额外搭 Nginx。但生产环境强烈不建议证书管理成本高每次证书更新都要重启 Java 进程影响服务可用性。安全风险集中Java 应用同时承载业务逻辑和 TLS 处理攻击面扩大且 JVM 对 TLS 的调优如 session cache、cipher suite 选择远不如专业代理灵活。资源消耗大每个 Java 实例都要独立承担 TLS 计算横向扩展时 CPU 成为瓶颈。2.3 方案三云服务商托管 TLS适合云原生架构如果你的应用部署在 AWS、阿里云或腾讯云可以直接利用其负载均衡器ALB/SLB/CLB的 TLS 终止能力。你只需在控制台上传证书配置监听规则443 端口 → wss → 后端实例的 8080 端口其余全部由云平台自动完成。这本质上和方案一相同只是 Nginx 换成了云厂商的托管服务。关键区别在于健康检查与超时设置。云 LB 默认的健康检查是基于 HTTP 的而 WebSocket 是长连接需要将健康检查路径配置为/ws/health这样的端点并确保后端应用能返回200 OK。更重要的是LB 的空闲超时Idle Timeout必须显著大于你的 WebSocket 心跳间隔。例如若 Stomp 客户端设置heartbeat: { outgoing: 10000, incoming: 10000 }10秒心跳那么 ALB 的 Idle Timeout 至少要设为 30 秒以上否则 LB 会在心跳间隙主动断开连接导致客户端频繁重连。这三种方案没有绝对优劣只有场景适配。我的经验是开发阶段用方案二快速验证预发布和生产环境无条件选择方案一Nginx或方案三云 LB。把 TLS 这个“脏活累活”交给专业的基础设施让业务代码保持纯粹是十年来踩过无数坑后总结出的铁律。3. 核心细节解析与实操要点从证书到心跳一个都不能少当 TLS 终止点确定后真正的实操细节才刚刚开始。这些细节往往藏在文档的犄角旮旯却能在上线前几小时让你抓耳挠腮。我整理了从证书准备、Nginx 配置、Spring Boot 设置到前端 Stomp 初始化的全链路关键点每一个都附带“为什么这么写”的原理说明。3.1 TLS 证书自签名 vs. 公共 CA选错等于白忙证书是wss的基石。生产环境必须使用由公共 CA如 Lets Encrypt、DigiCert签发的证书。自签名证书在浏览器里会触发红色警告用户必须手动点击“高级”→“继续访问”这在任何面向用户的场景中都是不可接受的。Lets Encrypt 是免费、自动化、广受支持的选择。使用certbot获取证书的命令非常简洁sudo certbot certonly --standalone -d yourdomain.com -d www.yourdomain.com执行后证书文件会存放在/etc/letsencrypt/live/yourdomain.com/目录下其中fullchain.pem是证书链包含站点证书和中间 CA 证书privkey.pem是私钥。注意Nginx 的ssl_certificate必须指向fullchain.pem而不是单独的cert.pem。因为浏览器需要完整的证书链来向上追溯到根 CA缺少中间证书会导致部分 Android 设备或旧版 iOS 无法建立连接。注意如果你的域名是泛域名如*.example.comcertbot需要使用 DNS 验证方式--dns-cloudflare等插件因为--standalone模式需要临时占用 80 端口而泛域名通常无法通过 HTTP 文件验证。3.2 Nginx 配置6 行核心指令缺一不可Nginx 的 WebSocket 代理配置核心在于正确透传两个关键 HTTP 头Upgrade和Connection。以下是经过千次压测验证的最小化、最健壮的配置片段upstream websocket_backend { server 127.0.0.1:8080; # Spring Boot 应用地址 } server { listen 443 ssl http2; server_name yourdomain.com; # TLS 证书配置 ssl_certificate /etc/letsencrypt/live/yourdomain.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/yourdomain.com/privkey.pem; # WebSocket 专用配置 location /ws { # 与 Spring Boot 的 MessageMapping(/ws) 路径严格一致 proxy_pass http://websocket_backend; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_read_timeout 86400; # 24小时匹配 Stomp 心跳 } }逐行解释其不可替代性proxy_http_version 1.1WebSocket 升级必须基于 HTTP/1.1HTTP/2 不支持 Upgrade 机制。proxy_set_header Upgrade $http_upgrade将客户端请求头中的Upgrade: websocket原样传递给后端这是触发 WebSocket 协议升级的关键信号。proxy_set_header Connection upgrade同理Connection: upgrade头必须显式设置为字符串upgrade不能写成$http_connection因为$http_connection在某些情况下可能为空。proxy_read_timeout 86400这是最常被忽略的致命参数。Nginx 默认的proxy_read_timeout是 60 秒意味着如果后端 60 秒内没有发送任何数据Nginx 就会主动关闭连接。而 WebSocket 是长连接数据可能几分钟才发一次。将其设为 24 小时确保连接稳定存活由 Stomp 的心跳机制来管理活跃性。3.3 Spring Boot 配置EnableWebSocketMessageBroker 的隐藏开关Spring Boot 的 WebSocket 配置核心是EnableWebSocketMessageBroker注解。但仅仅加上这个注解还不够必须显式配置StompEndpointRegistry的setAllowedOriginsConfiguration EnableWebSocketMessageBroker public class WebSocketConfig implements WebSocketMessageBrokerConfigurer { Override public void registerStompEndpoints(StompEndpointRegistry registry) { // 关键允许所有 HTTPS 来源或精确指定 registry.addEndpoint(/ws) .setAllowedOrigins(https://yourdomain.com, https://www.yourdomain.com) .withSockJS(); // 如果需要兼容 IE可启用 SockJS 回退 } Override public void configureMessageBroker(MessageBrokerRegistry registry) { registry.enableSimpleBroker(/topic, /queue); registry.setApplicationDestinationPrefixes(/app); registry.setUserDestinationPrefix(/user); } }为什么setAllowedOrigins如此关键这是 Spring Security 的 CORS跨域资源共享控制。当浏览器通过wss://yourdomain.com/ws连接时它首先会发送一个 HTTP OPTIONS 预检请求Preflight Request询问服务器“我这个来源Origin能否建立 WebSocket 连接” 如果setAllowedOrigins没有包含当前页面的https://yourdomain.comSpring 会直接返回403 Forbidden连接在第一步就被拒绝。切记这里填写的是前端页面的协议域名不是 WebSocket 的 URL本地开发时可以暂时设为*但生产环境必须精确列出所有合法来源。3.4 前端 Stomp 初始化心跳与错误重连的生存指南前端使用stomp/stompjs库连接wss初始化代码远不止Stomp.over(new WebSocket(...))这一行。一个健壮的客户端必须处理网络抖动、服务重启、证书过期等现实世界问题import { Client, Frame } from stomp/stompjs; const client new Client({ brokerURL: wss://yourdomain.com/ws, // 必须是 wss connectHeaders: { login: , // 如果启用了 SimpleAuthentication passcode: }, // 心跳是生命线每10秒发一次ping等待10秒pong响应 heartbeat: { outgoing: 10000, incoming: 10000 }, // 错误重连指数退避最大间隔30秒 reconnectDelay: 5000, maxReconnectDelay: 30000, // 连接成功回调 onConnect: (frame: Frame) { console.log(Stomp connected:, frame); client.subscribe(/topic/messages, (message) { console.log(Received:, message.body); }); }, // 连接失败回调包括首次连接失败和重连失败 onStompError: (frame: Frame) { console.error(Broker reported error:, frame.headers[message]); }, // WebSocket 级别错误如网络断开、证书无效 onWebSocketError: (error) { console.error(WebSocket error:, error); }, // WebSocket 关闭回调正常关闭或异常断开 onDisconnect: () { console.log(Disconnected, will retry...); } }); // 启动连接 client.activate();实操心得心跳参数必须与 Nginx 的proxy_read_timeout匹配。如果 Nginx 设为 60 秒而前端心跳是 30 秒那没问题但如果前端心跳是 60 秒Nginx timeout 也是 60 秒Nginx 可能在收到 ping 后、发出 pong 前就关闭连接导致假性断连。我的习惯是Nginx timeout 前端心跳间隔 × 3。onWebSocketError是诊断证书问题的第一现场。如果浏览器控制台报net::ERR_CERT_INVALID这个回调会立即触发错误信息里会包含具体的证书错误码如NET::ERR_CERT_DATE_INVALID比单纯看 Network 面板更精准。永远不要在onConnect里写复杂的业务逻辑。应该只做订阅subscribe和基础状态设置。复杂逻辑放到onConnect之后的 Promise 链里避免阻塞 Stomp 的内部事件循环。4. 实操过程与核心环节实现从零搭建一个可验证的 wssStomp 环境现在我们把前面所有的理论和配置落地为一个可立即运行、可逐行验证的完整流程。这个过程模拟了一个真实项目的上线前最后验证环节我会详细记录每一步的操作命令、预期输出和常见陷阱。目标是让你在自己的机器上5 分钟内跑通一个wss://localhost:443/ws的 Stomp 连接。4.1 步骤一本地生成自签名证书仅用于验证非生产生产环境用 Lets Encrypt但本地验证必须快。我们用 OpenSSL 一条命令生成# 创建一个存放证书的目录 mkdir -p ./certs # 生成私钥和证书有效期365天 openssl req -x509 -nodes -days 365 -newkey rsa:2048 \ -keyout ./certs/localhost.key \ -out ./certs/localhost.crt \ -subj /CCN/STBeijing/LBeijing/OMyOrg/CNlocalhost这条命令会生成localhost.key私钥和localhost.crt证书。关键参数-subj指定了证书的主题其中CNlocalhost是核心因为我们要用https://localhost访问浏览器会检查证书的 Common Name 是否匹配。提示如果你用 Chrome 访问https://localhost时仍提示不安全是因为 Chrome 83 开始要求本地证书必须包含Subject Alternative Name (SAN)扩展。此时需创建一个配置文件localhost.conf[req] distinguished_name req_distinguished_name x509_extensions v3_req prompt no [req_distinguished_name] C CN ST Beijing L Beijing O MyOrg CN localhost [v3_req] keyUsage critical, digitalSignature, keyAgreement, keyEncipherment extendedKeyUsage serverAuth subjectAltName alt_names [alt_names] DNS.1 localhost IP.1 127.0.0.1然后用openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout ./certs/localhost.key -out ./certs/localhost.crt -config localhost.conf -extensions v3_req生成。4.2 步骤二配置 Nginx 作为 TLS 终止代理假设你已安装 Nginx编辑其主配置文件/etc/nginx/nginx.conf在http块内添加一个serverserver { listen 443 ssl http2; server_name localhost; ssl_certificate /path/to/your/certs/localhost.crt; # 替换为你的实际路径 ssl_certificate_key /path/to/your/certs/localhost.key; # WebSocket 代理 location /ws { proxy_pass http://127.0.0.1:8080; # Spring Boot 默认端口 proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade; proxy_set_header Host $host; proxy_read_timeout 86400; } # 为了能用 https://localhost 访问还需要一个 HTTP 重定向 location / { return 301 https://$host$request_uri; } }保存后检查配置语法并重载sudo nginx -t # 输出 syntax is ok 表示成功 sudo nginx -s reload4.3 步骤三启动 Spring Boot 应用精简版创建一个最简 Spring Boot 项目使用 Spring Initializr勾选Spring Web,Spring WebSocket。在application.properties中# 关闭内置 Tomcat 的 HTTPS因为我们用 Nginx 终止 server.port8080 # 允许所有来源本地验证用 cors.allowed-originshttps://localhost编写配置类WebSocketConfig.java内容与 3.3 节完全一致确保addEndpoint(/ws)与 Nginx 的location /ws完全匹配。启动应用./gradlew bootRun # 或 java -jar your-app.jar4.4 步骤四前端验证连接终极检验创建一个index.html文件内容如下!DOCTYPE html html head titlewss Stomp Test/title script srchttps://unpkg.com/stomp/stompjs6/bundles/stomp.umd.js/script /head body button onclickconnect()Connect/button div idstatusStatus: Not Connected/div script let client; function connect() { client Stomp.over(() new WebSocket(wss://localhost/ws)); client.onConnect () { document.getElementById(status).innerText Status: Connected; client.subscribe(/topic/test, (message) { console.log(Received:, message.body); }); // 发送一条测试消息 client.publish({ destination: /app/test, body: Hello from wss! }); }; client.onStompError (frame) { document.getElementById(status).innerText Status: STOMP Error - ${frame.headers.message}; }; client.onWebSocketError (error) { document.getElementById(status).innerText Status: WS Error - ${error.message}; }; client.activate(); } /script /body /html用 Chrome 打开https://localhost注意是https不是http。第一次访问会看到证书警告点击“高级”→“继续前往 localhost不安全”。然后点击页面上的 “Connect” 按钮。预期成功现象页面状态变为Status: Connected。浏览器控制台输出Received: Hello from wss!。Network面板中能看到一个ws类型的连接其Protocol列显示wss。Security面板中连接状态为Secure证书信息显示localhost。如果失败按此顺序排查curl -I https://localhost确认 Nginx 的 HTTPS 服务是否正常响应200 OK。curl -i -N -H Connection: Upgrade -H Upgrade: websocket https://localhost/ws模拟 WebSocket 升级请求应返回101 Switching Protocols。查看 Nginx 错误日志sudo tail -f /var/log/nginx/error.log是否有SSL_do_handshake() failed等错误。查看 Spring Boot 日志是否有Handshake failed due to invalid origin这说明setAllowedOrigins配置错误。这个流程的价值在于它剥离了所有业务逻辑只聚焦于wss连接本身。当你亲眼看到wss://localhost/ws在浏览器里亮起绿色的“Secure”标识并成功收发消息时你就掌握了整个链条的命脉。后续的所有业务功能都只是在这个坚实基础上的自然延伸。5. 常见问题与排查技巧实录那些让我凌晨三点还在敲命令的瞬间在过去的项目中“Stomp 以 wss 方式连接 WebSocket”这个问题我平均每周都会遇到 2-3 次。它们往往披着相似的外衣但内核各不相同。我把这些血泪教训整理成一张速查表并附上我当时的真实排查思路和命令希望能帮你避开那些我已经趟过的雷。问题现象根本原因排查命令/步骤我的实操心得浏览器控制台报net::ERR_CONNECTION_REFUSEDNginx 未监听 443 端口或防火墙阻止了 443sudo ss -tuln | grep :443sudo ufw statusUbuntu这是最基础的网络层问题。我曾在一个新装的 Ubuntu 服务器上因为忘了sudo ufw allow 443白白浪费了 40 分钟。记住ufw默认 deny all443 必须显式开放。控制台报net::ERR_CERT_INVALID但证书是 Lets Encrypt 签发的证书链不完整Nginx 的ssl_certificate指向了cert.pem而非fullchain.pemopenssl s_client -connect yourdomain.com:443 -servername yourdomain.com | openssl x509 -noout -text | grep Issuer检查输出的 Issuer 是否为Lets Encrypt Authority X3这个命令会打印证书的详细信息。如果 Issuer 显示为R3或X3说明链是完整的如果显示为ISRG Root X1则说明中间证书缺失。Lets Encrypt 的fullchain.pem就是cert.pemchain.pem的合并。连接成功但 60 秒后自动断开控制台报WebSocket is closed before the connection is establishedNginx 的proxy_read_timeout过短与 Stomp 心跳不匹配sudo nginx -T | grep proxy_read_timeout检查 Spring Boot 日志搜索Session is closed这是“时间错位”问题。Stomp 客户端以为连接还活着因为心跳正常但 Nginx 已经在后台悄悄关掉了 socket。解决方案就是把proxy_read_timeout设为心跳间隔的 3 倍以上并在 Nginx 配置中显式写出这个值不要依赖默认。Nginx 日志报upstream prematurely closed connection while reading response header from upstreamSpring Boot 应用未启动或proxy_pass地址错误如写成了ws://curl -v http://127.0.0.1:8080/ws在 Spring Boot 服务器上netstat -tuln | grep :8080这个错误表明 Nginx 能连上后端但后端没有返回正确的 HTTP 响应头。curl -v会显示详细的 HTTP 状态码和响应头。如果返回502 Bad Gateway基本可以锁定是后端问题。前端onConnect不触发但onWebSocketError也不触发连接静默失败浏览器的混合内容策略Mixed Content被触发但错误被静默吞掉在 Chrome 中打开chrome://flags/#unsafely-treat-insecure-origin-as-secure将localhost加入白名单或更简单用https://localhost访问而不是http://localhost这是最隐蔽的坑。当你的页面是http://localhost:3000而 JS 尝试连接wss://localhost/ws时Chrome 会认为这是不安全的混合内容并静默阻止。解决方案只有一个确保页面本身也是https。本地开发时用webpack-dev-server的https: true选项或直接用https://localhost。除了这张表我还想分享一个独家技巧用wscat做原子化测试。wscat是一个命令行 WebSocket 客户端它能绕过浏览器的所有策略直接测试底层连接。# 安装 npm install -g wscat # 测试 wss 连接会提示证书警告输入 y 继续 wscat -c wss://yourdomain.com/ws # 如果连接成功你会进入一个交互式终端输入任意字符并回车即可向服务器发送文本帧 # 这是验证 Nginx TLS WebSocket 升级是否工作的黄金标准wscat的价值在于它把问题域缩小到了极致如果wscat能连上说明 Nginx、TLS、WebSocket 协议栈全部正常问题一定出在前端 JS 代码或浏览器策略上如果wscat都连不上那问题一定在服务端基础设施层。这种“二分法”排查能让你在 5 分钟内定位问题大类效率提升数倍。最后关于证书更新这个高频痛点Lets Encrypt 证书只有 90 天有效期。我写了一个简单的 Bash 脚本配合cron每月自动续期并重载 Nginx#!/bin/bash # renew_cert.sh certbot renew --quiet --no-self-upgrade if [ $? -eq 0 ]; then systemctl reload nginx echo Certificates renewed and nginx reloaded at $(date) /var/log/cert-renewal.log else echo Cert renewal failed at $(date) /var/log/cert-renewal.log fi把它加入 crontab0 2 1 * * /path/to/renew_cert.sh每月 1 号凌晨 2 点执行。从此证书过期再也不是一个需要人工值守的紧急事件。6. 性能与安全加固当连接数破万时你必须知道的 3 个关键阈值当你的wss Stomp服务从几十个连接增长到数千、上万时最初的配置就会成为性能瓶颈。这不是危言耸听而是我在一个物联网平台项目中亲历的“成长的烦恼”。当时当在线设备数突破 8000Nginx 开始出现大量502 Bad GatewayCPU 使用率飙升至 95%而 Spring Boot 应用的 GC 时间却很平稳。问题根源不在业务代码而在三个被忽视的系统级阈值。6.1 Nginx 的 worker_connections单机连接数的天花板Nginx 的worker_connections指令定义了每个 worker 进程能同时处理的最大连接数。默认值通常是512或1024。对于 WebSocket 这种长连接一个连接会持续占用一个worker_connections配额。计算公式很简单单机最大并发连接数 worker_processes × worker_connections。在我们的物联网项目中worker_processes auto;自动检测 CPU 核数为 4worker_connections 1024理论最大连接数是4 × 1024 4096。当设备数达到 8000显然超过了这个上限Nginx 只能返回502。解决方案修改/etc/nginx/nginx.conf在events块中增加events { worker_connections 65535; use epoll; # Linux 下推荐 }同时必须调整系统的文件描述符限制Linux 的ulimit -n。因为每个连接都需要一个文件描述符fd。在/etc/security/limits.conf中添加nginx soft nofile 65535 nginx hard nofile 65535并确保 Nginx 启动脚本中设置了LimitNOFILE65535如果是 systemd。提示65535不是魔法数字它是 IPv4 端口号的理论上限。但在实践中根据服务器内存和 CPU可以设为32768或65535。我的经验是内存 ≥ 8GB 的服务器worker_connections 32768是一个安全、高效的起点。6.2 Spring Boot 的 Tomcat 线程池别让一个慢订阅拖垮全局Spring Boot 内嵌 Tomcat 的默认配置是为短连接 HTTP 设计的。它有一个maxThreads200的线程池。但对于 WebSocket每个连接的onMessage回调即处理 Stomp 帧是在 Tomcat 的工作线程中执行的。如果某个MessageMapping方法里执行了耗时的数据库查询或外部 API 调用这个线程就会被长时间占用。当大量连接同时发送消息而线程池被占满时新的消息就会在队列中等待。Tomcat 的默认acceptCount100意味着最多 100 个请求可以排队。一旦超过Tomcat 就会直接拒绝连接表现为Connection refused或503 Service Unavailable。解决方案在application.properties中为 WebSocket 专门配置一个异步线程池# 为 Stomp 消息处理配置独立线程池 spring.task.execution.pool.core-size20 spring.task.execution.pool.max-size200 spring.task.execution.pool.queue-capacity1000更重要的是在MessageMapping方法上显式使用Async
