todo/Zapret2/log-analyzer.md

date	tags	aliases
2026-07-11	zapret zapret2 logs debug troubleshooting gui	Анализ лога winws2 Как читать логи запрета Debug-лог winws2 Страница анализа логов Что блочится в логе Какой профиль сработал Почему drop в логе

🔬 Анализ лога winws2: как читать debug-лог через GUI

[!info] О чём заметка В Zapret 2 GUI (раздел «Диагностика», с версии 21.1.4.0, июль 2026) есть страница «Анализ лога winws2»: она разбирает debug-лог движка winws2 и показывает его человеческим языком — какие были соединения, какой profile на них сработал, какие hostlist/ipset совпали и какой вердикт получил каждый пакет. Так preset можно анализировать по фактам, а не гадать. Как честно проверять результат смены стратегии — в verify-strategy; почему «не работает» — симптом, а не диагноз — в symptom-not-cause.

[!warning] Источник сведений Разбор основан на исходном коде Zapret 2 GUI и наблюдениях за версией 21.1.4.0 (июль 2026). Формат debug-лога задаёт сам winws2 и он может меняться в новых версиях — при расхождениях доверяйте свежему логу и официальной документации zapret2.

TL;DR

• Debug-лог включается строкой --debug=@logs/<имя_пресета>_debug.log в тексте preset; GUI умеет добавлять её сам, и тогда лог со стабильным именем появляется в папке logs.
• Страница «Анализ лога winws2» сворачивает тысячи строк лога в таблицу соединений: хост, IP, порт, протокол, сработавший profile, счётчики пакетов и вердиктов, совпавшие списки.
• Если профилям в пресете даны названия, анализатор подхватывает их из лога и показывает вместо голых номеров — сразу видно «7 (youtube.com QUIC)» вместо безликого «7».
• Если у соединения был hostname (из TLS ClientHello или QUIC), он показывается рядом с IP — не нужно вручную выяснять, чей это адрес.
• Клик по соединению раскрывает попакетную таблицу: направление, TCP-флаги, тип payload, какие Lua-функции реально сделали desync и вердикт каждого пакета.
• Красный drop на исходящем SYN или ClientHello — это обычно нормальная работа стратегии (оригинал заменён поддельными пакетами), а не ошибка.
• Анализатор — ещё и способ собрать IP и порты игры вместо Wireshark/TCPView (особенно для UDP, где TCPView не показывает удалённые адреса): временно расширьте wf на все порты, запишите лог с запущенной игрой — таблица соединений покажет все её адреса.

Откуда берётся debug-лог

Движок winws2 умеет писать подробный отладочный вывод в файл — для этого в аргументах должен быть флаг --debug=@путь_к_файлу. В Zapret 2 GUI это делается без ручной правки: переключатель debug-лога дописывает в текст preset строку вида --debug=@logs/имя_пресета_debug.log (имя пресета очищается от небезопасных символов). Пока пресет работает с этим флагом, winws2 пишет в файл каждый перехваченный пакет и все решения по нему.

Сам переключатель находится на главной странице «Управление Zapret 2», в блоке «Дополнительные настройки» (тот, что с предупреждением «Изменяйте только если знаете что делаете») — тумблер «Включить лог-файл (--debug)» с подписью «Записывает логи winws в папку logs» (расположение по версии 21.1.4.2, июль 2026):

!

После переключения тумблера перезапустите Zapret (примените пресет заново) — флаг --debug попадает в аргументы winws2 только при старте движка, на уже запущенный процесс переключатель не действует.

Страница анализа сама подтягивает свежие логи из папки logs в выпадающий список. Она ищет только файлы с выводом winws2: <пресет>_debug.log (стабильное имя по пресету), устаревшие zapret_winws2_debug_*.log и orchestra_*.log (сырой вывод оркестратор). Файл можно и просто перетащить мышью на страницу (.log или .txt).

[!danger] Не тот лог — не тот формат Файлы zapret_log_*.txt — это логи самого GUI (кнопки, статусы, ошибки интерфейса), а не вывод winws2. Парсер их не поймёт и честно скажет: «В файле не найдено пакетных блоков — это debug-лог winws2?». То же касается tg_proxy.log и crashes.log.

[!note] Debug-лог — временный инструмент Лог пишет каждый пакет и растёт очень быстро. Включайте его на время диагностики, воспроизводите проблему (открывайте сайт, запускайте приложение), затем выключайте — иначе файл раздуется на сотни мегабайт.

Как устроен сам лог (что именно парсится)

Debug-лог winws2 состоит из двух частей.

Преамбула — то, что движок печатает при старте: список профилей с их Lua-функциями (profile 7 (youtube.com (QUIC)) lua ...) и загруженные списки (Loaded 1234 hosts from ... / Loaded 567 ip/subnets from ...). Отсюда анализатор узнаёт имена профилей и какие filter были подключены.

Пакетные блоки — основное тело лога. Каждый перехваченный пакет открывается строкой-заголовком packet: id=N len=... outbound|inbound ..., дальше идут строки деталей (IP-адреса и порты, поиск профиля, проверки hostlist/ipset, распознанный протокол уровня приложения, TLS-детали, применённые Lua-функции), а закрывается блок строкой-вердиктом: packet: id=N reinject unmodified, reinject modified или drop.

Проще говоря: winws2 для каждого пакета записывает мини-протокол «что за пакет → под какой профиль попал → что с ним сделали → чем закончилось», а страница анализа собирает эти мини-протоколы в таблицы. Как эти строки выглядят живьём — в следующем разделе.

Сырой лог: реальный пример по строчкам

Выдержки ниже — из настоящего debug-лога пресета с игровым фильтром (июль 2026). Короткая сессия дала файл на 43 000 строк (~2,9 МБ) — наглядная иллюстрация, почему debug-лог включают только на время диагностики. Длинные строки сокращены троеточием ....

Преамбула: что загрузилось при старте

Первым делом winws2 отчитывается о загруженных ресурсах: blob (бинарные заготовки поддельных пакетов), затем перечисляет каждый профиль с его Lua-функциями и параметрами, затем — загруженные filter:

read 681 bytes from 'bin/tls_clienthello_www_google_com.bin'. offset=0
read 1200 bytes from 'bin/fake_quic.bin'. offset=0
...
we have 67 user defined desync profile(s) and default low priority profile 0
profile 1 (chatgpt) lua send(repeats="2" range_in=x0-x0 range_out=a0-d8 payload_type= all)
profile 1 (chatgpt) lua syndata(blob="tls_google" range_in=x0-x0 range_out=a0-d8 payload_type= all)
profile 1 (chatgpt) lua tls_multisplit_sni(seqovl_pattern="tls_google",seqovl="652" range_in=x0-x0 range_out=a0-d8 payload_type= all)
...
Loaded 117132 hosts from /lists/russia-blacklist.txt
Loaded 4 hosts from /lists/amazon.txt

Каждая строка profile N (имя) lua функция(параметры) — это одна Lua-функция профиля: видно имя профиля (в скобках), саму функцию (desync) и её параметры, включая out-range и payload. Профиль с несколькими функциями занимает несколько строк подряд. Именно отсюда анализатор берёт имена профилей и список подключённых списков.

Простой блок: пакет прошёл без вмешательства

Типичный блок для трафика, не попавшего ни под один профиль:

packet: id=0 len=969 outbound IPv6=0 IPChecksum=1 TCPChecksum=0 UDPChecksum=1 IfIdx=20.0
IP4: 192.168.1.x => 31.77.140.129 proto=tcp ttl=128 sport=18131 dport=443 flags=A seq=... ack_seq=...
TCP: len=917 : 09 5B A2 59 79 64 30 5C ... (hex-дамп содержимого)
client mode desync profile/ipcache search target ip=31.77.140.129 port=443
desync profile search for tcp ip=31.77.140.129 port=443 icmp=255:255 l7proto=unknown ssid='' hostname=''
* ipset check for profile 3 (AnyDesk TCP)
[/lists/ipset-anydesk.txt] include ipset check for 31.77.140.129 : negative
* ipset check for profile 45 (Cloudflare TCP)
[/lists/ipset-cloudflare.txt] include ipset check for 31.77.140.129 : negative
... (ещё полтора десятка ipset-проверок, все negative)
desync profile 0 (no_action) matches
dpi desync src=192.168.1.x:18131 dst=31.77.140.129:443 ... connection_proto=unknown payload_type=unknown
no lua functions in this profile
fixing tcp checksum
packet: id=0 reinject unmodified

Читается сверху вниз: заголовок блока (packet: id=0 len=969 outbound) → адреса и порты (IP4: ... =>) → поиск профиля. winws2 прогоняет IP пакета по ipset каждого профиля, у которого такой фильтр есть, и пишет результат каждой проверки (negative — не совпало, positive — совпало). Здесь всё negative, поэтому пакет достаётся профилю-заглушке 0 (no_action) — «Lua-функций нет, отдать как есть», и блок закрывается вердиктом reinject unmodified.

Обратите внимание, сколько строк ушло на пакет, с которым ничего не сделали, — вот эти простыни фильтр «Только modified/drop» в анализаторе и отсекает.

Полный блок: chatgpt.com от опознания до дурения

А это самый интересный сценарий — тот самый, который в попакетной таблице анализатора выглядит как drop с Lua-функциями. Браузер отправил TLS ClientHello размером больше одного пакета, и winws2 пришлось собрать его из двух кусков (реассемблирование). Первый кусок:

packet: id=283 len=1340 outbound ...
IP4: 192.168.1.x => 31.77.140.129 proto=tcp ttl=128 sport=21668 dport=443 flags=A ...
TCP: len=1288 : 16 03 01 06 01 ... (начало TLS ClientHello)
using cached desync profile 0 (no_action)
packet contains tls_client_hello payload
TLS client hello is PARTIAL
starting reassemble. now we have 1288/1542
DELAY desync until reasm is complete (#1)
packet: id=283 drop

winws2 видит начало ClientHello (PARTIAL), задерживает решение (DELAY desync) и дропает оригинал — он будет отправлен позже. Второй кусок докладывает недостающие байты (now we have 1542/1542, TLS client hello is FULL), и начинается разбор уже полного рукопожатия:

TLS record layer version : TLS 1.0
TLS handshake version : TLS 1.2
TLS supported versions ext : TLS 1.3
TLS ALPN ext : not present
TLS ECH ext : not present
hostname: chatgpt.com
hostname cached (is_ip=0): chatgpt.com
desync profile search for tcp ip=31.77.140.129 port=443 ... l7proto=tls ssid='' hostname='chatgpt.com'
* hostlist check for profile 1 (chatgpt)
[/lists/chatgpt.txt] include hostlist check for chatgpt.com : positive
desync profile 1 (chatgpt) matches
desync profile changed by revealed l7 protocol or hostname !

Вот ключевой момент всей механики: пока hostname не был известен, соединение сидело на кэшированном профиле 0 (no_action). Как только из ClientHello извлёкся SNI chatgpt.com, прошла проверка по hostlist (positive), и профиль соединения сменился на лету — об этом прямо говорит строка desync profile changed by revealed l7 protocol or hostname !. Поэтому в попакетной таблице анализатора у одного соединения первые пакеты могут идти под 0 (no_action), а профиль с именем появляется только с пакета, где раскрылся hostname.

Дальше отрабатывают Lua-функции профиля — по каждой видно, прошла ли она свои фильтры и что именно отправила:

* lua 'send_1_1' : payload_type 'tls_client_hello' satisfy filter
* lua 'send_1_1' : desync
* lua 'tls_multisplit_sni_1_3' : desync
LUA: tls_multisplit_sni: resolved split pos: 1 151 152 153 154 156 157 158 159 160 165 166 167
LUA: tls_multisplit_sni: sending part 14 167-1541 len=1375 seqovl=0
LUA: tls_multisplit_sni: sending part 13 166-166 len=1 seqovl=0
... (все куски по очереди, в обратном порядке)
DROPPING delayed packet #1

multisplit разрезал ClientHello на 14 кусков по вычисленным позициям (вокруг SNI) и отправил их отдельными пакетами, после чего задержанный оригинал окончательно дропнут — его содержимое уже ушло в сеть по частям. Строки * lua 'имя' : desync — ровно то, что анализатор собирает в колонку Lua.

[!note] Ещё одна «нормальная» причина drop — реассемблирование Как видно из примера, drop получают не только пакеты, заменённые стратегией, но и куски большого ClientHello, которые winws2 задержал до полной сборки (DELAY desync), а потом переслал сам (REPLAYING delayed packet). Парсер анализатора распознаёт такие строки и не считает их отдельными пакетами — но в сыром логе они выглядят пугающе, если не знать механику.

Таблица соединений: главный экран

После разбора файла сверху появляется сводка (сколько пакетов, соединений, совпадений hostlist/ipset, профилей), а под ней — таблица соединений. Соединение здесь — это все пакеты к одной удалённой стороне: одинаковая тройка «протокол + удалённый IP + удалённый порт».

!

Колонки таблицы:

Колонка	Что означает
Хост	hostname, если он встретился в логе (SNI из TLS ClientHello, QUIC или строка hostname:); иначе —
IP / Порт / Proto	удалённый адрес, порт и транспортный протокол (tcp/udp)
L7	распознанный протокол уровня приложения: tls, quic, http
Профиль	номер и имя profile, который winws2 подобрал для соединения
Пакеты (out/in)	всего пакетов и раздельно исходящие/входящие
Вердикты	счётчики по цветам: зелёный ok, оранжевый mod, красный drop (подробнее ниже)
Списки	имена файлов filter, проверка по которым дала совпадение

Над таблицей — фильтры: поиск по хосту или IP, «Только с hostname» и «Только modified/drop». Последний — самый полезный при разборе пресета: он оставляет только те соединения, которые Zapret реально трогал, и отсекает фон из «прошло насквозь без изменений».

Названия профилей подхватываются сами

Если при настройке пресета вы дали профилям осмысленные имена (см. add-profile), в логе и в анализаторе они видны как есть: 7 (youtube.com (QUIC)), 3 (AnyDesk TCP), 45 (Cloudflare TCP). Безымянный профиль показывается как N (noname) — ещё один довод именовать профили.

!

Особый случай — 0 (no_action): профиль-заглушка, под который попадает трафик, не подошедший ни одному «рабочему» профилю (или намеренно исключённый). Такие пакеты Zapret пропускает без вмешательства.

Хост и IP в одной строке

Раньше при чтении сырого лога приходилось самому выяснять, какому сервису принадлежит IP-адрес. Анализатор избавляет от этого: если в соединении был hostname, он стоит прямо рядом с IP. На скриншоте ниже видно, что dns.google по QUIC попал под профиль 7 (youtube.com (QUIC)) через совпадение в ipset-youtube.txt — то есть ipset зацепил чужой сервис, и это видно за секунду.

!

Совпадения списков — это отдельная диагностическая золотая жила: колонка «Списки» показывает, какой именно файл hostlist/ipset сработал. Если сайт дурится «не тем» профилем — почти всегда причина в том, что его IP оказался в чужом ipset, и здесь это видно явно (например, kessel-api.parsec.app попал в ipset-cloudflare.txt и обрабатывается профилем 45 (Cloudflare TCP) — логично, он за Cloudflare).

!

Таблица пакетов: что именно сделал Zapret

Клик по строке соединения раскрывает вторую таблицу — все пакеты этого соединения по порядку (при очень длинных соединениях показываются первые 2000 пакетов, об усечении предупреждает заголовок). Колонки: номер пакета, направление (→ out / ← in), длина, TCP-флаги, тип payload (например tls_client_hello), профиль (звёздочка * — профиль взят из кэша соединения, а не найден заново), Lua — какие Lua-функции desync реально отработали на этом пакете, TLS-детали и вердикт.

!

Колонка Lua — главное, ради чего стоит открывать попакетный вид: она отвечает на вопрос «а что конкретно сделала моя стратегия?». На скриншоте выше по соединению kessel-api.parsec.app видно, что на исходящем SYN отработали send_45_1 и syndata_45_2 (номера в имени — это номер профиля и порядковый номер функции), после чего оригинальный SYN получил вердикт drop, а следом ушёл настоящий tls_client_hello с вердиктом ok.

!

А здесь по chatgpt.com на пакете-SYN сработала связка send_1_1, syndata_1_2, tls_multisplit_sni_1_3 профиля 1 (chatgpt) — и снова drop оригинала. Так за пару кликов видно и профиль, и полный набор применённых техник, без чтения тысяч строк сырого лога.

Как читать вердикты (и почему drop — это часто хорошо)

Вердикт — это то, чем winws2 закончил обработку пакета:

Вердикт	В логе	Смысл
ok (зелёный)	reinject unmodified	пакет вернули в сеть как был, без изменений
mod (оранжевый)	reinject modified	пакет вернули изменённым (что-то в нём подправили)
drop (красный)	drop	оригинальный пакет не был отправлен

Интуиция подсказывает, что красный drop — это плохо. В debug-логе — чаще всего наоборот. Многие техники desync (например syndata или multisplit) работают так: вместо оригинального пакета Zapret отправляет свои — поддельные, порезанные или дополненные, — а сам оригинал после этого дропает, потому что его содержимое уже ушло в сеть в другом виде. Поэтому drop на исходящем SYN или ClientHello, рядом с которым в колонке Lua перечислены функции стратегии, — это след нормальной работы профиля, а не потеря данных. Вторая безобидная причина drop — реассемблирование большого ClientHello: winws2 задерживает его куски до полной сборки и потом отправляет сам (разобрано на живом примере в разделе log-analyzer#Полный блок: chatgpt.com от опознания до дурения).

Проще говоря: смотрите не на цвет вердикта сам по себе, а на связку «направление + Lua + вердикт». Исходящий пакет + сработавшие Lua-функции + drop = стратегия применилась. А вот если соединение состоит из одних drop без Lua и сайт не открывается — вот это уже повод разбираться.

Запрет не работает? Найдите свой домен или IP в логе

Когда сайт или приложение не открывается, обычный путь — перебирать стратегии наугад. Анализ лога позволяет вместо гаданий получить факт: видит ли Zapret этот трафик вообще, тем ли profile он обрабатывается и отработала ли стратегия. Это один из самых быстрых способов сузить проблему — почему «не работает» — это симптом с десятком возможных причин, разобрано в symptom-not-cause.

Порядок действий:

• Включите debug-лог пресета и перезапустите Zapret.
• Воспроизведите проблему новым соединением: окно инкогнито / Ctrl+F5, а для приложения — полный перезапуск с выходом из трея (почему это важно — в verify-strategy).
• Выключите debug-лог и откройте файл на странице «Анализ лога winws2».
• Найдите проблемный ресурс поиском: сначала по домену, а если у соединения не было hostname — по IP. IP приложения или игры можно подсмотреть через TCPView (как именно — в find-game-strategy).

Дальше сам результат поиска говорит, где проблема:

Что видите в анализаторе	Что это значит	Что делать
Домена/IP нет вообще	winws2 этот трафик даже не перехватывает: порт или протокол не попадает под wf пресета, либо приложение реально ходит на другой IP	Проверьте wf (входит ли нужный порт), перепроверьте IP через TCPView
Соединение есть, но профиль 0 (no_action)	Ни один профиль не зацепил: домена нет в filter, IP нет в ipset, либо hostname не раскрылся и матчить было нечем	Добавьте домен/IP в список своего профиля — пошагово в add-profile
Профиль чужой (не тот, что вы настраивали)	IP попал в чужой filter — колонка «Списки» покажет, какой именно файл его перехватил	Уберите IP из чужого списка, сузьте чужой ipset или перенесите домен в профиль с большим приоритетом
Профиль ваш, Lua-функции в пакетах отработали, но ресурс не открывается	Zapret всё сделал как задумано — просто стратегия не пробивает DPI	Менять саму desync (вручную или через Blockcheck) и перепроверять по verify-strategy
Пакеты только исходящие, входящих 0 (N (N/0))	Ответы от сервера не доходят вовсе — похоже на блокировку по IP или проблему маршрута, а не на DPI	Дурение тут может не помочь; проверьте ресурс без Zapret, с VPN, с другого DNS

Проще говоря: таблица соединений отвечает на вопрос «тем ли профилем ловится трафик», попакетная таблица — «сделала ли стратегия то, что должна», а отсутствие ресурса в логе — «видит ли Zapret этот трафик вообще». Три разных причины «не работает» — и все различаются за пару минут вместо слепого перебора стратегий.

[!tip] Быстрый фильтр при разборе Включите «Только modified/drop» — останутся лишь соединения, которые Zapret реально трогал. Если проблемный ресурс из списка исчез — он не дурится (профиль 0 (no_action) или его нет в логе), и дальше работайте по первой–второй строке таблицы выше.

Анализатор вместо Wireshark и TCPView: собрать адреса и порты игры

Классический путь собрать адреса игры или приложения для своего profile — TCPView и Wireshark (пошагово — в find-game-strategy и Создание своей категории). Но у обоих инструментов есть неудобства. Wireshark требует освоить фильтры захвата и не утонуть в потоке чужих пакетов — для разовой задачи это ощутимый порог входа. TCPView плохо дружит с UDP: протокол безсоединительный, и удалённый адрес у UDP-сокетов в таблице часто пуст (*) — как раз игровой трафик реального времени (матчи, голос) TCPView толком не показывает.

Анализатор лога даёт третий способ, без стороннего софта: winws2 и так перехватывает пакеты и знает про каждый точный IP, порт и протокол — debug-лог всё это фиксирует, а страница «Анализ лога winws2» сворачивает в таблицу соединений. Достаточно записать лог с запущенной игрой — и адреса снимаются прямо из таблицы, включая UDP. Бонус, которого нет в TCPView вовсе: у TLS/QUIC-соединений лаунчера и авторизации в таблице виден hostname — домены для hostlist собираются тем же заходом.

Главное условие: расширить глобальный wf-фильтр

В лог попадает только то, что winws2 вообще перехватил, а перехват определяет wf (--wf-tcp-out/--wf-udp-out) в шапке preset. Обычный пресет чаще всего слушает узкий набор портов (например, 80 и 443) — игровой трафик на порты вроде 27000–28000 идёт мимо winws2 и в логе не появится, сколько его ни записывай.

Проще говоря: анализатор показывает не «весь трафик компьютера», как Wireshark, а только то, что Zapret перехватил. С узким wf-фильтром лог по игре будет пустым — сначала расширяем перехват, потом пишем лог.

Расширить перехват на время диагностики можно двумя способами:

• Правкой пресета: в его тексте выставить --wf-tcp-out=80,443-65535 и --wf-udp-out=443-65535. Все порты перечисляются в одном флаге через запятую — повторный --wf-tcp-out не добавляет порты, а молча перезаписывает предыдущий (разбор этих граблей — в wf).
• Готовым пресетом из раздела «ALL TCP & UDP» — там wf уже открыт на всю ширину (его устройство разобрано в find-game-strategy).

Порядок действий

• Расширьте wf-фильтр пресета (или включите пресет «ALL TCP & UDP») и включите debug-лог.
• Перезапустите Zapret, затем полностью перезапустите игру с лаунчером (вплоть до выхода из трея — verify-strategy) и погоняйте её по всем режимам: логин, магазин, матч, голосовой чат — разные функции ходят на разные адреса.
• Выключите debug-лог (иначе на широком wf он раздуется особенно быстро) и откройте файл на странице «Анализ лога winws2».
• Найдите соединения игры в таблице. Признаки: нестандартные высокие порты, протокол udp, L7 unknown, hostname отсутствует — а у лаунчера, наоборот, TLS-соединения с узнаваемыми доменами.
• Выпишите IP (и домены, если были) в ipset/hostlist своего профиля — дальше по обычной схеме подбора: add-profile, find-game-strategy.

[!warning] Анализатор не знает, чей это трафик В debug-логе нет имени процесса — в отличие от TCPView, где каждое соединение привязано к программе. Лог собирает трафик всей системы, поэтому на время записи закройте лишнее (браузер, торренты, мессенджеры), чтобы фон не смешивался с игрой, и сопоставляйте соединения по портам и диапазонам IP.

После подбора: порты игры должны остаться в wf

Частая ошибка на финише: профиль игры собран, стратегия найдена на широком пресете, но после возврата на повседневный пресет игра снова падает. Причина та же, что и с пустым логом: если постоянный пресет слушает только 80/443, трафик игры на нестандартных портах не доходит до winws2, и профиль с идеально заполненным ipset просто не срабатывает. Поэтому найденные порты игры нужно добавить в --wf-tcp-out/--wf-udp-out постоянного пресета (через запятую к уже имеющимся) — и продублировать в --filter-tcp/--filter-udp самого профиля.

📚 См. также

• profile — что именно подбирается для каждого соединения и почему у него есть номер и имя
• preset — где живёт строка --debug=@... и сами профили
• filter — как winws2 решает, под какой профиль отдать соединение
• desync — что делают Lua-функции из попакетной таблицы
• verify-strategy — честная проверка результата перед тем, как лезть в логи
• symptom-not-cause — с чего начинать диагностику
• add-profile — где задаются имена профилей, которые анализатор потом показывает
• find-game-strategy — весь цикл подбора: профиль под игру, перебор стратегий, TCPView как классический способ сбора адресов
• Создание своей категории — TCPView и Wireshark подробно: сбор доменов, IP и UDP-портов ресурса
• wf — почему трафика может вообще не быть в логе и как правильно перечислять порты
• 🔗 Документация zapret2 — формат и флаги движка из первых рук

---

[!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование и скачивание всего репозитория одним zip-архивом доступны в Forgejo: исходник этой заметки · весь репозиторий.