프록시 사용 중 브라우저 인증서 오류: HTTPS 오류 원인과 해결 방법

인증서 오류와 프록시 연결 실패 구분하기

브라우저에 “연결이 비공개로 설정되어 있지 않습니다”라는 메시지가 표시된다면 HTTPS 인증에 실패한 것입니다. 노드 연결 시간 초과나 프록시 포트 미수신과는 다른 문제입니다. Clash Verge는 클라이언트 인터페이스이며, 실제 트래픽 전달은 사용하는 코어가 담당합니다. Clash 또는 Clash Meta(mihomo)는 일반적인 HTTP CONNECT 및 SOCKS 프록시 연결에서 대상 웹사이트의 HTTPS 콘텐츠를 복호화하지 않으며, 웹사이트 인증서를 발급하는 루트 인증서를 시스템에 설치할 필요도 없습니다.

따라서 “프록시를 켠 뒤 발생했다”는 사실만으로 네트워크 경로 변경과 오류 사이에 연관이 있음을 알 수 있을 뿐, “프록시 클라이언트에 인증서를 설치해야 한다”고 단정할 수는 없습니다. 클라이언트를 반복해서 재설치하기보다 브라우저 오류 코드, 접속 도메인, 인증서 발급자와 유효 기간을 기록한 뒤 경로별로 비교하면 원인을 더 쉽게 찾을 수 있습니다.

오류 코드 또는 증상	우선 확인 항목	기록해 둘 정보
`NET::ERR_CERT_DATE_INVALID`	시스템 시간 및 인증서 유효 기간	기기의 날짜와 인증서 유효 기간
`NET::ERR_CERT_AUTHORITY_INVALID`	알 수 없는 발급자, 누락된 인증서 체인, 신뢰 저장소	발급자 및 인증서 체인
`NET::ERR_CERT_COMMON_NAME_INVALID`	도메인 불일치, 잘못된 DNS 응답, 인증 포털 페이지	주소 표시줄의 도메인과 SAN 도메인 목록
`ERR_PROXY_CONNECTION_FAILED`	기기의 프록시 주소, 포트, 코어 상태	실제 수신 포트와 로그

1단계: 시스템 시간과 인증서 유효 기간 확인

인증서에는 유효 시작 시각과 만료 시각이 기록되어 있습니다. 컴퓨터를 오랫동안 끄거나 메인보드 배터리에 문제가 생기거나 가상 머신을 예전 스냅샷으로 복원하면 기기의 날짜가 실제 날짜와 달라질 수 있습니다. 작업 표시줄의 시각만 확인하지 말고 연도, 월, 시간대도 확인하세요. 서로 관련 없는 여러 웹사이트에서 동시에 날짜 오류가 발생한다면 먼저 시스템 시간을 바로잡아야 합니다.

Windows 11: ‘설정’ → ‘시간 및 언어’ → ‘날짜 및 시간’을 열고 ‘시간 자동 설정’을 켠 다음 시간대를 확인하고 ‘지금 동기화’를 클릭합니다. 조직에서 관리하는 기기는 관리자가 지정한 시간 원본을 사용해야 합니다.
macOS: ‘시스템 설정’ → ‘일반’ → ‘날짜 및 시간’을 열고 날짜 및 시간 자동 설정을 켠 뒤 시간대 설정을 확인합니다.
인증서 확인: 브라우저 오류 페이지에서 인증서 세부 정보를 확인하세요. 개발자 도구의 ‘보안’ 패널에서도 확인 가능한 인증서 정보를 볼 수 있습니다. ‘유효 기간 시작’과 ‘유효 기간 종료’를 기록하고 시간을 바로잡은 뒤의 날짜와 비교하세요.

웹사이트 한 곳의 인증서만 만료되고 다른 사이트는 정상이라면 대개 사이트 운영자가 인증서를 갱신하거나 CDN 설정을 수정해야 합니다. 기기의 날짜를 바꿔 인증서 유효 기간에 맞추면 다른 웹사이트와 로그인 토큰에 영향을 줄 수 있으므로 해결 방법으로 사용하면 안 됩니다. 브라우저는 현재 시각을 기준으로 인증서를 확인합니다. 시간대 표시만 바꿔도 잘못된 시스템 시계가 바로잡히는 것은 아닙니다.

2단계: HTTPS 중간자 검사와 낯선 발급자 확인

기업 게이트웨이, 보안 소프트웨어의 ‘HTTPS 검사’, 로컬 패킷 캡처 도구는 원래의 TLS 연결을 종료한 뒤 자체 인증서로 브라우저에 콘텐츠를 제공할 수 있습니다. 해당 루트 인증서를 현재 브라우저가 신뢰하지 않으면 알 수 없는 발급자 오류가 발생할 수 있습니다. 공용 Wi-Fi의 인증 페이지가 HTTPS 연결에 잘못 반환되는 경우에도 도메인이나 발급자 정보가 비정상적으로 표시될 수 있습니다.

직접 연결과 프록시 연결의 인증서 비교

같은 브라우저와 도메인을 사용해 두 경로에서 인증서 주체, SAN, 발급자, 유효 기간을 각각 기록하세요. CDN은 정상적으로 서로 다른 인증서를 사용할 수 있으므로 ‘인증서가 바뀌었다’는 이유만으로 가로채기가 있다고 단정하면 안 됩니다.
프록시 경로에서 발급자가 낯선 조직, 라우터 이름 또는 로컬 보안 제품 이름으로 바뀌었다면 해당 제품의 HTTPS 검사 기능과 네트워크 관리 정책을 확인하세요.
모든 HTTPS 웹사이트에서 서로 무관한 한 도메인의 인증서가 표시된다면 잘못된 게이트웨이, 인증 포털 또는 잘못된 서비스로 트래픽이 전달되는 상황을 먼저 의심하세요.

조직에서 관리하는 업무용 기기라면 관리자에게 조직 루트 인증서의 출처, 배포 방식, 사용 범위를 확인하세요. 개인 기기에서 디버깅 프록시를 사용한 적이 있다면 도구가 아직 실행 중인지, 시스템 프록시 설정이 남아 있는지 확인하세요. 더 이상 사용하지 않는 것이 확실하면 도구 설명서에 따라 관련 설정을 해제하세요. 시스템 인증서를 한꺼번에 삭제하거나 조직에서 관리하는 신뢰 항목을 임의로 제거하지 마세요.

서로 다른 두 가지 인증서 검증 구분하기

브라우저가 대상 웹사이트 인증서를 확인하는 것과 mihomo가 업스트림 TLS 노드 인증서를 확인하는 것은 서로 다른 단계입니다. 클라이언트 로그에 x509: certificate has expired처럼 노드 핸드셰이크 실패가 표시되고 브라우저에는 프록시 연결 중단이 나타난다면 노드 제공업체에 문의해 인증서 또는 서버 이름 설정을 확인하세요. 노드 설정의 skip-cert-verify는 대상 웹사이트에 대한 브라우저 인증서 경고를 해결하지 않습니다. 오히려 업스트림 서버 인증을 건너뛰게 됩니다.

3단계: DNS 변조, 잘못된 응답, 규칙 경로 확인

HTTPS 접속에는 ‘서버 찾기’와 ‘서버 신원 확인’ 두 단계가 있습니다. DNS가 잘못된 주소를 반환하면 브라우저가 다른 서버에 연결될 수 있으며, 그 서버가 다른 도메인의 인증서를 반환하면 이름 불일치 오류가 발생합니다. 이름 불일치는 웹사이트 자체의 CDN 설정 오류로도 생길 수 있으므로 DNS만 바꿔 보고 결론을 내리지 말고, 신뢰할 수 있는 다른 네트워크에서도 확인하세요.

Clash Verge의 ‘연결’ 페이지에서 오류가 발생한 도메인으로 필터링해 해당 연결에 적용된 규칙, 정책 그룹, 출구를 확인하세요. 페이지 이름은 버전에 따라 달라질 수 있으므로 현재 인터페이스를 기준으로 확인합니다.
테스트 중 자동으로 정책이 전환되지 않도록 사용 가능한 노드 하나를 임시로 고정하세요. 규칙 모드인지 글로벌 모드인지 기록하고, 점검이 끝나면 원래 설정으로 되돌리세요.
현재 적용 중인 설정에서 dns, nameserver, fallback, hosts를 확인하세요. 구독, 오버라이드 또는 스크립트가 최종 설정을 바꿀 수 있으므로 구독 원문만 확인해서는 안 됩니다.
시스템 hosts 파일에 해당 도메인의 오래된 매핑이 있는지 확인하세요. Windows의 일반적인 경로는 C:\Windows\System32\drivers\etc\hosts이며, macOS와 Linux에서는 /etc/hosts입니다.

fake-ip를 사용할 때 애플리케이션에 198.18.0.0/16 범위의 주소가 표시되는 것은 정상일 수 있으며, 실제 범위는 설정에 따라 달라집니다. 코어는 도메인과 가상 주소 간 매핑을 관리합니다. 가상 주소가 보인다고 DNS가 변조된 것은 아니며, fake-ip 주소를 브라우저 신뢰 목록에 추가할 필요도 없습니다.

Windows에서는 다음 명령으로 시스템 DNS 응답을 확인하고 시스템 캐시를 비울 수 있습니다. 하지만 브라우저의 보안 DNS, 코어 DNS, 프록시 측 DNS 조회는 서로 다른 경로를 사용할 수 있으므로 nslookup 결과만으로 프록시 연결에 실제로 어떤 주소가 사용됐는지 증명할 수는 없습니다.

nslookup example.com
ipconfig /flushdns

휴대폰 핫스팟으로 전환했을 때 정상 작동하고 원래 네트워크에서는 오류가 계속된다면 기존 네트워크의 DNS, 게이트웨이, 인증 상태를 확인하세요. 공용 네트워크에서 인증이 필요하면 시스템이 제공하는 네트워크 로그인 페이지를 이용하세요. 인증서 오류가 발생한 HTTPS 페이지에는 계정 정보를 입력하지 마세요.

4단계: 루트 인증서 업데이트 및 서버 인증서 체인 확인

운영체제를 오랫동안 업데이트하지 않으면 현재 사이트에서 사용하는 신뢰할 수 있는 루트 인증서가 없을 수 있습니다. 일부 브라우저는 별도의 신뢰 체계나 혼합된 신뢰 체계를 사용하므로 같은 기기에서 ‘한 브라우저는 정상이고 다른 브라우저는 오류가 발생하는’ 경우도 드물지 않습니다. 구형 브라우저는 웹사이트가 현재 사용하는 인증서 체인이나 TLS 기능을 지원하지 않을 수도 있습니다.

여러 웹사이트에서 알 수 없는 발급자 오류: 먼저 운영체제 보안 업데이트와 브라우저 업데이트를 설치하고, 정책에 의해 신뢰 저장소 업데이트가 차단되지 않았는지 확인한 다음 브라우저를 다시 시작해 테스트하세요.
웹사이트 한 곳에서만 오류: 서버에서 중간 인증서를 누락했을 수 있습니다. 일부 브라우저는 캐시를 사용하거나 인증서 체인을 추가로 가져올 수 있지만, 새 기기에서는 실패할 수 있습니다. 사이트 운영자가 완전한 인증서 체인을 제공하도록 수정해야 합니다.
특정 브라우저에서만 오류: 해당 브라우저 버전, 기업 정책, 인증서 관리 설정을 확인하세요. 모든 인증서를 모든 브라우저에 무작정 가져오지 마세요.
구형 시스템에서 보안 업데이트를 받을 수 없는 경우: 포럼에서 인증서 묶음을 내려받아 한꺼번에 가져오는 대신 지원되는 시스템 버전으로 이전하세요.

‘인증서가 만료되었습니다’라는 메시지는 최종 사용자 인증서의 만료를 뜻할 수도 있고, 중간 인증서나 루트 인증서의 체인 구성 문제를 뜻할 수도 있습니다. 오류 페이지의 한 줄만으로는 원인을 구분하기 어려우므로 인증서 체인에서 어느 단계가 실패했는지 확인하세요. 일반적으로 웹사이트에 접속하기 위해 해당 사이트의 최종 사용자 인증서를 직접 가져올 필요는 없습니다.

직접 연결과 프록시 연결을 비교해 문제 범위 좁히기

아래 예시에서는 로컬 HTTP 혼합 포트 7897을 사용하지만, 설치 환경에서도 반드시 같은 포트를 사용한다는 뜻은 아닙니다. 클라이언트 설정이나 현재 적용된 설정의 mixed-port 항목에서 실제 값을 먼저 확인하세요. 코어가 실행되고 있지 않으면 명령이 연결 오류를 반환하며, 아직 대상 웹사이트의 인증서 검증 단계에는 도달하지 않은 상태입니다.

Windows: 인증서 검증을 유지한 상태로 테스트

curl.exe --noproxy "*" -I https://example.com/
curl.exe --noproxy "" --proxy http://127.0.0.1:7897 -I https://example.com/

example.com을 오류가 발생한 도메인으로 바꾸세요. 첫 번째 명령은 curl에 설정된 명시적 프록시를 우회하고, 두 번째 명령은 프록시 제외 목록을 비운 뒤 로컬 HTTP 프록시를 지정합니다. macOS와 Linux에서는 curl.exe를 curl로 바꾸면 됩니다. 핸드셰이크 세부 정보를 확인하려면 -v를 추가하세요. 인증서 검증을 건너뛰는 -k는 추가하지 마세요.

비교 결과	다음 단계
직접 연결은 정상, 프록시에서는 인증서 오류	노드 출구, 프록시 측 DNS 조회, HTTPS 검사, 실제 적용된 규칙 확인
두 경로 모두 날짜 오류 발생	기기의 시간을 확인한 다음 웹사이트 인증서 유효 기간 확인
curl은 정상, 브라우저만 오류	브라우저 신뢰 체계, 보안 DNS, 확장 프로그램, 기업 정책 확인
모든 테스트에서 로컬 포트에 연결할 수 없음	먼저 코어 실행 상태나 포트 설정을 바로잡으세요. 인증서 문제로 처리할 상황이 아닙니다.

curl과 브라우저는 서로 다른 TLS 라이브러리와 신뢰 저장소를 사용할 수 있으므로 비교 결과는 원인 파악을 위한 단서이지 최종적인 보안 판단은 아닙니다. 로그를 공유하기 전에 구독 주소, 액세스 토큰, 프록시 인증 정보, 개인 도메인을 삭제하세요. 구독 링크에는 구독 정보를 확인하는 데 사용할 수 있는 자격 증명이 포함된 경우가 많습니다.

설정 복원 및 재검사 목록

한 번에 변수 하나만 바꾸세요. 먼저 시간을 바로잡고, 다음으로 인증서를 비교한 뒤 DNS 응답과 출구를 확인하고, 마지막으로 신뢰 저장소나 서버 인증서 체인을 점검합니다. 노드 변경, DNS 끄기, 모드 변경, 인증서 설치를 한꺼번에 하면 어떤 조치가 효과가 있었는지 판단하기 어렵습니다.

평소 사용하는 규칙 모드, 정책 그룹, TUN, 시스템 프록시 설정을 복원하고 점검 중 추가한 임시 규칙을 삭제하세요.
브라우저를 다시 열고 오류가 발생했던 도메인과 서로 관련 없는 HTTPS 웹사이트 두 곳에 접속해 인증서 경고가 더 이상 나타나지 않는지 확인하세요.
원래 웹사이트 인증서의 SAN에 접속한 도메인이 포함되어 있는지, 유효 기간이 맞는지, 현재 브라우저가 인증서 체인을 신뢰하는지 확인하세요.
특정 출구에서만 문제가 발생한다면 서비스 제공업체에 도메인, 발생 시각, 오류 코드, 민감 정보를 가린 로그를 전달하세요. 특정 사이트 한 곳에서만 문제가 발생한다면 사이트 운영자에게 인증서 체인 문제를 알리세요.

인증서 오류를 해결하는 목적은 경고 페이지를 없애는 것이 아니라 올바른 서버 인증을 복원하는 것입니다. 시스템 시간이 정확하고, 접속 도메인이 인증서와 일치하며, 인증서 체인을 신뢰할 수 있고, 트래픽 경로가 예상한 대로여야 점검이 끝난 것입니다. 프록시 모드, 구독, 규칙 항목에 대한 자세한 설명은 설정 참고를 확인하고, 자주 발생하는 연결 문제는 문제 해결에서 살펴보세요.