Clash, Clash Meta（mihomo）클라이언트를 켠 뒤 브라우저에 갑자기 “연결이 비공개로 설정되어 있지 않습니다”, “인증서를 신뢰할 수 없습니다” 또는 “인증서와 도메인이 일치하지 않습니다”라는 메시지가 표시될 수 있으며, 앱에서 TLS 핸드셰이크 실패를 보고할 수도 있습니다. 이런 현상은 프록시 노드의 문제로 단정하기 쉽지만, HTTPS 검증에는 시스템 시간, 대상 웹사이트 인증서, DNS 해석, 운영체제 신뢰 저장소, 상위 네트워크 장비와 앱 자체의 인증서 정책이 모두 관여합니다. 프록시는 연결 경로의 일부만 바꿀 뿐입니다.
표준 HTTP CONNECT, SOCKS5 또는 TUN 전달은 HTTPS 내용을 자동으로 복호화하지 않습니다. 클라이언트는 일반적으로 암호화된 트래픽을 선택한 출구로 전달할 뿐이며, 웹사이트 인증서는 대상 서버가 제공합니다. mihomo의 도메인 스니핑은 트래픽에 해당하는 호스트 이름을 식별하는 기능이지 웹사이트 인증서를 바꾸는 기능이 아닙니다. 따라서 구독을 반복해서 다시 가져오거나 프록시 모드를 무작정 바꾸기보다, 먼저 오류 유형을 확인한 다음 비교 테스트로 어느 계층에서 문제가 발생하는지 찾아야 합니다.
HTTPS 인증서 오류의 유형부터 확인하기
HTTPS 연결을 설정할 때 클라이언트는 인증서의 유효 기간, 접속 도메인, 발급 체인과 용도를 확인합니다. 오류마다 원인이 다르므로 브라우저 오류 코드, 오류가 발생한 도메인, 인증서 발급자와 유효 기간을 기록하는 것이 단순히 “페이지가 열리지 않는다”는 스크린샷만 남기는 것보다 훨씬 유용합니다.
인증서가 아직 유효하지 않거나 만료됨
먼저 컴퓨터나 휴대폰의 날짜, 시간, 시간대를 확인합니다. 시스템 시간이 몇 달 정도 어긋나면 정상적인 웹사이트도 대량으로 접속에 실패합니다. 한 사이트만 실패한다면 사이트 인증서 만료, 서버 배포 누락 또는 특정 출구가 아직 인증서를 갱신하지 않은 엣지 노드에 연결된 경우일 가능성이 더 큽니다. 자동 시간 동기화를 켠 뒤에도 시간이 맞지 않으면 시계에 표시된 시각뿐 아니라 시스템에서 선택한 시간대도 확인해야 합니다.
인증서 도메인 불일치
인증서의 호스트 이름과 주소 표시줄의 도메인이 다르면, 다른 웹사이트나 네트워크 로그인 페이지 또는 내부 게이트웨이에 발급된 인증서일 수 있습니다. DNS가 잘못된 주소를 반환하거나, 로컬 hosts 규칙이 덮어쓰거나, 투명 게이트웨이가 리디렉션하거나, 대상 사이트의 가상 호스트 설정이 잘못되었거나, 프록시 출구가 비정상 서버에 연결된 경우가 원인일 수 있습니다. 인증서가 라우터 관리 도메인, 공용 Wi-Fi 로그인 도메인 또는 낯선 기업 게이트웨이에 발급되었다면 현재 네트워크에서 인증을 요구하는지 먼저 확인해야 합니다.
인증서 발급자를 신뢰할 수 없거나 인증서 체인이 불완전함
서버는 사이트 인증서부터 중간 인증서까지 완전한 체인을 제공해야 하며, 시스템은 내장된 신뢰 루트로 검증을 완료합니다. 오래된 시스템의 루트 인증서 저장소, 사이트의 중간 인증서 누락, 기업 보안 게이트웨이의 HTTPS 검사 등이 이 오류를 일으킬 수 있습니다. 일부 브라우저는 독립적인 인증서 저장소를 사용하므로 같은 웹사이트도 브라우저마다 결과가 다를 수 있습니다. 이는 신뢰 저장소 문제를 찾는 중요한 단서입니다.
명확한 인증서 페이지 없이 TLS 핸드셰이크 실패
명령줄 도구나 앱은 handshake failed, certificate verify failed, unknown CA 같은 짧은 메시지만 표시하는 경우가 많습니다. 클라이언트가 지원하는 TLS 버전, 서버 이름 표시(SNI), 앱의 인증서 고정, 상위 프록시 프로토콜 오류 또는 연결 중간 종료도 원인일 수 있습니다. 이때는 Clash 로그와 앱 로그를 함께 확인해 노드 연결 단계에서 실패했는지, 대상 주소 연결 단계에서 실패했는지, 대상 인증서를 받은 뒤 검증에서 실패했는지 판단해야 합니다.
비교 테스트로 문제가 기기, 네트워크 또는 프록시 경로 중 어디에 있는지 확인하기
효율적인 문제 해결에서는 한 번에 하나의 조건만 바꿔야 합니다. 노드, DNS, TUN 설정과 브라우저를 동시에 바꾸면 실제로 어떤 변경이 결과에 영향을 주었는지 알 수 없습니다. 먼저 문제가 안정적으로 재현되는 도메인을 하나 선택하고, 현재 설정 이름, 프록시 모드, 정책 그룹과 선택한 노드를 기록하세요.
- 프록시를 끈 뒤 같은 도메인에 접속합니다.클라이언트의 시스템 프록시와 TUN 가로채기를 끄고 트래픽이 실제로 직접 연결로 돌아갔는지 확인합니다. 직접 연결에서도 오류가 발생한다면 시스템 시간, 웹사이트 인증서와 현재 네트워크를 먼저 점검하세요.
- 설정은 그대로 두고 노드만 바꿉니다.특정 노드에서만 실패하고 다른 노드는 정상이라면 해당 출구의 DNS, 상위 네트워크, 투명 검사 장비 또는 대상 웹사이트가 지역별로 반환하는 서버를 의심할 수 있습니다.
- 노드는 그대로 두고 시스템 프록시와 TUN을 비교합니다.TUN 모드에서만 문제가 발생한다면 DNS 하이재킹, Fake-IP 매핑, 라우팅 충돌과 다른 네트워크 필터링 소프트웨어를 확인하세요. 시스템 프록시에서만 문제가 발생한다면 앱이 별도의 프록시 설정을 사용하는지 확인해야 합니다.
- 다른 브라우저나 명령줄 클라이언트로 테스트합니다.특정 브라우저에서만 실패한다면 브라우저 인증서 저장소, 확장 프로그램, 캐시된 HSTS 상태 또는 보안 설정이 원인일 수 있습니다. 모든 앱에서 실패한다면 시스템이나 네트워크 계층의 문제일 가능성이 높습니다.
- 같은 네트워크에서 기기만 바꿉니다.한 기기에서만 실패한다면 해당 기기의 시간, 인증서 저장소와 네트워크 구성 요소를 확인하세요. 같은 네트워크의 여러 기기에서 모두 실패한다면 라우터, 공용 네트워크 인증과 상위 게이트웨이를 점검해야 합니다.
- 같은 기기에서 네트워크만 바꿉니다.가정용 네트워크에서는 실패하지만 모바일 네트워크에서는 정상이라면 클라이언트 설정 자체보다 로컬 DNS, 게이트웨이 또는 통신사 경로에 문제가 있을 가능성이 큽니다.
시스템 시간, 인증서 체인과 중간 프록시 확인 방법
시스템 시간과 인증서 유효 기간 확인
먼저 시스템을 신뢰할 수 있는 시간 서버와 동기화한 다음 브라우저를 완전히 종료하고 다시 시작합니다. 인증서 세부 정보에서 “발급 대상”, “발급자”, “유효 기간 시작 및 종료 시각”과 인증서 경로를 확인하세요. 현재 날짜가 유효 기간 밖에 있더라도 페이지 안내만 보고 웹사이트 인증서가 만료되었다고 판단하지 마세요. 시스템의 연도가 잘못되어도 같은 결과가 나타납니다.
데스크톱 운영체제의 업데이트가 장기간 중단되면 루트 인증서 저장소도 오래될 수 있습니다. 운영체제의 공식 업데이트 기능으로 인증서 신뢰 데이터를 갱신하고, 출처가 불분명한 페이지에서 루트 인증서를 내려받아 수동 설치하지 마세요. 조직 네트워크에서 내부 루트 인증서 설치를 요구한다면 먼저 네트워크 관리자에게 인증서 지문, 적용 기기와 배포 범위를 확인한 뒤 조직 절차에 따라 처리해야 합니다.
HTTPS 검사와 중간 프록시 식별하기
기업 게이트웨이, 자녀 보호 기능, 보안 소프트웨어와 디버깅 프록시는 원래의 TLS 연결을 종료한 뒤 로컬에서 신뢰되는 인증서로 대상 도메인에 임시 인증서를 발급할 수 있습니다. 이 경우 인증서의 도메인은 올바르지만 발급자가 조직 이름이나 로컬 보안 제품 이름으로 바뀔 수 있습니다. 해당 루트 인증서가 설치되지 않았거나 만료되었거나, 시스템 저장소에만 설치되고 브라우저의 독립 인증서 저장소에는 들어가지 않았다면 신뢰할 수 없음 오류가 발생합니다.
일반적인 Clash 규칙 라우팅은 이런 인증서 교체를 수행하지 않습니다. 낯선 발급자가 보이면 시스템에서 동시에 실행 중인 패킷 캡처 도구, 필터 프로그램, 백신의 HTTPS 검사, 기업 프록시와 상위 HTTP 프록시를 확인하세요. 경고를 없애려고 페이지에서 제공하는 루트 인증서를 함부로 가져오지 마세요. 루트 인증서가 신뢰되면 모든 웹사이트의 인증서를 발급하는 데 악용될 수 있습니다.
명령어로 핸드셰이크 결과 확인하기
시스템에 필요한 도구가 설치되어 있다면 응답과 인증서 체인을 확인할 수 있습니다. 아래 명령어의 도메인은 실제 오류가 발생한 사이트로 바꾸고, 실행할 때 인증서 검증을 유지하며 검증 건너뛰기 옵션은 추가하지 마세요.
curl -Iv https://example.com/
openssl s_client -connect example.com:443 -servername example.com -showcertscurl 출력에서는 연결 대상, 프록시 터널 설정 결과와 인증서 검증 원인을 확인할 수 있고, openssl s_client에서는 서버가 반환한 인증서 체인을 확인할 수 있습니다. 시스템 프록시를 사용할 때는 명령줄 도구가 실제로 프록시 환경 변수를 읽는지도 확인해야 합니다. 그렇지 않으면 여전히 직접 연결 경로를 테스트할 수 있습니다. 테스트 결과에서 노드에 따라 인증서 발급자가 달라진다면 서로 다른 출구와 대상 서버 사이의 경로가 다르다는 뜻입니다. 발급자는 항상 같은데 특정 앱에서만 실패한다면 앱의 신뢰 저장소와 인증서 고정 정책을 점검하세요.
Clash 시스템 프록시, TUN과 DNS가 인증서 오류에 미치는 영향
시스템 프록시 모드
시스템 프록시는 일반적으로 프록시 설정을 지원하는 앱이 HTTP 또는 SOCKS 인터페이스를 통해 연결하도록 합니다. HTTPS 웹사이트에 접속할 때 HTTP 프록시는 보통 CONNECT로 대상 호스트에 터널을 만들며, TLS 핸드셰이크는 앱과 웹사이트 사이에서 계속 수행됩니다. 상위 프록시가 CONNECT 요청을 거부하거나 바꾸거나 추가 인증을 요구하면 앱에 프록시 연결 실패가 표시될 수 있고, 게이트웨이가 생성한 인증서 페이지를 받을 수도 있습니다.
일부 앱은 시스템 프록시를 읽지 않고 직접 연결하며, 별도의 프록시 설정을 유지하는 앱도 있습니다. “브라우저는 정상인데 특정 앱만 실패”한다면 해당 앱이 시스템 프록시, TUN 또는 자체 네트워크 스택 중 무엇을 사용하는지 확인해야 합니다. Clash 로그에 해당 연결 기록이 없다면 트래픽이 클라이언트에 아예 들어오지 않은 것일 수 있으며, 규칙 선택이 잘못되었다는 뜻은 아닐 수 있습니다.
TUN 모드
TUN 모드는 네트워크 계층에서 더 많은 트래픽을 가로채므로 시스템 프록시를 지원하지 않는 앱에 적합합니다. 패킷 라우팅과 DNS 처리 방식은 바꾸지만, 가로채는 범위가 넓다고 TLS를 자동으로 복호화하지는 않습니다. TUN을 켠 뒤 인증서 도메인 불일치가 발생한다면 DNS 모드, 다른 가상 네트워크 어댑터, 라우팅 우선순위와 기기에서 동시에 실행 중인 다른 VPN 또는 필터링 서비스를 중점적으로 확인하세요.
여러 네트워크 구성 요소가 동시에 트래픽을 가로채면 패킷이 먼저 한 필터를 거친 뒤 mihomo로 들어갈 수 있고, 반환 경로도 일치하지 않을 수 있습니다. 문제를 해결할 때는 일시적으로 하나의 트래픽 가로채기 구성 요소만 남겨 문제가 사라지는지 확인한 다음 하나씩 다시 활성화하세요. 모바일 기기에서는 일반적으로 하나의 주요 VpnService만 사용할 수 있으므로, 다른 앱이 세션을 가로채면 명확한 인증서 오류보다 연결 끊김으로 나타날 수도 있습니다.
Fake-IP, 도메인 스니핑과 인증서 도메인
Fake-IP 모드는 먼저 앱에 예약 주소를 반환한 뒤, 커널이 매핑을 통해 원래 도메인을 찾아 연결합니다. 이 과정만으로 웹사이트 인증서가 Fake-IP 주소로 바뀌지는 않습니다. 브라우저는 여전히 원래 접속 도메인으로 인증서를 검증하기 때문입니다. 실제로 확인해야 할 부분은 매핑 만료, 클라이언트를 우회하는 DNS 요청, 인증서나 연결 주소를 직접 검증하는 특수 앱, 부적절한 hosts 덮어쓰기입니다.
도메인 스니핑은 TLS ClientHello 같은 정보에서 호스트 이름을 식별해 규칙 매칭을 돕지만, 인증서를 발급하거나 시스템 신뢰를 변경하지는 않습니다. 스니핑을 끈 뒤 오류가 사라진다면 추가 루트 인증서를 설치하기보다 규칙 매칭, 대상 주소 복원과 특수 도메인 제외 설정을 점검해야 합니다. LAN 서비스, 사설 도메인과 자체 서명 인증서를 사용하는 기기는 실제 용도에 따라 직접 연결 및 DNS 예외를 설정할 수 있지만, 인증서는 조직이나 기기에서 정식으로 정한 방식에 따라 배포해야 합니다.
위험도와 비용을 고려한 해결 순서
아래 순서는 위험이 낮고 확인하기 쉬운 작업부터 시작하며, “프록시를 켠 뒤 HTTPS 인증서 오류가 발생하는” 대부분의 상황에 적합합니다. 각 단계를 완료할 때마다 같은 도메인을 다시 테스트하고 결과를 기록하세요.
- 날짜, 시간과 시간대를 바로잡습니다.자동 동기화를 켜고 오류가 발생한 앱을 다시 시작하세요. 여러 웹사이트에서 동시에 만료 또는 유효하지 않음 메시지가 표시된다면 이 단계의 우선순위가 가장 높습니다.
- 오류가 특정 웹사이트에서만 발생하는지 확인합니다.한 사이트에서만 문제가 발생한다면 사이트 인증서의 유효 기간과 도메인을 확인하고 사이트 관리자의 수정을 기다리세요. 특정 사이트에 맞추려고 전체 인증서 검증을 끄지 마세요.
- 공용 네트워크 로그인을 완료합니다.프록시를 끈 뒤 일반 네트워크 확인 페이지를 열어 호텔, 학교 또는 매장 네트워크에서 인증을 기다리고 있지 않은지 확인하세요. 로그인이 끝나면 프록시를 다시 켭니다.
- 정상 작동이 확인된 노드로 전환합니다.특정 출구에서만 실패한다면 해당 노드를 잠시 제외하고 서비스 제공자에게 대상 도메인, 발생 시각과 노드 이름을 전달하세요.
- Clash 규칙 매칭과 로그를 확인합니다.대상 도메인이 예상한 정책 그룹으로 들어갔는지 확인해 규칙이 사용할 수 없는 상위 프록시로 보내지지 않도록 하세요. 로그의 DNS 실패, 연결 거부와 TLS 오류는 각각 구분해 처리해야 합니다.
- 시스템 프록시와 TUN을 비교합니다.어떤 트래픽 가로채기 방식에서만 문제가 발생하는지 확인한 뒤 해당 프록시 설정, 가상 네트워크 어댑터, DNS와 라우팅을 점검하세요. 모든 설정을 동시에 바꾸지는 마세요.
- 충돌하는 네트워크 필터 구성 요소를 중지한 뒤 다시 테스트합니다.한 번에 하나의 VPN, 패킷 캡처 프록시 또는 HTTPS 필터 기능만 중지하고 테스트가 끝나면 필요에 따라 다시 활성화하세요.
- 운영체제와 브라우저를 업데이트합니다.루트 인증서 저장소, TLS 구성 요소와 브라우저 신뢰 데이터를 지원되는 상태로 유지하세요. 오래된 앱은 새로운 인증서 체인을 인식하지 못할 수 있습니다.
- 조직 내부 인증서 배포를 확인합니다.기업이나 학교 네트워크에서 내부 CA를 사용한다면 관리자가 제공하는 공식 설치 방법을 따라야 하며, 오류 페이지에서 인증서를 임시로 내려받아서는 안 됩니다.
- 마지막으로 클라이언트 설정을 점검하거나 다시 구성합니다.로그에 DNS, 규칙 또는 상위 프록시 설정 오류가 표시될 때만 YAML, 구독 또는 설정 파일을 수정하세요. 문제가 있는 동일한 설정을 다시 가져와도 인증서 체인은 바뀌지 않습니다.
자주 하는 오해와 추가 판단 기준
글로벌, 규칙과 직접 연결 모드를 반복해서 전환하기
모드 전환은 트래픽이 어느 정책을 선택할지만 바꿀 뿐, 시스템 시간이나 루트 인증서 저장소를 고치지는 않습니다. 모드 전환의 가치는 비교에 있습니다. 직접 연결은 정상이고 프록시만 실패한다면 출구와 프록시 경로를 확인해야 하며, 세 모드에서 모두 실패한다면 먼저 기기나 네트워크 환경을 점검해야 합니다. 테스트가 끝나면 원래 모드로 복원해 이후 결과가 섞이지 않도록 하세요.
모든 TLS 오류를 DNS 문제로 단정하기
DNS가 도메인을 잘못된 서버로 연결해 도메인 불일치를 일으킬 수는 있지만, “신뢰할 수 없는 발급자”는 대개 인증서 체인이나 HTTPS 검사를 가리킵니다. 먼저 실제 인증서 내용을 확인한 뒤 DNS 캐시 삭제, 리졸버 전환 또는 Fake-IP 점검 여부를 결정하세요. DNS만 바꿔서는 만료된 인증서나 누락된 중간 인증서를 해결할 수 없습니다.
자체 서명 인증서를 보자마자 설치하기
가정용 라우터, 개발 환경과 기업 내부 서비스는 자체 서명 인증서를 사용할 수 있지만, 설치하기 전에 서비스 소유자와 인증서 출처를 반드시 확인해야 합니다. 공용 웹사이트에 갑자기 자체 서명 인증서가 표시되는 것은 정상적인 현상이 아닙니다. 낯선 게이트웨이에서 인증서가 발급되었다면 계정 정보를 입력하지 말고 네트워크 인증, 프록시 설정과 기기의 루트 인증서 변경을 확인하세요.
특정 앱에서만 실패하기
은행, 결제, 스트리밍과 일부 기업용 앱은 인증서 고정을 사용해 미리 등록된 서버 공개 키나 인증서 체인만 허용할 수 있습니다. 시스템이 특정 중간 프록시가 발급한 인증서를 신뢰하더라도 앱은 연결을 거부할 수 있습니다. 이는 대개 트래픽 경로에 TLS 검사가 있거나 대상 연결이 교체되었음을 의미합니다. 해당 앱이 관련 검사 장비를 우회하도록 하거나 조직 네트워크 규정에 따라 설정해야 하며, 앱의 검증 로직을 수정하려고 해서는 안 됩니다.
전체 판단 과정은 네 가지 질문으로 정리할 수 있습니다. 인증서는 누가 발급했는가, 기기를 바꾸면 오류가 달라지는가, 네트워크를 바꾸면 오류가 달라지는가, 노드나 트래픽 가로채기 모드를 바꾸면 오류가 달라지는가입니다. 이 네 가지에 답하면 문제 범위를 시스템 시간과 신뢰 저장소, 대상 웹사이트, 현재 네트워크, 특정 프록시 출구 또는 로컬 트래픽 가로채기 구성 요소로 좁힐 수 있습니다. 해결의 목표는 경고 페이지를 잠시 사라지게 하는 것이 아니라 올바른 인증서 체인과 연결 경로를 복구하는 것입니다.