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

1. 요청이 코어에 전달되는지 확인

라우팅 규칙은 코어에 전달된 연결에만 적용됩니다. v2rayN은 데스크톱 클라이언트, v2rayNG는 Xray 코어를 사용하는 안드로이드 클라이언트, v2flyNG는 V2Fly 코어를 사용하는 클라이언트입니다. 그래픽 인터페이스에서 설정을 관리하더라도 실제 규칙 매칭은 현재 실행 중인 코어가 처리합니다. VMess와 VLESS는 프록시 프로토콜이며, 프로토콜을 바꾼다고 규칙 순서 오류가 자동으로 해결되지는 않습니다.

시스템 프록시는 시스템 프록시 설정을 따르는 앱에만 적용되는 경우가 많습니다. 앱이 자체적으로 직접 연결하면 코어 로그에 해당 연결이 표시되지 않습니다. 안드로이드 VPN 모드에서는 앱별 우회가 설정되어 있을 수도 있습니다. geosite 분류를 추가하기 전에 대상 앱의 연결이 의도한 인바운드로 들어오는지 먼저 확인하세요.

10808은 이 글의 테스트를 위한 예시일 뿐, 모든 버전의 기본값은 아닙니다. 클라이언트의 현재 인바운드 설정에서 수신 주소와 포트, SOCKS 활성화 여부를 확인하세요. 포트는 로컬 진입점에 해당하며 443은 보통 원격 웹사이트의 포트이므로 혼동하지 마세요. DNS도 암호화된 전송을 사용할 수 있으므로 모든 조회 요청이 UDP 53을 사용한다고 볼 수는 없습니다.

2. domain·ip와 데이터셋의 매칭 대상

domain과 ip는 라우팅 규칙의 필드이고, geosite:와 geoip:는 해당 필드에서 데이터셋을 참조하는 표기법입니다. geosite는 도메인이 속한 국가를 실시간으로 조회하지 않으며, geoip도 웹사이트의 사업 지역을 판별하지 않습니다. 클라이언트나 코어와 함께 배포된 데이터 파일을 기준으로 매칭하므로 데이터 출처와 업데이트 시점에 따라 결과가 달라집니다.

도메인 매칭 범위를 명확히 지정하려면 full: 또는 domain:을 우선 사용하세요. 접두사 없는 일반 문자열은 보통 부분 문자열로 처리되어 이름이 비슷하지만 관련 없는 도메인까지 매칭할 수 있습니다. 분류 이름이 실제 설치된 데이터 파일에 있는지도 확인해야 합니다. 다른 곳에서 분류 이름을 복사했다고 해서 로컬 데이터 파일에서도 지원되는 것은 아닙니다.

3. 규칙은 구체성이 아니라 순서대로 매칭

일반적인 field 규칙은 위에서 아래로 확인하며, 조건에 처음 맞는 규칙이 출구를 결정합니다. 아래쪽 규칙이 더 구체적이라는 이유로 코어가 위쪽의 포괄적인 규칙을 자동으로 덮어쓰지는 않습니다. 따라서 수동 예외를 분류 규칙보다 앞에 두고, 분류 규칙은 기본 동작보다 앞에 배치해야 합니다.

1. 명시적 예외를 먼저 배치: 직결 분류에도 포함되지만 프록시로 보내야 하는 테스트 도메인 등이 해당합니다.
2. 그다음 로컬 및 분류 규칙 배치: 사설 IP, 중국 본토 도메인, 중국 본토 주소 범위 등이 해당합니다.
3. 마지막으로 기본 출구 지정: 어떤 규칙에도 매칭되지 않은 요청에 적용할 기본 경로를 설정합니다.

한 규칙의 domain 배열에 항목이 여러 개 있으면 그중 하나만 매칭되어도 조건을 충족합니다. 하지만 서로 다른 조건 필드를 한 규칙에 넣으면 일반적으로 모든 조건을 동시에 만족해야 합니다. 예를 들어 domain과 port를 함께 지정하면 도메인과 포트 조건을 모두 충족해야 하며, 도메인 또는 포트 중 하나만 맞으면 되는 것이 아닙니다. 도메인 분류와 주소 분류를 각각 독립적인 직결 조건으로 사용하려면 규칙을 두 개로 나누세요.

4. 중국 본토 직결, 나머지는 프록시로 보내는 라우팅 예제

아래 예제는 routing 객체만 보여줍니다. 기존 설정에 태그가 direct인 직결 아웃바운드와 태그가 proxy인 프록시 아웃바운드가 있고, 매칭되지 않은 요청의 기본 아웃바운드로 proxy가 outbounds 배열의 첫 번째 항목에 있다고 가정합니다. 태그는 참조에 사용되므로 인터페이스에 ‘직결’이라고 표시되어 있다는 이유만으로 내부 태그도 direct라고 단정하면 안 됩니다.

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "domain": ["full:example.com"],
        "outboundTag": "proxy"
      },
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["geosite:cn"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": ["geoip:cn"],
        "outboundTag": "direct"
      }
    ]
  }
}

example.com은 예외 규칙의 우선순위를 설명하기 위한 예시 도메인이며, 실제 서비스에 권장하는 도메인은 아닙니다. 이 설정은 지정한 도메인을 프록시로 보내고, 식별 가능한 사설 IP 대상은 직결하며, 중국 본토 도메인 또는 주소 분류에 해당하는 요청도 직결합니다. 나머지 요청은 첫 번째 프록시 아웃바운드를 사용합니다. 이는 선택 가능한 정책 중 하나이며 모든 네트워크 환경에 적용되는 정답은 아닙니다.

• 데이터 파일: 해당 분류를 포함하는 사용 가능한 geosite·geoip 데이터 파일이 필요합니다. 파일을 읽지 못했다면 먼저 시작 오류를 해결하세요.
• 로컬 네트워크 접속: geoip:private는 데이터셋의 특수 주소 분류입니다. 이를 직결하도록 허용하기 전에 로컬 네트워크 접속이 본인의 격리 요구사항에 맞는지 확인하세요.
• 기본 출구 설정: 클라이언트가 생성한 설정에서 첫 번째 아웃바운드가 proxy가 아니라면 기본 출구 설정을 변경하세요. 예제를 그대로 복사한 뒤 나머지 연결이 모두 프록시로 전송된다고 가정하면 안 됩니다.
• 가져오기 범위: 라우팅 편집기는 rules 배열만 허용할 수 있지만, 사용자 지정 전체 설정에는 인바운드와 아웃바운드 등 다른 항목도 필요합니다. 먼저 가져오기 형식을 확인하세요.

5. domainStrategy와 DNS의 관계

AsIs는 라우팅을 위해 도메인을 추가로 조회하지 않습니다. 인바운드에서 도메인을 전달받았다면 IP 규칙만으로는 매칭되지 않는 경우가 많습니다. IPIfNonMatch는 도메인 규칙에 매칭되지 않을 때 조회를 시도한 뒤 IP 규칙을 적용합니다. IPOnDemand는 매칭 과정에서 IP가 필요한 규칙을 만나면 조회를 시작할 수 있습니다. 조회 시점이 다르면 앞쪽 IP 규칙이 판정에 참여할 기회도 달라집니다.

위 예제에서는 도메인 규칙에 매칭되지 않은 요청만 조회 결과를 통해 geoip:cn에 매칭될 수 있습니다. rules 끝에 모든 도메인에 매칭되는 프록시 규칙을 추가하면 도메인 단계에서 이미 규칙이 적용되므로, IPIfNonMatch는 ‘아직 매칭되지 않은’ 요청에 대한 IP 대체 조회를 실행하지 않습니다. 이 대체 경로를 유지하려면 전체 매칭 규칙을 임의로 추가하는 대신 기본 아웃바운드를 사용하세요.

라우팅을 위한 조회 전략과 최종 아웃바운드에서 대상 주소를 조회하는 설정은 서로 다릅니다. 라우팅이 AsIs를 사용해도 직결 아웃바운드에서는 도메인 조회가 필요할 수 있습니다. DNS가 반환하는 CDN 주소의 지역, IPv4만 반환하는지 또는 IPv6도 함께 반환하는지에 따라 주소 분류 결과가 달라질 수 있습니다. 웹페이지가 열리는지만 확인하지 말고 도메인, 조회 결과, 아웃바운드 태그를 각각 기록하세요.

6. 일정한 테스트 절차로 규칙 충돌 진단

v2rayN에서는 먼저 ‘설정’ → ‘라우팅 설정’으로 이동해 활성화된 규칙 세트를 확인하세요. 버전에 따라 메뉴 이름이 다를 수 있으므로 실제 인터페이스를 기준으로 확인해야 합니다. v2rayNG와 v2flyNG는 각각 자체 라우팅 설정과 현재 실행 중인 설정을 확인하세요. 다른 클라이언트의 메뉴 이름을 그대로 적용해서는 안 됩니다. 코어 간에 설정을 복사할 때는 필드와 데이터 파일 형식이 호환되는지도 확인하세요.

1. 기준 상태 기록: 현재 코어 이름, 라우팅 모드, 규칙 순서, 로컬 수신 포트를 저장하세요. 먼저 프록시 노드가 연결되는지 확인합니다.
2. 인바운드 확인: 데스크톱에서는 아래 명령어를 사용해 로컬 SOCKS 진입점을 명시하고 도메인 처리를 프록시에 맡길 수 있습니다. 포트는 실제 설정값으로 바꾸세요.
3. 출구 확인: 클라이언트의 연결 로그나 액세스 로그에서 테스트 도메인, 대상 IP, 아웃바운드 태그를 찾으세요. 로그 형식은 코어 버전에 따라 다릅니다.
4. 규칙 분리 테스트: 테스트 도메인의 full 규칙을 임시로 맨 위에 두고 direct와 proxy를 각각 지정하세요. 설정에 따라 출구가 바뀐다면 라우팅 진입점과 태그는 대체로 정상입니다.
5. 분류 규칙 복원: 임시 규칙을 삭제한 뒤 중국 본토 서비스 도메인, 다른 도메인, 로컬 주소를 각각 테스트해 분류와 기본 동작을 확인하세요.

curl --socks5-hostname 127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.com/

여기서 10초는 연결 단계의 시간 초과, 20초는 명령 전체의 제한 시간이며 성능 측정 결과가 아닙니다. --socks5-hostname을 사용하는 테스트는 로컬에서 먼저 조회한 뒤 IP를 전달하는 방식과 다르므로 도메인 규칙 검증에 적합합니다. HTTP 요청 테스트에 성공해도 해당 경로만 정상이라는 뜻이며, UDP나 모든 앱, TUN 모드까지 올바르게 설정되었다고 볼 수는 없습니다.

7. geosite·geoip 분기 설정 FAQ

안정적인 트래픽 분기는 규칙 개수가 아니라 각 규칙의 적용 범위가 명확하고 로그를 통해 결과를 설명할 수 있는지에 달려 있습니다. 소수의 예외 규칙과 분류 규칙, 기본 출구부터 유지하고 실제로 잘못 분기되는 사례에 따라 하나씩 수정하세요. 겹치는 규칙을 한꺼번에 대량으로 가져오는 것보다 원인을 추적하기 쉽습니다. 클라이언트와 코어의 역할은 프로토콜 가이드와 용어 빠른 참조에서 더 자세히 확인할 수 있습니다.