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

JSON 구조와 설정 항목 개요

클라이언트 설정과 커널 설정의 차이

JSON 설정은 프록시 커널이 연결을 수신하고, 출구를 선택하고, 도메인을 조회하며, 세션을 관리하는 방식을 정의합니다. 클라이언트의 모든 설정을 담는 것은 아닙니다. v2rayN의 창 상태, 구독 그룹, 시스템 프록시 설정, 자동 업데이트 간격은 대개 클라이언트 자체 데이터입니다. 클라이언트는 커널을 시작할 때 이 데이터를 바탕으로 실행 설정을 생성합니다. v2rayNG와 v2flyNG도 각기 다른 설정 관리 방식을 사용합니다. 먼저 지금 확인 중인 파일이 클라이언트 저장 파일인지, 내보낸 사용자 지정 설정인지, 이번 실행에 실제로 적용된 파일인지 확인하세요. 그렇지 않으면 설정을 올바르게 수정해도 실행 과정에 반영되지 않을 수 있습니다.

커널 설정의 최상위에는 보통 log, inbounds, outbounds, routing, dns, policy가 포함됩니다. 인바운드와 아웃바운드는 배열이므로 여러 객체를 정의할 수 있습니다. 라우팅과 정책은 객체이며, 내부에 규칙이나 단계별 설정이 들어갑니다. 파일에서 필드를 작성한 순서가 실행 순서를 뜻하지는 않습니다. 실제 동작에는 배열 순서와 참조 관계가 영향을 줍니다. 예를 들어 라우팅 규칙은 위에서부터 차례로 적용되며, 어느 규칙에도 해당하지 않는 연결은 보통 아웃바운드 배열의 첫 번째 항목을 사용합니다.

읽기 쉬운 최소 구성 만들기

다음은 JSON을 불러올 수 있는지, 루프백 주소에서 연결을 수신할 수 있는지, 이 기기에서 대상에 직접 접속할 수 있는지 확인하는 완전한 로컬 직결 테스트 설정입니다. SOCKS 인바운드와 직결 아웃바운드만 만들며, 원격 프록시 기능이나 시스템 프록시는 설정하지 않습니다. 앱이 이 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": []
  }
}

설정을 읽을 때는 먼저 논리적인 연결 흐름을 그려 보세요. 앱의 연결이 태그가 붙은 인바운드로 들어오면 라우팅이 대상 주소와 인바운드 태그를 확인하고, 마지막으로 특정 아웃바운드에 연결을 전달합니다. 도메인 조회가 필요하면 DNS가 관여하고, 정책은 핸드셰이크나 유휴 연결 등의 동작을 제한합니다. 이 흐름을 이해하는 편이 필드를 하나씩 외우는 것보다 유용합니다. 같은 문제도 서로 다른 계층에서 발생할 수 있기 때문입니다. 예를 들어 앱의 연결이 인바운드에 들어오지 않았다면 아웃바운드 프로토콜을 바꿔도 해결되지 않습니다. 아웃바운드 태그가 잘못되었다면 DNS를 수정해도 참조 문제는 그대로입니다.

문법, 병합, 수정 범위

이 가이드에서는 표준 JSON을 사용합니다. 키와 문자열은 큰따옴표로 감싸고, 불리언 값은 true 또는 false로 쓰며, 포트는 숫자로 표기합니다. 배열이나 객체의 마지막 항목 뒤에는 쉼표를 붙이지 않습니다. 일부 로더는 주석이나 확장 문법을 허용하지만 모든 클라이언트에서 사용할 수 있는 것은 아닙니다. 특히 중복 키는 피해야 합니다. 파서에 따라 기존 값이 덮어써지거나, 오류가 발생하거나, 알아채기 어려운 차이가 생길 수 있습니다. 두 설정을 합칠 때는 최상위 객체를 하나로 병합해야 하며, 루트 객체 두 개를 이어 붙이면 안 됩니다.

수정하기 전에 정상 작동하는 설정을 백업하고 어느 설정 항목을 바꿨는지 기록하세요. 그래픽 인터페이스에서 관리하는 설정은 해당 설정 화면에서 수정하는 것이 좋습니다. 자동 생성 파일을 직접 편집하면 재시작, 노드 전환, 구독 업데이트 후 덮어써질 수 있습니다. 사용자 지정 필드를 계속 유지해야 한다면 임시 파일 경로에 의존하기보다 클라이언트의 사용자 지정 설정 모드, 덮어쓰기 규칙, 라우팅 가져오기 기능을 먼저 확인하세요. 시스템마다 데이터 폴더가 다르므로 다른 사람의 화면에 나온 절대 경로를 그대로 사용하지 않는 편이 좋습니다.

커널 선택도 설정을 읽기 전에 확인해야 합니다. V2Fly와 Xray는 일부 프로토콜, 전송 이름, 확장 필드를 다르게 처리하므로 JSON 파일이라는 이유만으로 서로 바꿔 쓸 수 있다고 가정하지 마세요. 클라이언트에서 현재 커널을 확인한 뒤 해당 커널이 인식하는 필드인지 살펴보세요. 알 수 없는 필드나 프로토콜 오류가 발생하면 관련 객체부터 범위를 좁혀 확인하고, 설정 전체를 한 번에 바꾸지 마세요. 용어는 용어집에서 확인할 수 있으며, 실제 조작 절차는 안내 페이지를 참고하세요.

inbounds 인바운드와 로컬 리스닝

리스닝 주소, 포트, 프로토콜

inbounds는 커널이 연결을 수신하는 진입점을 정의합니다. 각 진입점에는 프로토콜과 관련 설정이 필요하며, 로컬에서 흔히 사용하는 프로토콜은 SOCKS와 HTTP입니다. listen은 리스닝 주소, port는 포트, tag는 라우팅에서 참조할 이름을 지정합니다. 태그는 설정 내부의 식별자일 뿐 시스템 프록시를 자동으로 만들거나 브라우저가 연결하도록 설정하지 않습니다. 앱에서 프록시를 사용할지는 앱 자체의 프록시 옵션, 운영체제 설정 또는 다른 트래픽 연결 방식에 따라 달라집니다.

이 기기에서만 사용할 경우 리스닝 주소를 127.0.0.1로 지정하면 IPv4 루프백 인터페이스로 범위를 제한할 수 있습니다. 0.0.0.0으로 리스닝하면 이 기기의 모든 IPv4 인터페이스에서 연결을 받습니다. LAN 기기에서 접속할 수 있는지는 방화벽과 네트워크 환경에 따라 다르지만, 노출 범위 자체가 달라집니다. 문제를 해결하겠다고 리스닝 범위를 무작정 넓히지 마세요. LAN에서 공유해야 한다면 인증, 허용할 접속 출처, 시스템 방화벽을 함께 설정하고 누가 이 출구를 사용할 수 있는지 명확히 해야 합니다.

포트는 이를 사용하는 앱의 설정과 일치해야 합니다. SOCKS와 HTTP는 서로 다른 접속 프로토콜이므로 포트 번호가 비슷하다는 이유로 바꿔 쓸 수 없습니다. 아래 예제는 두 프로토콜을 구분해 로컬에서 테스트할 수 있도록 각각의 진입점을 정의합니다. 포트는 예시일 뿐이며 모든 클라이언트의 기본값을 의미하지 않습니다. 클라이언트가 혼합 인바운드를 사용한다면 실제로 생성된 설정을 따르고, 중복 리스너를 추가하지 마세요.

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

UDP와 대상 정보 식별

SOCKS 설정의 udp는 해당 인바운드에서 관련 UDP 요청을 처리하도록 허용하지만, 모든 프로그램이 자동으로 UDP 프록시를 사용하게 하는 전역 스위치는 아닙니다. 앱이 해당 접속 방식을 지원해야 하며, 아웃바운드 프로토콜과 원격 서버도 UDP 트래픽을 전달할 수 있어야 합니다. 운영체제의 일반적인 HTTP 프록시 설정은 기기 전체의 UDP 트래픽을 처리한다는 뜻이 아닙니다. 웹페이지는 열리지만 실시간 통신에 실패한다면 이 불리언 값만 반복해서 바꾸기보다 앱의 접속 방식, 인바운드 지원 여부, 아웃바운드 기능을 각각 확인하세요.

sniffing은 일부 연결의 초기 데이터에서 대상 정보를 식별합니다. 일반적으로 destOverride에 HTTP 호스트 이름이나 TLS 서비스 이름을 식별할 유형을 지정해, 원래 대상이 IP 주소뿐일 때 도메인 라우팅을 돕습니다. 모든 연결에서 식별 결과를 얻을 수 있는 것은 아니며 임의의 암호화 데이터를 복호화하지도 않습니다. 프로토콜에서 식별 가능한 정보가 제공되는지, 클라이언트에서 어떤 옵션을 실제로 활성화했는지에 따라 결과가 달라집니다. 식별 기능을 켰다고 모든 도메인 규칙이 반드시 적용되는 것은 아닙니다.

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

위 객체는 설정의 루트가 아니라 대상 인바운드 안에 넣어야 합니다. 식별된 정보로 연결의 목적지를 바꿀지, 라우팅에만 사용할지는 커널마다 옵션과 동작이 다릅니다. 원래 IP 연결의 의미를 유지하려면 현재 커널이 지원하는 라우팅 전용 옵션을 확인하세요. 식별 기능이 올바른 DNS 설정을 대신하지도 않습니다. 앱이 도메인을 SOCKS에 전달하면 커널은 처음부터 도메인을 알 수 있으므로 도메인 규칙 적용을 위해 별도로 식별 기능을 사용할 필요가 없을 수도 있습니다.

리스닝 실패 시 확인 순서

시작할 때 주소가 이미 사용 중이라는 오류가 나오면 먼저 다른 클라이언트나 이전 커널 인스턴스가 실행 중인지 확인한 다음, 현재 설정에서 같은 주소와 포트를 중복 정의했는지 살펴보세요. 리스닝 포트를 바꾸면 브라우저의 수동 프록시, 앱 프록시, 클라이언트가 설정한 시스템 프록시도 함께 변경해야 합니다. JSON의 숫자만 바꾸면 앱은 계속 이전 포트로 연결하므로 커널이 응답하지 않는 것처럼 보일 수 있습니다. 자세한 내용은 로컬 포트 충돌 및 리스닝 포트 변경을 참고하세요.

시작 오류는 없는데 접속 기록이 보이지 않는다면 앱이 현재 인바운드에 실제로 연결되어 있는지, 앱 자체의 프록시 우회 목록이 있는지 확인하세요. IPv4와 IPv6 루프백 주소도 구분해야 하며, 한쪽에서 리스닝한다고 다른 쪽까지 처리된다고 가정하면 안 됩니다. 문제를 찾는 동안에는 진입점 하나와 테스트 앱 하나만 남겨 각 요청의 출처를 분명히 하세요. 진입점이 정상임을 확인한 뒤 다른 진입점과 복잡한 라우팅을 다시 추가하면 여러 네트워크 계층을 동시에 바꾸는 것보다 원인을 찾기 쉽습니다.

outbounds 아웃바운드와 태그 참조

프로토콜, 출구, 기본 동작

outbounds는 트래픽이 커널을 빠져나가는 방식을 정의합니다. 직결에는 보통 freedom, 연결 차단에는 보통 blackhole을 사용하며, 원격 프록시는 해당 프로토콜의 아웃바운드가 처리합니다. protocol에 따라 settings의 구조가 달라지므로 프로토콜 이름만 바꾸고 다른 프로토콜의 서버 필드를 그대로 사용하면 안 됩니다. 라우팅은 outboundTag를 통해 아웃바운드의 tag를 참조합니다. 따라서 태그는 고유하고 알아보기 쉽게 정하며, 이름을 바꾸면 참조도 함께 수정하세요.

라우팅 규칙에 해당하지 않는 트래픽은 보통 첫 번째 아웃바운드로 전달되므로 배열 순서가 실제 동작에 영향을 줍니다. 직결을 맨 앞에 두면 규칙에 해당하지 않는 트래픽이 직결되고, 차단 아웃바운드를 첫 번째에 두면 많은 연결이 즉시 실패할 수 있습니다. 아웃바운드 배열을 자동으로 최적의 항목을 선택하는 후보 목록처럼 사용하지 마세요. 일반 아웃바운드 객체를 나열한다고 연결 실패 시 재시도, 지연 시간 테스트, 부하 분산이 이루어지는 것은 아닙니다. 이런 기능에는 별도의 방식과 명시적인 설정이 필요합니다.

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

위 예제에는 출구 두 개만 정의되어 있으며, 어떤 요청을 차단할지는 지정하지 않습니다. 라우팅에서 block을 참조할 때만 해당 트래픽이 차단 아웃바운드로 전달됩니다. 라우팅 동작을 살펴보는 데는 쓸 수 있지만 원격 서버 설정을 대신하지는 않습니다. 원격 프록시 객체는 주소, 포트, 사용자 인증, 전송, 보안 매개변수 등 서버에서 제공한 정보와 일치해야 합니다. 이런 정보는 권한이 있는 출처에서 받아야 하며, 다른 프로토콜의 예제를 보고 임의로 추측하거나 공개된 문제 보고에 포함하지 마세요.

노드 정보와 커널 지원 범위

VMess, VLESS, Trojan, Shadowsocks는 인증 필드와 보안 모델이 서로 다릅니다. 구독을 가져오면 클라이언트가 공유 형식을 지원되는 내부 형식으로 변환한 뒤 커널 설정을 생성할 수 있습니다. 변환에 성공했더라도 모든 필드가 실행 조건을 충족하는 것은 아닙니다. 일부 프로토콜이나 전송 방식은 특정 커널을 필요로 하며, 클라이언트가 인식하지 못하는 확장 매개변수가 링크에 포함될 수도 있습니다. 커널을 바꾸기 전에 대상 프로토콜을 지원하는지 확인하고, 생성된 설정과 시작 로그를 살펴보세요.

원격 주소는 연결 대상이며 TLS 서비스 이름은 신원 확인에 사용됩니다. 두 값은 다를 수 있지만 임의로 바꿔서는 안 됩니다. 포트도 프로토콜 유형을 결정하지 않습니다. 같은 포트 번호에서 서로 다른 서비스가 동작할 수 있습니다. 연결 시간 초과가 반드시 인증 오류인 것은 아니며, 인증 거부가 항상 명확한 비밀번호 오류로 표시되는 것도 아닙니다. 일부 서비스는 연결을 닫기만 합니다. 주소 연결 가능 여부, 전송 연결, 보안 핸드셰이크, 프로토콜 인증 순서로 점검하면 모든 실패를 노드 문제로 단정하지 않을 수 있습니다.

필드	역할	확인할 사항
`tag`	아웃바운드 내부 이름	고유해야 하며 라우팅 참조와 일치해야 합니다
`protocol`	아웃바운드 프로토콜을 결정합니다	현재 커널의 지원 여부
`settings`	프로토콜별 매개변수	프로토콜에 맞는 구조인지 확인합니다
`streamSettings`	전송 및 보안 매개변수	원격 서버 설정과 일치해야 합니다

직결 DNS 조회와 아웃바운드 재사용

직결에도 DNS가 필요할 수 있습니다. 라우팅이 direct를 선택했더라도 대상이 도메인이라면 연결하기 전에 IP 주소를 확인해야 합니다. 라우팅 단계의 domainStrategy와 직결 아웃바운드 자체의 DNS 옵션은 서로 다른 단계에서 작동하므로 이름이 비슷하다고 같은 스위치로 보면 안 됩니다. 주소 유형이나 DNS 조회 출처를 제어하려면 DNS 모듈, 라우팅, 직결 아웃바운드의 설정을 각각 확인하고 로그에서 실제 연결 주소를 살펴보세요. 최종 페이지가 열리는지만으로 판단하지 마세요.

연결 재사용은 모든 프로토콜과 앱에 적용할 수 있는 일반적인 속도 향상 옵션이 아닙니다. 여러 논리적 연결이 하위 연결을 공유하는 방식이 달라져 문제 양상에도 영향을 줄 수 있습니다. 특정 사이트의 연결이 끊기거나, 장시간 연결에 문제가 생기거나, 전송 호환성 문제가 발생하면 먼저 기본 재사용 설정으로 기준을 세운 뒤 개별 항목을 비교하세요. 재사용, 전송, 보안 검증, 라우팅을 한꺼번에 변경하면 문제가 해결되어도 어떤 변경이 효과를 냈는지 알기 어렵습니다.

노드를 바꾸더라도 일관된 라우팅 태그 구조를 유지하세요. 클라이언트는 선택한 노드의 이름이 달라져도 규칙을 유지할 수 있도록 공통 아웃바운드 태그를 생성할 수 있습니다. 수동 설정에서는 참조를 직접 관리해야 합니다. 외부 규칙을 가져오기 전에 기존 아웃바운드 이름을 확인해 규칙이 존재하지 않는 태그를 가리키지 않도록 하세요. 지연 시간, 지역, 프로토콜에 따른 노드 차이는 노드 선택 및 테스트 지표 안내에서 확인할 수 있습니다. 다만 어떤 경우든 설정 참조가 정확해야 한다는 점은 변하지 않습니다.

streamSettings 전송 및 보안 매개변수

프록시 프로토콜과 전송 방식 구분하기

프록시 프로토콜은 인증과 트래픽 전달 방식을, 전송 계층은 연결을 실어 나르는 방식을, 보안 계층은 연결을 보호하고 검증하는 방식을 정합니다. 서로 다른 설정입니다. VLESS가 REALITY를 뜻하는 것도 아니고, WebSocket이 독립적인 프록시 인증 프로토콜인 것도 아닙니다. 같은 프록시 프로토콜에 서로 다른 전송 방식을 사용할 수 있으며, 보안 방식에 따라 지원되는 커널과 조합이 다릅니다. 설정을 설명할 때 이 세 계층을 분리해야 공유 링크의 각 매개변수가 어느 객체에 해당하는지 파악할 수 있습니다.

streamSettings는 관련 전송이 필요한 인바운드나 아웃바운드 객체 안에 위치하는 경우가 많습니다. network는 전송 유형을, security는 연결 보안 방식을 지정하고, 각각의 설정 객체에 세부 매개변수를 넣습니다. 이 설정만으로 원격 연결을 만들 수는 없으며, 빠진 인증 정보도 보완하지 못합니다. 아래는 전통적인 TCP 이름을 사용하는 TLS 부분 예제입니다. 현재 커널에서 해당 이름을 실제로 지원하고 서버도 그에 맞는 전송 방식을 제공할 때만 사용하세요. 커널을 확인하지 않고 그대로 붙여 넣으면 안 됩니다.

{
  "streamSettings": {
    "network": "tcp",
    "security": "tls",
    "tlsSettings": {
      "serverName": "example.org",
      "allowInsecure": false
    }
  }
}

예제의 example.org는 문서 설명용 도메인이며 프록시 접속에 사용할 수 있는 서버 주소가 아닙니다. 실제로는 서비스 이름이 정식 서비스에서 제공한 인증서 정보와 설정 조건에 맞아야 합니다. 커널 문서에서 다른 전송 이름이나 설정 구조를 사용한다면 해당 구조를 따르세요. 비슷해 보이는 이름으로 문자열만 바꾸면 안 됩니다. 호환성은 클라이언트 버튼의 한국어 번역이 아니라 현재 실행 중인 커널의 설정 규격을 기준으로 판단해야 합니다.

TLS 서비스 이름과 인증서 검증

serverName은 TLS 서버 신원을 처리할 때 사용되며, 인증서 이름이나 서버 선택과 관련되는 경우가 많습니다. 원격 연결 주소는 IP일 수도, 도메인일 수도 있습니다. IP 주소로 연결하더라도 의도한 핸드셰이크를 완료하려면 올바른 도메인 서비스 이름이 필요할 수 있습니다. 반대로 흔히 쓰이는 도메인을 아무렇게나 입력한다고 인증서가 유효해지는 것은 아닙니다. 인증서 이름 불일치, 불완전한 인증서 체인, 잘못된 시스템 시간, 중간 장비의 개입은 모두 보안 핸드셰이크 실패의 원인이 될 수 있습니다.

allowInsecure를 기본적인 해결 방법으로 사용하지 마세요. 신원 검증을 끄면 겉으로는 인증서 오류가 사라질 수 있지만 보안 경계도 달라집니다. 먼저 시스템 날짜, 서비스 이름, 인증서 유효 기간과 신뢰 체인을 확인한 다음 네트워크에서 인증서를 바꾸는 장비가 있는지 살펴보세요. 서비스에서 자체 신뢰 체계를 명시적으로 사용하는 경우 관리 절차에 따라 신뢰할 인증서를 설정해야 합니다. 모든 이상을 검증 생략으로 해결하지 마세요. 구독 업데이트 중 발생한 인증서 문제와 노드 핸드셰이크 인증서 문제도 따로 기록하세요.

WebSocket, 경로, 중간 프록시 전달

WebSocket을 사용한다면 경로, 요청 호스트, 리버스 프록시 전달 규칙이 서로 맞아야 합니다. TLS 서비스 이름, HTTP 요청의 호스트 필드, 하위 연결 주소는 역할이 다릅니다. 특정 배포 환경에서 값이 우연히 같더라도 서로 바꿔 쓸 수 있다는 뜻은 아닙니다. 경로의 대소문자나 끝의 슬래시, 중간 프록시의 경로 변경 때문에 요청이 의도한 서비스가 아니라 일반 웹페이지에 도달할 수 있습니다. 이 경우 전통적인 프록시 인증 오류가 아니라 HTTP 상태 오류로 나타날 수 있습니다.

전송 문제를 확인할 때는 먼저 서버에서 안내한 전송 유형을 확인한 다음 TLS 사용 여부, 요청 경로와 호스트 정보를 점검하세요. 브라우저에서 어떤 사이트를 열 수 있는지로 프록시 전송이 작동한다고 판단하지 마세요. 일반 웹페이지 요청과 특정 업그레이드 요청은 서버의 서로 다른 처리 경로를 거칠 수 있습니다. 클라이언트에서 가져온 노드라면 자동 생성 파일과 인터페이스를 오가며 수정해 설정 출처를 혼란스럽게 만들기보다, 먼저 인터페이스에 저장된 매개변수가 온전한지 확인하고 생성된 설정을 살펴보세요.

전송 및 프로토콜 기능은 커널에 따라 달라집니다. v2rayNG와 v2flyNG는 서로 다른 커널 생태계를 대상으로 하므로 한 클라이언트가 인식한 모든 링크 매개변수를 다른 클라이언트에서도 지원한다고 가정할 수 없습니다. 데스크톱 v2rayN에서도 선택한 커널이 노드 기능과 맞아야 합니다. 알 수 없는 전송, 인식되지 않는 필드, 핸드셰이크 단계의 즉시 중단이 발생하면 먼저 기능 호환성을 확인한 뒤 네트워크를 살펴보세요. 여러 매개변수를 연달아 바꾸며 운에 맡기지 마세요.

가능하다면 한 번에 하나의 전송 조합만 확인하세요. 원격 설정은 그대로 두고 연결 재사용과 정책은 기본값으로 유지한 상태에서 먼저 기본 핸드셰이크를 확인한 다음 고급 설정을 하나씩 복원합니다. 오류가 설정 파싱, TCP 연결, TLS 핸드셰이크, 프록시 데이터 교환 중 어느 단계에서 발생했는지 기록하세요. 이렇게 기록하면 확인할 객체를 정확히 좁힐 수 있으며, 도움말 센터에서 오류 유형별 해결 방법을 찾는 데도 도움이 됩니다. 설치 과정을 처음부터 반복할 필요가 없습니다.

routing 규칙 순서와 매칭 범위

규칙을 먼저 적용한 뒤 아웃바운드를 선택합니다

routing은 이미 커널에 들어온 연결을 어느 출구로 보낼지 결정합니다. 프록시를 사용하지 않는 앱의 트래픽을 커널로 가져오거나 운영체제 프록시를 켜는 기능은 아닙니다. 규칙은 일반적으로 배열의 위에서 아래 순서로 확인하며, 처음 일치하는 규칙이 연결 경로를 결정합니다. 따라서 범위가 명확한 예외를 앞에 두고, 넓은 범위의 기본 규칙을 뒤에 두세요. TCP와 UDP 전체를 처리하는 규칙이 앞에 있으면 그 뒤의 관련 규칙은 적용되지 않을 수 있습니다.

규칙 하나에 포함된 서로 다른 조건은 일반적으로 모두 일치해야 합니다. 같은 필드 배열에 후보 값을 여러 개 넣으면 보통 그중 하나만 일치해도 됩니다. 예를 들어 인바운드 태그와 도메인을 함께 지정하면 특정 인바운드에서 특정 도메인에 접속할 때만 규칙을 적용하려는 것입니다. 여러 IP나 도메인을 같은 출구로 보내려면 규칙을 분리하는 편이 명확합니다. 여러 조건을 한 규칙에 넣어 놓고 그중 하나만 일치해도 된다고 오해하지 마세요.

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": [
          "full:example.org"
        ],
        "outboundTag": "block"
      },
      {
        "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"
      }
    ]
  }
}

이 예제는 앞에서 정의한 direct 및 block 아웃바운드 태그를 사용합니다. 정확히 지정된 도메인은 차단하고, 나열된 로컬 주소 범위는 직결하며, 나머지는 기본 아웃바운드로 전달합니다. 규칙 작동 방식을 보여주는 예제일 뿐 완성된 접근 분류 설정은 아닙니다. 특히 AsIs에서는 IP 규칙에 맞추기 위해 도메인 대상을 자동으로 조회하지 않으므로, 사설 주소 대역을 추가했다고 최종적으로 LAN IP로 연결되는 모든 도메인이 처리되는 것은 아닙니다.

도메인 표현과 조회 전략

full:은 도메인과 정확히 일치하는 항목을 지정합니다. domain:은 일반적으로 지정된 도메인과 하위 도메인에 적용되며, regexp:는 정규식을 사용합니다. 일반 문자열 매칭은 예상보다 넓은 범위에 적용될 수 있고 규칙을 읽기도 어려우므로 가능한 한 명시적인 접두사를 사용하세요. 정규식을 JSON 문자열에 넣을 때는 JSON 이스케이프도 필요합니다. 예를 들어 정규식의 역슬래시는 올바르게 이스케이프해야 합니다. 규칙이 도메인 목록처럼 보여도 각 항목의 매칭 방식이 같다고 보장되지는 않습니다.

라우팅의 domainStrategy에서 흔히 사용하는 값은 AsIs, IPIfNonMatch, IPOnDemand입니다. 첫 번째 값은 라우팅 매칭을 위해 도메인을 능동적으로 조회하지 않습니다. 나머지 두 값은 각각 정해진 조건에서 조회 결과를 사용해 IP 규칙을 확인합니다. 조회 시점이 달라지면 요청 횟수, 규칙 적용, 문제 발생 경로가 달라질 수 있지만 더 빠르거나 정확하다고 단정할 수는 없습니다. IP 분류 규칙의 사용 여부와 DNS에 이용 가능한 경로가 있는지를 고려해 선택하세요.

필드	매칭 대상	주요 제한 사항
`domain`	대상 도메인	IP 주소만 있는 경우 대상 식별이 필요할 수 있습니다
`ip`	대상 주소 또는 조회 결과	조회 전략의 영향을 받습니다
`inboundTag`	연결이 들어온 인바운드	실제 인바운드 태그와 일치해야 합니다
`port`	대상 포트	로컬 리스닝 포트가 아닙니다

규칙 리소스와 모드 전환

geosite: 또는 geoip: 분류를 사용한다면 관련 리소스가 있는지, 내용이 예상과 맞는지, 클라이언트가 어떻게 업데이트하는지도 확인해야 합니다. 분류 이름은 커널이 모든 사이트를 알아서 인식하는 기능이 아니라 리소스 데이터를 참조하는 이름입니다. 리소스를 찾을 수 없다는 오류가 발생하면 리소스와 규칙이 서로 맞는지 확인하세요. 불러오기는 성공했지만 결과가 이상하다면 대상이 실제로 어떤 분류에 해당하는지 점검해야 합니다. 규칙 이름이 같아도 리소스 패키지에 따라 내용이 완전히 같지는 않을 수 있습니다.

클라이언트의 '전역' 또는 '우회' 모드는 보통 여러 라우팅 규칙을 생성하거나 전환합니다. 시스템 프록시는 어떤 앱 요청을 로컬 인바운드로 보낼지 결정합니다. 모드를 바꾼 뒤 수동으로 추가한 규칙이 유지되는지, 어디에 삽입되는지는 실제 설정에서 확인해야 합니다. 두 설정 계층의 자세한 설명은 시스템 프록시와 라우팅 모드의 차이를 참고하세요. 트레이 아이콘만 보고 모든 앱이 같은 경로를 사용한다고 판단하지 마세요.

규칙을 확인할 때는 결과를 명확히 구분할 수 있는 대상을 고르고, 관련 예외 규칙과 기본 규칙만 남긴 다음 로그의 인바운드 및 아웃바운드 태그를 확인하세요. 대상에 예상치 못한 규칙이 적용되면 중복 항목을 추가하기보다 앞쪽에 범위가 넓은 규칙이 있는지, 앱에서 도메인을 미리 IP로 조회했는지, 대상 식별이 작동했는지 확인하세요. 최소 규칙의 동작을 확인한 뒤 분류를 묶음별로 복원하면 어느 항목이 매칭 범위를 넓혔는지 찾을 수 있습니다.

dns 조회 경로와 주소 유형 선택

앱, 시스템, 커널의 DNS 조회 구분하기

DNS 문제는 먼저 어느 계층에서 조회가 일어나는지 확인해야 합니다. 앱이 직접 조회할 수도 있고, 운영체제가 앱 대신 조회할 수도 있으며, 커널이 라우팅이나 연결 단계에서 도메인을 조회할 수도 있습니다. 이 경로들은 함께 사용될 수 있습니다. 앱이 도메인을 먼저 IP 주소로 변환해 SOCKS에 전달하면 커널에 원래 대상 도메인이 아니라 IP만 전달될 수 있습니다. 앱이 도메인을 SOCKS에 직접 전달하면 커널은 도메인 대상을 그대로 받습니다. 경로에 따라 도메인 라우팅에 추가 식별이 필요한지, 어떤 DNS 설정이 요청에 실제로 적용되는지가 달라집니다.

최상위 dns를 설정해도 기기의 모든 도메인 조회를 가로채는 것은 아닙니다. 이 설정은 주로 커널에서 필요한 조회에 적용됩니다. 앱의 DNS 요청도 처리하는지는 트래픽 연결 방식과 DNS 전달 설계에 따라 달라집니다. 브라우저의 암호화 DNS 기능이 별도 경로를 사용할 수도 있습니다. 앱이 직접 조회하는지, 어떤 프록시 프로토콜을 사용하는지, 다른 DNS 기능이 활성화되어 있는지 기록해 확인하세요. 시스템 네트워크 설정만 보고 모든 조회의 출처를 단정하면 안 됩니다.

{
  "dns": {
    "servers": [
      "localhost"
    ],
    "queryStrategy": "UseIP"
  }
}

이 부분 예제는 커널이 시스템 DNS 조회 경로를 사용하고 두 주소 유형을 모두 조회하도록 합니다. DNS 설정의 적용 범위를 파악하기 위한 기준으로 적합하지만, 모든 네트워크에서 시스템 DNS로 대상에 접속할 수 있다는 뜻은 아닙니다. 여기서 localhost는 커널이 정한 시스템 조회 방식이며, 기기에서 루프백 주소로 리스닝하는 DNS 서버를 반드시 실행해야 한다는 의미가 아닙니다. DNS 서버를 별도로 지정하려면 현재 커널이 지원하는 서버 표기 방식을 사용하고 조회가 실제로 어떻게 전송되는지 확인하세요.

조회 전략과 라우팅 전략은 별도로 처리

queryStrategy는 커널 DNS 조회에서 사용할 주소 유형을 제어합니다. 흔히 쓰는 값은 UseIP, UseIPv4, UseIPv6입니다. IPv4로 제한하면 사용할 수 없는 IPv6 경로를 우회할 수 있지만 IPv6 주소만 있는 대상은 접속할 수 없게 됩니다. IPv6를 사용할 수 있는지는 기기의 인터페이스, 기본 경로, 출구, 대상에 따라 달라집니다. 시스템에 IPv6 주소가 표시된다는 이유만으로 전체 연결 경로가 작동한다고 판단하지 마세요.

라우팅의 domainStrategy는 규칙 매칭을 위해 도메인을 언제 조회할지 정하고, DNS 조회 전략은 조회 시 어떤 주소 유형을 요청할지 정합니다. 직결 아웃바운드의 관련 전략은 연결할 때 주소를 사용하는 방식을 정할 수도 있습니다. 세 설정은 서로 다른 단계에 적용됩니다. 한 필드를 수정한 뒤 접속이 복구되더라도 그 경로에 변화가 생겼다는 뜻일 뿐, 나머지 두 설정도 올바르다는 증거는 아닙니다. 작동하는 기준 설정을 보존한 채 하나씩 확인하고, 이름이 비슷한 전략을 모두 같은 값으로 바꾸지 마세요.

도메인별로 서로 다른 DNS 서버를 선택한다면 서버 객체의 도메인 범위, 기대하는 주소 필터, 대체 처리 방식도 확인해야 합니다. 서버에서 응답을 받았다고 해서 그 응답을 반드시 사용한다는 뜻은 아닙니다. 원하는 주소 조건에 맞지 않으면 커널이 다른 경로를 시도할 수 있습니다. 복잡한 분기 설정은 먼저 연결 가능한 DNS 조회 경로 하나로 시작한 뒤 분류와 대체 처리를 차례로 추가하세요. 그렇지 않으면 서버에 연결할 수 없는지, 조건 필터에 걸렸는지, 대체 경로가 제한되었는지 구분하기 어렵습니다.

부트스트랩 의존성과 순환 조회

원격 서버 주소가 도메인이라면 연결을 시작하기 전에 IP 주소를 알아야 합니다. 암호화 DNS 서버도 도메인을 사용한다면 먼저 해당 서버의 주소를 조회해야 합니다. 이때 조회 경로가 아직 연결되지 않은 프록시 출구에 의존하면 순환 의존성이 생길 수 있습니다. 시작 후 계속 시간 초과가 발생하고 실제 원격 핸드셰이크까지 진행되지 않는 것이 일반적인 증상입니다. 원격 주소와 조회 서버 주소, 각 연결의 출구를 따로 살펴보고 자체 결과에 의존하지 않는 도달 가능한 경로를 하나 이상 확보하세요.

DNS 조회가 라우팅을 거치는지, 로컬 리졸버가 처리하는지, 암호화된 조회가 프록시를 사용하는지는 서버 형식과 커널 동작에 따라 달라집니다. 최상위 객체에 설정했다는 이유만으로 판단할 수 없습니다. 특정 로컬 처리 동작을 하는 서버 형식에서는 일반 라우팅 태그가 적용된다고 가정해서도 안 됩니다. 현재 커널에서 서버 유형별 설명을 확인하고 로그와 실제 요청 경로로 검증하세요. DNS 주소를 입력했으니 모든 조회가 지정된 출구를 사용한다고 생각하는 것은 흔한 오해입니다.

특정 도메인에 접속할 수 없다면 먼저 응답이 있었는지, 어떤 주소 유형으로 응답했는지 기록한 뒤 연결 대상 주소에 도달할 수 있는지 확인하세요. 조회에 성공해도 연결된다는 뜻은 아니며, IP 주소에 연결할 수 있어도 TLS 서비스 이름이 올바르다는 뜻은 아닙니다. 한 앱에서만 문제가 생기면 먼저 해당 앱의 DNS 설정을 비교하세요. 모든 앱에서 같은 문제가 발생하면 공통 DNS 경로와 출구를 확인합니다. 증상별 해결 방법은 도움말 센터에서 확인할 수 있습니다. DNS 문제를 해결하려고 인증서 검증을 바로 끄지 마세요.

policy 세션 정책과 통계 설정

단계별 정책은 라우팅 우선순위가 아닙니다

policy는 세션 수준의 리소스 및 시간 제한 동작을 관리합니다. levels는 사용자 수준별 정책을 설정하고, system은 시스템 수준의 통계 옵션 등을 관리합니다. 단계는 규칙 우선순위도 연결 속도 설정도 아닙니다. 관련 프로토콜 사용자나 연결에서 해당 단계가 실제로 사용될 때만 정책이 적용됩니다. 클라이언트가 설정을 생성할 때 기본 단계를 사용할 수 있습니다. 단계 객체를 직접 추가해도 모든 연결이 자동으로 그 단계로 전환되는 것은 아닙니다.

JSON에서 단계 키는 "0"처럼 문자열로 씁니다. 내부 필드는 규격에 따라 숫자나 불리언 값으로 설정합니다. 정책은 아웃바운드를 만들거나 인증서 문제를 해결하지 않으며, 라우팅에서 선택되지 않은 노드를 연결에 자동으로 참여시키지도 않습니다. 값을 조정하기 전에 문제의 원인이 핸드셰이크 시간 초과인지, 유휴 세션 종료인지, 통계 누락인지 확인하세요. JSON을 불러오거나 포트를 열 때 발생하는 오류에는 정책이 아직 적용되지 않았으므로 이런 값을 수정해도 원인을 해결할 수 없습니다.

{
  "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는 세션에서 한쪽 방향만 전송될 때의 대기 동작을 다룹니다. 일부 프로토콜에서는 연결을 반쪽 닫기 상태로 두는 것이 정상이며, 바로 오류라고 볼 수 없습니다. 업로드, 스트리밍 응답, 긴 폴링에 특별한 요구 사항이 있는 앱은 먼저 기본 정책으로 확인한 다음 로그와 연결 상태를 보며 항목별로 비교하세요. 대기 시간을 무작정 줄이면 남은 응답이 전송되기 전에 세션이 종료될 수 있습니다.

필드	처리 단계	대신 확인할 수 없는 항목
`handshake`	관련 세션 핸드셰이크	인증 정보와 보안 매개변수
`connIdle`	연결 유휴 시간	중간 장비와 앱 하트비트
`uplinkOnly`	단방향 전송 상태	앱의 반쪽 닫기 동작
`statsOutboundUplink`	아웃바운드 업로드 통계	통계 인터페이스와 클라이언트 표시

통계 의존성과 리소스 범위

통계 플래그를 켠다고 클라이언트 화면에 숫자가 반드시 표시되는 것은 아닙니다. 커널에서 통계 모듈을 활성화하고 조회 인터페이스를 제공해야 할 수 있으며, 클라이언트도 직접 조회해야 합니다. 사용자별 통계에는 프로토콜 사용자 ID 등의 정보가 필요한 경우가 많으므로 인증 정보가 없는 로컬 인바운드만으로는 구분 가능한 사용자 데이터가 만들어지지 않습니다. 로컬 연결이 특정 출구를 거쳤는지만 알고 싶다면 통계 인터페이스를 구축하는 것보다 접속 로그를 확인하는 편이 간단합니다. 문제 해결을 위해 관리용 리스너를 추가로 공개하지 마세요.

연결 통계, 네트워크 인터페이스 트래픽, 서비스 과금은 서로 다른 기준을 사용할 수 있습니다. 전송 캡슐화, 연결 재사용, 다른 프로세스의 트래픽, 측정 시점에 따라 결과가 달라지므로 여러 위치의 숫자가 항상 같을 필요는 없습니다. 설정 수준의 통계는 관련 객체의 트래픽 변화를 관찰하기 위한 것이지 서비스의 최종 과금 기준을 계산하는 수단이 아닙니다. 노드의 트래픽 배율은 서비스 안내를 따르세요. 정책 필드를 수정해 과금 결과를 바꾸려고 하지 마세요.

정책을 조정할 때는 기기 리소스도 고려해야 합니다. 데스크톱과 Android는 백그라운드 제한, 절전, 네트워크 전환 방식이 다르므로 장시간 연결이 끊기는 원인이 커널의 유휴 정책이 아니라 시스템 관리일 수 있습니다. 백그라운드에서 v2rayNG 또는 v2flyNG의 연결이 끊기면 먼저 시스템의 배터리 관리 및 네트워크 권한을 확인하세요. 컴퓨터가 절전 모드에서 깨어난 뒤 v2rayN에 문제가 생기면 연결을 다시 만들어 결과를 비교하세요. 커널이 정책에 따라 세션을 종료한다는 사실을 확인한 뒤에야 해당 시간 제한을 조정할 이유가 생깁니다.

설정 검증, 로그, 단계별 문제 해결

먼저 설정을 불러오는지 확인한 뒤 접속을 테스트하세요

검증은 설정 문법에서 시작해 커널 구조, 리스닝, 인바운드 접속, 라우팅, DNS, 전송, 앱 결과 순으로 진행해야 합니다. 문법이 올바르다는 것은 파서가 JSON을 읽을 수 있다는 뜻일 뿐, 프로토콜 필드가 지원된다는 뜻은 아닙니다. 커널이 시작되었다는 것은 기본 구조와 리소스가 로드 조건을 충족했다는 뜻일 뿐, 원격 연결이 가능하다는 뜻은 아닙니다. 각 단계의 성공 여부를 따로 기록하면 파일이 열리니 설정은 문제없다거나 브라우저가 실패했으니 노드가 고장 났다는 식의 계층을 넘나드는 추론을 피할 수 있습니다.

클라이언트에서 정상 작동하는 설정을 먼저 저장하거나 내보낸 뒤 별도의 테스트 설정을 만드세요. 클라이언트가 제공하는 설정 검사와 로그 메뉴를 사용하고, 현재 선택된 커널을 검사하는지 확인하는 것이 좋습니다. 사용자 지정 설정으로 실행한다면 클라이언트가 라우팅을 추가하거나 포트를 덮어쓰거나 다른 옵션을 병합하는지 점검하세요. 테스트 파일과 실행 파일이 다르면 문법 검사를 아무리 꼼꼼히 해도 실제 동작을 설명할 수 없습니다. 검증할 때마다 어느 파일이 로드되는지 확인하세요.

다음 명령은 Python 표준 라이브러리만 사용해 JSON을 검사하고 형식을 정리합니다. V2Fly 또는 Xray 필드의 의미를 검증하거나 연결을 시작하지는 않습니다. 명령의 config.json은 현재 폴더에 있는 로컬 테스트 파일을 가리킵니다. Windows에서 Python 런처를 사용하는 경우 두 번째 명령을 실행할 수 있습니다. 관련 도구가 설치되어 있지 않다면 클라이언트의 테스트 기능을 사용하면 됩니다. 가이드를 읽기 위해 실행 환경을 따로 바꿀 필요는 없습니다.

python3 -m json.tool config.json
py -m json.tool config.json

로그 상세도를 잠시 높이기

loglevel은 로그 상세도를 설정합니다. 평소에는 과도하지 않은 수준을 유지하고 문제를 확인할 때만 잠시 높이세요. 아래 설정은 정보 수준의 오류 로그를 출력하지만 파일 위치는 지정하지 않으므로 실제 실행 방식에 따라 출력 대상이 달라집니다. 접속 로그를 기록할지, 어디에 저장할지, 클라이언트에서 볼 수 있는지는 각각 확인해야 합니다. 오류 로그 수준을 높이면 접속 기록도 모두 남는다고 가정하지 마세요.

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

로그는 마지막의 '연결 실패' 문구만 보지 말고 처음 발생한 오류부터 확인하세요. 알 수 없는 프로토콜은 커널 지원이나 프로토콜 이름 문제, 주소 사용 중 오류는 인바운드 리스닝 문제, 리소스를 찾을 수 없다는 오류는 규칙 데이터 문제, DNS 시간 초과는 조회 경로 문제, 인증서 이름 오류는 보안 계층의 신원 확인 문제일 수 있습니다. 재시도하면 비슷한 기록이 쌓이므로 테스트 시작 시각을 기록하고, 하나의 요청만 보내며 다른 앱의 트래픽을 줄이세요.

로그에는 대상 도메인, 주소, 구독 링크 일부 등 사용 정보가 포함될 수 있습니다. 공유하기 전에 인증 정보, 전체 구독 주소, 관련 없는 접속 기록을 삭제하고 오류 유형과 필요한 필드만 남기세요. 사용자 정보가 담긴 설정 파일 전체를 공개 게시판에 올리지 마세요. 문제 해결 후에는 일반 로그 수준으로 되돌리고, 로컬 로그 저장 위치와 순환 설정을 확인해 더 이상 분석에 쓸모없는 기록이 장기간 쌓이지 않도록 하세요.

최소 재현과 원상 복구 절차

인바운드는 정상인데 접속에 실패한다면 이 페이지의 직결 기준 설정으로 앱과 로컬 인바운드 사이를 확인한 뒤, 필요한 정보가 모두 갖춰진 원격 아웃바운드 하나를 복구해 보세요. 그다음 라우팅 규칙 하나를 추가하고 마지막으로 DNS 분류와 정책을 복원합니다. 매 단계에서 같은 테스트 앱과 대상을 사용하고 결과와 로그를 기록하세요. 이렇게 하면 노드, 리소스, 덮어쓰기 규칙이 많은 설정에서 여러 원인을 한꺼번에 찾는 대신 특정 변경으로 문제 범위를 좁힐 수 있습니다.

구독 업데이트 실패는 '구독 내용 다운로드'와 '구독 노드로 연결'을 나누어 확인해야 합니다. 다운로드는 링크 상태, 클라이언트의 업데이트 경로, 인증서 문제에 영향을 받을 수 있습니다. 노드 연결은 매개변수와 커널에 따라 달라집니다. 노드에 접속할 수 있어도 구독 주소가 유효하다는 뜻은 아니며, 구독이 업데이트된다고 모든 노드에 연결할 수 있는 것도 아닙니다. 자세한 문제 해결은 구독 업데이트 실패 해결 방법에서 확인하세요. 업데이트 오류가 발생했다고 라우팅 객체 전체를 다시 작성하지 마세요.

다른 플랫폼으로 옮길 때 설정의 논리적 구조는 대체로 유지할 수 있지만 파일 경로, 포트 충돌, 시스템 프록시, 백그라운드 실행 제한은 다시 확인해야 합니다. Windows와 macOS의 첫 실행 문제는 첫 설치 및 초기 설정을 참고하세요. Linux에서는 데스크톱 세션의 프록시 설정과 앱 자체 환경을 구분해야 하며, Android에서는 시스템 네트워크 연결과 백그라운드 관리를 확인해야 합니다. 이전이 제대로 됐는지는 파일 복사에 오류가 없었는지가 아니라 앱 요청이 의도한 대로 커널에 들어가고 나오는지로 판단하세요.

마지막으로 작동하는 설정을 저장하고 일반 로그 수준으로 되돌린 뒤 태그 참조와 리스닝 범위를 확인하고, 재시작 후에도 변경 사항이 유지되는지 검증하세요. 이후 웹 탐색, 다운로드, 장시간 연결이 필요한 앱을 각각 테스트해 한 웹페이지만으로 모든 상황을 대표하지 않도록 합니다. 필드의 의미가 불분명하면 해당 절을 다시 확인하세요. 작업을 처음부터 순서대로 진행하려면 빠른 시작 가이드를 이용하세요. 이 가이드는 설정 간 관계를 설명하고, 빠른 시작 가이드는 순서에 따라 실제 설정을 완료하도록 안내합니다. 두 자료는 서로 대체할 수 없습니다.