Clash, Clash Meta（mihomo） 또는 다른 프록시 클라이언트를 켠 뒤 브라우저에 “연결이 비공개로 설정되지 않음”, “인증서가 유효하지 않음”, “인증서가 만료됨” 또는 NET::ERR_CERT_AUTHORITY_INVALID가 표시될 수 있습니다. 모두 HTTPS와 관련된 경고처럼 보이지만 실제 원인은 서로 다를 수 있습니다. 컴퓨터 날짜가 어긋나 인증서가 아직 유효하지 않은 것으로 판단될 수도 있고, 대상 사이트의 인증서 체인이 불완전할 수도 있습니다. 현재 네트워크가 TLS 연결을 검사하거나, 프록시 규칙이 요청을 적절하지 않은 출구로 보냈을 가능성도 있습니다.
점검할 때 인증서 경고가 보인다고 바로 ‘계속 방문’을 누르지 마세요. HTTPS 인증서는 접속 도메인, 암호화 연결의 신원, 인증서 발급 관계를 확인하는 데 사용됩니다. 경고를 무시하면 실제 네트워크 가로채기, 잘못된 출구 또는 도메인 하이재킹을 놓칠 수 있습니다. 먼저 오류 원문과 문제가 발생한 도메인을 기록한 뒤, 프록시를 끈 상태와 켠 상태의 결과를 단계별로 비교하고, 마지막에 클라이언트의 인증서 관련 옵션을 확인하는 방법이 가장 효율적입니다.
먼저 확인하기: 인증서 오류가 의미하는 것
브라우저가 HTTPS 사이트에 접속할 때는 인증서가 현재 도메인을 포함하는지, 유효 기간 내인지, 신뢰할 수 있는 인증서 체인을 따라 루트 인증서까지 연결되는지, 연결 과정의 호스트 이름이 인증서와 일치하는지를 확인합니다. 프록시 클라이언트는 일반적으로 연결 전달과 정책 선택을 담당할 뿐, HTTPS 복호화 도구와 같은 의미는 아닙니다. 일반 HTTP 프록시나 SOCKS 프록시는 연결을 전달할 수 있으며, 브라우저가 프록시를 통해 대상 사이트와 TLS 연결을 맺을 때도 브라우저에 표시되는 인증서는 대상 사이트가 제공한 것입니다.
따라서 “Clash를 켠 뒤 인증서 오류가 발생했다”는 사실이 곧 “Clash가 인증서를 변경했다”는 뜻은 아닙니다. 먼저 두 가지 연결 방식을 구분해야 합니다. 첫 번째는 프록시가 TCP를 전달하거나 터널을 통해 HTTPS를 전송하는 방식으로, 인증서는 일반적으로 대상 사이트가 직접 반환합니다. 두 번째는 네트워크 장비, 기업 보안 소프트웨어 또는 일부 디버깅 도구가 HTTPS 내용을 직접 검사하는 방식입니다. 이 경우 로컬 장치에 신뢰할 수 있는 루트 인증서를 설치하고 접속 도메인용 대체 인증서를 발급할 수 있습니다. 해당 루트 인증서를 현재 브라우저가 신뢰하지 않으면 인증서 발급자를 신뢰할 수 없다는 경고가 표시됩니다.
Clash Meta의 TUN 모드도 모든 HTTPS 인증서를 자동으로 변경하지는 않습니다. TUN은 주로 가상 네트워크 어댑터를 통해 시스템 트래픽을 넘겨받은 뒤, 설정의 라우팅, DNS 및 프록시 규칙에 따라 연결을 처리합니다. 바뀌는 것은 트래픽이 프록시 코어로 들어가는 경로이며, 실제로 확인해야 할 항목은 최종 출구, DNS 해석, 규칙 매칭 결과와 추가 TLS 검사 구성 요소의 존재 여부입니다.
1단계: 시스템 시간과 시간대 확인
인증서 유효 기간은 장치의 현재 시간에 따라 판단됩니다. 시스템 날짜가 몇 시간 또는 며칠 빠르거나 늦으면 브라우저가 정상적인 인증서를 “아직 유효하지 않음” 또는 “이미 만료됨”으로 판단할 수 있습니다. 시간대 설정이 잘못된 경우에도 같은 현상이 나타나며, 특히 듀얼 부팅, 가상 머신, 절전 모드 복귀 또는 메인보드 시계 이상 이후에 자주 발생합니다. 이 문제는 프록시 규칙과 관련이 없지만 네트워크 환경을 전환한 직후 발견되는 경우가 많아 Clash의 문제로 오해하기 쉽습니다.
- 시스템의 날짜 및 시간 설정을 열고 자동 시간 설정을 활성화한 다음, 시간대가 현재 위치와 일치하는지 확인하세요.
- 시간을 한 번 수동으로 동기화하고 시스템에 동기화 완료가 표시될 때까지 기다린 뒤, 브라우저를 완전히 종료했다가 다시 여세요.
- 서로 다른 인증서 서비스 제공업체를 사용하는 웹사이트 두 곳에 접속해 비교하세요. 여러 사이트에서 동시에 인증서가 아직 유효하지 않거나 만료되었다고 표시되면 시스템 시간을 먼저 확인해야 합니다.
한 사이트에서만 오류가 발생하고 다른 HTTPS 사이트는 정상이라면 시간 문제일 가능성은 낮아집니다. 이때는 프록시 모드를 반복해서 전환하기보다 인증서 상세 정보를 확인하세요. 모바일 핫스팟, 가정용 인터넷, 회사 네트워크를 비교 환경으로 사용할 수 있지만, 비교 전에는 가능한 한 장치 시간과 브라우저 설정을 동일하게 유지해야 합니다.
2단계: 인증서 도메인, 유효 기간과 발급자 확인
브라우저 주소 표시줄의 보안 정보에서 인증서 상세 정보를 열고 세 가지 항목을 중점적으로 확인하세요. 첫째는 주체 또는 사용자 이름으로, 인증서가 현재 접속한 도메인을 포함하는지 확인합니다. 와일드카드 인증서는 규칙에 맞는 하위 도메인만 포함하며 완전히 다른 주 도메인까지 보호하지 않습니다. 둘째는 유효 기간으로, 현재 시간이 시작일과 만료일 사이에 있는지 확인합니다. 셋째는 발급자와 인증서 체인으로, 중간 인증서가 완전한지와 루트 인증서를 운영체제 또는 브라우저가 신뢰하는지를 확인합니다.
인증서에 표시된 도메인과 주소 표시줄의 도메인이 완전히 다르면 DNS가 잘못된 서버로 해석되었거나, 프록시 출구가 비정상 페이지를 반환했거나, 네트워크 경로에 가로채기가 있을 수 있습니다. 도메인은 일치하지만 발급자가 회사 게이트웨이, 백신 소프트웨어 또는 로컬 디버깅 도구 이름으로 바뀌었다면 해당 구성 요소의 HTTPS 검사 기능이 켜져 있는지, 루트 인증서가 올바르게 배포되었는지 확인해야 합니다. 경고를 없애려고 출처가 불분명한 루트 인증서를 함부로 설치하지 마세요. 루트 인증서는 높은 수준의 신뢰 권한을 가지므로 출처와 용도가 명확해야 합니다.
| 현상 | 우선 의심할 원인 | 비교 방법 |
|---|---|---|
| 여러 사이트에서 동시에 만료로 표시됨 | 시스템 시간, 시간대 또는 로컬 인증서 저장소 | 시간을 동기화한 뒤 다른 브라우저로 테스트 |
| 하나의 도메인에서만 불일치 발생 | DNS, 잘못된 출구 또는 사이트 측 설정 | 프록시를 끈 상태, 모바일 네트워크와 서로 다른 DNS 결과 비교 |
| 발급자가 기업 게이트웨이로 표시됨 | HTTPS 검사 또는 보안 소프트웨어의 가로채기 | 네트워크 정책과 보안 소프트웨어의 TLS 검사 설정 확인 |
| 프록시를 켠 뒤에만 발생 | 규칙 매칭, 출구 노드 또는 DNS 경로 | 노드를 임시로 변경하고 연결 로그 확인 |
3단계: 프록시와 직접 연결을 최소 변수로 비교
프록시 문제를 점검할 때는 변수가 적을수록 결론을 내리기 쉽습니다. 먼저 시스템 프록시를 끄거나 클라이언트를 일시 중지하고, 같은 브라우저로 같은 URL에 접속해 오류가 계속되는지 기록하세요. 그런 다음 같은 노드, 같은 DNS 설정, 같은 브라우저 창을 유지한 채 프록시를 다시 활성화합니다. 오류가 프록시를 켰을 때만 발생한다면 이미 정상 작동이 확인된 다른 노드로 전환하세요. 매번 하나의 조건만 바꾸고, 규칙 모드, TUN, DNS와 브라우저 확장 기능을 동시에 수정하지 마세요.
클라이언트의 연결 또는 로그 화면에서 대상 도메인이 예상한 규칙과 매칭되었는지, 실제로 어떤 정책 그룹과 노드를 사용했는지 확인하세요. 규칙 모드에서는 도메인이 특정 규칙에 먼저 매칭된 뒤 프록시, 직접 연결 또는 거부 정책으로 전달될 수 있습니다. 전역 모드는 더 많은 요청을 선택한 프록시 그룹으로 보내므로 짧은 시간 동안 비교할 때 유용합니다. 직접 연결 모드는 사이트 자체가 정상인지 확인하는 데 도움이 되지만, 네트워크 정책을 장기적으로 우회하는 방법으로 사용해서는 안 됩니다.
DNS가 어디에서 해석되는지도 확인해야 합니다. 브라우저, 시스템, Clash 코어와 원격 프록시가 서로 다른 해석 경로를 사용할 수 있습니다. 해석 결과가 다르면 서로 다른 CDN 노드나 잘못된 주소로 연결될 수 있습니다. 특정 도메인에서만 문제가 발생한다면 먼저 브라우저 DNS 캐시를 지운 뒤, 설정의 DNS 모드, nameserver, fallback 및 fake-ip 관련 항목이 현재 네트워크 환경에 맞는지 확인하세요. 설정을 변경한 후에는 실제로 해당 파일이 활성화되었는지, 로드되지 않은 사본을 편집한 것은 아닌지 확인해야 합니다.
4단계: TLS, 인증서 저장소와 HTTPS 검사 확인
인증서 발급자가 로컬 소프트웨어나 조직 게이트웨이로 표시되면 시스템 보안 소프트웨어, 기업 프록시, 자녀 보호 프로그램과 디버깅 프록시의 HTTPS 검사 기능을 확인하세요. 일부 소프트웨어는 브라우저와 대상 사이트 사이에 두 개의 TLS 연결을 만들고 자체 루트 인증서로 로컬 대체 인증서를 발급합니다. 관리되는 장치에서 명확한 네트워크 정책으로 사용 중이라면 관리자에게 루트 인증서 배포와 인증서 교체 상태를 확인하세요. 개인 장치의 소프트웨어 기능이라면 영향을 이해한 후 HTTPS 검사를 끄고 다시 테스트할 수 있습니다.
브라우저가 시스템 인증서 저장소를 항상 그대로 사용하는 것은 아닙니다. 일부 브라우저는 자체 인증서 관리, 암호화 DNS 또는 보안 정책을 활성화하므로 시스템에서는 신뢰하는 인증서가 브라우저에서 거부될 수 있습니다. 테스트할 때는 별도의 깨끗한 브라우저 프로필로 비교할 수 있지만, “다른 브라우저에서는 열린다”고 해서 문제가 해결된 것으로 보아서는 안 됩니다. 두 브라우저의 인증서 저장소, 확장 기능 또는 네트워크 설정이 다르다는 뜻일 뿐입니다.
오류 메시지가 신뢰할 수 없는 인증서 발급자가 아니라 TLS 버전, 핸드셰이크 실패 또는 연결 재설정을 언급한다면 출구 노드, 대상 사이트 호환성 및 중간 네트워크 장비를 중점적으로 점검해야 합니다. 이 경우 루트 인증서를 반복해서 가져와도 도움이 되지 않습니다. 클라이언트 인증서가 필요한 사이트, 기업 내부망 또는 상호 TLS를 사용하는 서비스라면 프록시 경로가 해당 사이트의 인증 방식을 지원하는지도 확인해야 합니다.
TUN 모드에서 추가로 확인할 항목
TUN 모드는 시스템 트래픽을 가상 네트워크 인터페이스로 전달하므로, 브라우저에 기존 HTTP 프록시가 설정되어 있지 않아도 코어 규칙의 영향을 받을 수 있습니다. 인증서 오류가 발생하면 TUN만 잠시 끄고 시스템 프록시는 유지한 채 비교하거나, TUN을 켠 상태에서 직접 연결 정책으로 한 번 테스트할 수 있습니다. 이 과정의 목적은 트래픽 경로를 특정하는 것이며, 특정 모드를 고정적으로 사용하라는 뜻은 아닙니다.
- TUN 가상 네트워크 어댑터가 정상적으로 생성되었는지, 다른 VPN, 가상 머신 네트워크 어댑터 또는 네트워크 가속 소프트웨어와 충돌하지 않는지 확인하세요.
- 현재 코어가 DNS를 처리하고 있는지, fake-ip 매핑이 브라우저, 시스템 보안 소프트웨어 또는 로컬 네트워크 장비에서 비정상적으로 처리되지 않는지 확인하세요.
- 대상 도메인의 규칙 매칭 기록을 확인하고, 규칙 세트가 만료되어 요청이 잘못된 정책 그룹으로 전달되지 않았는지 확인하세요.
- TUN을 끈 뒤 정상으로 돌아온다면 전체 설정을 바로 초기화하지 말고 DNS, 라우팅과 네트워크 어댑터 우선순위를 계속 비교하세요.
권장 해결 순서와 보안 기준
전체 과정을 안정적인 점검 순서로 줄이면 다음과 같습니다. 먼저 오류를 기록하고 시간을 보정합니다. 이어서 인증서 도메인, 유효 기간과 발급자를 확인한 뒤 같은 사이트에서 직접 연결과 프록시를 비교합니다. 다음으로 노드, 규칙, DNS와 TUN 경로를 점검하고, 마지막으로 브라우저, 시스템 또는 보안 소프트웨어의 인증서 저장소를 확인합니다. 각 단계를 완료할 때마다 페이지를 다시 열고 결과를 기록하면 어떤 변경이 연결에 실제로 영향을 주었는지 알 수 있습니다.
해결 과정에서 “인증서 오류 무시”를 일반적인 방법으로 사용하지 말고, 페이지에 접속하기 위해 출처가 불분명한 루트 인증서를 시스템에 가져오지도 마세요. 회사 장치는 인증서와 프록시 정책을 관리자가 통합 설정할 수 있으므로 개인이 임의로 변경하면 규정 준수나 접속에 문제가 생길 수 있습니다. 공용 네트워크에서 인증서 발급자가 비정상이라면 먼저 신뢰할 수 있는 네트워크로 바꿔 확인하세요. 특정 사이트에서만 문제가 계속되면 사이트 운영자에게 서버 인증서 체인과 도메인 설정을 확인해 달라고 요청해야 합니다.
오류 코드 기록
→ 시스템 시간과 시간대 보정
→ 인증서 도메인 / 유효 기간 / 발급자 확인
→ 직접 연결과 프록시에서 같은 사이트 비교
→ 노드, 규칙 매칭과 DNS 확인
→ TUN 전환과 브라우저 인증서 설정 비교
→ 출처가 명확한 경우에만 HTTPS 검사 인증서 처리점검을 마친 뒤에는 기존 프록시 모드와 보안 설정을 복원하고, 테스트를 위해 임시로 추가한 인증서, 브라우저 확장 기능 또는 규칙을 정리하는 것이 좋습니다. 특정 노드에서만 문제가 발생한다면 우선 노드를 바꾸고 서비스 제공업체에 알려 주세요. 모든 노드와 여러 네트워크에서 같은 오류가 발생한다면 장치 시간, 브라우저 환경 또는 대상 사이트의 인증서를 더 우선적으로 확인해야 합니다. 이처럼 계층별로 원인을 좁혀 가면 HTTPS 오류를 막연한 “프록시가 작동하지 않음”에서 구체적인 인증서, DNS 해석, 규칙 또는 네트워크 단계의 문제로 분류할 수 있습니다.