CONFIGURATION LAYERS
먼저 설정이 어느 계층에 속하는지 확인한 뒤 해당 메뉴를 수정하세요. 클라이언트의 구독 관리, 시스템 프록시 설정, 코어 구성은 각각 역할이 다릅니다. '연결됨' 표시만으로 전체 연결 경로를 확인했다고 볼 수는 없습니다.
인바운드는 클라이언트가 연결을 받아들이는 지점을 정합니다. 일반적으로 기기에서 SOCKS 또는 HTTP 포트를 열고, 앱이나 시스템 프록시가 해당 포트를 사용하도록 설정합니다. 서버를 가져왔다고 해서 앱이 자동으로 프록시를 사용하는 것은 아닙니다. 문제가 생기면 수신 주소와 포트, 앱의 프록시 설정이 일치하는지 먼저 확인하세요. 기기 내에서만 사용할 때는 보통 루프백 주소에 바인딩합니다. 로컬 네트워크에 공개한다면 접근 제어와 방화벽도 확인해야 합니다. 앱마다 주소를 입력하는 것보다 시스템 프록시를 설정하는 편이 간편하지만, 이를 따를지는 앱에 따라 다릅니다.
{
"inbounds": [
{
"tag": "local-socks",
"listen": "127.0.0.1",
"port": 10808,
"protocol": "socks",
"settings": { "udp": true }
}
]
}라우팅은 도메인, 주소 또는 인바운드 태그에 따라 트래픽을 매칭하고 지정된 아웃바운드로 전달합니다. 규칙은 보통 순서대로 확인하므로 구체적인 조건을 포괄적인 조건보다 앞에 두세요. 먼저 직접 연결과 프록시의 기본 범위를 정한 뒤 내부 네트워크, 특정 도메인, 앱 관련 조건을 추가하는 편이 알 수 없는 규칙을 한꺼번에 가져오는 것보다 문제를 찾기 쉽습니다. 전역 모드만 전환하는 방식과 달리 규칙 기반 분할 라우팅은 로컬 네트워크 경로를 유지할 수 있습니다. 아래 예시는 규칙 일부만 보여줍니다. 참조하는 아웃바운드 태그가 실제 설정에 있어야 하며, 도메인 매칭에는 사용할 수 있는 도메인 정보가 필요합니다.
{
"routing": {
"rules": [
{
"type": "field",
"domain": ["domain:example.com"],
"outboundTag": "direct"
}
]
}
}DNS는 도메인을 IP 주소로 변환하지만, 앱·운영체제·프록시 코어가 각각 조회를 요청할 수 있습니다. 연결에 실패하면 서버 주소만 바꾸지 말고 누가 조회하는지, 조회 요청이 어떤 경로를 거치는지 확인하세요. 특정 요청에 코어의 DNS 설정이 적용되는지는 인바운드·라우팅·아웃바운드 구성에 따라 달라집니다. 시스템 DNS만 바꾸는 것과 달리 코어 설정을 사용하면 분할 라우팅에 맞춰 일부 조회 동작을 제어할 수 있지만, 모든 앱에 자동 적용되지는 않습니다. 아래 예시에는 실제 설정 키가 포함되어 있습니다. 리졸버 연결 가능 여부, 암호화 방식, 부트스트랩 조회도 별도로 확인해야 합니다.
{
"dns": {
"servers": ["1.1.1.1", "8.8.8.8"]
}
}아웃바운드는 코어에서 연결이 나가는 방식을 정의합니다. 프록시 서버를 사용할 수도 있고, 직접 연결하거나 차단할 수도 있습니다. 서버의 프로토콜·전송 방식·보안 매개변수는 서로 맞아야 합니다. 주소와 포트가 같다고 설정도 동일한 것은 아닙니다. GUI 클라이언트는 보통 서버 정보를 바탕으로 프록시 아웃바운드를 만들고, 라우팅은 태그를 사용해 이를 참조합니다. 설정 전체를 직접 편집하기보다 클라이언트가 지원하는 가져오기 메뉴를 이용하면 관련 필드를 유지하기 쉽습니다. 아래에는 직접 연결 아웃바운드 예시만 있으며 원격 접속 정보는 포함되지 않습니다. 구독을 대신할 수 있는 서버 설정도 아닙니다. 태그를 바꿀 때는 라우팅에서 참조하는 태그도 함께 확인하세요.
{
"outbounds": [
{
"tag": "direct",
"protocol": "freedom",
"settings": {}
}
]
}구독은 클라이언트가 서버 정보를 일괄로 가져오는 관리 방식이며, 코어의 최상위 설정 키가 아닙니다. 먼저 출처별로 그룹을 만들고 구독 주소를 입력해 업데이트한 뒤, 서버 정보가 표시되는지와 프로토콜을 정상적으로 읽는지 확인하세요. 공유 링크를 하나씩 붙여 넣는 것보다 구독을 사용하면 서버 변경 사항을 관리하기 편하지만, 직접 수정한 내용은 다음 업데이트 때 덮어써질 수 있습니다. 여러 출처를 사용한다면 그룹별 용도를 분명히 하고, 개인 식별 정보가 포함된 주소를 스크린샷이나 공개 로그에 노출하지 마세요. 아래 키는 생성된 코어 설정에 속하며 구독 자체의 필드는 아닙니다.
{
"log": { "loglevel": "warning" },
"inbounds": [],
"outbounds": []
}설정 예시는 구조를 파악하기 위한 것으로, 전체 연결 설정이 아닙니다. 실제로 실행하려면 유효한 서버 정보와 서로 일치하는 태그가 필요합니다. 코어마다 지원하는 필드와 프로토콜 기능이 다를 수 있으므로 수정 전에 클라이언트에서 현재 선택된 코어를 확인하세요. 정상 작동하는 설정을 먼저 저장하고, 한 번에 한 계층씩 변경한 뒤 같은 앱과 대상 주소로 결과를 확인하는 것이 좋습니다. 구독 업데이트로 설정이 다시 생성된다면 임시 생성 파일을 직접 수정하지 말고 클라이언트의 규칙 또는 사용자 지정 설정 메뉴를 이용하세요.
CLIENT SHELF
데스크톱에서는 주로 v2rayN을 사용하고, Android에서는 먼저 v2rayNG를 살펴보세요. V2Fly 코어 기능이 필요하다면 v2flyNG도 고려할 수 있습니다. 운영체제를 고른 다음 CPU 아키텍처와 설치 파일 형식을 확인하세요. 이름이 비슷해도 설치 파일을 서로 바꿔 쓸 수 있는 것은 아닙니다.
v2rayN을 선택하세요. 다운로드 페이지에서 크로스 플랫폼 인터페이스 버전과 클래식 인터페이스를 유지한 WPF 버전을 구분해 제공합니다. 두 버전 모두 서버·구독·라우팅 관리에 사용할 수 있습니다. 처음 설치할 때는 시스템 요구 사항에 맞는 버전 하나를 선택하면 됩니다. 같은 구독을 가져오기 위해 두 클라이언트를 함께 실행할 필요는 없습니다.
설치 후 로컬 프록시 포트를 확인하고 시스템 프록시를 설정하세요. 앱이 시스템 프록시를 따르지 않는다면 앱에서 프록시를 직접 설정하거나 TUN 모드를 살펴볼 수 있습니다. 두 클라이언트가 동시에 시스템 설정을 제어하면 포트 충돌이나 프록시 경로 혼선이 생길 수 있습니다. 문제를 확인할 때는 한 가지 실행 환경만 남겨두세요.
v2rayN 데스크톱 클라이언트를 선택할 때는 컴퓨터 칩에 따라 Apple Silicon 또는 Intel 설치 파일을 고르세요. macOS의 '이 Mac에 관하여'에서 칩이나 프로세서 정보를 확인할 수 있습니다. 여러 번 설치해 보며 확인할 필요는 없습니다.
처음 실행할 때 시스템 권한 안내를 확인하고 네트워크 프록시가 클라이언트의 수신 포트를 가리키는지 살펴보세요. 클라이언트를 종료한 뒤에도 네트워크 접속이 되지 않는다면 시스템 프록시 설정이 남아 있는지 먼저 확인하세요. TUN은 트래픽을 더 깊은 계층에서 처리합니다. 사용 전 권한과 라우팅 안내를 읽고, 모든 연결 문제를 해결하는 만능 스위치로 여기지 마세요.
먼저 Xray 코어를 사용하는 v2rayNG를 고려하세요. 기존 설정이 V2Fly 기능에 의존한다면 v2flyNG를 확인할 수 있습니다. 다운로드 페이지에서 arm64와 범용 버전을 각각 제공합니다. 최신 주류 기기는 보통 arm64를 사용하지만, 아키텍처를 모른다면 기기 정보를 확인하고 각 패키지의 요구 사항을 살펴보세요.
처음 연결할 때는 시스템 VPN 권한을 허용해야 합니다. 앱별 설정은 어떤 앱의 트래픽을 프록시로 보낼지 결정하며, 서버 라우팅 규칙과는 다른 계층입니다. 백그라운드에서 연결이 끊긴다면 시스템의 배터리 관리와 백그라운드 실행 제한을 확인하세요. VPN 연결을 사용하는 다른 앱이 트래픽 처리 자리를 차지하고 있는지도 살펴본 뒤 클라이언트 설정을 조정할지 판단하세요.
v2rayN을 선택한 뒤 배포판의 패키지 형식에 따라 deb 또는 rpm을 고르고, x64 또는 arm64 아키텍처도 확인하세요. 여기서는 GUI 클라이언트를 제공합니다. 실제 실행 가능 여부는 데스크톱 환경과 실행 종속성, 패키지 요구 사항에 따라 달라지므로 배포판 이름만으로 판단하지 마세요.
데스크톱 환경과 앱마다 프록시 설정을 읽는 방식이 다를 수 있습니다. 먼저 프록시 주소를 직접 입력할 수 있는 앱으로 로컬 포트를 확인한 다음, 데스크톱 환경의 시스템 프록시를 점검하세요. TUN을 사용하려면 권한과 라우팅을 별도로 설정하고, 네트워크 인터페이스를 변경하는 도구를 여러 개 동시에 실행하지 마세요. 업데이트 전에 구독 그룹과 사용자 지정 규칙을 저장해 두면 동작이 달라졌을 때 확인하기 쉽습니다.
클라이언트는 설정을 실행하고 관리할 뿐, 설치 파일에 서버 주소나 계정, 구독이 포함되어 있지는 않습니다. 공유 링크가 있다면 해당 프로토콜과 전송 방식을 확인하세요. 구독 주소가 있다면 클라이언트가 응답 형식을 인식하는지 살펴보세요. 웹페이지 주소를 구독 주소로 착각하거나 단일 공유 링크를 구독 업데이트 메뉴에 입력하면 목록이 비어 있을 수 있습니다. 가져오기에 실패했다면 반복해서 재설치하기보다 입력한 내용의 유형과 주소가 완전한지 먼저 확인하세요.
설치 후에는 두 단계로 확인하세요. 먼저 클라이언트가 서버 설정을 읽고 코어를 실행하는지 확인한 다음, 대상 앱의 요청이 실제로 예상한 경로를 통과하는지 확인합니다. 서버 목록이나 연결 스위치, 한 번의 테스트 결과만으로 모든 앱이 같은 출구를 사용한다고 단정할 수는 없습니다. 구독·서버 정보·로그가 포함된 스크린샷을 공유할 때는 주소의 개인 식별 정보와 인증 정보를 가리세요. 오류 유형과 설정 이름만 남기면 됩니다.
PROJECT V ECOSYSTEM
프로젝트, 코어, 클라이언트, 서버 설정을 구분하면 기능이 어디에서 비롯되는지 파악하고 문제 범위를 좁히기 쉽습니다. 이름이 비슷하다고 설정 기능까지 같은 것은 아닙니다.
PROJECT / CORE / CLIENT
Project V는 프록시 통신을 위한 도구와 구성 요소를 제공하며, V2Ray는 이 생태계에서 널리 사용되는 이름입니다. 실제로는 모든 실행 매개변수를 직접 편집하기보다 GUI 클라이언트에서 서버를 가져오고 코어를 실행하며 프록시 설정을 관리하는 경우가 많습니다. 코어는 프로토콜·전송·라우팅 로직을 처리하고, GUI 클라이언트는 자주 사용하는 작업을 인터페이스로 제공합니다. 이 역할을 이해하면 인터페이스를 바꿔도 프로토콜 기능은 달라지지 않을 수 있지만, 코어를 바꾸면 설정이 받아들여지는 방식이 달라질 수 있는 이유를 알 수 있습니다.
일상적인 대화에서 'V2Ray 설정'은 서버 공유 링크, 클라이언트에 저장된 서버 정보, 코어가 읽는 JSON 파일을 가리킬 수 있습니다. 이들은 서로 바꿔 쓸 수 없습니다. 공유 링크는 보통 서버 하나를 설명하고, 구독은 여러 서버 정보를 배포하며, 코어 설정에는 로컬 인바운드와 라우팅도 포함됩니다. 문제를 살펴보기 전에 어떤 대상을 말하는지 확인하면 클라이언트의 구독 옵션을 코어 설정에 잘못 입력하는 일을 막을 수 있습니다.
V2Fly는 V2Ray 관련 코어의 커뮤니티 개발을 이어가고 있으며, Xray는 공통 기술 기반에서 자체 구현과 기능을 발전시켜 왔습니다. 일부 개념과 설정 방식은 공유하지만, 모든 필드와 프로토콜 조합, 전송 동작이 완전히 같다고 볼 수는 없습니다. 이름이나 인터페이스 모양만으로 판단하기보다 현재 서버 설정에 필요한 기능과 클라이언트에 실제로 통합된 코어를 기준으로 선택하세요.
예를 들어 서버의 프로토콜 이름이 같더라도 전송 계층, 보안 매개변수, 확장 기능에 따라 특정 코어의 지원이 필요할 수 있습니다. 설정을 읽지 못하거나 실행할 수 없다면 먼저 오류에 표시된 필드와 기능 이름을 확인한 다음 해당 설정의 지원 범위를 살펴보세요. 오류를 단순히 서버에 접속할 수 없는 문제로만 판단하면 코어가 설정을 받아들이기 전 단계에서 발생한 문제를 놓칠 수 있습니다.
v2rayN은 데스크톱에서 설정과 실행을 관리하는 도구로, 이 사이트에서 다루는 세 가지 데스크톱 운영체제를 지원합니다. 구체적인 기능은 배포 패키지와 코어 설정에 따라 달라집니다. v2rayNG는 Android 기기용이며, 이 사이트에서는 일반적인 사용 방법을 Xray 코어 기준으로 소개합니다. v2flyNG는 V2Fly 코어를 사용하는 대안입니다. 세 클라이언트는 모두 오픈소스이며 공개된 구현과 설정 동작을 바탕으로 기능을 살펴볼 수 있습니다. 서버 서비스가 아니며 사용 가능한 구독을 자동으로 만들지도 않습니다.
한 클라이언트에서 정상 작동하는 설정을 다른 클라이언트로 옮길 때도 가져오기 형식, 라우팅 규칙, 트래픽 처리 방식을 확인해야 합니다. 서버를 가져와도 시스템 프록시, 앱별 목록, 로컬 사용자 지정 규칙까지 함께 옮겨지지는 않습니다. 환경 전체를 한 번에 복사하기보다 서버 하나와 대상 앱 하나로 먼저 확인한 뒤 그룹과 분할 설정을 추가하면 차이를 찾기 쉽습니다. 자세한 클라이언트 선택은 클라이언트 비교를 참고하세요.
Project V 생태계의 프로젝트·코어·GUI 클라이언트는 서로 다른 오픈소스 라이선스를 사용할 수 있습니다. 예를 들어 V2Fly의 V2Ray 코어와 Xray 코어는 MPL 2.0을 따르며, GUI 클라이언트와 함께 제공되는 구성 요소는 각각의 라이선스 안내를 확인해야 합니다. 오픈소스 라이선스는 코드의 사용·수정·재배포 조건을 설명합니다. 구독 출처의 서비스 약관이나 서버의 실행 상태와는 별개입니다. 사용자는 인증 정보와 접근 권한, 서버 설정을 별도로 관리해야 합니다.
클라이언트 업데이트, 코어 업데이트, 구독 업데이트는 서로 다른 작업입니다. 클라이언트 업데이트는 인터페이스와 관리 방식에 영향을 줄 수 있고, 코어 업데이트는 설정 해석과 프로토콜 동작을 바꿀 수 있습니다. 구독 업데이트는 주로 서버 정보를 새로 고칩니다. 동작이 달라졌다면 먼저 어떤 종류의 업데이트가 있었는지 기록하고 이전에 저장한 설정과 비교하세요. 클라이언트·코어·DNS·규칙을 한꺼번에 바꾼 뒤 테스트하면 연결 경로가 달라진 원인을 찾기 어렵습니다.
FIELD NOTES
구독 입력부터 웹페이지 접속까지 문제가 발생한 단계에 맞는 문서를 찾아보세요. 가져오기 단계의 문제라면 링크와 형식을 먼저 확인하고, 클라이언트가 실행됐는데 접속할 수 없다면 시스템 프록시·라우팅·DNS를 점검하세요. 단계별 점검 목록을 활용하면 관련 없는 절차를 반복하지 않아도 됩니다.
프록시 연결은 됐지만 인터넷에 접속할 수 없는 경우, 시스템 프록시 상태와 로컬 포트, 라우팅 규칙, DNS 조회, 시간 동기화 순으로 확인해 문제 지점을 찾습니다.
글 읽기구독 링크 만료, 형식 비호환, 업데이트 요청에 프록시 미사용, 인증서 오류 등 구독이 작동하지 않는 주요 원인을 빈도순으로 살펴보고 단계별 점검 및 해결 방법을 안내합니다.
글 읽기v2rayN에서 구독 그룹을 설정하는 방법과 v2rayNG의 구독 메뉴 사용법을 각각 설명하고, Base64 구독과 단일 공유 링크, 클립보드 가져오기 형식의 차이를 안내합니다.
글 읽기