V2Ray 설정 파일 가이드: 인바운드·아웃바운드·라우팅·DNS

JSON 구조 개요

설정 객체와 연결 경로

V2Ray 설정 파일의 최상위 요소는 JSON 객체입니다. 인바운드는 애플리케이션 연결을 받고, 아웃바운드는 연결을 내보냅니다. 라우팅은 연결을 어느 아웃바운드로 보낼지 선택하고, DNS는 설정 범위 내의 도메인 조회를 담당하며, 정책은 일부 연결 제한 및 통계 기능을 제어합니다. 이 모듈들은 파일에 적힌 순서대로 실행되는 스크립트가 아니라 커널이 읽어 구성하는 실행 구조입니다. 설정을 이해할 때는 특정 필드의 존재 여부만 확인하기보다 요청이 어떤 인바운드로 들어와 어떤 규칙에 일치하고 최종적으로 어느 아웃바운드로 전달되는지 추적해야 합니다.

GUI 클라이언트와 커널은 따로 이해해야 합니다. v2rayN, v2rayNG, v2flyNG는 노드 편집, 구독 관리, 프록시 전환 기능을 제공하지만 실제 연결은 내부의 커널이 처리합니다. 클라이언트의 한 옵션이 여러 JSON 필드를 생성할 수도 있고, 운영체제 설정만 바꿀 수도 있습니다. 시스템 프록시 전환은 대개 후자에 해당하므로 설정에 HTTP 인바운드가 있다고 해서 브라우저가 이를 사용한다고 볼 수는 없습니다. 먼저 로컬 SOCKS 인바운드와 직접 연결 아웃바운드로 구성된 기본 설정을 살펴보고 기본 연결 경로를 확인해 보겠습니다.

{
  "log": {
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "tag": "local-socks",
      "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": []
  }
}

자료형, 배열, 태그 참조

JSON은 필드별 자료형을 구분합니다. 이 예시에서 포트는 숫자, 스위치는 불리언, 태그와 주소는 문자열이며 여러 인바운드와 아웃바운드는 배열에 넣습니다. 문자열에는 큰따옴표를 사용해야 하고 배열의 마지막 요소 뒤에 쉼표를 붙이면 안 됩니다. 표준 JSON은 주석도 허용하지 않습니다. 편집기에서 파일이 열린다고 해서 커널이 파일을 파싱할 수 있는 것은 아닙니다. 문법 오류와 필드 의미 오류는 서로 다른 문제입니다. 괄호, 따옴표, 자료형을 먼저 확인한 뒤 프로토콜이 해당 설정을 지원하는지 살펴보면 단순한 문법 오류를 네트워크 문제로 오해하는 일을 줄일 수 있습니다.

태그는 모듈 간 연결에 사용됩니다. 라우팅의 아웃바운드 태그는 아웃바운드 객체의 태그와 정확히 일치해야 하며 대소문자가 다르면 참조가 실패할 수 있습니다. 태그는 짧고 명확하며 고유하게 지정하세요. 예를 들어 직접 연결, 차단, 원격 프록시에 각각 다른 이름을 사용할 수 있습니다. 배열에 표시된 순서만 보고 태그의 의미를 판단하지 마세요. 일반적으로 라우팅 규칙에 일치하지 않는 연결은 첫 번째 아웃바운드로 전달되므로 순서만 바꿔도 기본 동작이 달라질 수 있습니다. 코드 조각을 복사할 때는 참조와 대상이 함께 맞는지 확인하세요.

필드	주요 역할	주요 의존 항목
`inbounds`	애플리케이션 연결 수신	수신 주소, 포트, 인증 방식
`outbounds`	직접 연결, 프록시 또는 차단	프로토콜 및 전송 설정
`routing`	연결 목적지 선택	아웃바운드 태그, 규칙 순서
`dns`	커널의 도메인 조회	조회 정책, DNS 요청 경로
`policy`	연결 정책 및 통계 스위치	사용자 레벨, 통계 모듈

설정 조각 병합 및 변경 사항 저장

설정을 병합할 때 같은 최상위 필드는 하나만 남겨야 합니다. 기존 아웃바운드 배열에 객체를 추가하거나 수정하고, 같은 이름의 배열을 다시 만들지 마세요. 파서에 따라 중복 키 처리 방식이 달라 화면에는 저장된 것처럼 보여도 실제로는 뒤에 나온 내용만 읽힐 수 있습니다. 객체의 필드도 올바른 계층에 배치해야 합니다. 예를 들어 전송 설정은 해당 아웃바운드에 들어가야 하며 최상위 라우팅 객체에 둘 수 없습니다. 선택 필드는 우선 커널 기본값을 유지하고 실제로 필요한 동작에 대해서만 설정을 추가하세요. 문서에 나온 모든 매개변수를 파일에 넣을 필요는 없습니다.

데스크톱에서 일반 노드를 관리할 때는 v2rayN을 먼저 고려하되, 실행 중 자동 생성된 임시 설정을 직접 덮어쓰지는 마세요. 다음에 노드를 선택하거나 구독을 갱신하고 서비스를 다시 시작하면 클라이언트가 파일을 새로 생성할 수 있습니다. 사용자 지정 설정을 편집하는지, 클라이언트가 계속 저장하는 설정을 수정하는지 먼저 확인하세요. 테스트 전에 작동하는 설정을 백업하고 변경 필드와 예상 결과를 기록한 다음, 로그에서 실제 수신 포트와 선택된 아웃바운드를 확인하세요. 설정 구조를 안정화한 뒤 라우팅과 DNS를 추가하면 문제 범위를 좁히기 쉽습니다.

inbounds 인바운드 설정

수신 주소, 포트, 애플리케이션 연결

인바운드는 커널이 연결을 어디서 받고 어떤 프로토콜로 처리할지 정합니다. 일반적인 데스크톱 환경에서는 SOCKS와 HTTP가 대표적인 로컬 진입점입니다. 애플리케이션이 직접 이 진입점으로 요청을 보내거나 시스템 프록시, 가상 네트워크 인터페이스 같은 기능을 통해 요청이 전달되어야 합니다. 수신 주소를 루프백으로 설정하면 같은 기기에서만 연결할 수 있고, 모든 네트워크 인터페이스로 지정하면 LAN 기기에서도 접근할 수 있습니다. 후자는 방화벽, 인증, 네트워크 경계도 고려해야 합니다. 문제 해결을 위해 수신 범위를 무작정 넓히지 마세요. 공용 네트워크나 여러 사람이 사용하는 기기에서는 특히 주의해야 합니다.

포트는 애플리케이션에 입력한 프록시 포트와 일치해야 하며 다른 프로그램이 사용 중이어서는 안 됩니다. 포트 충돌은 대개 시작 로그에 바인딩 실패로 나타나므로 이때 노드를 바꿔도 해결되지 않습니다. 다른 프록시 클라이언트를 종료하거나 GUI 설정에서 로컬 포트를 바꾼 뒤 애플리케이션도 새 포트를 사용하도록 설정하세요. SOCKS와 HTTP 포트는 서로 바꿔 써도 되는 이름이 아닙니다. SOCKS 핸드셰이크만 받는 인바운드에 HTTP 요청을 보내면 연결 초기에 실패하며 브라우저에는 프록시 서버 오류만 표시될 수 있습니다.

{
  "inbounds": [
    {
      "tag": "local-socks",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "auth": "noauth",
        "udp": true
      }
    },
    {
      "tag": "local-http",
      "listen": "127.0.0.1",
      "port": 10809,
      "protocol": "http",
      "settings": {}
    }
  ]
}

인증, UDP, 도메인 정보

로컬에서 한 명이 사용하는 경우 인증 없는 SOCKS 인바운드를 자주 사용하지만, 그렇다고 모든 수신 주소에서 인증을 꺼도 된다는 뜻은 아닙니다. 다른 기기와 공유한다면 포트에 접근할 수 있는 대상, 클라이언트 프로토콜의 인증 지원 여부, 시스템 방화벽의 출발지 제한을 함께 검토해야 합니다. 인증은 보안의 한 요소일 뿐 적절한 수신 범위를 대신하지 못합니다. HTTP 인바운드는 SOCKS와 설정 구조가 다르므로 인증 필드를 그대로 복사하지 마세요. 현재 프로토콜과 커널이 지원하는 형식에 맞춰 설정하고 애플리케이션의 핸드셰이크도 각각 확인해야 합니다.

SOCKS 인바운드의 UDP 스위치는 해당 진입점에서 관련 UDP 요청을 처리할 수 있다는 뜻일 뿐, 전체 경로에서 UDP를 전송할 수 있음을 보장하지 않습니다. 애플리케이션이 SOCKS UDP 연결을 사용하는지, 원격 프로토콜과 서버가 이를 지원하는지, 아웃바운드가 허용하는지, 방화벽이 통과시키는지에 따라 결과가 달라집니다. 일반 브라우저에서 시스템 프록시를 테스트해도 모든 UDP 동작을 확인할 수는 없습니다. 웹페이지는 열리는데 특정 앱만 실패한다면 먼저 TCP 연결과 UDP 트래픽 중 어느 쪽이 실패했는지 구분한 다음 연결 방식을 바꿔야 하는지 판단하세요. 모든 문제를 노드 품질 탓으로 돌리지 마세요.

도메인을 어디서 조회하는지는 인바운드 방식과도 관련이 있습니다. 애플리케이션이 도메인을 SOCKS 인바운드에 전달할 수도 있고, 먼저 IP로 조회한 뒤 연결할 수도 있습니다. HTTP 프록시는 보통 대상 정보에서 도메인을 확인할 수 있습니다. 라우팅이 도메인 규칙에 의존하는데 인바운드에는 IP만 전달되면 예상과 다른 결과가 나올 수 있습니다. 프로토콜 스니핑으로 일부 식별 가능한 트래픽에서 대상 도메인 정보를 찾을 수 있지만 모든 트래픽에 이런 정보가 있는 것은 아닙니다. 스니핑은 대상 선택에도 영향을 줄 수 있으므로 필요성을 확인한 뒤 사용하세요. 도메인 규칙을 반드시 적용해 주는 만능 옵션은 아닙니다.

v2rayN TUN 모드와 시스템 프록시

v2rayN TUN 모드와 일반 로컬 인바운드는 서로 다른 문제를 해결합니다. 시스템 프록시는 시스템 설정을 따르는 애플리케이션에 프록시 진입점을 제공하고, TUN 모드는 가상 네트워크 인터페이스를 통해 지정된 라우팅 범위의 트래픽을 받습니다. 시스템 프록시를 사용하지 않는 앱에 적합할 수 있습니다. 가상 네트워크 인터페이스, 라우팅, 권한이 필요하므로 인바운드 배열에 필드 하나를 추가하는 것과는 다릅니다. 클라이언트의 연결 방식과 설정 생성 과정은 플랫폼에 따라 달라질 수 있으므로 수동 커널 설정과 클라이언트 TUN 설정을 별도로 확인하세요.

TUN으로 전환하기 전에 일반 프록시 경로가 작동하는지 확인하고 필요한 권한 및 다른 네트워크 프로그램과의 충돌 여부를 살펴보세요. 가상 네트워크 인터페이스나 프록시 프로세스가 여러 개 동시에 라우팅을 바꾸지 않도록 주된 트래픽 처리 방식은 하나만 사용하세요. 여러 방식이 겹치면 트래픽 순환이나 불분명한 DNS 경로가 생길 수 있습니다. TUN을 끈 뒤에도 접속이 이상하다면 시스템 프록시 설정이 남아 있는지, 가상 인터페이스가 복원됐는지, 앱에 프록시 설정이 캐시됐는지 확인하세요. 브라우저와 터미널의 연결 방식은 시스템 프록시가 작동하지 않을 때의 단계별 문제 해결에서 더 살펴볼 수 있습니다. 한 앱의 결과만으로 인바운드 전체가 작동하지 않는다고 판단하지 마세요.

outbounds 아웃바운드 설정

기본 아웃바운드와 연결 대상

아웃바운드는 요청이 커널을 빠져나가는 방식을 정의합니다. 직접 연결 아웃바운드는 기기에서 대상으로 바로 연결하고, 차단 아웃바운드는 일치한 요청을 종료하며, 프록시 아웃바운드는 원격 서버에 먼저 연결한 뒤 해당 서버가 대상에 연결합니다. 아웃바운드 배열에 이 객체들을 함께 넣고 라우팅으로 사용할 항목을 결정할 수 있습니다. 일반적으로 프록시 객체를 첫 번째에 두어 특별한 규칙에 일치하지 않는 연결이 프록시를 사용하게 합니다. 이 페이지 첫 장의 기본 설정은 로컬 연결을 확인하기 위해 의도적으로 직접 연결을 첫 번째에 둡니다. 예시를 복사하기 전에 기본 아웃바운드를 확인하세요. 연결 구조 테스트 설정을 원격 프록시 설정으로 착각하기 쉽습니다.

원격 주소, 원격 포트, 사용자 식별 정보, 전송 방식은 하나의 묶음으로 확인해야 합니다. 주소가 맞아도 포트가 틀리면 대개 서버에 연결할 수 없습니다. 네트워크 핸드셰이크가 성공해도 사용자 매개변수가 맞지 않으면 프로토콜 단계에서 거부될 수 있습니다. 사용자 매개변수가 맞더라도 전송 계층 설정이 다르면 예상한 연결을 만들 수 없습니다. 클라이언트에 표시되는 노드 이름은 별칭일 뿐 이 필드들이 일치한다는 증거가 아닙니다. 노드 편집 화면에서 서비스가 제공한 전체 매개변수를 확인하고, 가져온 뒤 전송 경로, 서비스 이름, 보안 설정이 빠지지 않았는지 특히 살펴보세요.

{
  "outbounds": [
    {
      "tag": "proxy",
      "protocol": "vless",
      "settings": {
        "vnext": [
          {
            "address": "example.com",
            "port": 443,
            "users": [
              {
                "id": "00000000-0000-0000-0000-000000000000",
                "encryption": "none",
                "level": 0
              }
            ]
          }
        ]
      },
      "streamSettings": {
        "network": "tcp",
        "security": "tls",
        "tlsSettings": {
          "serverName": "example.com"
        }
      }
    },
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {}
    }
  ]
}

VLESS 프로토콜, 전송, 보안 계층

VLESS 사용자 설정에 흔히 쓰이는 암호화 필드는 예시에 나온 값이지만, 그렇다고 연결 전체에 보안 계층이 없다는 뜻은 아닙니다. 프로토콜, 전송, 전송 보안은 서로 다른 요소입니다. 프로토콜은 프록시 요청의 표현 방식을, 전송은 해당 데이터를 전달하는 연결 유형을, 보안 계층은 연결을 보호하는 방법을 정합니다. 위 예시는 필드 간 관계를 보여주기 위해 TCP와 TLS를 사용하며 실제 서비스는 제공하지 않습니다. 서비스에서 다른 전송 또는 보안 방식을 사용한다면 해당 매개변수에 맞춰 수정하세요. 여러 방식의 필드를 한 객체에 모두 넣어서는 안 됩니다.

V2Ray 프로토콜 선택은 클라이언트 메뉴에서 이름을 자유롭게 바꾸는 문제가 아니라 서버 설정과 현재 커널의 지원 범위에 따라 결정됩니다. VMess, VLESS, Trojan, Shadowsocks는 인증 및 매개변수 구조가 다르므로 프로토콜 필드만 바꿔 서로 전환할 수 없습니다. VMess는 기기 시간 등 추가 조건도 확인해야 합니다. 각 프로토콜의 보안 설계를 설정 하나로 설명할 수는 없습니다. 기본적인 차이를 비교하려면 VMess와 VLESS의 차이를 참고한 뒤 실제 노드 매개변수에 맞춰 클라이언트에서 선택하세요.

TLS 서비스 이름은 인증서 및 서버 설정과 일치해야 합니다. 원격 연결 주소는 도메인이나 IP일 수 있지만 연결 주소와 인증서 검증에 사용하는 이름은 항상 같지는 않습니다. 브라우저에서 주소가 열린다고 해서 해당 주소가 프록시 프로토콜을 제공한다는 뜻도 아닙니다. 인증서 오류가 발생하면 시스템 시간, 이름, 인증서 체인을 확인하고 매개변수의 출처를 검토하세요. 오류를 없애려고 인증서 검증부터 끄지 마세요. 실제 설정 문제를 감추고 연결 검증도 약화합니다.

커널 호환성 및 매개변수 유지

Xray와 V2Fly는 일부 설정 개념을 공유하지만 모든 필드와 전송 방식, 확장 기능이 공통으로 지원되는 것은 아닙니다. v2rayN에서는 커널을 선택할 수 있고, v2rayNG와 v2flyNG는 서로 다른 커널 체계를 대상으로 하므로 전환 전에 노드가 사용하는 기능을 확인해야 합니다. 알 수 없는 필드, 미지원 프로토콜, 시작 실패가 발생하면 원격 주소를 반복해서 바꾸기보다 현재 커널의 지원 범위를 먼저 확인하세요. 생태계 관계는 Project V, V2Fly, Xray의 관계에서 살펴볼 수 있습니다.

기존 노드를 가져온 뒤에는 클라이언트가 인식하는 원래 매개변수를 우선 유지하고 항목별로 확인한 다음 사용자 설정을 추가하세요. 일부 화면은 전송 유형에 따라 관련 없는 입력 항목을 숨기지만, 숨겨졌다고 해서 이전에 입력한 값이 최종 설정에 반영된다는 뜻은 아닙니다. 생성된 설정의 아웃바운드 객체를 열어 매개변수가 올바른 계층에 들어갔는지 확인할 수 있습니다. 테스트할 때는 한 번에 설정 하나만 바꾸고 실패 로그와 시간을 기록하세요. 프로토콜, 전송 방식, 커널을 동시에 바꾸면 연결이 복구돼도 무엇이 원인이었는지 알기 어렵습니다.

routing 라우팅 규칙

규칙 순서와 일치 조건

라우팅은 연결 특성과 아웃바운드 태그를 연결합니다. 대표적인 조건으로 대상 도메인, 대상 IP, 대상 포트, 네트워크 유형, 인바운드 태그가 있습니다. 규칙은 대개 순서대로 검사하며 먼저 일치한 규칙이 연결 경로를 결정하므로 구체적인 예외를 포괄적인 규칙보다 앞에 배치해야 합니다. 어떤 규칙에도 일치하지 않으면 보통 첫 번째 아웃바운드로 연결됩니다. 더 많은 필드를 외우기보다 기본 아웃바운드와 규칙 순서를 이해하는 것이 중요합니다. 앞에 놓인 포괄적인 규칙 하나가 뒤의 세부 규칙을 무용지물로 만들 수 있습니다.

한 규칙 안에서 서로 다른 조건 유형은 보통 모두 충족해야 하며, 같은 유형의 배열에 여러 값을 넣으면 그중 하나에 일치하는 조건을 만들 수 있습니다. 예를 들어 인바운드 태그와 대상 도메인을 함께 지정하면 해당 인바운드로 들어온 요청 중 지정 도메인에 해당하는 요청만 처리합니다. 조건 중 하나만 일치해도 적용되는 것은 아닙니다. 서로 다른 목적을 한 객체에 억지로 넣지 마세요. 독립적인 상황을 표현해야 한다면 규칙을 나누세요. 규칙별 목적을 기록하고 로그에서 어떤 규칙이 아웃바운드를 바꿨는지 확인하기도 쉬워집니다.

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

도메인 규칙과 IP 규칙의 적용 범위

예시의 전체 도메인 일치는 지정한 이름만 대상으로 하고, 도메인 일치는 해당 도메인과 하위 도메인을 대상으로 합니다. 첫 번째 규칙에서 특정 하위 도메인을 차단하고 같은 기본 도메인에 속한 나머지 요청은 직접 연결하도록 해 구체적인 규칙을 우선하는 방법을 보여줍니다. 각 접두어의 의미를 일반 문자열처럼 추측하지 마세요. 특히 정규식은 범위가 지나치게 넓으면 관련 없는 도메인까지 일치해 유지 관리가 어려워질 수 있습니다. 먼저 정확한 도메인이나 도메인 접미사를 사용하고 복잡한 패턴이 꼭 필요할 때 정규식을 적용한 뒤 일치해야 할 대상과 일치하면 안 되는 대상을 모두 테스트하세요.

사설 IP 규칙은 실제로 라우팅 판단에 전달된 대상 IP에만 적용됩니다. 요청에 도메인이 들어왔지만 라우팅 정책이 도메인을 조회하지 않는다면 사설 IP 대역 규칙만으로 최종적으로 내부 서비스를 가리키는 도메인을 찾아내기 어려울 수 있습니다. 내부 도메인에는 명시적인 도메인 규칙을 추가하거나 필요에 따라 IP 판단에 관여하는 도메인 정책을 선택하세요. 도메인이 여러 주소를 반환하거나 IPv4와 IPv6 결과가 다를 수 있으므로 한 번 규칙에 일치했다고 모든 주소 유형과 조회 결과가 같은 경로를 사용한다고 볼 수는 없습니다.

라우팅의 도메인 정책과 직접 연결 아웃바운드의 도메인 정책은 서로 다른 위치에서 작동합니다. 라우팅 정책은 규칙 판단에 도메인 조회가 필요한지 제어하고, 직접 연결 아웃바운드 정책은 실제 직접 연결 시 주소 선택에 영향을 줍니다. 둘을 혼동하면 “조회 정책을 설정했는데 라우팅이 여전히 일치하지 않는다”고 오해할 수 있습니다. 필요할 때 조회하는 방식을 사용한다면 조회가 실행되는 조건과 현재 커널의 동작을 이해해 불필요한 DNS 요청을 줄이세요. 도메인으로 정확히 표현할 수 있는 규칙이라면 IP 일치를 위해 모든 요청을 강제로 조회할 필요는 없습니다.

규칙 리소스와 검증 가능한 변경

일부 라우팅 설정은 지리 정보나 도메인 분류 리소스를 참조합니다. 이런 참조가 작동하려면 클라이언트가 해당 리소스 파일과 이름, 업데이트 방식을 제공해야 합니다. JSON에 적는 것만으로 리소스가 자동으로 생기지는 않습니다. 리소스가 없으면 시작 오류가 발생할 수 있고 분류 내용이 다르면 일치 범위도 달라집니다. 이 페이지는 독립적으로 이해할 수 있도록 명확한 도메인과 IP 대역을 사용합니다. 외부 규칙을 가져오려면 필요한 리소스와 현재 커널에서의 사용 가능성을 먼저 확인한 뒤 생성된 설정의 실제 참조를 점검하세요. 규칙 제목만 보고 호환성을 판단하지 마세요.

라우팅을 바꾼 뒤에는 직접 연결되어야 하는 대상, 프록시를 사용해야 하는 대상, 차단되어야 하는 대상을 하나씩 골라 확인하고 연결 로그의 아웃바운드 태그도 확인하세요. 브라우저 캐시, 기존 장기 연결, 애플리케이션 자체 DNS 조회 때문에 결과가 바뀌지 않은 것처럼 보일 수 있습니다. 필요하면 기존 연결을 끊거나 앱을 다시 여세요. 전체 연결이 끊긴다면 마지막으로 추가한 포괄적인 규칙을 먼저 제거한 뒤 태그 철자와 기본 아웃바운드를 확인하세요. 규칙 개수가 많다고 좋은 설정은 아닙니다. 목적을 설명하고 테스트할 수 있는 적은 수의 규칙이 장기적으로 관리하기 쉽고 다른 클라이언트로 옮기기도 좋습니다.

dns 도메인 조회 설정

먼저 조회가 이루어지는 위치 확인

DNS 문제는 먼저 도메인 조회가 이루어지는 위치에 따라 구분해야 합니다. 애플리케이션은 시스템 리졸버를 사용하거나 자체 조회 기능을 사용할 수 있고, 로컬 프록시는 도메인을 받은 뒤 커널에서 조회할 수 있으며 원격 서버가 대상에 연결하면서 조회할 수도 있습니다. 이런 경로는 동시에 존재할 수 있습니다. 최상위 DNS 객체는 커널 DNS 기능을 사용하는 관련 요청만 제어하며 기기의 모든 프로그램이 보내는 도메인 조회를 자동으로 처리하지는 않습니다. 따라서 “DNS를 바꿨는데 브라우저 결과가 그대로다”라는 사실만으로 설정이 작동하지 않는다고 단정하지 마세요. 먼저 브라우저 요청이 해당 조회 경로를 사용하는지 확인해야 합니다.

연결 대상의 도메인 조회와 프록시 서버 주소의 조회도 구분해야 합니다. 아웃바운드는 원격 서버에 연결하기 전에 해당 서버의 주소를 알아야 합니다. 원격 주소가 도메인이라면 서비스 시작이나 연결 과정에서 먼저 DNS 조회가 필요할 수 있습니다. 그 뒤 웹사이트 도메인은 다른 위치에서 조회될 수도 있습니다. 아직 연결되지 않은 프록시를 통해 모든 DNS 요청을 보내려고 하면 시작 단계에서 의존성 순환이 발생할 수 있습니다. 조회 경로를 설계할 때는 원격 서비스 주소를 어떻게 조회할지, DNS 서버에 어떻게 연결할지, 프록시가 실패해도 필요한 조회 경로가 남는지 명확히 하세요. 익숙한 이름의 서버 하나만 고르는 것으로 끝나지 않습니다.

{
  "dns": {
    "hosts": {
      "service.example.com": "192.0.2.10"
    },
    "servers": [
      "localhost"
    ],
    "queryStrategy": "UseIP"
  }
}

고정 매핑, 서버, 주소 유형

이 설정 조각은 로컬 시스템 리졸버를 사용해 기본 동작을 구성하고 정적 도메인 매핑 구조를 보여줍니다. 예시 주소는 문서용이므로 실제 서비스 대상으로 사용할 수 없습니다. 실제 웹사이트를 테스트할 때는 이 설명용 매핑을 제거하세요. 정적 매핑은 대상 주소를 정확히 알고 있고 조회 결과를 고정해야 할 때 적합하지만, 자주 바뀌는 서비스의 조회를 계속 대신하기에는 적합하지 않습니다. 도메인 주소는 지역, 부하, 서비스 이전에 따라 달라질 수 있습니다. 오래된 주소 하나를 고정하면 연결이 실패하거나 정상적인 주소 선택 절차를 우회할 수 있습니다.

DNS 서버는 시스템 조회를 사용하거나 커널이 지원하는 다른 형식으로 지정할 수 있습니다. 형식마다 프로토콜, 포트, 요청 경로가 다를 수 있으므로 서버 주소만 보고 프록시 경유 여부를 판단할 수는 없습니다. HTTPS 기반 조회 서비스를 설정할 때는 서비스 도메인 자체의 조회 및 연결 경로도 고려해야 합니다. 일부 커널은 로컬 직접 조회와 라우팅이 처리할 수 있는 조회 방식을 구분합니다. 구체적인 동작은 사용하는 커널 문서를 확인하세요. 먼저 도달 가능성이 확인된 단순한 조회 방식으로 검증한 뒤 도메인별 서버 지정 규칙을 추가하면 여러 의존성이 한꺼번에 실패할 위험을 줄일 수 있습니다.

주소 유형 정책은 어떤 IP 유형을 조회하거나 받을지 결정하지만 IPv6 연결이 없는 네트워크에 갑자기 IPv6 기능을 추가하지는 않습니다. 한 주소 유형만 사용하도록 설정했는데 대상에 해당 레코드가 없으면 사용할 수 있는 주소를 얻지 못할 수도 있습니다. 일부 사이트의 연결이 느리거나 조회는 성공하지만 연결이 시간 초과된다면 조회된 주소 유형이 기기, 원격 서버, 최종 아웃바운드의 연결 능력과 맞는지 확인하세요. 설정을 바꾸기 전에 조회 결과를 기록하고 변경 후 같은 도메인을 다시 확인하세요. 한 번 접속에 성공했다는 이유만으로 모든 상황에서 특정 주소 유형이 더 적합하다고 단정하지 마세요.

도메인별 서버 지정, 캐시, 라우팅 연동

더 복잡한 DNS 설정에서는 일부 도메인에 조회 서버를 지정하고 대체 조회 동작을 제어할 수 있습니다. 지정한 서버의 응답이 실패하거나 비어 있거나 필터링된 경우 다른 서버로 계속 조회하는지에 따라 최종 결과와 속도가 달라집니다. 서버 객체에서 커널이 지원하는 필드와 대체 조회 로직을 함께 확인해야 합니다. “우선 사용”이 “이 서버만 사용”을 뜻하지는 않습니다. 주소 범위 제한을 설정했다면 정상적인 결과가 해당 범위 밖에 있을 수 있는지도 확인하세요. 조건에 맞지 않는다는 이유로 유효한 응답을 버릴 수 있습니다.

DNS와 라우팅은 설정 의도가 서로 맞아야 합니다. 내부 도메인을 직접 연결하려면 조회 경로에서 내부 주소를 얻을 수 있어야 하고 라우팅이 해당 이름이나 주소를 인식해야 합니다. 특정 연결을 원격 서버로 보내려는 경우에도 조회 위치가 서비스 동작을 방해하지 않는지 확인하세요. DNS 서버 선택, 라우팅 아웃바운드 선택, 브라우저의 보안 DNS 설정은 같은 스위치가 아닙니다. 각각 다른 계층에서 작동하므로 문제 해결 시 두 항목을 고정하고 나머지 하나만 변경한 뒤 로그와 애플리케이션 동작으로 결과를 확인할 수 있습니다.

캐시 때문에 변경 결과가 바로 나타나지 않을 수 있습니다. 브라우저, 운영체제, 커널, 원격 리졸버에 캐시가 있을 수 있으므로 프로세스 하나를 다시 시작해도 모든 단계의 캐시가 지워지는 것은 아닙니다. 설정이 다시 로드됐는지 확인한 다음 기존 연결을 끊고 필요하면 대상 앱을 다시 시작하세요. 조회 실패, 연결 시간 초과, 인증서 오류도 구분해야 합니다. 한 앱에서만 문제가 생긴다면 해당 앱이 별도 조회 기능을 사용하는지 먼저 확인하세요. 가상 네트워크 인터페이스를 사용하는 환경에서는 클라이언트가 DNS를 따로 처리하는지도 확인해야 합니다. 실제 요청에 사용되지 않는 최상위 설정만 반복해서 바꾸지 마세요.

policy 정책 및 통계

사용자 레벨 및 연결 시간 제한

정책 모듈은 일부 연결 동작과 통계 스위치를 설정하며 요청이 어느 노드로 갈지는 결정하지 않습니다. 일반적으로 사용자 레벨별 정책과 시스템 전체의 통계 옵션을 설정합니다. 사용자 레벨은 설정에서 참조하는 값이지 계정 권한, 유료 등급, 노드 품질 점수가 아닙니다. 해당 레벨이 프로토콜의 사용자 객체에서 지원되고 실제로 사용될 때만 관련 정책이 적용됩니다. 설정에 레벨을 입력했더라도 이를 참조하는 사용자가 없다면 모든 연결에 해당 매개변수가 자동 적용되지는 않습니다.

연결 수립, 유휴 연결 유지, 반쪽 닫기 대기는 서로 다른 단계입니다. 핸드셰이크 시간 제한은 연결 수립 과정의 대기 시간을 제한하고, 유휴 시간 제한은 활동이 없는 연결에 적용되며, 한 방향이 닫힌 뒤의 대기는 반대 방향에서 아직 처리 중인 데이터를 위한 것입니다. 값을 줄이면 리소스를 빨리 회수할 수 있지만 느린 네트워크, 롱 폴링, 오랫동안 대기하는 앱에서 연결이 자주 끊길 수 있습니다. 구체적인 증상을 바탕으로 매개변수를 조정하세요. 모든 시간 제한을 한꺼번에 줄인 뒤 그 결과로 발생한 연결 종료를 원격 서버 불안정으로 오해하지 마세요.

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

통계 스위치, 식별 정보, 조회 방식

예시의 시간 필드는 일반적인 커널 동작에 따라 초 단위로 사용하며, 값은 구조 설명용이지 모든 네트워크에 권장되는 조합이 아닙니다. 레벨 객체의 키는 문자열이고 사용자 객체의 레벨은 보통 숫자이므로 설정에서 자료형이 다릅니다. 먼저 클라이언트 기본 정책을 유지하고 재현 가능한 시간 초과 문제가 있을 때만 조정하세요. 버퍼나 연결 관리 필드의 지원 범위, 단위, 기본값은 커널마다 다를 수 있으므로 온라인에서 찾은 매개변수 전체를 범용 최적화 설정으로 사용하지 마세요.

통계 모듈을 켜는 것과 통계 결과를 읽을 수 있는 것은 별개의 문제입니다. 빈 통계 객체는 모듈을 활성화하고 정책 스위치는 어떤 방향이나 객체의 데이터를 수집할지 정하지만, 화면에 차트를 자동으로 표시하지는 않습니다. 결과를 읽으려면 클라이언트가 해당 기능을 지원하거나 커널이 지원하는 통계 인터페이스를 설정해야 합니다. 클라이언트가 표시하는 속도나 트래픽은 다른 방식으로 수집될 수도 있습니다. 화면에 사용자 통계가 표시되지 않는다고 통계 모듈 전체가 작동하지 않는 것은 아닙니다. 먼저 어떤 데이터를 읽으려는지, 인터페이스가 실제로 있는지 확인하세요.

사용자별 통계를 얻으려면 사용자 객체에 식별 가능한 정보가 있고 프로토콜이 이를 지원해야 할 수 있습니다. 레벨 스위치만으로는 예상한 항목이 생성되지 않을 수 있습니다. 일반 SOCKS 인바운드에 레벨 0을 적어도 원격 사용자의 신원이 자동으로 부여되지는 않습니다. 인바운드, 아웃바운드, 사용자 통계는 관측 위치가 다르므로 구분 없이 더해 실제 네트워크 사용량으로 판단하면 안 됩니다. 캡슐화 오버헤드, 전송 계층, 여러 연결도 비교 결과에 영향을 줍니다. 통계는 추세와 활동 출처를 살피는 데 적합하며 서버 청구량과 바로 일치하는 값은 아닙니다.

통계 인터페이스와 접근 범위

관리 인터페이스를 직접 설정해야 한다면 현재 커널의 인터페이스 구조와 서비스 목록을 확인하고 필요한 범위로 수신을 제한해야 합니다. 인터페이스 진입점, 관련 라우팅, 서비스 이름을 함께 설정해야 하는 경우가 많으므로 정책 조각 하나만 추가한다고 관리 경로가 열리지는 않습니다. 통계 도구의 연결을 위해 인터페이스를 모든 네트워크에 공개하지 마세요. 이 통로를 일반 프록시 진입점과 혼동해서도 안 됩니다. GUI 클라이언트가 관련 인터페이스를 이미 관리한다면 기존 화면을 우선 사용해 새 진입점이 기존 포트와 충돌하지 않도록 하세요.

정책을 바꿨다면 재현 가능한 동작으로 검증하세요. 유휴 연결 종료 문제라면 연결이 수립된 뒤 앱이 얼마나 대기했는지와 언제 끊겼는지 기록합니다. 핸드셰이크 실패라면 원격 포트 연결 여부와 보안 계층 또는 프로토콜 단계까지 진행했는지 확인합니다. 문제가 실제로 해당 단계에서 발생했다는 근거가 있을 때만 관련 정책을 바꾸세요. 실제 원인이 DNS 실패, 차단 아웃바운드로의 라우팅, 잘못된 노드 매개변수라면 시간 제한을 늘려도 연결은 복구되지 않고 대기만 길어집니다. 리소스 사용량이 비정상적이라면 연결 수와 트래픽 순환의 원인도 먼저 살펴보세요.

테스트가 끝나면 더 이상 필요하지 않은 진단 스위치를 꺼 두세요. 상세 로그와 많은 통계 항목은 지속적인 관찰 부담을 높이고 저장된 데이터에 이용 습관이 포함될 수도 있습니다. 설정 문서에 나온 모든 모듈을 계속 켜 둘 필요는 없습니다. 안정적으로 사용할 때는 목적을 설명할 수 있는 옵션만 유지하세요. 모바일에서는 정책에 따른 연결 정리와 운영체제의 백그라운드 제한도 구분해야 합니다. 앱이 백그라운드에서 시스템에 의해 중단된 경우 커널의 유휴 시간만 늘려서는 해결되지 않으므로 앱 권한과 배터리 관리 설정을 확인하세요.

구독 및 클라이언트 설정 생성

구독 내용은 전체 설정 파일이 아닙니다

구독은 주로 노드 정보를 클라이언트에 제공하며 전체 실행 설정은 보통 현재 선택한 노드, 로컬 인바운드, 라우팅, DNS, 기타 옵션을 조합해 클라이언트가 생성합니다. 구독 형식마다 담을 수 있는 정보가 다릅니다. 노드만 기술하는 형식도 있고 더 많은 설정 구조를 포함하는 형식도 있으며, 클라이언트가 이를 받아들이고 유지할지도 가져오기 방식에 따라 달라집니다. 구독 주소, 공유 링크, 전체 JSON 파일을 같은 종류의 리소스로 취급하지 마세요. 가져오기 전에 어떤 콘텐츠인지 확인하고 구독 업데이트, 클립보드 가져오기, 사용자 지정 설정 중 알맞은 기능을 선택하세요.

v2rayNG에서 구독을 가져올 때는 구독 그룹을 만들고 별칭과 주소를 입력해 저장한 다음 업데이트를 실행하고 그룹에 노드가 표시되는지 확인하는 것이 일반적입니다. v2rayN의 구독 그룹 설정도 비슷한 방식으로 관리합니다. 별칭은 출처를 구분하는 이름이고 주소는 실제 콘텐츠를 가져오는 경로이므로 서로 대신할 수 없습니다. 업데이트가 성공해도 노드를 선택하고 연결을 시작해야 합니다. 구독 내용을 내려받았다고 원격 서버를 사용할 수 있는 것은 아니며 시스템 프록시나 모바일 VPN 연결이 켜진 것도 아닙니다. 각 단계를 따로 확인하세요.

{
  "inbounds": [
    {
      "tag": "local-socks",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "auth": "noauth"
      }
    }
  ],
  "outbounds": [
    {
      "tag": "selected-node",
      "protocol": "freedom",
      "settings": {}
    }
  ],
  "routing": {
    "rules": [
      {
        "type": "field",
        "inboundTag": [
          "local-socks"
        ],
        "outboundTag": "selected-node"
      }
    ]
  }
}

위 객체는 직접 연결 프로토콜을 사용해 선택된 아웃바운드 위치를 모방한 것으로, 설정 생성 구조를 설명할 뿐 구독 형식은 아닙니다. 실제 클라이언트는 선택한 노드를 해당 프록시 아웃바운드로 변환해 로컬 설정과 조합합니다. 노드 이름은 바뀌어도 클라이언트 내부 아웃바운드 태그는 고정될 수 있고 설정 방식에 따라 태그가 다르게 생성될 수도 있습니다. 따라서 직접 작성한 규칙을 목록의 표시 이름에만 의존하지 말고 최종 생성된 태그를 확인하세요. 클라이언트가 공통 프록시 아웃바운드 참조를 제공한다면 해당 규칙에 맞춰 편집하는 편이 좋습니다.

업데이트 범위와 사용자 지정 설정

구독을 업데이트하면 노드 매개변수가 교체되거나 노드가 추가·삭제되고 별칭이 바뀔 수 있습니다. 구체적인 병합 방식은 클라이언트에 따라 다릅니다. 구독 노드를 직접 수정하면 다음 업데이트에서 변경 사항이 덮어써질 수 있습니다. 오래 유지해야 하는 특수 노드는 클라이언트가 지원하는 별도 그룹이나 설정에 넣고 출처와 수정 목적을 기록하세요. 로컬 라우팅과 DNS가 업데이트로 바뀌는지도 가져오기 방식에 따라 다릅니다. 노드만 업데이트하는 것과 전체 설정을 가져오는 것은 서로 다른 동작이므로 업데이트 전후에 실제 실행 객체를 확인하는 편이 확실합니다.

구조를 명확히 제어해야 하는 사용자에게는 전체 사용자 지정 설정이 적합하지만 클라이언트의 자동 생성 기능 일부를 우회할 수 있습니다. 화면에서 선택한 노드, 라우팅 프리셋, 로컬 포트 변경이 이 설정에 반영되지 않을 수도 있습니다. 사용자 지정 모드로 전환하기 전에 인바운드를 관리하는 주체, 관리 인터페이스, 클라이언트가 자동으로 필드를 추가하는지, 시작 시 어떤 파일을 불러오는지 확인하세요. 전체 사용자 지정 설정을 사용하면서 일반 GUI 옵션도 모두 동기화될 것이라고 기대하지 마세요. 먼저 설정의 관리 주체를 명확히 정한 뒤 사용자 지정 항목을 추가하세요.

클라이언트	지원 플랫폼	주요 확인 항목
v2rayN	Windows、macOS、Linux	커널 선택, 설정 생성, 시스템 프록시, TUN 설정
v2rayNG	Android	Xray 매개변수 지원, 구독 업데이트, VPN 권한
v2flyNG	Android	V2Fly 매개변수 지원, 기존 노드 호환성

마이그레이션, 개인정보 보호, 클라이언트 선택

다른 클라이언트로 옮길 때는 먼저 노드를 이전한 다음 로컬 연결과 라우팅을 다시 구성하세요. 각 GUI의 프리셋에 같은 이름의 옵션이 있다고 가정하면 안 됩니다. 데스크톱에서는 v2rayN을 우선 고려하고 Android에서는 필요한 커널에 따라 v2rayNG나 v2flyNG를 선택할 수 있습니다. 같은 노드 정보도 커널의 기능 지원 범위에 따라 다르게 작동할 수 있습니다. 클라이언트 다운로드 페이지에서 시스템에 맞는 항목을 선택하고 v2rayNG 다운로드를 검색할 때도 기기 아키텍처를 먼저 확인하세요. 아키텍처는 프로그램을 설치하고 실행할 수 있는지에 영향을 주며 노드 프로토콜이나 라우팅 동작을 직접 결정하지는 않습니다.

구독 주소에는 접근 자격 증명이 포함되는 경우가 많으므로 전체 링크를 공개 스크린샷, 채팅 기록, 오류 보고서에 올리지 마세요. 문제를 보고할 때는 오류 유형, 응답 상태, 업데이트 시간을 남기고 쿼리 매개변수와 사용자 식별 정보는 가리세요. 업데이트 실패는 주소에 접근할 수 없는 경우, 응답 내용이 비어 있는 경우, 형식이 지원되지 않는 경우, 노드 파싱이 실패한 경우로 나눠 확인해야 합니다. 이는 프록시 노드의 연결 가능 여부와 각각 대응하는 문제가 아닙니다. 구독에서 일부 노드만 누락됐다면 클라이언트를 바로 재설치하기보다 해당 노드의 프로토콜과 전송 방식이 지원되는지 확인하세요.

자동 업데이트 간격도 적절히 설정해야 합니다. 너무 자주 업데이트하면 불필요한 요청이 늘고 문제 해결 중 테스트 대상이 계속 바뀔 수 있습니다. 너무 길면 이미 유효하지 않은 매개변수가 남을 수 있습니다. 서비스의 실제 변경 빈도와 사용 방식에 맞춰 정하세요. 간격이 짧을수록 연결 품질이 높아지는 것은 아닙니다. 문제를 조사할 때는 노드와 설정을 잠시 고정하고 검증이 끝나면 일반 업데이트 주기로 되돌리세요. 처음 설정하는 경우에는 시작 가이드의 구독 절차를 따르세요. 이 장에서는 업데이트 이후 어떤 모듈이 바뀌었는지 설명합니다.

설정 검증 및 문제 해결

설정 로드부터 애플리케이션 연결까지

연결 경로에 따라 차례로 검증하세요. 먼저 설정 문법을 읽을 수 있는지 확인하고 커널이 시작되어 로컬 포트가 열리는지, 애플리케이션이 실제로 해당 진입점을 사용하는지, 라우팅 선택과 DNS 결과가 올바른지 확인합니다. 이어서 원격 연결과 프로토콜 핸드셰이크를 검사한 뒤 실제 애플리케이션을 테스트합니다. 이 순서대로 확인하면 문제를 특정 단계로 좁힐 수 있습니다. 웹페이지가 열리지 않는다는 것은 구체적인 원인이 아니며 클라이언트를 재설치해도 원인을 찾을 수 없습니다. 마지막으로 성공한 단계와 처음 실패한 단계를 알아야 포트, 권한, 매개변수, 네트워크 경로 중 무엇을 확인할지 결정할 수 있습니다.

변경 후에는 새 설정이 실제로 로드됐는지 먼저 확인하세요. 클라이언트가 이전 프로세스를 계속 실행하거나 시작할 때 다른 파일을 새로 생성할 수 있으므로 편집기에 보이는 내용과 실제 실행 상태가 다를 수 있습니다. 저장한 뒤 클라이언트 방식에 따라 서비스를 다시 시작하고 시작 로그에서 수신 주소, 포트, 사용 중인 커널을 확인하세요. 알 수 없는 필드가 표시되면 호환성을 확인하고 주소 바인딩 실패가 표시되면 포트를 확인하세요. 시작 로그조차 없다면 프로그램이 정상적으로 실행되는지 살펴보고 클라이언트 실행 직후 종료 및 권한 문제 해결을 참고하세요.

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

로그와 문제 유형 구분

정보 수준 로그를 잠시 사용하면 연결을 받고 아웃바운드로 전달하는 과정을 살펴보는 데 도움이 되지만 로그 내용과 상세도는 커널 및 클라이언트에 따라 다릅니다. 모든 규칙의 일치 기록이 같은 형식으로 나온다고 기대하거나 문맥을 무시하고 특정 단어 하나만 해석하지 마세요. 시간 순서에 따라 읽으세요. 앱이 연결을 요청한 뒤 인바운드 기록이 있었는지, 아웃바운드가 선택됐는지, 조회·연결·핸드셰이크 중 어느 단계에서 실패했는지 확인합니다. 진단이 끝나면 일상적인 사용에 적합한 수준으로 되돌리고 로그를 공유하기 전에 대상 주소, 구독 매개변수, 사용자 식별 정보 등 민감한 내용을 가리세요.

증상	우선 확인	우선 변경하지 않을 항목
시작 직후 실패	JSON 문법, 커널 지원, 포트 사용 여부	노드 속도 테스트, 앱 캐시
애플리케이션 인바운드 기록 없음	앱 프록시 설정, 인바운드 프로토콜과 포트	원격 사용자 매개변수
도메인 조회 실패	실제 DNS 경로, 서버 연결 가능 여부	프로토콜 이름
원격 연결 시간 초과	주소, 포트, 네트워크 경로, 방화벽	통계 화면 설정
핸드셰이크 거부	사용자 매개변수, 전송, 보안 계층 설정	로컬 포트의 표시 이름
일부 대상에서만 문제 발생	라우팅 규칙, 조회 결과, 주소 유형	모든 모듈을 한꺼번에 초기화

같은 오류도 원인이 여러 가지일 수 있으므로 이 표는 증상에 단일 결론을 붙이기보다 확인 순서를 정하는 데 사용하세요. 원격 시간 초과는 네트워크에 연결할 수 없는 문제일 수도 있고 포트가 틀린 문제일 수도 있습니다. 핸드셰이크 오류는 서비스 이름 불일치, 인증 정보 오류, 전송 매개변수 누락에서 발생할 수 있습니다. 익숙하지 않은 매개변수를 계속 추가하기보다 정상 작동하는 설정과 비교하는 편이 효과적입니다. 비교할 때는 기기, 네트워크, 테스트 대상을 되도록 동일하게 유지해 네트워크 환경 변화가 설정 수정 효과로 보이지 않도록 하세요.

V2Ray 노드 속도 테스트와 실제 사용 가능 여부

V2Ray 노드 속도 테스트에는 여러 방식이 있습니다. 포트 연결 테스트는 대상 포트에 연결할 수 있는지만 확인하며 프록시 프로토콜을 완료하지 않을 수 있습니다. 프록시를 통해 테스트 주소에 접속하는 방식은 실제 앱 사용에 더 가깝지만 테스트 사이트, DNS, 라우팅의 영향을 받습니다. 다운로드 테스트는 지속적인 전송 성능을 확인하지만 트래픽을 소모합니다. 화면에 표시되는 시간 하나만으로 전체 접속 환경을 판단할 수는 없습니다. 노드를 비교할 때는 같은 테스트 방식과 대상을 사용하고 실제 앱으로도 확인하세요. 한 번의 순위 결과만으로 장기 설정을 결정하지 마세요.

테스트는 성공했는데 브라우저에서 실패한다면 두 요청이 같은 인바운드와 라우팅을 사용하는지 확인하세요. 브라우저 확장 기능, 우회 목록, 자체 DNS 조회, 기존 연결이 요청 경로를 바꿀 수 있습니다. 터미널 도구도 자체 프록시 설정이나 환경 변수를 사용할 수 있습니다. 반대로 브라우저에서 성공해도 모든 앱이 시스템 프록시를 따르는 것은 아닙니다. 결과가 다른 앱의 연결 방식을 하나씩 확인하고 커널 로그에 요청이 나타나는지 기록하세요. 더 많은 트래픽을 처리해야 한다면 이 페이지의 TUN 장으로 돌아가 권한과 라우팅 영향을 검토하세요.

복구, 기록, 안정적인 사용

매 테스트마다 서로 관련된 필드 한 묶음만 바꾸고 예상 결과를 적으세요. 예를 들어 도메인 하나에 직접 연결 규칙을 추가했다면 예상 결과는 아웃바운드 태그가 바뀌는 것이지 모든 접속 속도가 향상되는 것이 아닙니다. 조회 정책을 바꿨다면 주소 유형이나 조회 경로가 달라지는 것이 예상 결과이지 인증 오류가 사라지는 것이 아닙니다. 결과가 예상과 다르면 마지막으로 작동한 설정으로 먼저 되돌린 다음 규칙의 선행 조건을 확인하세요. 필드, 테스트 대상, 관찰 결과를 짧게 기록해 두면 여러 차례 시험한 뒤에도 현재 설정의 목적을 잊지 않을 수 있습니다.

안정적인 설정에는 명확한 기본 아웃바운드, 범위가 제한되고 목적을 설명할 수 있는 규칙, 실제 연결 방식에 맞는 DNS, 필요한 로컬 수신 범위가 있어야 합니다. 임시 설명용 매핑, 진단 인터페이스, 시험용 매개변수를 정리한 뒤 구독 업데이트를 다시 활성화하세요. 문제가 계속된다면 클라이언트 이름, 운영체제, 커널 종류, 실패 단계, 민감 정보를 가린 로그를 보고하면 됩니다. 전체 설정을 공개할 필요는 없습니다. 이후 설정을 확인할 때는 이 페이지 목차에서 필요한 모듈을 찾아보고, 일상적인 연결은 시작 가이드를 따르세요. 이렇게 하면 유지 관리가 가능한 구조를 지키고 문제가 생길 때마다 모든 설정을 처음부터 다시 만드는 일을 피할 수 있습니다.