설정 참고 · 자주 쓰는 개념 25가지

V2Ray 용어 정리
프로토콜·코어·프록시 설정

개념을 먼저 구분한 뒤 설정을 변경하세요. 클라이언트에서 마주치는 설정 항목을 찾아 설명을 확인하고, 연결에 실패하면 문제 해결 가이드를 참고해 문제가 발생한 단계를 살펴보세요.

VMess / VLESS Xray / V2Fly TUN / DNS

프로토콜과 전송

프로토콜은 인증과 데이터 교환 방식을, 전송 방식은 데이터 전달을, 보안 계층은 연결 보호를 담당합니다. 설정을 가져올 때는 이 세 가지 항목을 각각 확인해야 합니다.

VMess: 프로토콜과 전송 · 프록시 프로토콜V2Ray 생태계에서 사용되는 프록시 프로토콜로, 사용자 ID 등의 매개변수로 인증하며 프로토콜 계층에서 데이터를 보호합니다. 설정에는 원격 주소, 포트, 전송 방식, 보안 계층도 포함되는 경우가 많으므로 사용자 ID만 맞아서는 연결되지 않습니다. VMess 공유 링크를 가져온 뒤에는 원래 설정을 유지하고, 인증 오류가 발생하면 기기 시간이 정확한지도 확인하세요.

VLESS: 프로토콜과 전송 · 프록시 프로토콜가벼운 프록시 프로토콜로 자체적으로 트래픽을 암호화하지 않으며, 실제 환경에서는 보통 TLS나 REALITY 같은 보안 방식을 함께 사용합니다. 사용자 ID, 전송 유형, flow 등의 항목은 서버 요구사항과 일치해야 하며 다른 설정을 그대로 가져와 사용할 수 없습니다. VLESS라는 이름만 보고 호환성을 판단하지 말고 보안 계층과 전송 설정도 확인하세요.

Trojan: 프로토콜과 전송 · 인증과 TLS일반적으로 TLS 연결에서 사용하는 프록시 프로토콜로, 비밀번호로 인증합니다. 연결하려면 비밀번호뿐 아니라 서버 이름, 인증서 검증, 전송 설정도 일치해야 합니다. 인증서 오류가 발생하면 먼저 서버 이름과 기기 시간을 확인하세요. 인증서 검증을 건너뛰면 연결 신뢰 조건이 달라지므로 일반적인 해결 방법으로 사용하지 않는 것이 좋습니다.

REALITY: 프로토콜과 전송 · 전송 보안Xray에서 지원하는 전송 보안 방식으로, VMess나 VLESS와 같은 독립 프록시 프로토콜은 아닙니다. 클라이언트에는 공개 키, 서버 이름, shortId, 지문 등의 설정이 필요할 수 있으며 구체적인 조합은 서버에서 결정합니다. 가져온 설정의 핸드셰이크가 실패하면 해당 항목과 코어 지원 여부를 확인하세요. 로컬 수신 포트만 바꿔서는 해결되지 않습니다.

전송 방식: 프로토콜과 전송 · 데이터 전달프록시 프로토콜의 데이터를 어떤 통로로 전달할지 정하는 방식입니다. 일반 TCP, WebSocket, gRPC 등이 있으며 코어와 버전에 따라 화면에 표시되는 이름이 다를 수 있습니다. 경로, Host, 서비스 이름은 해당 전송 방식의 연결 매개변수이므로 임의로 바꾸는 메모가 아닙니다. 전송 방식은 속도 등급이 아니므로 서버 설정과 일치하는지 먼저 확인한 뒤 실제 요청으로 성능을 살펴보세요.

코어와 생태계

GUI는 조작을 담당하고 프록시 코어는 실제 처리를 담당합니다. 기능 지원 여부를 확인할 때는 클라이언트와 코어가 각각 지원하는 범위를 함께 살펴야 합니다.

Project V: 코어와 생태계 · 프로젝트 생태계네트워크 통신 도구를 중심으로 형성된 프로젝트 생태계이며, V2Ray가 핵심 프로젝트입니다. 흔히 말하는 “V2Ray 클라이언트”는 관련 프로토콜과 코어를 지원하는 GUI 도구를 가리키는 경우가 많으며, 모두 같은 소프트웨어 패키지에 속한다는 뜻은 아닙니다. 이런 관계를 이해하면 GUI 업데이트, 코어 업데이트, 원격 서버 설정이 각각 어떤 부분에 영향을 주는지 구분하기 쉽습니다.

V2Fly: 코어와 생태계 · V2Ray 코어 유지 관리V2Ray 코어를 유지·관리하고 핵심 기능과 관련 설정을 발전시키는 커뮤니티 프로젝트입니다. v2flyNG는 Android용 GUI 클라이언트로, V2Fly 코어를 사용합니다. 프로토콜 이름이 비슷해도 모든 확장 항목을 함께 사용할 수 있는 것은 아닙니다. 설정이 호환되지 않으면 클라이언트 이름만 비교하지 말고 실제 코어 버전의 지원 범위를 확인하세요.

Xray: 코어와 생태계 · 프록시 코어V2Ray 기술 체계에서 파생된 프록시 코어 프로젝트로, 여러 프로토콜과 전송 및 보안 방식을 지원하며 v2rayNG에서 사용합니다. Xray와 V2Fly는 일부 개념을 공유하지만 확장 기능과 설정 세부 사항은 다릅니다. 한 코어에서 작동하는 설정이 코어를 바꾼 뒤에도 유효하다는 보장은 없으므로 보안 계층과 flow 등의 항목을 특히 주의해 확인하세요.

클라이언트와 코어: 코어와 생태계 · GUI와 실행v2rayN 등의 클라이언트는 구독 관리, 서버 선택, 설정 화면을 제공하고 코어는 수신 대기, 연결, 라우팅, 트래픽 전달을 담당합니다. GUI가 열렸다는 것은 프로그램이 실행 중이라는 뜻일 뿐 코어가 성공적으로 시작됐다는 의미는 아닙니다. 모든 연결이 실패하면 코어 시작 로그와 포트 수신 상태를 확인한 뒤 원격 서버와 로컬 설정 중 어디를 점검할지 판단하세요.

인바운드와 아웃바운드: 코어와 생태계 · 트래픽 방향인바운드는 로컬 애플리케이션이나 가상 네트워크 인터페이스에서 들어오는 트래픽을 받고, 아웃바운드는 해당 트래픽을 내보내는 방식을 나타냅니다. 하나의 설정에 인바운드와 아웃바운드가 여러 개 포함될 수 있으며, 라우팅 규칙으로 목적지를 선택합니다. 규칙의 outboundTag는 아웃바운드 태그를 가리키므로 설정에 실제로 정의된 태그와 일치해야 합니다. 서버 별칭이나 임의로 적는 설명 문구가 아닙니다.

클라이언트 기능

프록시 진입점은 어떤 트래픽이 클라이언트로 들어올지 정하고, 라우팅은 들어온 뒤의 처리 방식을 정합니다. 특정 모드를 켠다고 모든 애플리케이션이 같은 출구를 사용하는 것은 아닙니다.

시스템 프록시: 클라이언트 기능 · 애플리케이션 프록시 진입점운영체제가 애플리케이션에 제공하는 프록시 주소 설정으로, 일반적으로 클라이언트가 로컬에서 수신 대기하는 주소와 포트를 가리킵니다. 이 설정을 따르는 애플리케이션만 프록시를 사용하며 자체 네트워크 설정이 있는 앱은 다른 경로를 선택할 수 있습니다. v2rayN에서 시스템 프록시를 설정한 뒤에는 코어가 실행 중인지도 확인하세요. “시스템 프록시 자동 설정”은 운영체제 설정을 적용한다는 뜻이지 노드를 자동으로 선택한다는 뜻은 아닙니다.

TUN 모드: 클라이언트 기능 · 가상 네트워크 인터페이스가상 네트워크 인터페이스를 통해 IP 계층 트래픽을 받는 실행 방식으로, 프록시를 직접 설정할 수 없거나 시스템 프록시를 따르지 않는 애플리케이션에 적합합니다. 필요한 권한을 부여해야 하며 라우팅, DNS, 루프백 제외 설정도 올바르게 구성해야 합니다. TUN은 트래픽을 처리하는 범위를 넓히지만 모든 트래픽을 자동으로 프록시 아웃바운드로 보내지는 않습니다. 다른 가상 네트워크 소프트웨어와 함께 실행한다면 라우팅 충돌도 확인하세요.

로컬 수신 포트: 클라이언트 기능 · 로컬 연결 진입점클라이언트가 로컬 기기에서 애플리케이션 연결을 받는 포트입니다. 애플리케이션에 해당 프록시 유형과 포트 번호를 입력해야 합니다. 튜토리얼에 자주 나오는 10808은 실제 설정과 대조해 확인할 값이며, 현재 클라이언트에 설정된 포트를 사용해야 합니다. 포트가 이미 사용 중이면 코어가 시작되지 않을 수 있습니다. LAN 기기의 접속을 허용하려면 수신 주소와 방화벽도 설정해야 하므로 포트 번호만 바꾸면 해결되는 것은 아닙니다.

앱별 프록시: 클라이언트 기능 · 앱별 범위 설정애플리케이션별로 트래픽을 프록시 서비스에 보낼지 정하는 기능으로, v2rayNG에서는 보통 VPN 모드와 함께 사용합니다. 목록에 있는 앱을 “프록시로 보낼지” 또는 “프록시에서 우회할지” 먼저 확인하세요. 두 설정은 서로 바꿔 쓸 수 없습니다. 목록은 트래픽을 가져올 범위를 정하며, 서비스에 들어온 뒤에는 라우팅 규칙에 따라 다시 분기될 수 있습니다. 변경한 뒤에는 화면 안내에 따라 연결을 다시 시작하고 확인하세요.

Mux 다중화: 클라이언트 기능 · 연결 재사용여러 논리 연결이 소수의 하위 연결을 공유하도록 해 반복적인 연결 설정 비용을 줄일 수 있는 방식입니다. 하위 연결에 혼잡이나 패킷 손실이 발생하면 이를 공유하는 요청끼리 서로 영향을 받을 수 있으므로 Mux를 범용 속도 향상 기능으로 보면 안 됩니다. 사용 여부는 프로토콜, 코어, 사용 환경을 고려해 결정하세요. 효과를 비교할 때는 노드와 테스트 대상을 동일하게 유지하고 한 번에 설정 하나만 바꾸세요.

구독과 노드

설정의 출처를 먼저 확인한 다음 연결 가능 여부, 요청 소요 시간, 실제 처리량을 구분하세요. 서로 다른 지표입니다.

구독: 구독과 노드 · 설정 업데이트 출처하나의 주소에서 연결 설정 목록을 가져오고 업데이트하는 방식입니다. 구독 주소와 목록에 포함된 서버 주소는 서로 다른 개념인 경우가 많습니다. v2rayN은 구독 그룹으로 설정 출처를 관리하고, v2rayNG에는 구독 설정 메뉴가 있습니다. 업데이트 후 클라이언트가 응답 내용을 파싱합니다. 주소에 접근 인증 정보가 포함될 수 있으므로 공개하지 마세요. 업데이트 실패가 기존 노드의 작동 불능을 의미하는 것은 아닙니다.

노드: 구독과 노드 · 연결 설정 묶음클라이언트 목록에서 원격 서버에 연결할 때 사용하는 설정 항목으로, 보통 주소, 포트, 프로토콜, 인증, 전송 설정이 포함됩니다. 노드 별칭은 구분을 위한 이름일 뿐 실제 지리적 위치, 네트워크 경로, 서비스 품질을 증명하지 않습니다. 노드를 선택한 뒤 현재 활성 서버로 설정됐는지도 확인하세요. 구독 업데이트로 항목이 바뀌거나 삭제될 수 있으므로 필요하면 선택 상태를 다시 확인하세요.

TCPing: 구독과 노드 · 포트 연결 가능 여부대상 TCP 포트에 연결하는 데 걸리는 시간을 측정하는 테스트로, ICMP Ping과는 다릅니다. 주소와 포트에 연결할 수 있는지 확인하는 데 도움이 되지만 프록시 인증, 전체 보안 핸드셰이크, 대상 웹사이트 접속 여부는 보통 확인하지 않습니다. TCPing 결과가 정상인데 브라우저에서 접속되지 않으면 프로토콜 설정과 실제 프록시 요청을 추가로 확인하세요. 다운로드 대역폭도 직접 측정하지 않습니다.

실제 연결 지연 시간: 구독과 노드 · 프록시 요청 테스트선택한 프록시 설정을 통해 테스트 주소에 요청을 보내 측정한 소요 시간으로, 단순 포트 검사보다 실제 접속 경로를 더 가깝게 반영합니다. 테스트 대상, DNS, 핸드셰이크, 당시 네트워크 상태에 따라 결과가 달라지므로 조건이 다른 테스트끼리 직접 비교하지 않는 것이 좋습니다. 한 번의 테스트 성공은 해당 요청 경로를 사용할 수 있다는 뜻일 뿐 모든 앱의 트래픽이 프록시로 전달된다는 의미는 아니며, 지속적인 처리량 테스트를 대신하지도 않습니다.

라우팅과 DNS

분할 라우팅은 매칭 정보가 필요하고 DNS 조회는 주소를 제공합니다. 접속 문제가 발생하면 트래픽 출구와 DNS 조회 경로를 함께 확인하세요.

라우팅 규칙과 분할 라우팅: 라우팅과 DNS · 아웃바운드 선택도메인, IP, 포트 또는 기타 조건에 따라 아웃바운드를 선택하는 방식으로, 주로 직접 연결, 프록시, 차단 중 하나로 처리합니다. 규칙은 보통 순서대로 적용됩니다. 범위가 넓은 규칙을 앞에 두면 뒤에 있는 세부 규칙이 적용되지 않을 수 있습니다. 수정할 때는 매칭 조건, 규칙 순서, 아웃바운드 태그를 함께 확인하세요. 시스템 프록시 상태를 바꿔도 이 규칙은 자동으로 변경되지 않습니다.

GeoIP와 GeoSite: 라우팅과 DNS · 규칙 데이터 집합GeoIP는 IP 주소 집합을, GeoSite는 도메인 집합을 매칭하는 데 사용합니다. 코어는 해당 데이터 파일을 이용해 규칙에서 참조하는 분류를 확인합니다. 분류 이름을 사용할 수 있는지는 현재 데이터 파일에 따라 달라지므로 이름만 보고 판단하지 마세요. GeoIP 결과가 실제 서비스의 물리적 위치와 일치한다는 보장도 없습니다. 규칙이 작동하지 않으면 구독만 새로고침하지 말고 데이터 파일이 로드됐는지, 해당 분류가 있는지 확인하세요.

DNS 조회: 라우팅과 DNS · 도메인을 주소로 변환도메인을 IP 주소 등의 레코드로 변환하는 과정으로, 보통 애플리케이션이 연결을 시작하기 전에 이루어집니다. 운영체제, 브라우저, 프록시 코어가 각각 DNS 조회를 수행할 수 있으므로 시스템 DNS를 바꿔도 모든 앱의 조회 방식이 달라지는 것은 아닙니다. 문제를 확인할 때는 먼저 어느 구성 요소가 조회를 수행하고 어떤 출구를 통해 요청을 보내는지 파악한 뒤 캐시와 응답 결과를 살펴보세요. DNS 조회에 성공해도 대상 서버에 연결된다는 뜻은 아닙니다.

FakeDNS: 라우팅과 DNS · 가상 주소 매핑도메인에 가상 IP를 할당하고 코어에 도메인과 해당 주소의 매핑을 저장해, 이후 연결을 원래 도메인과 다시 연결할 수 있도록 하는 방식입니다. 일반 공용 DNS 서버를 대체하는 주소가 아니며 DNS 요청과 관련 트래픽이 함께 연동된 처리 절차를 거쳐야 합니다. 애플리케이션이 가상 주소를 캐시한 상태에서 관련 트래픽 처리가 꺼져 있으면 접속 문제가 발생할 수 있습니다. 이때는 연동 설정을 복구하고 필요에 따라 캐시를 삭제하세요.

DNS 누수: 라우팅과 DNS · 예상 경로 이탈DNS 요청이 예상한 경로를 따라 전송되지 않는 현상입니다. 예를 들어 지정한 DNS 출구에서 처리되길 기대했지만 운영체제의 다른 경로로 요청이 나갈 수 있습니다. 여러 DNS 서비스가 표시된다는 이유만으로 누수라고 단정하지 말고 먼저 기대하는 동작을 명확히 하세요. 브라우저의 암호화 DNS, 운영체제 DNS 설정, 코어의 DNS 라우팅을 로그와 함께 확인하세요. 노드를 바꿔도 요청을 보내는 앱의 설정은 그대로일 수 있습니다.