문제 해결 예상 읽는 시간 10분

프록시 사용 후 HTTPS 인증서 오류가 발생할 때: 원인별 점검 가이드

시스템 시간부터 중간자 검사, Fake-IP 캐시, 노드 경로 문제까지 프록시 사용 중 인증서 경고가 나타나는 원인을 살펴보고 순서대로 점검하는 방법을 안내합니다.

먼저 오류 유형을 확인하세요: 인증서 검증 실패와 연결 실패는 다릅니다

Clash를 켠 뒤 “연결이 비공개로 설정되어 있지 않습니다”라는 경고가 떠도 클라이언트가 웹사이트 인증서를 바꿨다는 뜻은 아닙니다. 일반적인 HTTP CONNECT, SOCKS 또는 TUN 전달 방식은 대상 사이트의 인증서를 발급하지 않습니다. 브라우저는 여전히 사이트의 인증서 체인, 유효 기간, 도메인을 검증합니다. 프록시는 연결 경로를 바꾸며, 경로에 있는 DNS, 출구 노드, 인증 게이트웨이 또는 트래픽 검사 프로그램 때문에 브라우저가 다른 인증서를 받을 수 있습니다.

먼저 주소창의 전체 호스트 이름과 오류 코드를 기록한 다음, 경고 페이지에서 인증서 보기 기능을 여세요. 브라우저마다 메뉴 위치는 다르지만 인증서의 ‘발급자’, ‘유효 기간’, ‘주체 대체 이름’(SAN)을 확인하면 됩니다. 인증서에 표시된 이름만 보지 마세요. 도메인 일치 여부는 SAN을 기준으로 판단해야 합니다.

오류 또는 증상 우선 확인할 항목 이것만으로 단정할 수 없는 점
NET::ERR_CERT_DATE_INVALID 시스템 시간, 인증서 유효 시작일과 만료일 노드가 반드시 작동 불능인 것은 아닙니다
NET::ERR_CERT_AUTHORITY_INVALID 인증서 체인, 신뢰 루트, HTTPS 검사 프로그램 페이지에서 제공하는 루트 인증서를 바로 설치하지 마세요
NET::ERR_CERT_COMMON_NAME_INVALID SAN, DNS 조회 결과, 인증 게이트웨이 오류 이름만으로 사이트 이름이 바뀌었다고 단정할 수 없습니다
ERR_PROXY_CONNECTION_FAILED 로컬 수신 포트, 클라이언트 실행 상태 웹사이트 인증서 검증 오류가 아닙니다
시간 초과, 연결 재설정, TLS 핸드셰이크 실패 네트워크 경로, 프로토콜 호환성, 출구 연결 상태 서버 인증서를 아직 받지 못했을 수도 있습니다

시스템 시간과 신뢰 저장소: 먼저 기기의 검증 조건을 확인하세요

날짜, 시간, 시간대를 확인하세요

인증서에는 유효 시작 시각과 만료 시각이 지정되어 있습니다. 컴퓨터가 절전 모드에서 깨어난 뒤, 메인보드 배터리에 문제가 생겼을 때, 또는 시간을 수동으로 변경한 뒤에는 시스템 시간이 실제 시간과 어긋날 수 있습니다. 관련 없는 여러 사이트에서 날짜 오류가 발생한다면 먼저 기기 설정을 확인하세요. 노드를 계속 바꿀 필요는 없습니다.

  1. Windows 11에서는 ‘설정’ → ‘시간 및 언어’ → ‘날짜 및 시간’으로 이동해 ‘자동으로 시간 설정’과 시간대를 확인한 다음 ‘지금 동기화’를 누르세요.
  2. macOS에서는 ‘시스템 설정’ → ‘일반’ → ‘날짜 및 시간’에서 날짜 및 시간 자동 설정을 확인하세요. 관리형 기기에서는 관리자 권한이 필요할 수 있습니다.
  3. 브라우저를 다시 열고 원래 도메인에 접속하세요. 한 사이트에서만 오류가 계속되면 해당 사이트의 인증서가 실제로 만료됐는지 확인하세요.

Windows에서는 아래 명령으로 현재 시간과 Windows 시간 서비스 상태를 확인할 수 있습니다. 두 번째 명령에서 서비스가 실행 중이 아니라고 나오면 시간 동기화 상태를 확인하지 못한 것입니다. HTTPS 자체에 문제가 있다는 뜻은 아닙니다.

Get-Date
w32tm /query /status

인증서 체인 누락과 오래된 신뢰 저장소를 구분하세요

오래된 운영체제, 오랫동안 업데이트하지 않은 브라우저, 웹사이트의 중간 인증서 누락은 모두 신뢰 체인 오류를 일으킬 수 있습니다. 먼저 운영체제와 브라우저를 정식으로 업데이트한 뒤 같은 기기에서 다른 브라우저로 접속해 보세요. 브라우저마다 루트 인증서를 처리하는 방식이 다를 수 있으므로, 다른 브라우저에서 열린다는 사실만으로 서버 인증서가 정상이라고 단정할 수는 없습니다.

같은 웹사이트에서 여러 기기와 네트워크를 사용해도 오류가 나고 다른 사이트는 정상이라면 웹사이트 관리자가 인증서 설정을 수정해야 할 가능성이 큽니다. 검색 결과나 오류 페이지에서 출처를 알 수 없는 인증서를 내려받아 ‘신뢰할 수 있는 루트 인증 기관’에 추가하지 마세요.

중간자 검사와 HTTPS 검사: 인증서 발급자를 확인하세요

Fiddler, Charles, mitmproxy 등의 트래픽 검사 도구는 HTTPS 복호화를 켜면 로컬에서 신뢰하는 루트 인증서로 웹사이트 인증서를 동적으로 발급합니다. 기업 보안 게이트웨이나 일부 보안 프로그램의 ‘HTTPS 검사’도 비슷하게 작동할 수 있습니다. 루트 인증서가 제대로 설치되지 않았거나 만료됐거나, 브라우저가 해당 신뢰 출처를 허용하지 않으면 인증서 경고가 나타납니다.

프록시 설정과 트래픽 검사 프로세스를 함께 확인하세요

  • 트래픽 검사 도구가 계속 실행 중인지, HTTPS 복호화가 켜져 있는지, 시스템 프록시를 설정했는지 확인하세요.
  • Windows에서 ‘설정’ → ‘네트워크 및 인터넷’ → ‘프록시’를 열고 ‘프록시 서버 사용’의 주소와 포트를 기록한 뒤 Clash 클라이언트의 현재 수신 설정과 비교하세요.
  • 인증서의 ‘발급자’가 트래픽 검사 도구나 조직 이름으로 바뀌었는지 확인하세요. 낯선 이름이 있으면 추가 확인이 필요하지만, 이름만으로 공격이라고 단정해서는 안 됩니다.
  • 개인용 트래픽 검사 도구를 종료한 뒤 클라이언트의 시스템 프록시를 다시 켜고 확인하세요. 기업 관리 기기라면 관리자에게 문의하고 조직 인증서나 보안 정책을 임의로 삭제하지 마세요.

127.0.0.1:7890은 흔히 사용하는 로컬 프록시 예시일 뿐, 모든 클라이언트에서 고정으로 사용하는 포트는 아닙니다. 트래픽 검사 도구와 Clash가 차례로 시스템 프록시를 바꾸면 나중에 설정한 값이 앞선 설정을 덮어쓸 수 있습니다. 다른 프로세스가 포트를 사용 중이면 예상하지 못한 로컬 서비스에 연결될 수도 있습니다.

일반적인 Clash/mihomo 전달 방식에서는 브라우저에 루트 인증서를 설치할 필요가 없습니다. ‘프록시 문제 해결’을 내세우는 안내에서 출처 불명의 루트 인증서를 설치하라고 하면 먼저 작업을 중단하세요. 루트 인증서는 신뢰를 부여하는 권한이지, 속도를 높이는 설정이 아닙니다.

Fake-IP와 DNS 캐시: 매핑을 커널이 계속 처리하는지 확인하세요

mihomo의 Fake-IP 모드는 도메인에 매핑 주소를 반환하며, 흔히 사용하는 설정 범위는 198.18.0.1/16입니다. 커널은 매핑된 주소에서 도메인을 복원한 뒤 규칙을 적용하고 연결합니다. 이 주소는 웹사이트의 실제 공인 IP가 아니므로 HTTPS 주소를 만들어 테스트하는 데 사용하면 안 됩니다.

Fake-IP 자체는 인증서를 발급하지 않으며 브라우저의 신뢰 저장소도 바꾸지 않습니다. 흔한 문제는 브라우저나 시스템에 이전 Fake-IP 주소가 캐시되어 있지만 TUN, DNS 가로채기 또는 클라이언트가 중지되어 매핑을 관리하는 커널로 연결이 돌아가지 않는 경우입니다. 보통은 연결 실패로 나타납니다. 트래픽이 잘못된 TLS 서비스에 도달해야 도메인 불일치 등의 인증서 오류로 이어질 수 있습니다.

순서대로 DNS와 연결 상태를 복구하세요

  1. 현재 ‘시스템 프록시’와 ‘TUN 모드’ 상태, 활성 설정의 dns.enhanced-mode, fake-ip-range, fake-ip-filter 값을 기록하세요. 여러 설정을 한꺼번에 바꾸지 마세요.
  2. 오류 페이지를 닫고 클라이언트 커널이 실행 중인지 확인한 다음 현재 설정을 다시 불러오세요. 클라이언트에 DNS 또는 Fake-IP 캐시 정리 기능이 있다면 기능을 이해한 뒤 사용하세요.
  3. Windows 명령 프롬프트에서 ipconfig /flushdns를 실행한 다음 브라우저를 완전히 종료했다가 다시 여세요. 시스템 캐시를 지워도 브라우저와 라우터의 모든 캐시가 자동으로 삭제되지는 않습니다.
  4. 원래 도메인에 다시 접속하면서 클라이언트의 ‘연결’ 또는 ‘로그’에 해당 도메인이 표시되는지, 어떤 규칙과 프록시 체인이 적용됐는지 확인하세요.

브라우저의 ‘보안 DNS’ 설정에 따라 도메인 조회 경로가 달라질 수 있습니다. Chrome에서는 ‘설정’ → ‘개인 정보 보호 및 보안’ → ‘보안’ → ‘보안 DNS 사용’으로 이동합니다. 세부 옵션은 버전과 조직 정책에 따라 달라질 수 있습니다. 문제를 확인하는 동안 기존 값을 기록하고 잠시 꺼서 테스트한 뒤 원래대로 복구할 수 있습니다. 보안 DNS를 끄는 것을 모든 인증서 오류의 해결책으로 삼지는 마세요.

노드, 출구 경로, 인증 게이트웨이: 한 번에 하나씩 비교해 범위를 좁히세요

기기 시간이 정상이고 HTTPS 복호화 도구도 없다면 이제 연결 경로를 비교하세요. 노드 문제, 출구 DNS 오류, 공용 Wi-Fi의 로그인 게이트웨이, 잘못된 규칙 경로 때문에 연결이 엉뚱한 서버에 도달할 수 있습니다. 일반적으로 프록시 노드는 브라우저가 신뢰하는 대상 웹사이트 인증서를 위조할 수 없습니다. 인증서 경고는 무시하면 안 되는 경계 신호이므로, ‘일단 페이지를 열기 위해’ 검증을 건너뛰지 마세요.

조건을 한 번에 하나씩만 바꾸세요

  1. 같은 기기, 같은 브라우저, 같은 URL을 사용하고 현재 모드, 적용된 규칙, 실제 선택된 노드를 기록하세요. 정책 그룹이 자동 선택 방식이라면 테스트 중 노드가 바뀌었는지도 확인하세요.
  2. 나머지 설정은 그대로 두고 신뢰할 수 있는 다른 노드로 전환한 다음 오류 코드와 인증서 발급자가 달라지는지 확인하세요.
  3. 네트워크 사용 정책을 준수하는 범위에서 직결도 테스트하세요. TUN이 켜져 있으면 ‘시스템 프록시’만 꺼도 직결되는 것은 아닙니다. 해당 트래픽 가로채기 기능을 명시적으로 끄거나 테스트 연결에 DIRECT가 적용되는지 확인하세요.
  4. 가능하면 휴대폰 핫스팟으로 바꿔 테스트하세요. 특정 Wi-Fi에서만 문제가 발생한다면 네트워크 포털 인증을 완료해야 하는지 확인하세요. 인증서 경고 페이지에 자격 증명을 입력하지 말고 운영체제의 네트워크 로그인 알림을 사용하세요.

특정 노드에서만 문제가 발생한다면 민감한 작업에 해당 노드를 사용하지 말고 서비스 제공업체에 도메인, 발생 시각, 오류 코드, 인증서 발급자를 전달하세요. 한 번의 도메인 불일치만으로 ‘노드가 트래픽을 가로챘다’고 입증되지는 않습니다. 하지만 관련 없는 여러 사이트에서 갑자기 똑같이 낯선 인증서가 표시된다면 해당 경로를 즉시 중단하고 확인해야 합니다.

실제 연결 경로는 규칙으로 확인하세요. 모드 이름만으로 판단하지 마세요

규칙 모드에서는 로그에서 DOMAIN-SUFFIX, GEOIP, 마지막의 MATCH 중 어떤 규칙이 적용됐는지 확인하고 최종 정책도 살펴보세요. 프록시 그룹 이름이 ‘자동 선택’이나 ‘Proxy’라고 해서 의도한 출구를 사용 중인 것은 아닙니다. 그룹 안에서 DIRECT가 선택됐을 수도 있습니다. TUN은 트래픽을 가로채는 기능이지 잘못된 인증서를 자동으로 고치는 기능이 아닙니다. 전역 모드로 바꾸는 것도 규칙 확인을 대신할 수 없습니다.

명령줄에서 다시 확인하기: 포트와 검증 범위를 분명히 하세요

아래 예제는 Windows에 기본 제공되는 curl.exe로 공개 도메인에 접속해 비교합니다. 클라이언트의 HTTP 또는 mixed 수신 포트가 7890이라고 가정했으므로 실행 전에 실제 포트로 바꾸세요. SOCKS 전용 포트는 HTTP 프록시로 사용할 수 없습니다. -I는 응답 헤더를 요청하고 -v는 연결 및 TLS 진단 정보를 출력합니다.

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

두 번째 명령은 curl에서 지정한 프록시만 사용하지 않을 뿐, 실행 중인 TUN, 투명 게이트웨이 또는 기업 네트워크 장비를 우회하지는 않습니다. 실제 연결 경로를 비교하려면 먼저 트래픽 가로채기 상태를 확인하세요. curl 빌드마다 TLS 백엔드와 인증서 저장소가 다를 수 있으므로 명령은 성공하지만 브라우저에서 실패한다면 브라우저의 인증서 정책, 확장 프로그램, 캐시도 확인해야 합니다.

  • 127.0.0.1에 연결할 수 없다는 메시지가 나오면 먼저 커널 실행 여부와 수신 포트를 확인하세요. DNS를 바로 바꿀 필요는 없습니다.
  • 프록시 터널이 성공적으로 만들어진 뒤 인증서 오류가 나타난다면 이후의 TLS 검증을 중점적으로 확인하세요. 터널 연결 성공이 인증서의 신뢰성을 보장하지는 않습니다.
  • 인증서 검증은 성공했지만 403 또는 429가 반환된다면 HTTP 접근 제한이나 요청 빈도 제한입니다. 인증서 오류가 아닙니다.
  • 인증서 검증 실패가 발생하면 전체 오류 내용을 기록하고 시간, 도메인, 신뢰 체인, 연결 경로를 계속 비교하세요. 문제를 숨기기 위해 -k 또는 --insecure를 사용하지 마세요.

설정을 복구하고 문제 정보를 전달하세요

점검을 마친 뒤 일시적으로 껐던 보안 DNS, 변경한 프록시 모드, 테스트 노드를 예정된 상태로 복구하세요. 설정을 수정했다면 원본 파일과 변경 내역을 보관하세요. 다음 구독 업데이트가 로컬 변경 사항을 덮어써 같은 문제가 다시 발생하는 일을 막을 수 있습니다. 구독 링크를 문의 티켓이나 공개 게시판에 그대로 올리지 마세요.

클라이언트 유지관리자, 웹사이트 관리자 또는 네트워크 관리자에게 문의할 때는 다음 정보를 제공하세요. ‘Clash를 켜면 오류가 납니다’라는 설명보다 문제를 파악하는 데 도움이 됩니다. Clash 배포 스테이션은 클라이언트 다운로드와 사용 안내를 제공하는 사이트이며 클라이언트 공식 개발팀이 아닙니다. 구체적인 결함은 해당 프로젝트나 서비스 제공업체에 문의하세요.

  • 운영체제, 브라우저, 클라이언트, mihomo 커널의 정확한 버전 번호. 각 프로그램의 ‘정보’ 또는 버전 정보 화면에서 확인할 수 있습니다.
  • 오류가 발생한 호스트 이름, 발생 시각과 시간대, 브라우저 오류 코드, 인증서 발급자와 유효 기간.
  • 시스템 프록시와 TUN 상태, 실제 수신 포트, 적용된 규칙 유형과 최종 정책. 노드 이름은 익명 처리해도 됩니다.
  • 같은 URL에서 노드 변경, 직결 확인, 네트워크 변경 후 각각 어떤 결과가 나왔는지 기록하고 단계마다 바꾼 항목을 명확히 하세요.

권장 순서는 오류 기록 → 시간 확인 → 인증서 체인과 복호화 도구 확인 → 일치하지 않는 DNS 상태 정리 → 노드와 네트워크 경로 비교입니다. 트래픽 가로채기 설정을 추가로 확인하려면 시스템 프록시 설정, 규칙 설정 안내, 문제 해결을 참고하세요. 인증서 검증이 정상적으로 복구된 뒤 로그인이나 민감한 작업을 진행하세요.

Clash 다운로드