ERR_CONNECTION_REFUSED

이 오류의 의미와 확인 방법

• Chrome, Edge 또는 다른 Chromium 기반 브라우저에 “이 사이트에 연결할 수 없습니다 — ERR_CONNECTION_REFUSED”가 표시됩니다.
• 긴 대기 후가 아니라 오류가 빠르게 나타납니다. 긴 지연은 ERR_CONNECTION_TIMED_OUT 같은 timeout에 더 가깝습니다.
• 이전에 작동하던 사이트가 서버 재시작, 배포, DNS 변경, 구성 업데이트 또는 방화벽 변경 후 작동하지 않습니다.
• 같은 컴퓨터의 SSH 또는 다른 애플리케이션 포트는 계속 연결되지만 웹 포트는 연결을 거부할 수 있습니다.
• 서비스가 localhost에서만 리스닝하거나 외부 방화벽이 포트를 차단하면 서버에서 보낸 요청은 성공하지만 외부에서 보낸 요청은 실패할 수 있습니다.

가능성이 높은 순서의 주요 원인

1. 웹 서버 또는 애플리케이션 프로세스가 중지됨 — Nginx, Apache 또는 애플리케이션 서버가 중단되었거나 중지되었거나 시작 과정에서 실패했을 수 있습니다.
2. 요청된 포트에서 리스닝 중인 항목이 없음 — 서비스가 다른 포트를 사용하지만 요청은 80 또는 443으로 전송되고 있을 수 있습니다.
3. 서비스가 잘못된 인터페이스에 바인딩됨 — 127.0.0.1에서 리스닝하면 로컬 요청은 수락하지만 직접적인 외부 연결은 수락하지 않습니다.
4. 호스트 또는 클라우드 방화벽이 트래픽을 거부함 — 운영 체제 방화벽, security group, network ACL 또는 제공업체 방화벽이 변경되었을 수 있습니다.
5. DNS가 잘못된 대상으로 연결됨 — 도메인이 오래된 서버, 재구축된 서버 또는 구성되지 않은 서버로 해석될 수 있습니다. AAAA 레코드로 인해 일부 방문자가 정상적인 웹 리스너가 없는 IPv6 주소로 연결될 수도 있습니다.

해결 방법

1. 대상 주소 확인

도메인의 A 및 AAAA 레코드를 확인하고, 해석된 주소를 요청을 받아야 하는 서버와 비교하세요. 도메인이 오래되었거나 폐기된 서버 또는 새로 재구축되었지만 아직 구성되지 않은 서버를 가리킨다면 웹 서비스 구성을 변경하기 전에 DNS를 수정하세요. IPv4와 IPv6 레코드가 모두 존재하는 경우 서비스와 방화벽이 두 경로를 모두 지원하는지 확인하세요.

2. 서비스 실행 여부 확인

SSH와 같은 승인된 관리 방법을 사용하여 관련 서비스를 확인하세요. 예를 들어 systemctl status nginx로 Nginx 상태를 확인하고, Apache 또는 애플리케이션 서버에는 해당 서비스 이름을 사용하세요.

서비스가 중지되었거나 실패한 경우 시작하기 전에 상태와 로그를 검토하세요. 최근 변경으로 발생한 구성 오류는 시작 실패의 일반적인 원인입니다. Nginx는 nginx -t, Apache는 apachectl configtest로 구성을 검증하세요. 테스트가 통과하고 서비스를 변경할 권한이 있는 경우에만 재시작하거나 reload하세요. 재시작은 활성 요청을 중단할 수 있으므로 운영 환경의 트래픽이 많은 시간에는 적절하지 않을 수 있습니다.

3. 리스닝 포트와 인터페이스 확인

서버에서 ss -tlnp 또는 해당 플랫폼의 동등한 명령으로 리스너를 확인하세요. 예상 프로세스가 요청된 포트에서 리스닝 중인지 확인하세요. 일반적으로 :80 또는 :443입니다.

포트뿐 아니라 바인드 주소도 확인하세요.

• 0.0.0.0:80 또는 0.0.0.0:443은 일반적으로 사용 가능한 IPv4 인터페이스에서 리스닝합니다.
• 특정 서버 주소가 표시되면 서비스가 해당 인터페이스에 바인딩된 것입니다.
• 127.0.0.1:80 또는 127.0.0.1:443은 로컬 요청만 수락합니다.

애플리케이션이 의도적으로 localhost에서만 비공개로 실행되는 경우, 외부에 공개되는 reverse proxy가 실행 중이며 애플리케이션으로 요청을 전달하는지 확인하세요. 그렇지 않다면 승인된 유지보수 또는 배포 변경 과정에서 서비스 구성을 조정하여 의도한 인터페이스에서 리스닝하도록 하세요.

4. 호스트 및 클라우드 방화벽 규칙 확인

ufw status, iptables -L 또는 운영 체제에 해당하는 명령으로 서버 방화벽을 검토하세요. 그런 다음 예상 서버에 연결된 cloud security group, network ACL 또는 제공업체 방화벽을 확인하세요.

필요한 포트로 들어오는 트래픽이 적절한 출발지에서 허용되는지 확인하세요. 공개 웹사이트에는 인터넷 액세스가 필요할 수 있지만 내부 서비스에는 승인된 더 좁은 범위를 사용해야 합니다. 두 레코드 유형이 모두 게시된 경우 IPv4 및 IPv6 규칙을 별도로 확인하세요. 필요한 범위를 넘어 액세스를 확대하지 말고, 승인된 경우에만 방화벽을 변경하세요.

5. 로컬 및 외부에서 테스트

서버에서 로컬 리스너와 구성된 호스트명을 별도로 테스트하세요. 로컬에서 성공했다는 것은 해당 컴퓨터에서 무언가가 응답한다는 것만 확인할 뿐, 외부 클라이언트가 포트에 연결할 수 있다는 의미는 아닙니다.

DNS, 서비스, 바인딩 또는 방화벽을 수정한 후 다른 네트워크나 외부 컴퓨터에서 영향을 받은 호스트명을 대상으로 상세한 curl -v 요청을 실행하세요. 요청이 예상 주소와 포트에 도달하는지, 연결 거부가 해소되었는지 확인하세요.

6. 최근 변경 사항 비교

배포, 재시작, 서버 재구축, DNS 업데이트 또는 방화벽 변경 후 문제가 시작되었다면 현재 구성을 마지막으로 정상 작동한 버전과 비교하세요. 변경된 포트, 실패한 서비스 시작, localhost 전용 바인딩, 잘못된 서버에 연결된 규칙 또는 불완전한 IPv6 구성을 중점적으로 확인하세요.

예방 및 해결 확인 방법

• service manager 또는 process supervisor를 사용하여 예기치 않은 장애 후 웹 서비스가 복구되도록 하세요.
• reload 또는 restart 전에 nginx -t 또는 apachectl configtest 같은 구성 검증을 필수 배포 검사로 지정하세요.
• 의도한 포트, 바인드 주소, 방화벽 규칙, security group 및 DNS 레코드를 정상 상태의 기준으로 문서화하세요.
• 로컬 health check에만 의존하지 말고 서버 외부에서 서비스를 모니터링하세요.
• 도메인에 A 및 AAAA 레코드가 모두 있는 경우 IPv4 및 IPv6 리스너와 방화벽 규칙을 함께 검토하세요.
• 인프라 변경 사항을 기록하여 새로운 연결 거부가 배포, 재구축, DNS 업데이트 또는 방화벽 변경과 관련 있는지 확인할 수 있도록 하세요.

자주 묻는 질문