ERR_SSL_PROTOCOL_ERROR: 해결 방법 완벽 가이드 (Chrome, Edge, 모든 브라우저)

ERR_SSL_PROTOCOL_ERROR란 무엇입니까?

ERR_SSL_PROTOCOL_ERROR는 브라우저가 아무것도 불러오기 전에 보안 연결이 TLS 핸드셰이크 도중 깨졌다는 뜻입니다. Chrome에서는 "사이트에 보안 연결할 수 없음", "example.com에서 잘못된 응답을 전송했습니다."라고 표시되며, Edge에서도 같은 ERR_SSL_PROTOCOL_ERROR가 표시됩니다. 주소가 localhost라면 개발 서버가 거의 확실히 암호화되지 않은 HTTP로 응답하고 있는 것이므로 http://localhost로 여십시오(아래 개발자용 섹션 참고).

모든 HTTPS 연결은 TLS 핸드셰이크로 시작됩니다. 이 과정에서 브라우저와 서버는 프로토콜 버전(TLS 1.2 또는 1.3)과 암호화 방식에 합의하고 인증서를 교환합니다. ERR_SSL_PROTOCOL_ERROR는 이 협상이 깨졌다는 뜻입니다. 즉, 상대방이 올바른 TLS가 아닌 데이터로 응답했거나, 브라우저가 분류할 수 없는 방식으로 핸드셰이크를 거부했습니다.

HTTP 요청이 전송되기 전에 발생하므로 HTTP 상태 코드가 아닙니다. Chromium의 오류 목록은 이 오류를 -107로 정의하며 설명은 "An SSL protocol error occurred"(SSL 프로토콜 오류 발생) 한 줄뿐입니다. 핸드셰이크가 깨진 경우를 모두 아우르는 오류로, "공통 프로토콜 버전이나 암호화 방식이 없음"을 뜻하는 구체적인 오류 -113과는 다릅니다.

ERR_SSL_PROTOCOL_ERROR는 어떻게 표시됩니까?

Chrome 및 기타 Chromium 기반 브라우저는 이 오류를 "사이트에 보안 연결할 수 없음"이라는 전체 페이지 경고로 표시합니다. 그 아래에 구체적인 오류 코드가 나타납니다. 다음은 흔히 볼 수 있는 변형들입니다.

• localhost에서 잘못된 응답을 전송했습니다.(영문: localhost sent an invalid response) — 개발자가 보는 형태로, 암호화되지 않은 HTTP로 동작하는 로컬 서버를 https://로 연 경우입니다
• ERR_SSL_PROTOCOL_ERROR — Chrome이 메시지 아래에 작은 글씨로 표시하는 오류 코드
• net::ERR_SSL_PROTOCOL_ERROR — Chrome DevTools 콘솔에 표시되는 전체 내부 오류 코드
• 사이트에 보안 연결할 수 없음 — Chrome에서 사용자에게 표시되는 헤드라인 메시지
• [도메인]에서 잘못된 응답을 전송했습니다. — Chrome이 헤드라인 아래에 표시하는 상세 오류 텍스트
• ERR_SSL_PROTOCOL_ERROR가 모든 브라우저에서 발생 — Chrome, Edge, Brave, Opera에서 동시에 오류가 나타나는 경우(브라우저 고유 버그가 아닌 서버 측 또는 시스템 전체 문제를 나타냅니다)

ERR_SSL_PROTOCOL_ERROR의 원인은 무엇입니까?

이 오류는 클라이언트 측(사용자 기기)과 서버 측(웹사이트) 원인이 모두 있습니다. 문제가 어느 쪽에 있는지 파악하는 것이 해결의 첫 번째 단계입니다. 오류가 모든 웹사이트에서 나타나면 사용자 측 문제이고, 특정 웹사이트 하나에서만 나타나면 서버 측 문제일 가능성이 높습니다.

• HTTP만 사용하는 서버에 HTTPS로 접속 — 가장 많이 검색되는 경우입니다. 개발 서버를 https://localhost로 열었거나, 포트 443이 TLS용으로 설정되지 않은 사이트가 여기에 해당합니다. 브라우저가 핸드셰이크를 시작했는데 일반 텍스트가 돌아오므로 Chrome은 이를 "잘못된 응답을 전송했습니다"로 표시합니다.
• 백신 프로그램의 SSL/HTTPS 검사 — HTTPS를 가로채는 보안 소프트웨어(Avast, Kaspersky, Bitdefender, ESET)는 핸드셰이크 중간에 끼어들기 때문에 모든 사이트에서 한꺼번에 핸드셰이크를 깨뜨릴 수 있습니다.
• VPN 또는 프록시 간섭 — HTTPS 트래픽을 검사하는 VPN과 기업 프록시는 핸드셰이크를 손상시킬 수 있으며, 특히 네트워크를 전환한 직후에 자주 발생합니다.
• 사이트를 차단하는 네트워크 — 통신사, 학교, 회사, 국가 단위의 필터링과 DNS 기반 차단기는 차단 대상 사이트의 핸드셰이크를 의도적으로 실패시킵니다. 구별하는 방법은 간단합니다. 모바일 데이터나 다른 Wi-Fi에서는 사이트가 열립니다.
• 서버의 잘못된 TLS 설정 — 포트 443이 일반 HTTP로 응답하거나(TLS를 켜지 않은 채 443 포트에 사이트를 설정한 경우), 다른 프로그램이 포트 443을 사용하고 있는 경우입니다.
• 브라우저 확장 프로그램 — HTTPS 요청을 다시 쓰는 개인정보 보호, 광고 차단, 보안 확장 프로그램이 핸드셰이크를 방해할 수 있습니다.
• 오래된 브라우저 상태 — 더 이상 서버와 맞지 않는 캐시된 세션 데이터.
• 이 오류로 착각하기 쉬운 경우 — TLS 1.0이나 1.1에 머문 서버는 ERR_SSL_VERSION_OR_CIPHER_MISMATCH("지원되지 않는 프로토콜을 사용합니다")를, 만료되었거나 이름이 다르거나 자체 서명된 인증서와 잘못된 시계는 인증서 오류(NET::ERR_CERT_…)를, QUIC(HTTP/3) 문제는 ERR_QUIC_PROTOCOL_ERROR를 표시합니다. ERR_SSL_VERSION_OR_CIPHER_MISMATCH와 "연결이 비공개로 설정되어 있지 않습니다"를 참고하십시오.

localhost에서의 ERR_SSL_PROTOCOL_ERROR (개발자용)

"localhost에서 잘못된 응답을 전송했습니다. ERR_SSL_PROTOCOL_ERROR"(영문 Chrome: localhost sent an invalid response.)는 거의 항상 HTTP만 사용하는 개발 서버를 https://localhost로 열었다는 뜻입니다. 브라우저가 TLS 핸드셰이크를 시작하면 서버가 일반 HTTP 텍스트로 응답하고, Chrome은 이 응답을 잘못된 응답으로 표시합니다. Firefox는 같은 실수를 SSL_ERROR_RX_RECORD_TOO_LONG으로 표시합니다.

• 서버가 출력하는 주소를 사용 — https://localhost:3000을 http://localhost:3000으로 바꾸십시오. Next.js, Vite, React, Django, Rails, Flask 개발 서버는 HTTPS를 켜지 않는 한 HTTP로 제공합니다
• 포트 확인 — 포트 없이 https://localhost라고 입력하면 포트 443을 뜻합니다. 앱이 3000이나 5173에서 실행 중이라면 요청이 다른 프로그램에 도달하거나 아무 데도 도달하지 않습니다
• Chrome이 계속 https://로 바뀜 — 같은 포트에서 예전에 실행한 앱의 리디렉션이 캐시되어 있으면 이렇게 될 수 있습니다. 캐시된 이미지 및 파일을 삭제하거나 시크릿 창에서 테스트하십시오. (Chrome 132 이전 버전에서는 localhost의 HSTS 항목이 남아 있을 수도 있었습니다. 이 경우 chrome://net-internals/#hsts의 Delete domain security policies(이 화면은 영어로 표시됨)에서 삭제합니다)
• 로컬에서도 HTTPS가 필요한 경우(OAuth 콜백, Secure 쿠키 등) — next dev --experimental-https는 mkcert로 로컬에서 신뢰되는 인증서를 만듭니다. Vite는 server.https에 인증서 옵션을 지정하거나, 빠르게 자체 서명 인증서를 쓰려면 @vitejs/plugin-basic-ssl을 사용합니다. 그 밖의 환경에서는 mkcert -install && mkcert localhost 127.0.0.1로 서버가 불러올 수 있는 인증서 파일을 만들 수 있습니다
• 자체 서명 인증서는 다른 오류를 표시 — 이 오류가 아니라 NET::ERR_CERT_AUTHORITY_INVALID가 나타납니다. 고급 → localhost(안전하지 않음)(으)로 이동을 클릭하거나, 더 나은 방법으로 mkcert로 만든 인증서를 사용하십시오(예전의 allow-insecure-localhost 플래그는 만료되었습니다)

ERR_SSL_PROTOCOL_ERROR 해결 방법 (사용자용)

해결 방법 1부터 시작하십시오. 2분이면 문제가 브라우저에 있는지, 기기나 네트워크에 있는지, 아니면 사이트에 있는지 알 수 있습니다. 그다음 목록 순서대로 진행하십시오.

해결 방법 1: 시크릿 모드와 다른 네트워크에서 시도

시크릿 모드는 쿠키, 캐시, 확장 프로그램 없이(시크릿 모드에서 허용한 확장 프로그램 제외) 시작합니다. 사이트를 시크릿 창(Chrome과 Edge는 Ctrl+Shift+N, Firefox는 Ctrl+Shift+P)에서 연 다음, 휴대폰의 모바일 데이터 같은 다른 네트워크에서도 열어 보십시오.

시크릿 창에서 열린다면 원인은 브라우저에 있으며, 확장 프로그램이나 오래된 데이터입니다(해결 방법 4와 5). 다른 네트워크에서만 열린다면 현재 네트워크나 VPN, 프록시가 접속을 차단하거나 가로채고 있습니다(해결 방법 3). 어디서나 실패한다면 SSL 인증서 확인로 사이트를 확인하십시오. 그곳에서도 실패한다면 사이트 소유자만 해결할 수 있습니다.

해결 방법 2: 백신 프로그램의 SSL/HTTPS 검사 비활성화

많은 백신 프로그램(Avast, Kaspersky, Bitdefender, ESET, Norton)에는 중간자 프록시 역할을 하여 암호화된 연결을 가로채는 "HTTPS 검사" 또는 "SSL 검사" 기능이 있습니다. 이 기능이 사이트의 핸드셰이크를 제대로 처리하지 못하면 그 컴퓨터의 모든 브라우저에서 해당 사이트가 열리지 않습니다.

백신 프로그램에서 Web Shield, HTTPS Scanning, SSL Scanning, Encrypted connections scanning 같은 이름의 설정(한국어판에서는 이름이 다를 수 있습니다)을 찾아 일시적으로 비활성화하십시오. 오류가 해결되면 백신 프로그램의 제외 목록에 해당 도메인을 추가할 수 있습니다.

해결 방법 3: VPN 또는 프록시 비활성화

VPN과 HTTP 프록시는 브라우저와 웹 서버 사이에 위치합니다. 일부 VPN은 HTTPS 트래픽을 검사하고, TLS가 제대로 동작하지 않는 서버를 통해 연결을 라우팅합니다. 기업 프록시는 종종 TLS 핸드셰이크를 중단시킬 수 있는 SSL 가로채기(백신 프로그램의 HTTPS 검사와 유사)를 사용합니다.

VPN을 일시적으로 연결 해제하고 웹사이트를 로드해 보십시오. VPN 없이 작동한다면 VPN이 SSL 연결을 처리하는 방식에 문제가 있는 것입니다. 다른 VPN 서버를 시도하거나 VPN 제공업체에 문의하십시오.

해결 방법 4: 브라우저 확장 프로그램 비활성화

VPN·프록시 확장 프로그램이나 보안 부가 기능처럼 트래픽을 걸러 내거나 경로를 바꾸는 확장 프로그램은 보안 연결을 깨뜨릴 수 있습니다.

chrome://extensions/로 이동하여 모든 확장 프로그램을 끄고 페이지를 새로고침하십시오. 오류가 사라지면 하나씩 다시 켜서 원인이 되는 확장 프로그램을 찾으십시오.

해결 방법 5: 브라우저 캐시 및 쿠키 삭제

오래된 쿠키나 캐시 데이터가 가끔 문제를 일으키며, 삭제하는 데는 1분이면 충분합니다.

• 1단계: Ctrl+Shift+Delete(Mac: Cmd+Shift+Delete)를 눌러 인터넷 사용 기록 삭제를 엽니다
• 2단계: 기간에서 더보기 → 전체 기간을 선택합니다
• 3단계: 쿠키 및 기타 사이트 데이터와 캐시된 이미지 및 파일을 선택합니다
• 4단계: 데이터 삭제(로그아웃 상태라면 이 기기에서 삭제)를 클릭하고 Chrome을 다시 시작합니다

사이트 하나만 삭제하려면 chrome://settings/content/all에서 해당 도메인을 검색해 데이터를 삭제하십시오.

해결 방법 6: QUIC(HTTP/3)가 원인인지 확인

Chrome은 QUIC(UDP 기반 HTTP/3)를 일반 TCP 연결과 동시에 시도하고 QUIC가 실패하면 TCP로 전환하므로, QUIC가 ERR_SSL_PROTOCOL_ERROR의 원인이 되는 경우는 드뭅니다. 페이지나 DevTools에 ERR_QUIC_PROTOCOL_ERROR가 대신 표시된다면 QUIC를 끄는 것이 해결책입니다(ERR_QUIC_PROTOCOL_ERROR 참고):

• 1단계: 주소 표시줄에 chrome://flags/#enable-quic를 입력합니다
• 2단계: Experimental QUIC protocol을 찾습니다
• 3단계: Default에서 Disabled로 변경합니다
• 4단계: Relaunch를 클릭하여 Chrome을 다시 시작합니다

QUIC를 꺼도 페이지는 TCP 기반 HTTP/2로 로드됩니다. 네트워크나 사이트 문제가 해결되면 다시 켜십시오.

해결 방법 7: 브라우저 업데이트

오래된 브라우저 버전에는 최신 사이트가 요구하는 TLS 기능과 암호화 제품군이 없을 수 있으며, 업데이트로 TLS 관련 버그도 수정됩니다.

Chrome 업데이트: chrome://settings/help로 이동하거나 메뉴 → 도움말 → Chrome 정보를 클릭합니다. Chrome은 업데이트를 자동으로 다운로드하지만 적용하려면 재시작이 필요합니다. Edge: edge://settings/help. Firefox: 메뉴 → 도움말 → Firefox 정보.

해결 방법 8: DNS 캐시 초기화

오래된 DNS 정보 때문에 브라우저가 더 이상 그 사이트를 TLS로 제공하지 않는 예전 서버로 연결될 수 있습니다. DNS 캐시를 초기화하면 새로 조회합니다.

# Windows (Command Prompt as Admin)
ipconfig /flushdns

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

# Linux
sudo resolvectl flush-caches

# Chrome internal DNS cache
# Visit chrome://net-internals/#dns → Click "Clear host cache"

초기화 후 DNS Robot의 DNS 조회를 사용하여 도메인이 올바른 IP로 연결되는지 확인하십시오. IP 주소가 올바르지 않다면, 웹사이트가 호스팅 제공업체를 변경했고 DNS가 아직 완전히 전파되지 않은 것일 수 있습니다.

해결 방법 9: 시스템 날짜 및 시간 확인

시계가 틀리면 보통 다른 오류인 NET::ERR_CERT_DATE_INVALID("시간이 너무 먼 미래로 설정되어 있습니다." 또는 "시간이 너무 먼 과거로 설정되어 있습니다.")가 표시됩니다. 인증서는 정해진 두 날짜 사이에서만 유효하기 때문입니다. 그래도 10초면 확인할 수 있으니 확인해서 배제해 두십시오:

• Windows: 설정 → 시간 및 언어 → 날짜 및 시간 → "자동으로 시간 설정"과 "표준 시간대 자동 설정"을 켭니다
• Mac: 시스템 설정 → 일반 → 날짜 및 시간 → "자동으로 시간 및 날짜 설정"을 켭니다
• Linux: sudo timedatectl set-ntp true 명령어를 실행하여 NTP 동기화를 활성화합니다

해결 방법 10: SSL 상태 초기화 (Windows)

많은 가이드가 Windows 인터넷 옵션의 SSL 상태 지우기(Clear SSL state, inetcpl.cpl → 내용 탭 → SSL 상태 지우기)를 권합니다. 이 기능이 지우는 것은 Windows 자체 TLS 라이브러리의 세션 캐시로, Windows 네트워킹 기능을 사용하는 앱이 이용합니다. Chrome과 Edge는 자체 TLS 라이브러리를 사용하므로 이 작업으로 달라지는 경우는 거의 없습니다.

브라우저에서 같은 효과를 내는 방법은 더 간단합니다. 브라우저 창을 모두 닫고(시스템 트레이에 백그라운드로 실행 중인 Chrome이 없는지도 확인) 다시 여십시오. 그러면 캐시된 TLS 세션이 모두 삭제됩니다. 완전히 다시 시작해도 오류가 남아 있다면 다음 해결 방법으로 넘어가십시오.

해결 방법 11: 네트워크 설정 초기화 (최후의 수단)

다른 방법이 모두 실패하면 네트워크 스택을 초기화하십시오. Windows에서는 아래 명령어가 Winsock과 TCP/IP를 초기화하며, 직접 설정한 고정 IP 주소와 DNS 서버도 함께 지워집니다. macOS와 Linux에서는 DNS 캐시를 비우거나 네트워크 서비스를 다시 시작할 뿐입니다.

# Windows (Command Prompt as Admin)
netsh winsock reset
netsh int ip reset
ipconfig /release
ipconfig /renew
ipconfig /flushdns

# Then restart your computer

# macOS — flush the DNS cache
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

# Linux — restart NetworkManager
sudo systemctl restart NetworkManager

ERR_SSL_PROTOCOL_ERROR 해결 방법 (웹사이트 소유자용)

많은 방문자가 ERR_SSL_PROTOCOL_ERROR를 보고한다면 문제는 서버에 있습니다. 보통 포트 443이 일반 HTTP로 응답하거나 다른 프로그램이 그 포트를 사용하고 있습니다. 인증서 문제는 각자 다른 오류를 표시하지만, 이참에 함께 확인하십시오. (인증서와 키가 일치하지 않으면 서버가 새 설정을 아예 불러오지 않습니다. 변경 후 nginx -t 또는 apachectl configtest로 확인하십시오.)

SSL 인증서 확인

첫 번째 단계는 SSL 인증서가 유효하고, 올바르게 설치되어 있으며, 만료되지 않았는지 확인하는 것입니다. DNS Robot의 SSL 인증서 확인를 사용하여 인증서 상태, 만료일, 발급자, 인증서 체인을 즉시 확인하십시오.

다음 인증서 문제는 ERR_SSL_PROTOCOL_ERROR가 아니라 각자의 오류를 표시하지만, 확인하는 김에 함께 해결하십시오:

• 만료된 인증서(NET::ERR_CERT_DATE_INVALID) — Let's Encrypt 인증서의 유효 기간은 90일(2027년 2월부터 64일)이므로 갱신이 자동으로 실행되어야 합니다. 자동 갱신이 실패하면(certbot 타이머가 실행되지 않거나 DNS 챌린지가 깨진 경우) 인증서가 조용히 만료됩니다.
• 잘못된 도메인(NET::ERR_CERT_COMMON_NAME_INVALID) — 인증서가 example.com용으로 발급되었지만 사이트가 www.example.com으로 제공되는 경우(또는 그 반대). 인증서는 정확한 도메인과 일치하거나 와일드카드(*.example.com)를 포함해야 합니다.
• 자체 서명 인증서(NET::ERR_CERT_AUTHORITY_INVALID) — 개발용으로는 괜찮지만 프로덕션 환경에서는 브라우저가 신뢰하지 않습니다.
• 폐기된 인증서(NET::ERR_CERT_REVOKED) — 키 유출이나 잘못된 발급 때문에 인증 기관이 인증서를 폐기한 경우입니다.
• 호스트 이름에 맞지 않는 인증서(NET::ERR_CERT_COMMON_NAME_INVALID) — 여러 사이트가 하나의 IP 주소를 공유하는데 서버가 SNI(Server Name Indication)로 사이트별 인증서를 고르지 않는 경우입니다.

# Check certificate from command line
openssl s_client -connect yourdomain.com:443 -servername yourdomain.com </dev/null 2>/dev/null | openssl x509 -noout -dates -subject -issuer

# Check certificate chain completeness
openssl s_client -connect yourdomain.com:443 -servername yourdomain.com </dev/null 2>&1 | grep -E "depth|Verify"

# Renew Let's Encrypt certificate
sudo certbot renew --dry-run   # test first
sudo certbot renew

TLS 1.2 및 TLS 1.3 활성화

모든 최신 브라우저는 최소 TLS 1.2를 요구합니다. TLS 1.0과 1.1은 2021년 RFC 8996에서 공식적으로 폐기되었습니다. 상대방의 버전을 받아들이지 않는 쪽은 TLS 경고(alert) 70인 protocol_version으로 핸드셰이크를 종료합니다(RFC 8446 §6.2). TLS 1.0이나 1.1만 지원하는 서버에서는 이 오류가 아니라 ERR_SSL_VERSION_OR_CIPHER_MISMATCH가 표시되지만, 어느 쪽이든 연결에 실패합니다. TLS 1.3은 TLS 1.2의 두 번 왕복 대신 한 번 왕복으로 연결되므로 두 가지를 모두 활성화하십시오.

# Nginx — ssl_protocols in nginx.conf or site config
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384';
ssl_prefer_server_ciphers off;

# Apache — in httpd.conf or ssl.conf
SSLProtocol -all +TLSv1.2 +TLSv1.3
SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256
SSLHonorCipherOrder off

TLS 구성을 업데이트한 후 웹 서버를 재시작하고(sudo systemctl restart nginx 또는 sudo systemctl restart apache2) DNS Robot의 SSL 인증서 확인로 프로토콜이 활성화되었는지 확인하십시오.

완전한 인증서 체인 설치

체인이 불완전하면 빠진 중간 인증서를 스스로 채우지 못하는 브라우저와 앱에서 인증서 오류(NET::ERR_CERT_AUTHORITY_INVALID)가 표시되므로, 확인하는 김에 전체 체인을 설치하십시오. 서버는 자신의 인증서와 함께, 그 인증서를 신뢰할 수 있는 루트에 연결하는 중간 인증서도 보내야 합니다.

대부분의 인증 기관은 "CA 번들" 또는 "전체 체인" 파일을 제공합니다. Let's Encrypt의 경우 cert.pem이 아닌 fullchain.pem을 사용하십시오. 다른 인증 기관의 경우 해당 문서에서 중간 인증서를 다운로드하여 인증서와 연결하십시오.

# Nginx — use fullchain, not just cert
ssl_certificate /etc/letsencrypt/live/yourdomain.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/yourdomain.com/privkey.pem;

# Apache
SSLCertificateFile /etc/letsencrypt/live/yourdomain.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/yourdomain.com/privkey.pem

HSTS 구성 확인

HSTS(HTTP Strict Transport Security)는 브라우저에 해당 도메인에 대해 항상 HTTPS를 사용하도록 지시합니다. HSTS 정책의 max-age가 길게 설정된 상태에서 나중에 TLS 설정이 깨지면 브라우저는 HTTP로 대체할 수 없고, 방문자에게는 클릭해서 넘어갈 방법이 없는 오류 페이지가 표시됩니다.

DNS Robot의 HTTP 헤더 검사로 HSTS 헤더를 확인하십시오. 매우 긴 max-age(예: 2년)를 설정했고 인증서가 만료된 경우, 이전에 사이트를 방문한 사용자는 대체 수단 없이 HTTPS에 고정됩니다. 이를 해결하려면 먼저 SSL 인증서를 고치십시오. 그러면 브라우저가 다시 정상적으로 연결됩니다.

서버 구성 확인

다음 서버 실수는 인증서가 유효해도 핸드셰이크를 깨뜨리며, 나머지 하나는 다른 오류를 표시합니다:

• 포트 443이 일반 HTTP를 제공 — 소유자 측의 전형적인 원인입니다. nginx에서 ssl 없이 listen 443;이라고 쓴 경우(listen 443 ssl;이어야 합니다)나 다른 서비스가 포트 443을 사용하는 경우입니다.
• 암호화 제품군 불일치 — 브라우저가 거부하는 암호화 제품군만 제공하는 서버는 ERR_SSL_VERSION_OR_CIPHER_MISMATCH를 표시합니다. AES-GCM, ChaCha20 같은 최신 AEAD 암호화를 사용하십시오.

외부에서 openssl s_client -connect example.com:443 -servername example.com </dev/null로 테스트하십시오. "wrong version number"(OpenSSL) 또는 "tlsv1 alert protocol version"(macOS 기본 openssl)이 나오면 포트 443이 TLS로 응답하지 않는 것이고, 인증서 내용이 출력되면 핸드셰이크는 정상입니다.

Android에서의 ERR_SSL_PROTOCOL_ERROR

Android 사용자는 Android용 Chrome과 WebView 기반 앱 모두에서 ERR_SSL_PROTOCOL_ERROR를 경험할 수 있습니다. Android는 인증서와 네트워크 설정을 다르게 관리하므로 해결 방법이 데스크톱과 약간 다릅니다.

• 네트워크 전환 — Wi-Fi를 끄고 모바일 데이터로 시도해 보십시오(또는 그 반대). 사이트가 열린다면 그 네트워크가 사이트를 차단하거나 가로채고 있습니다
• 비공개 DNS를 끄고 테스트 — 설정 → 네트워크 및 인터넷 → 비공개 DNS → "사용 안함"(Chrome에서도 설정 → 개인 정보 보호 및 보안 → "보안 DNS 사용"을 끕니다). 광고 차단이나 자녀 보호용 필터링 DNS 서비스는 차단한 사이트를 핸드셰이크를 완료할 수 없는 서버로 보냅니다
• Chrome 데이터 삭제 — 설정 → 앱 → Chrome → 저장용량 → "캐시 지우기"(그래도 해결되지 않으면 "공간 관리")
• Chrome 업데이트 — Play 스토어 → 프로필 사진 → 앱 및 기기 관리 → Chrome 업데이트
• 네트워크 자격 증명 삭제 — 설정 → 보안(최신 휴대폰에서는 "보안 설정 더보기" → "암호화 및 사용자 인증 정보") → "사용자 인증 정보 삭제". 사용자가 설치한 인증서가 모두 제거됩니다
• 날짜 및 시간 확인 — 설정 → 시스템 → 날짜 및 시간 → 자동 설정을 켭니다. 시계가 틀리면 인증서 오류가 표시되지만 금방 확인할 수 있습니다
• 네트워크 설정 초기화 — 설정 → 시스템 → 옵션 초기화 → Wi-Fi 및 모바일 네트워크 초기화(이름은 Android 버전마다 다릅니다)

아이폰·아이패드(iPhone·iPad)에서의 ERR_SSL_PROTOCOL_ERROR

아이폰에서는 Chrome이 ERR_SSL_PROTOCOL_ERROR를 표시하고, Safari는 서버에 보안 연결을 설정할 수 없다는 메시지(영문: "Safari can't establish a secure connection to the server")를 표시합니다. 원인은 컴퓨터와 같지만 설정 위치가 다릅니다:

• 네트워크 전환 — Wi-Fi를 끄고 모바일 데이터로 시도해 보십시오. 사이트가 열린다면 Wi-Fi 네트워크가 사이트를 차단하거나 가로채고 있는 것입니다
• 모르는 VPN과 프로필 삭제 — 설정 → 일반 → VPN 및 기기 관리. 자체 인증서나 VPN을 설치하는 프로필은 HTTPS를 가로챌 수 있습니다
• iCloud 비공개 릴레이를 끄고 테스트 — 설정 → [나의 이름] → iCloud → 비공개 릴레이를 끈 다음 다시 시도합니다
• 스크린 타임 제한 확인 — 설정 → 스크린 타임 → 콘텐츠 및 개인정보 보호 제한에서 웹 콘텐츠 설정을 확인합니다. 차단된 사이트는 열리지 않고 오류가 납니다
• 시계를 자동으로 설정 — 설정 → 일반 → 날짜 및 시간 → "자동으로 설정"을 켭니다

다른 브라우저에서의 ERR_SSL_PROTOCOL_ERROR

ERR_SSL_PROTOCOL_ERROR는 Chromium에 한정된 오류 코드입니다. 다른 브라우저에서는 동일한 SSL 핸드셰이크 실패에 대해 다른 오류 메시지를 표시합니다.

오류가 모든 브라우저에서 동시에 나타나면 문제는 사용자 시스템(백신 프로그램의 HTTPS 검사, VPN이나 프록시, 네트워크) 또는 서버(포트 443이 TLS를 제대로 제공하지 않음)에 있습니다. 하나의 브라우저에서만 실패한다면 그 브라우저의 확장 프로그램과 캐시된 데이터를 확인하십시오.

관련 SSL/TLS 오류 코드

Chrome에는 여러 가지 SSL 관련 오류 코드가 있습니다. 이 코드들은 각각 다른 TLS 핸드셰이크 또는 인증서 문제를 나타냅니다.

모든 SSL 오류에 대해 DNS Robot의 SSL 인증서 확인를 사용하면 인증서 상태, 체인 완전성, 지원되는 TLS 버전, 만료일을 한 번의 스캔으로 빠르게 진단할 수 있습니다.

화면에 "[도메인]에서 지원되지 않는 프로토콜을 사용합니다." 또는 "지원되지 않는 프로토콜"이 표시된다면 이 오류가 아니라 ERR_SSL_VERSION_OR_CIPHER_MISMATCH입니다. ERR_SSL_VERSION_OR_CIPHER_MISMATCH 해결 방법을 참고하십시오.

화면에 "[도메인]와(과)의 연결이 예기치 않게 종료되었습니다."(ERR_CONNECTION_CLOSED)라고 표시된다면 핸드셰이크가 깨진 것이 아니라 연결이 중간에 끊긴 것입니다. 이 경우는 ERR_CONNECTION_CLOSED를 참고하십시오.