v2rayN을 더블 클릭해도 창이 뜨지 않거나, 창이 잠깐 나타났다가 닫히거나, 화면은 열리지만 코어가 시작되지 않는 경우에 유용합니다. 메인 프로그램과 코어를 구분한 뒤 런타임, 압축 해제 폴더, 보안 소프트웨어, 쓰기 권한, 기존 설정 순으로 점검하세요. 이 글은 Windows를 중심으로 설명하며 macOS와 Linux에서 확인할 점도 다룹니다. 모든 명령은 점검 예시이며, 실제 판단은 해당 PC의 로그를 기준으로 하세요.
1. 먼저 확인: 메인 프로그램이 종료되나요, 코어가 실행되지 않나요?
v2rayN은 노드, 구독, 시스템 프록시와 코어 프로세스를 관리하는 데스크톱 클라이언트입니다. 실제 연결 처리는 Xray 또는 v2fly 코어가 담당합니다. 두 프로그램은 별개의 프로세스이므로 코어가 종료되어도 메인 창이 계속 열려 있을 수 있고, 메인 프로그램이 시작되지 않았다고 노드에 문제가 있다고 단정할 수도 없습니다. 점검 순서를 잘못 잡으면 런타임 문제를 해결하려다 구독을 다시 가져오는 일이 생길 수 있습니다.
| 증상 | 우선 점검할 항목 | 지금은 건드리지 말 것 |
|---|---|---|
| 더블 클릭해도 창과 트레이 아이콘이 나타나지 않음 | 런타임, 시스템 아키텍처, 이벤트 뷰어 | 구독 주소와 노드 설정 |
| 창이 나타난 직후 사라짐 | 앱 오류, 폴더 권한, 기존 설정 불러오기 | 원격 서버 설정 |
| 화면은 정상이나 로그에 코어 종료가 표시됨 | 코어 파일, 포트 충돌, 생성된 설정 파일 | 메인 프로그램 런타임 |
| 창은 보이지 않지만 작업 관리자에 프로세스가 남아 있음 | 트레이, 기존 실행 인스턴스, 창 위치 | 먼저 충돌로 단정하지 마세요 |
「작업 관리자」→「세부 정보」에서 v2rayN.exe 프로세스가 있는지 확인하세요. 작업 표시줄의 숨겨진 트레이 아이콘도 확인합니다. 창을 닫았을 때 트레이로 최소화되었을 수 있습니다. 이미 실행 중인 인스턴스가 있으면 트레이 메뉴에서 종료한 뒤 다시 시작하세요. 여러 번 연달아 더블 클릭하면 점검에 필요한 단서가 뒤섞일 수 있습니다.
2. .NET 런타임 누락: 버전 번호만 보지 말고 프레임워크 이름 확인
런타임에 종속된 배포 패키지는 PC에 해당 .NET 런타임이 설치되어 있어야 합니다. 자체 포함 배포 패키지에는 일반적으로 런타임이 포함되어 있습니다. PC에 .NET을 설치한 적이 있다는 이유만으로 문제가 없다고 판단하지 마세요. .NET Framework 4.8과 최신 .NET 런타임은 서로 다른 종속성이고, x64와 ARM64 패키지도 서로 대체할 수 없습니다.
프로그램 폴더에서 v2rayN.runtimeconfig.json을 확인하세요. 파일이 있으면 runtimeOptions 아래의 framework 또는 frameworks 항목을 살펴봅니다. 예를 들어 Microsoft.WindowsDesktop.App과 8.0.0이 표시되면 해당 아키텍처에 맞는 .NET 8 Windows Desktop Runtime이 필요하다는 뜻입니다. 여기의 8.0.0은 필드 예시이며, 현재 모든 v2rayN 패키지에 적용되는 고정 요구 사항은 아닙니다.
dotnet --list-runtimes
터미널에서 위 명령을 실행하세요. 데스크톱 프레임워크가 필요한 패키지는 Microsoft.NETCore.App만 보여도 데스크톱 런타임이 갖춰졌다고 볼 수 없습니다. 호환되는 Microsoft.WindowsDesktop.App도 확인해야 합니다. 명령을 찾을 수 없더라도 자체 포함 패키지가 실행되지 않는다고 단정하지 마세요. 시작 오류 메시지와 패키지 유형을 다시 확인하세요.
오류: You must install or update .NET to run this application.
원인: 시작 프로그램이 앱에 필요한 프레임워크나 아키텍처를 찾지 못했습니다. 해결: 안내에 표시된 Framework, Version, Architecture에 맞는 런타임을 설치한 다음 v2rayN을 완전히 종료하고 다시 실행하세요.
오류: The framework 'Microsoft.WindowsDesktop.App' was not found.
원인: Windows 데스크톱 런타임이 필요한 패키지에서 해당 프레임워크를 찾지 못했습니다. 해결: 일반 .NET Runtime만 설치하지 말고 필요한 주 버전의 Windows Desktop Runtime을 설치하세요.
오류: This app can't run on your PC
원인: 프로그램 아키텍처, 시스템 호환성 또는 파일 손상 문제일 수 있으며, 런타임 누락만을 뜻하는 메시지는 아닙니다. 해결: 먼저 「설정」→「시스템」→「시스템 정보」에서 시스템 종류를 확인한 뒤, 맞는 패키지를 다시 다운로드해 압축을 푸세요.
데스크톱 인터페이스 버전에 따라 필요한 프레임워크가 다를 수 있으므로 특정 Windows 인터페이스 패키지의 요구 사항을 모든 플랫폼에 적용할 수는 없습니다. 더 높은 주 버전을 설치해도 낮은 주 버전의 요구 사항까지 자동으로 충족되는 것은 아니며, 하위 호환 여부는 앱 설정에 따라 달라집니다. 온라인의 '최신 버전을 설치하면 된다'는 말보다 오류 메시지와 패키지에 포함된 런타임 설정을 기준으로 판단하세요.
3. 압축 해제 폴더와 파일 확인: 쓰기 가능한 짧은 경로에서 테스트
압축 파일 미리보기 창에서 메인 프로그램을 바로 더블 클릭하지 마세요. 실행에 필요한 파일만 임시로 풀리고 같은 폴더의 종속 파일, 리소스, 코어는 제대로 저장되지 않을 수 있습니다. 새 패키지의 파일을 기존 폴더에 일부만 덮어쓰는 것도 피하세요. 파일명이 같아도 기존 종속 파일과 새 프로그램이 호환된다는 보장은 없습니다.
-
기존 프로세스 종료
트레이에서 v2rayN을 종료한 뒤 「작업 관리자」→「세부 정보」에서 기존 메인 프로그램이 종료되었는지 확인하세요. 어떤 프로그램인지 확실하지 않은 프로세스는 종료하지 마세요.
-
기존 폴더 보관
기존 폴더 전체를 복사해 백업하세요. 버전에 따라 사용자 데이터가 다른 위치에 저장될 수 있으므로 실제 데이터 폴더도 백업해야 합니다. 구독 주소와 노드 인증 정보는 민감한 정보입니다.
-
압축 파일 전체 풀기
다운로드 센터에서 알맞은 패키지를 선택한 뒤 압축 파일 전체를 현재 사용자 계정에서 쓸 수 있는 짧은 경로에 푸세요. 예:
%USERPROFILE%\Apps\v2rayN-test. 메인 프로그램만 꺼내지 마세요. -
새 폴더에서 테스트
기존 설정은 복사하지 말고 새 폴더의 메인 프로그램을 바로 실행하세요. 빈 화면이라도 열리면 런타임과 기본 프로그램의 시작 과정은 통과한 것입니다.
폴더 이름이 중국어라고 해서 반드시 충돌이 발생하는 것은 아니며, 공백도 대체로 문제없이 처리됩니다. 다만 일부 호출 과정, 문자 이스케이프 방식 또는 지나치게 긴 경로에서 문제가 드러날 수 있습니다. 짧은 경로 테스트는 변수를 분리하기 위한 것이지, '중국어 경로는 모두 사용할 수 없다'는 뜻이 아닙니다. 짧은 경로에서 실행된다면 기존 폴더의 길이, 권한, 동기화 상태, 특수 문자를 비교하세요.
4. 보안 소프트웨어 차단: 보호 기능 전체를 끄지 말고 해당 파일 확인
메인 화면은 열리지만 노드를 선택한 직후 코어가 종료된다면 프로그램 패키지에 필요한 코어 파일이 남아 있는지 확인하세요. 보안 소프트웨어가 다운로드, 압축 해제 또는 첫 실행 과정에서 파일을 격리했을 수 있습니다. 이 경우 화면은 정상적으로 열려도 코어 프로세스가 생성되지 않습니다. 구독을 바꿔도 로컬 실행 파일은 복구되지 않습니다.
- Windows 기본 보안 기능: 「Windows 보안」→「바이러스 및 위협 방지」→「보호 기록」에서 오류가 발생한 시각의 기록을 확인하세요.
- 기타 보안 소프트웨어: 격리 항목, 행위 차단, 앱 제어 기록을 확인해 메인 프로그램과 코어 중 어떤 파일이 영향을 받았는지 살펴보세요.
- 회사에서 관리하는 기기: 기록에 조직 정책이 표시되면 관리자에게 문의하세요. 정책을 임의로 제거하거나 앱 제어를 우회하지 마세요.
- 파일을 복원하기 전에 패키지 출처, 파일 위치, 차단 사유를 확인하세요. 의심스러운 동작이 발견되면 실행을 중단하고 신뢰할 수 있는 배포 패키지를 다시 받으세요.
오류: The system cannot find the file specified.
원인: 호출된 코어, 종속 파일 또는 경로가 없을 수 있습니다. 해결: 오류가 발생한 상황을 살펴 누락된 대상을 확인하고, 압축 해제 결과와 격리 기록을 점검하세요. 신뢰할 수 있는 파일을 복원하거나 패키지 전체를 다시 압축 해제합니다.
오류: Access is denied.
원인: 파일 접근, 실행 권한 또는 보안 정책이 작업을 차단했을 수 있습니다. 해결: 먼저 접근이 거부된 파일이나 폴더를 확인한 뒤 권한과 보안 기록을 점검하세요. 이 메시지만으로 보안 소프트웨어의 오탐이라고 단정할 수는 없습니다.
허용 규칙을 추가해야 한다면 확인된 프로그램이나 폴더에만 적용하고 해당 기기의 보안 정책을 따르세요. 디스크 전체를 예외로 등록하거나 한 번 실행하려고 실시간 보호 기능을 계속 끄지 마세요. 문제 지점을 고쳐야지 보안의 문을 통째로 떼어 내서는 안 됩니다.
5. 권한과 포트: 관리자 권한 실행은 만능 해결책이 아닙니다
일반 시스템 프록시 모드는 보통 계속 관리자 권한으로 실행할 필요가 없습니다. TUN 모드는 가상 네트워크 인터페이스와 라우팅을 다루므로 일부 버전과 시스템 환경에서 권한 상승이 필요할 수 있습니다. 메인 프로그램 문제와 TUN 문제를 구분하려면 메인 화면에서 「TUN 활성화」를 끄고 일반 권한으로 시작해 보세요. TUN을 켰을 때만 실패한다면 해당 모드의 권한 요구 사항과 로그를 확인하세요.
일반 권한으로 실행되지 않지만 관리자 권한으로는 열린다면 먼저 데이터 폴더의 쓰기 권한을 확인하세요. 파일 탐색기에서 해당 폴더에 새 텍스트 파일을 만들어 보면 쓰기 가능 여부를 간단히 확인할 수 있습니다. 사용자 계정에서 쓸 수 있는 폴더는 정상이고 보호된 폴더에서만 실패한다면 '관리자 권한으로 실행'을 계속 설정하기보다 프로그램과 데이터를 다른 위치로 옮기는 편이 좋습니다.
netstat -ano | findstr :10808
tasklist /FI "PID eq 4321"
위의 10808은 포트 점검 예시입니다. 먼저 「설정」→「매개변수 설정」에 표시된 로컬 수신 포트를 확인하세요. 첫 번째 명령은 포트 사용 여부를 찾습니다. 두 번째 명령의 4321은 예시 PID이므로 실행할 때 첫 번째 명령 결과의 마지막 열에 나온 실제 값으로 바꾸세요. 원격 포트가 표시되더라도 로컬 수신 포트가 사용 중이라는 뜻은 아닙니다. 로컬 주소 열과 LISTENING 상태를 확인하세요.
오류: bind: Only one usage of each socket address (protocol/network address/port) is normally permitted.
원인: 수신하려는 주소와 포트를 다른 프로세스가 이미 사용 중입니다. 종료되지 않은 이전 코어나 중복 실행 인스턴스가 흔한 원인입니다. 해결: 포트를 사용 중인 프로세스가 무엇인지 확인한 뒤 종료하거나, 「설정」→「매개변수 설정」에서 로컬 수신 포트를 변경하고 코어를 다시 시작하세요.
포트를 변경한 뒤에는 브라우저, 터미널 또는 다른 앱에 직접 입력한 프록시 포트도 함께 변경해야 합니다. 시스템 프록시 설정과 코어의 수신 포트가 서로 맞아야 합니다. 메인 창은 정상인데 코어 로그에 바인딩 오류가 표시된다면 .NET을 다시 설치할 일이 아니라 코어 시작 실패로 분류하세요.
6. 기존 설정과 충돌 로그: 먼저 기록을 보존한 뒤 분리 점검
업데이트 후부터 실행 직후 종료되고 새 폴더에서는 정상적으로 시작된다면 기존 데이터나 남은 종속 파일을 먼저 살펴보세요. 기존 폴더를 보존하고 데이터베이스, 설정, 구독을 바로 삭제하지 마세요. 노드 인증 정보를 잃어버리면 원래 시작 오류를 해결하는 것보다 더 많은 시간이 걸립니다.
- 오류가 발생한 시각을 분 단위까지 기록하세요. 「이벤트 뷰어」→「Windows 로그」→「응용 프로그램」에서 같은 시각의 앱 오류나 .NET Runtime 이벤트를 확인합니다.
- 오류가 난 앱 이름, 오류 모듈, 예외 코드와 메시지를 기록하세요. 이벤트 ID 1000 또는 1026은 단서가 될 수 있지만, 충돌이 발생할 때마다 이 이벤트가 반드시 기록되는 것은 아닙니다.
- 프로그램이 로그를 생성했다면 실제 로그 폴더에서 수정 시각이 가장 최근인 파일을 확인하세요. 저장 위치는 버전에 따라 다를 수 있으므로 특정 경로 하나만 찾지 마세요.
- 먼저 설정이 없는 새 폴더에서 정상적으로 실행되는지 확인한 뒤, 클라이언트 화면을 통해 노드, 구독, 설정을 하나씩 복원하세요. 기존 폴더의 모든 파일을 바로 덮어쓰지 마세요.
- 특정 데이터를 복원한 뒤 다시 문제가 발생하면 더 이상 가져오지 말고 해당 단계의 로그와 백업을 보존하세요. 한 번에 한 종류의 데이터만 복원해야 문제를 일으키는 조건을 찾을 수 있습니다.
새 폴더에서 실행을 테스트할 때도 기존 위치의 공유 사용자 데이터를 읽지 않는지 확인해야 합니다. 패키지에 따라 프로그램 폴더에 데이터가 저장되기도 하고, 버전이나 시작 방식에 따라 다른 사용자 데이터 폴더를 사용하기도 합니다. 프로그램 파일을 새 폴더에 넣었다고 설정 환경까지 자동으로 새로워지는 것은 아닙니다. 이번 실행의 로그와 버전 정보를 바탕으로 실제 데이터 경로를 확인한 뒤 프로그램을 종료하고 해당 데이터를 백업해 분리하세요.
macOS 및 Linux 추가 점검
두 플랫폼 모두 먼저 아키텍처와 패키지 유형을 확인한 다음, 터미널에서 실제 설치된 프로그램을 실행해 표준 오류 출력을 확인하세요. Linux에서 Permission denied가 표시되면 실행 파일 권한과 파일 시스템이 실행을 제한하는지 살펴보세요. 폴더 전체에 모든 사용자의 쓰기 권한을 재귀적으로 부여하지 마세요. macOS에서 시스템 보안 차단 메시지가 표시되면 「시스템 설정」→「개인정보 보호 및 보안」에서 구체적인 안내를 확인하고, 신뢰할 수 있음을 확인한 앱만 시스템 절차에 따라 처리하세요.
- 터미널에서 공유 라이브러리가 없다고 나오면 정확한 라이브러리 이름을 기록하고 현재 배포판의 패키지 관리 방식으로 종속성을 설치하세요. 다른 운영 체제의 라이브러리 파일을 임의로 복사하지 마세요.
- 데스크톱 아이콘으로는 열리지 않지만 터미널에서는 실행되는 경우 시작 항목의 실제 경로와 작업 폴더를 확인하세요. 코어를 먼저 다시 설치하지 마세요.
- 메인 화면은 열리지만 코어가 실행되지 않는다면 선택한 코어가 해당 기기의 아키텍처와 맞는지, 로그에 표시된 경로에 파일이 실제로 있는지 확인하세요.
7. 자주 묻는 질문: 해결 여부 확인하기
.NET을 설치했는데도 런타임이 없다는 메시지가 표시되는 이유는 무엇인가요?
dotnet --list-runtimes를 실행해 시작 안내에 나온 프레임워크 이름, 주 버전, 아키텍처와 비교하세요. Microsoft.WindowsDesktop.App이 필요한 패키지는 Microsoft.NETCore.App만 설치해서는 부족할 수 있습니다. .NET Framework 4.8을 설치한 적이 있어도 이를 대신할 수는 없습니다.
다시 설치했는데도 실행 직후 종료됩니다. 설정을 전부 삭제해야 하나요?
먼저 백업한 뒤 쓰기 가능한 별도 폴더에서 테스트하고 기존 데이터 위치를 계속 읽고 있지 않은지도 확인하세요. 새 환경에서 실행될 때만 데이터를 하나씩 옮겨 보세요. 새 환경에서도 실패한다면 런타임과 이벤트 로그를 계속 확인하세요. 구독을 삭제해도 프로그램 종속성 문제는 대개 해결되지 않습니다.
관리자 권한으로는 열리지만 일반 더블 클릭으로는 실행되지 않나요?
먼저 「TUN 활성화」를 끄고 폴더 쓰기 권한을 확인한 다음 현재 사용자 계정에서 쓸 수 있는 위치로 옮겨 보세요. TUN 모드에서만 권한 상승이 필요하다면 해당 모드의 요구 사항에 따라 처리하세요. 일반 모드에서도 관리자 권한이 필요한 경우 접근이 거부된 경로나 보안 정책을 확인해야 합니다.
화면은 열리는데 웹페이지가 계속 열리지 않습니다. 해결된 건가요?
메인 프로그램이 다시 시작된 것만 확인된 상태입니다. 코어 로그에서 정상적으로 수신 대기 중인지 확인하고 「시스템 프록시」→「시스템 프록시 자동 설정」과 현재 라우팅 선택도 점검하세요. 앱 트래픽이 프록시를 거치는지, 노드에 연결되는지는 다음 단계의 연결 문제입니다. 실행 직후 종료 문제와 혼동하지 마세요.
문제를 해결한 뒤 바로 시작 프로그램으로 등록해도 되나요?
먼저 프로그램을 직접 종료한 뒤 다시 실행하고, 로그아웃하거나 재부팅해 테스트하세요. 메인 화면, 코어, 로그가 모두 정상인지 확인한 다음 「설정」→「매개변수 설정」에서 해당 자동 실행 옵션을 켜세요. 직접 실행은 되지만 로그인 시 시작되지 않는다면 시작 항목의 경로, 작업 폴더, 권한 컨텍스트를 비교하세요.
마지막으로 세 가지를 확인하세요. 일반 권한으로 반복 실행할 수 있는지, 선택한 코어가 시작 직후 종료되지 않는지, 클라이언트를 종료한 뒤 기존 프로세스와 로컬 수신 포트가 해제되는지 점검합니다. 정상적으로 작동한 버전, 폴더, 해결 절차를 기록해 두면 다음 업데이트에서 비슷한 문제가 생겼을 때 정상 상태와 비교할 수 있습니다.