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.
\nThe Port publishing and mapping documentation is the primary reference.
\nDocker’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.
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.
\nDSE 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.
\nInspect 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.
\nPlan 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.
\nResolve 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.
\nProposed 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.
\nRetain 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.
\nSource review completed October 30, 2026. Recheck the official documentation and deployment-specific applicability before a production change.
\n", "content_text": "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.\nSource fact: documented behavior\nThe Port publishing and mapping documentation is the primary reference.\nDocker’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.\nWhat the source does not establish\nThis 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.\nApplicability questions\n\nWhat gateway mode applies to IPv4 and IPv6 on this bridge?\nWhich exact client destination is intended in each family?\nDoes the network owner approve the required container-network route?\nWhat observed mapping and reachability evidence will confirm the intended exposure?\n\nDSE recommendation: write one destination per family\nDSE 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.\nInspect 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.\nPlan 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.\nResolve 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.\nVerification and evidence\nProposed 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.\nRetain 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.\nOfficial references\n\nPort publishing and mapping — Docker Docs.\n\nSource review completed October 30, 2026. Recheck the official documentation and deployment-specific applicability before a production change.", "content_markdown": "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.\n\n## Source fact: documented behavior\n\nThe [Port publishing and mapping](https://docs.docker.com/engine/network/port-publishing/) documentation is the primary reference.\n\nDocker’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.\n\n## What the source does not establish\n\nThis 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.\n\n## Applicability questions\n\n- What gateway mode applies to IPv4 and IPv6 on this bridge?\n\n- Which exact client destination is intended in each family?\n\n- Does the network owner approve the required container-network route?\n\n- What observed mapping and reachability evidence will confirm the intended exposure?\n\n## DSE recommendation: write one destination per family\n\nDSE 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.\n\nInspect 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.\n\nPlan 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.\n\nResolve 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.\n\n## Verification and evidence\n\nProposed 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.\n\nRetain 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.\n\n## Official references\n\n- [Port publishing and mapping](https://docs.docker.com/engine/network/port-publishing/) — Docker Docs.\n\nSource review completed October 30, 2026. Recheck the official documentation and deployment-specific applicability before a production change." }, "json_ld": { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://dsesecurity.com/#organization", "name": "Detection Systems & Engineering", "alternateName": "DSE Security", "url": "https://dsesecurity.com/", "logo": { "@type": "ImageObject", "url": "https://update.dsesecurity.com/assets/dse-logo-20260812.png?v=1.8.20" } }, { "@type": "Organization", "@id": "https://update.dsesecurity.com/#editorial-team", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/", "parentOrganization": { "@id": "https://dsesecurity.com/#organization" } }, { "@type": "WebSite", "@id": "https://update.dsesecurity.com/#website", "name": "DSE Updates", "alternateName": "DSE Security Knowledge Hub", "url": "https://update.dsesecurity.com/", "inLanguage": "en-US", "publisher": { "@id": "https://dsesecurity.com/#organization" }, "potentialAction": { "@type": "SearchAction", "target": { "@type": "EntryPoint", "urlTemplate": "https://update.dsesecurity.com/?q={search_term_string}" }, "query-input": "required name=search_term_string" } }, { "@type": "WebPage", "@id": "https://update.dsesecurity.com/updates/interpret-docker-published-ports-using-the-bridge-gateway-mode/", "url": "https://update.dsesecurity.com/updates/interpret-docker-published-ports-using-the-bridge-gateway-mode/", "isPartOf": { "@id": "https://update.dsesecurity.com/#website" }, "lastReviewed": "2026-10-30" }, { "@type": "BreadcrumbList", "@id": "https://update.dsesecurity.com/updates/interpret-docker-published-ports-using-the-bridge-gateway-mode/#breadcrumbs", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "DSE Updates", "item": "https://update.dsesecurity.com/" }, { "@type": "ListItem", "position": 2, "name": "IT", "item": "https://update.dsesecurity.com/topic/it/" }, { "@type": "ListItem", "position": 3, "name": "Interpret Docker published ports using the bridge gateway mode", "item": "https://update.dsesecurity.com/updates/interpret-docker-published-ports-using-the-bridge-gateway-mode/" } ] }, { "@type": [ "Article", "TechArticle" ], "@id": "https://update.dsesecurity.com/updates/interpret-docker-published-ports-using-the-bridge-gateway-mode/#article", "identifier": "https://update.dsesecurity.com/updates/interpret-docker-published-ports-using-the-bridge-gateway-mode/", "url": "https://update.dsesecurity.com/updates/interpret-docker-published-ports-using-the-bridge-gateway-mode/", "headline": "Interpret Docker published ports using the bridge gateway mode", "description": "Distinguish routed container-port access from a NAT host-port mapping, including the documented IPv4 and IPv6 split.", "abstract": "Distinguish routed container-port access from a NAT host-port mapping, including the documented IPv4 and IPv6 split.", "articleBody": "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.\nSource fact: documented behavior\nThe Port publishing and mapping documentation is the primary reference.\nDocker’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.\nWhat the source does not establish\nThis 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.\nApplicability questions\n\nWhat gateway mode applies to IPv4 and IPv6 on this bridge?\nWhich exact client destination is intended in each family?\nDoes the network owner approve the required container-network route?\nWhat observed mapping and reachability evidence will confirm the intended exposure?\n\nDSE recommendation: write one destination per family\nDSE 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.\nInspect 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.\nPlan 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.\nResolve 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.\nVerification and evidence\nProposed 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.\nRetain 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.\nOfficial references\n\nPort publishing and mapping — Docker Docs.\n\nSource review completed October 30, 2026. Recheck the official documentation and deployment-specific applicability before a production change.", "datePublished": "2026-10-30T06:04:25+00:00", "dateModified": "2026-10-30T06:05:14+00:00", "mainEntityOfPage": { "@id": "https://update.dsesecurity.com/updates/interpret-docker-published-ports-using-the-bridge-gateway-mode/" }, "inLanguage": "en-US", "isAccessibleForFree": true, "author": { "@type": "Organization", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "@id": "https://dsesecurity.com/#organization" }, "image": { "@type": "ImageObject", "@id": "https://update.dsesecurity.com/updates/interpret-docker-published-ports-using-the-bridge-gateway-mode/#primaryimage", "url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "contentUrl": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "width": 1200, "height": 630, "caption": "Interpret Docker published ports using the bridge gateway mode" }, "articleSection": [ "IT", "Networks & Infrastructure" ], "keywords": [ "IT", "Networks & Infrastructure", "Guide", "Advisory priority" ], "genre": "Guide", "about": [ { "@type": "Thing", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" }, { "@type": "Thing", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" } ], "wordCount": 575, "timeRequired": "PT3M", "publishingPrinciples": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usageInfo": "https://update.dsesecurity.com/usage/", "copyrightHolder": { "@id": "https://dsesecurity.com/#organization" }, "copyrightNotice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "citation": { "@type": "CreativeWork", "name": "Docker Docs — Port publishing and mapping", "url": "https://docs.docker.com/engine/network/port-publishing/" } } ] } }