v2rayN에서 서버를 바꾼 뒤 코어 실행 오류가 표시되거나, 사용자 지정 설정을 불러온 직후 프로그램이 종료되거나, 코어 업데이트 후 라우팅 규칙을 불러오지 못하는 경우에 적용할 수 있습니다. 먼저 로그를 통해 설정을 읽지 못한 것인지, 로컬 포트에서 수신 대기하지 못한 것인지, 코어는 실행됐지만 연결에 실패한 것인지 구분하세요. 그런 다음 포트, JSON, 필드 호환성, geo 데이터를 차례로 점검합니다. 마지막으로 설정 테스트와 실제 요청을 각각 확인해 구독 가져오기 실패를 코어 오류로 오해하지 않도록 합니다.
1. 코어 실행 실패와 연결 실패 구분하기
v2rayN은 관리 인터페이스이며, 프록시 설정을 실제로 실행하는 프로세스는 Xray 또는 V2Fly입니다. 메인 창이 열리고 서버 목록이 표시된다고 해서 코어가 정상 실행 중인 것은 아닙니다. 코어 실행 실패는 보통 설정을 읽거나 인바운드·아웃바운드를 구성하거나 로컬 포트에 바인딩하는 과정에서 발생합니다. 노드 연결 시간 초과, 인증서 불일치, 원격 서버의 연결 거부는 코어가 실행된 뒤에 발생할 수도 있습니다.
오류가 발생한 시점을 먼저 확인하세요. 활성 서버를 설정할 때마다 곧바로 설정 파싱 오류가 표시된다면 로컬 설정부터 점검해야 합니다. 시작 과정에 문제가 없고 웹 페이지를 열 때만 연결 오류가 발생한다면 서버 주소, 네트워크, TLS, 전송 매개변수를 확인하세요. 이 경우 로컬 수신 포트를 반복해서 바꿔도 대개 해결되지 않습니다.
| 로그 또는 증상 | 발생 단계 | 우선 확인할 항목 |
|---|---|---|
failed to load config | 설정 읽기 또는 구성 | 이후 로그에서 JSON, 프로토콜 필드, 데이터 파일 관련 원인 확인 |
failed to listen TCP | 로컬 수신 대기 시작 | 수신 주소, 포트 충돌, 시스템 예약 포트 |
connection refused | 대상 주소에 연결 | 오류에 표시된 대상이 로컬 인바운드인지 원격 서버인지 확인 |
context deadline exceeded | 요청 시간 초과 | 앞뒤 로그를 확인해 DNS, 연결, 핸드셰이크 중 어디서 시간이 초과됐는지 판단 |
2. 로그 창에서 실제 코어와 설정 파일 확인하기
문제 해결에 필요한 것은 프로그램 폴더에 우연히 있는 파일이 아니라, 해당 실행에서 실제로 사용한 코어와 설정입니다. v2rayN은 보통 활성 서버와 라우팅 설정에 따라 실행용 설정을 생성합니다. 생성된 파일을 직접 수정해도 노드를 바꾸면 변경 내용이 덮어써질 수 있습니다. 계속 유지해야 할 변경 사항은 매개변수 설정, 라우팅 설정 또는 해당 사용자 지정 설정에서 수정하세요.
-
현재 상태 보존하기
메인 창 하단 로그 영역에서 이번 오류를 복사하고, 직전에 실행한 작업이 코어 시작, 서버 변경, 라우팅 수정 중 무엇이었는지 기록하세요. 사용자 지정 설정은 수정 전에 백업해 재현 가능한 원본을 덮어쓰지 않도록 합니다.
-
코어 확인
「설정」→「매개변수 설정」을 열어 「Core 유형」 관련 옵션을 확인하고, 시작 로그에 표시된 Xray 또는 V2Ray 버전 정보와 대조하세요. 버전에 따라 메뉴 구분이나 명칭이 다를 수 있으므로 실제 실행 프로세스는 로그를 기준으로 판단하세요.
-
파일 위치 확인
시작 정보나 오류 경로를 통해 실제로 읽는 설정 파일을 확인하세요. 인터페이스에 전체 경로가 표시되지 않으면 클라이언트 로그와 실행 폴더를 확인합니다. 파일 이름만 보고 추측하거나 구독 응답을 실행 설정으로 취급하지 마세요.
-
한 항목씩 재시도
한 번에 하나씩 수정한 뒤 코어를 다시 시작하고 새 오류를 저장하세요. 이전 오류가 사라지고 다음 오류가 나타났다면 문제 해결이 진전된 것입니다. 모든 매개변수를 되돌리고 처음부터 다시 시작할 필요는 없습니다.
설정 파싱 로그가 나오기도 전에 실행 파일을 찾을 수 없거나, 프로세스를 만들 수 없거나, 접근이 거부됐다는 메시지가 표시된다면 코어 파일의 무결성, 프로그램 폴더의 읽기·쓰기 권한, 보안 프로그램의 차단 기록부터 확인하세요. 이 문제는 설정이 코어에 전달되기 전에 발생하므로 JSON을 수정해도 해결되지 않습니다.
3. 포트 충돌: PID를 확인한 뒤 로컬 수신 포트 변경
아래 숫자는 문제 해결을 위한 예시일 뿐, 모든 버전의 기본 설정을 의미하지 않습니다. 먼저 「설정」→「매개변수 설정」에서 로컬 수신 포트를 확인한 다음 명령에 있는 숫자를 실제 값으로 바꾸세요. 일부 버전은 혼합 수신 포트를 사용하므로 SOCKS와 HTTP 포트가 각각 따로 있어야 한다고 단정하지 마세요.
오류: bind: address already in use
원인: 해당 수신 주소와 포트를 다른 프로세스가 사용 중이거나, 다른 v2rayN 인스턴스가 실행한 코어가 계속 실행 중일 수 있습니다.
해결: 포트를 점유한 프로세스를 확인하고 중복 실행된 인스턴스를 정상 종료하세요. 두 프로그램을 모두 실행해야 한다면 한쪽에 다른 로컬 포트를 지정하세요.
오류: Only one usage of each socket address
원인: Windows에서 포트 바인딩 충돌이 발생할 때 흔히 표시되는 문구입니다. 전체 오류에는 수신 주소와 포트도 함께 나타납니다.
해결: 로그에 나온 정확한 포트로 PID를 확인하세요. 바인딩 오류가 보인다는 이유만으로 모든 코어 프로세스를 종료하지 마세요.
Windows에서 수신 프로세스 확인하기
netstat -ano -p tcp | findstr ":10808"
netstat -ano -p tcp | findstr ":10809"
로컬 주소 열에서 해당 포트와 상태가 LISTENING인 행만 수신 대기의 근거로 보세요. 명령 결과에는 원격 주소도 포함될 수 있으므로 숫자가 보인다고 곧바로 충돌로 판단하면 안 됩니다. 맨 오른쪽 열의 PID는 작업 관리자의 「세부 정보」에서 확인할 수 있습니다. 다음 PowerShell 명령으로 프로세스 이름을 바로 확인할 수도 있습니다:
Get-NetTCPConnection -LocalPort 10808 -State Listen |
Select-Object LocalAddress, LocalPort, OwningProcess,
@{Name='ProcessName';Expression={(Get-Process -Id $_.OwningProcess).ProcessName}}
결론: 포트를 바꾸면 연결하는 쪽도 함께 변경
로컬 포트를 10808에서 다른 값으로 바꿨다면 프록시를 수동 설정한 브라우저, 터미널, 앱의 포트도 함께 변경해야 합니다. v2rayN의 시스템 프록시를 사용 중이라면 「시스템 프록시 자동 설정」을 다시 적용하세요. 코어가 새 포트에서 수신 대기한다고 해서 앱도 새 포트에 연결된 것은 아닙니다.
오류가 forbidden by its access permissions처럼 접근 권한과 관련되고, 조회 결과 수신 프로세스가 없다면 시스템 제외 포트 범위도 확인하세요. netsh interface ipv4 show excludedportrange protocol=tcp를 실행하면 됩니다. 사용 중이지도 않고 예약되지도 않은 포트를 우선 선택하세요. 시스템 예약 범위를 직접 삭제하지 마세요.
4. JSON 문법 오류: 구두점과 계층 구조 수정
표준 JSON에서는 객체 키와 문자열에 영문 큰따옴표를 사용해야 하며, 마지막 항목 뒤에 쉼표를 붙일 수 없습니다. 한글 스마트 따옴표도 구분자로 사용할 수 없습니다. 일부 로딩 방식은 주석이나 다른 확장 문법을 지원할 수 있지만, 설정을 복사할 때는 표준 JSON을 사용해야 여러 도구에서 쉽게 검증할 수 있습니다. 문법 검사를 통과해도 프로토콜이나 라우팅 필드가 유효하다는 뜻은 아닙니다.
오류: invalid character '}' looking for beginning of object key string
원인: 객체의 마지막 항목 뒤에 쉼표가 남아 파서가 다음 키를 기다리다가 닫는 중괄호를 읽은 경우가 흔합니다.
해결: 오류 위치와 바로 앞 항목을 확인해 마지막 쉼표를 삭제하고 괄호가 짝을 이루는지 다시 점검하세요.
오류: unexpected EOF
원인: 구조가 끝나기 전에 내용이 잘렸습니다. 복사 누락, 닫히지 않은 문자열, 닫는 괄호 누락 등이 흔한 원인입니다.
해결: 원본 파일 전체와 대조해 빠진 내용을 복구하세요. 파일 끝에 괄호만 무작정 추가하지 마세요.
아래는 중첩 구조와 쉼표 위치를 보여 주는 문법적으로 올바른 로그 설정 예시입니다. 완전한 프록시 설정이 아니므로 실행 파일 전체를 대체할 수 없습니다.
{
"log": {
"loglevel": "warning"
}
}
- 따옴표 확인:
"loglevel"은 올바른 키 이름이며, 한글 스마트 따옴표는 사용할 수 없습니다. - 쉼표 확인: 같은 계층의 항목 사이에는 쉼표가 필요하지만 마지막 항목 뒤에는 붙이지 않습니다.
- 경로 확인: JSON 문자열에서 Windows의 역슬래시는 이스케이프해야 합니다. 예:
"C:\\proxy\\error.log". - 파일 내용 확인: 첫 부분에 HTML 태그가 보인다면 잘못된 오류 페이지가 저장됐을 수 있습니다. 구독 인코딩 문자열만 들어 있다면 일반 실행용 JSON이 아닙니다.
인증 정보가 포함된 설정을 온라인 포맷터에 올리지 마세요. 로컬 편집기에서 구두점을 확인한 뒤 같은 코어의 설정 테스트 명령으로 의미가 올바른지 검증하세요. v2rayN이 자동 생성한 파일에서 같은 문제가 반복된다면 매번 생성 결과를 직접 수정하기보다 사용자 지정 설정이나 템플릿의 출처를 확인하세요.
5. 알 수 없는 필드와 코어별 차이: 프로토콜, 유형, 계층 확인
Xray와 V2Fly는 기본 구조를 공유하지만, 한쪽에 추가된 전송·보안·프로토콜 매개변수를 다른 쪽에 그대로 적용할 수는 없습니다. 두 파일 모두 JSON이라도 코어 버전에 따라 같은 필드를 인식하지 못할 수 있습니다. VLESS와 VMess는 프로토콜 이름이지 범용 설정 형식이 아닙니다. 특정 클라이언트에서 공유 링크를 가져올 수 있다고 해서 모든 코어 버전이 그 안의 매개변수를 지원하는 것은 아닙니다.
| 오류 단서 | 가능한 원인 | 해결 방법 |
|---|---|---|
unknown field | 현재 로더가 필드를 엄격하게 검사하거나 필드가 잘못된 계층에 있음 | 해당 코어 버전의 필드 정의와 중첩 위치 확인 |
unknown config id | 지원되지 않는 프로토콜·전송 유형이거나 이름의 철자가 잘못됨 | 오류가 가리키는 유형과 실제 코어를 확인하고 다른 코어의 설정을 복사하지 않기 |
cannot unmarshal | 문자열, 숫자, 배열, 객체의 유형이 맞지 않음 | 전체 오류를 기준으로 필드를 찾고 파서가 억지로 통과하도록 따옴표만 바꾸지 않기 |
| 오류는 없지만 설정이 적용되지 않음 | 알 수 없는 필드가 무시됐거나 수정한 파일이 실제 실행 파일이 아님 | 생성된 설정과 실제 동작을 대조하고 테스트 종료 성공만으로 판단하지 않기 |
알 수 없는 필드가 모두 실행 실패를 일으키는 것은 아닙니다. 동작은 코어 버전과 설정을 불러오는 방식에 따라 달라집니다. 따라서 unknown field가 표시되지 않았다고 해서 해당 필드가 적용됐다고 단정할 수 없습니다. 우선 v2rayN의 해당 구조화 편집 기능을 사용하세요. 직접 JSON을 수정해야 한다면 실제 코어의 도움말, 설정 계층, 버전별 지원 범위를 확인하세요.
6. geo 파일 누락: 파일, 경로, 컬렉션 이름 구분하기
라우팅의 geosite:cn은 도메인 컬렉션을, geoip:cn은 IP 컬렉션을 참조합니다. 일반적인 DAT 데이터 로딩 방식에서는 각각 geosite.dat와 geoip.dat가 필요합니다. 코어가 데이터 파일을 찾을 수 있어야 할 뿐 아니라 파일 안에 참조한 컬렉션도 있어야 합니다. 파일의 존재 여부, 읽기 가능 여부, 컬렉션의 존재 여부는 각각 별개의 조건입니다.
오류: failed to load geosite
원인: 도메인 규칙을 불러오지 못했습니다. 이어지는 오류에는 파일 누락, 콘텐츠 파싱 실패, 컬렉션 이름 누락 등이 표시될 수 있습니다.
해결: 전체 오류 내용을 확인하고 실제 데이터 폴더부터 찾으세요. 그런 다음 파일과 참조된 컬렉션을 각각 점검해야 합니다. 파일 이름만 확인해서는 안 됩니다.
오류: no such file or directory
원인: 앞선 로그가 geo 데이터 경로를 명시한다면 해당 위치에서 필요한 파일을 찾지 못한 것입니다. Windows에서는 “지정된 파일을 찾을 수 없습니다”라고 표시될 수도 있습니다.
해결: 오류에 표시된 전체 경로에 데이터 파일을 복구하거나 리소스 폴더를 수정하세요. 다른 위치에 같은 이름의 파일이 있다고 문제가 해결된 것은 아닙니다.
- 파일 누락: 클라이언트의 데이터 파일 업데이트 기능으로 다시 받으세요. 버전에 따라 메뉴 위치가 다를 수 있으므로 업데이트 결과와 실제 리소스 경로를 확인해야 합니다.
- 파일 손상: 코어에서 읽기 또는 파싱 오류가 발생하면 데이터 파일 전체를 다시 받으세요. 다운로드 오류 페이지의 이름만
.dat로 바꾸지 마세요. - 컬렉션 없음:
geosite:또는geoip:뒤의 이름을 확인하세요. 데이터 출처에 따라 포함된 컬렉션이 다를 수 있습니다. - 외부 데이터 참조:
ext:파일명:컬렉션명을 사용하는 경우 사용자 지정 파일명, 리소스 폴더, 컬렉션을 모두 확인하세요. 기본 파일만 업데이트해서는 안 됩니다.
임시 확인이 필요하면 직접 추가한 규칙 중 오류를 일으킨 geo 규칙을 잠시 비활성화한 뒤 설정을 다시 생성하고 코어를 시작할 수 있습니다. 이 방법으로 해당 규칙이나 데이터 의존성이 원인임을 확인할 수는 있지만, 최종 해결책은 아닙니다. 라우팅 규칙을 삭제하면 연결 경로가 바뀔 수 있으므로 규칙을 복구한 뒤 원래 직접 연결, 프록시, 차단이 필요했던 대상이 올바르게 처리되는지 다시 확인하세요.
7. 설정 테스트와 실제 요청을 따로 검증하기
설정 테스트는 v2rayN이 실제로 호출하는 코어 버전과 동일한 데이터 리소스 환경에서 실행해야 합니다. 그렇지 않으면 수동 테스트에서 작업 폴더가 달라 geo 파일을 찾지 못하거나, 다른 코어를 사용해 결과가 달라질 수 있습니다. 아래 예시는 Windows용이며 현재 폴더에 코어 프로그램과 확인할 config.json이 있다고 가정합니다. 파일이 다른 위치에 있다면 실제 경로를 사용하세요.
.\xray.exe version
.\xray.exe run -test -config .\config.json
V2Fly의 명령줄 옵션은 주요 버전에 따라 다릅니다. 하위 명령 형식을 사용하는 V2Fly 버전에서는 아래 명령을 사용할 수 있습니다. 알 수 없는 명령이라는 메시지가 나오면 다른 버전의 실행 옵션을 그대로 복사하지 말고 현재 실행 파일의 도움말부터 확인하세요.
.\v2ray.exe version
.\v2ray.exe help
.\v2ray.exe test -c .\config.json
설정 테스트는 보통 설정을 불러오고 구성하는 과정만 확인합니다. 실제 실행에 필요한 수신 대기를 완전히 시작하지 않으며 원격 서버 연결도 대신 수행하지 않습니다. 따라서 테스트에 통과해도 포트 충돌, 원격 서버 연결 불가, 핸드셰이크 실패는 여전히 발생할 수 있습니다. 수정 후에는 v2rayN에서 코어를 정식으로 시작하고 다음 순서로 확인하세요.
- 시작 확인: 같은 실행에서 설정 파싱, 데이터 로딩, 수신 대기 오류가 더 이상 발생하지 않는지 확인합니다.
- 수신 대기 확인: 포트 조회 명령으로 예상한 포트가 수신 대기 중인지, 해당 프로세스가 이번에 시작한 코어인지 확인합니다.
- 연결 설정 확인: 시스템 프록시 또는 앱에 수동 설정한 프록시 주소를 확인합니다. 시스템 프록시 활성화 여부와 코어 실행 가능 여부는 별개의 문제입니다.
- 요청 확인: 실제로 접속해 로그를 확인하고 요청이 코어에 전달되는지, 어떤 대상과 단계에서 실패하는지 확인합니다.
- 라우팅 확인: 라우팅을 수정했다면 직접 연결 대상과 프록시 대상이 각각 의도대로 처리되는지 확인합니다. 임시로 비활성화한 규칙을 복구한 뒤 다시 테스트하세요.
8. 자주 묻는 질문: 재설치, 관리자 권한, 로그 수준
삭제 후 다시 설치해도 실행 오류가 계속됩니다. 또 재설치해야 하나요?
먼저 같은 사용자 설정과 사용자 지정 라우팅을 그대로 사용하고 있는지 확인하세요. 프로그램 파일을 업데이트해도 설정 오류가 제거되지 않을 수 있습니다. 백업한 뒤 정상 작동이 확인된 서버 설정 하나와 간단한 라우팅으로 테스트하고 사용자 지정 항목을 하나씩 복구하세요. 문제가 있는 설정 전체를 한 번에 복원하지 않는 편이 좋습니다.
관리자 권한으로 실행해야 해결되나요?
일반적인 로컬 고포트 수신 대기에는 보통 관리자 권한이 필요하지 않습니다. 먼저 포트 점유, 폴더 접근 거부, 추가 권한이 필요한 네트워크 기능을 구분하세요. 권한을 높여도 JSON 구두점 오류, 잘못된 필드, 누락된 컬렉션은 해결되지 않으며 프로세스와 경로 확인을 대신할 수 없습니다.
로그가 너무 적습니다. debug로 바꾸면 원인을 찾을 수 있나요?
「설정」→「매개변수 설정」에서 로그 수준을 찾아 일시적으로 debug로 바꾼 뒤 다시 시작해 문제를 한 번 재현하세요. 로그 시스템이 초기화되기 전에 설정 로딩이 실패한다면 시작 출력도 확인해야 합니다. 점검이 끝나면 평소 로그 수준으로 되돌리고 공유 전에 민감한 연결 정보를 삭제하세요.
다른 노드로 바꾸면 정상 작동합니다. 원래 노드가 끊긴 건가요?
꼭 그렇지는 않습니다. 두 노드는 프로토콜, 전송 방식, 보안 매개변수가 달라 한쪽 설정만 현재 코어에서 지원되지 않을 수 있습니다. 먼저 노드를 바꿀 때의 시작 로그를 비교하세요. 원래 노드에서도 코어가 정상 시작되고 요청만 실패한다면 서버 주소, 포트, 핸드셰이크 조건을 확인하세요.
문제를 재현할 수 있는 민감 정보 삭제 로그와 함께 코어 버전, 오류를 유발한 작업, 수정한 항목을 기록해 두세요. 비슷한 문제가 다시 발생하면 모든 설정을 초기화하는 대신 오류가 발생한 단계와 가장 안쪽 원인을 먼저 확인하는 편이 기존 설정을 유지하는 데 도움이 됩니다. 시스템 프록시와 연결 동작을 더 확인하려면 문제 해결 안내서를 참고하세요.