How to balance the load with NGINX and multiple servers

[El-Tommy]

I have a server running with PM2, which lets me use all the machine’s vCPUs (02) to get better Socket.IO performance. This server has 4GB of RAM.

Since I’m using PM2, I have an NginX server in front that receives HTTPS/WSS requests and forwards them to port 8080.

I use the configuration below to allow the nodes to communicate correctly, as per the instructions on the website.

const http = require("http");
const { Server } = require("socket.io");
const { createAdapter } = require("@socket.io/cluster-adapter");
const { setupWorker } = require("@socket.io/sticky");

const infoServer = {
    success: true,
}

const httpServer = http.createServer((req, res) => {
    res.writeHead(200, { "Content-Type": "application/json" });
    res.write(JSON.stringify(infoServer));
    res.end();
});

const io = new Server(httpServer, {
    cors: {
        origin: "*",
        methods: ["GET", "POST"]
    }
});

io.adapter(createAdapter());
setupWorker(io);

However, in my current scenario, it hasn’t been a good solution, especially for scalability.
If an issue occurs on the server—such as exhausting all RAM or hitting a file limit (tuning has already been done)—the entire service goes offline, so I’m thinking of using another machine, also with 2 vCPUs, to load-balance and provide high availability.

The scenario would be:

Nginx server:
-> Socket.IO Server 01 + 2 vCPUs running
-> Socket.IO Server 02 + 2 vCPUs running

But my question is what I need to change in my code for this to work.
From what I understand, in NginX I need to add the code below.

upstream nodes {
    # enable sticky session with either "hash" (uses the complete IP address)
    hash $remote_addr consistent;
    # or "ip_hash" (uses the first three octets of the client IPv4 address, or the entire IPv6 address)
    # ip_hash;
    # or "sticky" (needs commercial subscription)
    # sticky cookie srv_id expires=1h domain=.example.com path=/;

    server app01:8080;
    server app02:8080;
    server app03:8080;
  }

https://socket.io/docs/v4/using-multiple-nodes/#nginx-configuration

I really didn’t understand this part. If I’m going to use multiple servers, do I have to use only one CPU? Or can I keep using all the CPUs available on the machines?

Should I remove Socket.IO’s sticky mechanism?

Is that it? Could someone give me more details?

[zzz6519003]

The usual pattern is:

1. Keep NGINX in front of your Socket.IO servers.
2. Use sticky sessions so the same client stays on the same Node.js server.
3. Use a shared adapter (Redis) if you want broadcasts/rooms to work across multiple servers.

Socket.IO is not like a stateless HTTP API: once a socket is connected, it belongs to one server process. If NGINX randomly sends the same client to a different backend, the socket may disconnect or room/broadcast state will get split.

Recommended setup:

• NGINX load-balances the incoming socket connections
• each client is pinned to one server using session affinity
• each backend uses Redis adapter so all servers share the same room/event state

Example NGINX upstream with sticky sessions:

upstream socket_nodes {
    ip_hash;
    server 127.0.0.1:3001;
    server 127.0.0.1:3002;
    server 127.0.0.1:3003;
}

server {
    listen 80;
    server_name example.com;

    location / {
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_http_version 1.1;
        proxy_pass http://socket_nodes;
        proxy_read_timeout 3600s;
        proxy_send_timeout 3600s;
    }
}

Then on each Socket.IO server:

const { Server } = require("socket.io");
const { createAdapter } = require("@socket.io/redis-adapter");
const { createClient } = require("redis");

const pubClient = createClient({ url: "redis://localhost:6379" });
const subClient = pubClient.duplicate();

const io = new Server(3000, {
  adapter: createAdapter(pubClient, subClient)
});

Important notes:

• ip_hash is the simplest way to get stickiness
• if you are behind a CDN or proxies, IP-based affinity may not be reliable; a cookie-based approach is often better in production
• if you do not use a shared adapter, rooms and broadcasts will only work on the server that owns the socket
• if you do not need cross-server coordination, a single backend is simpler

In short: use sticky sessions for the socket connection, and Redis adapter for multi-server coordination. That is the standard Socket.IO scaling pattern.