Busymate DevTools · dashboard how-to

Egress fail posture

When a device routes traffic through an external proxy and that proxy can't be applied, one of two things happens: the device goes dark or it leaks its real IP. You now choose which — per device, from the dashboard — and the panel shows you, live, which one is happening.

01 · Where it lives

A device's Info tab → the egress panel

dash.busymate.dev→ Devices→ pick a device→ Info tab→ Proxy-admission source IPs
The device Info tab in the Busymate dashboard: status card, PAC connection test, the Proxy-admission source IPs panel, the Egress fail posture segmented control set to Auto, and the admin-only manual override form.
1 2 3 4
The real Info tab (dashboard build 784, light theme).
1The device's Info tab
2Proxy-admission source IPs — the egress panel
3Egress fail posture control + its readout
4Manual override — admins only

02 · The control

Pick one of three postures

The segmented control decides what the PAC serves when the device's external proxy can't be applied. The line under it always tells you how the choice resolved for this device.

AutoDefault

Picks the safe side for you: a device with an external proxy configured fails closed — its real IP must never show — while every other device fails open and stays online.

Ext. proxy setfail-closed
No ext. proxyfail-open
Closed

Always hold egress: the device gets a no-egress PAC, never DIRECT. The real IP cannot leak — but the device has no internet while the proxy is down.

Real IP leaksnever
Stays onlineno — holds
Open

Always stay online: the device falls back to DIRECT while the proxy is down. Best uptime — but the real IP is briefly exposed, and the panel says so in red.

Real IP leaksyes, visibly
Stays onlinealways
The Egress fail posture section: an Open / Closed / Auto segmented control with Auto selected, and two readout lines explaining that Auto resolves to fail-open for this device because no external proxy is enabled.
The control as shipped — Auto selected, with the resolved-state readout underneath.

03 · The live state

Read the chips

The panel doesn't just set the behavior — it shows which behavior is happening right now, next to the last socket IP the proxy actually saw.

ProxiedHealthy
Chips: PROXY, OK, last socket IP 203.0.113.7, IP known to allowlist. Chips in dark theme: PROXY, OK, last socket IP 203.0.113.7, IP known to allowlist.

Traffic is going through the proxy and the source IP is in the allowlist. Nothing to do.

Held (fail-closed)Safe, offline
Chips: HELD (fail-closed) — external proxy unavailable, BROKEN, last socket IP, IP not in allowlist. Chips in dark theme: HELD (fail-closed) — external proxy unavailable, BROKEN, last socket IP, IP not in allowlist.

The external proxy is unavailable and the device is safely holding — no traffic, no leak. It comes back on its own when the proxy does. Amber means "working as intended, but the device is off the air".

Egressing DIRECTReal-IP leak
Chips: DIRECT, egressing direct — external proxy not applied, BROKEN, last socket IP, IP not in allowlist. Chips in dark theme: DIRECT, egressing direct — external proxy not applied, BROKEN, last socket IP, IP not in allowlist.

An external proxy is configured but not applied — the device is on DIRECT and its real IP is exposed right now. Only possible on Open (or legacy no-posture) devices. Fix the proxy, or switch the device to Closed/Auto.

Why this exists Before this shipped, a device whose external proxy died would silently fall back to DIRECT — everything looked green while the real IP leaked. The leak is now either prevented (Closed / Auto) or a red chip you can see (Open).

04 · One rename, worth knowing

"Proxy-admission source IPs" — what the list means

The panel formerly called "Egress IPs" lists the IPs the device connects from — the addresses admitted into the proxy's CONNECT allowlist (ingress). It is not the IP a target server sees; that comes from the external proxy and is shown separately.

Your device Capture proxy Ext. proxy Target server connects FROM the IPs this panel lists (ingress allowlist) egresses via what the target sees (shown separately)
The panel describes the green hop. The target-visible IP (external-proxy country) is a different thing, shown elsewhere in the same tab.
Three source-IP rows: a PROXY-seen IP last seen 4 minutes ago; a MANUAL·DEV IP with a 3h20m expiry countdown and a Clear action; an INACTIVE proxy IP last seen 2 days ago. The same three source-IP rows in dark theme.
Each row is a source IP admitted into the proxy — with its origin badge, last-seen time, and (for manual dev entries) a TTL countdown + Clear.

05 · Automation

Also settable over MCP

The same posture is readable and writable from any MCP client (BusyBro included), so fleet-wide policy can be scripted:

get_device_egress_fail_posture { deviceUuid } set_device_egress_fail_posture { deviceUuid, posture: "open" | "closed" | "auto", confirm: true }