이중 스택 네트워크에서 Clash TUN을 켜도 IPv6·DNS가 어긋날 때: 누수를 막고 mihomo 규칙을 교정하는 실측 (2026)

1. TUN인데도 새는 것처럼 보이는 전형적 패턴

많은 사용자가 보고하는 첫 화면은 비슷합니다. 대시보드에는 TUN 어댑터가 올라가 있고, 로그에도 tun 인터페이스로 유입되는 기록이 있는데, 특정 웹사이트의 “내 IP” 페이지만 국내 회선 주소를 보여 줍니다. 또 다른 패턴은 스트리밍·클라우드·메신저가 서로 다른 지역 판정을 내놓는 경우입니다. 겉으로는 “한 가지 서비스만 실패”로 보이지만, 내부적으로는 DNS 응답이 A와 AAAA를 동시에 주고 애플리케이션이 더 빠른 쪽을 고른다는 점에서 출발하는 경우가 많습니다. 이는 Clash가 규칙을 무시한다기보다, 운영체제의 주소 선택 정책과 터널이 잡아야 할 패밀리가 어긋난 상태로 읽히는 것입니다.

여기서 중요한 구분은 “외부에서 보이는 출구 IP”와 “로컬 스택이 실제로 쓴 경로”입니다. 진단 페이지가 WebRTC나 QUIC 같은 별도 경로를 타면 TUN으로 잡힌 TCP 세션과 다른 결과를 낼 수 있습니다. 그래서 증상을 좁힐 때는 한 번에 “완전 누수”로 결론 내리기보다, 어떤 프로토콜·어떤 DNS 캐시·어떤 주소 패밀리에서만 어긋나는지 표로 적는 편이 재현에 유리합니다. TUN 모드가 무엇을 가로채는지 먼저 짚고 나면, 아래의 이중 스택 설명이 한결 선명해집니다.

2. 이중 스택이 규칙을 흔드는 이유

현대 운영체제와 브라우저는 대부분 해피 아이볼스 계열의 병렬 시도를 합니다. 같은 호스트 이름에 대해 A 레코드와 AAAA 레코드가 모두 있으면, 지연·패킷 손실·정책에 따라 먼저 성공한 쪽 세션이 이깁니다. Clash 쪽 규칙은 도메인 기준으로 잘 묶여 있어도, 어느 IP 패밀리로 소켓이 붙었는지에 따라 경로가 갈라질 수 있습니다. 특히 터널 경로가 IPv4 위주로만 안정적으로 잡혀 있고 IPv6는 여전히 ISP 직결로 열려 있으면, 사용자가 체감하는 “우회”와 “직결”이 번갈아 나타납니다.

또 하나의 변수는 로컬 DNS 캐시·스텁 리졸버·브라우저 내장 DoH입니다. 앱마다 “누가 이름을 푸는가”가 다르면, 규칙 테이블에 넣은 도메인과 실제 연결 대상 IP가 어긋납니다. Clash Meta / mihomo에서 흔히 이야기하는 fake-ip 체계는 이런 불일치를 줄이려는 장치이지만, 이중 스택과 섞이면 AAAA 해석만 OS 쪽에서 따로 흘러가는 꼴이 되기도 합니다. 그때는 규칙을 늘리기 전에 DNS 설정을 규칙과 같은 축으로 맞추는 쪽이 먼저입니다.

배경 개념은 Clash 개요의 “모드와 라우팅” 설명과 연결됩니다. 정리하면 이 글의 초점은 애플리케이션 한 개를 고치는 것이 아니라, 이중 스택 전체의 DNS·주소 패밀리·분기 규칙 일관성입니다.

3. IPv6를 끄기 vs 터널로 흡수하기

현장에서는 두 갈래가 모두 쓰입니다. 첫째는 단기 진단을 위해 OS나 라우터에서 IPv6 연결을 제한하는 방법입니다. 테스트 기간에는 “가능한 한 한 가지 주소 패밀리만 남긴다”는 원칙이 디버깅 비용을 크게 줄입니다. 둘째는 IPv6를 살려 두되 터널과 정책을 일치시키는 방법입니다. 상용 회선에서 v6가 더 빠르거나 필수인 경우가 있어, 무조건 끄는 것이 항상 답은 아닙니다. mihomo 및 GUI 프로필에서는 보통 IPv6 트래픽도 코어가 다루도록 하는 옵션과, OS 쪽 어댑터 우선순위를 함께 조정하는 식으로 맞춥니다(정확한 키 이름은 사용 중인 클라이언트 문서를 따르세요).

여기서 오해를 줄이기 위해 한 가지 분명히 하겠습니다. 본문은 불특정 네트워크에서 ISP 정책을 우회하라는 뜻이 아닙니다. 학교·회사·공공망에서는 터널링 자체가 금지될 수 있습니다. 아래 절차는 합법적으로 본인이 운영할 수 있는 기기 위에서, 기술적 일관성을 확보하기 위한 체크리스트입니다. 라우터 관리자라면 LAN 쪽 IPv6 접두 할당 방식(RA/PD)과 Clash 호스트의 기본 게이트웨이 순서를 같이 보는 것이 좋고, 노트북 한 대만 다룬다면 OS에서 어댑터 메트릭·인터페이스 우선순위를 함께 점검합니다.

4. DNS와 fake-ip를 이중 스택에 맞추기

DNS 누수라는 말은 흔히 “DNS 요청이 암호화되지 않았다”는 의미로 쓰이기도 하지만, 이 글에서는 더 넓게 이름 해석 경로가 Clash 밖에서 먼저 결정되어 규칙과 어긋나는 상태를 가리킵니다. mihomo 설정에서는 dns 블록의 enhanced-mode, nameserver 목록, fallback, 그리고 nameserver-policy로 특정 도메인을 별도 업스트림에 묶는 패턴이 자주 등장합니다. 이중 스택에서는 여기에 IPv6 전용 업스트림이 응답하는지, OS가 스텁 리졸버를 우회하는지를 함께 봐야 합니다.

예시로, 사용자가 자주 비교하는 Windows 구독·TLS·DNS 로그 글은 “같은 URL이 브라우저와 코어에서 왜 다르게 보이는가”를 분리해 줍니다. 이중 스택 상황에서는 그 위에 AAAA가 붙은 순간 경로가 갈라질 수 있다는 층을 얹어 읽으면 좋습니다. 테스트 시에는 가능한 한 한 종류의 DNS만 남기고, 브라우저 내장 DoH와 시스템 리졸버를 섞지 않는 것이 변수를 줄이는 데 도움이 됩니다.

# Excerpt — align DNS stack with your profile (adjust keys per client docs)
dns:
  enable: true
  enhanced-mode: fake-ip
  # Keep nameserver list minimal while debugging dual-stack races
  nameserver:
    - tls://…
  fallback:
    - tls://…

위는 형식 참고용입니다. 실제 업스트림 주소·프로토콜·fallback 필터는 신뢰하는 공급자와 클라이언트 버전에 맞춰야 하며, 회사망이라면 내부 규정을 우선합니다. 핵심은 DNS를 단순화한 상태에서 이중 스택 변화를 재현할 수 있는가입니다.

5. mihomo 규칙·GEOIP 교정

규칙 목록은 도메인 기준과 IP 기준이 섞입니다. 이중 스택에서 실패가 남는 흔한 이유는 GEOIP가 IPv4 데이터베이스만 본다거나, 반대로 IPv6 프리픽스가 기대한 국가와 다르게 매핑되는 경우입니다. rule-providers·GEOIP 갱신 글에서 말한 것처럼, 베이스 데이터가 오래되었거나 다운로드에 실패하면 체감 “지역”이 흔들립니다. IPv6가 살아 있는 환경이라면 IP-CIDR6 규칙이 필요한지, 로그에 찍힌 대상이 v4인지 v6인지부터 맞춥니다.

또 하나는 규칙 순서입니다. 넓은 GEOIP나 MATCH가 앞서면, 세세한 도메인 묶음이 있어도 뒤에서 삼켜지지 않습니다. Discord·게임·음성처럼 UDP와 호스트가 복잡한 앱은 TUN·UDP 분기 글의 순서를 참고해, 앱별 접미 도메인을 상단에 두는 패턴이 재현에 유리합니다. 이중 스택에서는 같은 도메인에서 나온 A와 AAAA가 서로 다른 정책 그룹으로 매칭되지 않도록, 한 호스트 이름에 대해 연결을 동일 아웃바운드로 묶인다는 전제를 먼저 확인합니다.

6. Sniffer와 AAAA의 교차점

HTTPS처럼 암호화된 세션은 처음부터 도메인이 보이지 않을 수 있어, mihomo의 Sniffer가 SNI나 인증서에서 이름을 복원하기도 합니다. 그런데 이중 스택에서는 같은 호스트의 AAAA가 먼저 붙어 IP만 보이는 경로가 생기면, 스니퍼·DNS·도메인 규칙의 세 축이 서로 다른 시점의 정보를 들고 움직입니다. 그래서 “스니퍼를 켰는데도 오분기된다”는 보고가 나올 때, IPv6 직결 트래픽이 섞여 있는지를 먼저 배제하는 편이 분석이 빠릅니다.

실무에서는 로그 타임스탬프를 맞추어 한 도메인 연결 시도에 대해 DOMAIN 규칙이 선택된 연결과 실제 패킷 경로가 같은지를 확인합니다. QUIC/HTTP3를 쓰는 환경이라면 UDP 경로가 별도인지, 브라우저 실험 플래그로 일시적으로 끄는 것이 변수 분리에 도움이 되는 경우도 있습니다. 다만 브라우저 버전마다 메뉴 이름이 달라지므로, 여기서는 구체 키보다 한 번에 한 변수만 바꾼다는 원칙만 강조합니다.

7. Windows·macOS·Linux에서 함께 볼 점

Windows에서는 어댑터 바인딩 순서·Wintun 설치·보안 제품의 가상 어댑터 필터가 겹칩니다. Verge Rev를 쓰는 경우 Windows 11 Verge Rev 가이드의 시스템 프록시와 TUN 순서를 먼저 확정하고 IPv6 관련 설정을 보는 편이 덜 헷갈립니다. 관리자 권한으로 네트워크 어댑터 목록을 열어 불필요한 터널이 중복으로 올라와 있지 않은지도 확인하세요.

macOS에서는 시스템 확장과 Full Disk Access가 TUN 활성화를 가릴 수 있고, IPv6는 인터페이스별로 별도 경로를 타기 쉽습니다. macOS Verge Rev 글의 권한 절차를 통과한 뒤, Wi-Fi 세부 정보에서 IPv6 구성이 자동인지 수동인지 확인하면 변수가 줄어듭니다.

Linux 배포판에서는 sysctl로 전달·프라이버시 확장 헤더와 관련된 옵션을 보거나, 네트워크 매니저에서 IPv6 방법을 “무시”로 두는 등 폭넓은 조정이 가능합니다. 다만 데스크톱 환경과 배포판마다 UI가 달라 본문에서 단일 명령으로 통일하기는 어렵습니다. 원칙은 같습니다. 한 번에 한 계층만 바꾸고, Clash 로그와 ip -6 route 같은 출력을 짝지어 보는 것입니다.

8. 실측 검증 순서

권장 루틴을 요약하면 다음과 같습니다. ① TUN을 켠 상태에서 Clash를 재시작하고, 로그에 tun 인터페이스 생성과 라우팅 추가가 정상인지 확인합니다. ② 같은 시점에 OS에서 IPv4·IPv6 주소가 무엇이 활성인지를 기록합니다. ③ DNS를 단순화한 뒤 웹·CLI에서 같은 호스트를 풀어 A와 AAAA가 동시에 돌아오는지를 봅니다. ④ 의심 앱 하나를 골라, 세션 동안 로그의 DOMAIN / IP / 아웃바운드 튜플이 끊기지 않는지 연속으로 확인합니다. ⑤ 마지막으로 지역 판정 사이트와 WebRTC 유출 테스트 페이지를 같은 브라우저 프로필에서 비교합니다.

이 순서의 장점은 “TUN이 잘못됐다”와 “IPv6 경로만 갈라졌다”를 빨리 가르는 것입니다. 둘째 증상이라면 규칙을 늘리기보다 주소 패밀리와 DNS를 먼저 맞추고, 그다음 노드 품질을 의심하는 편이 비용 대비 효율이 좋습니다. 장시간 재현이 어려우면 라우터·케이블·Wi-Fi 대역까지 바꿔 “한 시점에 병목이 하나뿐인지”를 확인하세요.

9. 정리와 다음 단계

2026년 기준으로도 이중 스택은 “깨끗하게 IPv4만 남긴 집”보다 흔한 배포입니다. Clash 사용자 입장에서 가장 비싼 실수는 TUN 스위치와 DNS 패널을 각각 보면서도 전체 주소 패밀리를 표에 올리지 않는 것입니다. 같은 도메인이 A와 AAAA를 동시에 갖고, OS가 더 빠른 쪽을 고르면 규칙은 맞는데 체감만 틀어지는 사이에 시간이 갑니다. 이 글이 제시한 순서—증상을 프로토콜별로 쪼개고, IPv6 정책을 명시하고, mihomo DNS를 단순화한 뒤 규칙·GEOIP·스니퍼를 교차 검증한다—는 그 공백을 메우기 위한 뼈대입니다.

오픈소스 생태계는 릴리스가 자주 바뀌므로, 특정 YAML 키를 고정값처럼 적어두기보다 원리를 이해하고 릴리스 노트를 함께 읽는 습관이 안전합니다. GitHub의 릴리스 노트는 코드·이슈·기여 방법을 보는 데 유용하지만, 설치 패키지를 받는 주 경로는 여전히 공식 안내에 맞는 배포 채널을 따르는 것이 사용자에게 일관된 경험을 제공합니다.

→ Clash를 무료로 내려받아 최신 클라이언트에서 TUN과 DNS를 같은 루틴에 넣고, 이중 스택 환경에서 IPv6·규칙·로그를 한 표로 다시 점검해 보세요. 정책 그룹과 노드 조합이 넓을수록 변수를 분리하기 쉬운 편입니다.