ERR_CONNECTION_REFUSED 해결 가이드

Problem

페이지가 거의 즉시 ERR_CONNECTION_REFUSED(또는 “사이트에 연결할 수 없음”)로 실패합니다. 호스트에는 닿고 보낸 SYN에 응답도 했지만, SYN/ACK가 아니라 TCP RST로 응답한 상태입니다. 반대편의 무언가가 능동적으로 거절하고 있는 것입니다. 멈춤이 없다는 점 자체가 진단 신호입니다. 조용히 버려진 패킷이 아니라 거부입니다.

Symptoms

• 1~2분 대기 없이 오류가 즉시 나타납니다.
• curl이 Connection refused를 출력하고, 요청이 아예 시작되지 않습니다.
• 서버 자체에서는(curl localhost) 열리는데 다른 모든 클라이언트는 거부될 수 있습니다.
• 오류가 ERR_CONNECTION_TIMED_OUT(긴 멈춤)이나 ERR_NAME_NOT_RESOLVED(DNS 미해결)가 아닙니다.

Top 3 Causes

1. 해당 포트에서 아무것도 수신하지 않음 - 서비스가 죽었거나, 시작된 적이 없거나, URL이 가리키는 포트와 다른 포트에 바인딩되어 있습니다(앱은 8080인데 브라우저는 443으로 접속). 그 포트에 LISTEN 상태의 소켓이 없으면 커널은 RFC 9293이 닫힌 포트에 대해 규정한 대로 SYN에 RST로 응답합니다.
2. 서비스가 loopback에만 바인딩됨 - 0.0.0.0이 아니라 127.0.0.1에서 수신하고 있어서, 호스트에서 시작된 요청에는 응답하고 공용 인터페이스로 들어오는 연결은 모두 거부합니다. “로컬에서는 되는데 원격에서는 거부”의 전형적인 원인입니다.
3. 방화벽이 능동적으로 거부함 - REJECT 규칙, 또는 ICMP port-unreachable을 반환하는 프록시가 즉시 거절을 보냅니다. 패킷을 삼켜 타임아웃을 만드는 DROP 규칙과 정반대입니다.

Diagnose with DechoNet

• Port Check로 대상 포트를 외부 네트워크에서 점검합니다. 닫힘(거부)으로 나오면 브라우저가 보는 현상과 같아 아무것도 수신하지 않거나 reject 규칙이 경로에 있다는 뜻이고, 열림으로 나오면 프로세스는 수신 중이며 문제는 더 위 계층에 있습니다.
• HTTP Check로 외부 관점에서 요청을 시도해, 거부가 전역적인지 내 네트워크에 국한된 것인지 확인합니다.
• DNS Lookup으로 A/AAAA 레코드가 더 이상 아무것도 수신하지 않는 이전 IP가 아니라 서비스가 실제로 도는 호스트를 가리키는지 확인합니다.

포트가 거부가 아니라 멈췄다가 타임아웃되면 ERR_CONNECTION_TIMED_OUT 해결로 넘어갑니다. 거부가 특히 443 포트에서 발생하면 443 포트 닫힘 체크리스트를 사용하세요.

Resolution Checklist

• 서비스 프로세스가 실행 중이고 기대한 포트에서 LISTEN 상태인지 확인합니다(ss -lntp 또는 netstat -lntp).
• bind 주소를 확인합니다. 0.0.0.0(모든 인터페이스)인지 127.0.0.1(loopback 전용)인지. loopback 전용은 “로컬에서는 되는데 원격에서는 거부”의 흔한 원인입니다.
• URL의 포트가 서비스가 수신하는 포트와 일치하는지 확인합니다. HTTPS는 443, HTTP는 80, 또는 명시적 :port.
• REJECT 방화벽 규칙, 또는 업스트림이 죽어 거부로 응답하는 리버스 프록시가 있는지 살펴봅니다.
• DNS가 이전 배포에 남은 주소가 아니라 서비스가 실제로 도는 호스트로 해석되는지 확인합니다.
• 변경할 때마다 Port Check를 다시 실행해 핸드셰이크가 완료되는지 확인합니다.

When to Escalate

• 프로세스는 호스트에서 정상으로 보이는데 여러 외부 네트워크에서 포트가 거부된다면, 네트워크가 아니라 bind 주소나 프록시 설정 문제일 가능성이 높으니 서비스 담당자에게 에스컬레이션합니다.
• 허용되어야 할 소스 범위를 REJECT 규칙이 거부하고 있다면 방화벽/네트워크 담당자에게 문의합니다.