V2Ray 프로토콜 선택
및 코어 호환성 가이드

01 / 연결 구조

프로토콜·전송 방식·보안 계층의 차이

여러 매개변수가 함께 연결을 결정합니다

v2rayN에서 서버 편집 창을 열면 프로토콜 유형은 연결 설정의 일부일 뿐입니다. 주소와 포트는 연결 대상을 지정하고, 사용자 ID나 비밀번호는 인증에 사용됩니다. 전송 설정은 데이터를 전달하는 방식을 정하고, TLS 또는 REALITY는 해당 보안 핸드셰이크를 처리합니다. 라우팅 규칙은 어떤 요청을 이 연결로 보낼지 결정합니다. 계층을 나누어 이해해야 두 항목이 모두 VLESS로 표시되어도 나머지 필드를 바꿔 쓸 수 없는 이유를 알 수 있습니다.

앱의 요청은 보통 클라이언트의 로컬 인바운드로 들어온 뒤 코어의 라우팅에 따라 아웃바운드로 전달됩니다. 아웃바운드가 원격 서버에 연결하고, 원격 서버가 다시 목적지에 접속합니다. 그래픽 인터페이스는 매개변수를 관리하고 실제 연결은 코어가 수행합니다. 시스템 프록시나 가상 네트워크 인터페이스는 앱 요청을 인바운드로 전달합니다. 따라서 ‘클라이언트가 실행됨’, ‘로컬 프록시 포트가 열림’, ‘원격 핸드셰이크 성공’, ‘목적지 페이지 접속 가능’은 서로 다른 단계입니다. 연결 아이콘 하나만으로 모든 단계가 정상이라고 판단할 수 없습니다.

서버 주소, 서버 이름, 요청 호스트 이름

서버 주소에는 도메인이나 제공업체가 지정한 주소를 사용할 수 있습니다. TLS 서버 이름은 보통 인증서 이름을 확인하고 SNI에도 사용됩니다. HTTP 기반 전송에는 별도의 Host 또는 요청 호스트 필드가 있을 수 있습니다. 세 값은 같을 수도, 서버 구성에 따라 다를 수도 있습니다. 서버 설정을 기준으로 각 항목을 입력하세요. 편집 창의 도메인 필드를 모두 서버 주소로 바꾸거나 다른 사람의 화면에 나온 무관한 이름을 복사하면 안 됩니다.

전송 유형은 임의로 고르는 속도 설정이 아닙니다. 일반 TCP, WebSocket, gRPC 등을 사용하려면 서버에 해당하는 접속 지점이 있어야 합니다. 경로, 서비스 이름, 중간 리버스 프록시의 전달 규칙도 서로 일치해야 합니다. WebSocket 경로는 웹사이트의 임의 디렉터리가 아니며 gRPC 서비스 이름도 메모가 아닙니다. 원격 서버가 한 가지 전송만 허용하는 경우 로컬 옵션을 바꾸면 핸드셰이크가 실패할 뿐, 다른 연결 방식으로 자동 협상되지 않습니다.

원본 매개변수를 보관한 뒤 한 항목씩 수정하세요

연결 설정을 가져온 뒤에는 원본 항목을 그대로 두고 복사본으로 테스트하는 것이 좋습니다. 메모에 변경 사항을 기록하세요. 라우팅 규칙만 바꾸거나 서버 이름만 확인하는 식으로 한 번에 한 종류의 설정만 조정합니다. 코어, 전송 방식, DNS를 동시에 바꾸면 연결이 복구되어도 원인을 찾기 어렵고, 다음에 문제가 생겼을 때 다시 추측해야 합니다. 구독을 업데이트하면 편집 내용이 덮어써질 수 있으므로 계속 유지할 로컬 설정은 별도 항목이나 독립적으로 관리되는 구성에 보관하세요.

로그도 같은 방식으로 계층을 나눠 읽어야 합니다. 이름 확인에 실패하면 주소 해석을, 연결이 거부되면 원격 포트와 서비스 상태를, 인증서 이름이 맞지 않으면 시스템 시간과 서버 이름을 먼저 확인하세요. 핸드셰이크 이후 접속에 실패한다면 목적지 해석과 라우팅을 살펴봅니다. 비슷한 화면 메시지도 서로 다른 단계에서 발생할 수 있습니다. 모든 스위치를 무작정 바꾸기보다 로그에서 처음 발생한 유효한 오류를 찾아 작업 시각과 대조하면 원인을 빠르게 좁힐 수 있습니다.

02 / 인증과 암호화의 경계

VMess와 VLESS의 설계 차이

VMess: 프로토콜에 인증 및 암호화 기능 포함

VMess는 Project V 생태계에서 비교적 일찍 만들어진 프록시 프로토콜로, 사용자 인증과 데이터 보호 기능을 프로토콜 자체에 포함합니다. 클라이언트에는 원격 주소뿐 아니라 일치하는 사용자 ID가 필요하며, 양쪽이 지원하는 방식으로 요청을 구성해야 합니다. 최신 배포에서는 보통 AEAD 인증을 사용하지만 오래된 항목에는 추가 ID 개수 같은 과거 필드가 남아 있을 수 있습니다. 필드 이름만 보고 용도를 추측하거나 ‘호환’을 위해 임의의 값을 입력하지 마세요.

VMess 인증 과정은 시간 조건과 관련이 있어 시스템 시간이 크게 어긋나면 핸드셰이크가 실패할 수 있습니다. 문제를 해결할 때는 운영체제에서 자동 시간 동기화를 켜고, 표시된 시간대와 실제 시간 기준이 맞는지 확인한 뒤 다시 연결하세요. 클라이언트 메모를 바꾸거나 브라우저를 재시작하고 라우팅을 전환해도 인증 시간 문제는 해결되지 않습니다. 오래된 구독에서 구식 매개변수를 계속 요구한다면 구형 클라이언트에 의존하기보다 제공업체에 현재 사용할 수 있는 형식을 문의하세요.

VMess의 보안 옵션은 코어가 지원하는 기능 및 서버 요구 사항과 일치해야 합니다. 시작 단계에서는 알고리즘을 직접 지정하기보다 자동 선택을 사용하는 편이 낫습니다. 실제 처리 비용은 프로세서의 하드웨어 가속 지원 여부에 따라서도 달라집니다. 프로토콜 자체에 데이터 보호 기능이 있다고 해서 외부 TLS가 항상 불필요한 것은 아닙니다. 일부 배포에서는 TLS 접속 지점과 리버스 프록시를 함께 사용합니다. 외부 보안 계층이 필요한지는 전체 서버 구성에 따라 결정됩니다.

VLESS: 간결한 프로토콜 계층, 보안은 외부 계층에 위임

VLESS는 프록시 프로토콜 계층을 간결하게 구성하고 사용자 식별 같은 필수 정보만 유지하며, 전송 보안은 외부 방식에 맡기는 것을 목표로 합니다. 일반 설정의 암호화 필드에 none이 있으면 VLESS 프로토콜 계층에서 해당 데이터 암호화를 제공하지 않는다는 뜻입니다. 이것만으로 전체 연결이 보호되지 않는다고 단정할 수는 없습니다. 연결의 보안성을 판단하려면 TLS나 REALITY를 외부 계층에서 사용하는지, 인증 및 인증서 매개변수가 올바른지 확인해야 합니다.

반대로 사용자 ID가 있다고 해서 암호화 계층을 대신한다고 볼 수도 없습니다. 서버에서 TLS를 요구하는데 문제 해결을 위해 로컬 보안 계층을 끄면 서버가 연결을 거부할 수 있습니다. 평문 연결을 허용하는 별도 접속 지점이 있더라도 두 연결의 보안 수준은 같지 않습니다. VLESS를 선택하려면 서버가 제공한 전체 조합을 이해해야 합니다. 필드가 적다는 이유만으로 선택하거나 VMess를 아무 조건 없이 대체할 수 있는 프로토콜로 여겨서는 안 됩니다.

VLESS 설정의 flow는 특정 흐름 제어 방식을 뜻하며 일반적인 라우팅 분할과는 다릅니다. 일부 flow는 특정 코어, 전송 방식, 보안 계층과 함께 사용해야 하므로 한 연결의 값을 모든 VLESS 항목에 복사하면 안 됩니다. 클라이언트에 입력란이 있다는 것은 해당 값을 입력할 수 있다는 뜻일 뿐입니다. 실제 지원 여부와 조합의 유효성은 현재 코어와 서버가 함께 결정합니다.

프로토콜 선택은 원격 서버의 지원 여부부터 확인하세요

사용 중인 VMess 서버가 정상적으로 작동한다면 이름이 최신이라는 이유만으로 VLESS로 바꿀 필요는 없습니다. 두 프로토콜은 서버 인증 과정이 다르므로 로컬에서 프로토콜 유형만 바꿔서는 마이그레이션되지 않습니다. 올바르게 전환하려면 서버가 해당 접속 지점을 제공해야 합니다. 새 연결 정보를 가져온 뒤 목적지 접속과 필요한 UDP 앱을 확인하고, 마지막으로 기존 항목을 대체할지 결정하세요. 정상 작동이 확인된 설정을 보관하면 서버 변경과 로컬 환경 변경을 구분하는 데도 도움이 됩니다.

서버에서 두 프로토콜의 완전한 설정을 모두 제공한다면 같은 기기와 네트워크에서 비슷한 시간대에 연결 상태를 비교할 수 있습니다. 먼저 라우팅, 목적지, 테스트 작업을 동일하게 유지한 다음 연결이 안정적으로 수립되는지, 전송이 지속되는지, 절전 모드에서 복귀한 뒤 다시 연결되는지 확인하세요. 한 번의 속도 측정만으로 프로토콜 차이라고 결론 내리지 마세요. 출구 회선, 서버 부하, 전송 캡슐화, 로컬 DNS가 프로토콜 계층의 차이보다 더 크게 작용할 수 있습니다.

03 / 보안 모델 비교

Trojan, Shadowsocks, REALITY

Trojan: TLS를 기반으로 구성하는 프록시 연결

Trojan은 일반적으로 TLS 연결을 기반으로 보호된 채널 안에서 비밀번호 인증과 프록시 요청을 처리합니다. 설정 절차는 여러 계층을 조합하는 방식보다 단순해 보일 수 있지만, 비밀번호만 입력하면 끝나는 것은 아닙니다. 서버 주소, 포트, 서버 이름, 인증서 확인도 중요한 매개변수입니다. 인증서의 도메인과 입력한 이름이 다르면 클라이언트는 연결을 거부해야 합니다. 인증 실패를 무시해도 되는 일반 경고로 취급해서는 안 됩니다.

Trojan의 핸드셰이크 성능은 TLS 협상, 원격 응답, 네트워크 품질에 영향을 받습니다. TLS를 사용한다는 이유만으로 연결이 반드시 느리다고 볼 수는 없습니다. 조건에 따라 세션 재개로 반복 핸드셰이크 비용을 줄일 수 있지만, 실제 효과는 구현과 연결 수명에 달려 있습니다. 선택할 때는 원격 인증서의 유지 관리, 비밀번호 교체, 클라이언트 지원 여부를 확인하세요. 인증서 오류의 유형별 해결 방법은 TLS 핸드셰이크 및 인증서 오류 해결 가이드를 참고하세요.

Shadowsocks: 방식 이름이 호환 범위를 결정합니다

Shadowsocks는 SS라고도 하며, 사전 공유 키로 암호화된 프록시 채널을 만드는 방식입니다. 발전 과정에서 각 방식의 인증, 키 처리, 데이터 구성에 차이가 생겼습니다. 구형 방식, AEAD 방식, 최신 방식 계열은 모두 SS라는 이유만으로 서로 호환된다고 볼 수 없습니다. 가져올 때 정확한 방식 이름과 비밀번호 형식을 유지하세요. 특히 특정 길이의 키가 필요한 설정을 일반 비밀번호 입력란처럼 다루지 마세요.

SS는 필드가 비교적 단순해 암호화 방식과 클라이언트 호환성을 이해하기 좋은 예입니다. 하지만 연결 정보에 플러그인 매개변수가 있다면 별도의 호환 조건이 추가됩니다. 코어가 기본 SS 프로토콜을 지원한다고 해서 그래픽 클라이언트에서 모든 플러그인이 실행되거나 구독 변환 과정에서 플러그인 옵션이 보존되는 것은 아닙니다. 가져오기는 성공했지만 핸드셰이크가 실패한다면 원본 정보의 추가 요구 사항이 누락되지 않았는지 확인한 다음, 현재 클라이언트가 이를 처리할 수 있는지 살펴보세요.

REALITY: 독립된 프록시 유형이 아닌 보안 계층 방식

REALITY는 VLESS와 함께 쓰이는 경우가 많지만 VLESS의 프록시 기능 전체를 대신하지는 않습니다. VLESS는 프록시 요청을 정의하는 계층이고 REALITY는 특정 보안 핸드셰이크 방식이라고 이해할 수 있습니다. 클라이언트에는 보통 서버 이름, 공개 키, 짧은 ID가 필요하며 일부 구현에는 지문 관련 옵션도 있습니다. 해당 값은 서버 설정에 따라 정해지므로 목적지 웹사이트의 인증서나 다른 연결에서 임의로 추론할 수 없습니다.

클라이언트는 서버에서 제공한 공개 키를 저장하고 서버는 그에 대응하는 개인 키를 보유합니다. 두 역할을 혼동하면 안 됩니다. 구독에 공개 키가 포함되어 있다면 그대로 유지하세요. 로컬에서 새 키를 생성해도 원격 서버가 받아들이지 않습니다. 짧은 ID도 서버에서 허용하는 값과 일치해야 하며, 비워도 되는지는 실제 설정에 따라 다릅니다. 서버 이름 역시 주소 표시줄의 도메인을 임의로 대입하지 말고 제공업체가 지정한 값을 사용하세요.

REALITY 지원 범위는 코어 구현을 기준으로 확인해야 합니다. v2rayN과 v2flyNG가 비슷한 생태계에 속한다고 해서 옵션이 완전히 같다고 볼 수는 없습니다. REALITY, 특정 flow, 해당 전송 방식의 조합은 먼저 Xray 구현 요구 사항을 확인한 다음 그래픽 클라이언트에서 필드를 빠짐없이 생성하는지 살펴보세요. 인터페이스에 필수 매개변수가 없다면 같은 링크를 반복해서 가져와도 기반 기능이 추가되지는 않습니다.

이 세 가지 이름은 같은 종류끼리 단순 순위를 매길 수 있는 목록이 아닙니다. 비교할 때는 전체 연결 조합을 명시하고 유지 관리 비용, 기기 부담, 원격 서버 사용 가능성을 살펴보세요. 매개변수 정보가 불완전하다면 범용 최적값을 찾기보다 정확한 설정 정보를 확보하는 것이 중요합니다. 클라이언트는 누락된 필드만 보고 서버의 의도를 자동으로 알아내지 못합니다.

04 / 구현과 설정

V2Fly, Xray, 클라이언트의 관계

코어가 연결을 처리하고 클라이언트가 설정을 관리합니다

Project V는 이 생태계를 이해하기 위한 배경입니다. V2Fly는 V2Ray 관련 코어를 이어서 유지·발전시키고, Xray는 관련 기술 기반에서 독자적인 기능 발전 경로를 만들어 왔습니다. 두 코어는 공통 개념을 사용하지만 구현과 필드에는 차이가 있습니다. 코어는 그래픽 인터페이스의 다른 이름이 아닙니다. 같은 클라이언트에서 여러 코어를 호출할 수 있고, 코어가 지원하는 저수준 옵션이 모두 인터페이스의 스위치로 표시되는 것도 아닙니다.

데스크톱에서는 v2rayN을 우선 권장하며 Windows, macOS, Linux를 지원합니다. 설치 경로는 클라이언트 페이지에서 확인하세요. v2rayN은 서버 목록, 구독 그룹, 시스템 프록시, 설정 생성 등을 관리합니다. 선택할 수 있는 코어와 기능은 실제 제공되는 빌드 및 설정에 따라 달라집니다. 모든 설치 패키지에 같은 구성 요소가 포함된다고 가정하거나, 파일 이름을 바꿔 호환되지 않는 프로그램을 다른 코어처럼 보이게 해서는 안 됩니다.

Android에서는 v2rayNG를 우선 선택하며 Xray 코어를 사용합니다. v2flyNG는 V2Fly 코어를 사용하며 관련 설정의 대안으로 고려할 수 있습니다. 두 앱의 조작 방식은 비슷할 수 있지만 설정 필드와 기본 동작은 다를 수 있습니다. 앱을 고를 때는 익숙한 인터페이스보다 현재 서비스의 요구 사항을 먼저 확인하세요. REALITY 같은 특정 기능이 필요한 설정은 해당 구현을 기준으로 확인해야 하며, 앱 이름이 비슷하다는 이유만으로 지원 여부를 판단하면 안 됩니다.

설정 구조가 비슷해도 필드를 그대로 복사할 수 있는 것은 아닙니다

두 코어의 일반적인 설정은 인바운드, 아웃바운드, 라우팅, DNS 등의 개념을 사용하며 일부 기본 구조가 매우 비슷합니다. 하지만 전송 이름, 허용되는 필드 범위, 흐름 제어 방식, 새 기능 지원이 같다고 보장되지는 않습니다. JSON 문법 검사를 통과했다는 것은 괄호와 문자열의 형식이 올바르다는 뜻일 뿐, 현재 코어가 모든 필드를 이해한다는 의미는 아닙니다. 일부 오류는 실행하거나 연결을 시도할 때 나타납니다.

그래픽 클라이언트는 구독을 읽고 내부 서버 항목에 저장한 다음 코어에 전달할 설정을 생성하는 경우가 많습니다. 호환성 문제는 어느 단계에서든 생길 수 있습니다. 링크 파서가 매개변수를 인식하지 못하거나, 내부 모델이 확장 필드를 저장하지 못하거나, 코어가 생성된 설정을 거부할 수 있습니다. 먼저 편집 창의 값과 실행 오류를 확인하세요. 모든 문제를 원격 서버 탓으로 돌리지 마세요. 설정 구간은 JSON 구조 해설과 함께 살펴볼 수 있습니다.

코어 전환 전후 확인 순서

전환 전에 현재 프로토콜, 전송 방식, 보안 계층, flow, DNS, 라우팅 설정을 기록하고 정상 작동이 확인된 항목을 보관하세요. 전환 후에는 클라이언트의 설정 검사를 실행하거나 시작해 알 수 없는 필드, 누락된 구성 요소, 포트 충돌이 없는지 확인한 뒤 원격 연결을 테스트하세요. 브라우저 접속 결과만 유일한 기준으로 삼으면 로컬 트래픽 처리 실패와 원격 프로토콜 비호환을 혼동하기 쉽습니다.

일반 연결을 마이그레이션할 때도 기본값 변경 여부를 확인해야 합니다. 도메인 일치 방식, 스니핑, UDP 전달, 연결 재사용은 서버 편집 창에 표시되지 않아도 실제 요청에 영향을 줄 수 있습니다. 이전 환경을 재현하려고 모든 고급 옵션을 켜지 마세요. 필요한 최소 설정을 유지하고 기본 연결을 확인한 다음 실제로 필요한 규칙만 하나씩 복원하세요. 안정적인 마이그레이션은 스위치가 많아서가 아니라 설정 경계가 명확해서 가능합니다.

코어 업데이트와 구독 업데이트는 서로 다른 문제를 해결합니다. 전자는 로컬 구현 기능을 바꾸고 후자는 원격 연결 정보를 바꿉니다. 업데이트 후 연결이 복구되어도 서로를 대체할 수 있다는 뜻은 아닙니다. 이전에 없던 문제가 생기면 마지막으로 변경한 항목이 클라이언트, 코어, 구독 중 무엇인지 기록하고 오류 발생 시각을 보관하세요. 문제 해결 자료를 공유하기 전에는 설정의 인증 정보와 구독 주소를 제거하고 필요한 필드 이름과 오류 유형만 남기세요.

05 / 성능 확인

연결 속도, 리소스 사용량, 배터리

연결 수립과 지속적인 데이터 전송을 나눠 살펴보세요

‘속도’에는 연결 수립 대기 시간, 첫 응답, 지속 처리량, 장시간 안정성이 포함됩니다. 도메인 확인, 원격 서버까지의 왕복 시간, 보안 핸드셰이크, 원격 서버에서 목적지까지의 연결이 첫 응답에 영향을 줍니다. 지속적인 데이터 전송은 회선 대역폭, 혼잡 제어, 서버 부하, 기기의 처리 능력에 더 큰 영향을 받습니다. 짧은 페이지가 빨리 열린다고 대용량 파일 전송도 빠르거나 백그라운드 연결의 배터리 사용량이 적다는 뜻은 아닙니다.

프로토콜 계층을 간결하게 만들면 일부 처리 작업을 줄일 수 있지만, 네트워크 거리와 패킷 손실까지 없앨 수는 없습니다. WebSocket, gRPC 같은 전송 방식은 캡슐화가 추가되지만 기존 서버 인프라에 적합할 수도 있습니다. 추가 캡슐화가 병목인지 여부는 실제 환경에서 확인해야 합니다. 계층 수만 보고 특정 조합의 성능이 낮다고 단정하거나 서로 다른 회선에 배포된 서버의 결과를 프로토콜 간 엄밀한 비교로 간주하면 안 됩니다.

암호화 알고리즘의 리소스 사용량은 프로세서, 시스템 라이브러리, 코어 구현에 따라 달라집니다. 하드웨어 가속을 지원하는 기기에서는 특정 암호화를 적은 부하로 처리할 수 있지만 다른 기기에서는 결과가 다를 수 있습니다. 고속으로 데이터를 계속 전송하면 프로세서 부하가 두드러질 수 있고, 일반 웹 이용에서는 네트워크 응답을 기다리는 시간이 더 클 수 있습니다. 비교할 때는 기기 발열과 작업 완료 여부를 함께 살펴보고 일시적인 부하를 클라이언트 오류로 오해하지 마세요.

연결을 재사용한다고 모든 작업이 빨라지는 것은 아닙니다

연결 재사용은 여러 논리 요청이 하위 연결 하나를 공유하도록 하여 연결을 반복해서 만드는 비용을 줄일 수 있습니다. 반면 공유 중인 연결의 혼잡이나 끊김이 여러 요청에 함께 영향을 줄 수도 있습니다. 효과는 작업 유형, 전송 방식, 구현에 따라 다릅니다. 짧은 요청이 적은 경우와 대용량 데이터를 계속 전송하는 경우에는 적절한 설정이 다를 수 있습니다. 활성화 후 일부 앱이 멈춘다면 고급 옵션을 더 켜기보다 먼저 재사용을 끄고 비교해 보세요.

UDP를 사용하는 작업은 별도로 확인해야 합니다. 웹 페이지가 열린다는 것은 관련 TCP 또는 HTTP 요청이 완료되었다는 뜻일 뿐, 음성 통화나 실시간 서비스 등 UDP 앱의 전달까지 정상이라는 의미는 아닙니다. 클라이언트, 프로토콜 구현, 서버, 라우팅이 모두 제약을 만들 수 있습니다. 네트워크에 따라 UDP 처리 방식도 TCP와 다르므로 필요한 앱을 직접 사용해 확인하고, 웹 속도 테스트 하나로 모든 호환성을 판단하지 마세요.

모바일 배터리는 트래픽 처리 방식과 재연결에 더 크게 좌우됩니다

Android 배터리 사용량은 프로토콜 이름만으로 결정되지 않습니다. 가상 네트워크 인터페이스가 처리하는 데이터 범위, 백그라운드 앱 활동, 무선 신호, 연결 유지용 신호, 재연결 빈도가 모두 영향을 줍니다. 모바일 네트워크와 Wi-Fi를 오가면 기존 연결을 다시 설정해야 할 수 있습니다. 백그라운드에서 요청이 계속되면 재시도로 무선 모듈의 활성 시간이 늘어날 수 있습니다. 추가 배터리 소모를 전부 TLS나 REALITY 탓으로 돌리려면 충분한 근거가 필요합니다.

시스템의 배터리 최적화 설정에도 장단점이 있습니다. 백그라운드 실행을 지나치게 제한하면 클라이언트가 중지되어 앱을 다시 열 때 계속 재연결할 수 있습니다. 반대로 백그라운드 실행을 모두 허용하면 다른 앱의 지속적인 트래픽도 그대로 전달될 수 있습니다. 먼저 앱별 배터리 사용 기록을 확인하고 연결이 끊긴 시각이 화면 꺼짐이나 네트워크 전환과 일치하는지 살펴보세요. 한 번 끊겼다는 이유만으로 모든 시스템 최적화를 끄면 원인 파악이 어려워지고 다른 앱의 배터리 사용량에도 영향을 줄 수 있습니다.

재현 가능한 비교를 하려면 설정을 두 개 보관하고 같은 기기, 같은 네트워크, 같은 작업에서 번갈아 테스트하세요. 발열을 비교할 때는 충전하면서 테스트하지 않는 편이 좋습니다. 첫 접속 성공 여부, 지속 작업 중단 여부, 화면을 끈 뒤 복구 여부, 시스템 배터리 기록을 각각 남기세요. 여러 차례 관찰해도 같은 경향이 있을 때 선택에 반영할 만합니다. 서로 다른 출구와 시간대에 나온 단일 최고 속도로 프로토콜 순위를 매기면 안 됩니다.

06 / 설정 정보 교환

구독 형식, 공유 링크, 마이그레이션

구독은 설정을 전달하는 방식이지 프로토콜 자체가 아닙니다

구독 주소는 보통 여러 연결 정보를 반환하며 클라이언트가 내용을 인식하고 항목을 파싱해 그룹에 추가합니다. 반환 내용은 공유 링크 모음, 인코딩된 텍스트, 구조화된 설정일 수 있습니다. 같은 주소라도 요청 조건에 따라 다른 내용이 반환될 수 있습니다. 따라서 브라우저에서 구독 주소가 열린다는 것은 응답을 받았다는 뜻일 뿐, 현재 클라이언트가 처리할 수 있는 형식이거나 포함된 모든 프로토콜을 현재 코어가 지원한다는 뜻은 아닙니다.

공유 링크에도 각각의 규칙이 있습니다. VMess 링크는 인코딩된 구조화 데이터를 사용하는 경우가 많고, VLESS·Trojan·SS는 인증 정보와 쿼리 매개변수를 담은 URI 형식으로 제공되는 경우가 많습니다. 제공업체에 따라 확장 필드를 사용할 수도 있습니다. 일부 문자는 퍼센트 인코딩이 필요하며 메모와 쿼리 매개변수에는 라틴 문자 이외의 문자가 들어갈 수 있습니다. 복사할 때 끝부분이 빠지거나 줄바꿈이 섞이거나 메시지 앱에서 잘리면 가져오기에 실패할 수 있습니다.

Base64는 데이터를 인코딩하는 방식이지 암호화가 아닙니다. 구독이나 공유 내용을 눈으로 읽기 어려워도 바로 사용할 수 있는 인증 정보가 들어 있을 수 있습니다. 전체 구독 주소를 공개 게시판에 붙여 넣거나 출처가 불분명한 변환 서비스에 맡기지 마세요. 형식을 확인할 때는 먼저 로컬에서 콘텐츠 유형을 확인하고 인증 필드를 삭제하세요. 메모만 가리고 연결 정보 전체를 남겨도 유출 위험은 줄지 않습니다.

가져온 뒤에는 필드가 모두 보존되었는지 확인하세요

가져온 뒤 항목을 열어 프로토콜, 주소, 포트, 사용자 인증, 전송 유형, 경로, 보안 설정을 하나씩 대조하세요. REALITY 조합은 공개 키와 짧은 ID를 확인하고 VLESS는 필요한 flow를 살펴봐야 합니다. 목록에 항목이 나타났다는 것은 파서가 항목을 만들었다는 뜻일 뿐, 모든 확장 매개변수가 보존되었다는 뜻은 아닙니다. 메모가 맞더라도 중요한 필드가 비어 있으면 연결 설정은 완성되지 않은 것입니다.

클라이언트 간에 마이그레이션할 때는 양쪽에서 지원한다고 명시한 공유 형식을 사용하세요. 먼저 소수의 항목을 가져와 확인한 다음 나머지 그룹을 옮기면 됩니다. 앱 데이터 폴더를 통째로 복사하면 플랫폼별 경로, 로컬 포트, 전용 설정이 포함될 수 있으므로 일반적인 마이그레이션 방법으로 볼 수 없습니다. 데스크톱의 시스템 프록시 설정은 Android의 네트워크 트래픽 처리 설정으로 자동 변환되지 않습니다. 연결 정보는 옮길 수 있지만 로컬 트래픽 처리 방식과 권한은 다시 확인해야 합니다.

구독을 업데이트하면 일반적으로 원격 정보를 기준으로 항목을 다시 만들거나 병합합니다. 수동 편집 내용이 유지되는지는 클라이언트의 관리 방식에 따라 다릅니다. 메모, 라우팅 연결, 연결 필드를 계속 조정하려면 업데이트 시 어떤 설정이 덮어써지는지 먼저 확인하세요. 테스트 설정을 별도 그룹에 보관하고 원본 구독에 알아보기 쉬운 이름을 붙이면 다음 업데이트 후 서버가 모든 설정을 바꿨다고 오해하는 일을 줄일 수 있습니다.

목록이 비어 있다면 응답과 파싱 단계를 나눠 확인하세요

업데이트에 실패하면 먼저 주소가 온전한지, 만료되지 않았는지, 현재 네트워크에서 응답을 받을 수 있는지 확인하세요. 응답을 받았다면 연결 정보인지, 로그인 페이지인지, 일반 오류 문구인지 살펴봅니다. 요청 성공과 파싱 성공은 별개입니다. 웹 페이지 내용을 반복해서 인코딩해도 유효한 구독으로 바뀌지 않습니다. 더 자세한 확인 순서는 구독 업데이트 실패 및 빈 목록 점검표를 참고하세요.

일부 서비스는 User-Agent나 요청 매개변수에 따라 구독 형식을 선택합니다. 제공업체가 명확히 안내한 경우에만 설정을 조정하고, 시험 삼아 다른 클라이언트로 임의 위장하지 마세요. 업데이트 요청이 기존 프록시를 사용하는지도 확인해야 합니다. 아직 연결되지 않은 설정으로 같은 설정을 업데이트하려 하면 순환 문제가 생길 수 있습니다. 우선 사용할 수 있는 업데이트 경로를 하나 이상 확보하고 반환 형식을 확인한 다음 개별 항목의 호환성을 살펴보세요.

07 / 요청의 전달 경로

라우팅 규칙과 DNS의 역할 구분

라우팅은 아웃바운드를 선택하며 핸드셰이크 문제를 해결하지 않습니다

라우팅은 도메인, 주소, 포트 등의 조건에 따라 아웃바운드를 선택합니다. 코어가 요청을 처리하는 과정에서 적용되며 원격 인증을 대신하거나 인증서 이름 오류를 고치지는 않습니다. 모든 접속이 실패하면 먼저 로컬 트래픽 처리와 프록시 아웃바운드가 정상인지 확인하세요. 일부 도메인에서만 문제가 생긴다면 일치하는 규칙과 DNS 결과를 살펴보세요. 연결 문제와 분할 라우팅 문제를 구분하면 불필요한 설정 변경을 줄일 수 있습니다.

일반적으로 규칙은 순서대로 적용됩니다. 앞쪽의 넓은 조건이 먼저 일치하면 뒤에 있는 세부 조건은 적용되지 않을 수 있습니다. 기본 아웃바운드도 중요합니다. 일반적인 설정 구조에서는 규칙에 맞지 않는 요청이 기본 경로를 따를 수 있으며, 실제 동작은 생성된 설정을 확인해야 합니다. 규칙 이름만 보지 말고 참조된 아웃바운드 태그가 실제로 존재하는지, 대소문자와 철자가 일치하는지 확인하세요.

아래는 사설 주소를 직접 연결하는 구성을 보여 주는 라우팅 설정 일부입니다. 독립적으로 실행할 수 있는 완전한 클라이언트 설정은 아닙니다. 다른 설정 구간과 함께 사용해야 하며 direct 태그가 붙은 직접 연결 아웃바운드와 해당 주소 규칙 데이터가 이미 있어야 합니다. 그래픽 클라이언트가 같은 내용을 생성했다면 이 구간을 중복으로 추가하지 마세요. 라우팅 설정 화면에서 같은 의도를 표현하는 것이 우선입니다.

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

DNS가 처리되는 위치에 따라 규칙에서 확인할 수 있는 정보가 달라집니다

앱이 도메인을 프록시에 전달할 수도 있고, 로컬에서 먼저 해석한 뒤 주소만 보낼 수도 있습니다. 전자의 경우 코어가 도메인을 기준으로 규칙을 적용할 수 있지만 후자는 주소 정보만 남을 수 있습니다. 시스템 프록시, 앱 자체 프록시, 가상 네트워크 인터페이스를 통한 트래픽 처리는 요청 정보를 보존하는 방식이 서로 다릅니다. 따라서 같은 도메인 규칙이 한 방식에서는 적용되고 다른 방식에서는 적용되지 않아도 규칙 문법이 잘못된 것은 아닐 수 있습니다.

AsIs는 일반적으로 라우팅 일치를 위해 도메인을 주소로 변환하지 않는다는 뜻입니다. 그렇다고 전체 연결 과정에서 DNS가 필요 없어지는 것은 아닙니다. 다른 도메인 처리 방식은 주소 규칙과 일치하는지 확인하기 위해 특정 조건에서 DNS 조회를 수행할 수 있습니다. 처리 방식을 바꾸면 규칙 결과와 DNS 처리 비용이 함께 달라지므로 더 적극적으로 해석할수록 정확하다고 단순화할 수 없습니다. 도메인과 주소 중 무엇을 기준으로 판단할지 먼저 정한 다음 그 목적에 맞는 방식을 선택하세요.

코어 DNS, 운영체제 DNS, 브라우저의 암호화 DNS, 원격 목적지의 DNS 조회는 서로 다른 경로를 사용할 수 있습니다. 한 설정을 바꿔도 모든 요청에 적용되지는 않습니다. 브라우저와 다른 앱의 결과가 다르면 브라우저가 자체 DNS 조회를 하는지, 앱의 요청이 실제로 클라이언트를 거치는지 확인하세요. DNS 서버가 응답해도 접속 경로가 올바르다는 뜻은 아닙니다. 주소 확인에 성공한 뒤에도 요청이 예상과 다른 아웃바운드로 전달될 수 있습니다.

시스템 프록시, 스니핑, 로컬 네트워크 접속

시스템 프록시 자동 설정은 시스템 설정을 따르는 앱에 주로 영향을 주며 모든 트래픽을 처리하는 기능은 아닙니다. 글로벌 프록시, LAN 우회, 직접 연결 같은 모드 이름은 클라이언트에서 미리 정한 항목일 수 있으므로 실제로 생성되는 규칙을 확인하세요. 로컬 프린터, 공유 폴더, 내부 관리 페이지를 사용할 때는 사설 주소가 어떻게 처리되는지 먼저 확인하고, 필요한 경우 내부 도메인에 명시적인 규칙을 추가하세요.

트래픽 스니핑은 요청에서 도메인 등의 정보를 추출해 라우팅 판단에 활용할 수 있지만 모든 프로토콜을 식별하는 것은 아니며 앱 계층의 의미를 완전히 대신하지도 않습니다. 일부 설정은 목적지 주소 처리에도 영향을 줄 수 있으므로 목적에 맞게 활성화해야 합니다. 특정 사이트를 확인할 때 DNS와 라우팅 모드를 동시에 바꾸기보다 앱이 도메인과 주소 중 무엇을 전달했는지, 어떤 규칙이 일치했는지, 최종적으로 어떤 아웃바운드를 사용했는지 기록하는 편이 더 유용합니다.

IPv6도 전달 경로를 확인할 때 포함해야 합니다. 시스템이 주소 레코드를 받은 뒤 실제 연결에서 다른 주소 계열을 선택할 수 있습니다. 한쪽 경로만 규칙을 설정하거나 지원하면 간헐적으로 접속되는 것처럼 보일 수 있습니다. 특정 주소 계열을 무조건 끄기보다 로컬 네트워크, 서버, 목적지가 선택한 경로를 모두 지원하는지 확인하세요. 구체적인 설정 방법은 DNS 설정 가이드에서 이어서 확인할 수 있습니다.

08 / 선택과 최종 확인

사용 환경에 맞는 클라이언트와 프로토콜 선택

기존 서비스를 사용한다면 전체 조합을 유지하고 호환성부터 확인하세요

안정적으로 사용 중인 서비스가 있다면 프로토콜을 바꾸기보다 서버에서 제공한 전체 조합을 그대로 유지하는 것이 우선입니다. 데스크톱에서는 v2rayN을 권장하며 운영체제와 프로세서 아키텍처에 맞는 설치 패키지를 선택하세요. Windows의 Desktop 및 클래식 WPF 인터페이스 선택은 Windows 설치 및 설정 안내를 참고하세요. 인터페이스 형태로 원격 프로토콜의 보안성을 판단할 수는 없습니다. 실제 기능은 호출되는 코어와 생성된 설정에 따라 달라집니다.

Android에서는 먼저 v2rayNG를 고려하세요. 기존 서비스가 V2Fly의 특정 기능을 전제로 구성되어 있다면 v2flyNG도 검토할 수 있습니다. 처음 확인할 때는 설정 정보가 완전한 연결 하나만 가져와 기본 접속을 확인한 다음 필요한 분할 라우팅과 트래픽 처리 범위를 활성화하세요. 처음부터 모든 구독, 규칙, 백그라운드 설정을 함께 옮기면 실패 원인이 정보 파싱인지 코어 호환성인지 시스템 권한인지 구분하기 어렵습니다.

선택지가 여러 개라면 제약 조건부터 정리한 뒤 비교하세요

서버에서 VMess, VLESS, Trojan, SS를 모두 제공한다면 먼저 반드시 충족해야 하는 조건을 정리하세요. 기기가 해당 코어를 지원하는지, UDP가 필요한지, 특정 전송 접속 지점에 의존하는지, 인증서나 키를 계속 관리할 수 있는지 확인합니다. 조건을 충족하는 조합 중에서 연결 안정성과 실제 작업 경험을 비교하세요. REALITY는 완전한 보안 계층 조합의 일부로 평가해야 하며 프로토콜 선택 메뉴에서 모든 연결을 단독으로 대체할 옵션을 찾으면 안 됩니다.

여러 기기를 사용할 때는 모든 기기에 적용되는 최소 공통 설정을 찾으려는 실수를 피해야 합니다. 모든 기기가 같은 접속 지점을 사용해야 하는 것은 아닙니다. 하나의 서비스에서 클라이언트마다 호환되는 설정을 제공할 수도 있습니다. 데스크톱의 새 필드를 다른 코어에 무리하게 복사하면 호환성을 잃을 수 있고, 이름을 통일하려고 필요한 매개변수를 지우면 보안 조건이 깨질 수 있습니다. 편집 창의 내용을 모두 똑같이 맞추기보다 관리 목표와 라우팅 의도를 통일하세요.

모바일과 데스크톱의 장시간 사용 시 확인할 점

데스크톱을 장시간 사용할 때는 시스템 절전 모드에서 복귀하는 과정, 네트워크 전환, 포트 충돌, 앱의 시스템 프록시 사용 여부를 확인하세요. Android에서는 백그라운드 제한, 트래픽 처리 대상 앱, 배터리 기록도 살펴봐야 합니다. macOS를 처음 설치할 때 시스템 차단이나 권한 안내가 나타나면 설치 및 네트워크 권한 해결 방법을 참고하세요. 플랫폼 권한 문제는 운영체제에서 해결해야 하며 사용자 ID나 프로토콜 유형을 바꿔도 해결되지 않습니다.

짧은 웹 접속을 위한 설정은 연결 수립과 첫 응답이 중요합니다. 지속적인 데이터 전송을 위해서는 작업 중 멈춤, 재연결, 기기 부하를 살펴보세요. 실시간 앱은 UDP 경로도 별도로 확인해야 합니다. 작업마다 중요한 기준이 다르므로 네트워크 환경을 무시한 고정 속도 순위는 제시하지 않습니다. 테스트 조건을 설명하고 다시 확인할 수 있는 결과가, 조건 없는 추천 태그보다 오래 참고하기 좋습니다.

실패하면 매개변수를 무작정 바꾸지 말고 단계별로 돌아가세요

시작 자체가 안 되면 설정 검사, 실행 환경, 로컬 포트를 먼저 확인하세요. 시작은 되지만 핸드셰이크에 실패한다면 원격 주소, 인증, 전송 방식, 보안 계층을 확인합니다. 핸드셰이크는 성공했는데 일부 앱이 실패하면 트래픽 처리 방식, UDP, DNS, 라우팅을 살펴보세요. 구독 업데이트 후에만 오류가 생겼다면 업데이트 전후의 주요 필드를 비교하고, 화면을 끈 뒤에만 문제가 생기면 백그라운드 제한과 재연결 로그를 먼저 확인하세요.

문제를 확인할 때는 비교 기준을 하나 이상 고정하세요. 같은 기기, 같은 네트워크, 같은 목적지, 같은 연결 중 몇 가지를 유지한 채 변수를 하나만 바꿔야 합니다. 로그는 명확한 작업 한 번을 기준으로 수집하고 오래된 오류와 현재 정상 연결 기록을 섞지 마세요. 오류 종류와 인증 정보를 제거한 필드 구조는 공유할 수 있지만 전체 인증 정보는 공개하지 마세요. 그래야 우연히 접속이 복구되는 데 그치지 않고 다음에도 재현할 수 있는 판단을 얻을 수 있습니다.

최종 설정에는 네 가지가 명확히 드러나야 합니다. 어떤 프로토콜 조합을 선택했는지, 현재 코어가 왜 이를 지원하는지, 어떤 앱의 트래픽이 클라이언트를 거치는지, 문제가 생기면 어디에서 근거를 확인할 수 있는지입니다. 처음 설정할 때는 빠른 시작 가이드를 따르세요. 이 페이지는 기본 절차의 배경과 경계를 설명해 필요한 설정을 근거에 따라 선택하도록 돕습니다.