# Interpret Docker published ports using the bridge gateway mode > Distinguish routed container-port access from a NAT host-port mapping, including the documented IPv4 and IPv6 split. - Canonical URL: https://update.dsesecurity.com/updates/interpret-docker-published-ports-using-the-bridge-gateway-mode/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-10-30T06:04:25+00:00 - Modified: 2026-10-30T06:05:14+00:00 - Last reviewed by DSE: 2026-10-30 - Resource type: Guide - DSE priority: Advisory - Topics: IT, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Distinguish routed container-port access from a NAT host-port mapping, including the documented IPv4 and IPv6 split. ## Potentially affected Docker bridge networks using the documented nat or routed gateway modes. ## DSE recommendation Record each address family’s gateway mode before interpreting published host-port mappings or reachability. ## Article Bottom line: Identify the gateway mode for each address family before reading a published-port entry. Record whether the intended client should address a host port or a directly routed container port. ## Source fact: documented behavior The [Port publishing and mapping](https://docs.docker.com/engine/network/port-publishing/) documentation is the primary reference. Docker’s bridge gateway mode defaults to nat, which configures translation and masquerading for published ports; routed omits those translations while retaining published-port filtering. Remote access to a published port in a routed network requires a route to the container network through an external Docker-host address. In routed mode, the host port in a publish mapping is unused and the host address selects IPv4 or IPv6; a specific host address or port has no effect and produces a warning. The documented mixed-mode example exposes container port 80 directly for routed IPv6 while mapping host port 8080 for NAT IPv4, and inspection shows an empty IPv6 HostPort. ## What the source does not establish This article interprets the documented bridge gateway modes and mixed-family example. It does not approve an exposure policy, supply routes for a real network or extend the behavior to Swarm publication. Keep host firewall enforcement and application authorization under their separate checks. ## Applicability questions - What gateway mode applies to IPv4 and IPv6 on this bridge? - Which exact client destination is intended in each family? - Does the network owner approve the required container-network route? - What observed mapping and reachability evidence will confirm the intended exposure? ## DSE recommendation: write one destination per family DSE recommends an exposure worksheet with separate IPv4 and IPv6 rows. Record the bridge network, gateway mode, container address and port, intended client location and any relevant host mapping. Have the network owner approve the actual addressing and route rather than copying the example subnet into a deployment. Inspect the resulting network and container settings through approved tooling. Compare the actual published-port representation with the worksheet, including an empty host-port field where the reviewed routed case calls for it. Preserve warnings and unexpected mappings for investigation. Avoid inventing a missing host listener as the explanation before checking the mode. Plan reachability from the intended client path. Keep a directly addressed container destination separate from a translated host destination, and record the address family on every observation. Include a deliberately excluded source or destination only within the authorized test plan. Do not infer enforcement from a host firewall summary alone. Resolve an unexpected result at the relevant layer. Have the network owner review routes and filtering, the container owner review publication and the application owner review its listening and authorization requirements. Limit any proposed correction to the demonstrated discrepancy, and preserve the previous managed network definition for the approved reversal. ## Verification and evidence Proposed verification, not performed: use an isolated dual-stack lab and harmless test service. Prepare the documented mixed-mode shape only if both address families and direct routing are supported by the lab design. Predict the IPv4 host destination and IPv6 container destination before creating the test mapping. Retain the actual gateway options, inspection output, warnings, source location and destination for each connection attempt. Compare the results with the worksheet, then run the separately approved excluded-path checks. Clean up disposable network objects through the lab procedure. Report the tested modes and routes without claiming that a port mapping proves application trust or every surrounding firewall rule. ## Official references - [Port publishing and mapping](https://docs.docker.com/engine/network/port-publishing/) — Docker Docs. Source review completed October 30, 2026. Recheck the official documentation and deployment-specific applicability before a production change. ## Primary reference - Name: Docker Docs — Port publishing and mapping - Authority: docs.docker.com - URL: https://docs.docker.com/engine/network/port-publishing/ - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Interpret Docker published ports using the bridge gateway mode,” DSE Security, https://update.dsesecurity.com/updates/interpret-docker-published-ports-using-the-bridge-gateway-mode/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved.