v2rayN 실행 로그 확인 방법: 주요 오류 메시지와 문제 해결 절차

v2rayN 로그의 세 가지 정보부터 구분하기

v2rayN 창에 표시되는 모든 정보가 오류는 아닙니다. 클라이언트는 구독, 화면 상태, 시스템 프록시와 코어 프로세스를 관리하고, Xray 또는 V2Fly 코어는 연결, 프로토콜, DNS와 라우팅을 담당합니다. 액세스 로그는 특정 대상 주소가 어떤 아웃바운드를 거쳤는지 보여 줍니다. 세 종류의 내용이 시간순으로 섞여 표시될 수 있으므로 마지막 줄만 보면 상위 단계의 결과를 근본 원인으로 오해하기 쉽습니다.

v2rayN 7.x에서는 먼저 메인 창 하단의 정보 영역을 확인하세요. 로그 상세도를 조정하려면 「설정」→「매개변수 설정」으로 이동해 로그 수준, 액세스 로그 또는 코어 출력과 관련된 옵션을 찾습니다. 세부 버전에 따라 항목 이름은 조금 다를 수 있지만, 클라이언트 화면에서 제공하는 옵션을 우선 사용해야 합니다. 실행 중 자동 생성된 설정 파일을 직접 수정하면 다음 코어 시작 때 클라이언트가 파일을 다시 만들 수 있습니다.

일반적인 프록시 요청은 애플리케이션, 로컬 리스너, 라우팅 판단, 프로토콜 캡슐화, 원격 연결 순서로 진행됩니다. 로그에서 오류가 앞 단계에 나타날수록 로컬 포트와 프록시 설정을 먼저 확인하고, 뒤 단계에 나타날수록 서버 주소, 포트, 전송 방식, TLS와 사용자 인증 정보를 점검해야 합니다.

로그는 어디부터 읽어야 할까

먼저 시간을 확인하고, 다음으로 로그 수준과 모듈을 본 뒤, 오류 체인을 끝에서부터 거꾸로 따라가세요. 많은 Xray 로그는 여러 개의 큰따옴표가 아닌 꺾쇠표(>)로 호출 관계를 연결합니다. 앞부분은 어느 모듈이 실패를 보고했는지 나타내고, 마지막 부분이 하위 단계의 실제 원인에 가까운 경우가 많습니다. 예를 들어 한 줄에 “failed to process outbound traffic”과 “i/o timeout”이 함께 있다면 우선 처리할 것은 포괄적인 아웃바운드 처리 실패가 아니라 연결 시간 초과입니다.

대상 주소도 중요합니다. 오류 대상이 구독 도메인이라면 구독 업데이트 과정의 문제이고, 노드 서버 주소라면 프록시 연결 수립 단계의 문제입니다. 노드 연결은 성공했지만 특정 웹사이트 도메인에서 DNS 오류가 발생한다면 DNS 또는 라우팅 규칙을 확인해야 합니다. 한 번의 구독 업데이트 실패만으로 가져온 모든 노드를 사용할 수 없다고 판단하지 마세요.

2026/08/02 14:21:08 [Warning] transport/internet/tcp:
failed to dial TCP > dial tcp 203.0.113.10:443: i/o timeout

2026/08/02 14:21:24 [Info] proxy/http:
request to tcp:example.com:443 accepted [proxy]

위 첫 번째 로그는 노드 예시 주소의 443 포트에 TCP 연결을 수립하는 과정에서 시간 초과가 발생했음을 뜻합니다. 노드 주소, 포트, 로컬 네트워크와 원격 연결 가능성을 확인해야 합니다. 두 번째 로그의 accepted는 로컬 HTTP 프록시가 애플리케이션 요청을 받았다는 의미일 뿐, 대상 웹페이지가 성공적으로 반환되었다는 뜻은 아닙니다. 같은 초 이후에 프록시 아웃바운드 실패가 나타나는지 계속 확인하세요.

rejected, timeout, invalid user는 각각 무엇을 의미할까

키워드만으로는 장애 범위만 좁힐 수 있으며, 문맥 없이 유일한 원인을 확정할 수 없습니다. 같은 timeout도 노드 포트에 연결할 수 없어서 발생할 수 있고 DNS 조회나 대상 웹사이트 응답 때문에 발생할 수도 있습니다. rejected 역시 라우팅이 의도적으로 거부한 경우와 서버가 프로토콜 요청을 거부한 경우가 모두 가능합니다. 오류를 복사할 때는 최소한 앞뒤 각 두 줄, 타임스탬프, 모듈 이름과 전체 오류 체인을 함께 남기세요.

invalid user에서 UUID만 확인하면 안 되는 이유

VMess와 VLESS는 모두 사용자 식별자를 사용하지만 서로 바꿔 쓸 수 있는 프로토콜은 아닙니다. 가져오는 과정에서 프로토콜 유형이 잘못 인식되면 UUID 문자가 완전히 같아도 서버가 요청을 정상적으로 처리하지 않습니다. 오래된 VMess 설정에는 추가 매개변수가 포함될 수 있으므로 현재 설정은 최신 구독 내용을 기준으로 확인하고, 기억에 의존해 직접 조합하지 않는 것이 좋습니다.

오류가 현재 선택한 노드에서 발생한 것인지도 확인해야 합니다. 구독을 업데이트하면 목록에 기존 그룹과 새 그룹이 함께 남을 수 있으며, 이름이 비슷해도 설정이 같다는 뜻은 아닙니다. 먼저 현재 노드 이름을 기록하고 서버 목록에서 선택된 행을 확인한 뒤, 다른 백그라운드 요청이 로그를 뒤섞지 않도록 웹페이지 하나만 접속해 테스트하세요.

• 포트 번호로 추측하지 말고 프로토콜 유형이 VMess인지 VLESS인지 확인합니다.
• UUID의 문자와 하이픈을 확인하고 앞뒤에 공백이 섞이지 않았는지 점검합니다.
• 해당 구독 그룹을 업데이트하고 이전 노드 복사본을 계속 선택하고 있지 않은지 확인합니다.
• 시스템 날짜, 시간과 시간대를 확인합니다. 큰 시간 오차는 핸드셰이크와 인증에 영향을 줄 수 있습니다.
• 코어를 재시작한 뒤 다시 테스트해 이전 연결이 관찰 시간을 차지하지 않도록 합니다.

오류에서 구체적인 설정 항목으로 거슬러 올라가기

효율적인 문제 해결에서는 한 번에 하나의 변수만 바꿔야 합니다. 설정 하나만 변경한 뒤 현재 로그의 마지막 시각을 지우거나 기록하고 같은 테스트 요청을 다시 보내세요. 노드, DNS, 라우팅 모드와 로컬 포트를 동시에 바꾸면 연결이 복구되어도 실제 원인을 알 수 없어 이후 같은 문제를 해결하기 어렵습니다.

먼저 정상적으로 열리는 일반 웹페이지 하나를 고정 테스트 대상으로 선택하고, 계속 네트워크에 접속하는 다운로드 프로그램과 동기화 프로그램을 종료하세요. 그런 다음 현재 노드, 시스템 프록시 상태, 로컬 포트와 테스트 시간을 기록합니다. 설정을 바꾼 뒤 약 15초간 기다리며 같은 오류가 다시 발생하는지 확인하고, 세 번 반복해도 같은 단계에서 나타날 때 안정적인 장애로 판단하세요.

1. 코어가 실행 중인지 확인합니다.설정 구문 오류나 로컬 포트 리슨 실패가 먼저 나타난다면 요청이 아직 컴퓨터 밖으로 나가지 않았으므로 원격 노드를 확인할 필요가 없습니다.
2. 애플리케이션이 로컬 프록시로 들어오는지 확인합니다.웹페이지에 접속한 뒤 accepted나 대상 도메인 기록이 전혀 없다면 시스템 프록시, 브라우저 프록시 설정 또는 애플리케이션이 시스템 설정을 따르는지 확인하세요.
3. 라우팅 동작을 확인합니다.대상이 direct, proxy 또는 blocked 중 어디로 전달되었는지에 따라 다음에 직접 연결 네트워크, 노드 아웃바운드 또는 차단 규칙을 점검할지가 결정됩니다.
4. 노드 연결 단계를 확인합니다.도메인 해석, TCP 연결, TLS 핸드셰이크와 프로토콜 인증을 순서대로 확인하고, 이전 단계를 건너뛴 채 다음 단계의 매개변수를 수정하지 마세요.
5. 두 번째 노드와 비교합니다.같은 네트워크, 애플리케이션과 라우팅에서 노드만 바꾸면 클라이언트 공통 설정 문제인지 특정 노드 설정 문제인지 구분할 수 있습니다.

로그는 정상인데 웹페이지가 열리지 않을 때 확인할 항목

로그에 accepted가 표시되는 것은 요청이 로컬 프록시에 도달했다는 사실만 증명합니다. 이후 proxy가 표시되고 뚜렷한 오류가 없는데도 웹페이지가 열리지 않는다면 DNS 응답, 브라우저 자체의 프록시 정책과 대상 웹사이트 연결을 계속 확인하세요. 일부 브라우저는 독립적인 DNS 방식을 사용할 수 있고 명령줄 도구도 시스템 프록시를 자동으로 읽지 않을 수 있으므로, 한 애플리케이션은 되는데 다른 애플리케이션은 안 되는 현상은 대개 노드 전체의 장애가 아닙니다.

Windows에서 v2rayN의 시스템 프록시를 켜면 시스템 설정을 따르는 데스크톱 애플리케이션이 해당 프록시를 사용합니다. 수동으로 프록시를 설정한 프로그램은 클라이언트의 현재 리슨 주소와 포트를 직접 입력해야 합니다. 로컬 혼합 포트가 10808로 표시된다면 화면에 표시된 실제 값을 사용하고, 오래된 안내에서 10809를 봤다고 그대로 입력하지 마세요. 포트가 다르면 v2rayN 로그에 해당 요청이 전혀 기록되지 않을 수 있습니다.

라우팅 규칙 때문에 겉보기에는 “연결 성공 후 접속 불가”처럼 보일 수도 있습니다. 예를 들어 대상 도메인이 direct와 일치하고 현재 네트워크에서 해당 대상에 직접 연결할 수 없다면, 코어는 실패한 요청을 자동으로 프록시로 전환하지 않습니다. blocked와 일치하면 규칙에 따라 차단됩니다. 액세스 로그의 아웃바운드 태그를 확인하는 편이 시스템 프록시를 반복해서 전환하는 것보다 빠릅니다.

플랫폼과 코어가 다를 때 로그를 비교하는 방법

Windows, macOS와 Linux에서 데스크톱 클라이언트를 사용할 때 화면 구성은 버전에 따라 조금 다를 수 있지만 문제 해결 순서는 같습니다. 먼저 클라이언트가 코어를 정상적으로 시작했는지 확인하고, 이어서 로컬 리슨, 라우팅 동작과 프록시 아웃바운드를 확인하세요. Android의 v2rayNG는 Xray 코어를, v2flyNG는 V2Fly 코어를 사용하므로 로그 표현은 다를 수 있지만 TCP, DNS, TLS, 인증과 라우팅 단계는 서로 대응시킬 수 있습니다.

한 코어의 전체 오류 문구가 다른 코어에서도 한 글자씩 같아야 한다고 기대하지 마세요. 한 버전은 context deadline exceeded를 표시하고 다른 버전은 같은 상황에서 timeout만 표시할 수 있습니다. 실제로 비교해야 할 것은 오류가 해석, 연결, 인증 중 어느 단계에서 발생했는지입니다. 구독에 VLESS 등의 설정이 포함되어 있다면 현재 클라이언트와 코어 버전이 해당 설정 필드를 지원하는지도 확인하세요.

로그를 다른 사람에게 전달할 때 남겨야 할 내용

장애 기록에는 클라이언트 버전, 코어 유형, 운영체제, 문제 발생 시간, 선택한 프로토콜, 오류 전후의 몇 줄과 이미 시도한 단계를 포함해야 합니다. 서버 주소, UUID, 구독 주소와 기타 인증 정보는 그대로 공개하지 말고 동일한 방식의 마스킹 표기로 바꾸세요. 다만 포트, 프로토콜, 전송 방식과 오류 구조는 남겨야 발생 단계를 판단할 수 있습니다.

플랫폼: Windows
클라이언트: v2rayN 7.x
코어: Xray
현상: 시스템 프록시를 켜면 웹페이지 시간 초과
재현 시간: 14:21:08
현재 프로토콜: VLESS
노드 주소: server.example
노드 포트: 443
주요 오류: dial tcp server.example:443: i/o timeout
시도한 방법: 구독 업데이트, 다른 노드로 전환, 다른 설정은 그대로 유지

로그 분석의 핵심은 텍스트를 많이 수집하는 데 있지 않고 시간 순서를 세우는 데 있습니다. 사용자가 무엇을 했는지, 요청이 어느 계층으로 들어갔는지, 어느 단계에서 멈췄는지, 어떤 항목을 바꾼 뒤 결과가 달라졌는지를 기록하세요. 이 흐름을 따라가면 rejected는 라우팅 또는 원격 거부로, timeout은 구체적인 연결 단계로, invalid user는 프로토콜과 인증 매개변수로 범위를 좁힐 수 있어 모든 설정 사이를 반복해서 오갈 필요가 없습니다.