Bitaxe – bitaxe.local Not Found on Windows / Android

Use the raw IP address instead of the hostname. The Bitaxe's OLED shows its IP on the home screen; bookmark `http://192.168.x.x/` instead of `http://bitaxe.local/`. This is not a workaround — it is the correct, OS-agnostic, router-agnostic, VLAN-agnostic way to reach AxeOS. Every operating system understands an IPv4 address; only some understand `.local`. Pick the one that always works.

Add a DHCP reservation in your router. Log into the router admin (typically `http://192.168.1.1/` or `http://192.168.0.1/`), find DHCP / LAN settings, locate the Bitaxe's MAC address (OLED, board silkscreen, or DHCP leases table), and bind it to a fixed IP. The IP never changes, the bookmark never rots, and most 'I can't reach my miner' calls disappear forever. Two minutes of setup; permanent fix.

Try a different browser. Chrome and Edge sometimes punt `.local` queries to public DNS (especially with DNS-over-HTTPS enabled) before consulting the OS resolver. Firefox and Safari handle local domains more conservatively. If `bitaxe.local` works in Safari but fails in Chrome, your Chrome DoH setting is the cause — disable secure DNS for the local network or just use the raw IP.

Test from a phone on the same WiFi. iPhones (Bonjour built in since iOS 1.0) and modern Android (8.0+) handle mDNS reliably. If `http://bitaxe.local/` works on your iPhone but not on your laptop, the laptop is the problem — install Bonjour, update Windows, or install Avahi on Linux. Phone-side success isolates the failure to the laptop OS, which is much easier to fix.

Power-cycle the router for 30 seconds. mDNS announcements get cached in router multicast tables, and a stale cache can hide a freshly-renamed Bitaxe or a recently-rebooted miner. Pull power on the router, wait 30 seconds, plug back in, wait two minutes for everything to come up, retry. This clears stale multicast state without changing any settings.

On Windows: install Bonjour Print Services or update to Windows 10 1803+. Apple's free Bonjour Print Services installer (`https://support.apple.com/kb/DL999`) adds full mDNS support to any Windows version. Or upgrade to Windows 10 build 17134 (1803, 'April 2018 Update') or later — every version since has built-in mDNS. After install, open `services.msc`, confirm 'Bonjour Service' is running, reboot, retest with `ping bitaxe.local` from `cmd.exe`.

On Linux: install and start avahi-daemon. `sudo apt install avahi-daemon libnss-mdns` (Debian/Ubuntu) or `sudo dnf install avahi nss-mdns` (Fedora/RHEL). Then `sudo systemctl enable --now avahi-daemon`. Verify `/etc/nsswitch.conf` has `mdns_minimal [NOTFOUND=return]` on the `hosts:` line — most distros add this when `libnss-mdns` is installed. Test with `avahi-browse -art | grep -i bitaxe` and `getent hosts bitaxe-<mac>.local`.

Disable AP isolation / client isolation on your WiFi. In the router admin under Wireless / WiFi settings, look for 'AP Isolation,' 'Client Isolation,' 'Wireless Isolation,' 'Guest Network Isolation,' or 'Block intra-network traffic.' Disable for any SSID your Bitaxe and your laptop both use. This setting blocks all client-to-client traffic — including multicast — and silently breaks `.local` resolution while leaving normal internet access untouched.

Force your laptop and the Bitaxe onto the same WiFi band and same VLAN. The ESP32-S3 is 2.4 GHz only. If your laptop is on 5 GHz and the AP treats the bands as separate broadcast domains, multicast won't bridge. Either join the 2.4 GHz SSID temporarily, disable band steering, or merge the SSIDs. Also confirm the Bitaxe and the laptop are on the same VLAN — many routers default WiFi clients to a 'guest' or 'IoT' VLAN that mDNS won't cross.

Disable DNS-over-HTTPS in your browser for local domains. Chrome: `chrome://settings/security` → 'Use secure DNS' → off, or whitelist the local network. Firefox: `about:preferences#privacy` → 'DNS over HTTPS' → off or 'Network only.' When DoH is enabled for everything, the browser sends `bitaxe.local` to Cloudflare, gets back `NXDOMAIN`, and never consults the OS mDNS resolver — even when Bonjour or Avahi is healthy.

Set up an mDNS reflector to bridge VLANs. If your Bitaxes live on a dedicated mining VLAN and you browse from your main LAN, install / enable an mDNS reflector. UniFi: Settings → Networks → toggle `mDNS` per network. pfSense: System → Package Manager → Avahi, configure interfaces. OPNsense: same package. OpenWrt: install `avahi-daemon` and enable `enable-reflector` in `/etc/avahi/avahi-daemon.conf`. Mikrotik: `/ip dns mdns set use-mdns=yes` plus interface bridge entries per VLAN. After setup, multicast is cloned across the L3 boundary and `.local` works LAN-wide.

Add static DNS entries on your router. Many routers (UniFi USG/UDM, pfSense, OPNsense, MikroTik, OpenWrt) let you add static DNS records on the LAN's resolver. Create entries like `bitaxe-supra.dcentral.lan → 192.168.10.7`, `bitaxe-gamma.dcentral.lan → 192.168.10.8`. Now every device on every LAN segment can reach the miner by a friendly name without any mDNS at all. This is the cleanest long-term solution for multi-Bitaxe homelabs.

Rename each Bitaxe to a unique hostname in AxeOS. `Settings → Hostname` → set to something unambiguous: `bitaxe-supra-shop`, `bitaxe-gamma-office`, `bitaxe-hex-rack-2`. This avoids hostname collisions when you have multiple miners, makes the router DHCP table readable, and makes static DNS entries trivially clear. Reboot the miner after the change so the mDNS responder re-announces with the new name.

Inspect mDNS traffic with Wireshark. If you have installed Bonjour, restarted everything, and `.local` still fails, capture multicast traffic. Wireshark filter: `udp.port == 5353`. Look for `Standard query response` packets from the Bitaxe's MAC. If you see them, the network is delivering them and the OS resolver is the problem (back to Step 6/7). If you don't see them, the router or AP is dropping multicast — focus on Step 8 and Step 11.

Disable IGMP snooping or increase the snooping TTL. Some routers default to aggressive IGMP snooping that drops mDNS announcements after seconds of silence. In the router admin under Multicast / IGMP, either disable IGMP snooping for the WiFi SSID or increase the snooping TTL. A mining LAN with one or two Bitaxes does not need IGMP snooping at all — it's a feature for IPTV-heavy networks and breaks more than it fixes on small home LANs.

Use the Bitaxe Companion Android app or a LAN scanner as a permanent workaround. The Bitaxe Companion app does its own LAN scan and raw HTTP probing — bypasses mDNS entirely. For Android users on locked-down corporate WiFi, this is often the only way to reach the dashboard from a phone. iOS users can use any LAN scanner (Fing, IP Scanner, etc.) plus Safari with the raw IP. Cross-platform tools mean you stop fighting `.local` and just find miners by IP.

Do NOT ship a working miner to D-Central because `.local` does not resolve. There is no hardware fault that manifests as 'mDNS failing while the miner hashes fine.' If the miner is on the pool, the miner is healthy. Open a free remote-support ticket at `https://d-central.tech/contact/` or hop into D-Central's Discord — we'll walk you through the router config, OS setup, or VLAN reflector setup that actually fixes it. Free for all Bitaxe customers, EN/FR support.

Provide D-Central remote-support enough info to help fast: Bitaxe variant (Supra / Ultra / Gamma / GT / Hex / Max), AxeOS firmware version (`Settings → System Info`), OLED screenshot showing IP and hostname, OS and version of the failing client (`winver` for Windows, `lsb_release -a` for Linux), router/AP make and model, and whether the network is single-subnet or VLANed. We've seen every combination — UniFi mDNS toggles, pfSense Avahi configs, Mikrotik scripts, hotel WiFi bypasses — and we'll get you to the fix without paying for shipping.