🧬 Профили и стратегии не влияют друг на друга: один сайт — один профиль

О чём заметка

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

TL;DR

  • На одно соединение к сайту работает ровно один профиль — первый сверху, чей фильтр (порты + hostlist/ipset) совпал. Остальные профили этот трафик не трогают.
  • Стратегии не складываются. Нельзя «усилить» обход, включив два профиля на один сайт — возьмётся один (верхний). Комбинация приёмов внутри одного профиля (fake+split и т.п.) — это другое, см. desync.
  • Профили не правят стратегию друг друга. Профиль Discord никак не меняет то, что применится к YouTube.
  • Единственное взаимодействие — конкуренция за трафик. Если фильтры двух профилей пересекаются, верхний перехватывает соединение, а нижний для него просто не запускается. Это не «влияние стратегии на стратегию», а «кто первый поймал пакет».
  • Поэтому «включил профиль/исключение — сломался другой сайт» — не глюк, а перехват по порядку (first-match-wins). Разбор ниже.

Два разных вопроса, которые постоянно путают

ВопросОтвет
Смешиваются ли стратегии разных профилей на одном соединении?Нет. Одно соединение → один профиль → одна стратегия.
Может ли стратегия соседнего профиля «помешать» моему сайту?Нет. Сама стратегия не утекает в чужой трафик.
Может ли включение одного профиля изменить судьбу другого сайта?Да — но не стратегией, а перехватом трафика по порядку/фильтру.

Первые две строки — это и есть «профили не влияют друг на друга». Третья — единственная оговорка, и она про фильтры и порядок, а не про стратегии.

Почему «не влияют» и «сломал другой сайт» — обе правды одновременно

Движок (winws2.exe) идёт по профилям сверху вниз и для каждого соединения берёт первый профиль, чей фильтр совпал (first-match-wins). Дальше:

  • Стратегия этого профиля действует только на перехваченный им трафик. Она не утекает в другие профили и не комбинируется с ними.
  • Профиль ниже, чей фильтр тоже подходил бы, для этого соединения вообще не выполняется — трафик до него не дошёл.

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

Разбор реального вопроса: «добавил один сайт в Исключения — наглухо умер YouTube»

Частый случай из вопросов пользователей. «Исключения (RU сайты)» — это профиль с pass (ничего не делать, см. профиль-исключение pass), который по правилам ставят первым/вверху. Когда его включают, pass-профиль встаёт над профилем YouTube. Если его фильтр перехватывает трафик YouTube раньше — к YouTube применяется pass = никакого обхода, DPI видит его SNI открытым → блок. Стратегия YouTube при этом не ломается — она просто не запускается, потому что соединение забрал верхний pass-профиль. Выключили исключения — перехватчик исчез, профиль YouTube снова отрабатывает, всё работает. Это не глюк, а детерминированный порядок.

Почему задевает именно YouTube, если в списке исключений всего один сайт (например qwen), — зависит от фильтра профиля-исключения (диапазон портов, ipset, и как реально применяется hostlist к захвату потока). Чаще всего pass-профиль захватывает поток по широкому диапазону портов раньше, чем хостлист успевает его сузить. Чтобы назвать точную причину в конкретной установке — нужно посмотреть её пресет (см. «Как диагностировать»).

«Исключение» = pass = голый трафик к DPI

pass сайт не «защищает» — он отключает обход для перехваченного трафика. Для российских/незаблокированных сайтов это правильно (им дурение вредит — symptom-not-cause). Но если pass-профиль перехватит заблокированный сайт, тот поедет к DPI без обхода и умрёт. Поэтому держи в списке исключений только то, что действительно должно идти мимо обхода, и следи, чтобы исключение не было шире, чем нужно.

Как диагностировать «включил X — сломался Y»

Это всегда порядок + фильтр, а не «порча стратегии». Алгоритм:

  1. Открой Настройка пресета → Порядок в пресете.
  2. Посмотри профиль, который включили: его порты и список (hostlist/ipset). Не накрывает ли он лишнего (широкий диапазон портов, большой ipset, pass без узкого хостлиста)?
  3. Подними узкий профиль сломавшегося сайта выше перехватчика — по правилу «выше = главнее» он заберёт свой трафик первым.
  4. Если перехватчик — это pass-исключение, проверь, что в его списке только нужные домены, и что его фильтр не шире задуманного.
  5. Профиль сайта проверяй в одиночку: временно отключи подозреваемый перехватчик и убедись, что сайт ожил — это подтвердит, что дело в перехвате, а не в стратегии.

Чего НЕ бывает (частые мифы)

  • ❌ «Включу два профиля на один сайт — обход будет сильнее.» → Возьмётся один (верхний), второй не выполнится.
  • ❌ «Стратегия соседнего профиля мешает моему сайту.» → Мешать может только перехват трафика по порядку, не сама стратегия.
  • ❌ «Программа глючит: тронул один сайт — отвалился другой.» → Это детерминированный first-match-wins, а не баг. Чините порядок/фильтр.
  • ❌ «Надо подобрать одну стратегию, которая сработает сразу на всё.» → Разным сайтам нужны разные профили; «одна на всё» — это просто широкий профиль сверху (см. «all tcp udp»), а не магия.

📚 См. также


🤖 Эти статьи открыты — можно обучать на них ИИ

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