이 글의 핵심 내용

v2rayN을 더블 클릭한 뒤 창이 사라지거나, 업데이트 후 실행되지 않거나, 화면은 나타나지만 코어가 바로 종료되는 경우에 해당합니다. 먼저 종료된 것이 인터페이스인지 코어인지 확인하고 로그를 보존한 뒤 런타임, 쓰기 권한, 사용자 설정, 리슨 포트를 차례로 점검하세요. 아래 설명은 Windows를 기준으로 하며 Linux에서 터미널로 확인하는 방법도 함께 안내합니다. 처음부터 데이터 폴더 전체를 삭제하지 마세요.

인터페이스 종료와 코어 종료 구분하기

v2rayN은 클라이언트 인터페이스이며, 프록시 연결은 호출된 코어가 처리합니다. 인터페이스 실행 실패와 Xray 같은 코어의 실행 실패는 서로 다른 문제입니다. VMess와 VLESS는 연결 프로토콜이고 구독은 설정을 가져오는 경로입니다. 연결을 시도하기도 전에 인터페이스가 종료된다면 구독을 바꾸거나 프로토콜을 수정해도 대개 해결되지 않습니다.

확인된 증상먼저 확인할 항목보존할 증거
창이 나타나지 않고 프로세스가 곧바로 종료됨런타임, 프로그램 패키지 아키텍처, 시작 오류시스템 경고 창, 이벤트 뷰어 기록
창은 닫혔지만 트레이 아이콘은 남아 있음트레이로 최소화되었는지 여부작업 관리자의 프로세스 상태
인터페이스는 열려 있지만 로그에 실행 실패가 반복됨코어 파일, 생성된 설정, 리슨 포트코어 오류 전체 내용
인터페이스와 코어는 정상인데 웹페이지가 열리지 않음시스템 프록시, 라우팅 규칙, DNS, 노드연결 로그 및 애플리케이션 프록시 설정

Ctrl + Shift + Esc를 눌러 작업 관리자를 열고 v2rayN 프로세스가 남아 있는지 확인하세요. 트레이로 최소화된 것뿐이라면 트레이 아이콘을 더블 클릭해 창을 복원합니다. 실제로 종료된 경우 발생 시간을 기록한 다음 Win + R을 누르고 eventvwr.msc를 입력하세요. 「Windows 로그」→「응용 프로그램」에서 같은 시간대의 「.NET Runtime」 또는 「Application Error」 기록을 확인합니다. 오류 모듈, 예외 유형, 파일 경로를 중심으로 기록하세요.

.NET 런타임: 오류 메시지에 맞는 프레임워크와 아키텍처 확인

.NET 설치를 요구하는 경고 창이 나타나면 먼저 안내에 표시된 프레임워크 이름, 필요한 버전, 아키텍처를 확인하세요. 외부 런타임에 의존하는 패키지와 자체 포함 패키지는 해결 방법이 다릅니다. 특정 .NET 주 버전이 모든 v2rayN 패키지에 필요한 것은 아니며, 더 최신 주 버전을 설치해도 구형 프로그램과 반드시 호환되는 것은 아닙니다.

You must install or update .NET to run this application.

원인: 프로그램이 필요한 .NET 런타임을 찾지 못하고 있습니다. 해결: 경고 창에 지정된 프레임워크, 버전, 아키텍처에 맞는 런타임을 설치한 뒤 프로그램을 다시 실행하세요. 자체 포함 패키지를 사용한다면 시스템에 맞는 패키지를 새로 완전히 압축 해제하는 방법을 우선 시도하세요.

PowerShell에서 아래 명령을 실행해 현재 호출 가능한 dotnet 호스트가 어떤 런타임을 찾는지 확인하세요. dotnet 명령을 찾을 수 없다는 메시지만으로 모든 아키텍처의 런타임이 설치되지 않았다고 단정할 수는 없습니다. Windows의 「설치된 앱」 목록과 오류 창도 함께 확인하세요.

dotnet --info
dotnet --list-runtimes

Linux에서는 먼저 터미널에서 압축을 푼 폴더로 이동한 뒤 프로그램을 실행해 오류를 확인하세요. Permission denied가 표시되면 실행 권한을 점검하고, 공유 라이브러리가 없다는 오류가 나타나면 해당 종속 항목을 해결하세요. Windows의 Desktop Runtime 설치 방법을 Linux에 그대로 적용하지 마세요.

cd ~/Applications/v2rayN
ls -l ./v2rayN
chmod u+x ./v2rayN
./v2rayN

아래 Linux 명령은 프로그램이 실제로 ~/Applications/v2rayN에 있는 경우를 예로 듭니다. 파일의 출처와 이름이 올바른지 확인한 경우에만 실행 권한을 추가하세요. 권한을 수정해도 아키텍처 불일치나 시스템 라이브러리 누락은 해결되지 않습니다.

폴더 권한: 실제 데이터 위치에 쓰기 가능한지 확인

v2rayN은 실행 중 설정, 로그, 데이터베이스, 임시 코어 설정을 기록할 수 있습니다. 프로그램 파일을 읽을 수 있다고 해서 사용자 데이터 폴더에도 쓸 수 있는 것은 아닙니다. 포터블 패키지를 보호된 폴더에 두거나 압축 파일 안에서 바로 실행하는 경우, 또는 읽기 전용 백업을 작업 폴더에 복원한 경우 초기화 중 오류가 발생할 수 있습니다.

  1. 종료 후 백업

    트레이에서 프로그램을 종료하고 작업 관리자에서 프로세스가 끝났는지 확인하세요. 원본 프로그램 폴더와 실제 데이터 폴더를 복사하고 로그 원본도 보존하세요. 유일한 데이터 사본으로 반복해서 테스트하지 마세요.

  2. 전체 압축 해제

    포터블 패키지는 현재 사용자 계정의 테스트 폴더인 Documents\v2rayN-test에 압축 해제할 수 있습니다. 압축 프로그램의 미리보기 창에서 주 프로그램을 더블 클릭하지 말고, 실행 파일 하나만 따로 꺼내지도 마세요.

  3. 쓰기 권한 확인

    로그에 표시된 데이터 폴더에 텍스트 파일을 새로 만들고 저장한 뒤 삭제하세요. 폴더를 마우스 오른쪽 버튼으로 클릭해 「속성」→「보안」으로 이동한 다음 현재 사용자를 선택하고 「쓰기」 및 「수정」 권한을 확인합니다.

  4. 차단 여부 확인

    「Windows 보안」→「바이러스 및 위협 방지」→「보호 기록」에서 해당 프로그램이나 코어가 차단되었는지 확인하세요. 파일 출처를 확인한 뒤 해당 파일에 한해 조치하고, 보안 기능 전체를 끄지는 마세요.

  5. 일반 사용자 권한으로 실행

    새 폴더에서 일반 사용자 권한으로 실행하세요. 인터페이스가 열리면 「설정」→「매개변수 설정」에서 로컬 리슨 포트를 기록합니다. 메뉴 항목은 버전에 따라 달라질 수 있으므로 실제 화면에 표시된 내용을 기준으로 하세요.

관리자 권한으로만 실행되는 경우 장기간 관리자 권한으로 실행하는 것을 해결책으로 삼지 말고 원래 프로그램 폴더와 데이터 폴더의 접근 제어를 확인하세요. 일반 로컬 프록시의 인터페이스를 실행하는 데는 보통 권한 상승이 필요하지 않습니다. TUN 모드는 가상 네트워크 어댑터와 라우팅 권한이 필요하므로 기본 실행을 복구한 뒤 별도로 테스트하세요.

설정 손상: 사용자 상태를 격리한 뒤 항목별로 복원

업데이트 중단, 강제 종료, 설정 수동 변경 후 JSON 구문 오류나 데이터베이스 읽기 오류가 발생할 수 있습니다. 인터페이스 설정, 구독 데이터베이스, 코어가 생성한 설정은 서로 다른 데이터 계층입니다. 코어에서 특정 필드가 유효하지 않다고 나와도 구독을 전부 삭제할 필요는 없으며, 인터페이스에서 데이터베이스를 읽지 못한다고 VLESS 매개변수를 수정해도 해결되지 않습니다.

System.Text.Json.JsonException

원인: JSON을 읽는 과정에서 형식이나 데이터 유형 오류가 발생했습니다. 예외 메시지 뒤에 표시된 경로와 줄 번호를 확인해 원인을 찾으세요. 해결: 오류가 가리키는 파일을 먼저 백업한 뒤 같은 버전에서 새로 생성한 설정과 비교하세요. 정체를 알 수 없는 파일을 함부로 비우지 마세요.

database is locked

원인: 다른 프로세스가 데이터베이스를 사용 중이거나 쓰기 작업이 끝나지 않았을 수 있습니다. 반드시 손상된 것은 아닙니다. 해결: 중복 실행된 인스턴스를 닫고 프로세스가 종료되었는지 확인한 뒤 다시 시도하세요. 데이터베이스가 열려 있는 동안 파일을 옮기거나 관련 파일을 삭제하지 마세요.

새 상태에서는 실행되지만 특정 설정을 복원한 뒤 다시 종료된다면 문제 범위가 해당 데이터로 좁혀집니다. VMess 또는 VLESS 노드는 실제로 사용하는 전송 및 보안 매개변수만 확인하세요. TLS, 전송 계층, 라우팅 항목을 서로 바꿔 적용하지 마세요. 복잡한 라우팅은 기본 연결을 복구한 뒤 전체 설정 가이드를 참고해 항목별로 확인하세요.

포트 충돌: PID를 확인한 뒤 프로세스 종료 또는 포트 변경

로컬 리슨 포트 충돌은 보통 프록시 코어 실행을 막지만 v2rayN 인터페이스까지 종료시키는 것은 아닙니다. 로그에 address already in use 또는 바인딩 실패가 표시되면 먼저 「설정」→「매개변수 설정」에서 로컬 리슨 설정을 확인하세요. 아래에서는 10808과 10809를 예시로 사용합니다. 모든 버전에서 이 두 포트를 모두 사용한다는 뜻은 아닙니다.

10808
로컬 리슨 포트 확인 예시
10809
다른 리슨 포트 확인 예시
20808
대체 포트 예시: 사용 전 점유 여부 확인

PowerShell에서 다음 명령을 실행해 지정한 TCP 리슨 포트의 소유 프로세스를 확인하세요. 실제 설정에서 다른 포트를 사용한다면 해당 값으로 조회해야 합니다. 결과가 없으면 이번 조회에서 해당 TCP 리슨을 찾지 못했다는 뜻이며, UDP나 다른 주소 계열까지 모두 확인된 것은 아닙니다.

Get-NetTCPConnection -State Listen -ErrorAction SilentlyContinue |
  Where-Object { $_.LocalPort -in 10808,10809,20808 } |
  Select-Object LocalAddress,LocalPort,OwningProcess

Get-Process -Name v2rayN -ErrorAction SilentlyContinue

OwningProcess의 숫자를 확인한 뒤 작업 관리자의 「세부 정보」에서 PID로 프로세스 이름과 경로를 대조하세요. 이전에 실행한 v2rayN 인스턴스가 맞다면 먼저 트레이 메뉴에서 정상 종료하세요. 정체를 모르는 PID라고 해서 시스템 서비스를 강제 종료하지 마세요. 필요한 다른 프로그램이 포트를 사용 중이면 v2rayN의 해당 리슨 포트를 사용 가능한 값으로 바꾸고 코어를 다시 시작하세요.

정리: 충돌이 발생한 리슨 포트만 변경

기존 리슨 포트를 20808로 바꾸면 브라우저의 수동 프록시, 터미널 프록시 환경 변수, 기존 포트를 참조하는 다른 앱도 함께 수정해야 합니다. 시스템 프록시를 사용한다면 실제 프록시 주소를 다시 설정하고 확인하세요. 서버의 원격 포트와 로컬 리슨 포트는 서로 다르므로 함께 바꾸지 마세요.

Linux에서는 아래 명령으로 해당 리슨 포트를 확인할 수 있습니다. 포트를 사용 중인 프로세스가 없는데도 바인딩에 실패한다면 권한 부족, 존재하지 않는 리슨 주소, 보안 정책 제한 등이 로그에 표시되는지 확인하세요. 이런 문제는 포트를 계속 바꿔도 원인을 찾을 수 없습니다.

ss -ltnp 'sport = :10808'
ss -ltnp 'sport = :10809'
ss -ltnp 'sport = :20808'

실행 복구 후: 확인 방법과 자주 묻는 질문

창이 다시 나타나는 것은 첫 단계일 뿐입니다. 기본 또는 최소한의 라우팅 설정을 유지하고 정상 작동이 확인된 노드를 선택해 코어 로그가 안정적인지 살펴보세요. 이어서 시스템 프록시를 켜고 브라우저 접속을 테스트합니다. 이후 구독 업데이트, 사용자 지정 DNS, 라우팅 규칙, TUN을 복구하되 한 번에 하나씩 변경하세요. 그래야 문제가 다시 생겼을 때 정확히 이전 상태로 되돌릴 수 있습니다.

.NET을 설치했는데도 잠깐 떴다가 사라집니다. 다음에는 무엇을 확인해야 하나요?

경고 창에서 요구한 프레임워크와 아키텍처를 다시 확인한 뒤 dotnet --list-runtimes를 실행하세요. 런타임 누락 메시지가 없다면 「Windows 로그」→「응용 프로그램」에서 예외 기록을 확인하세요. 관련 없는 주 버전을 여러 개 연달아 설치하지 마세요.

새 폴더로 옮겼는데 왜 이전 설정을 계속 읽나요?

프로그램이 별도의 사용자 데이터 폴더를 사용 중일 수 있습니다. 로그에서 실제 경로를 확인하고 프로그램을 종료한 뒤 해당 폴더를 백업해 되돌릴 수 있는 방식으로 격리 테스트를 진행하세요. 프로그램 파일만 옮겨도 새 설정이 생성된다고 보장할 수는 없습니다.

설정을 전부 삭제하면 한 번에 해결되나요?

구독, 노드, 규칙이 사라질 수 있고 실제 원인을 파악하기 더 어려워질 수도 있습니다. 먼저 백업하고 오류가 가리키는 데이터만 우선 격리하세요. 새 상태가 정상임을 확인한 뒤 설정을 나눠 복원하고 유일한 사본을 바로 삭제하지 마세요.

인터페이스는 정상인데 TUN을 켜면 실패합니다. 어떻게 해야 하나요?

먼저 TUN을 끄고 로컬 프록시로 노드와 코어를 확인하세요. 일반 프록시가 정상이라면 TUN 권한, 가상 네트워크 어댑터, 라우팅 로그를 점검하세요. 이 증상을 인터페이스 런타임 문제로 바로 단정하지 마세요.

그래도 해결되지 않으면 운영체제 버전과 아키텍처, 실제 v2rayN 버전, 패키지 유형, 오류 발생 시간, 마지막 변경 사항, 민감한 정보를 제거한 첫 오류 메시지를 정리하세요. 오류 전후의 로그도 보존하되 구독 링크, UUID, 비밀번호, 원격 주소는 숨기세요. 이 정보를 준비해 자주 묻는 질문을 더 확인하면 단순히 “실행되지 않음”이라고 설명하는 것보다 다음 점검 단계를 찾기 쉽습니다.