Chasing an HTTPS bug that wasn't one
The same self-hosted PWA loaded fine over HTTPS on the developer's Mac, on the Tailscale tailnet — but the iPhone browser insisted the site “couldn't be reached.” The obvious fix, blaming the fresh TLS code, was the wrong one.
First question: what exactly is the site the phone can't reach?
muxplex is a mobile-friendly, PWA-capable web dashboard for tmux, reached in a phone browser over HTTPS on the tailnet.
So the question becomes: was this dashboard actually serving?
Live probes showed muxplex listening on :8088 and Tailscale serve mapping the MagicDNS host to local services — reachability gated “tailnet only.”
If the server was serving, why was HTTPS still the first suspect?
muxplex had just added native clipboard support — and the browser Clipboard API requires a secure context. That's why muxplex setup-tls and all the fresh cert code existed at all.
Freshly-changed code is always the tempting scapegoat. So how do you clear it fairly?
tailscale cert, hostname read from tailscale status --self --json
The flagship session coordinated many subagents; foundation:explorer agents ran live network probes to clear the server before anyone touched the code.
Those read-only probes captured one line that flipped the whole case.
tailscale status to read the tailnet peer tabless -tlnp to confirm bound portstailscale serve/funnel status and docker psIn the captured tailscale status, iphone171 read “offline, last seen 16h ago” while macstudio was online. The evidence pointed away from HTTPS and toward the phone's tailnet membership.
Off the tailnet — so what actually broke first?
With the phone off the tailnet, MagicDNS couldn't resolve the spark-1 host at all. The browser never reached a server to negotiate HTTPS with. spark-1 even logged a DNS-layer health warning in the same window.
A name-resolution ghost stacked on a tailnet-membership failure — never an HTTPS bug.
Read-only recon that exonerates the server first saves you from patching innocent TLS code. The same “device not on the tailnet” failure class hits the Windows host too — it's off-tailnet and must be bridged over an SSH tunnel through WSL.
The ghost was never in the HTTPS. It was in who was — and wasn't — on the tailnet.
Data as of: 2026-07-15 (latest session referenced).
Feature status: muxplex HTTPS/TLS — SHIPPED (muxplex/tls.py, CHANGELOG.md:53, 2026-04-03..04-06). Amplifier multi-agent debugging & session recovery — OBSERVED IN PRACTICE.
Research performed:
cd ~/dev/ANext/amplifier-bundle-browser && git log --oneline (12 commits) + grep -rli 'tailscale|magicdns|iphone' . → only iPhone 14 device-emulation in context/patterns.mdgrep -in 'PWA' README.md CHANGELOG.md (README.md:19, :310); live socket ss -tlnp in session 830459e9git log --all --pretty='%ad | %an | %h | %s' | grep -iE 'tls|https|tailscale|cert|clipboard' (26 commits)sed -n '138,200p' muxplex/tls.py (reads DNSName from Self; runs tailscale cert)grep 'iphone171' ~/.amplifier/projects/*/sessions/*/transcript.jsonl (session 7084bb34) — iphone171 “offline, last seen 16h ago” vs macstudio onlinegrep "Tailscale can't reach the configured DNS servers" (session 7084bb34)~/dev/ANext/TUNNEL-ARCHITECTURE.mdevents.jsonl delegate:agent_spawned count = 31git log --all --format='%an' | sort | uniq -c | sort -rn (408 Brian Krabach; PR #4 @samueljklee)Gaps / notes: “AMP Browser” is a narrative nickname mapped to muxplex, not a shipped product name. In tailscale status, a bare “-” means ONLINE; a disconnected peer renders “offline, last seen ...”. Subagent totals differ by source (21 audited vs 31 on-disk spawn events); both confirm a large multi-agent investigation.
Primary contributors: Brian Krabach (408 muxplex commits); Samuel Lee / @samueljklee (iOS touch-scroll, PR #4); Sam Schillace / ramparte (operator on spark-1, ran the Amplifier sessions).