v2rayN 코어 시작 문제 해결

시작 오류와 연결 오류 구분하기

v2rayN은 설정 및 관리 화면이며 실제 연결은 선택한 코어가 처리합니다. 메인 창이 열려도 코어가 실행 중이라는 뜻은 아니고, 브라우저가 열리지 않는다고 코어 시작에 실패한 것도 아닙니다. timeout이 보인다고 클라이언트를 재설치하면 실제 원인을 놓치기 쉽습니다.

메인 화면 아래쪽의 로그 또는 정보 영역을 열고 한 번 실행했을 때 발생한 오류 전체를 확인하세요. 화면 배치는 Desktop과 WPF 버전에 따라 다릅니다. 클라이언트에 표시된 ‘시작 실패’ 알림이 아니라 코어 출력 로그를 찾는 것이 중요합니다. 오류 체인의 >는 상위 원인과 하위 원인을 연결하는 데 쓰이는 경우가 많으며, 대개 마지막 부분에 앞선 요약보다 구체적인 내용이 표시됩니다.

한 번 재현하고 점검 조건 고정하기

서버를 계속 바꾸고 코어를 전환하거나 라우팅을 수정하면 로그가 뒤섞입니다. 먼저 현재 코어, 서버 유형, 로컬 수신 대기 포트를 기록한 다음 한 번만 재현하세요. 아래 경로는 일반적인 중국어 UI를 기준으로 합니다. 메뉴 배치가 다르면 해당 설정 항목을 찾아 이동하고, 다른 버전의 디렉터리 구조를 그대로 적용하지 마세요.

1. 현재 설정 기록하기

   메인 화면에서 현재 서버와 라우팅 모드를 기록하세요. ‘설정’ → ‘매개변수 설정’에서 로컬 수신 대기 포트를 확인한 다음, ‘Core 유형’ 관련 설정에서 해당 프로토콜에 실제로 선택된 코어를 확인하세요.

2. 시스템 프록시 잠시 해제하기

   트레이 메뉴의 ‘시스템 프록시’에서 ‘시스템 프록시 해제’를 선택하세요. 이 작업은 시스템 프록시 설정을 취소할 뿐 코어 문제를 해결하지는 않습니다. 다만 점검하는 동안 다른 앱이 작동하지 않는 로컬 포트에 계속 접속하는 것을 막을 수 있습니다.

3. 한 번 실행한 로그 보관하기

   먼저 기존 오류를 복사한 뒤 로그 표시를 지우거나 시간을 기록하세요. 서버를 다시 활성화하고 새로 시작할 때의 출력을 확인하세요. 구독 업데이트와 일괄 테스트를 동시에 실행하지 마세요.

4. 오류에 맞춰 수정하기

   한 번에 한 항목만 바꾸세요. 저장한 뒤 코어를 다시 시작하고 첫 번째 구체적인 오류가 달라졌는지 비교하세요. 수신 대기가 정상화되면 시스템 프록시를 다시 설정하고 실제 요청을 테스트하세요.

포트 충돌: 먼저 수신 대기 프로세스 확인하기

로그에 bind, listen tcp 또는 ‘각 소켓 주소는 일반적으로 한 번만 사용할 수 있습니다’가 표시되면 로컬 포트를 먼저 확인하세요. 다른 v2rayN 인스턴스가 포트를 사용 중일 수도 있고, 이전 종료 후 코어 프로세스가 남아 있을 수도 있습니다. 운영체제마다 같은 오류의 표현이 다르므로 문구가 정확히 일치하는지보다 수신 대기 주소와 포트를 기준으로 판단하세요.

Windows 명령 프롬프트에서 다음 명령을 실행하세요. 숫자는 ‘설정’ → ‘매개변수 설정’에 실제로 지정된 포트로 바꿔야 합니다. 출력에서는 로컬 주소 열, LISTENING 상태, 마지막 열의 PID를 확인하세요. 원격 주소에만 해당 숫자가 있다고 로컬 포트가 사용 중인 것은 아닙니다.

netstat -ano -p tcp | findstr ":10808"
netstat -ano -p tcp | findstr ":10809"

• ‘작업 관리자’ → ‘세부 정보’에서 PID로 프로그램을 찾으세요. 필요한 경우 PID 열을 표시하고 실행 파일 위치를 확인하세요.
• 다른 클라이언트 인스턴스가 사용 중이라면 해당 인스턴스를 정상적으로 종료하세요. 알 수 없는 PID에 강제 종료 명령을 실행하지 마세요.
• 다른 프로그램이 해당 포트를 계속 사용해야 한다면 ‘설정’ → ‘매개변수 설정’에서 로컬 수신 대기 포트를 변경하고 저장한 뒤 코어를 다시 시작하세요.
• 포트를 바꾼 뒤 브라우저나 도구에 프록시 포트를 직접 입력해 둔 경우에도 함께 수정한 다음 시스템 프록시를 다시 설정하세요. 모든 앱이 자동으로 변경된 포트를 따라간다고 가정하지 마세요.

설정 항목: 오류 체인에서 구체적인 원인 찾기

failed to load config는 오류가 시작된 지점을 나타낼 뿐 JSON 형식, 사용자 식별자, 프로토콜 호환성 중 무엇이 문제인지는 알려주지 않습니다. 일반 서버는 화면에서 실행 설정을 생성하므로 서버 편집 화면으로 돌아가 수정하세요. 사용자 지정 설정을 쓰는 경우에만 해당 원본 파일을 직접 확인하세요. 실행 중 생성되는 파일은 다음 시작 때 덮어쓸 수 있어 장기적인 수정 위치로 적합하지 않습니다.

코어 종류가 다르면 ‘VLESS’라는 이름이 같다는 이유만으로 호환된다고 볼 수 없습니다. 전송 방식, 보안 계층, flow와 다른 매개변수도 모두 일치해야 합니다. 해당 항목을 직접 수정했다면 먼저 구독에서 받은 원래 설정으로 되돌리고 서버 측 요구 사항을 하나씩 확인하세요. 보안 계층을 암호화되지 않는 방식으로 바꾸는 것은 일반적인 해결책이 아닙니다.

• 일반 서버: 메인 화면에서 현재 서버를 편집하고 주소, 포트, 사용자 ID, 전송 방식, TLS 설정을 확인하세요.
• 사용자 지정 설정: JSON 문법과 필드 계층을 확인하세요. 다른 코어에서 작동한다는 이유만으로 필드 값을 그대로 가져오면 안 됩니다.
• 구독에서 생성된 설정: 필요한 백업을 보관한 뒤 구독을 다시 업데이트하고 문제가 재현되는지 확인하세요. 서버 설정을 직접 수정하면 다음 업데이트 때 덮어쓸 수 있습니다.

코어 파일: 경로와 아키텍처 확인

‘시스템이 지정된 파일을 찾을 수 없습니다’ 오류가 프로세스 생성 단계에서 발생했다면 보통 설정 파싱까지 진행되지 않은 것입니다. 이때 서버 설정을 계속 바꿔도 소용이 없습니다. 먼저 로그에 표시된 실행 파일 경로를 확인하고 선택한 코어 파일이 실제로 있는지 살펴보세요. 특정 버전의 bin 디렉터리 구조를 모든 버전에 적용되는 규칙으로 여기지 마세요.

압축 파일 미리 보기 창에서 프로그램을 바로 실행하지 말고, 실행 파일만 따로 꺼내 다른 디렉터리를 버리지도 마세요. 점검을 시작하기 전에 클라이언트를 종료하고 사용자 설정을 백업한 다음, 전체 프로그램 패키지를 새 별도 디렉터리에 압축 해제해 확인하세요. 새 디렉터리에서는 실행되지만 기존 디렉터리에서는 실행되지 않는다면 전체 사용자 데이터를 바로 덮어쓰기보다 파일과 권한을 비교해야 합니다.

규칙 파일: 누락, 태그, 경로 구분하기

특정 라우팅 모드를 켠 뒤에만 시작에 실패하고 오류에 geoip.dat, geosite.dat, geoip: 또는 geosite:가 표시되면 규칙 리소스를 확인하세요. 규칙 파일은 IP 또는 도메인 분류 정보를 제공합니다. 존재하지 않는 분류 태그를 참조해도 설정 로드 단계에서 시작이 차단될 수 있으므로, 실행 후 트래픽을 분류하지 못하는 문제와는 다릅니다.

• 현재 라우팅 설정을 먼저 백업한 다음, 최근 추가했고 Geo 분류를 참조하는 사용자 지정 규칙을 잠시 비활성화해 오류가 사라지는지 확인하세요.
• 이름만 다르고 동일한 누락 리소스를 참조하는 라우팅 모드로 바꾸는 데 그치지 마세요. 테스트 설정에서 오류가 난 리소스를 더 이상 사용하지 않는지 확인해야 합니다.
• 외부 규칙 파일의 경로는 로그와 실제 설정을 기준으로 확인하세요. 명령줄에서 코어를 실행할 때와 클라이언트가 코어를 실행할 때는 리소스 검색 환경이 다를 수 있습니다.
• 리소스를 복구한 뒤 원래 규칙을 다시 활성화하고 시작 여부뿐 아니라 대상 트래픽이 예상한 아웃바운드와 일치하는지도 확인하세요.

복구 확인 및 자주 묻는 질문

복구가 완료됐다고 판단하는 기준은 로그 창에 ‘빨간 글씨가 없는 것’이 아닙니다. 코어가 계속 실행되고, 예상한 포트에서 정상적으로 수신 대기하며, 실제 요청이 예상한 경로를 통과해야 합니다. 먼저 앱 하나로 테스트한 뒤 프록시에 의존하는 다른 도구를 다시 설정하세요. 여러 프록시 설정을 동시에 적용하지 마세요.