라우터 및 보조 라우터에서 mihomo 커널 직접 실행하기: 구조 선택과 기본 배포 절차

Clash Premium 구형 커널의 개발이 중단된 이후, 라우터 배포는 계속 업데이트되는 mihomo로 점차 전환되고 있습니다. 데스크톱 클라이언트와 달리 라우터에서는 그래픽 인터페이스가 설정 디렉터리, 권한, DNS 전달, 프로세스 관리를 대신 처리해 주지 않습니다. 따라서 배포의 핵심은 프록시 포트 하나를 열어 두는 데 그치지 않고, LAN 트래픽이 명확하고 필요할 때 되돌릴 수 있는 전달 경로를 거치도록 구성하는 것입니다.

이 글에서는 OpenWrt를 설치한 메인 라우터와 Debian, Ubuntu, ImmortalWrt 또는 기타 Linux 시스템을 실행하는 보조 라우터라는 두 가지 일반적인 환경을 다룹니다. 예시는 mihomo v1.19 계열의 설정 문법을 기준으로 하며, TUN 인계를 중심으로 설명하고 기존 방화벽 전달 방식에서 추가로 처리해야 할 부분도 함께 다룹니다. 실제 설치 전에는 장치 아키텍처와 대상 버전의 릴리스 안내를 기준으로 파일명을 다시 확인해야 합니다.

먼저 구조 선택: 메인 라우터에 직접 설치할까, 별도 보조 라우터를 둘까

메인 라우터 직접 설치는 전화 접속, DHCP, NAT, 방화벽을 담당하는 동일한 장치에 mihomo를 배치하는 방식입니다. 모든 단말의 기본 게이트웨이가 원래 이 장치를 가리키므로 트래픽 경로가 짧고, 보통 단말별로 게이트웨이를 바꿀 필요가 없습니다. 대신 프록시 설정 오류가 가정 내 전체 네트워크에 영향을 줄 수 있으며, 커널 업그레이드나 방화벽 재시작, DNS 설정 변경으로 문제가 생기면 복구 진입점도 같은 장치에 있습니다.

보조 라우터는 별도의 Linux 장치에 프록시 인계를 맡기는 방식입니다. 상위 메인 라우터가 계속 전화 접속을 처리하고, 보조 라우터는 정책 라우팅, DNS, mihomo만 담당합니다. 유지보수를 위해 장치를 중지하기 쉽고 TV, 휴대폰, 테스트 PC만 선택적으로 프록시를 통과시킬 수도 있습니다. 다만 같은 네트워크 구간에 단일 인터페이스로 연결한 보조 라우터는 반환 경로 우회, 게이트웨이 루프, DHCP 충돌이 발생하기 쉬우므로 주소와 전달 관계를 명확히 설계해야 합니다.

비교 항목	메인 라우터 직접 설치	독립 보조 라우터
기본 게이트웨이 변경	대개 필요 없음. 단말은 계속 메인 라우터 주소를 사용	DHCP 또는 단말에서 보조 라우터를 지정해야 함
장애 영향	설정 오류가 전체 네트워크에 영향을 줄 수 있음	단말 게이트웨이를 메인 라우터로 바꿔 빠르게 우회 가능
하드웨어 여유	라우터의 CPU, 플래시, 메모리 제약을 받음	x86 미니 PC나 더 높은 성능의 ARM 장치를 사용할 수 있음
유지보수 복잡도	트래픽 경로는 단순하지만 전화 접속과 방화벽을 함께 관리해야 함	장치가 하나 더 필요하며 전달, 반환 경로, DHCP를 처리해야 함
적합한 환경	네트워크 구조가 단순하고 장치 성능이 충분하며 전체 인계를 원하는 경우	단계적으로 연결하고 자주 테스트하며 빠른 복구 경로를 남기려는 경우

단일 인터페이스 보조 라우터 주소 예시

메인 라우터 주소가 192.168.1.1이고 보조 라우터를 192.168.1.2로 고정한다고 가정합니다. 보조 라우터 자체의 기본 게이트웨이는 계속 192.168.1.1로 설정하고, 인계할 단말의 게이트웨이와 DNS는 192.168.1.2를 가리키게 합니다. DHCP로 일괄 배포한다면 동일한 브로드캐스트 도메인에 DHCP 서버가 하나만 있는지 확인해야 두 장치가 서로 다른 게이트웨이를 동시에 할당하는 문제를 피할 수 있습니다.

단일 인터페이스 구조에서는 보조 라우터의 외부 인터페이스에서 소스 NAT를 수행하는 것이 반환 트래픽을 안정적으로 보조 라우터를 거치게 하는 데 유리합니다. 클라이언트의 원래 주소를 규칙 매칭에 사용하려면 메인 라우터에 클라이언트 네트워크로 향하는 정적 라우트를 추가하고, 반환 경로가 보조 라우터를 직접 우회하지 않는지 확인해야 합니다. 두 방식을 실제 패킷 경로를 판단할 수 없을 정도로 섞어 사용해서는 안 됩니다.

하드웨어, 시스템, 바이너리 아키텍처 확인

mihomo는 단일 커널 프로그램이지만 규칙 세트, 연결 추적, Fake-IP 매핑이 모두 메모리를 사용합니다. 소형 설정은 시작 후 보통 약 70~120MB를 사용하며, 대형 도메인 규칙 세트와 여러 provider, 수천 개의 연결을 로드하면 180~300MB까지 늘어날 수 있습니다. 메모리 128MB인 구형 라우터는 여유가 매우 적고, 512MB부터가 현실적인 시작점이며 1GB 이상이면 장기 실행과 잦은 규칙 업데이트에 더 적합합니다.

먼저 SSH로 시스템 아키텍처와 커널 정보를 확인합니다:

uname -m
uname -a
getconf LONG_BIT
cat /etc/os-release
free -m
df -h

`uname -m`의 일반적인 결과	일반적으로 선택	주의 사항
`x86_64`	linux-amd64	구형 CPU가 최신 명령어 집합을 지원하지 않으면 호환성 중심 빌드를 선택
`aarch64`	linux-arm64	64비트 ARM 라우터와 개발 보드에서 흔히 사용
`armv7l`	linux-armv7	시스템의 부동소수점 ABI와 릴리스 파일 안내를 확인
`mips` 또는 `mipsel`	MIPS 빅엔디언 또는 리틀엔디언 빌드에 해당	구형 장치는 성능과 사용 가능한 메모리가 대체로 더 부족함

TUN 모드는 커널 장치와 관련 모듈에도 의존합니다. ls -l /dev/net/tun을 실행해 장치 노드를 확인한 다음 ip rule, ip route, nft list ruleset으로 시스템이 정책 라우팅과 nftables 관리 기능을 갖추었는지 확인할 수 있습니다. OpenWrt에서는 LuCI의 「시스템」→「소프트웨어 패키지」에서 kmod-tun을 확인하거나 SSH로 현재 펌웨어 커널에 맞는 패키지를 설치할 수 있습니다.

설정 디렉터리를 만들고 첫 검증 완료하기

일반 Linux에서는 프로그램을 /usr/local/bin/mihomo에 두고 설정 디렉터리는 /etc/mihomo에 둘 수 있습니다. OpenWrt에서 플래시 공간이 부족하면 큰 규칙 파일을 /mnt/data/mihomo 같은 마운트 디스크에 둘 수 있지만, 부팅 서비스는 해당 마운트 지점을 사용할 수 있을 때까지 기다려야 합니다. 다음 명령은 압축 파일을 이미 로컬에서 해제한 상황을 가정하며, 파일명은 실제로 다운로드한 아키텍처 버전으로 바꿔야 합니다:

sudo install -m 0755 mihomo-linux-amd64 /usr/local/bin/mihomo
sudo mkdir -p /etc/mihomo
sudo install -m 0600 config.yaml /etc/mihomo/config.yaml

/usr/local/bin/mihomo -v
sudo /usr/local/bin/mihomo -t -d /etc/mihomo

-t는 설정 테스트에, -d는 작업 디렉터리 지정에 사용합니다. 테스트 통과는 YAML을 해석하고 주요 필드를 불러올 수 있다는 뜻일 뿐, 구독 주소, DNS 업스트림, 노드 연결까지 보장하지는 않습니다. 정식으로 실행한 뒤에는 로그에서 provider 업데이트, 수신 대기 포트, TUN 인터페이스, 규칙 매칭 결과도 확인해야 합니다.

구독은 바로 실행할 수 있는 완성 설정과 다름

데스크톱 클라이언트는 구독 가져오기, 오버라이드, 커널 매개변수를 그래픽 인터페이스로 묶어 처리하는 경우가 많지만, 라우터에서 직접 실행하려면 완전한 config.yaml이 필요합니다. 어떤 구독은 전체 Clash 설정을 반환하고, 어떤 구독은 노드 목록만 반환합니다. 후자의 경우 proxy-providers로 불러온 뒤 정책 그룹, DNS, 규칙, 수신 대기 포트를 직접 보완해야 합니다.

구독 주소에는 계정 토큰이 포함되는 경우가 많으므로 설정 파일은 관리자만 읽을 수 있도록 권한을 제한해야 합니다. provider를 업데이트한 뒤에는 원격 서버가 빈 콘텐츠를 반환하더라도 현재 작동 중인 노드 목록이 즉시 덮어써지지 않도록 이전에 정상 작동한 캐시를 남겨 두세요. 주 설정을 교체하기 전에 다음과 같이 테스트할 수 있습니다:

cp /etc/mihomo/config.yaml /etc/mihomo/config.yaml.bak
/usr/local/bin/mihomo -t -d /etc/mihomo

# 테스트 실패 시 복구
cp /etc/mihomo/config.yaml.bak /etc/mihomo/config.yaml

투명 프록시 설정: TUN, DNS, 수신 범위

mixed-port: 7890만 활성화하면 LAN 장치에서 HTTP 또는 SOCKS 프록시를 수동으로 지정해야 합니다. 이 방식만으로는 TV 앱, 게임 콘솔, 시스템 프록시 설정을 따르지 않는 프로그램을 자동으로 인계할 수 없습니다. 라우터 배포에서는 보통 TUN 또는 nftables 기반 투명 전달을 사용합니다. TUN 설정은 한곳에서 관리하기 쉽지만 커널 모듈, 정책 라우팅, DNS 가로채기, 방화벽 호환성은 여전히 처리해야 합니다.

다음은 주요 필드를 설명하기 위한 기본 조각입니다. 노드, 정책 그룹, 서비스별 규칙은 완전한 설정에서 별도로 제공해야 합니다:

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

external-controller: 127.0.0.1:9090
secret: "replace-with-a-long-random-secret"

profile:
  store-selected: true
  store-fake-ip: true

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

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

auto-detect-interface는 실제 외부 인터페이스를 식별해 전화 접속 인터페이스 이름이 바뀔 때 설정을 수정하는 부담을 줄여 줍니다. 다중 WAN, VPN 중첩, 컨테이너 브리지가 많은 환경에서는 자동 판단이 예상과 다를 수 있으므로 로그와 ip route get 1.1.1.1로 실제 출구를 확인해야 합니다. strict-route는 DNS나 연결 우회를 줄일 수 있지만 잘못된 정책 라우팅 설정을 더 쉽게 드러낼 수도 있습니다.

예시에서는 이미 dnsmasq가 사용하고 있을 수 있는 53 포트를 직접 점유하지 않도록 DNS 수신 포트를 1053으로 설정합니다. OpenWrt에서는 dnsmasq가 업스트림 요청을 127.0.0.1#1053으로 전달하게 할 수 있으며, LuCI의 일반적인 경로는 「네트워크」→「DHCP/DNS」→「일반 설정」→「DNS 전달」입니다. 저장하기 전에 요청을 다른 업스트림에도 동시에 보내는 병렬 전달 설정을 끄세요. 그렇지 않으면 해석 결과와 프록시 규칙이 일치하지 않을 수 있습니다.

Fake-IP 필터에는 LAN 서비스를 포함해야 함

Fake-IP를 사용하면 연결이 수립되는 단계에서 도메인 규칙으로 직접 분기할 수 있지만, 프린터, NAS, 화면 미러링, LAN 검색 서비스는 실제 주소에 의존할 수 있습니다. 로컬 도메인 접미사, 라우터 관리 도메인, 필요한 연결성 확인 도메인을 fake-ip-filter에 추가할 수 있습니다. LAN 서비스는 먼저 로컬 DNS가 사설 주소를 반환하도록 구성해 도메인이 공용 DNS에서 먼저 해석되지 않게 해야 합니다.

dns:
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "router.local"
    - "nas.home.arpa"
    - "+.home.arpa"

OpenWrt 메인 라우터 적용 절차

기존 설정을 백업합니다. LuCI에서 「시스템」→「백업 및 업그레이드」를 열어 복원 가능한 설정 아카이브를 생성하고, WAN 인터페이스 이름, LAN 주소, DHCP 설정도 기록합니다.
남은 공간을 확인합니다. df -h로 overlay를 확인하세요. 실행 파일, Geo 데이터, 규칙 세트가 합쳐져 수십 MB를 사용할 수 있습니다. 공간이 부족하면 외장 저장소를 사용하고 루트 파티션을 가득 채우지 마세요.
TUN을 지원하도록 설치합니다. 「시스템」→「소프트웨어 패키지」에서 펌웨어와 일치하는 kmod-tun을 설치한 다음 /dev/net/tun이 존재하는지 확인합니다.
프로그램과 설정을 배치합니다. /usr/bin/mihomo 및 /etc/mihomo/config.yaml을 사용하는 것을 권장하며, 권한은 각각 0755와 0600으로 설정합니다.
먼저 포그라운드에서 실행합니다. /usr/bin/mihomo -d /etc/mihomo를 실행해 TUN, DNS, provider 로그를 확인한 뒤 테스트 단말에서 직접 연결과 프록시 규칙을 검증합니다.
부팅 서비스에 등록합니다. 포그라운드 실행이 안정적인 것을 확인한 뒤 procd 서비스를 만들고, 마지막으로 「시스템」→「시작 항목」에서 활성화 상태를 확인합니다.

OpenWrt는 procd로 서비스를 관리합니다. 다음 스크립트는 최소 구조를 보여 주며, 설정 디렉터리는 실제 위치에 맞춰야 합니다:

#!/bin/sh /etc/rc.common

START=95
STOP=10
USE_PROCD=1

start_service() {
  procd_open_instance
  procd_set_param command /usr/bin/mihomo -d /etc/mihomo
  procd_set_param respawn 3600 5 5
  procd_set_param stdout 1
  procd_set_param stderr 1
  procd_set_param limits nofile="1048576 1048576"
  procd_close_instance
}

service_triggers() {
  procd_add_reload_trigger "mihomo"
}

/etc/init.d/mihomo로 저장한 뒤 다음을 실행합니다:

chmod 0755 /etc/init.d/mihomo
/etc/init.d/mihomo enable
/etc/init.d/mihomo start
logread -e mihomo

부팅 시 외장 디스크가 아직 마운트되지 않았다면 서비스가 설정이나 규칙 파일을 찾지 못합니다. 설정은 내부 플래시에 두고 provider 캐시만 외장 디스크로 옮길 수도 있으며, 부팅 순서를 조정하고 스크립트에서 디렉터리를 확인할 수도 있습니다. 마운트 순서 문제를 몇 초간 고정 대기하는 방식으로 덮어서는 안 됩니다.

일반 Linux 보조 라우터의 systemd 설정

Debian, Ubuntu 및 systemd를 사용하는 다른 시스템에서는 /etc/systemd/system/mihomo.service를 만들 수 있습니다. 라우터 투명 인계에는 TUN 생성, 라우트 설정, 관련 네트워크 권한 관리가 필요하므로 초기에는 root로 실행하는 것이 가장 직접적입니다. 배포가 안정된 뒤 실제 기능에 맞춰 권한을 줄여야 하며, 처음부터 권한을 제거해 TUN 생성이 실패하게 만들어서는 안 됩니다.

[Unit]
Description=mihomo routing core
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
ExecStartPre=/usr/local/bin/mihomo -t -d /etc/mihomo
ExecStart=/usr/local/bin/mihomo -d /etc/mihomo
Restart=on-failure
RestartSec=5
LimitNOFILE=1048576

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload
sudo systemctl enable --now mihomo
sudo systemctl status mihomo
sudo journalctl -u mihomo -n 100 --no-pager

보조 라우터에서는 IPv4 전달도 활성화해야 합니다. /etc/sysctl.d/90-router-forward.conf를 만들 수 있습니다:

net.ipv4.ip_forward=1

이후 sudo sysctl --system을 실행합니다. IPv6를 활성화한다면 IPv6 기본 라우트, DNS, 방화벽을 별도로 설계해야 합니다. net.ipv6.conf.all.forwarding=1만 켠다고 모든 트래픽이 이미 mihomo로 들어오는 것은 아닙니다. 아직 IPv6 인계가 완료되지 않았다면 테스트 네트워크에서 먼저 IPv6를 끄고, 단말이 규칙에 포함되지 않은 IPv6 경로로 연결하지 않도록 하세요.

방화벽과 TUN 규칙을 중복 적용하지 않기

기존에 nftables, Docker, Tailscale 또는 다른 VPN이 있으면 규칙 우선순위가 충돌할 수 있습니다. mihomo를 활성화한 뒤 ip rule, ip route show table all, nft list ruleset을 각각 실행해 중복 마크, TUN으로 되돌아가는 기본 라우트, 프록시로 잘못 유입된 컨테이너 네트워크 등을 확인하세요. TUN 자동 라우팅이 이미 대상 트래픽을 인계하고 있다면 기존 REDIRECT 규칙을 그대로 추가하지 마세요.

성능 검증과 문제 원인 파악

배포가 끝난 뒤 웹페이지가 열리는지만으로 판단하지 마세요. 최소한 LAN 직접 연결, 프록시 연결, DNS, 규칙 매칭, 재부팅 후 복구, 높은 동시 연결에서의 안정성 등 여섯 가지를 검증해야 합니다. 테스트할 때는 동일한 노드와 동일한 단말을 고정해 노드 변동과 로컬 설정 변경이 동시에 일어나지 않도록 하세요.

포트 상태: ss -lntup으로 7890, 9090, 1053이 예상대로 수신 대기 중인지 확인합니다.
DNS 경로: nslookup example.com 192.168.1.2를 실행한 뒤 mihomo 로그에 해당 질의가 나타나는지 확인합니다.
게이트웨이 전달: 단말에서 경로 추적을 실행해 첫 번째 홉이 계획한 메인 라우터 또는 보조 라우터인지, 다른 DHCP 서버가 배포한 오래된 게이트웨이가 아닌지 확인합니다.
규칙 매칭: 로그 수준을 잠시 debug로 바꾸고 대상 도메인이 최종적으로 예상한 정책 그룹에 들어가는지 확인합니다. 완료 후에는 info로 되돌려 로그가 장기간 과도하게 쌓이지 않게 하세요.
재부팅 복구: 장치를 재부팅한 뒤 mihomo, DNS 전달, TUN이 자동으로 복구되는지 확인하고 provider 캐시를 읽을 수 있는지도 점검합니다.
복구 테스트: mihomo를 중지한 뒤 테스트 단말의 게이트웨이를 메인 라우터로 되돌려 기본 네트워크가 독립적으로 작동하는지 확인합니다.

하드웨어 성능의 참고값으로, 500Mbps 회선, mihomo v1.19 계열, 약 8,000개 규칙이라는 조건에서 Intel N5105 쿼드코어 미니 PC는 TUN 전달 시 일반적으로 약 430~470Mbps를 달성할 수 있으며, 쿼드코어 Cortex-A53과 메모리 1GB 장치는 보통 약 180~240Mbps를 기록합니다. 수치는 암호화 프로토콜, 노드 거리, NIC 드라이버, 규칙 규모, 트래픽 스니핑 활성화 여부에 따라 달라지므로 장치 표기 성능으로 그대로 간주해서는 안 됩니다.

속도가 직접 연결의 절반 정도에 불과하다면 먼저 단일 코어 CPU 사용률이 100%에 가까운지 확인한 다음 MTU를 점검하세요. PPPoE, WireGuard, TUN을 함께 사용할 때 MTU가 너무 크면 단편화가 발생하거나 일부 사이트 로딩이 멈출 수 있습니다. 1500에서 시작해 1492, 1480, 1400 순으로 단계적으로 테스트하고, 매번 하나의 매개변수만 변경하면서 처리량, 지연 시간, 패킷 손실 결과를 기록하세요.

커널과 설정 업데이트 인수인계 절차

라우터 업데이트는 ‘새 파일 검증, 기존 파일 보존, 서비스 전환’ 순서로 진행해야 합니다. 실행 중인 바이너리를 바로 덮어쓴 뒤 즉시 재부팅하지 마세요. 먼저 새 버전을 mihomo.new로 저장하고 버전 확인과 설정 테스트를 실행한 다음 서비스를 중지하고 파일을 교체한 뒤 다시 시작합니다. 실행이 안정적인지 확인한 후에도 이전 버전은 업데이트 주기 하나 동안 보관할 수 있습니다.

sudo install -m 0755 mihomo.new /usr/local/bin/mihomo.new
sudo /usr/local/bin/mihomo.new -v
sudo /usr/local/bin/mihomo.new -t -d /etc/mihomo

sudo systemctl stop mihomo
sudo mv /usr/local/bin/mihomo /usr/local/bin/mihomo.previous
sudo mv /usr/local/bin/mihomo.new /usr/local/bin/mihomo
sudo systemctl start mihomo
sudo systemctl status mihomo

설정 업데이트 역시 먼저 임시 파일에 작성해 테스트한 뒤 주 파일을 교체해야 합니다. DNS 모드, TUN 스택, 규칙 세트 형식, provider 동작이 바뀌는 경우에는 먼저 단말 한 대에서 검증하고 시스템 펌웨어 업그레이드와 같은 시간에 진행하지 마세요. 구형 커널이 막을 내리고 mihomo가 이어받은 것은 실행 파일뿐 아니라 설정 필드와 네트워크 인계 방식도 계속 변화한다는 뜻입니다. 특정 스크립트가 오랫동안 변하지 않을 것이라고 기대하기보다 검증과 복구를 고정 절차로 만드는 편이 더 안정적입니다.