ERR_CONNECTION_RESET 오류 원인과 해결 방법

ERR_CONNECTION_RESET이란?

ERR_CONNECTION_RESET은 웹사이트와의 연결이 열렸다가 강제로 끊겼을 때 Chrome, Edge, Brave 등 Chromium 계열 브라우저가 표시하는 오류입니다. 화면에는 '사이트에 연결할 수 없음. 연결이 재설정되었습니다.'(영문: "This site can't be reached. The connection was reset.")라고 나옵니다. Chromium 내부에서는 네트워크 오류 -101이며, 소스 코드에는 연결이 재설정되었다는 한 줄 설명과 함께 "corresponding to a TCP RST", 즉 TCP RST에 해당한다고 적혀 있습니다.

TCP 리셋(RST)은 네트워크의 '전화 끊기' 버튼과 같습니다. 정상적인 연결은 데이터 전송이 끝난 뒤 FIN 패킷으로 정중하게 종료됩니다. 리셋은 인사 없이 즉시 연결을 끝내고, 반쯤 불러온 내용은 모두 버려집니다. 브라우저는 서버에 도달하는 데까지는 성공했습니다. DNS는 정상 작동했고 연결도 수립되었습니다. 그런데 경로 어딘가에서 무언가가 연결을 끊기로 한 것입니다.

그 '무언가'를 찾는 것이 이 문제의 전부입니다. 내 컴퓨터(백신, VPN, 손상된 네트워크 스택)일 수도 있고, 공유기나 ISP, 사이트 앞단의 방화벽, 또는 웹 서버 프로세스 자체일 수도 있습니다. 아래 해결 방법은 그 원인을 가장 빨리 찾을 수 있는 순서로 정리했습니다.

다른 브라우저에서 이 오류가 표시되는 방식

브라우저마다 문구는 다르지만, 모두 같은 TCP 리셋을 알려 주는 것입니다.

Firefox가 '보안 연결 실패(Secure Connection Failed)' 페이지에 PR_CONNECT_RESET_ERROR를 표시한다면 HTTPS 핸드셰이크 도중 리셋이 일어난 것입니다. 원인은 이 가이드와 거의 겹치며, 특히 백신의 HTTPS 검사와 네트워크 필터링이 많습니다.

ERR_CONNECTION_RESET의 원인

모든 리셋에는 보낸 쪽이 있습니다. 누가 보냈는지 알면 누가 고칠 수 있는지도 알 수 있습니다.

처음 다섯 가지는 사용자 쪽 문제이므로 보통 몇 분 안에 해결할 수 있습니다. 마지막 두 가지는 웹사이트 쪽 문제입니다. 캐시를 아무리 지워도 소용없고, 운영자가 해결하거나 사용자가 기다리는 수밖에 없습니다.

1단계: 내 문제인가, 웹사이트 문제인가?

설정을 바꾸기 전에 60초만 투자해 이것부터 확인하세요. 이 가이드의 어느 쪽 절반이 내게 해당하는지 알 수 있습니다.

• 다른 네트워크에서 시도하세요. 휴대폰의 Wi-Fi를 끄고 모바일 데이터로 같은 페이지를 열어 보세요. 열린다면 리셋은 내 기기나 집·회사 네트워크에서 일어나고 있는 것입니다.

• 다른 사이트를 열어 보세요. 모든 HTTPS 사이트에서 리셋이 난다면 VPN, 프록시, 백신을 의심하세요. 한 사이트에서만 난다면 필터링이나 그 사이트의 서버를 의심하세요.

• 외부에서 서버를 테스트하세요. DNS Robot의 포트 확인 도구는 저희 서버에서 해당 사이트의 443 포트로 연결합니다. 저희 쪽에서는 포트가 열려 있는데 내 쪽에서만 리셋된다면, 문제는 나와 사이트 사이의 경로에 있습니다.

• 경로를 추적하세요. traceroute는 DNS Robot과 서버 사이의 모든 네트워크 홉을 보여 주므로, 서버가 죽은 것인지 경로가 끊긴 것인지 구분하는 데 도움이 됩니다.

해결 방법 1: 새로고침 후 시크릿 창에서 열기

리셋이 한 번만 일어났다면 일시적인 경우가 많습니다. 공유기 재부팅, 배포 중 서버 재시작, Wi-Fi 전환 같은 경우입니다. 몇 초 기다린 뒤 Ctrl + R(Mac: Cmd + R)을 누르세요.

계속 발생한다면 시크릿 창(Ctrl + Shift + N, Mac Cmd + Shift + N)에서 페이지를 열어 보세요. 시크릿 모드는 확장 프로그램과 저장된 쿠키 없이 실행됩니다. 여기서 페이지가 열린다면 확장 프로그램이나 손상된 쿠키가 원인입니다. 확장 프로그램을 하나씩 꺼 보거나, 주소창 왼쪽 아이콘 → 사이트 설정 → 데이터 삭제로 해당 사이트의 데이터를 지우세요.

해결 방법 2: VPN 끄기 및 프록시 설정 확인

VPN과 프록시는 모든 연결의 중간에 자리 잡고 있어서, 서버가 과부하 상태이거나 차단되었거나 유휴 타이머가 너무 짧으면 연결을 리셋합니다. 서버만 바꾸지 말고 VPN 연결을 완전히 끊은 뒤 새로고침하세요.

• Windows 11: 설정 → 네트워크 및 인터넷 → 프록시. 자동으로 설정 검색은 켜 둔 채, 수동 프록시 설정에서 설정(또는 편집)을 클릭하고 프록시 서버 사용을 끄세요.

• macOS: 시스템 설정 → 네트워크 → Wi-Fi 또는 이더넷 선택 → 세부사항… → 프록시. 직접 설정하지 않은 프록시는 모두 끄세요.

• Chrome 자체는 시스템 프록시를 사용하므로 브라우저에서 따로 바꿀 것은 없습니다.

# Windows에는 시스템 서비스용 프록시(WinHTTP)가 따로 있습니다.
# 관리자 권한 명령 프롬프트 또는 PowerShell에서 실행:
netsh winhttp show proxy
netsh winhttp reset proxy

해결 방법 3: 백신 HTTPS 검사 또는 방화벽 일시 중지

많은 백신 제품이 HTTPS 트래픽을 복호화해 검사합니다. 이 기능은 HTTPS 검사, 웹 실드(Web Shield), SSL/TLS 프로토콜 필터링, 암호화된 연결 검사 같은 이름으로 불립니다. 검사기가 사이트의 인증서나 프로토콜을 처리하지 못하면, 연결을 통과시키는 대신 리셋해 버립니다.

테스트하려면 백신 전체가 아니라 HTTPS 검사 옵션만 끄고 새로고침하세요. 페이지가 열린다면 해당 사이트만 검사에서 제외하거나(대부분의 제품이 예외 설정을 지원합니다) 백신을 업데이트하세요. 타사 방화벽도 같은 일을 할 수 있으므로 방화벽도 일시 중지한 상태로 테스트해 보세요.

해결 방법 4: Windows 네트워크 스택(Winsock) 초기화

Windows는 Winsock이라는 네트워크 구성 요소 카탈로그를 관리합니다. VPN 클라이언트, 오래된 백신, 일부 악성코드가 여기에 항목을 추가하는데, 카탈로그가 손상되면 모든 사이트에서 리셋이 발생합니다. Winsock과 TCP/IP 스택을 초기화하면 둘 다 기본값으로 돌아갑니다. 관리자 권한으로 명령 프롬프트를 열고 다음을 실행하세요:

netsh winsock reset
netsh int ip reset
ipconfig /release
ipconfig /renew
ipconfig /flushdns

:: 실행 후 PC를 다시 시작하세요. Winsock 초기화는 재부팅해야 적용됩니다.

Windows 11에는 클릭 한 번으로 하는 방법도 있습니다: 설정 → 네트워크 및 인터넷 → 고급 네트워크 설정 → 네트워크 초기화. 모든 네트워크 어댑터를 제거한 뒤 다시 설치하고 PC를 재시작하므로, 이후 Wi-Fi에 다시 연결하고 VPN도 다시 설치해야 합니다.

해결 방법 5: DNS 플러시 및 다른 DNS 리졸버 사용

DNS가 직접 리셋을 보내지는 않지만, 일부 ISP와 회사 리졸버는 차단된 도메인을 연결을 리셋하는 필터링 서버로 연결합니다. 오래된 캐시 주소가 더 이상 해당 사이트를 호스팅하지 않는 서버로 보낼 수도 있습니다. 먼저 캐시를 비우세요. DNS 플러시 가이드에 운영체제별 명령이 모두 있습니다:

# Windows
ipconfig /flushdns

# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# Chrome 자체 캐시: chrome://net-internals/#dns 를 열고 "Clear host cache" 클릭

그다음 내 네트워크가 돌려주는 결과를 중립적인 응답과 비교하세요. DNS Robot의 DNS 조회로 도메인을 조회했을 때 나오는 IP 주소가 내 컴퓨터가 확인한 주소(nslookup example.com)와 다르다면, 사용 중인 리졸버가 나를 다른 곳으로 보내고 있는 것입니다. Cloudflare(1.1.1.1)나 Google(8.8.8.8) 같은 공용 리졸버로 바꾸세요. DNS 속도 테스트로 내 위치에서 가장 빠른 리졸버를 확인할 수 있습니다.

해결 방법 6: 큰 페이지만 실패한다면 MTU 낮추기

전형적인 패턴이 있습니다. 간단한 페이지는 열리는데 큰 페이지, 파일 다운로드, 로그인에서 리셋이 납니다. 이는 MTU 문제를 가리킵니다. 패킷이 경로상의 한 구간을 통과하기에 너무 크고(VPN, PPPoE DSL, 일부 모바일 핫스팟에서 흔함), 이를 알려야 할 장비가 대신 조용히 패킷을 버리기 때문에 연결이 멈췄다가 실패합니다.

조각화 없이 통과하는 가장 큰 패킷 크기를 찾으세요. 데이터 1472바이트에 헤더 28바이트를 더하면 표준 MTU인 1500이 됩니다:

:: Windows: -f = 조각화 금지, -l = 페이로드 크기
ping example.com -f -l 1472
:: "Packet needs to be fragmented but DF set" = 너무 큼. 응답이 올 때까지 값을 낮추세요.

:: 그다음 MTU = (응답이 온 가장 큰 크기 + 28)로 설정, 예: 1400
netsh interface ipv4 show subinterfaces
netsh interface ipv4 set subinterface "Wi-Fi" mtu=1400 store=persistent

# macOS: -D = 조각화 금지, -s = 페이로드 크기
ping -D -s 1472 example.com

해결 방법 7: Chrome 소켓 풀 비우기 및 Chrome 초기화

Chrome은 페이지를 더 빨리 불러오기 위해 열린 연결을 재사용합니다. 네트워크를 바꿨거나 VPN이 끊긴 뒤처럼 풀에 있던 연결 중 하나가 오래되면, Chrome이 그 연결을 다시 쓰려다 리셋될 수 있습니다. chrome://net-internals/#sockets를 열고 Flush socket pools를 클릭한 뒤 새로고침하세요.

Firefox에서는 되는데 Chrome에서만 계속 실패하나요? chrome://settings/reset → 설정을 원래 기본값으로 복원으로 이동하세요. 확장 프로그램이 사용 중지되고 임시 데이터가 삭제되지만, 북마크·방문 기록·저장된 비밀번호는 유지됩니다.

Android와 iPhone에서 ERR_CONNECTION_RESET 해결하기

휴대폰에서도 같은 이유로 이 오류가 발생하며, 원인이 하나 더 있습니다. Android의 비공개 DNS 설정이 필터링 서버나 연결할 수 없는 서버를 가리키는 경우입니다.

• Android, 비공개 DNS: 설정 → 네트워크 및 인터넷 → 비공개 DNS → 자동으로 설정(삼성: 설정 → 연결 → 기타 연결 설정 → 개인 DNS(Private DNS)). Android 비공개 DNS 가이드에서 각 옵션의 의미를 설명합니다.

• Android, 네트워크 설정 초기화: 설정 → 시스템 → 재설정 옵션 → 블루투스 및 Wi-Fi 재설정(Reset Bluetooth & Wi-Fi), 모바일 데이터도 문제라면 모바일 네트워크 설정 재설정(Reset Mobile Network Settings)도 실행하세요(삼성: 설정 → 일반 → 초기화 → Wi-Fi 및 블루투스 설정 초기화(Reset Wi-Fi and Bluetooth settings)).

• iPhone과 iPad: 설정 → 일반 → 전송 또는 iPhone 재설정 → 재설정 → 네트워크 설정 재설정. 저장된 Wi-Fi 네트워크와 비밀번호가 삭제되고, 구성 프로파일로 설치하지 않은 VPN 설정도 제거됩니다.

• 공통: VPN이나 광고 차단 앱(상당수가 로컬 VPN 방식으로 작동)을 끄고, Wi-Fi와 모바일 데이터를 번갈아 사용해 보고, 브라우저 앱을 업데이트하세요.

웹사이트 운영자용: 방문자의 연결을 리셋하는 원인 찾기

방문자들이 ERR_CONNECTION_RESET을 보고하고 여러 네트워크에서 사이트 접속이 실패한다면, 리셋은 내 서버 스택에서 나오고 있는 것입니다. 바깥쪽에서 안쪽 순서로 점검하세요:

• 외부에서 재현하세요. 내 네트워크 밖의 컴퓨터에서 curl -v https://yourdomain.com을 실행하거나, 포트 확인 도구로 443 포트를 테스트하세요. 리셋이 TLS 핸드셰이크 전인지, 도중인지, 요청 전송 후인지 기록해 두세요.

• 보안 계층을 확인하세요. 속도 제한기, fail2ban, CrowdSec, 클라우드 WAF는 차단된 IP를 TCP 리셋으로 거절할 수 있습니다(예: iptables의 REJECT --reject-with tcp-reset 규칙). 무엇보다 먼저 신고한 사용자의 IP가 차단되어 있는지 확인하세요.

• 크래시와 재시작을 찾으세요. 요청 처리 중 죽은 프로세스는 열려 있던 연결도 함께 끊어 버립니다. journalctl -u your-service, pm2 logs를 확인하고, Linux OOM(메모리 부족) 킬러는 dmesg -T | grep -i "killed process"로 확인하세요.

• TLS를 확인하세요. 완전한 인증서 체인과 함께 TLS 1.2와 1.3을 제공하세요. 오래된 프로토콜 설정이나 끊어진 체인은 일부 클라이언트에서 핸드셰이크를 갑자기 종료시킬 수 있습니다. SSL 인증서 확인 도구로 인증서 체인과 만료일을, HTTP 헤더 확인 도구로 실제 요청이 받는 응답을 확인할 수 있습니다.

• CDN을 확인하세요. Cloudflare나 다른 CDN 뒤에 있다면, 원본 서버를 건드리기 전에 CDN의 보안 이벤트 로그에서 방문자의 IP나 국가를 먼저 확인하세요.

# 방문자의 IP가 fail2ban에 차단되어 있나요?
sudo fail2ban-client status              # jail 목록
sudo fail2ban-client status sshd         # 특정 jail에서 차단된 IP
sudo fail2ban-client set sshd unbanip 203.0.113.7

# OOM 킬러가 앱을 종료했나요?
dmesg -T | grep -i "killed process"

ERR_CONNECTION_RESET vs REFUSED vs TIMED_OUT vs CLOSED

이 네 가지 오류는 화면에서는 비슷해 보이지만 네트워크에서는 서로 다른 상황을 나타내며, 해결 방법도 각각 다릅니다. 코드는 Chromium 자체의 네트워크 오류 번호입니다.

관련 오류의 전체 가이드: ERR_CONNECTION_REFUSED, ERR_CONNECTION_TIMED_OUT, ERR_CONNECTION_CLOSED. 네트워크가 보안 DNS까지 차단하고 있다면 이 네트워크가 암호화된 DNS 트래픽을 차단하고 있습니다를 참고하세요.