# SSL_ERROR_RX_RECORD_TOO_LONG: что проверить владельцу сайта
Если Firefox показывает `SSL_ERROR_RX_RECORD_TOO_LONG`, это значит, что браузер ожидал нормальное HTTPS-соединение, но получил некорректный ответ на этапе TLS. Для владельца сайта это опасная ситуация: у вас может открываться главная страница в одном браузере, а часть посетителей уже не может зайти на сайт, в личный кабинет или на страницу оплаты.
Ошибка нередко выглядит как «еще одна проблема с сертификатом», хотя причина может быть глубже: порт 443 отвечает обычным HTTP, прокси или CDN отправляют трафик не туда, сертификат не привязан к нужному хосту или после переноса сайта сломалась конфигурация HTTPS. Ниже — порядок проверки без лишней теории и с практическими примерами.
Что означает ошибка SSL_ERROR_RX_RECORD_TOO_LONG
Эта ошибка появляется, когда браузер пытается договориться с сайтом о защищенном соединении, но вместо корректного TLS-ответа получает что-то другое. Проще говоря, клиент пришел на HTTPS, а сервер, прокси или промежуточный узел ответил так, будто защищенное соединение настроено неправильно.
Для владельца сайта это важный сигнал по двум причинам:
- проблема может затрагивать не весь сайт, а только отдельный домен, поддомен или страницу;
- жалобы пользователей часто появляются раньше, чем ошибка становится очевидной в админке хостинга;
- ручная проверка главной страницы не гарантирует, что HTTPS работает везде.
Если рядом с этой ошибкой вы видите и другие HTTPS-сбои, полезно сравнить симптомы со статьями ERR_SSL_PROTOCOL_ERROR и проблемами цепочки сертификата.
Почему появляется SSL_ERROR_RX_RECORD_TOO_LONG
Порт 443 отвечает не HTTPS, а обычным HTTP
Одна из типичных причин — сервер слушает 443 порт, но на нем не включен TLS. Браузер приходит за HTTPS, а в ответ получает обычный HTTP-заголовок или другой неподходящий ответ. Такое бывает после переноса сайта, ручного редактирования конфигурации Nginx или Apache и переключения между несколькими виртуальными хостами.
Практический пример: сайт переехал на новый VPS, домен уже указывает на новый IP, но конфигурация `listen 443 ssl` не применена или сертификат подключен не к тому server block. В результате часть посетителей видит ошибку сразу, хотя сам веб-сервер формально работает.
Сертификат не привязан к нужному хосту
Иногда основной домен открывается нормально, а ошибка появляется только на `www`, `api`, `shop` или другой важной точке входа. Для владельца это особенно неприятно: главная страница выглядит живой, но форма заказа, личный кабинет или checkout уже недоступны.
Такой сценарий часто возникает после запуска нового поддомена, подключения отдельной панели, CRM-формы или переноса страницы оплаты на другой хост.
Прокси, CDN или балансировщик отправляют трафик не туда
Если между посетителем и origin-сервером стоит CDN, reverse proxy или балансировщик, ошибка может находиться не на самом сайте, а на промежуточном уровне. Например, edge-узел пытается сходить к origin по HTTPS, но получает оттуда ответ без корректного TLS, или запрос уходит на неправильный backend.
На практике это проявляется так: часть клиентов видит ошибку только в определенный момент, только на отдельном маршруте или только на одном хосте. Поэтому нельзя ограничиваться проверкой одной страницы из одного браузера.
После редиректа запрос уходит на неправильный порт или схему
Еще одна причина — некорректная цепочка редиректов. Например, сайт принудительно переводит пользователя на HTTPS, но делает это через неправильный порт, старый backend или промежуточный адрес, который не обслуживает нормальный TLS.
Внешне это может выглядеть как случайная HTTPS-ошибка, хотя проблема находится в правилах редиректа или в связке прокси и веб-сервера.
Как быстро понять, проблема у вас или у пользователя
Сначала нужно отделить массовую проблему от локальной.
Проверьте сайт из нескольких точек
Откройте проблемный URL:
- в Firefox и еще одном браузере;
- с мобильного интернета и из обычной сети;
- на главной странице и на той странице, где жалуются пользователи.
Если ошибка воспроизводится только на одном устройстве, в одной корпоративной сети или только у одного сотрудника, причина может быть в локальном прокси, антивирусе или фильтрации трафика. Но если сбой повторяется в разных сетях, искать нужно в конфигурации сайта.
Проверьте именно тот хост, на который жалуются
Не ограничивайтесь адресом `example.ru`. Отдельно проверьте `www`, `api`, `shop`, страницу входа, checkout и другие важные маршруты. Для пользователя это один сайт, а для TLS и прокси это могут быть разные конфигурации.
Сверьте SSL и доступность снаружи
Для быстрой ручной диагностики можно открыть проверку SSL и проверку доступности сайта. Первая помогает увидеть проблему с HTTPS, а вторая — понять, отвечает ли сайт вообще и не маскируется ли SSL-сбой под общую недоступность.
Пошаговый чек-лист для владельца сайта
1. Проверьте DNS и текущий IP
Убедитесь, что домен и нужные поддомены указывают на тот сервер, который вы действительно обслуживаете. После переезда сайта или смены CDN ошибка иногда возникает потому, что часть трафика уже идет на новый сервер, а часть — еще на старую конфигурацию.
Если сайт открывается по IP, но ломается по домену, полезно дополнительно свериться с материалом сайт открывается по IP, но не по домену.
2. Убедитесь, что на 443 порту действительно настроен TLS
Проверьте конфигурацию веб-сервера, панели хостинга или прокси. Важно не просто наличие открытого порта 443, а то, что этот порт обслуживается корректным HTTPS-конфигом именно для нужного домена.
Если есть доступ к терминалу, полезно проверить ответ сервера командой `openssl s_client -connect example.ru:443 -servername example.ru -showcerts`. Она помогает увидеть, что именно сайт отдает на этапе TLS и какой сертификат показывает.
3. Проверьте сертификат именно для проблемного хоста
Сертификат должен покрывать тот адрес, который реально открывает посетитель. Если проблема на `shop.example.ru`, бесполезно проверять только `example.ru`. Отдельно посмотрите:
- совпадает ли домен в сертификате;
- не забыли ли вы про `www` или поддомен;
- не истек ли срок действия;
- не сломалась ли цепочка сертификатов после перевыпуска.
4. Проверьте прокси, CDN и backend-маршруты
Если используется Cloudflare, CDN провайдера, reverse proxy или балансировщик, важно понять, куда именно он отправляет HTTPS-трафик. Ошибка может быть не на уровне браузера, а между edge и origin. Особенно внимательно проверьте эту часть после переключения режима проксирования, переноса origin-сервера или замены сертификата.
5. Посмотрите недавние изменения
`SSL_ERROR_RX_RECORD_TOO_LONG` редко появляется «сам по себе». Чаще перед этим было одно из изменений:
- перенос сайта на новый сервер;
- подключение нового поддомена;
- замена сертификата;
- включение CDN или WAF;
- изменение правил редиректа;
- перенос формы оплаты, API или личного кабинета на отдельный хост.
Если жалобы начались после конкретного изменения, ищите проблему сначала там. Это обычно быстрее, чем разбирать всю инфраструктуру с нуля.
Два практических сценария
После переноса сайт открывается не у всех
Представим, что вы перенесли сайт на новый VPS, обновили A-запись и убедились, что главная страница открывается. Через час менеджер присылает скриншот Firefox с `SSL_ERROR_RX_RECORD_TOO_LONG`. При проверке выясняется, что на новом сервере 443 порт слушает, но HTTPS для нужного virtual host настроен не полностью. В браузере это выглядит как ошибка SSL, хотя на самом деле проблема в конфигурации веб-сервера.
Ошибка только на странице заказа
Другой сценарий: каталог и главная страница работают, а на шаге оформления заказа пользователь получает ошибку HTTPS. Причина может быть в том, что checkout вынесен на отдельный поддомен, а сертификат или проксирование для него не настроены. Пока команда проверяет только главную страницу, проблема остается незаметной и напрямую бьет по продажам.
Как не узнавать об ошибке последним
Разовые ручные проверки помогают только в момент, когда вы уже подозреваете сбой. Но `SSL_ERROR_RX_RECORD_TOO_LONG` опасен именно тем, что может затронуть отдельный хост, конкретную страницу или только часть посетителей.
Чтобы такие проблемы не оставались незамеченными, полезно контролировать:
- HTTPS на основном домене;
- HTTPS на ключевых поддоменах;
- важные страницы вроде логина, формы заявки и checkout;
- срок действия SSL и общую внешнюю доступность сайта.
Чтобы не проверять это вручную, можно настроить автоматический мониторинг в Web-Puls. Он помогает быстрее заметить, что сайт перестал корректно открываться по HTTPS, и не ждать, пока о проблеме напишут клиенты.
Когда лучше сразу обратиться за поддержкой
Если ошибка связана не только с одним сертификатом, а затрагивает CDN, reverse proxy, DNS, поддомены или серверную конфигурацию, самостоятельная проверка может затянуться. В такой ситуации разумно быстрее собрать симптомы и передать задачу специалисту.
Если проблему нужно не только заметить, но и разобрать технически, можно оставить заявку через форму поддержки или воспользоваться контактами. Это особенно полезно, когда HTTPS ломается на боевом сайте с оплатой, заявками или авторизацией.
Вывод
`SSL_ERROR_RX_RECORD_TOO_LONG` не означает автоматически «сертификат истек». Чаще это признак того, что HTTPS настроен некорректно на одном из уровней: на 443 порту, в виртуальном хосте, в цепочке сертификатов, в прокси или в маршруте до origin-сервера.
Чем раньше вы проверите точный хост, сертификат, порт 443 и недавние изменения, тем быстрее восстановите доступность сайта. А чтобы не ловить такие сбои только по жалобам пользователей, стоит заранее держать под контролем SSL и внешнюю доступность сайта.