프록시 사용 중 HTTPS 인증서 오류? 원인과 해결 방법

먼저 구분하기: 웹사이트 인증서 오류인가, 프록시 노드 핸드셰이크 실패인가

Clash를 켠 뒤 HTTPS 오류가 발생했다고 해서 Clash가 웹사이트 인증서를 바꾼 것은 아닙니다. 일반적인 HTTP CONNECT, SOCKS 프록시와 TUN 전달은 연결만 중계하며, 브라우저와 웹사이트 사이의 HTTPS 내용을 복호화하지 않습니다. 먼저 어느 구간에서 실패했는지 확인한 다음 브라우저, 시스템 신뢰 저장소 또는 노드 설정을 점검하세요.

브라우저 오류 코드만으로 판단할 수 없는 경우도 있습니다. ERR_SSL_PROTOCOL_ERROR는 TLS 프로토콜 계층 오류이며, 인증서가 교체되었다는 증거는 아닙니다. HTTPS 요청을 일반 HTTP 서버로 보냈거나, 서버의 TLS 설정에 문제가 있거나, 네트워크 장비가 핸드셰이크 도중 연결을 끊었을 때도 발생할 수 있습니다.

1단계: 시스템 시간과 인증서 유효기간 확인

인증서에는 유효 시작일과 만료일이 있습니다. 컴퓨터 시간이 이 기간을 벗어나면 올바른 서버에 접속하더라도 오류가 발생할 수 있습니다. 절전 모드에서 복귀한 뒤, 메인보드 배터리에 문제가 있을 때, 가상 머신의 시간이 동기화되지 않았을 때도 시간이 어긋날 수 있습니다. DNS를 바꾸거나 클라이언트를 다시 설치하기 전에 시간을 먼저 확인하세요.

1. Windows 11: 「설정」→「시간 및 언어」→「날짜 및 시간」으로 이동해 「시간 자동 설정」을 켜고 시간대를 확인한 다음 「지금 동기화」를 클릭하세요.
2. macOS: 「시스템 설정」→「일반」→「날짜 및 시간」에서 날짜와 시간 자동 설정을 확인하세요. 변경할 때는 시스템에서 요구하는 권한을 승인해야 합니다.
3. Android: 시스템 설정에서 「날짜 및 시간」을 검색해 시간과 시간대 자동 설정을 켜세요. 메뉴 구성은 제조사마다 다를 수 있습니다.
4. iOS: 「설정」→「일반」→「날짜 및 시간」에서 「자동 설정」을 확인하세요. 기기 관리 정책으로 변경이 제한되면 관리자에게 문의하세요.

브라우저의 인증서 경고 상세 정보에서 인증서 보기 메뉴를 찾아 「유효 기간 시작」, 「유효 기간 종료」, 「발급자」를 기록하세요. 데스크톱 Chromium 브라우저에서는 개발자 도구의 「보안」 패널에서도 인증서 정보를 확인할 수 있습니다. 메뉴 이름과 위치는 브라우저 버전에 따라 달라질 수 있습니다.

기기의 날짜가 정확한데 특정 사이트의 인증서만 만료되었다면 웹사이트 운영자가 인증서를 갱신해야 합니다. 노드를 바꿔도 만료된 인증서가 유효해지지는 않습니다. 특정 노드에서만 오래된 인증서가 나타난다면 해당 노드의 출구가 다른 서버에 연결되는지 확인해야 합니다.

2단계: 같은 URL로 직접 연결과 프록시 연결 비교

비교 테스트에서는 도메인과 경로를 포함해 URL 전체를 동일하게 유지하세요. 한 번에 조건 하나만 바꾸고 오류 코드, 인증서 발급자, 적용된 규칙을 기록하세요. 노드, DNS, 브라우저, 네트워크를 동시에 바꾸면 문제가 해결되더라도 원인을 알 수 없습니다.

권장하는 4단계 확인 방법

1. 현재 상태 기록: 클라이언트의 현재 모드, 선택한 노드, 시스템 프록시와 TUN 설정을 기록하세요. 먼저 「연결」 목록에서 도메인을 찾아 실제 적용된 정책을 확인하세요.
2. 직접 연결 테스트: 시스템 프록시와 TUN을 끄고 브라우저 프록시 확장 프로그램, 수동 프록시, 다른 VPN이 연결을 가로채고 있지 않은지 확인하세요. 같은 URL에 접속해 결과를 기록하세요.
3. 프록시 다시 켜기: 원래 상태로 복원하고 노드 A를 선택하세요. 연결 목록에서 해당 요청이 실제로 노드 A를 통하는지, DIRECT 규칙이 적용된 것은 아닌지 확인하세요.
4. 노드만 바꾸기: 다른 설정은 그대로 두고 노드 B로 변경한 다음 오류 코드와 인증서 정보를 확인하세요.

직접 연결은 정상이고 노드 A에서는 오류가 나지만 노드 B에서는 정상이라면 노드 A의 출구 경로, DNS 응답 또는 서버 설정에 문제가 있을 가능성이 큽니다. 다만 이 결과만으로 누군가 가로챘다고 단정할 수는 없습니다. 직접 연결과 프록시 연결 모두 오류가 나면 기기 시간, 웹사이트 인증서, 시스템 신뢰 저장소, 사용 중인 네트워크를 먼저 확인하세요.

현재 네트워크에서 직접 연결할 수 없는 웹사이트도 있습니다. 직접 연결이 시간 초과되었다고 해서 인증서가 정상이라는 뜻은 아닙니다. 이 경우 신뢰할 수 있는 다른 네트워크나 다른 기기에서 비교해 볼 수 있지만, 조건이 어떻게 다른지 기록해야 합니다. 다른 기기에서 접속에 성공했다고 해서 이 기기의 설정까지 정상이라고 판단하지 마세요.

명령어로 로컬 프록시 경로 확인

클라이언트의 실제 혼합 포트가 7890이라면 Windows 터미널에서 다음 명령어를 실행할 수 있습니다. macOS와 Linux에서는 curl.exe 대신 curl을 사용하세요. 예시 도메인은 명령어 형식을 보여주기 위한 것이므로, 문제를 확인할 때는 오류가 발생한 웹사이트의 도메인으로 바꾸세요.

curl.exe -v --noproxy "*" https://example.com/
curl.exe -v --noproxy "" --proxy http://127.0.0.1:7890 https://example.com/

첫 번째 명령은 curl에 명시적으로 지정된 프록시 설정을 건너뛰지만, 시스템의 TUN이나 다른 네트워크 수준의 연결 가로채기까지 우회하지는 않습니다. 실행 전에 해당 기능을 꺼야 합니다. 두 번째 명령은 로컬 HTTP 프록시를 명시적으로 통합니다. 포트는 클라이언트에 표시된 값을 사용하세요. curl 빌드와 브라우저는 서로 다른 인증서 신뢰 저장소를 사용할 수 있으므로 결과가 달라도 모순은 아닙니다.

3단계: 중간자 가로채기와 루트 인증서 출처 확인

기업 게이트웨이, 백신 프로그램의 HTTPS 검사, 패킷 캡처 도구는 기기나 네트워크에서 TLS 연결을 종료한 뒤 새로 발급한 인증서를 브라우저에 제공할 수 있습니다. 기기가 해당 루트 인증서를 신뢰하면 브라우저에 경고가 표시되지 않을 수 있습니다. 반대로 루트 인증서가 없거나 만료되었거나 브라우저에서 신뢰하지 않으면 인증 기관을 신뢰할 수 없다는 경고가 나타날 수 있습니다.

먼저 인증서 체인을 확인한 뒤 신뢰 저장소를 조정하세요

• 도메인 확인: 인증서의 「주체 대체 이름」(SAN)에 주소창의 호스트 이름이 포함되어 있는지 확인하세요. 인증서에 표시된 이름이나 조직명만 보고 판단하지 마세요.
• 발급자 확인: 회사 게이트웨이, 패킷 캡처 도구, 보안 프로그램의 이름이 표시되면 설치된 도구 및 조직 정책과 일치하는지 확인하세요. 이름만으로 인증서를 신뢰할 수 있는 것은 아닙니다.
• 영향 범위 확인: 관련 없는 여러 웹사이트에서 갑자기 같은 로컬 발급 인증서가 나타나고 특정 기기나 네트워크에서만 발생한다면, 공통으로 적용되는 HTTPS 검사 과정을 확인해야 합니다.

Windows에서는 Win + R을 누르고 certmgr.msc를 실행해 현재 사용자의 「신뢰할 수 있는 루트 인증 기관」→「인증서」를 확인하세요. 컴퓨터 수준의 인증서는 해당 관리 콘솔에서 확인해야 합니다. macOS에서는 「키체인 접근」에서 「시스템」 또는 「로그인」 키체인을 선택해 인증서와 신뢰 설정을 확인할 수 있습니다.

이 메뉴는 인증서 출처를 확인하기 위한 것이며, 인증서를 한꺼번에 삭제하라는 뜻이 아닙니다. 관리 대상 기기의 인증서는 회사 업무에 필요할 수 있으므로 관리자에게 확인하세요. 개인 기기에서 최근 패킷 캡처 도구를 사용했다면 해당 도구의 안내에 따라 HTTPS 복호화를 중지하고 신뢰 설정을 해제한 뒤 다시 테스트하세요. 출처를 알 수 없는 다운로드 페이지에서 이른바 「Clash 전용 루트 인증서」를 설치하지 마세요. 일반적인 프록시 중계에는 필요하지 않습니다.

4단계: DNS 이상과 노드 TLS 설정 오류 구분

DNS 조회 오류가 인증서 오류처럼 보이는 이유

DNS가 도메인을 잘못된 주소로 연결해도 브라우저는 대상 도메인을 계속 검증합니다. 잘못 연결된 서버가 다른 도메인의 인증서를 보내면 이름 불일치 오류가 발생할 수 있고, 연결을 바로 끊으면 핸드셰이크 실패로 나타날 수 있습니다. DNS가 인증서를 발급하는 것은 아니므로 DNS 응답, 연결 대상, 인증서 SAN을 함께 확인해야 합니다.

Windows에서는 Resolve-DnsName example.com으로 시스템의 DNS 조회 결과를 확인할 수 있습니다. macOS와 Linux에서는 nslookup example.com으로 보조 점검을 하세요. 다만 브라우저의 「보안 DNS」, mihomo 내장 DNS, 프록시 서버의 원격 DNS 조회는 서로 다른 경로를 사용할 수 있으므로 시스템 명령의 결과가 브라우저에서 실제로 사용한 결과와 다를 수 있습니다.

• 클라이언트의 「연결」과 「로그」에서 대상 도메인, 적용된 규칙, 출구 정책을 확인해 요청이 실제로 어디로 전달되는지 파악하세요.
• 현재 적용 중인 설정에서 dns, nameserver, nameserver-policy와 TUN DNS 하이재킹 설정을 확인하세요. 로드되지 않은 파일만 수정하지 않도록 주의하세요.
• fake-ip를 사용 중이라면 198.18.0.0/16 범위의 주소가 보인다고 해서 반드시 DNS 오염인 것은 아닙니다. mihomo의 일반적인 기본 fake-ip 주소 범위는 198.18.0.1/16입니다. 이 주소는 내부 매핑에 쓰이므로 웹사이트의 실제 출구 주소로 보면 안 됩니다.
• DNS 조회 정책을 바꾼 뒤에는 연결을 새로 설정해 다시 테스트하세요. 기존 연결과 캐시가 이전 결과를 계속 사용할 수 있습니다. 처음부터 모든 DNS 항목을 같은 공개 DNS 서버로 바꾸지는 마세요.

노드 인증서 오류는 다른 연결 구간에서 발생합니다

TLS를 사용하는 프록시 프로토콜에서는 클라이언트가 프록시 서버의 인증서도 검증합니다. 브라우저가 웹사이트 인증서를 검증하는 것과는 별개의 절차입니다. 로그에 노드 서버가 대상으로 표시되고 브라우저에는 터널 연결 실패가 나타난다면 구독에서 제공한 서버 주소, 포트, TLS 매개변수를 먼저 확인하세요.

mihomo의 일반적인 TLS 노드 설정을 예로 들면 server는 연결 주소, port는 서버가 수신 대기하는 포트입니다. 일부 프로토콜은 TLS 서비스 이름을 servername으로 지정하고, 다른 설정 유형에서는 sni를 사용합니다. 각 필드의 사용 여부는 프로토콜과 코어의 지원 여부에 따라 달라지므로 한 프로토콜의 설정을 다른 프로토콜에 그대로 복사하면 안 됩니다.

오류 범위에 맞게 조치하고 재현 기록을 남기세요

여기까지 확인했다면 영향 범위를 기준으로 조치를 좁힐 수 있습니다. 접속이 복구되는 것만으로 충분하지 않습니다. 잘못된 신뢰 설정이나 임시로 완화한 검증 옵션이 남아 있지 않은지도 확인하세요.

공용 Wi-Fi는 먼저 포털 인증을 완료해야 할 수 있습니다. 시스템에서 자동으로 표시되는 네트워크 로그인 화면을 이용하고, HTTPS 인증서 경고 페이지에서 무시하고 진행해 계정 정보를 입력하지 마세요. 네트워크의 신원을 확인할 수 없다면 핫스팟 연결을 중단하고 신뢰할 수 있는 네트워크를 사용하세요.

문제를 문의할 때 함께 전달할 정보

• 운영체제, 브라우저 버전, 클라이언트 버전과 코어 이름을 기록하세요. 「정보」 또는 코어 정보 페이지에서 확인할 수 있습니다.
• 문제가 발생한 시각과 대상 도메인, 브라우저에 표시된 전체 오류 코드, 인증서의 SAN·발급자·유효기간을 기록하세요.
• 직접 연결, 노드 A, 노드 B의 비교 결과와 시스템 프록시 및 TUN이 켜져 있었는지 기록하세요.
• 오류 전후의 관련 로그를 첨부하되 구독 링크, 노드 비밀번호, 토큰, 계정 정보, 공개하기 곤란한 주소는 가리세요.

시스템이나 브라우저를 오랫동안 업데이트하지 않았다면 공식 시스템 업데이트와 브라우저 업데이트 경로를 통해 지원되는 보안 업데이트를 설치한 뒤 인증서 체인을 다시 확인하세요. 클라이언트를 바꾸기 전에 현재 포트, 규칙 모드, TUN 상태를 기록해 설치 변경과 네트워크 문제를 혼동하지 않도록 하세요. 기본 설정은 시스템 프록시 설정 안내를, DNS 문제는 DNS 문제 해결 안내를 참고하세요.

안전한 해결 순서는 오류 기록, 시간 확인, 연결 경로 비교, 인증서 출처 확인, 마지막으로 DNS나 노드 매개변수 점검입니다. 과정 내내 인증서 검증을 유지하고, 웹페이지가 열리는 것만을 해결 기준으로 삼지 마세요.