V2Ray 설정 파일 JSON 구조 해설: inbounds·outbounds·routing 한눈에 보기

먼저 구분하기: 클라이언트 설정, 구독, 커널 설정

v2rayN은 노드, 구독, 라우팅, 커널 실행을 관리하는 데스크톱 클라이언트입니다. 실제로 트래픽을 받고 연결을 만드는 것은 커널입니다. 클라이언트에 저장된 UI 환경설정, 구독 주소, 그룹 정보는 커널이 시작할 때 읽는 JSON 설정과 다릅니다. 클라이언트가 생성한 임시 설정을 직접 수정하면 노드 전환, 구독 업데이트 또는 커널 재시작 후 변경 사항이 덮어써질 수 있습니다.

이 글에서는 V2Ray에서 흔히 사용하는 기존 JSON 설정 구조를 다룹니다. V2Ray의 여러 설정 형식과 Xray 확장 필드는 파일 확장자만 보고 서로 혼용할 수 없습니다. 특히 VLESS, 전송 계층, 보안 계층 관련 매개변수는 실행 중인 커널과 해당 버전의 문서를 기준으로 확인하세요. 모두 JSON 형식이라고 해서 필드까지 완전히 호환되는 것은 아닙니다.

v2rayN에서는 먼저 ‘설정’ → ‘매개변수 설정’에서 로컬 리스닝 관련 설정을 확인한 다음, ‘설정’ → ‘라우팅 설정’에서 분기 규칙을 살펴보세요. 버전에 따라 메뉴 이름이 달라질 수 있으므로 실제 메뉴를 기준으로 확인해야 합니다. 커널 이름, 실행 매개변수, 설정 파일 위치는 시작 로그에서 확인하는 것이 좋습니다. 구독 파일을 실행에 필요한 전체 설정으로 착각하지 마세요.

트래픽 흐름: inbounds가 받고, routing이 선택하고, outbounds가 연결합니다

inbounds는 커널이 어디에서 어떤 프로토콜로 요청을 받을지 정의하는 인바운드 배열입니다. 예를 들어 앱이 로컬 127.0.0.1:10808의 SOCKS 서비스에 연결해야 해당 인바운드로 요청이 들어옵니다. 커널을 실행하는 것만으로 모든 프로그램이 자동으로 커널을 사용하는 것은 아닙니다. 시스템 프록시, 앱별 프록시, TUN은 서로 다른 연결 방식입니다.

outbounds는 원격 프록시, 직결, 차단 등의 아웃바운드를 담는 배열입니다. routing은 도메인, IP, 포트, 인바운드 태그 등의 조건에 따라 사용할 아웃바운드를 선택합니다. tag는 설정 내부에서 사용하는 식별자입니다. 프로토콜 이름이 아니며, 같은 이름의 아웃바운드를 자동으로 만들지도 않습니다.

• inboundTag: 어떤 인바운드에서 들어온 트래픽인지 지정합니다. 인바운드의 tag를 참조합니다.
• outboundTag: 규칙과 일치할 때 사용할 아웃바운드를 지정합니다. 실제 아웃바운드의 tag와 정확히 일치해야 합니다.
• 규칙은 순서대로 확인하며, 먼저 일치하는 규칙이 적용됩니다. 어떤 규칙에도 일치하지 않으면 일반적으로 outbounds 배열의 첫 번째 아웃바운드를 사용합니다.
• 한 규칙 안에서 도메인 목록의 여러 항목은 대체로 ‘하나라도 일치하면’ 조건을 충족합니다. 도메인과 포트처럼 서로 다른 조건 필드가 함께 있으면 모든 조건을 충족해야 합니다.

전체 예제: 로컬 SOCKS, 직결, 도메인 차단

아래는 구조를 이해하기 위한 기존 JSON 형식의 전체 예제입니다. 로컬에서만 SOCKS를 리스닝하고, example.com이라는 정확한 도메인은 차단하며, 해당 인바운드로 들어온 나머지 요청은 직결합니다. VMess 또는 VLESS 서버 매개변수는 포함하지 않으므로 웹페이지에 접속할 수 있더라도 로컬 인바운드와 직결 경로가 작동한다는 것만 확인할 수 있습니다.

{
  "log": {
    "loglevel": "warning"
  },
  "dns": {
    "servers": [
      "1.1.1.1"
    ]
  },
  "inbounds": [
    {
      "tag": "socks-local",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "auth": "noauth",
        "udp": true
      }
    }
  ],
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {}
    }
  ],
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": [
          "full:example.com"
        ],
        "outboundTag": "block"
      }
    ]
  }
}

JSON 객체에는 중괄호, 배열에는 대괄호를 사용하고 문자열은 영문 큰따옴표로 감쌉니다. 파서 간 차이를 줄이기 위해 예제에는 주석이나 마지막 쉼표를 넣지 않았습니다. 문법이 올바른 것은 첫 단계일 뿐입니다. 필드 이름과 자료형, 프로토콜 매개변수는 여전히 커널에서 검증해야 합니다.

인바운드와 아웃바운드: 리스닝 주소는 서버 주소가 아닙니다

인바운드의 listen은 로컬에서 바인딩할 주소입니다. 원격 프록시 서버 주소는 해당 아웃바운드의 프로토콜 설정에 입력합니다. 서버 도메인을 로컬 리스닝 주소에 넣어도 프록시 연결이 만들어지지 않으며, 오히려 인바운드 바인딩이 실패할 수 있습니다. 127.0.0.1은 로컬에서만 접속할 수 있습니다. 0.0.0.0으로 변경하면 모든 IPv4 네트워크 인터페이스에서 접속할 수 있으므로 인증, 방화벽, LAN 접근 범위도 함께 검토해야 합니다.

udp: true는 SOCKS 인바운드에서 UDP 전달을 허용한다는 뜻이지, 모든 앱의 UDP 트래픽이 자동으로 처리된다는 뜻은 아닙니다. 앱이 SOCKS5 UDP ASSOCIATE를 지원해야 하며, 이후 아웃바운드와 네트워크 경로도 UDP를 지원해야 합니다. 시스템에 HTTP 프록시만 설정해도 UDP 요청이 이 SOCKS 인바운드로 자동 전달되지는 않습니다.

VMess 또는 VLESS 아웃바운드를 추가하려면 서버 주소, 포트, 사용자 식별자, 호환되는 전송 설정이 필요합니다. VMess는 일반적으로 settings.vnext 구조를 사용하며, VLESS에도 사용자와 서버를 지정하는 구조가 있지만 인증 방식은 서로 다릅니다. 따라서 protocol 문자열만 바꾸면 안 됩니다. TLS를 사용한다면 서버 이름도 확인하세요. 서버 포트가 443이라고 해서 설정에서 TLS가 반드시 활성화된 것은 아닙니다.

• 원격 노드 정보는 서비스 제공업체나 유효한 구독에서 확인하세요. 연결 실패만으로 사용자 식별자를 추측하지 마세요.
• 커널이 특정 프로토콜을 지원하더라도 해당 프로토콜의 모든 최신 전송 방식과 보안 확장까지 지원하는 것은 아닙니다.
• v2rayNG는 Xray 커널을, v2flyNG는 v2fly 커널을 사용합니다. 노드를 옮긴 뒤에도 매개변수 호환성을 확인해야 합니다.

라우팅 규칙: 순서, 도메인 매칭, 기본 아웃바운드

예제의 full:example.com은 해당 도메인만 정확히 매칭하며 www.example.com은 자동으로 포함하지 않습니다. 도메인과 하위 도메인을 함께 매칭하려면 기존 라우팅 규칙에서 domain:example.com을 사용할 수 있습니다. 이 도메인 매칭은 URL 매칭과 다릅니다. 일반적으로 라우팅은 웹페이지 경로 /account를 기준으로 같은 웹사이트의 페이지를 구분할 수 없습니다.

domainStrategy: "AsIs"는 라우팅 단계에서 IP 규칙을 위해 도메인을 적극적으로 조회하지 않는다는 뜻입니다. 연결 과정 전체에서 DNS 조회가 전혀 일어나지 않는다는 의미는 아닙니다. 아웃바운드가 대상에 실제로 연결할 때는 여전히 DNS 조회가 필요할 수 있습니다. IPIfNonMatch를 사용하면 도메인 규칙에 일치하지 않은 뒤 IP를 조회해 다시 매칭을 시도할 수 있습니다. IPOnDemand를 사용하면 IP가 필요한 규칙을 만났을 때 조회가 발생할 수 있습니다.

규칙은 구체적인 조건부터 넓은 조건 순으로 배치해야 합니다. 첫 번째 규칙이 특정 인바운드의 모든 트래픽을 직결로 보내면 이후에 있는 같은 인바운드의 도메인 차단 규칙은 실행되지 않습니다. geoip:, geosite: 규칙을 쓸 때는 해당 데이터 파일을 사용할 수 있는지도 확인하세요. 데이터 파일이 없는 문제와 네트워크에 연결할 수 없는 문제는 서로 다릅니다.

DNS와 로그: 리졸버를 지정해도 모든 조회를 가로채는 것은 아닙니다

dns.servers는 커널 내장 DNS에서 사용할 상위 리졸버를 지정하며, 예제에서는 1.1.1.1을 사용합니다. 일반적인 IP 주소 형식은 암호화 DNS가 아니라 기존 DNS 조회를 의미하는 경우가 많습니다. 해당 리졸버에 연결할 수 있는지, DNS 쿼리가 어떤 경로로 나가는지는 네트워크와 관련 설정에도 영향을 받습니다. 이 필드만으로 DNS 조회 경로를 판단할 수는 없습니다.

앱이 먼저 운영체제 DNS로 IP를 조회한 뒤 IP 주소를 SOCKS에 전달할 수도 있습니다. 이 경우 커널은 원래 도메인이 아닌 IP를 받으므로 앞서 설정한 도메인 규칙이 일치하지 않을 수 있습니다. 스니핑은 지원되는 프로토콜에서 도메인을 식별하는 데 도움이 될 수 있지만, 모든 요청의 원래 도메인을 복원한다고 보장하지는 않습니다. 내장 DNS를 설정했다고 자동으로 사용할 수 있는 기능도 아닙니다.

1. 먼저 입력값을 확인하세요. 요청 로그에는 도메인과 IP 중 무엇이 표시되나요? SOCKS를 사용하는 앱에서 프록시 측 도메인 조회를 사용하도록 설정했나요?
2. 그다음 실패 단계를 구분하세요. 도메인 조회 실패, 연결 시간 초과, TLS 핸드셰이크 실패는 각각 다른 단계에서 발생합니다. 모두 DNS 문제로 단정할 수는 없습니다.
3. 로그 수준을 잠시 높이세요. loglevel을 warning에서 info 또는 debug로 변경하고 문제를 한 번 재현한 뒤 원래대로 돌리세요. 연결 세부 정보가 계속 대량으로 기록되지 않도록 주의해야 합니다.
4. 필요한 경우 로그 파일을 설정하세요.access와 error에 액세스 로그 및 오류 로그 경로를 지정할 수 있습니다. 대상 디렉터리가 존재해야 하며 실행 계정에 쓰기 권한이 있어야 합니다.

검증 순서: 문법부터 실제 트래픽까지 확인

예제를 config.json으로 저장한 뒤, 클라이언트가 사용 중인 설정을 덮어쓰지 말고 별도의 테스트 환경에서 먼저 검증하세요. 해당 명령을 지원하는 V2Ray에서는 아래와 같은 방법으로 설정을 검사할 수 있습니다. 배포 버전에 따라 명령줄 진입 방식이 다를 수 있습니다. 알 수 없는 명령이라는 메시지가 나오면 먼저 v2ray help를 실행해 현재 환경에서 지원하는 매개변수를 확인하세요.

v2ray test -c config.json

설정 검사에 통과해도 포트 바인딩이나 원격 연결이 성공하거나 라우팅이 예상대로 작동한다고 보장할 수는 없습니다. 커널을 시작한 뒤 프록시 프로토콜을 명시한 요청으로 검증하세요. 아래 명령은 curl이 설치된 환경에서 사용할 수 있습니다. Windows 터미널에서는 별칭 차이를 피하기 위해 curl.exe를 사용하세요.

curl --socks5-hostname 127.0.0.1:10808 --connect-timeout 10 https://example.com/

--socks5-hostname은 대상 도메인을 SOCKS 프록시에 전달하므로 이 예제의 도메인 규칙을 검증하는 데 적합합니다. 예상 결과는 요청한 웹페이지를 정상적으로 가져오지 못하는 것입니다. 로그에는 요청이 커널에 들어왔다는 내용이 표시되어야 합니다. 구체적인 오류 메시지는 커널과 curl 버전에 따라 달라지므로 오류 한 줄만 보고 어떤 규칙이 적용됐는지 판단하지 마세요.

1. 차단을 검증하세요. 전체 설정의 full:example.com 규칙을 유지하고 위 명령을 실행한 뒤 로그를 확인하세요.
2. 직결을 검증하세요. 테스트용 복사본에서 rules를 빈 배열 []로 바꾸고 커널을 다시 시작한 뒤 같은 요청을 실행하세요. 네트워크에서 대상에 접속할 수 있다면 첫 번째 직결 아웃바운드가 연결을 처리해야 합니다.
3. 인바운드를 확인하세요. 로그에 요청이 전혀 없다면 라우팅을 더 수정하지 말고 리스닝 주소, 포트, 앱 설정을 확인하세요.
4. 테스트 환경을 복구하세요. 별도로 실행한 테스트 커널을 종료하고 원래 설정을 복원한 뒤 클라이언트를 시작하세요. 여러 프로세스가 같은 포트를 사용하지 않도록 주의해야 합니다.

자주 묻는 질문: 시작은 되지만 라우팅이 달라지지 않습니다

설정을 읽을 때는 세 가지 질문을 순서대로 확인하세요. 앱이 예상한 인바운드로 들어왔는가, 요청이 예상한 규칙과 일치했는가, 선택된 아웃바운드에 올바른 매개변수가 있는가? DNS 조회, 라우팅, 연결을 각각 나눠 검증하면 여러 설정을 한꺼번에 바꾸는 것보다 원인을 찾기 쉽습니다.