설정 파일 종합 참고

V2Ray JSON 설정 가이드

요청 흐름에 따라 inbounds, outbounds, routing, dns, policy를 항목별로 살펴봅니다.

처음 설치하거나 구독을 가져오는 경우 먼저 사용 가이드를 읽어 보세요. 이 페이지에서는 생성된 설정을 이해하고 항목 간 관계를 확인하며 특정 문제를 찾는 방법을 다룹니다. 빠른 시작 절차를 대신하지는 않습니다.

설정 파일 구조와 요청 흐름

V2Ray 설정 파일은 하나의 JSON 객체를 루트로 사용합니다. 파일을 읽을 때는 먼저 inbounds, outbounds, routing을 확인하세요. 인바운드는 애플리케이션의 요청을 받고, 라우팅은 요청을 어떤 아웃바운드로 보낼지 결정하며, 아웃바운드는 이후 연결을 처리합니다. dns는 코어에서 사용할 도메인 이름 해석 기능을 제공하고, policy는 일부 연결 시간 제한과 통계 옵션을 관리합니다. 항목끼리 참조 관계가 있지만 파일의 모든 항목이 위에서 아래로 차례로 실행되는 것은 아닙니다. 일반적으로 최상위 키의 위치는 처리 방식에 영향을 주지 않습니다.

혼동하기 쉬운 데이터 세 가지를 구분해야 합니다. 구독 데이터에는 원격 연결 정보가 담기고, 클라이언트 설정에는 인터페이스 옵션이 저장됩니다. 코어 실행 설정은 클라이언트가 이 정보를 조합해 코어에 전달한 결과입니다. 구독 내용이 완전한 JSON이라는 보장은 없고, 클라이언트 자체 설정 파일을 코어에서 바로 불러올 수 있는 것도 아닙니다. 서버 목록, 창 상태, 구독 갱신 시각 등이 들어 있는 파일은 확장자만 보고 실행 설정이라고 단정할 수 없습니다. 클라이언트 로그나 설정 확인 메뉴, 사용자 지정 설정 안내를 통해 파일의 용도를 확인하세요.

기본 구조: 로컬 프록시 인바운드와 직접 연결 아웃바운드

아래는 기본적인 V2Ray 스타일 설정 예시입니다. 루프백 주소에서 SOCKS와 HTTP 인바운드를 제공하며, 일반 요청은 모두 직접 연결합니다. 원격 프록시 서버 정보는 포함하지 않습니다. 인바운드, 아웃바운드, 라우팅의 연결 방식을 살펴보기 위한 예시이며, 구독으로 생성된 프록시 설정을 대신하지 않습니다. 예시 포트는 문서에서 정한 값이므로 사용 전에 다른 프로그램이 점유하고 있지 않은지 확인하세요. 현재 클라이언트가 혼합 인바운드를 생성한다면 실제 포트 구성은 다를 수 있습니다.

{
  "log": {
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "tag": "socks-in",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "auth": "noauth",
        "udp": true
      }
    },
    {
      "tag": "http-in",
      "listen": "127.0.0.1",
      "port": 10809,
      "protocol": "http",
      "settings": {}
    }
  ],
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {}
    }
  ],
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      }
    ]
  }
}

여기서 direct와 block은 사용자 지정 식별자이며 예약어가 아닙니다. 라우팅의 outboundTag는 아웃바운드 중 하나의 tag와 정확히 일치해야 합니다. 어떤 규칙에도 해당하지 않는 요청은 기본적으로 첫 번째 아웃바운드로 전달되므로 이 예시에서는 직접 연결됩니다. 사설 주소 규칙은 관련 지리 데이터 파일이 있어야 작동합니다. 실행 환경에 해당 파일이 없다면 먼저 리소스 로딩 문제를 해결하거나, 용도를 파악한 뒤 명확한 주소 범위로 대체하세요. 시작 오류를 무시해서는 안 됩니다.

JSON 문법과 코어 동작을 따로 확인하기

표준 JSON에서는 키와 문자열을 큰따옴표로 묶고, 숫자와 불리언 값에는 따옴표를 붙이지 않습니다. 배열과 객체의 마지막 항목 뒤에 쉼표를 붙여서도 안 됩니다. 이 문서의 코드 블록은 모두 표준 JSON 형식이며 설정 내부에 주석을 넣지 않았습니다. 일부 로딩 방식에서 확장 문법을 허용하더라도 특정 클라이언트에서 받아들인 형식이 모든 코어에서도 통한다고 볼 수는 없습니다. 복사할 때는 코드 내용만 가져오고 제목, 설명, 코드 블록 경계는 파일에 넣지 마세요.

문법에 문제가 없어도 항목이 유효하다는 뜻은 아닙니다. "port": 10808은 숫자형 포트이고 "udp": true는 불리언 옵션입니다. 이를 문자열로 쓰면 파싱에 실패하거나 예상하지 못한 동작이 발생할 수 있습니다. 중복 키도 확인해야 합니다. 파서마다 처리 방식이 다를 수 있으므로 나중 값이 앞선 값을 덮어쓰리라 기대하기보다 중복 정의를 삭제하세요. 수정 후에는 구조, 참조 관계, 실제 실행 결과를 순서대로 확인해야 하며 어느 한 단계도 다른 단계를 대신할 수 없습니다.

이후 장의 짧은 예시는 모두 특정 항목을 교체하거나 이해하기 위한 부분 설정이며, 단독으로는 실행 가능한 전체 파일이 아닙니다. 클라이언트가 생성한 설정이 있다면 복사본에서 대상 항목 하나만 수정하고 나머지 유효한 내용은 유지하세요. 여러 항목의 연결 관계를 보여 주는 자세한 예시는 설정 파일 JSON 구조 살펴보기에서 확인할 수 있습니다.

inbounds: 리스닝 주소·포트·인바운드 프로토콜

inbounds는 요청을 받는 진입점을 각각 정의하는 배열입니다. 어떤 주소와 포트에서 수신하는지, 어떤 프로토콜을 사용하는지, 이 진입점에 어떤 식별자를 지정하는지 확인할 수 있습니다. 애플리케이션은 인바운드와 일치하는 프록시 프로토콜 및 포트를 사용해야 합니다. 브라우저에서 HTTP 프록시를 설정했다면 HTTP 인바운드에 연결해야 하고, SOCKS를 지원하는 앱은 SOCKS 인바운드에 연결할 수 있습니다. 시스템 프록시에 숫자만 입력한다고 해서 해당 포트가 앱이 기대하는 프로토콜로 자동 전환되지는 않습니다.

listen은 요청을 받을 범위를 지정합니다. 한 대의 기기에서 사용할 때는 우선 127.0.0.1에 바인딩해 이 인바운드가 로컬 기기에서만 사용되도록 하세요. 모든 네트워크 인터페이스에 바인딩하면 접근 범위가 넓어지며 방화벽, 인증, 로컬 네트워크 접근 제어도 함께 고려해야 합니다. 웹페이지가 열리지 않을 때 일반적으로 적용할 해결책은 아닙니다. 루프백 주소도 주소 계열에 따라 다릅니다. 앱이 IPv6 루프백 주소에 연결하는데 서비스가 IPv4 루프백 주소만 수신하면 연결에 실패할 수 있습니다. 문제를 확인할 때는 설정에 실제로 지정된 수신 주소를 명시해 사용하세요.

SOCKS 인바운드의 UDP와 도메인 전달

아래 예시는 로컬 SOCKS 인바운드와 UDP 지원을 활성화합니다. auth가 noauth이면 이 인바운드에 SOCKS 사용자 이름과 비밀번호가 필요하지 않다는 뜻이지, 원격 노드에 인증 정보가 필요 없다는 뜻은 아닙니다. 루프백 주소에만 바인딩하므로 한 명이 사용하는 데스크톱의 로컬 앱에 적합합니다. 여러 기기와 공유하는 인바운드로 바꾸려면 수신 주소만 수정하지 말고 접근 범위를 다시 검토하세요.

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

udp를 활성화하면 인바운드가 해당 UDP 전달 요청을 받을 수 있지만, 모든 앱 트래픽이 코어에 들어오거나 모든 아웃바운드가 UDP 전송을 지원한다는 뜻은 아닙니다. 앱에서 호환되는 전달 방식을 사용해야 하며 아웃바운드 프로토콜과 원격 서비스도 해당 기능을 지원해야 합니다. 일반 웹페이지에 접속된다는 사실만으로 실시간 통신이나 다른 UDP 앱도 작동한다고 판단할 수는 없습니다.

도메인을 어디에서 해석하는지는 앱이 프록시 요청을 보내는 방식에 따라 달라집니다. 앱이 로컬에서 먼저 도메인을 해석한 뒤 대상 IP를 SOCKS에 전달할 수도 있고, 도메인을 프록시 쪽으로 전달할 수도 있습니다. 첫 번째 방식에서는 도메인 라우팅에 사용할 정보가 줄어들 수 있고, 두 번째 방식에서는 코어가 원래 도메인을 기준으로 규칙을 적용할 수 있습니다. 앱의 ‘프록시를 통해 도메인 해석’ 같은 옵션은 실제 동작을 확인해야 합니다. SOCKS라는 이름만으로 해석 위치를 추측하지 마세요.

HTTP 인바운드와 진입점 식별자

HTTP 프록시 인바운드는 시스템 프록시나 브라우저의 수동 프록시 설정에 자주 사용됩니다. HTTPS 사이트에 접속할 때 앱은 일반적으로 HTTP 프록시를 통해 터널을 구성하므로 로컬 HTTP 인바운드 자체에 사이트 인증서를 설정해야 하는 것은 아닙니다. 로컬 프록시 프로토콜, 대상 사이트 프로토콜, 원격 프록시 전송 계층을 하나의 설정 항목으로 혼동하지 마세요. 별도의 HTTP 인바운드를 사용한다면 시스템 프록시에 입력한 포트가 해당 인바운드와 일치해야 합니다. 클라이언트에서 혼합 인바운드를 사용한다면 현재 표시된 포트를 기준으로 하세요.

항목설명확인할 점
listen로컬 수신 주소앱의 연결 주소 계열과 일치
port로컬 수신 포트기존 리스너와 충돌하지 않아야 함
protocol인바운드 프로토콜앱의 프록시 유형과 일치
tag진입점 식별자라우팅에서 inboundTag로 참조

인바운드 tag는 포트 유형을 정하지 않지만 라우팅 조건으로 사용할 수 있습니다. 예를 들어 같은 컴퓨터의 인바운드 두 개에 각각 다른 tag를 지정한 뒤 inboundTag에 따라 서로 다른 아웃바운드로 보낼 수 있습니다. 식별자는 고유하고 짧으며 의미가 분명하게 정하세요. 식별자를 바꾸면 모든 참조도 함께 확인해야 합니다. 인바운드 tag와 아웃바운드 tag가 자동으로 짝을 이루는 것은 아닙니다. 이름이 같아도 자동으로 연결되지 않으며 실제 아웃바운드는 라우팅과 기본 아웃바운드 규칙에 따라 정해집니다.

포트 충돌을 확인할 때는 먼저 중복으로 실행 중인 클라이언트를 종료하고 로그에 바인딩 실패가 있는지 살펴보세요. 포트를 변경했다면 앱 설정과 시스템 프록시도 함께 갱신해야 합니다. JSON만 수정하면 이전 인바운드 주소가 남습니다. 클라이언트에서 코어를 다시 시작한 뒤 실제로 수신이 시작됐는지도 확인하세요. 인바운드가 존재하는 것, 앱이 연결한 것, 원격 주소에 접속한 것은 서로 다른 단계이므로 각각 검증해야 합니다. 로컬 인바운드 문제를 가리기 위해 서버를 계속 바꾸지 마세요.

outbounds: 아웃바운드 프로토콜·tag·기본 연결 경로

outbounds는 코어가 요청을 받은 뒤 어떤 방식으로 연결할지 정의합니다. 직접 연결 아웃바운드는 일반적으로 freedom, 차단 아웃바운드는 blackhole을 사용하며, 원격 프록시 아웃바운드는 연결 정보에 맞는 프로토콜을 사용합니다. 프로토콜 이름은 설정 구조를 결정하고 tag는 다른 항목에서 참조하는 식별자입니다. tag를 proxy로 바꿔도 직접 연결이 프록시 연결로 바뀌지는 않습니다. 실제 동작은 protocol, 프로토콜 설정, 전송 설정에 따라 달라집니다.

클라이언트가 생성한 설정을 읽을 때는 먼저 아웃바운드마다 tag를 적고 실제 용도를 표시하세요. 흔히 proxy, direct, block 같은 이름을 쓰지만 클라이언트마다 다를 수 있습니다. 라우팅에 outboundTag: "proxy"가 있으면 같은 이름의 아웃바운드가 있어야 합니다. 실제 이름이 다르다면 실행 설정에 표시된 식별자를 기준으로 하세요. 대소문자, 하이픈, 앞뒤 공백을 대충 넘기지 마세요.

직접 연결과 차단의 최소 설정

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

이 예시에서는 첫 번째 아웃바운드가 직접 연결입니다. 라우팅 규칙에 해당하지 않는 요청은 기본적으로 첫 번째 아웃바운드로 전달되므로 배열 순서를 바꾸면 많은 요청의 연결 경로가 달라질 수 있습니다. 순서 정리를 단순한 서식 변경으로 생각해서는 안 됩니다. 기본 연결을 프록시로 사용하려면 첫 번째 항목이 실제로 작동하는 프록시 아웃바운드인지 확인하거나 코어에서 지원하는 라우팅 방식으로 최종 규칙을 명시하세요. 이름만 맞추려고 내용이 비어 있는 프록시 아웃바운드를 추가하지 마세요.

차단 아웃바운드는 규칙에 해당하는 트래픽을 의도적으로 거부하거나 폐기할 때 사용합니다. 이는 원격 서버 연결 실패와 다릅니다. 차단 아웃바운드는 의도한 라우팅 결과일 수 있지만 연결 실패라면 네트워크나 원격 설정을 확인해야 합니다. 특정 도메인에 계속 접속할 수 없다면 먼저 차단 규칙에 해당하는지 확인하고 DNS를 바꾸세요. 규칙이 많아질수록 각 차단 규칙의 용도를 기록하는 것이 중요합니다. 설명은 유지보수 문서나 클라이언트 메모에 적으면 되며 표준 JSON 안에 억지로 넣을 필요는 없습니다.

프로토콜 설정과 전송 설정을 나누어 살펴보기

원격 프록시 아웃바운드는 여러 계층으로 나눠 이해할 수 있습니다. 서버 주소와 포트는 연결 위치를 지정하고, 프로토콜 설정은 인증 정보와 프로토콜 동작을 정하며, streamSettings는 하위 전송 계층과 보안 계층을 설정합니다. VMess, VLESS, Trojan의 항목은 서로 바꿔 쓸 수 없습니다. REALITY는 특정 코어에서 지원하는 보안 계층 방식이며, 아웃바운드 프로토콜 이름을 REALITY로 바꾸는 방식도 아닙니다. 구독을 가져온 결과를 확인할 때는 실제 프로토콜을 먼저 확인한 뒤 각 계층의 매개변수를 살펴보세요.

포트와 대상 주소가 같더라도 두 설정이 같다고 볼 수는 없습니다. 서버가 요구하는 전송 방식, TLS 서버 이름, 경로 또는 협상 매개변수 중 하나라도 맞지 않으면 연결 또는 핸드셰이크 단계에서 실패할 수 있습니다. 다른 노드 정보에서 비슷해 보이는 값을 가져오지 마세요. 이 문서는 실제 원격 인증 정보를 제공하지 않습니다. 사용할 권한이 있는 서비스의 설정에서 연결 정보를 확인하고 로그를 공유할 때는 인증 정보와 구독 주소를 가리세요.

서버 주소를 도메인으로 지정하면 이름 해석 과정도 필요합니다. 코어가 원격 서버에 연결하려면 먼저 주소에 해당하는 IP를 알아야 합니다. 이때 해석 과정이 아직 연결되지 않은 동일한 연결에 의존하도록 설정하면 시작 단계에서 순환 의존이 생길 수 있습니다. JSON 오류가 뚜렷하게 나타나지 않고 계속 시간 초과가 발생할 수도 있습니다. 문제를 확인할 때는 ‘원격 서버 주소 해석 실패’와 ‘대상 사이트 해석 실패’를 구분하세요. 요청 경로에서 발생 위치가 서로 다르므로 DNS 설정 하나만 봐서는 알 수 없습니다.

클라이언트는 현재 선택된 서버에 따라 프록시 아웃바운드를 다시 생성할 수 있습니다. 이때 임시 실행 파일을 직접 수정해도 잠시만 적용된 뒤 서버를 바꾸거나 재시작하면 덮어써질 수 있습니다. 아웃바운드 설정을 계속 유지하려면 클라이언트에서 지원하는 사용자 지정 설정 방식을 사용하세요. 데스크톱과 모바일 클라이언트의 관리 차이를 비교하려면 클라이언트 선택 가이드를 참고하세요. 서로 다른 클라이언트에서 내보낸 항목을 모두 그대로 합쳐 하나의 파일로 만들지 마세요.

아웃바운드를 검증할 때는 직접 연결되어야 하는 요청과 프록시를 거쳐야 하는 요청을 각각 하나 이상 선택해 확인하세요. 페이지를 한 번 열어 본 것만으로 라우팅이 예상대로 작동한다고 할 수 없습니다. 브라우저 캐시, 기존 연결, 앱 자체의 프록시 설정이 결과에 영향을 줄 수 있습니다. 수정한 뒤 기존 연결을 닫고 다시 테스트한 다음 로그의 대상 주소, 아웃바운드 식별자, 오류 발생 단계를 함께 확인하세요.

routing: 조건 매칭·규칙 순서·기본 경로

routing은 요청을 어느 아웃바운드로 보낼지 결정합니다. 규칙은 일반적으로 위에서 아래로 확인하며 처음 일치한 규칙의 출구를 사용합니다. 이후 규칙에서 ‘더 정확한’ 조건을 계속 찾지 않습니다. 따라서 규칙 순서는 설정 동작의 일부입니다. 범위가 넓은 규칙을 앞에 두면 뒤에 있는 좁은 범위의 규칙이 적용되지 않을 수 있습니다. 예외 규칙을 마지막에 두면 한 번도 일치하지 않을 수도 있습니다. 수정하기 전에 예외 규칙, 일반 분류 규칙, 최종 기본 규칙 순으로 적용할 내용을 정리하세요.

일반적으로 하나의 규칙에 서로 다른 조건 항목을 함께 지정하면 조건을 모두 충족해야 합니다. 같은 조건 배열 안에 값이 여러 개 있으면 그중 하나와 일치하는 방식으로 처리됩니다. 예를 들어 inboundTag와 domain을 함께 지정하면 특정 인바운드에서 들어온 요청 중 대상 도메인이 조건에 맞는 경우를 뜻합니다. 인바운드나 도메인 중 하나만 맞으면 된다는 의미가 아닙니다. 서로 다른 경로를 표현하려면 하나의 객체에 무관한 조건을 쌓기보다 별도 규칙으로 나누세요.

도메인 규칙을 먼저 정하고 주소 규칙을 추가하기

아래 예시는 매칭 순서를 보여 줍니다. 모든 일치 결과를 direct로 보내 조건 구조를 살펴볼 수 있습니다. 설정에 같은 이름의 아웃바운드가 이미 있어야 합니다. full:과 domain:은 예시용으로 예약된 도메인을 사용하고, 지리 데이터 파일에 의존하지 않도록 명시적인 사설 주소 범위를 사용합니다. 완성된 지역별 라우팅 설정은 아닙니다.

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

full:은 도메인 전체를 정확히 일치시키고, domain:은 지정 도메인과 하위 도메인을 매칭합니다. 후자는 같은 도메인에 속한 서비스들을 관리할 때 유용하지만 웹사이트의 페이지, 이미지, 인증 인터페이스가 여러 도메인에서 제공될 수 있습니다. 대표 도메인 하나가 모든 의존성을 포함한다고 단정하지 마세요. 일반 문자열과 정규 표현식에도 각각 다른 매칭 규칙이 있습니다. 일반 규칙을 관리할 때는 의도가 분명한 접두어를 우선 사용해 오매칭과 이후 설명 부담을 줄이세요.

geosite:와 geoip:는 온라인 조회 서비스가 아니라 데이터 집합을 참조합니다. 사용 가능 여부와 포함된 분류는 실행 환경의 데이터 파일 및 분류 내용에 따라 달라집니다. 규칙에 분류 이름이 적혀 있다고 해서 현재 코어가 해당 항목을 불러올 수 있는 것은 아닙니다. 외부 규칙을 가져올 때는 분류 존재 여부, 리소스 접근 가능 여부, 참조하는 tag의 정의 여부를 함께 확인하세요. JSON 괄호가 닫혀 있는지만 확인해서는 부족합니다.

domainStrategy는 DNS 서버 설정과 다릅니다

AsIs는 일반적으로 라우팅 단계에서 현재 가진 대상 정보를 기준으로 매칭하고 IP 조건을 위해 도메인을 먼저 해석하지 않는다는 뜻입니다. IPIfNonMatch는 도메인 규칙에 일치하지 않을 때 IP 매칭을 위해 해석을 시도합니다. IPOnDemand는 라우팅에 IP 정보가 필요할 때 해석을 시작합니다. 전략은 규칙 구조를 보고 선택해야 합니다. 일찍 해석할수록 정확하다고 볼 수는 없습니다. 추가 해석은 의존성을 늘리고 요청 처리 시점에도 영향을 줄 수 있습니다.

라우팅의 domainStrategy와 DNS의 queryStrategy는 서로 다른 문제를 처리합니다. 전자는 라우팅에 필요한 주소 정보를 언제 얻을지, 후자는 DNS 조회에서 어느 주소 계열을 우선할지를 정합니다. 직접 연결 아웃바운드에도 별도의 도메인 해석 전략이 있을 수 있습니다. 문제를 확인할 때는 막연히 ‘DNS를 켰다’고 하기보다 어느 단계에서 해석이 일어나는지 적어 보세요. 앱이 이미 도메인을 해석한 경우 코어가 도메인 정보를 얻을 수 있는지는 앱이 전달한 내용이나 스니핑 같은 추가 기능에도 달려 있습니다.

기본 경로는 따로 확인해야 합니다. 어떤 규칙에도 해당하지 않으면 첫 번째 아웃바운드가 선택됩니다. 마지막 아웃바운드가 기본 경로라고 잘못 생각하면 정반대로 판단하게 됩니다. 일부 클라이언트 인터페이스에서 final → proxy라고 표시하는 것은 최종 경로를 읽기 쉽게 요약한 것입니다. 코어 JSON에 공통으로 쓰이는 최상위 final 필드가 있다는 뜻은 아닙니다. 실제 생성된 규칙이나 첫 번째 아웃바운드를 살펴보고 인터페이스의 선택이 어떻게 반영됐는지 확인하세요.

규칙을 추가한 뒤에는 일치해야 하는 대상과 일치하지 않아야 하는 대상을 각각 테스트하세요. 새 규칙이 적용되지 않는다면 먼저 위쪽 규칙이 요청을 가로채는지 확인하고, 코어가 대상을 도메인으로 받는지 IP로 받는지 살펴본 다음 tag 참조와 리소스 로딩을 확인하세요. 시스템 프록시의 ‘전역’ 설정은 앱이 트래픽을 전달하는 방식에만 영향을 주며 코어 라우팅은 여전히 트래픽을 나눌 수 있습니다. 두 설정을 따로 확인하세요. 관련 설정 방법은 사용 가이드의 모드 선택을 참고하세요.

dns: 해석 서버·주소 계열·조회 경로

dns는 코어에서 사용할 수 있는 이름 해석 기능을 정의하지만, 이 항목이 있다고 해서 컴퓨터 전체의 DNS를 자동으로 맡는 것은 아닙니다. 앱, 운영체제, 브라우저, 코어가 각각 이름을 해석할 수 있습니다. 먼저 어느 계층에서 조회를 시작하는지 확인한 뒤 변경할 항목을 정하세요. 브라우저에서 암호화된 DNS를 직접 사용하는 경우 시스템 DNS를 바꿔도 영향을 받지 않을 수 있습니다. 앱이 도메인을 IP로 변환해 전달하면 코어가 예상한 도메인 규칙을 적용하지 못할 수도 있습니다.

설정이 예상대로 작동하는지 판단하려면 세 가지를 확인해야 합니다. 조회를 어디로 보내는지, 어떤 경로로 전달되는지, 결과 주소가 어느 단계에서 사용되는지입니다. 서버 주소만 바꾸면 첫 번째 항목만 달라질 뿐 나머지 두 항목까지 바뀌지는 않습니다. 원격 프록시 서버 주소, 라우팅에서 IP 매칭에 쓰이는 주소, 직접 연결 대상 주소는 서로 다른 위치에서 해석될 수 있습니다. 이 의존성을 기록해 두면 DNS 서버를 여러 개 추가하는 것보다 안정적으로 문제를 찾을 수 있습니다.

명시적 서버와 정적 hosts

아래는 일부 DNS 설정 예시입니다. 정적 hosts 항목은 예시 도메인을 루프백 주소에 연결하며 로컬 테스트에만 사용합니다. 일반적으로 사용할 때는 이 테스트 매핑을 삭제하세요. 서버 목록에는 명시적인 IP 주소를 사용해 DNS 서버의 도메인을 먼저 해석해야 하는 상황을 피합니다. 해당 서버에 실제로 연결할 수 있는지, 조회가 어떤 아웃바운드로 전달되는지는 코어 동작 및 라우팅 설정을 함께 확인해야 합니다.

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

hosts는 알려진 주소를 잠시 고정하거나 통제된 환경에서 이름 해석과 연결의 차이를 확인할 때 유용합니다. 주소가 바뀔 수 있는 서비스를 장기간 대신하는 용도로는 적합하지 않습니다. 루프백 주소에 매핑하면 해당 도메인이 로컬 기기를 가리킵니다. 기기에 해당 서비스가 없다면 연결 실패는 예상된 결과입니다. 문제 확인이 끝나면 테스트 매핑을 삭제하세요. 남겨 두면 다음에 발생한 문제의 원인이 DNS 서버가 아니라 이전 설정일 수 있습니다.

queryStrategy에서 자주 쓰이는 값은 UseIP, UseIPv4, UseIPv6이며 실제 지원 범위는 현재 코어에 따라 다릅니다. 듀얼 스택 네트워크에서 IPv6 주소가 조회된다고 해서 IPv6 연결이 가능하다는 뜻은 아닙니다. IPv4로 잠시 제한하면 주소 계열 문제를 확인하는 데 도움이 되지만, 한 주소 계열을 비활성화하는 것이 모든 네트워크에 맞는 고정 해법은 아닙니다. 원격 주소와 대상 주소, 운영체제의 네트워크 기능이 서로 맞는지도 확인하세요.

도메인별 DNS와 대체 동작 범위

더 복잡한 서버 객체에는 도메인 매칭 범위나 예상 주소 같은 조건을 넣어 서로 다른 도메인을 별도 DNS 서버에 전달할 수 있습니다. 이런 설정을 추가하기 전에 현재 코어가 지원하는 항목과 대체 동작을 확인하세요. 서버를 여러 개 지정했다고 해서 배열 순서대로 성공할 때까지 차례로 시도하는 것은 아닙니다. 매칭 조건, 대체 옵션, 조회 결과 판단이 모두 결정에 관여합니다. 명확한 요구가 없다면 이해하기 쉬운 기본 경로를 먼저 유지한 뒤 도메인별 정책을 단계적으로 추가하세요.

암호화 DNS를 사용할 때는 전송 암호화와 아웃바운드 선택도 구분해야 합니다. 암호화는 해당 경로에서 조회가 전송되는 방식을 설명할 뿐 요청이 어떤 프록시 아웃바운드를 거치는지는 정하지 않습니다. DNS 서버 주소 형식에 따라 처리 경로가 다를 수 있으므로 일반 라우팅에서 UDP 조회가 처리되는 방식을 모든 암호화 DNS에 그대로 적용하지 마세요. 설정 전에 사용할 방식의 라우팅 및 부트스트랩 조회 요구 사항을 확인하고 로그와 실제 요청으로 검증하세요.

DNS 순환 의존은 DNS 서버에 접근하려면 프록시가 필요한데 프록시 서버의 도메인 해석은 같은 DNS 서버에 의존하는 경우 자주 발생합니다. 이때 구조 검사를 통과하더라도 첫 연결을 시작하지 못할 수 있습니다. 해결하려면 필요한 초기 조회가 사용할 수 있는 경로를 마련해야 합니다. 시간 제한만 계속 늘리는 것은 해결책이 아닙니다. 프록시 서버 도메인, DNS 서버 주소, 사용 아웃바운드를 기록하면 순환 관계를 직접 확인하고 어느 지점에서 의존성을 끊을지 정할 수 있습니다.

DNS를 테스트할 때는 기존 페이지와 연결을 닫고 앱이 예상한 프록시 설정을 사용 중인지 확인한 뒤 대상 도메인의 조회 결과와 접속 결과를 비교하세요. 운영체제나 브라우저 캐시 때문에 변경 사항이 적용되지 않은 것처럼 보일 수 있고, 기존 연결을 재사용하면 새로운 조회를 건너뛸 수도 있습니다. 어느 계층의 캐시를 지울지는 실제로 조회를 시작한 주체에 따라 달라집니다. 구체적인 검사 절차는 DNS 조회 경로 확인 및 설정 점검에서 살펴보세요. 특정 테스트 페이지의 결과를 모든 앱의 동작과 동일하게 보면 안 됩니다.

policy: 사용자 등급·연결 시간 제한·통계

policy는 일부 연결 동작과 통계 옵션을 관리하며 원격 서버 선택이나 지역별 라우팅을 담당하지 않습니다. 일반적으로 levels와 system으로 나뉩니다. 전자는 사용자 등급별 정책을 정의하고 후자는 시스템 범위의 일부 통계를 제어합니다. 설정을 읽을 때는 먼저 해당 연결이 어떤 등급을 사용하는지 확인한 다음 그 등급에 실제로 어떤 항목이 지정됐는지 살펴보세요. 모든 사용자가 등급 0이라고 단정하면 프로토콜 사용자 항목에 지정된 다른 등급을 놓칠 수 있습니다.

JSON에서 등급 이름은 객체의 키이므로 예시에서는 문자열 "0"을 사용합니다. 프로토콜 설정에서 참조하는 level은 일반적으로 숫자입니다. 등급은 서버 우선순위나 노드 품질 점수가 아닙니다. 숫자가 높은 등급으로 바꿔도 연결 성능은 향상되지 않으며 다른 정책 묶음을 선택할 뿐입니다. 명확한 등급 구분이 필요하지 않다면 설정을 단순하게 유지하세요. 어떤 사용자도 참조하지 않는 등급을 추가하면 설정을 바꿨는데도 효과가 없다는 오해를 낳을 수 있습니다.

연결 시간 제한 부분 예시

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

이 값들은 항목 구조를 보여 주기 위한 것으로 모든 네트워크에 권장되는 최적화 값은 아닙니다. handshake는 핸드셰이크 단계에서 허용하는 시간이며 단위는 초입니다. connIdle은 연결 유휴 시간 제한과 관련이 있습니다. uplinkOnly와 downlinkOnly는 한쪽 방향의 전송이 끝난 뒤 다른 방향을 유지할 시간을 지정합니다. 이 값들은 주로 연결 수명에 영향을 주며 경로 혼잡, 원격 서비스 처리 능력, 로컬 무선 네트워크 품질을 바꾸지는 않습니다.

핸드셰이크 시간 제한이 너무 짧으면 네트워크가 불안정할 때 연결이 성립하기 전에 종료될 수 있습니다. 반대로 너무 길면 실제로 연결할 수 없는 대상에 앱이 더 오래 기다릴 수 있습니다. 변경 필요성을 판단하려면 오류가 발생한 단계를 확인해야 합니다. 로그에 서버 이름이나 보안 계층 매개변수 불일치가 표시된다면 시간을 늘려도 설정 오류는 해결되지 않습니다. 로컬 포트 바인딩 실패라면 policy도 해결책이 아닙니다. 먼저 실패 위치를 찾고 시간 제한을 조정할지 결정하세요.

통계 옵션과 클라이언트 화면은 따로 확인하기

사용자 통계와 인바운드 통계는 서로 다른 범위를 나타냅니다. 통계 옵션을 켠다고 해서 클라이언트 화면에 해당 정보가 자동으로 표시되는 것은 아닙니다. 코어 통계 모듈, 조회 인터페이스, 클라이언트의 읽기 기능이 함께 필요할 수 있습니다. 일부 통계는 사용자를 식별할 수 있는 표시 정보도 요구합니다. 수집 및 조회 경로를 확인하지 않고 옵션만 복사하면 결과가 계속 비어 있을 수 있습니다. 화면에 표시되지 않는다는 이유만으로 네트워크 연결이 코어를 거치지 않았다고 판단하지 마세요.

클라이언트는 앱 상태, 연결 기록, 기타 실행 정보를 자체적으로 관리할 수 있으며 이 정보가 모두 policy에서 만들어지는 것은 아닙니다. 내보낸 설정을 볼 때는 ‘코어가 수집하는가’와 ‘인터페이스에 표시되는가’를 구분하세요. 문제 해결을 위한 임시 통계는 확인할 대상을 정하는 것만으로 충분하며 모든 옵션을 켤 필요는 없습니다. 실행 기록을 장기간 보관한다면 디스크 사용량과 로그에 방문 대상이 포함될 가능성도 고려해야 합니다.

항목 그룹확인할 내용대신할 수 없는 항목
handshake핸드셰이크 대기 시간원격 설정 확인
connIdle유휴 연결 정리라우팅 및 DNS 설정
uplinkOnly한쪽 방향 종료 후 연결 유지앱의 장시간 연결 설계
statsUserUplink사용자 업로드 통계통계 인터페이스와 조회 설정

버퍼 관련 정책도 이른바 일반 성능 설정을 그대로 복사해서는 안 됩니다. 연결 수, 앱의 데이터 패턴, 기기 메모리가 함께 자원 사용량을 결정합니다. 버퍼를 무작정 늘리면 실제 응답은 개선되지 않고 메모리 사용량만 증가할 수 있습니다. 코어마다 지원 항목이나 기본값도 달라질 수 있습니다. 익숙하지 않은 정책 항목은 현재 코어 문서를 확인하세요. 이전 문서에 나왔다는 이유만으로 현재 클라이언트에서도 지원된다고 단정하지 마세요.

정책 변경 효과를 테스트해야 한다면 같은 앱, 같은 아웃바운드, 비슷한 네트워크 조건을 사용하고 관련 값 한 묶음만 바꾸세요. 변경 전 설정도 보관해야 합니다. 새 연결, 잠시 유휴 상태였다가 복구되는 연결, 장시간 유휴 후 다시 연결되는 상황을 모두 테스트하세요. 앱에 하트비트가 있으면 예상한 유휴 상태에 진입하지 않을 수 있습니다. 다운로드를 한 번 계속하는 것만으로는 유휴 연결 정리 동작을 검증할 수 없습니다. 해당 항목이 실제로 관리하는 상황을 확인하세요.

기본 설정으로 요구 사항을 충족한다면 policy 전체를 명시적으로 작성할 필요가 없습니다. 항목을 생략하면 현재 코어의 기본 동작을 사용한다는 뜻이지 기능을 끈다는 뜻은 아닙니다. 모든 기본값을 펼쳐 적으면 유지보수 부담이 늘고 이전 코어의 선택이 새 환경에 고정될 수도 있습니다. 유지보수 문서에는 숫자만 적기보다 기본값을 덮어쓴 이유를 기록해야 나중에 변경이 여전히 필요한지 판단할 수 있습니다.

클라이언트 설정 생성과 사용자 지정 설정의 범위

v2rayN은 이 사이트에서 우선 추천하는 데스크톱 클라이언트로 Windows, macOS, Linux를 지원합니다. Android에서는 Xray를 주요 코어로 사용하는 v2rayNG 또는 V2Fly를 코어로 사용하는 v2flyNG를 이용할 수 있습니다. 클라이언트는 구독, 서버, 라우팅, 매개변수를 관리하는 인터페이스를 제공하지만 실제 동작은 선택한 코어와 생성된 설정에 따라 달라집니다. 설치 파일은 모두 클라이언트 다운로드 페이지에서 받을 수 있습니다. 이 가이드는 설정 항목 간 관계만 다루며 개별 코어 패키지나 원격 서버 정보를 제공하지 않습니다.

클라이언트 설정을 이해할 때 핵심은 ‘정보를 누가 관리하는가’입니다. 구독은 연결 정보를 갱신하고, 서버 선택은 현재 사용할 프록시 아웃바운드를 결정하며, 라우팅 템플릿은 트래픽 분할 규칙을 정합니다. 매개변수 설정은 인바운드 포트 및 기타 실행 옵션에 영향을 줍니다. 생성된 파일은 이 입력을 조합한 결과입니다. 생성 파일을 직접 수정하면 서버 변경, 구독 갱신, 코어 재시작, 앱 설정 변경 후 내용이 덮어써질 수 있습니다. JSON 저장에 실패한 것이 아니라 다음 생성 과정에서 관리 원본의 값이 다시 적용된 것입니다.

구독 관리는 코어 최상위 키가 아닙니다

subscription은 클라이언트 관리 개념이며 이 문서에서 다루는 V2Ray 코어 JSON의 일반적인 최상위 필드가 아닙니다. 구독 주소, 자동 갱신 주기, 그룹 이름은 클라이언트의 구독 관리 화면에서 설정해야 합니다. 실행 파일에 같은 이름의 객체를 추가해도 적용되지 않습니다. 구독 데이터는 인코딩된 텍스트나 프로토콜 링크 모음으로 제공될 수도 있습니다. 먼저 클라이언트가 이를 해석한 다음 코어에 필요한 프로토콜 및 전송 설정으로 변환합니다.

구독 갱신에 실패하면 기존에 사용할 수 있는 정보를 보존한 뒤 링크 유효 기간, 접속 경로, 응답 형식, 클라이언트 메시지를 확인하세요. 갱신 실패만으로 모든 서버를 삭제하지 마세요. 구독 주소를 공개 로그에 붙여 넣어서도 안 됩니다. 자동 갱신은 연결 정보 동기화를 담당할 뿐 로컬 포트 충돌이나 시스템 프록시 설정을 자동으로 해결하지 않습니다. 구체적인 해결 방법은 구독 갱신 실패 및 자동 새로고침 설정을 참고하세요.

시스템 프록시·라우팅·트래픽 처리 모드 따로 확인하기

시스템 프록시는 시스템 프록시 설정을 따르는 앱이 요청을 어느 로컬 인바운드로 전달할지 결정합니다. 코어 라우팅은 인바운드에 들어온 요청이 어떤 경로로 나갈지 정합니다. ‘시스템 프록시 자동 설정’을 선택해도 모든 앱의 트래픽이 처리되는 것은 아니며, ‘시스템 프록시 해제’를 선택해도 코어의 수신이 반드시 중단되는 것은 아닙니다. 앱 자체의 프록시 설정을 유지해 로컬 포트를 계속 사용하는 경우도 있습니다. 문제를 찾을 때는 운영체제와 앱 자체의 네트워크 옵션을 모두 확인하세요.

v2rayN에서 자주 사용하는 관련 메뉴는 ‘구독 그룹’, ‘라우팅 설정’, ‘매개변수 설정’, 시스템 프록시 메뉴입니다. 실제 이름과 위치는 인터페이스 종류에 따라 달라질 수 있습니다. Android 클라이언트는 일반적으로 시스템 권한을 받아 트래픽 처리 방식을 설정하므로 데스크톱 시스템 프록시 경로를 그대로 적용할 수 없습니다. 플랫폼을 바꿀 때는 필요한 기능과 연결 정보를 옮긴 뒤 새 플랫폼에서 권한, 리스닝 방식, 라우팅 모드를 확인하세요. 데스크톱에서 생성한 파일만 복사하지 마세요.

일부 클라이언트는 가상 네트워크 어댑터를 이용한 트래픽 처리 모드도 제공합니다. 이 방식은 일반 시스템 프록시와 처리 범위, 권한 요구 사항, DNS 경로가 다릅니다. 활성화한 뒤에는 로컬 네트워크 접근, 이름 해석, 다른 네트워크 앱과의 호환성을 다시 확인해야 합니다. HTTP 프록시만 사용하던 상황에서 얻은 결과를 그대로 적용할 수는 없습니다. 권한을 높여야 한다면 해당 모드가 정말 필요한지 먼저 판단하세요. 브라우저에서 수동 프록시를 설정할 수 있는데 포트 하나를 잘못 입력한 문제를 해결하겠다고 바로 트래픽 처리 방식을 바꿀 필요는 없습니다.

유지보수 가능한 수정 경로 남기기

장기간 사용자 지정 설정을 적용하기 전에 클라이언트가 제공하는 기능이 라우팅 규칙 편집인지, 사용자 지정 조각인지, 전체 사용자 지정 설정인지 확인하세요. 세 방식의 적용 범위는 서로 다릅니다. 일부 설정 조각은 자동 생성 내용에 병합되지만 전체 설정은 특정 자동 생성 과정을 건너뛸 수 있습니다. 현재 클라이언트의 안내와 생성 결과를 기준으로 판단하세요. 변경할 때마다 원래 설정을 보관하고 수정 메뉴, 대상 항목, 예상 결과를 기록하면 내용이 덮어써졌을 때 실제 관리 원본을 찾기 쉽습니다.

외부에서 받은 전체 설정을 불러오기 전에 추가 리스너, 제어 인터페이스, 원격 주소, 알 수 없는 라우팅 규칙이 포함됐는지 확인하세요. 실행 가능하다고 해서 현재 기기에 적합한 것은 아닙니다. 특히 리스닝 범위가 루프백 주소에서 모든 네트워크 인터페이스로 바뀌지 않았는지, 기존 시스템 프록시 포트가 올바른 인바운드와 연결되는지, 기본 아웃바운드 방향이 예상과 일치하는지 확인해야 합니다. 이해하지 못한 항목은 용도를 먼저 확인하세요. 시작되게 만들려고 보안 계층이나 라우팅 설정을 통째로 삭제하지 마세요.

설정 파일과 로그를 공유할 때도 주의가 필요합니다. 프로토콜 인증 정보, 전체 구독 링크, 방문 대상, 로컬 파일 경로에 개인정보가 포함될 수 있습니다. 공개적으로 도움을 요청할 때는 문제 재현에 필요한 항목과 오류 발생 단계만 남기고 민감한 값은 가린 뒤 코어 종류를 적으세요. 코어가 다른 오류는 문구가 비슷하다고 한데 묶어 처리할 수 없습니다. 문법 문제인지 지원 범위인지 네트워크 경로 문제인지 판단할 수 있도록 환경을 먼저 명확히 설명하세요.

설정 검증·로그 확인·이전 상태로 복구

요청 흐름에 따라 검증하세요. 설정을 불러올 수 있는지, 인바운드가 수신 중인지, 앱 요청이 인바운드로 들어오는지, 라우팅이 올바른 아웃바운드를 선택하는지, 원격 연결이 성립하는지, 대상 이름 해석과 접속이 끝나는지 차례로 확인합니다. 어느 단계에서든 실패할 수 있지만 사용자에게 보이는 증상은 그저 ‘웹페이지가 열리지 않음’일 때가 많습니다. 서버, DNS, 라우팅, 로컬 포트를 한꺼번에 바꾸지 마세요. 변수를 동시에 여러 개 바꾸면 잠시 복구되더라도 원인을 알기 어렵고 다음에 같은 문제를 해결하기도 힘듭니다.

시작하기 전에 작동이 확인된 클라이언트 설정이나 설정 파일 사본을 저장하고 현재 모드를 기록하세요. 그런 다음 한 항목만 수정하고 설정을 적용한 뒤 관련 코어를 재시작해 명확한 대상으로 테스트합니다. 파일만 저장하고 코어를 다시 불러오지 않았다면 기존 설정으로 동작하고 있을 수 있습니다. 반대로 클라이언트를 재시작한 뒤 설정이 사라진다면 이전 장으로 돌아가 설정 생성 출처를 확인하세요. 같은 임시 파일을 반복해서 수정하지 마세요.

설정 불러오기 실패와 연결 실패 구분하기

설정을 불러오는 단계에서 발생하는 문제에는 JSON 문법 오류, 항목 자료형 오류, 코어에서 지원하지 않는 프로토콜이나 필드, 라우팅 데이터 리소스 누락 등이 있습니다. 이때는 로그에서 가장 먼저 나타난 주요 오류를 확인하세요. 마지막의 ‘시작 실패’ 메시지만 봐서는 부족합니다. 오류 행 주변의 쉼표, 따옴표, 배열 경계를 특히 살펴보세요. 오류 위치가 실제 문제보다 뒤를 가리킬 때도 있으므로 앞선 객체의 끝부분도 다시 확인해야 합니다.

코어가 이미 시작됐는데 포트에 연결할 수 없다면 주소 계열 불일치, 포트 충돌, 앱이 이전 포트를 계속 사용하는지 확인하세요. 시스템 프록시 설정이 남아 있는 것도 흔한 원인입니다. 클라이언트를 종료했는데도 시스템이 존재하지 않는 로컬 리스너를 가리키면 시스템 프록시를 따르는 앱이 모두 영향을 받습니다. 먼저 올바른 시스템 프록시를 복구하고 클라이언트 실행 상태를 확인하세요. 원격 프로토콜 매개변수를 먼저 바꿀 필요는 없습니다.

로그 수준을 임시로 높여 확인하기

아래 예시는 로그 수준을 info로 설정해 연결 및 라우팅을 임시로 확인합니다. 클라이언트에 따라 로그가 자체 인터페이스에 표시되거나 지정된 파일에 기록될 수 있습니다. 파일 경로를 명시하지 않았다면 시작 방식에 따라 표시 위치가 달라집니다. 정보가 부족하면 문제를 확인하는 동안에만 상세 수준을 더 높이고, 작업이 끝나면 출력을 줄여 요청 정보가 장기간 쌓이지 않도록 하세요.

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

로그를 확인할 때는 같은 테스트에서 대상, 인바운드, 아웃바운드, 오류 발생 단계를 함께 찾으세요. 시간 초과는 이름 해석, 연결 수립, 핸드셰이크 중 어느 단계에서나 발생할 수 있으며 각 의미가 다릅니다. 연결 거부는 해당 주소와 포트에서 예상한 서비스가 제공되지 않거나 요청이 명시적으로 거부됐음을 나타내는 경우가 많습니다. 보안 계층 핸드셰이크에 실패했다면 서버 이름, 시간, 프로토콜 매개변수를 확인해야 합니다. 모든 오류를 노드 문제로 돌리지 말고 정상적인 연결 종료 기록을 장애 원인으로 오해하지 마세요.

증상우선 확인다음 단계
코어가 시작되지 않음문법·항목·리소스 로딩최근 수정한 항목 복구
로컬 인바운드에 연결할 수 없음리스닝 주소·포트·프로세스 상태앱에서 실제 사용하는 프록시 설정 확인
일부 사이트만 접속되지 않음규칙 순서와 조회 결과일치한 아웃바운드와 주소 계열 비교
서버 변경 후 작동하지 않음생성 설정과 사용자 지정 덮어쓰기새 아웃바운드 식별자 확인
절전 모드 해제 후 연결 끊김네트워크 변경과 기존 연결연결을 다시 만든 뒤 테스트

시스템 시간은 일부 프로토콜과 보안 핸드셰이크에도 영향을 줍니다. 로그에 인증 또는 인증서 시간 관련 오류가 표시되면 원격 정보를 확인하기 전에 기기의 시간과 시간대가 올바른지 확인하세요. 네트워크를 바꾼 뒤 문제가 생겼다면 기본 네트워크, DNS 서버 연결 가능 여부, 기존 연결 상태를 다시 살펴봐야 합니다. 유선 네트워크에서 무선 네트워크로 바뀌어도 기존 연결이 계속 작동한다고 볼 수 없습니다. 연결을 다시 만들면 환경 변화와 고정 설정 문제를 구분하는 데 도움이 됩니다.

이전 상태로 되돌릴 때는 오류가 난 항목 하나만 지우지 말고 관련된 수정 단위 전체를 복구해야 합니다. 예를 들어 아웃바운드 tag를 바꿨다면 라우팅 참조도 함께 되돌리고, 포트를 수정했다면 시스템 및 앱 프록시 설정도 같이 복구하세요. 복구한 뒤 코어를 다시 불러오고 시작 오류가 더 이상 없는지 로그에서 확인한 다음 처음 테스트를 반복하세요. 사본으로 복구해도 작동하지 않는다면 외부 네트워크나 원격 서비스가 바뀌었을 가능성도 고려해야 합니다. 같은 JSON 항목에 존재하지 않는 차이를 계속 찾지 마세요.

문제를 재현할 수 있는 기록에는 테스트한 앱, 트래픽 처리 방식, 코어 종류, 대상에 적용되어야 하는 라우팅 유형, 오류 발생 단계, 마지막 수정 사항이 포함되어야 합니다. 전체 구독 내용이나 모든 서버 정보를 공개할 필요는 없습니다. 인터페이스 기준의 점검 순서는 연결됐지만 웹페이지가 열리지 않을 때 확인할 사항을 참고하세요. 기본 절차를 다시 확인하려면 빠른 시작 가이드로 돌아가 정보를 가져오는 단계부터 모드 선택과 연결 검증까지 살펴보세요.

설정의 각 항목에는 명확한 출처가 있어야 하고, 모든 규칙에는 설명할 수 있는 용도가 있어야 하며, 모든 변경에는 실행 가능한 복구 방법이 있어야 합니다. 설정이 짧다고 해서 선택 항목을 모두 채울 필요는 없고, 길다고 기능이 더 완전한 것도 아닙니다. 필요한 인바운드, 아웃바운드, 규칙만 유지하고 기본 동작과 코어의 지원 범위를 이해하는 편이 출처를 알 수 없는 설정 조각을 계속 추가하는 것보다 읽고 문제를 해결하기 쉽습니다.

v2rayN 다운로드