[1.82.3] - 2026-09-23
- FIXED: A site with pinned addresses opened in a browser drifted to an address b4 never handed out after about a minute, and the tab ended in a timeout - only the A and AAAA queries were answered from the pin list, so the browser's parallel HTTPS query brought the site's CNAME back from the resolver, the system cache followed that CNAME on its own once the short pin answer expired, and the pins were not asked for again.
- FIXED: A pinned address the router could not reach was handed out first every time, and a browser waited on it for over two minutes before trying the next one - dead pins were left out only with IP block detection on, which it is not by default, and nothing ever checked whether a pin answered at all.
- FIXED: A site outside every set that shares an address with a pinned name went out unprotected for two minutes after each lookup of that name - the DNS hint stored for the client took precedence over the address learned from earlier traffic, and once the hello's SNI matched no set the match was dropped without falling back to it.
- ADDED: Discovery and the DPI Detector recognise a gateway in front of b4's host that terminates TCP itself - a SYN sent with a hop limit of one can only be answered by the next hop, so an address that answers it is served by a transparent proxy on that gateway (a router with its own redirect, or the ISP's edge when b4 is the router), not by the site. Discovery leaves such addresses out of the search, goes on with addresses from the ECS scan that route normally, and stops with a clear verdict when nothing is left; the Detector reports the site as
GATEWAYwith a note that no packet strategy from this host can change it. - FIXED: Discovery spent a run on two dead ends: an
http://check address whose port 80 answers everyone with a short error, and a second sweep of fake TTLs after the first had found none - the origin's403with an empty body failed every preset with "insufficient data" whatever the strategy, and the sweep's negative result was not kept between strategy families. - ADDED: Discovery history keeps the strategies that also worked, not only the winner - a site in the history expands to the alternatives its run found, up to twelve of them, and any of them can be applied from there long after the run is gone. A strategy that was already installed as a set is marked as tried, and every row shows what the site costs in the history file.
- CHANGED: Apply as a set starts on replacing the strategy of the set a site is already in, rather than only being able to create another one - the set keeps its name, its sites and its routing, so trying one strategy after another for the same site no longer leaves a trail of sets identical in everything but their targets. The one offer there was before, adding the site to a set that already carries the same strategy, never appeared at all: the comparison behind it covered the fake packet payload b4 materialises in memory for an enabled set, which a set just built by Discovery does not carry.
What's Changed
- feat: enhance service management and version handling in installer sc… by @DanielLavrushin in #363
- 1 82 3 fix by @DanielLavrushin in #365
Full Changelog: v1.82.2...v1.82.3