V2Ray 코어 시작 오류 해결: 로그로 설정 문제 찾기

1. 먼저 구분하기: 코어가 시작되지 않은 경우와 요청이 연결되지 않는 경우

v2rayN은 클라이언트 인터페이스이며, Xray와 V2Fly 같은 코어가 설정을 읽고 인바운드 리스닝과 아웃바운드 연결을 처리합니다. 인터페이스가 열리고 구독이 업데이트되더라도 코어가 정상 실행 중이라는 뜻은 아닙니다. 반대로 브라우저에서 웹페이지가 열리지 않는다고 해서 코어 시작 실패인 것도 아닙니다. 원격 연결 시간 초과, 인증서 검증 실패, DNS 조회 오류는 코어가 시작된 뒤에도 발생할 수 있습니다.

이 흐름은 오류가 발생한 단계를 찾기 위한 것으로, 모든 코어 버전의 내부 호출 순서를 엄격히 나타내지는 않습니다. 점검할 때는 시작 실패 로그에서 가장 구체적인 원인을 먼저 찾으세요. 코어가 이미 실행 중인데 connection refused 또는 i/o timeout이 발생한다면 대상 주소를 확인해 로컬 연결 문제인지 원격 연결 문제인지 판단해야 합니다. 이를 JSON 오류로 바로 분류하면 안 됩니다.

• 설정 단계: 파싱 오류, 프로토콜 인식 실패, 규칙 데이터 읽기 오류가 나타나면 먼저 설정이나 리소스 경로를 수정해야 합니다.
• 리스닝 단계: bind, listen tcp 같은 문구가 보이면 로컬 주소와 포트 충돌, 권한을 먼저 확인하세요.
• 요청 단계: 인바운드 요청 기록이 있는데 원격 시간 초과가 발생하면 노드, DNS, 라우팅, 서버 연결 상태를 확인하세요.

2. 한 번의 전체 시작 로그 수집하기

로그는 시작 버튼을 누르기 전부터 오류가 나타난 뒤까지 이어져야 합니다. “시작 실패”라는 문구만 캡처하지 마세요. 상위 알림은 결과만 보여 주는 경우가 많고, 실제 원인은 뒤에 나오는 failed to, 파일명 또는 시스템 오류에 담겨 있습니다. 연달아 여러 번 시작하면 실행별 로그가 섞이므로 먼저 서비스를 중지한 뒤 한 번만 재현하세요.

1. 환경 기록

   운영체제, 클라이언트 버전, 현재 코어 이름과 버전을 기록하세요. v2rayNG는 Xray를, v2flyNG는 V2Fly를 사용합니다. v2rayN은 현재 선택된 코어를 기준으로 확인하고, 창 이름만으로 판단하지 마세요.

2. 로그 열기

   v2rayN에서는 메인 창 하단의 로그 영역을 확인하세요. 접혀 있다면 로그 패널을 펼치면 됩니다. v2rayNG에서는 메인 화면 메뉴에서 ‘로그’를 여세요. 버전에 따라 메뉴 위치가 다를 수 있으니 현재 화면의 항목명을 기준으로 확인하세요.

3. 한 번만 재현

   먼저 연결을 중지하고 현재 시간을 기록한 다음 한 번 시작하세요. 시작 전후의 연속된 로그를 보관하고, 첫 번째 실패 메시지와 전체 원인 체인을 확인하세요. 마지막 한 줄만 남기지 마세요.

4. 수정 전 백업

   사용자 설정과 라우팅 규칙을 백업하고, 매번 변수 하나만 바꾸세요. 로그를 공유하기 전에는 구독 주소, 노드 인증 정보, UUID, 서버 주소, 개인 디렉터리명을 가리세요. 단, 필드명과 오류 유형, 포트는 남겨야 합니다.

클라이언트에서 코어 프로세스를 만들 수 없다고 표시되고 코어 출력도 전혀 없다면, 먼저 코어 실행 파일이 있는지, 압축 파일이 제대로 풀렸는지, 시스템 보안 기록에서 실행을 차단했는지, 설치 파일이 프로세서 아키텍처에 맞는지 확인하세요. 이런 문제는 설정 파싱 전에 발생하므로 노드 매개변수를 반복해서 바꿔도 해결되지 않는 경우가 많습니다.

3. 포트 충돌: 리스닝 프로세스를 확인한 뒤 포트 변경하기

로컬 프록시는 리스닝 주소와 포트에 바인딩해야 합니다. 같은 주소의 동일한 TCP 포트는 일반적으로 두 개의 독립 리스너가 동시에 사용할 수 없습니다. 클라이언트를 중복 실행했거나 이전 코어가 남아 있거나 다른 프로그램이 같은 포트를 사용하면 새 코어가 즉시 종료될 수 있습니다. 원격 서버 포트와 로컬 인바운드 포트를 혼동하지 마세요.

위 숫자는 문제 해결을 위한 예시이며 모든 버전의 기본값은 아닙니다. 로그에 127.0.0.1:10808 바인딩 실패가 표시된다고 가정해 보겠습니다. Windows PowerShell에서 아래 명령을 실행해 포트를 점유한 프로세스 ID를 확인한 다음 프로세스 이름을 조회하세요.

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

Get-Process -Id (Get-NetTCPConnection -State Listen -LocalPort 10808).OwningProcess

Linux에서는 ss -ltnp 'sport = :10808', macOS에서는 lsof -nP -iTCP:10808 -sTCP:LISTEN을 실행할 수 있습니다. 결과가 없다는 것은 조회 시점에 일치하는 TCP 리스너가 없다는 뜻일 뿐, 시작 순간의 충돌이나 UDP 충돌, 권한 문제까지 배제하지는 않습니다. 로그의 네트워크 유형도 함께 확인하세요.

• 이전 코어 프로세스가 발견되면 해당 클라이언트에서 정상 종료하고 포트가 해제된 것을 확인한 다음 대상 클라이언트를 시작하세요.
• 10818로 변경하기 전에도 사용 가능한 포트인지 확인하세요. 변경한 뒤에는 수동으로 설정한 브라우저 프록시, 터미널 프록시와 기타 로컬 연결 설정도 함께 업데이트해야 합니다.
• 로그에 존재하지 않는 로컬 IP 주소가 표시되면 리스닝 주소를 수정하세요. 로컬 기기에서만 사용할 경우 실제 필요에 따라 127.0.0.1을 사용할 수 있습니다. 오류를 없애겠다고 모든 네트워크 인터페이스에 무작정 공개하지 마세요.

4. JSON 구문 오류: 형식 오류와 필드 호환성 문제 구분하기

엄격한 JSON에서는 키 이름과 문자열에 영문 큰따옴표를 사용해야 하며, 배열과 객체 사이의 쉼표 위치도 정확해야 합니다. 전각 따옴표, 마지막 항목 뒤의 불필요한 쉼표, 복사 과정에서 빠진 괄호는 모두 설정 읽기 실패를 일으킬 수 있습니다. 일부 입력 방식은 주석 같은 확장 문법을 지원하지만 다른 방식에서는 지원하지 않을 수 있습니다. 차이를 줄이려면 점검용 사본에는 엄격한 JSON을 사용하세요.

아래는 구문 설명을 위한 예시이며 바로 실행할 수 있는 전체 프록시 설정은 아닙니다. loglevel 뒤에 불필요한 쉼표가 없고, 바깥 객체와 안쪽 객체가 각각 닫혀 있습니다.

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

JSON 형식 검사를 통과했다는 것은 텍스트 구조가 유효하다는 뜻일 뿐, 프로토콜 이름과 전송 설정, 필드 유형까지 올바르다는 뜻은 아닙니다. 일부 인식되지 않는 필드는 시작 오류를 일으키지 않고 무시될 수도 있습니다. 따라서 현재 실제로 사용하는 코어로 설정을 계속 테스트해야 합니다.

.\xray.exe run -test -config .\config.json

• 위 예시는 해당 명령을 제공하는 Xray 버전에서 사용할 수 있습니다. 먼저 .\xray.exe help run을 실행해 매개변수를 확인하세요. Linux와 macOS에서는 각 환경에 맞는 실행 파일 경로를 사용하세요.
• config.json은 실제로 로컬에 존재하는 설정 사본이어야 합니다. 클라이언트가 설정을 자동 생성한다면 테스트 대상이 현재 노드 실행에 사용되는 내용인지 확인하세요.
• 명령줄 테스트와 클라이언트 실행은 작업 디렉터리, 환경 변수, 리소스 경로가 서로 다를 수 있습니다. 테스트를 통과한 뒤에도 클라이언트에서 다시 확인해야 합니다.
• 노드 인증 정보가 포함된 전체 JSON을 낯선 온라인 포맷터에 업로드하지 마세요. 로컬 편집기와 코어의 테스트 기능을 우선 사용하세요.

5. 알 수 없는 프로토콜 및 필드 오류: 실제 실행 중인 코어 확인하기

공유 링크, 구독 내용, 네이티브 설정은 서로 다른 입력 형식입니다. vless:// 또는 vmess:// 공유 링크는 클라이언트가 파싱해야 하며, 이를 JSON 설정 파일로 저장해 코어에 직접 읽힐 수는 없습니다. 구독 목록에 노드가 표시된다고 해서 현재 코어가 해당 전송 방식과 보안 매개변수를 모두 지원한다는 뜻도 아닙니다.

VLESS는 프로토콜 이름이고 REALITY는 관련 보안 설정의 일부이므로, 둘은 protocol 값으로 서로 대체할 수 없습니다. 전송 방식, 보안 설정, 서버 이름과 인증 정보는 서버 요구 사항에 맞아야 합니다. 시작 가능한 프로토콜 이름으로 바꾸기만 해서는 노드에 연결되지 않습니다.

• v2rayN: 현재 노드에 사용 중인 코어와 시작 로그를 확인하세요. 코어를 바꾼 뒤에는 설정을 다시 생성해 이전에 남은 설정 파일을 계속 테스트하지 않도록 하세요.
• v2rayNG: 클라이언트에 포함된 Xray 기능을 기준으로 확인하세요. 새 매개변수를 인식하지 못하면 먼저 클라이언트와 코어 버전을 확인한 뒤 업데이트가 필요한지 판단하세요.
• v2flyNG: V2Fly 설정 규격을 기준으로 확인하세요. Xray용 전체 JSON을 그대로 가져오면 같은 방식으로 작동한다고 가정할 수 없습니다.

6. geo 파일 누락: 데이터 이름, 경로, 규칙 참조 확인하기

라우팅에서 사용하는 geosite: 및 geoip: 참조에는 해당 데이터가 필요합니다. 설정 구문이 올바르더라도 실행 환경에서 데이터 파일을 찾지 못하거나 데이터에 지정된 분류가 없으면 규칙 생성에 실패할 수 있습니다. 오류가 ‘파일을 열 수 없음’인지 ‘분류를 찾을 수 없음’인지 먼저 확인하세요. 두 경우의 해결 방법은 다릅니다.

1. 오류에 표시된 파일명(예: geosite.dat, geoip.dat)과 전체 경로를 기록하세요. 클라이언트 설치 디렉터리만 보고 리소스 위치를 추측하지 마세요.
2. 파일을 읽을 수 있고 비어 있지 않은지 확인하세요. Linux에서는 파일명 대소문자를 구분하며 디렉터리 권한도 코어의 파일 읽기에 영향을 줍니다.
3. 클라이언트에서 제공하는 데이터 업데이트 기능으로 호환되는 데이터 파일을 복원하세요. 해당 기능이 없다면 클라이언트의 리소스 관리 방식에 따라 처리하고, 형식이 다른 파일을 임의로 섞어 사용하지 마세요.
4. 파일은 있는데 로그에 분류를 찾을 수 없다고 표시되면 geosite: 뒤의 분류명 철자와 현재 데이터 내용을 확인하세요. 모든 데이터 파일에 서드파티 분류명이 포함되는 것은 아닙니다.
5. 백업한 뒤 문제가 있는 규칙 하나만 임시로 제거하고 시작을 테스트하세요. 시작에 성공해도 해당 규칙이나 리소스가 원인일 가능성만 좁혀진 것입니다. 정식 설정을 복원하기 전에 데이터와 규칙을 보완해야 합니다.

점검 중 모든 라우팅 규칙을 삭제하면 요청 경로가 달라져, 직접 연결해야 할 요청이 프록시로 전달되거나 프록시 요청이 직접 연결될 수 있습니다. 문제를 찾은 뒤 원래 라우팅 의도를 복구하고 outboundTag가 실제 존재하는 아웃바운드 태그를 가리키는지 확인하세요.

7. Android 서비스 오류와 수정 후 검증

v2rayNG는 Android의 시스템 VPN 인터페이스를 통해 트래픽을 처리합니다. VPN 권한 승인 실패와 Xray 설정 파싱 실패는 서로 다른 단계의 문제입니다. 전자는 시스템 권한, 다른 VPN 서비스, 기기 정책을 확인하고, 후자는 로그를 확인해 JSON, 프로토콜 또는 리소스 문제를 찾아야 합니다. v2flyNG는 V2Fly 코어를 사용하므로 점검할 때도 이 차이를 구분하세요.

• 서비스가 시작 직후 중지됨: 시작 로그에서 첫 번째 오류를 확인한 다음 시스템 VPN 권한이 승인되었는지 점검하세요. 상태 표시줄 아이콘만으로 원인을 판단하지 마세요.
• 다른 VPN이 실행 중: 충돌하는 VPN 서비스를 먼저 중지하세요. Android에서는 일반적으로 같은 사용자 계정에서 활성 VPN 서비스 하나만 트래픽을 처리할 수 있습니다.
• 화면을 잠근 뒤 연결이 끊김: 시작 시에는 정상인데 백그라운드에서 한동안 실행된 후 중지된다면 시스템 배터리 최적화와 백그라운드 제한을 확인하세요. 이는 일반적인 설정 읽기 오류가 아닙니다.
• 서비스는 실행 중이지만 트래픽이 없음: 앱별 프록시 범위, DNS와 라우팅, 현재 노드의 연결 가능 여부를 확인하세요. 시스템 VPN 인터페이스가 있다고 해서 모든 앱의 요청이 대상 아웃바운드로 전달되는 것은 아닙니다.

수정한 뒤에는 같은 노드와 같은 조건으로 다시 확인하세요. 먼저 코어가 즉시 종료되지 않는지 확인하고, 다음으로 로컬 리스닝 또는 Android VPN 서비스가 정상인지 점검한 뒤 웹페이지 접속을 테스트하세요. 시스템 프록시, VPN 연결, 코어 프로세스는 각각 다른 단계입니다. 한 단계만 정상이라고 전체 연결 경로가 작동한다고 볼 수 없습니다.

1. 재시작 후 확인

   서비스를 중지한 뒤 다시 시작해 원래 오류가 사라졌는지 확인하세요. 다른 오류로 바뀌었다면 새 오류가 발생한 단계부터 계속 점검하면 됩니다.

2. 연결 상태 확인

   데스크톱에서는 실제 리스닝 포트와 시스템 프록시 설정을 확인하고, Android에서는 VPN 서비스와 적용 대상 앱을 확인하세요. 포트가 바뀌었다면 수동 연결 설정도 모두 업데이트해야 합니다.

3. 요청 보내기

   브라우저에서 정상 작동이 확인된 HTTPS 페이지를 열고, 로그에 해당 요청이 표시되는지 확인하세요. 원격 시간 초과만 발생한다면 노드와 네트워크를 점검하고 JSON 구두점은 더 이상 반복해서 수정하지 마세요.

4. 설정 복구

   점검을 위해 임시로 변경한 라우팅과 로그 수준을 복구하고 최종 설정 사본을 저장하세요. 다음 업데이트 후 비교할 수 있도록 ‘오류 원문, 수정 항목, 검증 결과’를 기록하세요.