PR_CONNECT_RESET_ERROR 해결 가이드

문제

Firefox가 PR_CONNECT_RESET_ERROR 코드와 함께 “Secure Connection Failed” 또는 “연결할 수 없음” 페이지를 띄우고, 사이트가 열리지 않습니다. 같은 사이트가 Chrome에서는, 혹은 휴대폰에서는, 혹은 다른 네트워크에서는 멀쩡히 열릴 수 있습니다.

PR_CONNECT_RESET_ERROR가 실제로 뜻하는 것

PR_CONNECT_RESET_ERROR는 Firefox가 NSPR 오류 -5961(“connection reset by peer”)에 붙인 이름입니다. NSPR은 Firefox의 암호·네트워킹 라이브러리인 NSS 밑에 있는 포터블 런타임이라, 이 오류는 웹 페이지가 아니라 연결 배관 깊은 곳에서 옵니다.

쉽게 말하면 뭔가가 TCP 리셋 — RST 패킷 — 을 보냈고, 연결이 그 자리에서 죽은 것입니다. 리셋은 타임아웃도 아니고 정중한 종료도 아닙니다. 타임아웃은 침묵이고, 정중한 종료는 상대가 “안녕”이라며 예의 바르게 끊는 것입니다(그게 PR_END_OF_FILE_ERROR). 리셋은 문장 도중에 전화를 쾅 끊는 네트워크판입니다. 난데없고, 거의 언제나 의도적입니다.

바로 그 마지막이 핵심 통찰입니다. 리셋은 대개 오작동이 아니라 결정입니다. TCP 연결은 성공적으로 열렸고 — 두 기기가 악수를 나눴고 — 그다음 실제 데이터가 흐르기 시작하는 순간, 뭔가가 그 데이터를 보고 선을 끊은 것입니다. 정책 기반 차단이 정확히 이렇게 동작합니다. 방화벽이나 필터가 연결이 열리게 두었다가, TLS ClientHello가 접속하려는 사이트(SNI 필드)를 드러내면 RST를 주입해 차단합니다. 그래서 단서는 타이밍입니다 — 연결이 성립된 뒤 첫 바이트를 보내는 순간 죽습니다. 그냥 다운된 서버라면 거절하거나 타임아웃을 내며 전혀 다른 오류를 줬을 겁니다.

당신의 일은 그 리셋을 누가 보냈는지 — 그리고 그가 회선의 내 쪽에 서 있는지 서버 쪽에 서 있는지 — 찾는 것입니다.

모든 것을 가르는 갈림길: 나인가, 모두인가?

설정 하나 건드리기 전에 한 가지를 답하세요 — 이게 모두에게 실패하나, 나만 실패하나? 문제가 깔끔히 반으로 갈립니다.

내 Firefox에서만, 또는 내 네트워크에서만 실패하면, 리셋은 내 쪽에서 주입됩니다. 흔한 용의자를 순서대로: 백신 HTTPS 검사(전형적인 Firefox 전용 원인), VPN·프록시, 트래픽을 가로채는 확장, 또는 특정 목적지로의 연결을 정책으로 리셋하는 회사/ISP 방화벽. 서버는 멀쩡하고, 나와 서버 사이 무언가가 ‘아니오’라고 말하는 것입니다.

모두에게 — 내 네트워크 바깥에서 돌린 외부 점검을 포함해 — 실패하면, 리셋은 서버나 그 로드밸런서에서 옵니다. 연결을 떨구는 과부하 서버, IP 차단(레이트 리미터나 fail2ban이 당신을 표시), 또는 조용히 드롭하는 대신 리셋으로 거부하도록 설정된 엣지 방화벽. 그러면 서버 쪽 문제고, 모든 방문자가 같은 벽에 부딪힙니다.

이 한 구분이 전형적 낭비를 막아 줍니다 — 진짜 범인이 보안 스위트나 두 홉 떨어진 방화벽인데 한 시간 동안 Firefox를 재설치하고 인증서를 지우는 일, 혹은 반대로 서버가 조용히 내 IP를 차단했는데 내 설정과 씨름하는 일.

가장 흔한 원인 3가지

1. 백신·보안 스위트의 HTTPS 검사(Firefox 전용 단서). Avast, Kaspersky, Bitdefender, ESET 같은 스위트는 TLS 트래픽을 복호화·재암호화해 검사합니다. Firefox는 Windows와 별개인 자체 신뢰 저장소를 쓰므로, 그 루트를 Firefox가 신뢰하지 않거나 — 검사 프록시가 버그·만료·과부하면 — 가로채기가 거부되고 연결이 리셋됩니다. 사이트가 Chrome(OS 저장소 신뢰)에서는 되는데 Firefox에서만 리셋되는 가장 큰 이유입니다. 확인: 스위트의 “HTTPS/SSL 검사” 기능을 끄고 새로고침.
2. 정책으로 리셋하는 방화벽·VPN·ISP. DPI 방화벽과 콘텐츠 필터는 흔히 TCP 연결을 열게 두고, ClientHello에서 SNI 호스트명을 읽어, 목적지가 차단 목록에 있으면 RST를 주입합니다 — 회사 필터링, 학내망, 국가 단위 검열이 전부 이렇게 동작합니다. VPN·프록시는 같은 짓을 하거나, 목적지가 거부하는 IP로 라우팅하는 홉을 더합니다. 서명은 선택성입니다 — 어떤 사이트는 리셋되고 어떤 사이트는 열리며, 네트워크를 바꾸면(휴대폰 핫스팟) 문제가 이동합니다.
3. 서버나 로드밸런서가 리셋을 보낸다. 외부 점검도 리셋되면 오리진을 보세요. 과부하 서버는 연결을 떨구고, fail2ban 같은 레이트 리미터·침입 차단 도구는 표시한 IP에서 오는 연결을 리셋하며, 일부 엣지 방화벽은 리셋으로 거부하도록 설정돼 있습니다. 여기서 해법은 서버 운영자의 몫입니다 — 내 IP가 일시 차단됐다면, 그 차단이 풀리길 기다리거나 해제를 요청하는 것.

DechoNet으로 진단

• HTTP 진단 — 내 네트워크 바깥에서 사이트로 돌려 보세요. 연결돼 상태 코드를 반환하면 서버는 살아서 응답 중이므로, 리셋은 나와 서버 사이에서 주입되는 것입니다 — 내 쪽의 백신, VPN, 필터링 방화벽. 사이트 디버깅은 그만두세요. HTTP 진단도 연결에 실패하면 서버 쪽 문제고 모든 방문자가 겪습니다.
• 포트 진단 — 포트(HTTPS는 443)가 바깥에서 실제로 열려 도달 가능한지 확인하세요. 바깥에선 열렸는데 나에게만 리셋되면, 그 간극이 내 로컬 미들박스입니다. 모두에게 필터/차단이면, 차단은 서버의 네트워크 엣지에 있습니다.
• SSL 진단 — 이게 바깥에서 깨끗한 TLS 핸드셰이크를 마치고 인증서를 읽으면, 서버의 TLS 스택은 멀쩡하고 실패는 내 경로에 국한된 것입니다 — 망가진 서버가 아니라 주입된 리셋과 부합합니다.

해결 체크리스트

• 먼저 범위부터 정하세요: 사생활 보호 창에서 재현 → 다른 브라우저 → 외부 HTTP 진단. 나만이면 로컬, 모두면 서버.
• 로컬이면 백신·보안 스위트의 “HTTPS/SSL 검사”를 끄고 새로고침하세요. 그걸로 고쳐지면 검사를 영구히 끄지 말고 도구를 업데이트·재설정하거나, 그 루트를 Firefox 신뢰에 추가하세요(security.enterprise_roots.enabled).
• VPN·프록시·트래픽 가로채기 확장을 끄고 새로고침하세요. Firefox 문제 해결 모드로 확장을 깔끔히 배제해 테스트하세요.
• 완전히 다른 네트워크 — 휴대폰 핫스팟 — 를 시도하세요. 거기서 열리면 원래 네트워크의 방화벽·필터가 연결을 리셋하는 것이고, 이건 브라우저 설정이 아니라 IT·네트워크 팀 사안입니다.
• 외부 점검도 실패하면 서버 운영자에게 넘기세요: 로드밸런서 상태, 연결 한도, 그리고 당신의 주소를 리셋할 수 있는 IP 기반 차단(레이트 리미터나 fail2ban)을 보라고.
• 변경 후 HTTP 진단을 다시 돌려, 이제 리셋 대신 연결이 완료되는지 확인하세요.

언제 에스컬레이션하나

• 외부 HTTP·포트·SSL 점검이 전부 리셋되거나 연결에 실패하면, 문제는 서버의 네트워크 엣지나 로드밸런서고 브라우저 쪽 변경으로는 못 고칩니다 — 오리진 운영자에게 넘기세요.
• 리셋이 회사·학내망에 국한된다면, 거기의 DPI 방화벽이나 콘텐츠 필터가 정책으로 주입하는 것입니다. 사용자가 브라우저에서 재설정할 일이 아니라 네트워크 팀의 결정입니다.
• 실패를 분류할 때 함께 비교할 “연결 끊김” 계열: ERR_CONNECTION_RESET은 이 오류의 Chrome 정확한 대응, ERR_CONNECTION_CLOSED는 정중한 종료 형제, 그리고 리셋되는 게 내 IP라면 Your IP Has Been Temporarily Blocked이 레이트 리밋·fail2ban 경우를 다룹니다.