Clash 실행 후 HTTPS 인증서 오류 원인 분석과 올바른 대처법
브라우저 인증서 경고와 프록시 사이의 실제 관계를 설명합니다. 노드 탈취, 시간 오차, 로컬 차단 프로그램 등 원인별로 구분하고 각 상황에 맞는 대처법을 안내합니다.
인증서 경고는 프록시 프로그램 자체가 만드는 게 아니다
브라우저가 "연결이 비공개로 설정되어 있지 않습니다" 또는 "인증서가 유효하지 않습니다"라는 경고를 처음 접하면 대부분 프록시 클라이언트를 먼저 끄려고 합니다. 이해할 수 있는 반응이지만 방향은 대체로 틀렸습니다. HTTPS 인증서 검증은 브라우저와 대상 웹사이트 사이에서 이루어지며, 인증서 체인이 신뢰할 수 있는 인증 기관(CA)에서 발급되었는지, 도메인이 일치하는지, 유효기간이 현재 시점을 포함하는지를 확인합니다. Clash나 Clash Meta(mihomo) 코어는 프록시 계층으로서 요청을 어느 노드로, 어떤 경로로 전달할지를 담당할 뿐, TLS 핸드셰이크 과정에서 전달되는 인증서 내용을 수정하지 않으며 수정할 수도 없습니다 — 중간에서 능동적인 트래픽 조작이 발생한 경우는 예외입니다.
즉 인증서 오류는 본질적으로 "브라우저가 이 인증서를 신뢰하지 않는다"는 뜻이며, 신뢰 체인이 깨지는 원인은 보통 세 가지 상황에서 발생합니다. 프록시 노드나 착지 네트워크 자체에 중간자 행위가 있는 경우, 로컬 시스템 시간과 네트워크 환경이 동기화되지 않아 인증서 유효기간 판단이 잘못되는 경우, 그리고 일부 보안 소프트웨어나 기업 게이트웨이가 로컬 단에 자체 서명 루트 인증서를 삽입해 트래픽을 검사하는 경우입니다. 이 세 가지 상황의 차이를 이해하는 것이 문제가 어느 계층에 있는지, 누구에게 확인해야 하는지를 판단하는 전제입니다.
자주 발생하는 세 가지 상황과 판단 방법
먼저 분류하고 나서 점검하는 방식이 클라이언트를 무작정 재설치하거나 노드를 자주 바꾸는 것보다 효율적입니다.
가장 주의해야 할 상황입니다. 브라우저가 인증서를 "신뢰할 수 없는 기관에서 발급했다" 또는 "인증서가 도메인과 일치하지 않는다"고 알리고, 인증서 세부 정보를 열어보면 발급자 이름이 낯설거나 해당 웹사이트가 평소 사용하는 CA가 아닌 경우(예: 은행이나 대형 플랫폼의 인증서는 보통 몇몇 잘 알려진 CA에서 고정적으로 발급됩니다), 트래픽이 대상 웹사이트에 도달하기 전에 어떤 중간 노드에 가로채져 위조 인증서로 재서명되었을 가능성이 있습니다 — 이것이 전형적인 TLS 중간자 탈취입니다. 이런 행위는 착지 서버가 위치한 네트워크 사업자 계층에서 발생할 수도 있고, 노드 자체가 트래픽을 능동적으로 탐지하도록 설정되어 있을 수도 있습니다.
점검 방법: 같은 웹사이트에서 다른 노드나 다른 구독 소스로 전환해 다시 시도해 봅니다. 노드를 바꾼 뒤 인증서가 정상으로 돌아온다면 문제가 원래 노드나 그 착지 회선에 있었음을 거의 확실히 확인할 수 있으며, 클라이언트나 로컬 설정 문제는 아닙니다. 이런 경우 해당 노드 사용을 중단해야 하며, 특히 로그인이나 결제가 관련된 상황에서는 계속 사용하지 않는 것을 권장합니다.
인증서에는 명확한 유효기간 범위가 있고, 브라우저는 로컬 시스템 시간이 이 범위 안에 있는지 확인합니다. 컴퓨터가 오랫동안 네트워크에 연결되지 않아 시간 동기화가 안 되었거나, 가상머신의 시계가 밀렸거나, 날짜를 수동으로 바꾼 적이 있어서 시간이 눈에 띄게 어긋나 있다면(단 몇 시간 차이라도 발효나 만료 시점에 가까운 인증서를 만나면 경고가 뜰 수 있습니다) "인증서가 아직 유효하지 않음" 또는 "인증서가 만료됨"이라는 알림이 나타납니다. 이는 프록시와 전혀 관계가 없으며 어떤 노드로 바꿔도 해결되지 않습니다.
점검 방법: 시스템 시간이 자동 동기화되어 있는지, 시간대가 올바른지 확인합니다. Windows에서는 "설정 → 시간 및 언어 → 날짜 및 시간"에서 시간 자동 설정을 켜고 "지금 동기화"를 한 번 눌러줍니다. 시간을 수정한 뒤 오류가 사라진다면 문제가 계속 로컬 시계에 있었다는 뜻이며 클라이언트나 구독을 의심할 필요가 없습니다.
일부 백신 프로그램, 자녀 보호 도구, 기업 네트워크 관리 정책은 시스템이나 브라우저의 인증서 저장소에 자체 루트 인증서를 설치해 HTTPS 트래픽 내용을 검사합니다. 이 과정도 본질적으로는 "합법적인" 중간자 행위이지만, 원격 노드가 아니라 로컬 단에서 발생한다는 점이 다릅니다. 인증서 세부 정보의 발급자 이름이 어떤 보안 소프트웨어 업체 이름이거나 기업 내부 인증 기관으로 표시된다면, 이 오류는 프록시 노드나 Clash 클라이언트와는 무관하며 해당 소프트웨어의 인증서 삽입 방식 때문입니다.
점검 방법: 관련 보안 소프트웨어를 잠시 종료하거나 기업 네트워크 연결을 끊은 뒤 같은 웹사이트에 다시 접속해 봅니다. 오류가 사라지면 문제가 로컬 소프트웨어 계층에 있는 것으로 확인되며, 해당 소프트웨어 설정에서 "HTTPS 트래픽 검사" 같은 옵션을 끄거나 그 인증서를 신뢰하도록 설정할 수 있습니다(해당 소프트웨어의 신뢰도를 먼저 판단해야 합니다).
TUN 모드에서는 인증서 문제가 어떻게 다르게 나타나는가
TUN 모드가 전체 트래픽을 인수한 뒤에는 점검 방향을 조금 조정해야 합니다.
Clash Meta(mihomo 코어)가 지원하는 TUN 모드는 시스템 네트워크 계층에 가상 네트워크 카드를 만들어 기기의 거의 모든 아웃바운드 트래픽을 프록시로 처리합니다. 브라우저나 수동으로 프록시를 설정한 앱만이 아닙니다. 즉 어떤 노드에 중간자 행위가 있으면 영향 범위가 "브라우저로 접속하는 웹사이트"에서 "이 가상 네트워크 카드를 통해 나가는 모든 TLS 연결"로 확대되며, 시스템 업데이트나 일부 클라이언트 소프트웨어의 API 요청 등도 포함됩니다. 이런 상황은 평소 사용자가 인증서 경고를 직접 확인하기 어려운데, 브라우저처럼 명확한 보안 알림을 띄우지 않고 그냥 연결 실패나 조용한 재시도로 나타나는 프로그램이 많기 때문입니다.
TUN 모드를 켠 뒤 특정 앱에서 연결 이상, 핸드셰이크 실패, 또는 이유 없는 로그인 상태 해제가 발생하고 시스템 프록시 모드(HTTP/SOCKS 프록시만 사용)에서는 정상 작동한다면, TUN 모드를 잠시 끄고 시스템 프록시 모드로 돌아가 다시 테스트해 보세요. 이 단계는 문제가 가상 네트워크 카드의 트래픽 인수 범위와 관련이 있는지, 노드 자체의 인증서 문제인지를 확인하는 데 도움이 됩니다. 일상적으로는 시스템 프록시 설정을 지원하지 않는 일부 클라이언트 소프트웨어처럼 정말로 전체 프록시가 필요한 경우에만 TUN 모드를 켜서 점검 범위를 줄이는 것을 권장합니다.
단계별 점검 순서
인증서 오류를 만났을 때는 여러 설정을 한꺼번에 바꾸지 말고 아래 순서대로 하나씩 배제하는 것을 권장합니다.
- 먼저 인증서 세부 정보의 발급자 이름과 유효기간을 확인해 "낯선 CA"인지 "유효기간 이상"인지 판단합니다. 이 단계로 상황을 노드 문제 또는 시간 문제 두 방향으로 빠르게 나눌 수 있습니다.
- 노드 문제로 의심된다면 다른 회선으로 전환해 같은 웹사이트를 다시 시도합니다. 노드를 바꾼 뒤 정상으로 돌아오면 원래 노드 사용을 중단하고 클라이언트 설정은 더 확인할 필요가 없습니다.
- 시스템 시간이 자동 동기화되어 있는지 확인합니다. 특히 오랫동안 네트워크에 연결되지 않은 컴퓨터나 가상머신은 시간을 한 번 수동으로 동기화한 뒤 다시 시도해 봅니다.
- HTTPS 검사 기능이 있는 보안 소프트웨어가 설치되어 있는지 확인하고, 해당 기능을 잠시 끈 뒤 다시 시도해 로컬 인증서 삽입이 원인인지 판단합니다.
- TUN 모드를 켜둔 상태라면 잠시 시스템 프록시 모드로 전환해 테스트하며 문제 발생 범위를 좁힙니다.
- 위 항목을 모두 배제했는데도 오류가 남아 있다면 브라우저 자체의 인증서 캐시 문제를 고려해, 브라우저의 HSTS 캐시와 인증서 캐시를 지운 뒤 다시 시도합니다.
코어 mihomo
TUN 모드 및 시스템 프록시 모드 적용
안심하고 넘길 수 있는 알림과 그렇지 않은 알림
모든 인증서 알림이 위험을 뜻하는 것은 아니지만, 민감한 작업에서는 위험을 감수하고 진행하지 않는 것이 좋습니다.
로그인 페이지, 결제 페이지, 계정 비밀번호 입력이 필요한 사이트에서 발급자가 낯설거나 도메인이 일치하지 않는 경고가 나타났다면, 먼저 작업을 멈추고 노드를 바꾸거나 프록시를 끄고 직접 연결로 테스트해 사이트 자체 인증서가 정상인지 확인한 뒤 계속하는 것을 권장합니다. 계정 정보가 탈취된 중간 노드를 거치는 것을 피해야 합니다.
일반적인 정보성 웹사이트를 방문할 때 인증서 경고가 노드를 바꾸거나 시스템 시간을 동기화한 뒤 사라졌다면 문제가 이미 특정되고 해결된 것이므로 추가로 걱정할 필요는 없습니다. 이런 일시적인 중간자 차단은 대체로 특정 착지 회선의 네트워크 환경과 관련이 있으며 노드를 바꾸면 정상적으로 접속할 수 있습니다.
자주 묻는 질문
왜 특정 웹사이트에서만 인증서 오류가 나고 다른 사이트는 정상인가요?
이런 경우는 대개 대상 웹사이트 자체의 인증서 설정 문제를 가리킵니다. 예를 들어 인증서가 곧 만료되거나, 인증서 체인이 불완전하거나, 해당 웹사이트의 특정 CDN 노드 설정이 잘못된 경우이며 프록시 소프트웨어와는 관련이 적습니다. 먼저 프록시를 잠시 끄고 직접 연결로 같은 웹사이트에 접속해 보세요. 직접 연결에서도 오류가 나면 문제가 완전히 웹사이트 쪽에 있으며 Clash와는 무관합니다.
브라우저 캐시를 지워도 인증서 오류가 여전히 남아 있으면 어떻게 더 확인할 수 있나요?
다른 브라우저로 같은 웹사이트를 테스트해 볼 수 있습니다. 새 브라우저에서도 같은 오류가 나타나면 문제가 브라우저 캐시 계층에 있지 않고 노드나 시스템 인증서 저장소 쪽일 가능성이 크므로, 앞서 설명한 상황별 점검 순서로 돌아가 하나씩 확인하면 됩니다.
TUN 모드를 끄면 인증서 문제가 사라지는데, 이는 TUN 모드 자체에 결함이 있다는 뜻인가요?
결함이 아니라 인수 범위가 다르기 때문에 나타나는 표현상의 차이입니다. TUN 모드는 더 많은 종류의 연결을 인수하기 때문에 특정 노드 회선에 문제가 있으면 영향을 받는 연결 수가 늘어나고 더 뚜렷하게 드러날 뿐이며, 문제의 근원은 여전히 노드에 있고 TUN 모드라는 기능 자체는 아닙니다.
Clash 클라이언트 받기
안정적인 노드 회선을 선택하고 올바른 로컬 설정을 병행해야 불필요한 인증서 경고와 연결 이상을 줄일 수 있습니다.