Clash 실행 후 HTTPS 인증서 오류가 표시될 때: 원인과 해결 방법

먼저 인증서 오류가 정말 Clash 때문인지 확인하기

HTTPS 인증서 오류가 발생했다고 해서 Clash 클라이언트가 손상된 것은 아닙니다. 브라우저는 HTTPS 웹사이트에 접속할 때 인증서의 도메인, 유효 기간, 발급 기관, 인증서 체인을 확인합니다. Clash는 일반적으로 암호화된 트래픽을 전달할 뿐, 이미 수립된 TLS 세션의 내용을 읽을 수 없습니다. 연결 대상, 시스템 시간, 인증서 체인이 정상이라면 규칙 기반 프록시나 TUN 모드를 켰다는 이유만으로 웹사이트 인증서를 추가 설치할 필요는 없습니다.

문제는 전달 경로가 바뀐 뒤 더 자주 발생합니다. 프록시 노드가 연결을 잘못된 서버로 전달했거나, DNS가 비정상 주소를 반환했거나, 로컬 네트워크의 HTTP 프록시가 트래픽을 복호화하려 했거나, 기기 시간 오차로 유효 기간 판단이 잘못됐을 수 있습니다. Clash를 켠 시점에 이런 경로가 활성화되어 두 일이 시간상 가까워 보일 뿐입니다. 문제를 해결할 때는 클라이언트, 설정, 노드, 대상 웹사이트를 구분해 확인해야 합니다.

먼저 켜짐/꺼짐 상태를 비교하세요

1. 오류가 발생한 웹사이트의 전체 도메인(예: accounts.example.com)을 기록하세요. 홈페이지 이름만 적지 마세요.
2. 경고 페이지에 표시된 오류 코드, 인증서 발급자, 유효 기간을 캡처하세요. Safari에서는 ‘이 연결은 비공개 연결이 아님’이 표시될 수 있으며, Chromium 기반 브라우저에서는 NET::ERR_CERT_DATE_INVALID, NET::ERR_CERT_COMMON_NAME_INVALID, NET::ERR_CERT_AUTHORITY_INVALID 코드가 자주 나타납니다.
3. Clash의 시스템 프록시 또는 VPN 연결을 끄고, 브라우저를 완전히 종료한 뒤 다시 열어 같은 HTTPS 주소에 접속하세요.
4. Clash를 다시 활성화한 다음 해당 도메인을 임시로 DIRECT에 지정하세요. 직접 연결은 정상인데 프록시 그룹에서 오류가 발생한다면 현재 노드와 상위 경로를 우선 확인하세요.
5. Wi-Fi와 셀룰러 네트워크에서 각각 테스트하세요. 특정 Wi-Fi에서만 오류가 발생한다면 라우터, 공용 네트워크 인증 페이지, 수동 프록시를 먼저 확인해야 합니다.

노드가 가로채졌거나 상위 경로에서 잘못된 인증서를 반환하는 경우

규칙에 따라 도메인이 프록시 노드로 전달되면 노드가 기기를 대신해 대상 서버에 연결합니다. 노드의 출구가 투명 프록시, 악성 게이트웨이, 비정상적인 상위 경로에 장악되면 브라우저가 받은 인증서가 다른 도메인에 속하거나 기기에서 신뢰하지 않는 기관이 발급한 것일 수 있습니다. 이런 문제는 대개 특정 노드나 특정 경로에서만 반복됩니다.

대표적인 증상

• 같은 웹사이트가 DIRECT에서는 정상인데 특정 프록시 노드로 전환하면 도메인 불일치 오류가 발생합니다.
• 인증서의 ‘발급 대상’ 항목이 주소 표시줄의 도메인과 전혀 관련 없습니다. 예를 들어 계정 도메인에 접속했는데 라우터 관리 페이지나 낯선 도메인의 인증서가 도착합니다.
• 같은 구독의 다른 지역 노드로 전환하면 정상으로 돌아오지만, 원래 노드에서는 반복해서 오류가 발생합니다.
• HTTP 웹사이트가 광고 페이지, 인증 페이지, 낯선 검색 페이지로 리디렉션되는 동시에 HTTPS 웹사이트에서 인증서 이상이 발생합니다.

Clash의 전역 모드는 모든 일치 트래픽을 현재 프록시 그룹으로 보내므로 노드 비교에 유용합니다. 테스트가 끝나면 기존 규칙 모드로 되돌리세요. 특정 노드 하나만 비정상이라면 전체 구독을 삭제할 필요가 없습니다. 먼저 프록시 그룹에서 해당 노드를 제외한 뒤 구독을 업데이트해 서비스 제공업체가 경로를 조정했는지 확인하세요.

인증서의 세 항목 확인하기

1. Subject Alternative Name: 현재 접속 중인 전체 도메인이 포함되어 있어야 합니다. 와일드카드 *.example.com은 일반적으로 한 단계의 하위 도메인만 포함합니다.
2. Issuer: 발급 기관이 일관적인지 확인하세요. 테스트 전후로 공개 CA에서 기업 게이트웨이, 라우터 장비 또는 낯선 이름으로 갑자기 바뀌었다면 주의해야 합니다.
3. Validity: 현재 시간이 ‘유효 시작 시간’과 ‘만료 시간’ 사이에 있는지 확인하세요. 인증서 만료는 웹사이트 자체의 유지보수 문제일 수도 있습니다.

macOS에서는 시스템에 기본 제공되는 명령으로 원격 핸드셰이크 결과를 확인할 수 있습니다. 아래의 example.com은 실제 오류가 발생한 도메인으로 바꾸고, 443 포트는 표준 HTTPS 포트입니다.

openssl s_client -connect example.com:443 -servername example.com -showcerts
curl -Iv https://example.com/

-servername은 SNI를 전송합니다. 이 옵션이 없으면 같은 서버가 기본 인증서를 반환해 잘못 판단할 수 있습니다. 명령 출력의 인증서 정보로 직접 연결과 프록시 테스트를 비교할 수 있지만, 명령에 ‘핸드셰이크 성공’이 표시됐다고 웹사이트 콘텐츠까지 안전하다는 뜻은 아닙니다. 도메인과 인증서 발급 체인을 계속 확인하세요.

시스템 시간 오차로 인증서 유효 기간 확인에 실패하는 경우

인증서에는 명확한 유효 시작 시간과 만료 시간이 포함됩니다. iPhone의 시간이 며칠 늦으면 새 인증서를 ‘아직 유효하지 않음’으로 판단할 수 있고, 몇 달 빠르면 정상 인증서를 ‘이미 만료됨’으로 판단할 수 있습니다. 이런 문제는 보통 특정 웹사이트 하나가 아니라 여러 HTTPS 서비스, 앱 로그인, 시스템 계정에서 동시에 발생합니다.

iPhone 및 iPad에서 확인하는 경로

「설정」→「일반」→「날짜 및 시간」을 열고 「자동으로 설정」을 활성화하세요. 그런 다음 시간대가 현재 위치와 일치하는지 확인합니다. 스위치가 비활성화되어 있다면 스크린 타임 제한, 통신사 설정, 기기 관리 정책의 영향을 받을 수 있으므로 해당 제한을 먼저 해결해야 합니다.

• 시간 오차가 5분을 초과하면 일부 로그인 토큰과 일회용 인증 코드도 동시에 만료될 수 있습니다.
• 시간을 수정한 뒤 Safari에서 문제가 발생한 탭을 닫고 다시 여세요. 이전 연결을 계속 재사용하지 않도록 해야 합니다.
• 기기가 장기간 꺼져 있다가 방금 복구된 경우에는 먼저 안정적인 네트워크에 연결하고 시스템이 네트워크 시간 동기화를 완료할 때까지 기다리세요.
• 회사에서 관리하는 기기라면 관리자에게 문의하세요. 조직에서 배포한 관리 프로파일을 임의로 삭제하지 마세요.

인증서 오류에 표시된 날짜도 확인하세요. 브라우저에 인증서가 방금 만료된 것으로 표시되지만 시스템 날짜가 정확하고, 직접 연결·다른 노드·다른 네트워크에서도 같은 결과가 나오면 웹사이트 서버의 문제일 가능성이 큽니다. 이 경우 Clash 설정을 바꿔도 해결되지 않으며 웹사이트가 인증서를 갱신할 때까지 기다려야 합니다.

DNS 오염으로 도메인이 잘못된 서버로 연결되는 경우

HTTPS 연결을 시작하기 전에 기기는 도메인을 IP 주소로 변환해야 합니다. DNS가 잘못된 주소를 반환하면 TLS 요청이 다른 서버에 도착하고, 해당 서버는 당연히 일치하지 않는 인증서를 반환할 수 있습니다. 이때 브라우저에는 단순한 연결 시간 초과가 아니라 인증서가 현재 도메인에 적합하지 않다는 메시지가 자주 표시됩니다.

Clash 또는 mihomo 설정에서 DNS 동작은 nameserver, fallback, nameserver-policy, Fake-IP 매핑, 규칙의 DOMAIN 및 DOMAIN-SUFFIX에서 비롯될 수 있습니다. TUN 모드는 시스템 DNS 요청까지 가로챌 수 있습니다. 문제를 확인할 때 모든 항목을 한꺼번에 바꾸면 어떤 설정이 영향을 줬는지 알 수 없으므로 피하세요.

변수를 최소화해 DNS 확인하기

1. 먼저 구독과 설정을 업데이트하고 YAML이 정상적으로 로드되는지, 들여쓰기나 필드 오류가 없는지 확인하세요.
2. 오류가 발생한 도메인을 임시로 직접 연결 규칙에 추가하고, 해당 규칙이 MATCH보다 앞에 있는지 확인하세요.
3. 클라이언트 DNS 캐시를 삭제하세요. 클라이언트에 별도 메뉴가 없다면 시스템 VPN 연결을 약 10초간 끊었다가 다시 연결하세요.
4. 비행기 모드를 껐다가 다시 켜서 셀룰러 네트워크와 DNS 상태를 새로 가져오세요.
5. 다른 Wi-Fi 또는 셀룰러 네트워크로 다시 테스트해 로컬 라우터 DNS 문제인지 Clash 내장 DNS 문제인지 구분하세요.

임시 규칙은 다음과 같이 작성할 수 있습니다. 규칙은 위에서 아래 순서로 일치하므로 구체적인 도메인을 포괄적인 규칙보다 앞에 배치하세요.

rules:
  - DOMAIN,accounts.example.com,DIRECT
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,PROXY

직접 연결 규칙에서도 Clash의 DNS 모듈을 사용한다면 테스트 결과는 출구 방식이 바뀌었다는 것만 보여 줄 뿐 DNS 문제를 완전히 배제하지 못합니다. 더 엄밀하게 비교하려면 시스템 DNS와 설정 DNS를 함께 비교해야 합니다. 수정하기 전에 기존 설정을 저장하고 테스트가 끝나면 복원해 임시 규칙이 장기간 원래의 트래픽 분기를 방해하지 않도록 하세요.

Fake-IP는 인증서 위조가 아닙니다

Fake-IP 모드는 기기의 앱에 예약 주소를 반환한 뒤, 코어가 도메인 매핑을 기준으로 연결을 전달합니다. 앱에 198.18.0.0/15 범위와 비슷한 주소가 표시될 수 있지만 TLS 핸드셰이크는 여전히 원래 도메인을 사용해야 합니다. Fake-IP 주소가 보인다는 사실만으로 인증서가 교체됐다고 볼 수는 없습니다. 실제로 확인해야 할 부분은 도메인 매핑 손실, 코어를 우회한 DNS 요청, Fake-IP를 지원하지 않는 대상 앱이 잘못된 서버에 접속하는 경우입니다.

로컬 네트워크 기기, 게임 콘솔, 일부 호환되지 않는 앱에서만 문제가 발생한다면 전체 DNS를 끄기보다 해당 도메인에 Fake-IP 필터를 설정하세요. 구체적인 필드명은 Clash Meta 또는 mihomo 설정 버전에 따라 다르므로, 편집 후 설정 검증이 통과했는지 먼저 확인한 다음 TUN을 시작해야 합니다.

HTTP 프록시, 패킷 캡처 도구, 인증서 설치의 영향

일반적인 Clash HTTPS 전달은 보통 연결 통로만 만들며 웹사이트 인증서를 발급하지 않습니다. 패킷 캡처, 디버깅, 자녀 보호, 기업 게이트웨이, 콘텐츠 필터링 도구가 TLS 복호화를 직접 수행할 때만 기기에서 로컬 또는 게이트웨이 CA가 새로 발급한 인증서를 보게 됩니다. 이 CA를 시스템이 신뢰하지 않으면 복호화 대상인 모든 웹사이트에서 ‘발급 기관을 신뢰할 수 없음’ 오류가 발생할 수 있습니다.

Wi-Fi 수동 프록시 확인하기

iPhone에서 「설정」→「Wi-Fi」→ 현재 네트워크 오른쪽의 정보 버튼 →「프록시 구성」을 여세요. Clash의 시스템 VPN 또는 네트워크 확장을 사용할 때는 로컬 네트워크 프록시에 연결해야 하는 경우가 아니라면 보통 「끔」으로 설정해야 합니다.

일반적인 로컬 HTTP 또는 mixed 수신 포트는 7890, SOCKS 포트는 7891인 경우가 많지만 설정에 따라 달라질 수 있습니다. Wi-Fi 프록시가 192.168.1.20:8080처럼 낯선 로컬 네트워크 주소를 가리킨다면 설정을 먼저 기록한 뒤 프록시를 끄고 다시 테스트하세요. 다른 컴퓨터의 127.0.0.1로 착각하지 마세요. 루프백 주소는 언제나 현재 기기 자체를 의미합니다.

관리 프로파일과 인증서 신뢰 설정 확인하기

1. 「설정」→「일반」→「VPN 및 기기 관리」를 열고 모르는 구성 프로파일이 있는지 확인하세요.
2. 「설정」→「일반」→「정보」→「인증서 신뢰 설정」을 열고 완전히 신뢰하도록 활성화된 루트 인증서를 확인하세요.
3. 경고를 없애기 위해 웹페이지에서 임시로 제공하는 CA를 설치하지 말고, 출처가 불분명한 루트 인증서의 완전한 신뢰를 함부로 활성화하지 마세요.
4. 회사나 학교에서 관리하는 기기에는 합법적으로 검사 인증서가 배포되어 있을 수 있습니다. 먼저 네트워크 관리자에게 이름, 용도, 유효 기간을 확인하세요.

Clash 설정만 삭제한다고 해서 다른 도구가 설치한 구성 프로파일이나 루트 인증서까지 제거되지는 않습니다. 반대로 기업 인증서를 함부로 삭제하면 회사 Wi-Fi, 내부 웹사이트, 이메일이 작동하지 않을 수 있습니다. 인증서를 처리하기 전에 출처를 확인하고, 패킷 캡처 도구를 비활성화할지, 수동 프록시를 끌지, 관리자가 인증서를 다시 배포하도록 요청할지 결정하세요.

Clash 설정 및 규칙 집중 점검

인증서 오류는 규칙이 잘못된 출구를 선택해서 발생할 수도 있습니다. 예를 들어 원래 직접 연결해야 하는 도메인이 지나치게 포괄적인 DOMAIN-SUFFIX 규칙에 의해 불안정한 노드로 전달되거나, 구독에서 사용하는 정책 그룹 이름이 바뀌어 트래픽이 최종 MATCH 정책으로 들어갈 수 있습니다. 이때는 현재 모드 이름만 보지 말고 실제 일치 기록을 확인해야 합니다.

모드와 정책 그룹 확인하기

• 규칙 모드: 규칙에 따라 직접 연결, 프록시, 거부를 결정하며 특정 도메인의 일치 경로를 확인하는 데 적합합니다.
• 전역 모드: 현재 전역 노드를 일괄 사용하므로 노드 비교에 적합하지만 테스트 후에는 원래 모드로 복원해야 합니다.
• 직접 연결 모드: 프록시 노드를 우회하므로 문제가 프록시 경로를 따라 발생하는지 판단할 때 사용할 수 있습니다.

클라이언트의 연결 기록에서 오류가 발생한 도메인과 하위 도메인을 찾으세요. 최신 웹페이지는 로그인 도메인, 정적 리소스 도메인, API 도메인에 동시에 접속할 수 있으므로 메인 페이지가 직접 연결된다고 해서 모든 요청이 직접 연결되는 것은 아닙니다. 일치한 규칙 유형, 정책 그룹 이름, 최종 노드를 중점적으로 확인하세요.

포트와 프록시 체인을 섞어 사용하지 않기

데스크톱 패킷 캡처 도구, 브라우저 프록시 확장 프로그램, Clash를 동시에 실행하면 여러 단계의 프록시가 구성될 수 있습니다. 예를 들어 브라우저 확장 프로그램이 127.0.0.1:8080을 가리키고, 패킷 캡처 도구가 이를 Clash의 127.0.0.1:7890으로 전달하는 식입니다. 어느 한 단계에서든 HTTPS 복호화를 활성화하면 인증서가 바뀔 수 있습니다.

문제 해결 단계에서는 경로를 하나만 남기세요. 브라우저 프록시 확장 프로그램을 끄고 패킷 캡처 도구를 비활성화한 뒤, 시스템 프록시 또는 TUN이 Clash로 직접 연결되도록 하세요. 복원할 때는 한 번에 구성 요소 하나만 켜고 매번 같은 도메인으로 테스트하세요. 그러면 어느 단계에서 인증서가 교체되는지 확인할 수 있습니다.

위험도가 낮은 단계부터 진행하는 처리 순서

1. 오류 정보 저장: 도메인, 시간, 오류 코드, 인증서 발급자, 현재 노드를 기록합니다.
2. 민감한 입력 중단: 원인이 확인될 때까지 계정에 로그인하거나 결제 정보를 제출하지 않습니다.
3. 시스템 시간 보정: 「설정」→「일반」→「날짜 및 시간」에서 자동 설정을 활성화합니다.
4. Clash 끄고 비교: 브라우저를 종료한 뒤 다시 테스트해 이전 연결 재사용을 배제합니다.
5. 직접 연결과 노드 전환: 오류가 특정 프록시 출구에서만 발생하는지 확인합니다.
6. 네트워크 변경: Wi-Fi와 셀룰러 네트워크를 비교해 라우터 또는 공용 네트워크 인증 개입을 확인합니다.
7. 규칙 일치 확인: 도메인에 실제로 적용된 정책 그룹과 노드를 확인합니다.
8. DNS 확인: 캐시를 삭제하고 Fake-IP, nameserver, 도메인 정책을 점검합니다.
9. 수동 프록시 확인: Wi-Fi의 「프록시 구성」과 브라우저 프록시 확장 프로그램을 확인합니다.
10. 루트 인증서 확인: 구성 프로파일과 완전히 신뢰된 인증서의 출처를 확인합니다.

특정 노드에서만 오류가 발생하고 인증서 도메인도 명확히 일치하지 않는다면 해당 노드의 사용을 중단하세요. 발생 시간, 대상 도메인, 인증서 발급자를 구독 서비스 제공업체에 전달하면 됩니다. 모든 네트워크와 기기에서 같은 웹사이트에 동일한 만료 인증서가 표시된다면 웹사이트 운영자가 수정할 때까지 기다리는 것이 일반적입니다.

낯선 프록시를 제거하고 비정상 노드를 끈 뒤에도 많은 HTTPS 웹사이트에서 오류가 계속되면 중요한 데이터를 먼저 백업한 다음 네트워크 설정 재설정을 고려하세요. iPhone 경로는 「설정」→「일반」→「전송 또는 iPhone 재설정」→「재설정」→「네트워크 설정 재설정」입니다. 저장된 Wi-Fi 네트워크, VPN, 일부 네트워크 매개변수가 삭제되므로 일반적인 점검을 마친 뒤 시행해야 하며 첫 단계로 사용해서는 안 됩니다.

자주 묻는 질문