프록시 사용 시 브라우저에 HTTPS 인증서 오류가 뜨는 원인과 해결 방법
인증서 검증 체계와 프록시의 관계를 설명합니다. 시스템 시간 오차, MITM 복호화, 페이지 하이재킹, 노드 이상 등 원인별 오류 특징과 단계별 해결 방법을 안내합니다.
프록시를 켠 뒤 브라우저에서 갑자기 인증서 경고가 뜨는 것은 Clash 또는 Clash Meta(mihomo) 코어 클라이언트를 사용할 때 가장 당황스러운 오류 중 하나입니다. 경고 문구는 보통 "연결이 비공개로 설정되어 있지 않습니다", "인증서가 유효하지 않습니다", "NET::ERR_CERT_AUTHORITY_INVALID" 등으로 표시되지만, 그 뒤에 숨은 원인은 제각각입니다. 어떤 경우는 시스템 시계가 몇 분 늦은 것뿐이고, 어떤 경우는 노드 자체에 문제가 있는 것입니다. 이 글에서는 오류 특징별로 가장 흔한 네 가지 원인을 분류하고, 그대로 따라 할 수 있는 해결 절차를 제시합니다.
인증서 검증 체계와 프록시의 관계
프록시가 왜 HTTPS 인증서 문제와 연결되는지 이해하려면 먼저 브라우저의 인증서 검증 기본 원리를 알아야 합니다. HTTPS 사이트에 접속할 때마다 브라우저는 서버가 반환한 인증서가 세 가지 조건을 만족하는지 확인합니다. 인증서 체인이 시스템이 신뢰하는 루트 인증서까지 추적 가능한지, 인증서에 명시된 도메인이 접속한 도메인과 일치하는지, 인증서가 현재 유효 기간 내에 있는지입니다. 이 세 항목을 모두 통과해야 주소창에 보안 자물쇠 아이콘이 표시됩니다.
Clash 계열 클라이언트는 대부분의 사용 환경에서 전송 계층에서만 동작하며, TCP/UDP 트래픽을 원격 노드로 전달하는 역할만 합니다. HTTPS 인증서를 복호화하거나 재발급하지 않으므로 브라우저가 보는 것은 여전히 대상 사이트가 원래 갖고 있는 인증서 그대로입니다. 즉 정상적인 상황이라면 프록시를 켜는 것만으로 인증서가 바뀔 이유는 없습니다. 인증서 경고가 나타났다면 다음 네 가지 원인 중 하나로 볼 수 있습니다. 기기의 시스템 시간이 부정확하거나, 클라이언트가 복호화 기능이 포함된 특수 모드를 켜고 있거나, 경로 중간에 페이지 하이재킹이 존재하거나, 현재 연결된 노드 자체에 이상이 있는 경우입니다. 이제 하나씩 살펴보겠습니다.
시스템 시간 오차: 가장 자주 간과되는 원인
인증서 유효 기간 검사는 기기의 로컬 시계에 의존합니다. 시스템 시간이 실제 시간과 크게 어긋나 있으면(장기간 네트워크에 연결되지 않은 가상 머신, 테스트용으로 시간을 임의로 바꾼 기기, 배터리가 방전되어 메인보드 시계가 초기화된 오래된 장치 등에서 흔히 발생) 브라우저는 인증서가 "아직 유효하지 않음" 또는 "이미 만료됨"으로 오판하며, 오류 메시지에 보통 ERR_CERT_DATE_INVALID 문구가 포함됩니다. 이런 유형의 특징은 모든 사이트에서 예외 없이 오류가 발생하고, 노드나 프록시 사용 여부와 무관하며, 다른 기기로 같은 사이트에 접속하면 정상이라는 점입니다.
해결 방법은 간단합니다. 시스템 시간 설정을 열어 "네트워크 시간 자동 동기화"가 켜져 있는지 확인하고, 표준 시간대가 올바른지 점검합니다.
Windows 사용자는 설정의 날짜 및 시간 페이지에서 "지금 동기화"를 클릭하면 됩니다. macOS 사용자는 시스템 설정의 일반 - 날짜 및 시간에서 확인할 수 있습니다. Linux 사용자는 다음 명령으로 시스템 시간과 네트워크 시간이 일치하는지 빠르게 확인할 수 있습니다.
timedatectl status출력 결과에서 System clock synchronized가 no로 표시되면 동기화 서비스가 제대로 작동하지 않은 것이므로 네트워크 연결 상태를 점검하거나 시간 서버 주소를 변경해야 합니다.
MITM 복호화 및 규칙 하이재킹으로 인한 인증서 오류
두 번째 원인은 시스템 시간과 무관하며, 클라이언트 자체의 기능 설정에서 비롯됩니다. Clash Meta(mihomo) 코어 기반 클라이언트 일부는 MITM(중간자) 복호화 기능을 지원하여 특정 도메인의 HTTPS 트래픽에 스크립트 재작성이나 광고 필터링을 적용합니다. 이 기능은 클라이언트가 자체 서명 루트 인증서를 생성하여 시스템 신뢰 목록에 설치해야 합니다. 이 루트 인증서가 시스템이나 브라우저에 제대로 신뢰되지 않으면 MITM 규칙에 포함된 도메인에 접속할 때 NET::ERR_CERT_AUTHORITY_INVALID가 발생하며, 인증서 발급자가 신뢰할 수 없다는 안내가 표시됩니다.
이 유형의 판단 기준은 설정 파일의 mitm 섹션에 나열된 소수 도메인에서만 오류가 발생하고 대부분의 사이트는 정상 접속되며, 오류 페이지의 인증서 상세 정보에서 발급자가 사이트 본래의 인증 기관이 아니라 클라이언트 자신의 이름으로 표시된다는 점입니다.
MITM 활성화 여부 확인
클라이언트 설정이나 규칙 페이지에서 MITM/스크립트/재작성 관련 스위치가 있는지 확인합니다. 해당 기능이 필요 없다면 바로 꺼두는 것이 가장 간단합니다.
루트 인증서 재설치
기능을 계속 사용해야 한다면 클라이언트가 제공하는 인증서 내보내기 메뉴로 이동해 루트 인증서를 다시 다운로드하고 시스템 안내에 따라 수동으로 신뢰 설정을 해줍니다(macOS는 키체인 접근에서 인증서 신뢰 수준을 "항상 신뢰"로 변경, Windows는 "신뢰할 수 있는 루트 인증 기관"에 설치해야 합니다).
MITM 적용 범위 축소
mitm규칙을 실제로 처리가 필요한 도메인으로만 좁혀서 은행, 결제처럼 인증서에 매우 민감한 사이트에는 적용되지 않도록 하여 위험을 줄입니다.
더 주의해야 할 상황도 있습니다. 어떤 복호화나 재작성 기능도 켜지 않았는데 낯선 페이지에 접속했을 때 인증서 경고가 뜨고, 페이지 내용이 원래 기대했던 것과 완전히 다르다면(예: 쇼핑몰에 접속했는데 관련 없는 광고 페이지로 넘어가는 경우) 이는 대개 경로 중간에서 하이재킹이 발생해 트래픽이 목적지 서버에 도달하기 전에 중간 노드에서 변조되거나 리다이렉트되었다는 뜻입니다. 이런 경우에는 해당 노드에서 계정 로그인이나 결제 등의 작업을 즉시 중단하고 구독이나 노드 출처를 교체해야 합니다.
노드 이상으로 인한 연결 및 인증서 오류
네 번째 원인은 노드 자체의 상태와 관련이 있습니다. 프록시 노드가 이미 무효화되었거나 대상 서버에 차단되었거나, 노드 서버 측 설정에 문제가 있는 경우(직접 구축한 노드의 인증서가 만료되어 갱신되지 않았거나 TLS 파라미터 설정이 잘못된 경우 흔함) 브라우저는 연결 시간 초과로 나타날 수도 있고, 인증서 체인이 불완전하다는 오류로 나타날 수도 있습니다. 구체적인 안내는 브라우저마다 다르지만 흔히 ERR_CERT_COMMON_NAME_INVALID(인증서 도메인과 접속 도메인 불일치)와 ERR_SSL_PROTOCOL_ERROR가 나타납니다.
이 유형의 특징은 다른 노드로 전환하면 문제가 즉시 사라지거나, 같은 노드로 모든 사이트에 접속할 때 특정 도메인에만 한정되지 않고 비슷한 연결 이상이 발생한다는 점입니다. 확인 절차는 다음과 같습니다.
- 먼저 클라이언트에서 지연이 정상인 다른 노드로 전환해 재시도합니다. 문제가 사라지면 기존 노드에 이상이 있다고 거의 확정할 수 있으므로 구독 그룹에서 해당 노드를 제외 표시하거나 구독 갱신을 기다리는 것을 권장합니다.
- 어느 노드로 바꿔도 같은 오류가 발생한다면 노드 문제가 아닐 가능성이 높으므로 앞의 두 가지 원인(시간, MITM)을 다시 점검해야 합니다.
- 직접 구축한 노드를 사용하는 경우 명령줄 도구로 서버 측 인증서 상태를 직접 확인하여 인증서가 만료됐는지, 도메인이 일치하지 않는지 확인할 수 있습니다.
openssl s_client -connect example.invalid:443 -servername example.invalid명령 출력의 Verify return code 항목이 0이 아니라면 서버 측 인증서 자체에 문제가 있다는 뜻이므로 노드 제공자에게 문의하거나 인증서를 재발급받아야 하며, 클라이언트 설정 문제가 아닙니다.
TUN 모드에서의 별도 확인 방법
TUN 모드(가상 네트워크 어댑터로 전체 트래픽을 인계)를 켠 뒤에는 인증서 문제 확인 방법이 일반 프록시 모드와 대체로 동일하지만, 트래픽 경로가 시스템 네트워크 스택의 가상 인터페이스를 거치기 때문에 추가로 두 가지를 확인해야 합니다. 첫째는 가상 네트워크 어댑터의 DNS가 신뢰할 수 있는 해석 서버를 가리키고 있는지입니다. DNS 오염이나 하이재킹이 발생하면 브라우저가 잘못된 IP에 연결되어 대상 도메인과 일치하지 않는 인증서를 보게 됩니다. 둘째는 방화벽이나 보안 소프트웨어가 가상 네트워크 어댑터 트래픽을 추가로 차단하거나 리다이렉트하고 있는지입니다. 먼저 TUN 모드를 잠시 끄고 일반 시스템 프록시 모드로 같은 사이트에 접속해보면, 인증서 경고가 사라진다면 문제 범위를 TUN 관련 DNS나 라우팅 설정으로 좁힐 수 있습니다.
빠른 자가 점검 목록
위 네 가지 원인을 정리하면, 인증서 경고가 나타났을 때 다음 순서로 빠르게 점검하면 대부분 몇 분 안에 문제 범위를 파악할 수 있습니다.
시스템 시간과 표준 시간대 확인
자동 동기화가 실제로 작동하고 있는지, 시간 오차가 몇 분을 넘는지 확인합니다.
MITM이나 스크립트 재작성 활성화 여부 확인
해당 기능을 잠시 끄고 재시도하여 오류가 사라지는지 확인합니다.
오류가 특정 도메인에만 한정되는지 관찰
전체 사이트에서 오류가 발생하면 대개 시간이나 시스템 계층 문제이고, 단일 도메인에서만 발생하면 MITM 규칙이나 하이재킹과 관련이 있을 가능성이 높습니다.
노드를 전환해 재확인
지연이 정상인 다른 노드로 바꿔서 문제가 노드에 따라 달라지는지 확인합니다.
구독과 노드 출처의 신뢰성 확인
하이재킹이 의심되면 민감한 작업을 중단하고 구독 출처를 교체해야 합니다.
대부분의 인증서 경고는 이 다섯 단계 안에서 명확한 원인을 찾을 수 있습니다. 확인 결과 설정 자체에 문제가 있는 것으로 확인되면, 기존 규칙을 하나씩 수정하는 것보다 깨끗한 구독 설정을 새로 가져오거나 클라이언트를 기본 설정으로 초기화하는 편이 대체로 더 빠릅니다.