Google Chrome连接Nginx反向代理的WebSocket服务异常问题求助

阿华AIGC实验室

2026-4-30

问题分析与解决方案

首先，从你描述的各种现象来看——Chrome普通模式下wss连接失败（错误码1006），但其他浏览器、Chrome隐身/插件模式、直接连ws都正常，最关键的线索就是普通模式和隐身模式的差异，这一般指向Chrome的缓存、扩展程序或者本地存储（比如Cookie、LocalStorage）在搞鬼，当然也可能是Nginx配置里的小细节没到位。下面是具体的排查方向和解决办法：

一、先排查Chrome扩展程序的干扰

Chrome普通模式下的扩展程序是这类问题最常见的诱因，尤其是那些涉及网络拦截、广告屏蔽、VPN/代理类的插件。比如有些广告拦截插件会误判WebSocket连接为“可疑请求”直接阻断，或者VPN插件的全局代理设置和你的Nginx代理冲突。

操作步骤：
1. 打开Chrome的扩展管理页面（输入chrome://extensions/回车），暂时禁用所有扩展。
2. 重新测试wss连接，如果恢复正常，再逐个启用扩展，找出搞事情的那个插件——要么卸载它，要么在插件设置里把你的域名加到白名单。

二、清理Chrome的站点缓存与存储

Chrome普通模式下保存的站点Cookie、缓存数据可能和WebSocket的握手过程冲突，比如旧的Cookie导致Nginx或后端的鉴权逻辑异常，直接中断了连接。

操作步骤：
1. 打开你的域名页面，按F12调出开发者工具，切换到Application标签。
2. 在左侧菜单找到Storage，右键点击你的域名，选择Clear site data。
3. 关掉浏览器再重新打开，测试连接是否正常。

三、补全Nginx的`Connection`头配置细节

你的Nginx配置里用了$connection_upgrade变量，但这个变量需要提前在全局定义，否则在某些场景下（比如Chrome普通模式的特定请求头）可能无法正确赋值，导致握手失败。

修复方法：
在Nginx的http块（不是server块，是最外层的http配置）里添加以下内容，确保$connection_upgrade变量正确初始化：
```
map $http_upgrade $connection_upgrade {
    default upgrade;
    '' close;
}
```
这个map块的作用是：当请求头里有Upgrade字段时，把Connection头设为upgrade，否则设为close——这是WebSocket代理的标准配置补充，很多指南可能会漏掉这一步，但它是确保握手成功的关键。

四、排查Chrome的SameSite Cookie策略

如果你的后端或Nginx设置了SameSite=Strict的Cookie，而前端页面是从其他域名（比如本地localhost）访问的，Chrome普通模式下的Cookie策略会比隐身模式更严格，可能导致Cookie无法携带，进而影响WebSocket握手（如果你的后端依赖Cookie鉴权的话）。

验证与解决：
1. 在Chrome开发者工具的Network标签里，找到WebSocket握手的那个GET请求（状态码应该是101），检查请求头里是否携带了预期的Cookie。
2. 如果需要跨域携带Cookie，可以在Nginx中设置Cookie的SameSite属性为Lax或者None（注意None必须配合Secure属性）：
```
proxy_cookie_path / "/; SameSite=Lax; Secure";
```