# 🔬 Анализ лога 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](https://github.com/bol-van/zapret2/blob/master/docs/manual.md). ## 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|глобальный wf-фильтр]] на все порты, запишите лог с запущенной игрой — таблица соединений покажет все её адреса. ## Откуда берётся debug-лог Движок winws2 умеет писать подробный отладочный вывод в файл — для этого в аргументах должен быть флаг `--debug=@путь_к_файлу`. В Zapret 2 GUI это делается без ручной правки: переключатель debug-лога дописывает в текст [[preset|пресета]] строку вида `--debug=@logs/имя_пресета_debug.log` (имя пресета очищается от небезопасных символов). Пока пресет работает с этим флагом, winws2 пишет в файл каждый перехваченный пакет и все решения по нему. Сам переключатель находится на главной странице **«Управление Zapret 2»**, в блоке **«Дополнительные настройки»** (тот, что с предупреждением «Изменяйте только если знаете что делаете») — тумблер **«Включить лог-файл (--debug)»** с подписью «Записывает логи winws в папку logs» (расположение по версии 21.1.4.2, июль 2026): ![[log-analyzer-07-debug-toggle.png]] После переключения тумблера перезапустите 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|hostlist/ipset]] были подключены. **Пакетные блоки** — основное тело лога. Каждый перехваченный пакет открывается строкой-заголовком `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|hostlist/ipset]]: ``` 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|send, syndata, tls_multisplit_sni, fake, multisplit…]]) и её параметры, включая [[out-range|range_in/range_out]] и [[payload|payload_type]]. Профиль с несколькими функциями занимает несколько строк подряд. Именно отсюда анализатор берёт имена профилей и список подключённых списков. ### Простой блок: пакет прошёл без вмешательства Типичный блок для трафика, не попавшего ни под один профиль: ``` 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|tls_multisplit_sni]] разрезал ClientHello на 14 кусков по вычисленным позициям (вокруг SNI) и отправил их отдельными пакетами, после чего задержанный оригинал окончательно дропнут — его содержимое уже ушло в сеть по частям. Строки `* lua 'имя' : desync` — ровно то, что анализатор собирает в колонку **Lua**. > [!note] Ещё одна «нормальная» причина drop — реассемблирование > Как видно из примера, `drop` получают не только пакеты, заменённые стратегией, но и куски большого ClientHello, которые winws2 задержал до полной сборки (`DELAY desync`), а потом переслал сам (`REPLAYING delayed packet`). Парсер анализатора распознаёт такие строки и не считает их отдельными пакетами — но в сыром логе они выглядят пугающе, если не знать механику. ## Таблица соединений: главный экран После разбора файла сверху появляется сводка (сколько пакетов, соединений, совпадений hostlist/ipset, профилей), а под ней — таблица соединений. Соединение здесь — это все пакеты к одной удалённой стороне: одинаковая тройка «протокол + удалённый IP + удалённый порт». ![[log-analyzer-01-page.png]] Колонки таблицы: | Колонка | Что означает | | ----------------- | ---------------------------------------------------------------------------------------------------- | | Хост | 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)` — ещё один довод именовать профили. ![[log-analyzer-02-named-profiles.png]] Особый случай — `0 (no_action)`: профиль-заглушка, под который попадает трафик, не подошедший ни одному «рабочему» профилю (или намеренно исключённый). Такие пакеты Zapret пропускает без вмешательства. ### Хост и IP в одной строке Раньше при чтении сырого лога приходилось самому выяснять, какому сервису принадлежит IP-адрес. Анализатор избавляет от этого: если в соединении был hostname, он стоит прямо рядом с IP. На скриншоте ниже видно, что `dns.google` по QUIC попал под профиль `7 (youtube.com (QUIC))` через совпадение в `ipset-youtube.txt` — то есть ipset зацепил чужой сервис, и это видно за секунду. ![[log-analyzer-03-quic-drop.png]] Совпадения списков — это отдельная диагностическая золотая жила: колонка «Списки» показывает, **какой именно файл** hostlist/ipset сработал. Если сайт дурится «не тем» профилем — почти всегда причина в том, что его IP оказался в чужом ipset, и здесь это видно явно (например, `kessel-api.parsec.app` попал в `ipset-cloudflare.txt` и обрабатывается профилем `45 (Cloudflare TCP)` — логично, он за Cloudflare). ![[log-analyzer-04-hostname-ip.png]] ## Таблица пакетов: что именно сделал Zapret Клик по строке соединения раскрывает вторую таблицу — все пакеты этого соединения по порядку (при очень длинных соединениях показываются первые 2000 пакетов, об усечении предупреждает заголовок). Колонки: номер пакета, направление (`→ out` / `← in`), длина, TCP-флаги, тип payload (например `tls_client_hello`), профиль (звёздочка `*` — профиль взят из кэша соединения, а не найден заново), **Lua** — какие Lua-функции [[desync|дурения]] реально отработали на этом пакете, TLS-детали и вердикт. ![[log-analyzer-05-packets-lua.png]] Колонка Lua — главное, ради чего стоит открывать попакетный вид: она отвечает на вопрос «а что конкретно сделала моя стратегия?». На скриншоте выше по соединению `kessel-api.parsec.app` видно, что на исходящем SYN отработали `send_45_1` и `syndata_45_2` (номера в имени — это номер профиля и порядковый номер функции), после чего оригинальный SYN получил вердикт `drop`, а следом ушёл настоящий `tls_client_hello` с вердиктом `ok`. ![[log-analyzer-06-packets-chatgpt.png]] А здесь по `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\|windivert-фильтр]] пресета, либо приложение реально ходит на другой IP | Проверьте [[wf\|wf-фильтр]] (входит ли нужный порт), перепроверьте IP через TCPView | | Соединение есть, но профиль `0 (no_action)` | Ни один профиль не зацепил: домена нет в [[filter\|hostlist]], IP нет в ipset, либо hostname не раскрылся и матчить было нечем | Добавьте домен/IP в список своего профиля — пошагово в [[add-profile\|«Как добавить свой профиль»]] | | Профиль **чужой** (не тот, что вы настраивали) | IP попал в чужой [[filter\|ipset]] — колонка «Списки» покажет, какой именно файл его перехватил | Уберите 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|windivert-фильтр]] (`--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|заметке про 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|Фильтры, hostlist и ipset]] — как winws2 решает, под какой профиль отдать соединение - [[desync|Десинхронизация]] — что делают Lua-функции из попакетной таблицы - [[verify-strategy|Как проверить, заработала ли стратегия]] — честная проверка результата перед тем, как лезть в логи - [[symptom-not-cause|«Не работает» — это симптом]] — с чего начинать диагностику - [[add-profile|Как добавить свой профиль]] — где задаются имена профилей, которые анализатор потом показывает - [[find-game-strategy|Как найти стратегию для игры]] — весь цикл подбора: профиль под игру, перебор стратегий, TCPView как классический способ сбора адресов - [[Создание своей категории]] — TCPView и Wireshark подробно: сбор доменов, IP и UDP-портов ресурса - [[wf|windivert-фильтр (wf)]] — почему трафика может вообще не быть в логе и как правильно перечислять порты - 🔗 [Документация zapret2](https://github.com/bol-van/zapret2/blob/master/docs/manual.md) — формат и флаги движка из первых рук --- > [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ > При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование и скачивание всего репозитория одним zip-архивом доступны на GitHub: [исходник этой заметки](https://github.com/youtubediscord/todo/blob/main/Zapret2/log-analyzer.md) · [весь репозиторий](https://github.com/youtubediscord/todo/tree/main).