Docker Published Port Works Locally but Is Unreachable from the LAN

Record both endpoints

Write down the successful request's execution context, address, TCP port and any proxy, then the failing client's destination. Keep addresses and full outputs private. Do not compare a container port with a different host port as though they were the same endpoint.[1]

Inspect actual publication

With existing authorized Docker CLI access, replace <container> with the intended container name or ID. Read the TCP mapping and host address; no matching TCP entry is not a LAN firewall diagnosis.[6]

docker container port <container>

Repeat only a normal read operation

Use the application's existing non-destructive request. Record whether it responds now; do not create records, run jobs or change configuration as a connectivity test.[1]

1. Establish the network model

Confirm version, rootful Engine and bridge NAT configuration from existing deployment records. Host mode ignores published-port options and is outside this page. Do not switch modes to make the test pass.[3][1]

2. Separate publication from application access

Compare the mapping with the intended host LAN address and TCP port. Localhost publication is distinct from LAN-address publication. Docker warns that pre-28.0.0 same-L2 peers can reach localhost-published ports; this is not a security guarantee for old installations.[1][6]

3. Test the intended LAN endpoint from the host

Make the same safe request to the intended host-LAN-IP and published port from the Docker host. If only a container-local request works, record that narrower result. Do not diagnose an application listener without inspecting its actual runtime configuration.[1][3]

4. Inspect the actual backend

Read the running daemon's existing configuration and the applicable rules with the host owner. Docker's nftables support is documented as experimental since Engine 29.0.0 and has no equivalent DOCKER-USER chain. Unknown/nftables details require backend-specific review, not an iptables fix.[5]

5. Require matching filtering evidence

For the iptables backend, user filtering in DOCKER-USER is evaluated before Docker's forwarding chains, after destination translation. Ask for evidence matching this request, including translated addresses where relevant. Do not infer a denial from an unrelated rule or from absent logs.[4]

6. Compare another authorized LAN client

Repeat the same non-destructive request from another client on the intended LAN. HomeLabFix uses the contrast to prioritize a client/LAN owner, not to prove a unique router or firewall cause. Docker's published traffic does not follow ordinary ufw INPUT/OUTPUT expectations.[2]

Mapping or address mismatch: deployment-owner review

Provide the actual and intended mapping to the deployment owner. Request only a separately authorized correction that preserves intended exposure; do not blindly recreate the container or broaden the bind address.[6][1]

Local context mismatch: application-owner review

Provide the exact successful and failed contexts and ask the application owner to verify its listener against that application's documentation. There is no universal listener setting in this page.[3]

Matching filter or LAN evidence: network-owner review

Give the policy owner the installed backend, relevant matching evidence and controlled client comparison. Do not flush rules, disable firewall management or substitute host networking.[2][4][5]

Before any separately authorized exposure change

Planning boundary only: configuration and firewall changes can interrupt service or expose it beyond the intended clients. The responsible deployment/network owner must approve the exact change; this page supplies no mutation command.[2]

Unresolved: assemble a targeted evidence packet

Keep the version, topology, endpoint comparison, mapping and time-correlated observations. Share only sanitized excerpts with the appropriate application or network owner; missing evidence is a reason to investigate, not permission to weaken security.[6][2]