V2Ray 공유기·바이패스 게이트웨이 구성 가이드: 라우터에서 코어를 직접 실행할 때의 구조와 고려 사항

이 글 미리보기

데스크톱 클라이언트는 연결되는데 공유기에 설정하자 일부 기기에서 인터넷이 끊긴다면 노드만 바꾸기보다 트래픽 경로, DNS, 응답 경로부터 확인해야 합니다. 홈 네트워크를 조정하려는 사용자를 위해 클라이언트와 코어의 차이를 짚고, 주 라우터 직접 실행과 바이패스 게이트웨이 방식을 비교합니다. 한 기기에서 먼저 시험하고 DNS를 점검한 뒤 문제가 생기면 되돌리는 방법도 안내합니다. 본문에 나온 주소와 포트는 예시이며 소프트웨어의 기본값이 아닙니다.

클라이언트·코어·게이트웨이의 역할부터 구분하기

라우터에 구독 주소를 입력했다고 게이트웨이 구성이 끝나는 것은 아닙니다. v2rayN은 노드를 관리하고 설정을 생성해 코어를 실행하는 데스크톱 GUI 클라이언트입니다. 라우터에서는 보통 기기의 운영체제와 CPU 아키텍처에 맞는 V2Ray 또는 Xray 코어를 실행하고, 서비스 관리자와 방화벽 규칙으로 트래픽을 전달합니다. 데스크톱 설치 파일을 라우터에 복사해 실행할 수는 없습니다.

V2Ray와 Xray는 설정 형식과 기능이 서로 다릅니다. VMess와 VLESS는 프록시 프로토콜이며 WebSocket 등은 전송 방식입니다. 노드의 프로토콜, 전송 방식, 보안 매개변수가 선택한 코어와 일치해야 합니다. 구독을 v2rayN에 가져올 수 있다고 해서 라우터용 구독 변환 도구와 코어가 모든 항목을 지원한다고 단정할 수는 없습니다.

노드 연결 단계: 인증과 암호화를 처리하고 서버에 연결합니다. 먼저 노드 하나로 연결을 확인한 다음 전체 트래픽을 처리하세요.
트래픽 진입 단계: 명시적 HTTP/SOCKS 프록시는 해당 프록시를 사용하도록 설정한 앱의 요청만 받습니다. 투명 프록시를 쓰려면 트래픽 리디렉션이나 정책 라우팅을 별도로 구성해야 합니다.
게이트웨이 단계: 기기의 다음 홉, DNS, IPv4/IPv6, 방화벽을 처리합니다. 수신 포트 하나를 열어도 LAN 트래픽이 자동으로 게이트웨이를 통과하는 것은 아닙니다.

구성 방식 선택: 되돌릴 수 있는 인터넷 연결 경로부터 확보하기

집에서 프록시가 필요한 기기가 한두 대뿐이라면 데스크톱이나 Android 클라이언트로 시작하는 편이 문제를 찾기 쉽습니다. 데스크톱에는 v2rayN을 사용하고, Android에서는 Xray 코어를 사용하는 v2rayNG 또는 V2Fly 코어를 사용하는 v2flyNG를 사용할 수 있습니다. 여러 기기에 정책을 공유해야 하거나 기기별 프록시 설정이 어려운 경우에만 게이트웨이 관리 부담을 추가하는 편이 좋습니다.

바이패스 라우터를 한 기기에서 먼저 시험하기

권장

주 라우터의 PPPoE 연결, Wi-Fi, DHCP는 그대로 두고 별도 기기에서 코어를 실행합니다. 테스트용 컴퓨터 한 대의 게이트웨이를 바이패스 라우터로 수동 변경하고 연결과 DNS가 정상인지 확인한 뒤 적용 범위를 넓히세요. 권장하는 것은 단계적 전환 순서이지, 바이패스 라우터가 모든 네트워크에서 더 빠르다는 뜻은 아닙니다.

적합한 경우: 안정적인 주 라우터를 이미 사용하며 단계적으로 적용하고 쉽게 되돌리고 싶은 홈 네트워크

주 라우터에서 코어 직접 실행

PPPoE 연결, 트래픽 전달, DNS, 프록시를 한 기기에 모으면 경로가 단순해지고 정책 관리도 편리해집니다. 다만 코어 업데이트, 규칙 오류, 리소스 부족이 집 전체의 인터넷 연결에 영향을 줄 수 있으므로 설정 백업과 로컬 관리 접속 경로를 마련해야 합니다.

적합한 경우: 하드웨어 여유가 있고 방화벽과 시스템 서비스 관리에 익숙한 사용자

기기별 클라이언트 유지

각 기기에서 노드와 라우팅 방식을 따로 선택하며 홈 네트워크의 기본 게이트웨이는 변경하지 않습니다. 업데이트와 문제 해결 범위를 한 기기로 제한할 수 있지만 설정을 기기마다 관리해야 합니다. 시스템 프록시를 따르지 않는 앱은 별도로 설정해야 합니다.

적합한 경우: 기기가 많지 않고 자주 외출하며 앱별로 정책을 조정하려는 사용자

주소 계획: 바이패스 라우터를 연결한다고 자동으로 트래픽이 전달되지는 않습니다

같은 서브넷의 단일 포트 바이패스 라우터를 예로 들어 보겠습니다. 주 라우터는 192.168.10.1/24, 바이패스 라우터는 고정 주소 192.168.10.2/24, 테스트 컴퓨터는 192.168.10.100/24로 설정합니다. 바이패스 라우터 자체의 기본 경로는 주 라우터를 향하게 하고, 테스트 컴퓨터의 기본 게이트웨이는 바이패스 라우터를 향하게 합니다. 이 예시는 듀얼 포트나 여러 VLAN을 사용하는 모든 구성에 적용되지 않습니다.

대상	설정 예시	확인할 사항
주 라우터	`192.168.10.1`	인터넷 연결과 DHCP를 계속 제공합니다.
바이패스 라우터	`192.168.10.2`	고정 주소를 사용하고 동적 주소 풀과 겹치지 않게 하거나 주소 예약을 설정합니다.
테스트 컴퓨터	`192.168.10.100`	기본 게이트웨이를 먼저 `192.168.10.2`로 수동 변경합니다.
테스트 컴퓨터 DNS	`192.168.10.2`	바이패스 라우터에서 접속 가능한 DNS 서비스를 제공할 때만 이렇게 설정합니다.

같은 서브넷의 단일 포트 구성에서는 비대칭 경로가 생기기 쉽습니다. 컴퓨터가 트래픽을 바이패스 라우터로 보낸 뒤, 직접 연결 트래픽은 주 라우터를 통해 나가지만 응답은 주 라우터에서 컴퓨터로 바로 돌아올 수 있습니다. 즉시 인터넷이 끊기지는 않더라도 연결 추적, 통계, 일부 방화벽 정책에 영향을 줄 수 있습니다. 소스 주소 변환, 별도 서브넷, 추가 라우팅이 필요한지는 실제 토폴로지에 따라 판단하세요. 전체 네트워크에 적용되는 NAT 규칙을 그대로 복사해서는 안 됩니다.

예상한 DHCP 서버 하나만 활성화해 기기마다 서로 다른 게이트웨이를 무작위로 받지 않도록 합니다.
바이패스 라우터에서 IPv4 포워딩, 방화벽의 전달 권한, 응답 경로를 확인하세요. 정책 라우팅을 사용한다면 역방향 경로 필터링이 패킷을 잘못 차단하는지도 점검해야 합니다.
바이패스 라우터의 기본 경로를 자기 자신으로 지정하지 마세요. 주 라우터와 바이패스 라우터가 서로를 기본 출구로 지정하는 구성도 피해야 합니다.

순서대로 적용하기: 명시적 프록시부터 시험하고 전달 트래픽은 나중에 처리하기

먼저 코어가 연결되는지 확인하고, 그다음 게이트웨이가 트래픽을 처리하는지 확인하세요. 두 문제를 분리하면 노드 설정, 방화벽, DNS가 동시에 잘못됐을 때 원인을 찾기 쉬워집니다. 아래 절차는 주 라우터 설정을 그대로 둡니다. 시험에 실패해도 테스트 컴퓨터의 네트워크 설정만 되돌리면 됩니다.

기존 설정 기록하기

Windows에서 ‘설정’ → ‘네트워크 및 인터넷’ → 현재 연결의 ‘속성’을 열어 IP 주소, 게이트웨이, DNS를 기록합니다. 편집 메뉴는 Windows 버전에 따라 다를 수 있으므로 먼저 화면을 캡처한 뒤 테스트 컴퓨터의 설정을 변경하세요.
실행 환경 확인하기

라우터 운영체제에서 uname -m을 실행해 CPU 아키텍처를 확인하고 펌웨어의 패키지 저장소, 런타임 라이브러리, 커널 버전을 점검합니다. 해당 시스템에서 지원하는 방식으로 배포하고 실제 설치한 코어 버전을 기록하세요. 관리 화면에 표시된 버전만 기록해서는 안 됩니다.
노드 하나로 연결 확인하기

테스트용 HTTP/SOCKS 진입점만 먼저 실행합니다. 예시에서는 포트 10808을 직접 선택하고 신뢰할 수 있는 LAN에서만 접근하도록 제한한 뒤, 컴퓨터에서 명시적 프록시 요청을 보냅니다. 로그에 인증 실패, 핸드셰이크 실패, 포트 충돌이 없는지 확인하세요.
컴퓨터 한 대의 트래픽 처리하기

사용 중인 코어와 방화벽 방식에 맞춰 투명 프록시 진입점과 전달 규칙을 설정한 다음 테스트 컴퓨터의 게이트웨이를 192.168.10.2로 변경합니다. 테스트 전에 해당 컴퓨터의 시스템 프록시와 TUN을 끄세요. 요청이 여전히 기기 내 클라이언트를 통과해 성공한 것처럼 보이는 상황을 방지할 수 있습니다.
마지막으로 DHCP 조정하기

한 기기에서 안정적으로 동작하는 것을 확인한 뒤 전체 기기에 설정을 배포할지 검토하세요. 기본 OpenWrt LuCI에서는 ‘네트워크’ → ‘인터페이스’ → ‘LAN’ → ‘편집’ → ‘DHCP 서버’ → ‘고급 설정’의 ‘DHCP 옵션’에서 IPv4 게이트웨이와 DNS를 지정할 수 있습니다. 펌웨어에 따라 메뉴 이름이 다를 수 있으므로 실제 설정 항목을 확인하세요.

주 라우터에서 위 예시 설정을 DHCP로 배포한다면 DHCP 옵션 3,192.168.10.2는 IPv4 기본 게이트웨이를, 6,192.168.10.2는 DNS를 지정합니다. 변경 후 테스트 기기의 DHCP 임대를 갱신하고 실제로 받은 값을 확인하세요. 바이패스 라우터의 DNS가 작동하기 전에 전체 네트워크에 배포하지 마세요. IPv4 DHCP 옵션만으로 IPv6도 설정되는 것은 아닙니다.

# 예시: 바이패스 라우터에 HTTP/SOCKS 혼합 진입점 10808이 설정된 경우
# Windows에서는 curl.exe를 사용하고, 다른 시스템에서는 curl을 사용합니다
curl.exe --proxy socks5h://192.168.10.2:10808 --connect-timeout 10 -I https://example.com/

# 바이패스 라우터의 DNS 서비스에 응답이 있는지 확인
nslookup example.com 192.168.10.2

socks5h는 대상 도메인 이름 해석을 프록시에 맡긴다는 뜻입니다. 이 방법으로 확인할 수 있는 것은 명시적 프록시 경로뿐이며 컴퓨터의 일반 DNS 요청이나 투명 프록시가 올바르게 설정됐다는 뜻은 아닙니다. 이후에는 기기 프록시를 끈 상태에서 일반 브라우저와 실제 앱을 각각 테스트해야 합니다.

DNS·IPv6·UDP 경로를 따로 확인하기

일부 웹페이지는 열리지만 다른 페이지는 계속 로딩된다면 도메인 조회가 어디로 전달되는지 먼저 확인하세요. 앱이 시스템 DNS를 사용할 수도 있고 보안 DNS를 활성화해 HTTPS로 직접 조회할 수도 있습니다. 따라서 바이패스 라우터의 도메인 분할 규칙에서 같은 조회가 보이지 않을 수 있습니다. DNS 주소 하나만 보고 모든 앱의 조회 경로가 같다고 판단하지 마세요.

일반 DNS의 UDP/TCP 포트

10808

이 문서에서 직접 설정한 혼합 진입점

1대

처음 게이트웨이를 변경할 때 시험할 기기 수

DNS 순환 방지: 시스템 리졸버가 조회를 코어로 전달하고 코어의 상위 DNS가 같은 시스템 리졸버를 가리키면 요청이 반복해서 전달될 수 있습니다. ‘기기 → 로컬 리졸버 → 상위 DNS’의 실제 경로를 그려 보고 노드 서버 도메인을 처음 해석할 수 있는 경로를 확보하세요.
A와 AAAA 레코드를 각각 확인: A와 AAAA 레코드를 조회하고 실제 IPv4·IPv6 출구를 점검하세요. 기기가 주 라우터에서 받은 IPv6 기본 경로를 계속 사용할 수 있으므로 IPv4 게이트웨이만 바꿨다고 모든 연결이 바이패스 라우터를 거치는 것은 아닙니다.
UDP 지원 확인: 음성 통화, 게임, QUIC을 사용하는 앱은 UDP에 의존할 수 있습니다. 노드, 코어 진입점, 투명 전달 방식이 필요한 트래픽을 모두 지원하는지 확인하세요. TCP 웹페이지 테스트 한 번으로 대신할 수 없습니다.
규칙 적용 범위 제한: 게이트웨이 관리 주소, LAN 서브넷, 멀티캐스트와 브로드캐스트, 프록시 서버 연결을 어떻게 처리할지 명확히 정하세요. 코어에서 나가는 트래픽이 다시 진입점으로 들어가는 일을 막아야 합니다.

성능 비교: 단일 코어 성능·메모리·장애 영향 범위 확인

기가비트 이더넷 포트가 있다고 암호화 프록시도 기가비트 속도로 동작하는 것은 아닙니다. CPU 단일 코어 성능, 프로토콜과 전송 오버헤드, 동시 연결 수, 로그 기록, 냉각 상태가 처리량에 영향을 줍니다. 주 라우터는 PPPoE 연결, 방화벽, Wi-Fi 관리 등도 맡으므로 프록시 부하가 커지면 다른 기기의 지연 시간도 함께 늘 수 있습니다. 바이패스 라우터는 계산 부하를 분산하지만 주 라우터의 전달 병목까지 자동으로 없애 주지는 않습니다.

확인 항목	점검 방법	판단 기준
CPU 및 온도	10분간 계속 데이터를 전송하며 각 코어의 사용률과 기기 온도를 확인합니다.	특정 코어가 계속 최대 부하라면 전체 CPU 사용률만 봐서는 안 됩니다.
여유 메모리	`free` 명령어, 프로세스 사용량, 시스템 로그를 확인합니다.	캐시와 사용 가능한 메모리를 구분하고 메모리 부족으로 프로세스가 종료되는지 살펴보세요.
지연 시간 및 안정성	유휴 상태와 다운로드 중에 각각 측정하고 최소 30분간 관찰합니다.	제시된 시간은 권장 시험 시간이며 실제 측정 결과가 아닙니다.
재시작 후 복구	현장에서 복구할 수 있는 사람이 있을 때 코어와 게이트웨이를 각각 재시작합니다.	서비스 자동 시작, 규칙 복원, DNS 시작 순서를 확인합니다.

주 라우터에서 코어를 직접 실행한다면 하드웨어 오프로딩과 투명 프록시 규칙의 호환성을 중점적으로 확인해야 합니다. 일부 오프로딩 경로는 필요한 처리 체인을 우회할 수 있습니다. 속도 측정값을 높이려는 이유만으로 모든 오프로딩을 켜지 마세요. 바이패스 라우터는 전원이 꺼졌을 때의 동작도 확인해야 합니다. DHCP에서 전체 네트워크의 기본 게이트웨이로 배포한 상태라면 기기에 장애가 발생해도 주 라우터로 자동 복귀하지 않습니다.

유지보수에 대비해 코어 설정, 서비스 시작 항목, 방화벽 규칙, DHCP 설정을 보관하세요. 업데이트 전에 되돌릴 수 있는 버전을 기록하고 테스트 기기에서 구독 변환, 도메인 정책, UDP를 먼저 검증한 뒤 적용 범위를 넓히세요. 구독 업데이트가 성공해도 설정 데이터를 가져왔다는 뜻일 뿐, 모든 노드가 현재 코어에서 동작한다는 보장은 없습니다.

증상별로 문제 해결하고 데스크톱 클라이언트 역할도 유지하기

바이패스 라우터로 게이트웨이를 바꾼 뒤 컴퓨터에서 인터넷이 완전히 끊겼나요?

먼저 게이트웨이를 192.168.10.1로 되돌려 기존 네트워크가 작동하는지 확인하세요. 그다음 192.168.10.2에 접속할 수 있는지, 바이패스 라우터 자체가 인터넷에 연결되는지, 전달 권한이 활성화됐는지 점검합니다. 게이트웨이에는 접속되지만 DNS를 바꾼 뒤 도메인 접속이 실패한다면 DNS만 따로 테스트하세요. 코어를 바로 다시 설치하지 마세요.

명시적 프록시는 되지만 끄면 인터넷에 접속할 수 없나요?

노드와 명시적 프록시 진입점은 기본적으로 작동한다는 뜻입니다. 다음으로 투명 프록시 진입점, 방화벽 규칙의 일치 횟수, 정책 라우팅을 확인하세요. 컴퓨터가 실제로 사용하는 기본 게이트웨이를 확인한 뒤 요청이 대상 규칙에 들어가는지 살펴보세요. 이미 확인된 노드 인증 설정을 반복해서 바꾸지 마세요.

컴퓨터는 정상인데 같은 Wi-Fi에 연결한 휴대폰은 바이패스 라우터를 거치지 않나요?

휴대폰이 현재 받은 게이트웨이와 DNS를 확인하고 Wi-Fi에 다시 연결해 DHCP 임대를 갱신한 뒤 IPv6 경로와 앱 자체의 DNS 설정을 점검하세요. 휴대폰에서 v2rayNG 또는 v2flyNG를 계속 실행 중이라면 연결을 먼저 일시 중지한 다음 게이트웨이 경로를 테스트하세요. 두 설정이 겹쳐 판단을 흐리는 일을 막을 수 있습니다.

집에 바이패스 라우터가 있어도 v2rayN을 사용할 수 있나요?

사용할 수 있지만 역할을 분명히 나눠야 합니다. 평소에는 데스크톱이 게이트웨이를 사용하도록 하고, 노드를 따로 시험할 때는 v2rayN의 ‘시스템 프록시’에서 ‘시스템 프록시 자동 설정’을 선택하세요. 게이트웨이가 해당 노드 연결을 다시 프록시 처리하는지도 확인하고, 필요하면 명확한 직접 연결 규칙을 설정해 의도치 않은 이중 프록시를 방지하세요.

최종 점검은 웹페이지가 열리는지만 확인해서는 안 됩니다. LAN 공유, 프린터, 음성 통화, 자주 쓰는 앱이 정상인지 확인하고 DNS 및 IPv6 경로를 시험하세요. 네트워크 설정을 자동으로 받도록 되돌렸을 때 기존 연결 방식으로 복구되는지도 검증해야 합니다. 시스템 트래픽 전달 규칙에 익숙하지 않다면 기기별 클라이언트를 유지하고 게이트웨이 적용 범위를 통제 가능한 시험 환경으로 제한하는 편이 집 전체의 출구를 바로 바꾸는 것보다 관리하기 쉽습니다.