★ FEATURED ARTICLE 1. 项目概述为什么 WSS 配置成了 GatewayWorker 项目上线前的“最后一道关卡”GatewayWorker 是国内 PHP 社区广泛采用的长连接服务解决方案它用 Swoole 实现了 Gateway、BusinessWorker、Register 三进程模型把 WebSocket 连接管理、业务逻辑处理、服务注册发现做了清晰分层。很多团队在开发实时通知、在线客服、协同编辑、IoT 设备心跳上报这类功能时第一反应就是上 GatewayWorker——因为它文档齐、生态熟、配合 ThinkPHP 或 Laravel 做业务层非常顺手。但真正走到部署阶段90% 的人会卡在同一个地方本地ws://跑得飞起一上生产环境切到wss://就连不上控制台报错net::ERR_CONNECTION_CLOSED或WebSocket connection to wss://... failedGateway 日志里却安静得像没这回事。这个问题不是偶发而是有明确技术动因的WSS 不是简单给 WebSocket 加个 SSL它是建立在 TLS 协议之上的完整加密通道要求从客户端发起请求到反向代理如 Nginx再到 GatewayWorker 的 Worker 进程每一环都必须正确识别、透传、终止或协商 TLS。而 GatewayWorker 本身不内置 HTTPS 服务能力——它的 Worker 进程只监听纯 TCP 端口比如 2121所有 TLS 解密工作必须由前置组件完成。这就引出了最典型的配置失配Nginx 配置了 SSL但没正确转发 WebSocket 升级头或者 Nginx 转发了但 GatewayWorker 的gateway.php配置里ssl相关参数全为 false又或者证书路径写错、权限不足、Swoole 版本不支持 TLS 1.3……每一个看似微小的疏漏都会让整个 WSS 链路在握手阶段就静默失败。我最近在一个在线教育平台的直播互动模块中复现了全部典型问题。这个项目需要支撑 5000 并发学生端实时接收答题倒计时、教师端广播白板操作、后台监控连接健康度——对连接稳定性、首包延迟、断线重连成功率要求极高。我们前期在测试环境用ws://跑通了全部逻辑但正式灰度前切换 WSS 时花了整整三天才定位到根源Nginx 的proxy_set_header Upgrade $http_upgrade;这一行被注释掉了而开发同学误以为“SSL 配好了WebSocket 就自动好了”。这种认知偏差在中小团队中极其普遍。所以这篇纪实不讲原理推导也不堆砌 RFC 文档只聚焦真实生产环境里你马上会遇到的配置项、报错日志、验证命令和绕过陷阱的实操路径。无论你是刚接触 GatewayWorker 的 PHP 开发者还是负责部署的运维同学只要你的项目需要对外提供wss://接口这篇内容就能帮你省下至少 8 小时排查时间。2. 整体架构与配置思路三层解耦是 WSS 可靠性的底层前提要理解 GatewayWorker 的 WSS 配置为什么容易出错必须先厘清它的标准生产部署结构。这不是一个单体服务而是一个典型的“前端卸载 后端专注”的三层协作模型最外层反向代理Nginx / Apache / Caddy它是用户直接访问的入口承担 SSL 证书加载、HTTP/HTTPS 请求终止、WebSocket 协议升级协商、负载均衡、静态资源托管等职责。它不处理任何业务逻辑只做“流量翻译官”。中间层Gateway 进程它运行在独立端口如 8282负责维持与所有客户端的长连接做心跳检测、连接数统计、IP 黑白名单、消息广播等网关级功能。它通过register进程与 BusinessWorker 通信但自身不解析业务数据。最内层BusinessWorker 进程它监听另一个端口如 2121只接收来自 Gateway 的已认证、已解包的业务消息例如{type:submit_answer,data:{...}}执行数据库操作、调用第三方 API、触发事件总线等。它完全不知道 TLS 是什么只认 TCP 流。WSS 的核心难点就在于这三层之间存在两个关键“协议转换点”客户端 ↔ Nginx这是标准的 HTTPS WebSocket Upgrade 流程。客户端发送GET /websocket HTTP/1.1Upgrade: websocketSec-WebSocket-Key头Nginx 必须原样透传这些头并返回101 Switching Protocols同时将后续二进制帧流持续转发给后端。Nginx ↔ GatewayWorker这里必须是明文 TCP 连接。Nginx 解密完 TLS 后把原始的 HTTP Upgrade 请求不含 TLS 层以明文形式发给 Gateway 进程监听的端口。Gateway 进程收到的是干净的 WebSocket 握手请求它再按标准流程响应101并升级为 WebSocket 连接。提示很多人误以为 GatewayWorker 也要开 TLS 端口于是去改gateway.php里的ssl true并填证书路径。这是根本性错误。GatewayWorker 的 SSL 配置仅在一种场景下有效当你跳过 Nginx让客户端直连 Gateway 进程即wss://your-domain.com:8282。但生产环境绝不能这么做——没有反向代理你就失去了证书自动续期、DDoS 缓冲、HTTP/2 支持、日志审计等关键能力。所以ssl true在标准架构中应永远为false。那么正确的配置责任划分就非常清晰了Nginx 全权负责 TLS 终止、证书管理、Upgrade 头透传GatewayWorker 专注 WebSocket 协议处理只与 Nginx 建立明文连接BusinessWorker 完全无感照常收发 JSON 消息这种解耦带来的最大好处是可维护性换证书只需改 Nginx 配置调优 WebSocket 参数只需改 Gateway 配置升级业务逻辑只需重启 BusinessWorker——三者互不影响。而所有“踩坑”几乎都源于打破了这个边界比如在 Nginx 里忘了加Upgrade头导致 Gateway 收到的是普通 HTTP 请求而非 WebSocket 握手或者在 Gateway 配置里误启了 SSL结果它试图用明文端口去读取证书文件启动直接报错。3. 核心配置项逐项拆解Nginx 与 GatewayWorker 的 7 个关键开关WSS 配置的成败取决于 7 个具体配置项是否全部正确。少一个连接就建立不了错一个日志里就找不到线索。下面我按实际部署顺序把每个开关的作用、常见错误、验证方法、修复方案说透。3.1 Nginx Server 块SSL 证书与基础 HTTPS 启用这是整个 WSS 的起点。Nginx 必须能正常响应https://your-domain.com的普通 HTTPS 请求否则 WebSocket 根本没机会发起。server { listen 443 ssl http2; server_name your-domain.com; # 证书路径必须绝对准确且 Nginx 用户通常是 www-data 或 nginx有读取权限 ssl_certificate /etc/nginx/ssl/your-domain.com/fullchain.pem; ssl_certificate_key /etc/nginx/ssl/your-domain.com/privkey.pem; # 强烈建议启用 OCSP Stapling提升 TLS 握手速度 ssl_stapling on; ssl_stapling_verify on; ssl_trusted_certificate /etc/nginx/ssl/your-domain.com/chain.pem; # TLS 版本与加密套件兼顾安全与兼容性 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; ssl_prefer_server_ciphers off; # 其他常规配置... root /var/www/html; index index.php; }常见错误与排查证书路径错误ls -l /etc/nginx/ssl/your-domain.com/看文件是否存在sudo -u www-data cat /etc/nginx/ssl/your-domain.com/fullchain.pem | head -n 1测试 Nginx 用户能否读取。如果报Permission denied执行sudo chmod 644 /etc/nginx/ssl/your-domain.com/*.pem。证书链不完整用openssl s_client -connect your-domain.com:443 -servername your-domain.com 2/dev/null | openssl x509 -noout -text | grep CA Issuers检查是否包含中间证书。若缺失fullchain.pem应为cert.pemchain.pem拼接。Nginx 未重载改完配置必须sudo nginx -t sudo systemctl reload nginx只reload不restart避免连接中断。注意不要在ssl_certificate路径里用相对路径或~符号Nginx 启动时工作目录不固定必须用绝对路径。3.2 Nginx Location 块WebSocket 升级头的精准透传这是 WSS 失败率最高的环节。Nginx 默认不会透传Upgrade和Connection这两个关键头必须显式声明。location /websocket { # 关键必须开启代理缓冲否则大消息会截断 proxy_buffering off; # 关键透传 WebSocket 升级所需的两个头 proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade; # 关键告诉后端这是 WebSocket 请求不是普通 HTTP proxy_http_version 1.1; # 后端 Gateway 进程地址必须是明文 HTTP非 HTTPS proxy_pass http://127.0.0.1:8282; # 超时设置WebSocket 是长连接不能沿用默认的 60s proxy_read_timeout 86400; proxy_send_timeout 86400; # 其他可选优化 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_http_version 1.1WebSocket Upgrade 协议要求 HTTP/1.1HTTP/1.0 不支持。proxy_set_header Upgrade $http_upgrade$http_upgrade是 Nginx 内置变量值为客户端发来的Upgrade头内容通常是websocket。如果写死成websocket当客户端不带此头时会出错如果省略后端收不到升级指令。proxy_set_header Connection upgradeConnection: upgrade是 HTTP/1.1 协议规定的升级触发头必须原样传递。常见错误与排查忘记proxy_buffering offGatewayWorker 发送大消息如初始同步数据时Nginx 缓冲区满会导致连接被静默关闭。现象是客户端能连上但收不到第一条消息。tail -f /var/log/nginx/error.log会看到upstream sent too big header类似错误。proxy_pass写成https://proxy_pass https://127.0.0.1:8282是致命错误。Gateway 进程监听的是明文端口Nginx 会尝试用 HTTPS 去连它必然失败。必须是http://。proxy_read_timeout过短设为 60 秒是常见错误。WebSocket 连接空闲时Nginx 会在 60 秒后主动断开导致客户端频繁重连。设为8640024 小时是稳妥选择实际超时由 Gateway 的心跳机制控制。3.3 GatewayWorker 配置gateway.php中的 4 个核心参数GatewayWorker 的配置文件Applications/YourApp/Config/gateway.php是第二道防线。这里不需要开 SSL但必须确保与 Nginx 的通信方式完全匹配。return [ gateway [ class \GatewayWorker\Gateway, transport tcp, // 必须是 tcp不是 ssl ip 127.0.0.1, port 8282, count 4, lan_ip 127.0.0.1, start_port 2900, ping_interval 30, ping_not_response_limit 0, ping_data {type:ping}, // 关键必须为 false表示不启用内置 SSL ssl false, // 关键必须与 Nginx 的 proxy_pass 地址一致 registerAddress 127.0.0.1:1238, ], businessWorker [ class \GatewayWorker\BusinessWorker, count 4, // 关键监听端口必须与 gateway.php 中 registerAddress 的端口一致 registerAddress 127.0.0.1:1238, ], register [ class \GatewayWorker\Register, ip 127.0.0.1, port 1238, ] ];关键参数详解transport tcp明确指定传输层为 TCP。虽然默认就是 TCP但显式写出可避免歧义。ssl true时 transport 才是ssl。ssl false再次强调这是标准架构下的铁律。设为true会导致 Gateway 启动时报failed to open stream: No such file or directory找不到证书或SSL operation failed with code 1证书格式错误。registerAddressGateway 和 BusinessWorker 都必须指向同一个 Register 进程地址。这是三进程通信的“电话总机”地址不一致会导致业务消息无法送达。ping_interval心跳间隔。设为 30 秒是经验值太短增加无效流量太长如 120 秒可能导致 Nginxproxy_read_timeout先于心跳触发断连。验证方法启动 GatewayWorker 后执行netstat -tuln | grep :8282确认有tcp6 0 0 *:8282 *:* LISTEN。再执行curl -i -N -H Connection: upgrade -H Upgrade: websocket http://127.0.0.1:8282/websocket如果返回HTTP/1.1 101 Switching Protocols说明 Gateway 本身 WebSocket 握手正常问题一定出在 Nginx 层。3.4 Swoole 版本与 OpenSSL 支持被忽视的底层依赖GatewayWorker 依赖 Swoole 扩展而 Swoole 的 WebSocket 服务器能力与 OpenSSL 版本强相关。很多“配置全对却连不上”的案例根源在此。Swoole 4.5.0开始支持 TLS 1.3推荐使用 4.8.x 或 5.x 系列。OpenSSL 版本必须 ≥ 1.1.1。Ubuntu 18.04 自带 OpenSSL 1.1.1但 CentOS 7 默认是 1.0.2k不支持 TLS 1.3会导致 Nginx 与 Gateway 通信异常。验证命令# 查看 Swoole 版本与编译参数 php --ri swoole | grep -E (Version|OpenSSL) # 查看系统 OpenSSL 版本 openssl version # 检查 Swoole 是否链接了正确的 OpenSSL ldd $(php-config --extension-dir)/swoole.so | grep ssl输出示例正确swoole support enabled Version 5.0.3 OpenSSL OpenSSL 1.1.1w 11 Sep 2023 ...错误场景与修复如果php --ri swoole显示OpenSSL Disabled说明编译 Swoole 时没找到 OpenSSL 开发库。Ubuntu 上执行sudo apt install libssl-devCentOS 上执行sudo yum install openssl-devel然后重新编译安装 Swoole。如果OpenSSL版本是1.0.2k必须升级系统 OpenSSL 或更换发行版。强行用旧版 OpenSSL 会导致 TLS 握手失败Nginx 错误日志出现upstream prematurely closed connection while reading response header from upstream。3.5 客户端连接 URL协议、域名、端口的三位一体校验客户端代码里的一行new WebSocket(wss://...)是整个链条的发起点也是最容易写错的地方。// ✅ 正确协议 wss域名与 Nginx server_name 一致路径与 location 匹配 const ws new WebSocket(wss://your-domain.com/websocket); // ❌ 错误1协议写成 ws本地调试可用生产必须 wss const ws new WebSocket(ws://your-domain.com/websocket); // ❌ 错误2域名不匹配如用了 IP 或子域名但 Nginx 没配 server_name const ws new WebSocket(wss://192.168.1.100/websocket); // ❌ 错误3路径不匹配Nginx location 是 /ws客户端写了 /websocket const ws new WebSocket(wss://your-domain.com/ws);验证方法在浏览器开发者工具 Network 标签页过滤WS点击连接看 Initiator 列是否显示wss://your-domain.com/websocket。如果显示ws://检查前端构建配置如 Vue CLI 的devServer.proxy或 Webpack 的resolve.alias是否在生产环境注入了错误的协议。3.6 防火墙与安全组云服务器的隐形拦路虎本地curl能通但线上连不上90% 是防火墙挡的。云服务器阿里云、腾讯云、AWS的安全组默认只放行 80/443而 GatewayWorker 的 8282 端口是内部通信端口绝对不能开放给公网。但很多人误操作把 8282 加到了安全组白名单结果 Nginx 无法访问本地 8282因为流量被安全组规则拦截了。正确做法Nginx 与 GatewayWorker 在同一台机器无需开放 8282 端口127.0.0.1访问走本地回环不受安全组影响。Nginx 与 GatewayWorker 在不同机器如 Nginx 在 LBGateway 在应用服务器必须在应用服务器的安全组中仅允许 Nginx 服务器的内网 IP 访问 8282 端口禁止0.0.0.0/0。验证命令在 Nginx 服务器上执行# 测试能否 telnet 通 Gateway 服务器的 8282 端口 telnet gateway-server-ip 8282 # 如果不通检查 Gateway 服务器防火墙 sudo ufw status verbose # Ubuntu sudo firewall-cmd --list-all # CentOS 8 # 确保有类似 allow 8282/tcp from nginx-ip 的规则3.7 日志分级与关联快速定位故障环节的黄金法则WSS 故障排查本质是日志串联。必须养成习惯一次连接失败同时查看三处日志。日志位置查看命令关键线索Nginx error.logsudo tail -f /var/log/nginx/error.logupstream timed out超时、upstream refused端口拒绝、no live upstreams后端宕机GatewayWorker logstail -f Applications/YourApp/Logs/gateway-worker.logGateway started启动成功、onConnect连接建立、onClose连接关闭、SSL handshake failed如果误启了 SSL浏览器 ConsoleF12 → ConsoleWebSocket connection to wss://... failed客户端层面、Failed to construct WebSocket: An insecure WebSocket connection may not be initiated from a page loaded over HTTPS协议混用实战技巧在 GatewayWorker 的Events.php中加入详细日志public static function onConnect($client_id) { \GatewayWorker\Lib\Gateway::log(Client {$client_id} connected from {$_SERVER[REMOTE_ADDR]}); // 记录 User-Agent判断是否是爬虫或异常客户端 \GatewayWorker\Lib\Gateway::log(User-Agent: {$_SERVER[HTTP_USER_AGENT]}); }在 Nginx 配置中添加自定义日志格式记录 WebSocket 升级状态log_format websocket $remote_addr - $remote_user [$time_local] $request $status $body_bytes_sent $http_referer $http_user_agent $http_upgrade $http_connection; access_log /var/log/nginx/websocket.log websocket;4. 实操过程全记录从零部署一个可验证的 WSS 服务现在我们把前面所有知识点串起来走一遍完整的、可立即复现的部署流程。以下步骤基于 Ubuntu 22.04 PHP 8.1 Swoole 5.0.3 Nginx 1.18 环境所有命令均可复制粘贴执行。4.1 环境准备安装基础依赖与 Swoole# 更新系统 sudo apt update sudo apt upgrade -y # 安装 PHP 及常用扩展 sudo apt install -y php8.1-cli php8.1-mbstring php8.1-curl php8.1-xml php8.1-zip # 安装 OpenSSL 开发库编译 Swoole 必需 sudo apt install -y libssl-dev # 安装 Composer curl -sS https://getcomposer.org/installer | sudo php -- --install-dir/usr/local/bin --filenamecomposer # 安装 Swoole推荐 PECL自动处理依赖 sudo pecl install swoole # 安装过程中如果提示 Enable OpenSSL support? [no] :输入 yes 并回车 # 启用 Swoole 扩展 echo extensionswoole.so | sudo tee /etc/php/8.1/cli/conf.d/20-swoole.ini echo extensionswoole.so | sudo tee /etc/php/8.1/fpm/conf.d/20-swoole.ini # 重启 PHP-FPM sudo systemctl restart php8.1-fpm验证 Swoolephp --ri swoole | grep -E (Version|OpenSSL) # 输出应包含 Version 5.0.3 和 OpenSSL OpenSSL 1.1.1w4.2 下载并初始化 GatewayWorker 项目# 创建项目目录 mkdir -p /var/www/gateway-demo cd /var/www/gateway-demo # 使用 Composer 创建 GatewayWorker 项目官方推荐方式 composer create-project workerman/gatewayworker:4.1.0 . # 初始化应用结构 php start.php start -d # 此时应看到 Gateway start success但这是临时启动我们马上要配置 # 停止临时服务 php start.php stop4.3 配置 Nginx生成可直接使用的 server 块创建/etc/nginx/sites-available/gateway-demoupstream gateway_backend { server 127.0.0.1:8282; } server { listen 80; server_name gateway-demo.local; return 301 https://$server_name$request_uri; } server { listen 443 ssl http2; server_name gateway-demo.local; # 为本地测试生成自签名证书生产环境请用 Lets Encrypt ssl_certificate /etc/nginx/ssl/gateway-demo.local.crt; ssl_certificate_key /etc/nginx/ssl/gateway-demo.local.key; ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256; ssl_prefer_server_ciphers off; # WebSocket 专用 location location /websocket { proxy_buffering off; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade; proxy_pass http://gateway_backend; proxy_read_timeout 86400; proxy_send_timeout 86400; 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; } # 其他静态资源 root /var/www/gateway-demo/Web; index index.html; }生成自签名证书仅用于本地测试sudo mkdir -p /etc/nginx/ssl sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 \ -keyout /etc/nginx/ssl/gateway-demo.local.key \ -out /etc/nginx/ssl/gateway-demo.local.crt \ -subj /CCN/STBeijing/LBeijing/ODemo/CNgateway-demo.local启用站点sudo ln -sf /etc/nginx/sites-available/gateway-demo /etc/nginx/sites-enabled/ sudo nginx -t sudo systemctl reload nginx4.4 配置 GatewayWorker修改gateway.php与start.php编辑/var/www/gateway-demo/Applications/GatewayDemo/Config/gateway.phpreturn [ gateway [ class \GatewayWorker\Gateway, transport tcp, ip 127.0.0.1, port 8282, count 2, lan_ip 127.0.0.1, start_port 2900, ping_interval 30, ping_not_response_limit 0, ping_data {type:ping}, // 关键必须为 false ssl false, registerAddress 127.0.0.1:1238, ], businessWorker [ class \GatewayWorker\BusinessWorker, count 2, registerAddress 127.0.0.1:1238, ], register [ class \GatewayWorker\Register, ip 127.0.0.1, port 1238, ] ];编辑/var/www/gateway-demo/start.php确保use GatewayWorker\Autoloader;在顶部并在start()函数前添加// 设置时区避免日志时间错乱 date_default_timezone_set(Asia/Shanghai);4.5 启动服务并验证连接# 启动 GatewayWorker守护进程模式 cd /var/www/gateway-demo php start.php start -d # 查看进程是否运行 ps aux | grep GatewayWorker # 查看 Gateway 日志 tail -f /var/www/gateway-demo/Applications/GatewayDemo/Logs/gateway-worker.log # 应看到 Gateway started 和 Register started # 测试 Nginx 到 Gateway 的连通性在服务器本地执行 curl -i -N -H Connection: upgrade -H Upgrade: websocket http://127.0.0.1:8282/websocket # 应返回 HTTP/1.1 101 Switching Protocols # 测试 WSS 连接在另一台机器或浏览器中 # 访问 https://gateway-demo.local打开开发者工具 Console执行 # const ws new WebSocket(wss://gateway-demo.local/websocket); # ws.onopen () console.log(Connected!); # ws.onerror (e) console.error(Error:, e);如果浏览器报错ERR_CONNECTION_REFUSED检查sudo netstat -tuln | grep :8282确认 Gateway 进程在监听。检查sudo nginx -t确认 Nginx 配置语法正确。检查/var/log/nginx/error.log看是否有connect() failed (111: Connection refused)说明 Nginx 连不上 8282。如果浏览器报错ERR_SSL_PROTOCOL_ERROR检查curl -I https://gateway-demo.local确认 HTTPS 基础服务正常。检查证书路径是否正确ls -l /etc/nginx/ssl/看文件是否存在。4.6 前端验证页面一个最小可运行的 HTML在/var/www/gateway-demo/Web/index.html中写入!DOCTYPE html html head titleGatewayWorker WSS Test/title /head body h1GatewayWorker WSS 连接测试/h1 div idstatus等待连接.../div button onclickconnect()连接/button button onclicksend() disabled idsendBtn发送消息/button divtextarea idmsg rows2 cols50Hello from browser!/textarea/div script let ws; function connect() { const url wss://gateway-demo.local/websocket; ws new WebSocket(url); ws.onopen function() { document.getElementById(status).innerText ✅ 已连接; document.getElementById(sendBtn).disabled false; }; ws.onmessage function(event) { console.log(收到:, event.data); document.getElementById(status).innerText 收到: event.data; }; ws.onclose function() { document.getElementById(status).innerText ❌ 连接已关闭; document.getElementById(sendBtn).disabled true; }; ws.onerror function(error) { console.error(WebSocket 错误:, error); document.getElementById(status).innerText ❌ 连接错误: error; }; } function send() { const msg document.getElementById(msg).value; if (ws ws.readyState WebSocket.OPEN) { ws.send(msg); document.getElementById(status).innerText 已发送: msg; } } /script /body /html访问https://gateway-demo.local点击“连接”即可看到实时连接状态和消息收发。5. 常见问题与排查技巧实录那些让你抓狂的“幽灵错误”在多个项目的 WSS 部署中我整理出一份高频问题速查表。这些问题往往没有明确报错或者报错信息极具误导性必须结合上下文才能定位。5.1 问题速查表症状、原因、验证命令、修复方案症状可能原因验证命令修复方案浏览器控制台报net::ERR_CONNECTION_CLOSEDNginx error.log 为空Nginx 的proxy_pass指向了错误的端口如 2121 而非 8282或 Gateway 进程未启动sudo netstat -tuln | grep :8282curl -i http://127.0.0.1:8282/websocket确认gateway.php中port与 Nginxproxy_pass端口一致执行php start.php start -d启动 Gateway连接能建立但 30 秒后自动断开onClose日志频繁出现Nginxproxy_read_timeout过短或 Gatewayping_interval与 Nginx timeout 不匹配grep proxy_read_timeout /etc/nginx/sites-available/*grep ping_interval /var/www/gateway-demo/Applications/*/Config/gateway.php将 Nginxproxy_read_timeout设为86400Gatewayping_interval设为30确保 Nginx timeout 3 × ping_intervalNginx error.log 报upstream prematurely closed connectionGatewayWorker 进程崩溃退出或 Swoole 版本与 OpenSSL 不兼容sudo systemctl status php8.1-fpmphp --ri swoole | grep OpenSSL升级 Swoole 至 5.x确保 OpenSSL ≥ 1.1.1检查 Gateway 日志是否有 Segmentation fault
阅读完成 · 觉得有帮助？
