OpenWrt 라우터·우회 라우터에 mihomo 설치하기: 배포 방식과 하드웨어 요구 사항

커널, 관리 화면, 투명 프록시를 구분하기

mihomo는 Clash 설정 체계를 이어받은 프록시 커널로, 초기에는 Clash Meta라는 이름으로 불렸습니다. YAML 설정을 읽어 노드 연결, 프록시 그룹, DNS, 분기 규칙을 처리합니다. OpenWrt는 네트워크 인터페이스, 라우팅, 방화벽, 서비스 관리를 담당합니다. 라우터에 실행 파일을 넣었다고 해서 LAN 기기의 트래픽까지 프록시를 거치는 것은 아닙니다.

라우터에 배포할 때는 세 가지를 각각 확인해야 합니다. 서비스가 시작되는지, 단말 트래픽이 커널에 도달하는지, 커널이 올바른 출구를 선택하는지입니다. LuCI 관리 플러그인은 대개 이 과정을 통합해 처리하지만, 커널을 수동으로 설치하면 각 단계를 직접 연결해야 합니다.

• 명시적 프록시: 컴퓨터나 브라우저에서 라우터 주소와 HTTP·SOCKS 포트를 지정합니다. 이 설정을 따르는 앱만 프록시를 사용합니다.
• 투명 프록시: 게이트웨이가 리디렉션, 정책 라우팅 또는 TUN으로 트래픽을 가로채므로 단말마다 프록시 주소를 입력할 필요가 없습니다.
• DNS 분기: 도메인에 응답할 리졸버를 선택하고 규칙 매칭에 필요한 정보를 제공합니다. 트래픽 전달과 관련은 있지만 같은 기능은 아닙니다.

기본 라우터와 우회 라우터의 네트워크 구성 차이

기본 라우터 배포: 트래픽이 한곳에 모이고 영향 범위도 넓음

기본 라우터는 상위 네트워크에 직접 연결되며, 보통 PPPoE 접속, DHCP, DNS 전달, NAT를 함께 담당합니다. 단말의 기본 게이트웨이가 기본 라우터를 가리키므로 투명 프록시의 트래픽 경로가 비교적 명확합니다. 설정 업데이트, 규칙 로드, 프록시 프로세스도 PPPoE 접속, 무선 네트워크, 기타 서비스와 리소스를 나눠 씁니다.

인터넷
  │
OpenWrt 기본 라우터: LAN 192.168.1.1
  │
스위치 / 무선 액세스 포인트
  │
컴퓨터: 192.168.1.100, 게이트웨이 192.168.1.1

지원되는 OpenWrt 기기를 이미 보유하고 있고 네트워크 전체 트래픽을 한곳에서 관리하려는 환경에 적합합니다. 적용 전에 로컬 관리 경로를 남겨 두세요. 프록시 서비스에 문제가 생겼을 때 기본 포워딩이 일반 연결로 복구되는지는 플러그인의 방화벽 규칙 정리 및 오류 처리 방식에 따라 다르며, 자동 복구된다고 가정하면 안 됩니다.

단일 인터페이스 우회 라우터: 단말별 시험 적용과 응답 경로 확인

일반적인 우회 라우터는 LAN 인터페이스 하나만 사용하며 기본 라우터와 같은 스위치 네트워크에 연결됩니다. 인터넷 연결은 기본 라우터가 계속 담당합니다. 테스트 컴퓨터의 기본 게이트웨이를 192.168.1.2로 바꾸고, 우회 라우터 자체의 기본 게이트웨이는 192.168.1.1로 둡니다. 우회 라우터에서는 IP 포워딩을 켜고 해당 포워딩을 허용하는 방화벽 규칙을 설정해야 합니다.

기본 라우터: 192.168.1.1, 인터넷 연결 및 기존 DHCP 담당
  │
동일한 LAN 스위치 네트워크
  ├─ 우회 라우터: 192.168.1.2, 기본 게이트웨이 192.168.1.1
  └─ 테스트 컴퓨터: 192.168.1.100, 기본 게이트웨이 192.168.1.2

이 구성에서는 나가는 트래픽은 우회 라우터를 거치지만 응답 트래픽은 기본 라우터가 단말로 바로 보내는 비대칭 경로가 생길 수 있습니다. 우회 라우터에서 소스 NAT를 사용할지는 플러그인 요구 사항과 연결 추적 결과를 확인해 결정하세요. SNAT를 켜면 일부 응답이 우회 라우터를 다시 거치게 할 수 있지만 원래 단말 주소가 숨겨집니다. 모든 인터페이스에서 마스커레이드를 켜는 방법을 만능 해결책으로 취급하지 마세요.

배포 방식 세 가지와 유지 관리 비용

플러그인을 사용하면 구독, 프록시 그룹, 실행 로그를 관리하기 편리한 경우가 많습니다. 다만 지원하는 커널과 방화벽 백엔드를 확인해야 합니다. OpenWrt 22.03부터 기본 방화벽은 nftables 기반의 firewall4입니다. 기존 플러그인이 전통적인 iptables 규칙만 생성한다면 설치에 성공했다는 이유만으로 투명 프록시가 작동한다고 판단할 수 없습니다. 커스텀 펌웨어는 구성 요소를 바꿨을 수 있으므로 실제 환경을 확인하세요.

네이티브 실행은 설정 출처와 업데이트 시점을 직접 관리하려는 사용자에게 적합합니다. 먼저 커널의 설정 검사 명령으로 확인한 뒤 procd에 서비스를 맡길 수 있습니다. 구독 파일에 라우터용 DNS, 리스닝, 트래픽 가로채기 설정이 없다면 로컬 설정을 병합해야 합니다. 그렇지 않으면 구독을 한 번 업데이트하는 것만으로 로컬 설정이 덮어써질 수 있습니다.

컨테이너는 리소스가 넉넉한 기기에 적합하지만 투명 프록시의 복잡성을 없애 주지는 않습니다. TUN을 사용하려면 일반적으로 /dev/net/tun과 관련 네트워크 관리 권한이 필요합니다. 브리지 네트워크에서 지정한 리스닝 주소도 호스트의 LAN 주소와는 다릅니다. 컨테이너를 시작하려고 모든 권한을 부여하지 마세요.

# 커널이 /usr/bin/mihomo에 있다고 가정
/usr/bin/mihomo -v
/usr/bin/mihomo -t -d /etc/mihomo -f /etc/mihomo/config.yaml

위 경로는 수동 배포 예시이며 모든 플러그인에 적용되는 고정 경로가 아닙니다. 테스트할 때는 플러그인이 실제로 사용하는 설정 파일을 확인하세요. 일부 플러그인은 다운로드한 구독 파일을 직접 사용하지 않고 임시 디렉터리에 최종 설정을 생성합니다.

구조 선택과 메모리·저장 공간 계획

CPU와 펌웨어 타깃을 먼저 확인한 뒤 커널 파일 선택

ubus call system board
uname -m
cat /proc/cpuinfo
free -m
df -h /overlay /tmp

ubus call system board로 기기와 펌웨어 타깃 정보를 확인할 수 있으며, uname -m은 실행 아키텍처를 파악하는 데 도움이 됩니다. 일반적으로 aarch64는 ARM64, x86_64는 AMD64에 해당합니다. MIPS는 엔디안과 소프트웨어 부동소수점 등 빌드 조건도 구분해야 합니다. “MIPS”라는 정보만 보고 파일을 고르면 안 됩니다.

ARMv7이나 특정 CPU 명령어 집합이 필요한 x86 빌드도 하드웨어와 맞아야 합니다. Exec format error가 발생하면 우선 아키텍처와 파일 형식을 확인하고, Illegal instruction이 발생하면 필요한 명령어 집합을 확인하세요. 어느 문제도 구독 링크를 바꿔서 해결할 수 없습니다.

용량 수치는 계획용이며 성능을 보장하지 않습니다

이 수치는 용량 계획 참고용이며 실제 처리량이나 최소 시스템 요구 사항을 뜻하지 않습니다. 실제 사용량은 규칙 제공자, 지리 데이터 형식, 연결 수, DNS 캐시, 플러그인 구현에 따라 달라집니다. free 출력에서 ‘free’ 메모리가 적다고 곧바로 메모리 부족으로 판단하지 말고, 사용 가능 메모리, 프로세스 상주 메모리, 커널 로그를 함께 확인하세요.

• 저장 공간: 현재 커널, 설정, 규칙 데이터를 고려해 용량을 계획하세요. 업데이트 중에는 기존 파일, 다운로드 패키지, 압축 해제 파일이 동시에 남을 수도 있습니다.
• 임시 디렉터리: OpenWrt의 /tmp는 보통 메모리 파일 시스템을 사용하므로 큰 파일을 다운로드하면 실행 메모리와 공간을 두고 경쟁합니다.
• 쓰기 빈도: 용량이 작은 플래시에 디버그 로그를 계속 쓰지 마세요. 평소에는 적절한 로그 수준을 사용하고 문제를 조사할 때만 상세 로그를 잠시 켜세요.
• CPU: 프록시 암호화, 사용자 공간 포워딩, 규칙 매칭에는 연산 자원이 필요합니다. 기가비트 포트가 있다고 해서 모든 프록시 프로토콜이 기가비트 속도로 동작하는 것은 아닙니다.

게이트웨이·DNS·포트 설정 범위

각 주소의 역할을 명확히 구분하기

앞서 든 우회 라우터 예시에서 테스트 컴퓨터의 게이트웨이는 192.168.1.2입니다. 우회 라우터가 LAN DNS를 제공한다면 해당 주소를 컴퓨터의 DNS로 지정할 수도 있지만, 우회 라우터가 실제로 LAN의 53번 포트에서 수신 중이어야 합니다. DNS만 바꿔서는 일반 인터넷 트래픽이 자동으로 우회 라우터를 통과하지 않습니다. 게이트웨이만 바꿔도 DNS 질의가 커널의 리졸버를 거친다고 보장할 수 없습니다.

일반적인 구성 중 하나는 dnsmasq가 LAN에 53번 포트를 제공하고 필요한 질의를 127.0.0.1:1053의 커널로 전달하는 방식입니다. 이때 질의가 되돌아오는 순환을 막아야 합니다. 예를 들어 커널이 dnsmasq를 업스트림으로 사용하고 dnsmasq가 다시 모든 요청을 커널로 보내면 DNS 조회 루프가 발생합니다. 관리 플러그인이 이미 DNS를 관리하고 있다면 플러그인 설정을 변경하고, 같은 규칙을 별도로 추가하지 마세요.

fake-ip와 IPv6를 함께 점검하기

fake-ip 모드는 보통 198.18.0.0/16 같은 예약 주소 대역에서 매핑 주소를 반환합니다. 이런 주소를 받았다고 해서 DNS 조회가 실패한 것은 아닙니다. 다만 이후 연결은 같은 프록시 처리 경로에서 다뤄야 합니다. 단말이 fake-ip를 받은 뒤 우회 라우터를 거치지 않고 접속하면 도메인은 조회되지만 연결이 시간 초과될 수 있습니다.

IPv4 게이트웨이를 바꿔도 IPv6 경로는 자동으로 바뀌지 않습니다. 기본 라우터가 라우터 광고를 통해 IPv6 기본 경로와 DNS를 단말에 계속 알리면 일부 연결은 다른 경로를 사용할 수 있습니다. IPv6 트래픽까지 완전히 처리하도록 설정하거나 시험 단계에서 테스트 단말의 IPv6를 명시적으로 제한한 다음 각각 검증하세요. IPv4 연결이 한 번 성공했다고 듀얼 스택 트래픽이 모두 가로채졌다고 판단하면 안 됩니다.

투명 프록시·TUN·방화벽의 연동 방식

일반적인 트래픽 가로채기 방식으로는 TCP 리디렉션, TPROXY, TUN이 있습니다. TCP 리디렉션은 주로 TCP를 처리합니다. TPROXY는 TCP와 UDP에 사용할 수 있지만 관련 커널 모듈, 정책 라우팅, 방화벽 규칙이 필요합니다. TUN은 가상 네트워크 장치로 IP 패킷을 받아 처리하며 올바른 라우팅, 권한, 포워딩 설정도 필요합니다.

mihomo의 tun.auto-route는 관련 경로를 자동으로 설정하며, auto-redirect는 Linux의 자동 리디렉션 기능과 관련됩니다. 사용 가능 여부는 커널 버전과 시스템 종속성을 확인해야 합니다. 이 옵션만으로 모든 LAN 기기의 트래픽을 가로챌 수 있는 것은 아닙니다. 특히 기존 플러그인이 규칙을 생성했다면 자동 라우팅 방식을 중복으로 활성화하지 마세요.

• LAN 관리 트래픽과 필요한 사설망 트래픽이 올바른 경로를 사용하도록 설정해 라우터 관리 화면 접속까지 프록시 출구로 보내지 않도록 하세요.
• 프록시 노드 자체의 연결이 같은 트래픽 가로채기 지점에 다시 들어가지 않도록 확인하세요. 그렇지 않으면 트래픽 루프가 생길 수 있습니다.
• 소프트웨어 및 하드웨어 플로우 오프로드가 현재 트래픽 가로채기 설정을 우회하는지 확인하세요. 먼저 오프로드를 끄고 기준 동작을 검증한 뒤 플러그인의 호환성 안내에 따라 다시 설정하세요.
• 투명 프록시 관리 서비스는 하나만 실행하세요. 플러그인 두 개가 DNS 포트를 두고 충돌하거나 라우팅을 덮어쓰고 같은 연결을 중복 가로챌 수 있습니다.

# OpenWrt의 현재 상태 확인; 구체적인 명령은 설치된 구성 요소에 따라 다름
ip route show
ip rule show
nft list ruleset
logread | grep -i mihomo
dmesg | grep -i -E 'oom|out of memory'

ip route show는 기본적으로 주 라우팅 테이블을 표시합니다. 정책 규칙이 다른 테이블을 참조한다면 해당 테이블도 확인해야 합니다. 로그에 서비스 시작 성공이라고 표시되어도 프로세스가 실행 중이라는 뜻일 뿐, LAN 포워딩, DNS, UDP 경로까지 검증됐다는 의미는 아닙니다.

단말 한 대씩 단계별로 검증하고 문제 발생 시 되돌리기

1. 기준 설정을 저장합니다. OpenWrt 설정을 백업하고 기본 라우터, 우회 라우터, DHCP 범위, 관리 주소를 기록하세요. 기본 라우터를 게이트웨이로 계속 사용하는 관리용 단말을 한 대 남겨 두세요.
2. 먼저 커널을 검증합니다. 설정을 검사해 구독이 로드되는지, 프록시 그룹에 선택 가능한 노드가 있는지, 서비스가 반복해서 종료되지 않는지 확인하세요. 노드 연결에는 시간 동기화와 상위 네트워크 연결도 필요합니다.
3. 먼저 명시적 프록시를 시험합니다. 예시 포트 7890에서 LAN 접속을 허용하고 프록시를 활성화했다면 테스트 컴퓨터에서 아래 요청을 실행해 노드 문제와 투명 프록시 처리 문제를 구분하세요.
4. 그다음 테스트 컴퓨터의 게이트웨이를 바꿉니다. 192.168.1.2로 설정하고 실제 DNS 구성에 맞게 리졸버 주소를 지정하세요. LAN 관리, 직접 연결 사이트, 프록시 규칙이 각각 정상인지 확인합니다.
5. 규칙과 연결 상태를 확인합니다. 관리 패널에서 대상 도메인, 매칭된 규칙, 프록시 그룹, 최종 노드를 확인하세요. 웹페이지가 열린다고 해서 프록시를 거쳤다고 단정할 수 없습니다. DIRECT 규칙이 적용됐을 수도 있습니다.
6. 마지막으로 적용 범위를 넓힙니다. UDP, IPv6, 규칙 업데이트, 기기 재시작을 시험하세요. 모두 통과하면 DHCP 배포 정책을 바꾸거나 더 많은 단말로 적용 범위를 넓힙니다.

# 테스트 컴퓨터에서 실행; 해당 HTTP 프록시 포트를 먼저 활성화해야 함
curl -I --proxy http://192.168.1.2:7890 https://example.com/

# 우회 라우터에서 LAN DNS를 제공하는지 확인한 뒤 실행
nslookup example.com 192.168.1.2

첫 번째 명령은 HTTP 프록시 연결을 확인할 뿐 모든 앱, UDP, 투명 프록시가 작동한다는 뜻은 아닙니다. 두 번째 명령은 지정한 DNS 서버가 응답하는지만 확인하며, 응답이 예상한 업스트림을 거쳤다는 의미는 아닙니다. 커널 조회 로그와 실제 연결 기록을 함께 확인하세요.

되돌릴 때는 먼저 테스트 컴퓨터의 게이트웨이와 DNS를 기존 값으로 복구한 뒤 프록시 서비스를 중지하고 플러그인이 트래픽 가로채기 규칙을 정리했는지 확인하세요. DHCP 설정을 변경했다면 단말에서 임대 정보를 새로 받아야 합니다. 커널 프로세스만 종료하고 종료된 포트로 향하는 방화벽 리디렉션을 남겨 두지 마세요.

배포 전 선택 요약

안정적으로 운영 중인 OpenWrt 기본 라우터가 있고 리소스도 충분하다면 한곳에 배포해 추가 게이트웨이 관리 부담을 줄일 수 있습니다. 기존 인터넷 구성을 유지하면서 단계별로 검증하려면 먼저 우회 라우터를 사용할 수 있지만, 단말 게이트웨이 배포, DNS 경로, 응답 경로를 직접 관리해야 합니다. 우회 라우터는 네트워크 전체를 자동으로 가로채는 장치를 뜻하는 이름이 아니라 구체적인 포워딩 구성 방식입니다.

기기를 선택할 때는 CPU 아키텍처, 사용 가능한 메모리, 영구 저장 공간을 먼저 확인한 뒤 펌웨어 방화벽과 호환되는 관리 방식을 고르세요. 적용은 “명시적 프록시 → 단말 한 대 투명 프록시 → DNS 및 듀얼 스택 → 전체 네트워크 확장” 순서로 진행합니다. 각 단계의 범위가 명확해 문제가 생겨도 구독, 게이트웨이, 방화벽을 한꺼번에 바꾸지 않고 검증된 이전 단계로 돌아갈 수 있습니다.