Docker network connectivity inspection cheat sheet
Inspect container network membership, addressing, port publication and bounded application logs.
Docker Engine CLI against the intended local or remote Docker daemon; network behavior differs for Docker Desktop and Linux hosts.
Updated · Docker · 6 min read
| Command | What it does |
|---|---|
docker context show | Confirm the Docker context |
docker network ls | List available Docker networks |
docker network inspect app-net | Inspect a network and attached containers |
docker inspect --format "{{json .NetworkSettings.Networks}}" web | Inspect one container’s network attachments |
docker port web | Inspect published host ports |
docker logs --since 30m --tail 100 --timestamps web | Review a bounded application log sample |
Walkthrough
Replace web and app-net with exact container and network names. Confirm the Docker context first; inspect output can contain internal addresses and configuration.
Step 1: Confirm the Docker context
docker context show
Record the active context and check it against the incident environment. A similarly named container can exist on another daemon; endpoint overrides can also affect where the CLI connects.
Step 2: List available Docker networks
docker network ls
Find the intended network name, ID and driver. A network existing on the daemon does not prove that the application containers are attached or that their services are responding.
Step 3: Inspect a network and attached containers
docker network inspect app-net
Compare the network ID, driver, subnet and listed container endpoints with the intended deployment. Treat IP addresses as implementation details that can change when containers are recreated.
Step 4: Inspect one container’s network attachments
docker inspect --format "{{json .NetworkSettings.Networks}}" web
Compare the exact container’s network names and addresses with the peer’s attachments. A shared network enables a possible path but does not establish application readiness or listening ports.
Step 5: Inspect published host ports
docker port web
Check the host address and port mapped to the container. Published host ports and container-to-container ports are separate paths; a mapping does not prove that the process inside is listening.
Step 6: Review a bounded application log sample
docker logs --since 30m --tail 100 --timestamps web
Compare connection and startup errors with the incident time. Logging drivers and retention affect what is available; redact credentials and application data before sharing any excerpts.
WORKED INCIDENT
Practical case: A frontend cannot reach its backend container
Fictional teaching scenario; observations are examples, not captured production output.
Situation
A frontend and backend work individually, but requests between them fail after a deployment.
Investigation sequence
1. Confirm the Docker context
docker context showConfirm the CLI targets the daemon running the affected workload.
2. List available Docker networks
docker network lsList the networks and identify the expected application network.
3. Inspect a network and attached containers
docker network inspect app-netInspect the network membership for the frontend and backend.
4. Inspect one container’s network attachments
docker inspect --format "{{json .NetworkSettings.Networks}}" webCompare the exact attachments of the affected container with its peer.
Example findings
Illustrative findings: the frontend is attached to app-net but the backend was recreated on another network.
Interpret the findings
The membership mismatch is a supported explanation for the missing shared network path. Service name resolution and the backend listener still need separate verification.
Verify the outcome
After the owner corrects the approved deployment configuration, inspect both attachments again and test the application through its normal path.
Escalation handoff
Provide daemon context, container IDs, network IDs and sanitized error timestamps to the deployment owner.