OpenWrt 라우터·보조 라우터에 mihomo 커널 직접 설치하기: 배포 방식 가이드

배포 범위: 커널 실행, 트래픽 가로채기, 기기 게이트웨이

OpenWrt에서 mihomo를 실행해도 라우터에서 프록시 커널 프로세스가 동작할 뿐입니다. 휴대폰, TV, PC의 트래픽이 이를 거치게 하려면 진입 경로, 라우팅, DNS를 설정해야 합니다. 설정 파일이 로드되고 대시보드가 열린다는 사실만으로 LAN 트래픽이 가로채졌다고 볼 수는 없습니다.

mihomo는 Clash Meta의 설정 체계를 이어받아 프록시 프로토콜, 규칙 매칭, 연결 처리를 담당합니다. OpenWrt는 인터페이스, 라우팅, 방화벽, 서비스 관리를 맡습니다. LuCI 플러그인으로 관련 작업을 화면에서 처리할 수 있지만 플러그인, 커널, 구독 설정은 각각 별도로 업데이트해야 합니다.

명시적 프록시: 기기나 앱에서 프록시 서버 주소와 포트를 직접 입력합니다. 설정을 먼저 확인할 때 적합하지만, 프록시 설정을 따르지 않는 앱의 트래픽은 자동으로 커널을 거치지 않습니다.
투명 프록시: 라우터가 방화벽과 정책 라우팅으로 통과하는 트래픽을 가로챕니다. 일반적으로 각 기기에 HTTP 프록시를 따로 설정할 필요가 없습니다.
TUN: 커널이 가상 네트워크 인터페이스를 통해 IP 트래픽을 처리합니다. 시스템 라우팅, 방화벽 포워딩, 루프백 제외 설정도 함께 구성해야 합니다.

메인 라우터와 보조 라우터: 실제 트래픽 경로부터 확인

메인 라우터에 배포

메인 라우터는 인터넷 연결을 직접 제공하며, LAN 기기의 기본 게이트웨이도 보통 메인 라우터입니다. 트래픽이 자연스럽게 이 장비를 통과하므로 투명 프록시를 일괄 적용하기 쉽지만, 커널 재시작이나 규칙 재적용, DNS 설정 오류의 영향도 더 큽니다. 모든 연결을 한꺼번에 가로채기보다 직접 연결과 관리 주소를 예외로 두는 것이 중요합니다.

같은 서브넷에 보조 라우터 배포

아래 주소는 네트워크 구성을 설명하기 위한 예시이며 실제 측정값이 아닙니다. 메인 라우터는 192.168.10.1, 보조 라우터는 192.168.10.2, 테스트 PC는 192.168.10.100/24입니다. 보조 라우터의 상위 기본 경로는 메인 라우터를 향하고, 테스트 PC의 기본 게이트웨이는 보조 라우터를 향하도록 설정합니다.

대상	설정 예시	확인할 항목
메인 라우터	192.168.10.1	상위 인터넷 출구 역할, 초기에는 기존 DHCP 서비스 유지
보조 라우터	192.168.10.2/24	상위 게이트웨이는 192.168.10.1, 필요한 포워딩 허용
테스트 PC	192.168.10.100/24	기본 게이트웨이는 192.168.10.2, DNS는 설정된 DNS 진입점으로 지정

보조 라우터와 단말이 같은 서브넷에 있으면 직접 연결의 응답 트래픽이 메인 라우터를 거쳐 단말로 바로 돌아가 비대칭 경로가 생길 수 있습니다. 소스 NAT가 필요한지, ICMP 리디렉션을 어떻게 처리할지는 연결 추적과 실제 라우팅 경로를 기준으로 판단하세요. 모든 구성에 ‘NAT 켜기’를 정답처럼 적용해서는 안 됩니다. WAN과 LAN 포트가 분리되고 별도 하위 네트워크를 사용하는 보조 라우터는 일반 라우터에 가까워 경로가 대체로 더 명확합니다.

단말의 DNS만 보조 라우터로 바꿔도 실제 연결 트래픽까지 보조 라우터를 거치는 것은 아닙니다.
DHCP로 게이트웨이와 DNS를 배포할 때 IPv4 옵션은 보통 3과 6입니다. 설정을 바꾼 뒤에는 클라이언트에서 DHCP 임대를 갱신해야 합니다.
같은 브로드캐스트 도메인에서 계획 없이 DHCP 서버를 두 대 실행하면 기기마다 서로 다른 게이트웨이를 받을 수 있습니다.
IPv6 기본 경로는 보통 라우터 광고로 배포됩니다. IPv4 게이트웨이만 바꿔도 IPv6 경로까지 자동으로 바뀌지는 않습니다.

구조와 시스템 확인: 실행 가능한 mihomo 파일 선택

다운로드 전에 OpenWrt 버전, CPU 아키텍처, 사용 가능한 저장 공간을 확인하세요. OpenWrt 23.05 및 24.10의 일반적인 공식 이미지에는 firewall4와 nftables가 사용됩니다. 서드파티 펌웨어는 구성 요소가 다를 수 있으므로 실제 환경을 확인하고 펌웨어 이름만 보고 스크립트를 선택하지 마세요.

ubus call system board
uname -m
opkg print-architecture
df -h /overlay /tmp
free -m
command -v fw4
command -v nft
test -c /dev/net/tun && echo "TUN device available"

위의 opkg 명령은 opkg를 사용하는 펌웨어에서 사용할 수 있습니다. 다른 패키지 관리자를 사용하는 시스템은 해당 펌웨어의 안내에 따라 확인하세요. uname -m은 현재 실행 환경의 아키텍처를 표시하므로 CPU 명령어 집합과 배포 파일 안내를 따로 확인해야 합니다.

x86_64: amd64 계열에 해당하지만 최적화 빌드에 따라 필요한 CPU 명령어 집합이 다를 수 있습니다. 오래된 소형 라우터라면 배포 파일의 요구 사항을 확인하세요.
aarch64: 일반적으로 arm64에 해당합니다. 하드웨어가 64비트를 지원하더라도 펌웨어가 32비트 환경에서 실행 중이라면 실제 시스템을 기준으로 선택하세요.
ARM, MIPS: 제품 설명에 나온 칩 계열만 보지 말고 ARM 세대와 부동소수점 요구 사항, MIPS의 엔디언도 확인해야 합니다.
저장 공간과 메모리: 커널, 규칙 세트, 지리 데이터베이스가 공간을 차지합니다. /tmp는 보통 메모리에 위치하므로 재부팅하면 내용이 사라집니다.

Exec format error가 발생하면 먼저 아키텍처를 확인하세요. Illegal instruction이 표시되면 명령어 집합 요구 사항을 살펴보세요. 파일이 있는데 실행할 수 없다면 로더나 권한 문제일 수도 있으므로 구독이 만료됐다고 단정하지 마세요.

배포 방식: LuCI 플러그인, 독립 프로세스, 컨테이너

방법 1: LuCI 플러그인으로 통합 관리

구독 업데이트, 부팅 시 자동 실행, 투명 프록시 규칙 연동이 필요한 환경에 적합합니다. 현재 OpenWrt 방화벽 체계와 mihomo를 지원하는 플러그인을 선택하고 해당 버전의 문서를 확인하세요. 플러그인마다 메뉴, 설정 덮어쓰기 방식, 커널 업데이트 경로가 다르므로 한 플러그인의 설정 절차를 다른 플러그인에 그대로 적용해서는 안 됩니다.

플러그인은 실행 중 최종 설정 파일을 생성하는 경우가 많습니다. 생성된 파일을 직접 수정하면 다음 구독 업데이트나 서비스 재시작 때 변경 내용이 덮어써질 수 있습니다. 플러그인이 제공하는 지속 설정 기능을 사용하고, 별도의 커널을 추가로 실행해 포트가 충돌하지 않도록 하세요.

방법 2: 독립 바이너리와 procd 서비스

실행 옵션과 방화벽 규칙을 직접 관리하려는 사용자에게 적합합니다. 여기서는 커널 경로를 /usr/bin/mihomo, 데이터 디렉터리를 /etc/mihomo로 가정합니다. 이는 설명을 위한 예시 경로이며 모든 플러그인의 기본 경로는 아닙니다. 확인을 마친 설정 파일을 먼저 배치한 뒤 포그라운드에서 실행해 오류를 살펴보세요.

/usr/bin/mihomo -v
/usr/bin/mihomo -t -d /etc/mihomo -f /etc/mihomo/config.yaml
/usr/bin/mihomo -d /etc/mihomo -f /etc/mihomo/config.yaml

-t는 설정 파일을 테스트하는 옵션입니다. 테스트가 성공해도 DNS, 인터넷 출구, 포워딩을 별도로 확인해야 합니다. 포그라운드 실행이 안정적이면 /etc/init.d/에 procd 서비스를 등록하고 실행 명령, 표준 출력, 비정상 종료 후 재시작, 종료 시 정리 동작을 설정하세요. 백그라운드 명령을 반복 실행해 서비스를 대신하면 프로세스와 이전 규칙이 남기 쉽습니다.

방법 3: 컨테이너에서 실행

컨테이너는 이미 컨테이너 관리 체계를 사용하는 소형 라우터에 적합하지만 네트워크 네임스페이스, 데이터 볼륨, 권한 경계가 추가됩니다. TUN을 사용하려면 컨테이너가 해당 장치에 접근할 수 있어야 하며 필요한 네트워크 관리 권한도 있어야 합니다. 투명 프록시 규칙을 호스트와 컨테이너 중 어디에 설치할지도 명확히 정하세요. 7890 포트만 매핑하면 보통 명시적 프록시만 제공되며 LAN 전체 트래픽이 자동으로 가로채지지는 않습니다.

투명 프록시와 TUN: 트래픽 가로채기 방식 선택

투명 프록시는 트래픽을 가로채는 목표이고 TUN은 이를 구현하는 방법 중 하나입니다. REDIRECT 또는 TPROXY도 널리 사용됩니다. REDIRECT는 TCP 리디렉션에 주로 쓰이고, TPROXY는 TCP와 UDP를 처리할 수 있지만 정책 라우팅, 패킷 마크, 관련 커널 모듈이 필요합니다. 사용할 방식은 플러그인 지원 여부, 펌웨어 구성 요소, 네트워크 구조에 따라 선택하세요.

진입 방식	필요한 시스템 설정	중점 확인 사항
명시적 HTTP / SOCKS 프록시	앱에 프록시 주소 설정	프록시를 우회하는 앱이 있는지, UDP 지원 여부를 별도로 확인
REDIRECT / TPROXY	방화벽 규칙, 필요한 경우 정책 라우팅 설정	TCP·UDP 가로채기 범위, mark 충돌, 루프백 제외
TUN	TUN 장치, 라우팅, 포워딩 규칙	인터페이스 생성 여부, 트래픽 유입 여부, DNS 변경 여부

TUN을 사용하기 전에 LuCI의 ‘시스템’ → ‘소프트웨어’에서 현재 커널과 호환되는 kmod-tun이 설치되어 있는지 확인하고 /dev/net/tun도 살펴보세요. 펌웨어 커널 버전이 다른 모듈을 임의로 설치해서는 안 됩니다. 장치 파일이 존재한다는 것은 기본 조건을 갖췄다는 뜻일 뿐, 이후 라우팅까지 올바르게 설정됐다는 의미는 아닙니다.

라우팅을 담당하는 주체를 명확히 하세요. 플러그인이 트래픽 가로채기 규칙을 생성한다면 자동 라우팅을 활성화하는 별도 설정을 중복 적용하지 마세요.
커널 자체의 프록시 출구 연결, 라우터 관리 주소, 상위 게이트웨이, 필요한 LAN 대역은 제외해 연결이 커널로 반복해서 들어가는 일을 방지하세요.
LuCI의 ‘네트워크’ → ‘방화벽’에서 영역과 포워딩 관계를 확인하세요. 규칙 오류를 전체 허용 설정으로 덮어서는 안 됩니다.
문제 해결 중에는 소프트웨어 또는 하드웨어 플로우 오프로딩을 잠시 끄고 다시 테스트하세요. 오프로딩에 따라 이후 패킷의 처리 경로가 달라질 수 있습니다.

DNS 가로채기: 수신 포트, 상위 DNS, Fake-IP

OpenWrt에서는 보통 dnsmasq가 LAN DNS를 제공합니다. 이해하기 쉬운 구성은 단말이 라우터의 53 포트에 요청을 보내고, dnsmasq가 커널에 전달할 요청을 로컬 127.0.0.1:1053으로 넘기는 방식입니다. 이렇게 하면 dnsmasq의 로컬 호스트 이름 처리를 유지할 수 있지만, 실제 설정을 확인해 커널의 DNS 요청이 다시 dnsmasq로 돌아오는 순환을 막아야 합니다.

아래는 mihomo DNS 설정의 일부로, 바로 실행할 수 있는 완전한 라우터 설정이 아닙니다. 포트 관계를 설명하기 위해 일반 상위 DNS를 사용했습니다. 실제 배포에서는 네트워크 연결 가능성, 개인정보 보호 요구 사항, 프록시 서버 도메인의 조회 방식에 맞춰 상위 DNS를 선택하세요.

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 223.5.5.5
    - 119.29.29.29

53 포트의 진입점을 하나로 정하세요. dnsmasq가 이미 LAN의 53 포트를 수신 중이라면 mihomo를 같은 주소와 포트에 바인딩하면 안 됩니다.
DNS 요청을 전달하세요. LuCI의 ‘네트워크’ → ‘DHCP/DNS’에서 DNS 전달 주소로 127.0.0.1#1053 같은 dnsmasq 형식을 사용할 수 있습니다. 상위에서 전달받은 DNS 서버를 계속 사용할지도 확인하세요.
DNS 순환을 방지하세요. mihomo의 상위 DNS를 dnsmasq 진입점으로 다시 지정하면 안 됩니다. 프록시 서버 도메인도 처음 조회할 수 있는 경로가 확보되어야 합니다.
실제 DNS 요청을 확인하세요. 일반 DNS에는 UDP와 TCP 53이 모두 사용됩니다. 앱 내부 DoH는 HTTPS를 사용하므로 53 포트 리디렉션만으로 같은 DNS 처리 경로에 들어오지 않습니다.

Fake-IP는 매핑된 주소를 반환하고 커널은 매핑 정보를 통해 도메인을 연결합니다. 단말이 198.18.0.0/16 대역의 주소를 받았지만 해당 대역을 가로채지 않는 게이트웨이로 연결을 보내면 ‘DNS 응답은 있는데 웹페이지가 열리지 않는’ 문제가 생길 수 있습니다. Fake-IP, DNS 배포, 트래픽 진입 경로를 함께 확인하세요.

프린터, 화면 미러링, LAN 도메인 검색에 의존하는 앱은 별도로 테스트하세요. 필요하면 정확한 Fake-IP 필터와 로컬 도메인 DNS 규칙을 사용하세요. IPv6의 DNS 배포, AAAA 응답, 인터넷 출구 경로도 함께 확인해야 합니다. IPv4 테스트만 성공했다고 모든 연결이 가로채졌다고 판단하지 마세요. 자세한 필드 설명은 전체 매뉴얼의 DNS 항목과 Fake-IP 용어 설명을 참고하세요.

검증 순서: 설정 테스트부터 LAN 연결 확인까지

정해진 순서로 점검하면 규칙, DNS, 방화벽을 한꺼번에 바꾸지 않고 문제를 특정 단계로 좁힐 수 있습니다. 아래 포트는 이 문서의 예시입니다. 명시적 혼합 프록시는 7890, 커널 DNS는 1053이며, 제어 인터페이스를 활성화한다면 127.0.0.1:9090으로 제한할 수 있습니다.

커널 단계: 설정을 테스트하고 실행 로그를 확인하세요. 독립 procd 서비스는 logread로 시작 오류를 확인할 수 있으며, 플러그인은 우선 해당 플러그인의 로그 페이지를 사용하세요.
수신 단계: ss가 설치되어 있다면 ss -lntup을 실행하세요. 그렇지 않으면 펌웨어에서 제공하는 동등한 도구를 사용해 7890, 1053 등의 포트가 어느 주소와 프로토콜에서 수신 중인지 확인하세요.
명시적 프록시 단계: LAN 접근을 허용하고 방화벽에서 접속 출처를 제한한 상태로 테스트 PC에서 보조 라우터의 7890 포트를 통해 웹페이지에 접속하세요. 먼저 구독 설정과 인터넷 출구가 작동하는지 확인합니다.
DNS 단계: 테스트 PC에서 예상한 DNS 진입점으로 조회하고 커널 로그와 응답을 살펴보세요. DNS 시간 초과, Fake-IP 정상 응답, 상위 DNS 순환을 구분할 수 있습니다.
라우팅 단계: 테스트 PC의 명시적 프록시를 끄고 테스트용 게이트웨이와 DNS만 설정한 상태에서 연결이 계속 커널로 들어오는지 확인하세요. 라우터에서는 ip route show, ip rule show와 관련 라우팅 테이블을 함께 살펴보세요.
프로토콜 단계: 일반 웹페이지, 동영상, UDP 앱, IPv6 연결을 각각 확인하세요. TCP 연결이 성공해도 UDP나 IPv6가 같은 경로를 사용한다는 보장은 없습니다.

단말에서 명시적 프록시 연결을 테스트하려면 curl이 설치되어 있어야 하며, 보조 라우터에서 위 예시처럼 LAN 프록시 진입점이 열려 있어야 합니다. 예시 URL은 테스트 대상일 뿐, 프록시 규칙에 반드시 일치한다는 뜻은 아닙니다.

curl --proxy http://192.168.10.2:7890 --connect-timeout 10 -I https://example.com/
nslookup example.com 192.168.10.2

공인 IP가 바뀌는지만 확인하지 마세요. 규칙 모드에서는 일부 대상이 원래 직접 연결될 수 있습니다. 연결 기록의 대상, 적용된 규칙, 정책 그룹, 최종 출구를 함께 살펴보세요. 소형 라우터의 처리량에는 보편적인 ‘표준값’이 없습니다. 암호화 프로토콜, 단일 코어 성능, MTU, 회선 품질, 로그 양이 모두 결과에 영향을 미칩니다. 같은 장비와 대상에서 직접 연결과 프록시 연결을 비교하세요.

장기 운영: 업데이트, 권한, 장애 복구

설정 업데이트: 구독을 업데이트한 뒤 문법과 리소스 로드를 확인하고 현재 설정을 교체하세요. 이전에 정상 작동한 설정을 보관하고, 지속적으로 유지할 변경은 플러그인 덮어쓰기 기능이나 별도로 관리하는 파일에 저장하세요.
커널 업데이트: 새 커널이 현재 설정 필드, 규칙, 실행 옵션을 지원하는지 먼저 확인하고 업데이트 후 설정 테스트를 다시 실행하세요. 구독 새로고침은 프로그램 업데이트를 대신하지 않습니다.
관리 인터페이스: 제어 인터페이스는 가급적 루프백 주소에 바인딩하세요. LAN 접근이 꼭 필요하다면 인증 정보를 설정하고 접속 출처를 제한하세요. WAN 쪽에 프록시 포트나 제어 포트를 열어서는 안 됩니다.
저장 공간 관리: 디버그 로그를 대량으로 플래시에 계속 기록하지 마세요. 규칙 리소스를 업데이트할 때 다운로드 실패와 남은 공간도 고려하고, 유일한 설정 파일을 임시 디렉터리에 두지 마세요.
서비스 종료 및 정리: 서비스를 중지할 때 해당 서비스가 만든 트래픽 가로채기 규칙, 라우팅, DNS 전달 설정을 함께 제거하세요. 프로세스가 종료된 뒤에도 트래픽이 작동하지 않는 진입점으로 향하는 일을 막을 수 있습니다.

복구할 때는 먼저 테스트 단말의 게이트웨이와 DNS를 원래 값으로 되돌린 다음 보조 라우터의 트래픽 가로채기를 해제하세요. 메인 라우터에 배포했다면 미리 준비한 서비스 중지 및 규칙 복구 절차를 사용하세요. 장애 후 끊긴 원격 연결에 의존하기보다 로컬 유선 관리 경로를 확보해 두는 편이 안전합니다.

PC 한 대에서만 구독을 사용하려는 경우 먼저 데스크톱 클라이언트에서 설정을 확인한 다음 라우터의 트래픽 가로채기를 고려하세요. 라우터 배포의 핵심은 커널 파일을 복사하는 것이 아니라 트래픽 진입, 도메인 조회, 프록시 출구, 응답 경로가 서로 일치하도록 구성하는 데 있습니다.