v2rayN 설정 가이드

1단계: 핵심 개념

클라이언트, 코어, 원격 서버 구분하기

연결을 세 부분으로 나눠 이해하세요. v2rayN은 노드를 저장하고 구독을 관리하며 설정을 생성해 코어를 실행하는 그래픽 클라이언트입니다. 코어는 로컬 포트를 열고 프로토콜을 처리하며 도메인을 조회하고 아웃바운드를 선택합니다. 원격 서버는 연결을 받아 요청을 전달합니다. 클라이언트를 설치해도 사용할 수 있는 노드가 자동으로 생기지는 않으며, 구독을 등록했다고 원격 서버가 작동하는 것도 아닙니다. 문제를 해결할 때는 이 세 계층을 각각 확인하면 원격 장애를 클라이언트 설정 문제로 오해하지 않을 수 있습니다.

Project V, V2Fly, Xray의 관계를 알아두세요. Project V는 관련 도구와 프로토콜 생태계의 배경이며, V2Fly는 V2Ray 개발을 이어가고 Xray는 관련 코어의 한 갈래입니다. 클라이언트는 여러 코어를 사용할 수 있지만, 특정 프로토콜을 지원한다고 해서 모든 전송 방식과 보안 조합까지 지원한다는 뜻은 아닙니다. 가져오기에 성공했다면 설정을 인식했다는 의미일 뿐입니다. 실제 코어가 생성된 필드를 해석하고 서버와 협상할 수 있는지 확인해야 합니다.

요청 흐름으로 매개변수 이해하기

앱에서 요청을 보낼 때의 흐름을 살펴보세요. 시스템 프록시를 사용하는 브라우저는 먼저 로컬 리스닝 포트에 연결합니다. 코어는 대상 도메인이나 주소를 확인한 뒤 규칙에 따라 직접 연결하거나 프록시를 사용하거나 차단합니다. 프록시 아웃바운드는 노드 서버에 연결해 필요한 핸드셰이크를 수행합니다. TUN을 사용하면 가상 네트워크 인터페이스가 진입점이 되지만, 이후에도 라우팅 판단과 사용 가능한 아웃바운드가 필요합니다. 따라서 트래픽을 넘기는 방식을 바꿔도 잘못된 노드 주소, 인증 정보 또는 전송 매개변수는 해결되지 않습니다.

노드 매개변수는 항목별로 나눠 확인하세요. 서버 주소와 포트는 연결 대상이고, 사용자 ID나 비밀번호는 인증에 사용됩니다. 전송 방식은 데이터를 전달하는 방법을 정하며, TLS나 REALITY 등의 설정은 해당 보안 핸드셰이크를 결정합니다. VMess, VLESS, Trojan, Shadowsocks는 서로 다른 프로토콜이며 REALITY는 이들과 나란한 구독 형식이 아닙니다. 서비스 제공자가 안내한 전체 조합을 그대로 입력하고, 이름이 비슷하다는 이유로 필드를 바꾸지 마세요.

확인 가능한 판단 기준 세우기

도메인 조회, 전송 연결, 앱 응답을 구분하세요. 도메인 조회에 실패하면 요청이 노드에 도달하지 않았을 수 있습니다. 연결 거부는 리스닝 상태나 원격 포트를 확인해야 하는 경우가 많습니다. 핸드셰이크 오류라면 보안 매개변수와 시스템 시간을 점검하세요. 페이지에서 오류 상태를 반환했다면 대상 서비스 문제일 수도 있습니다. 모든 현상을 '프록시가 안 켜짐'으로 뭉뚱그리지 마세요. 문제가 발생한 앱, 대상, 시간, 모드를 기록하고 같은 시점의 코어 로그를 확인하세요.

연결 테스트 결과가 의미하는 범위를 이해하세요. 목록의 연결 테스트는 클라이언트가 사용하는 테스트 방법만 확인하며, 모든 사이트와 앱, 네트워크에서 정상 작동한다는 보장은 아닙니다. 테스트 대상이 차단되어 실패해도 실제 서비스는 접속될 수 있고, 반대로 테스트에 성공해도 도메인 조회, 장시간 연결, 파일 전송까지 정상이라는 뜻은 아닙니다. 실제 웹페이지와 앱을 각각 하나씩 정해 검증에 사용하세요.

이 단계를 마칠 때는 메뉴 이름을 쓰지 않고 요청 흐름을 설명해 보세요. 어떤 앱이 어떤 진입점을 통해 어떤 대상을 어느 코어에 전달하고, 어떤 아웃바운드로 보내는지 말할 수 있어야 합니다. 용어를 보충하려면 핵심 개념 빠른 참조를 확인하세요. 다음 장은 모두 이 흐름을 다룹니다. 모든 프로토콜 필드를 한꺼번에 외우거나 연결이 되기도 전에 복잡한 규칙을 추가할 필요는 없습니다.

2단계: 클라이언트 선택

운영체제와 프로세서부터 확인하기

데스크톱에서는 v2rayN을 우선 고려한 뒤 운영체제와 프로세서 아키텍처에 맞춰 클라이언트 다운로드 페이지를 확인하세요. Windows에서는 '설정 → 시스템 → 정보'에서 시스템 종류를 확인합니다. macOS에서는 '이 Mac에 관하여'에서 칩 또는 프로세서를 확인하고, Linux에서는 배포판의 패키지 형식과 시스템 아키텍처를 모두 확인하세요. 컴퓨터 브랜드만 보고 설치 파일을 고르거나, 인터페이스가 비슷하다는 이유로 다른 플랫폼의 패키지를 바꿔 사용하지 마세요.

Windows 다운로드 영역에서 데스크톱 버전과 클래식 WPF 버전을 구분하세요. 데스크톱 버전은 크로스 플랫폼 인터페이스를 사용해 여러 데스크톱 운영체제에서 비슷한 방식으로 쓰려는 사용자에게 적합합니다. WPF 버전은 Windows용으로 클래식 인터페이스와 사용 방식을 유지합니다. 두 버전 모두 실제 패키지의 실행 조건을 확인해야 합니다. '최신' 또는 '클래식'이라는 이유만으로 특정 기능이 반드시 있다고 판단하지 마세요. 메뉴 위치, 설정 적용 범위, 실행 환경은 배포 버전에 따라 달라질 수 있습니다.

코어 기능을 현재 설정에 맞추기

Android에서는 Xray 코어 기반의 v2rayNG를 우선 사용하고, V2Fly 코어를 사용하는 v2flyNG를 대안으로 고려하세요. 클라이언트를 여러 개 설치해 번갈아 쓰기보다는 기존 노드가 사용하는 프로토콜과 기능에 맞춰 선택하는 것이 좋습니다. 두 앱의 설정이 완전히 같다고 가정하지 마세요. 가져오는 방법이 비슷해도 설정 데이터베이스를 그대로 복사할 수 있다는 뜻은 아닙니다. 처음 사용하는 경우 Android 빠른 시작 단계를 참고하고, 네트워크 트래픽을 넘기는 기능은 한 번에 하나만 사용하세요.

클라이언트 기능과 구독 내용을 구분하세요. 클라이언트를 바꾼다고 일반 노드가 다른 보안 조합으로 바뀌거나 서버에서 제공하지 않은 매개변수가 채워지지는 않습니다. 가져온 뒤 필드가 빠져 있다면 구독이 어떤 클라이언트를 대상으로 하는지, 링크가 완전한지, 노드에 어떤 코어가 필요한지 확인하세요. 가져오기를 통과하려고 매개변수를 임의로 삭제하지 마세요. 저장은 되더라도 실제 핸드셰이크에서 호환성 문제가 드러날 수 있습니다.

전환 전에 되돌릴 수 있는 작업 환경 마련하기

데스크톱 인터페이스를 바꾸기 전에 기존 환경의 구독 그룹, 현재 노드, 리스닝 포트, 라우팅 모드, DNS 설정을 기록하고 클라이언트가 지원하는 백업을 내보내세요. 새 환경은 별도의 설치로 보고 노드 하나로 기본 접속부터 확인하세요. 두 클라이언트를 동시에 실행해 같은 포트를 사용하지 않도록 하고, 양쪽에서 시스템 프록시를 번갈아 설정하지 마세요. 화면에 표시된 모드와 실제 시스템에 적용된 주소가 달라질 수 있습니다.

실행 조건을 평가할 때는 인터페이스 실행과 트래픽 전달을 따로 보세요. 메인 창이 열려도 코어가 정상적으로 시작되지 않았을 수 있으며, 코어가 실행돼도 현재 계정에 가상 네트워크 인터페이스 생성 권한이 없을 수 있습니다. 일반 시스템 프록시를 위해 프로그램 전체를 계속 관리자 권한으로 실행할 필요는 대개 없습니다. TUN은 권한 상승이나 해당 서비스 방식이 필요할 수 있습니다. 필요한 기능에 맞춰 권한을 부여하고, 모든 오류를 권한 상승으로 해결하려 하지 마세요.

선택을 마친 뒤 운영체제, 프로세서, 사용할 클라이언트, 적용할 진입 모드를 한 줄로 정리하세요. 다운로드 페이지에서 해당 플랫폼의 요구 사항을 확인하면 설치 도중 계획을 바꾸는 일을 줄일 수 있습니다. 데스크톱 인터페이스 두 가지를 비교하려면 v2rayN 데스크톱 버전과 WPF 버전 비교를 참고하고, 외관보다 운영체제 지원과 기능 차이를 확인하세요.

이 단계의 목표는 '모든 기능 활성화'가 아니라 '올바른 패키지 선택'입니다. 현재 기기와 기존 노드에 필요한 조건을 충족하는 단순하고 재현 가능한 연결 방법 하나를 유지하세요. 이후 더 많은 앱을 연결하거나 규칙을 조정할 때 필요한 기능을 추가하면 문제 발생 시 확인 범위를 줄일 수 있습니다.

3단계: 설치 및 첫 실행

고정된 설치 경로와 실행 조건 준비하기

Windows 클라이언트 다운로드에서 확인한 버전 유형을 고른 뒤 실제 설치 패키지 형식에 맞춰 진행하세요. 설치 프로그램은 안내에 따라 설치하고, 압축 파일은 고정된 폴더에 풀어 실행하세요. 압축 창에서 바로 실행하지 마세요. 지속적으로 사용할 데이터 폴더를 임시 정리 대상 위치에 두지 않는 것이 좋습니다. 프로그램은 설정, 로그, 코어 파일을 저장하므로 경로가 짧은지보다 폴더에 쓸 수 있는지가 중요합니다.

처음 실행할 때 실행 구성 요소가 없다는 안내가 나오면 현재 배포 패키지 설명에 따라 필요한 구성 요소를 설치하세요. 오래된 안내만 보고 아키텍처가 맞지 않는 구성 요소를 설치하지 마세요. 메시지에 표시된 정확한 이름을 기록하고, 실행 환경 누락, 파일 차단, 코어 실행 실패를 구분하세요. 시스템 보안 경고가 나타나면 출처와 파일 속성을 먼저 확인한 뒤 진행 여부를 판단하세요. 인터페이스를 열기 위해 시스템 보호 기능 전체를 끄거나 모든 알 수 없는 프로그램을 허용해서는 안 됩니다.

인터페이스와 코어가 각각 실행되는지 확인하기

메인 창을 연 다음 로그나 정보 영역을 찾으세요. 아직 노드가 없다면 연결되지 않는 것이 정상입니다. 설정 읽기 실패, 경로 쓰기 불가, 리스닝 실패가 있는지 확인하세요. 인터페이스가 응답한다는 사실은 그래픽 프로그램이 정상이라는 뜻일 뿐, 코어가 리스닝 중이라는 뜻은 아닙니다. 노드를 추가한 뒤 시작 정보를 다시 확인해 코어가 곧바로 종료되거나 반복해서 재시작하지 않는지 확인하세요. 작동하지 않는 포트로 브라우저가 연결되기 전에 시스템 프록시 설정을 진행하지 마세요.

설정에서 로컬 리스닝 관련 항목을 찾아 주소, 포트, 지원되는 진입 프로토콜을 기록하세요. 버전에 따라 혼합 진입점을 제공하거나 HTTP와 SOCKS 진입점을 따로 제공할 수 있으므로 오래된 글만 보고 현재 기본 포트를 추측하지 마세요. 일반적으로 로컬 앱은 루프백 주소로 접속하면 됩니다. LAN 연결 허용을 켜면 접근 가능한 범위가 넓어집니다. 다른 기기와 공유해야 할 때만 활성화하고 방화벽과 접근 제한도 함께 검토하세요.

Get-NetTCPConnection -State Listen |
  Sort-Object LocalPort |
  Select-Object LocalAddress, LocalPort, OwningProcess

위 명령은 현재 TCP 리스닝 포트와 프로세스 ID를 표시하며 네트워크 설정을 변경하지 않습니다. 결과의 포트를 인터페이스에 기록한 값과 비교하고 작업 관리자의 '세부 정보'에서 해당 프로세스를 확인하세요. 다른 프로그램이 포트를 사용하고 있다면 중복 실행 중인 클라이언트를 먼저 종료하세요. 두 프로그램을 함께 실행해야 한다면 하나의 리스닝 포트를 바꾸고 이를 사용하는 앱도 함께 업데이트하세요. 낯선 프로세스라고 해서 바로 종료하지 마세요.

실행 기준과 종료 후 복구 방법 기록하기

자동 시작, 구독 자동 업데이트, TUN 등 부가 기능은 잠시 끄고 수동 실행과 종료를 한 번 확인하세요. 종료하기 전에 시스템 프록시를 해제하고, 종료 후 브라우저가 기존 네트워크 방식으로 접속되는지 확인하세요. 이 과정은 복구 경로를 점검합니다. 이후 노드에 문제가 생겨도 시스템이 로컬 프록시 진입점을 사용하지 않도록 되돌리는 방법을 알 수 있습니다. 메인 창을 닫아도 트레이로 최소화될 수 있으므로 트레이 메뉴에서 프로그램이 완전히 종료됐는지 확인하세요.

다른 데스크톱 운영체제에서도 같은 순서로 확인하세요. 프로그램 실행, 데이터 저장, 코어 로드, 리스닝 충돌 여부, 종료 후 복구를 차례로 점검합니다. macOS는 칩에 맞는 설치 경로를, Linux는 배포판의 패키지 형식을 선택하세요. 권한 문제가 발생하면 설치 위치와 시스템 메시지를 확인하고 모든 파일의 권한을 무작정 넓히지 마세요. 리스닝 충돌을 더 자세히 확인하려면 로컬 포트 사용 중 문제 해결을 참고하세요.

이 단계를 마치면 설치 위치, 데이터 백업 방법, 리스닝 설정을 간단히 기록하세요. 클라이언트를 한 번 재시작해 설정이 유지되는지 확인합니다. 이 기준이 안정적이어야 이후 구독을 가져오거나 규칙을 조정했을 때 결과를 비교할 수 있습니다. 설치 단계의 불안정성을 네트워크 변화로 오해하지 않게 됩니다.

4단계: 구독 및 노드 관리

그룹을 추가한 뒤 업데이트하기

'구독 그룹 설정'을 열고 알아보기 쉬운 그룹 이름을 입력한 다음 서비스 제공자가 준 구독 주소를 해당 입력란에 붙여 넣으세요. 앞뒤 공백, 줄바꿈, 복사 과정에서 붙은 문장부호가 없는지 확인합니다. 구독 링크에는 접속 인증 정보가 포함될 수 있으므로 민감 정보로 취급하고 공개 스크린샷이나 메모, 문의 글에 넣지 마세요. 그룹을 저장하고 메인 화면으로 돌아와 해당 그룹을 선택한 뒤 '현재 구독 업데이트(프록시 사용 안 함)'를 실행하세요.

'프록시 사용 안 함'은 일반적으로 로컬 프록시가 아직 설정되지 않았거나 구독 주소에 직접 접속할 수 있을 때 사용합니다. 프록시를 통한 업데이트는 이미 사용 가능한 연결 경로가 있어야 합니다. 직접 업데이트에 실패하면 현재 네트워크에서 구독 주소에 접속 가능한지 먼저 확인한 뒤 기존 프록시를 사용할지 판단하세요. 사용할 수 있는 노드가 전혀 없는데 프록시 업데이트로 최초 연결 문제까지 해결하려고 하지 마세요. 서로 의존하는 상황이 됩니다.

가져오기 실패와 구문 분석 실패 구분하기

업데이트 결과를 볼 때는 먼저 내용을 가져왔는지 확인하세요. 도메인 조회 실패, 연결 시간 초과, 서버의 거부 응답은 가져오기 단계의 문제입니다. 응답은 받았지만 노드가 나타나지 않는다면 형식이 맞지 않거나 로그인 페이지가 반환됐거나 노드 매개변수를 인식하지 못한 것일 수 있습니다. 웹페이지가 열린다고 구독 본문이 반환된다는 뜻은 아닙니다. 서비스 제공자에게 문의할 때는 오류 유형과 민감 정보를 가린 응답 설명만 보내고 전체 구독 주소나 인증 매개변수는 보내지 마세요.

업데이트에 성공하면 노드 목록에서 이름, 프로토콜, 주소, 소속 그룹을 확인하세요. 이름이 같아도 같은 설정이라는 뜻은 아니며, 이름만으로 실제 네트워크 품질을 알 수 없습니다. 노드 하나를 선택해 활성 서버로 지정하고 코어가 정상적으로 로드되는지 살펴보세요. 많은 노드를 한꺼번에 병렬 테스트하지 마세요. 테스트가 대역폭을 차지하거나 서비스 제한을 유발할 수 있고, 짧은 시간의 결과가 실제 사용 시 안정성을 가릴 수 있습니다.

수동 노드와 구독 업데이트 덮어쓰기 이해하기

공유 링크 하나를 추가하려면 클라이언트의 클립보드 가져오기 기능을 사용한 뒤 가져온 필드를 확인하세요. 수동 노드는 임시 테스트나 소수 설정에 적합하고, 구독 그룹은 서비스 제공자가 중앙에서 업데이트할 때 적합합니다. 구독 노드를 직접 수정해도 변경 내용이 영구적으로 유지된다고 가정하지 마세요. 다음 업데이트에서 항목이 다시 생성될 수 있습니다. 사용자 설정을 오래 유지하려면 별도의 수동 그룹에 복사하고 원래 구독과 동기화되지 않는다는 점을 명확히 표시하세요.

그룹을 삭제하기 전에 작업이 그룹 정보, 구독 노드, 전체 서버 중 무엇에 영향을 주는지 확인하세요. 테스트 그룹과 일상적으로 쓰는 그룹을 섞지 않는 것이 좋습니다. 구독 업데이트 후 노드 수가 줄어도 가져오기가 손상된 것은 아닐 수 있습니다. 서비스 제공자가 사용 가능한 항목을 조정했을 수도 있습니다. 먼저 업데이트 결과와 그룹 필터를 확인한 뒤 다른 그룹을 잘못 선택하지 않았는지 살펴보세요. 이전 백업은 로컬 기록을 복구할 뿐, 사용할 수 없게 된 원격 서비스까지 되살리지는 못합니다.

보안 관련 매개변수를 확인할 때 서버 주소, 포트, 사용자 ID, 전송 방식, 서버 이름, 관련 키 매개변수를 하나의 조합으로 일치시키세요. 핸드셰이크 오류를 없애려고 인증서 검증을 임의로 끄거나 다른 노드의 보안 필드를 복사하지 마세요. 시스템 시간이 크게 어긋나도 핸드셰이크에 영향을 줄 수 있으므로 시간을 바로잡은 뒤 다시 테스트하세요. 서버 요구 사항을 정확히 알고 있을 때만 필드를 직접 수정하세요.

업데이트 빈도는 서비스 제공자의 설정 변경 주기에 맞추세요. 자주 업데이트한다고 속도가 빨라지는 것은 아니며, 문제를 확인하는 중인 상태를 덮어쓸 수 있습니다. 중요한 변경 전에는 로컬 백업을 저장하고 현재 활성 노드를 기록하세요. 업데이트 후 같은 대상으로 다시 확인하면 내용 변경과 일시적인 연결 실패를 구분하고, 당시 상태를 보존한 채 원인을 찾을 수 있습니다.

이 단계의 목표는 구독이 어디에서 왔는지, 노드가 어느 그룹에 속하는지, 어떤 항목이 현재 활성화됐는지, 다음 업데이트가 무엇을 덮어쓰는지 설명할 수 있는 것입니다. 기본 가져오기에 실패하면 빠른 시작의 구독 단계를 순서대로 다시 진행하세요. 매개변수 이름이 불분명하다면 용어집을 확인하고 클라이언트 데이터 폴더 전체를 반복해서 삭제하지 마세요.

5단계: 시스템 프록시와 프록시 모드

트래픽 진입점과 아웃바운드 규칙 구분하기

먼저 두 가지를 나눠 생각하세요. 앱이 요청을 클라이언트에 전달하는 방식과, 클라이언트가 요청을 받은 뒤 전송하는 방식입니다. '시스템 프록시 자동 설정'은 앞의 문제를, 라우팅의 전역 또는 우회 규칙은 뒤의 문제를 해결합니다. 시스템 프록시를 켜도 모든 프로그램이 이를 사용하는 것은 아닙니다. 전역 프록시를 선택해도 코어에 들어온 트래픽에만 영향을 줍니다. 이 두 계층을 이해해야 브라우저는 되는데 일부 데스크톱 프로그램은 달라지지 않는 이유를 설명할 수 있습니다.

v2rayN에서 '시스템 프록시 자동 설정'을 선택한 뒤 Windows의 '설정 → 네트워크 및 인터넷 → 프록시'에서 실제 주소와 포트를 확인하세요. 클라이언트가 시스템 프록시에 사용하는 현재 리스닝 진입점과 일치해야 합니다. 트레이 아이콘만 보고 판단하지 마세요. 일반적으로 로컬 루프백 주소를 사용해야 하며 노드 서버 주소를 입력하지 않습니다. 원격 노드 포트는 코어가 서버에 연결할 때 쓰는 포트이지 브라우저에 입력하는 로컬 프록시 포트가 아닙니다.

앱 동작에 맞춰 트래픽 전달 방식 선택하기

먼저 시스템 프록시를 사용하는지 확인된 브라우저로 실제 대상에 접속해 보세요. 브라우저에 별도의 프록시, 프록시 확장 프로그램, 특정 프로필이 설정돼 있으면 시스템 설정을 따르지 않을 수 있습니다. 문제를 확인할 때는 기존 설정을 기록한 뒤 프록시 설정을 한 가지 방식만 남기고 충돌 항목을 잠시 끄세요. 명령줄 도구, 게임, 백그라운드 서비스도 별도의 네트워크 스택을 사용할 수 있으므로 각 앱의 설정을 확인해야 합니다. 브라우저 접속 성공을 모든 앱에 일반화하지 마세요.

앱에서 프록시를 직접 설정해야 한다면 앱이 지원하는 프로토콜에 맞춰 HTTP 또는 SOCKS 진입점을 입력하고, 클라이언트의 실제 리스닝 주소와 포트를 사용하세요. 두 진입점의 필드를 기계적으로 바꿔 넣으면 안 됩니다. 혼합 진입점을 제공하더라도 선택한 프로토콜을 실제로 지원하는지 확인하세요. 앱에 별도의 도메인 조회 옵션이 있다면 조회를 프록시 측에 맡기는지도 확인하세요. 요청은 프록시를 통과하지만 도메인은 다른 경로로 조회되는 상황을 방지할 수 있습니다.

해제, 유지, 자동 설정의 차이

'시스템 프록시 해제'는 시스템의 현재 수동 프록시 설정을 삭제하지만 각 앱의 내부 설정까지 자동으로 끄지는 않습니다. '시스템 프록시 변경 안 함'은 클라이언트가 시스템 설정을 직접 수정하지 않는다는 뜻이지, 시스템에 프록시가 없다는 의미는 아닙니다. 클라이언트를 종료한 뒤 모든 웹페이지 접속이 실패하면 시스템이 아직 로컬 포트를 가리키는지, 브라우저에 별도 설정이 남아 있는지 확인하세요. 클라이언트가 종료된 상태에서 아무도 리스닝하지 않는 진입점을 계속 사용하지 마세요.

모드를 바꾸기 전에 현재 상태를 기록하고, 변경 후 시스템 설정을 비교한 다음 새 연결을 테스트하세요. 기존 장시간 연결은 이전 경로를 계속 사용할 수 있고 브라우저 연결 풀 때문에 결과가 늦게 반영될 수 있습니다. 테스트 페이지를 닫았다가 다시 열거나 필요하면 테스트 앱을 완전히 종료한 뒤 재시도하세요. 테스트할 때마다 노드, DNS, 라우팅을 동시에 바꾸면 현상이 달라져도 어떤 변경이 영향을 줬는지 알 수 없습니다.

이 단계를 마친 뒤에는 정방향과 역방향을 각각 한 번 확인하세요. 자동 설정을 켜 브라우저가 로컬 진입점을 통해 작동하는지 확인하고, 시스템 프록시를 해제해 원래 네트워크 동작으로 돌아오는지 확인합니다. 장애가 발생했을 때 사용할 복구 절차로 이 과정을 기록해 두세요. 앱이 시스템 프록시를 사용하지 않으면서도 트래픽 전달이 꼭 필요한 경우에만 다음 TUN 단계로 진행하세요. 스위치가 더 많아 보이도록 모든 기능을 켜지는 마세요.

6단계: 라우팅 및 DNS

기본 제공 모드로 규칙 기준 세우기

먼저 라우팅 관련 메뉴에서 현재 요구에 맞는 기본 제공 규칙을 선택하세요. 예를 들어 '중국 본토 우회'에 해당하는 모드를 적용한 뒤 실제 접속을 확인합니다. 규칙 세트마다 사설 주소, 도메인 분류, 기본 아웃바운드 조합이 다를 수 있으므로 모드 이름만 보고 세부 동작을 추측하지 마세요. 사용 전에 규칙 내용과 순서를 확인하고 로컬 네트워크 리소스가 직접 연결되는지, 일치하지 않는 대상은 어디로 가는지, 참조하는 데이터 파일이 정상적으로 로드되는지 살펴보세요.

규칙 적용 순서를 이해하세요. 일반적으로 라우팅 규칙은 위에서부터 확인합니다. 앞쪽의 범위가 넓은 규칙이 뒤쪽의 세부 규칙보다 먼저 일치하면 뒤쪽 규칙은 적용되지 않을 수 있습니다. 특정 서비스에 예외를 추가할 때는 기존 규칙과의 관계를 먼저 확인한 뒤 적절한 위치에 배치하세요. 모든 트래픽을 프록시로 보내는 규칙을 맨 위에 추가하고 맨 아래의 사설 주소 직접 연결 규칙이 작동하길 기대하지 마세요. 변경한 뒤에는 페이지가 열리는지만 보지 말고 로그에서 실제로 일치한 규칙을 확인하세요.

도메인 규칙과 주소 규칙 구분하기

도메인 규칙은 요청에서 확인할 수 있는 도메인 정보를 기준으로 하고, 주소 규칙은 대상 주소를 기준으로 합니다. 하나의 서비스가 여러 도메인과 분산 주소를 사용할 수 있으므로 메인 페이지 도메인만 추가해서는 로그인, 정적 리소스, 다운로드 요청까지 처리하지 못할 수 있습니다. 반대로 특정 조회 결과 주소를 규칙에 넣으면 같은 주소를 공유하는 다른 서비스에 영향을 줄 수 있습니다. 한 번의 조회 결과를 장기간 사용할 규칙으로 삼기보다 업무에 해당하는 도메인 범위를 명확히 지정하세요.

{
  "type": "field",
  "domain": ["geosite:cn"],
  "outboundTag": "direct"
}

이것은 규칙 객체 한 개이며 전체 설정이 아닙니다. 해당 코어 설정의 규칙 배열에 넣어야 하고, 환경에 도메인 분류 데이터가 있어야 하며, 실제 아웃바운드 태그 이름도 direct여야 합니다. 클라이언트가 생성하는 태그는 다를 수 있으므로 생성된 설정을 먼저 확인해 대응시키세요. 이 조각으로 설정 파일 전체를 덮어쓰거나 공유 링크만 받는 가져오기 입력란에 붙여 넣지 마세요. 클라이언트가 지원하는 규칙 편집 기능을 우선 사용하세요.

도메인 조회 경로와 트래픽 경로 맞추기

DNS는 도메인을 주소로 변환하지만 클라이언트 코어, 운영체제, 앱이 각각 조회할 수 있습니다. 원격 DNS와 직접 연결 DNS는 용도가 다른 설정 역할이며, 주소 하나를 두 번 입력한다고 분할 처리가 완성되는 것은 아닙니다. 원격 조회 서비스에 접속하려면 프록시가 필요한 경우 해당 서비스 연결에 사용할 아웃바운드를 명확히 지정하세요. 프록시가 조회에 의존하고 프록시 연결은 아직 완료되지 않은 조회에 다시 의존하는 시작 단계의 순환을 피해야 합니다.

먼저 도메인을 누가 조회하는지 확인한 다음 조회 요청이 어떤 경로를 통과하는지 살펴보세요. 브라우저에서 암호화 DNS를 사용하면 예상한 시스템 조회 경로를 우회할 수 있습니다. 앱이 주소로 직접 요청하면 코어가 원래 도메인을 확인하지 못할 수도 있습니다. 스니핑은 특정 조건에서 프로토콜 정보를 추출할 수 있지만 모든 연결을 식별하지는 못하며 완전한 DNS 설계를 대신할 수도 없습니다. 라우팅이 예상대로 동작하지 않으면 경로를 단순화한 뒤 기능을 하나씩 복구하세요.

잘못된 규칙이 적용되면 전체 대상 도메인, 실제 조회 주소, 규칙 순서, 현재 아웃바운드를 기록하세요. 규칙 데이터가 업데이트되면 같은 도메인의 분류가 달라질 수 있으므로 데이터 업데이트도 설정 변경으로 취급해야 합니다. 임시 예외 규칙으로 문제가 해결되면 근본 원인을 확인한 뒤 유지하세요. 서로 덮어쓰는 임시 규칙을 계속 쌓지 마세요. 관련 점검 방법은 DNS 유출 테스트 및 유출 방지 설정에서 확인하고, 예상한 조회 경로가 적용되는지 중점적으로 살펴보세요.

이 단계를 마치면 세 가지 결과를 설명할 수 있어야 합니다. 명시적 직접 연결, 명시적 프록시 연결, 일치하는 규칙이 없을 때의 기본 동작입니다. 재시작 후 규칙이 유지되는지, 코어가 알 수 없는 필드나 누락된 데이터를 보고하지 않는지도 확인하세요. 시스템 프록시에서 라우팅과 조회가 안정적으로 동작한 뒤 TUN을 켜세요. 그렇지 않으면 트래픽 전달 범위가 넓어져 기존의 국소 문제가 더 많은 앱에 영향을 줍니다.

7단계: TUN 모드와 트래픽 전달 범위

가상 인터페이스가 실제로 필요한지 판단하기

TUN은 가상 네트워크 인터페이스를 통해 라우팅 조건에 맞는 시스템 트래픽을 전달하므로 시스템 프록시를 사용하지 않지만 통합 라우팅이 필요한 앱에 적합합니다. 바뀌는 것은 트래픽 진입점입니다. 노드에 새 프로토콜 기능이 생기거나 잘못된 인증 정보가 자동으로 복구되는 것은 아닙니다. 켜기 전에 일반 시스템 프록시에서 같은 노드가 정상 작동하는지 확인하고 기준 환경을 유지하세요. 기본 연결부터 불안정하다면 구독, 리스닝, 라우팅 장으로 돌아가 점검하세요.

트래픽 전달 범위를 평가할 때 로컬 기기, LAN, 원격 대상을 따로 정리하세요. 프린터, 공유 폴더, 개발 서버, 원격 데스크톱, 다른 가상 네트워크에는 특정 직접 연결 경로가 필요할 수 있습니다. TUN을 사용한다고 모든 주소를 프록시로 보내야 하는 것은 아닙니다. 켜기 전에 사설 주소와 필요한 네트워크 대역을 어떻게 처리할지 확인하세요. 원격 관리 연결이 끊긴 뒤에야 네트워크 복구 방법을 고민하지 마세요. 원격 기기에서 작업할 때는 특히 로컬 복구 수단을 준비해야 합니다.

권한, 인터페이스, 라우팅 순서에 맞춰 시작하기

설정을 저장한 뒤 현재 클라이언트의 요구에 따라 관리자 권한이나 해당 서비스 방식을 사용하고 'TUN 모드 활성화'를 켜세요. 인터페이스와 코어에 따라 시작 방법이 다를 수 있으므로 실제 안내를 확인해야 합니다. 스위치를 켜자마자 접속 실패라고 판단하지 마세요. 코어가 종료되지 않았는지, 가상 인터페이스가 생성됐는지, 시스템 라우팅이 설정됐는지 먼저 확인하세요. 로그에 권한 부족, 인터페이스 생성 실패, 라우팅 기록 실패가 나오면 각각 따로 해결해야 합니다.

인터페이스나 드라이버 관련 문제가 표시되면 중복 실행 중인 클라이언트를 먼저 종료하고 다른 가상 네트워크 소프트웨어가 비슷한 리소스를 사용 중인지 확인하세요. 시스템의 모든 가상 네트워크 카드를 삭제하거나 드라이버를 한꺼번에 제거하지 마세요. 일부 인터페이스는 가상 머신, 컨테이너, 기업 네트워크에서 사용하므로 삭제하면 기존 환경에 영향을 줍니다. 먼저 TUN을 끄고 클라이언트를 재시작한 뒤 명확한 오류에 해당하는 구성 요소만 처리하고 각 작업을 기록하세요.

TCP, UDP, DNS의 실제 동작 확인하기

먼저 시스템 프록시에서 작동하던 웹페이지를 테스트한 다음, 기존에는 트래픽이 전달되지 않았던 앱을 테스트하세요. 둘 다 성공해야 진입점 변경이 목적을 달성했다고 볼 수 있습니다. UDP, 음성 통화, 실시간 통신을 사용하는 앱이라면 원격 서버와 해당 프로토콜 조합이 필요한 트래픽을 지원하는지 확인하세요. 웹페이지 접속이 된다고 UDP까지 정상이라는 뜻은 아닙니다. 앱이 실행돼도 이후 미디어 연결이 같은 경로를 사용하는 것은 아니므로 실제 기능을 사용해 검증하세요.

DNS는 TUN 문제 해결에서 별도로 확인해야 하는 계층입니다. 사용 설정에 따라 시스템 조회, 앱의 암호화 조회, 가상 인터페이스의 트래픽 전달이 함께 작동할 수 있습니다. 주소로는 연결되는 것처럼 보이는데 도메인 접속이 실패한다면 조회 경로, 원격 조회 서비스의 접속 가능 여부, 라우팅 순환을 먼저 확인하세요. 주소를 영구적으로 고정해 조회 문제를 가리지 말고 모든 DNS 설정을 바로 지우지도 마세요. 현재 값을 보존하고 코어가 지원하는 설정 방식과 하나씩 비교하세요.

LAN 기기에 접속할 수 없다면 도메인 예외를 추가하기 전에 대상 주소, 서브넷 마스크, 현재 라우팅을 확인하세요. 주소로 직접 연결하는 공유 서비스에는 도메인 규칙이 적용되지 않습니다. 다른 네트워크 터널도 실행 중이라면 라우팅 우선순위와 기본 출구가 충돌할 수 있으므로 불필요한 진입점을 하나씩 끄고 비교하세요. 테스트 후 조합을 복원해 어떤 항목이 충돌을 일으켰는지 확인하세요. 모든 문제를 노드 탓으로 돌리지 마세요.

절전 후 복귀하거나 무선 네트워크를 바꾸거나 유선 케이블을 뺐다 다시 연결한 뒤에는 가상 인터페이스와 조회 경로를 다시 확인하세요. 복구되지 않으면 먼저 TUN을 껐다가 다시 켜 클라이언트 상태를 재구성해 보세요. 그래도 실패하면 새 로그를 확인하고 권한을 계속 높이지 마세요. 정상 종료 후 네트워크가 복구되는지 확인하고, 비정상 종료 후에도 시스템 프록시와 라우팅 상태를 점검하세요. 자세한 원리와 절차는 v2rayN TUN 모드 설정 노트를 참고하세요.

이 단계의 완료 기준은 '스위치가 켜져 있음'이 아닙니다. 추가한 앱의 트래픽이 올바르게 전달되고, 직접 연결 리소스를 계속 사용할 수 있으며, 종료 후 복구 방법이 명확해야 합니다. 실제로 필요한 경우에만 TUN을 유지하세요. 일반 시스템 프록시로 모든 사용 사례를 처리할 수 있다면 더 간단한 진입점을 사용해 권한, 인터페이스, 라우팅 간의 영향을 줄여도 됩니다.

8단계: 유지 관리 및 문제 해결

백업과 업데이트를 별도로 진행하기

연결이 안정적일 때 구독 그룹, 수동 노드, 라우팅, DNS, 필요한 사용자 설정을 포함해 백업을 만드세요. 클라이언트가 제공하는 내보내기 방법을 사용하고 백업에 포함되지 않은 항목도 기록하세요. 백업에는 구독 인증 정보와 노드 식별 정보가 포함될 수 있으므로 관리되는 위치에 저장하고 공유하기 전에 반드시 민감 정보를 가리세요. 프로그램 파일만 저장해서는 사용 상태를 복원하기 어렵고 노드 이름만 캡처해도 전체 매개변수를 복구할 수 없습니다.

클라이언트 업데이트, 코어 업데이트, 구독 업데이트, 규칙 데이터 업데이트를 구분하세요. 각각 바뀌는 대상이 다르므로 따로 실행하고 매번 결과를 확인해야 합니다. 클라이언트를 업데이트하기 전에는 정상적으로 종료해 파일이 사용 중이지 않게 하세요. 업데이트 후 메뉴, 리스닝, 설정 마이그레이션 결과를 확인합니다. 현재 패키지에서 코어 구성 요소를 통합 관리한다면 해당 방식을 따르세요. 다른 출처의 코어 파일을 임의로 덮어쓰면 인터페이스가 생성하는 필드와 코어 기능이 맞지 않을 수 있습니다.

진입점부터 출구까지 순서대로 문제 찾기

문제가 발생하면 설정을 더 바꾸기 전에 마지막으로 변경한 항목을 기록하세요. '앱이 진입점을 사용하는가, 로컬에서 리스닝 중인가, 코어가 시작됐는가, 도메인이 조회되는가, 노드 핸드셰이크가 되는가, 대상이 응답하는가' 순서로 확인합니다. 각 단계를 통과한 뒤 다음 단계로 넘어가세요. 이렇게 하면 문제를 구체적인 경계로 좁힐 수 있습니다. 노드를 여러 번 바꾸고 구독을 새로고침하거나 시스템 네트워크를 초기화해 재현이 불가능해지는 일을 피할 수 있습니다.

브라우저만 실패하고 다른 앱은 정상이라면 브라우저의 별도 프록시, 확장 프로그램, 암호화 DNS, 캐시된 연결을 확인하세요. 모든 앱이 실패하면 리스닝 상태와 코어 로그부터 확인합니다. 특정 대상만 실패한다면 대상 자체, 도메인 규칙, 분산 리소스에 차이가 있는지 살펴보세요. 네트워크를 바꾼 뒤에만 실패한다면 DNS, 접속 인증, 라우팅 환경을 비교하세요. 원인을 분류하면 연결 테스트를 반복해서 누르는 것보다 효과적이며 불필요하게 설정을 다시 만들 필요도 줄어듭니다.

Get-Date
Resolve-DnsName example.com

위 명령은 현재 시스템 시간과 시스템 조회 결과를 보여줄 뿐, 클라이언트 내부의 원격 DNS를 테스트하지는 않습니다. 비교 기준으로 활용하세요. 시스템 조회는 실패하지만 코어 조회는 정상이라면 두 경로가 다르다는 뜻입니다. 시스템 조회가 정상이어도 프록시 아웃바운드가 작동한다고 볼 수는 없습니다. 핸드셰이크 오류가 발생하면 시스템 시간도 함께 확인하고 시간대와 시간 동기화 상태를 기록하세요. 명령 한 번의 성공만으로 전체 프록시 경로가 정상이라고 판단하지 말고 실제 앱으로 검증해야 합니다.

최소 재현 절차와 복구 동작 기록하기

로그에서는 연이어 발생한 시간 초과보다 먼저 나타난 관련 오류를 찾으세요. 오류가 발생한 모듈, 대상 유형, 시간을 기록하고 작업 순서와 대조합니다. 문의할 때는 전체 구독 주소, 사용자 ID, 비밀번호와 다른 민감 정보를 삭제하세요. 규칙을 보여줘야 한다면 필요한 부분과 아웃바운드 관계만 남기세요. 로그 수준을 높이면 더 많은 접속 기록이 생성될 수 있으므로 문제를 찾은 뒤에는 적절한 수준으로 되돌리고 필요 없는 복사본을 삭제하세요.

백업을 복원했다고 환경이 완전히 돌아왔다고 가정하지 말고 실제로 확인하세요. 먼저 그룹이 있는지 확인하고 활성 노드, 리스닝 포트, 라우팅, DNS를 차례로 점검한 다음 시스템 프록시나 TUN을 확인합니다. 이전 환경의 인터페이스, 권한, 설치 경로는 새 기기에 맞지 않을 수 있으므로 새 시스템에 맞춰 다시 설정해야 합니다. 복원 과정에서도 현재 백업을 보존하고 출처가 불분명한 오래된 설정으로 유일하게 작동하는 상태를 덮어쓰지 마세요.

모바일 기기 유지 관리에서는 배터리 최적화, 자동 시작, 백그라운드 제한도 확인해야 합니다. 화면을 잠근 뒤 연결이 끊기는 문제는 데스크톱 리스닝 포트 충돌과 다른 유형이므로 데스크톱 문제 해결 절차를 그대로 적용하지 마세요. v2rayNG 백그라운드 및 배터리 설정을 참고해 기기별 점검표를 만들 수 있습니다. 어떤 클라이언트를 사용하든 복구 가능한 설정을 먼저 보존하고 업데이트를 진행하세요. 네트워크 사용 가능 여부와 소프트웨어 변경은 따로 확인해야 합니다.

이 단계를 마치면 간단한 복구 목록을 준비하세요. 시스템 프록시 해제, TUN 끄기, 기존 네트워크 확인, 클라이언트 실행, 기준 노드 로드, 라우팅 복구 순서입니다. 실제 장애가 생겼을 때 목록을 따르면 흩어진 안내를 급히 찾는 것보다 일관된 판단을 유지하기 쉽고, 일부 문제를 시스템 전체로 확대하는 일을 막을 수 있습니다.

9단계: 고급 설정과 학습 경로

생성된 설정 읽기부터 시작하기

고급 설정의 첫걸음은 전체 설정 파일을 직접 작성하는 것이 아니라 클라이언트가 실제로 생성한 내용을 읽는 것입니다. 현재 설정을 확인하는 메뉴를 찾아 인바운드, 아웃바운드, 라우팅, DNS, 로그 모듈을 구분하고 각 항목이 인터페이스 설정과 어떻게 연결되는지 살펴보세요. 생성 파일은 실행하거나 노드를 바꿀 때 다시 만들어질 수 있어 직접 수정해도 유지되지 않을 수 있습니다. 클라이언트가 지원하는 사용자 설정 방식과 병합 규칙을 먼저 이해한 뒤 인터페이스에서 관리할 항목을 정하세요.

아웃바운드 태그 하나를 추적하는 연습을 하세요. 먼저 프록시 아웃바운드와 직접 연결 아웃바운드의 실제 태그를 찾고, 규칙에서 참조하는 태그와 일치하는지 확인한 뒤 일치하는 규칙이 없을 때의 기본 동작을 살펴보세요. 태그는 설정 내부에서 사용하는 참조값이지 고정된 한국어 이름이나 노드 메모가 아닙니다. 다른 자료의 규칙을 복사하기 전에 먼저 이 대응 관계를 확인해야 합니다. 필드는 올바르지만 태그가 존재하지 않으면 시작 단계에서 실패하거나 예상한 출구를 선택하지 못할 수 있습니다.

각 실험의 예상 결과를 정하기

실험마다 목표, 변경 사항, 되돌리는 방법을 기록하세요. 예를 들어 특정 도메인을 직접 연결하려는 경우 해당 도메인이 지정한 규칙에 일치하고 다른 대상의 경로는 그대로여야 합니다. 특정 앱에 TUN을 적용한다면 그 앱의 새 트래픽이 코어에 들어오면서 로컬 리소스는 계속 접속할 수 있어야 합니다. 무엇을 관찰해야 하는지 알 수 있도록 예상 결과를 구체적으로 적으세요. '더 빨라진 것 같다'는 느낌만으로 복잡한 설정을 판단하면 캐시, 노드, 네트워크 변동의 영향을 구분할 수 없습니다.

실험 전용 설정 복사본을 만들어 일상적인 작업 환경에 매개변수를 계속 덧붙이지 마세요. 규칙 하나를 먼저 확인한 다음 여러 규칙을 조합하세요. 기본 조회 방식을 이해한 뒤 더 복잡한 도메인 처리 방법을 살펴보세요. 새로운 문제가 발생하면 패치를 계속 추가하기보다 가장 최근의 정상 상태로 돌아가 변경 사항을 비교하세요. 실험 기록은 하루가 지난 뒤 기기를 다시 켜도 각 사용자 설정 필드의 용도를 이해할 수 있을 만큼 명확해야 합니다.

문제 유형에 맞춰 다음 학습 경로 선택하기

가져오기나 핸드셰이크 문제가 자주 발생한다면 프로토콜 경로를 학습하세요. 서버 주소, 인증, 전송, 보안 계층, 서버 이름 순으로 살펴보고 어떤 매개변수를 원격 서버에서 받아야 하는지 이해합니다. 프로토콜 이름을 성능 순위처럼 여기거나 한 번의 테스트로 특정 조합이 항상 더 낫다고 판단하지 마세요. 프로토콜 선택은 우선 서버 지원 여부와 실제 네트워크 환경에 따라 달라지며, 클라이언트는 호환되는 범위에서 기존 설정을 실행할 뿐입니다.

LAN 리소스 접속, 서비스별 트래픽 경로 구분, 복잡한 앱 처리가 필요하다면 라우팅 경로를 학습하세요. 먼저 규칙 순서와 도메인 규칙과 주소 규칙의 차이를 익힌 다음 분류 데이터와 기본 아웃바운드를 살펴봅니다. DNS 경로에서는 조회를 누가 시작하고 어떤 출구를 거치며 결과가 규칙 매칭에 어떻게 사용되는지 추적합니다. 두 경로는 서로 확인해야 하지만 처음 설정을 바꿀 때는 실험을 분리하세요. 한 번의 접속 결과 변화에 조회 결과와 규칙 적용이 동시에 영향을 줄 수 있습니다.

TUN을 계속 사용해야 한다면 시스템 네트워크 경로를 학습하세요. 인터페이스, 라우팅 테이블, 주소 범위, 권한 경계를 살펴보고 네트워크 전환, 가상 머신, 다른 터널이 충돌을 일으키는 이유를 이해해야 합니다. 기능을 늘리려고 LAN 리스닝을 무작정 허용하거나 접근 범위를 모른 채 로컬 포트를 공유하지 마세요. 다른 기기에 서비스를 공개하면 인증, 기기 신뢰도, 방화벽까지 별도로 검토해야 하며 더 이상 로컬 프록시 설정만의 문제가 아닙니다.

유지 관리 가능한 설정 만들기

최종 설정을 정리할 때는 더 이상 필요 없는 임시 예외를 삭제하고 유지할 규칙에는 간단한 이유를 기록하세요. 필요한 코어 기능과 데이터 파일도 명확히 적어야 합니다. 규칙이 많다고 범위가 더 완전해지는 것은 아닙니다. 서로 겹치면 오히려 읽기 어려워집니다. 설명할 수 없는 매개변수 덩어리를 저장하지 마세요. 꼭 유지해야 한다면 먼저 실험 복사본에서 어떤 문제를 해결하는지 확인한 뒤 장기 설정에 반영하고 재시작 후에도 적용되는지 점검하세요.

정해 둔 순서로 참고 자료를 확인하세요. 사용 방법을 잊었다면 빠른 시작 가이드를, 용어가 궁금하다면 핵심 개념 빠른 참조를, 구체적인 오류가 발생했다면 기술 노트를 확인하세요. 플랫폼을 바꾸려면 클라이언트 다운로드 페이지로 이동하면 됩니다. 이 가이드는 각각의 내용을 연결하며 모든 기능을 한꺼번에 활성화할 필요는 없습니다. 설명과 검증, 복구가 가능한 작업 방식을 유지하고 실제 문제에 맞춰 조금씩 확장하는 것이 이 학습 경로의 목표입니다.