라우터·보조 라우터 Xray/V2Ray 설치 가이드: 구성 방식과 설정

1. 구성 방식 선택: 메인 라우터에 설치할까, 보조 라우터에 설치할까

Xray와 V2Ray는 프록시 코어이지 라우터 운영체제 전체가 아닙니다. 코어를 실행한 뒤에도 운영체제에서 패킷 전달, 방화벽 규칙 적용, 서비스 관리를 처리해야 합니다. 펌웨어 관리 화면에서 설정을 생성할 수 있지만, 화면의 옵션과 규칙 파일, 실제 실행 중인 코어 버전이 서로 호환되어야 합니다. 화면에 '실행 중'이라고 표시되는지만 확인해서는 안 됩니다.

노드 요구사항에 맞는 코어를 선택하세요. Xray와 V2Fly에서 관리하는 V2Ray는 프로토콜, 전송 방식, 설정 필드에 차이가 있습니다. 특히 REALITY 같은 특정 기능을 포함한 설정을 해당 기능을 지원하지 않는 코어에서 사용하면 안 됩니다. v2rayN은 데스크톱 클라이언트이고 v2rayNG와 v2flyNG는 Android 클라이언트입니다. 노드 확인에는 사용할 수 있지만 라우터에서 트래픽을 전달하는 서비스는 아닙니다.

2. 주소 계획: 게이트웨이, DNS, 응답 경로를 각각 확인

아래 주소는 설명을 위한 예시이며 모든 네트워크에 통용되는 기본값은 아닙니다. 배포 전에 실제 서브넷과 DHCP 주소 풀, 기존 기기를 확인해 주소 충돌을 방지하세요. 보조 라우터에는 고정 주소를 할당하고 동적 할당 범위에서 제외하거나 메인 라우터에서 고정 임대를 설정합니다.

단일 NIC를 사용하는 동일 서브넷의 보조 라우터에서는 직접 연결 트래픽이 보조 라우터를 거쳐 메인 라우터로 전달된 뒤, 메인 라우터에서 단말로 바로 돌아가 비대칭 경로가 생길 수 있습니다. 방화벽 상태 추적을 고려해 제한적인 SNAT를 적용할지, 대칭 경로가 유지되도록 네트워크 구성을 조정할지 결정하세요. ICMP 리디렉션 때문에 단말이 보조 라우터를 우회하는지도 확인해야 합니다. 모든 문제에 'NAT 활성화'를 일괄 적용해서는 안 됩니다.

3. 투명 프록시: 코어가 수신 대기한다고 트래픽이 연결된 것은 아닙니다

명시적 프록시는 애플리케이션이 HTTP 또는 SOCKS 프록시 포트에 직접 연결해야 합니다. 투명 프록시는 게이트웨이가 조건에 맞는 트래픽을 가로채 코어로 전달하고, 라우팅 판단에 필요한 목적지 주소를 유지합니다. SOCKS 인바운드만 설정한 경우에는 기기의 게이트웨이를 보조 라우터로 지정하더라도 일반 애플리케이션 트래픽이 해당 인바운드로 자동 전달되지 않습니다.

1. 먼저 아웃바운드 확인: 같은 노드를 클라이언트에서 테스트해 기본 연결 상태를 확인한 다음, 라우터의 시간 설정, 인증서 검증, 서버 도메인 조회, 연결 로그를 점검합니다. 데스크톱에서 작동한다고 라우터의 네트워크 조건까지 같은 것은 아닙니다.
2. 다음으로 인바운드 확인: 리스너 주소와 프로토콜, 포트를 확인하고 방화벽 트래픽이 명시적 프록시 포트가 아닌 올바른 투명 프록시 인바운드로 전달되는지 점검합니다.
3. 마지막으로 트래픽 가로채기 설정: 먼저 테스트 기기의 소스 주소로 범위를 제한한 뒤 대상 범위를 단계적으로 넓힙니다. TPROXY에는 해당 정책 라우팅이 필요합니다. 방화벽 규칙만 있고 라우팅 설정이 없으면 트래픽이 끊길 수 있습니다.
4. 프록시 루프 방지: 코어가 직접 생성하는 아웃바운드 연결이 다시 가로채지지 않도록 해야 합니다. 일반적으로 전용 마크, 프로세스 정보 또는 목적지 주소를 기준으로 제외하며, 구체적인 방법은 배포 방식에 맞춰야 합니다.

LAN 관리 주소, 브로드캐스트, 멀티캐스트 및 직접 연결해야 하는 다른 서브넷은 방화벽 트래픽 가로채기 단계와 코어 라우팅 단계에서 각각 고려해야 합니다. 노드 서버 IP 제외 규칙은 도메인 조회 결과가 바뀔 가능성도 반영해야 합니다. nftables 기반 방화벽 환경에서는 기존 iptables 스크립트를 그대로 추가 실행하지 마세요. 중복 적용과 잘못된 규칙 순서로 인해 문제를 재현하기 어려워질 수 있습니다.

4. DNS 설정: 포트, 도메인 분기, 시작 시 조회까지 연결

DNS 설정은 단말의 질의, 라우터의 로컬 전달, 상위 DNS 서버 조회의 세 단계로 이루어집니다. 단말의 DNS를 보조 라우터로 지정해도 해당 설정을 따르는 요청만 제한할 수 있습니다. 애플리케이션에 내장된 암호화 DNS는 일반 53번 포트를 가로채도 자동으로 지정한 DNS 리졸버를 사용하지 않으므로 브라우저와 앱의 설정을 따로 확인해야 합니다.

• 수신 포트: 일반 DNS 서비스는 UDP/TCP 53번 포트를 사용합니다. 시스템 DNS 서비스가 이미 53번 포트를 사용 중이면 다른 DNS 구성 요소를 로컬 5353번 포트에서 실행하고 기존 서비스가 요청을 전달하도록 설정할 수 있습니다. 이 포트 번호는 구성 예시이므로 실제 리스너 설정을 확인하세요.
• 도메인별 분기: 직접 연결할 도메인과 프록시를 사용할 도메인에 알맞은 상위 DNS 서버를 지정하고, 상위 서버로 향하는 트래픽이 의도한 아웃바운드 경로를 사용하는지 확인합니다. 상위 DNS 서버를 공용 리졸버로 바꾸는 것만으로 요청이 프록시를 거친다고 판단할 수는 없습니다.
• 시작 시 도메인 조회: 노드 서버 주소가 도메인이라면 먼저 사용할 수 있는 DNS 조회 경로가 있어야 합니다. 아직 연결되지 않은 프록시 연결에만 의존해 노드 도메인을 조회하도록 설정하지 마세요.
• 순환 조회 방지: 로컬 DNS가 요청을 코어에 전달한 뒤 코어가 같은 요청을 다시 로컬의 원래 진입점으로 보내지 않도록 해야 합니다. 각 단계의 주소와 포트, 아웃바운드 태그를 확인하세요.
• 도메인과 IP 매칭: domainStrategy는 라우팅 판단 시 도메인을 조회할지, 조회한다면 언제 할지를 결정합니다. 시스템의 모든 DNS 요청이 가로채진다는 뜻은 아닙니다. 지원 값과 동작 방식은 사용하는 코어 버전에 맞춰 확인하세요.

geosite, geoip 등의 규칙 리소스를 사용하는 경우 리소스 파일과 설정의 참조 경로가 일치하는지, 업데이트가 정상적으로 완료되는지도 확인해야 합니다. 스니핑은 일부 연결에서 도메인 정보를 복구하는 데 도움이 될 수 있지만 모든 트래픽을 인식하지는 못하며 DNS 경로 설계를 대신할 수 없습니다. 도메인 분기를 테스트할 때는 도메인 규칙의 일치 기록과 실제 아웃바운드 태그를 함께 확인하세요.

# dig가 설치된 테스트 기기에서 실행합니다. 도메인은 연결 테스트용입니다
dig @192.168.10.2 example.com A
dig @192.168.10.2 example.com AAAA
dig @192.168.10.2 example.com A +tcp

세 가지 조회는 각각 IPv4 레코드, IPv6 레코드, TCP DNS를 확인합니다. 응답이 오면 DNS 서비스가 응답한다는 사실만 확인할 수 있습니다. 요청이 어느 상위 DNS 서버로 전달되고 어떤 경로를 거치는지는 라우터 로그나 제한된 패킷 캡처로 추가 확인해야 합니다. DNS 설정을 변경한 뒤에는 이전 응답이 변경 사항을 가리지 않도록 단말과 라우터의 캐시를 비우세요.

5. 배포 순서: 기기 한 대로 검증한 뒤 DHCP 설정 변경

라우터 설정은 데스크톱에서 내보낸 파일을 그대로 복사하는 작업이 아닙니다. 리스너 주소, 파일 경로, 사용자 권한, 리소스 파일 위치, 투명 프록시 인바운드 설정이 달라집니다. 구독 URL이 곧바로 실행 가능한 코어 설정을 의미하지는 않습니다. 가져오기 지원 여부와 아웃바운드 생성 방식은 관리 도구 구현에 따라 달라집니다.

1. 기준 상태 기록: 네트워크, DHCP, 방화벽 설정을 백업하고 메인 라우터의 관리 주소를 기록합니다. 테스트 기기가 기존 게이트웨이를 사용할 때 도메인을 정상적으로 조회하고 웹사이트와 LAN 기기에 접속할 수 있는지 확인합니다.
2. 실행 환경 확인: 프로세서 아키텍처에 맞는 코어 바이너리를 선택하고 시스템 시간, 쓰기 가능한 저장 공간, 서비스 권한을 확인합니다. 규칙 리소스와 연결 수에 따라 메모리 사용량이 달라지므로 설치 파일 크기로 실행 요구사항을 추정하지 마세요.
3. 코어 단독 실행: 설정 문법과 시작 로그를 확인한 다음 노드 연결을 테스트합니다. 코어 설정 검증 명령은 배포 버전에 따라 다를 수 있으므로 프로그램에 포함된 도움말을 먼저 확인하세요.
4. 테스트 범위 제한: 192.168.10.100 기기 한 대의 게이트웨이와 DNS만 변경하고 해당 소스 주소의 트래픽만 가로챕니다. 직접 연결 사이트, 프록시 사이트, LAN 서비스를 각각 테스트합니다.
5. 예외 상황 정책 설정: 노드를 사용할 수 없을 때 연결을 차단할지, 특정 트래픽은 직접 연결을 허용할지 결정합니다. DNS 오류, 코어 중단, 기기 재부팅 상황도 테스트해야 합니다. 정상 작동만 확인해서는 안 됩니다.
6. 마지막으로 적용 기기 확대: 안정성을 확인한 뒤 DHCP 설정을 변경합니다. OpenWrt의 LuCI 화면에서는 일반적으로 '네트워크' → '인터페이스' → 'LAN' → 'DHCP 서버'에서 주소 할당 설정을 확인할 수 있습니다. 메뉴와 항목은 버전에 따라 다를 수 있으며, 기존 단말은 새 설정을 적용하려면 DHCP 임대를 다시 받아야 합니다.

6. 검증과 문제 해결: 외부 IP만 보지 말고 트래픽 경로를 확인

외부 IP가 바뀌었다는 사실은 특정 요청 하나가 특정 경로를 거쳤다는 것만 보여 줍니다. DNS, UDP, IPv6, 모든 애플리케이션이 올바르게 연결되었다는 뜻은 아닙니다. 정상 상태와 오류 상태의 결과를 모두 기록하고 단말, 게이트웨이, DNS, 코어 아웃바운드를 나눠 확인하세요.

# Linux 라우터 기기에서 실행합니다. 해당 정보를 조회할 권한이 필요합니다
ip -4 route
ip -6 route
ip rule show
ss -lntup

위 명령으로 IPv4 경로, IPv6 경로, 정책 라우팅 규칙, 수신 대기 포트를 확인할 수 있습니다. 경량 시스템에서는 해당 도구를 별도로 설치해야 할 수 있습니다. 출력 결과를 자신의 주소 계획과 비교하세요. 포트 번호가 하나 표시된다는 이유만으로 배포가 완료되었다고 판단하면 안 됩니다. 로그에 구독 URL, 접속 자격 증명, 기기 식별 정보가 포함되어 있다면 공유하기 전에 민감한 내용을 삭제하세요.