어떤 증상을 이 글이 가정하나요?
아래에 해당하면 이번 절차가 맞을 가능성이 큽니다. 프록시 자체는 켜져 있는데 특정 도메인만 이전보다 자주 실패하거나, 브라우저만 타임아웃이 나고 같은 기기의 다른 앱은 괜찮은 등 부분 실패 패턴입니다.
- IPv6 또는 DNS에서 IPv6를 우선하는 옵션을 켠 직후부터 증상이 시작됐다.
- AAAA 레코드가 있는 사이트에서만 문제가 두드러진다(반대로 IPv4만 있는 서비스는 정상).
- 연결 로그에 IPv6 대역으로 나가려다 끊기거나, 노드가 IPv4만 지원하는데 스택이 IPv6를 고른다고 의심된다.
반대로 모든 사이트가 동시에 안 되는 경우에는 먼저 노드 상태·구독·방화벽을 보는 편이 빠르고, 그다음에도 남으면 이 글의 DNS·IPv6 순서를 적용해 보세요. 전역 터널 설정은 TUN 모드 가이드와 함께 읽으면 맥락이 맞습니다.
왜 “IPv6를 켰더니 일부만” 깨질까?
클라이언트·OS·브라우저는 보통 이중 스택 환경에서 IPv4와 IPv6 중 하나를 먼저 고릅니다. prefer-ipv6가 켜져 있으면 코어가 해석 결과에서 IPv6 쪽을 우선할 수 있어, 출구 경로가 IPv6를 지원하지 않으면 연결이 성립하지 않거나 매우 느려지는 상황이 됩니다. 또한 DNS 단계에서 AAAA를 받아 오는 것과, 실제 TCP·UDP 세션이 노드를 통해 IPv6로 나갈 수 있는지는 별개입니다.
FakeIP 모드에서는 도메인 규칙 매칭과 실제 연결 정보 복원 과정이 추가로 얽히므로, IPv6만 문제 삼기보다 문서 허브에서 안내하는 대로 dns 블록 전체를 한 번에 보는 습관이 필요합니다. 증상 문구가 DNS처럼 보여도, 실제로는 IPv6 라우팅 불능인 경우가 많습니다.
1prefer-ipv6를 잠시 끄고 재현 여부 확인
Mihomo·Clash Meta의 dns 설정 안에 prefer-ipv6 항목이 있다면 false로 두고 코어를 다시 불러옵니다. 일부 GUI는 같은 의미의 스위치를 “IPv6 우선” 같은 이름으로 노출합니다. 이 한 줄만으로 특정 사이트가 바로 살아나면, 원인은 “해석은 IPv6인데 출구는 IPv6 미지원 또는 불안정” 쪽에 가깝습니다.
# Concept — adjust to your profile
dns:
enable: true
prefer-ipv6: false참고: YAML 키 이름은 클라이언트·코어 버전에 따라 GUI에서 자동 생성되는 문자열과 동일해야 합니다. 저장 후 반드시 프로필 재적용까지 했는지 확인하세요.
2DNS에서 IPv6 질의 자체를 줄이기
코어 설정에 dns.ipv6 같은 항목이 있다면, 이는 “AAAA 질의를 할지”와 관련된 경우가 많습니다. 네트워크나 노드가 IPv4 위주일 때 AAAA를 아예 받지 않도록 조정하면 브라우저·앱이 IPv6로 시도할 빌드를 줄일 수 있습니다. 다만 모든 환경에서 같은 키 이름이 보이지는 않으므로, 사용 중인 클라이언트 문서에서 dns 섹션의 IPv6 필드를 확인하는 것이 안전합니다.
동시에 nameserver와 fallback이 서로 다른 스택을 돌려 특정 도메인만 다른 해석 결과를 받는 경우도 있습니다. 이때는 nameserver-policy로 문제 도메인 묶음을 한 업스트림으로 고정해 보거나, 테스트 기간 동안에는 업스트림 수를 줄여 변수를 하나씩 없애는 방식이 디버깅에 유리합니다.
3TUN·스택과 IPv6 토글 정렬
TUN·터널 계층에서 IPv6를 허용하는 스위치와, 시스템이 실제로 IPv6 주소를 갖고 있는지가 어긋나면 이상한 경로로 빠지기 쉽습니다. 리눅스 게이트웨이나 서버에 바이너리를 올린 사용자는 Linux Mihomo·TUN 글에서 다룬 것처럼 인터페이스·포워딩·방화벽을 함께 봐야 합니다. 데스크톱 클라이언트만 쓰는 경우에도, VPN이나 다른 가상 어댑터가 IPv6를 가로채고 있으면 Clash 쪽 설정만으로는 증상이 남을 수 있습니다.
일시적으로 터널 IPv6를 끄거나, 반대로 OS에서 불필요한 IPv6 어댑터를 비활성화해 재현을 비교해 보세요. 운영체제 네트워크 진단 도구에서 IPv6 연결이 끊긴 상태인데 코어만 IPv6 우선으로 동작하면 타임아웃이 길어지기 쉽습니다.
4노드·업링크가 IPv6를 실제로 지원하는지
구독 노드나 백엔드가 IPv4만 제공하는 경우가 많습니다. 이때 애플리케이션 레벨에서 IPv6 타깃으로 나가려 하면 실패하거나 재시도 루프에 들어갑니다. 다른 노드나 다른 프로토콜로 바꿔 동일 사이트가 정상인지 비교하면 원인 분리가 빨라집니다. 멀티 홉이나 체인(relay)을 쓰는 구성이라면 중간 홉까지 포함해 IPv6 가능 여부를 가정해야 합니다.
5규칙·스니퍼와 함께 보기
도메인 기반 규칙이 기대대로 매칭되지 않으면 IPv6 여부와 무관하게 같은 증상이 납니다. 필요하면 스니퍼·프로세스 규칙을 다룬 다른 글을 참고하되, 이번 장에서는 “IPv6를 건드리기 전후로 로그의 목적지 주소가 IPv4에서 IPv6로 바뀌었는지”를 우선 확인해 보세요. MATCH 순서나 GEOIP 분기가 바뀌면 일부만 프록시를 타는 패턴도 생깁니다.
한 페이지 짜리 점검 목록
- prefer-ipv6 끄기 → 증상 소멸 여부.
- DNS IPv6 질의·업스트림 단순화 → 동일 도메인 재현 여부.
- TUN·OS IPv6 상태 일치 여부.
- 노드 IPv6 지원 여부 교차 테스트.
- 그다음에야 브라우저 전용 Secure DNS나 OS 캐시 비우기.
주의: 예시 YAML은 교육용입니다. 조직망·국가별 규정을 위반하지 않도록 하며, 제공자가 허용하는 범위 안에서만 노드·프로토콜을 사용하세요.
소스·릴리스 정보는 GitHub에서
Mihomo·클라이언트의 라이선스나 변경 내역은 GitHub에서 확인하는 것이 일반적입니다. 다만 설치 패키지를 받는 주 경로는 보안과 안내 일관성을 위해 공식 다운로드 페이지를 우선하는 편이 좋습니다. 소스 저장소는 투명성 확인용으로 두고, 일상적인 설치는 사이트 안내를 따르면 혼선이 줄어듭니다.
정리
Clash Meta·Mihomo에서 IPv6를 켠 뒤 일부 사이트만 문제라면, 넓게 보아 prefer-ipv6·DNS 이중 스택·노드 출구·TUN 네 축이 서로 다른 속도로 움직였는지 의심하면 됩니다. 한 번에 모든 스위치를 바꾸기보다 위 순서대로 꺼 보고 다시 켜며 원인을 좁히면, “DNS만 손댔는데 안 된다”는 소모전을 줄일 수 있습니다. 같은 구독이라도 IPv6 설계를 맞추면 체감 안정성이 달라지는 경우가 많습니다.
다른 도구와 비교해 보아도 규칙·로그·프로필 관리가 한데 모여 있는 Clash 계열이 장기 운영에는 편한 편입니다.