Expose Port on specific Interface

[kaaax0815]

I know you can expose a port on a specific interface on the host

But I want to expose a port thats bound to a specific interface inside the container.

something like this

-p <host_interface>:<host_port>:<container_interface>:<container_port>

such that if a program listens on 127.0.0.2:80 inside the container i could still export it

[thaJeztah]

such that if a program listens on 127.0.0.2:80 inside the container i could still export it

Curious; why make the program explicitly listen on a loopback address if the intent is for it to be accessible outside of the container?

[kaaax0815]

When multiple programs / or the same program twice inside the container want to bind to the same port.
i fixed it by using different ports, but thats not always easily possible

[abhigyan17]

This is a valid use case for network separation. Docker's port mapping doesn't directly support binding to specific container network interfaces, but here are some working solutions:

Solution 1: Use Docker Bridge Network with Fixed IPs

docker network create --subnet=172.20.0.0/16 mynet
docker run -it --network mynet --ip 172.20.0.2 myimage

Then inside the container, you can bind services to 172.20.0.2:80 specifically.

Solution 2: Network Namespaces (Advanced)

You can use ip netns and veth pairs to create more complex networking setups:

ip netns add container_ns
ip link add veth0 type veth peer name veth1
ip link set veth1 netns container_ns
ip netns exec container_ns ip addr add 192.168.1.2/24 dev veth1

Solution 3: Docker Compose with Custom Network

services:
  myservice:
    image: myimage
    networks:
      mynet:
        ipv4_address: 172.20.0.5
networks:
  mynet:
    driver: bridge
    ipam:
      config:
        - subnet: 172.20.0.0/16

Solution 4: Host Networking (if applicable)

For some use cases, use --network host (Linux only), but this sacrifices isolation.

The recommended approach is Solution 1 or 3 with custom Docker bridges where you assign fixed IPs to containers and bind services to those specific IPs internally.

[fabricnp]

Re: Expose Port on specific Interface (docker/cli #6696)

The existing answers address a different problem. Your question is specifically about a
service inside the container that binds to a non-default loopback address
(127.0.0.2:80) -- not a routable IP -- and you want that port reachable from outside
the container. This is a real and non-trivial problem because Docker's -p flag only
controls the host-side binding; it has no mechanism to reach into the container's network
namespace and redirect traffic from one interface to another.

Here is a precise breakdown of why the naive approaches fail, followed by three working
solutions ordered by complexity.

---

Why -p cannot solve this directly

Docker's port mapping works by installing an iptables DNAT rule on the host that
rewrites the destination IP of incoming packets to the container's routable IP (the one
assigned to eth0 inside the container, e.g. 172.17.0.2). The packet then enters the
container's network namespace addressed to 172.17.0.2:80.

If your process is listening on 127.0.0.2:80, the kernel inside the container will
drop that packet because 172.17.0.2 != 127.0.0.2. The DNAT rewrite happens before the
packet crosses the namespace boundary, so there is no Docker flag that can bridge this
gap.

---

Solution 1: socat relay inside the container (simplest, no privilege required)

Run a socat process inside the container that listens on eth0 and forwards to the
loopback address your service uses.

# In your Dockerfile or entrypoint script
RUN apt-get install -y socat   # or apk add socat on Alpine

In your entrypoint:

#!/bin/sh
# Forward from the container's routable eth0 address to the loopback alias
socat TCP-LISTEN:8080,bind=0.0.0.0,fork,reuseaddr TCP:127.0.0.2:80 &
exec your-actual-service

Then expose port 8080 from the host:

docker run -p 127.0.0.1:8080:8080 myimage

Traffic path: host:8080 -> DNAT -> container eth0:8080 -> socat -> 127.0.0.2:80

This works without any extra Linux capabilities. The tradeoff is an extra process and
one extra TCP hop inside the container.

---

Solution 2: iptables DNAT inside the container (clean, no extra process)

If your container runs with --cap-add NET_ADMIN (or --privileged), you can install
an iptables rule inside the container's own network namespace that rewrites the
destination before the packet hits the socket layer.

docker run \
  --cap-add NET_ADMIN \
  -p 127.0.0.1:8080:8080 \
  myimage

Inside the container's entrypoint, before starting your service:

#!/bin/sh

# Add the loopback alias so 127.0.0.2 is a valid local address
ip addr add 127.0.0.2/8 dev lo

# DNAT: packets arriving on eth0 port 8080 get rewritten to 127.0.0.2:80
iptables -t nat -A PREROUTING \
  -i eth0 \
  -p tcp --dport 8080 \
  -j DNAT --to-destination 127.0.0.2:80

# Allow the forwarded traffic
iptables -A FORWARD -p tcp -d 127.0.0.2 --dport 80 -j ACCEPT

exec your-actual-service

Traffic path: host:8080 -> DNAT (host) -> container eth0:8080 -> DNAT (container) ->
127.0.0.2:80

This is the cleanest solution if you control the image. No extra process, no extra TCP
round-trip. The ip addr add 127.0.0.2/8 dev lo line is required because 127.0.0.2
is not automatically configured on Linux -- only 127.0.0.1 is. Without it, the DNAT
target is unreachable and the kernel will reject the rewritten packet.

---

Solution 3: Macvlan or ipvlan network with a fixed container IP (advanced, no iptables)

If you want to avoid both extra processes and elevated capabilities, and you control the
host network, you can assign the container a real IP on your LAN and have the service
bind to that IP directly. This sidesteps the loopback problem entirely.

# Create a macvlan network attached to the host's physical interface (e.g. eth0)
docker network create \
  --driver macvlan \
  --subnet 192.168.1.0/24 \
  --gateway 192.168.1.1 \
  --opt parent=eth0 \
  macvlan_net

# Run the container with a fixed IP
docker run \
  --network macvlan_net \
  --ip 192.168.1.50 \
  myimage

The container now has 192.168.1.50 as its primary IP. Configure your service to bind
to 192.168.1.50:80 instead of 127.0.0.2:80. No port mapping is needed -- the
container is directly addressable on the LAN.

Caveats:

• The host itself cannot reach the container's macvlan IP by default (macvlan kernel
  limitation). You need a macvlan shim on the host if host-to-container communication
  is required.
• This requires the host NIC to be in promiscuous mode, which some cloud providers
  (AWS, GCP) do not allow on their virtual NICs.

---

Recommendation

Scenario	Recommended solution
No extra capabilities, quick fix	Solution 1 (socat relay)
You control the image and can add NET_ADMIN	Solution 2 (iptables DNAT inside container)
Bare-metal or VM host, need direct LAN access	Solution 3 (macvlan)

For most CI or development use cases, Solution 1 is the pragmatic choice. For production
workloads where you own the image, Solution 2 is cleaner and has lower overhead.

---

Root cause note

The reason your service binds to 127.0.0.2 in the first place is likely one of:

1. The application explicitly binds to a loopback alias for network isolation (common in
   multi-tenant or multi-instance setups where each instance gets its own loopback IP).
2. A legacy configuration that predates containerization.
3. A service mesh or sidecar pattern where the loopback alias is used for inter-process
   communication.

If you have control over the application, the simplest long-term fix is to make the bind
address configurable and set it to 0.0.0.0 (or the container's eth0 IP) when running
inside Docker. Solutions 1 and 2 above are the right answer when you do not have that
control.