Inspect Docker Networks with docker network inspect

Before you guess which container is on which network, run docker network inspect and read the actual answer instead of assuming one.

You will finish with a repeatable way to inspect a Docker network, find its connected containers and addresses, and pull out one value without hand-parsing a large JSON document. The examples use Docker CLI 29.8.1 from the installed docker-ce-cli package, version 5:29.8.1-1~ubuntu.24.04~noble.

1. Confirm the installed command

Check the client and package before trusting examples written against another Docker release. This is an ordinary, read-only check:

$ docker version --format '{{.Client.Version}}'
29.8.1
$ dpkg-query -W -f='${Package} ${Version}\n' docker-ce-cli
docker-ce-cli 5:29.8.1-1~ubuntu.24.04~noble

Your package revision may differ. The full form is docker network inspect [OPTIONS] NETWORK [NETWORK...]: the network argument can be a name or an ID, and you can pass several in one call.

Checkpoint: if docker version reports a daemon connection error, fix the Docker context or daemon availability first. Do not reach for sudo automatically; use it only when your Docker installation deliberately requires root, and remember it may pick up a different configuration and context.

2. Inspect one network as JSON

Start with a network that exists on the host. The default bridge network is a common read-only test, though it may be absent or unreachable in a customised environment:

$ docker network ls
NETWORK ID     NAME      DRIVER    SCOPE
...            bridge    bridge    local
...            host      host      local
...            none      null      local
$ docker network inspect bridge

The result is a JSON array even for one network. Its object normally includes the name, ID, scope, driver, IPAM configuration, internal and ingress flags, options, labels, and a Containers object. Each connected container entry can include a name, endpoint ID, MAC address, IPv4 address and IPv6 address.

Do not treat every field as universal: driver and network type decide which fields matter, and an empty Containers object is a perfectly normal result for an unused user-defined network. If the network is not found, check spelling with docker network ls and retry with the exact name or ID.

3. Inspect several networks together

Pass more than one name when comparing networks, and Docker returns one result object per match in the array:

$ docker network inspect bridge host
[
    {
        "Name": "bridge",
        "Id": "...",
        "Scope": "local",
        "Driver": "bridge",
        "Containers": { ... }
    },
    {
        "Name": "host",
        "Id": "...",
        "Scope": "local",
        "Driver": "host",
        "Containers": { ... }
    }
]

IDs and container entries vary by host. For a script, do not depend on whitespace or the order of object keys: either use Docker's format option in the next step, or pass the JSON to a JSON-aware tool you already have installed.

4. Select fields with a Go template

Use --format, or its short form -f, for a compact answer. The template runs once per inspected network:

$ docker network inspect --format 'name={{.Name}} driver={{.Driver}} scope={{.Scope}}' bridge
name=bridge driver=bridge scope=local

To print the configured subnet and gateway, traverse the nested IPAM configuration. The first entry is used here because a network can have more than one configured range:

$ docker network inspect --format 'network={{.Name}} subnet={{(index .IPAM.Config 0).Subnet}} gateway={{(index .IPAM.Config 0).Gateway}}' bridge
network=bridge subnet=172.17.0.0/16 gateway=172.17.0.1

The values above are examples, not defaults to copy into a firewall rule: your own subnet and gateway depend on the host. If IPAM.Config is empty, that template has nothing to index and will fail, so inspect the full JSON first and write a template for the shape you actually have.

For machine-readable output, --format json gives you JSON through the format option. For a quick human check, the default output is usually easier to explore because it keeps the surrounding object and nested fields intact.

5. List connected container names and addresses

Containers is a map keyed by container ID, so a template ranges over its values rather than assuming a numbered list:

$ docker network inspect --format '{{.Name}}{{range .Containers}}{{printf "\n  %s %s" .Name .IPv4Address}}{{end}}' bridge
bridge
  web 172.17.0.2/16
  worker 172.17.0.3/16

An unused network prints only its own name. An IPv6-enabled network may show a value in IPv6Address too; an empty string just means that endpoint has no IPv6 address recorded. Treat these as current Docker endpoint data, not a promise that an application is actually accepting traffic.

When you need one container's identity, compare the displayed name against docker ps: names can be reused after a container is removed, while endpoint and container IDs help you tell old records from the current one.

6. Add verbose output for a swarm overlay

Use --verbose, or -v, for diagnostics on swarm-mode overlay networks:

$ docker network inspect --verbose OVERLAY_NETWORK
[
    {
        "Name": "OVERLAY_NETWORK",
        "Scope": "swarm",
        "Driver": "overlay",
        "Peers": [ ... ],
        "Services": { ... }
    }
]

Replace OVERLAY_NETWORK with the exact name from docker network ls. Verbose inspection can include service VIPs, published port mappings, task IPs and the IPs of the nodes running those tasks, which is exactly the evidence you need when a service looks healthy on one node but traffic fails across the overlay.

Do not infer swarm behaviour from a local bridge network: the scope, driver and available fields differ, and verbose output does not repair a broken overlay, service or node by itself. Use it to gather evidence before you check service status, node membership or firewall rules.

7. Handle failures without changing state

A non-zero result is useful evidence in its own right. Capture the status when a check is part of a script:

$ docker network inspect does-not-exist >/tmp/network-inspect.json
$ status=$?
$ printf 'inspect status: %s\n' "$status"
inspect status: 1

The exact error text depends on the client and daemon, and the temporary file may be empty or hold partial output. Never feed a failed run into an automated firewall or routing change. Check the name, the active Docker context, and daemon access, then rerun the read-only inspection.

If access is denied, ask an administrator to grant the Docker access you need, or run the command through the approved administrative path. Docker group membership is effectively privileged on many hosts, because the daemon can control the whole host, so do not widen access just to make an inspection more convenient.

Done means