v2rayN을 처음 실행했거나 업데이트 후 기능 메뉴를 찾지 못하는 사용자를 위해, v2rayN 7.15.4 화면을 기준으로 메뉴 모음, 구독 그룹, 서버 목록, 실행 로그와 설정의 역할을 차례로 설명합니다. 현재 노드의 그룹, 사용 중인 노드, 연결 실패 시 확인할 로그, Core 유형과 로컬 포트의 확인 위치를 파악할 수 있습니다.
먼저 메인 창의 기능 지도를 익히기
화면 핵심
v2rayN 메인 창은 작업 순서에 따라 다섯 영역으로 이해할 수 있습니다. 상단 메뉴는 명령을 실행하고, 구독 그룹은 설정 출처를 나누며, 서버 목록은 노드를 표시하고 선택합니다. 로그 영역은 실행 과정을 알리고, 하단 상태 영역은 현재 프록시 모드, 활성 서버와 로컬 수신 포트를 보여줍니다. 문제를 확인할 때는 모든 메뉴를 반복해서 오가기보다 이 흐름을 따라가며 점검하는 편이 효율적입니다.
화면 핵심
7.x의 세부 버전에 따라 아이콘 위치나 메뉴 이름은 달라질 수 있지만 데이터 관계는 대체로 같습니다. 구독 그룹은 노드가 아니며, 노드가 곧 실행 중인 아웃바운드인 것도 아닙니다. 목록의 설정 하나를 활성 서버로 지정하고 해당 Core를 실행해야만 그 설정이 연결에 사용됩니다. 시스템 프록시가 켜져 있는지는 브라우저 같은 프로그램이 트래픽을 v2rayN으로 전달할 수 있는지를 결정하는 별도의 스위치입니다.
메인 창을 읽는 두 가지 경로
일상적인 연결 경로
- 올바른 구독 그룹 선택
- 실제 연결 지연 시간 테스트 실행
- 활성 서버로 지정
- 시스템 프록시 모드 확인
문제 해결 경로
- 활성 서버 이름 확인
- Core 시작 로그 확인
- 10808, 10809 포트 점검
- 라우팅 및 DNS 기록 확인
일상적인 작업은 그룹에서 상태 표시줄로 진행하고, 문제 해결은 상태 표시줄에서 서버 설정과 Core 로그를 거슬러 올라가며 확인합니다.
화면 핵심
메뉴 모음의 「서버」는 단일 설정을 추가, 수정, 삭제, 가져오기 또는 활성 서버로 지정하는 작업을 담당합니다. 「구독 그룹」에서는 구독 주소와 업데이트를 관리하고, 「설정」에는 시스템 프록시, 라우팅, 설정값과 Core 관련 옵션이 모여 있습니다. 처음에는 이 세 가지 메뉴만 기억해 두면 충분하며, 내보내기나 백업 또는 버전 정보를 확인할 때 다른 메뉴를 사용하면 됩니다.
서버 목록의 각 열은 무엇을 의미할까
화면 핵심
서버 목록은 설정 목록이며, 각 행은 Core가 읽을 수 있는 하나의 아웃바운드 설정에 해당합니다. 주소, 포트, 프로토콜과 전송 방식은 구독 또는 수동 입력에서 가져오고, 지연 시간과 속도 같은 값은 이 컴퓨터에서 테스트한 결과입니다. 테스트 수치는 노드 품질을 영구적으로 나타내지 않습니다. 네트워크 경로, 서버 부하와 테스트 시점이 바뀌면 값도 달라집니다.
화면 핵심
「별칭」은 보통 구독 제공자가 입력한 노드 이름으로, 지역·회선·용도를 식별하는 데 사용합니다. 「주소」는 원격 호스트 이름 또는 IP이고, 「포트」는 원격 서비스가 수신 대기하는 포트입니다. 로컬 10808과 혼동하지 마세요. 「네트워크」에는 tcp, ws, grpc 같은 전송 방식이 표시될 수 있으며, 「보안」에는 tls, reality 또는 none이 표시될 수 있습니다. VMess, VLESS 같은 프로토콜과 전송 계층 필드는 함께 확인해야 하며, 어느 한 열만으로는 전체 연결 조건을 알 수 없습니다.
| 목록 필드 | 표시 내용 | 문제 해결 시 용도 |
|---|---|---|
| 별칭 | 노드 이름 및 회선 표시 | 현재 선택한 행이 대상 지역 또는 그룹에 속하는지 확인 |
| 주소 / 포트 | 원격 서버 접속 지점 | 이름 해석 실패, 포트 연결 불가 또는 구독 데이터 이상 식별 |
| 프로토콜 | VMess, VLESS 등의 아웃바운드 프로토콜 | 어떤 Core와 프로토콜 매개변수 조합으로 처리할지 판단 |
| 전송 / 보안 | TCP, WebSocket, gRPC, TLS, Reality 등의 조합 | 경로, SNI, 지문, Flow 등 추가 필드 확인 |
| 실제 연결 지연 시간 | 프록시 핸드셰이크 후 측정한 응답 시간 | 일반 ping보다 실제 프록시 연결에 드는 비용을 더 잘 반영 |
| 속도 | 다운로드 테스트 단계에서 측정한 처리량 | 저지연 노드와 고대역폭 노드를 구분 |
화면 핵심
예를 들어 같은 그룹의 두 설정에서 실제 연결 지연 시간이 각각 186ms와 312ms라면, 앞의 설정이 일반적인 웹 탐색에 더 적합한 경우가 많습니다. 다운로드 속도가 각각 4.8MB/s와 12.4MB/s라면 뒤의 설정은 대용량 파일 전송에 더 유리할 수 있습니다. 지연 시간과 대역폭은 서로 다른 지표이므로 한 열만 기준으로 정렬한 뒤 노드를 영구적으로 고정하지 마세요.
화면 핵심
행을 선택한 뒤 「활성 서버로 지정」을 실행하면 일반적으로 화면의 강조 표시, 색상 또는 상태 표시줄 문구로 현재 설정을 알려줍니다. 행을 마우스로 한 번 클릭하는 것만으로는 보통 선택만 될 뿐 Core가 전환되었다고 볼 수 없습니다. 전환 후에는 하단에 표시된 활성 서버 이름을 확인하고, 로그에 새로운 아웃바운드 설정이 로드되었다는 기록이 있는지 살펴보세요.
구독 그룹으로 노드 구성하기
화면 핵심
구독 그룹은 구독 주소, 업데이트 규칙과 해당 출처에서 생성된 서버 목록을 저장합니다. 하나의 그룹에 여러 노드 설정을 넣을 수 있고 업데이트 방식도 개별적으로 지정할 수 있습니다. 업무용, 테스트용과 예비 회선을 서로 다른 그룹에 나누면 모든 노드를 하나의 긴 목록에 몰아넣는 것보다 문제를 찾기 쉽고, 실수로 삭제하거나 전환할 가능성도 줄어듭니다.
화면 핵심
구독을 업데이트하면 v2rayN이 구독 내용을 요청하고 지원되는 설정을 파싱합니다. 업데이트 성공은 클라이언트가 구독 데이터를 가져와 처리했다는 뜻일 뿐, 모든 노드가 연결된다는 의미는 아닙니다. 업데이트 후에는 먼저 목록의 개수와 별칭이 바뀌었는지 확인한 다음 대상 그룹에서 실제 연결 테스트를 실행하세요. 그룹을 바꾼 뒤 목록이 비어 있다면 구독을 바로 다시 추가하기보다 필터 조건부터 확인해야 합니다.
-
현재 그룹 확인
화면 핵심
메인 창의 구독 그룹 영역에서 대상 그룹을 선택하고, 업데이트 전 노드 수를 먼저 기록합니다. 예를 들어 18개로 기록해 두면 다른 출처의 목록을 업데이트 결과로 잘못 판단하는 일을 막을 수 있습니다.
-
구독 설정 확인
화면 핵심
「구독 그룹」→「구독 그룹 설정」으로 이동해 활성화 상태, 메모와 구독 주소의 대응 관계를 확인합니다. 이름이 같은 그룹은 메모로 추가 구분해야 합니다.
-
그룹 업데이트 실행
화면 핵심
「구독 그룹」→「현재 구독 업데이트」를 선택하고 상태 안내가 완료될 때까지 기다립니다. 모든 출처를 새로 고치려면 「모든 구독 업데이트」를 실행하세요.
-
유효한 설정 테스트
화면 핵심
서버 목록에서 대상 행을 선택하고 실제 연결 지연 시간 테스트를 실행합니다. 186ms 같은 구체적인 결과가 나오면 전체 프록시 핸드셰이크가 성공했다는 뜻이며, 값이 비어 있거나 시간 초과가 발생하면 로그를 확인해야 합니다.
-
Core 유형 확인
화면 핵심
「설정」→「설정」→「Core 유형」경로로 Core 선택 영역에 들어가 대상 프로토콜이 Xray 또는 v2fly에 할당되어 있는지 확인합니다. 저장한 뒤 Core를 다시 시작하세요.
화면 핵심
업데이트 후 노드 수가 줄었다고 해서 반드시 파싱 오류인 것은 아닙니다. 구독 출처에서 회선을 조정했을 수도 있습니다. 노드 수, 별칭과 프로토콜 열을 비교하고 업데이트 로그에 인식할 수 없는 설정 유형이 나타났는지 확인하세요. 구독으로 생성된 노드를 수동으로 수정할 때는 다음 업데이트에서 변경 사항이 덮어써질 수 있다는 점도 유의해야 합니다. 장기간 유지할 사용자 지정 설정은 별도 그룹에 두는 편이 좋습니다.
로그 패널에서 확인할 정보
화면 핵심
로그는 모든 줄을 읽는 데 의미가 있는 것이 아니라 연결 흐름이 어느 단계에서 멈췄는지 확인하는 데 가치가 있습니다. 시작 단계에서는 설정이 정상적으로 로드되었는지, Core 프로세스가 실행 중인지, 로컬 포트가 수신 대기 중인지 먼저 확인합니다. 접속 단계에서는 DNS, 라우팅 일치와 원격 연결 결과를 살펴봅니다. 첫 단계에서 이미 실패했다면 브라우저 프록시나 라우팅 규칙을 계속 조정해도 문제가 해결되지 않는 경우가 많습니다.
화면 핵심
정상적인 시작 순서는 대체로 다음과 같습니다. v2rayN이 실행 설정을 생성하고, Xray 또는 v2fly Core를 시작하며, 로컬 수신 주소가 생성된 뒤 애플리케이션 트래픽이 127.0.0.1로 들어옵니다. 이전 버전에서는 SOCKS 포트가 10808, HTTP 포트가 10809인 경우가 많았습니다. 일부 7.x 설정은 혼합 수신 방식을 사용하므로 최종적으로는 「설정」→「설정」에 표시된 로컬 포트를 기준으로 삼아야 합니다.
시작 점검 예시
Core: Xray
SOCKS: 127.0.0.1:10808
HTTP: 127.0.0.1:10809
Active server: HK-02 VLESS Reality
Routing: domainStrategy = AsIs
Test result: true connection latency 186 ms- 포트 충돌: 로그에 bind, address already in use 또는 수신 대기 실패가 나타나면 10808, 10809을 점유한 이전 프로세스를 먼저 종료하거나 설정에서 사용하지 않는 포트로 변경하세요.
- 도메인 이름 해석: resolve, DNS timeout 등의 기록이 나타나면 DNS 설정과 현재 네트워크의 기본 이름 해석 가능 여부를 확인한 뒤 조회 방식을 조정할지 판단하세요.
- 원격 연결 시간 초과: connection timeout, context deadline exceeded가 나타나면 같은 그룹의 다른 노드를 다시 테스트해 단일 노드 장애인지 로컬 네트워크 문제인지 구분하세요.
- 인증 실패: 기록이 사용자 식별자, 키, Reality 공개 키 또는 shortId를 가리킨다면 구독을 다시 업데이트하고 설정 필드를 대조하세요. 속도 테스트를 반복해도 매개변수 오류는 수정되지 않습니다.
- 라우팅 거부: 연결이 block 아웃바운드에서 처리된다면 규칙의 일치 순서와 inboundTag, domain, ip, outboundTag의 대응 관계를 확인하세요.
화면 핵심
로그의 warning이 항상 연결을 중단시키는 것은 아닙니다. 일부 호환 설정이 무시되어도 Core는 정상적으로 수신 대기할 수 있습니다. 프로세스 종료, 설정 파싱 실패 또는 수신 대기를 일으키는 error를 우선 처리해야 합니다. 시작 시각 주변의 첫 번째 핵심 오류를 먼저 찾고, 그 오류로 이어진 후속 오류를 확인하는 순서가 좋습니다.
화면 핵심
문제를 재현할 때는 이전 로그를 지우거나 현재 시간을 기록한 뒤 대상 동작을 한 번만 실행하세요. 예를 들어 14:32:10에 노드를 전환하고 14:32:15에 테스트 페이지를 열었다면 해당 시간대의 기록을 집중적으로 확인합니다. 이렇게 하면 몇 시간 전의 시간 초과 기록을 현재 문제로 잘못 판단하는 일을 피하고, 전환 전후의 활성 서버와 라우팅 결과도 비교하기 쉽습니다.
Core 설정 메뉴와 핵심 매개변수 4가지
화면 핵심
v2rayN의 자주 쓰는 스위치가 모두 서버 편집 창에 있는 것은 아닙니다. 개별 서버 편집 화면은 원격 프로토콜 설정을 담당하고, 로컬 수신 포트, Core 유형, 로그 수준과 일부 DNS 동작은 「설정」→「설정」에 있습니다. 시스템 프록시 모드와 라우팅 모드는 더 상위 단계의 트래픽 진입점 및 분기 제어이므로, 변경할 때 어느 계층을 조정하는지 분명히 해야 합니다.
화면 핵심
Core 유형은 어떤 Core가 설정을 처리할지 결정합니다. v2rayN 데스크톱 버전은 VLESS, Reality 등의 설정을 처리할 때 Xray를 주로 사용하며, 프로토콜 매핑에 따라 v2fly를 선택할 수도 있습니다. Core 유형을 변경한 뒤에는 설정을 저장하고 Core를 다시 시작한 다음 로그에서 실제로 시작된 Core 이름을 확인하세요. 드롭다운만 바꾸고 재시작하지 않으면 현재 프로세스가 이전 설정을 계속 사용할 수 있습니다.
로컬 프록시 진입점
- SOCKS 주소
- 127.0.0.1
- SOCKS 포트
- 10808
- HTTP 포트
- 10809
- 용도
- 로컬 애플리케이션 트래픽 수신
포트는 설정에 표시된 실제 값을 기준으로 하며, 브라우저에서 수동 프록시를 설정할 때 같은 포트를 입력해야 합니다.
Core 유형
- 메뉴 경로
- 설정 → 설정
- 주로 사용하는 Core
- Xray
- 선택 가능한 Core
- v2fly
- 적용 방법
- 저장 후 Core 다시 시작
선택 결과는 서버 프로토콜 및 전송 매개변수와 일치해야 하며, 시작 로그로 다시 확인해야 합니다.
시스템 프록시 모드
- 끔
- 시스템 프록시를 변경하지 않음
- 자동 설정
- 규칙에 따라 트래픽 전달
- 전역
- 시스템 트래픽을 로컬 프록시로 전달
- 확인 위치
- 메인 창 상태 영역
Core가 실행 중인데 웹 페이지가 직접 연결된다면 먼저 시스템 프록시 모드가 예상대로 설정되어 있는지 확인하세요.
로그 및 라우팅
- 로그 수준
- warning / info
- 문제 해결 수준
- info
- 도메인 정책
- AsIs
- 규칙 핵심 항목
- outboundTag
문제 해결이 끝나면 평소 사용하는 로그 수준으로 되돌리고, 라우팅을 변경한 뒤에는 대상 도메인으로 실제 동작을 확인하세요.
화면 핵심
시스템 프록시, Core 유형과 라우팅 모드는 서로 연결된 흐름을 이룹니다. 애플리케이션이 먼저 요청을 로컬 프록시 포트로 전달하면 Core가 서버 설정을 읽고, 마지막으로 라우팅 규칙에 따라 직접 연결, 프록시 또는 차단 아웃바운드를 선택합니다. 특정 웹 페이지가 열리지 않을 때는 이 순서대로 원인을 찾아야 합니다. Core 유형을 바로 바꾸는 것은 표면적인 현상만 바꿀 뿐, 포트·노드·규칙의 실제 오류를 해결하지 못할 때도 있습니다.
메인 화면의 자주 묻는 질문과 빠른 판단
화면 핵심
화면에 익숙해지면 대부분의 문제를 먼저 네 가지로 분류할 수 있습니다. 그룹이 업데이트되지 않았거나, 노드가 활성 서버로 지정되지 않았거나, Core가 정상적으로 수신 대기하지 않거나, 시스템 트래픽이 로컬 프록시로 들어오지 않는 경우입니다. 먼저 범주를 정한 뒤 설정을 바꾸는 편이 노드를 계속 교체하거나 구독을 반복해서 가져오는 것보다 재현 가능한 결과를 얻기 쉽습니다.
노드를 두 번 클릭했는데 왜 이전 회선이 그대로인가요?
화면 핵심
먼저 하단 상태 영역에 표시된 활성 서버 이름을 확인하세요. 바뀌지 않았다면 대상 행을 마우스 오른쪽 버튼으로 클릭해 「활성 서버로 지정」을 실행한 뒤 Core를 다시 시작하고, 로그에서 새 설정이 로드되었는지 확인합니다.
구독 업데이트는 성공했는데 왜 목록이 바뀌지 않나요?
화면 핵심
현재 보고 있는 그룹이 방금 업데이트한 그룹인지 확인하고 목록 필터를 해제하세요. 업데이트 전후 노드 수를 기록해 비교합니다. 예를 들어 모두 18개이고 수와 별칭도 바뀌지 않았다면 구독 내용 자체가 변경되지 않았을 수 있습니다.
실제 연결 지연 시간이 비어 있으면 어디를 봐야 하나요?
화면 핵심
먼저 Core가 실행 중인지 확인한 다음 테스트 시간대의 DNS, 연결 시간 초과와 인증 기록을 살펴보세요. 10808 수신 대기에 실패했다면 지연 시간 테스트를 하기 전에 포트 충돌부터 해결해야 합니다.
Core는 실행 중인데 브라우저는 계속 직접 연결되는 이유가 무엇인가요?
화면 핵심
시스템 프록시 모드와 브라우저 자체의 프록시 설정을 확인하세요. 수동으로 설정할 때 SOCKS는 127.0.0.1:10808을 가리켜야 하고, HTTP는 설정에 표시된 포트를 입력해야 합니다. 원격 서버 포트와 혼용하면 안 됩니다.
라우팅 모드를 전환한 뒤 적용 여부를 어떻게 확인하나요?
화면 핵심
Core를 다시 시작한 뒤 직접 연결과 프록시 연결이 예상되는 대상을 각각 방문하고, info 수준 로그에서 일치한 outboundTag를 확인하세요. 모든 요청이 같은 아웃바운드로 들어간다면 규칙 순서와 기본 처리 규칙의 위치를 점검합니다.
화면 핵심
마지막으로 다음 고정 순서로 메인 창을 점검할 수 있습니다. 그룹 확인, 노드 선택, 실제 연결 테스트 실행, 활성 서버 지정, 시스템 프록시 확인, 대상 페이지 열기, 해당 시간대의 로그 확인입니다. 각 단계에서 화면상 명확한 결과를 확인할 수 있으므로 이상이 생기면 현재 계층에서 처리를 멈출 수 있고, 구독·포트·Core·라우팅을 동시에 변경할 필요가 없습니다.