프록시 사용 중 HTTPS 인증서 오류의 원인: 노드 문제인가 기기 설정 문제인가
브라우저에 NET::ERR_CERT_AUTHORITY_INVALID 또는 "안전하지 않은 연결"이 표시되면 대부분 바로 프록시를 끄려고 합니다. 하지만 인증서 오류의 원인은 시스템 시간, 노드의 동작, 기기에 남아있는 인증서라는 서로 완전히 다른 세 계층에 걸쳐 있고, 대응 방법도 각각 다릅니다. 이 글에서는 오류 유형별로 점검 경로를 정리하고, 노드를 즉시 중단해야 하는 판단 기준을 제시합니다.
오류 유형 먼저 구분하기
HTTPS 인증서 오류는 단일 원인이 아니며, 브라우저가 보여주는 오류 코드 자체가 첫 번째 점검 실마리입니다. 프록시를 켠 후 갑자기 인증서 오류가 발생했다면 먼저 정확히 어떤 유형인지 확인한 뒤 방향을 정해야 불필요한 시도를 줄일 수 있습니다.
자주 나오는 오류 코드의 의미는 각각 다릅니다:
- NET::ERR_CERT_DATE_INVALID —— 인증서 유효기간 판단 실패. 보통 기기의 시스템 시간이나 시간대 설정 오류를 가리키며 프록시 노드 자체와는 관련이 적습니다.
- NET::ERR_CERT_AUTHORITY_INVALID —— 인증서 발급 기관을 신뢰할 수 없음. 가장 주의해야 할 유형으로, 연결이 중간에서 가로채져 재발급된 인증서일 가능성이 있습니다.
- NET::ERR_CERT_COMMON_NAME_INVALID —— 인증서의 도메인과 실제 접속 도메인이 일치하지 않음. 노드의 분기 규칙 오류로 요청이 잘못된 서버로 전달된 경우 흔히 발생합니다.
- NET::ERR_SSL_PROTOCOL_ERROR —— 전송 계층 핸드셰이크 실패. 노드 단절, 프로토콜 비호환, 또는 중간 장치가 강제로 연결을 끊은 경우일 수 있습니다.
Clash는 전송 계층에서 트래픽을 전달할 뿐, HTTPS 인증서를 임의로 복호화하거나 재발급하지 않습니다. 즉 정상적인 설정에서 노드를 통한 전달은 원래 사이트의 인증서 정보를 바꾸지 않아야 합니다. 인증서의 발급자, 유효기간, 지문 정보가 달라졌다면 문제는 노드의 비정상적인 동작이나 기기에 추가로 설치된 인증서에 있는 것이지, Clash 클라이언트의 일반적인 기능 때문이 아닙니다.
시스템 시간 오차: 가장 쉽게 놓치는 원인
HTTPS 인증서는 유효기간 구간을 가지고 있으며, 시스템은 현재 시간이 이 구간 안에 있는지 검증합니다. 시계 드리프트, 배터리 교체, 듀얼 부팅 오류 등으로 기기 시간이 실제 시간과 어긋나면, 인증서 자체가 정상이더라도 거의 모든 사이트의 인증서가 "아직 유효하지 않음" 또는 "만료됨"으로 판정됩니다.
이런 문제의 전형적인 특징은 여러 사이트에서 동시에 오류가 발생한다는 점이며, 프록시 사용 여부와 무관합니다. 다만 프록시를 켠 뒤 접속하는 사이트가 늘어나면서 프록시 때문이라고 오해하기 쉬울 뿐입니다. 확인 방법은 간단합니다:
시스템 시간과 시간대 확인
시스템 시간 설정을 열어 "자동으로 시간 설정" 또는 "네트워크 시간 동기화"가 켜져 있는지, 시간대가 실제 지역과 일치하는지 확인합니다. 가상머신이나 듀얼 부팅 환경에서는 시간이 덮어써지는 경우가 특히 많습니다.
프록시를 끄고 단독 확인
Clash를 잠시 끄고 신뢰할 수 있는 사이트 하나에만 접속해 인증서 오류가 여전히 발생하는지 확인합니다. 프록시를 꺼도 문제가 지속되면 프록시와는 무관하며 시스템 시간 문제로 확정할 수 있습니다.
재동기화 후 캐시 정리
시간을 교정한 뒤 브라우저의 HSTS 캐시와 인증서 투명성 로그 캐시를 삭제합니다(브라우저마다 경로가 다름). 이전의 잘못된 판단 결과가 캐시로 재사용되는 것을 막을 수 있습니다.
시간 오차로 인한 오류는 노드와 전혀 관계가 없으므로 노드를 바꾸거나 클라이언트를 재설치할 필요 없이 시스템 시간만 교정하면 해결됩니다.
노드의 중간자 공격: 즉시 중단해야 하는 신호
프록시를 끄면 인증서가 완전히 정상이고, 특정 노드를 켜자마자 NET::ERR_CERT_AUTHORITY_INVALID가 발생하며, 오류가 그 특정 노드에서만 나타난다면, 이 경로에 중간자(MITM) 행위가 존재할 가능성이 높습니다. 즉 어떤 중계 노드가 암호화된 트래픽을 단순히 전달하지 않고 TLS 연결을 가로채 자체 인증서로 재발급한 뒤 실제 사이트로 전달하고 있는 것입니다.
이런 동작은 정상적인 프록시 전달 과정에서는 발생하지 않아야 합니다. 이에 해당하는지 판단하려면 브라우저가 보여주는 인증서 세부 정보를 확인하세요:
- 발급 기관이 이상함 —— 정상적인 사이트의 인증서 발급 기관은 보통 Let's Encrypt, DigiCert, GlobalSign 등 공인 CA입니다. 발급 기관 이름이 낯설거나 자체 서명 표시가 보이면 경로가 가로채졌을 가능성을 강하게 의심해야 합니다.
- 유효기간이 비정상적으로 짧음 —— 일부 중간자 인증서는 실행 중 즉석에서 생성되어 유효기간이 며칠 또는 몇 시간에 불과할 수 있으며, 목표 사이트의 공식 인증서(보통 1년 이상)와 명백히 다릅니다.
- 특정 노드에서만 재현됨 —— 같은 구독의 다른 노드로 바꾸면 오류가 사라진다면, 문제는 그 특정 노드나 해당 중계 서버에 있으며 기기나 구독 전체의 문제가 아닙니다.
인증서가 교체되는 노드로 확인되면 즉시 해당 노드 사용을 중단하고, 계정 로그인, 결제, 신원 인증이 관련된 사이트에는 절대 그 노드로 접속하지 마세요. 중간자 노드는 평문 트래픽을 복호화하고 읽을 수 있으므로, 계속 사용하면 민감한 정보가 그 노드 운영자에게 노출되는 것과 같습니다. 해당 노드가 속한 구독의 출처가 신뢰할 만한지 함께 점검하고, 필요하면 구독을 교체하세요.
참고로 이런 가로채기 행위는 노드의 "유료/무료" 여부와 직접적인 관계가 없습니다. 출처가 불분명한 무료 노드의 위험이 더 높은 것은 사실이지만, 모든 무료 노드에 이 문제가 있다고 단정할 수는 없습니다. 판단 기준은 항상 인증서 세부 정보 자체이며 노드의 가격 방식이 아닙니다.
남아있는 패킷캡처 루트 인증서: 잊혀진 세 번째 가능성
또 하나 자주 놓치는 원인이 있습니다. 이전에 패킷 분석이나 트래픽 디버깅을 위해 루트 인증서를 설치한 적이 있는 경우(일부 네트워크 분석 도구는 HTTPS 트래픽을 복호화하기 위해 사용자 CA 인증서 설치를 요구함), 디버깅이 끝난 후 완전히 제거하지 않으면 이 루트 인증서가 시스템이나 브라우저의 신뢰 목록에 계속 남아 있게 됩니다.
이런 잔여 인증서 자체가 능동적으로 악용되지는 않지만, 두 가지 전형적인 문제를 일으킬 수 있습니다:
- 해당 인증서의 개인키가 부적절하게 보관되거나 유출되면 이론적으로 악용될 위험이 있으며, 브라우저는 보안 정책상 이 인증서 체인을 사용하는 연결에 경고를 표시할 수 있습니다.
- 일부 시스템 레벨 프록시 디버깅 도구가 비정상 종료되면서 설정한 시스템 프록시와 인증서 신뢰 상태를 제대로 정리하지 않아, 이후 Clash 노드를 켰을 때 두 신뢰 체계가 서로 충돌해 인증서 체인 검증 실패 오류가 나타날 수 있습니다.
점검 방법은 시스템과 브라우저의 인증서 관리 화면을 열어 잘 알려지지 않은 CA가 발급했고 설치 시점이 어떤 패킷캡처 디버깅 작업과 일치하는 인증서가 있는지 찾는 것입니다:
- Windows:
certmgr.msc를 실행해 "신뢰할 수 있는 루트 인증 기관" 목록을 확인하고, 이름이 낯설거나 설치 날짜가 의심스러운 항목을 살펴보세요. - macOS: "키체인 접근"을 열어 "시스템" 또는 "로그인" 분류에서 인증서 신뢰 설정을 확인하고, "항상 신뢰"로 표시된 시스템 기본 제공이 아닌 인증서를 찾으세요.
- 브라우저 내장 인증서 관리: Chrome, Edge 등 브라우저 설정에는 시스템 인증서 목록과 별도로 관리되는 인증서 관리 항목이 있으므로 두 곳 모두 확인해야 합니다.
불필요한 디버깅 인증서를 확인했다면 단순히 "신뢰 안 함"으로 설정하지 말고 바로 삭제하세요. 일부 시스템에서는 인증서가 존재하되 신뢰 안 함으로 표시된 상태에서도 특정 검증 단계에서 모호한 오류 메시지가 나올 수 있습니다.
점검 순서와 중단 시점
세 가지 원인은 점검 비용과 위험도가 완전히 다르므로 아래 순서대로 배제해 나가는 것을 권장합니다. 처음부터 노드를 의심하고 계속 바꾸기만 하다가 근본 원인을 놓치는 일을 피할 수 있습니다.
먼저 시스템 시간 확인
비용이 가장 낮고 1분 안에 확인 또는 배제할 수 있으며 별도 도구가 거의 필요 없습니다.
프록시를 끄고 한 번 재현
오류가 프록시 켜짐/꺼짐 상태와 관련이 있는지 확인하는 것이, "기기 환경 문제"와 "경로 문제"를 구분하는 핵심 분기점입니다.
노드를 바꿔 교차 검증
프록시를 켰을 때만 오류가 발생한다면, 같은 구독의 다른 노드로 바꿔서 문제가 특정 노드를 따라다니는지, 모든 노드에 존재하는지 확인합니다.
인증서 세부 정보와 기기 인증서 목록 확인
문제가 특정 노드를 따라다닌다면 해당 사이트 인증서의 발급 기관과 유효기간이 이상한지 확인하고, 모든 노드에서 발생한다면 기기에 남은 옛 디버깅 인증서를 확인합니다.
TUN 모드에 대해 보충하면, TUN 모드를 켜면 시스템 차원의 트래픽 처리 방식이 바뀌어 일부 보안 소프트웨어나 시스템 방화벽이 추가적인 인증서 검증 정책을 발동시킬 수 있습니다. 이는 시스템 호환성 차원의 문제이며 노드의 안전성과는 무관합니다. TUN 모드를 켰을 때만 인증서 오류가 발생하고 일반 시스템 프록시 모드에서는 정상이라면, 먼저 TUN 모드를 임시로 끈 뒤 문제 범위를 좁히고 클라이언트의 네트워크 어댑터 설정을 조정할지 판단하세요.
노드를 즉시 중단해야 하는지 판단하는 핵심 기준은 간단합니다: 프록시를 끄면 오류가 사라지고, 특정 노드에서만 재현되며, 동시에 인증서 발급 기관이나 유효기간에 뚜렷한 이상이 있는 경우 —— 이 세 조건을 모두 만족할 때가 노드를 중단해야 하는 강한 신호입니다. 단순히 시스템 시간이 맞지 않거나 남아있는 디버깅 인증서가 있는 정도로는 현재 사용 중인 노드에 보안 문제가 있다는 뜻이 아닙니다.
마지막으로 습관을 하나 권합니다. 구독을 바꾸거나 낯선 출처의 노드를 추가한 뒤에는 민감하지 않은 사이트로 먼저 인증서가 정상인지 테스트한 다음 계정이나 결제 관련 작업을 진행하면 위험을 최소한으로 줄일 수 있습니다.