V2Ray 설정 완벽 가이드

1. 핵심 개념과 연결 흐름

클라이언트, 코어, 서버의 역할

V2Ray를 설정할 때는 먼저 세 가지 구성 요소의 역할을 구분해야 합니다. GUI 클라이언트는 서버 정보를 저장하고 구독을 관리하며 설정을 보여 줍니다. 코어는 트래픽을 받아 규칙에 따라 연결을 처리하고, 원격 서버는 실제 외부 연결을 제공합니다. 클라이언트를 설치해도 로컬 환경만 준비될 뿐, 연결 가능한 서버가 자동으로 생기는 것은 아닙니다. 데스크톱에서는 v2rayN을 우선 고려하고, 모바일에서는 v2rayNG나 v2flyNG를 선택할 수 있습니다. 자세한 선택 기준은 다음 장을 참고하세요.

Project V는 관련 프록시 기술 생태계의 배경이며, V2Fly는 V2Ray 개발을 이어 가고 Xray는 같은 생태계의 또 다른 코어 계열입니다. 클라이언트 이름과 코어 이름이 일대일로 대응하는 것은 아니며, 이름만 보고 모든 프로토콜을 지원한다고 판단해서도 안 됩니다. 설정을 가져온 뒤에는 클라이언트가 어떤 코어를 사용하는지, 해당 코어가 어떤 필드를 지원하는지, 서버가 무엇을 요구하는지 확인하세요. GUI에 설정이 표시된다고 해서 코어에서 반드시 실행되는 것은 아닙니다.

프로토콜, 전송 방식, 보안 설정 구분하기

프로토콜은 클라이언트와 서버가 통신을 구성하는 방식을 말하며 VMess, VLESS, Trojan, Shadowsocks 등이 있습니다. 전송 방식은 TCP, WebSocket, gRPC처럼 데이터를 전달하는 방법입니다. TLS와 REALITY는 연결 시 보안 핸드셰이크와 관련된 설정입니다. 공유 링크에는 여러 계층의 설정이 함께 인코딩되는 경우가 많아 주소 한 줄처럼 보여도 포트, 사용자 정보, 전송 방식, 보안 설정이 포함되어 있습니다.

VLESS 자체가 완전한 암호화 전송 방식인 것은 아닙니다. TLS나 REALITY 사용 여부는 서버 설정에 따라 확인해야 합니다. REALITY는 VLESS와 나란히 선택하는 프록시 프로토콜도 아닙니다. 직접 추가할 때는 주소, 포트, 사용자 ID, 전송 방식, 서버 이름 등의 값이 서로 맞아야 합니다. VLESS를 사용하는 서버라고 해서 공용 키, 짧은 ID, 경로를 서로 바꿔 써도 되는 것은 아닙니다.

재현 가능한 기본 연결부터 만들기

일반적인 연결 흐름은 다음과 같습니다. 브라우저가 시스템 프록시 설정을 읽고 로컬 인바운드 포트로 요청을 전달하면, 코어가 라우팅 규칙에 따라 프록시 아웃바운드를 선택해 원격 서버에 연결합니다. 시스템 프록시를 무시하는 앱도 있으며, TUN은 트래픽이 들어오는 또 다른 경로를 제공합니다. 클라이언트로 들어오는 경로와 어떤 아웃바운드로 나가는지는 별개의 문제입니다. 이후 모드를 조정할 때도 이 흐름을 따라 원인을 확인하면 진입 단계 문제를 서버 문제로 오해하지 않을 수 있습니다.

첫 테스트에서는 출처가 명확한 서버 설정 하나만 사용하고, 복잡한 사용자 지정 규칙은 끈 채 클라이언트의 기본 라우팅을 적용하세요. 시스템 시간이 정확한지 확인하고 중복 실행 중인 프록시 프로세스를 종료한 다음 코어를 시작해 테스트할 사이트에 접속합니다. 연결에 성공했을 때의 모드와 로그 요약을 기록해 두면 이후 변경 사항을 기준 설정과 비교할 수 있습니다. 한 번의 속도 테스트만으로 실제 앱 접속이나 모든 전송 방식이 정상이라고 판단할 수는 없습니다.

문제 해결은 가까운 곳부터 원격 서버 방향으로 확인하세요. 로컬 인바운드가 시작되었는지, 앱이 해당 인바운드를 사용하는지, 규칙이 어떤 아웃바운드를 선택했는지, 원격 연결이 완료되었는지 순서대로 점검합니다. 로그의 시작 실패, 핸드셰이크 실패, 요청 시간 초과는 각각 다른 단계를 가리킵니다. 먼저 어느 단계에서 실패했는지 파악한 뒤 해당 설정을 수정하세요. 클라이언트를 반복해서 재설치해도 만료된 주소나 서버 매개변수 불일치는 해결되지 않는 경우가 많습니다.

2. 플랫폼과 코어에 맞는 클라이언트 선택

데스크톱에서는 v2rayN 우선

Windows, macOS, Linux 데스크톱 사용자는 v2rayN부터 시작하는 것을 권장합니다. 이 가이드에서 사용하는 구독 그룹, 서버, 매개변수, 라우팅, DNS 설정 등의 개념을 그대로 적용하기 쉽습니다. 선택 전에는 파일 크기만 보지 말고 운영체제, CPU 아키텍처, 패키지 형식을 확인하세요. 클라이언트는 무료 오픈 소스이지만 배포 패키지마다 필요한 런타임과 시스템 통합 방식이 다를 수 있으므로 설치 전에 플랫폼별 안내를 확인해야 합니다.

Windows 다운로드 페이지에는 Desktop 버전과 클래식 WPF 버전이 있습니다. Desktop은 크로스 플랫폼 UI를 사용하므로 여러 데스크톱 운영체제에서 비슷한 방식으로 사용하고 싶은 경우에 적합합니다. WPF는 Windows용 클래식 UI입니다. 두 버전은 프로토콜이 다른 것이 아니며, Desktop 버전의 서버 속도가 더 빠르다는 뜻도 아닙니다. 한 가지 버전을 골라 설정을 마친 뒤, 문제 해결을 위해 두 UI를 동시에 실행해 시스템 프록시를 서로 차지하게 하지 마세요.

모바일은 설정 호환성을 기준으로 선택

Android에서는 Xray 코어를 사용하는 v2rayNG를 우선 추천하며, V2Fly 코어 계열의 대안으로 v2flyNG를 선택할 수 있습니다. 기본 사용 흐름은 설정 가져오기, 서버 선택, 연결 시작으로 비슷하지만 프로토콜 구현과 필드 지원까지 완전히 같지는 않습니다. 특히 REALITY나 특정 전송 매개변수가 포함된 설정은 선택한 코어의 지원 여부를 먼저 확인하세요. 링크를 읽어 들일 수 있다고 해서 호환된다고 단정하지 마세요.

대부분의 최신 Android 기기에서는 arm64 패키지를 선택하지만, 기기 구매 연도만으로 아키텍처를 판단할 수는 없습니다. 일부 기기는 64비트 하드웨어를 지원해도 시스템 환경은 다를 수 있으므로, 확실하지 않다면 기기 정보를 확인하거나 범용 버전을 사용하세요. 범용 버전은 여러 아키텍처를 지원하는 대신 파일 크기가 더 클 수 있습니다. 설치에 실패하면 클라이언트를 바꾸기 전에 아키텍처, 시스템 요구 사항, 서명이 다른 기존 앱의 설치 여부를 확인하세요.

코어를 바꿔도 서버 설정 확인은 필요합니다

v2rayN에서는 배포 패키지와 기능 지원 여부에 따라 여러 코어를 선택할 수 있으며, 대표적으로 Xray와 sing-box가 있습니다. 코어를 바꾸기 전에 현재 설정을 대상 코어가 표현할 수 있는지 확인하세요. 특히 라우팅, DNS, TUN 설정을 살펴봐야 합니다. 코어마다 지원하는 JSON 필드가 다르고 GUI 설정을 변환하는 방식도 다를 수 있습니다. 한 코어의 전체 설정을 다른 코어의 사용자 지정 설정 입력란에 그대로 붙여 넣지 마세요.

기본 연결을 설정할 때는 해당 서버 유형에 맞춰 클라이언트가 제공하는 일반적인 코어 선택을 우선 사용하세요. 명확한 호환성 문제가 있거나 특정 기능이 필요할 때만 다른 코어 계열을 시도합니다. 코어를 바꾼 뒤에는 연결을 재시작하고 실제 생성된 설정과 로그를 다시 확인해 프록시 인바운드, 규칙, DNS가 기본값으로 되돌아가지 않았는지 살펴보세요. 화면에 같은 서버 이름이 표시되어도 실제 연결 흐름은 달라질 수 있습니다.

여러 기기에서 사용할 때는 버튼 이름을 통일하려 하기보다 설정의 의미를 기억해 두세요. 데스크톱에서는 시스템 프록시를 통해 브라우저를 연결할 수 있지만, Android는 보통 시스템 VPN 인터페이스로 앱 트래픽을 받습니다. 운영체제마다 권한 부여와 제한이 다릅니다. 다운로드는 다운로드 센터에서 확인하세요. Desktop과 WPF UI의 차이는 Desktop 버전과 WPF 버전 비교에서 살펴본 뒤 버전을 정하고 설치 단계로 넘어가세요.

3. 설치 및 첫 실행 점검

설치 전 아키텍처, 디렉터리, 기존 설정 확인

설치의 목표는 코어를 정상적으로 시작하고 설정을 저장하며 필요한 권한을 요청할 수 있는 클라이언트 환경을 만드는 것입니다. 실행 중인 클라이언트를 종료하고 보관할 서버 및 라우팅 설정을 백업한 뒤 다운로드 센터에서 알맞은 패키지를 선택하세요. 데스크톱 설정 디렉터리에 현재 사용자의 쓰기 권한이 있어야 합니다. 압축 파일 형태로 배포된 경우에는 모두 압축을 푼 뒤 실행하세요. 압축 프로그램에서 주 프로그램만 임시로 열면 안 됩니다.

마이그레이션과 첫 설치를 동시에 진행하지 마세요. 새 환경을 먼저 시작해 창이 정상적으로 열리고 기본 설정이 저장되는지 확인한 다음 기존 설정을 가져오세요. 이전 디렉터리 전체를 그대로 덮어쓰면 오래된 코어 파일, 포트 설정, 사용자 지정 매개변수까지 함께 가져올 수 있습니다. 설치 프로그램이 프로그램 파일을 관리한다면 해당 설치 절차를 따르세요. 독립 디렉터리 방식이라면 폴더 안 파일의 구성을 유지해 출처가 다른 코어와 UI 파일을 섞지 않도록 합니다.

Windows 및 macOS 첫 실행

Windows 사용자는 v2rayN을 실행한 뒤 런타임 누락이나 코어 시작 실패 알림이 표시되는지 확인하세요. 런타임 관련 알림이 나오면 해당 배포 패키지의 안내에 따라 처리하고, 파일 누락을 관리자 권한으로 덮으려 하지 마세요. 일반적인 시스템 프록시 설정에는 관리자 권한으로 계속 실행할 필요가 없습니다. TUN이나 시스템 수준 네트워크 설정에는 별도의 권한 상승이 필요할 수 있습니다. 권한, 런타임, 포트 사용 중은 서로 다른 문제이므로 각각 확인해야 합니다.

macOS 사용자는 '이 Mac에 관하여'에서 칩 종류를 확인한 뒤 Apple Silicon 또는 Intel 패키지를 선택하세요. 안내에 따라 앱을 일반적인 응용 프로그램 폴더로 옮긴 후 처음 실행합니다. 시스템이 확인되지 않은 개발자의 앱 실행을 차단하면 먼저 다운로드 출처를 확인한 뒤 '시스템 설정 → 개인정보 보호 및 보안'에서 해당 앱의 허용 옵션을 살펴보세요. 앱 하나를 실행하려고 시스템 전체 보안 기능을 끄지 마세요.

권한을 승인한 뒤에도 네트워크 관련 작업이 시스템에서 거부되지 않았는지 확인하세요. 앱이 열린다고 해서 시스템 프록시 변경이나 가상 네트워크 어댑터 시작 권한까지 확보된 것은 아닙니다. 실제 안내에 따라 필요한 작업을 허용하고 변경 후 연결을 다시 시작하세요. '앱이 손상되었습니다'라는 알림도 항상 권한 문제인 것은 아닙니다. 먼저 아키텍처에 맞는 설치 패키지를 다시 다운로드하고 설치 과정을 확인하세요. 자세한 방법은 macOS 설치 및 권한 문제 해결을 참고하세요.

Linux 및 Android 설치 시 확인할 점

Linux 사용자는 배포판의 패키지 시스템에 맞춰 deb 또는 rpm을 선택한 다음 x64와 arm64를 확인하세요. 시스템 패키지 도구를 우선 사용하면 의존성과 프로그램 파일을 일반적인 절차에 따라 설치할 수 있습니다. 데스크톱 세션, 권한 상승 도구, 시스템 프록시 통합 방식은 환경마다 다를 수 있습니다. 프로그램 창은 정상적으로 열리지만 시스템 프록시가 작동하지 않는다면 앱 하나에 로컬 프록시를 직접 설정해 UI 실행 문제와 시스템 통합 문제를 구분해 보세요.

Android에 v2rayNG 또는 v2flyNG를 설치할 때 현재 다운로드 앱이나 파일 관리자에 앱 설치 권한을 허용하라는 메시지가 표시될 수 있습니다. 권한은 현재 작업에 필요한 범위로 제한하세요. 기존 앱 위에 설치할 수 없다면 패키지 아키텍처나 서명 차이를 먼저 확인하고, 백업한 다음 삭제 여부를 결정하세요. 처음 연결을 시작할 때는 시스템 VPN 권한 요청이 표시되는 경우가 많으며, 승인해야 앱 트래픽을 받을 수 있습니다. 백그라운드 배터리 제한은 연결이 안정된 뒤 별도로 확인하세요.

처음 종료하기 전에 시스템 프록시 설정이 남아 있는지 확인하세요. 일부 클라이언트는 창을 닫아도 트레이로 최소화되어 코어가 계속 실행되고, 다른 클라이언트는 종료 시 프로세스를 끝내지만 오류로 인해 프록시 설정을 복구하지 못할 수 있습니다. 다시 실행해 실제 상태를 확인하고 로컬 인바운드 포트를 기록해 두세요. 이후 문제 해결 시 기본 포트를 기억에 의존하는 대신 이 포트로 앱이 올바른 인바운드에 연결되었는지 확인할 수 있습니다.

4. 구독 가져오기 및 서버 관리

구독 주소와 공유 링크 구분하기

구독 주소는 여러 서버를 가져오고 업데이트하는 데 사용하며, 공유 링크는 보통 서버 한 대의 설정을 설명합니다. 둘 다 긴 문자열처럼 보일 수 있지만 가져오는 메뉴는 다릅니다. 받은 정보가 어느 유형인지 먼저 확인하세요. 웹페이지 소개 주소를 구독 주소로 사용하거나 VLESS 공유 링크 하나를 구독 다운로드 입력란에 넣지 마세요. QR 코드는 텍스트를 담는 수단일 뿐이므로 스캔한 뒤 구독인지 단일 설정인지 확인해야 합니다.

v2rayN에서는 구독 그룹 메뉴로 이동해 그룹 이름과 구독 주소를 추가하고 저장한 뒤 업데이트하세요. 그룹 이름은 연결 품질이 아니라 출처나 용도를 기준으로 정하는 것이 좋습니다. v2rayNG와 v2flyNG에서는 구독 설정이나 해당 가져오기 메뉴에서 주소를 저장한 후 설정을 업데이트합니다. 메뉴 이름은 조금 다를 수 있지만 순서는 같습니다. 출처를 등록하고 설정을 가져온 다음 결과를 확인하고 사용할 서버를 선택하세요.

업데이트 후에는 목록만 보지 말고 필드를 확인하세요

업데이트가 끝나면 서버가 예상한 그룹에 실제로 추가되었는지 확인한 뒤 프로토콜, 주소, 포트, 전송 방식, 보안 매개변수를 살펴보세요. 목록에 표시되는 메모는 서버를 구분하기 위한 것이지 연결 가능성을 보장하지 않습니다. 구독 업데이트 과정에서 기존 항목이 바뀔 수 있으므로 이전에 선택한 서버가 무효가 되거나 위치가 달라질 수 있습니다. 업데이트 후 현재 선택된 항목을 다시 확인해 삭제되었거나 현재 코어와 호환되지 않는 설정을 계속 사용하지 않도록 하세요.

공유 링크는 클립보드에서 가져오기 메뉴로 추가할 수 있습니다. 복사할 때 전체 문자열을 포함하고, 메신저가 끝부분 매개변수를 자르거나 설명 문구까지 함께 복사하지 않도록 주의하세요. 각 필드의 의미를 명확히 아는 경우에는 직접 추가할 수 있지만, 완전한 공유 링크가 있다면 먼저 가져온 뒤 항목별로 확인하는 편이 좋습니다. 경로, 서버 이름, 공용 키, 짧은 ID 등을 빠뜨릴 가능성을 줄일 수 있습니다.

구독 정보와 단일 서버 설정은 각각 안전하게 관리하세요. 주소에 포함된 토큰, 사용자 ID, 인증 정보로 다른 사람이 서비스를 조회하거나 이용할 수 있습니다. 공개 스크린샷, 로그 게시물, 예제 코드에 넣지 마세요. 문제 해결 담당자에게 공유할 때는 필드 이름과 오류 메시지만 남기고 실제 주소와 사용자 정보를 숨기세요. 구독 정보가 유출되면 클라이언트에서 해당 줄을 삭제하는 데 그치지 말고 서비스 제공업체에서 다시 발급하거나 취소해야 합니다.

가져오기, 파싱, 실행 단계로 나누어 업데이트 문제 해결

첫 번째는 가져오기 실패입니다. 구독 도메인이 확인되는지, 주소가 만료되지 않았는지, 시스템 시간이 정확한지, 응답 내용이 로그인 페이지로 바뀌지 않았는지 확인하세요. 두 번째는 파싱 실패입니다. 텍스트 형식과 인코딩, 프로토콜 유형이 현재 클라이언트에서 지원되는지 살펴보세요. 세 번째는 실행 실패입니다. 항목은 가져왔지만 코어가 일부 필드를 지원하지 않거나 서버에 연결하지 못한 경우입니다. 세 가지 실패는 해결 방법이 다르므로 모두 '구독 오류'로 뭉뚱그리지 마세요.

처음 가져올 때는 아직 프록시 연결이 설정되지 않아도 구독을 업데이트할 수 있도록 '프록시를 사용하지 않고 구독 업데이트'를 시도해 볼 수 있습니다. 구독 주소에 프록시 연결이 꼭 필요하다면 먼저 다른 정상 서버를 확보한 뒤 프록시를 통한 업데이트를 실행하세요. 모든 주소에 공통으로 적용되는 고정 옵션은 없습니다. 업데이트 요청이 교체 중이거나 이미 만료되었거나 자기 자신을 가리키는 연결에 의존하지 않도록 하는 것이 중요합니다.

출처가 여러 곳이라면 그룹별로 관리해 항목을 자주 복사해 섞다가 출처 정보가 사라지지 않도록 하세요. 자동 업데이트를 사용하기 전에 덮어쓰기 동작과 수동으로 변경한 메모나 매개변수가 다시 생성되는지 확인합니다. 계속 실패하면 정상 작동하는 설정을 하나 보관하고 자동 업데이트를 일시 중지한 뒤 구독 업데이트 실패 자가 점검 방법에 따라 응답 내용과 업데이트 방식을 확인하세요. 이 단계를 마친 다음 프록시 인바운드를 설정하면 문제 범위를 좁히기 쉽습니다.

5. 시스템 프록시 모드와 앱 인바운드

모드는 인바운드를 제어하며 모든 아웃바운드를 결정하지 않습니다

시스템 프록시 모드는 운영체제가 앱에 프록시 설정을 제공하는 방법을 결정하고, 라우팅 규칙은 코어로 들어온 요청을 직접 연결할지 프록시로 보낼지 결정합니다. '시스템 프록시 자동 설정'을 켜면 브라우저가 로컬 인바운드를 사용하기 시작할 수 있지만, 라우팅 규칙에 따라 요청이 직접 연결될 수도 있습니다. 따라서 '시스템 프록시가 켜짐'과 '모든 트래픽이 서버를 통해 전달됨'은 같은 상태가 아닙니다. 테스트할 때 앱 인바운드와 실제 아웃바운드를 각각 확인하세요.

v2rayN에는 시스템 프록시 해제, 시스템 프록시 자동 설정, 시스템 프록시 변경 안 함 등의 옵션이 있습니다. 해제는 운영체제의 현재 프록시 설정을 제거하고, 자동 설정은 클라이언트의 로컬 주소와 포트를 기록합니다. 변경 안 함은 운영체제의 기존 설정을 유지합니다. 마지막 옵션은 남아 있는 포트를 자동으로 정리하지 않으므로 시스템이 이미 종료된 다른 클라이언트를 가리키고 있으면 앱 연결이 계속 실패할 수 있습니다.

앱에 직접 설정한 프록시와 시스템 프록시를 따로 테스트

모든 앱이 시스템 프록시를 읽는 것은 아닙니다. 일부 앱은 별도의 HTTP 또는 SOCKS 설정을 제공하고, 일부는 실행 시점의 환경 설정만 읽으므로 시스템 설정을 바꾼 뒤 앱을 재시작해야 합니다. 먼저 시스템 프록시를 지원하는 브라우저를 테스트 대상으로 선택하고 확장 프로그램이나 앱 내부 설정이 덮어쓰지 않는지 확인하세요. 이후 다른 프로그램을 테스트하면 클라이언트 연결 실패와 앱이 클라이언트로 들어오지 않는 문제를 구분할 수 있습니다.

앱에 프록시를 직접 설정할 때는 보통 로컬 루프백 주소를 입력하고, 포트는 클라이언트에 표시된 실제 값으로 지정해야 합니다. 유형도 수신 인바운드와 일치해야 합니다. HTTP 인바운드와 SOCKS 인바운드는 이름만 다른 것이 아니므로 앱에서 유형을 잘못 선택하면 핸드셰이크가 실패할 수 있습니다. 인바운드가 루프백 주소에서 수신 중이라면 다른 기기에서 직접 사용할 수 없습니다. 편의를 위해 모든 네트워크 인터페이스에서 수신하도록 설정하면 로컬 프록시의 접근 범위도 넓어지므로 주의하세요.

기존 설정, 클라이언트 배포 패키지, 사용자가 변경한 값에 따라 포트가 달라질 수 있으므로 이 가이드에서는 기본 포트를 특정하지 않습니다. 로그에 주소가 사용 중이라고 나오면 다른 프록시 프로세스를 종료하고 중복 실행 여부를 확인한 뒤 포트 변경을 결정하세요. 포트를 바꾼 뒤에는 시스템 프록시나 앱 내부 설정도 함께 업데이트해야 합니다. 클라이언트 포트만 바꾸고 브라우저에 이전 포트를 남겨 두면 코어가 정상적으로 시작되어도 페이지가 열리지 않을 수 있습니다.

연결 성공 여부 확인 및 문제 상황 복구

자동 설정을 마친 뒤 연결을 시작하고, 명확한 테스트 대상에 접속하면서 해당 시점의 로그를 확인하세요. 바로 속도를 비교하기보다 연결이 수립되는지 먼저 살펴보세요. 테스트 기능마다 측정하는 대상과 단계가 다를 수 있으므로 표시된 결과를 웹사이트 접속 품질로 바로 해석하면 안 됩니다. 클라이언트에 요청 또는 라우팅 로그가 있다면 요청이 기록되었는지, 어떤 아웃바운드를 선택했는지 확인해 문제 범위를 좁히세요.

코어에 요청이 들어오지 않으면 앱 프록시 설정, 시스템 설정, 로컬 포트를 먼저 확인하세요. 요청은 들어오지만 원격 핸드셰이크가 실패한다면 서버 매개변수와 코어 호환성을 다시 살펴보세요. 핸드셰이크는 완료되었지만 대상에 접속할 수 없다면 DNS, 라우팅, 대상 서비스 상태를 확인합니다. 모든 모드를 번갈아 바꾸는 것보다 이 순서가 효율적이며, 문제 발생 지점을 설명할 수 있는 정보를 남길 수 있습니다.

Android에서는 보통 시스템 VPN 인터페이스를 통해 연결하므로 데스크톱의 시스템 프록시 메뉴를 그대로 적용하면 안 됩니다. 시스템 권한, 앱 적용 범위, 백그라운드 제한을 모바일에서 별도로 확인하세요. 먼저 앱 하나가 화면에 표시된 상태에서 정상적으로 접속되는지 확인한 다음 화면 잠금과 네트워크 전환을 테스트합니다. 인바운드가 안정된 뒤 다음 장의 라우팅 설정으로 넘어가야 앱 연결 문제를 규칙 문제로 오해하지 않습니다.

6. 라우팅과 DNS 설정

규칙 매칭 순서

라우팅의 목표는 조건에 따라 아웃바운드를 선택하는 것이지 규칙을 최대한 많이 쌓는 것이 아닙니다. 대표적인 방식으로 중국 본토 우회(Whitelist), 블랙리스트(Blacklist), 전역(Global)이 있지만 기본 규칙은 클라이언트 설정에 따라 다릅니다. 이름은 구분에 도움이 될 뿐이며, 실제 동작은 규칙 내용과 순서, 조건에 맞는 규칙이 없을 때 사용할 기본 아웃바운드에 따라 달라집니다. 라벨만 믿지 말고 적용 전에 실제 규칙을 확인하세요.

대부분의 규칙은 순서대로 매칭되며 먼저 조건을 충족하는 규칙이 뒤에 있는 규칙의 적용 여부에 영향을 줍니다. 사설 주소와 LAN은 보통 직접 연결로 명시하고, 특정 서비스 도메인은 일반 규칙보다 앞에 배치하며, 포괄적인 기본 규칙은 뒤에 둡니다. 특정 도메인이 항상 잘못된 아웃바운드로 간다면 목록 앞쪽의 도메인, 주소, 포트 조건에 이미 매칭되는지 먼저 확인하세요. 목록 끝에 규칙을 추가해도 결과가 바뀌지 않을 수 있습니다.

도메인 규칙과 주소 규칙의 입력 조건

geosite:cn은 도메인 목록 참조이고, geoip:private는 사설 주소 목록 참조입니다. 코어에서 해당 리소스를 읽을 수 있어야 합니다. 도메인 규칙은 요청에 도메인 정보가 남아 있어야 하며, 주소 규칙은 대상 IP를 기준으로 판단합니다. 앱이 로컬에서 먼저 도메인을 해석해 IP만 인바운드에 전달하면 도메인 매칭이 제한될 수 있습니다. 스니핑으로 일부 트래픽의 도메인 정보를 보완할 수 있지만 모든 프로토콜을 식별할 수 있는 것은 아닙니다.

DNS 설정은 이 연결 흐름에도 영향을 줍니다. 누가 이름을 해석하는지, DNS 요청이 어떤 아웃바운드를 통과하는지, 어떤 주소를 응답하는지가 라우팅과 연결에 함께 작용합니다. 응답을 바꾸려고 서로 중복되는 DNS 기능을 여러 개 켜지 마세요. 먼저 로컬 앱 DNS와 코어 DNS의 역할을 구분한 다음, 직접 연결용 DNS와 프록시용 DNS가 같은 상위 서버를 사용하면서 순환 의존성이 생기지 않는지 확인하세요.

기존 설정에 이해하기 쉬운 규칙 추가하기

다음은 사설 주소와 도메인 목록을 직접 연결하는 의미를 설명하기 위한 Xray / V2Ray 형식의 라우팅 일부입니다. 완전한 클라이언트 설정은 아니며, 기존 아웃바운드에 direct 태그가 있고 해당 지리 데이터 파일도 있어야 합니다. GUI 클라이언트에서는 라우팅 설정에서 같은 규칙을 만드는 것을 우선 고려하세요. 다른 코어를 사용한다면 해당 코어의 규칙 형식에 맞게 다시 작성해야 합니다.

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

AsIs는 라우팅 단계에서 주소 매칭만을 위해 도메인을 자동으로 조회하지 않는다는 뜻이지, 연결 단계에서 DNS를 전혀 사용하지 않는다는 뜻은 아닙니다. 도메인 전략에 따라 조회 시점과 주소 규칙 적용 시도가 달라집니다. 전략을 바꾸면 이전에 매칭되지 않던 주소 조건이 적용될 수 있습니다. 처음에는 기본 설정을 유지하고 어떤 매칭 정보가 부족한지 확인한 뒤 조정하세요. 특정 전략 이름을 고정적인 성능 최적화로 여기면 안 됩니다.

사용자 지정 규칙은 범위가 명확한 도메인 하나로 시작하세요. 직접 연결할지 프록시로 보낼지 정하고 로그에서 매칭 여부를 확인한 다음 도메인 목록으로 확대합니다. LAN 기기를 테스트할 때는 사설 주소, LAN 도메인, TUN 적용 여부를 함께 확인하세요. 사설 IP만 직접 연결하도록 설정해도 LAN 도메인 해석 실패는 해결되지 않을 수 있습니다. 라우팅과 DNS가 정상인지 각각 검증해야 합니다.

규칙 리소스를 업데이트하면 결과가 달라질 수 있으며 수동 규칙이 구독 설정이나 기본 템플릿과 충돌할 수도 있습니다. 수정 전후의 설정 내용을 저장하고 테스트 대상과 매칭된 아웃바운드를 기록하세요. 문제가 발생하면 가장 최근 변경 사항부터 되돌립니다. 복잡한 설정이라면 각 규칙이 무엇과 매칭되는지, 왜 그 위치에 있는지, 매칭되지 않을 때 어떻게 되는지 설명할 수 있어야 합니다. 그렇지 않으면 유지 관리 부담이 계속 커집니다.

7. TUN 가상 네트워크 어댑터와 트래픽 적용 범위

앱 프록시에서 네트워크 인바운드로 확장하기

TUN은 가상 네트워크 인터페이스로 IP 계층 트래픽을 받아 시스템 프록시를 읽지 않는 앱을 연결할 때 유용합니다. TUN은 트래픽이 들어오는 범위를 넓힐 뿐, 만료된 서버를 복구하거나 모든 앱 프로토콜이 작동하도록 보장하지 않습니다. 활성화하기 전에 기본 연결이 정상이며 현재 라우팅 설정을 이해하고 있어야 합니다. 그렇지 않으면 인바운드, DNS, 서버 문제가 한꺼번에 발생해 로그로 원인을 찾기 어려워집니다.

데스크톱 TUN은 가상 인터페이스를 만들고 시스템 라우팅을 변경하므로 권한 상승이나 관련 네트워크 구성 요소가 필요할 수 있습니다. v2rayN의 'TUN 모드 활성화'는 기능을 실행하는 진입점일 뿐, 실제 동작은 코어, 플랫폼, 설정에 따라 달라집니다. 먼저 해당 환경이 이 기능을 지원하는지 확인한 뒤 클라이언트 안내에 따라 진행하세요. 코어가 시작되지 않았거나 필요한 구성 요소가 누락된 상태에서 시스템 라우팅을 반복해서 켜고 끄지 마세요.

루프백, LAN, 다른 터널 확인

TUN을 켜기 전에 라우팅을 변경하는 다른 프록시나 VPN 프로그램을 종료해 기본 경로와 DNS를 두 프로그램이 동시에 차지하지 않도록 하세요. 가상 네트워크 어댑터가 여러 개 있다고 해서 반드시 문제가 있는 것은 아니지만, 현재 트래픽을 어느 어댑터가 받는지는 알고 있어야 합니다. 활성화한 뒤 클라이언트 로그에서 인터페이스 생성 성공 여부를 확인하고 앱 하나를 테스트한 다음 LAN 기기와 일반 직접 연결 대상을 확인하세요. 화면의 스위치 상태만 보지 마세요.

원격 서버에 연결하는 기본 트래픽이 다시 TUN 인바운드로 들어가면 루프가 발생할 수 있습니다. 클라이언트와 코어는 보통 자동 라우팅, 인터페이스 선택, 우회 설정을 제공하지만 다중 네트워크 어댑터, 핫스팟 공유, 사용자 지정 라우팅에 따라 전제가 달라질 수 있습니다. 로그에 연결 시도가 반복되고 연결이 계속되지 않는다면 먼저 TUN을 끄고 시스템 프록시 기준 상태로 돌아간 다음 외부 네트워크 어댑터와 서버 주소의 실제 라우팅을 확인하세요.

LAN에 접속하려면 사설 주소와 이름 해석을 모두 고려해야 합니다. 프린터, 라우터 관리 페이지, 네트워크 저장소에 접속할 수 없다면 먼저 LAN IP로 테스트한 다음 기기 이름으로 접속해 보세요. IP 접속도 실패하면 라우팅이나 방화벽 문제일 가능성이 높고, 이름으로만 접속하지 못하면 DNS 문제일 가능성이 큽니다. LAN 장애를 포괄적인 프록시 규칙 하나로 해결하려 하지 마세요. 로컬에서 처리해야 할 요청이 원격으로 우회될 수 있습니다.

DNS, UDP, 네트워크 전환 확인 순서

TUN 설정은 DNS 가로채기와 함께 사용하는 경우가 많지만 DNS 가로채기만으로 완전한 이름 해석 정책이 마련되는 것은 아닙니다. 시스템 질의가 어디로 전달되는지, 코어가 원격 서버를 어떻게 조회하는지, DNS 상위 서버가 프록시 연결에 의존하는지 먼저 확인하세요. 서버 주소 해석에 아직 연결되지 않은 터널이 필요하면 시작 과정에서 교착 상태가 발생할 수 있습니다. 모든 DNS를 같은 아웃바운드에 무조건 맡기기보다 최초 연결을 완료할 수 있는 해석 경로를 설정에 남겨 두세요.

브라우저에서 웹페이지가 열린다고 UDP나 모든 앱 트래픽이 정상이라는 뜻은 아닙니다. 음성 통화, 실시간 통신, 기타 앱은 각각 필요한 프로토콜을 기준으로 테스트하고 서버와 전송 방식이 해당 트래픽을 지원하는지도 확인하세요. 테스트가 실패하면 코어에 요청이 들어오는지, 올바른 아웃바운드 규칙이 적용되는지, 시스템 방화벽이 차단하는지 살펴보세요. TUN을 켰다는 이유만으로 모든 앱이 똑같이 연결된다고 기대하지 마세요.

유선에서 무선으로 전환하거나 절전 모드에서 복귀하거나 핫스팟을 바꾸면 외부 인터페이스와 DNS가 달라질 수 있습니다. 모든 규칙을 바로 다시 작성하지 말고 연결을 재시작한 뒤 테스트하세요. Android에서도 시스템 VPN 상태, 백그라운드 실행 제한, 앱 적용 범위를 확인해야 합니다. 화면에 표시된 상태, 백그라운드, 네트워크 전환의 세 상황을 모두 명확히 확인한 뒤 일상적인 사용에 적합한 인바운드 방식인지 판단하세요.

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

정상 작동 기준과 최소한의 백업 유지

평소에는 검증된 설정을 하나 보관하세요. 클라이언트 계열, 사용 코어, 구독 그룹, 프록시 모드, 라우팅 방식, 필요한 DNS 설정을 포함하면 됩니다. 복구에 필요한 정보만 백업하고 로그 전체를 장기간 설정 파일과 함께 보관하지 마세요. 내보낸 파일에 구독 인증 정보와 서버 사용자 정보가 들어 있을 수 있으므로 안전한 위치에 저장하고, 기기 간 이동 시 공개 동기화나 실수로 공유하지 않도록 주의하세요.

구독, 클라이언트, 코어, 규칙 리소스 업데이트를 가능하면 각각 따로 진행하세요. 한 번에 한 종류만 변경하고 연결을 재시작해 자주 사용하는 대상을 테스트한 뒤 다음 변경으로 넘어갑니다. 모두 동시에 업데이트하면 서버 항목, 매개변수 변환, 규칙 매칭, 프로그램 의존성 중 무엇이 원인인지 판단하기 어렵습니다. 복잡한 기록표는 필요 없지만 무엇을 왜 바꿨고 어떻게 되돌릴 수 있는지는 적어 두세요.

실패 단계에 따라 로그 읽기

코어 시작에 실패하면 설정 문법, 필드 호환성, 리소스 파일, 포트 사용 여부를 먼저 확인하세요. 시작은 정상인데 앱 요청이 없다면 인바운드를 점검합니다. 요청은 들어오지만 연결 시간이 초과되면 서버 주소, 네트워크, 아웃바운드를 확인하세요. 핸드셰이크 오류는 사용자 정보와 TLS 또는 REALITY 매개변수를 점검해야 합니다. 로그의 오류 문구는 단서일 뿐이므로 발생 시점의 작업과 함께 살펴보고, 이전 연결의 오류를 현재 설정의 문제로 단정하지 마세요.

로그를 수집해야 한다면 일시적으로 상세 수준을 높이고 명확한 작업을 한 번 재현한 뒤 평소 수준으로 되돌리세요. 로그가 너무 많으면 저장 공간을 차지하고 대상 도메인, 주소, 계정 관련 필드가 기록될 수도 있습니다. 문제 해결 자료를 제출하기 전에 인증 정보와 관련 없는 요청을 삭제하고 클라이언트 환경, 오류 발생 시간, 작업 순서, 관련 로그만 남기세요. 문제를 구체적으로 설명할수록 검증 가능한 답변을 얻기 쉽습니다.

시간, 포트, 네트워크 환경 점검

시스템 시간이 틀리면 인증서 확인이나 일부 프로토콜의 인증 과정에 영향을 줄 수 있습니다. 기기를 오래 오프라인으로 사용했거나 절전 모드에서 복귀했거나 자동 시간 동기화를 껐다면 특히 확인하세요. 포트 충돌은 중복 실행 중인 프로세스나 다른 프록시 프로그램 때문인 경우가 많으므로 정상적으로 종료한 뒤 다시 시도하세요. 포트를 바꿨다면 앱 설정도 함께 업데이트해야 합니다. 네트워크 환경이 바뀌면 새로운 DNS, 외부 인터페이스, 웹 로그인이 먼저 필요한지 확인하세요.

같은 설정이 한 네트워크에서는 작동하고 다른 네트워크에서는 실패한다면 클라이언트 설정을 그대로 둔 채 비교 테스트하세요. 먼저 해당 네트워크에서 일반 접속과 DNS 조회가 되는지 확인한 다음 연결이 어느 단계에서 실패하는지 살펴봅니다. 대상에 따라 결과가 다르다고 모든 서버가 만료되었다고 바로 판단하지 마세요. 서버 한 대의 연결 실패만으로 클라이언트를 재설치해야 한다고 단정해서도 안 됩니다. 비교 대상을 고정해야 차이가 발생한 단계를 합리적으로 좁힐 수 있습니다.

업데이트 후 되돌릴 때는 프로그램 파일 하나만 교체하기보다 설정과 호환되는 실행 환경을 함께 복구하세요. 새 버전의 설정 형식은 이전 UI에서 완전히 이해하지 못할 수 있으므로 마이그레이션 전에 별도 백업을 보관하는 것이 안전합니다. Android 앱을 삭제하면 앱 데이터가 지워질 수 있으며 데스크톱 앱을 제거해도 설정 디렉터리가 반드시 유지된다고 볼 수 없습니다. 작업 전에 내보낸 파일을 읽을 수 있는지 확인하고 민감한 정보도 보호하세요.

자주 묻는 질문은 FAQ에서 확인할 수 있습니다. 기본 연결 흐름을 빠르게 다시 구성하려면 사용 가이드로 돌아가세요. 유지 관리의 핵심은 모든 설정을 최신 상태로 유지하는 것이 아니라 불확실한 변경을 줄이는 것입니다. 현재 설정을 설명하고 문제를 재현하며 안정적으로 되돌릴 수 있어야 고급 설정으로 넘어갈 수 있습니다.

9. 고급 설정 학습 순서

생성된 설정을 읽은 다음 사용자 지정 설정 작성

고급 설정의 첫 단계는 빈 파일에서 전체 설정을 만드는 것이 아니라 클라이언트가 이미 생성한 내용을 이해하는 것입니다. 로컬에서 현재 실행 설정의 인바운드, 아웃바운드, 라우팅, DNS 관계를 확인하고 GUI 설정이 각 필드로 어떻게 변환되는지 살펴보세요. 생성 파일은 다음 실행 때 덮어써질 수 있으므로 클라이언트가 지원하는 설정 메뉴에서 변경하세요. 임시 파일을 직접 수정하는 방식은 장기적인 유지 관리 방법이 아닙니다.

설정을 읽을 때는 먼저 태그를 따라가며 어떤 인바운드가 앱 요청을 받는지, 규칙이 어떤 아웃바운드를 가리키는지, 기본 아웃바운드는 무엇인지 확인하세요. 다음으로 전송 및 보안 매개변수를 살펴보고 마지막으로 DNS와 특수 기능을 확인합니다. 요청 하나의 흐름만 따라가도 특정 필드가 현재 연결에 실제로 적용되는지 파악할 수 있습니다. 참조되지 않는 아웃바운드나 매칭되지 않는 규칙은 파일에 있다는 이유만으로 작동하지 않습니다.

최소 규칙으로 매칭 원리 익히기

범위가 명확한 도메인 규칙 하나를 추가하고 매칭 여부를 확인한 뒤 도메인 목록으로 넓혀 보세요. 다음 조각은 example.com과 하위 도메인의 트래픽을 direct라는 아웃바운드로 보내는 예시입니다. 규칙 실습을 위한 예시일 뿐, 모든 환경에서 해당 도메인을 직접 연결해야 한다는 뜻은 아닙니다. 이 조각은 기존 Xray / V2Ray 형식 라우팅 규칙 배열에 추가해야 하며 해당 아웃바운드 태그가 존재해야 합니다.

{
  "type": "field",
  "domain": ["domain:example.com"],
  "outboundTag": "direct"
}

실습 전 기존 규칙 순서를 기록하고, 실습 후 대상 도메인이 코어에 들어오는지, 도메인 정보가 유지되는지, 지정한 아웃바운드가 선택되는지 확인하세요. 매칭되지 않으면 DNS나 스니핑을 바꾸기 전에 앞선 규칙과 인바운드 정보를 먼저 살펴보세요. 실패 원인을 설명할 수 있을 때 다음 조건을 추가해야 특정 실행에서만 우연히 작동하고 이유를 알 수 없는 설정을 피할 수 있습니다.

필요에 따라 DNS와 FakeDNS 살펴보기

FakeDNS는 예약된 주소 풀의 주소를 도메인 대신 사용하고 둘 사이의 매핑을 유지해 이후 트래픽에서 원래 대상 정보를 복원합니다. TUN 및 도메인 기반 라우팅과 함께 사용되는 경우가 많지만 일반적인 공용 DNS 주소가 아니며 모든 환경에 적합한 것도 아닙니다. 앱 캐시, LAN 이름 해석, 불완전한 인바운드 적용 범위로 문제가 생길 수 있으므로 주소가 어떻게 반환되고 코어가 이를 어떻게 받으며 실제 연결로 언제 변환하는지 먼저 이해해야 합니다.

이 기능을 살펴보기 전에 일반 DNS, TUN, 도메인 라우팅을 각각 확인할 수 있어야 합니다. 기능을 켠 뒤 도메인 접속, IP 직접 접속, LAN 기기 접속, 기능을 끈 뒤 복구 과정까지 테스트하세요. 특히 앱이 이전에 반환된 주소를 캐시하는지 확인해야 합니다. 자세한 원리와 TUN 연동 방법은 FakeDNS 원리와 TUN 연동에서 확인하세요. 연결 실패를 해결하는 만능 스위치처럼 사용하지 마세요.

고급 설정을 유지 관리 가능한 방식으로 정리

사용자 지정 설정, 복잡한 라우팅, 코어 간 규칙 변환은 기존 일상 설정을 보존한 채 별도 설정에서 먼저 실험하세요. 각 기능의 용도, 입력 조건, 필요한 리소스, 되돌리는 방법을 기록합니다. 예를 들어 도메인 규칙은 앱이 도메인 정보를 유지해야 하고, TUN 설정은 권한과 외부 인터페이스가 필요하며, 특정 DNS 설정은 프록시 연결을 먼저 수립해야 할 수 있습니다. 긴 매개변수를 복사하는 것보다 이러한 전제 조건을 이해하는 것이 중요합니다.

성능을 판단할 때도 변수를 통제하세요. 네트워크, 서버, 테스트 대상을 고정하고 연결 수립, 웹페이지 로딩, 앱의 실제 동작을 각각 살펴봅니다. 짧은 테스트 결과를 모든 환경에 적용하지 마세요. 로그 상세 수준, 동시에 실행 중인 앱, DNS 캐시도 관찰 결과에 영향을 줄 수 있습니다. 결과가 반복해서 안정적으로 재현되고 변경 사항이 연결 흐름에 미친 영향을 설명할 수 있을 때만 실험 설정을 평소 설정에 포함하세요.

이 페이지의 순서에 따라 설치와 구독을 확인하고, 앱 인바운드와 라우팅 및 DNS를 검증한 다음 TUN과 사용자 지정 기능으로 확장하는 과정을 반복할 수 있습니다. 기본 개념이 더 필요하다면 V2Ray 초보자를 위한 입문 질문 10가지에서 용어를 확인한 뒤 관련 장으로 돌아와 설정하세요. 이해하기 어려운 매개변수 묶음에 의존하기보다 간결하고 설명 가능한 설정을 유지하는 편이 관리하기 쉽습니다.