2026-07-15 · 문제 해결 · 약 10분

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

v2rayN과 v2rayNG 실행 로그를 쉽게 이해하고 access·error 로그의 차이, rejected·timeout·context canceled 오류의 의미와 로그를 활용한 원인 좁히기 방법을 알아봅니다.

이 글 한눈에 보기

이 글은 구독을 이미 가져왔지만 노드 timeout, 웹페이지 접속 불가 또는 연결 불안정을 겪는 사용자를 위한 안내입니다. 먼저 클라이언트 로그와 코어 로그를 구분한 뒤 요청 시간, 대상 주소, 아웃바운드 태그와 최종 오류를 순서대로 확인하면 문제가 시스템 프록시, 로컬 포트, DNS, 노드 매개변수 또는 원격 서버 중 어디에 가까운지 판단할 수 있습니다.

먼저 클라이언트 로그와 access·error를 구분하기

문제 해결을 시작하기 전에 현재 확인 중인 로그가 어느 계층에 속하는지 파악해야 합니다. v2rayN과 v2rayNG는 구독, 노드, 시스템 프록시와 코어 프로세스를 관리하는 클라이언트이고, Xray 또는 v2fly 코어는 실제 연결을 수신하고 라우팅을 수행한 뒤 아웃바운드 연결을 만듭니다. 클라이언트 화면에 “시작 성공”이 표시되어도 코어 프로세스가 실행됐다는 뜻일 뿐, 특정 노드의 연결까지 보장하는 것은 아닙니다.

access 로그에는 요청이 어떤 인바운드를 거쳤는지, 어떤 대상에 접속했는지, 마지막으로 어떤 아웃바운드가 선택됐는지가 기록됩니다. “요청이 코어에 들어왔는가”, “도메인이 어떤 규칙으로 처리됐는가”를 확인할 때 유용합니다. access 기록이 보인다는 것은 대개 브라우저나 앱이 트래픽을 로컬 프록시 포트로 보냈다는 의미입니다.

error 로그는 장애 원인에 더 가깝습니다. 도메인 확인 실패, 연결 timeout, 포트 사용 중, 프로토콜 핸드셰이크 실패, 원격 측의 연결 종료 등이 대표적입니다. 로그 레벨은 보통 debug, info, warning, error로 나뉩니다. 평소에는 info를 사용하고, 재현이 어려운 문제를 확인할 때만 일시적으로 debug로 바꾸는 것이 좋습니다. debug는 짧은 시간에도 많은 기록을 빠르게 생성하기 때문입니다.

로그 출처 주요 내용 우선 확인할 항목
클라이언트 로그 설정 생성, 코어 시작, 구독 업데이트, 시스템 프록시 전환 코어 파일, 설정 형식, 프로세스 상태와 구독 주소
access 로그 요청 대상, 인바운드 태그, 라우팅 결과와 아웃바운드 태그 앱이 프록시로 들어왔는지, 분할 라우팅 규칙이 예상대로 적용됐는지
error 로그 연결, 주소 확인, 핸드셰이크, 전송과 리스닝 실패 로컬 포트, DNS, 노드 매개변수, 네트워크와 원격 상태

v2rayN과 v2rayNG에서 유효한 로그 얻기

로그는 명확한 한 번의 작업과 연결되어 있을 때 의미가 있습니다. 시작하기 전에 연속 속도 측정, 자동 구독 업데이트와 백그라운드 다운로드를 중지해 수십 개의 동시 요청이 섞이지 않게 하세요. 그런 다음 노드 하나를 선택하고 로그 창을 연 뒤 문제를 한 번만 재현합니다. 예를 들어 접속 가능한 HTTPS 페이지 하나만 열거나 실제 연결 테스트를 한 번만 실행합니다.

v2rayN 7.x를 예로 들면 먼저 메인 화면에서 현재 활성 서버를 확인한 다음 「설정」→「매개변수 설정」→「Core 유형」으로 이동해 선택한 코어가 현재 설정과 일치하는지 확인합니다. 이후 메인 화면의 로그 영역으로 돌아가 시작 정보를 살펴보세요. 기록 수준을 높이려면 매개변수 설정에서 로그 레벨을 찾아 info를 일시적으로 debug로 바꾸고 저장한 뒤 코어를 다시 시작합니다.

  1. 활성 노드 확인

    v2rayN의 메인 목록에서 현재 활성 서버를 확인하고 주소, 포트와 프로토콜을 기록합니다. 원격 포트는 443, 8443 또는 서비스 제공업체가 지정한 다른 포트를 사용하는 경우가 많으며, 로컬 리스닝 포트로 대신할 수 없습니다.

  2. 코어 다시 시작

    설정을 저장한 뒤 「서비스 다시 시작」을 한 번 실행합니다. 먼저 로그에 설정 로드와 로컬 리스닝 성공이 표시되는지 확인한 다음 웹페이지에 접속하세요. 그래야 이전 프로세스가 남긴 기록을 이번 결과로 잘못 판단하지 않습니다.

  3. 한 번만 재현

    웹페이지 하나를 열거나 연결 테스트를 한 번 실행한 뒤 10~15초 동안 기다리고 작업을 멈춥니다. 동시에 노드 20개를 테스트하면 여러 timeout이 발생해 어느 기록이 현재 노드에 해당하는지 확인하기 어렵습니다.

  4. 앞뒤 맥락 함께 복사

    첫 번째 대상 요청부터 그 뒤의 10~20줄까지 함께 저장하세요. 마지막 한 줄만 잘라내지 마세요. 마지막의 context canceled는 앞선 연결 실패 뒤 정리 과정에서 발생한 결과인 경우가 많습니다.

v2rayNG에서는 사이드 메뉴에서 「로그」로 들어가 실행 기록을 확인할 수 있습니다. v2rayNG가 Xray 코어를 사용할 때는 Android 측 시작 정보와 코어 출력이 함께 기록됩니다. 문제를 확인할 때는 현재 노드 이름, 대상 도메인, 아웃바운드 태그와 실패 시각을 중점적으로 찾으면 되며 첫 줄부터 한 줄씩 읽을 필요는 없습니다.

기본 로컬 SOCKS 포트는 10808, HTTP 포트는 10809를 사용하는 경우가 많지만 실제 값은 클라이언트의 현재 설정을 기준으로 해야 합니다. 다른 앱에 127.0.0.1:10809을 직접 입력했는데 클라이언트 포트가 이미 10811로 바뀌었다면 앱 요청은 현재 코어에 전혀 들어오지 않습니다. 이때 error 로그에도 해당 기록이 없을 수 있습니다.

2026/07/15 14:32:10 [Info] transport/internet/tcp: listening TCP on 127.0.0.1:10808
2026/07/15 14:32:12 from 127.0.0.1:53142 accepted tcp:example.com:443 [socks -> proxy]
2026/07/15 14:32:22 [Warning] app/proxyman/outbound: failed to process outbound traffic
2026/07/15 14:32:22 [Warning] common/retry: all retry attempts failed

이 기록은 로컬 10808이 이미 리스닝을 시작했고, 임시 포트 53142에서 들어온 요청이 SOCKS 인바운드에 도달한 뒤 proxy라는 아웃바운드로 전달됐음을 보여 줍니다. 문제는 아웃바운드 연결을 만든 이후에 발생했으므로 브라우저 프록시 설정을 계속 바꾸기보다 노드 주소, 원격 포트, 네트워크 연결 가능 여부와 프로토콜 매개변수를 확인해야 합니다.

요청 하나의 흐름을 따라 로그 읽기

프록시 요청 하나는 보통 앱, 로컬 인바운드, 라우팅 판단, 프록시 아웃바운드와 원격 대상 단계를 거칩니다. 여러 연결이 동시에 처리되므로 로그 순서가 반드시 한 줄씩 정확히 대응하지는 않지만, 같은 시간대의 대상 도메인, 연결 식별자와 아웃바운드 태그를 함께 보면 흐름을 복원할 수 있습니다.

앱이 요청 시작로컬 포트가 수신라우팅 규칙 일치노드 연결 수립대상이 데이터 반환

첫 단계는 accepted가 있는지 확인하는 것입니다. 웹페이지를 새로 고친 뒤 새 access 기록이 전혀 없다면 시스템 프록시가 꺼져 있거나, 앱이 시스템 프록시를 사용하지 않거나, 앱에 잘못된 포트가 입력됐을 가능성이 큽니다. v2rayN에서는 “코어 시작”과 “시스템 프록시 설정”도 구분해야 합니다. 전자는 로컬 포트가 리스닝을 시작하게 할 뿐이고, 후자까지 설정해야 시스템 프록시를 지원하는 앱의 트래픽이 해당 포트로 향합니다.

두 번째는 대상이 올바른지 확인하는 것입니다. 로그에는 tcp:example.com:443처럼 표시될 수도 있고 주소 확인 후 IP로 표시될 수도 있습니다. 443 포트는 보통 HTTPS, 80 포트는 보통 HTTP에 사용됩니다. 웹페이지에 접속했는데 로그에 로컬 네트워크 주소만 보이거나 전혀 관계없는 도메인만 나온다면 다른 백그라운드 앱을 먼저 종료한 뒤 단독으로 다시 재현하세요.

세 번째는 대괄호 안의 라우팅 결과를 확인하는 것입니다. 예를 들어 [socks -> proxy]는 요청이 socks 인바운드로 들어와 proxy 아웃바운드로 전달됐다는 뜻이고, [socks -> direct]는 규칙에 따라 직접 연결됐다는 뜻입니다. 프록시로 보내야 할 대상이 direct로 들어갔다면 VMess나 VLESS 노드 매개변수보다 현재 라우팅 모드, 도메인 규칙과 규칙 순서를 먼저 확인해야 합니다.

자주 발생하는 오류의 의미와 처리 순서

error 로그에는 여러 단계의 래퍼 정보가 함께 포함되는 경우가 많습니다. 바깥쪽에는 failed to process outbound traffic만 표시되고, 실제 원인은 뒤쪽의 caused by, dial, lookup 또는 handshake 주변에 있는 경우가 많습니다. 첫 줄만 검색하기보다 가장 구체적인 원인부터 앞쪽으로 거슬러 올라가며 읽는 편이 효과적입니다.

오류: context canceled

원인과 해결:현재 요청이 상위 계층에서 취소됐다는 뜻입니다. 노드 전환, 코어 다시 시작, 페이지 닫기 또는 이전 연결 실패 후 정리 과정에서 흔히 발생합니다. 같은 시각 기준으로 앞의 5~20줄을 먼저 확인하세요. 방금 다시 시작한 뒤 연결이 정상이라면 이 기록은 별도로 처리하지 않아도 됩니다.

오류: i/o timeout

원인과 해결:정해진 시간 안에 연결 또는 읽기·쓰기가 완료되지 않았다는 뜻입니다. 먼저 일반 네트워크가 정상인지 확인하고 노드 주소와 원격 포트를 점검한 다음 같은 구독의 다른 노드로 테스트하세요. 여러 노드가 동시에 timeout이면 로컬 네트워크, 시스템 시간과 DNS를 우선 확인해야 합니다.

오류: connection refused

원인과 해결:대상 호스트가 해당 포트의 연결을 명확히 거부했다는 뜻입니다. 원격 서비스가 리스닝하지 않거나 포트가 잘못 입력됐을 수 있고, 로컬 앱이 실행되지 않은 10808 또는 10809에 연결했을 수도 있습니다. 로그의 대상 IP를 바탕으로 거부가 로컬에서 발생했는지 원격에서 발생했는지 판단하세요.

오류: failed to find an available destination

원인과 해결:코어가 사용할 수 있는 대상을 찾지 못했다는 뜻으로, 노드 도메인 확인 실패나 대상 설정 이상과 관련된 경우가 많습니다. 서버 주소에 공백이나 불필요한 문자가 없는지 확인하고, 안정적인 DNS로 바꾼 뒤 코어를 다시 시작하세요. 이후 더 구체적인 lookup 오류가 나타나는지 살펴봅니다.

오류: rejected

원인과 해결:요청이 라우팅 규칙, 프로토콜 검사 또는 대상 정책에 의해 거부됐다는 뜻입니다. 같은 줄 주변의 아웃바운드 태그와 원인을 먼저 확인하세요. block 아웃바운드로 들어갔다면 라우팅 규칙을 조정하고, invalid request나 인증 정보 관련 내용이 함께 표시되면 유효한 구독에서 노드 매개변수를 다시 가져오세요.

오류: EOF

원인과 해결:연결 상대가 예상한 데이터가 모두 도착하기 전에 연결을 닫았다는 뜻입니다. 한 번 발생한 경우에는 웹페이지가 요청을 취소한 결과일 수 있지만, 같은 노드에서 연결할 때마다 즉시 발생한다면 VMess 또는 VLESS의 전송 방식, TLS, 보안 설정, Host, 경로와 SNI를 확인하세요.

rejected를 항상 노드 고장으로 해석해서는 안 됩니다. 예를 들어 라우팅 설정이 광고 도메인을 block 아웃바운드로 보냈다면 거부는 예상된 동작입니다. 문제가 맞는지 판단하려면 대상 도메인과 아웃바운드 태그를 함께 확인해야 합니다. 규칙으로 차단된 특정 요청만 rejected이고 주요 페이지가 정상적으로 로드됐다면 노드를 바꿀 필요가 없습니다.

context canceled도 원인이 아니라 결과인 경우가 많습니다. 속도 측정이 끝나기 전에 노드를 바꾸면 기존 연결이 취소되고, 클라이언트가 코어를 다시 시작할 때 진행 중인 DNS 조회와 아웃바운드 연결도 종료됩니다. 수동 조작이 전혀 없는데 매번 요청이 취소될 때만 프로세스 반복 재시작, 자동 설정 새로 고침 또는 네트워크 전환을 추가로 확인하세요.

로그를 바탕으로 DNS·포트·매개변수·원격 상태 좁히기

오류를 발견했다고 여러 설정을 동시에 바꾸지 마세요. 한 번에 하나의 가설만 검증해야 어떤 조치가 실제로 효과가 있었는지 알 수 있습니다. 먼저 로컬 연결을 확인하고, 다음으로 도메인 확인을 점검한 뒤 여러 노드를 비교하고, 마지막에 프로토콜 매개변수를 하나씩 확인하는 순서가 좋습니다. 모든 설정을 삭제하고 다시 가져오면 일시적으로 해결될 수 있지만 원인 추적 단서를 잃게 됩니다.

로그에 lookup, no such host 또는 대상 주소를 얻지 못했다는 내용이 나타나면 DNS를 우선 확인하세요. 먼저 노드 서버 주소를 잘못 복사하지 않았는지 확인하고 도메인 노드와 IP 노드의 결과를 비교합니다. 도메인 노드만 실패하고 IP 노드는 작동할 때 DNS 문제라는 단서가 더 분명합니다. 모든 노드가 실패한다면 로컬 네트워크와 코어 시작 상태도 확인해야 합니다.

관찰 결과 가능성이 높은 범위 다음 확인 단계
10808 리스닝 실패 로컬 포트 사용 중 기존 프로세스를 종료하거나 사용 중이지 않은 포트로 변경한 뒤 다시 시작하고 listening 기록을 확인
새 access 기록 없음 시스템 프록시 또는 앱 프록시 설정 앱에 입력한 127.0.0.1과 실제 HTTP·SOCKS 포트를 대조
여러 도메인 노드에서 lookup 실패 DNS 또는 현재 네트워크 안정적인 네트워크로 전환하고 다시 주소를 확인하되, 노드 프로토콜 매개변수는 동시에 바꾸지 않기
노드 하나만 계속 timeout 노드 포트 또는 원격 서비스 같은 구독의 다른 노드와 비교해 단일 노드 문제인지 확인
모든 노드에서 즉시 핸드셰이크 실패 시스템 시간 또는 매개변수 불일치 시스템 시간을 동기화한 뒤 구독을 다시 업데이트하고 전송 매개변수를 대조
proxy 성공 후 특정 도메인만 direct로 연결 라우팅 분할 도메인 규칙, 규칙 우선순위와 현재 프록시 모드를 확인

포트 문제는 로컬 포트와 원격 포트를 구분해야 합니다. 로컬 10808과 10809는 앱이 클라이언트에 연결할 때 사용하고, 노드의 443과 8443 등은 코어가 서버에 연결할 때 사용합니다. 로그에 127.0.0.1:10808을 리스닝할 수 없다고 표시되면 로컬 포트 사용 문제를 해결해야 합니다. 반대로 특정 서버 주소의 443 연결이 timeout이라고 표시되면 로컬 SOCKS 포트를 바꿔도 보통 효과가 없습니다.

프로토콜 매개변수 문제는 대개 TCP 연결은 성립했지만 핸드셰이크가 곧바로 실패하는 형태로 나타납니다. VMess는 올바른 사용자 식별자, 전송 방식과 보안 설정이 필요하고, VLESS는 올바른 사용자 식별자와 전송 계층 매개변수, 서버와 일치하는 TLS 또는 기타 보안 설정이 필요합니다. WebSocket을 사용할 때는 경로와 Host를, TLS를 사용할 때는 SNI를 확인해야 합니다. 가장 안전한 방법은 유효한 구독을 다시 업데이트하는 것이며, 추측으로 매개변수를 직접 입력하지 않는 편이 좋습니다.

오해하기 쉬운 로그 문제

로그에 warning이 나타났다고 해서 모든 연결이 실패한 것은 아닙니다. 브라우저가 페이지 하나를 열 때 이미지, 스크립트, 통계 주소와 백그라운드 API를 동시에 요청하며, 그중 중요하지 않은 요청 하나가 timeout이어도 메인 페이지는 정상적으로 표시될 수 있습니다. 영향 범위를 판단할 때는 대상 도메인, 실패 횟수와 실제 페이지 표시 상태를 함께 확인하세요.

로그에 timeout이 계속 쌓이는데 구독이 만료된 걸까요?

먼저 일괄 속도 측정을 중지하고 노드 하나만 선택해 페이지 하나에 접속하세요. 해당 노드가 실패하면 같은 구독의 두 번째 노드로 테스트합니다. 같은 네트워크에서 여러 노드가 모두 timeout일 때만 구독 유효성, 로컬 네트워크, 시스템 시간과 DNS를 추가로 확인하세요.

context canceled가 나타나면 노드를 바꿔야 할까요?

발생 직전에 노드 전환, 서비스 다시 시작 또는 테스트 페이지 종료가 있었는지 먼저 확인하세요. 이런 작업이 있었다면 대부분 연결 정리 과정에서 남은 기록입니다. 수동 조작이 없었다면 앞쪽에서 처음 나타난 timeout, EOF 또는 프로세스 종료 기록을 찾아보세요.

코어는 시작 성공인데 웹페이지가 열리지 않는 이유는?

페이지를 새로 고칠 때 access 기록이 생성되는지 확인하세요. 기록이 없다면 시스템 프록시와 실제 리스닝 포트인 10808, 10809 등을 대조하고, 기록이 있다면 요청이 direct, proxy 또는 block 아웃바운드 중 어디로 들어갔는지 계속 확인합니다.

웹사이트 하나만 열리지 않을 때는 어떻게 확인하나요?

현재 로그를 지운 뒤 해당 웹사이트만 방문하고 대상 도메인과 아웃바운드 태그를 기록하세요. direct로 전달됐다면 해당 도메인 규칙을 일시적으로 조정해 확인하고, proxy로 들어간 뒤 실패했다면 DNS 결과와 대상 사이트 연결 기록을 점검합니다.

v2rayN은 되는데 v2rayNG에서 timeout이 발생하면 어떻게 하나요?

곧바로 노드 문제라고 단정하지 마세요. 먼저 양쪽이 같은 최신 구독과 같은 노드를 사용하는지 확인한 다음 네트워크 환경, 시스템 시간, Xray 코어 버전, 전송 매개변수와 DNS 설정을 비교합니다. 서로 다른 네트워크에서 얻은 결과는 직접 대체해 판단할 수 없습니다.

또 다른 흔한 오해는 지연 시간 테스트만 확인하는 것입니다. 지연 시간은 한 번의 탐색에 걸린 시간을 보여 줄 뿐 실제 프록시 경로 전체를 검증하지는 못합니다. 특정 노드가 180ms로 표시돼도 프로토콜 핸드셰이크, TLS 매개변수와 웹 전송이 반드시 정상이라는 뜻은 아닙니다. 반대로 특정 테스트 방식에서 timeout이 발생해도 실제 연결을 사용할 수 없다는 의미는 아닐 수 있습니다. 최종 판단은 실제 접속 결과와 해당 로그를 기준으로 해야 합니다.

문제 해결이 끝나면 debug 로그 레벨을 info로 되돌리고 간단한 결론을 남기세요. 예를 들어 “로컬 10808 정상 리스닝, access가 proxy로 진입, 두 노드 모두 원격 443 연결 후 약 10초 뒤 timeout”과 같이 기록합니다. 이런 메모가 “클라이언트가 작동하지 않음”보다 다음에 비슷한 문제가 생겼을 때 빠르게 비교하기 쉽습니다.

v2rayN 다운로드