Question

Socket.io error on server with Nginx + node.js + ssl

Posted February 10, 2021 2.1k views
NginxNode.js

I don’t understand what the problem is. I tried so many things! This is error what i get!

2021/02/06 01:07:00 [error] 728#728: *1 connect() failed (111: Connection refused) while connecting to upstream, client: 77.219.0.204, server: domens.lv, request: "GET /socket.io/?EIO=4&transport=polling&t=NTqu5wj HTTP/1.1", upstream: "http://127.0.0.1:3000/socket.io/?EIO=4&transport=polling&t=NTqu5wj", host: "domens.lv", referrer: "https://domens.lv/"

Here is my Nginx default

server {

    root /var/www/html;

    # Add index.php to the list if you are using PHP
    index index.html index.htm index.nginx-debian.html;

    server_name domen.lv.lv www.domen.lv.lv;

        location /socket.io/ {
            proxy_http_version 1.1;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection "Upgrade";
            proxy_set_header Host $host;
            proxy_pass http://localhost:3000/socket.io/;
        }

    location / {
        # First attempt to serve request as file, then
        # as directory, then fall back to displaying a 404.
        proxy_pass http://localhost:3000;
                proxy_http_version 1.1;
                proxy_set_header Upgrade $http_upgrade;
                proxy_set_header Connection 'upgrade';
                proxy_set_header Host $host;
                proxy_read_timeout 96000;
                proxy_cache_bypass $http_upgrade;
               }

                listen [::]:443 ssl ipv6only=on; # managed by Certbot
                listen 443 ssl; # managed by Certbot
                ssl_certificate /etc/letsencrypt/live/hola.lv/fullchain.pem; # managed by Certbot
                ssl_certificate_key /etc/letsencrypt/live/hola.lv/privkey.pem; # managed by Certbot
                include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
                ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
}

server {
    if ($host = www.domen.lv.lv) {
        return 301 https://$host$request_uri;
    } # managed by Certbot


    if ($host = domen.lvlv) {
        return 301 https://$host$request_uri;
    } # managed by Certbot


    listen 80 default_server;
    listen [::]:80 default_server;

    server_name domen.lv www.hola.lv;
    return 404; # managed by Certbot
}

script.js

// connect to main namespace const socket = io('/');

const conversation = document.querySelector('.conversation');

let alreadyTyping = false;

// change the number of online

nginx.conf

user www-data;
worker_processes auto;
pid /run/nginx.pid;
include /etc/nginx/modules-enabled/*.conf;

events {
    worker_connections 768;
    # multi_accept on;
}


http {


    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;
    keepalive_timeout 65;
    types_hash_max_size 2048;

    include /etc/nginx/mime.types;
    default_type application/octet-stream;

    ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3; # Dropping SSLv3, ref: POODLE
    ssl_prefer_server_ciphers on;

    access_log /var/log/nginx/access.log;
    error_log /var/log/nginx/error.log;

    gzip on;


    include /etc/nginx/conf.d/*.conf;
    include /etc/nginx/sites-enabled/*;
}

index.html

  <script src='/socket.io/socket.io.js'></script>
    <script src='./script.js'></script>

These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.

×
Submit an Answer
1 answer

Hi @ivoisakovsSquid,

Everything with our Nginx configuration does look okay at a first glance. I don’t see anything misconfigured.

In the past when I’ve dealt with error messages such as :

(111: Connection refused) while connecting to upstream

It was always related to the application rather than Nginx itself. This has been the case for my personal projects and going over questions in the community. What I would recommend is to take a deep, better look into the application and see what exactly is misconfigured there.

Regards,
KFSys