V2Ray 실행 로그 확인 방법: 자주 발생하는 오류 의미와 문제 해결 방법

먼저 로그가 기록하는 단계를 구분하세요

V2Ray 또는 Xray의 연결 과정은 하나의 동작으로 끝나지 않습니다. 애플리케이션이 먼저 요청을 로컬 리스닝 포트로 전달하면, 코어가 라우팅 규칙을 읽고 대상 도메인을 조회한 뒤 아웃바운드를 선택해 원격 서버에 연결합니다. 이후 프로토콜 인증과 전송 핸드셰이크가 진행됩니다. 로그에는 보통 실패한 단계만 기록되며, 한 번에 해결 방법 전체가 표시되지는 않습니다. 오류 한 줄만 보고 클라이언트를 바로 재설치하기보다 연결 흐름 속에서 해당 오류가 발생한 위치를 확인해야 합니다.

가장 실용적인 방법은 같은 작업에서 거의 동시에 기록된 여러 줄을 함께 읽는 것입니다. 먼저 이전 로그를 지우거나 일시 중지한 다음, 확실한 URL을 열거나 특정 애플리케이션을 실행하고 곧바로 새로 나타난 내용을 확인하세요. 이렇게 하면 몇 시간 전의 구독 업데이트 오류나 백그라운드 탐색 결과가 현재 연결 실패와 뒤섞이는 일을 막을 수 있습니다.

로그 레벨도 함께 확인해야 합니다. info는 정상적인 시작, 연결 수신 및 라우팅 결과를 기록할 때 주로 사용합니다. warning은 비정상적인 조건이 있음을 뜻하지만 모든 연결이 실패한다는 의미는 아닙니다. error는 현재 작업이 명확히 실패한 지점이므로 우선적으로 확인해야 합니다. 연결 오류가 발생한 뒤 브라우저가 자동으로 재시도해 성공할 수도 있으므로, 웹페이지가 실제로 열리는지, 노드 테스트가 통과하는지, 오류가 계속 반복되는지도 함께 살펴보세요.

v2rayN과 v2rayNG에서 로그를 확인하는 위치

v2rayN: 코어 출력부터 확인한 뒤 클라이언트 알림을 살펴보세요

v2rayN의 화면은 버전과 레이아웃 설정에 따라 조금씩 다를 수 있습니다. 일반적으로 메인 창 하단의 로그 또는 정보 영역에서 실행 출력을 확인할 수 있으며, 해당 영역이 접혀 있다면 메인 화면의 보기, 로그 또는 관련 메뉴에서 다시 열 수 있습니다. 노드 시작, 구독 업데이트, 지연 시간 테스트, 시스템 프록시 전환 시 클라이언트 알림과 코어 로그가 서로 다른 영역에 표시될 수 있습니다. 연결 문제를 확인할 때는 Xray, V2Ray, inbound, outbound, transport 등이 포함된 코어 실행 기록을 우선 확인하세요.

시작을 눌렀는데 새 로그가 전혀 추가되지 않는다면 코어 프로세스가 실제로 시작했는지 먼저 확인하세요. 설정 생성 실패, 다른 프로그램이 로컬 리스닝 포트를 사용 중인 경우, 파일 접근 권한 문제 등으로 연결 전에 과정이 멈출 수 있습니다. 이때 반복해서 속도를 측정해도 의미 있는 결론을 얻기 어렵습니다. 시작 단계에서 나타난 첫 번째 오류부터 해결해야 합니다.

로그에 accepted가 표시되고 로컬 주소에서 들어온 연결이 보인다면 브라우저나 애플리케이션이 트래픽을 로컬 프록시로 전달한 것입니다. 이후 timeout, rejected 또는 핸드셰이크 실패가 발생한다면 노드 매개변수, 네트워크 경로 또는 원격 서비스를 계속 확인해야 합니다. 반대로 브라우저에는 계속 오류가 표시되는데 로그에 해당하는 새 연결이 없다면 시스템 프록시 상태, 애플리케이션의 시스템 프록시 준수 여부, 로컬 리스닝 포트와 애플리케이션에 입력한 포트의 일치 여부가 핵심입니다.

v2rayNG: 사이드 메뉴에서 로그 페이지 열기

v2rayNG에서는 보통 사이드 메뉴를 통해 로그 페이지로 이동할 수 있습니다. 문제를 확인하기 전에 설정을 시작하고, 대상 애플리케이션으로 돌아가 연결 요청을 한 번 발생시킨 뒤 즉시 로그 페이지로 돌아와 마지막 부분을 확인하세요. Android의 백그라운드 관리로 애플리케이션이 일시 중지되거나 네트워크 연결을 다시 만들 수 있으므로 v2rayNG가 여전히 정상 실행 중인지도 함께 확인해야 합니다.

v2rayNG에서 Xray 코어를 사용할 때 프로토콜 연결, DNS, 라우팅 및 전송 오류는 코어 출력에 기록됩니다. 시스템 네트워크 전환이나 가상 네트워크 인터페이스 상태 정보가 코어 기록과 섞여 나타날 수도 있습니다. 판단 기준은 동일합니다. 처음 실패한 시점을 찾고 가장 먼저 나타난 오류부터 이후 기록을 읽으세요. 마지막 한 줄만 잘라서 확인하지 마세요.

v2rayNG 로그에 로컬 요청이 들어온 기록이 있는데 모든 노드가 같은 단계에서 시간 초과된다면 현재 네트워크를 한 번 전환한 뒤 다시 테스트하세요. 구독의 다른 노드는 정상이고 특정 노드 하나만 실패한다면 해당 노드의 매개변수나 상태를 우선 확인해야 합니다. 이와 같은 비교가 오류 한 줄만 계속 살펴보는 것보다 효과적입니다.

rejected: 요청이 거부된 위치 확인

rejected는 말 그대로 요청이 거부되었다는 뜻이지만, 거부한 주체가 반드시 원격 서버인 것은 아닙니다. 로컬 라우팅 규칙, 대상 호스트, 프록시 프로토콜 인증, 전송 계층 핸드셰이크 또는 상대방의 연결 종료로 인해 발생할 수 있습니다. 이 줄의 앞뒤에 있는 모듈명과 추가 정보를 함께 확인해야 합니다.

blocked, 라우팅 규칙 이름 또는 명시적인 차단 아웃바운드가 함께 표시된다면 요청이 로컬 규칙에 의해 차단 출구로 전달되었을 가능성이 있습니다. 예를 들어 사용자 지정 규칙이 특정 도메인을 거부 목록에 넣었거나, 규칙 순서 때문에 대상이 프록시 아웃바운드에 도달하기 전에 먼저 매칭될 수 있습니다. 이때는 UUID를 바꾸기보다 현재 라우팅 모드를 확인하고 대상 도메인을 일시적으로 프록시 또는 직접 연결로 설정해 비교하세요.

connection refused가 나타난다면 일반적으로 대상 IP에 대한 네트워크 연결이 명확하게 거부된 것입니다. 원격 포트가 리스닝 중이 아니거나, 서버 서비스가 시작되지 않았거나, 포트 입력이 잘못되었거나, 중간 네트워크 장비가 거부 응답을 반환한 경우가 흔합니다. 단순한 시간 초과와 달리 거부는 대개 빠르게 반환되며, 시간 초과는 수 초 이상 기다린 뒤 발생하는 경우가 많습니다.

rejected와 함께 handshake, authentication, invalid user 등의 정보가 나타나면 노드 매개변수와 서버 설정의 일치 여부를 중점적으로 확인하세요. 프로토콜 유형, 서버 포트, 사용자 식별자, 전송 방식, 보안 설정, 호스트명 및 경로를 항목별로 비교합니다. 구독으로 가져온 노드는 특정 필드를 추측해 수동으로 수정하지 않는 것이 좋습니다. 먼저 구독을 업데이트한 뒤 업데이트 전후의 설정을 비교하세요.

대상 웹사이트 자체의 거부도 고려해야 합니다. 노드 연결과 프록시 통로는 정상이어도 특정 대상이 접근을 제한하거나 연결을 적극적으로 종료할 수 있습니다. 같은 노드로 서로 다른 여러 사이트에 접속해 보세요. 대부분의 대상은 정상이고 한 곳만 계속 실패한다면 문제를 V2Ray 코어 또는 노드 인증 탓으로 단정해서는 안 됩니다.

timeout: 시간 초과가 발생한 단계부터 확인

timeout은 가장 흔하면서도 범위가 넓은 오류입니다. 특정 단계가 정해진 시간 안에 완료되지 않았다는 뜻일 뿐입니다. DNS 조회, TCP 연결, TLS 핸드셰이크, WebSocket 연결, 응답 읽기 등 여러 단계에서 시간 초과가 발생할 수 있습니다. timeout을 확인했다면 같은 줄이나 상위 오류에 있는 동사를 먼저 찾으세요. 예를 들어 lookup, dial, connect, handshake, read 같은 단어가 대기한 위치를 알려줍니다.

서버 주소 연결 중 시간 초과

기록이 서버 IP와 포트를 가리키며 dial 또는 connect가 나타난다면 로컬 장치가 외부 연결을 시도했지만 제때 완료하지 못한 것입니다. 먼저 같은 구독의 다른 노드를 테스트하고 현재 네트워크도 전환해 보세요. 노드 하나만 시간 초과되면 해당 노드 상태나 포트 문제일 가능성이 높습니다. 같은 네트워크에서 모든 노드가 시간 초과되고 네트워크를 바꾸면 정상으로 돌아온다면 현재 네트워크 경로 문제에 가깝습니다. 모든 네트워크와 모든 노드에서 실패한다면 로컬 설정과 코어 시작 상태를 다시 확인해야 합니다.

핸드셰이크 단계 시간 초과

하위 계층 연결이 성립된 뒤에도 프로토콜과 전송 계층은 계속 데이터를 주고받아야 합니다. 로그가 TLS, WebSocket 또는 다른 전송 핸드셰이크 단계에서 멈췄다면 서버 이름, 전송 유형, 경로, 호스트 필드 및 보안 매개변수를 확인하세요. 서버 주소에 연결할 수 있다고 해서 상위 계층 매개변수까지 일치한다는 뜻은 아닙니다. 시간 설정 차이로 인증서 유효 기간이나 시간 범위에 의존하는 연결이 영향을 받을 수도 있으므로 데스크톱과 Android 기기 모두 정확한 시스템 시간을 사용해야 합니다.

데이터 읽기 중 시간 초과

read timeout 또는 컨텍스트 제한 시간 도달은 연결은 성립했지만 이후 데이터가 반환되지 않았다는 뜻일 수 있습니다. 대용량 파일을 다운로드하거나 지속 연결을 사용할 때만 발생한다면 네트워크 안정성을 확인하세요. 어떤 웹페이지를 열어도 매번 같은 초 후에 실패한다면 원격 서비스, 전송 매개변수 및 DNS 결과를 계속 점검해야 합니다. 지연 시간 테스트만으로 실제 접속 테스트를 대신하지 마세요. 지연 탐색과 전체 웹페이지 연결은 서로 다른 요청 흐름을 사용할 수 있습니다.

timeout 비교 점검 순서
1. 같은 노드에서 다른 웹사이트로 접속
2. 같은 네트워크에서 다른 구독 노드로 전환
3. 같은 노드에서 현재 네트워크 전환
4. 구독을 업데이트한 뒤 노드를 다시 선택
5. 로그의 dial, handshake, read 또는 DNS 단계를 비교
6. 변수 하나만 변경한 뒤 다음 테스트 진행

invalid user: 서버와 인증 정보가 일치하지 않음

invalid user는 보통 VMess처럼 사용자 식별이 필요한 프로토콜을 처리하는 과정에서 나타나며, 서버가 받은 인증 정보를 유효한 사용자와 연결하지 못했다는 뜻입니다. 가장 흔한 원인은 UUID 불일치, 변경된 노드 설정, 구독에 남아 있는 이전 노드 사용 또는 실제로 잘못된 서버 포트에 연결된 경우입니다.

먼저 구독을 업데이트하고 현재 선택된 노드가 실제로 업데이트된 항목인지 확인하세요. v2rayN에는 이전 그룹, 수동 노드, 새 구독 노드가 동시에 남아 있을 수 있습니다. 이름이 비슷해도 매개변수가 같다는 뜻은 아닙니다. v2rayNG에도 중복 설정이 있을 수 있으므로 구독 업데이트 성공 여부만 보지 말고 현재 실행 중인 항목을 확인해야 합니다.

노드를 수동으로 설정했다면 UUID, 프로토콜 및 포트를 한 글자씩 대조하세요. UUID에 공백이 하나 더 들어가거나 문자가 빠졌거나 잘못된 필드에 붙여 넣어도 인증에 실패할 수 있습니다. 구독 링크 자체를 노드 주소에 입력하지 말고, 노드 공유 내용을 경험에 의존해 임의로 나누거나 필드를 추가하지 마세요. VLESS에서는 인증 및 요청 분석 실패 시 표시되는 구체적인 문구가 다를 수 있지만, 사용자 식별자, 흐름 제어, 보안 계층, 전송 방식 및 서버 진입점이 일치하는지 확인하는 것이 핵심입니다.

여러 기기에서 같은 최신 설정을 사용하고 있는데 한 기기에서만 invalid user가 계속 발생한다면 해당 기기의 이전 노드를 삭제하고 구독을 다시 가져온 뒤 같은 이름의 오래된 항목이 선택되지 않았는지 확인하세요. 모든 기기에서 같은 시점부터 실패하고 로컬에서 설정을 변경하지 않았다면 서비스 제공자에게 사용자 상태와 서버 설정을 확인해 달라고 요청해야 합니다.

DNS 조회 실패: 도메인이 사용 가능한 주소로 변환되지 않음

DNS는 도메인을 IP 주소로 변환합니다. 로그에 failed to lookup, no such host, DNS query failed 또는 조회 시간 초과가 나타난다면 연결이 아직 대상 서버에 도달하지 않았을 수 있습니다. 먼저 두 종류의 도메인을 구분해야 합니다. 하나는 노드 서버 주소이고 다른 하나는 사용자가 접속하려는 대상 도메인입니다. 전자의 조회가 실패하면 노드 전체가 연결을 시작할 수 없고, 후자의 실패는 특정 웹사이트에만 영향을 줄 수 있습니다.

노드 서버에 도메인을 사용하는 경우 해당 도메인의 조회가 실패하면 보통 원격 연결 전에 오류가 기록됩니다. 도메인 철자와 현재 네트워크의 DNS 조회 가능 여부를 먼저 확인한 뒤, 주소가 변경되지 않았는지 확인하기 위해 구독을 업데이트하세요. 서버 주소를 IP로 직접 입력했다면 이 단계에서 서버 도메인 조회는 필요하지 않지만 대상 웹사이트에는 여전히 DNS가 필요합니다.

일부 도메인만 실패한다면 라우팅 규칙과 DNS 규칙이 서로 맞물려 있는지 확인해야 합니다. 예를 들어 도메인은 프록시 대상으로 판정되었지만 DNS 조회는 현재 네트워크에서 접근할 수 없는 리졸버로 전송될 수 있습니다. 사용자 지정 규칙이 현재 연결에 적합하지 않은 결과를 반환하는 경우도 있습니다. 클라이언트의 기본 라우팅 및 DNS 설정으로 일시적으로 되돌리면 사용자 지정 항목이 원인인지 판단할 수 있습니다.

모든 도메인 조회가 시간 초과되지만 알려진 IP에 직접 접속하면 응답이 있다면 DNS 서버 연결 가능 여부, 시스템 네트워크 및 클라이언트 DNS 설정을 중점적으로 확인해야 합니다. 반복 조회나 요청 재시도가 계속 나타난다면 로컬 리스닝 포트, 시스템 DNS와 프록시 DNS가 서로 전달을 반복하는 구조인지도 확인하세요. 수정 후에는 코어를 다시 시작해 기존 연결과 캐시를 종료해야 합니다.

도메인이 조회된다고 해서 그 결과가 현재 연결 경로에 적합하다는 뜻은 아닙니다. 조회된 주소에 연결할 수 없으면 로그에 조회 성공이 먼저 표시된 뒤 dial 단계에서 시간 초과가 발생할 수 있습니다. 이때 문제는 이미 DNS 단계에서 네트워크 연결 단계로 넘어간 것이므로 timeout 점검 방법에 따라 노드, 네트워크 및 대상 주소를 계속 비교하세요.

설정, 포트 및 리소스 파일 오류

일부 문제는 코어가 시작되기 전에 발생하므로 웹페이지에는 프록시 연결 기록이 전혀 나타나지 않을 수 있습니다. 설정 분석 실패, 알 수 없는 필드, 필수 매개변수 누락 또는 파일 로드 실패가 로그에 표시되면 먼저 시작 가능한 설정으로 복구하세요. JSON을 수동으로 편집할 때는 쉼표, 괄호, 필드 계층 및 데이터 유형이 형식에 맞아야 합니다. v2rayN이나 v2rayNG의 구독 가져오기 기능을 사용할 때는 설정 파일과 클라이언트 생성 결과가 서로 덮어쓰지 않도록 가능한 한 앱 안에서 수정하세요.

address already in use 또는 유사한 포트 사용 메시지는 로컬 SOCKS, HTTP 또는 다른 인바운드 포트를 다른 프로세스가 이미 리스닝하고 있다는 뜻입니다. 이전 코어가 종료되지 않았거나, 클라이언트를 중복 실행했거나, 다른 로컬 서비스가 같은 포트를 사용하는 경우가 흔합니다. 먼저 현재 클라이언트를 완전히 종료한 뒤 다시 시작하세요. 그래도 오류가 계속되면 클라이언트의 로컬 포트를 변경하고 해당 포트를 사용하는 애플리케이션 설정도 함께 업데이트하세요.

라우팅 데이터 파일을 로드하지 못하면 geosite 또는 geoip에 의존하는 규칙이 작동하지 않을 수 있으며, 심한 경우 설정 시작 자체가 차단됩니다. 이런 로그에는 파일이 존재하지 않거나 읽을 수 없거나 규칙 이름이 유효하지 않다는 내용이 보통 명확히 표시됩니다. 현재 클라이언트 및 코어에 맞는 리소스 파일을 사용하고 사용자 지정 규칙이 참조하는 분류 이름이 실제로 존재하는지 확인하세요. 리소스 파일 오류를 노드 장애로 오해하지 마세요.

설정에 알 수 없는 필드가 나타난다면 클라이언트와 코어의 기능이 맞지 않을 수도 있습니다. 먼저 다운로드 센터에서 제공하는 최신 클라이언트 버전을 사용하고 클라이언트가 호환되는 코어를 관리하도록 하세요. 오래된 설정을 이전할 때는 구독을 가져와 기본 설정을 새로 만들고 연결이 되는지 확인한 다음 라우팅이나 DNS 사용자 지정 항목을 하나씩 추가하는 것이 좋습니다.

로컬 문제, 노드 문제 및 서버 문제를 구분하는 방법

로그 한 줄은 하나의 실패 현상만 보여줄 뿐이며, 원인을 구분하려면 비교 테스트가 필요합니다. 가장 안정적인 방법은 노드, 네트워크, 기기, 대상이라는 네 가지 변수를 두고 한 번에 하나만 변경하는 것입니다. 이렇게 하면 여러 설정을 동시에 바꾼 뒤 판단 근거를 잃지 않고 범위를 빠르게 좁힐 수 있습니다.

로컬 문제를 판단할 때는 코어가 시작되는지, 요청이 로컬 인바운드로 들어오는지, 라우팅이 예상한 아웃바운드에 매칭되는지를 중점적으로 봅니다. 노드 문제라면 같은 클라이언트의 다른 노드가 정상인지 확인하세요. 서버 문제라면 여러 기기나 네트워크에서 같은 결과가 나타나고, 로그가 인증, 원격 포트 또는 서버 처리 단계에 집중되어야 합니다.

“지연 시간은 정상인데 웹페이지가 열리지 않는” 상황은 모순이 아닙니다. 지연 시간 테스트는 특정 포트에 도달하거나 짧은 연결 한 번을 완료하는지만 확인할 수 있지만, 실제 웹페이지 접속에는 DNS, 라우팅, 프로토콜 전송 및 대상 접근 과정이 모두 필요합니다. 실제 연결 로그를 기준으로 삼고 테스트 이후 나타난 핸드셰이크, 읽기 또는 대상 연결 오류를 계속 찾아야 합니다.

반복 실행할 수 있는 로그 점검 절차

1. 클라이언트 실행 상태를 확인합니다. v2rayN 또는 v2rayNG의 실행 상태를 확인하고 코어가 시작된 직후 종료되지 않았는지 살펴보세요.
2. 구독을 업데이트하고 명확한 노드를 선택합니다. 같은 이름의 이전 노드를 계속 사용하지 않도록 현재 노드 이름과 업데이트 시간을 기록하세요.
3. 이전 로그를 정리합니다. 새 테스트 한 번으로 생성된 내용만 남겨 백그라운드 요청의 간섭을 줄이세요.
4. 단일 요청을 발생시킵니다. 확실히 접속 가능한 사이트 하나를 열고 속도 테스트, 구독 업데이트, 대량 다운로드를 동시에 실행하지 마세요.
5. 첫 번째 오류를 찾습니다. 처음 error 또는 warning이 나타난 위치에서 위쪽으로 몇 줄을 읽고 설정, 인바운드, 라우팅, DNS, 연결, 인증 중 어느 단계에 해당하는지 확인하세요.
6. 오류 유형에 따라 처리합니다. rejected는 거부 위치를, timeout은 시간 초과 동작을, invalid user는 인증 정보를, DNS 오류는 조회 대상과 리졸버를 확인하세요.
7. 한 번에 변수 하나만 변경합니다. 먼저 노드를 바꾸거나 네트워크를 바꾸거나 라우팅을 복구한 뒤 다시 테스트하고, 여러 필드를 동시에 수정하지 마세요.
8. 유용한 기록을 보관합니다. 시간, 클라이언트 버전, 코어 유형, 오류 내용 및 수행한 비교 테스트를 기록하되 인증 정보는 삭제하세요.

로그 점검의 핵심은 모든 영어 오류 문구를 외우는 것이 아니라 연결 경로의 어느 단계에서 실패했는지 확인하는 데 있습니다. 요청이 로컬 프록시에 들어왔는지, DNS가 완료되었는지, 서버에 연결되었는지, 인증을 통과했는지만 판단해도 문제 범위를 “전혀 연결되지 않음”에서 실행 가능한 점검 항목 하나로 좁힐 수 있습니다.

현재 설정을 여러 번 수동으로 수정했다면 필요한 정보만 보존하고 구독을 다시 가져온 뒤 기본 라우팅으로 한 번 연결해 보는 것이 대개 가장 빠릅니다. v2rayN, v2rayNG 및 v2flyNG에서도 같은 변수 통제 원칙을 적용하세요. 먼저 작동하는 기준선을 만든 다음 어떤 변경이 오류를 일으켰는지 찾아야 합니다.