Zapret Wiki

Недавно обновлено

время чтения ~25 мин.

.md

🦎 ТТК и YouTube: кэши Google (GGC) в сети Транстелекома отвечают, но видео встаёт (с 17 октября 2026)

О чём заметка

С утра 17 октября 2026 года абоненты ТТК (Транстелеком) в разных регионах пишут, что сайт YouTube открывается, а видео застывает на 144p или не стартует, и никакая стратегия Zapret не помогает. Заметка собирает хронику, скриншоты и записи трафика участников, собственные замеры от 20 октября 2026 года, разбор того, на каком уровне ломается передача и кто может быть причиной, и конкретные шаги в Zapret. Причина не установлена, и ни ТТК, ни Google, ни Роскомнадзор в найденных материалах её не объясняли. Подробности вынесены в две заметки: как устроены кэши Google и что показали прямые замеры и разбор записей трафика.

TL;DR

  • С 17 октября 2026 года видео YouTube у части абонентов ТТК грузится рывками: первые секунды идут, потом плеер застывает, в консоли браузера появляются NS_BINDING_ABORTED и ERR_CONNECTION_RESET. Сообщения идут из Хабаровска, Якутска, Иркутска, Красноярска, Республики Коми, Ростовской области, Тюмени и других мест.
  • Видео отдают кэши Google внутри сети ТТК: адреса 188.43.x.x по базе RIPE записаны как GOOGLE-TTK-NET, а имена узлов из обсуждения превращаются в адреса именно из этих блоков. С хостинга в Москве все четыре проверенных узла принимают соединение и завершают TLS-рукопожатие при любом имени в запросе (28 проб из 28). Узлы как серверы живы и к имени googlevideo не придираются.
  • Записи трафика к медленному узлу показывают, что на запросы, ответ на которые у узла уже есть, он отвечает за 7–42 мс, но один запрос из восьми прождал первого байта 2,9 секунды, после чего данные шли порциями по 0,5–1,6 Мбит/с. Это не похоже на ограничитель скорости на соединении: в соседнем соединении пять запросов подряд получили быстрый ответ.
  • Кто и на каком уровне: рукопожатие у абонентов проходит только с обходом, а передача ломается независимо от него. Фильтр по имени в запросе возможен на пути абонента, но не доказан, блокировка по IP касается в лучшем случае части адресов, DNS к этому сбою не относится. Кто виноват, замеры не показывают.
  • Zapret не может ускорить сам узел. Он может убрать собственные издержки (в записях обход добавляет около полусекунды к каждому новому соединению), закрыть QUIC для адресов кэшей ТТК и проверить, нужен ли обход для них вообще. Конкретные профили — в разделе «Что сделать в Zapret».

Что произошло: хроника 17–20 октября

Первые жалобы относятся к утру 17 октября 2026 года. Один из участников обсуждения написал, что сайт YouTube работает, а ломается именно загрузка с googlevideo, и что началось примерно с шести утра по Москве. Тема об этом появилась в репозитории Flowseal в 07:55 МСК, это Issue № 18162 «Ютуб сильно заболел», адрес у неё такой: https://github.com/Flowseal/zapret-discord-youtube/issues/18162 — к нему же относятся все ссылки на комментарии ниже. Первое сообщение именно от абонента ТТК пришло в 10:05 МСК из Хабаровска, его адрес https://github.com/Flowseal/zapret-discord-youtube/issues/18162#issuecomment-6231013029 — и в нём автор отметил, что стратегии, которые подсказывает диагностика, не помогают, а Discord на этом фоне работает.

Параллельно тема разрасталась. Модераторы репозитория пометили как дубликаты этой темы 24 других обращения (по журналу самой темы, номера от 18164 до 18232). На 20 октября 2026 года, 13:33 МСК, в теме 230 комментариев от 79 авторов, в 38 комментариях от 27 авторов упоминается ТТК. Расчёт по выгрузке комментариев через API GitHub дал 108, 46, 46 и 30 комментариев за четыре московских суток, и последняя цифра взята до середины дня.

Регионы, которые называют сами авторы сообщений про ТТК: Хабаровск и Дальний Восток, Якутск, Иркутск, Красноярск, Республика Коми, Тюмень, Ростовская область. Это самоотчёты: проверить, что провайдер у каждого именно ТТК, нельзя. Участники по-разному определяют это сами, например, по адресам узлов или по странице report_mapping, о которой подробно в заметке про устройство GGC.

Картина не сводится к одному провайдеру. В той же теме пишут о похожих сбоях при подключении через Дом.ру в Новосибирске, через Билайн, через небольших местных провайдеров, через «МегаФон» в Москве и «Планету» с МТС в Свердловской области. Часть участников возражает, что это другие проблемы, а один из них оценил долю ТТК в жалобах примерно в 90%. Аналитический сайт Detector404 в материале от 20 октября 2026 года сообщает о росте жалоб на YouTube и приводит доли по регионам (Красноярский край 8%, Новосибирская область 6%, Свердловская область 5%, Ханты-Мансийский округ 5%, Краснодарский край 4%), но провайдеров в нём не разбирает. Поэтому ответ на вопрос «только ТТК или не только» открыт: достоверно описан сбой у ТТК, у остальных он остаётся слухом из комментариев.

Чьи это узлы и что показывают скриншоты

Видеофрагменты приходят не с youtube.com, а с адресов вида rr1---sn-ug5onuxaxjvh-v8cz.googlevideo.com. Это серверы-кэши Google, которые стоят внутри сети провайдера и отдают популярные ролики абонентам по короткому пути (Google Global Cache, GGC). Как плеер выбирает такой узел и как его читать по имени, разобрано в заметке Кэши Google (GGC) у провайдера. Здесь важно, чьи это адреса. Каждая сеть оператора в интернете записана под своим номером автономной системы (AS). Адреса 188.43.65.140, 188.43.67.12 и 188.43.61.141, которые называют участники, по базе RIPE входят в блоки 188.43.64.0/23, 188.43.66.0/23 и 188.43.61.0/24 с названием сети GOOGLE-TTK-NET и описанием GOOGLE-SERVERS, а анонсирует их AS20485, TransTeleCom. Слово «Moscow» в описании — адрес организации, а не доказательство, что узел стоит в Москве. Имена узлов, о которых пишут участники, тоже ведут в эти блоки: rr1---sn-ug5onuxaxjvh-v8cz превращается в 188.43.65.140, rr1---sn-ug5onuxaxjvh-n8v6 в 188.43.61.140, rr1---sn-ug5onuxaxjvh-gv8e в 188.43.67.140 (таблица имён и адресов — в заметке про GGC). Быстрый адрес 188.170.166.77, на который жаловавшийся ссылается как на «хороший», принадлежит диапазону «МегаФона» (AS31133). Как именно абонент из Красноярска получал оттуда видео, из открытых данных не следует.

Две оговорки по номерам автономных систем. В одном из комментариев упомянута AS15774: по RIPEstat её держит отдельная организация «TTK-RTL» (ООО «ТТК-Связь»). В рецепте блокировки на роутере указана AS17337, но RIPEstat относит её к другому владельцу (Scuffle), поэтому подсети оттуда копировать нельзя. Все подсети перед блокировкой стоит проверять самому, как показано в заметке Как определить владельца домена или IP.

Автор темы на форуме ntc.party выложил два скриншота панели «Сеть» из браузера Firefox, снятые 17 октября с разницей в 13 секунд (17:49:50 и 17:50:03 по красноярскому времени). На первом видео идёт с узла ТТК 188.43.65.140: страница из 220 запросов передала 3,23 МБ за 1 минуту 25 секунд, качество упало до 360p. Выбранный запрос POST …/videoplayback к rr1---sn-ug5onuxaxjvh-v8cz.googlevideo.com вернул 432 КБ. Картинки и шрифты в этой же странице пришли с адресов Google 192.178.183.x и загрузились, то есть собственная связь абонента с Google в целом работает, а замедление приходится на узел ТТК.

На втором скриншоте, снятом на 13 секунд позже, то же самое видео идёт с адреса 188.170.166.77 (диапазон «МегаФона»): запрос POST …/videoplayback к rr2---sn-hxb54vo-v8cs.googlevideo.com вернул 62,8 МБ за 1 минуту 15 секунд, а страница из 23 запросов передала 286,2 МБ за 1,5 минуты. В «Статистике для сисадминов» видны 3840x2160@60 и скорость соединения 89 783 Кбит/с при буфере 7,38 секунды. В правой панели заголовков скриншота мы закрасили фрагмент с адресом абонента.

Расчёт по этим цифрам даёт около 0,31 Мбит/с против 25,4 Мбит/с. Ролики и качество на кадрах разные, а в 3,23 МБ входят и картинки со шрифтами, поэтому разницу в 80 раз стоит понимать как порядок величин, а не как замер.

Для сравнения: в той же теме участники проверяли тестовый ролик, который предложили для проверки узла. Две приложенные картинки показывают, что в тот же вечер у других зрителей, чей провайдер на кадре не виден, видео шло быстро. На первой статистика плеера от 19 октября, 22:30 МСК: качество 1280x720@50, скорость соединения 63 491 Кбит/с и запас буфера 47,6 секунды, потеряно 0 кадров из 5 310.

На второй показан Chrome с открытыми инструментами разработчика от 19 октября, 23:02 МСК: качество 2160p50, скорость 47 155 Кбит/с, буфер только 4,5 секунды, все запросы videoplayback идут по протоколу h3 (то есть по QUIC) и занимают 0,5–1,8 секунды при размере 0,9–2,1 МБ, то есть 8–20 Мбит/с на запрос. Один запрос id отменён через 5,02 секунды. Эти кадры показывают, что тот же ролик у части зрителей проигрывается без проблем, а у части нет: сбой избирателен.

Ещё две картинки участник приложил, чтобы показать, как выглядят неудачные и удачные запросы в одном браузере. На первой три подряд запроса videoplayback к узлам rr2---sn-ug5onuxaxjvh-n8v6 и rr3---sn-ug5onuxaxjvh-p5ge завершаются как NS_BINDING_ABORTED за 8–30 мс с размером 0 байт: браузер отменяет запрос почти сразу, как только он ушёл (адрес клиента участник закрасил).

На второй запрос к rr2---sn-ug5onuxaxjvh-p5ge из той же группы узлов проходит нормально: код 200, 6,81 МБ за 590 мс, то есть около 92 Мбит/с. Значит, внутри одного и того же кластера часть запросов отменяется за десятки миллисекунд, а часть выдаёт скорость почти 100 Мбит/с.

Что показали записи трафика и прямые замеры

Подробный разбор четырёх записей трафика (pcap), которые выложили на форуме, с логами пакетов, диаграммами и скриптом для проверки своей записи вынесен в заметку Как читать pcap видеосоединения с узлом googlevideo. Главное из неё. Рукопожатие SYN → SYN-ACK занимает 5–6 мс, то есть узел отвечает сразу. Из восьми запросов видеофрагментов семь получили первый ответ за 7–42 мс, а один, отправленный на 32-й секунде записи 63, ждал 2,86 секунды при том, что TCP-подтверждения пришли за 5 мс; после паузы данные шли порциями раз в секунду со скоростью 0,5–1,6 Мбит/с. Повторно узел отправил от 5 до 21% байтов, причём больше всего в быстрых всплесках. Огромные номера Seq вроде 4294957297 в начале соединения принадлежат поддельным пакетам самого обхода (badseq, смещение −10 000), а не узлу. В трёх записях соединение закрыл клиент (FIN), а узел ответил RST через 4–7 мс: это не обрыв со стороны узла.

Чтобы отделить поведение самих узлов от поведения сетей абонентов, четыре адреса GOOGLE-TTK-NET проверены 20 октября 2026 года прямым подключением с хостинга в Москве (AS207957), без прокси и туннелей. TCP-соединение с ними устанавливается за 2,1, 19, 41 и 99 мс, TLS-рукопожатие проходит при всех семи проверенных именах (rr1---sn-ug5onuxaxjvh-n8v6.googlevideo.com, googlevideo.com, www.youtube.com, www.google.com, ya.ru и других) с сертификатом *.googlevideo.com, а на чужой запрос узел сразу отвечает кодом 400. Подробности — в разделе про замеры в заметке про устройство GGC. Эти замеры сделаны из одной точки вне сети ТТК и ничего не говорят о том, что видят абоненты ТТК, но позволяют исключить два объяснения: «узел мёртв» и «узел сам отказывается от имени googlevideo».

На каком уровне и кто: что можно утверждать, а что нет

Путь видеозапроса состоит из нескольких шагов: страница выбирает узел, DNS превращает имя в адрес, браузер соединяется по TCP, договаривается о шифровании (TLS), затем идёт передача данных. Первое сообщение рукопожатия, ClientHello, содержит открытым текстом имя сайта (SNI), и по этому имени оборудование фильтрации может узнать, куда идёт запрос. Участники обсуждений находят обрыв на разных шагах, и чтобы их не путать, сведём всё в одну таблицу с указанием, чем подтверждён каждый шаг.

DNS. К этому сбою он не относится: адреса узлов у абонентов определяются (в DevTools видны 188.43.x.x), соединения с ними идут. Но у части абонентов есть отдельная проблема с подменой DNS (см. раздел ниже), которую легко принять за сбой узлов.

IP-адрес. О блокировке по адресу есть одно сообщение: участник форума с ником Xunlei пишет, что часть адресов узлов не отвечает на SYN, хотя те же адреса доступны с российского VPS, а соседние адреса с одинаковым суффиксом в имени могут отвечать. Наши замеры из Москвы такую картину не воспроизводят: все четыре проверенных адреса отвечают. Это не опровергает сообщение (адреса и точки наблюдения разные), но и не подтверждает его. У автора записей нужный адрес отвечает за 5 мс, и для него блок по IP не действует. Поэтому блокировка по IP-адресу в лучшем случае затрагивает часть адресов, и общей причиной сбоя её назвать нельзя.

Имя в запросе (SNI). Здесь стоит рассуждать аккуратнее. Узел одинаково принимает любое имя: из Москвы он завершает рукопожатие и с googlevideo.com, и с ya.ru, и с example.org. Значит, если у абонента зависание зависит от имени в запросе, причина лежит не в узле, а в чём-то на пути. Контрольный замер из-за рубежа (сервер в Нидерландах) эту мысль подтверждает прямо: на приветствие с именем …googlevideo.com, написанным строчными буквами, те же узлы и ряд других российских адресов молчат, а с заглавными буквами в COM, с googlevideo.net или ya.ru рукопожатие проходит; разрез приветствия на части не помогает, HTTP на порту 80 отвечает всегда. Подробности и таблица — в заметке про устройство GGC. Это фильтр по имени на пути из-за рубежа, чувствительный к регистру; видят ли его абоненты внутри сети ТТК, этот замер не показывает. Более того, сервер собирает TCP-поток целиком: ему безразлично, пришёл ClientHello одним пакетом или кусками, а поддельные пакеты с неверным номером он отбрасывает. Поэтому всё, что в этом месте меняют обходом (куски, поддельные пакеты), меняет поведение не сервера, а промежуточного устройства. Это самое сильное звено: то, что Zapret вообще помогал абонентам ТТК до 17 октября и в записях рукопожатие проходит, указывает на устройство на пути, которое разбирает ClientHello. Прямое подтверждение пока слабое: участник темы Flowseal привёл таблицу, по которой рукопожатие с 188.43.65.12 и именем rr…googlevideo.com висит без обхода (0 из 4) и проходит с обходом (3 из 3), а с www.google.com и ya.ru проходит всегда; он сам указал, что анализ вёл вместе с ИИ-моделью. Надёжный способ проверить самому описан в разделе про Zapret ниже.

Передача данных. Это место, где ломается по записям трафика, и ни SNI, ни IP тут не при чём: соединение к этому моменту установлено. Доводов против версии «ограничитель скорости, привязанный к соединению» два. В записи 64 пять запросов подряд на одном соединении получили ответ за 8–12 мс и 6,5 МБ за 12 секунд, то есть ограничителя на этом соединении не было. В записи 63 на том же соединении один запрос прождал 2,86 секунды, но остальные до него получили быстрый ответ. Ограничитель на соединении так бы не сработал, а различие между запросами внутри одного соединения лучше объясняется самим запросом: какой-то ролик есть на узле, а какого-то нет, и тогда узлу приходится ждать данные (вывод по косвенным признакам, а не наблюдение).

Кто. Прямых доказательств ни о виновном, ни о намерении нет. Рассмотрим, что можно сказать по логике. По скорости и паузам на передаче данных причина лежит на стороне узла или канала от него к Google, и здесь кандидатов три: сам Google (раздача, перенос нагрузки, вывод оборудования), ТТК как владелец сети между узлом и Google, и устройства фильтрации, управляемые централизованно (ТСПУ). Что касается имени в запросе, если оно действует, то это класс устройств фильтрации по ClientHello, и оно может быть отдельной проблемой, которую обход решает, а нехватка данных на узле остаётся. Об общей причине говорит одновременность: сбой начался в одно утро в десятках городов, и независимый отказ узлов в этих городах менее вероятен, чем централизованное изменение настроек (фильтрации, раздачи или сети). Это вывод по косвенным признакам. Решающие проверки такие: те же запросы из сети ТТК и вне её, запись без обхода и запись роликов, заведомо лежащих и заведомо отсутствующих в кэше.

Версии причины

Версии, которые звучат в обсуждениях, сведены в таблицу. Два столбца важны одинаково: что за версию говорит и что против.

ВерсияЧто говорит заЧто говорит против
Узлы износились или перегруженыВ июле 2024 года «Ростелеком» объяснял замедление «проблем с эксплуатацией серверов GGC» и перегрузкой мощностейСбой начался в одно утро и в разных регионах, а узлы отвечают на соединение и рукопожатие; независимый износ в десятках городов сразу маловероятен (это вывод, а не факт)
Кэш не может наполнитьсяУчастник темы Flowseal пишет, что при отсутствии ролика в кэше узел либо не получает его у Google, либо отдаёт на скорости 30–50 КБ/с (видно на прямой трансляции командой yt-dlp -vo - >/dev/null); в записях запрос с паузой 2,86 с и порциями раз в секундуЕдиничные наблюдения, механизм неизвестен, на узле «нет ролика» нельзя проверить без доступа к нему
Фильтрация узлов (ТСПУ)Часть адресов не отвечает на SYN при доступности с VPS, обход помогает пройти рукопожатие, тест с ClientHelloТест участника с ИИ-помощью на четырёх пробах; из Москвы все рукопожатия проходят; ограничитель на соединении не виден
Нехватка международных каналовУчастник форума связал сбой с договорённостью операторов не расширять каналыНи одно доказательство не опубликовано (см. ниже)

В апреле 2026 года, как сообщили «Важные истории» со ссылкой на РБК, около 20 владельцев каналов между Россией и Европой, в том числе «Транстелеком», договорились не расширять их. Источники РБК анонимны, а официального подтверждения нет: оригинал на сайте РБК от 16 апреля 2026 года, адрес которого https://www.rbc.ru/technology_and_media/16/04/2026/69dfc3f49a79474578e12a10 — при проверке отдал защиту от ботов, и о его содержании известно только в пересказе. Связь этого решения со сбоем кэшей остаётся догадкой одного комментатора.

Участник из Республики Коми отдельно выяснил, что плеер сначала пробует QUIC (HTTP/3 поверх UDP), а при неудаче через несколько секунд откатывается на TCP, и адресов кэшей ТТК нет в списках Zapret, поэтому QUIC к ним вообще не обрабатывается. Когда он закрыл UDP 443 к этим узлам, видео пошло по TCP с обходом в HD, но периодические зависания на 5–13 секунд остались. Он же оговорил, что подсети /24 он подобрал по соседству с найденными адресами, то есть это предположение.

Отдельная беда: подмена DNS, которую принимают за сбой узлов

Часть жалоб в той же теме описывает другое: страница YouTube вовсе не открывается или открывается с ошибкой DNS_PROBE_FINISHED_NXDOMAIN. Один из абонентов приложил вывод nslookup youtube.com к 8.8.8.8, 8.8.4.4 и 1.1.1.1: все три сервера ответили, что домена не существует (Non-existent domain), хотя настоящие серверы такого ответа дать не могли. Странные символы на месте слова «Сервер» в выводе — следствие кодировки консоли, а имя пользователя Windows мы закрасили.

Другой участник прогнал проверку более чем полусотни публичных резолверов. Таблица показывает для каждого DNS-сервера скорость ответа через шифрованные каналы DoH и DoT, по обычному UDP, адрес «реального» резолвера, который ответил на запрос по UDP, и долю проб, где ответ подменён. Ответы 8.8.8.8, 8.8.4.4, 1.1.1.1, 1.0.0.1 и OpenDNS по UDP приходят от резолверов RIPN (подмена в 5 пробах из 5), а Quad9, AdGuard (кроме одной пробы из пяти), Яндекс и ряд других отвечают сами. При этом шифрованные запросы к Google и Cloudflare проходят (DoH 26 и 17–26 мс), поэтому один из участников советует DoH: подмена по пути его не затрагивает.

Это перехват, который разобран в других заметках, и к кэшам Google он отношения не имеет: механизм описан в заметке Перехват DNS на ТСПУ, а причину пустых ответов по youtube.com объясняет заметка об исключении доменов из ответов НСДИ. Практическое следствие: абоненту с перехватом сначала приходится чинить DNS (шифрованный DNS не через Google и Cloudflare, как советуют в теме, или резолвер вне перехвата), и только потом оценивать, виноваты ли узлы.

Диагностика самого Zapret при этом может показывать всё зелёным. На скриншоте участника из Новосибирска режим general (ALT11) прошёл все проверки: HTTP, TLS 1.2 и TLS 1.3 для Discord, YouTube (включая YouTubeVideoRedirect), Google и Cloudflare с пингами 58–129 мс, но видео не работало.

По названиям строк видно, что проверяются рукопожатия, а не скорость узла, поэтому зелёный отчёт не доказывает, что видео пойдёт.

Что сделать в Zapret

Сначала границы. Zapret вмешивается в первые пакеты соединения на стороне клиента: режет ClientHello и первый запрос, добавляет поддельные пакеты. Он не ускоряет узел, не меняет, какой узел выдаст YouTube, и не лечит паузу в 2,9 секунды: она возникает после того, как рукопожатие и запрос уже прошли. Поэтому честный ответ на вопрос «как починить через Zapret» складывается из трёх задач: убрать то, что обход делает сам с собой, закрыть то, чего он не покрывает (QUIC), и проверить, нужен ли обход для этих адресов вообще. Всё ниже построено на записях трафика этой заметки и документации, но на самом ТТК не проверено (замеры сделаны из сети вне ТТК): это порядок экспериментов, а не готовый рецепт.

Шаг 0. Список адресов кэшей ТТК. По базе RIPE внутри 188.43.0.0/16 у GOOGLE-TTK-NET семь блоков. Весь /16 брать нельзя: в нём живут и другие клиенты ТТК, и кэши других компаний (например, AKAMAI-FB-TTK-NET).

188.43.61.0/24
188.43.64.0/23
188.43.66.0/23
188.43.68.0/23
188.43.87.0/24
188.43.126.0/24
188.43.127.0/24

Список получен запросом к базе RIPE по всем вложенным блокам 188.43.0.0/16 20 октября 2026 года и отфильтрован по названию сети. Четыре блока (188.43.61.0/24, 188.43.64.0/23, 188.43.66.0/23, 188.43.68.0/23) подтверждены ещё и именами узлов из обсуждения: DNS с московского хостинга превращает эти имена в адреса именно из них. Для 188.43.87.0/24, 188.43.126.0/24 и 188.43.127.0/24 по реестру тоже указаны серверы Google, но имён узлов оттуда в обсуждениях нет, и работают ли там кэши, не проверено: проверка из сети ТТК недоступна, а перебор адресов чужой сети ради этого не оправдан. Кэши ТТК могут стоять и в других диапазонах, поэтому сверяйте список с «Удалённым IP» в DevTools. Сохраните список в файл, например ipset-ttk-ggc.txt в папке списков.

Шаг 1. Закрыть QUIC к этим адресам. Плеер пробует QUIC первым, ждёт ответ несколько секунд и откатывается на TCP, а потом снова возвращается к QUIC. Адресов ТТК нет в списках Zapret, поэтому правила для UDP на них не срабатывают, и каждая попытка стоит секунд. В Zapret 2 для этого есть действие drop (отбросить пакет): профиль ставится выше общих UDP-профилей, потому что профили проверяются сверху вниз и побеждает первый совпавший (порядок профилей).

--filter-udp=443 --filter-l7=quic --ipset=lists/ipset-ttk-ggc.txt --lua-desync=drop

В winws из сборки Flowseal (zapret1) отбрасывать пакеты нечем, поэтому закрывать приходится брандмауэром Windows. Правило из сообщения участника из Республики Коми с исправленным списком подсетей выглядит так (в командной строке от администратора):

netsh advfirewall firewall add rule name="Block QUIC to TTK GGC" dir=out action=block protocol=UDP remoteport=443 remoteip=188.43.61.0/24,188.43.64.0/23,188.43.66.0/23,188.43.68.0/23,188.43.87.0/24,188.43.126.0/24,188.43.127.0/24
netsh advfirewall firewall delete rule name="Block QUIC to TTK GGC"

Вторая строка откатывает правило. Ожидаемый результат: видео сразу идёт по TCP, без пауз на откат; участник из Республики Коми получил HD по HTTP/1.1, но зависания на 5–13 секунд остались, и это уже передача, а не QUIC. Отдельно от этого можно отключить QUIC в самом браузере (флаг chrome://flags/#enable-quic или политика), но тогда он отключится для всех сайтов.

Шаг 2. Выяснить, нужен ли обход для кэшей ТТК. Это самый информативный опыт. Записи показывают, что обход добавляет в начале соединения поддельные пакеты и режет не только ClientHello, но и первый запрос: рукопожатие занимает 0,26–0,6 секунды вместо примерно 15 мс при пинге 5 мс, а запрос в 3,6 КБ доходит до узла только к 0,59 с. Если для адресов кэшей ТТК обход не нужен, это чистая потеря. Проверяется в два захода.

Вариант А: исключить адреса кэшей из обработки. В Zapret 2 это профиль без действий выше общих:

--filter-tcp=443 --ipset=lists/ipset-ttk-ggc.txt --new

В winws то же делает профиль без --dpi-desync, либо добавление списка в --ipset-exclude общих профилей. Выключите Zapret для этих адресов, откройте ролик и посмотрите, проходит ли рукопожатие. Для объективности выполните без обхода команды (подставьте адрес из DevTools):

openssl s_client -connect 188.43.65.140:443 -servername rr1---sn-ug5onuxaxjvh-n8v6.googlevideo.com
openssl s_client -connect 188.43.65.140:443 -servername ya.ru

Читать результат так. Висит только первая команда: фильтр срабатывает на имя googlevideo в ClientHello, и обход нужен, переходите к варианту Б. Висят обе: проблема не в имени, а в пути или адресе, и обход не поможет. Обе проходят, а видео всё равно встаёт: обход не нужен, оставляйте исключение, а проблема лежит в передаче и лечится только сменой узла (шаг 4).

Вариант Б: оставить обход только на ClientHello и без лишнего. В Zapret 2:

--filter-tcp=443 --ipset=lists/ipset-ttk-ggc.txt --out-range=-d2 --payload=tls_client_hello --lua-desync=multisplit:pos=1,midsld

Здесь —out-range=-d2 ограничивает обработку первыми двумя data-пакетами соединения (один ClientHello Chrome с постквантовым ключом занимает два сегмента), --payload=tls_client_hello оставляет только его, а multisplit:pos=1,midsld режет его после первого байта и посередине домена второго уровня, без поддельных пакетов. В winws аналог: --filter-tcp=443 --ipset="%LISTS%ipset-ttk-ggc.txt" --dpi-desync=multisplit --dpi-desync-split-pos=1,midsld --dpi-desync-cutoff=d2. Ожидаемый результат по записи: список «поддельные пакеты клиента» в выводе скрипта пуст, первое соединение завершает рукопожатие за десятки миллисекунд.

Шаг 3. Замерить, а не угадывать. Для каждого варианта снимите запись трафика (Wireshark на роутере или tcpdump), прогоните скриптом из заметки про разбор pcap и сравните три числа: время от SYN-ACK до первых данных, задержку первых данных после запроса и долю повторных передач. Роликов нужно минимум три: популярный, старый и малоизвестный, плюс прямая трансляция. Если число повторных передач и пауз после запросов не меняется между вариантами, значит, дело в узле, и дальнейшая возня со стратегиями бесполезна. Это важный вывод: записи, снятые автором, показывают, что при его текущей стратегии рукопожатие проходит, поэтому перебор вариантов TCP-стратегий (hostfakesplit с host=www.google.com, multisplit со seqovl=681 и другие, которые советуют в теме) не затронет то, что ломается после рукопожатия.

Шаг 4. Что Zapret не исправит, и как это обходят. Пауза в 2,9 секунды и скорость около 1 Мбит/с остаются при любом наборе правил: они возникают на узле или за ним. Единственный надёжный приём, о котором пишут участники, — не ходить на этот узел. Плеер получает узлы от www.youtube.com по IP клиента, поэтому для смены набора узлов пропускают через прокси или VPN другого региона запросы к *.youtube.com и youtu.be, оставляя остальное напрямую. Результат проверяют в DevTools: «Удалённый IP» запросов videoplayback больше не должен начинаться с 188.43.. Один из участников написал, что у него менялся только значок страны, поэтому приём работает не у всех. Zapret остаётся для всего прочего трафика.

Что не стоит делать

Блокировать узел по части имени в uBlock: по сообщениям, плеер выбирает другие узлы из той же группы и в итоге получает ошибки. Копировать подсети из чужих рецептов без проверки владельца (см. оговорку про AS17337 выше). Выбирать стратегию по зелёному отчёту диагностики, который не проверяет скорость. Верить, что одна найденная стратегия решит проблему всем: на скриншотах и в записях сбой избирателен.

Что делают пользователи и что из этого помогает

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

ПриёмКак он работаетЧто пишут
Увести плеер на другой регионПропустить *.youtube.com и youtu.be через прокси или VPN другого региона, чтобы плеер получил узлы не из ТТКЧасть участников называет это самым надёжным способом, один пишет, что у него менялся только значок страны
Заставить *.googlevideo.com идти в проксиПравило в расширении вроде ZeroOmega: для адресов, которые не отвечают на SYN, использовать прокси или VPSУчастник Xunlei держит отдельный профиль, в нём 16 правил на недоступные узлы
Подставить рабочий IP в hostsПривязать имя «битого» узла к адресу рабочего: браузер проверяет сертификат по имени, а не по IPСовет участника, подтверждения нет; имена узлов меняются, надолго не хватает
Закрыть QUIC к узлам ТТКБлокировка UDP 443 к их подсетям в брандмауэре или на роутере, плеер уходит на TCP, где работает ZapretПомогло нескольким, зависания остаются, а QUIC быстрее на тяжёлом видео
Блокировать «плохой» узел в uBlockФильтр на часть имени узлаПлеер выбирает другой узел из той же группы, в одном случае после половины видео ошибки пошли с двух других узлов
Прокси, VPN, WARPВесь трафик или только YouTube идёт мимо кэша ТТКРаботает у большинства, но один участник пишет о заметном падении скорости WARP
Подбор стратегий ZapretМенять list-google и тип desyncУ абонентов ТТК почти не помогает; у других провайдеров помогало обновление до версии 1.10.4 с режимом EXP и сброс сетевого стека

Как проверить свой случай

  • Открыть вкладку «Сеть» в инструментах разработчика (F12), поставить фильтр videoplayback и посмотреть «Удалённый IP»: адрес 188.43.x.x указывает на узел ТТК.
  • Открыть страницу https://redirector.gvt1.com/report_mapping?di=no — по рассказам участников, она показывает, какой кластер обслуживает вас (например, внутри сети ТТК).
  • Посмотреть статус запросов videoplayback к узлам rrN---sn-…: NS_BINDING_ABORTED и ERR_CONNECTION_RESET у нескольких запросов подряд характерны для этого сбоя, а запросы со статусом 200 и размером в мегабайты говорят, что часть запросов проходит.
  • Включить «Статистику для сисадминов» (Stats for nerds, правая кнопка по плееру) и сравнить Connection Speed с Buffer Health: при проблеме буфер остаётся в секундах, а скорость падает почти до нуля.
  • Проверить другой ролик, лучше свежий и малопопулярный: если популярные идут, а редкие встают, это похоже на проблему кэша.
  • Проверить в чистой вкладке без cookies: YouTube мог запомнить конкретный узел.
  • Проверить DNS командой nslookup youtube.com 8.8.8.8: ответ Non-existent domain означает подмену DNS, и это отдельная проблема.

Что пока неизвестно

Нет официальных заявлений ТТК, Google и Роскомнадзора (в материалах, которые удалось найти к 20 октября 2026 года). Не опубликованы запись трафика здорового узла и запись того же узла без Zapret, а они позволили бы отделить поломку узла от действия обхода. Не проверено, одинаково ли выглядит сбой у других провайдеров. Неизвестно, почему он начался именно 17 октября и закончится ли сам: отдельные пользователи сообщали, что видео вернулось без изменения настроек, но у большинства абонентов ТТК, судя по теме, ничего не изменилось. Шаги из раздела про Zapret на самом ТТК не проверены: их результат подтвердит или опровергнет версию о фильтрации по ClientHello.

Все данные из пользовательских сообщений

Сообщения форума и репозитория написаны самими пострадавшими, их ответы не проверены независимо. Скриншоты и записи трафика взяты из тем участников, фрагменты с личными данными (адрес в строке запроса, имя пользователя Windows) закрашены. Записи трафика проверены нами по данным файлов, а цифры из скриншотов пересчитаны по подписям. Сообщения форума ntc.party цитируются по копии текста темы: с сервера, на котором собирается вики, форум недоступен, поэтому прямой ссылки на тему нет. Прямые замеры сделаны с одного хостинга в Москве 20 октября 2026 года, то есть не из сети ТТК, и относятся только к узлам.

Источники

📚 См. также

🤖 Эти статьи открыты — можно обучать на них ИИ

При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование доступно в Forgejo: исходник этой заметки · скачать весь репозиторий одним zip-архивом.

Вид графа

Обратные ссылки