Xray를 개별 기기에서 가정용 네트워크 게이트웨이로 옮기려는 사용자를 위한 안내입니다. 메인 라우터에서 실행하는 방식과 별도 바이패스 라우터를 먼저 구분한 뒤, 예시 네트워크 대역을 기준으로 게이트웨이·DNS·투명 프록시 진입점·응답 경로의 관계를 살펴봅니다. 한 대의 기기부터 시험 운용하고 추가로 필요한 포워딩 규칙을 파악하며, 메인 라우터를 통한 기존 연결로 되돌리는 방법도 확인할 수 있습니다.
1. Xray 코어와 라우터의 역할
Xray는 프록시 프로토콜, 인바운드, 아웃바운드, 라우팅 규칙을 처리하는 코어이지 라우터 운영체제 전체가 아닙니다. 기기에 실행 파일을 넣는 것만으로 해결되는 건 프로그램 실행 여부뿐입니다. 패킷 포워딩, DNS 서비스, 방화벽 연동, 부팅 시 자동 실행은 운영체제와 배포 방식에서 따로 설정해야 합니다. v2rayN은 데스크톱 클라이언트이고 v2rayNG는 Xray 코어를 사용하는 Android 클라이언트입니다. 두 프로그램의 설치 파일을 라우터 서비스로 바로 설치할 수는 없습니다.
배포 전에 CPU 아키텍처, 시스템 버전, 사용 가능한 메모리와 저장 공간을 확인하세요. 펌웨어 패키지 관리자가 제공하는 패키지는 특정 시스템 라이브러리에 의존할 수도 있습니다. 파일명에 ARM이 포함됐다는 이유만으로 호환된다고 판단하면 안 됩니다. 아래 내용은 OpenWrt의 네트워크 관리 방식을 예로 듭니다. 실제 지원 기능은 기기 펌웨어와 설치 패키지를 기준으로 확인하세요.
- 시스템 계층: 네트워크 인터페이스 주소, 기본 경로, IP 포워딩, IPv6 라우팅, 방화벽.
- 트래픽 유도 계층: 처리할 TCP 또는 UDP 트래픽을 투명 프록시 리스닝 포트로 전달합니다.
- 코어 계층:
inbounds는 연결을 받고,routing.rules는 조건을 매칭하며,outbounds는 프록시 또는 직접 연결 경로를 정의합니다. - DNS 계층: 클라이언트가 어떤 DNS를 사용하는지, 질의를 어떻게 분기하는지, 상위 DNS 요청이 다시 프록시 규칙에 걸리는지 확인합니다.
2. 메인 라우터와 바이패스 라우터의 구성 범위
메인 라우터는 보통 인터넷 연결, DHCP, NAT, 방화벽을 담당합니다. 여기에 Xray를 실행하면 트래픽 진입점이 한곳에 모이지만, 규칙 오류가 전체 로컬 네트워크에 영향을 줄 수 있습니다. 별도 바이패스 라우터는 테스트 기기 한 대만 우선 연결하기 편하지만, 전달 경로가 늘어나고 응답 경로 불일치, 중복 DHCP, 게이트웨이 설정 오류의 위험도 생깁니다.
두 가지 구성 방식: 기기의 기본 게이트웨이를 먼저 확인하세요
메인 라우터에서 Xray 실행
- 기기의 기본 게이트웨이는 계속 메인 라우터 주소를 사용합니다.
- 포워딩 진입점에서 지정한 기기나 트래픽을 가로챕니다.
- 인터넷 연결, 무선 기능, 프록시가 함께 사용하는 자원을 고려해야 합니다.
- 방화벽을 변경하기 전에 로컬 관리 연결을 확보하세요.
별도 바이패스 라우터에서 Xray 실행
- 테스트 기기 한 대의 게이트웨이를 바이패스 라우터 주소로 변경합니다.
- 바이패스 라우터의 기본 경로는 메인 라우터를 가리킵니다.
- 단일 포트로 같은 네트워크 대역에 연결하는 구성은 응답 경로를 별도로 확인해야 합니다.
- 계획 없이 두 번째 DHCP 서비스를 켜지 마세요.
첫 배포에서는 메인 라우터의 설정을 그대로 유지하고 기기 한 대만 바이패스 라우터를 거치게 하세요. 검증이 끝난 뒤 적용 범위를 넓히면 됩니다.
바이패스 라우터에 반드시 네트워크 포트가 두 개 필요한 것은 아닙니다. 단일 포트로 같은 로컬 네트워크에서 송수신할 수 있지만, 그렇다고 포워딩 규칙을 생략해도 되는 것은 아닙니다. 포트가 두 개라고 자동으로 네트워크가 분리되는 것도 아닙니다. 두 인터페이스를 같은 브리지에 연결하면 실제로는 같은 2계층 네트워크에 속할 수 있습니다.
3. 고정 IP 주소로 게이트웨이와 응답 경로 이해하기
아래 표는 설명을 위한 IPv4 구성 예시이며, 기기의 기본값이나 성능 테스트 결과가 아닙니다. 먼저 이 주소들이 다른 기기에서 사용 중이지 않은지 확인하고, 고정 주소는 DHCP 동적 할당 범위에서 제외하세요. 테스트 기기만 설정을 변경하고 나머지 기기는 계속 메인 라우터를 사용합니다.
| 기기 | IPv4 주소 | 기본 게이트웨이 | DNS |
|---|---|---|---|
| 메인 라우터 | 192.168.10.1/24 | 인터넷 서비스 제공업체 상위망 | 현재 네트워크 설정에 따름 |
| 바이패스 라우터 | 192.168.10.2/24 | 192.168.10.1 | 직접 지정한 DNS 서버 |
| 테스트 기기 | 192.168.10.100/24 | 192.168.10.2 | 192.168.10.2 |
기기의 DNS를 192.168.10.2로 설정하려면 바이패스 라우터가 해당 주소의 53번 포트에서 실제로 DNS 서비스를 제공하고 로컬 네트워크의 질의를 허용해야 합니다. Xray만 설치했다고 DNS 서비스까지 자동으로 제공되는 것은 아닙니다. 메인 라우터와 바이패스 라우터가 같은 네트워크 대역에 있다면, 메인 라우터의 관리 주소로 직접 접속할 때는 보통 기본 게이트웨이를 거치지 않고 2계층에서 통신합니다.
단일 인터페이스 바이패스 라우터에서 직접 연결 트래픽을 전달하면 기기에서 바이패스 라우터로 나간 요청에 메인 라우터가 기기로 바로 응답할 수 있습니다. 이 경우 상태 기반 방화벽이나 연결 추적에 문제가 생길 수 있습니다. 소스 주소 변환을 사용하면 응답이 바이패스 라우터로 돌아오게 할 수 있지만, 상위 라우터에서 보이는 소스 주소가 바뀌므로 모든 구성에 적용할 수 있는 만능 설정은 아닙니다. ICMP 리디렉션 때문에 기기가 메인 라우터로 경로를 바꾸는지, 방화벽에서 같은 인터페이스 간 포워딩을 허용하는지도 확인하세요.
- 바이패스 라우터의 기본 경로가
192.168.10.1을 가리키는지 확인하세요. - IPv4 포워딩이 활성화돼 있는지, 포워딩 체인에서 테스트 기기의 트래픽을 허용하는지 확인하세요.
- 프록시 트래픽과 직접 연결 트래픽을 각각 살펴보세요. 웹페이지 한 번 접속한 결과로 모든 경로를 판단하지 마세요.
- IPv6가 여전히 메인 라우터에서 제공하는 기본 경로를 사용한다면 IPv4 게이트웨이 변경만으로 IPv6 트래픽까지 자동으로 처리되지는 않습니다.
4. 투명 프록시 진입점과 Xray 라우팅은 서로 다른 계층입니다
명시적 프록시는 애플리케이션이 SOCKS 또는 HTTP 진입점에 직접 연결하는 방식입니다. 투명 프록시는 네트워크 규칙으로 연결을 코어에 전달합니다. Xray에 리스닝 포트를 추가하는 것만으로 로컬 네트워크의 기기가 자동으로 해당 포트를 사용하는 것은 아닙니다. 이 문서의 12345는 예시로 지정한 포트입니다. 실제 투명 프록시 진입점 및 방화벽의 전달 대상과 일치시켜야 합니다.
단일 기기에서 명시적 프록시 테스트
권장먼저 로컬 네트워크에서 접속 가능한 SOCKS 또는 HTTP 인바운드로 노드, 인증서, 아웃바운드 설정을 확인하세요. 접속 가능한 소스 주소를 제한하고 테스트가 끝나면 더 이상 필요하지 않은 진입점을 닫습니다. 이 단계의 테스트를 통과해도 투명 프록시가 작동한다고 볼 수는 없습니다.
적합한 경우: 첫 배포에서 노드와 코어 설정 문제를 먼저 제외하고 싶을 때
REDIRECT 방식
일반적으로 TCP 트래픽에 사용하는 방식이며, 해당 인바운드가 원래 목적지 주소를 확인할 수 있어야 합니다. TCP 리디렉션 규칙을 모든 UDP 트래픽에 그대로 적용하면 안 됩니다. NAT 체인만 설정했다고 모든 프로토콜이 처리되는 것도 아닙니다.
적합한 경우: TCP만 처리하는 것이 명확하고 펌웨어에서 호환되는 설정을 제공할 때
TPROXY 방식
TCP와 UDP에 모두 사용할 수 있지만 커널 지원, 정책 라우팅, 트래픽 마크, 호환되는 투명 소켓 설정이 필요합니다. 마크 값, 라우팅 테이블, 인바운드 설정을 한 묶음으로 확인해야 합니다.
적합한 경우: UDP 트래픽도 처리해야 하고 정책 라우팅을 관리할 수 있을 때
OpenWrt 22.03부터 기본 방화벽은 firewall4와 nftables를 사용합니다. 기존 구성을 유지할 때는 실제 방화벽 백엔드를 먼저 확인하세요. 예전 iptables 스크립트를 새 펌웨어에 그대로 추가한 뒤 명령의 종료 코드만으로 배포 성공 여부를 판단하면 안 됩니다. 투명 프록시 규칙에서는 코어가 자체적으로 만드는 프록시 연결, 관리 주소, 필요한 로컬 서비스를 제외해 트래픽이 다시 자기 자신에게 들어오는 일을 방지해야 합니다.
5. DNS 분기는 연결 경로와 함께 구성하세요
기기의 DNS 질의 경로와 목적지 IP 주소로 연결하는 경로는 서로 다릅니다. 게이트웨이를 바이패스 라우터로 바꿔도 브라우저 자체의 암호화 DNS까지 자동으로 처리되지는 않습니다. DNS를 바이패스 라우터로 지정해도 기본 게이트웨이가 자동으로 바뀌지는 않습니다. 시험 운용 중 어떤 기기가 시스템 DNS를 사용하는지, 어떤 앱이 직접 DNS를 조회하는지 확인해야 합니다.
- 진입점:
192.168.10.2:53에서 서비스가 실행 중이고 TCP 및 UDP 질의가 모두 도달하는지 확인합니다. - 상위 DNS: 로컬 DNS 리졸버가 요청을 어디로 전달하는지 확인합니다. 상위 DNS에 프록시를 사용한다면 프록시 연결 자체가 아직 준비되지 않은 동일한 DNS 경로에 의존하지 않도록 해야 합니다.
- 규칙:
domainStrategy는 라우팅 규칙 매칭 시 DNS 조회 결과를 사용하는 방식을 제어합니다. 로컬 네트워크의 DNS 트래픽을 전부 가로채는 스위치는 아닙니다. - 도메인 정보: 투명 프록시 트래픽에 매칭 가능한 도메인 정보가 항상 포함되는 것은 아닙니다. 스니핑으로 모든 암호화 연결의 도메인을 알아낼 수 있는 것도 아닙니다.
- 캐시: DNS 경로를 바꾼 뒤에는 새 연결로 다시 테스트하고, 필요에 따라 기기와 로컬 DNS 리졸버의 캐시를 갱신해 이전 기록이 판단에 영향을 주지 않도록 하세요.
테스트 기기에 해당 도구가 설치돼 있다면 아래 두 명령으로 일반 UDP 질의와 TCP 질의를 각각 확인할 수 있습니다. 응답을 받았다는 사실은 해당 DNS 진입점이 작동한다는 뜻일 뿐, 요청이 예상한 상위 DNS를 거쳤다는 보장은 아닙니다. 상위 경로는 DNS 서비스 로그와 대조해 확인하세요.
dig @192.168.10.2 example.com A
dig +tcp @192.168.10.2 example.com A
IPv6도 함께 계획해야 합니다. 기기는 라우터 광고를 통해 IPv6 기본 게이트웨이와 DNS를 받을 수 있고, 애플리케이션이 AAAA 레코드를 우선 사용할 수도 있습니다. IPv6 트래픽 처리를 구성하기 전에는 테스트 기기의 IPv6 경로를 명시적으로 제어하고 설정을 기록하세요. IPv4 접속만 성공했다고 전체 네트워크에 적용됐다고 판단하면 안 됩니다.
6. 기기 한 대부터 적용하기
아래 메뉴 경로는 OpenWrt 23.05 계열의 기본 LuCI 한국어 인터페이스를 기준으로 합니다. 커스텀 펌웨어에서는 메뉴 이름이 다를 수 있습니다. 네트워크 주소를 변경하면 관리 연결이 끊길 수 있으므로 작업 전에 유선으로 접속할 수 있도록 준비하고, 메인 라우터 주소와 기존 DHCP 설정을 기록한 뒤 현재 설정을 백업하세요.
-
현재 설정 기록
「시스템」→「백업/업그레이드」에서 현재 설정을 백업하세요. 테스트 기기의 기존 게이트웨이와 DNS를 기록하고 메인 라우터
192.168.10.1에 직접 접속할 수 있는지 확인하세요. -
바이패스 라우터에 고정 주소 설정
「네트워크」→「인터페이스」→「LAN」→「편집」→「기본 설정」에서 예시처럼 고정 IP
192.168.10.2/24를 설정하고 IPv4 게이트웨이를192.168.10.1로 지정합니다. 저장 후 적용하고 새 주소로 다시 로그인하세요. -
중복 할당 방지
바이패스 라우터의 「네트워크」→「인터페이스」→「LAN」→「편집」→「DHCP 서버」→「일반 설정」에서 「이 인터페이스 무시」가 선택돼 있는지 확인하세요. 같은 네트워크 대역에서 테스트하는 동안에는 메인 라우터만 DHCP 주소를 할당하도록 유지합니다.
-
코어 진입점 확인
먼저 Xray 설정과 노드 연결을 테스트한 뒤 계획한 투명 프록시 규칙을 활성화하세요. 리스닝 포트, 포워딩 정책, DNS 서비스, 코어 자체 트래픽 제외 설정을 확인하고 다른 기기의 방화벽 명령 전체를 그대로 복사하지 마세요.
-
테스트 기기만 변경
테스트 기기의 게이트웨이를
192.168.10.2로 바꾸세요. DNS 서비스가 정상인지 확인한 다음 DNS도 해당 주소로 지정합니다. 웹페이지, UDP를 사용하는 앱, 로컬 네트워크 공유, 라우터 관리 페이지를 각각 테스트하세요. -
검증 후 적용 범위 확대
바이패스 라우터를 재부팅한 뒤 다시 테스트하세요. 서비스 시작 순서, 규칙 복구, DNS 준비 상태를 확인한 다음 DHCP 옵션 3으로 게이트웨이를, 옵션 6으로 DNS를 배포할지 검토하세요. 이미 주소를 할당받은 기기는 임대를 갱신한 뒤 실제로 받은 설정을 확인해야 합니다.
7. 증상별로 점검하고 한 번에 한 계층만 변경
다음 순서로 확인하는 것이 좋습니다: 기기 주소와 경로, 바이패스 라우터 포워딩, DNS, 코어 진입점, 프록시 아웃바운드. 한 번에 한 항목만 변경하고 변경 전후 로그를 기록하세요. 아래 명령은 Linux 게이트웨이에서 상태를 조회하는 용도입니다. 경량 펌웨어에서는 관련 도구를 별도로 설치해야 할 수 있습니다.
ip -4 route
ip -6 route
ip rule show
sysctl net.ipv4.ip_forward
ss -lntup
nft list ruleset
게이트웨이를 바꾼 뒤 모든 웹페이지에 접속할 수 없나요?
먼저 테스트 기기의 게이트웨이를 192.168.10.1로 되돌려 기존 네트워크가 정상인지 확인하세요. 그런 다음 바이패스 라우터의 기본 경로, IP 포워딩, 방화벽 포워딩 카운터를 점검합니다. 노드부터 바꾸지 마세요. DNS를 바이패스 라우터로 지정했다면 53번 포트에서 DNS 서비스가 실행 중인지도 확인해야 합니다.
웹페이지는 열리지만 음성 통화나 게임이 연결되지 않나요?
TCP 트래픽만 처리하도록 구성한 것은 아닌지 확인한 뒤 UDP 인바운드, 정책 라우팅, 아웃바운드 지원 여부를 점검하세요. 애플리케이션 로그에서 실패한 프로토콜을 확인해야 합니다. TCP 웹페이지가 열린다고 UDP와 DNS 포워딩까지 정상이라고 볼 수는 없습니다.
바이패스 라우터를 사용하는 기기와 사용하지 않는 기기가 있는 이유는 무엇인가요?
DHCP 관리 화면만 확인하지 말고 각 기기에서 실제 게이트웨이와 DNS를 확인하세요. 고정 IP, 이전 DHCP 임대, 앱 자체 DNS 조회, IPv6 기본 경로 때문에 기기별 차이가 생길 수 있습니다. 먼저 같은 기기에서 IPv4와 IPv6 경로를 각각 확인하세요.
재부팅하면 작동하지 않지만 수동으로 실행하면 정상인가요?
서비스 시작 로그를 확인해 네트워크, 시간 동기화, DNS가 프록시 연결보다 먼저 준비되는지 확인하세요. 방화벽을 다시 불러온 뒤에도 트래픽 유도 규칙이 유지되는지 점검합니다. 재시도 횟수를 제한하기 전에 시작 순서의 의존성을 해결하고, 설정 문제를 계속 재시작하는 방식으로 덮지 마세요.
적용 전에 복구 방법 세 가지를 마지막으로 확인하세요. 기기의 게이트웨이를 기존 값으로 되돌릴 수 있고, 메인 라우터 관리 페이지에 계속 접속할 수 있으며, 바이패스 라우터 서비스를 중지해도 비어 있는 포트를 가리키는 규칙이 남지 않아야 합니다. CPU 아키텍처, 노드 프로토콜, 회선 조건은 크게 다르므로 기기 광고에 나온 대역폭만으로 프록시 처리량을 계산할 수 없습니다. 실제 사용 테스트, 자원 사용량, 연결 로그를 바탕으로 적용 범위를 넓히세요.