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

ERR_SSL_PROTOCOL_ERROR란 무엇입니까?

ERR_SSL_PROTOCOL_ERROR는 브라우저와 웹 서버 간의 SSL/TLS 핸드셰이크가 실패했을 때 발생하는 브라우저 오류입니다. 브라우저가 안전한 암호화 연결을 수립할 수 없어 안전하지 않은 채널을 통한 데이터 전송으로부터 사용자를 보호하기 위해 페이지 전체를 차단합니다.

모든 HTTPS 연결은 TLS 핸드셰이크로 시작됩니다. 이것은 브라우저와 서버가 암호화 프로토콜(TLS 1.2 또는 1.3)에 합의하고, 인증서를 교환하며, 상호 신원을 확인하는 협상 과정입니다. ERR_SSL_PROTOCOL_ERROR는 이 협상이 완료되기 전에 중단되었음을 의미합니다.

이 오류는 서버 측 HTTP 상태 코드가 아닙니다 — HTTP 요청이 전송되기 전에 브라우저 내부에서 발생합니다. 기본 Chromium 오류 코드는 net::ERR_SSL_PROTOCOL_ERROR(오류 코드 -107)이며, Chromium 소스에서 수용 가능한 보안 매개변수 집합을 협상하지 못한 것으로 정의됩니다.

ERR_SSL_PROTOCOL_ERROR는 어떻게 표시됩니까?

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

• 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의 원인은 무엇입니까?

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

• 시스템 날짜/시간 오류 — 사용자 측 원인 1위입니다. SSL 인증서는 시간에 민감하여, 컴퓨터 시계가 몇 분만 틀려도 인증서 유효성 검사가 실패하고 TLS 핸드셰이크가 중단됩니다.

• 만료되었거나 유효하지 않은 SSL 인증서 — 웹사이트의 SSL 인증서가 만료되었거나, 자체 서명되었거나, 다른 도메인용으로 발급되었습니다. SSL Checker로 인증서를 즉시 확인할 수 있습니다.

• 오래된 TLS 프로토콜 — 서버가 최신 브라우저가 사용을 거부하는 더 이상 사용되지 않는 프로토콜(SSL 3.0, TLS 1.0, TLS 1.1)만 지원합니다. Chrome, Edge, Firefox 모두 2020년에 TLS 1.0/1.1 지원을 중단했습니다.

• 손상된 브라우저 SSL 상태 — 브라우저가 현재 연결 시도와 충돌하는 이전 SSL 세션 데이터, HSTS 기본 설정 또는 인증서 정보를 캐시하고 있습니다.

• QUIC 프로토콜 충돌 — Chrome의 실험적 QUIC 프로토콜(HTTP/3)이 이를 제대로 지원하지 않는 서버에서 TLS 협상을 방해할 수 있습니다.

• 백신 프로그램의 SSL/HTTPS 검사 — HTTPS 트래픽을 가로채는 보안 소프트웨어(Avast, Kaspersky, Bitdefender, ESET)가 연결에 자체 인증서를 삽입하여 TLS 핸드셰이크를 중단시킬 수 있습니다.

• 불완전한 인증서 체인 — 서버가 SSL 인증서는 보내지만 루트 인증 기관까지의 신뢰 체인을 검증하는 데 필요한 중간 인증서를 보내지 않습니다.

• VPN 또는 프록시 간섭 — HTTPS 트래픽을 검사하는 VPN과 기업 프록시가 TLS 핸드셰이크를 손상시킬 수 있으며, 특히 네트워크 전환 시 문제가 발생합니다.

• 브라우저 확장 프로그램 — HTTPS 요청을 수정하는 개인정보 보호 확장 프로그램, 광고 차단기, 보안 추가 기능이 SSL 핸드셰이크를 방해할 수 있습니다.

• 방화벽이 포트 443을 차단 — 네트워크 방화벽이나 라우터가 표준 HTTPS 포트(443)를 차단하여 TLS 핸드셰이크 완료를 막고 있습니다.

ERR_SSL_PROTOCOL_ERROR 해결 방법 (사용자용)

웹 브라우징 중 이 오류가 나타나면 가장 간단한 해결 방법부터 시도하십시오. 대부분의 경우 아래 처음 세 가지 해결 방법으로 문제가 해결됩니다.

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

잘못된 시스템 시계는 ERR_SSL_PROTOCOL_ERROR의 가장 흔한 원인입니다. SSL 인증서에는 유효 기간(시작일 / 만료일)이 있으며, 시스템 시간이 이 범위를 벗어나면 핸드셰이크가 실패합니다. 엄격한 인증서 유효성 검사에서는 몇 분만 차이 나도 문제가 발생할 수 있습니다.

컴퓨터가 자동으로 시간을 동기화하도록 설정되어 있는지 확인하십시오.

• Windows: 설정 → 시간 및 언어 → 날짜 및 시간 → "자동으로 시간 설정"과 "자동으로 표준 시간대 설정"을 켭니다

• Mac: 시스템 설정 → 일반 → 날짜 및 시간 → "자동으로 날짜 및 시간 설정"을 켭니다

• Linux: sudo timedatectl set-ntp true 명령어를 실행하여 NTP 동기화를 활성화합니다

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

Windows는 브라우저와 별도로 자체 SSL 인증서 캐시를 유지합니다. 이 캐시의 오래되었거나 손상된 항목이 브라우저 캐시를 삭제한 후에도 지속적인 ERR_SSL_PROTOCOL_ERROR를 유발할 수 있습니다.

Windows에서 SSL 상태를 초기화하려면: 인터넷 옵션을 엽니다(시작 메뉴에서 검색하거나 실행 대화 상자에서 inetcpl.cpl 입력) → 콘텐츠 탭을 클릭합니다 → SSL 상태 지우기를 클릭합니다 → 확인을 클릭합니다. 그런 다음 브라우저를 다시 시작합니다.

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

손상된 캐시 데이터 또는 오래된 HSTS(HTTP Strict Transport Security) 항목이 브라우저가 오래된 매개변수로 연결을 시도하게 만들어 SSL 프로토콜 오류를 발생시킬 수 있습니다.

• 1단계: Chrome 설정 → 개인정보 및 보안 → 인터넷 사용 기록 삭제를 엽니다 (또는 Ctrl+Shift+Delete 누르기)

• 2단계: 고급 탭으로 전환합니다

• 3단계: 기간을 전체 기간으로 설정합니다

• 4단계: 캐시된 이미지 및 파일, 쿠키 및 기타 사이트 데이터, 호스팅된 앱 데이터를 선택합니다

• 5단계: 데이터 삭제를 클릭하고 Chrome을 다시 시작합니다

특정 사이트의 데이터만 삭제하려면: chrome://settings/content/all로 이동하여 해당 도메인을 검색한 후 휴지통 아이콘을 클릭합니다.

해결 방법 4: QUIC 프로토콜 비활성화

Chrome은 더 빠른 연결을 위해 기본적으로 QUIC 프로토콜(UDP 기반 HTTP/3)을 사용합니다. 그러나 일부 서버, 방화벽, 네트워크 장비가 QUIC를 제대로 처리하지 못하여 SSL 핸드셰이크 실패를 유발할 수 있습니다. QUIC를 비활성화하면 Chrome이 표준 TCP 기반 TLS 연결을 사용하도록 강제합니다.

• 1단계: 주소 표시줄에 chrome://flags/#enable-quic를 입력합니다

• 2단계: Experimental QUIC protocol을 찾습니다

• 3단계: Default에서 Disabled로 변경합니다

• 4단계: Relaunch를 클릭하여 Chrome을 다시 시작합니다

QUIC를 비활성화한 후 오류가 사라지면, 서버의 HTTP/3 구현이나 네트워크의 UDP 포트 443 차단이 문제입니다. QUIC를 비활성화해 두어도 부정적인 영향은 없습니다. 페이지는 표준 HTTPS(TCP 기반 HTTP/2)를 통해 로드됩니다.

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

웹 트래픽을 가로채거나 수정하는 확장 프로그램 — 광고 차단기, VPN 확장 프로그램, 개인정보 보호 도구, HTTPS Everywhere — 이 TLS 핸드셰이크를 방해할 수 있습니다. 일부 확장 프로그램은 자체 인증서를 삽입하거나 요청 헤더를 수정하여 SSL 협상을 중단시킵니다.

chrome://extensions/로 이동하여 모든 확장 프로그램을 비활성화하고 페이지를 다시 로드하십시오. 오류가 사라지면 확장 프로그램을 하나씩 다시 활성화하여 원인을 찾으십시오. 가장 흔한 원인 확장 프로그램은: uBlock Origin(드물게), Avast Online Security, Norton Safe Web, HTTPS Everywhere입니다.

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

많은 백신 프로그램(Avast, Kaspersky, Bitdefender, ESET, Norton)에는 중간자 프록시 역할을 하여 암호화된 연결을 가로채는 "HTTPS 검사" 또는 "SSL 검사" 기능이 포함되어 있습니다. 이는 인증서 고정(certificate pinning)이나 최신 TLS 1.3 기능을 사용하는 사이트에서 특히 TLS 핸드셰이크를 중단시킬 수 있습니다.

백신 프로그램에서 Web Shield, HTTPS 검사, SSL 검사, 암호화된 연결 검사라는 이름의 설정을 찾아 일시적으로 비활성화하십시오. 오류가 해결되면 백신 프로그램의 제외 목록에 해당 도메인을 추가할 수 있습니다.

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

오래된 브라우저 버전은 최신 웹사이트에서 요구하는 TLS 프로토콜이나 암호화 제품군을 지원하지 못할 수 있습니다. Chrome은 정기적으로 보안 요구 사항을 업데이트합니다. 예를 들어 Chrome 98에서는 TLS 1.0과 1.1 지원을 완전히 중단했습니다.

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

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

오래된 DNS 레코드가 브라우저를 잘못된 서버나 유효한 SSL 인증서가 없는 오래된 IP 주소로 연결할 수 있습니다. DNS 캐시를 초기화하면 새로운 DNS 조회를 강제합니다.

# Windows (Command Prompt as Admin)
ipconfig /flushdns

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

# Linux
sudo systemd-resolve --flush-caches

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

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

해결 방법 9: 시크릿 모드 / 프라이빗 모드 사용

시크릿 모드는 깨끗한 브라우저 상태에서 시작합니다 — 캐시된 데이터, 쿠키, 확장 프로그램(시크릿 모드에서 명시적으로 허용하지 않은 경우)이 없습니다. 웹사이트가 시크릿 모드에서는 로드되지만 일반 모드에서는 로드되지 않으면, 브라우저 확장 프로그램, 캐시 데이터 또는 손상된 브라우저 프로필이 원인입니다.

시크릿 창을 엽니다: Ctrl+Shift+N (Chrome/Edge) 또는 Ctrl+Shift+P (Firefox). 같은 웹사이트로 이동합니다. 로드되면 브라우저 캐시를 삭제(해결 방법 3)하거나 확장 프로그램(해결 방법 5)을 확인하십시오.

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

VPN과 HTTP 프록시는 브라우저와 웹 서버 사이에 위치합니다. 일부 VPN은 HTTPS 트래픽을 검사하고, 자체 인증서를 삽입하거나, SSL 구성이 잘못된 서버를 통해 연결을 라우팅합니다. 기업 프록시는 종종 TLS 핸드셰이크를 중단시킬 수 있는 SSL 가로채기(백신 프로그램의 HTTPS 검사와 유사)를 사용합니다.

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

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

다른 방법이 모두 실패하면 네트워크 스택을 초기화하십시오. 이 작업은 DNS 설정, 프록시 구성, 소켓 연결을 포함한 모든 사용자 정의 네트워크 구성을 지우고 모든 것을 기본값으로 되돌립니다.

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

# Then restart your computer

# macOS — reset DNS settings
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

# Linux — restart NetworkManager
sudo systemctl restart NetworkManager

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

여러 사용자가 웹사이트에서 ERR_SSL_PROTOCOL_ERROR를 보고하는 경우 서버 측에 문제가 있습니다. 가장 흔한 서버 측 원인은 만료된 인증서, 누락된 중간 인증서, 오래된 TLS 구성입니다.

SSL 인증서 확인

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

ERR_SSL_PROTOCOL_ERROR를 유발하는 일반적인 인증서 문제:

• 만료된 인증서 — Let's Encrypt 인증서는 90일마다 만료됩니다. 자동 갱신이 실패하면(certbot cron이 실행되지 않거나 DNS 챌린지가 중단되면) 인증서가 조용히 만료됩니다.

• 잘못된 도메인 — 인증서가 example.com용으로 발급되었지만 사이트가 www.example.com으로 제공되는 경우(또는 그 반대). 인증서는 정확한 도메인과 일치하거나 와일드카드(*.example.com)를 포함해야 합니다.

• 자체 서명 인증서 — 개발용 인증서는 프로덕션 환경에서 브라우저가 신뢰하지 않습니다.

• 취소된 인증서 — 인증 기관이 인증서를 취소한 경우(키 유출, 잘못된 발급 또는 도메인 소유권 변경으로 인해).

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

# Check certificate chain completeness
openssl s_client -connect yourdomain.com:443 -servername yourdomain.com 2>/dev/null | grep -E "(depth|verify)"

# Renew Let's Encrypt certificate
sudo certbot renew --force-renewal

TLS 1.2 및 TLS 1.3 활성화

모든 최신 브라우저는 최소 TLS 1.2를 요구합니다. 서버가 TLS 1.0이나 1.1만 지원하면 브라우저가 연결을 거부하고 ERR_SSL_PROTOCOL_ERROR를 표시합니다. 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 on;

# 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 on

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

완전한 인증서 체인 설치

불완전한 인증서 체인은 ERR_SSL_PROTOCOL_ERROR의 흔하지만 진단하기 어려운 원인입니다. 서버는 SSL 인증서뿐만 아니라 인증서를 신뢰할 수 있는 루트 인증 기관에 연결하는 중간 인증서도 보내야 합니다. 이 인증서가 없으면 일부 브라우저와 기기에서 인증서를 확인할 수 없습니다.

대부분의 인증 기관은 "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가 설정되어 있고 이후 SSL 인증서에 문제가 생기면, 브라우저는 연결을 거부합니다. HTTP로 대체할 수 없고, 손상된 HTTPS가 ERR_SSL_PROTOCOL_ERROR를 유발합니다.

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

서버 구성 확인

잘못 구성된 웹 서버는 유효한 인증서가 있더라도 ERR_SSL_PROTOCOL_ERROR를 유발할 수 있습니다. 일반적인 서버 구성 오류는 다음과 같습니다:

• 잘못된 포트 — SSL/TLS는 포트 443에서 작동해야 합니다. 서버가 다른 포트에서 수신하면 브라우저가 핸드셰이크에 실패할 수 있습니다.

• 혼합 HTTP/HTTPS — HTTPS 페이지에서 일부 리소스를 HTTP로 제공하면 혼합 콘텐츠 경고가 발생하고 하위 리소스의 핸드셰이크가 중단될 수 있습니다.

• SNI(Server Name Indication) 미구성 — 여러 도메인이 하나의 IP 주소를 공유하는 경우, 서버는 각 도메인에 올바른 인증서를 제공하기 위해 SNI를 지원해야 합니다.

• 암호화 제품군 불일치 — 서버가 브라우저에서 수용하지 않는 암호화 제품군만 지원합니다. AES-GCM 및 ChaCha20과 같은 강력한 최신 암호화를 사용하십시오.

DNS Robot의 HTTP Headers Checker를 사용하여 서버의 응답 헤더를 검사하고 SSL 구성이 올바른 헤더를 보내고 있는지 확인하십시오.

Android에서의 ERR_SSL_PROTOCOL_ERROR

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

• 날짜 및 시간 확인 — 설정 → 시스템 → 날짜 및 시간 → "자동 날짜 및 시간"과 "자동 시간대"를 활성화합니다

• Chrome 데이터 삭제 — 설정 → 앱 → Chrome → 저장공간 → 캐시 삭제 (캐시 삭제로 해결되지 않으면 데이터 삭제)

• Chrome 업데이트 — Google Play 스토어를 열고 → 내 앱 → Chrome을 최신 버전으로 업데이트합니다

• 네트워크 자격 증명 삭제 — 설정 → 보안 → 자격 증명 삭제 (사용자가 설치한 모든 인증서가 제거됩니다)

• 네트워크 설정 초기화 — 설정 → 시스템 → 재설정 옵션 → Wi-Fi, 모바일 및 Bluetooth 재설정

• WebView 앱의 경우 — 개발자는 android:usesCleartextTraffic="false"가 설정되어 있고 네트워크 보안 구성이 올바른 인증 기관을 신뢰하도록 확인해야 합니다

다른 브라우저에서의 ERR_SSL_PROTOCOL_ERROR

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

오류가 모든 브라우저에서 동시에 나타나면, 시스템 전체(잘못된 날짜/시간, 백신 프로그램, 네트워크) 또는 서버 측(만료된 인증서, TLS 구성 오류) 문제입니다. 하나의 브라우저에서만 나타나면 해당 브라우저에 국한된 문제이므로, 해당 브라우저의 캐시와 SSL 상태를 삭제해 보십시오.

localhost에서의 ERR_SSL_PROTOCOL_ERROR (개발자용)

개발자는 로컬 개발 서버를 실행할 때 localhost sent an invalid response. ERR_SSL_PROTOCOL_ERROR를 자주 접합니다. 이는 브라우저가 HTTPS 연결에 유효한 SSL 인증서를 기대하지만 localhost는 자체 서명 인증서를 사용하거나 인증서가 없기 때문에 발생합니다.

• 로컬 개발에는 HTTP를 사용 — HTTPS가 특별히 필요한 경우가 아니라면 https://localhost:3000을 http://localhost:3000으로 변경하십시오

• 로컬 인증서 생성 — mkcert를 사용하여 로컬에서 신뢰할 수 있는 SSL 인증서를 생성합니다: mkcert -install && mkcert localhost 127.0.0.1

• Node.js — 개발 환경에서만 NODE_TLS_REJECT_UNAUTHORIZED=0을 설정합니다 (프로덕션에서는 절대 사용하지 마십시오)

• Chrome 플래그 — chrome://flags/#allow-insecure-localhost를 입력하고 "localhost에서 로드된 리소스에 대한 유효하지 않은 인증서 허용"을 활성화합니다

• Next.js / Vite / Webpack — 이러한 프레임워크는 개발 인증서를 자동 생성하는 --https 플래그를 지원합니다

관련 SSL/TLS 오류 코드

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

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