기기에 맞는 오픈소스 클라이언트를 선택하고, 구독 가져오기부터 라우팅 분할까지 설정과 연결 경로를 하나씩 확인하세요.
설정 질문과 답변
먼저 구독, 클라이언트, 코어를 구분한 뒤 해당 설정을 수정하세요. 클라이언트에 ‘연결됨’이라고 표시되어도 보통 로컬 프록시가 시작되었다는 뜻일 뿐입니다. 실제 웹사이트 접속 여부는 서버 정보, 앱의 프록시 사용 방식, DNS와 라우팅 설정이 함께 맞아야 결정됩니다. 아래에서 자주 쓰는 작업을 하나씩 살펴봅니다. 예시 필드는 Xray 형식의 설정을 기준으로 하며, 다른 코어는 해당 코어의 설정 형식을 확인하세요.
일상 사용먼저 구독 그룹을 만든 다음 전체 링크를 붙여넣고 업데이트하세요. 구독 주소는 서버 목록을 가져오는 주소이며, 개별 서버 공유 링크와는 다릅니다. 가져오기 유형을 잘못 선택하면 업데이트 후 목록이 비어 있을 수 있습니다. 저장한 뒤 현재 그룹을 확인하고 서버 하나를 활성 항목으로 선택하세요. 업데이트에 실패하면 링크가 만료되었는지, 응답이 로그인 페이지인지, 클라이언트에서 해당 주소에 접속할 수 있는지 확인하세요. 화면을 공유할 때는 접속 정보가 노출되지 않도록 구독 주소 전체를 가리세요.
{
"type": "field",
"domain": ["geosite:cn"],
"outboundTag": "direct"
}먼저 직접 연결할 대상을 정한 뒤 구체적인 규칙을 포괄적인 규칙보다 앞에 배치하세요. 라우팅은 보통 규칙 순서대로 매칭되며, 먼저 일치한 규칙이 아웃바운드를 결정합니다. 직접 연결 규칙을 맨 끝에만 추가하면 앞선 프록시 규칙을 덮어쓰지 못할 수 있습니다. 예시의 direct는 실제로 존재하는 아웃바운드 태그와 일치해야 하며, 코어가 geosite 데이터 파일을 읽을 수 있어야 합니다. 저장 후 설정을 다시 불러오고 새 연결의 로그를 확인하세요. 전역 모드를 반복해서 바꾸기보다 규칙이 매칭된 이유를 확인하면 설정을 관리하기 쉽습니다.
dns / routing먼저 도메인 주소를 어디에서 조회하는지 확인한 뒤 DNS 서버를 선택하세요. 브라우저, 운영체제, 프록시 코어가 각각 다른 조회 경로를 사용할 수 있으므로 한 곳의 설정을 바꿔도 모든 앱에 적용되는 것은 아닙니다. 도메인으로는 접속할 수 없지만 IP로는 접속되는 경우 로그에서 이름 조회 실패, 예상과 다른 결과, 조회 경로 문제를 확인하세요. 도메인 전략은 라우팅 단계에서 이름 조회를 시도할지에 영향을 줄 뿐, 모든 DNS 요청이 프록시를 통과한다는 뜻은 아닙니다. 설정을 한 번에 하나씩 바꾸고 관련 캐시를 비우면 여러 서버를 동시에 변경하는 것보다 원인을 찾기 쉽습니다.
앱이 시스템 프록시를 따르지 않는 경우 TUN 사용을 검토하세요. TUN은 가상 네트워크 인터페이스로 트래픽을 전달하므로 브라우저가 시스템 프록시 설정을 읽는 방식과는 작동 계층이 다릅니다. 사용하기 전에 일반 프록시 연결이 정상인지 확인하고, 클라이언트에 필요한 권한과 가상 네트워크 어댑터 지원 여부, 다른 네트워크 도구와의 충돌을 점검하세요. 사용 후에는 로컬 기기, LAN 서비스, DNS에 계속 접속할 수 있는지 테스트하세요. TUN으로 잘못된 서버 정보를 해결할 수는 없으며 모든 앱에서 정상 작동한다고 보장되지도 않습니다. 문제가 생기면 먼저 TUN을 끄고 확인된 기본 연결부터 점검하세요.
먼저 기기의 네트워크와 시간을 확인한 다음 구독과 로그를 점검하세요. 시간 초과는 정해진 시간 안에 연결이 완료되지 않았다는 뜻이지, 특정 원인으로 고장 났다는 의미는 아닙니다. 구독을 업데이트하고 활성 서버를 확인한 뒤 주소, 포트, 전송 방식, TLS 설정이 서로 맞는지 살펴보세요. 로그의 이름 조회 실패, 연결 거부, 핸드셰이크 오류는 각각 다른 단계의 문제이므로 따로 처리해야 합니다. 같은 네트워크에 연결된 여러 기기에서 동일한 문제가 생기면 서버 상태도 확인하세요. 오류 메시지를 살펴보는 대신 클라이언트를 반복해서 재설치하지 마세요.
먼저 구독 그룹을 만든 다음 전체 링크를 붙여넣고 업데이트하세요. 구독 주소는 서버 목록을 가져오는 주소이며, 개별 서버 공유 링크와는 다릅니다. 가져오기 유형을 잘못 선택하면 업데이트 후 목록이 비어 있을 수 있습니다. 저장한 뒤 현재 그룹을 확인하고 서버 하나를 활성 항목으로 선택하세요. 업데이트에 실패하면 링크가 만료되었는지, 응답이 로그인 페이지인지, 클라이언트에서 해당 주소에 접속할 수 있는지 확인하세요. 화면을 공유할 때는 접속 정보가 노출되지 않도록 구독 주소 전체를 가리세요.
{
"type": "field",
"domain": ["geosite:cn"],
"outboundTag": "direct"
}먼저 직접 연결할 대상을 정한 뒤 구체적인 규칙을 포괄적인 규칙보다 앞에 배치하세요. 라우팅은 보통 규칙 순서대로 매칭되며, 먼저 일치한 규칙이 아웃바운드를 결정합니다. 직접 연결 규칙을 맨 끝에만 추가하면 앞선 프록시 규칙을 덮어쓰지 못할 수 있습니다. 예시의 direct는 실제로 존재하는 아웃바운드 태그와 일치해야 하며, 코어가 geosite 데이터 파일을 읽을 수 있어야 합니다. 저장 후 설정을 다시 불러오고 새 연결의 로그를 확인하세요. 전역 모드를 반복해서 바꾸기보다 규칙이 매칭된 이유를 확인하면 설정을 관리하기 쉽습니다.
먼저 도메인 주소를 어디에서 조회하는지 확인한 뒤 DNS 서버를 선택하세요. 브라우저, 운영체제, 프록시 코어가 각각 다른 조회 경로를 사용할 수 있으므로 한 곳의 설정을 바꿔도 모든 앱에 적용되는 것은 아닙니다. 도메인으로는 접속할 수 없지만 IP로는 접속되는 경우 로그에서 이름 조회 실패, 예상과 다른 결과, 조회 경로 문제를 확인하세요. 도메인 전략은 라우팅 단계에서 이름 조회를 시도할지에 영향을 줄 뿐, 모든 DNS 요청이 프록시를 통과한다는 뜻은 아닙니다. 설정을 한 번에 하나씩 바꾸고 관련 캐시를 비우면 여러 서버를 동시에 변경하는 것보다 원인을 찾기 쉽습니다.
앱이 시스템 프록시를 따르지 않는 경우 TUN 사용을 검토하세요. TUN은 가상 네트워크 인터페이스로 트래픽을 전달하므로 브라우저가 시스템 프록시 설정을 읽는 방식과는 작동 계층이 다릅니다. 사용하기 전에 일반 프록시 연결이 정상인지 확인하고, 클라이언트에 필요한 권한과 가상 네트워크 어댑터 지원 여부, 다른 네트워크 도구와의 충돌을 점검하세요. 사용 후에는 로컬 기기, LAN 서비스, DNS에 계속 접속할 수 있는지 테스트하세요. TUN으로 잘못된 서버 정보를 해결할 수는 없으며 모든 앱에서 정상 작동한다고 보장되지도 않습니다. 문제가 생기면 먼저 TUN을 끄고 확인된 기본 연결부터 점검하세요.
먼저 기기의 네트워크와 시간을 확인한 다음 구독과 로그를 점검하세요. 시간 초과는 정해진 시간 안에 연결이 완료되지 않았다는 뜻이지, 특정 원인으로 고장 났다는 의미는 아닙니다. 구독을 업데이트하고 활성 서버를 확인한 뒤 주소, 포트, 전송 방식, TLS 설정이 서로 맞는지 살펴보세요. 로그의 이름 조회 실패, 연결 거부, 핸드셰이크 오류는 각각 다른 단계의 문제이므로 따로 처리해야 합니다. 같은 네트워크에 연결된 여러 기기에서 동일한 문제가 생기면 서버 상태도 확인하세요. 오류 메시지를 살펴보는 대신 클라이언트를 반복해서 재설치하지 마세요.
이 예시는 어떻게 사용하나요?현재 정상 작동하는 설정을 먼저 기록한 다음 문제 항목을 하나씩 수정하세요. 라우팅 화면은 설정 간 관계를 보여주는 예시이며, 그대로 가져올 수 있는 완성된 설정 파일이 아닙니다. 아웃바운드 태그는 클라이언트가 생성한 아웃바운드와 일치해야 하며, 규칙 데이터도 실제로 있어야 합니다. 수정 후 새 연결로 확인하세요. 기존 연결이 이전 경로를 계속 사용하는 상황을 설정 미적용으로 오해하지 않도록 주의하세요.
화면의 문구가 가이드와 다르면 메뉴 위치를 그대로 따라가기보다 해당 기능을 찾아보세요. 데스크톱과 모바일 클라이언트는 구독 관리, 로그 위치, 프록시 연결 방식이 완전히 같지 않습니다. 처음 사용한다면 기본 연결을 먼저 완료한 뒤 분할 규칙과 DNS 설정을 추가하세요. 그러면 문제가 생겼을 때 서버 연결, 앱의 트래픽 전달, 추가 규칙 중 무엇이 달라졌는지 파악하기 쉽습니다.
플랫폼 선택
데스크톱에서는 v2rayN, Android 기기에서는 v2rayNG를 먼저 확인하세요. V2Fly 코어와의 호환이 필요하면 v2flyNG도 고려할 수 있습니다. 클라이언트는 로컬 설정과 연결을 관리하며, 구독과 서버 접속 정보는 별도로 준비해야 합니다. 운영체제, CPU 아키텍처, 사용할 프로토콜을 먼저 확인한 뒤 해당 플랫폼의 설치 파일을 선택하세요. 파일명에 익숙한 클라이언트 이름이 있다는 이유만으로 설치하지 마세요.
데스크톱에서는 v2rayN을 우선 고려하세요. 크로스 플랫폼 데스크톱 버전과 기존 WPF 버전은 서로 다른 UI 기술을 사용하므로 실행 환경 요구 사항도 각각 확인해야 합니다. 처음 설치한다면 다운로드 페이지의 안내를 먼저 읽고 운영체제와 아키텍처에 맞는 파일을 선택하세요. 기존 설정을 사용 중이라면 업그레이드 전에 구독 그룹, 사용자 지정 라우팅, DNS 설정을 백업하세요.
실행 후 코어가 정상적으로 작동하는지 확인한 다음 구독을 가져오고 활성 서버를 설정하세요. 브라우저가 시스템 프록시를 따르지 않는다면 브라우저 확장 프로그램, 별도의 프록시 설정, 클라이언트의 시스템 프록시 상태를 먼저 확인하세요. 터미널은 보통 프록시를 별도로 설정해야 합니다. 브라우저가 연결된다고 해서 모든 데스크톱 앱도 프록시를 사용한다고 볼 수는 없습니다.
다운로드 페이지로 이동먼저 시스템의 ‘이 Mac에 관하여’에서 칩 정보를 확인한 뒤 Apple Silicon 또는 Intel에 맞는 설치 항목을 선택하세요. v2rayN 크로스 플랫폼 버전은 구독, 서버, 라우팅을 관리하는 주요 작업 흐름을 제공하지만, 시스템 프록시 권한, 네트워크 권한, 창 배치는 다른 데스크톱 시스템과 다를 수 있습니다.
처음 실행할 때 시스템 알림이 표시되면 다운로드 출처와 패키지 유형을 확인한 뒤 시스템에서 안내하는 앱 실행 절차를 따르세요. 시스템 보안 기능을 통째로 끄지 마세요. 연결 후 브라우저와 실제로 사용하는 앱을 각각 테스트하세요. TUN이 필요하다면 클라이언트 안내에 따라 필요한 권한을 허용하고 로컬 네트워크 접속에 영향이 있는지 확인하세요.
다운로드 페이지로 이동Android에서는 Xray 코어를 사용하는 v2rayNG를 먼저 확인하고, V2Fly 코어 기반 v2flyNG를 대안으로 고려하세요. 최신 기기 대부분은 arm64 패키지를 선택할 수 있습니다. 아키텍처를 모른다면 기기 정보를 확인한 뒤 범용 패키지를 검토하세요. 패키지 아키텍처는 설치 가능 여부를 결정하고, 서버를 실제로 사용할 수 있는지는 프로토콜과 코어의 지원 여부에 달려 있습니다.
프록시를 시작할 때 시스템 VPN 연결 권한 요청이 표시되는 경우가 많습니다. 이는 모바일 기기의 앱 트래픽을 전달하기 위한 방식이며 클라이언트가 원격 서버를 자동으로 제공한다는 뜻은 아닙니다. 같은 인터페이스를 사용하는 다른 네트워크 도구가 있다면 연결 충돌에 유의하세요. 백그라운드에서 연결이 끊긴다면 절전 설정과 백그라운드 실행 제한을 확인해 앱이 시스템에 의해 중지된 것인지 서버 연결이 실패한 것인지 구분하세요.
다운로드 페이지로 이동Linux 데스크톱에서는 v2rayN을 사용할 수 있습니다. 배포판의 패키지 관리 방식에 따라 deb 또는 rpm을 선택한 뒤 x64와 arm64를 구분하세요. 설치해도 데스크톱 환경에서 시스템 프록시가 자동으로 적용되는 것은 아닙니다. 데스크톱 환경, 브라우저, 터미널마다 프록시 설정을 처리하는 방식이 다르므로 실제 사용하는 프로그램에서 각각 확인해야 합니다.
클라이언트는 실행되지만 앱이 연결되지 않는다면 로컬 수신 포트, 프록시 유형, 앱 설정을 확인한 다음 시스템 프록시 연결을 살펴보세요. 프록시를 따르지 않는 트래픽까지 처리해야 하는 경우에만 TUN 사용을 검토하고 클라이언트가 요구하는 권한을 설정하세요. 서버의 명령줄 전용 환경은 그래픽 데스크톱과 설치 방식이 다르며, 이 페이지에서는 데스크톱 클라이언트를 중심으로 안내합니다.
다운로드 페이지로 이동클라이언트를 설치하면 바로 연결할 수 있나요?유효한 서버 설정이나 구독도 필요합니다. 클라이언트는 설정과 연결을 관리하는 도구이지, 원격 서버를 자동으로 만들어 주지는 않습니다. 구독이 있다면 먼저 유효 기간과 지원 프로토콜을 확인하세요. 첫 연결 방법 보기 →
데스크톱과 모바일 설정을 그대로 옮길 수 있나요?일반적인 공유 링크는 각각 가져올 수 있는 경우가 있지만, 클라이언트 백업 파일, 라우팅 템플릿, 코어 설정은 호환되지 않을 수 있습니다. 이전할 때는 서버를 먼저 가져온 뒤 규칙을 별도로 확인하세요. 클라이언트별 차이 보기 →
업데이트에 실패하면 재설치해야 하나요?클라이언트 업데이트 실패와 구독 업데이트 실패를 먼저 구분하세요. 전자는 설치 환경과 관련이 있고, 후자는 링크, 네트워크, 응답 형식 문제인 경우가 많습니다. 기존 설정과 오류 메시지를 보존한 뒤 해결 방법을 확인하세요. 도움말 센터 보기 →
모드가 많을수록 연결이 잘되나요?모드는 트래픽이 프록시로 전달되는 방식과 아웃바운드 선택에 영향을 줄 뿐, 인증이나 전송 설정 오류를 해결하지는 않습니다. 먼저 단순한 경로로 서버 연결을 확인한 뒤 규칙을 추가하면 문제 범위를 좁히기 쉽습니다. 심화 설정 읽기 →
생태계와 유지 관리
지원 기능을 이해하려면 먼저 코어와 클라이언트를 구분해야 합니다. 코어는 프로토콜, 라우팅, DNS 같은 네트워크 로직을 처리하고, 클라이언트는 구독과 서버 정보, 설정을 모아 실행 가능한 구성으로 만듭니다. 화면에 같은 이름이 표시되어도 실제로 사용하는 코어는 다를 수 있습니다. 같은 서버 정보를 어떤 코어에서나 그대로 실행할 수 있는 것도 아닙니다.
Project V는 네트워크 프록시와 통신 도구를 중심으로 형성된 오픈소스 프로젝트 생태계이며, V2Ray는 잘 알려진 핵심 소프트웨어입니다. 개발과 유지 관리 방향이 달라지면서 V2Fly는 V2Ray 관련 개발을 이어 갔고, Xray는 관련 코드 기반에서 출발해 자체 구현과 기능 방향을 발전시켰습니다. 따라서 검색어 ‘V2Ray’는 사용 환경 전반을 가리킬 때도 있고 특정 코어를 지칭할 때도 있습니다. 설정 문법을 확인할 때는 정확한 이름을 사용하세요.
이 관계가 소프트웨어 하나를 설치하면 모든 기능을 사용할 수 있다는 뜻은 아닙니다. GUI 클라이언트는 서로 다른 코어를 실행하는 방식을 제공할 수 있지만, 지원 프로토콜과 전송 방식, 설정 항목은 코어마다 다릅니다. 서버 정보를 가져왔는데 시작되지 않는다면 클라이언트 이름만 보고 호환 여부를 추측하지 말고 실제로 선택된 코어와 시작 로그를 확인해 인식할 수 없는 설정 항목이 있는지 살펴보세요.
서버에서 요구하는 프로토콜과 전송 방식을 우선 확인한 뒤 기존 설정을 옮기는 데 드는 비용을 고려하세요. 두 코어는 일부 개념과 개발 기반을 공유하지만 기능 방향과 설정 지원은 완전히 같지 않습니다. REALITY나 특정 flow 같은 항목이 포함된 설정이라면 해당 코어에서 실제 지원하는지 확인하세요. 파일 이름을 바꾸거나 다른 클라이언트로 복사하는 것만으로 변환이 끝나는 것은 아닙니다.
일반 사용자에게는 추상적인 코어 성능 비교보다 구독에 포함된 전체 설정값이 더 중요합니다. 주소, 포트, 인증 정보, 전송 방식, TLS 설정이 서로 맞아야 하며 항목 하나가 빠져도 핸드셰이크에 실패할 수 있습니다. 동일한 환경에서 반복 측정하지 않았다면 한 번의 속도 차이를 코어 자체의 성능 탓으로 단정하지 마세요. 먼저 정상 작동하는 상태를 유지하고 분명한 문제가 있을 때 조정해야 더 신뢰할 수 있는 결과를 얻습니다.
v2rayN은 데스크톱용으로 구독 관리, 서버 선택, 관련 프록시 설정 화면을 제공합니다. v2rayNG는 Xray 코어를 사용하는 Android용 클라이언트이고, v2flyNG는 V2Fly 코어를 사용하는 Android용 클라이언트입니다. 세 프로젝트 모두 오픈소스 클라이언트지만 이 사이트에서 개발한 것은 아니며, 한 클라이언트의 기능 설명을 다른 클라이언트에도 그대로 적용할 수 없습니다. 데스크톱에서는 v2rayN을, 모바일에서는 필요한 프로토콜에 맞는 클라이언트를 선택하세요.
오픈소스란 코드와 관련 라이선스 조건을 확인하고 검토할 수 있다는 뜻이지, 원격 서버도 같은 프로젝트에서 제공한다는 뜻은 아닙니다. 클라이언트 프로젝트, 코어 프로젝트, 구독 서비스는 서로 다른 구성 요소입니다. 이 사이트에서는 각 요소의 관계를 파악할 수 있도록 다운로드 경로와 한국어 사용 안내를 정리합니다. 서버의 이용 권한과 가용성, 사용 범위는 서비스 제공업체의 정보를 확인하세요.
오픈소스 라이선스는 코드의 사용, 수정, 재배포 조건을 정합니다. 코드를 공개한다고 해서 라이선스를 따르지 않아도 되는 것은 아닙니다. V2Fly 관련 코어와 Xray의 핵심 코드는 MPL 2.0을 사용하지만, 개별 파일과 의존성, GUI 클라이언트의 라이선스는 각각 확인해야 합니다. 클라이언트, 코어, 포함된 구성 요소의 라이선스가 서로 다를 수 있으므로 실제 사용 조건은 배포 패키지에 포함된 안내를 확인하세요.
업데이트에도 여러 종류가 있습니다. 클라이언트 업데이트는 UI와 설정 생성 로직에 영향을 주고, 코어 업데이트는 네트워크 구현을 변경합니다. 규칙 데이터 업데이트는 도메인이나 IP 분류에 영향을 주며, 구독 업데이트는 서비스에서 제공하는 서버 목록을 가져옵니다. 각각의 업데이트가 동시에 이뤄지는 것은 아닙니다. 변경 전에 백업하고 업데이트 후 로그를 살펴본 다음 자주 쓰는 앱으로 테스트하세요. 업데이트 직후에만 문제가 나타난다면 어떤 구성 요소가 바뀌었는지 기록하세요. 모든 설정을 한 번에 초기화하면 원인을 찾기 어려워집니다.
최신 글
설정 문제는 실제 증상부터 살펴보고, 원리를 알아볼 때는 프로토콜과 코어를 확인하세요. 아래 세 글은 최근 게시일 순으로 정리했습니다. 노드 연결 시간 초과는 연결 경로를 차례로 점검하고, 시스템 프록시 문제는 브라우저와 터미널을 나누어 확인합니다. REALITY와 Vision 글에서는 서버 설정을 임의로 생략할 수 없는 이유를 다룹니다. 글을 참고할 때는 해당 로그와 상황을 함께 확인하고 서로 다른 오류를 같은 문제로 취급하지 마세요.
기기 시간, 구독 업데이트, 코어 로그, 전송 및 TLS 설정, 서버 상태를 차례로 확인해 노드 연결 시간 초과를 해결합니다. v2rayN과 v2rayNG에서 확인할 위치도 안내합니다.
시간 초과 해결 순서 보기 →브라우저에서 프록시가 작동하지 않는 문제는 확장 프로그램이나 PAC 설정이 원인인 경우가 많고, 터미널은 환경 변수를 직접 설정해야 할 수 있습니다. 두 경로를 나누어 확인하고 TUN 모드를 검토할 시점도 설명합니다.
앱별 프록시 경로 알아보기 →TLS를 중첩할 때 발생하는 중복 암호화 비용을 살펴보고, Vision이 데이터 전송을 최적화하는 방식과 REALITY가 인증서 배포 방식을 바꾸는 원리를 설명합니다. flow와 공개 키의 의미 및 적용 조건도 다룹니다.
프로토콜과 전송 설정 이해하기 →