服务器 > 网络 > websocket

Nginx代理WebSocket失败的完整排查过程

3人参与 2025-11-14 websocket

问题现象

初步怀疑:nginx 配置错误?

首先检查 nginx 配置:

map $http_upgrade $connection_upgrade {
    default upgrade;
    '' close;
}

upstream webservers {
    server 192.168.1.10:8080;
}

server {
    listen 80;
    server_name localhost;

    location /ws/ {
        proxy_pass http://webservers/ws/;
        proxy_http_version 1.1;
        proxy_set_header upgrade $http_upgrade;
        proxy_set_header connection "$connection_upgrade";  # ⚠️ 这里有坑!
        proxy_read_timeout 3600s;
    }
}

常见错误包括:

但即使修正这些,日志依然为空,说明:请求根本没到 nginx!

关键转折:前端页面来源被忽略

通过 docker ps 确认端口映射正常:

nginx     0.0.0.0:80->80/tcp

但发现一个致命细节:

前端页面是通过虚拟机 ip 打开的:http://192.168.228.128/
而 websocket 地址写的是:ws://localhost/ws/xxx

问题本质

→ 请求压根没发给 nginx,自然没有日志!

解决方案

方法 1:显式指定虚拟机 ip(临时可用)

// 前端 js
const ws = new websocket('ws://192.168.228.128/ws/xxx');

立即生效!

方法 2:使用相对路径(推荐 ✅)

// 自动继承当前页面的 host
const ws = new websocket('/ws/xxx');

优势:

附:正确的 nginx 配置模板

http {
    # 必须在 http 块顶层!
    map $http_upgrade $connection_upgrade {
        default upgrade;
        '' close;
    }

    upstream backend {
        server host.docker.internal:8080;  # docker desktop 推荐
        # 或 server 192.168.1.10:8080;
    }

    server {
        listen 80;
        server_name _;  # 匹配任意 host

        location / {
            root /usr/share/nginx/html;
            index index.html;
        }

        location /ws/ {
            access_log /var/log/nginx/ws_access.log;
            proxy_pass http://backend/ws/;
            proxy_http_version 1.1;
            proxy_buffering off;          # 必须关闭
            proxy_cache off;
            proxy_set_header upgrade $http_upgrade;
            proxy_set_header connection $connection_upgrade;  # 无引号!
            proxy_read_timeout 3600s;
        }
    }
}

经验总结

问题类型排查要点
nginx 无日志先确认请求是否真的发到了 nginx(检查前端地址、端口映射)
websocket 426检查 upgradeconnection 头是否正确传递
前端连接失败确保 websocket 地址与页面同源(避免硬编码 localhost
docker 环境host.docker.internal 代替 ip 更可靠

最后提醒

localhost 在前端代码中 ≠ 你的服务器!
它永远指向用户浏览器所在的机器

开发时务必注意页面来源与 websocket 目标的匹配关系,这是 websocket 代理失败的最高频原因

结语

从“426 upgrade required”到“连接成功”,看似是配置问题,实则是网络拓扑理解偏差。希望本文能帮你少走弯路!

到此这篇关于nginx代理websocket失败的完整排查过程的文章就介绍到这了,更多相关nginx代理websocket失败内容请搜索代码网以前的文章或继续浏览下面的相关文章希望大家以后多多支持代码网!

(0)

您想发表意见!!点此发布评论

推荐阅读

Olingo分析和实践之ODataImpl详细分析(重要方法详解)

07-21

Olingo分析和实践之EDM 辅助序列化器详解(最佳实践)

07-21

Olingo分析和实践之OData框架核心组件初始化(关键步骤)

07-21

logback异步输出日志过程解读

07-21

websocket实现方法日志实时查询过程

07-21

前端WebSocket连接失败问题的排查过程及解决

07-09

猜你喜欢

版权声明:本文内容由互联网用户贡献,该文观点仅代表作者本人。本站仅提供信息存储服务,不拥有所有权,不承担相关法律责任。 如发现本站有涉嫌抄袭侵权/违法违规的内容, 请发送邮件至 2386932994@qq.com 举报,一经查实将立刻删除。

发表评论