라우터에서 Clash 코어 실행: 정책 라우터 배포 방법과 리소스 요구 사항

라우터에서 Clash 또는 mihomo 코어를 실행하는 핵심 목적은 데스크톱 클라이언트 화면을 네트워크 장비로 옮기는 것이 아니라, 라우터가 규칙 매칭, DNS 처리와 트래픽 전달을 중앙에서 수행하도록 하는 데 있습니다. TV, 게임 콘솔, 모바일 기기처럼 클라이언트를 설치하기 어려운 단말도 게이트웨이 또는 정책 라우팅을 통해 동일한 규칙을 적용할 수 있습니다. 동시에 라우터는 전달 경로의 핵심 노드가 되므로 설정 오류가 전체 LAN에 영향을 줄 수 있습니다. 배포 전에 토폴로지, 복구 경로와 장치 부하를 반드시 확인해야 합니다.

여기서 말하는 “라우터에서 Clash 실행”은 주로 OpenWrt, 파생 시스템 또는 범용 Linux 게이트웨이에서 Clash 호환 코어를 실행하는 것을 뜻합니다. 현재는 mihomo가 대표적인 구현이며 Clash 설정 구조를 이어받고 TUN, 규칙 집합, 트래픽 스니핑 등의 확장 기능을 제공합니다. 관리 플러그인은 설정 파일, 서비스 스크립트와 방화벽 규칙을 추상화하지만, 하위 단계에는 여전히 세 가지 과정이 필요합니다. 코어가 포트를 수신하고, 시스템이 대상 트래픽을 코어로 보내며, 코어가 규칙에 따라 직접 연결 또는 프록시 출구를 선택하는 과정입니다.

메인 라우터와 정책 라우터의 아키텍처 선택

메인 라우터에서 직접 코어 실행

메인 라우터 방식은 인터넷 접속, DHCP, NAT와 무선 접속을 담당하는 장비에서 Clash 코어도 함께 실행하는 구성입니다. 단말 트래픽이 자연스럽게 이 장비를 통과하므로 전달 경로가 가장 짧고 DNS를 일괄적으로 관리하기도 쉽습니다. 하드웨어 성능이 충분하고 시스템을 유지 관리할 수 있으며 방화벽 규칙에 익숙한 사용자에게 적합합니다. 상위 인터페이스는 통신사 네트워크에 연결되고 하위 인터페이스는 LAN에 연결되며, 프록시 프로그램은 방화벽이 넘긴 트래픽만 처리하면 됩니다.

가장 큰 대가는 장애 영향 범위가 넓다는 점입니다. 코어가 메모리를 모두 사용하거나 방화벽 규칙 로드에 실패하거나 DNS 서비스 포트가 충돌하면 인터넷 접속, LAN 이름 해석과 관리 페이지가 동시에 영향을 받을 수 있습니다. 시스템 업그레이드로 nftables, iptables 또는 플러그인이 규칙을 생성하는 방식이 바뀔 수도 있습니다. 따라서 메인 라우터 배포는 직렬 콘솔, 복구 모드 또는 예비 장비로 네트워크를 복구할 수 있는 환경에 더 적합하며, 유일한 가정용 인터넷 출구에서 첫 실험을 진행하는 것은 피해야 합니다.

독립 게이트웨이로 사용하는 정책 라우터

정책 라우터 방식은 기존 메인 라우터가 인터넷 접속과 기본 네트워크를 계속 담당하도록 두고, Clash 코어를 별도 장비에서 실행합니다. 가장 흔한 단일 NIC 정책 라우터는 메인 라우터와 같은 LAN에 배치됩니다. 예를 들어 메인 라우터 주소가 192.168.1.1이고 정책 라우터 주소가 192.168.1.2인 경우, 프록시 규칙을 적용할 단말의 기본 게이트웨이를 192.168.1.2로 지정합니다. 정책 라우터가 정책 처리를 마치면 트래픽을 메인 라우터로 전달합니다.

이 구성은 단계적인 이전에 유리합니다. 먼저 테스트 컴퓨터 한 대의 게이트웨이와 DNS만 변경해 규칙, UDP와 도메인 해석을 확인한 뒤 DHCP를 통해 더 많은 장치에 정책 라우터를 배포할 수 있습니다. 정책 라우터가 중지되면 단말의 게이트웨이를 메인 라우터로 되돌리면 되므로 광대역 접속 설정을 바꿀 필요가 없습니다. 유지 관리 범위도 명확합니다. 메인 라우터는 기본 연결을 보장하고 정책 라우터는 투명 프록시와 추가 정책을 담당합니다.

단일 NIC 정책 라우터는 게이트웨이 주소 하나만 입력하면 끝나는 구성이 아닙니다. 정책 라우터가 패킷을 직접 전달하면서 소스 주소 변환을 하지 않으면 반환 트래픽이 메인 라우터에서 바로 클라이언트로 전달될 수 있습니다. 이 경우 나가는 경로는 정책 라우터를 거치지만 돌아오는 경로는 우회하는 비대칭 경로가 됩니다. 실제 문제 발생 여부는 투명 프록시 방식, 연결 추적과 메인 라우터의 라우팅 테이블에 따라 달라집니다. 일반적인 해결 방법은 정책 라우터 출구에서 적절한 NAT를 수행하거나, 메인 라우터에 클라이언트 네트워크로 향하는 명확한 경로를 추가해 왕복 경로를 설계대로 맞추는 것입니다.

듀얼 NIC 정책 게이트웨이

독립된 네트워크 포트 두 개를 갖춘 장비는 직렬 게이트웨이로도 배포할 수 있습니다. 한 인터페이스는 메인 라우터에 연결하고 다른 인터페이스는 별도의 하위 스위치 또는 무선 액세스 포인트에 연결합니다. 정책 라우터는 하위 네트워크를 별도로 구성하고 해당 네트워크의 DHCP, 전달과 프록시 처리를 담당합니다. 단일 NIC 구성보다 상위·하위 네트워크의 경계가 명확하고 반환 트래픽도 자연스럽게 정책 라우터를 거치므로 전체 서브넷에 정책을 적용하기 쉽습니다.

대신 네트워크 계층이 늘어납니다. 포트 매핑, LAN 검색, 화면 공유와 서브넷 간 접근을 추가로 처리해야 하며, 메인 라우터와 정책 라우터가 모두 NAT를 수행하면 이중 NAT가 발생합니다. 가정용 장치가 mDNS 또는 브로드캐스트 검색에 의존한다면 릴레이 서비스가 필요한지 검토해야 합니다. 모든 서브넷 간 문제를 Clash 코어 탓으로 돌려서는 안 됩니다.

CPU, 메모리와 저장 공간 요구 사항

Clash 코어의 실제 하드웨어 요구 사항은 처리량, 규칙 규모, 연결 수, 프로토콜 암호화 부하와 TUN 사용 여부에 따라 달라집니다. 코어가 실행된다는 사실만으로 장비의 적합성을 판단할 수 없습니다. 라우터는 시스템 서비스, DNS 캐시, 방화벽 연결 추적과 관리 페이지에도 리소스를 남겨야 합니다. 메모리가 고갈되면 단순한 속도 저하보다 서비스 재시작이나 시스템 응답 중단이 더 진단하기 어려운 경우가 많습니다.

프로세서와 암호화 처리량

CPU는 규칙 매칭, 암호화 전송과 사용자 공간 전달의 한계를 결정합니다. 구형 싱글 코어 MIPS 장비도 간단한 규칙과 적은 연결은 처리할 수 있지만, 고속 인터넷, 여러 단말 또는 복잡한 프로토콜에서는 병목이 되기 쉽습니다. 최신 ARM64 또는 x86_64 플랫폼은 mihomo를 지속적으로 실행하기에 일반적으로 더 적합합니다. 코어 파일을 선택할 때는 시스템 아키텍처가 일치해야 하며, 대표적인 표기는 arm64, armv7, mipsle와 amd64입니다. 아키텍처가 잘못되면 프로그램이 실행 불가 오류를 바로 보고하는 경우가 많습니다.

하드웨어 NAT 또는 트래픽 오프로딩은 투명 프록시에 필요한 방화벽 체인을 우회할 수 있습니다. 프록시를 활성화한 뒤 속도가 비정상적으로 떨어지면 먼저 소프트웨어 오프로딩, 하드웨어 오프로딩과 투명 프록시 플러그인의 호환성을 확인하세요. 인터페이스 속도를 모두 끌어올리기 전에 유선 단말 한 대로 직접 연결, 규칙 기반 프록시와 UDP 세 가지 트래픽을 테스트하고 CPU 단일 코어 사용률이 지속적으로 한계에 가까운지 관찰해야 합니다.

메모리와 규칙 규모

메모리 64MB 장비는 대개 매우 간소한 시스템과 소형 설정에만 적합합니다. 대규모 도메인 규칙, GeoIP 데이터, 관리 패널과 여러 추가 서비스를 함께 로드하면 여유가 거의 없습니다. 128MB는 기본 배포의 출발점이 될 수 있지만 규칙 집합과 동시 실행 서비스를 여전히 제한해야 합니다. 256MB 이상이면 mihomo, DNS 강화 모드, 대규모 규칙 집합과 Web 관리 페이지를 함께 실행하기에 더 적합합니다. 연결 수가 많거나 규칙 제공자가 자주 업데이트되거나 트래픽 스니핑을 활성화한다면 더 많은 여유 공간을 확보해야 합니다.

Swap은 순간적인 메모리 압력을 완화할 수 있지만 플래시 저장 장치의 교환 속도는 느리며 충분한 물리 메모리를 대신할 수도 없습니다. 코어가 주기적으로 종료된다면 먼저 시스템 로그에서 메모리 회수 또는 프로세스 종료 기록이 있는지 확인한 뒤 규칙을 줄이거나 사용하지 않는 서비스를 끄거나 리소스가 더 많은 장비로 이전하세요.

저장 공간과 쓰기 정책

코어 본체, GeoIP 데이터, 규칙 집합, 구독 캐시와 로그가 모두 저장 공간을 사용합니다. 라우터의 내장 플래시가 작다면 데이터 디렉터리를 확장 저장 장치나 외장 디스크로 옮길 수 있지만, 서비스 시작 순서에서 마운트 지점이 먼저 준비되어야 합니다. 로그 수준을 장기간 debug로 유지해서는 안 됩니다. 상세 로그는 짧은 시간 문제를 추적할 때 유용하지만 계속 기록하면 공간을 차지하고 느린 플래시의 쓰기 부담도 늘어납니다.

투명 프록시, TUN과 DNS 전달 경로

라우터 배포에서 가장 혼동하기 쉬운 부분은 “코어가 실행 중”인 것과 “LAN 트래픽이 코어로 들어간다”는 것이 다르다는 점입니다. mixed-port, HTTP 포트 또는 SOCKS 포트는 수신 진입점일 뿐이며 단말에 프록시를 직접 입력할 때 사용합니다. 프록시를 설정하지 않은 장치도 규칙에 따라 자동 전달하려면 REDIRECT, TProxy 또는 TUN 같은 트래픽 가로채기 방식과 해당 방화벽 및 정책 라우팅이 필요합니다.

REDIRECT와 TProxy

REDIRECT는 TCP 연결을 가로채는 데 자주 사용되며 설정이 비교적 간단하지만 UDP와 원래 대상 주소를 보존해야 하는 경우에는 제한이 있습니다. TProxy는 TCP와 UDP를 처리하고 정책 라우팅을 통해 투명 트래픽을 코어의 수신 포트로 보낼 수 있습니다. 방화벽 마크, 정책 라우팅 테이블과 관련 커널 모듈에 의존하므로 어느 한 단계라도 빠지면 TCP만 작동하고 UDP가 타임아웃되거나 LAN 접근이 잘못 전달될 수 있습니다.

방화벽 규칙에서는 장치 자체의 관리 주소, LAN 예약 대역, 멀티캐스트, 브로드캐스트와 프록시 서버 자체의 연결을 제외해야 합니다. 그렇지 않으면 코어가 만든 외부 연결이 다시 투명 규칙에 포착되는 프록시 루프가 발생해 연결 실패 또는 CPU 사용률 상승으로 이어질 수 있습니다. 플러그인이 보통 이러한 제외 항목을 생성하지만 사용자 정의 스크립트에서는 대상 네트워크, 프로세스 또는 방화벽 마크를 항목별로 점검해야 합니다.

TUN 모드

TUN 모드는 가상 네트워크 인터페이스를 통해 IP 트래픽을 수신하므로 TCP, UDP와 복잡한 애플리케이션을 함께 처리해야 하는 환경에 더 일관된 방식입니다. mihomo의 TUN 설정에서는 자동 라우팅과 인터페이스 탐색을 활성화할 수 있지만, 라우터 플랫폼에는 이미 WAN, LAN, 정책 라우팅과 방화벽 영역이 존재합니다. 자동 생성된 경로가 기존 토폴로지와 맞지 않을 수 있으므로 기본 경로, TUN 라우팅 테이블과 LAN 전달 체인을 확인해야 합니다. 설정 파일의 문법이 통과했는지만 확인해서는 안 됩니다.

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

이 설정은 mihomo 측에서 TUN, 자동 라우팅과 DNS 가로채기 의도를 활성화한다는 의미일 뿐, 라우터 방화벽이 이미 LAN 트래픽의 TUN 진입을 허용한다는 뜻은 아닙니다. 펌웨어, 플러그인과 네트워크 관리 구성 요소에 따라 인터페이스 이름과 규칙 체인을 처리하는 방식이 다릅니다. 관리 플러그인이 이미 TUN 설정을 생성한다면 메인 설정에서 같은 내용을 중복 선언할 경우 설정이 덮어써지거나 라우팅이 중복될 수 있습니다.

DNS 요청 경로

규칙이 도메인에 의존한다면 DNS 경로도 프록시 정책과 일치해야 합니다. 일반적인 방법은 단말이 DNS 요청을 라우터로 보내고 dnsmasq 또는 다른 로컬 DNS 서비스가 mihomo의 DNS 수신 포트로 전달하도록 하는 것입니다. 또 다른 방법은 방화벽으로 LAN의 53번 포트 요청을 가로채는 방식입니다. 전자는 구조를 이해하기 쉽고 후자는 단말에 공용 DNS를 수동으로 입력한 경우도 처리할 수 있지만, 암호화 DNS 애플리케이션은 일반적인 53번 포트를 거치지 않습니다.

fake-ip 모드는 도메인에 예약 주소를 반환하고 코어가 매핑을 통해 원래 도메인을 복원하므로 도메인 규칙을 적용하기 쉽습니다. 일부 LAN 서비스, 게임 플랫폼 또는 실제 주소를 기준으로 판단하는 애플리케이션은 fake-ip-filter에 추가해야 할 수 있습니다. redir-host 모드는 기존 DNS에 더 가깝지만 매칭 효율과 특정 연결 과정이 다릅니다. 모드를 전환한 뒤에는 이전 해석 결과가 테스트에 영향을 주지 않도록 단말의 DNS 캐시를 삭제해야 합니다.

DNS 루프는 정책 라우터에서 흔히 발생하는 문제입니다. mihomo가 질의를 dnsmasq에 넘기고 dnsmasq가 다시 mihomo로 요청을 돌려보내는 방식입니다. 루프를 판단할 때는 두 서비스의 수신 포트와 상위 DNS 주소를 확인해 해석 경로가 한 방향으로만 이어지는지 확인하세요. 정책 라우터 자체의 질의, LAN 클라이언트의 질의와 프록시 노드 도메인 해석도 나누어 살펴봐야 합니다. 노드 도메인은 프록시 채널이 연결되기 전에 해석될 수 있어야 합니다.

IPv6도 빠뜨리지 마세요

IPv4만 가로채면 IPv6를 지원하는 단말이 메인 라우터에서 IPv6 기본 경로를 직접 받아 기존 정책을 우회할 수 있습니다. IPv6 전달과 규칙을 완전히 구성하거나, 초기 배포 단계에서 테스트 단말에 IPv6 경로를 배포하지 않는 방법을 사용할 수 있습니다. 최종 선택은 가정 네트워크의 요구 사항에 맞춰야 합니다. “같은 웹사이트가 어떤 때는 규칙을 따르고 어떤 때는 직접 연결되는” 문제를 조사할 때는 A와 AAAA 레코드, IPv4와 IPv6 기본 경로, 코어 설정의 IPv6 활성화 여부를 각각 확인해야 합니다.

정책 라우터 배포 단계와 검증 순서

1. 정책 라우터의 관리 주소를 고정합니다.

   메인 라우터와 같은 서브넷에 속하면서 DHCP 주소 풀과 충돌하지 않는 정적 주소를 정책 라우터에 설정하고, 기본 게이트웨이는 메인 라우터로 지정합니다. 먼저 정책 라우터 자체가 시간 동기화, 도메인 해석과 소프트웨어 저장소 접근을 할 수 있는지 확인하세요.

2. 아키텍처에 맞는 코어와 관리 구성 요소를 설치합니다.

   CPU 아키텍처, 시스템 libc 환경과 사용 가능한 저장 공간을 확인합니다. 먼저 코어를 직접 실행해 버전과 설정 로드 결과를 확인한 다음 서비스 스크립트로 관리하세요. 그래야 바이너리 호환성 문제를 방화벽 장애로 잘못 판단하지 않을 수 있습니다.

3. 설정을 가져오고 외부 연결을 확인합니다.

   구독으로 생성된 프록시 그룹, 규칙 제공자와 노드 프로토콜이 현재 코어에서 지원되는지 확인합니다. 먼저 명시적인 HTTP 또는 SOCKS 프록시를 통해 코어의 외부 연결을 테스트하세요. 이 단계가 성공한 뒤 투명 가로채기를 구성하면 노드 문제와 라우팅 문제를 분리할 수 있습니다.

4. IP 전달과 투명 프록시를 활성화합니다.

   플러그인 지원에 따라 TProxy 또는 TUN을 선택하고 LAN에서 WAN으로의 전달, 방화벽 영역과 정책 라우팅이 적용되었는지 확인합니다. 여러 투명 프록시 스크립트를 동시에 활성화하면 마크 또는 리디렉션이 중복될 수 있으므로 피해야 합니다.

5. 테스트 단말 한 대만 먼저 이전합니다.

   테스트 단말의 게이트웨이와 DNS를 수동으로 정책 라우터에 지정하고 LAN 접근, 직접 연결 웹사이트, 규칙 기반 프록시, 동영상, 음성 통화와 절전 모드 해제를 차례로 확인합니다. 안정성이 확인된 뒤 DHCP 배포 내용을 변경하세요.

6. 제외 및 그룹 정책을 설정합니다.

   프린터, NAS 관리 주소, 메인 라우터 페이지와 필요한 LAN 대역을 직접 연결 또는 우회 목록에 추가합니다. TV, 게임 콘솔과 게스트 장치는 소스 IP 또는 MAC에 연결된 고정 주소로 그룹화하면 어떤 단말이 프록시에 들어갈지 관리하기 쉽습니다.

7. 업데이트와 복구 방식을 설정합니다.

   구독과 규칙 집합 업데이트는 장치 부하가 높은 시간을 피해 실행하고, 마지막으로 정상 작동한 설정을 보관하세요. 서비스 시작에 실패하면 기본 설정으로 되돌릴 수 있어야 하며, 메인 라우터는 DHCP와 인터넷 출구를 계속 유지해야 합니다.

투명 프록시를 검증할 때 웹페이지 하나만 열어 보아서는 안 됩니다. 브라우저가 캐시, HTTP/3 또는 자체 보안 DNS를 사용할 수 있으므로 결과만으로 전체 경로가 올바르다고 판단하기 어렵습니다. 더 신뢰할 수 있는 순서는 단말이 받은 주소, 게이트웨이와 DNS를 확인하고, 정책 라우터가 연결을 수신했는지 확인한 뒤 규칙 적중과 외부 연결 선택을 점검하고 마지막으로 UDP, IPv6와 LAN 접근을 테스트하는 것입니다.

ip address
ip route
ip rule
nft list ruleset
logread
ss -lntup

이 명령은 인터페이스 주소, 라우팅 테이블, 정책 규칙, 방화벽 규칙, 시스템 로그와 수신 포트를 확인하는 데 사용합니다. iptables를 사용하는 시스템에서는 해당 규칙 테이블을 확인하도록 바꾸면 됩니다. 중요한 것은 명령을 한꺼번에 많이 복사하는 것이 아니라 데이터 경로를 따라 위치를 찾는 것입니다. 단말이 패킷을 정책 라우터로 넘겼는지, 방화벽이 마크 또는 리디렉션했는지, 코어가 수신했는지, 외부 트래픽이 메인 라우터로 향하는지를 차례로 확인하세요.

일반적인 장애와 유지 관리 범위

정책 라우터는 인터넷에 연결되지만 클라이언트는 연결되지 않음

먼저 클라이언트의 기본 게이트웨이가 실제로 정책 라우터를 가리키는지, 정책 라우터에서 IPv4 전달이 활성화되어 있는지 확인하세요. 이어서 LAN 전달 영역, NAT와 반환 경로를 점검합니다. 정책 라우터 자체의 접속 성공은 자체 OUTPUT 트래픽이 작동한다는 의미일 뿐, LAN에서 들어온 FORWARD 트래픽이 허용되었다는 뜻은 아닙니다.

웹페이지는 열리지만 게임 또는 음성 애플리케이션이 타임아웃됨

대개 UDP를 확인해야 하는 문제입니다. REDIRECT 구성은 TCP만 처리할 수 있고, TProxy에 필요한 모듈이나 정책 라우팅이 로드되지 않았을 수도 있습니다. 규칙이 UDP를 코어로 보내는지 확인하고 선택한 노드 프로토콜과 프록시 서버가 해당 UDP 트래픽을 지원하는지도 점검하세요. 특정 게임만 비정상이라면 NAT 유형, 포트 매핑과 게임 플랫폼의 지역 규칙도 확인해야 합니다.

활성화 후 LAN 장치에 접근할 수 없음

투명 프록시 제외 목록에서 사설 주소, 멀티캐스트 주소 또는 로컬 서비스 포트가 빠졌을 수 있습니다. 일반적인 LAN 대역과 라우터 관리 주소가 로컬 경로로 전달되는지 확인하세요. VLAN 또는 서브넷 간 접근에는 방화벽 영역도 확인해야 하며, 모든 사설 주소를 영구적으로 직접 연결로 처리해서는 안 됩니다. 프록시 리소스가 내부 네트워크에 있다면 실제 토폴로지에 맞는 정확한 규칙을 만들어야 합니다.

CPU 사용률은 높지만 처리량은 낮음

먼저 debug 로그를 끄고 단일 코어 부하를 관찰한 다음 직접 연결 규칙과 프록시 규칙의 속도를 비교하세요. 직접 연결도 뚜렷하게 느리다면 투명 전달로 하드웨어 오프로딩이 꺼졌거나 방화벽 체인에서 패킷이 중복 처리되는 것일 수 있습니다. 프록시 연결만 느리다면 암호화 프로토콜, 노드 경로와 MTU를 확인해야 합니다. TUN 환경에서 MTU가 맞지 않으면 단편화, 일부 웹사이트의 지연 또는 대용량 파일 연결 중단이 발생할 수 있습니다.

구독 업데이트 후 서비스가 시작되지 않음

일반적인 원인으로는 설정 필드와 코어 버전의 불일치, 규칙 제공자 다운로드 실패, YAML 들여쓰기 오류 또는 데이터 디렉터리 권한 변경이 있습니다. 유지 관리할 때는 “구독 원본”, “플러그인이 생성한 실행 설정”과 “코어가 실제로 로드한 설정”을 구분해야 합니다. 관리 플러그인이 템플릿을 병합하거나 포트를 덮어쓰거나 DNS 필드를 추가할 수 있으므로 구독 파일만 확인해서는 최종 오류를 찾지 못할 수 있습니다.

배포 결론: 먼저 경로를 정한 뒤 구성 요소를 선택하세요

라우터에서 Clash 코어를 실행할 때 어려운 점은 프로그램을 시작하는 데 있지 않고, 트래픽이 예상대로 들어오고 나가며 돌아오게 만드는 데 있습니다. 메인 라우터 방식은 경로가 간단하지만 유지 관리 위험이 집중됩니다. 단일 NIC 정책 라우터는 점진적인 테스트에 적합하지만 NAT와 반환 경로를 처리해야 합니다. 듀얼 NIC 게이트웨이는 경계가 명확한 대신 독립 서브넷과 서브넷 간 관리 비용이 발생합니다. 장비를 선택할 때는 CPU 아키텍처, 단일 코어 성능, 메모리 여유, 규칙 규모와 로그 저장 공간을 함께 고려해야 합니다.

실제 배포에서는 먼저 명시적 프록시로 코어와 노드를 검증한 뒤 투명 전달을 활성화하세요. 먼저 단말 한 대만 정책 라우터를 사용하게 한 다음 DHCP를 변경하고, 먼저 IPv4, TCP와 기본 DNS를 확인한 뒤 UDP, TUN과 IPv6를 테스트하세요. 데이터 경로를 계층별로 검증하면 구독, 코어, 방화벽, DNS와 LAN 토폴로지 문제를 각각 분리해 찾을 수 있으며, 설정 변경 후 영향 범위도 빠르게 파악할 수 있습니다.