각 기기가 아닌 라우터에서 Clash를 실행하는 이유
데스크톱 클라이언트는 사용자별 실험, 동일 머신에서 상세 로그 확인, 가정의 DHCP를 건드리지 않고 TUN 캡처가 필요할 때 빛을 발합니다. 반면 라우터 배포는 통합 정책이 목표일 때 진가를 발휘합니다. 스마트폰·태블릿·TV·게임 콘솔이 APK를 사이드로드하거나 앱별 VPN 스위치를 토글할 필요 없이 동일한 분할 규칙을 자동으로 상속받습니다. OpenClash는 이러한 기능을 LuCI를 통해 노출하므로, YAML·구독·데몬을 브라우저에서 관리할 수 있습니다. SSH가 익숙하지 않은 분들에게도 편리한 접근 방식입니다.
다만 운영상의 트레이드오프가 존재합니다. CPU 처리량·RAM 여유 공간·플래시 수명이 이제 GEOIP 데이터베이스의 최대 크기, 원격 Rule Provider 갱신 빈도, 로그 상세도의 상한을 결정합니다. 게이트웨이는 공유 런타임이므로, DNS 포워딩에서 한 가지 실수를 하면 가정 내 모든 기기에 동시에 영향을 미칩니다. 그래서 이 글은 라우터 가이드와 함께 데스크톱·모바일 가이드도 함께 살펴볼 것을 권장합니다. Meta 어휘는 동일하지만 실수의 영향 범위가 다릅니다. 프로필을 A/B 테스트할 로컬 GUI가 필요하다면, 라우터의 프로덕션 설정을 바꾸기 전에 먼저 Windows용 Clash Verge Rev나 Android용 FlClash에서 시작해 보세요.
펌웨어, 네트워크 구성, 그리고 현실적인 하드웨어 조건
대상 브랜치에 대한 보안 업데이트가 아직 제공되는 OpenWrt 릴리스를 사용하고, Wi-Fi가 핵심 기능이라면 무선 드라이버도 확인하세요. 일부 커뮤니티 빌드는 최신 커널과 독점 드라이버 간의 트레이드오프를 안고 있습니다. RAM의 경우, 대용량 원격 규칙 목록·로깅·복수의 플러그인을 동시에 활성화하면 256 MB를 현실적인 최저선으로 봐야 합니다. 128 MB 기기도 OpenClash를 부팅할 수 있지만, 야간 규칙 업데이트나 잘못된 로그 라인으로 메모리 사용량이 급증할 때 OOM(Out-of-Memory)이 발생할 가능성이 훨씬 높습니다. 플래시 공간도 중요합니다. 원격 Provider와 코어 바이너리가 영구 스토리지를 소비하므로, 좁은 NOR 플래시 파트에서 빈번하게 업데이트한다면 주기적인 정리가 필요합니다.
네트워크 구성은 포럼 글에서 메인 라우터와 사이드 라우터 설정이 자주 혼동되므로 명확히 짚고 넘어가겠습니다. 일반적인 단일 게이트웨이 가정에서는 DHCP가 클라이언트에게 라우터의 LAN 주소를 DNS와 기본 경로로 제공하므로 설정이 단순합니다. 사이드 라우터 구성에서는 DHCP 게이트웨이·정적 경로·헤어핀 리턴 경로를 일관성 있게 유지해야 합니다. 그렇지 않으면 일부 기기는 OpenClash를 완전히 우회하고, 나머지는 예측 불가능하게 이중 NAT를 겪습니다. ARP와 DHCP 옵션 진단에 자신이 없다면, 처음에는 간단한 구성을 유지하세요. OpenClash를 실행하는 게이트웨이 라우터 하나, 나머지는 스위치나 액세스 포인트로만 구성하는 것이 가장 무난합니다.
주요 업그레이드 전: OpenClash 프로필, 구독 URL, 커스텀 방화벽 스니펫을 반드시 백업하세요. OpenWrt 메이저 업그레이드는 커널 API와 iptables/nft 기본값을 바꿀 수 있어, kmods와 LuCI 플러그인을 함께 재설치해야 할 수 있습니다.
1OpenClash, 의존성 패키지, Meta 코어 설치
설치 방법은 유지 관리 피드, 기기 아키텍처, 온라인 패키지 미러를 신뢰하느냐 아니면 오프라인 .ipk 번들을 사용하느냐에 따라 달라집니다. 어떤 채널을 선택하든 순서가 중요합니다. 먼저 라우터를 안정적인 네트워크 상태로 만들고, 시스템 시간을 확인합니다(시계가 틀리면 TLS가 이상한 방식으로 실패합니다). 그다음 플러그인에서 요구하는 기반 라이브러리와 방화벽 도구를 설치하고, 마지막으로 OpenClash를 설치합니다. 데몬이 처음 시작되면 LuCI 페이지를 열고, CPU 아키텍처에 맞는 올바른 Meta(Mihomo) 코어 바이너리를 다운로드하거나 경로를 지정합니다. arm64 라우터에 armv7 빌드를 복사·붙여넣기 하는 실수는 의외로 자주 발생합니다.
UI에서 실행 중인 코어 버전을 확인하고, 서비스 로그를 한 번 꼭 살펴보세요. 코어 실행이 거부된다면 실행 권한, 누락된 libc 변형, 다운로드를 방해한 패키지가 있는지 점검하세요. 향후 코어 업그레이드를 위한 여유 공간도 확보해 두세요. 꽉 찬 오버레이에서 압축 해제를 시도하면 소프트 브릭처럼 느껴질 수 있습니다. 업데이트를 자동화할 때는, 업스트림 릴리스 이후 잠시 버전을 고정해 두고 가정 전체가 변경 사항을 적용하기 전에 브레이킹 체인지를 먼저 읽어보는 것을 권장합니다.
설치 시 흔한 함정과 체크포인트
- 시스템 시간 확인:
date명령으로 현재 시간을 확인하고, 벗어나 있다면ntpd -nq로 동기화하세요. - 아키텍처 일치:
uname -m으로 CPU 아키텍처를 확인하고, 그에 맞는 Meta 코어 바이너리를 선택하세요. - 의존성 순서:
iptables또는nftables관련 패키지를 OpenClash 본체보다 먼저 설치해야 방화벽 규칙이 올바르게 적용됩니다. - 플래시 공간:
df -h로/overlay여유 공간을 미리 확인하세요. 최소 20 MB 이상 여유가 있어야 안정적입니다.
2구독, 원격 프로필, 안전한 병합 유지
프로바이더 구독 URL을 OpenClash에 붙여 넣고 저장한 다음 업데이트를 실행합니다. 피드가 아직 Clash 호환 형식이 아니라면 먼저 변환해야 합니다. Subconverter 가이드에서 혼합 프로토콜 번들을 원격으로 호스팅하거나 참조할 수 있는 YAML로 변환하는 방법을 안내합니다. 가져오기 후에는 해당 정책 그룹 내의 노드를 선택하고, 실행 모드를 rule로 전환해야 완료된 것입니다. 글로벌 다이렉트 모드에서 테스트하면 WAN 연결만 확인되고 정책 정확성은 검증되지 않습니다.
공개 채팅에 구독 URL을 붙여 넣은 적이 있다면 구독 시크릿을 교체하세요. 플래시 내구성에 맞는 갱신 주기를 설정하세요. 수분마다 대용량 목록을 가져오는 것은 데스크톱 SSD보다 저가형 NAND에 훨씬 가혹합니다. 여러 프로필이 공존할 경우 명확하게 레이블을 붙이고 모호한 병합을 피하세요. OpenClash는 사용자 스니펫과 원격 베이스를 결합할 수 있지만, 구조 없는 오버라이드는 6개월 후 작은 편집이 쌓이면 비교하기 어려워집니다.
3투명 프록시, 리다이렉션, LAN 우회
투명 모드는 netfilter 규칙을 사용해 인터넷으로 향하는 트래픽을 로컬 Clash 리스너로 보내므로, 클라이언트에서 수동 프록시 설정이 필요하지 않습니다. 이 편의성은 정확한 우회 목록에 달려 있습니다. RFC1918 공간, 링크-로컬 범위, 관리용 서브넷이 실수로 터널을 통과해서는 안 됩니다. 우회가 너무 공격적이면 국내 사이트가 GEOIP 규칙에 걸리지 않을 수 있고, 너무 약하면 NAS나 프린터 접근이 패킷이 외국 출구를 통해 헤어핀되면서 멈출 수 있습니다.
OpenClash 설치 후 광고 차단기, 자녀 보호, 커스텀 NAT 스크립트 같은 다른 LuCI 패키지가 체인 순서를 재배열할 수 있습니다. 증상은 랜덤한 부분적 연결 실패처럼 보입니다. 한 VLAN은 되는데 다른 쪽은 안 된다는 식입니다. 의심스러운 패키지를 일시 비활성화해서 리다이렉트가 재개되는지 확인하세요. 안정화되면 최종 체인을 문서화해 미래의 자신이 규칙이 왜 존재하는지 이해할 수 있게 해두세요. 라우터에서 VPN 클라이언트도 운영한다면, 명확한 페일오버 시나리오 없이 기본 경로를 Clash에서 빼앗기지 않도록 확인하세요.
LAN 우회 목록 작성 가이드
OpenClash의 우회 목록에는 최소한 다음 항목들이 포함되어야 합니다.
- RFC1918 사설 IP 대역:
192.168.0.0/16,10.0.0.0/8,172.16.0.0/12 - 링크-로컬:
169.254.0.0/16 - 루프백:
127.0.0.0/8 - 라우터 자체 관리 IP: LuCI 대시보드 접근이 끊기지 않도록 반드시 포함
- 멀티캐스트:
224.0.0.0/4— IoT 기기의 mDNS·DLNA 트래픽 보호
NAS, 프린터, 스마트 홈 허브 등 고정 IP를 쓰는 장치가 있다면 해당 IP 또는 서브넷을 우회 목록에 추가하는 것이 좋습니다. 과도한 우회는 분할 규칙을 무력화하고, 과소한 우회는 관리 인터페이스 접근을 막습니다.
4게이트웨이 DNS: dnsmasq, FakeIP, 루프 방지
라우터 DNS는 “브라우저에서는 되는데” 류의 논쟁이 끊이지 않는 곳입니다. Meta의 dns 스탠자는 OpenWrt의 리졸버와 협력해야 합니다. dnsmasq가 Clash로 포워딩하고, Clash가 다시 업스트림 DoH로 포워딩하는 상황에서 잘못된 업스트림이 CPU를 마비시키는 해석 루프를 만들 수 있습니다. FakeIP와 redir-host 모드 중 어떤 것을 실행하는지 파악하고, LAN 핵심 이름에 대한 fake-ip-filter 항목을 유지하며, 하이재킹을 토글하기 전에 Meta 코어 DNS 유출 방지 가이드의 심층 필드 가이드를 먼저 읽어보세요.
TUN 유사 기능이나 포트 53 하이재킹을 활성화할 때는 한 컴포넌트만 리스너 경로를 소유하는지 확인하세요. 실패하는 클라이언트에서 라우터 주소와 공용 리졸버 양쪽에 dig를 실행해 답변이 어디서 달라지는지 파악하세요. 일부 IoT 기기는 DHCP DNS 옵션을 완전히 무시한다는 점도 기억하세요. 그런 예외적인 기기는 끝없는 YAML 조정보다는 정적 정책 항목이나 하드웨어 격리가 필요할 수 있습니다.
FakeIP vs redir-host: 어떤 모드를 선택할까?
두 모드는 DNS 처리 방식에서 근본적으로 다릅니다.
- FakeIP 모드: Clash가 가짜 IP를 즉시 반환해 연결 지연을 최소화합니다. 속도가 빠르지만
fake-ip-filter목록 관리가 중요합니다. NAS·프린터 등 내부 서비스 도메인을 반드시 필터에 추가하세요. - redir-host 모드: 실제 DNS 해석을 수행한 뒤 GEOIP 규칙을 적용합니다. 정확도가 높지만 추가 DNS 왕복으로 첫 연결이 약간 느릴 수 있습니다.
홈 라우터에서는 일반적으로 FakeIP가 더 빠르고 안정적인 경험을 제공합니다. 다만 로컬 도메인(예: *.local, *.lan)을 반드시 fake-ip-filter에 추가해야 내부 서비스 접근이 끊기지 않습니다.
DNS 루프 진단 팁: tcpdump -i any port 53로 패킷을 캡처해 dnsmasq → Clash → 업스트림 간 흐름이 순환하는지 확인하세요. 루프가 감지되면 dnsmasq의 server 지시어와 Clash의 dns.listen 포트 설정을 교차 검토하세요.
5Rule Provider, GEOIP, 지속 가능한 관리
원격 Rule Provider는 GEOIP와 도메인 인텔리전스를 최신 상태로 유지하지만, 각 페치는 플래시 쓰기와 파싱을 위한 RAM을 소비합니다. 자신의 트래픽에 맞춰 간결한 Provider 세트로 시작하고, “혹시 몰라서”라는 이유로 모든 커뮤니티 목록을 미러링하지 마세요. 유지 관리 오버헤드를 확약하기 전에 규칙 세트 비교 가이드에서 ACL4SSR과 Loyalsoldier 같은 엄선된 번들을 비교해 보세요. DNS 정책을 규칙 카테고리와 맞추세요. 리졸버 분할 정책을 수정하지 않고 GEOIP 파일만 바꾸면 “규칙이 작동을 멈췄다”처럼 보이는 위음성이 자주 발생합니다.
업데이트는 오프피크 시간대에 예약하고, 메이저 업스트림 변경 이후 첫 번째 페치 중 메모리 상황을 모니터링하세요. Provider가 사라지면 라우터가 여전히 결정론적으로 정책을 부팅할 수 있도록 로컬 폴백 YAML 스니펫을 보관하세요. 업스트림이 파일 이름을 바꾼 후 리베이스할 수 있도록 커스텀 패치를 벤더 병합과 별도로 버전 관리하세요.
Rule Provider YAML 예시
아래는 config.yaml에서 원격 Rule Provider를 선언하는 기본 구조입니다.
rule-providers:
reject:
type: http
behavior: domain
url: "https://cdn.jsdelivr.net/gh/Loyalsoldier/clash-rules@release/reject.txt"
path: ./ruleset/reject.yaml
interval: 86400
direct:
type: http
behavior: domain
url: "https://cdn.jsdelivr.net/gh/Loyalsoldier/clash-rules@release/direct.txt"
path: ./ruleset/direct.yaml
interval: 86400
proxy:
type: http
behavior: domain
url: "https://cdn.jsdelivr.net/gh/Loyalsoldier/clash-rules@release/proxy.txt"
path: ./ruleset/proxy.yaml
interval: 86400
rules:
- RULE-SET,reject,REJECT
- RULE-SET,direct,DIRECT
- RULE-SET,proxy,PROXY
- GEOIP,CN,DIRECT
- MATCH,PROXY
interval은 초 단위입니다. 86400은 하루에 한 번 갱신을 의미합니다. 라우터 플래시 수명을 고려해 너무 짧게 설정하지 마세요.
법적 고지: 프록시 기능은 허용된 곳에서만 사용하세요. 기업·학교·국가 네트워크에서는 우회 도구가 금지될 수 있습니다. 라우터 전체 터널을 배포하기 전에 정책을 반드시 확인하세요.
트러블슈팅: 메모리, DNS, 처리량, 플러그인 충돌
랜덤 재부팅 또는 OOM: Rule Provider를 줄이고, 로그 상세도를 낮추고, 불필요한 LuCI 앱을 비활성화하거나 RAM이 더 많은 하드웨어로 마이그레이션하세요. 부분적인 사이트 로드: TCP 리다이렉션만 활성화된 경우 QUIC 또는 HTTP/3에 추가 캡처 경로가 필요한지 점검하세요. 느린 최대 속도: 라우터 CPU는 데스크톱 CPU가 아닙니다. AES-NI 가용성, 열 스로틀링, 단일 코어 한계가 중요합니다. 테스트 중에 가벼운 프로토콜을 고려하거나 동시 연결 수를 줄여보세요.
DNS 이상: dnsmasq → Clash → 업스트림 리졸버를 보여주는 한 페이지짜리 다이어그램을 그려보세요. 스니퍼 설정을 추적하기 전에 루프를 제거하세요. 관리 페이지 접근 불가: 우회 목록에 라우터 자체의 관리 주소가 포함되어 있는지, 그리고 관리 VLAN을 의도치 않게 리다이렉트하지 않았는지 확인하세요. 플러그인 충돌: 의심스러운 플러그인을 하나씩 비활성화하면서 결과를 기록하세요. 한꺼번에 여러 변경을 가하면 주말을 날릴 수 있습니다.
메모리 절약 실전 팁
- OpenClash 로그 레벨을
warning또는error로 낮추세요. 기본값인info는 메모리를 빠르게 소진합니다. - 동시에 활성화하는 Rule Provider 수를 최소화하세요. 국가별로 필요한 것만 선택적으로 사용하세요.
- 사용하지 않는 LuCI 앱(adblock, banip 등)을 비활성화하면 수십 MB를 확보할 수 있습니다.
- nightly cron 업데이트 시간을 트래픽이 적은 새벽 3–5시로 설정하면 사용자 영향을 최소화할 수 있습니다.
- 128 MB RAM 기기라면 GEOIP 데이터베이스를 경량 버전으로 교체하는 것을 고려하세요.
고급 설정: 멀티 WAN, VLAN, 선택적 분할
단일 WAN 구성을 안정적으로 운영한 후에는 조금 더 복잡한 구성을 탐색할 수 있습니다. 멀티 WAN 환경에서는 OpenClash의 아웃바운드 인터페이스를 명시적으로 지정하지 않으면 정책 라우팅과 충돌할 수 있습니다. VLAN 분리를 사용한다면 각 VLAN의 트래픽이 OpenClash를 통과하는지 우회하는지를 방화벽 마크와 ip rule로 세밀하게 제어할 수 있습니다. 업무용 VLAN은 직접 연결, 개인용 VLAN만 프록시를 통하도록 구성하면 직장 원격 근무 시에도 안정성이 유지됩니다.
선택적 분할은 특정 기기(예: 스마트 TV, 게임 콘솔)에만 프록시를 적용하고 나머지는 직접 연결하는 방식입니다. iptables의 MAC 주소 기반 매칭이나 고정 IP 할당을 통해 구현할 수 있습니다. 이 방식은 가정 내 모든 트래픽을 프록시로 강제하지 않아도 되는 상황에서 특히 유용합니다.
GitHub와 다운로드: OpenClash와 Meta는 GitHub에 소스와 이슈를 공개하고 있어 체인지로그를 읽기에 적합합니다. 라우터 변경을 검증하는 데 사용하는 워크스테이션에 데스크톱 Clash 빌드를 설치할 때는, 설치 파일이 원시 저장소 브라우징과 분리될 수 있도록 공식 다운로드 페이지를 이용하세요.
마치며
OpenWrt에서 OpenClash를 실행하는 것은 모든 LuCI 체크박스를 암기하는 것보다 반복 가능한 파이프라인을 구축하는 것에 가깝습니다. 검증된 코어 바이너리, 깔끔한 구독 병합, LAN 우회를 존중하는 투명 경로, 루프 없는 DNS, 유지 관리할 수 있는 Rule Provider가 그 핵심입니다. 이 파이프라인이 안정화되면 가정의 모든 기기가 인스톨러 마법사 없이도 동일하고 사려 깊은 정책을 상속받습니다.
통제된 실험을 위해 데스크톱이나 스마트폰 클라이언트를 곁에 두세요. Meta는 일관성 있게 동작하지만, 단일 머신에서 변수를 격리하면 프로필을 비교할 때 수 시간을 절약할 수 있습니다. 기기마다 단일 프로토콜 앱을 관리하는 것과 비교할 때, 통합된 Meta 우선 워크플로우는 특히 2026년 현재 도구 생태계가 성숙해진 시점에서 유지 관리 비용 면에서 분명히 우위에 있습니다.