You add an allow rule to the host’s iptables INPUT chain,
but the Docker container port published with -p host:container is still unreachable.

The conclusion is simple.

Docker published port traffic is not handled by INPUT, but by FORWARD → DOCKER(-USER) chains.
So no matter how many rules you add to INPUT,
if the traffic is dropped in a Docker-related chain, it will be blocked.

---

Why INPUT Does Not Work

The typical traffic flow for Docker port publishing is as follows:

External → DNAT → FORWARD → DOCKER-USER → DOCKER → container

In other words, traffic destined for a container is not handled as a host-local process,
but as forwarded traffic.
Therefore, allow/deny control must be done in DOCKER or DOCKER-USER.

---

Quick Diagnosis

iptables -L DOCKER -n --line-numbers
iptables -L DOCKER-USER -n --line-numbers

If you see rules like the following, the system is effectively in a “block everything” state:

• -p tcp --dport 0:65535 -j DROP
• unconditional broad DROP rules

---

The Most Dangerous Pitfall (Important)

❌ Do NOT block traffic in DOCKER-USER using only --dport

The following rule is common, but dangerous in production:

iptables -I DOCKER-USER -p tcp --dport 8080 -j DROP

Reason

The DOCKER-USER chain is evaluated after DNAT is applied.
At this point, --dport 8080 refers to the container’s internal port, not the external port.

This leads to situations like:

• Container A: -p 9000:8080
• Container B: -p 8080:8080

Intent: “Block only external port 8080”
Reality: All containers using internal port 8080 are blocked

When this happens in production,
services that were separated only by external ports can all go down at once.

---

Safe Pattern (Recommended)

Principles

Although the rules below are syntactically valid if you replace DOCKER-USER with DOCKER,
using DOCKER-USER is strongly recommended in production.

• Allow ESTABLISHED,RELATED traffic first
• Narrow the target by container IP, not just port
• End with RETURN

Example: Controlling a Specific Container

# Allow response traffic
iptables -I DOCKER-USER 1 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

# Target a specific container IP
iptables -I DOCKER-USER 2 -d 172.17.0.10/32 -p tcp --dport 8080 -s 203.0.113.10/32 -j ACCEPT
iptables -I DOCKER-USER 3 -d 172.17.0.10/32 -p tcp --dport 8080 -j DROP

# Return to Docker’s default flow
iptables -A DOCKER-USER -j RETURN

Key point

Instead of controlling traffic by external port,
control it by which container the traffic is destined for.
This avoids side effects in a DNAT-based architecture.

---

Tip (Operational Consideration)

Container internal IPs can change when containers are recreated or when the server is rebooted.
In production environments, it is recommended to ensure stability using one of the following:

• User-defined bridge network with static IP assignment (most recommended)
• Or, if external-port–based matching is required, consider rules based on conntrack original tuples (e.g. --ctorigdstport)
  (Note: behavior may vary depending on conntrack entries, kernel modules, and rule placement, so testing is mandatory.)

---

Rule Persistence (Reboot Safety)

Rules in DOCKER / DOCKER-USER may be lost after a reboot.
Save them using the following command:

netfilter-persistent save

---

One-Line Summary

• Docker published ports are controlled by DOCKER(-USER), not INPUT
• In DOCKER-USER, --dport refers to the internal port, so always narrow rules to the container level

Remember these two points, and you will avoid 90% of Docker iptables-related incidents.

🛠 마지막 수정일: 2025.12.29