Mihomo를 홈 라우터나 바이패스 라우터에서 실행하는 핵심 목적은 각 기기에 데스크톱 클라이언트를 따로 설치하는 것이 아닙니다. 프록시 기능을 LAN 출구 가까이에 배치해 네트워크 장비가 조건에 맞는 연결을 일괄 처리하도록 하는 방식입니다. 따라서 Clash 클라이언트를 설치하기 어려운 TV, 게임 콘솔, 스마트 스피커, 홈 서버도 적용할 수 있지만, 설정·전달·DNS·장애 분석이 하나의 네트워크 노드에 집중됩니다.
실제 논의에서 ‘라우터 배포’는 전혀 다른 두 가지 구성을 가리킬 수 있습니다. 하나는 가정용 게이트웨이 역할을 하는 메인 라우터 시스템에서 Mihomo를 직접 실행하는 방식이고, 다른 하나는 별도 장비를 바이패스 라우터로 추가해 메인 라우터와 병렬로 운영하는 방식입니다. 이후 게이트웨이, 정책 라우팅 또는 수동 설정을 통해 일부 클라이언트의 트래픽을 바이패스 라우터로 보냅니다. 두 구성 모두 투명 프록시를 구현할 수 있지만, 패킷 경로와 전원 장애의 영향 범위, 유지관리 방식은 서로 다릅니다.
먼저 배포 모델을 정하세요: 메인 라우터에서 커널을 직접 실행할지, 바이패스 라우터로 트래픽을 분리할지
메인 라우터에서 커널 직접 실행
메인 라우터에서 커널을 직접 실행한다는 것은 현재 LAN의 기본 게이트웨이 장비에서 Mihomo를 실행하는 것을 뜻합니다. 단말은 DHCP를 통해 메인 라우터의 IP 주소를 기본 게이트웨이로 받으며, 외부 네트워크에 접속할 때 패킷은 자연스럽게 먼저 이 장비에 도착합니다. 라우팅 시스템은 전달 단계에서 트래픽을 Mihomo의 투명 프록시 진입점으로 넘기고, Mihomo는 규칙 모드·정책 그룹·프록시 노드에 따라 이후 경로를 결정합니다.
이 구성의 장점은 토폴로지가 단순하다는 점입니다. 기본 게이트웨이, LAN DHCP, DNS 전달과 프록시 프로그램이 한 장비에 모이고 규칙 적용 범위도 자연스럽습니다. 반면 메인 라우터의 담당 업무가 많아져 커널이 CPU·메모리·연결 테이블 자원을 사용합니다. 설정 업데이트 실패, 라우팅 시스템 재시작 또는 Mihomo 프로세스 이상이 발생하면 전체 홈 네트워크에 영향을 줄 수 있습니다. 하드웨어 성능이 제한적이거나 제조사 펌웨어가 폐쇄적이고, 라우팅 시스템의 시작 항목에 익숙하지 않다면 메인 라우터를 변경하기 전에 원상 복구가 가능한지 먼저 확인해야 합니다.
바이패스 라우터에서 독립 실행
바이패스 라우터는 보통 LAN에 추가하는 두 번째 장비로, Linux·OpenWrt 또는 다른 라우팅 시스템을 실행하는 소형 컴퓨터가 예입니다. 메인 라우터는 계속 인터넷 연결, 무선 접속과 DHCP를 담당하고, 바이패스 라우터는 Mihomo와 관련 투명 프록시 구성 요소만 실행합니다. 단말에서 이를 사용하는 일반적인 방법은 세 가지입니다. 바이패스 라우터를 기본 게이트웨이로 지정하거나, DNS만 바이패스 라우터로 지정하면서 투명 전달을 함께 사용하거나, 지정한 기기에만 게이트웨이와 프록시 진입점을 수동 설정하는 방식입니다.
바이패스 라우터의 장점은 위험을 분리할 수 있다는 데 있습니다. 메인 라우터의 기존 설정을 유지할 수 있으므로 바이패스 라우터가 중지되어도 이를 거치지 않는 기기는 메인 라우터를 통해 계속 인터넷에 접속할 수 있습니다. 먼저 한 대의 컴퓨터에 적용한 뒤 TV·홈 서버·게스트 네트워크로 범위를 넓히는 단계적 테스트도 편리합니다. 다만 바이패스 라우터가 모든 트래픽을 자동으로 가로채는 것은 아닙니다. 단말의 기본 게이트웨이가 여전히 메인 라우터이고 메인 라우터가 관련 트래픽을 바이패스 라우터로 전달하지 않는다면 Mihomo는 해당 연결을 볼 수 없습니다.
투명 프록시 이해하기: 트래픽 전환이 모든 연결의 자동 프록시를 뜻하지는 않습니다
데스크톱 클라이언트에서 흔히 사용하는 시스템 프록시는 HTTP·HTTPS 또는 SOCKS 프록시 주소를 운영체제나 애플리케이션 설정에 입력하는 방식입니다. 애플리케이션이 해당 설정을 따를 때 연결은 지정된 포트로 전송되지만, 시스템 프록시를 지원하지 않는 프로그램은 이를 완전히 우회할 수 있습니다. 라우터의 투명 프록시는 처리 방식이 다릅니다. 일반적으로 전달 경로에서 연결을 확인하고 방화벽 리디렉션·정책 라우팅 또는 TUN 등의 메커니즘으로 원래 직접 전달되던 트래픽을 프록시 커널에 넘깁니다.
기존 투명 프록시 방식은 대개 시스템 네트워크 스택과 방화벽 규칙에 의존합니다. 예를 들어 TCP 트래픽이 라우터의 전달 체인을 지날 때 로컬 투명 프록시 포트로 리디렉션되고, Mihomo는 원래 목적지 주소를 기준으로 규칙을 매칭합니다. UDP·ICMP·IPv6·로컬에서 시작한 트래픽은 별도 처리가 필요할 수 있으므로 TCP 웹 페이지가 열린다고 해서 모든 프로토콜이 이미 전환되었다고 판단해서는 안 됩니다.
TUN 모드는 가상 네트워크 인터페이스를 통해 시스템 라우팅을 거친 IP 패킷을 수신하고, 커널에서 TCP·UDP 등의 연결을 처리한 뒤 설정의 DNS 및 라우팅 규칙과 함께 후속 전달을 수행합니다. 포트 리디렉션을 항목별로 설정하지 않고 더 많은 애플리케이션 프로토콜을 적용해야 하는 환경에 적합하지만, 시스템 권한·라우팅 테이블·DNS 처리·IPv6 설정에 더 민감합니다. 라우터 환경에서 TUN 사용 가능 여부는 시스템 커널 기능, 가상 장치 권한 및 해당 Mihomo 버전의 지원 여부에 따라 달라집니다.
연결은 실제로 어떤 경로를 거칠까
- LAN 단말은 도메인을 조회하고 로컬 라우팅 테이블에 따라 기본 게이트웨이 또는 DNS 서버를 결정합니다.
- 패킷이 메인 라우터 또는 바이패스 라우터에 도착합니다. 바이패스 라우터가 기본 게이트웨이가 아니라면 트래픽이 이를 거치도록 별도의 전달 규칙이 필요합니다.
- 투명 프록시 진입점이 연결을 수신합니다. 진입점은 리디렉션 포트, TProxy 포트 또는 TUN 가상 네트워크 인터페이스일 수 있으며, 구체적인 명칭은 시스템과 설정에 따라 달라집니다.
- Mihomo가 목적지를 해석하고 DNS 처리를 수행한 뒤 규칙 순서에 따라 직접 연결, 프록시 또는 특정 정책 그룹을 선택합니다.
- 연결은 직접 연결 출구 또는 프록시 노드에서 나가며, 응답 데이터는 도달 가능한 반환 경로를 따라 단말로 돌아옵니다.
어느 한 단계라도 빠지면 ‘일부 웹사이트가 열리지 않는’ 현상이 나타날 수 있습니다. 예를 들어 정책 규칙은 프록시를 선택했지만 바이패스 라우터가 노드에 접속하지 못할 수 있습니다. 노드는 정상이어도 단말이 DNS를 계속 메인 라우터로 보내 잘못된 주소를 받을 수 있습니다. 문제를 분석할 때는 먼저 연결이 Mihomo에 도착했는지 확인하고, 다음으로 어떤 규칙이 매칭되었는지, 마지막으로 프록시 노드와 원격 네트워크를 확인하세요.
라우터에서 Mihomo가 실행되는 구성: 설정·포트·규칙
Mihomo는 설정을 해석하고 규칙을 매칭하며 프록시 연결을 수립하는 커널 구현입니다. 라우터에 배포할 때는 최소한 세 가지를 구분해야 합니다. 커널 실행 매개변수, 프록시 설정 파일, 시스템 네트워크 전환 규칙입니다. 설정 파일에는 일반적으로 프록시 노드·정책 그룹·규칙 세트·DNS·모드·수신 포트가 포함되고, 시스템 계층은 단말 트래픽을 올바른 진입점으로 보냅니다. 한 계층만 수정하고 다른 계층을 동기화하지 않으면 완전한 결과를 얻기 어렵습니다.
설정의 모드는 일반적으로 규칙·전체·직접 연결로 구성됩니다. 홈 네트워크를 장기간 운영할 때는 도메인·IP·규칙 세트에 따라 트래픽을 분리하는 규칙 모드가 적합합니다. 전체 모드는 프록시 경로가 작동하는지 확인할 때 사용할 수 있고, 직접 연결 모드는 문제가 프록시 노드나 규칙 선택에서 비롯되는지 판단할 때 유용합니다. 모드 전환은 Mihomo의 연결 처리 전략만 바꿀 뿐, 잘못된 기본 게이트웨이·접속할 수 없는 DNS·수신 포트 오류를 해결하지는 않습니다.
수신 포트도 트래픽 유형에 맞춰야 합니다. HTTP 및 SOCKS 포트는 주로 명시적 프록시 클라이언트를 위한 것이고, 투명 프록시 포트는 시스템 전달 경로에서 사용됩니다. DNS 수신 포트는 도메인 조회 요청을 처리합니다. 일반 HTTP 프록시 포트를 투명 프록시 진입점으로 사용하거나, 포트 점유 여부를 확인하지 않은 채 여러 서비스를 중복 실행하지 마세요. 라우터 시스템에서는 수신 주소도 확인해야 합니다. 루프백 주소에서만 수신하면 LAN 단말이 직접 접근할 수 없고, LAN 주소에서 수신한다면 접근 제어를 함께 설정해야 합니다.
mixed-port: 7890
mode: rule
allow-lan: true
external-controller: 127.0.0.1:9090
dns:
enable: true
listen: 0.0.0.0:1053위 예시는 설정 항목 간의 관계를 설명하기 위한 것이며 모든 라우팅 시스템에 그대로 적용할 수 있는 것은 아닙니다. allow-lan은 LAN에서 명시적 프록시 포트에 접근하도록 허용하지만, 투명 프록시는 여전히 시스템 측에서 전달 설정을 완료해야 합니다. DNS 수신 포트도 라우터의 DNS 전달 설정과 일치해야 합니다. 또한 제어판 포트는 로컬 또는 신뢰할 수 있는 관리 네트워크로 제한해 불필요한 네트워크에 관리 인터페이스가 노출되지 않도록 하세요.
유지관리 범위: 구독 업데이트·DNS·IPv6·복구 경로
구독 업데이트는 별도로 판단해야 합니다
구독 업데이트는 대개 프록시 노드·정책 그룹 또는 규칙 관련 내용을 교체하지만, 사용 중인 라우팅 토폴로지를 자동으로 파악하지는 않습니다. 업데이트된 설정에 기존에 의존하던 정책 그룹 이름이 없으면 규칙이 존재하지 않는 대상을 가리킬 수 있습니다. 구독이 노드만 제공하고 완전한 DNS·TUN·라우팅 설정을 포함하지 않는다면 투명 프록시 기능은 로컬 설정으로 보완해야 합니다. 업데이트 전에 현재 작동하는 설정을 보관하고, 업데이트 후 파일 해석 성공 여부와 정책 그룹 존재 여부를 확인한 다음 한 대의 단말로 테스트하세요.
DNS는 가장 쉽게 놓치는 중간 계층입니다
단말에서 도메인을 열 수 있는지는 조회 요청이 어디로 전송되는지, 그리고 반환된 주소가 현재 규칙에 적합한지에 달려 있습니다. 메인 라우터·바이패스 라우터·통신사 DNS·암호화 DNS·Mihomo 내장 DNS가 동시에 관여할 수 있습니다. 프록시 연결 자체는 정상인데 도메인 조회가 실패한다면 IP 접속, LAN DNS 포트, Mihomo DNS 수신 포트와 규칙의 도메인 조회 정책을 각각 테스트하세요. 모드만 반복해서 전환하지 마세요. 모드 전환은 단말이 실제로 사용하는 DNS 서버를 바꾸지 않습니다.
IPv6는 IPv4 경험만으로 판단할 수 없습니다
홈 네트워크에서 IPv6를 활성화하면 단말이 AAAA 레코드를 우선 받고 IPv6 기본 경로로 직접 연결할 수 있습니다. IPv4에만 투명 프록시를 설정했다면 일부 서비스가 프록시를 우회하거나 연결 대기 시간이 길어질 수 있습니다. 실제 필요에 따라 IPv6 방화벽·라우터 광고·Mihomo의 IPv6 처리 능력을 확인하세요. IPv6 경로를 아직 설계하지 않았다면 테스트 네트워크에서 먼저 IPv6를 끄고 비교할 수도 있지만, 이는 네트워크 정책 선택이지 프록시 커널에 반드시 문제가 있다는 뜻은 아닙니다.
메인 라우터의 복구 경로를 남겨 두세요
메인 라우터에서 직접 실행할 때는 로컬 관리 진입점, 사용할 수 있는 원본 설정과 투명 프록시를 끄는 방법을 준비해야 합니다. 바이패스 라우터를 사용할 때는 메인 라우터와 바이패스 라우터의 관리 주소, DHCP 담당 장비 및 기본 게이트웨이 변경 위치를 기록하세요. DHCP로 배포한 게이트웨이나 DNS를 변경한 뒤에도 단말에 이전 임대 정보가 남아 있을 수 있으므로 네트워크를 다시 연결하거나 수동으로 임대를 갱신해야 합니다. 유지관리 작업에서는 한 번에 하나의 변수만 바꾸고, 커널 업그레이드·구독 교체·방화벽 조정을 동시에 진행하지 않는 것이 좋습니다.
선택 방법: 적용 범위·성능·장애 비용으로 판단하기
프록시가 필요한 기기가 몇 대뿐이고 기기 자체가 시스템 프록시 또는 Clash 클라이언트를 지원한다면, 단말에서 클라이언트를 계속 실행하는 편이 연결·규칙 매칭·로그를 확인하기 쉽습니다. 라우터 배포는 다양한 기기에 일괄 적용하거나 홈 네트워크 전체를 동일한 규칙으로 분리하고 싶을 때 더 적합합니다. 선택하기 전에 장비 성능을 확인하세요. 메모리가 부족하면 시스템이 커널을 종료할 수 있고, CPU 성능이 낮으면 많은 연결·규칙 세트 해석·암호화 전달로 지연이 발생할 수 있습니다.
| 요구 사항 | 더 적합한 구성 | 주요 확인 사항 |
|---|---|---|
| 가족 구성원 전체 기기의 트래픽을 일괄 분리 | 메인 라우터 직접 실행 또는 바이패스 라우터를 기본 게이트웨이로 사용 | DHCP·DNS·IPv4·IPv6 경로를 중점적으로 확인 |
| 먼저 일부 기기만 테스트 | 기기별로 바이패스 라우터 게이트웨이 지정 | 메인 라우터를 기본 출구로 유지하고 범위를 단계적으로 확대 |
| 라우터 하드웨어 자원이 제한적임 | 독립형 바이패스 라우터 | 메모리·연결 수·규칙 세트 규모·발열을 확인 |
| 브라우저 프록시만 필요함 | 단말에서 명시적 프록시 사용 | 홈 네트워크의 트래픽 전달 구조를 먼저 바꿀 필요가 없음 |
안전한 검증 순서는 다음과 같습니다. 먼저 Mihomo 프로세스가 실행 중인지 확인하고, 설정 파일이 정상적으로 로드되었는지 확인합니다. 다음으로 바이패스 라우터 자체에서 노드 연결을 테스트한 뒤, LAN 단말 한 대를 지정된 진입점으로 연결합니다. 마지막으로 게이트웨이나 DNS를 더 많은 기기에 배포하세요. 단계마다 단말 IP·기본 게이트웨이·DNS 주소·프록시 수신 포트·현재 모드를 기록하면, 문제가 생겼을 때 기기가 바이패스 라우터를 거치지 않는지, 트래픽이 투명 프록시 진입점에 들어가지 않는지, 규칙 선택이 예상과 다른지, 노드 자체가 사용할 수 없는지를 빠르게 판단할 수 있습니다.
일반적인 증상과 문제 확인 순서
- 단말에서 프록시 효과가 전혀 없음: 먼저 단말의 기본 게이트웨이를 확인해 프록시 전환을 담당하는 장비를 가리키는지 확인한 다음, 바이패스 라우터의 전달 허용 여부와 방화벽 규칙 로드 상태를 점검하세요.
- 웹 페이지는 열리지만 애플리케이션이 실패함: 애플리케이션이 UDP·QUIC·별도 DNS 또는 IPv6를 사용할 수 있습니다. 테스트할 때 연결 유형과 로그를 확인하고 브라우저 결과만으로 판단하지 마세요.
- 노드 목록은 있지만 모두 시간 초과됨: 라우터 자체에서 노드 서버까지 연결되는지 테스트하고, 시간 설정·출구 DNS·상위 방화벽·구독에 포함된 서버 주소를 확인하세요.
- LAN 기기 간 접속이 비정상임: 투명 프록시가 내부 네트워크 주소를 잘못 가로채고 있지 않은지 확인하고, 규칙에서 LAN·예약 주소·관리 네트워크 대역을 어떻게 처리하는지 점검하세요.
- 재시작 후 설정이 적용되지 않음: 시작 서비스·마운트 경로·설정 파일 권한을 확인하고, 커널이 네트워크 인터페이스와 저장소 마운트보다 늦게 시작되는지 점검하세요.
로그는 네트워크 패킷 캡처나 라우팅 테이블 정보와 함께 읽어야 합니다. ‘연결 실패’만으로 문제가 노드에서 발생했다고 단정할 수 없습니다. 로그에 해당 도메인이나 목적지 주소가 전혀 없다면 단말이 Mihomo 진입점을 거치지 않았을 가능성이 큽니다. 반대로 규칙 매칭과 아웃바운드 연결이 확인되는데 응답 시간이 초과된다면 정책 그룹·원격 노드·반환 네트워크를 계속 점검해야 합니다.
결론적으로 Mihomo 라우터 배포는 프로그램 하나를 설치하는 작업이 아니라 네트워크 출구를 설계하는 일입니다. 메인 라우터 직접 실행은 경로 집중을, 바이패스 라우터는 역할 분리를 지향합니다. 투명 프록시는 지정된 노드를 거치는 연결을 전환하고, 규칙은 연결 처리 방식을 결정하며, 구독은 주로 업데이트 가능한 노드와 설정 내용을 제공합니다. 이 경계를 먼저 구분한 뒤 기기 수·하드웨어 자원·유지관리 역량에 맞는 구성을 선택하면 이후 설정과 문제 해결을 더 안정적으로 관리할 수 있습니다.