구독을 성공적으로 가져왔다는 것은 설정이 v2rayNG에 들어왔다는 뜻일 뿐입니다. 노드 이름이 목록에 표시되어도 현재 회선이 작동한다는 의미는 아닙니다. 첫 연결은 설정 확인, 노드 선별, 프록시 시작, 출구 확인의 네 단계로 나누어 진행해야 합니다. 각 단계마다 독립적인 판단 기준이 있습니다.
이 글에서는 v2rayNG 1.10.x의 일반적인 중국어 화면을 예로 듭니다. 세부 버전에 따라 메뉴 문구가 조금 달라질 수 있지만 핵심 판단 기준은 같습니다. 이미 가져온 VMess, VLESS 등의 노드를 대상으로 하며, 목록이 비어 있다면 먼저 구독을 추가하고 업데이트해야 합니다.
노드 목록은 확인했지만 어떤 노드를 골라야 할지 모르는 초보 사용자에게 적합합니다. 먼저 실제 연결 테스트로 후보 노드를 추린 다음 v2rayNG를 시작하고, 마지막으로 출구 IP와 웹 접속, 네트워크 전환 후 재테스트로 프록시가 실제로 적용되었는지 확인합니다. 아이콘은 켜졌지만 트래픽이 노드를 거치지 않는 경우도 함께 구분할 수 있습니다.
연결 전에 노드와 코어 확인하기
노드가 작동하는지는 클라이언트가 해당 프로토콜 필드를 이해하는지에 따라 먼저 결정됩니다. VMess 노드에는 일반적으로 서버 주소, 포트, 사용자 ID, 전송 방식과 TLS 설정이 포함됩니다. VLESS 노드에는 flow, Reality 공개 키, shortId, serverName 등의 매개변수가 추가될 수 있습니다. 핵심 필드가 빠졌거나 구독 변환 과정에서 잘못 바뀌면 연결 시간 초과로 나타날 수 있습니다.
대상 노드의 편집 화면을 열고 먼저 프로토콜 유형을 확인한 다음 주소와 포트를 대조합니다. 주소는 완전한 도메인 이름이거나 유효한 IP여야 하며, 포트는 1~65535 범위여야 합니다. 흔히 쓰이는 서버 포트로는 443, 8443, 2053 등이 있지만 포트 번호가 익숙하다고 해서 설정이 올바른 것은 아닙니다. 반드시 노드 정보를 기준으로 확인하세요.
Xray 코어
권장VLESS, Reality, XTLS Vision 및 일반적인 VMess 설정을 폭넓게 지원합니다. 구독에 최신 필드가 포함되어 있다면 이 항목을 우선 사용하세요.
적합한 용도: 일상적인 주력 사용, VLESS Reality, 혼합 프로토콜 구독
v2fly 코어
VMess, WebSocket, TLS 등 일반적인 조합을 중심으로 한 구형 설정에 적합합니다. Xray 전용 필드를 만났을 때 코어 비호환을 서버 오프라인으로 잘못 판단해서는 안 됩니다.
적합한 용도: 기존 VMess 설정, 호환성 비교 테스트
Xray를 주력 코어로 사용한다면 「설정」→「매개변수 설정」→「Core 유형」으로 이동해 현재 선택 항목이 Xray인지 확인하세요. 변경한 뒤에는 메인 화면으로 돌아와 연결을 한 번 다시 시작해야 새 코어가 실제로 로드됩니다. 옵션만 바꾸고 재연결하지 않으면 현재 세션에서 이전 상태가 계속 사용될 수 있습니다.
- VMess: 사용자 ID, alterId, 전송 방식과 TLS 스위치를 중점적으로 확인합니다. 최신 설정에서는 alterId가 일반적으로 0입니다.
- VLESS: 사용자 ID, flow, 암호화 항목, 전송 계층과 보안 계층을 중점적으로 확인합니다. VLESS 자체는 VMess의 alterId를 사용하지 않습니다.
- Reality: serverName, publicKey, shortId와 fingerprint를 중점적으로 확인하며, 필드가 서버 설정과 일치해야 합니다.
- WebSocket: path와 Host를 중점적으로 확인합니다. 경로 앞에 슬래시가 있는지도 설정의 일부입니다.
실제 연결 속도로 사용 가능한 노드 선별하기
지연 시간 수치는 먼저 테스트 방식을 구분해서 봐야 합니다. 일반 ping은 주로 ICMP 왕복 시간을 보여줍니다. 일부 서버는 ICMP를 제한하거나 무시하지만 프록시 포트에는 연결될 수 있습니다. v2rayNG 목록의 TCP 테스트도 대상 포트에 연결을 만들 수 있는지만 확인할 뿐, 프록시 프로토콜과 대상 요청을 끝까지 수행하지는 않습니다.
실제 연결 테스트는 노드 설정을 불러와 프로토콜 핸드셰이크와 프록시 경로를 거쳐 실제 요청을 보냅니다. 따라서 “웹페이지가 열리는가”에 더 가까운 결과를 얻을 수 있습니다. VLESS Reality, VMess TLS 또는 WebSocket 노드에서는 단순 ping보다 실제 연결 결과가 훨씬 유용합니다.
-
구독 업데이트
오른쪽 위 메뉴를 열고 「구독 업데이트」를 실행합니다. 노드 목록이 새로고침될 때까지 기다려 이미 제거되었거나 매개변수가 변경된 이전 설정을 계속 테스트하지 않도록 합니다.
-
코어 확인
「설정」→「매개변수 설정」→「Core 유형」으로 이동해 노드 필드와 호환되는 코어를 선택합니다. VLESS Reality는 보통 Xray를 선택합니다.
-
실제 연결 실행
메인 화면 메뉴에서 「모든 설정 실제 연결 테스트」를 선택합니다. 노드가 많다면 대상 노드를 길게 눌러 후보 3~5개를 각각 테스트할 수 있습니다.
-
후보 유지
두 번 연속 결과가 나오고 변동 폭이 작은 노드를 우선 남겨 두세요. 예를 들어 168ms와 191ms가 나온 노드는 120ms 뒤에 860ms로 튀는 노드보다 일반적으로 안정적입니다.
-
연결 후 재테스트
후보 노드를 선택해 연결을 시작한 다음 서로 다른 사이트 두 곳을 열어 보세요. 속도 테스트는 통과했지만 실제 브라우징이 실패한다면 라우팅, DNS와 앱 프록시 범위를 계속 확인해야 합니다.
전체 목록에서 가장 작은 값만 고르지 마세요. 한 번의 95ms는 우연한 결과일 수 있습니다. 182ms, 176ms, 189ms가 연속으로 나온 노드는 95ms, 640ms, 시간 초과가 나온 노드보다 일상적인 사용에 더 적합한 경우가 많습니다. 첫 선별에서는 300ms 이내이면서 연속 성공한 노드를 후보로 두고, 800ms를 넘거나 여러 번 실패한 노드는 우선순위를 낮추세요.
실제 연결 결과가 0, -1, 시간 초과 또는 빈 화면으로 표시되면 일반적으로 테스트에서 유효한 응답을 받지 못했다는 뜻입니다. 서버가 영구적으로 고장 났다는 의미는 아닙니다. 네트워크 전환, DNS 조회 실패, 시스템 시간 오차, 구독 필드 오류와 일시적인 혼잡도 같은 결과를 만들 수 있습니다. Wi-Fi와 모바일 네트워크에서 각각 한 번씩 다시 테스트한 뒤 노드 삭제 여부를 결정하세요.
연결을 시작하고 시스템 상태 이해하기
노드를 선택한 뒤 메인 화면 오른쪽 아래의 원형 연결 버튼을 누릅니다. 처음 시작하면 시스템에 네트워크 연결 권한 창이 표시됩니다. 승인하면 상태 표시줄에 보통 열쇠 모양 상태 아이콘이 나타나고, v2rayNG 메인 화면에도 연결됨 상태가 표시됩니다.
이 두 상태는 로컬 터널이 시작되었다는 사실만 보여 줄 뿐, 원격 노드가 정상적으로 작동한다는 것을 단독으로 증명하지는 않습니다. 클라이언트가 로컬 네트워크 인터페이스를 만들었어도 원격 핸드셰이크는 시간 초과될 수 있습니다. 또는 앱별 프록시나 라우팅 규칙 때문에 현재 브라우저 트래픽이 프록시로 들어가지 않을 수도 있습니다.
권장 방법: Wi-Fi와 모바일 네트워크를 각각 확인하기
Wi-Fi 환경
- 다른 프록시 도구를 종료한 뒤 연결하기
- 연결 전후 출구 IP 기록하기
- 서로 다른 도메인 두 곳 연속으로 열기
- 3분 동안 자동 연결 해제 여부 확인하기
모바일 네트워크 환경
- Wi-Fi를 끈 뒤 연결 다시 시작하기
- 실제 연결 테스트 다시 한 번 실행하기
- 웹페이지와 앱이 동시에 작동하는지 확인하기
- 1분간 화면을 잠근 뒤 웹페이지 다시 열기
두 네트워크 모두에서 출구 IP 변경과 웹 접속이 안정적으로 완료되어야 노드, 클라이언트 설정과 현재 라우팅 조합이 기본적으로 정상이라고 볼 수 있습니다.
현재 기기의 앱만 v2rayNG를 통해 연결하려는 경우 일반적으로 10808 또는 10809를 직접 입력할 필요가 없습니다. 시스템 권한 모드가 규칙에 맞는 트래픽을 처리합니다. 로컬 SOCKS와 HTTP 포트는 주로 다른 앱에서 프록시를 명시적으로 지정하거나 로컬 리스닝 상태를 디버깅할 때 사용합니다.
- 실제 연결 결과가 안정적인 노드를 하나 선택해 노드 이름이 선택된 상태가 되도록 합니다.
- 연결 버튼을 누르고 시스템 권한을 승인합니다. 권한 창이 표시된 상태에서 메인 화면으로 전환하지 마세요.
- 3~5초 기다린 뒤 실시간 트래픽에 업로드와 다운로드 수치가 나타나는지 확인합니다.
- 브라우저로 일반 웹페이지를 열고 이어서 출구 IP를 대조합니다.
- 곧바로 연결이 끊기면 로그 화면에서 첫 번째 error 또는 failed 기록을 확인합니다.
출구 IP와 웹 접속으로 적용 여부 확인하기
가장 직접적인 확인 방법은 연결 전후를 비교하는 것입니다. v2rayNG에 연결하기 전에 브라우저에서 “현재 IP”를 검색해 IP 주소, 국가 또는 지역, 통신사 이름을 기록하세요. 프록시를 시작한 뒤 같은 조회 페이지를 새로고침합니다. 출구 IP와 통신사 정보가 바뀌었다면 브라우저 트래픽이 원격 노드를 거친다는 뜻입니다.
국가나 지역만 보는 것은 정확하지 않습니다. 같은 네트워크도 데이터베이스에 따라 다른 도시로 표시될 수 있지만 주소 자체는 바뀌지 않을 수 있습니다. 먼저 전체 IP를 비교하고 그다음 ASN 또는 통신사를 비교하세요. 예를 들어 연결 전에는 가정용 인터넷 통신사로 표시되다가 연결 후 데이터센터 네트워크로 바뀌고 IP 주소도 완전히 달라졌다면 유효한 증거입니다.
before_ip
연결 전 출구
v2rayNG를 끈 뒤 조회해 기록합니다. 로컬 네트워크의 원래 출구를 확인하는 과정이므로 기억에 의존하지 마세요.
after_ip
연결 후 출구
연결을 시작한 뒤 조회 페이지를 다시 불러옵니다. 주소는 연결 전과 달라야 하며 선택한 노드의 대략적인 위치와도 일치해야 합니다.
web_access
웹 접속
서로 다른 도메인을 최소 두 곳 테스트해 단일 웹사이트 장애, 캐시된 페이지 또는 일시적인 속도 제한을 프록시 문제로 오해하지 않도록 합니다.
reconnect
재연결 테스트
연결을 끊은 뒤 5초 기다렸다가 다시 연결합니다. 두 번 연속 접속이 완료되는 결과가 우연한 한 번의 성공보다 신뢰할 수 있습니다.
웹페이지가 열린다고 해서 모든 앱이 프록시를 사용한다는 뜻은 아닙니다. 앱별 프록시를 활성화했다면 브라우저가 허용 목록에 있는지 확인하세요. 로컬 네트워크와 국내 영역을 우회하는 라우팅 규칙을 사용 중이라면 일부 사이트가 규칙에 따라 직접 연결되는 것은 정상입니다. 이때는 노드를 거쳐야 하는 테스트 페이지로 바꾼 뒤 출구를 다시 비교하세요.
실패 양상도 관찰할 수 있습니다. 웹페이지에서 즉시 도메인 조회 실패가 표시되면 DNS를 먼저 확인하세요. 오래 로딩한 뒤 시간 초과가 발생하면 원격 노드와 전송 매개변수를 먼저 확인합니다. 특정 앱만 인터넷에 연결되지 않으면 앱별 프록시와 해당 앱의 백그라운드 네트워크 권한을 먼저 확인하세요. 모든 웹페이지가 열리지만 IP가 바뀌지 않는다면 라우팅 모드가 테스트 트래픽을 직접 연결로 분류했는지 확인해야 합니다.
| 결과 확인 | 확인 가능한 상태 | 다음 단계 |
|---|---|---|
| IP 변경, 웹페이지 두 곳 모두 접속 가능 | 프록시가 기본적으로 적용됨 | 안정성과 속도를 계속 확인 |
| 연결됨으로 표시되지만 IP가 바뀌지 않음 | 트래픽이 직접 연결될 수 있음 | 라우팅 모드와 앱별 적용 범위 확인 |
| IP는 바뀌지만 웹페이지가 자주 시간 초과됨 | 노드 핸드셰이크는 가능하지만 품질이 불안정함 | 변동 폭이 작은 후보 노드로 변경 |
| 모든 도메인에서 즉시 조회 실패 | DNS 경로에 문제가 있을 수 있음 | 기본 DNS로 되돌린 뒤 재연결 |
라우팅 분기와 로컬 포트 확인 방법
라우팅 분기는 요청을 프록시, 직접 연결 또는 차단 중 어디로 보낼지 결정합니다. 첫 검증 단계에서 규칙이 복잡할수록 확인해야 할 변수가 많아집니다. 먼저 v2rayNG의 일반 사전 설정으로 연결을 확인하고, 노드가 작동하는 것을 확인한 뒤 사용자 지정 도메인, IP 또는 앱 규칙을 활성화하는 것이 좋습니다.
전역 프록시는 짧은 진단에 적합합니다. 프록시로 보낼 수 있는 대부분의 트래픽을 선택한 노드로 전달해 노드 자체의 작동 여부를 판단하기 쉽습니다. 분할 라우팅은 일상적인 사용에 더 적합합니다. 로컬 네트워크, 국내 영역 또는 지정 앱은 직접 연결하고 나머지 트래픽은 규칙에 따라 프록시로 보낼 수 있습니다. 둘의 차이는 라우팅 전략에 있으며 프로토콜의 우열을 의미하지 않습니다.
- 브라우저만 실패하는 경우: 앱별 프록시 목록을 확인해 브라우저가 제외되지 않았는지 확인합니다.
- 로컬 네트워크 기기에 접속할 수 없는 경우: 192.168.0.0/16과 같은 사설 주소 대역을 잘못 프록시 처리하고 있지 않은지 확인합니다.
- 국내 사이트가 느려진 경우: 현재 전역 프록시를 사용 중인지 확인하고 필요하면 일반적인 분할 라우팅으로 되돌립니다.
- 앱에 프록시를 수동 입력한 경우: 먼저 로컬 리스닝 포트를 확인합니다. 일반적인 SOCKS 진입 포트는 10808이지만 구체적인 값은 「설정」→「매개변수 설정」의 로컬 포트를 기준으로 삼으세요.
- 로그에 포트 사용 중이라고 표시되는 경우: 같은 포트를 사용하는 앱을 종료하거나 로컬 포트를 사용되지 않는 값으로 바꿉니다. 예를 들어 10818로 변경한 뒤 저장하고 다시 연결하세요.
포트 충돌은 기기 내부에서 발생하며 구독 노드의 원격 포트와는 다른 개념입니다. 원격 443은 서버가 연결을 받는 포트이고, 로컬 10808은 기기에서 앱이 프록시 코어에 연결하는 진입점입니다. 로컬 포트를 바꿔도 잘못된 원격 443 설정이 수정되거나 서버의 리스닝 상태가 변경되지는 않습니다.
첫 연결에서 자주 발생하는 문제를 순서대로 해결하기
실패했을 때 수십 개 노드 사이를 바로 반복해서 전환하지 마세요. 먼저 기기의 시스템 시간이 자동 동기화로 설정되어 있는지 확인한 다음 구독을 업데이트하고 실제 연결 테스트를 실행합니다. 시스템 시간 오차가 크면 TLS와 Reality 핸드셰이크에 영향을 주며, 겉으로는 연결 시간 초과처럼 보이는 경우가 많습니다.
로그는 첫 번째 실패가 발생한 지점부터 아래로 읽어야 합니다. 흔한 키워드로는 timeout, connection refused, failed to find an available destination 및 DNS 조회 오류가 있습니다. 로그의 원격 주소, 포트, 전송 방식은 노드 편집 화면의 정보와 일치해야 합니다. 구독 업데이트 후 필드가 바뀌었다면 새 설정으로 다시 테스트하세요.
실제 연결에는 수치가 나오는데 연결 후 웹페이지가 열리지 않는 이유는 무엇인가요?
현재 선택된 노드가 방금 테스트에 성공한 노드인지 먼저 확인한 뒤 라우팅을 일반 사전 설정으로 되돌립니다. 앱별 프록시를 끄고 다시 연결한 다음 5초 기다렸다가 서로 다른 도메인 두 곳에서 재테스트하세요. 출구 IP가 여전히 바뀌지 않는다면 테스트 브라우저가 규칙상 직접 연결로 지정되어 있지 않은지 확인합니다.
목록의 모든 노드가 시간 초과로 표시되면 어떻게 하나요?
시스템의 자동 날짜와 시간대 설정을 켜고 Wi-Fi와 모바일 네트워크를 한 번 전환한 다음 「구독 업데이트」를 실행합니다. 「설정」→「매개변수 설정」→「Core 유형」으로 이동해 Xray를 사용 중인지 확인한 뒤 서로 다른 프로토콜의 노드 3개를 테스트하세요. 모두 실패한다면 구독 유효 상태와 노드 필드를 확인해야 합니다.
지연 시간이 80ms에 불과한데 실제 웹페이지가 느리게 열리는 이유는 무엇인가요?
낮은 지연 시간은 한 번의 응답이 빠르다는 뜻일 뿐 대역폭이 충분하다는 의미는 아닙니다. 페이지 리소스를 연속으로 다운로드할 때는 패킷 손실, 혼잡과 서버 부하의 영향도 받습니다. 같은 노드를 세 번 연속 테스트하고 이미지가 포함된 웹페이지도 실제로 불러오세요. 결과가 80ms에서 900ms까지 크게 변한다면 지연 시간은 조금 높아도 더 안정적인 노드로 바꾸세요.
연결 버튼은 켜져 있는데 조회한 IP가 여전히 기존 IP인 이유는 무엇인가요?
현재 라우팅에서 조회 사이트를 직접 연결로 보내고 있지 않은지 확인하고, 브라우저가 앱별 프록시 적용 범위에 포함되어 있는지도 확인합니다. 사용자 지정 규칙을 일시적으로 끄고 다시 연결한 뒤 조회하세요. 다른 앱의 출구가 이미 바뀌었다면 문제는 일반적으로 노드 핸드셰이크가 아니라 앱 범위나 도메인 규칙에 있습니다.
Wi-Fi에서 모바일 네트워크로 전환한 뒤 연결이 끊기는 것이 정상인가요?
하위 네트워크가 바뀌면 기존 연결이 끊길 수 있습니다. 네트워크 전환 후 3~5초 기다리세요. 자동으로 복구되지 않으면 수동으로 연결을 끊었다가 다시 연결하고 출구 IP를 재조회합니다. 네트워크를 자주 전환한다면 시스템이 코어 프로세스를 일시 중지하지 않도록 v2rayNG의 백그라운드 실행을 허용해야 합니다.
완전한 성공 기준은 네 가지를 모두 충족하는 것입니다. 실제 연결에서 연속으로 유효한 결과가 나오고, 클라이언트가 연결 상태를 유지하며, 출구 IP가 예상대로 바뀌고, 서로 다른 사이트를 최소 두 곳 안정적으로 접속할 수 있어야 합니다. 이 중 하나만 충족해서는 문제 해결을 끝내기에 부족합니다.
첫 검증을 마친 뒤에는 품질이 안정적인 노드 두 개를 주력과 예비용으로 저장해 두세요. 일상적으로 갑자기 느려졌을 때는 전체 구독을 다시 테스트하기보다 이 두 노드를 서로 비교하는 것이 좋습니다. 이렇게 하면 로컬 네트워크 변동, 단일 노드 혼잡과 구독 전체 문제를 더 쉽게 구분할 수 있습니다.