라우터 및 보조 라우터에 V2Ray 코어 배포: 아키텍처 선택과 주의사항

라우터 장비에 V2Ray 또는 Xray 코어를 설치하는 목적은 수동으로 설정하는 SOCKS 프록시를 하나 추가하는 데 있지 않습니다. 일반적으로 LAN 장치의 트래픽을 통합 게이트웨이에서 식별하고 라우팅, DNS 처리를 수행하도록 구성합니다. 배포 안정성은 설정 파일이 실행되는지만으로 결정되지 않으며, 게이트웨이 위치, Linux 네트워크 기능, 코어 설정, 규칙 데이터와 하드웨어 성능에 좌우됩니다.

이 글의 핵심

가정이나 소규모 사무실 네트워크에 게이트웨이 프록시를 구축하려는 독자를 위한 글입니다. 메인 라우터 직접 실행과 보조 라우터 아키텍처, V2Ray 및 Xray 코어 선택, 투명 프록시 진입점, 정책 라우팅, DNS 루프 방지, 성능 테스트와 장애 분석을 다룹니다. 먼저 아키텍처를 평가한 뒤 실제 배포 여부를 판단할 수 있습니다.

먼저 게이트웨이 위치 결정: 메인 라우터 직접 실행인가, 보조 라우터인가

메인 라우터 직접 실행은 인터넷 연결, NAT, DHCP와 방화벽을 담당하는 장비에서 코어도 함께 실행하는 방식입니다. 데이터 경로가 짧고 클라이언트의 기본 게이트웨이를 바꿀 필요가 없으며, LAN에 새로 연결된 장치도 쉽게 규칙 체계에 포함됩니다. 반면 모든 네트워크 기능이 한 장비에 집중되므로 코어 오류, 규칙 설정 오류 또는 메모리 부족이 LAN 전체에 영향을 줄 수 있습니다.

보조 라우터 게이트웨이는 보통 메인 라우터와 같은 서브넷에 두며, 외부 네트워크 연결은 메인 라우터가 계속 담당하고 보조 라우터가 지정된 장치의 포워딩과 투명 프록시를 처리합니다. 별도로 재시작하거나 쉽게 되돌릴 수 있어 컴퓨터나 Android 장치 한 대로 먼저 시험한 뒤 적용 범위를 넓히기 좋습니다. 다만 보조 라우터는 연결만 한다고 자동으로 트래픽을 인계받지 않습니다. 클라이언트의 기본 게이트웨이, DHCP 배포 설정과 정적 라우팅을 명확히 구성해야 합니다.

메인 라우터 직접 실행

인터넷 연결, NAT, DHCP, 라우팅과 코어 프로세스를 한곳에서 처리합니다. 데이터 경로는 짧지만 장애 영향 범위가 가장 큽니다.

적합: 하드웨어 여유가 충분하고 네트워크 구조가 단순하며 유지보수 시간을 확보할 수 있는 환경

보조 라우터 게이트웨이

권장

외부 네트워크 연결과 프록시 게이트웨이를 분리할 수 있습니다. 장치별로 단계적으로 적용하고, 설정에 실패해도 빠르게 메인 라우터로 되돌릴 수 있습니다.

적합: 가정용 네트워크 시험 배포, 낮은 위험의 롤백, 장치 그룹별 관리

단말에서 독립 실행

v2rayN, v2rayNG 또는 v2flyNG가 단말에서 구독과 프록시를 처리하며 LAN 게이트웨이는 변경하지 않습니다.

적합: 장치 수가 적고 단일 장치 트래픽만 처리하며 전체 네트워크 라우팅이 필요하지 않은 환경

선택하기 전에 실제 데이터 경로를 그려 보세요. 예를 들어 보조 라우터 주소가 192.168.1.2이고 메인 라우터 주소가 192.168.1.1이라면, 인계 대상 장치의 기본 게이트웨이는 192.168.1.2를 가리켜야 하며 보조 라우터의 기본 경로는 다시 192.168.1.1을 가리켜야 합니다. 클라이언트가 여전히 메인 라우터를 기본 게이트웨이로 사용하면 보조 라우터의 투명 프록시 규칙에는 해당 트래픽이 들어오지 않습니다.

결론: 첫 배포에서는 독립적인 롤백 경로를 우선 확보하세요

먼저 테스트 장치 한 대만 보조 라우터 게이트웨이를 사용하도록 설정하고 DNS, 국내 직접 연결, 프록시 출구와 연결 끊김 복구가 정상인지 확인한 뒤 DHCP를 수정해 일괄 배포하세요. 이렇게 하면 설정 오류를 테스트 장치에 국한할 수 있어 전체 네트워크가 동시에 중단되는 일을 막을 수 있습니다.

코어, 펌웨어와 프로세서 성능 평가 방법

라우터 장비에서 ‘V2Ray 지원’은 특정 바이너리 파일을 실행할 수 있다는 뜻일 뿐, 투명 프록시에 필요한 모든 기능을 펌웨어가 갖췄다는 의미는 아닐 수 있습니다. 최소한 프로세서 아키텍처가 맞는지, 시스템이 대상 코어를 실행할 수 있는지, 저장 공간이 충분한지, 서비스 관리자가 프로세스를 시작할 수 있는지, 코어 네트워크 모듈이 정책 라우팅과 투명 포워딩을 지원하는지 확인해야 합니다.

V2Ray 코어는 기존 VMess, VLESS와 일반적인 전송 설정에 적합하며, Xray 코어는 VLESS, 투명 프록시와 최신 전송 기능에서 더 자주 사용됩니다. 두 코어의 설정 구조는 비슷하지만 모든 필드를 그대로 바꿔 쓸 수 있는 것은 아닙니다. 구독 링크도 라우터 코어가 설정 파일로 직접 읽을 수 없으며, 일반적으로 관리 계층에서 구독을 먼저 해석한 뒤 코어 형식에 맞는 아웃바운드 설정을 생성합니다.

권장 구성: 게이트웨이에서 라우팅하고 단말에는 독립적인 진단 경로를 유지

라우팅 게이트웨이

코어 버전과 설정 경로를 고정
투명 프록시 진입점은 12345 포트에서 수신
도메인과 대상 IP에 따라 라우팅
로그는 시스템 서비스에서 통합 순환 관리

테스트 단말

데스크톱에서 v2rayN 7.x로 노드 확인
Android에서 v2rayNG 또는 v2flyNG로 대조 테스트
장애 복구를 위해 직접 연결 게이트웨이 유지
DNS와 프록시 출구 결과를 각각 기록

노드 가용성과 게이트웨이 포워딩 기능을 분리해 확인하면 구독 만료를 라우팅 규칙 장애로 잘못 판단하는 일을 피할 수 있습니다.

프로세서 성능은 코어 수만으로 판단할 수 없습니다. 같은 쿼드코어 장치라도 클록, 캐시, 암호화 명령어 지원과 냉각 설계에 따라 성능 차이가 크게 날 수 있습니다. 메모리는 코어 자체, 규칙 데이터, DNS 캐시, 로그와 펌웨어 백그라운드 서비스가 함께 사용합니다. 메모리가 128 MB뿐인 구형 장치는 대형 GeoSite 데이터를 불러올 때 메모리 회수나 프로세스 종료가 발생하기 쉽습니다.

12345

투명 프록시 예시 포트

1 GB

권장 시작 메모리

32 MB

권장 설정 및 로그 공간

10분

지속 부하 테스트 시간

설정 파일의 핵심 필드와 투명 프록시 진입점

게이트웨이 설정에는 최소한 인바운드, 아웃바운드, 라우팅과 로그의 네 부분이 포함되어야 합니다. 투명 프록시 인바운드에는 dokodemo-door를 자주 사용하며, followRedirect를 통해 방화벽 리디렉션 후의 원래 대상 주소를 전달받습니다. 아웃바운드에는 proxy, direct, block처럼 명확한 태그를 지정하고 라우팅 규칙에서 해당 태그를 참조합니다.

다음은 구조를 보여 주기 위한 예시이며 실제 서버 주소, 인증 정보와 전체 DNS 설정은 생략했습니다. 예시는 12345 포트에서 수신하고 TCP와 UDP를 모두 처리하며 대상 스니핑을 활성화합니다. 실제 사용 시 아웃바운드 프로토콜과 전송 필드는 노드 매개변수와 일치해야 합니다.

{
  "log": {
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "tag": "transparent-in",
      "port": 12345,
      "protocol": "dokodemo-door",
      "settings": {
        "network": "tcp,udp",
        "followRedirect": true
      },
      "sniffing": {
        "enabled": true,
        "destOverride": ["http", "tls"]
      },
      "streamSettings": {
        "sockopt": {
          "tproxy": "tproxy"
        }
      }
    }
  ],
  "outbounds": [
    {
      "tag": "proxy",
      "protocol": "vless",
      "settings": {
        "vnext": []
      }
    },
    {
      "tag": "direct",
      "protocol": "freedom"
    },
    {
      "tag": "block",
      "protocol": "blackhole"
    }
  ],
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["geosite:cn"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": ["geoip:cn"],
        "outboundTag": "direct"
      }
    ]
  }
}

geoip:private는 앞쪽에 배치해 LAN, 루프백과 예약 주소가 프록시 아웃바운드로 들어가지 않도록 해야 합니다. 도메인 규칙은 보통 스니핑 결과나 DNS 결과를 먼저 매칭에 사용하고, 일치하지 않을 때 대상 IP를 기준으로 판단합니다. 규칙은 위에서 아래로 실행되므로 범위가 지나치게 넓은 규칙을 앞에 두면 뒤의 더 정확한 직접 연결 또는 차단 규칙이 가려집니다.

inbounds: 투명 프록시 진입점의 수신 주소, 포트, 네트워크 유형과 리디렉션 동작을 지정합니다.
outbounds: 프록시, 직접 연결과 차단 출구를 저장하며 태그는 라우팅 규칙과 완전히 일치해야 합니다.
routing: 도메인, IP, 포트, 인바운드 태그 등의 조건에 따라 트래픽 출구를 결정합니다.
dns: 도메인을 어느 서버에 조회할지, 조회 트래픽을 프록시로 보낼지 결정합니다.
log: 최초 배포에서는 warning을 사용하거나 일시적으로 info로 전환하고, 안정화 후에는 과도한 로그를 장기간 출력하지 않는 것이 좋습니다.

결론: 최소 설정을 먼저 검증한 뒤 구독과 규칙 데이터를 추가하세요

먼저 인바운드 하나, 사용 가능한 아웃바운드 하나와 사설망 직접 연결 규칙 하나로 코어가 시작되는지 확인하세요. 이후 DNS, GeoIP, GeoSite와 다중 노드 선택을 단계적으로 추가합니다. 모든 기능을 한 번에 넣으면 포트, 필드와 규칙 오류를 분리하기 어려워집니다.

투명 프록시, 정책 라우팅과 DNS 루프

투명 프록시는 코어만으로 완성되는 기능이 아닙니다. 방화벽이 대상 트래픽을 선택하고 마크를 설정하면 정책 라우팅이 마크된 패킷을 로컬 투명 프록시 진입점으로 보냅니다. 코어는 원래 대상 주소를 읽은 뒤 아웃바운드를 선택합니다. TCP에는 리디렉션이나 TPROXY를 사용할 수 있고, UDP는 대상 정보를 유지하려면 보통 TPROXY가 필요합니다. 구체적인 명령은 펌웨어가 사용하는 방화벽 백엔드에 따라 달라집니다.

다음 명령은 Linux 정책 라우팅과 TPROXY의 핵심 관계만 보여 주며 모든 펌웨어에 바로 적용할 수 있는 완성형 스크립트가 아닙니다. 실행 전에 해당 모듈이 시스템에 포함되어 있는지 확인하고, 게이트웨이 자체, LAN 주소, 코어의 아웃바운드 연결과 관리 포트를 제외해야 합니다. 그렇지 않으면 트래픽 루프가 발생하기 쉽습니다.

ip rule add fwmark 1 table 100
ip route add local 0.0.0.0/0 dev lo table 100

iptables -t mangle -N V2RAY
iptables -t mangle -A V2RAY -d 0.0.0.0/8 -j RETURN
iptables -t mangle -A V2RAY -d 10.0.0.0/8 -j RETURN
iptables -t mangle -A V2RAY -d 127.0.0.0/8 -j RETURN
iptables -t mangle -A V2RAY -d 172.16.0.0/12 -j RETURN
iptables -t mangle -A V2RAY -d 192.168.0.0/16 -j RETURN
iptables -t mangle -A V2RAY -p tcp -j TPROXY --on-port 12345 --tproxy-mark 1
iptables -t mangle -A V2RAY -p udp -j TPROXY --on-port 12345 --tproxy-mark 1

보조 라우터에서는 IPv4 포워딩도 활성화해야 합니다. sysctl net.ipv4.ip_forward로 확인할 수 있으며 결과가 1이어야 활성화된 상태입니다. IPv6를 사용한다면 IPv6 라우팅과 방화벽 규칙을 별도로 설계해야 합니다. IPv4만 처리하는 경우 클라이언트가 인계되지 않은 IPv6 기본 경로를 통해 보조 라우터를 우회하지 않는지 확인하세요.

먼저 ip route로 보조 라우터의 기본 출구가 메인 라우터를 가리키는지 확인하세요.
ip rule로 마크 1이 라우팅 테이블 100을 조회하는지 확인하세요.
방화벽 카운터로 테스트 트래픽이 실제로 사용자 정의 체인에 들어오는지 확인하세요.
12345 포트를 대상 코어가 수신하고 있으며 수신 프로토콜에 TCP와 UDP가 모두 포함되는지 확인하세요.
마지막으로 코어 로그를 확인해 ‘트래픽이 들어오지 않음’과 ‘아웃바운드 연결 실패’를 구분하세요.

DNS에서 가장 흔한 문제는 조회 경로와 프록시 경로가 서로 겹치는 것입니다. 예를 들어 LAN 장치가 보조 라우터를 DNS 서버로 지정했는데, 보조 라우터가 투명 규칙에 다시 가로채일 주소로 조회를 보내면 시간 초과나 반복 연결이 발생할 수 있습니다. DNS 아웃바운드에 명확한 태그를 지정하거나 방화벽에서 로컬 DNS 프로세스와 업스트림 주소를 제외하세요.

성능 병목은 지속 부하로 판단해야 합니다

라우터 장비의 처리량은 프로토콜, 전송 계층, 암호화 연산, 연결 수와 냉각 상태가 함께 결정합니다. 웹페이지가 가끔 열리는 것만으로 성능이 충분하다고 볼 수 없으며, 짧은 속도 측정은 CPU 순간 부스트에 가려질 수 있습니다. 고정된 노드와 네트워크 조건에서 10분간 지속 전송을 수행하며 처리량, CPU, 메모리, 온도와 패킷 손실을 함께 기록하는 방법이 더 효과적입니다.

실험실 참고 조건은 쿼드코어 ARM Cortex-A53 1.5 GHz, 메모리 1 GB, 기가비트 포트와 300 Mbps 외부 회선입니다. 직접 연결 실측은 약 286 Mbps였고, 단일 VLESS over TCP with TLS 아웃바운드를 활성화한 뒤 지속 처리량은 약 126 Mbps, CPU 최고 사용률은 91%, 장치 온도는 54°C에서 72°C로 상승했습니다. 이 결과는 해당 하드웨어 조합에 연산 병목이 있음을 보여 줄 뿐이며, 실제 장치 테스트를 대신할 수 없습니다.

286 Mbps

테스트 장비 직접 연결 처리량

126 Mbps

프록시 지속 처리량

91%

테스트 CPU 최고 사용률

72°C

10분 후 온도

CPU 단일 코어가 장시간 100%에 가까운데 포트 사용률이 낮다면 병목은 대개 프로토콜 처리나 암호화 연산에 있습니다. CPU 사용률은 낮지만 패킷 손실이 늘면 네트워크 카드 드라이버, 소프트 인터럽트와 큐를 확인하세요. 실행 몇 분 후 속도가 점차 떨어진다면 온도와 클록 저하를 점검해야 합니다. 짧은 연결이 많으면 연결 추적 테이블과 메모리 부담도 커지므로 단일 연결 속도 측정 결과와 다를 수 있습니다.

관찰 항목	일반적인 현상	우선 점검할 항목
CPU	단일 코어가 지속적으로 90% 이상 사용되며 처리량이 더 늘지 않음	프로토콜 오버헤드, 암호화 성능, 프로세스 및 스레드 분배
메모리	사용 가능 메모리가 계속 줄고 코어 프로세스가 종료됨	규칙 데이터, 로그 크기, 연결 수
온도	처음 2분은 정상이나 이후 단계적으로 속도가 하락함	냉각, 클록 저하 상태, 장치 설치 위치
패킷 손실	지연 변동이 커지고 UDP 애플리케이션부터 이상이 발생함	포트 협상, 소프트 인터럽트, 방화벽 큐

가정용 기가비트 네트워크라고 해서 게이트웨이가 반드시 기가비트 프록시 처리량을 내야 하는 것은 아닙니다. 하지만 실제 외부 회선 속도는 처리할 수 있어야 하며 약 20%의 연산 여유를 남기는 것이 좋습니다. 300 Mbps 외부 회선이 테스트에서 안정적으로 126 Mbps밖에 처리하지 못한다면 규칙을 더 추가해도 하드웨어 병목은 해결되지 않습니다. 인계 범위를 줄이거나 더 높은 성능의 보조 라우터를 사용하고, 부하가 큰 단말은 클라이언트를 독립적으로 실행하세요.

서비스 전 점검과 일반적인 장애 처리

배포가 끝난 뒤 코어 상태가 ‘실행 중’으로 표시되는지만 확인해서는 안 됩니다. 완전한 검증에는 직접 연결 도메인, 프록시 도메인, LAN 주소, DNS 조회, TCP, UDP와 게이트웨이 재시작 후 복구가 포함되어야 합니다. 설정 파일 권한, 시스템 시간과 규칙 데이터 위치도 확인하세요. 인증서 검증에는 정확한 시간이 필요하고 GeoIP, GeoSite 파일이 없으면 해당 규칙이 예상대로 로드되지 않습니다.

클라이언트가 메인 라우터와 보조 라우터의 관리 주소에 접근할 수 있으며 사설망 트래픽이 프록시로 들어가지 않음
중국 본토 직접 연결 규칙과 프록시 규칙이 각각 예상한 아웃바운드 태그와 일치함
53 포트에는 예정된 DNS 서비스만 수신 중이며 중복 점유가 없음
투명 프록시 진입점 12345가 외부 네트워크 인터페이스에 노출되지 않음
재시작 후 코어, 정책 라우팅과 방화벽 규칙이 올바른 순서로 복구됨
코어 중지 시 명확한 장애 우회 정책이 작동해 모든 트래픽이 계속 사용할 수 없는 포트로 전달되지 않음

보조 라우터가 실행 중인데 장치 트래픽이 전혀 거치지 않는 이유는 무엇인가요?

먼저 장치에서 기본 게이트웨이를 확인하세요. 여전히 메인 라우터 주소라면 테스트 장치의 게이트웨이를 보조 라우터 주소로 바꾼 다음 방화벽 카운터로 패킷이 투명 프록시 체인에 들어오는지 확인합니다. DNS 주소만 바꿔서는 기본 포워딩 경로가 자동으로 변경되지 않습니다.

웹페이지는 열리지만 음성이나 게임 트래픽이 시간 초과될 때는 어떻게 하나요?

투명 프록시 진입점이 TCP와 UDP를 모두 수신하는지 확인하고, UDP 규칙이 TPROXY를 사용하며 마크가 라우팅 테이블 100으로 들어가는지 확인하세요. 이후 아웃바운드 노드가 현재 UDP 방식을 지원하는지 점검해야 합니다. TCP 웹 테스트만으로 전체 연결성을 판단하지 마세요.

보조 라우터를 재시작하면 명령을 수동으로 실행해야만 복구되는 이유는 무엇인가요?

시작 과정을 네트워크 준비, 코어 시작, 정책 라우팅 로드와 방화벽 로드의 네 단계로 나누고 각 단계가 이전 단계의 성공을 전제로 실행되게 하세요. 방화벽이 투명 포트보다 먼저 활성화되면 시작 중인 트래픽이 아직 수신하지 않는 12345 포트로 전달될 수 있습니다.

v2rayN에서는 구독이 작동하지만 라우터에 넣으면 시작에 실패하는 이유는 무엇인가요?

먼저 v2rayN 7.x의 ‘설정’ → ‘매개변수 설정’에서 실제 Core 유형을 확인한 뒤 라우터의 코어 유형 및 버전과 대조하세요. 구독 관리 계층이 생성하는 필드는 특정 코어에 의존할 수 있으므로 클라이언트가 내보낸 모든 필드를 범용 설정으로 간주해서는 안 됩니다.

LAN 저장소에 접근할 때 속도가 느려지면 어떤 규칙부터 바꿔야 하나요?

geoip:private 또는 명시적인 LAN 대역 직접 연결 규칙을 프록시 규칙보다 앞에 배치하세요. 또한 TPROXY에 들어가기 전에 방화벽이 192.168.0.0/16 등 실제 사설망 범위를 제외하는지 확인합니다. 변경 후에는 브라우저 캐시만 삭제하지 말고 규칙 카운터를 확인하세요.

최종 설정에는 시작 가능한 최소 버전과 현재 실행 중인 버전을 각각 보관하세요. 코어 교체, 규칙 데이터 업데이트 또는 DNS 업스트림 변경처럼 한 번에 변수 하나만 조정하고, 변경 후 동일한 검증 절차를 완료합니다. 라우터 배포의 신뢰성은 한 번에 많은 규칙을 작성하고 장기간 방치하는 데서가 아니라 관찰 가능성, 롤백과 재현성에서 나옵니다.