How to fix Error response from daemon: network ingress not found in Docker

DockerINTERMEDIATEHIGHUpdated Dec 6, 2025ยท 174 views

This error occurs when Docker Swarm's built-in ingress network is missing or corrupted. The ingress network is essential for the routing mesh that enables load balancing across swarm nodes. The fix typically involves recreating the ingress network or reinitializing the swarm.

Quick fix

Fixes Error response from daemon: network ingress not found

docker network ls --filter scope=swarm
  1. Verify the ingress network is missing
  2. Check firewall and required ports
  3. Recreate the ingress network
  4. Handle subnet conflicts
docker โ€” error
docker network ls --filter scope=swarm
Error response from daemon: network ingress not found

What this error means

The "network ingress not found" error indicates that Docker Swarm's special ingress overlay network is missing from the cluster. The ingress network is automatically created when you initialize a swarm and is fundamental to how Docker Swarm routes external traffic to services. The ingress network powers Docker Swarm's routing mesh - a feature that allows any node in the swarm to accept connections on published ports for any service, even if that node isn't running a task for that service. When a request arrives on a published port, the ingress network routes it through IPVS (IP Virtual Server) to an active container running the service. This error typically surfaces when deploying services with published ports, running `docker stack deploy`, or after certain network operations that inadvertently remove the ingress network. It can also occur when nodes fail to properly join the swarm's ingress network due to firewall issues or network configuration problems. The ingress network is not just an ordinary overlay network - it's a special network managed by Docker that cannot be manually attached to or modified like regular networks. When it goes missing, swarm services with published ports will fail to deploy or become unreachable.

Typical symptoms

  • docker stack deploy fails with 'network ingress not found'
  • docker service create with published ports fails
  • Existing services become unreachable after swarm operations
  • docker network ls shows no 'ingress' network in the swarm scope
  • Services work with host mode ports but fail with ingress mode
  • Worker nodes cannot join the ingress network during swarm join
  • Error appears after deleting the last service with published ports

Common causes

  1. The ingress network was manually deleted using docker network rm
  2. A node failed to join the ingress network due to closed firewall ports (7946 TCP/UDP, 4789 UDP)
  3. Swarm state corruption after an unclean shutdown or crash
  4. The last service with published ports was removed, and Docker cleaned up the ingress network endpoint
  5. Network subnet conflicts between ingress and local networks
  6. Docker daemon restart with corrupted swarm state
  7. Incomplete swarm initialization or join operation

How to fix "Error response from daemon: network ingress not found"

1Verify the ingress network is missing

First, confirm that the ingress network is actually missing from your swarm:

bash
docker network ls --filter scope=swarm

You should see an ingress network with the overlay driver. If it's not listed, the network is indeed missing.

Also check the swarm status:

bash
docker info | grep -A5 "Swarm"

Verify you're on a manager node and the swarm is active.

2Check firewall and required ports

The ingress network requires specific ports to be open between all swarm nodes. If ports are blocked, nodes cannot participate in the ingress network.

Required ports:
- TCP/UDP 7946: Container network discovery and gossip
- UDP 4789: Overlay network traffic (VXLAN)
- TCP 2377: Cluster management (managers only)

Check if ports are open:

bash
# Test port connectivity from another node
nc -zv <manager-ip> 7946
nc -zuv <manager-ip> 4789

Open the required ports:

bash
# Using ufw
sudo ufw allow 7946/tcp
sudo ufw allow 7946/udp
sudo ufw allow 4789/udp
sudo ufw allow 2377/tcp

# Using firewalld
sudo firewall-cmd --permanent --add-port=7946/tcp
sudo firewall-cmd --permanent --add-port=7946/udp
sudo firewall-cmd --permanent --add-port=4789/udp
sudo firewall-cmd --permanent --add-port=2377/tcp
sudo firewall-cmd --reload
3Recreate the ingress network

If the ingress network was deleted, you can recreate it. First, remove any remnants of the old ingress network:

bash
# This may show an error if already missing - that's okay
docker network rm ingress

Then create a new ingress network:

bash
docker network create \
  --driver overlay \
  --ingress \
  --subnet=10.0.0.0/24 \
  --gateway=10.0.0.1 \
  --opt com.docker.network.driver.overlay.vxlanid_list=4096 \
  ingress

The --ingress flag is critical - it tells Docker this is the special routing mesh network, not a regular overlay.

Note: Only one ingress network can exist at a time. If you get a conflict error, ensure the old one is fully removed.

4Handle subnet conflicts

If the default ingress subnet (10.0.0.0/24) conflicts with your local network, create it with a different subnet:

bash
docker network create \
  --driver overlay \
  --ingress \
  --subnet=10.255.0.0/24 \
  --gateway=10.255.0.1 \
  ingress

You can verify there's no conflict by checking existing network ranges:

bash
docker network inspect ingress --format '{{range .IPAM.Config}}{{.Subnet}}{{end}}'
ip route show

If you initialized swarm with --default-addr-pool, ensure the ingress subnet doesn't overlap:

bash
docker swarm init --default-addr-pool 10.10.0.0/16 --default-addr-pool-mask-length 24
5Restart Docker daemon on affected nodes

Sometimes nodes need a Docker daemon restart to properly rejoin the ingress network:

bash
# On the affected node
sudo systemctl restart docker

After restart, verify the node sees the ingress network:

bash
docker network ls --filter scope=swarm
docker network inspect ingress

Check that the node is properly connected:

bash
docker info --format '{{.Swarm.LocalNodeState}}'

This should return active.

6Reinitialize swarm as last resort

If the ingress network cannot be recreated due to corrupted swarm state, you may need to reinitialize the swarm:

Warning: This will remove all services, configs, and secrets. Export important data first.

On all worker nodes first:

bash
docker swarm leave

On all manager nodes (except one):

bash
docker swarm leave

On the last manager:

bash
docker swarm leave --force

Then reinitialize:

bash
docker swarm init --advertise-addr <manager-ip>

This creates a fresh swarm with a new ingress network. Rejoin other nodes using the tokens from:

bash
docker swarm join-token manager
docker swarm join-token worker

Advanced notes

How the ingress network works: The ingress network is a special overlay network that implements Docker Swarm's routing mesh. When you publish a port on a service, Docker creates a Virtual IP (VIP) for that service. IPVS (IP Virtual Server) running on each node listens on the published port and load balances incoming connections to healthy service tasks across the swarm, routing traffic over the ingress network.

Ingress vs host mode publishing: If you need to bypass the routing mesh entirely (for example, to preserve client source IPs), you can publish ports in host mode:

yaml
services:
  web:
    ports:
      - target: 80
        published: 80
        mode: host

Host mode binds directly to the host's network stack, bypassing ingress. However, this means only nodes running the service can receive traffic on that port.

Ingress network encryption: By default, ingress traffic is unencrypted. To enable encryption (at a performance cost), you must recreate the ingress network with the --opt encrypted flag:

bash
docker network rm ingress
docker network create --driver overlay --ingress --opt encrypted ingress

Debugging ingress issues: Use these commands to diagnose routing mesh problems:

bash
# Check ingress network details
docker network inspect ingress

# View service VIP
docker service inspect <service-name> --format '{{.Endpoint.VirtualIPs}}'

# Check if IPVS rules are configured (requires ipvsadm)
sudo ipvsadm -Ln

# View docker-proxy processes for published ports
ps aux | grep docker-proxy

Ingress on Windows: Docker Swarm ingress on Windows uses the Host Networking Service (HNS). The error "hnsCall failed" during ingress creation typically indicates HNS issues. Restart the HNS service:

powershell
Restart-Service hns

Preventing accidental ingress deletion: The ingress network can be accidentally removed when running cleanup scripts. Always exclude it:

bash
# Safe network cleanup - excludes ingress
docker network prune --filter "type!=ingress"

Frequently asked questions

What does "Error response from daemon: network ingress not found" mean?
The "network ingress not found" error indicates that Docker Swarm's special ingress overlay network is missing from the cluster. The ingress network is automatically created when you initialize a swarm and is fundamental to how Docker Swarm routes external traffic to services. The ingress network powers Docker Swarm's routing mesh - a feature that allows any node in the swarm to accept connections on published ports for any service, even if that node isn't running a task for that service.
How do I fix "Error response from daemon: network ingress not found"?
This error occurs when Docker Swarm's built-in ingress network is missing or corrupted. The ingress network is essential for the routing mesh that enables load balancing across swarm nodes. The fix typically involves recreating the ingress network or reinitializing the swarm.
What causes "Error response from daemon: network ingress not found"?
The ingress network was manually deleted using docker network rm A node failed to join the ingress network due to closed firewall ports (7946 TCP/UDP, 4789 UDP) Swarm state corruption after an unclean shutdown or crash
Is the "Error response from daemon: network ingress not found" error serious?
Yes. This is a high-severity error that usually blocks work until it is fixed, but the steps above resolve it.

Official resources & further reading