라우터·보조 라우터에서 mihomo 실행하기: 설치 방식, 하드웨어 요구 사항 및 설정 가이드

설치 위치 선택: 게이트웨이 위치를 정한 뒤 트래픽 처리 방식 결정

메인 라우터의 성능이 충분하고 전체 네트워크 기기를 한곳에서 관리하려면 OpenWrt에서 mihomo를 직접 실행할 수 있습니다. 기존 메인 라우터를 유지하면서 일부 기기만 연결하려면 보조 라우터를 사용하는 편이 단계별 테스트에 유리합니다. 처음에는 수동 프록시부터 확인하고, DNS를 연결한 다음 투명 프록시를 활성화하세요. 세 가지를 한꺼번에 변경하면 장애 원인을 찾기 어렵습니다.

mihomo는 Clash Meta에서 발전한 프록시 코어로, 프로토콜 연결과 규칙 매칭, DNS 등의 기능을 담당합니다. 라우터 펌웨어가 아니며 완전한 라우터 관리 화면도 제공하지 않습니다. OpenWrt 플러그인은 보통 설정 생성, 프로세스 관리, 방화벽 규칙 설치, LuCI 페이지 제공을 맡습니다. 바이너리를 직접 실행하면 이런 작업을 직접 처리해야 합니다.

설치 위치	연결 방식	주요 관리 항목
OpenWrt 메인 라우터	네트워크 출구에서 LAN 트래픽 처리	방화벽, DNS, 하드웨어 오프로드
OpenWrt 보조 라우터	지정한 기기의 게이트웨이를 보조 라우터로 설정	응답 경로, DHCP, 같은 서브넷의 트래픽 전달
Linux 미니 PC	수동 프록시로 사용하거나 게이트웨이로 설정	서비스 관리, 트래픽 전달, 라우팅, 방화벽
컨테이너에서 실행하는 mihomo	먼저 명시적 프록시를 제공한 뒤 투명 프록시 적용 검토	네트워크 네임스페이스, 기기 연결, 권한

하드웨어 요구 사항: 아키텍처, 사용 가능 메모리, 저장 공간 확인

아키텍처는 운영체제 기준으로 확인

먼저 SSH로 아래 명령을 실행하세요. CPU가 64비트를 지원한다고 해서 설치된 펌웨어도 64비트인 것은 아닙니다. 바이너리를 내려받을 때는 실제 시스템 아키텍처에 맞춰야 합니다. ARM은 명령어 세대도 확인해야 하며, MIPS는 엔디언을 구분해야 합니다. 고급 명령어 세트용 빌드는 구형 프로세서에서 그대로 실행할 수 없습니다.

uname -m
cat /etc/openwrt_release
free -m
df -h /overlay
df -h /tmp

예를 들어 aarch64는 보통 ARM64, x86_64는 64비트 x86을 뜻합니다. 실행 후 잘못된 명령어 오류가 나오면 먼저 빌드 요구 사항을 확인하세요. 실행할 수 없다는 오류가 나면 구독을 바꾸기보다 파일 아키텍처와 실행 권한, 실행 환경을 점검해야 합니다.

실행 여유를 고려해 용량 계획

메모리 256MB 기기: 여유가 매우 부족한 환경입니다. 규칙 세트와 구독 규모를 줄이고, 규칙 업데이트 중 남은 메모리를 확인하세요. 시작 직후 사용량만 봐서는 안 됩니다.
메모리 512MB 기기: 가벼운 가정용 설치를 검토하기 위한 출발점입니다. 무선 서비스와 파일 공유, 다른 플러그인의 메모리 사용량도 고려해야 합니다.
메모리 1GB 이상: 여러 서비스를 함께 실행하거나 큰 규칙 세트를 사용하는 데 더 적합하지만, 실제 연결 수에 따른 메모리 사용량은 계속 확인해야 합니다.
저장 공간: 초기 계획에서는 쓰기 가능한 공간을 최소 100MB 확보하는 것이 좋습니다. 코어와 설정, 규칙 데이터, 업데이트 임시 파일을 저장하기 위한 기준이며 모든 구성에 공통으로 적용되는 최소 요구량은 아닙니다.

OpenWrt의 /tmp는 보통 메모리 파일 시스템을 사용합니다. 큰 파일을 저장하면 메모리를 소모하고 재부팅 후 사라질 수도 있습니다. 처리량은 CPU 단일 코어 성능과 암호화 프로토콜, 네트워크 드라이버, 투명 프록시 경로의 영향을 모두 받으므로 기가비트 포트가 있다고 프록시 속도도 기가비트에 도달한다고 볼 수는 없습니다.

설치 방식: 플러그인 관리, 네이티브 서비스, 컨테이너

OpenWrt 플러그인: 하나의 관리 화면에서 설정

현재 펌웨어 버전과 방화벽 체계에 맞는 플러그인을 선택하세요. 최신 OpenWrt는 대체로 firewall4와 nftables를 사용하고, 구형 환경은 firewall3와 iptables를 사용할 수 있습니다. 설치 전에 플러그인 문서를 확인하고 구버전 방화벽 스크립트를 새 시스템에 그대로 적용하지 마세요.

현재 네트워크와 DHCP, 방화벽 설정을 백업하고 라우터 LAN 주소와 SSH 접속 방법을 기록해 둡니다.
플러그인으로 설치하거나 아키텍처에 맞는 mihomo 코어를 선택한 뒤, 해당 코어를 지원하는 구독 설정을 추가합니다.
투명 프록시를 먼저 끄고 설정을 불러올 수 있는지, 노드에 연결되는지 확인한 다음 DNS와 트래픽 처리를 차례로 활성화합니다.
플러그인이 설정 파일을 다시 생성하는지 확인하세요. 계속 유지해야 할 변경 사항은 플러그인이 제공하는 덮어쓰기 또는 추가 설정 메뉴에 넣어야 합니다.

플러그인 메뉴 이름은 프로젝트와 버전에 따라 다르므로 데스크톱 클라이언트의 설정 경로를 그대로 따라서는 안 됩니다. 프록시 플러그인 두 개가 동시에 DNS나 투명 프록시를 처리하게 하지 마세요. 포트 충돌이나 규칙 덮어쓰기, 프록시 중복이 발생할 수 있습니다.

네이티브 바이너리: 프로세스와 부팅 시 실행을 직접 관리

아래 예시는 코어가 /usr/bin/mihomo에 설치되어 있고 설정이 /etc/mihomo/config.yaml에 저장되어 있다고 가정합니다. 먼저 구문을 확인한 뒤 포그라운드에서 실행해 로그를 살펴봅니다:

/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

설정 검사에 통과해도 원격 노드에 연결할 수 있거나 투명 프록시가 작동한다는 뜻은 아닙니다. 포그라운드 테스트를 마친 뒤 OpenWrt에서는 procd로 서비스를 관리하고, systemd를 사용하는 Linux에서는 작업 디렉터리와 재시작 정책을 지정한 서비스 유닛을 만드세요. SSH에서 백그라운드로만 실행하면 터미널을 닫거나 기기를 재부팅한 뒤 서비스가 중단될 수 있습니다.

컨테이너: 투명 게이트웨이보다 명시적 프록시가 간편

일반 브리지 네트워크에 포트 매핑을 더하면 HTTP 또는 SOCKS 프록시를 먼저 제공할 수 있습니다. TUN을 사용하려면 보통 /dev/net/tun 접근 권한과 네트워크 관리 권한, 적절한 네트워크 모드가 필요합니다. 컨테이너 내부의 라우팅은 해당 네트워크 네임스페이스에만 영향을 주며 호스트나 전체 LAN 트래픽을 자동으로 처리하지 않습니다. 문제를 찾겠다고 모든 권한을 열지 말고, 트래픽이 어느 계층에서 코어로 들어가야 하는지 먼저 확인하세요.

보조 라우터 구성: 게이트웨이와 DNS를 따로 확인

구체적인 네트워크를 예로 들어 보겠습니다. 메인 라우터는 192.168.50.1, 보조 라우터는 고정 주소 192.168.50.2를 사용하고, 두 장비의 서브넷 마스크는 모두 255.255.255.0입니다. 보조 라우터의 기본 게이트웨이는 메인 라우터로 설정합니다. 처음에는 컴퓨터 한 대만 변경하고 나머지 기기는 기존 설정을 유지하세요.

테스트 모드	단말 설정	확인할 항목
수동 프록시	게이트웨이는 계속 .1로 두고, 앱의 프록시는 .2:7890으로 설정	코어, 구독, 노드 연결 상태
투명 프록시	기본 게이트웨이를 .2로 바꾸고, 설정된 LAN DNS 서비스를 DNS로 지정	트래픽 전달, 규칙, DNS 처리
기존 네트워크로 복구	게이트웨이와 DNS를 .1 또는 기존 DHCP 설정으로 복원	보조 라우터 문제와 상위 네트워크 문제 구분

DNS만 바꿔서는 모든 연결이 자동으로 보조 라우터를 거치지 않습니다. 게이트웨이만 바꿔도 도메인 이름이 예상대로 조회된다고 보장할 수 없습니다. 투명 프록시를 사용하려면 IP 포워딩이 허용되어야 하며 방화벽과 응답 경로도 올바르게 설정해야 합니다. 특히 단일 포트 보조 라우터에서는 직접 연결된 트래픽이 보조 라우터에서 메인 라우터로 전달되는 동안 응답은 메인 라우터에서 단말로 바로 전송되어 경로가 비대칭이 될 수 있습니다.

일부 구성은 응답 경로를 안정화하기 위해 소스 NAT를 사용하지만, 이 경우 상위 라우터에서 보이는 소스 주소가 바뀝니다. NAT 명령 한 줄을 무조건 복사하지 말고 사용하는 플러그인의 네트워크 구성 안내에 따라 설정하세요. 단말 한 대에서 정상 작동을 확인한 뒤 DHCP 옵션 3으로 게이트웨이를, 옵션 6으로 DNS를 배포할지 검토합니다. 같은 브로드캐스트 도메인에서 DHCP 서버를 임의로 하나 더 켜지 마세요.

설정 핵심: 제한된 LAN 프록시 포트부터 열기

아래는 앞서 설명한 네트워크를 위한 기본 설정 조각이며, 완성된 구독 설정은 아닙니다. 수신 주소와 혼합 프록시 포트, DNS 진입점의 관계만 보여줍니다. 노드와 정책 그룹, 규칙은 유효한 설정에서 가져와야 합니다. 플러그인을 사용한다면 플러그인이 지원하는 방식으로 설정하고 생성된 파일을 직접 수정하지 마세요.

mixed-port: 7890
allow-lan: true
bind-address: 192.168.50.2
mode: rule
log-level: info
ipv6: false

dns:
  enable: true
  listen: 192.168.50.2:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 223.5.5.5
    - 1.1.1.1

mixed-port: 7890은 HTTP와 SOCKS 프록시를 함께 제공하는 포트입니다. 투명 프록시 포트가 아니므로 단말에서 프록시를 직접 설정해야 사용할 수 있습니다.
allow-lan: true를 설정하면 LAN에서 접속할 수 있지만, 방화벽에서는 신뢰할 수 있는 LAN만 허용해야 합니다. 7890 포트를 인터넷에 노출하지 마세요.
bind-address는 예시에서 보조 라우터 주소에 바인딩합니다. 실제 설치 시 이 주소가 로컬 네트워크 인터페이스에 할당되어 있어야 합니다.
1053은 예시 DNS 업스트림의 수신 포트입니다. 일반 단말은 기본적으로 53번 포트에 질의하므로 DHCP에서 1053을 별도로 지정할 수 없습니다.

OpenWrt에서는 dnsmasq가 LAN의 53번 포트를 계속 제공하고 질의를 mihomo의 1053번 포트로 전달하도록 구성할 수 있습니다. 이때 전달 경로를 반드시 확인하세요. dnsmasq는 mihomo를 가리켜야 하고, mihomo의 업스트림은 같은 dnsmasq로 되돌아가면 안 됩니다. 그렇지 않으면 DNS 순환이 발생합니다. 예시의 공용 DNS 서버는 형식을 보여주기 위한 것이므로 실제 네트워크 연결 상태와 분기 요구 사항에 맞춰 설정해야 합니다.

투명 프록시와 TUN: 같은 트래픽을 중복 처리하지 않기

일반적인 투명 프록시 방식에는 방화벽 리디렉션, TProxy, TUN이 있습니다. 리디렉션은 보통 TCP에 사용됩니다. TProxy는 TCP와 UDP를 처리할 수 있지만 관련 커널 기능과 정책 라우팅, 방화벽 규칙이 필요합니다. TUN은 가상 네트워크 인터페이스를 통해 트래픽을 코어로 전달하며, 모든 라우팅 및 DNS 문제가 자동으로 해결되는 것은 아닙니다.

함께 확인해야 할 세 가지

유입: LAN에서 전달된 트래픽이 예상한 체인이나 TUN 경로로 들어오는지 확인합니다. 라우터 자체 트래픽만 처리한다고 해서 LAN 기기까지 연결된 것은 아닙니다.
제외: 프록시 노드 서버 주소와 LAN 주소, 코어 자체의 아웃바운드 트래픽 등이 올바르게 제외되는지 확인해 프록시 루프를 방지합니다.
응답: 정책 라우팅과 방화벽 마크, 연결 추적이 일치하는지, UDP와 TCP가 모두 예상한 경로를 거치는지 확인합니다.

mihomo의 TUN은 auto-route 같은 옵션으로 라우팅 설정을 지원합니다. 지원되는 Linux 환경에서는 auto-redirect를 사용해 리디렉션을 보조할 수도 있습니다. 활성화 여부는 플러그인 설계를 따라야 합니다. 플러그인의 TProxy 처리와 별도의 TUN 자동 처리를 동시에 켜고 두 기능이 알아서 조정되기를 기대하지 마세요.

문제를 찾을 때는 소프트웨어 또는 하드웨어 트래픽 오프로드를 잠시 끄고 동작을 비교해 볼 수 있습니다. 일부 가속 경로는 필요한 처리 체인을 우회할 수 있습니다. QUIC 동영상이나 게임만 문제가 생긴다면 UDP 전달과 노드의 프로토콜 지원을 따로 확인하세요. 브라우저에서 웹페이지 하나가 열린다고 모든 트래픽이 정상이라고 단정할 수는 없습니다.

DNS, Fake-IP, IPv6: 이름 조회와 연결 경로를 일치시키기

Fake-IP는 도메인에 매핑 주소를 반환하며, 예시에서는 198.18.0.0/16을 사용합니다. mihomo가 이 주소를 인식해 도메인과 연결해야 하므로 공용 IP 대상처럼 상위 라우터에 바로 전달해서는 안 됩니다. 단말이 Fake-IP를 받은 뒤에는 해당 연결도 같은 프록시 처리 경로로 들어와야 합니다.

LAN 도메인: 프린터와 NAS, 라우터 관리 도메인은 로컬 DNS 조회를 유지해야 합니다. 필요하면 Fake-IP 필터와 DNS 정책을 함께 설정하세요. 필터에 추가하는 것만으로는 부족하며 로컬 DNS 응답이 어디서 오는지도 확인해야 합니다.
앱 자체 암호화 DNS: 브라우저의 DoH는 시스템 DNS를 우회할 수 있습니다. 기존의 53번 포트 가로채기로는 이런 질의를 처리할 수 없으므로 테스트할 때 브라우저가 별도의 DNS 서버를 설정했는지 기록하세요.
IPv6: 단말이 라우터 광고를 받아 별도의 기본 경로를 사용할 수 있습니다. IPv4 게이트웨이만 변경하면 IPv6 연결은 프록시를 거치지 않고 직접 나갈 수 있습니다.
설정 복원: Fake-IP를 끄거나 DNS를 전환한 뒤에는 단말과 앱의 캐시를 지워 오래된 매핑 주소를 계속 사용하지 않도록 하세요.

예시에서는 mihomo의 IPv6 사용과 AAAA 응답을 비활성화했지만, 이것이 전체 LAN의 IPv6를 끄는 것은 아닙니다. 설치 전에 IPv6 트래픽을 완전히 처리할지, 테스트 네트워크에서 라우터 광고와 관련 서비스를 일시적으로 비활성화할지 결정하세요. IPv6 경로를 빠뜨린 문제를 규칙이 무작위로 작동하지 않는 현상으로 오해하지 마세요.

검증과 복구: 연결 경로를 따라 단계별로 진단

한 번에 변수 하나만 바꾸고 변경 전후 설정을 기록하세요. 아래 명령은 프로세스 로그와 수신 포트, 라우팅, DNS를 확인하는 데 사용합니다. 시스템에 설치된 도구에 맞춰 필요한 명령만 실행하세요. 한 번의 문제 해결을 위해 모든 도구를 설치할 필요는 없습니다.

logread | grep -i mihomo
ss -lntup
ip route show
ip rule show
nslookup example.com 192.168.50.2
curl -I -x http://192.168.50.2:7890 https://example.com

nslookup 명령은 보조 라우터의 53번 포트에서 제공하는 LAN DNS 서비스를 확인하며, 예시의 1053번 포트 수신을 테스트하지 않습니다. 앞단 DNS 서비스를 구성하지 않았다면 이 결과만으로 mihomo DNS 모듈의 장애라고 판단할 수 없습니다. curl은 명시적 HTTP 프록시를 테스트하므로 투명 프록시와는 검증 경로가 다릅니다.

증상	우선 확인할 항목	다음 단계
설정을 불러올 수 없음	들여쓰기, 필드 유형, 코어 호환성	설정 검사를 실행해 오류가 발생한 줄 확인
수동 프록시도 연결되지 않음	수신 주소, LAN 방화벽, 노드 연결 가능 여부	먼저 프록시 포트 하나의 연결부터 복구
수동 프록시는 정상인데 게이트웨이를 바꾸면 실패	포워딩 설정, 트래픽 처리 규칙, 응답 경로	라우팅과 방화벽 카운터 확인
일부 도메인에서 문제 발생	DNS 캐시, Fake-IP, 로컬 도메인 조회	시스템과 앱의 DNS 응답 경로 비교
IPv4는 정상인데 일부 연결은 프록시를 우회	IPv6 기본 경로와 트래픽 처리 범위	IPv4와 IPv6 경로를 각각 확인

검증을 마친 뒤 부팅 시 자동 실행을 활성화하고 한 번 재부팅해 설정과 규칙 데이터, 방화벽이 순서대로 복구되는지 확인하세요. 테스트에 실패하면 먼저 단말의 게이트웨이와 DNS를 기존 메인 라우터 설정으로 되돌린 다음 플러그인에서 트래픽 처리를 끄고 해당 방화벽 설정을 복구합니다. 코어만 중지하면 작동하지 않는 인터페이스를 가리키는 규칙이 남을 수 있습니다. 보조 라우터를 거치지 않는 관리 접속 경로를 하나 유지하면 설정 오류로 네트워크 전체에 접속할 수 없게 되는 일을 줄일 수 있습니다.