workerman端口不可直接暴露公网，必须由nginx反向代理：终止ssl、透传upgrade/connection头、设置proxy_http_version 1.1、proxy_read_timeout≥86400、x-real-ip透传，并分离静态资源与动态请求。
Workerman监听端口不能直接暴露给公网
直接把 Workerman 的 HTTP 或 WebSocket 端口（比如 8080、2346）放到公网上，等于放弃连接管理、SSL 终止、请求限流和真实 IP 透传能力。Nginx 不只是“转发一下”，它是第一道防线——所有 TLS 解密、HTTP/2 升级、Header 校验、超时控制都发生在这里。
常见错误现象：502 Bad Gateway 频发、WebSocket 连接建立后秒断、$_SERVER['REMOTE_ADDR'] 总是 127.0.0.1、HTTPS 页面里混入 HTTP 资源被浏览器拦截。
- 必须用
proxy_pass http://127.0.0.1:8080（或 WebSocket 对应端口），禁止写成http://localhost:8080——某些系统下localhost会走 IPv6 回环，导致连接失败 -
proxy_set_header X-Real-IP $remote_addr和X-Forwarded-For必须设置，否则 Workerman 拿不到真实客户端 IP - HTTP 场景下，
proxy_http_version 1.1是默认值，但显式写出更稳妥；WebSocket 场景下这个参数不可省
静态资源必须由 Nginx 直接服务，不经过 Workerman
让 Workerman 处理 .js、.css、.png 这类文件，等于用 PHP 进程去读磁盘、拼 Header、做 gzip ——性能差、内存涨、并发上不去。Nginx 原生支持 sendfile、零拷贝、内存缓存，处理静态资源比 PHP 快 5–10 倍。
典型配置漏项：location /static/ 块没加 expires、没设 add_header Cache-Control，导致浏览器反复请求；或路径匹配顺序错乱，把 /api/ 请求误判为静态资源。
- 静态资源目录建议统一放在
/var/www/static/，Nginx 配置中用root /var/www;+location /static/，避免alias引发的路径拼接陷阱 - 务必加
expires 1y;和add_header Cache-Control "public, immutable";（适用于带哈希名的构建产物） - 如果前端是单页应用（SPA），需在
location /下 fallback 到index.html，但注意别覆盖掉/api/或/ws/的代理规则
WebSocket 和 HTTP 需共用一个域名但走不同 location 分流
浏览器不允许跨域建立 WebSocket 连接，所以 wss://example.com/ws 和 https://example.com/api 必须同域。Nginx 要在同一 server 块内，用不同 location 匹配路径，并分别指向 Workerman 的不同监听端口（如 HTTP 接口走 8080，WebSocket 服务走 2346）。
容易踩的坑：Upgrade 和 Connection 头没透传、proxy_read_timeout 设太小（WebSocket 是长连接，不是短请求）、SSL 配置只写了 listen 443 ssl 却漏了 http2 支持。
- WebSocket location 必须包含：
proxy_http_version 1.1;、proxy_set_header Upgrade $http_upgrade;、proxy_set_header Connection "upgrade"; -
proxy_read_timeout至少设为86400（24 小时），否则空闲连接会被 Nginx 主动断开 - 若启用 HTTP/2，记得在
listen行加上http2，且证书必须是有效、非自签、链完整
负载均衡与健康检查不能只靠 upstream 写死 IP
Workerman 本身支持多进程，但单机容量总有上限。生产环境要横向扩展，就得用 upstream 定义多个后端节点。但只写 server 192.168.1.10:8080; 是脆弱的——某台机器宕机，Nginx 默认仍会尝试转发，直到超时才切走，用户感知就是卡顿或失败。
更现实的问题：Workerman 进程可能因业务逻辑异常退出，但系统进程还在，Nginx 无法感知；或者新上线节点还没热身完成，就立刻接入流量。
- 必须加
max_fails=3 fail_timeout=30s，让 Nginx 主动踢出连续失败的节点 - 配合
health_check interval=5s fails=2 passes=2（需启用ngx_http_upstream_hc_module）做主动探测，路径建议返回200 OK的轻量接口（如/health） - 不要依赖
ip_hash做 WebSocket 会话粘性——它只保证同一 IP 的请求打到同一后端，但移动端 IP 易变，且 WebSocket 连接数远大于 HTTP 请求频次；改用hash $connection_upgrade consistent;更合理
真正难的不是写对这几行配置，而是理解每个指令背后发生的网络行为：一次 WebSocket 握手涉及多少次 TCP 往返、Nginx 缓冲区如何影响消息分片、proxy_buffering off 为什么对实时日志推送必不可少。这些细节不验证，上线后只会变成凌晨三点的告警电话。
