플랫폼 예상 읽기 시간 15분

라우터에서 직접 실행하는 mihomo 커널 배포 가이드: 메인 라우터·보조 라우터·투명 프록시 선택

라우터와 보조 라우터에서 mihomo를 직접 실행하는 방법을 정리합니다. 펌웨어·하드웨어 요구 사항, 메인 라우터와 보조 라우터 구성, 투명 프록시 흐름과 적합한 사용 사례를 살펴봅니다.

먼저 목표부터 정하기: 라우터 프록시로 해결할 문제

mihomo를 라우터에 설치한다고 해서 데스크톱 클라이언트를 다른 장치로 옮기는 것은 아닙니다. 핵심은 프록시 진입점을 로컬 네트워크 게이트웨이로 앞당기는 데 있습니다. 휴대폰, TV, 게임기, 스마트 기기의 트래픽이 먼저 게이트웨이에 도착하면, 게이트웨이가 대상 도메인·IP, 출발 장치, 프로토콜 유형에 따라 DIRECT, REJECT 또는 특정 프록시 그룹을 선택합니다. 단말은 일반 네트워크 설정을 그대로 사용하고, 트래픽 분기 로직은 라우터에 집중됩니다.

이 구성은 장치가 많거나 일부 장치에 클라이언트를 설치할 수 없고, 규칙을 통합 관리하거나 출발 장치별로 트래픽을 나누어야 하는 네트워크에 적합합니다. 예를 들어 TV는 스트리밍 노드, 업무용 PC는 고정 출구, 프린터와 NAS는 항상 직접 연결, 게스트 네트워크는 프록시를 완전히 우회하도록 설정할 수 있습니다. 규칙을 한 곳에서 관리하므로 장치마다 따로 수정할 필요가 없습니다.

라우터 투명 프록시는 장애 영향 범위도 넓힙니다. mihomo 설정 로드 실패, DNS 업스트림 접근 불가, 정책 라우팅 손실, 방화벽 규칙 순서 오류가 발생하면 여러 장치가 동시에 인터넷에 연결되지 않을 수 있습니다. 따라서 배포 전에 세 가지를 명확히 정하세요. 프록시가 필요한 장치, 반드시 지원해야 할 프로토콜, mihomo가 중지됐을 때 자동으로 직접 연결을 허용할지 여부입니다. 목표에 따라 메인 라우터, 보조 라우터, 투명 프록시 구성의 선택도 달라집니다.

펌웨어·아키텍처·하드웨어 요구 사항

라우터 모델보다 먼저 CPU 아키텍처 확인하기

mihomo는 여러 아키텍처용 Linux 커널 파일을 제공합니다. 일반적인 x86 소프트 라우터는 x86_64, 최신 ARM 라우터는 대개 aarch64, 일부 구형 장치는 armv7 또는 mipsle입니다. 잘못된 아키텍처를 다운로드하면 실행 파일이 보통 Exec format error를 바로 출력합니다. SSH로 다음 명령을 실행해 확인할 수 있습니다:

uname -m
cat /etc/openwrt_release
ubus call system board
df -h
free -m

아래 내용은 OpenWrt 24.10.0, Linux 6.6, mihomo 1.19.3에서 일반적으로 제공되는 기능을 기준으로 합니다. 모든 펌웨어에 동일한 모듈이 포함된다는 뜻은 아닙니다. 서드파티 펌웨어는 커널, nftables, DNS 서비스, 시작 관리 방식을 변경할 수 있으므로 실제 배포 시에는 장치에서 출력되는 명령 결과를 기준으로 판단해야 합니다.

규칙 세트를 위한 메모리와 저장 공간 확보

mihomo 커널과 작은 YAML 설정 파일 하나만 실행하면 리소스 요구량은 높지 않습니다. 하지만 GeoIP, GeoSite, 규칙 세트, Fake-IP 매핑, 연결 테이블, 관리 패널이 추가되면 메모리 사용량이 계속 늘어납니다. 하드웨어 계획은 다음 범위에서 시작할 수 있습니다:

장치 리소스 적합한 환경 배포 판단
메모리 128MB, 플래시 16MB 소규모 규칙, 적은 장치 수 공간이 부족하고 업그레이드·롤백이 어렵습니다. 가정 전체의 투명 프록시에는 권장하지 않습니다.
메모리 256MB, 저장 공간 128MB 장치 10~20대, 일반적인 규칙 세트 실행 가능하지만 로그 수준과 규칙 세트 수를 제어해야 합니다.
메모리 512MB 이상 TUN, 대규모 규칙 세트, 다수 장치 동시 연결 유지 관리에 필요한 여유 공간을 확보하기 좋습니다.
x86_64, 메모리 1GB 이상 기가비트 회선, 컨테이너, 복잡한 정책 메인 라우터 또는 독립 게이트웨이에 적합합니다.

저장 공간은 mihomo 실행 파일만 기준으로 계산하면 안 됩니다. 설정, 실행 로그, 규칙 데이터베이스, 업데이트 중 생성되는 임시 파일에도 공간이 필요합니다. 최소 50MB의 쓰기 가능 공간을 남겨 두고, 규칙 데이터와 로그를 로컬에 저장한다면 100MB 이상을 확보하는 편이 안전합니다. 플래시 공간이 부족하면 데이터 디렉터리를 마운트한 디스크로 옮길 수 있지만, 시작 스크립트는 마운트가 완료될 때까지 기다려야 합니다.

처리량은 단일 코어 성능·프로토콜·암호화에 좌우됩니다

라우터 포장에 적힌 ‘기가비트’는 대개 하드웨어 NAT 환경에서의 전달 속도를 의미하며, 프록시 처리량과 같지 않습니다. 투명 프록시를 사용하면 트래픽이 사용자 공간으로 들어오고, 프로토콜 암호화·규칙 매칭·연결 재사용에 CPU가 사용됩니다. 일반 NAT에서 940Mbps를 처리하는 쿼드코어 ARM 장치라도, 암호화 노드를 거치는 mihomo 연결에서 같은 속도를 낸다는 보장은 없습니다.

테스트할 때는 최소한 세 가지 수치를 기록하세요. 직접 연결 속도, 단말 클라이언트 속도, 라우터 투명 프록시 속도입니다. 또한 top에서 특정 코어가 100%에 가까워지는지도 확인해야 합니다. 투명 프록시가 180Mbps에 그치지만 단말 클라이언트는 600Mbps에 도달한다면, 병목은 대개 라우터 CPU·가상 네트워크 인터페이스 처리·프로토콜 구현에 있으며 구독 노드 자체의 문제가 아닙니다.

메인 라우터에서 직접 실행: 경로는 짧고 장애 범위는 넓다

메인 라우터 배포는 가장 단순한 구조입니다. 메인 라우터가 전화 접속 또는 상위 회선 연결, DHCP, DNS, 방화벽, NAT, mihomo를 모두 담당합니다. 모든 단말의 기본 게이트웨이가 메인 라우터를 가리키므로 별도로 다음 홉을 변경하지 않아도 트래픽이 자연스럽게 프록시 규칙을 통과합니다.

단말 장치
  ↓ 기본 게이트웨이
메인 라우터: DHCP / DNS / 방화벽
  ↓ 투명 프록시 규칙
mihomo: 규칙 매칭
  ├─ DIRECT → WAN
  ├─ REJECT → 폐기
  └─ 프록시 그룹 → 원격 노드 → 대상 사이트

메인 라우터 구성의 장점

  • 네트워크 토폴로지가 단순하고 기본 게이트웨이가 하나뿐입니다.
  • 소스 IP, MAC 주소 매핑, 게스트 네트워크 인터페이스를 식별하기 쉽습니다.
  • DNS 가로채기, IPv4 정책 라우팅, 방화벽 규칙을 한 곳에서 관리할 수 있습니다.
  • 단말끼리 NAS, 프린터, 화면 미러링 장치에 접근할 때 경로를 더 쉽게 제어할 수 있습니다.

메인 라우터 구성의 비용

  • 설정 오류가 전체 네트워크에 영향을 주므로 복구 작업은 프록시를 우회할 수 있어야 합니다.
  • 펌웨어를 업그레이드하면 사용자 지정 방화벽 규칙이나 패키지가 초기화될 수 있습니다.
  • 메인 라우터 CPU가 PPPoE, SQM, Wi-Fi, NAT, 프록시를 동시에 처리하므로 리소스 경쟁이 더 뚜렷합니다.
  • 일부 하드웨어 NAT, 트래픽 오프로딩, 소프트웨어 오프로딩이 투명 프록시 체인을 우회할 수 있으므로 비활성화하거나 다시 검증해야 합니다.

메인 라우터에서 직접 실행하기로 했다면 관리용 진입점 하나 이상을 남겨 두세요. LAN에서만 접근할 수 있는 SSH 경로를 유지하거나 관리용 PC에 고정 주소를 설정하고, mihomo 중지·정책 라우팅 정리·DNS 복구 명령을 준비할 수 있습니다. 관리 도메인, 라우터 자체의 업데이트 트래픽, 프록시 노드 주소를 다시 프록시로 보내지 마세요. 루프가 발생하기 쉽습니다.

보조 라우터 배포: 변경은 적지만 반환 경로를 계산해야 한다

보조 라우터는 보통 메인 라우터의 LAN에 연결된 독립 장치입니다. 전화 접속을 담당하지 않을 수도 있고, 전체 네트워크의 DHCP를 인계하지 않을 수도 있습니다. mihomo는 보조 라우터에서 실행되며, 선택한 단말의 기본 게이트웨이나 정책상 다음 홉을 보조 라우터로 지정합니다. 그러면 보조 라우터가 메인 라우터를 통해 인터넷으로 트래픽을 전달합니다.

테스트 PC 192.168.10.50
  ↓ 게이트웨이 192.168.10.2
보조 라우터 192.168.10.2: mihomo
  ↓ 상위 게이트웨이 192.168.10.1
메인 라우터 192.168.10.1
  ↓
인터넷

구성 1: 단말에서 보조 라우터 게이트웨이를 수동 지정

가장 문제를 추적하기 쉬운 보조 라우터 방식입니다. 메인 라우터 주소를 192.168.10.1, 보조 라우터 주소를 192.168.10.2로 설정하고 테스트 PC의 기본 게이트웨이를 192.168.10.2로 변경합니다. 보조 라우터 자체의 기본 경로는 계속 192.168.10.1을 가리킵니다. 테스트에 실패하면 PC의 게이트웨이만 메인 라우터로 되돌리면 됩니다.

DNS는 먼저 보조 라우터 주소로 명시적으로 설정하고, mihomo DNS가 정상인지 확인한 뒤 DHCP로 배포하세요. 보조 라우터는 IPv4 전달을 활성화하고 LAN 트래픽이 수신 인터페이스에서 메인 라우터로 전달되도록 허용해야 합니다. 두 장치가 같은 서브넷에 있다면 반환 경로가 보조 라우터를 우회하지 않는지 특히 확인하세요. 웹 페이지가 열리는지만으로는 투명 프록시가 완전히 작동한다고 판단할 수 없습니다.

구성 2: 메인 라우터에서 장치별로 다른 게이트웨이 배포

DHCP 옵션이나 정책 라우팅을 지원하는 메인 라우터라면 MAC 주소에 따라 지정한 장치에 보조 라우터 게이트웨이를 배포할 수 있습니다. TV나 휴대폰에 정적 주소를 직접 입력하지 않아도 됩니다. 설정할 때는 보조 라우터에 고정 임대 주소를 지정해 주소가 바뀌지 않도록 하세요. DNS를 누가 배포하는지도 명확히 해야 합니다. 게이트웨이는 보조 라우터를 가리키지만 DNS는 계속 공용 리졸버를 가리키면 도메인 규칙이 작동하지 않거나 DNS 경로가 노출될 수 있습니다.

보조 라우터에서 자주 발생하는 루프 오류

가장 전형적인 문제는 보조 라우터의 프록시 연결 자체가 투명 프록시 규칙에 다시 포착되는 것입니다. mihomo가 원격 노드에 연결할 때 데이터가 다시 mihomo로 들어가 결국 타임아웃됩니다. 처리 방법으로는 프로세스 ID 기준 우회, 방화벽 마크 기준 우회, 노드 서버 IP를 직접 연결 목록에 추가, 라우터 자체 트래픽과 전달 트래픽을 서로 다른 체인으로 분리하는 방법이 있습니다.

또 다른 문제는 메인 라우터가 반환 패킷을 단말에 직접 전달하는 반면, 나가는 경로는 보조 라우터를 거치는 경우입니다. 일반 TCP는 때때로 작동하지만 연결 추적, 소스 주소 변환, TProxy 마크에 의존하는 흐름은 어긋날 수 있습니다. 보다 안정적인 방법은 보조 라우터에서 필요한 SNAT를 수행하거나, 독립 서브넷으로 상·하위 네트워크를 명확히 분리해 동일 서브넷의 비대칭 라우팅을 피하는 것입니다.

투명 프록시를 구현하는 세 가지 경로

투명 프록시는 단일 스위치가 아닙니다. Linux 라우터에서 흔히 사용하는 방식은 Redirect, TProxy, TUN입니다. 세 방식 모두 단말 트래픽을 mihomo로 전달할 수 있지만 지원 프로토콜, 라우팅 방식, 문제 해결의 핵심이 서로 다릅니다.

Redirect: 먼저 TCP부터 연결할 때 적합

Redirect는 보통 NAT 규칙으로 TCP 연결을 mihomo의 redir-port로 리디렉션합니다. 설정 예시는 다음과 같습니다:

redir-port: 7892
allow-lan: true
bind-address: "*"
mode: rule
log-level: info

개념이 단순해 HTTP, HTTPS 및 대부분의 TCP 애플리케이션을 검증하기 좋습니다. 제한도 분명합니다. UDP는 TCP Redirect만으로 완전히 처리할 수 없습니다. QUIC, 일부 게임, 음성 통화, UDP 기반 DNS에는 추가 구성이 필요합니다. 웹 접속만 검증한다면 Redirect가 합리적인 시작점이지만, 전체 네트워크를 인계하려면 보통 TProxy나 TUN을 추가해야 합니다.

TProxy: 대상 주소를 유지하면서 TCP·UDP 지원

TProxy는 정책 라우팅, 패킷 마크, 방화벽 투명 프록시 대상 기능을 사용해 TCP와 UDP를 mihomo의 tproxy-port로 전달합니다. 커널에 해당 투명 프록시 모듈이 필요하며, OpenWrt에서는 nftables 또는 iptables 규칙이 현재 방화벽 체계와 맞는지도 확인해야 합니다.

tproxy-port: 7893
mixed-port: 7890
allow-lan: true
mode: rule

TProxy의 핵심은 포트 규칙 하나가 아닙니다. 패킷에 먼저 마크를 지정한 다음 ip rule이 전용 라우팅 테이블을 선택하고, 대상 트래픽을 로컬 투명 프록시 포트로 되돌립니다. 방화벽 규칙만 작성하고 정책 라우팅을 빠뜨리면 연결이 바로 실패합니다. 프록시 노드 IP, 로컬 네트워크 대역, 예약 주소를 미리 우회하지 않으면 루프가 발생하거나 로컬 서비스 연결이 끊길 수 있습니다.

TProxy를 점검할 때는 수신 대기 포트, nftables 카운터, 정책 규칙, 라우팅 테이블 순서로 확인할 수 있습니다:

ss -lntup
nft list ruleset
ip rule show
ip route show table all
conntrack -L | head

TUN: 더 완전한 트래픽 인계, 더 많은 라우팅 충돌

mihomo의 TUN 모드는 가상 네트워크 인터페이스를 생성하고 매칭된 트래픽을 사용자 공간 프로토콜 스택으로 전달합니다. 일반적으로 TCP와 UDP를 통합 처리할 수 있으며, 서로 다른 Linux 환경에서 설정을 재사용하기도 쉽습니다. 간단한 예시는 다음과 같습니다:

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-redirect: true
  strict-route: true
  dns-hijack:
    - any:53

dns:
  enable: true
  enhanced-mode: fake-ip
  listen: 0.0.0.0:1053

auto-route와 auto-redirect가 예상대로 작동하는지는 운영체제, mihomo 버전, 방화벽 환경에 따라 달라집니다. 다중 WAN, VPN, WireGuard, 정책 라우팅, 컨테이너 네트워크가 이미 구성된 장치에서는 자동으로 추가된 경로가 기존 규칙과 충돌할 수 있습니다. 배포 전에 ip rule, ip route, nft list ruleset 출력을 저장해 비교할 수 있도록 하세요.

TUN도 성능을 보장하지는 않습니다. 사용자 공간 네트워크 스택, GRO, MTU, UDP 처리가 모두 처리량에 영향을 줍니다. 특정 사이트가 로딩 중간에 멈춘다면 경로 MTU를 확인해 보세요. PPPoE 인터페이스의 MTU는 흔히 1492이며, 터널을 추가하면 실제 사용 가능한 값은 더 낮아집니다. 패킷 캡처 근거 없이 TUN MTU를 지나치게 큰 값이나 작은 값으로 임의 조정하지 마세요.

DNS가 도메인 규칙 매칭을 결정한다

투명 프록시에서 가장 과소평가되기 쉬운 부분은 DNS입니다. 규칙에 DOMAIN-SUFFIX를 작성했다고 해서 라우터가 연결에 대응하는 도메인을 반드시 알아내는 것은 아닙니다. 단말이 외부 DNS에 직접 접속하거나 암호화 DNS를 사용하거나, 대상 IP만 투명 프록시에 전달하면 도메인 규칙의 매칭률이 떨어집니다.

Fake-IP 트래픽 흐름

  1. 단말이 라우터에 도메인을 조회합니다.
  2. mihomo DNS가 Fake-IP 주소를 반환하고 도메인 매핑을 저장합니다.
  3. 단말이 해당 Fake-IP에 연결합니다.
  4. 투명 프록시가 연결을 가로채고 mihomo가 매핑에서 원래 도메인을 복원합니다.
  5. 규칙 엔진이 도메인에 따라 DIRECT, REJECT 또는 프록시 그룹을 선택합니다.

Fake-IP는 도메인 기반 분기가 필요한 네트워크에 적합하지만, 로컬 네트워크 도메인, 프린터 검색, 일부 게임과 특수 앱은 필터 목록에 추가해야 할 수 있습니다. 라우터 관리 도메인, 로컬 도메인 접미사, 사설 주소 조회는 우선 로컬 DNS가 처리하도록 하고 원격 프록시로 보내지 마세요.

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "router.lan"
  nameserver:
    - 223.5.5.5
  proxy-server-nameserver:
    - 1.1.1.1

proxy-server-nameserver는 프록시 노드 서버 도메인을 조회하는 데 사용됩니다. 프록시가 아직 연결되지 않은 상태에서도 이 조회 체인이 작동해야 합니다. 그렇지 않으면 노드 연결을 위해 먼저 DNS 조회가 필요하고, DNS 조회를 위해 먼저 노드 연결이 필요한 의존성 루프가 발생합니다. 실제 설정은 사용 중인 네트워크에서 접근 가능한 업스트림을 기준으로 정해야 하며, 주소를 기계적으로 복사해서는 안 됩니다.

53번 포트가 처리할 수 있는 범위

기존 DNS는 UDP 또는 TCP 53을 사용하므로 라우터에서 mihomo DNS로 리디렉션할 수 있습니다. 예를 들어 로컬 1053으로 전달하는 방식입니다. 하지만 DoH는 HTTPS를 사용하고 DoT는 일반적으로 TCP 853을 사용하므로 53번 포트 규칙 하나만으로는 인계할 수 없습니다. 단말에서 시스템 수준의 암호화 DNS를 활성화했다면 장치 관리로 비활성화하거나, 알려진 엔드포인트를 규칙으로 제한하거나, 해당 장치가 도메인 보강 해석에 참여하지 않는 것을 받아들여야 합니다.

규칙 설계: 먼저 우회한 뒤 인계하기

라우터 규칙의 최우선 과제는 더 많은 트래픽을 프록시로 보내는 것이 아니라, 어떤 트래픽이 절대 프록시에 들어가면 안 되는지 명확히 하는 것입니다. 로컬 네트워크 주소, 멀티캐스트, 브로드캐스트, DHCP, 라우터 관리 주소, 프록시 노드 서버, 필수 시간 동기화 트래픽은 먼저 우회해야 합니다. 그렇지 않으면 장치 검색, 화면 미러링, NAS 접근, 노드 자체 연결이 손상될 수 있습니다.

rules:
  - IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,224.0.0.0/4,DIRECT,no-resolve
  - DOMAIN-SUFFIX,lan,DIRECT
  - DOMAIN-SUFFIX,local,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,Fallback

출발 장치별 분기는 소스 IP 대역으로 구현할 수 있습니다. 예를 들어 TV에 192.168.10.60을 고정하고 게스트 네트워크에는 192.168.30.0/24를 사용한 뒤 출발지에 따라 정책을 선택합니다. 동적 주소에 의존하는 것보다 고정 임대가 안정적입니다. 규칙은 위에서 아래로 매칭되므로 로컬 네트워크 우회 규칙을 출발 장치 프록시 규칙보다 앞에 배치해야 합니다.

IPv6는 별도로 결정해야 합니다. IPv4만 인계하고 IPv6는 직접 연결로 남겨 두면 애플리케이션이 AAAA 레코드를 우선 사용해 규칙이 간헐적으로 작동하는 것처럼 보일 수 있습니다. 선택지는 세 가지입니다. IPv6 투명 프록시를 완전히 구성하거나, 테스트 단계에서 관리 대상 단말에 IPv6 기본 경로를 배포하지 않거나, IPv6 직접 연결을 명시적으로 허용하고 보안 경계에 포함하는 것입니다. mihomo 설정에 ipv6: false만 작성한 채 단말이 라우터를 통해 공인 IPv6를 계속 받도록 두지 마세요.

롤백 가능한 배포 순서

  1. 현재 상태를 기록합니다. 메인 라우터 주소, DHCP 범위, DNS, 기본 경로, 방화벽 규칙, 기존 VPN 설정을 저장합니다.
  2. 바이너리를 검증합니다. SSH에서 mihomo -v를 실행해 아키텍처가 올바른지 확인한 다음 mihomo -t -d /etc/mihomo로 설정을 검사합니다.
  3. 관리 포트만 엽니다. 먼저 mixed-port: 7890을 실행하고 테스트 PC에서 HTTP 또는 SOCKS5 프록시를 수동 설정해 노드와 규칙이 작동하는지 확인합니다.
  4. DNS를 연결합니다. 테스트 장치 한 대의 DNS를 라우터로 지정하고 nslookup 또는 dig로 응답을 확인합니다.
  5. 투명 프록시를 추가합니다. 우선 테스트 장치의 소스 IP만 처리하고 다른 장치는 일시적으로 직접 연결 상태로 둡니다.
  6. TCP·UDP·로컬 서비스를 테스트합니다. 웹, 동영상, 음성 통화, 게임, NAS, 프린터, 화면 미러링을 확인하세요. 속도 테스트 한 번만 실행해서는 안 됩니다.
  7. 시작과 롤백을 구성합니다. mihomo 시작에 실패했을 때 강제 리디렉션 규칙을 계속 유지하지 마세요. 서비스를 중지하면 일반 전달이 복구되어야 합니다.
  8. 범위를 단계적으로 넓힙니다. 장치 한 대에서 VLAN 하나로 확장하고, 마지막에 전체 네트워크 인계를 검토합니다.

디버깅 단계에서는 실행 로그를 info로 설정하고, 규칙을 추적할 때만 잠시 debug를 사용할 수 있습니다. 로그 수준을 장기간 높게 유지하면 저장 장치 쓰기와 CPU 부담이 증가합니다. 안정화 후에는 로그 순환을 설정하고 메모리, 연결 수, 프로세스 재시작 횟수를 정기적으로 확인하세요.

라우터에 적합한 환경과 단말에 남겨야 할 환경

라우터에 배치하기 적합한 경우

  • TV, 게임기, 스마트 기기에 프록시 클라이언트를 설치할 수 없습니다.
  • 가정이나 소규모 사무실에서 규칙과 구독을 통합 관리해야 합니다.
  • 장치, VLAN 또는 출발지 네트워크 대역에 따라 서로 다른 정책을 선택해야 합니다.
  • 라우터 하드웨어 성능이 충분하고 안정적인 SSH 관리 경로가 있습니다.
  • 관리자가 DHCP, DNS, 라우팅 테이블, nftables, 연결 추적을 이해합니다.

단말 클라이언트를 계속 사용하는 편이 좋은 경우

  • 프록시가 필요한 PC가 한두 대뿐이고 다른 장치는 모두 직접 연결합니다.
  • 메인 라우터가 통신사 장비라 소프트웨어를 설치하거나 방화벽 규칙을 확인할 수 없습니다.
  • 네트워크가 기업 VPN, 복잡한 다중 WAN, 엄격한 단말 인증에 의존합니다.
  • 설정을 자주 전환해야 하고 장애가 한 대의 장치에만 영향을 주길 원합니다.
  • 라우터의 메모리, 저장 공간 또는 단일 코어 성능이 이미 한계에 가깝습니다.

실제 배포에서는 둘 중 하나만 선택할 필요가 없습니다. 라우터는 TV, 게스트 네트워크, 클라이언트를 설치할 수 없는 장치만 담당하고 개발 PC에서는 데스크톱 클라이언트를 계속 실행하는 조합이 흔합니다. 이렇게 하면 장치별 제어를 유지하면서도 모든 복잡한 정책을 하나의 게이트웨이에 집중하지 않을 수 있습니다.

최종 판단은 한 문장으로 정리할 수 있습니다. 메인 라우터는 단순한 토폴로지를, 보조 라우터는 통제 가능한 변경을, TProxy는 Linux 네이티브 투명 전달을, TUN은 통합 인계 기능을 추구합니다. 선택할 때는 기능 수보다 먼저 장애 범위를 확인하세요. 빠르게 비활성화할 수 있고, DNS를 복구할 수 있으며, 노드 루프를 우회할 수 있는 구성이 장기 운영에 적합합니다.

클라이언트 설정 계속하기

먼저 PC에서 구독, 노드, 규칙을 검증한 다음 동일한 트래픽 분기 로직을 라우터로 옮길지 결정하세요.

다운로드 페이지로 이동 튜토리얼 보기
Clash 다운로드