왜 라우터 계층에서 OpenClash인가

터미널마다 프록시를 켜거나, 각 OS에 클라이언트를 설치하는 방식은 관리 지점이 많아집니다. 반면 OpenWrt 위에서 OpenClash(Clash Meta/Mihomo 계열을 다루는 LuCI 플러그인)을 쓰면, DHCP로 주소를 받는 TV·콘솔·IoT까지 동일한 분기 규칙을 적용하기 쉽습니다. “공유기 한 대만 조작하면 집 전체가 같은 DNS·같은 출구 정책을 본다”는 점이 가장 큰 이유입니다. 다만 라우터는 잘못 건드리면 전체 단말이 동시에 오프라인이 될 수 있으므로, 설정 전에 WAN/LAN 백업과 콘솔(시리얼)·복구 이미지를 확보하는 습관이 필요합니다.

데스크톱·모바일 단독 가이드와의 차이는 명확합니다. 이 글은 터미널 쪽 Fake-IP 우회보다 게이트웨이·DNS 체인에 초점을 둡니다. 단말 공유와 방화벽 이슈는 LAN 공유·바인딩 가이드를, 클라이언트 종류 비교는 클라이언트 선택과 함께 보시면 맥락이 이어집니다.

ℹ 핵심: OpenClash가 아무리 잘 떠 있어도, LAN 단말의 기본 게이트웨이가 OpenWrt를 가리키지 않으면 트래픽이 코어에 들어오지 않습니다. 먼저 ip route와 DHCP 옵션부터 확인하세요.

브리지 모드와 게이트웨이: 트래픽이 지나가는 실제 경로

상위 공유기 뒤의 브리지(AP)

OpenWrt 장치를 브리지에 가깝게 두면, 무선 AP 역할만 하고 게이트웨이는 상위 박스가 잡는 구성이 됩니다. 이 경우 Clash가 개입하려면 (1) 상위에서 DHCP로 DNS만 OpenWrt로 보내거나, (2) 상위의 DMZ·정적 라우팅으로 특정 대역을 OpenWrt 쪽으로 넘기는 식의 설계가 필요합니다. “브리지라서 OpenClash가 자동으로 모든 패킷을 본다”는 가정은 흔히 틀립니다. 실제로는 어느 홉에서 NAT가 일어나는지가 전부입니다.

직접 WAN을 잡는 라우터

OpenWrt가 PPPoE나 상위 LAN에서 WAN을 받고, LAN 단말의 기본 경로가 OpenWrt인 전형적인 가정용 구성에서는, 방화벽 영역(lan → wan)과 포워딩만 열려 있으면 나머지는 OpenClash의 리다이렉트/TUN/메타 설정에 따라 투명하게 붙일 수 있습니다. 이때 중요한 것은 중복 NAT와 이중 DHCP입니다. 상위와 하위가 둘 다 DHCP 서버를 켜 두면 게이트웨이가 매번 달라져 “어제는 됐는데 오늘은 안 된다” 패턴이 납니다.

OpenWrt 준비: 인터페이스·방화벽·저장 공간

OpenClash는 코어 바이너리·규칙 세트·로그를 저장합니다. 오버레이 여유가 부족하면 업데이트나 규칙 다운로드가 실패합니다. df -h로 /overlay를 확인하고, 필요하면 extroot·USB 오버레이를 검토하세요. 인터페이스 이름(br-lan, eth0 등)은 보드마다 다르므로, LuCI의 Network → Interfaces에서 실제 이름을 메모해 두고 OpenClash의 “바인딩/감지 인터페이스” 옵션에 그대로 넣는 편이 안전합니다.

방화벽 측면에서는 OpenClash가 DNS나 프록시 포트를 열 때 입구 존이 LAN에 한정돼 있는지, 관리 포트(SSH·LuCI)가 잠겨 있는지 확인합니다. 외부 WAN에서 관리 웹이 열려 있으면 위험하므로, 기본적으로 LAN만 허용하는 정책을 유지하는 것이 좋습니다.

OpenClash 설치와 코어 선택(개요)

설치 경로는 배포판·아키텍처·저장소 상태에 따라 다릅니다. 일반적으로는 사전 빌드된 ipk를 받아 opkg install하거나, 프로젝트 문서에 맞는 소스를 추가한 뒤 패키지를 올립니다. 버전이 바뀔 때마다 의존 라이브러리(libopenssl 등) 호환을 확인해야 합니다. 코어는 Meta(Mihomo) 계열을 선택하는 경우가 많고, LuCI에서 바이너리 경로와 업데이트 채널을 지정합니다.

설치 직후에는 “구독 URL이 맞는지, 다운로드가 끝났는지, 코어가 실제로 기동했는지”를 로그로 확인합니다. 구독·노드 운영 원칙은 구독 관리 가이드와 같이 읽으면 정리가 쉽습니다. 오픈소스 릴리스·이슈 트래커는 참고용으로 두고, 일반 사용자용 클라이언트 패키지는 사이트 다운로드 페이지를 기본 경로로 삼는 편이 혼동이 적습니다.

⚠ 주의: 펌웨어·패키지는 공식 채널과 체크섬을 확인하세요. 출처 불명 이미지나 ipk는 장치를 brick 시킬 수 있습니다.

LAN DHCP와 기본 게이트웨이 정렬

OpenWrt가 LAN의 기본 게이트웨이라면, DHCP 서버 옵션에 게이트웨이가 OpenWrt LAN 주소로 찍혀야 합니다. 상위 공유기가 게이트웨이인 이중 구조에서는, 테스트 단말에서 ip route(또는 설정 화면의 “라우터 주소”)를 보고 첫 번째 홉이 어디인지 먼저 적습니다. OpenClash가 “켜졌는데 안 잡힌다”는 경우의 절반은 트래픽이 애초에 그 장치를 안 지나간다는 사실에서 출발합니다.

고정 IP를 쓰는 NAS나 프린터가 있다면, 예외 목록과 충돌하지 않게 대역을 나누고, 게이트웨이/DNS를 수동으로 박아 둔 단말이 있는지도 점검합니다. 수동 DNS가 공용 DNS로만 가 있으면, 라우터에서 DNS를 가로채도 클라이언트가 우회할 수 있습니다.

DNS: dnsmasq, 하이재킹, Clash DNS 모듈

OpenWrt는 기본적으로 dnsmasq가 LAN의 DNS 응답을 담당하는 경우가 많습니다. OpenClash와 연동할 때는 “53번을 누가 듣는가”가 핵심입니다. 흔한 패턴은 dnsmasq가 업스트림으로 Clash의 DNS를 바라보게 하거나, 방화벽으로 DNS 리다이렉트를 걸어 Clash 쪽으로 보내는 방식입니다. 어느 쪽이든 루프에 빠지지 않게 순서를 맞춰야 합니다(Clash가 받은 질의를 다시 자기 자신에게만 돌리는 형태).

Clash Meta 계열의 dns 블록—nameserver, fallback, fake-ip-filter—은 데스크톱 글과 동일한 개념이지만, 라우터에서는 전체 LAN이 같은 DNS 정책을 공유합니다. 세부 키와 순서는 Clash Meta DNS 가이드를 기준으로 두고, OpenClash 화면의 “DNS 설정/모드”와 대조해 맞추면 됩니다. FAQ의 DNS 항목도 함께 보면 도움이 됩니다(FAQ).

개념 정리(실제 키는 코어·GUI 버전에 맞출 것) 
# dnsmasq upstream → Clash DNS listen address
# 또는 firewall REDIRECT 53 → clash-dns-port
# loop 방지: clash가 받는 upstream은 외부 리졸버로

국내·본토 직접 연결: GEOIP, RULE-SET, 정책 순서

“중국 본토·국내 사이트는 프록시를 타지 않게” 하려면 규칙이 먼저 매칭되도록 배치해야 합니다. 일반적으로 GEOIP나 RULE-SET으로 CN·국내 CDN 대역을 DIRECT로 보내고, 나머지를 프록시 정책 그룹으로 넘깁니다. 규칙 파일이 오래되면 오판이 나므로, 프로바이더·커뮤니티에서 권장하는 세트를 주기적으로 갱신합니다.

정책 그룹 안에서 url-test·fallback을 쓰는 방법은 정책 그룹·지연 가이드와 연결됩니다. 분기 자체의 큰 그림은 규칙 라우팅 모범 사례에서 다루는 “위에서 아래로 첫 매칭” 원칙과 같습니다. 라우터에서 한 번 맞춰 두면 PC마다 동일한 YAML을 반복 편집할 필요가 줄어듭니다.

Fake-IP를 쓸 때 라우터에서의 주의점

Fake-IP 모드는 응답 속도와 규칙 일관성에 유리한 대신, LAN에서 특정 IP 대역이 “가짜”로 보일 수 있습니다. 라우터 뒤 단말이 같은 이름에 다른 IP를 캐시하면, 관리 페이지나 로컬 호스트 접속이 꼬일 수 있습니다. 이때는 fake-ip-filter에 사설·로컬 도메인을 넣거나, 일시적으로 redir-host 계열로 바꿔 검증합니다. 구체적인 LAN·공유기 예외는 Fake-IP·라우터 우회 가이드를 참고하세요.

대표 증상과 점검 순서

  1. 인터넷 전체 단절 — OpenClash를 끄면 복구되는지 확인. 끄면 복구면 코어·리다이렉트·TUN 충돌을 의심합니다.
  2. DNS만 느리거나 실패 — 53 포트 점유, dnsmasq와 Clash의 순환, fallback이 프록시에만 의존하는지 봅니다.
  3. 국내 사이트만 느림 — DIRECT 규칙이 앞에 있는지, 잘못된 GEOIP/RULE-SET인지 확인합니다.
  4. 특정 단말만 예외 — 해당 단말이 수동 게이트웨이/DNS를 쓰는지, VLAN·게스트 Wi‑Fi로 다른 DHCP를 쓰는지 확인합니다.

원격 노드·TLS 쪽 이슈는 증상이 비슷해 보이므로, timeout·TLS 로그 가이드의 분리 방법을 그대로 적용할 수 있습니다. 로그에서 “어떤 규칙에 매칭됐는지”가 보이면, 라우터 문제인지 업스트림인지 빠르게 갈립니다.

맺음말

OpenWrt + OpenClash는 “한 번 제대로 깔면 집안 전체가 같은 분기를 본다”는 장점이 있습니다. 반면 게이트웨이·DNS·방화벽이 한꺼번에 얽혀 있어, 증상도 크게 보입니다. 브리지인지 라우터인지부터 고정하고, DHCP와 수동 IP를 점검한 뒤 DNS 체인과 규칙 순서를 맞추면 재현 가능한 운영이 됩니다. 라우터 밖에서 동일한 규칙을 편집·검증할 때는 PC용 클라이언트가 편할 수 있으니, 워크플로를 나눠 두는 것도 방법입니다.

→ Clash를 무료로 내려받아 데스크톱에서 프로파일을 다듬은 뒤, 검증된 설정을 라우터 쪽 OpenClash에 옮기면 실패 범위를 줄일 수 있습니다. 규칙 기반 프록시는 한 번 맞춰 두면 유지보수 리듬이 길어지는 편입니다.