Bitaxe – Port 80 Blocked by Firewall / VPN

Disconnect the corporate VPN entirely and wait 10 seconds for the OS to re-bind to the local interface, then retry `http://<bitaxe-ip>/` using the raw IP from the OLED — not `bitaxe-xxxx.local`. If AxeOS loads instantly, the VPN was the culprit. You can either toggle it off whenever you tune the Bitaxe (acceptable short-term) or move to Tier 2 for a permanent split-tunnel fix.

Always use the raw IP, never `bitaxe-xxxx.local`. Pull the IP off the Bitaxe's OLED and bookmark `http://192.168.1.42/` (or whatever your IP is). mDNS multicast traffic (224.0.0.251:5353/UDP) is one of the first things VPNs and corporate firewalls strip, and Windows without Bonjour does not resolve `.local` reliably anyway. Raw IP works on Windows, macOS, Linux, Android, and iOS without exception.

Hard-refresh the browser with `Ctrl`+`Shift`+`R` (Windows/Linux) or `Cmd`+`Shift`+`R` (macOS) and retry in a private / incognito window. Stale HSTS upgrade rules cached from another host can force the browser to silently rewrite `http://<bitaxe-ip>/` to `https://<bitaxe-ip>/`, and the connection collapses because AxeOS does not serve TLS on port 443.

Tether the laptop to your phone's hotspot (or open AxeOS in your phone's browser while the phone is on the same home WiFi). If the phone reaches AxeOS but the corporate laptop does not, you have confirmed the laptop is the constrained device — endpoint firewall, browser policy, or VPN — and can keep tuning from your phone while you work the permanent fix.

Disable browser HTTPS-Only Mode for the Bitaxe IP. Chrome: `chrome://settings/security` → 'Always use secure connections' → Off. Firefox: `about:preferences#privacy` → 'HTTPS-Only Mode' → Off (or add an exception). Edge: `edge://settings/privacy`. If the toggle is greyed out, your corporate browser policy is locking it on — file an exception request or use a personal browser profile.

Configure split-tunnel on the VPN to exclude RFC1918 ranges. On Cisco AnyConnect this is a server-pushed policy — file a ticket asking IT to add `192.168.0.0/16`, `10.0.0.0/8`, `172.16.0.0/12` to split-exclude. On Cloudflare WARP: turn off 'Include LAN' in the client settings. On NordVPN / Mullvad / Proton VPN: toggle 'Bypass LAN' or 'Allow LAN traffic.' On Tailscale exit nodes: just don't enable the exit node for home traffic.

Whitelist the Bitaxe IP in your endpoint firewall. Windows: Windows Defender Firewall → Advanced → Outbound Rules → New Rule → Custom → All programs → TCP, Specific Remote Ports `80`, Specific Remote IPs `192.168.1.42` → Allow. macOS: add the same exception in `pfctl` or the firewall GUI. The rule survives VPN reconnects and applies regardless of which interface the packet leaves through.

Disable AP client isolation on your home router. Setting is usually under WiFi → Advanced → 'AP Isolation' / 'Wireless Isolation' / 'Client Isolation' → Off. On UniFi: Network → Wireless Networks → edit SSID → Advanced → 'Client Device Isolation' → Off. On a home environment this is almost always safe to disable for the SSID the Bitaxe is on. Also test laptop-to-phone ping on the same SSID — if that fails, isolation is on regardless of the router's labeling.

Set a DHCP reservation for the Bitaxe so its IP never changes. Find the MAC address on the OLED or in the router's DHCP client list and bind it to a fixed IP in the reservation table. Bookmark `http://<fixed-ip>/`. Two-minute setup that eliminates the secondary failure mode where the IP changes overnight and your bookmark goes stale at the same time as the firewall starts misbehaving — easier to debug one variable at a time.

Use a personal browser profile or a different browser for self-hosted gear. Install a personal copy of Firefox or Brave outside of the Microsoft / Google managed-profile sync, sign in with a personal account, and access AxeOS from there. Many corporate browser policies (URLBlocklist, HttpAllowlist, HttpsOnlyMode) only apply to the managed profile — a clean personal profile bypasses them, and IT does not care because you are not touching corporate resources.

SSH-tunnel port 80 from a home Linux box. If you have a Raspberry Pi, NAS, or any always-on Linux server on the LAN, run from your laptop: `ssh -L 8080:<bitaxe-ip>:80 user@home-server`. Browse `http://localhost:8080/`. The tunnel rides on port 22 (rarely blocked) and presents AxeOS as a local service to the laptop — works through full-tunnel VPNs, corporate firewalls, and SASE proxies because they only see SSH to your home server, not HTTP to RFC1918.

Install Tailscale on the laptop and on a home node (Raspberry Pi, NAS, even an old phone). Enable subnet routing on the home node for `192.168.1.0/24`. The laptop now reaches `http://<bitaxe-ip>/` from anywhere over the WireGuard mesh. Tailscale traffic looks like normal UDP outbound, so it traverses corporate networks reliably. Free for personal use; MagicDNS handles naming. This is the easiest single-laptop bypass.

Reverse-proxy AxeOS through Caddy with TLS. On a home server, install Caddy and add a `Caddyfile` block: `bitaxe.your-domain.tld { reverse_proxy <bitaxe-ip>:80 }`. Caddy auto-provisions a Let's Encrypt cert. AxeOS becomes reachable at `https://bitaxe.your-domain.tld/` — TLS on the outside, plaintext on the inside, corporate firewall has no objection because the laptop sees a normal HTTPS connection. Add basic auth or Cloudflare Access in front for security.

Cloudflare Tunnel + Zero Trust Access. Run `cloudflared tunnel create bitaxe`, `cloudflared tunnel route dns bitaxe bitaxe.your-domain.tld`, and point the tunnel at `http://<bitaxe-ip>:80` in `~/.cloudflared/config.yml`. Add an Access policy requiring your email + 2FA. AxeOS now rides Cloudflare's HTTPS edge globally and is gated behind your identity provider — works behind every corporate firewall on Earth, including TLS-inspection proxies, because Cloudflare is on every 'allowed SaaS' allowlist.

Build a custom monitoring dashboard scraping the AxeOS REST API. Endpoints `/api/system/info`, `/api/system/restart`, `/api/system/swarm/info` return JSON. A 30-line Node / Python / Go service polling that and exposing Prometheus metrics or a Grafana panel gives you an enterprise-friendly observability path that does not touch port 80 outbound from the corporate laptop. Source: bitaxeorg/ESP-Miner README API section.

Fleet operators (5+ Bitaxes / Nerd-family miners): deploy a hardened reverse proxy + access broker. Caddy or Traefik with Authelia / Cloudflare Access for SSO, scrape every miner's API into a single Grafana dashboard, push alerts to PagerDuty / Discord. Single browser tab gives you fleet visibility from corporate laptops, hotels, phones, anywhere. Saves hours of band-aid debugging across the fleet.

Engage D-Central Mining Consulting if you have 10+ open-source miners and want a single secure pane across the fleet that works from a corporate laptop, hotel WiFi, and your phone — without you architecting it from scratch. D-Central designs and deploys the reverse-proxy + Tailscale / Cloudflare Access + Grafana stack on your hardware, locked to your identity provider. Built for solo-mining swarms, R&D labs, and Bitcoin-only homelabs across Canada and the US.

Stop DIY and book D-Central Bitaxe Repair when every bypass path has been tested (VPN off, phone hotspot, Tailscale, SSH tunnel) and AxeOS is still unreachable — that points at a fault on the Bitaxe itself: corrupted `www.bin` partition, dead `esp_http_server` on the ESP32-S3, lifted USB-C trace blocking reflash. Bench-test the ESP32, reflash via external USB-to-UART, replace the ESP32 module if needed. Ship in anti-static bag, double-boxed with note describing tested bypasses.