Clash 사용 후 인증서 오류가 뜰 때: 시스템 시간·중간자·TUN 점검 순서
프록시 사용 중 NET::ERR_CERT 오류가 발생한다면 시스템 시간, 노드 연결, TUN과 보안 프로그램 충돌을 확인하세요. 쉬운 단계부터 점검하는 순서와 각 단계의 판단 기준을 안내합니다.
오류 내용을 먼저 기록하고 시간·노드·TUN 순서로 점검
‘계속 방문’을 누르거나 상대방이 급히 보내 준 루트 인증서를 설치하지 마세요. HTTPS 인증서 오류는 브라우저가 현재 연결 대상의 신원을 확인하지 못했다는 뜻이며, ‘프록시 속도가 느리다’는 의미가 아닙니다. 일반적인 Clash 프록시 전달은 브라우저에 인증서 검증을 포기하라고 요구하지 않습니다. mihomo의 TUN이 트래픽을 처리한다고 해서 HTTPS를 복호화하는 것도 아닙니다.
이메일, 결제 페이지 또는 관리자 화면을 열고 있다면 비밀번호 입력부터 중단하세요. 오류 코드, 접속 도메인, 인증서 발급자와 발생 시각을 기록한 뒤 비교합니다. 이 글의 포트와 도메인은 점검 방법을 설명하기 위한 예시이며, 클라이언트의 기본 설정이나 사이트에서 직접 확인한 결과를 뜻하지 않습니다.
- 시스템 날짜와 시간대, 인증서 유효 기간을 확인해 컴퓨터 시계 오류를 배제합니다.
- 프록시를 완전히 종료한 결과를 확인한 다음 두 노드를 비교합니다.
- 인증서의 도메인과 발급자를 확인해 포털 페이지나 HTTPS 검사 여부를 판단합니다.
- TUN만 전환하고 DNS, 라우팅, 보안 프로그램을 확인합니다.
- 명령줄로 결과를 재확인하고 근거에 따라 되돌릴 설정을 결정합니다.
오류 코드 구분하기: 인증서 오류와 TLS 핸드셰이크 실패는 다릅니다
Chromium 계열 브라우저에서는 보통 NET::ERR_CERT_로 시작하는 오류 코드가 표시됩니다. Firefox는 문구와 코드가 다를 수 있지만, 확인할 항목은 시간, 인증서 체인, 도메인, 신뢰 출처로 같습니다. ‘안전한 연결을 설정할 수 없음’이라는 문구만 기억하지 말고 전체 오류 코드를 적어 두세요.
| 오류 예시 | 주요 의미 | 우선 확인할 항목 |
|---|---|---|
NET::ERR_CERT_DATE_INVALID |
컴퓨터에서 인증서가 아직 유효하지 않거나 만료된 것으로 판단 | 시스템 시간, 인증서 유효 시작일과 만료일 |
NET::ERR_CERT_AUTHORITY_INVALID |
인증서 체인이 신뢰할 수 있는 루트 인증서로 이어지지 않음 | 발급자, 체인의 완전성, HTTPS 검사 여부 |
NET::ERR_CERT_COMMON_NAME_INVALID |
인증서가 현재 호스트 이름과 일치하지 않음 | 인증서 SAN, 포털 리디렉션, DNS 및 hosts |
NET::ERR_CERT_REVOKED |
인증서가 폐기된 것으로 판단됨 | 인증서 정보, 사이트 또는 보안 제품 상태 |
ERR_SSL_PROTOCOL_ERROR |
TLS 프로토콜 협상 오류로, 유효한 인증서를 받지 못했을 수도 있음 | 프록시 포트, 프로토콜, 네트워크 장비, 서버 |
오류가 발생하는 범위도 중요합니다. 특정 도메인 하나에서만 문제가 생기면 해당 사이트나 그 사이트에 적용된 규칙을 먼저 의심하세요. 서로 관련 없는 HTTPS 사이트 여러 곳에서 동시에 오류가 나면 컴퓨터 시간, 신뢰 저장소, 공통으로 거치는 네트워크 장비부터 확인합니다. 어느 경우든 ‘방금 Clash를 켰다’는 이유만으로 코어가 손상됐다고 단정할 수는 없습니다.
1단계: 시스템 시간과 인증서 유효 기간 확인
시스템 시간 자동 동기화 후 같은 주소에 다시 접속
Windows 11에서는 ‘설정’ → ‘시간 및 언어’ → ‘날짜 및 시간’에서 ‘자동으로 시간 설정’을 확인하고 ‘지금 동기화’를 누르세요. macOS에서는 ‘시스템 설정’ → ‘일반’ → ‘날짜 및 시간’에서 날짜와 시간 자동 설정 상태를 확인합니다. 조직에서 관리하는 기기라 설정을 바꿀 수 없다면 관리자에게 문의하세요.
- 먼저 연도, 월, 날짜를 확인하세요. 절전 모드에서 깨어난 뒤나 메인보드 배터리에 문제가 있을 때 시계가 과거로 되돌아갈 수 있습니다.
- 시간대도 확인하세요. 현지 시간이 맞아 보여도 UTC 시간이 틀릴 수 있으므로 시계를 눈으로만 확인하지 마세요.
- 브라우저에서 인증서 뷰어를 열고 ‘유효 시작일’과 ‘만료일’을 기록해 시스템 시간과 비교하세요.
예를 들어 인증서 만료일이 오늘보다 이전이고 오류가 해당 사이트에서만 발생한다면 사이트 운영자가 인증서를 갱신해야 합니다. 시스템 날짜가 인증서 유효 시작일보다 이르면 여러 사이트에서 동시에 접속 문제가 생길 수 있습니다. 만료된 인증서에 맞추려고 시계를 과거로 돌리지 마세요. 로그인 토큰, 소프트웨어 업데이트와 다른 연결에도 영향을 줍니다.
Linux에서는 명령어로 시간 동기화 상태 확인
timedatectl status
date -usystemd를 사용하는 배포판에서는 첫 번째 명령어로 시간, 시간대, 동기화 상태를 확인하고 두 번째 명령어로 UTC 시간을 확인할 수 있습니다. 시간 동기화가 활성화되어 있는데도 오랫동안 동기화되지 않는다면 사용 중인 시간 서비스와 네트워크 연결을 점검하세요. 문제를 수정한 뒤 대상 웹페이지를 다시 열어 프록시 설정도 바꿔야 하는지 확인합니다.
2단계: 직접 연결과 노드를 비교해 문제 범위 파악
‘시스템 프록시 끄기’가 항상 직접 연결을 뜻하지는 않습니다. TUN이 여전히 트래픽을 처리할 수 있고 다른 VPN이 라우팅을 유지할 수도 있습니다. 먼저 현재 모드, 노드, DNS 설정을 저장한 뒤 클라이언트를 종료하고 TUN이 꺼졌으며 시스템 프록시가 원래대로 복구됐는지 확인하세요. 익숙하지 않은 로그인 페이지를 방문해 테스트하지 마세요.
| 테스트 조건 | 관찰 항목 | 판단에 참고할 내용 |
|---|---|---|
| 클라이언트 종료, 다른 VPN도 끔 | 같은 주소에서 같은 오류 코드가 계속 표시되는지 | 오류가 계속되면 사이트, 컴퓨터 또는 현재 네트워크부터 확인 |
| 시스템 프록시 켬, TUN 끔, 노드 A | 적용된 규칙, 실제 출구, 인증서 발급자 | 일반 프록시 전달 상태의 기준 결과 확인 |
| 같은 모드에서 노드 B로 전환 | 오류가 사라지는지, 인증서가 바뀌는지 | 노드에 따라 결과가 달라지면 노드 경로를 중점적으로 확인 |
| 노드 A로 돌아가 TUN만 켬 | TUN을 켰을 때만 오류가 발생하는지 | 라우팅, DNS, 드라이버 간 충돌을 확인 |
노드를 바꾼 뒤 클라이언트의 ‘연결’ 패널에서 새 연결이 실제로 해당 노드를 통과하는지 확인하세요. 정책 그룹이 다른 구성원을 자동 선택할 수도 있고, 규칙에 따라 대상 도메인이 DIRECT로 전송될 수도 있습니다. 비교할 때 이전 연결이 재사용되지 않도록 오류가 난 탭을 닫고 다시 열어 보세요. 필요하면 브라우저도 재시작합니다.
3단계: 인증서 발급자를 확인해 포털 페이지와 중간자 구분
일반 프록시 전달에는 웹사이트 인증서 교체가 필요하지 않습니다
브라우저가 HTTP CONNECT, SOCKS 또는 TUN으로 트래픽을 보내더라도 대상 웹사이트의 TLS 연결은 대개 브라우저와 웹사이트 사이에서 이루어집니다. 프록시를 켰다는 이유만으로 Clash나 mihomo가 모든 웹사이트의 인증서를 다시 발급해야 하는 것은 아닙니다. 서로 다른 여러 사이트에서 갑자기 같은 로컬 보안 제품이나 기업 이름이 발급자로 표시된다면 HTTPS 검사 기능과 기기 관리 정책을 확인하세요.
기업 게이트웨이는 조직 정책에 따라 HTTPS를 복호화해 검사할 수 있으며, 일부 보안 프로그램도 비슷한 기능을 제공합니다. 해당 루트 인증서를 현재 브라우저가 신뢰하지 않으면 인증서 체인 오류가 발생할 수 있습니다. Firefox와 Chromium은 인증서 신뢰 설정, 플랫폼 연동, 기업 정책 적용 방식이 다릅니다. 따라서 ‘다른 브라우저에서는 열린다’는 사실만으로 범위를 좁힐 수 있을 뿐, 연결 경로가 정상이라고 입증되지는 않습니다.
- 도메인 일치 여부: 인증서의 주체 대체 이름(SAN)에 접속한 호스트 이름이 포함되어 있는지 확인하세요. 와일드카드
*.example.com은 루트 도메인example.com이나 여러 단계의 하위 도메인에는 적용되지 않습니다. - 발급자 이상 여부: 라우터, 낯선 조직 또는 로컬 제품 이름으로 바뀌었다면 출처를 먼저 확인하세요. 곧바로 신뢰 대상으로 추가하지 마세요.
- 인증서 변경 여부: CDN은 지역에 따라 서로 다른 인증서를 제공할 수 있으므로 인증서가 다르다는 사실만으로 가로채기를 뜻하지는 않습니다. 도메인 일치 여부, 유효 기간, 신뢰 체인도 함께 확인하세요.
공용 Wi-Fi에서는 먼저 네트워크 인증을 완료하세요
호텔이나 공항 네트워크에서는 포털 인증을 아직 완료하지 않았을 수 있습니다. 운영체제에 표시되는 네트워크 로그인 창을 우선 사용하고 네트워크 이름을 확인하세요. 필요하다면 알고 있는 일반 HTTP 페이지에 접속해 포털 화면을 띄웁니다. HTTPS 인증서 경고 페이지에 계정 정보를 입력하거나, 포털을 통과하려고 낯선 인증서를 설치하지 마세요. 인증을 마친 뒤 다시 테스트하고, 인증서가 여전히 일치하지 않으면 민감한 업무에 해당 네트워크를 사용하지 마세요.
특정 노드에서만 인증서 불일치가 계속되고 다른 노드는 정상이라면 해당 노드를 먼저 비활성화한 뒤 서비스 제공자에게 발생 시각, 도메인, 인증서 정보를 전달하세요. 노드 장애, 출구 DNS 이상, 전달 경로 개입 여부를 확인할 필요는 있지만 오류가 한 번 발생했다는 이유만으로 누가 가로채기를 했다고 단정할 수는 없습니다.
4단계: TUN에서만 오류가 나면 DNS와 라우팅 확인
TUN은 시스템 트래픽을 가상 네트워크 인터페이스로 보내는 방식이며, 그 자체로 웹사이트 인증서를 발급하지 않습니다. TUN을 켠 뒤에만 오류가 발생한다면 이전에는 프록시를 거치지 않던 트래픽이 처리되기 시작했거나 DNS, 라우팅, 보안 프로그램의 처리 경로가 바뀌었을 가능성이 큽니다. 같은 노드와 규칙 모드를 유지한 채 TUN만 끄고 결과를 비교하세요.
fake-ip 주소는 웹사이트가 발급한 인증서가 아닙니다
일반적인 fake-ip 설정에서 코어는 도메인을 198.18.0.0/16 범위의 주소로 매핑한 뒤 해당 매핑에 따라 연결을 처리할 수 있습니다. 실제 범위는 적용 중인 설정을 기준으로 확인하세요. 이런 DNS 결과가 보인다고 인증서가 교체된 것은 아닙니다. 확인할 사항은 연결이 해당 매핑을 담당하는 코어로 들어갔는지, 대상 도메인이 최종적으로 어디로 전달됐는지입니다.
- 연결 기록을 열고 대상 도메인을 검색해 적용된 규칙, 정책 그룹, 출구를 기록하세요.
- 구독 원본 파일만 보지 말고 적용 중인 설정의
dns.enhanced-mode,tun.dns-hijack과 라우팅 관련 항목을 확인하세요. GUI 클라이언트에서 덮어쓰기 설정을 적용했을 수 있습니다. - 브라우저의 ‘보안 DNS’ 설정을 확인하세요. 브라우저 내장 DoH와 시스템 DNS가 서로 다른 경로를 사용할 수 있으므로 설정을 바꿀 때는 기존 값을 기록해 두세요.
- 컴퓨터의 hosts 파일에서 도메인이 이전 주소를 가리키는지 확인하세요. Windows의 일반적인 경로는
C:\Windows\System32\drivers\etc\hosts이고 Linux와 macOS에서는/etc/hosts입니다. - 다른 VPN이나 네트워크 필터링 도구를 하나씩 종료해 결과를 비교하세요. 회사 기기라면 관리자에게 먼저 확인하고, 여러 구성 요소를 한꺼번에 제거하지 마세요.
DNS가 잘못된 서버를 가리키더라도 브라우저가 TCP 연결을 맺고 다른 도메인의 인증서를 받을 수 있으며, 그 결과 도메인 불일치 오류가 발생할 수 있습니다. 반대로 라우팅 충돌은 대개 시간 초과나 연결 재설정으로 나타납니다. 모든 TUN 문제를 인증서 오류라고 부르지 마세요. 오류 코드와 인증서 세부 정보가 일치할 때만 인증서 문제로 계속 점검하세요.
5단계: 포트 혼동을 피하려면 브라우저와 curl 결과 비교
아래 예시는 로컬 HTTP 또는 혼합 프록시 리스너 127.0.0.1:7890을 사용합니다. 먼저 클라이언트의 리스너 설정이나 적용 중인 설정 파일에서 실제 포트를 확인하세요. 7890이 모든 클라이언트의 고정 포트는 아닙니다. 웹사이트가 HTTPS를 사용한다고 해서 로컬 프록시 주소도 https://127.0.0.1:7890로 작성해야 하는 것은 아닙니다.
Windows에서 두 가지 요청 보내기
curl.exe -v --noproxy "*" --connect-timeout 10 --max-time 30 https://example.com/
curl.exe -v --noproxy "" --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 30 https://example.com/첫 번째 명령은 curl에 지정된 프록시 설정을 우회하고, 두 번째 명령은 로컬 HTTP 프록시를 강제로 사용하며 프록시를 사용하지 않을 주소 목록을 비웁니다. 실제 오류를 점검할 때는 예시 도메인을 문제가 발생한 웹사이트의 공개 홈페이지 주소로 바꾸고 로그인 토큰은 포함하지 마세요. macOS나 Linux에서는 curl.exe 대신 curl을 사용하면 됩니다.
- 직접 연결을 테스트하기 전에 TUN을 종료하세요.
--noproxy "*"로는 운영체제 수준의 TUN 라우팅을 우회할 수 없습니다. - CONNECT와 TLS를 구분하세요.
200 Connection established는 프록시 터널이 만들어졌다는 뜻일 뿐, 웹사이트 인증서 검증이 성공했다는 의미는 아닙니다. - 반환된 오류를 확인하세요. curl 오류 60은 보통 상대 서버 인증서 검증 실패를 가리키고, 오류 7이나 28은 연결 실패 또는 시간 초과일 가능성이 큽니다.
- 검증을 건너뛰는 옵션은 사용하지 마세요. 이번 테스트의 목적은 검증이 실패하는 이유를 확인하는 것이지, 요청을 강제로 통과시키는 것이 아닙니다.
curl과 브라우저는 서로 다른 TLS 백엔드와 신뢰 저장소를 사용할 수 있습니다. 결과가 다르더라도 어느 한쪽이 반드시 더 신뢰할 만하다고 단정하지 말고 인증서 발급자, 시스템 프록시, 브라우저 확장 프로그램, 관리 정책을 계속 확인하세요. 자세한 로그에는 접속 주소나 인증 정보가 포함될 수 있으므로 외부에 제출하기 전에 민감한 내용을 가리세요.
설정 복구와 재검사: 한 번에 하나씩 변경
관련 변수를 찾으면 다른 테스트 설정을 먼저 복구한 뒤 필요한 수정만 남기세요. 예를 들어 시계를 맞춘 뒤 문제가 사라졌다면 DNS까지 바꿀 필요는 없습니다. 특정 노드에서만 문제가 생긴다면 해당 노드만 비활성화하세요. 기업 HTTPS 검사에서만 실패한다면 관리자가 인증서 배포와 정책을 확인해야 합니다.
- 원래 오류가 발생했던 주소에 다시 접속해 같은 인증서 오류가 나타나지 않는지 확인하세요.
- 서로 관련 없는 HTTPS 사이트 두 곳도 테스트해 전반적인 신뢰 문제가 있는지 확인하세요.
- 연결 패널에서 대상 트래픽의 실제 출구를 확인해 직접 연결로 돌아간 것을 프록시 문제 해결로 착각하지 않도록 하세요.
- 임시로 끈 보안 기능과 DNS 설정을 복구하고, 각 항목의 결과가 다시 바뀌지 않는지 확인하세요.
- 나중에 같은 문제를 재현할 수 있도록 오류 코드, 노드 이름, 코어 이름, TUN 상태, 해결 단계를 기록하세요.
문제를 제보할 때는 실제 클라이언트 버전, 코어 버전, 운영체제 버전, 민감 정보를 가린 로그를 첨부할 수 있습니다. 구독 주소, 프록시 비밀번호, 비공개 설정 전체를 공개하지 마세요. 클라이언트 이름과 코어 이름은 따로 기록해야 합니다. GUI가 비슷하다고 같은 Clash 또는 mihomo 코어를 사용하는 것은 아닙니다.
이후 설정은 사용 설명서의 DNS 안내와 프록시 모드 안내를 참고하세요. 판단의 핵심은 세 가지입니다. 현재 시간이 정확한가, 인증서는 누구에게 발급됐는가, 이번 연결은 실제로 어떤 경로를 거쳤는가.