프록시 사용 후 HTTPS 인증서 오류가 발생할 때: 원인과 해결 방법

오류 유형부터 확인하고 인증서 경고를 무시하지 마세요

Clash를 켠 뒤 브라우저에 “연결이 비공개로 설정되어 있지 않습니다”라는 경고가 표시되더라도, 프록시 프로그램에 인증서를 설치해야 한다는 뜻은 아닙니다. 경고 페이지에서 멈추고 접속한 전체 도메인, 오류 코드, 발생 시각을 기록하세요. 계정 로그인이나 결제를 진행하지 말고, 오류 페이지에서 안내하는 인증서 복구 도구도 다운로드하지 마세요.

일반적인 HTTP CONNECT 또는 SOCKS5 프록시는 주로 연결을 중계합니다. 브라우저와 대상 웹사이트 간에는 계속 TLS 핸드셰이크가 이루어지며, 브라우저는 웹사이트 인증서의 도메인, 유효 기간, 신뢰 체인을 확인합니다. Clash 및 Clash Meta(mihomo)의 일반적인 프록시 중계에는 브라우저가 새로운 로컬 루트 인증서를 신뢰하도록 설정할 필요가 없습니다.

“인증서 오류 무시”는 연결을 복구하는 만능 해결책이 아닙니다. 먼저 인증서를 신뢰할 수 없는 이유를 확인한 뒤 시간, 네트워크 또는 프록시 경로를 조정하세요. 검증을 끄는 설정을 평소에 사용하지 마세요.

브라우저마다 안내 문구가 다를 수 있으며 Firefox에서는 SEC_ERROR_UNKNOWN_ISSUER 같은 코드가 표시되기도 합니다. 프로토콜 오류나 연결 시간 초과는 인증서를 받지 못한 상태일 수 있으므로 모두 “인증서 만료”로 단정할 수 없습니다.

1단계: 시스템 시간을 맞추고 인증서 정보 기록하기

시간을 동기화한 뒤 페이지를 다시 여세요

1. Windows 11: 「설정」→「시간 및 언어」→「날짜 및 시간」으로 이동해 「자동으로 시간 설정」을 켜고, 시간대를 확인한 다음 「지금 동기화」를 누르세요.
2. macOS: 「시스템 설정」→「일반」→「날짜 및 시간」으로 이동해 날짜 및 시간 자동 설정을 켜고 시간대를 확인하세요.
3. Android: 일반적으로 「설정」→「시스템」→「날짜 및 시간」에서 자동 설정을 켭니다. 제조사에 따라 메뉴 이름이 「추가 설정」일 수 있습니다.
4. iPhone: 「설정」→「일반」→「날짜 및 시간」으로 이동해 「자동 설정」을 켜세요.

날짜가 몇 달씩 어긋나면 정상적인 웹사이트에서도 오류가 잇따라 발생할 수 있습니다. 시간대 표시가 다르다는 사실만으로 TLS 검증 실패를 의미하지는 않습니다. 기기의 실제 시간이 정확한지가 중요합니다. 동기화한 뒤 기존 오류 탭을 닫고 원래 도메인에 다시 접속하세요. 같은 경고 페이지를 반복해서 새로 고치지만 마세요.

인증서에서 세 가지 항목 기록하기

브라우저의 「인증서 보기」 기능을 사용해 유효 기간, 발급자, 「주체 대체 이름」(SAN)을 기록하세요. 최신 브라우저에서는 주소 표시줄 왼쪽의 사이트 정보나 경고 페이지의 고급 정보에서 확인할 수 있습니다. 인증서를 확인하려고 계속 접속을 선택하지 마세요.

• 유효 기간: 현재 날짜가 인증서의 시작 시각과 만료 시각 사이에 있는지 확인하세요.
• SAN: 주소 표시줄에 표시된 실제 호스트 이름이 포함되어 있는지 확인하세요. *.example.com 인증서는 일반적으로 루트 도메인 example.com이나 한 단계 더 깊은 a.b.example.com을 포함하지 않습니다.
• 발급자: 호텔, 회사 게이트웨이 또는 보안 소프트웨어 이름이 표시되는지 확인하세요. 이름만으로 신뢰 여부를 판단할 수 없으므로 네트워크 환경과 함께 확인해야 합니다.

시간이 정확하고 한 웹사이트에서만 인증서가 만료된 경우, 웹사이트 운영자가 인증서를 갱신해야 합니다. 노드를 바꾸면 우연히 정상적인 다른 접속 지점을 이용할 수도 있지만, 사이트 자체의 문제를 해결하는 방법은 아닙니다. 검증 수준을 낮춰 우회해서도 안 됩니다.

2단계: 공용 Wi-Fi 인증 및 기기의 HTTPS 검사 확인하기

공항, 호텔, 캠퍼스의 방문자용 Wi-Fi는 웹 인증을 먼저 완료해야 하는 경우가 많습니다. 인증 전에는 게이트웨이가 일반 HTTP 요청을 리디렉션할 수 있습니다. HTTPS 요청까지 잘못 가로채면 대상 웹사이트가 아니라 인증 게이트웨이의 인증서가 전달될 수 있습니다. 이때 프록시 노드를 무작정 바꿔도 해결되지 않는 경우가 많습니다.

1. 현재 Wi-Fi 연결은 유지한 채 시스템 프록시와 TUN을 일시적으로 끄세요. 둘 중 하나만 꺼도 나머지 기능이 트래픽을 가로챌 수 있습니다.
2. 시스템에 「네트워크에 로그인」 창이 표시되면 우선 사용하세요. 창이 나타나지 않으면 http://example.com/에 접속해 인증 페이지로 이동할 수 있습니다. 이 주소는 인증 페이지를 띄우는 용도일 뿐, 민감한 정보를 입력하는 데 사용하지 마세요.
3. 인증 페이지가 해당 장소의 네트워크 운영자가 제공한 것인지 확인한 뒤 필요한 인증을 완료하세요. 인증 페이지 자체에 인증서 경고가 표시되면 현장 담당자에게 먼저 문의하세요.
4. 프록시 없이 일반 HTTPS 웹사이트에 정상 접속되는지 확인한 뒤 기존 프록시 설정을 다시 켜고 테스트하세요.

같은 기기를 모바일 핫스팟에 연결했을 때 정상으로 돌아온다면 기존 Wi-Fi의 인증, 게이트웨이 또는 네트워크 정책을 우선 의심할 수 있습니다. 다만 이는 원인을 좁히기 위한 단서일 뿐, 확정적인 증거는 아닙니다. 기업 네트워크에서는 정책에 따라 HTTPS 검사를 적용할 수 있으므로 관리자에게 승인된 인증서 배포 방법을 확인하세요. 조직의 정책을 임의로 우회하지 마세요.

특정 컴퓨터에서만 문제가 생기면 로컬 HTTPS 검사 확인하기

보안 소프트웨어의 「암호화된 연결 검사」, 패킷 캡처 도구, 디버깅 프록시가 HTTPS를 복호화할 수 있습니다. 최근 이런 기능을 켰는지 확인하고 인증서 발급자가 해당 소프트웨어와 일치하는지 살펴보세요. 개인 기기라면 소프트웨어 공식 안내에 따라 관련 기능을 잠시 중지해 비교한 뒤 원래 상태로 되돌리세요. 관리 대상 기기는 관리자에게 문의하세요.

시스템 루트 인증서를 한꺼번에 삭제하거나 노드 제공자가 보낸 출처 불명의 루트 인증서를 설치하지 마세요. 일반적인 프록시 구독에는 노드, 정책 그룹, 규칙 등이 포함되며, 웹사이트 신뢰 인증서를 설치해야 작동하는 것은 아닙니다.

3단계: 같은 도메인에서 직접 연결과 프록시 연결 비교하기

접속 주소는 그대로 두고 조건 하나만 바꾸세요. 여기서 「직접 연결」은 시스템 프록시, TUN, 브라우저에 별도로 설정된 프록시를 끈 상태를 뜻합니다. 「프록시 연결」은 요청이 현재 클라이언트를 실제로 통과하는지 확인한 상태입니다. 사이트에 직접 연결할 수 없다면 「시간 초과」로 기록하세요. 시간 초과를 인증서가 정상이라는 뜻으로 해석하면 안 됩니다.

curl로 인증서 검증 오류와 연결 실패 구분하기

아래 예시는 클라이언트의 혼합 프록시 포트가 실제로 7890이라고 가정합니다. 먼저 클라이언트 설정에서 포트를 확인하세요. 모든 설치 환경에서 고정으로 사용하는 값은 아닙니다. Windows PowerShell에서는 curl.exe를, macOS나 Linux에서는 curl을 사용하세요.

# 명시적 프록시 환경 변수를 무시하고 직접 연결 테스트
curl --noproxy "*" -Iv --connect-timeout 10 https://example.com/

# 로컬 HTTP 혼합 프록시 포트에 직접 연결
curl --noproxy "" -x http://127.0.0.1:7890 -Iv --connect-timeout 10 https://example.com/

여기서 http://127.0.0.1:7890은 로컬 HTTP 프록시에 연결한다는 뜻이지, 대상 웹페이지를 HTTP로 바꾼다는 뜻은 아닙니다. HTTPS 대상에는 일반적으로 CONNECT 터널을 사용합니다. 이를 https://127.0.0.1:7890로 임의 변경하지 마세요. 이 주소를 사용하려면 로컬 프록시 진입점 자체가 TLS를 지원해야 합니다.

직접 연결을 테스트할 때는 TUN도 꺼야 합니다. --noproxy로는 시스템 수준의 투명 프록시를 우회할 수 없습니다. curl 종료 코드 60은 일반적으로 인증서 검증 실패, 7은 연결 실패, 28은 시간 초과를 뜻합니다. 이 결과는 이 문서에서 직접 측정한 데이터가 아닙니다. curl과 브라우저가 서로 다른 신뢰 저장소를 사용할 수 있으므로 결과가 다르면 어느 한쪽을 무조건 정답으로 택하지 말고 추가로 확인하세요.

4단계: 규칙, DNS, 실제 출구 확인하기

규칙 설정 오류가 웹사이트 인증서를 직접 바꾸는 경우는 드물지만, 연결이 잘못된 출구를 통과하거나 도메인이 현재 경로에 적합하지 않은 서버 IP로 해석될 수 있습니다. 먼저 클라이언트의 「연결」 화면에서 오류가 발생한 도메인을 필터링한 뒤 다시 접속해 적용된 규칙, 정책 그룹, 최종 노드를 기록하세요. 로그에 DNS 해석 실패나 핸드셰이크 실패가 있는지도 확인하세요.

전역 모드는 짧은 비교 테스트에만 사용하세요

규칙 모드에서 오류가 나지만 같은 노드가 전역 모드에서는 정상이라면 해당 도메인이 앞선 규칙에서 DIRECT로 매칭되거나 다른 정책 그룹에 들어가는지 확인하세요. 테스트가 끝나면 규칙 모드로 되돌리세요. 규칙은 위에서 아래 순서로 적용됩니다. 특정 도메인 하나를 위해 모든 트래픽을 같은 출구로 장기간 보내지 마세요.

아래 내용은 규칙 순서를 보여 주는 예시일 뿐, 완전한 설정이 아닙니다. 추가하기 전에 정책 그룹에 Proxy라는 이름의 그룹이 실제로 있는지 확인하고 예시 도메인을 문제가 발생한 도메인으로 바꾸세요. 구독으로 설정을 관리한다면 다음 업데이트에서 변경 사항이 사라지지 않도록 클라이언트가 지원하는 재정의 또는 병합 기능을 우선 사용하세요.

mode: rule
rules:
  - DOMAIN,example.com,Proxy
  - DOMAIN-SUFFIX,example.org,DIRECT
  - MATCH,Proxy

fake-ip 주소가 곧 인증서 위조를 뜻하지는 않습니다

mihomo의 fake-ip 모드는 도메인에 가상 주소를 할당합니다. 흔히 사용되는 주소 범위는 198.18.0.0/16이지만 설정에 따라 다를 수 있습니다. 코어는 매핑 정보를 이용해 원래 도메인으로 처리를 계속합니다. 이런 주소가 보인다고 해서 HTTPS 트래픽이 복호화되었다고 볼 수는 없습니다. 브라우저는 계속 도메인 이름으로 TLS 연결을 시작하고 해당 도메인의 인증서를 검증해야 합니다.

• 인증서를 테스트하려고 주소 표시줄의 도메인을 해석된 IP 주소로 바꾸지 마세요. 인증서 비교 조건이 달라지고 SNI 및 가상 호스트 선택에도 영향을 줄 수 있습니다.
• 기기의 hosts 파일과 설정의 hosts 항목을 확인해 문제가 발생한 도메인이 이전 서버에 고정되어 있지 않은지 살펴보세요.
• 브라우저에서 보안 DNS를 사용한다면 어떤 리졸버를 쓰는지 기록하세요. 클라이언트 DNS와 다른 경로를 사용할 수 있습니다. 영향을 이해한 경우에만 한 가지 조건을 바꿔 비교하고 테스트 후 원래대로 되돌리세요.
• DNS를 변경한 뒤에는 연결을 새로 설정해야 합니다. Windows에서는 ipconfig /flushdns로 시스템 캐시를 지울 수 있지만 브라우저와 클라이언트에 별도 캐시가 남아 있을 수 있습니다.

DNS, 노드, 규칙 모드, TUN 설정을 한 번에 모두 바꾸지 마세요. 한 번에 하나만 변경하고 같은 URL로 다시 테스트한 뒤 오류 코드와 발급자 정보가 바뀌었는지 기록해야 어떤 변경이 효과를 냈는지 파악할 수 있습니다.

브라우저 인증서와 노드 전송용 인증서 구분하기

자주 혼동하는 사례가 하나 더 있습니다. 브라우저에는 웹사이트 인증서 경고가 없는데 클라이언트 로그에 x509: certificate signed by unknown authority가 표시되는 경우입니다. 코어가 TLS 전송을 사용하는 프록시 노드에 연결할 때 발생할 수 있으며, 이는 「클라이언트와 노드 간」 인증서 문제일 수 있습니다. 「브라우저와 웹사이트 간」 인증서 문제와는 다를 수 있습니다.

노드 주소, 서버 인증서 유효 기간, 인증서 체인, 노드 제공자가 지정한 서버 이름 설정을 먼저 확인하세요. 직접 운영하는 서버라면 인증서 체인을 수정하거나 관리 가능한 방식으로 신뢰 설정을 하세요. 구독 노드는 제공자에게 확인해야 합니다. 추측으로 SNI를 바꾸거나 관련 없는 웹사이트의 도메인을 입력하지 마세요.

노드 설정의 skip-cert-verify: true는 해당 노드의 TLS 연결에서 인증서 검증을 건너뛰지만 대상 웹사이트의 인증서를 복구하지는 않습니다. 브라우저에서 검증을 무시하는 설정도 장기적인 해결책으로 적절하지 않습니다.

특정 노드에서만 문제가 반복되면 해당 노드를 먼저 비활성화하고 정상 작동이 확인된 출구로 바꾼 뒤, 발생 시각과 노드 식별 정보, 민감 정보를 가린 로그를 제공자에게 보내세요. 구독 URL, 액세스 토큰, 노드 비밀번호, 전체 설정 파일을 공개하지 마세요.

복구 확인 및 문제 기록

웹페이지가 다시 표시되는 것만으로는 충분하지 않습니다. 검증을 일시적으로 완화해 경고를 “없앤” 것은 아닌지 확인하세요. 아래 순서대로 마무리하면 다음에 네트워크를 바꿀 때 같은 문제가 재발할 가능성을 줄일 수 있습니다.

1. 일상적으로 사용하는 규칙 모드로 되돌리고 시스템 프록시와 TUN이 기존 사용 방식에 맞게 설정되어 있는지 확인하세요.
2. 오류가 발생했던 도메인을 다시 열어 인증서 경고가 나타나지 않는지, 인증서 SAN이 호스트 이름과 일치하는지, 현재 날짜가 유효 기간에 포함되는지 확인하세요.
3. 평소 자주 사용하는 HTTPS 웹사이트 두 곳도 확인해 한 페이지만 캐시 덕분에 정상 표시된 경우를 걸러내세요.
4. 임시 DNS, 규칙, 디버깅 설정을 원래대로 되돌리세요. 변경 사항을 유지해야 한다면 지원되는 재정의 설정에 반영하고 백업하세요.
5. 최종 원인을 기록하세요. 예: “시스템 연도 오류”, “Wi-Fi 미인증”, “특정 노드 출구 문제”. 단순히 “재시작하니 해결됨”이라고만 적지 마세요.

추가 지원을 요청할 때는 브라우저 이름과 버전, 운영체제 버전, 클라이언트 및 코어 버전, 문제 도메인, 오류 코드, 직접 연결과 프록시 연결의 비교 결과, 인증서 발급자를 제공하세요. 스크린샷을 공유하기 전에 계정, 개인 도메인, 구독 정보를 가리세요. 정확한 자료가 반복해서 구독을 가져오는 것보다 원인을 찾는 데 도움이 됩니다.

문제 해결 순서는 다음과 같이 정리할 수 있습니다. 먼저 시간과 오류 유형을 확인하고, Wi-Fi 인증과 기기의 HTTPS 검사를 배제한 다음, 출구를 비교하고 마지막으로 규칙과 DNS를 확인하세요. 알 수 없는 발급자가 표시되거나 민감한 사이트에서 문제가 발생하면 페이지를 억지로 여는 것보다 정보 제출을 중단하는 것이 중요합니다.