라우터·보조 라우터에서 Xray 실행하기: 배포 방식과 하드웨어 선택

핵심 내용

라우터 배포의 핵심은 데스크톱 클라이언트를 기기에 옮기는 것이 아니라 코어, 시스템 라우팅, 방화벽, DNS가 함께 작동하도록 구성하는 것입니다. 사용 가능한 연결 설정을 갖추고 LAN 기기의 트래픽을 분기하려는 사용자를 위해 메인 라우터와 보조 라우터의 차이부터 설명합니다. 프로세서 아키텍처와 여유 자원을 확인한 뒤 테스트 기기 한 대로 전달 경로를 검증하면, 전체 네트워크의 게이트웨이를 한 번에 바꾸다가 문제 해결 경로까지 잃는 일을 피할 수 있습니다.

라우터에서 실행하는 것은 데스크톱 클라이언트가 아니라 코어입니다

v2rayN은 데스크톱에서 설정과 연결을 관리하는 클라이언트이고, v2rayNG는 Xray 코어를 사용하는 Android 클라이언트이며, v2flyNG는 V2Fly 코어를 사용합니다. 구독 관리, 설정 생성, 사용자 인터페이스를 제공하지만, 라우터에서는 보통 Xray 또는 V2Fly 명령줄 프로그램을 직접 실행하고 펌웨어의 서비스 관리 기능으로 시작합니다. 클라이언트 화면의 ‘시스템 프록시’ 스위치를 라우터 전체의 프록시 기능으로 그대로 옮길 수는 없습니다.

코어는 인바운드 연결을 받아 라우팅 규칙을 적용하고 아웃바운드 연결을 설정합니다. 어떤 단말의 트래픽을 코어로 보낼지는 시스템의 포워딩, 방화벽, 정책 라우팅이 결정합니다. 프로세스를 실행하고 로그에 수신 대기 성공이 표시되더라도 같은 네트워크의 TV, 컴퓨터 등 다른 기기 트래픽까지 프록시를 거친다는 뜻은 아닙니다.

앱에서 프록시를 직접 설정: 프록시를 지원하는 앱에 라우터 주소와 SOCKS 또는 HTTP 포트를 입력해 단일 앱부터 테스트합니다. 변경 범위를 작게 유지할 수 있습니다.
투명 프록시 적용: 리디렉션, TPROXY 등의 방식으로 지정한 트래픽을 코어에 전달합니다. 시스템 모듈, 방화벽 규칙, 인바운드 설정이 함께 맞아야 합니다.
기기별 트래픽 분기: 단말 주소나 서브넷을 기준으로 트래픽을 넘길지 결정한 다음, 코어의 도메인·IP 규칙으로 구체적인 아웃바운드 경로를 선택합니다.

메인 라우터와 보조 라우터: 먼저 장애 영향 범위를 정하세요

메인 라우터는 보통 인터넷 연결, 주소 할당, 기본 게이트웨이, 방화벽을 담당합니다. 기능이 한곳에 모여 있고 트래픽 경로도 비교적 단순하지만, 코어를 업그레이드하거나 포워딩 규칙을 수정하거나 메모리가 부족해지면 LAN 전체에 영향을 줄 수 있습니다. 보조 라우터를 두면 기존 메인 라우터의 기본 인터넷 연결 기능을 유지하기 쉽습니다. 대신 반환 경로, 주소 할당, DNS를 더 세심하게 설계해야 합니다.

보조 라우터: 테스트 단말 한 대부터 연결하세요

권장

기존 메인 라우터의 인터넷 연결과 DHCP는 그대로 두고 테스트 단말의 게이트웨이나 앱 프록시 설정만 변경하세요. 문제가 생기면 해당 단말을 메인 라우터로 되돌릴 수 있어 항목별 검증이 쉽고 다른 기기에도 영향을 주지 않습니다.

적합한 경우: 안정적으로 작동하는 메인 라우터가 있고, 게이트웨이 트래픽 분기를 처음 시도하거나 명확한 롤백 경로가 필요한 경우

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

트래픽을 넘기는 지점과 출구가 한 기기에 모여 포워딩을 통합 관리하기 쉽습니다. 다만 관리 접속 경로를 확보하고 CPU, 메모리, 저장 공간, 펌웨어 모듈이 추가 작업을 감당할 수 있는지 확인해야 합니다.

적합한 경우: 펌웨어 방화벽에 익숙하고 설정을 복구할 수 있으며 점검 시간을 확보할 수 있는 경우

구성 예시: 메인 라우터는 유지하고 보조 라우터에서 별도 검증

메인 라우터: 192.168.10.1

인터넷 출구와 DHCP를 계속 담당합니다.
주소 충돌을 막기 위해 보조 라우터에 192.168.10.2를 할당합니다.
다른 단말의 기본 게이트웨이는 우선 변경하지 않습니다.

보조 라우터: 192.168.10.2

기본 경로는 192.168.10.1을 가리키도록 설정합니다.
트래픽을 전달하려면 IP 포워딩을 활성화하고 방화벽을 설정합니다.
테스트 단말은 구성에 따라 게이트웨이와 DNS 서비스를 사용합니다.

이 주소는 같은 서브넷을 사용하는 구성 예시입니다. 적용하기 전에 현재 네트워크의 서브넷, DHCP 주소 풀, 기존 고정 IP를 확인하세요.

단일 네트워크 포트의 보조 라우터도 사용할 수 있지만 반환 경로를 고려해야 합니다. 직접 연결된 트래픽이 보조 라우터를 거치지 않고 메인 라우터에서 단말로 바로 돌아갈 수 있습니다. 소스 NAT가 필요한지는 연결 추적, 방화벽, 반환 경로를 함께 확인해 판단하세요. 일반 규칙 하나를 그대로 적용하는 것은 바람직하지 않습니다. 포트가 여러 개여도 설정 문제가 저절로 해결되지는 않습니다. 각 홉의 진입점, 출구, 반환 경로를 명확하게 설명할 수 있어야 합니다.

하드웨어 선택: 아키텍처 호환성, 메모리 여유, 저장 공간

먼저 기기 정보를 확인한 다음 실행 파일을 고르세요. 프로세서 제품명만으로 호환성을 판단할 수는 없습니다. ARM의 비트 수와 명령어 집합, MIPS의 엔디언과 빌드 요구 사항을 구분해야 합니다. 하드웨어가 64비트를 지원해도 펌웨어의 사용자 공간이 반드시 64비트인 것은 아닙니다. 동적 링크 프로그램은 런타임 라이브러리와 로더의 영향도 받습니다. ‘실행할 수 없음’ 오류가 발생해도 노드나 구독부터 의심할 필요는 없습니다.

# 기기 터미널에서 시스템과 리소스를 확인합니다. 펌웨어마다 명령 옵션이 다를 수 있습니다
uname -m
uname -a
free -m
df -h
ip route show
ip -6 route show

점검 항목	확인할 내용	선택에 미치는 영향
프로세서 및 시스템	예: aarch64, armv7l, x86_64. 펌웨어 패키지의 아키텍처도 확인	실행 가능한 코어 빌드가 결정되므로 기기 모델만으로 판단할 수 없습니다
메모리 여유	시작 전, 규칙 로드 후, 연결이 늘어난 시점에 available 등의 지표를 각각 확인	규칙 세트, 연결 수, DNS 캐시, 기타 서비스가 메모리를 함께 사용합니다
쓰기 가능한 공간	코어, 규칙 파일, 임시 업데이트 파일, 로그가 저장된 파티션	새 파일을 내려받고 기존 파일을 교체할 때 추가 공간이 필요할 수 있습니다
시스템 기능	방화벽 백엔드, 정책 라우팅, 필요한 투명 프록시 모듈	구체적인 트래픽 처리 방식이 결정됩니다. 프로그램이 시작되는지만 확인해서는 안 됩니다
네트워크 및 냉각	포트 속도, 드라이버 안정성, 지속 부하 상태의 온도와 CPU 사용량	장기적인 안정성에 영향을 줍니다. 코어 수만으로 처리량을 추정할 수는 없습니다

새 기기를 구매한다면 경량 게이트웨이의 1차 선별 기준으로 메모리 512MB 이상을, 여러 서비스를 동시에 실행하는 환경에는 1GB 이상을 고려할 수 있습니다. 이는 리소스 계획을 위한 권장 사항이지 코어의 최소 사양이나 성능 보장은 아닙니다. 메모리가 적은 기존 기기도 구성을 간소화하면 사용할 수 있지만, 불필요한 규칙과 백그라운드 서비스를 줄이고 메모리 부족으로 프로세스가 종료되는지 확인해야 합니다. 스왑 공간 활성화를 지속적인 메모리 부족의 대책으로 삼지 마세요.

하드웨어 판단: 목표 규칙 세트로 먼저 시험한 다음 교체 여부를 결정하세요

같은 기기에서 유휴 상태, 규칙 로드 후, 여러 기기를 일상적으로 사용할 때의 리소스 변화를 기록하세요. 코어에 오류가 없는데 CPU 사용량이 계속 높다면 암호화와 포워딩 부하를 점검하고, 시스템이 프로세스를 종료했다면 메모리 로그부터 확인하세요. ‘노드 연결이 느리다’는 이유만으로 라우터 성능이 부족하다고 단정할 수는 없습니다.

포트, DNS, 투명 프록시: 경로를 나눠 검증하세요

앱에서 프록시 연결이 된다면 좋은 출발점이지만 투명 프록시가 올바르게 작동한다는 뜻은 아닙니다. 우선 테스트 전용 SOCKS 인바운드를 바인딩하고 앱 하나로 아웃바운드를 확인한 뒤 게이트웨이 포워딩을 추가하세요. 아래 세 포트는 역할을 설명하기 위한 예시일 뿐, 모든 클라이언트나 펌웨어의 기본값이 아닙니다. 실제 수신 대기 설정은 구성과 시스템 출력에 따라 확인하세요.

일반 DNS 서비스 포트. 기존 서비스가 사용 중인지 확인하세요

1080

이 문서의 SOCKS 인바운드 포트 예시

12345

이 문서의 투명 프록시 인바운드 포트 예시. 트래픽 처리 규칙과 맞춰야 합니다

수신 대기 범위 확인: 127.0.0.1만 수신하도록 설정하면 다른 LAN 기기에서 직접 연결할 수 없습니다. LAN에 프록시를 제공해야 한다면 적절한 주소에 바인딩하고 방화벽으로 접속 출처를 제한하세요. 프록시 포트를 인터넷에 공개해서는 안 됩니다.
프록시 자체 트래픽 제외: 코어가 설정한 아웃바운드 연결이 트래픽 처리 규칙에 다시 포착되지 않도록 해야 합니다. 배포 방식에 따라 프로세스, 사용자, 트래픽 마크 또는 대상 주소를 기준으로 제외하고 서버 주소에 정상적으로 연결되는지 확인하세요.
TCP와 UDP를 각각 처리: 특정 리디렉션 방식이 TCP를 지원한다고 해서 UDP도 처리되는 것은 아닙니다. TPROXY에는 정책 라우팅과 관련 모듈도 필요하므로 포트 포워딩 규칙 하나만 추가해서는 해결되지 않습니다.
DNS 부트스트랩 경로 설계: 먼저 서버 도메인을 누가 조회할지 정한 뒤 서비스 도메인의 조회 경로를 결정하세요. 프록시를 설정하려면 먼저 도메인 조회가 필요한데 조회는 아직 연결되지 않은 프록시를 통해서만 가능하다면 시작 단계에서 의존성 순환이 발생합니다.
IPv6는 별도로 검증: IPv4 규칙만 작성하면 IPv6 연결은 다른 경로로 나갈 수 있습니다. IPv6 트래픽도 분기할지 정하고 단말에 전달된 라우터 광고와 DNS 정보를 확인하세요.

설정 이전: 연결 정보는 옮기고 라우터 로컬 설정은 새로 구성

데스크톱에서 사용 중인 노드는 설정 이전의 참고 자료로 활용할 수 있지만, 라우터 설정을 통째로 덮어써서는 안 됩니다. v2rayN이 생성한 실행 설정에는 로컬 포트, 파일 경로, 클라이언트 관리 필드가 포함될 수 있습니다. 구독 내용도 코어에서 바로 실행할 수 있는 JSON이라고 단정할 수 없습니다. 서버 연결 정보와 로컬 실행 설정을 분리한 다음 대상 코어의 설정 규격에 맞게 다시 구성하세요.

연결 정보 기록: 주소, 포트, 프로토콜, 인증 정보, 전송 방식, 보안 계층을 기록합니다. TLS의 serverName, WebSocket의 path와 Host, REALITY의 서버 공개 키와 shortId 등은 실제 구성에 맞는지 확인해야 하며 서로 대체할 수 없습니다.
대상 코어 확인: 프로토콜, 전송 방식, 보안 계층의 조합이 지원되는지 확인하세요. 특정 클라이언트에서 구독을 가져올 수 있다는 사실은 해당 클라이언트가 처리할 수 있다는 뜻일 뿐, 다른 코어도 같은 설정을 받아들인다는 뜻은 아닙니다.
로컬 설정 재구성: 수신 주소, 인바운드 포트, 라우팅 규칙, DNS를 설정하고 규칙 파일 경로를 기기에서 유효한 위치로 바꾸세요. 실행 사용자에게 파일을 읽고 필요한 작업을 수행할 권한이 있는지도 확인해야 합니다.
활성화 전 검사: 코어의 설정 검사 명령으로 필드와 참조 파일을 확인한 뒤 포그라운드에서 시작해 로그를 살펴보세요. 검사를 통과해도 설정을 불러올 수 있다는 뜻일 뿐, 실제 연결은 별도로 검증해야 합니다.
마지막으로 서비스 관리에 등록: 펌웨어의 기본 서비스 관리자를 사용해 시작과 재시작을 처리하세요. 시작 경로를 여러 곳에 중복 설정하지 마세요. 백업 파일 위치, 복구 절차, 서비스 중지 방법을 기록해 두세요.

# 실행 파일 이름이 xray이고 설정이 이 경로에 저장되어 있다고 가정합니다
# 먼저 도움말을 확인해 현재 빌드에서 지원하는 명령 옵션을 확인합니다
xray help run
xray run -test -config /etc/xray/config.json

# 설정 검사를 통과한 뒤 포그라운드에서 시작해 로그를 확인합니다
xray run -config /etc/xray/config.json

V2Fly를 사용하는 경우 해당 빌드의 도움말을 확인하세요. Xray 명령과 필드를 공통 인터페이스로 간주해서는 안 됩니다. 구독 자동 업데이트도 코어를 시작한다고 저절로 제공되는 기능이 아닙니다. 제어된 다운로드, 변환, 설정 검사, 교체 절차가 필요합니다. 업데이트에 실패하면 이전의 정상 설정을 보존하고, 빈 결과로 현재 작동 중인 파일을 덮어쓰지 마세요.

자주 발생하는 문제: 설정을 바꾸기 전에 끊긴 구간부터 찾으세요

한 번에 변수 하나만 변경하세요. 먼저 기기 자체의 DNS 조회와 아웃바운드 연결이 정상인지 확인하고, 이어서 코어 연결, 마지막으로 단말에서 게이트웨이까지의 포워딩 경로를 검증합니다. DNS, 라우팅 규칙, 프로토콜을 한꺼번에 바꾸면 연결이 복구되더라도 원인을 파악하기 어렵고 재부팅 후에도 정상 작동한다고 보장하기 어렵습니다.

프로그램을 실행할 수 없다는 메시지가 표시됩니다. 다운로드를 잘못한 걸까요?

먼저 uname -m을 실행해 펌웨어 패키지의 아키텍처를 확인한 다음 파일 실행 권한, 동적 로더, 런타임 라이브러리 요구 사항을 점검하세요. ‘Exec format error’는 대개 아키텍처나 파일 형식 문제를 가리킵니다. 아직 연결 단계에 도달하지 않았으므로 서버 측 매개변수부터 바꿀 필요는 없습니다.

보조 라우터에서는 연결되는데 컴퓨터의 게이트웨이로 설정하면 웹 페이지가 열리지 않나요?

IP 포워딩, 방화벽의 포워딩 정책, 기본 경로, 반환 경로를 확인하세요. 그런 다음 컴퓨터에서 예시 SOCKS 포트 1080에 직접 연결해 보세요. 연결되면 노드를 다시 가져오기보다 투명 프록시 경로를 먼저 점검해야 합니다. 이후 DNS, TCP, UDP를 각각 테스트하세요.

일부 웹사이트만 문제가 있으면 프로토콜을 바꿔야 할까요?

먼저 규칙 적용 결과, DNS 응답, IPv6 경로를 확인하세요. 특정 대상이 잘못 직접 연결되거나 UDP가 처리되지 않는 문제, 경로 MTU 문제도 살펴보세요. 같은 단말에서 앱 프록시와 투명 프록시의 동작을 비교하면 프로토콜을 바로 바꾸는 것보다 원인을 찾는 데 도움이 됩니다.

재부팅할 때마다 작동하지 않습니다. 시작 스크립트를 하나 더 추가해야 할까요?

먼저 서비스 상태, 시작 로그, 설정 파일 권한을 확인한 다음 부팅 시 네트워크, 시간 동기화, 규칙 파일이 준비되는지 살펴보세요. 중복 실행으로 포트 충돌이 나지 않도록 주의하세요. 두 번째 프로세스를 추가하는 대신 기존 서비스의 의존성과 설정 경로를 바로잡아야 합니다.

운영 전 점검: 연결뿐 아니라 복구도 확인하세요

더 많은 단말로 확대하기 전에 기기 재부팅, 코어 중지, 설정 복구를 각각 한 번씩 시험하세요. 테스트 단말을 기존 메인 라우터로 되돌릴 수 있고 관리 페이지에 항상 접속할 수 있는지 확인한 뒤 DHCP 배포 정책을 단계적으로 조정하세요. 처음으로 네트워크 전체에 프록시를 적용하는 작업과 첫 업그레이드를 한 번에 진행하지 마세요.