V2Ray 설정 파일 가이드

01 / STRUCTURE

JSON 구조와 설정 범위

설정 파일은 객체 간 관계를 정의하고, 코어는 이를 연결해 트래픽 처리 경로를 구성합니다. 애플리케이션의 요청은 인바운드로 들어오고, 라우팅에서 대상과 출처 조건을 확인한 뒤 아웃바운드를 선택해 연결합니다. DNS는 도메인 이름 해석에 관여하고, 정책은 연결 리소스를 제한하며, 로그는 실행 과정을 기록합니다. 각 항목은 차례로 실행되는 스크립트가 아니므로 파일에서 작성 순서를 바꿔도 대개 처리 순서는 달라지지 않습니다. 다만 배열 내부의 순서는 결과에 직접 영향을 줄 수 있습니다.

실제로 읽히는 설정 파일부터 확인

v2rayN 같은 그래픽 클라이언트는 보통 노드, 라우팅, DNS 화면의 설정을 바탕으로 실행용 설정을 생성합니다. 구독 그룹, 창 배치, 속도 측정 설정은 클라이언트 데이터이지 코어의 최상위 항목이 아닙니다. 디스크에 config.json이라는 파일이 있다고 해서 현재 실행 중인 설정이라고 단정할 수도 없습니다. 클라이언트의 실행 정보, 설정 확인 메뉴 또는 시작 로그에서 코어 종류와 설정 출처를 확인한 뒤 수정 위치를 정하세요.

생성된 파일을 직접 수정하면 한 번만 적용될 수 있습니다. 노드 전환, 구독 업데이트, 설정 저장 또는 코어 재시작 때 클라이언트가 파일을 다시 만들어 변경 사항을 덮어쓸 수 있습니다. 평소에는 클라이언트에서 제공하는 라우팅, DNS, 사용자 지정 설정 메뉴를 이용하세요. 설정 전체를 직접 관리해야 한다면 해당 모드에서도 클라이언트 생성 규칙이 적용되는지 먼저 확인하세요. 두 설정이 자동으로 병합된다고 가정하면 안 됩니다.

독립 실행 가능한 최소 구조부터 시작

아래의 완전한 기본 설정은 로컬 루프백 주소에서 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": {}
    }
  ],
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "inboundTag": ["local-socks"],
        "outboundTag": "direct"
      }
    ]
  }
}

이 구조를 확장할 때는 기능을 한 번에 하나씩 추가하세요. 먼저 고유 태그가 있는 아웃바운드를 추가하고, 이를 참조하는 규칙을 만든 다음 매칭 여부를 확인합니다. DNS 변경, 스니핑 활성화, 정책 조정, 기본 아웃바운드 변경을 동시에 하지 마세요. 최소 기본 설정은 모든 기능을 제공하기 위한 것이 아니라, 언제든 돌아갈 수 있는 기준점을 마련해 각 변경의 원인을 분명히 하기 위한 것입니다.

객체, 배열, 항목 유형

inbounds와 outbounds는 여러 객체를 담을 수 있는 배열입니다. routing, dns, policy, log는 객체입니다. 문자열에는 영문 큰따옴표를 사용하고, 불리언 값은 true 또는 false로 작성하세요. 숫자와 문자열도 각 항목에서 요구하는 유형에 맞춰야 합니다. 포트 범위 항목 중에는 문자열을 허용하는 경우가 있지만, 그렇다고 모든 포트 항목에서 유형을 섞어 쓸 수 있는 것은 아닙니다.

여러 도구에서 읽을 수 있도록 이 페이지의 예제는 주석, 후행 쉼표, 중복 키가 없는 엄격한 JSON을 사용합니다. 일부 로더는 확장 문법을 허용할 수 있지만, 편집기에서 열린다는 이유만으로 현재 코어에서 불러올 수 있다고 판단하면 안 됩니다. 특히 설명 문구를 따옴표 밖에 붙여 넣거나 문서의 굽은 따옴표를 복사하지 않도록 주의하세요. 오류 위치는 문제가 발견된 곳을 가리키므로, 실제로 빠진 쉼표는 바로 앞 줄에 있을 수도 있습니다.

자주 쓰이는 여섯 항목이 최상위 항목의 전부는 아닙니다. 통계, 관리 인터페이스, 기타 확장 모듈에는 별도 설정이 필요할 수 있습니다. 구조를 완전해 보이게 하려고 빈 모듈을 무작정 추가하지 마세요. 문제가 수신, 매칭, 이름 해석, 연결 중 어디에 해당하는지 먼저 판단한 뒤 관련 항목을 확인하세요. 인터넷에서 찾은 매개변수를 하나씩 시험하는 것보다 설정 범위를 올바르게 유지하기 쉽습니다.

02 / INBOUNDS

inbounds 인바운드 설정

인바운드는 코어가 어디서 트래픽을 받고 수신한 데이터를 어떻게 처리할지 정의합니다. 로컬 애플리케이션이 SOCKS 또는 HTTP 프록시를 사용한다면 연결 대상은 원격 노드 주소가 아니라 프록시 인바운드입니다. 인바운드가 작동한다는 것은 애플리케이션이 코어에 연결할 수 있다는 뜻일 뿐, 원격 아웃바운드 연결의 성공을 보장하지 않습니다. 문제를 해결할 때는 로컬 수신과 원격 연결을 따로 확인해야 포트 문제를 노드 문제로 오인하지 않습니다.

수신 주소와 포트

listen은 수신할 네트워크 인터페이스를, port는 로컬 서비스 포트를 지정합니다. 이 기기에서 실행하는 프로그램만 사용한다면 127.0.0.1을 명시해 수신 범위를 제한할 수 있습니다. 모든 인터페이스에서 접근할 수 있는 주소로 바꾸면 같은 로컬 네트워크의 다른 기기도 해당 포트에 접근할 수 있으므로 시스템 방화벽, 접근 범위, 인증 설정을 함께 고려해야 합니다. 수신 포트를 개방하는 것만으로 공유가 보장되지는 않으며, 연결 실패 시 무조건 적용할 해결책도 아닙니다.

같은 주소와 포트에서 동일한 전송 방식으로 두 인바운드를 동시에 수신할 수는 없습니다. 포트를 사용 중인 프로세스는 다른 클라이언트 인스턴스일 수도 있고, 이전에 정상 종료되지 않은 코어 프로세스일 수도 있습니다. 바인딩에 실패하면 중복 실행 중인 인스턴스를 먼저 종료한 뒤 포트를 다시 사용할 수 있는지 확인하세요. 포트를 바꿨다면 브라우저, 시스템 프록시, 다른 애플리케이션의 프록시 주소도 함께 변경해야 합니다. 그렇지 않으면 애플리케이션이 계속 이전 포트에 연결합니다.

SOCKS와 HTTP는 서로 바꿔 쓸 수 없습니다

아래는 최상위 inbounds에 추가할 수 있는 항목 예시입니다. 두 인바운드는 서로 다른 포트를 사용하며 태그로 구분합니다. SOCKS의 UDP 옵션은 해당 인바운드가 관련 요청을 허용한다는 뜻일 뿐, 모든 애플리케이션과 아웃바운드, 전체 네트워크 경로가 UDP를 지원한다는 뜻은 아닙니다. HTTP 인바운드는 HTTP 프록시 프로토콜을 사용하는 애플리케이션을 위한 것으로, 포트에 연결된다고 SOCKS 인바운드처럼 사용할 수 있는 것은 아닙니다.

{
  "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": {}
    }
  ]
}

애플리케이션에서 선택한 프록시 유형은 인바운드 프로토콜과 일치해야 합니다. HTTP 요청을 SOCKS 포트에 보내면 연결이 끊기거나 프로토콜 오류 또는 빈 응답이 발생할 수 있으며, 이 경우 노드를 바꿔도 해결되지 않습니다. 애플리케이션이 대상 도메인을 프록시에 전달하는지, 아니면 먼저 직접 해석해 IP 주소를 전달하는지도 확인하세요. 두 방식에 따라 코어가 확인할 수 있는 대상 정보가 달라지고, 이후 도메인 규칙의 매칭 결과에도 영향을 줍니다.

태그와 요청 출처 식별

tag는 설정 내부에서 사용하는 이름으로, 네트워크 주소도 아니고 수신 동작을 결정하지도 않습니다. 로컬 SOCKS와 로컬 HTTP를 구분하는 식으로 짧고 의미가 분명하며 쉽게 바뀌지 않는 태그를 사용하세요. 라우팅의 inboundTag는 대소문자까지 태그와 정확히 일치해야 합니다. 태그를 변경한 뒤 규칙을 함께 수정하지 않으면 해당 인바운드 규칙이 작동하지 않고, 트래픽이 다음 규칙이나 기본 아웃바운드로 전달될 수 있습니다.

고유 태그를 사용하면 애플리케이션 인바운드를 구분할 수 있습니다. 일반 인바운드는 그대로 두고 테스트 전용 인바운드를 추가한 뒤, 인바운드 태그를 기준으로 테스트 트래픽을 지정한 아웃바운드에 전달할 수 있습니다. 모든 애플리케이션의 전역 규칙을 계속 수정하지 않고도 새 아웃바운드를 검증할 수 있습니다. 다만 인바운드가 많아지면 포트와 규칙의 관계도 복잡해집니다. 사용하지 않는 인바운드는 삭제하거나 비활성화해 오래된 테스트 경로가 설정에 남지 않도록 하세요.

스니핑으로 확인할 수 있는 정보

일부 요청은 IP 주소만 포함한 채 코어에 들어옵니다. 스니핑은 HTTP 호스트명이나 일부 TLS 핸드셰이크의 서버 이름처럼 지원되는 프로토콜의 초기 데이터에서 도메인 정보를 추출할 수 있습니다. 스니핑은 복호화 도구가 아니며 모든 암호화 트래픽을 식별하지도 못합니다. 대상 애플리케이션의 프로토콜, 핸드셰이크 형식, 개인정보 보호 기능에 따라 확인 가능한 정보가 달라집니다. 따라서 스니핑을 켰다고 모든 도메인 규칙이 매칭되는 것은 아닙니다.

{
  "sniffing": {
    "enabled": true,
    "destOverride": ["http", "tls"]
  }
}

위 예제는 단일 인바운드 객체에 넣는 항목 일부이며 최상위 객체가 아닙니다. destOverride는 스니핑 결과를 바탕으로 대상을 보정하는 동작과 관련이 있습니다. 구체적인 지원 항목과 옵션은 코어에 따라 확인해야 합니다. 연결 대상을 변경하지 않고 스니핑 결과만 라우팅에 활용하려면 현재 코어가 라우팅 전용 옵션을 제공하는지 확인하세요. 다른 코어의 확장 항목을 그대로 복사해 같은 방식으로 동작한다고 가정하지 마세요.

인바운드를 확인할 때는 먼저 클라이언트 로그에 수신 오류가 없는지 살펴본 다음, 프록시 설정을 지원하는 애플리케이션에서 해당 인바운드를 지정해 요청을 보내세요. 코어에 요청이 전혀 들어오지 않으면 애플리케이션 설정과 트래픽 가로채기 범위를 확인합니다. 수신 기록이 있다면 라우팅과 아웃바운드 설정을 살펴보세요. Android의 네트워크 가로채기는 시스템 권한과 앱별 설정에도 영향을 받으며, 데스크톱의 시스템 프록시와 설정 경로가 다릅니다.

03 / OUTBOUNDS

outbounds 아웃바운드 설정

아웃바운드는 코어가 대상에 연결하는 방식을 정의합니다. 직접 연결하거나 원격 프록시에 요청을 전달하거나 규칙에 따라 요청을 거부할 수 있습니다. 인바운드가 요청을 받고 아웃바운드가 요청을 보내며, 라우팅을 통해 둘이 연결됩니다. 원격 노드에 문제가 있어도 로컬 인바운드는 정상적으로 수신 중일 수 있습니다. 클라이언트 화면에 노드 이름이 표시된다고 해서 현재 코어가 아웃바운드 설정을 받아들였다는 뜻도 아닙니다. 설정 생성 성공 여부와 연결 성공 여부를 각각 확인하세요.

기본 아웃바운드는 배열 순서로 결정

전통적인 설정에서는 라우팅 규칙에 선택되지 않은 트래픽이 보통 outbounds 배열의 첫 번째 아웃바운드로 전달됩니다. 이 기본 동작은 매우 중요합니다. 객체 두 개의 순서만 바꿔도 매칭되지 않은 모든 요청의 경로가 달라질 수 있습니다. 태그가 direct 또는 proxy라고 해서 기본 아웃바운드라고 판단하지 마세요. 태그는 참조용 이름일 뿐이며 실제 동작은 프로토콜과 설정, 배열 내 위치에 따라 결정됩니다.

아래 항목 예시에서는 직결을 첫 번째에 두고 거부 아웃바운드를 추가합니다. 로컬 기본 설정과 규칙 참조 관계를 설명하기 위한 것이며 원격 노드를 포함한 설정은 아닙니다. 매칭되지 않은 요청을 원격 프록시로 보내려면 첫 번째 항목 또는 마지막 폴백 규칙을 다시 구성해야 합니다. 도메인 이름 해석, 구독 업데이트, 로컬 네트워크 접근까지 같은 아웃바운드로 전달되지 않는지도 확인하세요.

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

직결, 거부, 원격 프로토콜

freedom은 대상에 직접 연결하는 아웃바운드 프로토콜입니다. 직결 연결도 기기의 네트워크, 방화벽, 대상 서비스 상태에 영향을 받으므로 원격 노드를 우회한다고 항상 연결되는 것은 아닙니다. blackhole은 매칭된 트래픽을 거부하거나 폐기하는 프로토콜로, 명확한 차단 규칙에 사용할 수 있습니다. 애플리케이션에서는 프로토콜과 응답 설정에 따라 연결 실패, 빈 응답, 대기 등으로 나타날 수 있습니다. 문제를 진단할 때는 먼저 요청이 거부 아웃바운드로 전달됐는지 확인하세요.

원격 프록시 아웃바운드에는 서버 주소와 포트, 인증 정보, 전송 및 보안 매개변수가 포함됩니다. VMess, VLESS, Trojan, Shadowsocks는 설정 객체가 서로 다르므로 protocol만 바꿔 한 노드 유형을 다른 유형으로 변환할 수 없습니다. 신뢰할 수 있는 노드 정보나 클라이언트 가져오기 기능으로 해당 항목을 생성한 다음, 생성된 설정을 확인하세요. 불완전한 네트워크 예제에 값을 하나씩 추측해 넣지 마세요.

노드 주소는 연결할 서버를 가리키며, TLS 서버 이름은 핸드셰이크 검증이나 관련 프로토콜 동작에 사용됩니다. 둘은 다를 수 있지만 서버 구성에 맞아야 합니다. 전송 계층의 경로와 호스트명, 보안 계층의 서버 이름도 서로 다른 용도입니다. 핸드셰이크에 실패하면 각 계층을 나눠 확인하세요. 세 항목을 모두 서버 IP로 바꾸면 안 됩니다. 인증서 검증을 끄면 문제를 가릴 수 있으므로 일반적인 문제 해결 방법으로 사용하지 마세요.

항목을 조합하기 전에 코어의 지원 범위부터 확인

Xray와 V2Fly는 과거 설정 개념 일부를 공유하지만 확장 프로토콜과 전송 옵션이 모두 호환되는 것은 아닙니다. 노드에 REALITY나 특정 흐름 제어 항목이 필요하다면 클라이언트에서 실제로 실행 중인 코어가 이를 처리할 수 있는지 먼저 확인하세요. v2rayNG와 v2flyNG는 코어 지원 범위가 다릅니다. 데스크톱에서 v2rayN을 사용하더라도 클라이언트 이름만으로 모든 기능의 지원 여부를 추정하지 말고, 노드와 실행 정보를 확인하세요.

프로토콜, 전송, 보안 계층은 서로 관련되어 있지만 각각 다른 설정 범주입니다. VLESS는 프록시 프로토콜이고 TLS와 REALITY는 보안 관련 설정이며, 실제 네트워크 전송에는 별도의 매개변수가 있습니다. 항목을 잘못된 계층에 넣으면 설정 오류가 발생하거나, 설정이 로드된 뒤 협상에 실패할 수 있습니다. 배경은 REALITY와 XTLS Vision 원리 설명에서 확인할 수 있습니다. 실제 항목 지원 여부는 사용하는 코어를 기준으로 판단하세요.

태그와 연결 경로 다시 확인

규칙에서 참조할 아웃바운드에는 각각 고유 태그를 지정해야 합니다. 태그가 중복되면 설정의 의미가 불분명해지고, 도구가 중복 값을 처리하는 방식에도 의존할 수 없습니다. 아웃바운드 이름을 바꾸면 라우팅, 연결 체인, 기타 참조 항목도 함께 확인하세요. 클라이언트 화면에서 노드 표시 이름만 바꿔도 생성된 설정의 아웃바운드 태그가 바뀌지 않을 수 있습니다. 목록의 이름만 보는 것보다 실제 실행 설정을 확인하는 편이 정확합니다.

아웃바운드를 진단할 때는 먼저 로컬 직결 기본 설정으로 대상 서비스에 연결해 보고, 같은 인바운드와 같은 테스트 대상을 사용해 원격 아웃바운드로 바꿔 확인할 수 있습니다. 원격 경로에서만 실패한다면 서버 주소 해석, 포트 연결, 보안 핸드셰이크, 인증 매개변수를 확인하세요. 대상마다 서로 다른 라우팅이 적용될 수 있습니다. 웹페이지 하나가 열렸다고 모든 아웃바운드가 정상이라고 단정하거나, 대상 하나의 시간 초과만으로 노드 전체가 작동하지 않는다고 판단하지 마세요.

설정을 관리할 때 기본 아웃바운드, 명시적 직결, 명시적 거부, 원격 아웃바운드의 역할을 분명히 구분하세요. 새 아웃바운드를 먼저 단독으로 검증하고, 소수의 규칙에서 참조하게 한 뒤 기본 경로를 변경하는 것이 좋습니다. 이렇게 하면 새 노드 설정 오류가 모든 요청에 영향을 주는 일을 막을 수 있습니다. 문제가 생겨도 설정 전체를 다시 만들지 않고 관련 규칙만 되돌릴 수 있습니다.

04 / ROUTING

routing 규칙과 순서

라우팅은 요청 조건을 아웃바운드 태그에 연결합니다. 중요한 것은 규칙의 개수가 아니라 매칭 순서, 조건 조합, 코어가 확인할 수 있는 대상 정보입니다. 전통적인 필드 규칙은 보통 위에서 아래로 검사하며, 처음 매칭된 규칙의 아웃바운드를 선택합니다. 뒤에 있는 더 구체적인 규칙을 자동으로 찾지 않습니다. 따라서 정밀한 예외는 일반 규칙보다 앞에, 폴백은 마지막에 두는 것이 일반적입니다. 파일에서 뒤에 있다는 이유만으로 앞선 규칙을 덮어쓰는 것은 아닙니다.

규칙 하나 안의 조건 조합

같은 규칙에 있는 서로 다른 조건은 보통 모두 충족해야 합니다. 예를 들어 inboundTag와 domain을 함께 지정하면 인바운드와 도메인이 모두 일치해야 하며, 둘 중 하나만 일치해도 된다는 뜻이 아닙니다. 같은 조건에 여러 값을 나열하면 보통 그중 하나가 일치하면 됩니다. 서로 독립적인 조건 조합을 표현하려면 규칙을 나누세요. 의도한 ‘또는’를 ‘그리고’로 잘못 작성하지 않도록 주의해야 합니다.

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "inboundTag": ["local-socks"],
        "domain": [
          "full:example.com",
          "domain:example.org"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": [
          "127.0.0.0/8",
          "10.0.0.0/8",
          "172.16.0.0/12",
          "192.168.0.0/16",
          "::1/128",
          "fc00::/7",
          "fe80::/10"
        ],
        "outboundTag": "direct"
      }
    ]
  }
}

이 예제는 앞서 설명한 기본 설정과 함께 사용할 수 있는 라우팅 항목입니다. 첫 번째 규칙은 지정된 SOCKS 인바운드만 대상으로 하므로 HTTP 인바운드에서 같은 도메인에 접근해도 매칭되지 않습니다. 두 번째 규칙은 루프백, 사설 주소 및 일부 로컬 주소 범위를 나열하지만 전체 특수 용도 주소 목록은 아닙니다. 더 폭넓은 주소 분류가 필요하다면 출처와 범위가 확인된 데이터 집합을 사용하고 업데이트 방법도 파악하세요.

도메인 표현식의 매칭 범위 구분

full:은 완전한 도메인 이름을 매칭하므로 특정 호스트 하나를 지정할 때 적합합니다. domain:은 지정한 도메인과 그 하위 도메인을 매칭합니다. 접두사 없는 표현식은 키워드 기준으로 매칭될 수 있어 예상보다 범위가 넓습니다. 정규식은 JSON 이스케이프 규칙의 영향을 받으며 지나치게 넓게 작성하면 이해하고 관리하기 어렵습니다. 전체 도메인이나 도메인 접미사로 표현할 수 있다면 범위가 분명한 방식을 우선 사용하세요.

도메인 규칙은 요청에 포함되었거나 코어가 식별한 대상 정보를 매칭하며, 웹페이지가 최종적으로 불러오는 모든 리소스를 한꺼번에 매칭하지는 않습니다. 한 페이지에서 여러 도메인에 요청을 보낼 수 있으므로 메인 페이지가 지정한 아웃바운드를 사용해도 이미지, API, 동영상이 같은 경로를 사용한다는 보장은 없습니다. 규칙을 진단할 때는 단일 대상 요청을 확인하세요. 웹페이지 전체의 결과를 특정 도메인 규칙의 직접적인 증거로 삼지 마세요.

이름 해석 정책은 라우팅 매칭 과정에 영향을 줍니다

AsIs는 라우팅의 IP 매칭을 위해 도메인을 먼저 해석하지 않습니다. 요청 자체가 IP 주소라면 IP 규칙은 여전히 매칭될 수 있습니다. IPIfNonMatch는 도메인 대상이 기존 규칙과 매칭되지 않을 때 해석을 시도한 뒤 다시 매칭합니다. IPOnDemand는 라우팅 처리에 IP 정보가 필요할 때 해석을 시작합니다. 이 설정들은 시스템 DNS를 켜고 끄는 옵션도, 아웃바운드의 도메인 해석 정책도 아닙니다.

이름 해석을 실행하는 정책으로 바꾸면 지연 시간과 규칙 매칭 결과가 달라질 수 있습니다. DNS가 다른 지역의 주소를 반환하면 일부 IP 분류 규칙이 다른 아웃바운드를 선택할 수 있습니다. 반대로 애플리케이션이 코어에 요청을 보내기 전에 도메인을 IP로 변환했다면, 코어의 도메인 해석 정책을 바꿔도 원래 도메인을 되살릴 수 없습니다. DNS 주소를 계속 바꾸기보다 인바운드 프로토콜, 스니핑, 애플리케이션의 이름 해석 방식을 함께 살펴보세요.

예외, 분류, 폴백 순서로 규칙 구성

먼저 명시적으로 거부하거나 특정 아웃바운드로 보내야 하는 정밀한 대상을 두고, 그다음 로컬 네트워크와 서비스 분류를 배치한 뒤 나머지 요청을 처리할 수 있습니다. 순서는 정책에 따라 다르지만 각 규칙을 해당 위치에 둔 이유를 설명할 수 있어야 합니다. 모든 대상을 매칭하는 규칙을 마지막에 두면 그 뒤의 규칙은 적용되지 않습니다. 마지막 규칙을 두지 않는다면 첫 번째 아웃바운드가 기본 경로가 된다는 점을 명확히 이해해야 합니다.

geosite: 또는 geoip: 분류를 사용하려면 해당 데이터 파일과 유효한 분류 이름이 필요합니다. 코어가 문법을 지원한다고 해서 실행 환경에 필요한 데이터가 들어 있다는 뜻은 아닙니다. 업데이트 후 분류를 불러오지 못하면 데이터 경로와 분류 이름이 존재하는지 먼저 확인하세요. 분할 라우팅 규칙을 모두 삭제하지 마세요. 생성된 파일, 클라이언트 내장 규칙, 사용자 지정 규칙의 순서가 다를 수 있으므로 실제 실행 설정을 기준으로 확인해야 합니다.

규칙을 변경한 뒤에는 로그에서 대상, 출처, 아웃바운드가 예상과 일치하는지 확인하세요. 일부 사이트만 작동하지 않는다면 실제로 선택된 아웃바운드를 먼저 비교하고, 그다음 DNS와 연결 과정을 확인하는 것이 좋습니다. 클라이언트의 전체 연결 스위치나 노드 색상만으로는 개별 요청의 라우팅을 알 수 없습니다. 장기적으로는 중복 규칙을 계속 추가하기보다 규칙 그룹에 간단한 설명을 남기면 되돌리기 쉽습니다.

05 / DNS

dns 이름 해석과 연결 경로

DNS 문제는 먼저 ‘누가 이름을 해석하는지’ 확인해야 합니다. 애플리케이션이 직접 조회할 수도 있고, 운영체제가 대신 해석하거나, 코어의 내장 해석기가 처리할 수도 있습니다. 원격 프록시가 반대편에서 대상 도메인을 해석하는 경우도 있습니다. 최상위 dns는 주로 코어 내장 DNS 동작을 설정하며 기기 안의 모든 애플리케이션 DNS 설정을 자동으로 바꾸지는 않습니다. DNS 서버 주소를 설정한 뒤에도 실제 요청이 해당 해석기를 통과하는지 확인해야 합니다.

이름 해석 위치와 조회 경로 구분

SOCKS를 사용할 때 애플리케이션은 도메인 이름을 프록시에 그대로 전달할 수도 있고, 로컬에서 IP를 알아낸 뒤 연결할 수도 있습니다. HTTP 프록시 요청에는 보통 도메인이 포함되지만 애플리케이션에서 미리 이름을 해석할 수도 있습니다. 가상 네트워크 가로채기 환경에서는 DNS 요청을 가로채는 방식도 고려해야 합니다. 코어에 전달되는 값이 도메인인지 IP인지 확인해야 도메인 라우팅, 내장 DNS, 아웃바운드의 이름 해석이 각각 관여하는지 판단할 수 있습니다.

아래는 dns 항목 예시로, 정적 호스트 매핑, 서버 목록, 주소 계열 선택을 보여 줍니다. 예제에서는 접근 가능한 공용 DNS 주소를 사용하지만 실제 네트워크에서 해당 주소로 연결이 제한될 수 있으며 조직 내부 DNS가 필요할 수도 있습니다. 주소를 그대로 복사하면 모든 이름 해석 문제가 해결된다고 생각하지 말고 네트워크 환경에 맞춰 선택하세요.

{
  "dns": {
    "hosts": {
      "example.com": "192.0.2.10"
    },
    "servers": [
      "1.1.1.1",
      "8.8.8.8"
    ],
    "queryStrategy": "UseIPv4"
  }
}

192.0.2.10은 문서 예제용 주소입니다. 이 매핑은 형식 설명을 위한 것이며 실제 웹사이트에 사용할 수 없습니다. 정적 매핑을 사용하면 해당 도메인이 지정한 주소로 고정될 수 있어 로드 밸런싱, 서비스 이전, 인증서와의 관계에 문제가 생길 수 있습니다. 테스트가 끝나면 예제 매핑을 삭제하고 실제 도메인과 검증된 주소로 운영 규칙을 구성하세요.

DNS 정책과 라우팅 정책은 서로 다른 설정입니다

queryStrategy는 내장 DNS가 조회하거나 반환할 주소 계열을 설정합니다. 라우팅의 domainStrategy는 매칭 과정에서 도메인의 IP를 조회할지 결정합니다. 직결 아웃바운드에도 별도의 도메인 해석 정책이 있을 수 있습니다. 모두 이름 해석과 관련된 항목이지만 적용되는 위치는 다릅니다. 최상위 DNS만 수정해도 직결 아웃바운드가 같은 결과를 사용한다고 보장할 수 없으며, 모든 원격 프록시 아웃바운드가 대상을 로컬에서 해석하는 것도 아닙니다.

전통적인 직결 아웃바운드에서 내장 DNS 결과를 사용하려면 코어 지원 여부를 확인한 뒤 관련 정책을 설정할 수 있습니다. 아래 예제는 직결 아웃바운드에 UseIP를 추가해 도메인에 연결하기 전에 IP 주소를 조회하도록 합니다. 라우팅 단계의 매칭 순서를 결정하거나 다른 아웃바운드를 변경하지는 않습니다. 사용할 수 있는 정책 이름과 주소 계열 세부 값은 실제 실행 중인 코어의 항목 정의를 확인하세요.

{
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {
        "domainStrategy": "UseIP"
      }
    }
  ]
}

DNS 조회 요청을 보낼 경로도 필요합니다

내장 DNS가 보내는 네트워크 요청에는 도달 가능한 경로가 필요합니다. 일반 주소, 암호화 DNS 주소, 로컬 시스템 DNS 등 서버 유형에 따라 연결 방식이 다를 수 있으며 모두 같은 라우팅을 따르는 것은 아닙니다. DNS 요청에 태그를 지정해 별도로 라우팅하는 것은 추가 설정이므로 현재 코어의 지원 방식을 확인해야 합니다. DNS 주소를 설정하면 자동으로 선택한 원격 노드를 사용한다고 가정하지 마세요.

시작 단계의 의존성 순환도 피해야 합니다. 원격 노드 주소가 도메인인데 DNS 서버에 접속하려면 해당 원격 노드를 먼저 거쳐야 한다면, 원격 연결을 시작하기 전에 필요한 이름 해석이 완료되지 않을 수 있습니다. 암호화 DNS 서비스가 도메인으로 지정된 경우에도 최초 이름 해석이 필요합니다. 문제를 확인할 때는 먼저 노드 주소와 DNS 서버의 초기 이름 해석 경로가 작동하는지 확인한 뒤, 서비스 도메인을 최종적으로 어디서 해석할지 살펴보세요.

주소 계열, 캐시, 도메인별 DNS

기기에 IPv6 주소가 있다고 대상 방향의 IPv6 경로까지 정상인 것은 아닙니다. IPv4만 요청하면 일부 문제를 좁히는 데 도움이 될 수 있지만 모든 환경에서 계속 사용할 해결책은 아닙니다. 특정 주소 계열만 실패한다면 라우팅, 인터페이스, 상위 네트워크 연결을 확인하세요. 듀얼 스택 네트워크에서는 조회 결과와 실제 연결 대상이 다를 수 있으므로 DNS 응답 목록의 첫 번째 항목만 보지 말고 로그에 표시된 대상 주소를 확인해야 합니다.

DNS 서버를 바꿔도 애플리케이션, 운영체제, 코어, 상위 DNS에 이전 결과가 캐시되어 있을 수 있습니다. 검증하려면 기존 연결을 닫고 클라이언트에서 제공하는 방법으로 관련 구성 요소를 재시작하세요. 필요한 경우 시스템 캐시도 비운 다음 새 요청을 보내야 합니다. 기존 연결이 이전 주소를 계속 사용하는 것은 새 설정이 저장되지 않았다는 증거가 아닙니다. 캐시 비우기, 노드 변경, 규칙 수정을 동시에 하면 복구되더라도 원인을 알기 어렵습니다.

도메인별로 DNS 서버를 선택하면 규칙 목록, 예상 주소 범위, 폴백 설정이 서로 영향을 줄 수 있습니다. 서로 다른 DNS 응답이 실제로 필요한 경우에만 구성을 복잡하게 만들고 각 도메인 그룹의 용도를 기록하세요. 내부 도메인은 해당 도메인을 인식할 수 있는 내부 DNS 서버에서 해석해야 합니다. 연결은 되었는데 페이지가 열리지 않는다면 연결 후 인터넷이 안 될 때 확인할 항목을 참고해 시스템 프록시, 라우팅, 대상 서비스를 점검하세요.

06 / POLICY

policy 연결 및 통계 정책

policy는 사용자 등급별 연결 동작과 시스템 수준의 일부 통계 옵션을 설정합니다. 분할 라우팅 규칙이 아니므로 노드를 선택하지 않으며, 시간 제한 값을 낮춘다고 연결이 빨라지는 것도 아닙니다. 많은 설정은 정책을 직접 수정하지 않아도 정상적으로 작동합니다. 리소스 관리, 연결 유지, 통계처럼 분명한 요구가 있을 때만 항목을 하나씩 조정하고 실제 트래픽에서 결과를 확인하세요.

등급 객체와 사용자 항목의 연결 방식

levels는 "0"처럼 등급 번호를 객체 키로 사용합니다. 프로토콜의 사용자 객체에 있는 level 항목이 적용할 정책 등급을 선택하지만 프로토콜마다 사용자 구조는 다릅니다. 일부 로컬 인바운드 설정에는 기본 사용자 등급도 있습니다. level을 임의의 최상위 위치에 넣거나 노드 목록의 순서로 사용자 등급을 추측하지 마세요.

아래는 등급과 시스템 통계 설정의 계층을 보여 주는 정책 항목 예시입니다. 표시된 값은 설명을 위한 설정이며 모든 네트워크에 권장하는 매개변수가 아닙니다. 실제 코어에는 다른 기본값이나 동작 세부 사항이 있을 수 있습니다. 특히 연결 재사용, 전송 방식, 프로토콜 구현에 따라 다르므로 현재 지원 여부를 먼저 확인하세요. 분명한 요구 사항이 없다면 최적화 값이라고 알려진 설정을 복사하기보다 기본 정책을 유지하는 편이 관리하기 쉽습니다.

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

시간 제한 항목으로 해결할 수 있는 문제

handshake는 관련 연결의 핸드셰이크 단계에 적용되는 시간 제한이며, 웹페이지가 열려서 로딩을 마칠 때까지의 전체 시간이 아닙니다. 네트워크 지연, 상위 서버 응답, 프로토콜 협상으로 핸드셰이크가 늦어질 수 있습니다. 제한을 너무 짧게 설정하면 원래 완료될 연결도 중간에 종료될 수 있습니다. 핸드셰이크 시간 초과가 발생하면 시간 제한을 바꾸기 전에 서버 주소와 포트, 보안 매개변수를 확인하세요.

connIdle은 유휴 연결을 유지하는 시간을 제한합니다. 채팅, 푸시, 롱 폴링에서는 트래픽이 적은 상태가 오래 지속될 수 있으므로 유휴 시간을 지나치게 줄이면 재연결이 늘어납니다. 반대로 쓰지 않는 연결을 오래 유지하면 리소스를 점유할 수 있습니다. 평가할 때는 유휴 연결 수가 줄었다는 사실만으로 최적화되었다고 보지 말고, 연결 종료가 서비스에 문제를 일으키는지 확인하세요.

uplinkOnly와 downlinkOnly는 연결의 한쪽이 종료된 뒤 반대 방향 전송을 계속할 수 있는 시간에 적용됩니다. 일반적인 업로드·다운로드 속도 제한이 아니므로 대역폭 한도를 설정하는 데 사용하면 안 됩니다. 프로토콜이나 전송 계층에 따라 반쪽 닫기 처리가 다를 수 있습니다. 한 방향 전송이 중단된다면 두 값을 무작정 높이기보다 프로토콜 동작과 로그를 확인하세요.

통계 옵션만으로는 완전한 통계 시스템이 아닙니다

정책에서 통계 항목을 켜면 해당 카운터를 기록할 수 있을 뿐, 시각화 대시보드가 자동으로 생기지는 않습니다. 통계 시스템을 구성하려면 보통 통계 모듈과 관련 관리 인터페이스, 데이터를 읽을 도구가 더 필요합니다. 사용자별 통계에는 식별 가능한 사용자 정보도 필요합니다. 클라이언트가 관련 설정을 이미 생성했다면 클라이언트의 전체 구현을 먼저 확인하세요. 같은 포트에 관리 인터페이스를 별도로 추가해 충돌을 일으키지 않도록 주의해야 합니다.

클라이언트 화면의 트래픽 수치가 코어의 특정 카운터 하나와 같다고 볼 수는 없습니다. 시스템 트래픽 가로채기 범위, 연결 재시도, 프로토콜 오버헤드, 집계 위치에 따라 값이 달라집니다. 트래픽을 비교할 때는 어느 계층에서 언제부터 집계했는지, 모든 인바운드를 포함하는지 먼저 확인하세요. 화면에 표시된 수치 하나를 상위 서비스의 과금 기준으로 간주하거나 통계 범위를 모른 채 집계 오류라고 판단하면 안 됩니다.

모든 상황에 같은 값을 적용하기보다 실제 사용 환경에서 검증

정책을 변경했다면 실제 사용 시나리오를 기준으로 검증하세요. 짧은 웹 요청은 첫 연결과 연속 요청을 확인하고, 지속 연결 애플리케이션은 유휴 상태 이후에도 데이터가 다시 오가는지 살펴봅니다. 대용량 파일 전송은 한쪽 연결 종료나 연결 유지 설정 때문에 전송이 중간에 끊기지 않는지 확인하세요. 한 번에 항목 하나만 바꾸고 기존 값, 테스트 방법, 결과를 기록해야 네트워크 변동과 정책의 영향을 구분할 수 있습니다.

기기 리소스가 부족하다면 중복 실행 중인 코어, 불필요한 속도 측정 작업, 지나친 백그라운드 요청도 확인하세요. 정책은 모든 리소스 문제를 해결하는 만능 스위치가 아닙니다. 연결 관리가 병목이라는 근거가 없다면 모든 시간 제한을 줄이기보다 불필요한 작업과 사용하지 않는 인바운드를 정리하는 편이 효과적입니다. 원래 상태로 되돌릴 때는 클라이언트 기본 정책을 복원한 뒤 같은 테스트를 다시 진행해 출처가 불분명한 설정이 계속 남지 않도록 하세요.

07 / LOG

log 로그와 오류 확인

로그는 특정 요청에서 어떤 일이 있었는지 보여 주지만, 영어 오류 한 줄만으로 원인을 확정할 수는 없습니다. 요청 시간, 인바운드 출처, 대상 주소, 아웃바운드 태그, 이후 상태를 함께 살펴보세요. 백그라운드 애플리케이션은 계속 연결을 시도하므로 여러 사이트를 동시에 테스트하면 다른 요청의 오류를 현재 작업과 혼동하기 쉽습니다. 진단을 시작하기 전에 트래픽 범위를 좁히고 명확한 대상 하나로 재현하세요.

로그 수준과 출력 위치

loglevel은 오류 로그의 상세 수준을 제어합니다. 일반적인 수준으로는 debug, info, warning, error, none이 있습니다. 평소에는 필요한 정보만 기록하는 수준을 사용하고, 라우팅이나 연결을 확인할 때만 상세 수준을 일시적으로 높일 수 있습니다. 상세 로그에는 대상 정보가 포함될 수 있고 양도 많아질 수 있으므로 문제를 찾은 뒤에는 원래 설정으로 복구하세요.

{
  "log": {
    "access": "access.log",
    "error": "error.log",
    "loglevel": "info"
  }
}

아래는 파일 출력 항목 예시입니다. 상대 경로는 보통 프로세스의 작업 디렉터리를 기준으로 하며 설정 파일이 있는 디렉터리와 다를 수 있습니다. 그래픽 클라이언트가 표준 출력을 가로채 실행 로그 창에 표시할 수도 있습니다. 로그 파일을 찾을 수 없다고 코어가 실행되지 않는다고 판단하지 마세요. 실행 방식, 작업 디렉터리, 디렉터리 쓰기 권한을 먼저 확인하세요. 경로를 고정하려면 기기에 실제로 존재하며 쓰기가 허용된 경로를 지정해야 합니다.

접속 로그와 오류 로그는 용도가 다릅니다. 접속 기록은 요청 수신과 경로를 확인하는 데 도움이 되고, 오류 기록은 비정상 상황을 보여 줍니다. 하지만 접속 기록이 있다고 대상 콘텐츠가 끝까지 전송됐다는 뜻은 아닙니다. 표시되는 항목은 코어와 로그 수준에 따라 다를 수 있습니다. 예상한 아웃바운드 태그가 보이지 않으면 로그 상세 수준을 일시적으로 높이거나 실제 실행 설정에서 규칙을 확인하세요. 기본 경로를 추측해서는 안 됩니다.

요청 처리 순서에 따라 자주 발생하는 오류 확인

connection refused는 보통 대상 주소에서 연결을 명시적으로 거부했다는 뜻입니다. 대상이 로컬 프록시 포트라면 코어가 수신 중인지 확인하세요. 원격 노드 포트라면 서버 실행 여부와 주소, 포트를 확인해야 합니다. 인증은 보통 연결이 성립된 뒤 진행되므로 이 오류가 곧 인증 실패를 의미하는 것은 아닙니다. 로그에 표시된 주소가 어느 계층의 주소인지 먼저 구분하세요.

i/o timeout은 읽기나 쓰기 단계에서 대기 시간이 초과됐다는 뜻이지만, 연결 수립, 핸드셰이크, 데이터 전송 중 어느 단계에서든 발생할 수 있습니다. 주소에 도달할 수 없거나, 응답이 없거나, 패킷이 경로에서 손실되거나, 프로토콜이 맞지 않아도 비슷하게 나타날 수 있습니다. 같은 요청의 앞선 로그를 찾아 마지막으로 완료된 단계를 확인하세요. 모든 시간 제한을 늘리면 대기 시간만 길어질 뿐 연결 경로가 복구되지 않을 수 있습니다.

TLS 관련 오류가 발생하면 시스템 시간, 서버 이름, 인증서 체인, 보안 설정을 확인하세요. IP 주소로 연결할 때와 도메인으로 인증서를 검증할 때 필요한 조건은 다를 수 있으며, 전송 계층의 호스트명도 인증서 이름과 같지 않을 수 있습니다. 서버가 특정 보안 프로토콜을 요구하는데 클라이언트에서 다른 프로토콜을 설정했다면 포트 연결은 가능해도 핸드셰이크는 실패할 수 있습니다. 모든 검증 옵션을 끄기보다 항목 조합을 올바르게 수정하세요.

시작 오류와 실행 중 오류를 구분해 처리

시작 전 오류는 보통 JSON 문법, 항목 유형, 인식할 수 없는 프로토콜, 데이터 파일, 포트 바인딩과 관련이 있습니다. 먼저 코어가 안정적으로 시작되도록 한 뒤 네트워크를 테스트하세요. 실행 중 오류는 요청별로 추적해야 합니다. 클라이언트가 계속 시작했다가 종료된다면 반복되는 시작 메시지를 정상 실행으로 착각하지 마세요. 처음 발생한 치명적 오류를 찾아야 합니다. 그 이후의 연결 실패는 코어가 이미 종료된 결과일 수 있습니다.

태그를 찾을 수 없다는 오류가 발생하면 규칙 참조와 아웃바운드 배열을 확인하세요. 분류 데이터 로드에 실패하면 데이터 파일과 분류 이름을 확인하고, 권한 오류는 출력 디렉터리와 네트워크 가로채기에 필요한 권한을 확인합니다. 오류를 없애려고 모듈 전체를 바로 삭제하지 마세요. 각 오류를 해당 설정 객체와 연결해 가능한 한 그 범위에서 수정한 뒤, 같은 시작 또는 요청 테스트를 다시 실행하세요.

필요한 근거를 남기고 민감 정보는 가리기

로그를 공유해 도움을 요청하기 전에 사용자 식별 정보, 전체 구독 주소, 원격 노드 인증 정보, 공개하고 싶지 않은 방문 대상을 삭제하세요. 스크린샷의 창 제목, 클립보드 내용, 사이드바도 확인해야 합니다. 문제 해결에 필요한 항목 이름, 오류 유형, 상대적인 시간 순서, 익명화한 태그는 남겨도 됩니다. 중요한 앞뒤 내용을 빼고 마지막 줄만 캡처하지 마세요.

테스트 시간, 사용한 인바운드, 대상, 예상 아웃바운드, 실제 결과를 기록해 일관된 근거를 남기세요. 규칙을 바꿨는데 오류 내용이 전혀 달라지지 않는다면 실행 설정이 실제로 업데이트됐는지, 이전 프로세스가 종료됐는지, 테스트 애플리케이션이 이전 연결을 재사용하고 있지 않은지 확인해야 합니다. 오류의 의미는 v2rayN 실행 로그로 문제 찾기에서 더 자세히 확인할 수 있습니다. 최종 판단은 현재 설정과 동일한 요청을 기준으로 하세요.

로그 파일의 보관 범위도 관리해야 합니다. 장시간 실행하는 환경에서는 클라이언트 기능에 따라 파일을 정기적으로 삭제하거나 순환시켜 디스크 사용량이 계속 늘지 않도록 하세요. 기록 중인 파일을 삭제해도 공간이 즉시 확보되는지는 운영체제에 따라 다르므로 관리 전에 로그 출력을 중지하거나 코어를 종료하는 것이 좋습니다. 로그는 재현과 진단에 필요한 범위에서 보관해야 하며 모든 접속을 무기한 기록하기 위한 것이 아닙니다.

08 / VALIDATION

설정 검증과 변경 관리

설정 검증은 텍스트, 구조, 시작, 경로, 실제 서비스의 다섯 단계로 나누어야 합니다. 텍스트를 읽을 수 있다고 항목이 유효한 것은 아니며, 항목이 유효해도 포트를 열 수 있다는 뜻은 아닙니다. 포트가 열려도 요청이 올바른 아웃바운드와 매칭된다는 보장은 없고, 연결에 성공해도 모든 애플리케이션의 트래픽이 가로채졌다는 뜻은 아닙니다. 단계별로 점검해야 상위 단계의 문제가 해결되기도 전에 하위 항목을 계속 수정하는 일을 막을 수 있습니다.

원본 설정과 변경 목적 기록

수정 전에 정상 작동하는 설정을 별도로 저장하고 해당 설정이 적용되는 클라이언트, 코어, 실행 모드를 기록하세요. 백업은 접근이 제한된 위치에 보관하고 인증 정보가 포함된 파일을 무심코 동기화하거나 공개하지 마세요. 파일명에는 용도와 관리 날짜를 표시할 수 있지만 ‘최종본’처럼 모호한 이름에만 의존하면 안 됩니다. 되돌릴 때는 파일을 열 수 있었다는 사실뿐 아니라 어떤 인바운드, 아웃바운드, 규칙에 해당하는지도 알아야 합니다.

변경할 때마다 예상 효과를 구체적으로 적으세요. 예를 들면 ‘지정한 도메인을 직결로 전환’ 또는 ‘테스트 인바운드 추가’처럼 작성할 수 있습니다. 그런 다음 효과를 직접 확인할 요청을 설계하세요. 도메인 하나만 수정하려는 경우 DNS와 연결 정책을 함께 바꾸지 마세요. 변경 범위가 작을수록 테스트 실패 시 확인할 차이가 적어지고 이번 변경을 취소할지 판단하기 쉽습니다.

1단계: 문법과 구조 확인

로컬 편집기의 JSON 진단 기능으로 괄호, 따옴표, 쉼표, 항목 유형을 확인하세요. 설정을 출처가 불분명한 온라인 도구에 업로드하지 마세요. 그런 다음 최상위 객체의 위치를 하나씩 확인합니다. 스니핑 설정은 단일 인바운드에, 아웃바운드 설정은 해당 아웃바운드에, 규칙은 routing.rules에 있어야 합니다. 구조상 위치가 잘못된 경우 일반 JSON 파싱은 성공할 수 있어 철자 오류보다 발견하기 어렵습니다.

모든 참조도 확인하세요. 규칙에 지정된 아웃바운드 태그가 실제로 존재하는지, 인바운드 태그가 정확히 일치하는지, 분류 이름이 현재 데이터 파일에 있는지, 로그 경로에 쓰기 권한이 있는지 확인합니다. 태그는 자동으로 동기화되는 변수 참조가 아니므로 한쪽을 수정해도 다른 쪽은 바뀌지 않습니다. 클라이언트 화면의 표시 이름을 코어 항목 값으로 착각하지 않도록 비교표에 표시 이름과 실제 태그를 함께 기록하는 것이 좋습니다.

2단계: 시작과 로컬 연결 경로

클라이언트가 제공하는 설정 검사나 실행 정보를 확인해 코어가 설정을 불러올 수 있는지 확인하세요. 코어마다 명령줄 검사 방법이 다를 수 있으므로 이 페이지에서는 특정 시작 매개변수를 공통 명령으로 안내하지 않습니다. 시작에 성공하면 로컬 수신 상태를 확인한 다음 프록시를 지원하는 테스트 애플리케이션에서 해당 인바운드를 지정하세요. 수신 기록이 없다면 프록시 주소, 포트, 애플리케이션 설정, 시스템 권한을 다시 확인합니다.

먼저 첫 장의 완전한 직결 기본 설정으로 되돌려 로컬 요청을 수신하고 전달할 수 있는지 확인할 수 있습니다. 기본 설정도 실패한다면 원격 노드의 보안 매개변수를 살펴볼 단계가 아닙니다. 기본 설정은 성공하지만 사용자 지정 설정이 실패한다면 인바운드, 아웃바운드, 라우팅, DNS, 정책 순으로 하나씩 복원하세요. 각 부분을 복원할 때마다 재시작하고 테스트해 처음 차이가 발생하는 지점을 찾습니다.

3단계: 라우팅과 실제 서비스 재확인

지정한 아웃바운드를 사용해야 하는 대상 하나와 해당 규칙의 영향을 받지 않아야 하는 대상 하나를 선택해 비교하세요. 두 요청의 실제 아웃바운드를 기록해 규칙의 범위가 넓어지지 않았는지 확인합니다. 도메인 규칙은 하위 도메인, 페이지 리소스, 리디렉션을 고려해야 합니다. 포트 규칙에서는 대상 포트와 로컬 수신 포트를 구분하세요. 웹페이지가 한 번 열렸는지만 보는 것보다 비교 테스트가 규칙의 의미와 실제 동작이 일치하는지 더 잘 보여 줍니다.

같은 코어 설정이라도 운영체제마다 파일 경로, 수신 권한, 네트워크 가로채기 설정 경로가 다를 수 있습니다. 애플리케이션의 자체 네트워크 설정이 데스크톱 환경 설정을 따르지 않을 수도 있습니다. 한 기기에서 작동한 설정의 노드만 바꾸면 다른 기기에서도 같은 경로로 연결된다고 단정하지 마세요. 처음 이전할 때는 인바운드와 권한을 다시 확인한 다음 프로토콜과 라우팅 로직을 재사용하세요.

업데이트, 되돌리기, 장기 관리

클라이언트를 업데이트하거나 코어를 바꾼 뒤에는 이전 설정과 변경 기록을 보관하고 생성된 설정에 기존 규칙이 그대로 있는지 확인하세요. 구독 업데이트는 주로 노드 정보를 바꾸며 전체 실행 설정의 버전 관리를 대신하지 않습니다. 사용자 지정 항목이 덮어써졌다면 클라이언트가 지원하는 지속 설정 경로를 이용하세요. 임시 파일을 계속 직접 수정하는 것을 정기 관리 방식으로 삼지 마세요.

문제가 생기면 먼저 최근에 변경한 관련 항목을 되돌린 뒤 같은 테스트를 다시 진행하세요. 복구되면 변경 전후를 비교해 특정 항목을 찾아야 합니다. 원인을 분석하지 않은 채 이전 파일 전체로 계속 덮어쓰지 마세요. 코어 간 차이가 관련된 문제라면 기존 프로토콜과 전송 조합을 유지하세요. 되돌리는 과정에서 클라이언트, 코어, 노드, 규칙을 동시에 바꾸면 테스트 조건이 모두 달라집니다.

일상적인 연결 작업은 시작 가이드의 기본 절차를 따르세요. 다른 플랫폼으로 옮기거나 클라이언트를 고를 때는 세 클라이언트 비교를 확인하고, 설치 파일은 다운로드 페이지에서 받을 수 있습니다. 이 페이지는 설정 항목을 찾아볼 수 있도록 구성되어 있습니다. 수신 문제는 인바운드, 연결 경로 문제는 아웃바운드, 매칭 문제는 라우팅, 도메인 문제는 DNS, 연결 유지 문제는 정책에서 확인한 뒤 로그와 비교 테스트로 결론을 검증하세요.