Clash 실행 후 브라우저에서 HTTPS 인증서 오류가 발생하는 원인 분석과 해결 방법

프록시가 인증서 검증과 관련되는 이유

HTTPS 연결의 인증서 검증은 TLS 핸드셰이크 단계에서 클라이언트(브라우저 또는 시스템)에 의해 수행되며, 프록시 사용 여부와 직접적인 인과관계가 없습니다. 프록시는 데이터 패킷을 목적지 서버로 전달하는 역할만 하고, 인증서는 서버가 반환하고 클라이언트가 검증하는 대상입니다. 대부분의 경우 Clash 또는 Mihomo 코어는 순수 전달 모드로 동작합니다. 규칙에 따라 TCP/UDP 트래픽을 해당 노드로 분산 전송할 뿐, 전송 계층의 데이터를 해체하거나 인증서를 재발급하지 않으므로 브라우저가 보는 것은 여전히 웹사이트 서버 자체의 인증서 체인입니다. 이 모드에서 프록시를 켜서 발생하는 인증서 오류는 거의 전부 "프록시가 연결 경로를 바꿔서 원래 숨겨져 있던 다른 문제가 드러난 것"이며, 프록시 자체가 인증서를 위조한 것이 아닙니다.

다만 예외도 있습니다. 일부 클라이언트는 요청 상세 내용을 보거나 규칙을 디버깅하기 위한 "HTTP 패킷 캡처/MITM 복호화" 기능을 제공합니다. 이 기능은 로컬에서 생성한 루트 인증서를 사용하며, 프록시 프로세스가 이를 이용해 복호화된 연결에 인증서를 재발급한 뒤 다시 전달합니다. 이 스위치가 켜져 있는데 해당 루트 인증서가 시스템이나 브라우저의 신뢰 목록에 등록되지 않았다면, 검증 단계에서 인증서 체인이 곧바로 실패하며 "신뢰할 수 없는 발급자" "알 수 없는 기관이 발급한 인증서" 같은 메시지가 표시됩니다. 이는 프록시 소프트웨어 자체의 인증서 메커니즘이 직접 오류를 유발하는 유일한 경우이며, 이를 구분하는 것이 문제 확인의 첫 단계입니다.

문제 확인 전에 점검할 세 가지

구체적인 상황을 살펴보기 전에, 아래 세 가지를 순서대로 확인하면 문제 범위를 빠르게 좁힐 수 있습니다.

1. 시스템 시간과 시간대가 정확한지

   TLS 인증서 검증은 현재 시스템 시간과 인증서 유효 기간을 비교합니다. 시스템 시간이 인증서 유효 시작 시점보다 이르거나 만료 시점보다 늦으면 프록시와 무관하게 인증서가 무효로 판정됩니다. 네트워크 시간 자동 동기화를 켜거나 시간과 시간대를 직접 확인하는 것은 가장 자주 간과되지만 흔한 원인 중 하나입니다.

2. 프록시가 시스템 수준인지 브라우저 수준인지

   시스템 프록시 모드에서는 모든 앱의 트래픽이 프록시 규칙 판단을 거치지만, 브라우저 확장 프록시만 사용할 경우 다른 앱은 영향을 받지 않습니다. 브라우저에서만 인증서 오류가 발생하고 다른 프로그램에서 같은 사이트에 정상 접속된다면, 문제 범위는 브라우저 확장이나 브라우저 자체의 프록시 설정으로 좁혀야 하며 Clash 클라이언트 문제가 아닙니다.

3. 노드나 구독을 방금 전환했는지

   새 구독을 가져오거나 새 노드로 전환한 직후 인증서 오류가 발생한다면, 해당 노드 서버 측에서 하이재킹, 인증서 변조, 강제 리디렉션 같은 동작을 하는지 확인해야 합니다. 이런 문제는 대개 특정 노드에서만 발생하므로, 다른 노드로 바꿔 같은 사이트에 접속해 보면 바로 확인됩니다.

자주 발생하는 상황별 분석

상황 1: 공공 네트워크의 포털 하이재킹(Captive Portal)

공항, 호텔, 학교 등의 공공 Wi-Fi에서는 "먼저 로그인해야 인터넷을 사용할 수 있는" 포털 페이지 방식이 흔합니다. 네트워크 계층에서 인증을 완료하기 전 모든 HTTPS 요청을 가로채 자체 로그인 페이지의 인증서를 반환하는데, 이는 목적지 사이트의 실제 인증서와 전혀 일치하지 않아 브라우저가 신뢰할 수 없는 것으로 판단합니다. 이 경우 먼저 프록시를 끄고 포털 로그인 절차를 완료한 다음, 임의의 사이트에 정상 접속되는지 확인한 뒤 프록시를 다시 켜면 오류가 보통 사라집니다. 프록시를 켠 상태에서 로그인 페이지가 전혀 뜨지 않는다면, 임시로 프록시를 끄고 인증을 완료한 후 다시 프록시를 켜서 사용하면 됩니다.

상황 2: MITM 복호화 스위치가 실수로 켜진 경우

앞서 설명한 대로, 클라이언트의 패킷 캡처/재작성 기능이 켜져 있는데 해당 루트 인증서가 시스템 또는 브라우저 신뢰 목록에 설치되지 않았다면 거의 모든 HTTPS 사이트에서 오류가 발생합니다. 이는 특정 한두 사이트에 국한되지 않는 "전면적인" 현상으로 나타납니다. 해결 방법은 클라이언트 설정에서 패킷 캡처나 재작성 관련 옵션을 찾아 끄거나, 클라이언트 안내에 따라 해당 루트 인증서를 설치하고 신뢰하도록 등록하는 것입니다. 일상적으로 분산 프록시만 사용하고 요청 내용을 확인할 필요가 없다면 이 기능을 꺼두는 것이 더 편리합니다.

상황 3: 인증서 체인 불완전

일부 자체 구축 프록시 노드나 자체 서명 인증서를 사용하는 서비스는 중간 인증서 설정이 누락되어 있어, 브라우저가 리프 인증서까지는 검증하지만 루트 인증서까지 이어지는 완전한 체인을 채우지 못합니다. 이때는 "알 수 없는 발급자" 또는 "인증서 체인이 불완전함" 같은 오류 메시지가 자주 나타납니다. 이는 서버 측 설정 문제로 로컬 Clash 클라이언트 설정과는 무관합니다. 다른 노드로 같은 사이트에 접속해 비교해 보고, 특정 노드에서만 발생한다면 해당 노드 자체의 인증서 설정 문제이므로 다른 회선으로 전환하거나 구독 제공처에 문의하는 것이 좋습니다.

상황 4: DNS 오염 또는 하이재킹으로 잘못된 서버에 연결되는 경우

도메인 해석이 위조된 주소로 가로채졌다면, 해당 주소가 반환하는 인증서는 당연히 목적지 사이트의 실제 인증서와 일치하지 않습니다. 판단 방법은 프록시를 켜고 규칙을 "원격 해석"(로컬 DNS가 아닌 프록시 서버가 DNS 조회를 수행하는 방식)으로 설정한 상태에서 다시 접속해 보는 것입니다. 오류가 사라지면 로컬 네트워크의 DNS 환경에 문제가 있다고 거의 확신할 수 있고, 여전히 오류가 발생하면 상황 1~3으로 돌아가 계속 확인하면 됩니다.

플랫폼별 구체적인 처리 단계

문제 유형을 확인한 뒤에는 아래 플랫폼별 단계에 따라 순서대로 진행하면 됩니다.

Windows / macOS

1. 시스템 시간 확인

   시스템 설정의 날짜 및 시간 옵션을 열어 "시간 자동 설정"이 켜져 있는지, 시간대가 실제 위치와 일치하는지 확인합니다.

2. 클라이언트의 복호화 관련 기능 끄기

   Clash 또는 Mihomo 클라이언트의 연결/스크립트 설정에서 패킷 캡처, 재작성, MITM 관련 스위치를 찾아 꺼져 있는지 확인합니다. 실제로 요청 내용을 디버깅해야 하는 경우가 아니라면 꺼두는 것이 좋습니다.

3. 노드를 전환해 비교 테스트

   같은 브라우저 탭에서 다른 사용 가능한 노드로 전환한 뒤 오류가 발생한 사이트에 다시 접속해, 문제가 노드에 따라 달라지는지 확인합니다.

Android / iOS

1. 시스템 프록시와 VPN 모드의 충돌 확인

   모바일 클라이언트는 대부분 로컬 VPN 인터페이스를 통해 트래픽을 인수합니다. 다른 프록시 앱을 동시에 설치했다면 서로 간섭해 연결이 비정상적으로 동작할 수 있으므로, 확인 중에는 프록시 앱을 하나만 실행 상태로 두는 것이 좋습니다.

2. 자동 시간 동기화가 켜져 있는지 확인

   모바일 기기의 시스템 설정에도 "날짜와 시간 자동 설정" 옵션이 있으며, 꺼두면 시간 오차가 쉽게 발생합니다.

3. 앱 재시작 또는 구독 다시 가져오기

   노드를 바꿔도 해결되지 않으면 클라이언트 앱을 재시작하거나, 구독을 삭제한 뒤 링크를 다시 가져와 로컬 캐시 설정 이상 가능성을 배제해 봅니다.

TUN 모드에서의 인증서 오류는 별도로 봐야 합니다

TUN 모드는 시스템 네트워크 계층에 가상 네트워크 인터페이스를 만들어 전역 트래픽(애플리케이션 수준 프록시 설정을 우회하는 프로그램 포함)을 인수합니다. 이 인수 방식 자체는 인증서 재발급과 관련이 없어, 원리상 추가적인 인증서 문제를 일으키지 않습니다. 하지만 TUN 모드에서는 트래픽 경로 변경이 더 철저해서, 원래 시스템 프록시 규칙에서 제외되던 앱(예: 일부 백그라운드 서비스나 시스템 구성 요소의 네트워크 요청)도 프록시 경로에 포함될 수 있습니다. 이 요청들이 해당 노드 범위 내에서 설정이 불완전한 분산 규칙에 걸리면 앞서 언급한 인증서 체인이나 DNS 해석 문제가 마찬가지로 드러날 수 있습니다. 확인 방법은 앞과 동일하며, 우선 TUN 모드를 임시로 끄고 시스템 프록시 모드로 돌려 같은 사이트에서 테스트해 보면 오류가 트래픽 인수 범위 확대와 관련이 있는지 판단할 수 있습니다.

문제가 인증서 자체가 아니라 규칙 설정에 있는 경우

인증서 오류로 오인하기 쉬운 현상이 하나 있습니다. 특정 사이트가 규칙에 의해 해당 사이트 접속에 적합하지 않은 노드로 잘못 분산되어, 서버가 예상치 못한 응답(예: 통신사의 차단 페이지)을 반환하는 경우입니다. 브라우저가 이 예상치 못한 응답을 해석할 때도 연결이 안전하지 않다는 알림이 표시되지만, 근본 원인은 라우팅 규칙이며 인증서 검증 로직 자체의 문제는 아닙니다. 이런 경우 구독이나 로컬 설정 파일에서 해당 도메인이 매칭되는 정책 그룹을 확인하고, 해당 노드가 사용 가능한지, 정책 그룹의 속도 테스트 결과가 정상인지 확인하는 것이 인증서 세부사항을 파고드는 것보다 빠르게 문제를 찾는 방법입니다. 규칙 설정의 문법과 필드 설명은 전체 문서의 규칙 섹션을 참고하시기 바랍니다.

전체적으로 HTTPS 인증서 오류를 확인하는 방식은 먼저 요소를 하나씩 제외하는 것입니다. 프록시를 꺼서 문제가 사라지는지 확인하고, MITM 관련 기능을 꺼서 복호화와 관련이 있는지 확인하고, 노드를 전환해 특정 회선과 관련이 있는지 확인하고, DNS 해석 방식을 바꿔 로컬 네트워크 오염과 관련이 있는지 확인합니다. 각 단계마다 하나의 원인 범주를 배제할 수 있으므로, 대개 네 단계 이내에 문제를 찾아낼 수 있으며 무작정 추측할 필요가 없습니다.