Pod containers marked `(unreachable)` due to strict `EndpointID` check in v1.11.3 breaking `podman` compatability

Author: heyakyraCreated Jul 12, 2026Updated Jul 31, 2026

Prior to version 1.11.3, nginx-proxy worked seamlessly with podman setups where proxy containers lived outside a pod and backend applications lived inside a pod. Version 1.11.3 or some dependency apparently introduced a more aggressive network validation template block, all containers grouped inside Podman Pods seem to be completely dropped from the configuration loop, throwing a 502 Bad Gateway.

Steps to Reproduce:

  1. Create a Podman bridge network: podman network create nginx-proxy
  2. Spin up a Podman Pod attached to that network: podman pod create --name web --network nginx-proxy
  3. Launch an application container inside the pod (e.g., WordPress) using standard environment variables (VIRTUAL_HOST=example.com, VIRTUAL_PORT=80).
  4. Run nginx-proxy:latest (or v1.11.3+) globally, mounting the Podman socket (/run/podman/podman.sock:/tmp/docker.sock:ro).
  5. Run podman exec nginx-proxy nginx -T.

The generated upstream block will show:

nginx
upstream example.com {
    # Container: wp
    #     networks:
    #         nginx-proxy (unreachable)
    #     IPv4 address: (none usable)
    server 127.0.0.1 down;
}

Best guess: to maintain full compatibility across both Docker and Podman environments, the conditional statement inside nginx.tmpl should verify if a valid, usable container IP address is present before enforcing the strict network boundary check. If a container explicitly exposes an active IP value on the network interface namespace, it should be permitted to register its upstream targets