Bitaxe – AxeOS Dashboard Unreachable / Blank Web Page

Hard-refresh the browser with `Ctrl`+`Shift`+`R` on Windows/Linux or `Cmd`+`Shift`+`R` on macOS, then try the AxeOS URL in a private / incognito window or a different browser. After every OTA firmware flash, expect to do this at least once — the browser caches the old `app.js` under a hashed filename and the new page reference will not match. This alone fixes a significant fraction of 'blank AxeOS after update' reports.

Confirm the miner is online and hashing before you chase the dashboard. Look at the OLED: hashrate nonzero, IP shown, pool and worker visible. Cross-check on your pool's dashboard for a share submitted in the last 10 minutes. If the miner itself is down, back out to the 'Bitaxe Not Hashing' or 'ESP32 Crash Loop' pages — a blank dashboard is only a symptom there, not the root issue.

Find the miner's current IP. Check the OLED first — it is authoritative. If the OLED is blank or the IP is unreadable, log into your router admin and look for a client named `bitaxe-xxxx` or an ESP32-S3 MAC OUI such as `7C:DF:A1`, `DC:54:75`, or `F4:12:FA`. Update your bookmark to match. A stale bookmark pointing at a different device is the #1 cause of `ERR_CONNECTION_REFUSED` after a router reboot.

Power-cycle the Bitaxe for 30 seconds at the barrel / XT30 — not 5 seconds, not a soft reset. Pull the connector, wait 30 full seconds for the capacitors to drain and the ESP32 state to fully clear, then plug back in. Wait for the OLED to show hashing, retry `http://<miner-ip>/`. This clears the documented `esp_http_server` socket-exhaustion pattern (issue #1279 / #199) on older AxeOS builds.

Close every extra AxeOS browser tab across every machine. The ESP32-S3's HTTP server has a small connection pool (default 7 concurrent). Multiple tabs polling `/api/system/info` every second exhaust it over hours. Keep one tab open when you need it, close it when you don't. If you want a persistent monitor, scrape the API from a single source — Home Assistant, cron + curl, Grafana — instead of several browser tabs.

Update your AxeOS bookmark to use the raw IP, not `bitaxe-xxxx.local`. mDNS hostname resolution is unreliable: it works on macOS out of the box, needs Bonjour on Windows, and is filtered by many routers. `http://192.168.1.42/` is boring but reliable everywhere — and it survives the Windows / Linux / Android / iOS differences in mDNS support.

Assign the Bitaxe a DHCP reservation in your router. Find the MAC address on the OLED or in the DHCP client table and bind it to a fixed IP in the reservation table. This eliminates the 'IP changed overnight' failure forever and makes `http://<fixed-ip>/` permanently bookmarkable. Two-minute setup that saves hours over the life of the miner — do it for every Bitaxe on your network.

Verify LAN-segment health. From the same machine you browse AxeOS on: `ping <miner-ip>` should reply in under 10 ms; `curl -v http://<miner-ip>/ --max-time 10` should return HTML in under a second. Ping OK + curl hangs = the HTTP server is wedged, reboot. Ping fails = you are on a different VLAN / subnet / guest network — move to the same segment or disable AP client isolation on the router. On corporate or hotel WiFi, hotspot off your phone instead.

Test AxeOS from a second device on the same LAN — a phone, another laptop, a tablet. If every device sees a blank page, the problem is on the Bitaxe. If one device sees it fine and another doesn't, the first device is the problem: cached service worker, browser extension, stale DNS, or ad-blocker silently dropping local scripts. Clear site data for that IP on the problem device and retry.

Clear browser site data for the miner's IP. Chrome: `chrome://settings/content/all` → search the IP → Clear. Firefox: `about:preferences#privacy` → Manage Data. This nukes cached JS/CSS, stored cookies, and any service worker registered against the miner — all three can wedge AxeOS after an OTA flash even when the server-side is healthy.

Force the Bitaxe onto a dedicated 2.4 GHz SSID. The ESP32-S3 is 2.4 GHz only. On a merged 2.4/5 GHz SSID with band steering, the Bitaxe can end up on a weak edge-of-range 2.4 GHz cell with 30-40% packet loss — HTTP over a lossy link looks identical to 'dashboard unreachable.' Dedicated 2.4 GHz SSID or relocate the miner closer to the AP.

Capture a USB-C serial log. Connect USB-C data cable, open a serial terminal at 115200 baud (PuTTY, `screen /dev/ttyACM0 115200`, picocom, Arduino Serial Monitor). Reboot the miner, save the first 60 seconds. Search for `httpd_start`, `ESP_ERR_NO_MEM`, `Task watchdog got triggered`, `stratum_api`. `httpd_start: error` with no further context = corrupted `www.bin`. Watchdog triggers every N seconds = firmware crash loop (different page). No `httpd_start` line = firmware way out of date or missing web partition.

Reflash the latest stable AxeOS via the official USB-C web-flasher at `https://bitaxeorg.github.io/bitaxe-web-flasher/`. Chrome or Edge only — Web Serial API is Chromium-only. Select the correct variant by ASIC: `BM1366` = Ultra, `BM1368` = Supra, `BM1370` = Gamma and GT, `BM1397` = Max. Flashing the wrong `.bin` for the wrong chip bricks the board. `factory` flash rewrites both `esp-miner.bin` and `www.bin`.

Erase NVS and reconfigure from scratch if reflash alone did not fix it. In the web-flasher, choose 'Erase Flash' before reflashing. This wipes stored WiFi credentials, bookmarked pool URLs, and any corrupted config that survived an OTA. After reflash, connect to the `Bitaxe_xxxx` AP that appears post-boot, browse to `http://192.168.4.1/`, and reconfigure WiFi + pool + worker name.

Downgrade to the last-known-good AxeOS release if the current stable is the one that broke the dashboard. Historical regressions: `v2.11.0b1` (issue #1279) shipped an unresponsive-web-UI-after-hours bug; `v2.8.0` had an I2C race that wedged telemetry. The GitHub Releases page (`https://github.com/bitaxeorg/ESP-Miner/releases`) has every signed build — grab the release immediately before the regression.

Enable AP-mode fallback diagnostic if flashing is blocked (no data cable, web-flasher won't connect). Hold the BOOT button for 10+ seconds during power-on. The miner falls back to AP mode and serves its setup page at `http://192.168.4.1/`. Connect to the `Bitaxe_xxxx` SSID from your phone and verify the web UI works there — it is the same `www.bin`. If it works in AP mode but not in STA mode on your LAN, the problem is 100% network / router, not the miner.

Stop DIY and book D-Central Bitaxe Repair when you have reflashed twice with the correct `.bin`, the ESP32-S3 will not enumerate over USB-C on any cable or laptop with BOOT held, or the serial log shows repeated flash-read / brownout errors (`Flash read err, 1000`, `spi_flash_read: timeout`) from a known-good 5 V / 5 A PSU. At that point you have a dead ESP32-S3, a damaged flash chip, or a PCB-level fault — bench territory, not kitchen-table territory.

Ship to D-Central safely. Anti-static bag, double-box with 3 cm+ of foam on every side, include a note with: Bitaxe variant (Supra / Ultra / Gamma / GT / Hex / Max), last known working firmware version, symptom history (when it started, what you tried, what the serial log showed), pool and worker name. D-Central will bench-test the ESP32-S3 via JTAG, reflash via external USB-to-UART if the onboard USB is dead, and replace the ESP32 module if needed — saving you the cost of a full board replacement.