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

리눅스 서버 접속 장애가 발생했을 때 ping, nc, curl, traceroute, nslookup, dig, systemctl, journalctl을 순서대로 확인하는 방법을 설명하는 대표 이미지

리눅스 서버를 운영하다 보면 가장 자주 듣는 말 중 하나가 있습니다.

접속이 안 됩니다.
사이트가 안 열립니다.
서버가 죽은 것 같습니다.
도메인이 안 됩니다.
포트가 막힌 것 같습니다.

 

처음 들으면 마음이 급해집니다.

서버에 바로 접속해보고, ping을 날려보고, 방화벽부터 떠올리게 됩니다.
하지만 접속 장애는 생각보다 원인이 다양합니다.

서버 자체가 죽은 것일 수도 있고, 서비스 프로세스가 내려간 것일 수도 있습니다.
포트는 열려 있는데 HTTP 응답이 이상할 수도 있고, DNS가 다른 IP를 바라보고 있을 수도 있습니다.
중간 네트워크 구간에서 막힌 것처럼 보여도 실제로는 특정 장비가 응답을 제한하는 경우도 있습니다.

그래서 접속 장애는 한 가지 명령어만 보고 판단하면 위험합니다.

이 글에서는 리눅스 서버에서 접속 장애가 발생했을 때 ping, nc, curl, traceroute, nslookup, dig, systemctl, journalctl을 어떤 순서로 확인하면 좋은지 정리해보겠습니다.

접속 장애에서 가장 먼저 해야 할 일

접속이 안 된다고 바로 방화벽이나 서버 장애로 단정하면 안 됩니다.

먼저 “접속이 안 된다”는 말을 더 작게 나눠야 합니다.

서버 IP로 접근이 안 되는지
도메인으로만 접근이 안 되는지
SSH 접속이 안 되는지
웹 서비스만 안 되는지
특정 포트만 안 되는지
특정 URL만 안 되는지
내부망에서는 되고 외부망에서는 안 되는지
일부 사용자만 안 되는지
전체 사용자가 안 되는지

 

이걸 나누지 않으면 확인 순서가 꼬입니다.

예를 들어 도메인 문제인데 서버만 계속 보고 있을 수 있습니다.
반대로 서비스 프로세스 문제인데 방화벽만 계속 볼 수도 있습니다.

초보 운영자라면 먼저 이렇게 정리하는 것이 좋습니다.

현상:
웹 페이지 접속 불가

접속 대상:
https://example.com

확인 범위:
도메인 응답, 서버 접근, 포트 오픈 여부, HTTP 응답, 서비스 상태, 로그

주의할 점:
ping 결과만으로 서비스 정상 여부를 판단하지 않음

 

이렇게 적어두면 접속 장애 대응이 훨씬 차분해집니다.

접속 장애 확인 순서

접속 장애가 발생했을 때는 아래 순서로 보는 것이 좋습니다.

1. 접속 대상 구분
2. ping으로 기본 네트워크 응답 확인
3. nc로 포트 오픈 여부 확인
4. curl로 HTTP 응답 확인
5. systemctl로 서비스 상태 확인
6. journalctl로 서비스 로그 확인
7. traceroute로 경로 확인
8. nslookup으로 도메인 IP 확인
9. dig로 DNS 응답 상세 확인
10. 최근 변경 사항 확인
11. 조치 전 영향도 판단
12. 조치 후 재확인

 

여기서 중요한 건 순서입니다.

ping이 안 된다고 바로 방화벽 문제로 결론 내리면 안 되고, ping이 된다고 서비스가 정상이라고 봐도 안 됩니다.

접속 장애도 결국 아래 흐름으로 움직이는 게 안전합니다.

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

 

1. 먼저 IP 접속 문제인지 도메인 문제인지 나눕니다

접속 장애를 볼 때 가장 먼저 나눌 것은 이것입니다.

IP로도 안 되는가?
도메인으로만 안 되는가?

 

예를 들어 아래처럼 확인할 수 있습니다.

 

curl -I http://192.0.2.10
curl -I https://example.com

 

IP로는 접속되는데 도메인으로 안 된다면 DNS, 인증서, 가상호스트, 리버스 프록시 설정 쪽을 봐야 할 수 있습니다.

반대로 IP로도 접속이 안 된다면 서버 접근, 포트, 방화벽, 라우팅, 서비스 상태를 먼저 확인하는 쪽이 자연스럽습니다.

초반에 이걸 나누지 않으면 괜히 먼 길을 돌게 됩니다.

도메인 문제인데 서버 재기동 고민
서비스 문제인데 DNS만 계속 확인
포트 문제인데 ping만 반복 확인

 

접속 장애에서는 “어디까지 되는지”를 먼저 그려야 합니다.

2. ping은 기본 연결 확인용입니다

많이 사용하는 첫 번째 명령어는 ping입니다.

 

ping 192.0.2.10

 

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

 

ping example.com

 

ping은 대상까지 ICMP 응답이 오는지 확인하는 도구입니다.

다만 여기서 바로 결론을 내리면 안 됩니다.

ping이 된다고 웹 서비스가 정상이라는 뜻은 아닙니다.
반대로 ping이 안 된다고 서버가 반드시 죽었다는 뜻도 아닙니다.

일부 서버나 보안 장비는 ICMP 응답을 막아둘 수 있습니다.

초보 운영자 기준으로는 이렇게 기억하면 좋습니다.

ping 성공
→ 서버 또는 경로가 ICMP에는 응답함
→ 서비스 포트 정상 여부는 별도 확인 필요

ping 실패
→ 서버 장애일 수도 있지만 ICMP 차단일 수도 있음
→ 포트, 경로, DNS를 함께 확인 필요

 

ping은 되는데 서비스 접속이 안 되는 경우는 아래 글에서 따로 정리했습니다.

https://opsnote.tistory.com/34

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

 

ping이 안 될 때도 바로 방화벽 문제로 단정하지 않는 흐름은 아래 글과 이어서 보면 좋습니다.

https://opsnote.tistory.com/35

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

 

3. 포트가 열려 있는지는 nc로 확인합니다

웹 서비스나 애플리케이션은 결국 특정 포트로 접속합니다.

예를 들어 웹 서비스라면 보통 80, 443 포트를 봅니다.

 

nc -vz 192.0.2.10 80
nc -vz 192.0.2.10 443

 

결과가 성공하면 해당 IP와 포트로 TCP 연결이 가능하다는 뜻입니다.

Connection to 192.0.2.10 443 port [tcp/https] succeeded!

 

실패하면 포트가 닫혀 있거나, 중간에서 차단되었거나, 서비스가 해당 포트를 listen하지 않을 수 있습니다.

Connection refused
Connection timed out
No route to host

 

여기서도 메시지를 나눠서 봐야 합니다.

Connection refused
→ 대상까지는 갔지만 해당 포트에서 받는 서비스가 없을 가능성

Connection timed out
→ 중간 방화벽, 네트워크 차단, 응답 지연 가능성

No route to host
→ 라우팅 또는 네트워크 경로 문제 가능성

 

포트 확인은 ping보다 서비스 접근에 한 걸음 더 가깝습니다.

nc로 포트가 열려 있는지 확인하는 방법은 아래 글에서 정리했습니다.

https://opsnote.tistory.com/36

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

 

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

포트가 열려 있어도 웹 서비스가 정상이라는 뜻은 아닙니다.

포트는 열려 있는데 404, 500, 502, 503 같은 응답이 나올 수 있습니다.
이때는 curl로 HTTP 응답을 확인합니다.

 

curl -I https://example.com

 

예를 들어 이런 결과를 볼 수 있습니다.

HTTP/1.1 200 OK

 

또는 이런 결과가 나올 수도 있습니다.

HTTP/1.1 502 Bad Gateway
HTTP/1.1 503 Service Unavailable
HTTP/1.1 504 Gateway Timeout

 

curl은 단순히 포트가 열렸는지가 아니라, 웹 서버나 애플리케이션이 어떤 HTTP 응답을 주는지 확인하는 데 좋습니다.

그래서 nc와 curl은 역할이 다릅니다.

nc
→ 포트 연결 가능 여부 확인

curl
→ HTTP 응답 상태 확인

 

둘을 구분하지 않으면 “포트는 열려 있는데 왜 안 되지?”에서 멈추기 쉽습니다.

curl과 nc 차이는 아래 글에서 자세히 정리했습니다.

https://opsnote.tistory.com/38

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

 

5. 서비스가 떠 있는지 systemctl로 확인합니다

포트가 닫혀 있거나 HTTP 응답이 이상하다면 서버 안에서 서비스 상태를 봐야 합니다.

예를 들어 nginx 상태를 확인합니다.

 

systemctl status nginx --no-pager

 

Apache라면 아래처럼 볼 수 있습니다.

 

systemctl status httpd --no-pager

 

Tomcat이나 애플리케이션 서비스라면 환경에 맞는 서비스명을 확인해야 합니다.

 

systemctl status tomcat --no-pager

 

여기서 볼 것은 단순히 active인지 아닌지만이 아닙니다.

Active 상태
Main PID
최근 에러 메시지
실패 코드
서비스 시작 시각
마지막 로그 일부

 

예를 들어 서비스가 내려가 있다면 포트가 닫혀 있을 수 있습니다.

반대로 서비스는 떠 있는데 HTTP 502가 난다면, 웹 서버 뒤쪽 upstream이나 애플리케이션 연결 문제일 수 있습니다.

서비스가 안 뜰 때 systemctl status부터 확인하는 흐름은 아래 글에서 정리했습니다.

https://opsnote.tistory.com/27

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

 

실패한 서비스가 여러 개 있는지 보고 싶다면 아래 명령어도 도움이 됩니다.

 

systemctl --failed

 

관련 내용은 아래 글과 연결됩니다.

https://opsnote.tistory.com/32

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

 

6. journalctl로 서비스 로그를 확인합니다

서비스 상태를 봤다면 로그를 같이 확인해야 합니다.

 

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

 

커널 메시지가 의심될 때는 아래처럼 볼 수도 있습니다.

 

journalctl -k -n 100 --no-pager

 

로그에서는 이런 키워드를 봅니다.

error
failed
timeout
permission denied
connection refused
address already in use
no space left on device
upstream
bind

 

접속 장애는 네트워크 문제처럼 보여도 실제로는 서비스 내부 문제일 수 있습니다.

예를 들어 이런 경우입니다.

설정 파일 오류로 서비스 기동 실패
포트 충돌로 bind 실패
인증서 경로 오류
로그 디렉터리 권한 문제
디스크 용량 부족으로 서비스 오류
upstream 애플리케이션 장애

 

그래서 ping, nc, curl만 보고 끝내지 말고 서비스 로그까지 봐야 합니다.

journalctl로 서비스 로그를 확인하는 방법은 아래 글에서 정리했습니다.

https://opsnote.tistory.com/33

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

 

7. 경로 문제는 traceroute로 봅니다

접속이 안 될 때 서버 자체 문제인지, 중간 네트워크 구간 문제인지 헷갈릴 수 있습니다.

이때는 traceroute를 사용합니다.

 

traceroute example.com

 

환경에 따라 tracepath를 사용할 수도 있습니다.

 

tracepath example.com

 

다만 traceroute 결과도 조심해서 봐야 합니다.

중간에서 별표가 보인다고 해서 그 장비가 무조건 장애라는 뜻은 아닙니다.

* * *

 

일부 네트워크 장비는 traceroute나 ICMP 응답을 제한할 수 있습니다.
그래서 traceroute는 단독 판단용이 아니라 경로를 추정하는 참고 자료로 보는 것이 좋습니다.

예를 들어 아래 결과를 같이 봐야 합니다.

ping 결과
nc 포트 확인 결과
curl HTTP 응답 결과
DNS 응답 결과
traceroute 경로

 

traceroute로 어느 구간에서 막히는지 확인하는 흐름은 아래 글에서 정리했습니다.

https://opsnote.tistory.com/37

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

 

8. 도메인 문제는 nslookup으로 먼저 확인합니다

도메인으로 접속이 안 될 때는 서버만 보면 안 됩니다.

먼저 도메인이 어떤 IP를 바라보는지 확인합니다.

 

nslookup example.com

 

예를 들어 도메인이 예상한 IP를 바라보지 않는다면, 서버가 정상이어도 접속 장애처럼 보일 수 있습니다.

확인할 것은 아래입니다.

도메인이 IP를 정상적으로 응답하는지
예상한 IP와 일치하는지
내부 DNS와 외부 DNS 응답이 다른지
CNAME이 다른 곳을 바라보는지
DNS 변경 직후 TTL 영향은 없는지

 

운영 환경에서는 내부망과 외부망의 DNS 응답이 다를 수 있습니다.

예를 들어 내부에서는 사설 IP를 바라보고, 외부에서는 공인 IP나 로드밸런서 주소를 바라볼 수 있습니다.

그래서 가능하면 확인 위치도 같이 적는 것이 좋습니다.

내부 서버에서 조회한 결과인지
사용자 PC에서 조회한 결과인지
외부망에서 조회한 결과인지
특정 DNS 서버로 조회한 결과인지

 

도메인 접속 장애에서 nslookup을 먼저 보는 흐름은 아래 글과 이어집니다.

https://opsnote.tistory.com/39

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

 

9. DNS 응답을 더 자세히 보려면 dig를 사용합니다

nslookup으로 기본 확인을 했다면, 더 자세한 DNS 응답은 dig로 볼 수 있습니다.

 

dig example.com

 

A 레코드를 직접 확인할 수도 있습니다.

 

dig A example.com

 

CNAME을 확인할 수도 있습니다.

 

dig CNAME example.com

 

특정 DNS 서버를 지정해서 조회할 수도 있습니다.

 

dig @8.8.8.8 example.com

 

dig에서는 이런 부분을 봅니다.

ANSWER SECTION
응답 IP
CNAME 흐름
TTL
조회한 DNS 서버
응답 시간

 

DNS 변경 직후라면 TTL 때문에 어떤 곳에서는 새 IP가 보이고, 어떤 곳에서는 예전 IP가 보일 수 있습니다.

이런 경우 서버가 문제가 아니라 DNS 반영 시점 차이일 수 있습니다.

dig로 DNS 응답을 자세히 확인하는 방법은 아래 글에서 정리했습니다.

https://opsnote.tistory.com/40

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

 

10. 접속 장애와 서버 리소스도 같이 봅니다

접속 장애라고 해서 항상 네트워크만 보는 것은 아닙니다.

서버가 너무 느리거나, 디스크가 꽉 찼거나, 애플리케이션이 응답하지 못하는 상태라면 접속 장애처럼 보일 수 있습니다.

기본 리소스도 같이 확인합니다.

 

uptime
top
free -m
df -h

 

예를 들어 이런 상황이 있을 수 있습니다.

Load Average가 높아서 응답 지연
wa 값이 높아서 디스크 I/O 대기
메모리 부족으로 서비스 응답 지연
디스크 용량 부족으로 로그 기록 실패
서비스가 떠 있지만 요청 처리가 밀림

 

서버가 느린데 CPU만 보고 정상이라고 판단하면 안 됩니다.

Load Average 확인 흐름은 아래 글에서 정리했습니다.

https://opsnote.tistory.com/41

리눅스 서버 CPU 낮다고 정상이라 하지 말고 Load Average까지 확인하는 법

 

top에서 wa 값을 보는 흐름은 아래 글과 이어서 보면 좋습니다.

https://opsnote.tistory.com/42

리눅스 서버 CPU 낮다고 정상이라 하지 말고 top wa 값까지 확인하는 법

 

디스크 용량 문제가 접속 장애로 이어질 수도 있기 때문에, 디스크 확인도 같이 봐야 합니다.

https://opsnote.tistory.com/70

리눅스 서버 디스크 용량 문제 확인 순서 총정리

 

11. 최근 변경 사항을 확인합니다

접속 장애는 변경 작업 뒤에 나타나는 경우가 많습니다.

아래 항목을 꼭 확인합니다.

방화벽 정책 변경
보안그룹 변경
DNS 변경
인증서 교체
웹 서버 설정 변경
로드밸런서 설정 변경
Ingress 설정 변경
애플리케이션 배포
서비스 재기동
포트 변경
서버 IP 변경

 

특히 이런 상황은 흔합니다.

DNS는 바꿨는데 일부 사용자만 이전 IP를 바라봄
방화벽 정책 변경 후 특정 포트만 차단됨
서비스 포트가 변경됐는데 LB 설정은 예전 포트를 바라봄
인증서 교체 후 HTTPS 접속 오류 발생
배포 후 애플리케이션 포트가 열리지 않음

 

명령어 결과가 애매할수록 최근 변경 사항을 같이 봐야 합니다.

운영에서는 “지금 안 된다”만 보는 것보다 “언제부터, 무엇이 바뀐 뒤부터 안 되는지”가 훨씬 중요합니다.

12. 바로 재기동하기 전에 확인할 것

접속이 안 되면 재기동을 떠올리기 쉽습니다.

하지만 재기동은 마지막에 가까운 카드입니다.

서비스 재기동 전에는 최소한 아래를 봐야 합니다.

서비스 상태를 확인했는지
최근 로그를 확보했는지
포트가 실제로 닫혀 있는지
설정 파일 오류는 없는지
디스크나 메모리 문제는 없는지
재기동 영향 범위는 확인했는지
재기동 후 자동 기동 여부는 확인했는지

 

서비스 재기동은 아래처럼 할 수 있습니다.

 

systemctl restart nginx

 

하지만 운영 서버에서는 명령어를 아는 것보다, 지금 이 조치를 해도 되는지 판단하는 것이 더 중요합니다.

서버 전체 재기동은 더 조심해야 합니다.

 

reboot

 

재기동 전 체크리스트는 아래 글과 함께 보면 좋습니다.

https://opsnote.tistory.com/19

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

 

13. 조치 후에는 같은 경로로 다시 확인합니다

조치를 했다면 끝이 아닙니다.

반드시 다시 확인해야 합니다.

 

systemctl status nginx --no-pager
journalctl -u nginx -n 100 --no-pager
nc -vz 192.0.2.10 443
curl -I https://example.com

 

DNS 문제였다면 다시 조회합니다.

 

nslookup example.com
dig example.com

 

네트워크 경로 문제였다면 다시 확인합니다.

 

traceroute example.com

 

운영에서는 “조치했습니다”보다 “조치 후 정상 확인했습니다”가 더 중요합니다.

예를 들어 이렇게 정리할 수 있습니다.

조치 후 확인 결과:
서비스 상태 active 확인
443 포트 연결 성공
curl 기준 HTTP 200 응답 확인
최근 에러 로그 추가 발생 없음

 

이 정도까지 확인해야 대응이 마무리됩니다.

14. 실무에서 쓸 수 있는 보고 예시

접속 장애 상황에서는 보고도 중요합니다.

처음에는 짧게 정리하는 것이 좋습니다.

현상:
확인 내용:
원인 추정:
조치 내용:
현재 상태:
추가 확인 필요:

 

예를 들어 웹 접속 장애라면 이렇게 쓸 수 있습니다.

현상:
웹 서비스 접속 불가 문의가 접수되었습니다.

확인 내용:
서버 ping 응답은 확인되었으나, 443 포트 연결이 실패하는 상태입니다.
서비스 상태 및 방화벽 정책 변경 여부를 추가 확인 중입니다.

원인 추정:
현재까지는 웹 서비스 포트 미응답 또는 중간 방화벽 차단 가능성이 있습니다.

조치 내용:
서비스 상태와 최근 변경 사항을 확인하고 있습니다.

현재 상태:
서버 자체 접근은 가능하나 웹 서비스 접속은 정상 확인되지 않았습니다.

추가 확인 필요:
서비스 포트 listen 여부, 방화벽 정책, 로드밸런서 설정 확인이 필요합니다.

 

DNS가 의심된다면 이렇게 정리할 수 있습니다.

현상:
도메인 접속 시 일부 환경에서 접속 불가 현상이 확인되었습니다.

확인 내용:
nslookup 및 dig 조회 결과, 조회 위치에 따라 응답 IP가 다르게 확인됩니다.

원인 추정:
DNS 변경 후 TTL 또는 내부/외부 DNS 응답 차이 가능성이 있습니다.

조치 내용:
DNS 응답 경로와 실제 서비스 IP 일치 여부를 확인 중입니다.

현재 상태:
IP 직접 접속과 도메인 접속 결과를 분리하여 확인하고 있습니다.

 

서비스 장애가 의심된다면 이렇게 쓸 수 있습니다.

현상:
웹 서비스 접속 시 502 응답이 발생합니다.

확인 내용:
443 포트는 열려 있으나 curl 기준 502 응답이 확인되었습니다.
nginx 상태는 active이나 upstream 애플리케이션 연결 여부 확인이 필요합니다.

원인 추정:
웹 서버 자체보다는 뒷단 애플리케이션 또는 upstream 연결 문제 가능성이 있습니다.

조치 내용:
서비스 로그와 애플리케이션 프로세스 상태를 확인 중입니다.

 

이렇게 적으면 “접속 안 됩니다”보다 훨씬 실무적으로 보입니다.

접속 장애 빠른 확인 명령어 정리

상황별로 자주 쓰는 명령어를 정리하면 아래와 같습니다.

기본 네트워크 응답 확인

 

ping 192.0.2.10
ping example.com

 

포트 오픈 여부 확인

 

nc -vz 192.0.2.10 80
nc -vz 192.0.2.10 443

 

HTTP 응답 확인

 

curl -I http://example.com
curl -I https://example.com

 

서비스 상태 확인

 

systemctl status nginx --no-pager
systemctl --failed

 

서비스 로그 확인

 

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

 

네트워크 경로 확인

 

traceroute example.com
tracepath example.com

 

DNS 기본 확인

 

nslookup example.com

 

DNS 상세 확인

 

dig example.com
dig A example.com
dig CNAME example.com
dig @8.8.8.8 example.com

 

명령어를 한 번에 다 치는 것이 중요한 건 아닙니다.

순서가 중요합니다.

ping으로 기본 응답 확인
nc로 포트 확인
curl로 HTTP 응답 확인
systemctl과 journalctl로 서버 내부 확인
traceroute로 경로 확인
nslookup과 dig로 DNS 확인
최근 변경 사항과 영향도 확인

 

정리하면

리눅스 서버 접속 장애는 한 가지 원인으로만 생기지 않습니다.

서버가 내려간 것처럼 보여도 DNS 문제일 수 있고, 방화벽 문제처럼 보여도 서비스 프로세스 문제일 수 있습니다.
포트는 열려 있어도 HTTP 응답이 502일 수 있고, 도메인은 정상이어도 뒷단 애플리케이션이 응답하지 않을 수 있습니다.

초보 운영자라면 아래 순서를 기억하면 좋습니다.

접속 대상 구분
ping 확인
nc 포트 확인
curl HTTP 응답 확인
systemctl 서비스 상태 확인
journalctl 로그 확인
traceroute 경로 확인
nslookup, dig DNS 확인
최근 변경 사항 확인
조치 후 재확인

 

그리고 가장 중요한 문장은 이것입니다.

접속이 안 된다고 바로 방화벽이나 서버 장애로 단정하지 말고, 어디까지 되고 어디서부터 안 되는지 나눠서 확인해야 합니다.

운영 서버에서는 빠른 조치보다 정확한 구분이 먼저입니다.

접속 장애는 네트워크 문제처럼 보이지만, 실제로는 서비스 상태, DNS, 포트, HTTP 응답이 함께 얽혀 있는 경우가 많습니다.

전체적인 리눅스 서버 장애 대응 흐름을 먼저 보고 싶다면 아래 글을 함께 보면 좋습니다.
https://opsnote.tistory.com/69

초보 운영자를 위한 리눅스 서버 장애 대응 순서 총정리

 

디스크 용량 문제처럼 서버 내부 리소스 문제까지 함께 확인해야 하는 경우는 아래 글에서 따로 정리했습니다. https://opsnote.tistory.com/70

리눅스 서버 디스크 용량 문제 확인 순서 총정리

 

웹 장애 상황에서 400, 401, 403, 404, 500, 502, 503, 504 같은 HTTP 상태 코드를 구분해서 보고하는 방법은 아래 글을 참고하면 됩니다.
https://opsnote.tistory.com/64

리눅스 서버 웹 장애 보고할 때 HTTP 코드 정리하는 법, 한눈에 보이는 오류 보고 가이드