Detailed explanation of nginx reverse proxy webSocket configuration

Recently, I used the webSocket protocol when working on a project, and I used webSocket in the WeChat applet. When using the wss protocol in the WeChat applet, the port cannot be set and only the default port 443 can be used. Damn, my https is already listening on port 443, and webSocket is listening on 443 too, that's definitely not going to work. In order to find a solution, the boss gave this problem to me, and I happily (manually confused) accepted this task. I thought of two solutions. One solution is to deploy webSocket on another server, but this is too expensive. Another way is to use nginx reverse proxy.

Because the webSocket protocol is an upgrade based on the http protocol (see the figure below), you can use nginx to reverse proxy webSocket.

webSocket

As can be seen from this picture, the establishment of the webSocket connection is based on the http protocol.

GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13
Origin: http://example.com

Those who are familiar with HTTP may have discovered that this handshake request is similar to the HTTP protocol, but with a few more things.

Upgrade: websocket
Connection: Upgrade
This is the core of Websocket, telling servers such as Apache and Nginx: I am initiating the Websocket protocol.
Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13

First, Sec-WebSocket-Key is a Base64-encoded value, which is randomly generated by the browser, telling the server: Don’t fool me, I want to verify whether you are really a Websocket assistant.

Finally, Sec-WebSocket-Version tells the server the Websocket Draft (protocol version) used. In the beginning, the Websocket protocol was still in the Draft stage. There were all kinds of strange protocols, and there were many strange and different things in different periods, such as Firefox and Chrome using different versions. At the beginning, too many Websocket protocols were a big problem. . But it's okay now, it has been settled and everyone uses it.

The server will then return the following, indicating that the request has been received and the Websocket has been successfully established!

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: HSmrc0sMlYUkAGmm5OPpG2HaGWk=
Sec-WebSocket-Protocol: chat

This is the last area that HTTP is responsible for, telling the client that I have successfully switched the protocol~

Upgrade: websocket
Connection: Upgrade

It is still fixed, telling the client that the Websocket protocol is about to be upgraded. At this point, HTTP has completed all its work, and the next step is to proceed completely according to the Websocket protocol.

Once you understand the principles of the protocol, you can proceed to the next step.

First, nginx configures the https certificate

The server certificate was configured by the boss, so I used it directly. Check it yourself if you need it. 0.0

Add the following configuration to service node in the nginx configuration file

location /wss
    {
         proxy_pass http://127.0.0.1:8888;
         proxy_http_version 1.1;
         proxy_set_header Upgrade $http_upgrade;
         proxy_set_header Connection "Upgrade";
        proxy_set_header X-Real-IP $remote_addr;
     }

Explain the parameters

/wss is a random name that tells Nginx the URL to proxy. Now mine is set to wss . When I visit my server https://abc.com/wss , Nginx will map my request to port 8888 of this machine.

proxy_pass is the URL to be proxied to, my proxy is to port 8888 of the local machine.

proxy_http_version The http version used when proxying.

Here comes the point:

Key parameters for proxying webSocket

proxy_set_header Upgrade sets Upgrade of the http request header when proxying to the request header of the original http request, and the request header of the wss protocol is websocket
proxy_set_header Connection Because the proxy uses the wss protocol, Connection in the http request header is set to Upgrade

proxy_set_header X-Real-IP sets the original http request ip for the proxy, just fill in $remote_addr

As for the response parameters of the websocket protocol, you don't need to worry about them when using reverse proxy.

At this point, the configuration of Nginx reverse proxy webSocket is complete. Restart Nginx, try connecting with websocket, and fill in wss://abc.com/wss in the place of the original wss address. If the websocket is successfully connected, it means that the Nginx reverse proxy websocket has been successful.

Summarize

The current configuration is only for reverse proxying to the local machine. If you want to reverse proxy to another host, there may be cross-domain problems when proxying. You need to make cross-domain configuration in Nginx's reverse proxy.

think

You can see this section in the Nginx configuration file

location ~ .php$ {
   root html;
   fastcgi_pass 127.0.0.1:9000;
   fastcgi_index index.php;
   fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
   include fastcgi_params;
}

This is the configuration file of PHP in Nginx. Damn, why does it look so familiar? This configuration list is so similar to the reverse proxy of websocket just now. By searching online, I learned that when Nginx processes PHP type requests, it sends the requests to the fastcgi management process for processing. The fascgi management process selects the cgi child process to process the results and returns them to nginx. However, php-fpm is a PHP FastCGI manager. Nginx itself cannot process PHP. It is just a web server. When it receives a request, if it is a PHP request, it will be sent to the PHP interpreter for processing and the results will be returned to the client. Therefore, when Nginx processes PHP type requests, it is essentially implemented through the reverse proxy function.

We can expand our thinking and use Nginx reverse proxy to achieve more functions, such as proxying Tomcat

location /Tomcat
    {
         proxy_pass http://127.0.0.1:8080;
         proxy_http_version 1.1;
        proxy_set_header X-Real-IP $remote_addr;
     }

Of course, you can also use Nginx reverse proxy to achieve load balancing. I haven't tried this yet. I'll add more when I use it later.

The above is the full content of this article. I hope it will be helpful for everyone’s study. I also hope that everyone will support 123WORDPRESS.COM.