라우터용 Xray 코어 직접 실행 배포 가이드: 집안 모든 기기를 하나의 프록시 경로로 연결

먼저 보조 라우터의 네트워크 역할을 정하세요

보조 라우터에서 코어를 직접 실행하는 것은 데스크톱 클라이언트를 다른 장치에 단순히 복사하는 일이 아닙니다. 프록시 진입점을 한 대의 컴퓨터에서 LAN의 트래픽 전달 경로로 옮기는 방식입니다. 단말은 계속 일반 TCP, UDP, DNS 요청을 보내고, 게이트웨이나 보조 라우터가 트래픽을 식별해 Xray 인바운드로 전달한 뒤 라우팅 규칙을 적용하고 직접 연결 또는 프록시 아웃바운드로 전송합니다. TV, 태블릿, 컴퓨터 등 LAN 장치는 각각 노드 설정을 관리할 필요 없이, 트래픽이 이 보조 라우터를 통과하기만 하면 동일한 연결과 분할 규칙을 함께 사용할 수 있습니다.

일반적인 토폴로지는 두 가지입니다. 첫 번째는 보조 라우터를 특정 장치의 기본 게이트웨이로 사용하는 방식입니다. 주 라우터는 계속 인터넷 연결, 무선 접속, DHCP를 담당하고, 일부 단말은 고정 주소나 DHCP 옵션을 통해 게이트웨이를 보조 라우터로 지정합니다. 두 번째는 주 라우터를 단말의 기본 게이트웨이로 유지하면서 정책 라우팅으로 선택한 트래픽을 보조 라우터에 전달하는 방식입니다. 전자는 경로가 명확해 패킷이 어디를 통과하는지 확인하기 쉽고, 후자는 단말 설정을 거의 바꾸지 않아도 되지만 주 라우터에 충분히 명확한 정책 라우팅 기능이 필요합니다.

배포 전에 먼저 실제 경로를 그려야 합니다. 설정부터 작성해서는 안 됩니다. 최소한 주 라우터 주소, 보조 라우터 주소, LAN 대역, 상위 DNS 주소를 기록하세요. 보조 라우터가 고정된 LAN 주소 하나만 사용하고 재부팅 후 DHCP로 다른 주소를 받지 않는지도 확인해야 합니다. LAN에 여러 대역이나 게스트 네트워크가 있다면 어떤 대역이 보조 라우터에 접근할 수 있고 어떤 대역을 격리해야 하는지도 표시하세요.

코어, 설정 파일, 실행 디렉터리 배치

코어를 직접 실행하는 데 필요한 최소 구성은 Xray 실행 파일, 기본 설정, 지리 데이터, 실행 로그, 시작 관리 기능입니다. 디렉터리 위치에 정답은 없지만 역할은 분리해야 합니다. 실행 파일은 보통 시스템 프로그램 디렉터리에 두고, 설정은 영구 보존되는 설정 디렉터리에, 규칙 데이터는 읽기 전용 데이터 디렉터리에 둡니다. 로그는 순환 기록이 가능한 위치에 저장하세요. 임시 디렉터리에 유일한 설정 파일을 보관하면 펌웨어 업그레이드, 재부팅, 저장 공간 정리로 파일이 삭제될 수 있습니다.

/etc/xray/
├── config.json
├── conf.d/
│   ├── 10-inbounds.json
│   ├── 20-outbounds.json
│   ├── 30-dns.json
│   └── 40-routing.json
/usr/share/xray/
├── geoip.dat
└── geosite.dat
/var/log/xray/
├── access.log
└── error.log

단일 파일 설정은 처음 검증할 때 적합합니다. 로딩 순서가 직관적이고 문법 문제를 찾을 때 진입점 하나만 확인하면 되기 때문입니다. 장기 유지보수에는 설정 분리가 유리하며 인바운드, 아웃바운드, DNS, 라우팅을 각각 관리할 수 있습니다. 다만 현재 시작 방식이 디렉터리 읽기를 지원하는지, 여러 파일을 병합할 때 배열과 객체를 어떻게 처리하는지 확인해야 합니다. 어떤 파일명이든 자동으로 로드된다고 가정하지 마세요. 코어는 시작 매개변수가 가리키는 위치만 읽습니다.

아웃바운드는 최소 두 종류를 유지하세요. 프록시 아웃바운드 하나와 직접 연결 아웃바운드 하나입니다. 프록시 아웃바운드의 프로토콜, 주소, 포트, 사용자 식별자, 전송 방식, 보안 계층, 서버 이름, flow 등의 매개변수는 서버 측과 일치해야 합니다. VMess와 VLESS는 서로 다른 프로토콜이므로 주소만 바꾸고 필드를 섞어 사용할 수 없습니다. 구독에서 가져온 설정이라면 먼저 데스크톱 클라이언트에서 대상 노드에 연결되는지 확인한 다음 해당 매개변수를 코어 설정으로 변환하세요. 구독 링크 자체는 Xray가 바로 실행할 수 있는 완전한 게이트웨이 정책이 아닙니다. 일반적으로 노드 정보만 제공하며 LAN 예외, DNS 경로, 투명 인바운드 규칙까지 보조 라우터 대신 결정하지는 않습니다.

시작 관리는 세 가지 조건을 충족해야 합니다. 시스템 네트워크 초기화 후 시작하고, 프로세스가 종료되면 재시작하며, 설정 오류가 발생했을 때 읽을 수 있는 로그를 남겨야 합니다. 설정을 수정한 뒤에는 먼저 코어가 제공하는 설정 테스트를 실행하고 서비스를 다시 불러오세요. 문법 오류 하나로 가정 내 전체 네트워크 경로가 끊기는 일을 막을 수 있습니다. 배포 단계에서는 로그 수준을 warning 또는 info로 설정할 수 있지만, 안정화된 뒤에는 플래시 메모리에 계속 기록되지 않도록 지나치게 상세한 접속 로그를 장기간 남기지 않는 편이 좋습니다.

투명 프록시 방식: REDIRECT, TPROXY, TUN

투명 프록시의 목적은 단말에 HTTP 또는 SOCKS 프록시 주소를 직접 입력하지 않아도 되게 하는 것입니다. 게이트웨이는 방화벽과 정책 라우팅으로 연결을 가로채 Xray의 투명 인바운드로 전달합니다. 방식마다 지원 프로토콜, 커널 기능, 관리 복잡도가 다르므로 실제 트래픽에 맞춰 선택해야 하며, 모든 방식을 동시에 적용할 필요는 없습니다.

REDIRECT: TCP 중심의 간단한 경로

REDIRECT는 게이트웨이 방화벽에서 TCP 연결의 목적지를 변경해 로컬 리스닝 포트로 진입시킵니다. 설정이 비교적 직관적이어서 TCP 게이트웨이 경로를 먼저 검증하기 좋습니다. 다만 TCP 전달에 주로 초점이 맞춰져 있어 UDP, 실시간 통신, 원래 목적지 정보에 의존하는 일부 환경에서는 한계가 있습니다. 가정 내 네트워크에서 소수의 지정 장치만 웹 서비스에 접근하면 된다면 이 방식부터 시작할 수 있습니다. TCP와 UDP를 더 폭넓게 처리해야 한다면 TPROXY 또는 TUN을 검토하세요.

TPROXY: 원래 목적지를 보존하는 정책 전달

TPROXY는 TCP와 UDP를 가로챌 때 원래 목적지 주소를 보존할 수 있으며, 보통 패킷 마크, 별도 라우팅 테이블, 로컬 라우팅과 함께 사용합니다. 방화벽이 조건에 맞는 패킷에 표시를 추가하면 정책 라우팅이 해당 표시를 기준으로 패킷을 로컬 투명 인바운드로 돌려보내고, Xray가 원래 목적지를 읽어 아웃바운드를 결정합니다. 관련 커널 모듈을 사용할 수 있고 출발 장치와 대상 대역을 세밀하게 제어해야 하는 게이트웨이 환경에 적합합니다.

TPROXY의 어려운 부분은 노드 필드가 아니라 전달 루프를 완성하는 데 있습니다. Xray가 프록시 서버에 연결하기 위해 생성한 트래픽이 다시 Xray 투명 인바운드로 들어가면 안 됩니다. 일반적인 처리 방법은 프로세스 사용자 기준 우회, 패킷 마크 기준 우회, 또는 프록시 서버 주소를 직접 연결 목록에 추가하는 것입니다. 어떤 방법을 쓸지는 시스템 방화벽 기능에 따라 다르지만 결과는 반드시 검증할 수 있어야 합니다. 로그에서 같은 대상 연결이 반복해서 생성되지 않아야 하며 연결 추적 테이블도 빠르게 증가해서는 안 됩니다.

TUN: 가상 네트워크 인터페이스에서 통합 가로채기

TUN 방식은 가상 네트워크 인터페이스로 3계층 트래픽을 받아 Xray가 해당 연결을 적절한 아웃바운드로 전달합니다. 일부 방화벽 리디렉션 규칙의 복잡도를 줄일 수 있고 TCP와 UDP도 더 일관되게 처리할 수 있습니다. 하지만 TUN이 게이트웨이 배포를 자동으로 끝내주는 것은 아닙니다. 시스템은 여전히 대상 트래픽을 가상 인터페이스로 라우팅해야 하며 DNS, MTU, LAN 우회, 커널 자체 트래픽도 처리해야 합니다. 장치 성능이 제한적이면 TUN 프로토콜 스택 처리와 동시 연결 증가로 CPU와 메모리 부담이 커질 수 있습니다.

세 방식은 다음 순서로 판단하면 됩니다. 소량의 TCP 트래픽만 검증할 때는 REDIRECT, 원래 목적지를 보존하면서 TCP와 UDP를 정밀하게 처리해야 할 때는 TPROXY, 가상 인터페이스 지원이 안정적이고 통합 가로채기를 원할 때는 TUN을 고려하세요. 주 경로를 하나 선택한 뒤 규칙을 단일하게 유지해야 합니다. 같은 패킷이 먼저 TUN 라우팅에 잡힌 다음 방화벽을 통해 TPROXY로 다시 들어가는 상황은 피하세요.

DNS는 보조 라우터 배포의 핵심 경로입니다

‘노드는 연결되지만 웹페이지가 열리지 않는’ 문제의 상당수는 아웃바운드 연결 실패가 아니라 DNS 경로와 라우팅 정책이 맞지 않아서 발생합니다. 단말은 먼저 도메인을 특정 리졸버에 전달해 주소를 받은 뒤 연결을 수립합니다. DNS 조회가 보조 라우터를 우회하면 Xray는 대상 IP만 보게 되어 도메인 규칙을 활용하기 어렵습니다. 반대로 모든 조회를 잘못된 한 경로로 보내면 조회 시간 초과, 현재 출구에 맞지 않는 결과, 조회 루프가 발생할 수 있습니다.

먼저 LAN 단말에 DNS를 제공할 주체를 정하세요. 주 라우터가 계속 응답하되 상위 조회를 보조 라우터로 전달할 수도 있고, 지정한 단말이 보조 라우터 주소를 직접 사용하게 할 수도 있습니다. 어느 방식을 선택하든 LAN에는 명확한 기본 경로 하나만 두는 것이 좋습니다. 단말이 주 라우터와 보조 라우터의 DNS 주소를 동시에 받는다고 해서 입력 순서대로 고정 사용되는 것은 아닙니다. 실제 조회가 두 리졸버 사이에서 전환되면서 같은 도메인에 서로 다른 결과가 나올 수 있습니다.

다음으로 로컬 도메인과 공용 도메인을 구분하세요. 라우터 관리 이름, 홈 네트워크 장치 이름, LAN 전용 영역은 로컬 레코드를 인식하는 리졸버로 보내야 하며 공용 DNS로 전송해서는 안 됩니다. 공용 도메인은 규칙에 따라 직접 연결용 조회 또는 프록시용 조회를 선택할 수 있습니다. Xray 라우팅에 도메인 정보가 필요하다면 투명 인바운드가 도메인을 얻을 수 있게 하거나, DNS 응답과 코어 캐시가 확실히 연결되도록 해야 합니다.

domainStrategy는 라우팅에서 도메인과 IP를 매칭하는 방식을 결정합니다. 도메인 규칙만 사용할 때는 연결마다 다시 조회할 필요가 없습니다. 도메인 연결 판단에 geoip 규칙을 적용해야 할 때만 필요에 따라 조회하는 방식을 고려하세요. 불필요하게 조회를 활성화하면 DNS 왕복이 늘어나고, 도메인 기준으로 처리해야 할 트래픽이 일찍 IP 기준 판단으로 바뀔 수 있습니다. 규칙을 설계할 때 먼저 ‘도메인 우선인지 IP 우선인지’를 정한 다음 전략을 선택하세요. 여러 전략 이름을 성능 스위치처럼 반복해서 바꾸면 안 됩니다.

FakeDNS는 일부 TUN 가로채기 환경에 적합합니다. 단말에 예약 주소를 반환하고 내부에 도메인과 가상 주소의 매핑을 저장해 후속 연결에서 원래 도메인을 복원할 수 있게 합니다. 하지만 DNS 조회와 연결이 동일한 매핑 상태를 거쳐야 합니다. LAN에 보조 라우터를 우회하는 장치가 있거나, 실제 IP에 직접 접근해야 하는 앱을 사용하거나, 보조 라우터가 자주 재부팅된다면 신중하게 활성화하세요. 일반적인 게이트웨이 배포에서는 먼저 실제 DNS 조회를 사용해 기본 경로를 안정화한 뒤 가상 매핑을 검토하는 편이 좋습니다.

라우팅 분할은 LAN 예외부터 시작하세요

보조 라우터의 첫 번째 원칙은 LAN 접근성을 보호하는 것입니다. 사설 주소, 루프백 주소, 링크 로컬 주소, 멀티캐스트, 브로드캐스트는 원격 프록시로 보내면 안 됩니다. 프린터, 저장 장치, TV 캐스팅, 라우터 관리 페이지는 모두 로컬 직접 연결에 의존합니다. 이런 예외를 누락하면 인터넷은 정상적으로 접속되지만 홈 네트워크 장치 검색, 파일 공유, 관리 페이지가 작동하지 않는 현상이 나타납니다.

두 번째 계층은 대상에 따라 직접 연결과 프록시를 결정하는 것입니다. 규칙 순서가 매우 중요합니다. Xray 라우팅은 일반적으로 위에서 아래로 검사해 처음 일치한 결과를 실행합니다. 더 구체적인 규칙은 앞에, 포괄적인 규칙은 뒤에 두고 마지막에는 명확한 기본 규칙을 설정하세요. 이해하기 쉬운 세 단계 구조는 다음과 같습니다. LAN과 예약 주소는 직접 연결, 직접 연결할 도메인과 주소는 직접 연결, 나머지 트래픽은 프록시 아웃바운드로 전달합니다. geosite와 geoip 데이터를 사용한다면 규칙 데이터 파일이 코어에서 읽을 수 있는 위치에 있는지 확인하고 업데이트 후 핵심 규칙을 다시 검증해야 합니다.

세 번째 계층은 출발 장치에 따른 분할입니다. 보조 라우터는 출발지 주소를 기준으로 가로챌 대상을 결정할 수 있습니다. 예를 들어 테스트 컴퓨터와 TV만 투명 프록시를 통과시키고 나머지 장치는 기존 게이트웨이 경로를 유지하게 할 수 있습니다. 출발지 주소 정책은 안정적인 주소에 의존하므로 단말이 우연히 받은 주소가 아니라 DHCP에서 임대 주소를 고정하는 것이 좋습니다. 한 번에 전체 네트워크를 가로채기보다 그룹별로 적용하세요. 먼저 테스트 장치 한 대를 추가해 TCP, UDP, DNS, LAN 접근을 확인한 뒤 범위를 단계적으로 넓히는 방식이 안전합니다.

포트 규칙은 보조 수단으로만 사용하세요. 일반적인 웹 포트만으로는 모든 앱을 다룰 수 없고, 최신 앱은 TCP와 UDP 사이를 전환하기도 합니다. ‘몇 개 포트만 프록시하면 된다’고 생각하면 페이지는 열리지만 미디어나 통화가 실패할 수 있습니다. 더 안정적인 조합은 출발 장치, 대상 도메인, 대상 주소, 프로토콜을 함께 판단하고 식별할 수 없는 트래픽에는 명확한 기본 경로를 지정하는 것입니다.

루프, 연결 끊김, 성능 병목을 피하세요

투명 프록시에서 가장 주의해야 할 것은 트래픽 루프입니다. Xray가 프록시 서버에 연결하기 위해 생성한 트래픽이 다시 Xray 투명 인바운드로 들어가서는 안 됩니다. 일반적인 처리 방법으로는 프로세스 사용자 기준 우회, 패킷 마크 기준 우회, 프록시 서버 주소를 직접 연결 목록에 추가하는 방법이 있습니다. 선택은 시스템 방화벽 기능에 따라 달라지지만 결과는 반드시 검증해야 합니다. 로그에서 동일한 대상 연결이 계속 반복 생성되지 않아야 하며 연결 추적 테이블도 빠르게 증가해서는 안 됩니다.

보조 라우터 자체의 시스템 서비스에도 명확한 정책이 필요합니다. 시간 동기화, 소프트웨어 업데이트, 상위 DNS 조회는 모두 로컬에서 시작하므로 각각 프록시를 통과시킬지 결정해야 합니다. 가장 안전한 출발점은 보조 라우터 자체의 트래픽은 직접 연결로 유지하고 전달 트래픽만 가로채는 것입니다. 규칙이 안정된 뒤 특정 로컬 서비스에 프록시 경로를 추가하세요. 모든 로컬 출력을 곧바로 투명 가로채기하면 시작 의존성이 늘어납니다. 시간이 동기화되지 않았거나 DNS가 작동하지 않거나 Xray가 시작되지 않은 상태에서 시스템 서비스가 서로를 기다릴 수 있습니다.

MTU 문제는 작은 페이지는 열리지만 대용량 파일이나 특정 사이트에서 멈추는 형태로 나타나는 경우가 많습니다. 투명 경로, 터널, 상위 네트워크는 모두 캡슐화 오버헤드를 추가합니다. 연결 핸드셰이크는 정상인데 큰 패킷을 전송할 때 멈춘다면 노드 프로토콜을 바로 바꾸기보다 경로 MTU와 TCP MSS를 확인하세요. 조정할 때는 네트워크 인터페이스와 실제 경로부터 살펴보고 여러 위치에서 값을 중복으로 줄이지 않도록 하세요.

성능 면에서 장치에 표시된 포트 속도가 투명 프록시 처리량을 의미하지는 않습니다. 암호화 연산, 규칙 매칭, 연결 추적, TUN 프로토콜 스택, 로그 기록이 모두 리소스를 사용합니다. 테스트할 때는 CPU 단일 코어 사용률, 가용 메모리, 연결 수, 온도를 함께 확인하세요. 단일 코어가 장시간 100%에 가깝다면 규칙이나 동시 연결을 늘려도 속도는 올라가지 않습니다. 저전력 장치는 간결한 규칙, 제한적인 로그, 안정적인 프로토콜 매개변수를 사용하는 편이 적합합니다.

정해진 순서로 온라인 검증을 완료하세요

보조 라우터 배포는 계층별로 검증하는 것이 좋습니다. 각 단계에서는 하나의 질문만 확인하세요. 중간 단계를 건너뛰면 모든 ‘접속 불가’ 문제가 게이트웨이, DNS, 방화벽, Xray, 원격 노드 중 어디에서 발생했는지 동시에 살펴봐야 하므로 문제 해결 비용이 급격히 커집니다.

1. 기본 라우팅을 검증합니다. 투명 규칙을 끄고 테스트 단말의 게이트웨이를 보조 라우터로 지정한 뒤 주 라우터, LAN 장치, 인터넷에 접근할 수 있는지 확인하세요.
2. 코어 아웃바운드를 검증합니다. Xray의 명시적 SOCKS 또는 HTTP 인바운드를 사용해 단일 장치에서 테스트하고 프록시 노드 매개변수가 서버 측과 일치하는지 확인하세요.
3. 투명 진입점 하나를 활성화합니다. 먼저 테스트 단말만 가로채고 패킷 카운터와 Xray 접속 로그가 서로 대응하는지 확인하세요.
4. LAN 예외를 추가합니다. 라우터 관리 페이지, 파일 공유, 장치 검색, 기타 로컬 서비스가 계속 작동하는지 확인하세요.
5. DNS를 연결합니다. 단말의 실제 조회 주소, 보조 라우터의 상위 조회, 연결 아웃바운드가 서로 일치하는지 확인하세요.
6. TCP와 UDP를 테스트합니다. 웹페이지, 다운로드, 미디어, 실시간 연결을 각각 검증하고 웹페이지 하나만으로 성공 여부를 판단하지 마세요.
7. 재부팅을 시뮬레이션합니다. 보조 라우터를 재부팅한 뒤 주소, 정책 라우팅, 방화벽 규칙, Xray 서비스가 올바른 순서로 복구되는지 확인하세요.
8. 장치 범위를 단계적으로 넓힙니다. 매번 고정 주소 그룹 하나씩 추가하고, 장애 발생 시 접근할 수 있도록 보조 라우터를 거치지 않는 관리 장치 한 대를 남겨 두세요.

로그도 계층별로 판단해야 합니다. Xray가 연결을 받지 못했다면 먼저 단말 게이트웨이, 방화벽 적중 여부, 정책 라우팅을 확인하세요. 연결은 받았지만 아웃바운드가 없다면 라우팅 태그와 규칙 순서를 점검합니다. 아웃바운드 연결 후 시간 초과가 발생하면 노드 매개변수, 원격 접근 가능 여부, 시스템 시간을 확인하세요. 도메인만 실패하고 주소 직접 접속은 정상이라면 DNS 경로로 돌아가야 합니다. 프로토콜, 보안 계층, 라우팅 필드를 무작정 바꾸는 것보다 정해진 순서로 확인하는 편이 효과적입니다.

데스크톱 클라이언트와 어떻게 선택할까요

보조 라우터에서 직접 실행하는 가장 큰 장점은 중앙 관리입니다. 여러 장치가 노드, DNS, 라우팅 규칙을 공유한다면 게이트웨이 설정 하나만 관리하면 됩니다. 명시적 프록시를 설정하기 어려운 LAN 장치도 기본 게이트웨이를 통해 동일한 경로를 사용할 수 있습니다. 대신 장애의 영향 범위가 커집니다. 보조 라우터 서비스, DNS, 전달 규칙에 문제가 생기면 여러 장치가 동시에 영향을 받을 수 있습니다. 따라서 이는 일반적인 클라이언트 설치라기보다 네트워크 인프라에 가깝습니다.

v2rayN은 한 대의 Windows, macOS 또는 Linux 데스크톱에서 일상적으로 사용하고 노드를 검증하는 데 더 적합합니다. 그래픽 인터페이스를 이용하면 구독 가져오기, 서버 전환, 로그 확인, 시스템 프록시 조정이 편리합니다. 컴퓨터마다 노드를 따로 선택해야 하거나 여러 네트워크 사이를 자주 이동한다면 데스크톱 클라이언트의 경계가 더 명확합니다. Android 장치는 코어 요구 사항에 따라 v2rayNG 또는 v2flyNG를 선택하고 장치에서 직접 연결을 관리할 수 있습니다.

두 방식은 함께 사용할 수도 있습니다. 보조 라우터는 고정 장치와 기본 분할을 담당하고, 데스크톱에서는 노드 테스트나 임시 정책을 위해 v2rayN을 유지하는 방식입니다. 함께 사용할 때는 이중 가로채기를 피해야 합니다. 컴퓨터에서 v2rayN의 시스템 프록시나 TUN을 활성화한 상태에서 기본 게이트웨이도 투명 프록시를 통과하면 하나의 연결이 두 겹의 전달을 거칠 수 있습니다. 노드를 테스트할 때는 해당 컴퓨터가 보조 라우터의 투명 규칙을 일시적으로 우회하게 하거나 로컬 가로채기를 끄고 유효한 경로 하나만 남기세요.

프록시가 필요한 컴퓨터가 한두 대뿐이라면 먼저 데스크톱 클라이언트를 사용하는 편이 관리하기 쉽습니다. 가정 내 네트워크에 고정 장치가 여러 대 있고 DHCP, 고정 라우팅, 방화벽, DNS를 관리할 수 있다면 안정적인 노드를 보조 라우터로 옮기는 방식을 고려하세요. 배포의 기준은 ‘모든 트래픽이 프록시로 들어가는가’가 아닙니다. 경로를 설명할 수 있고, LAN 접근성이 유지되며, DNS와 트래픽 분할이 일치하고, 재부팅 후 자동으로 복구되는지가 기준입니다.