이 글은 v2rayN, v2rayNG 또는 v2flyNG를 처음 사용하는 분에게 적합합니다. 클라이언트 선택과 구독 가져오기를 마치고, VMess·VLESS·시스템 프록시·라우팅 규칙의 관계를 이해한 뒤 네트워크, 시간, 구독, 노드, 매개변수, 로그 순서로 흔한 연결 문제를 확인할 수 있습니다.
클라이언트와 프로토콜 선택 방법
질문 1: Windows, macOS, Android, Linux에서는 어떤 클라이언트를 선택해야 하나요?
클라이언트는 노드 이름이 아니라 사용 중인 플랫폼에 따라 선택하는 것이 우선입니다. Windows 데스크톱에서는 일반적으로 v2rayN을 사용합니다. Android에서는 Xray 코어를 탑재한 v2rayNG 또는 V2Fly 코어를 탑재한 v2flyNG를 선택할 수 있습니다. macOS와 Linux는 다운로드 센터에서 현재 제공되는 데스크톱 클라이언트를 확인하고, 페이지에 표시된 플랫폼과 아키텍처에 맞는 버전을 받으세요.
Android 사용자는 서버에서 별도 요구사항을 제시하지 않았다면 구독에 실제로 포함된 프로토콜을 기준으로 선택하세요. Xray 관련 기능이 필요하면 v2rayNG를, 설정에 V2Fly 코어가 명시되어 있으면 v2flyNG를 사용합니다. 클라이언트 이름이 다르다고 구독이 반드시 호환되지 않는 것은 아니며, 최종 호환 여부는 프로토콜, 전송 방식, 보안 계층과 코어 버전의 지원 여부에 달려 있습니다.
질문 2: VMess와 VLESS는 어떻게 다르며, 초보자는 무엇을 선택해야 하나요?
VMess와 VLESS는 모두 Project V 생태계에서 널리 사용되는 프록시 프로토콜입니다. VMess 설정에는 보통 사용자 ID, alterId 또는 호환 필드, 보안 옵션, 주소와 포트가 포함됩니다. VLESS는 더 간결한 인증 구조를 사용하며, 설정에는 사용자 ID, flow, 전송 방식과 보안 계층 매개변수가 자주 포함됩니다. 두 프로토콜은 클라이언트에서 임의로 바꿀 수 있는 단순한 옵션이 아닙니다.
가장 안전한 선택 방법은 서버 또는 구독에서 전달한 내용을 그대로 따르는 것입니다. 구독에 VMess가 지정되어 있으면 VMess로 가져오고, VLESS가 지정되어 있으면 VLESS를 유지하세요. 특정 프로토콜 이름을 사용하려고 유형을 수동으로 바꾸지 마세요. 주소와 포트가 같더라도 프로토콜, 사용자 ID, 전송 방식 또는 TLS 설정 중 하나라도 다르면 연결이 즉시 실패할 수 있습니다.
| 비교 항목 | VMess | VLESS |
|---|---|---|
| 인증 정보 | 사용자 ID 및 관련 호환 매개변수 | 사용자 ID, 일부 설정에는 flow 포함 |
| 일반적인 보안 계층 | TLS 등, 서버 설정에 따름 | TLS 또는 서버가 지정한 방식 |
| 선택 기준 | 구독 또는 서버에서 명확히 제공한 내용 | 구독 또는 서버에서 명확히 제공한 내용 |
| 그대로 서로 바꿀 수 있나요? | 불가능합니다 | 불가능합니다 |
질문 3: Xray와 V2Fly 코어를 수동으로 전환해야 하나요?
대부분의 초보자는 처음부터 코어를 직접 전환할 필요가 없습니다. v2rayNG는 Xray 코어로 설정을 처리하고, v2flyNG는 V2Fly 코어로 설정을 처리합니다. v2rayN에서 사용할 수 있는 코어와 버전 설정은 클라이언트 화면을 기준으로 확인하세요. 가져온 뒤 정상적으로 시작되고 속도 측정과 대상 사이트 접속이 가능하다면, 단지 “코어를 바꾸기 위해” 설정을 수정할 필요는 없습니다.
구독 링크 가져오기 및 업데이트
질문 4: 구독 링크는 어디에 붙여 넣어야 하나요?
구독 링크는 일반 노드 주소가 아니며, 브라우저 주소창에 붙여 넣고 장기간 열어 두는 웹페이지도 아닙니다. 보통 완전한 HTTPS 주소로 구성되며, 클라이언트가 해당 주소에 요청을 보내 노드 목록을 해석한 뒤 로컬 구독 그룹에 저장합니다. 복사할 때 마지막 문자가 빠지지 않았는지 확인하고, 메신저가 덧붙인 마침표까지 함께 복사하지 않도록 주의하세요.
링크 확인
구독 주소 전체를 복사한 뒤 시작 프로토콜, 도메인, 경로와 쿼리 매개변수를 확인하세요. 앞뒤에 공백이나 한국어·중국어 문장부호가 없어야 합니다.
그룹 추가
v2rayN 메인 화면에서 「구독 그룹」→「구독 그룹 설정」→「추가」로 이동한 뒤, 메모를 입력하고 주소를 붙여 넣으세요.
구독 업데이트
저장한 후 「구독 그룹」→「모든 구독 업데이트」로 이동하고 노드 목록이 메인 화면에 기록될 때까지 기다리세요.
노드 선택
먼저 노드를 하나 선택한 뒤 지연 시간 테스트를 실행하세요. 결과가 정상인지 확인한 다음 해당 노드를 활성 서버로 지정합니다.
프록시 시작
필요에 따라 시스템 프록시 또는 해당 실행 모드를 활성화한 뒤, 브라우저에서 대상 페이지가 열리는지 테스트하세요.
Android에서는 버전에 따라 메뉴 이름이 달라질 수 있지만 작업 흐름은 같습니다. 구독 그룹 관리로 이동해 추가를 누르고 메모와 URL을 입력한 다음 저장 후 업데이트를 실행하세요. QR 코드를 스캔할 때는 QR 코드에 구독 주소가 들어 있는지 단일 노드가 들어 있는지 먼저 확인하세요. 전자는 여러 노드가 포함된 그룹을 만들고, 후자는 보통 설정 하나만 추가합니다.
질문 5: 구독 업데이트에 실패했는데 이전 노드가 계속 남아 있는 이유는 무엇인가요?
업데이트에 실패하면 클라이언트는 보통 마지막으로 성공적으로 저장한 로컬 데이터를 유지합니다. 따라서 이전 노드가 보인다고 해서 이번 요청이 성공한 것은 아닙니다. 먼저 업데이트 알림과 로그 시간을 확인한 뒤 구독 주소가 아직 유효한지 점검하세요. 처음부터 그룹 전체를 삭제하면 비교에 사용할 이전 설정까지 함께 사라지므로 피하는 것이 좋습니다.
일반적인 원인으로는 시스템 시간 오차, 불완전하게 복사된 구독 주소, 현재 네트워크에서 구독 도메인에 접근할 수 없는 경우, 만료된 링크, 클라이언트의 백그라운드 네트워크 권한 부족 등이 있습니다. Android에서는 업데이트 중 앱이 시스템에 의해 일시 중지되지 않았는지도 확인해야 하며, 특히 화면을 잠그거나 다른 앱으로 전환한 뒤에 주의하세요.
오류: subscription update failed
원인 및 해결 방법:클라이언트가 구독 내용을 가져오지 못했습니다. 원본 링크를 다시 덮어써서 저장하고 시스템 시간을 보정한 뒤 네트워크를 바꿔 수동 업데이트를 한 번 실행하세요.
오류: unexpected EOF
원인 및 해결 방법:내용 전송이 완료되기 전에 연결이 끊겼습니다. 클라이언트를 전면에 둔 상태에서 안정적인 네트워크로 바꿔 재시도하고, 구독 서비스가 일시적으로 사용할 수 없는 상태인지 확인하세요.
프록시 모드와 라우팅 분할의 차이
질문 6: 시스템 프록시를 켜면 모든 프로그램이 노드를 사용하나요?
반드시 그렇지는 않습니다. 시스템 프록시는 프록시 주소와 포트를 운영체제 설정에 기록할 뿐이며, 시스템 프록시를 따르는 앱만 자동으로 사용합니다. 일부 프로그램은 독립적인 네트워크 스택을 사용하거나 자체적으로 프록시를 지정하거나 직접 연결을 만들기 때문에 시스템 프록시를 우회할 수 있습니다. Android의 VPN 서비스 모드는 적용 범위가 더 넓지만, 앱별 설정, 우회 규칙과 시스템 제한의 영향을 받을 수 있습니다.
데스크톱에서는 로컬 수신 포트가 HTTP 10809, SOCKS 10808로 표시될 수 있으며 버전이나 사용자 설정에 따라 달라질 수도 있습니다. 다른 프로그램에 프록시를 수동으로 입력할 때는 클라이언트에 현재 표시된 실제 포트를 확인해야 하며, 인터넷 예시를 그대로 복사하지 마세요. 다른 프로세스가 포트를 사용 중이면 코어가 시작되지 않을 수도 있습니다.
질문 7: 전역, 규칙, 직접 연결 모드는 어떻게 선택해야 하나요?
전역 모드는 일반적으로 클라이언트가 가로챈 트래픽을 우선 프록시 아웃바운드로 보냅니다. 노드 작동 여부를 임시로 확인하기에는 적합하지만, 로컬 서비스나 프록시가 필요 없는 사이트까지 우회시킬 수 있습니다. 규칙 모드는 도메인, IP, 규칙 세트 또는 프로세스 조건에 따라 프록시, 직접 연결 또는 차단을 결정하므로 일상적인 사용에 더 적합합니다. 직접 연결 모드는 프록시의 영향을 잠시 중단하고 로컬 네트워크와 비교할 때 주로 사용합니다.
초보자는 먼저 전역 모드로 짧게 테스트해 보세요. 전역 모드는 작동하지만 규칙 모드가 작동하지 않는다면 문제는 대개 노드 자체가 아니라 라우팅 규칙이나 DNS 분할에 있습니다. 확인이 끝나면 규칙 모드로 돌아가 대상 도메인이 어떤 규칙에 매칭되었는지 확인하세요. 규칙을 수정할 때는 한 번에 하나만 바꾸어야 합니다. DNS, 라우팅, 프로토콜을 동시에 조정하면 어떤 변경이 실제로 적용되었는지 판단하기 어렵습니다.
- 전역 모드:노드와 프로토콜 매개변수가 유효한지 빠르게 확인할 때 적합합니다.
- 규칙 모드:장기간 실행하기에 적합하며 도메인과 IP에 따라 트래픽 경로를 제어합니다.
- 직접 연결 모드:로컬 네트워크와 비교하여 문제가 프록시 경로에서 발생했는지 판단할 때 적합합니다.
- 차단 규칙:특정 요청을 명시적으로 거부할 때 사용하며 연결 시간 초과와는 다릅니다.
노드 연결 실패 점검 순서
질문 8: 노드에 시간 초과가 표시되면 첫 단계로 무엇을 해야 하나요?
첫 단계는 노드를 열 개 넘게 연속으로 바꾸는 것이 아니라 로컬 네트워크가 정상인지 확인하는 것입니다. 프록시를 끈 상태에서 안정적인 국내 사이트에 접속한 뒤 시스템 날짜, 시간대와 자동 동기화 상태를 확인하세요. TLS 연결에는 올바른 시간이 필요하므로 시스템 시간 오차가 크면 노드 주소와 포트가 맞아도 핸드셰이크 단계에서 실패할 수 있습니다.
두 번째로 구독 상태와 개별 노드 매개변수를 확인합니다. 주소에 불필요한 공백이 없는지, 포트가 1~65535 범위인지, 사용자 ID, 프로토콜 유형, 전송 방식, Host, 경로, SNI와 보안 계층이 서버와 일치하는지 확인하세요. 설정이 구독에서 가져온 것이라면 우선 다시 업데이트하고, 기억에 의존해 필드를 직접 수정하지 마세요.
세 번째 단계에서 네트워크와 노드를 바꾸고 로그를 확인합니다. 가정용 네트워크에서는 실패하지만 모바일 네트워크에서는 성공한다면 로컬 DNS, 라우팅 또는 네트워크 출구가 다를 가능성이 큽니다. 모든 네트워크에서 같은 노드가 실패한다면 노드 상태와 매개변수를 우선 확인하세요. 한 번의 지연 시간 테스트에는 최소 10~15초 정도 기다리며, 순간적인 무응답을 영구적인 만료로 단정하지 마세요.
오류: connection timed out
원인 및 해결 방법:제한 시간 안에 연결이 완료되지 않았습니다. 먼저 로컬 네트워크와 시스템 시간을 확인한 뒤 노드 주소, 포트 및 현재 네트워크에서 서버에 접근할 수 있는지 점검하세요.
오류: connection refused
원인 및 해결 방법:대상 주소에는 도달했지만 해당 포트가 연결을 거부했습니다. 포트를 잘못 입력하지 않았는지 확인하고 서버 프로세스가 해당 포트에서 수신 중인지 점검하세요.
오류: invalid user
원인 및 해결 방법:사용자 인증 매개변수가 일치하지 않습니다. 구독을 다시 동기화하고 사용자 ID, 프로토콜 유형과 서버의 사용자 설정을 확인하세요.
오류: failed to find an available destination
원인 및 해결 방법:아웃바운드 서버 주소를 확인하지 못했습니다. 노드 도메인의 철자를 점검하고 사용 가능한 DNS로 전환한 뒤 코어를 다시 시작하세요.
DNS, 로그와 백그라운드 실행 점검
질문 9: 연결은 되는데 웹페이지가 열리지 않으면 DNS 문제인가요?
그럴 수 있지만 먼저 “프록시 연결이 설정되었는지”와 “대상 도메인이 정상적으로 해석되는지”를 구분해야 합니다. 노드 지연 시간이 정상이라는 것은 프록시 서버까지의 경로가 작동할 가능성을 보여 줄 뿐, 대상 도메인이 반드시 올바르게 해석된다는 뜻은 아닙니다. IP에 직접 접속하면 응답하지만 도메인 접속에 실패한다면 DNS 문제일 가능성이 높습니다. 모든 요청이 시간 초과된다면 라우팅, 아웃바운드와 프로토콜 매개변수도 확인해야 합니다.
점검할 때는 먼저 클라이언트의 기본 DNS 설정으로 되돌려 출처가 불명확한 서버를 여러 개 동시에 설정하지 않도록 하세요. 그런 다음 코어를 다시 시작하고 시스템 DNS 캐시를 비운 뒤, 접속 가능한 것으로 확인된 도메인을 테스트합니다. 규칙 모드에서는 DNS 요청이 직접 연결되는지 프록시를 통하는지, 해석 결과가 라우팅 규칙에 따라 예상한 아웃바운드로 전달되는지도 확인해야 합니다.
기본 점검 순서
1. 프록시를 끄고 로컬 네트워크가 정상인지 확인
2. 프록시를 켜고 코어가 정상적으로 시작되는지 확인
3. 로컬 HTTP 및 SOCKS 수신 포트 확인
4. 노드 지연 시간과 실제 연결 테스트
5. DNS 해석 및 라우팅 매칭 기록 확인
6. 첫 번째 명확한 오류에 따라 매개변수 하나만 수정로그는 장애가 발생한 시점부터 과거 방향으로 확인하고, 첫 번째 error 또는 warning을 우선 찾으세요. 뒤이어 나타나는 많은 timeout은 첫 오류가 연쇄적으로 일으킨 결과일 수 있습니다. v2rayN에서는 메인 화면의 로그 영역에서 코어 출력을 확인하고, 「설정」→「매개변수 설정」에서 관련 실행 매개변수를 점검할 수 있습니다. Android 클라이언트에서는 로그 페이지에서 실패한 작업을 다시 실행해 시간과 요청을 서로 대조하세요.
질문 10: Android 백그라운드 연결 끊김을 안정성과 배터리 사용량 사이에서 어떻게 조절하나요?
백그라운드 연결 끊김은 보통 시스템 배터리 정책, 앱의 백그라운드 권한, 네트워크 전환 또는 메모리 회수와 관련이 있습니다. 먼저 시스템 설정에서 v2rayNG 또는 v2flyNG의 백그라운드 실행을 허용하고, VPN 연결이 절전 정책의 제한을 받지 않는지 확인하세요. Android 기기마다 메뉴 이름은 다르지만 일반적인 경로는 「설정」→「앱」→「v2rayNG」→「배터리」→「백그라운드 활동 허용」입니다.
그다음 불필요한 백그라운드 작업을 줄이세요. 구독은 몇 분마다 업데이트할 필요가 없고, 라우팅 규칙도 변경되지 않았다면 반복해서 다시 불러오지 않아도 됩니다. 브라우저를 사용할 때만 연결이 필요하다면 필요할 때 시작하고, 계속 온라인 상태를 유지해야 한다면 시스템 상태 표시줄의 VPN 서비스 알림을 유지하며 백그라운드 프로세스를 강제로 종료하는 시스템 정리 기능은 피하세요.
백그라운드 실행 허용
「설정」→「앱」→해당 클라이언트→「배터리」로 이동해 백그라운드 활동을 허용하고 과도한 제한을 해제하세요.
업데이트 주기 줄이기
구독 자동 업데이트를 몇 시간 단위로 조정하고, 노드에 변화가 없으면 수동 업데이트를 사용하세요.
네트워크 전환 확인
Wi-Fi와 모바일 네트워크를 전환한 뒤 연결 상태를 확인하고, 필요하면 서비스를 한 번 중지한 다음 다시 시작하세요.
로그 보관
연결이 끊긴 시간, 네트워크 유형과 첫 번째 오류를 기록해 단순히 “열리지 않는다”는 현상만으로 원인을 판단하지 않도록 하세요.
초기 설정을 마친 뒤에는 정상 작동이 확인된 노드 하나를 비교용으로 남겨 두는 것이 좋습니다. 이후 문제가 발생하면 먼저 이 노드를 테스트한 다음 구독 전체의 변경인지, 현재 네트워크 이상인지, 새 노드 매개변수 불일치인지 판단하세요. 고정된 비교 설정을 두면 무작정 수정하는 일을 크게 줄이고 로그에서 실제 변경 지점을 찾기도 쉬워집니다.