클라이언트는 설정을 시작하는 입구일 뿐입니다. 실제 사용 결과는 구독 업데이트, 트래픽을 넘겨받는 범위, 라우팅 규칙, DNS 조회 경로가 좌우합니다. 아래 네 항목은 실제 설정 순서에 맞춰 정리했습니다.
SUBSCRIPTION
구독 링크는 원격 설정 목록이라고 생각하면 됩니다. 링크를 클라이언트에 추가한 뒤 업데이트를 실행해야 노드가 현재 그룹에 들어옵니다. 이후 서버 측 내용이 바뀌면 구독을 다시 업데이트해야 하며, 클라이언트만 재시작해서는 목록이 자동으로 갱신되지 않습니다. 먼저 그룹이 활성화되어 있는지 확인한 다음 노드 하나를 선택해 연결을 테스트하는 것이 좋습니다.
VMess, VLESS 또는 Trojan 링크 하나를 수동으로 가져오는 방식은 임시 테스트에 적합하고, 장기간 사용하려면 구독 그룹으로 관리하는 편이 좋습니다. 그룹 이름은 정리용일 뿐 프로토콜 자체를 바꾸지 않습니다. 링크를 복사할 때는 전체 내용을 유지하고, 메신저에서 줄바꿈되거나 매개변수가 잘리지 않도록 주의하세요.
{
"remarks": "일상 연결",
"enabled": true,
"updateInterval": 24
}TRAFFIC INTAKE
시스템 프록시는 브라우저와 시스템 프록시 설정을 읽는 데스크톱 앱에 적합하고, 설정 경로가 짧아 문제를 추적하기도 쉽습니다. 노드에 연결한 뒤 시스템 프록시를 켜고 자주 사용하는 웹사이트에 접속해 확인하는 것이 데스크톱 환경의 가장 안정적인 시작점입니다. 일부 프로그램은 시스템 프록시 설정을 무시하므로 해당 트래픽은 클라이언트로 들어오지 않습니다.
TUN 모드는 가상 네트워크 인터페이스를 통해 더 넓은 범위의 애플리케이션 트래픽을 넘겨받으므로 여러 프로그램을 한꺼번에 처리해야 할 때 적합합니다. 일반적으로 관리자 권한, 라우팅 테이블, DNS 인계가 필요해 점검할 항목도 많습니다. 처음부터 여러 인계 방식을 동시에 켜지 말고, 먼저 일반 프록시가 작동하는지 확인한 뒤 TUN만 별도로 활성화하세요.
ROUTING
라우팅 규칙은 특정 트래픽을 직접 연결, 프록시 또는 차단 중 어디로 보낼지 결정합니다. 일반적으로 위에서 아래로 매칭하며 먼저 일치한 규칙을 실행하므로, 범위가 구체적인 규칙을 앞에 두고 포괄적인 규칙은 뒤에 배치해야 합니다. 수정하기 전에 클라이언트 기본 규칙을 보존하고, 사용자 도메인이나 네트워크 대역을 하나씩 추가하면 문제를 더 쉽게 추적할 수 있습니다.
domainStrategy는 도메인을 IP로 조회할지, 조회한다면 언제 수행할지를 결정하며, ‘강할수록 좋다’는 성능 옵션이 아닙니다. 일반적인 도메인 규칙에는 먼저 AsIs를 사용할 수 있습니다. 대상 IP를 기준으로 네트워크 대역을 매칭해야 할 때만 조회를 실행하는 전략을 선택하세요. 규칙을 바꾼 뒤에는 현재 연결을 재시작하고 직접 연결 대상과 프록시 대상를 각각 테스트해야 합니다.
{
"routing": {
"domainStrategy": "AsIs",
"rules": [
{
"type": "field",
"ip": ["geoip:private"],
"outboundTag": "direct"
}
]
}
}DNS
DNS의 역할은 도메인을 주소로 변환하는 것이지만, 조회가 어디에서 발생하고 결과가 어느 라우팅 경로에 사용되는지가 연결 결과에 직접 영향을 줍니다. 흔한 문제는 노드 자체의 장애가 아니라 시스템 DNS, 클라이언트 내장 DNS, TUN 인계가 동시에 작동하면서 같은 도메인이 서로 다른 조회 경로를 사용하는 경우입니다.
문제를 점검할 때는 먼저 구성을 단순화하세요. 명확한 DNS 설정 하나만 남기고 중복 인계를 끈 다음 시스템 캐시를 삭제하고 다시 연결합니다. 특정 도메인만 이상하다면 특수 라우팅 규칙에 매칭되었는지 확인하세요. 내장 DNS 분기를 사용할 때는 직접 연결 도메인과 프록시 도메인이 각각 해당 출구와 일치하는 조회 경로를 사용하도록 해야 규칙 판단과 최종 연결 대상이 어긋나지 않습니다.
{
"dns": {
"queryStrategy": "UseIP",
"servers": [
"localhost",
"1.1.1.1"
]
}
}데스크톱에서는 v2rayN을 우선 사용하고, Android에서는 v2rayNG와 v2flyNG 중에서 선택할 수 있습니다. 다운로드 페이지에서 프로세서 아키텍처와 설치 패키지 형식을 다시 구분해 안내합니다.
DESKTOP
Windows 데스크톱에서는 v2rayN을 사용합니다. 최신 데스크톱 UI는 새로 설치할 때 적합하고, 클래식 WPF 버전은 익숙한 메뉴 구성을 이어서 사용하려는 경우에 알맞습니다. 다운로드 페이지에서 시스템 아키텍처에 맞는 파일을 선택하고, 설치가 끝난 뒤 구독을 가져오세요. 처음 테스트할 때는 시스템 프록시를 먼저 활성화해 브라우저 연결을 확인한 다음 TUN과 사용자 지정 라우팅을 설정하는 것이 좋습니다.
다운로드 페이지로 이동DESKTOP
macOS에서는 v2rayN 데스크톱 버전을 사용합니다. 다운로드하기 전에 시스템 정보에서 프로세서 유형을 확인하세요. Apple 칩은 arm64, Intel 프로세서는 x64를 선택합니다. 처음 실행할 때는 시스템 안내에 따라 앱 권한을 허용하세요. 브라우저와 일반 데스크톱 프로그램만 필요하다면 시스템 프록시부터 시작하고, 더 많은 앱을 포함해야 할 때 TUN 권한과 라우팅 안내를 확인하세요.
다운로드 페이지로 이동MOBILE
Android에서는 v2rayNG를 우선 선택합니다. Xray 코어를 사용하며 구독, QR 코드, 라우팅, VPN 인계 기능을 제공합니다. V2Fly 코어가 필요하다면 v2flyNG를 선택할 수 있습니다. 대부분의 최신 기기에서는 arm64를 우선 사용하고, 아키텍처를 모를 때는 범용 버전을 사용하세요. 구독을 가져온 뒤 그룹을 먼저 업데이트하고 노드를 선택한 다음 시스템의 로컬 VPN 연결 생성을 허용합니다.
다운로드 페이지로 이동DESKTOP
Linux 데스크톱에서는 v2rayN을 사용하며, 배포판에 따라 deb 또는 rpm을 선택하고 x64와 arm64도 구분해야 합니다. 설치 후 UI는 실행되지만 시스템 트래픽에 변화가 없다면 데스크톱 환경이 프록시 설정을 적용했는지 먼저 확인한 뒤 권한과 TUN 설정을 점검하세요. 문제를 추적할 때는 그래픽 클라이언트, 시스템 프록시, 애플리케이션 자체 프록시를 세 계층으로 나누고 동시에 여러 항목을 바꾸지 마세요.
다운로드 페이지로 이동먼저 최소한으로 작동하는 설정을 만든 다음 TUN, DNS, 라우팅 규칙을 하나씩 추가하세요. 한 번에 변수 하나만 바꿔야 연결에 문제가 생겼을 때 어느 계층에서 발생했는지 알 수 있습니다.
전체 가이드 보기 →데스크톱 시스템에는 v2rayN을 설치하고, Android에는 v2rayNG를 설치하거나 코어 요구 사항에 따라 v2flyNG를 선택합니다. 클라이언트를 연 뒤 구독 설정을 찾아 그룹을 추가하고 전체 구독 링크를 붙여넣은 다음 업데이트를 실행하세요. 목록이 여전히 비어 있다면 그룹이 활성화되어 있는지, 링크가 잘리지 않았는지, 업데이트가 실제로 완료되었는지 먼저 확인합니다.
노드 링크 하나만 있다면 클립보드에서 가져오기 또는 QR 코드 가져오기를 사용할 수 있습니다. 구독과 단일 노드는 모두 로컬 설정을 생성하지만, 이후 일괄 업데이트에는 구독이 더 적합합니다. 가져오기가 끝난 뒤에는 라우팅 템플릿을 바로 수정하지 말고 기본 설정을 유지해야 노드 자체가 연결을 만들 수 있는지 판단하기 쉽습니다.
구독 그룹에서 노드 하나를 선택해 현재 활성 설정으로 지정합니다. 데스크톱에서는 먼저 시스템 프록시를 켜 시스템 설정을 읽는 앱이 클라이언트를 통하도록 하고, Android에서는 연결을 시작한 뒤 시스템 권한 승인을 확인합니다. 이 단계에서는 기본 연결만 확인하고 복잡한 라우팅 분기, 사용자 지정 DNS, 다중 프록시를 동시에 활성화하지 마세요.
더 많은 데스크톱 프로그램을 클라이언트로 보내야 할 때 TUN을 고려하세요. 활성화하기 전에 일반 시스템 프록시가 이미 작동하는지 확인하고, 같은 가상 인터페이스나 프록시 포트를 점유할 수 있는 다른 프로그램을 종료합니다. TUN이 실패했다고 노드가 고장 난 것은 아닙니다. 권한, 라우팅 테이블, 가상 인터페이스 또는 DNS 인계 방식 때문인 경우가 더 많습니다.
기본 연결이 설정되면 직접 연결되어야 하는 대상 하나와 프록시를 거쳐야 하는 대상 하나를 각각 테스트하고, 클라이언트 로그에 해당 아웃바운드가 나타나는지 확인합니다. 도메인 접속만 이상하고 주소로 직접 연결하면 정상이라면 DNS를 먼저 점검하세요. 브라우저는 정상인데 특정 프로그램만 연결되지 않는다면 해당 프로그램이 시스템 프록시를 읽는지 또는 TUN이 필요한지 확인합니다.
마지막으로 사용자 지정 라우팅을 추가하세요. 매번 규칙 한 그룹만 늘리고 저장한 뒤 다시 연결해 재테스트합니다. 문제가 생기면 ‘구독 내용, 노드 연결, 트래픽 인계, 라우팅 매칭, DNS 조회’ 순서로 내려가며 점검하는 편이 노드를 계속 바꾸는 것보다 원인을 찾기 쉽습니다.
코어, 그래픽 UI, 구독 서비스를 서로 분리해 이해하면 많은 설정 문제가 훨씬 단순해집니다. 이들은 서로 다른 계층에 있고 이름은 비슷하지만 담당하는 역할은 다릅니다.
PROJECT V
Project V는 조합 가능한 네트워크 프록시 도구와 설정 모델을 구축해 왔습니다. 일반적인 설정은 인바운드, 아웃바운드, 라우팅, DNS, 전송 매개변수로 구성됩니다. 인바운드는 로컬 앱의 트래픽을 받고, 아웃바운드는 트래픽이 나가는 방식을 결정하며, 라우팅은 대상별로 지정된 출구에 전달하고, DNS는 도메인 조회 결과를 제공합니다. 그래픽 클라이언트는 이러한 구조를 메뉴, 스위치, 구독 그룹으로 바꿔 일상적인 사용을 빈 설정 파일에서 시작하지 않아도 되게 합니다.
이 계층을 이해해야 하는 이유는 클라이언트 UI의 ‘시스템 프록시’, ‘라우팅 모드’, ‘원격 DNS’가 서로 무관한 독립 기능이 아니기 때문입니다. 결국 코어가 읽을 수 있는 설정으로 변환됩니다. 연결에 실패하면 모든 이상을 노드 탓으로 돌리기보다 UI 저장, 설정 생성, 코어 시작, 네트워크 출구 중 어느 단계에서 문제가 발생했는지 확인해야 합니다.
CORE FAMILIES
V2Fly는 Project V의 커뮤니티 구현과 설정 체계를 이어가고, Xray는 유사한 설정 방식 위에서 자체 기능 구성을 발전시키고 있습니다. 두 코어 모두 일반적인 인바운드, 아웃바운드, 라우팅, DNS 작업과 다양한 전송 조합을 지원하지만, 구체적인 필드와 기능 범위, 업데이트 주기는 다를 수 있습니다. 설정을 복사할 때는 대상 클라이언트가 어떤 코어를 사용하는지 먼저 확인해야 하며, 노드 이름이 같다는 이유만으로 모든 옵션을 서로 바꿔 쓸 수 있다고 가정해서는 안 됩니다.
VMess, VLESS, Trojan 등의 이름은 프로토콜이나 설정 방식을 가리키고, V2Fly와 Xray는 설정을 실행하는 코어 계열을 가리키며, v2rayN·v2rayNG·v2flyNG는 사용자가 직접 조작하는 클라이언트입니다. 이 세 계층을 나누어 보면 프로토콜 기능, 코어 기능, UI 기능을 하나의 개념으로 혼동하는 일을 피할 수 있습니다.
CLIENT LAYER
v2rayN은 Windows, macOS, Linux를 지원하는 데스크톱 그래픽 클라이언트로, 구독 관리, 노드 전환, 시스템 프록시, TUN, 라우팅 템플릿, 로그 확인을 담당합니다. 새로운 프로토콜이 아니라 코어 설정을 데스크톱 UI로 정리해 주는 도구입니다. 데스크톱 운영체제마다 권한 모델과 프록시 설정 위치가 다르므로 같은 옵션도 플랫폼별 활성화 과정에 차이가 있습니다.
v2rayNG는 Android용이며 일반적으로 Xray 코어와 함께 사용합니다. v2flyNG도 Android용이지만 코어 계열의 차이를 주요 선택 기준으로 삼습니다. 두 클라이언트 모두 구독과 단일 노드 설정을 가져올 수 있고, 시스템이 제공하는 로컬 VPN 인터페이스를 통해 앱 트래픽을 인계받습니다. 선택할 때는 먼저 구독 내용과 필요한 코어 기능을 확인하고, UI 이름만으로 판단할 필요는 없습니다.
LICENSE & MAINTENANCE
클라이언트와 코어는 서로 다른 프로젝트에서 유지보수하며, 각각 명확한 오픈소스 라이선스, 릴리스 주기, 호환 범위를 갖습니다. 오픈소스라는 것은 코드, 라이선스 범위, 변경 기록을 공개적으로 검토할 수 있다는 뜻이지 모든 구성 요소가 같은 날 업데이트된다는 의미는 아닙니다. 클라이언트 릴리스에는 UI 적용, 코어 통합, 플랫폼 패키징도 필요하므로 클라이언트와 코어 업데이트 사이에 시차가 생기는 것은 정상입니다.
일상적인 사용에서 모든 변경 사항을 따라갈 필요는 없습니다. 프로토콜 호환성, 운영체제 업그레이드, 명확한 장애가 발생했을 때 업데이트 내용을 확인하고 업그레이드하는 편이 안전합니다. 업데이트 전 현재 구독 그룹, 라우팅 모드, DNS 설정을 기록하고, 업그레이드 후 기본 연결을 먼저 확인한 다음 사용자 지정 규칙을 복원하세요. 이렇게 하면 ‘프로그램 업데이트로 인한 변화’와 ‘기존 설정 문제’를 구분할 수 있습니다.
클라이언트 선택, 플랫폼 배포, 연결 문제 해결을 중심으로 정리한 기술 글입니다. 각 글은 하나의 명확한 문제만 다룹니다.
플랫폼 지원, 코어 계열, 구독 관리, 라우팅 분기라는 네 가지 기준으로 세 클라이언트를 비교하고, 데스크톱과 Android에서의 선택 기준을 제시합니다. 또한 v2flyNG가 어떤 코어 요구에 더 적합한지도 설명합니다.
기술 노트 읽기 →메인 라우터와 별도 라우터에서 코어를 직접 실행하는 두 가지 방식을 정리하고, 하드웨어 성능, 시스템 펌웨어, 설정 배포, 투명 프록시의 관계를 설명합니다. 가정 네트워크를 중앙에서 관리하기에 적합한지 판단하는 데 도움을 줍니다.
기술 노트 읽기 →DNS 조회 경로부터 문제를 추적한 뒤 클라이언트의 원격 조회, 내장 DNS 분기, TUN 인계 설정을 조정하고, 반복 테스트로 DNS 출구와 트래픽 출구가 일치하는지 확인합니다.
기술 노트 읽기 →