어떤 상황을 가정했나요?
상위 인터넷 회선에 일반 공유기가 있고, 그 뒤에 OpenWrt 소프트라우터를 두었거나, OpenWrt 단일 공유기에서 Clash 계열 데몬이 돌아가는 형태를 염두에 둡니다. 무선으로 접속하는 휴대폰·태블릿은 DHCP로 OpenWrt의 LAN 주소를 기본 게이트웨이로 받고, 유선 연결된 워크스테이션에는 추가로 OS 수준 Clash(시스템 프록시 또는 TUN)가 켜져 있을 수 있습니다. 이 구성에서 문제는 대개 «노드 품질»보다 패킷이 어느 홉에서 어떤 규칙으로 다시 잡히는지에 있습니다.
DNS만 놓고 보면 라우터가 53번 포트를 가로채 클라이언트의 질의를 Clash로 넘기도록 해 두었는데, PC 브라우저는 DNS over HTTPS로 우회하거나, 반대로 PC Clash가 로컬 리스너를 DNS로 밀어 넣어 이중으로 감싸는 경우가 흔합니다. fake-ip 모드는 속도와 규칙 매칭에는 유리하지만, 내부 호스트명·일부 국내 사이트에서 «프록시만 켜면 깨진다» 패턴을 만들기도 합니다. 이 축은 데스크톱 단독 환경에서도 같으므로, fake-ip와 redir-host를 나누는 칼럼과 역할을 나눠 읽으면 설정 전체가 연결됩니다.
트래픽이 겹칠 때 실제로 무슨 일이 벌어지나요?
라우터 Clash가 켜진 상태에서 PC에서도 시스템 프록시만 켜면, 브라우저 트래픽이 «PC Clash → (이미 프록시된) LAN → 라우터 Clash → 업링크»처럼 연속으로 프록시 스택을 탈 수 있습니다. 대부분의 프로토콜은 한 번 더 감싸도 동작하지만, 지연·MTU·인증 헤더·일부 스트리밍·게임 UDP에서 이상 증상이 나올 여지가 있습니다. TUN 모드를 PC에서까지 켜면 OS 라우팅 테이블에 가상 인터페이스가 올라가 기본 경로 자체가 바뀌므로, «공유기 관리 화면은 브라우저 직접 IP로만 열린다» 같은 현상이 동반되기도 합니다.
반대로 «라우터에서 이미 다 처리하니 PC Clash는 끄고 쓴다»는 단순 규칙이 가장 안정적인 경우가 많습니다. 다만 회사 VPN·원격 데스크톱·특정 앱만 분리 우회해야 한다면 PC 쪽을 유지해야 하고, 그때는 어느 쪽이 최종 출구인지를 명확히 정하는 것이 먼저입니다. Windows·macOS에서 TUN과 시스템 프록시의 차이·권한 이슈는 TUN 점검 글의 순서를 그대로 차용해 트래픽 경로를 확인할 수 있습니다.
1단계: DHCP 기본 게이트웨이가 가리키는 장치부터 확인
OpenWrt LuCI의 DHCP 설정에서 내려보내는 기본 게이트웨이(option router)와 DNS(option dns-server)는 모든 클라이언트의 출발점이 됩니다. 여기가 의도치 않게 상위 ISP 공유기를 가리키면, 클라이언트는 OpenWrt의 Clash를 아예 건너뛰고 나가거나, 반대로 이중 경로로 ICMP가 꼬일 수 있습니다. 스마트폰에서 «Wi-Fi 상세」·Windows에서 ipconfig /all·macOS에서 네트워크 세부정보로 기본 게이트웨이 한 줄이 무엇인지 먼저 메모해 두세요.
정적 DHCP 예약을 쓰는 경우, 특정 PC만 다른 게이트웨이를 받도록 잘못 저장해 두었는지도 확인합니다. 가정에서는 거의 항상 OpenWrt LAN IP 하나로 통일하는 편이 디버깅에 유리합니다. «공유기 뒤에 공유기» 구조라면 아래 이중 NAT 절을 같이 읽어 상위에서 DMZ·브리지가 필요한지 판단합니다.
2단계: 라우터 DNS 강제와 PC 쪽 DNS가 싸우지 않게
OpenClash·유사 패키지는 종종 dnsmasq 앞단에서 53번을 Clash로 넘기거나, DHCP 옵션으로 라우터 자신의 LAN IP를 DNS로 줍니다. 이 상태에서 PC Clash도 로컬 DNS 리스너를 켜고 OS DNS를 그 주소로 바꾸면, 질의가 «OS → PC Clash → 라우터 Clash → 업스트림»으로 길어집니다. 대개 동작하지만, 한쪽에서 NXDOMAIN·타임아웃 정책이 다르면 «모바일만 되고 PC만 특정 도메인 실패»처럼 갈립니다.
브라우저의 보안 DNS(HTTPS)가 켜져 있으면 라우터의 DNS 하이재킹을 옆길로 빠져나가 규칙 분기와 실제 연결이 어긋날 수 있습니다. 점검할 때는 잠시 끄고 비교하는 것이 비용 대비 효과가 큽니다. IPv6가 활성화되어 있으면 AAAA 경로가 별도로 열려 «IPv4만 프록시» 설정과 섞일 때 이상 증상이 나기도 하므로, 재현이 IPv6 의심이면 일시적으로 끄고 같은 테스트를 반복해 보세요.
3단계: fake-ip와 사설망·로컬 이름
라우터 쪽 Clash에서 fake-ip를 쓰면 내부 전용 이름(.local, NAS 호스트명, 사내 포털)이 공인 DNS에 없을 때 응답이 어긋나기 쉽습니다. OpenWrt 환경에서는 공유기 관리 UI·프린터·스마트 홈 기기가 같은 증상을 보이기도 합니다. 이때는 redir-host로 바꿔 재현이 사라지는지 먼저 보거나, fake-ip-filter에 내부 접미사와 라우터 호스트를 넣고, 규칙 상단에 사설 대역·내부 DOMAIN-SUFFIX를 DIRECT로 두는 패턴이 안전합니다. 세부 YAML 흐름은 규칙 분기 가이드와 맞춰 정리하면 유지 보수가 쉬워집니다.
PC Clash까지 켜 둔 상태에서만 로컬 이름이 깨진다면, PC 쪽 DNS 모드·TUN의 exclude 목록에 사설 대역이 들어가 있는지도 함께 봅니다. «한쪽만 고치면 다른 쪽에서 다시 덮어쓴다»는 패턴이 잦습니다.
이중 NAT와 «상위 공유기 + OpenWrt»
많은 가정에서 ISP 모뎀·기본 공유기 뒤에 OpenWrt 박스를 두는데, 이때 두 장치 모두 NAT를 하면 이중 NAT가 됩니다. Clash 자체와는 별개이지만, 포트 개방·원격 접속·일부 P2P·콘솔 NAT 타입에서 문제를 키웁니다. 가능하면 상위를 브리지 모드로 두어 OpenWrt가 공인을 직접 받게 하거나, 최소한 상위에서 OpenWrt WAN을 DMZ로 고정하는 식으로 한 겹만 NAT가 되게 정리하는 것이 좋습니다.
Clash·OpenClash 설정에서 로컬 네트워크 bypass 목록을 넓게 잡아 두었는데도 특정 앱만 끊긴다면, 실제로는 상위 NAT가 세션을 끊는 경우도 있습니다. 트레이스 경로와 공유기 로그를 함께 보는 편이 빠릅니다.
역할 나누기: 전원 라우터만 vs 일부는 PC만
가장 단순하고 안정적인 패턴은 집 전체는 라우터 Clash만 켜고, 데스크톱·노트북의 Clash는 끄거나 «필요할 때만 수동으로» 켜는 것입니다. 게임·원격근무 PC처럼 분할 터널링이 꼭 필요하면, 해당 PC의 DHCP DNS를 일시적으로 상위 ISP DNS로 바꿔 라우터 Clash를 건너뛰게 하거나, 반대로 PC Clash만 신뢰하고 라우터 쪽 우회는 끄는 식으로 한 축만 남기는 편이 디버깅에 유리합니다.
소규모 사무실에서는 방문자 Wi-Fi와 사무용 SSID를 나누고, 한쪽만 우회하는 식으로 정책을 물리적으로 분리하면 운영 부담이 줄어듭니다. 문서상으로는 같은 YAML을 재사용하더라도, 어느 인터페이스의 DHCP가 어떤 DNS를 주는지를 표로 남겨 두면 나중에 인수인계가 쉽습니다.
OpenWrt·OpenClash 쪽에서 자주 만지는 체크포인트
펌웨어·플러그인 버전마다 메뉴 이름은 다르지만, 개념은 공통입니다. dnsmasq와 Clash DNS 리스너 포트가 충돌하지 않는지, iptables/nft 기반 리다이렉트가 원하는 인터페이스에만 걸려 있는지, IPv6 RA·DHCPv6가 별도 DNS를 밀어 넣지 않는지를 확인합니다. 업데이트 후에는 예전에 넣어 둔 방화벽 사용자 규칙이 남아 이중으로 돌아가는 경우도 있으므로, 변경 직후 한 번씩 서비스 재시작·재부팅으로 상태를 맞춥니다.
mihomo·Clash Meta 계열을 라우터에서 돌릴 때는 메모리·플래시 수명도 함께 고려합니다. 로그 레벨을 과하게 올려 두면 SD 카드·낸드에 부담이 가므로, 평시에는 낮게 두고 장애 재현 시에만 올리는 습관이 좋습니다.
증상별 점검 순서 요약
아래는 현장에서 빠르게 범위를 줄이기 위한 순서입니다. 각 단계마다 «라우터 Clash만 켬 / PC Clash만 켬 / 둘 다 끔» 세 가지 조합을 메모해 두면 원인 축이 분리됩니다.
- 문제 기기에서 기본 게이트웨이·DNS·IPv4/IPv6 값을 기록합니다.
- DHCP가 의도한 OpenWrt LAN인지, 상위 공유기로 새지 않는지 확인합니다.
- 브라우저·OS의 DoH·고정 DNS를 끄고 동일 증상인지 봅니다.
- 라우터 Clash DNS 모드(fake-ip / redir-host)를 바꿔 내부 이름·국내 사이트 증상이 달라지는지 확인합니다.
- PC에서 TUN·시스템 프록시를 각각 끄고 비교합니다.
- 상위·하위 이중 NAT 여부와 포트포워딩·브리지 필요성을 검토합니다.
표로 보는 빠른 대응
| 증상 | 우선 확인 |
|---|---|
| 모바일은 정상, PC만 특정 사이트 실패 | PC Clash DNS·브라우저 DoH·TUN exclude·라우터 DNS와의 이중 경로 |
| 라우터 프록시 켠 뒤 NAS·프린터 이름만 안 됨 | fake-ip → redir-host 테스트, fake-ip-filter, 사설 DIRECT 규칙 |
| 지연만 크고 끊기지는 않음 | 이중 프록시 스택, 불필요한 PC Clash 중복, 노드 체인 |
| 포트 개방·원격 접속만 안 됨 | 이중 NAT, 상위 DMZ/브리지, 방화벽 규칙 순서 |
마무리
OpenWrt에서 Clash를 돌리는 이점은 한 번 맞춰 두면 TV·폰·IoT까지 같은 정책을 공유할 수 있다는 점입니다. 그러나 같은 집 안에 데스크톱 클라이언트가 남아 있으면 게이트웨이·DNS·TUN이 조용히 겹쳐, 노드 문제로 오해되기 쉬운 증상을 만듭니다. 위 순서대로 «어느 홉에서 이름이 해석되고 어디로 패킷이 나가는지」를 먼저 분리하면 설정 시간을 크게 줄일 수 있습니다.
라우터만 쓰지 않고 PC에서도 규칙을 실험하고 싶다면, GUI·코어·프로필을 한 화면에서 정리해 주는 빌드를 고르는 것도 체감에 영향을 줍니다. ClashNote 다운로드 페이지에서는 Windows·macOS 등 여러 클라이언트를 한곳에서 비교할 수 있습니다.
스트리밍·AI·개발 도구처럼 시나리오별 분기가 필요하면 기술 칼럼 목록에서 주제별 글을 이어서 보시면 설정 흐름이 자연스럽게 연결됩니다.