v2rayN 라우팅 규칙 설정 가이드: geosite·geoip 분기 구성

1. 라우팅 전제: 트래픽이 코어에 전달되어야 규칙이 적용됩니다

v2rayN은 설정을 관리하고 Xray 코어는 프록시 인바운드로 들어온 연결을 처리합니다. 브라우저가 시스템 프록시를 사용해야 관련 요청이 로컬 프록시 포트로 전달됩니다. 프로그램이 시스템 프록시를 거치지 않고 직접 인터넷에 연결하면 Xray 라우팅을 바꿔도 영향을 받지 않는 경우가 있습니다. 데스크톱 TUN은 별도의 트래픽 처리 방식입니다. 지원 여부와 권한 요건은 사용 중인 플랫폼과 클라이언트 기능을 확인하세요.

이 글의 설정 예시는 Xray JSON 필드를 사용합니다. v2rayN은 여러 코어를 관리할 수 있지만 코어마다 규칙 형식이 다르므로 서로 혼용할 수 없습니다. Android용 v2rayNG는 Xray를, v2flyNG는 V2Fly를 사용합니다. 개념이 비슷하더라도 데스크톱 설정의 메뉴 위치, 생성되는 설정 파일, 데이터 파일 버전을 그대로 적용해서는 안 됩니다.

1. 현재 코어 확인

   「설정」→「매개변수 설정」에서 현재 프로토콜에 지정된 코어를 확인하세요. 일부 버전에서는 이 항목이 「Core 유형」으로 표시됩니다. 시작 로그에 나온 코어 이름도 확인해 실제로 Xray가 실행 중인지 살펴보세요. 노드 프로토콜만 보고 판단하면 안 됩니다.

2. 라우팅 구성 백업

   「설정」→「라우팅 설정」으로 이동해 현재 선택된 구성과 규칙 순서를 먼저 기록하세요. 편집 전에 기존 구성을 백업하세요. 현재 버전에서 내보내기를 지원한다면 수정 전에 내보내 기존 사용자 지정 규칙을 덮어쓰지 않도록 합니다.

3. 프록시 인바운드 확인

   「설정」→「매개변수 설정」에서 로컬 수신 포트를 확인한 다음, 브라우저나 시스템 프록시가 같은 주소와 포트를 사용하는지 확인하세요. 원격 노드의 포트를 로컬 프록시 포트에 입력하지 마세요.

4. 적용 후 로그 확인

   저장한 뒤 메인 화면의 라우팅 선택 항목에서 대상 구성을 선택하고, 현재 버전의 안내에 따라 적용하거나 코어를 다시 시작하세요. 메뉴 위치는 버전에 따라 달라질 수 있으므로 생성된 설정과 시작 로그를 기준으로 확인하세요.

2. geosite, geoip, outboundTag의 역할

geosite는 도메인 집합이고 geoip는 IP 대역 집합입니다. 둘 다 온라인 조회 서비스가 아니라 코어가 읽는 데이터입니다. geosite:cn은 현재 데이터 파일에 포함된 cn 도메인 집합을 가리키며, 특정 접미사로 끝나는 모든 도메인을 의미하지는 않습니다. geoip:cn은 현재 데이터에 정의된 중국 본토 IP 대역과 일치합니다.

outboundTag는 기존 아웃바운드를 지정할 뿐, 새 아웃바운드를 만들지는 않습니다. 이 글에서는 direct를 직접 연결 아웃바운드로, proxy를 설정된 프록시 아웃바운드로 사용합니다. 이 태그는 Xray에 예약된 이름이 아닙니다. 생성된 설정에서 다른 태그를 사용한다면 규칙도 함께 바꿔야 합니다. 규칙에 proxy를 지정해도 같은 이름의 아웃바운드가 없으면 유효한 프록시 경로가 만들어지지 않습니다.

• 한 규칙의 domain 배열에 여러 도메인 조건을 지정하면 그중 하나만 일치해도 규칙이 적용됩니다.
• 한 규칙의 ip 배열에 여러 IP 조건을 지정해도 그중 하나만 일치하면 됩니다.
• 한 규칙에 domain, ip, port 등 서로 다른 필드를 함께 설정하면 지정된 조건을 모두 만족해야 합니다. 하나만 충족해도 되는 방식이 아닙니다.
• 규칙은 순서대로 검사합니다. 앞선 규칙이 연결과 일치하면 뒤의 규칙은 해당 연결의 아웃바운드를 다시 선택하지 않습니다.

3. 기본 구성: LAN·중국 본토는 직접 연결, 나머지는 프록시

일반적인 순서는 「LAN 예외 → 사용자 지정 예외 → 중국 본토 도메인 → 중국 본토 IP → 기본 프록시」입니다. 아래에는 사용자 지정 예외를 제외한 기본 구성을 제시합니다. 이 코드는 routing을 포함한 일부 객체일 뿐, inbounds, outbounds, 노드 인증 정보는 없습니다. 따라서 완전한 클라이언트 설정으로 단독 실행할 수 없습니다.

{
  "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"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "proxy"
      }
    ]
  }
}

첫 번째 규칙은 알려진 사설 IP 대상에 직접 연결하므로 라우터, LAN 파일 공유, 내부 네트워크 장치에 접근할 때 적합합니다. 두 번째 규칙은 도메인 데이터를 우선 확인합니다. 세 번째 규칙은 IP를 직접 대상으로 한 연결과, 해석된 IP를 기준으로 판단해야 하는 도메인 연결을 처리합니다. 마지막 규칙은 나머지 TCP·UDP 트래픽을 명시적으로 처리해 전체 설정에서 첫 번째 아웃바운드의 기본 동작에 의존하지 않도록 합니다.

도메인 중심의 일반적인 분기에서는 geosite:cn을 주요 기준으로 삼고 geoip:cn으로 IP 대상을 보완할 수 있습니다. 사내 사용자 지정 도메인을 쓰는 내부 서비스는 해당 도메인 접미사를 직접 연결 규칙에 명시하는 것이 좋습니다. 사설 IP 규칙이 모든 내부 도메인의 해석을 유도한다고 가정하지 마세요.

4. 도메인 해석 전략: AsIs와 IPOnDemand 중 선택하기

routing.domainStrategy는 라우팅 일치 판정에 IP가 필요한 시점을 정합니다. DNS 모듈의 서버 목록이나 직접 연결 아웃바운드의 동명 설정과는 다릅니다. 올바른 주소를 얻을 수 있는지는 DNS 설정, 네트워크 환경, 요청에서 도메인이 유지되는지 여부에도 달려 있습니다. 전략 필드 하나만 바꿔서는 잘못된 DNS 경로, DNS 요청의 전달 방식, 모든 앱의 트래픽 처리 문제를 동시에 해결할 수 없습니다.

IPOnDemand를 사용하면서 특정 도메인을 항상 프록시로 보내려면, 해당 도메인 규칙을 범위가 넓은 IP 규칙보다 앞에 배치하세요. 그렇지 않으면 도메인이 먼저 해석되어 직접 연결 조건에 맞는 주소가 나오고, 직접 연결 규칙이 먼저 적용될 수 있습니다. 규칙 우선순위와 DNS 결과를 함께 확인해야 합니다.

5. 사용자 지정 규칙: 도메인 예외, 포트 조건, 로컬 집합

사용자 지정 규칙은 범위가 분명한 도메인 몇 개부터 시작하세요. 아래 두 규칙은 각각 「지정한 호스트는 프록시 사용」과 「예시 도메인 및 하위 도메인은 직접 연결」을 뜻합니다. 예시 도메인은 문법 설명용이므로 실제 관리할 도메인으로 바꾸세요. 도메인 조건에 URL의 https://, 경로, 쿼리 매개변수를 넣지 마세요.

[
  {
    "type": "field",
    "domain": ["full:api.example.com"],
    "outboundTag": "proxy"
  },
  {
    "type": "field",
    "domain": ["domain:example.com"],
    "outboundTag": "direct"
  }
]

두 규칙은 해당 연결을 먼저 처리할 수 있는 광범위한 규칙보다 앞에 배치하고, 더 구체적인 api.example.com 규칙을 먼저 두세요. 순서가 반대면 하위 도메인이 먼저 전체 도메인 직접 연결 규칙에 일치해 뒤의 정확한 프록시 규칙이 적용되지 않습니다. 내부 네트워크 주소도 관련된다면 안전한 접근 경계와 도메인 예외 중 무엇을 우선할지 명확히 정하고, 같은 순서를 무조건 적용하지 마세요.

포트 조건은 대상 포트를 가리킵니다. 예를 들어 "port": "443"을 도메인 조건과 같은 규칙에 두면 「해당 도메인이면서 대상 포트가 443」인 연결을 뜻합니다. 해당 도메인에 접속하는 모든 연결을 의미하지는 않습니다. 포트 53만 지정한 프록시 규칙으로는 다른 전송 방식을 쓰는 모든 DNS 트래픽을 처리할 수 없으며 DNS 모듈 설정을 대신하지도 않습니다.

사용자 지정 집합을 관리하는 두 가지 방법

• 도메인이 적은 경우: domain 배열을 직접 관리하고 각 항목에 full: 또는 domain:을 사용해 범위를 명확히 지정하세요. 별도의 집합 파일이 필요 없고 수정 내용도 쉽게 확인할 수 있습니다.
• 도메인이 많은 경우: 코어 데이터 형식에 맞는 집합 파일을 준비하세요. 예를 들어 ext:custom.dat:office는 사용자 지정 데이터 파일에서 office 집합을 읽는다는 뜻입니다. 일반 텍스트 파일 이름과 태그를 조합한 표기가 아니며 임의의 원격 규칙 주소도 사용할 수 없습니다.
• 데이터 갱신: 현재 코어가 사용하는 리소스 디렉터리, 파일 읽기 권한, 실제 집합 이름을 확인하세요. 기존 geosite 데이터에 없는 태그는 규칙 이름을 바꾸는 것만으로 생성되지 않습니다.

6. 전체 프록시: LAN 연결을 유지할지 모든 트래픽을 노드로 보낼지

「전체 프록시」를 설정하기 전에 적용 범위를 정의해야 합니다. v2rayN의 라우팅 구성은 코어에 들어온 트래픽을 제어할 뿐, 시스템의 모든 프로세스를 자동으로 처리하지는 않습니다. 시스템 프록시를 사용하지 않는 프로그램은 계속 직접 연결할 수 있습니다. UDP 사용 가능 여부도 인바운드 방식, 노드 프로토콜, 서버 기능에 따라 달라집니다.

특정 사이트의 문제를 일시적으로 확인하는 경우 모든 분기 규칙을 바로 삭제할 필요는 없습니다. 먼저 정확한 도메인 프록시 규칙을 추가해 해당 도메인을 처리하는 규칙보다 앞에 배치하고, 사이트의 기본 도메인과 API 도메인을 확인하세요. 웹페이지 하나가 로그인, 정적 리소스, 다운로드 도메인에 동시에 요청을 보낼 수 있으므로 주소창에 표시된 호스트만 바꿔서는 전체 요청을 처리하지 못할 수 있습니다.

노드 프로토콜을 바꾸는 것도 라우팅 문제 해결을 대신하지 않습니다. VMess와 VLESS는 프록시 연결 방식을 설명하고, outboundTag는 현재 연결을 설정된 아웃바운드 중 어디로 보낼지 지정합니다. 프록시 노드 자체가 정상이라면 프로토콜 필드를 계속 바꾸기보다 규칙 조건과 순서를 먼저 확인하세요.

7. 검증 순서: 트래픽 처리, 규칙 일치, 출구를 단계별로 확인

출구 IP 주소는 한 번의 테스트 요청이 거친 경로만 보여줄 뿐, 모든 프로그램이 같은 규칙을 따른다는 증거는 아닙니다. 테스트 대상을 고정하고 설정을 한 항목씩 바꾼 뒤 새 연결을 만드세요. 기존 브라우저 연결은 이전 아웃바운드를 계속 사용할 수 있습니다. 필요하면 관련 페이지를 닫고 기존 연결을 종료하거나 테스트 프로그램을 다시 시작하세요.

1. 트래픽이 프록시로 전달되는지 확인

   대상 페이지를 열면서 클라이언트 로그에 해당 연결이 표시되는지 확인하세요. 로그가 없다면 geosite를 바로 조정하지 말고 시스템 프록시, 로컬 수신 포트, 프로그램 자체의 프록시 설정부터 점검하세요.

2. LAN 연결 확인

   실제 라우터나 파일 서버의 IP로 테스트하세요. 예를 들어 현재 네트워크에 실제로 존재하는 192.168.1.1을 확인할 수 있습니다. 이 주소는 흔한 예시일 뿐이므로 로컬 네트워크에 맞는 주소를 사용하고, 해당 내부 도메인도 별도로 테스트하세요.

3. 도메인 예외 확인

   새로 추가한 정확한 도메인에 새 요청을 보내고 로그에 표시된 대상 주소와 아웃바운드 태그를 확인하세요. 로그 형식은 코어 설정에 따라 다릅니다. 완전한 규칙 번호가 표시되지 않는다면 연결 성공 로그 한 줄만으로 어떤 규칙이 적용됐는지 단정하지 마세요.

4. 기본 경로 확인

   사용자 지정 예외에 포함되지 않은 공용 인터넷 대상을 선택하고 프록시 아웃바운드를 사용하는지 확인하세요. 문제 해결을 위해 로그 수준을 임시로 높였다면 점검 후 원래대로 되돌리세요. 로그를 공유하기 전에 구독 주소와 노드 인증 정보를 삭제하세요.

자주 발생하는 문제와 해결 방향

• 도메인은 예상대로 직접 연결되지만 IP를 직접 입력하면 프록시를 사용하는 경우: 해당 IP가 실제로 대상 집합에 포함되는지 확인하고 geoip 파일이 정상적으로 로드됐는지 점검하세요. 도메인 분류와 서버 IP의 지역 판정은 서로 다른 검사입니다.
• 규칙을 추가했는데도 이전 경로를 사용하는 경우: 해당 구성이 선택됐는지, 코어에 설정이 적용됐는지, 앞에 더 광범위한 규칙이 있는지 확인하세요. 그다음 기존 연결을 닫고 다시 테스트하세요.
• 시작할 때 집합이 없다는 메시지가 표시되는 경우: 데이터 파일, 집합 이름, 리소스 디렉터리를 확인하세요. 먼저 범위가 명확한 full: 규칙 하나로 라우팅 경로를 검증한 뒤 집합 로드 문제를 해결하세요.
• 로그에는 프록시 규칙이 적용됐지만 페이지가 열리지 않는 경우: 노드 연결 상태, DNS 결과, 서버 접근 제한을 추가로 확인하세요. 규칙 일치는 아웃바운드를 선택했다는 뜻일 뿐, 이후 연결까지 성공했다는 의미는 아닙니다.

안정적인 분기 구성은 각 규칙의 목적을 명확히 설명할 수 있어야 합니다. 어떤 주소는 반드시 직접 연결하고, 어떤 도메인은 명시적으로 프록시를 사용하며, 어떤 조건은 주소 해석에 의존하고, 마지막으로 어떤 규칙이 나머지를 처리하는지 정리하세요. 검증 가능한 규칙 몇 개로 기준 구성을 만든 뒤 집합을 확장하면, 겹치는 규칙을 한꺼번에 많이 가져오는 것보다 유지 관리가 쉽습니다.