github DanielLavrushin/b4 v1.83.0rc1
on GitHub

pre-release3 hours ago

[1.83.0] - 2026-09-24

  • FIXED: Telegram through the MTProto proxy and the WebSocket bridge dropped connections and loaded media slowly where Telegram's own servers are blocked or unreliable - b4 tried its routes one at a time and gave Telegram's edge three seconds before Cloudflare, longer than Telegram Desktop waits, retried a dead edge every five minutes and after a single lost handshake, let its warm spares expire after 20 seconds, and the bridge kept no spares at all.
  • FIXED: A Cloudflare Worker was cut off and set aside for ten minutes in the middle of a working session - the stall check counted silence from the last byte Telegram sent, so a session that sat idle and then asked for something, or sent an acknowledgement that needs no reply, looked like a Worker that had stopped answering.
  • FIXED: Telegram through the MTProto proxy and the WebSocket bridge stopped connecting while a set covering Cloudflare was on, such as one with the cloudflare GeoIP or GeoSite category - b4's own connections to the Cloudflare-proxied domains and the Cloudflare Worker matched that set and got its faking and fragmentation, and on a network where those break Cloudflare connections every such route failed.
  • ADDED: Telegram's own WebSocket edge can be reached under another TLS name where a DPI drops the handshake for its kws*.web.telegram.org names - with a name such as sprinthost.ru, the one tg-ws-proxy uses, set under Settings, Telegram, Fronting name for Telegram's WS edge, the warm pool tries it after such a handshake goes unanswered and client sessions use it once it has carried a connection. A handshake that does not end on a telegram.org certificate is closed before any request is sent; the field is empty, and fronting off, by default.
  • ADDED: Telegram over WebSocket can be turned on with a switch under Settings, Telegram, without a set and without GeoIP or GeoSite files - it bridges Telegram for every device behind b4 and for the router itself, using Telegram's address ranges from a list b4 carries and refreshes daily from telegram.org, and the card shows whether the bridge is working and what is missing when it is not. The tab formerly named MTProto Proxy is named Telegram, the switch is system.mtproto.bridge.enabled and can be changed over MCP, and sets in the Telegram over WebSocket routing mode work as before.
  • FIXED: A proxy or Telegram over WebSocket set whose listener port was taken when b4 started sent its traffic to a closed port until the settings were saved again - b4 opened the listener once and never tried again.
  • FIXED: With device filtering in allow-list mode, the router's own connections to the targets of a proxy or Telegram over WebSocket set hung - b4 marked them for the set's listener, but the rule that hands a connection to the listener accepts only the selected devices, and the router is not one of them.
  • FIXED: The Traffic page labelled connections carried by the Telegram WebSocket bridge as -ws - every connection flag that started with mtproto was read as the MTProto proxy followed by a secret name.
  • FIXED: TUN mode did not start on routers with busybox ip, failing with invalid argument '9998' to 'table ID' - TUN used the fixed routing tables 9999 and 9998. Busybox accepts table ids only up to 1023.
  • CHANGED: TUN picks a free routing table itself - it starts at 97 and goes down, skipping tables already used by the system, another program or a set. queue.tun.route_table still sets the table by hand, and a table that is already taken is refused with the reason. The kernel's own tables 253 to 255 fall back to the automatic choice. Busybox older than 1.33 cannot run TUN at all, and the start error says so.
  • FIXED: Cleaning up after TUN removed other programs' routing rules and left some of b4's own behind - the cleanup deleted every fwmark rule pointing at tables 9999 and 9998, whoever had added it. It also missed the two rules TUN adds to the main table. A TUN start that refused a busy table still flushed that table on exit.
  • FIXED: In TUN mode a firewall restart by the router, for example after a port forward was changed on a Xiaomi router, left b4 seeing no traffic and without its masquerade, MSS clamp and routing-set rules until b4 itself was restarted - the TUN engine checked only that its capture chain existed, not what was in it, and the firewall monitor that restores the other rules, re-resolves routing-set domains and answers SIGUSR1 ran only with NFQUEUE.
  • FIXED: With TUN and device filtering on, LAN devices went uncaptured for a moment on every firewall check on routers with iptables 1.8 - the check compared MAC addresses case-sensitively, and iptables 1.8 prints them in lowercase, so the device chain was flushed and refilled every time.
  • ADDED: TUN mode shows the firewall monitor interval, and System Info shows rule restores - in TUN mode the interval appears under Settings, Firewall Features, where it cannot go below 10 seconds. System Info compares the rules in the TUN capture chain with the number b4 installed and shows how many times b4 restored its capture rules and the rules under the monitor, with the time of the last restore.
  • FIXED: In TUN mode with NAT Masquerade on and no interface selected, or with a masquerade rule of the router's own that names no outgoing interface, b4 captured traffic but no site opened through it - such a rule rewrote packets entering the TUN device to that device's own address before the TUN engine could put the uplink address on them, so b4 sent them out with a source the uplink could not answer.
  • FIXED: In TUN mode, a set's new ports, the packet limits, duplicate-to addresses, the device filter, NAT Masquerade and every MSS clamp took effect only after b4 restarted - the TUN engine read them once at start, the firewall refresh after a save only resynced routing, and the set editor does not ask for a restart.
  • ADDED: Discovery can search for a strategy for an existing set - a set can keep up to five Discovery addresses on the new Discovery tab of the set editor. Find a strategy on the set card runs Discovery on these addresses. The run tests the set's current strategy first and ends with one verdict for the whole set. MCP b4_find_bypass_strategy takes a set as well.
  • CHANGED: Replacing a set's strategy from Discovery changes only the bypass strategy - the set keeps its sites, UDP, routing and pinned addresses. Any set can be chosen, not only one that lists the site. Before, the replace also added the site to the set, removed it from other sets and copied UDP and DNS settings that Discovery never tested.
  • ADDED: The watchdog can keep a set working - with Keep this set working with the watchdog on in the set's Discovery tab, the watchdog checks the set's Discovery addresses on its schedule. When they keep failing, it runs Discovery for the set and writes in a strategy that works for every address. Then it checks the addresses again and puts the old strategy back if they still fail. The per-domain list keeps working, its entries can be moved into a set, and MCP b4_watchdog takes a set.
  • FIXED: A watchdog heal could damage the set it healed - it could write a strategy that had not passed confirmation, because the search stopped as soon as a success counter shared by all domains was high enough. It replaced the set's TCP and UDP sections whole, so the port filter, RST protection and UDP settings were lost. It saved without refreshing the firewall. A Settings or set page opened before the heal sent the old configuration back on its next save and undid the heal.
  • FIXED: After a set's strategy was changed, sites the old strategy had failed on stayed refused for up to five minutes - IP block detection had cached their addresses as blocked, and b4 answered every new connection to them with its own reset until the entry expired, whatever the new strategy.
  • FIXED: Discovery accepted local and private addresses such as 192.168.1.1 or ::1 and probed the router's own network with them - only the MCP tool refused them, and only when typed as an address. A name that resolved to such an address, or a redirect to one, was fetched by every tool.
  • FIXED: Discovery could count a strategy as working when the site redirected to the ISP's block page - the probe followed the redirect and judged only the page it ended on. The check of the redirect address itself never ran.
  • FIXED: The watchdog and the DPI Detector took a site's own redirect for the ISP's block page when its address contained a word like blocked - a redirect such as /login?reason=session_blocked matched the block-page markers even though it stayed on the same site.
  • FIXED: The DPI Detector showed Fake DNS for sites and Substituted for resolvers that had only failed to answer, and said port 53 queries reached their resolvers while all of them were answered by one redirect - a single timeout or error, never retried, counted as substitution, and the port 53 summary took the absence of rows marked as hijacked as proof that every query reached its resolver, although a redirect to a well-known resolver such as Google never marks a row.
  • FIXED: A connection that froze in the middle of a page cost every Discovery test the whole timeout - the 2-second stall check ran only after a read finished, and a read waits for data until the timeout ends. Behind a DPI that freezes connections mid-transfer, runs took longer than they had to.
  • FIXED: Send domain name to upstream changed nothing for most connections, so an upstream such as Tor received only an address and warned that the application was "giving Tor only an IP address" - the name came only from a TLS hello b4 had seen before the set took the connection over, and a connection the set diverts never passes that point.
  • FIXED: A proxy set whose targets included the address of its own upstream's server cut off every device behind the set - the connections an upstream proxy on the router, or on another device in the network, opened to its own server were diverted back into that same upstream in a loop, which held off only while the upstream kept a connection it had opened before the set came up.

What's Changed

Full Changelog: v1.82.3...v1.83.0rc1

Check out latest releases or
releases around DanielLavrushin/b4 v1.83.0rc1

Don't miss a new b4 release

NewReleases is sending notifications on new releases.

Get notifications