Nginx在phpEnv中默认不支持WebSocket，需显式配置：proxy_http_version 1.1、proxy_set_header Upgrade $http_upgrade、proxy_set_header Connection "upgrade"、proxy_buffering off、proxy_read_timeout 86400、proxy_send_timeout 86400，并限定于/ws等专用location块。
Nginx 在 phpEnv 环境下默认不支持 WebSocket 长连接，直接用 phpEnv 自带的 Nginx 配置访问 ws:// 或 wss:// 会立刻断开，根本连不上——这不是后端 PHP 的问题，而是 Nginx 代理层没透传 Upgrade 流程、也没放开超时限制。
proxy_set_header Upgrade $http_upgrade 和 Connection "upgrade" 必须显式配置
WebSocket 握手本质是 HTTP 协议升级，Nginx 不会自动转发 Upgrade 和 Connection 头，必须手动告诉它“这是要升级的请求，别关掉连接”：
-
proxy_http_version 1.1是前提，HTTP/1.0 不支持 Upgrade 机制 -
proxy_set_header Upgrade $http_upgrade把客户端发来的Upgrade: websocket原样传给后端 -
proxy_set_header Connection "upgrade"覆盖 Nginx 默认的Connection: close，否则连接在握手后立即被切断 - 注意：
Connection值必须是字面量"upgrade"（带英文双引号），不能写成$http_connection或漏掉引号
proxy_read_timeout 必须设为远大于默认值（如 86400）
phpEnv 自带的 Nginx 配置中 proxy_read_timeout 默认是 60 秒，而 WebSocket 连接空闲时不会发心跳，Nginx 就会直接 kill 掉连接，表现为前端报 WebSocket is closed before the connection is established 或反复重连：
- 把
proxy_read_timeout 86400（24 小时）加到location块里，不是 server 或 http 级别 - 配套加上
proxy_send_timeout 86400，防止后端响应慢导致中断 - 如果 phpEnv 使用的是 Windows 版本，某些旧版 Nginx 编译时对大 timeout 支持不稳定，建议确认版本 ≥ 1.19.0
phpEnv 的 nginx.conf 里要禁用 proxy_buffering
WebSocket 消息是流式、低延迟的，Nginx 默认开启缓冲（proxy_buffering on）会导致消息堆积、延迟甚至乱序，尤其在 Laravel Echo 或自定义推送场景下明显：
立即学习“PHP免费学习笔记（深入）”；
- 在对应
location /ws或location /api/ws块中添加proxy_buffering off - 同时可加
proxy_buffer_size 16k和proxy_busy_buffers_size 32k控制单次读取上限，防大包阻塞 - 不要在全局
http块里关 buffering，只关 WebSocket 路径，避免影响普通 PHP-FPM 请求
验证时重点看响应头里的 Connection 和 Upgrade
配完重启 phpEnv 的 Nginx 后，用浏览器开发者工具 → Network → WS → Headers，检查响应头是否含以下两项：
-
Connection: upgrade（不是keep-alive或缺失） -
Upgrade: websocket（不是被过滤或变成小写upgrade） - 如果看到
502 Bad Gateway且后端服务明明在跑，大概率是proxy_pass地址写错，或后端监听的是127.0.0.1但 phpEnv 的 Nginx 运行在 Docker/WSL 里导致网络不通
真正容易被忽略的是：phpEnv 的 Nginx 配置常被多层覆盖（比如 vhost 文件、nginx.conf、extra.conf），改完一定要确认最终生效的是哪一份；另外 Windows 下杀毒软件有时会拦截长连接，临时关闭测试能快速定位是不是环境干扰。
