Перейти к основному содержимому

История изменений

[1.87.0] - 2026-10-17​

  • ДОБАВЛЕНО: Сет может убирать ключи ECH из ответов DNS, и браузер открывает сайты, например на Cloudflare, там, где сеть отбрасывает соединения с ECH - переключатель находится в редакторе сета в разделе DNS & Маршрутизация, Перенаправление DNS, Encrypted ClientHello (ECH), сет с cloudflare-ech.com и включённым переключателем охватывает все сайты Cloudflare, а в режиме NFQUEUE ключи убираются и из ответов DNS, идущих по IPv6, даже при выключенной поддержке IPv6. Дискавери предлагает такой сет, без изменения пакетов, для сайта, который открывается только без ECH.
  • ДОБАВЛЕНО: Дашборд предупреждает, когда из-за фильтра TCP-портов сета b4 пропускает соединения - так бывает, только если b4 отличает пакеты устройства от ответов сервера по портам. Так он делает при включённом «Пропустить настройку IPTables/NFTables» или без match conntrack в ядре. Предупреждение в разделе «Последние изменения» называет порты, из-за которых это происходит.
  • ДОБАВЛЕНО: «Информация о системе» показывает, удерживает ли роутер отброшенное QUIC-соединение, в строке «Блокировка QUIC действует на всё соединение» - если роутеру не хватает того, что для этого нужно, строка это называет, в OpenWrt - пакет kmod-nf-conntrack-netlink.
  • ДОБАВЛЕНО: Сет, маршрутизированный через интерфейс, может отправлять свой трафик на шлюз в сети этого интерфейса, например на VPN-шлюз или другой роутер - поле «Шлюз (необязательно)» находится в редакторе сета, в разделе «DNS & Маршрутизация», «Маршрутизация трафика». Если шлюз IPv4, а интерфейс - порт Ethernet, мост, VLAN или Wi-Fi, за сетом идут и IPv4-устройства этой сети. Шлюз вне сети интерфейса или с адресом самого роутера b4 не использует и пишет причину в лог. #401, спасибо @alle-ox
  • ИЗМЕНЕНО: На Keenetic и на роутерах со старым ядром, где b4 не может задержать DNS-запросы до того, как ядро начнёт отслеживать их соединения, DNS-запросы уходят дальше к резолверу, которого спросило устройство, а ответ этого резолвера на имена, которые сет блокирует, закрепляет или отправляет на свой резолвер, перехватывает b4 - этот резолвер и серверы, которые он опрашивает, по-прежнему видят эти имена, в том числе для сета с зашифрованным резолвером. «Информация о системе» показывает строку «DNS-запросы копируются, а не задерживаются (NFLOG)».
  • ИЗМЕНЕНО: В режиме NFQUEUE соединение, которое другой сервис отправляет через туннель или не тем маршрутом, каким пошли бы пакеты самого b4, не получает стратегии от сета, с которым совпало - это касается интерфейсов WireGuard, AmneziaWG, TUN и TAP, а с iptables legacy и соединений, которые сервис вроде MagiTrickle по своей метке отправляет другим маршрутом. Страница «Логи» помечает их tunnel->wg0 или reroute->ppp1, а сеты блокировки по-прежнему их блокируют. Соединения через туннель, по которому идёт маршрут по умолчанию самого роутера, сохраняют стратегии.
  • ИСПРАВЛЕНО: На Keenetic устройство, запросившее IPv4- и IPv6-адреса имени одновременно, как и сам роутер, и после 1.85.1 часто теряло второй ответ, а «Информация о системе» при этом показывала возможность «DNS-запросы в очереди раньше conntrack (raw)» доступной или лог предлагал kmod-ipt-raw, пакет для OpenWrt - KeeneticOS обрабатывает таблицу raw, из которой b4 с версии 1.85.1 ставил DNS-запросы в очередь, только после того, как ядро начало отслеживать соединение запроса. #402
  • ИСПРАВЛЕНО: На роутерах со старым ядром устройство иногда получало только один из двух ответов, IPv4 или IPv6, которые запросило одновременно для имени из сета с DNS-перенаправлением - b4 отправлял оба ответа в один и тот же момент, и отслеживание соединений ядра отбрасывало один из них как дубликат другого.
  • ИСПРАВЛЕНО: На роутерах с iptables и старым ядром, например Keenetic, соединения через сет с включёнными «Фейковыми SYN-пакетами» открывались примерно на секунду дольше, а в режиме UDP Fake & Fragment терялась большая часть фейков, часто вместе с настоящим первым пакетом QUIC - с версии 1.25.0 b4 второй раз ставил в свою очередь пакеты, которые отправляет сам, и отслеживание соединений ядра на таком роутере отбрасывало часть из них.
  • ИСПРАВЛЕНО: Устройство, которое отправляет несколько DNS-запросов с одного сокета, например DNS-сервер в локальной сети, после того как b4 сам отвечал на один из них или изменял один из его ответов, например убирал из него IPv6-адреса, отправляло следующие запросы мимо b4 - когда b4 отправлял устройству ответ отдельным пакетом, его правила файрвола помечали соединение устройства как собственное соединение b4.
  • ИСПРАВЛЕНО: Сет с включённым «Только по домену» применялся только к началу каждого соединения - остальные пакеты соединения уходили без стратегии сета, и на странице «Трафик» у них не было сета. Если адрес или порт общий для нескольких сетов, эти пакеты могли получить стратегию другого сета. b4 выбирал сет для следующих пакетов по адресу или порту, а сет «Только по домену» адреса не запоминает. #428
  • ИСПРАВЛЕНО: Сет, который отбрасывает или отклоняет QUIC или блокирует сайт, не мешал браузеру, например Chrome, открыть сайт по QUIC - Chrome отправляет начало QUIC-соединения двумя пакетами, а имя сайта b4 узнаёт только из второго. Сет с включённым «Только по домену» отбрасывал только этот пакет. Остальные сеты отбрасывали только пакеты, которые b4 видит в начале соединения, по умолчанию 8, а следующие доходили до сервера. #428
  • ИСПРАВЛЕНО: При действии UDP «Склейка QUIC Initial» сайты не открывались по QUIC в Chrome - b4 ставил пакет с паддингом перед каждым пакетом QUIC-хендшейка соединения, а не только перед тем, который несёт имя сайта. Серверы оставляли такие пакеты без ответа. Когда сет уже запомнил адрес сайта, это касалось и первого пакета хендшейка. #427
  • ИСПРАВЛЕНО: Дискавери сообщал, что сайт, например на Cloudflare, открывается без b4, хотя Chrome открыть его не мог - его проверки никогда не использовали ECH, который браузер вроде Chrome использует для каждого сайта, публикующего ключ ECH, и который некоторые сети блокируют.
  • ИСПРАВЛЕНО: Дискавери мог предложить стратегию пакетов, запомненную в прошлом запуске, для сайта, которому нужно было только исправить DNS-ответ - запомненная стратегия, которая тоже открывала сайт, побеждала исправление DNS.
  • ИСПРАВЛЕНО: Информация о системе показывала утилиты, например jq, sha256sum и ipset, без версии, если они лежали на USB-накопителе, на который установлен b4 - b4 спрашивал версию только у утилиты из стандартного системного каталога, например /usr/bin или /opt/bin.
  • ИСПРАВЛЕНО: Запись regexp:, указанная в двух сетах, например в сете и его копии, созданной кнопкой «Дублировать», работала только в том из них, что выше в списке, поэтому, если один из них был ограничен устройствами-источниками, часть устройств получала для имён, совпадающих с этой записью, не тот сет или никакой - b4 закреплял каждый шаблон только за первым сетом, в котором он встретился.
  • ИСПРАВЛЕНО: Устройство, добавленное вручную по IPv6-адресу, введённому в другой записи, например заглавными буквами или с ведущими нулями, не распознавалось, когда b4 сопоставлял его трафик с доменами сетов, поэтому сет, в устройствах-источниках которого оно выбрано, его пропускал, а сет с режимом «Все устройства, кроме выбранных» к нему применялся - b4 искал пакеты по стандартной записи их адреса, а адрес устройства хранил в том виде, в каком его ввели.
  • ИСПРАВЛЕНО: Приложения с TCP Fast Open не могли открыть сайты через сет со стратегией - такое приложение кладёт начало защищённого соединения в пакет, который открывает соединение. b4 разрезал этот пакет как обычные данные, и каждая часть заново открывала соединение со своей нумерацией. Сайт оставлял одну из них и не мог прочитать начало. #431
  • ИСПРАВЛЕНО: «Режим окна» отправлял повреждённые фейковые пакеты на соединениях с метками времени TCP, которые Linux включает по умолчанию - каждый фейк сохранял длину заголовка исходного пакета, но нёс только первую часть заголовка.
  • ИСПРАВЛЕНО: С включённым SYN MD5 Signature фейковый SYN мог уйти без рабочей опции MD5, например у приложения с TCP Fast Open - если опции настоящего SYN не оставляли места, опция не добавлялась. Если они заканчивались маркером конца опций, она вставала после него, а там серверы уже ничего не читают. Сервер, до которого доходил такой фейк, мог принять его за настоящий SYN.
  • ИСПРАВЛЕНО: b4 мог остановиться из-за повреждённого TCP-пакета, отправленного на адрес из сета - заголовок пакета объявлял длину меньше, чем бывает у любого TCP-заголовка. Применяя стратегию сета, b4 читал данные за концом пакета.
  • ИСПРАВЛЕНО: Сет с фильтром TCP-портов, охватывающим порты собственных соединений устройств, например 1-65535, заставлял b4 пропускать часть или все TCP-соединения всех сетов - b4 отличал пакеты устройства от ответов сервера по портам. Пакет устройства с порта из фильтра выглядел как ответ. #429
  • ИСПРАВЛЕНО: В соединениях самого роутера и в IPv6-соединениях без трансляции адресов «Защита от RST-инъекций», «Обход входящих ответов» и эскалация по «Поддельным RST» переставали работать, как только b4 отправлял в соединение фейки или сегменты после разделения - с версии 1.71.1 правила файрвола b4 принимали такое соединение за собственное соединение b4. Пакеты сервера в нём после этого не доходили до b4.
  • ИСПРАВЛЕНО: Соединения самого роутера показывались на странице «Трафик» дважды, а «Обнаружение блокировки по IP» могло признать их адреса заблокированными после меньшего числа попыток без ответа, чем задано порогами - с версии 1.26.1 при выключенной «Фильтрации устройств» b4 обрабатывал каждый пакет, который отправлял роутер, дважды.
  • ИСПРАВЛЕНО: Соединения из интернета к серверу в локальной сети за пробросом порта не устанавливались, если с ними совпадал сет, например сет только с портом 443 - с версии 1.22.0 b4 принимал их за собственные соединения устройства с интернетом и применял стратегию сета в сторону сервера.
  • ИСПРАВЛЕНО: С nftables «Глобальный MSS Clamping» и MSS Clamping сета без исходных устройств не заставляли устройства отправлять пакеты меньшего размера и не действовали на соединения самого роутера - с версии 1.39.1 clamping стоял после правил очереди b4, и пакет, прошедший через очередь, его пропускал.
  • ИСПРАВЛЕНО: На роутере, прошивка которого перезаписывает метку соединения b4, например на некоторых моделях ASUS, проброшенный порт не отвечал на соединения с адреса из сета, маршрутизированного через интерфейс - на таком роутере b4 ставит метку на каждый пакет к адресам сета. Он ставил её и на ответы в таких соединениях, и они уходили через интерфейс сета.
  • ИСПРАВЛЕНО: Соединения, которые пометил другой сервис на роутере, например соединения устройств, которые KeeneticOS перечисляет для своего хотспота, или те, что маршрутизирует MagiTrickle, не получали стратегий от сетов b4 - b4 принимал эти метки за метки собственных пакетов, у которых с ними общий бит. (#422, спасибо @asovetov; #276)

[1.86.0] - 2026-10-09​

  • ДОБАВЛЕНО: Страница Дискавери показывает запуск, начатый через MCP-сервер или мониторингом, пока она открыта, а история помечает такие запуски - запуск появляется в течение пяти секунд, история обновляется, когда он заканчивается, а его строки в истории показывают под временем запуска «через MCP» или «через мониторинг».
  • ДОБАВЛЕНО: Кнопка «Копировать JSON» в диалоге Дискавери «Применить как сет» копирует предложенный сет, не создавая его - в формате вкладки «Импорт/Экспорт» редактора сета, через которую его можно импортировать на другом устройстве.
  • ДОБАВЛЕНО: Информация о системе показывает рядом с именем каждой утилиты из своего списка, например iptables, nft, ipset, curl и wget, её версию - это версия, которую сообщает сама утилита, а для утилиты из состава BusyBox - версия BusyBox, и «Копировать JSON» и MCP b4_diagnostics отдают её как version.
  • ДОБАВЛЕНО: Сет может записывать собственное значение DSCP в пакеты, которые идут к его адресам, чтобы роутер перед b4 маршрутизировал или приоритизировал трафик каждого сета отдельно - для этих пакетов значение сета заменяет значение «Задать DSCP», в том числе когда этот переключатель выключен, и действует для IP-, GeoIP- и ASN-целей сета и для адресов, которые b4 узнаёт для его доменов. Переключатель находится в редакторе сета, в разделе «DNS & Маршрутизация», «Маршрутизация трафика», где также видно, когда сет не может его использовать, например сет с прокси или блокировкой.
  • ДОБАВЛЕНО: Заголовок вкладки браузера называет открытую страницу, например «Трафик - B4», поэтому несколько вкладок b4 можно различить, тогда как раньше каждая вкладка называлась «B4» - редактор сета добавляет имя сета, например «YouTube - Сеты - B4», а «Настройки» - открытую вкладку.
  • ДОБАВЛЕНО: Панель «Устройства» на странице Трафик по умолчанию сортируется по имени, а через кнопку сортировки - по последней активности или по числу пакетов, тогда как раньше устройства менялись местами всякий раз, когда одно из них отправляло пакет - при сортировке по имени сначала идут устройства с именем, затем устройства, известные только по MAC-адресу, затем источники, известные только по IP-адресу, а выбранное устройство остаётся на панели и после того, как его последний пакет вышел за пределы периода.
  • ИЗМЕНЕНО: Устройство на панели «Блокировки» показывает под именем свой IP-адрес, а MAC-адрес - в подсказке - раньше эту строку занимал MAC-адрес.
  • ИЗМЕНЕНО: Дашборд раскладывает панели рядами, которые всегда занимают всю ширину, а панели ряда одной высоты, по самой высокой, тогда как раньше панели укладывались в свободные места, оставляли дыры и сдвигались вбок, когда списки росли - в режиме «Настроить» граница между двумя панелями и кнопки минус и плюс переносят ширину между соседями, панель, брошенная на другую, встаёт в её ряд, брошенная между рядами получает отдельный ряд, а кнопка ряда делит или объединяет ряды.
  • ИСПРАВЛЕНО: Дискавери минутами перебирал все стратегии на ссылке, которая отдаёт ошибку даже без b4, например на голом адресе хоста картинок, а затем сообщал, что ничего не сработало, будто сайт заблокирован - ответ сайта «неверный запрос» он считал признаком того, что стратегия испортила запрос, даже на первой попытке, которая идёт вообще без стратегии.
  • ИСПРАВЛЕНО: Запуск Дискавери через MCP-сервер работал хуже того же запуска со страницы Дискавери: ссылка вроде ссылки на картинку YouTube на каждую попытку получала ошибку, а стратегии хаба сообщества не проверялись - сервер обрезал ссылку на запятой внутри неё, принимал остаток за второй сайт и переводил путь ссылки в нижний регистр, поэтому сайт получал запрос страницы, которой не существует, а хаб в запуск не включал.
  • ИСПРАВЛЕНО: На Keenetic b4 иногда не работал после перезагрузки роутера, не создав даже errors.log, а также мог остановиться, перезапуская сам себя для повторной попытки запустить движок пакетов - хук, который b4 ставит для перестроек файрвола роутера, посылал сигнал перепроверки любому процессу с именем b4, и только что запущенный b4 от этого сигнала завершался. #404

[1.85.1] - 2026-10-08​

  • ИСПРАВЛЕНО: На роутерах со старым ядром устройство, запросившее IPv4- и IPv6-адреса имени одновременно, часто не получало ответа на второй запрос, поэтому приложения на нём, например видеоплеер на телевизоре, ждали и не подключались, а собственные запросы роутера могли зависать на секунды - b4 ставил каждый DNS-запрос в свою очередь только после того, как ядро начинало отслеживать его соединение, и второй запрос, отправленный в тот же момент из того же сокета, отбрасывался как дубликат первого, пока тот ждал в очереди b4.
  • ИЗМЕНЕНО: В iptables правила других сервисов для DNS-запросов, например TPROXY из Xray или метки mwan3 и KVAS, применяются и к запросам, которые уже видел b4 - b4 ставит запросы в очередь из таблицы raw, до этих правил, а прежде запрос, выпущенный из его очереди, пропускал следующие правила mangle.

[1.85.0] - 2026-10-04​

  • ДОБАВЛЕНО: Дискавери принимает доверенный DNS-сервер, заданный в Настройки, Дискавери или для одного запуска, в виде 9.9.9.9, 127.0.0.1:53053, tcp://, tcp+udp:// или URL https:// для DNS поверх HTTPS, и проверяет сайт через закреплённые адреса, указанные для запуска в «Закреплённых адресах» или взятые из сета, для которого идёт запуск - ответы сервера служат эталоном для проверки DNS, предложенный сет получает этот сервер как свой DNS, если сет умеет им пользоваться, и сохраняет закрепления, а сайт, имя которого существует, но не имеет адреса в DNS, показывается именно так, с подсказкой про закрепление, а не как имя с опечаткой. Списка «Запасные UDP DNS серверы» и неиспользуемой настройки «Эталонный домен» больше нет.
  • ДОБАВЛЕНО: «Скачать конфигурацию» в разделе «Настройки», «Система», «Бэкап» сохраняет текущую конфигурацию как есть или безопасной копией, которую можно отправить, когда нужна помощь - в безопасной копии пароли, токены, имена пользователей, имена хостов роутера и его relay и учётные данные внутри URL заменены на [redacted], а конфигурацию с такими заглушками b4 не загружает и не сохраняет.
  • ДОБАВЛЕНО: Информация о системе показывает, сколько сетов маршрутизации установлено, а пока они не ставятся, ошибку, время начала сбоя и время следующей попытки - строка «Сеты маршрутизации» находится в разделе Firewall, а лог предупреждает, если в системе нет ни одной утилиты файрвола, которая может поставить маршрутизацию.
  • ИЗМЕНЕНО: Настройки перегруппированы: у вкладки «Основные» появились подвкладки «Движок пакетов», «Устройства», «Файрвол», DNS и SOCKS5, а новая вкладка «Система» после неё объединяет «Сервис» с логированием, «Веб-сервер» и «Бэкап», заменивший отдельную вкладку «Бэкап» - подвкладка показывает точку, пока в ней есть несохранённые изменения, и значок, пока изменение ждёт перезапуска.
  • ИЗМЕНЕНО: Дашборд показывает соединения в минуту в сетах и вне сетов, что каждый сет поймал за последний час, и проблемы, требующие внимания - вместо «Активности устройств» и «Доменов не в сетах» стоят ссылки на страницу Трафик, показатели «Среды выполнения» перенесены в «Информацию о системе», а «Сброс статистики» стал «Сбросить счётчики», у «Активных эскалаций» появилась своя кнопка «Очистить».
  • ИЗМЕНЕНО: MCP b4_status и b4_metrics и API метрик считают каждое соединение один раз, поэтому их поля изменились - вместо connections_seen, current_cps, current_pps и memory_percent они отдают число соединений по минутам, cpu_percent и rss_bytes, /api/metrics и /api/ws/metrics отдают новый снимок дашборда, а POST /api/escalations/clear очищает эскалации.
  • ИСПРАВЛЕНО: Числа на дашборде вводили в заблуждение: «Активные потоки» только росли, «Трафик» учитывал только первые пакеты каждого соединения, «Воркеры» всегда были все активны, аптайм начинался заново после «Сброса статистики», а «Домены не в сетах» переставали принимать новые домены - b4 считал соединением каждый разобранный пакет, никогда не отмечал завершение соединения и выбрасывал каждый новый домен, как только список был полон.
  • ИСПРАВЛЕНО: «Сброс статистики» на дашборде заодно возвращал все сайты в эскалации в сет, который для них не справлялся - вместе со счётчиками сброс очищал эскалации b4.
  • ИСПРАВЛЕНО: Дискавери для несуществующего домена, например с опечаткой, несколько минут перебирал все стратегии, и каждая проверка заканчивалась ошибкой DNS resolution failed (no such host) - запуск не отличал имя, у которого нет ни одного адреса, от сайта, который стратегия ещё могла бы открыть.
  • ИСПРАВЛЕНО: Дискавери сообщал «Обход не нужен» для сайта, которому резолвер отдавал неверный адрес, если ни один опробованный DNS-сервер не отвечал честно, мог предложить DNS-перенаправление, которое тоже отдавало неверный адрес, а применение его результата могло выключить в сете «Отдавать SERVFAIL, если резолвер недоступен» - запуск открывал сайт по адресу от DNS поверх HTTPS, но не переносил этот адрес в сет, принимал первый сервер DNS поверх HTTPS с любым ответом, на роутере с локальным резолвером проверял фрагментированный DNS через этот резолвер вместо сервера, а свои настройки DNS, где этот переключатель выключен, записывал поверх настроек сета.
  • ИСПРАВЛЕНО: После запуска Дискавери DNS-запросы по TCP для сетов с DNS-перенаправлением уходили исходному резолверу, как только b4 пересобирал правила файрвола, и так до перезапуска b4, а пока шёл запуск, список «Активные переключения» на дашборде то и дело опустевал - собственная очередь пакетов Дискавери публиковала своё состояние вместо основной очереди b4: неработающий слушатель DNS по TCP и пустой список переключений.
  • ИСПРАВЛЕНО: Сет, DNS-перенаправление которого указывало на резолвер на другом устройстве локальной сети, заставлял запросы своих имён ждать весь таймаут запроса всякий раз, когда этот резолвер обращался к вышестоящему серверу по обычному DNS, а при включённом «Отдавать SERVFAIL, если резолвер недоступен» они завершались SERVFAIL - b4 отправлял этому резолверу обратно его же запросы этих имён к вышестоящему серверу.
  • ИСПРАВЛЕНО: После возврата «Часового пояса» на «Авто (система)» метки времени в логах оставались в прежнем поясе до перезапуска b4 - b4 загружал пояс, который установил сам, а не системный.
  • ИСПРАВЛЕНО: Интерфейс NAT Masquerade, который был выключен или переименован, пропадал из карточки, и она выглядела так, будто маскарадинг работает на всех интерфейсах, хотя он был ограничен пропавшим - карточка показывала только интерфейсы, которые есть в данный момент, и не показывала сохранённые, которых нет.
  • ИСПРАВЛЕНО: Карточки сетов писали число целей как 1 доменов или 2 доменов, а в русском интерфейсе длинные подписи в панели, которую карточка сета открывает с вкладок Цели, Разделение, Фейки, Маршрут, DNS и Эскалация, наезжали на значения или переносились на вторую строку - после числа всегда стояло одно и то же слово, а столбец подписей был фиксированной ширины, и длинные русские подписи в него не помещались.
  • ИСПРАВЛЕНО: Обновление из веб-интерфейса завершалось ошибкой Could not fetch the installer: mkdir /tmp/b4update-...: no such file or directory, если в /tmp ничего нельзя было создать, как это случилось в контейнере MikroTik после перезапуска, а при /tmp, смонтированном с noexec, веб-интерфейс сообщал о начале обновления, но ничего не происходило - b4 размещал установщик в /tmp и запускал его оттуда, а установщик переходил в другой каталог, только когда в /tmp не хватало свободного места.
  • ИСПРАВЛЕНО: Запрос к /api/system/update с версией вроде --remove или --arch=mips удалял b4 или ставил бинарник другой архитектуры вместо обновления - b4 передавал запрошенную версию установщику без проверки, и установщик принимал её за свой параметр.
  • ИСПРАВЛЕНО: На ядре, которое не принимает таблицу маршрутизации b4 в nftables, например в Synology DSM с b4 в Docker, b4 при каждом запуске и сохранении писал в лог ошибку маршрутизации и повторял попытку каждые 10 минут, даже если маршрутизацию не использовал ни один сет - b4 создавал таблицу маршрутизации, не проверив, нужна ли она хоть одному сету.
  • ИСПРАВЛЕНО: В Docker-образе сеты маршрутизации не работали на хосте, где не работает nftables, даже если ядро поддерживает ipset, движок NFQUEUE на таком хосте пропускал дублирование пакетов и MSS clamping сетов по адресам, а движок TUN ставил на каждый адрес дублирования пакетов отдельное правило захвата - в образе не было ipset.

[1.84.0] - 2026-09-30​

  • ДОБАВЛЕНО: Переключатели «Доступ из интернета» для портов веб-интерфейса, MTProto- и SOCKS5-прокси и WEB-прокси Telegram Desktop, по умолчанию выключенные - каждый открывает свой порт в файрволе и держит его открытым после перезапусков файрвола, а окно «Поделиться ссылкой» у MTProto может подставить в ссылку интернет-адрес.
  • ДОБАВЛЕНО: Информация о системе, лог и карточка Telegram через WebSocket называют сетевые мосты, из-за которых устройства за ними не попадают в proxy-сеты и в Telegram через WebSocket - при net.bridge.bridge-nf-call-iptables, равном 1, который на OpenWrt выставляет пакет dockerd, ядро теряет привязку к слушателю b4 у соединений, входящих через мост вроде br-lan, поэтому они висели без единой строки в логе, а соединения самого роутера работали. Строка Bridge netfilter в разделе Firewall окна Информация о системе называет настройку, которую нужно выключить.
  • ДОБАВЛЕНО: «Задать DSCP» записывает значение DSCP в пакеты, которые отправляет хост; по умолчанию выключено - роутер перед b4 может узнавать трафик b4 по полю в самом пакете, а внутренние метки b4 за пределы хоста не выходят. Переключатель находится в разделе «Настройки», «Основные», «Фаервол», а значение и интерфейсы появляются в группе «DSCP» после его включения.
  • ИСПРАВЛЕНО: Страница настроек требовала перезапустить b4 после изменения SOCKS5-прокси, имени пользователя, пароля или языка веб-интерфейса или настроек MCP, хотя ни одному из них перезапуск не нужен - она считала требующим перезапуска любое изменение на вкладке «Основные», а настройки MCP с вкладки «Интеграции» относила к «Основным».
  • ИСПРАВЛЕНО: Дискавери, в том числе запущенный мониторингом для сета, терял часть проверочных пакетов и работал в несколько раз медленнее на сайте, который уже покрывал включённый сет - очередь пакетов b4 снова забирала пакеты Дискавери на выходе с роутера: в iptables, а в nftables при некоторых настройках меток, например после изменения «Метки пакета» из веб-интерфейса.
  • ИСПРАВЛЕНО: Изменённая «Метка пакета» применялась лишь частично: сеты с маршрутизацией сохраняли старое значение до следующей проверки файрвола или перезапуска; в iptables правило CONNMARK со старым значением оставалось даже после остановки b4; а сохранение из веб-интерфейса оставляло метки Дискавери равными старому значению плюс 1 и плюс 2 - сеты с маршрутизацией сравнивались без «Метки пакета», обновление правил файрвола убирало то, что поставили бы новые настройки, а не то, что стояло, а конфигурация хранила вычисленные метки Дискавери.
  • ИСПРАВЛЕНО: В iptables b4 удалял правила маскарада, которые не добавлял, при каждом запуске, остановке и обновлении правил файрвола: простое -j MASQUERADE в nat POSTROUTING и -o <интерфейс> -j MASQUERADE для каждого интерфейса из NAT Masquerade - он всё ещё убирал по тексту правила, которые туда ставили версии до 1.71.0, и под них попадали такие же правила самого роутера.
  • ИСПРАВЛЕНО: Один неверный адрес, например 10.0.0.0/99 или имя, в сете с дублированием пакетов не давал запуститься движку пакетов NFQUEUE, а в режиме TUN, если сет с дублированием пакетов охватывал много адресов, например категорию GeoIP или ASN, веб-интерфейс появлялся через минуту и больше после запуска, при наличии сета маршрутизации обход затем останавливался ещё примерно на столько же, а остановка b4 в это время завершалась по тайм-ауту и оставляла правила перехвата - b4 передавал адреса сета в ipset или nft без проверки, а одна запись, которую инструмент отвергает, срывает загрузку целиком; в режиме TUN он давал каждому адресу дублирования отдельное правило файрвола и добавлял их по одной команде, раньше правил, перехватывающих первые пакеты каждого соединения, а на iptables-legacy каждая команда переписывает всю таблицу, поэтому цепочка перехвата строилась тем дольше, чем больше адресов, при запуске и ещё раз сразу после него, когда появлялись сеты маршрутизации.
  • ИСПРАВЛЕНО: В режиме TUN на ядре без некоторых модулей iptables: без таблицы raw или цели CT, например в Synology DSM, соединения, которые устройство пересылало для других, например для Docker-контейнеров в сети bridge или клиентов LAN, не работали дальше локальной сети, хотя собственные соединения устройства работали; без xt_connbytes соединение, совпавшее с сетом, получало обход DPI этого сета на каждом пакете, а не только на первых, из-за чего трафик через него шёл во много раз медленнее, а в лог попадала строка на каждый пакет - без правила NOTRACK копии пересылаемых пакетов, которые b4 отправлял дальше, второй раз проходили через отслеживание соединений, и NAT ядра давал им новый порт источника, поэтому ответы приходили на порт, который никто не слушал; а b4 полагался на правило connbytes ядра, которое передаёт ему только первые пакеты соединения, и без него TUN-движок получал и обрабатывал соединения целиком.
  • ИСПРАВЛЕНО: Первое соединение к адресу, который сет маршрутизации узнал из DNS-ответа, могло уйти мимо сета: напрямую, а не через upstream proxy-сета или интерфейс сета - b4 пропускал ответ к устройству раньше, чем адреса из него попадали в сет, и устройство успевало подключиться.
  • ИСПРАВЛЕНО: Соединения, которые proxy-сет отправлял в свой upstream, показывались на странице «Трафик» и в логе без имени сайта, если была выключена настройка «Передавать имя домена в upstream» или в сете были только адреса, а DNS-ответа для адреса b4 не видел - b4 читал имя из соединения, только когда оно требовалось для upstream.

[1.83.1] - 2026-09-27​

  • ДОБАВЛЕНО: Если движок пакетов не запускается, b4 продолжает работать без него, и веб-интерфейс остаётся доступен - дашборд показывает причину, например ядро без поддержки NFQUEUE, с кнопкой, которая переключает на другой движок и перезапускает b4, а b4 сам повторяет запуск три раза примерно за две минуты.
  • ДОБАВЛЕНО: b4 можно перезапустить из веб-интерфейса без менеджера сервисов, например в Docker, в контейнере MikroTik или после ручного запуска - b4 перезапускается сам, на месте, с тем же идентификатором процесса, поэтому контейнер продолжает работать.
  • ИСПРАВЛЕНО: b4 завершался при запуске, не показывая причину в консоли, некоторые ошибки запуска выглядели как %!w(...), а неудачное открытие очереди пакетов оставляло прокси-сеты отправлять трафик на слушатель, которого уже не было - последняя ошибка попадала только в errors.log, куда b4 перенаправляет stderr, лог не умел печатать ошибку, обёрнутую в другую, а правила маршрутизации снимались только после успешного запуска.
  • ИСПРАВЛЕНО: На роутерах, где b4 запускается из init-скрипта, например на ASUS Merlin и Keenetic, каждый перезапуск или обновление из веб-интерфейса переносили сокеты отправки пакетов старого b4 в новый, и открытые сокеты накапливались с каждым перезапуском - сокеты не помечались на закрытие при запуске b4 другой программы, поэтому их наследовали скрипт перезапуска и запущенный им b4.
  • ИСПРАВЛЕНО: При включённом «Разрешить только выбранные устройства» в разделе «Фильтрация устройств» соединения через SOCKS5-сервер b4 и другие соединения самого роутера шли напрямую, мимо proxy-сетов и «Telegram через WebSocket» - правило, передающее соединение слушателю сета, пропускало только выбранные устройства, а собственные соединения роутера приходят к нему через loopback-интерфейс, поэтому до 1.83.0 они зависали, а с 1.83.0 не попадали в эти сеты вовсе.
  • ИСПРАВЛЕНО: На iptables сет маршрутизации, которому «Разрешить только выбранные устройства» не оставлял ни одного устройства, например потому что сет их исключает или потому что это добавленные вручную IPv4-устройства при включённом IPv6, продолжал обслуживать прежние устройства, а b4 перестраивал маршрутизацию при каждой проверке файрвола - старый переход в правила сета заменялся, только когда новый фильтр давал новый, а проверка пропавших правил ожидала переход в каждом семействе адресов.
  • ИСПРАВЛЕНО: В режиме TUN сайт из proxy-сета, открытый через SOCKS5-сервер b4, не открывался по тайм-ауту, если его точного имени не было в сете, а адрес .onion через него не работал ни в одном режиме - SOCKS5-сервер сам разрешал имя и подключался напрямую, оставляя правилам файрвола перехватить адрес, но адреса сета b4 узнаёт из DNS-ответов, которые видит, в режиме TUN ответы на собственные запросы роутера до него не доходят, а у имени .onion нет адреса, который можно было бы узнать.
  • ИСПРАВЛЕНО: Там, где iptables работает поверх nf_tables, как в Debian, Ubuntu и некоторых сборках OpenWrt, соединения самого роутера к адресам proxy-сета уходили напрямую, пока b4 перехватывал трафик для обхода DPI - правило перехвата отправляло их в очередь пакетов b4, а пакет, вернувшийся из очереди, на таких системах уже не идёт по маршруту, который запрашивала метка сета.
  • ИСПРАВЛЕНО: Сет маршрутизации со своим резолвером в DNS-перенаправлении мог заполниться адресами, которые для его доменов выдал резолвер роутера, а в сети с подменой DNS - поддельными, и включение этого резолвера не разрешало домены заново - домены сета и имена, которые b4 передаёт upstream прокси в виде адреса, b4 разрешал через резолвер роутера, а тот попадает на резолвер сета, только когда b4 перехватывает его запросы, но не когда отвечает из своего кэша или сам ходит по DNS поверх TLS или HTTPS.
  • ИСПРАВЛЕНО: Сеты маршрутизации теряли адреса, которые должны были держать: на nftables каждый адрес, изученный из DNS, по истечении его времени жизни (по умолчанию час) с первого появления, сколько бы раз DNS ни возвращал его снова, что обрывало живые соединения через proxy-сеты и пропускало трафик мимо сетов блокировки, а на iptables адрес, вписанный в сет вручную, через час после того, как его вернул и DNS - на nftables повторное добавление адреса, который уже был в сете, оставляло в силе его первый срок, а на iptables изученная копия заменяла постоянную запись вписанного адреса на истекающую.
  • ИСПРАВЛЕНО: При net.ipv4.conf.all.src_valid_mark = 1, который выставляют XrayUI для outbound WireGuard и wg-quick, «Telegram через WebSocket» и proxy-сеты ничего не пропускали от устройств локальной сети и VPN, хотя MTProto Прокси при этом работал - в этом случае ядро проверяет, откуда пришло перенаправленное соединение, по таблице маршрутизации, которую выбирает метка сета, а таблица b4 на любой адрес отвечает самим роутером, поэтому ядро отбрасывало каждое соединение как пришедшее с поддельного адреса.

[1.83.0] - 2026-09-26​

  • ДОБАВЛЕНО: Сеты могут нацеливаться на целые сети по их ASN - вкладка ASN в редакторе сета принимает номер вроде AS15169 или IP-адрес, а b4 загружает анонсированные префиксы сети из RIPEstat и обновляет их раз в сутки. Со страницы «Трафик» в сет можно добавить анонсированный префикс адреса или всю его сеть, DPI Детектор может добавить сеть хостинга, MCP b4_edit_set_targets принимает вид asns, а общие сеты и сеты сообщества переносят ASN.
  • ИСПРАВЛЕНО: Сет, у которого не было файла или категории GeoIP или GeoSite, действовал на все соединения к портам из своего фильтра портов, а его MSS clamp применялся ко всем HTTPS-соединениям с его устройств-источников - b4 принимал сет без развёрнутых доменов и адресов за сет, который совпадает только по порту, а MSS clamp без адресов откатывался к одним устройствам сета.
  • ИСПРАВЛЕНО: Оборванная закачка geosite.dat или geoip.dat не давала b4 запуститься, пока файл не скачивали заново вручную - инсталлятор писал каждую попытку поверх рабочего файла и прерывал закачку GeoSite размером 74 МБ через 600 секунд, веб-интерфейс так же ставил на его место страницу ошибки или оборванный ответ без длины и прерывал закачку через 10 минут, а b4 завершался на нечитаемом файле ещё до запуска веб-интерфейса и повторной закачки отсутствующих файлов.
  • ИЗМЕНЕНО: Инсталлятор показывает размер каждого источника GeoSite и GeoIP и больше не предлагает по умолчанию тот, чей файл не помещается - GeoSite от RUNET Freedom весит 74 МБ, поэтому при первой установке, если он не помещается в целевой директории, инсталлятор предлагает самый маленький подходящий источник, например Loyalsoldier на 11 МБ, а при переустановке остаётся уже заданный источник.
  • ИСПРАВЛЕНО: Настройки могли потеряться из-за прерванного сохранения, например при пропадании питания, или из-за адреса, добавленного со страницы «Трафик» во время другого сохранения - файл перезаписывался на месте, поэтому после прерванного сохранения b4 запускался с настройками по умолчанию и при следующем сохранении записывал их поверх файла, а добавление сохраняло копию конфигурации, взятую до другого изменения.
  • ИСПРАВЛЕНО: Перекрывающиеся адреса дублирования пакетов вроде 8.8.0.0/16 и 8.8.8.0/24 останавливали обход на nftables, а дублирование пакетов и MSS clamp подхватывали новые адреса с опозданием - nft отклонял перекрывающиеся диапазоны, после чего b4 снимал свои правила обхода, а сохранение, которое включало дублирование или меняло его адреса, не обновляло фаервол, как и добавление со страницы «Трафик» или обновление файла GeoIP.
  • ИСПРАВЛЕНО: Сохранение настроек с большими сетами маршрутизации на nftables занимало секунды - при каждом сохранении b4 заново загружал адреса сета по 128 за раз, отдельным вызовом nft на каждую порцию, около 150 вызовов на 19 000 адресов.
  • ИСПРАВЛЕНО: Токен IPInfo мог попасть в лог b4, запросы к IPInfo и RIPE NCC на странице «Трафик» могли висеть бесконечно, а при неудачном добавлении адреса там показывалась ошибка разбора JSON вместо причины - неудачный запрос к IPInfo записывал в лог свой URL вместе с токеном, у запросов не было таймаута, а ошибки добавления возвращались простым текстом.
  • ДОБАВЛЕНО: «Telegram через WebSocket» включается переключателем в разделе Настройки, Telegram, без сета и без файлов GeoIP и GeoSite - мост пропускает Telegram для устройств за b4 и для самого роутера по диапазонам адресов Telegram, которые есть в самом b4 и раз в сутки обновляются, а карточка показывает, работает ли мост и чего не хватает, если нет. Вкладка «MTProto-прокси» переименована в «Telegram», переключатель system.mtproto.bridge.enabled можно менять через MCP, сеты в режиме маршрутизации «Telegram через WebSocket» работают как раньше, а страница «Трафик» помечает их соединения и соединения моста как «Мост Telegram» вместо -ws.
  • ДОБАВЛЕНО: Две настройки в разделе Настройки, Telegram, для сетей, где блокируют WebSocket-узел Telegram или замедляют workers.dev - в поле «Имя для фронтинга WS-узла Telegram (расширенное)» задаётся другое TLS-имя, например sprinthost.ru, которым пользуется tg-ws-proxy, и b4 пробует его после неудачного рукопожатия с именами kws*.web.telegram.org, а рукопожатие, которое не заканчивается сертификатом telegram.org, закрывает. Переключатель «Обрабатывать соединения с Worker сетами», который появляется после того, как задан домен Cloudflare Worker, позволяет сету с рабочей стратегией для Cloudflare обрабатывать собственные соединения b4 с Worker; обе настройки по умолчанию выключены.
  • ИСПРАВЛЕНО: Telegram через MTProto-прокси и WebSocket-мост обрывал соединения и медленно грузил медиа там, где собственные серверы Telegram заблокированы или работают с перебоями, а на Android через мост фото и видео в части каналов не загружались, и лог заполнялся предупреждениями -444 - b4 перебирал маршруты по одному, ждал узел Telegram три секунды до попытки через Cloudflare, снова пробовал мёртвые узлы каждые пять минут и держал запасные соединения всего 20 секунд, а для сессии Android определял дата-центр по адресу, что для 149.154.167.255 давало дата-центр 2 вместо 4.
  • ИСПРАВЛЕНО: Telegram через WebSocket-мост не работал там, где замедляют workers.dev, рабочий Cloudflare Worker обрывался и откладывался на десять минут посреди сессии, а маршруты Telegram через Cloudflare не работали, пока был включён сет, покрывающий Cloudflare - мост отправлял соединения, которые не смог расшифровать, на Worker, даже если они шли на порты кроме 443, до которых Worker не достаёт, и даже когда единственный Worker был отложен, проверка на зависание принимала следующий запрос простоявшей сессии или одиночное подтверждение за замолчавший Worker, а собственные соединения b4 с Cloudflare получали faking и фрагментацию такого сета, например с GeoIP- или GeoSite-категорией cloudflare, которые в некоторых сетях их ломают.
  • ИСПРАВЛЕНО: b4 обращался к core.telegram.org, при его недоступности к proxy.b4core.app и к raw.githubusercontent.com при каждом запуске, даже когда все функции Telegram были выключены - список дата-центров Telegram и список доменов Cloudflare-прокси скачивались при любых настройках.
  • ДОБАВЛЕНО: Дискавери умеет искать стратегию для существующего сета, а мониторинг умеет поддерживать его работу - у сета может быть до пяти адресов на новой вкладке «Дискавери» редактора сета, а пункт «Найти стратегию» в меню карточки сета открывает Дискавери с этими адресами. При включённом «Поддерживать работу сета с помощью мониторинга» мониторинг проверяет эти адреса и, если они стабильно не открываются, запускает Дискавери для сета, записывает стратегию, которая работает для всех адресов, и возвращает прежнюю, если адреса всё ещё не открываются; список доменов продолжает работать, его записи можно перенести в сет, а MCP b4_find_bypass_strategy и b4_watchdog принимают set.
  • ИЗМЕНЕНО: Замена стратегии сета из Дискавери меняет только то, что Дискавери проверил - сет сохраняет свои настройки UDP и маршрутизацию, а добавлять ли сайт в сет, который его ещё не покрывает, вместе с удалением его из всех других сетов, решает флажок, включённый по умолчанию. Раньше выбрать можно было только сет, в котором уже указан сайт, а замена всегда добавляла сайт в сет, убирала его из всех других сетов и копировала настройки UDP и DNS, которые Дискавери не проверял.
  • ИСПРАВЛЕНО: Восстановление мониторингом могло испортить сет, а после любой смены стратегии сайты, на которых не сработала прежняя, до пяти минут оставались недоступны - восстановление могло записать стратегию, не прошедшую подтверждение, стирало фильтр портов, защиту от RST и настройки UDP сета и отменялось следующим сохранением со страницы настроек или сета, открытой до него, а обнаружение блокировки по IP с включённым «Кэшировать заблокированные IP» отвечало собственным сбросом b4 на новые соединения с этими сайтами, пока запись не истекала.
  • ИСПРАВЛЕНО: Дискавери мог засчитать стратегию, которая приводила на страницу блокировки провайдера, проверять сеть самого роутера и ждать полный таймаут на соединении, замершем посреди страницы - он оценивал только страницу, на которой заканчивалось перенаправление, локальный или частный адрес вроде 192.168.1.1 отклонял только инструмент MCP и только записанный числом, а проверка зависания на 2 секунды выполнялась только после завершения чтения, тогда как чтение ждёт данных до конца таймаута.
  • ИСПРАВЛЕНО: Мониторинг и DPI Детектор сообщали о блокировке, которой не было, а Детектор писал, что запросы на порт 53 доходят до своих резолверов, хотя на все отвечал один перенаправляющий резолвер - перенаправление в пределах сайта вроде /login?reason=session_blocked совпадало с маркерами страницы блокировки, единственный таймаут или ошибка DNS без повторного запроса показывались как «Подмена DNS» для сайта и «Подменяет» для резолвера, а сводка по порту 53 считала отсутствие строк с пометкой о перехвате доказательством того, что каждый запрос дошёл до своего резолвера, хотя перенаправление на известный резолвер вроде Google никогда не помечается.
  • ИСПРАВЛЕНО: Proxy-сеты и «Telegram через WebSocket» могли перестать пропускать трафик, например после перезапуска xray в XrayUI - правило XrayUI в начале mangle PREROUTING забирало пакеты соединений, которые b4 направил на свои слушатели, правило слушателя отклоняло собственные соединения роутера при включённом «Разрешить только выбранные устройства» в разделе «Фильтрация устройств», слушатель, чей порт был занят при запуске, оставался закрытым до следующего сохранения, а proxy-сет, в цели которого попадал сервер upstream, работающего на роутере или на другом устройстве в сети, по кругу возвращал в этот upstream его же соединения и отключал все устройства за сетом.
  • ИСПРАВЛЕНО: «Передавать имя домена в upstream» ни на что не влияло для большинства соединений, и upstream вроде Tor получал только адрес, а с SafeSocks отклонял соединение с сообщением «giving Tor only an IP address» - имя бралось только из TLS- или QUIC-приветствия, которое b4 видел при обработке пакетов, а соединение, перенаправленное сетом, в эту обработку не попадает.
  • ИСПРАВЛЕНО: Сет с выходным интерфейсом после некоторых сохранений на iptables отправлял свои фейковые и разделённые пакеты через основной канал, а когда все таблицы маршрутизации с 100 по 249 были заняты, мог удалить все правила маршрутизации роутера и заменить его маршрут по умолчанию - сохранение, пересобиравшее правила фаервола, например при смене портов, лимитов пакетов, NAT Masquerade или MSS clamp, снова ставило правило b4, пропускающее его собственные пакеты, выше переходов в цепочки сетов, а DNS-ответ для сета, который синхронизация пропустила из-за отсутствия свободной таблицы, всё равно устанавливал его с меткой 0 и таблицей 0, которые ip rule и ip route понимают как все правила и основную таблицу.
  • ИЗМЕНЕНО: TUN сам выбирает таблицы маршрутизации из свободных ниже 100 вместо фиксированных 9999 и 9998 - ip из busybox принимает номера таблиц только до 1023, поэтому TUN с ним не запускался (invalid argument '9998' to 'table ID'), а очистка после TUN удаляла все правила, указывающие на эти таблицы, кто бы их ни добавил, очищала таблицу, от которой TUN отказался как от занятой, и оставляла два собственных правила TUN для таблицы main. queue.tun.route_table по-прежнему задаёт таблицу вручную, а с ip из busybox версии ниже 1.33 TUN не запускается вовсе.
  • ДОБАВЛЕНО: «Информация о системе» показывает, сколько правил захвата TUN на месте и сколько раз b4 восстанавливал свои правила, со временем последнего восстановления - в режиме TUN интервал мониторинга фаервола тоже есть в разделе Настройки, «Основные», «Фаервол», и там он не меньше 10 секунд.
  • ИСПРАВЛЕНО: В режиме TUN перезапуск фаервола роутером, например после изменения проброса портов на Xiaomi, оставлял b4 без трафика и без остальных его правил до перезапуска самого b4, часть изменений настроек тоже ждала перезапуска, а на iptables 1.8 фильтрация устройств при каждой проверке на мгновение выбрасывала устройства LAN из захвата - движок TUN проверял только наличие своей цепочки захвата, монитор фаервола, который также отвечает на SIGUSR1, работал только с NFQUEUE, TUN читал порты сета, лимиты пакетов, адреса дублирования, фильтр устройств, NAT Masquerade и MSS clamp один раз при старте, а MAC-адреса сравнивались с учётом регистра, хотя iptables 1.8 выводит их строчными буквами.
  • ИСПРАВЛЕНО: В режиме TUN при включённом NAT Masquerade без выбранных интерфейсов или при правиле маскарада роутера без выходного интерфейса b4 захватывал трафик, но ни один сайт не открывался - такое правило подменяло адрес пакетов, уходящих в устройство TUN, на адрес самого устройства раньше, чем TUN успевал поставить им адрес внешнего интерфейса, поэтому ответы не возвращались.

[1.82.3] - 2026-09-23​

  • ИСПРАВЛЕНО: Сайт с закреплёнными адресами, открытый в браузере, примерно через минуту уходил на адрес, которого b4 не выдавал, и вкладка заканчивалась таймаутом - из списка закреплённых адресов отвечались только запросы A и AAAA, поэтому параллельный запрос HTTPS браузера приносил от резолвера CNAME сайта, системный кэш сам шёл по этому CNAME, как только истекал короткий ответ с закреплёнными адресами, и их больше не спрашивал.
  • ИСПРАВЛЕНО: Закреплённый адрес, до которого роутер не мог достучаться, выдавался первым каждый раз, и браузер ждал на нём больше двух минут, прежде чем перейти к следующему - мёртвые адреса исключались только при включённом обнаружении блокировки по IP, которое по умолчанию выключено, а отвечает ли закреплённый адрес вообще, никто не проверял.
  • ИСПРАВЛЕНО: Сайт вне всех сетов, делящий адрес с закреплённым именем, две минуты после каждого запроса этого имени уходил без защиты - DNS-подсказка, сохранённая для клиента, имела приоритет над адресом, выученным из прежнего трафика, и когда SNI приветствия не совпадал ни с одним сетом, совпадение сбрасывалось без возврата к нему.
  • ДОБАВЛЕНО: Дискавери и DPI Детектор распознают шлюз перед хостом b4, который сам завершает TCP - на SYN с пределом в один переход может ответить только следующий узел, поэтому адрес, который на него отвечает, обслуживает прозрачный прокси на этом шлюзе (роутер со своим перенаправлением или граница провайдера, когда b4 и есть роутер), а не сайт. Дискавери исключает такие адреса из поиска, продолжает с адресами из ECS-сканирования, которые маршрутизируются обычным путём, и останавливается с понятным вердиктом, когда ничего не осталось; Детектор помечает сайт как GATEWAY с пометкой, что ни одна стратегия с этого хоста ничего изменить не может.
  • ИСПРАВЛЕНО: Дискавери тратил запуск на два тупика: адрес проверки http://, порт 80 которого всем отвечает короткой ошибкой, и второй перебор TTL подделки после того, как первый ничего не нашёл - 403 с пустым телом от самого сайта проваливал каждый пресет с «insufficient data» при любой стратегии, а отрицательный результат перебора не сохранялся между семействами стратегий.
  • ДОБАВЛЕНО: История Дискавери хранит стратегии, которые тоже сработали, а не только победившую - сайт в истории разворачивается в список найденных альтернатив, до двенадцати, и любую из них можно применить оттуда спустя долгое время после прогона. Стратегия, уже установленная как сет, помечена как испробованная, а в каждой строке видно, сколько сайт занимает в файле истории.
  • ИЗМЕНЕНО: «Применить как сет» начинает с замены стратегии в сете, где сайт уже есть, а не только с создания ещё одного сета - сет сохраняет название, сайты и маршрутизацию, поэтому перебор стратегий для одного сайта больше не оставляет череду сетов, отличающихся только целями. Единственное прежнее предложение, добавить сайт в сет с той же стратегией, не появлялось вовсе: в сравнении за ним участвовала подделка пакета, которую b4 держит в памяти для включённого сета и которой нет у сета, только что собранного Дискавери.

[1.82.2] - 2026-09-19​

  • ИСПРАВЛЕНО: После сохранения настройки, которая перестраивает firewall, в логе появлялось Tables rules missing, restoring..., иногда неудачное восстановление цепочки B4_DNSTCP, а на медленном роутере правила отсутствовали или были собраны наполовину до двадцати секунд - перестройка снимает все правила и ставит их заново, пока монитор таблиц продолжает опрос, и ничто не упорядочивало их между собой, поэтому опрос, попавший внутрь снятия, запускал второе восстановление, которое боролось с перестройкой за те же цепочки.
  • ИЗМЕНЕНО: Восстановление правил после перезаписи firewall, о которой сообщил хук Keenetic, пишется в лог уровнем INFO - в этом случае вместо предупреждения выводится Tables rules missing after a firewall rewrite, restoring..., а предупреждение остаётся для восстановления, которое опрос начал сам: на Keenetic это значит, что хука нет, а на других системах - что правила убрал не b4.
  • ИЗМЕНЕНО: Адреса хаба в Настройках, Интеграции, Хаб сообщества показаны метками, только имя хоста, в порядке перебора - зеркала, полученные от хаба, обведены, а адрес, ответивший при последней синхронизации, отмечен.
  • ИЗМЕНЕНО: Зеркала, полученные от хаба, перебираются после адреса самого хаба, а не перед ним - порядок такой: адреса из поля «Зеркала хаба», затем hub.b4core.app, затем полученные зеркала, так что адрес, указанный вручную, по-прежнему идёт первым, а полученное зеркало обслуживает роутер, только когда хаб не отвечает.
  • ИСПРАВЛЕНО: Сорвавшаяся синхронизация с хабом отмечалась как did not answer the health check только для одного адреса, независимо от причины - сама причина, неудачное разрешение имени, отказ в соединении, таймаут или код ответа, терялась по пути к строке состояния, а назывался только последний из перебранных адресов, так что зеркало, указанное вручную, могло отказать первым без единого следа.
  • ИСПРАВЛЕНО: На роутере, где стратегия сета, покрывающего адреса хаба, подвешивала собственное TLS-рукопожатие b4, как это делал сет со всеобъемлющим regexp:.*, хаб не синхронизировался, хотя с любого другого устройства открывался - запросы b4 к хабу проходили через его же обработку пакетов, как и любой другой трафик, второго пути на случай, когда она ломает соединение, не было, и ничто не показывало, какой сет стоит на пути.

[1.82.1] - 2026-09-18​

  • ДОБАВЛЕНО: b4 перепроверяет свои правила firewall по SIGUSR1, а на Keenetic установщик подключает это к каталогу хуков NDMS netfilter.d - NDMS перестраивает таблицы netfilter при продлении UPnP-проброса, переподключении WAN или смене политики и удаляет все чужие цепочки, поэтому правила b4 пропадали до следующего опроса монитора таблиц, то есть на срок до десяти секунд при каждой перестройке.
  • ИСПРАВЛЕНО: Восстановление правил, совпавшее с перезаписью firewall другой программой, сообщало xt_connbytes kernel module is not available и пропускало IPv4, хотя модуль был загружен - пробная цепочка исчезала под проверкой, а iptables отвечает на пропавшую цепочку теми же словами, что и на отсутствующий match.
  • ИСПРАВЛЕНО: Обновление могло оставить повреждённый бинарник b4, если роутер перезагружался вскоре после него - установщик проверял новый файл и удалял прежнюю копию до того, как запись доходила до накопителя, поэтому перезагрузка раньше, чем диск успевал её завершить, оставляла файл нужного размера с мусором внутри, и b4 падал при каждом запуске.
  • ИСПРАВЛЕНО: Свой список из пяти запасных UDP DNS серверов в Настройки, Дискавери пропадал после следующего перезапуска - загруженный список записывался поверх встроенного значения по умолчанию, с которым его потом сравнивали, поэтому при сохранении он считался значением по умолчанию и в файл не попадал.
  • ИСПРАВЛЕНО: На роутерах с nftables сет с дублированием или с MSS clamping, в котором больше нескольких тысяч адресов, останавливал b4 ошибкой argument list too long - все адреса пачки передавались nft одним словом командной строки, а ядро отвергает одно слово длиннее 128 КБ ещё до запуска команды.

[1.82.0] - 2026-09-17​

  • ДОБАВЛЕНО: Хаб сообщества: сет можно опубликовать на hub.b4core.app, а сеты других пользователей b4 просматривать, применять и оценивать на новой странице Сообщество - общий сет содержит только стратегию, её цели и файлы payload, не включает ничего привязанного к роутеру, ждёт модератора перед публикацией и после применения остаётся связанным с каталогом, поэтому его можно оценить, обновить или пожаловаться на него, а Дискавери пробует сеты сообщества для домена раньше собственных пресетов. Всё это за одним переключателем в Настройки, Интеграции, по умолчанию выключенным; сервис b4hub, который поставляется рядом, поднимает собственный хаб или зеркало центрального, а суточные лимиты на участника задаются в его консоли модерации, и доверенные ключи под них не подпадают.
  • ДОБАВЛЕНО: QUIC-хендшейк можно отправить за пакетом с паддингом внутри одной датаграммы - новый режим UDP coalesce ставит QUIC Initial из одного паддинга перед Initial клиента в одной датаграмме, зашифрованный на другом connection ID, так что сервер не может его расшифровать и отбрасывает, а DPI, читающий только первый пакет, останавливается на нём, и не меняет сам хендшейк.
  • ДОБАВЛЕНО: Обычный HTTP-запрос может нести пустую строку перед методом - новая опция TCP http_methodeol добавляет эту строку и убирает два символа из значения User-Agent, чтобы длина запроса не менялась, а инспекция, ожидающая метод в начале, перестаёт находить заголовок Host. Работает только на порту 80 и требует заголовок User-Agent; до неё для сайта, отфильтрованного по заголовку Host, не было ни одной стратегии.
  • ДОБАВЛЕНО: У WEB-прокси Telegram может быть собственный порт, а страницу-заглушку можно заменить - в Настройки, MTProto-прокси, WEB-прокси Telegram Desktop порт релея открывает отдельный слушатель со своим сертификатом, который отвечает на хост релея как релей, а на всё остальное заглушкой, для проброса с WAN 443, который иначе попадал на веб-интерфейс и показывал страницу входа b4 по https://<публичный IP>/. Заглушку можно заменить загрузкой самодостаточного HTML-файла в той же карточке.
  • ИСПРАВЛЕНО: Дискавери мог назвать рабочую стратегию для сайта, который остаётся заблокированным, и продолжал перебор с фейком, вред которого уже был доказан - ответ HTTP 400 и страница ошибки в 157 байт оба засчитывались как удачная загрузка, а когда не подходило ни одно значение TTL, перебор брал семёрку и измерял с ней группы TCP-фрагментации и TLS-записей.
  • ИСПРАВЛЕНО: Настройки принимали TLS-ключ с паролем, а веб-интерфейс молча оставался на обычном HTTP - при сохранении проверялось только наличие двух файлов, неудачная загрузка при старте была предупреждением, которое не попадало ни в лог ошибок, ни на дашборд, а отсутствующий при старте файл сертификата останавливал сервис целиком.
  • ИСПРАВЛЕНО: Без учётных данных веб-сервера любая веб-страница, открытая пользователем в локальной сети, могла читать и менять конфигурацию роутера - API отвечал любому origin браузера разрешением на кросс-доменный доступ, и между чужой страницей и изменяющими конфигурацию запросами больше ничего не стояло.
  • ИЗМЕНЕНО: Прерванный запуск Дискавери подтверждает найденное, а не оставляет его неподтверждённым - «Остановить и подтвердить» завершает поиск на текущем пресете, помечает оставшиеся шаги пропущенными и запускает подтверждение для найденных победителей, а повторное нажатие во время подтверждения завершает запуск немедленно. Раньше единственная остановка оставляла неподтверждённый результат - ровно тот, ради которого существует этап подтверждения.
  • ИЗМЕНЕНО: «Подгонять размер фейка» копирует в фейк настоящий ClientHello вместо растягивания payload до его размера - переписывается только доменное имя, подогнанное под длину настоящего, а Дискавери пробует эту форму со старым TCP timestamp или битой контрольной суммой при полном TTL. В двух российских сетях фильтр обрывает фейк, который отличается от настоящего приветствия по длине хотя бы на байт, и пропускает фейк той же длины, тогда как растянутый фейк повторял байты payload и не был ClientHello вовсе.
  • ИЗМЕНЕНО: Окно сравнения сетов перестроено на тех же строках Цели, Разделение, Фейки, Маршрут, DNS и Эскалация, что и карточки сетов - оба сета выбираются и меняются местами прямо в окне, у каждой отличающейся строки видно название настройки, цели сравниваются по категориям и доменам, а не по количеству, а переключатель «Только отличия» скрывает совпадающее. Старое окно открывалось узким столбцом и прятало названия настроек в обрезанных чипах. #356

[1.81.1] - 2026-09-10​

  • ИСПРАВЛЕНО: После перезапуска сервиса на OpenWrt b4 мог остаться работать, не реагируя ни на что, кроме kill -9, или задвоиться после обновления - демон переставал слушать сигналы с началом остановки и не соблюдал свой лимит, а установщик верил остановке, которую не проверял, и pidfile, который не сверял. #351
  • ИСПРАВЛЕНО: Установка или обновление с --quiet оставляли b4 остановленным, а --platform= пропускал настройку сервиса - единственный запуск прятался за интерактивным вопросом, указанная платформа не узнавала тип сервиса, Ctrl-C на вопросе засчитывался как ответ по умолчанию, а запуск без терминала сразу завершался.
  • ИСПРАВЛЕНО: Установщик после одного предупреждения переходил на непроверенные загрузки и записывал конфигурацию доступной всем пользователям - одна неудачная проверка сертификата переводила все последующие загрузки, включая контрольную сумму, на непроверенный TLS.
  • ИСПРАВЛЕНО: Любая установка на OpenWrt с MIPS64 завершалась ошибкой загрузки - установщик запрашивал сборку mips64_softfloat, которая никогда не публиковалась.
  • ИСПРАВЛЕНО: --remove оставлял правила файрвола убитого b4 и бинарник, установленный в нестандартный каталог - удаление полагалось на то, что процесс уберёт за собой сам, и не заглядывало в каталог, выбранный при установке.

[1.81.0] - 2026-09-06​

  • ИЗМЕНЕНО: Страница DPI Детектора перестроена вокруг введённых сайтов, и каждый сайт запрашивается дважды - напрямую и через b4, поэтому строка говорит, блокирует ли сайт провайдер, чинит ли его b4 или он всё ещё заблокирован; сверху вердикт одним предложением, кнопка, передающая всё ещё заблокированные сайты в Дискавери, и отчёт для копирования в issue. Старая страница запрашивала только через работающий движок, так что хорошо настроенный b4 прятал ту самую блокировку, которую должен был показать. Проверка принимает любой список доменов или URL, заполняется из сетов, а четыре её области названы по вопросу, на который отвечают: Сайты, DNS, Хостинги и CDN, Telegram. Проверка DNS объединяет две прежние в одну таблицу по провайдерам через UDP, DoH и DoT, судит о честности по шифрованным ответам и называет, кто на самом деле ответил на запрос к порту 53; проверка хостингов группирует цели по сетям с порогом обрыва и белыми SNI, которые проходят; проверка Telegram измеряет отправку наряду со скачиванием. Списки целей обновлены из проекта dpi-detector по состоянию на 2026-09-04, мёртвые сайты и адреса убраны, а кнопка подтягивает актуальные списки без выпуска новой версии.
  • ИЗМЕНЕНО: Страница Дискавери перестроена вокруг введённых сайтов - результаты и история перечисляют сайты в том порядке, в каком они введены, по одной карточке с понятным вердиктом на сайт, а найденная стратегия описана предложением и показана с теми же строками разделения, фейков, целей и DNS, что и на странице сетов, до того как будет применена. Во время запуска видны этап, число проверенных конфигураций и живая строка журнала вместо процента, остановка сохраняет найденное и помечает его неподтверждённым, параметры названы по тому, что они делают, а журнал последнего запуска остаётся доступным после перезапуска и скачивается файлом.
  • ДОБАВЛЕНО: Дискавери ищет адреса, которые не попали под блокировку, и может починить сайт одним DNS - когда известные адреса сайта недоступны или не проходят TLS-рукопожатие, запуск спрашивает публичный резолвер, какие адреса получают клиенты примерно из пятисот других регионов, проверяет, какие из них принимают соединение и завершают рукопожатие для сайта, и закрепляет сайт за ними в собранном сете, включив обнаружение мёртвых адресов, чтобы переставший отвечать адрес пропускался. Сайт, который открывается через честный DNS-ответ или через такой адрес, отмечается как найденный с сетом без изменения пакетов, тогда как раньше он читался как не нуждающийся в обходе и сета не получал.
  • ИСПРАВЛЕНО: Дискавери могло применить сет, не совпадающий с найденным, а остановленный запуск оставлял страницу устаревшей до перезагрузки - остановка прекращала опрос до того, как запуск записывал историю, альтернативный пресет нёс geo-категории всех остальных сайтов запуска и DNS-перенаправление, если хоть один из них выглядел подменённым, история применяла сет самой быстрой записи ко всем сайтам семейства техник под именем семейства, а никогда не блокировавшийся сайт читался как найденный, пока запомненные победители проверялись раньше обычного запроса.
  • ИСПРАВЛЕНО: Прокси-сет, совпадающий с любым адресом, отрезал привязанное к нему устройство от сети, а удаление адреса из целей ничего не возвращало - правила перехвата выбирают пакет только по адресу назначения, поэтому DNS-запросы устройства к роутеру, продление аренды DHCP и обращения к веб-интерфейсу тоже уходили на вышестоящий прокси, сет без фильтра по устройствам в свою очередь помечал для прокси ответы самого роутера совпавшему клиенту, а адрес, убранный из целей сета, оставался в наборе ядра до отключения сета или перезапуска сервиса. #322
  • ИСПРАВЛЕНО: Сет с маршрутизацией через интерфейс отправлял туда только первый пакет каждого соединения, а все следующие за ним уходили через обычный аплинк - решение о маршрутизации переносится на метке соединения, а держит ли роутер эту метку, b4 определяет по собственной отметке в таблице соединений, где соединение, ещё не завершившее рукопожатие, несёт эту отметку на любом роутере, в том числе на тех, чья прошивка владеет меткой и перезаписывает её мгновением позже; на ту же отметку была завязана подмена адреса источника при выходе в интерфейс, поэтому её тоже не происходило.
  • ИСПРАВЛЕНО: На роутере, где загрузка идёт через wget, обновление из веб-интерфейса оставляло в журнале обновления текст подсказки grep, а строки установщика отстояли от строк самого b4 на несколько часов - установщик спрашивает у grep, есть ли в справке wget опция таймаута, передавая имя опции, которое grep принимал за собственную, а две половины журнала брали время с разных часов.

[1.80.4] - 2026-08-31​

  • ИСПРАВЛЕНО: Любое изменение настроек сета с маршрутизацией разбирало его до того, как собрать заново, и около секунды подходящий трафик уходил через обычный аплинк - правило маршрутизации, маршрут, переход в prerouting, цепочка и выученные из DNS адреса снимались раньше, чем появлялась замена, а сет ставит метку на соединение только на первом пакете, поэтому соединение, открытое в этом окне, оставалось вне сета до самого своего конца.

  • ИСПРАВЛЕНО: Каждое изменение настройки через MCP-сервер оставляло за собой целую копию конфигурации, из-за чего память росла на десятки мегабайт и не освобождалась до перезапуска b4 - история отмены хранит конфигурацию в том виде, в каком она была до каждой из последних двадцати записей, а на роутере с большим geosite-сетом каждая такая копия несла по несколько мегабайт развёрнутого списка доменов.

  • ИСПРАВЛЕНО: Сет в режиме прокси, определяющий апстрим по домену, через несколько минут после любого изменения настроек возвращался к отправке голых адресов и оставался таким до перезапуска b4 - прозрачный прокси продолжал читать индекс доменов, собранный при старте, а движок захвата перестаёт его пополнять сразу после повторного применения конфигурации, поэтому выученные адреса истекали, и заменить их было нечем. #338

  • ИСПРАВЛЕНО: На Keenetic режимы маршрутизации proxy и mtproto-ws после каждой перезагрузки считались недоступными, хотя прошивка содержит модули TPROXY и socket для своего ядра - b4 загружал их через modprobe, которому нужен индекс модулей, отсутствующий в прошивке NDMS с файловой системой только для чтения, поэтому загрузка не удавалась, а следующая за ней проверка считала модули отсутствующими; стартовый скрипт установщика умеет прямой insmod, но этих четырёх модулей в его списке не было. #342

[1.80.3] - 2026-08-30​

  • ИСПРАВЛЕНО: Таблица маршрутизации, имеющая имя в /etc/iproute2/rt_tables, не опознавалась как та, которой пользуется сет - ip выводит такую таблицу по имени, а не по номеру, и именно так прошивка ASUS задаёт таблицы 100 и 200, поэтому b4 считал собственное живое правило маршрутизации отсутствующим и сообщал об этом на каждом проходе, движок TUN при остановке оставлял в этой таблице свои правила, а искал эти имена b4 только в одном файле, тогда как ip читает ещё и копию, поставляемую с пакетом.
  • ИСПРАВЛЕНО: Сет в режиме прокси или mtproto-ws переставал заворачивать что-либо на 443-м порту, из-за чего Telegram висел на "Соединение", хотя на остальных портах тот же сет работал - переход в prerouting для сета в 1.80.0 оказался ниже собственной цепочки движка захвата, а NFQUEUE завершает цепочку, поэтому ответные пакеты завёрнутого соединения забирались до того, как правило сета могло отдать их своему слушателю; на nftables порядок задают приоритеты цепочек, у iptables приоритетов нет, и порядок никто не держал.
  • ИСПРАВЛЕНО: Сет с маршрутизацией через интерфейс собирал список адресов, метки и таблицу, но не получал правило, отправляющее метку в эту таблицу, и всё, что он матчил, уходило через обычный аплинк - правило добавляется, следом вычищаются формы, которые писали прошлые версии, одна из этих форм идёт без маски и доходит до ядра как запрос на совпадение по одному только значению метки, поэтому ядра до 4.17 включительно, а это Keenetic, Padavan и старые сборки OpenWrt и Merlin, забирали по нему то правило, которое только что добавили, а обратно правила маршрутизации никто не перечитывал.
  • ИСПРАВЛЕНО: Домен из сета в режиме прокси не открывался через встроенный SOCKS5-сервер b4, тогда как у клиента, идущего транзитом, тот же домен открывался - трафик, который создаёт сам роутер, получает метку в выходной цепочке сета и возвращается в prerouting по локальному маршруту, где охранное правило, добавленное в 1.80.0, возвращает любой пакет с уже проставленной меткой маршрутизации, включая собственную метку сета.
  • ИСПРАВЛЕНО: Сет в режиме прокси с fwmark, выставленным вручную, укладывал всю сеть роутера - в режиме интерфейса такое значение проверяется и заменяется на собственное, если его нельзя провести через правила, а в режиме прокси бралось как есть, и значение с битами вне маски оставляло правило маршрутизации, которое ядро читает как совпадающее с любым пакетом вообще без метки маршрутизации, поэтому весь такой трафик уходил в таблицу локальной доставки сета.

[1.80.2] - 2026-08-29​

  • ИСПРАВЛЕНО: Интерфейс сообщал версию старее той, что лежит на диске, и ничего не говорил о причине - версия проставляется при сборке, поэтому сервис, чей файл заменили без перезапуска, продолжает отвечать той версией, с которой был собран, тогда как командная строка показывает новую, а там, где запущенный процесс не может прочитать собственный путь, например в контейнере без /proc, диагностика называла этот путь . вместо признания, что он неизвестен.
  • ИСПРАВЛЕНО: Telegram продолжал считать MTProto-прокси неверно настроенным и выключать его - диалог берётся из одного четырёхбайтного -444, отданного дата-центром, а не из медленного подключения, и b4 мог отправить обычную сессию на медийный edge дата-центра, который отвечает на немедийную сессию именно этим; исправление 1.78.0 обходило пустоту, потому что оба имени ведут на один адрес. На роутере без IPv6 мост к тому же отказывался от edge, чьё имя несёт и IPv6-адрес, потому что соединение к нему на машине без маршрута IPv6 ядро отклоняет сразу.
  • ИСПРАВЛЕНО: Сет, направленный в туннель или во внешний прокси, мог уронить роутер через несколько секунд после запуска сервиса - правила выбирают пакет только по адресу назначения, поэтому пакет, отданный прокси обратно для того же адреса, выбирался снова и уходил к тому же прокси - тридцать один круг, пока не кончался счётчик переходов. Если такой сет вёл ещё и собственный трафик роутера, прокси на каждом витке открывал собственное соединение с той же машины, каждый раз с нового исходного порта, пока не заканчивалась память.
  • ИСПРАВЛЕНО: Сет с маршрутизацией мог не вести вообще ничего, и в интерфейсе об этом ничего не говорилось - проверка обратного пути в ядре отбрасывала каждый ответ, приходящий через интерфейс сета; сет в режиме интерфейса без выбранного интерфейса или в режиме прокси без порта выпадал из прохода без единой строки в журнале; выключение сопоставления только по доменам не пересобирало сет, и его список адресов оставался пустым; прошивка, пересобирая собственный фаервол, уносила с ним переход b4; а на роутере с Broadcom прошивка сама раздаёт метку соединения и затирала решение о маршруте, которое b4 в ней хранит.
  • ИСПРАВЛЕНО: Сет с маршрутизацией мог отправить половину соединения одним путём, а половину другим, или занять то, чем уже пользуется другая программа - адрес домена узнаётся только тогда, когда приходит ответ на запрос, то есть уже после начала соединения, поэтому рукопожатие уходило через обычный аплинк, а остаток - по маршруту сета; номер таблицы брался из имени выходного интерфейса, и никто не сверялся ни с /etc/iproute2/rt_tables, ни с правилами, которые на него уже ссылаются; каждый прокси-сет ставил свой переход впереди предыдущего, поэтому последний в списке забирал адреса двух других; фильтр, написанный под клиента в сети, не может совпасть с пакетом, который создаёт сам роутер, поэтому подделки сета, привязанного к устройствам, шли через обычный аплинк; на nftables пара return по метке прокси-сета стояла в начале общей цепочки-хука и завершала её для всех сетов ниже; а каждая пересборка удаляла собственное правило маршрутизации сета, чтобы тут же добавить точно такое же, и всё помеченное в этом окне не находило ничего, указывающего на таблицу сета, и уходило в main.
  • ДОБАВЛЕНО: KILL-switch для выходного интерфейса сета - когда интерфейс пропадал, ядро убирало маршрут, который b4 положил в таблицу сета, правило метки находило таблицу пустой, и поиск проваливался в main, поэтому сет уходил через обычный аплинк с настоящим адресом роутера, а его правила читались как верные.
  • ИЗМЕНЕНО: Сет, направленный в туннель, больше не получает подделок, фрагментации и десинхронизации - работа шла над внутренним пакетом, который заворачивается или терминируется на роутере до того, как его увидит сеть, поэтому не давала ничего и стоила процессорного времени на каждом соединении, а поддельные пакеты доставлялись в стек самой туннельной программы в одном хопе, где им негде истечь. Вместе с этим отключаются SYN-проверки, эскалация по мёртвым адресам, детект блокировки по IP и дублирование TCP; сет сохраняет стратегию обхода, когда ведёт в обычный второй аплинк и когда его выходной интерфейс есть, но опущен.
  • ИСПРАВЛЕНО: Собственная работа b4 с фаерволом могла выбить всю сеть - на роутере, где у iptables нет флага блокировки, команды выполняются без сериализации, пока прошивка переписывает те же таблицы при проверках WAN и событиях DHCP, поэтому команда, проигравшая гонку, оставляла b4 с половиной набора правил, и один запуск проходил нормально, а следующий уносил сеть до перезагрузки; у запущенного, но не успевающего b4 заполнялась очередь, и ядро отбрасывало каждый пакет после четырёхтысячного, ничего об этом не сообщая; а остановка b4 возвращала строгое отслеживание TCP-окна, из-за которого этот фаервол отбрасывает пакеты, и страница отдавала первые пятьдесят килобайт и вставала.
  • ИСПРАВЛЕНО: Выбор сетевых интерфейсов для мониторинга мог выключить обход для всей сети, и об этом ничего не сообщалось - настройка сопоставляет интерфейс, через который пакет уходит, а его сдвигает VPN-клиент или прозрачный прокси, не трогая сам список, поэтому сделанный до этого выбор молча переставал совпадать, и каждый пакет попадал к b4 в очередь и принимался без изменений. Новый раздел Руководства разбирает три настройки с интерфейсами и работу b4 вместе с Xray, как пример.
  • ИСПРАВЛЕНО: На движке TUN b4 захватывал не тот трафик и не видел нужного - правило захвата стояло ниже правил маршрутизации, которые ставит прозрачный прокси, менеджер нескольких WAN или VPN-скрипт, поэтому пакеты сети забирали до того, как их видел b4, а захватывал b4 собственное исходящее соединение прокси; запрос из сети к устройству на другом мосту уносился в туннель и уходил в интернет с адресом аплинка; и внутрь несли только DNS-запросы, но не ответы, поэтому ничто не узнавало адрес в маршрутный сет, не срезало AAAA-записи и не лечило мёртвый адрес.
  • ДОБАВЛЕНО: MCP-сервер, который может действовать на b4, а не только его описывать - ИИ мог читать статус и менять по одной настройке за раз, поэтому всё, о чём просил пользователь, возвращалось инструкциями для ручной работы. Появляются факты по каждой настройке, поиск по geosite и geoip, правка целей и сетов, стенограмма последнего изменения, а за отдельным разрешением Разрешить активные пробы - проверка, грузится ли домен, и запуск Дискавери; каждый вызов инструмента и каждый отклонённый запрос попадают в журнал. Настройки > Интеграции.
  • ИСПРАВЛЕНО: Результат прогона Дискавери становился недоступен в тот момент, когда прогон заканчивался, а вотчдог судил о доменах по запросу мимо обхода - смотрели только в копию в памяти, а она удаляется через 30 секунд после конца прогона; стратегия, названная во время ещё идущего прогона, читалась как окончательная; ранняя остановка выбрасывала найденное; файл истории рос примерно на полмегабайта на каждый проверенный домен, потому что каждая испробованная стратегия сохранялась с полной копией сета, собранного для её проверки; а проверки вотчдога несли метку, которую b4 ставит на уже обработанный трафик.
  • ИСПРАВЛЕНО: Папка настроек была открыта на запись любой учётной записи на роутере, а скачанный бэкап мог не содержать ничего - файл настроек хранит логин веб-интерфейса и токен доступа MCP, но создавался читаемым и записываемым для всех, копии перед каждым обновлением - так же, а восстановление шло по ярлыкам папок, оставленным в ней, поэтому запись из архива могла попасть куда угодно; к тому же b4 пропускал каждый файл, помеченный как программа, а на дисках, подготовленных в Windows, файлы настроек несут эту пометку.
  • ИСПРАВЛЕНО: Импорт конфигурации zapret или byedpi конвертировал лишь часть вставленного и неверно описывал то, что сконвертировал - конфигурационный файл читался построчно, поэтому терялись многострочные значения, ссылки на переменные и порядок, в котором их склеивает штатный скрипт запуска.
  • ИСПРАВЛЕНО: Страница настроек MTProto запрашивала хост релея для WEB-прокси, пока обслуживающий его прокси был выключен - WEB-канал использует слушающий сокет MTProto-прокси и его секреты, поэтому при выключенном прокси карточка собирала хост для релея, который не мог ответить, рядом с карточкой секретов, где все элементы были неактивны, под чипами в заголовках, повторявшими переключатель, хост и режим транспорта, уже видимые ниже.
  • ДОБАВЛЕНО: Документация на WEB-прокси Telegram, который вышел в 1.79.0 без единой строчки описания - его предпосылки невозможно вывести из интерфейса: MTProto-прокси должен быть запущен, релею нужно собственное имя хоста с публично доверенным TLS, а ссылка, которую принимает Telegram Desktop, несёт секрет в другой форме, чем показывают настройки. Он входит в раздел Telegram, где три режима разобраны по отдельности, вместо одной страницы, которая описывала два из них и цитировала строки журнала, которых b4 не пишет.
  • ДОБАВЛЕНО: Зеркала обновления и личный Cloudflare Worker для них - в разделе Настройки, Управление поле «Зеркала обновления» принимает https-адреса, к которым сервис и установщик обращаются раньше встроенных, когда GitHub недоступен, и b4 передаёт этот список установщику при запуске обновления. В документации приведён скрипт Worker, подменяющий GitHub на бесплатном аккаунте Cloudflare, так что при блокировке хоста релизов можно зеркалить через собственный.
  • ДОБАВЛЕНО: Установка обновления из файла для роутера, которому недоступен ни один источник загрузки - окно обновления принимает b4-linux-<arch>.tar.gz, скачанный на другой машине, и необязательное поле для SHA256 со страницы релиза: это единственная проверка, которую автоматический путь не может сделать независимо, так как берёт архив и его сумму с одного хоста. Загрузка отклоняется, если в ней нет b4, собранного под этот роутер, поэтому неподходящая архитектура называется, а не устанавливается с последующим откатом.
  • ИСПРАВЛЕНО: Установка и обновление сервиса срывались там, где сеть блокирует хосты загрузки GitHub, а окно обновления могло не показать ни одной версии - архив релиза отдаётся редиректом на отдельный CDN GitHub, который часть провайдеров отбрасывает по адресу, а запасной прокси возвращал этот редирект роутеру вместо того, чтобы пройти по нему самому, так что роутер всё равно уходил на заблокированный хост и выжидал двухминутный таймаут, а список версий запрашивал браузер, расходуя часовой лимит GitHub, общий для всех за одним адресом.

[1.79.0] - 2026-08-18​

  • ДОБАВЛЕНО: WEB-канал для MTProto-прокси, к которому Telegram Desktop 7.1.1 подключается по обычному HTTPS - клиенту в сети, где MTProxy и fake-TLS блокируются полностью, зайти было нечем: любой транспорт b4 всё равно означал узнаваемый MTProto-сокет со стороны клиента. b4 отвечает на хосте релея bridge-страницей, которую клиент открывает в скрытом WebView, мультиплексирует поток MTProxy через WebSocket того же origin и отдаёт каждый логический поток тем же секретам, пулу DC и upstream-маршрутам, что и обычное соединение; запрос без валидного bridge-токена получает обычную страницу. Настройки > MTProto Прокси.
  • ИСПРАВЛЕНО: DNS-редирект сета отвечал SERVFAIL по всем своим доменам, как только его DoH-сервер становился недоступен - у редиректа не было никакого запасного пути, поэтому резолвер, который цензор в этот момент блокировал, ронял весь сет целиком, хотя стратегия обхода под ним работала как надо. b4 повторяет последний удачный ответ или возвращает запрос тому резолверу, которым клиент пользовался до этого, а переключатель «Отдавать SERVFAIL» в Сеты > Маршрутизация > DNS-редирект сохраняет прежнее поведение.
  • ИСПРАВЛЕНО: Дискавери предлагал стратегию обхода для доменов, которые никто не блокировал - ничто в прогоне не сравнивалось с его же попыткой без обхода, поэтому один заблокированный домен вешал стратегию на весь пакет, а процент улучшения измерял сайт относительно yandex.ru, референсного домена, которым b4 замеряет канал. Каждый домен оценивается по собственной попытке без обхода и докладывается отдельно.
  • ИСПРАВЛЕНО: Стратегия Дискавери объявлялась рабочей по одной загрузке страницы, которая могла и не удаться - неудачей считался только HTTP 451, поэтому 502 длиннее килобайта проходил как успех, проба договаривалась на HTTP/1.1 вообще без ALPN, тогда как любой браузер просит HTTP/2, а страница после редиректа оценивалась по адресу того домена, который на неё перенаправил. Победитель загружается ещё три раза в том виде, в каком его сохраняет сет, и не прошедший хотя бы одну попытку уступает следующему кандидату.
  • ИСПРАВЛЕНО: На роутере с работающим IPv6 Дискавери останавливался примерно на двадцати проверках и сообщал, что обход не нужен - его проверочные соединения были вольны идти по любой версии протокола, тогда как b4 работает только с IPv4, поэтому самая первая проверка проходила по маршруту, которому никто не мешал.
  • ИСПРАВЛЕНО: Дискавери собирал сеты с DNS-редиректом и geo-категориями, которые роутеру не нужны - редирект ставился на каждый сет прогона, стоило хотя бы одному домену выглядеть отравленным, хотя сами пробы им не пользовались, а категории geosite и geoip попадали в результат независимо от того, что установлено на роутере, поэтому результат для CDN-домена без баз geo нельзя было добавить вовсе.
  • ИСПРАВЛЕНО: Перезапуск и остановка службы из интерфейса на systemd проходили неправильно - b4 дожидался systemctl, который systemd останавливает вместе с перезапускаемой службой, поэтому после каждого перезапуска в журнале ошибок оставалось Restart command failed: signal: terminated, а незавершённое соединение браузера могло удерживать остановку все десять секунд, и процесс убивали в момент, когда очистка правил файрвола ещё шла.
  • ИСПРАВЛЕНО: Обновление могло оставить службу незагружаемой или второй b4, запущенный мимо менеджера служб - обновление распознавало все системы инициализации, кроме systemd, поэтому unit, написанный не установщиком b4, пересобирался скриптом SysV, а ещё установщик ждал одну секунду возвращения службы и запускал b4 сам, соперничая с перезапуском самого менеджера.
  • ДОБАВЛЕНО: Список разрешённых источников для SOCKS5-прокси: подключаться могут только перечисленные IP-адреса и CIDR-диапазоны - единственным способом ограничить круг подключающихся были имя пользователя и пароль, которые Chrome и Chromium не умеют отправлять вовсе, поэтому ради клиента в этих браузерах прокси приходилось оставлять открытым для всего, что дотягивалось до его порта. Настройки > SOCKS5 Прокси.
  • ИСПРАВЛЕНО: SOCKS5-прокси обслуживал клиентов, которых должен был не пускать - имя пользователя без пароля или пароль без имени пользователя выключали аутентификацию, а не приводили к отказу, а UDP-релей предпочитал адрес, вписанный в запрос ассоциации, адресу управляющего соединения, поэтому ассоциацию можно было направить на другой хост в сети.
  • ИСПРАВЛЕНО: Выключение SOCKS5-прокси оставляло работать соединения, которые он уже обслуживал - закрывался только слушающий сокет, поэтому установленные туннели продолжали передавать данные, пока клиент не разрывал их сам, и смена порта или адреса привязки вела себя так же.
  • ДОБАВЛЕНО: Переключатель «Блокировать QUIC» на вкладке UDP сета и действие для UDP, которое оставляет совпавшие пакеты без изменений - вытеснение браузера с QUIC обратно на TCP собиралось из двух настроек в разных местах вкладки, и ничто не говорило, что они связаны, а любое доступное сету действие меняло трафик, поэтому сет, совпадающий с QUIC только чтобы выучить адреса сайта, всё равно слал фейки и фрагментировал его. Сеты > UDP.
  • ИЗМЕНЕНО: Два из трёх значений совпадения QUIC делали одно и то же - одно читалось как отключение совпадения по QUIC, второе как «только разобрать», но оба сопоставляли сет по имени сервера из ClientHello. Значение осталось одно, «По SNI», а сохранённые сеты преобразуются при первом запуске.
  • ИСПРАВЛЕНО: IPv6-пакет с extension-заголовками мог уронить b4 - заголовок, объявивший больше байт, чем есть в пакете, уводил чтение за его конец и останавливал сервис для всех устройств роутера.
  • ДОБАВЛЕНО: «Форсировать IPv4 для совпавших доменов»: из ответов для имён, с которыми совпал сет, убираются IPv6-записи - b4 обрабатывает только IPv4, пока не включена поддержка IPv6, поэтому dual-stack сайт, на который нацелен сет, доставался по IPv6 и обходил сет стороной. Настройки > Основное > DNS.
  • ИСПРАВЛЕНО: DNS-ответ, переписанный b4, не сбрасывал счётчик неудач для этого имени - ответ оценивался до переписывания, а не после, поэтому восстановившийся сайт уходил на резервный сет после первой же следующей неудачи.
  • ДОБАВЛЕНО: Egress IP для сета: подменяет адрес источника его трафика - направить сет можно было, только назвав интерфейс или вышестоящий SOCKS5-прокси, а роутеру, который выбирает путь по адресу источника, это не подходит. Сеты > Маршрутизация.
  • ИСПРАВЛЕНО: Устройство, добавленное вручную, игнорировалось везде, где сопоставляются устройства - у такого устройства нет MAC-адреса в сети, поэтому сет, привязанный к нему, переставал уходить по своему маршруту, блокирующие сеты и опция «все устройства, кроме выбранных» оказывались обезоружены, фильтр в разделе Настройки, Фильтрация устройств оставался бездействующим, пока маршрутизация применялась ко всем устройствам сети, а MSS clamp на нём ничего не ограничивал и срезал все остальные проходящие соединения до наименьшего заданного размера. Такие устройства сопоставляются по введённому для них IP-адресу.
  • ИСПРАВЛЕНО: Маршрутизирующий сет, ограниченный исходными устройствами, уводил трафик, которого не должен был касаться - правила на исходящем трафике самого роутера не имели фильтра по устройству, и вместе с «Match any IP address» это затягивало в туннель весь его исходящий путь, а сет, совпадающий только по TCP- или UDP-порту, проверял порт до любой проверки источника и при этом сообщал, что его трафик уводится, отключая все меры против DPI.
  • ИСПРАВЛЕНО: Маршрутизирующий сет без доменов и IP-адресов собирался целиком и молча ни с чем не совпадал - любое правило маршрутизации сопоставляет адрес назначения, поэтому сет без них не мог совпасть ни с одним пакетом, и выше уровня trace об этом ничего не писалось.
  • ИЗМЕНЕНО: Три несвязанных сервиса делили вкладку API через двухколоночную сетку и три разных способа показать учётные данные - токен IPinfo был обычным полем, ключ AI - панелью из чипов и кнопок, MCP-токен - полем во всю ширину, печатавшим секрет открытым текстом, а переключатель включения каждого сервиса стоял в одном ряду с полями, которыми управляет. Вкладка называется «Интеграции» и отводит каждому сервису одну карточку, у которой в заголовке переключатель включения, одно скрытое поле учётных данных с показом, копированием и генерацией, а для MCP - блок настройки клиента, копирующий адрес и токен готовым JSON-фрагментом.
  • ИСПРАВЛЕНО: b4 ронял роутер через несколько минут на загруженном канале, оставляя в логе runtime: program exceeds 10000-thread limit - на каждый совпавший пакет заводилась отдельная задача инъекции без какого-либо потолка, а писали эти задачи в raw-сокет без таймаута отправки, поэтому исходящий интерфейс, переставший разгребать очередь, удерживал по одному потоку ядра на задачу, пока Go не отказывался создавать новые. Инъекция ограничена 512 пакетами в работе, пакет сверх этого проходит без изменений, а отправка, которую ядро не может принять, отбрасывается со счётчиком вместо ожидания.
  • ДОБАВЛЕНО: Число потоков операционной системы на карточке «Среда выполнения» дашборда - карточка показывала горутины, но ничего про потоки ОС, а именно по ним Go останавливает сервис, так что разгон был не виден до самого падения. При превышении половины лимита b4 пишет дамп горутин в каталог логов.

[1.78.0] - 2026-08-17​

  • ДОБАВЛЕНО: MCP-сервер на /api/mcp - b4 не говорил ни на одном протоколе, по которому к нему могло бы подключиться внешнее ИИ-приложение. Инструменты только для чтения сообщают статус, конфигурацию, сеты, покрытие доменов, последние соединения, хвост лога, метрики и диагностику, а отдельный ресурс на каждую документированную настройку описывает, что она делает. Модель работает в клиентском приложении; b4 не обращается ни к какому ИИ-провайдеру и не требует API-ключа. По умолчанию выключен, авторизуется собственным токеном, потому что токен входа в веб-интерфейс сбрасывается при каждом перезапуске. Отдельный переключатель, тоже выключенный по умолчанию, разрешает запись в любую настройку внутри сета, в подсистемы MTProto и SOCKS5 и в уровень логирования; учётные данные, веб-сервер, движок захвата, бэкенд файрвола и метки пакетов отклоняются, а последнее изменение можно откатить. MCP-сервер.
  • ИСПРАВЛЕНО: Трафик, который лишь использовал порт 53, читался как запрос имени - у VPN- или прокси-туннеля, спрятанного на этом порту, зашифрованное содержимое принималось за доменное имя и сопоставлялось с сетами.
  • ИСПРАВЛЕНО: Имя сервера, прочитанное из QUIC-соединения, принималось с любым содержимым - за имя хоста проходили любые байты любой длины, в отличие от того же имени из обычного HTTPS-соединения, которое проверялось.
  • ИСПРАВЛЕНО: Telegram объявлял MTProto-прокси неправильно настроенным и отключал его - сессия принималась до того, как b4 добирался до дата-центра, а на один заблокированный маршрут отводилось больше времени, чем клиент был готов ждать.
  • ИСПРАВЛЕНО: У дата-центра 203 не было заранее готового соединения - запасные соединения держались только для двух дата-центров, поэтому каждая сессия к остальным начиналась с открытия соединения с нуля.
  • ИСПРАВЛЕНО: Маршрут, который не отвечал ничем, откладывался только если возвращал ограничение частоты запросов - замолчавший маршрут стоил каждой следующей сессии того же полного ожидания.
  • ИСПРАВЛЕНО: Имя с несколькими адресами бросалось после того, как первый из них не ответил - попытка застревала на этом адресе, хотя другой адрес того же имени отвечал меньше чем за секунду.
  • ИСПРАВЛЕНО: Справочник API на сайте документации не принимал имя пользователя и пароль b4 - учётные данные уходили в сервис как есть, вместо обмена на токен входа, поэтому окно Authorize принимало только вставленный вручную токен.
  • ИСПРАВЛЕНО: Включение и выключение SOCKS5-прокси, как и перенос его на другой порт, ничего не меняли до перезапуска b4 - настройка сохранялась, сохранение объявлялось успешным, но слушатель запускался только один раз при старте, поэтому выключенный в интерфейсе прокси продолжал принимать соединения, а включённый так и не открывал свой порт.

[1.77.0] - 2026-08-15​

  • ДОБАВЛЕНО: Кнопка «Настроить» на главной странице: панели переставляются перетаскиванием, расширяются и сужаются потягиванием за правый край по сетке из двенадцати колонок, ненужные скрываются глазом, раскладка запоминается в браузере - порядок и ширина были заданы в коде, поэтому панель, за которой хочется следить, например MTProto-прокси и устройства, которые им пользуются, стояла под списком доменов в сотни строк, не было способа поднять её выше, дать ей больше места или убрать панель, которую никто не читает, а низкая панель рядом с высокой заставляла всё, что идёт следом, ждать ниже высокой.
  • ИЗМЕНЕНО: Раскладка главной страницы хранится в конфигурации b4, а не в браузере - порядок, скрытые панели и ширина лежали только в хранилище браузера, поэтому раскладка, собранная на одной машине, отсутствовала на всех остальных, а новый браузер, приватное окно или очистка данных сайта возвращали страницу к настройкам по умолчанию. Копия в браузере по-прежнему пишется и читается, когда b4 недоступен, так что страница сохраняет вид на время перезапуска сервиса.
  • ИЗМЕНЕНО: Панели среды выполнения, живого сигнала и блэкхола строят раскладку по собственной ширине, а не по ширине окна - каждая читала брейкпоинты браузера, поэтому панель, занимающая меньше всей ширины страницы, сохраняла раскладку под целый экран, и её содержимое обрезалось по краю панели.
  • ИСПРАВЛЕНО: Пакеты, которые b4 создаёт сам, уходили с роутера через тот канал, который выбрала основная таблица маршрутизации, а не через интерфейс, назначенный сету - подделки, разрезанные сегменты и пакеты рассинхронизации b4 отправляет сам, а не пересылает, поэтому они несли только собственную метку b4, и маршрутизация сета к ним не применялась. На роутере с балансировкой двух WAN соединение открывалось через один канал, а продолжалось через другой, с другого публичного адреса, и сервер сбрасывал его; у сета с маршрутизацией через туннель эти пакеты, вместе с именем сервера внутри них, уходили через обычный канал.
  • ИЗМЕНЕНО: Метка файрвола, выбранная для сета вручную, отклоняется, и вместо неё назначается своя, если она несёт все биты метки, которой b4 помечает собственные пакеты - такие метки становились неотличимы, и трафик сета читался как пакеты, вброшенные самим b4.
  • ДОБАВЛЕНО: Включённые сеты в заголовке трассировки: домены посчитаны, а не перечислены, учётные данные прокси в файл не попадают - трассировка несла системную часть отчёта и ничего о том, что b4 велено сопоставлять, поэтому трассировку проблемного сета приходилось читать без его целей, стратегии и маршрутизации.
  • ИСПРАВЛЕНО: Сет с маршрутизацией через прокси терял два сокета и два pipe на каждое соединение, дальняя сторона которого умирала без закрытия - счёт доходил до предела открытых файлов роутера примерно за час, и b4 переставал работать до перезапуска.
  • ИЗМЕНЕНО: Проксируемое соединение, по которому нет данных ни в одну сторону, разрывается через час, а если одна из сторон уже закончила передачу - через пять минут - у связки не было никакого ограничения по времени после завершения рукопожатия с прокси.
  • ИЗМЕНЕНО: Сет, который не может достучаться до своего прокси, сообщает об этом в журнале и в диагностическом отчёте - неудачное подключение записывалось только на уровне trace, поэтому прокси, отклонявший каждую попытку, не оставлял следов при обычном уровне журнала. Трафик, попавший в сет, принимался, удерживался всё время ожидания и отбрасывался, и причины в записях не оставалось.
  • ИСПРАВЛЕНО: Сет, чьё ограничение MSS задано адресами IPv4, больше не урезает IPv6-трафик перечисленных в нём устройств - ограничение записывалось отдельно для каждого семейства адресов, и то из них, для которого у сета адресов нет, откатывалось к совпадению по одному устройству, поэтому каждое IPv6-соединение HTTPS с этого устройства урезалось значением сета независимо от того, куда оно шло.
  • ИСПРАВЛЕНО: Имя сайта, переключённого на резервный сет, по-прежнему разрешал сет, который не справлялся - закреплённые адреса, DoH-сервер и адрес пересылки резервного сета для него не спрашивались, поэтому домен, который умел разрешить только резервный сет, оставался неразрешимым при любой настройке эскалации.
  • ДОБАВЛЕНО: Непригодный ответ на запрос имени переключает сайт на резервный сет - NXDOMAIN, SERVFAIL и ответы без адреса засчитываются в переключение, а запрос, который его вызвал, отвечает уже резервный сет. Эскалация реагировала только на то, что происходит после установления соединения, а сайт, адреса которого нет, до этого не доходит.
  • ДОБАВЛЕНО: Адрес назначения, не отвечающий ни на одну попытку соединения, переключает сайт на резервный сет - b4 и раньше замечал молчащий адрес и подтверждал это пробой с самого роутера, но дальше обрыва попытки устройства это знание не шло. У самого частого способа сломать сайт, когда его адрес просто отбрасывают, пути к резервному сету не было.
  • ИСПРАВЛЕНО: Резервный сет вступал в дело только после того, как из трафика прочитан TLS-хендшейк - соединение, которое до него не доходит, и первый пакет соединения к уже переключённому сайту обрабатывал сет, который не справлялся, поэтому настройки резервного сета для стадии SYN не применялись никогда.
  • ИСПРАВЛЕНО: Порог переключения сайта брался из детекта блокировки по IP, отдельной функции, выключенной по умолчанию - у TLS-хендшейков без ответа, поддельных RST и непригодных ответов на запрос имени появилось по своему регулятору на вкладке эскалации. Единственный, что был раньше, управлял только поддельными RST, поэтому его сдвиг ничего не менял в триггере, который срабатывает чаще всех.
  • ИСПРАВЛЕНО: Выключение резервного сета уничтожало ссылку на него - при следующем сохранении ссылка стиралась, а выбрать сет заново до его включения было нельзя, поэтому сет, выключенный на минуту, приходилось привязывать вручную.
  • ИСПРАВЛЕНО: Сет, направленный через прокси, не мог эскалировать дальше - цепочка обрывалась на первом прокси-переходе, хотя рассчитана на восемь.
  • ИСПРАВЛЕНО: Маршрутизации резервного сета отдавался только тот единственный адрес, куда шло соединение - сайту за несколькими адресами приходилось падать по разу на каждый, а запись успевала истечь в фаерволе, пока переключение ещё действовало, и трафик молча возвращался на неработающий путь.
  • ИСПРАВЛЕНО: Переключение не учитывало, какие устройства занимает резервный сет - сбой у одного устройства переводил на резервный сет всю сеть.
  • ИЗМЕНЕНО: Правка сета сбрасывает только те переключения, которые она обесценила - при каждом сохранении сбрасывались все действующие переключения, включая те, которых правка не касалась.
  • ИСПРАВЛЕНО: Предупреждение о длине цепочки повторялось на каждый пакет - после прохождения всех восьми переходов каждая переотправка писала его заново.

[1.76.3] - 2026-08-14​

  • ИСПРАВЛЕНО: В режиме захвата TUN запросы имён от устройств сети оставались без ответа - ответ, который собирал b4, адресовался на внешний адрес самого роутера, а не устройству, задавшему вопрос, потому что отправителя b4 читал из пакета уже после того, как роутер подменил его на выходе. Устройство оставалось ждать запрос, который b4 забрал из сети и ответил туда, где никто не слушал.
  • ИСПРАВЛЕНО: Запрос имени, который b4 не мог связать с устройством, уничтожался, а не оставлялся в покое - отправителя в пакете уже не было, и никто не проверял, удалось ли его восстановить, прежде чем забрать запрос из сети, поэтому устройство повторяло попытку в ту же пустоту всё время, пока сет был включён.
  • ИСПРАВЛЕНО: Заблокированное имя, закреплённый адрес и подменённый ответ не доходили до устройства, которому предназначались, в режиме захвата TUN - все три доставляются пакетом, который b4 собирает сам, и у всех трёх получателем стоял адрес роутера.
  • ИСПРАВЛЕНО: Каждый запрос имени записывался на роутер, а не на устройство, которое его сделало - в колонке источника на странице «Трафик» у всех стоял внешний адрес, а сету, суженному до конкретных устройств, сопоставлять запрос было не с чем.
  • ИЗМЕНЕНО: Число одновременно разрешаемых b4 запросов имён ограничено, остальные уходят к собственному резолверу устройства нетронутыми - каждый перехваченный запрос запускал свой пятисекундный резолвер, и ничто не ограничивало их одновременное количество, поэтому один медленный или недоступный DoH-сервер превращал обычный сеанс работы в тысячи ожидающих запросов. Сет, который совпадает с большой категорией geosite и при этом перенаправляет DNS, пропускал через этот путь все имена в сети.
  • ИЗМЕНЕНО: Запрос, сделанный самим роутером, запоминается на пять минут вместо двух секунд - он записывался как неудачный и перечитывался из таблицы соединений ядра целиком каждые две секунды всё время жизни потока.
  • ИСПРАВЛЕНО: Адреса, которые b4 читал из пакета, указывали в память, куда читается следующий пакет, в режиме захвата TUN - сет, направленный через прокси или интерфейс, записывает эти адреса в фаервол из фонового потока, и к моменту записи пакет, из которого они взяты, мог быть уже заменён другим.

[1.76.2] - 2026-08-12​

  • ИСПРАВЛЕНО: В 1.76.0 и 1.76.1 перестали загружаться фото, видео и стикеры - дата-центр, из которого Telegram отдаёт медиа, адресовался под именем другого, и каждая медиа-сессия уходила туда, где обслужить её не могли.
  • ИСПРАВЛЕНО: Два адреса Telegram уходили не в тот дата-центр - они отвечают как дата-центр 4, но лежат внутри блока, который b4 считал дата-центром 2.
  • ИСПРАВЛЕНО: У большинства адресов Telegram не определялся дата-центр, и таким соединениям почти не оставалось маршрутов - b4 знал пять блоков адресов, а почти половина соединений в захвате из цензурируемой сети не попадала ни в один из них.
  • ИЗМЕНЕНО: Блок, который b4 считает дата-центром 4, сужен вчетверо - выброшенные из него 768 адресов не отвечали ни на что.
  • ИЗМЕНЕНО: Свой Cloudflare Worker пробуется последним из WebSocket-маршрутов, а не первым - Cloudflare забирает воркер посреди сессии, заметно позже установления соединения, поэтому проверку он проходил, а видео на нём не грузилось.
  • ИСПРАВЛЕНО: Маршрут, который взял запрос и не вернул ничего, всё равно получал следующее соединение - вниз ранжировался только тот, кто замолчал посреди сессии с неотвеченным запросом. Для понижения нужно, чтобы сессию оборвал сам маршрут: пока засчитывались и закрытые первым клиентом, рабочий Cloudflare Worker уходил ниже всех остальных маршрутов из-за запросов, на ответ по которым ему давали 70 мс при обычных 300.
  • ИЗМЕНЕНО: Скрипт Cloudflare Worker в документации держит релей дольше - Cloudflare мог оборвать ту его часть, что несёт данные обратно от Telegram, сразу после принятия соединения. Поставьте воркеру compatibility date 2026-04-07 или новее.
  • ИСПРАВЛЕНО: tgprobe никогда не проверял общий пул Cloudflare - он собирал конфигурацию с нуля, и все переключатели в ней читались как выключенные.
  • ИЗМЕНЕНО: У Cloudflare Worker спрашивается только адрес дата-центра, без порта - дата-центр 203 не отвечает на 5222, одном из трёх портов, на которых Telegram отдаёт один и тот же узел, поэтому передача порта убивала медиа-соединение. Скрипт в документации по Telegram снова совпадает со скриптом tg-ws-proxy, и с уже развёрнутым по любой из страниц воркером делать ничего не нужно.

[1.76.1] - 2026-08-11​

  • ИСПРАВЛЕНО: Telegram не проходил дальше загрузки, с пустым списком чатов, в режиме маршрутизации через WebSocket-мост - мост ходил только через Cloudflare Worker, а собственный маршрут Telegram, которым всё это время шёл MTProto-прокси, ему не предлагался.
  • ИСПРАВЛЕНО: Cloudflare Worker, переставший пропускать трафик, продолжал доставаться новым соединениям Telegram - сессию на мёртвом держали пять минут, прежде чем бросить.
  • ИСПРАВЛЕНО: WebSocket-мост отправлял трафик не на тот адрес дата-центра, к которому обращалось устройство - он держал один адрес на дата-центр, тогда как Telegram выдаёт много.
  • ИСПРАВЛЕНО: Соединения, которые b4 открывает для себя, уходили без единой применённой к ним меры обхода - сильнее всего это оголяло fail-open соединение, которое открывается как раз тогда, когда с адресом уже что-то не так.
  • ИСПРАВЛЕНО: b4 возвращал свои маршрутные правила на место, только когда они пропадали целиком - пропажа части правил считалась нормой.

[1.76.0] - 2026-08-10​

  • ИСПРАВЛЕНО: Любое разрешение имени занимало пять секунд, если хотя бы один сет ходил через прокси или через интерфейс - каждый ответ для такого сета записывался в файрвол из того же потока, который читает пакеты у ядра, по отдельному процессу ipset на адрес, и пока эти процессы работали, не читалось ничего. Пришедшие в это время пакеты ядро отбрасывало молча, а запрос имени, до которого b4 нет дела, проходит через эту очередь несколько раз, поэтому именно он чаще всего и терял пакет и досиживал пятисекундный повтор резолвера.
  • ИЗМЕНЕНО: Адреса из DNS-ответа записываются в файрвол в фоне и одной пачкой - те же самые адреса добавлялись заново на каждый ответ для имени, по процессу на адрес, а это на роутере почти секунда работы, повторяемая ради того, что ничего не меняет.
  • ИСПРАВЛЕНО: DNS-запрос самого роутера отдавался b4 дважды - правило, которое его перехватывает, стояло в цепочке, куда заходят из двух мест, поэтому каждый такой запрос второй раз проделывал путь до b4 и обратно впустую.
  • ИЗМЕНЕНО: Всплеск пакетов больше не переполняет b4, пока он занят - буфер передачи от ядра оставался системным по умолчанию, это несколько сотен килобайт на все пакеты сразу.
  • ИСПРАВЛЕНО: Диагностика системы сообщала, что jq и другие утилиты отсутствуют, когда они установлены на USB-накопителе - проверка не заглядывала за пределы каталогов самого роутера.
  • ДОБАВЛЕНО: Закреплённые адреса для домена - когда CDN раз за разом отвечает адресом, который отбрасывает файрвол, до сервера не доходит ни одна стратегия обхода, а из средств оставались только hosts на каждом устройстве или alias в dnsmasq на роутере, и то и другое вручную и заново при каждой смене адресов у CDN. Запись как в файле hosts, сначала адрес. Закрепление действует только на имена, которые сет уже занимает, а это легко упустить незаметно, поэтому про имя, которого сет не ловит, интерфейс скажет и предложит его добавить. Сеты > DNS.
  • ИСПРАВЛЕНО: Исправленный DNS-ответ мог назвать тот самый адрес, который b4 собирался сбросить - когда недоступны были все адреса ответа, замена бралась из запомненных для этого имени без проверки, не помечен ли какой-то из них тем временем как недоступный, поэтому устройство могло получить именно его и словить сброс на первом же пакете.
  • ИЗМЕНЕНО: Запоминается каждый адрес, встреченный в DNS-ответе, а не только тот, с которым прошло рукопожатие - у имени, в ответах на которое приходит один адрес, как у CDN Meta, не оставалось запасного варианта, когда этот адрес отбрасывали: запомнить адрес можно было только соединившись с ним, а именно соединение блокировка и обрывает.
  • ИСПРАВЛЕНО: Сообщения Telegram приходили, а фотографии, видео и стикеры не загружались - в режиме маршрутизации через WebSocket-мост - клиент помечает соединение медийным знаком номера дата-центра в своём первом рукопожатии, а b4 брал этот номер из адреса, на который клиент шёл, и в адресе такой пометки нет. Каждая медийная сессия объявлялась Telegram обычной, и отвечала на неё не та половина дата-центра. Теперь адрес решает, что это за дата-центр, а рукопожатие клиента - медийный он или нет.
  • ИСПРАВЛЕНО: TCP-соединение числилось за сетом, у которого фильтр портов его исключает - сет, суженный до одного TCP-порта или до одной версии TLS, всё равно вписывал своё имя рядом с каждым TCP-соединением, пойманным по адресу, поэтому сет, собранный только под UDP, выглядел так, будто продолжает забирать TCP уже после того, как его от TCP отвели. Само соединение при этом не трогалось - расходилось только имя в таблице.
  • ИСПРАВЛЕНО: Страница трафика ничего не говорила о судьбе DNS-запроса - какой резолвер на него ответил, пришёл ли ответ из закреплённого адреса, заменялись ли в нём недоступные адреса, был ли он превращён в NXDOMAIN или отброшен совсем: всё это записывалось в запись о соединении и выбрасывалось интерфейсом, который умел рисовать только пять известных ему отметок. В документации эти исходы значились как видимые на этой странице, а страница показывала пустую строку UDP.
  • ДОБАВЛЕНО: Страница документации про DNS - что b4 делает с разрешением имён, было описано только по кускам, рядом с каждой настройкой, к которой относится. DNS.
  • ИСПРАВЛЕНО: На некоторых системах все правила файрвола сносились и создавались заново каждые несколько секунд - цепочка, которая ловит DNS по TCP от самого роутера, создавалась с приоритетом, названным по месту, где она стоять не может, поэтому вся DNS-таблица откатывалась; монитор правил затем не находил эту таблицу и на следующем проходе восстанавливал все правила b4 с нуля, и так по кругу. В каждой такой перестройке есть момент, когда не перехватывается ничего.

[1.75.0] - 2026-08-08​

  • ИСПРАВЛЕНО: Диагностика системы сообщала, что jq, sha256sum и nohup отсутствуют, хотя они были установлены - проверка искала их в меньшем числе каталогов, чем сессия в терминале.
  • ИСПРАВЛЕНО: Домен обрабатывался не той стратегией, которую нашёл для него Дискавери - каждый результат публиковался со всеми доменами запуска, поэтому два применённых результата заявляли одни и те же домены, а победителя выбирал порядок сетов.
  • ИСПРАВЛЕНО: Сет, применённый из Дискавери, не действовал до перезапуска b4 - он сохранялся и появлялся в интерфейсе, тогда как названный им трафик продолжал уходить с прежними настройками.
  • ДОБАВЛЕНО: Предупреждение, когда один домен назван несколькими включёнными сетами - его обрабатывает только один из них, выбранный по месту в списке, а не по работающей стратегии.
  • ДОБАВЛЕНО: Переключатель «любой домен» и переключатель «любой адрес» - сет, который должен ловить всё, приходилось записывать вручную как regexp:.* или 0.0.0.0/0, и ни одна из этих форм нигде в интерфейсе не упоминается. Про вторую половину, ::/0, легко было забыть, поэтому такой сет молча пропускал трафик IPv6 мимо себя. Ввод *, any или all в любое из полей добавляет те же записи, а *.example.com сохраняется как example.com - раньше он принимался как написан и не совпадал ни с чем.
  • ИСПРАВЛЕНО: Два сета с одним и тем же диапазоном IP делили его непредсказуемо - до движка сопоставления доходил только один, причём сохранённый последним, а не тот, что стоит выше в списке. Сет, ограниченный исходными устройствами, вовсе терял диапазон в пользу общего сета под ним, и победитель мог меняться от перезапуска к перезапуску. Диапазоны одинаковой длины разбираются по порядку сетов, а сет с привязкой к устройствам получает трафик первым.
  • ИСПРАВЛЕНО: 0.0.0.0/0 в списке IP сета терялся по дороге в файрвол - ipset не умеет хранить сеть с нулевым префиксом, поэтому на роутерах с iptables маршрутный набор терял эту запись, а у MSS-клампинга и дублирования по сету пропадали заодно и все остальные: они загружаются одной пачкой, которая падает целиком. Движок сопоставления ту же запись принимал, поэтому сет ловил трафик, а его сторона в файрволе оставалась пустой. Оба варианта записываются в файрвол двумя половинами.
  • ИСПРАВЛЕНО: Сет, направленный в upstream-прокси без поддержки UDP, не оставлял в файрволе ни одного правила на роутерах с iptables - каждая синхронизация сета обрывалась на имени цепочки, отклоняющей QUIC: оно было на символ длиннее, чем допускает iptables.
  • ИСПРАВЛЕНО: DNS по TCP проходил мимо DNS-сервера сета - перехватывались только запросы по UDP, поэтому устройство, переключившееся на TCP, попадало на обычный резолвер роутера.
  • ДОБАВЛЕНО: Раздел DNS в настройках - порт для DNS по TCP, время ожидания ответа, выключатель перехвата и проверка портов, уже занятых другими службами.
  • ДОБАВЛЕНО: Исход каждого DNS-запроса в трассировке - трассировка называла домен, но не говорила, дошёл ли запрос до DNS-сервера сета или проскочил мимо.
  • ИСПРАВЛЕНО: Один отказ WebSocket-узла Telegram отключал работающий Cloudflare Worker - отказ принимался за приговор всем WebSocket-маршрутам к этому дата-центру, включая релей, который пользователь держит сам.
  • ИСПРАВЛЕНО: Адрес дата-центра Telegram на паузе получал мгновенный отказ - Telegram считал это поводом переподключиться сразу же, и лог заполнялся сотнями одинаковых строк в секунду.
  • ДОБАВЛЕНО: Прогретое запасное соединение к вашему Cloudflare Worker - одно готовое соединение на каждый Worker и дата-центр вместо рукопожатия в 65-90 мс, которое оплачивало каждое новое соединение Telegram.
  • ИСПРАВЛЕНО: Трафик к Cloudflare Worker резался на мелкие записи, по одной на сообщение Telegram - такая нарезка требовалась только собственному WebSocket-узлу Telegram.
  • ИЗМЕНЕНО: Несколько адресов Worker перебираются в случайном порядке - они перебирались строго как записаны, поэтому первый принимал весь трафик и все ограничения по частоте запросов.
  • ИСПРАВЛЕНО: Flow offloading отмечался как проблема, даже когда был настроен так, чтобы не мешать b4 - проверка не отличала быстрый путь, полностью обходящий b4, от того, который включается только после начала соединения.
  • ИЗМЕНЕНО: Обнаружение блокировки по IP охватывает и адрес, который не отвечает на SYN - функция описана для адресов, отбрасываемых файрволом на уровне IP, но считала повторы TLS ClientHello, а ClientHello появляется только после установленного рукопожатия. Блокировка по адресу убивает само рукопожатие, поэтому единственный случай, названный в описании, оказался тем самым, который проверка увидеть не могла, а ловила она блокировку с отслеживанием состояния уже после рукопожатия.
  • ДОБАВЛЕНО: Роутер сам проверяет адрес, прежде чем считать его заблокированным - отсутствие ответов у одного устройства одинаково хорошо объясняется медленным сервером, кратким сбоем маршрутизации или обрывом аплинка, поэтому решение по одному этому признаку сбрасывало соединения к адресу, с которым всё было в порядке, а аплинк, пропавший на минуту, было не отличить от разом заблокированных адресов.
  • ИСПРАВЛЕНО: Адрес, помеченный как заблокированный, оставался таким, пока к нему хоть что-то обращалось - каждая проверка кэша обновляла отметку времени, поэтому пятиминутный срок не наступал, пока устройство продолжало попытки, и ничто не перепроверяло адрес. Ложное срабатывание или уже снятая блокировка держались столько же, сколько шёл трафик.
  • ДОБАВЛЕНО: Раздел «Доступность IP» в настройках - отвечает адрес или нет, зависит от самого адреса и пути к нему, а не от сета, который его поймал, так что вердикт один на все сеты, а у срока его жизни не было собственной настройки.
  • ДОБАВЛЕНО: Переключатель, вырезающий недоступные адреса из DNS-ответов - CDN отдаёт несколько адресов, из которых файрвол отбрасывает лишь часть, поэтому одно устройство зависает на заблокированном, пока другое в той же сети открывает сайт. Рабочий адрес приходилось прописывать вручную в hosts или через alias в dnsmasq - для каждого адреса, для каждого домена и заново при каждой смене адресов у CDN.
  • ДОБАВЛЕНО: Импорт из другого инструмента - конфигурацию byedpi или zapret приходилось собирать в b4 вручную, опция за опцией. Вставленная командная строка превращается в отдельный сет на каждый профиль, а по каждой опции сообщается, перенесена она, приближена или аналога в b4 нет. Домены запрашиваются для каждого сета: списка хостов в такой командной строке обычно нет. Сеты > Импорт.

[1.74.2] - 2026-08-02​

  • ИСПРАВЛЕНО: Собственный вывод b4 заполнял память роутера - init-скрипты старых установщиков писали полный лог b4 в файл, который на OpenWrt хранится в оперативной памяти, а обновления эти скрипты не заменяли.
  • ИСПРАВЛЕНО: Перезапуск мог оставить вторую копию b4 работать рядом с первой - уходящий процесс удалял файл, по которому отслеживается запущенная служба, уже после того, как его занял преемник.
  • ИСПРАВЛЕНО: Файлы логов росли всё время работы b4 - лог ошибок сверялся с пределом размера только при запуске, лог обновлений не подрезался вовсе, а брошенные файлы трассировки оставались на диске.
  • ИСПРАВЛЕНО: Выключение «Направлять UDP через вышестоящий прокси» оставляло правила UDP в фаерволе и забирало слушателя - состояние правил определялось только адресом, портом и именем пользователя вышестоящего прокси, поэтому переключатель не перестраивал сторону фаервола, тогда как слушатель пересоздавался уже без своей UDP-половины. Совпавший UDP по-прежнему заворачивался на порт, за которым ничего нет, поэтому браузер, говорящий с маршрутизируемым сайтом по HTTP/3, высиживал тайм-аут вместо отката на TCP, а выключение опции делало сайт менее доступным, чем её включённое состояние. Изменение применялось только после перезапуска.
  • ИЗМЕНЕНО: Сет, маршрутизируемый через вышестоящий прокси только по TCP, отклоняет QUIC вместо того, чтобы пропускать его мимо - при выключенной опции «Направлять UDP через вышестоящий прокси» совпавший UDP не заворачивался вовсе, поэтому любой сайт с поддержкой HTTP/3 открывался по QUIC напрямую из роутера, пока его TCP-трафик шёл через прокси. Обход был незаметен, а браузер предпочитал его ещё месяц после одного визита, ведь сайты объявляют HTTP/3 заголовком alt-svc с большим сроком жизни. Совпавший UDP на порту 443 отклоняется с ICMP port-unreachable, что браузеры читают как сигнал откатиться на TCP. Включите опцию, если вышестоящий прокси умеет UDP ASSOCIATE.
  • ИЗМЕНЕНО: Вышестоящий прокси, не умеющий передавать UDP, сообщал об этом только на уровне trace - совпавший UDP отбрасывался без единого слова, поэтому сет, направленный на SOCKS5 только с TCP при включённой опции «Направлять UDP через вышестоящий прокси», выглядел сломанным сайтом, а не настройкой, которую надо поменять.
  • ИСПРАВЛЕНО: Трафик, передаваемый вышестоящему прокси SOCKS5, уходил напрямую по одному разу на каждый адрес за доменом - сет сопоставляет по суффиксу домена, поэтому ipinfo.io покрывает website-cdn.assets.ipinfo.io, а предварительное разрешение адресов искало только имена, записанные в самом сете. Все прочие имена узнавались по одному адресу за раз из соединений, уже ушедших мимо маршрута, и сайт, размазанный по CDN, продолжал их порождать. Имя, совпавшее с маршрутным сетом по суффиксу, разрешается целиком, и все его адреса попадают в сет.
  • ИСПРАВЛЕНО: Первое соединение после перенаправленного DNS-ответа могло проскочить мимо маршрутного сета - b4 отправлял ответ клиенту и только затем записывал адреса в сет, а такая запись вызывает бинарник nft или ipset, которому нужно больше времени, чем клиенту на отправку пакета следом за DNS-ответом.
  • ДОБАВЛЕНО: Кнопка удаления для каждой базы геоданных - скачанный geosite.dat или geoip.dat можно было только заменить, но не убрать с устройства, а смена директории назначения оставляла прежнюю копию по старому пути, ведь правка одного этого поля не даёт ничего, что можно сохранить. На роутере с малым объёмом памяти это означало две копии файла в 51 МБ, до которых из интерфейса было не добраться. Удаление стирает файл и очищает его путь и URL источника, поэтому планировщик не скачивает базу обратно, а скачивание или загрузка в другую директорию стирает копию, записанную b4 по прежнему пути.
  • ИСПРАВЛЕНО: Обновление упиралось в нехватку места на устройствах с малым объёмом памяти - рядом с новым b4 хранилась вторая копия установленного, а после неудачного обновления эта копия оставалась на устройстве.
  • ДОБАВЛЕНО: Переключатель IPv4/IPv6 в помощнике socat для DC Relay - выдаваемые команды умели ходить к Telegram только по IPv4, поэтому на VPS, у которого рабочий маршрут до дата-центров - именно IPv6, адреса приходилось искать на стороне и вставлять вручную при каждой потере хоста. Переключатель выдаёт исходящие TCP6:, а адрес DC Relay, записанный литералом IPv6 ([2001:db8::1]:7007), переводит и сторону прослушивания на TCP6-LISTEN.

[1.74.1] - 2026-07-31​

  • ИСПРАВЛЕНО: Домен, добавленный в вотчдог, значился доступным до того, как его хоть что-то проверило - запись создавалась зелёной и попадала в счётчик доступных, поэтому сайт, про который пользователь и так знает, что он заблокирован, выглядел исправным до первой проверки, а при выключенном вотчдоге - бессрочно. Домен, ожидающий первой проверки, помечается как «В очереди», а кнопка ручной проверки при выключенном вотчдоге заблокирована, раз она ничего не делала.

  • ИСПРАВЛЕНО: Вотчдог сообщал, что сайт вылечен, пока тот оставался недоступен - лечение объявляло стратегию рабочей после одной удачной загрузки, а при фильтрации, которая срабатывает не всегда, одна из двух десятков перебираемых стратегий случайно попадает в паузу. Такой результат сразу уходил в сет, домен помечался здоровым, и ничто не проверяло, работает ли после этого обычный трафик к сайту. Вылеченная стратегия обязана повторить загрузку несколько раз и пройти перепроверку через рабочий движок, иначе конфигурация возвращается назад.

  • ИСПРАВЛЕНО: Лечение могло незаметно заменить вручную настроенный сет - оно переписывало целиком разделы tcp, udp, фрагментации и подделки, а в лог выводило только название стратегии фрагментации, поэтому переход между двумя вариантами combo читался как «combo -> combo», и все остальные настроенные значения исчезали бесследно.

  • ИСПРАВЛЕНО: Загрузка, не вернувшая ничего, засчитывалась при дискавери как рабочая стратегия - ответ без объявленной длины принимался за полный, даже если не пришло ни одного байта страницы.

  • ИСПРАВЛЕНО: Поддельный пакет перед заблокированным приветствием не походил на то приветствие, которое прикрывал - он нёс ту длину, какая оказалась у поддельной нагрузки, в одном частом случае более чем вдвое превышая настоящее приветствие, из-за чего фильтру, собирающему соединение, оставалась нетронутая копия настоящих байт. Параметр сета fake_len_mode: "match" подгоняет подделку под приветствие.

  • ИСПРАВЛЕНО: TTL поддельного приветствия игнорировался, если стратегия подделки не была равна «ttl» - сет мог нести значение TTL, а его поддельный ClientHello всё равно уходил с полным системным TTL и доходил до другого конца. Поддельные SYN читают то же значение при любой стратегии, поэтому настройка выглядела рабочей, ничего не делая на том пути, который был важен. Параметр сета apply_ttl применяет его к приветствию вместе с любой стратегией подделки.

  • ДОБАВЛЕНО: Опция TCP MD5 на самом поддельном приветствии - md5_on_fake заставляет другой конец отбросить подделку, пока фильтр по пути всё равно её читает. Раньше опция ставилась только на отдельное поддельное открытие соединения и только вместе со стратегией фрагментации.

  • ИЗМЕНЕНО: Подделка и настоящий пакет больше не уходят с одинаковым идентификатором IP - одно поле выдавало их общее происхождение.

  • ДОБАВЛЕНО: Стратегии дискавери из одной подделки - подделка с низким TTL и вовсе без фрагментации, с подписью MD5 и без неё, и та же форма во всём переборе TTL по семейству. Любая стратегия с подделкой заодно разрезала приветствие, а перебор по семейству строится на базе, у которой стратегия фрагментации - combo, поэтому против фильтра, который собирает TCP достаточно хорошо, чтобы видеть сквозь любое разбиение, эта форма была недостижима на всех фазах дискавери.

  • ИЗМЕНЕНО: Позиция разреза TLS может следовать за именем домена - middle_sni у сета со стратегией фрагментации tls ставит разрез внутри имени домена, а не на фиксированном смещении от заголовка записи.

  • ДОБАВЛЕНО: Фейковый payload STUN входит в состав b4 - tls_stun.bin встроен и выбирается как «Пресет: STUN» в типах фейкового payload. Раньше его приходилось загружать как capture-файл на каждом устройстве, а сет, переданный другому человеку, приходил со ссылкой на .bin, которого у того нет.

  • ДОБАВЛЕНО: При импорте чужого сета ничего не сообщалось о том, что сет ссылается на файл payload, которого нет на устройстве - сет указывал на .bin, существовавший только на машине автора, фейковые пакеты молча собирались из встроенного payload, и сет вёл себя не так, как у того, кто им поделился. Экран импорта называет отсутствующие файлы и ведёт в настройки Payloads.

  • ИСПРАВЛЕНО: b4 не запускался на роутере OpenWRT, в ядре которого нет модуля очереди пакетов - запуск обрывался сырой ошибкой фаервола, по которой отсутствующий модуль ядра было не найти. #275

  • ИСПРАВЛЕНО: Установщик сообщал, что роутер готов, хотя b4 на нём вообще не мог работать - проверка считалась пройденной при наличии любого из трёх модулей очереди, поэтому роутер с неподходящим модулем устанавливался без замечаний и падал при первом запуске.

  • ИСПРАВЛЕНО: Отчёт диагностики не показывал номер очереди, число рабочих потоков и режим очереди - эти значения читались из ключей конфигурации, которых b4 никогда не записывал, поэтому строки пропускались на любом роутере.

  • ИСПРАВЛЕНО: Неудачный запуск оставлял часть правил фаервола b4 на роутере - если применение правил обрывалось на полпути, созданные к этому моменту таблица, цепочки и хуки оставались в фаерволе после выхода b4.

  • ИСПРАВЛЕНО: Ядро без счётчиков пакетов соединения вообще не давало b4 запуститься - правило очереди отклонялось целиком и запуск падал из-за оптимизации, без которой можно было обойтись.

  • ИЗМЕНЕНО: «Сведения о системе» показывали не те модули ядра на роутерах с одним nftables - раздел отмечал как отсутствующие модули эпохи iptables и ничего не говорил о модулях nftables, от которых b4 там зависит.

  • ИСПРАВЛЕНО: Telegram на Android мог висеть в состоянии «Подключение», когда сет направлял его во встроенный мост Telegram - мост закрывал соединения, молчавшие пять секунд, хотя Telegram открывает их заранее, ещё не имея данных для отправки. #277

  • ИСПРАВЛЕНО: Первый запрос к домену после простоя мог висеть двадцать секунд или завершаться тайм-аутом, а YouTube на Android мог несколько минут не показывать интерфейс - когда клиент отправлял TLS ClientHello, не поместившийся в один пакет, имя домена могло оказаться во втором; b4 разбирал каждый пакет отдельно и никогда их не соединял, поэтому сет не совпадал и соединение уходило вообще без стратегии обхода. Chrome меняет порядок полей внутри этого приветствия на каждом соединении, поэтому один и тот же домен то не открывался, то загружался со следующей попытки. #279 #280

  • ИСПРАВЛЕНО: Первое соединение к адресу, который b4 только что разрешил для клиента, уходило без сета, которому принадлежал домен - ни DNS-ответ, ни домен из отклонённой попытки QUIC ничем не связывались с последующим соединением, поэтому до первого соединения с читаемым именем домена трафик считался неизвестным. Это было единственное место, где уже известный b4 домен оставался неопознанным, а на Android YouTube приложение могло из-за этого несколько минут повторять попытки. Связь запоминается отдельно для каждой пары клиент-адрес и отбрасывается, если два домена на одном адресе принадлежат разным сетам. #279

  • ИСПРАВЛЕНО: Одно устройство могло решать, через какой сет пойдёт трафик другого устройства - домен, выученный для общего CDN-адреса, хранился в единственном экземпляре на всю сеть и перезаписывался тем устройством, которое подключилось последним, поэтому на адресе, отдающем и превью YouTube, и видео, выбор одного телефона применялся ко всем остальным. Доказательства, которые устройство получило само - из своих DNS-ответов или попыток QUIC - имеют приоритет над общей записью. #279

  • ИСПРАВЛЕНО: Обычное начало соединения без необходимости разбиралось и отправлялось заново - любой сет с фрагментацией или fake SNI забирал из ядра каждый пакет без содержимого и отправлял его обратно через raw-сокет, включая первый SYN, хотя ни одна из этих техник не работает с пакетом без данных.

  • ИСПРАВЛЕНО: Предупреждение «Уже существует в других сетах» пропускало пересечения, которые влияют на маршрутизацию - записи сравнивались посимвольно, тогда как трафик сопоставляется по суффиксу домена, поэтому example.com в другом сете не давал предупреждения для www.example.com. #273

  • ИСПРАВЛЕНО: Помощник socat для DC Relay выдавал команды, указывающие на неправильные серверы Telegram - он строил их из опубликованного списка прокси Telegram, адреса которого обрывают соединение сразу после handshake.

  • ИСПРАВЛЕНО: Сет, собранный из большой категории geosite, занимал в несколько раз больше памяти, чем его домены - чтение нескольких категорий из файла в 51 МБ требовало около 90 МБ, а матчер и выключенный сервер SOCKS5 держали каждый свою лишнюю копию всех доменов.

[1.73.0] - 2026-07-05​

  • ИСПРАВЛЕНО: Телефон, отвалившийся от мобильного интернета, мог оставить подключение к прокси Telegram зависшим - когда мобильный клиент сворачивал Telegram или терял сигнал, его соединение часто обрывалось без чистого закрытия, но b4 удерживал полумёртвую сессию и свой канал до Telegram открытыми много минут, иногда до повторного открытия приложения, поэтому при возврате в Telegram можно было упереться в мёртвый сокет вместо чистого переподключения.
  • ИСПРАВЛЕНО: Зависший канал до Telegram через WebSocket-мост мог заклинить сессию прокси - если этот канал застревал посреди передачи, само закрытие сессии могло заблокироваться на много минут на застрявшей записи, удерживая слот клиента и оба соединения до истечения таймаута ядра.
  • ДОБАВЛЕНО: Настраиваемые таймауты подключений MTProto - в «Настройки → MTProto» появились TCP user timeout и таймаут простоя для прокси, на случай нестандартных операторских сетей или ядер роутеров, где встроенные значения по умолчанию (около двух и пяти минут) нужно подправить или отключить.
  • ДОБАВЛЕНО: API для просмотра активных сессий и клиентов MTProto - два HTTP-эндпоинта для интеграций: GET /api/mtproto/sessions возвращает по одной записи на каждое живое клиентское соединение (IP и порт клиента, адрес назначения в Telegram, время подключения и последней активности), а GET /api/mtproto/active-clients группирует их по секрету (число активных соединений и различные IP клиентов, использующих каждый). API отдавал только число соединений на секрет, без возможности увидеть адреса клиентов за ним.

[1.72.0] - 2026-07-02​

  • ДОБАВЛЕНО: Отдельный секрет MTProto для каждого человека - прокси MTProto теперь может хранить несколько именованных секретов вместо одного общего кода. Каждому можно задать имя (например, по человеку), включить или выключить его отдельно и поделиться им отдельной ссылкой или QR-кодом, поэтому доступ можно выдавать или отзывать по одному человеку.
  • ДОБАВЛЕНО: Видно, кто пользуется прокси MTProto - на странице «Трафик» каждое соединение прокси теперь помечается использованным секретом, а новая панель на главной показывает активные соединения, всего сессий и объём данных по каждому именованному секрету.
  • ДОБАВЛЕНО: Сет теперь можно применять ко всем устройствам, кроме выбранных - в исходных устройствах сета появился новый переключатель «Все устройства, кроме выбранных». Когда он включён, сет применяется к трафику всех устройств, кроме отмеченных, а не только к отмеченным - удобно, когда одно устройство (например, рабочий ноутбук) нужно оставить в покое.
  • ИЗМЕНЕНО: Список устройств сета показывает значение MSS каждого устройства - если для устройства задан лимит MSS в «Настройки → Фильтрация устройств», таблица исходных устройств сета теперь показывает его рядом с устройством, и переключаться между страницами для проверки не нужно.
  • ДОБАВЛЕНО: Совпадение набора только по домену, без запоминания его IP - переключатель «Только по домену» в целях набора. Когда он включён, b4 определяет набор строго по видимому домену или SNI и не запоминает и не маршрутизирует IP-адреса за этими доменами. Он предназначен для общих адресов CDN (YouTube, Google): доменное видео и посторонний домен, например превью-картинки, могут делить один IP, поэтому адрес, выученный b4 для первого, утягивал второй на неверную стратегию обхода.
  • ИСПРАВЛЕНО: Расход памяти рос после сохранения настроек - сохранение конфигурации приводило к росту использования памяти b4, даже при изменениях, никак не связанных со списками блокируемых сайтов.
  • ИСПРАВЛЕНО: Сет мог перестать добавлять новые адреса на некоторых роутерах - в отдельных конфигурациях (например, b4 в контейнере на MikroTik) роутер отклонял только что обнаруженные адреса, поэтому сет, направленный через выбранный интерфейс, прокси или мост Telegram, постепенно переставал работать. Теперь эти адреса хранятся в виде, который роутер принимает. #267
  • ИСПРАВЛЕНО: Лог каждые несколько секунд повторял «Tables rules missing, restoring...» - при включённом NAT Masquerade b4 искал одно из своих правил фаервола не в том месте, считал его пропавшим и без нужды заново применял все свои правила снова и снова. На самом деле правила были на месте; теперь b4 проверяет их там, где они находятся, и бесконечное восстановление прекратилось.

[1.71.1] - 2026-06-29​

  • ДОБАВЛЕНО: «Сведения о системе» теперь показывают возможности ядра роутера - новый раздел сообщает, поддерживает ли роутер низкоуровневые функции, на которые опираются продвинутые режимы.
  • ИСПРАВЛЕНО: Мост Telegram мог медленно подключаться или обрывать передачу - в некоторых конфигурациях b4 мешал собственному соединению с Telegram, что замедляло первое подключение и иногда прерывало передачу; теперь b4 не трогает собственный трафик.
  • ИСПРАВЛЕНО: Устройство с заданным именем иногда показывалось своим адресом вместо имени - на главой и странице «Трафик» устройство, которому вы задали имя, могло отображаться обычным аппаратным адресом, пока оно не в сети (например, подключено по VPN); теперь его сохранённое имя продолжает показываться, а устройства с именем остаются в списке фильтрации устройств с пометкой «не в сети».

[1.71.0] - 2026-06-28​

  • ДОБАВЛЕНО: Страницу логов стало удобнее читать - строки логов теперь выделяются цветом по важности, а каждый тип (ошибка, предупреждение, информация и так далее) можно показать или скрыть одним кликом.
  • ДОБАВЛЕНО: Запись сессии логов с возможностью скачать и поделиться - на странице логов появилась кнопка «Начать трассировку»: она записывает всё до нажатия «Остановить и сохранить», после чего скачивается один файл логов, который можно приложить при обращении за помощью. В файл уже включены сведения о системе, а запись сама останавливается через 15 минут.
  • ДОБАВЛЕНО: NAT Masquerade теперь можно применить сразу к нескольким интерфейсам - когда NAT Masquerade включён (Настройки → Функции), можно выбрать любое сочетание сетевых интерфейсов — например, два из трёх — вместо только одного интерфейса или всех сразу.
  • ДОБАВЛЕНО: Блок «Среда выполнения» на панели мониторинга - показывает расход памяти b4 со временем, с живым графиком и парой показателей состояния, чтобы медленный рост было легко заметить.
  • ДОБАВЛЕНО: Фильтрация по устройствам (белый/чёрный список) работает в режиме TUN - список фильтрации устройств в Настройках действовал только в режиме NFQUEUE; в режиме TUN трафик каждого устройства обрабатывался независимо от выбора, поэтому выбор устройств для обхода там ни на что не влиял.
  • ИЗМЕНЕНО: Блок «Живой сигнал» переработан вокруг трафика - показатели соединений и пакетов в секунду на домашнем роутере держались у нуля и мало что говорили, поэтому уступили место живому графику трафика, общему объёму данных, доле затронутых соединений и числу активных соединений.
  • ИСПРАВЛЕНО: Память могла медленно расти, чем дольше работал b4 - несколько фоновых задач (логирование, потоковый AI-чат, Дискавери) не всегда освобождали ресурсы, из-за чего за долгое время работы расход памяти увеличивался.
  • ИСПРАВЛЕНО: После остановки b4 в режиме TUN новые страницы могли перестать открываться, тогда как уже открытые продолжали работать - при нечистой остановке (принудительное завершение или выключение, вышедшее за отведённое время) виртуальный интерфейс TUN исчезал, но его правило маршрутизации могло остаться, направляя новые соединения и DNS-запросы в путь, которого больше не существовало, пока b4 не запускали вручную заново.

[1.70.1] - 2026-06-23​

  • ДОБАВЛЕНО: Системная диагностика теперь показывает активный движок и правила фаервола, созданные b4 - на странице диагностики видно, в каком режиме работает b4 — NFQUEUE или TUN (поэтому в режиме TUN это больше не выглядит как ошибка фаервола), и приводится список правил фаервола, которые b4 сейчас поддерживает, так что проще понять, что настроено, и приложить эту информацию при обращении за помощью.
  • ИЗМЕНЕНО: Внутренние firewall-метки b4 перенесены в менее загруженный диапазон - b4 помечает свои пакеты firewall-меткой (fwmark); прежние значения пересекались с диапазоном, который используют Tailscale и некоторые другие приложения на роутере, из-за чего трафик мог маршрутизироваться неправильно при их совместной работе с b4. Внутренние метки теперь используют старшие биты, которые другие инструменты затрагивают редко.
  • ИСПРАВЛЕНО: Обход перестал работать для мобильных приложений (например, приложение YouTube на Android) на шлюзах/контейнерах с NAT Masquerade - поддельные и фрагментированные пакеты, которые b4 отправляет для обхода DPI, больше не получали публичный адрес шлюза и не доходили до сервера. В основном это затрагивало трафик QUIC, который предпочитают мобильные приложения, тогда как обычные сайты по TCP продолжали работать.
  • ИСПРАВЛЕНО: Сет мог не запускаться, если в нём смешаны список страны/сервиса и собственные адреса - если добавленный вручную адрес уже входил в выбранный список (например, адреса Instagram вместе со списком Facebook), b4 считал их пересекающимися и отказывался запускаться.
  • ИСПРАВЛЕНО: В режиме TUN все устройства отображались под публичным адресом роутера, поэтому трафик нельзя было различить по устройству - движок TUN помечает пакеты адресом WAN роутера до того, как b4 их обработает, из-за чего журнал соединений, статистика по устройствам и правила сетов с привязкой к устройству схлопывались до одного адреса и за ним терялись телефон, ноутбук или телевизор.

[1.70.0] - 2026-06-21​

  • ДОБАВЛЕНО: Новый движок для устройств без NFQUEUE - на некоторых минимальных устройствах нет модулей ядра, которые обычно нужны b4, поэтому он на них не запускался. Новый режим в «Настройки → Функции» пропускает трафик через виртуальный интерфейс (TUN). Он обрабатывает только первые пакеты каждого соединения TLS (порт 443) и DNS, как обычный движок, а не весь трафик, и не трогает маршрут по умолчанию устройства; на ядрах, которые не умеют считать пакеты по соединению, он вместо этого направляет в TUN весь маршрут по умолчанию. Подбор стратегий (Дискавери) по-прежнему требует NFQUEUE, поэтому на таких устройствах он не работает.
  • ДОБАВЛЕНО: Аплинк в режиме TUN может автоматически следовать маршруту по умолчанию - оставьте аплинк в режиме «Авто» (по умолчанию), и b4 берёт исходящий интерфейс, шлюз и адрес источника из текущего маршрута по умолчанию и переключает их при каждом изменении; выберите конкретный интерфейс, чтобы закрепить фиксированный путь. Без этого аплинк задавался один раз при запуске, поэтому переключение WAN или переподключение туннеля L2TP/PPP/VPN после старта b4 отправляло обработанный трафик по старому, уже нерабочему пути в обход b4 до ручного перезапуска.
  • ДОБАВЛЕНО: Сортируемые столбцы в режиме «Группы» на странице «Трафик» - клик по заголовку столбца сортирует сгруппированный список по этому столбцу, по возрастанию или убыванию, как уже умел «Сырой поток».
  • ИЗМЕНЕНО: Пароль веб-интерфейса теперь хранится безопасно - он хранится только в виде хеша и больше не показывается на странице настроек (оставьте поле пустым, чтобы сохранить его, или введите новый для замены).
  • ИЗМЕНЕНО: Панель мониторинга переделана на единый стиль - график скорости соединений собран вместе с ключевыми счётчиками, а все блоки используют одинаковый стиль панелей, строк и заголовков.
  • ИСПРАВЛЕНО: Перенаправление сета на шифрованный DNS (DoH) не работало в некоторых конфигурациях - запросы могли завершаться тайм-аутом или возвращаться пустыми, из-за чего страницы не открывались. Это затрагивало шлюзы и контейнеры (например, b4 в контейнере на MikroTik) с включённым NAT masquerade.
  • ИСПРАВЛЕНО: Таблица маршрутизации сета переставала обновляться сама - в некоторых конфигурациях (например, b4 в контейнере на MikroTik) адреса добавлялись только при перезапуске или включении/выключении сета, затем истекали по таймауту и больше не обновлялись. Теперь сет снова узнаёт адреса на лету из DNS-ответов.
  • ИСПРАВЛЕНО: Мост Telegram не восстанавливался после обрыва интернета - если соединение пропадало и возвращалось позже, сет с мостом Telegram не работал, пока b4 не перезапускали вручную.

[1.69.1] - 2026-06-14​

  • ИСПРАВЛЕНО: Менеджер сетов казался зависшим после включения, изменения порядка, дублирования или удаления сета - экран менялся только после того, как действие сохранялось и вся конфигурация перезапрашивалась через секунду-две, поэтому клик выглядел так, будто ничего не произошло, перетащенный сет отскакивал на старое место перед прыжком на новое, а копия появлялась из ниоткуда после паузы.
  • ИСПРАВЛЕНО: Прокси MTProto переставал подключаться к Telegram в сетях, блокирующих адреса дата-центров - в 1.69.0 прокси обращался к каждому дата-центру Telegram по его собственному адресу, который многие ограничивающие сети отбрасывают, поэтому подключения завершались тайм-аутом и Telegram не загружался через прокси.

[1.69.0] - 2026-06-14​

  • ДОБАВЛЕНО: Диагностика теперь отмечает flow offloading - на многих роутерах есть функция ускорения под названием flow offloading, которая отправляет трафик по быстрому пути в обход b4, поэтому b4 выглядит установленным и работающим, но на деле ничего не обходится (частая загадка на OpenWrt). Системная диагностика (системная информация в Настройках и экран диагностики установщика) теперь показывает, включён ли flow offloading, чтобы это можно было сразу заметить и отключить.
  • ДОБАВЛЕНО: Ограничение числа подключений для прокси MTProto - новое поле «Макс. подключений» в «Настройки -> MTProto Proxy» задаёт, сколько клиентских подключений прокси обслуживает одновременно, а значение по умолчанию увеличено с 512 до 2048, чтобы у прокси, которым пользуется много людей, был запас, прежде чем он начнёт отклонять подключения.
  • ИСПРАВЛЕНО: Маршрутизация могла конфликтовать с другим приложением на роутере, например XrayUI - трафик сета, направленный через прокси или мост Telegram, мог обрабатываться этим приложением, поэтому работал только пока оно было установлено.
  • ИСПРАВЛЕНО: Дискавери не принимало веб-адреса, содержащие запятую - некоторые вполне корректные ссылки (например, отдельные адреса изображений Google) содержат запятую, которую Дискавери принимало за разделитель между адресами и разбивало ссылку на нерабочие куски, поэтому её нельзя было добавить.
  • ИСПРАВЛЕНО: Нельзя было выбрать отдельные результаты после завершения поиска Дискавери - пока поиск шёл, можно было добавить любую из найденных конфигураций, но как только он останавливался, применить можно было только лучшую в каждой группе, а кнопки для добавления остальных пропадали. Кнопки добавления каждого результата остаются доступными и после завершения поиска.
  • ИСПРАВЛЕНО: Журнал Дискавери терялся при обновлении страницы и пропадал после завершения поиска - журнал передавался только в реальном времени, поэтому обновление страницы стирало всё показанное ранее и оставляло лишь следующую пришедшую строку, а завершённый (особенно быстрый) поиск часто вообще не показывал журнала. Теперь журнал хранится на стороне службы, поэтому весь ход поиска воспроизводится заново при открытии или обновлении страницы и остаётся доступным после завершения поиска.

[1.68.0] - 2026-06-10​

  • ИСПРАВЛЕНО: Дискавери ничего не находило на подключениях с подменой DNS - там, где провайдер подменяет DNS, Дискавери не могло определить адреса тестовых сайтов и сообщало, что ничего не работает, даже когда рабочая конфигурация существовала. Поиск адресов идёт через зашифрованный DNS, а сохранённый сет по умолчанию использует DNS-over-HTTPS.
  • ИСПРАВЛЕНО: Отмена Дискавери могла привести к падению b4 - нажатие «Отмена» во время поиска, проверявшего несколько сайтов одновременно, могло обрушить всю службу, и её приходилось перезапускать.
  • ИСПРАВЛЕНО: Остановка b4 могла оставлять его сетевые правила на роутере - очистка при завершении работы могла быть отменена в последний момент, и правила оставались после выхода.
  • ИСПРАВЛЕНО: Маршрутизация через другой интерфейс ломалась после смены его адреса - когда выбранный исходящий интерфейс (например, VPN или модем) получал новый адрес, трафик сета продолжал использовать старый до перезапуска b4.
  • ИСПРАВЛЕНО: Неполная очистка при остановке - остановка b4 (или --clear-iptables) оставляла следы: изменённые системные сетевые настройки, лишние маршрутные записи, когда два сета использовали один исходящий интерфейс, и накапливающееся сетевое правило при маршрутизации через прокси или мост.
  • ИСПРАВЛЕНО: Сохранение настроек могло привести к расхождению между сохранённой и работающей конфигурацией - изменение SOCKS5-прокси или ваших сетов (добавление доменов или IP, создание, редактирование, изменение порядка, удаление или массовое включение/выключение) могло сохранить результат, не соответствующий тому, что фактически работало.

[1.67.2] - 2026-06-10​

  • ИСПРАВЛЕНО: Обновление через веб-интерфейс сообщало об успехе, но на некоторых установках оставалась старая версия - там, где b4 не управляется обычной службой (например, при запуске прямо в контейнере), обновление заменяло программу на диске, но не перезапускало работающую копию. Теперь b4 останавливает старую копию и запускает новую, поэтому обновление действительно вступает в силу.
  • ИСПРАВЛЕНО: Накопление зависших процессов обновления - после каждой попытки обновления оставался завершённый вспомогательный процесс; теперь они очищаются.
  • ДОБАВЛЕНО: Журнал обновлений - каждое обновление через веб-интерфейс теперь пишет пошаговую трассировку в update.log в папке логов (по умолчанию /var/log/b4, очищается при каждой попытке), что значительно упрощает диагностику неудачных обновлений.
  • ДОБАВЛЕНО: Локализованный журнал изменений - веб-интерфейс теперь показывает журнал изменений на выбранном языке.
  • ИЗМЕНЕНО: Настройка логирования теперь папка, а не отдельный файл - в «Настройки → Служба» теперь указывается папка для логов (по умолчанию /var/log/b4) вместо пути к errors.log, поэтому все файлы логов b4 (ошибки, обновления и любые добавленные позже) хранятся вместе и переносятся в одном месте. Существующие конфигурации мигрируются автоматически (ваша прежняя папка сохраняется); оставьте поле пустым, чтобы отключить запись логов в файл.

[1.67.1] - 2026-06-10​

  • ИСПРАВЛЕНО: Страница «Соединения» замедлялась по мере того, как вы смотрели всё больше владельцев сетей - определение метки «AS...» для множества адресов со временем делало живой список медленным. Теперь он остаётся отзывчивым независимо от того, сколько адресов вы добавляете.
  • ИСПРАВЛЕНО: Медленные сбои страниц, когда зашифрованный DNS-сервер набора был кратковременно недоступен - запросы раньше зависали до истечения тайм-аута; теперь они сразу завершаются ошибкой вместо зависания и никогда не откатываются на обычный DNS.
  • ИСПРАВЛЕНО: Отмена «Обнаружения» не останавливала его - нажатие «Отмена» оставляло поиск работающим, поэтому запуск нового приводил к одновременной работе двух поисков с перепутанными, ненадёжными результатами. Теперь «Отмена» оперативно останавливает поиск, а новый поиск ждёт, пока предыдущий не остановится.

[1.67.0] - 2026-06-08​

  • ДОБАВЛЕНО: Зашифрованный DNS (DoH) для набора - вкладка DNS набора теперь может отправлять свои запросы имён через зашифрованное соединение DNS-over-HTTPS вместо обычного DNS-сервера по IP. Некоторые сервисы работают только при запросе через определённый резолвер (например, xbox-dns.ru для сайтов, которые говорят «недоступно в вашей стране»), а некоторые провайдеры вмешиваются в обычный DNS - зашифрованный DNS обходит и то, и другое. Переключите набор между «Обычным DNS» и «DNS-over-HTTPS», затем выберите сервер из встроенного списка или вставьте свой адрес. Затрагиваются только запросы этого набора, так что остальной ваш DNS остаётся без изменений.
  • ДОБАВЛЕНО: Привязка набора только к IPv4 или IPv6 - набор теперь можно ограничить только трафиком IPv4 или только IPv6, наряду с существующей привязкой по домену, IP и версии TLS. Некоторые сети по-разному обрабатывают IPv4 и IPv6, поэтому настройки, работающие для сайта по одному протоколу, могут отличаться по другому. Теперь вы можете создать один набор для сайта по IPv4 и отдельный набор для того же сайта по IPv6, каждый со своими параметрами. «Обнаружение» также может искать рабочую конфигурацию именно по IPv4 или IPv6 и сохраняет результат с привязкой к этой версии. По умолчанию выбрано «Любой» (оба), и выбор появляется только когда в «Настройках» включены и IPv4, и IPv6.
  • ИСПРАВЛЕНО: Отправка трафика набора на прокси не работала при включённых опциях обхода - когда набор был настроен направлять трафик через вышестоящий прокси (или мост Telegram), b4 всё равно пытался применять к этому трафику свои приёмы обхода DPI, что конфликтовало с маршрутизацией, и соединение не открывалось. Теперь b4 передаёт маршрутизируемый трафик прямо на прокси, поэтому маршрутизация работает даже с включёнными опциями обхода - и маршрутизируемые соединения по-прежнему отображаются на странице «Трафик».
  • ИСПРАВЛЕНО: Защита от RST ничего не делала на наборах, которые также использовали обход на основе SYN - если набор сочетал «Защиту от RST» с некоторыми техниками обхода TCP, защита была незаметно неактивна, потому что такие соединения не отслеживались, и сайт всё равно сбрасывался. Теперь защита от RST работает в этой комбинации. Она также блокирует соответствующий поддельный сброс, направленный на сервер назначения, а не только на ваше устройство.
  • ИСПРАВЛЕНО: Фиктивные сетевые интерфейсы отсутствовали в списках интерфейсов - фиктивный интерфейс (например, dummy0) не появлялся в «Настройках», поэтому его нельзя было выбрать для мониторинга или NAT-маскарадинга. Любой поднятый фиктивный интерфейс теперь отображается в обоих списках.
  • ИСПРАВЛЕНО: Telegram Desktop переподключался каждые 30-60 секунд через мост Telegram - фоновый keep-alive, добавленный в 1.66.0 для удержания простаивающих соединений, на самом деле отправлял сигнал, который серверы Telegram отвергали, поэтому соединение разрывалось и пересоздавалось примерно дважды в минуту (вы могли видеть мерцание частей окна Telegram). Этот keep-alive удалён, поэтому соединения снова остаются стабильными сами по себе.
  • ИСПРАВЛЕНО: Мониторинг сайта мог добавить его в блокирующий набор и сломать его - если вы мониторили сайт (например, youtube.com) и одновременно запускали набор, который блокирует или маршрутизирует трафик - например, набор блокировки рекламы на основе категории вроде category-ads-all - сторож мог принять этот набор за тот, которому принадлежит ваш сайт, потому что в списке блокировки оказался поддомен этого сайта (например, ads.youtube.com). Когда сайт «проседал» и сторож пытался его починить, он добавлял сайт в этот блокирующий набор, и сайт оказывался заблокирован вместо восстановления. Теперь сторож чинит только наборы, в которых сайт указан по имени, и никогда не трогает набор с включённой маршрутизацией, так что мониторинг больше не может испортить блокирующий или маршрутизирующий набор. Примечание: если более ранняя версия уже добавила мониторимый сайт в такой набор, удалите его оттуда вручную один раз.

[1.66.0] - 2026-06-07​

  • ДОБАВЛЕНО: Статистика блокировок на «Панели» - когда набор использует режим Block (чёрная дыра) и действительно что-то блокирует, на «Панели» теперь отображается панель «Blackhole» с общим числом заблокированных попыток, наиболее часто блокируемыми доменами и устройствами, столкнувшимися с наибольшим числом блокировок. Панель остаётся скрытой, пока нечего показать, поэтому она не загромождает страницу, когда ничего не блокируется. Заблокированные соединения также помечаются меткой «block» на странице «Трафик», чтобы вы могли заметить их в живом потоке.
  • ДОБАВЛЕНО: Управление резервной копией списка серверов Telegram - чтобы достучаться до Telegram, b4 загружает список дата-центров Telegram с официального адреса Telegram и откатывается на резервную копию, размещённую автором b4, только если тот заблокирован (lavrush.in). В «Настройки → MTProto Proxy» теперь есть переключатель «Резервное зеркало списка DC», чтобы отключить его или указать на вашу собственную копию.
  • ИСПРАВЛЕНО: Маршрутизация набора теперь учитывает ваш выбор устройств - если вы использовали «Настройки → Устройства», чтобы b4 работал только для некоторых устройств (или исключал некоторые), этот выбор игнорировался вкладкой «Маршрутизация» набора. Что бы набор ни делал с трафиком (отправлял на другой сетевой интерфейс или вышестоящий прокси, пропускал через мост Telegram или блокировал), это происходило для всех устройств независимо от выбора. Теперь маршрутизация применяется только к выбранным вами устройствам. Вы также можете задать отдельному набору собственный список устройств в его настройках, так что один набор может маршрутизировать, пропускать через мост или блокировать трафик только для конкретных устройств, не затрагивая остальные.
  • ИСПРАВЛЕНО: Сам роутер отображался как неправильно названное устройство на странице «Трафик» - b4 принимал собственный адрес роутера за обычного клиента и указывал его как отдельное устройство (иногда угадывая марку телефона), относя собственные соединения роутера к нему. Теперь b4 распознаёт свои собственные интерфейсы и помечает этот трафик просто как «Router».
  • ИСПРАВЛЕНО: Голосовые и видеозвонки Discord могли обрываться при блокировке UDP - на наборе с UDP в режиме Drop или Reject звонки Discord могли прерываться, потому что b4 не распознавал трафик звонков Discord. Теперь b4 пропускает его (когда включён «Фильтр STUN», по умолчанию), поэтому звонки продолжают работать.
  • ИСПРАВЛЕНО: b4 не запускался на некоторых роутерах Asus Merlin - на определённых прошивках (например, MerlinWRT) b4 завершался сразу после запуска и показывал запутанное сообщение об отсутствующей функции xt_connbytes, хотя роутер на самом деле её поддерживал. Настоящей причиной было использование b4 более новой опции команды файрвола, которую встроенный инструмент роутера не понимал. Теперь b4 автоматически адаптируется к собственным инструментам роутера, поэтому запускается нормально и ничего дополнительно устанавливать не нужно.
  • ИСПРАВЛЕНО: Страница «Соединения» ничего не показывала при рассинхронизации часов устройства - фильтр времени (30с / 1м / 5м / 15м) и график активности по каждому соединению сравнивали живые данные с собственными часами браузера, поэтому компьютер с часами, сбитыми хотя бы на ~30 секунд, мог видеть пустой список и пустые столбцы активности. Фильтрация и график активности теперь используют отметки времени из самих данных соединения, поэтому работают независимо от часов устройства или его часового пояса.
  • ИСПРАВЛЕНО: Устройство всё ещё могло отображаться дважды на странице «Трафик» - одно устройство иногда появлялось как две строки: один раз под своим именем и один раз под голым IP. Теперь b4 распознаёт их как одно и то же устройство и показывает его только один раз.
  • ИСПРАВЛЕНО: «Обнаружение» не находило рабочую стратегию, когда имена сайтов вводились в кавычках - если вы добавляли домены в «Обнаружение» в кавычках (например, "discord.com","youtube.com", как бывает при вставке скопированного списка), b4 сохранял кавычки как часть каждого имени, поэтому все запросы завершались неудачей, и «Обнаружение» сообщало, что ничего не работает ни для одного сайта. Окружающие кавычки теперь удаляются автоматически. #241