Обрыв кабелей, штормы и сбои DNS: как ломался интернет в конце 2025

В 2025 году мы зафиксировали более 180 нарушений работы Интернета, вызванных различными причинами: некоторые были краткими и частичными, другие — полными отключениями, длившимися несколько дней. В четвёртом квартале мы отследили лишь одно санкционированное правительством отключение Интернета, однако несколько повреждений кабелей вызвали хаос в подключении в ряде стран. Отключения электроэнергии и экстремальные погодные условия нарушили работу интернет-сервисов в нескольких регионах, а продолжающийся конфликт на Украине также повлиял на доступность связи там. Как всегда, часть зафиксированных сбоев была вызвана техническими проблемами — некоторые из них были признаны соответствующими провайдерами, в то время как причины других остались неизвестными. Кроме того, инциденты на нескольких платформах гиперскейлеров облачных платформ и в Cloudflare повлияли на доступность веб-сайтов и приложений.

Данная публикация представляет собой краткий обзор наблюдавшихся и подтверждённых сбоев и не является исчерпывающим или полным перечнем проблем, возникших в течение квартала. Эти аномалии выявляются на основе значительных отклонений от ожидаемых моделей трафика, наблюдаемых в нашей сети. Полный список верифицированных аномалий и подтверждённых отключений смотрите в Центре отключений Cloudflare Radar.

Интернет в Танзании был отключён 29 октября, когда во время президентских выборов в стране произошли акции насильственного протеста. Трафик начал падать около 12:30 по местному времени (09:30 UTC), снизившись более чем на 90% по сравнению с предыдущей неделей. Сбой длился примерно 26 часов, и трафик начал возвращаться около 14:30 по местному времени (11:30 UTC) 30 октября. Однако это восстановление оказалось весьма кратковременным: значительное снижение трафика произошло около 16:15 по местному времени (13:15 UTC), примерно через два часа после его возвращения. Это второе, почти полное отключение продлилось до 3 ноября, когда трафик начал активно возвращаться после 17:00 по местному времени (14:00 UTC). Во время отключения также наблюдались незначительные сокращения в объявленном адресном пространстве IPv4 и IPv6, однако полного прекращения анонсов, которое означало бы полное отключение страны от Интернета, не было. (Автономные системы объявляют IP-адресное пространство другим интернет-провайдерам, сообщая им, за какие блоки IP-адресов они отвечают.)

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

К сожалению, для Digicel Haiti сбои Интернета из-за повреждения кабелей не редкость, и в четвёртом квартале в сети произошло ещё два подобных инцидента. 16 октября трафик от Digicel Haiti (AS27653) начал падать в 14:30 по местному времени (18:30 UTC), достигнув почти нуля к 16:00 по местному времени (20:00 UTC). В переведённом сообщении в X от генерального директора компании отмечалось: «Сообщаем нашей клиентуре, что @DigicelHT столкнулся с 2 повреждениями на своей международной волоконно-оптической инфраструктуре». Трафик начал восстанавливаться после 17:00 по местному времени (21:00 UTC) и достиг ожидаемого уровня в течение следующего часа. В 17:33 по местному времени (21:34 UTC) генеральный директор опубликовал, что «первое волокно на международной инфраструктуре было восстановлено» и сервис возобновлён.

25 ноября в другом переведённом сообщении в X от генерального директора провайдера говорилось, что была повреждена «международная волоконно-оптическая инфраструктура на национальной дороге № 1». Мы наблюдали падение трафика в сети Digicel примерно на час раньше, а полное отключение было зафиксировано между 02:00 и 08:00 по местному времени (07:00–13:00 UTC). В последующем сообщении в X в 08:22 по местному времени (13:22 UTC) было заявлено, что все сервисы восстановлены.

20 октября в 17:30 по местному времени (12:30 UTC) интернет-трафик для Cybernet/StormFiber (AS9541) резко упал, достигнув уровня примерно в 50% от показателей в то же время неделей ранее. Одновременно объявленное сетью адресное пространство IPv4 сократилось более чем на треть. Причиной этих изменений стало повреждение подводного кабеля PEACE, который был повреждён в Красном море недалеко от Судана.

PEACE — одна из нескольких подводных кабельных систем (включая IMEWE и SEA-ME-WE-4), которые передают международный интернет-трафик для пакистанских провайдеров. Провайдер пообещал полностью восстановить сервис к 27 октября, однако трафик и объявленное адресное пространство IPv4 восстановились до почти ожидаемого уровня уже около 02:00 по местному времени 21 октября (21:00 UTC 20 октября).

Необычные модели трафика, наблюдавшиеся у нескольких интернет-провайдеров в Камеруне 23 октября, по сообщениям, были вызваны проблемами на подводном кабеле WACS (Западноафриканская кабельная система), который соединяет страны западного побережья Африки с Португалией.

В опубликованном отчёте (перевод) говорилось, что MTN уведомила абонентов, что «в связи с инцидентом на волоконно-оптическом кабеле WACS интернет-сервис временно нарушен», а Orange Cameroun сообщила абонентам, что «из-за инцидента на международном канале доступа интернет-сервис нарушен». В сообщении Camtel в X говорилось: «Cameroon Telecommunications (CAMTEL) желает проинформировать общественность, что в ранние часы 23 октября 2025 года произошёл технический инцидент с оборудованием кабеля WACS в Батоке (ЛИМБЕ), вызвавший сбои в подключении к Интернету по всей стране».

Трафик у затронутых провайдеров изначально упал около 05:00 по местному времени (04:00 UTC), прежде чем восстановиться до ожидаемого уровня около 22:00 по местному времени (21:00 UTC). В течение дня трафик в этих сетях был весьма нестабильным, временами падая на 90–99%. Неясно, что вызвало заметную волатильность в модели трафика — возможно, попытки переключить интернет-трафик на другие подводные кабельные системы, соединённые с Камеруном. Объявленное IP-адресное пространство от MTN Cameroon и Orange Cameroon также сократилось в этот период, хотя объявленное IP-адресное пространство Camtel не изменилось.

Подключение в Центральноафриканской Республике и Республике Конго, по сообщениям, также пострадало из-за проблем с WACS.

9 декабря мы наблюдали, как трафик от интернет-провайдера Claro Dominicana (AS6400) в Доминиканской Республике резко упал около 12:15 по местному времени (16:15 UTC). Уровень трафика снова снизился около 14:15 по местному времени (18:15 UTC), достигнув минимума на 77% ниже, чем на предыдущей неделе, после чего быстро вернулся к ожидаемым значениям. Перерыв в соединении, вероятно, был вызван двумя повреждениями оптоволокна, как указал пост провайдера в X во время инцидента, где отмечалось, что они «вызывают прерывистую работу и замедление некоторых услуг». В последующем сообщении в X компания Claro заявила, что технические специалисты восстановили интернет-услуги по всей стране, отремонтировав повреждённые оптоволоконные кабели.

Согласно (переведённому) сообщению в X от Empresa de Transmisión Eléctrica Dominicana (ETED), 11 ноября отключение линии электропередачи вызвало перерыв в электроснабжении в Доминиканской Республике. Это привело к снижению интернет-трафика из страны, что вызвало падение трафика почти на 50% по сравнению с предыдущей неделей, начиная с 13:15 по местному времени (17:15 UTC). Уровень трафика оставался низким до примерно 02:00 по местному времени (06:00 UTC) 12 декабря. Позднее в (переведённом) сообщении ETED в X отмечалось: «В 2:20 ночи мы завершили восстановление национальной энергосистемы, обеспечив 96% спроса…»

Последующий технический отчёт установил, что «отключение началось на подстанции 138 кВ Сан-Педро-де-Макорис I, где линия под напряжением была отключена вручную, что вызвало короткое замыкание высокой интенсивности. Системы защиты сработали немедленно, но авария привела к отключению нескольких соседних линий, отделив 575 МВт генерации в восточном регионе от остальной части сети. Дисбаланс вызвал автоматическое отключение крупных электростанций в рамках их встроенных механизмов безопасности.»

9 декабря крупное отключение электроэнергии затронуло несколько регионов Кении. Компания Kenya Power пояснила, что отключение «было вызвано инцидентом в региональной межсетевой энергосистеме Кения-Уганда, который вызвал сбой на кенийской стороне системы», и заявила, что «электроснабжение в большинстве пострадавших районов было восстановлено примерно в течение 30 минут.» Однако влияние на интернет-соединение длилось почти четыре часа, с 19:15 до 23:00 по местному времени (16:15 - 20:00 UTC). Отключение электроэнергии привело к падению трафика на национальном уровне до 18%, причём наиболее заметные изменения трафика наблюдались в округ Накуру и округ Каимбу.

Российские удары дронами по Одесской области в Украине 12 декабря повредили склады и энергетическую инфраструктуру, причём последнее вызвало перебои с электричеством в некоторых частях региона. Эти отключения нарушили интернет-соединение, что привело к падению трафика до 57% по сравнению с предыдущей неделей. После первоначального падения в полночь 13 декабря (22:00 UTC 12 декабря) трафик постепенно восстанавливался в течение следующих нескольких дней, вернувшись к ожидаемым уровням около 14:30 по местному времени (12:30 UTC) 16 декабря.

Ураган Мелисса обрушился на Ямайку 28 октября, оставив после себя след разрушений. Связанные с этим отключения электроэнергии и повреждения инфраструктуры повлияли на интернет-соединение, в результате чего трафик сначала упал примерно вдвое, начиная примерно с 06:15 по местному времени (11:15 UTC), в конечном итоге достигнув уровня на 70% ниже, чем на предыдущей неделе. Интернет-трафик с Ямайки оставался значительно ниже уровней, предшествовавших урагану, в течение нескольких дней и начал активно приближаться к ожидаемым значениям утром 4 ноября. Часто могут потребоваться недели или месяцы, чтобы интернет-трафик из страны вернулся к «нормальному» уровню после штормов, вызывающих масштабные и повсеместные разрушения — хотя электроснабжение может быть в основном восстановлено в течение нескольких дней, повреждения физической инфраструктуры требуют значительно больше времени для устранения.

26 ноября Циклон Сеняр вызвал катастрофические наводнения и оползни в Шри-Ланке и Индонезии, унеся жизни более 1000 человек и повредив телекоммуникационную и энергетическую инфраструктуру в этих странах. Повреждения инфраструктуры привели к нарушениям интернет-соединения и снижению уровня трафика в нескольких регионах.

В Шри-Ланке наиболее пострадали регионы за пределами основной Западной провинции, и в нескольких провинциях трафик упал на 80–95% по сравнению с предыдущей неделей, включая Северо-Западную, Южную, Уву, Восточную, Северную, Северо-Центральную и Сабарагамуву.

В Индонезии наибольшие перебои в работе интернета наблюдались в Ачехе и регионах Суматры. В Ачехе трафик изначально упал более чем на 75% по сравнению с предыдущей неделей. На Суматре наиболее пострадала Северная Суматра, где первоначальное падение составило 30% по сравнению с предыдущей неделей, после чего на следующей неделе началось более активное восстановление.

3 октября у абонентов индонезийского интернет-провайдера Smartfren (AS18004) произошел сбой в обслуживании. Проблемы были подтверждены провайдером в публикации на X, где говорилось (в переводе): «В настоящее время телефонные, SMS- и интернет-услуги работают с перебоями в нескольких районах.» Трафик от провайдера упал на целых 84%, начиная примерно с 09:00 по местному времени (02:00 UTC). Сбой длился около восьми часов, поскольку трафик вернулся к ожидаемым уровням около 17:00 по местному времени (10:00 UTC). Smartfren не предоставил никакой дополнительной информации о причинах проблем с обслуживанием.

Крупный британский интернет-провайдер Vodafone UK (AS5378 и AS25135) столкнулся с кратковременным сбоем 23 октября. В 15:00 по местному времени (14:00 UTC) трафик на обоих ASN Vodafone упал до нуля. Объявленное адресное пространство IPv4 от AS5378 сократилось на 75%, в то время как объявленное адресное пространство IPv4 от AS25135 исчезло полностью. Как интернет-трафик, так и адресное пространство восстановились через два часа, вернувшись к ожидаемым уровням около 17:00 по местному времени (16:00 UTC). Vodafone не предоставила никакой информации на своих каналах в социальных сетях о причине сбоя, и их страница проверки состояния сети также была недоступна во время простоя.

Согласно опубликованному отчету, проблема с разрешением DNS нарушила работу интернет-услуг для клиентов итальянского провайдера Fastweb (AS12874) 22 октября, что привело к падению наблюдаемого объема трафика более чем на 75%. Fastweb подтвердил проблему, которая затронула клиентов с проводным интернетом в период с 09:30 до 13:00 по местному времени (08:30 - 12:00 UTC).

Хотя это и не был отказ интернета, вызванный потерей связи, влияние проблем с разрешением DNS на интернет-трафик очень похоже. Когда DNS-резолвер провайдера испытывает проблемы, переход на такой сервис, как публичный DNS-резолвер Cloudflare 1.1.1.1, часто восстанавливает подключение.

7 декабря было зафиксировано одновременное падение трафика в сетях SBIN (AS28683), MTN Benin (AS37424) и Etisalat Benin (AS37136). В период с 18:30 до 19:30 по местному времени (17:30 - 18:30 UTC) трафик упал на целых 80% по сравнению с предыдущей неделей на уровне страны, почти на 100% у Etisalat и MTN и более чем на 80% у SBIN.

Хотя попытка переворота произошла ранее в тот же день, неясно, было ли наблюдаемое нарушение работы интернета как-то связано с этим. С точки зрения маршрутизации, все три затронутые сети имеют Cogent (AS174) в качестве вышестоящего провайдера, поэтому локальная проблема у Cogent могла способствовать кратковременному сбою.

Согласно сообщенному заявлению израильского провайдера Cellcom (AS1680), 18 декабря произошел «сбой, влияющий на интернет-соединение, который затрагивает некоторых наших клиентов». Этот сбой привел к падению трафика почти на 70% по сравнению с предыдущей неделей и произошел между 09:30 и 11:00 по местному времени (07:30 - 09:00 UTC). Согласно опубликованному отчету, «сбоем» мог быть отказ DNS.

Завершая 2025 год, 30 декабря крупный технический сбой у израильского провайдера Partner Communications (AS12400) нарушил работу мобильной связи, телевидения и интернет-услуг по всей стране. Интернет-трафик от Partner упал на две трети по сравнению с предыдущей неделей в период с 14:00 до 15:00 по местному времени (12:00 - 13:00 UTC). Во время простоя количество запросов к публичному DNS-резолверу Cloudflare 1.1.1.1 резко возросло, что позволяет предположить, что проблема могла быть связана с DNS-инфраструктурой Partner. Однако провайдер публично не подтвердил, что стало причиной сбоя.

В четвертом квартале мы запустили новую страницу Cloud Observatory на Radar, которая отслеживает проблемы доступности и производительности на региональном уровне у гипермасштабных облачных платформ, включая Amazon Web Services, Microsoft Azure, Google Cloud Platform и Oracle Cloud Infrastructure.

20 октября регион Amazon Web Services us-east-1 в Северной Вирджинии испытал «повышенный уровень ошибок и задержек», которые затронули несколько сервисов в регионе. Проблемы повлияли не только на клиентов с публичными веб-сайтами и приложениями, которые полагаются на инфраструктуру в регионе, но и на клиентов Cloudflare, у которых исходные ресурсы размещены в us-east-1.

Мы начали наблюдать влияние проблем около 06:30 UTC, когда доля ошибочных (5xx-класс) ответов начала расти, достигнув 17% около 08:00 UTC. Количество сбоев при попытке подключения к источникам в us-east-1 также возросло, достигнув пика около 12:00 UTC.

Влияние также было четко видно в ключевых показателях производительности сети, которые оставались повышенными на протяжении всего инцидента, вернувшись к нормальным уровням незадолго до его окончания, около 23:00 UTC. Как TCP, так и TLS длительности рукопожатий постепенно ухудшались на протяжении инцидента — эти метрики измеряют время, необходимое Cloudflare для установки TCP- и TLS-соединений соответственно с исходными серверами клиентов в us-east-1. Кроме того, время, прошедшее до того, как Cloudflare получил заголовки ответов от источника, значительно увеличилось в течение первых нескольких часов инцидента, прежде чем постепенно вернуться к ожидаемым уровням.

29 октября в Microsoft Azure произошел инцидент, затронувший Azure Front Door, её сервис доставки контента. Согласно отчету Azure об инциденте, «Особая последовательность изменений конфигурации клиентов, выполненных в двух разных версиях сборки плоскости управления, привела к генерации несовместимых метаданных конфигурации. Сами эти изменения конфигурации были корректными и не злонамеренными — однако они создали метаданные, которые при развертывании на серверах периферийных узлов выявили скрытую ошибку в плоскости данных. Эта несовместимость спровоцировала сбой во время асинхронной обработки в сервисе плоскости данных.»

В отчете об инциденте время начала указано как 15:41 UTC, хотя мы наблюдали, как количество неудачных попыток подключения к ресурсам, размещенным в Azure, начало расти примерно на 45 минут раньше. Метрики TCP и TLS-рукопожатий также стали более нестабильными в период инцидента: TCP-рукопожатия в некоторые моменты занимали на 50% больше времени, а TLS-рукопожатия — почти на 200% дольше на пике. Затронутые метрики начали улучшаться после 20:00 UTC, и, по данным Microsoft, инцидент был исчерпан в 00:05 UTC 30 октября.

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

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

Второй инцидент произошел 5 декабря и затронул часть клиентов, на которую приходилось примерно 28% всего HTTP-трафика, обслуживаемого Cloudflare. Он был вызван изменениями в логике парсинга тела запроса, которые вносились при попытке обнаружить и нейтрализовать новую, общеотраслевую уязвимость в React Server Components. Подробный разбор в посте блога содержит дополнительную информацию, включая анализ корневой причины и хронологию.

Чтобы узнать больше о работе, ведущейся в Cloudflare для предотвращения подобных сбоев в будущем, ознакомьтесь с нашим постом в блоге, где подробно описана инициатива «Code Orange: Fail Small».

Нарушения работы, наблюдавшееся в четвертом квартале, подчеркивают важность данных в реальном времени для поддержания глобальной связности. Будь то отключение по распоряжению правительства или незначительная техническая проблема, прозрачность позволяет техническому сообществу реагировать быстрее и эффективнее. Мы продолжим отслеживать эти изменения на Cloudflare Radar, предоставляя информацию, необходимую для навигации в сложностях современного сетевого взаимодействия. Мы делимся своими наблюдениями в Центре отслеживания сбоев Cloudflare Radar, через социальные сети и в публикациях на blog.cloudflare.com. Подписывайтесь на нас в социальных сетях: @CloudflareRadar (X), noc.social/@cloudflareradar (Mastodon) и radar.cloudflare.com (Bluesky), или свяжитесь с нами по электронной почте.