Mihomo 라우터 설치 입문: 메인 라우터·보조 라우터·코어 직접 실행 방식 비교

네트워크 위치와 실행 방식부터 구분하기

Mihomo는 Clash Meta를 계승해 개발되는 프록시 코어입니다. 라우터 환경에 설치할 때 가장 혼동하기 쉬운 부분은 설정 문법이 아니라 서로 다른 두 기준입니다. 하나는 장치가 네트워크의 어느 위치에 있는지이고, 다른 하나는 코어를 어떤 방식으로 시작하고 관리하는지입니다. 메인 라우터와 보조 라우터는 네트워크 토폴로지를 뜻하며, 코어 직접 실행과 라우터 플러그인, 컨테이너는 소프트웨어 실행 방식을 뜻합니다. 이 선택지는 서로 배타적이지 않으므로 보조 라우터에서도 코어를 직접 실행할 수 있습니다.

배포하기 전에 가장 짧은 데이터 경로부터 그려 보세요. 단말이 패킷을 어느 기본 게이트웨이로 보내는지, DNS 질의는 어디로 전달되는지, 어느 장치에서 트래픽이 Mihomo로 진입하는지, 프록시 처리 후 어느 출구로 나가는지를 확인해야 합니다. 이 네 지점이 명확하지 않으면 웹페이지 접속 불가, 특정 지역 사이트의 우회, 일부 장치 미적용, IPv6 우회가 발생했을 때 규칙과 DNS, 라우팅 중 어디가 문제인지 판단하기 어렵습니다.

메인 라우터 배포: 경로는 단순하지만 변경 영향은 큼

메인 라우터 방식은 Mihomo를 전체 네트워크의 기본 출구에 배치합니다. 단말은 일반적으로 이 장치에서 IP 주소와 기본 게이트웨이, DNS 주소를 받으므로 장치마다 따로 설정하지 않아도 공통 규칙을 적용할 수 있습니다. 투명 프록시 진입점은 TProxy, 리디렉션 규칙 또는 TUN 장치로 구성할 수 있으며, 운영체제 커널과 플러그인 구현 방식, UDP 처리 필요 여부에 따라 선택합니다.

이 토폴로지의 장점은 경로가 명확하다는 것입니다. LAN 단말의 트래픽이 먼저 메인 라우터에 도착하고, 규칙에 따라 직접 연결하거나 프록시를 거치거나 차단됩니다. DNS도 한곳에서 관리하기 쉽고, 출발지 IP, MAC 주소와 연결된 고정 임대, VLAN, 서브넷을 기준으로 장치를 그룹화할 수 있습니다. TV, 스마트폰, PC, 게임기 등을 장기간 일관되게 관리해야 하는 홈 네트워크라면 장치마다 클라이언트를 설치하는 것보다 메인 라우터에서 통합 관리하는 편이 수월합니다.

반면 장애 영향 범위가 큽니다. 잘못된 방화벽 규칙이나 사용할 수 없는 설정 파일, DNS 루프는 LAN 전체에 동시에 영향을 줄 수 있습니다. 코어를 업데이트할 때도 장치 아키텍처, 실행 파일 권한, 설정 호환성, 서비스 재시작 순서를 고려해야 합니다. 라우터 성능이 제한적이라면 암호화 연결, 규칙 매칭, DNS 캐시, 로그 기록이 CPU와 메모리를 함께 사용하므로 포트의 표기 속도만으로 실제 프록시 처리량을 판단해서는 안 됩니다.

메인 라우터 방식에 적합한 조건

1. 라우터 운영체제를 관리할 수 있고, 로컬 관리 경로와 설정 복구 방법을 마련할 수 있습니다.
2. 장치의 CPU 아키텍처에 맞는 Mihomo 빌드가 있으며, 코어와 규칙 세트, 로그를 저장할 공간이 충분합니다.
3. 소수 장치만 프록시를 사용하도록 하기보다 대부분의 단말에 기본적으로 같은 라우팅 규칙을 적용하려는 경우입니다.
4. 업데이트 시간을 따로 확보할 수 있고, 프록시 서비스 재시작 중 발생하는 짧은 연결 중단을 감수할 수 있습니다.

보조 라우터 배포: 테스트에 유리하며 트래픽 전달이 핵심

보조 라우터는 일반적으로 메인 라우터와 같은 LAN에 연결합니다. 메인 라우터는 인터넷 연결, NAT, Wi-Fi 접속을 계속 담당하고, 보조 라우터는 선택한 단말의 프록시와 DNS를 처리합니다. 단계적 배포에 적합한 방식으로, 먼저 테스트 PC 한 대에 보조 라우터를 적용해 규칙과 구독, DNS를 검증한 뒤 고정 장치나 별도 서브넷으로 적용 범위를 넓힐 수 있습니다.

보조 라우터를 스위치에 연결한다고 해서 전체 네트워크 트래픽이 자동으로 들어오는 것은 아닙니다. 가장 간단한 방법은 단말의 기본 게이트웨이와 DNS를 보조 라우터로 지정하는 것입니다. DHCP에서 특정 장치에 다른 게이트웨이를 배포하거나, 메인 라우터의 정책 기반 라우팅으로 지정한 출발지 주소를 보조 라우터에 전달할 수도 있습니다. 어떤 방식을 사용할지는 메인 라우터가 고정 임대, 장치별 옵션 배포, 정책 기반 라우팅을 지원하는지에 따라 달라집니다.

원암형 보조 라우터는 LAN 인터페이스가 하나뿐이므로 패킷이 같은 인터페이스로 들어와 처리된 후 다시 메인 라우터로 나갑니다. 이때는 반환 경로를 특히 주의해야 합니다. 단말이 보낸 패킷은 보조 라우터를 거치지만 응답 패킷을 메인 라우터가 단말로 직접 보내면 비대칭 경로가 만들어질 수 있습니다. 일반 연결은 작동할 때도 있지만 연결 추적, 투명 프록시, 엄격한 상태 기반 방화벽에 의존하는 환경에서는 문제가 생길 수 있습니다. 실제 배포에서는 올바른 게이트웨이 설계, 정책 기반 라우팅 또는 필요한 경우 SNAT를 적용해 경로를 일치시킵니다.

보조 라우터의 일반적인 연결 방식

보조 라우터에서 DHCP를 끄는 것이 항상 정답은 아닙니다. 메인 라우터가 주소를 통합 할당한다면 보조 라우터에서 같은 대역의 DHCP를 다시 켤 필요가 없습니다. 반대로 보조 라우터가 별도 서브넷을 관리한다면 해당 서브넷에 DHCP를 제공할 수 있습니다. 판단 기준은 특정 서비스를 무조건 켜거나 끄는 것이 아니라, 각 브로드캐스트 도메인에 명확하고 통제 가능한 주소 할당 방식이 하나만 존재하는지입니다.

코어 직접 실행: 세밀한 제어가 가능하지만 시스템 구성은 직접 처리

코어 직접 실행은 CPU 아키텍처에 맞는 Mihomo 실행 파일을 내려받아 YAML 설정을 준비하고 시스템 서비스 관리자로 시작하는 방식입니다. GUI 플러그인이 설정 구조에 가하는 제약이 적어 규칙 프로바이더, 수신 포트, 실험적 기능, 자동 배포 절차를 직접 구성하려는 사용자에게 적합합니다. 단, 코어는 자체 프록시 기능만 담당하므로 라우터 시스템에 필요한 모든 작업을 자동으로 처리해 주지는 않습니다.

정상적으로 작동하는 직접 실행 환경에는 최소 다섯 가지가 필요합니다. 설정 파일과 외부 규칙 리소스, 영구 저장 디렉터리, 시작 서비스, 투명 프록시 또는 TUN에 필요한 권한, DNS와 방화벽 연동입니다. 업데이트와 롤백 절차도 마련해야 합니다. 업데이트 전에 설정 검사를 실행하고 이전 바이너리를 보관하며, 새 프로세스가 시작되지 않으면 기존 서비스를 복원할 수 있어야 합니다.

mode: rule
allow-lan: true
bind-address: "*"
mixed-port: 7890
tproxy-port: 7893

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  nameserver:
    - 223.5.5.5
  proxy-server-nameserver:
    - 1.1.1.1

위 예시는 포트 수신 관계만 보여 주며 라우터에 바로 적용할 수 있는 완전한 설정이 아닙니다. 프록시 노드, 정책 그룹, 규칙, 규칙 세트, 방화벽의 트래픽 전달 설정은 별도로 정의해야 합니다. DNS 업스트림도 네트워크 환경과 분기 목적에 맞게 선택해야 합니다. DNS를 1053 포트에서 수신하도록 설정했다면 시스템 DNS 포워더가 질의를 해당 포트로 넘기거나 단말이 직접 접근하도록 구성해야 합니다. 설정 파일에 추가하는 것만으로 LAN의 53 포트를 자동으로 넘겨받지는 않습니다.

직접 실행 서비스의 시작 순서

1. 네트워크 인터페이스와 시간 동기화가 정상이며 설정 디렉터리가 준비되었는지 확인합니다.
2. 설정 문법과 외부 리소스의 읽기 가능 여부를 검사해 서비스가 반복해서 재시작되지 않도록 합니다.
3. Mihomo를 시작하고 프록시 포트, DNS 포트, 제어 인터페이스가 예상대로 수신 중인지 확인합니다.
4. 수신하지 않는 포트로 트래픽이 전달되지 않도록 그다음에 투명 프록시와 정책 기반 라우팅 규칙을 적용합니다.
5. 서비스를 중지할 때는 트래픽 전달 규칙을 먼저 해제한 뒤 코어를 종료해 LAN 연결이 블랙홀로 빠지는 시간을 줄입니다.

DNS, 투명 프록시, IPv6를 함께 설계해야 하는 이유

라우터 배포에서 “노드가 불안정하다”고 보이는 현상은 실제로 DNS 경로에서 비롯되는 경우가 많습니다. 단말의 DNS 질의가 메인 라우터를 거쳐 Mihomo로 전달될 수도 있고, 보조 라우터를 직접 조회할 수도 있습니다. “시스템 DNS가 Mihomo로 전달하고, Mihomo가 같은 업스트림 요청을 다시 시스템 DNS로 보내는” 루프가 생기지 않는지 확인해야 합니다.

Mihomo의 fake-ip 모드는 예약 주소 풀에서 매핑 주소를 반환한 뒤, 후속 연결이 코어에 들어오면 도메인 이름을 복원합니다. 따라서 도메인 기반 규칙으로 연결을 처리하기 좋습니다. 일부 LAN 장치와 내부 도메인, 시간 동기화 서비스, 실제 IP 응답이 필요한 앱은 fake-ip-filter에 추가해야 할 수 있습니다. redir-host 모드는 실제 DNS 조회 결과를 반환하는 방식에 가깝지만, 도메인 식별과 캐시 동작은 프로토콜별로 검증해야 합니다. 두 모드의 우열은 환경에 따라 달라지므로 선택한 뒤 로그에서 도메인 규칙이 실제로 매칭되는지 확인하세요.

프록시 서버 도메인 이름의 DNS 조회는 별개의 과정입니다. 노드의 호스트 이름을 먼저 확인해야 연결을 시작할 수 있으므로, 이 질의를 처리할 수 있는 DNS 리졸버를 준비해야 합니다. Mihomo 설정의 proxy-server-nameserver를 사용하면 프록시 서버 도메인을 별도로 조회해 시작 단계에서 프록시 경로에 의존할 위험을 줄일 수 있습니다. 규칙 프로바이더나 구독 URL에 접근할 때도 같은 의존성을 고려해야 합니다. 설정을 받으려면 프록시가 필요하고, 프록시를 시작하려면 아직 받지 못한 설정이 필요한 구조라면 부팅 과정이 순환합니다.

투명 프록시 진입점 선택

• 명시적 프록시 포트: 단말에 HTTP 또는 SOCKS 프록시를 직접 입력하는 방식입니다. 경로를 확인하기 쉽지만 프록시 설정을 지원하지 않는 앱에는 적용할 수 없습니다.
• TProxy: Linux 라우터 환경에서 주로 사용하며 원래 목적지 정보를 유지한 채 TCP와 UDP를 처리할 수 있지만, 정책 기반 라우팅과 커널 모듈, 방화벽 규칙이 필요합니다.
• TUN 모드: 가상 네트워크 인터페이스가 트래픽을 받으므로 구성 방식이 비교적 일관적이지만, 장치 권한과 라우팅 테이블, DNS 하이재킹, 기존 VPN과의 충돌을 확인해야 합니다.
• 리디렉션 방식: TCP 트래픽 전달에 널리 쓰이며 구현이 안정적이지만, UDP와 원래 목적지 처리 기능은 운영체제의 구성 방식에 따라 달라집니다.

IPv6는 Mihomo 설정의 옵션 하나만 확인해서는 안 됩니다. LAN이 단말에 IPv6 기본 경로와 DNS를 계속 알리고 있다면 단말이 IPv6 직접 연결을 우선 사용해 IPv4만 처리하는 투명 프록시 규칙을 우회할 수 있습니다. IPv6도 프록시하려면 업스트림 프리픽스, 라우터 광고, 방화벽, TUN 또는 TProxy 지원, 규칙 적용 범위를 함께 확인해야 합니다. 당장 처리하지 않는 경우에도 관련 광고를 명시적으로 끄거나 설명 가능한 직접 연결 정책을 구성해야 합니다. IPv4와 IPv6가 서로 다르고 관찰할 수 없는 경로로 흐르도록 방치해서는 안 됩니다.

적용 범위, 관리 역량, 복구 비용에 따른 선택

방식을 고를 때 어느 쪽의 성능이 가장 높은지부터 묻기보다 적용할 장치 수, 메인 라우터 변경 가능 여부, 장애가 발생해도 인터넷 연결을 유지해야 하는 대상을 먼저 정해야 합니다. TV 한 대나 테스트 PC만 사용할 때는 보조 라우터와 선택적 게이트웨이 설정으로 충분합니다. 집 안의 모든 장치에 같은 규칙을 적용하고 라우터를 관리할 수 있다면 메인 라우터 방식이 더 단순합니다. 설정 생성과 서비스 구성, 방화벽 세부 항목을 정밀하게 제어해야 한다면 두 토폴로지 중 하나에서 코어를 직접 실행할 수 있습니다.

배포 전 확인할 항목

• 메인 라우터, 보조 라우터, 단말, DNS 서비스의 IP 주소를 기록해 주소 충돌을 방지합니다.
• 장치의 CPU 아키텍처, 사용 가능한 메모리와 저장 공간, 운영체제에서 사용하는 방화벽 프레임워크를 확인합니다.
• TCP, UDP, IPv4, IPv6를 각각 어떤 진입점으로 처리할지 결정합니다.
• 프록시를 거치지 않아야 하는 LAN 대역, 관리 주소, 기본 서비스에 예외 규칙을 적용합니다.
• 테스트 단말에 고정 주소를 할당해 로그에서 연결 출처를 쉽게 식별할 수 있도록 합니다.
• 프록시 중지 후 일반 인터넷 연결로 복원하는 절차를 준비하고, 정식 적용 전에 실제로 테스트합니다.

배포 후 단계별 검증

1. 기본 네트워크: 투명 프록시를 끈 상태에서 단말이 기존 출구를 통해 LAN과 인터넷에 정상적으로 접속할 수 있는지 확인합니다.
2. DNS: 단말이 실제로 사용하는 DNS 주소와 질의 응답, Mihomo DNS 로그를 확인해 루프와 시간 초과를 배제합니다.
3. 트래픽 진입점: 대상 연결이 Mihomo 로그에 표시되고 출발지 주소, 목적지 주소, 매칭된 규칙을 확인할 수 있는지 점검합니다.
4. 정책 결과: 직접 연결, 프록시, 차단 대상 도메인을 각각 테스트하고 속도 측정 사이트 하나의 결과에만 의존하지 않습니다.
5. UDP 및 IPv6: 실시간 통신, 게임 등 UDP 사용 환경을 별도로 검증한 뒤 IPv6가 정해진 경로를 따르는지 확인합니다.
6. 장애 시 복구: Mihomo를 중지하거나 사용할 수 없는 설정을 적용해도 관리 화면에 접근할 수 있고 계획대로 네트워크를 복원할 수 있는지 검증합니다.

라우터에 Mihomo를 배포하는 작업은 본질적으로 네트워크 경로를 설계하고 검증하는 과정입니다. 메인 라우터 방식은 통합된 진입점, 보조 라우터 방식은 통제 가능한 적용 범위, 코어 직접 실행은 설정과 시스템을 직접 관리하는 데 초점을 둡니다. 먼저 고정 단말 한 대로 관찰과 복구가 가능한 최소 경로를 구성한 뒤 DNS 제어, UDP, IPv6, 추가 장치를 단계적으로 적용하는 편이 전체 네트워크를 한 번에 전환하는 것보다 문제를 찾기 쉽습니다.