2026년 10월 12일 · 라우팅 규칙 · 약 10분

V2Ray 라우팅 분할 설정: geosite·geoip로 중국 내외 트래픽 구분

중국 본토 트래픽은 직접 연결하고 해외 트래픽은 프록시로 보내는 설정을 예로 들어 geosite·geoip 규칙 작성법, domainStrategy 선택, 규칙 순서에서 자주 하는 실수를 설명합니다.

이 글의 핵심 내용

v2rayN으로 서버에 연결할 수 있고 라우팅을 조정하려는 Mac 사용자를 위한 안내입니다. 도메인 목록과 IP 주소 데이터베이스의 차이를 먼저 살펴본 뒤, “사설 주소는 직접 연결, 중국 본토 도메인과 IP는 직접 연결, 나머지는 프록시로 전송”하는 규칙을 설정합니다. 이해하기 쉬운 routing 예시와 함께 기본 아웃바운드, DNS, 규칙 순서가 실제 연결 경로에 어떤 영향을 주는지도 설명합니다.

geosite와 geoip: 서로 다른 매칭 대상

라우팅은 웹페이지 언어나 기기 위치를 기준으로 경로를 정하지 않습니다. 요청을 받은 V2Ray 코어는 사용 가능한 대상 도메인, 대상 IP, 포트 등의 정보를 확인한 다음 routing.rules를 위에서부터 순서대로 검사합니다. 규칙이 일치하면 해당 규칙에 지정된 outboundTag로 트래픽을 보냅니다. 이 태그는 outbounds에 실제로 존재하는 tag와 일치해야 합니다.

구문매칭 대상주요 제한 사항
geosite:cn도메인 분류 목록사용 중인 geosite 데이터 파일에 따라 달라지며 중국 본토의 모든 웹사이트를 포함하지는 않습니다
geoip:cn데이터베이스에서 중국으로 분류된 IP 대역웹사이트 소속 회사나 콘텐츠 언어를 나타내지는 않습니다
geoip:private사설 및 특수 용도 주소 모음구체적인 범위는 사용 중인 데이터 파일을 기준으로 확인해야 합니다
domain:example.com지정한 도메인과 하위 도메인이름이 비슷한 다른 도메인은 포함하지 않습니다
full:example.com정확히 지정한 도메인하위 도메인은 포함하지 않습니다

geosite:cn은 분류 항목이며 도메인 접미사로 위치를 추정하는 방식이 아닙니다. .com 도메인도 목록에 포함될 수 있습니다. 반대로 해외 CDN을 사용하는 웹사이트는 도메인 분류와 IP 소속 국가가 서로 다르게 나올 수 있습니다. 도메인 정보가 있으면 우선 도메인 기준으로 라우팅하는 편이 일반적으로 IP만 보는 것보다 관리하기 쉽습니다.

v2rayN 라우팅 설정: 먼저 백업한 뒤 수정

v2rayN은 설정과 연결을 관리하는 클라이언트이며, 규칙을 실제로 실행하는 것은 선택한 코어입니다. Project V, V2Fly, Xray 생태계의 설정은 공통 필드도 있지만 각기 다른 확장 기능도 있습니다. 이 글에서는 일반적인 field 규칙만 사용하며, 특정 코어의 확장 매개변수를 다른 코어에 그대로 옮기지 않습니다.

  1. 현재 설정 기록하기

    메인 화면에서 현재 서버, 라우팅 모드, 시스템 프록시 상태를 기록합니다. 「설정」→「매개변수 설정」을 열어 사용 중인 코어와 로컬 수신 포트를 확인합니다. 버전에 따라 메뉴 구성이 다를 수 있으므로 실제 화면을 기준으로 확인하세요. 예시를 따라 하려고 현재 노드의 프로토콜을 지원하지 않는 코어로 바꾸지 마세요.

  2. 라우팅 규칙 백업하기

    「설정」→「라우팅 설정」으로 이동해 기존 규칙을 먼저 백업한 다음, 테스트용 라우팅 설정을 새로 만들거나 편집합니다. 메인 화면에서 이 라우팅 설정이 실제로 선택되어 있는지 확인하세요. 전역 프록시 또는 전역 직접 연결 모드가 그대로 선택되어 있으면 안 됩니다.

  3. 아웃바운드 태그 확인하기

    코어가 실제로 불러온 설정을 확인하고 프록시 및 직접 연결 아웃바운드의 tag를 점검합니다. 이 글에서 사용하는 proxy와 direct는 예시 태그입니다. 실제 태그가 다르면 규칙의 outboundTag도 함께 바꿔야 합니다.

  4. 적용한 뒤 로그 확인하기

    규칙을 저장한 다음 클라이언트에서 코어 설정을 다시 불러오고, 로그에서 시작 결과를 확인합니다. 알 수 없는 아웃바운드, 데이터 파일 로드 실패, JSON 파싱 오류가 발생하면 규칙을 더 추가하지 말고 먼저 백업을 복원하세요.

클라이언트는 일반적으로 실행 설정을 다시 생성합니다. 임시 config.json을 직접 수정하면 서버를 바꾸거나 재시작할 때 변경 내용이 덮어써질 수 있습니다. 평소에는 라우팅 설정에서 규칙을 저장하는 것이 좋습니다. 직접 설정 파일을 관리한다면 아래 내용을 자신의 설정 원본에 반영하세요.

routing 예시: 중국 본토는 직접 연결, 나머지는 프록시

아래 내용은 단독 라우팅 예시이며 완전한 클라이언트 설정이 아닙니다. 사용하려면 먼저 사용 가능한 프록시 아웃바운드와 protocol이 freedom인 직접 연결 아웃바운드가 있어야 합니다. 두 태그는 각각 proxy와 direct입니다. 코어가 해당 분류를 포함한 geosite 및 geoip 데이터 파일을 읽을 수 있는지도 확인하세요.

{
  "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"
      }
    ]
  }
}

규칙에 일치하는 항목이 없으면 코어는 일반적으로 outbounds의 첫 번째 아웃바운드를 사용합니다. 따라서 “나머지는 프록시로” 보내는 방식은 명시적 규칙으로 지정하거나 프록시를 기본 아웃바운드로 설정할 수 있습니다. 두 방식은 IPIfNonMatch에 미치는 영향이 다르므로 rules만 복사하고 아웃바운드 순서를 무시해서는 안 됩니다.

domainStrategy: 라우팅에서 도메인을 언제 해석할까

routing.domainStrategy는 라우팅 매칭 과정에서 도메인을 IP로 변환할지 결정합니다. 시스템 DNS 설정 스위치가 아니며 직접 연결 아웃바운드의 도메인 처리 정책과도 다릅니다. 이 필드를 바꿔도 DNS 요청이 자동으로 가로채지거나 암호화되는 것은 아니며, 상위 DNS 서버가 자동으로 선택되는 것도 아닙니다.

IPIfNonMatch

권장

먼저 이미 확인된 대상 정보로 규칙을 검사하고, 도메인이 어떤 규칙에도 일치하지 않을 때만 이름 해석을 시도해 결과를 다시 대조합니다. 시작 설정으로 적합하지만 마지막에 모든 요청과 일치하는 규칙이 있는지 확인해야 합니다. 이름 해석 결과로 추가 판정하려면 프록시를 첫 번째 아웃바운드로 두어 기본 동작을 명확히 하는 편이 좋습니다.

적합한 경우: 도메인 규칙을 우선하고 기본 아웃바운드를 명확히 관리하는 설정

AsIs

라우팅 단계에서 매칭을 위해 도메인을 능동적으로 해석하지 않습니다. 도메인 요청은 주로 domain 규칙으로 처리하고, 원래 대상이 IP인 요청은 계속 ip 규칙과 매칭할 수 있습니다. 연결 과정 전체에서 DNS 조회가 발생하지 않는다는 뜻은 아닙니다.

적합한 경우: 도메인 목록이 충분하고 라우팅 단계의 이름 해석 의존도를 낮추려는 설정

IPOnDemand

도메인 요청이 IP 정보가 필요한 규칙에 도달하면 이름을 해석한 뒤 판정합니다. 첫 번째 규칙이 geoip:private라면 비교적 이른 단계에서 이름 해석이 시작될 수 있어 DNS 사용 가능 여부와 반환 주소가 라우팅에 더 직접적인 영향을 줍니다.

적합한 경우: 해석된 주소를 기준으로 판단해야 하고 DNS 경로를 검증한 설정

정리: 기본 경로를 먼저 정한 뒤 이름 해석 전략을 선택하세요

“도메인 목록에 없는 대상은 IP로 추가 판정”하려면 먼저 프록시를 첫 번째 아웃바운드로 두고, 마지막의 전체 일치 규칙을 삭제한 다음 IPIfNonMatch를 사용해 확인하세요. 명시적 기본 규칙을 유지한다면 분류되지 않은 도메인이 바로 프록시로 전달되는 점을 감안하거나 IPOnDemand의 해석 결과를 별도로 테스트하세요.

같은 도메인에서도 IPv4와 IPv6 주소가 여러 개 반환될 수 있으며, DNS 상위 서버에 따라 CDN 접속 지점이 달라질 수도 있습니다. 한 번 geoip:cn에 일치했다고 해서 이후 모든 연결도 같은 결과가 나오는 것은 아닙니다. 안정적인 연결 경로가 필요하다면 우연히 반환된 CDN 주소를 규칙에 고정하지 말고 해당 도메인 전용 규칙을 설정하세요.

규칙 순서: 첫 번째로 일치하는 규칙을 사용하며 자동으로 더 적합한 규칙을 고르지 않습니다

규칙 목록은 위에서 아래로 확인하며 일치하는 규칙을 찾으면 해당 아웃바운드를 사용합니다. 코어가 두 규칙의 구체성을 비교해 선택하지는 않습니다. 전용 예외 규칙을 포괄적인 분류 규칙보다 위에 두고, 모든 요청과 일치하는 기본 규칙은 맨 마지막에 배치하는 것이 규칙 관리의 기본입니다.

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

예를 들어 특정 도메인이 도메인 데이터베이스에서 직접 연결 대상으로 분류되더라도 실제로는 프록시를 통해야 한다면 전용 규칙을 geosite:cn보다 위에 배치할 수 있습니다. example.com은 구문 설명용 예시 도메인이므로 실제 적용 시 대상 도메인으로 바꾸세요. 루트 도메인만 적용하고 하위 도메인은 포함하지 않으려면 full:을 사용하세요.

검증 및 문제 해결: 대상, 규칙, 아웃바운드 확인

웹페이지가 열렸다는 사실만으로 해당 요청이 예상한 경로를 거쳤다고 볼 수는 없습니다. 먼저 코어가 정상적으로 시작되었는지 확인한 다음, 동일한 요청을 보내고 액세스 로그에서 대상과 아웃바운드 태그를 살펴보세요. 코어마다 로그 형식이 다르며 일부 형식은 인바운드와 아웃바운드의 연결 관계를 보여 줍니다. 로그 수준이 낮다면 테스트 중에만 기록 수준을 높이고, 테스트가 끝나면 원래대로 돌려놓으세요.

curl --proxy http://127.0.0.1:10809 --connect-timeout 10 --max-time 20 -I https://www.baidu.com/
curl --proxy http://127.0.0.1:10809 --connect-timeout 10 --max-time 20 -I https://example.com/

여기서 10809는 설명을 위한 HTTP 프록시 포트일 뿐, 현재 v2rayN의 기본값을 뜻하지 않습니다. 「설정」→「매개변수 설정」에서 실제로 활성화된 HTTP 또는 혼합 수신 포트로 바꾸세요. 명령에 로컬 프록시를 직접 지정하면 터미널이 시스템 프록시 설정을 따르는지 여부를 변수에서 제외할 수 있습니다. 아래 두 요청은 주로 TCP 경로를 확인하며 브라우저의 UDP 동작은 검증하지 않습니다.

중국 본토 웹사이트가 여전히 프록시를 거치는 이유

먼저 로그에서 대상이 도메인인지 IP인지 확인한 다음 해당 도메인이 현재 geosite 데이터에 있는지 살펴보세요. IPIfNonMatch를 사용하면서 마지막에 모든 요청과 일치하는 프록시 규칙이 있으면 도메인을 다시 해석해 판정하지 않습니다. 우선 정확한 도메인을 지정한 직접 연결 규칙을 추가해 테스트하고, 곧바로 IP 대역 전체를 직접 연결하지는 마세요.

geoip:cn을 추가한 뒤 일부 웹사이트에 접속할 수 없는 이유

DNS에서 반환한 주소와 로그에 기록된 실제 아웃바운드를 확인하세요. 대상 IP가 중국 본토로 분류되지만 현재 네트워크에서 직접 연결할 수 없다면 해당 서비스 도메인에 프록시 예외 규칙을 추가하고 중국 본토 직접 연결 규칙보다 위에 배치하세요. 한 번에 규칙 하나만 바꾸고, 실패한 요청의 대상 기록을 비교할 수 있도록 남겨 두세요.

geosite 분류를 찾을 수 없다는 로그가 나오면

규칙에 적은 분류명, 코어가 실제로 불러온 데이터 파일 경로, 시작 로그를 확인하세요. 데이터 배포본마다 포함된 항목이 다를 수 있으며 구독 업데이트가 규칙 데이터베이스 업데이트를 뜻하지는 않습니다. 클라이언트의 데이터 업데이트 기능을 사용한 뒤 코어를 다시 시작하세요. 문제가 계속되면 존재 여부가 확인된 분류로 되돌리세요.

규칙을 바꿨는데 적용되지 않을 때 재설치해야 할까?

먼저 새 라우팅 설정이 선택되어 있는지 확인하고 코어 설정을 다시 불러온 다음, 테스트 앱의 기존 연결을 닫고 새 요청을 보내세요. 이미 연결된 장시간 연결은 규칙을 바꿔도 자동으로 다른 아웃바운드로 전환되지 않습니다. 클라이언트가 덮어쓸 수 있는 실행 파일이 아니라 설정 원본을 수정했는지도 확인하세요.

마지막으로 사용한 코어, 라우팅 규칙 내용, 테스트 요청에 해당하는 아웃바운드 태그 세 가지를 기록하세요. 로그를 공개하기 전에 구독 주소, 노드 인증 정보, 개인적인 접속 기록을 삭제하세요. 라우팅 설정의 검증 기준은 “지정한 요청이 지정한 아웃바운드로 안정적으로 전달되는 것”이지, 한 번의 속도 테스트 결과로 모든 규칙이 올바르다고 판단하는 것이 아닙니다.

v2rayN 다운로드플랫폼에 맞는 클라이언트를 선택하세요