WebSocket connection to ‘wss://aaa.bcb.ccc:81/ws/webSocket‘ failed

Nginx 代理 WebSocket 请求时，关键在于正确配置 HTTP 升级头（Upgrade和Connection），并确保 Nginx 能够处理 WebSocket 的长连接需求。如果配置不正确，前端就会出现错误。HTTP/1.0 和 HTTP/1.1 是超文本传输协议 (HTTP) 的两个不同版本。虽然它们在基本请求-响应模式上相似，但 HTTP/1.1 对 HTTP/1.0 进行了多个改

一个写前端的boy

1823人浏览 · 2024-09-10 22:49:42

一个写前端的boy · 2024-09-10 22:49:42 发布

前端的 WebSocket connection to 'wss://aaa.bcb.ccc:81/ws/webSocket' failed 错误通常与后端 Nginx 的配置有关。如果 Nginx 代理 WebSocket 请求出现问题，常见的原因包括 Nginx 没有正确处理 WebSocket 连接的升级，或者端口或协议配置错误。

解决 Nginx 配置问题的常见步骤

检查 Nginx 的 WebSocket 配置

WebSocket 使用 HTTP 协议的升级机制，将普通 HTTP 请求升级为 WebSocket 连接。为了让 Nginx 正确处理 WebSocket 请求，必须在 Nginx 配置中启用 upgrade 和 connection 头。

下面是一个典型的 Nginx WebSocket 代理配置示例：
```
server {
    listen 80;
    server_name aaa.bcb.ccc;

    location /ws/webSocket {
        proxy_pass http://backend_server; # WebSocket 后端服务
        
        # 设置 WebSocket 升级头
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        
        # 保持客户端真实的 IP 地址
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Host $host;

        # 增加超时设置，避免连接超时
        proxy_read_timeout 300s;
        proxy_send_timeout 300s;
    }
}
```
- proxy_http_version 1.1：WebSocket 需要 HTTP/1.1 协议进行通信，默认情况下 Nginx 使用 HTTP/1.0，需要将其设置为 1.1。
- proxy_set_header Upgrade $http_upgrade 和 proxy_set_header Connection "upgrade"：这两行配置是关键，它们告诉 Nginx 需要将 HTTP 请求升级为 WebSocket 连接。
- proxy_read_timeout 和 proxy_send_timeout：配置较长的超时可以防止 WebSocket 连接被过早关闭。

检查 Nginx 的端口配置

如果 WebSocket 连接使用了非标准端口（例如 81），需要确保 Nginx 正确监听并转发该端口的请求。

server {
    listen 81;
    server_name aaa.bcb.ccc;

    location /ws/webSocket {
        proxy_pass http://backend_server;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_read_timeout 300s;
        proxy_send_timeout 300s;
    }
}

检查 SSL 配置

如果你使用的是 wss://（安全 WebSocket），你需要确保 SSL 配置正确。一个典型的 SSL 配置如下：

server {
    listen 443 ssl;
    server_name aaa.bcb.ccc;

    ssl_certificate /path/to/cert.pem;
    ssl_certificate_key /path/to/key.pem;

    location /ws/webSocket {
        proxy_pass http://backend_server;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_read_timeout 300s;
        proxy_send_timeout 300s;
    }
}

确保 SSL 证书和密钥文件正确配置，并且路径有效。

Nginx 日志检查

查看 Nginx 的错误日志和访问日志，找出 WebSocket 请求失败的详细信息。这些日志可以帮助排查请求是否被正确代理，或者是否有其他问题导致连接失败。
- 错误日志路径（可能需要根据实际情况调整路径）：
```
/var/log/nginx/error.log
```
- 访问日志路径：
```
/var/log/nginx/access.log
```

其他注意事项

CORS 设置：
如果你从前端跨域访问 WebSocket 服务，确保后端（Nginx 或 WebSocket 服务器）允许跨域请求。

在 Nginx 中可以通过 proxy_set_header 来设置适当的 CORS 头：

location /ws/webSocket {
    proxy_pass http://backend_server;
    proxy_set_header Access-Control-Allow-Origin *;
    proxy_set_header Access-Control-Allow-Methods GET,POST,OPTIONS;
    proxy_set_header Access-Control-Allow-Headers X-Requested-With,Content-Type;
    # 其他 WebSocket 相关设置
}

防火墙：
检查服务器的防火墙设置，确保用于 WebSocket 的端口（如 81 或 443）没有被阻止。

总结

Nginx 代理 WebSocket 请求时，关键在于正确配置 HTTP 升级头（Upgrade 和 Connection），并确保 Nginx 能够处理 WebSocket 的长连接需求。如果配置不正确，前端就会出现 WebSocket connection failed 错误。

HTTP/1.0 和 HTTP/1.1 是超文本传输协议 (HTTP) 的两个不同版本。虽然它们在基本请求-响应模式上相似，但 HTTP/1.1 对 HTTP/1.0 进行了多个改进和优化，特别是在持久连接和缓存管理等方面。以下是两者的主要区别：

1. 持久连接（Persistent Connections）

HTTP/1.0：
- 默认情况下，HTTP/1.0 每次请求都会建立一个新的 TCP 连接。也就是说，每次请求/响应完成后，连接会关闭。
- 虽然支持 Connection: keep-alive 来保持连接，但并不默认启用，且在大多数情况下没有广泛使用。
HTTP/1.1：
- 默认启用持久连接，即 TCP 连接在多个请求和响应之间保持打开状态，不需要为每个请求都重新建立连接。
- 使用 Connection: close 来关闭连接，这减少了建立连接的开销（例如 TCP 握手），提高了网络效率。

2. 请求流水线化（Pipelining）

HTTP/1.0：
- 不支持请求流水线。客户端在发送一个请求时必须等待响应完成后才能发送下一个请求。
HTTP/1.1：
- 支持请求流水线（虽然现代浏览器不常启用）。客户端可以在接收到前一个请求的响应之前发送多个请求，从而提高请求的处理效率。

3. 缓存机制（Caching Mechanism）

HTTP/1.0：
- 缓存机制相对简单，主要通过 Expires 头字段来控制资源的缓存时间。
- 客户端通常会依赖日期（Date）头字段来确定资源是否过期。
HTTP/1.1：
- 引入了更强大的缓存控制机制，包括 Cache-Control 头字段（如 no-cache、no-store、must-revalidate 等），支持精细控制资源的缓存策略。
- 还引入了 ETag、If-Modified-Since、If-None-Match 等条件请求头来提高缓存的效率和一致性。

4. Host 头支持

HTTP/1.0：
- HTTP/1.0 请求中没有强制要求 Host 头字段，因此服务器无法通过同一个 IP 地址提供多个域名的服务（虚拟主机）。
HTTP/1.1：
- 强制要求客户端在请求中包含 Host 头字段，这允许服务器根据 Host 头字段来区分同一个 IP 地址下的不同域名，支持虚拟主机的概念。

5. 状态码的改进

HTTP/1.0：
- 状态码的种类较少，某些现代场景下的状态码无法支持。例如，客户端可能收到较为通用的状态码，无法更详细地了解响应的状态。
HTTP/1.1：
- 引入了更多的状态码，如 100 Continue、206 Partial Content 等，提供了更细粒度的响应控制和信息反馈。

6. 分块传输编码（Chunked Transfer Encoding）

HTTP/1.0：
- 不支持分块传输编码。服务器在响应时必须知道内容的长度并通过 Content-Length 头字段告知客户端。对于动态生成的内容（比如流式数据），这会带来不便。
HTTP/1.1：
- 支持分块传输编码（Transfer-Encoding: chunked）。服务器可以在不预先知道内容长度的情况下传输数据。响应可以按块发送，每块都有自己的长度，这对动态生成内容非常有用。

7. 错误处理

HTTP/1.0：
- 错误处理机制较为有限，客户端收到错误信息后处理空间较小。
HTTP/1.1：
- 改进了错误处理机制，引入了 100 Continue 状态码，允许客户端在发送较大的请求体之前确认服务器是否愿意接受请求，从而避免发送不必要的数据。

8. 带宽优化与网络延迟减少

HTTP/1.0：
- 每次请求都会重新建立 TCP 连接并发送完整的 HTTP 头，增加了网络延迟和带宽消耗。
HTTP/1.1：
- 默认持久连接、支持流水线和分块传输等优化大幅减少了网络延迟和带宽浪费。

9. 增强的代理支持

HTTP/1.0：
- 对代理服务器的支持有限，特别是在缓存和连接持久化等方面。
HTTP/1.1：
- 对代理有了更好的支持，包括缓存控制、连接复用以及处理不安全的连接方式等。

10. WebSocket 支持

HTTP/1.0：
- 不支持 WebSocket，因为 WebSocket 需要通过 HTTP 升级机制，而 HTTP/1.0 不具备这种机制。
HTTP/1.1：
- 支持 WebSocket 升级请求，通过 Connection: upgrade 和 Upgrade: websocket 头字段来建立 WebSocket 连接。