1단계: 클라이언트, 코어, 연결 경로 이해하기
프록시 연결은 여러 단계로 나눠 볼 수 있습니다. 앱이 요청을 보내면 클라이언트가 로컬 진입점을 제공하고, 코어가 설정을 읽어 라우팅을 처리하며, 선택된 서버가 이후 트래픽을 전달합니다. 그래픽 인터페이스는 설정을 관리하는 도구일 뿐, 연결 자체는 아닙니다. 창이 열렸다면 인터페이스가 시작된 것이고, 구독이 갱신됐다면 설정을 가져온 것입니다. 대상 페이지에 정상적으로 접속해야 요청이 지나가는 경로가 작동한다고 볼 수 있습니다. 각 단계의 역할을 구분해야 문제 발생 시 확인할 지점을 찾을 수 있습니다.
Project V, V2Fly, Xray 구분하기
V2Ray는 Project V 프록시 도구 생태계에 속합니다. V2Fly는 관련 코어를 커뮤니티에서 이어서 관리하고 있으며, Xray는 별도로 발전해 온 또 다른 코어 계열입니다. 코어는 프로토콜 처리, 전송, 암호화 연결, 라우팅, DNS 등 실제 작업을 담당합니다. v2rayN, v2rayNG, v2flyNG는 설정을 관리하고 코어를 실행하는 그래픽 클라이언트입니다. 이름이 비슷하다고 코어와 기능, 설정 항목까지 모두 같은 것은 아닙니다. 기능을 확인할 때는 사용하는 클라이언트와 실제 코어, 서버 요구 사항을 함께 살펴보세요.
프로토콜, 전송 방식, 연결 매개변수 구분하기
VMess, VLESS, Trojan은 프로토콜 계층을, WebSocket, gRPC는 전송 방식을 나타냅니다. TLS는 암호화 핸드셰이크와 인증서 검증에 관련됩니다. 서로 바꿔 쓸 수 있는 옵션이 아니라 각 계층에서 함께 작동해야 하는 요소입니다. 서버에서 요구하는 조합에 맞춰 클라이언트를 설정해야 합니다. 주소와 포트가 맞더라도 경로가 틀리거나, 프로토콜이 맞더라도 서버 이름이 틀리면 연결되지 않을 수 있습니다. 가능한 한 전체 공유 링크나 구독을 사용하고, 이름만 보고 설정을 직접 조합하지 마세요.
노드는 클라이언트에 저장되는 연결 매개변수 모음으로, 일반적으로 서버 주소, 포트, 사용자 식별자, 전송 방식, 보안 옵션 등을 포함합니다. 노드 이름은 식별을 돕기 위한 것이며, 이름에 표시된 지역이나 회선 정보만으로 실제 출구나 성능을 확인할 수는 없습니다. 구독은 여러 노드 설정을 한꺼번에 가져오는 방식입니다. 구독을 가져와도 서비스가 새로 만들어지는 것은 아니며, 모든 노드가 현재 사용 가능하다는 보장도 없습니다. 클라이언트, 구독 제공처, 원격 서비스는 각각 구분해서 이해해야 합니다.
트래픽 경로를 따라 설정의 역할 파악하기
앱이 요청을 클라이언트로 보낼지는 시스템 프록시, 앱 자체 프록시 설정, TUN의 트래픽 처리 여부에 따라 달라집니다. 요청이 코어에 들어온 뒤에는 라우팅 규칙이 직접 연결, 프록시, 차단 중 하나를 결정합니다. 따라서 시스템 프록시의 ‘자동 설정’과 라우팅의 ‘전역’은 서로 다른 설정입니다. 전자는 트래픽이 클라이언트에 들어오는 방법을, 후자는 들어온 트래픽이 나가는 방법을 정합니다. 시스템 프록시를 사용하지 않는 앱이라면 라우팅 규칙만 바꿔도 네트워크 경로가 달라지지 않을 수 있습니다.
처음 배울 때는 기기 한 대, 클라이언트 하나, 정상 작동이 확인된 노드 하나로 최소 연결을 구성하세요. 프록시 도구를 여러 개 동시에 실행하지 마세요. 테스트 조건도 고정합니다. 먼저 일반 네트워크가 되는지 확인하고, 프록시가 필요한 대상에 접속한 다음 로그와 출구를 살펴보세요. 각 단계의 예상 결과를 알아야 이후 DNS, 라우팅, 가상 네트워크 인터페이스를 변경했을 때 문제가 해결된 것인지 새로운 문제가 생긴 것인지 판단할 수 있습니다.
2단계: 플랫폼과 설정 요구에 맞는 클라이언트 선택하기
데스크톱에서는 v2rayN을 우선 고려하세요. 설치 패키지를 선택할 때는 운영체제, 프로세서 아키텍처, 인터페이스 계열과 패키지 형식을 차례로 확인합니다. 특정 플랫폼을 지원한다고 해서 아무 설치 패키지나 해당 플랫폼에서 실행되는 것은 아닙니다. 같은 제품이라도 빌드에 따라 필요한 구성 요소, 권한, 인터페이스 구성이 다를 수 있습니다. 클라이언트 다운로드 페이지에서 해당 플랫폼의 다운로드 항목을 확인하세요. 다른 가이드의 스크린샷에 나온 파일 이름만 보고 패키지를 고르지 마세요.
데스크톱 버전과 클래식 WPF 버전 선택하기
Windows에서는 v2rayN 데스크톱 버전과 클래식 WPF 버전을 사용할 수 있습니다. 데스크톱 버전은 새로운 크로스 플랫폼 인터페이스를 사용하고, WPF 버전은 기존 인터페이스를 유지합니다. 처음 설정한다면 데스크톱 버전부터 시작해 보세요. 이미 WPF 버전에 익숙한 작업 흐름이 있다면 해당 인터페이스의 메뉴에 따라 설정을 계속해도 됩니다. 두 버전은 설정 메뉴나 로컬 데이터 구조가 다를 수 있으므로 기존 인스턴스를 실행한 채 새 인스턴스에서 같은 데이터를 수정하지 마세요. 전환하기 전에 클라이언트를 종료하고 기존 설정을 저장하세요.
macOS에서는 칩에 맞는 Apple Silicon 또는 Intel 빌드를 선택하세요. 프로세서 정보는 시스템의 ‘이 Mac에 관하여’에서 확인할 수 있습니다. Linux에서는 배포판의 패키지 형식과 x64 또는 arm64 아키텍처를 확인하세요. deb와 rpm은 패키지 관리 형식이지 성능 등급이 아닙니다. 기기 외관만으로 아키텍처를 판단할 수도 없습니다. 호환 계층으로 실행할 수 있어도 해당 기기에 가장 적합한 빌드라는 뜻은 아닙니다. 설치에 실패하면 먼저 패키지 형식과 아키텍처가 맞는지 확인하고, 이후 의존성 문제를 살펴보세요.
| 사용 환경 | 선택 기준 | 먼저 확인할 사항 |
|---|---|---|
| Windows | v2rayN 데스크톱 버전 또는 WPF 버전 | 인터페이스 계열, 시스템 아키텍처, 실행 의존성 |
| macOS | v2rayN | Apple Silicon 또는 Intel |
| Linux | v2rayN | deb 또는 rpm, x64 또는 arm64 |
| Android | v2rayNG 우선, v2flyNG 대안 | 프로세서 아키텍처, 코어, 설정 호환성 |
코어와 아키텍처에 맞는 Android 클라이언트 선택
Android에서는 Xray 코어를 사용하는 v2rayNG를 우선 권장합니다. V2Fly 코어 기반 설정이 필요하다면 v2flyNG를 고려하세요. 두 클라이언트는 노드 수나 인터페이스 색상이 아니라 코어 호환성과 사용 방식에 따라 선택해야 합니다. 최신 주류 스마트폰은 보통 arm64를 선택하면 됩니다. 아키텍처를 확인하기 어렵거나 해당 패키지와 호환되지 않는 문제가 있다면 범용 버전 안내를 확인하세요. 범용 버전은 더 많은 기기를 지원하지만 운영체제 자체의 최소 요구 사항까지 우회하는 것은 아닙니다.
코어를 선택할 때는 서버 설정에 필요한 기능을 우선 확인하세요. 다른 코어로 바꾸면 모든 프로토콜 매개변수를 그대로 사용할 수 있다고 생각하지 마세요. 보안 옵션, 전송 항목, 최신 기능은 특정 코어나 빌드에서만 지원될 수 있습니다. 가져오기 중 지원하지 않는 항목이 표시되거나 노드가 건너뛰어지고 설정 검증에 실패하면 구독 제공처의 호환성 안내를 확인하세요. 임의의 옵션을 계속 바꾸는 것은 해결책이 아닙니다. 클라이언트를 업데이트해도 서버에 없는 기능을 추가할 수는 없습니다.
여러 기기에서 사용할 때는 노드 출처와 이름을 가급적 통일하되 앱 데이터 디렉터리 전체를 그대로 복사하지 마세요. 데스크톱의 시스템 프록시와 Android의 VPN 인터페이스는 트래픽을 처리하는 방식이 다르며, 사용할 수 있는 라우팅과 DNS 옵션도 다를 수 있습니다. 구독을 다시 가져오고 활성 노드를 선택한 다음, 기기에 맞게 프록시 진입점을 설정하는 편이 안전합니다. 플랫폼, 아키텍처, 코어 요구 사항과 선택 이유를 기록해 두면 다음 업데이트 때 다시 추측할 필요가 없습니다.
3단계: 설치와 실행 전 점검 완료하기
설치 전에 일반 네트워크가 작동하는지, 시스템 날짜·시간·시간대가 정확한지, 설정과 로그를 저장할 공간이 충분한지 확인하세요. 인증서 검증은 시스템 시간에 의존합니다. 시간이 크게 어긋나면 노드 설정이 올바르더라도 TLS 핸드셰이크에 실패할 수 있습니다. 다운로드와 실행은 로컬 준비 단계이므로 이때 TUN을 켜거나 DNS를 먼저 바꿀 필요는 없습니다. 설치, 코어 실행, 네트워크 트래픽 처리를 분리해서 진행하면 첫 설정에서 문제 범위를 명확히 할 수 있습니다.
Windows: 프로그램 폴더와 실행 의존성 확인하기
다운로드 페이지의 안내에 따라 설치 프로그램을 실행하거나, 압축 파일을 쓰기 권한이 있는 고정 폴더에 모두 압축 해제하세요. 압축 파일 미리보기에서 주 프로그램을 바로 실행하거나 실행 파일 하나만 따로 꺼내지 마세요. 관련 파일이 없으면 인터페이스나 코어가 시작되지 않을 수 있습니다. 첫 실행 시 실행 구성 요소가 필요하다는 안내가 나오면 해당 빌드에 맞는 아키텍처의 의존성을 설치하세요. 의존성 누락은 노드를 사용할 수 없는 문제와 발생 단계가 다르므로 혼동하지 마세요.
실행한 뒤에는 기본 창과 알림 영역을 확인하고 클라이언트가 중복 실행되지 않았는지 살펴보세요. 로그에 로컬 포트가 이미 사용 중이라고 나오면 다른 프록시 클라이언트를 종료한 다음 다시 시작하세요. 여러 인스턴스를 함께 실행해야 한다면 인스턴스마다 다른 수신 포트를 설정하고, 시스템 프록시를 담당할 인스턴스를 명확히 정하세요. 처음 설정하는 단계에서는 함께 실행하지 않는 편이 좋습니다. 방화벽 알림은 프로그램 경로와 용도를 확인해 판단하세요. 문제 해결을 위해 시스템 방화벽을 전부 끄지 마세요.
macOS와 Linux: 설치 권한과 트래픽 처리 권한 구분하기
macOS에 설치한 뒤에는 앱을 안정적인 위치로 옮기고 실행하세요. 시스템 제한이 발생하면 다운로드 경로와 패키지 종류, 시스템에 표시된 구체적인 안내를 먼저 확인한 뒤 시스템에서 허용하는 방식으로 처리하세요. 현재 시스템과 관계없는 우회 명령을 그대로 따라 하지 마세요. 일반 프록시와 TUN은 필요한 권한이 다릅니다. 인터페이스가 열린다고 해서 가상 네트워크 인터페이스를 만들 수 있는 것은 아닙니다. 먼저 일반 프록시 연결을 확인하고, 더 많은 앱의 트래픽을 처리해야 할 때 클라이언트 안내에 따라 필요한 권한을 부여하세요.
Linux에서는 배포판에 맞는 패키지 설치 방식을 사용하고 패키지 관리자가 표시하는 의존성 오류를 확인하세요. 데스크톱 클라이언트는 일반 사용자 세션에서 실행해야 합니다. TUN에 권한이 필요하다고 해서 데스크톱 프로그램 전체를 상시 높은 권한으로 실행하지 마세요. 실행에 실패하면 프로그램 로그, 폴더 쓰기 권한, 데스크톱 환경을 점검하세요. 시스템 프록시 설정은 보통 데스크톱 환경에 따라 달라집니다. 명령줄 프로그램이 프록시를 사용하는 방식은 별개이므로 한쪽 결과로 다른 쪽을 판단할 수 없습니다.
Android: 권한을 허용한 뒤 백그라운드 동작 확인하기
Android의 시스템 절차에 따라 설치한 뒤 클라이언트를 열어 설정을 가져오세요. 처음 연결을 시작하면 시스템에서 VPN 연결 권한을 요청합니다. 이는 클라이언트가 트래픽을 처리하는 시스템 인터페이스를 사용하는 권한이며, 원격 노드에 연결됐다는 뜻은 아닙니다. 같은 인터페이스를 사용하는 다른 앱이 있다면 먼저 중지한 다음 현재 클라이언트를 실행하세요. 실행 직후 연결이 끊기면 구독이나 모든 노드 설정을 지우기보다 시스템 권한과 앱 로그부터 확인하세요.
화면을 켠 상태에서 한 번 연결한 뒤 화면을 잠그거나 앱을 전환했을 때 연결이 끊기는지 살펴보세요. 일부 시스템은 백그라운드 실행을 제한하므로 기기 설정에서 클라이언트의 배터리 사용과 백그라운드 권한을 조정할 수 있습니다. 모든 앱의 제한을 해제할 필요는 없습니다. 설치 단계에서는 인터페이스가 정상적으로 열리고, 설정을 저장할 수 있으며, 코어가 실행되고, 로그에 로컬 실행 오류가 계속 나타나지 않는지 확인하세요. 이 조건을 충족하면 구독을 가져오고 서버를 선택하세요. 권한을 허용하는 구체적인 절차는 빠른 시작 가이드를 참고하세요.
4단계: 구독을 가져오고 활성 서버 관리하기
구독 주소는 설정을 가져오는 데 사용하는 주소이며, 보통 계정과 연결된 접근 정보가 포함됩니다. 클라이언트의 구독 설정에서만 사용하고 공개 토론, 스크린샷, 온라인 변환 도구에 붙여 넣지 마세요. 먼저 받은 것이 구독 주소인지 단일 노드 공유 링크인지 확인하세요. 구독 주소는 구독 그룹에 사용하고, 단일 노드 링크는 보통 클립보드에서 가져옵니다. 웹 계정 주소를 구독 입력란에 넣거나 기본 설정 텍스트를 구독 링크로 취급하면 파싱에 실패합니다.
네 단계로 구독 그룹 만들기
- v2rayN의 구독 그룹 설정을 열고 그룹을 추가한 다음 알아보기 쉬운 메모와 전체 구독 주소를 입력하세요.
- 그룹을 저장한 뒤 구독을 갱신하세요. 처음에는 현재 작동하는 네트워크 경로로 가져오기를 시도합니다.
- 서버 목록으로 돌아가 노드가 해당 그룹에 포함됐는지 확인하고, 갱신 로그에 파싱 오류가 있는지 살펴보세요.
- 노드를 선택해 활성 서버로 지정한 다음 시스템 프록시를 설정하거나 모바일에서 연결을 시작하세요.
주소 형식은 https://example.com/sub?token=xxxx처럼 표시할 수 있습니다. 도메인과 매개변수는 형식을 설명하기 위한 예시일 뿐 실제 노드 정보가 아닙니다. 실제 주소를 붙여 넣을 때 앞뒤 공백과 줄바꿈이 없는지, 문자가 빠지지 않았는지 확인하세요. 특히 물음표 뒤의 매개변수를 빠뜨리지 마세요. 그룹 메모는 로컬에서 구분하기 위한 것으로 연결 매개변수에 영향을 주지 않습니다. ‘사용’ 옵션의 동작은 보통 해당 그룹이 관련 작업에 참여할지 결정하지만, 자세한 동작은 현재 인터페이스 안내를 확인하세요.
갱신 간격과 요청 방식 이해하기
자동 갱신 간격은 최신 설정을 주기적으로 가져오는 기능입니다. 연결 속도를 높이려고 간격을 지나치게 짧게 설정할 필요는 없습니다. 요청이 너무 잦으면 구독 서비스의 요청 제한에 걸리거나 문제 해결 로그가 불필요하게 늘어날 수 있습니다. User-Agent에 따라 서버가 반환하는 설정 형식이 달라질 수 있으므로 보통 클라이언트 기본값을 유지하세요. 구독 제공처에서 명시적으로 요구하는 경우에만 변경합니다. 갱신 결과가 웹 페이지, 로그인 페이지 또는 지원되지 않는 형식이라면 주소와 반환된 콘텐츠 형식을 확인하고 기존에 작동하던 그룹을 반복해서 덮어쓰지 마세요.
구독을 직접 연결로 갱신할지 프록시로 갱신할지는 현재 사용 가능한 네트워크에 따라 결정하세요. 사용 가능한 노드가 하나도 없는데 사용할 수 없는 프록시를 통해 구독을 받도록 하면 해결할 방법이 없는 순환 상태가 됩니다. 정상적으로 작동하는 프록시는 있는데 구독 주소에 직접 연결할 수 없을 때만 가져오기 경로를 바꾸세요. 연결, 인증, 파싱 중 어디에서 실패했는지 먼저 기록합니다. 갱신 실패로 기존 노드가 반드시 삭제되는 것은 아니며, 기존 노드를 즉시 사용 중지할 필요도 없습니다.
설정 갱신, 속도 측정, 실제 연결 구분하기
구독 갱신은 연결 매개변수를 가져오는 작업이고, 활성 서버 지정은 현재 사용할 아웃바운드를 선택하는 작업입니다. 두 가지를 모두 해야 합니다. 노드 속도 측정은 특정 시점에 특정 방식으로 테스트한 결과일 뿐입니다. TCP 지연 시간은 TCP 연결 수립 상태를 주로 나타내며 프로토콜 인증, TLS, 전송, 대상 접속까지 보장하지 않습니다. 실제 연결 테스트는 실제 요청에 더 가깝지만 테스트 대상, 제한 시간, 네트워크 시간대의 영향을 받습니다. 목록에서 가장 작은 숫자만 보고 계속 사용할 노드를 결정하지 마세요.
Android에서도 구독 그룹이나 구독 관리에 주소를 추가하고 갱신한 뒤 목록으로 돌아가 노드를 선택하고 연결을 시작해야 합니다. 클라이언트마다 메뉴 이름은 조금씩 다를 수 있지만 순서는 설정 가져오기, 설정 선택, 연결 시작, 결과 확인입니다. 첫 연결은 v2rayNG 노드 선택과 프록시 작동 확인 가이드에서 이어서 살펴보세요. 공유 링크와 기본 설정을 다뤄야 한다면 구독 형식과 설정 변환 안내를 참고해 서로 다른 입력 형식을 혼용하지 마세요.
5단계: 프록시 진입점을 설정하고 트래픽 확인하기
데스크톱에서는 먼저 일반 시스템 프록시로 기본 연결을 확인하세요. 활성 서버를 선택한 다음 클라이언트의 시스템 프록시 메뉴에서 필요한 경우 ‘시스템 프록시 자동 설정’을 선택합니다. 이 작업은 시스템 설정에 로컬 프록시 진입점을 지정합니다. 해당 설정을 따르는 앱만 요청을 클라이언트로 보냅니다. 클라이언트가 계속 실행 중이어야 합니다. 프로그램을 종료했는데 시스템 프록시가 로컬 포트를 계속 가리키면 브라우저에 접속 오류가 나타날 수 있지만 일반 네트워크 자체가 사라진 것은 아닙니다.
시스템 프록시의 세 가지 동작 구분하기
‘시스템 프록시 자동 설정’은 프록시 진입점을 설정하고, ‘시스템 프록시 지우기’는 해당 시스템 설정을 제거합니다. ‘시스템 프록시 변경 안 함’은 클라이언트가 현재 시스템 설정을 직접 수정하지 않는다는 뜻입니다. 마지막 항목은 강제로 직접 연결하는 설정이 아니며, 시스템에 다른 프로그램이 남긴 프록시가 없다는 의미도 아닙니다. 클라이언트를 바꾸거나 종료 후 인터넷이 되지 않는 문제를 해결할 때는 시스템 네트워크 설정에서 실제 상태를 확인하세요. 트레이 메뉴의 문구만 보지 말고 운영체제에서 주소와 포트가 계속 적용 중인지 확인하세요.
| 설정 계층 | 해결하는 문제 | 흔한 오해 |
|---|---|---|
| 시스템 프록시 | 해당 설정을 지원하는 앱이 로컬 프록시에 연결되는 방법 | 모든 앱이 자동으로 시스템 프록시를 따른다고 생각함 |
| 앱별 프록시 | 앱이 연결할 로컬 진입점 지정 | HTTP 포트를 SOCKS 포트로 착각함 |
| 코어 라우팅 | 코어에 들어온 트래픽이 사용할 아웃바운드 | 전역으로 바꾸면 모든 앱이 처리된다고 생각함 |
| TUN | 가상 네트워크 인터페이스로 더 많은 트래픽 처리 | 켜면 반드시 속도가 빨라진다고 생각함 |
시스템 프록시를 사용하지 않는 앱에 개별 설정
일부 앱은 HTTP 또는 SOCKS 프록시를 별도로 설정할 수 있습니다. 클라이언트에 표시된 수신 유형과 포트에 맞춰 입력하세요. 로컬 주소는 보통 127.0.0.1을 사용하며 포트는 현재 설정에서 확인해야 합니다. 다른 기기의 값을 그대로 복사하지 마세요. 진입점에서 사용자 이름과 비밀번호를 요구한다면 앱에도 동일하게 설정해야 합니다. 앱에서 프록시 URL을 입력하라고 하면 프로토콜 접두어도 확인하세요. 포트 번호만 입력한다고 두 프록시 프로토콜이 서로 연결되는 것은 아닙니다.
로컬 수신 주소와 원격 노드 주소를 혼동하지 마세요. 앱별 프록시는 로컬 진입점을 가리키고, 원격 서버 매개변수는 클라이언트 코어가 사용합니다. 로컬 기기에서만 사용할 때는 기본 루프백 수신 설정을 유지하세요. LAN 연결을 허용하면 접근 범위가 넓어지므로 인증과 방화벽도 함께 고려해야 합니다. LAN의 다른 기기에서는 해당 기기의 루프백 주소가 아니라 클라이언트가 실행 중인 기기의 LAN 주소를 입력해야 합니다. 일반적인 개인 사용이라면 테스트를 위해 수신 범위를 넓힐 필요가 없습니다.
세 가지 근거로 연결 확인하기
먼저 일반적으로 접속할 수 있는 대상에 접속해 기본 네트워크가 끊기지 않았는지 확인합니다. 다음으로 프록시가 필요한 테스트 대상에 접속해 페이지가 실제로 열리는지 살펴봅니다. 마지막으로 출구 정보와 클라이언트 로그를 함께 확인해 트래픽 경로를 판단하세요. 출구 주소는 요청을 보낸 앱과 당시 라우팅만 보여 주므로 다른 앱의 결과까지 대신 설명하지는 않습니다. 분할 라우팅을 사용하는 경우 직접 연결 대상에 로컬 네트워크 출구가 표시되는 것은 정상일 수 있으며 프록시가 반드시 작동하지 않는다는 뜻은 아닙니다. 테스트 전에 각 대상이 어떤 경로를 따라야 하는지 정하세요.
브라우저는 작동하는데 특정 앱만 실패한다면 노드를 바로 바꾸지 말고 앱의 프록시 지원 여부, 개별 설정, 기존 연결 재사용부터 확인하세요. 프록시를 바꾼 뒤에도 이미 연결된 장시간 연결은 기존 경로를 사용할 수 있습니다. 관련 연결을 닫거나 테스트 앱을 다시 시작한 뒤 확인하세요. 모든 앱에서 실패한다면 활성 노드, 코어 로그, 로컬 수신 설정을 차례로 확인합니다. 첫 연결 점검 절차는 연결 및 프록시 작동 확인에서 볼 수 있습니다. 클라이언트를 종료한 뒤에는 시스템 프록시가 원래대로 복구됐는지도 확인해 사용 과정을 마무리하세요.
6단계: 라우팅과 DNS 규칙 설정하기
일반 프록시 연결을 확인한 다음 라우팅을 조정하세요. 라우팅 규칙은 코어에 들어온 요청을 프록시, 직접 연결, 차단 중 어디로 보낼지 결정합니다. 보통 규칙 순서대로 일치 여부를 확인하지만 구체적인 동작은 코어와 규칙 유형에 따라 다릅니다. 처음부터 방대한 규칙 모음을 가져오기보다 클라이언트에서 제공하는 일반적인 분할 라우팅 방식을 사용한 뒤 꼭 필요한 규칙만 추가하는 편이 관리하기 쉽습니다. 변경 전에는 현재 라우팅 방식, 기본 아웃바운드, 규칙 순서를 기록해 문제가 생겼을 때 되돌릴 수 있게 하세요.
세부 규칙부터 기본 아웃바운드까지 설정하기
먼저 LAN 주소와 내부 도메인 같은 로컬·내부 리소스를 처리하고, 그다음 특정 서비스 도메인을 설정한 뒤 마지막에 기본 아웃바운드로 보냅니다. 더 세밀하게 제어하는 규칙은 범위가 넓은 규칙보다 앞에 두는 것이 일반적입니다. 도메인 규칙과 IP 규칙은 서로 다른 정보를 기준으로 일치 여부를 판단합니다. 요청에 대상 도메인이 남아 있으면 도메인 규칙을 적용할 수 있고, 대상 IP만 있다면 DNS 결과나 다른 식별 방식이 필요할 수 있습니다. 모든 요청에 도메인과 주소 정보가 모두 있다고 가정하지 마세요.
아래는 Xray 라우팅 필드의 구조 예시로, LAN 사설 주소를 직접 연결하는 방법만 보여 줍니다. 완전한 클라이언트 설정이 아니며 direct라는 태그가 붙은 아웃바운드가 이미 있어야 합니다. 그래픽 인터페이스에서 설정할 때는 클라이언트가 제공하는 해당 규칙 메뉴를 사용하세요. 이 조각을 구독 주소에 붙여 넣거나 실행 설정 전체를 덮어쓰지 마세요. 클라이언트가 설정을 다시 생성할 수 있으므로 지속적으로 적용할 수정 사항은 지원되는 위치에 저장해야 합니다.
{
"routing": {
"domainStrategy": "AsIs",
"rules": [
{
"type": "field",
"ip": [
"geoip:private"
],
"outboundTag": "direct"
}
]
}
}DNS 경로와 대상 아웃바운드 연동하기
DNS는 도메인을 주소로 변환하지만, 누가 조회하는지, 조회 요청이 어떤 경로를 거치는지, 결과가 라우팅에 어떻게 반영되는지는 서로 다른 문제입니다. 앱에서 직접 DNS를 조회한 뒤 IP 주소를 프록시에 전달하는 경우와 앱이 도메인을 프록시에 전달한 뒤 조회하는 경우는 동작이 다릅니다. 운영체제 DNS를 바꿔도 코어 내부 DNS가 바뀌지 않을 수 있고, 코어 DNS를 바꿔도 앱 자체의 DNS 기능까지 제어할 수는 없습니다. 실제로 어느 계층에서 조회하는지 확인한 뒤 수정할 위치를 정하세요.
내부 도메인은 해당 이름을 알고 있는 로컬 DNS나 조직 DNS에서 조회해야 하는 경우가 많습니다. 프록시 대상은 사용 경로와 호환되는 DNS를 사용할 수 있어야 합니다. 암호화 DNS를 설정할 때는 DNS 서버로 연결되는 경로와 서버 도메인을 처음 조회하는 방법도 확인해 의존성 순환을 피하세요. DNS 주소 하나를 바꾸면 모든 접속 문제가 해결된다고 생각하지 마세요. 설정 변경 후에는 관련 앱의 캐시를 지우거나 연결을 다시 만들어야 합니다. 이전 결과가 남아 있으면 테스트에서 변경 사항이 드러나지 않을 수 있습니다.
모드 이름만 보지 말고 규칙을 하나씩 검증하기
규칙을 추가할 때마다 일치해야 하는 대상 하나와 일치하지 않아야 하는 대상 하나를 골라 각각 테스트하고, 로그에 표시된 대상과 아웃바운드를 확인하세요. 사이트의 본문은 열리지만 이미지나 로그인이 작동하지 않는다면 추가로 필요한 도메인이 서로 다른 경로에 배정됐는지 살펴보세요. IP 지역 데이터베이스나 도메인 분류 데이터에 의존하는 규칙은 관련 리소스가 정상적으로 있어야 작동합니다. 리소스 누락, 이름 불일치, 업데이트 시점 차이로 예상한 결과와 실제 동작이 다를 수 있습니다.
일상적으로 사용할 때는 설정을 이해하고 되돌릴 수 있어야 합니다. 사용자 지정 규칙마다 용도와 테스트 대상을 기록하고, 문제가 생기면 새로 추가한 규칙을 일시 중지하세요. 일부 앱만 특별한 경로를 사용해야 한다면 범위가 명확한 방법을 우선하고 전체 네트워크를 복잡한 정책으로 바꾸지 마세요.
7단계: 필요할 때 TUN과 가상 네트워크 트래픽 처리 사용하기
TUN은 가상 네트워크 인터페이스를 통해 트래픽을 받아 직접 프록시를 설정할 수 없거나 시스템 프록시를 따르지 않는 앱에 적합합니다. TUN은 트래픽이 클라이언트에 들어오는 방식을 바꾸는 기능입니다. 원격 노드 품질을 높이거나 회선 혼잡을 해결하지는 않습니다. 활성화하기 전에 같은 노드가 일반 프록시 모드에서 정상적으로 접속되는지 확인하세요. 그렇지 않으면 네트워크가 끊겼을 때 노드 상태를 확인할 수 없고, 가상 인터페이스, 시스템 라우팅, DNS 중 어디서 문제가 생겼는지도 구분하기 어렵습니다.
권한, 충돌, 기본 설정부터 확인하기
데스크톱에서 가상 인터페이스를 만들거나 시스템 라우팅을 바꾸려면 추가 권한이 필요한 경우가 많습니다. 클라이언트 안내에 따라 권한을 부여하세요. 스위치를 켰다고 트래픽 처리가 정상적으로 시작됐다고 판단하면 안 됩니다. 로그에서 권한 부족, 인터페이스 생성 실패, 라우팅 설정 실패가 있는지 확인하세요. 기기에서 조직 네트워크 도구, 다른 가상 네트워크 인터페이스, 다른 트래픽 처리 프로그램을 함께 사용한다면 해당 프로그램의 요구 사항도 확인해야 합니다. 확실하지 않다면 업무 연결에 영향을 주지 않도록 TUN 테스트를 중단하세요.
처음 사용할 때는 클라이언트가 권장하는 스택, 인터페이스, 라우팅 설정을 유지하고 MTU, DNS 가로채기, 스니핑 옵션을 동시에 바꾸지 마세요. 빌드마다 TUN 구현과 설정 메뉴가 다를 수 있으므로 다른 코어의 필드를 그대로 옮기지 마세요. 시스템 프록시와 TUN을 함께 켤지는 현재 클라이언트의 구현에 따라 판단해야 합니다. 테스트할 때는 어떤 진입점이 트래픽을 처리하는지 분명히 하세요. 여러 진입점을 반복해서 켜는 방식으로 작동하지 않는 진입점을 감추지 마세요.
트래픽 처리 범위를 단계별로 확인하기
- 정상 작동이 확인된 노드를 유지한 채 TUN을 켜고, 코어가 계속 실행되며 같은 오류가 반복되지 않는지 확인하세요.
- 브라우저와 원래 시스템 프록시를 사용하지 않던 앱 하나에서 각각 요청을 보내 실제 동작을 확인하세요.
- 로컬 라우터, 프린터, 내부 서비스에 접속해 LAN 리소스가 예상대로 연결되는지 확인하세요.
- 절전 모드에서 복귀하거나 네트워크를 전환하고 TUN을 끈 뒤 네트워크가 복구되는지 확인하세요.
외부 대상은 접속되는데 LAN 리소스만 작동하지 않는다면 노드를 바로 바꾸지 말고 사설 주소 제외 설정, 내부 도메인 조회, 라우팅 우선순위를 먼저 확인하세요. 도메인으로 접속할 수 없고 알려진 대상의 연결 결과도 다르다면 DNS 경로를 확인해야 합니다. 특정 IP에 접속된다는 사실만으로 모든 DNS 조회가 정상이라고 판단할 수는 없습니다. 특정 앱만 실패한다면 앱에서 사용하는 전송 프로토콜과 연결 방식, 자체 네트워크 제한도 확인하세요. TUN이 모든 원격 전송 기능을 제공하는 것은 아닙니다.
UDP, IPv6, MTU는 신중하게 다루기
UDP를 사용하는 앱은 진입점, 코어, 선택한 노드, 원격 서비스가 모두 해당 트래픽을 지원해야 합니다. IPv6는 시스템 주소와 기본 라우팅, DNS 결과, 클라이언트의 트래픽 처리 범위를 함께 확인해야 합니다. IPv4 테스트가 성공했다고 다른 주소 경로도 정상이라고 단정할 수 없습니다. 실제 연결 대상과 로그를 각각 확인해 처리되지 않은 경로가 예상대로 작동하는지 살펴보세요. 문제가 생겼다고 시스템의 네트워크 기능 전체를 영구적으로 끄지 마세요.
MTU는 인터페이스에서 허용하는 패킷 크기입니다. 일부 회선에서는 큰 패킷이나 추가 캡슐화로 로딩이 멈출 수 있지만, 비슷한 증상이 패킷 손실, DNS, 서버 문제로 발생할 수도 있습니다. 비교할 근거가 있을 때만 값을 조정하고 기존 값을 기록하세요. 한 번에 하나의 매개변수만 바꾼 뒤 같은 대상을 다시 테스트합니다. 개선되지 않으면 원래 값으로 되돌리세요. 흔히 말하는 범용 값을 무작정 적용하면 이후 문제 해결의 기준을 잃을 수 있습니다.
Android는 시스템 VPN 인터페이스로 트래픽을 처리하므로 데스크톱의 TUN 스위치와 설정 항목이 일대일로 대응하지 않을 수 있습니다. 중요한 점은 시스템 권한, 라우팅 범위, DNS, 백그라운드에서의 지속 실행입니다. 명확한 필요가 없다면 이미 검증된 간단한 설정을 유지하세요.
8단계: 업데이트, 백업, 일상 유지 관리 절차 만들기
연결이 되면 설정을 계속 바꾸기보다 정상 작동 기준을 유지하는 데 집중하세요. 클라이언트 계열, 활성 노드, 라우팅 방식, DNS 설정, TUN 사용 여부를 기록합니다. 전체 인증 정보나 모든 속도 측정 결과를 보관할 필요는 없습니다. 기록의 목적은 다음 문제가 발생했을 때 최근에 무엇을 바꿨는지, 마지막으로 정상 작동했을 때 어떤 설정을 사용했는지 확인하는 것입니다. 이후 업데이트도 이 기준에 맞춰 진행하고 여러 구성 요소를 한꺼번에 바꾸지 마세요.
네 가지 업데이트를 구분해 관리하기
클라이언트 업데이트는 인터페이스와 설정 관리 방식에 영향을 주고, 코어 업데이트는 프로토콜과 연결 동작을 바꿀 수 있습니다. 구독 업데이트는 원격 노드 매개변수를 교체하고 규칙 리소스 업데이트는 분할 라우팅 결과를 바꿀 수 있습니다. 서로 다른 작업입니다. 일부 빌드에서는 여러 항목을 함께 업데이트할 수 있지만 실제 업데이트 범위를 안내에서 확인하세요. 호환성 문제가 없다면 클라이언트 업데이트, 코어 교체, 전체 규칙 갱신을 동시에 진행한 다음 접속 결과 하나로 모든 변경 사항을 판단하지 마세요.
업데이트 전에 불필요한 인스턴스를 종료하고 설정을 저장하세요. 업데이트 후에는 기존 노드와 라우팅으로 먼저 테스트한 뒤 새 기능을 사용합니다. 설정 이전 안내가 표시되면 기존 데이터를 복구할 수 있는지 확인하세요. 같은 설정 폴더에 새 프로그램과 이전 프로그램이 동시에 기록하지 않도록 하세요. 이전 환경으로 돌아가려면 해당 환경과 호환되는 백업을 사용해야 합니다. 빌드마다 데이터 구조가 달라질 수 있으므로 새 설정을 이전 프로그램에 그대로 복사해도 원래 동작을 복구할 수 있다는 보장은 없습니다.
설정 단위로 백업하고 민감한 정보는 공개하지 않기
클라이언트가 지원하는 내보내기나 백업 기능을 사용해 그룹, 라우팅, 필요한 환경설정을 저장하세요. 백업 파일에 구독 주소, 사용자 식별자, 서비스 매개변수가 들어 있을 수 있으므로 접근이 통제되는 위치에 보관하고 공개 첨부 파일로 올리지 마세요. 다른 기기로 옮길 때는 구독과 규칙을 복원한 다음 대상 기기에 맞게 수신 포트, 시스템 프록시, TUN 권한을 다시 설정하세요. 이 기기의 네트워크 인터페이스 이름이나 LAN 주소가 모든 기기에서 통용된다고 생각하지 마세요.
도움 요청에 사용하는 자료와 전체 백업은 따로 관리하세요. 문제를 문의할 때는 증상, 플랫폼, 사용 모드, 재현 방법, 민감한 정보를 가린 로그를 제공하면 됩니다. 주소에 포함된 접근 매개변수, 노드 인증 정보, 계정 정보는 숨기세요. 스크린샷에 메모, QR 코드, 클립보드 내용이 보이지 않는지도 확인합니다. 로그를 정리할 때 설정까지 모두 지울 필요는 없습니다. 반복 재시도 기록을 많이 보내기보다 실패 직전과 직후의 핵심 로그를 남기는 편이 더 유용합니다.
일상적인 문제를 반복 가능한 점검 항목으로 나누기
구독 갱신이 갑자기 실패하면 주소가 유효한지, 가져오기 경로가 작동하는지 확인하세요. 노드 하나만 실패하면 같은 그룹에서 정상 작동이 확인된 노드로 비교합니다. 모든 노드가 느려졌다면 로컬 네트워크와 기기 부하를 먼저 확인하세요. 특정 대상만 이상하다면 대상 서비스 자체와 라우팅 결과를 살펴봅니다. 속도 문제는 노드, 회선, 로컬 설정으로 나눠 확인하세요. 자세한 내용은 v2rayN 속도 저하 단계별 문제 해결을 참고하세요. 원인을 찾는 대신 프로그램을 반복해서 재설치하지 마세요.
오랫동안 사용한 뒤에는 사용하지 않는 그룹, 중복된 수동 노드, 더 이상 필요 없는 규칙을 정리할 수 있습니다. 먼저 활성 설정이 해당 항목에 의존하지 않는지 확인하세요. 시작 시 자동 실행과 시스템 프록시 자동 설정도 함께 점검해야 합니다. 클라이언트가 실행되지 않았을 때 시스템에 프록시 진입점이 남는지, 네트워크 준비가 되기 전에 갱신에 실패하면 자동으로 다시 시도하는지 확인하세요. 절전 후 복귀, Wi-Fi와 유선 네트워크 전환, 모바일 핫스팟 전환도 간단히 테스트하는 것이 좋습니다.
유지 관리의 목표는 로그에서 모든 안내를 없애는 것이 아니라 연결 동작을 이해할 수 있게 하는 것입니다. 계속 발생하는 오류는 원인을 찾아야 하지만 정상 종료나 일시적인 네트워크 전환으로 남은 로그는 앞뒤 상황을 고려해 판단하세요. 확인되지 않은 최적화 값을 많이 모으는 것보다 간단하고 재현 가능한 절차를 유지하는 편이 유용합니다.
9단계: 계층별 문제 해결과 고급 설정 계획하기
고급 설정은 문제가 어디에서 발생했는지 파악하는 데서 시작합니다. 스위치를 더 늘리는 것부터 시작하지 마세요. 로컬 네트워크, 클라이언트 실행, 설정 파싱, 로컬 진입점, 원격 연결, 대상 접속, 라우팅과 DNS 순으로 확인합니다. 근거가 확보된 계층을 넘어 다음 단계로 진행하세요. 브라우저에 시간 초과가 표시된다는 사실만으로 인증서, DNS, 라우팅 중 무엇이 문제인지 알 수 없습니다. 같은 시점의 클라이언트 로그를 확인해 요청이 들어왔는지, 어디에 연결했는지, 어느 단계에서 멈췄는지 살펴보세요.
오류가 발생한 단계에서 문제 범위 좁히기
시작하자마자 파싱 오류가 발생하면 필드, 형식, 코어 호환성을 먼저 확인하세요. 로컬 포트 연결에 실패하면 중복 실행과 포트 점유 여부를 살펴봅니다. 원격 연결이 시간 초과되면 주소, 포트, 네트워크 경로, 서비스 상태를 확인하세요. 핸드셰이크나 인증에 실패하면 프로토콜, 사용자 식별자, 전송, 보안 매개변수를 점검합니다. 대상에서 명확한 애플리케이션 계층 오류를 반환했다면 대상 서비스 자체의 제한도 고려하세요. 성공하지 못한 응답을 모두 프록시 클라이언트 탓으로 돌리지 마세요.
TLS 문제가 발생하면 먼저 기기 시간을 확인한 뒤 서버 이름, 인증서 적용 범위, 인증서 체인을 살펴보세요. 서버 주소와 TLS에 사용하는 이름은 서로 다른 역할을 할 수 있지만 서버 요구 사항에 맞게 설정해야 합니다. 오류 메시지를 없애려고 인증서 검증을 계속 끄지 마세요. 검증을 끄면 연결 확인 조건만 달라질 뿐 서버 이름이나 인증서 설정이 수정되지는 않습니다. 자세한 순서는 TLS 핸드셰이크 및 인증서 오류 해결을 참고하세요. 변경 전후에 같은 대상을 테스트해 비교하세요.
실험마다 입력 조건과 판단 기준 고정하기
성능을 테스트할 때는 기기, 네트워크, 노드, 대상을 고정하고 연결 수립 시간과 지속 전송 속도를 구분하세요. 작은 파일 로딩이 느리다면 DNS나 핸드셰이크가 원인일 수 있고, 다운로드가 계속 느리다면 회선 대역폭, 혼잡, 원격 서버 부하도 확인해야 합니다. Mux 다중화가 항상 더 빠른 것은 아닙니다. 연결 구성 방식을 바꾸는 기능이며 결과는 프로토콜과 네트워크 환경에 따라 달라집니다. 활성화 전에 기존 값을 기록하고 성능 개선이 일관되게 확인되지 않으면 되돌리세요. 우연한 결과 한 번만 보고 복잡한 설정을 계속 사용하지 마세요.
| 기록 항목 | 기록 내용 | 판단 목적 |
|---|---|---|
| 문제 범위 | 모든 앱, 앱 하나 또는 대상 하나 | 진입점 문제와 특정 대상 문제 구분 |
| 단일 변경 사항 | 이번에 조정한 설정 하나 | 변경 전후 비교 |
| 테스트 근거 | 로그 단계, 접속 결과, 출구 경로 | 스위치 상태만 보고 판단하지 않기 |
| 복구 작업 | 기존 값과 복구 후 재테스트 결과 | 남은 부작용이 없는지 확인 |
그래픽 설정에서 설정 구조 읽기로 나아가기
다음 단계에서는 인바운드, 아웃바운드, 라우팅, DNS의 설정 구조를 살펴볼 수 있습니다. 먼저 그래픽 인터페이스의 옵션이 실제로 무엇을 의미하는지 확인한 다음 코어에서 지원하는 필드를 읽어 보세요. 클라이언트가 생성한 실행 설정이 지속적으로 수정할 수 있는 설정 파일인 것은 아닙니다. 직접 편집한 내용이 재시작 시 덮어써질 수 있습니다. 사용자 지정 설정 기능을 사용할 때는 일상적으로 쓰는 설정을 덮어쓰지 말고 별도의 테스트 설정을 준비하세요. 예시의 아웃바운드 태그, 리소스 이름, 의존성도 하나씩 확인해야 합니다.
라우터나 보조 라우터에 배포해야 한다면 시스템 포워딩, 정책 라우팅, 투명 프록시, DNS 루프백을 추가로 학습하세요. 이는 네트워크 장비 계층의 별도 주제이므로 데스크톱 클라이언트의 TUN 설정을 그대로 옮기는 방식으로 해결할 수 없습니다. Xray 라우터 및 보조 라우터 배포 개요에서 기본 라우터와 보조 라우터의 역할을 확인하고 로컬 복구 경로를 준비한 뒤 실험하세요. 기본 게이트웨이를 바꾼 뒤 관리 화면에 접속하지 못하는 상황을 피할 수 있습니다.
최종적으로 세 가지를 할 수 있어야 합니다. 최소 설정으로 연결하고, 각 트래픽이 어디로 가는지 근거를 들어 설명하며, 문제가 생기면 정상 작동이 확인된 상태로 복구하는 것입니다. 새로운 문제가 생겼다면 처음부터 다시 설치하지 말고 이 페이지에서 해당 단계를 확인하세요. 첫 설정은 빠른 가이드의 구독 가져오기 절차를 다시 확인할 수 있습니다. 기기나 클라이언트를 바꿀 때는 다운로드 페이지에서 플랫폼과 아키텍처를 다시 확인하세요. 각 단계의 역할을 명확히 구분해야 고급 설정을 안정적으로 다룰 수 있습니다.