ERR_CONNECTION_TIMED_OUT

이 오류의 의미와 확인 방법

• 브라우저에 ERR_CONNECTION_TIMED_OUT과 함께 “이 사이트에 연결할 수 없습니다”와 같은 메시지가 표시됩니다.
• 오류가 즉시 발생하지 않고 눈에 띄게 기다린 후 나타납니다.
• 한 네트워크에서는 호스트 이름이 작동하지만 다른 네트워크에서는 타임아웃됩니다.
• 호스팅 콘솔에는 인스턴스가 실행 중으로 표시되더라도 서버의 공용 주소에 대한 요청이 타임아웃될 수 있습니다.
• 호스트, 네트워크 인터페이스, 경로 또는 업스트림 네트워크를 사용할 수 없으면 많은 방문자에게 문제가 발생합니다.
• CPU, 메모리, 프로세스 또는 연결 부하가 심한 서버는 전원이 켜진 상태로 남아 있어도 새 연결을 제때 완료하지 못할 수 있습니다.
• CDN, 리버스 프록시 또는 로드 밸런서에는 연결할 수 있지만, 오리진에 연결하는 과정에서 타임아웃이 발생할 수 있습니다.

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

1. 호스트 또는 네트워크 인터페이스에 연결할 수 없음 — 서버, VM, 네트워크 인터페이스, 경로 또는 업스트림 네트워크를 사용할 수 없을 수 있습니다.
2. 방화벽 또는 보안 그룹이 트래픽을 조용히 삭제함 — 삭제 규칙은 일반적으로 타임아웃을 유발하지만, 명시적인 거부는 대체로 더 빠르게 실패합니다.
3. 서버 과부하 — 리소스 고갈, 프로세스 제한 또는 너무 많은 열린 연결로 인해 TCP 핸드셰이크나 애플리케이션 응답이 완료되지 않을 수 있습니다.
4. DNS가 잘못된 대상으로 연결함 — 호스트 이름이 오래된 주소, 연결할 수 없는 주소 또는 더 이상 사이트를 제공하지 않는 인프라로 확인될 수 있습니다.
5. 방문자의 네트워크 경로에 문제가 있음 — ISP 라우팅 문제, VPN, 프록시, 로컬 방화벽 또는 필터링 장치가 특정 네트워크에서의 접근을 차단할 수 있습니다.
6. IPv6가 잘못 구성됨 — 사용할 수 없는 AAAA 레코드로 인해 IPv4 서비스가 작동하더라도 IPv6를 우선하는 네트워크에서 오류가 발생할 수 있습니다.
7. CDN, 리버스 프록시, 로드 밸런서 또는 업스트림 보호 계층이 잘못 구성됨 — 오리진 자체는 실행 중이어도 프런트엔드가 오리진에 연결하지 못할 수 있습니다.

해결 방법

1. 두 번째 네트워크에서 테스트

모바일 데이터 또는 관련 없는 다른 연결을 사용하여 사이트를 엽니다. VPN 또는 프록시가 활성화되어 있다면 허용되는 경우 이를 해제하고 테스트하세요.

• 두 번째 네트워크에서는 작동함: 원래 Wi-Fi, ISP 경로, 로컬 방화벽, VPN, 프록시 또는 필터링 장치를 조사합니다.
• 어디서나 타임아웃됨: DNS, 서버, 방화벽 및 호스팅 공급업체를 계속 확인합니다.

한 번의 성공적인 테스트만으로 모든 사용자에게 사이트가 정상이라고 단정하지 마세요. 라우팅 및 주소 체계 문제는 일부 네트워크에만 영향을 줄 수 있습니다.

2. DNS와 두 주소 체계 확인

nslookup 또는 dig와 같은 DNS 조회 도구를 사용하여 호스트 이름에 반환되는 IPv4 및 IPv6 주소를 확인합니다. 반환된 각 주소를 트래픽을 받아야 하는 서버, 로드 밸런서, CDN 또는 기타 서비스와 비교하세요.

오래된 주소, 예상하지 못한 레코드 또는 구성되지 않은 IPv6 대상이 있는지 확인합니다. 최근 DNS를 변경했다면 권한 있는 레코드를 확인하고, 한 네트워크의 결과만으로 변경 사항을 판단하기 전에 설정된 캐싱 기간을 고려하세요.

3. 브라우저에 의존하지 않고 서비스 테스트

사이트에 연결할 수 있어야 하는 네트워크에서 다음과 같은 읽기 전용 요청을 실행합니다.

curl -v --connect-timeout 10 https://[your hostname]

상세 출력은 호스트 이름 확인, TCP 연결 설정 또는 HTTPS 협상 중 어느 단계에서 오류가 발생하는지 파악하는 데 도움이 됩니다. 실제 서비스 포트와 프로토콜을 테스트하세요. ICMP가 차단될 수 있으므로 ping 실패만으로는 결론을 내릴 수 없습니다.

서비스를 관리하는 경우 적절한 읽기 전용 테스트를 사용하여 IPv4와 IPv6 연결 동작을 각각 비교하세요. 한 주소 체계에서만 오류가 발생한다면 해당 경로, 리스너, 방화벽 정책 또는 DNS 레코드로 조사 범위를 좁힐 수 있습니다.

4. 호스팅 공급업체 콘솔 확인

네트워크 접근에 문제가 있을 때는 SSH에 의존하지 말고 공급업체 대시보드 또는 대역 외 콘솔을 사용하세요. 인스턴스가 실행 중인지, 네트워크 인터페이스가 연결되어 있는지, 공용 주소가 올바른지, 공급업체 상태 확인에서 오류가 보고되지 않았는지 확인합니다.

콘솔에 호스트가 응답하지 않는 것으로 표시되면 승인된 복구 절차를 사용하세요. 재시작 또는 전원 주기는 운영 변경입니다. 권한을 확인하고 활성 사용자와 저장되지 않은 작업에 미치는 영향을 파악한 후 공급업체가 문서화한 복구 절차를 따르세요.

5. 클라우드 및 호스트 방화벽 규칙 검토

보안 그룹, 네트워크 ACL 및 공급업체 방화벽 정책에서 구성된 HTTP 또는 HTTPS 등 필요한 인바운드 서비스 포트가 허용되는지 확인합니다. 그런 다음 콘솔 접근이 가능하다면 ufw 또는 iptables와 같은 운영 체제 방화벽을 검토하세요.

보안 강화 변경, 배포, 주소 업데이트 또는 마이그레이션 중 추가된 규칙을 확인합니다. 관련 소스 범위에서 트래픽이 허용되고 규칙이 올바른 인터페이스와 주소 체계에 적용되는지 확인하세요. 보호 기능을 광범위하게 비활성화하지 말고, 승인된 최소한의 변경만 수행한 뒤 기록하세요.

6. 리소스 고갈 확인

공급업체 콘솔 또는 기존 관리 세션에서 CPU, 메모리, 디스크 압박, 프로세스 제한, 수신 대기 소켓 및 연결 수를 확인합니다. 시스템은 전원이 켜진 상태로 표시되더라도 과도한 부하로 인해 새 연결을 수락하지 못할 수 있습니다.

현재 측정값을 정상 수준과 비교하고 첫 오류가 발생한 시점 전후의 로그를 검토하세요. 서비스 리소스가 고갈된 경우 반복적으로 재시작하지 말고 승인된 용량 확장 또는 복구 절차를 따르세요. 재시작하면 활성 트래픽이 중단되고 근본적인 부하 문제가 가려질 수 있습니다.

7. 프록시, CDN 또는 로드 밸런서 확인

DNS가 CDN, 리버스 프록시 또는 로드 밸런서를 가리키는 경우 프런트엔드가 구성된 포트로 오리진에 연결할 수 있는지 확인합니다. 오리진 주소, 상태 확인 상태, TLS 설정, 네트워크 경로 및 허용 목록을 확인하세요.

정상적인 오리진이라고 해서 프런트엔드와 오리진 사이의 잘못된 정책 또는 경로 문제가 배제되는 것은 아닙니다. 반대로 프런트엔드가 정상이라고 해서 오리진이 연결을 수락하고 있다는 의미도 아닙니다.

8. 유용한 증거와 함께 에스컬레이션

영향받은 호스트 이름, 대략적인 시간과 시간대, 클라이언트 네트워크, 확인된 IPv4 및 IPv6 주소, 각 주소 체계의 동작 차이 여부, 상세 연결 출력 및 공급업체 콘솔의 상태를 기록하세요. 이 증거는 DNS, 라우팅, 필터링, 호스트 및 중간 장치 문제를 구분하는 데 도움이 됩니다.

예방 및 해결 확인 방법

• 여러 외부 위치에서 사이트를 모니터링하고 연결 타임아웃을 HTTP 상태 오류와 별도로 알림 설정합니다.
• DNS 레코드, 공용 주소, CDN 오리진 및 IPv4/IPv6 구성을 문서화하고 마이그레이션 후 검토합니다.
• 복구 경로를 공급업체 콘솔에 마련한 통제된 절차를 통해 방화벽 및 보안 그룹 변경을 테스트합니다.
• CPU, 메모리, 파일 디스크립터, 프로세스 및 연결에 여유 용량을 유지하여 트래픽 급증이 새 연결을 방해하지 않도록 합니다.
• 오리진 상태를 CDN 또는 로드 밸런서 상태와 별도로 모니터링합니다.
• 인시던트 체크리스트에 두 번째 네트워크 테스트와 연결 타임아웃 증거를 포함합니다.
• 필요한 보안 정책을 유지하면서 정식 서비스 포트에는 명확하고 의도적인 방화벽 동작을 사용합니다.

자주 묻는 질문