프록시 사용 중 HTTPS 인증서 오류가 발생하는 이유
프록시 사용 중 발생하는 인증서 오류의 원인을 살펴봅니다. 프록시 문제와 시스템 시간 오류, 네트워크 가로채기를 구분하고 상황별 해결 방법을 안내합니다.
HTTPS 인증서 오류: 먼저 오류가 발생한 계층부터 확인하세요
Clash 클라이언트를 켠 뒤 “연결이 비공개로 설정되어 있지 않습니다”라는 메시지가 나타나더라도, 이는 브라우저가 현재 연결의 신원을 확인하지 못했다는 뜻일 뿐 프록시 노드가 웹페이지를 변조했다는 증거는 아닙니다. 시스템 시간이 잘못되었거나 웹사이트 인증서가 만료된 경우, 공용 Wi-Fi 로그인 페이지, 기업 네트워크의 HTTPS 검사, DNS가 도메인을 잘못된 서버로 연결한 경우에도 비슷한 경고가 표시될 수 있습니다.
HTTPS는 일반적으로 대상 서버의 443 포트에 연결합니다. TLS 핸드셰이크 과정에서 브라우저는 인증서의 유효 기간과 인증서 체인, 요청한 도메인과의 일치 여부를 확인합니다. 프록시는 트래픽이 이동하는 경로를 바꾸지만, 브라우저의 신원 확인 절차는 그대로 필요합니다. 문제를 해결하려면 먼저 검증을 끄는 대신 전체 오류 코드와 주소창의 도메인, 인증서 발급자 및 유효 기간을 기록하세요.
| 메시지 또는 오류 코드 | 주요 의미 | 먼저 확인할 항목 |
|---|---|---|
NET::ERR_CERT_DATE_INVALID | 인증서가 만료되었거나 아직 유효하지 않거나 기기 시간이 잘못됨 | 시스템 날짜와 시간, 시간 동기화, 인증서 유효 시작일 및 만료일 |
NET::ERR_CERT_COMMON_NAME_INVALID | 인증서에 현재 접속한 도메인이 포함되어 있지 않음 | 인증서 SAN, 실제 접속 도메인, DNS가 연결한 주소 |
NET::ERR_CERT_AUTHORITY_INVALID | 신뢰할 수 있는 루트 인증서까지 인증서 체인을 연결할 수 없음 | 발급자, 기업 HTTPS 검사 소프트웨어, 웹사이트 인증서 체인 |
ERR_SSL_PROTOCOL_ERROR | TLS 협상 실패. 반드시 인증서 검증 실패인 것은 아님 | 대상 포트, 서비스 프로토콜, 중간 네트워크 장비 |
ERR_PROXY_CONNECTION_FAILED | 브라우저가 프록시 서버에 연결하지 못함 | 로컬 프록시 포트, 커널 프로세스, 시스템 프록시 설정 |
Clash 클라이언트는 HTTPS 트래픽을 어떻게 전달할까요?
일반적인 프록시 전달에는 웹사이트 인증서를 바꿀 필요가 없습니다
브라우저가 로컬 HTTP 프록시를 통해 HTTPS에 접속할 때는 보통 먼저 CONNECT 대상 도메인:443을 전송한 다음, 생성된 터널을 통해 대상 웹사이트와 TLS 핸드셰이크를 진행합니다. SOCKS 프록시와 TUN 모드도 암호화된 연결을 전달할 수 있습니다. 정상적으로 트래픽을 전달하는 경우 브라우저에 표시되는 인증서는 대상 웹사이트의 인증서이지, ‘Clash 인증서’가 아닙니다.
Clash 클라이언트의 규칙에 따라 연결이 직접 연결될지 프록시를 거칠지, 어떤 정책 그룹을 사용할지가 결정됩니다. 도메인 스니핑을 켜더라도 읽을 수 있는 핸드셰이크 정보를 확인하는 것과 HTTPS 본문을 복호화하는 것은 다릅니다. TUN, Fake-IP 또는 스니핑이 활성화되어 있다는 이유만으로 브라우저의 인증서가 바뀌었다고 판단할 수는 없습니다.
대상 웹사이트 인증서와 프록시 노드 인증서를 구분하세요
일부 프록시 프로토콜은 자체적으로 TLS를 사용합니다. 이때는 서로 다른 두 계층에서 인증서를 검증합니다. 커널은 프록시 노드의 TLS 인증서를 확인하고, 브라우저는 대상 웹사이트의 HTTPS 인증서를 확인합니다. 커널 로그에 프록시 서버 연결 중 x509: certificate has expired or is not yet valid 오류가 표시된다면 노드 측 문제일 수 있습니다. 브라우저에서 대상 웹사이트의 인증서를 확인할 수 있고 도메인 불일치 오류가 나온다면 웹사이트 연결 계층을 점검해야 합니다.
mihomo 설정에서 일부 TLS 노드는 skip-cert-verify를 지원합니다. 이 필드는 해당 노드의 인증서 검증에만 적용되며, 대상 웹사이트에 대한 브라우저의 검증을 끄지 않습니다. 값을 true로 바꿔도 웹페이지 인증서 오류를 확실하게 해결할 수 없으며, 노드 신원 확인만 약화됩니다. 설정 제공자에게 노드 인증서와 서버 이름 또는 연결 주소를 수정해 달라고 요청하세요.
1차 점검: 시간, 도메인, 인증서 상세 정보
- 오류 정보를 저장하세요. 전체 URL과 오류 코드를 기록하세요. 브라우저의 사이트 정보나 인증서 뷰어에서 발급자와 유효 기간, ‘주체 대체 이름’(SAN)을 확인하세요. 메뉴 위치는 브라우저 버전에 따라 다를 수 있으므로 인증서 상세 정보 창을 기준으로 확인하세요.
- 기기 시간을 바로잡으세요. Windows 11에서는 ‘설정’ → ‘시간 및 언어’ → ‘날짜 및 시간’으로 이동해 자동으로 시간 설정을 켠 다음 ‘지금 동기화’를 선택하세요. macOS에서는 ‘시스템 설정’ → ‘일반’ → ‘날짜 및 시간’에서 날짜 및 시간 자동 설정을 확인하세요.
- 실제 도메인을 확인하세요. 주소 철자가 틀리지 않았는지, 오래된 북마크에서 새 하위 도메인으로 이동한 것은 아닌지 확인하세요. 인증서 SAN의
*.example.com은 일반적으로www.example.com을 포함하지만a.b.example.com은 포함하지 않습니다. 루트 도메인인example.com도 자동으로 포함되는 것은 아닙니다. - 인증서 유효 기간을 비교하세요. 예를 들어 기기 날짜가 2025년이고 인증서 유효 기간이 2026년에 시작된다면 아직 유효하지 않은 것으로 판단됩니다. 기기 날짜가 2030년으로 잘못 설정된 경우에도 유효한 인증서를 만료된 것으로 판단할 수 있습니다. 이해를 돕기 위한 예시이며 현재 웹사이트의 인증서 정보는 아닙니다.
시간대는 주로 현지 시간 표시 방식에 영향을 줍니다. 시간대 표시만 다르고 기기의 실제 시각이 정확하다면 일반적으로 인증서 검증 실패의 원인이 되지 않습니다. 시간대 이름을 거주 지역에 맞게 바꾸는 것만으로는 부족하며 실제 날짜와 시간을 바로잡아야 합니다.
특정 웹사이트에서만 오류가 발생하는 경우
같은 네트워크의 다른 HTTPS 웹사이트는 정상이고 직접 연결과 프록시 연결에서 동일한 만료 인증서가 보인다면, 먼저 웹사이트 측 인증서 갱신이나 인증서 체인 설정 문제를 의심하세요. 노드를 여러 개 바꿔도 이미 만료된 인증서가 다시 유효해지지는 않습니다. 오류 내용을 기록해 웹사이트 운영자에게 전달하고 서버 측 수정이 이루어질 때까지 기다리세요.
2차 점검: 비교 테스트로 프록시 경로를 파악하세요
테스트할 때는 한 번에 조건 하나만 바꾸고 동일한 URL과 브라우저를 사용해 비슷한 시간대에 확인하세요. 먼저 사용 중인 규칙 모드와 정책 그룹, 노드를 기록한 뒤 아래 항목을 비교하세요. 경로에 따라 서로 다른 CDN 엣지 서버에 연결될 수 있으므로 인증서가 다르다는 사실만으로는 가로채기의 증거가 되지 않습니다. 도메인 포함 범위와 인증서 체인도 함께 확인해야 합니다.
| 비교 결과 | 가능성이 있는 원인 | 다음 단계 |
|---|---|---|
| 직접 연결과 프록시 연결에서 같은 오류가 발생함 | 기기 시간, 신뢰 저장소, 웹사이트 설정 또는 공통으로 거치는 네트워크 장비 | 다른 기기나 네트워크에서 인증서 발급자를 다시 확인하세요 |
| 특정 노드에서만 문제가 발생함 | 해당 노드의 출구, 연결 경로 또는 CDN 경로 | 다른 노드로 바꾼 뒤 인증서 SAN과 대상 주소를 비교하세요 |
| 회사 또는 학교 네트워크에서만 문제가 발생함 | 인증 게이트웨이, HTTPS 검사 또는 네트워크 접근 정책 | 로그인 요건을 확인하고 네트워크 관리자에게 문의하세요 |
| 특정 브라우저에서만 문제가 발생함 | 브라우저 프록시 설정, 별도 신뢰 저장소 또는 확장 프로그램의 영향 | 브라우저 설정과 관리 정책을 확인하세요 |
시스템 프록시를 꺼도 반드시 직접 연결되는 것은 아닙니다
TUN 모드가 계속 켜져 있으면 가상 네트워크 어댑터가 트래픽을 계속 처리할 수 있습니다. 브라우저 확장 프로그램이 별도의 프록시를 설정했을 수도 있습니다. 직접 연결과 비교하기 전에 Clash 클라이언트의 시스템 프록시와 TUN을 끄고 브라우저에 별도 프록시가 설정되어 있지 않은지 확인하세요. 테스트가 끝나면 원래 설정으로 복원하세요. 조직에서 관리하는 기기라면 네트워크 규정을 따르고 강제 정책을 임의로 우회하지 마세요.
Clash 클라이언트의 연결 목록에서 대상 도메인에 해당하는 연결을 찾아 일치한 규칙과 최종 정책을 확인하세요. 화면에서 특정 노드를 선택했다고 해서 모든 요청이 해당 노드를 거치는 것은 아닙니다. 규칙에 따라 대상이 DIRECT 또는 다른 정책 그룹에 할당될 수 있습니다. 규칙 적용 방법은 고급 설정에서 자세히 확인할 수 있습니다.
curl로 로컬 프록시 연결 비교하기
아래 명령은 example.com을 예시로 사용하며 로컬 HTTP 또는 혼합 포트가 7890이라고 가정합니다. 실제 포트는 Clash 클라이언트의 현재 설정을 확인하세요. Windows에서는 curl.exe를, macOS 또는 Linux에서는 curl을 사용합니다.
# 프록시 환경 변수를 명시적으로 무시하고 직접 연결 경로 비교
curl --noproxy "*" -Iv https://example.com/
# 로컬 HTTP 프록시를 명시적으로 사용
curl --proxy http://127.0.0.1:7890 -Iv https://example.com/TUN이 계속 실행 중이면 첫 번째 명령도 TUN이 트래픽을 처리할 수 있으므로 앞서 안내한 대로 먼저 비활성화하세요. -I는 응답 헤더를 요청하고 -v는 연결 및 핸드셰이크 정보를 출력합니다. 이번에 확인할 인증서 검증을 건너뛰게 되는 -k 또는 --insecure는 추가하지 마세요. curl과 브라우저는 서로 다른 TLS 구현과 신뢰 저장소를 사용할 수 있으므로 결과는 비교 참고 자료일 뿐 브라우저 검증을 대신할 수 없습니다.
DNS, Fake-IP, 네트워크 로그인 페이지가 인증서에 미치는 영향
잘못된 대상 주소가 다른 인증서를 반환할 수 있습니다
DNS가 도메인을 잘못된 서버로 연결하더라도 브라우저는 원래 도메인을 기준으로 인증서를 확인합니다. 예를 들어 www.example.com에 접속했는데 네트워크 로그인 포털에만 적용되는 인증서가 반환되면 도메인 불일치 오류가 발생할 수 있습니다. 서로 다른 여러 웹사이트에서 낯선 발급자나 포털 도메인이 동일하게 표시된다면 공용 Wi-Fi 인증 절차와 라우터 설정, 로컬 HTTPS 검사 소프트웨어를 먼저 확인하세요.
Fake-IP는 도메인과 연결을 매핑하는 방식이지 HTTPS 인증서를 위조하는 기능이 아닙니다. mihomo 설정 예시에서는 Fake-IP 범위로 198.18.0.1/16을 사용하는 경우가 많지만 실제 범위는 설정에 따라 다릅니다. 해당 범위로 주소가 확인되었다고 해서 자동으로 DNS 오염을 의미하지는 않습니다. DNS 강화 모드와 TUN 처리 상태, 도메인 매핑이 정상인지 함께 확인하세요.
- DNS 강화 모드를 바꾸거나 TUN을 끈 뒤에도 이전 DNS 캐시에 매핑 주소가 잠시 남아 있을 수 있습니다. 새 설정이 적용되었는지 먼저 확인한 다음 캐시를 새로 고치고 브라우저를 다시 시작하세요.
- Windows에서는
ipconfig /flushdns를 실행해 시스템 DNS 캐시를 비울 수 있습니다. 브라우저에 별도 캐시가 있을 수 있으며 캐시를 비워도 만료된 인증서가 복구되지는 않습니다. - 브라우저의 보안 DNS 설정은 도메인 확인 경로를 바꿀 수 있습니다. 먼저 현재 설정을 기록한 뒤 클라이언트의 DNS 구성에 맞춰 일관되게 테스트하세요. 노드와 DNS 서버를 동시에 바꾸지 마세요.
공용 Wi-Fi에서는 먼저 정상적으로 인증하세요
호텔, 공항, 학교 네트워크에서는 먼저 로그인 포털을 이용해야 할 수 있습니다. 운영체제에서 표시되는 네트워크 로그인 창이나 네트워크 운영자가 안내한 인증 페이지를 우선 사용하세요. HTTPS 페이지가 리디렉션되면서 인증서 경고가 표시되면 해당 페이지에 계정 비밀번호를 입력하지 마세요. 신뢰할 수 있는 경로에서 인증을 마친 다음 프록시를 다시 켜고 웹사이트에 접속하세요.
기업 루트 인증서, 웹사이트 인증서 체인, 보안 경계
기업 게이트웨이와 보안 소프트웨어, 디버깅 도구가 HTTPS 검사를 수행할 수 있습니다. 기기와 게이트웨이 사이에 TLS 연결을 설정한 뒤 게이트웨이가 웹사이트에 연결하는 방식입니다. 이 경우 브라우저에는 조직의 루트 인증서가 서명한 웹사이트 인증서가 표시될 수 있습니다. 조직에서 관리하는 기기에서는 명시적으로 설정된 네트워크 정책일 수 있지만, 개인 기기에서 낯선 발급자가 갑자기 나타나면 출처를 꼼꼼히 확인해야 합니다.
- 관리 주체를 확인하세요. 조직 관리자에게 HTTPS 검사가 배포되었는지 문의하고 루트 인증서의 출처와 기기 관리 기록을 확인하세요. 포럼 첨부 파일이나 출처가 불분명한 메시지로 인증서를 받지 마세요.
- 네트워크를 비교하세요. 허용되는 경우 신뢰할 수 있는 개인 네트워크로 전환해 보세요. 특정 네트워크에서만 낯선 발급자가 나타난다면 해당 네트워크의 게이트웨이를 중점적으로 확인하세요. 모든 네트워크에서 나타난다면 기기에 설치된 소프트웨어와 신뢰 설정을 확인하세요.
- 웹사이트 인증서 체인을 확인하세요. 웹사이트에 중간 인증서가 누락되면 일부 브라우저는 캐시를 이용해 정상 접속하지만 다른 기기에서는 실패할 수 있습니다. 방문자에게 최종 인증서를 신뢰하도록 요구하지 말고 웹사이트 운영자가 서버의 인증서 체인을 올바르게 구성해야 합니다.
- 지원되는 환경으로 복구하세요. 필요한 보안 수정 사항과 신뢰 저장소 업데이트를 받도록 운영체제와 브라우저를 업데이트하세요. 조직에서 관리하는 기기의 업데이트와 인증서 변경은 관리 정책에 따라 관리자가 진행해야 합니다.
연결을 복구하기 전 확인 목록
- 시간 정확성: 시스템 시간을 동기화했으며 인증서가 현재 유효 기간 내에 있습니다.
- 도메인 일치: 주소창의 도메인이 인증서 SAN에 포함되어 있으며 오류를 무시하고 접속하지 않습니다.
- 연결 경로 확인: 시스템 프록시, TUN, 브라우저별 프록시, 실제 적용된 규칙 상태를 확인했습니다.
- 신뢰할 수 있는 발급자: 낯선 인증서의 출처를 확인했고 조직 인증서는 공식 관리 경로를 통해 검증했습니다.
- 변경 사항 복구 가능: 기존 설정을 보존했으며 인증서 검증을 건너뛰어 문제를 감추지 않았습니다.
도움을 요청할 때는 오류 코드와 운영체제 및 브라우저 버전, Clash 클라이언트와 커널 버전, TUN 사용 여부, 직접 연결과 프록시 연결의 비교 결과를 함께 제공하세요. 인증서 화면에는 도메인과 발급자, 유효 기간이 보이도록 하세요. 로그에서 구독 URL과 노드 비밀번호, 액세스 토큰, 개인 URL은 숨기세요. 기본 연결 문제 해결은 문제 해결에서도 확인할 수 있습니다.
점검 순서는 다음과 같습니다. 먼저 오류가 발생한 계층을 파악하고 시간과 인증서 신원을 확인한 뒤 연결 경로를 비교합니다. 마지막으로 DNS와 게이트웨이 또는 웹사이트 설정을 점검하세요. 목표는 경고 화면을 없애는 것이 아니라 신뢰할 수 있는 HTTPS 연결을 복구하는 것입니다.