V2Ray 라우팅 규칙 설정: geosite/geoip 국내외 트래픽 분리

1. geosite와 geoip: 무엇을 기준으로 매칭할까

라우팅은 연결이 코어에 전달된 다음 처리됩니다. 코어가 대상 도메인이나 IP를 확인하고 routing.rules를 순서대로 검사해 처음 조건에 맞는 규칙을 찾으면, 해당 연결을 지정된 outboundTag로 보냅니다. 여러 규칙의 매칭 결과를 합치거나 뒤에 있는 더 정밀한 규칙을 자동으로 찾지는 않습니다. 따라서 규칙의 내용만큼 배치 순서도 중요합니다.

geosite는 분류 데이터이지 실시간 검색 서비스가 아닙니다. 같은 이름의 분류라도 데이터 출처나 업데이트 날짜에 따라 포함 항목이 다를 수 있습니다. 시작 시 category-ads-all을 찾을 수 없다는 오류가 나오면 노드 프로토콜을 바꾸기 전에 데이터 파일에 해당 분류가 있는지 확인하세요. Xray와 V2Fly에서 흔히 사용하는 데이터 파일에 이러한 태그가 포함될 수 있지만, 실제 내용은 로컬 파일을 기준으로 확인해야 합니다.

2. domainStrategy: 라우팅을 위해 도메인을 언제 조회할까

routing.domainStrategy는 라우팅 판정 단계에서 도메인 조회 결과를 어떻게 사용할지 정합니다. 전역 DNS 설정 스위치가 아니며, 직접 연결 출구에 있는 같은 이름의 설정과도 다릅니다. 앱이 대상 IP를 코어에 전달하면 도메인 규칙만으로 웹사이트 이름을 알아낼 수는 없습니다. 대상이 도메인으로 전달됐을 때 IP까지 조회할지는 아래 전략에 따라 달라집니다.

이 글의 설정 예제는 마지막에 network: "tcp,udp" 프록시 기본 경로를 명시하므로 IPOnDemand를 사용합니다. IPIfNonMatch로 바꾸면 이 기본 경로 규칙이 첫 번째 매칭에서 적용되어 분류되지 않은 도메인은 ‘매칭 실패 후 조회’ 단계로 넘어가지 않습니다. 다른 방법은 전체 매칭 기본 경로를 삭제하고 설정에서 첫 번째 출구를 프록시로 두는 것입니다. 이 경우 정책 이름만 바꾸지 말고 클라이언트가 생성한 출구 순서도 확인해야 합니다.

• 도메인이 광고 규칙에 매칭되면 IP를 더 확인하지 않고 차단 출구로 보냅니다.
• 도메인이 국내 도메인 규칙에 매칭되면 직접 연결 출구로 보냅니다. 이후 IP 분류는 적용되지 않습니다.
• 도메인이 앞선 규칙에 매칭되지 않으면 IP 규칙에서 필요에 따라 주소를 조회합니다. 국내 IP는 직접 연결하고 나머지는 프록시 기본 경로로 보냅니다.

3. 설정 전 확인: 출구 태그, 포트, 데이터 파일

아래 설정에서는 출구 태그 세 개를 사용합니다. proxy는 이미 연결이 확인된 프록시 노드, direct는 Freedom 직접 연결, block은 Blackhole 차단입니다. 태그는 대소문자를 구분하는 문자열 참조이며 화면에 표시되는 이름이 아닙니다. 노드가 VMess인지 VLESS인지는 라우팅 태그를 참조하는 방식에 영향을 주지 않습니다. 전송 방식과 보안 설정은 기존 출구에서 그대로 관리합니다.

포트 10808은 이 글의 테스트 명령에서 사용하는 예시일 뿐, 모든 설치 환경의 기본값은 아닙니다. 명령을 실행하기 전에 클라이언트의 로컬 리슨 설정에서 실제 포트를 확인하고, 다르면 명령의 숫자를 바꾸세요. 리슨 주소는 127.0.0.1로 유지하면 됩니다. 라우팅 테스트를 위해 다른 로컬 네트워크 기기에 연결을 허용할 필요는 없습니다.

1. 설정 백업

   현재 설정과 사용자 지정 라우팅 규칙을 백업합니다. 먼저 현재 노드로 접속이 확인된 웹사이트에 연결해 기본 연결이 정상인지 확인한 다음 트래픽 분리 설정을 조정하세요.

2. 라우팅 설정 위치 확인

   v2rayN에서는 보통 ‘설정’ → ‘라우팅 설정’에서 관리합니다. 현재 활성화된 규칙 세트를 먼저 기록하세요. 버전에 따라 메뉴 위치가 다르면 실제 화면에 표시되는 ‘라우팅 설정’ 페이지를 기준으로 찾고, 기본 설정 JSON을 구독 주소 입력란에 붙여 넣지 마세요.

3. 출구 확인

   내보낸 실행 설정에서 프록시 출구의 실제 tag를 확인합니다. proxy가 아니라면 아래에서 해당 참조를 모두 바꾸고, 기존 노드의 서버·인증·전송 설정은 유지하세요.

4. 리소스 확인

   코어가 geosite.dat와 geoip.dat를 읽을 수 있고, 이 글에서 사용하는 cn, private, category-ads-all 등의 분류가 들어 있는지 확인하세요. 분류가 없다면 리소스를 먼저 수정하거나 해당 규칙을 제거한 뒤 테스트합니다.

5. 적용 후 재시작

   규칙을 저장한 다음 프록시 서비스를 재시작하고 시작 로그를 확인하세요. 웹사이트 접속을 테스트하기 전에 JSON 파싱 오류, 없는 태그, 리소스 로드 오류부터 해결해야 합니다.

4. 국내 직접 연결·광고 차단·프록시 기본 경로 설정

아래는 기본 설정 최상위에 병합할 수 있는 routing 객체입니다. 노드 인증 정보까지 포함된 전체 클라이언트 설정은 아닙니다. 광고 도메인 차단, 국내 도메인 직접 연결, 사설 주소 직접 연결, 국내 IP 직접 연결, 나머지 TCP/UDP 프록시 순으로 처리합니다. 앞에서 정한 세 가지 출구 태그가 설정에 있으면 기존 구성에서 이 규칙을 사용할 수 있습니다.

{
  "routing": {
    "domainStrategy": "IPOnDemand",
    "rules": [
      {
        "type": "field",
        "domain": [
          "geosite:category-ads-all"
        ],
        "outboundTag": "block"
      },
      {
        "type": "field",
        "domain": [
          "geosite:cn"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": [
          "geoip:private"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": [
          "geoip:cn"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "proxy"
      }
    ]
  }
}

이미 routing이 있다면 같은 레벨에 동일한 키를 다시 추가하지 말고, 기존 정책과 규칙 배열을 교체하거나 정리하세요. 아래에는 직접 연결 및 차단 출구 객체가 나와 있습니다. 필요한 객체를 기존 outbounds 배열에 추가하세요. 같은 태그가 이미 있다면 하나만 유지하고, 이 배열로 기존 프록시 노드를 덮어쓰지 마세요.

[
  {
    "tag": "direct",
    "protocol": "freedom",
    "settings": {}
  },
  {
    "tag": "block",
    "protocol": "blackhole",
    "settings": {}
  }
]

이 구성에서 ‘해외 트래픽은 프록시로 전송’한다는 것은 정확히 말해 ‘앞선 규칙에서 차단 또는 직접 연결 대상으로 분류되지 않은 트래픽은 프록시로 전송’한다는 뜻입니다. 해외 웹사이트를 하나씩 나열하는 방식은 아닙니다. 기본 경로를 사용하면 새로 생긴 도메인도 처리할 수 있지만, geoip:cn 때문에 해외 서비스가 중국 내 CDN 주소로 연결될 경우 직접 연결될 수 있습니다. 특정 사이트에 프록시를 반드시 사용해야 한다면 해당 사이트의 명시적 도메인 규칙을 IP 규칙보다 앞에 두세요.

5. 규칙 순서와 예외: 구체적인 규칙을 먼저

광고 규칙을 국내 도메인 규칙보다 앞에 두면 광고 분류에 포함된 국내 도메인도 차단됩니다. 꼭 필요한 로그인 또는 정적 리소스 도메인이 잘못 차단되면 구체적인 예외 규칙을 먼저 추가한 다음 광고 규칙을 유지하세요. 예외 범위는 가능한 한 좁게 설정합니다. 리소스 도메인 하나를 해결하려고 큰 도메인 목록 전체를 직접 연결하지 마세요.

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

static.example.com은 매칭 문법을 보여주기 위한 예시 도메인이며, 실제 서비스에서 허용해야 하는 리소스가 아닙니다. 적용할 때는 로그에서 확인한 전체 대상 이름으로 바꾼 뒤 이 규칙을 광고 규칙 앞에 넣으세요. 모든 하위 도메인까지 처리해야 할 때만 domain:을 사용하고, 특정 호스트 이름만 처리할 때는 full:을 우선 사용하세요.

광고 도메인 차단은 페이지 요소를 걸러내는 기능이 아닙니다. 광고와 본문이 같은 호스트 이름을 사용하면 라우팅으로 광고 영역만 삭제할 수 없습니다. 도메인을 차단하면 동영상 재생·로그인·통계 콜백까지 영향을 받을 수 있습니다. 기능에 문제가 생기면 실제로 매칭된 도메인과 출구를 확인하고 차단 범위를 줄이세요.

6. 트래픽 분리 확인: 웹페이지보다 출구 로그 확인

테스트할 때는 프록시 모드와 노드를 그대로 유지하고, 한 번에 규칙 하나만 수정하세요. 연결 대상과 출구를 기록할 수 있는 로그 수준을 잠시 활성화해 같은 요청의 대상과 출구 태그를 확인한 뒤 평소 로그 수준으로 되돌립니다. 로그에 접속 대상이 남을 수 있으므로 화면을 공유하기 전에 구독 주소, 노드 인증 정보, 개인 접속 기록을 삭제하세요.

1. 국내 도메인: 현재 geosite:cn에 포함된 것이 확인된 사이트를 골라 페이지 로딩 속도만 보지 말고 연결이 direct로 전달되는지 확인합니다.
2. 프록시 기본 경로: 앞선 규칙에 매칭되지 않는 것이 확인된 대상을 골라 proxy 출구로 연결되는지 확인합니다. 출구 IP 확인은 해당 요청을 검증하는 보조 수단일 뿐입니다.
3. 광고 규칙 매칭: 로컬 분류 데이터나 접속 로그에서 광고 목록에 속하는 것이 확인된 도메인을 찾아 block으로 전달되는지 확인합니다. 잘 모르는 사이트를 일부러 열 필요는 없습니다.
4. 사설 주소: 직접 관리하는 로컬 네트워크 서비스에 접속해 direct로 연결되는지 확인합니다. 브라우저가 시스템 설정을 따르지 않고 프록시를 우회하면 요청이 코어 로그에 아예 나타나지 않을 수 있습니다.

명령줄로 테스트하면 브라우저 캐시와 확장 프로그램으로 인한 간섭을 줄일 수 있습니다. 아래 명령은 로컬 SOCKS 리슨 주소가 127.0.0.1:10808이며, socks5h를 사용해 대상 도메인 조회를 프록시 서버에 맡긴다고 가정합니다. Windows에서는 명령 별칭과의 충돌을 피하도록 curl.exe를 사용하고, 다른 운영체제에서는 curl을 사용할 수 있습니다.

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

아래 두 주소는 요청 결과를 확인하기 위한 예시이며, 데이터 버전이나 네트워크 환경에 따라 최종 분류가 달라질 수 있습니다. HTTP 상태 코드가 반환됐다는 사실만으로 어떤 출구를 사용했는지 알 수 없으므로 로그도 함께 확인하세요. 첫 번째 명령이 리디렉션을 반환한다면 각 연결의 실제 대상을 기준으로 판단해야 합니다. 이후 새 도메인에 첫 요청과 같은 매칭 결과를 적용하지 마세요.

7. 자주 묻는 질문: DNS, 모드 덮어쓰기, 분류 누락

문제 해결 순서는 다음과 같이 정할 수 있습니다. 설정이 로드되는지, 요청이 코어에 들어오는지, 대상이 도메인인지 IP인지, 어떤 규칙이 처음 매칭되는지, 출구에서 연결을 설정할 수 있는지를 차례로 확인하세요. 이 다섯 가지를 먼저 점검한 다음 분류를 추가하거나 DNS를 조정합니다. 그러면 ‘규칙이 매칭되지 않은 문제’와 ‘규칙은 맞게 매칭됐지만 노드 연결이 실패한 문제’를 나눠 처리해 설정을 반복해서 바꾸며 생기는 혼선을 줄일 수 있습니다.