WebSocket-сервер на VPS с nginx

Чаты, нотификации, live-дашборды — всё держится на постоянных WebSocket-соединениях. Разберём, как поднять WS-сервер на VPS и корректно пробросить его через nginx с шифрованием wss.

Почему WebSocket любит выделенный сервер

WebSocket — это тысячи одновременных открытых соединений, каждое из которых занимает файловый дескриптор и немного памяти. Serverless и shared-хостинг обрывают такие соединения по таймауту. Нужен VPS с root, где вы сами управляете лимитами и nginx.

Постоянные соединения чувствительны к сети и стабильности. У MAATRIX локации в UK, США и РФ плюс NVMe-диски — соединения не рвутся, а под нагрузкой сервер не деградирует.

Есть и продуктовый нюанс: WebSocket плохо дружит с бессерверными платформами и большинством PaaS, которые рассчитаны на короткие HTTP-запросы. Балансировщики там закрывают idle-соединение через 30-60 секунд, и клиент постоянно переподключается. На VPS вы держите nginx и таймауты в своих руках, поэтому соединение живёт ровно столько, сколько нужно приложению. Оплата картой РФ, СБП или криптой делает такой зарубежный сервер доступным из России без плясок с иностранными платёжками.

Поднимаем WS-сервер

В качестве примера — Node.js с библиотекой ws. Ставим рантайм:

curl -fsSL https://deb.nodesource.com/setup_20.x | bash -
apt install -y nodejs
node -v

Минимальный сервер (файл /opt/wsapp/server.js):

const { WebSocketServer } = require('ws');
const wss = new WebSocketServer({ port: 8080, host: '127.0.0.1' });
wss.on('connection', (ws) => {
  ws.on('message', (m) => ws.send('echo: ' + m));
  ws.send('connected');
});
console.log('WS on 127.0.0.1:8080');

Устанавливаем зависимости и проверяем локально:

cd /opt/wsapp && npm init -y && npm install ws
node server.js

systemd-юнит

Чтобы сервер жил вечно и рестартился при падении:

cat > /etc/systemd/system/wsapp.service <<'EOF'
[Unit]
Description=WebSocket server
After=network.target

[Service]
WorkingDirectory=/opt/wsapp
ExecStart=/usr/bin/node server.js
Restart=always
User=www-data

[Install]
WantedBy=multi-user.target
EOF
systemctl daemon-reload
systemctl enable --now wsapp

nginx: Upgrade и wss

Ключ к WebSocket через nginx — правильные заголовки Upgrade и Connection. Без них соединение будет обрываться как обычный HTTP-запрос.

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

server {
    listen 443 ssl;
    server_name ws.example.com;

    ssl_certificate     /etc/letsencrypt/live/ws.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/ws.example.com/privkey.pem;

    location /ws {
        proxy_pass http://127.0.0.1:8080;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;
        proxy_set_header Host $host;
        proxy_read_timeout 3600s;
    }
}

Здесь ключевых момента два. Первый — proxy_http_version 1.1: без него nginx общается с бэкендом по HTTP/1.0, где нет апгрейда протокола. Второй — заголовки Upgrade и Connection, которые превращают обычный запрос в WebSocket-туннель. Большой proxy_read_timeout нужен, чтобы nginx не рвал тихие соединения между сообщениями.

Блок map кладётся в http-контекст (например, в /etc/nginx/nginx.conf). Проверяем и перезагружаем:

nginx -t && systemctl reload nginx

Тестирование и частые ошибки

Проверить wss можно утилитой websocat:

apt install -y websocat 2>/dev/null || cargo install websocat
websocat wss://ws.example.com/ws

• Соединение рвётся через 60 сек — не задан proxy_read_timeout; увеличьте до 3600s.
• 426 Upgrade Required — nginx не передаёт заголовок Upgrade; проверьте блок map.
• Too many open files — поднимите лимиты: ulimit -n 65535 и LimitNOFILE=65535 в юните.

Для десятков тысяч соединений добавьте worker_connections в nginx и берите план с запасом по RAM — на MAATRIX это делается апгрейдом тарифа без переезда.

Частые вопросы