WebSocket内网失效的根本原因是客户端地址与服务端监听、代理转发、DNS解析三者不一致；需确保服务监听0.0.0.0、Nginx透传Upgrade头、域名DNS与证书匹配、frp的host/path与客户端URL严格对齐。
WebSocket 在内网环境下无法使用，根本原因不是协议本身有问题，而是客户端发起连接时用的地址（ws://192.168.x.x:port 或 wss://your-domain.com）与服务端实际监听、代理层转发、DNS 解析三者之间不一致。只要其中一环错位，就会出现 Connection refused、net::ERR_CONNECTION_REFUSED 或握手阶段返回 400/502 等错误。
服务端监听地址必须匹配客户端访问路径
很多开发者在本地或内网启动 WebSocket 服务时，习惯写 ws://127.0.0.1:8080 测试成功，就以为部署完成。但一旦换设备访问（比如手机连同一 Wi-Fi），立刻失败——因为服务只绑定了 127.0.0.1，不接受外部请求。
- 正确做法是监听
0.0.0.0:8080（Linux/macOS）或:::8080（IPv6 兼容），确保服务响应来自局域网任意 IP 的连接 - 检查命令行输出或日志中是否出现类似
Listening on 0.0.0.0:8080，而非127.0.0.1:8080 - Node.js 示例：
server.listen(8080, '0.0.0.0')；Python Flask-SocketIO：socketio.run(app, host='0.0.0.0', port=8080) - 若用 Docker，需加
-p 8080:8080并确认容器内服务绑定0.0.0.0，否则端口映射无效
Nginx 反向代理 WSS 必须透传 Upgrade 头
当你用 Nginx 把内网 ws://192.168.1.100:8080 映射为外网 wss://api.example.com/ws，Nginx 默认会把 WebSocket 当作普通 HTTP 处理，导致握手失败，报错 Error during WebSocket handshake: Unexpected response code: 200 或 ERR_INVALID_HTTP_RESPONSE。
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- 关键配置缺一不可：
proxy_set_header Upgrade $http_upgrade和proxy_set_header Connection "upgrade" -
proxy_http_version 1.1必须显式声明，HTTP/1.0 不支持 Upgrade 机制 -
proxy_read_timeout建议设为300或更高，避免空闲连接被 Nginx 主动断开 - SSL 终止场景下，务必加
proxy_set_header X-Forwarded-Proto https，否则后端可能误判协议类型
域名解析与证书必须严格对应访问地址
用域名访问 wss://chat.example.com/ws 却连不上，大概率不是代码问题，而是 DNS 或 TLS 层卡住：
- DNS 必须解析到运行 Nginx 或 frp 的公网服务器 IP，而不是内网服务 IP；
nslookup chat.example.com要返回公网 IP - SSL 证书必须覆盖你实际访问的完整域名，例如证书是
*.example.com，就不能用chat.example.com.cn访问 - 如果用 Let’s Encrypt，确保
certbot申请时用了--standalone或--webroot，且验证路径能被公网访问到 - 浏览器控制台若报
NET::ERR_CERT_COMMON_NAME_INVALID，说明证书 Subject Alternative Name（SAN）不包含当前域名
frp 配置中 protocol.websocket.host 和 path 容易被忽略
启用 frp 的 WebSocket 模式后，protocol = websocket 只是开关，真正影响握手成功率的是两个字段： protocol.websocket.host 和 protocol.websocket.path。
-
protocol.websocket.host会作为 HTTP Upgrade 请求中的Host头发送，也参与 TLS SNI；它必须和你最终访问的域名完全一致（如chat.example.com），不能填 IP 或localhost -
protocol.websocket.path是 Upgrade 请求的 URL 路径，例如设为/live/tunnel，那么客户端必须用ws://chat.example.com/live/tunnel连接，否则 frps 会拒绝路由 - 常见错误：服务端配置了
path = /ws，但客户端仍连/或/socket，导致 404 或握手失败 - 路径建议避开
/ws、/websocket等明显关键词，用伪静态路径如/static/v2/conn更利于绕过某些中间设备识别
最常被跳过的细节是：客户端连接 URL、Nginx location 路径、frp 的 path、后端服务实际挂载路径，这四者必须对齐。差一个字符，握手就卡在 101 切换之前。
