레퍼런스 / 용어와 필드
연결 프로토콜부터 설정 필드까지 6개 범주로 살펴봅니다. 먼저 클라이언트, 코어, 프로토콜, 보안 계층을 구분한 뒤 필요한 설정을 찾아보세요. 이름이 비슷해도 필드를 서로 바꿔 쓸 수 있는 것은 아닙니다.
01 / PROTOCOL & TRANSPORT
프로토콜은 프록시 요청과 인증 형식을 정하고, 전송 방식은 데이터를 전달하는 방법을 정합니다. 서로 다른 옵션입니다.
VMess는 Project V 생태계의 프록시 프로토콜로, 사용자 식별자 등의 매개변수로 인증하며 프로토콜 자체의 데이터 보호 기능도 갖추고 있습니다. 가져올 때는 사용자 ID, 서버 포트, 전송 설정을 확인하세요. 주소가 같은지만 확인해서는 충분하지 않습니다.
오래된 설정에는 과거 인증 방식과 관련된 옵션이 있을 수 있습니다. 예전 예시에 맞추려고 매개변수를 임의로 바꾸지 말고, 먼저 서버 설정과 현재 코어의 호환 요건을 확인하세요.
VLESS는 UUID로 사용자를 식별하는 경량 프록시 프로토콜이며, 프로토콜 자체는 페이로드를 암호화하지 않습니다. 실제 연결이 전송 보호를 받는지는 TLS·REALITY 등의 보안 계층과 전체 구성 방식에 따라 달라집니다.
설정의 encryption, flow, 전송 보안 항목은 각각 역할이 다릅니다. 특히 flow는 서버와 코어가 함께 지원해야 하므로 범용 옵션처럼 임의로 활성화하면 안 됩니다.
Trojan은 보통 TLS와 함께 사용하는 프록시 프로토콜이며, 인증에는 VMess·VLESS의 사용자 ID가 아닌 비밀번호를 주로 사용합니다. 노드를 가져온 뒤 비밀번호, 대상 포트, 서버 이름, 전송 설정을 함께 확인하세요.
프로토콜이 서로 다른 경우 주소와 포트가 같더라도 인증 형식은 다릅니다. 프로토콜 드롭다운을 Trojan으로 바꾸는 것만으로는 프로토콜을 제대로 전환할 수 없습니다.
전송 방식은 프록시 데이터를 네트워크 연결에 실어 보내는 방법을 정의합니다. 일반적인 설정에는 TCP, WebSocket, gRPC 등이 있습니다. 경로, Host, 서비스 이름은 각 전송 방식의 매개변수이므로 다른 유형의 설정을 그대로 가져다 쓰면 안 됩니다.
클라이언트에 표시되는 이름과 JSON 값은 버전에 따라 달라질 수 있습니다. 설정을 확인할 때는 streamSettings.network와 해당 유형의 설정 객체를 함께 살펴보고 양쪽의 호환 여부를 확인하세요.
02 / CORE & CLIENT
GUI는 설정 관리를 담당하고 코어는 연결을 처리합니다. 특정 링크를 가져올 수 있다고 해서 실행 중인 코어가 모든 필드를 지원한다는 뜻은 아닙니다.
Xray는 Xray 프로젝트에서 관리하는 프록시 코어로, 프로토콜 처리, 라우팅 선택, 도메인 해석 등을 담당합니다. REALITY 같은 기능은 Xray 생태계의 기능이지만, 사용 가능 여부는 실제 코어 버전과 매개변수 조합에 따라 달라집니다.
연결 문제를 해결할 때는 클라이언트 버전과 코어 버전을 따로 확인해야 합니다. GUI를 업데이트한 뒤에도 클라이언트 정보나 로그에서 실제 실행 중인 코어를 확인하세요.
V2Fly는 V2Ray 개발을 이어가는 커뮤니티 프로젝트로, v2ray-core를 관리합니다. Xray와 생태계를 공유하지만, 이후 추가된 프로토콜 확장과 설정 형식, 필드 지원은 완전히 같지 않습니다.
한 코어에서 다른 코어로 설정을 옮길 때는 항목별 지원 여부를 확인해야 합니다. 파일 이름이 똑같이 config.json이라고 해서 내용을 그대로 함께 사용할 수 있는 것은 아닙니다.
GUI 클라이언트는 노드 관리, 구독 가져오기, 라우팅 편집, 연결 제어 화면을 제공합니다. v2rayN은 데스크톱용이며, v2rayNG와 v2flyNG는 Android용입니다. v2flyNG는 V2Fly 코어를 사용하려는 경우 선택할 수 있습니다.
클라이언트는 GUI 옵션을 바탕으로 실행 설정을 생성할 수 있으므로, 생성된 파일을 직접 수정하면 다음 실행 때 변경 사항이 덮어써질 수 있습니다. 클라이언트에서 지원하는 설정 메뉴나 사용자 지정 설정 기능을 우선 사용하세요.
TUN 모드는 가상 네트워크 인터페이스를 통해 트래픽을 받아들입니다. 일반적으로 시스템 프록시만 설정하는 것보다 더 많은 앱에 적용되지만, 범위는 시스템 라우팅, 권한, 클라이언트 구현에 따라 달라집니다. 시스템 프록시는 관련 프록시 설정을 따르는 앱에 주로 영향을 주므로 두 방식은 같지 않습니다.
TUN을 활성화한 뒤에도 DNS와 제외 규칙을 확인해야 합니다. 인터넷 연결이 끊기면 노드만 반복해서 바꾸지 말고 가상 인터페이스 상태와 라우팅 변경을 함께 살펴보세요.
03 / CONFIG STRUCTURE
데이터 흐름에 따라 JSON을 이해하면 됩니다. 인바운드는 요청을 받고, 라우팅은 경로를 선택하며, 아웃바운드는 연결을 시작하고, 정책은 연결 동작을 제어합니다.
inbounds는 인바운드 배열로, 코어가 어디에서 트래픽을 받을지 정의합니다. 흔히 사용하는 로컬 SOCKS 인바운드에는 listen, port, protocol, settings를 설정합니다.
127.0.0.1은 보통 로컬 기기에서만 접속할 수 있습니다. 수신 범위를 변경할 때는 인증, 방화벽, 실제 사용 목적도 고려하세요. 인바운드 포트는 앱이 로컬 프록시에 연결하는 포트이며 원격 서버 포트가 아닙니다.
outbounds는 아웃바운드 배열로, 연결을 내보내는 방식을 정의합니다. 프록시, 직접 연결, 차단 아웃바운드 등을 포함할 수 있습니다. 각 아웃바운드의 tag는 라우팅 규칙에서 참조하는 식별자로 사용할 수 있습니다.
예를 들어 규칙의 outboundTag를 direct로 지정하려면 해당 tag가 붙은 아웃바운드가 있어야 합니다. 이 이름은 사용자가 정하는 식별자일 뿐, 직접 연결 동작을 자동으로 만들지는 않습니다.
streamSettings는 전송 방식과 보안 계층을 설정하며, 주로 프록시 아웃바운드에 사용됩니다. network에서 전송 유형을, security에서 적용할 보안 방식을 선택하고 나머지 객체에는 각 방식에 필요한 매개변수를 입력합니다.
이 객체만 복사해서는 노드 전체를 구성할 수 없습니다. 인증 정보와 서버 주소는 보통 프로토콜의 settings에 들어갑니다. 필드 이름과 사용 가능한 조합은 현재 코어 문서를 기준으로 확인하세요.
policy는 코어의 연결 정책 설정으로, 사용자 수준 등에 따라 핸드셰이크 시간 초과, 연결 유휴 시간, 통계 동작을 지정할 수 있습니다. 여기서 말하는 정책은 특정 사이트를 특정 아웃바운드로 보내는 분기 규칙이 아닙니다.
연결이 자주 끊기면 시간 초과 설정을 확인할 수 있지만, 모든 값을 무조건 늘리는 것은 바람직하지 않습니다. 먼저 로그에서 핸드셰이크, 전송, 유휴 상태 중 어느 단계에서 끊기는지 확인한 뒤 관련 필드를 수정하세요.
04 / ROUTING & DNS
라우팅은 연결 경로를 정하고, DNS 해석은 도메인에 대응하는 주소를 찾습니다. 트래픽 분기 결과를 확인할 때는 두 경로를 함께 살펴봐야 합니다.
라우팅 규칙은 도메인, IP, 포트, 인바운드 tag 등의 조건으로 아웃바운드를 선택합니다. 이를 보통 트래픽 분기라고 합니다. 규칙은 대체로 위에서부터 검사하고 처음 일치한 규칙이 연결 경로를 결정하므로, 구체적인 규칙을 포괄적인 규칙보다 먼저 배치해야 합니다.
일반적으로 한 규칙 안의 서로 다른 조건 필드는 모두 충족해야 하며, 같은 필드에 여러 값이 있으면 그중 하나와 일치하면 됩니다. 어떤 규칙에도 맞지 않을 때의 기본 동작도 명확히 설정하거나 확인해야 합니다. 규칙이 적용되는 경우만 살펴봐서는 안 됩니다.
라우팅 규칙 보기 →GeoIP는 IP 주소 집합을 기준으로 라우팅을 매칭하는 데이터 분류 방식입니다. 흔히 geoip:private처럼 씁니다. 실제 주소 집합은 사용 중인 데이터 파일에 따라 달라지며, 이 태그가 실시간 위치 조회를 수행하는 것은 아닙니다.
대상이 처음부터 도메인으로 지정된 경우 IP 규칙 매칭이 가능한지는 DNS 해석 정책에도 영향을 받습니다. 데이터베이스나 도메인 해석 결과가 바뀌면 같은 규칙의 매칭 결과도 달라질 수 있습니다.
GeoSite는 도메인 집합을 기준으로 매칭하는 데이터 분류 방식으로, geosite:cn처럼 씁니다. GeoIP와의 차이는 매칭 대상입니다. GeoSite는 도메인을, GeoIP는 IP 주소 집합을 기준으로 합니다.
태그가 있는지와 어떤 도메인을 포함하는지는 데이터 출처와 버전에 따라 달라집니다. 사용 전에 클라이언트가 불러온 데이터 파일을 확인하세요. 특정 사이트를 따로 처리해야 한다면 전체 분류에 의존하지 말고 더 구체적인 도메인 규칙을 사용할 수 있습니다.
DNS는 도메인을 주소로 해석하고, routing.domainStrategy는 라우팅 매칭 중 언제 도메인 해석을 시도할지 정합니다. 예를 들어 IPIfNonMatch는 도메인 규칙에 일치하지 않을 때 DNS 해석 결과를 이용해 IP 규칙을 추가로 확인합니다.
이 필드가 모든 앱에서 코어 DNS를 사용하게 한다는 뜻은 아닙니다. 시스템, 브라우저, 프록시 코어가 각각 DNS 조회를 수행할 수 있으며, 아웃바운드에 있는 이름이 같거나 비슷한 필드도 위치에 따라 따로 이해해야 합니다.
DNS 설정 보기 →FakeDNS는 가상 주소와 도메인 간 매핑을 만들어 이후 연결에서 대상 도메인 정보를 복원합니다. 여기서 사용하는 주소는 내부 매핑을 위한 것이며 대상 사이트의 실제 공인 IP 주소가 아닙니다.
FakeDNS가 작동하려면 DNS 조회 경로, 트래픽 가로채기, 도메인 복원 등이 함께 연결되어야 합니다. 설정 객체 하나만 추가한다고 반드시 적용되는 것은 아닙니다. 모드를 바꾼 뒤에도 이전 DNS 캐시가 사용된다면 캐시와 실제 트래픽 경로를 함께 확인하세요.
DNS 누출은 조회가 예상한 경로를 따르지 않고 다른 리졸버에서 처리되는 현상입니다. 이는 조회 경로가 벗어났다는 뜻이지, 리졸버의 이름이나 위치만으로 판단할 수 있는 문제는 아닙니다.
문제를 확인할 때는 시스템 DNS, 브라우저의 암호화 DNS, 클라이언트의 트래픽 처리 방식, 코어의 DNS 아웃바운드를 각각 살펴보세요. 웹 요청이 프록시를 거치더라도 요청 전에 수행된 도메인 조회까지 같은 경로를 이용한다는 보장은 없습니다.
05 / SUBSCRIPTION & NODE
구독은 매개변수 목록을 관리하고, 노드는 연결 설정을 저장합니다. 가져오기 성공 여부와 연결 성공 여부는 별도로 확인해야 합니다.
구독은 주소 하나를 통해 노드 목록을 가져오고 업데이트하는 관리 방식이지 프록시 프로토콜 자체가 아닙니다. 내용을 사용할 수 있는 노드 항목으로 변환하려면 클라이언트가 해당 구독 형식을 지원해야 합니다.
업데이트하면 보통 원격 콘텐츠를 다시 가져옵니다. 직접 수정한 노드 매개변수가 유지되는지는 클라이언트에 따라 다릅니다. 구독 주소에 접근 자격 증명이 포함될 수 있으므로 스크린샷, 공개 로그, 공유 문서에 노출되지 않도록 주의하세요.
노드는 클라이언트에 저장된 연결 매개변수 묶음으로, 보통 서버 주소, 포트, 프록시 프로토콜, 인증 정보, 전송 설정을 포함합니다. 노드 항목 하나가 독립된 물리 서버 한 대를 뜻하는 것은 아니며, 표시 이름은 프로토콜 인증에 사용되지 않습니다.
주소가 해석된다는 것은 DNS 조회가 성공했다는 뜻일 뿐입니다. 연결하려면 포트에 접근할 수 있어야 하고, 인증 정보가 올바르며, 전송 및 보안 계층 매개변수도 서로 호환되어야 합니다.
공유 링크는 노드 매개변수를 가져오기 쉬운 텍스트로 인코딩한 것이며, QR 코드는 그 텍스트나 구독 주소를 담는 형식입니다. QR 코드로 가져와도 별도의 연결 프로토콜을 쓰는 것은 아니며, 최종적으로 클라이언트 설정으로 변환됩니다.
클라이언트마다 링크의 확장 필드를 인식하는 범위가 다를 수 있습니다. 가져온 뒤 전송, 보안 계층, 서버 이름을 확인하세요. QR 코드에 인증 정보가 포함될 수 있으므로 공유 전에 내용과 공유 대상 범위를 확인해야 합니다.
실측 지연 시간은 보통 클라이언트가 프록시 경로를 통해 테스트 대상에 접속할 때 걸리는 시간을 의미합니다. DNS 조회, 핸드셰이크, 응답 대기 시간을 포함하는지는 클라이언트 구현에 따라 다릅니다. 포트 연결만 확인하는 TCP 지연 시간과는 다른 지표입니다.
결과를 비교할 때는 테스트 대상과 방식을 동일하게 유지하세요. 지연 시간이 짧다고 다운로드 속도도 빠른 것은 아니며, 테스트 시간 초과는 대상 사이트나 DNS 조회 과정에서 발생할 수도 있습니다.
06 / SECURITY LAYER
인증 식별자, 인증서 검증, 전송 보호는 각각 다른 문제를 해결합니다. 핸드셰이크 오류가 발생하면 먼저 어느 계층의 문제인지 확인하세요.
TLS는 전송 연결을 암호화하고 신원을 인증합니다. 인증서 검증에는 신뢰 체인, 유효 기간, 시스템 시간, 도메인 일치 여부가 영향을 줍니다. 서버 주소에 접속할 수 있다고 해서 인증서가 클라이언트의 검증 요건을 충족하는 것은 아닙니다.
인증서 오류가 발생하면 먼저 시스템 시간, 서버 이름, 인증서 배포 상태를 확인하세요. allowInsecure를 활성화하면 인증서 검증이 완화되므로 모든 TLS 오류에 대한 기본 해결책으로 사용해서는 안 됩니다.
REALITY는 Xray 생태계의 전송 보안 메커니즘으로, VLESS 같은 프로토콜과 함께 사용하는 경우가 많습니다. VLESS와 같은 계층의 프록시 프로토콜은 아닙니다. 양쪽 코어가 지원해야 하며 인증 및 핸드셰이크 매개변수도 서로 맞아야 합니다.
클라이언트에는 보통 서버 이름, 공개 키 또는 관련 검증 매개변수, 짧은 ID 등이 필요하며 실제 필드 이름은 버전에 따라 달라질 수 있습니다. 서버의 개인 키를 클라이언트에 입력하지 말고, 일반 TLS 설정을 REALITY 설정과 동일하게 취급하지 마세요.
SNI는 TLS 핸드셰이크에서 서버 이름을 전달하는 기능이고, serverName은 해당 이름 및 인증서 검증과 관련된 클라이언트 설정 필드입니다. 실제 연결에 사용하는 address는 IP 주소여도 서버 이름은 도메인으로 지정할 수 있습니다.
두 필드가 항상 같아야 하는 것은 아니지만 서버 구성 요건에 맞아야 합니다. 서버 이름은 WebSocket의 Host나 HTTP 요청 헤더와도 다릅니다. 한 항목을 수정해도 나머지 항목이 자동으로 바뀌지는 않습니다.
UUID는 VMess·VLESS 등의 프로토콜에서 사용하는 사용자 식별자입니다. 클라이언트에 입력하는 값은 서버의 인증 항목과 일치해야 합니다. UUID는 사용자 식별용이며 전송 암호화 알고리즘이 아니고, TLS나 REALITY 매개변수를 대신할 수도 없습니다.
형식이 올바르다는 것은 문법에 맞는 값이라는 뜻일 뿐, 서버에서 인증을 허용한다는 뜻은 아닙니다. UUID를 새로 생성했다면 양쪽 설정을 모두 업데이트해야 합니다. 공개 노드의 스크린샷을 공유할 때는 사용자 식별자와 기타 인증 정보를 가리세요.