---
date: 2026-09-20
tags:
  - dpi
  - тспу
  - rkn
  - диагностика
  - tcp16-20
  - l4-25
  - sni
  - dns
  - инструменты
  - цензура
aliases:
  - Инспекторы ТСПУ
  - Чем проверить блокировки ТСПУ
  - Как проверить есть ли DPI у провайдера
  - Проверка TCP 16-20 блокировки
  - DPI Detector как пользоваться
  - dpi-ch чекер
  - rkn-block-checker
  - ByeByeVPN проверка сервера
  - ТСПУ Probe для Android
  - Почему не работает VLESS как проверить
  - cheburcheck
  - Проверить блокировку домена онлайн
description: "Семь инструментов диагностики ТСПУ: как каждый измеряет блокировку (TCP 16-20/l4-25, SNI, DNS, заглушки), где ошибается и в каком порядке их запускать."
image: DPI/attachments/tspu-inspectors-header.webp
---

> [!mirror] Резервное зеркало
> Актуальная версия этой страницы — на основной вики: [wiki.zapret.moe/DPI/tspu-inspectors-checkers-2026](https://wiki.zapret.moe/DPI/tspu-inspectors-checkers-2026)

# 🔎 Инспекторы ТСПУ: семь чекеров блокировок и что они измеряют на самом деле

![[tspu-inspectors-header.webp]]

> [!info] О чём заметка
> **ТСПУ** (Технические средства противодействия угрозам — оборудование фильтрации Роскомнадзора, стоящее в сетях российских операторов) не сообщает, что именно он сделал с вашим соединением. Браузер показывает «сайт недоступен» одинаково и при сброшенном соединении, и при подменённом DNS-ответе, и при упавшем сервере. Инструменты из этой заметки разбирают отказ по слоям и называют механизм: подмена DNS, RST на TLS-рукопожатии, фильтрация по имени домена в рукопожатии, «заморозка» после первых килобайт, заглушка провайдера. Здесь разобрано, **как** именно каждый из семи инструментов добывает свой вердикт, где его метод ошибается и в каком порядке их запускать, чтобы не получить красивую таблицу с ложными выводами.

## TL;DR

- Семь инструментов отвечают на три разных вопроса: пять смотрят **на вашу сеть** (что провайдер делает с вашими соединениями), один — **на ваш сервер** снаружи (насколько он похож на VPN с точки зрения цензора), ещё один — **на чужие сети** глазами зондов в разных регионах России. Путать их выводы нельзя.
- «Блокировка TCP 16–20 КБ» — не порог в байтах. По наблюдениям сообщества ограничение считает **пакеты** (обычно около 25 в обе стороны суммарно), поэтому в отчётах видно и 15 КБ, и 24 КБ на соседних строках. Автор `dpi-checkers` предложил честное имя — **l4-25**, и оно же объясняет, почему тот же эффект встречается на UDP.
- Самый подробный клиентский инструмент — **DPI Detector** (Python, 2240 ★ на 20 сентября 2026): пять тестов, 110 целей в 43 автономных системах, подбор «белого» SNI, двухфазная проверка DNS с эталоном по DoH и определением реального выходного резолвера.
- Самый методически интересный — **dpi-checkers**: браузерный чекер без установки, утилита `dpi-ch` на Go с динамическим выбором целей через фильтры вида `org("hetzner") && country("de")` (чтобы цензору нечего было внести в белый список) и проверка «сибирских» ограничений по числу одновременных рукопожатий.
- **rkn-block-checker** ценен не покрытием, а дисциплиной вывода: у каждого вердикта есть уровень уверенности, а если контрольный «белый» список сайтов сам разваливается — инструмент отказывается делать вывод вместо того, чтобы нарисовать блокировку.
- **ByeByeVPN** проверяет ваш сервер так, как его видит оператор: восемь проб на TLS-порт, JA4/JA4S, UDP-рукопожатия WireGuard и Hysteria2, эмуляция вердикта ТСПУ. Шкала — авторская модель, а не документация регулятора, и автор сам это помечает.
- **Cheburcheck** — единственный здесь сервис с распределённой сетью зондов: он показывает, как ваш домен ведёт себя у чужих провайдеров, и заодно определяет номер сетевого узла, на котором стоит фильтр. Его же зонды собирают публичный список доменов-исключений — 2138 штук на 20 сентября 2026.
- Два простых инструмента — bash-скрипт **tspu-checker** и Android-приложение **ТСПУ Probe** — полезны как быстрые полевые щупы, но в первом часть проверок измеряет не то, что обещает (разбор ниже), а второе не умеет ни l4-25, ни UDP.
- Любой чекер врёт, если на машине работает обход. Выключайте zapret, GoodbyeDPI, VPN и прокси перед запуском — иначе вы измеряете собственный обход, а не фильтр оператора.

## Что вообще можно измерить снаружи

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

| Этаж | Что делает фильтр | Как это выглядит у вас | Кто это видит |
| --- | --- | --- | --- |
| DNS | подмена ответа, `NXDOMAIN`, перехват запроса к чужому резолверу | «сервер не найден», сайт не резолвится | DPI Detector, rkn-block-checker, cheburcheck, tspu-checker |
| IP / маршрут | пакеты к адресу или подсети не доходят | таймаут на всех портах, ни одного RST | ByeByeVPN (признак BGP-blackhole), чекер подсетей у dpi-checkers, cheburcheck (номер узла с фильтром) |
| TCP | инъекция RST, дроп SYN | «соединение сброшено» сразу или зависание на подключении | все клиентские чекеры |
| TLS / SNI | разрыв по имени домена в ClientHello | рукопожатие рвётся, хотя порт открыт | DPI Detector, ТСПУ Probe, dpi-ch, cheburcheck, tspu-checker |
| Объём и поведение сессии | «заморозка» после ~25 пакетов, ограничение числа соединений, оценка почерка клиента | сайт начал грузиться и встал; VPN работает секунды и умирает | dpi-checkers (l4-25, «сибирская» проверка), DPI Detector (TCP 16–20), cheburcheck |
| HTTP | заглушка оператора, `451` | страница «Доступ ограничен» | rkn-block-checker, DPI Detector |

Проще говоря: вопрос «заблокировано или нет» почти бесполезен, а вопрос «на каком этаже рвётся» сразу подсказывает лечение. Если ломается DNS — помогает шифрованный резолвер; если рвётся ClientHello по имени домена — смена SNI или фрагментация; если соединение умирает после первых килобайт — ни то, ни другое не поможет, потому что фильтр вообще не смотрит на содержимое.

Подробный разбор того, в каком порядке DPI перебирает признаки соединения, есть в парной заметке [[DPI/dpi-analysis-pipeline|Как DPI анализирует соединение: воронка проверок]]; поведенческая «заморозка» VLESS+REALITY разобрана в [[VLESS/dpi-tls-june-2026|заметке про схему июня 2026]]. Здесь речь о другом: об инструментах, которые эти слои измеряют.

## Семь инструментов: общая картина

Данные о репозиториях — на 20 сентября 2026 (звёзды и даты получены через GitHub API).

| Инструмент | Язык, платформы | Смотрит | Ключевая техника | ★ | Лицензия |
| --- | --- | --- | --- | --- | --- |
| [DPI Detector](https://github.com/Runnin4ik/dpi-detector) | Python; Win/Linux/macOS/Termux/iOS, Docker | на вашу сеть | 5 тестов, TCP 16–20 через keep-alive с мусорным заголовком | 2240 | MIT |
| [dpi-checkers](https://github.com/hyperion-cs/dpi-checkers) | Go + браузерный JS + Python | на вашу сеть | l4-25, динамические цели по фильтрам AS/org/страны, «сибирская» проверка | 2012 | Apache-2.0 |
| [rkn-block-checker](https://github.com/MayersScott/rkn-block-checker) | Python; PyPI, Docker | на вашу сеть | послойный DNS→TCP→TLS→HTTP с калибровкой уверенности | 1620 | MIT |
| [cheburcheck](https://github.com/LowderPlay/cheburcheck) | Rust + SvelteKit; сайт, зонды для Debian/Docker/OpenWrt | на чужие сети | сеть зондов по регионам, поиск узла с фильтром, реестры и белые списки | 568 | BSD-3-Clause |
| [ByeByeVPN](https://github.com/pwnnex/ByeByeVPN) | C++; одна .exe, через Wine на Linux/macOS | на ваш сервер | 8 активных проб на порт, JA4/JA4S, UDP-рукопожатия, эмуляция вердикта | 411 | GPL-3.0 |
| [tspu-checker](https://github.com/ku78/tspu-checker) | Bash/PowerShell; Linux/WSL/Termux | на вашу сеть | меню ручных проверок поверх `curl`, `dig`, `openssl` | 183 | MIT |
| [ТСПУ Probe](https://github.com/stpavel/tspu-probe) | Java; Android 7+ | на вашу сеть | послойный щуп к своему серверу + перебор SNI | 25 | MIT по README |

Шесть из семи проектов моложе года, а четыре появились весной-летом 2026 — прямое следствие того, что блокировки в 2026 году перестали быть «список доменов» и превратились в набор разнородных механизмов, каждый со своим симптомом.

## DPI Detector: пять тестов и честный классификатор ошибок

Проект `Runnin4ik/dpi-detector` (создан 13 февраля 2026, MIT) — самый подробный из клиентских. Готовые сборки есть под Windows 7 и 10/11, Linux (x86_64, ARM64, ARMv7, x86), macOS Intel и Apple Silicon, Android через Termux и iOS через a-Shell; отдельно публикуется Docker-образ, в том числе вариант с веб-терминалом на порту 7681. Запускать можно как интерактивное меню, так и с аргументами (`-t 2 -d discord.com -p socks5://127.0.0.1:1080`).

Меню состоит из шести тестов плюс справка: информация о сети и системе, доступность DNS-серверов, доступность доменов, блокировка TCP 16–20 КБ, поиск белых SNI для автономных систем, проверка Telegram на замедление.

### Как он ищет «заморозку» TCP 16–20

Главная находка при чтении исходников — механика теста, которая объясняет и вид отчёта. Инструмент открывает **одно** соединение (`max_keepalive_connections=1`) и посылает по нему серию из десяти запросов `HEAD`. Первый запрос чистый — он проверяет, что хост вообще жив, и заодно измеряет время оборота. Каждый следующий несёт мусорный заголовок `X-Pad` длиной 4000 байт, нарезанный из заранее сгенерированного пула случайных символов. Итого в соединение «наливается» до сорока килобайт.

Срабатывание засчитывается только начиная с того запроса, после которого суммарно отправлено не меньше нижнего порога из конфигурации (`TCP_BLOCK_MIN_KB: 12`, верхняя граница окна анализа — `TCP_BLOCK_MAX_KB: 36`). Обрыв раньше порога помечается обычным таймаутом, а не блокировкой. Таймаут чтения при этом динамический: после первых двух запросов он ставится как утроенное измеренное время оборота, но не меньше полутора секунд и не больше двенадцати — иначе на медленном мобильном канале любая задержка выглядела бы как «заморозка».

Проще говоря: инструмент не скачивает большой файл, а сам постепенно выталкивает данные в соединение и смотрит, на каком килобайте оно перестаёт отвечать. Именно поэтому в правой колонке скриншота выше стоят разные значения — `Read timeout at 15KB`, `16KB`, `21KB`, `24KB`. Разброс не означает нестабильности инструмента: считаются не байты, а пакеты, и один и тот же счётчик срабатывает на разном объёме в зависимости от того, какими порциями данные легли в сегменты.

Список целей лежит в `tcp16.json` — 110 адресов в 43 автономных системах инфраструктурных провайдеров (Hetzner, Cloudflare, CDN77, Akamai, OVH, DigitalOcean, Contabo, Scaleway, Gcore, Oracle, Vultr и другие), из них шесть целей — на порту 80, чтобы отделить эффект TLS от эффекта самого объёма.

### Классификатор: ярлык зависит от стадии соединения

Вторая сильная часть — `utils/error_classifier.py`. Через трассировочные хуки HTTP-клиента инструмент знает, на какой стадии умерло соединение: установка TCP, рукопожатие TLS, отправка данных, чтение ответа. Одна и та же ошибка операционной системы превращается в разные вердикты в зависимости от стадии: сброс на стадии рукопожатия — это `TLS RST` («TCP RST на ClientHello»), тот же сброс после рукопожатия — `TCP RST`, таймаут на стадии подключения — `SYN DROP`, а таймаут на рукопожатии — `TLS DROP`.

Отдельно разбираются подделки: алерт `unrecognized_name` помечается как блокировка по имени домена, алерт `handshake_failure` — как вмешательство DPI, ошибки вида «wrong version number» и «record overflow» — как `TLS SPOOF`, то есть ответ, который прислал не сервер, а кто-то по дороге. Ошибки проверки сертификата разложены по кодам: самоподписанный, просроченный, несовпадение имени — всё это `TLS MITM`, а отсутствие корневых сертификатов в системе честно помечается жёлтым `NO CA BUNDLE`, чтобы пользователь не принял свою кривую сборку за перехват.

Полный набор ярлыков читается как словарь симптомов — он пригодится и при чтении чужих отчётов:

| Ярлык | Что под ним | О чём говорит |
| --- | --- | --- |
| `SYN DROP` | таймаут на стадии установки TCP | пакеты к адресу не доходят: блок по адресу или подсети |
| `TCP RST` / `TLS RST` | сброс соединения; во втором случае — ровно на ClientHello | инъекция RST промежуточным устройством (или занятой сервер) |
| `TLS DROP` | таймаут на стадии рукопожатия | ClientHello молча не пропускают |
| `TLS ALERT` | алерт `unrecognized_name` или `handshake_failure` | реакция на имя домена в рукопожатии |
| `TLS SPOOF` | «wrong version number», мусор вместо записи TLS | ответ сформировал не сервер |
| `TLS MITM` | самоподписанный, просроченный сертификат, чужое имя | перехват с подменой сертификата |
| `TCP16-20` | чтение встало, прочитано 12–36 КБ | «заморозка» по объёму и числу пакетов |
| `ISP PAGE` | адрес совпал с набором заглушек провайдера | подмена DNS на страницу «доступ ограничен» |
| `NO CA BUNDLE` | в системе нет корневых сертификатов | проблема вашей машины, а не сети |

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

![[tspu-inspectors-dpi-detector-domains-tcp1620.webp]]

На скриншоте выше видно, как это выглядит на практике: у большинства заблокированных доменов TLS 1.2 и TLS 1.3 дают `SSL ERR` с деталью `TLS Aborted`, а обычный HTTP приводит на `ISP PAGE` — страницу-заглушку провайдера. При этом `hub.docker.com`, `www.intel.com` и `www.linuxserver.io` в той же таблице зелёные, то есть канал в целом жив, и наблюдаемая картина — избирательная фильтрация, а не сломанный интернет.

### DNS: эталон правды и реальный выходной резолвер

Проверка DNS сделана в две фазы. Сначала по «доверенным» доменам вне цензуры (`vk.ru`, `gosuslugi.ru`) измеряется, жив ли сервер вообще и какая у него задержка. Потом те же серверы опрашиваются по заблокированным доменам (`rutor.info`, `flibusta.is`, `rezka.ag`, `shikimori.one` и другим), и ответ сравнивается с эталоном, полученным по DoH (DNS over HTTPS, шифрованный DNS поверх HTTPS) и DoT (DNS over TLS). Молчание в ответ на запрещённый домен при живом сервере тоже считается подменой — это блокировка без ответа, а не недоступность.

Дополнительно инструмент определяет, кто **на самом деле** обработал ваш UDP-запрос: он спрашивает у каждого сервера адрес `whoami.akamai.net`, а затем узнаёт организацию-владельца полученного адреса TXT-запросом к `origin.asn.cymru.com` через DoH. Если вы спрашиваете Google, а отвечает инфраструктура постороннего оператора — это видно прямо в колонке «Реальный UDP резолвер». Ровно этот приём в августе 2026 позволил показать, что запросы заворачиваются на резолверы НСДИ; механика инцидента разобрана в [[DPI/tspu-dns-nsdi-dnat-august-2026|заметке про перехват DNS на ТСПУ]], а в списке серверов `config.yml` адреса НСДИ `195.208.4.1` и `195.208.5.1` присутствуют штатно.

Заглушки провайдера вычисляются статистически: если один и тот же адрес приходит в ответ на два и более разных запрещённых домена, он записывается в набор «стабов», и дальше любой домен, резолвящийся туда, помечается как `ISP PAGE` без лишних запросов.

### Подбор белого SNI и тест Telegram

Четвёртый тест нужен тем, кто держит свой сервер. Сначала по одной цели на каждую автономную систему проверяется, есть ли там «заморозка»; перебор запускается только для тех систем, где она нашлась. Дальше 187 имён из `whitelist_sni.txt` (`hcaptcha.com`, `vk.com`, `2gis.ru`, поддомены Яндекса, `ok.ru` и прочие популярные российские и нейтральные домены) перебираются батчами по пять с уже известным временем оборота, и в отчёт попадают первые найденные имена, с которыми соединение доживает до конца. Практический смысл: это и есть кандидаты на `serverNames` для REALITY в сети, где обычные имена «замораживаются».

Пятый тест меряет не блокировку, а замедление: скачивание файла на 30,97 МБ с `telegram.org`, отправка 10 МБ и TCP-пинг пяти дата-центров Telegram. Он различает «ОК», «ЗАМЕДЛЕНИЕ», «ЗАМЕДЛЕНИЕ+ОБРЫВ» и «НЕДОСТУПНО» и показывает, на какой секунде оборвалась передача — полезно, потому что троттлинг Telegram проявляется именно как обрыв на середине, а не как отказ подключения.

> [!warning] Инструмент сам предупреждает: выключите обход
> В `utils/bypass_detector.py` зашит список примерно из двух десятков процессов — `nfqws`, `winws`, `tpws` (zapret), `goodbyedpi`, `byedpi`, `xray`, `sing-box`, `mihomo`, `hiddify`, `warp-svc` и другие. Если что-то из этого запущено, отчёт получится про ваш обход, а не про фильтр оператора. Для zapret в документации сделана оговорка: допустимо оставить его включённым только в режиме обработки всех пакетов, а не по списку — иначе часть проб пойдёт «в обход обхода» и результаты перемешаются.

## dpi-checkers: браузер, Go-утилита и переименование в l4-25

Репозиторий `hyperion-cs/dpi-checkers` (создан 30 июня 2025, Apache-2.0) — не одна программа, а четыре разных чекера плюс набор исследовательских скриптов. Именно отсюда пришли две вещи, которые изменили понимание блокировки: метод проверки «наливом» и сама формулировка **l4-25**.

### Веб-чекер: проверка прямо во вкладке

Страница `hyperion-cs.github.io/dpi-checkers/ru/tcp-16-20/` тестирует 36 хостов у популярных провайдеров и работает без установки, прямо в браузере.

![[tspu-inspectors-hyperion-tcp1620-web.png]]

Логика такая. Сначала `HEAD`-запрос проверяет, жив ли хост. Потом идут два метода подряд: `POST` с 64 КБ случайных байт в теле и, если он не дал результата, девять `HEAD`-запросов, где мусор в 7 КБ уложен в строку запроса (`/?x=<7 КБ>`) — вместе те же 64 КБ по одному keep-alive-соединению. Ограничение в 7 КБ на запрос — компромисс с длиной URI, которую примут серверы и промежуточные прокси.

Результат раскладывается на пять состояний, и в этом главное отличие от бинарного «заблокировано / нет»:

| Статус | Что случилось | Как читать |
| --- | --- | --- |
| `No` ✅ | пробы дошли, ошибок нет | ограничение не обнаружено |
| `Detected` ❗ | хост живой, а «налив» упёрся в таймаут | классическая заморозка |
| `Probably` | хост не ответил на проверку живости, «налив» завис по таймауту | скорее всего блокировка, но контроль потерян |
| `Possible` | хост живой, «налив» упал мгновенной ошибкой | возможно, но мгновенная ошибка бывает и от сервера |
| `Unlikely` | и проверка живости, и «налив» упали мгновенно | похоже на проблему хоста, а не фильтра |
| `Skip` | хост не отвечает | проверять нечего |

На скриншоте видно смешанную картину: у одного и того же провайдера соседние адреса дают и `No`, и `Detected` (Cloudflare `US.CF-01` против `US.CF-02`, Hetzner `FI.HE-03` против недоступных `FI.HE-01/02`). Это нормальная для 2026 года ситуация: ограничения применяются к подсетям, а не к компаниям, и «Hetzner заблокирован» — слишком грубое утверждение. Тема разобрана в [[DPI/subnet-whitelist-blocking-2026|заметке про блок подсетей по белому списку]].

У страницы есть параметры в адресной строке: `timeout` (по умолчанию 15 000 мс) и `host` с `provider` — можно добавить к штатному набору **свой** сервер и увидеть его в общей таблице. Своё положение в сети чекер определяет через публичный сервис статистики RIPE: внешний адрес, номер автономной системы, город.

Ограничение у метода принципиальное: браузерная песочница не даёт задать имя домена в TLS-рукопожатии, поэтому проверить фильтрацию по SNI из вкладки невозможно, а ответы читаются в режиме `no-cors`, то есть без доступа к статусу и телу. Всё, что различает чекер, — «упало мгновенно» против «упало по таймауту».

### dpi-ch: то же самое без песочницы

Утилита `dpi-ch` на Go (сборки под Windows, macOS, Linux, Android через Termux, плюс Docker) снимает браузерные ограничения. В ней четыре проверки: `whoami` (кто вы в сети), `cidrwhitelist` (ограничивает ли цензор соединения по подсетям), `webhost` (комплексная проверка сервисов и провайдеров) и `dns`.

Самое интересное решение — отказ от фиксированного списка целей. Цели задаются **фильтрами**, которые разворачиваются в набор подсетей локально, без обращения к сети: `org("hetzner")` — все подсети организации, `as(24940)` — конкретная автономная система, `country("de","fi")` — страны, `subnet("1.1.1.0/24")`, `host("google.com")`. Фильтры комбинируются: `(org("hetzner","digitalocean") && country("de","fi")) || as(199524, 53667)`. Мотив прямо назван в документации: фиксированный список цензору достаточно один раз внести в белый список, чтобы чекер у всех показывал «чисто», а динамическая выборка у каждого пользователя своя.

Проверка `webhost` идёт по строгому порядку: рукопожатие TLS (при отказе повторяется с чужими именами `cf.com` и `google.com` — если с ними проходит, ставится вердикт «блокировка по SNI»), затем проверка живости `HEAD`-запросом, затем `POST` на 64 КБ для l4-25 с замером скорости в обе стороны, затем «сибирская» проверка.

### «Сибирская» проверка: считают не байты, а соединения

Отдельный тест воспроизводит схему, которую сообщество называет «сибирскими» ограничениями (по региону, где её впервые массово наблюдали; общий разбор поведенческой заморозки — в [[VLESS/dpi-tls-june-2026|парной заметке про июнь 2026]]). Алгоритм читается в `checkers/webhost.go` буквально: сначала запускаются четыре **параллельных** TLS-рукопожатия со случайным именем домена, сразу после — одно контрольное, тоже со случайным именем. Если серия из четырёх падает, а одиночное проходит, ограничение зафиксировано: фильтр реагирует не на содержимое, а на частоту соединений к одному адресу.

Проверка появилась не на пустом месте: публичный разбор июньской схемы на Хабре, по которому сделана [[VLESS/dpi-tls-june-2026|парная заметка]], написан автором этого же набора чекеров — то есть инструмент и описание механизма вышли из одних рук, а не из пересказа чужих наблюдений.

В конфигурации по умолчанию у этой проверки два говорящих параметра: `siberian-conn-count: 4` и `siberian-fingerprint: chrome`, с комментарием, что почерк Chrome версии 133 в «сибирских» ограничениях наблюдался, а почерк Edge — нет. Для остальных проверок по умолчанию как раз выбран Edge. Это тонкая деталь: инструмент вынужден **воспроизводить** уязвимый почерк, иначе он не увидит ограничение, которое по этому почерку и срабатывает.

### Почему «16–20 КБ» стало «l4-25»

В документации `dpi-ch` сформулировано главное уточнение: ограничивается не суммарный объём, а **число переданных пакетов в обе стороны**, обычно около двадцати пяти, и это касается и TCP, и UDP. Отсюда предложение переименовать метод в `l4-25` — по четвёртому уровню модели OSI и числу пакетов. Первичное обсуждение самого явления живёт в [issue #490 у net4people](https://github.com/net4people/bbs/issues/490), где зафиксированы и порог «примерно 15–20 КБ на соединение», и формулировка про 25 пакетов, и способ смягчения — дробить передачу на несколько соединений.

Проверить это руками можно скриптом `utils/l4-25_prober.py`: он отправляет всего 64 байта, но чанками по 2 байта с паузой 50 мс, то есть создаёт много маленьких пакетов при ничтожном объёме. Если соединение умирает на таком трафике — счётчик точно пакетный, а не байтовый.

Второе важное следствие — направление. Автор отмечает, что исходящий трафик ограничивается так же, как входящий, и поэтому проверка «наливом» (мы шлём данные) требует от цели гораздо меньше: достаточно, чтобы хост принял соединение и не закрыл его сам. Это и позволило перевести браузерный чекер на отправку вместо скачивания.

### Поиск белого списка доменов

Четвёртый чекер, `TCP 16-20 DWC`, решает обратную задачу: не «что заблокировано», а «что пропускают». Методика наивная, но воспроизводимая. Нужен свой сервер в «ограниченной» сети — то есть в той, к которой у вашего оператора применяется l4-25, — с HTTPS и самоподписанным сертификатом, отдающий файл не меньше 128 КБ. Дальше скрипт по списку доменов гоняет `curl -k https://<домен>/1MB.bin --resolve <домен>:443:<ваш IP> --range 0-65535`: соединение идёт на **ваш** адрес, но имя домена в рукопожатии подставляется проверяемое. Скачалось 65 535 байт — значит, это имя фильтр пропускает.

Опубликованный результат от 2 июля 2025: из 10 000 популярных доменов в белый список попали 266, то есть 2,66 %. Оговорок к этой цифре две, и обе существенные. Первая: белые списки заметно различаются между операторами, и осмысленно брать пересечение по нескольким сетям. Вторая: по наблюдениям авторов, список строится по схеме `*.domain.com:*`, то есть поддомены найденных доменов тоже проходят.

## rkn-block-checker: вердикт с уровнем уверенности

`MayersScott/rkn-block-checker` (создан 3 мая 2026, MIT, автор — Дмитрий Виноградов) ставится одной командой `pip install rkn-block-checker` и запускается как `rkn-check`; есть локальный веб-дашборд (`rkn-check startweb`, порт 7777) и Docker. О проекте писали в новостях Хабра — [habr.com/ru/news/1031950](https://habr.com/ru/news/1031950/).

Идея проекта сформулирована автором точно: браузер и так сообщает, что сайт не открылся, а ценность — в независимой проверке каждого слоя и указании, **где** сломалось. Порядок проверки для каждого адреса такой:

- [ ] системный резолвер и DoH Cloudflare опрашиваются по одному имени; если система не резолвит, а DoH резолвит — вердикт `DNS` с высокой уверенностью;
- [ ] если оба набора адресов непустые, но не пересекаются — ставится пометка о расхождении (возможна прозрачная подмена), проверка продолжается;
- [ ] TCP на 443: таймаут → `TIMEOUT` с низкой уверенностью, сброс → `TCP RESET` со средней;
- [ ] TLS-рукопожатие: сброс сразу после ClientHello или тихий дроп → `TLS DPI` со средней уверенностью;
- [ ] HTTP: код 451 или совпадение тела с маркерами заглушки («доступ ограничен», «решению роскомнадзора», «единый реестр» и подобными) → `HTTP STUB` с высокой уверенностью.

Отдельно стоит отметить три решения, которые отличают аккуратный инструмент от «нарисуем красным».

**Контрольная группа.** Проверяются два списка: 17 заведомо доступных российских сайтов и 15 заблокированных. Если «белый» список сам падает больше чем наполовину, итоговый вердикт — «inconclusive», с прямым объяснением: без работающей базы нельзя отличить цензуру от сломанного канала. Это ровно та ошибка, которую делают самодельные скрипты: на плохом Wi-Fi они бодро рапортуют о тотальной блокировке.

**Калибровка формулировок.** Знак `✗` ставится только при высокой уверенности (подмена DNS, подтверждённая шифрованным резолвером; код 451; узнаваемая заглушка), а типичные, но неоднозначные признаки получают `~ LIKELY` и оговорку прямо в строке: сброс TLS «соответствует фильтрации по SNI, но не является доказательством», RST «совпадает с инъекцией промежуточного устройства, но занятой сервер тоже шлёт RST».

**Работа над ложными срабатываниями.** В коммите от 12 сентября 2026 добавлена проверка: если сервер ответил кодом 429 (слишком много запросов), а в теле нашлись слова из набора маркеров, это считается антибот-лимитом, а не блокировкой. Там же ослаблена строгая валидация сертификатов, чтобы самоподписанный сертификат не превращался в «блокировку».

Слабое место инструмента — единственный контрольный резолвер. Вся проверка DNS опирается на DoH Cloudflare, и если он у вас недоступен — а такое в 2026 году случалось массово, см. [[DPI/google-dns-8888-block-july-2026|инцидент 3 июля]] — контроль исчезает. Инструмент, впрочем, и это говорит прямо: «DoH lookup failed — control comparison unavailable, DNS poisoning cannot be ruled out».

## Cheburcheck: чужие глаза в других регионах

Все инструменты выше меряют ту точку сети, из которой вы их запустили. `LowderPlay/cheburcheck` (создан 19 ноября 2025, Rust + SvelteKit, BSD-3-Clause) отвечает на вопрос, который локальный чекер задать не может: **а как этот же домен ведёт себя у провайдеров в других регионах**. Работает как сайт [cheburcheck.ru](https://cheburcheck.ru) — ставить ничего не нужно, достаточно ввести домен, адрес, подсеть или номер автономной системы.

![[tspu-inspectors-cheburcheck-ya-ru.png]]

Проверка состоит из двух независимых частей, и на странице они показаны отдельно.

### Статическая часть: списки и реестры

Имя разрешается через шифрованный DNS Quad9 (чтобы локальная подмена не испортила исходные данные), а полученные адреса ищутся в префиксных деревьях по трём наборам данных: диапазоны CDN-провайдеров, выгрузки реестра Роскомнадзора с antifilter и собственный список доменов-исключений. Тут же показываются ASN, организация и расположение.

Публичный API отдаёт ровно то же в JSON: `https://cheburcheck.ru/api/v1/check?target=<домен>`. Для `ya.ru` в ответе, среди прочего, приходит `"whitelist":{"domain":"ya.ru","rank":706,"last_ok":"2026-05-29T…"}` — это и есть плашка «Исключение для CDN блокировки: найден 29.05.2026» на скриншоте. Читается она так: домен входит в перечень имён, при которых ограничение на объём сессии к заблокированным CDN **не применяется**, и в последний раз это подтверждалось замером 29 мая 2026.

Список исключений сервис собирает сам, утилитой Cheburcheck Reporter: она прогоняет топ-100 000 доменов из списка Tranco (до тысячи параллельных запросов) к собственному серверу, который отдаёт больше 64 КБ на любое имя в рукопожатии, и записывает, с какими именами передача доходит до конца. Методика совпадает с [[#Поиск белого списка доменов|поиском белых доменов у dpi-checkers]], но здесь она поставлена на поток, а результат публикуется: выгрузка `https://cheburcheck.ru/whitelist/domains.csv` на 20 сентября 2026 содержит 2138 доменов. Порядок величины тот же, что у DWC: около двух процентов от проверенного топа.

### Динамическая часть: сеть зондов

Вторая половина страницы — таблица «Результаты динамической проверки»: регион, провайдер с номером автономной системы и вердикт. За ней стоит сеть зондов `cheburprobe` — отдельная программа, которую добровольцы ставят у себя (пакет `.deb`, Docker-образ, пакеты OpenWrt с интерфейсом в LuCI, экспериментальная сборка под Windows). Зонд подключается к сервису по MQTT поверх WebSocket, получает задания и возвращает измерения; идентификатор и токен выдаются вручную по письму с указанием региона, провайдера и ASN. Прав администратора он не требует — хватает одной системной возможности `CAP_NET_RAW` для трассировки маршрута.

На каждое задание зонд делает три вещи параллельно.

**SNI-пробы.** Он подключается к набору контрольных хостов сервиса — часть из них заведомо доступна, часть лежит в ограниченных диапазонах CDN, — подставляет в рукопожатие **проверяемое** имя домена и запрашивает файл с заголовком `Range`, чтобы получить строго заданное число байт. Исход каждой пробы — одно из четырёх: соединение не установилось, рукопожатие срезано на ClientHello, данные встали на полпути (в отчёт идёт число полученных байт), всё дошло. Проверка сертификата намеренно отключена: измеряется проходимость, а не доверие.

**Трассировка и поиск узла с фильтром.** Это самая необычная часть. Для каждого значения TTL зонд открывает **новое** TCP-соединение к контрольной цели с заведомо блокируемым именем в рукопожатии, отправляет настоящий ClientHello, ждёт сто миллисекунд (чтобы фильтр успел классифицировать поток), а затем шлёт 256 случайных байт с ограниченным временем жизни пакета и слушает ICMP-ответ «время истекло». Наибольший номер узла, от которого такой ответ ещё приходит, и считается местом, где сидит фильтрующее устройство; трассировку до самой цели зонд начинает уже со следующего узла. Отдельное соединение на каждый TTL нужно потому, что TCP — поток байтов: потерянный сегмент с малым TTL иначе задержал бы последующие записи и retransmit ушёл бы уже с другим временем жизни.

**Проверка DNS.** Четыре провайдера (Google, Cloudflare, Quad9, Яндекс) опрашиваются по четырём протоколам: обычный UDP, TCP, DoH и DoT. Шифрованные ответы служат эталоном, открытые сравниваются с ними, и подмена объявляется только если разошлись ответы **не менее чем у двух** провайдеров. Порог в две независимые сети — защита от ложного срабатывания на обычной ротации адресов у крупных сервисов; в коде на это есть отдельный тест.

### Как читаются вердикты в таблице

Итоговая метка региона собирается из этих измерений по фиксированным правилам, и знание правил меняет чтение таблицы:

| Метка | Когда ставится | О чём говорит |
| --- | --- | --- |
| Блокировка ТСПУ | узел с фильтром найден, а трассировка до самой цели упирается в таймаут | пакеты гибнут за фильтром — блокировка по адресу |
| SNI-блок | большинство заведомо доступных контрольных хостов отвалилось на ClientHello | режется имя домена, а не адрес |
| Подмена DNS | у двух и более провайдеров открытый ответ разошёлся с шифрованным | вмешательство в DNS |
| Исключение для CDN | большинство хостов в ограниченных диапазонах **не** встало на полпути | с этим именем ограничение по объёму снимается |
| Блокировка CDN | цель лежит в списках CDN, а проба ведёт себя как обычно для ограниченной сети | адрес под ковровым ограничением диапазона |
| Неопределённо | ответов не хватило или они противоречивы | вывода нет — не «всё хорошо» |

Обратите внимание на строку «Исключение для CDN» на скриншоте: у `ya.ru` она стоит во всех четырёх регионах, и это не про доступность самого Яндекса. Метка означает, что имя `ya.ru` в рукопожатии снимает ограничение на объём сессии — то есть годится как имя-донор, и ровно по этой причине такие домены интересны при настройке [[#Подбор белого SNI и тест Telegram|белых SNI]].

Главное ограничение сервиса вытекает из его же устройства: он показывает **чужие** сети, а не вашу. Сколько зондов онлайн и в каких они регионах, видно прямо на странице (на скриншоте — четыре в Свердловской, Тюменской областях и Краснодарском крае), и на другом операторе картина может отличаться. Чтобы в этой таблице появилась ваша сеть, нужно поднять у себя зонд и запросить у авторов идентификатор с токеном; для разовой проверки собственного канала быстрее локальный чекер.

## ByeByeVPN: взгляд с другой стороны провода

`pwnnex/ByeByeVPN` (создан 18 апреля 2026, GPL-3.0, версия 2.8.3) отвечает на противоположный вопрос. Все предыдущие инструменты спрашивают «что мой провайдер делает с моими соединениями». Этот спрашивает: **насколько мой сервер похож на VPN, если смотреть на него снаружи, как смотрит цензор**. Подключаться к серверу не нужно — сканер работает как посторонний наблюдатель.

Пайплайн из восьми модулей: разрешение имени, агрегация геоданных по нескольким источникам, скан портов (полный диапазон или 205 отобранных, в 500 потоков), отпечаток TCP-стека, UDP-пробы, отпечатки сервисов с проверкой прозрачности сертификатов, двойная проба TLS с вычислением JA4 и JA4S, активные пробы J3, сверка задержки с заявленной географией, итоговый вердикт.

Две части заслуживают отдельного внимания.

**UDP-пробы под современные туннели.** В версии 2.6.0 из набора убрали OpenVPN, IKEv2, L2TP и подобное — у них фиксированные порты и заголовки, любой DPI ловит их и без сканера. Остались: 148-байтное рукопожатие WireGuard на 51820, дельта-проба AmneziaWG (ванильный WireGuard отвергается, а тот же пакет с восьмибайтовым мусорным префиксом принимается — это и выдаёт обфускацию), перебор размера мусорного префикса в двенадцать шагов для восстановления настроенного параметра `S1`, и QUIC-инициализация Hysteria2 на портах 36712 и 443.

**Пробы J3 против REALITY.** На каждый TLS-порт отправляются восемь разных проб: пустое подключение без единого байта, обычный `GET /`, прокси-запрос `CONNECT`, правдоподобный баннер OpenSSH, 512 случайных байт, ClientHello с несуществующим именем домена в зоне `.invalid`, запрос с абсолютным URI и 128 байт `0xFF`. Диагностический сигнал — не ответ, а **узор**: REALITY и XTLS молча проглатывают все восемь, обычный веб-сервер отвечает ошибками 400/403. С версии 2.7.0 порядок проб перемешивается, потому что фиксированная последовательность сама стала отпечатком сканера.

Итог — оценка от 0 до 100 (`CLEAN` ≥ 85, `NOISY` 70–84, `SUSPICIOUS` 50–69, ниже — «очевидный VPN») и отдельная эмуляция вердикта ТСПУ по двум уровням правил. Уровень A (восемь правил: сигнатура WireGuard, обфусцированный AmneziaWG, Hysteria2, SSTP, штатные порты Shadowsocks, открытый SOCKS5, редирект на страницу-заглушку оператора, полное молчание всех портов без единого RST) даёт «немедленную блокировку». Уровень B — мягкие аномалии: узор cert-steering у REALITY, сертификат, выданный на чужой известный бренд, кластер портов, характерный для установщика 3x-ui или Marzban, сертификат со сроком жизни меньше двух недель, утечка заголовков `Via`/`X-Forwarded-For`, отсутствие сертификата в логах прозрачности, расхождение задержки с заявленной страной. Две аномалии уровня B складываются в «блокировку по накоплению», одна — в «ограничение скорости и наблюдение».

> [!warning] Это модель автора, а не документ регулятора
> Шкала, веса и разбиение правил на уровни — авторская реконструкция того, как мог бы рассуждать классификатор ТСПУ. Сам проект это признаёт: в версии 2.8.1 из набора убрали правило, штрафовавшее адреса вида `10.x.y.z` в трассировке маршрута, — ТСПУ работает прозрачно на сетевом уровне и собственным узлом в трассировке не появляется, а такие адреса означают обычную внутреннюю адресацию оператора. Теперь они показываются как справочная информация без штрафа. Это хороший признак зрелости инструмента: правило, дававшее красивый, но ложный сигнал, удалили, а не оставили ради эффектности.

Полезная деталь для владельцев серверов: отдельная команда аудита читает конфигурации Xray, sing-box и WireGuard/AmneziaWG и указывает на опасные места ещё до сканирования — например, на инбаунд без `reality` и без настоящего сертификата. В репозитории лежат примеры «плохой» и «хорошей» конфигурации.

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

## tspu-checker: полезная шпаргалка со спорными местами

`ku78/tspu-checker` (создан 21 мая 2026, MIT, последнее обновление 8 июня 2026) — набор из трёх скриптов: bash, PowerShell и отдельный вариант для Termux. Интерфейс — меню на семнадцать пунктов, которое запускает готовые команды `ping`, `nc`, `curl`, `dig`, `openssl`, при наличии — `hping3` и `nmap`. Автор описал инструмент в статье на Хабре — [habr.com/ru/articles/1042152](https://habr.com/ru/articles/1042152/), где привёл и свой полевой результат: у мобильного оператора пинг проходил, TCP вставал по таймауту, а внешние DNS не отвечали — картина, которую он трактует как режим белого списка.

Часть проверок здесь действительно полезна и воспроизводима вручную:

- проверка фильтрации по имени домена: `openssl s_client -connect <IP>:443 -servername <домен>` с разбором трёх исходов — пришёл сертификат, пришёл сброс соединения, ничего не пришло;
- сравнение системного `dig` и `dig @1.1.1.1` по одному имени — простейший способ увидеть подмену;
- контрольная группа: одинаковая проверка для заведомо доступного `ya.ru` и для заблокированного `twitter.com`, с разделением DNS, TCP и рукопожатия;
- парные тесты UDP и WireGuard между двумя своими серверами — с их помощью видно, режется ли UDP как класс.

Но три вещи стоит знать до того, как строить выводы на его отчёте.

**Определение «режима ТСПУ» стоит на одном адресе.** Пункт 1 пингует `173.194.222.113` и стучится туда же в порт 443; живой ICMP при мёртвом TCP объявляется «режимом белых списков». Один адрес Google в anycast-сети — слишком узкая база: тот же результат даст локальная маршрутная проблема, фильтрация конкретной подсети или особенность мобильного оператора. Вывод «у меня allowlist» требует как минимум нескольких целей в разных автономных системах — то, что делают dpi-detector и dpi-checkers.

**Пункт «Split DNS/утечка» измеряет не то, что заявляет.** Он берёт `curl -w %{remote_ip}` для `ya.ru` — а это адрес сервера Яндекса, к которому подключился curl, — и сравнивает его с вашим внешним адресом от `ifconfig.me`. Совпадение объявляется утечкой, расхождение — работающим туннелем. Величины разной природы: они и должны различаться при любых настройках, с VPN и без. Проверять утечку нужно сравнением внешнего адреса, который видят два независимых сервиса, а не адреса сервера с адресом клиента.

**Тест WireGuard не запустится.** Скрипт формирует общий ключ как первые 32 шестнадцатеричных символа от `sha256` фиксированной строки. WireGuard ждёт ключ в base64 длиной 44 символа; локальная проверка 20 сентября 2026 подтверждает, что такой ключ отвергается с ошибкой `Key is not the correct length or format`, то есть `wg setconf` не примет конфигурацию.

Вывод по инструменту: как справочник рабочих команд и способ быстро пробежаться по слоям он экономит время, особенно на сервере, где нет Python. Как источник вердиктов — нет: его сильные проверки дублируются более аккуратными инструментами, а слабые дают выводы, которые не следуют из измерений.

## ТСПУ Probe: карманный щуп для своего VLESS

`stpavel/tspu-probe` (создан 2 июня 2026, версия 1.1, Android 7 и новее, root не нужен; README указывает лицензию MIT, отдельного файла лицензии в репозитории нет) решает одну узкую задачу: почему конкретный VPN-сервер не работает именно с этого телефона и этой SIM-карты.

![[tspu-inspectors-tspu-probe-android.png]]

Вводятся адрес сервера, порт и имя домена из конфигурации, дальше приложение идёт по слоям: разрешение имени, ICMP-пинг (через системный бинарник `ping`, потому что стандартный Java-метод проверки доступности без root на Android работает некорректно), TCP-подключение с замером времени оборота, рукопожатие TLS **без** имени домена, рукопожатие с вашим именем, затем перебор списка имён с паузой 600 мс между попытками — пауза специально сделана, чтобы серия не выглядела как сканирование.

Ключ к чтению результата — в том, что именно считается успехом. Если сервер прислал TLS-алерт, приложение засчитывает попытку как успешную: алерт означает, что ClientHello **дошёл** до сервера и фильтр его не срезал. Сброс соединения помечается как `RST`, отсутствие ответа — как таймаут. На скриншоте виден чистый случай: TLS проходит, фильтрации по имени нет, лучшее имя по задержке — `google.com` со 165 мс, диагноз «Сеть в порядке», то есть искать причину надо в конфигурации клиента, а не в сети.

Диагноз выдаётся один из четырёх: TCP заблокирован (совет — сменить порт или уйти на UDP-протоколы), TLS заблокирован целиком (сменить адрес сервера или спрятаться за CDN), фильтрация по имени домена (подставить работающее имя в `serverNames`), сеть чистая.

Два ограничения, о которых стоит помнить. Во-первых, приложение не проверяет ни l4-25, ни UDP, ни подмену DNS: сценарий «TLS проходит, но соединение умирает через несколько секунд после начала передачи» останется за кадром, и для него нужен другой инструмент. Во-вторых, сверка сертификата сделана по полю `CN` из субъекта; у современных сертификатов имя часто указано только в списке `SAN`, и тогда появится предупреждение «SNI не совпадает с cert сервера» на совершенно исправном сервере. Само по себе это предупреждение не означает проблему с фильтрацией.

## Одна блокировка — пять способов её нащупать

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

| Инструмент | Как создаётся нагрузка | Объём | Можно задать SNI | Слепая зона |
| --- | --- | --- | --- | --- |
| Веб-чекер dpi-checkers | `POST` 64 КБ, затем 9 × `HEAD` с 7 КБ в URI | 64 КБ | нет (песочница браузера) | не отличает фильтрацию по имени; нет доступа к статусу ответа |
| DPI Detector | 10 × `HEAD` с заголовком `X-Pad` по 4 КБ в одном keep-alive | до 40 КБ | да | фиксированный список из 110 целей — его можно внести в белый список |
| dpi-ch | один `POST` 64 КБ поверх uTLS с выбранным почерком | 64 КБ | да | требует установки; сложнее в настройке |
| DWC (поиск белых доменов) | `curl --range 0-65535` к **своему** серверу с чужим SNI | 64 КБ | да, это и есть смысл теста | нужен свой сервер в «ограниченной» сети |
| Зонд cheburcheck | `GET` с `Range` к контрольным хостам, имя цели в рукопожатии | до порога хоста | да | меряет сеть зонда, а не вашу |
| `l4-25_prober.py` | 64 байта чанками по 2 байта с паузой | 64 байта | да | ручной, одна цель за запуск |

Отсюда следуют два практических правила. Первое: расхождение между веб-чекером и настольным инструментом на одной и той же сети — не баг, а разные методы; браузерная проба слабее и охотнее ставит «Possible» вместо «Detected». Второе: если вы проверяете не абстрактные хостинги, а **свой** сервер, добавляйте его в проверку явно — через параметр `host` у веб-чекера, через фильтр `subnet("<ваш IP>/32")` у `dpi-ch` или через собственный список целей у DPI Detector.

## Как читать результаты и не обмануться

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

- **Работающий обход.** Zapret, GoodbyeDPI, системный прокси или VPN искажают всё: от задержек до содержимого ClientHello. Выключайте их полностью; для zapret допустим только режим обработки всех пакетов, а не выборочный по списку.
- **Сервер сам отвергает чужое имя.** При проверке фильтрации по SNI подключение идёт на адрес одного сервиса с именем другого. Многие серверы на такое законно отвечают алертом или сбросом — и это не работа фильтра. Достоверный вариант — проверять на **своём** сервере, который отвечает одинаково на любое имя (именно так устроена методика DWC).
- **Anycast и CDN.** Один и тот же домен резолвится в разные адреса в разных сетях и в разное время; «заблокирован» у одного адреса Cloudflare и «чисто» у соседнего — обычная картина, а не противоречие.
- **Одна точка, один момент.** Результат верен для вашего оператора, региона и минуты. Схемы различаются даже между узлами одного оператора и откатываются в течение суток. Частично это лечится взглядом со стороны: таблица регионов у cheburcheck показывает, совпадает ли ваша картина с чужими сетями.
- **Антибот вместо цензуры.** Коды 403 и 429, капчи и страницы защиты выглядят как блокировка. Хорошие инструменты это учитывают (rkn-block-checker отдельно разбирает 429), самописные скрипты — нет.
- **Мобильная сеть.** NAT оператора, шейпинг и агрессивные тайм-ауты дают картину, похожую на фильтрацию. Сравнивайте с проводной сетью, прежде чем делать вывод.
- **«Белый список» ≠ «нет DPI».** Если ваш трафик проходит, это может значить, что вы попали в разрешённый перечень, а не что фильтра нет. Значения термина разобраны в заметке [[Белые списки|Белые списки]].

Если свести наблюдения инструментов к таблице «симптом → механизм → лечение», получится короткая шпаргалка. Она не заменяет измерение, но помогает понять, что делать с полученным вердиктом.

| Что показывают чекеры | Вероятный механизм | Что обычно помогает |
| --- | --- | --- |
| системный DNS не резолвит, DoH резолвит | подмена или перехват DNS | шифрованный резолвер (DoH/DoT), DNS через туннель |
| домен резолвится в один и тот же адрес-заглушку | подмена на страницу оператора | то же самое плюс проверка настроек роутера |
| порт 443 открыт, рукопожатие рвётся с вашим именем домена и проходит с чужим | фильтрация по SNI | смена имени в конфигурации, фрагментация ClientHello |
| рукопожатие рвётся с любым именем, включая пустое | блок по адресу или подсети на уровне TLS | смена адреса сервера, CDN, переход на UDP-протокол |
| ни один порт не отвечает, RST нет вообще | блок по адресу | только смена адреса |
| соединение живёт, но встаёт на 15–25 КБ | l4-25 | дробление потока, поиск имени из белого списка, другой хостинг |
| серия одновременных подключений падает, одиночное проходит | ограничение по частоте соединений | снижение параллелизма, мультиплексирование, смена почерка клиента |
| всё проходит, но VPN всё равно не работает | причина не в сети | проверка конфигурации клиента и сервера, ключей и идентификаторов |

> [!warning] Сканировать можно только своё
> Клиентские чекеры обращаются к чужим публичным сайтам обычными запросами — это ничем не отличается от захода браузером. Сканер `ByeByeVPN` ведёт себя иначе: он перебирает порты, шлёт активные пробы и провоцирует ответы, то есть выполняет полноценное сканирование. Запускайте его **только по своим серверам** или там, где у вас есть явное разрешение владельца. Сами авторы инструментов сопровождают их оговоркой: материалы предназначены для исследовательских и образовательных целей, а ответственность за соблюдение местного законодательства лежит на пользователе.

> [!tip] Порядок, который экономит время
> Сначала быстрый общий снимок: **DPI Detector** с тестами 1–3 — он сразу скажет, что ломается, DNS, TLS или объём. Если проблема на уровне DNS — сверьтесь с [[DPI/tspu-dns-nsdi-dnat-august-2026|разбором перехвата DNS]]. Если подозрение на l4-25 — подтвердите вторым методом через **веб-чекер dpi-checkers**, добавив свой сервер параметром `host`. Если дело в имени домена — подберите рабочее через тест белых SNI у DPI Detector или через **ТСПУ Probe** с телефона (мобильная сеть часто фильтрует иначе). Прежде чем винить свой канал, сверьтесь с чужими: **cheburcheck** по тому же домену покажет, что видят зонды в других регионах, и лежит ли адрес в реестрах и диапазонах CDN. И только после этого запускайте **ByeByeVPN** по своему серверу: он ответит на вопрос, не является ли сервер сам по себе очевидной мишенью.

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

Честная граница применимости важнее списка возможностей.

Ни один из семи не измеряет **поведенческую заморозку во времени** полноценно: `dpi-ch` проверяет реакцию на четыре одновременных рукопожатия, но длительность штрафа, накопление санкций и зависимость от почерка клиента остаются за кадром — это тема отдельных исследований, см. [[VLESS/dpi-tls-june-2026|разбор схемы июня 2026]]. Троттлинг измеряется только частным случаем — тестом Telegram у DPI Detector. UDP покрыт фрагментарно: пробы известных туннелей у ByeByeVPN и утверждение про пакетный счётчик у dpi-checkers, но систематической проверки UDP-фильтрации нет ни у кого. Региональную и операторскую разницу систематически собирает только cheburcheck, да и та ограничена числом добровольцев с зондами: у остальных каждый запуск — одна точка наблюдения, и сравнение делает человек.

И главное: ни один инструмент не имеет доступа к самому оборудованию. Все вердикты — интерпретация симптомов. Формулировки вроде «соответствует фильтрации по SNI» у rkn-block-checker и «эмулированный вердикт» у ByeByeVPN точнее, чем категоричное «заблокировано», и читать их следует именно так.

> [!warning] Статус данных
> Механика блокировок в этой заметке описана по исходному коду перечисленных проектов, их документации и наблюдениям сообщества (обсуждение [net4people/bbs#490](https://github.com/net4people/bbs/issues/490), материалы ntc.party и Хабра). Официальных описаний работы ТСПУ нет; числа вроде «25 пакетов», «12–36 КБ» и «4 соединения» — параметры инструментов и оценки исследователей, а не опубликованные константы системы. Сведения о репозиториях (даты создания, число звёзд, версии) приведены на 20 сентября 2026.

## 📚 См. также

- [[DPI/dpi-analysis-pipeline|Как DPI анализирует соединение: воронка проверок]] — какой признак соединения проверяется на каком этапе
- [[VLESS/dpi-tls-june-2026|Как DPI «замораживает» VLESS+REALITY]] — поведенческая схема, которую нащупывает «сибирская» проверка в dpi-ch
- [[DPI/tspu-dns-nsdi-dnat-august-2026|Перехват DNS на ТСПУ, август 2026]] — что означает «реальный выходной резолвер» в отчёте DPI Detector
- [[DPI/subnet-whitelist-blocking-2026|Блок подсетей по белому списку]] — почему у одного хостера соседние адреса ведут себя по-разному
- [[DPI/tspu-false-blocks-june-2026|Как ТСПУ ломает легитимные сайты]] — сопутствующий ущерб тех же механизмов
- [[DPI/curl-impersonate|curl-impersonate]] — ручная проверка блокировок с подменой почерка браузера
- [[DPI/browser-ja4-fingerprint-block|Блокировка по JA4-отпечатку браузера]] — слой, который измеряет ByeByeVPN через JA4/JA4S
- [[Белые списки|Белые списки]] — три разных значения термина, которые постоянно путают
- 🔗 [github.com/Runnin4ik/dpi-detector](https://github.com/Runnin4ik/dpi-detector) — DPI Detector, сборки и Docker-образы
- 🔗 [github.com/hyperion-cs/dpi-checkers](https://github.com/hyperion-cs/dpi-checkers) — веб-чекеры, `dpi-ch` и методика поиска белых доменов
- 🔗 [hyperion-cs.github.io/dpi-checkers/ru/tcp-16-20](https://hyperion-cs.github.io/dpi-checkers/ru/tcp-16-20/) — проверка l4-25 прямо в браузере
- 🔗 [github.com/MayersScott/rkn-block-checker](https://github.com/MayersScott/rkn-block-checker) — послойная диагностика с уровнями уверенности
- 🔗 [cheburcheck.ru](https://cheburcheck.ru) — проверка домена по реестрам и зондам в регионах; исходники: [github.com/LowderPlay/cheburcheck](https://github.com/LowderPlay/cheburcheck), выгрузка исключений: [cheburcheck.ru/whitelist/domains.csv](https://cheburcheck.ru/whitelist/domains.csv)
- 🔗 [github.com/pwnnex/ByeByeVPN](https://github.com/pwnnex/ByeByeVPN) — сканер детектируемости своего сервера
- 🔗 [github.com/ku78/tspu-checker](https://github.com/ku78/tspu-checker) — bash-меню ручных проверок; разбор автора: [habr.com/ru/articles/1042152](https://habr.com/ru/articles/1042152/)
- 🔗 [github.com/stpavel/tspu-probe](https://github.com/stpavel/tspu-probe) — Android-приложение для диагностики по слоям
- 🔗 [net4people/bbs#490](https://github.com/net4people/bbs/issues/490) — первичное обсуждение блокировки TCP 16-20 / l4-25

---

> [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ
> При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование доступно в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/DPI/tspu-inspectors-checkers-2026.md) · [скачать весь репозиторий одним zip-архивом](https://git.zapret.moe/zapretdiscordyoutube/todo/archive/main.zip).