🦎 Кэши Google (GGC) у провайдера: как YouTube выбирает узел googlevideo.com и что показали прямые замеры

О чём заметка

Основа для разбора сбоев вроде истории с ТТК в октябре 2026 года: что такое кэш Google внутри сети провайдера, как плеер YouTube попадает именно на него, что значит имя rr1---sn-…, как это проверить самому и что отвечают такие узлы на прямые подключения со стороны. Раздел с замерами содержит собственные измерения от 20 октября 2026 года.

TL;DR

• Видео YouTube приходит не с youtube.com, а с адресов *.googlevideo.com. Для популярных роликов Google ставит собственные серверы-кэши прямо в сетях провайдеров: это Google Global Cache (GGC).
• Какой узел достанется, решает страница воспроизведения по IP клиента, поэтому прокси или VPN для *.youtube.com меняют набор узлов, а правила для *.googlevideo.com часто не нужны.
• Четыре адреса из блока GOOGLE-TTK-NET с хостинга в Москве дали одинаковую картину: TCP-соединение за 2–99 мс, TLS-рукопожатие с сертификатом *.googlevideo.com при любом имени в запросе (28 проб из 28), на чужой запрос быстрый ответ HTTP 400; имена узлов из обсуждения превращаются в адреса именно этих блоков. Узлы как серверы живы и не придираются к имени.
• Из-за рубежа картина другая: на приветствие с именем …googlevideo.com, написанным строчными буквами, те же узлы молчат (и ряд других российских адресов тоже), а HTTP на порту 80 отвечает всегда. Заглавные буквы в имени рукопожатие пропускают. Разрез приветствия не помогает.
• Значит, зависание, о котором пишут абоненты, возникает на пути до узла или в передаче данных, а не потому, что узел «мёртв».

Что такое кэш Google у провайдера

Пока абонент смотрит ролик, его данные могут идти из дата-центра Google за границей, а могут из небольшого сервера, который Google поставил в сеть самого провайдера. Второй путь короче и дешевле для обеих сторон: провайдер не гоняет популярный ролик через международные каналы каждый раз, а Google экономит на внешнем трафике. Такой сервер и называется Google Global Cache (GGC, кэш-сервер Google у оператора). Он хранит то, что чаще всего смотрят абоненты этого провайдера. Если нужного ролика на нём нет, сервер сам докачивает его у Google и отдаёт абоненту: для абонента это выглядит как короткая задержка перед началом фрагмента.

Проще говоря: хорошо работающий кэш быстро отдаёт то, что у него лежит, и быстро докачивает остальное. Когда докачка сломана, популярное по-прежнему идёт быстро, а редкое и новое встаёт. Именно такую картину описывают участники обсуждения ТТК.

Как читать имя узла

Адрес вида rr1---sn-ug5onuxaxjvh-n8v6.googlevideo.com состоит из трёх частей. Префикс rr1 отражает номер: у одного кластера несколько узлов (rr1, rr2, …). Часть sn-… служит идентификатором кластера, а последний фрагмент после дефиса, судя по всему, различает отдельные машины. Значение этих кусков Google не публикует. Участники обсуждения по общему фрагменту uxaxjvh предполагали, что такие узлы стоят в России, и это остаётся гипотезой.

Имя нельзя считать надёжным признаком принадлежности оператору: что за сеть стоит за адресом, надёжнее проверить по базе RIPE. Например, адреса из обсуждения ТТК 188.43.65.140, 188.43.67.12 и 188.43.61.141 записаны в RIPE как GOOGLE-TTK-NET с описанием GOOGLE-SERVERS и анонсируются из AS20485 (TransTeleCom). Как узнать владельца любого адреса, разобрано в заметке Как определить владельца домена или IP.

Как YouTube выбирает узел

Самое важное, что стоит понять: выбор делается заранее и не на уровне DNS. По описаниям участников форума ntc.party, браузер при открытии ролика запрашивает у www.youtube.com данные для воспроизведения, и в ответе Google перечисляет узлы googlevideo.com, подобранные по IP-адресу, с которого пришёл запрос. Телевизоры и мобильные клиенты, по тем же сообщениям, берут список ещё у redirector.googlevideo.com, а возможно, и у manifest.googlevideo.com. Дальше имя узла превращается в IP обычным DNS-запросом, и плеер идёт к этому адресу.

Практическое следствие такое. Если пустить запросы к *.youtube.com через прокси или VPN другого региона, плеер получит имена узлов, подобранных для региона прокси, и пойдёт на них напрямую. Поэтому участники обсуждений советуют направлять через другой регион именно *.youtube.com, а не *.googlevideo.com. Дополнительная деталь: по словам участника, после первого фрагмента плеер может переключиться на ближайший к клиенту кэш, где лежит следующий фрагмент. Независимо подтвердить это не удалось.

Увидеть, куда направили именно вас, можно на служебной странице Google: https://redirector.gvt1.com/report_mapping?di=no — по рассказам участников, она показывает кластер, который обслуживает ваш адрес (например, внутри сети ТТК). Второй способ без специальных страниц: открыть вкладку «Сеть» в инструментах разработчика браузера (F12), отфильтровать запросы videoplayback и посмотреть «Удалённый IP».

Что показали прямые замеры 20 октября 2026 года

Чтобы отделить поведение самих узлов от поведения сетей абонентов, четыре адреса GOOGLE-TTK-NET проверены прямым подключением с хостинга в Москве (AS207957), без прокси и туннелей. Для каждого адреса измерены время установления TCP-соединения, успех TLS-рукопожатия при семи разных именах в запросе и ответ на заведомо чужой запрос (ссылка на ролик, выданная для другого кластера).

Адрес	TCP до порта 443	TLS при 7 именах	Сертификат	Ответ на чужой запрос
188.43.61.141	2,1 мс	7 из 7	*.googlevideo.com	HTTP 400 за 7,6 мс
188.43.67.12	19,0 мс	7 из 7	*.googlevideo.com	HTTP 400 за 55 мс
188.43.65.140	41,2 мс	7 из 7	*.googlevideo.com	HTTP 400 за 121 мс
188.43.65.12	98,6 мс	7 из 7	*.googlevideo.com	HTTP 400 за 268 мс

Семь имён: rr1---sn-ug5onuxaxjvh-n8v6.googlevideo.com, rr2---sn-ug5onuxaxjvh-p5ge.googlevideo.com, r1---sn-aigl6nze.googlevideo.com, googlevideo.com, www.youtube.com, www.google.com и ya.ru. Время ответа HTTP 400 считалось от начала соединения и включает TCP и TLS, поэтому в каждой строке оно лишь немного превышает задержку из предыдущего столбца.

Из таблицы следуют три вывода. Во-первых, все четыре узла живы: они отвечают на соединение, завершают TLS и отвечают на запрос, пусть и отказом, мгновенно. Во-вторых, узлу безразлично имя в запросе: даже ya.ru и www.google.com получают сертификат *.googlevideo.com и успешное рукопожатие, то есть избирательность по имени узлом не создаётся. Это важно для диагностики: если у абонента запрос с именем googlevideo.com зависает, а с другим именем проходит (так утверждает тест одного из участников обсуждения), причина лежит на пути между абонентом и узлом, а не в узле. В-третьих, четыре адреса одного блока находятся на разном удалении: 2, 19, 41 и 99 мс от Москвы. Это разные площадки, а не одна машина.

Есть деталь, которая пока объяснения не имеет. Автор записей трафика видит до 188.43.65.140 около 5 мс, а с московского хостинга до того же адреса 41 мс. Значит, из региона абонента ближе, чем из Москвы, то есть узел стоит где-то в пределах региона абонента или адрес обслуживают разные машины в зависимости от точки входа. Из публичных данных выбрать между этими вариантами нельзя.

Отдельно проверено, как имена узлов из обсуждения превращаются в адреса. Имена разрешены тем же прямым подключением с московского хостинга (DNS-запросы без прокси), и все они ведут в блоки GOOGLE-TTK-NET.

Имя узла (без .googlevideo.com)	Адрес	Блок в RIPE
rr1---sn-ug5onuxaxjvh-n8v6	188.43.61.140	188.43.61.0/24
rr2---sn-ug5onuxaxjvh-n8v6	188.43.61.141	188.43.61.0/24
rr3---sn-ug5onuxaxjvh-n8v6	188.43.61.142	188.43.61.0/24
rr2---sn-ug5onuxaxjvh-p5ge	188.43.65.77	188.43.64.0/23
rr3---sn-ug5onuxaxjvh-p5ge	188.43.65.78	188.43.64.0/23
rr1---sn-ug5onuxaxjvh-v8cz	188.43.65.140	188.43.64.0/23
rr1---sn-ug5onuxaxjvh-gv8e	188.43.67.140	188.43.66.0/23
rr6---sn-ug5onuxaxjvh-axql	188.43.69.17	188.43.68.0/23

Из таблицы видно три вещи. Во-первых, число в rrN — номер внутри кластера, и адреса идут подряд: у кластера …-n8v6 rr1, rr2, rr3 равны .140, .141, .142. Во-вторых, адрес 188.43.65.140 для rr1---sn-ug5onuxaxjvh-v8cz совпадает с тем, который абонент увидел в своих инструментах разработчика и на который смотрят записи трафика: ответ DNS из Москвы тот же, что у абонента, то есть имя не зависит от того, откуда спрашивают. В-третьих, четыре из семи блоков GOOGLE-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 реестр тоже называет серверы Google, но имён узлов оттуда в обсуждениях нет, и перебирать чужие адреса, чтобы найти их, нельзя.

Чего эти замеры не показывают

Это одна точка наблюдения (хостинг в Москве) и один день. Замеры не показывают, что происходит у абонентов ТТК и как узлы отдают ролики, которых нет в кэше: чтобы получить такое видео с конкретного кэша, нужна ссылка, выданная именно для этого кластера, а YouTube выдаёт её по IP клиента. Поэтому вывод «узел жив и не придирается к имени» относится только к рукопожатию и первому ответу.

Контрольный замер из-за рубежа: имя googlevideo.com строчными буквами теряется

Результат из Москвы нельзя читать как «узел всегда отвечает»: тот же узел проверен ещё и из-за границы, с сервера Zapret DNS в Нидерландах (AS41745, настоящие задержки 50–140 мс). Картина другая.

• HTTP на порту 80 отвечает всегда. Запрос GET /generate_204 с любым заголовком Host (rr1---sn-….googlevideo.com, googlevideo.com, www.google.com, example.org, вовсе без Host) возвращает 204 No Content и из Москвы, и из Нидерландов, за доли секунды.
• HTTPS из-за рубежа теряется по имени. TCP-соединение с узлами 188.43.65.140 и 188.43.61.141 устанавливается, но на приветствие TLS с именем вида rr1---sn-ug5onuxaxjvh-v8cz.googlevideo.com ответа нет вовсе (5 секунд). С именами googlevideo.com (без имени слева), www.youtube.com, www.google.com, ya.ru и даже rr1---sn-ug5onuxaxjvh-v8cz.example.com рукопожатие проходит. Из Москвы проходят все имена.
• Правило зависит от регистра. Стоит изменить буквы в googlevideo.com, и рукопожатие проходит: …GOOGLEVIDEO.COM, …GoogleVideo.com и даже …googlevideo.COM (заглавными только COM) прошли, а RR1---SN-….googlevideo.com (заглавная только левая часть) и rr1---sn-….googlevideo.com. (точка в конце) по-прежнему теряются. Не проходят и другие имена вида x.googlevideo.com, r1.googlevideo.com, manifest.googlevideo.com. Не проходит то, что оканчивается на строчное .googlevideo.com; имена googlevideo.net, xgooglevideo.com и ….googlevideo.com.example.org не затронуты.
• Разрез приветствия не помогает. Приветствие, разрезанное на два и три TCP-сегмента (до имени, посреди имени, внутри googlevideo.com), теряется так же, как целое. Значит, на пути стоит устройство, которое собирает поток, а не смотрит один пакет.
• Это не свойство узла. Приветствие с именем rr1---sn-….googlevideo.com из Нидерландов молча теряется и на части других российских адресов: у ya.ru (5.255.255.242) на пяти попытках из пяти, у других адресов ya.ru, mail.ru, rt.ru и gosuslugi.ru на отдельных запусках; к зарубежным серверам (google.com, example.org) оно проходит, а адрес 74.125.110.168 из семейства Google отвечает на любое имя. Есть и российские адреса, к которым это же приветствие проходит (mail.ru, 90.156.232.4). Значит, дело не в кэшах как таковых: узлы ТТК попадают под правило потому, что они российские и называются googlevideo.com.
• Запись пакетов на стороне Нидерландов для потерянного приветствия показывает: рукопожатие TCP проходит, подтверждение первого сегмента (1584 байта) приходит с адреса узла, после этого ничего не отвечают: следующий сегмент в 184 байта остаётся без подтверждения и клиент пересылает его заново. Для приветствия с заглавными буквами ответ приходит сразу. Из записи не видно, кто именно шлёт подтверждение, узел или устройство на пути.

Что из этого следует. Первое: сообщение «кэш недоступен через VPN, а с другого провайдера доступен, и по HTTP всегда доступен» совпадает с замерами для узлов ТТК. Выход VPN за рубежом — зарубежный источник, и его приветствие с именем …googlevideo.com в этом направлении теряется, а HTTP на порту 80 проходит. Второе: приём «пустить через VPN только *.googlevideo.com» обречён, когда плеер получил от youtube.com российские узлы; надёжнее, чтобы и страница воспроизведения, и сами видеоузлы шли через один выход, тогда плеер получает узлы того же региона, что и выход. Третье: правило нечувствительно к разрезу, но чувствительно к регистру, поэтому «простая нарезка» из Zapret в этом направлении не поможет, а смена регистра имени (достаточно заглавных букв в COM) в замере помогла. Это не рекомендация и не проверенный обход: клиентская программа должна уметь менять регистр имени в приветствии, а у браузера такой возможности нет. Проверить гипотезу на своём канале можно командами openssl s_client -connect <адрес>:443 -servername rr1---sn-….googlevideo.com и такой же командой с …googlevideo.COM: если первая молчит, а вторая отвечает, на пути стоит такое же правило.

Чего замеры не показывают. Где именно стоит устройство (на границе, в сети ТТК или рядом с узлами), чьё оно и действует ли то же правило внутри сети ТТК для абонентов, неизвестно: замер идёт только от двух точек и только по направлению «из-за рубежа». Часть результатов нестабильна (одно и то же имя то проходит, то теряется): это похоже на несколько путей с разным оборудованием. Адреса кэшей «Ростелекома» в Санкт-Петербурге не проверялись: их адресов нет, а по имени узла их из открытых данных не найти.

QUIC и откат на TCP

Плеер YouTube умеет получать видео двумя способами: по QUIC (протокол HTTP/3 поверх UDP, порт 443) и по обычному TCP с шифрованием TLS. Он сначала пробует QUIC и, если ответа нет в течение нескольких секунд, откатывается на TCP, а затем периодически снова возвращается к QUIC. Для обходов блокировок это важная деталь: стратегия, настроенная только для TCP, не помогает, пока плеер ждёт тайм-аут QUIC. Участник из Республики Коми выяснил, что адресов кэшей ТТК нет в списках Zapret, поэтому его правила для UDP вообще не срабатывали на трафик к ним. О том, как три области Zapret (YouTube TCP, YouTube QUIC, GoogleVideo) делят эту работу, написано в заметке YouTube в Zapret.

История GGC в России

Правила игры вокруг GGC в России менялись несколько раз, и это объясняет, почему любые сбои с ними принято сначала проверять на старение оборудования.

Единственное событие, подтверждённое первоисточником, которое удалось открыть: 12 июля 2024 года «Ростелеком» заявил в сообщении, опубликованном ComNews, что из-за «проблем с эксплуатацией серверов GGC и невозможности их расширения» наблюдается серьёзная перегрузка мощностей, в том числе на пиринговых стыках. Остальные события на схеме даны по обзору Runnin4ik/ggc-russia: автор сам называет цифры расчётными, а события 2025–2026 годов, по его же оговорке, опираются на посты форума. Отсюда общий вывод: версия «оборудование стареет» действительно давно звучит, но для событий конца октября 2026 года её не подтверждает ни одно измерение.

Источники

• RIPEstat: whois для 188.43.65.140 — сеть GOOGLE-TTK-NET, AS20485
• ComNews, 15 июля 2024 — «YouTube не показался „Ростелекому“» — заявление «Ростелекома» от 12 июля 2024
• Обзор Runnin4ik/ggc-russia на GitHub — компиляция по GGC в России, цифры расчётные
• Служебная страница Google, которую участники используют для проверки кластера: https://redirector.gvt1.com/report_mapping?di=no
• Форум ntc.party, тема от 17 октября 2026 об отдаче YouTube через разные кэши googlevideo.com: прямой ссылки нет, форум недоступен с сервера, который собирает вики
• Собственные замеры 20 октября 2026 года с хостинга в Москве (AS207957) и с сервера Zapret DNS в Нидерландах (AS41745): TCP, TLS (разные имена и регистр, разрез приветствия, запись пакетов) и HTTP к узлам блока GOOGLE-TTK-NET и к контрольным адресам

📚 См. также

• ТТК и YouTube: кэши Google в сети Транстелекома (с 17 октября 2026) — инцидент, для разбора которого написана эта заметка
• Как читать pcap видеосоединения с узлом googlevideo — разбор записей трафика к узлу ТТК
• YouTube в Zapret — три области обхода и вкладка GoogleVideo
• Как определить владельца домена или IP — как проверять подсеть узла

---

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

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