Binding Node.js to loopback vs all interfaces for containerized services

When running a Node.js HTTP/TCP service inside a container that is exposed through an ingress controller, the developer must choose a listen host that balances accessibility with safety. The goal is to allow the ingress and health‑check probes to reach the service while preventing the port from being listenable on any external network interface that might be publicly routable.

Binding to 127.0.0.1 (or ::1) limits connections to the local host, reducing exposure, but some container orchestrators expect the service to listen on 0.0.0.0/:: for liveness probes and for traffic to traverse the container network boundary. IPv6 dual‑stack behavior further complicates the choice because ::1 may not accept IPv4‑mapped traffic on certain kernels, and omitting the host argument can default to the unspecified address on IPv6‑capable systems.

Which host binding strategy provides the required ingress reachability without unintentionally exposing the service on a public interface? Should developers explicitly bind to both 127.0.0.1 and ::1 and rely on OS firewall rules, or is binding to 0.0.0.0/:: acceptable when the container network is isolated? How does Node.js’s default host behavior differ between IPv4‑only, IPv6‑only, and dual‑stack environments, and what verification steps are needed to confirm the intended binding?