How to Read docker network inspect Output
Part of the Docker Toolkit{"Name":"myapp_default","Driver":"bridge","IPAM":{"Config":[{"Subnet":"172.19.0.0/16","Gateway":"172.19.0.1"}]},"Internal":false,"Containers":{"<id>":{"Name":"myapp-web-1","IPv4Address":"172.19.0.3/16"}}}one element of the array docker network inspect always prints, trimmed to the fields that matter most
Explanation
docker network inspect <name> always prints a JSON array, even for one network — a habit worth knowing before wondering why the output starts with [ instead of {. Most of the object is straightforward once you know what to look at first: Driver, Internal, and Containers answer almost every real question people paste this output to answer.
Driver decides what kind of network this even is
bridge is an isolated network on the host; host means the container shares the host's own network stack directly, with no isolation at all; none gives a container nothing beyond loopback. host and none always show empty Containers and IPAM — that's expected, not a sign the inspect output is broken or truncated.
The single most common surprise: the default bridge network
Docker's embedded DNS server — the thing that lets one container reach another by name instead of IP — only runs on user-defined networks. The network literally named bridge (Docker creates it automatically, every container lands there if nothing else is specified) doesn't get it. Two containers sitting in bridge's Containers map can reach each other by the IPv4Address listed there, but a request to the other container's name fails to resolve — which is exactly the "my containers can't find each other" symptom that sends people looking at this JSON in the first place. The fix is almost always creating a real network (docker network create, or just letting Compose create its default one) rather than the default bridge.
Internal: true means no route out, not just restricted
A network with Internal: true lets its containers talk to each other but gives them no path to the internet or any other network at all. From inside a container on one, a failed outbound request looks identical to a DNS problem or a firewall block — checking Internal on the network it's attached to is a faster diagnosis than debugging DNS first.
Containers, IPAM, and Labels
Containers is a map keyed by container ID, each value giving that container's Name and its IPv4Address/IPv6Address on this specific network — a container attached to three networks has three different addresses, one per network, not one address total. IPAM.Config holds the Subnet and Gateway for the whole network. And a com.docker.compose.project label under Labels means Compose created and owns this network — docker compose down is the right way to remove it, not docker network rm by hand.
A gotcha specific to this output: subnet overlaps that shouldn't coexist
Docker refuses to create two local networks with an overlapping subnet on one host — it errors immediately at creation time. So if you're looking at inspect output for two networks that both claim the same subnet, they didn't come from the same Docker daemon right now; they're either from two different hosts you're comparing, or one is stale output from before a network was recreated.
For the full breakdown of default-bridge name resolution and what Compose actually sets up, see Understanding Docker Networks.
Valid examples
{"Name":"myapp_default","Driver":"bridge","Internal":false,"Labels":{"com.docker.compose.project":"myapp"},"Containers":{"c1":{"Name":"myapp-web-1"},"c2":{"Name":"myapp-api-1"}}}A Compose-created, user-defined network — containers here resolve each other by name, since it isn't the default bridge.
{"Name":"host","Driver":"host","IPAM":{"Config":[]},"Containers":{}}Empty IPAM and Containers are correct for the host driver — containers share the host's own network stack, so there's no separate virtual network to track.
{"Name":"myapp_db-internal","Driver":"bridge","Internal":true,"Containers":{}}Internal: true is intentional here — a database tier reachable from other containers on the network but with no route to the internet, exactly what you want for a component that should never be reachable directly.
Invalid examples
{"Name":"bridge","Driver":"bridge","Options":{"com.docker.network.bridge.default_bridge":"true"},"Containers":{"c1":{"Name":"web"},"c2":{"Name":"api"}}}The literal default bridge network relied on for name-based discovery — web and api can reach each other by IP, but not by name. Only user-defined networks get Docker's embedded DNS.
{"Name":"myapp_db-internal","Driver":"bridge","Internal":true,"Containers":{"c1":{"Name":"db"}}}A container on an internal network trying to reach an external API — the request will hang or fail. Internal: true has no route out, which looks identical to a DNS or firewall problem from inside the container.
[{"Name":"net-a","IPAM":{"Config":[{"Subnet":"172.20.0.0/16"}]}},{"Name":"net-b","IPAM":{"Config":[{"Subnet":"172.20.0.0/16"}]}}]Two networks declaring the identical subnet in one inspect dump — Docker refuses this on a single host, so seeing it means the two came from different Docker hosts, or one is stale.