프록시 사용 후 브라우저에서 인증서가 신뢰되지 않는 경우: HTTPS 인증서 오류 원인과 해결 방법

1. 먼저 오류 정보를 기록하고 경고를 무시하지 마세요

Clash 계열 클라이언트를 켠 뒤 브라우저에 “연결이 비공개로 설정되어 있지 않습니다” 또는 “이 연결은 비공개가 아닙니다”라는 메시지가 표시된다면, 브라우저가 대상 사이트의 신원을 확인하지 못한 것입니다. 노드 연결 시간 초과나 구독 만료를 뜻하는 것은 아닙니다. 서버까지 연결되었더라도 서버가 제공한 인증서나 인증서 체인, 또는 기기의 신뢰 설정이 요구 사항을 충족하지 않을 수 있습니다.

문제를 확인하기 전에는 해당 페이지에 비밀번호, 결제 정보, 인증 코드를 입력하지 마세요. 주소창의 전체 호스트 이름, 브라우저 오류 코드, 인증서 발급자와 유효 기간을 기록하세요. 도움을 요청하기 위해 스크린샷을 공유할 때는 계정 정보, 구독 주소, 토큰이 포함된 쿼리 매개변수를 가려야 합니다.

오류 예시	의미 및 우선 확인 사항
`NET::ERR_CERT_DATE_INVALID`	기기의 시간이 맞지 않거나 인증서가 아직 유효하지 않거나 이미 만료되었습니다. 먼저 시간을 확인한 다음 인증서 날짜를 살펴보세요.
`NET::ERR_CERT_AUTHORITY_INVALID`	신뢰할 수 있는 인증서 체인을 만들 수 없습니다. 발급자, 루트 인증서의 출처, 서버의 중간 인증서를 확인하세요.
`NET::ERR_CERT_COMMON_NAME_INVALID`	접속한 호스트 이름이 인증서의 적용 범위와 일치하지 않습니다. 인증서의 주체 대체 이름(SAN)을 확인하세요.
Safari의 “이 연결은 비공개가 아닙니다”	여러 상황을 아우르는 안내입니다. 세부 정보를 펼쳐 인증서와 구체적인 원인을 확인하세요. 제목만 보고 판단해서는 안 됩니다.

2. HTTPS 핸드셰이크에서 Clash 프록시의 역할

일반적인 트래픽 중계는 웹사이트 인증서를 바꾸지 않습니다

브라우저가 로컬 HTTP 프록시를 통해 HTTPS 웹사이트에 접속하는 경우를 예로 들어 보겠습니다. 브라우저가 먼저 프록시에 CONNECT example.com:443을 보내면 프록시는 사용할 수 있는 중계 터널을 만들고, 이후 브라우저와 대상 사이트가 TLS 핸드셰이크를 진행합니다. 웹사이트 인증서는 브라우저가 검증합니다. 로컬 수신 포트가 7890이라고 해서 HTTPS 콘텐츠가 평문으로 바뀌는 것은 아닙니다.

SOCKS 프록시와 TUN은 트래픽을 가져오는 방식이 다르지만, 그 자체로 HTTPS를 복호화하지는 않습니다. Clash와 Clash Meta(현 mihomo)의 일반적인 프록시 중계에는 웹페이지 복호화용 루트 인증서를 설치할 필요가 없습니다. 설정의 트래픽 스니핑도 HTTPS 본문 복호화와는 다릅니다. 확인 가능한 핸드셰이크 메타데이터를 읽는 것과 대체 인증서를 발급하는 것은 별개의 작업입니다.

프록시 노드의 TLS와 웹사이트의 TLS는 서로 다른 연결입니다

일부 노드 프로토콜은 자체적으로 TLS를 사용합니다. 이 경우 클라이언트와 노드 서버 사이에서 한 번, 브라우저와 웹사이트 사이에서 다시 한 번 핸드셰이크가 이루어집니다. 로그에 노드 측 인증서 검증 실패가 표시되면 보통 프록시 연결 실패, 시간 초과 또는 터널 오류가 발생하며, 브라우저에 웹사이트 인증서 경고가 나타나지 않을 수도 있습니다.

일부 설정에서 지원하는 skip-cert-verify는 해당 아웃바운드 연결의 인증서 검증에 적용됩니다. 웹사이트 인증서 체인을 복구하거나 브라우저가 해당 사이트를 신뢰하게 만들지는 않습니다. 웹페이지 오류를 해결하려고 true로 바꾸지 마세요. 노드 주소, 서버 인증서, TLS 서버 이름이 서비스 제공업체에서 올바르게 설정되었는지 확인해야 합니다.

3. 시스템 시간을 확인한 뒤 한 번에 한 가지씩 비교하세요

macOS 날짜 및 시간 확인

macOS Ventura 13 이상에서는 ‘시스템 설정’ → ‘일반’ → ‘날짜 및 시간’을 열어 날짜 및 시간 자동 설정이 켜져 있는지 확인하고, 현재 날짜와 연도, 시간대를 점검하세요. 이전 macOS에서는 ‘시스템 환경설정’ → ‘날짜 및 시간’에서 확인할 수 있습니다. 오래된 시스템 백업을 복원했거나 오랫동안 오프라인 상태였던 경우에는 연도가 어긋나지 않았는지 특히 확인하세요.

인증서 유효 기간은 타임스탬프를 기준으로 판단합니다. 기기 시간이 잘못되면 정상적인 웹사이트의 인증서도 아직 유효하지 않거나 이미 만료된 것으로 처리될 수 있습니다. 시간대만 바꿔서는 시스템 시계 오류가 해결되지 않는 경우가 많으므로 자동 동기화된 실제 시간을 기준으로 확인하세요. 시간을 바로잡은 뒤 브라우저를 완전히 종료했다가 다시 열고 같은 호스트 이름에 접속하세요.

같은 URL에서 다음 네 가지 결과를 기록하세요

현재 노드: 브라우저 오류, 인증서 발급자, 클라이언트 연결 목록에 표시된 규칙과 아웃바운드 정책을 기록합니다.
다른 노드: 정책 그룹에서 노드만 바꾸고 DNS, 규칙, 브라우저 설정은 동시에 변경하지 않습니다.
직접 연결: 시스템 프록시와 TUN을 잠시 끄고, 브라우저 확장 프로그램이나 별도 프록시 설정이 여전히 트래픽을 가로채는지도 확인합니다.
다른 네트워크: 가능하다면 개인 핫스팟으로 다시 접속해 현재 Wi-Fi, 라우터 또는 조직 네트워크의 영향을 구분합니다.

직접 연결 테스트에 실패했다고 해서 반드시 웹사이트 인증서에 문제가 있는 것은 아닙니다. 현재 네트워크에서 해당 웹사이트에 아예 연결할 수 없을 수도 있습니다. 구체적인 인증서 정보나 오류 코드, 또는 접속 성공 결과가 있어야 비교할 수 있습니다. 테스트 중에는 URL을 동일하게 유지하고, 리디렉션 후 다른 하위 도메인으로 이동하지 않았는지도 확인하세요.

4. 중간자 복호화와 출처가 불분명한 루트 인증서 확인

회사 네트워크의 HTTPS 검사, 디버깅용 패킷 캡처 도구, 일부 보안 소프트웨어는 브라우저와 웹사이트 사이의 TLS 연결을 중간에서 종료한 뒤 새로 발급한 인증서를 브라우저에 제공할 수 있습니다. 이런 방식은 해당 루트 인증서를 기기에서 신뢰해야 작동합니다. 루트 인증서가 제대로 배포되지 않았거나 만료되었거나, 소프트웨어를 완전히 제거하지 않은 경우 “신뢰할 수 없음” 경고가 나타날 수 있습니다.

발급자 확인: 브라우저의 경고 세부 정보나 인증서 뷰어에서 인증서 발급자를 확인하세요. 서로 관련 없는 여러 웹사이트에서 같은 낯선 조직 이름이 표시되면 살펴볼 필요가 있습니다.
인증서 저장소 확인: ‘응용 프로그램’ → ‘유틸리티’ → ‘키체인 접근’을 열고 ‘로그인’과 ‘시스템’ 키체인의 인증서를 각각 확인하세요. 시스템 루트 인증서를 일괄 삭제하지 마세요.
디버깅 도구 확인: HTTPS 패킷 캡처 도구를 설치한 적이 있다면 해당 도구의 HTTPS 복호화와 시스템 프록시 제어를 먼저 끈 뒤 다시 테스트하세요. 로컬 프록시 두 개가 서로 설정을 덮어쓰는 상황을 피할 수 있습니다.
관리 대상 기기인지 확인: 회사에서 관리하는 Mac이라면 기기 관리 설정을 통해 인증서가 배포되었을 수 있습니다. 관리자에게 인증서의 용도, 유효 기간, 배포 상태를 확인하고 조직의 신뢰 정책을 임의로 변경하지 마세요.

발급자가 바뀌었다는 사실만으로 공격이라고 단정할 수는 없습니다. 대형 웹사이트는 인증 기관을 변경할 수 있고, CDN의 서로 다른 엣지 노드가 다른 인증서를 반환하기도 합니다. 호스트 이름 적용 범위, 유효 기간, 신뢰 체인, 여러 접속 경로를 함께 살펴봐야 합니다. 개인 기기에서 ‘프록시를 고치려면’ 출처 불명의 루트 인증서를 설치하라는 안내가 갑자기 나타나면 진행을 멈추고 출처를 확인하세요.

5. 노드 문제, DNS 차이, 웹사이트 설정 오류 구분

특정 노드에서만 오류가 나면 해당 노드 사용을 중지하세요

다른 노드에서는 같은 호스트 이름에 정상적으로 접속되지만 특정 노드에서 관련 없는 도메인의 인증서가 계속 반환된다면 해당 출구 노드의 DNS, 네트워크 트래픽 변조, 서버 측 라우팅 문제일 수 있습니다. 먼저 이 노드로 민감한 사이트에 접속하지 말고, 발생 시각, 대상 호스트 이름, 오류 코드, 인증서 발급자를 서비스 제공업체에 전달하세요. 한 번의 오류만으로 노드 운영자가 트래픽을 변조했다고 단정할 수는 없습니다.

DNS가 변조되면 연결이 잘못된 서버로 향할 수 있지만, 정상적인 인증서 검증은 대개 해당 서버가 원래 웹사이트를 사칭하는 것을 막습니다. mihomo의 Fake-IP 모드는 도메인을 로컬에서 가상 주소에 매핑한 뒤 코어가 연결을 처리하는 방식이므로, 가상 주소가 보인다고 해서 DNS 오염을 의미하지는 않습니다. 연결 세부 정보에 표시된 도메인, 적용된 규칙, 실제 아웃바운드를 함께 확인하세요.

모든 경로에서 특정 사이트만 오류가 나면 사이트 인증서를 확인하세요

같은 웹사이트가 여러 노드와 직접 연결, 다른 기기에서 모두 비슷한 오류를 보인다면 사이트 인증서 만료, 도메인 적용 범위 누락, 중간 인증서 체인 설정 오류를 의심할 수 있습니다. 예를 들어 *.example.com 와일드카드 인증서는 일반적으로 www.example.com에 적용되지만, 이 규칙만으로 a.b.example.com까지 포함하지는 않으며 루트 도메인 example.com에도 자동으로 적용되지 않습니다.

서버에서 중간 인증서를 누락하면 브라우저마다 캐시나 보완 기능이 달라 결과가 다르게 나타날 수 있습니다. 따라서 “Safari에서는 열리지만 다른 브라우저에서는 열리지 않는다”는 사실만으로 서버 설정 문제를 완전히 배제할 수는 없습니다. 기기의 신뢰 설정을 바꾸기보다 인증서 체인 정보를 기록해 사이트 관리자에게 문의하는 편이 적절합니다.

공용 Wi-Fi에서만 발생하면 먼저 네트워크 인증을 완료하세요

호텔이나 공항 네트워크는 포털 로그인 절차를 요구할 수 있습니다. 포털이 HTTPS 요청을 인증 페이지로 보내려 하면 도메인 불일치 오류가 나타날 수 있습니다. 먼저 macOS의 네트워크 로그인 안내에 따라 인증을 완료하세요. 인증서 경고 페이지에는 웹사이트 비밀번호를 입력하지 마세요. 인증을 마친 뒤에도 문제가 계속되면 개인 핫스팟으로 확인하세요.

6. curl로 직접 연결과 로컬 프록시 비교하기

터미널 테스트는 브라우저 캐시나 확장 프로그램과 별개의 단서를 제공하지만, 브라우저 결과를 대체하지는 않습니다. 먼저 클라이언트 설정에서 HTTP 또는 혼합 수신 포트를 확인하세요. 아래의 127.0.0.1:7890은 테스트를 위한 예시일 뿐 모든 클라이언트에 공통으로 적용되는 값은 아닙니다. 실제 오류가 난 호스트 이름으로 예시 도메인을 바꾸되 https://는 그대로 두세요.

# curl 버전 및 TLS 백엔드 기록
curl --version

# curl의 프록시 선택 우회; TUN이 켜져 있으면 트래픽은 여전히 가로채질 수 있음
curl -Iv --connect-timeout 10 --max-time 20 --noproxy '*' https://example.com/

# 로컬 HTTP / 혼합 프록시 포트를 명시적으로 사용
curl -Iv --connect-timeout 10 --max-time 20 --noproxy '' \
  --proxy http://127.0.0.1:7890 https://example.com/

실제 직접 연결과 비교하기: --noproxy '*'를 사용하는 것 외에도 TUN을 끄고 다른 VPN이나 네트워크 확장 프로그램이 트래픽을 가로채지 않는지 확인해야 합니다. 이 옵션은 curl 자체의 프록시 선택만 우회합니다.
터널과 웹사이트 구분하기: 출력에 표시되는 200 Connection established는 일반적으로 프록시가 CONNECT 요청을 수락했다는 뜻입니다. 대상 웹사이트의 인증서 검증이 완료되었다는 의미는 아닙니다.
오류 유형 확인: curl: (60)은 보통 상대방 인증서 검증에 실패했음을 뜻하고, curl: (7)은 대개 연결 실패를 나타냅니다. 로컬 프록시가 수신 대기 중이지 않은 것인지, 웹사이트 TLS 검증에 실패한 것인지 먼저 구분하세요.
신뢰 저장소 차이 유의: macOS에 기본 포함된 curl과 다른 경로로 설치한 curl은 서로 다른 TLS 백엔드와 CA 저장소를 사용할 수 있습니다. 한쪽은 성공하고 다른 쪽은 실패한다면 버전과 신뢰 저장소를 확인하세요.

이 명령에는 연결 시간 초과 10초와 전체 제한 시간 20초가 설정되어 있어 테스트가 오래 멈춰 있는 상황을 방지합니다. 이는 성능 측정값이 아닙니다. -I는 HEAD 요청을 보내며 일부 웹사이트는 405를 반환할 수 있습니다. TLS 검증이 완료된 뒤 HTTP 메서드가 지원되지 않는 문제는 인증서 오류와 별개입니다.

7. 확인된 원인에 따라 조치하고 문제가 가려지지 않았는지 확인하세요

시간 오류: 자동 시간 설정을 복구하고 브라우저를 다시 연 다음 원래 호스트 이름의 인증서가 정상적으로 검증되는지 확인합니다.
조직 HTTPS 검사 문제: 관리자가 인증서 배포를 수정하거나 게이트웨이를 점검하도록 하세요. 채팅 첨부 파일을 통해 출처를 알 수 없는 루트 인증서를 임시로 설치하지 마세요.
특정 노드 문제: 해당 노드 사용을 중지하고 증거를 보존한 뒤 서비스 제공업체에 문의하세요. 다른 신뢰할 수 있는 경로로 다시 테스트합니다.
웹사이트 인증서 문제: 사이트에서 인증서를 갱신하거나 중간 인증서 체인을 보완하고 도메인 연결을 수정해야 합니다. 로컬 클라이언트를 다시 설치해도 대개 해결되지 않습니다.
로컬 소프트웨어 충돌: 해당 소프트웨어의 안내에 따라 HTTPS 복호화와 프록시 제어를 해제하세요. 한 번에 하나씩만 바꾸고 같은 테스트를 반복합니다.

마지막으로 필요한 규칙 모드, 시스템 프록시 또는 TUN 설정을 복원하고 대상 웹사이트와 자주 이용하는 다른 HTTPS 사이트 두 곳도 확인하세요. 주소창에서 의도치 않은 리디렉션이 없는지, 인증서가 유효한지, 클라이언트 연결 목록의 아웃바운드가 예상한 대로인지 살펴봅니다. 브라우저를 바꾼 뒤 경고가 사라졌더라도 두 브라우저의 신뢰 저장소나 확장 프로그램 설정 차이를 확인해야 합니다. 문제를 해결된 것으로 간주해서는 안 됩니다.

클라이언트 설치와 기본 설정은 빠른 시작을 참고하세요. 프록시 프로토콜, 규칙, DNS 설정을 확인하려면 프로토콜 가이드를 살펴보세요. 인증서 오류를 진단할 때는 구독을 반복해서 갱신하거나 포트를 무작위로 바꾸기보다 시간, 호스트 이름, 인증서 체인, 접속 경로를 확인하는 것이 중요합니다.