총 24개 항목입니다. 각 항목에는 바로 이동할 수 있는 앵커가 있어 주소를 복사해 위치를 공유할 수 있습니다. 메뉴 이름은 클라이언트 버전에 따라 다를 수 있습니다.
PROTOCOL / TRANSPORT
프로토콜 및 전송
프로토콜은 연결 양쪽이 프록시 요청을 주고받는 방식을 정합니다. TCP, WebSocket 같은 전송 방식은 별도 계층이므로 보안 계층과 서버 설정도 함께 확인해야 합니다.
프로토콜 및 전송 · 프록시 프로토콜
VMess
VMess는 Project V 생태계의 프록시 프로토콜로, 사용자 인증과 데이터 암호화 기능을 제공하며 사용자 ID로 사용자를 식별합니다. 클라이언트와 서버의 사용자 ID, 전송 방식 및 관련 매개변수가 일치해야 합니다. 시스템 시간이 맞지 않아도 인증에 실패할 수 있습니다. VMess라는 이름만 보고 다른 노드의 포트, 경로, 보안 계층 설정을 그대로 적용하지 마세요.
VLESS는 간결한 프로토콜 계층을 지향하며 자체적으로 데이터를 암호화하지 않습니다. TLS나 REALITY의 역할은 배포 방식에 맞춰 확인해야 합니다. 사용자 ID, 흐름 제어, 전송 프로토콜, 보안 계층은 서로 다른 항목이므로 하나로 다른 항목을 대신할 수 없습니다. xtls-rprx-vision을 사용하는 경우 서버 요구사항에 맞게 입력하고 해당 조합을 코어가 지원하는지 확인하세요.
Trojan은 일반적으로 TLS로 보안 연결을 설정한 뒤 비밀번호로 인증하며, VMess나 VLESS의 사용자 ID를 인증 항목으로 사용하지 않습니다. 가져온 뒤 비밀번호, 서버 이름, 전송 설정을 확인하세요. 포트가 같다는 이유만으로 설정이 호환된다고 판단할 수는 없습니다. 연결에 실패하면 TLS 핸드셰이크 실패인지 비밀번호 인증 실패인지 구분한 다음 관련 매개변수를 확인하세요.
Shadowsocks는 보통 SS로 줄여 부르며, 사전 공유 자격 증명과 지정된 암호화 방식으로 프록시 트래픽을 처리합니다. 암호화 방식, 비밀번호, 포트가 서버 설정과 일치해야 합니다. 방식에 따라 키 형식과 코어 지원 조건이 다를 수 있습니다. 공유 링크를 가져온 뒤에도 암호화 방식이 올바르게 인식됐는지 확인하고, 모든 SS 설정을 같은 형식으로 취급하지 마세요.
클라이언트는 화면과 설정 관리를 담당하고, 코어는 실제 연결 처리를 담당합니다. 클라이언트에 옵션이 표시된다고 해서 현재 코어가 반드시 지원하는 것은 아닙니다.
코어 및 생태계 · 연결 처리
Xray
Xray는 V2Ray 생태계에서 발전한 프록시 코어 프로젝트로, 프로토콜 처리, 라우팅, 아웃바운드 연결 등을 담당합니다. VLESS, REALITY, Vision 등의 설정은 클라이언트 이름만 볼 것이 아니라 사용 중인 Xray 버전의 지원 여부를 확인해야 합니다. 코어를 바꾼 뒤에는 연결을 다시 검증하세요. 기존 설정의 일부 필드 의미나 지원 범위가 달라질 수 있습니다.
V2Fly는 V2Ray 코어 개발을 이어가는 커뮤니티 프로젝트로, 일부 인터페이스에는 v2fly 또는 V2Ray Core로 표시됩니다. Xray와 공통된 역사를 지녔지만 이후 기능, 설정 필드, 지원 범위는 완전히 같지 않습니다. 설정이 JSON 형식이라는 이유만으로 두 코어 사이에서 그대로 전환할 수 있다고 생각하지 마세요. 특히 프로토콜, 보안 계층, 라우팅 기능을 확인해야 합니다.
v2rayN은 서버 목록, 구독 가져오기, 라우팅, 시스템 프록시 등을 관리할 수 있는 데스크톱 GUI 클라이언트입니다. 인터페이스에서 설정한 내용은 결국 코어가 실행할 구성으로 변환되므로 문제 해결 시 클라이언트 버전과 현재 코어를 함께 기록하세요. 데스크톱 버전과 클래식 WPF 버전은 메뉴 위치가 다를 수 있으니 실제 버전에 맞춰 찾아야 합니다.
v2rayNG와 v2flyNG는 모두 Android GUI 클라이언트이며, 각각 Xray와 v2fly 코어를 주된 기반으로 합니다. 서버 설정을 관리할 수 있지만 모든 공유 링크, 구독 형식, 프로토콜 확장이 서로 호환된다는 뜻은 아닙니다. 처음 연결할 때 시스템 VPN 권한을 요청하는 경우가 많습니다. 이 권한은 트래픽을 가로채도록 허용하는 것이며 원격 서버 연결이 완료됐다는 의미는 아닙니다.
트래픽 처리 범위, 연결 다중화, 테스트 지표에는 각각 한계가 있습니다. 기능을 켜거나 끄기 전에 앱이 프록시를 사용하지 않는 문제인지, 원격 연결이 실패하는 문제인지 먼저 확인하세요.
클라이언트 기능 · 트래픽 진입점
시스템 프록시
시스템 프록시는 운영체제의 프록시 주소를 클라이언트의 로컬 수신 포트로 지정합니다. 주로 해당 설정을 따르는 브라우저와 앱에 적용됩니다. v2rayN의 「시스템 프록시 자동 설정」을 켜도 모든 프로그램이 프록시를 사용하는 것은 아니며, 트래픽의 최종 경로도 결정되지 않습니다. 로컬 포트를 직접 변경했다면 시스템 프록시 주소도 함께 확인하세요. 그렇지 않으면 프로그램이 이전 포트로 계속 요청을 보낼 수 있습니다.
TUN 모드는 가상 네트워크 인터페이스로 트래픽을 받아 시스템 프록시 설정을 읽지 않는 일부 앱에도 적용할 수 있습니다. 실제 적용 범위는 라우팅 및 제외 설정에 따라 달라집니다. 관리자 권한이 필요할 수 있으며 DNS, 다른 VPN 소프트웨어, 가상 네트워크 어댑터 간 충돌도 확인해야 합니다. TUN은 트래픽 진입점일 뿐, 잘못된 노드 설정을 자동으로 수정하거나 모든 트래픽을 원격 출구로 보내지는 않습니다.
Mux는 여러 논리 연결을 더 적은 수의 하위 연결로 묶어 특정 상황에서 반복적인 연결 설정 비용을 줄이는 기능입니다. 효과는 코어, 프로토콜, 흐름 제어, 사용 유형에 따라 달라지므로 일반적인 속도 향상 기능으로 여겨서는 안 됩니다. Vision 같은 조합을 사용할 때는 특히 호환성을 먼저 확인하세요. 문제가 발생하면 여러 매개변수를 한꺼번에 바꾸기보다 원래 설정으로 되돌려 비교하는 편이 좋습니다.
실제 연결 지연 시간은 클라이언트가 프록시 경로를 통해 테스트 주소에 요청을 보내고, 지정한 단계가 완료될 때까지 걸린 시간을 측정한 값입니다. 서버 포트만 확인하는 테스트보다 실제 사용에 가깝지만 테스트 주소, DNS, 핸드셰이크, 현재 네트워크 상태에 영향을 받습니다. 값이 낮다고 대용량 파일 다운로드가 더 빠른 것은 아니며, 테스트 실패만으로 서버가 오프라인이라고 단정할 수도 없습니다. 로그를 함께 확인하세요.
라우팅은 트래픽이 어느 경로로 나갈지 정하고, DNS는 도메인을 해석합니다. 도메인 정보 유지 여부와 규칙 데이터의 사용 가능 여부에 따라 최종 매칭 결과가 달라집니다.
라우팅 및 DNS · 아웃바운드 선택
라우팅 규칙과 트래픽 분할
트래픽 분할은 도메인, 대상 IP, 포트 등의 조건에 따라 요청을 직접 연결, 프록시, 차단 중 하나로 보내는 방식입니다. 규칙은 보통 정해진 순서대로 적용되며, 범위가 넓은 규칙을 앞에 두면 뒤의 세부 규칙이 적용되지 않을 수 있습니다. 「중국 본토 우회」 같은 모드는 사전 설정된 정책 이름입니다. 문제를 해결할 때는 어떤 규칙에도 해당하지 않는 트래픽의 기본 경로와 DNS가 매칭에 필요한 정보를 제공하는지도 확인하세요.
프록시 설정에서 GeoIP는 일반적으로 라우팅 규칙에서 참조하는 IP 주소 모음을 뜻하며, 주소 분류에 따라 경로를 선택할 때 사용합니다. 분류 결과는 데이터 파일, 업데이트 시점, 태그 정의에 따라 달라지므로 실제 기기의 물리적 위치를 정확히 나타내지는 않습니다. 서비스가 동적 주소나 공유 인프라를 사용한다면 IP 분류만으로는 충분하지 않을 수 있으니 도메인 규칙과 실제 연결 기록도 함께 확인하세요.
GeoSite는 규칙에서 참조하는 도메인 모음으로, 서비스, 용도, 지역 등의 기준으로 분류할 수 있습니다. 실제 태그는 데이터 출처에 따라 달라집니다. 사용 전에 클라이언트에 호환되는 데이터 파일이 있는지, 현재 코어가 매칭 대상 도메인을 인식할 수 있는지 확인하세요. 앱이 IP 주소로 직접 연결하거나 도메인 정보가 없거나 새 도메인이 데이터에 포함되지 않았다면, 규칙이 적용되지 않아도 프록시 연결 자체의 문제는 아닐 수 있습니다.
FakeDNS는 먼저 앱에 가상 IP를 반환하고, 이후 코어가 매핑 정보로 도메인을 복원해 트래픽을 처리합니다. TUN과 함께 사용하는 설정에서 자주 볼 수 있습니다. 공용 DNS 서버 주소가 아니며 모든 DNS 해석 방식을 자동으로 대체하지도 않습니다. 클라이언트를 종료한 뒤 앱이나 시스템에 가상 주소 캐시가 남으면 접속에 영향을 줄 수 있으므로, 비활성화할 때 관련 캐시와 트래픽 처리 상태를 확인하세요.
구독은 설정을 배포하는 방식이고, 노드는 하나의 연결 설정입니다. 가져오기에 성공했다는 것은 내용을 파싱했다는 뜻일 뿐, 인증 정보가 유효하거나 연결이 완료됐다는 의미는 아닙니다.
구독 및 노드 · 설정 배포
구독
구독은 보통 여러 서버 설정을 가져오는 주소입니다. 클라이언트에서 구독을 업데이트하면 내용을 파싱해 해당 그룹을 갱신합니다. 구독 내용에 따라 기존 항목이 변경되거나 삭제될 수 있으며, 직접 수정한 설정의 유지 여부는 클라이언트 관리 방식에 따라 다릅니다. 주소에 접근 자격 증명이 포함될 수 있으므로 비밀번호처럼 안전하게 보관하세요. 문제 해결을 위해 자료를 공유할 때 전체 구독 주소를 그대로 보내지 마세요.
노드는 클라이언트에서 선택할 수 있는 서버 연결 설정 하나로, 일반적으로 주소, 포트, 프로토콜, 인증 정보, 전송 방식, 보안 계층 매개변수를 포함합니다. 목록에 표시되는 이름은 메모일 뿐 실제 물리적 위치나 출구 위치를 보장하지 않습니다. 노드를 바꿔도 시스템 프록시가 자동으로 켜지지는 않습니다. 노드 선택, 코어 실행, 앱의 웹 접속은 서로 다른 상태입니다.
공유 링크는 특정 URI 형식으로 연결 매개변수를 담습니다. 예를 들면 vmess://, vless://, ss://로 시작하는 형식이 흔합니다. 클라이언트마다 확장 필드 인식 방식이 다를 수 있으므로 가져온 뒤 전송 방식, 보안 계층, 서버 이름이 제대로 들어왔는지 확인하세요. 링크에 비밀번호나 사용자 ID가 포함될 수 있으니 스크린샷, 로그 복사, 질문글을 공유하기 전에 인증 정보를 삭제하세요.
지연 시간은 특정 테스트에 걸리는 시간을 뜻합니다. ICMP 왕복 시간, TCP 연결 시간, 프록시 요청 시간은 서로 다른 측정값입니다. 노드를 비교할 때는 같은 테스트 방식과 대상, 비슷한 시간 조건을 사용해야 결과를 비교할 수 있습니다. 서버가 특정 테스트에 응답하지 않는다고 실제 서비스 연결까지 반드시 실패하는 것은 아닙니다. 지연 시간이 짧아도 대역폭이 더 크거나 장시간 연결이 더 안정적이라고 단정할 수 없습니다.
보안 계층, 서버 이름, DNS 해석 경로는 각각 따로 확인해야 합니다. 특정 옵션이 켜져 있다는 사실만으로 연결 전체가 의도대로 작동한다고 볼 수는 없습니다.
암호화 및 보안 계층 · 연결 보호
TLS
TLS는 연결 암호화와 인증에 사용하는 전송 계층 보안 프로토콜로, 다양한 프록시 프로토콜 및 전송 방식과 함께 사용됩니다. 설정할 때 인증서의 유효성, 서버 이름 일치 여부, 시스템 시간이 정확한지 확인하세요. 「인증서 검증 건너뛰기」는 인증 수준을 낮춥니다. 핸드셰이크 오류가 발생하면 검증을 건너뛰는 방법을 장기 해결책으로 삼기보다 인증서와 이름 설정부터 확인하세요.
REALITY는 Xray 생태계의 전송 계층 보안 방식으로 VLESS와 함께 사용하는 경우가 많습니다. VLESS와 완전히 같은 계층의 대체 프로토콜로 취급해서는 안 됩니다. 클라이언트에서 서버 설정에 맞춰 SNI, PublicKey, ShortId, 필요한 경우 Fingerprint 등의 필드를 확인해야 합니다. Fingerprint는 클라이언트 핸드셰이크 특성을 나타냅니다. 필드가 모두 입력됐더라도 값이 올바르다는 보장은 없으며, 예시 공개 키나 임의로 입력한 서버 이름으로 실제 연결할 수는 없습니다.
SNI는 TLS 핸드셰이크에서 대상 서버 이름을 나타내는 확장 기능입니다. 클라이언트 화면에는 「서버 이름」 또는 serverName으로 표시될 수 있습니다. 연결 주소와는 별도 필드입니다. 연결 주소는 서버를 찾는 데 사용되고, 이름 매개변수는 해당 핸드셰이크 및 인증 과정에 사용됩니다. 두 값이 다르다고 반드시 잘못된 것은 아니지만 임의로 바꾸면 안 됩니다. 서버 요구사항을 따르고 인증서 또는 REALITY 매개변수와의 일치 여부를 확인하세요.
DNS 누출은 도메인 조회가 의도한 해석 경로를 벗어나는 현상을 말합니다. 예를 들어 지정한 출구를 통해 해석하려 했지만 시스템 기본 DNS 서버가 처리하는 경우입니다. 판단할 때는 브라우저의 보안 DNS, 시스템 DNS, 클라이언트 DNS, 라우팅 설정을 모두 확인해야 합니다. 웹 트래픽의 출구 주소만으로는 알 수 없습니다. 규칙에 따라 직접 연결하는 조회는 반드시 누출이 아닙니다. 실제 해석 경로가 미리 정한 정책에 맞는지가 핵심입니다.