OpenWrt 보조 라우터에서 mihomo 실행하기: 구성 방식과 투명 프록시 설정

먼저 트래픽이 어느 장비를 거치는지 확인하세요

OpenWrt에서 mihomo를 실행했다고 해서 프록시 커널만 동작할 뿐, LAN 기기까지 투명 프록시를 사용하게 되는 것은 아닙니다. 전체 경로에는 최소 세 단계가 필요합니다. 단말이 트래픽을 보조 라우터로 보내고, 보조 라우터가 해당 연결을 커널로 전달하며, 커널이 규칙에 따라 직접 연결 또는 프록시 출구를 선택합니다. DNS 경로도 별도로 설계해야 합니다. 기본 게이트웨이만 바꿨다고 설정이 끝난 것은 아닙니다.

mihomo는 Clash Meta를 이어 발전한 프록시 커널이며, GUI가 있는 데스크톱 클라이언트와는 다릅니다. 라우터 플러그인은 보통 커널 다운로드, 설정 파일 생성, 방화벽 규칙 구성, 서비스 관리를 담당합니다. 커널을 직접 설치하면 이 작업을 직접 처리해야 합니다. 이미 플러그인이 네트워크를 관리 중인 장비에 별도의 수동 투명 프록시 규칙까지 추가하는 것은 피하는 편이 좋습니다.

먼저 단말 한 대로 테스트하세요

메인 라우터의 기존 DHCP 설정은 유지하고 테스트용 PC 한 대의 게이트웨이와 DNS만 변경하세요. 관리 페이지, LAN 접속, 프록시 연결이 모두 정상인지 확인한 뒤 전체 네트워크에 적용하는 것이 좋습니다. 작업 전에는 로컬 관리 경로를 확보해 두세요. 변경 중인 프록시 경로를 통해 원격으로 네트워크를 수정하면 접속이 끊길 수 있습니다.

자주 쓰이는 배치 방식 세 가지

구성 방식	트래픽 진입점	주요 확인 항목
메인 라우터에서 커널 실행	단말의 기본 게이트웨이가 OpenWrt	WAN 출구, 포워딩 영역, DNS, 라우팅 처리
같은 서브넷의 단일 인터페이스 보조 라우터	단말의 기본 게이트웨이를 보조 라우터로 설정	동일 인터페이스 포워딩, 응답 경로, ICMP 리다이렉트
별도 서브넷 보조 라우터	단말이 보조 라우터 하위 서브넷에 연결	상위 라우터의 정적 경로 또는 NAT, 하위 DHCP, 서브넷 간 접근

메인 라우터 방식은 경로가 단순하지만 장애 영향 범위가 큽니다. 같은 서브넷의 단일 인터페이스 방식은 단계별 테스트에 편리하지만, 요청은 보조 라우터를 거치고 응답은 단말로 직접 돌아가는 비대칭 경로가 생기기 쉽습니다. 별도 서브넷 방식은 경계가 명확하지만 추가 라우팅이나 NAT를 관리해야 합니다. 장비의 LAN 포트 수가 아니라 현재 네트워크 구성에 맞춰 선택하세요.

게이트웨이와 DNS 설정 방법

아래 주소는 구성을 설명하기 위한 예시이며 실제 측정값이 아닙니다. 메인 라우터는 192.168.10.1, OpenWrt 보조 라우터는 192.168.10.2, 테스트 단말은 192.168.10.100이며 서브넷 마스크는 모두 255.255.255.0입니다. 보조 라우터의 기본 경로는 메인 라우터를 가리키고, 테스트 단말의 기본 게이트웨이는 보조 라우터를 가리킵니다.

테스트 단말 192.168.10.100
  기본 게이트웨이: 192.168.10.2
  DNS：192.168.10.2
        ↓
OpenWrt 보조 라우터 192.168.10.2
  기본 게이트웨이: 192.168.10.1
        ↓
메인 라우터 192.168.10.1
        ↓
인터넷

게이트웨이는 경로를, DNS는 조회 지점을 결정합니다

DNS만 변경: 도메인 조회는 보조 라우터에 도달해도 실제 연결은 메인 라우터를 통해 직접 전달될 수 있습니다. 이것만으로 투명 프록시가 작동한다고 판단할 수는 없습니다.
게이트웨이만 변경: 트래픽은 보조 라우터를 통과할 수 있지만 단말은 기존 DNS 서버에 계속 조회합니다. 도메인 기반 판별과 DNS 응답 정책이 예상과 다르게 작동할 수 있습니다.
둘 다 변경: 테스트 경로를 일관되게 구성하기 쉬워집니다. 그래도 보조 라우터에서 포워딩을 허용하고 실제 트래픽을 가로채도록 설정했는지 확인해야 합니다.

일반적인 LuCI 화면에서는 「네트워크」→「인터페이스」→「LAN」→「편집」에서 고정 IP를 확인할 수 있습니다. 기본 게이트웨이와 DNS 설정 메뉴는 펌웨어 버전에 따라 다를 수 있습니다. 메인 라우터가 DHCP를 담당한다면 네트워크 전체에 배포할 때 보통 DHCP 옵션 3(기본 게이트웨이)과 6(DNS 서버)을 설정합니다. 같은 브로드캐스트 도메인에서 메인 라우터와 보조 라우터가 조율 없이 동시에 DHCP를 제공하지 않도록 하세요. 단말마다 다른 게이트웨이를 받을 수 있습니다.

같은 서브넷의 단일 인터페이스 포워딩에서는 ICMP 리다이렉트도 확인해야 합니다. 일부 라우팅 동작은 단말에 메인 라우터를 직접 사용하도록 알려 원래 경로를 우회시킬 수 있습니다. 소스 NAT가 필요한지는 응답 경로와 트래픽 처리 방식에 따라 다릅니다. ‘마스커레이드 활성화’를 만능 해결책으로 여기면 안 됩니다. 커널이나 상위 라우터에서 보이는 소스 주소가 바뀌어 단말별 규칙과 로그에도 영향을 줄 수 있습니다.

설치 전 시스템과 커널 확인하기

먼저 CPU 아키텍처, 사용 가능한 저장 공간, 방화벽 구성을 확인한 다음 실행 파일을 선택하세요. OpenWrt 패키지의 아키텍처 명칭과 배포 파일의 명칭이 항상 일치하는 것은 아니므로 장비 제품명만 보고 고르면 안 됩니다. ARM 장비는 32비트·64비트 여부와 세부 명령어 집합을 확인해야 합니다. x86 장비도 CPU가 선택한 빌드를 지원하는지 확인하세요.

ubus call system board
uname -m
df -h /overlay
free
command -v fw4
command -v nft
ls -l /dev/net/tun
ip route show
ip -6 route show

공식 OpenWrt 23.05 및 24.10 계열의 일반적인 환경에서는 보통 firewall4가 nftables를 관리합니다. 서드파티 펌웨어는 관련 구성 요소를 변경했을 수 있으므로 장비에서 직접 확인해야 합니다. 이전 버전 가이드의 iptables 명령이 현재 시스템에도 맞는다고 볼 수는 없습니다. 특히 같은 연결을 두 규칙 시스템이 동시에 관리하지 않도록 하세요.

서비스를 시작하기 전에 설정부터 검증하세요

이 문서에서는 커널 경로를 /usr/bin/mihomo, 작업 디렉터리를 /etc/mihomo, 설정 파일을 /etc/mihomo/config.yaml로 가정합니다. 이는 설명에 사용하는 로컬 경로이며 모든 플러그인의 기본 경로는 아닙니다. 규칙 파일, 지리 데이터, 캐시도 실제 설정에 맞게 배치하세요. YAML만 복사하고 실행에 필요한 파일을 빠뜨리지 않도록 주의해야 합니다.

/usr/bin/mihomo -v
/usr/bin/mihomo -t -d /etc/mihomo -f /etc/mihomo/config.yaml

-v는 실제 커널 버전을 확인할 때, -t는 설정을 테스트할 때 사용합니다. 테스트 통과는 커널이 설정을 읽고 필요한 항목을 불러올 수 있다는 뜻일 뿐, 단말 라우팅과 방화벽까지 올바르다는 의미는 아닙니다. 처음 문제를 확인할 때는 포그라운드에서 실행해 로그를 살펴본 다음 OpenWrt의 procd로 관리하세요. 플러그인이 관리 중이라면 플러그인의 서비스 메뉴를 사용해 커널 프로세스가 중복 실행되지 않도록 하세요.

먼저 로컬 프록시와 DNS 기준을 확인하세요

투명 프록시를 적용하기 전에 명시적 프록시부터 확인하는 것이 좋습니다. 아래 설정은 로컬 리스너와 직접 연결을 위한 기준만 구성하며, 프록시 노드는 포함하지 않고 단말이 자동으로 프록시 출구를 사용하게 하지도 않습니다. 실제 배포 시에는 유효한 설정 파일에 병합하세요. 파일 끝에 같은 이름의 최상위 필드를 다시 추가하지 마세요.

mixed-port: 7890
allow-lan: false
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:
    - 1.1.1.1
    - 8.8.8.8

rules:
  - MATCH,DIRECT

mixed-port: 7890: 명시적 HTTP/SOCKS 프록시에 사용하는 포트이며 투명 프록시 진입점은 아닙니다. 테스트 PC에서 이 포트에 접속하려면 LAN 수신 설정과 엄격한 접근 제한을 별도로 구성해야 합니다.
allow-lan: false: 이 기본 설정에서는 LAN에 명시적 프록시 서비스를 공개하지 않습니다. TUN이 포워딩 트래픽을 처리하는 것과 이 포트를 개방하는 것은 별개입니다.
127.0.0.1:9090: 컨트롤 인터페이스는 로컬에서만 수신합니다. 원격 관리가 필요하면 인증과 접근 범위를 별도로 설계하고, 인터넷에 그대로 공개하지 마세요.
127.0.0.1:1053: DNS는 로컬에서 전달된 요청만 받습니다. 여기서 포트 53을 사용하지 않는 이유는 dnsmasq의 수신 포트와 직접 충돌하는 일을 피하기 위해서입니다.
MATCH,DIRECT: 규칙에 맞지 않는 연결은 모두 직접 연결합니다. 먼저 연결 경로를 확인하기 위한 설정입니다. 프록시 출구를 사용하려면 유효한 노드와 정책 그룹, 관련 규칙을 추가해야 합니다.

장비에 curl과 nslookup이 설치되어 있다면 보조 라우터에서 명시적 프록시와 LAN DNS를 각각 테스트할 수 있습니다. 예시 도메인은 연결 확인용이며 응답 시간으로 프록시 노드 품질을 판단할 수는 없습니다.

curl --proxy http://127.0.0.1:7890 -I https://example.com
nslookup example.com 192.168.10.2

DNS 전달 경로는 하나로 정리하세요

확인하기 쉬운 구성 한 가지는 단말이 보조 라우터의 53 포트로 조회하고, dnsmasq가 로컬 mihomo의 1053 포트로 전달하는 방식입니다. 일반적인 LuCI 경로는 「네트워크」→「DHCP/DNS」→「일반 설정」→「DNS 전달」입니다. 여기에 127.0.0.1#1053을 입력하고, 상위 장비에서 다른 DNS 서버를 받아오고 있지는 않은지도 확인하세요. 모든 외부 조회를 커널로 전달하려면 펌웨어 화면에 맞춰 ‘resolv 파일 무시’ 등의 설정을 조정하고, 필요한 로컬 도메인 처리는 유지해야 합니다.

DNS 루프 방지하기

dnsmasq가 조회를 mihomo에 전달한다면 mihomo의 상위 DNS를 같은 dnsmasq 전달 경로로 다시 지정하면 안 됩니다. 여기에 나온 숫자 IP 상위 DNS는 경로 설명용일 뿐, 일괄 권장 설정이 아닙니다. 도메인 이름을 사용하는 암호화 DNS로 바꾸려면 상위 DNS 도메인의 초기 조회 방법과 상위 서버 연결이 직접 연결인지 프록시를 경유하는지도 고려해야 합니다.

투명 프록시 트래픽 처리 방식 세 가지

투명 프록시는 단말의 앱마다 프록시 주소를 입력할 필요가 없다는 뜻이지, 모든 프로토콜이 자동으로 프록시를 지원한다는 뜻은 아닙니다. 실제 처리 범위는 트래픽 처리 방식, 커널 지원, 노드 프로토콜, 방화벽 규칙에 따라 달라집니다. UDP, IPv6, LAN 목적지 주소는 각각 따로 확인해야 합니다.

방식	작동 원리	구성 시 주의 사항
REDIRECT	방화벽이 연결을 투명 프록시 수신 포트로 리다이렉트	주로 TCP에 사용합니다. TCP 리다이렉트 규칙만으로 UDP까지 모두 처리할 수는 없습니다.
TPROXY	투명 소켓과 트래픽 마크, 정책 라우팅을 함께 사용	TCP와 UDP에 사용할 수 있지만 이에 맞는 커널 모듈, 라우팅, 방화벽 규칙이 필요합니다.
TUN	가상 L3 장치를 통해 IP 트래픽을 커널로 전달	TUN 지원과 권한이 필요하며, 라우팅과 LAN 포워딩이 처리 경로에 포함되는지도 확인해야 합니다.

주요 방식을 하나 선택한 뒤 구성하세요. ‘더 폭넓게 처리하려고’ 플러그인 TPROXY, 직접 설정한 REDIRECT, 별도의 TUN 자동 라우팅을 동시에 켜지 마세요. 중복으로 연결이 커널에 전달되거나 마크가 충돌하고 라우팅 루프가 생길 수 있습니다. 이 경우 일부 사이트만 열리고 다른 연결은 계속 시간 초과되는 현상이 나타나기도 합니다.

TUN 설정 항목 예시

아래 예시는 해당 항목을 지원하는 Linux용 mihomo 빌드에서 사용할 수 있으며, TUN 트래픽 처리 방향을 설명하기 위한 것입니다. 모든 OpenWrt 펌웨어에서 바로 사용할 수 있는 설정은 아닙니다. 실제 커널로 설정을 테스트하고 실행 로그, 생성된 규칙, 라우팅을 확인하세요. 구버전 빌드에서는 일부 항목을 지원하지 않을 수 있습니다.

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-redirect: true
  strict-route: true
  dns-hijack: []

enable: TUN을 활성화합니다. 시스템에서 TUN 장치를 사용할 수 있어야 하며 필요한 네트워크 관리 권한도 있어야 합니다.
stack: mixed: 혼합 프로토콜 스택을 선택합니다. 투명 프록시 진입점을 여러 개 동시에 켠다는 뜻은 아닙니다.
auto-route: 커널이 관련 자동 라우팅을 설정하도록 합니다. LAN에서 라우터로 향하는 게이트웨이 설정을 대신하지 않으며, 펌웨어의 모든 포워딩 정책이 트래픽을 허용한다고 보장하지도 않습니다.
auto-redirect: 지원되는 Linux 환경에서 자동 라우팅과 함께 트래픽 처리에 필요한 규칙을 만듭니다. firewall4, 기존 플러그인, 정책 라우팅과 충돌하지 않는지 실제 환경에서 확인해야 합니다.
strict-route: 트래픽 처리 라우팅을 더 엄격하게 제한합니다. 그렇다고 IPv6와 모든 우회 경로까지 점검이 끝난 것은 아닙니다.
dns-hijack: []: 이 예시에서는 TUN이 DNS를 가로채지 않고, 앞에서 정한 dnsmasq 전달 경로를 계속 사용합니다. 첫 배포부터 두 가지 DNS 처리 방식을 겹쳐 사용하지 않기 위해서입니다.

TUN으로 DNS까지 처리하려면 조회 진입점, 상위 DNS, 제외 규칙을 다시 확인하세요. any:53만 복사해 넣는다고 설정이 끝나는 것은 아닙니다. 기존 UDP/TCP 53 조회, 앱 자체 DoH, 운영체제의 비공개 DNS는 서로 다른 경로입니다. 포트 53을 처리해도 앱 내부의 암호화 DNS까지 자동으로 처리되지는 않습니다.

IPv6, 응답 경로, 방화벽 경계

IPv4 테스트가 성공해도 듀얼 스택 단말의 모든 연결이 보조 라우터를 거친다고 볼 수는 없습니다. 메인 라우터가 IPv6 라우터 광고로 단말에 기본 경로를 계속 제공할 수 있습니다. 이 경우 단말이 AAAA 레코드가 있는 사이트에 접속하면 다른 경로를 사용할 수 있습니다. DHCPv4 옵션 3과 6만 바꿔서는 이 IPv6 경로를 제어할 수 없습니다.

먼저 테스트 단말에서 IPv4와 IPv6 기본 경로를 확인하고 실제 다음 홉을 파악하세요.
듀얼 스택 전체를 처리할지, 테스트 범위에서는 우선 IPv4로 제한할지 명확히 결정하세요. mihomo의 IPv6 DNS 응답만 끈다고 시스템의 IPv6까지 비활성화되는 것은 아닙니다.
LAN에서 상위 네트워크로의 포워딩 권한, 동일 인터페이스 포워딩, 관련 방화벽 영역을 확인하세요. 문제 해결을 위해 모든 영역의 입력과 포워딩을 허용으로 바꾸면 안 됩니다.
라우터 관리 주소와 내부 네트워크 대역, 프록시 서버 자체 연결에 대한 우회 처리를 확인하세요. 출구 연결이 다시 트래픽 처리 진입점으로 돌아가지 않도록 해야 합니다.

nft list ruleset으로 방화벽 규칙을, ip rule show와 ip route show table all로 정책 라우팅을 확인할 수 있습니다. 명령 출력은 기존 플러그인과 펌웨어 구성을 함께 고려해 판단하세요. 구현마다 이름과 우선순위가 다를 수 있으므로 특정 테이블 번호나 규칙 이름만 보고 성공 여부를 결정하지 마세요.

단계별 확인과 안전한 원복

문제 해결은 트래픽 진입점부터 출구까지 단계별로 확인하고, 한 번에 변수 하나만 바꾸는 것이 좋습니다. 웹페이지가 열린다는 사실만으로는 직접 연결인지, 명시적 프록시인지, 투명 프록시인지 구분할 수 없습니다. 단말 라우팅, 커널 연결 로그, 실제 적용된 정책을 함께 확인하세요.

증상	먼저 확인할 항목	다음 단계
단말에서 보조 라우터 관리 페이지에 접속할 수 없음	IP 주소, 서브넷 마스크, 주소 충돌, 입력 규칙	먼저 LAN 관리를 복구하고 투명 프록시 설정은 계속 진행하지 마세요.
IP 연결은 되지만 도메인 이름 조회 실패	53 및 1053 포트 수신 상태, dnsmasq 전달, DNS 루프	LAN DNS 진입점과 커널 상위 DNS를 각각 확인하세요.
로컬 명시적 프록시는 정상인데 단말 연결 로그가 없음	기본 게이트웨이, IPv6, 포워딩, 트래픽 처리 규칙	트래픽이 실제로 보조 라우터에 도달하는지 확인하세요.
TCP는 정상이지만 게임이나 음성 통화에 문제가 있음	UDP 처리, 노드의 UDP 지원 여부, 방화벽	해당 프로토콜로 다시 테스트하고 웹페이지 접속 결과만으로 판단하지 마세요.
방화벽을 다시 불러온 뒤 연결이 끊김	자동 트래픽 처리 규칙이 여전히 존재하는지	해당 서비스에서 규칙을 다시 생성하고 서비스 시작 순서를 확인하세요.

원복은 단말 설정을 먼저, 서비스를 나중에 변경하세요.

테스트에 실패하면 먼저 테스트 단말의 기본 게이트웨이를 192.168.10.1로 되돌리고, DNS도 기존의 유효한 설정으로 복구하세요. 그런 다음 새로 추가한 서비스를 중지하고 해당 서비스가 생성한 트래픽 처리 규칙을 정리합니다. TUN 종료 후 라우팅도 확인해야 합니다. 실행 파일만 삭제해서는 충분하지 않습니다. 전체 DHCP 설정을 바꿨다면 기존 설정을 복구하고 단말에서 임대 갱신을 진행하세요.

구성이 안정되면 procd 자동 시작, 로그 용량, 설정 업데이트 절차를 정리하세요. 설정을 업데이트할 때마다 먼저 테스트하고 노드 이름과 정책 그룹 참조가 일치하는지 확인한 뒤 서비스를 다시 불러오세요. 방화벽과 라우팅을 변경했다면 단말 DNS, TCP, UDP, IPv6, LAN 접속도 다시 검증해야 합니다. 설정 항목은 설정 참고 문서에서, 기본 가져오기와 클라이언트 사용법은 설치 및 설정 가이드에서 확인할 수 있습니다.