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

먼저 v2rayN 시작 흐름부터 구분하기

시작 버튼을 눌렀다고 v2rayN이 곧바로 프록시 연결을 만드는 것은 아닙니다. 먼저 현재 서버, 라우팅, DNS, 로컬 포트 설정을 읽어 코어용 설정을 생성한 다음 Xray 또는 V2Ray 코어 프로세스를 시작합니다. 코어가 설정을 읽고 로컬 포트를 수신 대기하면 그 후에야 원격 서버 연결을 시도합니다.

따라서 ‘코어 시작 실패’와 ‘코어는 실행 중이지만 웹사이트가 열리지 않음’은 서로 다른 문제입니다. 전자는 프로세스가 나타나자마자 종료되거나 트레이 상태가 곧바로 원래대로 돌아오고, 설정 파싱 또는 수신 대기 실패가 로그에 표시되는 경우가 많습니다. 후자는 로컬 SOCKS·HTTP 포트가 이미 수신 대기 중이지만 핸드셰이크, 도메인 확인 또는 라우팅 단계에서 실패하는 경우가 일반적입니다.

문제 해결을 시작하기 전에 다음 세 가지를 확인하세요.

1. 코어 프로세스가 실제로 시작되어 계속 실행 중인가요?
2. 로컬 프록시 포트가 정상적으로 수신 대기 상태가 되었나요?
3. 첫 번째 치명적 오류는 설정 읽기, 포트 수신 대기, 원격 연결 중 어느 단계에서 발생했나요?

로그 창을 열고 한 번의 전체 시작 과정을 기록하기

v2rayN 기본 창에서 로그 영역이나 로그 창을 연 다음 현재 코어를 중지합니다. 화면을 정리한 뒤 대상 서버를 다시 선택하고 한 번만 시작하세요. 시작 버튼을 연속으로 누르면 여러 기록이 섞이고 잠시 살아 있는 이전 프로세스가 남아 포트 충돌 여부를 판단하기 어려워질 수 있습니다.

로그를 읽을 때는 먼저 타임스탬프가 방금 수행한 작업의 것인지 확인한 뒤 v2rayN 자체 출력과 코어 출력을 구분하세요. 인터페이스 계층은 설정을 생성하고 프로세스를 호출하며, Xray와 V2Ray의 출력이 실제 실패 지점에 더 가깝습니다. 주요 단서는 대략 다음과 같이 나뉩니다.

• 설정 파싱: invalid, failed to parse, unexpected, unknown field 등의 키워드가 나타납니다.
• 포트 수신 대기: bind, listen, address already in use 또는 access denied가 나타납니다.
• 프로토콜 매개변수: UUID, security, flow, transport, Reality, TLS 등의 필드명이 나타납니다.
• 파일 및 프로세스: file not found, permission denied, cannot execute 또는 경로 오류가 나타납니다.
• 원격 연결: timeout, connection refused, handshake, certificate 또는 DNS 조회 실패가 나타납니다.

로그에 ‘프로세스 종료’나 종료 코드 하나만 표시된다면 몇 줄 위로 올라가 확인하세요. 종료 코드는 프로세스가 정상적으로 끝나지 않았다는 사실은 알려 주지만 구체적인 필드까지 알려 주지는 않습니다. 실제로 조치할 수 있는 정보는 대개 그보다 앞에 있습니다. 일시적으로 로그 수준을 높일 수도 있지만, 문제를 해결한 뒤에는 일반적으로 사용하는 수준으로 되돌려 과도한 디버그 기록이 핵심 오류를 가리지 않게 하세요.

로그를 유지 관리자에게 공유하기 전에는 구독 주소, 서버 주소, 사용자 식별자, 비밀번호, Reality 공개 키 관련 설정과 전체 공유 링크를 삭제해야 합니다. 오류 유형, 필드명, 시간 순서, 클라이언트 버전과 코어 유형만 남겨도 대개 원인을 찾는 데 충분합니다.

bind 또는 address already in use가 보일 때: 포트 충돌 처리

v2rayN은 로컬 SOCKS, HTTP 등의 진입 포트를 수신 대기해야 합니다. 다른 프로그램, 이전 코어 프로세스 또는 두 번째 v2rayN 인스턴스가 같은 포트를 이미 사용 중이면 새 프로세스가 즉시 종료됩니다. 로그에는 bind failed, address already in use 또는 하나의 소켓 주소는 한 번만 사용할 수 있다는 시스템 메시지가 자주 나타납니다.

먼저 v2rayN 설정에서 현재 로컬 포트를 기록하세요. 포트가 항상 특정 고정 숫자인 것은 아니므로 현재 화면과 이번에 생성된 설정을 기준으로 확인해야 합니다. Windows 터미널에서는 아래 명령으로 사용 중인 프로세스를 확인할 수 있습니다. 예시 포트는 실제 값으로 바꾸세요.

netstat -ano | findstr :10808
tasklist /FI "PID eq 프로세스 번호"

첫 번째 명령의 끝에 프로세스 번호가 표시되고, 두 번째 명령은 이를 바탕으로 프로그램 이름을 조회합니다. 점유한 프로세스가 이전에 비정상적으로 남은 코어라면 먼저 v2rayN에서 코어를 정상적으로 중지한 뒤 프로세스가 종료되었는지 확인하세요. 다른 프록시 도구나 로컬 개발 서버라면 충돌하는 프로그램을 종료하거나 v2rayN에서 사용되지 않는 포트로 변경합니다.

포트를 변경한 뒤에는 브라우저, 터미널 환경 변수, 프록시를 수동으로 입력해야 하는 애플리케이션도 함께 확인해야 합니다. 코어는 시작되었지만 애플리케이션이 계속 이전 포트를 가리키면 ‘시작은 성공했지만 접속할 수 없음’이라는 2차 문제가 발생합니다. 충돌을 피하려고 여러 포트를 무작위로 연속 변경하지 마세요. 한 번에 한 항목만 바꾸고 변경 전후 값을 기록하세요.

parse 또는 invalid character가 보일 때: JSON과 규칙 구조 수정

v2rayN은 일반적으로 화면에서 선택한 옵션을 바탕으로 설정을 생성합니다. 사용자 지정 설정, 직접 편집한 아웃바운드, 복잡한 라우팅 규칙을 사용하거나 가져온 내용 자체가 불완전하면 코어가 파싱할 수 없는 JSON이 생성될 수 있습니다. 대표적인 로그로는 unexpected end, invalid character, failed to parse config, unknown field, cannot unmarshal 등이 있습니다.

unexpected end는 내용이 잘렸다는 뜻인 경우가 많습니다. 예를 들어 오른쪽 중괄호나 오른쪽 대괄호가 빠졌을 수 있습니다. invalid character는 불필요한 쉼표, 한글 문장 부호, 잘못된 따옴표 또는 들어가서는 안 되는 주석을 가리키는 경우가 많습니다. 표준 JSON의 키와 문자열은 영문 큰따옴표를 사용해야 하며, 마지막 항목 뒤에 불필요한 쉼표를 남겨서는 안 되고 주석을 직접 작성할 수도 없습니다.

다음과 같은 구조는 끝에 불필요한 쉼표가 있어 실패합니다.

{
  "log": {
    "loglevel": "warning",
  }
}

수정할 때는 로그에 표시된 줄 번호만 보지 마세요. 파서는 더 이상 읽을 수 없다고 판단한 위치에서 오류를 보고하는 경우가 많아 실제로 빠진 기호는 바로 앞줄에 있을 수 있습니다. 먼저 오류 줄 앞뒤의 쉼표, 따옴표, 괄호가 서로 짝을 이루는지 확인한 다음 필드 유형을 점검하세요. 예를 들어 포트가 숫자여야 한다면 추가 문자가 포함된 텍스트로 잘못 입력해서는 안 됩니다.

라우팅 설정은 구조는 올바르지만 필드 내용이 유효하지 않은 경우에도 문제가 생깁니다. 도메인 규칙, IP 규칙, 아웃바운드 태그는 서로 다른 의미를 가집니다. 존재하지 않는 outboundTag를 규칙에서 참조하면 코어가 설정을 거부하거나 실행 단계에서 예상대로 트래픽을 분기하지 못할 수 있습니다. 최근 규칙을 추가한 뒤 오류가 발생했다면 구독을 전부 삭제하기보다 해당 규칙을 먼저 비활성화하고 다시 시작하세요.

사용자 지정 설정을 쓸 때 가장 안전한 방법은 원본 파일을 먼저 복사해 보관하고, 최소 실행 구조에서 시작해 DNS, 라우팅, 아웃바운드를 단계별로 추가하는 것입니다. 한 부분을 추가할 때마다 한 번씩 시작하세요. 그러면 수백 줄의 설정을 반복해서 추측하지 않고 최근 변경 사항으로 오류 범위를 좁힐 수 있습니다.

설정은 파싱되지만 프로토콜 매개변수가 맞지 않는 경우

JSON 문법이 올바르다고 해서 연결 매개변수까지 올바른 것은 아닙니다. VMess와 VLESS는 서로 다른 프로토콜이므로 인증 필드, 전송 설정, 암호화 관련 옵션을 서로 바꿔 사용할 수 없습니다. 구독을 가져오면 v2rayN이 항목에 따라 아웃바운드 설정을 생성합니다. 구독 내용이 오래되었거나 필드가 누락되었거나 직접 수정하면서 프로토콜을 잘못 선택하면 시작 검사 또는 첫 연결 시 로그에 매개변수 오류가 표시될 수 있습니다.

VLESS 항목 확인

VLESS 항목에서는 서버 주소, 포트, 사용자 식별자, 전송 방식과 보안 계층을 최소한 확인해야 합니다. REALITY를 사용하는 경우 serverName, 공개 키, shortId, 지문, flow 등의 필드가 서버에서 제공한 정보와 일치하는지도 확인하세요. 자주 쓰이는 flow 값은 구체적인 전송 조합에 따라 달라지므로 다른 노드에서 사용한다고 그대로 복사해서는 안 됩니다.

로그에 unsupported flow, invalid public key 또는 Reality handshake가 표시되면 먼저 구독 원본으로 돌아가 항목을 업데이트하세요. 감으로 필드를 추가하지 마세요. 서버 주소가 확인되고 포트에 연결된다는 사실은 네트워크가 대상에 도달했다는 것만 증명할 뿐 REALITY 매개변수가 일치한다는 뜻은 아닙니다.

VMess 항목 확인

VMess 역시 올바른 사용자 식별자, 포트와 전송 매개변수가 필요합니다. 오래된 설정에는 alterId와 같은 이전 필드가 있을 수 있으며, 최신 서버는 일반적으로 다른 권장 설정을 사용합니다. 클라이언트 항목은 현재 서버 설정을 기준으로 해야 하며 이전 노드의 매개변수를 새 노드에 섞어서는 안 됩니다. 구독을 업데이트한 뒤 특정 VMess 노드 하나만 실패한다면 해당 노드를 복제해 비교할 수 있지만, 원본 항목을 수정해 기준을 잃지는 마세요.

전송 계층 확인

TCP, WebSocket, gRPC 등의 전송 방식은 서로 다른 필드에 대응합니다. WebSocket에는 보통 경로와 Host가 필요하고, gRPC에는 서비스 이름이 필요하며, TLS에는 serverName도 관련됩니다. 경로의 슬래시 하나가 더 있거나 서비스 이름의 대소문자가 다르거나 Host가 잘못된 대상을 가리키면 코어는 정상적으로 시작되어도 핸드셰이크 단계에서 실패할 수 있습니다.

노드 문제인지 전체 설정 문제인지 판단하려면 같은 구독에 있는, 정상 작동이 확인된 다른 서버를 테스트해 보세요. 모든 노드가 코어 시작 전에 실패한다면 로컬 설정, 포트와 코어 파일을 먼저 확인합니다. 단일 서버만 연결 단계에서 실패한다면 해당 항목의 프로토콜 매개변수와 서버 상태를 우선 점검하세요.

코어 유형, 파일 경로와 읽기·쓰기 권한 확인

v2rayN은 관리 인터페이스이며 실제 네트워크 처리는 Xray 또는 V2Ray 코어가 담당합니다. 일부 프로토콜 기능과 필드는 특정 코어 버전에서만 지원됩니다. 로그에 unknown field, unsupported security 또는 특정 Reality 설정을 인식하지 못한다는 내용이 나오면 먼저 해당 항목에서 선택한 코어 유형을 확인하고, 코어 버전이 필요한 기능을 지원하는지도 확인하세요.

설정 오류를 감추기 위해 코어를 반복해서 바꾸지는 마세요. VLESS와 REALITY 환경에는 보통 이에 맞는 Xray 기능이 필요하며, 일반 VMess 설정도 선택한 코어 형식에 맞는 필드를 사용해야 합니다. 변경 후 오류 키워드가 ‘알 수 없는 필드’에서 ‘핸드셰이크 실패’로 바뀌었다면 설정이 다음 단계까지 진행된 것이지만 원격 매개변수는 여전히 확인해야 합니다.

file not found 또는 cannot execute는 대개 코어 파일 누락, 경로 변경 또는 프로그램 실행 권한 부족을 의미합니다. 먼저 v2rayN 설정에서 코어 디렉터리를 확인한 다음 해당 파일이 실제로 존재하는지 점검하세요. 프로그램 디렉터리 전체를 옮겼거나 일부 파일만 복사했거나 이전 버전을 덮어써 업그레이드했다면 인터페이스에 기록된 경로가 여전히 이전 위치를 가리킬 수 있습니다.

설정 디렉터리에도 쓰기 권한이 필요합니다. v2rayN은 코어를 시작하기 전에 임시 설정이나 실행 설정을 생성합니다. 프로그램이 현재 계정으로 쓸 수 없는 위치에 있으면 코어 시작 전에 실패할 수 있습니다. 현재 사용자가 정상적으로 읽고 쓸 수 있는 디렉터리로 프로그램을 옮긴 뒤 다시 시작하고 로그에 설정이 생성되는지 확인하세요. 장기적인 해결책으로 항상 높은 권한으로 실행하지는 마세요. 파일 소유권이 바뀌어 이후 일반 실행에서 또 다른 읽기·쓰기 문제가 생길 수 있습니다.

보안 프로그램이나 시스템 정책이 프로세스를 차단하면 로그에는 시작 실패나 파일 접근 오류만 남는 경우가 있습니다. 이때는 시스템 보안 기록에서 실제로 차단된 파일과 규칙을 확인한 뒤 프로그램 실행을 허용할지 결정하세요. 테스트를 위해 전체 보안 기능을 끄지 마세요. 명확한 파일, 디렉터리와 프로세스 범위로 제한하는 편이 복구하기 쉽고 원인 확인에도 유리합니다.

재현 가능한 문제 해결 순서

포트, 노드, 라우팅과 DNS를 동시에 변경하면 결과를 비교할 수 없게 됩니다. 아래 순서대로 진행하고 매 단계마다 다시 시작하면서 로그의 첫 번째 오류를 기록하세요.

1. 현재 상태 저장. v2rayN 버전, 코어 유형, 대상 서버 메모, 로컬 포트와 첫 번째 오류를 기록합니다. 로그를 복사할 때는 먼저 민감한 연결 정보를 삭제하세요.
2. 이전 프로세스 중지. 인터페이스에서 코어를 중지하고 두 번째 v2rayN 인스턴스나 동일한 포트를 계속 수신 대기 중인 잔여 코어가 없는지 확인합니다.
3. 로컬 수신 대기 확인. bind 또는 access denied가 나타나면 먼저 포트와 권한 문제를 해결하고 원격 프로토콜 매개변수는 아직 변경하지 마세요.
4. 최근 변경 되돌리기. 방금 추가한 사용자 지정 라우팅, DNS 또는 아웃바운드 설정을 일시 중지하고 변경 전 상태로 되돌립니다.
5. 구독 업데이트. 기존 구독 그룹에서 업데이트를 실행한 다음 업데이트된 항목을 선택합니다. 구독 주소를 단일 노드 공유 링크로 가져오지 마세요.
6. 같은 유형의 다른 서버로 테스트. 단일 노드 매개변수 오류와 전체 설정 오류를 구분하기 위해 테스트 중에는 로컬 포트와 라우팅을 그대로 유지합니다.
7. 코어 기능 확인. unknown field 또는 unsupported가 나타나면 항목에 필요한 프로토콜 기능이 현재 코어와 일치하는지 확인합니다.
8. 트래픽 분기 설정 복원. 코어가 안정적으로 실행된 뒤 라우팅과 DNS를 항목별로 다시 활성화합니다. 한 번에 한 그룹의 규칙만 복원하세요.

최소 테스트 환경을 만들어야 한다면 잠시 기본 라우팅, 기본 DNS와 매개변수가 완전한 것으로 확인된 서버 하나만 사용하고 추가 사용자 지정 인바운드와 아웃바운드는 끄세요. 최소 설정으로 시작되는 것을 확인한 뒤 구독 그룹, 도메인 분기, IP 규칙과 사용자 지정 DNS를 차례로 추가합니다. 어느 단계에서 문제가 나타나는지에 따라 원인이 있는 설정 그룹을 좁힐 수 있습니다.

자주 묻는 질문