Linux No Route to Host 오류의 원인과 해결 방법

작성자:

Linux 서버를 운영하다 보면 SSH 접속, 웹 서버 연결, 데이터베이스 접속 또는 API 통신 중 No route to host, EHOSTUNREACH와 같은 오류를 만나는 경우가 있습니다. 이 오류는 목적지 서버까지 도달할 수 있는 네트워크 경로(Route)가 없거나 중간 네트워크 장비에서 통신이 차단될 때 발생하는 대표적인 네트워크 오류입니다.

특히 서버 간 통신, Docker, Kubernetes, VPN, 클라우드 환경에서는 라우팅 설정이나 방화벽 정책 문제로 자주 발생합니다.

이번 글에서는 No Route to Host 오류의 원인과 확인 방법, 해결 방법을 실무 중심으로 자세히 알아보겠습니다.

No Route to Host란?

Linux에서 다른 서버로 TCP 연결을 시도하면 운영체제는 먼저 목적지까지의 경로를 확인합니다.

동작 과정은 다음과 같습니다.

Application

↓

TCP Connect()

↓

Routing Table 확인

↓

Gateway 선택

↓

목적지 전송

하지만 목적지까지 이동할 수 있는 경로가 없으면 다음과 같은 오류가 발생합니다.

No route to host

EHOSTUNREACH

즉, 목적지 서버에 도착하기 위한 네트워크 경로를 찾을 수 없는 상태입니다.

No Route to Host가 발생하는 주요 원인

대표적인 원인은 다음과 같습니다.

  • 라우팅 테이블 오류
  • 기본 게이트웨이(Default Gateway) 설정 오류
  • 목적지 서버 다운
  • 방화벽 차단
  • Security Group 차단
  • Network ACL 차단
  • VPN 연결 문제
  • Docker 네트워크 오류
  • Kubernetes CNI 오류
  • 잘못된 IP 주소 입력

실무에서는 방화벽 또는 라우팅 설정 오류가 가장 많이 발생합니다.

1. 목적지 서버 Ping 확인하기

먼저 목적지 서버가 응답하는지 확인합니다.

ping 192.168.10.100

응답이 없다면 서버가 종료되었거나 네트워크가 차단되었을 가능성이 있습니다.

2. Routing Table 확인하기

현재 라우팅 정보를 확인합니다.

ip route

또는

route -n

기본 게이트웨이와 목적지 네트워크가 올바르게 설정되어 있는지 확인합니다.

3. 기본 게이트웨이 확인하기

기본 경로를 확인합니다.

ip route | grep default

예시

default via 192.168.10.1 dev eth0

기본 게이트웨이가 없으면 외부 네트워크로 통신할 수 없습니다.

4. 인터페이스 상태 확인하기

네트워크 인터페이스가 정상인지 확인합니다.

ip addr

또는

ip link

DOWN 상태라면 통신이 불가능합니다.

5. 목적지까지의 경로 확인하기

Traceroute를 사용합니다.

traceroute 192.168.10.100

또는

tracepath 192.168.10.100

어느 구간에서 통신이 끊기는지 확인할 수 있습니다.

6. 방화벽 확인하기

iptables 사용 시

iptables -L -n

firewalld 사용 시

firewall-cmd --list-all

필요한 포트와 프로토콜이 허용되어 있는지 확인합니다.

7. 클라우드 보안 정책 확인하기

AWS 환경이라면 다음 항목을 확인합니다.

  • Security Group
  • Network ACL
  • Route Table

Azure와 GCP도 동일하게 보안 정책과 라우팅 구성을 확인해야 합니다.

8. Docker 및 Kubernetes 확인하기

Docker 네트워크 확인

docker network ls

Kubernetes Pod 확인

kubectl get pods -A -o wide

CNI 플러그인 오류나 Overlay Network 문제도 점검합니다.

9. ARP 확인하기

동일한 네트워크라면 ARP 정보를 확인합니다.

ip neigh

또는

arp -a

ARP가 정상적으로 학습되지 않으면 통신이 실패할 수 있습니다.

10. 로그 확인하기

커널 로그를 확인합니다.

dmesg | grep -i network

또는

journalctl -k

네트워크 인터페이스 오류나 드라이버 문제도 함께 확인합니다.

No Route to Host 점검 순서

실무에서는 다음 순서대로 확인하는 것이 좋습니다.

  1. Ping 확인
  2. Routing Table 확인
  3. Default Gateway 확인
  4. 인터페이스 상태 확인
  5. Traceroute 실행
  6. 방화벽 확인
  7. 클라우드 보안 정책 확인
  8. Docker/Kubernetes 확인
  9. ARP 확인
  10. 커널 로그 분석

No Route to Host 사용 시 주의사항

다음 사항을 고려해야 합니다.

  • 목적지 서버가 실제로 실행 중인지 먼저 확인한다.
  • 라우팅 테이블을 우선 점검한다.
  • 방화벽 정책도 반드시 확인한다.
  • Security Group과 Network ACL을 함께 확인한다.
  • VPN 사용 시 터널 상태도 점검한다.
  • Docker와 Kubernetes 환경도 함께 분석한다.

단순히 Ping이 되지 않는다고 해서 항상 서버 문제라고 단정해서는 안 됩니다.

No Route to Host와 Connection Timed Out의 차이

항목No Route to HostConnection Timed Out
오류 코드EHOSTUNREACHETIMEDOUT
원인경로 없음응답 없음
라우팅실패성공
TCP 연결시작되지 않음시작 후 응답 없음

No Route to Host는 경로 자체를 찾지 못하는 경우, Connection Timed Out은 경로는 있지만 응답을 받지 못하는 경우입니다.

자주 묻는 질문

Ping이 되지 않으면 반드시 No Route to Host인가요?

아닙니다. 방화벽에서 ICMP를 차단했거나 서버가 Ping 응답을 허용하지 않는 경우에도 Ping은 실패할 수 있습니다.

SSH에서 No Route to Host가 발생하는 이유는 무엇인가요?

라우팅 오류, 방화벽 차단, VPN 연결 문제, 잘못된 IP 주소 설정 등이 대표적인 원인입니다.

클라우드 환경에서도 자주 발생하나요?

네. AWS, Azure, GCP에서는 Security Group, Route Table, Network ACL 설정 오류로 인해 자주 발생합니다.

마무리

No Route to Host(EHOSTUNREACH)는 목적지 서버까지 도달할 네트워크 경로를 찾을 수 없을 때 발생하는 대표적인 Linux 네트워크 오류입니다. ip route, traceroute, ping, iptables, journalctl 등을 활용하면 원인을 빠르게 분석할 수 있으며, 라우팅 정보와 방화벽 정책, 클라우드 네트워크 설정을 함께 점검하면 대부분의 문제를 해결할 수 있습니다.

댓글 남기기