Clash 사용 후 인증서 오류가 뜰 때: NET::ERR_CERT 원인과 해결 방법

먼저 확인할 점: 인증서 오류는 일반적인 연결 시간 초과와 다릅니다

시스템 시간을 먼저 확인하고 인증서 정보를 기록한 뒤, 프록시와 TUN 경로를 비교하세요. 브라우저에 NET::ERR_CERT_AUTHORITY_INVALID가 표시되면 수신한 인증서의 신뢰성 검증에 실패했다는 뜻입니다. 노드 연결 시간 초과나 구독 만료와는 다른 문제입니다. 노드를 바꾸면 증상이 달라질 수 있지만, 인증서 점검을 대신할 수는 없습니다.

일반적인 Clash 또는 Clash Meta(mihomo) 프록시 연결은 보통 HTTPS 트래픽을 전달할 뿐, 대상 사이트용 인증서를 새로 발급하지 않습니다. HTTP 프록시를 사용하면 브라우저가 CONNECT로 터널을 만든 다음 대상 사이트와 TLS 핸드셰이크를 수행하며, 사이트 인증서는 브라우저가 계속 검증합니다. Clash 클라이언트를 정상적으로 사용하기 위해 이른바 ‘Clash 루트 인증서’를 설치할 필요는 없습니다.

우선 다음 5가지 정보를 기록하세요

주소창에 표시된 전체 도메인과 오류 페이지의 오류 코드. 공유할 때는 URL에서 토큰과 개인 식별 매개변수를 삭제하세요.
인증서 발급자, 유효 기간, 주체 대체 이름(SAN). 브라우저마다 오류 페이지의 고급 정보나 인증서 뷰어에서 확인할 수 있습니다.
문제 발생 범위: 도메인 하나인지, 같은 조직의 여러 도메인인지, 거의 모든 HTTPS 사이트인지 확인하세요.
Clash의 현재 모드와 실제 선택된 노드, 시스템 프록시 및 TUN 모드의 활성화 여부를 확인하세요.
문제가 발생하기 전에 패킷 캡처 도구를 켰는지, 보안 소프트웨어를 업데이트했는지, 호텔이나 공항처럼 인증이 필요한 네트워크에 연결했는지 확인하세요.

오류 코드로 점검 범위 좁히기

Chrome, Edge 등 Chromium 기반 브라우저는 오류 코드가 비슷하지만 Firefox에서는 표현이 다를 수 있습니다. 코드는 검증이 실패한 단계를 나타낼 뿐, 원인이 된 프로그램을 바로 특정하지는 않습니다. 먼저 아래 표를 확인한 다음 이어지는 단계를 진행하세요.

오류 코드	일반적인 의미	우선 점검 항목
`NET::ERR_CERT_DATE_INVALID`	인증서가 만료되었거나 아직 유효하지 않음, 또는 기기 시간이 잘못됨	시스템 날짜와 시간 동기화, 인증서 유효 기간
`NET::ERR_CERT_AUTHORITY_INVALID`	인증서 체인을 신뢰할 수 있는 루트 인증서까지 연결하지 못함	패킷 캡처 프록시, 보안 소프트웨어, 조직 인증서, 서버 중간 인증서 체인
`NET::ERR_CERT_COMMON_NAME_INVALID`	인증서에 포함된 이름과 접속 도메인이 일치하지 않음	주소 오타, DNS, hosts 파일, 인증 게이트웨이
`NET::ERR_CERT_REVOKED`	인증서가 폐기됨	사이트 인증서 상태, 발급 기관, 서버 인증서 갱신 여부

ERR_SSL_PROTOCOL_ERROR는 인증서 신뢰 오류가 아닐 수도 있습니다. 잘못된 포트 서비스, TLS 협상 실패, 네트워크 장비 간섭 등이 원인일 수 있습니다. SSL이 포함된 오류를 모두 ‘루트 인증서 누락’으로 단정하지 마세요.

1단계: 시스템 시간과 인증서 유효 기간 확인

기기 시간이 과거나 미래로 설정되면 유효한 인증서도 ‘아직 유효하지 않음’ 또는 ‘만료됨’으로 처리될 수 있습니다. 관련 없는 여러 사이트에서 날짜 오류가 동시에 발생한다면 규칙을 한꺼번에 수정하기보다 먼저 기기를 확인하세요.

Windows 11에서 ‘설정’ → ‘시간 및 언어’ → ‘날짜 및 시간’을 열고 ‘자동으로 시간 설정’을 확인한 뒤 ‘지금 동기화’를 클릭하세요. 날짜, 연도, 표시 시간이 모두 올바른지도 확인하세요.
macOS에서 ‘시스템 설정’ → ‘일반’ → ‘날짜 및 시간’을 열고 날짜 및 시간 자동 설정과 시간대 옵션을 확인하세요.
시간을 동기화한 후 브라우저를 완전히 종료했다가 다시 실행하고, 오류 페이지를 새로 고치는 대신 원래 주소를 다시 여세요.
사이트 하나에서만 계속 문제가 발생하면 해당 사이트 인증서의 유효 시작일과 종료일을 확인하세요. 서버 인증서가 실제로 만료되었다면 사이트 관리자가 갱신해야 합니다.

Windows 명령줄로 추가 확인

Get-Date
w32tm /query /status

아래 명령은 PowerShell에서 현재 시간과 Windows 시간 서비스 상태를 확인합니다. 서비스가 실행 중이 아니면 두 번째 명령에서 오류가 발생할 수 있습니다. 시간대는 표시 방식에 주로 영향을 주며, 인증서 검증은 실제 시스템 시간을 기준으로 합니다. 따라서 시간대만 바꾸고 연월일을 확인하지 않는 것은 피하세요. 기기의 전원이 끊길 때마다 시간이 초기화된다면 펌웨어 시간과 하드웨어 시계도 확인해야 합니다.

2단계: 패킷 캡처 프록시와 HTTPS 검사 확인

Charles, Fiddler 같은 디버깅 도구에서 HTTPS 복호화를 사용하면 도구의 로컬 루트 인증서로 서명한 사이트 인증서를 브라우저에 제공합니다. 일부 보안 소프트웨어의 HTTPS 검사와 기업 게이트웨이도 비슷한 방식으로 동작할 수 있습니다. 루트 인증서를 현재 브라우저가 신뢰하지 않거나 만료된 경우, 또는 도구를 제거한 뒤 프록시 설정이 남아 있는 경우 경고가 발생할 수 있습니다.

인증서 발급자부터 확인하세요

서로 다른 여러 사이트의 인증서가 같은 로컬 디버깅 도구나 조직 이름으로 발급되었다면 사이트 자체보다 중간 프록시를 먼저 확인하세요.
직접 설치한 패킷 캡처 도구와 HTTPS 복호화 기능을 잠시 끈 다음, 시스템 프록시가 아직 해당 도구의 수신 포트를 가리키는지 확인하세요.
Windows 11에서는 ‘설정’ → ‘네트워크 및 인터넷’ → ‘프록시’에서 수동 프록시를 확인할 수 있습니다. macOS에서는 ‘시스템 설정’ → ‘네트워크’ → 현재 연결 → ‘세부사항’ → ‘프록시’에서 확인하세요.
Clash에서 실제로 사용 중인 혼합 포트도 기록하세요. 7890은 흔히 쓰이는 예시일 뿐이며 다른 프로세스가 해당 포트를 사용할 수도 있습니다. 시스템 프록시 주소가 현재 클라이언트에 표시된 수신 주소와 일치해야 합니다.

개인 기기에서 브라우저 하나만 오류가 난다면 업데이트된 다른 브라우저로 비교해 볼 수 있습니다. 브라우저 버전, 루트 인증서 저장소, 관리 정책이 서로 다를 수 있습니다. 따라서 다른 브라우저에서 열린다는 사실은 검증 환경이 다르다는 뜻일 뿐, 이상한 인증서를 바로 신뢰해도 된다는 뜻은 아닙니다.

3단계: DNS, hosts 파일, 네트워크 인증 페이지 확인

DNS가 HTTPS 인증서를 발급하지는 않지만, 잘못된 이름 해석으로 연결이 엉뚱한 서버에 도달할 수 있습니다. 요청한 도메인과 다른 도메인의 인증서가 반환되면 이름 불일치 오류가 발생합니다. 공용 Wi-Fi의 인증 게이트웨이, 오래된 hosts 항목, 잘못된 DNS 매핑을 확인하세요.

인증 네트워크를 먼저 처리한 다음 이름 해석을 확인하세요

호텔이나 공항 Wi-Fi에 막 연결했다면 인증서 오류 페이지에 계정 정보를 입력하지 말고, 운영체제에서 제공하는 네트워크 로그인 페이지를 통해 먼저 인증하세요.
hosts 파일에 대상 도메인의 오래된 매핑이 있는지 확인하세요. Windows 파일 위치는 C:\Windows\System32\drivers\etc\hosts이고, macOS와 Linux에서는 보통 /etc/hosts입니다.
Windows에서는 아래 명령으로 시스템 DNS 조회 결과를 확인하고 시스템 캐시를 비울 수 있습니다. 캐시를 비운 뒤 브라우저를 다시 시작하고 Clash 자체의 DNS 캐시와 연결 상태도 확인하세요.

nslookup example.com
ipconfig /flushdns

example.com은 명령 형식의 예시입니다. 실제 점검에는 오류가 발생한 도메인을 사용하세요. nslookup의 조회 경로가 브라우저와 항상 같은 것은 아닙니다. 브라우저의 보안 DNS, 프록시 측 이름 해석, TUN DNS 하이재킹이 결과에 영향을 줄 수 있습니다. 명령 출력만으로 브라우저가 어느 IP 주소에 접속했는지 단정할 수는 없습니다.

Fake-IP 주소를 곧바로 오염된 주소로 판단하지 마세요

mihomo에서 Fake-IP 모드를 사용하면 애플리케이션에 198.18.0.0/16 범위의 매핑 주소를 반환한 뒤, 커널이 이를 원래 도메인과 연결할 수 있습니다. 이 범위는 흔히 사용되는 설정이지만 모든 클라이언트가 같지는 않습니다. 이런 주소가 보인다고 위조 사이트에 연결된 것은 아닙니다. 실제 적용 중인 설정의 dns.enhanced-mode, fake-ip-range, 연결 로그를 함께 확인하세요.

직접 연결에서만 잘못된 인증서가 반환되고 프록시로는 정상 접속되는 경우에 한해 로컬 이름 해석, 통신사 네트워크, 직접 연결 서버를 추가로 점검하세요. 테스트를 위해 HTTPS URL을 IP 주소로 바꾸지는 마세요. 인증서는 보통 도메인 이름을 기준으로 발급되므로 IP로 직접 접속하면 이름 불일치 오류가 생길 수 있습니다.

4단계: 시스템 프록시와 TUN 모드를 따로 검증

TUN 모드는 보통 네트워크 계층에서 트래픽을 처리하며, 그 자체로 TLS를 복호화하지는 않습니다. TUN을 켠 뒤에만 오류가 발생한다면 라우팅, DNS 처리, 규칙 매칭이 바뀌어 연결 경로가 달라졌을 가능성이 큽니다. 다른 VPN, 가상 네트워크 어댑터, 보안 소프트웨어와 충돌할 수도 있습니다.

한 번에 한 가지씩 순서대로 테스트

기준 상태 기록: 현재 모드, 노드, DNS 설정, 오류 인증서 정보를 저장하세요. 테스트 중에는 노드를 고정하고 구독을 업데이트하거나 규칙을 바꾸지 마세요.
시스템 프록시 테스트: TUN을 끄고 시스템 프록시를 켠 다음 브라우저를 완전히 종료했다가 다시 실행하세요. 확장 프로그램이나 조직 정책이 브라우저에 다른 프록시를 지정하지 않았는지도 확인하세요.
TUN 테스트: 시스템 프록시를 끄고 TUN을 켜세요. 같은 도메인과 노드를 사용하면서 Clash 연결 기록의 규칙, 아웃바운드 정책, 대상 정보를 확인하세요.
로컬 직접 연결 테스트: 시스템 프록시와 TUN을 끄고, 다른 VPN이나 수동 프록시도 연결을 가로채지 않는지 확인하세요. 연결을 새로 설정한 뒤 사이트가 열리는지만 보지 말고 인증서를 비교하세요.

TUN 경로에서만 실패하면 DNS 하이재킹, 다른 VPN, 가상 네트워크 어댑터 충돌부터 확인하세요. 시스템 프록시 경로에서도 실패한다면 인증서 발급자와 실제 노드를 중점적으로 비교하세요. 설정을 바꾸기 전에 백업하고 한 번에 한 항목만 수정하세요. 구독 업데이트가 직접 편집한 내용을 덮어쓸 수 있으므로, 지속적으로 적용할 설정은 클라이언트에서 지원하는 오버라이드 또는 병합 기능을 사용하세요. 구체적인 필드는 현재 mihomo 버전에 맞춰 확인해야 합니다.

curl로 연결 경로를 비교하고 검증 근거를 보관하세요

아래 예시는 로컬 HTTP 또는 혼합 프록시 포트 7890을 사용합니다. 명령을 실행하기 전에 클라이언트 설정에서 포트를 확인하세요. Windows PowerShell에서는 curl.exe를 사용하면 일부 환경에서 같은 이름의 별칭이 명령에 영향을 주는 일을 피할 수 있습니다.

curl.exe -Iv --proxy http://127.0.0.1:7890 https://example.com/
curl.exe -Iv --noproxy "*" https://example.com/

macOS와 Linux에서는 curl.exe 대신 curl을 사용하면 됩니다. 첫 번째 명령은 애플리케이션 계층 프록시를 명시적으로 지정하고, 두 번째 명령은 curl의 애플리케이션 계층 프록시 설정을 건너뜁니다. 두 번째 명령도 TUN이나 시스템의 다른 네트워크 계층 트래픽 처리를 우회하지는 않습니다. 로컬 직접 연결을 비교하려면 해당 기능을 먼저 꺼야 합니다.

TLS 검증 결과, 인증서 주체, 발급자를 비교하세요. 표시되는 인증서 정보의 범위는 curl 버전과 TLS 백엔드에 따라 다릅니다.
curl 오류 코드 60은 보통 인증서 검증 실패를 뜻합니다. 뒤에 표시되는 구체적인 원인도 확인해야 하며, 이를 곧바로 DNS 문제로 단정해서는 안 됩니다.
-k 또는 --insecure 옵션을 추가하지 마세요. 현재 점검 중인 인증서 검증 단계를 건너뛰게 됩니다.
curl과 브라우저는 서로 다른 신뢰 저장소를 사용할 수 있으므로 curl이 성공했다고 브라우저의 정책도 정상이라고 단정할 수는 없습니다. HEAD 요청에서 405가 반환되어도 TLS 핸드셰이크가 실패했다는 뜻은 아닙니다.

로그를 공유하기 전에 프록시 인증 정보, 쿠키, 구독 주소, 토큰이 포함된 요청 매개변수를 삭제하세요. 전체 설정 파일을 보내는 것보다 테스트 시간, 오류 코드, 인증서 발급자를 기록하는 편이 문제 해결에 더 도움이 되는 경우가 많습니다.

문제 범위에 따라 다음 단계를 선택하세요

모든 사이트에서 오류가 발생하는 경우

시스템 시간, 루트 인증서 업데이트, 패킷 캡처 도구, 네트워크 인증을 먼저 확인하세요. 운영체제와 브라우저를 지원되는 최신 상태로 유지하세요. 오래된 운영체제의 신뢰 저장소에는 새 인증서 체인이 없을 수 있습니다. 출처가 불분명한 루트 인증서 ‘복구 패키지’는 다운로드하지 마세요.

사이트 하나에서만 오류가 발생하는 경우

다른 기기와 다른 네트워크에서도 비교하세요. 두 환경 모두 같은 만료 인증서나 이름 오류를 표시하면 사이트 관리자에게 문의하세요. 특정 노드에서만 문제가 생기면 해당 노드와 인증서 정보를 기록하고, 신뢰할 수 있는 다른 노드로 바꿔 다시 테스트한 다음 서비스 제공업체에 알려 주세요.

복구 여부 확인 방법

문제가 발생했던 도메인과 서로 다른 사이트 두 곳 이상에서 정상적인 인증서 검증에 성공합니다.
인증서가 현재 접속 도메인을 포함하고 유효 기간이 적절하며, 출처가 불분명한 루트 인증서가 새로 추가되지 않았습니다.
일상적으로 사용하는 규칙 모드로 돌아온 뒤 연결 기록의 아웃바운드 정책이 예상대로 적용됩니다. 클라이언트와 브라우저를 다시 시작해도 결과가 동일합니다.

최종적으로 해결해야 하는 것은 브라우저 경고를 숨기는 일이 아니라 시간, 신뢰 체인, 이름 해석, 연결 경로의 구체적인 문제입니다. 모드와 구독 설정을 확인하려면 Clash 설정 안내서를, 클라이언트 설치와 초기 설정은 사용 가이드를 참고하세요.