Windows에서 v2rayN을 처음 설정하거나 WPF에서 Desktop 인터페이스로 옮기려는 사용자를 위한 안내입니다. 먼저 프로세서 아키텍처와 런타임을 확인한 뒤 압축 해제, 구독 업데이트, 시스템 프록시 설정을 진행합니다. 마지막으로 로컬 포트, 코어 로그, 브라우저 요청을 이용해 문제를 진단합니다. 포트 번호는 설명을 위한 예시이므로 실제 설정은 클라이언트에 표시된 값을 사용하세요. 노드 매개변수를 그대로 따라 입력할 필요는 없습니다.
1. WPF와 Desktop: 인터페이스를 고르고 아키텍처 확인하기
v2rayN은 노드, 구독, 라우팅, 로컬 프록시를 관리하는 데스크톱 클라이언트입니다. 실제 네트워크 연결은 클라이언트가 호출하는 코어가 처리합니다. WPF와 Desktop은 주로 인터페이스 구현과 플랫폼 지원 방식이 다를 뿐, 서로 다른 노드 프로토콜을 뜻하지 않습니다. 같은 구독을 사용할 수 있는지는 노드 매개변수, 선택한 코어, 서버 설정에 따라 달라지므로 창 모양만으로 판단할 수 없습니다.
Desktop 버전
추천처음 설정한다면 다운로드 페이지에서 Windows 아키텍처에 맞는 Desktop 버전을 선택해 시작할 수 있습니다. 크로스 플랫폼 인터페이스를 사용하므로 기존 WPF와 컨트롤 위치가 다를 수 있습니다. 튜토리얼 화면과 다르면 버튼 위치를 그대로 따라가기보다 설정 항목의 이름을 찾아보세요.
추천 대상: 처음 설치하거나 크로스 플랫폼 인터페이스에 익숙해지고 싶은 사용자.
WPF 버전
기존 Windows 인터페이스를 그대로 사용하고 싶은 경우에 적합합니다. WPF가 구형 프로토콜 전용 버전이라고 생각하지 마세요. 인터페이스를 바꾸려고 실행 중인 프로그램 폴더에 파일을 덮어쓰는 것도 피해야 합니다. 이전하기 전 기존 프로그램을 종료하고 설정을 백업하세요.
추천 대상: WPF 사용 방식에 익숙하거나 기존 인터페이스를 기준으로 한 튜토리얼을 참고하려는 사용자.
Windows에서 ‘설정’ → ‘시스템’ → ‘시스템 정보’를 열고 ‘시스템 종류’를 확인하세요. 일부 시스템에서는 마지막 항목이 ‘정보’로 표시됩니다. 일반적인 Intel 및 AMD PC는 대개 x64를 선택하며, Windows on ARM 기기는 ARM64 패키지인지 먼저 확인하세요. 프로세서 브랜드만으로 판단하지 말고 시스템에 표시된 아키텍처와 다운로드 페이지의 안내를 따르세요.
- 먼저 아키텍처를 확인하세요:x64와 ARM64 패키지는 파일 크기만 보고 서로 바꿔 쓸 수 없습니다. 아키텍처가 맞지 않으면 프로그램이나 코어가 시작되지 않을 수 있습니다.
- 다음으로 패키지 구성을 확인하세요:런타임이 포함되어 있는지, 필요한 코어가 들어 있는지는 현재 릴리스 안내를 확인하세요. 파일 이름에 특정 약어가 있는지만 보고 구성을 단정하지 마세요.
- 마지막으로 시스템 요구 사항을 확인하세요:구형 Windows가 현재 클라이언트와 런타임 요구 사항을 충족하지 못할 수 있습니다. 같은 패키지를 반복해서 내려받는다고 호환성 문제가 해결되지는 않습니다.
2. 압축 해제와 첫 실행: 폴더 구성을 그대로 유지하기
사이트의 클라이언트 다운로드 페이지에서 Windows 다운로드 항목을 선택하세요. 압축 파일을 받았다면 먼저 전체 압축을 해제한 뒤 실행해야 합니다. 압축 프로그램의 미리보기 창에서 실행 파일을 바로 열면 코어, 설정 파일, 종속 라이브러리가 임시 폴더에 남을 수 있습니다. 이 경우 창은 열려도 연결되지 않을 수 있습니다.
-
폴더 준비
일반 사용자 계정으로 쓸 수 있는 별도 폴더를 만드세요. 예:
D:\Tools\v2rayN. D 드라이브가 없다면 사용자 폴더 안에 만들면 됩니다. 추가 쓰기 권한이 필요한 시스템 폴더는 피하세요. -
전체 압축 해제
압축 파일의 모든 내용을 풀고 기존 하위 폴더 구조를 유지하세요.
v2rayN.exe만 따로 꺼내지 말고, 아키텍처나 인터페이스가 다른 파일을 한 폴더에 섞지 마세요. -
프로그램 실행
v2rayN.exe를 실행하세요. 일반적인 시스템 프록시 사용에는 보통 관리자 권한이 필요하지 않습니다. 처음 설정할 때는 권한 및 가상 네트워크 어댑터 변수를 줄이기 위해 TUN을 꺼 두세요. -
런타임 설치
.NET이 없다는 팝업이 표시되면 프레임워크 이름, 주 버전, 아키텍처를 확인한 뒤 안내에 맞는 런타임을 설치하세요. 설치가 끝나면 클라이언트를 다시 실행하세요. SDK만 설치했다고 필요한 종속성이 모두 갖춰지는 것은 아닙니다.
-
로그 확인
메인 창이 정상적으로 열리는지 확인한 다음 로그 영역에서 코어 누락, 시작 실패, 설정 파싱 오류가 있는지 살펴보세요. 이 단계에서 구독 노드가 아직 없는 것은 정상이며, 설치 실패를 뜻하지 않습니다.
3. 구독 가져오기: 주소 저장과 노드 업데이트 구분하기
구독 링크는 보통 노드 설정을 가져오는 데 사용합니다. 로컬 프록시 주소가 아니며 Windows의 ‘프록시 서버’ 입력란에 그대로 넣는 값도 아닙니다. 링크에 포함된 토큰은 개인 계정과 연결될 수 있으므로 스크린샷, 로그 공유, 원격 지원 시 전체 주소가 노출되지 않도록 가리세요.
- 메인 화면에서 ‘구독 그룹 설정’을 여세요. 인터페이스에 따라 ‘구독 그룹’ 메뉴에 항목이 있을 수 있습니다. ‘추가’를 선택하고 알아보기 쉬운 이름과 전체 구독 주소를 입력한 다음 저장하세요.
- ‘구독 그룹’ 메뉴로 돌아가 ‘모든 구독 업데이트(프록시 사용 안 함)’를 선택해 처음으로 가져오세요. 인터페이스에 따라 괄호 안 문구가 생략될 수 있으므로 로컬 프록시를 거치지 않는 업데이트 방식을 선택해야 합니다.
- 업데이트가 끝나면 현재 그룹 필터와 검색창을 확인해 노드가 필터링되지 않았는지 살펴보세요. 구독 주소를 저장했다고 해서 노드가 정상적으로 내려받아진 것은 아닙니다.
- 노드를 하나 선택하고 마우스 오른쪽 버튼 메뉴에서 ‘활성 서버로 설정’을 선택하세요. 상태 표시줄이나 현재 노드 표시가 바뀌었는지 확인한 뒤 프록시를 테스트하세요.
현재 네트워크에서 구독 서버에 직접 연결할 수 없지만 클라이언트에 연결 가능한 노드가 이미 있다면, 먼저 해당 노드를 활성화한 뒤 ‘모든 구독 업데이트(프록시 사용)’를 선택할 수 있습니다. 목록이 비어 있는 첫 설치 상태에서는 연결에 사용할 아웃바운드가 없으므로 프록시를 통한 업데이트를 반복해도 해결되지 않는 경우가 많습니다. 구독 제공자에게 링크 유효성과 접속 방법을 먼저 문의하세요.
4. 시스템 프록시와 로컬 포트: 먼저 브라우저 연결 확인하기
활성 노드가 있으면 트레이 아이콘을 마우스 오른쪽 버튼으로 클릭하고 ‘시스템 프록시’에서 ‘시스템 프록시 자동 설정’을 선택하세요. 여기서 ‘자동 설정’은 클라이언트가 Windows 시스템 프록시를 설정한다는 의미이지, 시스템의 모든 프로그램이 이 설정을 따른다는 뜻은 아닙니다. 브라우저는 첫 테스트에 적합하지만 게임이나 명령줄 도구 등은 별도로 설정해야 할 수 있습니다.
‘설정’ → ‘매개변수 설정’을 열고 로컬 수신 주소와 포트를 확인하세요. 릴리스에 따라 HTTP와 SOCKS를 함께 받는 혼합 포트가 제공되거나, 각 포트가 따로 표시될 수 있습니다. 기존 튜토리얼에 나온 10809를 현재 HTTP 포트라고 단정하지 마세요. 혼합 포트는 현재 코어 설정이 지원하는 경우에만 HTTP와 SOCKS 요청을 모두 받을 수 있습니다.
첫 연결 확인 기준
- 로컬 주소
- 127.0.0.1
- 포트 예시
- 10808, 실제 포트 확인 필요
- 시스템 프록시
- 시스템 프록시 자동 설정
- TUN 상태
- 꺼짐
먼저 시스템 프록시를 따르는 브라우저를 확인하고, 가상 네트워크 어댑터와 추가 권한 변수는 일단 제외하세요.
명령줄 진단 기준
- 테스트 연결 지점
- 확인된 HTTP 또는 혼합 포트
- 대상 주소
- https://example.com
- 최대 대기 시간
- 15초
- 확인 기준
- 명령 출력과 같은 시점의 코어 로그
프록시를 명시하면 앱이 시스템 프록시를 읽는지 여부와 관계없이 테스트할 수 있어, 로컬 연결 지점과 원격 연결 문제를 구분하는 데 도움이 됩니다.
현재 로컬 10808이 HTTP 또는 혼합 포트인 것을 확인했다면 PowerShell에서 아래 테스트를 실행할 수 있습니다. SOCKS 포트만 있다면 두 번째 명령을 사용하세요. 두 명령을 모두 실행할 필요는 없으며, 포트는 반드시 현재 사용 중인 값으로 바꾸세요. 예시 대상은 요청 경로를 확인하기 위한 것으로, 특정 사이트 하나에 연결됐다고 모든 라우팅이 검증된 것은 아닙니다.
curl.exe --proxy http://127.0.0.1:10808 --connect-timeout 5 --max-time 15 -I https://example.com
curl.exe --proxy socks5h://127.0.0.1:10808 --connect-timeout 5 --max-time 15 -I https://example.com첫 번째 명령에서 200 Connection established만 표시된다면 프록시가 터널 요청을 수락했다는 뜻일 뿐, 이후 TLS 연결과 대상 사이트 요청까지 성공했다는 의미는 아닙니다. 최종 응답이나 후속 오류도 확인해야 합니다. 두 번째 명령은 socks5h를 사용해 대상 도메인의 처리를 프록시 측에 맡기므로 로컬 DNS 문제의 범위를 좁히는 데 도움이 됩니다.
5. 라우팅과 코어: 설정은 한 번에 하나씩 변경하기
시스템 프록시는 ‘앱이 요청을 클라이언트에 전달하는지’를 처리하고, 라우팅 규칙은 ‘클라이언트에 들어온 요청이 어떤 아웃바운드로 나가는지’를 정합니다. 서로 다른 설정입니다. 상태 표시줄이나 메인 화면의 ‘라우팅’ 선택기에서 현재 구성을 확인하세요. 시스템 프록시를 켰다고 모든 도메인이 원격 노드를 거치는 것은 아닙니다.
- 먼저 기본 라우팅을 유지하세요:프록시가 필요한 것으로 확인된 대상을 테스트하고 로그에서 아웃바운드 선택을 확인하세요. 웹페이지가 열려도 로그에 직접 연결로 표시된다면 원격 노드가 정상이라는 증거가 아닙니다.
- 다음으로 프로토콜 호환성을 확인하세요:VMess와 VLESS는 프로토콜 이름이며, Xray는 연결을 처리할 수 있는 코어 중 하나입니다. 지원되지 않는 필드가 있다면 ‘코어를 바꾸면 더 빨라진다’는 이유만으로 전환하지 말고 현재 코어와 노드 요구 사항을 확인하세요.
- 마지막으로 DNS를 확인하세요:도메인 확인 오류가 발생하면 먼저 문제가 로컬, 코어, 원격 중 어디에서 발생했는지 살펴보세요. DNS 주소를 임의의 공용 주소로 바꿔도 라우팅이나 구독 접속 문제가 해결되지 않을 수 있습니다.
6. 시작 실패와 포트 충돌: 오류에 따라 원인 찾기
메인 창이 정상적으로 열려도 코어가 시작됐다는 보장은 없습니다. 로그에 address already in use 또는 바인딩 실패가 표시되면 로컬 수신 포트를 확인하세요. 파일을 찾을 수 없다는 메시지가 나오면 압축 해제 폴더와 보안 소프트웨어 기록을 확인해야 합니다. 두 문제 모두 서버 연결 전 발생하므로 구독을 다시 구매하거나 바꿔도 대개 해결되지 않습니다.
| 증상 | 우선 확인할 항목 | 해결 방법 |
|---|---|---|
| 두 번 클릭해도 창이 열리지 않음 | 트레이 아이콘 및 런타임 | 먼저 알림 영역에 이미 실행 중인 인스턴스가 있는지 확인한 다음, 시작 팝업에 표시된 프레임워크와 아키텍처를 확인하세요. |
| 코어 파일을 찾을 수 없음 | 압축 해제가 완전한지 | 프로그램 하위 폴더와 Windows 보안의 보호 기록을 확인해 파일이 격리됐는지 살펴보세요. |
| 로컬 포트 바인딩 실패 | 다른 인스턴스 또는 프록시 프로세스 | 해당 포트를 수신 중인 프로세스 ID를 확인하세요. 프로그램이 무엇인지 확인한 뒤 중복 인스턴스를 종료하거나 로컬 포트를 변경하세요. |
| 종료 후 브라우저에서 인터넷에 연결되지 않음 | 시스템 프록시 설정이 남아 있음 | 클라이언트를 다시 실행해 ‘시스템 프록시 지우기’를 선택하거나 Windows 프록시 설정에서 수동 프록시를 확인하세요. |
| 노드 연결 시간 초과 | 원격 주소와 네트워크 경로 | 로컬 연결 지점이 정상인지 확인한 뒤 노드 유효성, 서버 포트, 네트워크 연결을 점검하세요. |
10808을 예로 들어 PowerShell에서 수신 상태를 확인하세요. 마지막 열은 프로세스 ID입니다. 출력된 프로세스 ID가 4321이라고 가정하고 두 번째 명령을 실행해 프로그램 이름을 확인합니다. 프로세스 ID는 명령 사용법을 보여 주기 위한 예시이므로 실제 PC에서 해당 프로세스를 그대로 종료하지 마세요.
netstat -ano -p tcp | findstr ":10808"
tasklist /FI "PID eq 4321"출력의 ‘로컬 주소’가 실제로 해당 포트로 끝나는지, 상태가 수신 중인지 확인하세요. 원격 연결 기록을 포트 점유로 오해하지 않도록 주의해야 합니다. 점유 프로세스가 이전 v2rayN 인스턴스라면 정상적으로 종료하세요. 다른 필수 프로그램이라면 v2rayN 매개변수 설정에서 사용하지 않는 로컬 포트로 변경하고, 코어를 다시 시작한 뒤 시스템 프록시를 다시 적용하세요.
7. 자주 묻는 질문: 구독, 권한, 인터넷 연결 복구
구독 업데이트는 성공했는데 목록이 비어 있는 이유는 무엇인가요?
먼저 검색 조건을 지우고 올바른 그룹으로 바꾼 다음 업데이트 로그에서 파싱 결과를 확인하세요. 요청 성공은 응답을 받았다는 뜻일 수 있지만, 응답 내용이 로그인 페이지나 만료 안내일 수도 있습니다. 링크에 공백이나 줄바꿈이 들어갔는지, 토큰이 빠지지 않았는지 확인하세요. 개인 구독 링크를 공개 게시판에 올리지 마세요.
실행할 때마다 관리자 권한으로 실행해야 하나요?
일반적인 로컬 프록시와 현재 사용자 계정의 시스템 프록시에는 보통 필요하지 않습니다. TUN처럼 시스템 네트워크 기능을 사용하는 경우에만 현재 구현에 따라 관리자 권한이나 서비스 설치가 필요할 수 있습니다. 처음 문제를 해결할 때는 TUN을 끄고 일반 권한으로 브라우저를 테스트해 권한 문제와 노드 문제를 혼동하지 않도록 하세요.
창을 닫았는데 프로그램이 계속 실행되는 이유는 무엇인가요?
설정에 따라 닫기 버튼을 누르면 프로그램이 트레이로 최소화될 수 있습니다. Windows 알림 영역을 열고 v2rayN 아이콘을 마우스 오른쪽 버튼으로 클릭한 뒤 먼저 ‘시스템 프록시 지우기’를 선택하고 ‘종료’를 누르세요. 작업 표시줄에서 창이 사라졌는지만 보고 프로세스가 종료됐다고 판단하지 마세요.
클라이언트를 종료한 뒤 브라우저에서 웹페이지가 전혀 열리지 않으면 어떻게 하나요?
Windows ‘설정’ → ‘네트워크 및 인터넷’ → ‘프록시’를 열고 ‘프록시 서버 사용’이 중지된 로컬 포트를 가리키는지 확인하세요. 개인 PC라면 남아 있는 설정을 지울 수 있습니다. 회사 정책으로 관리되는 기기라면 기존 프록시나 스크립트 설정을 덮어쓰지 말고 관리자에게 문의하세요.
웹페이지는 열리는데 특정 프로그램은 왜 프록시를 사용하지 않나요?
먼저 해당 프로그램이 Windows 시스템 프록시를 사용하는지 확인하세요. 별도의 HTTP 또는 SOCKS 프록시 설정을 지원한다면 클라이언트가 실제로 수신하는 주소, 포트, 연결 유형을 입력하세요. 지원하지 않는다면 TUN으로 트래픽을 처리하는 방법을 검토할 수 있습니다. 특정 앱이 시스템 프록시를 따르지 않는다는 이유로 구독 노드를 계속 바꾸지 마세요.
8. 업그레이드와 이전: 백업 후 교체하기
업그레이드 전에 시스템 프록시를 지우고 클라이언트를 종료한 다음 이전 프로세스가 끝났는지 확인하세요. 이어서 설정과 구독 정보를 백업합니다. 설정에는 노드 인증 정보가 포함될 수 있으므로 본인이 관리하는 위치에 보관하고 공개 클라우드에 바로 올리지 마세요. WPF와 Desktop 사이에서 모든 설정 파일을 그대로 덮어써도 된다고 가정해서는 안 됩니다.
- 롤백용 백업 보관:기존 프로그램 폴더와 실제 설정 폴더를 각각 백업하세요. 설정 위치는 배포 방식에 따라 달라질 수 있으므로 현재 클라이언트의 폴더 메뉴나 릴리스 안내를 확인하세요.
- 새 폴더에서 시험 실행:새 패키지의 압축을 다른 폴더에 완전히 풀고 두 인스턴스를 동시에 실행하지 마세요. 먼저 시작 로그를 확인한 다음 구독을 가져오고 활성 노드를 확인하세요.
- 로컬 연결 설정 재확인:업그레이드 전후의 수신 주소, 포트, 시스템 프록시 모드, 라우팅 설정을 기록하세요. 외부 앱에 포트를 직접 입력했다면 해당 설정도 함께 확인해야 합니다.
- 마지막으로 추가 기능 복원:기본 브라우저 요청이 정상적으로 처리된 뒤 사용자 지정 DNS, 라우팅 규칙, TUN을 하나씩 다시 설정하세요. 항목을 바꿀 때마다 테스트하면 충돌 원인을 찾기 쉽습니다.
설치가 제대로 끝났는지 확인하려면 세 가지를 모두 점검해야 합니다. 클라이언트가 코어를 시작할 수 있는지, 구독에서 선택 가능한 노드가 생성되는지, 실제 요청이 예상한 아웃바운드를 통해 응답을 받는지 확인하세요. 메인 창이 보이거나 노드 수가 표시되거나 지연 시간 테스트가 한 번 성공한 것만으로는 충분하지 않습니다. 이후 문제가 생기면 처음부터 재설치하기보다 ‘로컬 연결 지점 → 시스템 프록시 → 라우팅 → 원격 연결’ 순서로 확인하는 편이 원인을 찾기 쉽습니다.