공유기와 서브 라우터에서 직접 구동하는 mihomo 커널: 전체 네트워크 투명 프록시 배포 개요

왜 프록시를 라우터 계층으로 내려야 할까

데스크톱 클라이언트(Clash Verge Rev, FlClash 등)는 프록시를 특정 기기 한 대에서 구동하기 때문에 설정이 직관적이고 화면이 친절하지만, 적용 범위는 그 한 대에 그칩니다. 집 안의 TV 셋톱박스, 스마트 스피커, 태블릿, 프린터, 친구가 잠시 빌려 쓰는 휴대폰 같은 기기는 모두 프록시 밖에 남습니다—공용망으로 직접 연결되거나 아예 프록시를 설정할 방법이 없습니다. mihomo 커널을 공유기나 서브 라우터에 직접 배포하면 "프록시"라는 작업을 단말 기기에서 떼어내 네트워크 출구 계층에 얹는 셈이 되어, 이 라우터에 연결된 모든 기기가 별도 설치나 구독 재설정 없이 자동으로 프록시 기능을 갖게 됩니다.

이런 "전체 네트워크 프록시" 방식은 몇 가지 상황에 특히 잘 맞습니다: 집에 기기 종류와 수가 많을 때, 커스텀 프록시 설정을 지원하지 않는 스마트 기기(TV, 셋톱박스)에 출구를 제공해야 할 때, 또는 기기마다 클라이언트를 따로 유지하는 운영 비용을 줄이고 싶을 때입니다. 대가는 데스크톱 클라이언트 설치보다 훨씬 높은 진입장벽으로, 설정 파일과 명령줄, 어느 정도의 네트워크 기초 지식을 다뤄야 하며 문제가 생기면 클라이언트의 시각적 연결 상태 표시 없이 로그로 직접 원인을 찾아야 합니다.

하드웨어 선택: 메인 라우터에 커스텀 펌웨어를 올릴지, 서브 라우터를 둘지

배포 전에 먼저 하드웨어 방향을 정해야 하며, 흔한 두 가지 방식이 있습니다:

• 메인 라우터에 mihomo를 지원하는 펌웨어를 직접 설치: 이미 라우터를 교체할 계획이 있고 기존 라우터의 안정성에 크게 신경 쓰지 않는 경우에 적합합니다. 장점은 별도 기기가 필요 없고 구조가 단순하다는 점이며, 단점은 메인 라우터가 모든 전달 부담을 지게 되어 펌웨어에 문제가 생기면 집 전체가 인터넷 끊김에 빠지는, 위험이 집중되는 구조라는 점입니다.
• 서브 라우터 방식(대다수 가정에 추천): 기존 메인 라우터 뒤에 작은 기기(x86 미니 PC, 라즈베리 파이, 커스텀 펌웨어를 지원하는 중고 라우터 등)를 하나 더 연결해 mihomo만 이 기기에서 구동하고, 메인 라우터는 DHCP와 일반 라우팅을 그대로 담당하며 게이트웨이 주소나 기본 경로만 서브 라우터로 돌립니다. 이 구조는 변경 폭이 작고 메인 라우터의 안정성에 영향을 주지 않아, 문제가 생기면 기본 경로를 메인 라우터로 되돌리기만 해도 임시로 인터넷을 복구할 수 있어 되돌리는 비용이 낮습니다. 전체 네트워크 프록시를 처음 시도하는 사용자에게 더 적합합니다.

하드웨어 사양 면에서 mihomo 자체는 CPU와 메모리 요구사항이 그리 높지 않아, 일반적인 기가비트 환경이라면 듀얼 코어에 메모리 512MB 이상인 기기로도 안정적으로 구동할 수 있습니다. 집 대역폭이 500Mbps를 넘고 규칙 수가 많다면 여유 있는 메모리와 조금 더 강한 CPU를 준비해, 규칙 매칭과 연결 수가 늘어난 뒤 전달 병목이 생기지 않도록 하는 것이 좋습니다. 저장 공간은 커널과 설정 파일의 일상 사용을 만족시키는 데 수십~수백 MB 정도면 충분합니다.

시스템 환경 준비

하드웨어 경로에 따라 시스템 환경은 달라지지만, 진행 방식은 동일합니다:

1. 시스템 아키텍처 확인: mihomo 커널을 내려받기 전에 기기가 amd64, arm64인지 다른 아키텍처인지 먼저 확인하세요. 아키텍처가 맞지 않으면 바이너리 파일이 실행되지 않습니다.
2. 실행 환경 준비: Linux 기반 서브 라우터(일반 배포판이나 OpenWrt 계열 펌웨어)라면 시스템에 기본 네트워크 도구(iproute2, iptables 또는 nftables)와 부팅 스크립트 기능이 있는지 확인하세요. 서드파티 플러그인을 지원하는 라우터 펌웨어라면 해당 펌웨어에 이미 mihomo/Clash 플러그인 패키지가 준비돼 있는지 먼저 확인하면 수동 컴파일과 의존성 확인 과정을 줄일 수 있습니다.
3. 충돌 요소 정리: 이전에 다른 프록시나 투명 프록시 방식을 이 기기에서 실행한 적이 있다면, 관련 전달 규칙과 DNS 하이재킹 규칙이 이미 정리됐는지 먼저 확인하세요. 신규 규칙과 기존 규칙이 겹치면 트래픽 경로가 뒤엉켜 원인 파악이 어려워집니다.
4. 관리 접근 경로 확보: 배포 전에 SSH나 펌웨어 자체 관리 화면을 미리 열어두세요. 나중에 커널 로그를 확인하거나 서비스를 재시작할 때 필요하며, 네트워크가 끊긴 다음에야 관리 접근 경로 자체도 프록시 규칙을 타고 있어서 접속이 안 된다는 사실을 발견하는 상황을 피할 수 있습니다.

설정 파일 배치와 핵심 항목

mihomo가 사용하는 설정 파일은 Clash 계열 설정의 YAML 구조를 이어받아, 핵심 항목으로 인바운드 포트, 모드, DNS 구간, 프록시 규칙이 있습니다. 이는 데스크톱 클라이언트에서 "구독 가져오기"를 할 때 내부적으로 벌어지는 일과 본질적으로 같으며, 라우터 계층에서는 파일 경로를 직접 배치하고 서비스 생명주기를 관리해야 한다는 점만 다릅니다. 전형적인 최소 골격은 대략 다음과 같습니다:

mixed-port: 7890
mode: rule
log-level: info
tun:
  enable: true
  stack: system
  auto-route: true
  auto-detect-interface: true
dns:
  enable: true
  nameserver:
    - 223.5.5.5
    - 119.29.29.29
proxies: []
proxy-groups: []
rules:
  - MATCH,DIRECT

실제 사용 시 proxies와 rules 구간은 대개 구독 링크가 제공하는 원격 설정으로 교체되며, 노드 정보를 하나하나 직접 입력할 필요는 없습니다. 구독으로 생성된 설정 파일을 커널이 정한 설정 디렉터리에 두면, 커널이 시작될 때 이 파일을 읽어 프록시 그룹과 규칙 표를 구성합니다. 대부분의 배포는 설정 파일을 별도로 저장하고 커널이 고정된 파라미터로 그 파일 경로를 가리키게 해, 이후 구독을 갱신할 때 설정 파일만 교체하면 되고 시작 스크립트를 다시 조정할 필요가 없도록 합니다.

규칙 구간의 작성 방식은 데스크톱 쪽과 동일하며, 흔한 판단 우선순위는 도메인 규칙, IP 규칙, 마지막으로 MATCH로 마무리하는 방식입니다. 예를 들어 국내(중국 본토) 도메인은 직접 연결, 특정 서비스는 프록시로, 나머지 트래픽은 정책 그룹에 따라 분류합니다. 규칙 수가 많아지면 규칙셋(rule-provider)을 사용해 원격 규칙 파일을 참조하는 방식을 추천하며, 수천 줄의 규칙을 메인 설정에 그대로 쌓아 넣는 것보다 갱신이 편리하고 커널 시작 시 파싱 부담도 줄어듭니다.

투명 프록시 모드: TUN과 게이트웨이 하이재킹, 무엇을 고를까

라우터 계층 배포에서 풀어야 할 핵심 과제는 접속 기기가 "느끼지 못하게" 트래픽을 mihomo에 넘기는 것으로, 흔히 두 가지 방식이 있습니다:

TUN 모드로 전체 출구를 관리

서브 라우터나 커스텀 펌웨어 라우터에서 TUN 모드를 켜면, 커널이 가상 네트워크 카드를 만들고 시스템 라우팅 테이블을 자동으로 인수합니다. 이 기기를 거쳐 전달되는 모든 트래픽은 먼저 mihomo로 들어가 처리된 뒤 규칙에 따라 분산됩니다. 이 방식은 설정이 비교적 간단하고 별도의 iptables 전달 규칙이 필요 없으며 호환성도 좋아, 현재 라우터 계층 배포에서 가장 널리 쓰이는 방식입니다. 설정에서는 앞서 예시의 tun.enable과 auto-route 항목에 해당합니다.

게이트웨이 하이재킹과 DNS 분리

같은 네트워크 안의 다른 기기들이 mihomo를 구동 중인 이 기기를 기본 게이트웨이로 삼거나(또는 서브 라우터에서 기본 경로만 이쪽으로 돌리거나), 기기들의 DNS 요청과 TCP/UDP 트래픽이 이 기기를 거쳐 일괄 처리되게 하는 방식입니다. 이 방법은 네트워크 계층에서 기본 경로나 DHCP 게이트웨이 주소를 조정해야 해서 네트워크 기초 지식이 더 많이 필요하지만, 접속 기기가 완전히 무설정으로 랜선을 꽂거나 Wi-Fi에 연결하기만 하면 자동으로 프록시 기능을 얻는다는 장점이 있으며, 이것이 "전체 네트워크 프록시"가 궁극적으로 목표하는 효과입니다.

두 방식은 서로 배타적이지 않아, 실제 배포 대부분은 "서브 라우터에서 TUN을 켜 자체 전달 트래픽을 관리" + "같은 네트워크의 기기가 게이트웨이를 서브 라우터로 향하게 함"을 함께 사용해 서브 라우터를 네트워크의 통합 출구로 만드는 방식입니다.

자동 시작과 안정성 유지

라우터나 서브 라우터는 보통 장시간 전원이 켜진 채로 운영되므로, 정전 후 재부팅했을 때 커널이 자동으로 다시 올라오지 못하면 집 전체 네트워크가 함께 끊깁니다. 그래서 자동 시작은 선택이 아니라 필수입니다. 시스템 서비스 관리자를 기반으로 하는 기기라면, 커널 실행 명령을 서비스 유닛으로 작성해 시스템 부팅 시 자동 실행되고 비정상 종료 후 자동 재시작되도록 설정하는 방식이 흔합니다. 펌웨어 플러그인 체계를 쓰는 라우터라면 대개 플러그인 자체에 이미 자동 시작 로직이 내장돼 있어 관리 화면에서 "라우터 부팅 시 시작"만 체크하면 됩니다.

• 커널 로그를 정기적으로 확인해 규칙 매칭 오류나 노드 연결 실패 같은 에러를 살펴, "구동은 되고 있지만 실제로는 작동하지 않는" 상황이 장기간 방치되지 않도록 합니다.
• 구독 갱신 후에는 설정을 다시 불러오세요(대부분의 배포는 핫 리로드를 지원해 서비스 전체를 재시작할 필요가 없습니다). 설정 갱신으로 인한 짧은 인터넷 끊김 시간을 줄일 수 있습니다.
• 관리 접근 경로에는 직접 연결이나 화이트리스트 규칙을 남겨 두어, 어떤 규칙 갱신 때문에 자기 자신의 관리 화면조차 접속되지 않는 상황을 방지하세요.
• 커널 버전 갱신 흐름에 관심을 두세요. mihomo는 업데이트가 빠른 편이며 새 버전은 대개 프로토콜 호환성 수정과 성능 개선을 가져오지만, 업그레이드 전에는 릴리스 노트를 먼저 확인해 설정 항목 변경으로 시작 실패가 생기지 않도록 하세요.

데스크톱 클라이언트 방식과의 취사선택

라우터 계층 배포와 데스크톱 클라이언트는 양자택일 관계가 아니라, 필요에 따라 조합하는 것이 더 적합합니다:

• 적용 범위: 라우터 계층 배포는 한 번에 집 안 모든 기기를 아우르지만, 데스크톱 클라이언트는 설치된 그 한 대만 적용됩니다. 집에 스마트 기기가 많거나 방문객이 자주 네트워크에 임시로 접속한다면, 라우터 계층 배포의 추가 비용이 더 낮습니다.
• 시각화와 사용 편의성: 데스크톱 클라이언트는 그래픽 화면, 연결 테스트, 노드 지연 시간 한눈에 보기 기능이 있어 문제를 스스로 확인하기 쉽습니다. 라우터 계층 배포는 이런 기능이 없어 로그와 명령줄에 의존해야 하며 비기술 사용자에게는 불친절합니다.
• 유연한 전환: 데스크톱 클라이언트는 앱별, 창별로 프록시 정책을 언제든 바꿀 수 있지만, 라우터 계층 배포의 정책은 전체 네트워크에 일괄 적용되어 기기 단위로 세밀하게 차등 설정하려면 별도의 정책 라우팅 지식이 필요합니다.
• 장애 영향 범위: 데스크톱 클라이언트에 문제가 생기면 그 한 대만 영향을 받지만, 라우터 계층 배포에서 문제가 생기면 특히 메인 라우터에 직접 펌웨어를 올린 경우 집 전체가 인터넷이 끊길 수 있습니다. 이것이 앞서 서브 라우터 방식을 우선 권장한 이유입니다.

흔한 조합 방식은 라우터 계층 배포로 TV 셋톱박스나 스마트 기기처럼 "클라이언트를 따로 설치하기 어려운" 단말에 기본 프록시 기능을 제공하는 동시에, 자신의 컴퓨터와 휴대폰에서는 계속 데스크톱이나 모바일 클라이언트를 써서 앱별 세밀한 분리를 하는 것으로, 두 방식이 서로 대체하는 것이 아니라 각자의 역할을 맡는 구조입니다.