Clash 실행 후 브라우저에 인증서 오류가 표시될 때: HTTPS 오류와 프록시의 관계

HTTPS 인증서 오류란 무엇인가

브라우저가 HTTPS 웹사이트에 접속하면 먼저 대상 서버와 TLS 연결을 설정합니다. 서버는 인증서 체인을 반환하고, 브라우저는 인증서의 유효 기간, 발급 기관, 적용 도메인과 폐기 상태를 차례로 확인합니다. 어느 하나라도 조건을 충족하지 못하면 연결을 중단하고 인증서 오류를 표시할 수 있습니다. Clash는 네트워크 전달 경로에 위치하지만, 일반적인 시스템 프록시, HTTP 프록시, SOCKS5 프록시와 TUN 전달 자체가 웹페이지 내용을 자동으로 복호화하지는 않습니다.

HTTP 프록시를 예로 들면, 브라우저가 HTTPS 웹사이트에 접속할 때 먼저 로컬 프록시 포트로 CONNECT 요청을 보냅니다. 예를 들어 127.0.0.1:7890에 연결한 뒤 example.com:443으로 이어지는 터널을 설정하도록 요청합니다. 터널이 만들어진 뒤에도 TLS 핸드셰이크는 브라우저와 원격 서버 사이에서 진행됩니다. 중간 과정에서 HTTPS 복호화를 수행하지 않는 한 Clash는 웹페이지의 평문을 볼 수 없으며 웹사이트를 대신해 인증서를 발급하지도 않습니다.

브라우저 오류 코드별 점검 방향

오류 코드	일반적인 의미	우선 확인할 항목
`NET::ERR_CERT_DATE_INVALID`	인증서의 유효 기간이 아니거나 컴퓨터의 시간이 크게 어긋남	시스템 날짜, 시간대, 자동 시간 동기화, 웹사이트 인증서 기간
`NET::ERR_CERT_COMMON_NAME_INVALID`	인증서가 적용되는 도메인과 현재 접속 도메인이 일치하지 않음	DNS 오염, 노드 하이재킹, 잘못된 hosts 기록
`NET::ERR_CERT_AUTHORITY_INVALID`	인증서 체인을 신뢰할 수 있는 루트 인증서까지 연결할 수 없음	로컬 패킷 캡처 인증서, 기업 게이트웨이, 인증서 저장소 이상
`ERR_SSL_PROTOCOL_ERROR`	TLS 핸드셰이크가 중단되었으며 반환된 내용이 예상한 TLS 데이터가 아님	노드 가용성, 포트 전달, 프로토콜 설정, 네트워크 차단
`SEC_ERROR_UNKNOWN_ISSUER`	Firefox가 인증서 발급자를 신뢰할 수 없음	Firefox 독립 인증서 저장소, 로컬 중간 인증서

Clash를 켠 뒤에만 오류가 나타나는 이유

Clash를 켜면 연결에 사용되는 출구, DNS 해석 경로와 라우팅 규칙이 바뀝니다. 프록시를 켠 뒤 오류가 나타났다는 사실은 문제가 새 경로와 관련되어 있음을 의미할 뿐, Clash 코어가 인증서를 직접 변경했다는 뜻은 아닙니다. 실제로 점검할 때는 브라우저, 로컬 프록시, 규칙 매칭, 노드, 원격 DNS와 대상 서버의 여섯 단계로 경로를 나누어 확인해야 합니다.

노드가 요청을 잘못된 서버로 전달하는 경우

노드 출구에서 비정상적인 DNS를 사용하거나 경로에 도메인 하이재킹이 있으면 대상 도메인이 잘못된 IP로 해석될 수 있습니다. 브라우저는 원래 account.example.com에 접속했지만 원격 서버가 다른 사이트의 인증서를 반환하면 도메인 불일치 오류가 발생합니다. 이런 문제는 대개 일부 도메인에만 영향을 주며 다른 노드로 바꾸면 즉시 정상화됩니다.

인증서 세부 정보의 ‘발급 대상’ 항목도 확인할 수 있습니다. 현재 도메인과 인증서의 Subject Alternative Name이 전혀 관련 없다면 노드와 DNS를 중점적으로 점검하고, 브라우저의 ‘계속 방문’을 바로 클릭하지 마세요. 로그인 페이지, 결제 페이지와 계정 센터에서 도메인 불일치가 발생하면 계정과 비밀번호 입력을 중단해야 합니다.

로컬 프로그램이 HTTPS 복호화를 수행하는 경우

Charles, Fiddler, mitmproxy, 일부 디버깅 프록시, 기업용 단말 관리 프로그램과 보안 소프트웨어는 로컬 루트 인증서를 설치한 뒤 HTTPS 트래픽을 중간자 방식으로 복호화할 수 있습니다. 설정이 올바르면 브라우저가 로컬에서 발급한 임시 인증서를 신뢰하지만, 루트 인증서가 없거나 만료되었거나 잘못된 인증서 저장소에만 설치되어 있으면 발급 기관을 신뢰할 수 없다는 오류가 표시됩니다.

일반적인 경로는 브라우저가 먼저 Clash에 연결되고, Clash가 다시 다른 로컬 프록시로 트래픽을 전달하는 방식입니다. 운영체제에 오래된 PAC 주소가 남아 있는 경우도 있습니다. Clash 패널에서 시스템 프록시가 켜져 있다고 표시되어도 트래픽은 여러 프로세스를 거칠 수 있습니다. Windows에서는 「설정」→「네트워크 및 인터넷」→「프록시」에서 수동 프록시와 설정 스크립트를 확인하세요. macOS에서는 「시스템 설정」→「네트워크」→현재 네트워크→「세부사항」→「프록시」에서 웹 프록시, 보안 웹 프록시와 자동 프록시 구성을 확인할 수 있습니다.

시스템 시간 때문에 인증서가 아직 유효하지 않거나 이미 만료된 것으로 표시되는 경우

TLS 인증서에는 명확한 Not Before 및 Not After 시간이 포함됩니다. 컴퓨터 날짜가 하루 어긋나거나 시간대를 잘못 선택했거나, 장치가 절전 모드에서 깨어난 뒤 시계가 동기화되지 않으면 NET::ERR_CERT_DATE_INVALID가 발생할 수 있습니다. 프록시를 켠 시점과 시간 오류가 겹쳤을 뿐일 수도 있으며, 특히 시스템을 방금 재설치했거나 메인보드 배터리가 부족하거나 가상 머신을 스냅샷에서 복원한 경우에 흔합니다.

Windows 11에서는 「설정」→「시간 및 언어」→「날짜 및 시간」을 열어 ‘자동으로 시간 설정’과 ‘자동으로 시간대 설정’을 활성화한 뒤 ‘지금 동기화’를 클릭하세요. macOS에서는 「시스템 설정」→「일반」→「날짜와 시간」에서 자동 설정을 활성화할 수 있습니다. 동기화가 끝나면 현재 탭만 새로 고치지 말고 브라우저를 완전히 종료한 뒤 다시 열어야 합니다.

순서대로 진행하는 Clash 인증서 오류 문제 해결

다음 순서는 원인 범위를 빠르게 좁히기 위한 것입니다. 각 단계에서는 한 번에 하나의 변수만 바꾸고 결과를 기록하세요. 노드 변경, DNS 수정, 인증서 재설치와 브라우저 데이터 삭제를 동시에 진행하면 정상화된 뒤 실제 원인을 확인할 수 없습니다.

오류 코드를 빠짐없이 기록하세요. ‘안전하지 않은 연결’이라고만 기록하지 마세요. 주소 표시줄의 도메인, 브라우저 오류 코드와 인증서 발급자를 복사하고 오류가 발생한 시간도 확인하세요.
시스템 프록시를 끈 뒤 다시 테스트하세요. Clash 클라이언트에서 ‘시스템 프록시’를 끄고 브라우저를 완전히 종료한 다음 같은 주소를 방문하세요. 직접 연결은 정상이고 프록시에서만 오류가 발생한다면 문제 범위를 규칙, 노드 또는 프록시 경로로 좁힐 수 있습니다.
다른 경로의 노드로 전환하세요. 서로 다른 지역, 서비스 제공업체 또는 프로토콜의 노드를 우선 선택하세요. 전환 후 3~5초간 기다려 기존 연결을 종료한 다음 시크릿 창에서 테스트하세요.
프록시 모드를 잠시 전역으로 변경하세요. 전역 모드에서는 정상이고 규칙 모드에서 오류가 난다면 같은 페이지에 필요한 기본 도메인, API 도메인 또는 정적 리소스 도메인이 서로 다른 출구로 분리되었을 수 있습니다. 테스트가 끝나면 규칙 모드로 되돌리세요.
시스템 시간을 확인하세요. 연월일, 시, 분과 시간대를 점검하세요. 한국 국내에서는 일반적으로 UTC+09:00을 사용합니다. 작업 표시줄에 표시된 시간이 현재 시각과 비슷한지만 확인해서는 안 됩니다.
인증서 발급자를 확인하세요. 브라우저 주소 표시줄에서 인증서 세부 정보를 여세요. 발급자 이름이 로컬 디버깅 도구, 회사 게이트웨이 또는 보안 소프트웨어를 가리킨다면 해당 프로그램과 루트 인증서를 계속 점검하세요.
추가 프록시 계층을 중지하세요. 패킷 캡처 프로그램, 브라우저 프록시 확장 프로그램과 다른 프록시 클라이언트를 종료하고 시스템에서 하나의 프로그램만 예상 포트를 수신하고 있는지 확인하세요.
마지막으로 DNS와 설정 파일을 확인하세요. 소수의 도메인에서만 잘못된 인증서가 반환된다면 직접 연결과 프록시 경로의 해석 주소를 비교하고, 규칙이 관련 도메인을 잘못된 출구로 보내고 있지 않은지 확인하세요.

포트, 프록시 체인과 로컬 수신 상태 확인

클라이언트마다 기본 포트가 다를 수 있습니다. 설정에서 흔히 보이는 혼합 포트는 7890이고 SOCKS 포트는 7891, 외부 컨트롤 포트는 9090인 경우가 많습니다. 이는 일반적인 값일 뿐이며 실제 결과는 현재 설정과 클라이언트 설정 페이지를 기준으로 확인해야 합니다. 브라우저나 시스템 프록시가 오래된 포트를 가리키면 아직 실행 중인 다른 프로세스에 연결될 수 있습니다.

Windows PowerShell에서는 일반적인 포트를 어떤 프로세스가 수신 중인지 확인할 수 있습니다:

Get-NetTCPConnection -State Listen |
  Where-Object LocalPort -In 7890,7891,9090 |
  Select-Object LocalAddress,LocalPort,OwningProcess

Get-Process -Id <OwningProcess 숫자>

macOS 또는 Linux에서는 다음 명령을 사용할 수 있습니다:

lsof -nP -iTCP:7890 -sTCP:LISTEN
lsof -nP -iTCP:7891 -sTCP:LISTEN
lsof -nP -iTCP:9090 -sTCP:LISTEN

7890을 이전 버전 클라이언트, 디버깅 프록시 또는 다른 서비스가 사용 중이면 현재 Clash 클라이언트가 다른 포트를 자동으로 사용하거나 시작에 실패할 수 있습니다. 먼저 충돌하는 프로세스를 종료한 다음 클라이언트의 「설정」→「포트 설정」 또는 「설정」→「Clash 설정」으로 돌아가 Mixed Port, HTTP Port와 SOCKS Port를 확인하세요. 메뉴 이름은 클라이언트마다 다를 수 있지만 포트 값은 시스템 프록시에 입력된 값과 일치해야 합니다.

상위 프록시가 있는지 확인

mihomo 설정에서는 프록시 프로바이더, 체인 프록시 또는 dialer-proxy 등의 기능을 통해 연결이 다른 프록시를 거치게 할 수 있습니다. 브라우저 확장 프로그램이 시스템 프록시를 덮어쓸 수도 있습니다. 점검할 때는 가장 짧은 경로를 먼저 유지하세요. 브라우저는 시스템 프록시를 사용하고, 시스템 프록시는 Clash의 Mixed Port를 직접 가리키며, Clash는 확실히 작동하는 일반 노드 하나를 선택하도록 구성합니다. 경로가 복구된 뒤 중계와 확장 기능을 하나씩 다시 추가하세요.

명령줄로 테스트한다면 직접 연결과 로컬 프록시가 반환하는 인증서 정보를 각각 비교할 수 있습니다. 다음 예시는 요청 헤더만 전송하며 계정 데이터는 제출하지 않습니다:

curl -I https://example.com/
curl -I --proxy http://127.0.0.1:7890 https://example.com/

직접 연결은 성공하지만 프록시 요청에서 인증서 오류가 표시되면 두 번째 명령을 다른 노드로 바꿔 반복하세요. 노드 하나에서만 실패한다면 일반적으로 시스템 인증서 저장소를 수정할 필요가 없습니다. 해당 노드를 비활성화하고 도메인, 시간과 오류 코드를 노드 제공업체에 전달하세요.

DNS, 규칙 모드와 TUN이 인증서 결과에 미치는 영향

인증서 검증은 도메인을 기준으로 이루어지지만 연결은 최종적으로 IP 주소에 도달해야 합니다. Clash의 DNS 모듈, Fake-IP 모드, 규칙 분할과 노드의 원격 해석이 실제 연결 대상을 함께 결정합니다. 설정이 일치하지 않으면 브라우저 주소 표시줄의 도메인은 그대로인데도 서버가 다른 도메인의 인증서를 반환할 수 있습니다.

규칙 모드에서 출구가 일치하지 않는 경우

현대적인 웹페이지는 기본 사이트, 로그인 API, 콘텐츠 전송 네트워크와 타사 리소스를 동시에 요청하는 경우가 많습니다. 기본 도메인은 프록시를 사용하고 API 도메인은 직접 연결한다고 해서 자동으로 인증서 오류가 발생하는 것은 아닙니다. 다만 지역 제한, 기업 내부 DNS 또는 지역별 CDN 환경에서는 출구가 다르면 서로 다른 주소를 받을 수 있습니다. 클라이언트의 연결 기록을 열고 오류가 발생한 시간대에 대상 도메인을 찾아 적용된 규칙과 프록시 그룹을 확인하세요.

전역 모드로 잠시 전환한 뒤 정상화된다면 같은 서비스의 도메인에 일관된 규칙을 추가할 수 있습니다. 기본 도메인과 하위 도메인을 같은 프록시 그룹으로 보내야 한다면 실제 도메인에 맞춰 다음과 같이 규칙을 추가하세요:

rules:
  - DOMAIN,login.example.com,PROXY
  - DOMAIN-SUFFIX,example.com,PROXY
  - MATCH,DIRECT

규칙은 위에서 아래 순서로 매칭됩니다. 더 구체적인 도메인 규칙은 포괄적인 규칙보다 앞에 배치해야 합니다. 예시 도메인을 실제 설정에 그대로 입력하지 말고 연결 기록으로 실제 요청 도메인을 확인하세요.

Fake-IP와 DNS 하이재킹

Fake-IP 모드는 로컬 컴퓨터에 매핑 주소를 반환한 뒤 코어가 도메인을 기준으로 규칙 적용과 실제 해석을 수행합니다. 브라우저에 198.18.0.0/16 범위의 주소가 표시된다고 해서 인증서가 교체된 것은 아닙니다. 이는 Clash에서 흔히 사용하는 내부 매핑 방식입니다. 실제로 확인해야 할 것은 트래픽이 코어에 의해 올바르게 인계되었는지, 대상 도메인이 부적절한 Fake-IP 필터 목록에 들어갔는지입니다.

TUN 모드는 일반적으로 더 많은 애플리케이션 트래픽을 인계하며 DNS 하이재킹과 함께 사용해 53번 포트의 조회를 코어로 전달할 수 있습니다. 시스템에서 기업 VPN, 게임 가속기, 가상 머신 네트워크 또는 다른 TUN 드라이버를 동시에 실행하면 라우팅과 DNS가 충돌할 수 있습니다. 테스트할 때는 클라이언트의 「설정」→「TUN 모드」에서 TUN을 잠시 끄고 시스템 프록시만 유지하세요. 인증서 오류가 사라진다면 출처가 불분명한 루트 인증서를 가져오지 말고 라우팅 테이블, DNS 하이재킹과 다른 가상 네트워크 어댑터를 계속 점검해야 합니다.

도메인 해석 결과 비교

Windows에서는 Resolve-DnsName, macOS와 Linux에서는 dig를 사용할 수 있습니다. 먼저 Clash를 끈 상태에서 한 번 조회한 뒤 켜고 다시 조회하세요. Fake-IP 모드에서 결과가 달라지는 것은 예상된 동작이므로 Clash 연결 기록과 함께 실제 대상이 무엇인지 확인해야 합니다. Redir-Host 모드에서 완전히 다른 공인 주소가 반환된다면 nameserver, fallback, 프록시 노드의 원격 해석과 로컬 hosts 파일을 점검하세요.

Resolve-DnsName example.com
nslookup example.com

dig example.com A
dig example.com AAAA

인증서 저장소와 브라우저 차이에 대응하는 방법

Chrome과 Edge는 일반적으로 운영체제의 인증서 기능을 사용하지만 플랫폼별 구현 세부 사항은 완전히 같지 않습니다. Firefox는 자체 인증서 저장소를 사용할 수 있으므로 Chrome은 정상인데 Firefox에서 SEC_ERROR_UNKNOWN_ISSUER가 발생하는 경우가 있습니다. 한 브라우저에서만 오류가 발생한다면 먼저 해당 브라우저의 확장 프로그램, 프록시 설정, 인증서 저장소와 보안 정책을 점검하세요.

Windows 인증서 확인

Win + R을 누르고 certmgr.msc를 입력하면 현재 사용자 인증서를 확인할 수 있습니다. 「신뢰할 수 있는 루트 인증 기관」→「인증서」에서 더 이상 사용하지 않는 패킷 캡처 도구의 인증서가 있는지 중점적으로 확인하세요. 시스템 루트 인증서를 일괄 삭제하거나 출처가 불분명한 안내에 따라 인증서를 임의로 가져오지 마세요. 인증서가 이미 제거한 디버깅 도구의 것임이 분명하다면 해당 도구의 제거 안내를 먼저 확인한 뒤 관련 인증서만 삭제하세요.

macOS 키체인 확인

「응용 프로그램」→「유틸리티」→「키체인 접근」을 열고 ‘로그인’과 ‘시스템’ 키체인을 각각 확인하세요. 오류 페이지의 인증서 세부 정보에 표시된 발급자 이름을 검색하고 인증서 유효 기간과 신뢰 설정을 점검하세요. 기업이나 학교에서 관리하는 장치에는 구성 프로파일로 인증서가 설치되어 있을 수 있으므로 직접 삭제하지 말고 네트워크 관리자에게 확인을 요청해야 합니다.

Firefox 별도 확인

「설정」→「개인 정보 및 보안」→「인증서」→「인증서 보기」를 열어 ‘인증 기관’ 목록을 확인하세요. 또한 「설정」→「일반」→「네트워크 설정」에서 Firefox가 시스템 프록시, 수동 프록시 또는 자동 프록시 구성을 사용하는지 확인해야 합니다. 시스템 프록시가 이미 Clash를 가리키는데 Firefox가 다른 포트를 수동으로 가리키고 있다면 다른 브라우저와 경로가 달라집니다.

Clash 로그로 장애 위치 확인

인증서 검증이 브라우저 측에서 수행되면 Clash 로그에 ‘certificate invalid’가 직접 표시되지 않을 수 있습니다. 로그에는 연결 대상, 적용된 규칙, 노드 이름과 하위 계층의 핸드셰이크 오류가 주로 기록됩니다. 문제를 점검하는 동안 로그 수준을 일시적으로 info 또는 debug로 높여 한 번 재현한 뒤 즉시 원래대로 되돌리세요. 장시간 많은 기록이 쌓이는 것을 방지할 수 있습니다.

i/o timeout: 연결 또는 핸드셰이크 시간이 초과되었습니다. 노드 품질, 대상 접근 가능 여부와 방화벽을 우선 확인하세요.
connection refused: 대상 포트 또는 상위 프록시가 연결을 거부했습니다. 포트, 프로토콜과 서비스 상태를 확인하세요.
tls handshake timeout: 제한 시간 안에 TLS 핸드셰이크가 완료되지 않았습니다. 회선 패킷 손실, 노드 이상 또는 대상의 제한이 원인일 수 있습니다.
remote error: tls: 원격 서버가 TLS 세션을 직접 종료했습니다. 전후 로그와 대상 도메인을 함께 확인해야 합니다.
no such host: 도메인 해석에 실패했습니다. DNS 설정, 네트워크 접근 가능 여부와 도메인 철자를 중점적으로 확인하세요.

로그에 예상한 규칙과 일치하고 다른 노드를 통해서도 연결이 성공하는데 브라우저에 여전히 로컬 발급자 인증서가 표시된다면 문제는 브라우저와 Clash 사이에 있을 가능성이 큽니다. 반대로 특정 노드에서만 핸드셰이크 시간 초과나 잘못된 대상 주소가 발생한다면 해당 노드를 비활성화하고 브라우저 보안 설정을 낮춰 우회하지 마세요.

복구 후 설정 마무리

원인을 찾았다면 점검 중 적용한 임시 변경을 되돌리세요. 전역 모드를 규칙 모드로 복원하고, 로그 수준을 정상으로 되돌리며, 사용하지 않는 수동 프록시를 끄고, TUN과 시스템 프록시가 평소 사용 목적에 맞는지 확인하세요. 규칙을 수정했다면 최소한 홈 페이지, 로그인 API와 자주 사용하는 리소스 도메인을 테스트해 예상한 프록시 그룹에 매칭되는지 확인해야 합니다.

검증을 마친 정상 작동 설정 사본을 보관하고 클라이언트 이름, 코어 버전, Mixed Port, DNS 모드와 문제가 발생한 노드를 기록해 두면 좋습니다. 다음에 인증서 오류가 다시 발생했을 때 모든 설정을 초기화하거나 재설치하는 것보다 이 항목들을 먼저 비교하는 편이 차이를 찾기 쉽습니다.