V2Ray 프로토콜·코어 가이드

설정 계층: 항목이 속한 위치부터 확인하기

클라이언트의 ‘서버 유형’ 하나로 전체 연결 방식을 알 수는 없습니다. 일반적인 프록시 연결에는 앱의 접속 방식, 프록시 프로토콜, 하위 전송 방식, 보안 설정, 라우팅 출구가 함께 관여합니다. 주소와 포트는 어디에 연결할지를, UUID나 비밀번호는 어떻게 인증할지를 정합니다. TCP나 WebSocket은 데이터를 전달하는 방식이고 TLS나 REALITY는 별도의 보안 협상 설정입니다. 항목별 역할을 구분하면 조합 이름을 외우는 것보다 이해하기 쉽고, 서버가 요구하는 보안 방식을 프로토콜 메뉴에서 잘못 고르는 일도 줄일 수 있습니다.

프로토콜·전송·보안 계층 구분하기

VMess, VLESS, Trojan, Shadowsocks는 여기서 다루는 프록시 프로토콜입니다. 클라이언트와 서버가 목적지 주소를 지정하고, 사용자를 인증하며, 프록시 데이터를 주고받는 방식을 정하지만 기능과 보안 모델은 서로 다릅니다. TCP, WebSocket, gRPC는 데이터를 전달하는 방식이고 TLS는 널리 쓰이는 전송 보안 방식입니다. REALITY는 Xray 생태계의 보안 전송 방식으로, 보통 VLESS와 함께 사용하지만 VLESS와 같은 계층에서 서버 유형을 대체하는 독립 옵션은 아닙니다.

VLESS 설정을 확인할 때는 먼저 서버 유형, 다음으로 전송 방식, 마지막으로 보안 계층을 확인하세요. 예를 들어 서버가 TCP와 REALITY를 요구한다면 UUID가 같다는 이유로 WebSocket과 일반 TLS로 바꿔서는 안 됩니다. 반대로 같은 VMess 설정이라도 경로, 호스트명, 전송 방식이 다르면 서로 바꿔 쓸 수 없을 수 있습니다. 실제 연결 여부는 목록에 표시된 프로토콜 이름이 아니라 전체 설정이 일치하는지에 달려 있습니다.

주소·이름·경로는 서로 다른 설정입니다

서버 주소는 하위 연결을 맺을 때 사용하고, TLS 서버 이름은 이름 검증과 협상에 사용하며, WebSocket의 Host는 애플리케이션 계층 요청 정보에 해당합니다. 값이 우연히 같을 수는 있지만 항상 같아야 하는 것은 아닙니다. 서버에서 서로 다른 값을 명시한 경우에만 각각 입력하고, 익숙한 값을 모든 입력란에 복사하지 마세요. 포트는 서버가 연결을 받는 지점일 뿐입니다. 흔히 쓰이는 포트라고 해서 TLS가 활성화되어 있거나 전송 방식이 올바르다는 뜻은 아닙니다.

WebSocket 경로는 서버 및 리버스 프록시 설정과 일치해야 합니다. 앞의 슬래시, 대소문자, 쿼리 문자열도 일치 여부에 영향을 줄 수 있습니다. gRPC 서비스 이름은 일반 웹 경로와 다른 개념입니다. 가져온 뒤 빈 항목이 보여도 반드시 값이 누락된 것은 아닙니다. 해당 프로토콜에서 필요하지 않거나 클라이언트가 기본값을 사용하는 항목일 수 있습니다. 판단하기 전에 프로토콜과 전송 방식의 조합을 확인하고, 다른 가이드의 경로를 그대로 추가하지 마세요.

로컬 접속과 원격 프로토콜을 나눠 확인하세요

데스크톱 앱이 로컬 SOCKS 또는 HTTP 접속 지점에 연결되면 코어가 라우팅 설정에 따라 직접 연결하거나 프록시로 보냅니다. 로컬 포트는 원격 서버 포트와 다르므로 한쪽을 바꿔도 다른 쪽은 바뀌지 않습니다. 시스템 프록시는 프로토콜의 일부가 아닙니다. 시스템 프록시 설정을 읽는 앱에만 영향을 줍니다. 특정 프로그램이 프록시를 거치지 않는다면 원격 프로토콜을 바로 바꾸기보다 먼저 해당 프로그램의 접속 방식을 확인하세요.

Android VPN 모드는 시스템 가상 네트워크 인터페이스로 범위에 해당하는 트래픽을 받은 뒤 코어에 전달합니다. 데스크톱 시스템 프록시와는 적용 범위가 다릅니다. 연결 아이콘이 보인다는 것은 로컬 접속이 설정되었다는 뜻일 뿐, 원격 인증과 도메인 조회, 라우팅까지 정상이라는 의미는 아닙니다. 로그는 ‘로컬에서 요청을 받았는지, 라우팅이 어디를 선택했는지, 원격 연결이 되는지’ 순서로 확인하면 문제를 단계별로 나눠 살펴볼 수 있습니다.

VMess와 VLESS의 설계 차이

VMess와 VLESS는 모두 Project V 관련 클라이언트에서 자주 볼 수 있지만 설계 목표는 다릅니다. VMess는 초기 V2Ray 프로토콜 체계에서 발전했으며 인증, 요청 구성, 데이터 보호 기능을 프로토콜에 포함합니다. VLESS는 Xray 생태계에서 널리 사용되며 구조를 간결하게 하고 보안 전송은 주로 외부 계층에 맡깁니다. 서버 조건을 제외한 우열은 없습니다. 서버가 제공하는 방식과 현재 코어가 전체 조합을 지원하는지가 선택의 기준입니다.

VMess: 최신 인증 방식과 구형 설정 구분하기

VMess의 UUID는 사용자 식별 정보입니다. 서버 주소도 아니고, 새로 만들어 자유롭게 바꿔 넣을 수 있는 메모도 아닙니다. 최신 VMess 설정에서는 AEAD 인증 방식을 사용해야 합니다. 오래된 자료에 나오는 추가 ID 또는 alterId는 과거 호환성을 위한 항목이므로, 구형 가이드를 보고 임의로 0이 아닌 숫자를 입력하지 마세요. 구형 방식 지원 여부는 서버와 코어에 따라 다를 수 있습니다. 오래된 구독을 가져왔다면 제공자가 안내하는 최신 설정을 먼저 확인하세요.

VMess 인증에는 시간이 관여하므로 기기 시계가 크게 어긋나면 인증에 실패할 수 있습니다. 주소에 연결되지만 핸드셰이크가 실패한다면 시스템 날짜, 시간대, 자동 시간 설정을 확인한 뒤 UUID와 서버 상태를 점검하세요. 그렇다고 VMess 연결 실패가 항상 시간 문제인 것은 아닙니다. 전송 경로, 외부 TLS, 원격 포트 오류도 연결 실패로 나타날 수 있습니다. 단순한 시간 초과 메시지보다 로그에 표시된 오류 단계가 원인을 좁히는 데 유용합니다.

VMess는 다양한 전송 방식과 조합할 수 있으므로 프로토콜 이름만으로 리소스 사용량을 가늠할 수 없습니다. VMess와 WebSocket·TLS를 조합한 설정은 직접 전송하는 설정과 핸드셰이크, 캡슐화, 연결 재사용 방식이 다를 수 있습니다. 기존 VMess 설정이 안정적으로 작동하고 구독 업데이트도 정상이며 용도에 맞는다면, 다른 이름이 더 흔하다는 이유만으로 바꿀 필요는 없습니다. 코어 지원을 통일하거나 불필요한 전송 계층을 줄이는 등 구체적인 목적이 있을 때 전환하세요.

VLESS: 간결한 헤더가 완전한 보안을 의미하지는 않습니다

VLESS는 주로 프록시 요청과 사용자 정보를 처리하며, VMess와 동일한 페이로드 암호화 기능을 자체적으로 제공하지는 않습니다. 클라이언트에서 encryption 값이 none으로 표시되는 것은 해당 프로토콜 항목의 정상적인 설정일 수 있으며, 전체 연결이 반드시 평문이라는 뜻은 아닙니다. 전송 보호 여부를 판단하려면 외부 TLS, REALITY 또는 배포 환경의 다른 보안 설정을 확인해야 합니다. none이라는 항목 하나만 보고 전체 보안을 판단하지 마세요.

UUID가 복잡해 보인다고 VLESS에서 외부 보안 계층을 생략해도 되는 것은 아닙니다. 사용자 식별과 암호화된 전송은 서로 다른 문제를 해결합니다. 일반 사용자는 서버에서 제공한 보안 조합을 그대로 가져와야 하며, 설정을 줄이려고 보안 계층을 끄지 마세요. 제공자가 보안 관련 안내 없이 설정만 전달했다면 일반 인터넷용 설정이라고 간주하기보다 먼저 배포 범위와 용도를 확인하세요.

flow, 전송 방식, 서버 지원 여부

VLESS의 flow는 모든 설정에 적용할 수 있는 속도 향상 옵션이 아닙니다. 일부 Xray 설정은 xtls-rprx-vision을 사용하며 서버, 클라이언트 코어, 전송 방식이 관련 조건을 충족해야 합니다. 이 값을 임의의 VLESS 설정에 복사하면 설정이 거부되거나 핸드셰이크에 실패할 수 있습니다. 특히 서버 근거 없이 직접 전송 설정과 WebSocket·gRPC 항목을 섞지 마세요. 이름만 맞고 실제로는 작동하지 않는 설정이 될 수 있습니다.

클라이언트 편집기에 옵션이 표시된다고 해서 현재 선택한 코어가 해당 옵션을 구현한다는 뜻은 아닙니다. VLESS를 확인할 때는 UUID, 전송 방식, 보안 유형, 서버 이름, flow 순으로 살펴보세요. REALITY의 공개 키와 짧은 ID는 별도로 확인합니다. 설정이 일치하는데도 연결되지 않으면 코어 로그의 구체적인 오류를 기록하고 도움말 센터에서 인증, 핸드셰이크, 이름 조회 순으로 추가 확인하세요.

실제 선택 기준은 간단하게 잡을 수 있습니다. 이미 운영 중인 VMess 서비스는 기존 설정을 유지하고, 서버가 VLESS와 명확한 TLS 또는 REALITY 설정을 제공할 때 해당 조합을 지원하는 Xray 클라이언트를 선택하세요. 프로토콜 전환은 유형 메뉴 하나를 바꾸는 일이 아닙니다. 인증 구조와 보안 설정이 다르므로 서버에서 새 전체 설정을 받아야 하며, 비교 검증을 위해 기존 설정도 보관하세요.

Trojan, SS, REALITY

Trojan, Shadowsocks, REALITY는 구독 목록에서 함께 보이는 경우가 많지만 같은 계층에서 서로 대체할 수 있는 세 가지 옵션은 아닙니다. 앞의 두 가지는 프록시 프로토콜이고, REALITY는 보안 전송 방식입니다. 비교할 때는 Trojan과 TLS, VLESS와 REALITY, 또는 구체적인 암호화 방식을 지정한 Shadowsocks처럼 전체 조합을 적어야 합니다. REALITY를 사용한다고만 해서는 필요한 클라이언트와 설정 항목을 판단할 수 없습니다.

Trojan: TLS를 기본 조건으로 확인하기

Trojan은 TLS 보안 연결을 기반으로 하며, 클라이언트는 보통 비밀번호로 프록시 요청을 인증합니다. 설정할 때 비밀번호뿐 아니라 서버 이름과 인증서 검증 조건도 확인해야 합니다. 서버 주소에는 도메인이나 IP 주소를 사용할 수 있지만, TLS 이름은 서버 인증서와 설정에 맞아야 합니다. 주소에 연결되더라도 이름이 일치하지 않으면 프록시 요청을 시작하기 전에 실패할 수 있습니다. 이 경우 비밀번호를 바꿔도 해결되지 않습니다.

인증서 오류가 발생했다고 인증서 검증을 건너뛰는 방식으로 해결하지 마세요. 검증을 끄면 연결 보안 범위가 달라지고, 이름 오입력이나 기기 시간 오류, 서버 인증서 문제를 놓칠 수 있습니다. 먼저 이름, 시간, 인증서 유효성을 확인한 뒤 서비스 제공자에게 설정을 문의하세요. 별도의 테스트 환경에서 자체 서명 인증서를 사용한다면 해당 환경의 신뢰 설정을 따르세요. 테스트 방법을 일상적인 설정에 그대로 적용하지 마세요.

Shadowsocks: 암호화 방식도 필수 설정입니다

Shadowsocks는 흔히 SS로 줄여 부르며, 가벼운 프록시와 암호화 전송을 중심으로 별도의 프로토콜 체계를 이룹니다. 클라이언트에는 보통 주소, 포트, 비밀번호, 암호화 방식이 필요합니다. 암호화 방식은 사용자가 임의로 고르는 취향 설정이 아니라 서버와 일치해야 하는 값입니다. 구형 스트림 암호화 방식과 널리 쓰이는 AEAD 방식, 최신 프로토콜 변형은 호환 범위가 다릅니다. 클라이언트 메뉴에 비슷한 이름이 있다고 서로 연결되는 것은 아닙니다.

암호화 방식에 따라 비밀번호 형식도 달라질 수 있습니다. 일부 방식은 일반 텍스트 비밀번호를 받지만, 새로운 방식은 특정 길이의 인코딩된 키를 요구할 수 있습니다. 텍스트 비밀번호를 그대로 넣으면 로컬에서 설정을 해석하는 단계부터 오류가 날 수 있습니다. 구독을 가져왔는데 주소와 비밀번호만 표시되고 방식, 플러그인, 추가 항목이 없다면 설정이 불완전할 수 있습니다. 플러그인 필요 여부는 서버 안내와 코어 지원을 기준으로 판단하세요. 임의로 삭제해도 기능이 유지된다고 가정하지 마세요.

SS는 설정이 간단하고 캡슐화 계층이 적다는 장점이 있지만 모든 기기에서 배터리를 덜 쓰거나 처리량이 더 높다는 뜻은 아닙니다. 실제 결과는 암호화 구현, 프로세서 성능, 전송 품질, 앱의 요청 방식에 따라 달라집니다. UDP가 필요한 서비스라면 서버와 로컬 접속 지점 모두 UDP 전달을 지원하는지도 확인해야 합니다. 웹페이지 하나를 열었다고 UDP까지 검증된 것은 아니며, 모든 앱이 작동한다고 판단할 수도 없습니다.

REALITY: 공개 키·짧은 ID·이름 확인하기

REALITY는 일반적인 인증서 배포와 다른 인증 방식을 사용합니다. 사용자가 확인하는 주요 항목은 서버 이름, 공개 키, 짧은 ID, 클라이언트 지문입니다. 공개 키는 서버 설정과 일치해야 하며 일반 인증서에서 임의로 복사할 수 없습니다. 짧은 ID도 메모처럼 보인다고 삭제하지 말고 그대로 입력하세요. 짧은 ID를 비워도 되는지는 서버 설정에 따라 다르므로 다른 설정의 값을 가져다 채우지 마세요.

클라이언트 지문은 핸드셰이크 특성과 관련된 설정이지 기기 인증용 비밀번호가 아닙니다. 현재 코어가 지원하고 서버 요구사항에 맞는 값을 사용해야 합니다. 임의로 바꾼다고 성능이 향상되지는 않습니다. 서버 이름 역시 아무 웹 도메인이나 선택하는 항목이 아니라 서버에서 허용한 이름이어야 합니다. 연결에 실패하면 포트를 계속 바꾸기보다 이름, 공개 키, 짧은 ID, 지문, 시간, flow 순서로 확인하세요.

최종 선택은 서버가 지원하는 기능을 기준으로 해야 합니다. 표준 인증서 검증이 필요하다면 명확히 관리되는 Trojan 설정을 검토하고, 기존 SS 서비스는 먼저 암호화 방식의 호환성을 확인하세요. REALITY를 사용한다면 해당 조합을 명확히 지원하는 Xray 코어를 우선 선택하세요. 프로토콜 이름만 바꿔 세 설정 사이를 전환할 수는 없습니다. 클라이언트가 연결을 맺으려면 구독에 포함된 전체 설정이 필요합니다.

연결 속도와 리소스 사용량

‘연결이 빠르다’는 말에는 적어도 세 가지 지표가 있습니다. 첫 요청이 성공하기까지 걸리는 시간, 연속 다운로드 처리량, 페이지의 여러 작은 요청이 완료되는 시간입니다. 프로토콜 헤더가 짧으면 처리 작업이 조금 줄 수 있지만 네트워크 왕복 횟수까지 줄어드는 것은 아닙니다. 지속 처리량이 높아도 페이지 첫 화면이 더 빨리 열린다고 할 수 없습니다. 선택 전에 주된 용도가 짧은 요청, 장시간 연결, 동영상 전송, 장시간 유휴 후 연결 재개 중 무엇인지 정하세요. 한 번의 테스트로 모든 상황을 판단하지 마세요.

핸드셰이크 과정을 나눠 살펴보기

첫 연결 요청은 도메인 조회, 하위 연결, 보안 협상, 프록시 인증, 대상 서버 연결을 차례로 거칠 수 있습니다. 전송 방식에 따라 애플리케이션 계층의 연결 과정이 추가되기도 합니다. 각 단계의 지연이 첫 응답 시간에 영향을 줍니다. 따라서 서버 거리, 도메인 조회 상태, 패킷 손실이 프로토콜 간 고정 헤더 차이보다 더 큰 영향을 주는 경우가 많습니다. 도메인 조회가 계속 시간 초과된다면 인증 프로토콜을 바꿔도 대기 시간이 바로 사라지지 않습니다.

WebSocket과 gRPC는 특정 서버 구성에 적합하지만 자체적인 캡슐화와 연결 관리 과정이 추가됩니다. 직접 전송은 구조가 대체로 단순하지만 서버의 접속 조건과 일치해야 합니다. ‘계층을 줄이겠다’며 전송 설정을 임의로 지우지 마세요. 연결을 더 빠르게 만드는 것이 아니라 올바른 서버에 요청을 보내지 못하게 될 수 있습니다. 비교할 때는 서버가 실제로 제공하는 조합을 사용하세요.

CPU·메모리·처리량의 관계

암호화 연산, 사용자 공간의 데이터 전달, 버퍼 복사, 규칙 조회는 모두 리소스를 사용합니다. 기기의 하드웨어 가속 여부, 코어 구현의 효율성, 앱이 동시에 만드는 연결 수에 따라 결과가 달라집니다. 저사양 기기는 CPU가 먼저 병목이 될 수 있고, 데스크톱은 원격 대역폭이 주된 제한 요소일 수 있습니다. 프로토콜 이름만으로 리소스 사용량을 일괄 순위화하면 실제 병목을 가리고 조정 가능한 설정을 찾기 어려워집니다.

메모리 사용량이 곧 프로토콜 부담을 뜻하는 것은 아닙니다. 규칙 데이터베이스, 도메인 조회 캐시, 연결 수, 클라이언트 화면, 로그 캐시도 메모리를 사용할 수 있습니다. 클라이언트를 오래 실행한 뒤 사용량이 늘었다고 해서 프로토콜 누수를 단정할 수 없습니다. 확인할 때는 클라이언트 프로세스와 코어 프로세스를 구분하고, 같은 작업 부하를 유지하세요. 사용량이 계속 증가해 줄어들지 않는지도 관찰한 뒤 문제를 신고할지 판단하세요.

연결 재사용과 유지 연결은 용도별로 확인하세요

연결을 재사용하면 반복적인 연결 수립 비용을 줄일 수 있지만 여러 업무가 전송 상태를 공유하게 됩니다. 하위 네트워크의 패킷 손실, 서버 구현, 연결 종료 정책에 따라 결과가 달라질 수 있습니다. 이미 다중 전송이 안정적으로 동작하는 조합에서 추가 재사용 옵션을 켜도 이점이 없을 수 있습니다. 일부 사이트만 멈추거나 대용량 파일은 정상인데 작은 요청이 실패한다면 설정 복사본에서 추가 재사용 옵션을 끄고 문제가 사라지는지 비교해 보세요.

연결 유지는 장단점이 있습니다. 연결을 적극적으로 유지하면 유휴 시간 후 재연결을 줄일 수 있지만 모바일 네트워크 모듈이 깨어나는 횟수가 늘 수 있습니다. 보수적으로 설정하면 백그라운드 활동은 줄지만 첫 요청 때 연결을 다시 맺어야 할 수 있습니다. 전원에 연결해 사용하는 데스크톱과 대기 시간이 긴 Android 기기에 같은 ‘성능 최적화’ 설정을 적용하지 마세요. 기본값부터 확인하고 구체적인 문제가 관찰될 때만 조정하는 편이 좋습니다.

반복 가능한 비교 방법

백그라운드 다운로드를 끄고 동일한 라우팅을 유지한 뒤 두 설정이 같은 업무 출구를 사용하는지 확인하세요. 그런 다음 최초 연결과 일정 시간 동안의 연속 전송을 각각 여러 차례 테스트하세요. 한 번의 결과만 보지 말고 실패율, 첫 응답, 전송 안정성, 기기 발열 여부를 기록하세요. 클라이언트의 지연 시간 테스트는 특정 테스트 주소나 핸드셰이크 일부만 측정할 수 있습니다. 실제 웹페이지나 UDP 사용 경험을 그대로 나타내지는 않습니다.

서버가 서로 다른 두 설정을 비교했다면 ‘현재 조건에서 이 두 설정의 성능이 달랐다’고만 결론 내릴 수 있습니다. 특정 프로토콜의 속도가 항상 더 빠르다는 증거는 아닙니다. 프로토콜의 영향을 분리하려면 서버 위치, 대역폭, 부하를 가능한 한 동일하게 맞추세요. 조건을 통제할 수 없다면 한 번의 테스트에서 나온 작은 차이를 따라 설정을 바꾸기보다 호환성, 유지 관리, 지속적인 사용 가능성을 우선하세요.

V2Fly와 Xray 코어 계열

Project V는 이 생태계를 이해하는 배경입니다. V2Ray는 처음에 인바운드, 아웃바운드, 라우팅, 전송을 조합할 수 있는 구조를 만들었습니다. V2Fly는 V2Ray 관련 코어 개발을 이어가고, Xray는 이 기술 기반에서 분기해 자체 프로토콜과 전송 기능을 더했습니다. 공통 용어와 설정 방식이 일부 있지만 두 코어를 아무 조건 없이 서로 바꿔 쓸 수는 없습니다. 코어를 선택할 때는 공통된 출처만 보고 호환된다고 판단하지 말고 필요한 기능을 확인하세요.

그래픽 클라이언트와 프록시 코어는 다릅니다

v2rayN은 데스크톱에서 서버 관리, 구독 업데이트, 설정 편집, 코어 실행을 담당합니다. 실제 데이터 처리는 선택한 코어가 수행합니다. v2rayNG는 Android에서 흔히 사용하는 Xray 클라이언트이며, v2flyNG는 V2Fly 코어를 사용하는 대안입니다. 클라이언트 화면에 버튼이 있는지와 코어가 관련 프로토콜을 지원하는지는 별개의 문제입니다. 비슷하게 보이는 설정도 코어에 따라 다른 구성으로 생성될 수 있습니다.

데스크톱에서는 구독 그룹, 로그, 시스템 프록시를 한 화면에서 관리할 수 있는 v2rayN을 우선 사용하세요. 코어 유형을 설정할 때는 대상 프로토콜에 어떤 구현이 필요한지 확인한 다음 전환하세요. Android에서는 앱이 사용하는 코어 계열에 맞춰 클라이언트를 선택하는 편이 좋습니다. 데스크톱의 코어 전환 절차를 Android 메뉴에 그대로 적용하지 마세요. 세부 메뉴 위치는 설치된 버전에 따라 다를 수 있습니다.

공통 항목이 있다고 전체 설정이 호환되는 것은 아닙니다

두 코어 모두 주소, 포트, 사용자, 라우팅 규칙과 같은 기본 개념을 처리할 수 있지만 지원하는 전송 이름, 프로토콜 확장, 설정 구조, 기본 동작은 다를 수 있습니다. REALITY와 Vision 같은 기능은 Xray의 지원 범위를 확인해야 합니다. V2Fly가 VLESS 유형을 읽을 수 있다고 해서 모든 Xray VLESS 조합을 처리할 수 있는 것은 아닙니다. 반대로 다른 코어로 옮길 때도 원본 설정의 전용 기능을 확인해야 합니다.

구독을 클라이언트에서 해석하면 대개 현재 코어에 맞는 설정이 생성됩니다. JSON 파일 전체를 직접 붙여 넣으면 일부 변환 과정을 건너뛰게 되어 다른 코어 전용 항목이 섞일 수 있습니다. 실행에 실패하면 먼저 로그에서 알 수 없는 항목, 프로토콜, 잘못된 매개변수 메시지를 확인하고 설정 출처를 살펴보세요. 프로그램을 실행하려고 오류가 난 항목을 무더기로 삭제하지 마세요. 삭제한 값이 연결에 필요한 인증이나 보안 설정일 수 있습니다.

라우팅 규칙: 의미와 리소스를 함께 확인하기

라우팅 설정은 아웃바운드 식별자와 규칙 데이터베이스를 참조합니다. 규칙 구문을 해석할 수 있더라도 대상 아웃바운드 태그가 없거나 참조한 geosite 분류가 로컬 데이터에 포함되지 않으면 실행에 실패하거나 예상과 다르게 트래픽이 분기될 수 있습니다. 아래는 사설 주소를 우선 직접 연결하는 의미를 보여 주는 Xray 라우팅 객체의 일부 예시입니다. 독립적으로 실행할 수 있는 전체 설정은 아닙니다. 적용 전에 direct라는 이름의 직접 연결 아웃바운드가 있는지 확인하고 필요한 규칙 데이터를 준비하세요.

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

이 규칙은 IP 조건으로 일치하는 요청만 처리합니다. AsIs는 IP 규칙을 적용하기 위해 모든 도메인을 자동으로 조회하지 않으므로, 이것만으로 완전한 LAN 도메인 및 조회 설정을 대신할 수는 없습니다. 실제 규칙은 로컬 서비스 접속 방식에 맞춰 보완해야 합니다. 데이터베이스의 출처, 업데이트, 참조 방법은 geoip.dat 및 geosite.dat 규칙 데이터베이스 안내에서 확인하세요. 데이터베이스 누락을 프로토콜 비호환으로 오해하지 않도록 주의하세요.

업그레이드와 전환 시 되돌릴 범위

코어 업데이트는 문제를 해결하고 기능을 추가할 수 있지만, 오래된 설정의 검증 조건을 강화할 수도 있습니다. 업데이트 전에 클라이언트 설정과 주요 사용자 항목을 저장하세요. 업데이트 후에는 작동이 확인된 설정 하나로 기본 연결을 확인한 다음 구독, 라우팅, 특수 전송을 점검하세요. 코어를 전환할 때는 먼저 현재 연결을 중지해 기존 프로세스 상태와 새 설정이 섞이지 않게 하세요. 화면에 표시된 이름보다 로그를 통해 새 코어가 실제로 시작됐는지 확인하는 편이 정확합니다.

오픈소스 라이선스를 한데 묶어 설명해서도 안 됩니다. V2Fly 코어 프로젝트는 일반적으로 MIT 라이선스를, Xray 코어 프로젝트는 MPL 2.0을 사용합니다. 클라이언트, 의존성 구성 요소, 포함 데이터의 라이선스는 다를 수 있으므로 해당 배포물의 안내를 확인하세요. 오픈소스는 구현과 라이선스를 살펴볼 수 있다는 뜻이지, 설정 확인과 인증서 검증, 서비스 제공자에 대한 독립적인 판단을 대신하지는 않습니다.

구독 형식과 설정 호환성

구독은 설정을 배포하는 방식이지 프록시 프로토콜이 아닙니다. 구독 주소가 공유 링크 목록, Base64로 인코딩된 텍스트, 특정 클라이언트용 구조화 설정 중 하나를 반환할 수 있습니다. 클라이언트는 먼저 외부 형식을 이해하고 각 항목을 자체 서버 모델로 변환한 다음 코어 설정을 생성해야 합니다. 따라서 ‘구독 주소가 열림’, ‘목록을 가져올 수 있음’, ‘서버에 연결됨’은 서로 다른 단계입니다. 한 단계에 성공해도 다음 단계가 정상이라는 보장은 없습니다.

공유 링크에 담을 수 있는 정보

일반적인 공유 링크는 프로토콜 접두사로 유형을 구분하지만, 프로토콜과 과거 구현에 따라 항목의 인코딩 방식이 다를 수 있습니다. VMess 링크에는 인코딩된 구조화 데이터가 흔히 사용됩니다. VLESS와 Trojan 링크는 주소와 쿼리 매개변수로 전송 및 보안 설정을 표현하는 경우가 많고, SS도 여러 인코딩 형식이 있습니다. 메모는 보통 화면에 표시하는 정보라 인증에 사용되지 않습니다. 반면 쿼리 매개변수의 경로, 이름, 보안 항목은 연결 여부를 좌우할 수 있습니다.

가져오기 도구가 프로토콜 접두사를 인식하더라도 링크의 확장 항목까지 지원하지 않을 수 있습니다. 서버가 목록에 표시된다고 해서 flow, 공개 키, 짧은 ID, 서비스 이름, 플러그인 설정이 모두 보존된 것은 아닙니다. 가져온 뒤 편집 화면에서 프로토콜, 보안, 전송 항목을 하나씩 확인하세요. 복잡한 설정에서는 값이 비어 있거나 오래된 기본값이 적용되고, 알 수 없는 항목이 무시되지 않았는지 특히 주의하세요.

Base64는 인코딩이지 접근 보호가 아닙니다

공유 링크 목록을 Base64로 인코딩하면 텍스트를 배포하기는 편하지만 계정 정보가 보호되는 것은 아닙니다. 구독 주소 자체에 접근 권한을 가진 토큰이 포함될 수도 있어 링크를 전달하면 업데이트 권한까지 넘기는 셈이 될 수 있습니다. 전체 구독 주소, QR 코드, 서버 정보를 공개 로그에 올리지 마세요. 도움을 요청할 때 프로토콜 유형, 오류 발생 단계, 가린 설정 항목 이름만 남겨도 대부분의 호환성을 확인할 수 있습니다.

구독을 업데이트한 뒤 목록이 비었다면 실제로 노드가 모두 삭제된 것이 아니라 로그인 페이지, 오류 안내, 지원하지 않는 형식이 반환됐을 수 있습니다. 먼저 링크 유효성과 구독 형식을 확인하고 업데이트에 기존 프록시가 필요한지도 살펴보세요. 현재 프록시가 작동하지 않는데 업데이트까지 해당 프록시에 의존하면 순환 문제가 생길 수 있습니다. 자세한 확인 순서는 구독 업데이트 실패·가져오기 결과 없음 점검표를 참고하세요. 그룹을 계속 삭제하고 다시 가져오지는 마세요.

클라이언트 간 설정 이전

v2rayN, v2rayNG, v2flyNG로 이전할 때는 여러 변환 도구를 거치기보다 대상 클라이언트가 지원하는 원본 구독을 사용하세요. 형식을 변환할 때마다 대상 형식에서 표현할 수 없는 설정이 빠질 수 있습니다. 구독 제공자가 여러 형식을 제공한다면 현재 클라이언트와 코어용으로 명시된 형식을 선택하세요. 다른 설정 형식을 내려받을 수 있다고 해서 이 세 클라이언트가 직접 읽을 수 있는 것은 아닙니다.

로컬에서 내보낸 단일 공유 링크는 소수의 설정을 옮길 때 편리하지만 전체 라우팅, DNS, 앱 적용 범위, 화면 설정까지 포함하는 경우는 드뭅니다. 서버 설정을 가져온 뒤 새 기기에서 이러한 로컬 설정을 다시 확인해야 합니다. Android의 앱별 라우팅 범위가 데스크톱 시스템 프록시 설정으로 자동 변환되지는 않습니다. 데스크톱 사용자 지정 라우팅도 단일 서버 링크에 포함되지 않을 수 있습니다. 계정 설정과 기기 정책을 따로 백업하면 이전 후 누락된 항목을 확인하기 쉽습니다.

업데이트 후 설정과 수동 수정

구독 그룹의 항목은 업데이트할 때 다시 생성될 수 있으므로 구독 노드의 포트, 이름, 보안 항목을 직접 수정해도 계속 유지되지 않을 수 있습니다. 설정을 테스트하려면 먼저 별도 항목으로 복사하고 출처와 수정 목적을 분명히 표시하세요. 그러면 다음 업데이트가 테스트 조건을 덮어쓰는 일을 막고, 제공자가 설정을 변경했다고 오해하는 일도 줄일 수 있습니다. 원래대로 되돌릴 때는 복사본만 삭제하면 되므로 그룹 전체를 다시 만들 필요가 없습니다.

여러 구독 그룹을 관리할 때는 프로토콜만으로 나누기보다 용도와 출처를 기준으로 구분하는 편이 관리하기 쉽습니다. 하나의 구독에 여러 프로토콜이 포함될 수 있고, 항목마다 설정이 바뀌는 시점도 다를 수 있습니다. 업데이트 후에는 자주 쓰는 항목이 남아 있는지, 선택 항목이 바뀌지 않았는지 확인하고 실제 접속을 테스트하세요. 문제가 생기면 업데이트 전의 작동 설정을 보관해 두면 서버 변경, 파싱 차이, 로컬 코어 문제를 구분하는 데 도움이 됩니다.

Android 배터리와 백그라운드 동작

모바일 배터리 사용량을 프로토콜 이름만으로 판단할 수는 없습니다. Android에서 프록시를 실행할 때는 무선 네트워크 전송, CPU 처리, 시스템 가상 네트워크 인터페이스, 백그라운드 앱 요청, 연결 유지 등 여러 요소가 전력을 소모합니다. 작은 요청이 반복해서 셀룰러 네트워크를 깨우면 한 번의 연속 다운로드보다 대기 전력에 더 큰 영향을 줄 수 있습니다. 신호가 약하면 재전송과 네트워크 검색이 늘어나 프로토콜 차이가 묻힐 수도 있습니다. 먼저 ‘사용 중 전력 소모’와 ‘화면을 끈 뒤에도 계속되는 활동’을 구분하세요.

v2rayNG와 v2flyNG 선택 기준

Xray 전용 조합이 필요하다면 Android에서 v2rayNG를 우선 고려하세요. 서버 설정이 V2Fly 기능에 의존하거나 해당 코어를 계속 사용해야 한다면 v2flyNG를 검토하세요. 두 클라이언트를 동시에 활성 VPN으로 실행할 수는 없습니다. 시스템에서 VPN 서비스 사용을 제한하기 때문입니다. 비교 테스트에서는 먼저 한 앱을 중지한 뒤 다른 앱을 실행하고, 동일한 앱 범위와 라우팅을 유지하세요. 그렇지 않으면 코어 차이가 아니라 서로 다른 작업 부하를 비교하게 됩니다.

VPN 서비스를 처음 시작할 때 표시되는 시스템 권한 확인은 로컬 트래픽 접속 절차일 뿐 서버 연결 성공을 뜻하지 않습니다. 연결 후 실제 대상에 접속해 요청이 로그에 나타나는지, 올바른 출구를 사용하는지 확인하세요. 일부 앱만 접속할 수 없다면 앱별 프록시 적용 범위와 우회 설정부터 살펴보세요. 앱을 VPN 대상에서 제외하면 해당 앱의 접속으로 프록시 서버 상태를 검증할 수 없습니다. 테스트할 때 어떤 경로를 사용하는지 확인하세요.

백그라운드 제한과 연결 안정성의 균형

시스템 절전 정책은 백그라운드 서비스, 네트워크 활동, 자동 시작을 제한할 수 있습니다. 화면을 끄면 연결이 끊기고 클라이언트로 돌아오자마자 복구된다면 먼저 시스템이 해당 앱의 백그라운드 실행을 제한하는지 확인한 뒤 사용 방식에 맞게 조정하세요. 기기마다 메뉴 이름은 다르므로 시스템 배터리 관리 화면을 기준으로 살펴보세요. 백그라운드 실행을 허용하면 연결을 유지하는 데 도움이 되지만 관련 앱을 전부 예외로 둘 필요는 없습니다. 필요한 범위만 바꾸고 되돌릴 수 있게 설정하세요.

연결은 계속 유지되는데 기기가 계속 뜨거워진다면 백그라운드 동기화, 실패한 재시도, 비정상적인 DNS 요청이 있는지 먼저 확인하세요. 요청이 반복해서 실패하면 연결이 계속 다시 만들어져 프록시 프로세스가 배터리를 소모하는 것처럼 보일 수 있지만 실제 원인은 특정 앱의 반복 요청일 수 있습니다. 앱 범위를 잠시 줄이거나 정상 작동이 확인된 라우팅 설정을 사용하면 원인을 좁힐 수 있습니다. 문제를 확인하는 동안에만 로그 상세 수준을 높이세요. 로그를 계속 대량으로 기록하면 처리량과 저장 활동이 늘어납니다.

DNS, UDP, 앱 적용 범위

도메인 조회 방식은 연결 전 대기 시간과 요청 수에 영향을 줍니다. 조회할 주소에 연결할 수 없거나, 라우팅 규칙이 조회 트래픽을 잘못된 출구로 보내거나, 로컬과 원격의 조회 결과가 다르면 재시도가 반복될 수 있습니다. ‘더 빠르게’ 하겠다며 조회 정책을 이해하지 못한 채 서버를 여러 개 추가하지 마세요. 설명할 수 있는 조회 경로 하나를 유지하고 일반 도메인, LAN 서비스, 프록시 대상이 각각 의도한 대로 처리되는지 확인한 뒤 항목을 하나씩 추가하세요.

실시간 통신과 일부 인터랙티브 서비스는 UDP에 의존할 수 있습니다. 프로토콜, 서버, 접속 경로가 UDP를 완전히 지원하지 않으면 앱이 다른 방식으로 전환하거나 반복해서 재시도해 사용 경험과 배터리 수명에 영향을 줄 수 있습니다. 웹페이지가 열린다고 UDP까지 정상인 것은 아닙니다. 실제 필요한 서비스를 이용해 테스트하고 연결이 끊기거나 오래 걸리거나 재접속이 반복되는지 확인한 뒤 코어 로그를 살펴보세요. 모든 문제를 Android 백그라운드 제한 탓으로 돌리지 마세요.

실제 대기 상태를 포함해 배터리 사용량 비교하기

신호 세기와 사용 시간을 비슷하게 맞추고 화면 밝기, 앱 적용 범위, 백그라운드 동기화를 동일하게 유지하세요. 한 번은 기기를 적극적으로 사용하는 동안, 다른 한 번은 화면을 끈 대기 상태에서 관찰하고 시스템 배터리 사용량에 표시되는 앱 활동을 기록하세요. 시스템의 배터리 비율은 추정치이므로 짧은 시간의 작은 차이만으로 결론 내리지 마세요. 한 번의 측정에서 1% 덜 줄었는지보다 대기 중 반복적인 깨우기, 지속적인 발열, 연결 재수립이 반복되는지가 더 중요합니다.

LAN 기기에 접속할 수 없다면 모든 트래픽을 프록시로 보내기보다 사설 주소와 로컬 도메인의 라우팅부터 확인하세요. 지역과 용도별로 규칙을 조합해야 한다면 v2rayNG 라우팅 설정 실전 가이드를 참고하세요. 실제 사용에 맞는 규칙을 세우면 불필요하게 원격 경로를 거치는 트래픽을 줄일 수 있습니다. 안정적이고 설명하기 쉬운 설정이 절전 옵션을 계속 덧붙이는 것보다 장기적으로 관리하기 좋습니다.

상황별 선택과 연결 검증

제약 조건에 따라 선택 범위를 차례로 좁히세요. 먼저 기기 플랫폼을 확인하고, 서버가 제공하는 전체 프로토콜 조합을 확인한 다음 호환되는 코어를 선택합니다. 마지막으로 용도에 맞게 라우팅과 접속 범위를 정하세요. 프로토콜은 따로 구매하는 성능 옵션이 아니라 클라이언트와 서버가 함께 따라야 하는 통신 조건입니다. 구독에서 유지 관리 가능한 설정을 하나만 제공한다면 먼저 그 설정의 동작을 완전히 검증하세요. 이름을 바꾸기 위해 관리 부담을 늘리기 전에 다른 조합이 꼭 필요한지 판단하세요.

데스크톱 일반 사용, Android 모바일, 기존 서버

Windows, macOS, Linux 데스크톱에서는 v2rayN을 우선 사용하고 프로세서 아키텍처와 시스템 패키지 형식에 맞춰 다운로드 페이지에서 파일을 선택하세요. 웹 탐색과 개발 앱이 함께 사용할 때는 이해하기 쉬운 시스템 프록시와 로컬 접속 설정부터 적용하고 어떤 프로그램이 시스템 설정을 따르는지 확인하세요. 특정 프로그램에서 SOCKS 설정을 직접 요구한다면 해당 프로그램에 접속 정보를 입력하세요. ‘전체 라우팅 모드’가 모든 앱의 네트워크를 자동으로 가로챈다고 해석하지 마세요.

Android에서는 서버 조합에 따라 v2rayNG 또는 v2flyNG를 선택한 뒤 모든 앱에 적용할지 특정 앱에만 적용할지 설정하세요. 모바일 네트워크와 Wi-Fi를 오갈 때 하위 연결을 다시 맺어야 할 수 있으므로 기존 연결이 잠시 끊겼다고 프로토콜이 불안정하다고 단정하지 마세요. 재연결이 계속 실패하면 조회 결과 변화, 원격 접속 가능 여부, 백그라운드 제한을 확인하세요. 로컬 기기를 자주 이용한다면 LAN 주소와 관련 도메인도 별도로 검증하세요.

안정적으로 작동하는 VMess, Trojan, SS 서비스가 있다면 정확한 설정과 구독 업데이트를 유지하는 데 집중하세요. 서버가 VLESS와 REALITY를 제공한다면 보안 항목과 flow를 명확히 지원하는 Xray 구성을 선택하세요. 기기 부담을 줄이고 싶다면 프로토콜만 바꾸기보다 불필요한 전달 계층, 비정상적인 재시도, 과도한 백그라운드 작업부터 줄이세요. 저사양 기기에서는 복잡한 설정을 겹치는 것보다 단순하고 지원이 확실한 조합을 검증하기 쉽습니다.

재검토할 수 있는 검증 순서 만들기

첫째, 로컬 설정으로 코어가 실행되는지 확인하세요. 코어가 바로 종료된다면 잘못된 항목, 포트 충돌, 규칙 데이터 누락을 먼저 해결해야 합니다. 이 단계에서는 요청이 아직 원격으로 정상 전달되지 않습니다. 둘째, 주소 조회와 원격 접속 지점에 연결할 수 있는지 확인하세요. 셋째, 보안 협상과 프로토콜 인증을 확인하세요. 앞의 세 단계가 완료된 뒤에야 대상 사이트, DNS, 라우팅을 점검하세요. 단계별로 처리하면 로컬 구문 오류를 서버 불안정으로 오해하지 않습니다.

넷째, 실제 업무를 검증하세요. 일반 웹페이지를 열고 필요한 업무 서비스와 LAN 주소에 접속하며, 필요한 경우 UDP 앱도 테스트하세요. 다섯째, 유휴 상태에서 복귀할 때와 네트워크를 전환할 때 연결을 확인하세요. 각 단계에서 사용한 클라이언트, 코어 계열, 프로토콜 조합, 결과를 기록하되 계정 정보는 공개하지 마세요. 문제가 발생한 단계의 짧은 로그를 보관하면 서버를 계속 바꾸며 기록을 뒤섞는 것보다 도움을 요청하기 쉽습니다.

규칙 순서와 검증 대상

라우팅 규칙은 보통 순서대로 적용됩니다. 앞쪽의 광범위한 규칙이 뒤쪽의 세부 조건보다 먼저 일치해 우선 적용될 수 있습니다. 프로토콜을 바꾼 뒤 일부 사이트의 동작이 달라졌다면 편집기의 서버 유형만 비교하지 말고 실제 생성된 라우팅 규칙과 기본 출구를 확인하세요. 도메인과 주소 조건을 직접 설정해야 한다면 Xray 사용자 지정 라우팅 규칙과 매칭 순서를 참고하세요. 규칙은 구체적인 용도에 맞춰 작성하고, 설명할 수 없는 예외를 한꺼번에 많이 가져오지 마세요.

검증을 마친 뒤에는 작동이 확인된 설정 하나를 기준으로 보관하세요. 앞으로 구독을 업데이트하거나 코어 또는 시스템을 바꿀 때 먼저 이 설정으로 기본 연결을 확인한 뒤 복잡한 라우팅과 특수 옵션을 다시 적용하세요. 기준 설정을 둔다고 업데이트를 막는 것은 아닙니다. 변경 사항을 비교할 출발점이 생기는 것입니다. 선택을 마쳤다면 일상적인 사용은 빠른 시작 가이드를 참고하세요. 이 문서는 프로토콜 경계, 호환 항목, 오류 발생 단계를 확인할 때 활용하면 됩니다. 연결할 때마다 모든 설정을 다시 조정할 필요는 없습니다.