프록시 규칙을 라우터 계층에 모아 처리하는 방식은 여러 기기의 트래픽 분기 문제를 해결하는 흔한 접근법입니다. 기기마다 클라이언트를 따로 설치하는 대신, 라우터에서 mihomo 커널을 직접 실행하면 LAN에 연결된 모든 기기(클라이언트를 설치할 수 없는 TV 박스, 스마트 스피커, 게임 콘솔 포함)가 동일한 분기 규칙을 그대로 따르게 됩니다. 설정을 한 곳에서 바꾸면 네트워크 전체에 적용됩니다. 이 글은 라우터에서 mihomo를 직접 실행하는 전체적인 사고 흐름을 정리하며, 특정 펌웨어의 화면별 클릭 절차는 다루지 않고 의사결정 지점과 흔히 놓치는 부분을 중심으로 설명합니다.
왜 라우터에서 mihomo를 실행하는가
스마트폰, 태블릿, PC에 각각 클라이언트를 설치하는 방식은 유연하지만 명확한 약점이 두 가지 있습니다. 첫째, 앱을 설치할 수 없는 기기(스마트 TV, 로봇 청소기, 일부 게임 콘솔)는 프록시 네트워크에 전혀 접속할 수 없고, 프록시 서버 주소를 수동으로 설정하는 방법에 기대야 하는데 많은 기기는 이 옵션조차 제공하지 않습니다. 둘째, 기기마다 별도의 설정을 유지하다 보니 규칙과 구독을 업데이트할 때마다 하나씩 동기화해야 하고, 버전이 어긋나면서 분기 결과가 달라지는 문제가 쉽게 생깁니다.
mihomo 커널을 라우터에 배포하면 이 두 문제가 함께 해결됩니다. LAN 내 모든 기기는 기본적으로 라우터를 거쳐 트래픽을 전달하므로, 라우터가 투명 프록시를 제대로 처리해두면 기기 쪽에서는 추가 설정 없이 규칙 분기를 그대로 누릴 수 있고, 설정 관리도 라우터 한 곳으로 집중됩니다. 이런 접근은 실무에서 흔히 "게이트웨이 프록시" 또는 "서브 라우터 프록시"라고 불리는데, 차이는 프록시가 네트워크 출구 역할을 맡는 메인 라우터에서 도는지, 아니면 메인 라우터와 병렬로 두고 정책 라우팅으로 트래픽을 넘겨받는 서브 라우터에서 도는지뿐입니다.
메인 라우터 직접 실행과 서브 라우터의 선택
메인 라우터 직접 실행은 mihomo를 지원하는 서드파티 펌웨어(흔히 OpenWrt 및 그 파생 버전)를 올린 라우터가 네트워크 출구 계층에서 곧바로 프록시 커널을 돌리는 방식으로, 모든 트래픽이 기본적으로 이를 거칩니다. 경로가 가장 짧고 별도 하드웨어가 필요 없지만, 라우터 자체의 펌웨어 호환성과 성능 요구가 더 높습니다. 설정에 문제가 생기면 집 전체 인터넷에 영향을 줄 수 있고 원인 파악도 번거로우므로, 실험적인 설정 변경 전에는 롤백 경로를 먼저 정해두는 편이 좋습니다.
서브 라우터 방식은 기존 라우터 네트워크에 소형 기기(라즈베리 파이, 미니 PC, 혹은 개조한 중고 라우터 등)를 추가로 연결해 프록시 커널만 돌리고, DHCP나 무선 같은 메인 라우터의 기본 기능은 맡지 않는 구성입니다. 메인 라우터는 정책 라우팅이나 DHCP 게이트웨이 지정을 통해 일부 트래픽을 서브 라우터로 넘겨 처리합니다. 이 방식의 장점은 메인 라우터의 안정적인 설정을 건드리지 않는다는 점으로, 문제가 생겨도 게이트웨이를 다시 메인 라우터로 돌리기만 하면 되어 위험이 통제 가능합니다. 단점은 경로가 한 단계 늘어 이론상 지연이 약간 늘어나고, 추가 기기와 정책 라우팅을 연동할 네트워크 지식이 필요하다는 점입니다.
대부분의 가정용 네트워크 환경에서는 서브 라우터가 비교적 안전한 출발점입니다. 먼저 소규모로 분기 규칙이 예상대로 동작하는지 확인하고, 안정성이 검증되면 메인 라우터 방식으로 전환할지 판단하면 됩니다. 이미 개조 가능한 고성능 라우터를 쓰고 있고 네트워크 문제를 스스로 해결할 자신이 있다면, 곧바로 메인 라우터에 배포하는 쪽이 경로가 더 단순합니다.
하드웨어와 펌웨어의 기본 요구사항
어느 방식을 택하든 하드웨어 측면에서 반드시 넘어야 할 몇 가지 기준이 있습니다.
- CPU 아키텍처와 성능: mihomo 커널은 CPU에 일정한 요구 수준이 있어, 규칙 수가 많고 동시 연결이 큰 환경에서는 저전력 단일 코어 기기에서 전달 지연이나 패킷 손실이 생기기 쉽습니다. 기기를 새로 구매하거나 재활용할 때는 멀티코어 ARM 또는 x86 플랫폼을 우선 고려하고, 성능이 지나치게 약한 구형 라우터에 고동시성 프록시 작업을 맡기지 않는 것이 좋습니다.
- 메모리 용량: 규칙 세트와 GeoIP/GeoSite 데이터베이스를 메모리에 올리면 일정 공간을 차지하므로, 메모리가 너무 작은(예: 128MB 이하) 기기는 규칙 수가 많아지면 커널이 비정상 종료되거나 응답이 느려질 수 있습니다. 사용 가능한 메모리를 최소 256MB 이상 확보하는 것을 권장합니다.
- 저장 공간: 펌웨어 자체, mihomo 바이너리, 규칙 데이터베이스, 로그 파일 모두 저장 공간을 필요로 하므로, 기기 내장 저장 공간이 너무 작다면 USB 드라이브를 연결하거나 저장 공간 확장을 지원하는 모델을 사용하는 것이 좋습니다.
- 펌웨어 지원: 가장 흔한 선택은 OpenWrt 및 그 파생 펌웨어(호환성이 좋은 커뮤니티 브랜치 포함)입니다. 이런 펌웨어는 생태계가 성숙해 있어 플러그인 저장소에서 패키징된 mihomo나 호환 컴포넌트를 대부분 찾을 수 있어 직접 컴파일하는 수고를 줄여줍니다. 순정 펌웨어는 대체로 프록시 커널을 직접 실행할 능력이 없어, 커스텀 소프트웨어 설치를 지원하는 서드파티 펌웨어로 먼저 교체해야 합니다.
펌웨어 교체 자체에 기기가 벽돌이 될 위험이 있으므로, 작업 전 펌웨어 버전과 기기 모델이 완전히 일치하는지 확인하고 순정 펌웨어와 주요 파티션 데이터를 미리 백업해 두시기 바랍니다.
커널 바이너리 선택
mihomo 커널은 CPU 아키텍처와 명령어 집합에 맞춘 바이너리 파일을 각각 배포하며, 흔히 볼 수 있는 아키텍처 표기로는 amd64, arm64, armv7 등이 있습니다. 아키텍처를 잘못 선택하면 프로그램이 실행되지 않거나 실행 즉시 충돌합니다. 아키텍처 일치 외에도 다음 두 가지를 함께 확인해야 합니다.
- 버전 안정성: 라우터 환경은 최신 버전을 따라가기보다 안정성이 더 중요하므로, 방금 출시된 최신 버전보다는 일정 기간 검증된 안정 버전을 선택해 네트워크 출구를 알려지지 않은 호환성 문제에 노출시키지 않는 편이 좋습니다.
- 기능 특성 대응: 선택한 버전이 사용할 계획인 기능(예: TUN 모드, 특정 규칙 문법, 특정 전송 프로토콜 구현)을 지원하는지 확인하세요. 배포 채널마다 패키징된 바이너리는 용량을 줄이기 위해 일부 기능을 제외하는 경우가 있으므로, 배포 전에 해당 버전의 릴리스 노트를 확인해 필요한 기능이 포함되어 있는지 점검하세요.
펌웨어 플러그인 저장소에 패키징된 mihomo 컴포넌트는 대체로 아키텍처 대응 문제가 이미 처리되어 있어, 수동 배포 절차에 익숙하지 않은 사용자에게는 더 편한 출발점입니다. 컴파일 옵션을 직접 지정하거나 플러그인 저장소에 아직 패키징되지 않은 신버전을 써야 할 때만 바이너리를 직접 내려받아 시작 스크립트를 구성하는 방식을 고려하면 됩니다.
투명 프록시와 DNS 하이재킹 요점
라우터 직접 실행의 핵심 가치는 "투명성"에 있습니다. LAN 기기는 프록시가 존재한다는 사실을 인지할 필요가 없고, 모든 트래픽이 게이트웨이 계층에서 자동으로 처리됩니다. 이를 구현하려면 두 가지 메커니즘이 함께 맞물려야 합니다.
트래픽 투명 전달
mihomo는 TUN 모드로 시스템 계층에 가상 네트워크 인터페이스를 만들어, 라우터를 거치는 트래픽을 이 가상 인터페이스로 리다이렉트한 뒤 커널이 규칙에 따라 분기 처리하도록 지원합니다. 이 방식은 프로토콜 호환성이 좋아 TCP와 UDP를 모두 다룰 수 있습니다. 일부 펌웨어 환경은 iptables/nftables 규칙 기반의 투명 프록시 방식도 지원하는데, 특정 포트 구간이나 전체 트래픽을 커널이 리스닝하는 로컬 포트로 리다이렉트하는 원리입니다. 두 방식 모두 각자 적합한 상황이 있는데, TUN 모드는 설정이 비교적 직관적이지만 커널 버전과 펌웨어 네트워크 스택 호환성 요구가 더 높고, iptables 방식은 호환 범위가 넓지만 규칙 작성이 복잡해 문제 해결 시 네트워크 리다이렉트 경로에 익숙해야 합니다.
DNS 하이재킹과 오염 회피
규칙 분기는 상당 부분 도메인 해석 결과를 근거로 판단하므로, 기기의 DNS 요청이 mihomo를 거치지 않고 통신사 DNS로 직접 나가면 오염되었거나 부정확한 해석 결과를 받을 수 있고, 이는 분기 정확도에 영향을 줍니다. 그래서 라우터 배포에서는 보통 DNS 하이재킹이라는 추가 단계가 필요합니다. LAN 내 모든 기기가 보내는 53번 포트 DNS 요청을 mihomo에 내장된 DNS 서버로 강제 리다이렉트해, 커널이 해석과 이후의 분기 결정을 일괄 처리하도록 만드는 것입니다.
이 단계가 완전하지 않을 때 가장 흔히 나타나는 증상은 "일부 앱은 프록시가 정상 작동하는데 일부 앱은 직접 원래 네트워크로 나간다"는 현상입니다. 이런 앱은 대체로 자체 DNS 해석 로직을 내장해 시스템 DNS 설정을 우회하고, 그 결과 하이재킹 규칙까지 함께 우회하게 됩니다. 이런 문제를 조사할 때는 먼저 라우터 계층의 DNS 리다이렉트 규칙이 모든 서브넷과 모든 포트 방향을 빠짐없이 커버하는지 확인하고, 그다음 해당 앱이 암호화 DNS(예: DoH)로 특정 서버에 직접 접속하고 있는지 점검하세요.
LAN 기기 접속의 두 가지 흔한 방식
mihomo를 돌리는 것은 첫 단계일 뿐이고, 더 중요한 것은 LAN 내 다른 기기들이 이 프록시 경로를 거치도록 "알게" 만드는 일입니다. 흔히 쓰는 두 가지 접속 방식은 각각 장단점이 있습니다.
| 방식 | 구현 방법 | 장점 | 한계 |
|---|---|---|---|
| 게이트웨이 직접 지정 | DHCP가 할당하는 기본 게이트웨이를 mihomo를 실행하는 기기로 직접 지정 | 설정이 간단하고, 새로 접속하는 기기에도 자동 적용되어 개별 설정이 필요 없음 | 해당 기기가 단일 장애 지점이 되어, 문제가 생기면 하위의 모든 기기가 함께 네트워크 연결에 영향을 받음 |
| 정책 라우팅 분기 | 메인 라우터가 소스 IP나 MAC 주소를 기준으로 지정된 기기의 트래픽을 서브 라우터로 전달 | 기기 단위로 프록시 여부를 세밀하게 제어할 수 있어 장애 영향 범위가 제한적 | 메인 라우터에서 정책 라우팅 규칙을 계속 관리해야 하고, 새 기기를 추가할 때마다 목록에 수동으로 등록해야 함 |
게이트웨이 직접 지정은 "집 전체를 프록시로 통일"하는 상황에 적합하며, 한 번 설정하면 새로 접속하는 모든 기기에 자동 적용되므로 가족 구성원의 기기가 많고 기기마다 설정하고 싶지 않은 경우에 잘 맞습니다. 정책 라우팅 분기는 "일부 기기는 프록시가 필요하고 일부 기기는 직접 연결을 유지"하는 상황에 적합합니다. 예를 들어 스마트 TV와 게임 콘솔만 프록시를 거치게 하고 나머지 업무용 기기는 기존 네트워크 경로를 유지해 불필요한 영향을 피하는 식입니다. 어느 쪽을 택할지는 "전면 통합"과 "세밀한 제어" 중 어느 쪽을 더 우선할지에 달려 있으며, 먼저 정책 라우팅으로 소규모 검증을 하고 안정성이 확인되면 게이트웨이 직접 지정으로 전환하는 방법도 있습니다.
배포 전 점검해 둘 몇 가지
작업을 시작하기 전 다음 사항들을 먼저 확인해 두면 이후 문제 해결 시간을 상당히 줄일 수 있습니다.
- 기기 아키텍처와 펌웨어 버전을 확인하고, 해당하는 mihomo 바이너리나 플러그인 패키지를 미리 내려받아 인터넷이 끊긴 상태에서 현장에서 자료를 찾는 상황을 피하세요.
- 구독 링크와 기본 규칙 세트를 준비한 뒤, 먼저 소규모(예: 자신의 기기 한 대)로 설정 파일 문법이 올바르고 규칙 적용이 예상대로 작동하는지 검증하고 나서 집 전체로 확대하세요.
- 로그 보관 위치를 미리 계획하세요. 라우터의 저장 공간은 제한적이므로 장기 운영 시 로그 순환이나 주기적인 정리를 해 두면 저장 공간이 가득 차서 기기가 이상 동작하는 상황을 막을 수 있습니다.
- 롤백 경로를 확인하세요. 배포 후 집 전체 인터넷이 끊겼을 때 게이트웨이를 빠르게 메인 라우터로 되돌릴 수 있는지, 또는 보조 네트워크(예: 휴대폰 테더링)로 임시로 라우터 관리 화면에 접속해 복구할 수 있는지 미리 확인해 두세요.
라우터 계층의 프록시 배포는 효과가 확실하지만, 문제가 생겼을 때 집 전체 네트워크에 영향을 준다는 점에서 시행착오 비용도 개별 기기 클라이언트보다 높습니다. 트래픽이 적은 시간대에 배포와 조정을 진행하고, 설정이 안정화된 뒤에 장기 방안으로 운영하며, 빠르게 복구할 수 있는 원래 네트워크 설정 백업본을 항상 남겨 두는 것을 권장합니다.