01
502와 504는 프록시가 뒤쪽과 실패한 것입니다.
둘 다 Nginx · Caddy 같은 프록시가 뒤쪽 앱과 이야기하다 실패한 경우입니다. 502는 앱이 이상한 응답을 돌려줬거나 아예 받지 못한 것이고, 504는 제때 답이 오지 않은 것입니다. 두 경우 모두 프록시 설정보다 앱이 살아 있는지, 어느 포트를 듣고 있는지부터 봐야 합니다.
SERVER ERROR CLINIC
서버 오류 진단소
오류 코드는 무엇이 고장났는지가 아니라 어디까지 갔다가 실패했는지를 알려줍니다. 하나씩 답하면 확인할 곳이 줄어듭니다.
이 도구는 여러분의 서버에 접속하지 않습니다. 답한 내용만으로 확인할 순서를 정해주는 도구이며, 실제 로그를 대신하지 않습니다.
오류 코드는 어디까지 갔다가 실패했는지를 알려줍니다
- 브라우저요청을 보낸 곳
- 인터넷이름 찾기·연결
- 프록시Nginx·Caddy
- 앱Node·Spring·Django
- DB·외부 API앱이 부르는 곳
- 1증상을 고릅니다코드를 눌러도 되고 오류 메시지를 그대로 붙여넣어도 됩니다
- 2한 번에 한 가지만 답합니다명령 한 줄을 쳐보고 결과를 고르면 됩니다
- 3후보가 줄어듭니다남은 원인마다 확인할 명령과 그렇게 본 근거가 붙습니다
어떤 오류를 보고 계신가요?
이 도구에 대하여
코드는 실패한 지점을 알려줍니다
오류 코드는 무엇이 고장났는지가 아니라, 요청이 어디까지 갔다가 실패했는지를 알려줍니다. 그래서 코드만 봐도 어느 로그를 먼저 열지 정할 수 있습니다. 장애가 났을 때 가장 많이 낭비되는 시간이 어디부터 볼지 정하지 못한 채 여기저기 열어 보는 구간인데, 이 도구는 그 첫 선택을 대신 좁혀 줍니다. 원인을 찾아 주는 것이 아니라 확인할 순서를 정해 주는 도구라고 보는 편이 정확합니다.
- 보고 있는 오류 코드를 고르거나, 오류 메시지를 그대로 붙여넣습니다.
- 묻는 명령을 한 줄 실행하고 그 결과를 고릅니다.
- 답할수록 남은 원인이 줄고, 원인마다 확인할 명령과 그렇게 판단한 근거가 함께 붙습니다.
- 후보 목록이 줄어드는 과정을 보며 어떤 답이 가장 많이 걸러냈는지 확인합니다.
- 제시된 명령을 실제 서버에서 실행하고 결과를 다시 화면에 반영합니다.
- 마지막에 남은 원인과 그 근거를 함께 읽고 납득되는지 확인합니다.
- 다른 코드를 골라 같은 질문이 나오는지 비교해 봅니다.
- 즉시 실패와 지연 실패를 각각 골라 남는 후보가 어떻게 갈리는지 확인합니다.
- 연결 단계 오류 이름 네 가지가 각각 무엇을 뜻하는지 정리해 봅니다.
- 같은 코드라도 답에 따라 다른 원인에 도달할 수 있는지 두 번 해 봅니다.
코드를 나누는 기준
02
500과 503은 앱 쪽 이야기입니다.
500은 앱 안에서 예외가 나 요청을 끝내지 못한 것이라 앱 로그의 스택 트레이스가 답을 가지고 있습니다. 503은 앱이 지금 요청을 받을 준비가 되지 않았다는 뜻이라 기동 중이거나 과부하 · 점검 상태를 의심합니다.
03
한 번에 하나씩만 바꿉니다.
여러 곳을 동시에 손대면 무엇이 문제를 고쳤는지 알 수 없습니다. 이 도구는 답 하나에 후보를 하나씩 줄이는 순서를 유지해, 마지막에 무엇을 근거로 그 원인에 도달했는지 되짚을 수 있게 합니다.
04
코드는 계층을 가리킵니다.
요청은 프록시를 지나 앱에 닿습니다. 프록시가 앱과 이야기하다 실패했는지, 앱이 요청을 받았지만 처리에 실패했는지에 따라 돌려주는 코드가 달라집니다. 그래서 코드 하나만 알아도 로그를 열 순서가 정해지고, 아무 로그나 먼저 열어 보는 것보다 훨씬 빨리 좁힐 수 있습니다.
05
연결 단계의 오류는 이름이 다릅니다.
HTTP 상태 코드가 나오려면 최소한 응답이 돌아와야 합니다. 아예 연결이 안 되면 그 전 단계에서 실패한 것이라 다른 이름의 오류가 뜹니다. 거절당한 것인지, 시간이 초과된 것인지, 이름을 못 찾은 것인지, 포트가 이미 쓰이고 있는지가 각각 다른 원인을 가리키므로 이 도구도 그 이름들을 함께 다룹니다.
06
즉시와 지연이 원인을 가릅니다.
같은 접속 실패라도 곧바로 실패하는 것과 한참 기다리다 실패하는 것은 원인이 다릅니다. 즉시 거절은 상대가 그 자리에 없다는 답을 돌려준 것이고, 오래 걸리는 실패는 중간에서 조용히 버려져 답 자체가 오지 않는 상황입니다. 이 도구가 시간을 묻는 질문을 두는 이유입니다.
07
근거를 함께 남깁니다.
각 후보가 왜 남았고 왜 빠졌는지를 화면에 적어 둡니다. 결론만 제시하면 그것이 맞는지 사람이 판단할 수 없고, 틀렸을 때 어디서 어긋났는지도 찾을 수 없습니다. 진단 도구의 출력은 답보다 근거가 중요하다고 봤습니다.
08
메시지를 그대로 붙여 넣을 수 있습니다.
코드를 고르는 대신 오류 메시지를 그대로 붙여 넣어도 됩니다. 실제 상황에서는 코드가 무엇인지 파악하기 전에 메시지 덩어리부터 손에 들어오기 때문입니다. 화면이 그 안에서 알아볼 수 있는 표시를 찾아 시작 지점을 잡아 줍니다.
09
질문이 코드마다 달라집니다.
모든 코드에 같은 질문을 던지면 대부분이 의미 없는 확인이 됩니다. 그래서 코드에 따라 남아 있는 후보가 다르고, 그 후보들을 가장 잘 가르는 질문이 먼저 나오도록 순서를 잡았습니다. 답 하나로 절반씩 줄어드는 것이 이상적인 진단 순서입니다.
10
확인 명령을 함께 줍니다.
무엇을 의심하라는 말만으로는 다음 행동으로 이어지지 않습니다. 그래서 각 후보마다 실제로 실행해 볼 수 있는 한 줄을 붙여 두었습니다. 프로세스가 살아 있는지, 어느 포트를 듣고 있는지, 그 포트로 연결이 되는지를 확인하는 명령들이며 순서대로 실행하면 후보가 줄어듭니다. 다만 환경마다 명령이 조금씩 다르므로 그대로 되지 않으면 같은 목적의 다른 명령을 찾아 써야 합니다.
서버에 접속하지 않습니다.
이 도구는 여러분의 서버나 네트워크에 전혀 접속하지 않습니다. 화면에서 답한 내용만으로 확인할 순서를 정해주는 것이라, 실제 로그와 모니터링을 대신하지 않습니다. 다루는 코드는 HTTP 502 · 504 · 500 · 503과 ECONNREFUSED · ETIMEDOUT · EADDRINUSE · ENOTFOUND이며, 실제 원인은 프록시 설정, 컨테이너 구성, 방화벽 규칙에 따라 달라질 수 있습니다. 이 도구가 제시하는 순서는 흔한 경우를 기준으로 한 것이라 드문 원인은 목록에 없을 수 있고, 여러 원인이 겹쳐 있으면 하나를 고쳐도 증상이 남습니다. 최종 판단은 실제 로그와 모니터링 지표로 해야 하며, 화면에 나오는 명령도 환경에 맞게 고쳐 써야 합니다.
실험을 마쳤다면