고급 설정 약 14분 읽기

Clash Meta(Mihomo) fake-ip-filter: LAN·직접 연결 도메인이 FakeIP에 잡히지 않게 하는 설정 (2026)

FakeIP(enhanced-mode: fake-ip)를 켜 두면 대부분의 이름이 코어가 관리하는 가짜 주소로 먼저 응답받습니다. 덕분에 DOMAIN·GEOSITE 기반 DNS 분류가 안정하는 경우가 많지만, 반대로 공유기 관리 페이지·NAS·프린터·mDNS(*.local)처럼 “진짜 사설 IP나 로컬 레코드”가 꼭 필요한 대상은 막혀 버릴 수 있습니다. 이때 전역으로 FakeIP를 끄기보다 dns.fake-ip-filter예외 목록을 두는 편이 운영에 유리합니다. 본 글은 Clash Meta·Mihomo 계열에서 그 목록을 어떻게 쌓고, nameserver-policy·rules와 맞춰 검증하는지 2026년 기준으로 정리합니다. 큰 그림은 Meta 코어 DNS 유출 방지 가이드와 짝을 이룹니다.

Clash 편집팀 Clash Meta · Mihomo · fake-ip-filter · FakeIP · LAN

증상: 프록시는 되는데 집 안 장비만 이상할 때

흔한 패턴은 다음과 같습니다. 해외 사이트는 잘 되는데, 브라우저에서 192.168.x.1 대신 북마크해 둔 공유기 호스트 이름(예: router.lan)만 타임아웃됩니다. 혹은 NAS 웹 UI, 네트워크 프린터 설정 페이지, 개발용 something.local 이름이 갑자기 열리지 않습니다. 이때 노드를 바꿔도 증상이 그대로라면, 원인은 종종 출구 품질이 아니라 DNS 응답이 FakeIP 대역(예: 198.18.0.0/15 계열)으로 돌아가 버려 애플리케이션이 기대하는 “실제 LAN 주소”와 어긋난 경우입니다. 운영체제나 브라우저가 그 가짜 주소를 잠깐이라도 캐시하면, 설정을 고쳐도 몇 분간 이상하게 보이기도 합니다.

같은 이유로 직접 연결(DIRECT)으로 보내고 싶은 특정 사내·국내 도메인이 FakeIP에 먼저 걸리면, 규칙상으로는 DIRECT인데 연결 단계에서만 이상한 IP를 잡는 식의 스플릿 브레인이 생길 수 있습니다. 해결의 첫 단추는 “이 이름은 가짜 응답을 주면 안 된다”는 목록을 명시하는 것입니다. 그게 바로 fake-ip-filter가 담당하는 축입니다.

fake-ip-filter가 하는 일

dns 블록 아래 fake-ip-filter는 문자열 목록으로, 여기에 걸리는 이름에 대해서는 FakeIP 풀을 쓰지 않고 일반 nameserver·fallback 체인으로 실제 레코드를 받아 오라고 코어에 힌트를 줍니다(빌드·프리셋에 따라 세부 동작 표현은 조금씩 다를 수 있으나, 실무에서는 “FakeIP를 건너뛸 호스트 화이트리스트”로 이해하면 충분합니다). 반대로 말하면, 목록이 비어 있거나 부족하면 LAN 친화적 이름도 전부 가짜 주소로 돌아가기 쉽습니다.

주의할 점은 fake-ip-filter규칙(rules) 자체를 대체하지 않는다는 것입니다. DNS가 올바른 사설 IP를 돌려줘도, 그 다음 홉에서 여전히 PROXY 그룹을 타면 NAS에 붙지 못할 수 있습니다. 따라서 DNS 분류패킷 분류를 같은 시나리오에서 맞춰야 합니다. 예를 들어 IP-CIDR,192.168.0.0/16,DIRECT 같은 줄이 앞쪽에 있어야 할 수도 있고, 호스트 기준이면 DOMAIN-SUFFIX로 NAS 도메인을 DIRECT로 보내야 할 수도 있습니다.

복붙용 스타터: LAN·로컬·mDNS

아래는 교육용 스케치입니다. 사용 중인 코어 버전과 구독 템플릿에 맞게 병합하고, 이미 존재하는 dns: 키와 중복되지 않게 정리하세요.

# Sketch — merge into your real profile under dns:
dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "+.local"
    - "localhost"
    - "router.lan"
    - "time.*.com"
    - "+.msftconnecttest.com"
    - "connectivitycheck.gstatic.com"
  nameserver:
    - https://dns.example/dns-query
  fallback:
    - tls://dns.public:853

*.lan·*.local류는 가정용 공유기·맥·리눅스에서 자주 보이는 패턴입니다. 템플릿에 이미 비슷한 줄이 있다면 중복보다 누락이 문제인 경우가 많으니, “안 되는 호스트 문자열”을 로그에서 한 번 적어 두고 목록과 교차 확인하세요. time.*.com 같은 항목은 일부 운영체제의 시간 동기화 경로를 안정시키기 위한 예시로, 자신의 환경에 필요 없으면 빼도 됩니다.

참고: Meta 계열은 버전에 따라 +. 접두로 “서픽스 전체”를 표현하는 패턴이 문서화되어 있습니다. 저장 후 코어가 뜨지 않으면 YAML 문법·들여쓰기·중복 키부터 확인하세요.

사설 IP 대역과 호스트 이름

브라우저가 이미 숫자 사설 IP(10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 등)로 직접 접속한다면 DNS 단계가 아니라 라우팅·TUN·방화벽 쪽을 의심해야 합니다. 반면 이름으로만 접속하는 장비라면 fake-ip-filter가 여전히 중요합니다. 일부 NAS는 nas.home.arpa 같은 특수한 접미사를 쓰기도 하니, 증상이 난 호스트를 정확한 문자열로 적어 넣는 습관이 좋습니다.

회사망에서는 *.corp.example처럼 내부 전용 존이 길게 이어지기도 합니다. 이때는 nameserver-policy로 해당 접미사만 사내 리졸버로 보내고, 동시에 fake-ip-filter에도 같은 패턴을 넣어 FakeIP와 정책 DNS가 서로 다른 이야기를 하지 않게 맞추는 패턴이 자주 쓰입니다. 정책 DNS의 도달성·로그 보존은 조직 규정을 따르세요.

rules 순서와 DIRECT의 의미

DNS가 진짜 192.168.1.10을 돌려줬는데도 연결이 프록시로 나간다면, rules에서 MATCH,PROXY 같은 넓은 줄이 앞서지 않았는지, 혹은 GEOIP 줄이 의도와 다르게 적중하지 않는지 봐야 합니다. GEOIP·GEOSITE 분할 가이드에서 강조하듯, 위에서 먼저 매칭된 줄이 이후를 가립니다. LAN 트래픽은 가능한 한 앞쪽에서 DIRECT로 끝내고, 인터넷만 PROXY로 보내는 구조가 디버깅에 유리합니다.

HTTPS에서 도메인이 보이지 않고 IP로만 연결되는 앱이 있다면 Sniffer 가이드와도 연관이 있습니다. 다만 NAS 웹 UI처럼 호스트가 분명한 경우에는 스니퍼 이전에 fake-ip-filter부터 맞추는 편이 비용 대비 효과가 큽니다.

TUN·dns-hijack과의 관계

TUN 모드에서 시스템이 여전히 다른 경로로 53번 포트를 쓰면, Clash 밖에서 먼저 해석이 끝나 “필터는 맞는데 체감은 이상”이 될 수 있습니다. Clash Verge Rev TUN 모드 가이드DNS 유출 방지 글tun.dns-hijack 설명을 함께 적용하세요. 하이재킹이 빠지면 FakeIP·필터를 아무리 손봐도 일부 프로세스만 예외 동작할 수 있습니다.

검증 절차: 로그로 이름을 고정하기

  1. 프로필 저장 후 코어가 에러 없이 기동하는지 확인합니다.
  2. 문제 이름 하나를 골라 Clash DNS 로그에 그 질의가 찍히는지 봅니다.
  3. 응답이 FakeIP 대역이면 fake-ip-filter 패턴을 추가하거나 좁힙니다.
  4. 응답이 올바른 사설 IP인데도 연결이 실패하면 rules·TUN·방화벽 순으로 넘어갑니다.
  5. OS·브라우저 DNS 캐시를 비운 뒤 같은 실험을 반복합니다.

외부 컨트롤러를 쓴다면 Yacd·external-controller 가이드로 활성 연결과 정책 이름을 같이 보면 “DNS는 맞는데 출구만 다르다”를 빠르게 가릅니다. 한 번에 옵션을 여러 개 바꾸지 말고, fake-ip-filter 한 줄 또는 rules 한 줄만 움직이는 편이 원인 추적에 유리합니다.

흔한 실수

  • 과도하게 넓은 필터: 사실상 FakeIP 이점을 반쯤 포기하게 됩니다. LAN·직접 연결에 꼭 필요한 최소 집합을 유지하세요.
  • 규칙만 고치고 DNS는 그대로: 규칙이 DIRECT여도 DNS가 가짜 IP를 돌려주면 앱은 여전히 길을 잃습니다.
  • 템플릿 병합 충돌: 같은 키가 두 번 들어가면 마지막 값만 살아 남거나 로드에 실패합니다.
  • 캡티브 포털·게스트 Wi-Fi: 공항·호텔망에서 DNS 예외가 더 민감할 수 있습니다.

주의: 조직 보안 정책·국가 법규를 위반하지 마세요. 사내 존을 외부 리졸버로 보내는 설정은 승인 없이 적용하면 안 됩니다.

오픈소스와 설치 패키지

Mihomo 소스·이슈·릴리스 노트는 GitHub에서 확인할 수 있습니다. 다만 일상적인 클라이언트 설치는 보안 안내와 경로 통일을 위해 사이트 다운로드 페이지를 우선하는 편이 혼선이 적습니다. 전체 옵션 지도는 문서·설정 허브와 함께 보세요.

맺음말

FakeIP는 규칙 모드를 살리는 강력한 도구이지만, LAN·직접 연결 도메인에는 오히려 방해가 될 수 있습니다. fake-ip-filter로 “가짜 응답을 주면 안 되는 이름”을 명시하고, rules에서 같은 트래픽을 DIRECT로 마무리하면 공유기·NAS·*.local 문제를 전역 FakeIP 해제 없이 대부분 정리할 수 있습니다. DNS 스택 전체의 그림은 Meta 코어 DNS 유출 방지 가이드가 담당하고, 본 글은 그중 한 줄짜리 설정 키에 초점을 맞춘 보조편이라 생각하면 읽기 쉽습니다.

다른 프록시 도구에 비해 Clash Meta 계열은 로그와 정책 이름의 대응이 비교적 읽기 쉬워, 한 번 예외 목록을 팀과 공유해 두면 이후 온보딩 비용이 줄어듭니다. GUI마다 YAML 편집 경로는 다르지만, 저장 후 짧은 검증 루프는 동일합니다.

Clash를 무료로 다운로드하고, fake-ip-filter를 적용해 LAN·직접 DNS를 FakeIP와 분리해 보세요

Clash Meta / Mihomo 클라이언트 FakeIP · fake-ip-filter

fake-ip-filter로 내부 IP와 직접 연결 도메인을 제외하면, NAS·프린터 등 LAN 장치가 FakeIP에 영향받지 않고 프록시 분류와 공존할 수 있습니다.

LAN 제외

내부 도메인을 FakeIP에서 보호

정밀 화이트리스트

직접 연결 도메인을 필요에 따라 기재

DNS 가이드

FakeIP·DoH 글 함께 참조

이전 / 다음 글

관련 글

fake-ip-filter

LAN 이름을 필터에 넣고 로그로 응답 대역을 확인하면 FakeIP를 끄지 않고도 NAS·공유기 UI를 살릴 수 있습니다. 클라이언트는 공식 다운로드에서 받으세요.

무료 다운로드