ping은 되는데 사이트가 안 열릴 때 nc와 curl로 확인하는 실제 점검 흐름

PING CHECK ping은 되는데 사이트가 안 열릴 때 nc → curl → DNS → 로그 확인

리눅스 서버나 웹 서비스를 운영하다 보면 이런 말을 들을 때가 있습니다.

서버는 살아 있는 것 같은데 사이트가 안 열립니다.
ping은 됩니다.
그런데 브라우저에서는 접속이 안 됩니다.

처음에는 헷갈립니다.

ping이 되면 서버가 살아 있는 것처럼 보입니다.
그래서 초보 운영자 입장에서는 “네트워크는 정상인데 왜 사이트가 안 열리지?”라는 생각이 들 수 있습니다.

저도 처음에는 ping 결과를 보고 꽤 안심했던 적이 있습니다.
하지만 운영 서버에서는 ping이 된다는 것과 웹 서비스가 정상이라는 것은 전혀 다른 이야기입니다.

ping은 주로 ICMP 응답을 확인합니다.
반면 웹사이트 접속은 TCP 포트, 웹서버, 애플리케이션, 인증서, 라우팅, DNS, HTTP 응답까지 함께 봐야 합니다.

이번 글에서는 ping은 되는데 사이트가 안 열릴 때, nc와 curl을 이용해서 어디까지 정상인지 실제 운영 흐름처럼 좁혀보겠습니다.

핵심은 단순합니다.

ping이 된다고 서비스가 되는 것은 아닙니다.

운영 서버에서는 항상 확인 → 판단 → 조치 → 재확인 순서가 먼저입니다.

---

1. 먼저 “사이트가 안 열린다”를 나눠서 봅니다

“사이트가 안 열린다”는 말은 생각보다 넓습니다.

브라우저에서 보이는 증상도 여러 가지입니다.

• 페이지가 계속 로딩됨
• 연결 시간이 초과됨
• 연결이 거부됨
• 403, 404, 500 같은 HTTP 오류가 뜸
• 인증서 경고가 뜸
• 특정 사용자만 접속이 안 됨
• 내부에서는 되는데 외부에서는 안 됨
• 도메인은 안 되는데 IP로는 됨

이 증상들은 비슷해 보이지만 원인이 다를 수 있습니다.

그래서 처음에는 이렇게 나눠야 합니다.

사이트가 안 열린다.
그러면 DNS 문제인지, 포트 문제인지, HTTP 응답 문제인지 나눠서 본다.

여기서 바로 서버 재기동부터 하면 안 됩니다.

웹 접속 장애는 서버 프로세스 문제가 아닐 수도 있습니다.
DNS, 방화벽, 로드밸런서, WAF, 포트, 인증서, 애플리케이션 라우팅 문제일 수도 있습니다.

---

2. ping은 참고용으로만 봅니다

먼저 많은 사람이 ping부터 확인합니다.

ping -c 4 example.com

또는 IP로 확인할 수도 있습니다.

ping -c 4 203.0.113.10

ping이 정상으로 보이면 서버나 장비가 ICMP에 응답하고 있다는 뜻입니다.

하지만 여기서 바로 “서비스 정상”이라고 판단하면 안 됩니다.

ping이 된다는 것은 대략 이런 의미에 가깝습니다.

• 대상까지 ICMP 응답이 올 수 있음
• 서버나 네트워크 장비가 완전히 죽은 것은 아닐 가능성이 있음
• 기본적인 경로가 일부 살아 있을 가능성이 있음

하지만 아래는 보장하지 않습니다.

• 80 포트가 열려 있는지
• 443 포트가 열려 있는지
• nginx나 Apache가 정상인지
• 애플리케이션이 정상인지
• HTTP 응답이 정상인지
• DNS가 의도한 IP를 바라보는지
• 인증서가 정상인지

그래서 ping 결과는 시작점일 뿐입니다.

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

ping은 서버 생존 여부를 보는 참고 자료이고, 서비스 정상 여부를 보장하지 않습니다.

ping은 되는데 서비스가 안 될 때의 기본 흐름은 아래 글에서 정리했습니다.

https://opsnote.tistory.com/34

---

3. nc로 포트 연결 여부를 확인합니다

ping이 된다면 다음은 실제 서비스 포트가 열려 있는지 확인해야 합니다.

웹 서비스라면 보통 80 또는 443 포트를 봅니다.

nc -vz example.com 80

nc -vz example.com 443

여기서 중요한 것은 ping이 아니라 TCP 포트 연결 여부입니다.

nc 결과가 성공하면, 클라이언트 입장에서 해당 포트까지 TCP 연결은 가능한 상태로 볼 수 있습니다.

예를 들어 이런 결과가 나올 수 있습니다.

Connection to example.com 443 port [tcp/https] succeeded!

이 경우에는 최소한 443 포트까지는 연결이 되는 것입니다.

반대로 아래처럼 나오면 포트 연결 자체가 안 되는 상황일 수 있습니다.

Connection timed out

또는 이렇게 나올 수도 있습니다.

Connection refused

이 두 결과는 느낌이 다릅니다.

timed out은 중간에서 막히거나 응답이 없는 상황일 수 있습니다.
refused는 대상까지는 갔지만 해당 포트에서 받아주는 서비스가 없을 때 볼 수 있습니다.

정리하면 이렇게 볼 수 있습니다.

ping 성공
nc 실패
→ 서버는 응답하지만 서비스 포트는 안 열렸거나 중간에서 막혔을 수 있음

포트가 열렸는지 nc로 확인하는 방법은 아래 글에서 이어서 볼 수 있습니다.

https://opsnote.tistory.com/36

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

 

---

4. nc 성공이 서비스 정상이라는 뜻은 아닙니다

여기서 한 번 더 조심해야 합니다.

nc가 성공했다고 해서 웹 서비스가 정상이라는 뜻은 아닙니다.

nc는 TCP 포트 연결 여부를 보는 데 가깝습니다.
하지만 웹 서비스는 TCP 연결만으로 끝나지 않습니다.

예를 들어 443 포트 연결은 되지만 이런 문제가 있을 수 있습니다.

• 웹서버는 떠 있지만 애플리케이션 오류가 있음
• 인증서 문제가 있음
• 리버스 프록시 뒤쪽 upstream이 죽어 있음
• HTTP 500 응답이 발생함
• 특정 경로만 404가 발생함
• 로그인 페이지나 API 경로만 실패함

그래서 nc 다음에는 curl로 HTTP 응답을 확인해야 합니다.

흐름은 이렇게 잡습니다.

ping으로 기본 응답 확인
→ nc로 포트 연결 확인
→ curl로 HTTP 응답 확인

---

5. curl로 HTTP 응답을 확인합니다

웹 서비스 상태를 확인할 때는 curl이 유용합니다.

먼저 헤더만 간단히 확인할 수 있습니다.

curl -I https://example.com

HTTP 상태 코드와 응답 헤더를 볼 수 있습니다.

예를 들어 정상이라면 이런 식의 응답을 기대할 수 있습니다.

HTTP/2 200

또는 리다이렉트가 있는 경우 아래처럼 볼 수 있습니다.

HTTP/1.1 301 Moved Permanently

오류가 있다면 이런 코드가 보일 수 있습니다.

HTTP/1.1 403 Forbidden
HTTP/1.1 404 Not Found
HTTP/1.1 500 Internal Server Error
HTTP/1.1 502 Bad Gateway
HTTP/1.1 504 Gateway Timeout

여기서 중요한 것은 상태 코드입니다.

nc가 성공했는데 curl에서 502가 나온다면, 포트는 열려 있지만 뒤쪽 애플리케이션이나 upstream 문제가 있을 수 있습니다.

curl에서 404가 나온다면, 서버는 응답하지만 경로나 라우팅 문제가 있을 수 있습니다.

curl에서 timeout이 난다면, 포트 연결 이후 응답이 지연되거나 중간 구간 문제가 있을 수 있습니다.

curl과 nc 차이는 아래 글에서 따로 정리했습니다.

https://opsnote.tistory.com/38

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

 

---

6. DNS가 의도한 IP를 바라보는지도 확인합니다

도메인으로 접속이 안 될 때는 DNS도 함께 확인해야 합니다.

특히 이런 상황에서는 DNS를 봐야 합니다.

• IP로는 접속되는데 도메인으로는 안 됨
• 일부 사용자만 접속이 안 됨
• 최근 DNS 변경 작업이 있었음
• 로드밸런서 IP 변경이 있었음
• 내부 DNS와 외부 DNS 결과가 다름

가볍게 확인할 때는 nslookup을 사용할 수 있습니다.

nslookup example.com

조금 더 자세히 보고 싶다면 dig를 사용할 수 있습니다.

dig example.com

DNS 확인에서 볼 것은 단순히 응답이 있느냐가 아닙니다.

의도한 IP를 바라보고 있는지 봐야 합니다.

예를 들어 서비스가 원래 203.0.113.10을 바라봐야 하는데, DNS 결과가 다른 IP를 반환한다면 접속 장애 원인이 DNS일 수 있습니다.

도메인 확인은 아래 글들도 함께 보면 좋습니다.

https://opsnote.tistory.com/39

리눅스 서버 도메인 안 된다고 서버부터 보지 말고 nslookup으로 DNS부터 확인하는 법

 

https://opsnote.tistory.com/40

리눅스 서버 nslookup만 보지 말고 dig로 DNS 응답까지 확인하는 법

 

---

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

외부에서 nc나 curl로 확인했다면, 서버 내부에서도 상태를 확인해야 합니다.

웹서버가 실제로 포트를 열고 있는지 봅니다.

ss -lntp | grep ':80'

ss -lntp | grep ':443'

서비스 상태도 봅니다.

systemctl status nginx --no-pager

Apache라면 이렇게 볼 수 있습니다.

systemctl status httpd --no-pager

최근 로그도 확인합니다.

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

서비스가 떠 있는데 외부에서 접속이 안 된다면 방화벽, 보안그룹, 로드밸런서, WAF 구간을 봐야 할 수 있습니다.

반대로 서버 내부에서도 포트가 안 열려 있다면 웹서버 설정, 서비스 실패, 포트 충돌, 애플리케이션 기동 문제를 먼저 봐야 합니다.

서비스 상태 확인은 아래 글에서 이어서 볼 수 있습니다.

https://opsnote.tistory.com/27

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

 

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

https://opsnote.tistory.com/33

리눅스 서버 systemctl status만 보지 말고 journalctl로 서비스 로그 확인하는 법

 

---

8. traceroute는 경로 참고용으로 봅니다

접속이 안 될 때 경로를 보고 싶다면 traceroute를 사용할 수 있습니다.

traceroute example.com

하지만 traceroute 결과에 별표가 보인다고 바로 장애로 단정하면 안 됩니다.

중간 장비가 ICMP 응답을 제한할 수도 있고, 경로상 장비가 응답하지 않도록 설정되어 있을 수도 있습니다.

그래서 traceroute는 참고 자료로 보는 것이 좋습니다.

경로 확인은 도움이 되지만, 실제 서비스 판단은 nc, curl, DNS, 서비스 상태, 로그를 함께 봐야 합니다.

traceroute를 볼 때 주의할 점은 아래 글에서 정리했습니다.

https://opsnote.tistory.com/37

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

 

---

9. 결과를 조합해서 원인을 좁힙니다

이제 결과를 조합해야 합니다.

각 명령어는 보는 영역이 다릅니다.

ping
→ ICMP 응답 확인

nc
→ TCP 포트 연결 확인

curl
→ HTTP 응답 확인

nslookup, dig
→ DNS 응답 확인

ss
→ 서버 내부 포트 listen 확인

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

예를 들어 이런 식으로 판단할 수 있습니다.

ping 성공, nc 실패
→ 서버는 응답하지만 포트 연결이 안 되는 상태일 수 있음

nc 성공, curl 502
→ 포트는 열렸지만 뒤쪽 애플리케이션이나 upstream 문제일 수 있음

DNS 결과가 다른 IP
→ 도메인이 의도한 서버를 바라보지 않을 수 있음

서버 내부 ss에서 포트 없음
→ 웹서버가 포트를 열지 않았을 수 있음

systemctl failed
→ 서비스 기동 실패 원인부터 확인해야 함

이렇게 조합해서 봐야 합니다.

명령어 하나만 보고 결론을 내리면 위험합니다.

---

10. 조치 전에 영향도를 확인합니다

원인을 어느 정도 좁혔다면 조치를 고민해야 합니다.

하지만 운영 서버에서는 조치 전에 영향도를 먼저 봐야 합니다.

예를 들어 아래 작업은 모두 영향이 있을 수 있습니다.

• 웹서버 restart
• 설정 파일 수정
• 방화벽 정책 변경
• 로드밸런서 대상 변경
• DNS 레코드 변경
• WAF 정책 수정
• 애플리케이션 재기동

조치 전에는 최소한 아래를 정리하는 것이 좋습니다.

확인된 사실:
ping, nc, curl, DNS, 서비스 상태 결과

추정 원인:
포트 차단, DNS 오류, 웹서버 오류, upstream 장애, 설정 문제

조치 계획:
서비스 재기동, 설정 수정, 방화벽 확인, DNS 확인, 담당자 협의

영향 범위:
접속 중인 사용자, 외부 서비스 영향, 장애 지속 시간

원복 방법:
변경 전 설정, 기존 DNS 값, 기존 방화벽 정책, 서비스 상태

운영 서버에서는 빠른 조치보다 안전한 조치가 중요합니다.

---

11. 조치 후에는 다시 확인합니다

조치가 끝났다면 반드시 다시 확인해야 합니다.

다시 확인할 명령어는 처음 확인했던 것과 비슷합니다.

ping -c 4 example.com

nc -vz example.com 443

curl -I https://example.com

nslookup example.com

서버 내부에서는 서비스 상태와 로그도 다시 봅니다.

systemctl status nginx --no-pager

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

조치 후 확인할 것은 아래와 같습니다.

• DNS가 의도한 IP를 바라보는가?
• 포트 연결이 되는가?
• HTTP 응답 코드가 정상인가?
• 서비스가 active 상태인가?
• 최근 로그에 같은 오류가 반복되지 않는가?
• 외부와 내부에서 결과가 같은가?

접속 장애는 조치보다 재확인이 더 중요할 때가 많습니다.

---

12. 보고는 구간별로 정리합니다

접속 장애를 확인한 뒤에는 보고도 남겨야 합니다.

보고는 길게 쓰기보다 어느 구간까지 확인했는지 나누는 것이 좋습니다.

예시는 이렇게 정리할 수 있습니다.

[현상]
도메인 접속 불가 신고 접수

[확인]
ping 응답 정상
nc 확인 결과 443 포트 연결 실패
nslookup 결과 도메인은 정상 IP 반환
서버 내부 ss 확인 결과 443 포트 listen 없음
systemctl status 확인 결과 nginx failed 상태 확인
journalctl 확인 결과 설정 파일 오류 메시지 확인

[조치]
설정 파일 오류 수정 후 nginx 재기동
서비스 active 상태 확인
443 포트 listen 확인
curl -I 결과 HTTP 200 응답 확인

[결과]
도메인 접속 정상 확인
동일 오류 로그 재발 없음

[추가 확인]
설정 변경 이력 및 재발 방지 체크 예정

이렇게 쓰면 “접속 안 됨”이라는 넓은 문제를 어디까지 확인했는지 쉽게 보여줄 수 있습니다.

---

13. 정리하면

ping이 된다고 웹 서비스가 정상인 것은 아닙니다.

운영 서버에서는 접속 장애를 아래 순서로 나눠서 보는 것이 좋습니다.

1. ping으로 기본 응답을 확인합니다.
2. nc로 TCP 포트 연결 여부를 확인합니다.
3. curl로 HTTP 응답 코드를 확인합니다.
4. nslookup 또는 dig로 DNS 응답을 확인합니다.
5. 서버 내부에서 ss로 포트 listen 상태를 확인합니다.
6. systemctl status로 서비스 상태를 확인합니다.
7. journalctl로 최근 로그를 확인합니다.
8. 조치 후 같은 순서로 다시 확인합니다.

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

ping은 참고용이고, 실제 서비스 확인은 nc와 curl까지 봐야 합니다.

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

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

접속 장애를 전체 순서로 보고 싶다면 아래 글을 함께 보면 좋습니다.

https://opsnote.tistory.com/71

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

 

관련 명령어별 확인 방법은 아래 글들도 이어서 볼 수 있습니다.

https://opsnote.tistory.com/34

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

 

https://opsnote.tistory.com/36

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

 

https://opsnote.tistory.com/38

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

 

https://opsnote.tistory.com/39

리눅스 서버 도메인 안 된다고 서버부터 보지 말고 nslookup으로 DNS부터 확인하는 법

 

https://opsnote.tistory.com/40

리눅스 서버 nslookup만 보지 말고 dig로 DNS 응답까지 확인하는 법

 

https://opsnote.tistory.com/37

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

 

https://opsnote.tistory.com/27

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

 

https://opsnote.tistory.com/33

리눅스 서버 systemctl status만 보지 말고 journalctl로 서비스 로그 확인하는 법