프록시 사용 후 HTTPS 인증서 오류가 발생하는 이유와 해결 방법

오류 코드를 먼저 기록하고 인증서 검증을 건너뛰지 마세요

Clash를 켠 뒤 “연결이 비공개로 설정되어 있지 않습니다”라는 메시지가 나타나더라도, 이는 현재 연결 경로에서 브라우저가 서버 신원을 확인하지 못했다는 뜻일 뿐 노드가 작동하지 않는다는 의미는 아닙니다. HTTPS 검증에는 접속 도메인, 인증서 유효 기간, 인증서 체인, 기기의 신뢰 저장소가 모두 필요합니다. 프록시로 연결 경로가 바뀌면 이 중 어느 항목에서든 문제가 드러날 수 있습니다.

주소창의 전체 호스트명, 브라우저 오류 코드, 시스템 시간, 인증서 뷰어의 ‘발급자’, ‘유효 기간’, Subject Alternative Name(SAN, 주체 대체 이름)을 먼저 기록하세요. 보통 호스트명만으로도 충분합니다. 스크린샷을 공유할 때는 주소에 포함된 로그인 토큰, 이메일 주소와 기타 개인정보를 가리세요.

인증서 검증을 끄거나 출처를 알 수 없는 루트 인증서를 설치하거나 ‘계속 방문’을 누르는 방식으로 해결하려 하지 마세요. 은행, 결제, 이메일, 계정 로그인 페이지에서 인증서 경고가 나타나면 비밀번호를 입력하지 말고 신뢰할 수 있는 네트워크에서 연결을 확인하세요.

Clash, mihomo와 HTTPS 인증서의 관계

일반적인 Clash 또는 mihomo 설정은 연결을 전달하는 역할을 합니다. 브라우저가 HTTP 프록시의 CONNECT 터널, SOCKS5 또는 TUN 라우팅을 통해 웹사이트에 연결해도 웹사이트 HTTPS의 TLS 핸드셰이크는 보통 브라우저와 웹사이트 사이에서 이루어집니다. 시스템 프록시를 켰다고 해서 웹페이지를 복호화하는 루트 인증서를 시스템에 설치할 필요는 없습니다.

서로 다른 두 TLS 연결을 구분해야 합니다. 노드 설정의 tls, servername, skip-cert-verify는 ‘코어와 프록시 노드 사이’의 연결을 제어할 수 있습니다. 반면 브라우저의 인증서 경고는 대개 ‘브라우저와 웹사이트 사이’의 연결에 관한 문제입니다. 노드의 skip-cert-verify를 수정해도 웹사이트 인증서는 복구되지 않으며, 노드 신원 검증의 신뢰성만 낮아집니다.

증상에 따라 다른 곳부터 확인하세요

• 브라우저에 인증서 경고가 표시됨: 웹페이지 인증서의 도메인, 발급자, 유효 기간을 확인하세요.
• 클라이언트 로그에 x509가 표시되고 브라우저에서 프록시 연결 실패가 발생함: 노드 도메인과 노드 인증서, 코어 실행 환경의 시간과 신뢰 저장소를 확인하세요.
• TUN을 켠 뒤에만 문제가 발생함: 실제로 적용된 규칙, DNS 경로, 다른 VPN을 확인하세요. TUN 자체가 웹사이트에 새 인증서를 발급하지는 않습니다.

브라우저 보안 DNS, 확장 프로그램 프록시, 시스템 프록시, TUN이 동시에 작동할 수 있습니다. 진단할 때는 먼저 연결 방식을 하나로 고정하세요. ‘시스템 프록시’를 꺼도 TUN이 트래픽을 처리할 수 있으므로, 이를 직결 상태로 잘못 판단하지 않도록 주의해야 합니다.

시스템 시간 오류와 인증서 유효 기간

인증서에는 유효 시작 시각과 만료 시각이 있습니다. 기기 시간이 시작 시각보다 이르거나 만료 시각보다 늦으면 검증에 실패합니다. 듀얼 부팅, 가상 머신 스냅샷 복원, 메인보드 배터리 방전, 시간 동기화 서비스 오류로 여러 정상 웹사이트에서 동시에 문제가 발생할 수 있습니다.

먼저 실제 시각을 확인하고 시간대 표시를 살펴보세요

• Windows 11: ‘설정’ → ‘시간 및 언어’ → ‘날짜 및 시간’으로 이동해 ‘자동으로 시간 설정’을 확인한 뒤 ‘지금 동기화’를 누르세요. 회사 관리 기기의 시간 기준은 조직 정책으로 제어될 수 있습니다.
• macOS: ‘시스템 설정’ → ‘일반’ → ‘날짜 및 시간’에서 날짜와 시간 자동 설정 및 시간대를 확인하세요.
• Ubuntu: 다음 명령으로 현재 시각, 시간대, 동기화 상태를 확인하세요.

date -Is
timedatectl status

System clock synchronized 항목을 확인하세요. systemd가 시간을 관리하고 다른 시간 서비스나 조직 정책의 제한을 받지 않는 시스템이라면 아래 명령으로 네트워크 시간 동기화를 켠 다음 상태를 다시 확인할 수 있습니다.

sudo timedatectl set-ntp true
timedatectl status

시간대가 다르다고 해서 시스템의 절대 시각이 틀린 것은 아닙니다. 웹사이트 지역에 맞추려고 시간대를 바꿀 필요는 없습니다. 시간이 정확한데 특정 도메인의 인증서만 만료됐다면 보통 웹사이트 운영자가 인증서를 갱신해야 합니다. 기기 날짜를 바꾸면 문제를 가릴 뿐 아니라 다른 사이트에도 영향을 줍니다.

패킷 캡처 도구, HTTPS 검사, 기기의 신뢰 저장소

Fiddler, Charles, mitmproxy 등의 도구에서 HTTPS 복호화를 켜면 접속하는 웹사이트용 인증서를 동적으로 발급합니다. 일부 보안 소프트웨어와 기업 게이트웨이도 비슷한 검사를 수행할 수 있습니다. 이 경우 브라우저에 표시되는 발급자가 웹사이트의 원래 공인 인증 기관이 아니라 도구명이나 조직명으로 바뀔 수 있습니다.

인증서를 바로 가져오지 말고 발급자를 확인하세요

1. 오류 페이지에서 인증서 상세 정보의 발급자와 인증서 체인을 확인하세요. 메뉴 경로는 브라우저 버전에 따라 다를 수 있습니다.
2. 패킷 캡처 프로그램이 실행 중인지, HTTPS 복호화가 켜져 있는지, 시스템 프록시가 여전히 해당 프로그램을 가리키는지 확인하세요.
3. 개인 테스트를 마치면 도구의 HTTPS 복호화를 끄고 안내에 따라 프록시 설정을 복원하세요. 해당 도구에서 설치한 것으로 확인되고 더 이상 필요하지 않은 테스트용 루트 인증서만 제거하세요.
4. 발급자가 회사나 학교에 속한다면 관리자에게 기기 관리와 신뢰 인증서 배포 여부를 확인하세요. 조직 인증서를 임의로 삭제하거나 정책을 우회하지 마세요.

모든 앱이 같은 인증서 신뢰 방식을 사용하는 것은 아닙니다. Firefox, 시스템 브라우저, 명령줄 curl, 컨테이너 안의 프로그램은 서로 다른 인증서 저장소, 버전, 조직 정책의 영향을 받을 수 있습니다. ‘브라우저에서는 되지만 curl에서는 안 됨’이라면 노드를 계속 바꾸기보다 각 프로그램의 신뢰 기준을 비교하세요.

Ubuntu에서 공인 CA 인증서 묶음이 오래된 경우, 신뢰할 수 있는 소프트웨어 저장소를 통해 ca-certificates를 업데이트할 수 있습니다. 아래 작업은 시스템의 신뢰 인증서를 갱신할 뿐, 웹사이트 도메인 오류를 자동으로 고치거나 출처를 알 수 없는 사설 인증서를 신뢰하게 만들지는 않습니다.

sudo apt update
sudo apt install --only-upgrade ca-certificates
sudo update-ca-certificates

직결, 고정 노드, 인증서 정보를 비교하세요

같은 기기와 URL을 사용하고 가능한 한 비슷한 시간대에 비교 테스트를 진행하세요. 한 번에 하나의 조건만 바꾸고, 먼저 패킷 캡처 도구와 다른 VPN을 잠시 끈 다음 TUN, 시스템 프록시, 브라우저 확장 프로그램의 실제 상태를 확인하세요. 규칙 모드에서는 대상 도메인에 DIRECT 규칙이 적용될 수 있으므로 클라이언트가 켜져 있어도 해당 요청이 반드시 노드를 거치는 것은 아닙니다.

로컬 mixed-port를 통해 요청을 비교하세요

아래 예시는 로컬 mixed-port가 7890이고 공개 테스트 도메인 example.com을 사용하는 경우입니다. 실제 문제를 테스트할 때는 토큰이 포함되지 않은 해당 사이트 URL로 바꾸고, 클라이언트에 표시된 포트에 맞추세요. Windows에서는 일부 PowerShell 환경에서 같은 이름의 별칭이 사용될 수 있으므로 curl.exe를 명시적으로 실행하는 것이 좋습니다.

# curl에서 프록시를 지정하지 않음; TUN이 연결을 계속 처리할 수 있음
curl -Iv --noproxy '*' https://example.com/

# mixed-port의 HTTP 프록시 연결 사용
curl -Iv --noproxy "" --proxy http://127.0.0.1:7890 https://example.com/

--noproxy '*'는 curl의 프록시 설정만 우회합니다. TUN, 투명 게이트웨이, 시스템 라우팅은 우회하지 못합니다. 실제 직결 기준을 얻으려면 허용되는 환경에서 관련 트래픽 처리 기능도 함께 꺼야 합니다. 위 명령은 인증서 검증을 끄지 않습니다. 출력에 요청 정보가 포함될 수 있으므로 공유 전에 민감한 내용을 가리세요.

• 특정 노드에서만 오류가 발생함: 다른 조건은 그대로 두고 노드를 바꾸며 인증서 SAN, 발급자, 오류 코드를 비교하세요. 클라이언트 연결 기록에서 적용된 규칙과 실제 출구도 확인하세요.
• 모든 출구에서 특정 웹사이트에만 오류가 발생함: 로컬 프록시 포트보다 웹사이트 인증서, 인증서 체인, CDN 엣지 설정을 먼저 의심하세요.
• 같은 기기에서 여러 웹사이트에 오류가 발생함: 시스템 시간, 신뢰 저장소, 패킷 캡처 도구, 관리형 네트워크를 먼저 확인하세요.
• 같은 네트워크의 여러 기기에서 오류가 발생함: 포털 인증, 라우터 DNS, 게이트웨이, 통신사 네트워크를 확인하고 필요하면 신뢰할 수 있는 다른 네트워크에서 비교하세요.

출구에 따라 다른 인증서가 표시된다고 해서 반드시 경로 변조가 발생한 것은 아닙니다. CDN은 지역별로 유효한 인증서와 중간 인증서 체인을 다르게 사용할 수 있습니다. 도메인이 일치하는지, 인증서 체인을 신뢰할 수 있는지, 유효 기간이 맞는지, 낯선 발급자를 설명할 수 있는지가 핵심입니다.

DNS 오염, 노드 문제, 포털 인증 구분하기

DNS 오염이나 잘못된 DNS 응답으로 도메인이 엉뚱한 서버를 가리키면 인증서 도메인 불일치가 발생할 수 있습니다. 그렇다고 상대 서버가 해당 도메인의 유효한 인증서를 갖게 되는 것은 아닙니다. 공격자가 DNS 응답만 바꾸는 것으로는 인증서 검증이 정상인 HTTPS 연결을 보통 몰래 복호화할 수 없습니다. 브라우저 경고는 바로 이 보안 경계를 지키기 위한 것입니다.

fake-ip 주소가 잘못된 DNS 응답을 뜻하는 것은 아닙니다

mihomo의 fake-ip 모드는 앱에 매핑용 가상 IP를 반환합니다. 일반적으로 198.18.0.0/16 범위를 사용하지만 실제 범위는 fake-ip-range 설정에 따릅니다. 조회 결과가 이 범위에 있다는 이유만으로 DNS 오염이라고 단정할 수는 없습니다. 코어에 도메인 매핑이 유지되는지, 연결에 어떤 규칙과 출구가 적용됐는지 확인하세요.

• 먼저 dns.enhanced-mode, nameserver, 설정되어 있을 수 있는 nameserver-policy, TUN의 dns-hijack을 확인하세요.
• 브라우저에서 보안 DNS를 사용하는지 확인하세요. 브라우저가 자체적으로 DNS 서버를 선택하면 예상과 다른 경로로 도메인을 조회할 수 있습니다.
• 두 DNS 서버가 반환한 IP가 같은지만 비교하지 마세요. CDN, 위치, 부하 분산에 따라 정상적으로 다른 결과가 나올 수 있습니다.
• DNS 설정을 바꾼 뒤에는 설정을 다시 불러오고 테스트 연결을 새로 만드세요. 기존 연결, DNS 캐시, fake-ip 매핑이 남아 있으면 결과가 한동안 뒤섞일 수 있습니다.

특정 출구에서만 문제가 발생하고 인증서 도메인이 일치하지 않거나 발급자를 설명할 수 없다면 해당 출구를 사용하지 말고 민감한 정보를 가린 기록을 보관하세요. 이는 해당 연결 경로와 관련된 문제라는 뜻이지만, 노드가 의도적으로 트래픽을 변조했다고 단정하기에는 부족합니다. 출구 네트워크의 DNS나 중간 장비 문제일 수도 있습니다.

호텔이나 공항 등의 네트워크에서는 먼저 포털 인증을 해야 할 수 있습니다. HTTPS 요청이 로그인 게이트웨이로 전달되면 인증서 오류가 발생할 수 있습니다. 시스템에서 제공하는 ‘네트워크에 로그인’ 안내를 통해 인증을 완료하세요. 인증서 오류가 발생한 원래 웹사이트에 계정을 입력하거나 포털 페이지용으로 출처를 알 수 없는 루트 인증서를 설치하지 마세요.

문제 해결 확인 및 흔한 오해

HSTS가 적용된 웹사이트에서 ‘계속 방문’이 표시되지 않는 이유는?

HSTS(HTTP Strict Transport Security)는 브라우저가 해당 사이트에 HTTPS를 엄격하게 적용하도록 합니다. 인증서 오류를 우회하는 기능이 제공되지 않는 것은 정상일 수 있습니다. HSTS 상태를 지우는 것은 인증서 문제를 해결하는 방법이 아닙니다. 시간, 인증서 체인, 도메인, 네트워크 경로 자체를 바로잡아야 합니다.

전역 모드로 바꾸거나 TUN을 켜면 해결되나요?

두 설정은 출구나 트래픽 처리 범위를 바꾸므로 통제된 비교 테스트에는 쓸 수 있지만, 만료된 인증서나 출처를 알 수 없는 발급자를 해결하지는 못합니다. 전역 모드는 라우팅 경로를 바꾸고 TUN은 네트워크 계층의 트래픽을 처리합니다. 어느 쪽도 브라우저의 웹사이트 신원 확인 기준을 바꾸면 안 됩니다. 테스트 후 정상으로 돌아왔다면 기존 규칙이나 경로에서 문제가 발생한 이유를 더 확인해야 합니다.

문제 해결 후 확인 목록

1. 필요한 규칙 모드와 프록시 연결 방식을 복원하고 임시 테스트 설정을 제거하세요. 인증서 검증은 켜 둡니다.
2. 기존 탭을 닫고 다시 접속해 호스트명이 올바른지, 인증서가 유효한지, 오류가 더 이상 나타나지 않는지 확인하세요.
3. 클라이언트 연결 기록에서 실제 적용된 규칙을 확인하세요. 캐시된 페이지나 예상한 출구를 거치지 않은 요청으로 결과를 판단하지 마세요.
4. 문제를 전달해야 한다면 운영체제, 브라우저 버전, 클라이언트와 코어 버전, 오류 코드, 발생 시각, 민감한 정보를 가린 인증서 정보를 제공하세요. 구독 URL, 노드 비밀번호, 전체 설정 파일은 보내지 마세요.

문제 해결 순서는 오류 코드 → 시스템 시간 → 인증서 정보 → 로컬 HTTPS 검사 → 직결 및 고정 출구 비교 → DNS와 네트워크 경로로 정할 수 있습니다. 검증 기준을 유지하면서 항목을 하나씩 좁혀 가는 편이 여러 설정을 한꺼번에 바꾸는 것보다 원인을 찾기 쉽습니다.