diff --git a/docs/quick_start.md b/docs/quick_start.md
index d22bf7e..cc4a2e9 100644
--- a/docs/quick_start.md
+++ b/docs/quick_start.md
@@ -74,161 +74,164 @@
проблемы, обход будет работать только для тех программ или ОС, которые сами
реализуют механизмы SecureDNS. Для других программ обход работать не будет.
- Решение проблемы DNS выходит за рамки проекта. Обычно она решается либо
- заменой DNS серверов от провайдера на публичные (`1.1.1.1`, `8.8.8.8`), либо
- в случае перехвата провайдером обращений к сторонним серверам - через
- специальные средства шифрования DNS запросов, такие как `dnscrypt`, `DoT`,
- `DoH`.
-
- Еще один эффективный вариант - использовать ресолвер от yandex
- (`77.88.8.88`) на нестандартном порту `1253`. Многие провайдеры не
- анализируют обращения к DNS на нестандартных портах.
-
- Проверить работает ли этот вариант можно так:
- ```sh
- $ dig -p 53 @77.88.8.88 rutracker.org dig -p 1253 @77.88.8.88 rutracker.org
- ```
-
- Если DNS действительно подменяется, и ответ на эти 2 команды разный, значит
- метод вероятно работает.
-
- В openwrt DNS на нестандартном порту можно прописать в `/etc/config/dhcp`
- таким способом :
-
- ```
- config dnsmasq
- <...>
- list server '77.88.8.88#1253'
- ```
-
- Если настройки IP и DNS получаются автоматически от провайдера, в
- `/etc/config/network` найдите секцию интерфейса `wan` и сделайте так:
-
- ```
- config interface 'wan'
- <...>
- option peerdns '0'
- ```
-
- ```sh
- $ /etc/init.d/network restart
- $ /etc/init.d/dnsmasq restart
- ```
-
- Если это не подходит, можно перенаправлять обращения на UDP и TCP порты `53`
- вашего DNS сервера на `77.88.8.88:1253` средствами `iptables`/`nftables`. В
- `/etc/resolv.conf` нельзя прописать DNS на нестандартном порту.
-
-6. `blockcheck.sh` позволяет выявить рабочую стратегию обхода блокировок По
+ > Решение проблемы DNS выходит за рамки проекта. Обычно она решается либо
+ > заменой DNS серверов от провайдера на публичные (`1.1.1.1`, `8.8.8.8`),
+ > либо в случае перехвата провайдером обращений к сторонним серверам - через
+ > специальные средства шифрования DNS запросов, такие как `dnscrypt`, `DoT`,
+ > `DoH`.
+ >
+ > Еще один эффективный вариант - использовать ресолвер от yandex
+ > (`77.88.8.88`) на нестандартном порту `1253`. Многие провайдеры не
+ > анализируют обращения к DNS на нестандартных портах.
+ >
+ > Проверить работает ли этот вариант можно так:
+ > ```sh
+ > $ dig -p 53 @77.88.8.88 rutracker.org dig -p 1253 @77.88.8.88 rutracker.org
+ > ```
+ >
+ > Если DNS действительно подменяется, и ответ на эти 2 команды разный,
+ > значит метод вероятно работает.
+ >
+ > В openwrt DNS на нестандартном порту можно прописать в `/etc/config/dhcp`
+ > таким способом :
+ >
+ > ```
+ > config dnsmasq
+ > <...>
+ > list server '77.88.8.88#1253'
+ > ```
+ >
+ > Если настройки IP и DNS получаются автоматически от провайдера, в
+ > `/etc/config/network` найдите секцию интерфейса `wan` и сделайте так:
+ >
+ > ```
+ > config interface 'wan'
+ > <...>
+ > option peerdns '0'
+ > ```
+ >
+ > ```sh
+ > $ /etc/init.d/network restart
+ > $ /etc/init.d/dnsmasq restart
+ > ```
+ >
+ > Если это не подходит, можно перенаправлять обращения на UDP и TCP порты
+ > `53` вашего DNS сервера на `77.88.8.88:1253` средствами
+ > `iptables`/`nftables`. В `/etc/resolv.conf` нельзя прописать DNS на
+ > нестандартном порту.
+
+6. `blockcheck.sh` позволяет выявить рабочую стратегию обхода блокировок. По
результатам скрипта нужно понять какой вариант будете использовать : `nfqws`
- или `tpws` И запомнить найденные стратегии.
+ или `tpws` и запомнить найденные стратегии для дальнейшего применения.
Следует понимать, что скрипт проверяет доступность только конкретного
домена, который вы вводите в начале. Вероятно, все остальные домены
блокированы подобным образом, **но не факт**. В большинстве случаев можно
- объединить несколько стратегий в одну универсальную, и это крайне
- желательно. Необходимо понимать как работают стратегии. zapret не может
- пробить блокировку по IP адресу. Для проверки нескольких доменов вводите их
- через пробел.
-
- Сейчас блокираторы ставят на магистральных каналах. В сложных случаях у вас
- может быть несколько маршрутов с различной длиной по ХОПам, с DPI на разных
- хопах. Приходится преодолевать целый зоопарк DPI, которые еще и включаются в
- работу хаотичным образом или образом, зависящим от направления (IP сервера).
- скрипт не всегда может выдать вам в итогах оптимальную стратегию, которую
- надо просто переписать в настройки. В некоторых случаях надо реально думать
- что происходит, анализируя результат на разных стратегиях. Если вы
- применяете большой **TTL**, чтобы достать до магистрала, то не лишним будет
- добавить дополнительный ограничитель `--dpi-desync-fooling`, чтобы не
- сломать сайты на более коротких дистанциях. `md5sig` наиболее совместим, но
- работает **только** на linux серверах. `badseq` может работать только на
- **https** и не работать на **http**. Чтобы выяснить какие дополнительные
- ограничители работают, смотрите результат теста аналогичных стратегий без
- **TTL** с каждым из этих ограничителей.
-
- При использовании `autottl` следует протестировать как можно больше разных
- доменов. Эта техника может на одних провайдерах работать стабильно, на
- других потребуется выяснить при каких параметрах она стабильна, на третьих
- полный хаос, и проще отказаться.
-
- Далее, имея понимание что работает на **http**, **https**, **quic**, нужно
- сконструировать параметры запуска `tpws` и/или `nfqws` с использованием
- мультистратегии. Как работают мультистратегии описано в readme.txt.
-
- Если кратко, то обычно параметры конструируются так:
- ```sh
- "--filter-udp=443 'параметры для quic' <HOSTLIST_NOAUTO> --new
- --filter-tcp=80,443 'обьединенные параметры для http и https' <HOSTLIST>"
- ```
-
- Или так:
- ```sh
- "--filter-udp=443 'параметры для quic' <HOSTLIST_NOAUTO> --new
- --filter-tcp=80 'параметры для http' <HOSTLIST> --new
- --filter-tcp=443 'параметры для https' <HOSTLIST>"
- ```
-
- `<HOSTLIST>` и `<HOSTLIST_NOAUTO>` так и пишутся. Их не надо на что-то
- заменять. Это сделают скрипты запуска, если вы выбрали режим фильтрации по
- хостлистам, и уберут в противном случае. Если для какого-то протокола надо
- дурить все без стандартного хостлиста - просто уберите оттуда `<HOSTLIST>` и
- `<HOSTLIST_NOAUTO>`. Можно писать свои параметры `--hostlist` и
- `--hostlist-exclude` для дополнительных хостлистов или в профилях
- специализаций под конкретный ресурс. В последнем случае стандартный хостлист
- там не нужен. Следует избегать указания собственных параметров `--hostlist`
- на листы из директории ipset. Эта логика включена в `<HOSTLIST>` и
- `<HOSTLIST_NOAUTO>`. Отличие `<HOSTLIST_NOAUTO>` в том, что стандартный
- автолист по этому профилю используется как обычный, то есть без
- автоматического добавления доменов. Однако, добавления в других профилях
- автоматически отражаются во всех остальных.
-
- Если стратегии отличаются по версии ip протокола, и вы не можете их
- обьединить, фильтр пишется так:
- ```sh
- "--filter-l3=ipv4 --filter-udp=443 lпараметры для quic ipv4' <HOSTLIST_NOAUTO> --new
- --filter-l3=ipv4 --filter-tcp=80 'параметры для http ipv4' <HOSTLIST> --new
- --filter-l3=ipv4 --filter-tcp=443 'параметры для https ipv4' <HOSTLIST> --new
- --filter-l3=ipv6 --filter-udp=443 "параметры для quic ipv6" <HOSTLIST_NOAUTO> --new
- --filter-l3=ipv6 --filter-tcp=80 'параметры для http ipv6' <HOSTLIST> --new
- --filter-l3=ipv6 --filter-tcp=443 'параметры для https ipv6' <HOSTLIST>"
- ```
-
- Но здесь совсем "копи-пастный" вариант. Чем больше вы объедините стратегий и
- сократите их общее количество, тем будет лучше.
-
- Если вам не нужно дурение отдельных протоколов, лучше всего будет их убрать
- из системы перехвата трафика через параметры `TPWS_PORTS`,
- `NFQWS_PORTS_TCP`, `NFQWS_PORTS_UDP` и убрать соответствующие им профили
- мультистратегии.
-
- | Протокол | Порт | Примечание |
- |---|---|---|
- | `tcp` | `80` | `http` соединение |
- | `tcp` | `443` | `https` соединение |
- | `udp` | `443` | `quic` соединение |
-
- Если используются методы нулевой фазы десинхронизации (`--mss`, `--wssize`,
- `--dpi-desync=syndata`) и режим фильтрации `hostlist`, то все параметры,
- относящиеся к этим методам, следует помещать в отдельные профили
- мульистратегии, которые получат управление до определения имени хоста.
- Необходимо понимать алгоритм работы мультистратегий. Самым надежным
- вариантом будет дублирование этих параметров на 2 профиля. Какой-нибудь
- сработает в зависимости от параметра `MODE_FILTER`.
-
- ```sh
- "--filter-tcp=80 'параметры для http' <HOSTLIST> --new
- --filter-tcp=443 'параметры для https' --wssize 1:6 <HOSTLIST> --new
- --filter-tcp=443 --wssize 1:6"
- ```
-
- В этом примере `wssize` будет применяться всегда к порту **tcp** `443` вне
- зависимости от параметра `MODE_FILTER`. Хостлист будет игнорироваться, если
- таковой имеется. К **http** применять **wssize** вредно и бессмысленно.
-
- Никто не мешает использовать `tpws` для **http**, `nfqws` для **https**,
- либо комбинировать действие `nfqws` и `tpws` для одного протокола. В текущем
- варианте скриптов запуска это делается максимально гибко и независимо друг
- от друга.
+ объединить несколько стратегий в одну универсальную, и это **крайне
+ желательно**. Необходимо понимать как работают стратегии. zapret **не может
+ пробить блокировку по IP адресу**. Для проверки нескольких доменов вводите
+ их через пробел.
+
+ > Сейчас блокираторы ставят на магистральных каналах. В сложных случаях у
+ > вас может быть несколько маршрутов с различной длиной по ХОПам, с DPI на
+ > разных хопах. Приходится преодолевать целый зоопарк DPI, которые еще и
+ > включаются в работу хаотичным образом или образом, зависящим от
+ > направления (IP сервера). скрипт не всегда может выдать вам в итогах
+ > оптимальную стратегию, которую надо просто переписать в настройки. В
+ > некоторых случаях надо реально думать что происходит, анализируя результат
+ > на разных стратегиях. Если вы применяете большой **TTL**, чтобы достать до
+ > магистрала, то не лишним будет добавить дополнительный ограничитель
+ > `--dpi-desync-fooling`, чтобы не сломать сайты на более коротких
+ > дистанциях. `md5sig` наиболее совместим, но работает **только** на linux
+ > серверах. `badseq` может работать только на **https** и не работать на
+ > **http**. Чтобы выяснить какие дополнительные ограничители работают,
+ > смотрите результат теста аналогичных стратегий без **TTL** с каждым из
+ > этих ограничителей.
+ >
+ > При использовании `autottl` следует протестировать как можно больше разных
+ > доменов. Эта техника может на одних провайдерах работать стабильно, на
+ > других потребуется выяснить при каких параметрах она стабильна, на третьих
+ > полный хаос, и проще отказаться.
+ >
+ > Далее, имея понимание что работает на **http**, **https**, **quic**, нужно
+ > сконструировать параметры запуска `tpws` и/или `nfqws` с использованием
+ > мультистратегии. Как работают мультистратегии описано в readme.txt.
+ >
+ > Если кратко, то обычно параметры конструируются так:
+ > ```sh
+ > "--filter-udp=443 'параметры для quic' <HOSTLIST_NOAUTO> --new
+ > --filter-tcp=80,443 'обьединенные параметры для http и https' <HOSTLIST>"
+ > ```
+ >
+ > Или так:
+ > ```sh
+ > "--filter-udp=443 'параметры для quic' <HOSTLIST_NOAUTO> --new
+ > --filter-tcp=80 'параметры для http' <HOSTLIST> --new
+ > --filter-tcp=443 'параметры для https' <HOSTLIST>"
+ > ```
+ >
+ > `<HOSTLIST>` и `<HOSTLIST_NOAUTO>` так и пишутся. Их не надо на что-то
+ > заменять. Это сделают скрипты запуска, если вы выбрали режим фильтрации по
+ > хостлистам, и уберут в противном случае. Если для какого-то протокола надо
+ > дурить все без стандартного хостлиста - просто уберите оттуда `<HOSTLIST>`
+ > и `<HOSTLIST_NOAUTO>`. Можно писать свои параметры `--hostlist` и
+ > `--hostlist-exclude` для дополнительных хостлистов или в профилях
+ > специализаций под конкретный ресурс. В последнем случае стандартный
+ > хостлист там не нужен. Следует избегать указания собственных параметров
+ > `--hostlist` на листы из директории ipset. Эта логика включена в
+ > `<HOSTLIST>` и `<HOSTLIST_NOAUTO>`. Отличие `<HOSTLIST_NOAUTO>` в том, что
+ > стандартный автолист по этому профилю используется как обычный, то есть
+ > без автоматического добавления доменов. Однако, добавления в других
+ > профилях автоматически отражаются во всех остальных.
+ >
+ > Если стратегии отличаются по версии ip протокола, и вы не можете их
+ > обьединить, фильтр пишется так:
+ > ```sh
+ > "--filter-l3=ipv4 --filter-udp=443 lпараметры для quic ipv4' <HOSTLIST_NOAUTO> --new
+ > --filter-l3=ipv4 --filter-tcp=80 'параметры для http ipv4' <HOSTLIST> --new
+ > --filter-l3=ipv4 --filter-tcp=443 'параметры для https ipv4' <HOSTLIST> --new
+ > --filter-l3=ipv6 --filter-udp=443 "параметры для quic ipv6" <HOSTLIST_NOAUTO> --new
+ > --filter-l3=ipv6 --filter-tcp=80 'параметры для http ipv6' <HOSTLIST> --new
+ > --filter-l3=ipv6 --filter-tcp=443 'параметры для https ipv6' <HOSTLIST>"
+ > ```
+ >
+ > Но здесь совсем "копи-пастный" вариант. Чем больше вы объедините стратегий и
+ > сократите их общее количество, тем будет лучше.
+ >
+ > Если вам не нужно дурение отдельных протоколов, лучше всего будет их
+ > убрать из системы перехвата трафика через параметры `TPWS_PORTS`,
+ > `NFQWS_PORTS_TCP`, `NFQWS_PORTS_UDP` и убрать соответствующие им профили
+ > мультистратегии.
+ >
+ > | Протокол | Порт | Примечание |
+ > |---|---|---|
+ > | `tcp` | `80` | `http` соединение |
+ > | `tcp` | `443` | `https` соединение |
+ > | `udp` | `443` | `quic` соединение |
+ >
+ > Если используются методы нулевой фазы десинхронизации (`--mss`,
+ > `--wssize`, `--dpi-desync=syndata`) и режим фильтрации `hostlist`, то все
+ > параметры, относящиеся к этим методам, следует помещать в отдельные
+ > профили мульистратегии, которые получат управление до определения имени
+ > хоста. Необходимо понимать алгоритм работы мультистратегий. Самым надежным
+ > вариантом будет дублирование этих параметров на 2 профиля. Какой-нибудь
+ > сработает в зависимости от параметра `MODE_FILTER`.
+ >
+ > ```sh
+ > "--filter-tcp=80 'параметры для http' <HOSTLIST> --new
+ > --filter-tcp=443 'параметры для https' --wssize 1:6 <HOSTLIST> --new
+ > --filter-tcp=443 --wssize 1:6"
+ > ```
+ >
+ > В этом примере `wssize` будет применяться всегда к порту **tcp** `443` вне
+ > зависимости от параметра `MODE_FILTER`. Хостлист будет игнорироваться,
+ > если таковой имеется. К **http** применять **wssize** вредно и
+ > бессмысленно.
+ >
+ > Никто не мешает использовать `tpws` для **http**, `nfqws` для **https**,
+ > либо комбинировать действие `nfqws` и `tpws` для одного протокола. В
+ > текущем варианте скриптов запуска это делается максимально гибко и
+ > независимо друг от друга.
7. Запустите скрипт облегченной установки - `install_easy.sh` Выберите `nfqws`
и/или `tpws`, затем согласитесь на редактирование параметров. Откроется