라우터·보조 라우터에서 Xray 실행하기: 배포 방식, 하드웨어 요구 사항, 트래픽 분리

이 글의 핵심

라우터에 Xray를 설치하려면 커널 실행뿐 아니라 트래픽 전달, DNS, 장애 시 복구까지 함께 고려해야 합니다. 클라이언트에서 노드에 연결해 본 뒤 여러 LAN 기기에서 같은 출구를 사용하려는 분을 위한 안내입니다. 메인 라우터·보조 라우터·데스크톱 배포 방식을 비교하고, 하드웨어 계획, 단일 기기 검증 절차, 문제 해결 순서를 살펴봅니다. 커널을 실행했다고 해서 네트워크 전체의 프록시 설정이 끝난 것은 아닙니다.

1. Xray 코어와 라우터의 트래픽 전달 구분하기

Xray는 프록시 프로토콜, 인바운드, 아웃바운드, 라우팅 규칙을 처리하는 코어입니다. 라우터 펌웨어가 아니며 LAN 전체를 자동으로 설정하지도 않습니다. 라우터에 실행 파일을 넣고 시작하는 것은 여러 단계 중 하나일 뿐입니다. 단말에서 보낸 트래픽이 코어에 도달하는지는 게이트웨이, 시스템 포워딩, 방화벽 규칙, 인바운드 설정에 따라 달라집니다.

v2rayN은 데스크톱 클라이언트이고, v2rayNG는 Xray 코어를 사용하는 Android 클라이언트이며, v2flyNG는 V2Fly 코어를 사용합니다. 클라이언트의 구독 관리, 노드 목록, 연결 버튼은 Xray 실행 파일 하나를 라우터에 복사한다고 생기지 않습니다. 구독 텍스트도 일반적으로 Xray JSON 설정 파일로 바로 사용할 수 없습니다.

앱에서 프록시 직접 설정: 앱에 프록시 주소와 포트를 입력합니다. 적용 범위가 분명하고, 전체 LAN 트래픽을 처리할 필요 없이 노드 연결부터 확인할 수 있습니다.
투명 프록시: 게이트웨이 규칙으로 조건에 맞는 트래픽을 코어에 전달합니다. 단말마다 프록시를 설정하지 않아도 되지만, 라우터에서 포워딩·응답 경로·제외 규칙을 갖춰야 합니다.
DNS 분리: 각 DNS 조회를 어느 리졸버에 맡기고 어떤 출구로 보낼지 정합니다. 서비스 트래픽 분리와 관련은 있지만 같은 작업은 아닙니다.

2. 배포 위치: 데스크톱, 보조 라우터, 메인 라우터

배포 위치를 정하기 전에 적용할 기기 수와 프록시가 끊겼을 때 일반 인터넷 연결을 허용할지 확인하세요. 보조 라우터는 특정 소프트웨어가 아니라 네트워크에서 맡는 역할입니다. 별도의 기기가 일부 단말의 게이트웨이나 정책 기반 포워딩을 담당합니다. 독립형 미니 PC나 가상 머신으로 구성할 수 있으며, 가상 머신은 가상 네트워크 카드, 브리지 모드, 호스트 리소스 할당도 점검해야 합니다.

먼저 데스크톱에서 검증

권장

같은 노드와 네트워크로 먼저 v2rayN 연결을 확인하세요. 대상 서비스에 접속할 수 있으면 게이트웨이로 옮깁니다. 문제가 생겼을 때 노드 문제와 라우터의 트래픽 전달 문제를 구분하기 쉬워집니다.

적합한 경우: 첫 배포, PC 한 대에서 사용, 빠른 원상 복구가 필요한 경우

독립형 보조 라우터

메인 라우터의 PPPoE 연결과 일반 DHCP는 그대로 두고, 선택한 기기만 보조 라우터를 거치게 합니다. 단계적으로 테스트하기 좋지만 기본 게이트웨이, DNS, 응답 경로를 계획해야 합니다. 케이블만 연결했다고 적용된 것은 아닙니다.

적합한 경우: 여러 기기에서 같은 규칙 사용, 메인 라우터 변경 최소화

메인 라우터에서 직접 실행

한 기기에서 연결, 포워딩, DNS 조회, 프록시를 모두 처리하므로 경로가 단순해집니다. 반면 업데이트, 메모리 부족, 방화벽 규칙 오류가 모든 단말의 인터넷 연결에 영향을 줄 수 있습니다.

적합한 경우: 하드웨어 여유가 있고, 유지보수 시간과 복구 수단이 준비된 경우

단일 LAN 포트 보조 라우터는 유입·유출 트래픽이 같은 인터페이스를 사용할 수 있으므로 스위칭 경로와 응답 경로를 별도로 확인해야 합니다. 포트가 두 개라고 성능이 자동으로 높아지는 것도 아닙니다. 네트워크 카드 드라이버가 불안정하거나 CPU 단일 코어 성능이 부족하면 동시 연결이 많거나 규칙이 복잡할 때 병목이 생길 수 있습니다. 포트의 표기 속도를 프록시 처리량 보장으로 간주하지 마세요.

3. 하드웨어 요구 사항: 여유 리소스를 고려한 계획

모든 노드와 규칙 집합에 공통으로 적용되는 최소 사양은 없습니다. CPU 아키텍처에 따라 바이너리 실행 가능 여부가 결정되고, 메모리는 규칙과 연결 규모에 영향을 주며, 쓰기 가능한 저장 공간은 설치·업데이트·로그에 필요합니다. 아래 내용은 배포 계획을 위한 권장 사항이며 Xray의 공식 최소 사양이나 회선 속도를 전부 활용할 수 있다는 성능 보장이 아닙니다.

점검 항목	계획 기준	확인 방법
CPU 및 아키텍처	호환 빌드가 제공되는 ARM64 또는 x86-64 기기를 우선 선택	uname -m을 실행하고 시스템 ABI와 패키지 아키텍처를 대조
기기 전체 메모리	가벼운 테스트는 512 MiB부터 계획하고, 복잡한 규칙이나 추가 서비스에는 1 GiB 이상 고려	free -m의 available 값과 부하가 높은 시간대의 로그 확인
쓰기 가능한 공간	최소 256 MiB를 확보하고 업데이트 임시 파일과 데이터 파일 공간을 추가로 고려	df -h로 실제 설치 파티션을 확인하고 플래시 메모리의 표기 용량만 보지 않기
네트워크 인터페이스	회선 속도와 단일 포트·이중 포트 네트워크 구성에 맞춰 선택	일반 포워딩과 프록시 포워딩을 각각 테스트하고 CPU 사용률과 패킷 손실 비교
냉각 및 전원	지속적인 부하에서도 안정적으로 작동하는지 확인	온도, CPU 스로틀링, 재부팅, 네트워크 포트 연결 끊김 기록 확인

플래시 용량이 작은 기기에서는 코어보다 로그가 파티션을 먼저 가득 채워 장애를 일으킬 수 있습니다. 평소에는 필요한 오류 로그만 남기고, 문제 해결 시에만 로그 수준을 잠시 높이세요. 로그 순환을 설정하거나 메모리 로그를 사용할 수도 있습니다. 외장 저장 장치를 쓴다면 부팅 시 마운트 순서를 확인해 서비스 시작 시 설정 디렉터리를 사용할 수 없는 상황을 방지하세요.

결론: 실제 사용량으로 먼저 테스트

실제로 사용할 노드를 선택해 30분간 연속 실행하면서 웹 페이지 접속, 동영상 재생, DNS 조회를 함께 수행하세요. 가용 메모리, CPU 사용률, 온도를 기록합니다. 리소스 여유가 부족하면 하드웨어를 교체하기 전에 규칙과 추가 서비스를 줄여 보세요.

4. 보조 라우터 시험 운영: 단말 한 대씩 연결

아래 경로는 일반적인 OpenWrt LuCI 화면을 기준으로 하며 번역이나 버전에 따라 조금 다를 수 있습니다. 예시에서 메인 라우터는 192.168.10.1, 보조 라우터는 192.168.10.2, 테스트 단말은 192.168.10.100이며 서브넷 접두사 길이는 모두 /24입니다. 주소 계획 예시이므로 사용 전에 기존 네트워크 대역과 주소 사용 여부를 확인하세요.

기존 설정 백업

LuCI의 「시스템」→「백업/업그레이드」에서 설정을 백업하고 기존 게이트웨이와 DNS를 기록하세요. 메인 라우터를 게이트웨이로 사용하는 관리 기기 한 대를 남겨 두고, 유선 연결로 관리 페이지에 접속할 수 있는지 확인합니다.
관리 주소 고정

「네트워크」→「인터페이스」→「LAN」→「편집」→「일반 설정」에서 보조 라우터 주소를 192.168.10.2로 설정합니다. 선택한 단일 포트 구성에서는 보조 라우터의 상위 게이트웨이를 192.168.10.1로 지정하고, 해당 주소가 DHCP 동적 할당 범위에 포함되지 않는지 확인하세요.
주소 할당 확인

메인 라우터에서 주소를 일괄 할당한다면 보조 라우터의 「네트워크」→「인터페이스」→「LAN」→「편집」→「DHCP 서버」→「일반 설정」에서 「이 인터페이스 무시」를 선택합니다. IPv6 RA와 DHCPv6 설정도 확인해 계획하지 않은 두 번째 게이트웨이가 광고되지 않도록 하세요.
코어 설정 검증

아키텍처에 맞는 Xray와 실제 설정 파일을 준비하고, 프로세스를 시작하기 전에 설정을 테스트하세요. 먼저 앱에서 프록시를 직접 설정해 아웃바운드 연결을 확인한 뒤 선택한 구성에 따라 포워딩, 인바운드, 제외 규칙을 설정합니다. 이 단계에서는 전체 네트워크의 DHCP를 변경하지 마세요.
테스트 단말 전환

테스트 단말 한 대에서만 IPv4 게이트웨이를 192.168.10.2로 바꾸세요. 보조 라우터에서 DNS 서비스를 사용할 수 있을 때만 DNS도 해당 주소로 변경합니다. 로컬 관리 페이지, 직접 연결 서비스, 프록시 연결 서비스를 각각 확인한 다음 단계적으로 적용 범위를 넓히세요.

위의 주소 설정은 기본 네트워크 구성만 만드는 것이지 완전한 투명 프록시 규칙이 아닙니다. 같은 서브넷의 단일 포트 구성에서는 응답 경로가 비대칭이 될 수 있으며, 소스 주소 변환이 필요한지는 포워딩과 트래픽 전달 방식에 따라 달라집니다. 패킷 캡처, 연결 추적, 코어 요구 사항을 함께 확인하세요. 출처가 불분명한 방화벽 명령을 통째로 운영 게이트웨이에 붙여 넣지 마세요.

# 아래 명령은 점검용입니다. 경로는 실제 설치 위치에 맞게 조정하세요
uname -m
free -m
df -h
ip route
xray version
xray run -test -config /etc/xray/config.json

# OpenWrt에서 최근 시스템 로그 확인
logread | tail -n 80

# nftables를 사용하는 시스템에서 현재 규칙 확인
nft list ruleset

5. 투명 프록시와 DNS: 두 경로를 함께 설계하기

투명 프록시에는 보통 두 가지 경로가 있습니다. 서비스 연결이 어느 인바운드로 들어가는지, DNS 조회를 어느 리졸버에 맡기는지입니다. Linux의 REDIRECT와 TPROXY는 서로 같은 기능이 아닙니다. REDIRECT는 주로 TCP 리디렉션에 사용됩니다. TPROXY로 TCP와 UDP를 처리하려면 커널 지원, 트래픽 마킹, 정책 라우팅이 서로 맞물려야 합니다. 리디렉션 규칙 하나만 추가했다고 UDP까지 작동하는 것은 아닙니다.

트래픽 분리 규칙에는 매칭 순서와 기본 경로도 명확히 정해야 합니다. 도메인 기준으로 매칭한다면 코어가 도메인 정보를 얻을 수 있는지 고려하세요. 클라이언트가 대상 도메인을 이미 IP 주소로 변환했거나 앱에서 자체 암호화 DNS를 사용할 수 있습니다. 스니핑은 지원되는 트래픽에서 정보를 보완할 뿐 모든 연결의 원래 도메인을 복원해 주지는 않습니다.

DNS에서 일반적으로 사용하는 UDP/TCP 포트

10808

SOCKS 인바운드 포트 예시

12345

투명 프록시 인바운드 포트 예시

10808과 12345는 이 글의 구성 예시일 뿐 모든 클라이언트나 라우터 설정의 고정 기본값이 아닙니다. 포트 번호가 다르다는 것만으로 장애는 아닙니다. 방화벽의 대상 포트와 실제 인바운드 포트가 일치하면 됩니다. DNS의 53번 포트는 UDP와 TCP를 모두 고려해야 하며 한쪽 전송 방식만 처리해서는 안 됩니다.

기본 네트워크 트래픽은 제외: DHCP, 필요한 멀티캐스트·브로드캐스트, LAN 관리 주소, 코어 자체 연결은 프록시로 잘못 전달되지 않도록 제외하세요.
프록시 루프 방지: 노드 서버로 향하는 외부 연결은 일반 출구를 사용해야 하며, 투명 프록시 규칙에 다시 걸려 동일한 인바운드로 되돌아오면 안 됩니다. 노드 주소가 도메인이라면 주소 변경과 시작 시 이름 조회도 고려하세요.
DNS 역할 분리: LAN 호스트 이름은 일반적으로 로컬 리졸버에서 처리하고, 공용 도메인은 정책에 맞는 상위 DNS를 선택하세요. 리졸버 자체의 아웃바운드 경로도 계획에 맞아야 합니다.
IPv6 별도 점검: IPv4 트래픽만 처리하도록 설정하면 단말이 IPv6로 직접 연결할 수 있습니다. 듀얼 스택 정책을 완전히 설정하거나 테스트 범위에서 관련 IPv6 광고와 연결 경로를 명확히 비활성화하세요.
수신 범위 제한: LAN용 DNS 및 프록시 인바운드를 WAN에 직접 노출하지 마세요. 수신 주소와 방화벽 규칙으로 접속 출처를 제한하세요.

6. 자주 발생하는 문제: 게이트웨이, DNS, 아웃바운드 순서로 점검

문제를 해결할 때는 한 번에 조건 하나만 바꾸세요. 먼저 단말이 예상한 게이트웨이를 받았는지 확인하고, 다음으로 DNS 응답을 점검한 뒤 연결이 올바른 아웃바운드로 향하는지 확인합니다. 브라우저 새로고침만으로는 캐시, 연결 재사용, 앱 자체 DNS가 섞여 장애가 발생한 계층을 찾기 어렵습니다.

게이트웨이를 바꿨는데 왜 여전히 기존 출구를 사용하나요?

먼저 단말의 실제 라우팅 테이블과 IPv6 기본 경로를 확인해 이전 DHCP 임대나 RA가 여전히 메인 라우터를 가리키는지 살펴보세요. 그런 다음 보조 라우터의 트래픽 전달 규칙이 실제로 적용되는지 확인합니다. 기본 게이트웨이를 보조 라우터로 바꿨다는 사실만으로 트래픽이 Xray에 들어갔다고 볼 수는 없습니다.

IP 주소로는 연결되는데 도메인이 열리지 않나요?

nslookup을 지원하는 테스트 단말에서 nslookup example.com 192.168.10.2를 실행해 조회가 시간 초과되는지 확인하세요. 보조 라우터에서 DNS를 수신하지 않는다면 단말의 DNS를 해당 주소로 지정하지 마세요. DNS 서비스의 수신 주소, 53번 포트 규칙, 상위 DNS로 나가는 경로를 이어서 점검하세요.

웹은 되는데 게임이나 음성 통화가 안 되나요?

UDP가 예상한 인바운드로 들어가는지, 아웃바운드가 해당 트래픽 전달을 지원하는지, 정책 라우팅이 완성됐는지 확인하세요. TCP 웹 접속 성공이 UDP 성공을 뜻하지는 않습니다. 실제 앱과 로그로 검증해야 하며, TCP 지연 시간 테스트 한 번만으로 전체 경로가 정상이라고 판단해서는 안 됩니다.

재부팅 후 전체 네트워크가 끊겼다면 무엇부터 바꿔야 하나요?

먼저 테스트 단말의 게이트웨이와 DNS를 기존 값으로 되돌린 뒤 남겨 둔 관리 기기로 로그인하세요. 코어, DNS 서비스, 방화벽 규칙의 시작 순서를 확인하고 시간 동기화와 저장 장치 마운트를 점검합니다. 서비스가 복구된 것을 확인한 다음에만 트래픽 전달을 다시 활성화하세요. 원인을 가리기 위해 반복해서 재부팅하지 마세요.

장애 발생 시 동작 방식도 미리 정해야 합니다. 코어가 종료되면 지정한 트래픽의 직접 연결을 허용할지, 아니면 차단할지 결정하세요. 두 방식 모두 명시적으로 구현하고 실제 테스트해야 합니다. 유지보수 시간에 코어를 한 번 중지해 단말 동작을 확인하고 의도한 결과와 일치하는지 점검하세요. 프로세스 자동 재시작을 완전한 복구 방안으로 간주하지 마세요.

7. 검수와 선택: 여러 기기에서 쓸 때 라우터로 이전

라우터에 배포하면 규칙을 한곳에서 관리하고 프록시를 개별 설정하기 어려운 기기까지 적용할 수 있습니다. 대신 네트워크 장애의 영향 범위가 커집니다. PC 한 대만 사용한다면 v2rayN에서 노드 전환, 로그 확인, 설정 복구를 더 간편하게 할 수 있습니다. Android 기기에서는 v2rayNG로 Xray 노드를 먼저 확인하세요. v2flyNG를 선택한다면 노드와 V2Fly 간 프로토콜 호환성도 별도로 확인해야 합니다.

기능 검수: 직접 연결 대상, 프록시 대상, LAN 서비스, DNS, UDP를 각각 테스트하세요. 웹 페이지 하나로 모든 항목을 대신 확인할 수는 없습니다.
성능 검수: 같은 노드와 비슷한 시간대에 데스크톱과 라우터의 처리량을 비교하고 CPU, 메모리, 온도를 함께 기록해 노드 혼잡과 로컬 병목을 구분하세요.
재부팅 검수: 보조 라우터를 재부팅하고 임대를 새로 받은 뒤 주소, 규칙, DNS, 아웃바운드가 모두 복구됐는지 확인하세요. 관리 페이지가 열리는지만 확인해서는 안 됩니다.
복구 검수: 게이트웨이, DNS, 트래픽 전달 규칙을 되돌리는 구체적인 절차를 기록하세요. 백업 복구가 가능한지 확인하고 테스트 경로를 거치지 않는 관리 접속 경로를 남겨 두세요.

단말 한 대에서 검증을 마친 다음 기기별 또는 주소별 그룹으로 적용 범위를 넓히세요. 펌웨어 교체, 코어 업데이트, 노드 변경, DNS 정책 재작성은 한꺼번에 하지 마세요. 변경을 나누어야 각 단계가 효과가 있었는지 로그와 비교 테스트로 판단할 수 있습니다.