프록시 사용 후 브라우저 인증서 오류: HTTPS 인증서 오류 원인과 해결 방법

먼저 오류 코드와 문제가 발생하는 범위를 확인하세요

FlClash를 켠 뒤 “연결이 비공개로 설정되어 있지 않습니다”라는 메시지가 표시된다면 브라우저가 HTTPS 연결의 신원을 확인하는 과정에서 문제가 생긴 것입니다. 페이지를 반복해서 새로 고치기보다 오류 코드, 접속하려는 도메인, 인증서 정보를 먼저 확인하세요. 로그인·결제·이메일 페이지라면 비밀번호나 인증 코드를 입력하지 말고 오류 화면 정보를 기록해 두세요.

브라우저 오류 페이지에서 ‘고급’ 안내를 펼쳐 전체 오류 코드를 기록하세요. 인증서 보기 기능이 있다면 발급자, 유효 기간, 주체 대체 이름도 확인합니다. 브라우저마다 메뉴 위치가 다를 수 있으므로 오류 페이지에 표시된 인증서 정보를 우선 확인하세요.

자주 표시되는 오류	실패 원인	우선 확인할 항목
`NET::ERR_CERT_DATE_INVALID`	현재 시간이 인증서 유효 기간에 포함되지 않음	기기 날짜, 시간 동기화, 사이트 인증서 만료 시각
`NET::ERR_CERT_COMMON_NAME_INVALID`	인증서의 도메인과 접속한 도메인이 일치하지 않음	주소 입력 오류, 인증서 SAN, DNS, 리디렉션
`NET::ERR_CERT_AUTHORITY_INVALID`	인증서 체인을 신뢰할 수 있는 루트까지 연결할 수 없음	발급자, 사이트 인증서 체인, HTTPS 검사 소프트웨어
`SSL_ERROR_BAD_CERT_DOMAIN`	Firefox에서 도메인 불일치를 감지함	접속 호스트와 인증서 적용 범위

다음으로 문제 범위를 좁혀 보세요. 한 사이트에서만 오류가 발생하나요, 서로 관련 없는 여러 HTTPS 사이트에서 동시에 발생하나요? 특정 노드에서만 나타나나요, 프록시를 꺼도 계속되나요? 이런 차이를 확인하면 단순히 인터넷 접속 여부를 보는 것보다 원인을 더 정확히 찾을 수 있습니다. 연결 시간 초과, 연결 재설정, 인증서 오류는 서로 다른 단계에서 발생하므로 같은 방법으로 해결할 수 없습니다.

HTTPS 핸드셰이크와 프록시: 두 종류의 인증서를 구분하세요

브라우저가 HTTPS 사이트에 접속할 때는 대상 사이트 인증서의 도메인, 유효 기간, 신뢰 체인을 확인합니다. 일반 HTTP 프록시를 통해 HTTPS에 접속하면 브라우저는 보통 CONNECT로 터널을 만든 뒤 사이트와 TLS 핸드셰이크를 진행합니다. SOCKS 프록시와 TUN도 이 암호화된 트래픽을 전달할 수 있습니다. 일반적인 트래픽 전달에는 브라우저에 전용 루트 인증서를 설치할 필요가 없습니다.

노드 프로토콜 자체가 TLS를 사용한다면 ‘클라이언트와 프록시 노드 간’ 인증도 추가됩니다. 이때 mihomo 로그의 x509: certificate has expired or is not yet valid 또는 certificate signed by unknown authority는 노드 인증서 문제를 가리킬 수 있습니다. 반면 브라우저 오류 페이지에 표시되는 인증서는 일반적으로 브라우저가 접속하려는 사이트의 인증서입니다. 두 경우를 구분해 확인하세요.

브라우저에 인증서 경고가 직접 표시되는 경우: 대상 사이트 도메인, 발급자, 시스템 시간, 기기의 신뢰 저장소부터 확인하세요.
클라이언트 로그에 노드 TLS 실패가 표시되는 경우: 노드 서버 이름, 구독 설정, 노드 인증서 상태를 확인한 뒤 서비스 제공자에게 문의하세요.
프록시 연결 실패 또는 시간 초과가 표시되는 경우: 로컬 수신 포트, 노드 연결 상태, 라우팅을 먼저 확인하세요. 사이트 인증서 문제로 단정하지 마세요.

시스템 시간이 잘못된 경우: 날짜를 바로잡고 자동 동기화를 설정하세요

인증서에는 유효 시작 시각과 만료 시각이 명시되어 있습니다. 기기 날짜가 유효 기간을 벗어나면 사이트 설정이 정상이어도 연결이 실패합니다. 듀얼 부팅, 장기간 전원 차단, 메인보드 배터리 이상으로 시스템 시간이 틀어질 수 있습니다. 먼저 신뢰할 수 있는 시간과 비교해 연도, 날짜, 분을 확인하고 시간대도 점검하세요.

Windows 11: ‘설정’ → ‘시간 및 언어’ → ‘날짜 및 시간’에서 ‘시간 자동 설정’을 켜고, ‘추가 설정’에서 ‘지금 동기화’를 선택하세요.
macOS: ‘시스템 설정’ → ‘일반’ → ‘날짜 및 시간’에서 날짜와 시간 자동 설정을 확인하세요. 설정을 변경할 때 관리자 인증이 필요할 수 있습니다.
Android: 시스템 설정에서 ‘날짜 및 시간’을 검색한 뒤 자동 시간과 자동 시간대를 켜세요. 제조사별로 메뉴 위치가 다를 수 있습니다.
동기화가 끝나면 오류가 발생한 탭을 닫고 같은 도메인에 다시 접속한 다음 인증서 유효 기간을 확인하세요.

시간대는 시간 표시 방식에 영향을 주지만 인증서 유효성은 실제 시각을 기준으로 판단합니다. 시간대만 올바르게 바꾸고 시스템 시계가 여전히 틀려 있으면 문제가 계속될 수 있습니다. 시간이 정확한데 특정 사이트에서만 만료 오류가 발생한다면 사이트 운영자가 인증서를 갱신해야 합니다. 프록시 노드를 바꿔도 만료된 인증서가 다시 유효해지지는 않습니다.

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

기업 게이트웨이, 일부 보안 소프트웨어, 디버깅 프록시는 HTTPS 트래픽을 복호화해 검사할 수 있습니다. 이 경우 브라우저에는 새로 발급한 인증서를 제시하고, 대신 대상 사이트에 연결합니다. 해당 루트 인증서를 신뢰하지 않거나 인증서가 만료됐거나 소프트웨어 설정이 남아 있으면 발급 기관을 신뢰할 수 없다는 경고가 표시될 수 있습니다.

같은 도메인에서 세 가지를 비교하세요

오류가 발생한 기기와 정상적으로 접속되는 다른 기기의 인증서 발급자를 비교하세요. CDN이나 인증서 갱신에 따라 인증서가 다를 수 있지만, 회사 게이트웨이·보안 소프트웨어·디버깅 도구 이름이 보인다면 자세히 확인해야 합니다.
같은 기기에서 브라우저 두 개를 비교하세요. 브라우저마다 신뢰 저장소를 사용하는 방식이 다를 수 있습니다. 한 브라우저에서만 오류가 난다면 해당 브라우저의 인증서 설정, 확장 프로그램, 관리 정책을 우선 확인하세요.
허용되는 환경이라면 휴대폰 핫스팟으로 테스트하세요. 회사 네트워크에서만 문제가 발생한다면 네트워크 관리자에게 검사 정책과 인증서 배포 상태를 확인해 달라고 요청하세요.

Windows에서는 certmgr.msc를 실행해 현재 사용자 인증서 저장소를, certlm.msc를 실행해 로컬 컴퓨터 인증서 저장소를 확인할 수 있습니다. ‘신뢰할 수 있는 루트 인증 기관’을 중점적으로 살펴보고, 낯선 이름이라는 이유만으로 인증서를 여러 개 삭제하지 마세요. macOS에서는 ‘키체인 접근’에서 관련 인증서와 신뢰 설정을 확인할 수 있습니다. 관리 대상 기기의 인증서는 조직의 절차에 따라 처리하세요.

패킷 캡처나 디버깅 도구를 설치한 적이 있다면 도구를 종료하고 시스템 프록시가 여전히 해당 도구를 가리키는지 확인하세요. 브라우저의 확장 프로그램 프록시와 시스템 프록시가 함께 작동하면 서로 다른 경로로 연결될 수 있습니다. 한 번에 한 항목만 변경하고 매번 결과를 기록하세요. 인증서 삭제, 브라우저 초기화, 설정 변경을 동시에 하면 원인을 파악하기 어렵습니다.

도메인 불일치: DNS, 인증 포털, 트래픽 분기를 확인하세요

DNS 이상으로 도메인이 잘못된 서버를 가리킬 수 있지만, DNS 문제가 항상 인증서 경고로 나타나는 것은 아닙니다. 연결 시간 초과가 발생할 수도 있습니다. 도메인 불일치 오류가 나면 먼저 주소창에 오타가 없는지 확인하고 인증서의 주체 대체 이름(SAN)에 현재 호스트명이 포함되어 있는지 살펴보세요. 인증서가 example.com을 포함하더라도 모든 하위 도메인이 자동으로 포함되는 것은 아닙니다.

공용 네트워크에서는 먼저 로그인 인증을 완료하세요

호텔, 공항, 학교 네트워크에서는 인증 포털에 먼저 로그인해야 할 수 있습니다. 시스템의 ‘네트워크에 로그인’ 알림을 눌러 인증 페이지를 열고 네트워크가 맞는지 확인한 뒤 로그인하세요. 이후 HTTPS 접속을 테스트합니다. 은행이나 이메일 사이트의 인증서 오류 페이지에 공용 네트워크 계정 정보를 입력하지 마세요. 인증 포털과 접속하려는 사이트를 구분해야 합니다.

시스템 DNS와 프록시 DNS를 따로 확인하세요

Windows에서는 아래 명령으로 시스템의 DNS 조회 결과를 확인할 수 있습니다. 이 명령은 해당 조회 경로의 결과만 보여 주며 브라우저의 보안 DNS나 mihomo의 DNS 결과와 다를 수 있습니다.

nslookup example.com
ipconfig /flushdns

두 번째 명령은 Windows 시스템 DNS 캐시를 비웁니다. 브라우저, 상위 DNS 리졸버, mihomo 내부 캐시까지 자동으로 비우지는 않습니다. 설정에서 Fake-IP를 사용한다면 매핑된 주소가 보인다고 해서 DNS 오염이라고 단정할 수 없습니다. mihomo에서 흔히 사용하는 Fake-IP 주소 대역은 198.18.0.0/16이며, 실제 적용 대역은 현재 설정을 확인하세요.

FlClash 연결 기록에서 오류가 난 도메인을 검색해 적용된 규칙과 실제 아웃바운드 정책을 확인하세요. 규칙 모드에서는 설정에 따라 직접 연결 또는 프록시를 사용합니다. 전역 모드는 아웃바운드 선택을 바꾸지만 시스템 시간이나 신뢰 저장소 문제를 해결하지는 않습니다. 브라우저에서 보안 DNS를 켰다면 해당 상태도 기록하세요. 시스템 DNS만 바꾸고 모든 조회 경로가 바뀌었다고 판단해서는 안 됩니다.

노드와 TUN 점검: 한 번에 변수 하나만 바꾸세요

노드를 바꾼 뒤 문제가 해결됐다는 사실만으로는 해당 연결 경로와 관련이 있음을 알 수 있을 뿐입니다. 원래 노드에서 잘못된 DNS 조회, 출구 리디렉션, 연결 이상이 있었는지 추가로 확인해야 합니다. 정상적인 종단 간 HTTPS 연결에서는 브라우저가 사이트 신원을 검증해야 합니다. 낯선 인증서가 표시되면 인증서 정보를 보관하고 해당 연결 경로의 사용을 중단하세요.

현재 아웃바운드 모드, 선택한 노드, 시스템 프록시와 TUN 설정, 오류가 난 도메인 및 오류 코드를 기록하세요.
노드는 그대로 둔 채 TUN만 끄고, 확인된 시스템 프록시를 통해 브라우저에서 테스트하세요. 요청이 여전히 클라이언트를 거치는지도 확인합니다.
기존 설정으로 되돌린 뒤 노드 하나만 바꾸고 같은 도메인에 접속하세요. 오류 코드와 인증서 발급자를 비교합니다.
네트워크에서 직접 연결이 허용되고 사용 조건에도 부합한다면 시스템 프록시와 TUN을 끈 상태로 비교 테스트하세요. 브라우저 확장 프로그램이나 명령줄 환경 변수에서 프록시를 계속 지정하고 있을 수도 있으니 함께 확인해야 합니다.
클라이언트 로그의 시간대를 확인해 노드 TLS 연결 단계에서 실패했는지, 사이트 접속 단계에서 실패했는지 판단하세요.

포트를 지정해 HTTP 프록시를 테스트하세요

아래 예시는 로컬 HTTP 포트 또는 혼합 포트 7890을 사용합니다. 현재 클라이언트 설정에서 실제 포트를 확인한 뒤 명령의 포트 번호를 바꾸세요. 이 값은 예시일 뿐 모든 FlClash 설정의 기본 포트가 아닙니다. Windows에서는 이전 버전 PowerShell의 명령 별칭과 혼동하지 않도록 curl.exe를 사용하고, macOS와 Linux에서는 curl을 사용하세요.

curl.exe --noproxy "*" -Iv --connect-timeout 10 https://example.com/
curl.exe --noproxy "" -x http://127.0.0.1:7890 -Iv --connect-timeout 10 https://example.com/

첫 번째 명령은 curl에 설정된 프록시를 우회하고, 두 번째 명령은 로컬 HTTP 프록시를 명시적으로 지정합니다. 두 명령 모두 인증서 검증을 유지하며 연결 시간 제한은 10초입니다. TUN이 켜져 있으면 첫 번째 명령의 트래픽도 가로채질 수 있으므로 --noproxy만으로 완전히 직접 연결된다고 판단할 수 없습니다. SOCKS 전용 포트를 HTTP 프록시 주소에 입력해서도 안 됩니다.

curl과 브라우저는 서로 다른 인증서 처리 방식과 신뢰 저장소를 사용할 수 있습니다. 따라서 명령이 성공해도 브라우저 문제가 해결됐다고 볼 수는 없습니다. 상세 출력 내용을 공유하기 전에 프록시 인증 정보, 쿠키, 구독 주소와 기타 민감한 정보를 삭제하세요.

해결 확인: 인증서를 검증한 뒤 평소 설정으로 되돌리세요

설정을 변경한 뒤 처음 오류가 발생한 도메인과 서로 관련 없는 HTTPS 사이트 두 곳에 다시 접속하세요. 페이지가 정상적으로 열리는지, 오류 코드가 사라졌는지, 인증서의 유효 기간과 도메인이 일치하는지 확인합니다. 그런 다음 평소 사용하는 규칙 모드, 시스템 프록시 또는 TUN 설정으로 되돌리고 다시 테스트하세요.

특정 웹사이트 하나에서 계속 실패하는 경우: 도메인, 오류 코드, 인증서 유효 기간, 테스트 시간을 사이트 운영자에게 전달하세요.
특정 노드 하나에서 계속 실패하는 경우: 노드 이름, 발생 시간, 민감 정보를 가린 로그를 구독 제공자에게 전달하세요. 구독 링크는 공개하지 마세요.
회사 네트워크나 관리 대상 기기에서만 실패하는 경우: 관리자에게 루트 인증서 배포, 게이트웨이 시간, HTTPS 검사 정책을 확인해 달라고 요청하세요.
모든 네트워크에서 실패하는 경우: 기기 시간, 시스템 업데이트, 브라우저 신뢰 저장소, 로컬 보안 소프트웨어를 계속 확인하세요.

인증서 오류 해결의 목표는 경고를 숨기는 것이 아니라 검증 가능한 연결을 복구하는 것입니다. 클라이언트의 트래픽 처리 방식을 다시 확인하려면 빠른 시작 가이드를 참고하세요. 구독과 연결에 관한 기본적인 문제는 문제 해결에서 확인할 수 있습니다.