php扩展加载成功但websocket路由无响应，根本原因是swoole服务未真正运行或监听地址/端口配置错误；需先验证swoole.so已加载、服务进程存在且监听0.0.0.0（非127.0.0.1），再检查nginx是否透传upgrade和connection头、https下证书域名是否匹配。
PHP扩展加载成功但WebSocket路由无响应
这通常不是Swoole没装好，而是服务端代码根本没跑起来，或者监听地址/端口被系统屏蔽。先确认swoole.so已加载：php -m | grep swoole有输出才算基础过关。再检查服务是否真在运行：ps aux | grep websocket或netstat -tuln | grep :9501（把9501换成你用的端口）。如果进程不存在、端口没监听，那后续所有“连接失败”都是假问题。
WebSocket服务器监听了127.0.0.1却从外网访问
本地开发时写"127.0.0.1"没问题，但一旦部署到云服务器或局域网设备，外部客户端必须通过服务器真实IP或域名连——"127.0.0.1"对客户端来说永远指向它自己。正确做法是绑定"0.0.0.0"：
$server = new Swoole\WebSocket\Server("0.0.0.0", 9501);
注意：某些云厂商安全组默认封锁非80/443端口，9501这类端口需手动放行；Mac上可能被防火墙拦截，可临时执行sudo pfctl -d验证。
Nginx反向代理漏配Upgrade头导致握手失败
前端报ERR_CONNECTION_REFUSED或net::ERR_INCOMPLETE_CHUNKED_ENCODING，大概率是Nginx没转发WebSocket协议升级请求。只写proxy_pass不够，必须显式透传Upgrade和Connection头：
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
-
proxy_http_version 1.1—— 强制使用HTTP/1.1（WebSocket升级依赖此版本） -
proxy_set_header Upgrade $http_upgrade—— 把客户端的Upgrade头原样传给后端 -
proxy_set_header Connection "upgrade"—— 告诉Nginx这是个需要升级的连接，别当普通HTTP处理
少任何一条，Nginx都会把WebSocket握手请求当普通HTTP丢给Swoole，而Swoole收不到Upgrade: websocket头，直接返回400或静默丢弃。
HTTPS下用wss却硬填IP地址触发证书校验失败
浏览器强制校验证书域名，wss://192.168.1.100:9501这种写法必然报ERR_CERT_COMMON_NAME_INVALID。解决方案只有两个：
- 开发阶段用自签名证书+域名映射：改
/etc/hosts把dev.example.com指向本机IP，服务端证书CN填dev.example.com，前端连wss://dev.example.com:9501 - 生产环境必须走Nginx反代HTTPS：Swoole本身不处理SSL（或仅作测试），由Nginx终结TLS，再以
ws://127.0.0.1:9501转发到后端
绕过证书校验（如Chrome加--unsafely-treat-insecure-origin-as-secure）只适用于调试，上线前必须按标准流程走域名+有效证书。
