어떤 증상이면 이 글을 먼저 보면 좋을까

Clash나 mihomo 계열 클라이언트에서 DNS 모드를 Fake-IP로 두었다가, 예전에는 되던 행위만 막히는 패턴이 있습니다. 브라우저에서 NAS 관리 페이지(nas.home, diskstation.local 같은 이름)가 더 이상 열리지 않거나, 파일 탐색기의 SMB 공유만 멈추고 인터넷 검색은 멀쩡한 경우가 대표적입니다. 네트워크 프린터는 “대기 중”으로 보이다가 출력 직전에 실패하거나, 스캐너 유틸리티만 계속 재연결을 시도하기도 합니다.

또 하나의 단서는 공유기나 메시 공유기의 설정 화면입니다. http://192.168.0.1처럼 숫자 주소를 직접 넣었을 때만 불안정하고, 프록시를 끄면 즉시 정상으로 돌아온다면 원인 후보가 거의 좁혀집니다. 사용자 입장에서는 “내부망이 고장 난 것처럼” 느껴지지만, 실제로는 애플리케이션이 받아든 IP와 실제 패킷이 향해야 할 목적지가 어긋난 경우가 많습니다.

Fake-IP가 로컬 장비와 부딪히는 이유

Fake-IP는 이름 해석 단계에서 도메인을 임시 가상 주소 풀(예: 198.18.0.0/15 계열)에 매핑해 두었다가, 실제 연결 시점에 원래 이름으로 다시 붙는 방식입니다. 글로벌 사이트를 빠르게 라우팅하고 규칙 엔진과 맞추기에는 유리하지만, 애플리케이션이 DNS로 받은 IP를 그대로 들고 추가 작업을 하는 경우 문제가 드러납니다.

예를 들어 어떤 NAS 클라이언트는 최초 연결 후 같은 IP로 재접속을 반복합니다. 이때 그 IP가 Fake-IP라면, 운영체제 방화벽·다른 VPN·프린터 드라이버가 보기에는 “존재하지 않는 대역과 통신”처럼 보일 수 있습니다. 반대로 브라우저는 매 요청마다 이름을 다시 물어보므로 증상이 덜한 반면, 레거시 프로토콜일수록 영향이 크다는 점이 특징입니다.

그래서 LAN 장비에는 두 가지 축이 동시에 필요합니다. 첫째, 특정 이름은 Fake-IP를 적용하지 않도록 fake-ip-filter로 빼 줍니다. 둘째, 이미 숫자 목적지(RFC1918 사설 대역)로 향하는 트래픽은 규칙 상단에서 DIRECT로 고정해 프록시 우회나 이중 라우팅을 막습니다. YAML 전반 구조와 DNS 블록 배치는 YAML 설정 가이드와 함께 보시면 수정 위치를 헷갈리지 않습니다.

RFC1918 사설 대역을 규칙으로 고정하기

가정·소규모 사무실에서 자주 쓰는 내부 주소는 표준 문서 RFC1918에 정의된 다음 세 묶음입니다. Clash의 IP-CIDR 규칙으로 통째로 예외 처리하는 경우가 많습니다.

• 10.0.0.0/8
• 172.16.0.0/12
• 192.168.0.0/16

운영 중인 프로필에 이미 비슷한 줄이 있는지 먼저 검색해 보세요. 다만 “있는데도 증상이 남는다”면 순서가 흔한 원인입니다. 지역 분류나 GEOIP 같은 넓은 규칙이 먼저 적용되어 사설 목적지가 노드로 보내지면, 내부 프린터와 NAS 세션은 중간에서 끊깁니다. 좁고 명확한 LAN 예외는 항상 매치 규칙 중 상단에 두는 습관이 안전합니다.

# Conceptual rules excerpt — keep LAN CIDR above broad MATCH / GEOIP rules
rules:
  - IP-CIDR,127.0.0.0/8,DIRECT
  - IP-CIDR,10.0.0.0/8,DIRECT
  - IP-CIDR,172.16.0.0/12,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT
  - IP-CIDR,fc00::/7,DIRECT,no-resolve
  # ... remote proxy rules ...
  - MATCH,PROXY_DEFAULT

no-resolve는 필요 시에만 붙입니다. 코어 버전과 프로필 스타일에 따라 다르니, 적용 후 로그에서 해당 줄이 의도대로 매치되는지 확인하세요.

fake-ip-filter로 이름 해석 예외 만들기

NAS 제조사나 공유기가 제공하는 로컬 호스트 이름, *.local(mDNS), 사내 도메인 등은 Fake-IP 대신 실제 주소를 받는 편이 안정적입니다. dns 섹션 안에서 fake-ip-filter(또는 클라이언트 GUI의 동일 옵션)에 다음과 같은 후보를 차례로 넣어 봅니다.

• 실제로 브라우저 주소창에 입력하는 NAS 호스트 이름 전체
• +.lan, +.local처럼 가정 내 멀티캐스트 이름 공간
• 프린터 설정 유틸이 고정으로 조회하는 업체 제공 도메인(있을 경우)

# Conceptual dns excerpt — syntax varies slightly by core / GUI export
dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "+.internal.example.com"
    - "nas-home"

구독 프로필을 통째로 덮어쓰기보다는, 로컬 오버레이 파일이나 클라이언트의 “구성 편집”에서 위 목록만 추가하는 방식이 업데이트 때 안전합니다. 필터를 넓게 잡으면 인터넷 도메인까지 실제 DNS를 타게 되어 속도가 떨어질 수 있으므로, 처음에는 증상이 난 장비 이름부터 좁혀 가세요.

프린터와 NAS에서 자주 나오는 다른 원인과 구분

Fake-IP만의 문제는 아니지만 함께 겹치면 진단이 어려워집니다. 프린터가 스마트폰 앱 경유라면 OS의 로컬 네트워크 권한이나 다른 VPN 프로필과의 충돌을 의심해야 합니다. 모바일 환경 점검 흐름은 iOS 로컬 네트워크·DNS 관련 글에서 단계적으로 다룹니다.

NAS 웹 UI만 안 되고 SMB는 된다면, 브라우저 확장 프로그램 프록시와 시스템 프록시가 갈라진 경우도 있습니다. 반대로 SMB까지 동시에 실패하면 Fake-IP·TUN·방화벽 중 하나가 공통 경로에서 막고 있을 가능성이 큽니다. 한 가지 모드로 통일한 뒤에만 규칙을 수정하면 시간을 크게 아낄 수 있습니다.

TUN 모드·시스템 프록시와 같이 쓸 때

TUN으로 전체 트래픽을 흡수하면 “규칙은 DIRECT인데도 인터페이스 선택이 꼬인다”는 사례가 나옵니다. 이때도 원칙은 같습니다. 사설 목적지에 대한 IP-CIDR 예외가 살아 있는지, 그리고 운영체제 라우팅 테이블에 더 높은 우선순위의 다른 VPN이 동일 대역을 가로채고 있지 않은지 확인합니다.

Windows에서는 어떤 앱이 시스템 프록시를 무시하고 직접 나가기도 하므로, Clash 로그의 CONNECT 목적지와 작업 관리자의 네트워크 활동을 대조해 보세요. “규칙만 고쳤는데 특정 exe만 예외”라면 프로세스 규칙을 쓰는 클라이언트도 있지만, LAN 장비 문제에는 보통 앞서 설명한 DNS 필터와 CIDR 예외만으로 충분한 경우가 많습니다.

복구 순서 체크리스트

1. 실제 로드 중인 프로필이 편집한 파일과 같은지, 구독 새로고침 후 덮어쓰이지 않았는지 확인합니다.
2. dns.enhanced-mode가 fake-ip인지 확인하고, 증상이 나는 이름을 fake-ip-filter에 하나씩 추가합니다.
3. rules 최상단 근처에 RFC1918 IP-CIDR … DIRECT 묶음이 있는지, 더 넓은 규칙보다 위인지 검토합니다.
4. 프린터·NAS 클라이언트를 재시작해 DNS 캐시를 비운 뒤 다시 시도합니다.
5. TUN 사용 시 다른 VPN·가상 스위치와 라우팅이 겹치지 않는지 확인합니다.
6. 그래도 남으면 Fake-IP를 잠시 끄고 Redundant-Host 이름만 실제 DNS로 받게 했을 때 증상이 사라지는지 비교합니다.

정리

Clash Fake-IP는 해외 서비스 이용에는 편리하지만, NAS·프린터·공유기처럼 이름과 주소가 로컬에 묶인 장비에서는 해석 경로가 살짝만 어긋나도 “내부망 전체가 고장 난 것처럼” 보일 수 있습니다. fake-ip-filter로 문제 이름을 빼 주고, RFC1918 대역은 규칙에서 확실히 DIRECT로 고정하면 대부분의 가정 환경에서 접속이 바로 안정됩니다.

코어와 GUI 조합은 최신 릴리스를 쓰는 것이 예외 처리와 로그 표현 면에서 유리합니다. 설치 패키지와 호환 매트릭스는 다운로드 페이지에서 확인할 수 있습니다. → Clash를 무료로 내려받아 프로필을 백업한 뒤, DNS 필터와 LAN IP-CIDR 줄부터 순서대로 적용해 보시기 바랍니다.