1. 증상 정리: fake-ip 의심 신호
fake-ip의 핵심 동작은 로컬 DNS 질의 단계에서 규칙에 맞는 도메인에 대해 가상 IPv4 주소를 돌려주는 것입니다. 보통 설정의 fake-ip-range(예: 198.18.0.1/16 같은 예약 대역) 안에 들어가는 값이고, 실제 원격 IP로의 이름 해석은 연결이 맺어진 뒤 커널이나 프록시 쪽에서 이어집니다. 대부분의 웹사이트는 이 덕분에 더 매끄럽게 동작하지만, 특정 앱이나 사이트가 가짜 IP를 받은 뒤에도 자기만의 방식으로 재해석하거나 인증서·SNI를 엄격히 검사하거나, 실제 지리·통신사 기준의 해석 결과에 의존하면 몇 군데만 이상하고 나머지는 정상인 패턴으로 나타납니다.
스스로 점검할 때는 다음을 떠올려 보세요. 주소창이 오래 하얗거나 로딩만 돈다. 은행·공공·기업 포털처럼 보안이 빡센 사이트가 프록시를 켠 뒤에만 막힌다. 게임 런처·음성·화상이 네트워크 오류를 낸다. HTTPS에서 인증서와 도메인이 맞지 않는다는 경고가 난다. 터미널만 이상하거나 특정 앱만 이상한데 같은 PC의 브라우저는 다른 사이트를 잘 본다. fake-ip를 끄고 redir-host 등으로 바꾸면 즉시 나아진다면, 원인은 가짜 주소 경로나 필터 목록 쪽을 의심하는 편이 맞고, 단순히 노드가 죽었다고 보기 어렵습니다.
이 접근은 Perplexity 분기와 DNS를 다룬 글에서 말한 것과 같은 맥락입니다. 규칙이 맞는지 보기 전에 도메인 해석 이상을 먼저 분리해 내고, 목록을 고칠지 DNS를 고칠지 결정하는 순서가 실무에서 훨씬 덜 헛돕니다.
2. 대조 실험: fake-ip와의 상관 확인
큰 설정을 뜯기 전에 최소 대조로 인과를 고정하는 것이 좋습니다. 첫째, 문제가 나는 호스트명에 대해 클라이언트 로그나 연결 미리보기에서 해석 결과가 fake-ip-range 안에 들어가는지 봅니다. 둘째, dns.enhanced-mode(또는 사용 중인 커널의 동등한 항목)를 fake-ip에서 redir-host로 잠시 바꾼 뒤 설정을 다시 불러오고 같은 URL을 다시 열어 봅니다. 이상이 사라지면 문제 사슬이 fake-ip 동작과 연결된다고 볼 수 있고, 이후에는 fake-ip-filter와 DNS에 집중하면 됩니다.
셋째(선택): fake-ip를 유지한 채 시스템이나 브라우저만 Clash DNS를 우회하게 해 비교합니다(테스트 기기에서만 공용 DNS를 잠깐 지정하는 식). 우회 후 사이트가 살아나면 병목은 Clash DNS 업스트림, 가로채기 순서, 폴백 쪽에 있을 가능성이 크고, 그래도 실패하면 규칙·노드·스니퍼 층으로 되돌아가야 합니다.
3. fake-ip-filter: 실제 IP가 필요한 도메인
fake-ip-filter(일부 템플릿에서는 fake-ip-filter 아래 도메인 목록이나 nameserver-policy와 조합해 쓰기도 합니다)의 역할은 목록에 있는 도메인에는 fake-ip를 쓰지 않고 실제 해석 결과를 돌려준다는 것입니다. 한 줄 빠져 있으면 그 도메인은 클라이언트 입장에서 계속 가짜 주소로만 보이게 되고, 앞에서 말한 호환성 문제가 터지기 쉽습니다.
필터에 넣기 좋은 유형
- 랜과 순수 내부망 호스트:
*.local, 공유기 관리 주소, NAS, 프린터, 사내 포털 등. 가짜 IP는 실제 L2·L3 경로와 맞지 않습니다. - 인증서 검증이 매우 엄격한 서비스: 일부 인터넷뱅킹·결제·전자정부·제로트러스트 접속은 핸드셰이크 단계에서 특정 해석 경로나 인증서 고정(pinning)에 묶여 있어 fake-ip에서 실패하거나 리다이렉트가 무한히 이어질 수 있습니다.
- 실제 CDN 에지 스케줄에 민감한 사이트: DNS 단계에서 가장 가까운 주소를 받아야 하는 소수 사이트는, 오래 고정된 가짜 주소만 받으면 지연·타임아웃처럼 보일 수 있습니다(클라이언트 구현에 따라 다름).
- 직접 연결이나 특정 지역 최적화로 알려진 도메인: 규칙상 직접 연결이어도 fake-ip를 타면 직접 출구와 가짜 목적지 의미가 어긋날 수 있어, 이런 도메인은
fake-ip-filter에 넣으면 경계 상황이 줄어듭니다.
설정 예시(필드명은 사용 커널 문서 기준)
아래는 구조만 보여 주는 예이며, 키 이름은 Mihomo / Meta 최신 문서를 따르세요. 구독을 합칠 때 dns: 블록이 중복되지 않게 주의합니다.
dns:
enable: true
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.1/16
fake-ip-filter:
- "*.lan"
- "*.local"
- "+.msftconnecttest.com"
- "stun.*.*"
- "+.srv.nintendo.net"
# fake-ip와 충돌하는 호스트는 아래에 추가실무에서는 문제 사이트의 루트 도메인, 로그인 리다이렉트 도메인, 정적 자원 도메인, WebSocket 도메인을 개발자 도구 네트워크 탭에서 모아 한 줄씩 필터에 넣고 DNS를 다시 불러오거나 커널을 재시작한 뒤 다시 테스트합니다. 목록이 길어지면 geosite나 규칙 세트로 묶은 다음 예외만 손대는 방식이 관리에 유리합니다.
fake-ip-filter는 광고 차단 목록이 아닙니다. 목적은 호환성이고, 남용하면 fake-ip의 이점이 줄어듭니다. 문제가 확인된 도메인만 넣는 습관을 유지하세요.
4. DNS: nameserver·폴백·해석 순서
fake-ip-filter가 맞아도 DNS 블록 자체가 불안정하면 가끔 안 열리거나 특정 이동통신망에서만 깨지는 식으로 보일 수 있습니다. 위에서 아래로 링크를 따라 점검하는 것이 좋습니다.
nameserver 도달 여부
Clash에 넣은 DoH·DoT·UDP DNS가 지금 네트워크에서 차단되지 않는지 확인하세요. 기업망·캠퍼스·일부 통신사는 비표준 포트나 특정 DoH 호스트를 건드려 간헐적 해석 실패를 만듭니다. 다른 업스트림 세트로 잠시 바꿔 A/B를 해 보면 원인이 따라오는지 금방 감이 옵니다.
fallback과 fallback-filter
주 업스트림이 오염되거나 이상한 값을 줄 때 fallback이 실제로 타는지, fallback-filter의 geoip·도메인 조건이 과하지 않은지에 따라 fake-ip 상황에서도 잘못된 대륙·잘못된 회선 정보를 미리 받는 경우가 있습니다. 공격적으로 잘라 둔 템플릿을 복사했다면 공식 예시와 대조해 한 줄씩 이해한 뒤 다듬는 편이 안전합니다.
nameserver-policy와 도메인별 업스트림
국내 사이트와 해외 사이트를 섞어 쓸 때 nameserver-policy로 특정 접미사를 지정 DNS에 넘기면, 전역 단일 업스트림보다 안정적인 경우가 많습니다. 이는 WSL2와 DNS를 다룬 글에서 강조한 해석 경로를 층으로 나눈다는 말과 같은 줄기입니다. 먼저 질의가 올바른 업스트림에 닿는지 확정한 다음 fake-ip 여부를 논의하는 순서가 맞습니다.
| 현상 | 우선 확인 |
|---|---|
| 특정 도메인만 이상 | fake-ip-filter에 넣어야 하는지, CNAME 체인이 규칙 세트에서 빠졌는지 |
| 네트워크를 바꾸면 나아짐 | 현재 망에서 DNS 업스트림이 가로채이거나 속도 제한을 받는지, DoH 호스트가 막혔는지 |
| 인증서 오류·SNI 관련 로그 | 스니퍼가 과하게 개입했는지, TUN과 시스템 인증서 정책이 충돌하는지(다음 절) |
5. 스니퍼와 인증서: 좁히기·일시 끄기
스니퍼(sniffer)는 트래픽이 암호화된 뒤에도 TLS Client Hello 등에서 도메인을 복원해, 평문 Host를 볼 수 없을 때도 규칙 엔진이 분기할 수 있게 돕습니다. fake-ip와 함께 켜 두는 경우가 많고, 둘이 겹치면 스니퍼 범위가 넓거나 특정 사이트의 핸드셰이크 특성과 맞지 않을 때 인증서 경고, 중간 리셋, HTTP/2·QUIC 이상 동작처럼 보일 수 있습니다.
점검 순서는 로그에서 문제 연결이 스니퍼 경로를 타는지 확인하고, 스니퍼를 필요한 프로토콜·포트로만(예: 특정 인바운드만, TCP 443만) 좁힌 뒤 오탐을 걷어 냅니다. 그래도 설명이 안 되면 짧게 스니퍼를 끄고 대조해 보세요. 끄면 나아지면 fake-ip를 먼저 끄기보다 스니퍼 규칙을 먼저 다듬는 편이 낫습니다.
일부 데스크톱 클라이언트는 자동 스니퍼를 시스템 프록시·TUN과 묶어 둡니다. 바꾼 뒤에는 시스템 프록시 서비스나 가상 NIC를 재시작해 이전 프로세스가 옛 동작을 유지하지 않게 하는 것이 좋습니다.
6. TUN·시스템 프록시·다른 클라이언트와의 중첩
TUN 모드와 fake-ip를 같이 켜면 시스템 라우팅, 기본 DNS, Clash 내부 DNS가 이중 고리를 이룰 수 있습니다. 시스템은 DNS가 로컬의 어떤 주소라고 믿는데, Clash는 앱이 연결을 열어야 비로소 원격 해석을 끝내는 식입니다. 겉보기 증상은 순수 fake-ip 문제와 비슷하지만, 고치는 위치는 라우팅 제외, 대륙 우회, DNS 하이재킹 스위치 쪽인 경우가 많습니다. TUN·라우팅·방화벽 점검 글과 함께 보아 TUN이 전역 단절이나 루프를 만들지 않는지 먼저 확인한 뒤, 이 글의 필터·DNS 목록으로 돌아오면 순서가 깔끔합니다.
같은 머신에 다른 VPN, 기업 보안 프록시, 게임 부스터가 같이 돌면 가상 NIC 우선순위 싸움으로 소수 도메인만 잘못된 스택을 탈 수 있습니다. 문제 앱 안에서 독립 프록시를 끄거나 우선순위를 조정해 출구 경로가 하나로 명확해지게 만드는 것도 실무에서 자주 필요합니다.
장기적으로는 fake-ip-filter에 넣은 도메인과 이유(인증서, 내부망 해석, CDN 스케줄 등)를 로컬 메모에 남겨 두세요. 구독을 갱신하거나 클라이언트를 바꿔도 같은 함정을 반복하지 않기 쉬워집니다.
7. 요약
Clash fake-ip는 많은 경우 연결 수립을 빠르게 해 주지만, 일부 사이트만 안 열린다는 증상은 흔히 노드 한 대의 고장이 아니라 fake-ip-filter 미포함, DNS 업스트림·폴백 불안정, 스니퍼와 TLS 동작이 겹친 호환성 문제입니다. 대조 실험으로 고정한 뒤 필터를 보강하고, DNS를 점검하고, 스니퍼를 좁히고, TUN을 맞추는 순서로 가면 전체 경험을 크게 해치지 않고 국소적으로 고칠 수 있는 경우가 많습니다.
조각난 검색을 반복하기보다 이상이 난 도메인을 위 분류 중 어디에 해당하는지 적어 두면 설정은 시간이 갈수록 단단해집니다. 신뢰할 수 있는 클라이언트와 기본 템플릿을 찾고 싶다면 먼저 사이트의 설정 문서를 읽고 구독을 가져온 다음, 이 글의 순서로 DNS와 fake-ip 구간을 맞추면 됩니다.
Clash 계열은 규칙·DNS·여러 모드의 조합에 대한 문서와 커뮤니티 사례가 풍부한 편입니다. fake-ip와 실제 해석의 경계를 정리해 두면 일상 브라우징과 개발 도구 모두 안정감이 올라갑니다.