프록시 사용 후 HTTPS 인증서 오류가 뜨나요? 원인과 해결 방법

인증서 오류와 프록시 연결 실패 구분하기

HTTPS 인증서 경고가 표시되면 비밀번호나 결제 정보를 입력하지 말고, 시스템 시간과 인증서 발급자, 실제 연결 경로부터 확인하세요. ‘계속 방문’을 해결 방법으로 여기지 마세요. 일반적인 프록시 전달에는 브라우저가 새 루트 인증서를 신뢰할 필요가 없습니다. 구독을 가져오는 것만으로 웹사이트가 제공하는 인증서를 설치해야 하는 것도 아닙니다.

ClashX 또는 mihomo 코어를 사용하는 클라이언트는 일반적으로 트래픽을 전달합니다. 브라우저가 HTTP CONNECT 터널, SOCKS 또는 TUN 경로로 HTTPS 사이트에 접속하더라도 웹사이트 인증서는 브라우저가 검증합니다. TUN이 네트워크 트래픽을 처리한다고 해서 HTTPS가 복호화되는 것은 아닙니다. mihomo의 트래픽 스니핑 기능도 웹사이트 인증서를 다시 발급하는 기능이 아닙니다.

일반적인 메시지	우선 확인할 항목	단정할 수 없는 내용
`NET::ERR_CERT_DATE_INVALID`	기기의 시간, 인증서 유효 시작·종료 시각	노드 문제라고 단정할 수 없음
`NET::ERR_CERT_AUTHORITY_INVALID`	발급자, 루트 인증서 신뢰 여부, 인증서 체인	출처 불명의 인증서를 설치해야 한다는 뜻이 아님
`NET::ERR_CERT_COMMON_NAME_INVALID`	주소와 인증서 SAN, DNS, 리디렉션	DNS 캐시 문제만은 아닐 수 있음
`ERR_PROXY_CONNECTION_FAILED`	프록시 수신 포트, 클라이언트 실행 여부	웹사이트 인증서 검증 오류가 아님
`ERR_SSL_PROTOCOL_ERROR`	TLS 핸드셰이크, 잘못된 서버 포트, 중간 장비	루트 인증서 누락과 같은 의미가 아님

브라우저마다 오류 이름이 다를 수 있습니다. 오류 코드와 접속 도메인, 발생 시각, 인증서 발급자를 먼저 기록한 뒤 한 번에 한 가지 조건만 바꿔 확인하세요. 도메인만 기록하면 충분합니다. 로그인 토큰이 포함된 전체 주소를 공개하지 마세요.

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

시스템 시간이 틀리면 정상적인 웹사이트에서도 인증서가 만료되었거나 아직 유효하지 않다는 경고가 표시될 수 있습니다. 가상 머신 스냅샷을 복원했거나, 기기를 오랫동안 꺼 두었거나, 멀티 부팅 운영체제를 전환했다면 먼저 확인하세요. 시간대 표시가 다르다고 반드시 인증서 검증에 영향을 주는 것은 아닙니다. 시스템에 기록된 실제 시간이 맞는지가 중요합니다.

Windows 11: ‘설정’ → ‘시간 및 언어’ → ‘날짜 및 시간’에서 ‘자동으로 시간 설정’을 켜고, ‘추가 설정’에서 ‘지금 동기화’를 실행합니다.
macOS: ‘시스템 설정’ → ‘일반’ → ‘날짜 및 시간’에서 날짜 및 시간 자동 설정을 켭니다. 구버전에서는 메뉴 이름이 다를 수 있습니다.
브라우저를 다시 열고 오류 페이지의 인증서 세부정보에서 ‘유효 시작’과 ‘만료’ 시각을 확인하세요. 시스템 시간이 올바른데 특정 웹사이트에서만 인증서가 만료되었다면 웹사이트 관리자가 인증서를 갱신해야 합니다.

터미널에서 아래 명령으로 UTC 시간을 확인한 뒤 신뢰할 수 있는 다른 기기와 비교할 수 있습니다. 이 명령은 시간을 읽기만 하며 시스템 설정을 변경하지 않습니다.

# macOS / Linux
date -u

# Windows PowerShell
(Get-Date).ToUniversalTime().ToString("o")

2단계: 직접 연결과 프록시 연결을 비교해 범위 확인

‘시스템 프록시 끄기’가 반드시 직접 연결을 뜻하지는 않습니다. TUN이 계속 연결을 처리할 수 있고, 브라우저 확장 프로그램이 별도로 프록시를 설정했을 수도 있습니다. 기업 네트워크가 기기 외부에서 트래픽을 검사하는 경우도 있습니다. 먼저 현재 모드와 선택한 노드, 설정 파일을 기록한 뒤 동일한 조건으로 비교하세요.

같은 도메인으로 세 가지 조건 비교

직접 연결: 클라이언트의 시스템 프록시와 TUN을 끄고 브라우저 프록시 확장 프로그램도 잠시 비활성화합니다. 직접 연결이 허용되고 대상에 접속할 수 있는 네트워크에서 같은 HTTPS 도메인에 접속하세요.
노드 A: 기존 설정을 복원하고 원래 노드를 선택한 뒤 인증서 발급자와 오류 코드를 기록합니다.
노드 B: 노드만 바꾸고 브라우저, 대상 도메인 및 나머지 설정은 그대로 둔 채 다시 테스트합니다.

직접 연결이 되지 않는다고 해서 시간 초과를 ‘인증서가 정상’이라는 뜻으로 해석하면 안 됩니다. 휴대전화 핫스팟처럼 신뢰할 수 있는 다른 네트워크에서 추가로 비교해 보세요. DNS와 노드, 브라우저, 규칙을 한꺼번에 바꾸면 어떤 변경이 결과에 영향을 주었는지 알 수 없습니다.

curl로 HTTP CONNECT 경로 확인하기

아래 예시는 클라이언트가 실제로 수신하는 혼합 포트가 7890인 경우입니다. 현재 적용 중인 설정에서 mixed-port 값을 확인하세요. 포트가 7890이 아니면 명령도 해당 포트에 맞게 바꿔야 합니다. Windows에서는 일부 PowerShell 환경의 동명 별칭과 혼동하지 않도록 curl.exe를 사용하는 것이 좋습니다.

# macOS / Linux: 환경 변수에 설정된 HTTP/SOCKS 프록시 제외
# TUN이 꺼져 있고 다른 투명 프록시가 없을 때만 직접 연결 비교에 사용
curl -Iv --connect-timeout 10 --max-time 20 --noproxy '*' https://example.com/

# 로컬 HTTP 프록시를 명시적으로 사용하고 no_proxy 우회 목록 비우기
curl -Iv --connect-timeout 10 --max-time 20 --noproxy "" \
  --proxy http://127.0.0.1:7890 https://example.com/

# Windows PowerShell: 로컬 HTTP 프록시를 명시적으로 사용
curl.exe -Iv --connect-timeout 10 --max-time 20 --noproxy "" --proxy http://127.0.0.1:7890 https://example.com/

200 Connection established는 프록시가 CONNECT 요청을 수락했다는 뜻일 뿐, 이후 TLS 검증까지 성공했다는 의미는 아닙니다. 인증서 검증 결과와 최종 응답도 확인하세요. 예시 도메인은 명령어 설명을 위한 것이므로 실제 오류가 발생한 도메인으로 바꾸면 됩니다. 비공개 경로를 덧붙일 필요는 없습니다.

curl과 브라우저는 TLS 백엔드와 신뢰 저장소가 다를 수 있습니다. 따라서 ‘curl은 성공하고 브라우저는 실패한다’는 결과는 원인을 좁히는 단서이지 최종 판정이 아닙니다. 명령줄에 -k 또는 --insecure를 추가하지 마세요. 지금 확인하려는 인증서 검증을 건너뛰게 됩니다.

3단계: MITM, 패킷 캡처 도구, 남아 있는 루트 인증서 확인

MITM은 중간자 가로채기를 뜻합니다. 명시적으로 허가된 디버깅 환경이나 기업 환경에서는 패킷 캡처 도구가 기존 TLS 연결을 종료한 뒤 로컬 루트 인증서로 웹사이트 인증서를 발급할 수 있습니다. 프록시 설정이 남아 있는데 루트 인증서는 제거되었거나, 애플리케이션이 해당 인증서 저장소를 신뢰하지 않으면 인증서 오류가 발생합니다.

발급자를 먼저 확인하고 설정 출처 조사하기

브라우저 오류 페이지나 사이트 정보 패널에서 인증서 세부정보를 열어 발급자와 유효기간, ‘주체 대체 이름’(SAN)을 확인하세요. SAN에는 현재 접속 중인 도메인이 포함되어야 합니다.
서로 관련 없는 여러 웹사이트에서 동일한 낯선 조직명이나 로컬 도구 이름이 발급자로 표시되면 패킷 캡처 도구, HTTPS 검사 기능, 브라우저 확장 프로그램, 기기 관리 정책을 확인하세요.
Windows에서는 ‘설정’ → ‘네트워크 및 인터넷’ → ‘프록시’에서 수동 프록시와 설정 스크립트를 확인하세요. macOS에서는 ‘시스템 설정’ → ‘네트워크’ → 현재 네트워크 → ‘세부사항’ → ‘프록시’에서 남아 있는 설정을 확인할 수 있습니다.
HTTP_PROXY, HTTPS_PROXY, ALL_PROXY, NO_PROXY 환경 변수도 확인하세요. 브라우저와 터미널이 서로 다른 프록시 설정을 사용할 수 있습니다.

인증서를 삭제하기 전에 용도 확인

macOS에서는 ‘키체인 접근’에서 ‘로그인’ 키체인과 ‘시스템’ 키체인을 각각 확인할 수 있습니다. Windows의 certmgr.msc는 현재 사용자 인증서를, certlm.msc는 로컬 컴퓨터 인증서를 표시합니다. 후자를 수정하려면 보통 관리자 권한이 필요합니다. ‘신뢰할 수 있는 루트 인증 기관’을 확인할 때는 먼저 인증서 이름과 용도, 배포 경로를 확인하세요.

개인 기기에서 예전 패킷 캡처 도구가 설치한 인증서임을 확인했다면, 먼저 도구의 HTTPS 가로채기를 끄고 프록시 설정을 되돌린 다음 해당 도구의 제거 안내에 따라 인증서를 삭제하세요. 시스템 루트 인증서를 한꺼번에 삭제하지 마세요. 조직에서 관리하는 기기는 내부 서비스에 문제를 일으키거나 네트워크 관리 정책을 위반하지 않도록 관리자에게 맡기세요.

4단계: 비정상 노드, DNS, 잘못 연결된 사이트 점검

특정 노드에서만 인증서 도메인 불일치가 발생하고 다른 노드로 바꾸자마자 해결된다면 해당 노드를 격리하고 DNS 조회 경로를 확인하세요. 다만 한 번의 오류만으로 노드가 트래픽을 가로챈다고 단정할 수는 없습니다. 출구 네트워크 인근의 로그인 포털, 상위 DNS, 잘못된 리버스 프록시 설정 때문에 요청이 다른 서버로 연결될 수도 있습니다.

DNS 오염이 인증서 경고를 일으키는 이유

도메인이 잘못된 서버로 연결되더라도 브라우저는 주소창의 원래 도메인을 기준으로 인증서를 검증합니다. 잘못 연결된 서버가 다른 도메인의 인증서를 반환하면 이름 불일치 오류가 발생합니다. 공격자가 DNS만 바꿔 대상 도메인의 유효한 인증서를 얻기는 어렵습니다. 따라서 인증서 경고는 반드시 유지해야 할 보안 경계입니다.

먼저 주소창의 도메인 철자가 맞는지 확인한 뒤 기기의 hosts 파일, 브라우저 보안 DNS, 라우터 DNS, 클라이언트 DNS 설정을 점검하세요. mihomo의 fake-ip 모드는 198.18.0.0/16 범위의 매핑 주소를 반환할 수 있으며, 이 주소 대역 자체가 DNS 오염의 증거는 아닙니다. 일반적인 nslookup은 브라우저 보안 DNS나 클라이언트가 실제 사용하는 DNS 조회 경로를 거치지 않을 수도 있습니다.

클라이언트의 ‘연결’ 또는 ‘로그’ 페이지에서 대상 도메인으로 필터링해 적용된 규칙과 정책 그룹, 최종 노드를 확인하세요. 메뉴 위치는 클라이언트 인터페이스에 따라 다를 수 있습니다.
대상 트래픽을 DIRECT로 보내는 더 우선순위가 높은 DOMAIN, DOMAIN-SUFFIX 또는 규칙 모음이 있는지 확인하세요. 규칙은 대체로 순서대로 적용되므로 정책 그룹을 바꿔도 이미 일치한 직접 연결 규칙이 적용된 요청은 달라지지 않을 수 있습니다.
문제를 덮기 위해 전역 모드를 상시 사용하지 마세요. 비교를 위해 잠시 사용할 수는 있지만, 테스트를 마치면 원래 모드로 되돌리고 규칙을 수정해야 합니다.
공용 Wi-Fi에서는 먼저 운영체제가 제공하는 네트워크 로그인 절차를 완료하세요. HTTPS 페이지에 포털 인증서가 표시되면 신뢰할 수 있는 네트워크에서 확인하세요. 포털에 예외를 허용해 대상 웹사이트의 인증서 경고를 무시하지 마세요.

DNS 설정을 바로잡은 뒤에만 캐시 삭제를 고려하세요. Windows에서는 ipconfig /flushdns를 실행할 수 있으며, macOS에서는 아래 명령을 실행하면 됩니다. 브라우저와 클라이언트가 별도 캐시를 유지할 수도 있으므로 필요하면 완전히 종료한 뒤 다시 시작하세요.

# macOS: 시스템 DNS 캐시 새로고침, 관리자 권한 필요
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

같은 노드에서 계속 인증서 불일치가 발생하지만 다른 신뢰할 수 있는 노드와 직접 연결에서는 정상이라면 해당 노드 사용을 중단하고 민감 정보를 제거한 증거를 서비스 제공자에게 전달하세요. 도메인과 발생 시각, 발급자, 오류 코드를 포함하면 됩니다. 구독 주소와 노드 비밀번호, 전체 설정 파일은 보내지 마세요.

5단계: 웹사이트 인증서 체인과 클라이언트 신뢰 저장소 문제 구분

시스템 시간이 맞고 연결 경로가 안정적이라면 인증서 체인 누락이나 신뢰 저장소 차이가 흔한 원인입니다. 웹사이트 서버가 중간 인증서를 빠뜨리면 일부 브라우저는 캐시로 보완하지만 다른 기기나 명령줄 도구에서는 검증에 실패할 수 있습니다. 한 컴퓨터에서 접속된다는 이유만으로 서버 설정이 올바르다고 볼 수는 없습니다.

OpenSSL로 인증서 체인과 도메인 검증 확인

해당 옵션을 지원하는 OpenSSL 환경에서는 아래 명령을 실행할 수 있습니다. -servername은 SNI를 지정해 공유 IP 서버가 해당 사이트를 선택하도록 합니다. -verify_hostname은 도메인 검사를 명시적으로 활성화합니다. 일반적인 s_client를 실행해 연결 성공 메시지를 확인하는 것만으로는 인증서가 완전히 검증되었다고 볼 수 없습니다.

# 직접 연결 확인: 테스트 중 TUN이나 다른 투명 프록시가 없는지 확인
openssl s_client -connect example.com:443 \
  -servername example.com -showcerts \
  -verify_hostname example.com -verify_return_error < /dev/null

# 로컬 HTTP CONNECT 프록시 사용; -proxy를 지원하는 OpenSSL 필요
openssl s_client -proxy 127.0.0.1:7890 \
  -connect example.com:443 -servername example.com \
  -showcerts -verify_hostname example.com \
  -verify_return_error < /dev/null

출력에서 검증 오류와 인증서 체인, Verify return code를 확인하세요. OpenSSL의 신뢰 저장소는 macOS 키체인, Windows 인증서 저장소 또는 브라우저와 다를 수 있습니다. ‘로컬 발급자 인증서를 가져올 수 없음’ 오류가 나면 로컬 CA 설정과 서버의 중간 인증서 누락을 모두 고려해야 합니다. 곧바로 노드 문제라고 단정하지 마세요.

한 웹사이트에서만, 여러 기기와 네트워크에서 동일하게 실패: 만료된 인증서와 SAN, 완전한 인증서 체인을 확인하도록 웹사이트 관리자에게 문의하세요.
오래된 기기 한 대에서만 실패: 지원되는 운영체제와 브라우저로 업데이트한 다음 루트 인증서 업데이트 상태를 확인하세요. 출처를 알 수 없는 인증서 묶음을 포럼에서 내려받지 마세요.
애플리케이션 하나에서만 실패: 해당 앱이 별도의 CA 파일이나 인증서 고정 방식을 사용하는지 확인하세요. 인증서 고정 오류를 검증 비활성화로 해결하지 마세요.
인증서 폐기 관련 오류 발생: 구체적인 오류와 네트워크 조건을 기록하고 폐기 확인 서비스에 접속할 수 있는지 확인한 뒤 관리자나 웹사이트 담당자에게 문의하세요. 인증서 폐기 검사를 영구적으로 끄지 마세요.

수정 후 확인과 보안 기준

수정이 끝나면 다른 웹사이트만 열어 보는 대신 처음 오류가 난 도메인으로 다시 확인하세요. 브라우저와 실제로 사용해야 하는 앱, 클라이언트 로그의 규칙 및 노드를 차례로 점검합니다. 원래 규칙 모드로 되돌리고 클라이언트를 다시 시작한 뒤에도 문제가 재발하지 않아야 설정이 안정적이라고 볼 수 있습니다.

시스템 날짜와 시간이 정확하고 인증서 유효기간이 현재 시각을 포함합니다.
인증서 SAN이 대상 도메인과 일치하고, 인증서 체인이 기기에서 신뢰하는 루트 인증서까지 이어집니다.
시스템 프록시와 TUN, 브라우저 확장 프로그램, 환경 변수의 용도가 명확하며 남아 있는 디버깅 프록시가 없습니다.
인증서 오류를 무시하는 브라우저 실행 옵션을 사용하지 않았고 명령줄에서 TLS 검증을 건너뛰지 않았습니다.
원래 노드나 대체 노드로 다시 테스트해 문제 범위와 해결 조치가 일치하는지 확인합니다.

경고 페이지에서 계속 진행해 민감 정보를 입력했다면 신뢰할 수 있는 네트워크에서 해당 비밀번호를 변경하고 의심스러운 세션을 취소한 뒤 계정 로그인 기록을 확인하세요. 인증서 경고만으로 정보가 유출되었다고 단정할 수는 없지만, 의심스러운 연결을 통해 민감한 작업을 계속해서는 안 됩니다.