플랫폼 예상 읽기 시간 12분

V2Ray 코어를 라우터와 바이패스 라우터에서 실행하는 방법: 배포 방식과 하드웨어 요구 사항

메인 라우터와 바이패스 라우터에서 V2Ray 코어를 직접 실행하는 방법을 정리합니다. 펌웨어 환경, 메모리 및 암호화 성능 요구 사항, 투명 프록시의 기본 흐름과 데스크톱 클라이언트로 전환하는 것이 적합한 경우를 살펴봅니다.

프록시 코어를 라우터에 배치할 때 달라지는 핵심은 단순히 “실행 위치를 바꾸는 것”이 아닙니다. 게이트웨이가 LAN 장치의 연결을 일괄 처리하게 됩니다. 각 단말에서 시스템 프록시를 따로 설정하지 않아도 되지만, 게이트웨이는 포워딩, DNS, 라우팅 규칙 매칭, 연결 추적과 암호화 연산을 모두 담당해야 합니다. 설정 오류의 영향도 한 대의 컴퓨터에서 전체 LAN으로 확대됩니다.

배포 전에는 메인 라우터와 바이패스 라우터를 먼저 구분해야 합니다. 메인 라우터는 인터넷 회선, DHCP와 기본 게이트웨이를 직접 관리하므로 경로가 짧지만, 코어를 유지보수하는 동안 전체 네트워크에 영향을 줄 수 있습니다. 바이패스 라우터는 기존 메인 라우터 뒤에 배치하며, 보통 지정한 단말만 기본 게이트웨이나 정책 라우팅을 통해 연결합니다. 테스트와 롤백에는 유리하지만 반환 경로와 DNS 방향을 추가로 처리해야 합니다.

이 글 한눈에 보기

여러 기기에서 V2Ray 및 Xray 프록시 기능을 공유하려는 사용자를 대상으로, 메인 라우터와 바이패스 라우터의 차이, 펌웨어와 하드웨어 요구 사항, 투명 프록시 흐름, 배포 절차와 롤백 조건을 순서대로 설명합니다. 장치를 설정할 가치가 있는지 먼저 판단한 뒤 게이트웨이 배포와 데스크톱 클라이언트 중 적합한 방식을 선택할 수 있습니다.

메인 라우터와 바이패스 라우터: 먼저 장애 범위를 정하기

메인 라우터 배포의 일반적인 트래픽 경로는 “단말 → 메인 라우터 투명 프록시 진입점 → V2Ray 또는 Xray 코어 → 원격 서버”입니다. 코어 프로세스와 NAT, 방화벽, DHCP가 같은 장치에 있습니다. 토폴로지가 단순하고 모든 단말이 동일한 정책 지점을 통과한다는 장점이 있지만, 코어 장애, 방화벽 규칙 오류 또는 DNS 설정 실수만으로도 정상적인 인터넷 사용에 직접 영향을 줄 수 있습니다.

바이패스 라우터 구성에서는 기존 메인 라우터를 안정적인 인터넷 출구로 유지합니다. 프록시가 필요한 단말의 게이트웨이를 바이패스 라우터로 지정하거나, 메인 라우터가 출발지 주소를 기준으로 특정 장치를 해당 라우터로 전달합니다. 바이패스 라우터는 규칙을 매칭한 뒤 직접 연결 또는 프록시 트래픽을 메인 라우터로 돌려보냅니다. 장치를 한 대씩 이전하기에 적합하고, 장애가 발생하면 단말의 게이트웨이를 메인 라우터 주소로 빠르게 되돌릴 수 있습니다.

메인 라우터에서 직접 실행

DHCP, NAT, DNS와 투명 프록시를 한곳에서 관리하므로 경로가 가장 짧습니다. 코어를 업그레이드하거나 방화벽을 수정하기 전 복구 가능한 설정을 보관해야 합니다.

적합한 경우: 성능이 충분하고 네트워크 구성이 단순하며 유지보수 시간을 확보할 수 있을 때

바이패스 라우터로 분리

권장

기존 메인 라우터는 그대로 두고 지정한 단말만 이전합니다. 프록시에 문제가 생기면 기본 게이트웨이를 기존 주소로 빠르게 되돌릴 수 있습니다.

적합한 경우: 처음 배포하거나 단계별 검증이 필요하고, 가정 내 네트워크를 오래 중단할 수 없을 때

데스크톱 클라이언트

컴퓨터에서 v2rayN을 실행하고 시스템 프록시, TUN, 구독과 코어 로그를 사용자가 직접 제어합니다.

적합한 경우: 사용하는 장치가 한두 대뿐이고 노드와 규칙을 자주 전환하거나 디버깅해야 할 때

바이패스 라우터라고 해서 장치를 스위치에 연결하기만 하면 자동으로 트래픽을 가져가는 것은 아닙니다. 단말은 DHCP, 수동 게이트웨이 설정 또는 메인 라우터 정책을 통해 트래픽을 바이패스 라우터로 보내야 합니다. 단말의 기본 게이트웨이가 여전히 메인 라우터라면 바이패스 라우터에서 코어가 정상 실행 중이어도 해당 연결을 볼 수 없습니다.

펌웨어 환경: 코어가 시작되는 것은 최소 조건일 뿐

라우터에는 먼저 해당 아키텍처용 Linux 프로그램을 실행할 수 있는 환경이 필요합니다. 일반적인 아키텍처로는 x86_64, aarch64, armv7, mipsle가 있으며, 다운로드하기 전에 프로세서 브랜드가 아니라 시스템이 보고하는 아키텍처를 확인해야 합니다. 예를 들어 64비트 ARM 시스템은 aarch64로 표시될 수 있습니다. 같은 계열의 구형 장치는 32비트 사용자 공간을 실행할 수도 있으므로 armv7 빌드만 사용할 수 있습니다.

Linux 5.10 이상 커널을 사용하고 nftables 또는 완전한 iptables 확장 기능이 있는지 확인하는 것이 좋습니다. 투명 프록시에는 정책 라우팅, 연결 마크, TPROXY 또는 REDIRECT 등의 기능이 필요합니다. 경량 펌웨어는 코어 프로그램을 실행할 수 있어도 투명 포워딩 모듈이 빠져 있을 수 있으며, 이 경우 단말에서 직접 입력할 SOCKS 또는 HTTP 인바운드 포트 하나만 열 수 있습니다.

구독 역시 라우터 코어가 기본적으로 처리하는 범용 입력 형식이 아닙니다. 구독 링크는 보통 클라이언트나 관리 계층이 해석한 뒤 코어가 읽을 수 있는 JSON 설정으로 변환합니다. V2Ray 설정에 구독 주소 하나만 입력한다고 해서 코어가 노드 해석, 그룹 구성과 라우팅 규칙 생성을 자동으로 수행하지는 않습니다. 라우터 배포에는 별도의 설정 관리 계층이 필요하거나, 인바운드·아웃바운드·라우팅 객체를 명시적으로 수동 관리해야 합니다.

하드웨어 요구 사항: CPU 코어 수보다 지속 처리량을 확인하기

프록시 트래픽은 사용자 공간의 코어를 거치므로 처리량은 단일 코어 성능, 암호화 알고리즘, TLS 구현, 메모리 대역폭과 냉각 성능의 영향을 함께 받습니다. 저주파 쿼드코어 프로세서가 고성능 듀얼코어보다 항상 빠른 것은 아닙니다. 한 연결의 핸드셰이크, 캡슐화와 일부 암호화 작업은 모든 코어에 균등하게 분산되지 않기 때문입니다. 복잡한 도메인 규칙과 많은 연결을 사용하면 메모리 부담도 크게 증가합니다.

아래 수치는 장치 성능을 보장하는 값이 아니라 실험실 수준의 출발점으로 참고하세요. 테스트 조건은 1Gbps LAN, 단일 원격 회선, 동시 다운로드 8개, 약 4,000개의 도메인 규칙이며, 15분간 안정적으로 실행한 뒤 처리량과 메모리를 확인했습니다. 회선 지연 시간, 프로토콜 조합과 펌웨어 컴파일 옵션에 따라 결과는 달라질 수 있습니다.

하드웨어 등급 권장 메모리 참고 프록시 처리량 적합한 범위
듀얼코어 ARM, 약 1.0GHz 최소 256MB 약 45–90Mbps 가벼운 웹 사용과 소수의 단말에 적합하며, 고속 다운로드 전체를 프록시로 처리하는 것은 권장하지 않습니다.
쿼드코어 ARM, 약 1.5GHz 최소 512MB 약 160–320Mbps 일반적인 가정용 분기 구성, 활성 단말 10–20대
최신 쿼드코어 ARM, 2.0GHz 이상 최소 1GB 약 350–650Mbps 고대역폭 회선, 많은 동시 연결과 복잡한 규칙
x86_64 저전력 플랫폼 최소 2GB 약 700–940Mbps 기가비트 인터넷, 지속적인 다운로드, DNS 및 모니터링 서비스 동시 실행

결론: 15분 연속 테스트부터 진행하기

속도 측정에서 500Mbps가 나왔다고 해서 라우터가 장시간 그 속도를 안정적으로 유지한다는 뜻은 아닙니다. 15분 연속 실행 후 처리량이 20% 넘게 떨어지거나 단일 코어 사용률이 장시간 100%에 가깝고 본체의 클럭이 눈에 띄게 낮아진다면 목표 대역폭을 낮추고 냉각을 개선하거나 바이패스 라우터와 데스크톱 클라이언트로 전환해야 합니다.

메모리 측면에서 코어는 유휴 상태일 때 수십 MB만 사용할 수 있지만, 규칙 파일 파싱, DNS 캐시, 연결 추적과 로그가 점유량을 늘립니다. 128MB 장치는 간신히 시작되더라도 구독으로 많은 아웃바운드가 생성되거나 동시 연결이 늘고 시스템이 업데이트될 때 메모리 회수가 발생하기 쉽습니다. 512MB는 가정용 트래픽 분기의 현실적인 시작점입니다. 필터링, 모니터링과 파일 서비스까지 실행한다면 1GB부터 평가하는 것이 좋습니다.

프로토콜 선택도 프로세서 부하에 영향을 줍니다. VMess 자체에 암호화와 인증 처리가 포함되어 있고 VLESS의 설계는 더 가볍지만, TLS와 REALITY 같은 보안 계층을 조합하면 핸드셰이크와 암호화 비용이 여전히 발생합니다. 프로토콜 이름만으로 속도를 추정하지 말고, 동일한 노드와 시간대에서 CPU 사용률, 지속 처리량과 첫 바이트 지연 시간을 비교해야 합니다.

투명 프록시 흐름: 진입점·마크·라우팅·DNS가 모두 필요합니다

투명 프록시의 목표는 단말에서 SOCKS 주소를 입력하지 않아도 되게 하는 것입니다. TCP와 UDP를 함께 처리하는 경우를 예로 들면, 방화벽이 먼저 프록시가 필요한 연결을 선별한 뒤 트래픽을 로컬 투명 인바운드 포트(예: 12345)로 보냅니다. 코어는 원래 목적지 주소를 읽고 도메인, IP, 포트 또는 프로토콜에 따라 라우팅 규칙을 매칭한 다음 직접 연결, 차단 또는 원격 프록시 아웃바운드를 선택합니다.

단말 192.168.1.20
  → 기본 게이트웨이 192.168.1.2
  → LAN 및 원격 서버 주소 제외
  → TPROXY 진입점 0.0.0.0:12345
  → fwmark 0x1 / 정책 라우팅 테이블 100
  → V2Ray 또는 Xray 라우팅 매칭
  → direct 또는 proxy 아웃바운드

정책 라우팅의 핵심은 마크가 붙은 패킷이 기본 경로로 계속 전달되지 않고 로컬 투명 인바운드로 돌아오게 하는 것입니다. 일반적으로 0x1 마크와 별도 라우팅 테이블 100을 사용합니다. 구체적인 명령은 nftables, iptables 버전과 펌웨어의 구성 방식에 따라 달라지므로 두 규칙 체계를 섞은 뒤 한쪽만 삭제해서는 안 됩니다.

DNS는 도메인 규칙이 매칭되는지를 결정합니다. 단말이 외부 DNS를 직접 조회하면 게이트웨이는 목적지 IP만 보게 되어 도메인별 분류가 안정적으로 이루어지지 않을 수 있습니다. DHCP를 통해 바이패스 라우터 주소를 DNS로 배포한 뒤, 로컬 캐시 서비스가 53번 포트를 수신하고 처리할 요청을 코어의 DNS 인바운드(예: 127.0.0.1:1053)로 전달하도록 구성할 수 있습니다. 동시에 코어가 원격 도메인을 조회할 때 자체 투명 규칙으로 다시 들어가지 않도록 해야 합니다.

  1. 네트워크 매개변수 확인

    메인 라우터 주소, 바이패스 라우터 주소, DHCP 범위와 원격 서버 IP를 기록합니다. 예시에서 메인 라우터는 192.168.1.1, 바이패스 라우터는 192.168.1.2이며 두 장치가 같은 주소를 사용해서는 안 됩니다.

  2. 먼저 수동 진입점 열기

    먼저 코어가 127.0.0.1:10808에서 SOCKS 인바운드를 수신하도록 설정합니다. 컴퓨터 한 대에서 프록시를 수동으로 설정해 노드, 프로토콜과 시간 동기화를 확인하고, 이 단계에서는 전체 네트워크의 방화벽을 수정하지 않습니다.

  3. 투명 진입점 추가

    12345 투명 인바운드를 추가하고 원래 목적지 주소 전달 기능을 활성화한 다음, 테스트 단말에만 적용되는 TPROXY 또는 REDIRECT 규칙을 구성합니다.

  4. DNS 경로 고정

    LAN의 53번 포트를 점유하는 서비스가 하나뿐인지 확인합니다. 코어 DNS 수신 주소를 127.0.0.1:1053으로 설정한 뒤 도메인 분기와 직접 연결 DNS 조회 결과를 검증합니다.

  5. 처리 범위 확대

    30분 동안 로그, CPU, 메모리와 연결 수를 관찰합니다. 루프와 연결 끊김이 없는 것을 확인한 뒤 단일 테스트 주소에서 지정한 장치 그룹으로 범위를 넓히고, 마지막에 전체 네트워크 적용을 검토합니다.

배포와 검수: 장치 한 대씩 단계적으로 확대하기

배포할 때 처음부터 전체 투명 포워딩을 활성화하지 마세요. 코어 설정을 먼저 검증하고, 수동 프록시 진입점을 확인한 다음 테스트 단말 한 대만 처리하는 순서가 안전합니다. 각 단계마다 독립적인 확인 지점을 남겨야 문제가 노드, 코어 설정, 방화벽, DNS 또는 바이패스 라우터의 반환 경로에 있는지 판단할 수 있습니다.

  1. 시스템 아키텍처, 쓰기 가능 공간과 시간을 확인합니다. 실행 환경은 현재 시간을 올바르게 표시해야 하며 최소 40MB의 여유 공간을 확보해야 합니다.
  2. 코어를 시작한 뒤 처음 30줄의 로그를 확인하여 설정 파일이 로드되었고 인바운드 포트가 수신 중이며 아웃바운드 도메인이 해석되는지 확인합니다.
  3. 테스트 컴퓨터에서 바이패스 라우터의 10808 SOCKS 포트에 연결하고 직접 연결 대상과 프록시 대상에 각각 접속하여 기본 노드가 정상인지 확인합니다.
  4. 테스트 컴퓨터의 주소를 192.168.1.20으로 고정하고, 다른 장치에 영향을 주지 않도록 투명 규칙이 해당 출발지 주소만 매칭하게 합니다.
  5. TCP 웹 접속, UDP DNS 조회, 지속적인 다운로드와 대기 후 복귀의 네 가지 테스트를 수행하고, 로그에 연결 루프, 포트 점유 또는 DNS 조회 시간 초과가 나타나는지 관찰합니다.
  6. 프록시를 끈 직접 연결 처리량과 프록시를 켠 처리량을 기록합니다. 500Mbps 인터넷이 안정적으로 120Mbps밖에 나오지 않고 단일 코어가 최고 사용률이라면 라우팅 규칙을 더 쌓을 것이 아니라 하드웨어 병목으로 판단해야 합니다.

결론: 되돌릴 수 있는 설정을 완료 기준으로 삼기

배포 완료는 웹페이지가 열리는 것만을 뜻하지 않습니다. 2분 안에 투명 규칙을 비활성화하고 기존 DNS와 기본 게이트웨이를 복구할 수 있어야 합니다. 네트워크를 복구하려면 펌웨어를 다시 설치해야 한다면 현재 변경 사항에 독립적인 차단 장치가 없는 것이므로 처리 범위를 더 넓히기에 적합하지 않습니다.

검수 시 기록해야 할 네 가지 데이터

로그 수준을 장기간 debug로 유지해서는 안 됩니다. 검증 단계에서는 일시적으로 상세도를 높일 수 있지만, 원인 파악이 끝나면 warning 또는 error로 되돌리고 로그 순환을 구성하세요. 라우터 플래시는 쓰기 수명과 공간이 제한되어 있으므로 모든 연결을 계속 기록하면 불필요한 쓰기가 발생하고 루트 파일 시스템이 로그로 가득 찰 수 있습니다.

언제 v2rayN, v2rayNG 또는 v2flyNG로 되돌려야 할까

게이트웨이 배포가 모든 네트워크에 적합한 것은 아닙니다. 프록시가 필요한 데스크톱 컴퓨터가 한 대뿐이라면 v2rayN이 더 직접적일 때가 많습니다. 구독 업데이트, 노드 테스트, 시스템 프록시, TUN과 로그를 한 화면에서 처리할 수 있습니다. v2rayN 7.x에서는 “설정” → “매개변수 설정” → “Core 유형”에서 현재 코어 선택을 확인한 뒤 노드 프로토콜에 맞는 코어로 전환할 수 있습니다.

Android 단말은 코어 요구 사항에 따라 v2rayNG 또는 v2flyNG를 사용할 수 있습니다. v2rayNG는 Xray 코어를 사용하므로 해당 프로토콜 기능이 필요한 설정에 적합하고, v2flyNG는 v2fly 코어를 사용하므로 V2Ray 호환 프로토콜 기반 연결에 적합합니다. 단말 클라이언트에서는 전체 네트워크의 방화벽을 다시 로드하지 않고도 노드를 독립적으로 전환할 수 있어 문제를 한 대의 장치로 한정하기도 쉽습니다.

바이패스 라우터에서 코어가 시작되는데 왜 단말 트래픽이 라우터를 거치지 않을까?

먼저 단말의 기본 게이트웨이를 확인하세요. 여전히 192.168.1.1이고 바이패스 라우터가 192.168.1.2라면 트래픽은 자동으로 우회하지 않습니다. 테스트 단말 한 대의 게이트웨이와 DNS를 수동으로 192.168.1.2로 지정한 뒤 투명 진입점의 카운터가 증가하는지 확인하세요.

웹페이지는 열리지만 일부 프로그램이 계속 직접 연결될 때는 어떻게 해야 할까?

해당 프로그램이 UDP, 별도 DNS를 사용하거나 시스템 프록시를 따르지 않는지 확인하세요. 라우터에서는 UDP 투명 포워딩과 DNS 경로를 함께 검증해야 합니다. 하드웨어나 펌웨어에 TPROXY 기능이 없다면 데스크톱에서 v2rayN의 TUN 모드로 전환할 수 있습니다.

투명 프록시를 켜자마자 원격 노드가 계속 재연결되는 이유는 무엇일까?

먼저 원격 서버 IP가 투명 규칙에 다시 걸리는지 확인하세요. 해당 IP를 직접 연결 제외 목록에 추가하고 라우터 자체에서 코어가 시작한 연결도 제외한 다음, 기존 연결 추적 기록을 삭제하고 코어를 다시 시작합니다.

메모리 256MB 라우터를 계속 사용할 수 있을까?

규칙 규모와 동시 연결 수를 제한하고 소수의 장치만 처리하면서 30분 동안 사용 가능한 메모리를 계속 관찰해 보세요. 유휴 메모리가 장시간 30MB 미만이거나 프로세스 종료가 자주 발생하고 구독 업데이트 후 다시 로드되지 않는다면 512MB 이상 바이패스 라우터 또는 데스크톱 클라이언트로 이전해야 합니다.

언제 라우터 설정을 더 이상 조정할 가치가 없을까?

장치에 투명 포워딩 모듈이 없거나 안정적인 처리량이 인터넷 회선의 3분의 1보다 낮고, 설정을 업데이트할 때마다 전체 네트워크가 자주 끊기거나 프록시가 필요한 단말이 한두 대뿐이라면 v2rayN, v2rayNG 또는 v2flyNG를 사용하는 편이 일반적으로 유지보수 비용이 낮습니다.

최종 선택은 장애 범위와 유지보수 빈도를 중심으로 결정해야 합니다. TV, 게임 기기, 워크스테이션 등 여러 단말이 통일된 규칙을 공유해야 하고 성능이 충분한 게이트웨이가 이미 있다면 바이패스 라우터가 안정적인 출발점입니다. 구독을 자주 바꾸고 노드를 비교하거나 상세 로그를 확인해야 하며 프록시 사용 장치가 소수라면 데스크톱 및 Android 클라이언트가 더 명확합니다.

메인 라우터와 바이패스 라우터 중 무엇을 선택하든 “직접 연결로 복구 가능”을 배포 계획에 먼저 포함해야 합니다. 기존 게이트웨이 주소, DNS 설정, 방화벽 백업과 서비스 중지 명령을 보관한 뒤 장치를 한 대씩 추가하세요. 라우터 프록시의 가치는 중앙 관리에서 나오지만, 중앙 관리가 장애까지 확대한다면 규칙을 더 복잡하게 만들 것이 아니라 범위를 줄여야 합니다.

V2Ray 클라이언트 다운로드