어떤 증상을 이 글이 다루나요?
Clash·미호모 계열을 켠 뒤에만 다음과 같은 패턴이 보일 때가 대표적입니다. 브라우저 주소창에 내부 호스트 이름을 넣었을 때 «사이트에 연결할 수 없음»이 뜨거나, 같은 Wi-Fi에서 Clash를 끄면 바로 열리는 관리 페이지가 켜진 상태에서는 영원히 로딩만 도는 경우입니다. 또 해외 사이트는 빠른데 특정 국내 도메인만 간헐적으로 실패한다면, 애플리케이션이 가짜 IP(fake-ip)를 받은 뒤 규칙 매칭·실제 연결 단계에서 어긋나는 시나리오도 흔합니다.
안드로이드에서 구독 후 노드가 전부 타임아웃처럼 보이는 경우는 권한·분 앱·TUN 등 다른 축이 앞서는 편이라, 같은 칼럼의 Android 7단계 점검 글과 역할을 나눕니다. 여기서는 데스크톱·공통 YAML에서 DNS 모드 선택과 로컬·내부망 호환에 초점을 맞춥니다.
fake-ip와 redir-host, 한 줄로 무엇이 다른가요?
fake-ip는 애플리케이션이 이름 해석을 요청했을 때 Clash가 먼저 응답해 주고, 그 뒤에 백그라운드에서 실제 IP를 맞춰 가는 방식에 가깝습니다. 연결을 빠르게 시작하려는 장점이 있지만, 앱이 «이미 받은 IP»에 의존해 동작하는 경우 로컬 전용 이름·스플릿 DNS 환경과 섞이면 기대와 다른 경로로 붙으려다 실패하는 일이 생깁니다.
redir-host(또는 문서·버전에 따라 표기는 다를 수 있으나 개념은 동일)는 상대적으로 전통적인 흐름에 가깝게, 실제 응답을 바탕으로 호스트 이름과 IP의 대응을 맞추는 쪽입니다. 로컬·사내망과의 궁합은 좋아지는 대신, DNS 서버 선택이나 오염·지연에 더 민감해질 수 있어 nameserver 구성이 함께 중요해집니다.
fake-ip에서 자주 깨지는 경우: 로컬·내부망·특수 DNS
라우터 별칭(router.local 등), NAS, 프린터, 사내 인트라넷 포털처럼 공인 DNS에 없는 이름은 fake-ip 경로에서 특히 잘 갈라집니다. 애플리케이션이 Clash가 돌려준 주소를 그대로 쓰는 동안 실제로는 다른 인터페이스·다른 리졸버를 타야 하는 트래픽이면, 증상은 «프록시만 켜면 내부 자원이 안 보인다»로 압축됩니다.
일부 국내 사이트나 CDN 분기가 복잡한 도메인은 규칙 순서·GEOIP·DNS 응답이 한꺼번에 얽혀, fake-ip 아래에서만 이상하게 보이기도 합니다. 이때는 노드를 바꾸기 전에 이름이 어디에서 해석되는지를 먼저 분리해 보세요. OS의 «고정 DNS»나 브라우저의 «DNS over HTTPS만 사용» 같은 옵션이 켜져 있으면 Clash DNS와 이중으로 싸우는 경우도 있으니, 점검 시에는 잠시 기본값으로 돌려 비교하는 것이 좋습니다.
redir-host로 바꿀 때 같이 봐야 할 것
모드만 바꾸고 nameserver 목록이 불안정하면, 오히려 전체 웹이 느려지거나 특정 회선에서만 간헐 실패가 늘 수 있습니다. 신뢰할 수 있는 업스트림(예: ISP DNS, 공인 리졸버)을 2개 이상 두고, 클라이언트 로그에서 DNS 타임아웃 메시지가 반복되는지 확인하세요. 회사망처럼 내부 리졼버를 반드시 써야 하는 환경이라면, 그 서버를 nameserver에 포함시키되 누출·우회 정책과의 균형은 조직 보안 규정에 맞춰 조정해야 합니다.
IPv6가 활성화된 환경에서는 AAAA 응답과 경로 선택이 얽혀 «브라우저만 실패»처럼 보이기도 합니다. 의심될 때는 일시적으로 IPv6를 끄거나, 규칙에서 IPv6 관련 트래픽을 명시적으로 다루는지 프로필 전체를 함께 보는 편이 안전합니다.
점검 순서: 한 번에 하나씩 배제하기
아래 순서는 현장에서 재현을 빨리 끊기 위해 자주 쓰는 흐름입니다. 각 단계마다 «Clash를 완전히 끈 상태»와 비교해 차이가 있는지 메모해 두면, 나중에 YAML을 정리할 때도 근거가 남습니다.
- 증상 범위를 나눕니다. 내부 호스트만인지, 특정 TLD만인지, 전체 HTTP인지 HTTPS만인지.
- DNS enhanced-mode를 fake-ip에서 redir-host로 바꾼 뒤 동일 증상인지 확인합니다.
- fake-ip-filter(또는 동등 옵션)에 로컬·사내 접미사, 라우터 호스트, mDNS 관련 이름을 넣어 재시험합니다.
- rules 앞쪽에
IP-CIDR사설 대역과 사내DOMAIN-SUFFIX를DIRECT로 두었는지 확인합니다. - OS·브라우저의 고정 DNS·DoH를 끄고 다시 시험합니다.
- TUN·시스템 프록시를 동시에 켠 상태라면, TUN과 시스템 프록시 차이 점검 글의 순서로 트래픽이 실제로 어디로 나가는지 확인합니다.
YAML에서 자주 쓰는 패턴과 주의점
프로필마다 키 이름이 조금씩 다를 수 있으므로, 구독 제공자 문서와 사용 중인 코어 버전 설명을 함께 보는 것이 안전합니다. 다만 개념은 공통입니다. 로컬 전용 이름은 가능하면 이름 해석 단계에서 Clash 밖의 리졼버로 보내거나, fake-ip를 쓰더라도 필터로 예외를 두어 실제 IP를 받게 합니다. 사내망 대역은 규칙 상단에서 DIRECT로 빼 두면 애플리케이션이 어떤 DNS 응답을 받았는지와 관계없이 경로가 안정됩니다.
중요한 것은 «한 줄 추가로 끝나는 마법»보다, 어떤 트래픽이 어떤 순서로 매칭되는지를 로그와 함께 확인하는 습관입니다. 정책 그룹·Rule Providers를 손보는 일반적인 흐름은 YAML 규칙 분기 가이드와 이어서 읽으면 설정 전체가 한 덩어리로 정리됩니다.
증상별로 우선 의심할 항목
| 증상·상황 | 우선 확인 |
|---|---|
| 공유기·NAS 같은 내부 이름만 실패 | fake-ip → redir-host 테스트, fake-ip-filter, DIRECT·사설 대역 규칙 |
| Clash 끄면 즉시 정상 | DNS 모드, OS 고정 DNS, TUN·시스템 프록시 중복 |
| 특정 국내 사이트만 간헐 실패 | nameserver 지연·오염, IPv6 경로, 규칙 순서와 GEOIP |
| 터미널은 되는데 브라우저만 이상 | 브라우저 DoH, 확장 프로그램 프록시, Secure DNS 설정 |
마무리
Clash DNS 모드는 구독 한 줄로 끝나는 화려한 기능이라기보다, 매일 쓰는 로컬 이름과 내부망까지 포함해 네트워크를 어떻게 해석할지 정하는 바닥입니다. fake-ip는 속도와 규칙 매칭 측면에서 강점이 있지만, 사내망·로컬 전용 호스트와 맞물릴 때는 redir-host나 필터·DIRECT 예외로 손보는 편이 체감 안정성에 크게 도움이 됩니다. 위 순서대로 좁히면 «노드가 나빠서»가 아니라 «이름과 경로가 어긋나서」인 경우를 빨리 구분할 수 있습니다.
같은 Clash 계열라도 GUI마다 DNS 메뉴 이름이 다릅니다. 반복 시행착오를 줄이려면, 한 화면에서 프로필·코어·모드를 정리해 주는 빌드를 고르는 것도 실사용 만족도에 영향을 줍니다. ClashNote 다운로드 페이지에서는 여러 플랫폼용 클라이언트를 한곳에서 비교할 수 있습니다.
스트리밍·AI·개발 도구처럼 시나리오별 분기가 필요하면 기술 칼럼 목록에서 주제별 글을 이어서 보시면 설정 흐름이 자연스럽게 연결됩니다.