v2rayN 커널 시작 오류 해결: Xray 로그로 설정 문제 찾기

먼저 구분하기: 커널이 시작되지 않는 문제와 시작 후 연결 실패

v2rayN은 노드를 관리하고 설정을 생성해 커널을 실행하는 GUI 클라이언트입니다. Xray는 설정을 읽고 리스너를 열어 연결을 처리합니다. 클라이언트 창이 열려도 Xray가 정상 실행 중이라는 뜻은 아닙니다. 시스템 프록시가 켜져 있어도 프록시 주소가 설정됐을 뿐, 해당 포트에서 실제로 프로세스가 연결을 수신한다는 보장은 없습니다.

문제를 점검하는 동안에는 브라우저가 작동하지 않는 로컬 포트로 계속 연결하지 않도록 시스템 프록시를 잠시 끄세요. Windows 데스크톱에서는 보통 트레이 메뉴의 「시스템 프록시」에서 「시스템 프록시 해제」를 선택할 수 있습니다. 그런 다음 메인 창 아래의 정보 또는 로그 영역을 열고 기존 로그를 지운 뒤 커널을 한 번만 시작하거나 재시작하세요. 버전에 따라 버튼 이름이 다를 수 있으므로 이번 시작 과정에서 생성된 로그를 기준으로 판단하세요.

예를 들어 connection refused, i/o timeout 또는 TLS 핸드셰이크 오류가 웹 요청을 보낸 뒤 발생했다면, 대개 설정 로드 단계의 문제는 아닙니다. 로그 시각과 로컬 포트 상태를 먼저 확인하고, 영어 오류 문구 하나만 보고 커널 시작 실패로 판단하지 마세요.

로그 읽기: 마지막 한 줄만 복사하지 말고 오류 체인 보존하기

Xray 오류는 여러 단계로 감싸져 표시되는 경우가 많습니다. 바깥쪽에는 Failed to start만 표시될 수 있고, 중간 단계에서 설정 파일을 가리키며, 가장 안쪽에서 특정 포트나 프로토콜 필드, 리소스 파일의 문제를 설명할 수 있습니다. 로그의 >는 오류 원인을 이어 주는 기호로, 입력해야 하는 명령이 아닙니다.

1. 환경 기록: 클라이언트의 「도움말」→「정보」 또는 해당 버전 정보 메뉴에서 v2rayN 버전을 기록하고, 시작 로그에서 Xray 버전을 확인하세요. 클라이언트 버전과 커널 버전을 혼동하지 마세요.
2. 한 번의 시작 로그 전체 보존: 커널을 호출하는 첫 줄부터 종료 메시지까지 저장하세요. 연속으로 여러 번 재시도한 로그를 한데 섞지 마세요.
3. 구체적인 오류 찾기: bind, invalid, failed to load, not found를 검색하고 앞뒤 몇 줄도 함께 확인하세요.
4. 설정 출처 구분: 현재 선택한 항목이 일반 노드인지 사용자 지정 설정인지 확인하세요. 일반 노드는 노드 편집 창과 클라이언트 설정부터 수정하고, 사용자 지정 설정은 실제로 읽어들이는 JSON 파일을 확인해야 합니다.

현재 로그에 정보가 부족하면 「설정」→「매개변수 설정」에서 로그 수준을 찾아 잠시 info로 바꾼 뒤 한 번 재시작하세요. 그래도 원인을 찾기 어렵다면 잠깐 debug를 사용해 보세요. 디버그 로그에는 접속 대상이 포함될 수 있으므로 점검이 끝나면 로그 수준을 원래대로 돌리고, 장기간 기록하거나 공개적으로 업로드하지 마세요.

포트 충돌: 먼저 점유 프로세스를 찾고 로컬 리스너를 변경하세요

포트 충돌은 로컬에서 발생하며 원격 서버의 가동 여부와는 관계가 없습니다. v2rayN을 두 번 실행했거나 이전 커널이 계속 실행 중인 경우, 또는 다른 프로그램이 같은 리스닝 주소와 포트를 사용하는 경우가 흔합니다. 아래의 10808은 예시일 뿐이므로 실제 점검에는 로그에 표시된 포트를 사용하세요.

Windows에서는 PowerShell을 열어 리스닝 포트와 해당 프로세스를 먼저 조회할 수 있습니다. 아래 명령은 정보를 확인할 뿐 프로세스를 종료하지 않습니다.

Get-NetTCPConnection -State Listen -LocalPort 10808 -ErrorAction SilentlyContinue |
  Select-Object LocalAddress, LocalPort, OwningProcess

Get-NetTCPConnection -State Listen -LocalPort 10808 -ErrorAction SilentlyContinue |
  ForEach-Object { Get-Process -Id $_.OwningProcess }

점유한 프로세스가 중복 실행된 클라이언트라면 해당 프로그램의 종료 기능을 사용하세요. 정체를 모르는 시스템 프로세스를 직접 종료하지 마세요. 리스닝 포트를 10808에서 10818로 바꾸려면 「설정」→「매개변수 설정」에서 로컬 리스닝 포트를 찾으세요. 일부 버전에서는 로컬 혼합 리스닝 포트로 표시됩니다. 저장한 뒤 커널을 재시작하고 프록시 주소를 직접 입력한 앱도 업데이트하세요.

JSON 문법 오류: 구조를 먼저 고친 다음 프로토콜 의미를 확인하세요

JSON 파싱에 실패했다면 커널은 아직 정상적인 연결 절차를 시작하지 않은 상태입니다. 일반 노드의 실행 설정은 v2rayN이 생성하므로 생성된 파일을 직접 편집해도 다음 시작 때 덮어써질 수 있습니다. 노드 편집 창이나 관련 설정으로 돌아가 원본을 수정하세요. 사용자 지정 설정을 사용하는 경우에만 실제로 읽어들이는 JSON 파일을 직접 확인하면 됩니다.

아래 예시는 log 설정의 문법만 보여 주며, 프록시 트래픽을 처리할 수 있는 완전한 설정이 아닙니다. 잘못된 예시는 "warning" 뒤에 쉼표가 하나 더 있습니다.

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

올바른 JSON 표기는 다음과 같습니다. 한국어 곡선 따옴표는 영문 큰따옴표를 대신할 수 없습니다. JSON 숫자와 불리언 값도 함부로 문자열로 바꾸지 마세요.

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

• 문법을 먼저, 의미는 그다음: JSON 파싱에 성공했다는 것은 구조를 읽을 수 있다는 뜻일 뿐, 프로토콜과 전송 계층 설정이 서버와 일치한다는 의미는 아닙니다.
• 행 번호에 주의: 로그에 표시된 위치는 파서가 문제를 발견한 곳일 수 있으며, 실제 오류는 바로 앞 행에 있을 수도 있습니다.
• 온라인 도구에 설정을 붙여 넣지 마세요: 인증 정보가 포함된 설정은 로컬에서 확인하고 공개 포맷터에 업로드하지 마세요.

프로토콜 필드 누락: 노드 편집 창에서 수정하세요

JSON을 읽은 뒤에도 Xray는 프로토콜과 전송 설정을 검사합니다. VMess, VLESS, Trojan은 필요한 인증 정보가 서로 다르므로 프로토콜 이름만 바꿔서는 전환할 수 없습니다. VLESS에서는 UUID를 사용자 식별자로 흔히 사용하고, Trojan은 비밀번호를 사용합니다. TLS, REALITY, 전송 방식, flow도 서버와 합의한 설정과 일치해야 합니다.

시작 오류가 없다고 해서 모든 필드가 올바른 것은 아닙니다. 예를 들어 TLS 서버 이름과 인증서가 일치하지 않는 문제는 원격 서버에 연결할 때 드러나는 경우가 많습니다. 인증서 검증을 건너뛰도록 설정해 문제를 가리지 마세요. 먼저 기기 시간, 서버 이름, 서버 인증서를 확인하세요. REALITY 인증 매개변수는 해당 버전과 서버 요구 사항에 맞춰 입력해야 하며 일반 TLS 설정을 그대로 적용할 수 없습니다.

구독 노드를 수정해도 이후 업데이트에서 원본 매개변수가 다시 가져와질 수 있습니다. 문제를 확인하는 목적이라면 노드를 복제해 로컬 테스트용으로 사용하고 용도를 명확히 표시하세요. 원본 데이터의 문제로 확인되면 구독 원본을 수정하세요. 임시 수정 사항이 구독에 계속 적용된다고 오해하지 마세요.

커널 및 규칙 파일 누락: 로그에 표시된 경로를 따라 복구하세요

Xray 실행 파일을 찾을 수 없는 경우 대개 프로세스 생성 단계에서 실패합니다. geoip.dat 또는 geosite.dat을 찾을 수 없다면 프로세스는 이미 실행됐지만 해당 리소스를 참조하는 라우팅 규칙을 불러오는 데 실패했을 수 있습니다. 두 문제는 따로 해결해야 하며 구독을 업데이트하는 것만으로 모두 해결되지는 않습니다.

1. 설치 방식 확인: 압축 파일을 사용했다면 일반 폴더에 전체 압축을 푼 뒤 실행하세요. 압축 파일 안에서 프로그램을 바로 열지 마세요.
2. 아키텍처 확인: 시스템 아키텍처에 맞는 설치 파일과 커널을 선택하세요. 아키텍처가 맞지 않으면 파일 누락이 아니라 실행 불가로 나타날 수 있습니다.
3. 보안 소프트웨어 기록 확인: 먼저 파일 출처와 격리 사유를 확인한 뒤 시스템 절차에 따라 처리하세요. 보호 기능 전체를 끄는 것을 일반적인 문제 해결 방법으로 삼지 마세요.
4. 라우팅 리소스 확인: 로그에 규칙 분류가 없다고 표시되면 규칙 데이터를 업데이트하거나 분류명을 수정하세요. 파일이 존재해도 필요한 분류가 들어 있다는 보장은 없습니다.

설치 파일을 복구해야 한다면 클라이언트 다운로드 페이지에서 플랫폼에 맞는 설치 파일을 선택하세요. 직접 관리하는 설정을 먼저 백업한 뒤 프로그램 파일을 복구하세요. 문제를 점검하는 동안 사용자 데이터 폴더 전체를 함부로 삭제하지 마세요. 일반적인 파일 누락 문제를 해결하려고 관리자 권한을 먼저 사용하는 것도 피하세요. 로그에 권한 문제가 명확히 표시된 경우에만 해당 경로를 대상으로 조치하세요.

수정 후 검증: 한 번에 한 항목만 변경하세요

항목을 하나씩 수정할 때마다 다시 시작하고 새 로그를 저장하세요. 먼저 설정이 정상적으로 로드됐는지, 다음으로 로컬 리스너가 열렸는지 확인한 후 앱에서 요청을 한 번 보내 보세요. 이렇게 하면 “기존 시작 오류가 해결된 것”과 “이후 새로운 원격 연결 문제가 발생한 것”을 구분할 수 있습니다. 두 문제가 동시에 있을 수도 있지만 포트, 프로토콜, DNS, 라우팅을 한꺼번에 변경하지 마세요.

• 첫 번째: 같은 시작 로그에서 치명적인 오류가 뒤따르거나 프로세스가 종료되지 않았는지 확인하세요. 시작 메시지를 봤다는 이유만으로 점검을 멈추지 마세요.
• 두 번째: 앞서 안내한 PowerShell 명령으로 실제 포트를 조회해 리스닝 프로세스가 이번에 시작한 커널인지 확인하세요.
• 세 번째: 시스템 프록시를 다시 켜고 브라우저나 대상 앱이 사용하는 프록시 연결 지점을 확인한 다음 요청을 한 번 보내고 로그를 살펴보세요.
• 네 번째: 연결 시간 초과나 핸드셰이크 오류만 나타난다면 원격 매개변수를 점검하세요. 로드에 성공한 JSON 구조를 계속 수정하지 마세요.

마지막으로 커널 버전, 실패를 일으킨 설정 항목, 수정 후 정상적으로 리스닝한 포트까지 세 가지를 명확히 기록하세요. 이는 “재설치하니 해결됨”보다 다시 활용하기 좋고, 다음 업데이트나 구독 가져오기, 라우팅 변경 때도 빠르게 원인을 추적할 수 있습니다.