라우터 및 바이패스 라우터에서 V2Ray 코어를 직접 실행하는 배포 개요: 방식 선택과 주의사항

이 글 한눈에 보기

프록시 기능을 단일 기기에서 가정용 게이트웨이로 옮기려는 사용자에게 적합한 글입니다. 특정 관리 화면의 설치 절차보다 트래픽이 어느 기기를 통과하는지, TCP와 UDP가 코어로 어떻게 들어가는지, DNS 조회를 누가 처리하는지, 장애 발생 시 일반 연결로 어떻게 되돌릴 수 있는지를 파악하는 데 중점을 둡니다.

먼저 게이트웨이 역할을 정한 뒤 배포 위치를 선택하세요

라우터에서 V2Ray 코어를 직접 실행한다는 것은 일반적으로 Linux 게이트웨이에서 Xray 또는 V2Fly를 실행하고 라우팅 규칙으로 지정된 단말의 트래픽을 코어로 전달하는 것을 의미합니다. Xray와 V2Fly는 연결, 프로토콜, 라우팅을 실제로 처리하는 핵심 프로그램이며, v2rayN, v2rayNG, v2flyNG는 단말용 클라이언트이므로 라우터 게이트웨이 구성과 동일하게 볼 수 없습니다.

메인 라우터 배포에서는 코어를 실행하는 기기가 동시에 PPPoE 접속, DHCP, NAT, 방화벽, 기본 게이트웨이 역할을 맡습니다. 모든 단말이 자연스럽게 이 기기를 거치므로 정책 적용 범위가 완전하지만, 설정 오류가 발생하면 전체 LAN에 영향을 줄 수 있습니다. 방화벽, DNS 또는 코어 서비스를 수정하기 전에 설정을 내보내고, 유선으로 관리 주소에 로그인할 수 있는 기기를 준비해야 합니다.

바이패스 라우터 배포는 기존 메인 라우터를 유지하면서 다른 기기를 같은 LAN에 배치하는 방식입니다. 단말은 게이트웨이를 수동 설정하거나 DHCP 정책 또는 메인 라우터의 정책 라우팅을 통해 바이패스 라우터로 연결할 수 있습니다. 이전 범위를 통제하기 쉽고 TV, 업무용 PC, 테스트 기기를 단계적으로 전환할 수 있다는 장점이 있지만, 경로가 길어지고 게이트웨이 또는 반환 경로를 잘못 설정하면 루프가 발생하기 쉽습니다.

메인 라우터에 직접 배포

기본 게이트웨이, DHCP, DNS, 투명 프록시를 한 기기에 집중해 정책 진입점을 통일하며 LAN 단말을 하나씩 수정할 필요가 없습니다.

적합한 경우: 네트워크 구성이 단순하고 방화벽과 시작 서비스를 관리할 수 있을 때

바이패스 라우터에 단계적으로 연결

권장

기존 메인 라우터를 유지하고 테스트 단말이나 지정 기기만 바이패스 라우터로 보냅니다. 장애가 발생해도 기존 게이트웨이로 빠르게 되돌릴 수 있습니다.

적합한 경우: 첫 배포, 저위험 이전, 기기별 제어가 필요할 때

단말 클라이언트 병행

라우터는 일반 네트워크로 유지하고 PC에서는 v2rayN, Android 기기에서는 v2rayNG 또는 v2flyNG를 사용해 각 기기에서 프록시 상태를 관리합니다.

적합한 경우: 기기 수가 적고 각 기기에서 노드를 독립적으로 전환해야 할 때

결론: 첫 배포는 바이패스 라우터로 경로를 검증하세요

먼저 테스트 단말 한 대의 기본 게이트웨이와 DNS만 조정하고 TCP, UDP, 도메인 확인, 반환 경로가 모두 정상인지 확인한 다음 연결 범위를 넓히세요. 전체 네트워크의 기본 게이트웨이를 바로 변경하는 것보다 문제를 찾기 쉽습니다.

배포 전에 아키텍처, 메모리, 시스템 기능을 확인하세요

설치 패키지는 프로세서 아키텍처와 일치해야 합니다. 일반적인 소프트 라우터는 x86_64이고 소형 ARM 기기는 aarch64일 수 있으므로 이름이 비슷하다고 바이너리를 함께 사용할 수 있는 것은 아닙니다. uname -m을 실행해 아키텍처를 확인한 뒤 시스템에서 nftables, 정책 라우팅, TPROXY를 지원하는지 점검하세요. SOCKS 인바운드 포트 하나만 설정한다고 LAN 트래픽을 자동으로 가져올 수는 없습니다.

다음 기준은 리소스 요구 사항을 파악하는 데 적합합니다. OpenWrt 23.05.5, Linux 5.15.167, 4코어 x86_64 프로세서와 사용 가능한 메모리 512MB면 일반적인 가정용 네트워크의 규칙 매칭과 수백 Mbps급 포워딩을 처리할 수 있습니다. 대형 geosite·geoip 데이터와 상세 액세스 로그는 메모리와 저장장치 쓰기를 늘리므로, 플래시 용량이 작은 기기에서는 로그 수준을 낮추고 보관 파일 수를 적게 설정하세요.

512 MB

권장 최소 가용 메모리

12345

투명 프록시 예시 포트

1053

코어 DNS 예시 포트

LAN DNS 서비스 포트

권장 방식: 관리 영역과 포워딩 영역을 나누어 검증

게이트웨이 측

Xray 또는 V2Fly를 시스템 서비스로 시작
투명 인바운드를 12345 포트에서 수신
로컬 DNS 인바운드를 127.0.0.1:1053에서 수신
관리 주소와 LAN 대역은 직접 연결로 유지

단말 측

먼저 한 기기의 게이트웨이 주소를 고정
DNS를 분할 처리를 담당하는 게이트웨이로 지정
웹 브라우징, 다운로드, UDP 애플리케이션을 각각 테스트
전환 전후의 외부 IP와 지연 시간을 기록

코어가 시작된다는 것은 설정 문법이 통과했다는 의미일 뿐입니다. 단말 트래픽이 실제로 투명 인바운드에 들어와 반환 경로까지 완료되어야 게이트웨이 경로를 사용할 수 있습니다.

투명 프록시는 트래픽 진입과 반환 경로를 함께 처리해야 합니다

투명 프록시의 핵심은 프록시의 존재를 모르는 단말의 연결을 Xray 또는 V2Fly에 전달하는 것입니다. Linux에서는 TPROXY 또는 리디렉션이 일반적인 진입 방식입니다. 리디렉션은 TCP 처리에 더 간단하고, TPROXY는 원래 목적지 정보를 유지하면서 UDP에도 적용할 수 있지만 추가적인 fwmark, 정책 라우팅, 로컬 라우팅 테이블이 필요합니다. 구체적인 기능은 커널 모듈과 방화벽 프레임워크에 따라 달라집니다.

완전한 규칙 세트는 최소한 라우터 자체의 관리 주소, LAN 대역, 멀티캐스트 주소, 노드 서버 주소, 코어 프로세스가 생성한 연결을 먼저 제외한 뒤 프록시가 필요한 TCP와 UDP를 가로채야 합니다. 노드 서버를 제외하지 않으면 코어가 노드로 보내는 연결이 다시 투명 진입점으로 들어가 연결 시간 초과, CPU 사용량 증가 또는 동일한 대상이 로그에 반복되는 현상이 발생할 수 있습니다.

투명 인바운드를 생성하고 예를 들어 12345 포트에서 고정 수신하도록 설정한 뒤 실제 필요에 따라 TCP와 UDP를 활성화하세요.
정책 라우팅 테이블을 만들고 0x1 마크가 붙은 패킷을 로컬 루프백 인터페이스로 보냅니다.
방화벽 체인에는 먼저 직접 연결 예외를 작성한 다음 대상 트래픽에 TPROXY와 마크를 설정하세요.
코어 라우팅 규칙을 설정해 LAN, 관리 주소, 노드 주소가 direct 아웃바운드를 사용하도록 하세요.
서비스를 재시작한 뒤 프로세스 상태만 보지 말고 수신 포트, 규칙 카운터, 코어 로그를 확인하세요.

ip rule add fwmark 0x1 table 100
ip route add local 0.0.0.0/0 dev lo table 100

nft add rule inet proxy prerouting \
  meta l4proto { tcp, udp } \
  tproxy to :12345 meta mark set 0x1

DNS 분할이 도메인 규칙의 안정적인 적용을 결정합니다

트래픽 분할만 설정하고 DNS를 계획하지 않으면 도메인 규칙이 적용되지 않거나, 확인 결과와 외부 IP가 일치하지 않거나, 단말이 게이트웨이를 우회해 외부 DNS를 직접 조회하는 문제가 흔히 발생합니다. 관리 대상 단말의 DNS를 게이트웨이의 53 포트로 통일한 다음 로컬 DNS 서비스가 도메인 유형에 따라 직접 연결용 DNS를 사용하거나 코어의 로컬 DNS 인바운드로 전달하도록 구성하는 것이 좋습니다.

구조를 명확히 하려면 LAN 단말은 게이트웨이의 53 포트를 조회하고, dnsmasq가 로컬 도메인과 DHCP 호스트 이름을 담당하도록 구성합니다. 코어 처리가 필요한 조회는 127.0.0.1:1053으로 전달하고, Xray 또는 V2Fly가 DNS 규칙에 따라 아웃바운드를 선택합니다. 1053의 상위 DNS를 다시 53으로 지정하면 재귀 루프가 발생하므로 반드시 피해야 합니다.

점검 항목	권장 설정	이상 징후
단말 DNS	게이트웨이 LAN 주소의 53 포트로 지정	도메인 규칙이 간헐적으로 적용되지 않거나 외부 IP가 일치하지 않음
코어 DNS 인바운드	127.0.0.1:1053에서만 수신	포트가 LAN에 노출되거나 다른 기기에서 직접 호출됨
캐시 위치	dnsmasq 또는 코어 중 주 캐시 담당자를 명확히 지정	규칙을 변경해도 이전 주소가 계속 반환됨
IPv6 조회	IPv6 라우팅 및 프록시 정책과 함께 활성화·비활성화	단말이 정책에 포함되지 않은 IPv6 경로를 우선 사용

일반적인 OpenWrt 관리 화면에서는 「네트워크」→「인터페이스」→「LAN」→「DHCP 서버」→「고급 설정」에서 단말에 전달되는 DHCP 및 DNS 매개변수를 확인할 수 있습니다. 시스템 버전에 따라 항목 이름은 조금 다를 수 있습니다. 변경 후에는 테스트 단말이 임대 정보를 다시 받아오게 하고, 시스템의 DNS 조회 명령으로 실제 DNS 서버를 확인하세요. 화면 설정만 보고 추정해서는 안 됩니다.

결론: DNS와 투명 프록시는 함께 검수해야 합니다

테스트할 때 도메인 확인 결과, 적용된 라우팅 규칙, 실제 외부 IP를 함께 기록하세요. 웹 페이지가 열리는지만 확인하면 DNS 우회, 캐시 미갱신, IPv6 미적용 문제를 발견할 수 없습니다.

성능 테스트에서는 코어 부하와 네트워크 품질을 구분해야 합니다

게이트웨이 성능은 프로세서 코어 수만으로 판단할 수 없습니다. 암호화 알고리즘, 연결 수, 규칙 세트 크기, 로그 수준, NIC 드라이버, 하드웨어 인터럽트 분배가 모두 처리량에 영향을 줍니다. 투명 프록시를 활성화하면 일부 하드웨어 가속이나 트래픽 오프로딩이 방화벽 규칙을 우회할 수 있습니다. 일부 연결에 정책이 적용되지 않는다면 먼저 관련 오프로딩 기능을 끄고 다시 테스트하세요.

참고 테스트는 4코어 N5105, 8GB 메모리, 기가비트 유선 LAN, 500Mbps 하향 회선을 사용했으며 테스트 단말과 게이트웨이는 모두 유선으로 연결했습니다. 동일한 노드와 시간대에서 메인 라우터 직접 포워딩은 438Mbps, 같은 대역의 바이패스 라우터를 거친 경우는 421Mbps였습니다. 지속 전송 중 코어 프로세스 사용량은 단일 코어 기준 약 118%, 게이트웨이 전체 CPU 사용량은 약 34%였습니다. 이 수치는 측정 방법을 설명하기 위한 참고값일 뿐 현지 회선의 실측을 대신하지 않습니다.

먼저 프록시를 거치지 않는 LAN 처리량을 측정해 NIC 협상과 케이블 문제를 배제하세요.
그다음 외부망 직접 연결 속도를 측정하고 지연 시간, 패킷 손실, 다운로드, 업로드 기준값을 기록하세요.
투명 프록시를 활성화한 뒤 동일한 단말, 노드, 테스트 대상을 사용해 다시 측정하세요.
최소 5분 이상 지속 테스트를 진행하면서 CPU, 메모리, 온도, 연결 수를 함께 관찰하세요.
TCP 다운로드, 웹 단기 연결, UDP가 필요한 애플리케이션을 각각 테스트해 단일 결과로 전체 성능을 판단하지 마세요.

속도는 떨어졌지만 CPU 사용량이 높지 않다면 먼저 노드 품질, MTU, DNS, 반환 경로를 확인하세요. 특정 코어 하나만 계속 거의 최대 사용량에 도달하고 다른 코어가 여유롭다면 단일 연결 처리나 인터럽트 분배가 병목일 수 있습니다. 바이패스 라우터의 추가 포워딩 단계 자체가 큰 속도 저하를 자동으로 일으키는 경우는 드물며, 이중 NAT, 100Mbps 포트, 무선 반환 경로를 먼저 점검하는 편이 좋습니다.

일반적인 배포 문제와 복구 방법

게이트웨이 서비스에는 명확한 시작 순서를 설정해야 합니다. 네트워크 인터페이스와 시스템 시간이 준비된 후 코어를 시작하고, 코어가 수신에 성공한 뒤 투명 프록시 규칙을 활성화하세요. 노드에 도메인을 사용하는 경우 시간 동기화나 DNS가 아직 완료되지 않으면 첫 연결이 실패할 수 있습니다. 서비스 관리자에는 실패 후 재시작 간격도 설정해 잘못된 설정으로 인한 고빈도 재시작을 방지해야 합니다.

복구 방법은 배포 전에 준비해야 합니다. 메인 라우터 방식은 최소한 LAN 관리 주소, 유선 로그인 방법, 투명 프록시를 비활성화한 방화벽 설정 파일을 보관하세요. 바이패스 라우터 방식에서는 테스트 단말의 기본 게이트웨이와 DNS를 메인 라우터로 되돌릴 수 있습니다. 복구 작업을 이미 고장 났을 수 있는 프록시 경로에 의존해서는 안 됩니다.

코어는 실행 중인데 단말이 계속 직접 연결되는 이유는 무엇인가요?

먼저 포트 검사를 실행해 12345가 수신 중인지 확인한 다음 nftables 규칙 카운터가 증가하는지 확인하세요. 카운터가 계속 0이면 단말의 게이트웨이가 해당 기기를 가리키지 않거나 패킷이 예상한 prerouting 체인을 통과하지 않는다는 뜻일 수 있습니다.

바이패스 라우터를 활성화하자마자 LAN 기기에 접근할 수 없는 이유는 무엇인가요?

LAN 대역이 투명 규칙에서 제외되어 있는지 확인하고, 바이패스 라우터의 동일한 대역이 두 인터페이스에 동시에 설정되지 않았는지 점검하세요. 테스트 단계에서는 단일 LAN 주소를 유지해 중복 DHCP 서비스와 비대칭 반환 경로를 피해야 합니다.

웹 페이지는 열리지만 일부 UDP 애플리케이션이 시간 초과되는 이유는 무엇인가요?

투명 인바운드에서 UDP가 활성화되어 있고 정책 라우팅에도 UDP가 포함되며 방화벽이 TCP만 매칭하지 않는지 확인하세요. 그런 다음 MTU와 노드 프로토콜이 현재 전송 방식을 지원하는지 점검하고 코어 로그에서 거부된 대상 포트를 찾으세요.

도메인 규칙을 수정했는데도 이전 결과가 계속 적용되는 이유는 무엇인가요?

단말, 로컬 DNS 서비스, 코어 DNS 캐시를 차례로 비운 다음 다시 조회하세요. dnsmasq가 53 포트를 사용하고 코어가 1053 포트를 사용한다면 두 서비스가 서로 전달되어 루프를 만들지 않는지도 확인해야 합니다.

Xray와 V2Fly 중 무엇을 선택해야 하나요?

먼저 실제 노드 프로토콜에 따라 코어를 선택하세요. VLESS, XTLS, REALITY 설정을 사용한다면 일반적으로 Xray를 선택하고, 기존 VMess 등의 설정을 V2Fly 기반으로 관리하고 있다면 V2Fly를 계속 사용할 수 있습니다. 이전하기 전에 단말 클라이언트에서 동일한 설정으로 정상 연결되는지 확인하세요.

배포 완료 후 검수 목록에는 게이트웨이 재부팅 뒤 서비스 자동 복구, 구독 또는 설정 업데이트로 인한 로컬 예외 규칙 덮어쓰기 방지, DNS 조회 루프 없음, 노드 서버 주소의 항상 직접 연결, LAN 관리 주소의 프록시 우회, 코어를 끈 뒤 사전 정의된 작업으로 일반 네트워크를 복구할 수 있는지가 포함되어야 합니다. 이 조건을 충족한 후 더 많은 단말을 게이트웨이 정책에 추가하세요.