V2Ray 설정 파일 구조 완벽 해설: inbounds·outbounds·routing의 역할 구분

먼저 설정 파일의 트래픽 경로부터 이해하기

V2Ray 설정 파일은 JSON 객체이며, 최상위 필드는 로그, 도메인 확인, 인바운드, 아웃바운드, 라우팅을 각각 제어합니다. 핵심은 파일을 위에서 아래로 한 줄씩 실행하지 않습니다. 시작할 때 전체 설정을 읽고 수신 포트, 아웃바운드 처리기, 라우팅 규칙을 구성합니다. 설정은 텍스트 줄 번호가 아니라 데이터 흐름을 따라 읽어야 합니다.

애플리케이션은 먼저 로컬 SOCKS 또는 HTTP 프록시 포트로 요청을 전달하며, 이는 설정의 inbounds에 해당합니다. 인바운드가 대상 주소를 확인하면 연결을 라우팅 모듈로 넘기고, routing은 규칙 순서에 따라 아웃바운드 태그를 선택합니다. 마지막으로 outbounds에서 해당 태그의 처리기가 원격 연결을 만들거나 대상에 직접 접속합니다. dns는 확인이 필요한 도메인에 결과를 제공하고, log는 이 과정의 경고와 오류를 기록합니다.

아래 예시는 로컬 SOCKS 포트 10808을 사용하고, VMess 프록시 아웃바운드와 freedom 직접 연결 아웃바운드를 정의합니다. 사설 주소는 먼저 직접 연결로 보내고, 나머지 TCP 및 UDP 트래픽은 프록시 아웃바운드로 전달합니다. 예시 도메인인 example.com은 구조를 보여 주기 위한 예약 도메인일 뿐이므로 실제 서버 설정으로 바로 사용할 수 없습니다.

{
  "log": {
    "loglevel": "warning"
  },
  "dns": {
    "servers": [
      "localhost",
      "1.1.1.1"
    ]
  },
  "inbounds": [
    {
      "tag": "socks-in",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "auth": "noauth",
        "udp": true
      },
      "sniffing": {
        "enabled": true,
        "destOverride": [
          "http",
          "tls"
        ]
      }
    }
  ],
  "outbounds": [
    {
      "tag": "proxy",
      "protocol": "vmess",
      "settings": {
        "vnext": [
          {
            "address": "server.example.com",
            "port": 443,
            "users": [
              {
                "id": "11111111-2222-4333-8444-555555555555",
                "security": "auto"
              }
            ]
          }
        ]
      },
      "streamSettings": {
        "network": "tcp",
        "security": "none"
      }
    },
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    }
  ],
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": [
          "geoip:private"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "proxy"
      }
    ]
  }
}

inbounds: 트래픽을 핵심에 전달할 주체 정의

settings와 sniffing은 각각 무엇을 제어할까

• tag는 인바운드의 내부 식별자이며, 라우팅 규칙에서 inboundTag를 사용해 트래픽 출처를 구분할 수 있습니다.
• listen: 127.0.0.1은 현재 기기에서만 사용할 로컬 프록시 진입점에 적합합니다.
• port가 충돌하면 로그에 대개 수신 실패 또는 주소가 이미 사용 중이라는 메시지가 표시됩니다.
• udp: true는 SOCKS 인바운드가 UDP 요청을 처리할 수 있음을 뜻하지만, 실제 전송 가능 여부는 아웃바운드 프로토콜과 서버 설정에도 좌우됩니다.

outbounds: 트래픽이 빠져나갈 경로 정의

프로토콜 매개변수와 전송 매개변수는 서로 다른 계층입니다

VMess를 예로 들면 settings의 vnext는 원격 서버와 사용자를 설명하고, streamSettings는 하위 네트워크와 보안 방식을 설명합니다. 서버 포트는 올바르지만 전송 방식이 다르면 TCP 연결이 이미 성립했더라도 프로토콜 핸드셰이크는 실패할 수 있습니다. 따라서 연결 문제를 점검할 때 주소, 포트, 사용자 식별자만 확인해서는 안 됩니다.

routing: 규칙에 따라 인바운드 연결을 아웃바운드로 전달

1. 규칙의 type이 핵심에서 지원하는 유형인지 확인하고, 일반적인 필드 매칭 규칙에는 field를 사용합니다.
2. 조건이 도메인, IP, 포트, 네트워크 유형, 인바운드 태그 중 어느 범주에 속하는지 확인하세요.
3. 위에서 아래로 확인하며 처음으로 일치할 가능성이 있는 규칙을 찾으세요. 예상한 규칙만 살펴봐서는 안 됩니다.
4. outboundTag가 outbounds의 tag 중 하나와 대소문자까지 완전히 일치하는지 확인하세요.
5. 일시적으로 로그 수준을 높이고 핵심을 다시 시작한 뒤, 로그에서 실제 대상과 오류가 발생한 단계를 확인하세요.

domainStrategy는 라우팅을 위해 도메인을 확인할 시점을 결정합니다

dns와 log: 도메인 확인 및 장애 진단 보조

dns는 핵심이 사용할 DNS 서버와 관련 확인 정책을 정의합니다. 예시에는 localhost와 1.1.1.1을 차례로 작성해 서버 목록 구조를 보여 줍니다. 실제 설정에서는 네트워크 환경과 라우팅 대상에 맞는 확인 방식을 선택하고, 조회가 의도한 아웃바운드로 처리되는지도 살펴봐야 합니다.

애플리케이션 자체의 도메인 확인, 운영체제의 도메인 확인, V2Ray 내장 DNS를 구분해야 합니다. 애플리케이션이 먼저 도메인을 확인하고 SOCKS 인바운드에 IP만 전달하면 핵심이 같은 도메인 조회를 다시 수행하지 않을 수 있습니다. sniffing을 활성화하면 도메인을 복원할 가능성이 있지만, 성공 여부는 프로토콜 트래픽에서 해당 정보를 추출할 수 있는지에 달려 있습니다. 도메인 분기 문제를 점검할 때는 먼저 핵심이 실제로 받은 값이 도메인인지 IP인지 확인하세요.

loglevel은 출력 상세도를 제어합니다. 평상시에는 warning을 사용해 경고와 오류를 남길 수 있고, 요청 경로를 확인해야 할 때는 일시적으로 info 또는 debug로 바꿀 수 있습니다. 상세 로그는 기록량이 늘어나므로 문제가 해결된 뒤 계속 유지하지 않는 것이 좋습니다.

• 시작 후 수신 포트가 전혀 열리지 않음: JSON 문법, 필드 유형, 포트 사용 여부를 먼저 확인하세요.
• 로컬 포트에는 연결되지만 원격 연결이 실패함: outbounds의 서버, 프로토콜, 전송 매개변수를 확인하세요.
• 프록시는 작동하지만 트래픽 분기가 잘못됨: routing 순서, 대상 형식, outboundTag를 확인하세요.
• 도메인은 실패하지만 IP에는 접속 가능함: DNS 응답, 확인 경로, 도메인 전략을 점검하세요.
• UDP 애플리케이션만 이상함: 인바운드에서 UDP를 허용하는지 확인하고, 아웃바운드와 서버의 UDP 지원 여부를 점검하세요.

클라이언트에서 설정 생성부터 수동 점검까지

v2rayN, v2rayNG, v2flyNG는 그래픽 인터페이스의 서버 및 라우팅 옵션을 바탕으로 핵심 설정을 생성합니다. 구독 주소나 공유 링크는 주로 단일 서버에 필요한 프로토콜 매개변수를 제공하며, 클라이언트는 여기에 로컬 인바운드, 로그, DNS, 라우팅 내용을 추가합니다. 따라서 공유 링크의 필드 구성이 핵심에 전달되는 최종 JSON 전체와 일치하지 않는 경우가 많습니다.

그래픽 클라이언트를 사용할 때는 실행 중 생성된 파일을 장기적인 설정 원본으로 삼아 직접 수정하지 않는 것이 좋습니다. 클라이언트가 핵심을 다시 시작하거나 서버를 전환하거나 설정을 갱신하면 생성 파일이 덮어써질 수 있습니다. 더 안전한 방법은 먼저 인터페이스에서 해당 옵션을 변경한 뒤 로그나 생성 결과로 필드를 확인하는 것입니다. 독립 설정을 관리해야 한다면 별도 파일로 관리하고, 변경할 때마다 문법 검사와 시작 테스트를 수행하세요.

권장하는 최소 점검 순서

1. 먼저 JSON을 정상적으로 해석할 수 있는지 확인하고, 모든 객체·배열·쉼표·따옴표의 위치가 올바른지 점검하세요.
2. 핵심을 시작한 뒤 127.0.0.1:10808이 이미 수신 중인지 확인하세요.
3. 일단 명확한 프록시 아웃바운드 하나와 직접 연결 아웃바운드 하나만 남겨 변수의 수를 줄이세요.
4. 두 개의 routing 규칙으로 사설 주소는 직접 연결되고 나머지 트래픽은 프록시로 가는지 확인하세요.
5. 기본 연결이 성립한 뒤 도메인 분류, 포트 조건, 추가 아웃바운드를 하나씩 추가하세요.
6. 한 번에 서로 관련된 필드 한 묶음만 변경하고, 다시 시작한 직후 해당 로그를 확인하세요.

V2Ray 설정을 이해하는 핵심은 필드를 연결 경로로 되돌려 보는 것입니다. inbounds는 수신하고, routing은 선택하며, outbounds는 전송합니다. dns는 도메인 매칭과 연결에 필요한 확인 결과를 제공하고, log는 각 단계의 진단 단서를 남깁니다. 문제가 생기면 이 다섯 경계를 따라 범위를 단계적으로 좁히는 편이 프로토콜·포트·DNS·라우팅을 동시에 수정하는 것보다 검증 가능한 결론에 더 쉽게 도달할 수 있습니다.