Bitaxe – iOS 401 Authentication Error on AxeOS Dashboard

Open `http://<miner-ip>/` in a Safari Private Window on the iPhone. Tap the tabs icon, tap `Private`, tap `+`, type or paste the AxeOS URL. Private Browsing does not share Safari's persistent credential cache, so a clean load there confirms the diagnosis: a stale `Authorization` header is being attached from regular Safari's cache. Keep using Private as a workaround until you have time for Tier 2, or jump straight to clearing site data.

Force-quit Safari and re-open. Swipe up from the bottom edge (or double-tap the home button on older iPhones) to enter the app switcher, then swipe Safari off the top. Tap Safari again. Re-load the AxeOS URL. This drops Safari's in-memory state — sometimes enough to clear a transient `Authorization` header even before you touch persistent storage.

Try the URL from a different iOS browser: Chrome iOS, Brave iOS, Firefox iOS, or Edge iOS. They all use `WKWebView` under the hood (Apple requires it on iOS) but maintain their own credential / cache layer above it. If Chrome works while Safari fails, you have isolated the bug to Safari and confirmed the miner is healthy.

Reload AxeOS using both the mDNS form and the raw-IP form. If you have been using `http://bitaxe-xxxx.local/`, switch to the numeric IP from the OLED. If you have been using the IP, try the `.local` form. The credential cache is keyed by URL form, so one of them often works while the other fails.

Settings → Safari → Clear History and Website Data → Clear History and Data. This is the correct nuclear option on iOS — there is no per-site equivalent. Confirm the prompt. You will be signed out of websites and lose tab history, but the rogue `Authorization` header for the Bitaxe IP will go with everything else. Force-quit Safari afterward, reopen, retry. This fixes the vast majority of `iOS 401 on AxeOS` reports.

Settings → Safari → Advanced → Website Data → Edit → Remove All. Subtler than the History clear above — this targets the cached request / response store specifically and leaves your bookmarks and history alone. Useful when you have already done the full History clear and the 401 still returns. Sometimes the cached `WWW-Authenticate` realm survives a History clear but not a Website Data clear.

Disable AutoFill for Safari Passwords temporarily. Settings → Passwords → Password Options → AutoFill Passwords → toggle off. This stops Safari from offering to attach saved credentials to outgoing requests on its own. Re-test AxeOS, then re-enable AutoFill if you do not want to live without it. If the 401 stops while AutoFill is off and returns when you turn it back on, you have found a saved-credential leak — go to step 8.

Audit Settings → Passwords for any entries against the miner's IP or `.local` hostname. Search the iOS password manager for the Bitaxe IP, the `.local` hostname, or anything LAN-flavoured. Delete any entries. If you are using iCloud Keychain (Settings → [your name] → iCloud → Passwords and Keychain), the same entries will be on every Apple device signed into your iCloud — purge them everywhere or they will sync back overnight.

Close the miner's URL across every iOS / iPadOS device on the same Apple ID. A 401 cached on an iPad and synced via iCloud Keychain will come back on the iPhone after you clear it. Treat the Apple ID as one cache: clear it on every device in the same session before re-testing.

Bookmark the working URL form. If you found that `.local` works and the IP does not, or vice versa, bookmark the form that works and use that bookmark exclusively from iOS. This is not a fix to the underlying bug, but it converts the failure from `it broke` to `use this bookmark` — which is sometimes all you need.

Tether the iPhone to a Mac and open Web Inspector against the failing tab. On the iPhone: Settings → Safari → Advanced → Web Inspector → On. On the Mac: Safari → Settings → Advanced → Show Develop menu. Plug iPhone into Mac via USB-C / Lightning, trust the computer, then on the Mac: Develop → <Your iPhone> → the AxeOS tab. Open the Network panel, reload the AxeOS URL, watch the request fly. The `Authorization` header (if any) and the actual response status will show whether the 401 is client-side, server-side, or proxy-injected.

Capture full request / response pairs in Web Inspector's Network panel. Click the failing request, copy headers and body, save them. Look for `Authorization: Basic <base64>`, `WWW-Authenticate: Basic realm=...`, and the response body. If the body is empty or matches AxeOS's normal HTML start but truncated, the iOS / proxy layer is the cause. If it is a generic Apache / nginx 401 page, you have a proxy or captive portal in the way that is not AxeOS at all.

Decode any base64 `Authorization` header. Copy the `Basic <base64>` string from Web Inspector and decode it (`echo "<string>" | base64 -d` on a Mac). The decoded value is `username:password` in cleartext. If it is a username from a NAS / printer / router on your LAN, you have identified the source device whose credentials Safari is leaking. Disable Basic Auth on that device — most modern NAS / IoT admin panels support session-based auth instead — to prevent Safari from ever caching the credential against that LAN host again.

Test the iPhone against a Bitaxe in AP mode. Hold BOOT on the Bitaxe at power-on (5-10 seconds depending on firmware) to force AP mode. The Bitaxe broadcasts a `Bitaxe_xxxx` SSID; join it on the iPhone. Browse `http://192.168.4.1/`. AP mode serves the same `www.bin` AxeOS UI but on a brand-new network with no cached state from your home LAN. If the 401 disappears in AP mode, the diagnosis is locked: cache against your home LAN. If it persists in AP mode, the cache is tied to the iPhone itself, not to the network.

Reflash AxeOS via the official USB-C web-flasher to rule out (very unlikely) `www.bin` corruption. Use `https://bitaxeorg.github.io/bitaxe-web-flasher/` from Chrome or Edge on a desktop. Flash the latest stable for your variant: `BM1366` = Ultra, `BM1368` = Supra, `BM1370` = Gamma / GT, `BM1397` = Max. Reflashing rarely changes the 401 behaviour because the root cause is iOS-side, but it is free, takes 60 seconds, and rules out a corrupted web partition emitting an unexpected response.

There is no Tier-4 hardware repair for this error. If you have worked through Tiers 1-3 and the 401 persists, the issue is somewhere in your iOS / iCloud / network stack that this guide cannot reach from the outside — typically a corporate MDM profile, an aggressive content filter, a captive portal that injects auth, or an iCloud Keychain entry that keeps re-syncing. D-Central cannot repair your iPhone. Book a Bitaxe consultation only if you need a written third-party diagnosis for a corporate IT or MDM escalation — we will bench-test the unit, confirm AxeOS is serving correctly to multiple device classes, and provide a written report.