V2Ray 종합 가이드
v2rayN 설치 및 고급 설정

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

연결은 어떤 구성 요소로 이루어질까요?

GUI 클라이언트는 서버 설정을 저장하고 구독을 관리하며 시스템 프록시를 설정한 뒤, 선택한 구성을 프록시 코어에 전달합니다. 코어는 로컬 포트를 열고 라우팅을 판단해 원격 연결을 수립하며 프로토콜을 처리합니다. 서버는 원격 접속 지점을 제공하며 클라이언트와 호환되는 프로토콜 및 설정을 사용해야 합니다. v2rayN을 설치했다고 해서 사용할 수 있는 원격 서버까지 마련된 것은 아닙니다. 구독 주소 역시 프로그램 다운로드 주소가 아닙니다.

일반적인 요청 흐름은 다음과 같습니다. 브라우저가 시스템 프록시 설정을 읽고 요청을 로컬 리스닝 포트로 전달합니다. 코어는 대상 도메인이나 주소에 따라 라우팅 규칙을 확인한 뒤 직접 연결, 프록시 또는 차단을 선택합니다. 프록시가 선택된 경우에만 현재 서버의 프로토콜을 사용해 원격 연결을 수립합니다. 문제를 해결할 때는 이 흐름을 따라 각 구간을 확인하세요. 웹페이지가 열리지 않는다는 이유만으로 서버가 중단됐다고 단정하면 안 됩니다. 브라우저가 프록시를 사용하지 않는 문제와 원격 핸드셰이크 실패는 서로 다른 단계에서 발생합니다.

Project V는 관련 도구 생태계를 이해하는 배경이며 V2Fly와 Xray는 관련 코어 계열, v2rayN 등은 사용자용 GUI 클라이언트입니다. 이름은 비슷해도 각자 역할은 다릅니다. 가이드를 읽을 때는 설명 대상이 클라이언트 버튼인지, 코어 설정 항목인지, 서버 배포 매개변수인지 먼저 확인하세요. 코어 JSON을 구독 주소처럼 가져오거나 한 앱의 백업을 다른 앱에서 불러오면 대개 원하는 결과를 얻을 수 없습니다.

프로토콜, 전송 방식, 보안 설정을 함께 맞추기

VMess, VLESS 등은 프록시 프로토콜을 선택하는 항목입니다. TCP, WebSocket, gRPC 등은 통신을 전달하는 전송 방식이며, TLS와 REALITY는 관련 보안 설정입니다. 연결을 완성하려면 프로토콜 이름뿐 아니라 주소, 포트, 사용자 ID, 전송 경로, 보안 매개변수도 서로 일치해야 합니다. 구독에 포함된 설정을 우선 그대로 사용하세요. 더 최신처럼 보이는 옵션이라는 이유만으로 임의로 바꾸지 마세요.

특히 연결 주소와 서버 이름 표시(SNI)를 구분해야 합니다. 연결 주소는 요청이 전송될 곳을 지정하고, TLS의 서버 이름은 핸드셰이크와 인증서 확인에 사용되므로 배포 방식에 따라 둘이 다를 수 있습니다. 전송에 사용하는 Host, 경로, 서비스 이름도 각각 용도가 다릅니다. 메모용 이름을 이 항목에 입력하면 안 됩니다. 서버에서 특정 값을 요구한다면 누락하거나 잘못 입력했을 때 핸드셰이크가 실패할 수 있습니다. 인증서 검증을 끄는 것은 주소나 이름 오류를 해결하는 일반적인 방법이 아닙니다.

검증 가능한 최소 구성부터 만들기

처음 설정할 때는 목표를 단순하게 잡으세요. 시스템 프록시를 따르는 앱 하나로, 확인된 설정 하나를 사용해 지정한 대상에 접속하는 것입니다. 우선 TUN을 끄고 복잡한 라우팅을 추가하거나 DNS를 함께 바꾸지 마세요. 기본 연결이 성립해야 이후 분할 라우팅을 비교할 기준이 생깁니다. 설정을 여러 개 동시에 바꾸면 우연히 연결이 복구되더라도 무엇이 영향을 줬는지 알 수 없어 다음 문제를 해결할 근거가 부족해집니다.

현재 사용하는 클라이언트와 운영체제, 프록시 진입 방식, 프로토콜, 테스트 결과를 기록해 두세요. 구독 키나 전체 공유 링크를 기록에 저장할 필요는 없습니다. 재현 조건을 남기는 것이 핵심입니다. 용어가 헷갈린다면 용어 가이드를 확인한 뒤 설정을 변경하세요. 이 장의 목표는 모든 프로토콜 이름을 외우는 것이 아니라, 요청이 앱에서 코어로 전달되는 방식과 현재 직접 연결을 사용하는지 원격 프록시를 사용하는지 설명할 수 있는 것입니다.

클라이언트 선택: 데스크톱은 v2rayN, Android는 필요한 코어에 맞춰 선택

먼저 운영체제와 프로세서 아키텍처 확인하기

데스크톱에서는 Windows, macOS, Linux를 지원하는 v2rayN을 우선 고려하세요. 다운로드하기 전에 시스템 정보에서 프로세서 아키텍처를 확인하고 설치 파일을 선택하세요. 파일 이름에 표시된 숫자만 보고 판단하면 안 됩니다. 일반적으로 x64는 데스크톱 Intel 또는 AMD의 64비트 환경, arm64는 해당 ARM 환경을 가리킵니다. 시스템 아키텍처와 앱 패키지가 맞지 않으면 설치되지 않거나 호환 계층을 통해 실행될 수 있습니다. 후자는 첫 설정의 기본 경로로 권장하지 않습니다.

Windows 다운로드 페이지에서는 데스크톱 버전과 클래식 WPF 버전을 제공합니다. 데스크톱 버전은 크로스 플랫폼 UI를 사용하고, WPF 버전은 기존 Windows 인터페이스를 유지합니다. 익숙한 UI와 대상 시스템의 호환성을 고려해 선택하세요. 두 버전이 서로 다른 프록시 프로토콜을 사용하는 것은 아닙니다. 메뉴 위치와 설정 디렉터리, 이전 방법은 버전마다 다를 수 있으므로 기존 설정을 먼저 백업하고 클라이언트가 지원하는 가져오기 기능으로 옮기세요. 프로그램 디렉터리 전체를 그대로 덮어쓰면 안 됩니다.

macOS는 Apple Silicon과 Intel용 설치 파일이 구분됩니다. 시스템의 ‘이 Mac에 관하여’에서 칩 또는 프로세서 정보를 확인할 수 있습니다. Linux는 아키텍처와 배포판의 패키지 형식을 모두 고려하세요. Debian, Ubuntu 계열은 보통 deb, Fedora 계열은 rpm을 사용합니다. 패키지 형식은 어떤 패키지 관리자로 설치하는지를 나타낼 뿐, 프로토콜 지원 수준과는 관계가 없습니다. 특정 프로토콜을 사용하려고 다른 배포판용 패키지를 억지로 설치하지 마세요.

Android용 두 클라이언트의 선택 기준

Android에서는 Xray 코어를 사용하는 v2rayNG를 우선 권장합니다. V2Fly 코어를 사용하는 v2flyNG는 대안으로 고려할 수 있습니다. 서버 설명에 특정 코어 구현이 필요하다고 명시되어 있다면 프로토콜 이름만 보고 판단하지 말고, 클라이언트가 해당 매개변수를 지원하는지 먼저 확인하세요. 같은 공유 링크를 가져올 수 있다고 해서 모든 확장 항목이 올바르게 적용되는 것은 아닙니다. 가져온 뒤 보안 및 전송 설정을 확인하세요.

Android 설치 파일은 arm64와 범용 버전으로 제공됩니다. 최근 출시된 대부분의 스마트폰은 arm64를 선택하지만, 최종적으로는 기기의 실제 아키텍처를 확인해야 합니다. 확인하기 어렵다면 시스템 정보를 살펴보고, 더 다양한 아키텍처를 지원하는 범용 버전을 선택할 수 있습니다. 클라이언트를 비교하는 동안 두 앱에서 VPN 연결을 동시에 활성화하지 마세요. 시스템에서는 보통 이런 연결을 하나만 유지할 수 있어 나중에 실행한 앱이 앞선 연결을 대체할 수 있습니다. 그러면 테스트 결과가 들쭉날쭉해 보일 수 있습니다.

서버 설정은 공유하되 클라이언트 설정까지 같게 맞추려 하지 않기

데스크톱과 Android에서 공유하기 가장 쉬운 것은 지원되는 구독 링크나 개별 서버 공유 링크입니다. 반대로 로컬 경로, 프록시 진입점, 라우팅 설정 파일은 그대로 복사해 사용하기 어렵습니다. 데스크톱 시스템 프록시, Android VPN 인터페이스, 데스크톱 TUN은 모두 트래픽 진입 방식과 관련 있지만 권한 모델은 서로 다릅니다. 기기 간 동기화 후에는 각 기기의 진입점, DNS, 라우팅을 별도로 확인하세요. 한 기기에서 연결된다는 이유만으로 모든 기기에서 제대로 작동한다고 볼 수 없습니다.

다운로드 파일은 다운로드 센터에서 확인하고, 클라이언트별 차이는 클라이언트 비교에서 살펴보세요. 이 단계에서는 주로 사용할 클라이언트와 설치 파일 하나만 정하고 기본 코어를 유지하세요. 기본 연결에 문제가 없고 프로토콜 호환성 요구도 없다면, 코어를 바꾸는 것을 일반적인 최적화로 여길 필요는 없습니다. 변수를 적게 유지해야 설정 과정을 검토하고 재현하기 쉽습니다.

설치 준비: 실행 여부를 확인한 뒤 네트워크 권한 조정하기

설치 전 디렉터리, 프로세스, 기존 설정 정리하기

설치하기 전에 실행 중인 유사 프록시 프로그램을 종료하고, 알림 영역이나 메뉴 막대에 시스템 프록시를 계속 제어하는 기존 프로세스가 없는지 확인하세요. 기존 v2rayN을 업데이트하는 경우에는 먼저 클라이언트에서 시스템 프록시를 해제하고 프로그램을 종료한 뒤 설정을 백업하세요. 프로그램 실행 중 파일을 덮어쓰거나 새 설치 디렉터리와 기존 디렉터리를 섞어 사용하지 마세요. 화면에는 새 버전이 보이지만 백그라운드 코어는 이전 버전인 상황을 방지할 수 있습니다.

설치 경로는 안정적이어야 하며 현재 사용자가 클라이언트 요구에 따라 파일을 읽고 쓸 수 있어야 합니다. 임시 압축 해제 폴더, 이동식 드라이브, 자동 정리 대상 폴더에 오래 두면 다음 실행 때 설정이나 규칙 파일이 사라질 수 있습니다. 설정이 프로그램 디렉터리와 사용자 데이터 디렉터리 중 어디에 저장되는지는 클라이언트의 설정 디렉터리 열기 기능이나 설명을 확인하세요. 모든 설치 방식이 같다고 가정하면 안 됩니다. 백업은 바탕화면 바로 가기가 아니라 실제 데이터가 저장된 경로를 대상으로 해야 합니다.

처음 실행하면 메인 창이 정상적으로 표시되는지, 로그에 오류가 계속 쌓이는지, 코어가 정상적으로 시작되는지 확인하세요. 아직 원격 서버를 설정하지 않았다면 대상에 접속할 수 없어도 설치 실패를 뜻하지 않습니다. 하지만 실행 환경이 없거나 파일이 격리됐거나 설정 디렉터리에 쓸 수 없다면 로컬 설치 문제입니다. 보안 소프트웨어에서 알림이 표시되면 해당 파일과 작업 내용을 확인하세요. 문제를 우회하려고 보호 기능을 모두 끄는 것은 권장하지 않습니다.

필요한 권한만 플랫폼별로 부여하기

Windows에서 시스템 프록시를 일상적으로 사용하는 경우 클라이언트 전체를 계속 관리자 권한으로 실행할 필요는 없습니다. TUN을 활성화하거나 네트워크 구성 요소를 설치할 때만 화면 안내에 따라 권한을 부여하세요. 실행할 때마다 포트가 달라지거나 설정이 사라진다면 일반 사용자와 관리자 권한으로 실행한 인스턴스가 함께 떠 있는지 먼저 확인하세요. 권한을 높이면 프로세스가 보는 환경도 달라질 수 있습니다. ‘관리자 권한으로 실행하면 열렸다’는 이유만으로 문제가 해결됐다고 단정하지 마세요.

macOS에서 개발자 확인 메시지가 표시되면 시스템의 ‘개인정보 보호 및 보안’ 관련 메뉴에서 차단된 앱을 확인하고, 출처를 확인한 뒤 시스템이 안내하는 절차를 따르세요. 출처를 알 수 없는 파일의 보안 제한을 일괄 해제하지 마세요. 시스템 프록시와 이후의 네트워크 제어에는 서로 다른 권한이 필요할 수 있습니다. 창이 열린다고 네트워크 권한까지 모두 설정된 것은 아닙니다. 자세한 경로는 macOS 설치 및 네트워크 권한 안내를 참고하세요. 시스템 버전에 따라 메뉴 이름이 조금 다를 수 있습니다.

Linux에서는 배포판의 패키지 관리자를 통해 해당 deb 또는 rpm 패키지를 설치하는 것이 좋습니다. 그러면 의존성을 체계적으로 관리할 수 있습니다. 구성 요소가 없다는 메시지가 표시되면 설치 프로그램이나 실행 로그를 먼저 확인하고, 출처를 알 수 없는 라이브러리 파일을 연달아 직접 복사하지 마세요. 그래픽 세션의 시스템 프록시 설정이 모든 데스크톱 환경이나 명령줄 프로그램에 적용되는 것은 아닙니다. 설치 성공은 프로그램을 실행할 수 있다는 뜻일 뿐, 앱이 프록시를 사용하는지는 이후 단계에서 따로 확인해야 합니다.

첫 설치 상태를 기준으로 남기기

클라이언트가 실행되면 로컬 리스닝 주소와 포트를 확인하세요. 흔히 사용하는 혼합 리스닝 포트는 10808이지만, 현재 설정을 기준으로 판단해야 합니다. 이전 설정이나 사용자 지정 값에 따라 다를 수 있습니다. 리스닝 주소는 로컬 진입점에 접근할 수 있는 대상을 제한합니다. 개인 기기에서만 사용하는 경우에는 일반적으로 루프백 주소를 유지하세요. 문제를 해결하려고 LAN에 포트를 바로 개방하지 마세요. 포트가 이미 사용 중이라면 점유 프로세스를 찾고, 중복 인스턴스인지 확인한 다음 종료하거나 포트를 변경하세요.

이 장을 마칠 때는 ‘정상 실행되고 로컬 오류가 계속 발생하지 않는’ 설정을 시작점으로 보관하세요. 완전한 연결을 확인할 때까지 TUN과 자동 실행은 꺼 두세요. 코어가 시작되지 않으면 로그로 코어 시작 오류 진단하기를 참고하고 포트, 설정 문법, 항목 호환성, 규칙 파일 순으로 확인하세요. 설치 단계에서 원격 서버 설정까지 함께 바꾸면 로컬 문제와 네트워크 문제가 하나의 로그에 뒤섞입니다.

구독 가져오기: 주소, 공유 링크, 설정 백업 구분하기

먼저 받은 내용의 형식 확인하기

구독 주소는 보통 서버 정보를 가져오기 위해 클라이언트가 접속하는 업데이트 가능한 웹 주소입니다. 개별 공유 링크는 서버 연결 하나를 설명합니다. 클라이언트 설정 백업에는 그룹, 라우팅, UI 환경 설정, 로컬 설정이 포함될 수 있습니다. 각 유형은 가져오기 메뉴가 다릅니다. 제공자의 안내를 먼저 확인해 관리 페이지 주소를 구독 주소로 입력하거나 전체 설정 파일을 서버 링크처럼 붙여 넣지 않도록 하세요.

v2rayN에서 먼저 구독 그룹을 만들고 알아보기 쉬운 그룹 이름을 지정한 뒤, 구독 URL 입력란에 주소를 붙여 넣고 저장하세요. 그룹 이름은 로컬에서 관리할 때만 사용되며 주소 내용을 수정해 주지는 않습니다. 붙여 넣은 뒤 앞뒤 공백, 줄바꿈, 따옴표가 없는지, 채팅 앱에서 문자가 바뀌지 않았는지 확인하세요. 주소에 인증 정보가 포함될 수 있으므로 민감한 정보로 취급해야 합니다. 전체 주소가 보이는 스크린샷이나 공개 로그, 온라인 변환 서비스에 올리지 마세요.

그룹을 저장한 뒤 구독을 업데이트하고 로그와 서버 목록이 예상대로 바뀌었는지 확인하세요. 업데이트 완료 메시지는 클라이언트가 특정 작업을 마쳤다는 뜻일 뿐입니다. 서버 정보가 제대로 파싱됐는지, 전송 및 보안 설정이 유지됐는지도 확인해야 합니다. 다른 그룹 필터가 선택되어 있으면 새 항목이 보이지 않을 수 있습니다. 목록에 변화가 없다고 반복해서 삭제하고 다시 만들지 말고 해당 그룹이나 전체 목록으로 전환하세요.

업데이트 오류가 네트워크 문제인지 내용 문제인지 구분하기

로그에 구독 도메인 확인 실패, 연결 시간 초과, 인증서 오류가 표시되면 먼저 구독 내용을 가져오는 경로를 확인하세요. 기기가 인터넷에 정상적으로 연결되어 있고 시스템 시간이 정확한지 살펴본 뒤, 업데이트 요청에 기존 프록시가 필요한지 확인합니다. 처음 설치해 사용할 수 있는 프록시가 아직 없다면 프록시를 통해 업데이트하려는 설정은 순환 문제가 될 수 있습니다. 이미 작동하는 설정이 있다면 클라이언트에서 지원하는 업데이트 경로를 선택하세요. 버튼 이름만 보고 실제 연결 경로를 추측하면 안 됩니다.

요청은 성공했지만 내용을 파싱하지 못한다면 응답이 로그인 페이지, 오류 페이지 또는 다른 클라이언트 형식인지 확인하세요. 일부 구독 변환 서비스는 연결 정보를 다시 생성하지만 클라이언트별 항목이 누락될 수 있습니다. 형식이 실제로 호환되지 않을 때만 변환을 고려하고, 제공자가 안내한 호환 경로를 우선 사용하세요. 파싱 오류를 해결하려고 인증 정보가 포함된 원본 구독을 데이터 처리 방식이 불분명한 서비스에 제출하지 마세요.

개별 공유 링크는 설정 하나를 명확하게 검증할 때 적합합니다. 클립보드로 가져온 뒤 주소, 포트, 프로토콜, 사용자 ID, 전송 및 보안 설정을 하나씩 확인하세요. QR 코드는 같은 텍스트 정보를 전달하는 방법일 뿐, 스캔에 성공했다고 연결 매개변수가 유효한 것은 아닙니다. 구독으로 생성된 항목을 직접 수정하기 전에 다음 업데이트 때 변경 사항이 덮어써지는지 확인하세요. 장기적으로 유지할 설정은 별도의 수동 그룹에 두고 변경 이유를 기록하는 것이 좋습니다.

사용할 서버를 선택하고 되돌릴 방법 남기기

가져오기가 끝나면 대상 서버를 현재 활성 항목으로 설정하고, 메인 창의 상태와 로그에서 설정이 다시 로드됐는지 확인하세요. 목록에 서버가 있어도 현재 코어가 그 서버를 사용하고 있다는 뜻은 아닙니다. 지연 시간 테스트, 연결 테스트, 웹페이지 접속은 서로 다른 작업입니다. 테스트 하나가 성공해도 해당 테스트 경로만 정상이라는 의미입니다. 실제 사용할 때는 대상 앱으로 확인하세요. 테스트에 실패하면 바로 모든 매개변수를 바꾸지 말고 어느 단계에서 실패했는지 먼저 살펴보세요.

정기 업데이트 전에는 작동하는 설정을 백업하고, 업데이트 후 현재 활성 항목을 확인한 다음 오래된 항목을 정리하세요. 사용할 수 있는 유일한 설정을 백업하지 않은 상태에서 모두 삭제하지 마세요. 여러 기기에서 지원되는 구독을 공유할 수 있지만 제공자의 기기 및 연결 정책을 따라야 하며, 로컬 라우팅은 기기별로 관리해야 합니다. 구체적인 이전 방법은 여러 기기에서 구독 공유 및 설정 내보내기를 참고하세요. 이 단계의 완료 기준은 매개변수를 확인했고 선택된 상태이며 독립적으로 검증할 수 있는 서버 설정 하나를 갖추는 것입니다.

프록시 모드: 앱의 진입점부터 확인한 뒤 외부 연결 정책 판단하기

시스템 프록시는 모든 네트워크 트래픽을 제어하는 스위치가 아닙니다

v2rayN의 시스템 프록시 옵션에는 보통 시스템 프록시 설정 해제, 자동 설정, 변경하지 않기가 있습니다. 자동 설정은 시스템 프록시를 클라이언트의 로컬 리스닝 진입점으로 지정합니다. 해제는 해당 설정을 취소하고, 변경하지 않기는 현재 시스템 상태를 유지합니다. 이 옵션은 앱 요청을 프록시로 전달할지 결정하는 기능입니다. 도메인이 직접 연결될지 프록시를 사용할지는 라우팅과 외부 연결 설정에 따라 별도로 결정됩니다.

시스템 프록시는 주로 해당 설정을 읽는 앱에 영향을 줍니다. 일부 명령줄 도구는 환경 변수를 사용하고, 일부 앱은 별도의 프록시 설정이 있으며, 어떤 프로그램은 직접 연결합니다. 따라서 ‘브라우저는 되는데 터미널은 안 된다’고 해서 반드시 서버 문제인 것은 아닙니다. 대상 앱의 시스템 프록시 지원 여부를 확인한 뒤 앱 내 설정, 명시적 프록시 옵션, TUN 중 적절한 방법을 선택하세요. 진입점 차이를 파악하기 전에 원격 서버부터 계속 바꾸지 마세요.

브라우저 확장 프로그램이 시스템 프록시 설정을 덮어쓸 수도 있습니다. 문제를 확인할 때는 프록시 관련 확장 프로그램을 잠시 끄고 브라우저에 별도의 프록시 설정이 남아 있지 않은지 확인한 다음 시스템 프록시와 비교해 보세요. 특정 브라우저만 작동하지 않는다면 브라우저별 보안 DNS, 캐시, 확장 기능도 확인해야 합니다. 테스트 환경이 단순할수록 요청이 코어에 전달되는지 파악하기 쉽습니다. 여러 프록시 관리 도구를 동시에 실행하면 시스템 설정이 서로 덮어써질 수 있습니다.

명시적 프록시 요청으로 로컬 리스닝 확인하기

현재 혼합 리스닝 포트가 10808이라면 아래 명령으로 HTTPS 요청 하나가 로컬 HTTP 프록시를 명확히 거치도록 할 수 있습니다. 예시에는 예약된 도메인을 사용하므로 실제 실행 시에는 네트워크 연결이 필요합니다. 명령 출력의 연결 과정을 살펴보면 실패가 로컬 진입점, 원격 연결, 대상 응답 중 어디에서 발생했는지 파악하는 데 도움이 됩니다. 요청 한 번의 결과로 모든 앱의 트래픽이 정상적으로 프록시를 거친다고 판단하지 마세요.

curl --proxy http://127.0.0.1:10808 --connect-timeout 10 -I https://example.com/

명령 실행 직후 로컬 포트 연결에 실패한다면 클라이언트와 코어가 실행 중인지, 포트가 일치하는지, 리스닝 주소가 루프백 연결을 허용하는지 확인하세요. 프록시까지 연결된 뒤 핸드셰이크가 실패하면 서버 매개변수, 시스템 시간, 보안 설정을 살펴보세요. 명령으로 대상 응답을 받을 수 있지만 브라우저는 실패한다면 브라우저의 프록시 진입점을 우선 확인하세요. Windows의 일부 터미널에서는 같은 이름의 명령이 다른 동작을 할 수 있으므로 curl.exe를 명시적으로 사용하세요.

SOCKS 요청을 명시할 때는 DNS 조회 위치도 확인해야 합니다. 해당 옵션을 지원하는 curl에서 socks5h://127.0.0.1:10808을 사용하면 도메인 처리를 SOCKS 프록시에 맡깁니다. 로컬에서 먼저 도메인을 확인한 뒤 연결하는 방식과 다릅니다. 이 차이를 활용하면 DNS 문제를 찾을 수 있지만, 모든 프로그램이 같은 형식을 지원하는 것은 아닙니다. 앱에서 주소와 포트를 따로 입력하도록 되어 있다면 화면의 각 항목에 맞춰 입력하세요. 전체 프록시 URL을 주소 입력란에 넣으면 안 됩니다.

진입 방식과 라우팅 방식을 구분해 기록하기

‘전역’과 ‘규칙’은 외부 연결 정책을, 시스템 프록시와 TUN은 진입 방식을 가리키는 경우가 많습니다. 두 종류의 설정은 조합해서 사용할 수 있습니다. TUN을 켜도 규칙에 따라 일부 트래픽은 직접 연결될 수 있고, 시스템 프록시만 켜도 코어에 들어온 요청을 모두 프록시로 보낼 수 있습니다. 설정을 판단할 때는 ‘어떤 앱이 코어로 들어오는가’와 ‘들어온 요청이 어떤 경로로 나가는가’를 나눠 적으세요. 그래야 클라이언트마다 다른 모드 이름에 혼동되지 않습니다.

종료하기 전에 시스템 프록시를 해제하면 로컬 리스닝이 중단된 뒤에도 앱이 이전 포트로 요청을 보내는 상황을 예방할 수 있습니다. 종료 후 네트워크에 문제가 생기면 네트워크를 초기화하기 전에 시스템 프록시가 남아 있는지, 다른 프로그램이 프록시를 설정했는지 확인하세요. 기본 연결이 안정된 뒤 자동 실행을 설정하고, 시스템이 프록시를 사용하기 전에 코어가 준비되는지 확인해야 합니다. 빠른 설정 방법은 사용 가이드의 프록시 모드 설명을 참고하세요. 이 장에서는 각 결과가 발생하는 원인을 살펴봅니다.

라우팅 설정: 규칙 순서, 매칭 대상, DNS

간단한 규칙으로 예상 동작부터 설정하기

라우팅은 코어에 들어온 요청이 어떤 외부 연결을 사용할지 결정하는 기능입니다. 대표적인 외부 연결 태그는 direct, proxy, block이며 각각 직접 연결, 프록시, 차단을 뜻합니다. 각 태그는 실제로 정의된 외부 연결과 연결되어 있어야 합니다. 규칙은 보통 위에서 아래 순서로 확인하고, 조건에 맞으면 해당 동작을 적용합니다. 범위가 넓은 규칙을 앞에 두면 뒤의 세부 규칙이 실행되지 않을 수 있으므로 주의하세요.

처음에는 요구 사항에 맞는 라우팅 프리셋을 선택하고 실제 규칙을 살펴보세요. 규칙을 대량으로 가져오는 것부터 시작하지 않는 것이 좋습니다. 일반적으로 사설 주소는 직접 연결하고, 직접 연결이 필요한 도메인이나 주소는 direct로 보낸 뒤 나머지는 기본 정책으로 처리할 수 있습니다. 광고 차단은 선택 기능이지 연결 성립의 전제 조건이 아닙니다. 차단 규칙을 추가한 뒤 로그인, 이미지, 결제 페이지에 문제가 생기면 기록을 확인해 필요한 요청이 잘못 차단됐는지 살펴보세요.

아래는 매칭 순서를 설명하기 위한 Xray 라우팅 객체 예시이며, 단독으로 실행할 수 있는 완전한 설정이 아닙니다. 같은 이름의 외부 연결이 정의되어 있고, 필요한 geosite 및 geoip 데이터가 준비되어 있다고 가정합니다. 마지막 규칙은 이 예시에서 TCP와 UDP를 모두 처리하는 기본 규칙입니다. 실제 클라이언트는 프리셋이나 다른 방식으로 기본 외부 연결을 생성할 수 있으므로 기존 구조를 이해하지 않은 채 그대로 덧붙이지 마세요.

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["geosite:cn"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": ["geoip:cn"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "proxy"
      }
    ]
  }
}

도메인 규칙과 IP 주소 규칙은 서로 대체할 수 없습니다

도메인 매칭은 라우팅 단계에서 대상 도메인을 확인할 수 있어야 합니다. 주소 매칭은 실제 대상 IP 또는 정책상 허용된 조회 결과에 따라 달라집니다. 앱이 IP 주소로 직접 요청하면 도메인 규칙이 적용되지 않을 수 있습니다. 반대로 도메인 요청이 들어와도 모든 도메인 정책이 즉시 주소를 조회해 IP 규칙을 확인하는 것은 아닙니다. 위 예시는 AsIs를 사용하므로 각 도메인의 IP 주소를 자동 조회해 지역 분류까지 확인할 것으로 기대해서는 안 됩니다.

geosite와 geoip는 분류 데이터이지 온라인 조회 서비스가 아닙니다. 규칙을 인식할 수 있는지는 코어 지원 여부, 파일 존재 여부, 데이터 내용에 따라 달라집니다. 분류를 찾을 수 없거나 파일을 읽지 못한다는 오류가 표시되면 규칙 데이터와 설정 경로부터 확인하세요. 원격 서버를 바꿔도 해결되지 않습니다. 분류 결과가 실제 서비스 배포 위치와 완전히 일치하지 않을 수도 있습니다. 특정 서비스에 대한 요구가 명확하다면 지역 분류가 항상 정확하다고 가정하기보다 범위가 분명한 도메인 규칙을 추가하세요.

DNS는 요청이 어떤 IP 주소를 받는지에 영향을 주며 이후 라우팅 매칭에도 영향을 줄 수 있습니다. 앱 자체의 암호화 DNS, 시스템 DNS, 코어 DNS가 반드시 같은 경로를 사용하지는 않습니다. 설정을 바꾸기 전에 현재 조회 방식을 기록하고 한 번에 하나만 변경하세요. 조회가 성공하는지, 연결 대상이 달라지는지, 라우팅 결과가 예상과 맞는지 확인합니다. 공개 DNS 주소라고 해서 항상 접근 가능한 것은 아니며, DNS 조회에 성공했다고 원격 프록시 연결까지 정상이라고 볼 수도 없습니다.

실제 사용 환경에서 규칙을 검증하고 변경 범위 제한하기

검증할 때는 직접 연결되어야 하는 대상, 프록시를 사용해야 하는 대상, 접근이 필요한 LAN 서비스를 각각 하나씩 선택하고 관련 로그와 실제 결과를 확인하세요. 페이지가 열렸다고 해서 모든 요청이 완료된 것은 아니며, IP 확인 페이지 하나만으로 앱의 모든 연결을 판단할 수도 없습니다. 한 페이지는 여러 도메인에 요청할 수 있어 기본 문서, 정적 파일, 로그인 API에 각각 다른 규칙이 적용됩니다. 일부 요청만 실패한다면 해당 대상을 확인하세요. 사이트 전체의 규칙을 무작정 넓히지 마세요.

사용자 지정 규칙에는 용도를 명확히 적고 적절한 위치에 배치하세요. 업무용 도메인 하나의 동작을 수정할 때는 먼저 정확한 도메인 범위로 검증한 뒤 매칭 범위를 넓힐 필요가 있는지 판단합니다. 변경 후 저장하고 설정을 다시 불러온 다음 같은 대상들을 재검사하세요. 이전 규칙 버전도 보관해 두면 쉽게 되돌릴 수 있습니다. DNS, 도메인 매칭, 외부 연결 용어를 확인하려면 먼저 설명을 살펴보세요. 고급 설정의 핵심은 규칙을 계속 늘리는 것이 아니라 어떤 요청에 영향을 줄지 예측하는 것입니다.

TUN 설정: 트래픽 진입 범위를 넓히고 라우팅과 권한 확인하기

TUN이 필요한 상황인지 먼저 확인하기

TUN은 가상 네트워크 인터페이스와 시스템 라우팅을 통해 트래픽을 받습니다. 시스템 프록시를 사용하지 않는 앱이나 여러 종류의 네트워크 요청을 한데 처리해야 하는 경우에 적합합니다. TUN은 트래픽이 코어로 들어오는 방식을 바꾸지만, 서버 설정 오류를 해결하거나 모든 프로토콜과 대상의 통신을 보장하지는 않습니다. 시스템 프록시를 사용한 기본 연결부터 확인하세요. 그 전에 TUN을 켜면 원격 연결 문제와 가상 인터페이스 문제가 뒤섞일 수 있습니다.

활성화하기 전에 현재 사용할 수 있는 서버, 라우팅 프리셋, DNS 설정, LAN 접근 상태를 기록하고 TUN을 끄는 위치도 확인하세요. 원격 데스크톱이나 원격 유지 관리 환경에서는 라우팅 변경으로 현재 연결이 끊길 수 있으므로 특히 주의해야 합니다. 첫 테스트는 기기를 직접 조작할 수 있는 환경에서 진행하고 기존 네트워크 설정을 유지하세요. 무선 네트워크, 게이트웨이, 구독, 코어를 한꺼번에 변경하지 마세요.

활성화할 때는 클라이언트 안내에 따라 관리자 권한이나 필요한 네트워크 권한을 부여하고, 인터페이스 생성 실패, 라우팅 설정 실패, 권한 거부가 있는지 확인하세요. 구현 방식은 플랫폼과 클라이언트 기능에 따라 다를 수 있으므로 한 플랫폼의 드라이버 설치 절차를 다른 플랫폼에 그대로 적용하면 안 됩니다. 설정 화면에서 켜져 있다고 표시되더라도 로그와 대상 앱으로 검증해야 합니다. 스위치 상태는 설정 의도를 나타낼 뿐, 시스템 작업이 모두 성공했다는 뜻은 아닙니다.

루프 방지 및 LAN 예외 확인하기

프록시 코어가 원격 서버로 보내는 연결이 잘못 설정되어 같은 진입점으로 다시 전달되면 루프가 발생합니다. 클라이언트가 관련 라우팅이나 제외 설정을 관리하는 경우가 많지만, 사용자 지정 시스템 라우팅이나 다른 VPN, 보안 소프트웨어가 이를 방해할 수 있습니다. TUN을 켠 뒤 로그가 반복해서 쌓이거나 모든 접속이 즉시 실패한다면 먼저 TUN을 끄고 기존 상태를 복구한 다음 충돌하는 프로그램과 사용자 지정 설정을 확인하세요. 무작정 계속 재시작하지 마세요.

라우터 관리 페이지, 프린터, 공유 폴더, 개발 서버 등 LAN 서비스는 별도로 테스트하세요. 사설 주소 직접 연결 규칙은 외부 연결 경로를 설정하는 데 도움이 됩니다. 하지만 일부 시스템 라우팅, DNS, 앱 검색 기능에는 추가 경로가 필요하므로 규칙 하나를 추가했다고 모든 LAN 기능이 복구되는 것은 아닙니다. 먼저 분명한 LAN 주소로 테스트한 뒤 이름 조회, 연결 경로, 서비스 자체의 접근 제한 중 어디에서 문제가 생겼는지 확인하세요.

DNS 가로채기 동작은 현재 클라이언트의 구현 방식에 맞춰 이해해야 합니다. 시스템 DNS 경로를 바꾸는 설정도 있고 특정 요청만 처리하는 설정도 있습니다. 앱 자체의 암호화 DNS를 사용하면 동작이 달라질 수 있습니다. ‘IP 주소로는 접속되는데 도메인으로는 안 됨’이라면 우선 DNS를 확인하세요. ‘도메인 조회는 되지만 연결은 실패함’이라면 라우팅과 전송 방식을 살펴보세요. 현재 코어에서 지원하지 않는 DNS 설정 항목을 복사하지 마세요. 이름이 비슷해도 의미가 다를 수 있습니다.

UDP, 절전 모드, 기타 네트워크 도구는 별도 테스트 필요

앱의 트래픽이 TUN으로 들어온다고 해서 원격 서버가 필요한 모든 UDP 기능을 지원하는 것은 아닙니다. 음성 통화, 실시간 통신 등은 서버 기능, 전송 방식, 로컬 네트워크 상태에도 영향을 받으므로 실제 사용 환경에서 확인해야 합니다. 브라우저가 정상이라고 해서 실시간 앱 오류를 클라이언트 성능 문제로 단정하지 마세요. 특정 기능만 작동하지 않는다면 사용 프로토콜, 대상, 외부 연결부터 확인하고 직접 연결이나 호환성 설정이 필요한지 판단하세요.

절전 모드에서 복귀하거나 네트워크를 전환하고 Wi-Fi에 다시 연결한 뒤에는 TUN이 복구됐는지, 시스템 DNS를 사용할 수 있는지 다시 확인하세요. 회사 VPN이나 다른 가상 네트워크 도구와 함께 사용하면 서로 라우팅을 바꿀 수 있고 실행 순서에 따라 결과가 달라질 수 있습니다. 충돌이 확인되면 제외 항목을 계속 추가하지 말고 어떤 도구가 트래픽을 제어할지 정리하세요. 이 장의 완료 기준은 대상 앱이 작동하고 LAN 동작이 예상과 일치하며 TUN을 끈 뒤 원래의 정상 상태로 돌아갈 수 있는 것입니다.

유지 관리: 백업, 업데이트, 로그를 하나의 과정으로 관리하기

설정 백업과 구독 업데이트를 별도로 관리하기

구독 업데이트는 구독 제공자에게서 서버 정보를 다시 가져오는 기능이지, 클라이언트 전체를 백업하는 기능이 아닙니다. 라우팅 규칙, DNS, 프록시 진입점, 그룹 설정, 수동으로 추가한 항목은 구독에 포함되지 않을 수 있습니다. 기본 연결이 안정된 뒤, 주요 규칙을 변경한 뒤, 업그레이드 전 각각 백업을 남기고 운영체제, 클라이언트 종류, 백업 목적을 기록하세요. 백업 폴더에는 구독 인증 정보, 연결 식별자, 민감한 설정이 들어 있을 수 있으므로 공개 동기화 폴더에 두지 않는 것이 좋습니다.

복원하기 전에 대상 클라이언트가 해당 백업 형식을 지원하는지 확인하고 필요한 항목만 선택적으로 복원하세요. 플랫폼별 로컬 파일 경로, 권한, 리스닝 설정을 확인 없이 그대로 적용하면 안 됩니다. 서버만 옮기는 경우에는 구독이나 지원되는 공유 링크를 우선 사용하세요. 클라이언트 상태 전체를 복원한다면 라우팅과 DNS도 추가로 검증해야 합니다. 복원 성공 메시지는 파일 읽기가 끝났다는 뜻일 뿐, 실제 연결과 종료 후 네트워크 복구 여부는 다시 테스트해야 합니다.

구독 자동 업데이트를 사용하면 수동 작업을 줄일 수 있지만, 실패했다고 기존의 정상 항목을 바로 삭제하지 마세요. 먼저 오류 원인과 현재 활성 설정이 남아 있는지 확인한 뒤 다시 시도하거나 구독 제공자에게 문의하세요. 구독 항목을 직접 수정했다면 업데이트로 덮어써지는지 특히 주의해야 합니다. 장기적으로 유지해야 할 특수 매개변수는 화면을 캡처하는 것보다 구체적인 변경 항목과 이유를 기록하는 편이 이전과 재검토에 유용합니다.

필요한 항목만 바꾸며 업그레이드하기

클라이언트를 업그레이드하기 전에 프로그램을 종료하고 설정을 백업하세요. 사용할 기능과 관련된 변경 사항을 읽고, 특히 설정 형식, 라우팅 데이터, 권한 요구 사항을 확인해야 합니다. 한 번에 클라이언트 업그레이드, 코어 전환, 구독 변경, DNS 재설정을 함께 진행하지 마세요. 문제가 생겼을 때 변경 사항이 적을수록 원인을 찾기 쉽습니다. 이전 환경으로 돌아가는 방법을 확인한 뒤 새 버전으로 교체하세요. 새 환경이 작동하지 않고 기존 설정도 복구할 수 없는 상황을 방지할 수 있습니다.

업그레이드 후에는 동일한 검증 항목을 사용하세요. 시스템 프록시를 사용하는 브라우저, 명시적 프록시 요청, 필요한 LAN 서비스, 실제로 TUN을 사용하는 앱을 확인합니다. 화면이 열리는지만 봐서는 안 됩니다. 새로 추가한 기능만 실패한다면 해당 기능을 잠시 끄고 기본 연결은 유지하세요. 기본 연결도 실패한다면 로그를 확인해 설정 호환성과 로컬 실행 환경을 점검해야 합니다.

클라이언트가 안정적으로 작동한 뒤 부팅 시 자동 실행을 설정하세요. GUI 클라이언트 실행, 코어 실행, 시스템 프록시 자동 설정은 서로 다른 작업입니다. Linux 데스크톱의 자동 실행은 사용자 세션에 따라 달라집니다. 자세한 내용은 deb/rpm 설치 및 자동 실행 안내를 참고하세요. 실행을 위해 GUI 전체를 적절하지 않은 고권한 서비스로 등록하지 마세요. 권한 범위와 실행 세션이 맞지 않으면 설정 디렉터리와 네트워크 상태가 더 달라질 수 있습니다.

로그의 맥락을 보존하고 공유 전에 민감한 정보 제거하기

로그를 확인할 때는 오류가 발생한 시점 전후에서 가장 먼저 관련된 오류를 찾고, 그 앞의 시작, 설정 다시 불러오기, 연결 기록을 살펴보세요. 이후 반복되는 오류는 같은 원인에서 비롯된 결과일 수 있습니다. 연결 거부, 시간 초과, 인증서 오류, 알 수 없는 설정 항목은 각각 다른 원인을 가리키므로 모두 단순한 네트워크 문제로 분류하면 안 됩니다. 문제를 해결할 때는 직전에 수행한 작업, 대상 앱, 시스템 프록시와 TUN의 상태를 기록하세요.

로그 상세 수준을 일시적으로 높이면 원인을 찾는 데 도움이 되지만, 문제를 확인한 뒤에는 평상시 수준으로 되돌려 불필요한 기록이 핵심을 가리지 않게 하세요. 외부에 공유하기 전에 구독 주소, 사용자 ID, 전체 서버 정보, 개인정보가 드러나는 항목을 삭제하고 오류 유형과 필요한 맥락만 남기세요. 로그의 시간은 시스템 시간과도 대조해야 합니다. 변경 전 백업, 변경 후 테스트와 결과 기록이 있고, 실패하면 명확한 절차에 따라 되돌릴 수 있어야 유지 관리 과정이 완성됩니다. 재시작한 뒤 한 번 연결됐다는 기억에만 의존하지 마세요.

고급 설정: 문제를 중심으로 프로토콜과 해결 방법 익히기

계층별 문제 해결 순서부터 익히기

고급 설정은 옵션을 더 많이 켜는 것이 아니라 문제를 올바른 계층에서 파악하는 것입니다. 로컬 네트워크 사용 가능 여부, 앱의 프록시 진입 여부, 코어 실행 여부, 서버 설정 일치 여부, DNS 조회 성공 여부, 예상 라우팅 규칙 적용 여부, 마지막으로 대상 서비스 상태 순으로 확인하세요. 각 단계에서 판단을 뒷받침하거나 배제할 관찰 결과를 찾아야 합니다. 검증되지 않은 추측으로 중간 단계를 건너뛰지 마세요.

예를 들어 브라우저에서 페이지가 열리지 않으면 명시적 프록시 요청으로 비교해 보세요. 로컬 포트에 연결할 수 없다면 프로세스와 리스닝 설정을 확인합니다. 포트에는 연결되지만 원격 핸드셰이크가 실패하면 프로토콜, 보안 매개변수, 시스템 시간을 확인하세요. 프록시 요청은 성공하지만 브라우저만 실패한다면 확장 프로그램, 별도 프록시 설정, DNS 조회 방식을 살펴보세요. ‘연결할 수 없음’이라는 같은 증상도 원인별로 나누면 클라이언트를 매번 다시 설치하지 않아도 됩니다.

대상 하나에서만 실패하더라도 여러 개의 정상 확인된 대상과 비교하세요. 모든 대상에서 실패하면 공통 진입점이나 원격 연결부터 확인하는 것이 좋습니다. 특정 도메인만 실패한다면 DNS, 라우팅, 대상 서비스, 접근 조건을 중점적으로 살펴보세요. 페이지에 표시된 지역 제한, 계정 상태, 서비스 접근 제한을 프록시 프로토콜 문제로 오해하지 마세요. 연결 수립 성공과 서비스 이용 허용 여부는 서로 다른 결과입니다.

실제 요구에 맞춰 프로토콜과 코어 익히기

VLESS, VMess 등의 프로토콜을 익힐 때는 먼저 서버와 클라이언트에서 일치해야 하는 항목을 파악한 뒤 전송 계층과 보안 계층의 조합을 이해하세요. 프로토콜 이름만으로 속도, 안정성, 적합한 사용 환경을 판단할 수 없습니다. 실제 배포 방식과 네트워크 경로도 중요합니다. 한 네트워크에서 작동하는 조합이 다른 환경에서도 같은 결과를 보장하지 않으므로 프로토콜 이름만 기록하지 말고 실제 설정 조건을 함께 남기세요.

코어를 바꾸기 전에 현재 서버 설정, 사용자 지정 라우팅, DNS 항목이 대상 코어에서 지원되는지 확인하세요. 클라이언트 UI가 자주 사용하는 작업을 간소화해도 모든 고급 설정이 완전히 호환되는 것은 아닙니다. 먼저 최소 설정으로 기본 연결을 확인하고 사용자 지정 항목을 하나씩 복원하세요. 알 수 없는 설정 항목 오류가 표시되면 해당 코어의 설정 의미에 맞춰 수정하세요. 대소문자만 바꾸거나 오류가 난 줄을 무작정 삭제하지 마세요.

JSON을 수정할 때는 괄호, 쉼표, 문자열 따옴표, 배열 구조부터 확인하세요. JSON에서는 임의의 주석을 사용할 수 없고 마지막 항목 뒤에 쉼표를 둘 수도 없습니다. 문법을 확인한 다음 의미도 검토해야 합니다. 외부 연결 태그가 실제로 정의되어 있는지, 규칙에서 참조하는 데이터를 읽을 수 있는지, 리스닝 포트가 충돌하지 않는지 확인하세요. 형식이 올바른 것은 첫 번째 단계이고 실행에 성공하는 것은 두 번째 단계입니다. 요청이 예상대로 처리되어야 작업이 끝난 것입니다.

특정 기능 최적화를 재현 가능한 실험으로 진행하기

DNS, UDP, 특정 앱의 호환성을 확인할 때는 ‘이 앱이 시스템 프록시를 우회하는가?’ 또는 ‘이 도메인이 직접 연결 규칙에 매칭되는가?’처럼 한 번에 질문 하나만 정하세요. 먼저 기존 결과를 기록하고 관련 설정 하나만 바꾼 뒤 같은 대상으로 다시 검증하세요. 이른바 최적화 설정을 여러 개 한꺼번에 가져오지 마세요. 결과가 좋아져도 원인을 알 수 없고, 나빠져도 되돌릴 범위를 찾기 어렵습니다.

테스트 데이터의 한계도 이해해야 합니다. 연결 테스트는 해당 방식으로 확인한 결과일 뿐 장시간 실제 사용을 대신하지 않습니다. 한 번 응답이 빨랐다고 이후 요청도 모두 같은 성능을 보장하지는 않습니다. 가정, 모바일, 회사 네트워크는 DNS, 프록시, 라우팅 정책이 다를 수 있습니다. 네트워크 간 결과를 비교할 때는 조건을 함께 기록하세요. 숫자 하나를 높이려고 실제 업무에 필요한 안정적인 설정을 망가뜨리지 마세요.

마지막으로 직접 사용할 작업 기록을 정리하세요. 시작과 종료 방법, 현재 진입점과 포트, 직접 연결이 필요한 대상, 백업 위치, 문제가 생겼을 때 먼저 볼 로그를 적어 둡니다. 메인 화면 구성이 익숙하지 않다면 v2rayN 메인 창 기능 살펴보기를 참고하세요. 기본 연결을 다시 설정해야 한다면 사용 가이드로 돌아가세요. 종합 가이드의 목표는 모든 고급 기능을 동시에 켜는 것이 아니라, 설정을 설명하고 검증하고 복구할 수 있는 상태를 만드는 것입니다.