리눅스 서버 접속 안 될 때 traceroute로 어느 구간에서 막히는지 확인하는 법

리눅스 서버 접속이 안 될 때 traceroute 명령어로 네트워크 경로를 확인하고 ping, nc, curl, ss, systemctl, journalctl 결과를 함께 보며 어느 구간에서 막히는지 점검하는 방법을 설명하는 대표 이미지

 

리눅스 서버에 접속이 안 되는 문제가 생기면 초보 운영자는 방화벽부터 의심하기 쉽습니다.

서버 접속이 안 됩니다.
API 호출이 안 됩니다.
방화벽 문제 아닌가요?
보안그룹 열어야 하는 거 아닌가요?

 

물론 방화벽이나 보안그룹 문제일 수도 있습니다.

하지만 바로 방화벽 설정을 바꾸기 전에 먼저 확인해야 할 것이 있습니다.

내 서버에서 대상 서버까지 네트워크 경로가 어느 구간까지 이어지는지입니다.

이때 사용할 수 있는 명령어가 traceroute입니다.

 

traceroute는 출발지 서버에서 대상 서버까지 가는 중간 경유 구간을 확인할 때 사용합니다.

이번 글에서는 리눅스 서버 접속이 안 될 때 traceroute로 어느 네트워크 구간에서 막히는지 확인하는 방법과, ping, nc, curl, ss, systemctl, journalctl을 어떤 순서로 함께 보면 좋은지 정리합니다.

접속 안 될 때 바로 방화벽부터 보면 위험한 이유

서버 접속이 안 된다고 해서 바로 방화벽 정책을 열거나, 보안그룹을 수정하거나, 네트워크 서비스를 재시작하면 더 큰 문제가 생길 수 있습니다.

초보 운영자가 하기 쉬운 실수는 이런 흐름입니다.

접속 안 됨
→ 방화벽 문제로 추정
→ 방화벽 정책부터 수정
→ 실제 원인은 서비스 미기동 또는 라우팅 문제
→ 원인 파악이 더 어려워짐

 

운영 서버에서는 “일단 열어보자”보다 “어디까지 되는지 확인하자”가 먼저입니다.

특히 아래 같은 조치는 원인 확인 없이 바로 하면 위험할 수 있습니다.

- 방화벽 전체 허용
- 보안그룹 전체 오픈
- 네트워크 서비스 재시작
- 서버 재기동
- 운영 중인 서비스 재시작

 

접속이 안 될 때 먼저 봐야 할 것은 이것입니다.

내 서버에서 대상 서버까지 패킷이 어느 구간까지 가는가?

 

이때 traceroute가 도움이 됩니다.

traceroute는 무엇을 확인하는 명령어일까?

traceroute는 내 서버에서 대상 서버까지 가는 네트워크 경로를 hop 단위로 보여주는 명령어입니다.

간단히 말하면 이런 흐름을 확인하는 도구입니다.

내 서버
→ 게이트웨이
→ 중간 라우터
→ 방화벽 또는 NAT 구간
→ 대상 서버

 

기본 사용법은 아래와 같습니다.

 

traceroute 203.0.113.10

 

도메인으로도 확인할 수 있습니다.

 

traceroute example.com

 

운영 상황에서는 가능하면 -n 옵션을 같이 사용하는 것이 좋습니다.

 

traceroute -n 203.0.113.10

 

-n 옵션은 IP를 이름으로 변환하지 않고 그대로 보여줍니다.

DNS 조회 때문에 결과가 느려지거나, 이름 변환 때문에 헷갈리는 상황을 줄일 수 있습니다.

ping, nc, curl, traceroute는 역할이 다릅니다

접속 장애를 볼 때 여러 명령어가 나오면 헷갈릴 수 있습니다.

초보 운영자 기준으로는 이렇게 나누면 됩니다.

ping
→ ICMP 응답 확인

nc
→ TCP 포트 접근 확인

curl
→ HTTP 응답 확인

traceroute
→ 대상까지 가는 네트워크 경로 확인

ss
→ 서버 내부 포트 LISTEN 확인

systemctl
→ 서비스 상태 확인

journalctl
→ 서비스 로그 확인

 

즉, traceroute는 서비스가 정상인지 확인하는 명령어가 아닙니다.

대상까지 가는 네트워크 경로를 보는 명령어입니다.

ping이 된다고 서비스가 정상이라는 뜻이 아닌 것처럼, traceroute가 된다고 애플리케이션이 정상이라는 뜻도 아닙니다.

ping과 실제 서비스 접속을 구분하는 흐름은 아래 글에서 먼저 볼 수 있습니다.

https://opsnote.tistory.com/34

리눅스 서버 ping 된다고 정상이라 하지 말고 포트와 curl까지 확인하는 법

 

ping이 안 된다고 바로 방화벽 문제로 단정하면 안 되는 이유는 아래 글에서 정리했습니다.

https://opsnote.tistory.com/35

리눅스 서버 ping 안 된다고 방화벽 문제라 하지 말고 포트와 curl까지 확인하는 법

 

가상의 운영 상황 예시

예를 들어 배치 서버에서 API 서버 호출이 안 된다고 가정해보겠습니다.

[상황]
- 출발지 서버: batch-01
- 대상 서버: api-01
- 대상 IP: 203.0.113.10
- 대상 포트: 443
- 증상: API 호출 실패
- 초보 운영자는 방화벽 문제를 의심

 

이때 바로 방화벽을 수정하기보다 먼저 확인해야 합니다.

 

ping -c 4 203.0.113.10
nc -vz -w 3 203.0.113.10 443
curl -I https://example.com
traceroute -n 203.0.113.10

 

이렇게 보면 문제를 나눠볼 수 있습니다.

ping 실패
→ ICMP 차단 또는 네트워크 응답 없음 가능성

nc 실패
→ TCP 포트 접근 실패 가능성

curl 실패
→ HTTP 응답 또는 애플리케이션 문제 가능성

traceroute 중간 끊김
→ 특정 네트워크 구간 확인 필요

 

명령어 하나로 결론을 내리는 것이 아니라, 결과를 조합해서 보는 것이 중요합니다.

1단계. 먼저 대상 정보를 정확히 정리하기

traceroute를 실행하기 전에 먼저 대상 정보를 정리해야 합니다.

접속 장애 문의가 이렇게 들어왔다고 가정해보겠습니다.

배치 서버에서 API 서버 호출이 안 됩니다.

 

이때 바로 명령어부터 치기보다 아래 정보를 먼저 정리합니다.

출발지 서버: batch-01
출발지 IP: 192.0.2.10
대상 서버: api-01
대상 IP: 203.0.113.10
대상 포트: 443
문제 상황: API 호출 실패
확인 위치: 출발지 서버에서 확인

 

초보일수록 이 부분을 건너뛰기 쉽습니다.

하지만 출발지와 대상지를 헷갈리면, 아무리 명령어를 많이 쳐도 엉뚱한 서버를 보고 있을 수 있습니다.

도메인 기반 접속이라면 DNS도 함께 확인합니다.

 

nslookup example.com

 

또는 아래처럼 확인할 수 있습니다.

 

dig example.com

 

도메인이 엉뚱한 IP를 가리키고 있으면 traceroute 문제가 아니라 DNS 문제일 수 있습니다.

2단계. 기본 traceroute 실행하기

대상 IP를 알고 있다면 먼저 아래처럼 확인합니다.

 

traceroute -n 203.0.113.10

 

예시 결과는 이런 식으로 나올 수 있습니다.

traceroute to 203.0.113.10 (203.0.113.10), 30 hops max
 1  192.0.2.1      1.123 ms  1.045 ms  1.008 ms
 2  198.51.100.1   2.341 ms  2.288 ms  2.301 ms
 3  198.51.100.10  4.827 ms  4.801 ms  4.790 ms
 4  203.0.113.10   6.112 ms  6.095 ms  6.088 ms

 

이 경우는 대상 서버까지 경로가 이어진 것으로 볼 수 있습니다.

그런데도 접속이 안 된다면 네트워크 경로보다 대상 포트, 서비스 상태, 애플리케이션 응답을 봐야 할 가능성이 큽니다.

포트 확인은 nc로 볼 수 있습니다.

 

nc -vz -w 3 203.0.113.10 443

 

HTTP 응답은 curl로 확인합니다.

 

curl -I https://example.com

 

nc로 TCP 포트가 열렸는지 확인하는 흐름은 아래 글에서 정리했습니다.

https://opsnote.tistory.com/36

리눅스 서버 포트 열렸는지 nc로 확인할 때 ping만 보지 말고 TCP 접속까지 확인하는 법

 

3단계. traceroute에서 별표가 나온다고 무조건 장애는 아닙니다

traceroute를 보면 이런 결과가 나올 때가 있습니다.

traceroute to 203.0.113.10 (203.0.113.10), 30 hops max
 1  192.0.2.1      1.204 ms  1.180 ms  1.160 ms
 2  * * *
 3  198.51.100.10  4.902 ms  4.880 ms  4.861 ms
 4  203.0.113.10   6.200 ms  6.188 ms  6.170 ms

 

2번 구간에 * * *가 보입니다.

초보 운영자는 이걸 보고 바로 이렇게 판단할 수 있습니다.

2번 장비에서 막혔구나.

 

하지만 꼭 그런 것은 아닙니다.

중간 장비가 traceroute 응답을 하지 않도록 설정되어 있을 수 있습니다.

중요한 것은 이것입니다.

별표 이후에도 경로가 계속 이어지는가?

 

별표가 중간에 한 번 나오더라도 뒤쪽 hop이 계속 나오고 대상 서버까지 도착한다면, 그 구간이 실제 장애라고 단정하면 안 됩니다.

중간 장비가 ICMP 또는 UDP 응답만 막고 있을 수 있습니다.

4단계. 특정 구간부터 계속 별표가 나오면 의심해야 합니다

이번에는 이런 결과를 보겠습니다.

traceroute to 203.0.113.10 (203.0.113.10), 30 hops max
 1  192.0.2.1      1.100 ms  1.080 ms  1.070 ms
 2  198.51.100.1   2.300 ms  2.280 ms  2.270 ms
 3  * * *
 4  * * *
 5  * * *
 6  * * *

 

이 경우는 조금 다르게 봐야 합니다.

3번 구간부터 계속 응답이 없고, 대상 서버까지 도달하지 못하고 있습니다.

이럴 때는 아래 가능성을 의심할 수 있습니다.

- 중간 라우팅 문제
- 방화벽 또는 보안 장비 차단
- VPN 또는 사설망 경로 문제
- 대상 네트워크 대역으로 가는 경로 누락
- 클라우드 라우팅 테이블 문제
- 보안그룹 또는 네트워크 ACL 문제

 

하지만 이때도 바로 방화벽을 수정하기보다 정보를 모아야 합니다.

출발지
대상지
대상 포트
traceroute 결과
nc 결과
curl 결과
확인 시간

 

이렇게 정리해야 네트워크 담당자나 보안 담당자와 이야기할 때 빨라집니다.

5단계. 첫 번째 hop부터 안 나오면 로컬 경로를 봅니다

첫 번째 hop부터 응답이 없을 때도 있습니다.

traceroute to 203.0.113.10 (203.0.113.10), 30 hops max
 1  * * *
 2  * * *
 3  * * *

 

이 경우에는 대상 서버 문제가 아닐 수도 있습니다.

출발지 서버의 기본 게이트웨이, 라우팅, 로컬 네트워크 설정을 먼저 봐야 합니다.

라우팅은 아래처럼 확인할 수 있습니다.

 

ip route

 

특정 대상 IP로 어떤 경로를 타는지 보려면 아래 명령도 사용할 수 있습니다.

 

ip route get 203.0.113.10

 

확인할 것은 아래입니다.

- 기본 게이트웨이가 있는지
- 대상 대역으로 가는 경로가 있는지
- 예상한 인터페이스로 나가는지
- 내부망으로 가야 하는데 외부망으로 나가고 있지 않은지

 

라우팅 결과가 낯설다면 혼자 결론 내리기보다 네트워크 담당자와 같이 확인하는 것이 안전합니다.

6단계. 대상 서버까지 도착하는데 접속이 안 되면 포트를 봅니다

traceroute가 대상 서버까지 도착한다고 해서 서비스 접속이 정상이라는 뜻은 아닙니다.

traceroute는 경로 확인이고, 대상 포트가 열려 있는지는 별도 확인해야 합니다.

포트는 nc로 확인할 수 있습니다.

 

nc -vz -w 3 203.0.113.10 443

 

HTTP/HTTPS 서비스라면 curl도 같이 봅니다.

 

curl -I https://example.com

 

이때는 네트워크 경로보다 아래 항목을 봐야 할 수 있습니다.

- 대상 서버에서 서비스가 떠 있는지
- 해당 포트를 LISTEN 중인지
- 서버 내부 방화벽에서 막고 있는지
- 애플리케이션이 정상 응답하는지
- 로드밸런서 뒤쪽 헬스체크가 실패 중인지
- WAF나 프록시에서 차단 중인지

 

서버 내부 포트 LISTEN 확인은 ss로 봅니다.

 

ss -lntp | grep ':443'

 

포트 LISTEN 확인은 아래 글에서도 정리했습니다.

https://opsnote.tistory.com/18

리눅스 서버 접속이 안 될 때 netstat보다 ss로 포트 확인하는 이유

 

7단계. TCP 포트 기준 traceroute가 필요할 때도 있습니다

일반적인 traceroute 결과가 애매할 때가 있습니다.

기본 traceroute는 환경에 따라 UDP 또는 ICMP 응답이 중간 장비에서 막힐 수 있습니다.

그런데 실제 서비스 포트는 443일 수 있습니다.

이럴 때는 TCP 기준으로 확인해볼 수 있습니다.

 

sudo traceroute -T -p 443 -n 203.0.113.10

 

옵션을 간단히 보면 이렇습니다.

-T
→ TCP 방식으로 확인

-p 443
→ 443 포트 기준으로 확인

-n
→ IP를 이름으로 변환하지 않음

 

다만 이 명령은 환경에 따라 권한이 필요할 수 있습니다.

운영 서버에서 sudo 사용이 제한되어 있다면 무리해서 실행하지 말고, 권한 정책에 맞게 확인해야 합니다.

또한 TCP traceroute 결과도 절대적인 정답은 아닙니다.

중간 장비 정책, 클라우드 네트워크, 보안 장비 설정에 따라 결과가 다르게 보일 수 있습니다.

8단계. ICMP 기준 traceroute도 있습니다

ping과 비슷한 방식으로 경로를 보고 싶다면 -I 옵션을 사용할 수 있습니다.

 

traceroute -I -n 203.0.113.10

 

하지만 ICMP는 보안 정책상 막혀 있는 경우가 많습니다.

그래서 ICMP traceroute가 안 된다고 해서 바로 네트워크 장애라고 보면 안 됩니다.

운영에서는 상황에 따라 결과를 비교해서 봅니다.

 

traceroute -n 203.0.113.10
traceroute -I -n 203.0.113.10
sudo traceroute -T -p 443 -n 203.0.113.10

 

한 가지 결과만 보고 결론 내리기보다, 문제 상황에 맞는 방식으로 비교하는 것이 안전합니다.

9단계. 외부 확인과 서버 내부 확인을 구분해야 합니다

접속 장애에서는 “어디에서 확인했는지”가 중요합니다.

외부 클라이언트에서 확인할 수 있는 명령은 보통 아래입니다.

 

ping -c 4 203.0.113.10
nc -vz -w 3 203.0.113.10 443
curl -I https://example.com
traceroute -n 203.0.113.10

 

서버 내부에서 확인하는 명령은 아래처럼 볼 수 있습니다.

 

ss -lntp | grep ':443'
curl -I http://127.0.0.1
systemctl status nginx --no-pager
journalctl -u nginx -n 100 --no-pager

 

결과는 이렇게 나눠서 봅니다.

외부 traceroute 중간 끊김, 내부 서비스 정상
→ 네트워크 경로, 방화벽, 보안그룹, LB, WAF 확인

외부 traceroute 도착, nc 실패
→ 대상 포트 또는 서비스 상태 확인

외부 nc 성공, curl 실패
→ HTTP 응답 또는 애플리케이션 문제 확인

서버 내부 ss LISTEN 없음
→ 서비스 미기동 또는 포트 설정 문제 확인

 

내부에서는 되는데 외부에서 안 되면 외부 접근 경로를 봐야 합니다.

내부에서도 안 되면 서비스 상태와 로그부터 보는 것이 좋습니다.

10단계. 서비스 상태와 로그도 함께 확인합니다

네트워크 경로가 정상으로 보이는데 서비스 접속이 안 된다면 서비스 상태를 봐야 합니다.

 

systemctl status nginx --no-pager

 

실패한 서비스 목록을 먼저 볼 수도 있습니다.

 

systemctl --failed

 

서비스가 failed라면 journalctl로 로그를 확인합니다.

 

journalctl -u nginx -n 100 --no-pager

 

여기서 확인할 키워드는 아래와 같습니다.

failed
denied
permission
timeout
address already in use
syntax error
connection refused
not found

 

서비스 상태 확인은 아래 글에서 정리했습니다.

https://opsnote.tistory.com/27

리눅스 서버 서비스가 안 뜰 때 재기동부터 하지 말고 systemctl status 먼저 확인하는 법

 

실패한 서비스 목록 확인은 아래 글에서 볼 수 있습니다.

https://opsnote.tistory.com/32

리눅스 서버에서 실패한 서비스 한 번에 확인하는 systemctl --failed 사용법

 

서비스 로그 확인은 아래 글에서 정리했습니다.

https://opsnote.tistory.com/33

리눅스 서버 서비스 장애 났을 때 journalctl로 systemd 로그 확인하는 법

 

11단계. 방화벽, 보안그룹, LB, WAF는 언제 볼까?

방화벽이나 보안그룹을 봐야 할 때도 있습니다.

하지만 바로 수정하는 것이 아니라, 아래 조건을 먼저 확인합니다.

- 대상 IP와 도메인이 맞음
- traceroute 결과 특정 구간 이후 응답이 끊김
- 서버 내부에서는 포트 LISTEN 상태가 정상임
- 서버 내부 curl 응답은 정상임
- 외부에서 nc 또는 curl이 실패함

 

이런 경우라면 외부 접근 경로를 의심할 수 있습니다.

확인 대상은 환경에 따라 다릅니다.

- OS 방화벽
- 클라우드 보안그룹
- 네트워크 ACL
- 라우팅 테이블
- Load Balancer
- WAF
- Ingress
- 프록시 설정
- VPN 또는 사설망 경로

 

반대로 서버 내부에서도 포트가 열려 있지 않다면 방화벽보다 서비스 미기동을 먼저 봐야 합니다.

서버 내부 ss LISTEN 없음
→ systemctl status, journalctl 확인

서버 내부 curl 성공, 외부 curl 실패
→ 방화벽, 보안그룹, LB, WAF 확인

 

서버 전체 상태까지 같이 봐야 한다면 아래 체크리스트도 도움이 됩니다.

https://opsnote.tistory.com/19

리눅스 서버 재기동 전 바로 껐다 켜지 말고 확인해야 할 체크리스트

 

12단계. traceroute만 보고 네트워크 문제라고 단정하면 안 됩니다

초보 운영자가 자주 하는 실수는 명령어 결과 하나로 너무 빨리 결론을 내리는 것입니다.

예를 들어 이런 판단은 위험합니다.

traceroute에 별표가 있다
→ 중간 장비 문제다
→ 방화벽을 열어야 한다

 

하지만 실제로는 중간 장비가 traceroute 응답만 막고 있을 수 있습니다.

또 이런 판단도 위험합니다.

traceroute는 도착한다
→ 네트워크는 정상이다

 

경로는 도착해도 서비스 포트가 막혀 있을 수 있습니다.

정리하면 이렇게 봐야 합니다.

traceroute
→ 경로 확인

nc
→ TCP 포트 확인

curl
→ HTTP 응답 확인

ss
→ 서버 내부 LISTEN 확인

systemctl, journalctl
→ 서비스 상태와 로그 확인

 

결과를 조합해야 안전합니다.

13단계. 접속 안 될 때 안전한 확인 순서

접속 장애 상황에서는 아래 순서가 무난합니다.

1. 출발지 서버와 대상 서버를 정확히 확인한다
2. 대상 IP와 포트를 확인한다
3. DNS 이름과 IP를 구분해서 확인한다
4. ping으로 ICMP 응답을 확인한다
5. nc로 TCP 포트 접근을 확인한다
6. curl로 HTTP 응답을 확인한다
7. traceroute -n으로 경로를 확인한다
8. 필요하면 TCP 포트 기준 traceroute를 확인한다
9. 서버 내부에서 ss로 LISTEN 상태를 확인한다
10. systemctl status로 서비스 상태를 확인한다
11. journalctl로 서비스 로그를 확인한다
12. 결과를 정리해서 담당자에게 공유한다

 

명령어로 보면 이런 흐름입니다.

 

getent hosts example.com
ping -c 4 203.0.113.10
nc -vz -w 3 203.0.113.10 443
curl -I https://example.com
traceroute -n 203.0.113.10
ss -lntp | grep ':443'
systemctl status nginx --no-pager
journalctl -u nginx -n 100 --no-pager

 

운영 서버에서는 명령어를 많이 치는 것보다 순서를 지키는 것이 더 중요합니다.

14단계. 장애 공유할 때는 이렇게 정리하면 좋습니다

접속 장애를 혼자 해결하기 어려울 때는 결과를 정리해서 공유해야 합니다.

이때 실제 회사명, 고객사명, 실제 IP, 실제 도메인, 실제 로그 원문은 외부에 노출하면 안 됩니다.

내부 공유용으로는 필요한 범위만 정리합니다.

출발지 서버: batch-01
출발지 IP: 192.0.2.10
대상 서버: api-01
대상 IP: 203.0.113.10
대상 포트: 443
증상: curl 접속 실패
traceroute 결과: 198.51.100.1 이후 응답 없음
nc 결과: 443 포트 timed out
확인 시간: 2026-06-14 10:30 KST
추가 확인: DNS 조회 정상, 서버 내부 LISTEN 여부 확인 필요

 

이렇게 정리하면 “접속 안 됩니다”보다 훨씬 빠르게 다음 확인으로 넘어갈 수 있습니다.

15단계. 실무 보고 예시

traceroute 결과 대상까지 도착한 경우는 이렇게 쓸 수 있습니다.

traceroute 기준 대상 서버까지 경로는 확인되었습니다.
다만 서비스 접속은 실패 중이므로 대상 포트, 서비스 상태, 애플리케이션 로그를 추가 확인하겠습니다.

 

중간 구간 이후 응답이 없는 경우는 이렇게 정리할 수 있습니다.

traceroute 확인 결과 198.51.100.1 이후 응답이 확인되지 않습니다.
대상 포트 443 nc 결과도 timed out으로 확인되어, 중간 네트워크 구간 또는 보안 정책을 추가 확인하겠습니다.

 

별표가 중간에만 보이는 경우는 이렇게 쓸 수 있습니다.

traceroute 중간 hop에서 일부 응답 누락이 확인되었으나, 이후 hop 응답은 계속 확인됩니다.
중간 장비의 ICMP/UDP 응답 제한 가능성이 있어 서비스 포트와 curl 응답 기준으로 추가 판단하겠습니다.

 

서비스 상태 확인이 필요한 경우는 이렇게 정리할 수 있습니다.

네트워크 경로는 확인되나 서비스 포트 응답이 없어 대상 서버 내부 LISTEN 상태와 systemctl 상태를 확인하겠습니다.

 

방화벽 문제로 단정하기 어려울 때는 이렇게 정리합니다.

현재 traceroute 결과만으로 방화벽 문제로 단정하기는 어렵습니다.
ping, nc, curl, 서버 내부 ss, 서비스 로그를 함께 확인해 원인 범위를 좁히겠습니다.

 

이렇게 쓰면 단순히 “네트워크 문제 같습니다”보다 훨씬 정확합니다.

정리하면

리눅스 서버 접속이 안 될 때 방화벽부터 보는 습관은 위험할 수 있습니다.

먼저 traceroute로 네트워크 경로를 확인하고, nc나 curl로 실제 포트와 응답을 확인한 뒤 원인을 좁혀가는 것이 안전합니다.

기본 명령어는 아래입니다.

 

traceroute -n 203.0.113.10

 

포트 확인은 아래처럼 볼 수 있습니다.

 

nc -vz -w 3 203.0.113.10 443

 

HTTP 응답은 아래처럼 확인합니다.

 

curl -I https://example.com

 

서버 내부에서는 포트와 서비스 상태를 봅니다.

 

ss -lntp | grep ':443'
systemctl status nginx --no-pager
journalctl -u nginx -n 100 --no-pager

 

초보 운영자라면 이 문장만 기억해도 좋습니다.

traceroute에 별표가 나온다고 바로 네트워크 장애로 단정하지 마세요.

접속 장애도 결국 같습니다.

확인 → 판단 → 조치 → 재확인

 

traceroute에서 별표가 보인다고 바로 네트워크 장애로 단정하면 안 됩니다.

접속 장애는 경로 확인뿐 아니라 포트 연결, HTTP 응답, 서비스 상태, DNS 응답을 함께 봐야 더 안전하게 판단할 수 있습니다.

포트 연결과 HTTP 응답을 구분해서 보고 싶다면 curl과 nc 차이를 아래 글에서 이어서 볼 수 있습니다.

https://opsnote.tistory.com/38

리눅스 서버 접속 확인할 때 curl과 nc 차이, 포트와 HTTP 응답을 구분하는 법

 

접속 장애를 ping, nc, curl, DNS 순서로 정리해서 보고 싶다면 아래 글을 함께 보면 좋습니다.

https://opsnote.tistory.com/71

리눅스 서버 접속 장애 확인 순서 총정리