라우터와 보조 라우터에서 mihomo 코어 직접 실행하기: 아키텍처 선택과 설정 핵심

먼저 설치 목표를 정하세요: 라우터에서 mihomo가 맡을 역할

Windows, macOS 또는 스마트폰에서 Clash 그래픽 클라이언트를 실행하면 보통 현재 기기만 프록시 적용 대상이 됩니다. mihomo 코어를 라우터나 보조 라우터에 설치하면 트래픽 진입점이 로컬 네트워크 게이트웨이로 이동하므로 TV, 게임기, 스마트 스피커처럼 클라이언트 설치가 어려운 기기도 규칙에 따라 트래픽을 분배할 수 있습니다. 여기서 mihomo는 Clash Meta에서 이어져 발전한 코어로, Clash 형식의 YAML 설정을 읽고 규칙 매칭, 프록시 그룹, DNS, TProxy, 리디렉션, TUN 등의 기능을 제공합니다.

라우터 설치의 핵심은 “코어를 실행하는 것”이 아니라 데이터 패킷이 실제로 코어를 통과하고 올바른 경로로 돌아오게 하는 데 있습니다. 완전한 경로에는 최소 네 부분이 필요합니다. LAN 기기가 게이트웨이에 데이터를 전달하고, 라우팅 규칙이 대상 트래픽을 mihomo로 보내며, 코어가 규칙에 따라 직접 연결 또는 프록시 출구를 선택하고, 반환 트래픽이 올바른 경로로 원래 기기에 돌아와야 합니다. 프로세스만 실행하고 투명 프록시 규칙을 설정하지 않으면 LAN 기기는 자동으로 이를 사용하지 않습니다.

메인 라우터와 보조 라우터의 핵심 차이

메인 라우터 방식은 경로가 가장 명확합니다. LAN 클라이언트의 기본 게이트웨이가 곧 mihomo를 실행하는 기기이므로, 방화벽은 어떤 트래픽을 투명 프록시 포트로 보낼지만 판단하면 됩니다. 반면 보조 라우터 방식에서는 클라이언트가 왜 보조 라우터로 패킷을 보내야 하는지 추가로 정해야 합니다. 일반적으로 특정 기기의 기본 게이트웨이를 보조 라우터 주소로 설정하거나, 메인 라우터가 출발지 주소를 기준으로 정책 라우팅을 적용합니다. 클라이언트 DNS만 보조 라우터로 지정한다고 해서 일반 TCP·UDP 트래픽까지 자동으로 보조 라우터를 통과하지는 않습니다.

펌웨어·아키텍처·하드웨어 리소스 선택 기준

mihomo는 다양한 CPU 아키텍처용 실행 파일을 제공합니다. 설치 전에 라우터 제품명만 확인하지 말고 uname -m으로 시스템 아키텍처를 확인해야 합니다. 대표적인 결과는 aarch64, armv7l, x86_64, mips입니다. 다운로드 파일의 아키텍처는 시스템과 일치해야 합니다. 예를 들어 64비트 ARM 펌웨어는 일반적으로 ARM64 빌드를 사용하지만, 32비트 펌웨어가 설치된 기기는 CPU가 64비트를 지원하더라도 ARM64 파일을 직접 실행할 수 없습니다.

펌웨어가 갖춰야 할 기본 기능

• Linux 커널이 정책 라우팅을 지원하고 시스템에서 ip rule과 ip route를 사용할 수 있어야 합니다.
• 방화벽이 nftables 또는 iptables를 지원하고 투명 프록시에 필요한 TProxy 모듈을 제공해야 합니다.
• 설정, 규칙 세트, GeoIP와 GeoSite 데이터를 저장할 수 있는 영구 파일 시스템 위치가 필요합니다.
• OpenWrt의 procd나 일반 Linux의 systemd처럼 부팅 시 서비스를 등록할 수 있어야 합니다.
• 시스템 시간과 DNS가 정상적으로 작동해야 합니다. 그렇지 않으면 구독 업데이트, TLS 연결과 도메인 규칙이 오작동할 수 있습니다.

OpenWrt 23.05 이후의 일반적인 빌드는 firewall4와 nftables를 중심으로 구성되므로, 오래된 튜토리얼의 iptables 명령을 그대로 섞어 쓰면 안 됩니다. 설치 전에 LuCI의 「시스템」→「패키지」에서 TProxy, nftables와 정책 라우팅 관련 구성 요소가 있는지 확인하세요. SSH에서 nft list ruleset을 실행해 현재 방화벽 체계를 확인할 수도 있습니다. 명령이 없다면 mihomo 설정을 반복해서 수정하기보다 먼저 펌웨어 구성 요소를 보완해야 합니다.

메모리·저장 공간·CPU의 실제 기준

코어 자체는 전체 리소스 사용량의 일부에 불과합니다. 설정의 규칙 수, GeoSite 데이터, DNS 캐시, 연결 수와 패널 리소스도 메모리를 사용합니다. 128MB 메모리 기기에서는 간소화된 설정을 실행할 수 있지만 대형 규칙 세트를 불러오거나 fake-ip을 활성화하고 동시 연결을 많이 처리하면 여유가 거의 없습니다. 256MB는 기본 출발점으로 더 적합하고, 512MB 이상이면 광고 필터, DNS 서비스와 모니터링 구성 요소를 함께 실행하기 편합니다.

다음 데이터는 RK3399 6코어 ARM64 기기, 메모리 4GB, OpenWrt 23.05.5, mihomo v1.19.10 환경에서 LAN 테스트로 측정했습니다. 테스트 회선은 300Mbps이며 하류 클라이언트는 기가비트 유선으로 연결했고, 설정에는 약 8.6만 개의 도메인 및 IP 규칙이 포함되었습니다. 결과는 성능 규모를 가늠하기 위한 참고값일 뿐이며 암호화 방식, 노드 거리와 펌웨어 빌드가 다르면 동일하게 재현되지 않을 수 있습니다.

100Mbps급 회선과 소수의 단말에서는 CPU 요구량이 높지 않지만, 기가비트 접속, WireGuard, 복잡한 암호화와 많은 UDP 트래픽은 부하를 크게 높입니다. 소프트 라우터는 네트워크 포트가 같은 버스를 공유하는지, USB 네트워크 어댑터 병목이 있는지도 확인해야 합니다. 처리량은 CPU 클럭만으로 판단할 수 없으며 AES 명령어 지원, 커널 드라이버와 냉각 성능도 지속 성능에 영향을 줍니다.

투명 프록시 방식: TProxy·리디렉션·TUN

라우터에서 흔히 사용하는 트래픽 처리 방식은 REDIRECT, TProxy와 TUN입니다. REDIRECT는 주로 TCP를 처리하며 구조가 비교적 단순하지만 UDP를 완전히 지원하지 못하고 코어가 인식하는 대상 주소 처리 방식도 바뀝니다. TProxy는 TCP와 UDP를 투명하게 가로채면서 원래 대상 정보도 보존하므로 Linux 라우터 환경에서 자주 사용됩니다. TUN은 가상 네트워크 인터페이스로 IP 트래픽을 수신하는 방식이라 개념은 직관적이지만, 성능이 낮은 라우터에서는 컨텍스트 전환과 프로토콜 스택 오버헤드가 더 커지는 경우가 많습니다.

TProxy 포트와 정책 라우팅

mihomo의 tproxy-port는 투명 프록시 트래픽을 수신하는 역할만 합니다. 방화벽은 선택한 패킷에 마크를 지정해야 하며, 정책 라우팅은 마크가 붙은 패킷을 로컬 루프백 인터페이스로 전달해야 합니다. 흔히 7893 포트를 사용하지만 포트 번호 자체에 강제 조건은 없습니다. 설정, nftables 규칙과 서비스 권한만 일치하면 됩니다.

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

external-controller: 127.0.0.1:9090
secret: "별도의 제어용 보안 키를 설정하세요"

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

mixed-port: 7890은 LAN에서 HTTP 또는 SOCKS 프록시를 임시로 수동 테스트할 때 사용할 수 있습니다. 다른 기기의 접속을 허용하려면 방화벽으로 출발지 네트워크 대역을 제한해야 합니다. 제어 인터페이스는 127.0.0.1:9090에서만 수신하도록 유지하는 편이 좋습니다. 원격 패널이 필요하면 통제된 리버스 프록시나 SSH 포워딩을 통해 접속하고 WAN에 직접 노출하지 마세요.

TUN을 고려할 시점

펌웨어에 완전한 TProxy 모듈이 없거나 정책 라우팅을 수동으로 작성하는 작업을 줄이고 싶다면 TUN을 검토할 수 있습니다. mihomo의 TUN 설정에는 일반적으로 자동 라우팅과 인터페이스 탐색을 지정해야 하지만, 라우터가 WAN, LAN, 전화 접속과 브리지를 동시에 담당하면 자동 탐색이 예상한 출구를 선택하지 않을 수 있습니다. 설치 후 기본 라우트, TUN 라우팅 테이블과 로컬 네트워크 대역을 확인하고, 특히 라우터 관리 주소와 상위 게이트웨이가 TUN으로 들어가지 않도록 주의해야 합니다.

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

stack: mixed는 흔히 사용하는 시작점이지만 플랫폼 지원 여부는 코어 버전에 따라 달라질 수 있습니다. dns-hijack을 활성화하기 전에는 LAN의 53번 포트를 dnsmasq, AdGuard Home과 다른 리디렉션 규칙이 동시에 중복 처리하고 있지 않은지 확인해야 합니다. 실제 환경에서는 dnsmasq가 LAN의 53번 포트를 계속 수신하게 두고 특정 질의만 mihomo의 127.0.0.1:1053으로 전달할 수 있습니다. 이렇게 하면 DHCP 도메인과 로컬 호스트명은 계속 dnsmasq가 관리합니다.

메인 라우터 설치: 장애 범위를 서비스 계층으로 제한하기

메인 라우터 방식에서는 모든 클라이언트가 이미 해당 기기를 통과하므로 각 단말의 게이트웨이를 수정할 필요가 없습니다. 안정적인 활성화 순서는 먼저 mihomo를 일반 mixed 프록시로 실행해 127.0.0.1:7890이 작동하는지 확인한 다음, 테스트 기기 한 대에 투명 프록시 규칙을 추가하고, 마지막으로 규칙을 전체 LAN으로 확대하는 것입니다. 이렇게 하면 YAML이나 규칙에 오류가 있어도 라우터의 기본 NAT와 DHCP는 계속 작동합니다.

1. 라우터에 유선 관리 포트나 투명 프록시를 거치지 않는 관리 기기처럼 직접 인터넷에 연결할 수 있는 관리 경로를 하나 남겨 두세요.
2. 테스트 클라이언트에 고정 DHCP 임대 주소를 할당해 출발지 IP 기준으로 규칙을 추가하기 쉽게 만드세요.
3. 먼저 해당 클라이언트의 TCP를 가로챈 다음 UDP, DNS와 IPv6를 차례로 확인하세요.
4. 직접 연결 사이트, 프록시 사이트, LAN 기기 접속과 라우터 관리 페이지가 모두 정상인지 확인하세요.
5. 되돌릴 수 있는 방화벽 설정을 저장한 뒤 트래픽 처리 범위를 단계적으로 넓히세요.

IPv6는 자주 빠뜨리는 부분입니다. LAN 클라이언트가 공인 IPv6 주소를 함께 받고 투명 프록시가 IPv4만 처리하면 일부 앱이 IPv6로 직접 연결되어 규칙이 무작위로 실패하는 것처럼 보일 수 있습니다. 해결책은 IPv6를 무조건 끄는 것이 아니라 명확한 방식을 선택하는 것입니다. IPv6를 완전히 가로채거나, 해당 도메인이 IPv4를 반환하도록 하거나, 현재 네트워크가 준비되지 않았다면 RA와 DHCPv6 계층에서 일괄적으로 비활성화할 수 있습니다. 설정의 ipv6: true는 mihomo의 DNS와 연결 기능이 IPv6를 허용한다는 뜻일 뿐, 방화벽 규칙까지 자동으로 추가하지는 않습니다.

메인 라우터 방식의 롤백 설계

투명 프록시 서비스가 중지됐는데도 방화벽이 트래픽을 7893으로 보내면 클라이언트는 인터넷 연결을 잃습니다. 시작 스크립트는 먼저 코어를 실행하고 수신 포트를 확인한 뒤 투명 프록시 규칙을 로드해야 하며, 중지 스크립트는 규칙을 먼저 제거한 다음 프로세스를 종료해야 합니다. OpenWrt에서는 procd로 프로세스를 감시하고 재시작 정책을 설정할 수 있지만, 너무 빠른 무한 재시작은 피해야 합니다. 설정 문법 오류가 있을 때 계속 재실행하면 CPU를 점유하고 로그가 빠르게 쌓입니다.

보조 라우터 설치: 게이트웨이·반환 경로·단일 인터페이스 구성

보조 라우터는 보통 메인 라우터와 같은 네트워크 대역에 둡니다. 예를 들어 메인 라우터 주소가 192.168.10.1이고 보조 라우터가 192.168.10.2일 수 있습니다. 테스트 PC의 기본 게이트웨이를 192.168.10.2로 지정했다면 보조 라우터는 IP 포워딩을 활성화하고, 프록시되지 않은 트래픽과 프록시 후 트래픽을 192.168.10.1로 올바르게 보내야 합니다. 이때 보조 라우터는 클라이언트 게이트웨이이자 mihomo 실행 위치가 됩니다.

단일 인터페이스 보조 라우터는 LAN 포트 하나만 사용하며 입출력 트래픽이 같은 물리 포트를 통과합니다. 배선은 단순하지만 반환 경로를 특히 주의해야 합니다. 메인 라우터가 반환 패킷을 클라이언트에 직접 전달하고 요청 패킷만 보조 라우터를 거치면 상태 추적이 비대칭이 될 수 있습니다. 일반적인 처리 방법은 보조 라우터가 전달하는 트래픽에 소스 주소 변환을 적용하거나, 메인 라우터에 클라이언트 대역을 가리키는 정적 라우트를 추가하는 것입니다. 전자는 설정이 쉽지만 클라이언트의 원래 주소가 가려지고, 후자는 주소 정보를 보존하지만 메인 라우터가 정밀한 라우팅 설정을 지원해야 합니다.

클라이언트가 보조 라우터를 거치게 하는 세 가지 방법

• 게이트웨이 수동 지정: 한두 대의 기기만 수정하므로 테스트에 적합합니다. 클라이언트 게이트웨이를 보조 라우터로 지정하고 DNS는 보조 라우터나 지정한 LAN DNS를 사용합니다.
• DHCP로 보조 라우터 게이트웨이 배포: 전체 네트워크를 이전할 때 적합하지만, 네트워크에는 주소 할당을 명확히 담당하는 DHCP 서비스가 하나만 있어야 클라이언트가 충돌하는 게이트웨이를 받지 않습니다.
• 메인 라우터 정책 라우팅: 메인 라우터가 클라이언트 IP, MAC에 연결된 고정 임대 주소 또는 네트워크 대역을 기준으로 트래픽을 보조 라우터로 보냅니다. 그룹별 활성화에 적합하지만 메인 라우터 펌웨어 기능에 의존합니다.

보조 라우터와 메인 라우터가 같은 브로드캐스트 도메인에 DHCP를 임의로 동시에 제공해서는 안 됩니다. 보조 라우터에서 DHCP를 제공해야 한다면 메인 라우터의 해당 인터페이스에서 DHCP 서비스를 끄거나 두 장치를 서로 다른 VLAN으로 분리하세요. 이전 기간에는 게이트웨이가 메인 라우터로 고정된 관리 PC 한 대를 남겨 두면 보조 라우터 설정에 실패해도 두 장치의 관리 화면에 계속 접속할 수 있습니다.

설정 파일·구독·규칙 세트 저장 방식

mihomo는 영구 디렉터리에서 설정을 읽어야 합니다. OpenWrt에서는 일반적으로 /etc/mihomo/config.yaml에 기본 설정을 저장하고, /etc/mihomo/providers/에 프록시 제공자 파일을 저장합니다. 실행 중 생성되는 캐시와 대형 데이터베이스는 /var/lib/mihomo/ 또는 마운트된 저장 공간에 둘 수 있습니다. 유일한 설정 파일을 /tmp에 저장하지 마세요. OpenWrt의 /tmp는 보통 메모리 파일 시스템이므로 재부팅하면 내용이 사라집니다.

/etc/mihomo/
├── config.yaml
├── providers/
│   ├── primary.yaml
│   └── backup.yaml
└── rules/
    ├── direct.yaml
    └── proxy.yaml

/var/lib/mihomo/
├── cache.db
├── country.mmdb
└── geosite.dat

구독 주소는 proxy-providers에 작성하면 mihomo가 지정한 간격으로 업데이트합니다. 라우터 플래시의 쓰기 수명은 제한적이므로 업데이트 간격을 지나치게 짧게 설정할 필요가 없습니다. 대부분의 환경에서는 interval: 21600, 즉 6시간부터 시작하면 됩니다. 규칙 세트는 변경 빈도에 따라 12시간 또는 24시간으로 설정할 수 있습니다. 매분 가져오면 업스트림 요청과 불필요한 쓰기 및 로그만 늘어납니다.

proxy-providers:
  primary:
    type: http
    url: "https://example.invalid/subscription"
    path: ./providers/primary.yaml
    interval: 21600
    health-check:
      enable: true
      url: "https://www.gstatic.com/generate_204"
      interval: 600

위의 도메인은 설정 구조를 보여 주기 위한 예시일 뿐이므로 실제 설치 시에는 실제 구독 주소로 바꿔야 합니다. 설정 파일에는 보통 접속 자격 증명이 포함되므로 서비스 사용자와 관리자만 읽을 수 있도록 파일 권한을 제한하세요. YAML을 수정한 뒤에는 먼저 코어가 제공하는 설정 검사를 실행하고 현재 파일을 교체해야 합니다. 들여쓰기에는 공백만 사용하고, 프록시 그룹이 참조하는 provider 이름, 규칙 세트 이름과 아웃바운드 이름도 정확히 일치해야 합니다.

부팅 자동 실행·상태 확인·로그 문제 해결

수동 실행 명령은 최초 검증에 적합하지만 장기간 실행할 때는 서비스 관리자를 사용해야 합니다. OpenWrt에서 procd를 사용할 경우 서비스 스크립트에 실행 파일, 작업 디렉터리, 설정 디렉터리, 표준 출력과 재시작 정책을 지정해야 합니다. 일반적인 Linux 보조 라우터에서는 systemd를 사용하고 After=network-online.target 등으로 네트워크가 준비될 때까지 기다릴 수 있습니다. 서비스가 성공적으로 시작됐다고 해서 투명 프록시가 작동한다는 뜻은 아닙니다. 포트, 방화벽 규칙, 정책 라우팅과 DNS도 확인해야 합니다.

권장 시작 점검 순서

1. mihomo -t -d /etc/mihomo를 실행해 설정을 파싱할 수 있는지 확인합니다.
2. 서비스를 시작한 뒤 ss -lntup으로 7890, 7893, 9090, 1053 중 실제로 활성화된 포트를 확인합니다.
3. ip rule과 ip route show table all로 정책 라우팅 테이블을 확인합니다.
4. nft list ruleset으로 트래픽 마크, 예약 주소 허용과 투명 프록시 전달 규칙을 확인합니다.
5. 테스트 클라이언트 한 대에서 도메인 접속, IP 직접 접속, UDP 앱과 LAN 기기를 각각 테스트합니다.

설정 오류는 보통 시작 로그에 필드 경로와 줄 번호로 표시됩니다. OpenWrt에서는 LuCI의 「상태」→「시스템 로그」에서 확인하거나 logread -e mihomo를 실행할 수 있습니다. 프로세스는 실행 중인데 클라이언트가 인터넷에 연결되지 않는다면 먼저 투명 프록시 포트가 수신 중인지 확인하세요. 도메인만 실패하면 DNS 업스트림과 53번 포트 경로를 점검하고, TCP는 정상인데 게임이나 음성 통화가 실패하면 UDP가 TProxy를 통과하는지 확인합니다. 라우터 관리 화면에 접속할 수 없다면 LAN 예약 주소가 잘못 가로채지고 있는지 확인하세요.

아키텍처 선택 결론: 기능 수보다 유지 관리 비용을 기준으로 결정

기존 메인 라우터에 충분한 CPU와 메모리, 관리 가능한 펌웨어가 있고 가정의 네트워크 구조가 단순하다면 메인 라우터에서 mihomo를 직접 실행하는 편이 중간 계층을 줄일 수 있습니다. 기본 게이트웨이와 투명 프록시 경로도 더 명확합니다. 설치할 때는 관리 접속 경로를 남겨 두고 단일 테스트 IP부터 활성화한 뒤 전체 LAN으로 확대하세요.

메인 라우터를 통신사가 관리하거나 펌웨어 확장 기능이 제한적이고, 프록시 장애를 기본 인터넷 연결과 분리하고 싶다면 보조 라우터가 더 적합합니다. 보조 라우터는 “클라이언트 게이트웨이를 보조 라우터로 지정”할지 “메인 라우터에서 정책 전달”을 사용할지 한 가지 방식으로 명확히 정하고, DHCP·반환 라우팅과 DNS를 미리 처리해야 합니다. 여러 규칙이 우연히 연결되기를 기대해서는 안 됩니다.

TProxy는 TCP와 UDP를 함께 처리할 수 있어 기능이 완전한 Linux 라우터 환경에 더 적합합니다. TUN은 가상 네트워크 인터페이스가 트래픽을 통합 처리하도록 구성하고 싶으며 하드웨어 리소스도 충분한 기기에 적합합니다. 어떤 방식을 선택하든 안정적인 설치의 원칙은 같습니다. 설정을 영구 저장하고, 노드 연결은 우회하며, 서비스와 방화벽을 순서대로 시작하고, 롤백 경로를 남기고, 단일 클라이언트에서 항목별로 검증해야 합니다.