프록시 사용 후 브라우저에 HTTPS 인증서 오류가 뜬다면? 원인 분류와 Clash 관련 점검 절차

인증서 오류 메시지의 유형과 의미

브라우저가 표시하는 인증서 오류는 종류가 다양해 보이지만 실제로는 몇 가지 방향으로 정리됩니다. 인증서가 신뢰되지 않음(NET::ERR_CERT_AUTHORITY_INVALID), 인증서 만료 또는 아직 유효하지 않음(NET::ERR_CERT_DATE_INVALID), 도메인 불일치(NET::ERR_CERT_COMMON_NAME_INVALID), 그리고 연결 하이재킹류의 일반적인 경고가 대표적입니다. 이런 메시지는 브라우저가 TLS 핸드셰이크 단계에서 서버 인증서 체인이 신뢰할 수 있는지, 유효 기간 내인지, 접속 도메인과 일치하는지를 검증하는 정상적인 동작입니다. 프록시를 켜기 전에는 나타나지 않고 켠 후에만 자주 나타난다면, 문제는 로컬 시간, DNS 해석 경로, 또는 인증서 신뢰 체인에 있을 가능성이 높으며 대상 웹사이트 자체의 문제는 아닐 확률이 큽니다.

이런 문제를 점검할 때는 먼저 다음을 명확히 기록해 두어야 합니다. 모든 웹사이트에서 오류가 나는지, 일부 웹사이트에서만 나는지; 모든 노드에서 오류가 나는지, 노드를 바꾸면 사라지는지; 프록시를 끄면 즉시 정상으로 돌아오는지, 프록시를 꺼도 계속 나타나는지. 이 세 가지 대조만으로 문제 범위를 시스템 계층, 프록시 계층, 로컬 소프트웨어 계층 중 어디인지 빠르게 좁힐 수 있습니다.

시스템 시간 오차로 인한 인증서 오류

TLS 인증서 검증은 현재 시스템 시간이 인증서 유효 기간 범위 내에 있는지를 확인합니다. 기기 시간이 실제 시간과 몇 분 이상 차이가 나면, 인증서 자체가 완전히 정상이더라도 검증 과정에서 "아직 유효하지 않음" 또는 "이미 만료됨"으로 판정될 수 있습니다. 이런 상황은 가상 머신, 듀얼 부팅, 장시간 절전 후 재부팅한 기기에서 특히 자주 발생하며 프록시 사용 여부와는 직접적인 관계가 없지만, 노드를 전환하거나 클라이언트를 재시작한 뒤에야 발견되는 경우가 많아 노드 문제로 오인하기 쉽습니다.

1. 시스템 시간 자동 동기화 여부 확인

   Windows는 「설정 → 시간 및 언어」에서 「자동으로 시간 설정」이 켜져 있는지 확인하고, macOS는 「시스템 설정 → 일반 → 날짜 및 시간」에서 자동 설정이 체크되어 있는지 확인합니다.

2. 시간대를 수동으로 확인

   시간 동기화는 켜져 있어도 시간대가 잘못 설정되어 있으면 인증서 유효 기간 판정에 오차가 생길 수 있습니다. 특히 지역 설정을 최근에 변경한 기기에서 주의해야 합니다.

3. 강제로 재동기화

   자동 동기화를 끈 뒤 다시 켜거나, 시스템 시간 서비스에서 동기화를 직접 실행해 로컬 시간을 네트워크 시간 서버와 즉시 맞춥니다.

노드 하이재킹과 중간자 위험

특정 노드로 전환했을 때만 인증서 오류가 발생하고 다른 노드로 바꾸면 즉시 정상으로 돌아온다면, 이 신호는 신중하게 다뤄야 합니다. 정상적인 프록시 전달은 TLS 핸드셰이크 과정에 개입하지 않습니다. 클라이언트와 대상 웹사이트 사이에는 종단 간 암호화 연결이 구성되며, 중간의 프록시 서버는 암호화된 패킷을 전달하는 역할만 하고 이론적으로 인증서를 확인하거나 교체할 권한도 필요도 없습니다. 만약 어떤 노드의 출구에서 트래픽 계층의 중간자 개입—예를 들어 자체 서명 인증서를 삽입해 트래픽을 복호화하는 방식—이 이루어지고 있다면, 브라우저는 즉시 인증서가 신뢰되지 않는다는 오류를 표시합니다. 제시된 인증서의 발급자가 시스템이 신뢰하는 루트 인증서 목록에 전혀 존재하지 않기 때문입니다.

이런 상황은 출처가 불명확하거나 지나치게 저렴한 무료 노드, 검증되지 않은 서드파티 공유 노드에서 자주 발생하며, 정식 서비스의 신뢰할 수 있는 노드에서는 거의 나타나지 않습니다. 점검 방법은 다음과 같이 직관적입니다.

• 오류가 발생했을 때 사용 중이던 노드 이름을 기록하고, 같은 구독의 다른 노드로 전환해 재현 여부를 확인합니다.
• 오류 상세 정보에 표시되는 인증서 발급자(브라우저 주소창의 자물쇠 아이콘 → 인증서 정보)를 확인합니다. 발급자가 해당 웹사이트가 원래 사용하는 유명 인증기관이 아니라 낯선 자체 구축 CA라면, 노드 계층의 중간자 행위임을 거의 확신할 수 있습니다.
• 문제 노드를 확인한 뒤 클라이언트에서 선택 그룹에서 제외하고, 신뢰할 수 있는 구독으로 교체합니다.

TUN 모드에서의 DNS 오염 폴백 문제

TUN 모드는 시스템의 모든 네트워크 트래픽을 가져가며, DNS 조회 요청도 포함됩니다. Clash Meta(mihomo) 코어는 TUN 모드에서 보통 자체 DNS 해석 로직을 활성화하고, 암호화 DNS(DoH/DoT 등)를 우선 사용하면서 fake-ip 또는 redir-host 정책을 함께 적용해 로컬 네트워크의 DNS 하이재킹·오염을 피합니다. 하지만 설정에 빠진 부분이 있으면—예를 들어 enhanced-mode가 제대로 활성화되지 않았거나 nameserver 목록에 오염되기 쉬운 일반 DNS 서버가 섞여 있으면—시스템이 TUN 모드에서 해석에 실패했을 때 조용히 로컬 기본 DNS로 폴백할 수 있습니다. 로컬 기본 DNS가 오염된 네트워크 환경에 있다면 해석된 IP가 잘못된 서버를 가리키게 되고, 해당 서버는 당연히 대상 도메인에 맞는 정상 인증서를 제시할 수 없어 브라우저가 도메인 불일치 또는 신뢰할 수 없는 인증서 오류를 표시하게 됩니다.

dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - https://doh.example.net/dns-query
    - https://1.1.1.1/dns-query
  fallback:
    - https://dns.google/dns-query
tun:
  enable: true
  stack: system
  dns-hijack:
    - any:53

설정을 확인할 때는 세 가지를 중점적으로 봐야 합니다. enhanced-mode가 fake-ip(또는 사용 환경에 따라 redir-host)로 설정되어 있는지, nameserver가 모두 암호화 DNS이고 평문 udp:// 주소가 아닌지, dns-hijack이 53번 포트를 포함해 모든 DNS 요청이 클라이언트가 관리하는 해석 로직을 강제로 거치도록 하는지입니다. 이 중 하나라도 빠지면 특정 네트워크 환경에서 신뢰할 수 없는 경로로 폴백될 수 있습니다.

로컬 패킷 캡처 도구의 잔여 인증서

쉽게 놓치는 또 다른 원인은 과거에 설치했던 디버깅 프록시나 패킷 캡처 도구입니다. 이런 도구는 HTTPS 트래픽을 복호화해 분석하기 위해 대개 자체 서명 루트 인증서를 생성하고 사용자가 이를 시스템 신뢰 목록에 직접 설치하도록 요구합니다. 그래야 중간에서 "정당하게" 중간자 역할을 할 수 있기 때문입니다. 도구를 제거할 때 이 인증서를 함께 삭제하지 않았거나, 인증서가 만료되었는데도 신뢰 목록에 남아 있다면, 이후 프록시를 사용할 때 특정 트래픽 경로가 우연히 남아 있는 프록시 설정을 거치면서 인증서 경고가 발생할 수 있습니다. 브라우저에 표시되는 증상은 실제 중간자 하이재킹과 거의 동일해 노드 문제로 오인하기 쉽습니다.

1. 시스템 인증서 신뢰 목록 확인

   Windows는 「인증서 관리자」(certmgr.msc)에서 「신뢰할 수 있는 루트 인증 기관」을 확인하고, macOS는 「키체인 접근」에서 로그인 및 시스템 인증서를 확인해 디버깅 도구 이름이 붙은 자체 서명 항목을 찾습니다.

2. 의심스러운 인증서 삭제 또는 비활성화

   이미 사용하지 않는 디버깅 도구가 만든 인증서임을 확인한 뒤에는 신뢰 목록에서 제거하거나 신뢰하지 않음으로 표시합니다.

3. 시스템 프록시 설정 잔여 여부 확인

   일부 패킷 캡처 도구는 시스템 네트워크 설정에 고정 프록시 주소와 포트를 기록해 둡니다. 도구를 제거한 후 이런 잔여 설정을 수동으로 지워야 Clash 클라이언트의 프록시 설정과 충돌하지 않습니다.

점검 절차 우선순위 체크리스트

인증서 오류가 발생하면 다음 순서대로 하나씩 점검하며, 비용이 가장 적고 배제하기 쉬운 항목부터 진행합니다.

1. 시스템 시간과 시간대 확인

   가장 빠르게 배제할 수 있는 항목으로, 몇십 초 안에 확인 또는 배제가 가능합니다.

2. 프록시를 끄고 재테스트

   클라이언트를 완전히 종료한 뒤 같은 웹사이트에 다시 접속해 프록시와 관련이 있는지 판단합니다. 끈 뒤에도 여전히 오류가 발생한다면 문제는 시스템 인증서 신뢰 목록이나 로컬 hosts 설정에 있으며 Clash와는 무관합니다.

3. 노드를 전환해 재테스트

   프록시를 끈 뒤 정상으로 돌아온다면 노드를 하나씩 전환해 보며 특정 노드의 하이재킹 여부를 확인합니다.

4. TUN 모드 DNS 설정 확인

   enhanced-mode, nameserver, dns-hijack 세 항목이 모두 갖춰져 있고 암호화 DNS를 사용하는지 확인합니다.

5. 시스템 인증서 신뢰 목록의 의심스러운 항목 확인

   과거 설치했던 디버깅 도구, 패킷 캡처 소프트웨어가 남긴 자체 서명 루트 인증서를 중점적으로 점검합니다.

6. 클라이언트와 규칙 구독 업데이트

   Clash Meta(mihomo) 코어가 최신 버전인지 확인합니다. 이전 버전의 TLS 라이브러리나 DNS 처리에 있던 알려진 문제가 이후 업데이트에서 수정되었을 수 있습니다.