라우팅 규칙 분기 실전: geosite와 geoip로 직접 연결과 프록시를 정확히 분리하는 방법

라우팅 분기를 세 가지 판단 대상으로 나누기

v2rayN의 라우팅 규칙은 최종적으로 Xray 코어가 실행합니다. 연결이 코어에 들어오면 라우팅 모듈은 대상 도메인, 대상 IP, 포트, 네트워크 유형, 인바운드 태그 등의 속성을 읽고 위에서 아래로 규칙을 확인합니다. 조건에 처음으로 일치한 규칙이 연결에 사용할 아웃바운드를 결정합니다. 일반적인 아웃바운드에는 프록시, 직접 연결, 차단이 있으며, 이 글에서는 프록시와 직접 연결을 정확히 분리하는 방법만 다룹니다.

중국 본토의 일상적인 네트워크 환경에서는 유지 관리가 쉬운 규칙을 세 가지 논리 계층으로 나눌 수 있습니다. 첫 번째 계층은 로컬 네트워크와 로컬 장치의 사설 주소를 처리해 라우터, 저장 장치 또는 로컬 서비스에 접근할 때 프록시 경로로 우회하지 않도록 합니다. 두 번째 계층은 중국 본토에 속하는 것이 명확한 사이트나 주소 대역을 처리해 직접 연결합니다. 세 번째 계층은 도메인 유형을 더 나열하지 않고 나머지 트래픽을 프록시 아웃바운드로 보냅니다.

사설 주소 계층: geoip:private에 매칭하고 직접 연결 아웃바운드를 사용합니다.
중국 본토 대상 계층: geosite:cn과 geoip:cn을 각각 매칭하고 직접 연결 아웃바운드를 사용합니다.
기본 처리 계층: 나머지 TCP 및 UDP 연결에 매칭하고 프록시 아웃바운드를 사용합니다.

여기서 말하는 “계층”은 정책 구조를 뜻하며, 각 계층에 규칙 객체를 하나만 작성할 수 있다는 의미는 아닙니다. 도메인 조건과 IP 조건은 별도의 규칙으로 나누는 편이 좋습니다. 같은 규칙 안의 서로 다른 필드는 일반적으로 모든 조건을 동시에 만족해야 하지만, 같은 필드 안의 여러 값은 하나만 일치해도 됩니다. domain과 ip를 구분 없이 하나의 규칙에 넣으면 실제 매칭 범위가 예상보다 좁아질 수 있습니다.

geosite와 geoip는 각각 무엇을 해결할까

geosite는 도메인 분류를 기준으로 판단합니다

geosite 데이터는 도메인 특성에 따라 분류되어 있습니다. geosite:cn은 중국 본토 범주로 분류된 도메인에 매칭할 때 사용합니다. 앱이 대상에 접근할 때 코어가 원래 도메인을 확인할 수 있다면, 도메인 규칙은 대상 연결을 만들기 전에 판단할 수 있으므로 대상 주소가 어느 IP 대역에 속하는지 먼저 확인할 필요가 없습니다.

도메인 분류는 콘텐츠 전송 네트워크, 동적 주소 또는 다중 주소 분산을 사용하는 사이트를 처리하는 데 적합합니다. 사이트의 해석 결과는 통신사, 지역, 시간에 따라 달라질 수 있지만 도메인의 소속은 대체로 더 안정적입니다. 이런 도메인을 직접 연결 아웃바운드에 매칭하면 주소 변경으로 인한 규칙 변동을 줄일 수 있습니다.

주의할 점은 geosite:cn이 데이터 파일의 도메인 분류를 뜻할 뿐, “현재 해석된 결과가 반드시 중국 본토에 있다”는 의미는 아니라는 것입니다. 사이트가 여러 지역의 노드를 사용할 수도 있고, 기업이 호스팅 위치를 변경할 수도 있습니다. 따라서 geosite는 도메인 정책을 표현하는 데 적합하지만 실시간 네트워크 측정을 대신할 수는 없습니다.

geoip는 대상 주소를 기준으로 판단합니다

geoip 데이터는 IP 주소 대역을 용도나 지역별로 분류합니다. geoip:private는 로컬 네트워크 같은 비공인 대상 주소를 포함하며, 로컬 장치 대역, 가정용 라우터 관리 주소, 네트워크 프린터, 내부 저장 장치에 직접 연결할 때 자주 사용합니다. 사설 주소는 원격 프록시로 처리하기에 적절하지 않은 대상이므로 일반 지역 규칙보다 앞에 배치해야 합니다.

geoip:cn은 중국 본토 주소 대역으로 분류된 대상에 매칭할 때 사용합니다. 앱이 특정 IP에 직접 연결하거나, 도메인이 기존 geosite 규칙에 매칭되지 않은 뒤 해석이 완료되면 IP 규칙으로 보완할 수 있습니다. 이는 geosite:cn을 대체하는 관계가 아니라 “도메인으로 식별”하는 경로와 “주소로 식별”하는 경로를 각각 담당합니다.

규칙 항목	판단 기준	일반적인 용도	권장 아웃바운드
`geoip:private`	대상 IP가 사설 주소 범위에 속함	로컬 네트워크, 로컬 장치 대역, 내부 서비스	직접 연결
`geosite:cn`	대상 도메인이 해당 분류에 속함	도메인으로 중국 본토 사이트 식별	직접 연결
`geoip:cn`	대상 IP가 해당 주소 대역에 속함	IP 직접 연결 또는 도메인 해석 후 보완 판단	직접 연결
`network: tcp,udp`	연결이 TCP 또는 UDP를 사용함	앞선 규칙에 매칭되지 않은 일반 트래픽 처리	프록시

domainStrategy는 도메인을 IP로 해석하는 시점을 결정합니다

geosite와 geoip만 작성하는 것으로는 충분하지 않습니다. 도메인 요청이 IP 판단으로 이어질지는 라우팅 설정의 domainStrategy에 따라 달라집니다. 이 매개변수는 라우팅 단계의 해석 동작에 영향을 주며, 단순한 “DNS 스위치”가 아닙니다. 이를 이해하면 “도메인 규칙은 정상인데 IP 규칙이 이어받지 못하는” 현상을 설명할 수 있습니다.

AsIs: 원래 대상 형식 유지

AsIs는 라우팅 단계에서 연결이 전달한 원래 대상을 우선 기준으로 판단합니다. 대상이 도메인이면 도메인 관련 규칙을 주로 사용하며, 라우팅 모듈이 geoip 규칙을 시도하기 위해 도메인을 자동으로 IP로 해석하지는 않습니다. 대상 자체가 IP라면 geoip 규칙은 정상적으로 매칭됩니다.

이 모드는 해석 작업이 적고 경로가 직관적이지만, “도메인이 geosite에 등록되지 않았고 해석된 주소로 다시 판단하려는” 상황에는 충분히 대응하지 못합니다. 예를 들어 중국 본토 도메인이 geosite:cn에 매칭되지 않으면, geoip:cn 주소 대역으로 해석되더라도 마지막 프록시 규칙으로 바로 넘어갈 수 있습니다.

IPIfNonMatch: 도메인 규칙이 매칭되지 않을 때 해석

IPIfNonMatch는 이 글에서 소개하는 3단계 분기에 적합합니다. 코어는 먼저 도메인 정보로 규칙을 시도하고, 도메인 규칙에서 결과를 얻지 못하면 대상 도메인을 해석한 뒤 얻은 IP로 주소 규칙을 시도합니다. 이렇게 하면 geosite:cn의 분류 장점을 먼저 활용하고, geoip:private와 geoip:cn으로 보완 판단을 수행할 수 있습니다.

이 전략은 정확도와 추가 해석 비용 사이에서 균형이 좋습니다. 도메인 연결이 시작될 때마다 즉시 IP 판단을 요구하지 않으면서도 도메인 분류가 부족할 때 두 번째 매칭 경로를 제공합니다. “중국 본토 도메인은 직접 연결하고, 중국 본토 주소도 직접 연결하며, 나머지는 프록시로 보낸다”는 일반적인 데스크톱 설정에는 대체로 AsIs보다 잘 맞습니다.

IPOnDemand: IP 조건이 있을 때 우선 해석

IPOnDemand는 라우팅 판단에 IP 정보가 필요할 때 도메인을 더 적극적으로 해석합니다. 설정에 매칭에 사용할 수 있는 IP 규칙이 있으면 해석이 더 일찍 수행될 수 있습니다. 대상 주소를 기준으로 세밀하게 제어해야 하는 설정에 적합하지만, DNS 경로, 캐시 상태, 해석 결과가 라우팅 과정에 더 직접적인 영향을 준다는 뜻이기도 합니다.

규칙의 목적이 일반적인 중국 본토 직접 연결과 나머지 프록시라면, “더 철저해 보인다”는 이유만으로 적극적인 해석 전략을 선택할 필요는 없습니다. 먼저 IPIfNonMatch를 사용하고 로그에서 매칭되지 않은 구체적인 대상을 확인해 조정하는 편이 대개 문제를 찾기 쉽습니다.

라우팅 해석과 DNS 아웃바운드를 함께 확인해야 합니다 domainStrategy는 라우팅 단계에서 IP 정보가 필요한지를 결정하지만, 해석 요청이 어느 경로로 전달되는지는 DNS 설정, 아웃바운드 태그, 라우팅 규칙의 영향을 받습니다. 해석 시간 초과, 비정상적인 결과 또는 요청 반복이 발생하면 DNS 설정과 라우팅 로그를 함께 확인해야 합니다.

바로 적용할 수 있는 3단계 라우팅 템플릿

아래 조각은 routing 부분만 보여 줍니다. 완전한 기존 설정에 direct라는 태그의 직접 연결 아웃바운드와 proxy라는 태그의 프록시 아웃바운드가 이미 있다고 가정합니다. 현재 설정에서 다른 태그를 사용한다면 템플릿의 outboundTag를 실제 값으로 바꿔야 합니다. 태그는 대소문자를 포함해 완전히 일치해야 합니다.

{
  "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라면 첫 번째 규칙에 바로 매칭됩니다. 대상이 geosite:cn 분류에 속한 도메인이면 두 번째 규칙이 적용됩니다. 중국 본토 IP를 직접 입력했거나 도메인 분류에 매칭되지 않은 대상이 IPIfNonMatch 단계에서 중국 본토 주소로 해석되면 세 번째 규칙이 처리합니다. 그 밖의 일반 TCP 및 UDP 트래픽은 마지막 프록시 아웃바운드로 전달됩니다.

완전한 설정에 특정 도메인 차단, 특정 업무 트래픽의 프록시 고정, 특정 프로세스의 아웃바운드 지정 같은 규칙이 더 있다면 이런 구체적인 규칙을 기본 처리 규칙보다 앞에 배치해야 합니다. 중국 본토 직접 연결 규칙보다 앞에 둘지는 우선순위에 따라 결정합니다. 예를 들어 geosite:cn에 포함된 도메인 하나를 반드시 프록시로 보내야 한다면, 해당 도메인의 개별 프록시 규칙을 geosite:cn보다 앞에 배치해야 합니다.

v2rayN에 적용할 때 먼저 확인할 네 가지 위치

1. 규칙이 사용하는 아웃바운드 태그 확인

템플릿의 direct와 proxy는 흔히 사용하는 태그일 뿐입니다. 실제 실행 설정은 현재 서버, 라우팅 모드, 코어 설정에 따라 v2rayN이 생성할 수 있습니다. 사용자 지정 설정이나 고급 라우팅을 수정하기 전에 현재 아웃바운드 태그를 확인해 규칙이 참조하는 대상이 실제로 존재하는지 확인하세요. 존재하지 않는 태그를 참조하면 규칙이 의도대로 전달되지 않으며, 코어 로그에 해당 오류가 표시되는 경우가 많습니다.

2. 현재 코어가 geosite 및 geoip 데이터를 읽을 수 있는지 확인

geosite:cn과 geoip:cn은 데이터 파일에 의존합니다. 코어 프로그램은 규칙을 실행하고, 분류 내용은 함께 제공되는 데이터에서 가져옵니다. 로그에 분류를 불러올 수 없거나, 파일이 없거나, 알 수 없는 항목이라는 메시지가 표시되면 규칙 순서를 계속 바꾸기보다 코어와 데이터 파일의 호환 상태부터 해결해야 합니다.

데이터를 업데이트한 뒤에는 관련 코어 프로세스를 다시 시작해 새 프로세스가 리소스를 다시 읽도록 해야 합니다. 설정 창만 닫는다고 실행 중인 코어가 다시 로드되는 것은 아닙니다. 테스트 전 v2rayN에서 연결을 중지한 뒤 다시 시작하고 새로 생성된 로그를 확인하세요.

3. 시스템 트래픽이 실제로 v2rayN에 들어오는지 확인

라우팅 규칙은 코어에 들어온 연결만 처리할 수 있습니다. 시스템 프록시를 사용한다면 앱이 시스템 프록시 설정을 따라야 하고, TUN 모드를 사용한다면 TUN 실행 여부, 라우팅 생성 여부, DNS 인계 상태를 확인해야 합니다. 특정 앱이 현재 진입 경로를 완전히 우회한다면 geosite나 geoip 규칙을 수정해도 네트워크 경로는 바뀌지 않습니다.

문제를 확인할 때 웹페이지 로딩 속도만으로 분기 결과를 추측하지 마세요. 대상에 접근할 때 연결 로그가 생성되는지, 어떤 아웃바운드 태그에 매칭되는지, 로그에 도메인으로 표시되는지 IP로 표시되는지를 확인하는 편이 더 정확합니다. 관련 기록이 전혀 없다면 라우팅 조건을 계속 추가하기보다 먼저 트래픽 진입 경로를 확인해야 합니다.

4. 구독 업데이트가 사용자 지정 라우팅을 덮어쓰지 않는지 확인

구독은 서버 노드와 연결 관련 매개변수를 제공하고, 라우팅 규칙은 클라이언트의 로컬 정책입니다. 구독을 업데이트하면 노드 목록은 바뀌지만 사용자 지정 라우팅의 보존 여부는 규칙 저장 위치와 현재 설정 방식에 따라 달라집니다. 장기간 사용할 규칙은 v2rayN의 라우팅 설정이나 명확하게 관리하는 사용자 지정 설정에 저장하고, 한 번 생성된 임시 실행 파일만 수정하지 마세요.

규칙 순서가 잘못되면 나타나는 대표적인 현상

프록시 기본 규칙을 맨 앞에 둔 경우

network: tcp,udp 프록시 규칙이 목록 맨 앞에 있으면 대부분의 일반 연결이 즉시 매칭되어 뒤에 있는 geoip:private, geosite:cn, geoip:cn은 실행될 기회를 얻지 못합니다. 일반적으로 중국 본토 사이트와 로컬 네트워크 대상까지 모두 프록시로 전달됩니다. 해결 방법은 제외 규칙을 추가하는 것이 아니라, 범위가 넓은 기본 규칙을 맨 뒤로 옮기는 것입니다.

개별 예외를 geosite:cn 뒤에 둔 경우

중국 본토 분류에 속한 업무 도메인 하나가 테스트 때문에 반드시 프록시를 사용해야 하는데 개별 규칙이 geosite:cn 뒤에 있다면, 연결은 먼저 중국 본토 직접 연결 규칙에 매칭됩니다. 구체적인 도메인 규칙을 분류 규칙보다 앞에 배치해야 합니다. 라우팅 목록 앞부분일수록 범위가 좁고 의도가 명확한 예외를 배치하기에 적합합니다.

geosite:cn만 작성하고 geoip:cn을 작성하지 않은 경우

이 설정은 도메인을 사용하는 많은 접속을 처리할 수 있지만 중국 본토 IP에 직접 연결하는 상황은 처리하지 못하며, 해석 결과로 미등록 도메인을 보완할 수도 없습니다. 로그에 대상이 IP로 직접 표시되는 경우가 많다면 도메인 목록을 계속 늘리는 것보다 독립적인 geoip:cn 규칙을 추가하는 편이 효과적입니다.

geoip:cn만 작성하고 geosite:cn을 작성하지 않은 경우

주소 판단에만 의존하면 해석 과정의 부담이 커지고 콘텐츠 전송 노드와 주소 분산의 영향을 더 많이 받습니다. 중국 본토의 특정 업무 도메인이 예상과 다른 주소로 해석되어 프록시로 넘어갈 수도 있습니다. 도메인 정책이 명확하다면 먼저 geosite:cn으로 의도를 표현하고, geoip:cn으로 보완하는 편이 적합합니다.

여러 조건을 하나만 일치하면 되는 것으로 잘못 이해한 경우

하나의 규칙에 domain, ip, port, network를 함께 작성하면 일반적으로 연결이 이 모든 필드를 동시에 만족해야 한다는 뜻입니다. 규칙이 매칭되지 않을 때는 도메인 하나가 목록에 있는지만 확인하지 말고 각 필드를 하나씩 점검하세요. 유지 관리를 쉽게 하려면 서로 다른 판단 기준을 의도가 하나인 여러 규칙으로 나누는 것이 좋습니다.

감이 아니라 로그로 검증하기

분기 규칙을 완성한 뒤에는 최소 네 가지 대상을 테스트하세요. 로컬 네트워크 주소, 중국 본토 분류 도메인, 중국 본토 직접 연결 IP, 그리고 프록시로 보내야 하는 일반 외부 도메인입니다. 한 번에 하나의 대상만 테스트하고 대상 형식, 해석 결과, 최종 아웃바운드 태그를 기록하세요.

라우터나 로컬 네트워크 서비스에 접속해 연결이 direct를 사용하는지 확인합니다.
안정적인 중국 본토 도메인에 접속해 geosite:cn에 해당하는 직접 연결 경로가 적용되는지 확인합니다.
명확한 중국 본토 IP에 연결해 geoip:cn이 독립적으로 매칭되는지 확인합니다.
앞서 언급한 분류에 속하지 않는 대상에 접속해 최종적으로 proxy가 처리하는지 확인합니다.

코어 로그 수준이 너무 낮아 라우팅 정보를 충분히 볼 수 없다면 문제를 확인하는 동안 로그 상세 수준을 높이고, 완료 후 일상적인 설정으로 되돌리세요. 로그에서는 대상 주소, 도메인 해석, 규칙 오류, 아웃바운드 태그를 중점적으로 확인합니다. 테스트 중에는 브라우저 캐시, 기존 장기 연결, 백그라운드 요청이 판단에 섞이지 않도록 하세요. 대상 페이지를 닫은 뒤 연결을 새로 만들면 결과를 더 쉽게 구분할 수 있습니다.

기본 템플릿을 확장할 때는 “구체적인 규칙을 앞에, 범위가 넓은 규칙을 뒤에”

3단계 템플릿은 출발점으로 적합하지만, 검증되지 않은 분류를 끝없이 덧붙이는 용도로는 적합하지 않습니다. 확장할 때는 먼저 업무 의도를 명확히 한 다음 도메인, IP, 포트, 인바운드 태그 중 무엇을 사용할지 결정하세요. 특정 도메인을 반드시 프록시로 보내야 한다면 구체적인 도메인 프록시 규칙을 추가하고, 특정 내부 네트워크 대역을 반드시 직접 연결해야 한다면 해당 IP 대역의 직접 연결 규칙을 추가하세요. 특정 UDP 업무에 별도의 아웃바운드가 필요하다면 네트워크와 포트 조건을 별도 규칙으로 작성합니다.

규칙을 하나 추가할 때마다 세 가지 질문에 답할 수 있어야 합니다. 어떤 대상을 처리하는가, 어느 규칙보다 앞에 있어야 하는가, 매칭되지 않으면 어디로 넘어가는가입니다. 답할 수 없다면 규칙 범위나 우선순위가 아직 명확하지 않은 것입니다. 규칙을 많이 만드는 것보다 순서가 분명하고 필드가 단순하며 로그로 검증할 수 있는 짧은 규칙 집합이 장기적으로 관리하기 쉽습니다.

이 글의 상황에 대한 최종 원칙은 한 문장으로 줄일 수 있습니다. 먼저 사설 네트워크를 보호하고, 명확한 중국 본토 도메인과 주소를 식별한 다음, 나머지 연결을 프록시로 보냅니다. geosite:cn은 도메인 계층의 정책을 담당하고, geoip:private와 geoip:cn은 주소 계층을 보완하며, IPIfNonMatch는 두 판단 경로를 연결합니다. 아웃바운드 태그가 정확하고 데이터 파일을 읽을 수 있으며 트래픽이 실제로 코어에 들어오기만 하면 이 구조로 직접 연결과 프록시를 이해하기 쉽고 점검 가능한 방식으로 분리할 수 있습니다.