먼저 인증서 오류가 어느 계층에서 발생했는지 확인
Clash를 실행한 뒤 브라우저에 “연결이 비공개로 설정되지 않음”, “인증 기관을 알 수 없음”, “인증서 이름이 일치하지 않음” 또는 TLS 핸드셰이크 실패가 표시되더라도 Clash 클라이언트가 웹사이트 인증서를 직접 변경했다는 뜻은 아닙니다. 일반적인 HTTP CONNECT 또는 SOCKS5 프록시는 대상 서버까지 전송 경로를 연결하는 역할만 하며, HTTPS 암호화와 인증서 검증은 계속 브라우저와 대상 웹사이트 사이에서 수행됩니다. 정상적인 경우 브라우저에 표시되는 인증서는 대상 웹사이트와 신뢰할 수 있는 인증 기관이 발급한 것이어야 합니다.
Clash, Clash Meta(mihomo) 및 이러한 코어를 기반으로 하는 클라이언트에서 시스템 프록시나 TUN 모드를 활성화하는 것만으로 일반 HTTPS 접속에 사용할 공용 루트 인증서를 설치할 필요는 없습니다. 인증서 발급자가 갑자기 회사 게이트웨이, 보안 검사 프로그램, 라우터 장비 또는 낯선 기관으로 바뀌었다면 구독을 삭제하거나 클라이언트를 반복해서 재설치하기보다 먼저 프록시 상위 경로와 로컬 네트워크의 중간 계층을 점검해야 합니다.
점검을 시작하기 전에 세 가지 조건을 기록하세요. 어떤 웹사이트에서 오류가 발생하는지, Clash를 종료하면 즉시 정상으로 돌아오는지, 같은 네트워크의 다른 기기에서도 오류가 발생하는지 확인합니다. 한 사이트만 실패한다면 사이트 인증서, 도메인 해석 또는 규칙 라우팅 문제일 가능성이 높습니다. 여러 사이트에서 동시에 실패한다면 시스템 시간, 인증서 저장소, 상위 프록시 또는 네트워크 검사 장비가 원인인 경우가 많습니다. 특정 브라우저에서만 실패한다면 해당 브라우저의 인증서 저장소, 확장 프로그램 및 보안 설정을 확인해야 합니다.
일반적인 오류와 우선 점검 항목
- 인증서가 아직 유효하지 않거나 만료됨: 먼저 시스템 날짜, 시간, 시간대와 자동 시간 동기화 상태를 확인하세요.
- 인증 기관을 신뢰할 수 없음: 인증서 체인이 완전한지, 기업용 HTTPS 검사나 로컬 필터링 프로그램이 설치되어 있는지 확인하세요.
- 인증서 이름이 일치하지 않음: DNS 해석, 투명 게이트웨이, 로그인 인증 페이지 및 규칙 라우팅 결과를 확인하세요.
- 핸드셰이크 실패 또는 프로토콜 오류: 프록시 노드의 작동 여부, 상위 프로토콜 매개변수, TLS Server Name, 네트워크 차단 및 클라이언트 로그를 확인하세요.
- 일부 하위 리소스만 실패: 브라우저 개발자 도구에서 실제로 실패한 도메인을 확인해 타사 API 장애를 메인 사이트의 인증서 문제로 잘못 판단하지 않도록 하세요.
시스템 시간·시간대·자동 동기화 확인
TLS 인증서에는 명확한 유효 시작 시각과 만료 시각이 있습니다. 기기 시간이 몇 시간, 며칠 또는 몇 년씩 어긋나면 브라우저는 아직 유효한 인증서를 유효하지 않거나 만료된 것으로 판단합니다. 노트북의 장시간 방전, 메인보드 시계 이상, 가상 머신 일시 중지 후 복원, 멀티부팅 전환 및 수동 시간대 변경 등이 이런 현상을 일으킬 수 있습니다. Clash를 켠 뒤 이전에 접속하지 않았던 사이트에 접근하면서 오류가 한꺼번에 나타나면 Clash가 원인이라고 오해하기 쉽습니다.
- 시스템에 표시되는 날짜, 시간 및 현재 위치의 시간대가 정확한지 확인하세요. 특히 UTC 오프셋이 현재 위치와 맞는지 점검합니다.
- 시스템의 자동 시간 설정과 자동 시간대 설정을 켠 다음 시간 동기화를 직접 한 번 실행하세요.
- 브라우저를 완전히 종료한 뒤 다시 열어 이전 TLS 세션이나 오류 페이지가 탭에 남아 있지 않도록 하세요.
- 자동 동기화에 실패하면 프록시를 잠시 끈 상태에서 다시 동기화하고, 시간 서비스가 규칙에 의해 잘못 라우팅되고 있지 않은지 확인하세요.
Windows 시간 확인
Windows 설정에서 “시간 및 언어”로 이동해 자동 시간 설정과 시간대를 확인하세요. 필요한 권한이 있는 터미널에서 다음 명령으로 동기화 상태를 조회할 수도 있습니다:
w32tm /query /status
w32tm /resync시스템에 시간 서비스가 실행되고 있지 않다는 메시지가 표시되면 먼저 서비스 관리에서 Windows Time 서비스를 확인하세요. 도메인 환경의 기기는 조직의 시간 서버가 통합 관리할 수 있으므로 동기화 소스를 임의로 변경하지 않는 것이 좋습니다.
macOS 및 Linux 시간 확인
macOS에서는 “시스템 설정—일반—날짜 및 시간”에서 자동 설정을 활성화할 수 있습니다. systemd를 사용하는 Linux 배포판에서는 현재 시간 상태를 확인하세요:
timedatectl status
sudo timedatectl set-ntp true컨테이너나 가상 머신의 애플리케이션은 일반적으로 호스트 시스템의 시간을 상속합니다. 가상 머신 내부에서만 오류가 발생한다면 호스트와 게스트 시스템을 모두 확인하고, 스냅샷 복원 후 시간이 다시 동기화되었는지 점검하세요.
브라우저에 표시되는 인증서 체인 확인
인증서 체인은 일반적으로 웹사이트 인증서, 중간 인증서 및 신뢰할 수 있는 루트 인증서로 구성됩니다. 브라우저는 접속 도메인이 인증서의 주체 대체 이름에 포함되어 있는지, 인증서가 유효 기간 내에 있는지, 서명 체인이 로컬에서 신뢰하는 루트 인증서로 연결되는지, 인증서 용도가 서버 인증에 적합한지를 확인합니다. 점검할 때는 오류 페이지의 제목만 보지 말고 인증서 뷰어를 열어 구체적인 필드를 기록해야 합니다.
먼저 웹사이트 인증서의 “발급 대상” 또는 주체 대체 이름을 확인해 현재 접속한 도메인이 포함되어 있는지 확인하세요. 다음으로 “발급자”를 확인하고 Clash를 종료했을 때 표시되는 결과와 비교합니다. 두 상태에서 인증서 주체, 일련 정보 또는 발급자가 뚜렷하게 다르다면 트래픽 경로에 TLS를 종료한 뒤 다시 설정할 수 있는 중간 계층이 존재한다는 뜻입니다. 기업 네트워크의 규정 준수 검사, 자녀 보호 기능, 보안 프로그램의 HTTPS 검사, 디버깅 프록시 또는 구독에 설정된 상위 프록시 서비스가 원인일 수 있습니다.
인증서가 항상 동일한데 특정 브라우저에서만 신뢰할 수 없다는 메시지가 표시된다면 브라우저별 결과를 비교하세요. 일부 브라우저는 주로 시스템 인증서 저장소를 사용하지만, 다른 환경은 독립적인 인증서 데이터베이스를 관리할 수 있습니다. 불완전한 시스템 업데이트, 오래된 루트 인증서 목록 또는 손상된 브라우저 설정 때문에 같은 인증서가 프로그램마다 다르게 판단될 수 있습니다.
명령줄에서 핸드셰이크 결과 확인
명령줄 도구를 사용하면 브라우저 설정 문제와 시스템 네트워크 문제를 구분하는 데 도움이 됩니다. 아래 요청은 기본 연결과 로컬 HTTP 프록시 포트를 통한 연결을 각각 테스트합니다. 포트는 클라이언트의 실제 설정에 맞게 변경하세요:
curl -Iv https://example.com/
curl -Iv --proxy http://127.0.0.1:7890 https://example.com/출력 결과에서 인증서 주체, 발급자, 유효 기간 및 최종 오류를 비교하세요. 직접 연결은 성공하지만 명시적 프록시 연결이 실패한다면 Clash에서 선택한 노드, 프록시 그룹 및 상위 경로를 계속 확인해야 합니다. 두 방식 모두 실패한다면 시스템 시간, 인증서 저장소, DNS 또는 현재 네트워크 문제일 가능성이 높습니다. 실제 장애 도메인을 테스트할 때는 계정, 토큰 또는 쿼리 매개변수가 포함된 전체 URL을 공개 로그에 남기지 않도록 주의하세요.
Clash 프록시 경로 및 규칙 라우팅 점검
Clash의 규칙 모드는 설정 파일의 규칙 순서에 따라 요청을 프록시 그룹, 특정 노드 또는 DIRECT로 라우팅합니다. 브라우저가 한 페이지를 열 때 메인 도메인, 정적 리소스, 로그인 API 및 콘텐츠 전송 도메인이 서로 다른 규칙에 매칭될 수 있습니다. 메인 페이지는 프록시를 사용하지만 인증 API가 제한되었거나 리디렉션된 주소로 직접 연결되면 브라우저에 인증서 오류, 로그인 반복 또는 일부 리소스의 핸드셰이크 실패가 나타날 수 있습니다.
클라이언트 연결 기록과 코어 로그를 열고 오류가 발생한 시각 전후의 대상 도메인을 찾아 매칭된 규칙, 출구 정책 및 노드를 확인하세요. Clash Meta(mihomo) 설정은 일반적으로 패널에서 실시간 연결을 확인할 수 있습니다. 그래픽 클라이언트마다 메뉴 이름은 “연결”, “로그”, “규칙” 또는 “프록시”로 다를 수 있습니다. 핵심은 글로벌 모드를 반복해서 전환하는 것이 아니라 해당 도메인이 실제로 어떤 경로를 사용하는지 확인하는 것입니다.
변수를 최소화해 전환하기
- 기존 네트워크는 그대로 유지한 채 오류 도메인을 임시로 DIRECT에 연결하고 브라우저를 다시 열어 테스트하세요.
- 직접 연결이 정상이라면 해당 도메인을 작동이 확인된 다른 노드를 거치도록 변경해 인증서가 복구되는지 확인하세요.
- 모든 노드에서 실패한다면 구독에 통합 체인 프록시, 외부 제어 프로그램 또는 추가 상위 프록시가 설정되어 있는지 확인하세요.
- 특정 노드 하나에서만 실패한다면 노드의 서버 주소, 포트, 전송 매개변수, TLS Server Name 및 시스템 시간을 확인하세요.
- 테스트가 끝나면 규칙 모드로 되돌려 글로벌 정책이 원래의 규칙 순서 문제를 가리지 않도록 하세요.
노드 프로토콜 자체가 TLS를 사용해 프록시 서버에 연결할 수 있지만, 이 계층의 인증서는 브라우저가 웹사이트에 접속할 때 보는 인증서와 다른 객체입니다. 노드 로그의 “certificate verify failed”, “x509” 또는 “hostname mismatch”는 대개 클라이언트가 프록시 서버 인증서를 검증하지 못했다는 뜻입니다. 반면 브라우저 페이지의 인증서 경고는 대상 웹사이트 연결을 가리킵니다. 이 두 계층을 구분하면 노드 서버 인증서 문제를 웹사이트 인증서 문제로 오해하지 않을 수 있습니다.
노드 설정에서 서버 주소로 도메인을 사용한다면 TLS Server Name은 일반적으로 서버 인증서가 포함하는 이름과 일치해야 합니다. 이를 IP 주소로 임의 변경하거나 다른 도메인을 입력하거나 상위 서버의 인증서가 교체된 경우 노드 핸드셰이크가 실패할 수 있습니다. 이러한 매개변수는 서비스 제공업체가 제공한 유효한 설정을 기준으로 해야 하며, 노드 인증서 검증을 끄는 방식으로 연결을 유지해서는 안 됩니다.
시스템 프록시와 TUN 모드의 차이
시스템 프록시는 운영체제의 프록시 설정을 따르는 프로그램에 주로 영향을 줍니다. TUN 모드는 가상 네트워크 어댑터를 통해 더 광범위한 IP 트래픽을 가로채고 라우팅 및 DNS와 함께 시스템 프록시를 읽지 않는 애플리케이션을 처리합니다. TUN으로 전환한 뒤 여러 프로그램에서 동시에 오류가 발생한다면 DNS 변조 설정 충돌, 다른 VPN의 동시 라우팅 변경, 보안 프로그램의 가상 어댑터 필터링 또는 LAN 인증 트래픽 가로채기가 흔한 원인입니다.
TUN 모드는 가로채는 범위가 넓어질 뿐 HTTPS를 자동으로 복호화하지 않습니다. TUN을 켰을 때만 인증서 이름 불일치가 발생한다면 TUN을 잠시 끄고 시스템 프록시는 유지한 채 비교 테스트를 진행하세요. 그런 다음 fake-ip, DNS 리스너, 라우팅 제외 항목 및 다른 VPN을 확인합니다. 한 번에 하나의 옵션만 변경해야 라우팅, 해석 또는 상위 노드 중 무엇이 차이를 만들었는지 판단할 수 있습니다.
DNS 이상·인증 페이지·네트워크 변조 확인
인증서 이름 불일치는 브라우저가 잘못된 서버에 연결되었다는 뜻인 경우가 많습니다. 공공 Wi-Fi, 호텔 및 학교 네트워크에서는 먼저 웹 인증을 완료해야 할 수 있습니다. 기기가 처음 연결되면 게이트웨이가 일반 요청을 로그인 페이지로 리디렉션합니다. HTTPS 요청까지 가로채면 인증 페이지가 대상 도메인에 유효한 인증서를 제공할 수 없어 브라우저에 인증서 경고가 표시됩니다. 이때는 프록시를 끄고 운영체제가 제공하는 네트워크 확인 페이지나 일반 HTTP 페이지에 접속해 인증을 완료한 뒤 Clash를 다시 활성화하세요.
DNS가 잘못된 주소를 반환해도 같은 현상이 발생할 수 있습니다. Clash를 끄고 켤 때 해석 방식이 시스템 DNS, 클라이언트 DNS 모듈, 원격 리졸버 또는 fake-ip 메커니즘으로 달라질 수 있습니다. 특정 도메인이 한 상태에서만 오류를 보인다면 각 상태에서 해석 결과를 조회하고 신뢰할 수 있는 네트워크의 결과와 비교하세요. 대형 웹사이트는 지역별 주소를 사용할 수 있으므로 IP가 완전히 같지 않다고 반드시 이상인 것은 아닙니다. 핵심은 주소의 소속, 인증서 도메인 및 접속 결과가 합리적인지 여부입니다.
nslookup example.com
dig example.com A
dig example.com AAAA가정용 라우터의 보안 필터, 통신사 네트워크의 비정상 리디렉션, 회사 출구의 TLS 검사 및 로컬 디버깅 프록시가 연결 경로를 바꿀 수 있습니다. 가장 효과적인 교차 테스트는 같은 기기를 다른 신뢰할 수 있는 네트워크에 임시 연결하고 Clash 설정은 그대로 유지하는 것입니다. 네트워크를 바꾼 뒤 즉시 정상으로 돌아온다면 기존 라우터의 DNS, 접근 제어, 펌웨어 설정 및 인터넷 인증 상태를 확인하세요. 모든 네트워크에서 실패한다면 로컬 인증서 저장소, 클라이언트 설정 및 보안 프로그램으로 돌아가 계속 점검합니다.
로컬 필터링 프로그램 및 기업 인증서
일부 기업 환경에서는 관리되는 루트 인증서를 사용해 HTTPS 트래픽을 검사합니다. 조직에서 관리하는 기기에서는 이 인증서가 일반적으로 관리자가 일괄 배포하며, 브라우저에는 조직이 지정한 발급자가 표시됩니다. 인증서가 만료되었거나 배포 범위가 누락되었거나 브라우저가 독립적인 인증서 저장소를 사용하면 신뢰 오류가 발생할 수 있습니다. 이때는 인증서 지문 외에도 주체, 발급자 및 유효 기간 정보를 기록해 네트워크 관리자에게 확인을 요청하고 조직 인증서를 직접 삭제하지 마세요.
개인 기기에 패킷 캡처 디버깅 도구, 트래픽 분석 도구 또는 HTTPS 검사 기능이 있는 보안 프로그램을 설치한 적이 있다면 해당 프로그램이 아직 실행 중인지 확인하세요. 화면에서 종료했다고 해서 백그라운드 서비스와 로컬 프록시까지 중지된 것은 아닐 수 있습니다. 시스템 프록시 설정, 프로세스 목록 및 인증서 관리자를 점검하세요. 소프트웨어의 출처와 용도를 확인한 뒤 공식 제거 절차를 통해 관련 네트워크 구성 요소를 삭제합니다.
단계별 복구 및 결과 확인
인증서 문제는 영향이 적고 되돌리기 쉬운 작업부터 점검해야 합니다. 네트워크 설정 전체를 바로 초기화하거나 모든 인증서를 삭제하면 기존 환경이 손상되고 중요한 단서도 사라질 수 있습니다. 다음 순서는 대부분의 Clash 실행 후 HTTPS 오류 상황에 적합합니다.
- 오류 기록: 브라우저 오류 코드, 장애 도메인, 인증서 주체, 발급자, 유효 기간 및 발생 시각을 저장하세요.
- 시간 보정: 날짜, 시간대 및 자동 동기화 상태를 확인한 다음 브라우저를 다시 시작하세요.
- 상태별 비교: Clash 종료, 시스템 프록시만 사용, TUN만 사용 또는 기존 모드를 각각 테스트하고 결과를 기록하세요.
- 연결 로그 확인: 대상 도메인에 매칭된 규칙, 프록시 그룹, 노드 및 DNS 해석 경로를 확인하세요.
- 단일 출구 교체: 다른 설정은 바꾸지 않고 노드만 전환해 문제가 노드를 따라 이동하는지 확인하세요.
- 신뢰할 수 있는 네트워크로 변경: 라우터, 공공 네트워크 인증 및 출구 검사 장비의 영향을 배제하세요.
- 중간 프로그램 점검: 다른 VPN, 로컬 디버깅 프록시, 보안 필터 및 기업 관리 정책을 확인하세요.
- 설정 복원: 최근 DNS, TUN 또는 규칙을 변경했다면 변경 전 보관한 설정을 기준으로 항목별로 되돌리세요.
웹사이트 또는 서비스 제공업체에 문의해야 하는 경우
같은 웹사이트가 여러 기기와 네트워크에서, 직접 연결과 프록시 환경 모두에서 동일한 만료 인증서 또는 불완전한 인증서 체인을 표시한다면 문제는 웹사이트 서버에 있을 수 있습니다. 사이트 점검이 끝날 때까지 기다리거나 사이트 관리자에게 문의하세요. 오류가 특정 프록시 노드에서만 발생하고 노드 로그에 서버 인증서 이름 또는 유효 기간 이상이 명확히 표시된다면 노드 설정 제공업체에 발생 시각, 노드 이름 및 로그 요약을 전달하세요.
문의할 때 전체 구독 주소, 인증 키 또는 계정 정보를 제출할 필요는 없습니다. 클라이언트 코어 버전, 운영체제, 연결 모드, 오류 발생 시각, 대상 도메인, 매칭된 규칙 결과 및 민감 정보가 제거된 로그를 제공하면 됩니다. “노드 TLS 핸드셰이크 실패”와 “브라우저에서 웹사이트 접속 시 인증서 경고”를 명확히 구분하면 원인 파악 시간을 크게 줄일 수 있습니다.
복구 후에도 확인해야 할 설정
문제가 사라졌다고 해서 즉시 우연한 오류로 단정하지 마세요. 기존 규칙 모드를 다시 활성화하고 자주 사용하는 웹사이트, 소프트웨어 업데이트, 로그인 API 및 시스템 프록시를 따르지 않는 애플리케이션을 각각 테스트하세요. TUN이나 DNS 모듈을 임시로 끈 적이 있다면 항목별로 다시 활성화하면서 로그를 관찰합니다. 사용자 지정 규칙 때문에 인증 도메인과 메인 사이트가 서로 다른 출구를 사용한다면 관련 도메인을 같은 정책 그룹에 넣고 규칙 순서에 대한 설명을 남겨 구독 업데이트 후 다시 확인할 수 있도록 하세요.
회사 네트워크, 가정용 네트워크 및 공공 Wi-Fi를 자주 오가는 기기라면 비교용 기본 설정을 하나 보관해 두는 것이 좋습니다. 안정적인 구독, 명확한 DNS 설정 및 적은 수의 사용자 지정 규칙을 사용하세요. 문제가 발생하면 먼저 기본 설정으로 재현한 뒤 TUN, 스크립트 또는 사용자 지정 규칙을 단계적으로 추가합니다. 이런 최소화 테스트가 클라이언트를 반복 설치하는 것보다 실제 장애 계층을 찾는 데 효과적입니다.