todo/Zapret2/log-analyzer.md

---
date: 2026-07-11
tags:
  - zapret
  - zapret2
  - logs
  - debug
  - troubleshooting
  - gui
aliases:
  - Анализ лога 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](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-архивом доступны в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/Zapret2/log-analyzer.md) · [весь репозиторий](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main).