Configuring Websocket Support in Ngnix

When SignalR is used to implement Websocket real-time data transmission, after the front-end and back-end code are implemented respectively, Websocket cannot be debugged. When frustrated, the colleague in charge of configuring the network proxy said that the network access uses the Ngnix proxy settings, which may be the reason why the Websocket connection cannot be reached. Checked the information, it is true. Nima is another pit.

Well, then try to configure support for Websockets in Ngnix.

However, first of all, let's introduce what Websocket is.

WebSocket

The WebSocket protocol provides an option for creating webapps that require real-time two-way communication between client and server. Part of HTML5, WebSocket makes development easier than the original method of developing such apps. Most modern browsers support WebSocket, such as Firefox, IE, Chrome, Safari, Opera, and more and more server frameworks now also support WebSocket.

In the actual production environment, multiple WebSocket servers are required to have high performance and high availability, then the WebSocket protocol requires a load balancing layer. NGINX supports WebSocket since 1.3, which can be used as a reverse proxy and load for WebSocket programs. balanced.

The WebSocket protocol is different from the HTTP protocol, but the WebSocket handshake is done over HTTP, using the HTTP Upgrade facility to upgrade the connection from HTTP to WebSocket. This allows WebSocket programs to be more easily integrated into existing infrastructure. For example, WebSocket programs can use standard HTTP ports 80 and 443, allowing the use of existing firewall policies.

A WebSocket program holds a long-running open connection between the client and the server, facilitating the development of real-time applications (this translation is problematic). The HTTP Upgrade mechanism used to upgrade connections from HTTP to WebSocket is done using the Upgrade and Connection headers. In reverse proxy server supporting WebSocket, there are some challenges to face. The first is that WebSocket is a hop-by-hop protocol, so when the proxy server intercepts an Upgrade request from the client, the proxy server needs to send its own Upgrade request to the backend server, including some appropriate headers. Also, because WebSockets are long-lived and, in contrast, HTTP connections are typically short-lived, the reverse proxy server must allow these connections to remain open, rather than closing them when they appear to be idle.

Then, let's talk about the configuration in Ngnix.

nginx

NGINX supports WebSockets by allowing a tunnel between the client and the backend server. In order for NGINX to send Upgrade requests from clients to backend servers, the Upgrade and Connection headers must be set explicitly. So,

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

    server {
        ...

        location /chat/ {
            proxy_pass http://backend;
　　　　　　　// Add this:
            proxy_http_version 1.1;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection $connection_upgrade;
        }
    }

 Reference from: https://nginx.org/en/docs/http/websocket.html