공유기에서 Clash 커널을 직접 구동하는 방법: OpenWrt와 서브 라우터 배포 가이드

왜 Clash 커널을 공유기로 옮겨야 할까

데스크톱 클라이언트는 클라이언트를 설치한 그 PC에서만 프록시 기능을 사용할 수 있습니다. 스마트폰, TV 셋톱박스, 게임기에서 같은 분기 규칙을 적용하려면 각각 별도의 클라이언트를 설치해야 하거나, 아예 방법이 없는 경우도 많습니다. mihomo 커널을 공유기에 직접 배포하면 프록시 기능이 네트워크 출구 단계로 내려오는 셈이라, 집 안의 모든 인터넷 연결 기기가 별도 소프트웨어 설치 없이 이 공유기에 연결만 하면 자동으로 규칙 분기가 적용됩니다. 다기기 가정, 스마트 TV, 앱 설치가 불가능한 기기(일부 셋톱박스, 프린터 네트워크 모듈 등)에는 특히 유효한 방법입니다.

이 방식의 대가는 설정 난이도가 데스크톱 클라이언트보다 훨씬 높다는 점입니다. 펌웨어 플래싱, 투명 프록시 경로, DNS 하이재킹처럼 다소 로우레벨인 영역을 다뤄야 하고, 어느 한 단계라도 설정을 잘못하면 집 전체 인터넷이 끊길 수 있습니다. 명령줄과 네트워크 기초 지식이 전혀 없는 사용자가 바로 시도하기에는 적합하지 않습니다. 단일 기기의 일상적인 사용이 목적이라면 데스크톱이나 모바일 클라이언트의 그래픽 인터페이스 설정이 훨씬 편합니다. "집 안의 모든 기기를 통일된 분기로 처리"하는 것이 반드시 필요한 요구일 때만 공유기 방식에 이 정도의 설정 비용을 투자할 가치가 있습니다.

두 가지 구조: 메인 라우터 직접 구동과 서브 라우터 연결

공유기에 Clash 커널을 배포하는 방식은 크게 두 가지 구조로 나뉩니다. 선택하기 전에 자신의 하드웨어 조건과 얼마나 손을 대고 싶은지를 먼저 정리해야 합니다.

메인 라우터 직접 구동: 가정용 공유기를 OpenWrt로 플래싱

이 방식은 집에서 쓰던 공유기(또는 플래싱을 지원하는 모델을 새로 구입)를 OpenWrt 펌웨어로 플래싱한 뒤, 펌웨어 내부에 mihomo 커널과 관리용 플러그인을 설치해 공유기 자체가 프록시 포워딩을 전담하도록 하는 것입니다. 장점은 경로가 가장 짧고 추가 하드웨어가 필요 없으며, LAN 내 모든 기기의 트래픽이 자연스럽게 이 공유기를 거쳐 나간다는 점입니다. 단점은 공유기의 CPU와 메모리에 일정 수준의 요구 사항이 생긴다는 점입니다. mihomo 실행과 규칙 매칭, DNS 해석까지 하면 보급형 공유기의 프로세서에는 상당한 부담이 되며, 기존 공유기 성능이 부족하면 프록시를 켠 뒤 인터넷 속도가 눈에 띄게 느려지거나 끊김이 발생할 수 있습니다. 플래싱 자체도 벽돌화(먹통) 위험이 있으므로, 사전에 기기 모델이 지원하는 펌웨어 버전을 확인하고 복구용 정품 펌웨어와 플래싱 도구를 반드시 준비해 두어야 합니다.

서브 라우터 연결: 별도의 소형 기기를 프록시 게이트웨이로 추가

서브 라우터(우회 라우터) 방식은 기존 공유기(기본 인터넷 연결만 계속 담당, 변경 없음) 외에 별도의 소형 PC나 미니 라우터를 하나 더 연결해 mihomo 커널을 전담 실행시키고, LAN 내 다른 기기들의 게이트웨이나 DNS 설정을 수정해 프록시가 필요한 트래픽만 이 서브 라우터로 보내는 방식입니다. 흔히 쓰는 하드웨어는 라즈베리파이, 미니 x86 PC, 또는 OpenWrt를 설치한 두 번째 공유기이며, 브리지 모드로 기존 네트워크에 연결합니다. 이 방식은 메인 라우터의 펌웨어를 건드릴 필요가 없어 위험과 난이도가 메인 라우터 직접 구동보다 훨씬 낮고, 서브 라우터 성능이 부족해지면 하드웨어만 따로 업그레이드하면 되므로 메인 라우터의 기본 인터넷 기능에 영향을 주지 않습니다. "메인 라우터를 건드려야 할지" 고민하는 대다수 가정 사용자에게는 서브 라우터가 더 안전한 시작점입니다.

투명 프록시 경로: 공유기가 트래픽을 넘겨받는 방식

공유기 단계에서 프록시를 처리하는 핵심 메커니즘은 투명 프록시(Transparent Proxy)입니다. 데스크톱 클라이언트의 시스템 프록시나 TUN 모드와 원리는 비슷하지만 구현 방식이 다릅니다. 기기(스마트폰, TV 셋톱박스) 자체는 자신의 트래픽이 프록시되고 있다는 사실을 알지 못하고 평소처럼 요청을 보내며, 공유기가 네트워크 계층에서 이 트래픽을 투명하게 리다이렉트해 로컬의 mihomo 프로세스로 넘긴 뒤 처리가 끝나면 다시 내보냅니다. 클라이언트 기기는 전혀 인지하지 못하고, 기기마다 별도로 프록시 주소를 설정할 필요도 없습니다.

투명 프록시를 구현하려면 공유기 운영체제의 트래픽 리다이렉트 기능이 필요합니다. OpenWrt에서 흔히 쓰는 방식은 방화벽 규칙(iptables 또는 nftables)으로 특정 포트 대역이나 프로토콜의 트래픽을 mihomo가 리스닝하는 투명 프록시 포트로 유도하고, mihomo 설정 파일의 tproxy-port 혹은 이와 유사한 필드와 맞물려 처리를 완료하는 것입니다. 이 단계는 전체 구성에서 실수하기 가장 쉬운 부분으로, 규칙을 잘못 작성하면 기기는 정상적으로 인터넷에 연결되지만 프록시 규칙이 전혀 작동하지 않거나, 반대로 모든 트래픽이 아예 나가지 못하는 상황이 발생할 수 있습니다. 먼저 테스트용 기기에서 경로가 정상적으로 통하는지 확인한 뒤, 점진적으로 집 안 전체 기기로 확대하는 것을 권장합니다.

DNS 하이재킹: 분기 규칙이 작동하는 전제 조건

투명 프록시는 트래픽 전달 경로 문제만 해결합니다. 프록시 규칙이 도메인 기준으로 정밀하게 분기되려면 DNS 계층의 협조도 필요합니다. 기기가 통신사 DNS에 직접 질의하면 실제 IP를 받아오게 되어, mihomo는 IP 대역이나 GeoIP 규칙으로만 대략적으로 판단할 수밖에 없고, 도메인 단위의 세밀한 규칙(예: 사이트별로 다른 프록시 그룹에 분기)은 작동하지 않습니다. 해결 방법은 공유기에서 LAN 내 모든 기기의 DNS 질의를 mihomo에 내장된 DNS 서버로 하이재킹해, mihomo가 직접 도메인 해석을 담당하고 그 결과와 규칙에 따라 해당 트래픽을 직결로 보낼지 프록시로 보낼지 판단하게 하는 것입니다.

이 과정은 OpenWrt에서 보통 dnsmasq 설정을 수정하거나 방화벽 규칙으로 53번 포트 질의를 mihomo의 DNS 리스닝 포트로 강제 전달하는 방식으로 구현합니다. mihomo 설정 파일에서 대응하는 필드로는 DNS 서버 주소, fake-ip 모드 활성화 여부 등이 있습니다. fake-ip는 도메인 분기의 정확도를 한층 높여주지만, 실제 IP가 필요한 일부 상황(예: 특정 LAN 내부 서비스 디스커버리 프로토콜)에서는 호환성 문제가 생길 수 있으므로 실제 사용 환경에 맞춰 취사선택해야 합니다.

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 223.5.5.5
    - 119.29.29.29

위는 mihomo 설정 파일 중 DNS 섹션의 단순화된 예시이며, 실제 배포 시에는 fake-ip 제외 범위, 국내 도메인 직결 목록 등의 필드를 더 세밀하게 조정해야 합니다. 각 필드의 구체적인 의미는 개념 정리 페이지에서 자세한 설명을 확인할 수 있습니다.

부팅 시 자동 실행 및 안정적인 운영 설정

공유기와 데스크톱 PC의 사용 시나리오는 다릅니다. 공유기는 거의 24시간 항상 켜져 있으며, 정전이나 재부팅 후에는 프록시 서비스가 자동으로 복구되어야 하고 사람이 직접 개입할 것을 기대할 수 없습니다. OpenWrt에서 mihomo의 부팅 자동 실행을 설정하려면 일반적으로 /etc/init.d/ 아래에 procd 규격에 맞는 시작 스크립트를 작성하고 service mihomo enable로 시스템 서비스에 등록해, 펌웨어 재부팅 후 프로세스가 자동으로 다시 올라오게 합니다. 서브 라우터 방식에서 범용 리눅스 배포판을 사용하는 경우에는 보통 systemd로 해당 .service 파일을 작성하고 Restart=on-failure를 설정해 프로세스가 비정상 종료되면 자동으로 재시작되도록 합니다.

부팅 자동 실행 외에도 장기적인 안정 운영을 위해 고려할 세부 사항이 몇 가지 있습니다. 구독 업데이트에 정기 작업이 설정되어 있는지, 로그 파일이 무한히 늘어나 저장 공간을 다 채우지는 않는지, 메모리 사용량이 실행 시간에 따라 계속 늘어나는지(일부 구버전 커널에서 메모리 누수가 발견된 적이 있으므로 커널을 최신 버전으로 유지하는 것을 권장) 등입니다. 서브 라우터처럼 독립적인 소형 PC를 쓰는 경우에는 워치독 스크립트를 구성해 mihomo 프로세스 상태를 주기적으로 점검하고, 비정상 상태가 감지되면 자동으로 다시 실행하도록 하는 것도 권장됩니다. 심야에 서비스가 다운되었는데 아무도 모르는 상태로 방치되면 다음날 아침 집 안 모든 기기에서 인터넷 이상을 겪게 됩니다.

데스크톱 클라이언트 방식과의 선택 기준

공유기 방식과 데스크톱 클라이언트 방식은 서로를 대체하는 관계가 아니라, 상황에 맞게 함께 쓰는 것이 더 적합합니다. 집에 프록시가 필요한 기기가 한두 대뿐이라면 데스크톱 클라이언트(Clash Verge Rev나 FlClash 등)를 설치해 그래픽 인터페이스로 설정하는 것이 몇 분 안에 끝나며, 명령줄이나 펌웨어를 건드릴 필요가 없습니다. 하지만 집에 기기 종류와 수가 많고, 특히 TV 셋톱박스, 게임기, 스마트 스피커처럼 클라이언트를 직접 설치할 수 없는 기기까지 분기 규칙을 적용해야 한다면, 공유기 방식이 모든 기기를 한 번에 커버할 수 있는 유일한 방법입니다.

또 하나 고려할 점은 유지보수 비용입니다. 데스크톱 클라이언트는 업데이트할 때 새 버전을 다운로드해서 재설치하면 끝이지만, 공유기의 커널 업그레이드는 대개 바이너리 파일을 직접 교체하거나 펌웨어 패키지를 다시 플래싱해야 해서 작업 경로가 더 번거롭고, 문제가 생겼을 때 원인을 찾기도 더 어렵습니다. 일반 사용자가 운영 중인 공유기에서 큰 변경을 하기 전에는 테스트 환경이나 예비 기기에서 먼저 검증해 보는 것이 좋습니다. 대다수 가정 사용자에게 더 현실적인 조합은, 주력 기기에는 데스크톱 클라이언트를 설치해 유연성과 빠른 업데이트를 확보하고, 집 안에 여러 기기를 통일된 분기로 처리해야 하는 실질적인 필요가 있을 때만 서브 라우터를 별도로 구성해 그 역할을 맡기는 것입니다. 둘은 양자택일이 아니라 상호 보완 관계입니다.

규칙과 설정은 어디서 가져오나

공유기의 mihomo든 데스크톱 클라이언트든, 규칙셋과 정책 그룹, 구독 링크의 작성 방식은 동일한 mihomo 설정 문법을 따르며 공유기 전용의 별도 형식은 없습니다. 즉 데스크톱 클라이언트에서 이미 정상 작동을 확인한 설정 파일을 이론적으로 그대로 공유기의 mihomo 인스턴스로 가져와 쓸 수 있으며, 투명 프록시 포트나 DNS 리스닝 주소처럼 공유기 환경에만 필요한 몇 가지 필드만 추가하면 됩니다. 정책 그룹이나 규칙 분류 개념을 처음 접한다면, 먼저 데스크톱 클라이언트에서 설정 로직을 정리한 뒤 공유기 환경으로 옮기는 것을 권장합니다. 그러면 문제가 발생했을 때 규칙 작성 오류인지 공유기 경로 설정 문제인지 훨씬 쉽게 판단할 수 있습니다.