프록시 프로토콜·코어 참고 자료

GUI 클라이언트·코어·서버의 역할

GUI 클라이언트는 서버 목록을 표시하고 공유 링크를 읽으며, 구독과 설정을 관리합니다. 코어는 로컬 수신 포트를 열고 라우팅 규칙을 적용해 원격 서버에 연결한 뒤 트래픽을 전달합니다. 원격 서버는 약속된 프로토콜에 따라 연결을 받습니다. v2rayN에 특정 설정 항목이 표시된다고 해서 현재 선택된 코어가 이를 지원한다는 뜻은 아닙니다. 클라이언트가 링크를 가져올 수 있어도 서버가 모든 설정값을 허용하는 것은 아닙니다. 호환성을 확인할 때는 클라이언트가 필드를 어떻게 해석하는지, 코어가 어떤 설정을 생성하는지, 서버가 어떤 조합을 허용하는지 함께 살펴봐야 합니다. 화면에 표시된 프로토콜 이름만으로 판단해서는 안 됩니다.

로컬 앱은 보통 시스템 프록시나 가상 네트워크 인터페이스에 먼저 연결되고, 이후 코어를 거쳐 원격 서버로 트래픽을 보냅니다. 브라우저 접속 실패는 로컬 진입점, 이름 해석, 라우팅, 원격 연결, 대상 사이트 등 어느 단계에서든 발생할 수 있습니다. 프로토콜은 그중 한 부분일 뿐입니다. 모든 문제를 VMess나 VLESS 탓으로 돌리면 포트 충돌, 시스템 프록시 미적용, 잘못된 분기 규칙처럼 더 직접적인 원인을 놓칠 수 있습니다. 처음 테스트할 때는 앱 하나와 대상 하나를 정하고 요청이 클라이언트에 들어오는지 확인한 뒤, 어느 단계에서 오류가 나는지 살펴보세요. 노드 변경, DNS 수정, 라우팅 변경을 한꺼번에 하지 마세요.

프록시 프로토콜·전송 방식·보안 계층

VMess, VLESS, Trojan, Shadowsocks는 프록시 양쪽에서 사용자를 식별하고 대상 주소를 전달하며 데이터를 감싸는 방식을 정의합니다. TCP, WebSocket, gRPC 등은 연결을 전달하는 전송 방식이며, TLS와 REALITY는 외부 보안 메커니즘과 관련됩니다. VLESS와 REALITY는 같은 계층의 프로토콜이 아니므로 서로 직접 비교할 수 없습니다. 하나의 연결에서 함께 사용할 수도 있습니다. WebSocket이 보인다고 VMess를 사용한다고 단정할 수 없고, TLS가 보인다고 반드시 Trojan인 것도 아닙니다. 프로토콜 이름을 서로 다른 계층에서 가져와 속도 순위를 매기기보다 전체 조합을 비교해야 합니다.

접속 주소·서버 이름·앱 대상

접속 주소는 클라이언트가 처음 네트워크 연결을 시도할 대상을 정하고, 서버 이름은 보안 핸드셰이크와 신원 확인에 주로 사용되며, 앱 대상은 브라우저가 원래 접속하려던 사이트입니다. 세 값이 같은 도메인일 때도 있지만 역할은 서로 다릅니다. 접속 주소를 바꾸면서 서버 이름까지 함께 덮어쓰지 마세요. WebSocket의 Host를 바꾼다고 앱 대상이 바뀌는 것도 아닙니다. 서버에서 리버스 프록시를 사용한다면 경로, Host, 서버 이름이 함께 전달에 관여할 수 있습니다. 값 하나가 빠지면 접속 지점에는 도달해도 올바른 서비스로 요청이 전달되지 않을 수 있으며, 이는 단순한 계정 오류와는 다릅니다.

설정을 확인할 때는 먼저 현재 값을 계층별로 기록하세요. 프로토콜, 하위 전송 방식, 외부 보안 사용 여부, 인증 필드의 출처를 정리하면 됩니다. 익숙하지 않은 옵션은 원래 값으로 두고, 처음 가져온 설정도 별도로 보관하세요. 공유 링크의 짧은 필드 이름과 화면의 한글 항목명이 글자 그대로 일치하지 않을 수 있으므로 비슷한 이름만 보고 서로 바꾸면 안 됩니다. 가장 신뢰할 수 있는 기준은 서버가 제공한 전체 설정값과 코어 문서의 필드 설명입니다. 이어지는 각 장에서는 이 계층 구분을 바탕으로 설계상의 선택과 클라이언트에서 확인할 순서를 다룹니다.

VMess: 인증과 데이터 보호를 함께 고려한 설계

VMess는 Project V 프로토콜 생태계에서 사용자 인증, 요청 정보, 데이터 보호를 함께 다루도록 설계되었습니다. 일반적인 설정에서는 UUID로 사용자를 식별하고 암호화 방식을 지정합니다. 최신 구현은 AEAD 인증 방식을 사용하며, 오래된 가이드에 나오는 추가 식별자나 구형 인증 옵션을 일반적인 권장값으로 보면 안 됩니다. 가져온 설정은 현재 형식에 따라 클라이언트가 구성을 생성하도록 하고, 과거 화면 예시를 따라 구형 필드로 되돌리지 마세요. 기기 시간도 정확해야 합니다. 인증 과정에 시간 조건이 적용될 경우 시계가 크게 어긋나면 네트워크 연결은 가능해도 인증에 실패할 수 있습니다.

VMess를 사용할지는 기존 서버와 클라이언트의 지원 여부에 따라 결정하면 됩니다. 이미 안정적으로 작동하는 VMess 서버가 있다면 이름이 더 새롭다는 이유만으로 프로토콜을 바꿀 필요는 없습니다. 전송 방식, 사용자 식별자, 암호화 설정, 외부 보안이 서로 일치하는지 확인하세요. VMess는 여러 전송 방식과 조합할 수 있고, 실제 연결 오버헤드도 조합에 따라 달라집니다. 여러 겹으로 감싼 VMess 연결을 다른 경로의 직접 전송과 단순 비교한 뒤, 차이를 전부 프로토콜 탓으로 돌릴 수는 없습니다. 비교할 때는 최소한 서버, 대상, 네트워크, 테스트 방식을 동일하게 맞추세요.

Trojan: TLS에 의존하는 프록시 인증

Trojan은 TLS 연결 안에서 프록시 요청을 전달하고, 프로토콜 자체의 인증 정보로 사용자를 식별하도록 설계되었습니다. 계정을 UUID 하나로 통일해 표현하지 않으며, 클라이언트에서는 보통 비밀번호를 요구합니다. 사용할 때는 원격 주소와 서버 이름을 구분하고 인증서가 서버 이름과 일치하는지 확인해야 합니다. TLS 연결이 성립해도 프록시 인증까지 성공한 것은 아닙니다. 반대로 비밀번호가 맞아도 인증서 이름 오류는 해결되지 않습니다. 두 단계의 로그를 구분해서 확인하세요. 인증서 검증을 끄는 것은 일반적인 설치 절차가 아닙니다. 원격 서버의 신원을 확인하는 클라이언트 기능이 약해집니다.

Trojan은 설정 필드가 비교적 간결하다고 여겨지지만, 실제 운영 난이도는 인증서, 도메인, 서버 배포 방식에 따라 달라집니다. 연결 재사용, 전송 확장, 외부 전달 구성이 추가되면 확인할 조건도 늘어납니다. 클라이언트가 Trojan을 지원해도 이름이 비슷한 모든 확장 조합을 지원한다는 뜻은 아닙니다. 설정을 이전할 때는 서버가 어떤 구현과 전송 방식을 사용하는지 먼저 확인한 다음, 클라이언트가 비밀번호와 서버 이름을 그대로 보존하는지 살펴보세요. 비밀번호에 URL 인코딩이 필요한 문자가 들어갈 수 있으므로 공유 링크를 직접 만들 때 특히 주의해야 합니다.

Shadowsocks: 암호화 방식과 키를 정확히 맞추기

Shadowsocks는 보통 간결한 설정으로 프록시 연결을 구성하며, 주요 값은 서버 주소, 포트, 암호화 방식, 비밀번호입니다. SS라는 약칭은 프로토콜 계열을 가리킬 뿐, 구체적인 암호화 방식을 대신하지 않습니다. 기존 AEAD 방식과 최신 Shadowsocks 2022 방식은 키 요구사항과 구현 지원에 차이가 있습니다. 후자는 길이에 상관없이 임의의 일반 비밀번호를 사용할 수 없습니다. 클라이언트가 SS 링크를 인식하더라도 링크에 지정된 모든 방식을 코어가 지원한다는 뜻은 아닙니다. 가져오기는 성공했지만 연결 오류가 난다면 서버 주소를 반복해서 바꾸기보다 먼저 방식 이름과 키 형식을 확인하세요.

이 세 가지 프로토콜은 각각 인증과 전달 문제를 해결하며, 필드 수만으로 보안성이나 리소스 사용량을 판단할 수 없습니다. 설정이 짧다고 배터리를 덜 쓰는 것도 아니고, 계층이 많다고 반드시 느린 것도 아닙니다. 기존 서버를 사용한다면 설정값이 완전하고 클라이언트 지원이 명확한 조합을 우선하세요. 여러 기기를 관리해야 한다면 모든 기기에서 같은 형식으로 사용할 수 있는지도 중요합니다. 네 가지 프록시 프로토콜을 더 자세히 비교하려면 VMess·VLESS·Trojan·Shadowsocks 선택 가이드를 읽고, 다음 장에서 VLESS의 보안 범위도 확인하세요.

VLESS만으로 완전한 암호화 연결이 되는 것은 아닙니다

VLESS는 프록시 프로토콜 자체를 간결하게 설계하고, 일부 역할을 외부 메커니즘에 맡기는 방식입니다. 사용자 식별에는 보통 UUID를 사용하지만, VMess의 암호화 옵션을 그대로 적용할 수는 없습니다. 일반적인 VLESS 설정의 encryption: none은 프로토콜 계층에서 별도의 데이터 암호화 방식을 선택하지 않는다는 뜻이지, 연결 전체가 자동으로 보호되지 않는다는 뜻은 아닙니다. 전체 연결이 보호되는지 확인하려면 전송 설정의 TLS 또는 REALITY를 살펴보세요. 반대로 외부 보안 계층이 없다면 프로토콜 이름이 VLESS라는 이유만으로 암호화되어 있다고 판단해서는 안 됩니다.

따라서 VLESS를 설명할 때는 전송 방식과 함께 전체 조합을 명시해야 합니다. 예를 들면 TLS를 사용하는 VLESS 또는 REALITY를 사용하는 VLESS입니다. 조합에 따라 서버 요구사항, 핸드셰이크 필드, 코어 지원 범위가 다릅니다. 옵션의 flow도 어디서나 쓸 수 있는 속도 향상 버튼이 아닙니다. 특정 흐름 제어 방식을 지정하며 서버와 전송 조건이 맞아야 합니다. xtls-rprx-vision을 임의로 입력해도 해당 조합을 지원하지 않는 서버에 기능이 추가되지는 않습니다. 원본 링크에 이 필드가 없다면 가이드 화면 예시만 보고 추가하지 마세요.

REALITY 클라이언트 검증 정보

REALITY는 보안 전송 메커니즘이며 VLESS를 대체하는 별도의 사용자 계정 프로토콜이 아닙니다. 일반적인 Xray 클라이언트 설정에서는 서버 이름, 공개 키 계열 검증 정보, 짧은 식별자, 지문 설정 등을 확인해야 합니다. 화면에 표시되는 이름은 클라이언트와 코어의 설정 모델에 따라 달라질 수 있고, 공유 링크에서는 약어를 사용할 수도 있습니다. 필드 이름만 보지 말고 가져온 뒤 실제로 어떤 의미로 적용됐는지 확인하세요. 클라이언트가 원격 서버를 검증하는 정보와 서버가 보관하는 개인 정보는 역할이 다릅니다. 서버의 개인 정보는 일반 클라이언트 설정에 복사하면 안 됩니다.

짧은 식별자는 보통 16진수 형식과 길이 제한을 따르며, 빈 값을 허용할지는 서버가 정합니다. 서버 이름은 서버에서 허용하는 범위에 속해야 하며, 익숙한 도메인으로 임의 변경할 수 없습니다. 지문 설정은 핸드셰이크 동작에 영향을 주고 코어 구현의 지원 여부에도 좌우됩니다. 기기 신원을 바꾸는 범용 도구가 아닙니다. 원본 설정은 연결되는데 직접 다시 만든 설정은 실패한다면 해당 필드를 하나씩 비교하고, 복사 과정에서 공백이나 전각 문자가 들어갔거나 쿼리 매개변수가 빠지지 않았는지 확인하세요. 여러 최적화 조합을 한꺼번에 시도하기보다 원래 값을 복원하는 편이 원인을 찾기 쉽습니다.

호환성 오류 확인 순서

설정을 저장한 뒤 코어가 바로 종료된다면 지원되지 않는 필드, 잘못된 매개변수 구조, 허용되지 않는 조합을 먼저 의심하세요. 코어는 정상 실행되지만 원격 핸드셰이크가 실패한다면 주소, 포트, 서버 이름, 검증 정보를 확인합니다. 핸드셰이크는 성공했는데 앱 접속이 되지 않으면 라우팅, DNS, 대상 서버 연결을 살펴보세요. 이 순서대로 보면 로컬 설정 파싱과 네트워크 핸드셰이크를 구분할 수 있습니다. 클라이언트 로그에 보안 계층 이름이 표시된다는 것은 해당 단계가 처리 중이라는 뜻일 뿐, 사용자 인증과 앱 데이터 전달까지 완료됐다는 근거는 아닙니다.

새 데스크톱 설정은 해당 기능을 지원하는 코어와 v2rayN을 함께 사용하는 것이 기본 경로입니다. Android에서 v2rayNG를 사용할 때도 실제 코어 기능을 확인해야 합니다. Xray용 VLESS·REALITY 설정을 다른 코어 계열에 그대로 넣으면 완전히 호환될 것이라고 기대하지 마세요. 기존 설정이 작동한다면 클라이언트가 가져오는 과정에서 필드를 누락하지 않았는지 먼저 확인한 다음 클라이언트를 바꾸세요. 코어 지원 범위는 5장, 공유 링크에서 필드를 보존하는 방법은 6장을 참고하세요. 두 가지 모두 기기 간 설정 이전의 성공 여부에 영향을 줍니다.

연결 시간·응답 시간·처리량

연결 성능은 적어도 세 가지로 나눠 봐야 합니다. 새 연결을 설정하는 데 걸리는 시간, 요청 후 응답을 받기까지 걸리는 시간, 지속 전송 중 유지되는 처리량입니다. 각 항목에 영향을 미치는 요인은 다릅니다. 이름 해석, TCP 연결, 보안 핸드셰이크, 프록시 인증은 최초 응답에 영향을 줍니다. 왕복 시간, 패킷 손실, 혼잡 제어, 서버 부하는 지속 전송에 영향을 줍니다. 프로토콜의 애플리케이션 계층 필드가 적다고 해서 더 열악한 네트워크에서도 빠르다는 뜻은 아닙니다. 한 번의 속도 측정만으로 프로토콜 구현, 서버 위치, 네트워크 상태의 영향을 구분할 수 없습니다.

Tcping 같은 테스트는 보통 특정 TCP 접속 지점에 연결되는지만 보여 주며, 프록시 인증과 대상 사이트 접속까지 완전히 확인하지는 않습니다. 실제 연결 테스트는 앱이 프록시를 거쳐 테스트 주소에 접속하는 과정을 더 잘 반영하지만, 테스트 대상과 클라이언트 구현의 영향을 받습니다. 두 결과는 같은 지표가 아닙니다. 접속 지점에는 연결되지만 실제 연결에 실패한다면 인증, 보안 핸드셰이크, 대상 사이트 접속, DNS가 원인일 수 있습니다. 곧바로 회선이 끊겼다고 판단하지 마세요. 자세한 방법은 첫 연결 및 실제 연결 테스트 가이드를 참고하고, 고정된 테스트 대상을 반복해서 확인하세요.

캡슐화·재사용·리소스 사용량

WebSocket과 gRPC 같은 전송 방식은 각자 핸드셰이크와 캡슐화 방식을 적용하며 기존 서버 배포 환경에 맞출 수도 있습니다. 캡슐화가 추가되면 처리할 구조가 늘지만, 실제 오버헤드가 크게 드러나는지는 요청 크기, 연결 유지 시간, 구현 효율에 따라 달라집니다. 짧은 요청에서는 지속적인 데이터 처리보다 연결 설정 과정이 더 중요할 수 있고, 장시간 다운로드에서는 처리량과 패킷 손실이 더 큰 영향을 줄 수 있습니다. 따라서 모든 네트워크에 통하는 고정 순위를 매길 수 없으며, 설정 필드가 적다는 이유만으로 처리 비용이 낮다고 볼 수도 없습니다.

연결 재사용은 연결을 반복해서 만드는 비용을 줄일 수 있지만 모든 작업의 성능을 개선하는 것은 아닙니다. 여러 요청이 하위 연결 하나를 공유하면 해당 연결 상태에 함께 영향을 받습니다. 네트워크가 불안정하거나 특정 흐름이 리소스를 많이 차지하면 다른 요청도 영향을 받을 수 있습니다. 사용 여부는 코어 지원, 서버 기능, 작업 유형을 고려해 결정하고, 먼저 기본 상태를 기록한 뒤 비교하세요. CPU 사용량은 암호화 방식, 하드웨어 명령어, 트래픽 규모, 로그 수준에도 영향을 받습니다. 프로세스 사용량이 잠깐 증가했다는 이유만으로 해당 프로토콜이 기기에 맞지 않는다고 결론 내릴 수 없습니다.

Android 배터리 사용량에 영향을 주는 요인

모바일 기기의 배터리 소모는 암호화 연산뿐 아니라 무선 네트워크 인터페이스가 활성화된 시간, 백그라운드 깨우기, 연결 재시도, 앱 트래픽에도 좌우됩니다. 신호가 약한 상태에서 반복적으로 재연결하면 정상적인 데이터 처리보다 배터리를 더 많이 쓸 수 있습니다. 전체 기기 트래픽을 프록시로 처리하면 원래 프록시를 거치지 않던 앱도 처리 경로에 들어갈 수 있습니다. 처리 범위가 넓어졌다면 배터리 차이를 전부 프로토콜 탓으로 돌릴 수 없습니다. 시스템의 백그라운드 제한으로 클라이언트가 중단되면 연결 복구와 재인증이 반복되어 대기 중 배터리 소모, 알림 지연, 잠금 해제 직후의 집중적인 재연결이 발생할 수 있습니다.

의미 있게 비교하려면 기기, 네트워크 유형, 앱 구성, 사용 시간을 고정하고 화면을 켠 상태의 전송과 백그라운드 대기를 구분해야 합니다. 반복 측정과 과도한 로그를 끄고 지속적인 재시도가 없는지 확인한 뒤 설정을 비교하세요. 시스템 배터리 통계를 기록할 때는 화면, 모바일 네트워크, 대상 앱의 활동도 함께 살펴보세요. 프로토콜뿐 아니라 서버, 전송 방식, 프록시 적용 범위까지 함께 바꿨다면 결과는 두 전체 구성의 차이일 뿐 프로토콜 자체의 전력 소모를 보여 주지는 않습니다. v2rayNG와 v2flyNG를 비교할 때도 같은 원칙을 따르세요.

실제로는 설정 오류, 무의미한 재시도, 불필요한 전체 트래픽 처리부터 바로잡고 전송 방식을 미세 조정하는 것이 좋습니다. 일상적인 웹과 메시지 앱에는 설정이 정확하고 안정적으로 연결되는 기존 구성이 잦은 전환보다 평가하기 쉽습니다. 대용량 파일 작업은 지속 처리량과 실패 후 복구를 따로 살펴보세요. 재현 가능한 테스트 조건이 없다면 한 번의 측정 화면만 보고 프로토콜을 바꾸기보다 기존에 작동하는 구성을 유지하는 편이 합리적입니다. 구체적인 오류를 확인하려면 자주 묻는 질문을 참고해 오류 단계별로 점검하세요.

Project V 생태계의 역할 구분

Project V는 이 생태계를 이해하는 출발점입니다. V2Ray의 설정 모델과 프로토콜 설계는 이후 도구의 기반이 되었습니다. V2Fly는 V2Ray 관련 구현을 계속 유지 관리하며, Xray는 관련 코드와 기술 기반에서 출발해 독립적으로 발전한 코어 프로젝트입니다. 두 프로젝트는 인바운드, 아웃바운드, 라우팅, DNS 등 여러 개념을 공유하지만 기능과 필드 모델은 각자 달라집니다. Xray를 V2Fly의 단순한 버전 업그레이드로 볼 수 없고, 둘을 필요에 따라 서로 바꿔 쓸 수 있는 같은 프로그램으로 간주해서도 안 됩니다. 실제 호환 범위는 기능별로 확인해야 합니다.

클라이언트는 또 다른 계층에 속합니다. v2rayN은 데스크톱 사용자에게 GUI 관리 기능을 제공하고, 실제 프로토콜 처리는 사용 중인 코어가 담당합니다. v2rayNG는 일반적으로 Xray 기능을 중심으로 사용하며, v2flyNG는 Android에서 V2Fly 코어를 사용하는 대안입니다. 플랫폼과 필요한 기능이 클라이언트 선택의 우선 기준이지, 단순히 화면 취향으로 결정할 문제는 아닙니다. 데스크톱에서는 v2rayN을 먼저 고려하세요. Android에서 Xray 전용 기능이 필요하면 v2rayNG를 확인하고, 기존 V2Fly 설정을 유지하려면 v2flyNG의 호환성을 살펴보세요.

공통 설정 구조와 코어별 기능

inbounds는 로컬에서 트래픽을 받는 방법을, outbounds는 외부 연결을 만드는 방법을, routing은 요청을 어느 아웃바운드로 보낼지 설명합니다. 개념이 비슷하다고 하위 필드까지 모두 같은 것은 아닙니다. 특히 전송 설정, 보안 메커니즘, 흐름 제어 옵션, DNS 동작을 확인해야 합니다. 바깥쪽 JSON 구조가 익숙해 보인다는 이유만으로 REALITY와 관련 Xray 연결 기능을 V2Fly로 바로 옮길 수는 없습니다. 다른 코어에서 일부 필드를 해석하지 못할 수도 있고, 이름은 비슷하지만 동작이 다른 설정일 수도 있습니다.

라우팅 데이터 리소스도 막연히 설치만 하면 같은 방식으로 동작하는 것은 아닙니다. 도메인 및 IP 분류 태그는 실제로 로드한 리소스 내용에 따라 달라집니다. 파일이 없거나 태그를 사용할 수 없으면 규칙 때문에 시작에 실패하거나 기대한 결과를 얻지 못할 수 있습니다. 설정을 이전할 때는 JSON뿐 아니라 실행 환경의 리소스와 경로도 확인해야 합니다. 상대 경로는 클라이언트가 코어를 실행할 때의 작업 디렉터리에 따라 달라질 수 있으므로 다른 기기의 절대 경로를 그대로 남겨 두면 안 됩니다. GUI 클라이언트가 관리하는 리소스는 실제로 어떤 파일을 불러오는지 모르게 덮어쓰지 말고, 클라이언트의 업데이트와 설정 메뉴를 이용하세요.

어느 계층을 업데이트할지 판단하기

화면에서 링크 필드를 인식하지 못한다면 클라이언트의 가져오기 기능을 확인해야 합니다. 설정 생성은 정상인데 코어에서 옵션을 지원하지 않는다고 보고한다면 코어 기능을 점검하세요. 코어는 정상 실행되지만 규칙 태그를 찾지 못한다면 리소스 파일을 확인해야 합니다. 서로 다른 세 가지 문제입니다. GUI만 업데이트해도 코어가 바뀌지 않을 수 있고, 코어를 바꿔도 클라이언트가 필드를 누락하는 문제는 해결되지 않을 수 있습니다. 업데이트 전에 원본 구독과 작동 중인 설정을 보관하세요. 업데이트 후에는 확인된 설정 하나로 먼저 테스트하고 복잡한 규칙은 나중에 복구하세요. 한 번에 코어 계열을 바꾸고 구독을 수정하고 규칙 전체를 가져오지 마세요.

오픈소스라는 것은 코드를 살펴보고 해당 라이선스에 따라 사용할 수 있다는 뜻이지, 두 프로젝트의 설정 형식이 계속 같게 유지된다는 뜻은 아닙니다. 필요한 기능, 클라이언트 지원 여부, 유지 관리 방식에 따라 선택하세요. 특정 계열이 모든 상황에 맞는 유일한 답이라고 볼 필요는 없습니다. 설정 각 부분의 역할을 이해하려면 Xray 설정 파일 구조 분석을 참고하세요. 다른 기기의 설치 파일이 필요하다면 다운로드 페이지에서 운영체제와 프로세서에 맞는 파일을 선택하세요. 코어 개념과 설치 파일의 아키텍처를 혼동하지 마세요.

단일 공유 링크와 링크 모음

공유 링크는 서버 설정 하나를 표현하며, 흔한 접두어로는 vmess://, vless://, trojan://, ss://가 있습니다. 각 링크의 내부 형식은 서로 다릅니다. 일반적인 VMess 공유 링크는 JSON 내용을 인코딩하며, VLESS와 Trojan은 보통 URL의 사용자 정보, 주소, 쿼리 매개변수로 설정을 표현합니다. Shadowsocks에는 과거부터 서로 다른 표현 방식이 있습니다. 클라이언트는 먼저 프로토콜 접두어를 인식한 다음 해당 형식에 맞춰 파싱해야 합니다. 한 종류의 링크를 디코딩하는 방식을 다른 링크에 그대로 적용할 수는 없습니다.

구독 주소는 설정 여러 개를 가져오는 진입점이지 서버 주소 하나를 가리키는 것이 아닙니다. 구독 응답에는 여러 줄의 공유 링크가 담기거나 링크 모음을 base64로 인코딩한 내용이 담길 수 있습니다. base64는 인코딩 방식일 뿐 암호화나 프록시 프로토콜이 아닙니다. 디코딩에 성공해도 텍스트를 얻었다는 뜻일 뿐이며, 그 텍스트가 클라이언트가 지원하는 형식인지 확인해야 합니다. 줄바꿈, 문자 인코딩, URL 인코딩이 파싱에 영향을 줄 수도 있습니다. 구독 주소를 복사할 때는 제공업체가 준 전체 주소를 사용하고, 페이지 제목이나 안내 문구, 눈에 보이지 않는 공백, 메일 프로그램이 추가한 줄바꿈이 섞이지 않게 하세요.

네이티브 JSON과 클라이언트 관리 설정

Xray 네이티브 JSON은 여러 인바운드와 아웃바운드, 라우팅, DNS 등 전체 실행 동작을 정의할 수 있습니다. 공유 링크 여러 개를 다른 모양으로 표현한 것이 아닙니다. 단일 공유 링크는 보통 원격 연결에 필요한 주요 필드만 포함하며, 로컬 수신 설정이나 복잡한 분기 규칙은 담지 않습니다. 따라서 네이티브 설정을 링크로 변환하면 전체 동작이 빠질 수 있고, 링크를 가져온 뒤 생성되는 설정에는 클라이언트의 기본 인바운드와 라우팅이 추가될 수 있습니다. 두 설정 모두 연결은 되더라도 처리하는 트래픽 범위, DNS 경로, 규칙 우선순위는 서로 다를 수 있습니다.

클라이언트 자체 설정 파일에는 그룹, 표시 이름, 창 상태, 속도 측정 설정 등이 포함될 수 있으며, 이는 코어 공통 형식이 아닙니다. 이전 전에 원격 서버 설정만 보존할지 클라이언트 환경 전체를 보존할지 먼저 정하세요. 서버 하나만 다른 기기로 옮기려면 해당 클라이언트가 인식하는 공유 형식을 쓰는 편이 간단합니다. 복잡한 규칙을 유지하려면 라우팅과 DNS도 별도로 기록해야 하며, 공유 링크에 자동으로 포함될 것이라고 기대하면 안 됩니다. 사용자 지정 설정 전체를 가져올 때는 클라이언트가 시스템 프록시와 포트 설정을 계속 관리하는지도 확인하세요. 화면의 모든 스위치가 사용자 지정 설정을 덮어쓸 수 있는 것은 아닙니다.

형식 변환과 업데이트의 한계

변환은 이미 있는 정보를 재배치할 뿐, 누락된 서버 이름, 공개 키 계열 정보, 짧은 식별자, 전송 경로를 만들어 내지 못합니다. 변환기가 유효한 JSON을 출력해도 필드 의미가 올바르거나 대상 코어가 해당 조합을 지원한다는 보장은 없습니다. 새로운 전송 필드가 포함된 경우 오래된 파서는 알 수 없는 쿼리 매개변수를 무시할 수 있습니다. 가져온 뒤 화면에 서버 항목이 정상 표시되더라도 실제로는 필드가 빠졌을 수 있습니다. 원본 설정과 가져온 뒤의 세부 정보를 비교하세요. 목록에 이름이 표시된다는 것만으로 호환성이 확인된 것은 아닙니다.

구독을 업데이트하면 구독이 관리하는 항목이 다시 생성되는 경우가 많아 수동으로 수정한 내용이 다음 업데이트 때 덮어써질 수 있습니다. 테스트가 필요하다면 테스트 설정을 독립 항목으로 복사하고 기존 구독 그룹은 그대로 두세요. 복사와 그룹 기능은 클라이언트 화면에 따라 다를 수 있습니다. 업데이트 뒤 이름이 중복되더라도 같은 접속 지점이라고 단정할 수 없습니다. 주소, 전송 방식, 사용자 매개변수가 다를 수 있으므로 삭제 전에 주요 필드를 비교하세요. 그룹이 갑자기 비었다면 전체 설정을 연달아 삭제하고 다시 만들거나 초기화하지 말고 응답 내용과 형식부터 확인하세요.

전체 점검 순서는 다음과 같습니다. 구독 주소에 접속할 수 있는지 확인하고, 응답 텍스트가 예상한 형식인지 확인한 뒤, 클라이언트가 프로토콜을 인식하는지와 주요 필드가 유지되는지 확인하고, 마지막으로 코어 연결을 테스트합니다. 형식 문제와 원격 인증 문제는 따로 기록해야 합니다. 형식별 구조와 변환 한계를 알아보려면 base64 구독·네이티브 JSON·공유 링크 비교를 참고하세요. 이 페이지에는 온라인 변환 도구가 없습니다. 민감한 설정은 신뢰할 수 있는 로컬 도구와 클라이언트에서 처리해 변환 과정에서 정보 노출 범위를 넓히지 마세요.

시스템 프록시와 TUN의 적용 범위

시스템 프록시는 앱에 프록시 진입점을 제공하며, 관련 설정을 읽는 앱만 예상대로 이를 사용합니다. 일부 프로그램은 별도 네트워크 스택이나 자체 프록시 설정을 사용하므로 브라우저 접속이 된다고 모든 프로그램이 같은 경로를 거친다는 뜻은 아닙니다. TUN 모드는 가상 네트워크 인터페이스로 트래픽을 받아 더 넓은 범위에 적용되지만, 라우팅, 권한, DNS 등의 조건이 추가됩니다. 이는 프록시 프로토콜을 바꾸는 기능도 아니고 원격 설정을 자동으로 수정하는 기능도 아닙니다. 프로토콜 인증에 실패했을 때 TUN을 켜면 트래픽이 클라이언트로 들어오는 방식만 달라질 뿐, 서버가 잘못된 계정을 받아들이게 되지는 않습니다.

v2rayN의 '시스템 프록시 자동 설정'과 'Tun 모드 사용'은 작업에 맞게 선택하세요. 기본값처럼 모든 트래픽 처리 방식을 한꺼번에 켤 필요는 없습니다. 먼저 시스템 프록시를 사용해 시스템 설정을 따르는 앱 하나로 확인한 뒤, 필요할 때 TUN을 테스트하면 변수 수를 줄일 수 있습니다. Windows, macOS, Linux는 권한, 가상 인터페이스, 시스템 네트워크 설정이 다르므로 클라이언트와 운영체제의 안내를 따르세요. Android 클라이언트는 시스템에서 제공하는 가상 네트워크 처리 기능을 사용하므로 권한과 백그라운드 실행 상태를 확인하고, 같은 진입점을 사용하는 앱 여러 개가 서로 충돌하지 않도록 하세요.

규칙 순서·아웃바운드 태그·도메인 해석

라우팅 규칙은 보통 순서대로 검사하며, 먼저 일치하는 규칙이 아웃바운드를 결정합니다. 구체적인 규칙을 포괄적인 규칙보다 앞에 두고, 아웃바운드 태그가 실제 정의와 일치하는지 확인하세요. domainStrategy는 라우팅 중 도메인과 IP의 관계를 처리하는 방법을 정하며, 브라우저의 전체 DNS 동작을 제어하지는 않습니다. IPIfNonMatch는 도메인 규칙이 일치하지 않을 때 DNS 조회로 얻은 IP를 기준으로 추가 일치를 시도할 수 있다는 뜻입니다. 지리적 분류 규칙을 자동으로 만들거나 모든 도메인을 원하는 대로 분류해 주지는 않습니다. 실제 동작은 기존 규칙과 DNS 조회 결과에 따라 달라집니다.

아래는 Xray 네이티브 설정의 routing 필드에 넣을 수 있는 JSON 객체 조각이며, 전체 실행 설정은 아닙니다. 로컬 루프백 주소는 direct라는 아웃바운드로 보내고 나머지 TCP·UDP 트래픽은 proxy라는 아웃바운드로 보냅니다. 사용하려면 두 아웃바운드가 미리 정의되어 있어야 하며, 프록시 아웃바운드는 실제 요청의 네트워크 유형을 지원해야 합니다. 이 예시는 규칙 순서와 태그만 보여 줍니다. 완전한 LAN 예외, DNS 정책, 가상 인터페이스의 루프백 방지 설정을 대신하지 않으며, 클라이언트가 자동 생성한 라우팅 전체를 덮어쓰는 용도로도 사용할 수 없습니다.

{
  "domainStrategy": "AsIs",
  "rules": [
    {
      "type": "field",
      "ip": ["127.0.0.0/8", "::1/128"],
      "outboundTag": "direct"
    },
    {
      "type": "field",
      "network": "tcp,udp",
      "outboundTag": "proxy"
    }
  ]
}

DNS·UDP·문제 진단

도메인 해석은 앱, 운영체제, 코어 중 어디에서 실행되는지에 따라 라우팅에서 볼 수 있는 정보가 달라집니다. 앱이 먼저 도메인을 IP로 해석하면 코어가 원래 도메인 규칙을 직접 사용하지 못할 수도 있습니다. 트래픽 스니핑도 지원 범위와 적용 한계가 있으므로 도메인을 반드시 복원하는 기능으로 간주해서는 안 됩니다. DNS를 설정할 때는 누가 조회를 시작하고, 어떤 아웃바운드를 거치며, 누가 결과를 사용하는지 먼저 확인하세요. 프록시를 통해 DNS를 조회해야 하는데 프록시 자체의 주소도 먼저 해석해야 한다면 순환 의존이 생길 수 있습니다. 원격 접속 지점을 위한 명확하고 사용 가능한 DNS 경로를 마련하세요.

UDP를 사용하려면 로컬 진입점, 코어, 프로토콜 구현, 원격 서버가 모두 이를 지원해야 합니다. 웹은 정상인데 실시간 앱 하나만 실패한다면 UDP 전달 조건이 맞지 않거나 라우팅 범위가 부족할 수 있습니다. 프로토콜 이름만으로 사용 가능 여부를 판단할 수 없습니다. 테스트할 때는 실패하는 앱의 트래픽이 클라이언트에 들어오는지 확인한 다음, 사용 중인 네트워크 유형과 실제로 선택된 아웃바운드를 살펴보세요. 원격 연결은 안정적인데 일부 도메인만 실패한다면 규칙과 DNS를 먼저 확인하고, 모든 앱의 트래픽이 코어에 들어오지 않는다면 로컬 진입점부터 점검하세요. 자세한 규칙 문법은 사용자 지정 라우팅 규칙과 일치 우선순위를 참고하세요.

데스크톱과 Android 선택 경로

데스크톱에서는 v2rayN을 먼저 선택하고 Windows, macOS, Linux에 맞는 설치 파일을 고르세요. Windows의 Desktop과 클래식 WPF 인터페이스는 클라이언트 형태의 차이이지 프록시 프로토콜 두 종류가 아닙니다. macOS에서는 Apple Silicon과 Intel을 구분해야 하며, Linux에서는 프로세서와 패키지 형식을 맞춰야 합니다. 이러한 선택은 프로그램이 정상적으로 설치되고 실행되는지를 결정할 뿐, 원격 프로토콜 사용 가능 여부를 정하지는 않습니다. 설치 후에도 코어와 가져온 매개변수를 확인해야 합니다. 다운로드 파일은 다운로드 페이지에서 확인하세요. 프로토콜 가이드의 예시 이름만 보고 설치 파일을 추측하지 마세요.

Android에서는 먼저 설정이 어떤 코어 기능에 의존하는지 확인하세요. Xray 기능이 필요하면 v2rayNG를 우선 선택하고, V2Fly에 맞춰 관리 중인 설정과 절차가 있다면 v2flyNG를 검토할 수 있습니다. 이름이 비슷하다는 이유만으로 두 클라이언트의 앱 설정 전체를 서로 가져오면 안 됩니다. 특히 사용자 지정 JSON과 라우팅 리소스는 주의가 필요합니다. 프로세서 아키텍처는 프로토콜과 무관합니다. 최신 기기는 arm64가 흔하지만 실제 시스템 아키텍처와 설치 결과를 기준으로 선택하세요. 범용 패키지를 선택해도 코어가 지원하지 않는 프로토콜 조합은 해결되지 않습니다. 아키텍처와 기능은 별도로 확인해야 합니다.

안정적으로 사용 중인 서버와 새 구성 평가

안정적으로 사용 중인 서버가 있다면 현재 프로토콜을 유지하고 필요한 앱과 네트워크 유형을 지원하는지 먼저 확인하세요. 프로토콜 이름이 다르다는 이유만으로 바꾸기보다 기능 요구사항, 기기 호환성 문제, 관리상의 어려움처럼 분명한 이유가 있어야 합니다. 서버가 VMess만 제공한다면 클라이언트에서 VLESS를 선택해도 호환 연결이 생기지 않습니다. 서버가 여러 조합을 제공해야 같은 대상과 네트워크에서 비교할 수 있습니다. 각 조합이 정상적으로 인증되는지 먼저 확인한 뒤 최초 응답, 지속 전송, 백그라운드 안정성을 비교하세요. 실패하는 설정으로 속도를 측정하면 설정 오류가 성능 결과에 섞일 뿐입니다.

새 구성을 평가할 때는 클라이언트, 실제 코어, 프록시 프로토콜, 전송 방식, 보안 메커니즘, 흐름 제어 필드, DNS, 트래픽 처리 모드를 간단히 기록하세요. 한 번에 한 계층만 바꾸고, 정상 작동이 확인된 항목 하나를 유지하세요. 장시간 백그라운드 실행이 필요하다면 네트워크 복구와 시스템 백그라운드 제한을 확인하세요. 짧은 요청이 많다면 연결 설정과 재사용을 살펴보고, 지속 전송이 중요하다면 처리량, 리소스 사용량, 중단 후 복구를 확인하세요. 작업마다 적합한 선택이 다를 수 있으므로 하나의 지표로 모든 상황을 판단할 필요는 없습니다.

오류가 발생한 단계에 맞는 장으로 돌아가기

가져오는 단계에서 형식 오류가 표시되면 6장으로 돌아가 링크와 구독 형식을 확인하세요. 저장 후 코어가 시작되지 않으면 5장에서 지원 범위와 필드 구조를 확인하세요. 접속 지점에는 도달하지만 핸드셰이크에 실패하면 2장과 3장에서 인증 및 보안 설정을 점검하세요. 일부 앱만 실패하면 7장에서 트래픽 처리, 라우팅, DNS를 확인하세요. 연결은 되지만 배터리 사용량이 비정상적이면 4장에서 지속적인 재시도와 반복 측정을 살펴보세요. 이 순서는 프로토콜을 계속 바꾸는 것보다 재현하기 쉽고, 민감한 정보를 보호하면서 문제를 정확하게 설명하는 데도 도움이 됩니다.

최종 선택은 네 가지 조건으로 정리할 수 있습니다. 서버가 실제로 제공하고, 클라이언트에서 전체 설정을 표현할 수 있으며, 코어가 명확히 지원하고, 실제 사용 환경에서 검증된 조합이어야 합니다. 이 조건을 충족한 뒤 관리 편의성과 리소스 사용량을 고려하세요. 처음 설정한다면 빠른 시작 가이드에 따라 가져오기, 연결, 검증을 진행하세요. 세 클라이언트를 비교하려면 선택 가이드를 읽고, 구체적인 증상이 있다면 자주 묻는 질문을 확인하세요. 이 안내서는 선택에 영향을 미치는 기술적 경계를 설명하며, 서버 조건과 무관한 일률적인 프로토콜 순위를 제공하지 않습니다.