v2rayN 설정 및 유지 관리 가이드

핵심 개념: 클라이언트, 코어, 설정 구분하기

요청이 이동하는 경로부터 살펴보기

연결 과정을 이해하려면 몇 단계로 나누어 보세요. 앱에서 요청을 보내면 로컬 프록시로 들어오고, 코어가 규칙을 읽어 출구를 선택한 뒤 원격 서버가 목적지에 접속합니다. 클라이언트는 그래픽 인터페이스를 제공하고 구독을 저장하며 실행 설정을 만듭니다. 실제 연결 처리는 코어가 담당합니다. 창이 열린 것은 인터페이스 프로그램이 실행됐다는 뜻일 뿐, 코어가 정상 작동하거나 원격 서버를 사용할 수 있다는 뜻은 아닙니다. 문제가 생기면 여러 설정을 한꺼번에 바꾸기보다 이 경로를 따라 단계별로 확인하는 편이 원인을 찾기 쉽습니다.

설정은 두 종류로 나눠 보세요. 첫 번째는 서버 주소, 포트, 인증 정보, 전송 방식, 보안 설정 등 원격 연결에 관한 항목입니다. 두 번째는 수신 주소, 시스템 프록시, 라우팅, 도메인 이름 확인 등 이 기기에서 처리하는 방식입니다. 구독은 대개 첫 번째 항목을 제공하고, 로컬 설정은 클라이언트에서 관리합니다. 구독을 업데이트해 노드가 바뀌어도 시스템 프록시나 라우팅 설정까지 함께 바뀌는 것은 아닙니다. 반대로 로컬 프록시가 정상이어도 잘못된 원격 인증 정보가 고쳐지지는 않습니다.

코어 계열과 프로토콜 필드 알아보기

Project V는 관련 프록시 기술의 생태계 배경이며, V2Fly와 Xray는 서로 다른 코어 개발 계열입니다. v2rayN은 데스크톱 그래픽 클라이언트로, 사용할 수 있는 기능은 선택한 코어와 클라이언트의 지원 여부에 따라 달라집니다. v2rayNG는 Xray 코어를, v2flyNG는 V2Fly 코어를 사용합니다. 클라이언트 이름, 코어 이름, 프로토콜 이름을 같은 개념으로 혼동하지 마세요. 프로토콜 필드가 작동하려면 클라이언트에서 설정을 표현할 수 있고, 코어가 이를 해석하며, 원격 서버에도 같은 설정이 적용되어야 합니다.

VMess, VLESS, Trojan은 널리 쓰이는 연결 프로토콜 이름입니다. 전송 방식은 연결을 전달하는 방법을 정하고, TLS나 REALITY 같은 설정은 연결의 보안 협상과 관련됩니다. REALITY는 독립된 구독 형식이 아니며, 스위치를 켠다고 아무 노드에서나 해당 기능을 쓸 수 있는 것도 아닙니다. 설정을 가져온 뒤에는 서비스 제공자가 지정한 조합을 그대로 유지하세요. 특히 서버 이름, 지문, 공개 키, 전송 경로를 이름만 보고 추측해 입력하지 마세요. 항목 하나만 맞지 않아도 단순한 주소 연결 실패가 아니라 핸드셰이크 오류가 발생할 수 있습니다.

관찰되는 증상으로 문제 단계 나누기

도메인 이름 확인, 연결 수립, 앱 응답을 서로 다른 단계로 구분하세요. 도메인 확인에 실패하면 요청이 원격 서버에 도달하지 않았을 수 있습니다. 연결 시간이 초과되면 로컬 네트워크, 목적지 주소, 중간 경로를 점검하세요. 핸드셰이크 오류라면 프로토콜 매개변수와 보안 설정을 살펴봐야 합니다. 클라이언트 연결 테스트는 테스트 방식이 확인하는 구간만 보여 줄 뿐, 실제 앱에서의 동작을 대신 확인해 주지는 않습니다. 웹페이지 하나가 열린다고 해서 다른 앱이나 프로토콜, 라우팅까지 모두 정상이라고 단정할 수 없습니다.

최소 설정 기준을 마련하세요. 정상 작동이 확인된 설정 하나를 보관하고, 먼저 시스템 프록시로 프록시를 지원하는 앱을 테스트한 다음 분할 라우팅과 가상 네트워크 인터페이스를 단계적으로 추가합니다. 한 번에 변수 하나만 바꾸고 변경 전후의 증상을 기록하세요. 노드 변경, DNS 규칙 수정, 가상 네트워크 인터페이스 사용을 동시에 하면 연결이 복구되더라도 어떤 변경이 효과가 있었는지 알기 어렵습니다. 유지 관리에는 우연히 한 번 성공한 결과가 아니라 반복해서 재현할 수 있는 결과가 필요합니다.

클라이언트 선택: 운영체제, 아키텍처, 코어 요구 사항 확인

데스크톱에서는 v2rayN 우선 고려

먼저 클라이언트 다운로드 페이지를 열고 현재 운영체제에 맞는 항목을 선택한 다음, 프로세서 아키텍처와 설치 파일 유형을 확인하세요. 데스크톱에서는 Windows, macOS, Linux를 지원하는 v2rayN을 우선 추천합니다. 파일 이름에 비슷한 글자가 들어 있다는 이유만으로 설치하거나, 한 플랫폼에서의 사용 경험을 다른 플랫폼에 그대로 적용하지 마세요. 인터페이스 프레임워크, 권한 체계, 배포 패키지 형식이 다를 수 있습니다. 올바른 설치 항목을 선택하면 실행 실패, 아키텍처 비호환, 설치 방식 불일치 문제를 줄일 수 있습니다.

Windows 다운로드 페이지에서는 데스크톱 버전과 클래식 WPF 버전을 제공합니다. 데스크톱 버전은 새 세대 크로스 플랫폼 인터페이스를, WPF 버전은 Windows 데스크톱 인터페이스 프레임워크를 사용합니다. 사용 습관과 현재 시스템 환경을 고려해 선택하되, ‘새 인터페이스’가 모든 기능의 완전한 일치를 의미한다고 생각하지 마세요. 메뉴 위치와 설정 구성, 일부 조작 방식이 다를 수 있습니다. 가이드를 볼 때는 같은 픽셀 위치를 기계적으로 찾기보다 설정의 의미를 확인하세요. 두 버전의 자세한 차이는 데스크톱 버전과 WPF 버전 비교를 참고하세요.

모바일 기기는 아키텍처와 필요한 기능부터 확인

Android에서는 Xray 코어를 사용하는 v2rayNG를 우선 고려하세요. V2Fly 코어가 필요하고 설정 호환성까지 확인했다면 v2flyNG를 선택할 수 있습니다. 두 앱 모두 구독과 연결을 관리하지만, 코어별 설정 필드를 서로 바꿔 쓸 수 있는 것은 아닙니다. 설정을 가져오지 못하면 먼저 구독이 해당 클라이언트와 코어에서 사용할 수 있는지 확인한 뒤 앱을 바꿀지 판단하세요. 클라이언트를 바꾸는 것만으로 만료된 구독, 잘못된 비밀번호, 연결할 수 없는 원격 주소가 해결되지는 않습니다.

프로세서 아키텍처에 따라 설치 파일의 실행 가능 여부가 달라집니다. 최신 Android 휴대전화는 대체로 arm64를 사용할 수 있지만, 실제 기기와 시스템 지원 여부를 확인하세요. 확실하지 않다면 파일 크기가 커질 수 있지만 범용 버전을 고려할 수 있습니다. macOS에서는 ‘이 Mac에 관하여’에서 칩 종류를 확인하고 Apple Silicon 또는 Intel용 항목을 선택하세요. Linux에서는 아키텍처뿐 아니라 배포판의 패키지 체계도 확인해야 합니다. 해당하는 deb 또는 rpm 패키지를 선택하세요. 패키지 형식이 프록시 기능의 차이를 뜻하는 것은 아닙니다.

사용 환경도 선택 기준에 포함하기

클라이언트를 고른 뒤 실제로 프록시를 사용해야 하는 앱을 정리하세요. 브라우저만 연결하면 된다면 우선 시스템 프록시를 사용할 수 있습니다. 시스템 프록시를 읽지 않는 앱까지 처리해야 한다면 가상 네트워크 인터페이스 방식을 검토하세요. 회사 기기나 관리 대상 기기, 다른 네트워크 도구를 함께 실행해야 하는 환경에서는 드라이버, 라우팅, 권한 변경이 제한될 수 있습니다. 먼저 기기 관리 정책을 확인하고, 더 많은 트래픽을 제어하는 것을 기본 목표로 삼지 마세요. 기능이 많아질수록 영향을 받는 시스템 영역도 늘어나므로 문제 해결에 필요한 정보도 더 많아집니다.

마지막으로 설정 이전 범위를 확인하세요. 노드 링크와 QR 코드에는 보통 원격 연결 매개변수가 담기지만, 로컬 라우팅, DNS 설정, 단축키, 인터페이스 기본 설정까지 포함된다고 보장할 수는 없습니다. 플랫폼을 바꿔 설정을 옮길 때는 원격 설정을 먼저 가져온 다음 새 기기에 맞춰 로컬 설정을 다시 구성하세요. 운영체제, 아키텍처, 클라이언트 버전, 사용 코어, 필요한 권한을 기록해 두면 재설치하거나 기기를 바꿀 때 이전 설치 파일이 다시 작동할지에 의존하지 않고 선택할 수 있습니다.

설치 준비: 실행과 종료가 모두 가능한 환경 만들기

설치 전에 기존 네트워크 설정 정리하기

다운로드 전에 운영체제 버전과 아키텍처를 확인하고 저장 공간이 충분한지 살펴보세요. 기기에 다른 프록시 설정이 있다면 시스템 프록시 주소와 포트, 가상 네트워크 인터페이스 상태를 기록한 뒤 관련 프로그램을 종료해 여러 도구가 동시에 네트워크를 제어하지 않도록 하세요. 계속 사용하는 설정 폴더를 바로 삭제하지 마세요. 설치 단계의 목표는 클라이언트와 코어가 실행되고 로그를 열 수 있게 하며, 종료 후 시스템 네트워크가 복구되는지 확인하는 것입니다. 이 단계에서 복잡한 분할 라우팅이나 자동 시작 작업을 추가할 필요는 없습니다.

Windows에서는 다운로드 페이지에서 해당 설치 항목을 선택해 설치 마법사의 안내를 따르세요. 압축 해제 후 실행하는 배포 형태라면 먼저 지정된 폴더에 압축을 완전히 푸세요. 압축 파일 미리 보기에서 바로 실행하지 마세요. 폴더를 한곳에 고정하면 업데이트, 로그 확인, 설정 저장이 편리합니다. 자주 정리되는 임시 폴더에 작업 디렉터리를 두지 말고 실행 중인 파일을 직접 옮기지도 마세요. 실행 환경이 없다는 안내가 나타나면 해당 배포 버전의 설명에 따라 종속성을 설치하세요. 출처가 불분명한 곳에서 누락된 구성 요소를 따로 찾지 마세요.

데스크톱과 모바일 권한을 각각 확인

macOS에서는 칩에 맞는 설치 파일을 열고 앱을 안정적으로 사용할 수 있는 응용 프로그램 폴더에 넣은 다음 실행하세요. 시스템 보안 경고가 나타나면 출처와 현재 시스템의 허용 절차를 확인한 뒤 시스템 설정에서 실행을 허용하세요. 앱 하나를 실행하려고 시스템 보호 기능 전체를 끄지 마세요. 클라이언트는 열리지만 핵심 기능이 작동하지 않는다면 앱 실행 권한, 네트워크 권한, 이후의 가상 네트워크 인터페이스 권한을 따로 확인하세요. 창이 열렸다고 필요한 권한이 모두 부여된 것은 아닙니다.

Linux에서는 배포판의 소프트웨어 설치 도구나 패키지 관리 방식으로 적절한 패키지를 설치하세요. 먼저 종속성 안내를 확인하고 데스크톱 환경에서 그래픽 인터페이스가 실행되는지 살펴보세요. 일반 모드는 작동하지만 가상 네트워크 인터페이스 모드가 작동하지 않는다면 같은 패키지를 반복해서 설치하기보다 권한과 서비스 요구 사항을 확인하세요. 로그는 클라이언트 인터페이스, 사용자 디렉터리 또는 시스템 서비스 관리 도구에서 확인할 수 있으며 위치는 설치 형태에 따라 달라집니다. 실제 로그 위치를 기록해 두면 이후 업데이트와 문제 해결에 도움이 됩니다.

Android에서는 시스템 안내에 따라 현재 다운로드 출처의 앱 설치를 허용하고, 설치 후 필요하다면 해당 출처 권한을 해제하세요. 처음 연결할 때 시스템에서 VPN 연결 생성을 요청하면 안내를 읽고 필요한 경우 승인합니다. 이 권한은 앱이 시스템 네트워크 인터페이스를 통해 트래픽을 처리하도록 허용하는 것이지, 원격 설정이 정상임을 확인해 주는 것은 아닙니다. 조직에서 관리하는 휴대전화는 설치 출처나 VPN 권한이 정책으로 제한될 수 있습니다. 기기 관리 정책을 따르고 반복 설치로 제한을 우회하지 마세요.

실행과 종료를 한 번씩 확인

처음 실행하면 로그, 설정, 종료 메뉴를 찾아 두세요. 데스크톱 창을 닫아도 프로그램이 알림 영역에서 계속 실행될 수 있으므로, 완전히 중지하려면 명확한 종료 명령을 사용하세요. 종료 전후에 시스템 프록시가 복구되는지, 백그라운드 연결 프로세스가 남아 있는지 확인하세요. ‘창 닫기’와 ‘프록시 서비스 종료’를 같은 동작으로 생각하지 마세요. Android에서는 화면을 밀어 닫는 동작과 VPN 서비스 중지를 구분하고, 앱과 시스템의 네트워크 알림을 함께 확인하세요.

이어서 로컬 수신 설정을 확인하세요. 처음에는 기본 포트와 로컬 기기에서만 접근할 수 있는 범위를 유지하고, LAN 연결은 열지 마세요. 포트가 이미 사용 중이라면 이전 인스턴스나 다른 프로그램이 사용하고 있는지 확인한 뒤 충돌 프로그램을 종료할지 포트를 바꿀지 결정하세요. 포트를 변경하면 해당 포트를 명시적으로 입력한 앱의 설정도 함께 바꿔야 합니다. 클라이언트만 바꾸고 브라우저나 다른 앱의 프록시 주소를 수정하지 않으면 ‘코어는 실행됐지만 요청이 들어오지 않는’ 문제가 생길 수 있습니다.

구독 가져오기: 주소 저장부터 설정 확인까지

구독 주소는 접근 정보로 취급해 보관

구독 주소에는 계정이나 접근 권한을 식별할 수 있는 정보가 포함되는 경우가 많으므로 민감한 데이터로 다루세요. 전체 주소를 공개 화면 캡처, 온라인 변환 페이지, 공개 문의에 올리지 마세요. 먼저 주소 출처와 지원 클라이언트, 유효 기간을 확인한 뒤 로컬 기기에 복사하세요. 클라이언트는 주소가 반환하는 설정을 읽을 뿐 원격 서비스를 제공하지 않습니다. 앱만 설치되어 있고 유효한 설정이 없다면 노드 목록이 비어 있는 것은 정상입니다. 시스템 프록시를 바꿔 노드를 ‘만들’ 필요는 없습니다.

v2rayN에서 ‘구독 그룹’ 메뉴의 ‘구독 그룹 설정’을 열고 알아보기 쉬운 그룹 이름을 추가한 뒤 구독 주소를 붙여 넣고 저장하세요. 그룹 이름은 로컬 관리용이며 원격 연결에 영향을 주지 않습니다. 저장한 다음 기본 화면으로 돌아가 ‘프록시를 사용하지 않고 모든 구독 업데이트’를 선택하거나 현재 화면에 해당하는 업데이트 기능을 사용하세요. 주소 저장과 내용 가져오기는 별개의 작업입니다. 저장은 주소를 기록할 뿐이며 업데이트를 해야 내용을 내려받아 해석합니다. 완료 후 해당 그룹에 설정이 표시되는지 확인하세요.

사용 가능한 네트워크에 맞춰 업데이트 방법 선택

처음 설정하는 중이고 사용할 수 있는 프록시가 없다면 프록시 없이 업데이트해 보세요. 구독 서비스에 접속하려면 기존 프록시 경로가 꼭 필요하다고 확인된 경우에는 먼저 검증된 다른 연결을 만든 뒤 프록시를 통한 업데이트를 사용하세요. 같은 작동하지 않는 설정에서 업데이트 경로만 반복해서 바꿔도 구독이 복구되지는 않습니다. 업데이트에 실패하면 로컬 네트워크, 주소 전체가 정확한지, 계정이 유효한지, 서비스가 설정 대신 로그인 페이지나 오류 페이지, 접근 제한 안내를 반환하지는 않는지 차례로 확인하세요.

v2rayNG에서는 메뉴에서 ‘구독 그룹 설정’을 열고 이름과 주소를 추가한 뒤 저장하세요. 설정 목록으로 돌아가 ‘구독 업데이트’를 실행합니다. 화면에 전체 업데이트와 현재 그룹 업데이트가 따로 표시될 수 있으므로 선택된 그룹을 확인하세요. v2flyNG는 메뉴 구성이 다를 수 있지만 주소 추가, 그룹 저장, 업데이트 실행, 설정 확인 순서로 진행하면 됩니다. 가져온 내용이 없다면 같은 그룹을 바로 반복해서 추가하지 말고 업데이트 결과와 로그에 형식 해석 오류가 있는지 먼저 확인하세요.

구독 주소, 반환 내용, 공유 링크의 차이

구독 주소는 설정을 가져오는 경로입니다. 주소에서 반환되는 내용은 여러 링크를 인코딩한 것일 수도 있고 클라이언트가 지원하는 다른 구독 형식일 수도 있습니다. 단일 공유 링크는 원격 설정 하나를 설명합니다. 이 세 가지를 구분하면 구독 주소를 단일 노드로 가져오거나, 정기 업데이트가 필요한 주소 입력란에 단일 노드 링크를 넣는 실수를 피할 수 있습니다. Base64는 내용의 인코딩 방식일 뿐 연결 프로토콜이 아니며, 인증 정보가 암호화되어 보호된다는 뜻도 아닙니다. 공유 QR 코드에도 전체 연결 인증 정보가 담길 수 있습니다.

업데이트가 성공하면 설정 하나를 선택해 활성 항목으로 지정하고 프로토콜, 주소, 보안 필드가 모두 채워졌는지 확인하세요. 목록을 정리하려고 구독에서 관리하는 연결 매개변수를 임의로 수정하지 마세요. 다음 업데이트에서 변경 내용이 덮어써질 수 있습니다. 수동 설정을 유지해야 한다면 별도의 로컬 그룹에 복사하고 변경 목적을 기록하세요. 구독 설정이 삭제되거나 교체됐다면 서버 측 목록이 변경됐을 수도 있으므로 클라이언트가 데이터를 잃었다고 단정하지 마세요.

마지막으로 목록에 항목이 표시되는지만 보지 말고 실제 요청을 보내 확인하세요. 활성 설정을 확인하고 코어를 실행한 뒤, 뒤에서 설명하는 시스템 프록시를 켜고 프록시 설정의 영향을 받는 것이 확인된 앱으로 정상 작동하는 페이지에 접속해 보세요. 실패하면 구독 가져오기, 설정 해석, 실제 연결 중 어느 단계에서 발생했는지 기록하세요. 여러 기기에서 같은 구독을 쓴다면 허용된 연결 수와 사용 범위도 확인하세요. 구독을 가져올 수 있다고 해서 여러 기기의 동시 연결까지 허용되는 것은 아닙니다.

프록시 모드: 진입 경로부터 확인하고 제어 범위 넓히기

시스템 프록시로 첫 연결 확인하기

프록시 모드는 앱의 트래픽이 코어에 들어오는 방식을 정합니다. 데스크톱의 시스템 프록시는 시스템에 로컬 프록시 주소를 등록하지만, 해당 설정을 읽는 프로그램만 이를 사용합니다. 일부 프로그램은 자체 네트워크 설정을 사용하고, 시스템 프록시를 완전히 무시하는 프로그램도 있습니다. 따라서 시스템 프록시를 켠 뒤 브라우저는 접속되지만 독립 앱은 접속되지 않는다고 해서 노드에 문제가 있다고 단정할 수 없습니다. 먼저 앱이 어떤 프록시 경로를 사용하는지 확인하고, 앱에 주소를 직접 입력할지 가상 네트워크 인터페이스로 처리할지 결정하세요.

v2rayN에서는 먼저 활성 설정과 코어 실행 상태를 확인한 뒤 ‘시스템 프록시’ 메뉴에서 ‘시스템 프록시 자동 설정’을 선택하세요. 그런 다음 시스템 프록시를 사용하는 앱에서 요청을 테스트합니다. ‘자동 설정’은 노드를 자동으로 선택하거나 모든 앱의 프록시와 라우팅을 최적화한다는 뜻이 아닙니다. 주로 시스템에 프록시를 등록하는 기능입니다. 설정에 실패하면 시스템에 등록된 주소와 클라이언트가 실제로 수신하는 주소가 같은지, 특히 포트를 직접 변경한 적이 있는지 확인하세요.

설정 초기화와 현재 상태 유지 구분하기

‘시스템 프록시 지우기’는 해당 작업에서 관리하는 시스템 프록시 설정을 삭제합니다. ‘시스템 프록시 변경 안 함’은 클라이언트가 현재 시스템 상태를 직접 바꾸지 않는다는 뜻입니다. 후자는 프록시를 끄는 것과 다릅니다. 시스템에 원래 등록된 설정이 그대로 남을 수 있습니다. 종료 전후 네트워크에 문제가 생기면 시스템 프록시가 중지된 로컬 포트를 계속 가리키는지 확인하세요. 직접 연결로 복구하려면 설정을 명시적으로 지우거나 되돌려야 합니다. 클라이언트 창만 닫아서는 해결되지 않습니다.

개별 앱에 프록시를 설정하려면 클라이언트에서 실제로 제공하는 진입 방식과 수신 포트를 확인한 뒤 앱에서 일치하는 HTTP 또는 SOCKS 설정을 선택하세요. 다른 가이드에 나온 포트 번호를 그대로 입력하거나 원격 서버 주소를 로컬 프록시 주소로 사용하지 마세요. 도메인 이름 확인은 앱에 따라 로컬에서 처리하거나 도메인을 프록시 측으로 전달할 수 있습니다. 이는 이후의 분할 라우팅과 DNS 처리에 영향을 주므로 앱 자체 설정도 함께 확인해야 합니다.

Android의 VPN 서비스와 앱별 적용 범위 확인

v2rayNG는 Android의 VPN 인터페이스를 통해 로컬 트래픽 진입 경로를 만듭니다. 처음 연결할 때 시스템 권한을 승인해야 하며, 연결 후에는 클라이언트의 라우팅 및 관련 설정이 트래픽의 경로를 결정합니다. 시스템에 VPN 표시가 나타나는 것은 인터페이스가 만들어졌다는 뜻일 뿐, 모든 목적지로 가는 트래픽이 원격 출구를 거친다는 뜻은 아닙니다. 앱별 설정을 사용하면 범위에 포함되지 않은 앱은 이 경로를 사용하지 않을 수 있습니다. 확인할 때는 앱 적용 범위, 라우팅 규칙, 활성 설정을 함께 살펴보세요.

여러 진입 경로가 동시에 작동하지 않도록 하세요. 가상 네트워크 인터페이스를 테스트할 때는 먼저 시스템 프록시를 지워 동일한 요청이 로컬 진입 경로를 중복으로 거칠 가능성을 줄일 수 있습니다. 앱 내 프록시를 쓴다면 나중에 되돌릴 수 있도록 직접 입력한 설정도 기록하세요. ‘전역’이라는 표현만으로 문제를 진단하지 마세요. 모든 앱의 트래픽을 제어한다는 의미일 수도 있고, 라우팅에서 모든 트래픽을 프록시로 보낸다는 의미일 수도 있습니다. 두 표현은 서로 다른 설정 단계입니다. 문제를 설명할 때 진입 방식과 라우팅 모드를 각각 명시하세요.

이 장을 마치면 세 가지 질문에 답할 수 있어야 합니다. 어떤 앱이 요청을 보내는지, 요청이 어떤 로컬 진입 경로로 들어오는지, 코어가 요청을 확인했는지입니다. 로그에 관련 활동이 전혀 없다면 진입 경로와 앱 설정부터 확인하세요. 연결 기록이 있다면 원격 서버와 라우팅을 점검하세요. 문제 범위를 단계별로 좁히면 모든 연결 문제를 구독이나 노드 탓으로 돌리는 일을 막고, 이후 가상 네트워크 인터페이스 설정과 비교할 기준도 마련할 수 있습니다.

라우팅 및 DNS: 규칙 조건과 이름 확인 경로 일치시키기

기본 규칙부터 분할 라우팅 기준 마련

라우팅은 코어에 들어온 트래픽이 어디로 나갈지 결정합니다. 시스템 프록시와는 별도의 설정입니다. 시스템 프록시는 트래픽이 들어올지를 정하고, 라우팅은 들어온 트래픽을 직접 연결, 프록시 또는 정의된 다른 출구 중 어디로 보낼지 정합니다. v2rayN에서는 먼저 ‘라우팅 설정’의 ‘중국 본토 우회’ 같은 사전 설정으로 시작하고, 적용 대상과 의미를 이해한 뒤 사용하세요. 규칙은 도메인과 주소 데이터에 따라 달라지며 업데이트 상태, DNS 처리 위치, 연결 대상의 변경에 영향을 받을 수 있습니다. 사전 설정 이름만 보고 모든 사이트에서 항상 똑같이 동작한다고 단정하지 마세요.

대부분의 규칙 시스템은 위에서부터 순서대로 일치 여부를 확인하므로 구체적인 예외는 포괄적인 규칙보다 앞에 두는 편이 좋습니다. 모든 트래픽과 일치하는 규칙이 앞에 있으면 뒤쪽 도메인 규칙이 적용되지 않을 수 있습니다. 규칙을 추가할 때는 ‘사용’으로 표시됐는지만 확인하지 말고 조건, 출구, 규칙 순서를 함께 확인하세요. 클라이언트마다 출구 태그가 다를 수 있으므로 설정 조각을 복사하기 전에 실제 태그를 점검하세요. 존재하지 않는 출구를 지정하면 설정을 불러오지 못하거나 요청이 예상대로 처리되지 않을 수 있습니다.

도메인 규칙, 주소 규칙, DNS 처리 방식 구분

도메인 규칙은 코어가 도메인 정보를 얻을 수 있어야 적용됩니다. 주소 규칙은 연결에서 사용하는 목적지 주소를 대상으로 합니다. 앱이 로컬에서 먼저 DNS 조회를 하고 주소만 전달하면 도메인 규칙의 적용 조건이 달라질 수 있습니다. 트래픽 스니핑은 일부 상황에서 식별 정보를 보완하지만 모든 요청의 실제 도메인을 복원한다고 보장할 수 없으며, 올바른 DNS 설정을 대신하는 만능 기능도 아닙니다. 분할 라우팅 결과가 예상과 다르면 로그에서 코어가 실제로 어떤 정보를 받았는지 확인한 뒤 규칙이 적용되지 않은 이유를 살펴보세요.

아래 예시는 Xray 라우팅 필드의 규칙 구조를 이해하기 위한 것으로, 단독 실행 가능한 완전한 설정이 아닙니다. 예시 도메인과 하위 도메인을 이미 정의된 직접 연결 출구로 보내도록 구성합니다. 전체 설정에 direct라는 출구가 정의되어 있는지 먼저 확인해야 합니다. 예시 도메인은 문법 설명용이며 실제 서비스와는 관계가 없습니다. 그래픽 클라이언트에서는 자동 생성된 전체 파일을 직접 덮어쓰기보다 라우팅 편집기에서 같은 규칙을 설정하세요.

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": ["domain:example.com"],
        "outboundTag": "direct"
      }
    ]
  }
}

AsIs는 라우팅 단계에서 현재 제공된 정보로 규칙을 적용한다는 뜻이지, 시스템 전체에서 도메인 조회를 중단한다는 뜻은 아닙니다. 실제 연결을 수립할 때는 필요한 위치에서 여전히 DNS 조회가 수행될 수 있습니다. 다른 DNS 처리 방식도 사용 중인 코어 문서를 참고해 이해하고, 이름만 보고 추가 조회 여부를 추측하지 마세요. DNS와 라우팅은 서로 영향을 줍니다. 한쪽을 바꾼 뒤에는 편집기에 표시된 텍스트만 보지 말고 최종 목적지 주소와 출구를 다시 확인하세요.

DNS 확인 경로를 별도로 점검

DNS 구성을 설계할 때는 누가 조회하는지, 조회가 어디로 전달되는지, 조회 자체가 어떤 출구를 사용하는지부터 정리하세요. 직접 연결해야 하는 도메인은 보통 로컬 경로에 알맞은 결과를 반환하는 DNS 방식을 사용합니다. 프록시를 통해 접속할 도메인은 예상한 경로로 조회되는지 확인하세요. 암호화 DNS는 조회 전송을 보호하는 방식만 바꾸며 출구 선택 오류를 자동으로 바로잡지는 않습니다. 원격 DNS 서버 접속에 프록시가 필요하다면 같은 경로로 프록시 서버 자체를 조회해야 하는 순환 의존성이 생기지 않도록 하세요.

브라우저의 보안 DNS, 운영체제 캐시, 앱 자체 캐시가 관찰 결과에 영향을 줄 수 있습니다. 규칙을 수정한 뒤에는 기존 연결을 닫고 필요하다면 관련 캐시를 새로 고친 다음 같은 목적지를 테스트하세요. 기존 연결이 이전 경로를 계속 사용한다고 새 규칙이 작동하지 않는다고 판단하지 마세요. 특정 앱 하나에서만 문제가 생기면 해당 앱이 클라이언트의 DNS 설정을 우회하는지 확인하세요. 자세한 DNS 분할 설정은 DNS 설정 가이드를 참고하세요. 문제를 해결할 때는 DNS 결과와 라우팅 규칙 적용 여부를 함께 기록하세요.

TUN 사용: 권한, 라우팅, 충돌 범위 확인

가상 네트워크 인터페이스가 필요한지 먼저 확인

TUN은 가상 네트워크 인터페이스를 통해 시스템 라우팅이 전달하는 트래픽을 받으므로 시스템 프록시를 읽지 않는 일부 프로그램도 처리할 수 있습니다. 진입 경로와 시스템 네트워크 경로를 바꾸는 기능이지, 유효하지 않은 원격 설정을 고치거나 모든 트래픽을 프록시 출구로 보내는 기능은 아닙니다. 가상 네트워크 인터페이스로 들어온 트래픽도 라우팅 규칙, 프로토콜 지원, 제외 규칙에 따라 처리됩니다. 시스템 프록시가 정상 작동하고 제어 범위가 부족한 경우에만 이 기능을 추가하면 문제 해결 변수를 크게 줄일 수 있습니다.

사용 전에 현재 설정을 저장하고 시스템 네트워크 설정, 클라이언트 로그, 비활성화 메뉴를 찾을 수 있는지 확인하세요. 데스크톱 플랫폼은 관리자 권한, 보조 서비스, 네트워크 구성 요소가 필요할 수 있으며 구체적인 요구 사항은 운영체제와 배포 형태에 따라 다릅니다. 클라이언트 안내에 따라 필요한 절차를 진행하되 일상적인 실행 환경을 계속 최고 권한으로 실행하지 마세요. 기기 관리 정책에서 가상 네트워크 인터페이스나 라우팅 변경을 금지한다면 허용되는 진입 방식을 사용하세요. 권한을 반복해서 요청해 정책 제한을 해결할 수는 없습니다.

정해진 순서대로 첫 사용 진행

먼저 일반 프록시로 연결을 확인한 활성 설정을 선택한 다음 네트워크 라우팅을 변경하는 다른 도구를 종료하세요. 시스템 프록시를 잠시 지우고 하나의 명확한 진입 경로만 남긴 뒤, v2rayN에서 ‘Tun 사용’ 또는 현재 화면에 해당하는 스위치를 찾으세요. 안내에 따라 권한을 허용하고 로그에서 인터페이스 생성과 라우팅 로드가 성공했는지 확인하세요. 권한 부족, 인터페이스 생성 실패, 주소 충돌이 발생하면 구독을 바꾸거나 여러 원격 설정을 한꺼번에 전환하지 말고 표시된 시작 오류부터 해결하세요.

인터페이스가 만들어지면 일반 웹페이지, 원래 시스템 프록시를 사용하지 않던 앱, LAN 기기, 자주 쓰는 업무 서비스를 차례대로 확인하세요. 외부 웹페이지 하나만 테스트하면 로컬 프린터, 파일 공유, LAN 관리 페이지의 접근 문제가 드러나지 않을 수 있습니다. 로컬 리소스에 접속할 수 없다면 사설 주소와 필요한 네트워크 대역이 올바르게 제외됐는지 확인하고 목적지가 실제 해당 대역에 있는지도 살펴보세요. 모든 사설 주소를 기계적으로 제외하지 마세요. 조직 네트워크는 실제 구성에 따라 별도로 판단해야 할 수 있습니다.

루프, DNS, 여러 네트워크 인터페이스 문제 구분

프록시 프로그램의 원격 연결이 다시 진입 경로로 들어와 순환하지 않도록 가상 네트워크 인터페이스를 구성해야 합니다. 클라이언트가 필요한 제외 설정과 출구 바인딩을 처리하는 경우가 많지만, 여러 네트워크 인터페이스나 공유 네트워크, 다른 네트워크 도구를 함께 사용하면 경로 선택에 문제가 생길 수 있습니다. 사용을 시작한 뒤 모든 연결이 끊기거나 로그에 비슷한 연결이 반복해서 표시되거나 코어 부하가 비정상적으로 커지는 증상이 나타날 수 있습니다. 이때는 가상 네트워크 인터페이스를 끄고 기본 상태로 돌아간 다음 인터페이스 선택과 라우팅을 하나씩 확인하세요. 프록시 계층을 더 추가하지 마세요.

DNS도 흔히 문제가 발생하는 지점입니다. 가상 네트워크 인터페이스가 시스템 조회 경로를 바꿔 기존 보안 DNS, 조직에서 제공하는 DNS, 다른 VPN과 충돌할 수 있습니다. 숫자 주소로는 연결되지만 도메인에 접속할 수 없다면 DNS 경로부터 확인하세요. 대용량 파일이나 일부 프로토콜에서만 문제가 생긴다면 경로, 패킷 크기, 프로토콜 지원도 살펴봐야 합니다. 검증 없이 MTU를 낮추거나 다른 사람의 값을 그대로 적용하지 마세요. 기본값을 기록하고 변경할 때마다 되돌릴 수 있는지 확인한 뒤 같은 목적지를 다시 테스트하세요.

네트워크 인터페이스가 여러 개인 기기는 네트워크 전환에 특히 주의해야 합니다. Wi-Fi와 유선 네트워크 전환, 절전 모드 해제, 네트워크 공유로 기본 출구가 바뀔 수 있습니다. 전환 후에만 문제가 생긴다면 트래픽 처리를 중지했다가 다시 시작하고 새 인터페이스에 맞게 라우팅이 복구됐는지 확인하세요. Android의 VPN 처리는 시스템 인터페이스를 사용하므로 데스크톱의 드라이버 설치나 서비스 조작 방법을 그대로 적용하지 마세요. 주로 확인할 항목은 시스템 권한, 앱별 적용 범위, 다른 VPN의 사용 여부입니다.

유지 관리: 업데이트, 백업, 단계별 문제 해결

되돌릴 수 있는 업데이트 절차 만들기

유지 관리에서는 클라이언트 프로그램 업데이트, 코어 업데이트, 구독 업데이트를 구분하세요. 프로그램 업데이트는 인터페이스와 설정 관리 기능을 바꾸고, 코어 업데이트는 지원 필드와 연결 동작에 영향을 줄 수 있으며, 구독 업데이트는 원격 목록을 바꿉니다. 세 가지를 한꺼번에 실행한 뒤 문제가 생긴 원인을 찾으려 하지 마세요. 먼저 백업한 뒤 한 단계만 업데이트하고 고정된 목적지로 테스트한 다음 다음 항목으로 넘어가는 편이 안전합니다. 업무에 중요한 연결을 변경한다면 복구할 시간을 확보하고 사용 직전에 전체 환경을 바꾸지 마세요.

백업 전에 어떤 데이터가 포함되는지 확인하세요. 구독 주소로 원격 설정을 다시 가져올 수 있어도 수동 노드, 로컬 규칙, DNS 설정, 인터페이스 기본 설정까지 복구된다는 보장은 없습니다. 클라이언트에서 내보낸 백업에 인증 정보가 들어 있을 수 있으므로 안전한 위치에 저장하고 공개 클라우드나 단체 채팅에 공유하지 마세요. 다른 운영체제로 복원할 때는 백업 형식과 가져오기 지원 여부를 확인한 뒤 로컬 경로, 수신 포트, 권한 관련 설정을 점검하세요. 같은 백업이 모든 플랫폼에서 똑같이 작동한다고 가정하지 마세요.

구독 관리 중 수동 설정 보호

구독을 업데이트하기 전에 주소가 유효한지 확인하고 현재 활성 설정을 기록하세요. 업데이트 후 그룹 내용, 활성 항목, 연결 매개변수가 바뀌었는지 살펴보세요. 서버에서 항목을 삭제하면 목록에서 사라질 수 있고 클라이언트가 활성 항목을 다시 선택할 수도 있습니다. 따라서 업데이트가 성공해도 실제 접속을 확인해야 합니다. 오래 유지할 수동 설정은 별도 그룹에 넣고 출처를 적어 두세요. 구독 관리 항목과 섞어 업데이트 과정에서 덮어쓰지 않도록 하세요. 그룹 관리 문제를 숨기려고 같은 설정을 반복해서 가져오지 마세요.

여러 기기에서 같은 구독을 사용한다면 ‘원격 목록 공유’와 ‘로컬 설정 공유’를 따로 관리하세요. 데스크톱과 휴대전화의 라우팅은 서로 다를 수 있고, LAN 제외 설정과 앱 적용 범위는 기기에 맞게 다시 구성해야 합니다. 구독, QR 코드, 백업을 활용하는 방법은 여러 기기 간 설정 동기화 방법을 참고하세요. 어떤 방법을 선택하든 이전한 기기에서 진입 경로, DNS, 라우팅을 다시 확인해야 합니다. 가져오기 완료 안내만 보고 끝내지 마세요.

문제 증거를 단계별로 정리

문제가 생기면 먼저 모든 앱에서 발생하는지, 프록시를 끈 뒤 기본 네트워크가 정상인지 기록하세요. 기본 네트워크도 작동하지 않으면 기기의 연결과 상위 네트워크부터 확인하세요. 시스템 프록시를 사용하는 앱만 실패하면 수신 경로를 점검하세요. 코어가 요청을 받았지만 원격 연결에 실패했다면 활성 설정과 핸드셰이크 로그를 확인하세요. 특정 도메인이나 앱에서만 실패한다면 분할 라우팅, DNS, 앱별 설정에 주의를 기울이세요. 영향 범위에 따라 분류하면 처음부터 모든 프로그램을 다시 설치하는 일을 피할 수 있습니다.

로그를 확인할 때는 오류 발생 시각과 주변 내용을 남기되 주소, 계정 식별 정보, 구독 매개변수, 인증 필드는 먼저 삭제하세요. 로그에 기록된 시간 초과는 여러 단계에서 발생할 수 있으므로 특정 단어 하나만으로 원인을 확정하지 마세요. ‘구독 업데이트 중’, ‘코어 실행 중’, ‘특정 앱을 연 뒤’처럼 오류를 구체적인 동작과 연결해 기록하세요. 문의할 때 운영체제, 클라이언트 버전, 진입 방식, 최근 변경 사항을 함께 적으면 전체 설정 파일을 보내는 것보다 도움이 됩니다.

마지막으로 복구 상태를 확인하세요. 가상 네트워크 인터페이스를 중지하고 남은 시스템 프록시 설정을 지운 뒤 클라이언트를 종료해 일반 네트워크가 정상인지 확인합니다. 이후 최소 설정 기준에 따라 하나씩 다시 실행하세요. 절전 모드에서 깨어난 뒤나 네트워크 전환 후에만 문제가 생긴다면 그 조건을 기록하세요. 간헐적인 상태를 영구적인 설정 오류로 보지 마세요. 필요하다면 문제 해결에서 비슷한 증상을 찾아보세요. 문제 해결 기록에 원인, 변경 사항, 재확인 결과를 남겨 두면 다음에 같은 문제가 발생했을 때 시간을 줄일 수 있습니다.

고급 설정: 검증 가능한 실험으로 구성 확장

설명할 수 있는 기본 설정부터 완성

고급 설정은 모든 고급 스위치를 켜는 것이 아닙니다. 각 요청의 진입 경로, DNS 처리 위치, 일치 규칙, 최종 출구를 설명할 수 있어야 합니다. 먼저 작동하는 기본 설정을 정리하세요. 운영체제와 클라이언트, 활성 설정의 출처, 진입 방식, 라우팅 프리셋, DNS 설정을 기록합니다. 필수 기능과 선택 가능한 실험도 구분하세요. 기본 설정이 없으면 복잡한 구성에서 잠시 연결에 성공해도 네트워크가 바뀌거나 업데이트된 뒤 복구하기 어렵고, 추가 설정이 실제로 어떤 문제를 해결했는지도 알기 힘듭니다.

실험을 시작할 때는 ‘특정 앱이 시스템 프록시를 무시하는가’, ‘특정 도메인이 예상한 출구 규칙과 일치하는가’, ‘네트워크 전환 후에도 DNS가 작동하는가’처럼 검증할 수 있는 질문을 먼저 정하세요. 이어서 고정된 테스트 대상을 선택하고 변경 전 상태를 기록한 뒤 관련 매개변수 하나만 수정하세요. 연결 재사용으로 관찰이 흐려지지 않도록 기존 연결을 닫고 테스트가 끝난 뒤 새 요청을 보내세요. 결과를 안정적으로 재현할 수 없다면 규칙을 더 추가하기보다 실험 범위를 줄이세요.

의존 관계에 맞춰 규칙과 DNS 확장

첫 번째 고급 설정 경로는 세밀한 라우팅입니다. 도메인 전체 일치, 도메인 접미사, 주소 대역의 차이를 익힌 뒤 필요한 예외를 추가하고 순서를 확인하세요. 와일드카드, 정규 표현식, 코어 전용 규칙은 의미가 서로 다를 수 있으므로 다른 환경의 표현식을 그대로 붙여 넣지 마세요. 사용자 지정 규칙마다 목적과 테스트 대상을 기록하세요. 오랫동안 쓰지 않았거나 의미를 설명할 수 없거나 앞의 규칙과 중복되는 항목은 계속 쌓지 말고 정리하세요.

두 번째 경로는 DNS 분할 설정입니다. 앱의 조회, 클라이언트의 DNS, 원격 DNS, 시스템 캐시를 각각 그려 보고 각 단계의 네트워크 의존성을 확인하세요. DNS 서비스 이름만 보고 결과의 품질을 판단하지 말고 실제 대상에 어떤 주소를 반환하는지, 그 주소가 최종 출구에 적합한지 살펴보세요. 암호화 DNS를 사용하는 경우 DNS 서비스 자체의 도메인 주소를 어떻게 확인하는지도 고려해야 합니다. 불필요한 대체 DNS 주소를 늘리기보다 명확한 시작 경로를 구성하는 편이 관리하기 쉽습니다.

완전한 설정 파일과 일부 설정 구분

세 번째 경로는 생성된 설정을 이해하는 것입니다. 먼저 클라이언트에서 제공하는 보기 기능으로 실제 실행 내용을 살펴보고 인바운드, 아웃바운드, 라우팅, DNS가 각각 어떤 역할을 하는지 확인하세요. 그래픽 클라이언트는 시작하거나 저장할 때 파일을 다시 생성할 수 있으므로 생성 결과를 직접 수정해도 변경 사항이 오래 유지되지 않을 수 있습니다. 사용자 지정 설정이 꼭 필요하다면 현재 클라이언트의 불러오기 방식과 지원 범위를 확인하고 기본 설정 전체를 보관하세요. 일부만 보여 주는 예시를 완전한 파일로 간주해 실행하지 마세요.

프로토콜 매개변수는 실제 필요한 기능에 맞춰 익히세요. 새 필드가 포함된 설정을 받으면 필요한 코어와 클라이언트가 지원하는지 확인하고 필드 간 의존성을 파악하세요. 사용 중인 서버에서 제공하지 않은 인증이나 보안 매개변수를 임의로 바꿔 특정 프로토콜을 시험하지 마세요. 전송 방식, 서버 이름, 관련 보안 필드는 원격 서버 설정과 일치해야 하며 클라이언트만으로 결정할 수 없습니다. 용어 가이드를 볼 때는 용어 설명을 실제 설정 항목과 하나씩 연결해, 이름만 외우고 적용 조건을 놓치지 않도록 하세요.

체크리스트로 학습 마무리

전체 점검에는 연결, 분할 라우팅, DNS, LAN 접속, 종료 후 복구가 포함되어야 합니다. 프록시가 필요한 앱이 작동하는지뿐 아니라 직접 연결해야 하는 리소스도 예상대로 접속되는지 확인하세요. 처음 실행뿐 아니라 네트워크 전환, 절전 모드 해제, 재부팅 후 상태도 살펴보세요. 테스트 대상은 특정 테스트 결과를 목표로 삼기보다 실제 사용 환경에서 선택하세요. 네트워크 조건에 따라 결과가 달라질 수 있으므로 하나의 수치보다 환경 정보를 남기는 편이 유용합니다.

점검을 마치면 임시 실험을 간단한 유지 관리 안내로 정리하세요. 설정을 추가한 이유, 적용 여부를 확인하는 방법, 문제가 생겼을 때 끄는 방법, 서비스 업데이트에 맞춰 변경해야 할 필드를 기록합니다. 일상적인 연결을 빠르게 다시 설정하려면 사용 가이드를 참고하세요. 클라이언트를 바꿀 때는 다운로드 페이지에서 플랫폼을 확인하고, 구체적인 오류가 발생하면 해당 장과 문제 해결 안내를 살펴보세요. 경계와 복구 절차를 명확히 해 두면 요구 사항이 늘어나도 설정을 쉽게 이해하고 검증하며 유지 관리할 수 있습니다.