V2Ray 프로토콜 및 코어 가이드

클라이언트, 코어, 서버는 서로 다릅니다

v2rayN, v2rayNG, v2flyNG는 구독 정보를 저장하고 설정을 표시하며 실행 매개변수를 생성하는 그래픽 클라이언트입니다. 시스템 프록시나 가상 네트워크 인터페이스도 관리합니다. 코어는 연결을 구성하고 프로토콜을 처리하며 도메인을 해석하고 라우팅을 적용합니다. 서버는 연결의 반대편에서 서비스를 제공하는 프로세스입니다. 화면에서 특정 항목을 선택할 수 있다는 것은 클라이언트가 해당 설정을 표현할 수 있다는 뜻일 뿐입니다. 실제 사용 가능 여부는 실행 중인 코어와 서버 설정에도 달려 있으므로, 화면의 지원 여부를 양쪽 끝의 완전한 지원으로 오해해서는 안 됩니다.

연결을 구성하는 요소는 여러 계층으로 나누어 생각할 수 있습니다. 프록시 프로토콜은 사용자 인증과 대상 주소 전달 방식을 정하고, 전송 계층은 데이터를 상대편까지 전달하는 방식을 담당합니다. 보안 계층은 연결을 보호하고 상대방의 신원을 확인하며, 라우팅은 어떤 요청을 이 연결로 보낼지 결정합니다. 인바운드는 로컬 앱의 트래픽을 받아들입니다. 각 요소는 함께 작동하지만 서로를 대신할 수 없습니다. 라우팅 모드를 바꿔도 잘못된 비밀번호는 해결되지 않으며, 시스템 프록시를 켜도 누락된 서버 인증서 이름이 자동으로 채워지지 않습니다.

프로토콜 이름은 연결의 일부만 설명합니다

예를 들어 VLESS는 여러 전송 및 보안 설정과 조합할 수 있습니다. 같은 VLESS 설정이라도 하나는 일반 TLS를 사용하고 다른 하나는 REALITY를 사용할 수 있으므로 필요한 항목과 서버 기능이 달라집니다. WebSocket은 데이터를 전달하는 전송 방식이지 VLESS와 같은 범주의 프록시 프로토콜이 아닙니다. TLS도 노드 인증 비밀번호의 다른 이름이 아닙니다. 구독 정보를 확인할 때는 프로토콜, 주소, 포트, 전송, 보안 방식, 인증 정보를 각각 확인하세요. 프로토콜 이름 하나만 기억해서는 충분하지 않습니다.

클라이언트의 ‘주소’는 보통 서버에 연결할 도메인이나 IP를 뜻합니다. ‘서버 이름’은 TLS의 serverName에 해당하며 SNI로 표시되기도 합니다. WebSocket의 Host와 경로는 애플리케이션 계층 요청에 속합니다. 세 항목이 같을 수도 있지만, 서버 설정에 따라 서로 다른 값을 입력해야 할 수도 있습니다. 보기 좋게 맞춘다며 모두 주소의 도메인으로 바꾸면 인증서 확인이나 리버스 프록시 라우팅이 깨질 수 있습니다. 필드 이름이 비슷한지보다 설정 제공자가 안내한 필드 대응 관계를 따르는 것이 가장 안전합니다.

가져오기 성공과 연결 성공을 따로 확인하기

가져오기에 성공했다는 것은 클라이언트가 입력 형식을 받아들이고 항목을 만들었다는 뜻입니다. 일부 고급 항목을 인식하지 못했거나 기본값이 원래 설정과 달라졌을 수도 있습니다. 실제 연결에는 주소 접근 가능 여부, 포트 개방 상태, 인증 정보 일치 여부, 올바른 보안 계층 설정, 라우팅 규칙이 모두 영향을 줍니다. 이름과 아이콘이 제대로 표시되는 노드라도 핸드셰이크 전에 연결이 실패할 수 있습니다. 따라서 먼저 세부 설정을 확인하고 단일 연결을 테스트한 뒤 사용 경험을 비교하세요.

계층별로 나누면 문제 범위를 좁히기도 쉽습니다. 요청 로그가 전혀 없다면 인바운드와 라우팅을 먼저 확인하세요. 서버에는 연결되지만 인증에 실패한다면 프로토콜 인증 정보를 확인합니다. 인증서나 핸드셰이크 오류는 보안 계층과 시스템 시간을 살펴보세요. 특정 사이트만 실패한다면 DNS, 대상 사이트, 라우팅 규칙을 확인해야 합니다. 프로토콜, 코어, 라우팅을 한꺼번에 바꾸는 것보다 계층별로 점검하는 편이 문제를 재현하기 쉽습니다. 주요 필드의 간단한 정의는 용어 가이드에서 확인할 수 있으며, 이어지는 내용에서는 각 계층의 선택 기준과 한계를 자세히 설명합니다.

VMess: 프로토콜 자체의 인증과 데이터 보호

VMess는 Project V 생태계와 함께 발전했으며 사용자 식별자를 이용해 인증하고 프로토콜 자체에서 데이터를 보호합니다. 바깥쪽에만 보안 채널을 구성하는 방식과 달리 프록시 프로토콜이 더 많은 역할을 맡습니다. 실제 설정에서는 UUID뿐 아니라 구현에서 사용하는 인증 방식과 암호화 옵션도 확인해야 합니다. 구형 설정의 추가 식별자 필드는 과거의 배경이 있으므로 오래된 문서를 따라 값을 임의로 추가하지 마세요. 최신 서버에 연결할 때는 양쪽 구현에서 지원하는 인증 방식이 기준입니다.

VMess 인증에는 시간 조건이 있습니다. 기기 시간이 크게 어긋나면 인증에 실패할 수 있지만 오류 메시지에 시간 문제가 직접 표시되지 않을 수도 있습니다. 문제를 확인할 때는 구독 정보를 반복해서 새로 고치기보다 시스템의 자동 시간 설정을 켜고 인증 로그를 살펴보세요. 이미 안정적으로 운영 중이고 클라이언트와 서버 설정이 명확하다면 VMess를 계속 사용할 수 있습니다. 다른 프로토콜을 따라가려고 정상 작동하는 연결을 굳이 옮길 필요는 없습니다. 프로토콜의 역사가 길다는 사실만으로 성능을 판단할 수 없으며 실제 구현의 유지 관리 상태도 따로 확인해야 합니다.

VLESS: 각 계층에 적절한 역할 맡기기

VLESS는 비교적 간결한 프록시 프로토콜로, 인증과 요청 표현을 담당합니다. VMess와 달리 프로토콜 자체에서 같은 방식으로 데이터를 암호화하지 않습니다. 따라서 VLESS 설정에서 encryption 값이 none이어도 연결 전체가 반드시 평문이라는 뜻은 아닙니다. 실제 보호는 TLS나 REALITY에서 제공될 수 있습니다. 반대로 VLESS라는 이름만 보고 연결이 보호되고 있다고 단정해서도 안 됩니다. 드롭다운 메뉴의 none만 따로 해석하지 말고 보안 계층을 함께 확인하세요.

VLESS의 flow도 주의해서 살펴봐야 하는 항목입니다. Vision 관련 값처럼 특정 트래픽 처리 방식을 나타내지만, 모든 전송 방식과 자유롭게 조합할 수 있는 것은 아닙니다. 클라이언트에서 값을 입력할 수 있다고 서버도 지원하는 것은 아니며, 구독에 이 항목이 없다고 임의로 추가해야 하는 것도 아닙니다. 서버에서 flow를 지정했다면 값을 그대로 유지하고 코어 지원 여부를 확인하세요. 설정 항목이 적으니 아무렇게나 조합해도 된다는 생각은 흔한 오해입니다. 프로토콜 자체의 역할이 줄어들수록 각 계층의 경계를 더 분명히 이해해야 합니다.

Trojan: TLS 기반 프록시 연결

Trojan은 일반적으로 바깥쪽에서 TLS로 연결을 보호한 뒤 그 안에서 비밀번호 인증과 프록시 요청을 처리합니다. 사용자가 주로 다루는 항목은 서버 주소, 포트, 비밀번호, 서버 이름입니다. 비밀번호 인증과 인증서 검증은 서로 다른 역할을 합니다. 전자는 사용 권한을 확인하고, 후자는 의도한 상대방에 연결되었는지 확인하는 데 도움을 줍니다. 따라서 비밀번호를 고쳐도 인증서 이름 불일치가 해결되지 않으며, 인증서 검증을 끄더라도 잘못된 비밀번호가 고쳐지지 않습니다. 어떤 단계에서 실패했는지 먼저 확인하세요.

Trojan을 선택할 때는 인증서 체인, 서버 이름, 리버스 프록시 구성 여부를 확인하세요. 도메인으로 연결하면 인증서와 연결 대상의 관계를 명확히 유지하기가 더 쉽습니다. 주소에 IP를 입력하더라도 유효한 서버 이름을 별도로 지정해야 할 수 있습니다. 추가 전송 방식이나 연결 재사용 지원 여부는 사용 중인 코어와 서버 구현을 확인해야 합니다. 특정 클라이언트의 확장 기능을 모든 Trojan 서버가 공통으로 제공한다고 간주해서는 안 됩니다. 기본 프로토콜과 구현별 확장 기능은 구분해서 이해하세요.

Shadowsocks: 간결한 데이터 캡슐화와 암호화 방식 호환성

Shadowsocks는 일반적으로 프록시 데이터 스트림을 직접 암호화하고 캡슐화합니다. 설정에서 가장 중요한 항목은 주소, 포트, 암호화 방식, 비밀번호입니다. 반드시 인증서 핸드셰이크를 사용해야 하는 것은 아니어서 바깥쪽 구성 요소를 줄이려는 환경에서 쓰이기도 합니다. 다만 Shadowsocks라는 이름만으로 모든 암호화 방식이 서로 호환되는 것은 아닙니다. 기존 방식, 최신 AEAD 방식, Shadowsocks 2022 계열은 요구 사항이 다르고 비밀번호의 표기와 길이 제한도 달라질 수 있습니다. 암호화 방식 이름을 빠뜨린 채 비밀번호만 복사하지 마세요.

구체적인 선택은 실제 배포 환경에 맞춰야 합니다. 어떤 서버를 사용하는지, UDP가 필요한지, 기기의 코어가 어떤 암호화 방식을 지원하는지, 구독에 필요한 설정값이 모두 포함되어 있는지 확인하세요. 가볍다는 이유만으로 Shadowsocks가 모든 휴대전화에서 배터리를 더 적게 쓴다고 단정하거나, VLESS의 설정 항목이 적다는 이유만으로 반드시 더 빠르다고 판단하지 마세요. 자세한 비교는 네 가지 프로토콜의 사용 환경별 비교에서 확인할 수 있습니다. 여기서 기억할 점은 호환성과 기능을 먼저 충족한 뒤 같은 조건에서 오버헤드를 비교하는 것입니다.

REALITY는 보안 메커니즘이지 독립된 프록시 프로토콜이 아닙니다

REALITY는 VLESS와 함께 쓰이는 경우가 많지만 둘은 같은 계층에서 선택하는 대체 옵션이 아닙니다. VLESS는 프록시 요청을 처리하고 REALITY는 바깥쪽 연결의 보안 핸드셰이크와 관련 검증을 처리합니다. 클라이언트에서 자주 보이는 항목은 서버 이름, 서버 공개 키 관련 값, 짧은 ID, 클라이언트 지문입니다. 서버의 개인 키를 클라이언트 구독에 넣어서는 안 됩니다. 클라이언트에 따라 공개 키 관련 항목 이름이 다를 수 있으므로 필드 이름의 신구만 보고 설정이 맞는지 판단하지 말고 사용 중인 클라이언트와 코어 문서를 확인하세요.

REALITY 핸드셰이크가 성공하려면 클라이언트 매개변수와 서버 설정이 맞아야 합니다. 서버 이름은 일반적으로 서버에서 허용하는 범위에 포함되어야 하며, 공개 키 관련 값은 서버 키와 짝이 맞아야 합니다. 짧은 ID도 서버에서 허용하는 값이어야 합니다. 일부 서버는 짧은 ID를 비워도 되지만, 지정된 값을 요구하는 서버도 있으므로 일괄적으로 판단할 수 없습니다. 클라이언트 지문은 핸드셰이크의 관련 특성을 구성하는 값입니다. 브라우저 이름을 아무렇게나 입력한다고 연결이 나아지는 것은 아니며, 유효한 값과 동작은 코어 구현에 따라 달라집니다.

TLS: 포트 연결 여부보다 중요한 이름 검증

일반 TLS 연결에서는 인증서 체인과 인증서 이름을 확인해야 합니다. 서버 포트에 TCP 연결이 된다는 것은 네트워크 계층에서 해당 지점까지 도달했다는 뜻일 뿐, 상대방 인증서가 신뢰할 수 있거나 프록시 인증이 성공했다는 의미는 아닙니다. 흔한 문제로는 기기 시간 오류, 서버에서 중간 인증서를 모두 보내지 않는 경우, 서버 이름과 인증서 불일치, 리버스 프록시가 요청을 잘못된 인바운드로 전달하는 경우가 있습니다. 검증을 건너뛰는 설정을 고정값으로 남기지 말고 인증서와 서버 구성을 바로잡으세요.

ALPN은 애플리케이션 계층 프로토콜을 협상하는 데 사용되며 임의로 켜는 속도 향상 옵션이 아닙니다. 특정 전송 방식은 정해진 협상 결과에 의존할 수 있고, 서버에 따라 결과에 맞춰 처리 경로를 선택하기도 합니다. 값을 직접 삭제하거나 바꾸면 핸드셰이크 이후 요청이 실패할 수 있습니다. 구독에 ALPN이 있으면 우선 해당 값을 유지하세요. 구독에 없다면 다른 노드의 설정을 무작정 복사하지 마세요. 선택 사항처럼 보이는 항목도 실제 배포 환경에서는 분명한 역할을 할 수 있습니다.

TCP·WebSocket·gRPC의 실제 비용

TCP를 직접 전송에 사용하면 경로가 비교적 단순하고 추가 캡슐화가 적습니다. WebSocket은 HTTP 업그레이드를 먼저 완료한 뒤 데이터를 전달하므로 경로와 Host를 맞춰야 합니다. gRPC는 일반적으로 HTTP/2에 의존하며 서비스 이름과 중간 프록시의 지원이 필요합니다. 이런 전송 방식은 데이터 전달과 배포 환경에 맞추기 위한 것이지, 복잡할수록 더 발전했다는 뜻은 아닙니다. 이름이 최신인 방식을 고르기보다 서버가 실제로 지원하는 조합을 선택하세요.

리버스 프록시를 거치는 경우 프록시의 유휴 시간 제한, 요청 크기 제한, 지속 연결 처리, 업스트림 프로토콜도 고려해야 합니다. 웹 페이지는 정상적으로 열리지만 장시간 연결이 주기적으로 끊긴다면 특정 계층의 시간 제한 때문일 수 있으며 프록시 프로토콜 인증이 갑자기 실패한 것은 아닐 수 있습니다. WebSocket 경로의 문자 하나가 다르거나 변환 과정에서 gRPC 서비스 이름이 사라져도 서버가 일반 HTTP 오류를 반환할 수 있습니다. 이때는 로컬 리스닝 포트를 계속 바꾸기보다 경로와 프록시 로그를 확인하세요.

연결 재사용과 UDP는 전체 경로를 기준으로 판단해야 합니다

연결 재사용은 여러 논리 연결이 하나의 하위 연결을 공유하도록 해 반복적인 연결 설정을 줄일 수 있습니다. 하지만 공유 연결에서 발생한 혼잡이나 장애가 여러 연결에 동시에 영향을 줄 수도 있습니다. 전송 방식 자체가 이미 다중화 기능을 제공한다면 재사용을 추가해도 이득이 없을 수 있습니다. 활성화 여부는 코어, 프로토콜, 서버, 앱의 특성을 고려해 결정하세요. 모든 상황에서 켜야 하는 옵션으로 취급하지 마세요. 특히 문제 해결 단계에서는 단순한 조합으로 기준을 잡고 연결 재사용을 켜기 전후의 짧은 요청과 장시간 전송을 비교하세요.

UDP 지원 여부는 인바운드, 프록시 프로토콜, 코어 캡슐화, 서버, 대상 네트워크가 함께 지원하는지에 달려 있습니다. 로컬 SOCKS 인바운드가 UDP를 받을 수 있어도 일반 HTTP 프록시 인바운드에서 같은 방식으로 동작한다는 뜻은 아닙니다. 앱이 해당 인바운드를 사용하지 않으면 프로토콜이 UDP를 완벽히 지원해도 실제로 적용되지 않습니다. 음성 통화, 게임 등 UDP 앱에 문제가 생기면 데이터가 클라이언트로 들어오는 방식부터 아웃바운드 전달, 서버 정책까지 차례로 확인하세요. ‘노드가 UDP를 지원한다’는 표시만으로 결론을 내릴 수 없습니다.

연결 지연, 첫 응답, 지속 처리량을 구분하세요

클라이언트에 표시되는 TCP 지연 시간은 보통 서버 포트까지 연결을 맺는 데 걸리는 시간을 나타냅니다. 실제 요청 테스트에는 보안 핸드셰이크, 프록시 인증, 대상 사이트의 응답 시간이 포함될 수도 있습니다. 측정 대상이 다르므로 두 결과를 서로 바꿔 해석할 수 없습니다. TCP 응답이 빠른 인바운드라도 대상 경로, DNS, 서버 부하 때문에 웹 페이지가 느리게 열릴 수 있습니다. 반대로 특정 탐지에 실패했더라도 테스트 대상이나 방식이 맞지 않았을 수 있으므로 모든 업무 연결이 실패한다고 단정할 수 없습니다.

첫 응답 시간은 새 요청을 보낸 뒤 데이터를 받을 때까지 걸리는 시간이고, 지속 처리량은 연결을 맺은 뒤 얼마나 많은 데이터를 전송할 수 있는지를 나타냅니다. 보안 핸드셰이크와 전송 업그레이드는 첫 응답에 더 큰 영향을 주며, 회선 대역폭, 혼잡 제어, 서버의 외부 연결 용량은 지속 처리량에 더 큰 영향을 줍니다. 웹 페이지는 작은 리소스를 여러 개 동시에 요청하므로 대용량 파일 전송이 원활해도 페이지 렌더링이 빠르다는 보장은 없습니다. 프로토콜을 비교하기 전에 새 연결, 일반 웹 사용, 장시간 전송 중 무엇을 개선하려는지 정하세요. 측정 지표와 목표가 어긋나지 않도록 해야 합니다.

프로토콜 비용은 같은 조건에서 비교해야 합니다

프로토콜 캡슐화, 인증, 암호화에는 연산 자원이 들지만 이것만이 사용 경험을 좌우하는 것은 아닙니다. 원격 서버와의 거리, 패킷 손실, 네트워크 전환, 서버 혼잡, 대상 사이트 차이가 프로토콜 헤더의 작은 차이보다 더 크게 작용하는 경우가 많습니다. 제대로 비교하려면 가능한 한 같은 기기, 네트워크, 서버 지역, 테스트 대상을 사용하세요. 두 구독이 서로 다른 서버에 연결된다면 결과는 두 연결 경로 전체의 차이를 보여줄 뿐, 프로토콜 이름만의 차이를 설명하지 않습니다.

하드웨어 성능도 결과를 바꿀 수 있습니다. 프로세서마다 암호화 알고리즘 가속 지원이 다르고 코어 구현, 시스템 스케줄링, 온도 제한도 처리 시간에 영향을 줍니다. 노트북은 전원 연결 여부나 절전 모드에 따라 성능이 달라질 수 있으며, 휴대전화는 장시간 실행 후 발열 제어로 작동 속도가 낮아질 수 있습니다. 기기와 테스트 조건이 일정하지 않다면 누구에게나 적용되는 리소스 사용량 순위를 제시하기 어렵습니다. 일반 사용자에게는 작은 순간 차이를 쫓기보다 안정적으로 작동하고 앱 요구 사항을 충족하는 편이 더 중요합니다.

메모리와 배터리 사용량은 실행 방식에 따라 달라집니다

메모리는 프로토콜 처리뿐 아니라 연결 버퍼, DNS 캐시, 라우팅 리소스, 클라이언트 목록에도 사용됩니다. 많은 노드를 가져오거나 상세 로그를 오래 보관하거나 대규모 규칙을 불러오는 일이 프록시 프로토콜을 바꾸는 것보다 사용량에 더 큰 영향을 줄 수 있습니다. 그래픽 클라이언트와 코어 프로세스를 구분하고 실행 직후가 아니라 안정적으로 작동한 뒤의 상태를 비교하세요. 중복 그룹을 삭제하고 불필요한 로그 보관 기간을 줄이는 편이 숫자를 낮추려고 코어를 반복해서 바꾸는 것보다 결과를 이해하기 쉽습니다.

모바일 기기의 배터리 사용량은 무선 모듈이 깨어나는 빈도와 밀접한 관련이 있습니다. 잦은 연결 확인, 지나치게 짧은 연결 유지 간격, 불안정한 네트워크에서의 지속적인 재연결, 백그라운드 앱의 반복 요청은 기기가 활성 상태로 머무는 시간을 늘릴 수 있습니다. 한 번의 핸드셰이크가 조금 짧은 프로토콜이라도 실제 네트워크에서 계속 연결이 끊기면 배터리를 더 많이 쓸 수 있습니다. 유휴 상태, 일반적인 웹 탐색, 네트워크 전환 후 동작을 함께 살펴보세요. 짧은 테스트 한 번으로 하루 종일 사용할 때의 영향을 판단해서는 안 됩니다.

반복 가능한 비교 기록 만들기

먼저 정상 작동이 확인된 설정 하나를 남기고 테스트 사이트와 앱을 고정하세요. 첫 요청, 지속 전송, 유휴 상태 유지, 네트워크 전환 후 복구 여부를 각각 기록합니다. 매번 변수를 하나만 바꾸고 테스트 후에는 기준 설정으로 되돌린 다음 다음 항목을 확인하세요. 프로토콜, 서버, DNS를 동시에 바꾸면 사용 경험이 나아져도 원인을 설명하기 어렵습니다. 노드 속도 측정은 참고 자료일 뿐 최종 판단 기준이 아닙니다. 실제 작업을 중단 없이 완료할 수 있는지, 오류를 재현할 수 있는지를 기준으로 삼으세요.

Project V, V2Fly, Xray의 관계

Project V는 이 도구 생태계를 이해하기 위한 배경이며, V2Ray는 그 안에서 널리 사용된 코어 구현이었습니다. V2Fly 커뮤니티는 V2Ray 코어의 개발과 유지 관리를 이어가고 있습니다. Xray는 관련 코드 기반에서 출발해 독립 프로젝트로 발전했으며 자체 기능 방향에 따라 계속 개선되고 있습니다. 두 프로젝트는 역사적 연관성이 있고 여러 개념을 공유하지만 같은 프로그램에 표시 이름만 다른 것은 아닙니다. 문서를 읽을 때 어느 코어를 대상으로 하는지 확인해 한쪽에 추가된 기능이 다른 쪽에도 당연히 있다고 오해하지 마세요.

두 코어 모두 프록시 연결, 라우팅, 도메인 조회 등을 처리할 수 있지만 프로토콜 확장, 전송 세부 사항, DNS 동작, 설정 항목은 점차 달라지고 있습니다. REALITY와 XTLS Vision은 Xray의 기능 방향을 이해할 때 자주 접하는 내용입니다. 그렇다고 V2Fly의 같은 이름 설정 위치에서 동일한 매개변수를 사용할 수 있다는 뜻은 아닙니다. 반대로 V2Fly 문서에 나온 전송 방식이나 특정 옵션도 공통된 과거만 보고 Xray에서 완전히 호환된다고 판단하지 말고 현재 구현에서 따로 확인하세요.

클라이언트 세 가지의 선택 기준

데스크톱에서는 구독 관리와 아웃바운드 설정 확인에 편리한 v2rayN을 우선 고려하세요. Windows, macOS, Linux를 지원합니다. 배포 패키지마다 화면과 포함된 구성 요소가 다를 수 있으므로 선택 전에 클라이언트 다운로드 페이지에서 운영체제와 아키텍처 안내를 확인하세요. Windows 데스크톱판은 크로스 플랫폼 인터페이스를 사용하며 기존 WPF판은 별도의 인터페이스 방식을 유지합니다. 이는 클라이언트 화면과 배포 형식의 차이이지 특정 프로토콜이 더 빠르거나 코어 기능이 더 많다는 의미는 아닙니다.

Android에서는 Xray 코어를 사용하는 v2rayNG를 우선 고려하고 V2Fly 호환성을 확인해야 한다면 v2flyNG를 검토하세요. 두 앱의 화면 구성과 개념이 비슷하더라도 프로토콜 확장 지원 범위까지 같다는 뜻은 아닙니다. 기존 구독에 Xray 전용 매개변수가 있다면 가져온 뒤 모르는 항목을 하나씩 삭제하기보다 선택한 클라이언트와 코어가 맞는지 먼저 확인하세요. 항목을 지우면 실행은 될 수 있어도 서버 요구 사항과 다른 설정이 될 수 있습니다.

설정 문법이 비슷해도 그대로 옮길 수 있는 것은 아닙니다

코어 JSON에서 인바운드, 아웃바운드, 라우팅 구조는 비슷한 개념을 사용하지만 필드 구성, 기본값, 허용되는 조합까지 항상 같은 것은 아닙니다. 설정을 파서가 받아들였다고 해서 예상대로 작동한다는 보장은 없습니다. 알 수 없는 필드가 무시되거나 기본 라우팅이 달라지고 DNS 조회 경로가 바뀔 수 있습니다. 마이그레이션할 때는 먼저 프로토콜과 보안 계층을 확인하고 전송 방식, 라우팅, DNS를 차례로 검토하세요. 복잡한 설정 전체를 한 번에 옮기면 문제가 생겼을 때 차이의 원인을 찾기 어렵습니다.

클라이언트는 보통 자체 노드 모델을 코어 설정으로 변환합니다. 화면에서 항목을 수정해도 다음 실행 때 생성 파일이 다시 덮어써질 수 있으므로 임시 실행 파일을 직접 편집하는 것은 지속적인 해결책이 아닙니다. 고급 설정이 필요하면 클라이언트에서 공식 지원하는 사용자 지정 설정 메뉴를 이용하고, 기본 라우팅을 대체하는지 구독 업데이트를 계속 반영하는지 확인하세요. 실행 로그로 실제로 어떤 코어가 시작되었는지 알 수 있지만 파일 경로와 설정 내용이 공개되지 않도록 주의하세요.

업데이트와 마이그레이션에는 되돌릴 방법을 마련하세요

클라이언트 업데이트와 코어 업데이트는 서로 다른 문제를 해결합니다. 클라이언트 업데이트는 화면, 구독 파싱, 매개변수 생성 방식을 바꿀 수 있고 코어 업데이트는 프로토콜 구현이나 실행 동작을 바꿀 수 있습니다. 업데이트 후 문제가 생기면 무엇이 바뀌었는지 기록하고 모든 문제를 ‘새 버전이 불편하다’고 뭉뚱그리지 마세요. 소수의 설정으로 기본 연결, 자주 쓰는 앱, 네트워크 전환을 확인한 뒤 전체 규칙을 복원하세요. 필요한 이유가 없다면 새 확장 기능을 시험하려고 모든 구성 요소를 한꺼번에 바꾸지 않아도 됩니다.

되돌릴 방법을 마련한다고 해서 구형 구현을 계속 써야 하는 것은 아닙니다. 변경점을 비교하고 원인을 찾기 위한 기준을 남기는 것입니다. 업데이트 전에 필요한 설정을 내보내고 주요 화면 옵션을 기록한 다음 실행 로그와 실제 요청을 비교하세요. 화면에 표시된 코어 종류가 예상과 다르면 먼저 클라이언트 설정을 바로잡으세요. 특정 확장 기능만 실패한다면 해당 기능의 문서를 확인합니다. 생태계, 클라이언트 기능, 실제 실행 코어를 구분하면 ‘설정은 같은데 왜 다르게 작동할까’라는 오해를 대부분 피할 수 있습니다.

구독 URL, 공유 링크, 실행 설정

구독 URL은 여러 설정을 가져오는 주소이고, 단일 노드 공유 링크는 연결 하나를 표현하며, 코어 실행 설정은 프로세스의 동작 방식을 설명합니다. 세 가지는 서로 다른 형식입니다. 구독 응답은 여러 줄의 링크일 수도 있고 Base64로 인코딩되거나 특정 클라이언트 전용 구조를 사용할 수도 있습니다. 브라우저에서 URL이 열린다는 것은 서버가 내용을 반환했다는 뜻일 뿐입니다. 로그인 페이지, 안내 문구, 오류 페이지가 반환되면 클라이언트는 형식 오류를 표시할 수 있습니다. 업데이트가 실패하면 네트워크 연결 문제와 응답 형식 문제를 구분해서 살펴보세요.

흔한 공유 링크 형식에는 vmess, vless, trojan, ss 등의 URI 스킴이 있습니다. VMess 공유 링크는 과거에 인코딩된 JSON 데이터를 사용하는 경우가 많았습니다. VLESS와 Trojan은 연결 매개변수를 쿼리 부분에 넣는 경우가 많고, Shadowsocks는 인증 정보를 인코딩하는 등 여러 표기 방식을 사용합니다. 공유 링크의 매개변수는 형식 규약의 일부이지 임의의 메모가 아닙니다. 같은 프로토콜도 공유 형식에 따라 필드 이름이 달라지거나 표현 가능한 정보에 제한이 있을 수 있으므로 앞부분만 보고 호환성을 판단하지 마세요.

가져오는 과정에서 누락되기 쉬운 항목

고급 보안 매개변수, flow, ALPN, 클라이언트 지문, WebSocket Host와 경로, gRPC 서비스 이름, 일부 UDP 캡슐화 옵션을 중점적으로 확인하세요. 일부 구독 형식은 기본 연결 정보만 표현할 수 있어 코어의 모든 기능을 전달하지 못합니다. 변환기가 필드를 인식하지 못하면 그대로 생략할 수 있고, 클라이언트가 지원하지 않으면 메모와 기본 주소만 남을 수도 있습니다. 가져오기에 성공한 것처럼 보이더라도 원래 설정과 같지 않을 수 있습니다.

인코딩 방식도 결과에 영향을 줍니다. 쿼리 매개변수의 특수 문자는 올바르게 퍼센트 인코딩해야 하는 경우가 많고 링크 설명과 인증 정보에도 서로 다른 인코딩 규칙이 적용될 수 있습니다. 복사 중 끝부분이 잘리거나 링크 중간에 줄바꿈이 들어가거나 인코딩된 내용을 두 번 디코딩하면 파싱 결과가 달라질 수 있습니다. 링크를 읽기 좋게 만들려고 기호를 직접 바꾸지 마세요. 수정이 필요하다면 공유 텍스트의 모양만 비교하지 말고 클라이언트 상세 화면에서 필드별 값을 확인하세요.

구독 업데이트 실패 시 확인 순서

먼저 URL이 완전한지 확인하세요. 특히 쿼리 매개변수가 있는 링크가 잘리지 않았는지 살펴봅니다. 로그인이 필요한지, 구독이 만료되었는지, 기기에서 구독 서버에 접근할 수 있는지도 확인하세요. 로그에 네트워크 시간 초과가 표시된다면 구독을 가져올 때 직접 연결하는지 현재 프록시를 이용하는지 확인합니다. 일부 클라이언트는 업데이트 경로를 여러 방식으로 제공하므로 현재 프록시를 사용할 수 없는데 이를 거쳐 구독을 갱신하려 하면 순환 문제가 생길 수 있습니다. 같은 버튼을 반복해서 눌러 다른 결과를 기다리기보다 현재 환경에서 접근할 수 있는 경로를 선택하세요.

요청에는 성공했지만 파싱에 실패한다면 응답이 웹 페이지가 아니라 해당 클라이언트에서 지원하는 구독 형식인지 확인하세요. 주소와 응답에 계정 정보가 포함될 수 있으므로 전체 구독을 낯선 변환 서비스에 업로드하지 마세요. 올바른 형식을 설정 제공자에게 문의하는 편이 더 간단합니다. 문제를 설명할 때는 오류 유형, 클라이언트 이름, 선택한 코어, 민감 정보를 가린 필드 구조를 전달하면 됩니다. 구독 URL 전체나 인증 정보를 공개 토론에 올릴 필요는 없습니다.

그룹 관리와 업데이트 덮어쓰기 범위

구독 노드는 업데이트할 때 다시 생성되므로 직접 수정한 내용이 덮어써질 수 있습니다. 장기간 보관해야 할 테스트 설정은 별도의 로컬 그룹에 복사하고 용도를 분명하게 표시하세요. 다만 그룹 메모는 보안 격리 기능이 아니라 항목을 정리하기 위한 표시입니다. 그룹을 삭제하기 전에 구독에서 가져온 노드와 직접 관리하는 노드가 섞여 있는지 확인해 함께 지우는 일이 없도록 하세요. 중복 항목을 주기적으로 정리하면 오래된 인바운드를 잘못 선택할 가능성도 줄어듭니다.

클라이언트 간 마이그레이션은 전체 구독을 가져오기 전에 설정 하나를 옮겨 양쪽의 값을 비교하세요. 노드 수가 같은지보다 주요 매개변수가 그대로 유지되었는지가 중요합니다. 기본 설정은 같은데 기능이 다르다면 코어 호환성 항목에서 확장 지원을 확인하세요. 연결은 정상이지만 분할 라우팅이 다르면 클라이언트의 로컬 라우팅을 살펴봐야 합니다. 구독이 전체 라우팅 정책까지 제공하는 것은 아닙니다. 구독은 연결 정보를 전달하고 이를 사용하는 방식은 로컬 클라이언트가 결정합니다.

데스크톱 업무: 앱의 연결 경로부터 통일하세요

데스크톱에서는 먼저 v2rayN으로 단순하고 검증 가능한 구성을 만드세요. 브라우저, 터미널, 업무용 소프트웨어가 같은 프록시 인바운드를 사용하는 것은 아닙니다. 일부 앱은 시스템 프록시를 따르고, 일부는 자체 설정을 사용하며, 일부는 별도 설정이 필요합니다. 브라우저 한 곳에서 접속할 수 있어도 모든 프로그램이 코어를 거친다는 뜻은 아닙니다. 프로토콜 차이를 살펴보기 전에 앱이 실제로 어떤 경로를 사용하는지 확인하세요. 시스템 프록시는 시스템 설정을 따르는 앱에 적합하지만 기기의 모든 트래픽을 자동으로 처리하지는 않습니다.

일반적인 업무에는 짧은 요청, 지속적인 회의 연결, 백그라운드 동기화가 함께 포함됩니다. 한 번의 속도 측정보다 장시간 연결의 안정성, 일관된 DNS, 이해하기 쉬운 규칙이 더 중요합니다. 정상 작동하는 TLS나 REALITY 설정이 있다면 우선 기본 매개변수를 유지하세요. UDP가 필요한 앱은 경로의 각 단계가 이를 지원하는지 확인해야 합니다. 모든 요청을 같은 경로로 보내려는 목적으로 복잡한 모드를 성급히 활성화하지 마세요. 먼저 앱의 요구 사항을 확인한 다음 인바운드와 라우팅 범위를 결정하세요.

출퇴근 중 휴대전화 사용: 네트워크 전환과 유휴 후 복구 확인

Android에서는 v2rayNG를 우선 사용하고 Xray가 지원하는 프로토콜 조합에 맞춰 설정을 확인하세요. Wi-Fi와 모바일 네트워크 사이를 전환하면 출발지 주소와 하위 연결이 달라질 수 있어 기존 연결을 복구하거나 다시 설정해야 할 때가 많습니다. 복구 속도는 프로토콜뿐 아니라 클라이언트의 네트워크 감지, 운영체제의 백그라운드 제한, 서버 시간 초과, 앱의 재시도 방식에도 영향을 받습니다. 테스트할 때는 실제로 네트워크를 전환하고 자주 사용하는 앱을 실행하세요. 한 가지 네트워크에서 연결에 한 번 성공한 것만으로 판단해서는 안 됩니다.

절전 설정은 실제 증상에 맞춰 조정해야 합니다. 운영체제가 클라이언트를 중지하면 앱을 닫은 뒤 연결이 끊길 수 있고, 백그라운드 활동을 모두 허용하면 불필요한 작동 시간이 늘어날 수 있습니다. 먼저 시스템의 백그라운드 제한이 지나치게 강한지 확인하고 유휴 상태에서 계속 재연결하거나 자주 연결을 확인하는지 살펴보세요. 필요한 백그라운드 실행 조건만 유지하고 고주기 속도 측정으로 연결을 유지하려 하지 마세요. 중요한 것은 필요한 작업을 할 때 안정적으로 작동하고 사용하지 않을 때 추가적인 깨우기를 줄이는 것입니다.

불안정한 네트워크: 프로토콜을 바꾸기 전에 변수를 줄이세요

불안정한 네트워크에서는 패킷 손실, 지연 변동, 간헐적인 연결 끊김이 흔합니다. 프록시 프로토콜을 바꾼다고 하위 네트워크 문제가 자동으로 해결되지는 않습니다. 문제를 확인할 때는 경로가 안정적이고 전송 계층이 단순한 설정을 우선 선택해 여러 연결 재사용이나 추가 전달 방식을 한꺼번에 적용하지 마세요. 새 요청은 자주 실패하지만 이미 연결된 세션은 비교적 안정적이라면 핸드셰이크와 재연결을 확인하세요. 지속 전송이 멈춘다면 혼잡과 패킷 손실을 살펴봐야 합니다. 서로 다른 두 현상을 모두 ‘불안정한 네트워크에는 프로토콜이 맞지 않는다’고 설명할 수는 없습니다.

짧은 요청이 많을 때 다중화는 연결을 반복해서 만드는 일을 줄일 수 있지만, 공유 하위 연결이 막히면 여러 논리 요청에 동시에 영향을 줄 수도 있습니다. 먼저 선택적 연결 재사용을 끄고 기준 동작을 확인한 다음 작업별로 비교하세요. ‘불안정한 네트워크에서는 항상 켜야 한다’는 조언을 그대로 적용하는 것보다 안전합니다. HTTP/2에 의존하는 전송 방식을 사용한다면 중간 프록시가 지속 연결을 안정적으로 유지하는지도 확인하세요. 복잡한 구성은 필요한 환경에서 유용하지만 불안정한 네트워크를 점검할 때 미지의 변수를 추가해서는 안 됩니다.

장시간 전송과 실시간 앱을 각각 확인하세요

파일 전송은 지속 처리량, 안정적인 연결, 서버 외부 연결 용량이 중요하고 실시간 음성은 지연 변동, 패킷 손실, UDP 경로가 더 중요합니다. 다운로드 속도가 빠르다고 통화 품질이 좋은 것은 아니며, 웹 응답이 빠르다고 대용량 전송 중 발열 제어나 대역폭 제한이 발생하지 않는다는 보장도 없습니다. 장시간 실행되는 작업은 실제 사용 상황을 일정 시간 관찰하면서 기기 온도, 오류 로그, 연결 복구 여부를 확인하세요. 일상적인 사용에 가까운 조건에서 테스트할수록 결과의 참고 가치가 높아집니다.

V2Fly 호환성이 필요한 경우 v2flyNG의 별도 설정으로 확인할 수 있지만 모든 연결 문제를 해결하는 만능 대체재로 취급해서는 안 됩니다. 서버 매개변수가 Xray에 의존한다면 다른 코어로 바꿔 오히려 새 문제가 생길 수 있습니다. 클라이언트, 프로토콜, 서버는 서로 맞아야 합니다. 먼저 서버가 제공하는 기능을 확인하고 필요한 매개변수를 모두 지원하는 클라이언트를 고른 뒤 일상적인 작업에서 성능을 비교하세요. 선호하는 이름부터 선택하는 방식은 피하세요.

선택 결과는 순위가 아닌 조건으로 정리하세요

유용한 결론은 ‘이 기기와 현재 네트워크에서 이 설정으로 회의와 동기화를 안정적으로 완료할 수 있다’와 같은 형태입니다. ‘특정 프로토콜이 언제나 가장 빠르다’는 결론은 도움이 되지 않습니다. 기기, 코어, 인바운드, 전송, 보안 방식, 서버 경로를 조건으로 기록하세요. 이렇게 남겨 두면 네트워크가 달라지거나 구성 요소를 업데이트한 뒤 다시 확인할 수 있습니다. 여러 설정이 모두 요구 사항을 충족한다면 구조가 명확하고, 설정 출처를 신뢰할 수 있으며, 복구하기 쉬운 방식을 우선해 장기적인 관리 부담을 줄이세요.

먼저 최소 구성으로 기준을 만드세요

매개변수가 완전한 설정 하나를 선택하고 클라이언트 기본 라우팅이나 명확히 기록된 라우팅으로 일반 웹 요청을 확인하세요. 첫 연결부터 복잡한 사용자 규칙을 가져오거나 DNS를 조정하고, 연결 재사용을 켜고, 코어까지 바꾸지 마세요. 로그를 열어 코어가 정상적으로 시작되었는지 확인한 다음 실제 요청이 코어에 도달했는지 확인합니다. 시작 단계에서 실패했다면 네트워크 속도 측정은 의미가 없습니다. 설정 문법, 포트 충돌, 지원되지 않는 옵션을 먼저 해결해 프로세스가 안정적으로 실행되게 하세요.

로컬 리스닝 주소도 명확히 설정해야 합니다. 아래 예시는 Xray 전체 설정에서 inbounds 부분에 사용할 수 있는 최소 인바운드 조각으로, 필드 간 관계를 설명하기 위한 것입니다. 원격 서버 설정까지 포함한 완전한 구성은 아닙니다. SOCKS 인바운드는 로컬 루프백 주소에서만 수신하며 LAN에는 공개되지 않습니다. 포트는 앱에 입력한 값과 일치해야 합니다. 클라이언트가 이미 해당 포트를 사용 중이라면 다른 프로세스가 중복해서 사용할 수 없습니다. 일반적인 그래픽 설정에서는 클라이언트 화면에서 해당 항목을 수정하는 것이 좋습니다.

{
  "inbounds": [
    {
      "tag": "local-socks",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "auth": "noauth",
        "udp": true
      }
    }
  ]
}

실패 단계에 따라 범위를 좁히세요

요청 로그가 전혀 없다면 앱이 로컬 인바운드를 사용하는지, 라우팅 규칙이 요청을 직접 연결하도록 지정하지 않았는지 확인하세요. 연결 시간 초과가 발생하면 서버 주소, 포트, 현재 네트워크, 서버 리스닝 상태를 확인합니다. 즉시 연결이 거부되면 대상 포트가 연결을 받아들이지 않는 경우가 많지만 로그와 함께 판단해야 합니다. 핸드셰이크 단계에서 실패하면 TLS 서버 이름, 인증서, REALITY 매개변수, 시스템 시간을 확인하세요. 인증 오류는 UUID, 비밀번호, 암호화 방식을 점검해야 합니다. 서로 다른 종류의 오류를 한꺼번에 처리하지 마세요.

서버에 연결되었지만 일부 도메인만 실패한다면 대상 사이트 자체의 문제인지, DNS 응답인지, 라우팅 규칙이 일치한 것인지 구분하세요. 직접 연결 DNS와 프록시 DNS는 조회 위치가 다르므로 같은 도메인에서 서로 다른 결과를 반환할 수 있습니다. DNS 요청을 프록시로 전달하는지도 코어의 정책에 따라 달라집니다. 공개 DNS 주소 하나만 바꿔 문제가 해결됐다고 단정할 수 없습니다. DNS 경로에 관한 자세한 내용은 v2rayN DNS 점검 및 설정 방법을 참고한 뒤 실제 요청으로 확인하세요.

로그로 경로를 확인하되 민감한 정보는 공개하지 마세요

로그에서는 시간 순서, 인바운드 출처, 일치한 아웃바운드, 오류 종류를 중점적으로 확인하세요. 경고 한 줄이 연결 전체의 실패를 의미하지는 않습니다. 특정 백그라운드 요청이 대상 서버에서 거부된 것일 수도 있습니다. 반대로 화면에 실행 중이라고 표시되어도 실제 업무 트래픽이 성공했다는 보장은 없습니다. 다른 앱의 활동을 잠시 줄이고 명확한 테스트 요청을 하나 보낸 뒤 시간에 맞는 로그를 찾으세요. 일시적으로 로그 상세 수준을 높이면 원인을 찾는 데 도움이 되지만, 확인이 끝나면 정상 수준으로 되돌려 불필요한 로그가 계속 쌓이지 않게 하세요.

로그를 공유하기 전에 구독 URL, 인증 정보, 사적인 도메인, 계정과 연결될 수 있는 매개변수를 삭제하세요. 문제를 보고할 때는 클라이언트 이름, 코어 종류, 인바운드 방식, 프로토콜과 보안 계층 조합, 오류 전후의 필요한 문맥만 남기면 됩니다. 실행 설정 전체를 공개하거나 전체 구독을 일반적인 테스트 URL처럼 게시하지 마세요. 민감 정보 삭제는 기술 정보를 전부 지우는 것이 아닙니다. 설정 구조와 오류 원인은 유지하고 연결에 직접 사용할 수 있는 인증 정보만 제거해야 합니다.

재테스트에 성공한 뒤 복잡한 설정을 복원하세요

최소 설정이 정상 작동하면 라우팅 규칙, DNS, 사용자 지정 인바운드, 연결 재사용을 하나씩 복원하고 매번 같은 요청을 반복하세요. 특정 항목을 복원한 뒤 문제가 나타나면 모든 프로토콜을 무작위로 바꾸지 말고 해당 항목을 중심으로 확인합니다. 사용자 지정 라우팅은 규칙 순서가 특히 중요합니다. 범위가 넓은 규칙이 먼저 일치하면 뒤에 있는 구체적인 규칙이 적용되지 않을 수 있습니다. 자세한 문법은 라우팅 일치와 우선순위 안내를 참고하세요. 수정할 때는 한 번에 변수 하나만 바꾸세요.

최종 확인에는 일반 웹 탐색, 실제 업무 앱, 유휴 상태 이후 복구, 네트워크 전환을 최소한 포함하세요. UDP가 필요하면 해당 앱에서 별도로 확인하고 여러 기기에서 사용할 경우 기기별 인바운드도 점검하세요. 한 기기에서 성공했다고 모두 정상이라고 판단할 수는 없습니다. 검증이 끝나면 복구 가능한 설정을 저장하고 주요 선택 근거를 기록하세요. 나중에 문제가 생기면 업데이트나 마이그레이션을 결정하기 전에 환경과 설정이 어떻게 달라졌는지 먼저 비교하세요. 설치와 가져오기는 빠른 시작 가이드에서, 설치 파일과 플랫폼 선택은 클라이언트 다운로드 페이지에서 확인하세요.