라우터에서 V2Ray 코어를 직접 실행할 수 있을까: 보조 라우터 배포 방식과 절차 개요

먼저 토폴로지 선택: 메인 라우터에서 직접 실행할까, 별도 보조 라우터를 둘까

‘라우터에서 코어를 직접 실행한다’는 것은 V2Ray 또는 Xray 프로세스를 게이트웨이 장비에서 실행한 뒤 방화벽으로 LAN 트래픽을 코어에 전달하는 방식입니다. PC와 Android 기기에서 각각 v2rayN이나 v2rayNG를 켜지 않아도 게이트웨이 규칙에 따라 트래픽을 분기할 수 있습니다. 이는 여러 기기를 통합 관리하기 위한 방법이며, 노드 회선이나 대역폭, 지연 시간을 자동으로 개선해 주지는 않습니다.

메인 라우터 방식은 경로가 가장 짧습니다. 전화 접속, DHCP, DNS, NAT, 투명 프록시를 한 장비에서 처리하므로 전달 단계가 줄고 네트워크 구조도 이해하기 쉽습니다. 다만 설정 오류가 집 전체의 인터넷 연결에 바로 영향을 줍니다. 코어 오류, DNS 루프, 잘못된 방화벽 규칙은 일반 직결 트래픽까지 끊어 놓을 수 있습니다.

보조 라우터 방식은 프록시 역할을 두 번째 장비로 분리합니다. 메인 라우터는 전화 접속과 기본 네트워크를 계속 담당하고, 보조 라우터는 지정된 단말만 처리합니다. 테스트 중에는 PC 한 대의 게이트웨이를 보조 라우터 주소로 바꿔 안정성을 확인한 뒤 DHCP로 더 많은 기기에 배포할 수 있습니다. 보조 라우터가 중단되어도 메인 라우터에서 일반 네트워크를 복구할 수 있습니다.

하드웨어 기준: 메모리가 충분해도 전달 속도가 빠른 것은 아니다

코어 실행에 필요한 디스크와 메모리는 많지 않지만, 실제 체감 성능은 싱글 코어 성능, 암호화 처리, 연결 수와 발열에 좌우됩니다. 라우터에 기가비트 포트가 있어도 물리 인터페이스의 성능을 뜻할 뿐, 투명 프록시를 거친 뒤에도 기가비트 속도가 나온다는 의미는 아닙니다. VMess, VLESS와 다양한 전송 계층 조합은 CPU를 사용하며, 상세 로그와 복잡한 규칙을 활성화하면 추가 부하도 발생합니다.

OpenWrt 24.10.2와 Xray 25.6.8을 배포 기록 예시로 삼아 쿼드코어 ARM 장비에서 단일 연결 다운로드를 테스트했습니다. 직결은 약 936 Mbps, VLESS over TCP는 약 612 Mbps, VMess over WebSocket은 약 438 Mbps였습니다. 듀얼코어 저클럭 장비에서는 같은 회선이 각각 약 917 Mbps, 214 Mbps, 156 Mbps로 떨어졌습니다. 이 수치는 모든 하드웨어에 적용되는 벤치마크는 아니지만, 포트 규격과 프록시 처리량이 직접 연결되지 않는다는 점을 보여 줍니다.

• 아키텍처가 코어 파일과 일치하는지 확인하세요. 일반적인 유형은 aarch64, armv7, x86_64이며 파일을 서로 바꿔 사용할 수 없습니다.
• 플래시에 충분한 여유 공간이 남아 있는지 확인하세요. 코어 본체뿐 아니라 Geo 데이터, 설정 백업과 로그 순환을 위한 공간도 남겨야 합니다.
• 부하 테스트는 최소 15분 이상 진행하고, 속도 측정 페이지의 순간 최고값만 보지 마세요. 온도가 오른 뒤 발생하는 클럭 저하는 실제 가정용 부하에 더 가깝습니다.
• TCP와 UDP를 모두 테스트하세요. 웹페이지가 열린다고 해서 영상 통화, 게임 또는 UDP 기반 도메인 조회가 정상이라는 뜻은 아닙니다.

설정 적용: 구독 링크를 코어에 바로 넘길 수는 없다

v2rayN, v2rayNG와 v2flyNG는 인터페이스를 갖춘 클라이언트로, 구독과 노드, 실행 매개변수를 관리할 수 있습니다. V2Ray 또는 Xray 코어가 읽는 것은 구조화된 설정 파일이며, 일반적인 구독 링크를 완전한 투명 프록시 구성으로 자동 변환하지는 않습니다. 구독에 노드 정보만 들어 있다면 인바운드 포트, DNS, 라우팅 규칙, 로그 수준과 방화벽 연동이 여전히 필요합니다.

안전한 절차는 먼저 클라이언트에서 노드 매개변수를 확인한 다음 서버 주소, 포트, 사용자 식별자, 전송 방식과 TLS 관련 필드를 라우터 설정에 옮기는 것입니다. 데스크톱에서는 v2rayN의 「설정」→「매개변수 설정」→「Core 유형」에서 현재 사용하는 코어 계열을 확인한 뒤 같은 노드로 연결을 테스트할 수 있습니다. Android에서는 v2rayNG로 Xray 노드를, v2flyNG로 V2Fly 설정을 확인할 수 있지만 클라이언트에서 내보낸 일부 정보만으로 라우터의 투명 프록시 설정을 대신해서는 안 됩니다.

1. 아키텍처 확인

   라우터 시스템 정보에서 aarch64, armv7 또는 x86_64를 확인하고 사용 가능한 플래시와 메모리도 점검하세요. 디스크는 최소 80 MB, 여유 메모리는 256 MB 이상 남겨 두는 것이 좋습니다.

2. 노드 확인

   먼저 v2rayN, v2rayNG 또는 v2flyNG에서 같은 노드에 연결하고 주소, 포트, 사용자 식별자, 전송 계층, TLS와 서버 이름을 기록해 노드 자체의 문제를 배제하세요.

3. 코어 결정

   데스크톱에서 테스트할 때 v2rayN의 「설정」→「매개변수 설정」→「Core 유형」으로 이동해 Xray와 V2Fly 중 무엇을 사용하는지 확인하세요. 라우터에서는 해당 코어에 맞는 필드를 사용하고 전용 기능을 섞지 마세요.

4. 설정 생성

   인바운드 리스너를 로컬 주소와 고정 포트로 설정하세요. 예를 들어 투명 인바운드는 12345, 관리용 SOCKS 인바운드는 10808을 사용하고, 직결·프록시·차단 아웃바운드도 구성합니다.

5. 소규모로 적용

   먼저 테스트 기기 한 대의 게이트웨이를 보조 라우터로 설정하고 웹, DNS, 영상과 UDP 앱을 차례로 확인하세요. 로그에 연결 루프가 없는 것을 확인한 뒤 DHCP 게이트웨이 배포 범위를 변경합니다.

투명 프록시의 핵심: 인바운드 포트, 정책 라우팅과 DNS

투명 프록시는 SOCKS 포트 하나를 여는 것만으로 끝나지 않습니다. SOCKS 포트는 애플리케이션이 직접 연결해야 하지만, 라우터가 가로채는 것은 원래 임의의 대상 주소로 향하던 트래픽입니다. 방화벽이 먼저 연결을 표시해 전달하고, 정책 라우팅이 표시된 데이터를 로컬 투명 인바운드로 되돌려 보내면 코어가 원래 대상 주소를 기준으로 프록시 또는 직결을 결정합니다.

TCP는 리디렉션이나 TPROXY를 사용할 수 있지만 UDP는 대상 정보를 보존하려면 일반적으로 TPROXY가 필요합니다. TCP만 처리하면 웹페이지는 정상적으로 열려도 게임, 실시간 통화와 일부 DNS 요청이 우회하거나 실패할 수 있습니다. 최신 OpenWrt는 보통 firewall4와 nftables을 기반으로 하므로 예전 튜토리얼의 iptables 명령을 그대로 복사해서는 안 됩니다. 규칙의 개념은 같지만 문법과 적용 위치가 다릅니다.

{
  "inbounds": [
    {
      "tag": "transparent-in",
      "listen": "0.0.0.0",
      "port": 12345,
      "protocol": "dokodemo-door",
      "settings": {
        "network": "tcp,udp",
        "followRedirect": true
      },
      "streamSettings": {
        "sockopt": {
          "tproxy": "tproxy"
        }
      }
    }
  ],
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      }
    ]
  }
}

위 설정은 코어 측의 핵심 구조만 보여 주며 노드 아웃바운드는 포함하지 않습니다. 방화벽 규칙을 대신할 수도 없습니다. 포트 12345는 nftables의 전달 대상과 일치해야 합니다. LAN 주소, 멀티캐스트, 라우터 관리 주소와 DHCP 트래픽은 먼저 제외해야 하며, 그렇지 않으면 게이트웨이 관리 페이지 접속이 다시 프록시로 전달될 수 있습니다.

DNS는 데이터 경로를 별도로 그려야 한다

• LAN 기기는 보통 게이트웨이의 53번 포트로 조회를 보내고, 게이트웨이의 로컬 해석 서비스가 사용할 업스트림을 결정합니다.
• 코어 DNS 인바운드가 1053에서 수신 대기한다면 로컬 해석 서비스가 지정된 도메인을 127.0.0.1:1053으로 전달하도록 설정하세요. 1053이 다시 53으로 돌아가 루프를 만들지 않도록 해야 합니다.
• 중국 본토 도메인과 LAN 도메인은 로컬 DNS를 사용하고, 프록시가 필요한 도메인은 원격 DNS로 전달한 뒤 해당 연결이 프록시 아웃바운드를 사용하도록 구성할 수 있습니다.
• 문제 해결 시 조회 도메인, 반환 주소와 실제 아웃바운드를 각각 기록하세요. ‘DNS 결과가 있다’는 사실만으로는 분기 설정이 올바른지 판단할 수 없습니다.

라우팅 분기: 먼저 내부망을 제외한 뒤 프록시 범위 결정

라우터의 트래픽 분기에서는 코어 규칙과 방화벽 규칙을 함께 고려해야 합니다. 방화벽은 어떤 데이터가 코어로 들어갈지를 담당하고, 코어는 들어온 뒤 어떤 아웃바운드로 보낼지를 담당합니다. 한쪽만 수정하면 두 가지 문제가 생기기 쉽습니다. 원래 직결이어야 할 LAN 트래픽이 가로채이거나, 코어에 프록시 규칙이 있어도 데이터가 투명 인바운드로 들어오지 않는 경우입니다.

최소 규칙 세트는 먼저 기본 네트워크가 작동하도록 한 뒤 도메인 분류를 추가해야 합니다. 사설 주소, 루프백 주소, 링크 로컬 주소, 멀티캐스트 주소와 라우터 자체에 필요한 연결은 투명 입구를 우회해야 합니다. 프록시 아웃바운드 연결도 반드시 제외해야 합니다. 그렇지 않으면 노드 서버로 향하는 코어의 연결이 다시 자신에게 가로채여 트래픽 루프가 생기고 CPU를 빠르게 소모합니다.

1. 먼저 192.168.1.0/24 같은 LAN 대역과 메인 라우터, 보조 라우터, 네트워크 저장 장비의 고정 주소를 제외하세요.
2. 노드 서버 주소를 제외해 프록시 아웃바운드가 포트 12345로 다시 들어오지 않도록 하세요. 노드 주소가 바뀌면 규칙도 함께 갱신해야 합니다.
3. DHCP에 사용하는 UDP 67번과 68번 포트, LAN 검색과 관리에 필요한 트래픽은 유지하세요.
4. 그다음 프록시가 필요한 도메인이나 주소 규칙을 추가하세요. 일치하지 않는 트래픽은 기본적으로 모두 차단하지 말고 미리 정한 정책에 따라 직결합니다.
5. 마지막으로 라우터 자체의 업데이트, LAN 기기 간 통신, 일반 웹, 영상과 UDP 앱을 테스트하세요.

적용 전 점검: 로그, 복구와 장애 위치 확인

전체 네트워크를 정식으로 인계하기 전에 프록시에 의존하지 않는 관리 경로를 준비해야 합니다. 가장 간단한 방법은 메인 라우터의 고정 관리 주소를 유지하고 IP, 게이트웨이와 DNS를 수동으로 입력할 수 있는 PC 한 대를 준비하는 것입니다. DHCP나 보조 라우터가 고장 나도 메인 라우터에 직접 접속해 설정을 복구할 수 있습니다.

로그 수준은 문제 해결 중에는 info로 사용하고, 안정화된 뒤에는 warning으로 낮추는 것이 좋습니다. 장기간 debug를 사용하면 기록량이 많아져 소용량 플래시에 부담을 줍니다. 모든 연결 기록보다 포트 점유, DNS 시간 초과, 라우팅 루프, 아웃바운드 핸드셰이크 실패와 프로세스 반복 재시작을 중점적으로 확인하세요.

배포할 가치는 기기 수와 유지 관리 의지에 달려 있습니다. PC와 Android 기기가 한두 대뿐이라면 각각 v2rayN, v2rayNG 또는 v2flyNG를 사용하는 편이 직관적이고 장애 범위도 작습니다. TV, 게임 기기 또는 개별 프록시 설정이 어려운 단말을 통합 관리해야 할 때 보조 라우터의 장점이 분명해집니다.

실제 적용에서는 복구 가능성을 최우선으로 두세요. 먼저 노드를 확인하고 코어를 실행한 다음, 로컬 SOCKS 테스트를 통과시킨 뒤 투명 트래픽을 연결하고, 기기 한 대를 인계한 후 DHCP를 변경합니다. 토폴로지, DNS와 정책 라우팅을 나눠 검증하면 라우터에서 코어를 직접 실행하는 일이 특별히 신비롭지는 않습니다. 다만 일반 클라이언트보다 네트워크 관리 작업이 한 단계 더 늘어나는 것은 사실입니다.