프록시를 켠 뒤 HTTPS 인증서 오류가 발생할 때: 흔한 원인과 단계별 해결 방법

HTTPS 인증서 오류는 대개 TLS 핸드셰이크 단계에서 발생합니다. 브라우저는 웹 요청을 실제로 보내기 전에 서버가 반환한 인증서가 신뢰할 수 있는 기관에서 발급되었는지, 인증서의 도메인이 현재 주소와 일치하는지, 현재 시간이 유효 기간에 포함되는지, 인증서 체인이 시스템이 신뢰하는 루트 인증서까지 완전하게 연결되는지를 확인합니다. Clash 또는 mihomo를 켠 뒤 오류가 발생했다면 연결 경로가 바뀌었다는 뜻일 뿐, 원인을 특정 노드로 단정할 수는 없습니다.

표준 HTTP CONNECT, SOCKS5 또는 TUN 전달 방식은 웹사이트를 대신해 인증서를 발급하지 않습니다. mihomo 코어는 일반적으로 연결 전달, 규칙 매칭, 출구 선택만 담당하며 웹페이지의 TLS 내용을 복호화하지 않습니다. 브라우저에 표시되는 인증서 발급자가 갑자기 로컬 보안 프로그램, 회사 게이트웨이 또는 낯선 기관으로 바뀌었다면 HTTPS 검사, 상위 프록시, 공용 네트워크 인증 페이지와 시스템 인증서 저장소를 추가로 확인해야 합니다. 프록시 규칙만 반복해서 수정하는 것은 해결책이 아닙니다.

오류 코드로 범위를 먼저 좁히세요

인증서 오류마다 확인해야 할 방향이 다릅니다. Chrome, Edge 및 Chromium 기반 클라이언트는 보통 NET::ERR_CERT_로 시작하는 코드를 표시하고, Firefox에서는 SEC_ERROR_UNKNOWN_ISSUER 또는 SSL_ERROR_BAD_CERT_DOMAIN이 자주 나타납니다. 먼저 브라우저의 “고급” 또는 “인증서 보기”를 열고 아래 표에 따라 확인하세요.

오류 코드 또는 증상	우선 확인할 항목	흔한 원인
`NET::ERR_CERT_DATE_INVALID`	시스템 날짜, 시간, 시간대 및 인증서 유효 기간	기기 시간 오차, 듀얼 부팅 시간 불일치, 절전 후 동기화되지 않음
`NET::ERR_CERT_COMMON_NAME_INVALID`	주소 표시줄의 도메인과 인증서 SAN 도메인	DNS가 잘못된 서버를 가리킴, 투명 게이트웨이 리디렉션, 잘못된 도메인에 접속함
`NET::ERR_CERT_AUTHORITY_INVALID`	인증서 발급자와 전체 인증서 체인	로컬 HTTPS 검사, 기업 프록시, 자체 서명 인증서, 서버의 중간 인증서 누락
`SEC_ERROR_UNKNOWN_ISSUER`	Firefox 인증서 저장소와 시스템 인증서 저장소	브라우저가 로컬 검사 도구의 루트 인증서를 신뢰하지 않거나 인증서 체인이 불완전함
일부 애플리케이션만 실패	애플리케이션 인증서 고정, 프록시 유형 및 TUN 가로채기 범위	애플리케이션이 인증서 고정 검사를 수행하거나 트래픽이 추가 필터링 모듈을 통과함
모든 HTTPS 웹사이트에서 동시에 실패	시스템 시간, 로컬 보안 프로그램, 공용 네트워크 인증	개별 웹사이트의 인증서 장애보다 전체 환경 문제일 가능성이 높음

인증서 페이지에서 중점적으로 볼 네 가지

발급 대상: 현재 접속한 도메인이 포함되어야 합니다. 와일드카드 인증서 *.example.com은 www.example.com을 포함할 수 있지만, 일반적으로 한 단계 더 깊은 a.b.example.com까지 포함하지는 않습니다.
발급자: 직접 연결에서는 공인 인증 기관이던 발급자가 프록시 사용 시 로컬 프로그램 이름이나 조직 내부 CA로 바뀐다면, 경로에 TLS 검사가 존재한다는 뜻입니다.
유효 기간: “유효 시작 시간”과 “만료 시간”을 비교할 때는 시스템 시간대도 함께 확인해야 합니다. 날짜가 맞더라도 시간대가 몇 시간 어긋나면 인증서가 갱신된 직후 오류가 발생할 수 있습니다.
주체 대체 이름: 최신 브라우저는 기존 Common Name만이 아니라 SAN을 주로 확인합니다. 인증서에 현재 도메인이 없으면 도메인 불일치 오류가 발생합니다.

1단계: 시스템 시간과 인증서 환경 보정

시간 오류는 가장 넓은 범위에 영향을 주면서 확인 비용은 낮습니다. 모든 HTTPS 사이트에서 실패하거나 컴퓨터가 절전 모드에서 막 복귀했거나 메인보드 배터리를 교체했거나 듀얼 부팅을 사용한다면 먼저 시간 동기화를 완료하세요. Windows 11에서는 “설정” → “시간 및 언어” → “날짜 및 시간”으로 이동해 “자동으로 시간 설정”과 “자동으로 표준 시간대 설정”을 켠 다음 “지금 동기화”를 클릭합니다.

Windows에서는 터미널에서 다음 명령을 실행해 시간 서비스 상태도 확인할 수 있습니다. 결과의 Source에는 사용 가능한 시간 원본이 표시되어야 하며, Last Successful Sync Time은 현재 시간과 가까워야 합니다.

w32tm /query /status
powershell -NoProfile -Command "Get-Date"

macOS에서는 “시스템 설정” → “일반” → “날짜 및 시간”으로 이동해 자동 설정을 켭니다. Linux에서는 timedatectl status로 System clock synchronized와 시간대를 확인할 수 있습니다. Android의 일반적인 경로는 “설정” → “시스템” → “날짜 및 시간”이며, 제조사에 따라 “추가 설정”에 있을 수 있습니다.

만료된 로컬 인증서 개입 정리

기기에 패킷 캡처 도구, 디버깅 프록시, 기업 단말 관리 프로그램 또는 HTTPS 검사 구성 요소를 설치한 적이 있다면 해당 프로그램이 아직 실행 중인지 확인하세요. 브라우저만 종료하는 것으로는 부족할 수 있습니다. 필터 드라이버, 시스템 서비스, 로컬 프록시 프로세스가 계속 연결을 가로챌 수 있기 때문입니다. 먼저 프로그램 자체 설정에서 HTTPS 검사 또는 TLS 복호화를 끈 뒤 해당 프로그램을 완전히 종료하고 브라우저를 다시 시작하세요.

Windows에서는 Win + R을 누르고 certmgr.msc를 입력해 현재 사용자 인증서를 확인할 수 있습니다. 컴퓨터 수준 인증서는 MMC의 “인증서” 관리 스냅인을 통해 확인합니다.
macOS에서는 “키체인 접근”에서 “시스템” 및 “로그인” 키체인을 확인하고, 최근 추가되었으며 인증서 서명 용도로 사용되는 항목을 중점적으로 살펴보세요.
Firefox에서는 “설정” → “개인정보 및 보안” → “인증서” → “인증서 보기”를 열어 “인증 기관” 목록을 확인합니다.
Android에서는 “설정” → “보안” → “암호화 및 자격 증명”에서 사용자가 설치한 자격 증명을 확인할 수 있습니다. 실제 메뉴 이름은 운영체제 버전에 따라 달라집니다.

2단계: 직접 연결, 시스템 프록시, TUN 경로 비교

인증서 문제를 확인하는 가장 효과적인 방법은 통제된 비교 테스트입니다. 매번 변수 하나만 바꾸고, 노드·DNS·규칙을 동시에 변경하거나 인증서를 다시 설치하지 마세요. 먼저 안정적인 HTTPS 사이트 하나를 테스트한 다음 처음 오류가 발생한 사이트를 확인하면 “모든 사이트 실패”와 “특정 사이트 실패”를 구분할 수 있습니다.

Clash 또는 mihomo는 실행 상태로 두고 시스템 프록시와 TUN을 끈 뒤 직접 연결을 테스트합니다.
시스템 프록시만 켜고 같은 노드와 같은 브라우저로 다시 테스트합니다.
시스템 프록시를 끄고 TUN만 켠 뒤 한 번 더 테스트합니다.
모드는 그대로 유지한 채 현재 노드를 다른 회선의 노드로 변경합니다.
마지막에야 규칙 모드, 글로벌 모드 또는 직접 연결 모드로 전환해 문제가 규칙 매칭과 관련 있는지 확인합니다.

curl로 로컬 혼합 포트 확인

Clash 그래픽 클라이언트는 로컬 혼합 포트를 보통 7890으로 설정하지만, 실제 값은 구성의 mixed-port 또는 클라이언트의 “설정” → “포트 설정”을 기준으로 해야 합니다. 아래 두 명령은 각각 직접 연결과 로컬 HTTP 프록시를 통한 연결을 테스트합니다. -I는 응답 헤더만 요청하고, -v는 연결 및 TLS 과정을 표시합니다.

curl -Iv https://www.cloudflare.com/
curl -Iv --proxy http://127.0.0.1:7890 https://www.cloudflare.com/

직접 연결은 성공하고 프록시만 실패한다면 노드를 바꿔 가며 mihomo 로그를 확인하세요. 모든 노드에서 실패하지만 특정 로컬 보안 구성 요소를 끈 뒤 복구된다면 로컬 TLS 검사를 우선 처리해야 합니다. 특정 노드 하나에서만 실패한다면 노드 출구 네트워크, 상위 DNS, 공용 네트워크 인증 또는 서버에서 대상 사이트로 이어지는 경로에 문제가 있을 수 있습니다.

OpenSSL로 서버가 전송하는 인증서 체인을 확인할 수도 있습니다. 최신 OpenSSL은 HTTP 프록시를 통해 연결을 설정하는 기능을 지원합니다.

openssl s_client -proxy 127.0.0.1:7890 -connect www.cloudflare.com:443 -servername www.cloudflare.com -showcerts

-servername은 SNI를 전송합니다. SNI가 없으면 여러 도메인을 운영하는 서버가 기본 사이트 인증서를 반환해 도메인 불일치가 발생할 수 있습니다. 직접 연결과 프록시 결과를 비교할 때는 인증서 주체, 발급자, 유효 기간, 검증 반환 코드를 중점적으로 확인하고, 명령 마지막에 TCP 연결이 성립했는지만 보지 마세요.

3단계: 노드, DNS 및 프록시 규칙 확인

노드 전환으로 알 수 있는 것

프록시를 통한 HTTPS 연결에서는 클라이언트가 먼저 노드에 암호화 터널을 만든 뒤 노드가 대상 웹사이트에 연결하는 것이 일반적입니다. HTTP 프록시에서는 브라우저가 CONNECT example.com:443으로 터널을 만들고, SOCKS5에서는 도메인 또는 대상 주소가 SOCKS 요청으로 전달됩니다. 정상적인 터널에서는 TLS 연결이 여전히 브라우저와 대상 웹사이트 사이에서 이루어집니다.

다른 노드로 바꾸자마자 정상화된다면 실패한 노드가 속한 네트워크가 대상 도메인을 잘못된 주소로 연결하는지, 통신사 인증 페이지가 나타나는지, 대상 사이트가 현재 사용하는 인증서 체인을 가져오지 못하는지 추가로 확인할 수 있습니다. 노드 자체가 인증서를 교체할 수 있고 기기가 그 발급 인증서를 신뢰하는 경우에만 브라우저가 경고 없이 교체된 내용을 받아들일 수 있습니다. 신뢰가 없으면 대개 즉시 인증서 오류가 발생합니다.

DNS 오류가 인증서 도메인 오류로 이어지는 이유

DNS가 도메인을 잘못된 서버로 해석해도 브라우저는 원래 도메인을 SNI로 전송합니다. 잘못된 서버에 해당 가상 호스트가 없으면 다른 웹사이트의 인증서를 반환할 수 있고, 결국 NET::ERR_CERT_COMMON_NAME_INVALID가 발생합니다. 이때 인증서 자체의 유효 기간은 남아 있을 수 있지만 적용 도메인이 주소 표시줄의 도메인과 일치하지 않습니다.

mihomo의 fake-ip 모드는 먼저 예약된 주소 풀에서 매핑 주소를 반환한 다음 코어에서 원래 도메인을 복원하고 규칙에 따라 연결합니다. Fake-IP 자체가 웹사이트 인증서를 생성하는 것은 아닙니다. 문제가 Fake-IP에서만 발생한다면 도메인이 fake-ip-filter에 잘못 추가되었는지, 애플리케이션이 TUN을 우회하는지, 로컬 네트워크의 DNS 요청이 실제로 mihomo에 들어오는지 확인하세요.

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "localhost.ptlogin2.qq.com"

fake-ip-filter는 실제 주소에 의존하는 로컬 네트워크 서비스, 기기 검색 도메인 또는 특정 호환성 상황에 한해 설정해야 하며, 광범위한 도메인을 모두 제외해서는 안 됩니다. 제외된 도메인은 실제 DNS 해석을 사용하게 되고, 해석 출처와 규칙 경로도 달라집니다.

실제로 매칭된 규칙 확인

연결 목록을 지원하는 Clash 클라이언트에서는 “연결” 또는 “로그” 페이지를 열고 오류가 발생한 사이트에 접속한 뒤 도메인으로 필터링하세요. 매칭된 규칙, 정책 그룹, 최종 노드를 기록합니다. 원래 직접 연결되어야 할 대상이 프록시로 들어간다면 앞쪽의 DOMAIN, DOMAIN-SUFFIX, GEOSITE 및 규칙 세트를 확인하세요. 반대로 프록시를 사용해야 하는데 직접 연결된다면 로컬 네트워크 규칙, 사설 주소 규칙, 최종 MATCH를 확인합니다.

rules:
  - DOMAIN-SUFFIX,example.com,PROXY
  - GEOSITE,private,DIRECT
  - GEOIP,private,DIRECT,no-resolve
  - MATCH,PROXY

규칙은 순서대로 매칭되며 앞에서 매칭되면 이후 규칙으로 내려가지 않습니다. YAML을 수정한 뒤에는 먼저 들여쓰기를 확인하고 구성을 다시 불러오세요. 클라이언트가 구독 오버라이드, 스크립트 또는 전역 확장 구성을 함께 사용한다면 구독 원문이 아니라 최종 적용 구성을 확인해야 합니다.

4단계: MITM, HTTPS 검사 및 방화벽 개입 확인

여기서 MITM은 중간 구성 요소가 원래 TLS 연결을 종료한 뒤 브라우저에 대체 인증서를 발급하고, 동시에 해당 구성 요소가 대상 웹사이트와 두 번째 TLS 연결을 만드는 방식을 뜻합니다. 기업 감사 게이트웨이, 패킷 캡처·디버깅 도구, 자녀 보호 프로그램, 일부 단말 보안 제품이 HTTPS 트래픽을 검사할 때 이 방식을 사용할 수 있습니다.

표준 mihomo 구성의 proxies, proxy-groups, rules, tun, dns 필드는 웹페이지 인증서를 발급하지 않습니다. 따라서 Clash 클라이언트 화면에서 이른바 “웹사이트 인증서 스위치”를 찾을 수 없는 것은 정상입니다. 인증서 발급자가 로컬 프로그램으로 표시된다면 해당 프로그램의 네트워크 보호 또는 HTTPS 검사 설정으로 돌아가 처리하세요.

모든 구성 요소를 한꺼번에 삭제하지 말고 하나씩 비활성화하세요

브라우저 확장 프로그램의 프록시 전환, 패킷 캡처 또는 디버깅 기능을 끄고 브라우저를 완전히 종료한 뒤 다시 엽니다.
로컬 패킷 캡처 프로그램의 시스템 프록시와 HTTPS 복호화를 일시 중지하고 Clash의 시스템 프록시만 남겨 둡니다.
보안 프로그램에서 “HTTPS 검사”, “암호화 연결 검사” 또는 유사 기능을 잠시 끄고 한 번 비교 테스트한 뒤 다시 켭니다.
회사 VPN, 제로 트러스트 클라이언트 또는 원격 근무 게이트웨이 연결을 끊은 뒤 가정용 네트워크와 모바일 핫스팟을 비교합니다.
공용 Wi-Fi 인증이 아직 완료되지 않았다면 먼저 프록시를 끄고 시스템이 제공하는 로그인 페이지에 접속해 인증을 완료한 뒤 프록시를 다시 켭니다.

일부 공용 네트워크는 최초 HTTP 요청을 인증 페이지로 리디렉션합니다. 인증 게이트웨이가 반환하는 인증서는 원래 웹사이트의 인증서가 아니므로 HTTPS는 이러한 리디렉션을 직접 받아들일 수 없고, 브라우저에는 도메인 불일치가 표시됩니다. 휴대폰 핫스팟으로 전환하자마자 정상화된다면 이런 문제를 식별하는 중요한 단서입니다.

5단계: 브라우저 또는 특정 애플리케이션에서만 발생하는 오류 처리

Chrome과 Edge는 정상인데 Firefox에서 오류가 발생함

Chrome과 Edge는 일반적으로 운영체제의 인증서 환경을 따르지만 Firefox의 인증서 처리는 시스템과 다를 수 있습니다. 먼저 Firefox에서 “설정” → “개인정보 및 보안” → “인증서” → “인증서 보기”를 열고 필요한 기관이 있는지 확인하세요. 기업 기기는 관리자가 인증서 정책을 일괄 배포해야 하며, 웹페이지 안내에 따라 임시로 인증서를 내려받아서는 안 됩니다.

브라우저는 정상인데 데스크톱 또는 모바일 애플리케이션에서 실패함

일부 애플리케이션은 별도의 인증서 저장소를 사용하며, 개발자가 미리 지정한 인증서 또는 공개 키 관계만 허용하는 인증서 고정 검사를 수행하기도 합니다. 이 경우 브라우저에서는 사이트가 정상적으로 열리지만 애플리케이션은 연결을 거부할 수 있습니다. 일반적인 해결 방향은 시스템에 인증서를 더 가져오는 것이 아니라 해당 애플리케이션의 트래픽이 TLS 복호화 구성 요소를 우회하도록 하는 것입니다.

문제가 TUN 모드에서만 발생한다면 애플리케이션 트래픽이 다른 VPN, 보안 필터 또는 사설 DNS를 동시에 통과하는지 확인하세요. Android와 iOS는 일반적으로 한 번에 하나의 주요 VPN 터널만 허용하지만, 로컬 DNS, 콘텐츠 필터 설정 또는 기기 관리 정책이 경로를 바꿀 수 있습니다. 다른 네트워크 확장을 끈 뒤 Clash 클라이언트만 단독으로 실행하면 변수를 줄일 수 있습니다.

시크릿 창은 정상인데 일반 창에서 실패함

이는 대개 브라우저 확장 프로그램, 캐시된 HSTS 상태, 별도 프록시 확장 프로그램 또는 사용자 설정 차이를 가리킵니다. 먼저 확장 프로그램 관리 페이지에서 네트워크 관련 확장 프로그램을 끈 다음 대상 사이트의 쿠키와 사이트 데이터를 삭제하세요. “인증서 오류 무시” 시작 옵션을 장기적인 해결책으로 사용하면 전체 브라우저 세션의 인증서 검증 수준이 낮아집니다.

재사용할 수 있는 10분 점검 순서

1분: 오류 코드를 적고 인증서의 도메인, 발급자, 유효 기간을 확인합니다.
2분: 시스템 시간을 동기화하고 날짜, 시간대, 시간 서비스 상태를 확인합니다.
3분: 시스템 프록시와 TUN을 끄고 직접 연결을 비교 테스트합니다.
4분: 시스템 프록시만 켜고 같은 사이트와 같은 브라우저로 테스트합니다.
5분: 다른 회선의 노드로 바꾸되 다른 설정은 변경하지 않습니다.
6분: 연결 로그를 확인해 도메인에 매칭된 규칙, 정책 그룹, 출구를 확인합니다.
7분: curl -Iv로 직접 연결과 127.0.0.1:7890 프록시 결과를 비교합니다.
8분: HTTPS 검사, 패킷 캡처, 기업 네트워크 구성 요소를 일시 중지하고 하나씩 비교합니다.
9분: 휴대폰 핫스팟으로 전환해 공용 네트워크 인증과 현재 라우터 경로를 배제합니다.
10분: 클라이언트 버전, mihomo 코어 버전, 시스템 버전, 노드, 모드, 오류 코드를 포함해 재현 조건을 정리합니다.

최종 판단은 비교 결과를 바탕으로 내려야 합니다. 모든 네트워크와 모든 기기에서 같은 웹사이트에 오류가 발생하면 웹사이트의 인증서 배포 문제일 가능성이 높습니다. 한 기기에서만 실패하면 시간, 인증서 저장소, 보안 프로그램을 우선 확인하세요. 프록시 경로에서만 실패하면 노드, DNS, 규칙, 상위 네트워크를 계속 점검해야 합니다. 특정 애플리케이션에서만 실패한다면 별도 인증서 저장소, 인증서 고정, 애플리케이션 트래픽 가로채기 범위를 중점적으로 살펴보세요.

점검이 끝나면 임시로 끈 보안 기능을 하나씩 다시 켜고 브라우저와 자주 사용하는 애플리케이션을 재확인하세요. Clash 또는 mihomo 구성도 평소 사용 모드로 되돌려 전역 프록시, 지나치게 넓은 Fake-IP 제외 항목, 테스트를 위해 추가한 규칙을 장기간 유지하지 않도록 합니다.