v2rayN 코어 시작 실패 해결 방법: 로그로 설정 오류를 한 줄씩 찾기

먼저 어느 단계에서 실패했는지 확인하기

v2rayN은 관리 인터페이스이며, 인바운드를 만들고 라우팅을 수행하며 원격 서버에 연결하는 역할은 Xray 또는 v2fly 코어가 담당합니다. 시작을 클릭하면 클라이언트가 노드와 라우팅 설정을 읽어 실행 설정을 생성한 다음 선택한 코어를 호출합니다. 생성된 설정을 해석할 수 없거나 포트를 열 수 없거나 필수 필드가 누락되면 코어가 1초 안에 종료될 수 있습니다.

“시작 실패”와 “시작은 됐지만 인터넷에 연결되지 않음”은 같은 방식으로 처리하면 안 됩니다. 전자는 계속 실행 중인 Core 프로세스가 보이지 않고 로컬 포트도 리슨 상태가 되지 않는 경우가 많습니다. 후자는 “started”와 같은 시작 로그가 보이지만 웹사이트에 접속할 때 연결 시간 초과, 도메인 확인 실패 또는 TLS 핸드셰이크 오류가 발생합니다. 단계를 먼저 구분하면 노드만 계속 바꾸면서 실제 중단 지점을 놓치는 일을 피할 수 있습니다.

1. 로그 열기

   v2rayN 메인 창에서 「도움말」→「로그 보기」로 이동합니다. 현재 버전에서 “정보” 영역이 바로 표시된다면 해당 영역으로 전환한 뒤 이전 기록을 삭제합니다.

2. 코어 확인

   「설정」→「매개변수 설정」→「Core 유형」으로 이동해 VMess, VLESS 등의 노드가 실제로 Xray에 할당되어 있는지 확인합니다. 삭제했거나 경로가 잘못된 코어가 계속 호출되지 않도록 합니다.

3. 다시 실행하기

   먼저 서비스를 중지하고 3초간 기다린 뒤 다시 시작합니다. 이번 시작에서 생성된 로그만 남기고 구독 업데이트 기록과 이전 연결 오류는 판단에 섞지 마세요.

4. 첫 오류 저장

   아래쪽에서 위로 살펴보며 처음 나타난 error, failed, panic 또는 fatal 행을 찾고, 앞뒤 각 5행을 텍스트 파일에 복사합니다.

시간순으로 코어 로그 읽기

코어 로그는 보통 시간순으로 출력됩니다. 첫 번째 구간은 버전과 시작 매개변수, 두 번째는 설정을 읽은 결과, 세 번째는 포트 리슨과 아웃바운드 연결입니다. 문제를 찾을 때는 마지막 줄의 “exited”나 “stopped”만 보지 말고 흐름을 처음 중단시킨 오류를 찾아야 합니다. 종료 메시지는 결과일 뿐 그 자체로 근본 원인을 알려주는 경우는 드뭅니다.

2026/07/29 10:18:42 [Info] Xray 25.6.8 started
2026/07/29 10:18:42 [Info] loading config: config.json
2026/07/29 10:18:42 [Error] failed to listen TCP on 127.0.0.1:10809
2026/07/29 10:18:42 [Error] listen tcp 127.0.0.1:10809: bind: address already in use
2026/07/29 10:18:42 [Info] core exited with code 1

이 예시에서 실제로 중요한 부분은 네 번째 줄입니다. 첫 번째 줄은 Xray 프로세스가 호출되었음을, 두 번째 줄은 설정 파일을 읽을 수 있음을 보여 줍니다. 세 번째와 네 번째 줄은 실패 지점을 로컬 10809 포트로 좁혀 주며, 마지막 줄은 프로세스가 0이 아닌 상태로 종료되었다는 뜻일 뿐입니다. 따라서 이때는 서버 주소, UUID 또는 전송 방식을 바꿀 필요 없이 먼저 로컬 포트 충돌을 해결해야 합니다.

포트 충돌과 프로세스 중복 해결 방법

v2rayN에서 자주 사용하는 로컬 포트는 SOCKS 포트 10808과 HTTP 포트 10809이지만 실제 값은 「설정」→「매개변수 설정」→「기본 설정」의 로컬 리슨 설정을 기준으로 합니다. 다른 v2rayN 인스턴스, 이전 Core 프로세스 또는 다른 네트워크 프로그램이 같은 포트를 이미 사용 중이면 새 코어가 인바운드 리슨을 만들 수 없습니다.

Windows 터미널에서는 포트에 대응하는 프로세스 ID를 바로 조회할 수 있습니다. 아래 명령은 현재 리슨 상태만 읽으며 마지막 열이 PID입니다. 명령 결과가 없다면 해당 포트를 TCP 프로세스가 현재 리슨하고 있지 않다는 뜻이므로 설정 생성과 권한 문제를 계속 확인해야 합니다.

netstat -ano | findstr :10808
netstat -ano | findstr :10809
tasklist | findstr 4320

• PID가 다른 v2rayN 인스턴스를 가리킨다면 작업 표시줄에서 해당 인스턴스를 종료하세요. 메인 창만 닫아서는 안 됩니다.
• PID가 이전 Xray 또는 v2fly 프로세스를 가리킨다면 현재 클라이언트에서 먼저 서비스를 중지한 뒤 남은 프로세스를 종료합니다.
• 포트를 반드시 실행해야 하는 프로그램이 사용 중이라면 「설정」→「매개변수 설정」에서 v2rayN 로컬 포트를 변경하고 브라우저나 다른 애플리케이션의 수동 프록시 포트도 함께 업데이트합니다.
• 변경 후 조회 명령을 다시 실행해 새 포트를 이번에 시작한 Core 프로세스가 리슨하고 있는지 확인합니다.

JSON 형식 오류와 프로토콜 필드 누락

구독으로 가져온 노드는 v2rayN에서 Core가 읽을 수 있는 JSON으로 변환됩니다. 노드를 직접 편집하거나 불완전한 공유 내용을 가져오거나 사용자 지정 설정을 수정하면 쉼표 누락, 닫히지 않은 괄호, 숫자의 문자열 입력 같은 문제가 발생할 수 있습니다. 로그에는 대개 행과 열 번호가 표시되므로 먼저 문법 위치를 찾은 다음 해당 위치 앞의 필드를 확인해야 합니다.

{
  "address": "edge.example.net",
  "port": 443,
  "id": "00000000-1111-4222-8333-444444444444",
  "security": "auto",
  "network": "tcp"
}

위 내용은 필드 유형을 이해하기 위한 일부 예시이며 실행 설정 전체를 그대로 대체하는 파일이 아닙니다. 포트는 숫자여야 하고 주소와 UUID는 문자열이어야 합니다. 로그가 특정 행의 시작 부분을 가리키더라도 실제 누락된 쉼표는 이전 행 끝에 있는 경우가 많습니다. 오류가 난 필드만 삭제하지 마세요. 문법을 통과한 뒤에도 프로토콜 필수 항목이 없어 다시 실패할 수 있습니다.

노드 하나만 시작에 실패하고 같은 그룹의 다른 노드는 정상적으로 시작된다면 먼저 구독을 다시 업데이트하고 해당 노드의 필드를 확인하세요. 모든 노드에서 같은 행에 JSON 오류가 발생한다면 전역 라우팅, 사용자 지정 DNS 또는 템플릿 설정이 손상되었을 가능성이 큽니다. 두 경우는 문제 범위가 다르므로 처리 방법도 달라집니다.

주소 확인, TLS와 Core 유형 오류

설정 문법을 통과하면 로그에 dial, lookup, certificate 또는 handshake가 나타나기 시작할 수 있습니다. 이때 Core는 대개 로컬 리슨을 완료했으며 오류는 원격 연결 단계에서 발생합니다. 오류 대상이 노드 도메인인지, 로컬 DNS 주소인지, 인증서 이름인지 먼저 확인하세요. 모든 timeout을 같은 원인으로 보아서는 안 됩니다.

시스템 시간 오차도 인증서 유효 기간 판단에 영향을 줍니다. 시간, 시간대와 자동 동기화 상태를 바로잡은 뒤 다시 연결하는 편이 인증서 검증 옵션을 직접 변경하는 것보다 문제 범위를 잘 보존합니다. 로그에 인증서 이름과 대상 SNI가 일치하지 않는다고 명확히 표시된다면 노드 편집 창으로 돌아가 서버 이름을 수정해야 합니다.

2026/07/29 10:31:08 [Info] dialing tcp: edge.example.net:443
2026/07/29 10:31:08 [Error] tls: failed to verify certificate
2026/07/29 10:31:08 [Error] certificate is valid for node.example.net, not edge.example.net

이러한 기록에는 이미 두 도메인이 표시됩니다. 연결 주소는 edge.example.net일 수 있지만 서버 인증서가 node.example.net에 해당한다면 SNI는 일반적으로 노드 설정에 따라 인증서에 포함된 이름으로 입력해야 합니다. 정확한 값은 유효한 구독이나 서버 설정에서 확인해야 하며 오류 문구만 보고 임의로 추측해서는 안 됩니다.

최소 설정으로 복구하고 결과 확인하기

로그에 여러 종류의 오류가 동시에 나타날 때는 변수를 줄이는 것이 가장 안전합니다. 출처가 확실한 노드 하나만 남기고 기본 라우팅과 기본 DNS를 임시로 사용하며 테스트하지 않는 사용자 지정 인바운드는 끈 뒤 Core를 시작하세요. 최소 설정을 사용하면 구독 데이터, 전역 규칙과 로컬 리슨을 분리해 확인할 수 있습니다.

1. 설정 백업

   현재 로컬 포트, Core 유형, DNS와 라우팅 모드를 기록하고 중요한 로그를 저장합니다. 복잡한 분기 규칙을 기억에 의존해 복구하지 마세요.

2. 구독 업데이트

   「구독 그룹」에서 해당 그룹을 선택해 업데이트를 실행한 다음 필드가 완전하고 최근에 사용 가능한 노드 하나만 선택해 테스트합니다.

3. 기본값 복원

   사용자 지정 JSON, 추가 인바운드와 직접 작성한 DNS 규칙을 잠시 비활성화하고 기본 로컬 리슨 설정과 기본 라우팅만 남깁니다.

4. 코어 시작

   로그를 삭제한 뒤 한 번 시작하고 10초간 기다립니다. 로그에 started, 리슨 주소와 포트가 나타나며 바로 뒤에 fatal 또는 exited code 1이 나오지 않는지 확인합니다.

5. 항목별로 다시 적용

   한 번에 설정 하나만 복원하고 다시 시작합니다. 복원한 뒤 처음 오류가 발생한 항목이 문제 범위입니다.

정상 상태라면 최소한 세 가지를 만족해야 합니다. Core 프로세스가 계속 실행되고, 로컬 프록시 포트가 계속 리슨 상태이며, 요청을 보낼 때 로그에 정상적인 아웃바운드 기록이 나타나야 합니다. 시작 성공만 표시되고 요청 로그가 전혀 없다면 시스템 프록시가 활성화되어 있는지, 애플리케이션이 실제로 v2rayN이 제공하는 프록시 포트를 사용하는지도 확인해야 합니다.