关于WebSocket的Nginx反向代理方式及配置无效避坑
与传统的http服务的nginx反向代理配置方式略有不同,但总体与http协议相似,有反向代理需求的可以参靠我的配置方式
server {
#本机的nginx监听8085端口
listen 8085;
server_name localhost;
#charset koi8-r;
#access_log logs/host.access.log main;
location / {
root html;
index index.html index.htm;
}
#传统http请求的代理方式,将/property 开头的http请求转发到自己本机的8086服务上
location /property {
proxy_pass http://127.0.0.1:8086/property;
}
#websocket服务 /myWs相关的请求转发到本机8080端口的服务上配置
location /myWs {
proxy_pass http://127.0.0.1:8080/myWs;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Port $server_port;
}
#error_page 404 /404.html;
}
经过测试能正常连接并发送消息,Nginx配置成功!
注意避坑:如已经正确配置发现点击连接直接显示断开,请检查您的服务是否存在多个Nginx转发的情况,这种情况在生产环境比较常见。生产环境经常是通过域名访问服务,访问域名经过DNS解析请求到生产服务器A上的nginx(a),nginx(a) 会配置根据不同的情况再请求分发至自己的内网服务器B,服务器B上有nginx(b)再将对应请求转发至websocket服务器。这样一来一个请求实际经过了两个nginx的转发。因为websocket协议配置相较于http协议有协议升级的概念。如果在上述案例中的nginx(a)没有配置正确的协议升级可能导致websocket请求无法最终成功转发,具体解决方式有两种:
-
直接在nginx(a)上配置转发直达websocket服务,需求其他配置改动(因为配置中已经包含协议升级部分)
-
在nginx(b)上配置,但是需在nginx(a)的统一配置转发的地方配置允许协议升级,配置方式请参考:
server { listen 80; location / { proxy_pass http://backend_server; # WebSocket-specific headers proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection 'upgrade'; proxy_set_header Host $host; proxy_cache_bypass $http_upgrade; } }
说明:
proxy_http_version 1.1;
:确保使用 HTTP/1.1 协议,因为 WebSocket 协议需要 HTTP/1.1。proxy_set_header Upgrade $http_upgrade;
:转发 Upgrade 头,以便将连接升级到 WebSocket。proxy_set_header Connection 'upgrade';
:设置 Connection 头为 ‘upgrade’,以支持 WebSocket 协议。proxy_set_header Host $host;
:传递原始的 Host 头。proxy_cache_bypass $http_upgrade;
:确保 WebSocket 连接不会被缓存。
有关websocket的基本入门知识请参考本人主页《WebSocket的简单入门使用》~