🔎 Как найти домены сайта через F12 (вкладка «Сеть») для своего профиля Zapret 2

О чём заметка

Как понять, какие именно домены вписать в свой профиль Zapret 2, когда сайт открывается не полностью или не открывается вовсе. Инструмент — встроенная в браузер панель разработчика (клавиша F12) и её вкладка «Сеть». Механика создания профиля и вписывания доменов в GUI — в add-profile; как по найденному домену узнать CDN и готовый профиль пресета — в find-domain-owner.

TL;DR

1. Откройте проблемный сайт, нажмите F12 → вкладка «Сеть», включите «Сохранять журнал» и «Отключить кеш», обновите страницу через Ctrl+F5.
2. Ищите красные строки: статусы «(ошибка)», «(отменено)» и долго висящие «(ожидает)» с размером 0 кБ. Их домены — кандидаты в профиль.
3. Отсейте то, что к DPI не относится: ERR_BLOCKED_BY_CLIENT и «(заблокировано)» — это блокировщик рекламы или сам браузер, ERR_NAME_NOT_RESOLVED — проблема DNS.
4. Выпишите домены, которые падают, и внесите их в hostlist своего профиля по add-profile. Начинайте с точных поддоменов, а не с родительского домена: запись example.com захватывает все поддомены сразу и может сломать те, что работали.
5. После подбора стратегии снова откройте «Сеть» и убедитесь, что те же запросы получили статус 200.

Почему «сайт» — это десятки доменов

Когда вы вводите в адресной строке soundcloud.com, браузер загружает с этого адреса только каркас страницы. Всё остальное — скрипты, картинки, шрифты, данные для ленты, плеер, авторизация — страница затем догружает отдельными запросами, и часто с других доменов: с поддоменов (api-v2.soundcloud.com), со своей сети доставки контента (у SoundCloud статика приходит с отдельного домена sndcdn.com), со сторонних сервисов аналитики и рекламы. На одну обычную страницу приходится несколько десятков, а то и сотен запросов.

Для обхода блокировок это важно по простой причине. ТСПУ (технические средства противодействия угрозам — оборудование DPI у провайдера) решает судьбу каждого соединения отдельно, по имени домена в нём. Поэтому главная страница может открыться, а запросы к API того же сайта — повиснуть. Со стороны это выглядит как «сайт вроде работает, но кнопки не нажимаются, лента пустая, видео не играет». Если вписать в профиль только домен из адресной строки, часть сайта так и останется за блокировкой.

Проще говоря: чтобы сайт заработал целиком, в hostlist профиля должны попасть все домены, запросы к которым режет DPI. Узнать их на глаз нельзя, а вкладка «Сеть» показывает их списком.

Шаг 1. Откройте панель разработчика и вкладку «Сеть»

Панель разработчика (DevTools) есть в любом браузере на основе Chromium: Chrome, Edge, Яндекс Браузер, Opera, Brave. Открыть её можно клавишей F12 или сочетанием Ctrl+Shift+I. Вверху панели — ряд вкладок: «Элементы», «Консоль», «Источники», «Сеть» и другие. Нужна «Сеть» (в английском интерфейсе — Network): она записывает каждый запрос, который страница отправляет, и показывает, чем он закончился.

Перед записью включите две галочки в верхней строке вкладки:

• «Сохранять журнал» — чтобы список не очищался при переходах и перезагрузках страницы;
• «Отключить кеш» — чтобы браузер заново скачивал всё из сети, а не показывал сохранённые копии. Иначе запрос к заблокированному домену может «успешно» прийти из кеша, и вы его не заметите.

Панель записывает запросы только пока открыта. Поэтому порядок такой: сначала открыть «Сеть», затем обновить страницу через Ctrl+F5 (обновление с новым соединением, подробнее — в verify-strategy). Внизу панели появится счётчик вроде «Запросы: 134».

Firefox

В Firefox панель открывается так же, по F12, вкладка тоже называется «Сеть». Колонки и тексты статусов там другие, но принцип тот же: ищите запросы без ответа и с ошибками.

Шаг 2. Прочитайте таблицу запросов

Каждая строка таблицы — один запрос. Для поиска доменов хватит пяти колонок:

Колонка	Что в ней	На что смотреть
URL (Имя)	Адрес запроса	Домен — часть между https:// и следующим /
Статус	Код ответа сервера или причина неудачи	Числа 200, 204, 304 — всё дошло; текст в скобках — ответа не было
Тип	Что запрашивалось: документ, скрипт (script), данные (xhr, fetch), картинка	Больше всего говорят упавшие document и xhr/fetch: без них страница пустая
Размер	Сколько байт пришло	0,0 кБ у упавшего запроса — сервер не ответил ничего
Время	Сколько длился запрос	Круглые большие числа (10,00 с) — запрос висел, пока его не оборвали

Чтобы видеть домены отдельно от длинных адресов, щёлкните правой кнопкой по заголовку любой колонки и включите колонку «Домен», а заодно «Удалённый адрес» — в ней IP-адрес сервера, который пригодится в find-domain-owner. По заголовку «Домен» таблицу можно отсортировать, и запросы к одному домену встанут рядом.

Какие статусы означают блокировку

Статус в скобках значит, что нормального ответа сервера не было, и браузер описывает, что случилось вместо него. Точную причину видно в «Консоли» (соседняя вкладка): для каждого упавшего запроса там есть красная строка вида GET https://… net::ERR_CONNECTION_RESET. Та же ошибка появляется во всплывающей подсказке, если навести курсор на статус.

Что видно	Что это обычно значит	Помогает ли профиль Zapret
«(ошибка)» + ERR_CONNECTION_RESET, ERR_CONNECTION_CLOSED, ERR_SSL_PROTOCOL_ERROR	Соединение оборвали посреди установки или обмена данными. Типичная картина вмешательства DPI	Да, это основной кандидат в профиль
«(ошибка)» + ERR_TIMED_OUT, ERR_CONNECTION_TIMED_OUT	Ответа не пришло вовсе: пакеты теряются по дороге	Часто да; если не помогает ни одна стратегия, возможна блокировка по IP
«(отменено)» с временем около 10–30 с и размером 0 кБ	Запрос висел без ответа, и скрипт сайта сам его оборвал по таймауту	Да, это та же «тихая» блокировка, только оборвал её сайт, а не браузер
«(ожидает)», который не заканчивается	Запрос ещё не получил ответа	Смотрите по итогу: если так и не завершился, считайте его упавшим
«(заблокировано…)», ERR_BLOCKED_BY_CLIENT	Запрос не выпустил сам браузер: блокировщик рекламы, расширение или политика сайта	Нет. К провайдеру отношения не имеет
ERR_NAME_NOT_RESOLVED	Домен не удалось перевести в IP-адрес (не сработал DNS)	Нет. Это проблема DNS, стратегия обхода DPI её не решит
Число 403, 451 или переадресация на страницу-заглушку	Сервер ответил, но отказал: сайт закрылся от региона сам, или провайдер подставил свою заглушку	403 от самого сайта — нет, см. GEO-ограничения и файл hosts; заглушка провайдера — да

Расшифровка статусов — ориентир, а не диагноз

Один и тот же текст ошибки бывает и при блокировке, и при обычной неполадке сервера или вашей сети. Надёжный признак DPI — когда запросы к домену падают при включённом Zapret-профиле со «слабой» стратегией и проходят при подобранной. Поэтому таблица выше подсказывает, какие домены проверять первыми, а окончательный ответ даёт только перебор стратегий.

Строки вида data:image/… и строки с пометкой «(кеш памяти)» в размере — это данные, которые браузер взял у себя, без обращения к сети. Их можно не рассматривать.

Пример: SoundCloud открывается, но лента пустая

Типичный случай, сентябрь 2026. Главная страница soundcloud.com отрисовалась: баннер, поиск, кнопки на месте. Но ниже заголовка «Hear what’s trending» вместо ленты надпись «Sorry, something went wrong.». Во вкладке «Сеть» видна причина:

Что можно прочитать в таблице справа:

• Почти все красные строки ведут на один домен — api-v2.soundcloud.com. Именно оттуда страница берёт данные для ленты, поэтому лента и не появилась.
• Статус «(отменено)», размер 0,0 кБ, время ровно 10,00 с. Запросы висели без единого байта ответа, и через 10 секунд скрипт сайта их оборвал. Круглая цифра — признак таймаута, заданного самим сайтом, а не сбоя браузера.
• Статус «(ошибка)» с временем от 0,5 до 8 секунд на том же домене — соединения, которые оборвались раньше таймаута.
• Строки «(ожидает)» с инициатором «Предварительная проверка» — служебные запросы-разрешения (preflight), которые браузер отправляет перед основными запросами к API. Они висят по той же причине.
• Внизу несколько запросов к тому же api-v2.soundcloud.com со статусом 200. Домен не заблокирован намертво: часть соединений проходит. Такая картина больше похожа на вмешательство DPI, чем на недоступность сервера, а значит, подобранная стратегия, скорее всего, поможет.
• dwt.soundcloud.com отвечает 200 за 268 мс — этот поддомен работает.
• Строки «(заблокировано)» с типом ping — запросы статистики, которые не выпустил браузер или расширение. В профиль их добавлять не нужно.

Итог: для SoundCloud начинать стоит с одной строки api-v2.soundcloud.com — именно этот поддомен падает, а dwt.soundcloud.com и главная страница работают и без профиля. Если бы красными были и запросы к sndcdn.com (картинки, скрипты, звук), его понадобилось бы добавить отдельно: это другой домен. Как быть с поддоменами в целом — в следующем шаге.

Шаг 3. Соберите список доменов

Когда красные строки найдены, превратите их в список для профиля:

• Выпишите домены всех упавших запросов типа document, xhr, fetch, script и медиа. Упавшие картинки второстепенны, но если их много с одного домена, добавьте и его.
• Вписывайте точные поддомены, которые падают (api-v2.example.com), а не родительский домен целиком. Подробнее — ниже, в «Поддомены: начинайте с малого».
• Вычеркните домены из строк «(заблокировано…)» и ERR_BLOCKED_BY_CLIENT, а также чужие счётчики и рекламу (google-analytics.com, doubleclick.net и подобные), если без них сайт работает.
• Отдельно пройдите действия, которые не работают: вход в аккаунт, воспроизведение видео, загрузку файла. Перед каждым очистите журнал кнопкой ⊘ в панели, чтобы видеть только запросы этого действия. Авторизация и видео часто живут на своих доменах.

Поддомены: начинайте с малого

Hostlist в Zapret сам применяется к поддоменам: строка example.com включает в профиль и www.example.com, и api-v2.example.com, и любой другой поддомен. Это удобно, но опасно. Поддомены одного сайта нередко живут на разных серверах и в разных сетях доставки контента, и DPI может обращаться с ними по-разному. Стратегия, которая пробивает api-v2.example.com, способна сломать www.example.com, который до этого открывался без всякого обхода, потому что профиль начнёт вмешиваться и в его соединения.

Поэтому двигайтесь от меньшего к большему:

1. Впишите только те поддомены, запросы к которым падают, — по одному на строку.
2. Проверьте сайт по вкладке «Сеть» (шаг 4). Если всё заработало, на этом остановитесь.
3. Если падают всё новые поддомены того же сайта и все они лечатся той же стратегией, тогда замените их одной строкой с родительским доменом и снова проверьте, что не сломалось ничего из работавшего.
4. Если после расширения что-то перестало грузиться, верните точные поддомены. Поддомену, которому нужна другая стратегия, заведите отдельный профиль: одно соединение обрабатывает только один профиль, см. profile-independence.

Удобный приём для длинного журнала: в поле «Фильтр» можно написать domain:api-v2.soundcloud.com, чтобы оставить только запросы к одному домену, или -domain:soundcloud.com, чтобы скрыть уже разобранный домен и посмотреть, что осталось.

Готовый список вписывается в hostlist своего профиля: пошагово, со скриншотами GUI, это разобрано в «Как добавить свой профиль», шаг 3.

Прежде чем заводить новый профиль, проверьте, чей это сервер

Колонка «Удалённый адрес» даёт IP каждого домена. Если сайт живёт на крупной сети доставки контента (Cloudflare, Akamai, Amazon), в пресете уже может быть профиль под эту сеть, и тогда стратегию нужно подбирать в нём, а не плодить свой. Как по IP узнать сеть и найти её профиль — в find-domain-owner.

Шаг 4. Проверьте результат в той же вкладке

После того как профиль создан и стратегия выбрана, откройте сайт заново: включённые «Сохранять журнал» и «Отключить кеш», очистка журнала, Ctrl+F5. Если стратегия подошла, запросы к тем же доменам получат статус 200 (или 204, 304), а в колонке «Время» вместо 10,00 с появятся сотни миллисекунд. Если красные строки остались на тех же доменах — стратегия не пробивает их, переходите к следующей. Если красным стал новый домен — допишите его в список и повторите.

Такая проверка честнее, чем «вроде открылось»: страница может отрисоваться из кеша или по уже открытому соединению, а вкладка «Сеть» показывает каждый запрос. Подробно о ложных успехах при проверке — в verify-strategy; о том, почему «не работает» почти всегда значит «стратегия устарела», а не «программа сломалась», — в symptom-not-cause.

Ловушки и оговорки

• Не всё красное — блокировка. Блокировщик рекламы, антивирус с веб-защитой и расширения приватности режут запросы сами, и в «Сети» это тоже выглядит как ошибка. Если сомневаетесь, откройте сайт в окне инкогнито без расширений и сравните.
• Список доменов со временем меняется. Сайты переезжают на другие домены и сети доставки контента. Если профиль перестал помогать, пройдите вкладку «Сеть» заново.
• Не для игр и приложений. Вкладка «Сеть» видит только то, что делает страница в браузере. Для игр, клиентов и голосовых звонков нужен перехват трафика всей системы: find-game-strategy (TCPView) и создание своей категории (Wireshark).
• Hostlist видит только трафик с именем домена. Если сайт ходит на голые IP-адреса или по UDP (например, QUIC), домена в соединении может не оказаться, и тогда нужен ipset с адресами, а не hostlist. Разница разобрана в find-domain-owner.

📚 См. также

• Как добавить свой профиль — куда в GUI вписать найденные домены и как включить профиль
• Как узнать CDN домена — что делать с IP из колонки «Удалённый адрес» и как найти готовый профиль сети
• Стратегия для игры — тот же подход для игр, где браузерной панели нет
• hostlist · ipset — списки доменов и IP-адресов профиля
• Как проверить, заработала ли стратегия — ловушки F5 и автоподбора
• Одно соединение — один профиль — почему домен должен попасть ровно в один подходящий профиль
• Zapret 2: обзор раздела — карта всех заметок о настройке
• 🔗 Документация Chrome DevTools о вкладке Network — все колонки, фильтры и статусы (на английском)

---

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

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