프록시 인증서 오류 해결
시스템 시간, HTTPS 중간자 검사, 노드 상태, 브라우저 캐시를 점검하고 프록시와 인증서 오류의 관계 및 단계별 해결 순서를 안내합니다.
먼저 인증서 오류가 발생한 계층을 확인하세요
프록시를 켠 뒤 인증서 경고가 나타났다고 해서 Clash에 루트 인증서를 설치해야 하는 것은 아닙니다. 일반적인 HTTP CONNECT, SOCKS, TUN 전달은 트래픽 경로만 바꾸므로 브라우저는 여전히 대상 사이트와 TLS 핸드셰이크를 수행하고 사이트 인증서를 검증해야 합니다. 먼저 오류 코드, 인증서의 도메인과 발급자를 확인한 다음 시스템 시간과 실제 외부 연결 경로를 점검하세요. 클라이언트를 바로 재설치하는 것보다 효과적입니다.
서로 다른 두 암호화 연결을 구분해야 합니다. 하나는 브라우저와 대상 사이트 간 HTTPS 연결이고, 다른 하나는 프록시 엔진과 노드 서버 간 TLS 연결일 수 있습니다. 브라우저에 표시되는 NET::ERR_CERT_AUTHORITY_INVALID와 엔진 로그의 x509: certificate signed by unknown authority는 같은 문제로 단정해 처리할 수 없습니다.
| 발생 위치 | 우선 확인할 항목 | 다음 단계 |
|---|---|---|
| 브라우저 개인정보 보호 경고 페이지 | 대상 사이트 인증서, 시스템 신뢰 체인, HTTPS 검사 | 오류 코드를 기록하고 인증서 세부 정보 열기 |
| 클라이언트의 노드 연결 로그 | 노드 인증서, SNI, 인증서 유효기간 | 실패한 노드와 구독 설정 확인 |
| 구독 업데이트 중 | 구독 도메인 인증서와 업데이트 요청 경로 | 구독 서버 문제인지 로컬 네트워크 문제인지 확인 |
| 연결 시간 초과 또는 연결 재설정 | 라우팅, 포트, 노드 연결 가능 여부 | 먼저 연결 문제로 다루고 인증서 문제라고 단정하지 않기 |
NET::ERR_CERT의 전체 오류 코드 기록
‘연결이 비공개로 설정되어 있지 않습니다’는 안내 제목일 뿐이며, 구체적인 원인을 찾으려면 뒤에 표시되는 오류 코드가 중요합니다. Chrome과 Edge의 코드는 비슷하고 Firefox는 명칭이 다르지만 점검 방향은 대체로 같습니다. 브라우저 버전, 시스템 신뢰 저장소, 조직 정책에 따라서도 안내 내용이 달라질 수 있습니다.
NET::ERR_CERT_DATE_INVALID: 기기의 시간이 잘못되었거나 인증서가 만료됐거나 아직 유효하지 않습니다. 먼저 기기의 날짜와 인증서 유효기간을 비교하세요. 화면 오른쪽 아래의 시각만 확인해서는 충분하지 않습니다.NET::ERR_CERT_AUTHORITY_INVALID: 신뢰할 수 있는 인증서 발급 체인을 확인하지 못했습니다. 자체 서명 인증서, 누락된 중간 인증서, 기기의 신뢰 저장소 문제 또는 HTTPS 검사 도구가 원인일 수 있습니다.NET::ERR_CERT_COMMON_NAME_INVALID: 접속한 도메인이 인증서의 주체 대체 이름(SAN)에 포함되어 있지 않습니다. 과거 오류명에 Common Name이 들어가더라도 최신 브라우저가 CN 필드만 확인한다는 뜻은 아닙니다.NET::ERR_CERT_REVOKED: 인증서가 폐기된 것으로 확인되었습니다. 사이트 운영자나 관련 관리자가 인증서를 교체해야 합니다. 브라우저의 검증 기준을 낮춰 해결하려고 해서는 안 됩니다.
인증서 세부 정보에서 최소 네 가지를 기록하세요
경고 페이지의 인증서 메뉴나 브라우저 주소창의 사이트 정보 패널에서 접속 도메인, SAN, 발급자, 유효기간을 확인하세요. 메뉴 위치는 버전에 따라 다를 수 있습니다. 세부 정보를 열 수 없다면 오류 코드와 접속 시각을 기록해 두세요. 서로 관련 없는 여러 사이트의 인증서가 갑자기 동일한 낯선 조직에서 발급됐다면, 여러 사이트가 동시에 잘못된 인증서를 교체했다고 보기보다 중간자 검사를 먼저 의심하세요.
반대로 발급자가 같다는 사실만으로 문제를 단정할 수는 없습니다. 많은 사이트가 동일한 공인 CA를 사용합니다. 인증서 체인, 접속 도메인, 네트워크 환경, HTTPS 검사 소프트웨어 설치 여부를 함께 확인해야 합니다.
1단계: 시간을 맞추고 비교 테스트하기
먼저 시스템 시간을 동기화하세요
Windows 11에서는 ‘설정’ → ‘시간 및 언어’ → ‘날짜 및 시간’으로 이동해 ‘자동으로 시간 설정’을 확인한 뒤 ‘지금 동기화’를 누르세요. macOS에서는 ‘시스템 설정’ → ‘일반’ → ‘날짜 및 시간’에서 자동 설정을 확인할 수 있습니다. 연·월·일, 시간대, 동기화 성공 여부를 확인하세요. 표시되는 시간대만 다른 지역으로 바꿔도 시스템 시계의 오차는 해결되지 않습니다.
절전 모드에서 복귀하거나, 듀얼 부팅을 전환하거나, 가상 머신의 시간이 어긋나면 인증서가 ‘아직 유효하지 않음’으로 표시될 수 있습니다. 시간을 바로잡은 뒤 연결을 다시 설정해 테스트하세요. 특정 사이트 하나에서만 만료 오류가 계속되고 다른 HTTPS 사이트는 정상이라면 전역 설정을 더 바꾸지 말고 해당 사이트의 인증서를 확인하세요.
같은 URL로 네 가지 테스트를 진행하세요
- 전체 URL, 오류 발생 시각, 현재 클라이언트의 모드가 규칙 모드인지 전역 모드인지 기록하세요.
- URL은 그대로 둔 채 시스템 프록시를 끄고 다시 테스트하세요. TUN도 켜져 있다면 확실히 끈 뒤 확인해야 합니다.
- 기존 프록시 경로를 다시 켜고 노드 하나만 바꾼 다음 인증서 오류도 노드를 따라 바뀌는지 확인하세요.
- 가능하다면 휴대전화 핫스팟이나 다른 기기에서도 같은 URL을 테스트해 기기 문제와 네트워크 문제를 구분하세요.
한 번에 변수 하나만 바꾸세요. 시스템 프록시를 꺼도 브라우저 확장 프로그램이 프록시를 지정할 수 있고, TUN을 꺼도 시스템 프록시가 계속 작동할 수 있습니다. 실제로 ‘직접 연결’ 상태인지 판단하려면 스위치만 보지 말고 클라이언트의 연결 기록도 확인해야 합니다. 직접 연결이 되지 않는다는 사실은 비교 결과를 얻지 못했다는 뜻일 뿐, 프록시 경로가 안전하거나 문제가 있다는 증거는 아닙니다.
2단계: 중간자 검사와 인증이 필요한 네트워크 확인하기
백신 프로그램의 ‘HTTPS 검사’, 패킷 캡처 도구, 기업 게이트웨이, 일부 디버깅 프록시는 브라우저의 TLS 연결을 먼저 종료한 다음 대상 도메인용 로컬 인증서를 발급할 수 있습니다. 브라우저가 해당 루트 인증서를 신뢰하지 않으면 경고가 표시됩니다. 이미 신뢰하는 경우에도 의도한 관리 정책인지 확인해야 합니다.
- 개인 기기: 최근 패킷 캡처 도구를 켰거나 네트워크 보안 소프트웨어를 설치했거나 인증서를 가져왔는지 확인하세요. 해당 소프트웨어 설정에서 원래 HTTPS 검사 상태로 되돌리세요. 시스템 루트 인증서를 일괄 삭제하지 마세요.
- 회사 또는 학교 기기: 발급자 이름과 조직 안내를 대조한 뒤 관리자에게 루트 인증서 배포 및 프록시 정책을 확인하세요. 관리 대상 인증서를 임의로 삭제하거나 조직의 접근 제어를 우회하지 마세요.
- 호텔, 공항, 방문객용 Wi-Fi: 먼저 시스템에 표시되는 네트워크 로그인 페이지에서 인증을 완료하세요. 인증 게이트웨이가 HTTPS를 잘못 가로채면 도메인이 일치하지 않는 인증서를 반환할 수 있습니다. 가로채기된 HTTPS 경고 페이지에는 계정 정보를 입력하지 마세요.
3단계: 노드, DNS, 실제 규칙 확인하기
규칙을 바꾸기 전에 연결 기록부터 확인하세요
규칙 모드에서는 규칙의 순서에 따라 정책 그룹이 선택되며, 정책 그룹 이름이 최종 노드를 뜻하지는 않습니다. 클라이언트의 연결 기록이나 로그에서 대상 도메인을 찾아 적용된 규칙, 정책 체인, 최종 외부 연결 노드를 확인하세요. 메뉴 이름은 클라이언트마다 다르지만 보통 ‘연결’ 또는 ‘로그’에서 찾을 수 있습니다. 정책 그룹 이름만 보인다면 그룹에서 현재 선택된 항목도 확인해야 합니다.
DNS 조회 오류로 요청이 잘못된 서버로 연결되면 해당 서버가 도메인과 일치하지 않는 인증서를 반환할 수 있습니다. 다만 DNS 문제는 조회 실패나 시간 초과로 나타나는 경우도 흔합니다. fake-ip 사용 시 198.18.0.0/16 범위의 매핑 주소가 보여도 DNS가 오염됐다는 뜻은 아닙니다. mihomo는 매핑된 주소에서 도메인을 복원해 계속 전달할 수 있습니다.
특정 노드에서만 오류가 발생하고 다른 노드는 정상이라면 두 경로에서 실제로 받은 인증서를 비교하세요. 외부 연결 네트워크의 간섭, CDN 엣지 설정, 대상 사이트의 지역별 서비스 차이가 영향을 줄 수 있습니다. ‘노드를 바꾸니 해결됐다’는 것은 원인을 좁히는 단서이지 노드가 트래픽을 가로챘다는 충분한 증거는 아닙니다. DNS 변경, 전역 모드 전환, TUN 활성화, 규칙 수정까지 한꺼번에 하면 재현이 어려워지므로 피하세요.
엔진 로그의 x509 오류는 노드 설정을 확인하세요
웹페이지에 연결할 수 없고 클라이언트가 노드 서버에 대해 x509 오류를 기록했다면 노드의 TLS 계층을 확인해야 합니다. 인증서 도메인, 연결 주소, SNI가 서로 다를 수 있습니다. 예를 들어 IP 주소로 노드에 연결하더라도 서버 이름 검증에는 서비스 제공자가 지정한 도메인을 사용할 수 있습니다. 서비스 제공자가 안내한 유효한 설정을 대조하고, 인기 있는 도메인을 임의로 입력하지 마세요.
mihomo 노드의 TLS 옵션에 skip-cert-verify가 있을 수 있습니다. 이를 true로 설정하면 해당 노드의 인증서 검증을 건너뜁니다. 브라우저가 받은 대상 사이트 인증서 문제는 해결하지 못하며 노드 신원 확인도 약화합니다. 일반적으로는 인증서 체인, 서버 이름 또는 서버 인증서를 바로잡아야 합니다. 이 옵션을 모든 문제에 적용하는 범용 스위치로 취급하지 마세요.
4단계: curl로 터널 문제와 인증서 문제 구분하기
명령줄 테스트는 브라우저 안내를 보완할 수 있지만, 실제로 사용 중인 수신 포트를 먼저 확인해야 합니다. 아래 예시는 로컬 HTTP 또는 mixed 포트 7890을 사용합니다. 예시 포트가 모든 클라이언트의 기본값은 아닙니다. 대상은 https://example.com/이며, 실제 문제를 재현할 때는 토큰이 포함되지 않은 대상 URL로 바꾸세요.
# 명시적 프록시를 사용하지 않음. TUN이 켜져 있으면 트래픽이 계속 가로채질 수 있음
curl -Iv --noproxy "*" https://example.com/
# 로컬 HTTP 프록시를 통해 CONNECT 터널을 명시적으로 생성
curl -Iv --noproxy "" --proxy http://127.0.0.1:7890 https://example.com/Windows PowerShell에서는 환경에 따라 curl이 다른 명령으로 해석될 수 있으므로 명령에서 curl.exe를 사용하는 것이 좋습니다. -I는 응답 헤더를 요청하고 -v는 연결 진단 정보를 출력합니다. 일부 사이트에서 HEAD 메서드를 지원하지 않으면 -I를 빼고 응답 본문을 로컬 빈 장치로 리디렉션하세요.
| 출력 단서 | 설명 |
|---|---|
200 Connection established | HTTP 프록시가 CONNECT를 수락했다는 사실만으로 이후 웹사이트의 인증서 검증까지 성공한 것은 아닙니다. |
curl: (60) | 상대방 인증서 검증에 실패했습니다. 발급 체인, 도메인, 유효기간에서 구체적인 원인을 확인하세요. |
curl: (7) | 연결에 실패했습니다. 수신 포트와 서비스 상태를 확인하세요. 인증서 문제라고 바로 단정할 수 없습니다. |
| 대상에서 HTTP 403 또는 405 응답 반환 | 응답이 대상 사이트에서 왔는지 프록시에서 왔는지 확인하세요. TLS 검증 성공 후 대상 사이트가 보낸 응답이라면 접근 정책이나 요청 메서드를 점검해야 합니다. |
‘문제가 해결됐다’고 말하려고 -k 또는 --insecure를 추가하지 마세요. 이 옵션들은 인증서 검증을 건너뛰어 테스트 조건만 바꿉니다. 또한 curl과 브라우저는 서로 다른 TLS 백엔드, 신뢰 저장소, DNS 경로를 사용할 수 있습니다. 한쪽은 성공하고 다른 쪽은 실패한다면 결과 하나만 믿지 말고 차이를 계속 확인하세요.
마지막으로 브라우저 상태와 사이트 인증서 체인을 확인하세요
캐시는 인증서 오류의 우선적인 원인이 아닙니다. 모든 인터넷 사용 기록을 지워도 만료된 인증서, 잘못된 도메인, 신뢰할 수 없는 발급자 문제는 보통 해결되지 않습니다. 먼저 관련 탭을 닫고 브라우저를 완전히 종료한 뒤 다시 시도하세요. 그래도 문제가 계속되면 임시 새 프로필이나 다른 브라우저로 비교해 보세요.
- 특정 브라우저에서만 실패: 브라우저 업데이트, 확장 프로그램 프록시, 조직 정책, 인증서 신뢰 설정을 확인하세요. 시크릿 창에서도 시스템 프록시, 조직 정책, 허용된 확장 프로그램의 영향을 받을 수 있으므로 완전히 격리된 환경으로 볼 수 없습니다.
- 오래된 기기에서만 실패: 운영체제 지원 여부와 신뢰 저장소 업데이트를 확인하세요. 포럼에서 루트 인증서 패치를 임의로 다운로드하지 말고 운영체제와 브라우저의 공식 업데이트 경로를 우선 사용하세요.
- 여러 기기와 네트워크에서 같은 사이트에 오류 발생: 사이트 인증서 만료, 중간 인증서 누락, CDN 특정 엣지 노드의 잘못된 배포 가능성이 커집니다. 도메인, 발생 시각, 인증서 정보를 기록해 사이트 운영자에게 전달하세요.
- 상태를 지운 뒤 잠시 해결됐다가 재발: 연결 재사용, DNS 결과, 실제 노드 변경 여부를 계속 확인하세요. 단순히 시간상 먼저 일어났다는 이유만으로 캐시가 문제를 해결했다고 단정하지 마세요.
HSTS가 적용된 사이트는 HTTPS 접속을 요구하므로 브라우저에서 계속 진행하는 버튼을 제공하지 않을 수 있습니다. 이는 보안 정책이 작동하는 것이므로 오류를 우회하려고 HSTS 상태를 삭제하지 마세요. 올바른 해결 기준은 인증서 검증을 정상적으로 켠 상태에서 브라우저가 연결을 완료하고, 인증서가 대상 도메인을 포함하며 유효기간과 발급 체인이 정상인 것입니다.
점검 결과에 따른 후속 조치
- 시간을 맞춘 뒤 모든 사이트가 정상화됨: 시간 동기화 서비스, 절전 모드 복귀 또는 듀얼 부팅 전환 문제를 확인하고 인증서 검증 설정은 그대로 유지하세요.
- 관리 대상 네트워크에서만 동일한 발급자가 표시됨: 관리자에게 HTTPS 검사 설정을 확인하세요. 출처를 알 수 없는 루트 인증서를 직접 가져오지 마세요.
- 특정 노드에서만 오류 발생: 노드 식별 정보와 민감 정보를 가린 로그를 보관하고, 검증이 정상인 경로로 전환한 뒤 서비스 제공자에게 문의하세요.
- 구독 업데이트에서만 오류 발생: 구독 도메인과 인증서를 확인하고 업데이트 요청이 프록시를 통과하는지 점검하세요. 비공개 구독 링크를 공개 진단 사이트에 붙여 넣지 마세요.
- 모든 경로에서 특정 사이트 하나만 실패: 인증서 유효기간, SAN, 재현 시각을 사이트 운영자에게 전달하고 인증서 배포가 수정될 때까지 기다리세요.
운영자에게 전달하면 도움이 되는 정보는 운영체제 버전, 브라우저 버전, 클라이언트와 엔진 버전, 전체 오류 코드, 발생 시각, 영향을 받은 도메인, 노드나 네트워크를 바꿨을 때의 비교 결과입니다. 클라이언트 버전과 엔진 버전은 따로 기록하세요. 인터페이스가 비슷하더라도 인증서를 처리하는 경로가 완전히 같지는 않습니다. 추가 사용 방법은 사용 가이드에서, 일반적인 연결 문제는 자주 묻는 질문에서 확인하세요.
정리: 먼저 오류가 브라우저, 노드 TLS, 구독 요청 중 어느 계층에서 발생했는지 확인한 다음 시간, 인증서 발급자, 실제 외부 연결 경로, 로컬 기기 상태를 차례로 점검하세요. 인증서 검증을 통과해야 문제가 해결된 것입니다. 경고를 무시하거나 검증을 끄는 것은 해결책이 아닙니다.