config.reference

V2Ray 설정 파일 종합 참고서

최상위 JSON부터 인바운드, 아웃바운드, 라우팅, DNS와 정책까지 처리 흐름에 따라 필드를 확인합니다. 기존 설정 점검은 물론 그래픽 클라이언트 밖에서 코어가 실제로 읽는 규칙을 이해하는 데도 유용합니다.

설정 참고 시작 먼저 빠른 시작 보기
JSON 최상위 구조 라우팅과 DNS 검증과 문제 해결
01 / CONFIG

JSON 구조 개요와 처리 흐름

데이터가 설정을 어떻게 통과하는지 먼저 확인

V2Ray 설정은 서로 독립된 스위치의 모음이 아니라 순서가 있는 처리 흐름입니다. 애플리케이션 트래픽은 먼저 inbounds로 들어오고, 코어는 인바운드 연결에서 대상 주소, 포트, 네트워크 유형과 인바운드 태그를 가져옵니다. 이어서 routing이 규칙을 위에서부터 확인해 어느 아웃바운드로 보낼지 결정합니다. 도메인은 매칭 또는 연결 수립 과정에서 dns 해석 절차를 거칠 수 있으며, 마지막으로 outbounds에서 선택된 프록시, 직접 연결 또는 차단 출구가 처리합니다. policy, log 및 통계 설정은 목적지를 직접 바꾸지는 않지만 연결 수명, 관측 정보와 문제 해결 효율에 영향을 줍니다. 이 흐름을 이해하는 편이 필드를 따로 암기하는 것보다 안정적입니다.

최상위 객체에는 보통 log, dns, inbounds, outbounds, routing 및 policy가 포함됩니다. 배열의 각 인바운드와 아웃바운드에는 명확한 tag를 지정해야 합니다. 라우팅 규칙이 태그로 이를 참조하기 때문입니다. 태그는 설정 내부 식별자일 뿐 네트워크 연결을 자동으로 만들지 않으며, 구독에 표시되는 노드 메모와도 다릅니다. 흔한 오류는 규칙에 outboundTag: proxy를 적었지만 실제 아웃바운드 이름은 proxy-main인 경우입니다. JSON 문법 검사는 통과해도 실행 시 의도한 경로를 선택하지 못할 수 있습니다.

{
  "log": {
    "loglevel": "warning"
  },
  "dns": {
    "servers": [
      "1.1.1.1",
      "localhost"
    ]
  },
  "inbounds": [
    {
      "tag": "socks-in",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "auth": "noauth",
        "udp": true
      }
    }
  ],
  "outbounds": [
    {
      "tag": "proxy",
      "protocol": "vmess",
      "settings": {
        "vnext": [
          {
            "address": "node.example.com",
            "port": 443,
            "users": [
              {
                "id": "11111111-1111-4111-8111-111111111111",
                "security": "auto"
              }
            ]
          }
        ]
      }
    },
    {
      "tag": "direct",
      "protocol": "freedom"
    },
    {
      "tag": "block",
      "protocol": "blackhole"
    }
  ],
  "routing": {
    "domainStrategy": "AsIs",
    "rules": []
  }
}

객체, 배열과 필드 유형

JSON은 형식 요구 사항이 엄격합니다. 객체는 중괄호, 배열은 대괄호를 사용하고, 키 이름과 문자열은 큰따옴표로 감쌉니다. 불리언 값은 true 또는 false로만 작성하며 숫자에는 따옴표를 붙이지 않습니다. 마지막 필드 뒤에 쉼표를 남겨서는 안 되고 설정에 설명용 주석을 섞어서도 안 됩니다. 많은 “코어 시작 실패”는 프로토콜 문제가 아니라 복사 과정에서 전각 구두점, 굽은 따옴표, 중복 키 또는 괄호 계층 오류가 생겨 발생합니다. 편집할 때는 UTF-8 텍스트를 유지하고 먼저 순수 JSON 문법을 확인한 뒤 현재 코어가 해당 필드를 지원하는지 판단하세요.

지원되는 필드 범위는 코어 계열에 따라 다릅니다. v2rayNG는 보통 Xray 코어와 함께 사용하고, v2flyNG는 V2Fly 코어를 사용하며, v2rayN은 여러 유형의 코어와 설정을 관리할 수 있습니다. VMess, VLESS, 전송 계층 보안과 라우팅 필드는 서로 겹치는 부분이 많지만 REALITY 같은 기능은 실제 코어 지원 여부에 맞춰 선택해야 합니다. 다른 코어 전용 필드를 그대로 붙여 넣으면 “알 수 없는 필드”, 아웃바운드 초기화 실패 또는 저장 시 해당 필드가 삭제되는 일이 흔히 발생합니다. 설정을 옮길 때는 먼저 프로토콜 기능을 확인한 뒤 부분별로 이전하고, 파일 전체를 한 번에 교체하지 않는 편이 좋습니다.

그래픽 클라이언트와 코어 설정의 경계

v2rayN, v2rayNG와 v2flyNG는 모두 화면 설정, 구독 노드와 라우팅 옵션을 코어 설정으로 변환합니다. 화면의 “시스템 프록시”, “VPN 서비스”, “로컬 네트워크 우회” 같은 옵션이 같은 이름의 JSON 필드로 대응되는 것은 아닙니다. 일부는 운영체제의 트래픽 인계 계층에 속하고, 일부만 routing.rules에 들어갑니다. 따라서 문제를 해결할 때는 먼저 어느 계층의 문제인지 판단해야 합니다. 클라이언트가 트래픽을 인계했는지, 생성된 설정이 올바른지, 코어가 정상적으로 시작했는지, 대상 연결이 예상한 아웃바운드와 매칭됐는지를 순서대로 확인하세요. 구독 노드 상태만 바라보면 시스템 프록시와 라우팅 계층을 놓치기 쉽습니다.

설정을 수동으로 관리할 때는 socks-in, http-in, proxy, direct, block처럼 일관된 태그 이름을 사용하는 것이 좋습니다. 짧고 의미가 겹치지 않는 이름은 이후 규칙의 오타를 줄여 줍니다. 복잡한 설정이라면 각 아웃바운드의 역할도 기록하세요. 노드 메모를 영구 식별자로 사용해서는 안 됩니다. 클라이언트가 구독을 갱신하면 노드 이름은 바뀔 수 있지만, 역할을 나타내는 태그는 안정적으로 유지되어야 라우팅 규칙이 “프록시, 직접 연결, 차단” 같은 논리적 출구에만 의존할 수 있습니다.

02 / INBOUNDS

inbounds 인바운드: 트래픽이 들어오는 경로

수신 주소, 포트와 노출 범위

inbounds는 로컬 애플리케이션이 코어에 트래픽을 전달하는 방식을 정의합니다. 데스크톱 클라이언트에서는 SOCKS와 HTTP 인바운드가 흔하고, 모바일 클라이언트는 시스템 네트워크 인터페이스를 통해 애플리케이션 트래픽을 인계받기도 합니다. 수동 설정에서 가장 먼저 확인할 항목은 listen과 port입니다. 127.0.0.1에서 수신하면 로컬 연결만 허용하므로 브라우저, 터미널 또는 시스템 프록시에 적합합니다. 모든 네트워크 인터페이스에서 수신하면 접근 범위가 넓어지므로 로컬 네트워크 환경, 인증 방식과 시스템 방화벽을 함께 검토해야 합니다. 다른 기기의 연결이 명확히 필요한 경우가 아니라면 로컬 수신을 유지하는 편이 관리하기 쉽습니다.

포트는 다른 프로그램이 사용하지 않아야 하며, 서로 다른 인바운드가 동일한 주소와 포트 조합을 중복 수신해서도 안 됩니다. v2rayN 화면의 로컬 포트는 보통 클라이언트가 관리합니다. 설정을 수동으로 변경한 뒤 화면에는 이전 포트가 남아 있으면 시스템 프록시가 계속 이전 값을 가리켜 “코어는 실행 중이지만 웹 페이지가 열리지 않는” 현상이 나타날 수 있습니다. 이때는 코어 로그의 수신 정보, 클라이언트에 표시된 로컬 포트와 운영체제 프록시 설정을 모두 확인해야 하며 세 곳이 일치해야 합니다.

{
  "inbounds": [
    {
      "tag": "socks-in",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "auth": "noauth",
        "udp": true,
        "ip": "127.0.0.1"
      },
      "sniffing": {
        "enabled": true,
        "destOverride": [
          "http",
          "tls"
        ],
        "routeOnly": true
      }
    },
    {
      "tag": "http-in",
      "listen": "127.0.0.1",
      "port": 10809,
      "protocol": "http",
      "settings": {}
    }
  ]
}

SOCKS, HTTP와 투명 인계

SOCKS 인바운드는 SOCKS5를 지원하는 애플리케이션에 적합하며 udp: true로 UDP 요청도 받을 수 있습니다. HTTP 인바운드는 주로 HTTP 프록시와 CONNECT 터널을 처리해 다양한 데스크톱 소프트웨어와 호환됩니다. 두 방식 모두 애플리케이션 또는 시스템 프록시가 해당 포트를 명확히 가리켜야 합니다. 투명 인계는 다릅니다. 운영체제 라우팅, 가상 네트워크 인터페이스 또는 전달 규칙이 트래픽을 코어로 보낼 수 있어 대상 주소를 복원하는 방식이 더 복잡합니다. 그래픽 클라이언트는 보통 플랫폼 차이를 관리하므로 시스템 전달 흐름을 이해하지 못한 상태에서 데스크톱 SOCKS 예제를 투명 인바운드로 직접 바꾸는 것은 권장하지 않습니다.

settings의 내용은 인바운드 프로토콜에 따라 달라집니다. SOCKS의 auth, udp와 HTTP 인바운드의 계정 필드는 서로 바꿔 사용할 수 없습니다. 수신 범위가 로컬에 한정된다면 noauth가 흔한 설정입니다. 로컬 네트워크 기기에서 사용해야 한다면 먼저 클라이언트에서 해당 공유 기능을 활성화하고 접근 제어를 설정하세요. 수신 주소만 넓혀 공유를 끝내려 해서는 안 됩니다. 시스템 방화벽, 네트워크 유형과 인증도 실제 노출 범위에 영향을 줍니다.

트래픽 스니핑과 routeOnly

sniffing은 HTTP 요청이나 TLS 핸드셰이크에서 도메인을 식별하는 기능입니다. 원래 대상이 IP 주소로만 들어와도 도메인 규칙을 적용할 가능성을 확보할 수 있습니다. destOverride는 식별할 수 있는 프로토콜 유형을 지정하고, routeOnly는 스니핑 결과를 주로 라우팅 판단에만 사용하며 최종 연결 대상을 직접 바꾸지 않는다는 뜻입니다. 스니핑을 켠다고 모든 연결에서 도메인을 얻을 수 있는 것은 아닙니다. 암호화된 클라이언트 인사, 비표준 프로토콜, 이미 수립된 연결과 호스트 정보가 없는 트래픽은 여전히 IP만 보일 수 있습니다.

스니핑을 켠 뒤 일부 사이트의 연결에 문제가 생기면 두 가지 방법으로 점검할 수 있습니다. 첫째, 스니핑을 일시적으로 끄고 문제가 도메인 식별이나 대상 변경에서 비롯됐는지 확인합니다. 둘째, 스니핑은 유지하되 routeOnly를 사용해 도메인이 규칙 매칭에만 참여하도록 합니다. 규칙이 주로 IP 기반이라면 스니핑의 이점은 제한적입니다. 반대로 domain, geosite 또는 접미사 규칙을 많이 사용한다면 스니핑이 더 유용할 수 있습니다. 최종 선택은 고정된 성능 스위치가 아니라 규칙 설계에 따라 결정해야 합니다.

인바운드 유형 주요 용도 중점 확인 항목
SOCKS 브라우저, 터미널과 SOCKS5를 지원하는 애플리케이션 UDP 스위치, 수신 주소, 로컬 포트
HTTP 시스템 프록시와 HTTP CONNECT를 지원하는 소프트웨어 포트 일치 여부, 프록시 프로토콜 선택
투명 인계 시스템 전달 흐름 또는 가상 네트워크 인터페이스가 일괄 인계 플랫폼 권한, 대상 복원, 라우팅 루프
03 / OUTBOUNDS

outbounds 아웃바운드: 프록시, 직접 연결과 차단

아웃바운드 역할과 선택 순서

outbounds는 코어가 사용할 수 있는 출구를 정의합니다. 일반적인 설정에는 프록시 아웃바운드, freedom 직접 연결 아웃바운드와 blackhole 차단 아웃바운드가 최소 하나씩 포함됩니다. 라우팅 규칙은 outboundTag로 이 중 하나를 선택합니다. 규칙에 매칭되지 않으면 코어는 보통 아웃바운드 배열에서 사용 가능한 첫 항목을 사용하므로 배열 순서에도 실제 의미가 있습니다. 기본값을 프록시로 하려면 프록시 출구를 앞에 두고, 기본값을 직접 연결로 하려면 순서를 명확히 조정한 뒤 프록시가 필요한 규칙을 보완해야 합니다. 태그 이름만 바꾸는 것으로는 충분하지 않습니다.

하나의 아웃바운드는 프로토콜 계층, 서버 계정, 전송 방식과 보안 계층이 함께 구성합니다. VMess 또는 VLESS를 예로 들면 settings는 서버 주소, 포트와 사용자 정보를 설명하고 streamSettings는 TCP, WebSocket, gRPC 등의 전송과 TLS 또는 REALITY 같은 보안 방식을 설명합니다. 네 부분은 서버 측 매개변수와 각각 일치해야 합니다. 주소는 맞지만 전송 방식이 다르거나 포트는 맞지만 보안 계층 이름이 다르면 핸드셰이크가 실패합니다.

{
  "outbounds": [
    {
      "tag": "proxy",
      "protocol": "vless",
      "settings": {
        "vnext": [
          {
            "address": "edge.example.com",
            "port": 443,
            "users": [
              {
                "id": "22222222-2222-4222-8222-222222222222",
                "encryption": "none"
              }
            ]
          }
        ]
      },
      "streamSettings": {
        "network": "tcp",
        "security": "tls",
        "tlsSettings": {
          "serverName": "edge.example.com",
          "allowInsecure": false
        }
      }
    },
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {
        "domainStrategy": "UseIP"
      }
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {
        "response": {
          "type": "none"
        }
      }
    }
  ]
}

서버 주소, 사용자와 전송 계층

address에는 도메인 또는 IP를 사용할 수 있고 port는 숫자여야 합니다. 도메인을 사용하면 코어가 먼저 해석해야 하므로 DNS 설정이 프록시 아웃바운드 수립에 간접적으로 영향을 줍니다. 사용자 식별자, 암호화 설정과 flow 등의 필드는 프로토콜마다 다르므로 VMess 사용자 객체의 이름만 바꿔 VLESS 설정으로 사용해서는 안 됩니다. 공유 링크나 구독에 이러한 매개변수가 포함되어 있다면 클라이언트가 해석하도록 맡기는 편이 우선입니다. 수동 입력은 필드 대조에 적합하지만 경로, 호스트 이름, 서비스 이름 또는 서버 이름을 빠뜨리지 않도록 주의하세요.

streamSettings.network는 하위 전송 방식을 나타냅니다. WebSocket을 선택하면 보통 경로와 요청 헤더의 호스트가 필요하고, gRPC를 선택하면 서비스 이름이 필요합니다. TCP에서도 특정 헤더나 보안 계층을 설정할 수 있습니다. 전송 이름이 같다고 다른 매개변수를 생략할 수 있는 것은 아닙니다. 문제를 해결할 때는 “프로토콜 계정”과 “전송 핸드셰이크”를 분리하세요. 계정 오류는 프로토콜 인증 단계에서 실패하는 경우가 많고, 전송 매개변수 오류는 더 이른 시점에 연결 종료, TLS 이름 불일치 또는 서비스 경로 접근 불가로 나타납니다.

TLS, REALITY와 코어 차이

TLS 설정의 serverName은 서버 이름 검증과 핸드셰이크에 사용되므로 노드가 제공한 정보에 맞춰 입력해야 하며 연결 주소와 단순히 같은 값으로 보면 안 됩니다. allowInsecure는 인증서 검증을 제어하고 일반적인 설정에서는 false를 유지해야 합니다. 노드가 REALITY에 의존한다면 현재 클라이언트가 해당 기능을 지원하는 Xray 코어를 사용하는지 확인하고, 노드가 제공한 서버 이름, 공개 키, 짧은 식별자와 지문 등을 빠짐없이 입력하세요. v2flyNG는 V2Fly 코어를 사용하므로 클라이언트 선택 시 화면만 비교하지 말고 먼저 노드 프로토콜의 호환 범위를 확인해야 합니다.

v2rayN은 데스크톱 노드와 여러 코어 설정을 관리할 수 있어 Windows, macOS와 Linux에 적합합니다. v2rayNG는 Android용이며 Xray의 프로토콜 지원을 주요 기준으로 선택합니다. v2flyNG는 V2Fly 코어 계열의 대안입니다. 세 제품 모두 설정 관리 계층에 속하므로 노드 연결 여부는 프로토콜 매개변수, 코어 지원과 네트워크 경로가 함께 결정합니다. 해당 클라이언트를 설치하려면 클라이언트 다운로드 페이지에서 플랫폼을 선택하세요.

직접 연결, 차단과 체인형 출구

freedom은 로컬 네트워크에서 대상에 직접 연결하는 방식으로, 로컬 네트워크, 기기 주소 또는 로컬 출구가 명확히 필요한 도메인에 적합합니다. blackhole은 규칙에 매칭된 연결을 종료하는 데 사용합니다. 차단 규칙은 충분히 앞에 배치하되 매칭 범위는 최대한 좁혀 업데이트 서비스, 로그인 인터페이스 또는 로컬 네트워크 기기까지 함께 차단하지 않도록 하세요. 로그에 연결이 종료됐다는 내용만 보인다면 먼저 대상이 block에 잘못 매칭되지 않았는지 확인하고, 곧바로 프록시 노드를 바꾸지는 마세요.

복잡한 설정에서는 proxySettings 또는 다른 방식으로 한 아웃바운드를 다른 아웃바운드에 넘겨 앞단 프록시나 체인형 출구를 구성할 수 있습니다. 경로가 길수록 문제 해결 비용이 커집니다. 어느 한 계층에서 DNS, 전송 또는 인증이 실패해도 최종 연결이 끊기기 때문입니다. 체인형 설정을 만들기 전 각 출구가 단독으로 작동하는지 먼저 확인한 뒤 단계별로 연결하세요. 중간 아웃바운드의 태그는 고유하게 유지해 규칙이 체인 내부 전용 출구를 직접 선택하지 않도록 해야 합니다.

04 / ROUTING

routing 라우팅: 규칙 순서와 매칭 범위

위에서 아래로 확인하고 매칭되면 중지

routing.rules는 트래픽 분할 설정의 핵심입니다. 규칙은 배열 순서에 따라 위에서 아래로 확인되며, 연결이 한 규칙에 매칭되면 보통 이후 규칙은 평가하지 않습니다. 따라서 구체적인 규칙을 일반 규칙보다 앞에 배치해야 합니다. 로컬 네트워크 직접 연결은 광범위한 프록시 규칙보다 먼저, 명시적인 차단 항목은 포괄적인 도메인 접미사보다 먼저 두고, 최종 대체 경로는 마지막 규칙이나 기본 아웃바운드가 담당하게 하세요. 많은 분할 문제는 조건이 틀린 것이 아니라 앞쪽의 더 넓은 규칙이 트래픽을 먼저 가로채서 발생합니다.

규칙은 도메인, IP, 포트, 네트워크 유형, 인바운드 태그, 프로토콜 식별 결과 또는 사용자 식별자로 매칭할 수 있습니다. 하나의 규칙에 여러 종류의 조건이 함께 있으면 보통 모든 조건을 만족해야 하며, 같은 필드의 배열에 있는 여러 값은 하나라도 일치하면 된다는 의미입니다. 규칙을 설계하기 전에 자연어 요구 사항을 분해하세요. 예를 들어 “SOCKS 인바운드로 들어오고 대상 포트가 53인 UDP 트래픽을 DNS 아웃바운드로 보낸다”에는 인바운드 태그, 포트와 네트워크라는 세 가지 조건이 있습니다. 하나라도 빠지면 범위가 예상보다 넓어질 수 있습니다.

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "domainMatcher": "hybrid",
    "rules": [
      {
        "type": "field",
        "ip": [
          "geoip:private"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": [
          "domain:example.internal",
          "full:router.example.internal"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": [
          "geosite:category-ads-all"
        ],
        "outboundTag": "block"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "proxy"
      }
    ]
  }
}

도메인 규칙의 대표적인 네 가지 작성법

full:은 완전한 도메인 매칭에 사용하며 호스트 이름이 정확히 같은 경우만 매칭합니다. domain:은 보통 지정한 도메인과 하위 도메인을 포함합니다. regexp:는 정규 표현식을 사용해 유연하지만 범위가 넓어지기 쉽습니다. geosite:는 코어에서 사용할 수 있는 분류 데이터를 참조합니다. 접두사가 없는 작성 방식은 설정 맥락에 따라 의미가 달라질 수 있으므로 유지 관리를 위해 매칭 유형을 명시하는 편이 좋습니다. 도메인 규칙을 점검할 때는 웹 페이지 제목이나 제품명이 아니라 실제 접속 호스트 이름을 기록하세요.

정규 표현식 규칙에서는 이스케이프 계층을 함께 고려해야 합니다. 정규 표현식 자체에서 백슬래시를 사용하고, 이를 JSON 문자열에 넣을 때는 JSON 이스케이프도 필요하므로 눈으로 확인하면 빠뜨리기 쉽습니다. full:과 domain:으로 표현할 수 있는 요구라면 정규 표현식을 먼저 선택할 필요가 없습니다. 분류 데이터 역시 실시간 네트워크 상태가 아니라 데이터 파일에 따라 갱신되는 도메인 또는 주소 집합입니다. 매칭 결과는 현재 코어가 로드한 데이터 내용에 좌우됩니다.

IP, 포트, 네트워크와 인바운드 태그

IP 규칙에는 단일 주소, CIDR 네트워크 또는 geoip: 분류를 사용할 수 있습니다. geoip:private는 로컬 네트워크와 예약 주소를 직접 연결하는 데 흔히 사용되지만 실제 네트워크 환경과 함께 확인해야 합니다. 회사나 가정 네트워크에서 특수한 주소 범위를 사용한다면 해당 네트워크를 명시적으로 추가하세요. 포트는 단일 값 또는 범위로 작성할 수 있고, 네트워크 유형에는 보통 tcp, udp 또는 조합을 사용합니다. 제한 조건이 구체적일수록 다른 트래픽에 미치는 부작용이 줄어듭니다.

inboundTag를 사용하면 같은 대상이라도 진입 경로에 따라 다른 정책을 적용할 수 있습니다. 예를 들어 브라우저가 socks-in으로 들어오면 프록시를 사용하고, 특정 로컬 서비스가 다른 인바운드로 들어오면 직접 연결할 수 있습니다. 이는 코어 인스턴스를 두 개 복제하는 것보다 관리하기 쉽습니다. 단, 인바운드 태그가 실제로 존재하고 철자가 정확히 일치해야 합니다. 태그 비교는 대개 문자를 구분하므로 불필요한 공백, 대소문자 변경과 클라이언트의 설정 재생성으로 규칙이 작동하지 않을 수 있습니다.

domainStrategy는 언제 해석을 시작하는가

AsIs는 연결에 이미 포함된 도메인을 우선 사용해 라우팅하며 IP 규칙을 위해 도메인을 능동적으로 해석하지 않습니다. IPIfNonMatch는 도메인 규칙이 매칭되지 않을 때 도메인을 IP로 해석해 IP 규칙을 시도합니다. IPOnDemand는 IP 조건이 필요할 때 더 적극적으로 해석을 시작합니다. 전략이 적극적일수록 IP 기반 분할 능력은 높아지지만 DNS 의존성도 커집니다. DNS 서버에 연결할 수 없거나 예상과 다른 결과를 반환하면 라우팅 단계에서 지연과 오판이 생길 수 있습니다.

전략은 규칙 집합과 함께 선택해야 합니다. 도메인 규칙이 중심이고 IP 규칙은 직접 입력된 주소만 처리한다면 AsIs가 직관적입니다. 도메인이 최종적으로 지역 IP 분류와 매칭되어야 한다면 IPIfNonMatch를 고려할 수 있습니다. 변경 후에는 도메인 대상과 직접 IP 대상을 각각 테스트하고 로그에서 실제 선택된 아웃바운드를 확인하세요. 연결은 성공했지만 접속할 수 없는 문제를 체계적으로 점검하려면 DNS·라우팅 규칙·시스템 프록시 단계별 점검 목록도 참고할 수 있습니다.

05 / DNS

DNS 설정: 해석 경로와 트래픽 분할의 일관성

내장 DNS와 시스템 DNS의 역할

dns 모듈은 코어 내부의 도메인 해석을 위해 규칙과 서버 선택을 제공합니다. 주로 라우팅 판단, 프록시 서버 도메인 해석과 코어가 인계받은 요청에 사용됩니다. 운영체제의 모든 DNS 동작을 반드시 대체하는 것은 아닙니다. 애플리케이션이 직접 암호화 DNS를 요청하거나 브라우저가 시스템 설정을 우회하거나 트래픽이 코어로 들어오지 않으면 해당 쿼리는 이 모듈을 거치지 않을 수 있습니다. 문제를 해결할 때는 먼저 “누가 해석을 요청했는지” 확인한 뒤 V2Ray의 DNS 설정을 살펴보세요. 모든 도메인 문제를 하나의 모듈 탓으로 돌려서는 안 됩니다.

servers에는 일반 주소, localhost 또는 매칭 도메인을 포함한 서버 객체를 넣을 수 있습니다. 단순 목록은 설정 전략에 따라 해석기를 선택하고, 서버 객체는 특정 도메인을 지정한 해석 서비스로 보낼 수 있습니다. 해석 서버 자체가 도메인으로 지정되어 있으면 코어가 먼저 해당 서버 주소를 해석해야 하므로 추가 의존성이 생깁니다. 기본 해석용 서버는 접근 가능한 주소를 명확히 작성하고, 연결이 직접 연결로 가야 하는지 프록시로 가야 하는지 확인하세요.

{
  "dns": {
    "queryStrategy": "UseIP",
    "disableCache": false,
    "disableFallback": false,
    "servers": [
      {
        "address": "1.1.1.1",
        "domains": [
          "domain:example.com"
        ],
        "skipFallback": true
      },
      {
        "address": "8.8.8.8",
        "domains": [
          "geosite:geolocation-!cn"
        ]
      },
      "localhost"
    ],
    "hosts": {
      "router.example.internal": "192.168.1.1"
    }
  }
}

hosts, 캐시와 조회 전략

hosts는 정적 도메인 매핑을 제공하며 고정된 로컬 네트워크 서비스나 테스트 환경에 적합합니다. 일반적으로 외부 조회보다 우선하므로 오래된 매핑이 실제 해석 결과를 계속 덮어쓸 수 있습니다. 서버 주소를 바꿨는데도 이전 IP로 연결된다면 먼저 hosts를 확인한 다음 DNS 캐시를 점검하세요. 정적 매핑은 실제로 안정적인 대상만 넣고 네트워크 변경 후 함께 갱신해야 합니다.

disableCache는 코어의 DNS 캐시 사용 여부를 제어합니다. 캐시를 유지하면 반복 조회와 연결 대기 시간을 줄일 수 있고, 해석 변경을 점검할 때는 일시적으로 끌 수 있지만 장기간 비활성화하면 조회량이 늘어납니다. queryStrategy는 우선 요청할 주소 체계를 결정합니다. IP 사용, IPv4만 사용 또는 IPv6만 사용하는 방식이 흔하지만 정확한 이름과 지원 범위는 현재 코어를 기준으로 확인해야 합니다. 로컬 네트워크에 안정적인 IPv6 경로가 없는데 IPv6 주소를 받아 우선 연결하면 도메인은 해석되지만 연결은 시간 초과되는 현상이 생길 수 있습니다.

도메인별 해석기 지정

서버 객체의 domains는 해당 해석기가 담당할 도메인을 제한합니다. 매칭 문법은 라우팅 도메인 규칙과 비슷하며 완전한 도메인, 접미사 또는 분류 데이터를 사용할 수 있습니다. skipFallback은 해당 서버에 매칭된 도메인을 일반 대체 절차로 넘기지 않는다는 뜻으로, 특정 해석기를 반드시 사용해야 하는 내부 도메인에 적합합니다. 범위를 지나치게 넓히면 해당 서버에서 실패한 뒤 다른 해석 경로를 잃을 수 있습니다.

disableFallback은 전체 대체 동작을 바꾸므로 서버 매칭 순서를 이해하지 못한 상태에서 바로 켜서는 안 됩니다. 더 안전한 방법은 대체를 유지하고 로그로 특정 도메인이 어느 서버를 선택했는지 확인한 뒤, 확실한 소수의 대상에만 skipFallback을 추가하는 것입니다. DNS 분할과 라우팅 분할은 일관되어야 합니다. 어떤 도메인의 해석 요청은 프록시로 보내면서 해석된 대상 연결은 직접 연결로 보내면 출구 관점이 어긋날 수 있습니다. 반대의 경우도 마찬가지로 해석과 연결 경로가 분리되면 원인 파악이 어려워집니다.

프록시 서버 도메인의 시작 의존성

프록시 아웃바운드의 address에 도메인을 입력하면 코어는 프록시 연결을 수립하기 전에 해당 도메인을 해석해야 합니다. 이때는 사용할 수 있는 프록시 터널이 아직 없으므로 프록시에 의존하는 해석기를 사용하면 시작 단계에서 순환 의존성이 생길 수 있습니다. 해결 방법은 무작정 노드를 바꾸는 것이 아니라 프록시가 수립되기 전에 작동하는 기본 DNS 경로를 하나 이상 확보하고, 프록시 서버 도메인의 해석이 그 경로를 사용하도록 하는 것입니다. 복잡한 DNS 아웃바운드를 구성할 때 특히 주의하세요.

DNS가 근본 원인인지 판단하려면 네 단계로 범위를 좁힐 수 있습니다. 먼저 고정 IP 대상을 사용해 아웃바운드 경로를 확인하고, 다음으로 노드 서버 도메인이 해석되는지 확인합니다. 이어서 대상 도메인의 A 및 AAAA 결과를 확인하고, 마지막으로 해석 결과에 따라 라우팅이 아웃바운드를 바꾸는지 관찰합니다. 고정 IP도 실패한다면 문제는 대개 DNS에만 있지 않습니다. 노드는 연결되지만 일부 도메인만 실패한다면 도메인 매칭, 캐시와 주소 체계 선택을 계속 점검하세요.

현상 우선 확인할 항목 흔한 경계 사례
모든 도메인 실패 기본 해석기 접근성, 노드 도메인 해석 프록시 수립 전 발생하는 해석 순환
일부 도메인 실패 서버 객체 domains, hosts, 대체 경로 규칙 범위가 너무 넓거나 정적 매핑이 오래됨
해석은 성공하지만 연결 시간 초과 주소 체계, 라우팅 매칭, 대상 아웃바운드 IPv6 경로 또는 출구 선택 불일치
06 / POLICY

policy 정책: 연결 수명과 통계 스위치

시스템 정책과 사용자 레벨

policy는 연결 시간 초과, 핸드셰이크 시간, 업로드·다운로드 유휴 판단과 통계 스위치를 제어합니다. 어느 노드로 트래픽을 보낼지는 결정하지 않으며 라우팅 규칙을 대신하지도 않습니다. 설정은 보통 levels와 system으로 나뉩니다. levels는 사용자 레벨별 연결 정책을 적용하고, 프로토콜 사용자 객체의 level이 이 키와 연결됩니다. system은 전역 통계 차원을 제어합니다. 사용자가 레벨을 명시하지 않으면 보통 기본 레벨 정책이 적용됩니다.

레벨 키는 JSON에서 "0"처럼 문자열로 나타납니다. 프로토콜마다 사용자 레벨을 참조하는 방식이 다를 수 있으며, 클라이언트가 설정을 자동 생성할 때 사용하지 않는 정책을 생략하기도 합니다. 레벨을 수동으로 추가하기 전에 해당 인바운드 또는 사용자 객체가 실제로 이를 참조하는지 확인하세요. "1" 정책만 만들어 두고 어떤 사용자도 level: 1을 설정하지 않았다면 모든 연결의 레벨이 자동으로 올라가지는 않습니다.

{
  "policy": {
    "levels": {
      "0": {
        "handshake": 4,
        "connIdle": 300,
        "uplinkOnly": 2,
        "downlinkOnly": 5,
        "statsUserUplink": false,
        "statsUserDownlink": false,
        "bufferSize": 0
      }
    },
    "system": {
      "statsInboundUplink": true,
      "statsInboundDownlink": true,
      "statsOutboundUplink": true,
      "statsOutboundDownlink": true
    }
  },
  "stats": {}
}

handshake와 connIdle

handshake는 연결 수립 단계에서 기다릴 수 있는 시간을 제한하며 단위는 보통 초입니다. 값이 너무 작으면 지연이 큰 네트워크, 최초 DNS 조회 또는 복잡한 핸드셰이크가 완료되기 전에 종료될 수 있습니다. 반대로 너무 크면 명백히 실패한 연결이 더 오래 자원을 점유합니다. 조정할 때는 먼저 “연결 수립이 느린지”와 “수립 후 전송이 느린지”를 구분하세요. 전자만 핸드셰이크 대기 시간과 직접 관련됩니다. 로그에 아웃바운드가 이미 수립됐다고 표시된다면 핸드셰이크 시간을 계속 늘려도 도움이 되지 않습니다.

connIdle은 데이터 활동이 없을 때 연결을 얼마나 유지할지 제어합니다. 메신저, 롱 폴링, 원격 터미널과 백그라운드 동기화는 오랫동안 뚜렷한 트래픽이 없을 수 있으므로 유휴 시간이 너무 짧으면 주기적으로 연결이 끊깁니다. 일반 웹 연결은 더 짧은 유휴 회수도 대체로 감당할 수 있습니다. 값을 바꾸기 전에 문제가 일정한 유휴 시간 뒤에 반복되는지 관찰하세요. 지속적으로 전송 중인데도 연결이 끊긴다면 정책만 조정하지 말고 네트워크 경로, 서버 제한과 전송 계층을 계속 확인해야 합니다.

uplinkOnly, downlinkOnly와 버퍼

uplinkOnly와 downlinkOnly는 반쪽 닫힘 상태의 연결 회수에 사용됩니다. 한쪽 데이터 방향이 끝난 뒤에도 코어가 다른 방향의 남은 전송이 완료되기를 기다릴 수 있습니다. 대기 시간이 너무 짧으면 응답의 끝부분이 잘릴 수 있고, 너무 길면 종료된 연결이 더 오래 남습니다. 이런 매개변수는 보통 합리적인 기본값을 유지하면 되며, 로그와 캡처 결과가 반쪽 닫힘 단계의 문제를 명확히 가리킬 때만 조정하세요.

bufferSize는 연결별 버퍼 전략에 영향을 주며 의미와 단위는 코어 구현에 따라 달라질 수 있습니다. 버퍼가 크다고 속도가 반드시 빨라지는 것은 아니고, 동시 연결이 많으면 메모리 사용량이 늘어납니다. 성능을 조정하기 전에 병목이 CPU, 네트워크, 프로토콜 핸드셰이크 또는 애플리케이션 읽기 속도 중 어디에 있는지 확인하세요. 측정 근거가 없다면 클라이언트나 코어의 기본 설정을 유지하는 편이 안정적입니다.

통계 데이터 활성화 방법

system 아래의 통계 스위치는 인바운드와 아웃바운드의 업로드·다운로드 데이터를 기록할지 결정하며, 보통 최상위에 stats 객체도 있어야 합니다. 사용자별 통계를 사용하려면 해당 레벨에서 statsUserUplink와 statsUserDownlink도 활성화해야 합니다. stats: {}만 작성한다고 모든 통계 차원이 자동으로 생성되지는 않습니다. 정책 스위치만 켜고 통계 데이터를 읽는 인터페이스가 없다면 클라이언트 화면에 차트가 저절로 나타나지도 않습니다.

통계를 사용하면 일정한 상태 관리 비용이 발생하므로 실제 관측 필요성에 따라 활성화해야 합니다. 트래픽 분할을 점검할 때 아웃바운드 통계는 트래픽이 프록시, 직접 연결 또는 차단 출구 중 어디로 들어갔는지 판단하는 데 도움이 됩니다. 특정 사용자를 점검할 때는 사용자별 통계가 의미 있습니다. 개인 데스크톱 설정이라면 보통 아웃바운드 차원만 필요하며 모든 사용자 통계를 동시에 켤 필요는 없습니다. 그래픽 클라이언트가 이미 트래픽 표시를 제공한다면 해당 클라이언트가 생성한 설정과 읽기 방식을 기준으로 삼아 여러 통계 경로를 중복 설정하지 마세요.

정책을 조정한 뒤에는 세 가지 연결을 모두 검증해야 합니다. 빠른 단기 연결, 지속적으로 전송하는 연결, 오랫동안 유휴 상태였다가 복구되는 연결입니다. 웹 페이지 하나만 열어서는 유휴 회수가 적절한지 또는 반쪽 닫힘 대기가 작동하는지 판단할 수 없습니다. 클라이언트가 노드를 저장할 때마다 설정을 다시 생성한다면 수동 정책이 덮어써질 수 있으므로, 사용 가능한 옵션을 클라이언트의 사용자 지정 설정 기능에 넣거나 구독을 갱신할 때마다 생성 결과를 다시 확인해야 합니다.

07 / OBSERVE

로그, 통계와 실행 상태

로그 레벨과 파일 출력

log는 설정 문제 해결의 첫 번째 관문입니다. 일반적인 레벨은 자세한 순서부터 debug, info, warning, error와 none이며 정확한 이름은 현재 코어 지원 범위를 따릅니다. 일상적인 실행에는 warning이 주요 이상을 남기면서 반복 정보를 줄여 주는 경우가 많습니다. 규칙이나 핸드셰이크 문제를 찾을 때는 일시적으로 info 또는 debug로 높이세요. 재현이 끝나면 평소 레벨로 되돌려 로그가 디스크를 과도하게 사용하거나 이후 검색을 방해하지 않도록 합니다.

access와 error로 접근 로그와 오류 로그의 경로를 지정할 수 있습니다. 상대 경로를 사용하면 기준 디렉터리는 코어가 시작된 위치에 따라 달라지며 그래픽 클라이언트, 터미널과 시스템 서비스가 서로 다를 수 있습니다. 설정상 파일에 기록된다고 나오는데 실제 파일을 찾을 수 없다면 먼저 프로세스 작업 디렉터리와 파일 권한을 확인하세요. 경로의 디렉터리는 미리 존재해야 하고 현재 사용자가 쓸 수 있어야 합니다. 설치 패키지 내부나 임시 압축 해제 디렉터리를 로그 경로로 지정하지 마세요.

{
  "log": {
    "access": "./logs/access.log",
    "error": "./logs/error.log",
    "loglevel": "warning",
    "dnsLog": false
  },
  "stats": {}
}

연결 기록 한 건 읽는 방법

로그를 읽을 때는 시간 순서에 따라 같은 연결의 여러 단계를 이어서 봐야 합니다. 인바운드 연결 수락, 대상 식별, 라우팅 매칭, 아웃바운드 선택, 서버 주소 해석, 전송 수립, 프로토콜 핸드셰이크와 종료 원인의 순서입니다. “connection closed”라는 문구 하나만으로 노드 장애인지, 대상이 먼저 종료했는지, 라우팅 차단인지 판단할 수 없습니다. 같은 시간대의 대상 주소, 인바운드 태그와 아웃바운드 태그를 함께 확인해 어느 계층에서 종료됐는지 파악해야 합니다.

로그에 인바운드 기록만 있고 아웃바운드 선택이 없다면 먼저 라우팅 규칙과 설정 로드를 확인하세요. 아웃바운드는 선택됐지만 서버 주소 해석에 실패했다면 DNS를 점검합니다. 원격 TCP가 수립됐지만 프로토콜 핸드셰이크가 실패했다면 사용자, 전송과 보안 매개변수를 확인하세요. 핸드셰이크 성공 후 특정 대상만 실패한다면 대상 라우팅, 주소 체계와 애플리케이션 동작을 계속 살펴봐야 합니다. 단계별로 원인을 좁히면 여러 모듈을 오가며 반복해서 시행착오를 겪는 일을 줄일 수 있습니다.

접근 로그와 오류 로그의 역할

접근 로그는 “어떤 대상이 어느 입구를 통해 처리됐는가”를 확인하는 데 적합하고, 오류 로그는 “처리가 왜 중단됐는가”를 확인하는 데 적합합니다. 라우팅을 검증할 때는 식별하기 쉬운 테스트 도메인을 하나 정하고 오래된 로그를 지운 뒤 요청을 한 번만 보낸 다음 새 기록을 확인하세요. 여러 웹 페이지를 동시에 열면 백그라운드 요청, 업데이트 확인과 미디어 연결이 발생해 대상이 섞이므로 특정 규칙이 정확히 매칭됐는지 판단하기 어려워집니다.

로그의 도메인과 IP는 서로 다른 단계에서 나온 것일 수 있습니다. 스니핑으로 식별된 도메인은 규칙 매칭에 사용되고, DNS가 반환한 IP는 연결 수립에 사용됩니다. 최종 접근 로그에 어느 정보가 표시되는지는 코어와 로그 위치에 따라 달라집니다. IP가 보인다고 도메인 규칙이 실행되지 않았다는 뜻은 아니며, 도메인이 보인다고 연결에 해석 과정이 없었다는 뜻도 아닙니다. domainStrategy, 스니핑 설정과 라우팅 로그를 함께 확인해야 합니다.

통계, API와 클라이언트 화면

통계 모듈은 카운터를 기록하고 API 또는 클라이언트 화면은 이를 읽어 표시합니다. 코어 API를 사용할 때는 보통 전용 인바운드, 서비스 태그와 API 트래픽을 해당 아웃바운드로 보내는 라우팅 규칙도 필요합니다. 이 구조는 코어별 차이와 클라이언트 관리 경계가 크므로 수동으로 추가하기 전에 클라이언트가 같은 이름의 태그를 이미 만들었는지 확인하세요. API 인바운드 포트가 중복되면 시작에 실패하고, 라우팅 태그가 중복되면 상태 조회가 일반 프록시 출구로 들어갈 수 있습니다.

v2rayN 등의 그래픽 클라이언트는 보통 실행 로그, 코어 로그와 연결 상태 화면을 제공합니다. 문제를 해결할 때는 클라이언트가 표시하는 실제 시작 설정과 오류 정보를 우선 사용하세요. 화면 설정은 시작 전에 필드를 변환할 수 있기 때문입니다. 별도의 JSON 파일을 수동 편집했지만 클라이언트는 다른 임시 설정을 실제로 로드하는 경우가 흔합니다. 설정 출처를 확인하려면 시작 로그의 설정 경로, 수신 포트와 아웃바운드 태그를 보고 현재 편집 중인 파일과 항목별로 대조하세요.

로그의 개인정보와 보존

접근 로그에는 도메인, 대상 주소, 로컬 계정 식별자와 연결 시간이 포함될 수 있습니다. 상세 레벨을 활성화하기 전에 로그 저장 위치와 사용 범위를 확인하세요. 문제 해결이 끝나면 레벨을 낮추고 더 이상 필요하지 않은 디버그 파일을 정리합니다. 오류 일부를 공유할 때는 장애와 직접 관련된 단계만 남기고 노드 주소, 사용자 식별자, 경로와 계정 필드를 바꾸세요. 서버 주소 한 줄만 삭제하는 것으로는 충분하지 않습니다. 주변 핸드셰이크 정보에도 설정 세부 정보가 드러날 수 있습니다.

로그 분석의 목표는 내용을 많이 모으는 것이 아니라 재현 가능한 인과 관계를 세우는 것입니다. 한 번에 하나의 문제만 재현하고 변경 전후의 차이, 명확한 시점과 테스트 대상을 기록하세요. 노드 교체, DNS 변경, 라우팅 조정과 시스템 프록시 전환을 동시에 하면 문제가 사라져도 어느 변경이 효과가 있었는지 알 수 없습니다. 안정적인 문제 해결 기록에는 현재 클라이언트, 사용한 코어 계열, 인바운드 방식, 매칭된 아웃바운드와 최종 오류 단계가 포함되어야 합니다.

08 / VALIDATE

설정 검증, 마이그레이션과 문제 해결

세 단계 검사를 먼저 통과하기

설정 검증은 세 단계로 나눠야 합니다. 첫 번째는 JSON 문법으로 괄호, 쉼표, 따옴표와 필드 유형이 올바른지 확인합니다. 두 번째는 설정 의미로 현재 코어가 프로토콜 필드를 인식하는지, 태그 참조가 존재하는지, 포트가 충돌하지 않는지 확인합니다. 세 번째는 실행 흐름으로 인바운드가 트래픽을 받는지, 라우팅이 매칭되는지, 아웃바운드가 수립되는지, 대상이 응답하는지 확인합니다. 세 단계는 서로를 대신할 수 없습니다. JSON을 읽을 수 있다는 것은 텍스트 구조가 성립한다는 뜻일 뿐 노드 매개변수와 라우팅 결과가 올바르다는 의미는 아닙니다.

일부 코어는 서비스를 장기간 실행하지 않고도 설정을 읽고 오류를 반환하는 테스트 모드를 제공합니다. 명령 형식은 코어와 패키징 방식에 따라 달라지므로 클라이언트에 포함된 코어의 도움말을 기준으로 해야 합니다. 데스크톱 클라이언트에서는 화면의 검사, 코어 재시작 또는 시작 로그 확인 기능을 먼저 사용하는 편이 안전합니다. 테스트할 때는 명령이 클라이언트가 실제로 사용하는 코어 파일을 호출하는지 확인하세요. 시스템 경로에 있는 다른 코어는 지원 필드가 다를 수 있습니다.

v2ray run -test -config ./config.json
xray run -test -config ./config.json

명령에서 매개변수 형식을 지원하지 않는다고 나오면 먼저 해당 프로그램의 도움말 명령으로 로컬 문법을 확인하세요. 이를 근거로 설정 내용이 틀렸다고 판단해서는 안 됩니다. 검증에 성공한 뒤 코어를 시작하고 로그에 예상한 수신 포트가 나타나는지 확인합니다. 포트가 나타나지 않으면 실행 설정, 권한 또는 포트 점유 문제가 남아 있는 것입니다. 포트는 나타나지만 애플리케이션 트래픽이 들어오지 않으면 시스템 프록시 또는 애플리케이션 프록시 설정으로 돌아가야 합니다.

모듈별 이분 탐색으로 문제 해결

복잡한 설정에서는 모든 필드를 한 글자씩 읽는 것보다 최소 실행 경로로 줄이는 방법이 가장 빠릅니다. 로컬 SOCKS 인바운드 하나, 매개변수가 완전한 검증된 프록시 아웃바운드 하나, 직접 연결 아웃바운드 하나와 빈 라우팅 규칙만 남기세요. 먼저 프록시 출구가 연결되는지 확인한 뒤 사설 주소 직접 연결, 도메인 분류, DNS 분할과 차단 규칙을 차례로 추가합니다. 계층을 하나 추가할 때마다 되돌릴 수 있는 설정 사본을 남기세요. 어느 단계에서 문제가 생기면 원인은 방금 추가한 모듈로 제한됩니다.

노드가 연결 성공으로 표시되지만 웹 페이지가 열리지 않는다면 “애플리케이션 인계, 인바운드 수신, 노드 연결, DNS, 라우팅, 시스템 프록시” 순서로 확인하세요. 클라이언트 상태는 특정 프로세스가 시작됐거나 한 번의 테스트가 끝났다는 뜻일 뿐 현재 브라우저 트래픽이 실제로 해당 인바운드로 들어갔다는 의미는 아닙니다. 가장 직접적인 판단 방법은 접근 로그에 테스트 대상이 나타나는지 확인하는 것입니다. 기록이 없으면 먼저 트래픽 입구를 처리하고, 기록이 있으면 아웃바운드를 분석하세요.

구독 갱신 후 설정 변화

구독을 갱신하면 노드 목록과 일부 노드 매개변수가 새로 반영되고, 클라이언트가 현재 라우팅 모드에 따라 실행 설정을 다시 생성할 수도 있습니다. 임시 파일을 수동으로 수정해도 오래 유지되지 않는 경우가 많습니다. 지속적으로 사용해야 하는 라우팅 규칙은 클라이언트가 제공하는 사용자 지정 규칙, 사전 설정 또는 지원되는 템플릿 위치에 작성하세요. 갱신 후에는 노드 프로토콜, 전송 방식, 서버 이름, 아웃바운드 태그와 규칙 순서를 중점적으로 확인하고, 특히 서로 다른 코어에서 노드를 가져올 때 주의하세요.

단일 vmess:// 또는 vless:// 공유 링크는 보통 하나의 노드를 의미하고, 구독 주소는 갱신 가능한 노드 목록을 반환합니다. 두 방식은 클라이언트에서 가져오는 위치와 갱신 동작이 다릅니다. 자세한 차이는 공유 링크와 구독 주소 사용 안내에서 확인할 수 있습니다. 갱신 후 노드가 없거나 오류가 반환되면 구독 갱신 실패 문제 해결과 자동 갱신 설정도 참고하세요.

코어 간 마이그레이션 점검표

V2Fly 설정을 Xray로 옮기거나 반대로 이전할 때는 먼저 양쪽이 모두 지원하는 기본 구조를 유지하세요. SOCKS 인바운드, 일반 직접 연결 출구와 단순한 도메인·IP 라우팅이 이에 해당합니다. 그런 다음 프로토콜별로 사용자 필드, 전송 계층, 보안 계층과 흐름 제어 설정을 하나씩 확인합니다. 알 수 없는 필드가 발견됐다고 보안 설정 전체를 바로 삭제하고 연결을 시도해서는 안 됩니다. 해당 필드가 노드 작동에 필요한 요소일 수 있기 때문입니다. 올바른 방법은 대상 코어가 동일한 프로토콜 기능을 표현할 수 있는지 확인하고, 불가능하다면 해당 노드에 맞는 클라이언트와 코어를 선택하는 것입니다.

REALITY 노드는 일반적으로 해당 기능을 지원하는 Xray 코어 계열을 사용해야 하며, Android에서는 v2rayNG를 우선 고려할 수 있습니다. V2Fly 설정과 노드를 사용할 때는 필요에 따라 v2flyNG를 선택하세요. 데스크톱에서는 v2rayN을 우선 사용하고 코어 설정에서 실제 활성화된 코어를 확인하세요. 생태계와 코어의 관계는 Project V, V2Fly, Xray와 클라이언트 관계 정리 및 Xray와 V2Fly 코어 선택 참고서에서 더 자세히 확인할 수 있습니다.

문제 발생 단계 대표적인 증상 확인 대상
설정 로드 코어 즉시 종료, 알 수 없는 필드, JSON 오류 문법, 필드 지원 여부, 태그 참조
인바운드 인계 코어는 실행 중이지만 접근 로그에 요청이 없음 로컬 포트, 시스템 프록시, 애플리케이션 설정
아웃바운드 수립 연결 시간 초과 또는 핸드셰이크 실패 노드 주소, 프로토콜, 전송, 보안 계층
해석과 라우팅 일부 도메인 실패, 예상과 다른 출구 DNS, 스니핑, 규칙 순서, 주소 체계
대상 접속 프록시는 수립됐지만 특정 서비스가 중단됨 대상 포트, 네트워크 유형, 애플리케이션 동작

유지 관리 가능한 설정 기준 만들기

장기간 유지 관리할 수 있는 설정에는 명확한 태그, 제한적인 규칙 계층, 설명 가능한 DNS 경로와 적절한 로그가 포함되어야 합니다. 변경할 때는 필드 값만 기록하지 말고 목적을 기록하세요. 예를 들어 “로컬 네트워크 대역을 직접 연결”이라고 적는 편이 “geoip 항목 추가”보다 나중에 필요성을 판단하기 쉽습니다. 규칙은 차단, 특정 직접 연결, 특정 프록시와 대체 경로의 논리적 그룹으로 나누고, 각 그룹 안에서는 구체적인 항목부터 포괄적인 항목 순으로 배치하세요.

수정을 마친 뒤 최소한 로컬 주소, 일반 도메인, 직접 IP, TCP 요청과 UDP가 필요한 애플리케이션 환경을 확인하세요. 그런 다음 클라이언트를 한 번 재시작해 설정이 현재 프로세스에서만 임시로 적용된 것이 아닌지 확인합니다. 구독을 사용한다면 한 번 갱신하고 사용자 지정 규칙이 유지되는지도 점검하세요. 빠른 사용 흐름은 v2rayN 및 v2rayNG 설정 튜토리얼로 돌아가고, 설치 패키지를 다시 선택해야 한다면 V2Ray 클라이언트 다운로드 페이지로 이동하세요.