PR_END_OF_FILE_ERROR 해결 가이드

Problem

파이어폭스가 PR_END_OF_FILE_ERROR 코드와 함께 “보안 연결 실패” 페이지를 띄우고 사이트가 열리지 않습니다. 다른 브라우저에서는 같은 사이트가 멀쩡히 열리기도 합니다.

PR_END_OF_FILE_ERROR가 실제로 뜻하는 것

PR_END_OF_FILE_ERROR는 NSPR 오류 -5938, 문자 그대로 “Encountered end of file(파일 끝을 만남)“에 파이어폭스가 붙인 이름입니다. NSPR은 파이어폭스가 TLS에 쓰는 암호 라이브러리 NSS 아래에 있는 포터블 런타임이라 — 이 코드는 웹 페이지가 아니라 연결 장치 깊은 곳에서 나옵니다.

쉬운 말로 옮기면 이렇습니다. HTTPS 연결을 열려고 파이어폭스가 서버에 첫 메시지(ClientHello)를 보내고 응답을 기다립니다. 이 오류는 응답 대신 end of file가 왔다는 뜻입니다 — 상대가 TCP 연결을 닫고 더 이상 바이트를 보내지 않은 것이죠. 핸드셰이크가 문장 중간에 멈췄습니다. 파이어폭스가 다음 단어를 기다리는데 전화가 끊긴 셈입니다.

여기서 중요한 결론: 이건 인증서·암호(cipher)·프로토콜 버전이 합의되기도 전에 일어납니다. 인증서 오류가 아닙니다 — 인증서를 아직 주고받지 않았으니까요. 가끔 그렇게 설명되지만 사실 cipher 불일치도 아닙니다 — 진짜 불일치는 침묵이 아니라 특정 alert를 냅니다. PR_END_OF_FILE_ERROR는 대화가 시작되기도 전에 수화기를 내려놓는 소리이고, 당신의 일 전부는 누가 끊었는지를 밝히는 것입니다 — 서버냐, 나와 서버 사이에 선 무언가냐.

모든 걸 가르는 갈림길: 나만이냐, 모두냐

설정을 하나라도 바꾸기 전에 한 가지를 답하세요 — 모두에게 실패하는가, 나만 실패하는가? 이걸로 문제가 깔끔하게 반으로 갈립니다.

내 파이어폭스에서만, 혹은 내 네트워크에서만 실패하면 범인은 거의 항상 내 쪽 미들박스입니다: HTTPS를 검사하는 백신, VPN·프록시, 회사 방화벽, 또는 — 요즘의 기본 용의자 — 파이어폭스의 커진 양자내성 ClientHello를 처리 못 하는 장비. 서버는 멀쩡하고 가로채기가 깨진 것입니다.

모두에게 실패하면 — 내 네트워크 밖에서 돌린 외부 진단까지 포함해 — 서버나 그 로드밸런서가 연결을 끊는 것입니다: 잘못된 TLS 종료 설정, 마음에 안 드는 핸드셰이크를 리셋하는 리스너, SNI가 안 맞으면 버리는 프록시. 그러면 서버측 수정이고, 모든 방문자가 함께 겪고 있습니다.

이 한 가지 구분이 전형적 실수를 막아줍니다 — 진짜 문제는 두 홉 건너 방화벽인데 파이어폭스를 재설치하고 인증서를 지우며 몇 시간을 태우거나, 그 반대이거나.

Top 3 Causes

1. 미들박스가 파이어폭스의 양자내성 ClientHello에 걸림. 파이어폭스 132(2024년 말)부터 X25519MLKEM768 하이브리드 키 교환이 기본으로 켜집니다. ML-KEM 키 셰어가 ClientHello에 약 1.2KB를 더해 단일 TCP 세그먼트에 안 들어가고 두 패킷으로 쪼개지죠. ClientHello 전체를 한 번에 읽는다고 가정하고 만든 오래된 DPI 방화벽·검사 장비·로드밸런서는 재조립하지 않고 연결을 리셋합니다. 2025년에 “파이어폭스만, 이 네트워크에서만 깨진다”는 제보가 흔해진 이유가 이것입니다. Fortinet을 비롯한 여러 벤더가 flow-based deep inspection에서 정확히 이 문제로 known-issue 공지를 내고 수정본을 냈으며, 대부분 2025년 중에 패치했습니다. 그래서 최근 업데이트가 안 된 스택에선 먼저 배제해볼 값어치가 있고, 업데이트된 스택에선 답이 아닐 가능성이 큽니다.
2. 로컬 TLS 가로채기가 깨짐. ‘HTTPS/SSL 검사’가 켜진 백신·엔드포인트 보안은 트래픽을 복호화·재암호화해 들여다봅니다. 버그가 있거나 만료·오설정된 놈은 핸드셰이크를 완료하지 않고 끊습니다. VPN·프록시도 홉을 더해 같은 짓을 하고요. 단서는 ‘범위’입니다 — 가로채기 문제는 여러 사이트를 한꺼번에 치는 경향이 있고, 검사 기능(또는 VPN)을 끄면 오류가 사라집니다.
3. 서버나 로드밸런서가 핸드셰이크를 버림. 외부 진단도 핸드셰이크를 못 끝내면 origin을 보세요: 특정 연결을 리셋하는 정책의 프록시/CDN에서 TLS 종료, 미지원 프로토콜이나 SNI 누락 시 닫도록 오설정된 리스너, 연결을 일찍 끊는 과부하 밸런서. 여기선 수정 책임이 방문자가 아니라 서버 운영자에게 있습니다.

Diagnose with DechoNet

• SSL Check — 내 네트워크 밖에서 그 도메인에 실행하세요. TLS 핸드셰이크를 마치고 인증서 정보를 반환하면 서버는 건강하고 문제는 내 쪽(백신·VPN·위의 ClientHello 분할 미들박스) — 사이트 디버깅을 멈추세요. SSL 진단도 핸드셰이크에 실패하면 서버측 문제이고 모두에게 영향을 줍니다.
• Port Check — 443이 실제로 열려 닿는지 확인. Open이 아니라 Filtered(타임아웃)면 핸드셰이크가 시작조차 못 하는 것이고, TLS 문제가 아니라 경로상 방화벽을 보는 것입니다.
• HTTP Check — 80의 HTTP는 되는데 HTTPS만 죽으면, 그 대비가 실패가 TLS 계층에 국한됨을 확인해 줍니다. 서버가 죽은 게 아니라 핸드셰이크가 잘리는 상황과 맞아떨어지죠.

Resolution Checklist

• 범위부터 판정: 사생활 보호 창에서 재현 → 다른 브라우저에서 → 외부 SSL Check로. ‘나만’이면 로컬, ‘모두’면 서버.
• 로컬이고 업데이트 안 된 네트워크 장비에서 최근 시작됐다면 양자내성 ClientHello를 의심하세요. 테스트 목적으로만 about:config에서 파이어폭스의 양자내성 키 셰어를 잠시 꺼볼 수 있습니다. 오류가 사라지면 ClientHello 분할을 처리 못 하는 미들박스를 확인한 것 — 진짜 해결은 설정을 끈 채 두는 게 아니라 그 장비를 업데이트하는 것입니다.
• 백신의 ‘HTTPS/SSL 검사’와 VPN·프록시를 끄고 새로고침. 그걸로 해결되면 검사를 영구히 끄지 말고 도구를 업데이트·재설정하세요.
• 완전히 다른 네트워크(휴대폰 핫스팟)에서 파이어폭스를 시도. 거기서 되면 원래 네트워크의 방화벽·검사 장비를 정면으로 가리킵니다.
• 외부 SSL 진단도 실패하면 서버 운영자에게 넘기세요: TLS 종료 설정, 로드밸런서, 핸드셰이크를 리셋할 수 있는 프록시를 점검.
• 서버측을 바꾼 뒤 SSL Check를 다시 돌려 핸드셰이크가 끝에서 끝까지 완료되는지 확인.

When to Escalate

• 외부 SSL 진단이 핸드셰이크를 못 끝내면 문제는 서버의 TLS 스택이나 로드밸런서이고, 브라우저측 변경으로는 못 고칩니다 — origin이나 CDN 운영 주체로 에스컬레이션하세요.
• 실패가 회사 네트워크에 국한되면 거기 검사 장비나 방화벽이 주인입니다. 개인 사용자가 브라우저에서 재설정할 게 아니라 IT/네트워크팀의 수정(미들박스가 분할 ClientHello를 처리하도록 업데이트)입니다.
• 실패를 지도로 그릴 때 비교해볼 브라우저별 변형: ERR_CONNECTION_CLOSED, ERR_SSL_PROTOCOL_ERROR, ERR_EMPTY_RESPONSE는 밀접하게 관련된 ‘연결 끊김’ 상황에 크롬이 붙인 이름들입니다.