Bitaxe – AxeOS HTTPS Redirect Blocks Dashboard Access

Click the address bar, clear it completely (do not let auto-complete pre-fill anything), and type the full URL with explicit protocol: `http://192.168.1.42/` — substitute your miner's actual IP. Press Enter. Browsers honour an explicit `http://` token for bare-IP hosts more often than they honour an auto-completed entry from history. Bookmark the resulting URL once it loads so you do not have to retype the protocol every visit.

Open an Incognito / Private window with `Ctrl`+`Shift`+`N` (Chrome / Edge), `Ctrl`+`Shift`+`P` (Firefox), or `Cmd`+`Shift`+`N` (Safari) and try `http://<miner-ip>/`. A private window has fewer extensions active and a separate HTTPS-Only state in Firefox. If AxeOS loads in private but not normal, you are chasing an extension or stale HSTS state — proceed to Step 7 or Step 8.

Try the URL in a different browser entirely. If you live in Chrome, try Firefox; if Firefox, try Edge. Different browsers ship different HTTPS-upgrade defaults and different heuristics for bare-IP and `.local` hosts. You may find one that just works on your network — keep that browser pinned as your LAN admin tool.

Try the alternate hostname form. If you used `http://192.168.1.42/`, try `http://bitaxe-xxxx.local/` instead, or vice versa. Browsers and OS mDNS adapters apply different HTTPS-upgrade policies to bare IPs vs `.local` mDNS hostnames vs FQDNs. macOS Bonjour resolves `.local` cleanly; some Windows mDNSResponder builds treat `.local` as a private zone with stricter HTTPS-Only behaviour. Use whichever form your network/browser combo allows.

Disable HTTPS-Only Mode in Firefox: open `about:preferences#privacy`, scroll to 'HTTPS-Only Mode', and select 'Don't enable HTTPS-Only Mode' or 'Enable HTTPS-Only Mode in private windows only'. Reload `http://<miner-ip>/`. Alternatively, leave HTTPS-Only on globally and use the 'Continue to HTTP site' exception button on the interstitial each time — but that gets tedious across multiple miners.

Toggle 'Always use secure connections' off in Chrome / Edge. Open `chrome://settings/security` (or `edge://settings/privacy`), find 'Always use secure connections' under the Advanced section, and toggle it off. This is the exact equivalent of Firefox's HTTPS-Only Mode. Reload the dashboard. Re-enable globally later if you want, with a per-site exception for the Bitaxe IP.

Clear browser HSTS state for the host. In Chrome / Edge, open `chrome://net-internals/#hsts` (or `edge://net-internals/#hsts`), find the 'Delete domain security policies' field, enter `192.168.1.42` or `bitaxe-xxxx.local`, and click Delete. In Firefox, open `about:preferences#privacy` → 'Cookies and Site Data' → 'Manage Data', search for the host, and Remove. This is the most-skipped diagnostic and the fix when 'I had a Pi at this IP last year' matches your history — old HSTS state outlives old devices.

Disable browser extensions one at a time. Open the Extensions page (`chrome://extensions/`, `about:addons` in Firefox) and toggle off every extension. Reload `http://<miner-ip>/`. If AxeOS works, re-enable one extension, reload, repeat until the failure returns; that is the offender. Common offenders: HTTPS Everywhere (legacy), Privacy Badger, NoScript, uBlock Origin with custom HTTPS rules, Smart HTTPS, Cloudflare Browser Plugin. Keep that extension disabled for LAN sessions or whitelist the miner host.

Add a per-site exception. In Chrome / Edge, navigate to `chrome://settings/content/siteDetails?site=http://192.168.1.42` and set 'Insecure content' to Allow. In Firefox, visit the URL once, accept the HTTPS-Only 'Continue to HTTP site' prompt, and check the 'Don't show this for this site again' box. The exception persists across browser restarts so future visits load without prompting.

Verify with `curl -v` what the browser is actually sending. From a terminal: `curl -v http://<miner-ip>/ 2>&1 | head -40`. The first line of the request log shows `> GET / HTTP/1.1`. If `curl` succeeds with `200 OK` HTML body but the browser network tab shows a request to `https://`, you have proved the upgrade is happening client-side and not on the network — which narrows the fix to browser settings and extensions rather than network changes.

Test from a phone hotspot. Disable WiFi on your laptop, tether to your phone's mobile data, and try `http://<miner-ip>/`. If it works on the phone path and fails on your normal WiFi, your home or work network is injecting an HTTPS upgrade or rewriting traffic — proceed to the reverse-proxy fix in the next step. If it fails on both paths, the fix is purely browser-side.

Stand up Caddy as a TLS-terminating reverse proxy on any always-on LAN host (Raspberry Pi, home server, NAS). Caddyfile: `bitaxe.lan.yourdomain.com { reverse_proxy 192.168.1.42:80 }`. Caddy auto-issues a Let's Encrypt cert via DNS-01 challenge against `yourdomain.com`. Browser hits `https://bitaxe.lan.yourdomain.com`, gets a valid cert, Caddy forwards plain HTTP to the Bitaxe. Browser HTTPS-Only is satisfied; miner stays untouched. Mining Hacker move and the right answer for fleets.

Alternative: nginx with mkcert local CA if you do not own a public domain. Install mkcert and run `mkcert -install` to add a local CA to your system trust store. Then issue per-host certs with `mkcert bitaxe-01.lan` and configure nginx with `ssl_certificate` and `ssl_certificate_key` directives plus a `proxy_pass http://192.168.1.42:80;` location. Trust the local CA on every browser and laptop you use to access the dashboard.

Pin firmware to a stable AxeOS build so you do not get caught between an OTA that changes the dashboard URL structure and a browser update that tightens HTTPS upgrade. AxeOS releases are visible at `https://github.com/bitaxeorg/ESP-Miner/releases`; pin to a known-good tag. Stable behaviour beats new features when you operate at scale, especially for a fleet behind a reverse proxy where path changes ripple through your proxy config.

Set DHCP reservations for every Bitaxe at your router. Map each Bitaxe MAC to a permanent IP in the 192.168.x.x range. Bitaxe MAC OUI is usually Espressif (`24:6F:28`, `7C:DF:A1`, `94:B5:55`, etc.) — easy to identify in the router's DHCP table. Stable IPs survive HSTS confusion, browser cache wipes, and 'I forgot which one was Hex 03'. Stable IPs also let your reverse-proxy config stay valid forever.

Document the network-specific fix for your team. If you operate more than one miner at home or share access with family or a co-op, write a one-paragraph 'how to reach the dashboard on this network' note: explicit-`http://` URL, browser to use, HTTPS-Only toggle status, reverse-proxy URL if you have one. Tape it to the rack. New phone, new laptop, new family member — everybody hits the same browser quirk. The note saves the next debugging session.

When to call D-Central: ninety-nine times out of a hundred this is a browser problem and you can fix it in five minutes with Tier 1. Engage D-Central Mining Consulting when (a) you suspect your network gateway is a corporate / institutional MITM proxy and you do not have admin access to disable HTTPS interception for the LAN range, (b) you operate a small farm (5+ Bitaxe / Nerd devices) and want a turnkey reverse-proxy + monitoring + alerting stack stood up on your LAN, or (c) you have isolated the failure to a specific corporate captive portal and need a workaround that survives the IT team's next policy update.

What D-Central delivers in a Mining Consulting engagement for this scenario: a LAN-side TLS-terminating proxy (Caddy or nginx) on a Raspberry Pi or NUC, deployed and configured for your fleet; per-miner DHCP reservations applied at your router; a one-page operator runbook in your team's wiki; optional Prometheus + Grafana dashboard pulling AxeOS API metrics behind the same proxy. Two-hour engagement, mostly remote, Canada-wide and international. Book at d-central.tech/services/mining-consulting.