Nginx反向代理Go服务长连接频繁断开原因排查-Golang-PHP中文网

nginx代理go服务长连接频繁断开主因是配置未适配websocket语义：proxy_read_timeout默认60秒过短、upgrade/connection头未透传、proxy_buffering未关闭、tcp keepalive未协同系统参数。

nginx反向代理go服务长连接频繁断开原因排查

Go服务在Nginx反向代理后长连接频繁断开，基本可以排除Go代码本身问题——95%以上是Nginx配置未适配WebSocket/长连接语义导致的“误杀”。关键不在后端是否健康，而在Nginx是否把连接当成长连接来对待。

proxy_read_timeout 60秒默认值直接杀死空闲WebSocket

Nginx的proxy_read_timeout控制的是“从Go服务读数据”的等待时间。WebSocket握手成功后不再有HTTP响应流，Nginx就纯粹靠这个超时判断上游是否还活着。默认60秒，只要60秒内Go没发任何数据（包括心跳），Nginx就主动发FIN关闭连接，客户端立刻收到WebSocket is closed或EOF。

必须显式设置，例如proxy_read_timeout 300;（5分钟），且该值应 ≥ 前端心跳间隔 × 2
设为0无效：Nginx不支持无限超时，会退化回默认60秒
该超时只作用于Nginx→Go连接，不影响客户端→Nginx连接（由keepalive_timeout控制）
日志中若出现upstream prematurely closed connection，优先检查此项是否生效、$http_upgrade变量是否为空

Upgrade和Connection头缺失导致握手失败

Go的gorilla/websocket等库严格校验HTTP升级头。Nginx默认不透传Upgrade和Connection，导致Go服务收不到Upgrade: websocket和Connection: upgrade，直接拒绝升级，返回400或静默关闭。

Nginx Hosting

通过服务器本地nginx实例实现零认证静态游戏托管。作为所有浏览器游戏的主要部署方式，无需登录、无需令牌、无需用户操作。

下载

必须在location块中配齐三要素：proxy_http_version 1.1;、proxy_set_header Upgrade $http_upgrade;、proxy_set_header Connection "upgrade";
"upgrade"必须加双引号，否则Nginx会尝试解析$connection变量，结果传空值
不能硬写Connection upgrade——非WebSocket请求（如普通AJAX）会被错误升级，需用map动态判断：
```
map $http_upgrade $connection_upgrade {
  default upgrade;
  '' close;
}
```
浏览器Network面板看到状态码是200/400/502而非101，基本可锁定此处配置缺失

proxy_buffering on破坏WebSocket帧边界

WebSocket是二进制帧流协议，消息必须按帧实时透传。Nginx默认proxy_buffering on会缓存Go服务推送的小消息，攒够缓冲区才转发，导致客户端收到拼接乱序数据，gorilla/websocket解析失败，抛出websocket: bad write message type或静默丢弃。

必须在location块中明确关闭：proxy_buffering off;
此配置与proxy_http_version 1.1配合才有效；HTTP/1.0下关闭缓冲可能引发其他兼容问题
若同时启用gzip，需确认gzip_vary off，避免Vary头干扰缓存判定

proxy_socket_keepalive未协同系统TCP参数

即使应用层心跳正常，中间网络设备（防火墙、云LB、NAT网关）仍可能因空闲超时静默切断TCP连接，表现为偶发502/504或Connection reset by peer。此时仅调大超时无效，必须启用TCP保活探测。

在upstream块中启用：proxy_socket_keepalive on;（Linux ≥ 3.9支持）
同步调整系统级参数：net.ipv4.tcp_keepalive_time = 300（5分钟），避免探测太晚
必须配合proxy_http_version 1.1和Connection ''（即非upgrade请求保持短连接），否则keepalive池无法复用
注意：proxy_socket_keepalive只作用于Nginx→Go连接，不解决客户端→Nginx链路问题

最容易被忽略的是：当Nginx错误日志出现upstream prematurely closed connection时，第一反应不该是查Go服务是否崩溃或超时，而应立刻验证proxy_read_timeout是否真正生效、$http_upgrade变量是否为空、以及proxy_set_header Connection那行有没有被引号包裹——这三个点卡住，其他配置再全也白搭。