V2Ray 코어가 시작되지 않을 때: 로그로 config.json 설정 오류 찾기

먼저 시작 단계에서 실패했는지 확인하기

코어 시작 실패와 노드 연결 실패는 서로 다른 문제입니다. 시작에 실패하면 V2Ray 또는 Xray 프로세스가 보통 config.json을 읽거나 인바운드 리스너를 만들거나 아웃바운드 설정을 초기화하는 과정에서 종료됩니다. 반면 노드 연결 실패는 코어가 실행 중인 상태에서 대상 접속이 시간 초과되거나 핸드셰이크에 실패하거나 서버가 거부하는 경우입니다. 점검 방법도 다르므로 단순히 웹 페이지가 열리지 않는다는 이유만으로 판단해서는 안 됩니다.

로그를 연 다음 위쪽으로 이동해 이번 시작 과정의 첫 번째 error 또는 failed를 찾으세요. 뒤에 나오는 프로세스 종료나 재시작 실패는 결과일 뿐이며, 실제 원인은 대개 앞의 한 줄에서 다섯 줄 안에 있습니다. 예를 들어 설정 파싱 오류는 먼저 문자 위치를 표시한 뒤 코어 종료 코드를 보여 주고, 포트 충돌은 먼저 리스닝 주소를 표시한 뒤 시작 실패를 보고합니다.

v2rayN 7.x를 예로 들면, 먼저 「설정」→「매개변수 설정」→「Core 유형」에서 현재 노드가 Xray Core를 사용하는지 v2fly Core를 사용하는지 확인한 뒤 메인 화면에서 로그 영역을 여세요. Core 유형을 변경했다면 한 번 다시 시작해 현재 코어가 생성한 새 기록만 남기세요. 이전 설정의 오류를 현재 문제로 오해하는 일을 줄일 수 있습니다.

1. 코어 중지

   클라이언트에서 중지 작업을 실행하고 로그에 프로세스 종료 정보가 나타날 때까지 기다립니다. 기존 프로세스가 로컬 리스닝 포트를 더 이상 사용하지 않는지도 확인하세요.

2. 로그 지우기

   로그 창을 비우거나 현재 시간을 기록한 다음 코어를 한 번만 시작하세요. 연속 재시도로 같은 오류가 반복 기록되는 것을 막을 수 있습니다.

3. 첫 오류 찾기

   새 로그의 위쪽부터 내려오며 failed, error, invalid 또는 unknown이 포함된 첫 기록을 찾습니다.

4. 주변 로그 기록

   오류 행 앞뒤의 각 세 줄을 보관하고 설정 파일 경로, 행·열 위치, 리스닝 포트와 아웃바운드 태그를 기록하세요.

5. 한 번에 하나씩 수정

   한 번에 한 문제만 수정하고 저장한 뒤 다시 시작하세요. 여러 필드를 동시에 변경하면 새 로그만으로 어떤 수정이 적용됐는지 판단하기 어렵습니다.

JSON 문법 오류: 행·열 위치를 기준으로 구조 수정

config.json은 표준 JSON 문법을 따라야 합니다. 키 이름과 문자열에는 반각 큰따옴표를 사용하고, 배열과 객체는 각각 대괄호와 중괄호로 작성하며, 인접한 필드 사이는 쉼표로 구분해야 합니다. 마지막 필드 뒤에는 불필요한 쉼표를 둘 수 없습니다. 중국어 입력기에서 생긴 곡선 따옴표, 빠진 따옴표, 복사 과정에서 섞인 주석 때문에 코어가 프로토콜 매개변수를 처리하기도 전에 중단될 수 있습니다.

아래 조각은 port 행 끝에 쉼표가 빠져 있어 파서가 다음 행의 protocol을 읽지 못합니다. 로그의 행 번호는 때때로 문제가 발견된 위치를 가리키므로, 실제로 빠진 문자는 바로 앞 행에 있을 수 있습니다.

{
  "inbounds": [
    {
      "listen": "127.0.0.1",
      "port": 10808
      "protocol": "socks"
    }
  ]
}

수정할 때 오류가 표시된 문자만 보지 마세요. 안내된 위치에서 위로 올라가 가장 가까운 중괄호 묶음을 확인하고, 각 객체의 키-값 쌍이 올바르게 구분되어 있는지 점검해야 합니다. 파일 처음부터 끝까지 괄호가 쌍을 이루는지도 확인하세요. 편집기가 JSON 서식 지정을 지원한다면 먼저 실행하세요. 서식 지정이 되지 않는다면 구조가 아직 닫히지 않았을 가능성이 큽니다.

• 중국어식 따옴표를 반각 큰따옴표로 바꾸고, 특히 서버 주소, UUID, 태그와 프로토콜 이름을 확인하세요.
• 숫자에 단위가 붙은 문자열로 작성되지 않았는지 확인하세요. 예를 들어 포트는 10808로 써야 하며 10808포트로 작성하면 안 됩니다.
• 불리언 값은 소문자 true 또는 false를 사용하고, 따옴표로 감싼 텍스트로 작성하지 마세요.
• 완전한 텍스트로 저장한 뒤 코어를 다시 시작하세요. 미리 보기 창에서만 수정하고 디스크에 저장되지 않은 사본을 사용하지 않도록 합니다.

포트 충돌: 충돌 프로세스와 중복 인바운드 찾기

JSON을 정상적으로 파싱하면 코어는 인바운드 리스너를 차례로 생성합니다. v2rayN의 이전 프로세스가 종료되지 않았거나 다른 로컬 네트워크 도구가 같은 포트를 사용하거나 config.json의 두 인바운드가 같은 주소와 포트를 사용하면 리스닝 단계에서 시작이 중단됩니다. 로그에는 보통 listen, bind, address already in use 같은 키워드가 표시됩니다.

일반적인 테스트 설정에서는 SOCKS 인바운드를 127.0.0.1:10808, HTTP 인바운드를 127.0.0.1:10809에 둡니다. 이 숫자가 모든 클라이언트 버전에서 고정된 값은 아니므로 실제 점검에서는 로그와 현재 매개변수 설정을 기준으로 삼으세요. 로그에 충돌 포트가 10808로 표시되면 10808만 확인하고 원격 서버 포트까지 동시에 변경할 필요는 없습니다.

Windows에서는 터미널에서 다음 명령을 실행해 10808을 사용하는 프로세스 번호를 확인할 수 있습니다. 결과의 마지막 열이 6420이라고 가정하면 두 번째 명령으로 프로세스 이름을 조회하세요. 포트가 사용 중이라는 이유만으로 임의의 시스템 프로세스를 종료하지 말고, 먼저 종료되지 않은 이전 코어 인스턴스인지 확인해야 합니다.

netstat -ano | findstr :10808
tasklist /FI "PID eq 6420"

결론: 포트를 먼저 해제한 뒤 번호 변경 검토

이전 프로세스가 남아 있을 때 10810으로 바꾸면 충돌을 잠시 피할 수 있을 뿐이며 시스템 프록시는 계속 이전 포트를 가리킵니다. 먼저 남은 인스턴스를 종료하고 포트가 해제됐는지 확인하세요. 포트를 다른 필수 프로그램이 계속 사용해야 할 때만 인바운드 포트와 시스템 프록시 설정을 함께 변경해야 합니다.

필드 오타: 계층, 코어와 설정 형식 구분하기

필드 이름을 올바르게 입력했더라도 잘못된 계층에 배치하면 설정 불러오기에 실패할 수 있습니다. TLS의 서버 이름을 예로 들면 serverName은 해당 전송 보안 설정 안에 있어야 하며 outbound 루트에 임의로 둘 수 없습니다. settings를 setting으로 쓰거나 streamSettings를 streamSetting으로 쓰는 경우, 배열 필드를 단일 객체로 작성하는 경우도 같은 문제를 일으킵니다.

서로 다른 코어 또는 버전의 설정 조각을 섞는 것도 흔한 원인입니다. v2rayN은 노드와 Core 유형에 따라 설정을 생성할 수 있지만 Xray Core와 v2fly Core는 일부 프로토콜, 플로우 값과 전송 필드의 지원 범위가 완전히 같지 않습니다. 한 코어에서 작동하는 설정이 Core 유형을 그대로 바꾼 뒤에도 불러와진다고 보장할 수 없습니다.

{
  "outbounds": [
    {
      "tag": "proxy",
      "protocol": "vless",
      "settings": {
        "vnext": []
      },
      "streamSettings": {
        "security": "tls",
        "tlsSettings": {
          "serverName": "example.com"
        }
      }
    }
  ]
}

1. v2rayN의 「설정」→「매개변수 설정」→「Core 유형」에서 선택한 코어가 노드 프로토콜과 일치하는지 확인하세요.
2. 로그에 표시된 실제 설정 경로를 확인해 백업 파일이나 이전 디렉터리의 config.json을 편집한 것이 아닌지 점검하세요.
3. 복잡한 설정을 인바운드 하나와 아웃바운드 하나로 줄이고, 시작되는 것을 확인한 뒤 DNS, 라우팅과 추가 인바운드를 복원하세요.
4. 오류가 구독 노드에서 발생했다면 클라이언트에서 노드 매개변수를 편집한 뒤 설정을 다시 생성하세요. 실행 중인 임시 파일만 수정하지 마세요.

결론: 알 수 없는 필드는 위치를 바꿔 가며 해결할 수 없음

먼저 현재 Core 유형과 설정 형식을 확인한 다음 필드가 속한 객체를 검토하세요. 필드를 여러 계층으로 반복 이동하면 오류 하나는 사라질 수 있지만 의미가 잘못되어 코어가 시작된 뒤에도 연결되지 않을 수 있습니다.

프로토콜 매개변수 누락: 인바운드부터 아웃바운드까지 단계별 점검

JSON 문법과 필드 계층이 모두 올바른 뒤에야 코어가 프로토콜 매개변수를 검사합니다. VMess에서는 사용자 ID 형식 오류가 흔하고, VLESS에서는 주소, 포트, 사용자 ID, 암호화 값 또는 플로우 매개변수 불일치가 자주 발생합니다. TLS를 사용한다면 보안 유형과 서버 이름도 확인해야 합니다. 매개변수 누락이 반드시 missing으로 표시되는 것은 아니며, 사용자를 파싱하지 못하거나 UUID가 유효하지 않거나 지원되지 않는 플로우 값이라는 메시지로 나타날 수도 있습니다.

구독을 가져온 뒤 이런 오류가 발생하면 먼저 클라이언트에서 해당 노드의 편집 화면을 열고 서버 주소 앞뒤의 공백, 1~65535 범위의 포트, 완전한 사용자 ID, 일치하는 프로토콜과 전송 유형을 확인하세요. 구독 주소 자체를 노드 서버 주소로 사용하거나 로컬 10808 포트를 원격 서버 포트 위치에 입력하지 마세요.

프로세스가 어느 단계에서 멈췄는지가 점검 범위를 결정합니다. 로그에 로컬 포트 리스닝 성공이 표시된 뒤 라우팅 태그가 없다고 보고된다면 SOCKS 인바운드로 돌아가 수정할 필요가 없습니다. 아웃바운드 사용자를 파싱하다 종료됐다면 DNS와 라우팅은 아직 작동하지 않은 것이므로 노드 프로토콜 매개변수를 우선 처리하세요.

최소 설정 방법: 오류 범위 줄이기

로그에 여러 설정 오류가 동시에 나타날 때 가장 효과적인 방법은 모든 필드를 한 번에 수정하는 것이 아니라 실행 가능한 최소 설정을 만드는 것입니다. 먼저 로컬 인바운드 하나와 매개변수가 완전한 아웃바운드 하나만 남기고 사용자 지정 DNS, 라우팅 규칙, 추가 인바운드와 복잡한 전송 옵션은 잠시 제거하세요. 코어가 계속 실행되면 모듈별로 하나씩 복원합니다.

모듈을 하나 복원할 때마다 중지, 시작과 로컬 연결 테스트를 한 번씩 실행하세요. 예를 들어 먼저 DNS를 복원해 도메인 확인 오류가 없는지 확인하고, routing을 복원해 규칙이 참조하는 inboundTag와 outboundTag가 모두 존재하는지 확인한 뒤 추가 리스너를 복원합니다. 이렇게 하면 수십 개 필드에서 오류를 찾는 대신 방금 추가한 모듈 하나만 점검할 수 있습니다.

1. 인바운드 유지

   127.0.0.1에서 리스닝하는 로컬 인바운드 하나만 남기고, 현재 사용되지 않는 높은 포트를 사용하세요.

2. 아웃바운드 유지

   매개변수가 완전한 VMess 또는 VLESS 아웃바운드 하나만 남기고, 테스트에 사용하지 않는 예비 노드는 삭제하세요.

3. 라우팅 일시 중지

   사용자 지정 routing 규칙을 잠시 제거해 삭제된 태그 참조가 시작 판단을 방해하지 않도록 하세요.

4. 시작 재테스트

   로그에 더 이상 설정 오류가 나타나지 않고 프로세스가 3초 이상 실행되며 로컬 리스닝 포트가 유지되는지 확인하세요.

5. 항목별 복원

   DNS, 라우팅, 추가 인바운드, 전송 옵션 순서로 복원하고 매번 하나의 모듈만 추가하세요.

시작 성공 확인: 로그·포트·연결을 모두 통과해야 함

설정 오류가 사라진 것은 첫 단계일 뿐입니다. 실제 시작 성공은 세 가지 조건을 모두 충족해야 합니다. 코어 프로세스가 즉시 종료되지 않고, 로컬 인바운드 포트가 리스닝 상태이며, 클라이언트의 테스트 요청이 해당 아웃바운드를 통과해야 합니다. 설정을 불러왔다는 메시지만 확인한 뒤 프로세스가 종료된다면 복구된 것으로 볼 수 없습니다.

시작 후 3~10초 동안 로그를 먼저 관찰하세요. 실행 정보가 계속 출력되고 새로운 failed to start, panic 또는 종료 코드가 없다면 포트를 확인합니다. Windows에서 netstat -ano | findstr :10808을 다시 실행하면 현재 코어 프로세스에 해당하는 리스닝 기록이 보여야 합니다. 클라이언트가 다른 포트로 설정되어 있다면 명령의 숫자를 바꾸세요.

그다음 클라이언트에 내장된 지연 시간 테스트나 접속 테스트를 한 번 실행하세요. 이때 TLS 핸드셰이크, 서버 시간 초과 또는 연결 거부가 나타난다면 시작 문제는 해결되었고 장애가 원격 연결 단계로 넘어간 것입니다. 이후에는 JSON 괄호를 계속 수정하지 말고 서버 주소, 네트워크 연결, TLS serverName, 전송 방식과 노드 유효성을 확인하세요.

• 연속으로 두 번 시작해도 계속 실행되는지 확인하여 이전 프로세스가 우연히 남은 경우를 배제하세요.
• 클라이언트를 중지했을 때 로컬 리스닝이 사라지고 다시 시작한 뒤 리스닝이 복구되는지 확인하세요.
• 로그에 설정 파일의 행·열 오류, 알 수 없는 필드 또는 포트 바인딩 실패가 더 이상 나타나지 않아야 합니다.
• 시스템 프록시가 변경 전의 이전 포트가 아니라 현재 로컬 포트를 가리켜야 합니다.
• 구독을 업데이트하고 설정을 다시 생성한 뒤에도 수정 결과가 유지되어야 합니다.

결론: 시작 성공과 노드 사용 가능 여부를 나누어 확인

프로세스가 계속 실행되고 로컬 포트가 정상적으로 리스닝된다면 config.json이 시작 단계를 통과했다는 뜻입니다. 이후 나타나는 핸드셰이크나 시간 초과는 연결 경로 문제로 전환해 점검하세요. 단계별 확인을 통해 이미 올바른 설정 구조를 반복 수정하는 일을 막을 수 있습니다.

여전히 원인을 찾지 못했다면 이번 시작의 첫 오류, 앞뒤 세 줄의 로그, 현재 Core 유형, 클라이언트 버전과 문제가 발생한 설정 모듈을 함께 정리하세요. 로그를 공유하기 전 서버 주소, 사용자 ID, 구독 주소 같은 연결 자격 정보는 삭제하되 오류 유형, 필드 이름, 행·열 위치와 포트 번호는 남겨야 합니다. 이 정보가 설정 문제를 판단하는 핵심입니다.