V2Ray 설정 가이드
설치부터 라우팅까지

핵심 개념: 인터페이스, 커널, 연결 흐름

GUI 클라이언트와 프록시 커널의 역할

V2Ray는 Project V 프록시 생태계의 핵심 프로젝트입니다. 일상적으로 사용하는 v2rayN, v2rayNG, v2flyNG는 서버, 구독, 라우팅과 시작 옵션을 관리하는 GUI 클라이언트입니다. 실제 연결 처리는 커널이 담당합니다. V2Fly와 Xray는 서로 관련된 커널 계열이지만 기능 발전 방향과 설정 지원 범위가 완전히 같지는 않습니다. 화면에 특정 프로토콜 옵션이 보여도 모든 커널에서 해당 설정을 사용할 수 있다는 뜻은 아닙니다. 호환성을 판단할 때는 클라이언트와 커널, 서버 요구 사항을 함께 확인해야 합니다.

일반적인 연결 흐름은 다음과 같습니다. 앱이 요청을 보내면 트래픽이 로컬 프록시 입구로 들어오고, 커널이 규칙에 따라 직접 연결, 프록시 또는 차단 중 하나를 선택한 뒤 연결을 이어 갑니다. GUI에서 '시작'을 눌렀다는 것은 클라이언트가 커널 실행을 시도했다는 뜻입니다. 서버를 선택했다는 것은 기본 프록시 출구를 지정했다는 의미일 뿐입니다. 실제로 목적지에 접속하려면 앱이 해당 입구를 사용하고, 도메인이 정상적으로 해석되며, 서버 설정이 올바르고, 목적지 서비스가 연결을 허용해야 합니다. 문제를 해결할 때는 이 흐름을 단계별로 확인하세요.

프로토콜, 보안 계층, 전송 방식을 구분하세요

VMess, VLESS, Trojan, Shadowsocks는 서로 다른 프록시 프로토콜입니다. TCP, WebSocket, gRPC 등은 전송 방식을 설명하며, TLS와 REALITY는 연결 보안 메커니즘과 관련이 있습니다. 공유 링크에는 각 계층의 설정이 함께 들어가므로 프로토콜 이름만 보고 노드를 직접 다시 만들 수는 없습니다. 같은 VLESS 설정이라도 전송 방식, 보안 설정, 서비스 이름이 다르면 연결되지 않을 수 있습니다. 서버에서 제공한 조합 그대로 클라이언트에 가져오세요. 흔히 보이는 옵션을 하나씩 무작정 켜는 방식은 피해야 합니다.

특히 서버 주소, TLS 서버 이름, HTTP Host를 구분해야 합니다. 서버 주소는 연결 입구를 찾는 데 사용하고, 서버 이름은 보통 TLS 핸드셰이크와 인증서 검증에 쓰입니다. Host는 애플리케이션 계층의 전달에 사용될 수 있습니다. 이 값들은 서로 같을 수도, 서버 설정에 따라 다를 수도 있습니다. REALITY에는 공개 키, 짧은 ID 등 서로 짝이 맞아야 하는 값이 포함될 수 있으므로 다른 설정의 값을 가져와 채우면 안 됩니다. 필드가 빠져 있다면 설정 출처에 확인하세요. 오류를 피하려고 검증을 끄는 방법은 사용하지 마세요.

구독, 공유 링크, 로컬 설정의 관계

공유 링크는 보통 서버 설정 하나를 담고, 구독 주소는 클라이언트가 주기적으로 가져올 수 있는 설정 묶음을 가리킵니다. 구독은 프록시 연결 통로나 계정 자체가 아닙니다. 가져오기에 성공했다는 것은 클라이언트가 내용을 읽었다는 뜻이지, 모든 연결이 정상이라는 의미는 아닙니다. 특정 클라이언트나 설정 형식에 맞춘 구독도 있으므로 브라우저에서 열린다고 바로 가져올 수 있는 것은 아닙니다. 전체 설정 파일에는 진입점, DNS, 라우팅까지 포함될 수 있어 단일 공유 링크보다 적용 범위가 넓습니다. 가져오기 전에 어떤 항목을 다루는지 확인하세요.

이후 장에서도 같은 순서로 확인합니다. 먼저 설정 내용을 확인하고, 커널이 실행되는지 살핀 뒤, 앱이 연결되는지 검증하고, 마지막으로 라우팅 출구를 확인하세요. 한 번에 한 계층만 변경하고 변경 전의 정상 상태를 보존해야 합니다. 연결에 실패했을 때 가져오기 형식, 연결 매개변수, 로컬 트래픽 처리 방식 중 어디에 문제가 있는지 구분할 수 있습니다. 프로토콜, 구독, 클라이언트 이름은 서로 다른 항목을 가리키는 레이블일 뿐 속도, 안정성, 서비스 품질을 판단하는 기준은 아닙니다.

클라이언트 선택: 데스크톱과 Android의 역할

데스크톱은 v2rayN, Android는 커널 요구 사항에 맞춰 선택

Windows, macOS, Linux 데스크톱에서는 v2rayN을 우선 고려하세요. GUI에서 서버 관리, 구독 업데이트, 라우팅 선택, 코어 설정을 할 수 있어 연결 상태 확인이나 여러 설정 관리, 분할 라우팅 조정에 적합합니다. Windows 다운로드 페이지에는 데스크톱 버전과 클래식 WPF 버전이 있습니다. 전자는 크로스 플랫폼 인터페이스를, 후자는 클래식 인터페이스를 사용합니다. 버전의 속도 등급을 나타내는 구분이 아니며, 인터페이스의 신구만으로 프로토콜 지원을 판단할 수도 없습니다. 실제 지원 범위는 포함된 커널과 릴리스 안내를 확인하세요.

Android에서는 Xray 커널을 사용하는 v2rayNG를 우선 고려하고, V2Fly 커널을 사용하는 v2flyNG는 대안으로 살펴볼 수 있습니다. 이미 가진 설정의 요구 사항, 기기 호환성, 필요한 커널 기능을 기준으로 선택하세요. 한 기기에서 두 클라이언트를 동시에 실행할 필요는 없습니다. Android에서 VPN 연결을 처리하는 활성 서비스는 일반적으로 하나뿐이라 다른 VPN, 업무용 프로필 또는 보안 도구와 충돌할 수 있습니다. 비교 테스트를 하려면 기존 서비스를 먼저 중지한 다음 같은 네트워크와 서버 설정으로 새 클라이언트를 실행하세요.

아키텍처와 설치 형식이 패키지 실행 여부를 결정합니다

프로세서 아키텍처에 맞는 설치 패키지를 선택해야 합니다. macOS에서는 시스템의 '이 Mac에 관하여'에서 칩을 확인하세요. Apple Silicon은 arm64, Intel은 x64 패키지를 선택합니다. Linux에서는 배포판의 패키지 형식도 확인해야 합니다. 보통 Debian·Ubuntu 계열은 deb, Fedora 등은 rpm을 사용하지만, 확장자가 같다고 의존성까지 호환되는 것은 아닙니다. 이 사이트의 Windows 다운로드 항목은 x64용이므로 모든 프로세서에서 쓸 수 있는 패키지로 오해하지 마세요. 아키텍처가 맞지 않으면 실행을 반복해서 시도하기보다 올바른 패키지를 선택하세요.

최근 출시된 Android 기기는 보통 arm64를 우선 고려할 수 있습니다. 실제 시스템에서 다른 ABI를 사용한다면 호환되는 패키지가 필요합니다. 범용 버전에는 여러 아키텍처용 파일이 포함되어 있어 아키텍처를 모를 때 선택하기 좋지만, 파일이 크다고 연결 성능이 더 좋아지는 것은 아닙니다. 기기 출시 시기는 대략적인 참고 자료일 뿐이며, 정확한 정보는 시스템이나 기기에서 확인하세요. 설치 프로그램에서 호환되지 않는다고 표시되면 시스템 요구 사항, ABI, 남은 저장 공간을 먼저 확인하고 기존 서명과의 충돌 여부를 살펴보세요.

실제 사용 목적에 맞춰 선택 기준 세우기

컴퓨터와 휴대폰에서 같은 구독을 사용하려면 두 기기에서 구독 형식과 서버가 요구하는 프로토콜을 모두 지원하는지가 중요합니다. 클라이언트 이름까지 같을 필요는 없습니다. 공유 링크로 연결 매개변수를 전달할 수는 있지만, 데스크톱 시스템 프록시와 Android 앱별 라우팅은 로컬 설정이므로 기기마다 따로 구성해야 합니다. 서버에서 REALITY를 요구한다면 해당 커널과 클라이언트가 필요한 필드를 지원하는지 확인하세요. 'VLESS 지원'만으로 모든 VLESS 조합을 사용할 수 있다고 단정하면 안 됩니다. 프로토콜별 자세한 비교는 프로토콜 비교 글을 참고하세요.

설치 전에 클라이언트 다운로드 페이지에서 플랫폼과 다운로드 항목을 확인한 뒤 클라이언트 비교를 참고해 사용 범위를 정하세요. 주로 사용할 클라이언트는 하나만 두고, 다른 클라이언트는 필요할 때 확인용으로 활용하면 됩니다. 사용 경험을 비교할 때는 같은 서버, 네트워크, 목적지를 사용하세요. 프로토콜 설정별 차이는 원격 환경에서 비롯될 수 있으며 클라이언트 때문만은 아닙니다. 선택한 설치 패키지 종류를 기록해 두고 같은 경로로 업데이트하면 설정 폴더와 실행 방식, 이전 절차를 일관되게 유지하기 쉽습니다.

설치 및 초기 설정: 실행 가능한 로컬 환경부터 만들기

설치 전에 권한, 경로, 기존 설정 확인

설치 전에 실행 중인 다른 클라이언트를 종료하고 다운로드한 패키지가 시스템과 아키텍처에 맞는지 확인하세요. 이전에 포터블 폴더나 다른 설치 경로를 사용했다면 설정을 먼저 백업하고, 새 파일과 기존 파일을 같은 폴더에 섞지 마세요. 설치 폴더와 사용자 설정 폴더는 서로 다를 수 있으므로 프로그램 파일을 삭제해도 설정이 지워지지 않을 수 있습니다. 재설치 후에도 이전 설정이 남는 것은 이상한 일이 아닙니다. 클라이언트에서 설정 위치를 확인하거나 시스템 앱 폴더를 살펴 데이터가 저장된 곳을 찾으세요. 다른 프로그램의 파일을 실수로 지우지 않도록 주의해야 합니다.

Windows에 설치한 뒤 처음 실행할 때는 주 창이 정상적으로 표시되는지 확인한 다음 실행 로그를 살펴보세요. 포터블 버전은 읽기·쓰기가 가능한 안정적인 폴더에 두세요. 압축 파일 미리보기에서 바로 실행하거나 자동 정리되는 임시 경로에 두지 않는 것이 좋습니다. 일반적인 시스템 프록시 설정에는 관리자 권한을 계속 사용할 필요가 없습니다. TUN이나 관련 서비스에는 추가 권한이 필요할 수 있습니다. 보안 프로그램이 파일을 격리했다면 출처와 감지 내용을 확인하고, 시스템 보호 기능 전체를 바로 끄지 마세요.

플랫폼별 첫 실행 확인

macOS에 설치할 때는 다운로드 페이지 안내에 따라 칩에 맞는 패키지를 선택하고, 앱을 안정적인 위치에 둔 뒤 실행하세요. 시스템에서 실행을 차단하면 '개인정보 보호 및 보안'에서 구체적인 사유를 확인하고 시스템이 제공하는 승인 절차를 따르세요. 모든 앱의 보안 검사를 해제하는 포괄적인 명령은 사용하지 않는 것이 좋습니다. 네트워크나 보조 구성 요소 권한을 처음 요청하면 현재 클라이언트가 요청한 것인지 확인하세요. 실행 후 창이 보이지 않더라도 메뉴 막대나 Dock에서 상태를 확인해 백그라운드 실행, 창 숨김, 실제 종료를 구분하세요.

Linux에서는 배포판이 지원하는 패키지 관리 방식으로 deb 또는 rpm을 설치하고, 먼저 패키지 관리자가 보고한 의존성 문제를 해결한 뒤 GUI를 실행하세요. 데스크톱 세션의 시스템 프록시 지원 여부는 데스크톱 환경에 따라 다릅니다. 클라이언트에서 설정이 성공했다고 모든 앱이 연결된 것은 아닙니다. Android는 설치 후 앱을 열고 설정을 가져오세요. 처음 프록시를 시작할 때 VPN 권한을 승인해야 할 수 있습니다. 권한 창은 시스템이 로컬 트래픽 처리 서비스를 허용한다는 뜻이지, 구독이나 원격 연결을 검증했다는 의미는 아닙니다.

먼저 연결 입구를 확인하고 서버를 살펴보세요

처음 실행할 때는 TUN을 끄고 다른 프록시 도구도 잠시 종료하세요. 설정에서 로컬 수신 주소, 포트, 입구 유형을 확인하고 HTTP, SOCKS, 혼합 중 무엇인지 살펴보세요. 모든 클라이언트에 공통으로 적용되는 로컬 포트는 없습니다. 예시 포트를 실제 설정 대신 사용하지 마세요. 로그에 주소가 이미 사용 중이라고 나오면 남아 있는 인스턴스를 종료하거나 수신 포트를 바꾸세요. 포트를 바꿨다면 프록시를 수동 설정한 앱에서도 값을 업데이트해야 합니다. 그렇지 않으면 앱이 계속 이전 입구로 요청을 보냅니다.

수신 주소는 우선 루프백 범위로 유지해 이 기기에서만 사용하세요. 'LAN 연결 허용'을 켜면 다른 기기에서도 입구에 접근할 수 있습니다. 파일 공유와는 별개의 설정이므로 꼭 필요한 경우에만 사용하고, 방화벽에서 접근 출처를 제한하고 필요한 접근 제어를 설정하세요. 처음 테스트할 때는 LAN을 열거나 모든 고급 옵션을 켤 필요가 없습니다. 서버가 아직 없어도 인터페이스, 설정 저장, 로그 창은 정상적으로 작동해야 합니다. 커널이 시작되지 않으면 경로, 권한, 의존성부터 확인하세요. 구독 업데이트로 로컬 실행 환경 문제를 해결할 수는 없습니다.

간단한 기본 상태 기록을 남겨 두세요. 시스템 종류, 클라이언트 버전 계열, 설정 저장 위치, 수신 입구, 현재 권한 방식을 기록하면 됩니다. 계정, 구독 주소, 서버 인증 정보는 적지 마세요. 나중에 업데이트하거나 기기를 옮길 때 프로그램 실행 문제와 프록시 연결 문제를 구분하는 데 도움이 됩니다. 설치가 끝났다고 설정이 완료된 것은 아닙니다. 환경을 안정적으로 유지해야 이후 변경 사항을 비교할 기준을 확보할 수 있습니다. 버튼을 누르는 순서는 빠른 시작 가이드를 참고하세요.

구독 가져오기: 그룹 관리, 업데이트, 설정 확인

가져올 항목이 구독 주소인지 공유 링크인지 먼저 확인

구독 주소는 보통 네트워크를 통해 설정을 가져오는 링크이고, 공유 링크는 vmess://, vless://, trojan://, ss:// 등으로 시작하는 경우가 많습니다. 복사하기 전에 제공된 항목이 어느 쪽인지 확인하세요. 구독 관리 페이지 주소를 구독 주소로 사용하거나 로그인 페이지 내용을 서버 목록으로 착각하지 마세요. 주소에 계정 식별 정보나 접근 매개변수가 포함될 수 있으므로 민감 정보로 취급하고 공개 댓글, 스크린샷, 단체 채팅방에 올리지 마세요.

v2rayN에서는 먼저 구독 그룹 관리로 이동해 알아보기 쉬운 그룹을 만든 뒤 구독 주소를 입력하고 저장하세요. 다음으로 해당 그룹을 업데이트하고 결과와 서버 목록을 확인하세요. 가져오기를 반복해서 누를 필요는 없습니다. v2rayNG에서는 구독 설정에 주소를 추가한 뒤 해당 메뉴에서 구독을 업데이트할 수 있습니다. 화면 버전에 따라 메뉴 이름은 다를 수 있지만 순서는 같습니다. 먼저 주소를 저장한 다음 내용을 가져오세요. 서버 하나만 있는 공유 링크는 클립보드에서 가져오면 되므로 별도의 네트워크 구독을 만들 필요가 없습니다.

가져온 뒤 연결에 영향을 주는 필드 확인

목록에 서버가 표시되면 설정 하나를 선택해 편집 항목을 확인하세요. 주소, 포트, 사용자 ID 또는 비밀번호, 프로토콜, 전송 방식, 보안 설정을 중점적으로 살펴봅니다. WebSocket을 사용한다면 경로와 Host를, gRPC라면 서비스 이름을 확인하세요. TLS에서는 서버 이름과 인증서 검증 옵션을, REALITY에서는 공개 키, 짧은 ID, 필요한 지문 등의 필드를 확인합니다. 필수 항목은 서버 설정에 따라 다르므로 빈칸이 보인다고 흔히 쓰이는 값을 임의로 넣으면 안 됩니다.

가져오는 중 '지원하지 않는 형식' 오류가 나면 복사한 내용에 설명 문구나 앞뒤 공백이 섞였는지, 채팅 앱이 내용을 잘라냈는지 먼저 확인하세요. 구독에서 로그인 페이지나 오류 메시지, 다른 클라이언트 전용 형식이 반환되어도 파싱에 실패할 수 있습니다. 페이지가 열린다는 사실과 설정을 읽을 수 있다는 사실을 구분하세요. 형식 변환이 필요하다면 호환 범위를 명확히 안내하는 신뢰할 수 있는 방법을 우선 사용하세요. 변환 서비스가 구독 전체 내용을 볼 수 있으므로 민감한 주소를 출처 불명의 웹사이트에 제출하지 마세요.

구독 업데이트 실패가 서버 전체의 연결 불가를 뜻하지는 않습니다

구독 업데이트는 별도의 HTTP 요청 흐름이므로 DNS, 인증서, 네트워크 상태, 접근 권한의 영향을 받을 수 있습니다. 기존 서버에 연결할 수 있다면 먼저 목록을 보존하고 구독 업데이트 로그를 확인하세요. 일부 클라이언트는 프록시를 통해 업데이트할 수 있습니다. 직접 연결로 구독 출처에 접근할 수 없지만 이미 사용 가능한 프록시가 있는 경우에 유용합니다. 그러나 처음 설치해 아직 사용할 출구가 없다면 이 옵션만으로 문제를 모두 해결할 수는 없습니다. 시간 오차가 보안 연결에 영향을 줄 수 있으므로 기기 시각도 확인하세요.

업데이트 전에 해당 그룹의 교체 방식을 확인하는 것이 좋습니다. 구독에서 생성된 항목은 다음 업데이트 때 다시 만들어질 수 있어 수동으로 바꾼 이름, 설정, 순서가 유지되지 않을 수 있습니다. 임시 수정이 필요하면 별도의 수동 그룹에 복사하고 용도를 명확히 표시하세요. 테스트 항목을 주 사용 목록에 섞지 마세요. 구독 출처 삭제와 이미 가져온 서버 삭제는 서로 다른 작업일 수 있으므로 정리 전에 확인 메시지를 읽으세요. 서버 이름의 기호에 의존하기보다 출처나 용도별로 그룹을 나누면 관리하기 쉽습니다.

가져오기를 마치면 설정이 분명한 서버 하나만 기준으로 선택하고, 우선 여러 서버를 번갈아 사용하지 마세요. 그룹과 현재 선택 항목, 업데이트 출처를 확인한 뒤 다음 장에서 앱 연결을 검증합니다. 컴퓨터와 Android에서 호환되는 구독 출처를 함께 사용할 수 있지만 로컬 라우팅, 앱 목록, 권한은 각각 확인해야 합니다. 기기 간 설정 동기화는 여러 기기에서 설정 동기화하기를 참고하세요. '구독 업데이트 성공'만으로 프록시 연결 전체가 검증된 것은 아닙니다.

프록시 모드: 앱 연결과 출구 선택은 별도로 설정

시스템 프록시는 일부 앱의 연결만 처리합니다

데스크톱 시스템 프록시는 시스템 설정을 따르는 앱에 요청을 전달할 로컬 프록시 입구를 알려 줍니다. 브라우저는 대체로 시스템 설정을 읽지만 명령줄 도구, 게임, 일부 데스크톱 앱은 자체 연결 방식을 사용할 수 있습니다. 따라서 시스템 프록시를 켠 뒤 앱이 계속 직접 연결되더라도 서버가 고장 났다고 단정할 수 없습니다. 먼저 앱이 시스템 프록시를 지원하는지, 별도의 프록시나 우회 목록이 설정되어 있는지 확인하세요. 그다음 앱 내부 설정을 사용하거나 이후 장에서 다룰 TUN 연결을 고려하면 됩니다.

v2rayN의 일반적인 시스템 프록시 옵션은 해제, 자동 설정, 시스템 프록시 변경 안 함입니다. '해제'는 관련 시스템 프록시 설정을 제거하고, '자동 설정'은 지원되는 시스템 프록시를 로컬 입구로 지정합니다. '변경 안 함'은 클라이언트가 현재 시스템 설정을 수정하지 않는다는 뜻이지, 시스템에 프록시가 없다는 뜻은 아닙니다. 이전에 다른 프로그램이 설정한 주소가 남아 있을 수 있습니다. 클라이언트를 종료한 뒤 웹페이지가 열리지 않는다면 시스템 프록시가 중지된 로컬 포트를 가리키는지 확인하세요.

전역 및 우회 규칙이 연결된 트래픽의 출구를 결정합니다

라우팅 모드는 별도의 설정 계층입니다. 일반적인 전역 프록시는 커널에 들어온 트래픽을 프록시 출구로 전달합니다. 중국 본토 우회 같은 사전 설정은 도메인과 주소 분류에 따라 직접 연결하거나 프록시를 사용합니다. 여기서 '전역'은 운영체제의 모든 프로세스를 처리한다는 보장이 아닙니다. 커널로 들어오지 않은 트래픽을 규칙이 자동으로 포착할 수는 없습니다. 시스템 프록시는 '들어오는지'를, 라우팅은 '들어온 뒤 어디로 가는지'를 결정하며 둘을 함께 설정해야 최종 동작이 정해집니다. 사전 설정의 구체적인 규칙은 클라이언트에서 확인하세요.

직접 연결은 클라이언트를 끄는 것과 다릅니다. 규칙에서 직접 연결을 선택해도 트래픽은 이미 커널에 들어와 있을 수 있으며, 출구 단계에서 기기가 목적지에 직접 연결하는 방식입니다. 차단은 조건에 맞는 요청을 명시적으로 거부하는 것으로, 연결 시간 초과와는 다릅니다. 문제를 해결할 때는 잠시 단순한 라우팅 모드로 바꿔 동작을 비교할 수 있지만 테스트가 끝나면 원래 설정으로 되돌리세요. 임시 전역 모드를 장기 해결책으로 사용하면 안 됩니다. 전역 모드에서는 되지만 분할 라우팅에서 실패한다면 같은 구독을 다시 가져오기보다 규칙과 DNS를 확인하세요.

반복 가능한 테스트 한 번으로 연결 여부 확인

확인할 때는 TUN을 끈 상태로 유지하고 커널을 시작한 뒤 시스템 프록시를 켜세요. 시스템 설정을 따르는 것이 분명한 브라우저로 확인된 목적지에 접속합니다. 로그나 연결 정보에 해당 목적지가 표시되는지도 살펴보세요. 브라우저의 기존 연결, 캐시, 자체 보안 DNS 설정이 결과에 영향을 줄 수 있으므로 새 연결을 만들거나 앱을 재시작해 비교하세요. 로컬 HTTP 입구를 지정해 테스트하려면 아래 명령을 사용할 수 있습니다. 단, 포트를 클라이언트가 실제로 수신 중인 포트로 바꾸고 해당 입구가 HTTP 프록시를 지원하는지 확인해야 합니다.

curl --proxy http://127.0.0.1:10809 --head https://example.com/

이 명령은 지정한 입구를 통해 목적지에 요청을 보내는지만 확인하며 시스템 프록시 설정은 바꾸지 않습니다. 예시 포트는 모든 클라이언트의 기본값이 아닙니다. 프록시 연결이 거부되면 먼저 로컬 수신 상태를 확인하세요. 프록시에 연결된 뒤 응답이 시간 초과되면 서버, DNS, 원격 접속을 확인하세요. 목적지에 따라 HEAD 요청에 특별한 응답을 보낼 수 있으므로 HTTP 오류 코드가 표시되어도 프록시 실패라고 단정할 수 없습니다. 연결 과정을 함께 살펴보세요. 명령줄 도구가 없다면 앱 자체의 프록시 설정으로 같은 방식의 비교 테스트를 할 수 있습니다.

Android는 일반적으로 시스템 VPN 인터페이스로 트래픽을 연결하며, 앱별 프록시나 LAN 우회 옵션에 따라 적용 범위가 달라집니다. 데스크톱의 시스템 프록시 옵션을 Android에 그대로 적용하지 마세요. 일부 앱에서만 문제가 생긴다면 해당 앱이 프록시 적용 대상인지, 시스템에서 백그라운드 실행을 제한하는지, 다른 VPN 서비스와 충돌하는지 확인하세요. 모드 차이는 시스템 프록시와 라우팅 모드의 차이를 참고하세요. 먼저 재현 가능한 결과를 확보한 뒤 세부 라우팅을 조정하세요.

라우팅 설정: 규칙 순서, DNS, 출구 태그

규칙 추가 전에 매칭 순서부터 이해하기

라우팅 규칙은 일반적으로 순서대로 확인하며, 먼저 일치하는 규칙이 출구를 결정합니다. 어떤 규칙에도 일치하지 않는 연결은 기본 정책을 따릅니다. 구체적인 필드 조합과 매칭 동작은 커널 설명서를 기준으로 해야 하며 규칙 목록을 단순한 태그 모음으로 보면 안 됩니다. 범위가 넓은 프록시 규칙을 앞에 두면 뒤쪽의 세부 직접 연결 규칙이 매칭되지 않을 수 있습니다. 처음에는 필요한 LAN 처리, 명시적인 도메인 예외, 지역 규칙, 기본 출구만 간결하게 구성하고 하나씩 검증한 뒤 확장하세요.

도메인 규칙과 IP 규칙은 서로 다른 정보에 의존합니다. 클라이언트가 원래 도메인을 알고 있다면 도메인 규칙으로 직접 매칭할 수 있지만 목적지 IP만 받은 경우에는 도메인 규칙에 필요한 정보가 부족할 수 있습니다. DNS 해석 결과는 IP 분류에도 영향을 주므로 DNS와 라우팅을 하나의 흐름으로 확인해야 합니다. 웹사이트에 한국어가 표시된다는 이유만으로 직접 연결 대상으로 분류하지 마세요. 웹사이트 도메인, 콘텐츠 전송 네트워크, 서버 위치 사이에 고정된 관계는 없습니다. 지역 규칙은 관리되는 데이터셋이지 실시간 측정 결과가 아닙니다.

설정 조각은 올바른 계층에 넣어야 합니다

아래는 Xray 라우팅 객체를 설명하기 위한 예시이며, 그대로 실행할 수 있는 완전한 설정은 아닙니다. 사설 주소 직접 연결, 지정 도메인 직접 연결, 지역 규칙의 순서를 보여 줍니다. 사용하기 전에 현재 설정에 direct라는 출구가 있고 필요한 geosite, geoip 데이터 파일이 설치되어 있는지 확인하세요. GUI 클라이언트에 규칙 편집 화면이 있다면 실행 중 자동 생성되는 설정을 직접 수정하기보다 화면에서 추가하는 것이 좋습니다. 기본 출구가 포함된 전체 설정을 모르면 이 조각만으로 모든 트래픽의 경로를 판단할 수 없습니다.

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

geosite:cn → direct는 해당 도메인 집합과 일치하는 트래픽을 직접 연결 출구로 보내며, geoip:cn은 주소 집합을 대상으로 합니다. domain:example.com은 도메인 접미사 유형의 매칭으로, 보통 해당 도메인과 하위 도메인을 포함합니다. 임의의 위치에 문자열이 포함되는지 판단하는 규칙은 아닙니다. AsIs는 라우팅 매칭을 위해 도메인을 IP로 변환하지 않으므로 도메인으로 들어온 요청은 지역 IP 규칙만으로 출구가 바뀌지 않을 수 있습니다. 다른 해석 정책을 선택하기 전에 적용 조건과 조회 비용을 먼저 확인하세요.

스니핑, DNS, 예외 규칙의 범위

트래픽 스니핑은 일부 프로토콜에서 도메인 정보를 복원하는 데 도움이 될 수 있지만 모든 요청을 알아내는 것은 아니며 앱 암호화를 우회하는 범용 방법도 아닙니다. 앱 자체 DNS, 암호화된 DNS, IP 직접 연결을 사용하면 라우팅에서 확인할 수 있는 정보가 달라질 수 있습니다. 스니핑이나 DNS를 조정한 뒤에는 웹페이지가 열리는지만 보지 말고 같은 목적지에 대한 규칙 매칭 결과가 달라졌는지 확인하세요. 클라이언트에 연결 상세 정보가 있다면 실제 목적지, 매칭 규칙, 출구를 우선 살펴보세요. 일반 로그 수준에서는 모든 정보가 기록되지 않을 수 있습니다.

예외 규칙을 추가할 때는 가능한 한 범위가 좁은 도메인이나 주소를 사용하고 적절한 위치에 배치하세요. 넓은 주소 범위를 직접 연결하면 관계없는 서비스까지 포함될 수 있고, 도메인 전체를 프록시로 보내면 LAN 리소스 접속이 달라질 수 있습니다. 규칙을 수정한 뒤 저장하고 적용한 다음 새 연결을 만드세요. 기존 연결은 규칙이 즉시 다시 적용되지 않을 수 있습니다. 분할 라우팅이 실패하면 마지막 규칙을 먼저 되돌리고 데이터 파일이 있는지, 태그가 정확한지, 도메인에 프로토콜이나 경로가 붙어 있지 않은지 확인하세요. 규칙 필드에는 보통 전체 웹 주소가 아닌 도메인만 입력합니다.

TUN 모드: 트래픽 처리 범위 확대와 루프 방지

TUN은 어떤 경우에 필요한가요?

TUN은 가상 네트워크 인터페이스로 IP 트래픽을 받아 시스템 프록시를 읽지 않거나 앱별로 프록시를 설정하기 어려운 앱을 처리하는 데 적합합니다. 클라이언트로 트래픽이 들어오는 방식을 바꾸는 기능이지, 잘못된 서버 매개변수를 고치거나 서버에 새 프로토콜 지원을 추가하는 기능은 아닙니다. 일반 브라우저와 프록시를 지원하는 개발 도구가 이미 잘 작동한다면 우선 시스템 프록시를 유지하세요. 앱 연결 범위에 문제가 명확하게 있을 때만 TUN을 추가해야 문제 해결 범위를 줄일 수 있습니다.

데스크톱 TUN은 가상 인터페이스, 라우팅 테이블, DNS 처리, 높은 권한을 포함할 수 있으며 구체적인 구현은 클라이언트와 선택한 커널에 따라 다릅니다. v2rayN GUI가 서로 다른 커널이나 보조 구성 요소를 조정할 수 있으므로 TUN 설정 하나가 모든 Xray 설정에 공통으로 적용되는 필드라고 보면 안 됩니다. 커널을 바꾸기 전에 현재 서버, 보안 방식, 라우팅, DNS를 새 커널에서도 지원하는지 확인하세요. 설정을 가져올 수 있다는 것과 실행 시 의미가 같다는 것은 별개입니다. 특히 서로 다른 커널 계열의 원본 설정 파일을 그대로 교환하지 마세요.

모든 옵션을 한꺼번에 켜지 말고 단계별로 활성화

TUN을 켜기 전에 시스템 프록시나 앱에서 지정한 프록시로 같은 서버가 작동하는지 확인하세요. 설정을 백업하고 다른 VPN이나 트래픽 처리 도구를 종료한 다음 진행합니다. 클라이언트 안내에 따라 필요한 서비스 설치나 권한 승인을 완료하고 TUN을 켜세요. 처음에는 권장 스택과 자동 라우팅 설정을 유지하고 MTU, DNS 주소, 앱 제외 항목을 동시에 바꾸지 마세요. 인터페이스 생성에 실패했다면 구독을 바꾸거나 서버를 한꺼번에 테스트하지 말고 권한, 남은 프로세스, 드라이버 상태부터 확인하세요.

일부 구성에서는 TUN과 시스템 프록시를 함께 사용할 수 있지만, 문제를 해결할 때는 요청이 어느 입구로 들어오는지 헷갈리지 않도록 겹치는 설정을 줄이는 것이 좋습니다. TUN을 켠 뒤 일반 웹페이지를 확인하고, 다음으로 기존에 프록시를 사용하지 않던 앱을 테스트한 다음, LAN 기기와 내부 서비스를 확인하세요. 앱 하나가 작동한다고 UDP, IPv6, 모든 DNS 요청까지 예상대로 처리된다는 뜻은 아닙니다. 이러한 기능에는 클라이언트, 커널, 서버, 네트워크 경로의 지원이 모두 필요합니다. 음성 통화나 게임에 사용한다면 실제 기능을 별도로 테스트하세요.

DNS, 루프백, LAN 예외

DNS를 처리할 때는 요청이 업스트림 서버에 도달해야 하며 업스트림으로 향하는 연결이 자신에게 반복해서 잡히지 않도록 해야 합니다. 클라이언트가 서버에 연결하는 트래픽도 올바르게 제외하거나 출구 인터페이스에 연결해야 합니다. 그렇지 않으면 루프가 생겨 시작 후 연결이 쌓이거나 CPU 사용량이 비정상적으로 높아지고 네트워크 전체가 끊길 수 있습니다. 이때는 TUN을 먼저 끄고 정상 상태로 복구한 뒤 자동 라우팅과 출구 제외 설정을 살펴보세요. 무작위 직접 연결 규칙을 계속 추가해 문제를 덮지 마세요.

LAN 프린터, 공유 폴더, 라우터 관리 페이지, 기업 내부 주소에는 명시적인 우회 설정이 필요할 수 있지만 사설 주소 직접 연결 여부도 사용 환경에 따라 판단해야 합니다. 기업 네트워크는 특정 VPN을 통해 내부 라우팅을 제공할 수 있어 단순히 우회해도 접속할 수 있다는 보장이 없습니다. IPv6 트래픽을 처리하는지도 별도로 확인하세요. IPv4 접속만 확인해서는 다른 주소 체계의 경로를 알 수 없습니다. 일부 웹사이트에서 문제가 생기면 모든 문제를 DNS 탓으로 돌리기보다 도메인 해석 결과와 주소 체계를 비교하고 MTU나 경로 문제를 확인하세요.

TUN을 끈 뒤에는 일반 직접 연결, LAN, 절전 모드에서 깨어난 뒤의 네트워크 상태를 확인하세요. 클라이언트가 비정상적으로 종료되면 서비스나 시스템 설정이 남을 수 있습니다. 우선 정상 종료 절차로 복구하고, 필요한 경우 시스템 네트워크 관리 방법을 따르세요. Android의 일반 VPN 연결과 데스크톱 TUN은 권한과 라우팅 방식이 다르므로 데스크톱의 드라이버, 서비스, 인터페이스 절차를 그대로 적용하지 마세요. 대상 앱의 트래픽이 처리되고 내부 리소스에 접속할 수 있으며 종료 후 네트워크가 복구되는 세 가지 조건을 만족할 때 TUN을 일상적으로 사용하세요.

유지 관리: 로그, 속도 측정, 업데이트, 백업

문제가 발생한 계층부터 좁혀 가기

네트워크에 문제가 생기면 발생 시각, 네트워크 환경, 대상 앱, 마지막 변경 사항을 먼저 기록하세요. 클라이언트가 실행 중인지, 커널이 종료되지 않았는지, 로컬 입구가 충돌하지 않는지 확인한 뒤 현재 서버와 라우팅을 살펴보세요. 로그의 connection refused는 어떤 연결 대상이 연결을 거부했다는 뜻인 경우가 많지만, 대상이 로컬 입구인지 원격 서버인지는 주소를 함께 확인해야 합니다. i/o timeout은 응답을 기다리다 시간이 초과됐다는 의미일 뿐 계정 만료, 서버 중단, DNS 문제를 단독으로 입증하지는 않습니다.

핸드셰이크에 실패하면 프로토콜 매개변수, 보안 설정, 기기 시간, 서버 요구 사항을 차례로 확인하세요. 로그 한 줄은 백그라운드 상태 확인이나 이미 종료된 연결에 해당할 수 있으므로 대상 정보를 함께 보지 않고 해석하면 안 됩니다. 문제를 해결하는 동안 로그 수준을 잠시 높여 한 번 재현한 뒤 일반 수준으로 되돌리세요. 로그가 계속 쌓이지 않게 주의해야 합니다. 로그를 공유하기 전에 서버 주소, 사용자 ID, 구독 매개변수, 요청에 포함된 개인정보를 지우세요. 자세한 분석은 실행 로그 해설을 참고하세요.

속도 측정 결과는 실제 문제에 맞춰 해석

TCPing은 주로 대상 포트에 연결할 수 있는지 보여 주며 프록시 인증이나 목적지 접속까지 확인하지는 않습니다. 실제 연결 지연은 더 많은 프록시 요청 단계를 거치지만 테스트 주소, DNS, 핸드셰이크, 당시 네트워크 부하의 영향을 받습니다. 다운로드 속도 테스트는 처리량을 확인하고 실제 데이터를 사용하지만 모든 목적지와 앱의 성능을 대표하지는 않습니다. 측정 방식이 다르면 같은 기준으로 순위를 매길 수 없으며, 한 번 실패했다고 설정을 바로 삭제하지 말고 테스트 조건이 같은지 먼저 확인하세요.

비교할 때는 기기, 네트워크, 테스트 목적지, 프록시 모드를 동일하게 유지하세요. 구독을 업데이트하면서 여러 서버의 속도를 한꺼번에 측정하지 마세요. 먼저 실제 연결이 안정적으로 이루어지는지 확인하고, 그다음 앱에 필요한 처리량과 응답 속도를 살펴보세요. 백그라운드 동기화, 무선 신호 변화, 서버 측 속도 제한도 결과에 영향을 줍니다. 클라이언트 목록의 정렬은 특정 시점의 결과일 뿐입니다. 지표 차이는 지연 시간과 다운로드 속도 측정의 차이를 참고하세요. 평소에 전체 서버를 자주 측정하기보다 현재 문제와 관련된 항목만 다시 확인하는 편이 유용합니다.

업데이트와 백업은 되돌릴 수 있게 진행

업데이트 전에 클라이언트 설정을 내보내고 현재 정상 작동하는 라우팅, DNS, 사용자 지정 그룹을 저장하세요. 백업에는 유효한 인증 정보가 들어갈 수 있으므로 보호된 위치에 보관하고 일반 스크린샷이나 문서처럼 동기화하지 마세요. 클라이언트의 내보내기 및 백업 기능을 우선 사용하세요. 파일을 직접 복사해야 한다면 데이터가 기록되는 중이 아닐 때 복사할 수 있도록 클라이언트를 먼저 종료하세요. 프로그램 파일, 사용자 설정, 자동 생성된 실행 설정은 서로 다른 데이터이므로 설치 폴더만 보관해서는 환경을 완전히 복구하지 못할 수 있습니다.

다운로드 페이지에서 기존에 사용한 시스템, 아키텍처, 인터페이스 계열에 맞춰 업데이트하세요. 기존 백업은 보관하고 커널 실행, 구독 업데이트, 라우팅, TUN을 차례로 테스트합니다. 새 버전에서 설정 구조를 변환할 수 있으므로 문제가 생겼다고 이전 프로그램으로 변환된 데이터를 바로 열지 마세요. 업데이트 전 백업을 복원해야 합니다. 문제가 생겼을 때 원인을 구분하기 쉽도록 클라이언트와 커널 업데이트도 나누어 확인하세요. 분명한 이유가 없다면 막연히 '더 빠른' 성능을 기대하며 커널을 자주 바꾸지 않아도 됩니다.

평소 유지 관리는 짧은 절차로 정리할 수 있습니다. 구독 출처가 정상인지 확인하고, 더 이상 쓰지 않는 테스트 항목을 정리하고, 백업이 열리는지 확인하고, 로그가 비정상적으로 늘지 않는지 살펴보세요. 자동 시작과 구독 예약 업데이트는 설정이 안정된 뒤 켜고 절전, 네트워크 전환, 시스템 업데이트 후에도 정상인지 확인하세요. 설정을 복원한 뒤에는 항목 수만 보는 데 그치지 말고 실제 연결을 다시 검증해야 합니다. 재현하고 설명하고 되돌릴 수 있는 구성이, 검증하지 않은 옵션을 많이 켜 두는 것보다 유용합니다.

고급 활용: 재현 가능한 설정과 기기 간 이전

정상 작동하는 기본 설정부터 정리한 뒤 성능과 프로토콜 테스트

앞의 8단계를 마치면 인증 정보가 없는 설정 요약을 작성하세요. 클라이언트 계열, 사용 커널, 서버 프로토콜과 전송 방식 조합, 앱 연결 방식, 라우팅 사전 설정, DNS 정책, TUN 상태를 기록하면 됩니다. 모든 필드를 복사하는 것이 아니라 시간이 지난 뒤에도 문제를 해결할 맥락을 남기는 것이 목적입니다. 검증된 설정을 기준으로 삼고 한 번에 변수 하나만 바꾸세요. 예상 결과, 실제 결과, 복구 방법을 기록하면 여러 옵션을 기억에 의존해 연달아 바꾸는 일을 줄일 수 있습니다.

프로토콜을 고급 설정할 때는 필드 사이의 제약부터 이해해야 합니다. VLESS는 일부 프로토콜과 같은 자체 암호화 메커니즘을 제공하지 않으므로 실제 보안 수준은 선택한 보안 계층과 전체 설정에 달려 있습니다. Trojan은 일반적으로 TLS와 함께 사용하고, Shadowsocks는 양쪽의 암호화 방식과 비밀번호를 일치시켜야 합니다. VMess의 동작은 구체적인 구현과 매개변수의 영향도 받습니다. 프로토콜 이름만으로 성능이나 보안 등급을 단정할 수 없습니다. 기기 자원, 네트워크 경로, 서버 구현, 운영 방식까지 포함해 전체 구성을 평가하세요.

REALITY와 전송 설정을 조정하기 전에 호환 조건 확인

REALITY 설정은 클라이언트와 서버가 보안 매개변수에 합의해야 합니다. 신뢰할 수 있는 출처에서 서버 이름, 공개 키, 짧은 ID, 지문과 기타 필수 필드를 확인하고 커널 지원 여부도 점검하세요. 핸드셰이크에 실패하면 매개변수 누락, 시간 오류, 연결 입구 접근 여부를 먼저 확인한 다음 전송 방식 조합을 살펴보세요. 인증서 검증 건너뛰기는 잘못된 설정을 해결하는 일반적인 방법이 아닙니다. 다른 서버의 값을 복사해 시험하지 마세요. 커널을 바꾼 뒤에는 해당 필드가 제대로 유지되는지 다시 확인하세요.

전송 설정은 실제 문제를 해결할 때만 조정하세요. 연결 재사용, 동시 연결 수, MTU, DNS 캐시는 일부 환경에서 개선 효과가 있을 수 있지만 자원 사용량이나 문제 양상을 바꿀 수도 있습니다. 반복되는 핸드셰이크를 줄이려는지, 특정 앱의 응답을 개선하려는지, 네트워크 경로 문제를 해결하려는지 먼저 정하세요. 목적에 맞는 옵션을 선택한 뒤 같은 목적지와 부하로 실제 사용 환경에서 관찰하세요. 가장 좋았던 한 번의 결과만 떼어 판단하지 마세요. 반복해서 개선되지 않는 설정은 더 단순하고 관리하기 쉬운 상태로 되돌리세요.

기기 간 이전은 공유해도 되는 항목만 동기화

데스크톱과 Android에서 호환되는 구독을 함께 사용할 수는 있지만, 앱별 라우팅 목록, 로컬 수신 설정, 시스템 프록시, TUN 권한, 설정 폴더는 기기별로 다릅니다. 데스크톱의 전체 실행 설정을 휴대폰에 그대로 덮어쓰지 말고 같은 구독이라고 라우팅까지 자동으로 같아진다고 생각하지 마세요. 새 기기에 클라이언트를 별도로 설치하고 신뢰할 수 있는 같은 출처의 구독을 가져온 뒤 서버 하나부터 검증하세요. 라우팅과 DNS는 하나씩 다시 설정합니다. 새 기기에서 실제 앱 테스트를 마칠 때까지 이전 기기의 정상 작동 상태를 유지하세요.

공유 링크는 서버 몇 개를 전달할 때, QR 코드는 가까운 거리에서 가져올 때, 전체 백업은 같은 계열의 클라이언트를 복원할 때 적합합니다. 어떤 방식이든 동일하게 보호해야 합니다. 받는 사람, 전송 경로, 저장 위치를 확인하고 이전이 끝나면 임시 파일과 스크린샷을 삭제하세요. 라우팅 규칙은 적용 커널, 출구 태그, 필요한 데이터 파일을 적어 별도 문서로 관리할 수 있습니다. 민감한 매개변수는 따로 보관하세요. 형식이 다르면 필드의 의미를 먼저 비교하고 가져오기에 성공하려고 이해하지 못한 보안 설정을 삭제하지 마세요.

설정 변경은 검증 결과를 확인하고 마무리

변경할 때마다 같은 항목을 점검하세요. 커널이 정상적으로 시작되는지, 지정한 앱이 연결되는지, 목적지 경로가 규칙과 일치하는지, LAN 리소스가 정상인지, 클라이언트 종료 후 네트워크가 복구되는지 확인합니다. UDP, IPv6, TUN이 필요하다면 해당 기능을 위한 테스트를 추가하세요. 결과를 설명할 수 없다면 로그와 환경 요약을 저장하고 정상 작동 기준으로 되돌린 뒤 재현 범위를 좁히세요. 웹페이지가 한 번 열린 것으로 전체 설정을 검증했다고 볼 수 없으며, 일시적으로 작동했다고 모든 앱이 올바르게 설정된 것도 아닙니다.