Does Teleport proxy public_addr omission cause unreachable advertised addresses in production?

Unreachable proxy address after omitting public_addr

A Teleport proxy that starts without public_addr may advertise an address derived from its listen interface or hostname, which works in local development but can be unreachable when the same configuration runs behind NAT, containers, or multiple network interfaces. The goal is to determine whether the proxy's automatic address inference is reliable enough for dynamically scaled production proxies, or whether explicit public_addr values should be mandated during provisioning.

The inference behavior is version-sensitive, and a loopback or host-local fallback that matches a developer workstation can mask the missing configuration until the cluster is deployed behind a load balancer or in a cloud environment. This failure mode is distinct from TLS certificate mismatches, though both can surface as generic connection errors, so verifying the advertised address is a separate diagnostic step. Setting public_addr does not update TLS certificates, firewall rules, or load balancer health checks, and it should not be conflated with independent auth_service or kubernetes_service addresses.

Does the proxy's advertised address remain routable in containerized or NAT topologies when public_addr is omitted, or is explicit configuration the only safe default for production? Which version-specific inference rules apply when the proxy has multiple interfaces? What is the recommended verification method to confirm the advertised address before clients fail to connect?