Android app: "Couldn't reach this computer through any available route" with zero network attempts from the app; server verified reachable (browser on same phone pairs fine) #2355

Summary

The Android app fails pairing against a self-hosted headless server with:

"Couldn't reach this computer through any available route (https://…). Keep Phone access turned on in OpenMausBot, then try again."

The app makes zero network connections when this error appears — the failure happens before any dial.

Environment

• Server: npm openmausbot 0.1.96 (Linux, serve --public-url https://… behind an nginx reverse proxy, Let's Encrypt cert)
• Phone: Android 10, Discord APK reported as v1.6
• Pairing attempted via: (1) openmausbot://pair?… deep link opened from a browser button, (2) camera QR scan of the same app link — both with fresh single-use tokens minted seconds earlier

Steps to reproduce

1. Mint a phone pairing (openmausbot pair --phone android or web UI → Settings → Remote access → Create pairing code)
2. Open the openmausbot://pair?… link / scan its QR with the app
3. Confirm screen appears with correct computer name + https:// address
4. Tap "Pair with this computer"

Expected

App dials the https origin, redeems the token, session created.

Actual

Error appears immediately; on the server:

• tcpdump (SYN capture, all interfaces): the phone opens 0 connections to the server during/after the tap — only its browser's page loads appear (same IP, same minutes)
• nginx access log: no requests from the app, ever
• journalctl -u openmausbot: no pairing attempts from the phone's IP

Verified server-side (works fine)

• GET /.well-known/openmausbot/environment → 200; /api/health → 200
• TLS: full chain served, openssl s_client -verify_return_error → Verify return code: 0 (ok)
• A browser on the same phone pairs and works full-access over the same address
• Pairing mints work via CLI, web UI, and loopback POST /api/auth/pairing
• Server is latest release (0.1.96, includes Phone pairing: dial the computer's real Wi-Fi address, try every route, keep spaces in names #2262); reproduced again after removing --no-pair from serve flags

Hypothesis

Route enumeration builds an empty/failing route list for hosted https:// origins before any dial (maybe a follow-up gap from #2262) — or something the app expects from the server is absent in the headless/npm configuration. Happy to run any diagnostic build or share full packet captures.