todo/Zapret2/profile-independence.md
loop-uh baf0091fa3
Some checks failed
Published content check / validate (push) Failing after 17s
git.zapret.moe → git2.zapret.moe во всём хранилище, защита от возврата старых имён
git.zapret.moe в России заблокирован по имени, как и wiki.zapret.moe. Ссылки
на Forgejo во всех заметках, футерах, wizard.html и главной заменены на
git2.zapret.moe (включая закодированные адреса значков shields.io).

Какое имя рабочее, теперь решают реестры хоста /etc/zapret-*-domains.conf через
zapret-site-names: pre-commit хук vault отклоняет добавленные строки с
заблокированным именем, сборка Quartz сама переводит ссылки и baseUrl на
рабочие имена. Правило в AGENTS.md переписано под этот механизм.

scripts/wiki-stats.py: переходы с любых имён вики и git (wikiN, gitN) больше
не считаются внешними сайтами. content-check: проверка зеркал сторонних
проектов узнаёт любое имя git.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-24 15:51:32 -04:00

16 KiB
Raw Permalink Blame History

date tags aliases description
2026-06-28
zapret
zapret2
profile
preset
troubleshooting
Один сайт — один профиль
Одно соединение — один профиль
Профили не влияют друг на друга
Влияют ли профили друг на друга
Влияют ли стратегии друг на друга
Складываются ли стратегии
Включил профиль — сломался другой сайт
Включил исключения — перестал работать YouTube
Влияют ли профили Zapret 2 друг на друга: стратегии не смешиваются, но профили конкурируют за соединение. Почему исключение может «сломать» YouTube.

[!mirror] Резервное зеркало Актуальная версия этой страницы — на основной вики: wiki2.zapret.moe/Zapret2/profile-independence

🧬 Влияют ли профили Zapret 2 друг на друга: одно соединение — один профиль

[!info] О чём заметка Ответ на частый вопрос «как профили и стратегии влияют друг на друга» и на жалобу «включил один профиль — сломался другой сайт». Что такое профиль и пресет — в profile и preset; как движок перебирает профили и почему исключения работают именно так — в exclusions#Как движок выбирает профиль: три факта, без которых исключения не понять.

[!tip] TL;DR

  • Каждое соединение обрабатывает один профиль — первый сверху, чьи фильтры совпали. Стратегии разных профилей на одном соединении не смешиваются и не складываются.
  • Профили конкурируют за соединения: если фильтры двух профилей пересекаются, соединение забирает верхний, а нижний для него не запускается.
  • Отсюда «включил профиль — сломался другой сайт»: новый профиль стоит выше и перехватывает чужие соединения. Чинится порядком профилей и сужением фильтра, а не сменой стратегии.
  • Сайт из нескольких доменов может обслуживаться несколькими профилями сразу: каждое его соединение выбирает профиль отдельно.

Стратегии не смешиваются

profile в Zapret 2 состоит из двух частей: фильтров, которые решают, какой трафик ему достаётся (порты, протокол, списки доменов и IP-адресов), и стратегий, которые решают, что с этим трафиком делать. Когда появляется новое соединение, движок (winws2 на Windows, nfqws2 на Linux) перебирает профили пресета сверху вниз и отдаёт соединение первому, у которого совпали все фильтры. Остальные профили это соединение не обрабатывают вовсе.

Из этого следуют три вещи, о которых часто спрашивают:

  • Два профиля на один сайт не «усиливают» обход. Сработает только верхний; стратегия нижнего для этих соединений не выполнится.
  • Стратегия одного профиля не меняет стратегию другого. Профиль Discord никак не влияет на то, что применится к соединениям YouTube, и наоборот.
  • Комбинировать приёмы можно только внутри одного профиля. Несколько --lua-desync подряд (например, фейк, а за ним разрез) — это одна стратегия одного профиля, и все её части применяются к одному и тому же соединению. Как они выполняются по очереди — в profile#Стратегия: что делать с пакетами и в desync.

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

Где профили всё же пересекаются: конкуренция за соединение

Единственный способ, которым один профиль влияет на другой, — забрать у него соединение. Если фильтры двух профилей подходят к одному и тому же трафику, его получает тот, что выше в списке. Для нижнего профиля это выглядит так, будто соединения не было: его стратегия не запускается, хотя сама по себе исправна.

Со стороны пользователя это выглядит как «профиль A сломал сайт B», хотя стратегии друг друга не касались. Изменилось только то, какой профиль забирает соединения сайта B. Поэтому такие поломки чинят не перебором стратегий, а порядком профилей и фильтрами: как правило, узкий профиль конкретного сайта должен стоять выше широкого, см. profile#Порядок профилей важен.

Оговорка: профиль может смениться посреди соединения

«Одно соединение — один профиль» верно для каждого момента времени, но выбранный профиль иногда меняется по ходу соединения. В самом начале движок ещё не знает ни протокола, ни имени сайта: они появляются только в первом сообщении с данными (для HTTPS — в TLS ClientHello). Профиль, у которого в фильтре есть Zapret/hostlist, до этого момента в выборе не участвует. Поэтому первые пакеты (установка соединения) достаются другому профилю, а когда имя сайта становится известно, движок ищет профиль заново, с самого верха списка, и соединение может перейти к другому профилю. Таких пересмотров бывает не больше двух за соединение (по официальной документации zapret2).

На практике это важно для стратегий, которые работают с самого первого пакета, вроде syndata: они выполнятся в том профиле, который достался соединению до пересмотра, а не в профиле с хостлистом. Подробно — в exclusions#Как движок выбирает профиль: три факта, без которых исключения не понять и в схема обработки трафика.

Сайт — это не одно соединение

Профиль выбирается для каждого соединения отдельно, а браузер открывает к одному сайту десятки соединений: к основному домену, к API, к серверам с картинками и видео. Каждое из них может попасть в свой профиль. Это нормально и даже полезно: поддомену, которому нужна другая стратегия, можно завести отдельный профиль, не трогая остальной сайт. Как найти, к каким доменам ходит сайт и какие из них не проходят, — в find-site-domains.

Пример: включили исключения — перестал работать YouTube

Частый случай из вопросов пользователей. В пресетах есть профили-исключения «Исключения айпи (RU сайты)» и «Исключения домены (RU сайты)» (так они называются с августа 2026). Их стратегия — pass: соединение забирается и отправляется без всякого обхода. Такие профили ставят выше широких профилей с обходом, чтобы российские сайты не проходили через обход, который им вредит. После включения исключений YouTube перестаёт открываться, а после выключения снова работает.

Стратегия YouTube при этом не сломана: она просто не запускается, потому что часть соединений YouTube забирает стоящий выше pass-профиль и отправляет их без обхода, прямо под DPI. Какие соединения он забирает, зависит от его фильтра:

  • Исключение по IP-адресам (ipset). Адрес сервера известен с первого пакета, поэтому такой профиль ловит соединение сразу, ещё до того, как станет известно имя сайта. Если в список «российских» адресов попали подсети, где физически обслуживается видео YouTube (например, кэш-серверы Google, которые стоят внутри сетей российских провайдеров), эти соединения уйдут в pass.
  • Исключение по доменам (hostlist). Оно срабатывает только по имени сайта и захватывает все поддомены записи. Если в список попал слишком общий домен, под исключение могут уйти и адреса, нужные YouTube.

Какой из вариантов сработал в конкретной установке, видно в логе: log-analyzer показывает, какой профиль обработал каждое соединение. Если соединения YouTube приписаны профилю «Исключения…», причина найдена.

[!warning] Исключение отключает обход, а не защищает сайт pass отправляет пойманный трафик как есть. Для незаблокированных сайтов это правильно, но заблокированный ресурс, попавший под исключение, поедет к DPI без обхода и перестанет открываться. Держите в исключениях только то, что действительно должно идти напрямую, и не делайте их фильтр шире нужного. Подробнее — в exclusions.

Как найти, какой профиль перехватывает сайт

  1. Включите debug-лог и откройте сломавшийся сайт. В log-analyzer посмотрите колонку «Профиль» у его соединений: так вы увидите, какой профиль их на самом деле обработал.
  2. Если это не тот профиль, который вы настраивали для сайта, откройте «Настройка пресета → Порядок в пресете» и найдите перехватчик выше по списку.
  3. Посмотрите фильтры перехватчика: порты, Zapret/hostlist, Zapret/ipset. Слишком широкий диапазон портов, большой ipset или общий домен в хостлисте — типичные причины.
  4. Поднимите узкий профиль сайта выше перехватчика или сузьте фильтр перехватчика. Если перехватчик — исключение, уберите из его списка лишнее.
  5. Проверьте результат новым соединением (см. verify-strategy) и снова посмотрите в лог, какой профиль сработал.

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

📚 См. также

  • exclusions — как движок выбирает профиль, профиль pass против exclude-списков и их подводные камни
  • profile — из чего состоит профиль и почему порядок профилей важен
  • filter — порты, протокол, hostlist и ipset, по которым профиль получает соединение
  • схема обработки трафика — путь пакета через движок, включая пересмотр профиля
  • find-site-domains — какие домены сайта не проходят и в какие профили их вписывать
  • log-analyzer — как увидеть, какой профиль обработал соединение
  • add-profile — практика создания профиля под сайт
  • symptom-not-cause — когда сайту нужен pass, а когда обход
  • zapret_not_working — общий чек-лист диагностики

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