Akka HTTP bind to 127.0.0.1 versus 0.0.0.0 for container reachability

Direct answer

`127.0.0.1` is sufficient only for callers inside the same network namespace as the container, such as a sidecar in the same pod. It is not sufficient for an orchestrator, kubelet, or health probe that reaches the container by its pod IP from a different namespace. Use `0.0.0.0` for pod-reachable traffic, then limit exposure with NetworkPolicy, Service selectors, authentication, and TLS instead of relying on the bind address alone.

Likely explanation versus confirmed facts

Likely explanation: `127.0.0.1` inside a container is a distinct loopback from the host's `127.0.0.1`. A connection from another namespace to that loopback is refused or times out, which can be mistaken for an Akka HTTP fault.

Confirmed facts: `Http().newServerAt(interface, port)` binds to the literal interface supplied. `0.0.0.0` accepts IPv4 connections on every IPv4 interface and does not cover IPv6. An unset bind interface should not be assumed to default to loopback or all interfaces; behavior can depend on the Akka HTTP overload, configuration, and OS hostname resolution.

Steps for this case

1. Bind the application server to `0.0.0.0` when the orchestrator or probes contact the container by pod IP.
2. Bind Akka Management to `127.0.0.1` on a separate port only when no external probe or cluster peer requires it; otherwise bind it pod-reachably and protect it with network policy and authentication.
3. After binding, log `binding.localAddress()` and fail startup unless it equals the expected `InetSocketAddress`.
4. Inside the container, run ss -ltn and confirm the port shows `127.0.0.1:PORT` for loopback-only or `0.0.0.0:PORT` for all IPv4 interfaces.
5. From a different namespace, run curl --connect-timeout 2 http://CONTAINER_OR_POD_IP:PORT/health. Connection refused means loopback-only; success means the socket is reachable.

Assumptions and required verification

This draft assumes a recent Akka Platform release and Akka HTTP 10.x. Confirm default bind behavior for an unset interface against the target version before production rollout. Because `0.0.0.0` is IPv4-only, evaluate `::` or dual-stack behavior for the specific JVM and OS if IPv6 clients or platform components are involved.

Missing diagnostic detail: Is the orchestrator, sidecar, or probe in the same network namespace as the Akka HTTP container? If the only caller is a same-netns sidecar, `127.0.0.1` is enough. If any caller is in a different namespace, use a pod-reachable bind such as `0.0.0.0`.