[1.83.1] - 2026-09-27
- ADDED: When the packet engine fails to start, b4 keeps running without it, so the web interface stays reachable - the dashboard shows the reason, such as a kernel without NFQUEUE support, with a button that switches to the other engine and restarts b4, and b4 retries on its own three times within about two minutes.
- ADDED: b4 can be restarted from the web interface without a service manager, for example in Docker, in a MikroTik container or after a manual start - it restarts itself in place and keeps its process ID, so the container keeps running.
- FIXED: b4 exited at startup without showing the reason on the console, some startup errors read
%!w(...), and a failure to open the packet queue left proxy sets sending traffic to a listener that was gone - the last error went only toerrors.log, which b4 redirects stderr into, the log could not print an error that wrapped another one, and routing rules were removed only after a successful start. - FIXED: On routers where b4 runs from an init script, such as ASUS Merlin and Keenetic, every restart or update from the web interface carried the old b4's packet-sending sockets into the new one, so open sockets piled up with each restart - the sockets were not marked to close when b4 started another program, so the restart script and the b4 it launched inherited them.
- FIXED: With Allow only selected devices on under Device Filtering, connections through b4's SOCKS5 server and others the router opened itself went out directly instead of through proxy sets and Telegram over WebSocket - the rule that hands a connection to the set's listener accepted only the selected devices, while the router's own connections reach it over the loopback interface, so they hung before 1.83.0 and were left out of these sets since.
- FIXED: On iptables, a routing set that Allow only selected devices left with no device, for example because the set excludes them or because they are manually added IPv4 devices while IPv6 is on, kept the devices it had before and made b4 rebuild routing at every firewall check - the set's old jump was replaced only when the new filter produced a new one, and the check for missing rules expected a jump in every address family.
- FIXED: In TUN mode, a site of a proxy set opened through b4's SOCKS5 server timed out unless its exact name was listed in the set, and a
.onionaddress never worked through it in any mode - the SOCKS5 server looked the name up itself and connected directly, leaving it to the firewall rules to catch the address, but b4 learns a set's addresses from the DNS answers it sees, TUN mode never shows it the answers to the router's own lookups, and a.onionname has no address to look up. - FIXED: Where iptables is the nf_tables variant, as on Debian, Ubuntu and some OpenWrt builds, connections the router opened itself to a proxy set's addresses went out directly while b4 captured traffic for DPI bypass - the capture rule handed them to b4's packet queue, and a packet coming back from the queue on these systems no longer takes the route the set's mark asked for.
- FIXED: A routing set with a resolver of its own under DNS Redirect could fill with the addresses the router's resolver gave for its domains, fake ones on a network with spoofed DNS, and turning that resolver on did not look the domains up again - b4 resolved the set's domains, and the names it hands a proxy upstream as addresses, through the router's resolver, which reaches the set's resolver only when b4 intercepts its queries, not when it answers from its cache or uses DNS over TLS or HTTPS of its own.
- FIXED: Routing sets let go of addresses they should have kept: on nftables every address learned from DNS once its time to live (an hour by default) ran out after it was first seen, however often DNS returned it again, which cut live connections through proxy sets and let traffic past block sets, and on iptables an address listed in the set by hand an hour after DNS also returned it - on nftables adding an address that was already in the set again left its first expiry running, and on iptables the learned copy replaced the permanent listed entry with one that expires.
- FIXED: With net.ipv4.conf.all.src_valid_mark set to 1, as XrayUI does for a WireGuard outbound and wg-quick does, Telegram over WebSocket and proxy sets passed nothing from LAN and VPN devices, while the MTProto Proxy kept working - the kernel then checks where a diverted connection came from in the routing table the set's mark selects, and b4's table answers every address with the router itself, so each connection was dropped as having a spoofed source.
What's Changed
- fix: update Go version from 1.25.5 to 1.25.14 in Dockerfiles and go.m… by @DanielLavrushin in #376
- Refactor routing logic to enhance loopback handling and device filtering by @DanielLavrushin in #377
- feat: keep b4 running when the packet engine fails to start by @DanielLavrushin in #379
- fix(routing): keep transparent-proxy sets working with src_valid_mark=1 by @DanielLavrushin in #380
Full Changelog: v1.83.0...v1.83.1