Clash 프록시 사용 후 HTTPS 인증서 오류: 원인 진단과 단계별 해결 방법

Clash의 시스템 프록시나 TUN 모드를 활성화한 뒤 브라우저에 갑자기 “연결이 비공개로 설정되어 있지 않음”, “인증 기관을 알 수 없음”, “인증서 이름이 일치하지 않음”과 같은 메시지가 표시되면 문제를 곧바로 클라이언트 탓으로 돌리기 쉽습니다. 실제로 점검할 때는 먼저 두 가지를 구분해야 합니다. 프록시 때문에 트래픽이 다른 경로로 이동했는지, 그리고 HTTPS 연결이 어느 계층에서 종료되는지입니다. 일반적인 Clash와 Clash Meta（mihomo）커널은 보통 연결을 전달하고 규칙에 따라 출구를 선택할 뿐, 로컬에서 일반 웹사이트의 TLS 내용을 복호화하지 않습니다. 설정에 별도의 트래픽 스니핑, 스크립트 또는 중간자 프록시 구성 요소가 없다면 브라우저가 확인하는 인증서는 원칙적으로 대상 사이트가 제공해야 합니다.

따라서 인증서 오류는 시스템 시간 오차, 웹사이트의 인증서 체인 설정 문제, 잘못된 DNS 응답, 프록시 출구에서 반환한 차단 페이지, 조직 네트워크의 HTTPS 검사, 보안 소프트웨어가 삽입한 로컬 인증서, 브라우저의 별도 인증서 저장소 등에서 더 자주 발생합니다. 올바른 순서는 노드를 계속 바꾸는 것이 아니라 오류를 먼저 기록한 뒤 비교 테스트로 장애 범위를 좁히는 것입니다.

1. HTTPS 인증서와 Clash의 역할 이해하기

HTTPS 웹사이트에 접속하면 브라우저는 인증서의 도메인, 유효 기간, 발급 체인 및 용도를 확인합니다. 인증서는 현재 접속한 호스트 이름을 포함해야 하고, 현재 시간이 유효 기간 안에 있어야 하며, 인증서 체인은 시스템이나 브라우저가 신뢰하는 루트 인증서까지 이어져야 합니다. 어느 하나라도 충족되지 않으면 브라우저는 접속을 차단하거나 경고합니다.

Clash의 시스템 프록시는 일반적으로 시스템 프록시를 지원하는 앱의 HTTP 또는 SOCKS 연결을 로컬 수신 포트로 전달합니다. TUN 모드는 가상 네트워크 인터페이스를 통해 더 많은 IP 트래픽을 가로챕니다. 두 방식이 바꾸는 것은 연결 진입점과 라우팅 범위이지, 웹사이트 인증서를 자동으로 교체하는 것이 아닙니다. 프록시 노드나 상위 네트워크가 DNS 결과를 바꾸거나 대상 주소를 차단하거나 인증 페이지와 위험 안내 페이지를 반환할 가능성은 여전히 있습니다. 이때 브라우저가 요청한 도메인은 같지만 다른 서버에서 콘텐츠를 받게 되므로 인증서 이름 불일치나 발급자 이상으로 나타날 수 있습니다.

TLS 인증서와 구독 주소의 관계도 구분해야 합니다. 구독은 클라이언트에 프록시 노드, 정책 그룹, 규칙 등의 설정을 제공할 뿐입니다. 구독 다운로드에서 인증서 오류가 발생한다면 구독 도메인, 시스템 시간, 네트워크 경로를 별도로 확인해야 하며, 이를 근거로 모든 노드가 만료되었다고 판단해서는 안 됩니다. 반대로 구독 업데이트가 성공했다는 것은 해당 주소에 접속할 수 있다는 뜻일 뿐, 모든 대상 웹사이트의 TLS 체인이 정상이라는 의미는 아닙니다.

2. 네 가지 비교 테스트로 장애 범위 좁히기

점검 전에는 계정 로그인, 결제 또는 관리 페이지와 관련된 작업을 잠시 중단하세요. 그런 다음 평소 안정적으로 접속되는 HTTPS 사이트 하나와 오류가 발생한 사이트 하나를 선택해 아래 비교 테스트를 진행합니다. 매번 조건 하나만 바꾸세요. 브라우저, 노드, DNS, TUN을 동시에 전환하면 결과를 해석할 수 없습니다.

1. 프록시 활성화와 비활성화 비교: Clash의 시스템 프록시와 TUN을 끈 뒤 다시 접속합니다. 직접 연결은 정상이고 프록시 경로에서만 오류가 발생한다면 노드 출구, 규칙 적용, DNS 및 중간 장비를 중점적으로 확인하세요. 두 상태 모두 오류가 나면 시스템 시간, 브라우저 인증서 저장소와 대상 사이트를 먼저 점검하세요.
2. 특정 사이트와 전체 사이트 비교: 하나의 도메인만 실패한다면 대개 사이트 인증서, 도메인 해석 또는 특정 규칙 문제에 가깝습니다. 서로 관련 없는 많은 사이트에서 동시에 실패한다면 로컬 시간, 루트 인증서 저장소, 조직 네트워크의 검사 또는 보안 소프트웨어가 공통 원인일 가능성이 큽니다.
3. 특정 브라우저와 모든 앱 비교: 특정 브라우저에서만 실패한다면 해당 브라우저의 보안 정책, 확장 프로그램, DNS over HTTPS 설정과 별도 인증서 저장소를 확인하세요. 브라우저, 명령줄 도구와 다른 앱에서 모두 실패한다면 문제는 시스템이나 네트워크 경로에 있을 가능성이 높습니다.
4. 현재 네트워크와 대체 네트워크 비교: 사용 조건에 부합하는 신뢰할 수 있는 다른 네트워크로 전환해 보세요. 조직 또는 학교 네트워크에서만 오류가 나고 다른 네트워크에서는 정상이라면 인증 포털, 게이트웨이 검사 또는 출구 정책이 원인일 수 있습니다. 모든 네트워크에서 동일하다면 로컬 장치와 설정 계층으로 돌아가 점검하세요.

테스트할 때는 Clash 패널에서 실제로 어떤 규칙이 적용되었는지도 확인해야 합니다. 한 도메인은 프록시를 사용하지만 관련 이미지, API 또는 로그인 도메인은 직접 연결될 수 있습니다. 웹페이지의 주요 문서가 열린다고 해서 페이지의 모든 HTTPS 요청이 같은 출구를 거친다는 뜻은 아닙니다. 개발자 도구에서 특정 하위 도메인의 인증서만 실패한 것으로 보이면 전체 호스트 이름을 기록한 뒤 어떤 규칙과 정책 그룹이 적용되었는지 확인하세요.

3. 시스템·브라우저·네트워크 계층별 점검

1. 시스템 날짜, 시간 및 시간대 보정하기

인증서 검증에는 정확한 시간이 필요합니다. 메인보드 배터리 부족, 가상 머신 일시 중지 후 복원, 듀얼 부팅 전환 또는 수동 시간대 설정으로 시간이 몇 시간에서 몇 년까지 어긋날 수 있습니다. 먼저 시스템의 날짜와 시간 자동 설정을 켠 다음 시간 동기화를 한 번 실행하세요. 시간대도 확인해야 하며 작업 표시줄에 표시된 시각만 확인해서는 안 됩니다. 시간이 정상으로 돌아오면 브라우저를 완전히 종료한 뒤 다시 시작해 새 TLS 연결을 수립하세요.

재부팅할 때마다 시간이 다시 틀어진다면 브라우저에 예외를 계속 추가할 것이 아니라 시스템 시간 소스나 하드웨어 시계를 점검해야 합니다. 인증서 안내의 “아직 유효하지 않음”과 “만료됨”은 모두 로컬 시간 때문에 나타날 수 있으므로 페이지 문구만 보고 인증서가 실제로 무효라고 판단해서는 안 됩니다.

2. 인증서 도메인과 발급 체인 확인하기

브라우저의 인증서 보기 기능을 열고 “발급 대상”, “발급자”, “유효 기간” 및 인증서 경로를 중심으로 기록하세요. 현재 접속한 도메인과 인증서가 적용되는 도메인이 다르면 DNS가 잘못된 서버를 가리키거나, 투명 게이트웨이가 인증 페이지를 반환하거나, 사이트 자체의 배포가 누락된 경우가 흔합니다. 발급자가 조직, 보안 제품 또는 로컬 네트워크 장비 이름으로 표시된다면 HTTPS 검사 구성 요소를 거쳤을 가능성이 있습니다. 이 인증서를 신뢰해도 되는지는 장비 또는 네트워크 관리자가 확인해야 합니다.

인증서 경로에 중간 인증서가 없으면 일부 브라우저는 캐시를 이용해 보완하지만 다른 앱은 바로 실패할 수 있습니다. 이 때문에 “브라우저에서는 열리지만 명령줄 도구에서는 오류가 남” 또는 그 반대 현상이 발생할 수 있습니다. 이 경우 서버 측 인증서 체인을 수정하거나 시스템 인증서 저장소와 앱 실행 환경을 업데이트해야 하며, 인증서 검증을 끄는 것은 장기적인 해결책이 아닙니다.

3. 브라우저 정책과 인증서 저장소 비교하기

브라우저마다 시스템 인증서 저장소를 사용하기도 하고 별도의 신뢰 정책을 유지하기도 합니다. 기업 관리 정책, 자녀 보호 기능, 보안 소프트웨어의 HTTPS 검사와 오래된 실행 환경도 결과에 영향을 줄 수 있습니다. 먼저 게스트 프로필이나 새 테스트 프로필을 사용해 확장 프로그램의 영향을 배제한 뒤 브라우저에 “조직에서 관리됨”이 표시되는지 확인하세요. 장치가 조직 소유라면 관리자가 제공한 공식 안내에 따라 처리하고 조직 인증서를 임의로 삭제하지 마세요.

암호화 DNS가 활성화된 브라우저는 Clash 설정의 DNS 방식을 우회해 다른 앱과 다른 결과를 사용할 수도 있습니다. 점검 중에는 브라우저가 시스템 DNS를 따르도록 임시 설정한 뒤 Clash의 DNS 로그와 비교해 보세요. 여기서 목적은 해석 경로를 확인하는 것이지 특정 DNS 방식이 무조건 더 낫다고 단정하는 것이 아닙니다.

4. 인증 포털과 중간 장비 배제하기

호텔, 공항, 학교 및 방문자 네트워크에서는 먼저 웹 인증을 요구하는 경우가 많습니다. 장치가 아직 인증되지 않았다면 게이트웨이가 요청을 로그인 페이지로 보낼 수 있습니다. HTTPS 요청은 일반 HTTP처럼 원활하게 리디렉션되지 않아 도메인 불일치 오류가 발생할 수 있습니다. 먼저 프록시를 끄고 네트워크가 신뢰할 수 있는지 확인한 뒤 네트워크가 제공하는 인증 페이지를 열어 로그인하고, 완료 후 Clash를 다시 활성화하세요.

라우터의 콘텐츠 필터, 가정용 보안 기능, 회사 게이트웨이와 엔드포인트 보안 소프트웨어도 암호화 연결을 검사할 수 있습니다. 인증서 발급자가 갑자기 로컬 제품 이름으로 바뀌고 해당 관리 네트워크를 해제했을 때 정상으로 돌아온다면 그 제품의 관리 정책을 확인해야 합니다. 출처가 불분명한 루트 인증서를 설치하면 신뢰 범위가 넓어지므로 빠른 해결책으로 사용해서는 안 됩니다.

4. Clash 규칙, DNS, 노드 및 TUN 확인하기

규칙 적용과 정책 출구 확인하기

Clash 클라이언트의 연결 기록에서 오류가 난 도메인을 찾아 직접 연결, 프록시 또는 거부 규칙 중 무엇이 적용되었는지 확인하세요. 규칙은 위에서 아래로 매칭되므로 앞쪽의 도메인, 접미사 또는 규칙 세트가 뒤의 설정을 덮어쓸 수 있습니다. 대상 도메인이 부적절한 출구로 잘못 전달되었다면 먼저 명확한 정책으로 임시 전환해 확인한 뒤 설정에서 규칙 순서를 수정하세요. 규칙 문제를 가리기 위해 글로벌 모드에 장기간 의존하지 마세요.

하나의 서비스가 로그인, 정적 리소스, API와 인증서 상태 조회에 여러 도메인을 사용하는 경우가 많습니다. 페이지의 주 도메인만 조정해서는 충분하지 않을 수 있습니다. 연결 로그를 바탕으로 관련 도메인이 서로 다른 출구로 분리되었는지 확인하세요. 특히 로그인 리디렉션 후에만 오류가 발생하는 경우를 주의해야 합니다. 전체 규칙 개념과 정책 그룹 설명은 사용 안내서에서 계속 확인할 수 있습니다.

DNS 해석 결과 확인하기

프록시를 켠 뒤에만 인증서 이름 불일치가 발생한다면 DNS를 중요하게 확인해야 합니다. Clash Meta（mihomo）는 서로 다른 DNS 상위 서버, 규칙 기반 해석 및 fake-ip 또는 redir-host 모드를 설정할 수 있습니다. 설정 방식 자체가 잘못된 인증서를 만들어 내는 것은 아니지만, 잘못된 상위 서버 응답, 오염된 결과, 오래된 캐시 또는 어긋난 분할 경로가 도메인을 잘못된 주소로 보낼 수 있습니다.

먼저 Clash 로그에서 조회 결과와 연결 대상 주소를 확인하고, 필요하면 운영체제와 브라우저의 DNS 캐시를 삭제한 뒤 다시 테스트하세요. 설정이 fake-ip를 사용한다면 Clash 내부 매핑과 최종 연결 기록을 기준으로 판단해야 하며, 예약 주소 형태의 fake-ip를 웹사이트의 실제 서버 주소로 오해하지 마세요. DNS를 변경한 뒤에는 커널을 재시작하거나 설정을 다시 불러와 기존 연결과 캐시가 결과에 영향을 주지 않도록 해야 합니다.

노드 전환은 진단을 위한 수단으로만 사용하기

같은 설정에서 특정 노드만 인증서 오류를 일으키고 다른 신뢰할 수 있는 노드는 정상이라면 해당 출구 또는 상위 경로에 문제가 있다는 뜻입니다. 노드, 대상 도메인과 발생 시간을 기록한 뒤 해당 경로의 사용을 중단하세요. 모든 노드에서 실패하고 직접 연결은 정상이라면 공통으로 사용하는 DNS, 규칙 제공자, 체인 프록시 또는 로컬 중간 소프트웨어를 계속 확인해야 합니다.

지연 시간이 정상이라고 해서 TLS까지 정상인 것은 아닙니다. 지연 시간 테스트는 보통 특정 주소의 응답 속도만 확인하며 대상 웹사이트의 인증서 체인, SNI, DNS 결과와 전체 페이지 요청은 검사하지 않습니다. 따라서 “노드에 지연 시간 수치가 표시된다”는 사실을 인증서 문제가 해결되었다는 근거로 삼지 마세요.

시스템 프록시와 TUN 모드 각각 테스트하기

시스템 프록시는 정상인데 TUN에서 오류가 난다면 TUN의 DNS 가로채기, 라우팅, 권한과 다른 가상 네트워크 어댑터를 중점적으로 확인하세요. TUN은 정상인데 시스템 프록시에서 오류가 난다면 앱이 시스템 프록시를 올바르게 읽는지, 브라우저가 별도 프록시 설정을 사용하는지, 로컬 수신 포트를 다른 프로그램이 점유하고 있지 않은지 확인해야 합니다. 모드를 전환하기 전에 진행 중인 다운로드와 로그인 작업을 중지하고, 전환 후 연결을 새로 수립하세요.

프록시 클라이언트 여러 개, 브라우저 프록시 확장 프로그램과 중복 TUN 소프트웨어를 동시에 실행하지 마세요. 트래픽이 여러 로컬 포트를 차례로 거치는 프록시 체인이나 루프가 형성될 수 있습니다. 점검할 때는 명확한 진입점 하나만 남기고, 클라이언트에서 HTTP, SOCKS 또는 mixed 포트가 시스템 설정과 일치하는지 확인하세요. 기본 설정은 Clash 사용 튜토리얼을 참고할 수 있습니다.

5. 흔한 브라우저 오류 코드 판단하기

오류 코드 문구는 Chrome, Edge, Firefox, Safari마다 완전히 같지 않지만 판단 기준은 동일합니다. 코드를 확인할 때는 접속 주소와 인증서 정보도 함께 기록하세요. 페이지 주소가 원래 도메인에서 인증 페이지나 다른 도메인으로 리디렉션되었다면 네트워크 인증 과정이 원인일 수 있습니다. 주소는 그대로인데 인증서가 전혀 관련 없는 도메인에 속한다면 접속을 중단하고 DNS와 중간 장비를 확인해야 합니다.

6. 안전한 처리 범위와 최종 점검표

인증서 경고는 브라우저가 연결의 신원을 판단한 결과이므로 HTTPS 검증을 장기간 끄는 방식으로 없애서는 안 됩니다. 명령줄 도구의 검증 건너뛰기 옵션, 브라우저의 강제 계속 버튼과 알 수 없는 루트 인증서 수동 신뢰는 이후 연결의 중요한 보호 기능을 약화할 수 있습니다. 테스트로 원인을 찾을 수는 있지만 비밀번호, 인증 코드 또는 결제 정보를 입력하는 대가로 테스트해서는 안 됩니다.

문제가 대상 웹사이트의 인증서 만료나 체인 설정 오류에서 비롯되었다면 클라이언트 측에서는 사이트가 수정하거나 관리 담당자에게 연락할 때까지 기다리는 방법밖에 없는 경우가 많습니다. 관리되는 장치가 원인이라면 조직 관리자가 루트 인증서와 검사 정책을 확인해야 합니다. 특정 노드에 문제가 집중된다면 해당 경로 사용을 중단하고 서비스 제공자에게 도메인, 시간과 오류 유형을 전달하세요. 로컬 시간, DNS 캐시, 중복 프록시 또는 잘못된 규칙이 원인이라면 수정 후 설정을 다시 불러오고 원래 오류가 발생한 사이트에서 재테스트하세요.

사용을 재개하기 전 다시 확인하기

• 시스템 날짜, 시간과 시간대가 정확하고 자동 동기화 상태가 정상입니다.
• 브라우저 주소 표시줄의 도메인이 인증서 적용 범위와 일치합니다.
• 인증서 발급자가 예상한 대상이며 인증서 체인이 신뢰할 수 있는 루트까지 연결됩니다.
• Clash 연결 로그의 규칙, 정책 그룹과 실제 출구가 설정 의도와 일치합니다.
• DNS 해석 경로가 명확하고 브라우저와 시스템이 서로 다른 상위 서버를 예기치 않게 사용하지 않습니다.
• 시스템 프록시와 TUN이 다른 프록시 도구나 가상 네트워크 어댑터와 중복으로 트래픽을 가로채지 않습니다.
• 네트워크나 노드를 전환한 뒤의 테스트 결과를 기록했으며, 문제가 안정적으로 재현되거나 복구되었음을 확인했습니다.

수정이 끝나면 먼저 일반 공개 페이지로 확인한 뒤 원래 오류가 발생한 도메인을 테스트하세요. 페이지에 로그인이 필요하다면 주소, 인증서 발급자와 연결 상태가 모두 정상인지 확인한 후 정보를 입력해야 합니다. 인증서 문제는 브라우저 경고 페이지에만 나타나는 것처럼 보이지만 실제로는 시간, DNS, 규칙, 출구와 네트워크 관리 등 여러 계층에 걸쳐 있을 수 있습니다. 한 번에 변수 하나만 바꾸는 방식이 클라이언트를 계속 재설치하는 것보다 원인을 더 빠르게 찾는 경우가 많습니다.