Nginx代理WebSocket必须显式配置proxy_http_version 1.1、proxy_set_header Upgrade $http_upgrade、proxy_set_header Connection "upgrade"及足够长的proxy_read_timeout等参数，否则握手失败或连接秒断。
Nginx 默认不透传 WebSocket 升级请求，直接代理会卡在 400 或 502，根本连不上。必须显式配置协议升级头和超时参数，否则握手失败或连接秒断。
proxy_http_version 1.1 和 upgrade 头缺一不可
WebSocket 握手依赖 HTTP/1.1 的 Upgrade 机制，Nginx 必须主动参与并转发这个意图：
-
proxy_http_version 1.1是前提：HTTP/1.0 不支持Upgrade，设成 1.0 会导致后端收不到升级请求 -
proxy_set_header Upgrade $http_upgrade：把客户端原始的Upgrade: websocket值原样传下去；若写成固定值"websocket"，非标准客户端（比如某些 IoT 设备）可能带其他 upgrade 值，会被截断 -
proxy_set_header Connection "upgrade"：注意是字符串"upgrade"，不是变量$connection；后者为空时 Nginx 会发Connection: close，直接断连
proxy_read_timeout 必须远大于业务空闲周期
Nginx 默认 proxy_read_timeout 是 60 秒，只要后端 60 秒没发数据，它就主动关掉连接——这对 WebSocket 来说就是“静默掉线”：
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 股票行情类应用每分钟推一次数据？至少设为
proxy_read_timeout 65s - 聊天系统允许用户长时间不发消息？建议设为
proxy_read_timeout 86400s（24 小时） - 别只改
proxy_read_timeout，proxy_send_timeout也要同步调大，否则大消息分片发送中途超时 - 如果后端本身有心跳保活（如 ping/pong），Nginx 超时可略高于心跳间隔，但不要低于它
location 配置里要关 buffer、开 tcp_nodelay
WebSocket 数据是实时流，不是等攒够一包才发，缓冲和 Nagle 算法会引入毫秒级延迟：
-
proxy_buffering off：禁用响应缓冲，避免 Nginx 缓存后端发来的帧，导致客户端收不到实时消息 -
tcp_nodelay on：绕过 TCP 的 Nagle 算法，小数据包立即发出，对高频低延迟场景（如协同编辑、实时游戏）很关键 - 不用配
proxy_cache或proxy_buffer_size，WebSocket 不走缓存路径，设了也无效
SSL 场景下不能漏掉 Host 头和 X-Forwarded-*
HTTPS + WebSocket（wss://）时，后端常靠 Host 或 X-Forwarded-Proto 判断协议类型，漏掉会导致重定向循环或拒绝连接：
- 务必保留
proxy_set_header Host $host，尤其当后端做虚拟主机路由时 - 加上
proxy_set_header X-Forwarded-Proto $scheme，让后端知道原始是https，否则可能生成 http 链接 - 如果前端校验来源，需补
proxy_set_header X-Real-IP $remote_addr和X-Forwarded-For - WSS 握手失败常见错误是
ERR_CONNECTION_REFUSED或控制台报net::ERR_SSL_PROTOCOL_ERROR，大概率是后端没收到正确的X-Forwarded-Proto
最易被忽略的是：所有这些配置必须放在具体 location 块里，而不是 server 或 http 全局块——Nginx 只在 location 级生效 upgrade 头和 timeout 参数。写错层级，等于没配。
