Clash TUN 모드 DNS 누수 막기: Mihomo 고급 설정과 점검 방법

TUN 모드가 DNS 누수를 자동으로 막아 주지는 않습니다

Clash Verge Rev나 Mihomo에서 TUN 모드를 켜면 시스템 프록시를 따르지 않는 앱의 연결도 가상 네트워크 인터페이스를 통해 처리할 수 있습니다. 하지만 이것이 모든 DNS 조회를 자동으로 Clash의 DNS 모듈에 전달한다는 뜻은 아닙니다. 앱이나 운영체제가 어떤 서버에 질의하는지, 그 질의가 TUN에 포착되는지, Mihomo가 받은 뒤 어떤 업스트림 DNS를 선택하는지까지 흐름이 이어져야 합니다.

DNS 누수는 보통 두 가지 상황을 가리킵니다. 첫째, 도메인 조회가 공유기나 인터넷 서비스 제공업체의 DNS로 직접 전달되는 경우입니다. 둘째, Mihomo가 DNS를 처리하더라도 사용자가 기대한 프록시 경로가 아니라 직접 연결로 업스트림 서버에 질의하는 경우입니다. 반대로 DNS 질의가 암호화되지 않았다는 사실만으로 반드시 누수라고 단정할 수도 없습니다. 중요한 것은 실제 질의 경로와 정책이 의도한 설정과 일치하는지입니다.

전체 흐름은 다음 순서로 생각하면 편합니다. 앱이 도메인을 조회하고, 운영체제나 앱 내부 DNS가 질의를 생성합니다. TUN의 DNS 하이재킹 규칙이 그 패킷을 포착하면 Mihomo DNS가 설정에 따라 응답하거나 업스트림으로 질의합니다. 이후 앱의 연결은 Fake-IP 매핑, 도메인 스니핑, 라우팅 규칙을 거쳐 DIRECT 또는 프록시 아웃바운드로 전달됩니다. 이 중 어느 한 단계라도 빠지면 DNS 응답은 정상처럼 보이면서 실제 연결은 예상과 다르게 나갈 수 있습니다.

따라서 점검할 때는 “TUN이 켜져 있는가?”만 확인하지 말고, “질의가 TUN에 들어왔는가?”, “어떤 DNS 서버가 선택됐는가?”, “해당 도메인 연결은 어떤 규칙에 매칭됐는가?”를 나눠서 살펴보세요. 이 구분은 DNS 오류와 프록시 노드 장애를 혼동하지 않게 해 줍니다.

TUN의 DNS 하이재킹과 우회 경로 확인

먼저 클라이언트 화면에서 TUN이 실제로 실행 중인지 확인합니다. 일부 클라이언트는 TUN 스위치를 켰더라도 서비스 설치가 끝나지 않았거나 권한 승인이 보류되어 가상 인터페이스가 만들어지지 않을 수 있습니다. 운영체제의 네트워크 어댑터 목록에서 Mihomo 관련 인터페이스가 나타나는지 확인하고, 로그에 TUN 초기화 오류나 라우트 등록 실패가 반복되는지도 살펴보세요. 다른 VPN, 가상 머신, 방화벽 프로그램이 동시에 기본 경로를 변경하면 DNS 패킷이 다른 인터페이스로 빠질 수 있습니다.

설정 파일에서는 TUN과 DNS를 각각 확인해야 합니다. 다음은 구조를 설명하기 위한 예시이며, 사용 중인 Mihomo 버전과 클라이언트의 설정 병합 방식에 맞춰 조정해야 합니다.

tun:
  enable: true
  stack: mixed
  auto-route: true
  dns-hijack:
    - any:53
    - tcp://any:53

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip

dns-hijack는 TUN을 통과하는 일반 DNS 패킷을 Mihomo 쪽으로 보내는 설정입니다. UDP 53번 질의만 포착하면 TCP를 사용하는 DNS 요청이 빠질 수 있으므로 TCP 항목도 확인하는 편이 좋습니다. 다만 하이재킹이 적용되는 범위는 운영체제, 코어 버전, 클라이언트가 생성하는 최종 설정에 따라 달라질 수 있습니다. 설정 파일에 항목이 있다는 이유만으로 동작한다고 가정하지 말고 로그와 실제 질의 결과를 함께 확인하세요.

브라우저의 보안 DNS나 앱 자체 DoH도 점검 대상입니다. DoH는 HTTPS를 이용하므로 일반 DNS의 53번 포트 규칙만으로는 구분되지 않습니다. TUN이 연결 자체를 포착할 수는 있지만, 브라우저가 지정한 DoH 서버로 연결을 직접 보내거나 앱별 우회 설정이 있으면 Clash DNS의 nameserver-policy가 그 질의를 통제하지 못할 수 있습니다. 진단할 때는 브라우저의 보안 DNS를 잠시 끄거나, 해당 앱의 자체 DNS 설정을 기본값으로 되돌린 뒤 같은 도메인을 다시 조회해 비교하세요.

Fake-IP와 nameserver-policy를 목적에 맞게 설정하기

Fake-IP 모드에서는 Mihomo가 도메인에 실제 IP 대신 가상 주소를 반환하고, 해당 가상 주소와 도메인의 대응 관계를 기억합니다. 앱이 그 주소로 연결하면 Mihomo는 저장된 도메인 정보를 이용해 규칙을 적용할 수 있습니다. 도메인 기반 규칙을 활용하기 편리하지만, 앱이 IP 주소를 직접 사용하는 경우나 Fake-IP 응답을 허용하지 않는 일부 환경에서는 예외가 생길 수 있습니다. 이때는 해당 도메인을 Fake-IP 제외 목록에 넣을지, redir-host 모드가 더 적합한지 비교해야 합니다.

nameserver는 일반적인 DNS 질의에 사용할 업스트림을 지정합니다. nameserver-policy는 특정 도메인이나 도메인 분류에 별도의 업스트림을 적용할 때 사용합니다. 예를 들어 내부 도메인은 사내 DNS로, 그 외 도메인은 암호화된 DNS 서버로 보내도록 나눌 수 있습니다. 정책이 넓은 도메인 패턴과 좁은 패턴에 동시에 적용될 때는 실제 선택 결과를 확인하고, 중요한 도메인을 명시적으로 지정해 의도하지 않은 기본 서버 사용을 줄이세요.

dns:
  enable: true
  enhanced-mode: fake-ip
  default-nameserver:
    - 223.5.5.5
  nameserver:
    - https://1.1.1.1/dns-query
  proxy-server-nameserver:
    - 223.5.5.5
  nameserver-policy:
    'geosite:cn':
      - https://dns.alidns.com/dns-query

위 예시의 서버 주소와 정책은 설명을 위한 것이므로 네트워크 환경에 맞게 바꾸세요. default-nameserver는 호스트 이름으로 적힌 DNS 서버 주소를 먼저 해석해야 할 때 사용할 수 있습니다. 프록시 노드 주소를 찾는 데 필요한 DNS까지 프록시를 거치도록 강제하면 순환 의존이 생길 수 있으므로, 노드 서버 도메인을 해석할 경로를 proxy-server-nameserver 등으로 분리하는 것이 중요합니다.

nameserver-policy는 도메인별 업스트림 선택에 관한 설정이고, 연결이 최종적으로 프록시를 타는지는 라우팅 규칙이 결정합니다. DNS 서버를 암호화된 주소로 바꿨다고 해서 질의가 자동으로 프록시를 경유하는 것은 아닙니다. 반대로 도메인 정책은 맞더라도 마지막 MATCH 규칙이 DIRECT를 선택하면 연결은 직접 나갈 수 있습니다. DNS 응답과 연결 규칙을 별도로 검증해야 하는 이유입니다.

respect-rules와 IPv6를 함께 점검하기

respect-rules는 Mihomo가 DNS 업스트림으로 보내는 질의에도 라우팅 규칙을 고려하도록 하는 옵션입니다. 이를 켜면 DNS 요청의 목적지에 적용되는 규칙에 따라 질의가 전달될 수 있어, 원하는 프록시 경로를 구성할 때 유용합니다. 하지만 이 옵션만 추가하면 모든 DNS가 프록시로 간다고 볼 수는 없습니다. 규칙의 순서, DNS 서버 주소, 해당 서버에 적용되는 아웃바운드, 프록시 노드 주소를 해석하는 별도 경로가 함께 맞아야 합니다.

특히 프록시 노드의 서버 주소를 DNS로 알아내야 하는데, 그 DNS 질의도 해당 프록시를 통과해야 한다고 설정하면 연결이 시작되기 전에 경로가 막힐 수 있습니다. 이런 순환을 피하려면 노드 서버 해석에 사용할 업스트림을 따로 지정하고, 필요한 경우 해당 조회는 직접 연결하도록 분리하세요. 설정을 바꾼 뒤에는 노드 도메인 해석이 성공하는지, 일반 웹 도메인의 DNS 요청은 의도한 경로를 따르는지 각각 확인해야 합니다.

IPv6도 자주 놓치는 부분입니다. Mihomo의 DNS 설정에서 IPv6 응답을 허용하더라도 운영체제나 공유기가 별도의 IPv6 기본 경로를 제공할 수 있습니다. 반대로 DNS에서 AAAA 응답을 받지 못하게 설정했더라도 앱이 이전에 캐시한 IPv6 주소를 사용할 수 있습니다. 테스트 중 IPv4만 프록시를 통과하고 IPv6는 직접 연결되는지 의심되면 운영체제의 IPv6 상태, TUN의 IPv6 라우트, 방화벽 정책, Mihomo DNS의 IPv6 응답 설정을 한꺼번에 보지 말고 각각 확인하세요.

로그와 명령으로 DNS 경로 확인하기

다음 순서로 점검하면 설정을 무작정 바꾸지 않고 문제 지점을 좁힐 수 있습니다. 가능하면 한 대의 기기와 한 개의 앱에서 테스트하고, 같은 도메인을 사용해 설정 변경 전후 결과를 비교하세요. 테스트용 웹사이트가 표시하는 DNS 서버 이름이나 위치만으로 결론을 내리지 말고, Clash 로그와 운영체제의 조회 결과도 함께 살펴보는 것이 좋습니다.

nslookup이나 dig의 출력에 표시되는 서버 주소는 해당 명령이 사용한 질의 경로의 단서입니다. 다만 명령줄 결과 하나만으로 모든 앱의 DNS 경로가 동일하다고 증명할 수는 없습니다. 브라우저는 자체 DoH를 사용할 수 있고, 일부 앱은 자체 DNS 라이브러리나 고정된 서버를 사용할 수 있습니다. 따라서 브라우저와 문제가 발생한 앱에서도 별도로 재현하고 Mihomo 로그에 같은 시각의 요청이 나타나는지 비교하세요.

로그에 업스트림 타임아웃이 보이면 먼저 해당 DNS 서버에 접근 가능한지 확인합니다. 암호화된 DNS 주소가 프록시를 필요로 하는 환경에서 직접 연결로만 설정되었거나, 반대로 노드 주소 해석까지 프록시를 강제해 순환한 경우일 수 있습니다. timeout이 없고 질의 응답도 정상인데 웹사이트 연결만 실패한다면 DNS를 계속 바꾸기보다 연결 로그에서 도메인 매칭과 아웃바운드를 확인하는 편이 빠릅니다.

DNS 유출 테스트 사이트는 참고 자료로 활용하되, 한 번의 결과를 확정적인 판정으로 받아들이지 마세요. 테스트 사이트가 여러 서버에 질의하거나 브라우저 캐시를 사용하면 결과가 달라질 수 있습니다. 다른 네트워크에서 다시 시험하고, 브라우저 보안 DNS를 끈 상태와 켠 상태를 비교하며, 실제 Mihomo 로그에서 조회가 처리됐는지를 함께 확인해야 오진을 줄일 수 있습니다.

자주 묻는 질문

TUN을 켰는데도 DNS 누수가 발생할 수 있나요?

가능합니다. TUN은 연결을 가상 인터페이스로 전달하는 기능이며, DNS 패킷 포착 여부는 dns-hijack, 앱의 자체 DoH, 운영체제 라우트와 클라이언트 구현에 영향을 받습니다. TUN 상태와 DNS 로그를 함께 확인하고, 문제가 발생한 앱의 보안 DNS 설정도 점검하세요.

Fake-IP와 redir-host 중 어느 쪽을 선택해야 하나요?

도메인 규칙을 적극적으로 활용하고 일반적인 앱 호환성이 확인됐다면 Fake-IP가 편리할 수 있습니다. IP 주소를 직접 사용하는 앱이나 Fake-IP와 충돌하는 환경에서는 redir-host를 시험해 볼 수 있습니다. 어느 방식이 항상 더 안전한 것은 아니므로, 자주 사용하는 앱과 규칙을 기준으로 비교하세요.

respect-rules를 켜면 DNS가 모두 프록시로 가나요?

그렇지 않습니다. 이 옵션은 DNS 업스트림 질의에 라우팅 규칙을 고려하게 하지만, 실제 경로는 규칙과 아웃바운드 구성에 따라 달라집니다. 프록시 노드 주소를 조회하는 경로도 별도로 확인해 순환 의존이 없는지 점검해야 합니다.

DNS 누수 테스트 사이트 결과만으로 문제를 확정할 수 있나요?

아니요. 사이트의 테스트 방식, 브라우저 캐시와 보안 DNS 설정에 따라 결과가 달라질 수 있습니다. Mihomo 로그, 운영체제 조회 결과, 앱에서의 재현을 함께 비교해 질의가 실제로 어디서 처리됐는지 확인하세요.

일부 간단한 프록시 앱은 DNS 업스트림을 세밀하게 나누거나 도메인 규칙과 연결 로그를 함께 확인하기 어려워, 문제가 생겼을 때 원인을 구분하는 데 시간이 걸릴 수 있습니다. Clash와 Mihomo는 Fake-IP, 도메인별 DNS 정책, 규칙 기반 라우팅을 조합하고 로그로 각 단계를 점검할 수 있어 설정을 세밀하게 관리하려는 사용자에게 유용합니다. 사용 중인 기기와 코어 버전에 맞는 구성을 확인한 뒤 직접 비교해 보고 싶다면 지금 Clash 받기에서 클라이언트를 살펴보세요.