OpenWrt 라우터·서브 라우터에서 mihomo 실행하기: 배포 방식 가이드

배포 방식 선택: 게이트웨이 경로를 먼저 정하고 트래픽 처리 방식을 고르세요

OpenWrt에서 mihomo를 실행하려면 두 가지를 따로 정해야 합니다. 커널을 어느 기기에서 실행할지, LAN 연결을 어떻게 커널로 보낼지입니다. 이 둘을 구분하면 문제가 설정 파일, DNS, 라우팅, 방화벽 중 어디에 있는지 파악하기 쉽습니다.

mihomo는 Clash Meta 프로젝트에서 이어서 사용하는 커널 이름으로, 설정을 읽고 규칙을 매칭해 아웃바운드 연결을 선택합니다. LuCI 관리 플러그인은 관리 계층으로, 보통 설정 생성, 방화벽 규칙 설치, 프로세스 관리까지 담당합니다. 커널 파일만 라우터에 복사한다고 집 안의 모든 기기 트래픽이 자동으로 처리되는 것은 아닙니다.

하드웨어 아키텍처 확인: 명령어 집합, 메모리, 저장 공간

먼저 OpenWrt의 SSH 터미널에서 시스템 정보를 확인한 뒤, 이에 맞는 Linux 커널 파일을 선택하세요. 라우터 외형이나 프로세서 홍보 문구만 보고 아키텍처를 추측하지 마세요. 같은 제품군이라도 칩이 다를 수 있습니다.

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

• x86_64는 보통 amd64에 해당하지만, 배포 파일에서 요구하는 CPU 명령어 집합 수준도 확인해야 합니다. 구형 프로세서는 최신 최적화 빌드를 지원하지 않을 수 있습니다.
• aarch64는 보통 arm64에 해당합니다. 32비트 ARM은 ARM 버전과 부동소수점 지원 여부를 추가로 확인해야 하며, arm64 파일을 그대로 사용할 수 없습니다.
• MIPS 기기는 엔디언과 구체적인 빌드 조건을 확인해야 합니다. OpenWrt 패키지의 아키텍처 이름과 업스트림 바이너리 파일 이름이 반드시 일치하는 것은 아닙니다.
• /tmp는 보통 메모리 파일 시스템에 있으며 재부팅하면 비워집니다. 다운로드, 압축 해제, 로그가 사용 가능한 메모리를 차지하므로 남은 플래시 저장 공간을 메모리처럼 계산하면 안 됩니다.

실제 사용량을 기준으로 용량 판단

구독 노드 수, 규칙 세트 크기, 연결 수, DNS 캐시, 로그 수준이 모두 메모리 사용량에 영향을 줍니다. 특정 메모리 용량만으로 실행을 보장할 수는 없습니다. 실제 설정을 불러와 관찰한 뒤 자동 시작을 적용하세요. 대규모 규칙 세트는 다운로드 공간과 영구 저장 공간도 추가로 필요할 수 있습니다.

프로세스가 시작된 뒤 곧바로 종료된다면 logread에서 메모리 부족이나 프로세스 종료 기록을 확인하세요. Exec format error가 나타나면 아키텍처와 압축 해제 여부를 먼저 확인하고, Illegal instruction이 나타나면 CPU 명령어 집합 호환성을 집중적으로 확인하세요.

커널과 설정: 파일을 검증한 뒤 서비스 관리에 등록

아래 경로는 수동 배포 예시입니다. 커널은 /usr/bin/mihomo에 두고, 작업 디렉터리는 /etc/mihomo, 기본 설정 파일은 /etc/mihomo/config.yaml로 지정합니다. LuCI 관리 플러그인을 이미 설치했다면 플러그인에서 지정한 커널 디렉터리와 설정 경로를 사용하고, 인스턴스를 추가로 실행하지 마세요.

수동 배포 확인 순서

1. 기존 네트워크, 방화벽, DNS 설정을 백업하고 로컬 유선 연결로 라우터에 다시 접속할 수 있는지 확인합니다.
2. 아키텍처에 맞는 압축 해제된 커널을 /tmp/mihomo에 업로드합니다. 기존에 정상 작동하던 설정을 덮어쓰지 않도록 설정 파일은 별도로 준비하세요.
3. 대상 디렉터리의 여유 공간을 확인한 다음 커널을 복사하고 실행 권한을 부여합니다.
4. 먼저 버전 확인과 설정 테스트를 실행합니다. 테스트가 통과하면 포그라운드에서 실행해 로그를 확인하세요.

mkdir -p /etc/mihomo
cp /tmp/mihomo /usr/bin/mihomo
chmod 755 /usr/bin/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

실행 전에 config.yaml 파일이 있는지 확인하세요. -v는 실제 버전을 확인하고, -t는 설정을 테스트합니다. 테스트가 성공해도 업스트림 노드에 연결할 수 있다는 뜻은 아니며, LAN 트래픽이 커널로 들어간다는 뜻도 아닙니다. 일부 설정은 규칙 세트, 지리 데이터 또는 외부 파일에 의존합니다. 최초 테스트에 실패하면 작업 디렉터리와 다운로드 로그도 함께 확인하세요.

최소 직접 연결 설정: 프로세스와 리스닝 확인

아래는 프록시 노드 없이 모든 연결을 직접 연결하는 독립 테스트 파일입니다. YAML, 포트, 프로세스 시작 문제를 확인하기 위한 것으로, 프록시 출구를 검증할 수는 없습니다.

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

external-controller: "127.0.0.1:9090"

dns:
  enable: true
  listen: "127.0.0.1:1053"
  enhanced-mode: redir-host
  nameserver:
    - 223.5.5.5

rules:
  - MATCH,DIRECT

7890은 이 예시의 HTTP/SOCKS 혼합 포트이고, 9090은 컨트롤 인터페이스, 1053은 DNS 리스닝 포트입니다. 서로 대체할 수 없습니다. 포그라운드에서 확인한 뒤 관리 플러그인이나 OpenWrt의 procd 서비스 관리로 시작, 중지, 재시작하세요. 플러그인, 사용자 정의 서비스, 백그라운드 명령으로 같은 커널을 동시에 실행하지 마세요.

메인 라우터에서 직접 실행: 트래픽 통합 처리와 DNS 연결

메인 라우터에 배포하면 단말의 트래픽이 원래 이 기기를 거치므로 기기마다 게이트웨이를 수정할 필요가 없습니다. 반면 위험도 네트워크 전체에 미칩니다. 방화벽이나 DNS 설정이 잘못되면 LAN 전체에 영향을 줄 수 있습니다. 테스트 단말 한 대나 테스트 서브넷만 먼저 선택하고, 처리 범위를 단계적으로 넓히세요.

LuCI에서 기존 설정부터 확인

• 「네트워크」→「인터페이스」→「LAN」→「편집」으로 이동해 LAN 주소와 서브넷 마스크를 기록합니다.
• LAN의 「DHCP 서버」에서 주소 풀과 DHCP 옵션을 확인하고, 다른 기기가 충돌하는 게이트웨이를 함께 배포하지 않는지 살펴봅니다.
• 「네트워크」→「방화벽」으로 이동해 기존 LAN에서 WAN으로의 포워딩 설정이 실수로 삭제되지 않았는지 확인합니다.
• 「상태」→「시스템 로그」에서 커널 및 DNS 서비스 로그를 확인합니다. 펌웨어 번역이나 테마에 따라 메뉴 이름이 조금씩 다를 수 있습니다.

일반적인 DNS 경로에서는 단말이 라우터의 53 포트로 질의하고, dnsmasq가 이를 mihomo의 로컬 1053 포트로 전달합니다. 이때 업스트림 방향이 반대로 dnsmasq를 가리키지 않는지 확인하세요. 잘못 설정하면 DNS 조회 루프가 생길 수 있습니다. dns.listen만 설정해도 단말이 자동으로 해당 포트를 사용하는 것은 아니므로, 포워딩 또는 트래픽 처리 규칙을 별도로 구성해야 합니다.

서브 라우터 게이트웨이: 단말 한 대로 왕복 경로 확인

단일 포트 서브 라우터는 메인 라우터와 같은 서브넷에 두는 경우가 많습니다. 예시에서는 메인 라우터가 192.168.50.1/24, 서브 라우터가 192.168.50.2/24, 테스트 단말이 192.168.50.100/24입니다. 이 주소는 네트워크 구성 예시일 뿐이므로, 배포 전에 기존 DHCP 주소 풀과 충돌하는지 확인하세요.

1. 서브 라우터의 LAN 주소를 고정 IP 192.168.50.2로 설정하고, 기본 업스트림 게이트웨이는 192.168.50.1로 지정합니다.
2. 두 기기가 같은 브로드캐스트 도메인에서 주소를 중복 할당하지 않도록, 우선 DHCP는 메인 라우터에서만 제공하세요.
3. 테스트 단말 한 대의 기본 게이트웨이를 192.168.50.2로 직접 변경합니다.
4. 서브 라우터에서 LAN용 DNS 서비스를 제공한다면 테스트 단말의 DNS도 192.168.50.2로 지정하세요. 그렇지 않다면 먼저 라우팅만 따로 검증합니다.
5. 서브 라우터에서 해당 포워딩 경로를 허용하는지, 직접 연결 트래픽의 반환 경로가 설계와 일치하는지 확인합니다.

이처럼 같은 서브넷에 구성하면 직접 연결 트래픽은 서브 라우터를 거쳐 메인 라우터로 갈 수 있지만, 응답은 메인 라우터에서 단말로 바로 전달되어 비대칭 경로가 생길 수 있습니다. 소스 NAT, 메인 라우터의 정적 라우트, 별도 서브넷이 필요한지는 방화벽의 상태 추적과 네트워크 구조를 기준으로 판단해야 합니다. 서브 라우터에서는 NAT를 항상 끄거나 항상 켜야 한다는 식으로 단정할 수 없습니다.

게이트웨이와 DNS를 따로 확인

게이트웨이를 바꾸면 IP 패킷의 다음 홉이 달라질 뿐, 도메인 조회도 서브 라우터를 거친다고 보장할 수는 없습니다. 브라우저의 암호화 DNS, 단말에 직접 설정된 DNS, IPv6 라우터 광고가 별도의 경로를 만들 수 있습니다. 테스트 단말이 실제로 받은 IPv4 게이트웨이, IPv6 기본 경로, DNS 주소를 먼저 확인한 뒤 트래픽 처리가 필요한지 판단하세요.

단말 한 대로 테스트를 마친 뒤에만 메인 라우터 DHCP에서 옵션 3으로 IPv4 기본 게이트웨이를, 옵션 6으로 DNS를 배포하는 방안을 검토하세요. 일부 가정용 메인 라우터는 세부 옵션 배포를 지원하지 않습니다. 이 경우 전체 네트워크를 바로 전환하기보다 수동 설정을 유지하거나 별도 테스트 서브넷을 사용하면 되돌리기 쉽습니다.

투명 프록시: REDIRECT, TPROXY, TUN의 차이

명시적 프록시를 사용하려면 앱에서 7890 같은 프록시 포트에 직접 연결해야 합니다. 투명 프록시는 라우팅과 방화벽을 통해 기존 연결을 커널로 전달합니다. 두 진입 방식을 함께 사용할 수 있지만, 여러 규칙이 같은 연결을 중복 처리하지 않도록 주의하세요.

OpenWrt 22.03부터 일반적인 기본 환경은 firewall4와 nftables를 사용합니다. 예전 가이드의 iptables 규칙을 새 환경에 확인 없이 붙여 넣으면 안 됩니다. 펌웨어에서 사용자 정의 방화벽 백엔드를 사용하는지, 필요한 모듈이 설치되어 있는지도 확인해야 합니다.

TUN을 켜도 LAN 트래픽 처리가 자동으로 완료되지는 않습니다

tun.auto-route는 관련 라우트를 자동으로 설정하지만, 동작은 시스템, 버전, 네트워크 구성에 따라 달라집니다. 이 설정만 보고 포워딩 트래픽 전체가 TUN으로 들어간다고 판단해서는 안 됩니다. tun.auto-redirect도 플랫폼과 버전에 따라 지원 여부가 달라 모든 Linux 환경에 그대로 적용할 수 없습니다. 라우터 플러그인이 트래픽 처리 규칙을 관리한다면 규칙 생성은 플러그인에 맡기고, 별도의 수동 규칙을 중복 적용하지 마세요.

• 라우터 관리 주소, 필요한 로컬 서브넷, 커널이 업스트림 프록시 서버에 연결하는 트래픽은 처리 대상에서 제외해 루프를 방지합니다.
• fake-ip를 사용할 때는 DNS가 반환하는 가상 주소 대역에 해당하는 라우트와 트래픽 처리 경로가 있는지 확인하세요. 그렇지 않으면 DNS 조회는 성공해도 연결이 실패할 수 있습니다.
• UDP가 필요한 앱은 진입 방식, 노드 프로토콜 지원, 서버 측 기능을 모두 확인해야 합니다. TCP 웹 페이지가 열린다고 UDP도 정상이라는 뜻은 아닙니다.
• IPv4와 IPv6를 각각 확인하세요. IPv4 투명 프록시만 설정해도 IPv6 연결까지 자동으로 처리되지는 않습니다.

LAN 연결: 명시적 프록시부터 테스트하고 규칙 매칭 확인

정식으로 트래픽을 처리하기 전에 단말 한 대에서 명시적 프록시를 사용하면 네트워크 포워딩 문제를 분리해 확인할 수 있습니다. 테스트 설정의 7890 포트를 LAN에 개방하려면 allow-lan을 true로 변경하고, bind-address를 실제 LAN 주소(예: "192.168.50.2")로 지정하세요. 방화벽에서도 신뢰하는 서브넷만 접근하도록 제한해야 합니다.

프록시 포트나 컨트롤 인터페이스를 WAN 포트 포워딩으로 외부에 공개하지 마세요. external-controller는 보통 로컬 주소에만 바인딩해야 접근을 제어하기 쉽습니다. 원격 관리가 꼭 필요하다면 강력한 secret을 설정하고 접근 가능한 출발지를 제한하세요. 컨트롤 인터페이스 인증과 혼합 프록시 포트 인증은 서로 다른 설정이며 대체할 수 없습니다.

계층별로 문제 범위 좁히기

1. 프로세스: 설정 테스트가 통과하고 커널이 계속 실행되는지, 같은 포트를 사용하는 다른 인스턴스가 없는지 확인합니다.
2. 진입 경로: 단말에서 LAN 주소의 프록시 포트에 연결할 수 있는지 확인합니다. 연결이 거부되면 리스닝 주소를, 시간 초과가 발생하면 방화벽과 경로를 먼저 확인하세요.
3. 아웃바운드: 실제로 사용할 수 있는 노드와 정책 그룹으로 바꾼 뒤 인증, 프로토콜, 업스트림 연결을 확인합니다. 앞서 사용한 직접 연결 테스트 파일에는 프록시 출구가 없습니다.
4. 규칙: mode: rule인지 확인한 다음 로그에서 매칭된 규칙과 아웃바운드 정책을 살펴봅니다. 규칙은 위에서 아래로 매칭되므로, 앞쪽의 기본 규칙이 뒤에 있는 규칙을 가릴 수 있습니다.
5. 트래픽 처리: 명시적 프록시는 작동하지만 투명 프록시가 작동하지 않는다면 구독을 반복해서 바꾸기보다 DNS, 정책 라우팅, 방화벽, IPv6를 먼저 확인하세요.

커널 리소스와 노드 속도도 구분해서 판단해야 합니다. 웹 페이지의 첫 응답이 느리다면 DNS나 연결 설정 과정이 원인일 수 있고, 대용량 파일 전송이 느리다면 CPU, 암호화 처리, 회선 대역폭, 혼잡도 영향을 받을 수 있습니다. 단순히 ‘서브 라우터가 느려졌다’고 기록하는 것보다 발생 시각, 테스트 단말, 대상 서비스, 매칭된 정책을 기록해야 재현하기 쉽습니다.

업데이트와 롤백: 정상 설정과 별도 관리 경로 유지

구독 업데이트, 커널 업그레이드, 방화벽 변경은 각각 따로 진행하세요. 구독 업데이트로 노드, 정책 그룹, 규칙이 바뀔 수 있으며 관리 플러그인이 시작할 때 실행 설정을 다시 생성할 수도 있습니다. 계속 유지해야 하는 변경 사항은 임시 생성 파일이 아니라 플러그인에서 지원하는 오버라이드나 사용자 정의 규칙 입력란에 작성하세요.

• 업그레이드 전에 mihomo -v 출력 결과를 기록하고, 정상 작동하는 커널, 기본 설정, 사용자 정의 규칙을 보관합니다.
• 기존 프로세스를 중지한 다음 바이너리 파일을 교체하세요. 먼저 설정을 테스트하고 이후 서비스를 시작해야 합니다. 실행 중인 파일을 바로 덮어쓰지 마세요.
• logread에서 시작 결과를 확인하고 규칙 리소스가 정상적으로 로드되는지 살펴본 뒤, DNS, TCP, 필요한 UDP 앱을 테스트합니다.
• 관리 주소에 직접 연결할 수 있는 기기를 한 대 유지하세요. 서브 라우터에 문제가 생기면 테스트 단말의 게이트웨이와 DNS를 기존 메인 라우터로 되돌립니다. DHCP 배포 설정을 변경했다면 해당 옵션도 복구한 뒤 단말에서 임대 정보를 다시 받아야 합니다.

컴퓨터나 휴대폰 한 대에서만 프록시를 사용하려는 경우에는 해당 플랫폼의 클라이언트를 실행하는 편이 설정 단계를 줄일 수 있습니다. TV, 게임 기기, 여러 단말을 한꺼번에 관리해야 할 때 라우터로 게이트웨이, DNS, 투명 프록시 처리를 옮기는 것이 좋습니다. YAML의 기본 구조와 규칙 순서는 설정 파일 구조와 규칙 필드 설명에서 확인할 수 있습니다.