Diagnostics

In the app#

Open the menu bar icon → Open → Diagnostics (or click Diagnose directly in the menu bar). Enter a hostname and TailMux reports which profile owns it and whether it's reachable — DNS resolution, ping, and an HTTP probe — through that profile. If the hostname classifies to the wrong profile, fix the suffixes under Profiles and restart the router when prompted. For path-level detail (direct vs. DERP, timing samples), use the CLI commands below.

diag path#

Run diag path first. It resolves which profile owns a hostname, whether the peer is visible in status JSON, whether the path is direct or DERP, and how long the HTTP probe took through the TailMux router.

$tailmux diag path \$  http://nas.home-lab.ts.net:8080/dashboard \$  --netcheck

diag fetch#

Use diag fetch for repeated timing samples and to compare transport modes side by side — router vs. embedded vs. the official direct client:

$tailmux diag fetch \$  --modes router,embedded,direct \$  --samples 5 \$  --timeout 25s \$  --read-limit 4194304 \$  http://nas.home-lab.ts.net:8080/dashboard

Streams & SSE#

For server-sent events and other long-lived streams, what matters is the first body byte, not total transfer time. Measure it directly:

$tailmux diag fetch \$  --modes router,direct \$  --samples 5 \$  --first-byte-only \$  http://nas.home-lab.ts.net:8080/events

Reading results#

• Owner — if the host resolves to the wrong profile, fix the suffix ownership in config.yaml rather than retrying.
• Direct vs. DERP — a DERP path adds latency; a stable profile_udp_port_base helps peer-to-peer path discovery.
• Router vs. direct — compare against the official client to decide whether the router is actually the bottleneck.