Error 113: No Route to Host (EHOSTUNREACH)

Error 113 Quick Reference

The same underlying error shows up with different numbers and wording depending on the operating system and programming language. If your message contains "No route to host", this page applies.

What "No Route to Host" Actually Means

Despite the name, errno 113 rarely means your routing table is missing a route. On Linux, if there is no matching route at all you normally get errno 101, ENETUNREACH ("Network is unreachable") instead. EHOSTUNREACH is returned in these situations:

1. A firewall rejected the connection with an ICMP message. A REJECT rule using icmp-host-prohibited or icmp-admin-prohibited sends back ICMP type 3 (destination unreachable) code 10 or 13, which the Linux kernel reports as EHOSTUNREACH. This is the number-one cause: firewalld (the default on RHEL, CentOS, Rocky Linux, AlmaLinux and Fedora) and the classic RHEL/CentOS iptables rule set reject any port that is not explicitly allowed this way. The host is up and answers ping, but the port you want is closed by the firewall.
2. A router sent "host unreachable". A router or gateway along the path sent ICMP type 3 code 1, typically because the final router could not reach the host on its own LAN.
3. ARP (or IPv6 neighbor discovery) failed on your local subnet. If the target is on the same subnet as you, your machine has to find its MAC address first. If nothing answers (host off, wrong IP, different VLAN, Wi-Fi client isolation), the connection fails with EHOSTUNREACH after about three seconds.
4. A local "unreachable" route. A route installed with ip route add unreachable … (some VPN clients and kill switches do this) also returns EHOSTUNREACH.

A firewall that silently drops packets (the default for ufw, most cloud security groups and many home routers) does not cause error 113. You get a timeout (errno 110) instead.

Error 113 vs 101, 110, 111 and 112

The errno number tells you how far your packets got. Linux numbers are shown (check them with python3 -c "import errno; print(errno.EHOSTUNREACH)").

In short: 111 means "I reached the server but nothing is listening", 110 means "nobody answered", and 113 means "a firewall or router told me I can't get there, or the host isn't on the LAN".

How to Diagnose Error 113, Step by Step

Run these from the machine that shows the error (the client), replacing 10.0.0.5 and 8080 with your target IP and port.

1. Confirm the address you are really connecting to. A stale DNS record or /etc/hosts entry pointing to an old IP is a common hidden cause.

   getent hosts myserver.example.com
   dig +short myserver.example.com A
   dig +short myserver.example.com AAAA

2. See which route and interface the kernel will use.

   ip route get 10.0.0.5
   ip route show

   If the target is on your own subnet, the output has no via gateway. If it unexpectedly goes through a VPN interface (tun0, wg0), the VPN is involved.
3. Test basic reachability and check the ARP/neighbor table.

   ping -c 3 10.0.0.5
   ip neigh show 10.0.0.5

   FAILED or INCOMPLETE in ip neigh means the host is not answering ARP: it is off, the IP is wrong, or it is on a different VLAN/subnet than you think.
4. Test the exact port. If ping works but this fails with "No route to host", a firewall on the target (or in between) is rejecting that port.

   nc -vz 10.0.0.5 8080
   curl -v telnet://10.0.0.5:8080
   curl -v https://10.0.0.5:8443/

5. Watch for the ICMP reject. This shows exactly who is rejecting you:

   sudo tcpdump -ni any 'icmp or icmp6'
   # typical output:
   # IP 10.0.0.5 > 10.0.0.9: ICMP host 10.0.0.5 unreachable - admin prohibited filter

   If the source of the ICMP message is the target itself, its host firewall is the culprit. If it is a router address, look at that router or firewall.
6. Trace the path to the port.

   traceroute -n 10.0.0.5
   sudo traceroute -n -T -p 8080 10.0.0.5   # TCP traceroute to the real port

7. On the target server, confirm the service is listening and inspect the firewall.

   sudo ss -tlnp | grep 8080
   sudo firewall-cmd --state
   sudo firewall-cmd --get-active-zones
   sudo firewall-cmd --list-all
   sudo iptables -L -n -v --line-numbers
   sudo nft list ruleset | grep -i -E 'reject|drop'

   Look for a REJECT … reject-with icmp-host-prohibited rule (iptables) or reject with icmpx admin-prohibited (nftables / firewalld) that comes before any rule allowing your port.
8. Check anything outside the two hosts: cloud security groups and network ACLs (AWS, Azure, GCP, OpenStack), corporate firewalls, VPN split-tunnel settings, and Wi-Fi "client isolation" on guest networks.

How to Fix Error 113

1. Open the port in firewalld (RHEL, CentOS, Rocky, Alma, Fedora)

sudo firewall-cmd --permanent --add-port=8080/tcp
# or, for a known service:
sudo firewall-cmd --permanent --add-service=ssh
sudo firewall-cmd --reload
sudo firewall-cmd --list-all

Make sure you add the rule to the zone that is actually active on the interface (--zone=public etc.). Avoid "fixing" it by stopping the firewall entirely on a production server.

2. iptables or nftables

# iptables: insert an ACCEPT rule ABOVE the REJECT rule
sudo iptables -I INPUT -p tcp --dport 8080 -j ACCEPT
# make it persistent, e.g. on RHEL with iptables-services:
sudo service iptables save

# nftables: add an accept rule to your input chain (adjust table/chain names)
sudo nft add rule inet filter input tcp dport 8080 accept

With iptables, order matters: a rule appended with -A after the final REJECT line will never be reached.

3. ufw (Ubuntu, Debian)

sudo ufw allow 8080/tcp
sudo ufw status verbose

By default ufw drops rather than rejects, so it usually causes timeouts. You get error 113 only if a reject rule or policy is configured.

4. Host down, wrong IP or ARP failure

• Power on or reconnect the target; check its own IP with ip addr and compare it with what clients use.
• Make sure both machines are on the same subnet/VLAN with matching netmasks, or that traffic goes through a gateway.
• Look for duplicate IP addresses (arping -D -I eth0 10.0.0.5).
• Flush a stale neighbor entry: sudo ip neigh flush 10.0.0.5.

5. Routing and VPN

• Add the missing route: sudo ip route add 192.168.50.0/24 via 10.0.0.1.
• Check whether a VPN or kill switch installed an unreachable route: ip route show table all | grep unreachable.
• Overlapping subnets (home LAN and VPN both using 192.168.1.0/24) are a frequent cause. Change one side's range.

Error 113 in Specific Tools and Platforms

SSH: "connect to host … port 22: No route to host"

Run ping first. If ping works, the SSH port is being rejected: on the server run sudo firewall-cmd --permanent --add-service=ssh && sudo firewall-cmd --reload, or allow your custom port if sshd does not listen on 22. If ping also fails, the server is off, on another network, or behind a VPN you are not connected to. ssh -v user@host shows which IP and port it tries.

curl: errno 113

curl reports this as exit code 7 (CURLE_COULDNT_CONNECT) with the message "Failed to connect to … : No route to host". The 113 is the operating-system errno. curl never reached HTTP, so the web server configuration is not involved. Test with curl -v, and try curl -4 to rule out a broken IPv6 path.

Python: [Errno 113] No route to host

Raised as OSError by socket, and wrapped by libraries: requests shows ConnectionError … NewConnectionError … [Errno 113] No route to host, and paramiko raises NoValidConnectionsError or a plain socket error. Compare against errno.EHOSTUNREACH rather than the literal 113 so the code also works on macOS (65):

import errno
import socket

try:
    with socket.create_connection(("10.0.0.5", 8080), timeout=5):
        print("connected")
except OSError as e:
    if e.errno == errno.EHOSTUNREACH:
        print("No route to host: check the target firewall, IP address and routes")
    elif e.errno == errno.ECONNREFUSED:
        print("Host reachable, but nothing is listening on that port")
    else:
        raise

Kafka: "Connection … could not be established" / NoRouteToHostException

Kafka clients first contact a bootstrap server, then connect to the addresses the brokers advertise. Error 113 usually means one of these:

• The broker port (commonly 9092, or 9093/9094 for other listeners) is not open in firewalld on the broker host.
• advertised.listeners contains an address that is unreachable from the client, for example a Docker container IP or a private IP seen from outside.

Test every advertised host and port with nc -vz broker1 9092 from the client machine, not just the bootstrap address.

Docker and Kubernetes

• Container to host: a container connecting to a port on its own host gets errno 113 when the host firewall (often firewalld) rejects traffic from the Docker bridge network. Allow the port in the zone that covers the bridge interface (such as docker0).
• Pod to pod / node to node: dial tcp …: connect: no route to host between nodes usually means node firewalls are rejecting cluster traffic: the kubelet port 10250, the API server port 6443, or your CNI's overlay ports (for example VXLAN on UDP 8472 for Flannel). Check the ports your CNI documents.
• Services: run kubectl get endpoints <service>. If the list is empty, no ready pod backs the Service and connections to it are rejected.

OpenStack Neutron: [Errno 113] EHOSTUNREACH

Neutron and other OpenStack agents typically log this when they cannot reach the message queue or database, e.g. AMQP server on controller:5672 is unreachable: [Errno 113] EHOSTUNREACH. Check from the affected node that the management network is up and that the controller firewall allows RabbitMQ (5672), MySQL/MariaDB (3306) and the API ports. For instances, also check security groups and the metadata service path.

Squid: "The system returned: (113) No route to host"

This appears on Squid's connection-failed error page. The proxy server could not reach the website, so the problem is between Squid and the origin, not between your browser and Squid. Test from the proxy host itself (curl -v https://site/), check its routes and outbound firewall, and check whether it is trying an IPv6 address over a broken IPv6 path.

IBM MQ / z/OS: "TCP/IP (connect) call was 113 (X'71')"

IBM MQ communication errors (such as AMQ9213) print the operating system's errno in decimal and hex. X'71' is simply 113 written in hexadecimal. On Linux, 113 is EHOSTUNREACH, so the queue manager or client could not reach the remote listener's host: check the CONNAME address, the listener port (often 1414) in the remote firewall, and routing. On other platforms, including z/OS and AIX, errno numbers differ, so look the value up in that platform's own errno list rather than assuming it means the same thing.

Other tools that print errno 113

• PBS / Torque qstat (errno=113): the PBS server port (15001 by default) is rejected or unreachable from the submit host.
• Teleport "os error 113": the Teleport agent or proxy cannot reach the target host (for RDP, port 3389 on the Windows machine).
• MySQL/MariaDB: ERROR 2003 (HY000): Can't connect to MySQL server on 'host' (113). 2003 is MySQL's code and (113) is the errno. Open port 3306 on the server and check bind-address.
• PostgreSQL: could not connect to server: No route to host. Open port 5432 and check listen_addresses.
• Embedded and automotive tools (Vector CANoe, test rigs, PLC software) that print "errno 113" are passing the same network error through: the device's IP is not reachable on that interface.

Errno 113 With IPv6

Linux maps ICMPv6 errors slightly differently from IPv4. With IPv6, errno 113 most often means neighbor discovery failed (the IPv6 equivalent of ARP) or a router answered "address unreachable". An IPv6 firewall reject with icmp6-adm-prohibited is reported as EACCES, "Permission denied", not as error 113. If there is no IPv6 route at all, you get errno 101.

ip -6 route get 2001:db8::5
ip -6 neigh show
ping -6 -c 3 2001:db8::5
curl -4 -v https://example.com/   # compare with -6

If a name resolves to both IPv4 and IPv6 and only IPv6 fails, either fix IPv6 routing or make the client prefer IPv4.

Error 113 on an Already-Established Connection

Seeing "socket read error 113" or "No route to host" on a TCP connection that was working means the peer became unreachable mid-session. Linux keeps ICMP unreachable messages received during a connection as a "soft" error. When TCP finally gives up retransmitting, it reports that stored error (113) instead of a plain timeout. Typical causes are the peer rebooting or changing IP, a failover moving an address, a VPN tunnel dropping, or a stateful firewall losing its connection-tracking entry and rejecting the next packet. Add application-level reconnect logic and check the firewall and network logs at the time of the failure.

Other "Error 113" Codes That Are Not errno 113

Many products number their own errors, and "113" in those lists is unrelated to the Linux errno. Here is what can be said reliably:

Windows error 113

Windows does not use 113 for "No route to host". Its network equivalent is WSAEHOSTUNREACH (10065). Windows system error code 113 is ERROR_NO_MORE_SEARCH_HANDLES ("No more internal file identifiers"), which is unrelated to networking. If an application on Windows shows "error 113", it is almost always that application's own code or an errno passed through from a Linux server, so check the full message. (Earlier versions of this page wrongly described Winsock error 113 as WSAEPROVIDERFAILEDINIT; that error is actually 10106.)

HTTP 113 ("http113", "web:113")

There is no HTTP status code 113. The standard informational (1xx) status codes are 100 to 103. The number 113 existed in HTTP only as a Warning header code, "113 Heuristic Expiration", which caches added to responses older than 24 hours. RFC 9111 (2022) made the Warning header obsolete. An "HTTP 113" in an app or log is usually the app's own code, or errno 113 raised while opening the HTTP connection.

"routepacket_113" and similar log strings

We could not find a public, documented meaning for strings such as "routepacket_113" or "routepacket113". They look like internal identifiers from a specific product's logs. If the line also contains "No route to host" or "unreachable", treat it as errno 113 and follow the steps above. Otherwise, search the vendor's documentation or ask their support with the full log line.

IXON / Beijer: "Unexpected HTTP(S) response (113)"

This message comes from IXON's VPN client, which many machine builders and automation vendors use for remote access to their equipment. We have not found a public official definition of the 113 here, so check IXON's support documentation. The message indicates the VPN client could not complete its HTTPS exchange with the cloud service. Safe checks:

• Confirm the PC has normal internet access and the correct date and time (wrong time breaks HTTPS).
• Check whether a corporate proxy, SSL-inspection firewall or antivirus "web shield" is intercepting HTTPS or blocking the VPN client's outbound ports. Try another network, such as a phone hotspot, to compare.
• Restart the VPN client service, or reinstall or update the VPN client to the current version.
• If it persists, contact IXON (or your machine builder) support with the client log.

Dropbox, ADP and other app-specific "error 113"

Codes like Dropbox updater / update installer error 113, ADP error code 113, WhatsApp, Discord, CyberArk, F5, Junos Space or game and console "error 113" are defined by each vendor. We have not found official public definitions for them, so we won't guess. What generally helps:

• Dropbox updater error 113: download the latest installer directly from Dropbox's website and run it, ideally as administrator. Temporarily pause antivirus or firewall software that may block the updater, and make sure no old Dropbox process is still running. If it fails again, contact Dropbox support.
• ADP error code 113: this comes from ADP's own login or portal system. Clear the browser cache and cookies, try another browser or the ADP mobile app, confirm your user ID and registration status, and contact your employer's HR/payroll administrator or ADP support, who can see what the code means for your account.
• Everything else: note the exact message, check the vendor's status page and knowledge base, and test basic connectivity. If the message mentions "unreachable" or "no route", it is very likely the network errno described above.

Preventing Error 113

• Open firewall ports as part of deployment. When you install a service on a firewalld-based system, add the firewalld rule in the same step (Ansible, cloud-init, etc.).
• Use stable addresses. Use DNS names or DHCP reservations so clients don't keep connecting to an old IP.
• Monitor the port, not just ping. Health checks should open the actual TCP port, since ping can succeed while the port is rejected.
• Handle the error in code. Treat EHOSTUNREACH as retryable with exponential backoff and a clear log message that includes the IP and port.

const net = require('net');

function connectWithRetry(host, port, retries = 3, attempt = 0) {
  const socket = net.connect({ host, port });
  socket.once('connect', () => console.log('connected'));
  socket.once('error', (err) => {
    // err.code is 'EHOSTUNREACH' for "No route to host"
    if (err.code === 'EHOSTUNREACH' && attempt < retries) {
      const delay = 2 ** attempt * 1000;
      console.error(`No route to ${host}:${port}, retrying in ${delay} ms`);
      setTimeout(() => connectWithRetry(host, port, retries, attempt + 1), delay);
    } else {
      console.error(err);
    }
  });
}

connectWithRetry('10.0.0.5', 8080);

Frequently Asked Questions