프로토콜 및 코어 가이드

1. 설정 계층과 항목별 역할

먼저 클라이언트, 코어, 서버를 구분하세요

클라이언트는 설정을 관리하는 그래픽 인터페이스로, 공유 링크 가져오기, 구독 그룹 관리, 서버 선택, 시스템 프록시 변경을 담당합니다. 코어는 클라이언트가 생성한 설정을 읽어 실제로 포트 대기, 도메인 이름 확인, 라우팅 판단, 원격 연결을 수행합니다. 서버는 클라이언트 설정에 맞는 접속 구성을 실행합니다. 각 요소의 역할은 서로 다릅니다. 따라서 인터페이스에서 항목을 저장할 수 있다는 것은 입력 검사를 통과했다는 뜻일 뿐, 코어가 모든 설정 항목을 지원하거나 서버가 같은 방식으로 구성되었다는 뜻은 아닙니다.

연결은 네 계층으로 나누어 살펴볼 수 있습니다. 프록시 프로토콜은 인증과 프록시 요청의 표현 방식을 정하고, 전송 방식은 해당 데이터를 전달하는 방법을 정합니다. 보안 계층은 외부 연결의 암호화와 상대 인증을 처리하며, 라우팅 규칙은 어떤 요청을 이 연결로 보낼지 결정합니다. 구독 링크는 설정을 배포하는 경로이며, 연결 계층에 속하지 않습니다. 구독 주소를 서버 주소 입력란에 넣거나 전송 이름을 프록시 프로토콜로 착각하면 이후 확인 과정에서 항목 간 관계가 어긋납니다. 먼저 편집 중인 것이 구독 그룹인지 개별 서버 항목인지 확인하세요.

표시 이름만 보고 설정을 판단하지 마세요

서버 별칭은 목록에서 항목을 구분하기 위한 이름으로, 구독 제공자가 자유롭게 지정할 수 있습니다. 별칭에 프로토콜 이름이 들어 있어도 실제 프로토콜 항목이 그 종류라는 뜻은 아닙니다. 편집 창의 유형, 주소, 포트, 인증 정보, 전송 방식, 보안 설정을 기준으로 판단하세요. 주소는 도메인 이름일 수도 있고 IP 주소일 수도 있습니다. 포트는 원격 서버가 수신 대기하는 포트이며 로컬 프록시 포트와 다릅니다. 브라우저가 로컬 프록시에 연결할 때 사용하는 포트와 원격 포트는 서로 다른 연결 구간에 속하므로, 한쪽을 바꿔도 다른 쪽 문제가 자동으로 해결되지는 않습니다.

전송 경로와 서버 이름도 서로 바꿔 쓸 수 없습니다. 웹 연결 기반 전송에서는 경로가 보통 서버 측 요청 분배에 사용되고, 서버 이름은 보안 핸드셰이크나 인증서 검증에 관여합니다. 일부 구성에는 요청 헤더의 호스트 이름도 포함됩니다. 세 항목은 배포 방식에 따라 같을 수도 다를 수도 있습니다. 클라이언트에서 항목이 가까이 배치된 것은 편집을 쉽게 하기 위한 것으로, 의미까지 같다는 뜻은 아닙니다. 문제를 해결할 때는 원본 설정을 항목별로 확인하고, 모든 도메인 항목을 서버 주소로 바꾸지 마세요.

변경을 최소화해 재현 가능한 조건을 만드세요

구독 설정에는 대개 필요한 구성이 이미 지정되어 있으므로, 선호에 따라 한 계층만 임의로 바꾸는 것은 적절하지 않습니다. 기존 항목의 보안 계층을 다른 유형으로 바꿔도 서버에 해당 기능이 자동으로 추가되지는 않습니다. 전송 방식도 서버에서 함께 지원해야 합니다. 두 가지 방식을 비교하려면 서버에서 제공한 완전한 설정 두 개를 확보하고, 로컬 라우팅과 테스트 대상, 접속 네트워크를 동일하게 유지하세요. 항목 하나의 유형만 바꾸면 의미 있는 프로토콜 비교가 아니라 연결 실패로 이어질 수 있습니다.

첫 문제 해결에 앞서 클라이언트 이름, 실행 중인 코어, 프로토콜 유형, 전송 방식, 보안 계층을 기록하고 문제가 가져오기, 시작, 핸드셰이크, 접속 중 어느 단계에서 발생하는지도 적어 두세요. 막연한 ‘사용 불가’를 구체적인 단계로 나눌 수 있습니다. 로그에 설정 항목을 인식하지 못한다는 내용이 있으면 코어와 설정 형식을 먼저 확인하세요. 코어는 시작했지만 원격 핸드셰이크에 실패했다면 주소, 인증 정보, 보안 설정을 확인하면 됩니다. 여러 계층을 동시에 바꾸면 이전에 작동하던 설정으로 되돌리기도 어려워집니다.

2. 네 가지 프록시 프로토콜 비교

VMess와 VLESS: 역할의 차이

VMess는 Project V 생태계에서 비교적 일찍 사용된 프록시 프로토콜로, 사용자 인증과 메시지 보호 메커니즘을 포함합니다. 일반적인 설정에서는 사용자 식별자가 인증 정보로 쓰입니다. 과거 구현에는 여러 인증 방식이 있었으며, 최근 설정은 대체로 AEAD 방식을 기반으로 합니다. 오래된 가이드에 나오는 추가 ID 값을 새로운 설정의 권장값으로 그대로 사용해서는 안 됩니다. 클라이언트 사용자는 서버가 제공한 항목대로 가져오고 시스템 시간을 정확하게 유지하는 것이 중요합니다. 일부 인증 실패는 시간 오차와 관련될 수 있으므로 곧바로 회선 문제라고 단정하지 마세요.

VLESS는 역할을 분리하는 설계에 따라 프로토콜 자체를 단순화하고, 일반적인 배포 환경에서 전송 보안은 외부 보안 계층에 맡깁니다. 암호화 항목이 비어 있는 경우에도 연결 전체가 반드시 평문이라는 뜻은 아니며, 보안 설정을 생략해도 된다는 의미도 아닙니다. 실제 보호 여부는 바깥 계층에서 TLS, REALITY 또는 명시적으로 설계된 다른 보안 채널을 올바르게 활성화했는지에 달려 있습니다. 보통 사용자 식별자로 인증하지만 VMess의 인증 정보, 암호화 항목, 전송 설정과 임의로 바꿔 쓸 수는 없습니다. VLESS를 선택할 때는 보안 계층과 관련 흐름 제어 요구 사항도 함께 설정해야 합니다.

일부 VLESS 구성은 XTLS Vision과 같은 특정 흐름 제어 방식을 사용합니다. 흐름 제어 항목은 모든 전송 방식에 적용되는 범용 가속 옵션이 아닙니다. 코어, 전송 방식, 서버가 모두 조건을 충족해야 합니다. 기존 구독에 흐름 제어가 설정되어 있지 않다면 임의로 항목을 추가하지 마세요. 기존 설정에 포함되어 있다면 다른 코어에 맞추려고 삭제해서도 안 됩니다. 두 경우 모두 연결 동작이 달라질 수 있습니다. 프로토콜 이름이 더 최신인지보다 양쪽이 완전한 구성을 지원하는지를 우선 확인하세요.

Trojan: 올바른 TLS 설정이 중요합니다

일반적인 Trojan 설계에서는 프록시 인증과 요청을 TLS 채널로 전달하며, 비밀번호를 주요 인증 정보로 사용합니다. 이 비밀번호는 프록시 인증에 쓰이고, 인증서 검증은 외부 보안 연결의 상대를 확인하는 역할을 하므로 서로 대체할 수 없습니다. 비밀번호가 맞아도 인증서 이름이 일치하지 않으면 연결에 실패할 수 있고, 인증서 검증에 성공해도 비밀번호가 틀리면 프록시 요청을 처리할 수 없습니다. 편집할 때 서버 주소, 서버 이름, 포트, 비밀번호를 각각 확인하세요. 모든 핸드셰이크 오류에 ‘안전하지 않은 연결 허용’을 적용하는 것은 올바른 해결 방법이 아닙니다.

사용자 입장에서 Trojan의 설정 항목은 비교적 단순하지만, 배포가 쉬운지는 인증서, 도메인 이름, 서버 관리 방식에 달려 있습니다. 코어마다 확장 전송과 추가 옵션을 지원하는 범위도 다를 수 있습니다. 프로토콜 이름이 붙은 공유 링크만 보고 어떤 전송 조합을 사용하는지 추정할 수는 없습니다. 구독을 가져온 뒤 경로가 비어 있거나 보안 옵션이 사라지거나 확장 항목을 인식하지 못한다면 원본 설정을 확인하세요. 모든 클라이언트가 같은 설정을 자동으로 보완한다고 가정해서는 안 됩니다.

Shadowsocks: 단순한 구조와 암호화 방식 호환성

Shadowsocks는 비교적 단순한 프록시 구조를 사용하며, 일반적인 설정의 핵심 항목은 서버 주소, 포트, 비밀번호, 암호화 방식입니다. 암호화 방식마다 데이터 처리와 키 요구 사항이 다르므로 비밀번호만 남기고 방식을 임의로 바꾸면 안 됩니다. 초기 방식, 널리 쓰이는 AEAD 방식, 이후 등장한 새 프로토콜 계열은 기본적으로 서로 호환되지 않습니다. 일부 방식은 특정 길이나 인코딩 형식의 키를 요구합니다. 클라이언트에서 일반 텍스트를 입력할 수 있다고 해서 서버도 이를 동일한 유효 키로 해석한다는 뜻은 아닙니다.

설정 계층을 줄이고 싶은 환경에서 이 프로토콜을 사용하는 경우가 많지만, 적합성은 클라이언트 구현, 서버의 암호화 방식, 추가 전송 구성 요소 사용 여부에 따라 달라집니다. 공유 링크가 추가 구성 요소를 참조하는데 현재 클라이언트가 이를 지원하지 않는다면 기본 항목만 가져오는 것으로는 충분하지 않습니다. 리소스 사용량을 비교할 때도 추가 구성 요소를 전체 연결 비용에 포함해야 합니다. 구조가 단순하면 일부 처리 단계를 줄일 수 있지만 원격 대역폭, 회선 혼잡, 애플리케이션 요청 방식까지 바뀌지는 않습니다.

3. TLS 및 REALITY 설정 항목

인증서 검증, 서버 이름, 시간

TLS는 상위 연결을 보호하고 인증서 검증 등의 방식으로 상대의 신원을 확인합니다. 서버 주소는 네트워크 연결에 사용되고, 서버 이름은 보통 핸드셰이크의 이름 표시와 인증서 대조에 사용됩니다. 둘은 반드시 같을 필요는 없지만 서버 설정과 일치해야 합니다. IP 주소로 연결하면서 인증서는 도메인 이름용으로 발급된 경우 서버 이름까지 IP 주소로 바꾸면 이름 검증에 실패할 수 있습니다. 검증을 끄고 오류를 우회하는 대신 서버에서 요구하는 이름을 확인하세요.

인증서 검증에는 기기 시간과 인증서 신뢰 체인도 영향을 줍니다. 기기 날짜가 크게 어긋나면 인증서가 아직 유효하지 않거나 이미 만료된 것으로 판단될 수 있습니다. 서버가 적절한 인증서 체인을 제공하지 않으면 일부 환경에서 신뢰 설정이 완료되지 않을 수도 있습니다. 같은 기기에서 여러 서버에 동시에 인증서 오류가 발생하면 먼저 기기 시간과 네트워크 환경을 확인하세요. 특정 설정 하나만 실패한다면 해당 서버의 인증서와 이름을 우선 점검하면 됩니다. 원인에 따라 해결 방법도 달라지므로 비밀번호를 계속 바꿔도 도움이 되지 않습니다.

REALITY에서 추가로 맞춰야 하는 항목

클라이언트 측 REALITY 설정에는 보통 서버 이름, 서버 공개 키, 짧은 ID 등의 항목이 있습니다. 인증 방식은 일반적인 공개 인증서 배포와 다릅니다. 서버 공개 키는 해당 서버 설정에서 받아야 하며 클라이언트에서 임의로 생성한 값으로 대체할 수 없습니다. 짧은 ID의 값과 형식도 서버에서 허용하는 범위에 맞아야 합니다. 보안 계층 옵션을 바꾸기만 하면 활성화되는 기능이 아닙니다. 클라이언트와 코어가 REALITY를 지원해야 하며, 서버도 해당 방식으로 구성되어 있어야 합니다.

공개 키와 사용자 식별자는 서로 다른 역할을 합니다. 사용자 식별자는 프록시 계층에서 인증에 사용되고, 공개 키는 관련 보안 인증에 쓰이며, 짧은 ID에는 별도의 일치 조건이 적용됩니다. 두 입력란의 값이 비슷해 보여도 한 항목을 다른 곳에 복사한다고 같은 설정이 되지는 않습니다. 인터페이스에 클라이언트 핑거프린트 옵션이 있을 수도 있으며, 이는 핸드셰이크 동작에 영향을 줍니다. 핑거프린트는 임의로 입력하는 브랜드 표시가 아닙니다. 현재 코어가 명시적으로 지원하는 값을 사용하고 제공자가 안내한 조합을 유지하세요.

일부 가이드에서는 REALITY, VLESS, Vision을 함께 표기해 세 가지가 항상 한꺼번에 필요하다고 오해하기 쉽습니다. 실제로는 프록시 계층, 보안 계층, 흐름 제어 계층을 각각 이해한 뒤 구현에 따라 유효한 조합을 확인해야 합니다. 한 조합이 작동했다고 해서 모든 전송 방식에서 같은 흐름 제어를 지원한다고 추정해서는 안 됩니다. 특정 코어 전용 항목을 다른 코어 설정으로 옮겨도 같은 방식으로 실행된다고 기대할 수도 없습니다. 인터페이스에 비슷한 이름이 있는지가 아니라 사용 중인 코어의 실제 기능을 기준으로 판단하세요.

전송 경로와 협상 설정

WebSocket에는 경로와 요청 헤더 설정이 자주 쓰이고, gRPC에는 서비스 이름과 관련 모드 설정이 자주 사용됩니다. 이러한 항목은 서버 및 중간 프록시 설정과 일치해야 합니다. 보안 핸드셰이크가 성공한 뒤에도 경로나 서비스 이름이 잘못되면 전송 단계에서 실패할 수 있습니다. 이런 오류는 인증서만 확인해서 해결되지 않습니다. ALPN은 애플리케이션 계층 프로토콜 협상 선호도를 나타내며, 설정값도 배포 요구 사항에 맞아야 합니다. 후보 값을 더 많이 추가한다고 호환성이 반드시 좋아지는 것은 아닙니다. 오히려 서버가 처리할 준비가 되지 않은 경로로 연결될 수 있습니다.

보안 계층 설정을 저장하기 전에 원본 공유 설정과 항목별로 대조하세요. 특히 복사할 때 공백, 인코딩, 대소문자가 달라지지 않았는지 확인해야 합니다. 새 항목의 의미를 모르겠다면 먼저 클라이언트가 지원하는지, 이어서 코어가 지원하는지 확인하세요. 비어 있는 항목을 모두 채워야 설정이 완성되는 것은 아닙니다. 여러 옵션은 기본값을 유지하거나 설정하지 않는 것이 맞습니다. 원인 파악을 위해 임시로 수정해야 한다면 원본을 복사해 두고 테스트가 끝난 뒤 되돌리세요. 보안 검증의 장기 설정을 우연히 한 번 연결된 결과만으로 정해서는 안 됩니다.

4. 속도, 리소스, 연결 비용

첫 연결과 지속 전송을 나눠서 확인하세요

사용자가 말하는 ‘속도’는 웹 페이지를 처음 여는 시간, 다운로드 지속 속도, 동영상 재생 시작 시간, 상호작용 요청의 응답 시간 등 여러 의미일 수 있습니다. 첫 연결에는 도메인 이름 확인, 네트워크 연결, 보안 핸드셰이크, 프록시 요청이 포함될 수 있습니다. 지속 전송은 대역폭, 혼잡 제어, 회선 손실, 서버 부하의 영향을 더 많이 받습니다. 핸드셰이크 단계를 줄이는 구성이라고 대용량 파일 다운로드가 반드시 빨라지는 것은 아닙니다. 반대로 지속 전송 성능이 좋은 회선도 도메인 이름 확인이 느리면 첫 접속이 더디게 느껴질 수 있습니다.

프록시 프로토콜의 암호화와 캡슐화에는 처리 비용이 들지만, 최신 기기에서는 병목이 다른 곳에 있는 경우가 많습니다. 처리 성능이 크게 제한되거나 높은 처리량이 계속 유지되거나 동시 연결이 많을 때 프로토콜 구현과 하드웨어 가속의 차이가 더 두드러질 수 있습니다. 일반적인 웹 탐색에서는 원격 회선과 대상 사이트의 응답이 대부분의 시간을 차지할 수 있습니다. 한 번의 다운로드 결과만으로 서버 부하 변화를 프로토콜 탓으로 돌리거나 모든 기기에 동일한 속도·사용량 순위를 적용하지 마세요.

다중화와 전송 캡슐화의 한계

다중화는 적은 수의 하위 연결에 여러 논리 요청을 실어 연결을 반복해서 만드는 비용을 줄이려는 방식입니다. 다만 여러 요청이 한 회선을 공유하는 방식도 달라집니다. 하위 연결에서 패킷 손실이나 지연이 발생하면 여러 요청이 함께 영향을 받을 수 있습니다. 일부 전송이나 흐름 제어 조합은 일반적인 다중화 설정과 맞지 않아 강제로 활성화하면 효과가 없거나 오류가 발생할 수 있습니다. 먼저 클라이언트와 서버가 기본적으로 호환되는 조합을 사용하고, 연결을 자주 새로 만드는 것이 실제 원인임을 확인한 뒤 지원되는 다중화 방식을 검토하세요.

웹 전송과 같은 캡슐화 계층을 추가하면 특정 배포 환경에서 접속이나 트래픽 분배에 유리할 수 있지만, 추가 헤더와 버퍼링, 중간 프록시 제한이 생길 수도 있습니다. 기본 연결 경로가 짧다고 모든 네트워크에서 더 안정적인 것은 아닙니다. 중간 프록시를 거치는 연결이 더 복잡하다고 반드시 느린 것도 아닙니다. 비교할 때는 두 설정이 같은 지역과 서버 리소스에 연결하는지 확인하세요. 회선 차이와 프로토콜 차이가 섞이면 결과는 해당 연결 두 개의 차이만 설명할 뿐, 프로토콜 자체를 대표하지 않습니다.

지연 시간 테스트를 올바르게 해석하기

기본 네트워크 탐색은 특정 계층에 도달할 수 있는지만 보여 주며, 프록시 인증이나 대상 사이트 접속까지 완전히 검증하지는 않습니다. 실제 연결 지연 테스트는 보통 프록시 연결을 거쳐 지정한 대상에 접속하지만, 결과는 테스트 주소, 라우팅 규칙, 도메인 이름 확인, 시간 제한 설정의 영향을 받습니다. 테스트에 성공했다는 것은 해당 요청이 처리되었다는 뜻이지 모든 애플리케이션이 프록시를 사용한다는 뜻은 아닙니다. 실패했다면 어느 단계에서 오류가 났는지 확인하세요. 첫 연결을 확인하는 순서는 v2rayN 첫 연결 및 프록시 적용 확인을 참고하세요.

비교할 때는 같은 네트워크와 비슷한 시간대를 사용하고 같은 대상을 지정한 뒤 항목별로 테스트하고 횟수는 적절히 제한하세요. 대용량 작업 여러 개를 동시에 실행하거나 구독을 자동 업데이트하면서 연결을 비교하지 마세요. 요청 성공 여부, 첫 응답의 안정성, 지속 전송 중단 여부를 기록하는 편이 가장 잘 나온 수치 하나만 남기는 것보다 유용합니다. 반복 테스트에서 결과가 계속 뒤바뀐다면 억지로 우열을 정하지 말고 ‘현재 조건에서는 일관된 차이가 없음’으로 결론을 제한하세요.

리소스를 살펴볼 때도 클라이언트 인터페이스와 코어 프로세스를 구분해야 합니다. 로그를 오래 많이 보관하거나 목록을 자주 새로 고치거나 백그라운드 테스트를 실행하면 인터페이스 부하가 늘어날 수 있습니다. 지속 연결과 규칙 처리는 주로 코어에서 이루어집니다. 시스템 작업 관리 도구에서는 둘을 함께 확인해 창의 리소스 사용량을 프로토콜 비용으로 오해하지 마세요. 메모리 사용량 증가는 연결 캐시, 도메인 캐시, 규칙 모음 때문일 수도 있으므로 일시적인 최고치만 보고 프로토콜을 바꾸지 마세요. 테스트와 백그라운드 작업을 중지한 뒤 안정된 상태를 관찰하세요.

5. V2Fly 및 Xray 코어

같은 기술 기반이어도 기능은 다를 수 있습니다

Project V는 설정을 기반으로 프록시 연결, 라우팅, 다양한 전송을 처리하는 기술 생태계를 형성했습니다. V2Fly는 V2Ray 관련 프로젝트의 발전을 이어 왔고, Xray는 이 기술 기반에서 갈라져 나와 자체 목표에 따라 프로토콜과 전송 기능을 확장했습니다. 두 프로젝트는 일부 개념과 과거 설정 구조를 공유해 항목이 비슷해 보이기도 합니다. 하지만 각자 발전하면서 지원 범위, 기본 동작, 확장 항목은 완전히 같지 않습니다. 코어 선택은 기능이 맞는지를 따져야 하며 단순히 신구 관계로 설명하기 어렵습니다.

REALITY, XTLS Vision 등의 조합을 사용할 때는 Xray의 지원 여부와 설정 요구 사항을 확인하세요. V2Fly가 같은 의미로 처리한다고 가정해서는 안 됩니다. 두 코어가 모두 지원하는 프로토콜이라도 구체적인 전송 방식, 암호화 방식, 추가 옵션을 확인해야 합니다. 지원 목록에 프로토콜 이름이 있다고 해서 과거 및 신규 확장 기능까지 모두 쓸 수 있다는 뜻은 아닙니다. 항목을 인식하지 못하거나 시작에 실패하면 프로토콜 전체를 기준으로 호환성을 추측하지 말고 어떤 기능에서 문제가 발생하는지 좁혀 보세요.

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

v2rayN은 서버 목록, 구독 그룹, 로그, 라우팅 상태를 확인하고 싶은 사용자를 위한 데스크톱 설정 관리 클라이언트입니다. 실제로 관리할 수 있는 코어 기능은 사용 중인 코어와 클라이언트의 연동 상태에 따라 달라지므로 창 이름만으로 판단해서는 안 됩니다. v2rayNG는 Android용으로 Xray 관련 설정에 주로 사용되며, v2flyNG는 V2Fly 계열을 위한 Android 대안입니다. 두 모바일 클라이언트의 인터페이스가 비슷해도 설정을 옮기기 전에 지원 범위를 항목별로 확인하세요. 이름만 바꾼 같은 프로그램으로 취급하면 안 됩니다.

클라이언트 업데이트, 코어 업데이트, 구독 업데이트는 서로 별개의 작업입니다. 클라이언트 업데이트는 인터페이스와 설정 생성 로직에 영향을 주고, 코어 업데이트는 실행 중 사용할 수 있는 기능에 영향을 줍니다. 구독 업데이트는 원격에서 제공한 서버 항목을 교체하거나 추가합니다. 구독 업데이트에 성공해도 코어가 지원하지 않는 기능이 추가되지는 않으며, 코어를 업데이트해도 잘못된 구독 주소가 수정되지는 않습니다. 작업 전에 어느 계층을 바꾸려는지 확인하세요. 업데이트한 뒤 로그에서 실제 실행 중인 코어 식별자를 확인하고 기존 연결이 예상대로 동작하는지 검증하세요.

설정 호환성은 형식뿐 아니라 의미로 판단하세요

두 파일 모두 JSON으로 파싱된다는 사실은 문법이 올바르다는 뜻일 뿐입니다. 필드 구조, 허용 값, 기본값, 동작 방식이 호환성을 결정합니다. 어떤 항목은 파싱 단계에서 거부되지만 일부는 무시될 수 있으며, 무시되는 항목은 오히려 문제를 알아차리기 어렵게 합니다. 다른 코어로 옮길 때는 전체 설정 파일을 그대로 교체하지 말고 대상 클라이언트에서 지원하는 공유 링크를 다시 가져와 설정을 생성하는 방법을 우선 고려하세요. 사용자 지정 라우팅, 도메인 이름 확인, 특수 전송이 포함되면 해당 부분을 나누어 작성 방식과 의미를 확인하세요.

코어를 옮겨 테스트할 때는 복구할 수 있도록 원본 설정을 보관하고, 먼저 이미 작동하는 서버 하나로 확인하세요. 코어 변경, 새 구독 가져오기, 라우팅 변경을 한꺼번에 하면 실패 원인을 찾기 어렵습니다. 시작 로그에 인식되지 않은 항목이 없는지 확인한 다음 보안 핸드셰이크와 대상 접속을 검증하고, 마지막으로 복잡한 규칙을 옮기세요. 기존 코어에서만 지원되는 기능이라면 원래 구성을 유지하거나 서버에서 제공하는 다른 완전한 구성을 받아야 합니다. 오류가 난 항목을 삭제해 억지로 시작시키지 마세요.

오픈 소스라는 점은 구현을 살펴보고 지속적으로 관리할 수 있다는 의미지만, 실제 환경에서 기능이 작동하는지 확인하는 일을 대신하지는 않습니다. 프로젝트마다 오픈 소스 라이선스가 다를 수 있으며, 라이선스는 코드의 사용과 배포를 규정할 뿐 연결 속도나 서버 호환성을 직접 결정하지 않습니다. 이 사이트는 다운로드와 안내를 제공하며 프로젝트 자체의 기술 정의를 대신하지 않습니다. 설치 파일의 운영체제와 프로세서 아키텍처만 확인하려면 설치 파일 페이지로 돌아가세요. 프로토콜 기능은 이 장의 코어와 설정 항목 관계를 기준으로 판단하면 됩니다.

6. 구독 형식과 가져오기 호환성

구독 가져오기와 설정 해석은 별개의 단계입니다

구독 링크는 보통 설정 내용을 반환하는 주소입니다. 반환되는 내용은 공유 링크 모음, 인코딩된 텍스트, 구조화된 설정 등일 수 있습니다. 클라이언트는 먼저 응답을 받아 형식을 판별한 뒤 항목을 자체 서버 레코드로 변환합니다. 따라서 ‘구독 업데이트 실패’에는 네트워크 요청 실패, 응답 형식 불일치, 개별 항목 파싱 실패가 모두 포함될 수 있습니다. 브라우저에서 주소가 열린다는 것은 어떤 응답을 받았다는 뜻일 뿐, 현재 클라이언트에 적합한 형식이거나 모든 설정을 지원한다는 뜻은 아닙니다.

인증이 만료된 주소는 웹페이지 안내를 반환할 수 있고, 다른 주소는 리디렉션되거나 빈 내용을 반환할 수 있습니다. 클라이언트가 웹페이지를 구독 텍스트로 해석하려 하면 형식 오류가 표시되거나 가져온 항목이 없을 수 있습니다. 이때는 구독 그룹에 입력한 전체 주소, 접근 권한, 제공자가 안내한 형식을 확인하세요. 같은 주소를 여러 그룹에 반복해서 추가하지 마세요. 구독 주소에는 접근 권한 정보가 포함되는 경우가 많으므로 비밀번호처럼 안전하게 보관하세요. 오류를 공유할 때는 쿼리 매개변수와 개인 식별 정보를 가리고 오류 유형만 남기세요.

공유 링크는 가져오는 과정에서 항목이 변환됩니다

프로토콜마다 공유 링크의 내부 구조가 다릅니다. 설정 객체를 인코딩해 링크에 넣는 방식도 있고, 사용자 정보, 호스트, 포트, 쿼리 매개변수로 항목을 표현하는 방식도 있습니다. 퍼센트 인코딩은 예약 문자를 표현하는 데 쓰입니다. 인코딩 단계가 잘못되거나 복사 중 구분자가 빠지면 파싱 결과가 달라질 수 있습니다. 문자열이 알아보기 어렵다고 임의로 디코딩해 저장하지 말고, 모든 더하기 기호나 슬래시를 일괄 치환하지도 마세요. 먼저 클라이언트의 표준 가져오기 기능을 사용한 뒤 실패한 항목에서 어떤 설정이 누락되었는지 확인하세요.

가져온 뒤에는 변환이 제대로 되었는지 확인해야 합니다. 특히 보안 계층, 공개 키, 짧은 ID, 흐름 제어, 경로, 서비스 이름은 구현에 따라 다르게 처리될 수 있습니다. 별칭과 그룹이 보인다고 중요한 설정까지 모두 보존된 것은 아닙니다. 일부 클라이언트는 기본 프로토콜은 인식하지만 링크의 확장 매개변수는 지원하지 않을 수 있습니다. 이 경우 서버 목록은 정상으로 보여도 실제 생성된 설정이 서버 요구 사항과 맞지 않을 수 있습니다. 편집 창을 제공자 안내와 대조하고 시작 로그에서 실행 중 해당 설정이 수락되는지 확인하세요.

전체 설정과 단일 서버 항목을 구분하세요

라우팅, 도메인 이름 확인, 인바운드, 여러 아웃바운드를 포함하는 전체 설정은 서버 공유 링크 하나와 다릅니다. 전체 설정을 단일 항목 가져오기 창에 붙여 넣으면 가져오지 못하거나 일부만 추출될 수 있습니다. 반대로 단일 링크에는 전체 로컬 라우팅 정책이 들어 있지 않은 경우가 많습니다. 구독을 바꾼 뒤에도 로컬 애플리케이션의 연결 경로가 달라지지 않는다면 라우팅이 서버 항목과 별도로 관리되기 때문일 수 있습니다. 공유 링크 하나가 로컬 수신 설정, 시스템 프록시, 앱별 선택까지 자동으로 수정한다고 기대하지 마세요.

구독 그룹을 사용하면 설정의 출처를 추적하기 쉽습니다. 업데이트 후 원격 제공자가 항목을 바꾸거나 삭제하거나 표시 이름을 변경할 수 있으며, 로컬에서 직접 편집한 내용이 유지되는지는 클라이언트 동작에 따라 다릅니다. 오래 보관할 실험 설정은 먼저 별도 항목으로 복사하고 용도를 명확하게 표시한 뒤 테스트하세요. 복사본은 원본 구독의 변경 사항을 자동으로 반영하지 않으므로 이후 확인과 관리가 필요합니다. 모든 매개변수를 직접 제어하려고 하면서 구독 업데이트가 수동 설정을 알아서 수정할 것이라고 기대해서는 안 됩니다.

같은 구독이 두 클라이언트에서 다르게 보이면 어느 한쪽 코어가 불안정하다고 바로 판단하지 말고 실제로 가져온 항목 수와 주요 설정을 비교하세요. 한쪽은 형식을 지원하지만 다른 쪽은 링크 일부만 지원할 수 있습니다. 한쪽은 기존 프록시를 통해 구독을 가져오지만 다른 쪽은 직접 접속을 시도할 수도 있습니다. 먼저 ‘어떤 내용을 가져왔는지’와 ‘설정을 어떻게 실행하는지’를 나누어 확인한 뒤 네트워크 접속 방식을 점검하세요. 필요하다면 대상 클라이언트용으로 제공자가 명시한 형식을 사용해 인증 정보가 신뢰할 수 없는 온라인 변환 서비스에 노출되지 않도록 하세요.

7. 라우팅, 로컬 접속, 배터리

시스템 프록시와 라우팅은 서로 다른 문제를 해결합니다

시스템 프록시 설정은 해당 설정을 따르는 애플리케이션에 요청을 보낼 로컬 주소와 포트를 알려줍니다. 코어의 라우팅은 요청이 들어온 뒤 직접 연결, 프록시 연결, 차단 중 어떤 방식으로 처리할지 결정합니다. ‘시스템 프록시 자동 설정’을 선택해도 모든 프로그램이 반드시 연결되는 것은 아닙니다. 특정 라우팅 규칙을 선택해도 접속되지 않은 프로그램이 자동으로 프록시를 사용하게 되지는 않습니다. 웹페이지에 변화가 없다면 먼저 브라우저가 시스템 프록시를 읽는지, 로컬 포트가 올바른지 확인하세요. 그다음 요청이 코어에 도달한 뒤 어떤 규칙에 일치했는지 살펴보면 됩니다.

로컬 수신은 필요한 인터페이스에만 열어 두는 것이 일반적입니다. 기기의 애플리케이션만 사용할 경우 문제 해결을 위해 모든 네트워크 인터페이스에 임의로 수신을 허용할 필요는 없습니다. 로컬 네트워크에서 공유해야 한다면 접근 제어와 기기 방화벽도 함께 고려하세요. 수신 주소를 바꾼 뒤에도 시스템 프록시가 이전 주소를 가리킬 수 있습니다. 포트를 다른 프로세스가 사용 중이면 코어가 시작되지 않거나 인바운드를 만들지 못할 수 있습니다. 이 경우 원격 프로토콜은 실행 단계에 도달하지 못합니다. 자세한 확인 방법은 로컬 포트 사용 중 문제 해결을 참고하세요.

규칙 순서와 도메인 이름 확인

라우팅은 보통 규칙 순서대로 일치 여부를 확인하고, 요청이 규칙에 맞으면 지정된 아웃바운드로 전달합니다. 도메인 규칙은 요청에 도메인 정보가 유지되는지에 따라 적용 여부가 달라질 수 있습니다. 주소 규칙은 이름 확인 결과와 도메인 처리 방식의 영향을 받을 수 있습니다. 적용 범위가 넓은 규칙을 앞에 두면 뒤에 있는 세부 규칙이 적용되지 않을 수 있습니다. 아래는 Xray 형식 설정의 일부로, 로컬 도메인 두 개를 직접 연결하도록 지정하는 예시만 보여 줍니다. 단독으로 실행할 수 있는 완전한 파일이 아니므로 통합하기 전에 direct라는 이름의 아웃바운드가 정의되어 있는지, 사용 중인 코어의 문법에 맞는지 확인하세요.

{
  "routing": {
    "rules": [
      {
        "type": "field",
        "domain": [
          "full:localhost",
          "domain:local"
        ],
        "outboundTag": "direct"
      }
    ]
  }
}

규칙 일치와 도메인 이름 확인 위치는 서로 다른 설정입니다. 애플리케이션이 먼저 이름을 확인한 다음 주소를 프록시에 전달할 수도 있고, 도메인 이름을 로컬 프록시에 넘겨 처리하게 할 수도 있습니다. 코어의 도메인 이름 확인 정책, 시스템 설정, 브라우저 자체 설정이 각각 작동할 수도 있습니다. 일부 도메인만 접속되지 않는다면 실제 요청에서 도메인 이름과 IP 주소 중 무엇을 사용하는지, 확인된 주소에 도달할 수 있는지 살펴보세요. 한 곳의 이름 확인 주소만 바꾸고 전체 요청 경로가 통일되었다고 단정하지 마세요. 규칙 순서를 파악하지 않은 채 예외 항목을 계속 추가하는 것도 피해야 합니다.

Android 접속과 앱별 프록시

Android 클라이언트는 보통 시스템이 제공하는 가상 네트워크 인터페이스로 애플리케이션 트래픽을 받습니다. 이는 데스크톱 애플리케이션이 시스템 프록시를 읽는 방식과 다릅니다. 연결을 활성화할 때 시스템 권한이 필요하며, 같은 접속 방식을 사용하는 다른 앱과 충돌할 수도 있습니다. 앱별 프록시는 어떤 앱을 접속 경로에 포함할지 정하지만, 연결 경로에 들어온 트래픽도 코어 라우팅에 따라 직접 연결될 수 있습니다. 따라서 앱을 선택했다고 모든 요청이 원격 서버를 거치는 것은 아닙니다. 반대로 앱을 선택하지 않았다면 코어 규칙으로 해당 앱을 나중에 경로에 포함할 수 있는 것도 아닙니다.

배터리 사용량은 프로토콜과 관련이 있지만 이름만으로 판단할 수는 없습니다. 지속적인 업로드와 다운로드, 약한 신호에서의 재전송, 잦은 재연결, 빈번한 백그라운드 확인, 앱의 주기적 깨우기는 무선 통신과 프로세서를 계속 활성 상태로 유지할 수 있습니다. 두 설정이 처리하는 앱 트래픽이 다르면 배터리 사용량을 직접 비교하기 어렵습니다. 측정할 때는 같은 앱 작업과 화면 상태를 유지하고 추가 테스트를 줄인 뒤 시스템 배터리 사용량과 연결 로그를 확인하세요. 연결이 반복해서 끊긴다면 모든 보안 설정을 먼저 낮추기보다 재연결 원인을 찾으세요.

클라이언트를 배터리 최적화 예외에 추가하면 백그라운드 연결 유지에 도움이 될 수 있지만, 백그라운드 활동 기회가 늘어날 수도 있습니다. 백그라운드 동작을 제한하면 배터리를 아낄 수 있지만 대기 후 연결 복구에 영향을 줄 수 있습니다. 메시지를 계속 받아야 하는지에 따라 선택하세요. 앱별 프록시는 불필요한 접속 범위를 줄일 수 있지만 배터리가 일정 비율만큼 줄어든다고 보장하지는 않습니다. 자세한 설정 방법은 v2rayNG 백그라운드 및 절전 설정을 참고하세요. 테스트가 끝난 뒤에는 필요하지 않은 백그라운드 탐색을 꺼서 진단 작업의 부하가 일반 사용량에 포함되지 않도록 하세요.

8. 사용 환경별 선택과 단계별 문제 해결

제약 조건을 먼저 정하고 구성을 비교하세요

사용 가능한 구독이 있다면 첫 번째 기준은 서버에서 실제로 제공하는 설정이고, 두 번째는 클라이언트와 코어가 해당 설정을 완전히 지원하는지입니다. 데스크톱에서는 v2rayN으로 관리와 확인을 시작할 수 있으며 Android에서는 필요한 기능에 따라 v2rayNG 또는 v2flyNG를 선택하면 됩니다. 구독에 안정적으로 작동하는 지원 조합 하나만 있다면 프로토콜 이름을 바꾸기 위해 설정을 다시 나눌 필요는 없습니다. 서버에서 여러 조합을 제공한다면 보편적인 최적 구성을 미리 정하기보다 첫 응답, 지속 전송, 백그라운드 안정성, 관리 복잡성을 비교하세요.

관리 비용이 중요한 환경에서는 선택 기능을 많이 쌓는 것보다 설정 항목이 명확하고 출처가 신뢰할 수 있으며 안정적으로 업데이트되는 편이 중요합니다. 새로운 보안 계층이나 특수 흐름 제어가 필요하다면 이를 명시적으로 지원하는 코어를 선택하고 서버에서 완전한 설정을 받아야 합니다. 처리 성능이 낮은 기기에서는 지속 작업 중 리소스 사용량을 직접 확인하고 불필요한 캡슐화, 탐색, 백그라운드 동시 작업을 줄이세요. 모바일 기기는 화면이 켜진 상태의 일회성 연결만으로 평가를 끝내지 말고 네트워크 전환과 대기 후 복구도 테스트해야 합니다.

가져오기부터 접속까지 단계별로 범위를 좁히세요

첫 번째 단계에서는 입력과 파싱을 확인합니다. 구독에서 서버 항목이 생성되지 않았다면 요청 성공 여부, 응답 형식, 링크 전체가 입력되었는지 확인하세요. 항목은 표시되지만 코어가 시작되지 않는다면 인식되지 않은 항목, 잘못된 매개변수, 로컬 수신 오류를 살펴보세요. 이 단계에서는 아직 연결이 시작되지 않았을 수 있으므로 원격 서버를 먼저 바꾸지 마세요. 인터페이스에서 로그 위치를 찾기 어렵다면 v2rayN 메인 창 기능 살펴보기를 참고해 서버 편집, 하단 상태 표시줄, 로그 영역을 확인하세요.

두 번째 단계에서는 원격 연결과 보안 인증을 확인합니다. 코어가 정상적으로 시작된 뒤 주소 확인 실패, 연결 시간 초과, 연결 거부, 보안 핸드셰이크 실패, 프록시 인증 실패를 구분하세요. 시간 초과가 비밀번호 오류를 직접 의미하지 않으며, 인증 오류를 로컬 포트 변경으로 해결할 수도 없습니다. 로그의 오류 단계에 따라 도메인 이름 확인, 원격 포트, 시간, 서버 이름, 인증 정보, 보안 설정을 각각 확인하세요. 서버 상태를 로컬에서 제어할 수 없다면 작동 중인 항목을 무작위로 바꾸기보다 제공자에게 해당 설정을 확인하세요.

세 번째 단계에서는 요청이 실제로 접속 경로에 들어오는지, 어떤 라우팅 규칙을 따르는지 확인합니다. 코어의 테스트 요청은 성공했는데 브라우저에서 접속되지 않는다면 브라우저의 프록시 설정 출처, 로컬 수신, 규칙 일치를 중점적으로 확인하세요. 특정 앱만 실패한다면 앱별 접속 방식과 도메인 이름 확인 동작을 비교하고, 특정 대상만 실패한다면 대상 서버 상태, 규칙, 이름 확인 결과를 점검하세요. Android에서는 앱별 적용 범위와 시스템 권한도 확인해야 합니다. ‘서버 사용 가능’과 ‘애플리케이션 접속 정상’을 따로 검증하면 같은 서버를 반복해서 바꾸는 일을 줄일 수 있습니다.

결론이 적용되는 범위를 함께 기록하세요

연결은 되지만 동작이 불안정할 때 성능과 배터리 사용량을 살펴보세요. 먼저 백그라운드 속도 측정과 동시 다운로드를 중지하고 같은 네트워크에서 여러 설정의 안정성을 비교한 뒤 다른 접속 네트워크에서도 확인하세요. 특정 네트워크에서 모든 설정이 실패한다면 해당 네트워크의 이름 확인, 접속, 회선 조건을 먼저 살펴보세요. 한 항목만 실패한다면 해당 서버 상태와 설정 조합을 다시 확인하면 됩니다. 한 번에 한 가지 요인만 바꾸고 변경 전 결과를 보관해 우연히 복구된 것을 특정 설정의 확실한 효과로 오해하지 마세요.

유효한 선택을 하려면 네 가지 질문에 답할 수 있어야 합니다. 서버가 제공한 전체 구성은 무엇인지, 현재 코어가 지원하는지, 애플리케이션이 예상대로 접속하는지, 실제 작업에서 안정적인지 확인하세요. 프로토콜에 영구적인 빠르기나 우열을 붙일 필요는 없습니다. 설정 출처, 주요 항목, 테스트 조건, 오류 단계를 기록하면 이후 업데이트나 이전 작업 때 비교할 근거가 됩니다. 작업 순서를 다시 확인하려면 빠른 시작 가이드로 돌아가세요. 특정 오류는 문제 해결에서 계속 확인할 수 있습니다. 클라이언트를 다시 설치하고 설정 전체를 새로 만드는 것보다 문제를 찾기 쉽습니다.