config.json 설정 항목 가이드

JSON 구조 개요

V2Ray 생태계의 설정 파일은 애플리케이션이 로컬 포트에 연결하고, 인바운드가 요청을 코어에 전달한 뒤, 라우팅이 목적지와 출발지를 기준으로 아웃바운드를 선택하고, 아웃바운드가 실제 연결을 수립하는 전체 데이터 흐름을 정의합니다. dns는 내장 DNS 조회 기능을 제공하고 policy는 일부 연결 단계의 제한 시간을 제어합니다. 파일명은 보통 config.json이지만, 의미를 결정하는 것은 파일명이 아니라 내용과 이를 불러오는 코어입니다. 먼저 Xray를 사용하는지 V2Fly를 사용하는지 확인한 다음 해당 코어가 지원하는 설정 형식과 대조하세요.

객체, 배열 및 항목 유형

최상위는 JSON 객체입니다. inbounds와 outbounds는 배열입니다. 하나의 프로세스에서 여러 수신 지점을 제공하거나 여러 출구를 준비할 수 있기 때문입니다. routing, dns, policy는 각각 규칙, 서버, 정책 매핑을 담는 객체입니다. 필드명과 문자열에는 영문 큰따옴표를 사용하고, 포트는 보통 숫자, 스위치는 true 또는 false 불리언 값으로 지정합니다. 숫자와 문자열은 임의로 바꿔 쓸 수 없습니다. 경로, 태그, 프로토콜 이름도 정확한 표기를 유지해야 합니다.

엄격한 JSON에서는 주석, 마지막 항목 뒤의 쉼표, 한국어 따옴표를 사용할 수 없습니다. 일부 코어 도구에서 추가 설정 읽기 기능을 제공할 수 있지만, 클라이언트 간에 설정을 전달할 때는 엄격한 JSON 형식을 유지하세요. 예제의 들여쓰기는 가독성을 위한 것으로 실행에는 영향을 주지 않습니다. 파싱에 영향을 미치는 것은 괄호, 쉼표, 데이터 유형입니다. JSON 파서가 파일을 읽었다고 해서 프로토콜 항목, 아웃바운드 참조, 실행 환경까지 올바르다는 뜻은 아닙니다. 시작에 실패하면 여러 계층을 한꺼번에 수정하지 말고 먼저 문법 오류와 코어 설정 오류를 구분하세요.

{
  "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": {}
    }
  ],
  "routing": {
    "domainStrategy": "AsIs",
    "rules": []
  },
  "dns": {
    "servers": ["localhost"]
  }
}

설정 섹션 간 참조 관계

tag는 설정 내부에서 사용하는 이름이며 서버에 전달되는 인증 정보가 아닙니다. 라우팅 규칙의 outboundTag는 실제로 존재하는 아웃바운드를 가리켜야 합니다. inboundTag를 지정하면 특정 인바운드에서 들어온 요청에만 규칙을 적용할 수 있습니다. 태그는 짧고 안정적인 영문 이름을 사용하고 각 배열 안에서 고유하게 지정하는 것이 좋습니다. 아웃바운드 태그를 바꾸면 이를 참조하는 규칙도 모두 수정해야 합니다. 그렇지 않으면 설정 파일이 완전해 보여도 연결이 예상대로 전달되지 않을 수 있습니다. 기본 아웃바운드는 보통 배열의 첫 번째 항목이므로 순서도 설정 동작에 영향을 줍니다.

최상위 섹션을 작성한 순서가 처리 순서를 뜻하지는 않습니다. dns를 routing 앞에 작성해도 모든 요청이 먼저 내장 DNS 조회를 거치는 것은 아닙니다. 반면 규칙을 배열의 맨 위로 옮기면 매칭 결과가 달라질 수 있습니다. 설정을 읽을 때 객체의 필드 순서와 배열 항목 순서를 구분하세요. 전자는 대체로 내용을 정리하는 역할을 하지만, 후자는 라우팅과 기본 아웃바운드 선택 등에 실제 영향을 줍니다. 설정 두 개를 합칠 때는 최상위 키가 중복되지 않는지도 확인하세요. 중복 키는 파서가 덮어써도 알아채기 어려울 수 있습니다.

먼저 정상적으로 시작되는 기본 설정을 저장한 뒤 인바운드, 아웃바운드, 라우팅, DNS, 정책 순서로 항목을 하나씩 추가하세요. 설정 섹션을 하나 추가할 때마다 다시 불러오고 로그를 확인합니다. 이렇게 하면 복잡한 파일을 추측하며 고치는 대신 최근 변경 사항에서 오류 원인을 좁힐 수 있습니다. 그래픽 클라이언트가 생성한 파일에는 보조 인바운드와 내부 태그가 포함될 수 있습니다. 파일을 읽을 때는 먼저 주요 데이터 흐름을 그린 다음 클라이언트가 자동으로 관리하는 부분을 구분하세요.

inbounds 인바운드 리스닝

inbounds는 코어가 트래픽을 받는 위치를 정의합니다. 로컬 클라이언트에서는 SOCKS 또는 HTTP 인바운드를 주로 사용하며, 애플리케이션은 해당 프록시 프로토콜로 포트에 접속합니다. 인바운드는 원격 서버가 아니며 최종적으로 어떤 프록시 아웃바운드를 사용할지도 결정하지 않습니다. 문제를 진단할 때는 먼저 애플리케이션이 이 인바운드에 실제로 연결되는지 확인하세요. 요청이 코어에 들어와야 이후 라우팅과 아웃바운드 설정이 적용됩니다. 브라우저에서 시스템 프록시를 사용하는 방법과 프로그램에 SOCKS 주소를 직접 입력하는 방법은 서로 다른 접속 방식입니다.

리스닝 주소, 포트 및 프로토콜

listen은 어떤 로컬 주소에서 대기할지 지정합니다. 개인 기기에서 사용하는 로컬 프록시는 인바운드가 기기 안에서만 연결을 받도록 127.0.0.1에 바인딩하는 것이 좋습니다. 모든 인터페이스에 바인딩하면 접근 범위가 넓어지므로 연결 문제를 해결하는 일반적인 방법으로 사용해서는 안 됩니다. port는 애플리케이션에 입력한 포트와 일치해야 하며 다른 프로세스가 사용 중이어서는 안 됩니다. protocol은 클라이언트가 인바운드와 통신하는 방식을 정합니다. HTTP 요청을 SOCKS 포트로 보내면 프로토콜이 자동 변환되는 것이 아니라 핸드셰이크가 실패할 가능성이 큽니다.

SOCKS와 HTTP 인바운드의 차이

SOCKS 인바운드는 SOCKS 프록시를 명시적으로 지원하는 애플리케이션에 적합합니다. settings.udp를 활성화하면 인바운드에서 SOCKS UDP 전달을 처리할 수 있지만, 애플리케이션도 해당 프로토콜을 사용해야 하며 이후 아웃바운드와 원격 연결 경로도 그 트래픽을 전달할 수 있어야 합니다. HTTP 인바운드는 보통 HTTP 프록시 또는 CONNECT를 지원하는 애플리케이션에 사용하며, 임의의 UDP 트래픽을 받는 인바운드가 아닙니다. 시스템 프록시 설정은 이를 따르는 프로그램에만 영향을 줍니다. 기기의 모든 연결이 코어로 들어온다고 단정해서는 안 됩니다.

{
  "inbounds": [
    {
      "tag": "http-in",
      "listen": "127.0.0.1",
      "port": 10809,
      "protocol": "http",
      "settings": {}
    }
  ]
}

이 조각은 HTTP 인바운드 하나만 추가합니다. 앞 장의 기본 설정과 합칠 때는 이 객체를 기존 inbounds 배열에 추가하고, 같은 이름의 최상위 키를 다시 작성하지 마세요. 포트 번호는 예시일 뿐 모든 클라이언트에서 고정으로 사용하는 값이 아닙니다. v2rayN이나 Android 클라이언트는 설정에 따라 다른 포트를 만들 수 있으므로 실제 사용 중인 클라이언트 설정을 확인해야 합니다. 리스닝 포트를 바꾸면 애플리케이션의 프록시 설정도 함께 바꿔야 합니다. 그렇지 않으면 기존 포트에 계속 연결을 시도합니다.

목적지 식별 및 접속 범위

sniffing은 지원되는 트래픽의 특성에서 도메인을 추출해 도메인 라우팅에 활용할 정보를 보완합니다. 모든 트래픽을 복호화하거나 임의의 연결에서 도메인을 복구하는 기능은 아닙니다. 목적지 재정의, 라우팅에만 적용 등의 옵션은 코어별 지원 여부를 확인해야 합니다. 처음 문제를 진단할 때는 클라이언트 기본 식별 설정을 유지하고 일반 요청이 들어오는지 확인한 뒤, 도메인 정보가 분기 처리에 영향을 주는지 단계적으로 살펴보세요. 인바운드 문제와 식별 동작을 혼동하지 않는 것이 중요합니다.

로컬 네트워크에서 접근을 허용하려면 바인딩 주소, 인증, 호스트 방화벽, 신뢰할 수 있는 네트워크 범위를 함께 고려해야 합니다. listen만 바꾼다고 다른 기기에서 반드시 접속할 수 있는 것은 아니며, 해당 인바운드가 공용 인터넷에 노출해도 괜찮다는 뜻도 아닙니다. 개인 기기에서 로컬로 사용할 때는 루프백 리스닝을 유지하는 편이 접근 범위를 제어하기 쉽습니다. 로그에 주소 사용 중 오류가 표시되면 기존 클라이언트를 종료하거나 사용 가능한 포트로 변경하세요. 접속 기록이 전혀 없다면 애플리케이션의 프록시 주소와 유형, 로컬 프록시 우회 규칙이 켜져 있는지 확인하세요.

TUN을 통한 트래픽 처리와 일반 SOCKS·HTTP 리스닝은 서로 다른 접속 계층입니다. 클라이언트는 가상 네트워크 인터페이스를 통해 트래픽을 코어로 전달할 수 있지만, 인터페이스 이름과 권한 요청, 시스템 라우팅은 클라이언트가 관리하는 경우가 많습니다. 이를 일반적인 단일 인바운드 항목으로 설명할 수는 없습니다. 자세한 내용은 v2rayN TUN 모드 설정 노트를 참고하세요. 이 절을 확인할 때는 애플리케이션 프록시 인바운드 문제인지 가상 네트워크 인터페이스를 통한 트래픽 처리 문제인지 먼저 구분해야 합니다.

outbounds 아웃바운드 및 기본 출구

outbounds에는 코어가 사용할 수 있는 출구가 정의됩니다. 목적지에 직접 연결하거나 연결을 거부할 수도 있고, 원격 프록시를 통해 전달할 수도 있습니다. 라우팅 규칙이 선택하는 것은 구독 화면에 표시된 이름이 아니라 아웃바운드 태그입니다. 클라이언트에서 노드를 바꾸면 프록시 아웃바운드의 주소와 인증 매개변수가 다시 생성되는 경우가 많습니다. 따라서 노드 선택과 아웃바운드 JSON 편집은 같은 경로에서 서로 다른 계층의 작업입니다. 내보낸 설정을 읽을 때는 선택한 노드가 어떤 아웃바운드에 해당하는지, 실제로 어떤 규칙이 이를 참조하는지 확인하세요.

프로토콜 설정과 전송 설정의 구분

protocol은 아웃바운드에서 사용할 프로토콜을 지정하고, settings에는 해당 프로토콜에 필요한 값이 들어갑니다. VMess 같은 원격 프로토콜에서는 서버 주소, 포트, 사용자 ID 등이 서버 설정과 일치해야 합니다. streamSettings는 사용할 전송 방식, TLS 연결 여부, 서버 이름 등 하위 전송 및 보안 계층을 정의합니다. 프로토콜 인증 성공과 전송 연결 수립은 서로 다른 단계입니다. 모든 연결 실패를 노드 주소 오류로 판단하지 마세요.

클라이언트 화면에 표시되는 서버 주소, TLS 서버 이름, HTTP 계열 전송의 Host는 역할이 서로 다를 수 있습니다. 서버 주소는 연결할 끝점을 지정하고, TLS 서버 이름은 핸드셰이크와 인증서의 신원 확인에 사용되며, 전송 계층의 Host는 해당 프로토콜의 요청 매개변수입니다. 값이 같은 경우도 있지만, 그렇다고 모두 동일한 값으로 맞춰서는 안 됩니다. 수정할 때는 서버에서 제공한 연결 정보를 기준으로 항목별로 입력하세요. 인증서 검증을 임의로 끄면 신원 확인과 연결 경로 문제를 가릴 수 있으므로 일반적인 문제 해결 방법이 아닙니다.

직접 연결, 거부 및 프록시 아웃바운드

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

이 조각에서는 freedom으로 목적지에 직접 연결하고 blackhole로 해당 아웃바운드에 배정된 트래픽을 거부합니다. 첫 번째 항목이 직접 연결이므로 어떤 규칙에도 매칭되지 않은 요청은 기본적으로 직접 연결됩니다. 거부 아웃바운드를 첫 번째로 옮기면 규칙에 매칭되지 않은 요청이 모두 거부될 수 있습니다. 이 예제에는 프록시 아웃바운드가 없으므로 원격 프록시가 작동하는지 확인할 수 없습니다. 실제 프록시 아웃바운드를 추가할 때는 기본 트래픽을 프록시와 직접 연결 중 어느 쪽으로 보낼지 정한 뒤 배열 순서나 마지막 기본 규칙을 설정하세요.

코어별 차이와 연결 기능

Xray와 V2Fly는 일부 설정 방식이 비슷하지만, 필드를 자유롭게 서로 바꿔 쓸 수 있는 것은 아닙니다. 같은 이름의 기능도 값, 기본값, 지원 조건이 다를 수 있습니다. 특히 새 프로토콜과 전송, 보안 계층, 도메인 조회 정책은 현재 사용하는 코어의 기능을 기준으로 확인하세요. 한 코어용 설정을 다른 코어에서 사용하기 전에는 프로토콜과 전송, 확장 필드를 차례로 점검해야 합니다. 파일명이 둘 다 config.json이라는 이유만으로 바로 실행할 수 있다고 판단하지 마세요.

UDP 사용 가능 여부는 전체 연결 경로가 함께 지원하는지에 달려 있습니다. 인바운드에서 UDP를 허용하고, 아웃바운드 프로토콜이 해당 트래픽을 전달할 수 있으며, 서버가 전달을 허용하고, 네트워크 경로까지 연결되어야 합니다. 하나라도 충족되지 않으면 실패할 수 있습니다. 웹 페이지가 열린다는 것은 관련 TCP 요청이 작동한다는 뜻일 뿐, 음성 통화나 게임 등 UDP 애플리케이션도 같은 경로를 사용할 수 있다는 의미는 아닙니다. 일부 애플리케이션에서만 문제가 생기면 실제로 어떤 네트워크 프로토콜을 사용하는지 확인한 뒤 인바운드, 아웃바운드, 원격 전달 설정 중 어디를 점검할지 결정하세요.

처음 설정할 때는 v2rayN의 노드 편집 또는 구독 가져오기 기능으로 원격 아웃바운드를 생성한 뒤 이 절과 대조하는 것이 좋습니다. 조각만 보고 인증 정보를 임의로 채우지 마세요. Android의 v2rayNG와 v2flyNG는 서로 다른 코어 선택에 해당합니다. 자세한 범위는 Xray와 V2Fly 코어 선택 노트를 참고하세요. 진단 자료를 공유할 때는 필요한 항목과 오류 유형만 남기고 구독 주소, 사용자 ID, 기타 인증 정보는 숨겨야 합니다. 전체 연결 정보가 로그를 통해 퍼지지 않도록 주의하세요.

routing 라우팅 규칙 및 매칭 순서

routing은 각 요청을 어느 아웃바운드로 전달할지 결정합니다. 이미 코어에 들어온 트래픽을 처리하므로 운영체제 라우팅을 대신하거나 프록시 설정을 무시하는 애플리케이션을 자동으로 연결하지는 않습니다. 일반적으로 rules 배열에 각 규칙의 도메인, IP, 포트, 네트워크 유형, 인바운드 태그 조건을 지정합니다. 규칙은 위에서 아래로 확인하며 매칭되면 해당 출구를 선택합니다. 조건이 지나치게 넓은 규칙은 뒤에 있는 세부 규칙을 가릴 수 있습니다.

규칙 조건 조합 방식

필드 규칙에서 같은 목록에 여러 후보를 넣으면 보통 그중 하나만 만족해도 매칭됩니다. 예를 들어 domain 배열에는 여러 도메인을 넣을 수 있습니다. 반면 한 규칙에 서로 다른 조건 필드를 지정하면 모든 조건을 만족해야 합니다. 예를 들어 inboundTag와 domain을 함께 지정하면 특정 인바운드에서 들어오고 목적지 도메인도 목록에 포함된 요청을 뜻합니다. 이런 조건을 선택 사항처럼 잘못 해석하면 규칙이 예상보다 좁게 적용될 수 있습니다. 문제를 진단할 때는 조건 하나만 남겨 매칭 여부를 확인한 다음 제한을 하나씩 추가하세요.

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": ["full:blocked.example"],
        "outboundTag": "block"
      },
      {
        "type": "field",
        "ip": ["127.0.0.0/8", "10.0.0.0/8", "192.168.0.0/16"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "direct"
      }
    ]
  }
}

이 조각은 앞 장의 직접 연결 및 거부 아웃바운드와 함께 사용할 수 있습니다. blocked.example은 정확한 매칭 문법을 보여 주는 예시 도메인입니다. 거부되지 않은 요청은 최종적으로 직접 연결됩니다. 마지막 규칙은 명시적인 기본 규칙이며 프록시 분기 처리는 다루지 않습니다. 기본 출구를 프록시로 바꾸려면 실제 프록시 아웃바운드를 먼저 정의한 뒤 마지막 규칙에서 정확한 태그를 지정하세요. 정의되지 않은 proxy를 규칙에 적어도 아웃바운드가 자동으로 생성되지는 않습니다.

도메인, IP 및 조회 정책

full:은 전체 도메인과 일치시키고, domain:은 도메인과 하위 도메인까지 매칭합니다. 일반 문자열과 정규식은 의미가 서로 다르므로 겉으로 보이는 문자열만 보고 혼용해서는 안 됩니다. IP 조건에는 단일 주소나 CIDR 대역을 사용할 수 있습니다. 지리 분류 데이터를 사용한다면 실행 환경에 해당 데이터 파일이 있고, 분류 이름이 유효하며, 데이터 출처를 신뢰할 수 있는지 확인해야 합니다. 문제를 분리해 살펴보려면 처음에는 특정 도메인이나 주소 하나로 테스트한 뒤 대규모 분류 목록을 추가하세요.

domainStrategy는 라우팅 단계에서 도메인 조회 결과를 사용하는 방식을 결정합니다. AsIs는 요청에 이미 들어 있는 대상 정보를 유지합니다. IPIfNonMatch는 도메인 규칙으로 출구를 결정하지 못했을 때 IP 조회를 시도한 뒤 IP 규칙을 계속 확인할 수 있습니다. IPOnDemand는 매칭에 IP 정보가 필요한 경우 조회를 시작할 수 있습니다. 구체적인 동작 범위는 사용하는 코어의 설명을 확인하세요. 정책을 선택할 때는 조회 비용, DNS 접근성, 기본 규칙 위치를 함께 고려해야 합니다. 조회를 적극적으로 한다고 반드시 정확해지는 것은 아닙니다.

원래 요청에 IP만 포함되어 있다면 도메인 규칙이 매칭되지 않을 수 있습니다. 애플리케이션이 운영체제에서 이미 도메인을 조회했거나 자체 암호화 DNS로 주소를 얻었을 수 있습니다. 인바운드의 대상 식별 기능은 지원되는 트래픽에서 일부 도메인 정보를 보완할 뿐입니다. 반대로 도메인 요청이라고 해서 IP 규칙에 사용할 주소가 즉시 확보되는 것도 아닙니다. 특정 규칙을 진단할 때는 브라우저 주소 표시줄만 보고 추측하지 말고 로그에서 코어가 실제로 어떤 목적지를 확인했는지 살펴보세요.

규칙 관리 및 회귀 테스트

거부 규칙, 특정 서비스 규칙, 내부망 규칙, 기본 규칙을 구분해 명확한 순서로 정리하는 것이 좋습니다. 규칙을 추가할 때마다 예상 목적지와 아웃바운드를 기록하고, 더 앞선 규칙이 요청을 먼저 가로채지 않는지 확인하세요. 규칙 파일을 정리할 때 순서를 단순한 서식 문제로 여기지 마세요. 위치를 옮기면 동작이 바로 달라질 수 있습니다. 클라이언트에서 미리 설정된 라우팅 모드를 제공한다면 사용자 지정 목록을 덮어쓰는지, 모드 전환 시 설정 섹션 전체가 다시 생성되는지 먼저 확인하세요.

주요 설정 섹션 세 가지의 관계는 inbounds, outbounds, routing 단계별 설명에서 더 살펴볼 수 있습니다. 자주 사용하는 애플리케이션의 트래픽 처리 범위만 바꾸려는 경우에는 먼저 클라이언트의 시스템 프록시 또는 TUN 상태를 확인한 뒤 코어의 분기 설정을 편집하세요. 애플리케이션이 아직 연결되지 않았다면 도메인 규칙을 더 추가해도 실제 연결 경로는 달라지지 않습니다.

dns 조회 서버 및 도메인 분기

dns는 코어의 내장 DNS 조회를 설정하지만 기기의 모든 DNS 요청을 자동으로 처리하지는 않습니다. 시스템 조회, 애플리케이션 자체 조회, 코어가 라우팅을 위해 실행하는 조회, 원격 출구 측 조회가 동시에 발생할 수 있습니다. 설정을 살펴보기 전에 어느 계층에서 주소가 필요한지 확인하세요. 애플리케이션이 이미 IP를 전달했다면 내장 서버를 바꿔도 연결에 영향이 없을 수 있습니다. 라우팅에서 도메인을 IP로 바꿔야 한다면 내장 조회기가 규칙 선택에 직접 영향을 줄 수 있습니다.

servers 목록 및 서버 객체

servers에는 간단한 서버 항목이나 도메인 범위 등의 조건을 포함한 서버 객체를 지정할 수 있습니다. localhost는 로컬 시스템의 조회 경로를 사용한다는 뜻으로, 최소 진단 설정을 만들 때 유용합니다. 다만 결과는 시스템 DNS, 네트워크, 로컬 설정의 영향을 받습니다. 공용 DNS 주소를 입력하는 것은 조회 대상을 지정하는 것일 뿐, 조회가 반드시 프록시를 통하거나 원하는 결과를 보장하지는 않습니다. 해당 서버에 접근할 수 있는지, 조회 요청이 어떤 경로로 전송되는지는 코어와 관련 라우팅 설정을 함께 확인해야 합니다.

{
  "dns": {
    "servers": [
      {
        "address": "1.1.1.1",
        "port": 53,
        "domains": ["domain:example.com"],
        "expectIPs": ["93.184.216.0/24"]
      },
      "localhost"
    ]
  }
}

여기서는 예약된 예시 도메인으로 조회 조건과 결과 필터링 방식을 설명합니다. expectIPs의 주소 대역은 필터 문법을 보여 주기 위한 예시일 뿐, 해당 도메인이 현재 이 대역을 반환해야 한다는 뜻은 아닙니다. 도메인 주소는 달라질 수 있으므로 그대로 사용하면 필터링이 실패할 수 있습니다. 실제 적용 전에는 직접 관리하는 조회 범위에 맞춰 입력하고, 예상 주소를 모른다면 해당 조건을 제거하세요. 이 예제는 첫 번째 서버의 조회가 프록시를 통한다고 보장하지 않으므로 조회 경로를 별도로 점검해야 합니다.

domains, expectIPs 및 대체 동작

domains는 특정 서버가 우선 처리할 도메인 범위를 지정하며, 라우팅에서 최종 출구를 고르는 설정과는 다릅니다. expectIPs는 조회 결과에 예상 주소 범위를 적용해 예상과 다른 주소를 확인하는 기능입니다. 조회 결과를 임의로 바로잡아 주지는 않습니다. 주소 범위가 너무 좁거나 오래되면 유효한 결과를 거부해 정상적으로 접속할 수 있는 도메인의 조회도 실패할 수 있습니다. 이런 조건을 설정하기 전에는 도메인의 실제 호스팅 방식과 주소의 안정성을 확인해야 합니다.

매칭되는 서버와 매칭되지 않는 서버, 조회 실패 후의 대체 동작은 사용하는 코어와 관련 옵션의 영향을 받습니다. 서버가 배열에서 어느 위치에 있는지만 보고 모든 조회가 엄격히 순차 처리된다고 가정하지 마세요. 특정 서버가 일반적인 대체 경로에 참여하지 않게 하려면 먼저 해당 코어에서 관련 필드가 의미하는 바를 확인한 뒤 일부 조건만 적용해 테스트하세요. 복잡한 분기 설정을 만들 때는 서버를 여러 개 한꺼번에 묶기보다 각 서버가 대상 도메인을 조회하는지 따로 확인한 다음 하나의 정책에 추가하는 편이 문제를 찾기 쉽습니다.

조회 순환, 캐시 및 주소 계열

암호화 DNS 엔드포인트를 사용할 때는 엔드포인트의 호스트 이름도 조회해야 할 수 있습니다. 이 호스트 이름을 조회하는 데 아직 설정되지 않은 같은 조회 경로가 필요하다면 시작 단계에서 의존성 순환이 발생합니다. 서버 이름을 계속 바꾸기보다 조회를 시작하는 경로와 조회 전송 경로를 먼저 정리하세요. 로컬 조회, 원격 조회, DNS 라우팅 태그 지원 여부는 코어마다 다릅니다. 특히 코어를 바꿀 때는 다시 확인해야 하며 전송 방식 이름만으로 전체 동작을 판단해서는 안 됩니다.

IPv4와 IPv6 결과도 구분해야 합니다. IPv6 주소를 얻었다고 현재 아웃바운드에서 IPv6 연결을 사용할 수 있는 것은 아닙니다. IPv4만 조회하는 방식도 모든 네트워크에 적합한 것은 아닙니다. 테스트할 때 조회 결과의 주소 계열을 기록하고 실제 연결에 실패한 주소와 대조하세요. DNS를 수정한 뒤에는 설정을 다시 불러오고 새 연결을 만들어야 합니다. 운영체제, 애플리케이션, 코어마다 캐시가 있을 수 있어 이전 결과가 한동안 영향을 줄 수 있습니다. 페이지를 한 번 새로고침한 것만으로 설정이 반영되지 않았다고 판단하지 마세요.

DNS 설정의 목적은 조회 위치, 요청 경로, 연결 출구를 일관되게 맞추는 것이지 서버 수를 늘리는 것이 아닙니다. 도메인 범위별로 조회를 나누려면 DNS 분기 조회 설정 노트를 참고해 항목별로 확인하세요. 검증된 규칙을 소수만 유지하고 각 규칙의 적용 범위를 기록하는 편이 테스트 근거가 없는 긴 목록을 관리하는 것보다 안전합니다.

policy 연결 단계 및 사용자 레벨

policy는 라우팅 규칙도, 클라이언트의 전역 트래픽 처리 모드도 아닙니다. 주로 연결 단계와 유휴 상태, 일부 통계 동작을 위한 정책을 제공합니다. 시간 제한을 네트워크 속도 향상 설정으로 오해하기 쉽습니다. 대기 시간을 줄여도 실제 연결 지연이 줄어드는 것은 아니며, 실패가 더 빨리 드러날 뿐입니다. 제한을 지나치게 짧게 설정하면 복구될 수 있는 연결도 끊길 수 있습니다. 분명한 문제가 없다면 코어 기본값을 유지하세요.

levels와 level의 관계

levels는 사용자 레벨을 키로 사용하며 각 레벨에 정책을 설정합니다. JSON 객체의 키는 문자열이어야 하므로 예제에서는 "0"으로 표기합니다. 사용자 레벨을 지원하는 프로토콜 사용자 객체에서는 level이 보통 숫자입니다. 두 항목은 서로 연결되지만 같은 필드는 아닙니다. 레벨을 정의해도 모든 연결에 자동 적용되지는 않습니다. 관련 프로토콜이 해당 사용자 정보를 전달하는지, 사용자가 어떤 레벨로 설정되어 있는지에 따라 적용 여부가 달라집니다.

{
  "policy": {
    "levels": {
      "0": {
        "handshake": 4,
        "connIdle": 300,
        "uplinkOnly": 2,
        "downlinkOnly": 5
      }
    }
  }
}

이 조각은 정책 객체의 구조만 보여 줍니다. 숫자의 단위는 초이며 모든 네트워크에 권장되는 값은 아닙니다. 사용자, 아웃바운드, 리스닝 인바운드를 생성하지 않으며 모든 프로토콜에 해당 제한이 적용된다고 보장하지도 않습니다. 클라이언트에 관련 사용자 레벨 설정이 없다면 수정하기 전에 생성된 설정에서 실제 매핑을 확인하세요. 특히 levels를 노드 우선순위 목록으로 해석하면 안 됩니다. 숫자가 높다고 노드가 더 빠르거나 라우팅 우선순위가 높아지는 것은 아닙니다.

핸드셰이크, 유휴 상태 및 단방향 연결

handshake는 관련 연결이 수립되는 단계에서 허용할 대기 시간을 설정합니다. 인증이나 핸드셰이크가 느린 네트워크에서는 값을 너무 짧게 설정하면 계속 재시도할 수 있습니다. connIdle은 연결에서 데이터가 오가지 않을 때의 유휴 제한을 나타냅니다. 실제 동작은 프로토콜, 애플리케이션의 연결 유지 신호, 중간 네트워크 장비의 영향을 받습니다. 코어에서 긴 유휴 시간을 허용해도 라우터나 원격 서비스가 먼저 연결을 닫을 수 있으므로 이 값만 늘린다고 장시간 연결이 보장되지는 않습니다.

uplinkOnly와 downlinkOnly는 한쪽 데이터 흐름이 끝난 뒤 남은 연결을 얼마나 더 기다릴지 설정합니다. 업로드·다운로드 속도 제한이 아닙니다. 여기서 상향·하향은 연결 처리 방향을 뜻하므로 속도 측정 화면의 의미와 혼동하지 마세요. 일부 애플리케이션은 먼저 전송을 끝내고 서버 응답을 기다립니다. 남은 대기 시간을 너무 짧게 설정하면 응답을 받기 전에 연결이 닫힐 수 있습니다. 이런 문제를 분석할 때는 페이지에 시간 초과가 표시되는지만 보지 말고 연결에서 절반 닫기가 발생한 시점도 확인해야 합니다.

통계 설정 및 클라이언트 표시

일부 정책은 사용자 또는 시스템 수준의 트래픽 통계를 제어할 수 있지만, 정책 필드를 활성화하는 것만으로 통계 기능 전체가 작동하지 않을 수 있습니다. 코어에 통계 모듈과 관리 인터페이스가 필요하거나 클라이언트가 데이터를 읽어야 할 수 있습니다. 사용자 통계는 프로토콜의 사용자 ID에 의존하기도 합니다. 화면에 트래픽이 표시된다고 모든 통계가 policy에서 나온 것은 아닙니다. 화면에 데이터가 없다고 연결이 코어를 통과하지 않았다고 단정할 수도 없습니다. 통계 문제는 연결 문제와 분리해 진단하고, 먼저 요청이 정상 처리되는지 확인하세요.

원격 관리가 필요하지 않다면 통계를 표시하려고 관리용 리스닝을 임의로 개방하지 마세요. 클라이언트가 내부 인터페이스를 이미 관리하고 있다면 기본 접근 범위를 유지하고 사용자 지정 설정이 관련 인바운드를 덮어쓰지 않는지 확인하세요. 통계 항목, 메모리 관련 옵션, 기본 정책은 코어마다 다릅니다. 확장 필드가 많이 포함된 정책을 복사하면 시작 오류 위험만 커질 수 있습니다. 각 항목의 용도를 하나씩 확인하고 필요하지 않거나 설명할 수 없는 설정은 제거하세요.

회귀 테스트에는 짧은 요청, 지속 전송, 유휴 상태 후 복구를 최소한 포함하세요. 일반적인 웹 페이지에 한 번 접속하는 것만으로 장시간 연결에 적합한 정책인지 확인할 수 없습니다. 변경 전후 필드 값과 실제 대기 과정, 오류 유형을 기록하세요. 안정적인 개선이 없으면 기본값으로 되돌립니다. 핸드셰이크와 유휴 시간, 클라이언트 옵션을 한꺼번에 바꾸는 것보다 범위를 좁혀 조정해야 결과를 검증하기 쉽습니다.

클라이언트 생성 설정 및 다시 불러오기 절차

그래픽 클라이언트에 저장된 설정이 코어가 최종적으로 읽는 JSON과 항상 일치하는 것은 아닙니다. 구독 그룹, 노드 메모, 화면 테마, 시스템 프록시, 자동 시작 등은 보통 클라이언트 계층의 설정입니다. 인바운드, 아웃바운드, 라우팅, DNS는 클라이언트가 이런 설정을 바탕으로 생성할 수 있습니다. 실행 디렉터리의 파일을 직접 편집하면 다음 시작이나 노드 전환 때 변경 내용이 덮어써질 수 있습니다. 수정 전에 설정이 어디에서 생성되는지 확인해야 클라이언트 화면에서 조정할지, 클라이언트가 제공하는 사용자 지정 설정 입력란을 사용할지 결정할 수 있습니다.

구독, 노드 및 전체 설정의 차이

구독에는 여러 연결 항목과 관련 정보가 포함되는 경우가 많으며 클라이언트가 이를 읽고 저장해 아웃바운드를 생성합니다. 노드 공유 정보는 보통 원격 연결 하나를 설명하며 로컬 인바운드와 전체 라우팅 설정까지 포함하지는 않습니다. 전체 코어 설정은 실행에 필요한 여러 부분을 정의해야 합니다. 노드 문자열을 config.json으로 저장한다고 JSON 설정이 자동으로 만들어지지는 않습니다. dns만 있는 조각을 전체 설정으로 가져오면 필요한 인바운드와 아웃바운드가 없을 수도 있습니다. 내용 유형에 맞는 가져오기 기능을 사용하세요.

v2rayN은 데스크톱에서 노드 관리와 설정 확인에 적합합니다. Android에서는 필요한 코어에 따라 v2rayNG를 우선 선택하고, V2Fly 설정을 사용해야 할 때 v2flyNG를 고려하세요. 세 클라이언트의 메뉴 이름과 지원 필드가 완전히 같다고 볼 수는 없습니다. 특정 클라이언트의 화면 경로를 코어 공통 규격처럼 취급하지 마세요. 다운로드 및 플랫폼 선택은 클라이언트 페이지에서, 처음 가져오기부터 연결 확인까지의 절차는 시작 가이드에서 확인하세요.

변경 전에 복구 가능한 상태 저장

먼저 현재 클라이언트와 운영체제, 사용 중인 코어, 트래픽 처리 방식, 재현 가능한 문제를 기록하세요. 기존 설정을 저장하거나 필요한 설정을 내보내고, 구독 주소와 인증 정보는 민감한 자료로 별도 보관하세요. 진단용 백업을 공개된 위치에 함부로 올리지 마세요. DNS 규칙 하나만 테스트한다면 노드와 라우팅은 그대로 두세요. 코어를 바꿀 때는 구독 업데이트와 전송 설정 변경을 동시에 하지 않는 것이 좋습니다. 한 번에 한 가지씩 바꾸면 실패 원인을 명확히 파악하고 쉽게 되돌릴 수 있습니다.

사용자 지정 설정을 쓸 때는 클라이언트가 내부 인바운드, 통계 설정, 라우팅을 계속 추가하는지 확인하세요. 일부 입력란은 전체 설정을 읽지만 다른 입력란은 특정 필드만 덮어씁니다. 두 방식의 병합 동작은 다릅니다. 편집 창의 일부 텍스트보다 코어에 실제로 전달되는 최종 실행 설정을 확인하는 것이 가장 확실합니다. 내보내기 기능에서 노드 정보만 제공한다면 이를 전체 실행 설정의 스냅샷으로 볼 수 없습니다. 현재 모드와 전역 설정도 함께 확인하세요.

저장, 불러오기 및 새 연결

1. JSON 문법과 태그 참조를 확인하고 계획한 설정 섹션만 변경했는지 검토하세요.
2. 클라이언트에 설정을 저장한 뒤 제공되는 다시 불러오기, 서비스 재시작 또는 재연결 기능을 사용하세요.
3. 시작 로그를 확인해 새 코어 프로세스가 설정을 불러왔는지, 리스닝 포트 사용 오류는 없는지 살펴보세요.
4. 새 테스트 연결을 만들고 요청이 예상한 인바운드로 들어와 올바른 아웃바운드를 선택하는지 확인하세요.
5. 결과가 예상과 다르면 직전 설정으로 되돌리고 기본 설정이 여전히 작동하는지 확인한 다음 차이를 분석하세요.

저장했다고 해서 설정을 불러온 것은 아니며, 불러온 뒤에도 기존 연결이 새 출구로 즉시 이동하지 않을 수 있습니다. 브라우저와 다른 애플리케이션은 기존 연결을 재사용할 수 있고 DNS 캐시가 남아 있을 수도 있습니다. 라우팅 변경을 테스트할 때는 기존 페이지에서 계속 작업하지 말고 새 요청 세션을 만드세요. 필요하다면 애플리케이션을 종료한 뒤 다시 시도합니다. 클라이언트 로그에 이번 테스트 시각과 일치하는 이벤트가 표시되는지 확인하세요. 그렇지 않으면 이전 연결의 기록일 수 있습니다.

Windows, macOS, Linux는 시스템 프록시를 따르는 방식과 백그라운드 실행 방식이 다릅니다. 버튼 이름이 같다는 이유만으로 동작도 같다고 판단해서는 안 됩니다. Linux 데스크톱의 자동 시작은 데스크톱 세션과 설치 방식의 영향을 받을 수 있습니다. 자세한 내용은 Linux 설치 및 자동 시작 노트를 참고하세요. Android의 시스템 VPN 권한, 애플리케이션별 분기, 백그라운드 제한도 접속 환경에 해당하므로 JSON 라우팅과 별도로 확인해야 합니다.

마지막으로 복구 경로를 확인하세요. 사용할 수 있는 노드와 기존 모드, 수정 전 설정을 보존해 진단 변경 사항이 일상 설정을 대신하지 않도록 합니다. 클라이언트 업데이트 후 특정 필드를 더 이상 허용하지 않는다면 생성 설정의 기본 템플릿으로 복구한 뒤 코어 지원 여부를 확인하세요. 설명하기 어려운 설정 파일을 만들려고 오래된 필드를 계속 덧붙이지 마세요. 사용자 지정 필드의 목적을 하나씩 설명할 수 있어야 이후에도 관리하기 쉽습니다.

설정 검증 및 문제 진단 순서

설정 문제는 데이터 흐름을 따라 단계별로 확인하세요. 먼저 파일이 불러와지는지, 인바운드가 요청을 받는지, 라우팅이 올바른 아웃바운드를 선택하는지 확인한 다음 DNS 조회, 핸드셰이크, 목적지 응답을 점검합니다. 한 번에 하나씩 검증하세요. 노드, DNS, 라우팅, 시간 제한을 한꺼번에 바꾸면 우연히 연결이 복구되어도 어떤 변경이 효과가 있었는지 알기 어렵습니다. 안정적인 테스트 대상과 동일한 접속 방식, 관련 로그를 유지해야 변경 전후의 실제 차이를 비교할 수 있습니다.

시작 실패: 첫 오류부터 확인

파일을 불러오지 못하면 뒤이어 나타나는 연쇄 종료 메시지보다 가장 먼저 나온 명확한 오류를 확인하세요. 괄호나 쉼표 오류는 JSON 문법 문제입니다. 알 수 없는 프로토콜, 잘못된 필드 유형, 필수 매개변수 누락은 설정 의미 문제입니다. 주소 사용 중, 권한 부족, 파일 경로 접근 불가는 실행 환경 문제입니다. 문제 유형에 따라 조치할 위치가 다릅니다. 편집기에서 문법이 올바르게 표시되어도 실제로 선택한 코어에서 검증해야 합니다. 다른 코어의 성공 결과로 대신할 수 없습니다.

오류가 특정 설정 섹션을 가리키면 해당 섹션에서 가장 최근에 변경한 내용을 먼저 되돌리세요. 설정을 합친 파일이라면 최상위 키가 중복되거나 배열이 잘못 교체되거나 숫자가 문자열로 바뀌지 않았는지 확인합니다. 포트 사용 중 오류는 클라이언트가 여러 개 실행 중인지 확인하고 기존 인스턴스를 종료한 뒤 다시 시도하세요. 권한 문제는 필요한 작업과 자원을 구체적으로 확인해야 합니다. 가상 네트워크 인터페이스 생성 권한은 높은 번호의 로컬 포트를 리스닝하는 권한과 다릅니다. 일반적인 설정 오류만으로 모든 작업을 계속 높은 권한으로 실행하지 마세요.

시작되지만 연결되지 않을 때: 범위를 좁혀 확인

인바운드에 요청이 전혀 없다면 애플리케이션 프록시 주소와 포트, 유형, 시스템 프록시 적용 여부를 확인하세요. 인바운드에 요청이 있지만 출구가 잘못되었다면 규칙 순서와 대상에 도메인 정보가 포함되는지, 태그 참조가 올바른지 살펴보세요. 올바른 아웃바운드를 선택했는데 연결되지 않으면 DNS 조회, 원격 접근성, 인증, 전송 매개변수를 확인합니다. 특정 대상만 실패한다면 대상 서비스 자체의 상태도 고려하세요. 이를 근거로 전체 설정이 잘못되었다고 단정하지 마세요. 내부망 리소스에 문제가 생기면 기본 규칙이 부적절한 출구로 요청을 보내는지 먼저 확인합니다.

로그 수준 및 최소 재현 사례

문제 진단 중에는 로그 상세 수준을 일시적으로 높여 인바운드, 라우팅, 연결 오류를 확인할 수 있습니다. 로그에 대상 도메인과 주소, 사용 내역이 포함될 수 있으므로 수집 범위를 제한하고 문제 해결 후 평소 수준으로 되돌리세요. 로그를 공유하기 전에는 민감한 연결 정보를 숨기고 오류 설명에 필요한 데이터만 남기세요. 전체 구독이나 인증 항목을 문의 글에 붙여 넣지 마세요. 대부분의 설정 문제는 필드 구조와 오류 유형, 필요한 범위에서 정리한 대상 정보만으로 설명할 수 있습니다.

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

이 조각은 로그 수준만 변경합니다. 실제 로그 위치는 클라이언트가 관리할 수 있으므로 파일 경로가 지정되지 않았다면 클라이언트의 로그 화면에서 확인하세요. 상세 수준을 높인 뒤 문제가 발생한 대상을 한 번 요청하고 주변 로그를 기록한 다음 원래 수준으로 복구합니다. 특정 오류 하나를 찾으려고 모든 애플리케이션 활동을 장시간 수집하지 마세요. 정보 수준 로그로 문제 단계를 구분하기 어렵다면 코어가 지원하는지 확인한 뒤 더 상세한 수준을 사용하고 수집 시간을 줄이세요.

최소 재현은 이 페이지 첫 장의 직접 연결 기본 설정으로 시작해 로컬 인바운드와 일반 네트워크가 작동하는지 확인한 다음 실제 프록시 아웃바운드를 복구하는 방식으로 진행할 수 있습니다. 직접 연결 기본 설정이 작동해도 프록시 경로가 정상이라는 뜻은 아닙니다. 일부 로컬 접속 문제만 제외할 수 있습니다. 이후 라우팅, DNS, 정책을 순서대로 복구하고 각 단계에서 설정을 다시 불러온 뒤 새 연결을 만드세요. 직접 연결 테스트가 적절하지 않은 서비스라면 접근 경로를 억지로 바꾸지 말고 직접 관리하는 테스트 대상을 사용해 같은 설정 단계를 확인하세요.

자주 묻는 질문 및 참고 자료

이 페이지에서는 설정 항목과 계층별 진단을 다룹니다. 처음 설정할 때는 시작 가이드를 따라 진행하고, 프로토콜 및 생태계 용어는 용어 설명에서 확인하세요. 문제를 해결한 뒤에는 어떤 설정 섹션을 수정했는지, 무엇을 확인했는지, 다시 불러와야 하는지, 어떻게 복구할 수 있는지 간단히 기록해 두세요. 설명과 재현, 복구가 가능한 설정이 매개변수를 무작정 늘리는 것보다 관리하기 쉽습니다.