ERR_CONNECTION_TIMED_OUT과 ERR_CONNECTION_REFUSED는 어떻게 다른가요?

TIMED_OUT은 연결 시도에 아무 응답이 없어 브라우저가 기다리다 포기한 것입니다. REFUSED는 그 포트에서 듣는 프로그램이 없거나 방화벽이 거부해 즉시 reset이 돌아온 것입니다. 침묵은 패킷을 버리는 방화벽, 잘못된 IP, 라우팅을, 거부는 서버를 가리킵니다.

휴대폰에서는 되는데 노트북에서만 시간 초과가 납니다.

노트북 쪽 문제입니다. VPN, 프록시, PC 방화벽, 예전 IP를 가리키는 hosts 파일 항목이나 DNS 캐시, 그 네트워크의 차단 장비를 의심하세요. 휴대폰이 모바일 데이터였다면 노트북이 붙은 네트워크 자체도 용의자입니다.

오류가 뜨기까지 왜 이렇게 오래 멈춰 있나요?

아무 응답이 없으면 컴퓨터는 반응할 신호가 없으니, 간격을 늘려 가며 연결 요청을 몇 번 다시 보낸 뒤 포기합니다. 걸리는 시간은 운영체제 설정에 따라 다르고, 리눅스 기본값에서는 약 2분입니다.

Cloudflare를 쓰는 내 사이트에서 방문자가 ERR_CONNECTION_TIMED_OUT을 봅니다. 원 서버가 죽은 건가요?

꼭 그렇지는 않습니다. 원 서버에 닿지 않으면 방문자는 브라우저 시간 초과가 아니라 Cloudflare의 522 페이지를 봅니다. 브라우저 시간 초과라면 방문자가 Cloudflare 엣지에 닿지 못했거나, 그 이름이 실제로는 Cloudflare를 가리키지 않는 것입니다.

ERR_CONNECTION_TIMED_OUT 원인과 해결: 패킷은 어디서 사라졌나

이 오류가 정확히 말하는 것

크롬은 “사이트에 연결할 수 없음 / example.com에서 응답하는 데 시간이 너무 오래 걸립니다.”와 함께 ERR_CONNECTION_TIMED_OUT(내부 코드 -118)을 보여 줍니다. 파이어폭스는 연결 시간이 초과됐다는 문구(The connection has timed out)를, 프로그램은 ETIMEDOUT을 받습니다.

내 컴퓨터가 TCP 연결의 첫 패킷인 SYN을 보냈는데 아무것도 돌아오지 않았습니다. 수락도 거절도 아닙니다. 컴퓨터는 간격을 늘려 가며 SYN을 몇 번 더 보내다 결국 포기합니다. 그 시간은 운영체제마다 다릅니다. 리눅스 기본 설정에서는 재시도가 약 2분에 걸쳐 이어지고, 윈도우는 그보다 빨리 포기합니다.

침묵이 단서입니다. 그 포트에서 듣는 프로그램이 없는 기기라면 즉시 거부했을 것입니다. 침묵은 패킷이 어딘가에서 버려졌거나, 아무도 없는 주소로 갔다는 뜻입니다.

오류	일어난 일	체감	볼 곳
`ERR_CONNECTION_TIMED_OUT`	SYN에 아무 응답 없음	한참 멈췄다 실패	패킷을 버리는 방화벽, 잘못된 IP, 라우팅, 과부하 서버
`ERR_CONNECTION_REFUSED`	SYN에 RST가 돌아옴	즉시 실패	그 포트에서 듣는 프로그램이 없음, 거부하는 방화벽
`ERR_CONNECTION_RESET`	연결은 열렸고 그 뒤 RST가 옴	연결 후 실패	애플리케이션, 프록시, 트래픽을 검사하는 필터

이 오류는 연결을 여는 단계에 대한 것입니다. 연결은 열렸는데 페이지가 오지 않는다면 한참 로딩만 돌다가 ERR_TIMED_OUT 같은 다른 오류가 날 수 있습니다. 그건 다른 문제이고 글 끝에서 다룹니다.

먼저: 어디서 나는가

모든 사이트인가, 한 사이트인가? 모든 사이트가 시간 초과라면 내 인터넷 연결이 문제입니다. 공유기, 와이파이, 멈춘 VPN, 아무 데도 없는 곳을 가리키는 프록시 설정입니다. 더 읽기 전에 공유기를 재시작하고 VPN을 끄세요.

한 네트워크인가, 모든 네트워크인가? 휴대폰 와이파이를 끄고 모바일 데이터로 같은 주소를 열어 보세요. 모바일 데이터로 된다면 문제는 내 네트워크와 사이트 사이, 또는 내 컴퓨터에 있습니다. 어디서나 시간 초과라면 서버나 서버의 방화벽을 봐야 합니다.

HTTP 점검은 내 네트워크 밖에서 페이지를 불러옵니다. 거기서 성공한다면 사이트는 살아 있고 나에서 사이트까지의 경로가 끊긴 것입니다.

방문자라면

내 컴퓨터가 예전 주소를 기억하고 있습니다. 사이트가 최근에 서버를 옮겼다면 내 컴퓨터나 네트워크의 DNS 리졸버가 아무도 답하지 않는 예전 IP를 들고 있을 수 있습니다. 캐시를 비우세요. 윈도우는 ipconfig /flushdns, macOS는 sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder, 크롬은 chrome://net-internals/#dns → Clear host cache입니다. hosts 파일(/etc/hosts 또는 C:\Windows\System32\drivers\etc\hosts)에 그 이름이 있는지도 보세요.

내 컴퓨터의 VPN, 프록시, 방화벽. 하나씩 끄고 다시 시도하세요. 터널이 끊긴 줄 모르는 VPN은 트래픽을 삼켜서 모든 사이트에서 정확히 이 오류를 냅니다.

내 네트워크가 사이트나 포트를 막고 있습니다. 회사, 학교, 일부 공용 와이파이는 허용하지 않은 사이트나 포트로 가는 트래픽을 버리고, 버려진 패킷은 시간 초과로 보입니다. 공공기관·금융권처럼 망분리를 하는 곳의 업무용 PC는 외부 사이트 접속 자체가 막혀 있는 것이 정상입니다. 443보다 흔하지 않은 포트가 더 자주 막힙니다. 주소에 :8080이나 :8443이 있다면 다른 네트워크에서 시험해 보세요. 한국의 불법·유해 사이트 SNI 차단도 통신사에 따라 연결 재설정이 아니라 무응답으로 나타난다는 보고가 있습니다.

사이트가 내 나라나 내 IP를 막고 있습니다. 자국 방문자만 받고 나머지는 조용히 버리는 사이트가 있습니다. 국내 공공기관 사이트 중에도 해외 IP를 막는 곳이 많아서, 해외에 있을 때나 해외 서버를 거치는 VPN을 쓸 때 시간 초과가 납니다. 속도 제한에 걸린 IP를 버리는 방화벽도 있습니다. 다른 네트워크나 HTTP 점검에서는 되고 내 연결만 무시당한다면 이 경우일 가능성이 높고, 사이트 운영자만 바꿀 수 있습니다.

사이트를 운영한다면

내 네트워크 밖에서, 2분씩 기다리지 않도록 연결 타임아웃을 지정해 재현하세요.

curl -v --connect-timeout 10 https://www.example.com/ -o /dev/null

*   Trying 203.0.113.10:443...
* Failed to connect to www.example.com port 443 after 10001 ms: Timeout was reached
curl: (28) Failed to connect to www.example.com port 443 after 10001 ms: Timeout was reached

curl 버전에 따라 문구는 다르지만 시도한 IP를 적어 두세요. 아래 모든 점검은 그 IP가 맞는지에서 시작합니다.

1. 이름이 엉뚱한 주소를 가리킴

dig +short www.example.com A
dig +short www.example.com AAAA

볼 것은 이렇습니다.

이전 후의 예전 서버 IP. 전파 확인으로 공용 리졸버들이 모두 새 주소로 넘어갔는지 보세요.
사설 주소. 10.x.x.x, 172.16~31.x.x, 192.168.x.x는 사무실 안에서는 되고 인터넷에서는 아무 데도 가지 않습니다. 내부용 레코드를 공개 DNS에 그대로 옮겨 적었을 때 생깁니다.
IP 오타, 또는 인스턴스를 중지하면서 클라우드 사업자에게 반납된 주소. 고정 IP(AWS의 Elastic IP 등)가 있는 이유입니다.

DNS 조회는 공용 리졸버가 돌려주는 값을 보여 줍니다. 내 컴퓨터가 보는 값과 다를 수 있습니다.

2. 방화벽이 패킷을 버림

서버 쪽 원인으로는 가장 흔합니다. 클라우드 방화벽은 기본이 ‘버림’입니다. 443 인바운드 규칙이 없는 AWS 보안 그룹, GCP 방화벽 규칙, Azure NSG는 SYN을 아무 말 없이 버립니다. 확인할 곳이 두 겹인 경우가 많습니다. 클라우드 방화벽과 서버 자체의 방화벽입니다.

sudo ufw status verbose
sudo iptables -S
sudo nft list ruleset

ufw의 기본 수신 정책 deny는 패킷을 버리므로, ufw allow 443/tcp가 빠지면 거부가 아니라 시간 초과가 납니다. 일부 클라우드 이미지는 사업자 방화벽과 별개로 자체 호스트 방화벽 규칙을 넣어 배포하므로(Oracle Cloud 이미지가 잘 알려진 예입니다), 웹 콘솔에서 포트를 여는 것만으로는 부족할 수 있습니다.

패킷이 서버에 도착하기는 하는지 보려면, 바깥에서 다시 시도하는 동안 서버에서 패킷을 잡아 보세요.

sudo tcpdump -ni any 'tcp port 443 and tcp[tcpflags] & tcp-syn != 0'

SYN이 오지 않으면 서버 앞에서 버려진 것입니다(클라우드 방화벽, 잘못된 IP, 라우팅). SYN은 오는데 SYN-ACK가 나가지 않으면 서버 자체 방화벽이거나 서버가 과부하입니다. SYN-ACK는 나가는데 클라이언트는 여전히 시간 초과라면 응답이 돌아가는 길에서 사라진 것이고, 돌아가는 경로의 라우팅이나 방화벽을 가리킵니다.

3. 집에서 공유기 뒤에 둔 서버

가정용 회선으로 호스팅한다면 바깥에서의 시간 초과는 흔히 세 가지 때문입니다.

포트 포워딩이 없음. 공유기가 SYN을 받고 보낼 곳이 없습니다. 443을 서버의 내부 주소로 포워딩하세요.
통신사 NAT(CGNAT). 공유기 상태 화면의 WAN 주소가 내 공인 주소(IP 확인에서 볼 수 있습니다)와 다르거나 100.64.0.0/10 대역이라면, 통신사가 공인 IP 하나를 여러 가입자가 나눠 쓰게 하는 것입니다. 포트 포워딩은 동작할 수 없고, 통신사에서 공인 IP를 받거나 터널 서비스를 써야 합니다.
통신사가 수신 포트를 막음. 일부 가정용 요금제는 80, 443, 25 포트로 들어오는 연결을 막습니다. 가입한 상품의 약관을 확인하세요.

반대 경우도 있습니다. 바깥에서는 되는데 우리 집 안에서만 시간 초과가 나는 경우로, 공유기가 내부에서 내 공인 IP로 되돌아 들어가는 것(헤어핀 NAT)을 지원하지 않아서입니다. 내부 DNS를 쓰거나 바깥에서 시험하세요.

4. 서버가 너무 바빠 답하지 못함

연결 대기열(listen queue)이 넘치면 리눅스는 새 연결 시도에 답하지 않고 버리고, 클라이언트에게는 시간 초과로 보입니다. 대기열 넘침과 연결 추적 테이블이 가득 찼는지 보세요.

nstat -az TcpExtListenOverflows TcpExtListenDrops
ss -ltn 'sport = :443'
dmesg -T | grep -i conntrack

LISTEN 소켓에서 ss는 Recv-Q에 현재 accept 대기열 길이를, Send-Q에 그 한도를 보여 줍니다. Recv-Q가 한도에 붙어 있다면 애플리케이션이 연결을 충분히 빨리 받아 가지 못하는 것입니다. nf_conntrack: table full, dropping packet 메시지는 방화벽의 상태 테이블이 가득 찼다는 뜻이니 nf_conntrack_max를 올리거나 추적 대상을 줄이세요.

5. 특정 경로의 라우팅 문제

한 통신사 가입자들만 시간 초과이고 나머지는 괜찮다면 문제는 그 사이의 라우팅입니다. TCP traceroute로 패킷이 어디서 멈추는지 볼 수 있습니다.

sudo traceroute -T -p 443 www.example.com
mtr --tcp --port 443 www.example.com

일반 ICMP traceroute는 중간에서 걸러지는 경우가 많아 오해를 부릅니다. TCP 모드는 브라우저와 같은 포트를 씁니다. 영향을 받는 네트워크에서만, 매번 같은 구간에서 멈춘다면 그 결과를 첨부해 호스팅 사업자나 통신사에 보내세요.

Cloudflare나 다른 CDN 뒤라면

Cloudflare 프록시를 켠 호스트명에서 브라우저는 내 서버가 아니라 Cloudflare에 연결합니다. 원 서버가 답하지 않으면 방문자는 ERR_CONNECTION_TIMED_OUT이 아니라 Cloudflare의 522 오류 페이지를 봅니다. 그러니 프록시를 켠 호스트명에서 브라우저 시간 초과가 난다면, 방문자가 Cloudflare 엣지에 닿지 못했거나(방문자 쪽 네트워크), 레코드가 실제로는 프록시되지 않아 방문자가 패킷을 버리는 원 서버로 바로 가고 있는 것입니다.

연결은 되는데 멈춘다면: 다른 문제

curl이 Connected to까지는 가고 그 뒤 TLS 핸드셰이크나 응답 대기에서 멈춘다면 연결은 열린 것입니다. 흔한 원인은 둘입니다.

경로 MTU 문제. 작은 패킷은 통과하고 큰 패킷(TLS 중 서버 인증서)만 조용히 사라집니다. VPN, PPPoE 회선, 터널에서 흔합니다. 조각내지 않는 ping으로 시험하세요. 리눅스는 ping -M do -s 1472 example.com, 윈도우는 ping -f -l 1472 example.com입니다. 작은 크기는 되는데 이것만 실패하면 MTU를 낮추거나 터널에서 MSS clamping을 켜세요.
애플리케이션이 느림. 서버는 연결을 받았지만 답이 너무 늦습니다. 프록시 뒤라면 504 Gateway Timeout이 됩니다.

DechoNet으로 바깥에서 확인하기

포트 점검은 DechoNet 서버에서 TCP 연결을 시도합니다. ‘열림’은 3초 안에 핸드셰이크가 완료됐다는 뜻입니다. ‘닫힘’은 거부, reset, 무응답을 모두 포함하므로 어느 쪽인지는 알려 주지 않습니다. 그건 바깥에서 curl -v를 돌리면 알 수 있습니다. 점검은 내 네트워크 밖, 대부분 국외에서 나가므로 국내 접속만 받는 서버는 닫힘으로 보입니다. Cloudflare IP 주소의 호스트는 우리 쪽에서 아예 점검할 수 없고, 도구가 그렇게 알려 줍니다.
HTTP 점검은 바깥에서 페이지를 불러옵니다. DechoNet의 해외 출구에서 응답을 받지 못하면 서울 관측점에서 다시 시도하므로, ‘서버가 죽었다’와 ‘해외 IP를 막는다’를 구분할 수 있습니다.
DNS 조회는 외부에서 보이는 A·AAAA 레코드를 보여 줍니다.

비슷해 보이는 다른 오류

ERR_CONNECTION_REFUSED: 침묵 대신 즉시 거절이 돌아옵니다.
ERR_CONNECTION_RESET: 연결은 열렸고, 그 뒤에 끊겼습니다.
ERR_NAME_NOT_RESOLVED: IP 주소 자체가 없어 연결을 시도조차 하지 않았습니다.

내 도메인에서 바로 확인

무료, 가입 불필요. 이 가이드가 다루는 항목을 바로 검사하고 조치 방법을 알려드립니다.