프로토콜과 전송 방식
프로토콜은 통신 방식을, 전송 방식은 데이터 전달 수단을, 보안 기능은 연결 보호를 담당합니다. 이름이 비슷하다고 서로 대체할 수 있는 것은 아닙니다.
- VMess프록시 프로토콜 · 사용자 식별 정보 인증
- VMess는 Project V 생태계의 프록시 프로토콜로, 사용자 식별 정보로 인증합니다. 일반적인 설정에는 서버 주소와 포트, 전송 방식, 보안 설정도 포함됩니다. 연결하려면 클라이언트와 서버의 설정이 서로 일치해야 하므로 주소만 입력해서는 연결되지 않습니다. 인증 과정은 시간 설정의 영향을 받습니다. 기기의 시간이 크게 어긋났다면 먼저 시스템 시간을 동기화한 뒤 설정이 만료되었는지 확인하세요.
- VLESS경량 프록시 프로토콜 · 보안 계층과 함께 사용
- VLESS는 프로토콜 계층의 처리를 간소화했으며, 통신 내용을 자체적으로 암호화하지 않습니다. 보통 TLS나 REALITY 같은 보안 기능과 함께 사용합니다. 설정을 가져올 때는 사용자 식별 정보뿐 아니라 전송 방식, 서버 이름, 흐름 제어 등의 원래 매개변수도 유지해야 합니다. VLESS와 VMess는 서로 바꿔 쓸 수 있는 이름이 아닙니다. 프로토콜 목록만 바꾼다고 설정이 변환되지는 않습니다.
- Trojan프록시 프로토콜 · 비밀번호와 TLS
- Trojan은 일반적으로 TLS 연결을 통해 프록시 통신을 수행하며 비밀번호로 인증합니다. 주소와 비밀번호 외에도 서버 이름, 인증서 검증, 실제 전송 방식이 연결 결과에 영향을 줍니다. 인증서 오류가 발생하면 도메인과 기기 시간, 서버 설정을 확인하세요. 평소 해결 방법으로 인증서 검증을 끄는 것은 권장하지 않습니다.
- REALITY전송 보안 기능 · Xray 생태계
- REALITY는 Xray 생태계의 전송 보안 기능이며 독립적인 프록시 프로토콜은 아닙니다. VLESS와 함께 사용되는 경우가 많습니다. 연결하려면 공개 키, 서버 이름, 짧은 ID 등의 설정이 일치해야 하며, 세부 항목은 클라이언트와 코어 버전에 따라 달라집니다. REALITY가 표시된다면 프로토콜 목록에 VLESS가 있는지만 볼 것이 아니라 현재 코어가 해당 설정을 지원하는지도 확인해야 합니다.
코어와 생태계
화면은 설정을 관리하고 코어는 연결을 처리합니다. 호환성 문제를 확인할 때는 프로그램 이름만 보지 말고 둘 다 확인해야 합니다.
- Project V프로젝트 생태계 · 모듈형 프록시 통신
- Project V는 모듈형 프록시 통신을 중심으로 하는 프로젝트 생태계이며, V2Ray는 이 생태계를 이해하는 데 중요한 출발점입니다. 일상적인 대화에서 “V2Ray”는 코어를 가리키기도 하고, 호환 프로토콜이나 클라이언트를 통칭하기도 합니다. 가이드를 읽을 때는 문맥을 확인하세요. 소프트웨어를 선택하기 전 프로토콜, 실행 코어, 그래픽 클라이언트를 구분하면 각 구성 요소의 기능을 혼동하지 않을 수 있습니다.
- V2Fly커뮤니티 프로젝트 · V2Ray 코어 유지 관리
- V2Fly는 V2Ray 코어와 관련 구성 요소를 유지 관리하는 커뮤니티 프로젝트입니다. 실제 연결 기능은 사용하는 코어 버전에 따라 달라집니다. Android 클라이언트 v2flyNG는 이 계열의 코어를 사용하는 선택지 중 하나지만, 클라이언트 이름이 프로토콜 이름을 뜻하지는 않습니다. 설정을 옮길 때는 프로토콜과 전송 방식, 지원되는 항목을 확인해야 합니다. 다른 코어의 모든 설정이 그대로 작동한다고 가정해서는 안 됩니다.
- Xray프록시 코어 · 연결 및 라우팅 처리
- Xray는 V2Ray와 기술적 연관성이 있으며 프로토콜 협상, 연결 처리, 라우팅 등의 작업을 담당합니다. 일부 기능은 각자 다른 방향으로 발전했습니다. v2rayN은 코어 설정을 관리하고, v2rayNG는 널리 쓰이는 Android 그래픽 클라이언트 중 하나입니다. 코어가 시작되지 않으면 화면이 열리는지만 볼 것이 아니라 시작 로그에서 구체적인 설정 항목이나 파일 오류를 확인하세요.
- 코어와 클라이언트실행 계층과 설정 화면의 차이
- 클라이언트는 구독 관리, 서버 선택, 로그 확인 등의 화면을 제공하고, 코어는 생성된 설정에 따라 백그라운드에서 네트워크 작업을 수행합니다. 화면에 특정 설정이 표시된다고 해서 현재 선택한 모든 코어가 해당 항목을 인식하는 것은 아닙니다. 클라이언트 업데이트, 코어 업데이트, 구독 업데이트는 서로 다른 작업입니다. 문제가 생기면 어느 계층을 변경했는지 기록해 두세요.
구독과 노드
구독으로 설정을 가져오고 노드로 연결을 지정합니다. 공유하거나 백업할 때는 민감한 정보와 설정을 옮길 범위도 고려해야 합니다.
- 구독 링크연결 설정 모음을 가져오는 주소
- 구독 링크는 클라이언트가 여러 연결 설정을 가져오는 데 사용하는 주소이며, 반환되는 형식은 클라이언트가 인식할 수 있어야 합니다. 링크에 계정 정보가 포함될 수 있으므로 공개 화면 캡처나 로그, 게시물에 올리지 마세요. 가져오기에 실패하면 주소에 접근할 수 없는 문제인지, 형식을 해석하지 못하는 문제인지 먼저 구분하세요. 구독 변환은 형식만 맞출 뿐 원본에 없는 연결 정보를 자동으로 채우지는 않습니다.
- 노드서버 항목 · 연결 설정
- 노드는 일반적으로 클라이언트 목록에 등록된 연결 설정 하나를 뜻하며, 서버 주소와 포트, 프로토콜, 인증 및 전송 보안 정보가 포함됩니다. 목록에 표시된 이름은 메모일 뿐, 실제 서버 위치나 연결 품질을 보장하지 않습니다. 노드를 선택하면 현재 연결 후보로 지정되지만, 앱에서 실제로 사용할지는 프록시 모드와 라우팅 규칙, 코어의 정상 작동 여부에 따라 달라집니다.
- 구독 업데이트설정 목록 새로 고침 · 프로그램 업데이트와 다름
- 구독 업데이트는 구독 주소에 다시 요청을 보내고 클라이언트의 처리 방식에 따라 설정 목록을 새로 고치는 작업입니다. 클라이언트나 코어 업데이트를 대신하지 않습니다. 원본이 바뀌면 기존 항목이 수정되거나 삭제될 수 있으므로 구독 항목을 장기간 보관할 수 있는 수동 백업으로 사용하지 않는 것이 좋습니다. 업데이트 후에는 현재 선택한 항목이 남아 있는지 확인한 다음 연결을 테스트하세요. 항목 변경을 네트워크 오류로 오해하지 않도록 주의해야 합니다.
라우팅과 분기
규칙은 조건을 판단하고 아웃바운드는 연결을 실행합니다. 먼저 규칙 순서와 데이터 출처를 확인한 뒤 최종 매칭 결과를 살펴보세요.
- 라우팅 규칙매칭 조건 → 아웃바운드 이름
- 라우팅 규칙은 도메인, IP, 포트, 프로세스 등의 조건에 따라 아웃바운드를 선택합니다. 사용할 수 있는 조건은 코어와 클라이언트에 따라 달라집니다. 규칙은 보통 위에서부터 순서대로 적용되며, 조건이 일치하면 해당 아웃바운드를 사용합니다. 따라서 범위가 넓은 조건이 뒤에 있는 세부 규칙을 가릴 수 있습니다. 문제를 확인할 때는 규칙 순서를 먼저 살펴보고, 요청에 사용할 수 있는 도메인 정보가 있는지 확인하세요. 최종 처리 규칙은 마지막에 검토하는 것이 좋습니다.
- GeoIPIP 주소 모음 · 지역 및 용도별 분류
- GeoIP는 IP 주소를 지역이나 용도별로 묶어 라우팅에 사용할 수 있게 합니다. 예를 들어
geoip:private는 사설 주소를 매칭할 때 자주 사용합니다. 분류 결과는 데이터 출처와 업데이트 버전에 따라 달라지므로 실제 주소 위치를 절대적으로 증명하지는 않습니다. IP 조건을 사용할 때는 도메인이 언제 조회되는지, 현재 라우팅 정책이 매칭을 위해 주소를 직접 조회하는지도 고려해야 합니다.
- GeoSite도메인 분류 모음 · 규칙 데이터 필요
- GeoSite는 도메인을 카테고리별로 묶습니다. 규칙에서
geosite:cn같은 분류를 참조하면 도메인을 하나씩 등록할 필요가 없습니다. 분류가 존재하는지, 어떤 항목이 포함되는지는 현재 불러온 데이터 파일에 따라 달라집니다. 로그에 분류가 없다고 표시되면 데이터 파일과 분류명을 확인하세요. 규칙 순서만 바꿔서는 존재하지 않는 분류를 사용할 수 없습니다.
- 라우팅 분기와 아웃바운드요청 분배 과정과 실제 연결 설정
- 라우팅 분기는 요청마다 다른 처리 경로를 선택하는 과정이고, 아웃바운드는 실제 연결을 실행하는 설정입니다. 화면에서는
direct,proxy,block을 직접 연결, 프록시, 차단을 뜻하는 이름으로 자주 사용합니다. 하지만 이름만으로 동작이 정해지는 것은 아니며 해당 이름에 맞는 설정이 있어야 합니다. 직접 연결도 기기에서 대상에 접근할 수 있어야 하므로, direct를 선택해도 일반적인 네트워크 제약은 그대로 적용됩니다.
클라이언트 기능
프록시 모드는 클라이언트로 들어오는 트래픽의 범위를 정하고, 연결 테스트는 특정 대상만 확인합니다. 두 기능 모두 적용 범위를 파악해야 합니다.
- 시스템 프록시시스템에 로컬 프록시 주소 등록
- 시스템 프록시는 로컬 프록시 주소를 운영체제에 등록합니다. 해당 설정을 따르는 앱에 주로 적용되며 모든 네트워크 연결을 자동으로 가로채지는 않습니다. v2rayN의 ‘시스템 프록시 자동 설정’과 ‘시스템 프록시 해제’는 시스템 설정을 바꾸는 기능이지 원격 연결 매개변수를 바꾸는 기능이 아닙니다. 클라이언트를 종료한 뒤 작동하지 않는 프록시 주소가 남아 있으면 브라우저가 중지된 로컬 포트로 계속 요청을 보낼 수 있습니다.
- TUN 모드가상 네트워크 인터페이스 · 더 넓은 트래픽 처리
- TUN 모드는 가상 네트워크 인터페이스로 트래픽을 받아 시스템 프록시를 따르지 않는 일부 앱도 처리할 수 있습니다. 보통 관리자 권한이나 적절한 네트워크 권한이 필요합니다. 실제 적용 범위는 시스템 라우팅, 제외 규칙, IPv6 설정, 구현 방식에 따라 달라지므로 스위치가 켜졌다는 이유만으로 모든 트래픽이 처리된다고 볼 수는 없습니다. 사용 전 권한과 DNS 설정을 확인하고 다른 가상 네트워크 어댑터 프로그램과 라우팅이 충돌하지 않는지 살펴보세요.
- 지연 시간 테스트테스트 방식이 다르면 결과도 직접 비교할 수 없음
- 지연 시간은 특정 테스트에 걸리는 시간입니다. TCP 연결 수립, HTTP 요청, 기타 탐색 방식은 측정 과정이 서로 다릅니다. TCP 포트에 연결할 수 있다는 것은 해당 연결 단계에 도달할 수 있다는 뜻일 뿐, 프로토콜 인증이나 대상 접근까지 성공한다는 의미는 아닙니다. 결과를 비교할 때는 같은 방식과 테스트 대상을 사용하세요. 지연 시간이 짧다고 지속적인 다운로드 속도가 더 빠른 것도 아닙니다.
- 실제 연결 지연 시간프록시 설정으로 요청을 보내는 테스트
- 클라이언트의 실제 연결 지연 시간 테스트는 보통 현재 프록시 설정을 통해 테스트 주소에 요청을 보냅니다. 서버 포트만 확인하는 테스트보다 더 많은 연결 단계를 포함합니다. DNS 조회와 핸드셰이크, 리디렉션을 측정에 포함하는지, 성공 여부를 어떻게 판단하는지는 클라이언트 구현에 따라 다릅니다. 테스트 실패가 테스트 주소 자체나 해당 주소의 라우팅 문제일 수도 있으므로 모든 앱이 연결되지 않는다고 단정할 수는 없습니다.
네트워크 기초
도메인 조회, 주소 매핑, 로컬 포트는 서로 다른 단계입니다. 먼저 문제가 발생한 계층을 찾은 다음 설정을 변경하세요.
- DNS도메인 조회 · 연결 전 주소 확인
- DNS는 도메인을 IP 주소 등의 레코드로 변환하며, 그 결과는 이후 연결과 IP 기반 라우팅 판단에 영향을 줍니다. 시스템과 브라우저, 프록시 코어에 각각 DNS 설정이 있을 수 있으므로 한 곳을 바꿔도 모든 조회 경로가 바뀌지는 않습니다. 도메인에 접속할 수 없다면 DNS 조회가 성공했는지, 확인된 주소에 접근할 수 있는지, 요청이 최종적으로 어떤 아웃바운드를 사용하는지 각각 점검하세요.
- FakeDNS가상 주소와 도메인 매핑
- FakeDNS는 지정된 주소 풀에서 가상 주소를 반환하고, 가상 주소와 원래 도메인의 매핑을 유지해 이후 처리 단계에서 도메인 정보를 보존합니다. 이 주소는 대상 서버의 실제 주소가 아니므로 매핑을 인식하는 구성 요소가 연결을 이어받아야 합니다. 모드를 켜거나 끈 뒤 앱이 이전 주소를 캐시하고 있으면 접속 문제가 생길 수 있습니다. DNS 캐시와 트래픽 처리 범위를 클라이언트 구현에 맞게 확인하세요.
- DNS 누수예상한 조회 경로에서 벗어난 상태
- DNS 누수는 일반적으로 도메인 조회가 의도한 경로를 거치지 않고 시스템이나 앱에서 다른 DNS 서비스로 전달되는 상태를 뜻합니다. 문제가 있는지는 원래 계획한 라우팅 대상에 따라 달라집니다. 직접 연결할 도메인을 로컬 DNS로 조회하는 것만으로는 오류라고 볼 수 없습니다. 브라우저의 보안 DNS, 시스템 DNS, 코어 DNS, TUN 설정을 함께 확인해야 하며, 검사 페이지 하나만으로는 일부 상황만 확인할 수 있습니다.
- 로컬 수신 포트앱이 클라이언트에 연결하는 기기 내 입구
- 로컬 수신 포트는 클라이언트가 기기에서 연결을 받는 입구이며 원격 서버 포트와는 다른 개념입니다. 일부 v2rayN 설정은 SOCKS/HTTP 혼합 수신 포트로
10808을 사용하지만 실제 값은 현재 설정을 기준으로 확인해야 합니다. 앱에 입력하는 프로토콜과 포트는 이 설정과 일치해야 합니다. 다른 프로그램이 포트를 사용 중이면 코어 시작이나 수신 대기가 실패할 수 있으므로 로그에서 충돌 원인을 먼저 찾으세요.