V2Ray 라우팅 규칙 설정: geosite·geoip 분기와 프록시·직접 연결

라우팅 분기: 요청이 먼저 코어에 도달하는지 확인

v2rayN은 데스크톱 GUI 클라이언트이고, v2rayNG는 Xray 코어를 사용하는 Android 클라이언트입니다. 인터페이스에서 노드와 설정을 관리하지만 라우팅 규칙은 코어가 실제로 판별합니다. VMess, VLESS 등의 프로토콜은 프록시 연결 방식을 정할 뿐, 특정 사이트를 직접 연결할지 프록시로 연결할지를 직접 결정하지 않습니다.

시스템 프록시는 해당 설정을 따르는 앱에만 적용됩니다. TUN이나 Android VPN 방식은 더 많은 트래픽을 처리할 수 있지만, 앱 제외 설정과 라우팅 설정, 시스템 권한의 영향을 받습니다. 브라우저가 연결을 클라이언트에 전달하지 않는다면 geosite 규칙을 열 개 수정해도 접속 경로는 바뀌지 않습니다.

• 시스템 프록시 사용 시: 브라우저가 로컬 프록시 주소를 사용 중인지 확인한 다음, 로그에 대상 도메인이 표시되는지 살펴봅니다.
• TUN 사용 시: 가상 네트워크 어댑터가 실행 중인지, 대상 앱이 제외되지 않았는지 먼저 확인한 뒤 코어의 트래픽 분기를 점검합니다.
• Android 사용 시: v2rayNG가 연결되어 있는지, 대상 앱이 VPN 적용 범위에 포함되어 있는지, 앱별 분기 설정에서 제외되지 않았는지 확인합니다.

geosite와 geoip: 도메인과 IP를 각각 매칭

geosite.dat에는 태그별 도메인 목록이, geoip.dat에는 태그별 IP 대역 목록이 저장됩니다. 규칙의 geosite:cn과 geoip:cn은 목록을 참조하는 표현이지, 네트워크 조회 명령이나 최신 목록을 자동으로 다운로드한다는 뜻은 아닙니다.

도메인을 직접 지정할 때 full:example.com은 해당 도메인만 정확히 매칭하고, domain:example.com은 해당 도메인과 하위 도메인까지 포함합니다. 접두어 없는 일반 문자열은 대개 부분 문자열로 매칭되어 관련 없는 도메인까지 포함할 수 있으므로, 정확한 예외에는 full: 또는 domain:을 우선 사용하세요.

규칙 리소스가 없으면 로그에 geosite·geoip를 불러오지 못했거나 태그를 찾을 수 없다는 오류가 표시될 수 있습니다. 현재 클라이언트에 있는 리소스 업데이트 기능을 사용하고, 실행 중인 코어가 실제로 읽는 리소스 경로도 확인하세요. 파일을 임의의 다운로드 폴더에 복사하는 것만으로는 해결되지 않습니다. 또한 geosite:어떤태그 형식이 모든 데이터 세트에서 지원되는 고정 문법이라고 가정하지 마세요.

규칙 순서: 먼저 일치하는 규칙이 적용되며 기본 출구는 별도로 확인

일반 라우팅 규칙은 배열 순서대로 위에서 아래로 확인하며, 처음으로 일치한 규칙이 아웃바운드를 결정합니다. 이후 규칙이 결과를 다시 덮어쓰지 않습니다. 한 규칙에서 서로 다른 조건 필드는 보통 모두 충족해야 하지만, 같은 domain 배열에 있는 여러 도메인 항목은 그중 하나만 일치해도 됩니다.

1. 명시적인 사이트 예외: 특정 사이트를 반드시 프록시로 연결해야 한다면, 범위가 넓은 직접 연결 목록보다 앞에 배치합니다.
2. 로컬 네트워크 및 사설 주소: 라우터나 로컬 네트워크 서비스로 향하는 요청은 직접 연결합니다. 실제 적용 범위는 사용하는 사설 주소 목록에 따라 달라집니다.
3. 일반 도메인 목록: 예를 들어 geosite:cn을 직접 연결로 지정합니다.
4. IP 할당 규칙: 예를 들어 geoip:cn을 직접 연결로 지정하고, 도메인 전략에 따라 규칙 적용 조건을 확인합니다.
5. 일치하는 규칙이 없을 때: 네이티브 설정에서는 첫 번째 아웃바운드가 사용됩니다. 클라이언트가 별도의 기본 규칙을 생성할 수도 있습니다.

‘모든 TCP·UDP를 프록시로 연결’하는 기본 규칙을 맨 앞에 두지 마세요. 일반 연결이 먼저 매칭되어 뒤에 있는 직접 연결 규칙이 실행되지 않습니다. 더 놓치기 쉬운 문제는 IPIfNonMatch를 사용할 때입니다. 범위가 넓은 기본 규칙이 먼저 매칭되면 ‘일치하는 규칙이 없을 때 도메인 확인’ 단계도 진행되지 않습니다.

domainStrategy: 라우팅 단계에서 도메인을 확인할지 결정

여기서는 routing.domainStrategy를 다룹니다. 라우팅 규칙을 매칭할 때 도메인을 어떻게 처리할지 정하는 설정입니다. 직접 연결 아웃바운드 내부의 같은 이름 설정과는 다르며, DNS 요청이 어느 출구를 통하는지도 단독으로 보장하지 않습니다.

어떤 도메인이 도메인 목록 어디에도 없지만, 조회된 IP는 geoip:cn에 해당한다고 가정해 보겠습니다. 앞서 일치하는 규칙이 없다면 IPIfNonMatch는 도메인을 조회한 뒤 직접 연결 규칙과 매칭할 수 있습니다. 반면 AsIs는 이 변환을 위해 도메인을 직접 조회하지 않습니다.

DNS 응답은 IP 규칙의 결과에 영향을 줍니다. DNS 서버마다 반환하는 CDN 주소가 다를 수 있고, IPv4와 IPv6의 할당 정보도 다를 수 있습니다. ‘같은 사이트가 어떤 때는 직접 연결되고 어떤 때는 프록시를 통한다면’ 실제 대상 주소와 DNS 설정, 매칭된 규칙을 함께 확인하세요. geosite가 작동하지 않는다고 바로 단정하지 마세요.

• 앱이 IP 주소만 전달하면 코어가 원래 도메인을 알지 못할 수 있어 도메인 규칙이 매칭되지 않을 수 있습니다.
• 트래픽 스니핑으로 일부 연결의 도메인을 확인할 수 있지만, 결과는 프로토콜과 암호화 방식, 현재 설정에 따라 다릅니다.
• 특정 사이트의 출구를 고정하려면 먼저 코어가 도메인을 확인할 수 있는지 점검한 다음 명시적인 도메인 예외를 추가하세요.

네이티브 설정 예시: 도메인을 우선하고 IP 규칙으로 보완

아래는 생성된 설정을 확인하거나 네이티브 설정을 편집할 때 참고할 수 있는 routing 부분만 보여 줍니다. 설정에 proxy와 direct 아웃바운드가 이미 있고, 첫 번째 아웃바운드가 proxy여야 합니다. 예시의 example.com과 example.org는 문서용 도메인으로, 실제로 특정 출구를 사용해야 한다는 뜻은 아닙니다.

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

이 부분에는 노드 인증 정보, 수신 대기 설정, DNS, 전체 아웃바운드 정의가 포함되어 있지 않으므로 클라이언트 설정 전체를 대체할 수 없습니다. GUI의 ‘라우팅 규칙 가져오기’ 기능도 자체 데이터 형식을 사용할 수 있습니다. JSON이라는 이유만으로 그대로 붙여 넣지 마세요.

• domain:example.com은 우선순위가 높은 프록시 예외입니다. IP 조회 결과가 직접 연결 주소 목록에 포함되더라도 도메인 규칙이 먼저 적용됩니다.
• full:example.org는 해당 도메인만 직접 연결하며 하위 도메인까지 자동으로 포함하지 않습니다.
• 도메인 요청이 첫 번째 매칭에서 완전히 실패한 경우에만 IPIfNonMatch가 IP 조회 후 재매칭을 시도합니다.
• 별도의 기본 규칙이 없다면 끝까지 매칭되지 않은 연결에는 첫 번째 아웃바운드가 사용되므로 아웃바운드 순서를 확인해야 합니다.

v2rayN·v2rayNG: GUI에서 규칙 설정하기

버전에 따라 메뉴 이름에 ‘설정’이나 ‘사용자 지정’ 같은 문구가 덧붙을 수 있습니다. 아래에는 일반적인 중국어 UI를 기준으로 메뉴 경로와 순서를 안내합니다. 이름이 다르면 기능을 기준으로 찾아보세요. 데스크톱에서 내보낸 라우팅 파일이 Android에서도 그대로 사용되는 공용 형식이라고 가정하지 마세요.

v2rayN: 설정을 복사한 뒤 우선순위 편집

1. 「설정」→「라우팅 설정」을 열고, 현재 정상 작동하는 설정을 보존한 다음 복사하거나 새 테스트 설정을 만듭니다.
2. 규칙 편집기에서 도메인 또는 IP 조건을 선택하고 domain:example.com, geosite:cn, geoip:cn 등의 항목을 입력합니다. 아웃바운드는 인터페이스에서 제공하는 프록시 또는 직접 연결 옵션을 사용하세요.
3. 명시적인 도메인 예외를 범위가 넓은 목록보다 앞에 배치합니다. 도메인 전략 옵션이 있다면 이에 해당하는 라우팅 동작도 확인합니다.
4. 저장한 다음 메인 화면의 라우팅 선택 영역에서 해당 설정을 활성화합니다. 저장만 하고 선택하지 않으면 현재 연결에는 보통 적용되지 않습니다.
5. 테스트 연결을 다시 시작한 뒤 로그나 생성된 설정을 확인해 규칙 순서, 기본 출구와 실제 태그를 점검합니다.

v2rayNG: 코어 라우팅과 앱별 분기를 구분

1. 사이드 메뉴에서 「설정」→「라우팅 설정」을 열고 현재 라우팅 모드, 도메인 전략, 프록시·직접 연결·차단 규칙 메뉴를 확인합니다.
2. 해당 사용자 지정 규칙 입력란에 도메인 항목을 추가합니다. geosite 참조 전체 지원 여부와 규칙 정렬 또는 JSON 편집 지원 여부는 현재 버전의 UI를 기준으로 확인하세요.
3. 대상 앱이 VPN 적용 범위에 들어 있지 않다면 먼저 앱별 분기 설정을 조정합니다. 이는 geosite 도메인 분기와는 별개의 설정입니다.
4. 저장한 후 연결을 끊었다가 다시 연결하고 새 요청을 보냅니다. 이미 연결된 장시간 연결은 기존 출구를 계속 사용할 수 있습니다.

규칙을 세밀하게 정렬해야 하는데 현재 버전에서 범주별 텍스트 입력만 지원한다면, 최종 생성된 규칙 순서를 확인하세요. UI에서 ‘프록시 도메인’과 ‘직접 연결 도메인’이 분리되어 있어도 충돌 시 어느 쪽이 먼저 매칭되는지는 알 수 없습니다.

분기 확인: 웹페이지가 열리는지만 보지 말고 로그에서 출구 확인

웹페이지가 열린다는 사실만으로 연결이 예상한 출구를 사용했다고 볼 수는 없습니다. 테스트 대상은 세 가지로 정하세요. 로컬 네트워크 주소, 명시적으로 지정한 도메인 예외, 어떤 목록에도 매칭되지 않는 일반 도메인입니다. 한 번에 한 항목만 바꾸고 연결을 다시 시도한 뒤 대상과 아웃바운드를 기록하세요.

위의 10808은 테스트용 예시이며 현재 클라이언트의 수신 대기 포트와 다를 수 있습니다. 먼저 실제 수신 대기 설정을 확인하세요. 시스템에 curl이 설치되어 있다면 데스크톱 터미널에서 아래 요청을 실행해 대상 도메인을 SOCKS 진입점으로 전달할 수 있습니다. 앱이 미리 도메인을 조회하면서 생기는 차이를 줄이는 데 도움이 됩니다.

curl --proxy socks5h://127.0.0.1:10808 --head https://example.com

socks5h는 이미 조회된 IP만 전달하는 테스트 방식과 다릅니다. 도메인 조회를 프록시 측에서 처리하도록 전달합니다. 이 테스트의 목적은 속도 비교가 아니라 로그의 대상과 규칙 입력을 일치시키는 것입니다. 로그 정보가 부족하면 잠시 로그 수준을 높이세요. 테스트가 끝나면 원래대로 되돌리고, 로그를 공유하기 전에 구독 주소와 노드 인증 정보, 개인 접속 기록을 삭제하세요.

자주 묻는 질문: 규칙을 저장했는데도 분기가 예상과 다를 때