Skip to main content

Troubleshooting

The table names the page where each problem is solved. A site that does not open is covered on this page.

SymptomWhere it is solved
A site does not open, or stopped openingA site does not open
Status on the dashboard reads Engine failedEngine failed
No packets reached b4 in the last N min, or the Traffic page shows nothing while devices are in useb4 does not see traffic
Another message under Needs attention on the dashboardNeeds attention
Telegram does not connect, or media do not loadTelegram problems
The service or its container does not start, or a problem specific to OpenWrt, Keenetic or MikroTikRouter platforms
None of the above, or b4 itself seems at faultReporting a problem

A site does not open​

The checks go from the quickest to the slowest. The first one that fails points to the cause.

1. b4 is running​

Status on the dashboard reads Running in normal operation. Engine failed means that the packet engine did not start: the web interface works, but traffic passes through the router untouched, and no set applies. The card under the status strip shows the error, and Engine failed lists the fixes.

2. The site's connections reach a set​

  1. Open the site on a device behind the router.
  2. Open Traffic and find the site's domain. The Set column shows the set it matched.
The Traffic page showsCause and fix
The site's domains without a setThe set is off, or the site loads from domains that are not in it. The + next to a domain adds it to a set, see Adding sites to a set.
Another setThat set handles the site, and the strategy of the intended set does not apply to it. Unblocking a site shows how to write the strategy into the set that handles the site.
Nothing from the deviceb4 does not see the device's traffic, see b4 does not see traffic.

Domains not in any set on the dashboard's Activity panel opens the Traffic page with only the connections no set matched.

3. The browser opens new connections​

b4 handles only the first packets of a connection. A connection the browser opened before the set existed, or while the strategy did not work yet, gets no bypass, and the browser keeps reusing it. It keeps DNS answers for a while as well.

In Chrome, Edge and other Chromium browsers:

  1. Open chrome://net-internals/#sockets and click Flush socket pools.
  2. Open chrome://net-internals/#dns and click Clear host cache.
  3. Reload the site.

A full restart of the browser has the same effect, in Firefox as well. On Windows, ipconfig /flushdns also clears the system's DNS cache.

An address typed without https:// has one more trap. Chrome tries HTTPS first and falls back to plain HTTP when HTTPS fails, for example while the site is blocked. After that it keeps choosing HTTP for the site for some time, and the address bar can suggest the http:// address. The strategies Discovery finds are tested over HTTPS, so over plain HTTP a blocked site usually stays blocked. Typing the address with https:// opens the site over HTTPS. Shift+Delete (Shift+Fn+Delete on a Mac) removes the http:// suggestion from the address bar.

4. DNS​

b4 sees the DNS queries that devices send to port 53. A device with encrypted DNS, such as secure DNS in the browser or Android Private DNS, bypasses b4. The DNS options of the sets then do not apply to it: another resolver, pinned addresses, the IPv4 fallback. Turning encrypted DNS off on the device fixes it, see What b4 sees.

flags:dns in the filter of the Traffic page shows the lookups of the sets' domains and what b4 did with each, see Checking the result. A device whose lookups never show there uses encrypted DNS.

When the provider's DNS answers the site with wrong addresses, a set can send its domains to another resolver, see Sending a set's domains to another resolver. The DPI Detector shows whether DNS answers are forged. A device keeps an answer it already has until the answer expires.

5. IPv6​

While Enable IPv6 Support is off, b4 handles IPv4 only, and a connection over IPv6 skips every set. When the router has IPv6, the dashboard shows IPv6 traffic skips all sets under Needs attention. Force IPv4 for matched domains removes the IPv6 addresses of the sets' domains from DNS answers. A device with encrypted DNS, or with an address it already has, still connects over IPv6. Enable IPv6 Support under Settings > Core > Packet Engine brings IPv6 into the sets. In TUN mode, IPv6 always skips b4.

6. QUIC​

YouTube, Google, Discord and other sites load over QUIC (HTTP/3), which runs over UDP. On the Traffic page, such connections show UDP next to the site's domain. b4 has only weak means against QUIC. Block QUIC (force TCP) on the set's UDP tab refuses QUIC, and the browser switches to TCP at once, where the set's strategy applies.

7. The strategy still works​

A site that opened with its set and stopped later, while the Traffic page still shows that set, points to a strategy that no longer works. Find a strategy in the set card's menu, or on the set's Discovery tab, opens Discovery with the set picked. Unblocking a site walks through a run. Keeping sets working lets the watchdog search for a new strategy and write it into the set on its own.

8. The address is not blocked​

Some blocks no strategy passes. Discovery marks them on the site's card:

  • address blocked: connections to every address of the site fail.
  • intercepted by the gateway: the first hop in front of b4's host answers the connection itself. When that hop is another router, b4 has to run on it, or b4's host has to be excluded from its redirect.

Such a site needs another way out: Routing sites through a VPN or Sending sites through a SOCKS5 proxy. When the gateway intercepts and b4 already runs on the main router, only a proxy helps. The DPI Detector shows how the ISP blocks a site.

When every check passes and the site still does not open, Reporting a problem lists what to collect for a bug report.