프록시 사용 후 HTTPS 인증서 오류가 뜰 때: 주요 원인과 단계별 해결 방법

인증서 검증은 유지한 채 어느 구간에서 연결 문제가 생겼는지 확인하세요. 일반적인 HTTP CONNECT 또는 SOCKS 전달은 웹사이트의 HTTPS를 복호화하지 않습니다. Clash 클라이언트가 트래픽을 정상적으로 전달하는 데 브라우저에 루트 인증서를 설치할 필요도 없습니다. 프록시를 켠 뒤 갑자기 오류가 발생했다면 연결 경로가 달라진 것이지만, 그것만으로 클라이언트 손상이나 노드 경로 조작을 단정할 수는 없습니다.

1. 먼저 브라우저 인증서 오류인지 노드 TLS 핸드셰이크 실패인지 구분하세요

certificate라는 문구가 같아도 오류가 나타나는 위치에 따라 확인 대상은 다릅니다. 브라우저는 대상 웹사이트의 인증서를 검사합니다. TLS를 사용하는 프록시 프로토콜에서는 코어가 노드 서버 인증서를 검사할 수도 있습니다. 두 문제를 혼동하지 마세요.

오류 위치와 내용	주요 원인	먼저 확인할 항목
브라우저 `NET::ERR_CERT_DATE_INVALID`	인증서 유효 기간과 기기 시간이 맞지 않음	시스템 날짜, 시간대, 인증서 유효 시작일과 만료일
브라우저 `NET::ERR_CERT_COMMON_NAME_INVALID`	접속한 도메인과 인증서 이름이 일치하지 않음	주소창의 도메인, 인증서 SAN, DNS, 인증 포털
브라우저 `NET::ERR_CERT_AUTHORITY_INVALID`	인증서 체인을 신뢰할 수 있는 루트까지 연결할 수 없음	발급자, 시스템 신뢰 저장소, 패킷 캡처 도구 또는 보안 소프트웨어
클라이언트 로그 `x509: certificate signed by unknown authority`	특정 TLS 연결의 인증서 체인을 코어가 신뢰하지 않음	같은 로그에 표시된 대상 주소와 연결 용도
클라이언트 로그 `x509: certificate has expired or is not yet valid`	연결 대상 서비스의 인증서가 만료되었거나 아직 유효하지 않음 또는 기기 시간 오류	시간 동기화, 노드 또는 구독 서버 인증서

로그의 TLS 오류는 노드가 아니라 구독 다운로드, 속도 측정 주소 또는 암호화 DNS 서비스에서 발생했을 수도 있습니다. 대상 호스트 이름, 오류 시각, 수행한 작업을 함께 기록하세요. x509 한 줄만 잘라서 남기지 마세요. 브라우저에 ERR_PROXY_CONNECTION_FAILED가 표시되면 인증서 설정을 바꾸기보다 먼저 로컬 수신 포트와 클라이언트 실행 여부를 확인하세요.

2. 시스템 시간과 인증서 유효 기간부터 확인하세요

시간이 잘못되면 정상적인 웹사이트도 여러 곳에서 한꺼번에 접속에 실패할 수 있습니다. 컴퓨터를 오랫동안 끈 뒤, 가상 머신 스냅샷을 복원한 뒤, 메인보드 배터리에 문제가 생긴 뒤에는 특히 먼저 확인하세요. 작업 표시줄의 시각만 보지 말고 연도, 날짜, 시간대도 확인해야 합니다.

Windows 11: 「설정」→「시간 및 언어」→「날짜 및 시간」으로 이동해 「시간 자동 설정」을 켜고 시간대를 확인한 다음 「지금 동기화」를 선택하세요.
macOS: 「시스템 설정」→「일반」→「날짜 및 시간」으로 이동해 「시간 및 날짜 자동 설정」과 시간대 자동 설정 옵션을 확인하세요.
Android: 기본 시스템에서는 보통 「설정」→「시스템」→「날짜 및 시간」에서 설정합니다. 제조사에 따라 「추가 설정」에 있을 수 있습니다. 날짜 및 시간 자동 설정과 시간대 자동 설정을 확인하세요.
브라우저 오류 페이지의 「고급」 메뉴나 인증서 보기 기능에서 유효 기간을 확인하세요. 메뉴 이름은 브라우저 버전에 따라 다를 수 있으니 「유효 시작일」과 「만료일」을 기록하면 됩니다.

기기 시간이 정확하고 다른 웹사이트는 정상인데 한 사이트에서만 만료 오류가 난다면 웹사이트 운영자가 인증서를 갱신해야 할 가능성이 큽니다. 노드를 바꿔도 만료된 인증서가 다시 유효해지지는 않습니다. 여러 사이트에서 같은 시각에 오류가 시작됐다면 구독을 반복해서 갱신하기보다 시스템 시간이나 일괄 차단 소프트웨어부터 확인하세요.

3. 테스트 조건을 고정하고 직접 연결과 프록시 경로를 비교하세요

항상 같은 전체 HTTPS 주소로 테스트하고 한 번에 조건 하나만 바꾸세요. 노드를 바꾸고 DNS를 수정하고 TUN까지 켜면 어떤 변경이 영향을 줬는지 알 수 없습니다. 먼저 현재 규칙 모드, 선택한 노드, 시스템 프록시 상태, TUN 상태를 기록하세요.

다음 네 단계로 비교해 보세요

Clash 클라이언트의 시스템 프록시와 TUN을 끄고, 다른 VPN이나 브라우저 프록시 확장 프로그램이 트래픽을 가로채지 않는지 확인한 뒤 대상 웹사이트에 접속하세요.
시스템 프록시만 켜고 TUN은 끈 상태에서 기존 노드로 다시 접속하세요. 클라이언트의 「연결」 페이지에서 대상 도메인이 실제로 노드를 거치는지 DIRECT로 연결되는지 확인하세요.
나머지 설정은 그대로 두고 정상 작동이 확인된 다른 노드로만 바꾼 다음 같은 주소에 접속하세요.
같은 클라이언트 설정을 유지한 채 휴대전화 핫스팟으로 다시 테스트하세요. 이 단계는 현재 로컬 네트워크와 기기 자체의 문제를 구분하는 데 도움이 됩니다.

직접 연결로 원래 접속할 수 없는 사이트라면 직접 연결 실패는 인증서 비교에 도움이 되지 않습니다. 시간 초과와 인증서 오류를 같은 결과로 기록하지 마세요. 일반 시크릿 창도 깨끗한 인증서 환경을 뜻하지 않습니다. 시스템 루트 인증서를 그대로 사용할 수 있으므로 기업 보안 소프트웨어 여부를 배제할 수 없습니다.

명령어로 TLS 핸드셰이크 정보 확인하기

다음은 Windows PowerShell 예시입니다. 7890은 예시 포트이므로 실행 전에 클라이언트의 현재 HTTP 또는 혼합 수신 포트로 바꾸세요. SOCKS 전용 포트에는 그대로 사용할 수 없습니다. 두 번째 테스트를 하려면 클라이언트가 해당 포트에서 연결을 받고 있어야 하며, 환경 변수 NO_PROXY로 인해 테스트 도메인이 프록시를 우회하지 않는지도 확인하세요.

PowerShell · 직접 연결 및 명시적 HTTP 프록시

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

인증서 검증을 건너뛰는 옵션은 사용하지 않았습니다. 첫 번째 명령은 애플리케이션 프록시만 우회합니다. TUN이 계속 실행 중이면 트래픽이 여전히 가로채일 수 있으므로 직접 연결을 비교하기 전에 TUN을 꺼야 합니다. curl 빌드마다 사용하는 신뢰 저장소가 다르므로 브라우저의 인증서 정보와 함께 결과를 살펴보세요. 명령 한 번이 성공했다고 브라우저의 신뢰 저장소 문제를 배제할 수는 없습니다.

4. Fake-IP와 DNS 확인: 도메인이 잘못된 서버로 연결되는지 확인하세요

Fake-IP 자체가 웹사이트 인증서를 바꾸지는 않습니다. mihomo의 Fake-IP 모드에서는 DNS가 합성 주소를 반환하고, 코어는 도메인과 주소의 매핑을 저장한 뒤 연결 경로를 결정합니다. 설정에서 198.18.0.1/16을 사용한다면 해당 범위의 주소가 조회되는 것은 정상일 수 있습니다. 이는 공용 서버의 실제 주소가 아니지만 DNS 오염을 뜻하는 것도 아닙니다.

DNS가 변조되거나 경로가 잘못된 서비스로 연결되거나 이전 연결과 매핑 상태가 일치하지 않으면 브라우저가 현재 도메인에 속하지 않는 인증서를 받을 수 있습니다. 반면 잘못된 매핑은 시간 초과만 일으키고 인증서 경고는 표시하지 않을 수도 있습니다. 인증서 이름과 실제 연결 기록을 함께 확인해야 합니다.

먼저 근거를 확인하고 DNS 설정을 바꾸세요

Windows PowerShell에서 Resolve-DnsName example.com을 실행해 반환된 주소를 확인하세요. 예시 도메인은 실제 오류가 발생한 도메인으로 바꾸면 됩니다.
클라이언트의 「연결」 또는 로그 화면에서 도메인, 일치한 규칙, 아웃바운드 노드를 확인하세요. 시스템 명령으로 조회한 DNS가 브라우저에서 사용한 DNS와 다를 수도 있습니다.
Chrome의 「설정」→「개인 정보 보호 및 보안」→「보안」에서 「보안 DNS 사용」 설정을 확인할 수 있습니다. 비교 테스트를 위해 잠시만 변경하고 원래 값은 기록해 두세요. DoH 트래픽도 TUN을 통과할 수 있습니다.
방금 DNS 모드를 바꿨다면 관련 웹페이지와 브라우저 연결을 먼저 닫고 필요하면 클라이언트를 다시 시작하세요. Windows에서는 ipconfig /flushdns를 실행해 시스템 DNS 캐시를 지울 수 있습니다. 이 명령으로 브라우저 캐시나 코어의 매핑이 모두 지워지는 것은 아닙니다.

다음은 필드를 확인하기 위한 mihomo DNS 설정 예시이며 인증서 오류를 해결하는 완성된 설정은 아닙니다. DNS 업스트림, 라우팅, 클라이언트 오버라이드는 현재 환경에 맞게 구성해야 합니다.

YAML · DNS 필드 예시

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16

특정 앱이 Fake-IP와 호환되지 않는 것이 확인된 경우에만 원인을 살펴본 뒤 fake-ip-filter 적용을 검토하세요. 모든 도메인을 한꺼번에 제외하지는 마세요. 구독에서 관리하는 설정은 다음 업데이트 때 원래 값으로 돌아가지 않도록 클라이언트가 지원하는 오버라이드 기능으로 수정하세요. 다른 설정 방법은 고급 설정에서 확인할 수 있습니다.

5. 중간자 패킷 검사 인증서, 기업 HTTPS 검사, 공용 Wi-Fi

서로 관련 없는 여러 웹사이트에서 같은 로컬 조직이나 보안 제품이 발급자로 표시된다면 HTTPS 검사 기능을 확인하세요. Fiddler, Charles, mitmproxy 같은 디버깅 도구는 루트 인증서를 설치하고 신뢰하도록 설정하면 HTTPS를 복호화할 수 있습니다. 일부 기업 게이트웨이와 엔드포인트 보안 소프트웨어도 비슷한 기능을 제공합니다. 이는 Clash 클라이언트가 일반적인 방식으로 HTTPS를 전달하는 것과는 다릅니다.

인증서 출처 확인 방법

오류 페이지나 인증서 뷰어에서 주체 대체 이름(SAN), 발급자, 유효 기간, 인증서 체인을 기록하세요. SAN에는 주소창에서 접속한 도메인이 포함되어야 합니다.
패킷 캡처 도구를 종료하고 시스템 프록시가 여전히 해당 도구의 수신 포트를 가리키는지 확인하세요. 도구 창을 닫았다고 시스템 프록시 설정까지 원래대로 돌아오는 것은 아닙니다.
Windows에서는 certmgr.msc로 현재 사용자 인증서를 볼 수 있습니다. certlm.msc로 로컬 컴퓨터 인증서를 보려면 일반적으로 해당 권한이 필요합니다. macOS에서는 「키체인 접근」에서 인증서와 신뢰 설정을 확인할 수 있습니다.
개인 기기에서는 출처를 확인한 디버깅 인증서만 처리하세요. 회사에서 관리하는 기기라면 인증서를 일괄 삭제하지 말고 먼저 관리자에게 문의하세요.

브라우저와 명령줄 도구는 서로 다른 인증서 신뢰 저장소를 사용할 수 있으므로 브라우저는 정상인데 curl에서 오류가 나거나 그 반대일 수 있습니다. 루트 인증서를 추가하기 전에 HTTPS 검사 기능이 실제로 기기 관리 정책에 따른 것인지, 인증서 출처를 신뢰할 수 있는지 확인하세요.

6. 특정 노드에서만 오류가 발생하면 SNI와 인증서 체인을 확인하세요

같은 기기, 같은 웹사이트, 같은 DNS 설정에서 특정 노드로 바꿀 때만 오류가 발생한다면 해당 노드 사용을 일시 중지하세요. 클라이언트가 노드에 연결하지 못하는 문제인지, 노드 연결은 성공했지만 브라우저가 비정상적인 웹사이트 인증서를 받은 것인지 구분해야 합니다.

클라이언트 로그에 노드 TLS 오류가 표시되는 경우

TLS를 사용하는 노드에서는 연결 주소와 인증서 검증에 사용하는 이름이 다를 수 있습니다. mihomo는 프로토콜에 따라 사용하는 필드도 다릅니다. 예를 들어 VMess와 VLESS에서는 보통 servername, Trojan에서는 보통 sni를 사용합니다. 해당 프로토콜 문서와 서비스 제공자가 안내한 설정값을 확인하세요. 하나의 필드 이름을 모든 노드에 적용하면 안 됩니다.

연결 주소에 IP를 입력했다면 인증서 SAN에 해당 IP가 포함되지 않을 수 있습니다. 서비스 제공자에게 올바른 서버 이름과 연결 설정을 확인하세요.
로그에 인증서 만료 또는 체인 누락이 표시된다면 노드 운영자가 인증서를 갱신하고 중간 인증서를 보완해야 합니다. 사용자 측에서 규칙을 바꿔 서버 인증서를 고칠 수는 없습니다.
skip-cert-verify는 해당 노드 연결의 인증서 검증에만 영향을 주며 대상 웹사이트에 대한 브라우저의 인증서 검증을 고치지는 않습니다. 오류를 숨기려고 true로 바꾸지 마세요.

브라우저에서 비정상적인 웹사이트 인증서를 받은 경우

일반적인 전달 노드에는 대상 웹사이트의 개인 키가 없으므로 브라우저가 신뢰하는 웹사이트 인증서를 임의로 발급할 수 없습니다. 비정상적인 인증서는 DNS 오류, 출구 네트워크의 인증 또는 차단, 원격 설정 오류, 악의적인 간섭과 관련이 있을 수 있습니다. 한 번의 오류만으로 경로 조작을 단정할 수는 없지만, 해당 경로에서 민감한 작업은 중단하는 것이 안전합니다.

해당 노드에서 받은 인증서 정보를 기록한 뒤 다른 신뢰할 수 있는 네트워크나 노드로 비교 테스트하세요. CDN 출구가 다르면 정상적으로 다른 인증서와 발급 기관을 사용할 수 있으므로 발급자가 다르다는 이유만으로 경로 조작을 단정하지 마세요. 도메인 포함 여부, 유효 기간, 신뢰할 수 있는 인증서 체인, 반복 테스트 결과가 중요합니다.

7. 결과에 따라 마무리하기: 수정, 재테스트, 문의 정보 정리

문제를 한 가지 수정한 뒤 처음 오류가 발생한 전체 주소로 다시 테스트하고 별개의 웹사이트도 하나 더 확인하세요. 웹페이지가 열린다고 끝난 것은 아닙니다. 규칙 모드, 시스템 프록시, TUN이 의도한 상태로 복구됐는지, 테스트를 위해 켠 전역 라우팅이나 임시 DNS 설정이 남아 있지 않은지도 확인하세요.

비교 결과	우선 확인할 항목
모든 네트워크에서 여러 웹사이트에 날짜 오류가 발생함	기기 시간을 맞춘 뒤 시스템 업데이트와 신뢰 저장소를 확인하세요
경로를 바꿔도 특정 웹사이트에서만 만료 오류가 발생함	인증서 검증을 우회하지 말고 웹사이트 운영자에게 문의하세요
현재 Wi-Fi에서만 문제가 생기고 핫스팟에서는 정상임	인증 포털, 게이트웨이 DNS, 네트워크의 HTTPS 검사 기능을 확인하세요
특정 노드에서만 문제가 발생함	해당 노드를 사용 중지하고 노드 TLS 설정과 출구 경로를 확인하세요
특정 브라우저에서만 문제가 발생함	브라우저 정책, 확장 프로그램, 별도 신뢰 저장소, 보안 DNS를 확인하세요

문제를 문의할 때 다음 정보를 함께 보내세요

운영체제 버전, Clash 클라이언트 이름과 버전, mihomo 코어 버전. 단순히 '최신 버전'이라고만 적지 마세요.
전체 오류 코드와 발생 시각, 오류가 브라우저에서 표시됐는지 클라이언트 로그에 기록됐는지 알려 주세요.
대상 도메인, 인증서 SAN, 발급자, 유효 기간을 포함하세요. URL의 쿼리 문자열에 개인 정보가 있으면 삭제하세요.
시스템 프록시와 TUN 상태, 실제 수신 포트, 규칙 모드, 직접 연결·노드 A·노드 B의 비교 결과를 알려 주세요.
문제와 관련된 로그만 필요한 만큼 첨부하세요. 먼저 구독 주소, 액세스 토큰, 노드 비밀번호, 외부 컨트롤 키를 삭제하세요.

다음 순서로 확인하면 됩니다: 오류 위치 → 시스템 시간 → 연결 경로 비교 → DNS 및 인증서 출처 → 노드 설정. 단계마다 근거를 확인할 수 있으므로 처음부터 클라이언트를 재설치하거나 YAML을 크게 수정할 필요가 없습니다. 기본 설정 가져오기와 프록시 설정은 사용 가이드를 참고하세요. 일반적인 연결 문제는 도움말 센터에서 더 확인할 수 있습니다.