WebSocket test online: как проверить соединение

Проверить WebSocket — значит убедиться, что:.

Ниже — разделы про что значит проверить WebSocket, первый способ: проверить в браузерной консоли и что смотреть в DevTools, чтобы быстро понять устройство материала, практические ограничения и типовые точки отказа.

Что значит проверить WebSocket

Проверить WebSocket — значит убедиться, что:

• клиент может открыть соединение;
• сервер принимает handshake;
• события open, message, close, error работают ожидаемо;
• сообщение можно отправить;
• ответ приходит;
• соединение не закрывается сразу;
• на продакшене нет проблемы с ws:// и wss://;
• proxy или Nginx не теряет заголовки Upgrade.

Запрос websocket test online часто появляется в момент паники: локально работало, на сервере нет; браузер молчит; в консоли красная ошибка; непонятно, виноват код, SSL, домен или proxy

Первый способ: проверить в браузерной консоли

Если endpoint открыт и не требует сложной авторизации, начните с DevTools

Откройте Console и выполните:

const socket = new WebSocket('ws://localhost:3000');

socket.addEventListener('open', () => {
  console.log('open');
  socket.send('hello');
});

socket.addEventListener('message', (event) => {
  console.log('message:', event.data);
});

socket.addEventListener('close', (event) => {
  console.log('close:', event.code, event.reason);
});

socket.addEventListener('error', (event) => {
  console.log('error:', event);
});

Если сервер на HTTPS-домене, адрес должен быть:

wss://example.com/socket

А не:

ws://example.com/socket

Что смотреть в DevTools

Откройте вкладку Network и найдите WebSocket-запрос. В современных браузерах можно смотреть:

• статус handshake;
• request headers;
• response headers;
• frames/messages;
• close code.

Если handshake не прошел, WebSocket-соединение даже не стало нормальным каналом. Значит, проблема до обмена сообщениями: адрес, proxy, SSL, авторизация, заголовки, сервер

Второй способ: online WebSocket client

Онлайн-клиенты удобны для публичных тестовых endpoint. Обычно вы вставляете URL, нажимаете Connect и отправляете сообщение

Но есть важное правило: не вставляйте в случайные online-инструменты приватные токены, production-cookie, секретные query-параметры и внутренние адреса. Для закрытых систем используйте локальные инструменты

Онлайн-проверка подходит для:

• учебного echo-сервера;
• публичного демо;
• endpoint без секретов;
• проверки, доступен ли сервер извне.

Не подходит для:

• приватной CRM;
• боевого чата с токеном;
• внутренних API;
• соединений с персональными данными.

Третий способ: Postman

Postman умеет работать с WebSocket-запросами. Это удобно, если вы уже проверяете REST API там же

Что проверить:

• URL начинается с ws:// или wss://;
• правильный path, например /socket или /ws;
• есть нужные headers;
• токен передается так, как ожидает сервер;
• сообщение отправляется в нужном формате: текст или JSON.

Пример JSON-сообщения:

{
  "type": "ping",
  "payload": {
    "source": "postman"
  }
}

Если сервер ждет строгий формат, обычное hello может не сработать. Это не значит, что WebSocket сломан. Это значит, что приложение не приняло ваше сообщение

Четвертый способ: CLI-клиент

Для Python-библиотеки websockets есть интерактивный клиент:

websockets ws://localhost:8765/

Если используете Node.js, можно поставить отдельный CLI-инструмент или написать маленький клиент на ws

client.js:

const WebSocket = require('ws');

const socket = new WebSocket('ws://localhost:3000');

socket.on('open', () => {
  console.log('open');
  socket.send('hello from node client');
});

socket.on('message', (data) => {
  console.log('message:', data.toString());
  socket.close();
});

socket.on('close', (code, reason) => {
  console.log('close:', code, reason.toString());
});

socket.on('error', console.error);

Запуск:

node client.js

Такой клиент полезен, когда браузерная страница добавляет лишний шум

Почему локально работает, а на сервере нет

Самые частые причины:

HTTPS-страница подключается к ws://

На продакшене нужен wss://

Nginx не передает Upgrade

Для WebSocket proxy нужны специальные заголовки. Если их нет, handshake ломается

Сервер слушает только localhost

Приложение может быть доступно внутри сервера, но не снаружи

Неверный path

Клиент подключается к /, а сервер ждет /ws

Авторизация работает иначе

REST API может брать токен из header, а WebSocket handshake настроен на cookie или query-параметр

Хостинг не поддерживает долгие соединения

Некоторые платформы закрывают соединения или имеют строгие таймауты

Проверка close code

Событие close может дать код:

socket.addEventListener('close', (event) => {
  console.log(event.code, event.reason, event.wasClean);
});

Полезно хотя бы увидеть, соединение закрыто сервером, клиентом, из-за ошибки или без нормального завершения

Проверка формата сообщения

Если сервер ждет JSON, отправляйте JSON:

socket.send(JSON.stringify({
  type: 'ping'
}));

Если сервер ждет конкретный тип:

{
  "type": "subscribe",
  "channel": "orders"
}

то hello не даст полезного ответа

Мини-чеклист диагностики

1. URL правильный?
2. Используется wss:// на HTTPS-сайте?
3. Сервер запущен?
4. Порт открыт?
5. Path совпадает?
6. Авторизация передается?
7. Формат сообщения правильный?
8. Nginx передает Upgrade?
9. В DevTools виден handshake?
10. Сервер пишет ошибку в логах?

Именно в таком порядке обычно быстрее найти проблему

Безопасность при тестировании

Не публикуйте:

• production URL с приватным токеном;
• cookie авторизованного пользователя;
• внутренние адреса;
• пароли в query string;
• реальные персональные данные в тестовом сообщении.

Для демонстрации используйте локальный echo-сервер или тестовый endpoint

Ответы на эти вопросы могут быть для вас полезными

Можно ли проверить WebSocket через curl?

Обычный curl не самый удобный инструмент для WebSocket. Лучше использовать браузер, Postman, специализированный CLI или библиотеку клиента

Почему online tester не подключается к localhost?

Потому что online-сервис работает не на вашем компьютере. Его localhost — это его сервер, а не ваш. Для локального endpoint используйте браузер или локальный клиент

Почему WebSocket сразу закрывается?

Причин много: сервер отверг handshake, неверная авторизация, неправильный path, ошибка приложения, proxy timeout или сервер сам закрывает соединение после первого сообщения

Как понять, что виноват Nginx?

Если напрямую к Node.js/FastAPI серверу подключение работает, а через домен нет, смотрите Nginx-конфиг: Upgrade, Connection, HTTP version, timeout

Нужно ли тестировать WebSocket отдельно от REST API?

Да. REST endpoint может работать идеально, а WebSocket ломаться из-за другого протокола, proxy или авторизации

Что почитать дальше по WebSockets

Если вы собираете тему по шагам, рядом лучше открыть:

• WebSocket простыми словами: когда нужен real-time — сверить, что именно должно происходить при handshake.
• WebSocket на JavaScript и Node.js: мини-чат в браузере — поднять тестовый Node.js endpoint для проверки.
• WebSocket на Python: быстрый пример клиента и сервера — поднять Python echo-сервер для диагностики.
• Nginx и WebSocket proxy: почему локально работает, а на сервере нет — дойти до типичных серверных причин 400, 502 и обрыва соединения.