2026-08-22 고급 설정 예상 읽기 시간 12분

mihomo 보조 라우터 구성 가이드: OpenWrt 투명 프록시 설정

그래픽 클라이언트 없이 라우터나 보조 라우터에서 mihomo를 실행해 집 안의 모든 기기에 동일한 프록시 규칙을 적용하세요. 구성 방식, TProxy와 redir의 차이, 게이트웨이 설정을 정리했습니다.

1. 먼저 보조 라우터가 처리할 트래픽 범위를 정하세요

mihomo는 프록시 엔진이며 OpenWrt의 네트워크 설정 전체를 자동으로 구성하지는 않습니다. 구독은 노드와 규칙을 제공하고, 엔진은 아웃바운드를 선택합니다. 기기 트래픽이 엔진에 전달되는지는 기본 게이트웨이, 라우팅 테이블, 방화벽, DNS 경로가 함께 결정합니다. YAML 파일을 라우터에 올려 실행하는 것만으로는 LAN 기기가 투명 프록시에 연결되지 않습니다.

이 문서에서는 명확한 IPv4 구성 예시를 사용합니다. 메인 라우터는 192.168.10.1/24이며 인터넷 연결과 DHCP를 담당하고, 보조 라우터는 192.168.10.2/24이며 기본 게이트웨이는 메인 라우터로 설정합니다. 테스트 PC 주소는 192.168.10.100/24입니다. 이 주소는 설명을 위한 예시일 뿐이므로 실제 배포 전에 현재 네트워크 주소로 바꾸고 DHCP 주소 풀과 겹치지 않는지 확인하세요.

연결 방식	트래픽 유입 경로	적합한 상황
명시적 프록시	앱에서 보조 라우터의 7890 포트에 직접 연결	노드, 구독, 규칙을 먼저 확인할 때
단일 NIC 보조 라우터	기기의 기본 게이트웨이를 192.168.10.2로 변경	일부 기기부터 단계적으로 연결할 때
듀얼 NIC 하위 라우터	기기를 별도의 하위 네트워크에 연결	명확한 포워딩 경계가 필요할 때
메인 라우터에서 정책 기반 트래픽 전달	메인 라우터가 출발지 주소 또는 정책에 따라 전달	연결 기기를 중앙에서 관리할 때

2. OpenWrt 배포 전 확인 사항

시스템 아키텍처와 방화벽 백엔드 확인

SSH에서 시스템 버전, CPU 아키텍처, 사용 가능한 저장 공간을 확인하세요. OpenWrt 22.03부터 기본 방화벽은 firewall4와 nftables를 사용하지만, 업그레이드나 커스텀 펌웨어, 타사 플러그인에 따라 실제 환경이 다를 수 있습니다. 구형 iptables 규칙을 nftables 환경에 그대로 붙여 넣지 말고, 동일한 트래픽을 처리하는 투명 프록시 플러그인을 두 개 동시에 실행하지 마세요.

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

uname -m 출력은 아키텍처를 파악하는 데 참고할 수 있지만, mihomo 빌드는 기기의 CPU 기능에 맞춰 선택해야 합니다. 구형 기기 중에는 최신 명령어 집합을 지원하지 않는 경우도 있습니다. 실행 직후 종료되거나 잘못된 명령어 오류가 발생하면 구독 설정을 반복해서 바꾸기보다 먼저 바이너리 빌드가 맞는지 확인하세요.

엔진, 설정 파일, 서비스 관리 구분

실행 파일, 작업 디렉터리, 서비스 스크립트를 분리해 관리하는 것이 좋습니다. 예를 들어 엔진은 /usr/bin/mihomo, 설정 파일은 /etc/mihomo/config.yaml에 두고, 실행 상태는 OpenWrt의 procd 서비스로 관리할 수 있습니다. 아래 경로는 배포 시의 예시이며, 시스템에 관련 파일이 미리 설치되어 있다는 뜻은 아닙니다.

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

두 번째 명령은 설정 파일을 불러올 수 있는지 확인할 뿐, 전체 네트워크 연결을 테스트하지는 않습니다. 규칙 세트, GeoIP 또는 GeoSite 데이터를 사용하는 설정에는 해당 리소스도 필요합니다. 외부 리소스를 다운로드할 수 있는지, 디렉터리에 쓸 수 있는지, 최초 실행이 아직 설정되지 않은 프록시 연결에 의존하는지 확인하세요. SSH 세션이 끝나도 프로세스가 종료되지 않도록 서비스 스크립트에 시작 순서, 오류 시 재시작, 로그 출력을 설정해야 합니다.

3. 명시적 프록시로 구독과 규칙 확인

배포 순서는 “엔진 실행 → 명시적 프록시 확인 → DNS 확인 → 투명 프록시 적용”으로 진행하세요. 이렇게 하면 노드 문제와 라우팅 설정 오류를 구분하기 쉽습니다. 아래 구성은 연결 확인을 위한 기본 예시로 프록시 노드는 없고 마지막 규칙도 모두 직접 연결합니다. 구독을 대체하지 않으며 프록시 출구가 작동하는지 판단하는 데도 사용할 수 없습니다.

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

rules:
  - MATCH,DIRECT

예시를 실제 설정에 합칠 때는 같은 최상위 필드를 하나만 남겨야 합니다. LAN 수신을 활성화했다면 OpenWrt 방화벽에서 신뢰할 수 있는 LAN만 7890 포트에 접근하도록 허용하세요. WAN에 포트를 개방하거나 공인망 포트 포워딩을 설정하지 마세요. 수신 주소는 보조 라우터가 실제로 사용하는 주소여야 합니다.

먼저 테스트 PC에서 HTTP 프록시를 192.168.10.2:7890으로 설정해 요청이 엔진에 도달하는지 확인하세요.
유효한 Clash 형식 구독을 불러온 다음 프록시 그룹에 사용 가능한 노드가 포함되어 있는지 확인하고 원하는 노드를 선택하세요.
연결 기록에서 적용된 규칙과 아웃바운드를 확인하세요. 규칙 모드의 결과는 규칙 순서에 따라 달라지며 프록시 그룹 이름에 “자동”이라는 문구가 있는지와는 관계없습니다.
투명 프록시를 테스트하기 전에 PC의 명시적 프록시를 끄세요. 두 연결 방식이 겹치면 결과를 잘못 판단할 수 있습니다.

curl이 설치된 테스트 PC에서 curl -I --proxy http://192.168.10.2:7890 https://example.com을 실행할 수 있습니다. 이 명령은 HTTP 프록시 요청 경로를 확인합니다. 노드를 거쳐 나가는지 확인하려면 적용된 규칙, 아웃바운드 기록, 신뢰할 수 있는 IP 확인 결과도 함께 살펴보세요.

4. TProxy, redir, TUN의 차이

방식	주요 기능	필요한 시스템 설정
`redir-port`	리디렉션된 TCP 연결 수신	NAT 리디렉션, 주소 예외, 루프백 제외
`tproxy-port`	투명 프록시 TCP·UDP 트래픽 수신	TPROXY 규칙, 마크, 정책 라우팅
`tun`	가상 네트워크 인터페이스로 IP 트래픽 수신	TUN 지원, 라우트 제어, 방화벽 포워딩

redir는 주로 TCP를 처리합니다

redir-port: 7892를 설정하면 수신 포트가 만들어질 뿐입니다. 조건에 맞는 TCP 트래픽을 해당 포트로 보내도록 방화벽도 설정해야 합니다. 이 방식으로 UDP까지 동일하게 투명 프록시 처리할 수는 없습니다. 웹페이지는 열리지만 게임, 음성 통화, QUIC이 작동하지 않는다면 타임아웃을 늘리기보다 UDP가 실제로 어떤 경로를 거치는지 먼저 확인하세요.

TProxy에는 마크와 정책 라우팅이 필요합니다

tproxy-port: 7893는 TCP와 UDP의 투명 프록시 진입점으로 사용할 수 있지만, 필요한 커널 모듈과 방화벽 규칙, 라우팅 테이블이 모두 준비되어야 합니다. 시스템은 fwmark와 ip rule을 사용해 마크된 패킷을 로컬 수신 경로로 보냅니다. 마크 값과 라우팅 테이블 번호는 기존 VPN, 멀티 WAN, 다른 플러그인과 겹치지 않도록 정해야 합니다. 모든 기기에서 특정 숫자가 비어 있다고 가정하면 안 됩니다.

TUN은 스위치 하나만 켜면 되는 기능이 아닙니다

mihomo의 TUN은 auto-route 같은 필드로 라우트를 설정할 수 있지만, OpenWrt의 포워딩 정책, 인터페이스 인식, IPv6 라우팅은 별도로 확인해야 합니다. 최신 mihomo는 Linux에서 auto-redirect 관련 기능도 제공하며, 구체적인 동작은 설치된 엔진 버전의 문서를 기준으로 확인하세요. 여러 가이드에서 본 자동 리디렉션 기능과 직접 작성한 TProxy 규칙을 동시에 활성화하지 마세요.

5. 게이트웨이, 응답 경로, 방화벽 포워딩

단일 NIC 보조 라우터 구성에서는 테스트 PC의 기본 게이트웨이를 192.168.10.2로 지정하고, 보조 라우터 자체의 기본 경로는 계속 192.168.10.1을 향하도록 설정합니다. 메인 라우터와 보조 라우터의 기본 경로가 서로를 가리키게 하지 마세요. DHCP를 계속 메인 라우터가 제공한다면 먼저 PC에서 수동으로 변경해 검증한 뒤, DHCP 옵션 3으로 게이트웨이를, 옵션 6으로 DNS를 배포할 수 있습니다.

IP 포워딩: sysctl net.ipv4.ip_forward로 IPv4 포워딩 상태를 확인하세요. 정상적으로 포워딩하려면 값이 1이어야 합니다.
방화벽 영역: LuCI의 「네트워크」→「방화벽」→「일반 설정」에서 인터페이스가 속한 영역과 포워딩 규칙을 확인하세요. 메뉴 이름은 버전에 따라 달라질 수 있으므로 실제 영역과 인터페이스 연결을 기준으로 확인해야 합니다.
동일 서브넷의 응답 경로: 메인 라우터가 응답 패킷을 PC에 직접 전달해 비대칭 경로가 생길 수 있습니다. 이 경우 보조 라우터의 연결 추적, 필터링 규칙, 통계가 예상과 다르게 동작할 수 있습니다.
ICMP 리디렉션: 같은 인터페이스로 패킷을 주고받을 때 시스템이 기기에 더 직접적인 게이트웨이를 사용하라고 알릴 수 있습니다. 보조 라우터의 리디렉션 전송 동작과 기기가 리디렉션을 수락하는지 확인하세요.

일부 단일 NIC 구성에서는 직접 연결되는 트래픽의 응답이 다시 보조 라우터를 거치도록 제한적으로 소스 NAT를 사용합니다. 다만 상위 라우터에서 출발지가 보조 라우터 주소 하나로 통일되어 보일 수 있어 기기별 통계와 정책에 영향을 줍니다. 모든 영역에서 주소 위장을 켜는 것을 일반적인 해결책으로 삼지 마세요. 듀얼 NIC, 별도 하위 네트워크, 방화벽 정책에 따라 각각 다르게 설계해야 합니다.

6. DNS: 53과 1053의 역할을 먼저 구분하세요

OpenWrt는 보통 dnsmasq가 53 포트를 수신해 DHCP와 LAN 도메인 이름 조회를 처리합니다. 같은 주소의 53 포트를 mihomo도 수신하게 하면 충돌이 발생합니다. 점검하기 쉬운 구성은 기기가 보조 라우터의 53 포트에 질의하고, dnsmasq가 로컬 mihomo의 1053 포트로 전달한 뒤 mihomo가 상위 DNS 서버에 질의하는 방식입니다.

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://1.1.1.1/dns-query

이는 DNS 설정의 예시일 뿐입니다. 상위 DNS 주소는 현재 네트워크에서 연결 가능해야 하며, 해당 연결 경로는 실제 프록시 정책과 맞아야 합니다. LuCI의 「네트워크」→「DHCP/DNS」→「일반 설정」에서 DNS 전달 항목에 현재 버전이 지원하는 문법으로 127.0.0.1#1053을 설정할 수 있습니다. resolv 파일의 출처도 확인해 dnsmasq가 다시 자기 자신에게 요청을 보내지 않도록 하세요.

fake-ip가 반환하는 주소는 연결을 매핑하기 위한 주소이지 대상 웹사이트의 실제 주소가 아닙니다. 기기가 해당 주소로 연결을 시도했을 때 그 트래픽도 mihomo가 받아야 매핑이 의미가 있습니다. DNS는 보조 라우터를 사용하지만 게이트웨이는 메인 라우터를 가리키면 “DNS 조회는 되지만 모든 웹페이지 연결이 시간 초과되는” 현상이 나타날 수 있습니다.

LAN 호스트 이름 조회는 우선 dnsmasq가 처리하도록 두세요. 호환성 문제가 있을 때만 도메인별 fake-ip 제외나 도메인 조회 정책을 설정하세요.
53 포트 리디렉션은 규칙과 일치하는 일반 DNS만 처리할 수 있습니다. 브라우저에 내장된 DoH, 앱 자체의 암호화 DNS, 그 밖의 터널은 별도로 확인해야 합니다.
dns.ipv6: false만 설정해도 기기의 IPv6가 꺼지거나 IPv6 트래픽이 mihomo에 전달되는 것은 아닙니다. 기기는 메인 라우터가 광고한 IPv6 기본 경로를 통해 프록시를 거치지 않고 연결할 수 있습니다.

먼저 IPv4 설정을 검증한 뒤 IPv6의 RA, DNS 광고, 기본 경로, 프록시 경로를 별도로 계획하세요. IPv4와 IPv6를 모두 처리하려면 AAAA 조회와 실제 IPv6 연결을 함께 확인해야 합니다. IPv4 출구만 확인해서는 충분하지 않습니다.

7. 단계별 검증과 문제 해결

한 번에 한 항목만 변경하고 변경 전후 결과를 기록하세요. 다음 순서대로 점검하면 트래픽이 보조 라우터에 도달하지 않은 경우, 엔진에는 도달했지만 규칙이 잘못된 경우, 노드 자체에 문제가 있는 경우를 구분할 수 있습니다.

기본 네트워크: 테스트 PC에서 메인 라우터와 보조 라우터의 관리 주소에 접속할 수 있는지 확인합니다. 보조 라우터의 기본 경로와 시스템 시간이 올바른지도 확인하세요.
명시적 프록시: 7890 포트로 테스트 사이트에 접속한 다음 연결 기록, 프록시 그룹 선택, 아웃바운드 오류를 확인합니다.
DNS: nslookup example.com 192.168.10.2를 실행해 질의가 지정한 DNS 경로로 전달되는지 확인하세요. fake-ip를 사용하는 경우 매핑 결과도 확인합니다.
투명 프록시: 앱의 프록시 설정을 끈 뒤 새 연결을 시도해 mihomo에 연결이 표시되고 예상한 규칙이 적용되는지 확인합니다.
UDP와 IPv6: UDP가 필요한 앱과 IPv6 대상에 각각 연결해 보세요. TCP 연결에 성공했다고 해서 나머지 경로까지 정상이라는 뜻은 아닙니다.
재부팅 후 복구: 보조 라우터를 재부팅한 뒤 서비스 시작, DNS 작동, 방화벽 규칙 복구, 노드 도메인 조회를 확인합니다.

증상	우선 확인할 항목
명시적 프록시는 정상인데 투명 프록시 기록이 없음	기기의 게이트웨이, 포워딩 경로, 규칙 카운터, TUN 라우트
도메인은 조회되지만 연결이 계속 시간 초과됨	fake-ip 트래픽이 엔진에 전달되는지, 프록시 루프, 노드 연결 가능 여부
웹페이지는 정상인데 일부 실시간 앱이 작동하지 않음	UDP 진입 경로, 노드의 UDP 지원 여부, MTU, 방화벽
규칙 변경 후에도 기존 연결이 이전 출구를 사용함	테스트 연결을 종료한 다음 새로 연결해 기존 세션 재사용을 피하세요
재부팅 후 모든 기기에서 DNS 조회가 안 됨	dnsmasq 상위 DNS, mihomo 시작 순서, 리소스 다운로드 의존성

패킷 캡처가 필요하면 tcpdump가 설치된 기기에서 tcpdump -ni br-lan host 192.168.10.100을 실행해 테스트 PC의 트래픽을 확인할 수 있습니다. br-lan은 실제 LAN 인터페이스 이름으로 바꿔야 합니다. 로그에 구독 주소, 노드 인증 정보, 접속 도메인이 포함되어 있다면 공유 전에 민감한 정보를 삭제하세요.

8. 설정 유지 관리와 되돌리기

구독 업데이트, 엔진 업그레이드, 방화벽 변경은 따로 진행하세요. 기기별 DNS, 수신 주소, 진입 포트, 라우팅 정책은 로컬 관리 영역에 보관해 원격 구독 업데이트가 보조 라우터 설정을 덮어쓰지 않도록 합니다. 오버라이드나 설정 병합 기능을 사용하는 경우 원본 구독뿐 아니라 최종 생성된 YAML도 확인하세요.

업그레이드 전에 현재 엔진 버전, 적용 중인 설정, 서비스 스크립트, 방화벽 규칙을 저장하세요. 설정을 테스트한 뒤 서비스를 재시작하도록 일정을 잡습니다.
메인 라우터 DHCP의 게이트웨이와 DNS를 변경할 때 기존 값을 기록해 두세요. 되돌릴 때는 두 항목을 함께 복구해야 게이트웨이를 원래대로 설정한 뒤 중지된 DNS에 의존하는 상황을 피할 수 있습니다.
제어 인터페이스는 필요한 관리 주소에서만 접근할 수 있도록 제한하고 인증 정보를 설정하세요. 구독 파일은 민감한 설정으로 취급하고 공개 저장소에 올리지 마세요.
장애 발생 시 우회 방법을 미리 설계하세요. 보조 라우터가 꺼진 상태에서 기기가 계속 보조 라우터를 게이트웨이로 사용하면 메인 라우터가 해당 게이트웨이 주소를 자동으로 대신할 수 없습니다.

보조 라우터 구성의 핵심은 트래픽 유입, DNS 조회, 아웃바운드의 세 경로를 일치시키는 것입니다. 먼저 기기 한 대에서 명시적 프록시를 검증하고, 투명 프록시 방식 하나를 선택한 뒤 DHCP 적용 범위를 넓히세요. 규칙 모드, 구독 가져오기, 클라이언트 사용법은 Clash 사용 가이드에서 확인할 수 있으며, 필드 설명은 전체 문서를 참고하세요.