Docker Container Cannot Access Internet: Fix

Confirm the symptom: host connectivity vs. container connectivity

A Docker container that cannot reach the internet while the host can is almost always failing at one of three layers: the container's network mode and IP configuration, DNS resolution inside the container, or host-level firewall and routing. The steps here isolate which one on Linux and Windows, then apply the matching fix.

Confirm the host has internet access before touching the container. On a Linux host:

ping -c 4 8.8.8.8
curl -I https://example.com

On a Windows host, run the same tests in PowerShell:

Test-NetConnection 8.8.8.8
Invoke-WebRequest -Uri https://example.com -Method Head

If the host fails these, fix the host's network first. If the host works, run the same checks inside the container. On Linux:

docker exec -it mycontainer ping 8.8.8.8
docker exec -it mycontainer wget -qO- https://example.com

Minimal images may not include ping or curl. Use wget, getent hosts example.com, or install diagnostic tools temporarily. On Windows containers, use PowerShell inside the container:

docker exec -it mycontainer powershell Test-NetConnection 8.8.8.8

Test by IP first, then by hostname. If an IP ping works but a hostname lookup fails, the problem is DNS, not routing. If neither works, the container's network interface, route, or host firewall is likely at fault.

Check the container's network mode and IP configuration

Inspect how the container is attached to the network first. This command works on both Linux and Windows hosts (in PowerShell or bash):

docker inspect -f '{{.HostConfig.NetworkMode}}' mycontainer

That output tells you the network mode. none means the container has no network stack at all. host shares the host's network namespace and is only available on Linux; Windows containers do not support host mode. bridge is the default Docker bridge. A custom name means the container is attached to a user-defined network.

Check the container's IP address and routing table next. On Linux:

docker exec mycontainer ip addr
docker exec mycontainer ip route

On Windows containers:

docker exec mycontainer ipconfig
docker exec mycontainer route print

Confirm the container has an IP address in the expected Docker subnet and a default route via a gateway. A missing default route often explains why outbound traffic never leaves the container.

List the networks with docker network ls and inspect the relevant one with docker network inspect <network>. The default bridge network (bridge) does not provide Docker's embedded DNS; user-defined networks do. If your container must resolve names of other containers or services, put it on a user-defined network.

Test DNS resolution inside the container

If the container can ping IP addresses but cannot resolve domain names, the DNS configuration is the prime suspect.

Run a DNS query inside the container. On Linux:

docker exec mycontainer nslookup example.com
# If nslookup is missing, use getent:
docker exec mycontainer getent hosts example.com

On Windows containers:

docker exec mycontainer powershell Resolve-DnsName example.com

Check which DNS server the container uses. On Linux:

docker exec mycontainer cat /etc/resolv.conf

If the container is on a user-defined network, this file should show nameserver 127.0.0.11, Docker's embedded DNS. If it shows something else—such as a VPN provider's DNS or a manually edited value—that is likely the problem. On the default bridge, Docker copies the host's /etc/resolv.conf into the container, so the value may be your LAN or ISP DNS server.

On Windows containers, run ipconfig /all inside the container to see the configured DNS servers.

Compare that with the host's DNS resolution. Run nslookup example.com on the host (Linux or Windows). If the host resolves but the container does not, the container DNS configuration or Docker's DNS forwarding is broken.

Common causes include a VPN altering the host DNS settings, a custom /etc/resolv.conf mounted into the container, missing --dns flags, or Docker Desktop's DNS proxy failing to forward from WSL2 or Hyper-V.

Inspect host firewall, routing, and NAT for outbound blocking

If the container has a valid IP and route but still cannot reach the internet, host-level firewall or NAT rules may be blocking outbound traffic.

On Linux, examine Docker's NAT and forwarding rules. Run these as root:

iptables -t nat -L -n -v
iptables -L FORWARD -n -v

Docker's default rules allow outbound traffic from the bridge subnet. If you see a DROP policy or a rule that rejects packets from Docker's subnet, that is the culprit. Also confirm IP forwarding is enabled:

sysctl net.ipv4.ip_forward

This should output net.ipv4.ip_forward = 1. If it is 0, enable it temporarily with sysctl -w net.ipv4.ip_forward=1 and persist it in /etc/sysctl.conf.

On Windows, check IP forwarding and firewall rules. In an elevated PowerShell:

Get-NetIPInterface -AddressFamily IPv4 | Select-Object InterfaceAlias,Forwarding
Get-NetFirewallRule | Where-Object { $_.DisplayName -like '*Docker*' -or $_.DisplayName -like '*vEthernet*' }
Get-NetNat

Docker Desktop uses a virtual switch (DockerNAT or vEthernet) for WSL2 or Hyper-V. Outbound traffic must be allowed through Windows Defender Firewall for that adapter. A VPN with split tunneling disabled can also misroute container traffic because the virtual switch traffic may be pushed into the VPN tunnel and dropped.

Also check whether the environment requires a proxy. If the host uses HTTP_PROXY, HTTPS_PROXY, and NO_PROXY environment variables, the container may need the same values to reach the internet.

Apply the fix for the identified cause

After isolating the failing layer, apply the change that matches.

DNS failure: Add explicit DNS servers to the container. With docker run:

docker run --dns 8.8.8.8 --dns 8.8.4.4 myimage

In a Compose file, use the dns: key:

services:
  web:
    dns:
      - 8.8.8.8
      - 8.8.4.4

For containers on user-defined networks, rely on Docker's embedded DNS rather than manually editing /etc/resolv.conf. If you must override, do it with --dns flags or Compose.

Wrong network mode: If the container is on none, change its network mode to bridge or a user-defined network. In Compose, set network_mode: bridge or attach the service to a custom network, then recreate the container. For Windows containers, ensure the desired network (NAT, transparent, or l2bridge) exists. Create it with docker network create -d nat mynat or the appropriate driver, then attach the container.

Firewall or NAT blocking: On Linux, add an ACCEPT rule for the Docker bridge subnet. First find the subnet with docker network inspect bridge, then run:

iptables -I FORWARD -s 172.17.0.0/16 -j ACCEPT
systemctl restart docker

Adjust the subnet to match your setup. On Windows, allow outbound traffic for the DockerNAT or vEthernet adapter in Windows Defender Firewall, then restart Docker Desktop.

Proxy required: Pass proxy variables to the container:

docker run -e HTTP_PROXY=http://host.docker.internal:3128 -e HTTPS_PROXY=http://host.docker.internal:3128 -e NO_PROXY=localhost,127.0.0.1 myimage

On Linux native Docker, host.docker.internal may not resolve; use the host's IP address or add --add-host=host.docker.internal:host-gateway. For the Docker daemon itself on Linux, create /etc/systemd/system/docker.service.d/http-proxy.conf with:

[Service]
Environment="HTTP_PROXY=http://proxy.example.com:3128"
Environment="HTTPS_PROXY=http://proxy.example.com:3128"
Environment="NO_PROXY=localhost,127.0.0.1"

Then run systemctl daemon-reload && systemctl restart docker. On Docker Desktop for Windows, configure the proxy in Docker Desktop settings instead.

After any change, re-run the connectivity test from the first section to confirm the container can now reach the internet.

Verify connectivity and prevent recurrence

Add a health check that tests external connectivity to catch this early. In a Compose service:

services:
  web:
    healthcheck:
      test: ["CMD", "curl", "-f", "https://example.com"]
      interval: 30s
      timeout: 10s
      retries: 3

For Windows containers, use a PowerShell command inside the health check that returns non-zero on failure, such as Invoke-WebRequest -Uri https://example.com -Method Head.

Keep network configuration in Compose or docker run flags rather than making manual changes inside the container. Prefer user-defined networks over the default bridge; they give automatic DNS and better isolation. Document any host firewall changes and note that restarting Docker may reset some manual iptables rules.

Tools that can inspect container state and run read-only diagnostics inside containers can reduce the number of manual steps. An AI agent for Docker can check a container's network mode, DNS settings, and logs, and run ping, nslookup, or curl inside the container when you ask why it cannot reach the internet. However, host firewall and daemon changes still require your action.

Related reading

• Tomcat 404 After Deploying WAR Context Path Mismatch: Fix It
• Manage Docker with an AI agent