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

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

[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