OpenWrt 보조 라우터에 mihomo 코어 설치하기: 배포 방식과 네트워크 구성

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

OpenWrt에서 mihomo를 실행할 때 핵심은 바이너리 설치가 아니라 대상 트래픽이 mihomo를 통과하도록 구성하는 것입니다. mihomo는 Clash Meta의 후속 코어 이름입니다. 코어는 프록시 프로토콜, 규칙 매칭, 연결 처리를 담당하고 OpenWrt는 네트워크 인터페이스, 라우팅, 방화벽, 서비스 관리를 담당합니다. 설정 파일의 문법 검사를 통과했다고 해서 LAN 기기의 트래픽까지 자동으로 처리되는 것은 아닙니다.

메인 라우터는 보통 인터넷 연결, NAT, DHCP를 직접 담당합니다. 보조 라우터는 LAN에 추가로 연결하는 장치이며, 메인 라우터가 계속 인터넷 회선에 접속하거나 상위 네트워크와 연결됩니다. 이 글에서는 단일 LAN 포트와 동일 서브넷을 사용하는 보조 라우터를 예로 듭니다. 두 개의 LAN 포트를 직렬로 연결하는 장치는 실제 인터페이스에 맞춰 포워딩 영역을 다시 설계해야 하며, 동일 서브넷 설정을 그대로 적용할 수 없습니다.

예시 네트워크 구성과 역할
항목	메인 라우터 구성	보조 라우터 구성
인터넷 출구	OpenWrt가 상위 네트워크에 직접 연결	기존 메인 라우터를 인터넷 출구로 유지
기기의 기본 게이트웨이	OpenWrt의 LAN 주소	처리할 기기의 게이트웨이를 보조 라우터로 지정
DHCP 서비스	보통 OpenWrt에서 제공	메인 라우터에서 계속 제공 가능
장애 영향	모든 기기에 영향을 줄 수 있음	테스트 기기 한 대부터 지정 가능
주요 고려 사항	인터넷 출구 방화벽 및 리소스 부하	게이트웨이, 응답 경로, DNS 일관성

동일 서브넷 구성 예시

메인 라우터: 192.168.10.1/24, 인터넷 연결과 DHCP를 담당합니다.
OpenWrt 보조 라우터: 192.168.10.2/24, 기본 게이트웨이는 192.168.10.1입니다.
테스트 기기: 192.168.10.100/24, 기본 게이트웨이와 DNS를 모두 우선 192.168.10.2로 설정합니다.

주소는 실제 LAN 주소로 바꿔야 합니다. 보조 라우터에는 고정 주소를 지정하거나 DHCP 서버에서 고정 임대를 설정하고, 동적 주소 범위와 겹치지 않게 하세요. 두 장치가 조정 없이 같은 브로드캐스트 도메인에 각각 DHCP 설정을 배포해서는 안 됩니다.

설치 전 점검: 아키텍처, 저장 공간, 펌웨어 지원

먼저 OpenWrt의 ‘상태’ → ‘개요’에서 펌웨어 정보를 확인한 다음 SSH로 CPU와 시스템 정보를 확인하세요. 제품 설명에 ‘64비트 프로세서’라고 적혀 있어도 펌웨어 아키텍처를 대신할 수는 없습니다. 같은 하드웨어라도 비트 수가 다른 사용자 공간을 실행할 수 있습니다.

ubus call system board
uname -m
cat /etc/openwrt_release
df -h /overlay /tmp
free -m

x86_64는 보통 amd64 빌드, aarch64는 보통 arm64 빌드에 해당합니다. 32비트 ARM은 명령어 집합도 확인해야 하고, MIPS는 엔디안과 부동소수점 ABI를 구분해야 합니다. 릴리스 파일의 이름은 버전에 따라 달라질 수 있으므로 mihomo 릴리스 안내에 따라 선택하세요. 파일명에 ‘linux’가 있다고 해서 사용할 수 있다고 판단해서는 안 됩니다.

패키지 관리자와 커널 모듈

opkg를 사용하는 펌웨어에서는 opkg print-architecture로 패키지 아키텍처를 확인할 수 있습니다. apk를 사용하는 펌웨어에서는 apk --print-arch로 확인할 수 있습니다. 두 패키지 관리자의 설치 명령을 섞어 쓰지 마세요.
TUN 방식은 펌웨어에서 TUN을 지원해야 하며, 관련 패키지로는 kmod-tun이 흔히 사용됩니다. TPROXY 방식은 해당 방화벽 및 커널 모듈 지원이 필요합니다.
OpenWrt 22.03부터 기본 방화벽은 대체로 firewall4이며, 내부에서 nftables를 사용합니다. 이전 안내에 나온 iptables 규칙을 firewall4 환경에 그대로 복사하지 마세요.
커널 모듈은 현재 실행 중인 펌웨어의 커널과 버전이 맞아야 합니다. 패키지 저장소를 사용할 수 없거나 버전이 일치하지 않는다면 먼저 펌웨어와 패키지 저장소의 호환성 문제를 해결하세요.

코어 직접 실행: 설정 테스트와 명시적 프록시부터

일반적인 배포 방식은 OpenWrt 플러그인으로 코어를 관리하거나 mihomo를 직접 실행하는 두 가지입니다. 플러그인은 보통 서비스 스크립트, 방화벽, DNS, 구독 업데이트를 관리하고, 직접 실행하는 경우에는 각 기능을 따로 설정해야 합니다. 하나의 인스턴스는 두 방식 중 하나로만 관리하세요. 플러그인이 실행한 코어와 수동 실행 프로세스가 같은 포트를 두고 충돌할 수 있습니다.

아래 예시는 아키텍처에 맞는 코어를 /usr/bin/mihomo에 압축 해제하고, 완성된 설정을 /etc/mihomo/config.yaml에 저장한 것으로 가정합니다. 이는 이 글에서 사용하는 경로이며 모든 플러그인의 기본 경로는 아닙니다. 구독에 프록시 노드 목록만 포함되어 있다면 프록시 그룹과 규칙을 포함한 전체 설정을 추가해야 합니다.

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

-v는 프로그램 실행 여부와 실제 버전을 확인할 때, -t는 설정을 검사할 때 사용합니다. Exec format error가 나타나면 아키텍처와 파일 압축 해제 여부를 먼저 확인하세요. YAML 파싱 오류가 발생하면 들여쓰기, 필드 유형, 참조하는 규칙 세트를 수정해야 합니다. 네트워크 설정을 계속 추가하지 마세요.

7890 포트로 프록시 연결 확인

완성된 설정에 아래 조각을 먼저 추가해 볼 수 있습니다. 이 예시는 보조 라우터의 LAN 주소에서만 수신하도록 허용합니다. 다른 기기의 접속 허용 여부는 방화벽 설정에도 달려 있습니다. allow-lan을 켠 뒤에는 해당 포트를 인터넷에 노출해서는 안 됩니다.

mixed-port: 7890
allow-lan: true
bind-address: 192.168.10.2
mode: rule
log-level: info

테스트를 통과하면 SSH에서 코어를 포그라운드로 실행해 오류를 확인하세요. 이때 동일한 인스턴스를 동시에 하나 더 실행하지 마세요.

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

테스트 컴퓨터의 HTTP 프록시를 192.168.10.2:7890으로 지정하거나, 아래 명령으로 HTTPS 요청을 보내세요. 요청에 성공하면 명시적 프록시 진입점, 노드, 대상 사이트 간의 기본 경로가 작동한다는 뜻입니다. UDP나 투명 프록시까지 작동한다는 의미는 아닙니다.

curl -I --proxy http://192.168.10.2:7890 https://example.com/

포그라운드 테스트를 마친 뒤 procd 서비스 스크립트로 관리하도록 전환하고, 부팅 시 자동 실행과 비정상 종료 후 재시작을 설정하세요. 서비스에는 절대 경로를 사용하고 로그를 시스템 로그에 연결하세요. SSH를 종료하면 끝날 수 있는 임시 프로세스에 의존하지 마세요.

투명 프록시 방식 선택: REDIRECT, TPROXY, TUN

기기에서 프록시를 직접 설정하면 해당 설정을 따르는 앱에만 적용됩니다. 보조 라우터에서 일반 포워딩 트래픽까지 처리하려면 투명 프록시 진입점과 라우팅도 구성해야 합니다. 아래 세 방식은 필요에 따라 모두 켜도 되는 스위치가 아닙니다. 특히 플러그인 규칙과 직접 작성한 규칙이 같은 트래픽을 중복으로 가로채지 않게 하세요.

Linux 투명 프록시 방식 비교
방식	주요 진입점	추가 조건
REDIRECT	`redir-port: 7892`, 보통 TCP에 사용	NAT 리다이렉션 규칙이 필요하며, 이 설정만으로 UDP까지 처리된다고 볼 수 없습니다.
TPROXY	`tproxy-port: 7893`, TCP와 UDP 처리 가능	투명 소켓 지원, 마크 설정, 정책 라우팅 필요
TUN	가상 네트워크 인터페이스	TUN 지원, 라우팅 및 포워딩 권한, 올바른 방화벽 처리가 필요

TUN 설정 예시의 적용 범위

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53
    - tcp://any:53

이 설정 조각은 mihomo의 TUN 설정 방향을 보여 주는 예시이며, 완성된 OpenWrt 투명 프록시 설치 스크립트가 아닙니다. auto-route로 관련 라우트를 설정할 수 있지만, 모든 LAN 구성에서 통신 경로가 자동으로 완성되는 것은 아닙니다. LAN 포워딩 트래픽이 TUN으로 들어가는지, 아웃바운드 연결이 메인 라우터에 도달하는지, firewall4가 필요한 포워딩을 허용하는지 확인해야 합니다.

출구가 여러 개인 환경에서는 자동 감지가 의도와 다른 출구를 선택할 수 있으므로 실제 라우팅을 확인하고, 필요하면 코어 설정 문서에 따라 인터페이스를 지정하세요. Linux의 auto-redirect는 nftables를 사용하는 별도 옵션입니다. 지원 여부와 동작은 실제 mihomo 버전을 기준으로 확인해야 하며, 최신 버전 예시를 구버전 코어에 그대로 적용하면 안 됩니다.

게이트웨이와 DNS: 각각 따로 확인

기본 게이트웨이는 일반 트래픽의 다음 홉을 정하고, DNS는 도메인 조회를 보낼 곳을 결정합니다. DNS만 바꾸면 실제 연결은 보조 라우터를 우회할 수 있습니다. 게이트웨이만 바꾸면 기기가 이전 DNS 캐시, IPv6 DNS, 앱 자체의 암호화 DNS를 계속 사용할 수 있습니다.

기기 한 대로 게이트웨이부터 확인

LuCI의 ‘네트워크’ → ‘인터페이스’ → ‘LAN’ → ‘편집’에서 보조 라우터 주소와 서브넷 마스크를 확인하세요. 펌웨어에 따라 탭 이름이 조금씩 다를 수 있으므로 실제 화면을 기준으로 확인해야 합니다.
보조 라우터 자체의 기본 경로가 192.168.10.1을 통해 나가는지 확인하세요. ip route show default 명령으로 점검할 수 있습니다.
테스트 기기의 기본 게이트웨이만 192.168.10.2로 바꾸고, 메인 라우터가 전체 네트워크에 DHCP로 배포하는 설정은 아직 수정하지 마세요.
기기에서 보조 라우터와 메인 라우터에 모두 접속되는지 확인한 다음 외부 사이트에 연결해 보세요. 게이트웨이를 변경한 뒤에도 기존 연결은 이전 경로를 계속 사용할 수 있습니다.

이후 DHCP로 여러 기기에 설정을 배포한다면 IPv4 옵션 3은 기본 게이트웨이, 옵션 6은 DNS 서버입니다. 변경 후 기기의 임대를 갱신하고 실제로 받은 값을 확인하세요. 동일 서브넷의 보조 라우터에서는 직접 연결된 트래픽의 비대칭 응답 경로나 ICMP 리다이렉트가 발생할 수 있습니다. 패킷을 캡처해 확인한 뒤, 관리 대상 포워딩 트래픽에 소스 NAT를 적용할지 결정하세요. 소스 NAT를 적용하면 메인 라우터에서 보이는 소스 주소가 바뀌므로 ‘마스커레이딩 활성화’를 모든 구성에 필수인 단계로 여겨서는 안 됩니다.

dnsmasq의 53 포트 유지

문제를 단계별로 확인하기 쉬운 구성은 dnsmasq가 LAN의 53 포트를 계속 수신하고, mihomo DNS는 127.0.0.1:1053에서 수신하도록 한 뒤 dnsmasq가 상위 DNS 조회를 mihomo로 전달하는 방식입니다. 아래 설정은 기존 구성에 추가해 사용하며, 예시 상위 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

일반적인 LuCI 화면을 사용하는 펌웨어라면 ‘네트워크’ → ‘DHCP/DNS’ → ‘일반 설정’의 DNS 전달 항목에 127.0.0.1#1053을 입력할 수 있습니다. 다른 상위 DNS 서버를 여전히 참조하고 있는지도 확인해 예정된 경로를 우회하지 않도록 하세요. mihomo의 상위 DNS가 다시 dnsmasq를 가리키면 DNS 루프가 발생합니다.

Fake-IP가 반환한 가상 주소는 투명 프록시 경로에서 올바르게 처리되어야 합니다. 명시적 프록시를 테스트하는 단계에서는 서둘러 전체 네트워크의 DNS를 이 모드로 전환하지 마세요. LAN 도메인, 프린터, 특정 앱과 호환성 문제가 생기면 실제 도메인에 맞춰 필터를 설정하거나 적절한 해석 모드를 선택하세요. 모든 DNS 설정을 한꺼번에 지우지 마세요.

예시 상위 DNS는 일반 DNS로, 수신과 전달 관계를 설명하기 위한 것입니다. 조회가 암호화된다는 뜻은 아닙니다. 브라우저의 보안 DNS, 앱 내 DoH, Android 비공개 DNS는 dns-hijack을 설정했다고 해서 모두 자동으로 가로채지는 않습니다.

단계별 문제 해결: 프로세스부터 IPv6까지

문제를 해결하는 동안 게이트웨이를 바꾸지 않은 관리 기기 한 대를 남겨 두고 기존 설정을 기록하세요. 노드를 계속 바꾸기보다 진입점, 라우팅, DNS 해석, 규칙 순서로 확인하는 편이 원인을 찾기 쉽습니다. 아래 명령은 상태 확인용이며 방화벽 설정을 대신하지 않습니다.

pgrep -af mihomo
logread -e mihomo
ip addr show
ip route show table all
ip rule show
nft list ruleset
nslookup example.com 192.168.10.2

자주 발생하는 증상과 우선 점검 항목
증상	우선 확인할 항목	판단 기준
코어가 시작 직후 종료됨	설정 검사, 포트 점유 여부, 파일 권한	시작 로그에 수신 실패나 설정 오류가 있는지
7890은 작동하지만 투명 프록시는 작동하지 않음	기기 게이트웨이, 포워딩 경로, 정책 라우팅	실제 서비스 트래픽이 보조 라우터에 도달하는지
외부 IP에는 연결되지만 도메인 접속은 실패	53 및 1053 포트의 수신과 상위 DNS 전달	DNS 조회 시간 초과 여부와 해석 루프 발생 여부
TCP는 정상이나 게임 또는 QUIC이 작동하지 않음	UDP 처리, 노드 프로토콜, 서버 지원 여부	TCP 트래픽만 리다이렉션되는지
일부 앱이 여전히 기존 출구를 사용	IPv6 기본 경로, 앱별 프록시 설정, VPN	기기에 사용할 수 있는 다른 네트워크 경로가 있는지

IPv4 게이트웨이를 바꿔도 IPv6 경로는 그대로 유지됨

기기가 보조 라우터를 가리키는 IPv4 게이트웨이를 받더라도 메인 라우터의 RA를 통해 IPv6 기본 경로를 받을 수 있습니다. 이 경우 IPv6 연결은 메인 라우터를 직접 통과할 수 있습니다. IPv4와 IPv6의 라우팅, DNS, 방화벽을 각각 확인하고 IPv6까지 완전히 처리할지, 테스트 네트워크에서 IPv6 경로 배포를 잠시 중단할지 결정하세요. mihomo에서 IPv6 옵션 하나를 끄는 것만으로 기기에 이미 설정된 경로가 삭제되지는 않습니다.

처리량 테스트는 지연 시간만 확인해서는 안 됩니다

보조 라우터의 CPU, 암호화 프로토콜, 포트 속도, 가상 머신 네트워크 카드가 모두 처리량에 영향을 줄 수 있습니다. 먼저 일반 LAN 전송을 측정한 뒤 같은 대상을 대상으로 명시적 프록시와 투명 프록시의 다운로드 속도를 비교하세요. 테스트 중 CPU 사용률, 트래픽 경로, 실제 사용 노드를 기록해야 합니다. 한 번의 지연 시간 테스트로 대역폭을 판단할 수는 없습니다. 문제를 찾는 동안에는 소프트웨어 또는 하드웨어 트래픽 오프로딩을 잠시 끄면 기존 고속 경로가 규칙 검증에 미치는 영향을 줄일 수 있습니다.

운영 적용과 롤백: 한 번에 한 범위씩 확대

기준 설정을 저장합니다. OpenWrt 네트워크, 방화벽, DHCP, mihomo 설정을 백업하고 메인 라우터의 기존 게이트웨이와 DNS 배포 방식을 기록합니다.
명시적 프록시를 확인합니다. 투명 프록시를 구성하기 전에 코어, 구독, 프록시 그룹, 규칙이 정상적으로 작동하는지 확인합니다.
기기 한 대로 확인합니다. 웹 접속, DNS, UDP, LAN 기기 접근, IPv6를 각각 테스트하세요. 사이트 하나만 확인해서는 안 됩니다.
재부팅 후 복구를 확인합니다. 인터페이스가 준비된 뒤 서비스가 시작되는지, DNS가 아직 시작되지 않은 프록시 경로에 의존하지 않는지, 방화벽을 다시 불러온 뒤에도 규칙이 올바른지 확인합니다.
DHCP 적용 범위를 넓힙니다. 기기 한 대에서 안정적으로 작동한 뒤 보조 라우터 주소를 단계적으로 배포하고, 메인 라우터에 직접 접속해 관리할 기기는 남겨 두세요.

롤백하려면 먼저 테스트 기기나 DHCP로 배포한 게이트웨이를 192.168.10.1로 복구하고, 사용할 수 있는 DNS도 복원한 뒤 기기의 임대를 갱신하세요. 그다음 투명 프록시 서비스를 중지하고 서비스가 관리하는 규칙을 정리합니다. mihomo만 중지한 채 이를 가리키는 DNS 전달과 투명 리다이렉션을 남겨 두면 기기의 네트워크 연결이 계속 끊길 수 있습니다.

보조 라우터 구성의 핵심은 경로를 일관되게 유지하는 것입니다. 기기의 트래픽이 올바른 게이트웨이로 전달되고, DNS가 반환한 주소가 해당 경로를 따라 처리되며, 코어의 아웃바운드 연결이 다시 가로채지 않아야 합니다. 이 세 가지를 확인한 뒤 규칙 세트, 구독 업데이트, 모니터링을 추가하면 배포를 재현하고 롤백하기 쉬워집니다. 클라이언트와 코어의 차이는 용어 빠른 확인에서, 여러 플랫폼의 설치 방법은 전 플랫폼 설치 가이드에서 확인하세요.