Clash 실행 후 인증서 오류 발생: NET::ERR_CERT 원인 및 해결 방법

인증서 오류 코드를 기록하고 계속 진행하지 마세요

Chrome이나 Edge에서 ‘연결이 비공개로 설정되어 있지 않습니다’라는 메시지가 표시되면 페이지 하단의 오류 코드를 먼저 확인하세요. NET::ERR_CERT_DATE_INVALID와 NET::ERR_CERT_AUTHORITY_INVALID는 점검할 항목이 서로 다르므로, 무조건 노드 문제로 단정하면 안 됩니다. 결제, 이메일, 회사 계정 또는 관리자 페이지라면 즉시 멈추고 비밀번호를 입력하지 마세요.

일반적인 Clash 및 Clash Meta(mihomo)의 프록시 중계는 대상 웹사이트의 인증서를 새로 발급하지 않습니다. 브라우저가 HTTP 프록시로 CONNECT 터널을 만들거나 TUN이 트래픽을 처리하더라도, HTTPS 연결은 대개 브라우저와 대상 웹사이트 사이에서 설정됩니다. 프록시를 사용하기 위해 출처가 불분명한 루트 인증서를 먼저 설치할 필요는 없습니다.

다음 네 가지를 기록하세요

주소와 오류 코드: 도메인과 필요한 경로만 기록하세요. 공유할 때는 로그인 토큰, 쿼리 매개변수, 개인정보를 삭제하세요.
영향 범위: 특정 웹사이트 하나만 실패하는지, 서로 관계없는 여러 HTTPS 사이트에서 동시에 발생하는지 확인하세요.
연결 경로: 시스템 프록시나 TUN이 켜져 있는지, 현재 어떤 정책 그룹과 실제 노드를 사용하는지 기록하세요.
인증서 정보: 오류 페이지나 브라우저의 인증서 보기 메뉴에서 발급자, 유효 기간, 주체 대체 이름(SAN)을 확인하세요. 메뉴 이름은 브라우저 버전에 따라 다를 수 있습니다.

NET::ERR_CERT 오류 코드로 원인 범위 좁히기

오류 코드	주요 원인	우선 확인할 항목
`NET::ERR_CERT_DATE_INVALID`	인증서가 아직 유효하지 않거나 만료되었거나, 기기 시간이 잘못되었을 수 있습니다.	시스템 날짜와 시간 동기화 상태, 인증서의 시작일과 만료일
`NET::ERR_CERT_AUTHORITY_INVALID`	브라우저가 신뢰할 수 있는 루트 인증서까지 검증 체인을 구성하지 못했습니다.	자체 서명 인증서, 누락된 중간 인증서, HTTPS 검사 소프트웨어, 루트 인증서 정책
`NET::ERR_CERT_COMMON_NAME_INVALID`	접속한 호스트 이름이 인증서에 포함된 이름과 일치하지 않습니다.	SAN, 잘못된 DNS 응답, 포털 리디렉션, 웹사이트 서버 설정
`NET::ERR_CERT_REVOKED`	인증서가 폐기된 것으로 판단되었습니다.	웹사이트 인증서 상태와 기기의 보안 소프트웨어를 확인하세요. 검증을 완화해 계속 접속하면 안 됩니다.

오류 이름에 포함된 COMMON_NAME이 인증서의 CN 필드만 확인한다는 뜻은 아닙니다. 최신 브라우저는 주로 SAN을 기준으로 호스트 이름을 검증합니다. 예를 들어 www.example.com에 접속했는데 인증서에 portal.example.net만 포함되어 있다면 호스트 이름 검증을 통과하지 못합니다.

ERR_SSL_PROTOCOL_ERROR와 ERR_TUNNEL_CONNECTION_FAILED는 위의 인증서 오류와 다른 유형입니다. 전자는 TLS 프로토콜 협상 중 발생할 수 있고, 후자는 프록시 터널이 연결되지 않은 경우일 수 있습니다. 이때는 대상 웹사이트의 인증서를 아직 받지 못했을 수도 있으므로 클라이언트 연결 기록과 로그부터 확인하세요.

날짜 오류: 시스템 시간을 먼저 맞춘 다음 웹사이트 인증서 유효 기간 확인

여러 웹사이트에서 동시에 NET::ERR_CERT_DATE_INVALID가 발생하면 작업 표시줄의 시간을 먼저 확인하세요. 기기를 오래 꺼 두었거나 배터리에 문제가 있거나 연도를 수동으로 변경하면 정상 인증서도 만료되었거나 아직 유효하지 않은 것처럼 표시될 수 있습니다. 시간대 표시가 다르다는 사실만으로 오류가 발생하는 것은 아닙니다. 중요한 것은 시스템의 실제 시간이 정확한지 여부입니다.

Windows 11: ‘설정’ → ‘시간 및 언어’ → ‘날짜 및 시간’에서 ‘시간 자동 설정’을 켜고 시간대를 확인한 다음, ‘추가 설정’에서 ‘지금 동기화’를 선택하세요.
macOS: ‘시스템 설정’ → ‘일반’ → ‘날짜 및 시간’에서 ‘시간 및 날짜 자동 설정’을 켜세요.
Android: 시스템 설정에서 ‘날짜 및 시간’을 검색하고 자동 설정을 켜세요. 메뉴 위치는 제조사마다 다를 수 있습니다.
시간을 맞춘 뒤 브라우저를 완전히 종료했다가 다시 열고 같은 주소에 접속하세요. 기기를 재시작할 때마다 시간이 다시 틀어진다면 시스템 동기화 서비스나 하드웨어 시계를 점검하세요.

시스템 시간이 정확한데 특정 웹사이트 하나만 실패한다면 해당 사이트 인증서의 유효 기간을 확인하세요. 인증서가 실제로 만료되었다면 웹사이트 운영자가 갱신해야 합니다. 노드를 바꾸면 우연히 다른 서버에 연결될 수는 있지만, 웹사이트의 인증서 문제를 해결해 주지는 않습니다. 실패한 도메인과 발생 시간, 인증서 유효 기간을 기록해 운영자에게 전달하는 편이 효과적입니다.

발급자가 낯선 경우: MITM, 패킷 캡처 도구, 보안 소프트웨어 잔여 설정 확인

서로 관계없는 여러 웹사이트의 인증서에 같은 낯선 발급자가 표시된다면 HTTPS 복호화를 수행하는 소프트웨어가 있는지 확인하세요. MITM은 중간자 방식으로 트래픽을 검사하는 것을 뜻합니다. 디버깅 프록시, 기업 게이트웨이, 일부 보안 소프트웨어는 로컬에서 신뢰하는 인증서로 사이트 인증서를 다시 발급할 수 있습니다. 이는 Clash의 일반적인 트래픽 중계와는 별개입니다.

인증서 재발급 기능을 먼저 끄고 인증서 출처를 확인하세요

Fiddler, Charles, mitmproxy 등 패킷 캡처 도구를 종료하고, 해당 도구에서 HTTPS 복호화 또는 SSL Proxying을 끄세요. 창만 닫아도 백그라운드 프로세스가 종료되지 않을 수 있습니다.
보안 소프트웨어의 HTTPS 검사나 암호화 연결 검사 기능을 확인하세요. 개인 기기라면 비교 테스트를 위해 해당 기능을 잠시 끌 수 있지만, 테스트 후 제품 안내에 따라 다시 설정하세요. 관리되는 기기라면 먼저 관리자에게 문의하세요.
Windows에서 Win + R을 누르고 certmgr.msc를 입력한 뒤, 현재 사용자의 ‘신뢰할 수 있는 루트 인증 기관’ → ‘인증서’를 확인하세요. 컴퓨터 수준의 인증서는 certlm.msc에서 볼 수 있습니다.
macOS에서 ‘키체인 접근’을 열고 ‘로그인’과 ‘시스템’ 키체인의 인증서 및 신뢰 설정을 각각 확인하세요.

루트 인증서가 남아 있다고 해서 반드시 인증서 재발급이 진행 중인 것은 아닙니다. 연결에는 해당 프록시나 검사 서비스도 관여해야 합니다. 반대로 인증서를 신뢰하도록 설정했더라도 재발급 서비스가 계속 실행 중이고 신뢰 인증서를 삭제했다면 발급 기관을 신뢰하지 않는 오류가 발생할 수 있습니다. 인증서 관리자에서 반복해서 인증서를 추가하거나 삭제하는 대신 프록시 설정, 실행 중인 프로세스, 인증서를 함께 확인하세요.

이름 불일치: DNS 이상, 네트워크 포털, 웹사이트 설정 구분하기

NET::ERR_CERT_COMMON_NAME_INVALID는 요청이 잘못된 서버로 전달되었을 때 흔히 발생하지만, 이 오류 하나만으로 DNS 변조나 노드 가로채기라고 단정할 수는 없습니다. 웹사이트 CDN 설정 오류, 공용 Wi-Fi 로그인 포털, IP 주소 직접 입력도 같은 오류를 일으킬 수 있습니다.

먼저 기기의 주소 재정의를 확인하고 실제 DNS 확인 경로를 살펴보세요

주소 표시줄에 입력한 도메인의 철자가 맞는지, HTTPS 도메인을 IP 주소로 바꾸지 않았는지 확인하세요. 인증서는 보통 도메인에 발급되며 서버 IP 주소까지 포함하지 않을 수 있습니다.
hosts 파일에 테스트용 주소 매핑이 남아 있는지 확인하세요. Windows 경로는 C:\Windows\System32\drivers\etc\hosts이고, macOS와 Linux에서는 /etc/hosts입니다. 수정하기 전에 복사본을 보관하세요.
공항이나 호텔 등에서 네트워크를 사용할 때는 시스템의 네트워크 로그인 안내를 통해 먼저 포털 인증을 완료하세요. 대상 HTTPS 사이트로 위장한 인증서 오류 페이지에 포털 비밀번호를 입력하지 마세요.
브라우저에서 보안 DNS를 사용하면 시스템과 다른 경로로 도메인을 확인할 수 있습니다. Chrome의 ‘설정’ → ‘개인 정보 보호 및 보안’ → ‘보안’에서 ‘보안 DNS 사용’을 확인하세요. 비교 테스트를 위해 임시로 변경할 때는 기존 설정을 기록해 두세요.

Windows에서는 아래 명령으로 시스템 기본 DNS 확인 결과를 볼 수 있습니다. hosts 파일이나 시스템 DNS를 수정한 뒤에는 시스템 캐시를 비우세요. 아래 도메인은 명령 예시이므로 문제를 확인할 때 실제 오류가 발생한 도메인으로 바꿔야 합니다.

nslookup example.com
ipconfig /flushdns

nslookup만으로 브라우저가 실제로 어떤 IP 주소를 사용했는지 단정할 수는 없습니다. mihomo의 TUN, DNS 가로채기 또는 fake-ip를 사용하면 조회 경로가 변경될 수 있습니다. fake-ip 모드에서 198.18.0.0/16 범위의 가상 주소가 반환되는 것도 반드시 이상 징후는 아닙니다. 현재 설정의 dns, enhanced-mode, fake-ip-range와 클라이언트 연결 기록을 함께 확인하세요.

DNS를 바꾸고, 노드를 교체하고, 캐시를 지우는 작업을 한꺼번에 하지 마세요. 한 번에 한 항목만 바꾸고 기존 연결을 끊은 뒤 다시 테스트하세요. CDN이 네트워크에 따라 서로 다른 IP를 반환하는 일은 흔하므로, IP가 다르다는 이유만으로 변조를 의심할 수는 없습니다. 여기서 확인할 핵심은 인증서가 요청한 도메인을 포함하는지 여부입니다.

직접 연결과 노드 연결을 비교해 프록시 경로 문제 확인하기

프록시를 켠 뒤에만 문제가 발생한다면 조건을 통제해 비교해 보세요. 로그인할 필요가 없는 공개 페이지를 골라 같은 도메인에 직접 연결했을 때, 노드 A를 사용할 때, 노드 B를 사용할 때의 결과를 기록하세요. 자동 선택 정책 그룹을 사용하면 실제 노드가 바뀔 수 있으므로 그룹 이름만 적지 말고 연결 기록에서 최종 출구 노드를 확인해야 합니다.

현재 상태 저장: 현재 설정과 규칙 모드, 시스템 프록시 및 TUN 상태를 기록하세요. 연결 경로가 겹치지 않도록 다른 VPN이나 패킷 캡처 프록시는 먼저 중지하세요.
직접 연결 테스트: Clash의 시스템 프록시와 TUN을 끄세요. 시스템에 수동 프록시나 자동 구성 스크립트가 남아 있지 않은지 확인한 다음 클라이언트를 종료하고 브라우저를 다시 여세요. 클라이언트를 종료해도 모든 프록시 설정이 자동으로 해제되는 것은 아닙니다.
프록시 테스트: 기존 설정을 복원하고 고정 노드로 같은 도메인에 접속한 뒤, 연결 기록에서 적용된 규칙과 출구 노드를 확인하세요.
변수 하나만 변경: 규칙과 DNS 설정은 그대로 두고 신뢰할 수 있는 다른 노드 하나로 바꾼 뒤 인증서 이름, 발급자, 오류 코드를 비교하세요.

명령줄로 비교할 때는 로컬 포트를 명시하세요

아래는 클라이언트에 HTTP 또는 혼합 포트가 7897로 표시된 경우의 Windows 예시입니다. 실제 포트는 클라이언트에서 확인하세요. 명시적 프록시 테스트에서는 TUN을 꺼야 ‘직접 연결’이 투명하게 가로채이지 않습니다. macOS와 Linux에서는 보통 명령어 이름을 curl로 바꾸면 됩니다.

curl.exe -I -v --connect-timeout 10 --max-time 20 --noproxy "*" https://example.com/
curl.exe -I -v --connect-timeout 10 --max-time 20 --noproxy "" --proxy http://127.0.0.1:7897 https://example.com/

첫 번째 명령은 명시적 프록시를 우회하고, 두 번째 명령은 로컬 HTTP 프록시를 지정합니다. 이번에 확인할 인증서 검증을 건너뛰게 되므로 -k 또는 --insecure를 추가하지 마세요. -I는 HEAD 요청을 보냅니다. 일부 사이트에서 405를 반환해도 인증서 오류라는 뜻은 아닙니다. HTTP 응답을 받았다면 해당 연결의 TLS 검증 단계는 대개 통과한 것입니다.

curl과 브라우저는 신뢰 저장소와 프록시 경로가 다를 수 있으므로, 명령이 성공해도 브라우저 테스트를 대신할 수 없습니다. -v 출력 내용을 공유하기 전에 인증 헤더, 쿠키, 내부 네트워크 주소 등 민감한 정보를 삭제하세요. 테스트를 위해 구독 링크를 명령줄이나 공개 검사 사이트에 붙여 넣지 마세요.

비교 결과에 따라 다음 단계를 선택하세요

직접 연결은 정상이고 특정 노드만 실패: 해당 노드를 사용 중지하고 오류 도메인, 발생 시간, 인증서 발급자, 오류 코드를 전달하세요. 관계없는 웹사이트에서도 같은 비정상 인증서가 반복해서 나타나면 연결 경로가 리디렉션되거나 가로채였을 가능성을 의심할 수 있지만, 증거를 바탕으로 확인해야 합니다.
모든 노드와 직접 연결에서 실패: 시스템 시간, 기기의 HTTPS 검사, 루트 인증서, 현재 네트워크를 먼저 점검하세요. 구독을 계속 바꾸지 마세요.
여러 네트워크에서 특정 웹사이트 하나만 실패: 인증서 체인, 만료 인증서 갱신 또는 CDN 연결을 웹사이트 측에서 처리해야 할 가능성이 큽니다.
브라우저에서는 실패하고 명령줄에서는 성공: 브라우저 확장 프로그램, 정책, 보안 DNS, 별도의 인증서 설정을 확인하세요. Firefox의 신뢰 설정은 Chromium 기반 브라우저와 다를 수 있습니다.

설정 복원 및 재테스트: 검증 건너뛰기를 설정에 남기지 마세요

설정의 skip-cert-verify: true는 브라우저 인증서 오류를 해결하는 범용 방법이 아닙니다. TLS를 사용하는 프록시 프로토콜에서 이 항목은 보통 브라우저가 아닌 프록시 서버 인증서를 커널이 검증할지 제어합니다. 이를 변경하면 노드 연결의 신원 검증이 약해질 수 있지만, 웹페이지 인증서의 도메인, 유효 기간, 신뢰 체인 문제는 해결되지 않습니다.

TUN도 주로 트래픽을 처리하는 경로를 바꿀 뿐, 웹사이트의 인증서를 발급하지는 않습니다. TUN을 켰을 때만 문제가 생긴다면 트래픽이 다른 노드를 경유하는지, DNS가 가로채이는지, 다른 VPN과 충돌하는지 확인하세요. 시스템에 인증서를 곧바로 설치하지 마세요.

임시로 변경한 보안 DNS, 보안 소프트웨어 검사 기능, 정책 그룹 설정을 확인된 원래 값으로 복원하세요.
브라우저를 완전히 재시작한 뒤, 이전에 오류가 발생한 도메인과 정상적으로 열리는 다른 도메인을 각각 테스트하세요.
시스템 시간 동기화가 정상인지, 오류 페이지가 더 이상 나타나지 않는지, 연결 기록의 규칙과 노드가 예상대로인지 확인하세요.
인증서가 비정상인 페이지에서 계속 진행해 비밀번호를 입력했다면 신뢰할 수 있는 기기와 네트워크에서 비밀번호를 변경하고 로그인 세션을 확인하세요. 계정 서비스의 보안 절차도 따르세요.

인증서 오류는 전체 오류 코드 확인, 시스템 시간 점검, 인증서 발급자와 이름 확인, 직접 연결과 노드 연결 비교 순서로 처리하면 됩니다. 이 과정을 따르면 기기의 신뢰 설정 문제, 웹사이트 설정 문제, 프록시 경로 문제를 구분할 수 있어 설정을 바꾸거나 검증을 끄며 반복해서 시험하는 일을 줄일 수 있습니다.