v2rayN은 실행되지만 Xray가 시작 직후 종료되는 경우에 적용할 수 있습니다. 먼저 전체 시작 로그를 저장한 뒤 설정 파싱, 매개변수 구성, 포트 바인딩 단계 중 어디서 문제가 발생했는지 확인하세요. 설정 테스트와 로컬 포트 조회로 원인을 찾을 수 있습니다. 생성된 config.json을 직접 수정하면 변경 사항이 사라질 수 있는 이유와 수정 내용을 노드 또는 사용자 지정 설정에 반영하는 방법도 설명합니다.
1. 먼저 종료된 프로세스가 Xray 코어인지 확인
v2rayN은 클라이언트 인터페이스이고 Xray는 프록시 설정을 실행하는 코어입니다. 메인 창이 계속 작동한다고 코어도 정상 실행 중인 것은 아닙니다. 반대로 브라우저에서 웹페이지가 열리지 않는다고 코어 시작 오류라고 단정할 수도 없습니다. 이 글의 절차가 필요한 상황은 노드를 선택한 뒤 시작 오류가 표시되거나, 코어 프로세스가 곧바로 종료되거나, 로그가 설정 로드 단계에서 반복해서 멈추는 경우입니다.
먼저 메인 창 하단의 로그 패널을 열고 현재 서버를 다시 선택한 뒤, 작업 전후의 로그를 모두 보관하세요. Failed to start, failed to load config files 또는 failed to listen이 포함된 오류 체인을 찾으세요. 하나의 오류에 여러 원인이 >로 연결될 수 있으며, 보통 가장 오른쪽 항목이 근본 원인에 가깝습니다. 마지막의 “프로세스가 종료되었습니다”라는 문구만 캡처하지 마세요.
-
상황 기록
v2rayN 버전, 로그에 표시된 Xray 버전, 현재 노드 프로토콜, 오류 발생 시각을 기록하세요. 로그를 공유하기 전에 구독 주소, UUID, 비밀번호, 서버 주소 등 민감한 정보를 가리세요.
-
코어 확인
「설정」→「매개변수 설정」으로 이동해 현재 프로토콜에 사용되는 코어 설정을 확인하고, 시작 로그에 표시된 Xray 버전을 기준으로 판단하세요. 버전에 따라 설정 그룹 이름이 다를 수 있으므로 다른 코어의 오류에 이 문서의 명령을 그대로 적용하지 마세요.
-
설정 저장
로그에 표시된 설정 경로에서 실제로 로드되는 파일을 찾아 복사본을 만드세요. 파일 이름은
config.json일 수도 있고 다른 접두사가 붙을 수도 있습니다. 시작 매개변수를 기준으로 확인하고 파일 이름만 보고 추측하지 마세요. -
한 번만 재현
노드를 계속 바꾸지 말고 시작 오류를 한 번만 재현하세요. 해당 실행의 로그를 백업한 설정 파일과 연결해 두면 이전 노드의 오류를 현재 노드 문제로 오인하지 않을 수 있습니다.
2. 설정 테스트로 파싱 오류와 실행 오류 구분하기
가능하면 v2rayN이 실제로 실행하는 Xray 프로그램으로 백업한 설정을 테스트하세요. 같은 설정도 코어 버전에 따라 지원 여부가 다를 수 있으므로 다른 구버전 프로그램으로 테스트하면 잘못 판단할 수 있습니다. 다음은 Windows PowerShell 명령입니다. 해당 코어가 있는 디렉터리로 이동하고 테스트용 설정 복사본의 이름을 config.json으로 바꾼 뒤 실행하세요.
.\xray.exe version
.\xray.exe run -test -config ".\config.json"-test는 설정을 읽고 구성한 뒤 유효성을 테스트하며, 프록시 서비스를 실제로 시작하지는 않습니다. JSON 파싱 오류, 일부 필수 매개변수 누락, 잘못된 프로토콜 설정을 찾을 수 있지만 실제 시작을 대신하거나 원격 계정의 유효성을 확인하지는 못합니다. 특히 테스트를 통과해도 포트를 사용할 수 있다는 보장은 없습니다. 포트 충돌은 시작 단계에서 별도로 확인해야 합니다.
| 로그 위치 또는 결과 | 우선 확인할 항목 | 다음 단계 |
|---|---|---|
| 설정 파일을 읽지 못함 | 시작 매개변수, 파일 경로, 읽기 권한 | 로그에 표시된 실제 로드 파일을 테스트했는지 확인 |
| 파싱 중 invalid character 발생 | 따옴표, 쉼표, 괄호, 문자열 이스케이프 | 먼저 문법을 수정한 뒤 설정을 다시 테스트 |
| 아웃바운드 구성 중 오류 | protocol, settings, 사용자 매개변수 | 오류 체인을 따라 해당 outbound 확인 |
| 테스트는 통과했지만 시작 단계에서 바인딩 실패 | 바인딩 주소, 포트 충돌, 시스템 제한 | 로컬 포트와 바인딩 주소 확인 |
| 시작은 됐지만 접속 시 오류 발생 | 원격 연결, TLS, DNS | 연결 문제 해결 단계로 이동하고 JSON 문장 부호는 더 이상 반복해서 수정하지 않기 |
3. JSON 문법 오류: 문장 부호를 먼저 확인한 뒤 필드 점검
사용자 지정 설정을 직접 편집할 때 흔히 생기는 문제는 마지막 쉼표, 빠진 쉼표, 전각 따옴표, 이스케이프하지 않은 백슬래시입니다. 일부 로딩 방식은 주석을 허용하지만 파서 간 차이를 배제하려면 재현 시 표준 JSON을 사용하는 것이 좋습니다. 웹페이지의 설명문, 코드 블록 표시, 줄 번호를 파일에 함께 붙여 넣지 마세요.
오류: invalid character '}' looking for beginning of object key string
원인 및 해결: 객체의 마지막 속성 뒤에 쉼표가 남아 있을 때 흔히 발생합니다. 닫는 중괄호 바로 앞 줄을 확인해 불필요한 마지막 쉼표를 삭제한 뒤 설정을 다시 테스트하세요.
오류: invalid character '"' after object key:value pair
원인 및 해결: 속성 사이에 쉼표가 빠졌을 수 있습니다. 오류가 표시된 곳 근처에서 앞 속성의 끝부분을 확인하세요. 표시된 따옴표만 수정해서는 해결되지 않을 수 있습니다.
오류: unexpected EOF
원인 및 해결: 파일이 중간에 잘렸거나 객체, 배열 또는 문자열이 닫히지 않았을 수 있습니다. 먼저 백업 파일의 끝부분과 비교한 뒤 괄호가 짝을 이루는지 확인하세요.
위 예시는 자주 발생하는 파싱 오류이며, 앞부분의 메시지는 버전과 로더에 따라 달라질 수 있습니다. JSON 파서는 대개 더 이상 읽을 수 없는 위치를 가리키지만 실제 오류는 바로 앞 줄에 있을 수 있습니다. 아래의 완전한 JSON 예시에는 마지막 쉼표가 없습니다. 따옴표와 구분 기호를 확인할 때 참고하세요. 로그 설정 일부일 뿐 전체 프록시 설정은 아닙니다.
{
"log": {
"loglevel": "warning"
}
}- 속성 이름과 문자열 값은
"loglevel"처럼 영문 큰따옴표로 감싸세요. 전각 따옴표는 사용하지 마세요. - 불리언 값은
true또는false로 작성하세요. 문법을 고치려고 모든 값을 문자열로 바꾸지 마세요. - JSON 문자열 안에서 Windows 경로는 이스케이프해야 합니다. 예:
"C:\\Temp\\xray-error.log". 해당 디렉터리가 존재하고 쓰기 가능한지도 확인하세요. - 로컬 편집기에서 설정을 확인하고, 노드 인증 정보가 포함된 전체 파일을 온라인 포맷터에 올리지 마세요.
4. 포트 충돌: 10808을 점유한 프로세스 확인
오류 체인에 listen tcp가 표시되면 구독을 다시 가져오기보다 먼저 로컬 포트의 리스닝 상태를 확인하세요. 아래는 문제 해결을 위한 예시입니다. 로컬 SOCKS 포트는 10808, HTTP 포트는 10809, 바인딩 주소는 127.0.0.1입니다. 모든 버전의 기본값은 아닙니다. 일부 설정은 혼합 인바운드를 사용해 포트 하나만 리스닝할 수 있으므로 실제 생성된 설정을 확인하세요.
오류: bind: address already in use
원인 및 해결: Linux에서 흔히 볼 수 있는 메시지로, 지정한 주소와 포트를 이미 다른 프로세스가 사용 중이라는 뜻입니다. 먼저 프로세스를 확인하고 중복 실행 중인 클라이언트를 종료하거나 인바운드 포트를 변경하세요.
오류: Only one usage of each socket address (protocol/network address/port) is normally permitted.
원인 및 해결: Windows에서 흔히 발생하는 포트 바인딩 충돌 메시지입니다. 이전 코어 프로세스가 남아 있는지 확인하고, 설정에서 두 인바운드가 같은 주소와 포트를 사용하려는지도 확인하세요.
PowerShell에서 포트를 리스닝하는 프로세스를 확인하세요. 첫 번째 명령은 TCP 리스닝 상태만 조회하고 두 번째 명령은 프로세스 정보를 표시합니다. PID는 현재 컴퓨터에서 조회한 값을 사용해야 하며 다른 사람의 숫자를 그대로 따라 하면 안 됩니다.
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 등으로 변경하고 저장한 뒤 코어를 다시 로드하세요. 프록시 포트를 직접 지정한 앱도 함께 수정해야 합니다. 클라이언트가 관리하는 시스템 프록시는 다시 설정하세요.
정리: 테스트는 통과했지만 바인딩에 실패했다면 로컬 리소스부터 확인
실제 오류에 리스닝 문제가 있을 때만 포트 문제를 확인하세요. TCP 리스닝 프로세스가 없는데도 권한 거부 메시지가 표시된다면 바인딩 주소가 이 컴퓨터에 속하는지, 포트 예약 및 보안 정책에 문제가 없는지도 확인하세요. 모든 바인딩 오류를 노드 문제로 단정하지 마세요.
5. 필드 오타와 프로토콜 매개변수: 문법이 맞아도 설정이 유효한 것은 아닙니다
JSON을 읽을 수 있다는 것은 텍스트 구조가 대체로 올바르다는 뜻일 뿐입니다. Xray는 protocol에 따라 인바운드와 아웃바운드를 구성한 뒤 프로토콜에 필요한 필드를 검사합니다. 예를 들어 vless를 vles로 잘못 입력해도 유효한 문자열이지만 해당하는 프로토콜 설정은 없습니다. 일부 알 수 없는 필드는 무시될 수 있으므로 오류가 없다고 해서 해당 필드가 적용된 것도 아닙니다.
오류: unknown config id: vles
원인 및 해결: 프로토콜 식별자를 잘못 입력했습니다. 해당 아웃바운드의 protocol을 실제 노드 프로토콜과 대조하세요. 이 오류를 피하려고 다른 매개변수를 수정하지 마세요.
오류: invalid UUID
원인 및 해결: 잘못된 사용자 ID가 원인일 수 있으며, 상위 오류 메시지에서 관련 프로토콜을 확인할 수 있습니다. 원본 노드에서 ID를 다시 복사하고 공백이나 전각 문자가 섞이지 않았는지, 비밀번호를 UUID 필드에 입력하지 않았는지 확인하세요.
| 확인 대상 | 구체적인 확인 사항 | 흔히 하는 잘못된 수정 |
|---|---|---|
| VMess / VLESS | 프로토콜 유형, 서버 포트, 사용자 ID가 원본 노드와 일치하는지 확인 | protocol만 바꾸고 다른 프로토콜의 settings 전체를 그대로 둠 |
| VLESS 사용자 매개변수 | encryption을 확인하세요. 일반적인 설정은 none이며 flow에는 노드에서 제공한 값을 입력합니다. | VMess 사용자 암호화 필드를 그대로 가져옴 |
| 전송 설정 | streamSettings의 전송 유형과 해당 설정이 서로 맞는지 확인 | 전송 유형을 바꿨지만 관련 없는 경로나 서비스 이름을 그대로 둠 |
| TLS / REALITY | security, serverName 및 해당 보안 계층 매개변수가 서로 맞는지 확인 | 서로 다른 보안 계층의 필드를 섞어 입력하거나 검증을 끄는 것으로 문제를 해결하려고 함 |
| 라우팅 대상 | outboundTag가 의도한 아웃바운드 tag와 일치해야 함 | 임의의 문자열을 입력하면 프록시 출구가 자동으로 만들어진다고 생각함 |
노드 주소, 포트, UUID 또는 TLS 도메인이 잘못되어도 코어는 시작될 수 있으며 첫 연결 시에야 문제가 드러나기도 합니다. “시작 성공” 메시지를 보려고 프로토콜을 다른 종류로 바꾸지 마세요. 기존 설정 오류가 이후 연결 오류로 바뀔 뿐입니다. 필드 구조와 라우팅 관계는 설정 참고 자료를 보며 하나씩 확인하세요.
6. 최소 설정으로 문제를 분리한 뒤 항목별로 복구
설정이 길고 인바운드와 라우팅 그룹이 여러 개라면 복사본에 최소 설정을 만들어 읽기 및 구성 단계를 확인할 수 있습니다. 아래 예시는 로컬 SOCKS 인바운드와 직접 연결 아웃바운드만 포함하며 원격 노드는 없고 프록시 출구를 테스트하는 용도도 아닙니다. minimal.json으로 저장하고 기존 구독 또는 노드 설정을 덮어쓰지 마세요.
{
"log": {
"loglevel": "warning"
},
"inbounds": [
{
"tag": "local-socks",
"listen": "127.0.0.1",
"port": 10818,
"protocol": "socks",
"settings": {
"auth": "noauth",
"udp": false
}
}
],
"outbounds": [
{
"tag": "direct",
"protocol": "freedom",
"settings": {}
}
]
}.\xray.exe run -test -config ".\minimal.json"이 파일은 테스트를 통과하지만 원래 설정은 통과하지 못한다면 원래 설정을 한 부분씩 복구하세요. 실제 프록시 아웃바운드를 먼저 넣고, 다음으로 전송 및 보안 계층을 추가한 뒤, 마지막으로 DNS와 라우팅을 복원합니다. 각 부분을 추가할 때마다 다시 테스트하세요. 처음으로 실패한 변경 항목이 집중적으로 확인할 대상입니다. 최소 설정을 실제로 실행하려면 먼저 10818이 비어 있는지 확인하세요. 이 설정은 모든 트래픽을 직접 연결하므로 원래 노드의 사용 가능 여부를 판단하는 데 쓰면 안 됩니다.
- 한 번에 변수 하나만 변경: 노드 변경, 포트 수정, 코어 교체를 동시에 하면 무엇 때문에 문제가 해결됐는지 알 수 없습니다.
- 변경 전후 차이 기록: 수정한 필드와 이유를 기록하되 문제 해결 메모에 전체 인증 정보를 남기지 마세요.
- 기존 보호 설정 복원: 임시로 로그 수준을 변경했다면 확인 후 원래대로 되돌리세요. 액세스 로그에는 대상 도메인 등의 정보가 포함될 수 있습니다.
- 마지막으로 실제 사용 확인: 코어가 안정적으로 실행된 뒤 시스템 프록시, 브라우저 접속, 예상되는 출구를 확인하세요.
7. 설정 오류 해결 관련 자주 묻는 질문
config.json을 수정해도 노드를 바꾸면 다시 문제가 생기나요?
먼저 해당 파일이 v2rayN에서 자동 생성한 실행 설정인지 확인하세요. 자동 생성 파일이라면 서버 목록에서 해당 노드를 편집하거나 사용자 지정 설정 소스를 수정한 뒤 다시 로드하세요. 생성된 파일만 수정하면 다음에도 변경 사항이 유지된다는 보장이 없습니다.
설정 테스트는 통과했는데 왜 시작에 실패하나요?
시작 로그에서 리스닝 오류를 확인하고 실제 인바운드 포트를 조회하세요. 테스트는 원격 연결 상태를 확인하지 않으며 실행 시 포트를 사용할 수 있는지도 보장하지 않습니다. 테스트 통과를 전체 네트워크 연결 확인으로 간주하지 마세요.
로그에 종료 메시지만 있고 구체적인 오류가 없다면 어떻게 하나요?
클라이언트에 표시된 시작 명령과 설정 경로를 보관하고 같은 Xray 프로그램으로 터미널에서 설정 테스트를 실행하세요. 그래도 출력이 없다면 log에 설정된 error 파일 경로와 읽기 권한을 확인해 오류가 별도 로그에 기록되는지 살펴보세요.
클라이언트를 다시 설치하면 바로 해결되나요?
먼저 노드와 구독 설정을 백업한 뒤 어느 단계에서 실패하는지 확인하세요. 다른 프로세스가 포트를 점유하거나 구독 매개변수가 잘못되었거나 인바운드가 중복된 문제는 대개 재설치해도 해결되지 않습니다. 프로그램 파일에 문제가 있거나 버전 호환성이 없다고 확인된 경우에만 호환되는 버전으로 교체하세요.
문제 해결의 기준은 오류 창이 사라지는 것이 아니라 원인을 설명하고 같은 결과를 다시 확인할 수 있는 것입니다. 원래 설정이 실패한 이유, 어떤 항목을 수정해 테스트를 통과했는지, 클라이언트를 재시작해도 정상인지 확인하세요. 실제 네트워크 연결을 확인하려면 사용 가이드에 따라 노드를 선택하고 프록시를 테스트하세요. 설정 구성, 포트 바인딩 성공, 원격 연결 성공은 서로 다른 결과입니다.