V2Ray 고급 설정

라우팅 규칙 및 매칭 순서

라우팅 규칙은 코어에 들어온 연결이 어떤 아웃바운드를 사용할지 결정합니다. 규칙만으로 앱 트래픽이 프록시로 들어오게 만들거나 작동하지 않는 서버를 복구할 수는 없습니다. 라우팅을 이해하려면 유입, 매칭 조건, 아웃바운드를 구분하세요. 유입은 연결을 받고, 조건은 도메인·대상 IP·포트를 확인하며, 아웃바운드는 직접 연결·프록시·차단을 수행합니다. 앱 트래픽이 유입 단계에 도달하지 않으면 규칙을 아무리 완벽하게 작성해도 적용되지 않습니다.

생성된 설정의 태그부터 확인하기

v2rayN과 v2rayNG에서는 라우팅 설정 화면에서 규칙과 프리셋을 조정할 수 있습니다. 편집하기 전에 현재 설정이나 실행 로그를 확인해 프록시, 직접 연결, 차단 아웃바운드의 실제 태그를 파악하세요. 아래 예시는 proxy, direct, block이라는 아웃바운드가 있다고 가정합니다. 이 태그는 읽기 쉬운 이름일 뿐, 현재 클라이언트가 실제로 같은 이름을 사용한다고 보장하지 않습니다.

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

아래는 순서를 설명하기 위한 라우팅 예시이며 완전한 클라이언트 설정은 아닙니다. 예시 도메인은 실제 서비스 도메인으로 바꾸고, 분류 목록은 사용할 수 있는 데이터 파일과 맞춰야 합니다. 규칙은 위에서 아래 순서로 확인하며 처음 일치하는 규칙이 연결 경로를 결정합니다. 마지막의 전체 매칭 규칙은 남은 TCP 및 UDP 트래픽을 처리하므로 세부 규칙보다 앞에 두면 안 됩니다. 앞에 놓으면 뒤에 있는 도메인 및 IP 조건이 검사되지 않습니다.

도메인 조건과 IP 조건의 범위 이해하기

full:은 정확한 도메인을 매칭합니다. domain:은 도메인과 하위 도메인을 대상으로 합니다. geosite:는 도메인 목록을 참조하고, geoip:는 IP 목록을 참조합니다. 한 규칙에 도메인과 포트를 함께 지정하면 보통 두 조건을 모두 만족해야 하며, 둘 중 하나만 만족해도 된다는 뜻이 아닙니다. ‘특정 도메인 또는 특정 IP는 모두 직접 연결’하려면 규칙을 각각 만들어야 합니다.

domainStrategy는 라우팅 단계에서 매칭을 위해 도메인을 조회할지 결정합니다. AsIs는 원래 대상 정보를 최대한 사용합니다. IPIfNonMatch는 도메인 조건이 일치하지 않을 때 주소를 조회해 IP 조건을 추가로 검사합니다. IPOnDemand는 IP 판단이 필요한 규칙에서 주소 조회를 시작할 수 있습니다. 이 설정은 DNS 서버 목록이 아니며 앱이 자체적으로 수행하는 이름 조회를 코어가 자동으로 처리하도록 보장하지도 않습니다.

도메인이 여러 서비스에서 공유하는 IP 주소로 해석되면 IP 분류만으로는 서로 다른 서비스를 같은 출구로 보낼 수 있습니다. 출구를 명확히 제어해야 하는 서비스에는 구체적인 도메인 규칙을 사용하고, 포괄적인 분류 규칙보다 앞에 배치하세요. 소프트웨어가 로그인, 이미지, 인증, 업데이트 등 여러 도메인에 의존한다면 대표 도메인만 추가해서는 부족할 수 있습니다. 연결 로그를 참고해 필요한 도메인을 보완하되 전체 트래픽으로 범위를 무작정 넓히지는 마세요.

스니핑과 로컬 네트워크 규칙

‘트래픽 스니핑 사용’은 지원되는 연결 내용에서 도메인 정보를 복원해 도메인 기반 분기를 돕습니다. 모든 프로토콜을 식별하거나 암호화된 내용을 해독할 수 있는 것은 아닙니다. 대상 IP만 있는 연결에서는 도메인을 복원하지 못할 수도 있습니다. 활성화한 뒤 일부 앱에 문제가 생기면 먼저 스니핑 관련 대상 덮어쓰기 동작을 확인하고 해당 설정만 되돌리세요. DNS와 라우팅을 동시에 바꾸면 원인을 구분하기 어려워집니다.

로컬 네트워크에 직접 연결하려면 보통 사설 주소 규칙이 필요하며, 클라이언트의 ‘로컬 네트워크 우회’, 시스템 라우팅, TUN 제외 대역의 영향도 받습니다. 코어에 직접 연결 규칙이 있다고 해서 모든 로컬 네트워크 접근이 가상 네트워크 인터페이스를 우회한다고 단정하지 마세요. 사설 주소 대역을 원격으로 프록시하지도 마세요. 기업 네트워크의 내부 도메인과 주소는 실제 네트워크 구성에 맞춰 설정하고, 원격 사설망과 로컬 사설망이 겹치지 않는지 특히 확인해야 합니다.

확인할 때는 서버 하나를 고정하고 정확한 도메인, 분류 도메인, 매칭되지 않는 대상을 차례로 테스트한 뒤 로그에서 아웃바운드 태그를 확인하세요. 규칙을 편집해도 달라지지 않는다면 수정한 라우팅 설정이 선택되어 있는지, 연결을 다시 시작해야 하는지 확인합니다. 분류 데이터가 누락되었다면 먼저 로딩 오류를 해결하세요. 무작정 더 포괄적인 직접 연결 규칙으로 바꾸지 마세요. 기본 개념은 도움말 센터에서 더 확인할 수 있습니다.

FakeDNS 및 가상 주소 매핑

FakeDNS는 앱에 대상 서버의 실제 주소를 반환하지 않고 내부 가상 주소를 할당한 뒤 해당 주소와 도메인의 대응 관계를 저장합니다. 앱이 가상 주소에 연결하면 트래픽 처리 구성요소가 도메인을 찾아 라우팅과 아웃바운드를 적용해야 합니다. 이 기능은 도메인 정보를 유지하는 데 목적이 있습니다. 가상 주소가 일반 네트워크에서 직접 접속 가능한 것은 아닙니다. 매핑 환경을 벗어나면 해당 주소만으로는 보통 대상에 접근할 수 없습니다.

먼저 전체 트래픽 처리 조건 충족하기

FakeDNS가 작동하려면 관련 DNS 요청이 FakeDNS 처리 경로에 들어가야 하며, 앱이 가상 주소에 연결할 때 발생하는 트래픽도 같은 처리 방식으로 가로채야 합니다. 한쪽만 작동하면 이름 조회는 성공했지만 연결은 실패할 수 있습니다. 브라우저가 자체 암호화 DNS를 사용하면 FakeDNS를 우회할 수 있습니다. 앱이 이전 주소를 캐시한 경우에도 실제 주소를 계속 사용해 같은 기기에서 동작이 일관되지 않아 보일 수 있습니다.

v2rayNG에서 ‘FakeDNS 사용’을 켤 때는 VPN 모드, DNS 설정, 스니핑 관련 설정을 함께 확인하세요. 그래픽 인터페이스의 스위치 하나가 코어 설정 여러 곳을 자동으로 생성할 수 있으므로 불리언 값 하나만 비교해서는 안 됩니다. v2rayN의 TUN DNS도 트래픽 처리 구성요소가 비슷한 방식을 구현할 수 있지만, 설정 필드와 상태 위치는 Xray 코어와 다를 수 있습니다. 한쪽의 설정 조각을 다른 쪽에 그대로 붙여 넣지 마세요.

v2flyNG는 v2fly 코어를 사용하므로 지원 기능은 현재 화면과 설정 파싱 결과를 기준으로 판단하세요. 알 수 없는 필드가 나오면 오류 메시지를 무시하고 계속 켜지 말고 해당 코어가 지원하는 설정 구조를 확인해야 합니다. 클라이언트 이름, 화면의 스위치, 코어 설정은 서로 다른 계층입니다. 기능 이름이 같아도 필드가 완전히 호환되는 것은 아닙니다. 특히 클라이언트 간 DNS 설정을 옮길 때 주의하세요.

주소 풀과 스니핑의 연동 이해하기

{
  "fakedns": [
    {
      "ipPool": "198.18.0.0/15",
      "poolSize": 65535
    }
  ]
}

위 예시는 해당 구조를 지원하는 Xray 설정의 주소 풀 부분만 보여주며 FakeDNS를 활성화하는 완전한 방법은 아닙니다. DNS에서 FakeDNS를 사용하고, 관련 유입 경로에서 도메인을 복원하며, 가상 주소 대역의 트래픽을 처리해야 합니다. ipPool은 할당 범위, poolSize는 매핑 용량을 결정합니다. 서버 수나 네트워크 성능을 나타내는 값이 아닙니다. 먼저 클라이언트가 생성하는 호환 설정을 사용하세요. 이 부분만 추가해 테스트를 시작하지 마세요.

매핑 주소 대역은 현재 네트워크나 다른 가상 네트워크와 겹치면 안 됩니다. 기업 테스트 네트워크나 다른 터널 도구가 같은 범위를 사용하고 있다면 충돌을 피하도록 통합 관리해야 합니다. 가상 주소 풀을 트래픽 처리 제외 목록에 넣으면 앱 연결이 일반 네트워크로 빠져나갑니다. 이 주소 대역을 원격 직접 연결 정책에서 실제 대상으로 취급해서도 안 됩니다. 올바른 로컬 처리 계층에서 매핑을 복원해야 합니다.

트래픽 스니핑과 FakeDNS는 함께 사용할 수 있지만 역할은 다릅니다. 일반 스니핑은 연결 내용에서 도메인을 복원하려고 시도하고, FakeDNS는 앞서 만든 매핑을 사용해 도메인을 찾습니다. 연결이 들어왔을 때 매핑이 이미 사라졌다면 일반 스니핑만으로 복구하기 어려울 수 있습니다. 클라이언트 재시작, 매핑 만료, 구성요소 상태 불일치로 앱에 남아 있는 가상 주소의 도메인 정보가 사라질 수 있습니다.

사용 범위와 복구 방법 파악하기

도메인 기준으로 안정적으로 분기해야 하지만 유입 단계에서는 IP만 얻는 경우, 기본 연결 경로가 안정된 뒤 FakeDNS를 테스트할 수 있습니다. 고정 IP에 직접 연결하는 프로그램, 로컬 네트워크 검색, DNS 응답을 검증하는 일부 앱에는 적합하지 않을 수 있습니다. 이런 앱은 전역 스위치를 더 바꾸기보다 트래픽 처리 제외를 명확히 지정하거나 일반 DNS 방식을 고려하세요.

활성화한 뒤 일반 웹페이지, 로그인, 미디어, 백그라운드 작업을 차례로 테스트하세요. 일부 앱만 실패하면 자체 암호화 DNS를 사용하는지, IP에 직접 연결하는지, 활성화 전에 실행 중이었는지 기록하세요. 먼저 앱을 완전히 종료한 뒤 다시 시도하세요. 문제가 계속되면 다른 설정은 그대로 두고 FakeDNS만 끈 다음 같은 대상으로 비교해야 주소 매핑 문제인지 판단할 수 있습니다.

문제를 기록할 때는 도메인, 트래픽 처리 모드, 아웃바운드 태그만 남기면 됩니다. 전체 설정을 공개할 필요는 없습니다. FakeDNS를 끄면 문제가 사라지고 다시 켰을 때 안정적으로 재현된다면 DNS 가로채기, 주소 풀 라우팅, 매핑 복원 과정을 계속 확인하세요. 두 모드 모두 실패한다면 서버 연결과 일반 DNS 점검으로 돌아가야 합니다. 관련 없는 매개변수를 계속 바꾸지 마세요.

설정 확인 및 단계별 복구

고급 설정의 확인 목표는 ‘가끔 페이지가 열린다’가 아니라 요청이 어디로 들어와 어떻게 조회되고 어떤 규칙에 일치하며 어떤 아웃바운드로 나가는지 설명할 수 있는 상태입니다. 최소 설정을 기준으로 만든 다음 구독 필터, 라우팅, TUN, FakeDNS를 하나씩 추가하세요. 각 단계에서 복구할 수 있는 상태를 남겨야 문제가 생겼을 때 범위를 좁힐 수 있습니다. 원인 파악을 클라이언트 재설치로 대신하지 마세요.

고정된 테스트 항목 만들기

기본 구성에는 작동이 확인된 서버 하나, 일반 DNS, 가장 단순한 라우팅 규칙, 명확한 유입 방식이 포함되어야 합니다. 자주 사용하는 전체 도메인 하나, 로컬 네트워크 리소스 하나, 프록시가 필요한 서비스 하나를 고정 테스트 항목으로 선택하세요. 테스트 중에는 기기 네트워크와 서버를 그대로 유지하세요. 무선 네트워크를 바꾸고 DNS 서버를 수정한 뒤 접속 결과만으로 특정 설정이 유효하다고 판단하지 마세요.

변경할 때마다 원래 값, 변경 목적, 예상 결과를 기록하세요. 예를 들어 정확한 도메인 직접 연결 규칙을 추가했다면 막연히 ‘더 안정적일 것’이라고 기대하는 대신 로그의 아웃바운드 태그가 바뀌는지 확인해야 합니다. 저장하고 연결을 다시 시작한 뒤 테스트 앱의 기존 연결을 종료하고 다시 접속하세요. 구독 업데이트는 항목이 생성되는지, TUN은 인터페이스와 라우팅이 작동하는지, FakeDNS는 가상 주소가 복원되는지 각각 확인합니다.

로그로 실패 단계 구분하기

설정 파싱 오류는 보통 시작 단계에서 발생하며 필드, 문법, 태그 문제로 나타납니다. 리슨 실패는 포트 충돌이나 권한과 관련된 경우가 많습니다. 연결이 시작된 뒤 시간 초과가 발생하면 네트워크와 원격 서버를 확인해야 합니다. 가장 먼저 발생한 오류를 찾고 반복되는 후속 연결 실패만 복사하지 마세요. 앞 단계가 성공하지 못했다면 뒤 단계 오류는 그 결과일 수 있습니다. 뒤 단계만 수정해서는 근본 원인을 해결하기 어렵습니다.

로그 상세 수준을 일시적으로 높이면 대상과 아웃바운드를 확인하는 데 도움이 되지만 높은 상세 수준을 계속 유지하지는 마세요. 로그에는 도메인, 주소, 사용 내역이 포함될 수 있으므로 공유 전에 민감한 정보를 삭제해야 합니다. 스크린샷에서도 구독 URL, 연결 자격 정보, 전체 공유 링크를 확인하세요. 점검이 끝나면 평소 로그 수준으로 되돌리고 임시 파일을 정리해 민감한 설정이 다운로드 폴더나 공유 폴더에 남지 않게 하세요.

하나의 서비스가 여러 연결을 만들 수도 있습니다. 기본 문서는 열리지만 로그인에 실패한다면 관련 도메인이 다른 규칙을 사용하는 것이 원인일 수 있습니다. 이미지가 표시되지 않는 경우에는 리소스 도메인, 조회 결과, 주소 계열이 다를 수 있습니다. 전체 트래픽을 같은 경로로 보내기보다 실패한 요청을 기준으로 규칙을 보완하고 확인하세요. 필요하다면 잠시 간소화된 라우팅으로 비교한 뒤 테스트가 끝나면 기존 정책을 복원합니다.

변수를 역순으로 되돌리기

여러 설정을 연달아 바꾼 뒤 문제가 생겼다면 가장 최근에 변경한 항목부터 되돌리세요. 새로 추가한 FakeDNS를 끄고 일반 DNS를 복구한 다음 새 라우팅 규칙을 취소하고, 마지막으로 TUN 또는 VPN 트래픽 처리를 종료해 원래 유입 방식으로 돌아갑니다. 되돌릴 때마다 같은 테스트 항목으로 확인하세요. 그룹 비우기, 서버 삭제, 시스템 네트워크 초기화를 동시에 하면 문제가 해결되어도 원인을 알 수 없습니다.

클라이언트를 종료한 뒤에도 네트워크에 접속할 수 없다면 시스템 프록시가 남아 있는지, 가상 라우팅이 복구되었는지, 다른 네트워크 도구가 실행 중인지 확인하세요. 정체를 알 수 없는 네트워크 인터페이스를 바로 삭제하거나 시스템 라우팅을 한꺼번에 변경하지 마세요. 먼저 현재 상태를 저장하고 각 항목의 소유 프로그램을 확인합니다. 브라우저만 이상하면 브라우저 전용 프록시와 암호화 DNS를 확인하고, 앱 하나만 이상하면 앱별 트래픽 처리와 해당 앱의 네트워크 옵션을 확인하세요.

설정 흐름을 처음부터 다시 정리하려면 빠른 시작 가이드로 돌아가 가져오기, 모드, 연결, 확인 순서대로 진행하세요. 특정 증상을 찾으려면 도움말 센터를 이용하세요. 설치 파일은 다운로드 페이지에서 선택할 수 있습니다. 이 가이드의 설정 조각은 해당 계층을 설명하기 위한 것으로 완전한 설정을 대체하지 않습니다. 실제 환경에서 사용하기 전에 클라이언트, 코어, 현재 생성된 설정 구조를 확인하세요.