Когда регулятор вмешивается в интернет-трафик: почему сайт начал зависать и как мы решили проблему

Сбой в работе сайта не всегда связан с ошибками кода, сервером или CMS. Иногда узкое место находится вне проекта и даже вне зоны досягаемости - в сетевой инфраструктуре, DNS, маршрутизации или политиках интернет-регуляторов. Именно с такой нетипичной, но показательной ситуацией наша команда столкнулась на одном из проектов в ноябре 2025 года.

Этот кейс демонстрирует, почему техподдержка сайтов обязана включать не только работу с кодом, но и глубокую диагностику сетевой части, DNS, внешних API и смежных инфраструктурных зависимостей.

Симптомы проблемы: сайт «висит» при обращении к внешним системам

У клиента начали массово зависать страницы сайта. Причём зависание возникало не всегда, а только при действиях, связанных с внешними API. Особенно это проявлялось в:

• обращениях к Google reCAPTCHA;

• расчёте стоимости доставки через API логистики;

• попытках получить информацию о скидках из программы лояльности;

• отправке SMS-кодов через сторонний шлюз.

Также мобильное приложение клиента стало работать настолько медленно и нестабильно, что пользоваться им стало невозможно.

Поверхностная диагностика выявила, что внешние сервисы отвечали слишком долго - запросы могли «висеть» от 20–30 секунд до более чем минуты, что приводило к:

• зависанию выполнения всего кода, который обращался к сторонним сервисам;

• превышению лимитов max_execution_time;

• перегрузке очередей запросов.

В общем и целом, такое качество работы сайта не могло не вызвать недовольство посетителей сайта, а из-за того, что проблема проявилась в разгар рекламной кампании, с нами связался возмущённый маркетолог заказчика, думающий, что мы устроили внеочередное развёртывание в прайм-тайм и сливаем их рекламный бюджет. На позиции в поисковой выдаче такие проблемы тоже влияют, ведь страницы, которые загружаются долго или с ошибками, с первых позиций перемещаются на последние, а вслед за отдельными страницами уходит и весь сайт.

Диагностика: проблема оказалась не на сайте, а в интернете

После анализа логов и трассировок стало ясно: сам сервер, код и CMS работают стабильно. В большинстве сценариев проверки ошибки не фиксировались, нестабильность проявлялась только в случаях, предусматривающих обращения к некоторым внешним сервисам, причём, не ко всем. Мы провели масштабную диагностику доступности сервисов, с которыми взаимодействует сайт, используя  traceroute/mtr, dig/nslookup, curl и telnet.

Диагностика продемонстрировала предельно странные результаты: какие-то сервисы работали штатно, до каких-то трафик не доходил, у некоторых не резолвились домены или резолвились с задержкой больше минуты. Проверочный скрипт, который обращался к сайту заказчика, который мы запустили на том же самом сервере, где размещается сайт, нормально выполнил более чем сотню HTTP-запросов, однако при выполнении некоторых не мог выполнить резолвинг домена сайта.

Предполагаемая причина: особенности работы российского регулятора

(которые повлияли на Google, внешние API и даже DNS)

Опрос коллег по несчастью показал, что в этот период один из российских регуляторов вводил новые механизмы фильтрации и регулирования интернет-трафика. Побочными эффектами стали:

1. Случайная блокировка DNS-резолвинга отдельных доменов

Это привело к тому, что сервер иногда… не мог узнать IP-адрес даже собственного домена. Запросы просто висели, ожидая ответа от внезапно заблокированного DNS-сервера, контейнеризованные приложения не предусматривали такую потенциальную неисправность, и такие молчаливые отказы в обслуживании DNS приводили к полной остановке работы контейнера, то есть, у заказчика отказали и бэкенд мобильного приложения, и интеграционные сервисы, и внутреннее ПО, с которым работают сотрудники.

2. Частичная блокировка IPv4-трафика на цепочке маршрутов до зарубежных датацентров

Маршруты до ряда датацентров, расположенных вне РФ, и связанных с ними сервисов периодически деградировали, что сказывалось на:

• reCAPTCHA;

• API-сервисах доставки;

• сервисах аналитики и аутентификации;

• связке с сервисом программы лояльности, с которой сотрудничает наш клиент;

• некоторых SMS-шлюзах, даже не связанных с инфраструктурой Google.
   

Иными словами - сайт работал, сервер работал, код работал, а внешняя среда была нестабильной.

Решение: сетевой обход проблемных зон

Мы внедрили комплекс мер, нацеленных на исключение точек отказа:

✔ 1. Ручная установка проверенных DNS-серверов

Мы явно прописали публичные DNS-резолверы:

• Cloudflare - 1.1.1.1 / 1.0.0.1

• Google - 8.8.8.8 / 8.8.4.4

• Quad9 - 9.9.9.9
   

Это позволило полностью обойти DNS-серверы, получаемые через DHCP. Впоследствии, когда мы описали проблему хостинг-провайдеру, он установил нам эти DNS для автоматической выдачи по DHCP.

✔ 2. Настройка статической IPv6-конфигурации

Хостинг-провайдер выдаёт IPv6, но, так как DHCPv6 в его инфраструктуре отключён, этот сетевой протокол требует статической настройки. Мы запросили у провайдера актуальную конфигурацию: шлюз, варианты маски и адреса его DNS для IPv6 соединений.
 

IPv6-маршрутизация оказалась полностью исправна и не подвержена «блокировкам» IPv4-маршрутов, затронутых регулятором.

✔ 3. Настройка IPv6 для Docker-контейнеров, которым нужен доступ наружу

Мы вручную прописали:

• сетевую конфигурацию IPv6 и DNS для docker-daemon,

• разрешения маршрутизации IPv6 для всех виртуальных сетей docker compose

Это позволило критичным сервисам (recaptcha, SMS, API доставки, система лояльности) уходить во внешнюю сеть через рабочие IPv6-маршруты, минуя проблемный IPv4-сегмент, который впрочем, на следующий день снова начал чувствовать себя нормально, но с такой работой регулятора это вряд ли надолго.

Результат: время выполнения скриптов упало с 1 минуты до 1.5 секунд

После перенастройки сетевой инфраструктуры DNS-резолвинг вновь начал проходить мгновенно, а задержка до всех внешних ресурсов перестала превышать 100 мс.

Сайт снова стал работать стабильно и быстро, рекламный бюджет клиента спасён,  спокойствию заказчика и его клиентов больше ничего не угрожает.

Описанная авария была зафиксирована дважды с интервалом в неделю, диагностика и разработка надёжного решения потребовали суммарно 7 человеко-часов.

Почему этот кейс - пример того, что техподдержка сайта должна быть профессиональной

Этот случай подчёркивает важную мысль: ряд задач обслуживания сайтов требует широких смежных компетенций и в разработке самих сайтов, и в DevOps, и в сетевой инфраструктуре и диагностике. Одному специалисту, будь он системным администратором или разработчиком, такая проблема оказалась бы не по зубам.

Что мы используем для таких задач

• анализ сетевой деградации (traceroute/mtr);

• диагностика DNS;

• dual-stack IPv4/IPv6;

• конфигурация виртуальных сетей Docker;

• мониторинг внешних API;

• контроль времени отклика по каждому интеграционному узлу.

Несмотря на то, что эта проблема встречается редко, наш инструментарий профессиональной техподдержки сайтов смог её локализовать и помог обойти.

Хотите, чтобы ваш сайт работал быстро и стабильно, даже при внешних сбоях?

Мы в Синвеб занимаемся технической поддержкой, администрированием и оптимизацией производительности коммерческих сайтов.

Если ваш сайт зависает или работает медленнее, чем раньше, мы найдём и устраним причину. Как видите, у нас есть средства, которые могут помочь даже в тех случаях, когда проблема находится вне вашего сайта и даже не у вашего хостинг-провайдера.

Напишите нам - и мы сделаем так, чтобы ваш сайт работал быстро, стабильно и предсказуемо.

Сергей Семёнов

Руководитель Синвеб. Веду проекты и организую разработку с фокусом на юзабилити. Пишите, поболтаем.