2026-09-17 네트워크 구성 예상 읽기 시간 14분

OpenWrt 보조 라우터에서 Clash 코어 직접 실행하기: 투명 프록시 구성과 게이트웨이·DNS 설정

OpenWrt 보조 라우터에서 Clash 코어를 직접 실행하는 방법과 TProxy·Redir의 차이, LAN 기기의 게이트웨이 설정, DNS 처리 방법을 알아봅니다.

구성 시 유의점: 코어 실행만으로 투명 프록시가 작동하지는 않습니다

OpenWrt에서 Clash 계열 코어를 직접 실행하려면 프로세스, 트래픽 진입 경로, DNS를 각각 설정해야 합니다. 프로세스가 정상적으로 시작됐다는 것은 설정 파일을 불러왔다는 뜻일 뿐입니다. 클라이언트 트래픽이 보조 라우터를 거쳐 방화벽을 통해 투명 프록시 포트로 전달되어야 합니다. 이 글에서는 mihomo를 예로 들어 세 단계가 어떻게 연결되는지 살펴봅니다.

프로세스: 기기 아키텍처에 맞는 바이너리를 사용하고, 설정 파일은 /etc/mihomo/config.yaml에 저장합니다. 서비스는 OpenWrt의 procd로 관리합니다.
포워딩: 클라이언트의 기본 게이트웨이를 보조 라우터로 지정하고, 보조 라우터에서 일반 트래픽을 메인 라우터로 전달할 수 있어야 합니다.
트래픽 처리: 방화벽에서 프록시할 연결을 선별하고, DNS는 명확하게 구성된 로컬 해석 경로를 사용합니다.

기기에 프록시 관리 플러그인이 설치되어 있다면 코어 실행, 설정 파일 생성, 방화벽 규칙 적용을 플러그인이 담당하는지 먼저 확인하세요. 같은 라우터에서 별도의 트래픽 처리 설정을 수동으로 추가하면 포트 충돌, 중복 리디렉션, 설정 덮어쓰기 문제가 생길 수 있습니다. 코어 직접 실행과 관리 플러그인 중 하나를 제어 방식으로 명확히 선택하세요.

네트워크 구성: 먼저 기기 한 대의 트래픽을 보조 라우터로 보내기

아래 주소는 단일 네트워크 인터페이스와 동일 서브넷을 사용하는 보조 라우터 구성을 설명하기 위한 예시입니다. 실제 설정에서는 현재 네트워크 대역에 맞게 바꾸세요. 메인 라우터는 인터넷 연결과 DHCP를 계속 담당하고, 보조 라우터에는 고정 주소를 지정합니다. 테스트 PC의 게이트웨이와 DNS만 별도로 변경합니다.

기기 또는 항목	예시 값	용도
LAN 서브넷	`192.168.10.0/24`	세 기기가 동일한 IPv4 서브넷에 있습니다
메인 라우터	`192.168.10.1`	인터넷 게이트웨이, 기존 DHCP 서비스
OpenWrt 보조 라우터	`192.168.10.2`	고정 주소 사용, 기본 경로는 메인 라우터를 가리킴
테스트 PC	`192.168.10.100/24`	사용하지 않거나 예약된 주소 사용
PC 기본 게이트웨이	`192.168.10.2`	외부 연결이 먼저 보조 라우터를 거치도록 설정
PC DNS	`192.168.10.2`	일반 DNS 요청이 먼저 보조 라우터로 가도록 설정

OpenWrt 인터페이스 및 포워딩 확인

LuCI에서 「네트워크」→「인터페이스」→「LAN」→「편집」으로 이동해 고정 주소를 확인합니다. 테마에 따라 메뉴 이름이 조금 다를 수 있으므로 인터페이스, IPv4 주소, 게이트웨이 항목을 기준으로 확인하세요. 메인 라우터 주소를 보조 라우터의 기본 게이트웨이로 잘못 입력하지 않도록 주의합니다.

ip -4 addr show
ip -4 route show
sysctl net.ipv4.ip_forward
ping -c 3 192.168.10.1

라우팅 테이블에 192.168.10.1을 가리키는 기본 경로가 있어야 하며, 포워딩 설정은 1이어야 합니다. 해당 인터페이스 간 포워딩을 방화벽에서 허용하는지도 확인하세요. 단일 인터페이스 구성에서는 트래픽이 같은 LAN 인터페이스로 들어왔다가 나갈 수 있으므로, LAN→WAN 규칙을 그대로 적용하는 것만으로는 충분하지 않습니다.

같은 서브넷에서 포워딩할 때는 응답 경로도 고려해야 합니다. 보조 라우터를 통해 나간 연결이 메인 라우터에서 PC로 직접 돌아올 수 있습니다. 비대칭 경로, ICMP 리디렉션, 연결 추적 정책 등이 결과에 영향을 줄 수 있습니다. 일부 네트워크 구성에서는 소스 NAT를 사용해 응답 트래픽이 보조 라우터를 다시 거치게 할 수 있지만, 원래 클라이언트 주소가 가려집니다. 무조건 켜 두기보다는 실제 라우팅과 방화벽 구성을 확인한 뒤 결정하세요.

코어 파일: 아키텍처, 설정 디렉터리, 실행 인자 확인

먼저 uname -m으로 하드웨어 아키텍처를 확인하고, ubus call system board로 시스템 정보를 확인합니다. 아키텍처 이름이 비슷해도 바이너리가 반드시 호환되는 것은 아닙니다. CPU 명령어 집합과 배포 파일의 실행 요구 사항도 확인하세요. 데스크톱 클라이언트 설치 파일을 라우터 코어로 실행하지 마세요.

uname -m
ubus call system board
df -h /overlay
free -m

기기에 충분한 영구 저장 공간과 메모리가 있는지 확인하세요. 규칙 세트, 지리 데이터베이스, 연결 수에 따라 자원 사용량이 늘어나므로 모든 설정에 적용되는 고정 메모리 기준은 없습니다. 재부팅하면 비워지는 /tmp에 설정 파일을 유일하게 저장하지 마세요.

아래 명령은 기기에 맞는 mihomo 바이너리를 확보해 /usr/bin/mihomo에 저장하고, 전체 YAML 설정 파일을 지정된 디렉터리에 배치한 상태를 가정합니다. 먼저 설정을 테스트한 뒤 서비스를 시작하세요:

mkdir -p /etc/mihomo
chmod 0755 /usr/bin/mihomo
chmod 0600 /etc/mihomo/config.yaml
/usr/bin/mihomo -v
/usr/bin/mihomo -t -d /etc/mihomo -f /etc/mihomo/config.yaml

-v는 실제 사용 중인 코어 버전을 확인하는 옵션이고, -t는 설정을 검사하는 옵션입니다. 로그에 규칙 파일이나 데이터베이스 누락, 다운로드 실패가 표시되면 해당 리소스를 먼저 준비하세요. 설정 테스트에 통과해도 원격 노드를 사용할 수 있다고 보장되지 않으며, 방화벽을 통한 트래픽 처리까지 완료된 것은 아닙니다.

Redir, TProxy, TUN: 트래픽 유형에 맞는 진입 방식 선택

방식	처리 범위	필요한 설정
Redir	주로 TCP 리디렉션에 사용	`redir-port` 설정 및 NAT 리디렉션 규칙 적용
TProxy	TCP와 UDP 모두 처리 가능	`tproxy-port` 설정, 투명 프록시 규칙·트래픽 마킹·정책 라우팅 구성
TUN	가상 네트워크 인터페이스를 통해 IP 트래픽 처리	커널의 TUN 지원, 라우팅 및 DNS 설정 확인, 자동 라우팅의 적용 범위 지정

이 글에서는 Redir와 TProxy를 중심으로 설명합니다. Redir의 TCP 진입 방식은 일반적인 UDP 처리 기능을 대신할 수 없습니다. Redir만 설정하면 QUIC, 게임, 음성 앱의 UDP 트래픽이 자동으로 프록시를 거치지 않습니다. TProxy로 UDP를 처리할 수 있더라도 선택한 노드 프로토콜과 서버가 해당 포워딩을 지원해야 합니다.

mihomo 포트 설정 예시

아래는 기존 설정에 합쳐 사용하는 예시이며, 단독으로 프록시를 구성할 수 있는 구독 설정이 아닙니다. 기존 노드, 정책 그룹, 규칙을 유지하고 YAML 최상위에 같은 이름의 키를 중복 정의하지 마세요. 두 투명 프록시 포트를 동시에 열 수는 있지만, 각 트래픽은 명확한 하나의 방화벽 경로로 처리해야 합니다.

mode: rule
log-level: info
redir-port: 7892
tproxy-port: 7893

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: redir-host
  nameserver:
    - 223.5.5.5

여기서는 동작을 확인하기 쉬운 시작점으로 redir-host를 사용해 DNS가 실제 IP 주소를 반환하도록 합니다. 223.5.5.5는 업스트림 DNS 예시이므로 현재 위치에서의 연결 가능성과 필요한 해석 방식에 따라 선택하고, 직접 연결되는지 확인하세요. 도메인 기반 분기에 필요한 DNS 처리 방식, 노드 도메인 해석, 암호화 DNS는 기본 연결이 안정된 뒤 각각 구성합니다.

fake-ip로 전환한다면 클라이언트에서 가상 주소 대역으로 향하는 연결도 코어가 처리하도록 해야 하며, 앱 호환성에 맞춰 필터 항목도 설정해야 합니다. DNS 모드만 바꾸고 가상 주소 트래픽이 보조 라우터를 우회하게 두지 마세요.

방화벽 설정: firewall4와 기존 규칙 체계 구분하기

먼저 아래 읽기 전용 명령을 실행해 기기에서 사용하는 방화벽 도구를 확인하세요. OpenWrt 22.03부터 기본 방화벽은 firewall4와 nftables로 전환됐지만, 실제 기기에는 다른 펌웨어가 설치됐거나 설정이 수정됐을 수 있으므로 기기에서 확인한 결과를 기준으로 삼아야 합니다.

command -v fw4
command -v nft
command -v iptables
nft list ruleset
ip -4 rule show
ip -4 route show table all

인터넷에서 찾은 iptables 트래픽 처리 스크립트를 firewall4 설정에 그대로 넣지 마세요. 호환 명령이 있더라도 규칙이 실제로 어느 규칙 세트에 추가되는지, 방화벽을 다시 불러온 뒤에도 유지되는지 확인해야 합니다. TProxy에는 관련 커널 모듈과 사용자 공간 표현식 지원도 필요하므로 포트만 열어 두는 것으로는 충분하지 않습니다.

트래픽 처리 규칙에서 확인할 네 가지

출발지 제한: 처음에는 테스트 PC 192.168.10.100만 대상으로 지정하세요. LAN 전체를 바로 처리하거나 WAN에서 들어오는 모든 트래픽을 대상으로 삼지 마세요.
예외를 먼저 지정한 뒤 처리: 로컬 관리 주소, LAN 내부 목적지, 필요한 브로드캐스트 및 멀티캐스트 트래픽은 예외로 둡니다. IPv4와 IPv6의 예외 범위는 각각 설계해야 합니다.
진입 경로 일치: TCP Redir는 7892로, TProxy는 7893으로 전달합니다. 트래픽 마킹과 일치하는 정책 라우팅도 설정해 표시된 트래픽이 로컬로 전달되도록 해야 합니다.
루프 방지: 코어가 노드, DNS, 직접 연결 대상에 보내는 트래픽이 같은 처리 규칙에 다시 들어오지 않도록 해야 합니다. 라우터 자체의 OUTPUT 트래픽 처리는 별도로 설계하세요.

일반적인 TProxy 구성은 fwmark, ip rule, 라우팅 테이블의 로컬 경로를 함께 사용합니다. 마크 값, 마스크, 규칙 우선순위, 라우팅 테이블 번호는 기존 VPN이나 정책 라우팅 플러그인과 충돌하지 않도록 정해야 합니다. 모든 기기에 안전하게 적용할 수 있는 고정 번호는 없으므로, 실제 네트워크에 그대로 적용할 수 있는 전체 규칙을 제시하지 않습니다.

처음 테스트할 때는 관련 트래픽 오프로드를 끄고 규칙 카운터를 확인하세요. 하드웨어 또는 소프트웨어 오프로드가 후속 패킷의 경로를 바꿀 수 있습니다. 첫 연결이 성공했다는 이유만으로 모든 트래픽이 올바르게 처리된다고 판단하지 마세요.

DNS 처리: dnsmasq의 53 포트 요청을 코어의 1053 포트로 전달

먼저 dnsmasq가 LAN의 53 포트를 계속 담당하게 하고, mihomo는 루프백 주소 127.0.0.1:1053에서만 수신하도록 설정하는 것이 좋습니다. 이렇게 하면 두 프로세스가 같은 주소와 포트를 놓고 충돌하지 않으며, 코어의 DNS 포트를 LAN에 직접 노출할 필요도 없습니다.

「네트워크」→「DHCP/DNS」에서 DNS 전달 설정을 찾아 127.0.0.1#1053을 추가합니다. 이 형식은 dnsmasq 서버 포트 표기법이며 YAML 표기법이 아닙니다.
다른 포워딩 서버와 resolv 파일의 적용 경로도 확인하세요. DNS 질의가 mihomo만 거치게 하려면 상위 resolv 파일에서 다른 서버를 읽어 오는 경로를 비활성화해 로컬 포워딩과 병렬로 처리되지 않도록 합니다.
mihomo의 업스트림 DNS가 보조 라우터 자체의 53 포트가 아닌지 확인하세요. 그렇지 않으면 “dnsmasq → mihomo → dnsmasq” 형태의 DNS 루프가 발생합니다.
서비스를 다시 불러온 뒤 테스트 PC에서 nslookup example.com 192.168.10.2를 실행하고, 코어 로그와 DNS 수신 상태도 확인하세요.

PC의 DNS 항목에는 192.168.10.2만 입력하고 192.168.10.2:1053은 입력하지 마세요. 일반적인 운영체제 DNS 설정은 포트 지정 형식을 지원하지 않습니다. DHCP의 DNS 옵션도 서버 주소만 배포합니다.

dnsmasq와 코어에서 모두 캐시를 사용한다면 설정 변경 후 이전 기록이 남을 수 있습니다. 우선 서버를 명시한 질의로 확인한 뒤 클라이언트 캐시를 비우세요. 캐시에서 응답이 반환된 것을 새 DNS 경로가 적용된 것으로 오해하지 마세요.

procd 자동 시작: 프로세스를 먼저 관리하고 트래픽 처리 규칙 설정하기

코어를 직접 실행할 때는 OpenWrt의 procd로 관리할 수 있습니다. 아래 내용을 /etc/init.d/mihomo에 저장하세요. 최소한의 프로세스 서비스 예시로, 방화벽 규칙을 자동 설치하거나 클라이언트 게이트웨이를 변경하지는 않습니다.

#!/bin/sh /etc/rc.common

USE_PROCD=1
START=99
STOP=10

start_service() {
    procd_open_instance
    procd_set_param command /usr/bin/mihomo \
        -d /etc/mihomo \
        -f /etc/mihomo/config.yaml
    procd_set_param respawn 3600 5 5
    procd_set_param stdout 1
    procd_set_param stderr 1
    procd_close_instance
}

chmod 0755 /etc/init.d/mihomo
/etc/init.d/mihomo enable
/etc/init.d/mihomo start
logread -e mihomo
netstat -lnptu

수신 목록에서 7892, 7893, 127.0.0.1:1053을 확인하세요. 사용할 수 있는 명령은 펌웨어에 포함된 도구에 따라 다릅니다. netstat이 필요한 옵션을 지원하지 않으면 설치된 ss -lnptu로 확인할 수 있습니다. 관리 API를 공용 네트워크 인터페이스에서 수신하도록 설정하지 마세요.

예시 서비스는 시스템 기본 권한으로 시작합니다. 투명 프록시와 라우팅 작업에는 권한이 필요하므로 설정 파일과 서비스 스크립트는 관리자만 수정할 수 있어야 합니다. 방화벽 규칙은 현재 방화벽 체계에 맞는 방식으로 영구 적용하고, 서비스를 중지할 때 트래픽 처리를 해제하는 방법도 명확히 정하세요. 그렇지 않으면 코어가 종료된 뒤에도 클라이언트 트래픽이 수신 프로세스가 없는 포트로 전달될 수 있습니다.

검증 순서: 라우팅, DNS, 트래픽 처리, 원격 연결을 단계별로 확인

기본 라우팅부터 확인: 투명 프록시를 활성화하기 전에 테스트 PC의 게이트웨이를 보조 라우터로 설정해도 인터넷에 정상적으로 연결되는지 확인합니다. 연결되지 않으면 먼저 포워딩과 응답 경로를 점검하세요.
다음은 DNS 확인: 192.168.10.2를 지정해 직접 질의합니다. 시간 초과가 발생하면 dnsmasq, 1053 포트 수신 여부, DNS 루프를 먼저 확인하세요. 주소가 반환되어도 해당 웹사이트에 연결할 수 있다는 뜻은 아닙니다.
다음은 TCP 처리 확인: 테스트 PC에서 HTTPS 사이트에 접속하고 관련 방화벽 카운터와 mihomo 연결 로그를 확인해 출발지 주소, 일치한 규칙, 최종 정책이 예상과 같은지 살펴봅니다.
UDP는 따로 확인: 실제로 UDP를 사용하는 앱을 실행하고 TProxy 카운터와 연결 로그를 확인하세요. 일반 웹페이지가 열린다고 해서 UDP 프록시도 작동한다고 볼 수는 없습니다.
IPv4·IPv6 모두 확인: IPv4와 IPv6를 각각 테스트합니다. IPv6가 여전히 메인 라우터를 통해 직접 나간다면 IPv6 처리, DNS 배포, 방화벽 정책을 명확히 설계하세요. 듀얼 스택 동작을 간헐적인 오류로 치부하지 마세요.
마지막으로 재적용 및 재부팅 확인: 방화벽 재적용, 코어 재시작, 기기 전체 재부팅을 테스트해 중복 규칙이 없는지, DNS가 복구되는지, 코어 중지 후 되돌릴 방법이 마련되어 있는지 확인하세요.

노드를 바꾸기보다 증상에 맞춰 원인 찾기

게이트웨이 변경 후 인터넷이 전혀 안 됨: 구독 설정을 의심하기 전에 IP 포워딩, 방화벽 포워딩, 메인 라우터 출구, 응답 경로부터 확인하세요.
IP 주소에는 연결되지만 도메인이 열리지 않음: PC가 실제 사용하는 DNS, dnsmasq 업스트림, 코어 DNS 로그, 브라우저 보안 DNS를 확인하세요.
웹은 되지만 일부 앱이 작동하지 않음: UDP, IPv6, 규칙 일치 여부, 원격 프로토콜 지원을 확인하고 트래픽이 처리되지 않은 경우와 처리 후 연결에 실패한 경우를 구분하세요.
라우터 자체에서만 연결되지 않음: OUTPUT 규칙과 코어 자체 트래픽의 예외 처리를 확인해 프록시의 아웃바운드 연결이 다시 처리되지 않도록 하세요.
재부팅 후 작동하지 않음: 서비스가 활성화되어 있는지, 필요한 파일이 영구 디렉터리에 있는지, 방화벽이 관련 규칙을 다시 불러왔는지 확인하세요.

전체 네트워크에 적용하기 전에 기기 한 대의 검증 결과를 기록하세요. 주소, 게이트웨이, DNS, 투명 프록시 포트, 적용된 정책, 재부팅 결과가 포함되어야 합니다. 안정성을 확인한 뒤 DHCP를 변경하세요. 임대 갱신이 항상 즉시 이뤄지는 것은 아니며 기기에 따라 연결을 끊었다가 다시 연결해야 할 수 있습니다. 설정을 되돌릴 때는 먼저 클라이언트의 게이트웨이와 DNS를 메인 라우터 및 기존 값으로 복구하고, 투명 프록시 규칙을 해제한 다음 코어를 중지하세요. 그래야 전체 네트워크가 사용할 수 없는 경로에 남는 일을 막을 수 있습니다.