V2Ray 기초부터 고급 설정까지

핵심 개념: 클라이언트·커널·프로토콜·라우팅

그래픽 클라이언트와 프록시 커널부터 구분하기

v2rayN, v2rayNG, v2flyNG는 기본적으로 그래픽 클라이언트입니다. 구독을 저장하고 노드를 표시하며 설정을 생성하고 커널을 실행한 뒤 시스템 프록시나 가상 네트워크 인터페이스를 올바른 상태로 전환합니다. 실제로 프로토콜 핸드셰이크, 암호화 전송, DNS 조회, 라우팅 매칭을 수행하는 것은 클라이언트가 호출한 커널입니다. v2rayN은 데스크톱 플랫폼에서 Xray 또는 V2Fly 계열 커널을 사용할 수 있고, v2rayNG는 주로 Xray 커널을 사용하며, v2flyNG는 V2Fly 커널 설정을 대상으로 합니다. “클라이언트는 실행 중인데 웹페이지에 접속할 수 없음”을 확인할 때는 창이 열려 있는지만 보지 말고 커널 실행 여부, 수신 포트 생성 여부, 시스템 트래픽이 해당 포트로 들어오는지도 확인해야 합니다.

클라이언트 설정과 노드 설정도 같은 계층이 아닙니다. 노드 설정은 원격 주소, 포트, 사용자 식별자, 프로토콜, 전송 방식, 보안 매개변수를 설명하고, 클라이언트 설정에는 로컬 리스너, 시스템 프록시, DNS, 라우팅, 로그가 포함됩니다. 구독은 보통 노드와 그룹 정보만 제공하며 모든 로컬 네트워크 정책을 대신 결정하지는 않습니다. 구독을 가져온 뒤에도 프록시 모드를 선택하고 필요하면 LAN 우회, 중국 본토 도메인 직접 연결, 원격 DNS 또는 TUN을 설정해야 합니다. 두 계층을 나누어 이해하면 같은 구독이 여러 기기에서 연결되더라도 분할 라우팅 결과가 완전히 같지 않은 이유를 설명할 수 있습니다.

프로토콜·전송·보안 매개변수는 함께 맞춰야 합니다

VMess, VLESS, Trojan은 노드 프로토콜 계층에 속하고 TCP, WebSocket, gRPC 등은 전송 계층에 속하며 TLS와 REALITY는 연결 보안 및 신원 확인과 관련된 설정입니다. 클라이언트가 연결을 수립할 때 이 매개변수는 서버와 하나씩 일치해야 합니다. VLESS 설정에서 주소와 포트가 올바르다고 해서 반드시 연결되는 것은 아닙니다. 사용자 식별자, 흐름 제어, 전송 유형, 서비스 이름, 서버 이름, 공개 키, 짧은 식별자 중 하나라도 맞지 않으면 핸드셰이크 실패, 연결 직후 종료, 지연 시간 테스트 초과로 나타날 수 있습니다.

REALITY 노드의 일반적인 필드에는 서버 이름, 지문, 공개 키, 짧은 식별자, 흐름 제어가 있습니다. 서버 이름은 임의로 입력하는 메모가 아니라 핸드셰이크에 참여하는 값입니다. 공개 키는 노드 제공자가 준 값을 사용해야 하고, 짧은 식별자는 제공된 내용대로 입력해야 합니다. Vision 흐름 제어를 사용할 때는 프로토콜, 전송, 보안 조합도 일관되게 유지해야 합니다. 표준 공유 링크나 구독을 가져오면 클라이언트가 보통 이 필드를 자동으로 해석합니다. 수동 입력은 필드의 출처를 확인할 때만 적합하며, 다른 노드의 매개변수를 현재 노드에 섞어 넣지 마세요.

인바운드·아웃바운드·라우팅이 데이터 경로를 구성합니다

인바운드는 클라이언트가 로컬에서 트래픽을 받는 위치를 뜻합니다. 예를 들면 로컬 SOCKS 포트, HTTP 포트, TUN 가상 인터페이스가 있습니다. 아웃바운드는 트래픽이 클라이언트를 떠난 뒤 처리되는 방식이며, 일반적으로 프록시, 직접 연결, 차단으로 표시됩니다. 라우팅 규칙은 각 요청을 어느 아웃바운드로 보낼지 결정합니다. 브라우저가 시스템 프록시를 사용하면 요청은 먼저 로컬 HTTP 또는 SOCKS 인바운드로 들어온 뒤 라우팅에 따라 직접 연결되거나 프록시를 거칩니다. TUN을 켜면 더 많은 애플리케이션 트래픽이 가상 네트워크 인터페이스를 통해 커널로 들어오지만 이후의 라우팅 및 아웃바운드 로직은 그대로 존재합니다.

라우팅은 보통 도메인, IP, 포트, 네트워크 유형 또는 프로세스 정보에 따라 매칭됩니다. 규칙에는 순서가 있으므로 먼저 일치한 규칙이 먼저 실행됩니다. 따라서 규칙 내용이 올바른 것만으로는 부족하고 적절한 위치에 있는지도 확인해야 합니다. LAN 주소와 예약 주소는 보통 직접 연결을 우선하고, 명확히 차단할 대상은 직접 연결 규칙보다 앞에 배치하며, 지역 도메인과 IP 규칙은 기본 프록시보다 앞에 둡니다. 마지막에는 예측 가능한 기본 아웃바운드를 남겨 매칭되지 않은 트래픽이 불명확한 상태로 빠지지 않게 하세요.

관찰 가능한 결과로 현재 계층 판단하기

연결 테스트가 성공했다는 것은 특정 테스트 조건에서 클라이언트가 대상에 접근할 수 있다는 뜻일 뿐 모든 애플리케이션을 보장하지는 않습니다. 브라우저는 되지만 명령줄은 되지 않는다면 해당 프로그램이 시스템 프록시를 읽는지 확인해야 합니다. 도메인은 열리지 않지만 알고 있는 IP에 직접 접속하면 응답이 오는 경우에는 DNS를 먼저 확인하세요. LAN 기기에 갑자기 접근할 수 없다면 라우팅과 TUN 우회 항목을 먼저 확인하고, 모든 노드가 동시에 실패하면 로컬 네트워크, 시스템 시간, 커널 실행, 구독 매개변수를 먼저 살펴보세요. 노드를 하나씩 삭제하지 마세요.

로그는 계층을 확인하는 핵심 근거입니다. 시작 로그에서는 설정 수락 여부, 포트 점유 여부, 가상 네트워크 인터페이스 생성 여부를 확인합니다. 연결 로그에서는 도메인, 대상 주소, 매칭 규칙, 아웃바운드 태그를 확인합니다. 오류 로그에서는 이름 확인 실패, 핸드셰이크 실패, 시간 초과, 권한 문제를 찾습니다. 평소 로그 수준은 warning으로 두고 문제를 해결할 때만 잠시 info로 전환하세요. 해결 후에는 다시 되돌려 불필요한 파일이 장기간 쌓이지 않게 합니다. 로그에는 방문 도메인과 노드 주소가 포함될 수 있으므로 공유하기 전에 문제와 관계없는 연결 정보를 삭제하세요.

클라이언트 선택 및 설치

플랫폼과 커널 요구 사항에 맞춰 클라이언트 선택하기

Windows, macOS, Linux 데스크톱 환경에서는 v2rayN을 우선 선택합니다. 구독, 노드, 시스템 프록시, 라우팅, DNS, TUN, 로그를 한 화면에서 관리할 수 있어 기본 연결부터 분할 라우팅과 가상 네트워크 인터페이스 설정까지 단계적으로 익히기 좋습니다. Windows 사용자는 데스크톱 버전과 클래식 WPF 버전 중에서 선택할 수 있습니다. 데스크톱 버전은 크로스 플랫폼 인터페이스를 사용하므로 여러 데스크톱 시스템에서 비슷한 조작 흐름을 원하는 사용자에게 적합하고, 클래식 WPF 버전은 기존 Windows 메뉴와 트레이 동작에 익숙한 사용자에게 적합합니다.

Android 기기에서는 v2rayNG를 우선 사용하며, 노드 필드가 Xray 방식과 비교적 잘 맞습니다. V2Fly 커널 설정이 필요하다면 v2flyNG를 선택하세요. 두 클라이언트 모두 구독 가져오기, 노드 선택, 로컬 VPN 연결, 로그 확인을 지원하지만 설정 이름과 진입 위치에는 차이가 있습니다. 이전할 때 스크린샷의 스위치 상태만 복사하지 말고 표준 노드 링크를 먼저 내보내거나 구독을 다시 추가한 뒤 라우팅, DNS, 애플리케이션별 정책을 항목별로 재구성하세요.

설치 전에 아키텍처와 기존 설정 확인하기

다운로드하기 전에 클라이언트 페이지에서 해당 플랫폼을 선택하세요. macOS는 Apple Silicon과 Intel을 구분해야 합니다. Android 최신 주류 기기는 보통 arm64를 선택하고, 확인하기 어렵다면 범용 버전을 사용하세요. Linux는 배포판 패키지 형식과 프로세서 아키텍처를 모두 확인해야 합니다. 파일명의 x64, arm64, deb, rpm은 선택 기준이므로 애플리케이션 이름만 보고 판단하면 안 됩니다. 시스템 아키텍처가 맞지 않으면 설치 프로그램이 실행을 거부하거나 지원되지 않는 형식이라는 메시지를 표시하거나, 실행 직후 종료될 수 있습니다.

기존 클라이언트가 있다면 먼저 현재 구독 주소, 구독 그룹, 라우팅 규칙, DNS 설정, 로컬 포트를 기록하세요. 클라이언트에서 설정 백업을 지원하면 개인 문서 폴더에 저장하고, 포터블 설정 디렉터리를 사용한다면 클라이언트를 완전히 종료한 뒤 전체 디렉터리를 복사하세요. 업데이트할 때 클라이언트 계열, 커널 유형, 주요 설정을 동시에 바꾸지 마세요. 문제가 생겼을 때 변경 원인을 파악하기 어렵습니다. 안전한 순서는 설정을 보존한 뒤 클라이언트를 업데이트하고, 기본 연결을 확인한 다음 커널을 업데이트하거나 라우팅을 조정하는 것입니다.

데스크톱 플랫폼에서 최초 실행 완료하기

Windows 설치 후 v2rayN을 실행하고 먼저 창 하단이나 설정 페이지에서 커널 상태를 확인하세요. 프로그램이 알림 영역에만 표시되면 트레이 아이콘에서 메인 화면을 여세요. 시스템 보안 알림이 나타나면 실제로 필요한 네트워크 범위에만 접근 권한을 부여하세요. 포트 충돌은 보통 이전 인스턴스가 종료되지 않았거나 다른 프록시 프로그램이 같은 수신 포트를 사용해서 발생합니다. 이때 중복 프로그램을 먼저 종료한 다음 v2rayN의 로컬 수신 설정에서 SOCKS와 HTTP 포트가 다른 프로세스에 사용되지 않는지 확인하세요.

macOS 최초 실행 시 애플리케이션 실행, 네트워크 접근, 시스템 프록시 변경에 대한 확인이 필요할 수 있습니다. 권한을 부여한 뒤에는 먼저 일반 시스템 프록시 모드로 확인하고 TUN은 바로 켜지 마세요. Linux에서 메인 창은 열리지만 트레이가 표시되지 않으면 데스크톱 환경이 상태 아이콘을 지원하는지 확인하세요. 트레이가 잠시 보이지 않아도 메인 창에서 구독과 연결을 완료할 수 있습니다. Linux에서는 현재 사용자가 설정 디렉터리를 읽고 쓸 권한이 있는지도 확인해야 종료 후 설정이 저장되지 않는 문제를 피할 수 있습니다.

모바일에서 기본 권한 설정 완료하기

Android에 v2rayNG 또는 v2flyNG를 설치한 뒤 처음 연결하면 VPN 연결 생성을 요청합니다. 이는 시스템이 애플리케이션 트래픽을 클라이언트에 전달하는 데 필요한 권한입니다. 시스템 팝업에서 승인하면 됩니다. 백그라운드 제한이 엄격하게 설정되어 있다면 클라이언트의 백그라운드 실행을 허용하세요. 그렇지 않으면 화면을 잠근 뒤 커널이 시스템에 의해 종료될 수 있습니다. 듀얼 SIM, 핫스팟 공유, 업무용 프로필 환경은 네트워크 인터페이스를 바꿀 수 있으므로 네트워크 전환 후 연결이 끊기면 먼저 연결을 중지했다가 다시 시작하세요.

최초 설치 단계에서는 세 가지만 확인합니다. 클라이언트가 정상적으로 열리는지, 구독 또는 단일 노드를 저장할 수 있는지, 연결 후 로그에 시작 오류가 반복되지 않는지입니다. 이때 사용자 지정 규칙을 대량으로 가져오거나 DNS 옵션을 모두 바꾸지 마세요. 먼저 기본 라우팅으로 재현 가능한 연결을 만들고, 이후 장에서 시스템 프록시, 분할 라우팅, TUN을 단계적으로 추가하세요. 첫 연결만 빠르게 완료하려면 빠른 시작 기본 과정으로 이동해 간단한 절차를 따르세요.

구독 가져오기 및 노드 관리

구독 링크와 단일 노드 링크의 차이

구독 링크는 노드 묶음과 업데이트 결과를 지속적으로 가져오는 데 사용되고, 단일 노드 링크는 하나의 구체적인 연결 설정만 나타냅니다. 장기간 사용할 때는 구독 내용을 수동 노드로 하나씩 변환하기보다 구독 그룹을 만드는 것이 좋습니다. 그룹에는 업데이트 주소, 메모, 필터 조건, 독립적인 업데이트 정책을 저장할 수 있습니다. 노드 주소, 포트, 보안 매개변수가 바뀌어도 구독만 업데이트하면 됩니다. 수동 노드는 임시 테스트나 필드 확인에는 적합하지만, 많은 노드를 관리하는 기본 방식으로는 적합하지 않습니다.

v2rayN에서 “구독 그룹”을 열고 그룹 이름과 구독 주소를 추가한 뒤 저장하고 “모든 구독 업데이트” 또는 현재 그룹 업데이트를 실행하세요. 그룹 이름은 출처나 용도를 나타내야 하며 노드의 원래 메모리에만 의존해 구분하지 마세요. v2rayNG와 v2flyNG의 진입점은 보통 구독 설정이나 사이드 메뉴에 있습니다. 추가한 뒤 먼저 업데이트하고 노드 목록으로 돌아가 대상을 선택하세요. 구독 주소를 복사할 때 앞뒤 공백, 줄바꿈, 메신저가 붙인 설명 문구가 포함되지 않았는지 확인하세요.

업데이트 실패 시 요청 경로별로 확인하기

구독 업데이트 실패와 노드 연결 실패는 서로 다른 문제입니다. 구독을 업데이트할 때 클라이언트는 먼저 구독 주소에 접근해 응답 내용을 해석해야 하고, 노드 연결에서는 해석된 서버 매개변수를 사용합니다. 구독 업데이트는 실패했지만 기존 노드가 연결된다면 현재 설정은 계속 사용할 수 있으므로 구독 주소의 완전성, 시스템 시간, 현재 네트워크의 구독 주소 접근 가능 여부, 구독 그룹의 잘못된 프록시 설정을 확인하세요. 기존 그룹을 먼저 삭제하면 사용 가능한 설정과 비교 샘플을 잃게 됩니다.

구독 업데이트에 현재 프록시가 필요하다면 먼저 저장되어 있고 사용할 수 있는 노드에 연결한 다음 구독 그룹에서 프록시를 활성화하세요. 구독 주소를 로컬 네트워크에서 직접 접속할 수 있다면 직접 연결 업데이트를 유지하는 편이 문제를 해결하기 쉽습니다. 반환 내용을 해석할 수 없다면 로그에서 HTTP 요청 실패인지, 지원되지 않는 콘텐츠 형식인지, 특정 노드 필드 이상인지 확인하세요. 하나의 노드 해석 실패가 전체 구독을 사용할 수 없다는 뜻은 아니므로 성공한 항목은 보존하고 구독 제공자에게 이상 필드를 문의하세요.

그룹·메모·필터로 목록 규모 관리하기

여러 구독이 있다면 각 그룹에 안정적인 짧은 이름을 지정하고, 노드 메모에는 “지역｜회선｜프로토콜”처럼 검색 가능한 구조를 유지하세요. 필터는 표시 또는 업데이트 결과에만 적용되며 노드 프로토콜 필드를 수정해서는 안 됩니다. v2rayN은 키워드 포함 또는 제외로 노드를 필터링할 수 있어 중복 항목을 숨기거나 특정 프로토콜만 남길 때 유용합니다. 규칙은 한두 개의 안정적인 키워드로 최대한 단순하게 유지하세요. 노드 이름의 임시 문구에 과도하게 의존하면 구독 제공자가 이름을 바꾼 뒤 목록이 갑자기 비게 됩니다.

자동 업데이트 간격을 지나치게 짧게 설정할 필요는 없습니다. 구독 내용은 보통 분 단위로 바뀌지 않으며, 잦은 요청은 실패 알림과 목록 새로 고침만 늘립니다. 일상적으로는 시작할 때 업데이트하거나 실제 변경 빈도에 맞춰 주기를 설정하세요. 업데이트 후에는 현재 선택한 노드가 여전히 존재하는지 먼저 확인하고, 삭제되었다면 새 항목을 수동으로 선택하세요. 더 자세한 그룹 전략은 v2rayN 다중 구독 그룹 관리를 참고하세요.

노드 선택을 한 번의 테스트에만 의존하지 않기

지연 시간 테스트는 클라이언트가 지정된 탐색을 완료할 수 있는지 빠르게 판단하는 기능이지만 실제 애플리케이션 품질과 같지는 않습니다. 테스트 방식에 따라 TCP 연결 수립, HTTP 응답, 실제 연결 과정 중 서로 다른 항목을 측정하므로 결과를 직접 비교할 수 없습니다. 노드를 선택할 때는 먼저 프로토콜 필드가 완전한지 확인하고 클라이언트의 연결 테스트를 실행한 다음 실제로 필요한 웹페이지나 애플리케이션으로 검증하세요. 한 번의 시간 초과는 로컬 네트워크 불안정, DNS, 원격 제한, 테스트 대상의 일시적인 접근 불가 때문에 발생할 수 있으므로 다시 테스트하고 로그를 비교하세요.

모든 노드에서 시간 초과가 발생하면 먼저 설정이 명확한 노드 하나를 샘플로 선택하세요. 서버 주소가 해석되는지, 포트가 로컬 네트워크에서 차단되지 않았는지, 시스템 시간 차이가 지나치게 크지 않은지, 커널이 노드에 사용된 매개변수를 지원하는지 확인합니다. 단일 노드만 실패하고 같은 그룹의 다른 노드가 정상이면 메모가 아닌 실제 프로토콜, 전송, 보안 필드를 비교하세요. 모든 구독이 동시에 실패하면 로컬 네트워크, 커널 실행, 프록시 루프백을 중점적으로 확인하고 사용자 식별자를 하나씩 바꾸지 마세요.

{
  "protocol": "vless",
  "settings": {
    "vnext": [
      {
        "address": "example.com",
        "port": 443,
        "users": [
          {
            "id": "11111111-1111-4111-8111-111111111111",
            "encryption": "none",
            "flow": "xtls-rprx-vision"
          }
        ]
      }
    ]
  }
}

위 조각은 VLESS 아웃바운드 필드의 계층을 설명하기 위한 것으로, 도메인과 사용자 식별자는 예시 값입니다. 실제 구독을 사용할 때는 클라이언트가 구독 내용에 따라 전체 설정을 생성해야 하며, 예시 필드로 기존 노드를 덮어쓰지 마세요. 생성된 설정을 확인하는 주된 목적은 화면의 주소, 포트, 사용자 식별자, 흐름 제어가 올바른 계층에 들어갔는지 확인하는 것이지, 생성된 전체 파일을 장기간 수동 관리하는 것이 아닙니다.

시스템 프록시 및 프록시 모드 선택

시스템 프록시는 프록시를 지원하는 프로그램을 연결합니다

v2rayN은 커널을 실행한 뒤 로컬에서 SOCKS와 HTTP 포트를 수신하지만, 수신 포트가 있다고 해서 모든 프로그램을 자동으로 제어하지는 않습니다. “시스템 프록시 자동 설정”을 켜면 운영체제의 프록시 설정을 읽는 브라우저와 데스크톱 애플리케이션이 v2rayN으로 요청을 보냅니다. 시스템 프록시를 꺼도 커널은 계속 실행할 수 있고, 로컬 프록시 포트를 직접 지정한 프로그램은 계속 사용할 수 있습니다. 이는 “클라이언트는 실행 중인데 일부 애플리케이션만 연결됨”을 해결할 때 중요한 차이입니다.

시스템 프록시 모드는 브라우저, 오피스 프로그램, 시스템 설정을 따르는 대부분의 애플리케이션에 적합하며 영향 범위가 명확하고 클라이언트 종료 후 복구하기도 쉽습니다. 시스템 프록시를 읽지 않는 명령줄 도구는 바로 TUN으로 전환하기보다 해당 도구에서 HTTP 또는 SOCKS 프록시를 직접 설정하세요. 로컬 프록시 주소는 일반적으로 루프백 주소를 사용하고 포트는 클라이언트의 현재 수신 포트와 일치해야 합니다. 원격 노드 포트를 로컬 프록시 포트로 잘못 입력하지 마세요.

전역·규칙·직접 연결 모드는 서로 다른 라우팅 정책입니다

“전역”은 보통 클라이언트로 들어온 트래픽을 현재 프록시 아웃바운드로 일괄 전송하는 모드입니다. 라우팅 규칙 때문에 접속 문제가 생겼는지 확인하거나 노드 자체를 잠시 검증할 때 유용합니다. 하지만 LAN, 프린터, 로컬 개발 서비스, 중국 본토 리소스까지 프록시로 보낼 수 있으므로 일상 사용에 반드시 필요한 모드는 아닙니다. “규칙” 모드는 도메인, IP 및 기타 조건에 따라 직접 연결 또는 프록시를 선택하므로 장기간 사용에 더 일반적입니다. “직접 연결”은 클라이언트로 들어온 요청을 대상에 직접 보내며 문제가 프록시 경로에서 비롯되었는지 확인할 때 사용할 수 있습니다.

문제 해결 시 다음 순서를 정해둘 수 있습니다. 먼저 전역 모드로 대상을 테스트하고, 전역은 되지만 규칙 모드가 안 되면 라우팅 매칭을 확인하세요. 전역도 안 되면 노드, DNS, 커널을 확인합니다. 직접 연결이 된다고 해서 노드가 정상이라는 뜻은 아니며, 로컬 네트워크에서 대상까지의 직접 경로가 도달 가능하다는 뜻일 뿐입니다. 테스트가 끝나면 원래 모드로 복원하고 로그에서 대상 도메인이 예상한 아웃바운드 태그를 사용했는지 확인하세요.

PAC 및 시스템 프록시 예외 범위 명확히 하기

일부 데스크톱 환경에서는 PAC 스크립트로 어떤 요청을 로컬 프록시로 보낼지 결정할 수 있습니다. PAC는 요청이 커널에 도달하기 전에 한 번 선택하고, 클라이언트 라우팅은 요청이 커널에 들어온 뒤 다시 아웃바운드를 결정하므로 두 기능을 함께 사용하면 이해하기 어려워집니다. 세밀한 라우팅이 필요하다면 시스템 프록시를 클라이언트로 통일하고 커널 라우팅에서 직접 연결과 프록시를 처리하는 편이 명확합니다. 특정 프로그램이나 도메인이 클라이언트에 전혀 들어오지 않아야 할 때만 시스템 프록시 예외나 PAC를 고려하세요.

LAN 주소는 우회 범위에 포함해야 하며 일반적인 범위에는 루프백 주소, 사설 주소, 로컬 도메인이 있습니다. 이렇게 하면 라우터 관리 페이지, LAN 파일 서비스, 개발 환경에 접근할 때 프록시를 우회할 수 있습니다. LAN 서비스가 도메인 형식이면 먼저 DNS를 거칠 수 있으므로 IP 우회만 추가해서는 해결되지 않을 수 있습니다. 이때 DNS hosts, 시스템 hosts, 로컬 도메인 확인 서비스에서 동일한 기록을 유지해야 합니다.

트래픽이 실제로 클라이언트에 들어오는지 확인하기

웹페이지가 열리는지만으로 시스템 프록시 상태를 판단하지 마세요. 클라이언트 연결 로그를 열고 이전에 캐시되지 않은 도메인에 접속한 뒤 새 연결 기록과 해당 아웃바운드가 나타나는지 확인하세요. 브라우저는 정상인데 로그에 변화가 없다면 브라우저 자체 프록시, 다른 네트워크 확장 기능, 캐시된 연결을 사용하고 있을 수 있습니다. 로그에 요청이 나타나지만 아웃바운드가 direct라면 라우팅을 확인하고, proxy로 표시된 뒤 핸드셰이크가 실패하면 노드 매개변수와 원격 연결 계층으로 돌아가세요.

명령줄 환경에서는 직접 연결을 통한 이름 확인, 시스템 프록시 읽기 여부, 명시적 프록시를 각각 확인할 수 있습니다. 도구마다 시스템 프록시 환경 변수 지원이 다르므로 테스트 명령이 어느 경로를 사용하는지 알고 실행해야 합니다. 확인이 끝나면 임시 환경 변수를 삭제해 이후 터미널 세션에서 종료된 로컬 포트로 소프트웨어 업데이트나 패키지 관리 요청을 보내지 않도록 하세요. 일상 설정의 목표는 모든 프로그램이 같은 진입점을 사용하는 것이 아니라 각 애플리케이션의 진입점이 명확하고 확인 가능하며 복구 가능한 상태를 만드는 것입니다.

라우팅 및 DNS 설정

최소 라우팅 규칙부터 시작하기

일반적인 라우팅 목표는 LAN과 사설 주소를 직접 연결하고, 명확한 중국 본토 도메인과 IP도 직접 연결하며, 나머지 트래픽은 프록시로 보내는 것입니다. v2rayN에서는 먼저 “중국 본토 우회” 같은 사전 설정 규칙을 선택한 뒤 실제 애플리케이션에 필요한 사용자 지정 도메인을 추가할 수 있습니다. 사전 설정 규칙은 GeoSite와 GeoIP 데이터에 의존합니다. GeoSite는 도메인 집합으로 매칭하고 GeoIP는 대상 IP가 속한 주소 대역으로 매칭합니다. 도메인 규칙은 해석 전에 정책을 결정할 수 있고 IP 규칙은 보통 먼저 해석 결과를 얻어야 하므로 서로 대체하기보다 함께 사용해야 합니다.

최소 규칙 집합에서는 먼저 사설 주소를 처리해 LAN 요청이 원격 아웃바운드로 들어가지 않게 하고, 그다음 명확한 차단 항목, 직접 연결할 도메인과 IP, 마지막으로 프록시 기본 경로를 설정합니다. 규칙이 많다고 항상 정확해지는 것은 아닙니다. 중복 도메인, 오래된 규칙, 서로 덮어쓰는 표현식이 많으면 로그를 해석하기 어려워집니다. 규칙을 추가할 때는 먼저 정확한 도메인 하나로 확인하고 매칭이 검증된 뒤 접미사나 분류 태그로 확장하세요.

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["geosite:cn"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": ["geoip:cn"],
        "outboundTag": "direct"
      }
    ]
  }
}

domainStrategy는 도메인 규칙이 매칭되지 않았을 때 계속 해석해 IP 규칙을 시도할지 결정합니다. IPIfNonMatch는 도메인 규칙에 결과가 없을 때 IP를 해석한다는 뜻으로, GeoSite와 GeoIP를 함께 사용하는 일반적인 환경에 적합합니다. 기존 IP만 기준으로 처리하도록 설정하면 일부 도메인 트래픽이 예상한 IP 규칙에 들어가지 않을 수 있고, 모든 도메인을 미리 해석하면 DNS 관여도가 커집니다. 전략을 변경한 뒤에는 해석 로그와 라우팅 로그를 함께 확인하세요.

도메인 규칙의 매칭 범위 이해하기

정확한 도메인은 지정한 호스트만 매칭하고, 도메인 접미사는 하위 도메인까지 포함할 수 있습니다. 키워드 매칭은 범위가 더 넓어 이름은 비슷하지만 용도가 다른 도메인까지 함께 포함하기 쉽습니다. 정확한 도메인이나 명확한 분류 태그를 우선 사용하고, 도메인 구조가 안정적이며 여러 하위 도메인을 반드시 포함해야 할 때만 접미사를 사용하세요. 콘텐츠 전송 네트워크에서는 하나의 서비스가 여러 도메인을 호출할 수 있으므로 주소창의 주 도메인만 보고 규칙을 만들지 말고 연결 로그에서 실제 요청 집합을 확인하세요.

라우팅 판단은 클라이언트가 확인한 도메인에 의존합니다. 애플리케이션이 IP에 직접 연결하면 도메인 규칙은 매칭되지 않고 IP, 포트, 프로세스 규칙만 사용할 수 있습니다. 일부 DNS 매핑 기능을 켜면 커널이 도메인과 연결의 대응 관계를 복원할 수 있지만 DNS 요청도 클라이언트가 관리해야 합니다. “같은 웹사이트가 어떤 때는 직접 연결되고 어떤 때는 프록시를 사용함”이라면 서로 다른 하위 도메인, IPv4와 IPv6 결과 차이, 캐시된 해석 결과, 애플리케이션 자체의 해석 경로를 확인하세요.

DNS와 라우팅을 하나의 경로로 설정하기

DNS의 역할은 도메인을 IP로 변환하는 데 그치지 않습니다. 이후 라우팅 매칭 여부와 로컬 캐시 또는 해석 경로의 영향을 좌우합니다. 일반적인 설정은 중국 본토 도메인에 로컬 또는 중국 본토 DNS를 사용하고, 그 외 도메인에는 원격 DNS를 사용하며 원격 DNS 요청은 프록시 아웃바운드를 거치게 하는 것입니다. 이렇게 하면 도메인 해석 결과와 실제 접속 경로가 어긋나는 상황을 줄일 수 있습니다. 구체적인 규칙은 현재 커널이 지원하는 DNS 구조에 맞춰 설정하고, 시스템·브라우저·클라이언트·여러 네트워크 도구에 서로 충돌하는 해석 정책을 동시에 설정하지 마세요.

DNS를 문제 해결할 때는 먼저 변수를 줄이세요. 브라우저의 독립 보안 DNS 설정을 끄고 클라이언트 DNS만 유지하거나, 클라이언트 사용자 지정 DNS를 잠시 끄고 시스템 해석만 테스트합니다. 주요 해석 경로는 한 번에 하나만 남기세요. 도메인에 접근할 수 없다면 로그에 조회가 나타나는지, 어떤 주소가 반환되었는지, 그 주소가 이후 어떤 라우팅 규칙에 매칭되었는지 확인하세요. 해석은 성공했지만 연결에 실패했다면 문제는 이미 전송 계층에 있으며, 조회 기록이 없다면 애플리케이션이 클라이언트 DNS를 우회했을 수 있습니다.

DNS 누수·캐시·IPv6 경로 처리하기

시스템 프록시를 사용해도 애플리케이션이 시스템 DNS를 직접 호출할 수 있으며, 이는 애플리케이션의 도메인 해석 방식에 따라 달라집니다. 해석 요청을 클라이언트에서 통합 처리하려면 클라이언트의 원격 DNS, DNS 아웃바운드, TUN DNS 제어를 사용할 수 있습니다. 확인 방법으로는 브라우저 검사, 시스템 명령 조회, 클라이언트 로그 비교가 있습니다. 자세한 단계는 v2rayN DNS 누수 검사 및 해결을 참고하세요. 판단할 때는 최종 반환 IP만 보지 말고 DNS 서버와 요청 경로를 확인해야 합니다.

캐시 때문에 변경 사항이 적용되지 않은 것처럼 보일 수 있습니다. 클라이언트, 운영체제, 브라우저, 애플리케이션 모두 DNS 결과를 저장할 수 있습니다. 규칙을 변경한 뒤 관련 애플리케이션을 다시 시작하거나 해당 캐시를 지우고 새 도메인으로 연결을 만드세요. IPv6를 사용할 수 있으면 도메인이 A와 AAAA 레코드를 함께 반환할 수 있습니다. 로컬 IPv6 경로가 불안정하면 애플리케이션이 실패하는 주소를 우선 선택할 수 있습니다. 먼저 시스템의 IPv6 연결이 정상인지 확인한 다음 IPv6를 유지하거나 제한하거나 별도 라우팅을 만들지 결정하세요. DNS 레코드 하나를 삭제해 네트워크 문제를 장기간 감추면 안 됩니다.

GeoIP 및 GeoSite 데이터 유지 관리

GeoIP와 GeoSite 데이터는 주소 할당과 도메인 변화에 따라 업데이트됩니다. 규칙을 수정하지 않았는데 분할 라우팅 결과가 점점 예상과 달라진다면 현재 커널이 데이터 파일을 읽을 수 있는지, 업데이트가 완료되었는지, 사용자 지정 파일이 클라이언트 관리 버전을 덮어쓰지 않았는지 확인하세요. 데이터 파일과 커널은 호환성을 유지해야 하며, 업데이트 후 커널을 다시 시작하고 로그에서 분류 태그가 로드되었는지 확인하세요.

데이터 파일을 수동으로 교체하기 전에 클라이언트를 종료하고 원본 파일을 백업해 파일 점유를 피하세요. 시작 로그에서 태그가 없거나 파일 형식이 잘못되었다고 보고하면 즉시 백업을 복원하고 보완 규칙을 계속 추가하지 마세요. 정확한 확인 위치, 업데이트 방법, 복구 절차는 GeoIP 및 GeoSite 데이터 업데이트 가이드에서 확인할 수 있습니다. 라우팅 데이터베이스는 분류 기준일 뿐이므로 최종적으로는 접속 로그에서 대상이 예상한 아웃바운드에 매칭되는지 확인해야 합니다.

TUN 모드 활성화 및 조정

TUN이 필요한 경우 명확히 하기

TUN 모드는 가상 네트워크 인터페이스를 통해 운영체제의 IP 트래픽을 받으며, 시스템 프록시를 읽지 않는 애플리케이션, 일부 명령줄 프로그램, 트래픽을 통합 제어해야 하는 환경에 적합합니다. 시스템 프록시보다 적용 범위가 넓어 LAN, 소프트웨어 업데이트, 백그라운드 서비스, 원래 프록시를 거치지 않던 트래픽까지 라우팅 판단에 포함할 수 있습니다. 브라우저와 일반 데스크톱 애플리케이션만 사용한다면 시스템 프록시로 충분한 경우가 많습니다. 별도로 프록시를 설정할 수 없는 애플리케이션이 확인된 뒤 TUN을 켜는 편이 관리하기 쉽습니다.

TUN은 노드 연결 능력을 높이는 스위치가 아닙니다. 노드 자체의 핸드셰이크 실패, 잘못된 구독 필드, 원격 서버 접근 불가 문제는 TUN으로 해결되지 않으며 라우팅 테이블, DNS, 권한 변수만 늘어납니다. 올바른 순서는 시스템 프록시 모드에서 현재 노드를 먼저 검증하고, 같은 노드와 기본 라우팅을 유지한 채 TUN을 켜는 것입니다. TUN을 켠 뒤 모든 접속이 실패하면 전후 로그와 시스템 라우팅을 바로 비교하면 되며 구독 내용을 다시 의심할 필요는 없습니다.

활성화 전에 권한·인터페이스·주소 범위 확인하기

가상 네트워크 인터페이스를 만들고 라우팅을 변경하려면 보통 시스템 권한이 필요합니다. v2rayN에서 권한 부족을 알리면 클라이언트와 운영체제가 안내하는 방식으로 권한을 부여하고 시작 버튼을 반복해서 누르지 마세요. 시스템에 다른 가상 네트워크 도구가 있으면 인터페이스 라우팅 경쟁, DNS 중복 제어, 기본 경로 반복 전환이 발생할 수 있습니다. 문제를 해결할 때는 시스템 네트워크를 변경하는 다른 프로그램을 먼저 종료하고 v2rayN만 남긴 뒤 TUN 인터페이스를 다시 만드세요.

TUN에서 사용하는 가상 주소 대역은 현재 LAN, 기업 네트워크, 다른 가상 인터페이스와 겹치면 안 됩니다. 겹치면 특정 주소에 접근할 수 없거나 LAN 기기 연결이 끊기거나 요청이 순환할 수 있습니다. 먼저 로컬 라우팅을 확인한 뒤 클라이언트 기본값 중 충돌하지 않는 주소 대역을 선택하세요. Windows에서는 시스템 네트워크 화면에서 어댑터와 라우팅을 확인하고, macOS와 Linux에서는 시스템 네트워크 도구로 인터페이스를 확인할 수 있습니다. 핵심은 기본 경로, LAN 대역, TUN 대역이 각각 올바른 인터페이스를 가리키는지 확인하는 것입니다.

ip route
ip route get 1.1.1.1
resolvectl status

이 Linux 명령은 각각 라우팅 테이블 확인, 지정한 대상이 통과하는 인터페이스 확인, 현재 DNS 상태 확인에 사용됩니다. 다른 데스크톱 시스템에서는 해당 운영체제의 네트워크 확인 도구를 사용하세요. 명령 결과는 TUN을 켜기 전후의 변화를 비교하는 데 활용합니다. 기본 트래픽이 가상 인터페이스로 들어가는지, LAN 대역이 여전히 물리 인터페이스로 직접 연결되는지, DNS 서버가 예상한 진입점으로 바뀌었는지 확인하세요.

자동 라우팅·엄격한 라우팅·우회 항목 설정하기

자동 라우팅은 클라이언트가 트래픽을 TUN으로 보내는 시스템 경로를 만들도록 하며, 보통 기본값부터 사용하는 것이 좋습니다. 엄격한 라우팅은 우회 트래픽 제한을 강화하므로 기본 TUN이 정상임을 확인한 뒤 테스트하세요. 엄격한 정책을 켜면 로컬 서비스, 가상 머신, 컨테이너, LAN 검색이 영향을 받을 수 있으므로 사설 주소와 로컬 인터페이스 우회를 먼저 설정해야 합니다. 모든 사설 주소를 프록시 아웃바운드로 보내면 라우터, 프린터, 로컬 개발 서비스에 접근할 수 없게 됩니다.

프로세스별 우회 또는 포함은 TUN의 적용 범위를 줄일 수 있지만 프로세스 이름, 자식 프로세스, 시스템 서비스 관계를 실제로 확인해야 합니다. 애플리케이션이 런처에 의해 별도 프로세스로 실행되거나 네트워크 요청을 시스템 구성 요소에 넘길 수 있기 때문입니다. 주 프로그램 이름만 추가한다고 전체 요청 경로가 포함되지는 않습니다. 처음에는 일반 라우팅 규칙으로 확인하고, 애플리케이션별 제어가 꼭 필요할 때 로그를 보며 프로세스를 하나씩 추가하고 기본 아웃바운드는 우회 경로로 남겨두세요.

TUN에서 DNS 및 MTU 처리하기

TUN 환경에서는 도메인, 매핑 주소, 실제 연결이 서로 연관되도록 DNS를 클라이언트에서 통합 처리하는 것이 좋습니다. 일반적으로 시스템 DNS를 클라이언트가 제공하는 로컬 진입점으로 지정하고 커널이 도메인 규칙에 따라 로컬 또는 원격 해석을 선택하게 합니다. 시스템이 다른 DNS도 동시에 사용하면 해석 결과가 커널에 들어가지 않거나 도메인 규칙과 연결되지 않거나 검사 결과가 일치하지 않을 수 있습니다. TUN으로 전환한 뒤 먼저 DNS 상태를 확인하고 웹페이지를 테스트하세요.

일부 네트워크에서는 웹페이지는 로드되기 시작하지만 대용량 파일이나 특정 요청이 멈출 수 있으며, 이는 MTU와 관련될 수 있습니다. TUN 캡슐화는 추가 오버헤드를 만들고 경로상의 일부 장비가 조각화를 제대로 처리하지 못할 수 있습니다. 문제를 해결할 때는 클라이언트가 지원하는 범위에서 MTU를 단계적으로 낮추고, 한 번에 하나의 값만 변경하며 같은 대상으로 다시 테스트하세요. 지나치게 낮은 값을 바로 설정하지 마세요. MTU가 너무 작으면 조각화와 처리 부담이 커집니다. 하나의 네트워크에서만 문제가 발생한다면 다른 Wi-Fi나 유선 네트워크와도 비교하세요.

복구 가능한 종료 절차 만들기

클라이언트를 정상 종료하기 전에 TUN을 먼저 꺼서 가상 인터페이스, 라우팅, DNS 변경 사항을 되돌리게 하세요. 시스템이 비정상 종료되거나 클라이언트가 충돌한 뒤 네트워크를 사용할 수 없다면 클라이언트를 다시 시작하고 TUN을 정상적으로 한 번 켰다 끄며 정리 로직을 실행하세요. 그래도 복구되지 않으면 시스템 프록시, 기본 라우팅, DNS를 확인합니다. 잔여 상태가 명확하지 않은데 여러 네트워크 도구를 연달아 설치하지 마세요. 라우팅 출처를 판단하기 더 어려워집니다.

안정적인 TUN 설정은 네 가지를 충족해야 합니다. 켠 뒤 기본 접속이 정상이고, LAN에 접근할 수 있으며, DNS 요청이 예상한 경로로 들어가고, 끈 뒤 시스템 네트워크가 완전히 복구되어야 합니다. 이 네 가지를 확인한 다음에야 엄격한 라우팅, 프로세스 규칙, 복잡한 DNS를 추가하세요. TUN 사용 중 문제가 생기면 빠른 시작 페이지에서 기본 연결 확인 순서를 다시 살펴본 뒤 이 장을 참고해 시스템 제어 계층을 찾을 수 있습니다.

일상 유지 관리·백업·문제 해결

클라이언트·커널·구독·규칙을 분리해 업데이트하기

v2rayN 그래픽 클라이언트, 프록시 커널, 구독 콘텐츠, GeoIP·GeoSite 데이터는 서로 독립적인 네 가지 업데이트 대상입니다. 한 번에 하나만 업데이트하고 기본 연결과 분할 라우팅을 확인한 뒤 다음 항목으로 넘어가세요. 이렇게 하면 설정 호환성 문제가 생겼을 때 빠르게 되돌릴 수 있습니다. 클라이언트 업데이트는 주로 화면과 설정 생성 방식을 바꾸고, 커널 업데이트는 프로토콜 구현이나 매개변수 지원을 바꿀 수 있으며, 구독 업데이트는 노드를 바꾸고, 라우팅 데이터베이스 업데이트는 분류 결과를 바꿉니다. 각 문제의 양상은 서로 다릅니다.

업데이트 전에 현재 사용할 수 있는 노드, 커널 유형, 시스템 프록시 모드, TUN 상태, 사용자 지정 라우팅을 기록하세요. 중요한 설정을 백업하고 최근에 정상 작동을 확인한 설정 사본을 보관합니다. 업데이트 후에는 기존 노드와 기존 모드로 먼저 테스트하고 오래된 설정을 바로 정리하지 마세요. 시작 로그에 해석 오류가 없고 연결 로그가 정상인지 확인한 뒤 오래된 백업을 삭제하세요. 자동 업데이트는 구독과 일반 데이터에 적합하지만 클라이언트 계열 전환이나 광범위한 규칙 변경은 수동으로 계획해야 합니다.

“진입점—해석—라우팅—전송” 순서로 문제 해결하기

첫 단계는 진입점 확인입니다. 프로그램이 시스템 프록시를 읽는지, 트래픽이 TUN으로 들어오는지 확인합니다. 두 번째는 해석입니다. 도메인이 주소를 얻는지, DNS 요청이 예상한 경로를 사용하는지 확인합니다. 세 번째는 라우팅입니다. 대상이 direct, proxy, block 중 어디에 매칭되는지 확인합니다. 네 번째는 전송입니다. 노드 프로토콜, 포트, 보안 매개변수, 원격 응답을 확인합니다. 순서를 고정하면 DNS 문제 때문에 노드를 계속 바꾸거나 노드 핸드셰이크 실패 때 라우팅을 무작정 수정하는 일을 피할 수 있습니다.

브라우저는 되지만 다른 애플리케이션이 안 되면 애플리케이션 진입점을 먼저 확인하세요. 모든 도메인이 실패하지만 알고 있는 IP는 연결되면 DNS를 먼저 확인합니다. 규칙 모드는 실패하지만 전역 모드는 정상이라면 라우팅을 먼저 확인하세요. 모든 노드가 갑자기 실패하면 로컬 네트워크, 시스템 시간, 커널 프로세스, 구독 변경을 먼저 확인하고, 단일 노드만 실패하면 같은 그룹에서 정상인 노드와 필드를 비교하세요. 문제 해결 중에는 알고 있는 정상 샘플 하나를 남겨두는 것이 많은 노드를 동시에 테스트하는 것보다 유용합니다.

로그 수준과 타임라인 올바르게 사용하기

일상적으로 로그 수준을 warning으로 유지하면 시작 실패, 해석 이상, 연결 오류를 강조할 수 있습니다. 라우팅 매칭을 확인해야 할 때만 info로 잠시 전환하고 대상에 한 번 접속한 뒤 해당 시간대의 로그를 즉시 저장하세요. 로그가 너무 많으면 먼저 연결을 중지하고 현재 화면을 지운 다음 다시 시작해 테스트 동작 하나만 실행합니다. 이렇게 하면 시작, DNS, 라우팅, 연결 기록을 시간순으로 이어 볼 수 있어 많은 백그라운드 요청 속에서 대상을 찾기 쉽습니다.

오류 메시지는 문맥과 함께 해석해야 합니다. timeout은 정해진 시간 안에 예상한 응답을 받지 못했다는 뜻이며 DNS, TCP 연결 수립, 프로토콜 핸드셰이크에서 발생할 수 있습니다. connection refused는 대상이 현재 포트를 명확히 거부했다는 뜻이고, name resolution failed는 해석 계층 문제를 가리킵니다. 설정 해석 오류는 보통 필드 경로나 유형을 표시합니다. 로그를 공유할 때는 오류 앞뒤의 필요한 줄만 남기고 구독 주소, 노드 인증 정보, 문제와 무관한 접속 기록을 삭제하세요.

시스템 시간·포트·백그라운드 상태 관리하기

TLS와 REALITY 같은 연결은 합리적인 시스템 시간을 필요로 합니다. 기기 시간이 크게 어긋나면 인증서 유효 기간 판단과 핸드셰이크가 모두 실패할 수 있으므로 시스템 자동 시간 동기화를 사용하세요. 로컬 SOCKS, HTTP, API 수신 포트는 다른 프로그램과 충돌해서는 안 되며, 포트를 바꾸면 애플리케이션에 수동으로 설정한 프록시도 함께 변경해야 합니다. 클라이언트를 중복 실행하면 화면 인스턴스가 두 개 생길 수 있지만 포트를 정상적으로 점유하는 것은 하나뿐입니다. 프로세스 목록과 로그로 확인하세요.

모바일 기기에서는 백그라운드 제한을, 데스크톱 시스템에서는 절전 복귀, 네트워크 전환, 트레이 종료를 주의해야 합니다. 유선에서 Wi-Fi로, 가정용 네트워크에서 모바일 핫스팟으로 전환하면 기존 연결과 DNS 캐시가 남아 있을 수 있습니다. 이상이 발생하면 현재 연결을 먼저 중지하고 이전 세션이 해제될 때까지 기다린 뒤 다시 연결하세요. TUN을 장기간 사용할 때는 시스템 주요 버전 업데이트 후마다 가상 인터페이스 권한과 종료 후 복구 절차를 다시 확인해야 합니다.

단순하고 되돌릴 수 있는 백업 구조 만들기

백업에는 최소한 구독 그룹, 수동 노드, 사용자 지정 라우팅, DNS 설정, 클라이언트 기본 설정이 포함되어야 합니다. 파일명에는 날짜와 용도를 사용할 수 있습니다. 예를 들어 “데스크톱 기본 규칙”, “TUN 안정 설정”처럼 지정하되 구독 주소나 노드 식별자를 파일명에 쓰지 마세요. 백업 후에는 실제로 가져오거나 복원할 수 있는지 확인해야 합니다. 불완전한 데이터베이스 파일 하나만 복사한다고 유효성이 보장되지는 않습니다. 플랫폼 간 이전에서는 표준 구독과 규칙 설계를 우선 옮기고 모든 화면 설정 파일이 그대로 호환된다고 가정하지 마세요.

복잡한 장애가 발생하면 규칙을 계속 덧대기보다 최소 설정으로 되돌리는 편이 빠릅니다. TUN을 끄고 시스템 프록시를 사용하며, 기본 DNS를 임시로 사용하고, 설정이 확실한 노드 하나를 선택해 전역 모드로 연결을 확인한 뒤 규칙, DNS, TUN을 순서대로 복원하세요. 각 단계마다 같은 대상으로 다시 테스트합니다. DNS 관련 문제는 중국 본토·해외 분할 해석 설정을, Linux 설치와 자동 시작 문제는 v2rayN Linux 설치 가이드를 참고하세요.

사용 가능한 설정에서 관리 가능한 설정으로

먼저 최소 기준 설정 하나를 고정하기

고급 설정의 출발점은 규칙을 더 많이 추가하는 것이 아니라 안정적으로 재현할 수 있는 최소 기준 설정을 보관하는 것입니다. 기준 설정에는 사용 가능한 구독 그룹, 검증된 노드 하나, 시스템 프록시 진입점, 단순한 사설 주소 직접 연결 규칙, 명확한 기본 아웃바운드, 확인 가능한 로그가 포함되어야 합니다. 모든 애플리케이션을 다룰 필요는 없지만 요청이 어디에서 들어오고, 어떻게 해석되며, 어떤 라우팅에 매칭되고, 어느 아웃바운드를 사용하는지는 답할 수 있어야 합니다.

기준 설정에 기능을 추가할 때는 작은 단위로 변경하세요. 먼저 GeoSite와 GeoIP 분할 라우팅을 추가하고, 검증한 뒤 원격 DNS를 추가하며, 다시 검증한 다음 TUN을 적용하고, 마지막으로 프로세스 규칙, 엄격한 라우팅, 복잡한 도메인 범위를 고려합니다. 각 단계에서 설정 스냅샷과 테스트 대상을 보관하세요. 테스트 대상에는 일반 웹페이지, LAN 서비스, 프록시가 필요한 도메인, 직접 연결 도메인, 시스템 프록시를 읽지 않는 애플리케이션 하나가 포함되어야 변화가 특정 상황만 해결하지 않았는지 확인할 수 있습니다.

생성된 설정을 이해한 뒤 사용자 지정 여부 결정하기

v2rayN 같은 클라이언트는 화면 설정을 커널 설정으로 변환합니다. 고급 사용자는 생성 결과의 inbounds, outbounds, routing, dns, log를 확인하는 방법을 익혀야 하지만, 임시로 생성된 파일을 장기간 직접 수정해 클라이언트를 우회해서는 안 됩니다. 클라이언트를 다시 시작하거나 노드를 바꾸면 파일이 다시 생성될 수 있기 때문입니다. 올바른 방법은 클라이언트가 제공하는 사용자 지정 설정, 라우팅 규칙, 프리셋 진입점에서 수정하고 생성 결과로 원하는 필드에 반영되었는지 확인하는 것입니다.

설정을 확인할 때는 먼저 태그 관계를 추적하세요. 라우팅 규칙의 outboundTag는 실제 아웃바운드 태그와 일치해야 하고, DNS 서버에 아웃바운드를 지정했다면 해당 태그도 존재해야 합니다. 인바운드 태그는 규칙 적용 범위를 제한하는 데 사용할 수 있습니다. 필드 이름은 맞지만 태그 철자가 다르면 커널이 시작을 거부하거나 예상과 다른 경로를 사용할 수 있습니다. 배열 순서도 특히 라우팅 규칙, DNS 서버 선택, 도메인 매칭 목록에서 중요합니다.

{
  "dns": {
    "servers": [
      {
        "address": "https://dns.example/dns-query",
        "domains": ["geosite:cn"],
        "skipFallback": true
      },
      {
        "address": "https://resolver.example/dns-query",
        "domains": ["geosite:geolocation-!cn"]
      }
    ],
    "queryStrategy": "UseIP"
  }
}

이 조각은 도메인 집합에 따라 DNS 서버를 선택하는 구조를 보여 주며, 예시 도메인은 필드를 설명하기 위한 것입니다. 실제 설정에서는 현재 커널이 해당 문법을 지원하는지 확인하고 해석 서비스에 올바른 아웃바운드를 지정하세요. skipFallback은 매칭된 서버가 실패했을 때의 대체 동작에 영향을 주므로 결과를 이해하지 못한 상태에서 일괄 활성화하면 안 됩니다. DNS 설정을 완료한 뒤에도 라우팅과 함께 확인해 해석 요청과 대상 연결이 일관된 경로를 사용하는지 살펴보세요.

네트워크 환경별 설정 범위 만들기

가정, 사무실, 공용 네트워크, 모바일 핫스팟은 DNS, IPv6, LAN 대역, 포트 접근성이 서로 다를 수 있습니다. 강한 가정을 담은 하나의 규칙 세트로 모든 환경을 덮지 마세요. 네트워크를 자주 전환한다면 “시스템 프록시 기본”, “TUN 제어”, “LAN 유지”처럼 몇 가지 설정을 준비하고, 이름에는 장소보다 제어 범위를 표시하세요. 전환 후 현재 기본 경로와 DNS를 먼저 확인하고 클라이언트를 시작하면 이전 인터페이스가 남아 생기는 문제를 줄일 수 있습니다.

사무실 네트워크는 내부 도메인과 사설 DNS를 사용할 수 있으므로 이러한 요청은 로컬 해석 경로에 두고 내부 주소는 직접 연결해야 합니다. 가정 네트워크의 저장 장치, 프린터, 미디어 기기도 사설 대역 우회가 필요합니다. 공용 네트워크에는 로그인 인증 페이지가 있을 수 있으므로 네트워크에 연결한 뒤 먼저 로컬 인증을 완료하고 프록시나 TUN을 시작하세요. 인증 페이지가 열리지 않으면 시스템 프록시와 TUN을 잠시 끄고 인증을 완료한 다음 원래 설정을 복원하세요.

주관적 판단 대신 테스트 매트릭스 사용하기

관리 가능한 설정에는 고정된 테스트 매트릭스가 필요합니다. 변경할 때마다 다음 순서로 테스트하세요. 클라이언트가 시작되는가, 구독이 업데이트되는가, 알려진 노드가 연결되는가, 직접 연결 도메인이 direct를 사용하는가, 프록시 도메인이 proxy를 사용하는가, LAN 주소에 접근할 수 있는가, DNS가 예상한 서버를 사용하는가, TUN을 끈 뒤 네트워크가 복구되는가. 결과는 “통과, 실패, 미테스트”로 기록하고 단순히 “네트워크 정상”이라고만 쓰지 마세요.

회귀 문제가 발생하면 처음 실패한 항목에 해당하는 계층으로 돌아가세요. 클라이언트를 시작할 수 없다면 웹페이지를 테스트하지 말고, DNS를 확인하지 않았다면 라우팅을 평가하지 마세요. LAN이 실패하면 사설 주소 규칙과 인터페이스를 확인하고, TUN을 끈 뒤 복구되지 않으면 먼저 시스템 네트워크를 처리하세요. 테스트 순서를 고정하면 클라이언트, 커널, 데이터 파일을 업데이트할 때도 같은 절차로 검증할 수 있어 기억에 의존하지 않게 됩니다.

장기 학습 과정 만들기

이 매뉴얼을 마친 뒤에는 먼저 연결 로그와 생성된 설정을 읽는 법을 익히고, 도메인 전략, DNS 아웃바운드, TUN 라우팅, 프로토콜 매개변수로 범위를 넓히세요. 프로토콜 학습은 필드 관계를 중심으로 진행합니다. VLESS의 사용자 식별자와 흐름 제어, REALITY의 서버 이름과 공개 키, 전송 계층의 서비스 이름과 경로를 실제 노드 설정과 함께 이해해야 합니다. 많은 설정 조각을 모으는 것부터 시작하지 마세요. 클라이언트 버전, 커널 기능, 서버 조건을 벗어난 조각은 그대로 재사용하기 어렵습니다.

일상 유지 관리의 핵심은 설명 가능성입니다. 현재 노드가 어느 그룹에서 왔는지, 시스템 프록시나 TUN이 켜져 있는지, 주요 DNS 경로가 무엇인지, 라우팅 기본 아웃바운드가 무엇인지, 기준 설정으로 어떻게 복구하는지 알아야 합니다. 설정이 복잡할수록 숨은 상태를 줄여야 합니다. 구체적인 문제가 생기면 해당 장으로 돌아간 뒤 사이트 내 관련 글과 빠른 시작 페이지의 자주 묻는 질문을 확인하고, 계층에 따라 로그와 재현 절차를 수집하세요.