SERVER ERROR CLINIC
연결 시도가 능동적으로 거절됐습니다. 수신 프로세스가 없거나 다른 주소에 바인딩된 경우가 흔하고, 방화벽의 REJECT 규칙도 같은 결과를 만들 수 있습니다.
이 도구는 여러분의 서버에 접속하지 않습니다. 답한 내용만으로 확인할 순서를 정해주는 도구이며, 실제 로그를 대신하지 않습니다.
어느 로그를 볼까 받는 쪽의 수신 프로세스와 바인딩 주소·포트를 먼저 보고, 정상이면 호스트·클라우드 방화벽의 REJECT 규칙을 확인합니다.
원인 후보 3개
포트를 이미 잡고 있는 주인을 찾으면 원인이 바로 갈립니다.
서버에서 이 명령을 쳐보고, 아래에서 결과를 골라 주세요.
ss -ltnp | grep :3000가장 먼저 확인할 것
그 포트에 수신 프로세스가 없으면 운영체제가 연결을 즉시 거절합니다. 가장 흔한 원인이지만 능동적인 방화벽 REJECT도 같은 증상을 만들 수 있습니다.
다른 후보가 하나씩 제외되면서 남은 원인입니다.
그 포트를 듣고 있는 프로세스가 있는지 봅니다.
ss -ltnp | grep :3000그다음 먼저 띄우고, 곧바로 죽는다면 시작 로그를 봅니다. 여기서도 원인은 대개 설정값 누락입니다.
연결이 어떻게 맺어지는지 보기 →아니라면 다음
앱이 자기 컴퓨터 안에서만 받도록 열려 있습니다. 서버 안에서 부르면 되는데 다른 컨테이너나 다른 서버에서는 거부됩니다.
127.0.0.1로 열려 있는지 0.0.0.0으로 열려 있는지 확인합니다.
ss -ltn | grep :3000그다음 127.0.0.1로 열려 있으면 밖에서 닿지 않습니다. 0.0.0.0으로 여는 대신, 도커라면 컨테이너 이름으로 부르는 쪽이 안전합니다.
어느 주소로 나가는지 보기 →아니라면 다음
부르는 쪽과 받는 쪽이 서로 다른 번호를 보고 있습니다. 환경변수가 비어서 기본값으로 떨어진 경우가 흔합니다.
지금 열려 있는 포트 전체를 훑어 앱이 어디 있는지 찾습니다.
ss -ltnp | head -20그다음 부르는 쪽의 설정값과 실제로 열린 포트를 눈으로 맞춰봅니다. 둘 다 출력해 보는 게 가장 빠릅니다.
실험을 마쳤다면