Loading page
About this tool
Compare Docker bridge, host, none, container and macvlan network modes and see exactly how your container is reached.
This tool explains what each Docker network mode — bridge, user-defined bridge, host, none, container:<name> and macvlan — actually does to a container's reachability, DNS and port publishing. Pick a mode and your app's port, and it shows exactly how the container is reached from the host, from the LAN and from other containers, following the semantics documented for the Docker Engine network drivers. It is built for developers debugging 'connection refused' between containers or wondering why -p seems to do nothing.
Open Docker Network Mode Explainer on AltFTool — it loads instantly in your browser.
Paste your code or data sample into the workspace.
Pick the format, conversion, or analysis you need.
Copy the polished result straight back into your project.
Shows the exact address (localhost:port, host-ip:port or container name) each party uses to reach your app.
Flags the modes where -p is ignored (host), rejected (container:) or simply unnecessary (macvlan).
All six modes compared on DNS, publishing and host isolation in one glance.
A user-defined bridge adds automatic DNS: containers on it resolve each other by container name or network alias, while on the default bridge they can only use IP addresses (the old --link flag is legacy). Both use NAT and need -p for outside access, which is why Docker's own docs recommend user-defined networks for anything multi-container.
No. In host networking the container shares the host's network namespace, so the app's listening port is already a host port; Docker prints a warning and ignores any -p flags. This also means only one process — container or host service — can own a given port.
By design: the macvlan driver blocks traffic between the host's parent interface and the containers attached to it. LAN devices can reach the container directly on its own IP and MAC, but from the host itself you need a workaround such as adding a macvlan sub-interface on the host and routing through it.
It puts the new container into an existing container's network namespace, so both share one localhost and one set of interfaces — the same pattern Kubernetes uses for containers in a pod. Ports must be published on the container that owns the namespace; docker run rejects -p combined with --network container:<name>.