Consul dev mode HTTP API listening on all interfaces

The direct answer

Start the dev agent with the -client flag pointed at loopback:

consul agent -dev -client=127.0.0.1

Equivalently, in a config file loaded alongside dev mode:

client_addr = "127.0.0.1"

This is the only supported knob for the API bind address in dev mode. Dev mode exists precisely to skip the usual server hardening (no ACLs, no TLS, no gossip encryption), so anything reachable on port 8500 has full read/write access to the agent's state. Binding to 127.0.0.1 removes the network path entirely, which is the only meaningful protection when authentication is off.

What actually changes

One thing worth knowing before applying this: -client controls all client-facing listeners, not just HTTP. Setting it moves the HTTP API/UI (8500), DNS (8600), and gRPC (8502) to the same address. If your test setup has other containers resolving service DNS through this agent, they will break when DNS moves to loopback. Also note that -client is unrelated to -bind, which governs cluster Serf traffic and already defaults to 127.0.0.1 in dev mode — do not try to fix the API exposure with -bind.

If the host uses IPv6 loopback, -client=127.0.0.1 binds only IPv4. Use -client='[::1]' or pass both addresses if your tooling connects over ::1.

Confirming the bind

Three independent checks, in increasing order of confidence:

1. Startup log. The agent prints a line like client_addr: 127.0.0.1 (HTTP: 8500, DNS: 8600, gRPC: 8502). This reflects the effective configuration.
2. Socket inspection on the host:

   ss -ltn 'sport = :8500'

   The Local Address column must show 127.0.0.1:8500. If it shows 0.0.0.0:8500 or *:8500, the flag did not take effect (common cause: a config file later in the load order overriding the flag, or an old agent process still holding the port).
3. External probe. From a different host or container network:

   curl -m 2 http://<agent-host-ip>:8500/v1/status/leader

   The connection must be refused or time out. A successful response means the API is exposed regardless of what the logs claim.

You can also query the agent itself: curl -s http://127.0.0.1:8500/v1/agent/self | jq -r .Config.Addresses.HTTP should return 127.0.0.1:8500.

Automating the check in CI or staging

Because dev mode bypasses most config validation, a static lint of the config file is not sufficient — the runtime socket state is the ground truth. Two practical gates:

• Socket assertion step: after the agent starts, run ss -ltn | grep ':8500' and fail the job if the address column contains 0.0.0.0 or *. This is cheap and catches both misconfiguration and flag-override mistakes.
• Reachability probe: from a separate container on the same Docker network, attempt the /v1/status/leader curl above and assert failure. This catches cases where socket inspection is unavailable (e.g., the agent runs in a container you cannot exec into) and also validates that firewall rules are not the only thing standing between the API and the network.

One caveat to flag for review: exact log wording and the /v1/agent/self response shape vary slightly across Consul versions, so pin the parsing in your CI script to the Consul version you run and re-verify after upgrades. The ss-based check is version-independent and the more robust gate.