Clash 구독 갱신이 Windows에서만 실패할 때: TLS handshake·DNS·로그로 원인 분기하고 mixed-port까지 맞추기 (2026)

1. 증상 정리: 브라우저 OK vs 클라이언트만 실패

먼저 「브라우저에서 같은 URL이 열린다」는 사실만으로 「네트워크는 완전히 정상」이라고 단정하면 안 됩니다. 브라우저는 사용자가 로그인해 둔 세션·쿠키·리다이렉트 체인을 그대로 타고, 기업 환경에서는 PAC·프록시 예외가 자동으로 붙는 경우도 있습니다. 반면 Clash 쪽 구독 갱신은 보통 백그라운드 HTTP 클라이언트가 프로필의 DNS·아웃바운드 규칙을 따라 새 연결을 여는 그림에 가깝습니다. 그래서 브라우저에선 200 OK인데 코어에선 403·451·빈 응답·리다이렉트 루프가 나올 수 있습니다.

또 하나 자주 빠지는 전제는 User-Agent와 Referer입니다. 일부 구독판은 데스크톱 브라우저 문자열은 허용하지만 봇·기본 UA는 거절합니다. 이때는 로그의 HTTP 상태코드와 응답 본문 일부를 같이 봐야 합니다. 증상을 「타임아웃」「TLS」「DNS」 중 어디에 가깝게 묶어 두면 아래 단계에서 로그를 읽을 때 훨씬 빨라집니다.

2. 구독 갱신이 밟는 경로(DNS → TCP → TLS → HTTP)

mihomo 계열에서 구독 URL을 가져올 때는 대략 다음 순서를 밟습니다. 호스트명을 DNS 해석하고, 선택된 다이얼러(직통·프록시·체인)로 TCP 연결을 열며, HTTPS라면 TLS handshake로 인증서를 검증한 뒤 HTTP GET으로 본문을 받습니다. 어느 단계에서 멈추는지가 로그에 다른 얼굴로 남습니다. DNS가 먼저 막히면 이름 자체를 못 얻거나 잘못된 IP로 붙습니다. TCP가 막히면 SYN 이후 응답이 없거나 RST가 납니다. TLS에서 실패하면 handshake 관련 문구가 찍히고, HTTP에서 실패하면 상태코드·바디가 남습니다.

여기에 규칙 모드가 끼어 있으면 구독 도메인이 의도와 다른 정책 그룹·프록시로 나가거나, 반대로 DIRECT인데 회사 방화벽에 막혀 실패하는 식으로 어긋납니다. 그래서 구독 도메인만 잠시 GLOBAL이나 단일 노드로 고정해 보는 A/B 테스트가 실무에서 자주 쓰입니다. 라우팅 개념을 더 맞추려면 고급 라우팅 가이드를 참고하세요.

3. mihomo 로그에서 무엇을 먼저 보나

GUI마다 로그 탭 이름은 다르지만, 코어 로그에는 보통 DNS 질의, dial, TLS, fetch·subscription 같은 키워드가 섞여 나옵니다. 먼저 로그 레벨을 debug나 info로 올려 한 번 갱신을 눌러, 같은 타임스탬프 묶음만 따라가 보세요. DNS 단계에서 이미 에러면 TLS까지 가지 않습니다. 반대로 IP까지 찍힌 뒤 handshake에서 터지면 네트워크 경로는 열렸다고 보는 편이 맞습니다.

로그에 나오는 프록시 체인 이름이 기대와 다르면, 그 구독 요청이 어떤 아웃바운드로 나갔는지부터 의심합니다. DIRECT로 나가야 하는데 노드로 나가면 노드 쪽 TLS 검증 정책이나 SNI 문제가 겹칠 수 있고, 노드로 나가야 하는데 DIRECT면 로컬 ISP나 회사망 필터에 걸립니다. 한 줄이라도 「어떤 정책에 매칭됐는지」를 GUI의 연결 기록이나 로그의 rule 힌트와 맞춰 보세요.

# Optional: same host check from PowerShell (does not mimic Clash DNS stack)
curl.exe -vI --connect-timeout 12 "https://your-subscription-host/path"

위 명령은 OS 스택 기준이라 Clash와 1:1로 같다고 보지는 말되, 「직통으로는 TLS가 되는지」를 빠르게 가늠하는 용도로는 유용합니다. Clash에서만 실패하면 DNS·다이얼·인증서 검증 경로가 다르다는 신호에 가깝습니다.

4. DNS 분기: fake-ip, DoH, NXDOMAIN, 타임아웃

DNS 해석이 흔한 1차 원인입니다. fake-ip를 켠 프로필에서는 앱이 보는 IP와 실제 업스트림이 붙는 IP가 달라, 로그만 보면 혼란스러울 수 있습니다. 구독 갱신이 코어 내부에서 일어날 때는 매핑이 기대대로인지, DoH 엔드포인트 자체가 막히지 않았는지를 같이 봅니다. 로그에 i/o timeout·no such host·NXDOMAIN 류가 찍히면 우선 DNS 서버 가용성과 프로필의 nameserver·fallback 구성을 점검합니다.

Windows에서는 백신·필터 드라이버가 특정 DNS 포트나 DoH만 가로채는 경우도 있어, 브라우저의 보안 DNS 설정과 Clash의 DNS 설정이 엇갈리면 「브라우저만 된다」가 나옵니다. 테스트용으로 구독 호스트만 시스템 DNS나 신뢰할 수 있는 DoH로 잠시 고정해 보고, 성공하면 프로필의 DNS 섹션을 단계적으로 단순화하는 방식이 안전합니다. 스트리밍·AI 글에서 다룬 fake-ip·누수 이슈와 겹치면 Disney+ DNS 글의 체크 순서도 참고할 만합니다.

5. TLS handshake·인증서·회사망 SSL 검사

로그에 TLS handshake 실패·certificate 검증 오류·x509 관련 문구가 보이면, 실제 서버 인증서가 아니라 중간 프록시가 끼워 넣은 기업용 루트를 코어가 신뢰하지 못하는 전형적인 패턴입니다. 브라우저는 OS 저장소에 올라온 회사 루트를 이미 믿는데, Go 기반 코어는 별도 번들을 쓰는 경우가 있어 이런 괴리가 납니다. 해결은 (1) 올바른 신뢰 체인을 쓰는 출구로 나가게 하거나, (2) IT에서 배포한 루트를 신뢰 저장소에 포함하는 정석 루트이고, skip-cert-verify 같은 우회는 보안상 최후의 임시 조치로만 이해해야 합니다.

또 다른 TLS 계열은 SNI나 ALPN을 중간 장비가 깨뜨리는 경우입니다. 특정 노드로만 나갈 때만 실패하면 노드 쪽이 아웃바운드 TLS를 재종료하는 구조인지, 아니면 로컬 백신의 HTTPS 스캔이 Clash 프로세스만 다르게 대하는지를 비교합니다. 노드 전환이 즉시 증상을 바꾸면 구독 서버보다 아웃바운드 품질 쪽에 무게를 둡니다.

6. mixed-port·시스템 프록시·TUN과 갱신 트래픽

구독 갱신은 보통 코어가 직접 아웃바운드를 열기 때문에, 사용자가 브라우저에 넣은 시스템 프록시와 무관하게 동작하는 경우가 많습니다. 그래도 혼동이 생기는 지점이 mixed-port입니다. mixed-port는 로컬에서 앱이 붙는 HTTP·SOCKS 입구이고, 구독 클라이언트가 실수로 로컬 프록시를 한 번 더 타게 만들면 루프나 이중 프록시로 타임아웃이 날 수 있습니다. Verge Rev 등에서 시스템 프록시를 켠 뒤, 다른 도구가 같은 포트를 바라보게 꼬여 있지 않은지 확인하세요.

TUN 모드를 켠 상태에서 DNS 스니핑·스택 옵션이 공격적으로 켜져 있으면, 구독 도메인까지 가로채여 예기치 않은 경로로 나가기도 합니다. 이럴 때는 잠시 TUN을 끄고 시스템 프록시만으로 갱신이 되는지 비교해 보는 것이 좋은 분기입니다. TUN 원리는 TUN 모드 가이드에 정리되어 있습니다. LAN에서 mixed-port를 열어 둔 경우 방화벽 이슈는 LAN 공유·방화벽 글과 겹치니 같이 읽으면 빠릅니다.

7. Windows 방화벽·백신·다른 VPN과의 충돌

Windows Defender 방화벽이 Clash 코어 실행 파일의 아웃바운드를 막으면 구독만 조용히 실패하는 그림이 나옵니다. 처음 실행 때 뜬 대화상자에서 공용 네트워크로만 허용해 둔 경우, 집 Wi-Fi 프로필이 바뀌며 막히기도 합니다. 또 다른 상용 VPN이 TUN·WFP 필터를 잡고 있으면 Clash와 패킷 순서가 겹쳐 간헐적 실패가 납니다. 테스트 시에는 한쪽만 전역으로 켜는 습관이 안전합니다.

백신의 HTTPS 검사는 특정 프로세스만 예외로 두는 옵션이 있어, 브라우저와 Clash가 서로 다른 대우를 받으면 증상이 갈라집니다. 회사 PC라면 제로트러스트 에이전트가 로컬 프록시를 강제로 끼우는 경우도 있으니, 허용된 출구·PAC 문서를 IT에 확인하는 것이 장기적으로 가장 빠릅니다.

8. 구독 소스·403·User-Agent 차이

로그상 TCP·TLS는 통과했는데 HTTP에서 403·401·빈 본문이면 구독판 측 정책을 의심합니다. 토큰형 URL이 만료됐거나, IP 화이트리스트가 브라우저 세션과 Clash 출구 IP를 다르게 보는 경우입니다. 클라우드플레어류 보호를 쓰는 판은 봇 탐지로 코어 요청만 막기도 합니다. 이때는 공식 클라이언트가 권장하는 갱신 주기·헤더·대체 링크를 확인하고, 임의로 UA만 바꿔 우회하는 식은 유지보수가 어렵습니다.

구독 파일이 리다이렉트 체인을 길게 타는 경우, 중간 302가 인증을 요구하면 코어는 멈춘 것처럼 보일 수 있습니다. 로그에 최종 URL이 찍히는지, 중간 호스트가 다른 인증서를 쓰는지까지 따라가 보면 원인이 갈립니다.

9. 한 번에 적는 수정 체크리스트

아래 순서는 현장에서 시간 대비 효과가 좋은 편입니다. (1) 로그 레벨을 올리고 갱신 한 번을 재현한다. (2) 같은 시각대의 DNS 로그에 타임아웃·NXDOMAIN이 없는지 본다. (3) dial 로그의 아웃바운드 이름이 의도와 같은지 확인한다. (4) TLS 오류면 회사망·백신·노드 전환 A/B를 한다. (5) HTTP 코드면 구독 URL·토큰·판 정책을 본다. (6) TUN·시스템 프록시·다른 VPN을 끄고 최소 구성으로 재시도한다. (7) mixed-port와 방화벽 프로필을 점검한다.

이 루틴을 한 번 통과해 두면 이후에는 「브라우저만 된다」는 말이 나와도 당황하지 않고, 구독 갱신 실패를 DNS 해석·TLS handshake·HTTP·정책 그룹 네 갈래로 빠르게 접을 수 있습니다. Windows에서 GUI를 바꿔도 코어 로그의 말투는 비슷하니, 글의 흐름을 그대로 다른 클라이언트에도 이식할 수 있습니다.