V2Ray JSON 설정 파일 가이드

01 / JSON 구조와 연결 경로

설정 파일은 코어의 동작을 정의합니다

그래픽 클라이언트는 서버 관리, 구독 업데이트, 시스템 프록시 설정, 코어 실행을 담당합니다. 코어 설정은 연결 수신, 라우팅 실행, 도메인 조회, 아웃바운드 연결을 담당합니다. 서로 관련은 있지만 같은 데이터는 아닙니다. 클라이언트 메인 창에 저장된 서버 정보는 보통 변환을 거쳐야 코어가 읽을 수 있는 설정이 됩니다. 화면에서 이름을 바꿔도 코어 설정의 모든 태그가 함께 바뀌는 것은 아닙니다.

연결 경로를 네 단계로 나눠 살펴보세요. 애플리케이션이 인바운드에 연결하고, 인바운드가 대상 주소를 받은 다음, 라우팅이 아웃바운드를 선택하고, 아웃바운드가 다음 연결을 설정합니다. DNS는 라우팅 조건을 확인하거나 연결을 설정할 때 관여할 수 있습니다. 로그에는 각 단계의 일부 이벤트가 기록되고, 정책은 연결 시간 제한과 통계 동작에 영향을 줍니다. 문제를 진단할 때는 이 경로를 따라가세요. 브라우저 오류만 보고 모든 DNS 설정을 바꾸는 식으로 건너뛰지 마세요.

객체, 배열, 필드 유형

JSON 객체는 중괄호, 배열은 대괄호를 사용합니다. 키 이름과 문자열은 영문 큰따옴표로 감싸야 하며, 포트는 보통 숫자, 스위치는 따옴표 없는 불리언 값으로 씁니다. 끝에 붙은 쉼표, 전각 따옴표, 닫히지 않은 괄호가 있으면 엄격한 JSON 파싱에 실패합니다. 일부 코어 또는 로딩 방식은 주석 같은 확장 문법을 허용하지만, 이 페이지의 예제는 여러 도구에서 확인하기 쉽도록 엄격한 JSON 문법을 따릅니다.

최상위에는 보통 객체 하나가 옵니다. inbounds와 outbounds는 여러 수신 지점과 출구를 선언할 수 있어 배열입니다. routing, dns, policy는 각각 규칙이나 하위 설정을 담는 객체입니다. 같은 이름의 최상위 키를 반복해서 쓴다고 항목이 추가되는 것은 아닙니다. 파서에 따라 앞의 값이 덮어써지거나 로딩이 거부될 수 있으므로 필드마다 하나로 합쳐야 합니다.

완성된 직결 설정으로 기준 만들기

아래는 로컬 수신을 점검하기 위한 완성된 설정입니다. 루프백 주소에서 SOCKS 인바운드만 제공하며, 모든 연결은 직결 아웃바운드로 전송합니다. 원격 프록시 서버는 포함되어 있지 않습니다. 포트는 예시이므로 실행 전에 다른 프로그램이 사용 중인지 확인하세요. 이 설정은 애플리케이션이 로컬 코어에 연결되는지 확인하는 데 적합하지만, 원격 노드의 작동 여부를 입증하지는 않으며 시스템 프록시도 자동으로 변경하지 않습니다.

{
  "log": {
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "tag": "socks-in",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "auth": "noauth",
        "udp": true
      }
    }
  ],
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    }
  ]
}

예제를 읽을 때는 먼저 수신 주소와 포트, 다음으로 인바운드 프로토콜, 마지막으로 기본 아웃바운드를 확인하세요. 라우팅 규칙이 없으면 일반적으로 아웃바운드 배열의 첫 번째 항목이 사용됩니다. 따라서 배열 순서는 단순한 정렬 문제가 아닙니다. 클라이언트가 설정을 다시 생성했다면 기본 출구도 다시 확인해야 합니다. 특정 프록시 프로토콜 객체가 남아 있는지만 확인해서는 안 됩니다.

설정의 tag는 다른 필드에서 참조하는 식별자이지 연결 인증 정보가 아닙니다. 짧고 고유하며 의미가 쉽게 바뀌지 않는 이름을 사용하는 것이 좋습니다. 파일명만으로 역할이 결정되는 것도 아닙니다. config.json이라는 파일도 현재 코어 프로세스가 실제로 불러와야 적용됩니다. 다음 장을 살펴볼 때는 실행 가능한 기준 설정을 하나 보관하고, 매번 관련된 일부 항목만 수정하세요.

02 / inbounds: 수신 주소와 인바운드 프로토콜

먼저 누가 이 수신 지점에 연결하는지 확인하세요

인바운드는 코어가 어떤 주소와 포트에서 어떤 종류의 연결을 받을지 정의합니다. 데스크톱 애플리케이션에서 흔히 사용하는 수신 방식은 SOCKS와 HTTP이며, 포트 번호만으로 서로 바꿔 쓸 수는 없습니다. 애플리케이션은 HTTP 프록시를 선택했는데 SOCKS 핸드셰이크만 받는 포트에 연결하면, 포트가 열려 있어도 바로 프로토콜 오류가 발생할 수 있습니다. 문제를 확인할 때는 주소, 포트, 프록시 유형을 모두 대조해야 합니다.

listen은 수신 범위를 정합니다. 127.0.0.1에 바인딩하면 주로 이 컴퓨터에서만 사용할 수 있습니다. 모든 인터페이스에 바인딩하면 접근 범위가 넓어지며, 시스템 방화벽과 네트워크 환경의 영향도 받습니다. 원격 프록시 프로토콜이 암호화되어 있어도 로컬 SOCKS 수신 지점이 LAN에 공개된 상태까지 자동으로 보호되지는 않습니다. 공유가 꼭 필요하고 접근 제어도 설정한 경우가 아니라면 루프백 수신을 유지하는 편이 경계를 관리하기 쉽습니다.

SOCKS와 HTTP를 별도로 선언

아래 조각은 두 개의 수신 지점을 나란히 선언합니다. SOCKS에는 예시 포트 10808, HTTP에는 예시 포트 10809를 사용합니다. 포트 번호는 소프트웨어를 구분하는 고유 식별자가 아니므로 변경했다면 애플리케이션 설정도 함께 바꿔야 합니다. 같은 주소에서 두 수신 항목이 하나의 TCP 포트를 동시에 사용할 수는 없습니다. 다른 클라이언트가 백그라운드에서 실행 중이라면 먼저 포트를 점유한 프로세스를 확인한 뒤 종료할지 새 포트를 선택할지 결정하세요.

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

settings.auth가 noauth이면 SOCKS 수신 지점에서 사용자 이름과 비밀번호를 요구하지 않습니다. 이 설정은 제어된 로컬 수신 환경에 적합하며, 임의의 네트워크에 공유해도 된다는 뜻은 아닙니다. 인증이 필요하다면 현재 코어의 SOCKS 인바운드 정의에 맞춰 계정을 설정하고, 호출하는 쪽도 같은 인증 방식을 지원하는지 확인하세요. HTTP 인바운드는 별도의 설정 구조를 사용하므로 SOCKS 인증 필드를 그대로 가져다 쓸 수 없습니다.

udp를 사용하면 SOCKS 인바운드가 해당 UDP 요청을 처리할 수 있지만, 모든 애플리케이션에 UDP 프록시를 제공한다는 뜻은 아닙니다. 애플리케이션이 SOCKS UDP 전송을 실제로 지원해야 하며 아웃바운드 프로토콜과 원격 서비스에도 필요한 기능이 있어야 합니다. 운영체제의 HTTP 프록시만 설정해도 임의의 UDP 프로그램이 자동으로 해당 SOCKS 수신 지점을 이용하지는 않습니다. 트래픽이 들어오는 경로가 서로 다르기 때문입니다.

트래픽 스니핑 정보와 원래 대상

sniffing은 지원되는 프로토콜의 핸드셰이크에서 도메인 등의 정보를 가져오려고 시도합니다. 애플리케이션이 대상 IP만 전달하더라도 스니핑으로 라우팅에 필요한 도메인 정보를 보완할 수 있습니다. 예제의 destOverride는 대상을 덮어쓸 때 사용할 프로토콜 유형을 지정하지만, 실제로 정보를 추출할 수 있는지는 트래픽에 따라 달라집니다. 모든 애플리케이션의 콘텐츠를 복호화하거나 모든 연결에서 원래 방문한 도메인을 복원하는 기능은 아닙니다.

스니핑을 활성화하면 라우팅이나 아웃바운드 처리에 사용되는 연결 대상 정보가 달라질 수 있습니다. 일부 코어에는 라우팅에만 적용되는 관련 옵션도 있으므로 지원 필드와 세부 동작을 따로 확인해야 합니다. 활성화한 뒤 특정 애플리케이션에 문제가 생기면 먼저 스니핑을 켜기 전후의 로그와 대상을 비교하고, 이어서 아웃바운드가 도메인 대상을 받는지 확인하세요. 문제를 인바운드 포트 탓으로 돌려서는 안 됩니다.

인바운드 태그는 라우팅의 inboundTag에서 참조해 로컬 애플리케이션별로 출구를 나눌 수도 있습니다. 이때 태그는 고유하게 유지하고 애플리케이션에 수신 지점을 명확히 지정하세요. 흔한 실수는 인바운드 이름을 바꾼 뒤 라우팅 규칙의 참조를 업데이트하지 않는 것입니다. 그러면 연결이 이후 규칙이나 기본 아웃바운드로 넘어가 설정이 저장되지 않은 것처럼 보일 수 있습니다.

수정한 뒤 현재 코어를 재시작하거나 다시 불러와 수신이 정상적으로 시작되는지 확인하세요. 시스템 프록시 스위치는 클라이언트 또는 운영체제 계층의 설정이므로 인바운드 객체를 추가해도 자동으로 켜지지 않습니다. 빠른 시작 절차를 참고해 애플리케이션이 실제로 이 수신 지점을 사용하는지 확인한 다음 아웃바운드와 라우팅을 점검하세요. 계층을 넘나들며 설정을 반복해서 바꾸는 일을 줄일 수 있습니다.

03 / outbounds: 출구, 태그, 프로토콜 매개변수

아웃바운드 순서와 라우팅 참조

아웃바운드는 코어가 대상에 어떻게 이어서 연결할지 정의합니다. 직접 연결하거나 차단할 수 있고, 프록시 프로토콜을 통해 원격 서버에 연결할 수도 있습니다. tag는 라우팅 규칙에서 특정 출구를 선택할 때 사용하며, protocol은 settings의 구조를 결정합니다. 이름이 proxy인 아웃바운드라고 해서 반드시 프록시인 것은 아니므로 프로토콜 내용을 확인해야 합니다. 반대로 프록시 아웃바운드에도 다른 고유 태그를 사용할 수 있습니다.

일반적인 설정에서는 어떤 규칙에도 일치하지 않는 연결에 배열의 첫 번째 항목이 사용됩니다. 프록시를 기본 경로로 삼으려면 첫 항목을 명확히 관리하고 필요한 직결 규칙도 유지하세요. 읽기 편하게 보이도록 아웃바운드 배열 순서를 임의로 바꾸면 안 됩니다. 클라이언트 생성기가 현재 서버와 라우팅 모드에 따라 아웃바운드 순서를 다시 정할 수 있으므로, 화면의 목록 순서가 아니라 실제 실행 중인 설정을 기준으로 확인하세요.

직결 및 차단 최소 설정

freedom은 로컬 네트워크에서 직접 연결하고, blackhole은 해당 연결을 차단합니다. 아래 조각은 직결 테스트 설정의 아웃바운드 부분으로 사용할 수 있으며 프록시 출구가 포함된 설정에 합칠 수도 있습니다. 차단 아웃바운드만 선언한다고 대상이 자동으로 차단되지는 않습니다. 라우팅 규칙이 이를 선택하거나 기본 아웃바운드로 지정해야 해당 동작이 적용됩니다.

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

직결이라고 해서 도메인 조회를 건너뛰는 것은 아닙니다. 대상이 도메인이면 연결 가능한 주소로 바꿔 줄 구성 요소가 필요합니다. 내장 DNS와 시스템 조회 중 무엇을 사용하는지, 어떤 주소 계열을 선택하는지는 현재 코어와 아웃바운드 설정에 따라 달라집니다. 라우팅에 ‘직결’이라고 표시되어 있어도 출구 선택만 알 수 있을 뿐, 조회 요청이 어떤 경로를 거쳤는지는 알 수 없습니다.

원격 프로토콜 필드는 서로 섞어 쓸 수 없습니다

프록시 아웃바운드에는 실제 서버 주소와 포트, 인증 매개변수가 필요합니다. VMess, VLESS, Trojan, Shadowsocks는 인증 정보 구조가 서로 다르고 전송 계층과 보안 계층에도 각각 제약이 있습니다. 이 페이지는 허위 계정 정보가 들어간 프록시 설정 완제품을 제공하지 않습니다. 실제로 사용할 때는 신뢰할 수 있는 연결 정보로 아웃바운드를 생성한 뒤 필드가 서버 설정과 일치하는지 확인하세요. 프로토콜 이름만 바꾸고 다른 프로토콜의 사용자 객체를 남겨 두면 안 됩니다.

전송 설정은 보통 streamSettings 같은 해당 구조에 들어갑니다. 전송 유형은 서버에서 실제로 사용하는 방식과 일치해야 하며, 프로토콜 지원 여부는 코어에 따라서도 달라집니다. REALITY 같은 기능이 모든 코어에서 사용할 수 있는 공통 필드라고 간주해서는 안 됩니다. 코어를 선택하기 전에 Xray와 V2Fly 코어의 차이를 살펴보고 클라이언트가 생성한 설정이 적합한지도 확인하세요.

서버 주소, TLS 서비스 이름, 전송 계층의 호스트 필드는 우연히 같을 수 있지만 의미는 서로 다릅니다. 서버 주소는 연결할 대상이고, 서비스 이름은 핸드셰이크와 인증에 관여하며, 일부 전송 헤더는 서버에서 요청을 분배하는 데 사용됩니다. 핸드셰이크 오류가 발생하면 도메인과 관련된 모든 필드를 서버 IP로 일괄 변경하지 말고 출처 정보를 항목별로 대조하세요.

인증서 검증을 건너뛰는 설정을 일반적인 해결책으로 삼지 마세요. 프로토콜 불일치, 원격 포트 오류, 시스템 시간 오차를 해결하지 못하면서 인증 경계만 바꿀 수 있습니다. 인증서 오류가 나면 먼저 시스템 시간, 서비스 이름, 인증서 적용 범위를 확인하세요. 서버가 특수한 방식으로 구성된 경우 보안 옵션을 조정하기 전에 구체적인 설정 안내를 확인해야 합니다.

마지막으로 의존 관계를 확인하세요. 라우팅에서 참조하는 아웃바운드 태그가 실제로 존재해야 하며 대소문자도 일치해야 합니다. 이전 서버의 아웃바운드를 삭제했다면 이를 가리키는 규칙도 정리하세요. 여러 출구가 필요하다면 먼저 명확한 출구 두 개로 검증한 뒤 부하 분산이나 체인 연결 같은 기능을 추가하세요. 기본 경로를 확인하기 전에 중첩 구조를 추가하면 문제 위치를 찾기 더 어려워집니다.

04 / routing: 매칭 조건과 규칙 순서

위에서 아래로 규칙 선택

라우팅은 연결 정보를 바탕으로 출구를 선택합니다. 흔히 사용하는 필드 규칙은 type이 field인 객체에 도메인, IP, 포트, 인바운드 태그 등의 조건을 설정합니다. 일반적으로 배열 순서대로 확인하며 일치하는 규칙을 찾으면 지정된 출구를 사용합니다. 범위가 좁고 우선순위가 높은 예외 규칙은 앞에, 범위가 넓은 규칙은 뒤에 두세요. 그렇지 않으면 뒤쪽 규칙에 도달하지 못할 수 있습니다.

한 규칙 안에서는 서로 다른 조건 필드를 모두 만족해야 하는 경우가 많습니다. 같은 도메인 목록이나 IP 목록에 여러 항목이 있으면 보통 그중 하나와 일치하면 됩니다. ‘특정 도메인 또는 특정 인바운드에서 온 연결’처럼 만들려면 두 필드를 한 객체에 나란히 넣지 말고 규칙을 둘로 나누세요. 규칙을 작성하기 전에 의도가 ‘그리고’인지 ‘또는’인지 자연어로 명확히 한 뒤 설정 구조에 옮기면 좋습니다.

통제 가능한 대상으로 규칙 순서 확인

아래 예제는 예시 도메인을 차단 출구로 보내고 사설 주소를 직결 출구로 보냅니다. 앞 장에서 정의한 direct 및 block 아웃바운드가 필요하며, 현재 코어가 해당 지리 데이터도 읽을 수 있어야 합니다. 예시 도메인은 규칙 검증용이며 실제 운영에 권장하는 목록은 아닙니다. 나머지 연결은 기본 아웃바운드로 전달되므로 규칙 두 개를 추가했다고 전체 연결이 자동으로 프록시를 통과하지는 않습니다.

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

도메인 매칭에서는 정확한 도메인, 하위 도메인을 포함하는 범위, 정규 표현식을 구분해야 합니다. 예를 들어 full:example.com은 지정된 도메인만 일치시키고, domain:example.com은 해당 도메인과 하위 도메인에 사용합니다. 일반 문자열의 매칭 방식은 이 접두사들과 다르므로 예상보다 넓은 범위가 일치할 수 있습니다. 규칙 목록에서는 의도를 분명히 표현하는 형식을 사용하세요.

라우팅 조회 정책과 출구 조회 정책은 다릅니다

AsIs는 보통 IP 규칙을 위해 전달된 도메인을 따로 조회하지 않습니다. 원래 대상이 IP라면 IP 조건과는 여전히 일치할 수 있습니다. IPIfNonMatch는 도메인 단계에서 일치 항목을 찾지 못했을 때 조회를 시도해 IP 규칙을 확인합니다. IPOnDemand는 규칙 검사에 IP 정보가 필요할 때 더 일찍 조회를 시작할 수 있습니다. 이 세 옵션은 라우팅 판단 단계에 적용되며 전체 DNS 트래픽 처리 방식을 정하는 것은 아닙니다.

예를 들어 전달된 대상이 example.com이라는 정확한 도메인이면 첫 번째 규칙과 일치하므로 뒤의 사설 주소 규칙에 의존할 필요가 없습니다. 도메인 규칙과 일치하지 않는 대상은 조회 결과가 IP 규칙 검사에 사용될 수 있습니다. 위쪽에 범위가 넓은 도메인 직결 규칙이 있으면 뒤의 IP 차단 규칙은 실행되지 않을 수 있습니다. 조회 정책만 바꿔서는 규칙 순서 자체의 문제를 해결할 수 없습니다.

규칙 데이터가 없으면 코어가 로딩 단계에서 오류를 보고할 수 있습니다. 데이터가 오래되었거나 분류가 기대와 다르면 시작은 성공해도 분기 결과가 잘못될 수 있습니다. 먼저 두 상황을 구분한 다음 파일 위치 또는 규칙 내용을 확인하세요. 클라이언트의 규칙 데이터 업데이트와 서버 구독 업데이트는 서로 다른 작업입니다. 구독 업데이트가 성공했다고 지리 규칙 데이터까지 업데이트된 것은 아닙니다.

특정 인바운드에 출구를 지정하려면 inboundTag를 사용할 수 있습니다. 대상 포트로 매칭할 때는 현재 코어가 지원하는 포트 표현 방식을 사용하세요. 처음에는 단일 조건으로 확인한 뒤 조합을 추가하는 편이 좋습니다. 로그에서 대상과 실제 출구를 함께 살펴보세요. 대상 주소는 예상과 일치하는데 출구가 다를 때 라우팅 매칭을 중점적으로 확인해야 하며, 곧바로 원격 프로토콜 매개변수를 바꾸면 안 됩니다.

전체, 규칙, 직결 모드는 클라이언트가 생성 설정에 적용하는 사전 설정인 경우가 많으며, 공통 JSON 필드가 따로 있는 것은 아닙니다. 모드를 전환했다면 기본 아웃바운드와 규칙 배열을 다시 확인하세요. 분기 결과가 의심된다면 ‘일부 사이트가 안 열림’이라고만 기록하기보다 특정 대상, 인바운드, 일치 조건, 최종 출구를 적어 두세요. 재현하기 쉽고 이후 설정 변경 결과도 비교하기 좋습니다.

05 / dns: 조회 출처, 주소 계열, 라우팅 의존성

먼저 세 가지 조회 경로를 구분하세요

애플리케이션은 프록시에 연결하기 전에 직접 도메인을 조회할 수도 있고, 도메인을 프록시에 그대로 전달할 수도 있습니다. 코어는 라우팅이나 아웃바운드 연결을 위해 자체 조회기를 사용할 수 있으며, 마지막 조회를 원격 서비스가 맡을 수도 있습니다. 이 경로는 동시에 존재할 수 있습니다. 설정에 dns 객체가 있다고 해서 모든 애플리케이션의 조회를 이 객체가 처리하거나 시스템 DNS가 교체되었다고 볼 수는 없습니다.

예를 들어 애플리케이션이 먼저 IP를 얻은 다음 그 IP를 SOCKS 대상 주소로 전달하면 코어가 받은 최초 대상에는 도메인이 없을 수 있습니다. 이때 도메인 규칙을 사용할 수 있는지는 스니핑 같은 기능이 정보를 보완하는지에 따라 달라집니다. 애플리케이션이 도메인을 프록시에 전달하면 라우팅과 아웃바운드에서 더 많은 대상 정보를 유지할 수 있습니다. 따라서 두 애플리케이션의 연결 결과를 비교하기 전에 로컬 프록시에 도메인을 전달하는지, 이미 조회한 주소를 전달하는지 확인하세요.

기본 내장 DNS 설정 예제

아래 예제는 일반 DNS 서버 두 개를 설정하고 내장 조회에서 IPv4 주소만 조회하는 정책을 우선 사용하도록 합니다. 주소는 구조 설명을 위한 예시일 뿐 모든 네트워크에 가장 적합한 선택은 아니며 운영체제의 DNS 설정을 바꾸지도 않습니다. DNS 서버에 연결할 수 있는지, 네트워크에서 사용할 수 있는지, 개인정보 보호 요구사항에 적합한지는 별도로 평가해야 합니다. 주소를 입력했다고 실제로 연결 가능한 경로가 자동으로 생기지는 않습니다.

{
  "dns": {
    "servers": [
      "1.1.1.1",
      "8.8.8.8"
    ],
    "queryStrategy": "UseIPv4"
  }
}

servers에는 간단한 서버 항목을 사용할 수 있으며, 일부 환경에서는 도메인 범위나 원하는 주소 같은 조건을 포함한 객체도 지원합니다. 객체 필드가 있다고 해서 항상 해당 서버 한 곳만 이용한다는 뜻은 아닙니다. 실제 후보 선택과 대체 동작은 현재 코어의 알고리즘에도 영향을 받습니다. 복잡한 옵션을 한꺼번에 추가하지 말고 먼저 기본 조회가 되는지 확인한 다음 도메인 범위와 대체 동작을 하나씩 제한하세요.

주소 계열은 실제 네트워크에 맞춰야 합니다

queryStrategy는 내장 조회에 사용할 주소 계열 정책을 정합니다. 일부 주소 계열 문제를 분리할 때 IPv4만 조회할 수 있지만 모든 연결 실패를 해결하는 만능 방법은 아닙니다. IPv6를 사용할 수 있는 네트워크라면 관련 조회를 유지해야 할 수도 있습니다. 반대로 시스템에서 IPv6 주소를 얻더라도 원격 서비스까지의 IPv6 경로, 프록시 서버, 아웃바운드 정책이 모두 같은 기능을 지원한다는 뜻은 아닙니다.

도메인에서 최종 선택되는 주소 계열은 애플리케이션의 선행 조회, 아웃바운드의 조회 방식, 원격 처리에도 영향을 받습니다. 최상위 DNS의 조회 정책만 바꿔 모든 연결이 한 주소 계열만 사용하도록 보장할 수는 없습니다. 문제를 진단할 때 조회 결과와 실제 연결 대상 주소를 비교하세요. 서로 다르면 다른 조회기나 원격 서비스가 처리했는지 먼저 확인하고, 서로 충돌하는 DNS 옵션을 계속 추가하지 마세요.

조회와 프록시 사이의 순환 의존 방지

프록시 서버 주소 자체가 도메인이고 조회기가 아직 연결되지 않은 프록시를 통해서만 접근 가능하다면 시작 단계에서 순환 의존이 생길 수 있습니다. 암호화 DNS를 사용하면서 조회 엔드포인트도 도메인인 경우에는 엔드포인트를 처음 조회하는 방법도 고려해야 합니다. 설계할 때 어느 단계에서 초기 조회를 수행하는지, 어떤 경로가 프록시 시작에 의존하지 않는지, 현재 네트워크에서 해당 경로에 실제로 접근할 수 있는지 명확히 하세요.

코어마다 DNS 조회의 라우팅, 태그, 로컬 조회 모드를 다르게 처리할 수 있습니다. 암호화 DNS 주소를 문자열에 복사해 넣었다고 조회가 지정한 프록시 출구를 반드시 통과하는 것은 아닙니다. 원격 조회가 필요하다면 엔드포인트 형식, 지원 방식, 아웃바운드 경로를 함께 확인하세요. 시스템 조회를 사용한다면 운영체제 자체 캐시와 네트워크 설정의 영향도 고려해야 합니다.

DNS 설정을 테스트할 때는 애플리케이션 캐시, 시스템 캐시, 기존 연결 때문에 변화가 가려질 수 있습니다. 테스트 페이지의 기존 연결을 먼저 닫고 플랫폼에서 제공하는 일반적인 방법으로 캐시를 처리한 뒤 같은 도메인으로 다시 확인하세요. 계획 없이 무작위 도메인을 많이 사용하는 방식은 피하세요. 변경 전후의 조회 대상과 로그를 기록하면 ‘조회 결과 변경’과 ‘출구 변경’이라는 서로 다른 결과를 구분할 수 있습니다.

DNS는 라우팅과 무관하게 켜는 독립적인 최적화 스위치가 아닙니다. 라우팅이 조회 결과에 의존할 수 있고, 조회 연결은 아웃바운드 경로의 영향을 받을 수 있습니다. 도메인 규칙이나 주소 계열을 바꾸기 전에 의존 관계를 먼저 정리하세요. 기본 연결도 성립하지 않았다면 복잡한 도메인 분류, 대체 제한, 다단계 전달을 추가하기보다 단순한 조회 설정으로 되돌아가야 합니다.

06 / policy: 시간 제한, 사용자 수준, 통계

정책은 표시 이름이 아닌 수준 번호와 연결됩니다

policy는 연결 처리 정책과 일부 통계 스위치를 설정합니다. levels 아래의 키는 사용자 수준 번호를 문자열로 표현한 것입니다. 연결이 해당 수준과 연결되는 방식은 프로토콜의 사용자 필드나 인바운드 관련 설정에 따라 달라집니다. 클라이언트 그룹 이름, 서버 메모, 구독 이름은 정책 수준이 아닙니다. 화면에 표시되는 이름을 바꿔도 다른 시간 제한 설정이 자동으로 선택되지는 않습니다.

사용자 수준을 명시적으로 설정하지 않는 일반적인 경우에는 보통 0 수준이 사용되지만, 현재 프로토콜과 코어의 동작을 확인해야 합니다. 수준별 설정이 필요하다면 먼저 해당 사용자 객체에서 수준을 정하는 필드를 찾아 같은 번호를 정책 표에 입력하세요. 어떤 연결에도 사용되지 않는 수준을 선언해도 기존 연결에는 기대한 효과가 없으며 정책 지원 여부를 확인하는 방법으로도 적합하지 않습니다.

시간 제한 값은 연결 단계별 한계를 나타냅니다

아래 숫자는 설명용 예시이며 코어의 기본값을 의미하지 않습니다. handshake는 핸드셰이크 단계의 시간 제한, connIdle은 유휴 연결 처리, uplinkOnly와 downlinkOnly는 한쪽 방향의 전송이 끝난 뒤 기다리는 동작과 관련됩니다. 일반적으로 필드 값은 초 단위지만 구체적인 의미는 사용하는 코어의 문서를 확인하세요. 속도 측정이나 대역폭 설정으로 오해해서는 안 됩니다.

{
  "policy": {
    "levels": {
      "0": {
        "handshake": 8,
        "connIdle": 300,
        "uplinkOnly": 2,
        "downlinkOnly": 5,
        "statsUserUplink": false,
        "statsUserDownlink": false
      }
    },
    "system": {
      "statsInboundUplink": false,
      "statsInboundDownlink": false
    }
  }
}

핸드셰이크 시간이 너무 짧으면 네트워크가 불안정하거나 서버 응답이 조금 느린 경우에도 연결이 일찍 중단될 수 있습니다. 반대로 시간을 크게 늘려도 잘못된 비밀번호나 맞지 않는 전송 방식이 갑자기 정상 동작하지는 않습니다. 핸드셰이크 실패가 발생하면 로그에서 시간 초과, 인증 오류, 프로토콜 불일치 중 무엇인지 먼저 확인하세요. 연결 경로가 정상인데 대기 단계에서만 제한 시간으로 종료되는 경우에 한해 시간 제한을 조정할 이유가 있습니다.

유휴 연결과 데이터가 계속 전송되는 연결은 다릅니다. 브라우저 연결 풀, 메시징의 장시간 연결, 터미널 세션은 애플리케이션 데이터가 한동안 오가지 않을 수 있습니다. 유휴 시간 제한이 너무 짧으면 이런 연결을 다시 설정해야 할 수 있습니다. ‘한동안 두었다가 처음 접속할 때 실패’한다면 애플리케이션의 재연결, 네트워크 장비의 세션 유지, 원격 동작도 함께 고려하세요. 시간 간격만으로 로컬 정책의 문제라고 단정할 수 없습니다.

한쪽 방향의 종료가 전체 세션 종료를 뜻하지는 않습니다

일부 프로토콜에서는 한쪽이 전송을 멈춘 뒤에도 나머지 데이터를 받을 수 있습니다. 단방향 대기 매개변수는 이런 연결 상태를 처리하기 위한 것이며 다운로드를 더 오래 유지하는 스위치가 아닙니다. 대기 시간을 지나치게 짧게 줄이면 필요한 마무리 과정이 중단될 수 있고, 너무 길게 설정하면 불필요한 연결이 오래 남을 수 있습니다. 분명한 문제가 없다면 ‘최적화 설정’을 그대로 따라 하기보다 코어 기본 정책을 유지하는 편이 관리하기 쉽습니다.

정책은 네트워크 패킷 손실, 원격 서버의 연결 거부, 인증서 서비스 이름 오류를 해결하지 못합니다. TCP 연결이 성립하기 전에 발생한 문제라면 프로토콜 핸드셰이크 이후의 유휴 시간을 조정해도 효과가 없습니다. 오류를 읽을 때는 로컬 수신, 도메인 조회, 원격 연결 시도, 프로토콜 핸드셰이크, 데이터 전송 중 어느 단계인지 구분하세요. 단계에 맞는 매개변수를 확인해야 합니다.

통계 스위치와 표시 경로는 따로 설정합니다

예제는 관련 통계 스위치를 명시적으로 끄고 필드 위치만 보여 줍니다. 사용자 통계를 켜려면 일반적으로 식별 가능한 사용자 정보와 해당 통계 기능도 필요합니다. 외부 프로그램에서 데이터를 읽으려면 통계 객체, API 서비스, 접근이 제한된 수신 지점이 추가로 필요할 수 있습니다. 불리언 값 하나만 참으로 바꾼다고 클라이언트 화면에 사용할 수 있는 통계 패널이 자동으로 생기지는 않습니다.

통계 필드를 서비스 제공자의 과금 데이터와 동일하게 볼 수도 없습니다. 코어는 특정 계층에서 연결 바이트를 집계할 수 있고, 원격 서비스는 다른 기준을 사용할 수 있습니다. 재시작, 코어 전환, 상태 초기화로 로컬 누적 범위가 달라질 수도 있습니다. 기록이 필요하다면 먼저 수집 대상, 시간 범위, 초기화 조건을 정하세요. 로컬 관측값을 계정 잔액이나 최종 청구액으로 해석해서는 안 됩니다.

정책을 안전하게 변경하려면 먼저 기본값을 유지하고 재현 가능한 현상에 대해서만 한 항목을 조정하세요. 원래 값과 해결하려는 현상, 재검사 결과를 기록하고 개선되지 않으면 되돌리세요. 애플리케이션이 기존 연결을 계속 사용해 변경 효과를 가리는 일이 없도록 연결을 실제로 다시 설정했는지도 확인해야 합니다. 정책은 연결 수명 주기를 관리하므로 기본 프로토콜과 라우팅을 확인한 다음 다루세요.

07 / 클라이언트 설정 생성, 구독, TUN

원본 데이터를 편집하는지 실행 설정을 편집하는지 확인

v2rayN은 데스크톱에서 서버를 관리하고 코어를 실행하는 데 적합합니다. Android에서는 주로 v2rayNG를 사용하며, V2Fly 코어를 고려한다면 v2flyNG도 대안이 될 수 있습니다. 세 클라이언트는 화면 설정과 저장 방식이 완전히 같지는 않지만 모두 서버 데이터, 클라이언트 설정, 최종 코어 설정을 구분해야 합니다. 한 클라이언트의 설정 디렉터리 구조를 다른 클라이언트에 그대로 적용할 수는 없습니다.

클라이언트가 자동 생성한 실행 파일은 서버나 라우팅을 전환하거나 다시 시작할 때 덮어써질 수 있습니다. 임시 파일을 직접 수정하면 잠시 바뀐 결과를 볼 수는 있어도 계속 유지되지 않을 수 있습니다. 수정 전에 해당 설정이 ‘사용자 지정 설정’, 라우팅 설정, 일반 서버 매개변수 중 어디에 속하는지 확인하세요. JSON 전체를 직접 관리해야 한다면 클라이언트가 공식 지원하는 사용자 지정 설정 기능을 사용하고 적용 범위를 확인하세요.

구독은 서버 정보를 가져오는 출처이지 공통 최상위 필드가 아닙니다

구독 링크는 보통 서버 항목이나 클라이언트가 지원하는 설정 내용을 가져오는 데 사용되며 파싱은 클라이언트 계층에서 이루어집니다. subscription은 V2Ray 최상위 객체에 임의로 넣을 수 있는 공통 필드가 아닙니다. 구독을 업데이트했다고 코어가 새 서버로 전환된 것도 아닙니다. 클라이언트 목록은 업데이트되었더라도 현재 선택한 항목, 활성 연결, 실행 중인 프로세스는 그대로일 수 있으므로 각각 확인해야 합니다.

업데이트에 실패하면 먼저 링크가 완전한지, 여전히 접근 권한이 있는지, 반환된 내용이 클라이언트가 지원하는 형식인지 확인하세요. 로그인 화면, 오류 메시지, 빈 텍스트가 반환되어도 파싱 실패처럼 보일 수 있습니다. 구독 주소를 공개 페이지에 올리지 말고 접근 자격 증명이 포함된 쿼리 부분도 로그 화면에 붙여 넣지 마세요. 전체 점검 순서는 구독 업데이트 실패 자가 점검 목록을 참고하세요.

TUN은 트래픽을 받아들이는 인터페이스와 연계 라우팅에 해당합니다

TUN은 가상 네트워크 인터페이스를 통해 트래픽을 처리 경로로 보냅니다. 클라이언트는 이를 위해 해당 수신 방식을 지원하는 다른 코어나 보조 구성 요소를 사용할 수 있으며, 설정 모델이 이 페이지의 V2Ray 스타일 JSON과 같지 않을 수도 있습니다. 화면에 TUN 스위치가 있다는 이유만으로 설정 최상위에 같은 이름의 객체를 추가하면 안 됩니다. 먼저 현재 TUN이 사용하는 구성 요소, 권한 요구사항, 설정 형식을 확인한 다음 해당 필드를 찾아보세요.

시스템 프록시는 프록시 설정을 따르는 애플리케이션에 주로 영향을 줍니다. TUN이 다루는 범위는 시스템 라우팅, 제외 항목, 주소 계열, 트래픽 수신 구현에 따라 달라집니다. 활성화한 뒤에도 처리되지 않는 트래픽이 있을 수 있고 라우팅 설정이 잘못되어 네트워크 문제가 생길 수도 있습니다. ‘전체’ 모드라고 해서 모든 프로그램과 프로토콜이 반드시 같은 출구를 사용한다고 볼 수는 없습니다. 실제 동작은 분기 규칙과 애플리케이션 동작을 함께 확인해야 합니다.

TUN에서는 프록시 연결이 다시 가상 네트워크 인터페이스로 들어가지 않도록 특히 주의해야 합니다. 클라이언트가 일반적으로 필요한 우회 경로와 제외 항목을 설정하므로 라우팅을 수동으로 추가하면 이런 설정을 망가뜨릴 수 있습니다. 활성화 후 코어가 서버에 연결되지 않는다면 권한, 네트워크 인터페이스, DNS를 확인하기 전에 트래픽이 순환해서 다시 수신되는지 살펴보세요. 설정 절차는 v2rayN TUN 모드 설정 안내를 참고하세요.

설정을 옮길 때는 먼저 클라이언트와 실제 코어 이름을 기록하고 사용 중인 프로토콜과 확장 기능도 적어 두세요. Xray가 지원하는 아웃바운드나 보안 옵션을 V2Fly가 바로 읽을 수 있는 것은 아닙니다. 같은 Project V 생태계에 속한다고 해서 필드가 항상 호환되는 것도 아닙니다. 코어를 바꾼 뒤에는 창이 열리는지만 확인하지 말고 설정 로딩, 핸드셰이크, 라우팅을 다시 검증하세요.

백업에는 임시 생성 파일뿐 아니라 복구에 필요한 원본 데이터도 포함해야 합니다. 최소한 사용자 지정 규칙, 수정 내역, 필요한 클라이언트 내보내기 파일을 보관하고 서버 인증 정보는 안전하게 보호하세요. 문제 해결 자료를 공유할 때는 주소 외의 민감한 인증 정보를 예시 값으로 바꾸세요. 바꾼 뒤에는 중첩 객체, 메모, 구독 쿼리 부분도 다시 확인해 화면 첫 줄만 가린 채 정보가 남는 일이 없도록 하세요.

재설치가 필요하다면 클라이언트 및 플랫폼 다운로드에서 운영체제와 아키텍처에 맞는 항목을 선택하세요. 파일명이 비슷하다는 이유로 호환된다고 판단하지 마세요. 설치를 마친 뒤 최소 설정부터 복원하고 구독, 라우팅, 트래픽 수신 설정을 차례대로 복원하세요. 이전 설정을 한꺼번에 모두 가져온 뒤에야 테스트하면 문제가 클라이언트 환경 변화 때문인지 기존 설정의 호환성 때문인지 구분할 수 없습니다.

08 / 설정 검증, 로그, 복구 순서

실패 단계에 따라 범위 좁히기

문제를 해결할 때 가장 먼저 실패가 어느 계층에서 발생하는지 확인해야 합니다. 창이 열린다는 것은 클라이언트 화면이 실행된다는 뜻일 뿐입니다. 코어 프로세스가 시작되어야 설정 로딩이 관련 단계를 통과했다고 볼 수 있고, 로컬 포트에 연결된다고 원격 인증까지 성공한 것은 아닙니다. 조건을 나눠 검증하면 JSON 문법 오류가 있는데 노드만 계속 바꾸거나 애플리케이션이 프록시를 사용하지 않는데 라우팅만 계속 수정하는 일을 줄일 수 있습니다.

저장하기 전에 괄호의 짝, 문자열의 닫힘, 배열 항목 사이의 쉼표, 필드 값 유형을 정적으로 확인하세요. 그런 다음 아웃바운드 참조가 있는지, 규칙 데이터를 읽을 수 있는지, 프로토콜 필드가 현재 코어에서 지원되는지 구조와 의미를 살펴보세요. 엄격한 JSON 파싱에 성공해도 문법만 확인된 것입니다. 코어가 모든 필드를 인식한다거나 실제 서버 요구사항에 맞는 설정이라고 보장하지는 않습니다.

로그 수준은 문제를 찾을 수 있는 정도로 높인 뒤 평상시 설정으로 되돌리세요

warning은 일반적인 실행 정보를 줄이는 데 적합하지만 아웃바운드 선택 과정을 확인하기에는 부족할 수 있습니다. 문제를 찾을 때는 임시로 info로 바꾸고, 필요하면 현재 코어가 지원하는 더 자세한 수준을 짧은 시간 동안 사용하세요. 로그 수준마다 표시되는 이벤트가 다르므로 특정 로그가 없다고 해서 해당 동작도 없었다고 단정할 수 없습니다. 상세 로그에는 대상 주소가 포함될 수 있으니 필요한 시간 동안만 수집하고 공유 범위를 제한하세요.

{
  "log": {
    "loglevel": "info"
  }
}

이 조각은 로그 객체를 교체하는 부분 설정이며 단독으로 실행할 수 있는 완성 설정이 아닙니다. 출력 파일 경로를 별도로 설정한다면 코어 프로세스에 쓰기 권한이 있고 현재 실행 환경에서 사용할 수 있는 경로인지 확인하세요. 포터블 디렉터리, 보호된 설치 폴더, 모바일 기기 저장소는 권한이 다를 수 있습니다. 로그 파일이 비어 있다면 코어에서 이벤트가 발생하지 않았다고 판단하기 전에 출력 위치와 권한부터 확인하세요.

흔한 증상별 확인 순서

로컬 연결이 거부되었을 때 원격 DNS부터 조사할 필요는 없습니다. 현재 클라이언트가 종료되지 않았는지, 코어가 시작 직후 충돌하지 않았는지, 애플리케이션이 실제 수신 포트를 사용하는지 확인하세요. 클라이언트가 여러 개 실행 중이라면 어느 프로세스를 대상으로 테스트하는지도 확인해야 합니다. 백그라운드 프로세스가 남아 있으면 포트 충돌이 발생할 수 있습니다. 화면에 보이는 창을 닫기만 해서는 해당 서비스가 종료되지 않을 수도 있습니다.

원격 연결 시간 초과와 인증 실패는 나눠서 처리해야 합니다. 시간 초과라면 대상 주소에 도달할 수 있는지, 도메인이 예상한 주소로 조회되는지, 아웃바운드가 자기 자신으로 되돌아가는지를 먼저 확인하세요. 인증 실패라면 프로토콜, 비밀번호나 사용자 ID, 전송 및 보안 매개변수를 대조하는 것이 중요합니다. 서로 관련 없는 필드를 연달아 바꾸면 명확했던 오류에 여러 문제가 겹쳐 로그를 비교하기 어려워집니다.

일부 대상에서만 문제가 생긴다면 같은 애플리케이션과 대상을 고정해 테스트하세요. 애플리케이션이 프록시를 우회하는지, 자체 DNS를 사용하는지, 기존 연결을 유지하고 있는지 확인한 다음 일치한 라우팅 규칙과 최종 출구를 살펴보세요. 속도 테스트 성공이 실제 애플리케이션 검증을 대신하지는 않습니다. 테스트마다 대상, 연결 방식, 라우팅 조건이 다를 수 있기 때문입니다. 관련 용어는 용어 설명에서 확인할 수 있습니다.

변수를 하나씩 바꿔 재검사하고 복구 내역을 남기세요

매번 직접적인 인과 관계가 있는 항목만 함께 수정하세요. 예를 들어 로컬 포트를 바꾸면서 애플리케이션의 연결 포트도 바꿀 수는 있지만 DNS, 아웃바운드 프로토콜, 라우팅 모드를 동시에 조정하지는 마세요. 저장한 뒤 클라이언트가 요구하는 방식으로 코어를 다시 불러오거나 재시작하고 새 연결을 만들어 테스트하세요. 기존 장시간 연결은 이전 경로를 계속 사용할 수 있으며 페이지를 새로고침해도 완전히 새로운 연결이 만들어지지 않을 수 있습니다.

재검사 기록에는 수정 목적, 변경 전후 설정 조각, 테스트 대상, 로그에서 확인한 현상을 포함하세요. 근거 없는 성능 결론을 기록하거나 모든 로그를 장기간 보관할 필요는 없습니다. 맥락 없이 ‘네트워크가 느림’이라고 적는 것보다 ‘특정 규칙이 잘못된 출구와 일치함’처럼 안정적으로 재현되는 현상이 더 유용합니다. 결과가 개선되지 않으면 원래 값으로 복구한 다음 기준 상태가 여전히 작동하는지 확인하세요.

일상적으로 사용할 때는 안정적으로 표현할 수 있는 일반 설정을 클라이언트에 맡기고 사용자 지정 JSON은 명확히 필요한 동작에만 사용하세요. 설정 위치를 찾기 어렵다면 v2rayN 메인 화면 안내를 참고하세요. 처음 설정하는 순서는 입문 가이드를 우선 확인하면 됩니다. 이 매뉴얼은 필드와 적용 범위를 설명하며, 실제 적용 여부는 현재 코어, 실행 설정, 재검사 결과를 기준으로 판단해야 합니다.