Страница чата открывается, а живое соединение не работает: где искать
Страница и транспорт чата - разные запросы. Проверьте WebSocket, поток событий или длинный опрос, затем разделите настройку, доставку и время жизни.
Откройте панель сети до загрузки страницы чата, а затем найдите запрос, который несёт сообщения, а не тот, что рисует каркас страницы. Документ, скрипты, обмен при входе и транспорт чата могут идти на разные хосты. Большинство сообщений о том, что VPN сломал чат, на самом деле описывают сбой одного из этих четырёх запросов. Смотрите их по порядку, и ответ обычно виден в первые две минуты.
Найдите запрос, который несёт сообщения
Отфильтруйте по типу, когда страница успокоится: WebSocket появляется отдельной записью, поток событий остаётся открытым с растущим ответом, а длинный опрос повторяется с ровным интервалом. Запишите схему, хост, порт и состояние для того, который несёт обновления. Отметьте, начался он до или после входа, потому что транспорт, открытый до аутентификации, обычно устроен иначе, чем открытый после неё. Читайте заголовки запроса на обновление или принятый тип содержимого: они показывают транспорт, который развёрнутая страница выбрала на самом деле.
Старые сообщения на форумах описывают транспорты, от которых продукты отказались годы назад, поэтому доверяйте тому, что записал браузер, а не статье. Если записи нет вовсе, код клиента мог ни разу не попытаться подключиться, и это указывает на более ранний сбой скрипта или конфигурации. Загрузка страницы доказывает лишь то, что документ дошёл, и именно это различие решает, отлаживаете ли вы вообще сеть.
Настройка, доставка и время жизни ломаются по-разному
WebSocket открывается обновлением HTTP, на которое отвечают состоянием 101, а всё дальнейшее - сообщения в кадрах, а не загрузка страниц; эти два этапа RFC 6455 явно разделяет. Поток событий отвечает потоковым типом содержимого и держит тело ответа открытым. Оба могут не открыться, открыться и ничего не доставить или открыться, доставить и затем тихо умереть.
wscat -c wss://chat.example.com/socket -H "Origin: https://chat.example.com"
curl -N -H "Accept: text/event-stream" https://chat.example.com/events
Поймайте первый значимый сбой, прежде чем трогать профиль, потому что три момента указывают на разные слои. Если рукопожатие не завершается, сравните его с обычным запросом HTTPS на тот же хост и посмотрите, доходит ли до него хоть что-нибудь. Если оно завершается, а сообщения не приходят, смотрите на кадры или тело потока, пока кто-то отправляет тестовое сообщение с другого аккаунта. Если работает, а затем останавливается, запишите точное время и код закрытия: эта пара указывает, какая сторона сдалась.
Код 1006 означает, что сокет закрылся без кадра закрытия, и именно так изнутри браузера выглядит промежуточное устройство или тайм-аут простоя. Пульс VPN не доказывает, что внутренняя сессия приложения ещё жива.
Живой хост - отдельный адресат
Бэкенды чата часто живут на собственном имени хоста, иногда на другом порту или за отдельным сертификатом. Этому адресату нужны своё разрешение имени, маршрут и обработка прокси, а раздельное туннелирование может включить страницу и исключить сокет. Разрешите имя живого хоста с клиентской машины и подтвердите, что оно отвечает ожидаемым адресом в этой сети. Проверьте цепочку сертификатов именно для этого имени хоста: подстановочный сертификат, покрывающий сайт, не всегда покрывает конечную точку сокета.
Если на пути стоит прокси, убедитесь, что он разрешает обновление или долгий ответ, а не буферизует их. Корпоративные прокси, переписывающие HTML, часто плохо обрабатывают обновления WebSocket, и получается страница, которая рисуется, пока чат так и не подключается. Поэтому два запроса к одному продукту - не два запроса к одному хосту.
Исправляйте список адресатов, а не проверки безопасности
Исправление списка адресатов - это изменение маршрутизации, и оно принадлежит владельцу маршрута. Ослабление проверки сертификатов или удаление заголовка Origin - это изменение безопасности, и оно принадлежит владельцу политики, которым редко бывает человек, отлаживающий тикет. Самый быстрый способ сделать соединение работающим обычно совпадает с самым быстрым способом сделать инцидент возможным.
Прежде чем что-либо менять, спросите владельца приложения, какие источники принимает бэкенд, и передайте этот ответ тому, кто управляет прокси. Если ошибка сертификата появляется только через туннель, осмотрите перехватывающее устройство, а не устанавливайте обход.
Запишите достаточно, чтобы передать
Полезный артефакт короток: URL страницы, живая конечная точка, результат рукопожатия, время первого сбоя и была ли попытка переподключения. Добавьте имя профиля VPN и сеть, в которой вы были, и любой читатель воспроизведёт тест, не задавая шесть вопросов. Скрывайте cookie, заголовки авторизации и тела сообщений и предпочитайте снимок экрана со столбцом времени полному экспорту архива. Кадры и сетевые архивы могут содержать личные сообщения и токены сессий, поэтому просмотрите их перед вложением.
Если сбой - тихое закрытие, включите код закрытия и интервал простоя перед ним: эта пара обычно указывает владельца тайм-аута. Передайте запись владельцу приложения или шлюза, а не угадывайте значение тайм-аута сами. Их ответ о поддерживаемом поведении keepalive и закрывает тикет.