튜토리얼 · 약 16분

안드로이드 「전용 DNS」가
Clash·FakeIP·규칙 분할을 망가뜨릴 때

Android에서 설정 › 연결 › 더보기 › 전용 DNS(영문 기기에서는 Private DNS)를 dns.google 같은 호스트명 모드로 켜 두면, 앱·웹뷰의 이름 해석이 Mihomo(Clash Meta)가 붙잡은 로컬 스텁(예: 127.0.0.1)을 건너뛰고 공개 DoT/DoH로 직행하는 경우가 많습니다. 그러면 FakeIP·dns.enhanced-mode: fake-ip가 전제하는 «클라이언트가 먼저 응답하는 가짜 대역» 흐름이 깨지고, 직접 연결처럼 보이거나 규칙 분할이 엇나갑니다. 본문은 끄기·자동으로 되돌리는 경로, FlClash·다른 VPN과 같이 쓸 때 점검 순서, 데스크톱 Chrome·Edge 보안 DNS 글과 어떻게 다른지까지 정리합니다.

Android · Private DNS · Clash · FakeIP · DNS

1 흔한 증상: 프록시 켰는데 앱만 «규칙이 안 먹는» 느낌

FlClashClash 계열 Android 클라이언트로 VPN 터널을 올리고, PC와 같은 구독·규칙을 썼는데도 특정 ·인앱 브라우저에서만 해외 라인이 아닌 것처럼 보이거나, DIRECT로 새는 로그가 남는 상황이 있습니다. 같은 단말에서 Termuxdig·Chrome 주소줄 테스트를 하면 분기가 맞는데, SNS·쇼핑 앱만 이상할 때 원인 목록에는 배터리 최적화(FlClash 백그라운드 글), 다른 VPN 동시 실행, 그리고 이 글의 핵심인 시스템 전용 DNS 설정이 함께 올라갑니다.

특히 이름을 미리 «진짜 IP»로 받아 버리면 Mihomo가 나중에 연결 단계에서 매칭하려 해도 이미 브라우저·소켓이 다른 경로를 탄 뒤라, 사용자 입장에서는 분할 이상·DNS 이상으로 읽히기 쉽습니다. 먼저 Android 전용 DNS자동이나 해제로 돌려 로컬 리졸버가 다시 클라이언트 스텁을 보도록 맞추는 것이 비용 대비 효율이 좋습니다.

2 Android 「전용 DNS」(Private DNS) 한 줄 요약

Android 9(Pie) 이후 기본으로 들어간 기능으로, 설정 › 연결 › 더보기 연결 › 전용 DNS에서 해제·자동·전용 DNS 공급자 호스트 이름 중 하나를 고를 수 있습니다. 자동은 단말·통신사 정책에 따라 ISP나 제조사가 제안하는 DNS를 쓰거나, 사용자가 다른 곳에서 지정한 값을 우선할 수 있습니다. 호스트 이름을 직접 넣으면 TLS 기반(DoT)으로 해당 서버와 질의하게 되어, 평문 DNS보다 패킷 차원에서 우회 관측이 어렵다는 장점이 있습니다. 다만 이 «시스템 전역» 경로가 Clash가 붙잡으려는 127.0.0.1과 겹치지 않으면, 암호화 DNS는 오히려 규칙 엔진과 싸우게 됩니다.

용어 같은 주제가 PC에서는 Chrome 보안 DNS(DoH)·Windows 암호화 DNS로 나뉩니다. 안드로이드에선 브라우저보다 한 단계 위인 OS 네트워크 설정이라 경로만 다르고,「이름을 클라 바깥에서 먼저 풀어버리는 점»은 같습니다.

3 왜 Clash·Mihomo·스텁 DNS와 충돌하나

Mihomo 프로필에서 TUN이나 로컬 socks/http와 함께 DNS 섹션을 쓸 때, 많은 사용자는 루프백 127.0.0.1:포트 또는 dhcp/시스템에 맡겨 클라이언트 내부 스텁으로 질의를 모읍니다. 이때 안드로이드 전용 DNS공급자 호스트 이름 모드면, 도메인 쿼리가 스텁을 타지 않고 외부 레지스트리로 직행합니다. 결과적으로 fake-ip 스니펏이 기대하는 198.18.0.0/15 대역이 아닌, 이미 알려진 실서버 IP가 소켓에 박히고 DOMAIN/MATCH 규칙이 순서대로 적용되지 않을 수 있습니다.

IPv6 듀얼 스택 환경에서는 AAAA가 먼저 풀리며 경로가 갈라지는 경우도 있어, «DNS만 보면 될 것 같다»가 앱마다 달라 보이기도 합니다. 전용 DNS를 끄거나 자동으로 되돌린 뒤에도 남으면, Meta 커널 dns:·nameserverTUNstack 설정을 같이 점검합니다.

4 FakeIP·enhanced-mode와 동시에 쓰려면

dns.enhanced-mode: fake-ip을 켜면 애플리케이션이 A 레코드를 요청할 때 가짜 IP가 먼저 돌아가고, 실제 연결 시점에 스니퍼·규칙이 실제 호스트를 맞춥니다. Android 전용 DNS가 이 루프 앞에서 «진짜 응답»을 가져오면 설계가 흔들립니다. 그래서 FakeIP를 쓰는 팀일수록 시스템 DNS클라이언트와 일치시키는 문서(온보딩 체크리스트)에 전용 DNS 끄기 한 줄을 넣는 편이 장기적으로 이득입니다. 상세한 YAML·fallback 설계는 DNS 유출 방지·DoH 가이드를 참고하세요.

5 설정에서 끄기·「자동」으로 두기 (한국어·영문 UI)

대표 경로는 설정 › 연결 › 더보기 연결 설정 › 전용 DNS입니다(제조사에 따라 Wi-Fi 메뉴 안쪽·네트워크 및 인터넷 등으로 표기가 조금 다릅니다). 여기서 사용 안 함 또는 자동을 선택합니다. 자동은 통신사·기기가 제안하는 DNS를 쓰게 되어, 클라이언트가 시스템 DNS를 가로채는 구성(TUN·로컬 VPN)과 맞물릴 때 스텁으로 다시 모이는 경우가 많습니다. 반면 one.one.one.one·dns.google처럼 호스트 이름을 직접 넣은 모드는 이 글에서 말하는 «충돌»이 잘 나는 패턴입니다.

변경 후에는 Wi-Fi/모바일 데이터를 한 번 끄고 켜거나, 비행기 모드 토글로 스택을 재협상해 보세요. 특정 ROM은 개인 정보 보호 대시보드·보안·개인 정보 보호 패치로 메뉴가 옮겨지기도 하니, 검색창에 전용 DNS 또는 Private DNS를 입력해 바로 들어가는 방법이 빠른 경우도 있습니다.

기업 단말·MDM 회사 정책으로 전용 DNS항상 연결 VPN이 강제되면 사용자가 못 고칠 수 있습니다. 그때는 IT 쪽에 Mihomo 테스트용 예외 또는 분할 테스트 단말을 요청하는 편이 낫습니다.

6 FlClash·Mihomo Android와 같이 볼 때

FlClash 완전 설정에서 VPN 권한을 켠 뒤에도 분기가 이상하면, 다른 VPN 앱이 동시에 올라와 VpnService를 교체했는지·백그라운드에서 죽지 않았는지(배터리 가이드)를 먼저 제거합니다. 그 다음 순서가 전용 DNS입니다. Termux에서 코어를 올린 고급 시나리오는 Termux·WakeLock 글과 겹치는데, 본 주제에서는 «OS DNS가 코어 바깥으로 새는지」를 맞추는 것이 먼저입니다.

스플릿 터널·앱별 우회를 제공하는 클라이언트는 앱 패키지에 따라 DNS 경로까지 갈라질 수 있어, 전용 DNS와 겹치면 증상이 더 잘게 쪼개집니다. 이때도 기본 원칙은 동일합니다. 시스템 전용 DNS를 단순화한 뒤, 클라이언트 로그어떤 도메인이 어떤 그룹으로 잡혔는지 다시 확인합니다.

7 삼성·샤오미 등 제조사 스킨·Android 버전 차이

One UI·MIUI/HyperOS 등은 메뉴 이름이 다르거나, 보안 센터 안에 DNS 관련 스위치가 또 있을 수 있습니다. 개인 DNS·암호화 DNS 같은 동의어로 검색해 보세요. 어떤 ROM은 Wi-Fi별로 고급 옵션에서 IP 설정DHCP로 두지 않으면 사용자 지정 DNS가 우선이라, 전용 DNS와 겹칠 때 두 군데 모두 확인이 필요합니다. 증상이 한 앱에서만 재현되면 WebView 내부 캐시·앱 내 HTTP DNS 가능성도 있으나, OS 전용 DNS는 그 전에 맞추는 편이 낫습니다.

8 끄고 난 뒤 검증 (짧은 체크리스트)

  1. 전용 DNS를 자동 또는 해제로 바꾼 뒤, 비행기 모드재부팅으로 네트워크 스택을 초기화한다.
  2. Clash 클라이언트에서 로그를 열고, 문제가 되던 도메인이 기대한 프록시 그룹·규칙에 매칭되는지 본다.
  3. 가능하면 동일 SSID에서 Wi-FiLTE/5G를 바꿔 가며 테스트해 통신사 DNS 캐시 차이가 없는지 본다.
  4. FakeIP 풀 구간이 보이면, 이전에 «진짜 IP»만 보이던 앱에서도 패턴이 바뀌었는지 확인한다.
증상이 웹뷰만이면 브라우저 앱 vs 인앱 보드를 나누어 재현되는지 확인하세요. 순수 OS DNS 문제라면 브라우저 종류보다 네트워크 재협상 후 전체 앱에서 함께 나아지는 편입니다.

9 데스크톱 Chrome·Edge «보안 DNS」와 무엇이 다른가

PC에서는 브라우저가 직접 DoH를 켜며 OS 스텁을 우회하는 사례가 많아, 동일 팀의 Chrome·Edge 보안 DNS 가이드가 대응 문서입니다. 안드로이드에선 그보다 상위인 설정 앱의 전용 DNS가 전역에 가깝게 작동하므로, «앱 하나만 꺼도 된다»가 아니라 시스템 메뉴를 먼저 보는 검색 의도가 갈립니다. 두 글 모두 「이름 해석 경로 단일화」라는 같은 목표를 공유합니다.

10 자주 묻는 질문

  • 보안상 전용 DNS를 켜 두는 게 좋다고 하는데요. 통신 구간 암호화 관점에서는 맞지만, Mihomo가 이미 DoH/TLS DNS를 상류에 두고 로컬에서만 다루는 구성이라면, OS에서 또 중복 우회하는 것이 규칙·FakeIP와 충돌할 수 있습니다. 위협 모델이 ISP 스누핑 방지뿐이면 클라 단일 경로가 팀 단위로 더 깔끔할 때가 많습니다.
  • 자동 모드와 해제 무엇이 더 안전한가요? 기기·통신사마다 달라 «항상 우위»가 정해져 있진 않지만, 분할 테스트 목적이라면 우선 둘 다 시험해 로그 상 원하는 규칙이 붙는 쪽을 택하면 됩니다. 중요한 것은 하드코딩된 외부 호스트명 모드를 피하는 것입니다.
  • iPhone은요? iOS에는 동일 이름의 설정이 없고 iCloud 개인 정보 보호 릴레이·VPN 등 다른 레이어와 맞물립니다. 본문은 Android만 다룹니다.

11 정리

Android 전용 DNS(Private DNS)는 Clash·Mihomo가 설계한 로컬 DNS 스텁·FakeIP와 같은 길을 걷지 않을 때 «앱만 직연결처럼 보인다»·«규칙 분할이 이상하다»는 착시를 만들 수 있습니다. 자동 또는 해제로 돌린 뒤 네트워크를 재협상하고, FlClash·Termux 등 실행 방식과 겹쳐 읽으면 원인을 빠르게 줄일 수 있습니다. 노드·구독을 손보기 전에 OS DNS 입구 한 번 정리하는 습관이, 실제 운영 시간을 아꿉니다.

데스크톱·모바일·라우터까지 같은 정책 감각을 유지하려면 Clash 다운로드 페이지에서 환경에 맞는 클라이언트를 고르고, 구독·규칙을 한 흐름에서 맞추는 편이 유지 보수에 유리합니다.

→ Clash를 무료로 내려받고, 전용 DNS를 맞춘 뒤 분할이 기대대로 붙는지 확인해 보세요 — 설치 패키지는 본 사이트 다운로드 허브를 우선 사용하고, GitHub는 소스·이슈 확인용으로 두는 편이 버전 관리에 좋습니다.

→ Clash 무료 다운로드: Android DNS·규칙 한번에 점검

태그: Android 전용 DNS Private DNS Clash FakeIP Mihomo 규칙 분할 DNS
Clash Android Private DNS tutorial

Clash · Mihomo

FakeIP, DNS, 규칙 — OS와 맞추기

전용 DNS를 끄면 로컬 스텁과 dns 블록이 다시 이어집니다. FlClash·데스크톱까지 같은 설정 감각을 쓰려면 다운로드에서 플랫폼별 클라이언트를 선택하세요.

Android DNS 분할 FakeIP

관련 읽을거리