OpenWrt 보조 라우터에서 mihomo 실행하기: 배포 방식 한눈에 보기

먼저 수동 프록시로 확인한 뒤 게이트웨이 트래픽을 처리하세요

OpenWrt에서 mihomo를 직접 실행한다는 것은 시스템이 커널 프로세스를 시작하고 YAML 설정을 읽은 뒤, 필요에 따라 라우팅과 방화벽에 연결한다는 뜻입니다. 일반적으로 Clash Meta 커널이라고 부르는 것이 mihomo입니다. LuCI 플러그인이 아니며, 라우터에 파일을 복사한다고 해서 집 안의 모든 트래픽을 자동으로 처리하지도 않습니다. 그래픽 인터페이스, 구독 업데이트, 투명 프록시 규칙, 부팅 시 자동 실행은 각각 따로 설정해야 합니다.

초보자라면 세 단계로 진행하는 것이 좋습니다. 먼저 커널이 설정 파일 검사를 통과하는지 확인하고, 다음으로 컴퓨터 한 대에서 보조 라우터의 명시적 프록시를 사용해 봅니다. 마지막으로 해당 컴퓨터의 기본 게이트웨이와 DNS를 변경하세요. 각 단계마다 확인할 항목이 명확하고, 문제가 생겨도 직전 단계로 빠르게 되돌릴 수 있습니다.

브라우저에만 프록시를 적용하려면 첫 번째 방식으로 충분합니다. TV, 게임 기기 또는 수동 프록시를 지원하지 않는 앱까지 연결하려는 경우에만 나머지 두 방식을 살펴보세요. OpenWrt 관리 플러그인이 설치된 기기라면 먼저 플러그인이 이미 mihomo를 실행하고 있는지 확인해야 합니다. 관리 경로 두 곳에서 같은 포트와 라우팅을 동시에 제어하는 상황을 피할 수 있습니다.

주 라우터와 보조 라우터: 먼저 트래픽 흐름부터 정리하기

이 글에서는 IPv4 LAN 환경의 구체적인 예를 들어 각 장치의 역할을 설명합니다. 주 라우터는 인터넷 연결, 외부 회선 접속, DHCP를 담당합니다. 보조 라우터에는 고정 IP를 설정하고, 지정한 테스트 기기 한 대의 트래픽만 우선 통과시킵니다. 아래 주소는 설명을 위한 예시이므로 실제 설정 전에 기존 네트워크 대역과 IP 사용 여부를 확인하세요.

• 주 라우터: 192.168.10.1/24, 인터넷에 연결됩니다.
• OpenWrt 보조 라우터: 192.168.10.2/24, 상위 게이트웨이는 192.168.10.1입니다.
• 테스트 컴퓨터: 192.168.10.100/24, 처음에는 주 라우터를 게이트웨이로 사용합니다.
• DHCP 주소 풀 예시: 192.168.10.100–192.168.10.200. 보조 라우터의 IP는 동적 주소 풀에서 제외합니다.

보조 라우터 IP는 고정하고 DHCP는 한 곳에서만 제공하기

표준 LuCI 화면에서 「네트워크」→「인터페이스」→「LAN」→「편집」으로 이동해 고정 IPv4 주소와 상위 게이트웨이를 확인하세요. 테마에 따라 메뉴 이름은 조금 다를 수 있습니다. 보조 라우터 LAN 인터페이스의 「DHCP 서버」에서는 보통 「이 인터페이스 무시」를 선택해 주 라우터와 동시에 IP를 할당하지 않도록 합니다. 관리 IP를 변경하기 전에는 유선 연결을 유지하고 새 주소를 기록해 두세요.

같은 네트워크 대역을 사용하는 단일 인터페이스 보조 라우터에서는 송수신 트래픽이 모두 같은 LAN 인터페이스를 통과할 수 있습니다. LAN과 WAN이 분리된 듀얼 포트 라우터와는 다르며, 응답 경로도 비대칭일 수 있습니다. 소스 주소 변환이 필요한지, ICMP 리디렉션을 어떻게 처리할지는 기존 방화벽과 투명 프록시 구성에 따라 판단해야 합니다. 다른 장치용 방화벽 명령 몇 줄을 그대로 복사해 붙여 넣으면 안 됩니다.

보조 라우터의 상위 게이트웨이는 항상 주 라우터를 가리켜야 하며, 자기 자신을 게이트웨이로 지정하면 안 됩니다. 실제 전환 전까지 주 라우터의 DHCP 설정은 그대로 두고 테스트 단말 한 대만 변경하세요.

커널과 디렉터리: 아키텍처, 권한, 설정 경로 맞추기

먼저 SSH로 하드웨어와 펌웨어를 확인하세요. uname -m으로 커널 아키텍처를, ubus call system board로 보드와 시스템 정보를, df -h로 저장 공간을 확인합니다. mihomo 릴리스 파일을 고를 때는 CPU 명령어 집합 요구 사항도 확인해야 합니다. 같은 x86_64 기기라도 더 높은 명령어 집합을 요구하는 빌드를 모두 실행할 수 있는 것은 아닙니다.

uname -m
ubus call system board
df -h
free -m
ls -l /dev/net/tun

/dev/net/tun이 없어도 명시적 프록시는 먼저 테스트할 수 있습니다. TUN을 활성화하기 전에 필요한 커널 모듈을 준비하세요. OpenWrt 커널 모듈은 펌웨어의 커널 버전과 일치해야 하므로 다른 버전의 모듈을 억지로 설치하지 마세요. 패키지 관리자는 펌웨어에 따라 opkg 또는 apk를 사용합니다.

세 경로를 고정해 두세요

• /usr/bin/mihomo: 압축을 푼 커널 실행 파일입니다. 압축 파일을 지정하는 경로가 아닙니다.
• /etc/mihomo/config.yaml: 실제로 사용하는 설정 파일입니다.
• /etc/mihomo/: 규칙, 데이터베이스, 실행 데이터를 참조할 때 사용하는 작업 디렉터리입니다.

기기에 맞는 아키텍처의 커널을 지정된 경로에 업로드한 다음 실행 권한을 설정하고 버전을 확인하세요. 설정 파일에 구독 URL, 노드 비밀번호, 토큰이 포함될 수 있으므로 읽기 권한을 제한하고 공개된 게시판에 그대로 올리지 마세요.

mkdir -p /etc/mihomo
chmod 755 /usr/bin/mihomo
/usr/bin/mihomo -v
chmod 600 /etc/mihomo/config.yaml
/usr/bin/mihomo -t -d /etc/mihomo -f /etc/mihomo/config.yaml

마지막 명령은 설정 파일을 검사합니다. 필드 오류가 표시되면 로그를 참고해 YAML 들여쓰기나 호환되지 않는 옵션을 먼저 수정하세요. 규칙 파일이나 지리 데이터베이스가 없다는 오류가 나오면 해당 파일 경로와 다운로드 연결 상태를 확인합니다. 설정 검사를 통과했다는 것은 파일을 읽을 수 있다는 뜻일 뿐, 노드 연결, DNS, 투명 프록시가 정상이라는 의미는 아닙니다.

먼저 7890 포트를 열고 명시적 프록시와 구독 설정을 확인하세요

아래는 리스닝과 직접 연결 경로를 확인하기 위한 최소 설정입니다. 프록시 노드가 없어 모든 연결을 DIRECT로 처리하므로 구독 노드의 사용 가능 여부를 판단할 수는 없습니다. 우선 이 설정으로 배포 자체를 점검한 다음, mihomo 지원이 확인된 전체 구독 설정으로 바꾸세요.

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

rules:
  - MATCH,DIRECT

mixed-port는 같은 포트에서 HTTP와 SOCKS5 프록시 연결을 받습니다. allow-lan을 사용하면 다른 기기에서도 접속할 수 있습니다. 리스닝 주소는 보조 라우터가 실제로 사용하는 주소여야 합니다. 방화벽에서 신뢰할 수 있는 LAN에 한해 TCP 7890을 허용하고, 주 라우터에서 이 포트의 인터넷 포트 포워딩을 설정하지 마세요.

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

오류를 살펴보기 쉽도록 포그라운드에서 실행하세요. SSH 세션을 그대로 둔 채 테스트 컴퓨터에서 아래 요청을 실행합니다. curl이 없다면 운영체제나 브라우저의 프록시 설정에 HTTP 프록시 주소 192.168.10.2와 포트 7890을 입력하세요.

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

대상 사이트의 HTTP 응답 헤더가 보이면 컴퓨터에서 보조 라우터의 프록시에 연결할 수 있고 커널이 외부 연결도 만들 수 있다는 뜻입니다. 다음으로 실제 설정을 불러온 뒤 프록시 그룹에서 참조하는 이름과 규칙의 대상이 일치하는지 확인하고, 대상 연결에 어떤 정책이 적용되는지 테스트하세요. 구독 링크가 들어 있는 텍스트 파일을 다운로드했다고 해서 곧바로 실행 가능한 YAML 설정을 얻은 것은 아닙니다.

관리 API와 프록시 포트는 서로 다른 접속 경로입니다. 이 단계에서는 external-controller를 열 필요가 없습니다. 나중에 대시보드를 연결한다면 secret을 설정하고 관리 포트에 접근할 수 있는 범위를 제한하세요.

투명 프록시: 게이트웨이, TUN, DNS를 함께 점검하기

명시적 프록시 연결에 성공하면 테스트 컴퓨터의 수동 프록시 설정을 해제하고 기본 게이트웨이를 192.168.10.2로 변경하세요. 이제 패킷이 보조 라우터를 통과할 뿐입니다. TUN 라우팅이나 방화벽 전달 규칙이 없으면 트래픽이 mihomo로 자동 전달되지는 않습니다. 게이트웨이를 바꿨다는 사실만으로 투명 프록시가 성공했다고 판단할 수 없습니다.

TUN 방식의 적용 범위와 한계

mihomo의 tun.enable은 가상 네트워크 장치를 활성화하고, auto-route는 관련 경로를 자동으로 설정하며, auto-detect-interface는 외부 연결에 사용할 인터페이스를 자동으로 찾습니다. 이 옵션만으로 OpenWrt의 모든 방화벽 설정을 대체할 수는 없습니다. 특히 LAN 인터페이스 하나로 트래픽이 들어오고 나가는 보조 라우터 환경에서는 전달 허용, 커널의 트래픽 경로, 예외 대상, 응답 경로를 함께 확인해야 합니다.

다른 방법으로는 redir-port 또는 tproxy-port를 방화벽과 함께 사용할 수 있습니다. REDIRECT는 주로 TCP 리디렉션에 쓰이고, TPROXY는 TCP와 UDP에 사용할 수 있지만 정책 라우팅이 필요합니다. 최신 OpenWrt에서는 firewall4와 nftables를 사용하는 경우가 많고, 오래된 가이드는 firewall3와 iptables를 기준으로 작성됐을 수 있습니다. 두 방식의 규칙을 구분 없이 섞어 쓰면 안 됩니다. 또한 두 방식이 같은 연결을 동시에 가로채게 설정하지 마세요.

DNS 리스닝 설정과 DHCP 배포 설정 맞추기

흔히 dnsmasq가 LAN의 53번 포트에서 DNS 요청을 받고, mihomo DNS는 로컬 127.0.0.1:1053에서 요청을 받은 뒤 dnsmasq가 이 주소로 질의를 전달하도록 구성합니다. 1053은 내부 전달용 포트이므로 휴대폰에 입력하는 DNS 주소가 아닙니다. 일반 단말의 DNS 설정에서는 사용자 지정 포트를 지정할 수 없는 경우가 많습니다.

• 단말의 DNS를 보조 라우터로 지정한다면 보조 라우터의 53번 포트가 실제로 DNS 요청에 응답하는지 확인하세요.
• dnsmasq가 mihomo로 요청을 전달한다면 mihomo의 상위 DNS 서버를 같은 dnsmasq 경로로 되돌려 지정하지 마세요. DNS 조회 루프가 발생합니다.
• fake-ip를 사용한다면 DNS 응답과 그 뒤에 이어지는 연결이 같은 트래픽 처리 경로를 거쳐야 합니다. 가상 IP만 할당되고 연결은 커널에 전달되지 않는 상황을 피하세요.
• 브라우저의 보안 DNS, 앱 내 DoH, 고정 DNS 설정은 시스템의 DNS 설정을 우회할 수 있으므로 각각 확인해야 합니다.

IPv6도 별도로 설정해야 합니다. 주 라우터가 RA로 배포하는 IPv6 기본 경로는 IPv4 게이트웨이를 수동으로 변경해도 사라지지 않습니다. 설정의 ipv6: false만으로 LAN 전체의 IPv6를 끌 수는 없습니다. 테스트 중에는 범위를 좁히기 위해 테스트 단말에서 IPv6를 잠시 끌 수 있습니다. 실제 배포에서는 IPv6 라우팅, DNS, 트래픽 처리 방식을 명확히 정하세요.

부팅 시 실행: 백그라운드 명령 대신 procd로 프로세스 관리하기

포그라운드 테스트를 마치면 Ctrl+C로 테스트 프로세스를 중지한 다음 시스템 서비스를 설정하세요. OpenWrt는 procd로 서비스를 관리합니다. SSH에서 명령 끝에 &를 붙이는 것만으로는 부팅 시 자동 실행이나 프로세스 감시를 대신할 수 없습니다. 아래 최소 서비스는 커널을 실행하는 역할만 하며 방화벽 규칙 생성이나 구독 자동 업데이트는 처리하지 않습니다.

아래 내용을 /etc/init.d/mihomo에 저장하세요. 같은 이름의 서비스가 이미 있거나 플러그인이 커널을 관리하고 있다면 먼저 관리 주체를 확인하고 기존 파일을 덮어쓰지 마세요.

#!/bin/sh /etc/rc.common

START=99
STOP=10
USE_PROCD=1

start_service() {
    procd_open_instance
    procd_set_param command /usr/bin/mihomo \
        -d /etc/mihomo \
        -f /etc/mihomo/config.yaml
    procd_set_param respawn
    procd_set_param stdout 1
    procd_set_param stderr 1
    procd_set_param file /etc/mihomo/config.yaml
    procd_close_instance
}

chmod 755 /etc/init.d/mihomo
/etc/init.d/mihomo enable
/etc/init.d/mihomo start
logread -e mihomo

구독을 업데이트하기 전에 이전에 정상 작동하던 설정을 보관하세요. 새 내용을 임시 파일에 저장하고 mihomo -t로 검사한 다음 정식 설정 파일로 교체하고 서비스를 재시작합니다. 설정 문법이 맞더라도 노드를 사용할 수 없다면 이전 설정으로 되돌려야 합니다. 자동 업데이트가 사람이 수정한 설정을 반복해서 덮어쓰지 않도록 하세요. 규칙 세트, 데이터베이스 다운로드, 캐시도 플래시 저장 공간을 차지하므로 남은 용량을 주기적으로 확인하세요.

작동 확인과 롤백: 한 대부터 테스트한 뒤 범위 넓히기

배포가 끝나면 아래 순서대로 확인하세요. 대시보드의 연결 상태만 보지 말고, 한 항목을 통과한 뒤 다음 항목으로 넘어가세요. 그러면 막연한 네트워크 장애를 원인을 찾을 수 있는 구체적인 단계로 좁힐 수 있습니다.

1. 라우터의 외부 연결: 보조 라우터에서 주 라우터에 접속할 수 있고, 도메인 이름을 조회해 HTTPS 연결을 설정할 수 있는지 확인합니다.
2. 프록시 연결: 테스트 컴퓨터에서 192.168.10.2:7890을 통해 요청을 보낼 때 로그에 해당 연결이 표시되는지 확인합니다.
3. DNS 응답: nslookup example.com 192.168.10.2를 실행하고 응답 서버가 예상한 서버인지 확인합니다.
4. 투명 프록시 처리: 명시적 프록시를 끈 뒤 대상 사이트에 접속해도 mihomo에 연결 기록이 남고 예상한 규칙이 적용되는지 확인합니다.
5. LAN 예외 처리: 주 라우터 관리 페이지, 프린터, NAS, 로컬 서비스 트래픽이 실수로 원격 프록시로 전달되지 않는지 확인합니다.
6. 재부팅 후 복구: 보조 라우터를 재부팅한 뒤 서비스를 다시 테스트해 서비스, DNS, 트래픽 전달 경로가 모두 복구되는지 확인합니다. 이전에 수동으로 실행한 명령에 의존해서는 안 됩니다.

기기 전체에서 인터넷이 끊기면 먼저 테스트 컴퓨터의 게이트웨이와 DNS를 원래 주 라우터 설정으로 되돌리고 수동 프록시를 해제하세요. 그다음 mihomo를 중지합니다. nftables, 정책 라우팅, DNS 전달을 직접 추가했다면 해당 변경 사항도 별도로 취소해야 합니다. 커널 프로세스를 중지해도 외부에서 추가한 트래픽 처리 규칙까지 자동으로 지워지지는 않습니다.

한 대의 기기에서 안정적으로 작동하는 것을 확인한 뒤에만 DHCP로 보조 라우터의 게이트웨이와 DNS를 배포하세요. DHCP 게이트웨이는 보통 옵션 3, DNS는 옵션 6에 해당합니다. 설정을 배포한 뒤 단말에서 DHCP 임대 갱신이 필요할 수 있습니다. 보조 라우터가 전체 네트워크의 필수 경로가 되면 전원을 끄거나 업그레이드할 때 단말도 영향을 받습니다. 주 라우터 관리 방법과 명확한 복구 절차를 마련해 두세요.

이 배포 방식의 핵심은 모든 옵션을 한 번에 설정하는 것이 아니라 커널, 명시적 프록시, DNS, 트래픽 전달을 각각 확인하는 것입니다. 규칙과 구독 설정부터 익히려면 구독 가져오기 가이드를 참고하세요. 설정 항목을 확인할 때는 전체 설정 가이드를 살펴보고, 여러 계층의 설정을 한꺼번에 바꾸지 마세요.