Clash IPv6·듀얼 스택 느림·유출? 인터페이스·규칙 점검

1. 증상: 듀얼 스택·IPv6가 의심될 때

프록시를 켠 상태에서 국내 포털·쇼핑·은행만 유독 느리거나, 로그인 단계에서만 시간이 깨지는 패턴은 여러 원인이 있습니다. 그중 하나가 IPv4와 IPv6가 서로 다른 물리 경로로 나가는 것입니다. 예를 들어 브라우저나 OS가 AAAA 레코드를 받아 IPv6로 접속을 시도하면, Clash가 IPv4 트래픽만 터널에 넣어 두었을 때 IPv6는 통신사 회선으로 그대로 빠져 나가 “프록시를 켰는데도 일부 연결은 집 주소처럼 보인다”는 검사 결과가 나올 수 있습니다. 반대로 IPv6까지 노드를 타게 했는데 노드 쪽 IPv6 경로가 불안정하면, 같은 사이트라도 체감 속도만 이상하게 나빠질 수 있습니다.

웹에서 흔히 말하는 「유출」은 대개 WebRTC나 DNS 문제로 설명되지만, 드물지 않게 IPv6 직통과 겹칩니다. 특히 홈 통신사나 캠퍼스망이 IPv6를 적극적으로 깔아 둔 환경에서는, “규칙은 맞는데도 검사 페이지만 이상하다”면 프로토콜 가족별 출구를 의심하는 것이 빠릅니다.

이 글은 특정 국가만을 가리키기보다, 지역 상관없이 국내·근거리 트래픽이 의도와 다르게 분배될 때 공통으로 쓸 수 있는 절차를 다룹니다. 이미 GeoIP로 국내 DIRECT를 맞춘 뒤에도 증상이 남으면, 이번 축(IPv6·바인딩·AAAA)을 다음 단계로 보시면 됩니다.

2. 로그로 IPv4·IPv6 출구 나누기

먼저 클라이언트 연결 로그에서 목적지가 IPv4인지 IPv6인지를 구분해 보세요. Mihomo·메타 계열은 목적지 주소 형태만으로도 한 번 걸러 볼 수 있습니다. IPv4 트래픽만 프록시 그룹으로 찍히고, 같은 호스트에 대한 IPv6 연결이 DIRECT이거나 아예 다른 정책이면, 규칙 YAML을 고치기 전에 “왜 v6만 이렇게 나가나”를 고정하는 편이 안전합니다.

확인 포인트

정책 이름: 두 프로토콜 모두 같은 정책 그룹으로 나가야 출구가 일관됩니다. 한쪽만 DIRECT면 검사 사이트에서 출구 IP가 둘로 갈립니다.
규칙 매칭 이유: GEOIP 규칙이 IPv6 주소에 대해 기대한 국가 코드로 분류되는지, 데이터베이스가 비어 있지 않은지 확인합니다.
TUN·시스템 모드: TUN을 켠 경우 OS 라우팅이 IPv6를 여전히 물리 NIC으로 보내는지, split 포함 예외에 국내 대역이 빠져 나가지 않는지 함께 봅니다. Windows 환경은 TUN·방화벽 글과 연결해 점검하세요.

팁: 진단 중에는 DNS·규칙·OS IPv6 토글을 동시에 바꾸지 마세요. 로그에 찍힌 한 줄이 어떤 변경에 반응했는지 남겨 두어야 재현과 롤백이 쉽습니다.

3. 인터페이스·바인딩과 라우팅

멀티 홈·VPN·Docker 등으로 물리·가상 NIC가 여러 개일 때, 코어가 어떤 인터페이스 이름으로 나가도록 바인딩돼 있는지가 출구를 바꿉니다. 데스크톱 클라이언트 설정에 interface-name 또는 유사 옵션이 있다면, 의도한 WAN과 일치하는지 확인하세요. Wi-Fi와 유선을 동시에 쓰거나, 셀룰러 테더링을 자주 바꾸면 운영체제가 기본 경로를 바꿔 버려 “어제까지 됐는데 오늘만 IPv6가 이상하다”가 되기도 합니다.

TUN 모드를 쓸 때는 IPv6 라우트 전체가 터널 어댑터를 향하는지가 핵심입니다. IPv4만 정책 라우팅에 올라가 있고 IPv6는 여전히 ISP RA를 타면, 같은 호스트라도 앱이 고른 주소 가족에 따라 완전히 다른 경로를 탑니다. 이 경우 단순히 규칙 YAML만 만져서는 부족하고, OS에서 기본 IPv6 게이트웨이와 Clash가 만든 인터페이스 우선순위를 같이 봐야 합니다.

현상	먼저 볼 것
IPv4만 노드, IPv6는 로컬 ISP	코어·OS IPv6 스위치·TUN이 v6를 덮는지, 노드가 IPv6 출구를 지원하는지
국내 사이트만 간헐 타임아웃	해당 호스트가 QUIC/HTTP3로 IPv6 우선 시도하는지, 규칙·방화벽이 UDP 경로만 다르게 막는지
노드 지연은 낮은데 체감만 나쁨	경로가 두 개라 세션·쿠키·위치 판별이 섞여 보이는지; DNS·브라우저 측 측정과 대조

4. DNS·AAAA·fake-ip 정렬

애플리케이션은 보통 A와 AAAA를 함께 받습니다. 해석 결과가 어디서 오느냐에 따라 “어느 주소로 연결할지”가 갈립니다. Clash DNS 섹션에서 enhanced-mode·fake-ip를 쓰면 규칙 엔진과의 상호작용이 달라지므로, fake-ip와 DNS 글에서 설명한 것처럼 이름 해석과 규칙 매칭이 같은 그림을 보게 맞추는 것이 선행입니다.

IPv6 전용 업링크나 ULA·임시 주소가 섞인 환경에서는, resolver가 AAAA를 우선 반환하는데 코어가 그 트래픽을 아직 처리하지 못하는 순간이 생길 수 있습니다. 이때 임시 완화로 OS나 라우터에서 IPv6를 끄고 증상이 사라지는지 확인하는 방법도 진단용으로는 유효합니다. 운영 목적의 최종 선택은 환경마다 다르지만, “끄면 나아진다”는 사실은 경로 불일치를 가리키는 단서입니다.

주의: 공공 Wi-Fi나 제한망에서는 IPv6 정책이 ISP마다 크게 다릅니다. 같은 YAML이라도 회선만 바꿔 증상이 달라지는 것은 정상에 가깝습니다.

5. 규칙이 IPv6 트래픽까지 커버하는지

GEOIP 규칙은 목적지 IP를 보고 판별합니다. IPv6 주소도 동일하게 매칭되어야 하므로, 로그에 찍힌 목적지가 2000::/3 등 글로벌 유니캐스트라면 GeoIP 데이터베이스에 해당 접두가 포함돼 있는지 확인합니다. 필요하면 코어가 지원한다면 IP-CIDR6 줄로 특정 국가·ISP 접두를 명시적으로 DIRECT 또는 프록시 그룹에 연결하는 방법도 있습니다.

규칙 순서 자체는 IPv4와 동일합니다. 넓은 MATCH나 글로벌 프록시 줄이 위에 있으면, 아래에 둔 GEOIP 국내 직통 줄은 도달하지 못합니다. 이미 GeoIP DIRECT 글에서 다룬 순서 원칙을 IPv6 로그에도 그대로 적용해 보세요. 도메인 기반 규칙만 있고 IP 규칙이 부족하면, 특정 사이트에서만 IPv6로 우회하는 패턴을 놓치기 쉽습니다.

rules:
  # Example shape — keys vary by Mihomo/Meta version
  - IP-CIDR6,fc00::/7,DIRECT
  - IP-CIDR6,fe80::/10,DIRECT
  - GEOIP,KR,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

위 예는 개념용입니다. 실제 국가 코드·사설 접두·프록시 그룹 이름은 사용 중인 리스트와 클라이언트에 맞게 바꿔야 합니다.

6. Mihomo·코어의 IPv6 스위치 의미

Mihomo 계열 설정에는 종종 ipv6: true/false 같은 최상위 또는 인바운드 관련 키가 등장합니다. 의미는 빌드마다 문맥이 조금씩 다르지만, 보통 한쪽은 코어가 IPv6 트래픽을 처리할지, 다른 쪽은 터널 인터페이스에 IPv6를 노출할지를 제어합니다. 잘못 이해하고 끄면 “IPv6만 전부 직통” 혹은 “IPv6 연결 자체가 실패” 중 하나로 극단적으로 기울 수 있으므로, 변경 전 현재 로그를 저장해 두고 한 단계씩 적용하는 편이 안전합니다.

프록시 노드가 IPv6 출구를 제공하지 않거나 불안정하면, 클라이언트가 IPv6를 활성화했더라도 실패·폴백이 반복될 수 있습니다. 이때는 노드 제공자 문서와 Health 체크 결과를 함께 보고, 필요하면 IPv4 우선 정책을 택합니다. url-test·interval 튜닝 글과 연결하면 “노드 선택은 되는데 특정 프로토콜만 깨진다”는 유형을 더 잘 설명할 수 있습니다.

7. 한 번에 점검하는 순서

증상 재현: 문제 사이트 하나만 고정하고, 동일 동작을 두 번 반복해 로그에 같은 패턴이 찍히는지 확인합니다.
프로토콜 분리: 연결 로그에서 목적지가 IPv4인지 IPv6인지 구분하고, 정책 이름이 가족별로 다른지 봅니다.
DNS 레이어: AAAA 응답이 클라이언트 DNS를 통과하는지, fake-ip와 충돌하지 않는지 fake-ip 글 순서로 점검합니다.
규칙 레이어: GEOIP·DOMAIN·MATCH 순서가 IPv6 목적지에도 기대대로 매칭되는지 확인하고, 필요 시 IP-CIDR6를 보강합니다.
TUN·OS: 예외 라우트와 인터페이스 우선순위가 IPv6에 대해 일관적인지 확인합니다. 필요 시 한동안 OS IPv6를 꺼 증상 소거를 시도합니다.
코어 스위치: ipv6 관련 키를 문서대로 조정한 뒤, 노드 IPv6 지원 여부와 함께 재측정합니다.

이 순서를 지키면 “규칙은 맞는데 DNS만 어긋난다”와 “DNS는 맞는데 TUN이 IPv6를 빼먹는다”처럼 층별 원인을 빠르게 가를 수 있습니다.

8. 요약

Clash·Mihomo에서 IPv6를 켠 뒤 국내 사이트만 느려지거나 IP 검사에서 출구가 둘로 갈라져 보인다면, 먼저 IPv4와 IPv6가 같은 정책·같은 터널 경로를 타는지를 로그로 확인하세요. 인터페이스 바인딩, DNS·AAAA·fake-ip, GEOIP와 IP-CIDR6 규칙, TUN·OS 라우팅을 순서대로 좁히면 원인이 한층 선명해집니다. 지역별 국내 직통은 GeoIP 글, 브라우저 측 유출은 WebRTC·DNS 글과 함께 보시면 전체 그림이 맞습니다.

환경마다 최적 해가 다르므로, 한 번에 모든 스위치를 뒤집기보다 단계별 로그 비교를 권합니다. 클라이언트 설치와 개요는 문서 센터에서 확인할 수 있습니다.

프록시 경로를 안정적으로 맞추어 두면 해외 서비스와 국내 업무 트래픽을 동시에 다루기 훨씬 수월해집니다. 다른 도구에 비해 설정 계층이 잘 나뉘어 있는 편이라, 원인만 분리되면 반복 튜닝 부담도 줄어듭니다.

→ Clash 클라이언트를 무료로 내려받고, IPv6·규칙·DNS를 한데 맞춰 보세요