프로토콜 및 전송
프로토콜은 프록시 요청을 표현하는 방식, 전송은 데이터를 전달하는 방식, 보안 계층은 연결을 보호하는 방식입니다. 설정할 때는 전체 매개변수 조합을 확인해야 합니다.
- VMess
- Project V 생태계의 프록시 프로토콜로, 인증과 데이터 보호 기능을 제공하며 최신 설정에서는 보통 AEAD 인증을 사용합니다. 클라이언트와 서버의 사용자 식별자 등 설정을 맞춰야 하며, 시스템 시간 차이가 크면 인증에 실패할 수 있습니다. VMess는 특정 전송 방식과 같은 뜻이 아니며, 같은 프로토콜에 서로 다른 전송 설정을 적용할 수 있습니다.
- VLESS
- 경량화를 지향하는 프록시 프로토콜로, 자체적으로 페이로드를 암호화하지 않으며 실제 환경에서는 보통 TLS 또는 REALITY와 함께 사용합니다. 사용자 ID, 흐름 제어, 전송 방식, 보안 계층을 서버 요구 사항에 맞춰 입력해야 합니다. 프로토콜 드롭다운만 VLESS로 바꿔서는 안 됩니다. 사용 가능 여부는 프로토콜 이름이 아니라 전체 설정 조합에 달려 있습니다.
- Trojan
- 일반적으로 TLS로 연결을 보호하고 비밀번호로 인증하는 프록시 프로토콜입니다. 비밀번호뿐 아니라 포트, 서버 이름, 인증서 검증 설정도 확인해야 합니다. 주소에 접속할 수 있어도 인증에 성공한다는 보장은 없습니다. 인증서 오류가 발생하면 검증을 건너뛰기보다 이름과 시스템 시간, 서버 인증서를 확인하세요.
- Shadowsocks
- SS라고도 불리며, 공유 키와 지정된 암호화 방식으로 동작하는 프록시 프로토콜입니다. 세대별 구현에 따라 암호화 방식, 키 형식, 코어 버전 요구 사항이 다르므로 형식이 다른 키를 그대로 바꿔 쓸 수 없습니다. 가져올 때는 주소와 포트만 확인하지 말고 암호화 방식과 인증 필드도 점검하세요.
- REALITY
- Xray 생태계의 전송 계층 보안 방식으로, VLESS와 나란히 놓이는 독립적인 프록시 프로토콜은 아닙니다. 일반적인 클라이언트 설정에는 PublicKey, ShortId, SNI, 지문 등의 매개변수가 있으며 서버 설정과 일치해야 합니다. 짧은 ID를 비워도 되는지는 서버 설정에 따라 달라집니다. 공개 키와 개인 키는 용도가 다르므로 클라이언트에 서버 개인 키를 입력해서는 안 됩니다.
- XTLS Vision
- Xray의 흐름 제어 방식이며, 클라이언트에서는 보통
xtls-rprx-vision으로 표시됩니다. 전송 프로토콜이나 보안 계층이 아니며, 호환되는 VLESS 연결 구성에서 주로 사용합니다. 서버 설정과 전송 방식, 코어가 모두 지원하는 경우에만 선택해야 하며, 아무 노드에나 적용하는 속도 향상 옵션으로 보면 안 됩니다.
- 전송 프로토콜
- 프록시 프로토콜 데이터를 전달하는 방식으로, TCP와 WebSocket 등이 흔히 사용됩니다. 선택 가능한 항목은 코어와 버전에 따라 달라집니다. 프록시 프로토콜이 같아도 전송 방식이 다르면 양쪽이 통신하지 못할 수 있습니다. 경로나 Host 같은 추가 필드는 해당 전송 방식에서만 의미가 있으므로 다른 방식에 그대로 복사해 넣지 마세요.
코어 및 생태계
클라이언트는 UI를 제공하고 코어는 연결을 처리합니다. 기능 지원 여부를 판단하려면 클라이언트의 설정 항목과 실제로 실행 중인 코어를 모두 확인해야 합니다.
- Project V
- 네트워크 프록시 도구와 관련 구성 요소를 중심으로 형성된 프로젝트 생태계이며, V2Ray는 그중 중요한 구성 요소입니다. 일상적으로 말하는 “V2Ray 클라이언트”는 보통 그래픽 관리 도구를 가리키며, 모든 도구가 같은 코어를 사용하는 것은 아닙니다. 이러한 관계를 알면 UI 기능, 설정 형식, 프로토콜 구현을 구분하는 데 도움이 됩니다.
- V2Fly
- V2Ray 코어를 지속적으로 관리하는 커뮤니티 프로젝트로, 프로토콜 처리와 라우팅, DNS 등의 기능을 제공합니다. v2flyNG는 이 코어 계열을 Android용 대안으로 사용합니다. 지원 기능은 실제 코어 버전을 기준으로 확인해야 합니다. 다른 코어의 설정 항목을 그대로 복사하거나 클라이언트 이름만 보고 호환성을 판단해서는 안 됩니다.
- Xray
- V2Ray와 역사적 연관이 있는 프록시 코어 프로젝트로, 이후 자체적인 기능과 설정을 발전시켜 왔습니다. REALITY와 XTLS Vision 등의 기능은 해당 기능을 지원하는 Xray가 필요하며, v2rayNG는 이 코어 계열을 사용합니다. 설정 구조가 비슷하더라도 설정 전체를 그대로 서로 바꿔 쓸 수 있다는 보장은 없습니다.
- 코어
- 프로토콜 처리, 연결 수립, DNS, 라우팅을 담당하는 구성 요소입니다. 클라이언트는 UI와 구독 및 설정 관리를 담당합니다. UI에 옵션이 보인다고 해서 현재 선택한 코어가 이를 실행할 수 있는 것은 아닙니다. 시작 오류를 해결할 때는 먼저 코어 로그를 확인해 미지원 항목, 누락된 매개변수, 포트 충돌이 있는지 살펴보세요.
클라이언트 기능
트래픽을 받아들이는 범위와 아웃바운드를 선택하는 일은 서로 다릅니다. 시스템 프록시나 TUN은 트래픽이 처리 경로에 들어오는 방식을 정하고, 라우팅은 들어온 트래픽을 어디로 전달할지 결정합니다.
- 시스템 프록시
- 운영체제의 프록시 설정을 통해 해당 설정을 따르는 앱이 클라이언트가 제공하는 로컬 프록시로 연결되도록 합니다. 일부 앱은 별도의 네트워크 설정을 사용해 시스템 프록시를 따르지 않을 수 있으므로 모든 트래픽을 가로채는 방식은 아닙니다. 클라이언트를 종료한 뒤 웹페이지에 문제가 생기면 노드 상태만 확인하지 말고 시스템 프록시 설정이 복원됐는지 확인하세요.
- TUN 모드
- 가상 네트워크 인터페이스와 라우팅 설정을 통해 네트워크 트래픽을 클라이언트 처리 경로로 보내는 방식으로, 일반적으로 시스템 프록시보다 더 넓은 범위의 트래픽을 처리합니다. 관리자 권한이 필요할 수 있으며 올바른 라우팅 및 DNS 설정에 의존합니다. 활성화해도 모든 연결이 프록시 아웃바운드를 사용하는 것은 아닙니다. 다른 가상 네트워크 도구와 함께 쓸 때는 라우팅 충돌을 확인하세요.
- 인바운드와 아웃바운드
- 인바운드는 로컬 HTTP 또는 SOCKS 프록시 같은 진입점을 통해 코어로 들어오는 연결을 받습니다. 아웃바운드는 프록시, 직접 연결, 차단 등 연결을 목적지까지 처리하는 방식을 결정합니다. 라우팅 규칙은 아웃바운드 식별자를 통해 구체적인 처리 방식과 연결됩니다. 인바운드의 수신 포트는 원격 서버 포트가 아니므로 한쪽을 변경해도 다른 쪽은 바뀌지 않습니다.
- 트래픽 스니핑
- 일부 연결의 핸드셰이크 정보에서 도메인이나 프로토콜 단서를 파악해 라우팅 판단에 활용합니다. 앱 데이터 내용을 복호화하는 기능이 아니며 모든 연결을 식별할 수도 없습니다. 정보를 얻을 수 있는지는 프로토콜과 핸드셰이크 형식에 따라 달라집니다. 활성화한 뒤에도 DNS와 라우팅을 올바르게 설정해야 하며, 스니핑을 완전한 도메인 조회 정책의 대안으로 사용해서는 안 됩니다.
트래픽을 처리하는 범위와 프록시를 거치는 범위는 다릅니다. 앱의 트래픽이 TUN으로 처리되더라도 규칙에 따라 직접 연결될 수 있습니다. 실제 연결 경로를 확인하려면 모드 스위치만 보지 말고 접속 대상, 일치한 규칙, 아웃바운드 로그를 함께 살펴보세요.
구독 및 노드
구독은 설정의 출처와 업데이트를 담당하고, 노드는 개별 연결 항목입니다. 가져오기, 업데이트, 테스트, 실제 접속은 각각 다른 단계를 확인합니다.
- 구독
- 서버 설정을 일괄로 가져오거나 업데이트하는 주소로, 클라이언트가 내용을 읽어 관리 가능한 항목으로 변환합니다. 구독 URL에는 접속 정보가 포함될 수 있으므로 민감한 정보로 보관하고 스크린샷이나 공개 문서에 노출하지 마세요. 업데이트 성공은 내용을 가져와 해석했다는 뜻일 뿐 모든 노드에 연결할 수 있다는 의미는 아니며, 시스템 프록시가 자동으로 활성화되는 것도 아닙니다.
- 노드
- 클라이언트에서 서버 연결 설정 하나를 가리킬 때 흔히 쓰는 말로, 보통 주소, 포트, 인증 정보, 전송 설정을 포함합니다. 여러 노드 이름이 같은 인프라를 가리킬 수 있으며, 이름에 표시된 지역만으로 실제 위치나 출구 특성을 증명할 수는 없습니다. 사용 가능 여부를 판단하려면 연결 테스트와 앱 접속, 로그를 함께 확인해야 합니다. 목록에 항목이 표시되는지만으로는 충분하지 않습니다.
- 구독 그룹
- 구독 주소와 서버 항목을 출처별로 관리하는 단위로, 각각 업데이트하고 필터링하거나 삭제하기 편리합니다. 그룹 이름은 관리 목적이며 라우팅 정책, 자동 전환, 로드 밸런싱을 의미하지 않습니다. 그룹을 삭제하거나 구독을 업데이트하기 전에 직접 수정한 항목이 덮어써지는지 확인하고, 필요하면 클라이언트의 백업 기능을 사용하세요.
- 지연 시간과 실제 연결 지연 시간
- ‘지연 시간’은 TCP 연결 수립에 걸리는 시간만 측정할 수 있습니다. ‘실제 연결 지연 시간’은 보통 선택한 프록시를 통해 지정된 요청을 보내므로 앱 사용 경로에 더 가깝지만, 테스트 방식은 클라이언트마다 다릅니다. 결과는 대상 사이트, DNS, 핸드셰이크, 시간 초과 설정의 영향을 받으며 다운로드 속도를 직접 나타내지는 않습니다. 시간 초과가 발생해도 테스트 대상을 함께 확인해야 하며, 곧바로 노드가 끊겼다고 단정할 수 없습니다.
라우팅 및 DNS
도메인 조회는 어떤 주소를 가져올지 결정하고, 라우팅은 연결을 어느 아웃바운드로 보낼지 정합니다. 두 설정은 서로 영향을 주지만 같은 설정은 아닙니다.
- 라우팅 규칙과 분할 라우팅
- 도메인, IP, 포트, 인바운드 식별자 등의 조건에 따라 연결을 지정한 아웃바운드로 전달하는 방식입니다. 주요 필드에는
domain,ip,outboundTag가 있습니다. 규칙은 보통 순서대로 적용되며, 일치하는 규칙이 없는 연결은 기본 아웃바운드가 처리합니다. 규칙이 있어도 반드시 일치하는 것은 아니므로 코어가 도메인과 IP 중 무엇을 인식했는지 확인해야 합니다.
- GeoIP
- 지역이나 네트워크 유형별로 정리한 IP 주소 모음으로, 라우팅 조건에 사용할 수 있습니다. 실제 데이터 파일과 업데이트 상태에 따라 달라지며 실시간 위치 정보가 아니고 도메인 분류를 직접 대체할 수도 없습니다. 콘텐츠 전송 네트워크를 사용하는 서비스는 네트워크 위치에 따라 조회되는 주소가 달라질 수 있으므로 GeoIP 태그만으로 서비스의 소속을 정확히 판단하기 어려울 수 있습니다.
- GeoSite
- 서비스나 카테고리별로 정리한 도메인 모음으로, 도메인 분할 라우팅이나 DNS 정책에 자주 사용됩니다. 분류 이름과 포함 범위, 사용 가능한 항목은 데이터 파일에 따라 다르므로 모든 출처에 같은 태그가 있다고 가정해서는 안 됩니다. 규칙을 불러오는 중 오류가 발생하면 먼저 해당 카테고리가 존재하고 파일을 읽을 수 있는지 확인한 다음 도메인 일치 방식을 점검하세요.
- FakeDNS
- 도메인에 가상 IP를 할당하고, 이후 트래픽이 해당 처리 경로에 들어오면 도메인 정보를 복원하는 방식입니다. 반환된 주소는 실제 대상 서버의 주소가 아니며 DNS 조회, 매핑, 라우팅이 함께 작동해야 합니다. 앱이 가상 주소를 받은 뒤 클라이언트를 우회해 연결하면 접속에 실패할 수 있습니다. 방식을 바꿀 때는 앱과 시스템의 DNS 캐시도 고려하세요.
- DNS 유출
- DNS 조회가 예상한 경로를 벗어나 다른 리졸버로 전송되는 현상이며, 명확히 설정한 목표를 기준으로 판단해야 합니다. 시스템 DNS, 앱 내장 암호화 DNS, 코어 DNS가 함께 사용될 수 있으므로 웹사이트 접속 IP가 정상이라고 DNS 경로도 의도대로 동작한다고 볼 수는 없습니다. 앱 설정, 시스템 리졸버, 코어 로그를 각각 확인하고 한 번의 테스트 결과에만 의존하지 마세요.