라우터·서브라우터에서 Clash 코어 직접 구동:mihomo 배포 방안 개요

왜 프록시를 라우터 계층에 두는가

데스크톱 클라이언트와 모바일 앱은 소프트웨어가 설치된 그 기기만 커버할 수 있습니다. 집에 있는 TV 셋톱박스, 게임 콘솔, 스마트 스피커, 태블릿 등은 하나씩 설정하기 어렵고, 시스템 프록시나 TUN 모드도 제조사마다 구현이 달라 커스텀 DNS나 가상 네트워크 카드를 지원하지 않는 기기를 만나면 손을 쓸 수 없습니다. 프록시를 라우터나 서브라우터 계층으로 내려보내면 네트워크 출구에서 트래픽을 일괄적으로 처리하는 셈이 되어, 이 네트워크에 연결된 모든 기기가 자동으로 분기 기능을 얻게 됩니다. 기기마다 클라이언트를 설치할 필요도 없고, 특정 기기의 아키텍처가 특이해서 소프트웨어를 설치할 수 없는 상황을 걱정할 필요도 없습니다. 이것이 많은 가정 네트워크가 결국 게이트웨이 계층에 mihomo 코어를 배포하는 핵심 이유입니다.

mihomo는 Clash Meta 프로젝트를 이어받은 코어 구현체로, 초기 Clash 코어에 비해 프로토콜 지원이 더 풍부하고 규칙 엔진이 유연하며, TUN 모드와 다양한 프로세스 단위 분기 기능을 기본으로 제공합니다. 펌웨어화되어 라우터에서 장기간 구동하기에 매우 적합합니다. 아래에서는 메인 라우터와 서브라우터 두 가지 구성으로 나누어 구축 방법을 설명합니다.

메인 라우터와 서브라우터: 어떤 구성을 선택할까

"메인 라우터"란 서드파티 펌웨어(주로 OpenWrt 계열)를 직접 설치해 라우터 자체가 mihomo 실행 환경을 맡는 방식이고, "서브라우터"는 기존 라우터 외에 소형 장치(미니 PC, 유휴 라우터를 순수 게이트웨이로 만든 것, 심지어 NAS의 가상머신)를 추가로 연결해, 게이트웨이 리다이렉트나 LAN 내 DHCP 옵션을 통해 프록시가 필요한 기기를 이 서브라우터로 향하게 하는 방식입니다.

• 메인 라우터 방식: 구성이 단순해 한 대의 장치가 라우팅과 프록시를 모두 처리하며 추가 하드웨어가 필요 없다는 장점이 있습니다. 다만 라우터 자체의 펌웨어 호환성과 CPU 성능 요구가 더 높고, 프록시 프로세스에 문제가 생기면 전체 네트워크의 라우팅 전달에도 영향을 줄 수 있어 위험이 한 장치에 집중됩니다.
• 서브라우터 방식: 메인 라우터는 출고 펌웨어 그대로 유지되어 안정성과 A/S에 영향이 없고, 서브라우터가 프록시 전용으로 동작하므로 문제가 생기면 이 한 대만 재시작하면 되어 문제 해결 범위가 명확합니다. 다만 하드웨어가 하나 더 필요하고 네트워크 설정(게이트웨이 지정, DHCP 배포)이 한 단계 더 늘어나 초기 구축 난이도가 다소 높습니다.

집에 서드파티 펌웨어를 설치할 수 있는 라우터가 한 대뿐이고 "모든 위험이 한 장치에 집중되는" 상황을 감수할 수 있다면 메인 라우터 방식이 더 간편합니다. 프록시 환경과 기본 네트워크를 분리해 언제든 프록시 장치를 초기화하거나 교체해도 인터넷 사용에 영향을 주지 않길 원한다면 서브라우터가 더 안전한 선택이며, 현재 가정 네트워크에서 더 흔하게 쓰이는 방식이기도 합니다.

하드웨어 선택과 펌웨어 기초

mihomo 자체는 Go로 작성된 단일 바이너리 프로그램으로 리소스 사용량이 그리 크지 않지만, 투명 프록시 환경에서는 NAT 포워딩, DNS 조회, 규칙 매칭을 동시에 처리해야 하므로 선택 시 세 가지 측면을 확인하는 것이 좋습니다:

1. CPU 아키텍처와 연산 성능: 하드웨어 가속을 지원하는 멀티코어 ARM 또는 x86 플랫폼을 우선 고려하세요. 순수 라우팅 수준의 저전력 단일 코어 칩은 동시 연결이 많을 때 규칙 매칭 지연이 발생하기 쉽습니다.
2. 메모리 용량: 규칙 세트 로딩과 연결 테이블 유지는 메모리를 많이 사용하므로, 프록시 프로세스와 펌웨어 자체를 위해 최소 512MB 이상을 확보하는 것이 좋습니다. 규칙이 많거나 로그 추적을 켤 경우 여유를 더 두는 것이 좋습니다.
3. 저장 공간과 펌웨어 생태계: 메인 라우터 방식은 보통 OpenWrt 또는 그 파생 펌웨어에 의존하므로 대상 기기가 안정적인 서드파티 펌웨어 지원과 커뮤니티 유지 관리를 받고 있는지 확인해야 합니다. 서브라우터 방식은 더 자유로워서 미니 PC에 Linux 배포판을 설치하거나 오래된 라우터를 OpenWrt 순수 게이트웨이 모드로 설치하는 등 흔히 쓰이는 방식이 다양합니다.

펌웨어 측면에서 mihomo 공식 및 커뮤니티는 OpenWrt에 맞춘 패키지와 LuCI 관리 인터페이스를 제공해, 패키지 관리자로 설치할 수도 있고, 컴파일된 바이너리를 직접 배치해 init 스크립트와 함께 실행할 수도 있습니다. 두 방식 모두 뒤에 나오는 자동 시작 부분에서 다룹니다.

투명 프록시 모드: TUN, TPROXY, REDIRECT 중 무엇을 선택할까

게이트웨이 계층에서 트래픽을 처리하는 핵심은 LAN 기기가 보내는 TCP/UDP 트래픽을 mihomo가 리스닝하는 포트로 투명하게 전달하고, 코어가 규칙에 따라 통과·프록시·차단을 결정하도록 하는 것입니다. 흔히 쓰는 세 가지 구현 방식은 각각 장단점이 있습니다:

• TUN 모드: mihomo가 가상 네트워크 카드를 생성해 3계층에서 트래픽을 직접 처리합니다. 설정이 직관적이고 UDP 지원이 완전해 현재 권장되는 기본 방식이며, IPv4/IPv6 분기를 정밀하게 제어해야 하는 상황에 특히 적합합니다.
• TPROXY: Linux 커널의 투명 프록시 메커니즘에 의존해 게이트웨이 기기에서 iptables/nftables로 트래픽을 mihomo로 리다이렉트합니다. 원래의 목적지 주소 정보를 보존할 수 있어 호환성이 좋으며, 성숙한 OpenWrt 분기 스크립트 방식에서 흔히 쓰입니다.
• REDIRECT: 비교적 초기의 구현 방식으로 TCP 리다이렉트만 지원하며, UDP(특히 UDP에 의존하는 게임이나 일부 영상 프로토콜)는 별도 처리가 필요합니다. 새로 구축할 때는 보통 우선적으로 선택하지 않습니다.

어떤 방식을 선택하든 설정 파일에서 해당 투명 프록시 옵션을 켜고 리스닝 포트를 지정해야 합니다. 예를 들어 TUN 모드를 활성화할 때 핵심 항목은 대략 다음과 같습니다(구체적인 파라미터는 최신 버전 문서를 기준으로 하세요):

tun:
  enable: true
  stack: system
  auto-route: true
  auto-detect-interface: true

auto-route는 라우팅 테이블을 자동으로 작성하고, auto-detect-interface는 코어가 출구 네트워크 카드를 자동으로 인식하도록 돕습니다. 이 둘을 함께 쓰면 수동으로 라우팅 규칙을 수정하는 단계를 크게 줄일 수 있어, 현재 서브라우터 방식에서 가장 흔히 쓰이는 조합입니다.

DNS 처리와 오염 방지

투명 프록시는 트래픽 전달만 해결할 뿐, DNS 조회가 여전히 통신사 기본 경로를 거친다면 도메인 기반 규칙 분기는 "잘못된" 해석 결과를 받아 무력화됩니다. 흔한 증상은 규칙을 분명히 설정했는데도 특정 사이트 접속이 여전히 비정상적으로 느리거나 전혀 연결되지 않는 경우입니다. 따라서 게이트웨이 계층 배포에서는 반드시 DNS도 함께 처리해야 합니다:

1. mihomo 설정에서 내장 DNS 서버를 활성화하고, LAN 기기가 접근할 수 있는 리스닝 주소와 포트를 지정합니다.
2. fake-ip 또는 redir-host 모드를 결합해 코어가 먼저 도메인을 확보한 뒤 어느 상위 서버로 해석할지 결정하게 하고, 규칙 엔진과 함께 단순 IP 대역 기반이 아닌 도메인 기반 분기를 구현합니다.
3. 라우터의 DHCP 설정에서 LAN 기기에 배포되는 DNS 서버 주소를 게이트웨이 자신(즉 mihomo가 실행되는 기기)으로 지정해, 기기가 게이트웨이를 거치지 않고 외부 DNS에 직접 질의하는 것을 막습니다.

서브라우터 구성이라면 메인 라우터에서 DHCP 옵션 6(DNS)이 실제로 서브라우터 주소를 가리키는지 확인해야 합니다. 그렇지 않으면 서브라우터 설정이 올바르더라도 LAN 기기는 여전히 메인 라우터가 배포하는 기본 DNS를 받게 되어 분기 규칙이 유명무실해집니다. 이 단계는 "규칙을 설정했는데 적용되지 않는" 문제를 해결할 때 가장 자주 놓치는 부분입니다.

자동 시작과 장기 안정성

게이트웨이 계층의 프록시 프로세스는 "라우터 재시작 후 자동 복구" 능력을 갖춰야 합니다. 그렇지 않으면 한 번의 예기치 못한 정전으로 집 전체가 인터넷이 끊기거나 분기되지 않은 상태로 되돌아갈 수 있습니다. 실제 구축 시 다음 사항을 확인하는 것이 좋습니다:

• init 스크립트 또는 시스템 서비스: OpenWrt에서는 procd 서비스 스크립트를 작성해 mihomo를 시스템 서비스로 등록할 수 있습니다. enable, start, stop 등 표준 명령을 지원하며, 펌웨어 재시작 후 procd가 자동으로 다시 구동합니다.
• 워치독과 자가 복구: 간단한 예약 작업(cron)으로 프로세스 생존 여부를 확인하고, 비정상 종료 시 자동 재시작되게 해 코어의 우발적 크래시로 장시간 인터넷이 끊긴 것을 아무도 모르는 상황을 방지합니다.
• 설정과 규칙 세트 분리: 구독으로 생성된 노드 설정과 로컬에서 직접 작성한 규칙을 서로 다른 파일로 분리해 참조하면, 구독을 갱신해도 수동으로 조정한 라우팅 규칙이 덮어써지지 않아 매번 구독을 새로 불러올 때마다 다시 점검해야 하는 작업량을 줄일 수 있습니다.
• 로그 보관: 적절한 수준의 연결 로그와 코어 로그를 로컬 파일로 출력해두면, 기기가 오프라인이거나 분기가 비정상일 때 어떤 규칙 또는 어떤 DNS 조회에서 문제가 발생했는지 거슬러 확인하기 편합니다.

서브라우터 방식은 메인 라우터와 독립적으로 동작하기 때문에 로그 보관과 프로세스 관리가 대체로 더 쉽고, 실험적인 규칙 변경을 시도하기에도 적합합니다. 메인 라우터 방식은 설정을 비교적 보수적으로 유지하고, 중대한 변경 전에는 현재 정상 동작하는 설정 파일을 미리 백업해두는 것이 좋습니다.

구축 전 확인 목록

앞서 다룬 판단 기준을 간단한 체크리스트로 정리해 자신의 가정 네트워크 상황과 대조해 볼 수 있습니다:

1. 현재 라우터가 안정적인 서드파티 펌웨어를 지원하는가? 지원하고 위험을 한 장치에 집중시킬 수 있다면 → 메인 라우터 방식을 우선 고려하세요.
2. 프록시 전용으로 쓸 수 있는 유휴 미니 PC, 오래된 라우터, 소형 NAS가 있는가? 있다면 → 서브라우터 방식이 문제 해결이 더 명확하고 위험이 더 분산됩니다.
3. 집에 커스텀 DNS를 지원하지 않는 스마트 기기(TV 셋톱박스, 스피커 등)가 있는가? 있다면 → 게이트웨이 계층의 DNS 하이재킹 전략을 미리 계획해야 합니다.
4. 프록시 장치를 자주 교체하거나 펌웨어를 다시 설치해 테스트할 필요가 있는가? 자주 그렇다면 → 서브라우터가 메인 네트워크에 영향을 주지 않고 언제든 교체하기 더 편리합니다.
5. 장기간 관리자 없이 방치되는 상황(출장, 원격지)이 있는가? 있다면 → 자동 시작과 워치독을 반드시 설정해 정전 후 원격으로 복구할 수 없는 상황을 피해야 합니다.

어떤 구성을 최종 선택하든 핵심 원리는 동일합니다: 먼저 게이트웨이 계층에서 트래픽과 DNS를 모두 mihomo 코어로 모으고, 명확한 규칙 파일로 분기 로직을 기술한 뒤, 시스템 서비스와 로그 메커니즘으로 장기 안정 운영을 보장하는 것입니다. 이 세 단계를 각각 튼튼하게 만들어야 가정 네트워크 안의 모든 기기가 기기마다 설정을 따로 손대지 않고도 같은 프록시 정책을 진정으로 공유할 수 있습니다.