라우터·바이패스 라우터에서 Xray 실행하기: 투명 프록시 구성 가이드

핵심 내용 미리보기

라우터에서 Xray를 실행하려면 코어 설정뿐 아니라 트래픽 가로채기, 정책 라우팅, DNS도 함께 구성해야 합니다. 데스크톱 클라이언트로 연결을 확인했고 프록시를 게이트웨이로 옮기려는 사용자를 대상으로, 먼저 메인 라우터와 바이패스 라우터 중 하나를 선택한 뒤 단일 기기에서 TCP·UDP·DNS 조회·응답 경로를 검증하고 적용 범위를 넓히는 순서를 안내합니다. 아래 주소와 포트는 구성 예시이며, 모든 펌웨어에 그대로 적용할 수 있는 설정은 아닙니다.

먼저 Xray 코어와 클라이언트의 역할 구분하기

Xray는 인바운드, 아웃바운드 및 라우팅 규칙을 처리하는 핵심 프로그램입니다. v2rayN은 설정을 관리하고 코어를 실행하는 데 사용하는 데스크톱 클라이언트입니다. v2rayN에서 작동하는 노드를 라우터로 옮긴다고 해서 데스크톱 프록시 환경 전체가 그대로 이전되는 것은 아닙니다. Linux 게이트웨이에는 방화벽 규칙, 패킷 전달 설정, DNS 서비스와 서비스 시작 관리도 필요합니다.

VMess와 VLESS는 프록시 프로토콜이지, 트래픽을 투명하게 가로채는 방식이 아닙니다. 노드의 프로토콜, 전송 계층, TLS 또는 REALITY 설정은 서버와 일치해야 합니다. REDIRECT와 TPROXY는 LAN 트래픽을 로컬 코어로 전달하는 방식을 결정합니다. 아웃바운드 연결이 성공해도 전체 구성 중 한 단계가 정상이라는 뜻일 뿐입니다.

코어 설정: 수신 연결, 노드 아웃바운드, 직접 연결 경로와 도메인 또는 IP 매칭 규칙을 정의합니다.
시스템 네트워크: 지정한 기기의 트래픽을 인바운드로 보내고 응답이 원래 기기로 돌아가도록 처리합니다.
DNS 경로: 도메인을 조회하는 주체와 요청 경로를 정하고, 조회 결과가 라우팅 규칙과 맞물리는지 결정합니다.
서비스 관리: 시작·재시작, 로그, 권한 및 장애 시 복구를 관리합니다. 노드 공유 링크만으로 제공되는 기능이 아닙니다.

메인 라우터와 바이패스 라우터: 장애 영향 범위에 맞춰 선택

메인 라우터는 보통 인터넷 연결, DHCP, NAT와 기본 게이트웨이를 이미 담당하므로 트래픽 처리 지점이 명확하지만, 규칙을 잘못 설정하면 네트워크 전체에 영향을 줄 수 있습니다. 바이패스 라우터를 사용하면 실험 환경을 메인 라우터와 분리해 우선 단일 기기만 대상으로 시험할 수 있습니다. 다만 기본 게이트웨이, DNS, 응답 경로를 명확히 구성해야 하며, 랜선을 연결하는 것만으로 트래픽이 자동으로 이 경로를 통과하지는 않습니다.

단일 기기부터 바이패스 라우터로 테스트

권장

메인 라우터의 기존 설정은 유지하고 테스트 기기 한 대의 IPv4 게이트웨이와 DNS만 바이패스 라우터로 지정합니다. 문제가 생기면 해당 기기의 자동 설정을 복원하면 되므로 영향 범위가 작습니다.

적합한 경우: 첫 배포, 투명 프록시 검증, 기존 네트워크 유지가 필요한 경우

메인 라우터에서 일괄 처리

실제 패킷 전달 경로에서 클라이언트 트래픽을 한꺼번에 처리하므로 네트워크 구성이 비교적 명확합니다. 작업 전 DHCP, 방화벽, DNS 설정을 백업하고 로컬 관리 접속 방법을 준비해야 합니다.

적합한 경우: Linux 네트워크에 익숙하고 여러 기기를 일괄 관리하려는 경우

결론: 먼저 기기 한 대만 적용하고, DHCP 전체 변경은 나중에

테스트 기기의 게이트웨이와 DNS를 먼저 수동 지정하고, 전원 재시작과 설정 복구까지 확인한 뒤 DHCP 할당 범위를 조정하세요. 최초 디버깅과 네트워크 전체 이전을 한 번에 진행하지 마세요.

같은 서브넷의 바이패스 라우터를 예로 들면 메인 라우터는 192.168.10.1, 바이패스 라우터는 192.168.10.2, 테스트 기기는 192.168.10.100입니다. 바이패스 라우터의 기본 경로는 메인 라우터를 향하게 하고, 테스트 기기의 기본 게이트웨이는 바이패스 라우터로 지정합니다. 주소가 이미 사용 중이지 않은지 확인하고 DHCP 주소 풀에서 고정 주소를 제외하세요.

투명 프록시 경로: REDIRECT와 TPROXY 구분하기

투명 프록시를 사용하면 HTTP나 SOCKS 프록시를 직접 설정하지 않은 기기도 게이트웨이 규칙에 따라 트래픽을 전달할 수 있습니다. 일반적인 경로는 “기기 → 게이트웨이 방화벽 → Xray 인바운드 → 라우팅 선택 → 아웃바운드”입니다. 트래픽이 게이트웨이를 지나지 않는다면 Xray 라우팅 규칙을 바꿔도 효과가 없습니다.

방식	주요 적용 범위	구성 시 확인 사항
명시적 프록시	프록시를 직접 설정한 앱	노드 아웃바운드가 정상인지 확인하는 단계일 뿐, 모든 기기의 트래픽이 처리된다는 뜻은 아닙니다.
REDIRECT	주로 TCP 투명 처리에 사용	원래 목적지를 식별하도록 구성해야 합니다. 이것만으로 UDP까지 처리된다고 볼 수는 없습니다.
TPROXY	TCP 및 UDP	투명 소켓, 패킷 마킹, 정책 라우팅을 함께 구성

TPROXY는 방화벽 규칙 한 줄만 추가한다고 동작하지 않습니다. 커널과 방화벽 백엔드가 관련 기능을 지원해야 하며, 마킹된 패킷은 정책 라우팅을 통해 로컬 기기로 전달되어야 합니다. Xray 인바운드에도 투명 프록시 설정이 필요합니다. nftables를 사용하는 시스템에 출처가 불분명한 iptables 스크립트를 섞지 마세요. 호환 명령을 사용할 수 있더라도 실제로 어떤 규칙이 생성됐는지 확인해야 합니다.

예약된 목적지 주소 제외: 실제 네트워크에 맞춰 루프백, LAN, 브로드캐스트, 멀티캐스트 등 프록시를 거치면 안 되는 목적지 주소를 제외하고 라우터 관리와 DHCP 통신은 유지하세요.
노드 연결 제외: 프록시 서버로 향하는 연결이 동일한 인바운드에서 다시 처리되지 않도록 해야 합니다. 그렇지 않으면 무한 루프가 발생합니다.
포워딩 트래픽과 로컬 트래픽 구분: 전달되는 트래픽과 게이트웨이가 직접 생성한 트래픽은 서로 다른 훅을 사용합니다. 최초 배포에서는 LAN에서 전달되는 트래픽만 처리하세요.
마킹 충돌 방지: 정책 라우팅 마크는 멀티 WAN 연결이나 트래픽 셰이핑 등의 기능과 공유될 수 있습니다. 사용 전에 기존 규칙과 마스크를 확인하세요.

문제 해결을 위해 방화벽 전체를 끄지 마세요. 투명 프록시 수신 포트는 필요한 출발지에서만 접근할 수 있도록 하고 인터넷에 노출하지 않아야 합니다. 로그에 권한 오류가 나타나면 투명 소켓에 필요한 권한과 서비스 실행 계정을 확인하세요. 모든 서비스를 계속 높은 권한으로 실행하도록 바꾸는 것은 해결책이 아닙니다.

DNS 분기: DNS 조회와 트래픽 출구 경로 맞추기

웹 페이지가 열리지 않는다고 해서 반드시 노드에 문제가 있는 것은 아닙니다. 기기가 메인 라우터에서 받은 DNS를 계속 사용하거나 앱 내 암호화 DNS로 지정된 경로를 우회할 수 있습니다. DNS 요청이 바이패스 라우터에 도착하더라도 DNS 서버의 아웃바운드 경로와 실제 접속 경로가 다르면 현재 출구에 적합하지 않은 주소를 반환할 수 있습니다.

일반 DNS의 TCP 및 UDP 포트

12345

이 문서에서 사용하는 투명 프록시 인바운드 예시 포트

경로 2개

IPv4와 IPv6를 각각 확인

여기서 12345는 예시로 정한 값이며 Xray의 고정 포트가 아닙니다. 방화벽의 전달 대상 포트와 인바운드 수신 포트는 일치해야 합니다. 일반 DNS는 UDP와 TCP를 모두 사용할 수 있으므로 UDP 53만 허용해서는 안 됩니다. 암호화 DNS는 포트 53 규칙만으로 경로를 판단할 수 없습니다.

DNS 설정 확인: 라우터의 상위 DNS 주소만 바꾼 것이 아니라, 기기가 실제로 받은 DNS 주소가 계획한 조회 지점을 가리키는지 확인하세요.
항목별로 검증: 내부 도메인, 직접 연결 도메인, 프록시 접속 도메인을 각각 테스트하고 응답 주소와 최종 출구를 기록하세요.
초기 DNS 조회 확인: 노드 주소가 도메인이라면 프록시 연결을 시작하기 전에 해당 도메인을 조회할 수 있어야 합니다. 프록시를 통해야 DNS를 조회할 수 있고 프록시도 DNS 응답을 기다리는 순환 의존성을 피하세요.
캐시 정리: 규칙을 바꾼 뒤 기기와 게이트웨이의 관련 캐시를 비우고 테스트 앱을 다시 시작하세요. 이전 DNS 응답이나 연결이 결과 판정을 방해하지 않도록 합니다.

도메인 분기는 대상 정보가 어디서 오는지에도 영향을 받습니다. 투명 인바운드에서는 원래 목적지가 IP 주소인 경우가 많습니다. 트래픽 스니핑은 식별 가능한 프로토콜에서 도메인 정보를 보완할 수 있지만 모든 연결의 도메인을 복원한다고 보장하지는 않습니다. 도메인 규칙을 사용한다면 DNS 설계, 스니핑 설정, 규칙 순서를 함께 확인하세요. 스니핑을 켜는 것만으로 완전한 구성이 되지는 않습니다.

단계별 배포: 아웃바운드 테스트부터 단일 기기 적용까지

아래는 일반적인 Linux 게이트웨이를 기준으로 정리한 순서입니다. 설정 경로와 서비스 이름은 설치 방식에 따라 다릅니다. 명령에 나오는 /etc/xray/config.json과 xray.service는 구체적인 예시이므로 사용 전 실제 경로를 확인하세요. 경량 펌웨어는 다른 서비스 관리자를 사용할 수 있습니다.

네트워크 정보 기록

메인 라우터 주소, DHCP 범위, DNS, 인터페이스 이름과 방화벽 규칙을 저장하세요. 변경 중인 원격 연결에만 의존하지 말고 유선 연결이나 로컬 콘솔로 설정을 복구할 수 있는지 확인하세요.
아웃바운드 확인

프로세서 아키텍처와 Xray 버전을 확인한 뒤 노드 설정부터 테스트하세요. 루프백 주소에서만 수신하는 명시적 프록시를 이용해 아웃바운드를 검증하고, 아직 네트워크 전체를 처리하는 규칙은 추가하지 마세요.
인바운드 확인

투명 인바운드 포트를 정하고 사용 중인 포트가 있는지 확인하세요. TPROXY를 사용한다면 인바운드의 투명 프록시 설정, 시스템 지원 여부, 정책 라우팅과 마킹을 함께 점검하세요. 프로세스가 실행 중인지 확인하는 것만으로는 충분하지 않습니다.
단일 기기 적용

테스트 기기 192.168.10.100의 트래픽만 매칭하세요. 먼저 TCP를 테스트한 뒤 UDP 전달을 실제로 지원하는 아웃바운드인지 확인하세요. 웹 페이지가 열린다는 이유만으로 UDP도 정상이라고 판단하지 마세요.
DNS 연동 테스트

테스트 기기의 DNS를 설정된 조회 지점으로 지정하고 직접 연결, 프록시, 내부 네트워크, IPv6 경로를 각각 확인하면서 코어와 방화벽 로그를 살펴보세요.
복구 절차 확인

게이트웨이를 재시작해 서비스 시작 순서와 규칙 유지 여부를 확인하세요. 코어를 중지해 장애 시 동작을 시험한 다음 DHCP를 통해 적용 범위를 넓힐지 결정하세요.

읽기 전용으로 먼저 확인한 뒤 패킷 전달 규칙 수정

# 프로그램 버전과 설정 확인; 설정 검사 통과가 원격 연결 성공을 뜻하지는 않음
xray version
xray run -test -config /etc/xray/config.json

# IPv4·IPv6 라우팅 및 IPv4 정책 라우팅 확인
ip -4 route show
ip -6 route show
ip -4 rule show

# 수신 포트와 현재 nftables 규칙 확인
ss -lntup
nft list ruleset

# systemd를 사용하고 서비스 이름이 xray인 설치에만 적용
systemctl status xray --no-pager
journalctl -u xray -n 80 --no-pager

일부 규칙과 프로세스 정보를 확인하려면 관리자 권한이 필요할 수 있습니다. 규칙을 점검할 때 테스트 트래픽에 따라 매칭 횟수가 증가하는지 살펴보세요. 횟수가 늘지 않으면 인터페이스, 출발지 주소, 체인 연결 위치를 먼저 확인합니다. 횟수는 늘지만 코어에 해당 기록이 없으면 포트, 정책 라우팅, 인바운드 설정을 확인하세요. 여러 계층을 한꺼번에 바꾸면 어떤 변경이 효과를 냈는지 파악하기 어렵습니다.

라우팅과 성능: 근거를 바탕으로 병목 찾기

라우팅 규칙은 일반적으로 순서대로 매칭되며, 프로토콜과 도메인 처리 정책, IP 조회 동작에도 영향을 받습니다. 먼저 명확한 LAN 규칙과 필수 예외를 배치한 뒤 트래픽 분기와 기본 출구를 설정하세요. 출발지 주소, 도메인, 목적지 IP를 함께 관리한다면 각 규칙의 목적을 기록하세요. 규칙 위치를 이리저리 바꾸며 운에 맡기지 마세요.

증상	우선 확인 항목	다음 조치
명시적 프록시는 되지만 투명 프록시는 실패	트래픽 처리 규칙, 정책 라우팅, 원래 목적지	단일 기기의 규칙 매칭 횟수와 인바운드 로그 확인
웹은 되지만 실시간 앱에 문제가 있음	UDP 처리, 아웃바운드 지원, MTU	UDP를 따로 테스트하고 재전송 및 패킷 분할 문제 확인
일부 도메인에서 계속 대기	DNS 조회 지점, 상위 서버 경로, IPv6	A와 AAAA 레코드를 각각 조회하고 해당 경로 테스트
부하가 늘면 속도가 저하됨	CPU, 메모리, 연결 추적 테이블	같은 시간대에 같은 대상에 직접 연결한 결과와 프록시 결과 비교

라우터에 표시된 무선 속도를 프록시 처리량으로 간주하지 마세요. 암호화, 연결 수, 단일 코어 성능과 발열이 모두 결과에 영향을 줍니다. 테스트할 때는 유선 기기를 사용하고 노드와 테스트 대상을 고정한 다음 CPU 사용률을 기록하세요. 속도 측정의 순간 최고치만으로는 무선 간섭과 게이트웨이 처리 성능을 구분할 수 없습니다.

IPv6: IPv4만 처리한다고 해서 모든 앱의 트래픽이 프록시를 통과하는 것은 아닙니다. 라우터 광고, IPv6 기본 경로, 방화벽, DNS의 AAAA 응답을 확인하고 IPv6도 별도로 처리할지 직접 연결로 유지할지 정하세요.
트래픽 가속: 하드웨어 또는 소프트웨어 오프로딩이 예상한 규칙을 우회할 수 있습니다. 통제된 범위에서 관련 가속을 잠시 끄고 비교한 뒤 호환성을 확인하고 다시 활성화하세요.
역방향 경로 검사: 복잡한 정책 라우팅은 엄격한 검사와 충돌할 수 있습니다. 인터페이스 설정과 패킷 손실 증거를 먼저 확인한 뒤 필요한 부분만 조정하세요. 전역 비활성화 명령을 그대로 복사하지 마세요.
장애 시 정책: 코어가 종료되면 프록시 트래픽을 차단할지 직접 연결로 전환할지 명확히 정해야 합니다. 직접 연결로 전환하면 출구 경로가 바뀌므로 기본 동작처럼 암묵적으로 처리해서는 안 됩니다.

자주 묻는 질문: 바이패스 라우터 적용 후 문제 해결

게이트웨이를 바이패스 라우터로 바꾼 뒤 관리 페이지에도 접속할 수 없는 이유는 무엇인가요?

먼저 테스트 기기의 게이트웨이를 기존 메인 라우터로 되돌려 관리 페이지에 접속할 수 있는지 확인하세요. 그런 다음 바이패스 라우터의 주소 충돌, 서브넷 마스크, 패킷 전달 설정과 LAN 주소 제외 규칙을 살펴보세요. 관리 트래픽을 프록시 아웃바운드로 보내서는 안 됩니다. 문제를 해결하는 동안 로컬 접속 방법을 유지하세요.

v2rayN에서는 노드가 작동하지만 라우터로 복사하면 연결되지 않는 이유는 무엇인가요?

양쪽의 Xray 버전과 아웃바운드 설정 전체를 비교하고 서버 포트, 전송 경로, SNI, REALITY 설정을 특히 확인하세요. 라우터의 시간과 노드 도메인 조회도 점검해야 합니다. 먼저 명시적 인바운드로 아웃바운드를 테스트하고 성공한 뒤 투명 프록시를 구성하세요.

DNS만 바꾸고 기본 게이트웨이는 그대로 두면 모든 트래픽을 프록시할 수 있나요?

아니요. DNS는 도메인 조회 경로를 결정할 뿐 일반 IP 패킷의 다음 홉을 바꾸지 않습니다. 다른 명시적인 트래픽 전달 방식이 없다면 기기는 계속 기본 경로로 데이터를 보냅니다. 먼저 기기의 라우팅 테이블을 확인하고 대상 트래픽을 바이패스 라우터로 전달할 방법을 정하세요.

재시작 후에는 작동하지 않지만 수동으로 시작하면 정상입니다. 무엇을 확인해야 하나요?

네트워크 연결 준비, 시간 동기화, DNS, 코어 서비스의 시작 순서를 확인하세요. 방화벽을 다시 불러올 때 사용자 정의 체인이나 정책 라우팅이 지워지지 않는지도 살펴보세요. 서비스 로그와 규칙 스냅샷을 각각 저장해 두면 반복 재시작으로 의존성 문제를 가리는 일을 방지할 수 있습니다.

배포를 마친 뒤에는 복구에 필요한 설정을 기록해 두세요. 기기의 게이트웨이와 DNS, 바이패스 라우터 주소, 투명 프록시 포트, 규칙 위치, 서비스 이름, 장애 시 정책을 포함하면 됩니다. 이후 코어를 업데이트하거나 구독을 변경할 때도 “아웃바운드 → 트래픽 처리 → DNS → 듀얼 스택 → 재시작” 순서로 다시 테스트하세요. 코어와 DNS 기초는 코어 안내 및 DNS 설정 안내에서 확인할 수 있습니다.