2026-09-04 · 문제 해결 · 약 10분

v2rayN 로그 보는 법: 자주 나오는 오류와 원인 파악

connection refused, i/o timeout, TLS 핸드셰이크 실패 등 v2rayN 로그의 주요 오류 메시지를 단계별로 분류해 원인을 찾는 방법을 안내합니다.

핵심 내용

‘노드를 선택했는데 웹페이지가 열리지 않거나’ ‘코어가 시작 직후 종료되는’ 경우에 유용한 안내입니다. 먼저 클라이언트 로그와 코어 로그를 구분한 뒤, 로컬 리스닝, 노드 연결, TLS 핸드셰이크, 대상 사이트 접속 순서로 오류를 확인합니다. 주요 키워드, Windows 포트 확인 명령어, 한 번에 재현하는 절차를 통해 설정 전체를 반복해서 바꾸지 않고 문제 발생 지점을 좁힐 수 있습니다.

먼저 로그가 어느 단계에서 발생했는지 확인하기

v2rayN은 클라이언트 인터페이스이며, 실제 연결 처리는 선택한 코어가 담당합니다. 구독 다운로드 실패, 인터페이스 오류, 코어 시작 실패는 클라이언트 메시지에 나타날 수 있습니다. 노드 연결, DNS 조회, 아웃바운드 핸드셰이크는 주로 코어 로그에 기록됩니다. 서로 다른 단계에서 발생하므로 ‘구독 업데이트 성공’을 ‘프록시 연결 성공’으로 볼 수 없습니다. 속도 측정 실패 메시지 하나만으로 모든 앱의 인터넷 연결이 끊겼다고 판단해서도 안 됩니다.

이 글은 v2rayN에서 Xray 코어를 사용하는 경우를 중심으로 설명합니다. 먼저 메인 화면의 메시지 또는 로그 영역에서 현재 코어 이름을 확인한 다음, ‘설정’ → ‘매개변수 설정’에서 로그 관련 항목을 살펴보세요. 데스크톱 인터페이스와 버전에 따라 메뉴 이름이나 구성이 다를 수 있으므로 현재 화면의 ‘로그 수준’ 항목을 기준으로 확인해야 합니다. 아래의 Xray 필드를 구독 주소 입력란에 붙여 넣지 마세요.

앱 요청 로컬 리스닝 라우팅에서 아웃바운드 선택 노드 핸드셰이크 대상 사이트 접속

로그를 읽을 때는 이 흐름을 따라가며 확인하세요. 앱이 요청을 로컬 포트로 보내는지, 라우팅이 예상한 아웃바운드를 선택하는지, 코어가 노드에 연결되는지, 노드와 프로토콜 핸드셰이크를 완료하는지 살펴봅니다. 앞 단계가 정상임을 확인해야 다음 단계의 오류를 정확히 파악할 수 있습니다. TUN을 사용하는 경우 가상 네트워크 어댑터와 권한도 확인해야 하지만, 이후의 노드 연결 및 핸드셰이크 확인 방법은 동일합니다.

로그 수준과 한 번에 재현하기: 확인하기 쉬운 로그 확보

Xray에서 자주 사용하는 loglevel 값은 debug, info, warning, error, none입니다. 로그가 상세할수록 연결 상황을 파악하기 쉽지만, 접속 대상이 기록될 가능성도 커집니다. 평소에는 비교적 낮은 수준으로 유지하고, 문제를 확인할 때만 info로 임시 변경하세요. 그래도 정보가 부족하면 짧은 시간 동안 debug를 사용합니다.

수준 또는 기록확인할 수 있는 내용이 내용만으로 단정할 수 없는 것
debug파싱, 연결 시도, 핸드셰이크 세부 정보정보가 많다고 오류가 더 많은 것은 아닙니다
info연결 과정 및 일반 실행 이벤트오류가 없다고 웹페이지가 완전히 로드된 것은 아닙니다
warning확인이 필요한 비정상 연결경고 한 건만으로 코어 전체가 중단된 것은 아닙니다
error심각한 오류 및 일부 시작 문제모든 요청 실패가 기록되는 것은 아닙니다
접속 기록요청 대상, 인바운드 및 아웃바운드 태그accepted가 원격 핸드셰이크 성공을 보장하지는 않습니다

접속 로그와 오류 로그는 서로 다른 개념이며, 로그 출력 여부는 설정에 따라 달라집니다. ‘accepted’를 확인하려고 모든 기록을 무작정 켜지 마세요. 아래처럼 요청 한 건을 재현해 확인하는 편이 수백 줄의 뒤섞인 로그를 살펴보는 것보다 효과적입니다.

  1. 환경 정보 기록

    ‘도움말’ → ‘정보’에서 확인할 수 있는 클라이언트 버전을 기록하고, 시작 메시지에서 코어 버전을 확인하세요. 현재 화면에 해당 메뉴가 없다면 창에 실제로 표시된 버전 정보를 기록합니다.

  2. 로그 수준 변경

    ‘설정’ → ‘매개변수 설정’으로 이동해 로그 수준을 찾아 임시로 info로 변경합니다. 저장한 뒤 현재 코어를 다시 시작하고 새 설정이 적용됐는지 확인하세요.

  3. 변수 줄이기

    노드 하나, 브라우저 하나, 대상 페이지 하나만 정하고 일괄 속도 측정과 구독 업데이트는 잠시 중지합니다. 시작 오류는 남겨 두고 기존 화면 로그를 정리하되, 대조에 필요한 로그 파일은 삭제하지 마세요.

  4. 한 번 재현하기

    요청 시간을 기록한 뒤 페이지를 한 번만 새로고침하고, 해당 시간 전후의 오류 흐름을 빠짐없이 수집합니다. 로그에 연결 ID가 있으면 같은 ID를 기준으로 묶어 확인하세요. 인접한 줄이라는 이유만으로 하나의 오류로 연결하지 마세요.

  5. 설정 원래대로 복원

    문제 위치를 파악한 뒤 로그 수준을 원래 값으로 되돌립니다. 로그를 공유하기 전에는 구독 주소, 인증 정보, 노드 주소, 접속 도메인을 가리고 필요한 오류 키워드와 포트 역할만 남기세요.

connection refused와 포트 사용 중 오류: 어느 쪽에서 거부했는지 확인하기

connection refused는 연결을 시도했을 때 거부 응답을 받았다는 뜻입니다. 해당 포트에서 서비스를 수신 대기 중인 프로세스가 없거나 네트워크 장비가 연결을 능동적으로 거부할 때 자주 발생합니다. 시간 초과와는 다른 오류입니다. 핵심은 오류 메시지의 대상 주소를 확인하는 것입니다. 127.0.0.1은 로컬 컴퓨터, 노드 주소는 노드 연결, 원격 대상 주소는 직접 연결 아웃바운드의 실패일 수 있습니다.

오류: dial tcp 127.0.0.1:10808: connect: connection refused

원인: 호출한 프로그램이 로컬 10808 포트에 접속했지만 사용할 수 있는 리스너가 없습니다. 코어 종료, 포트 변경, 잘못된 프록시 주소 등이 원인일 수 있습니다.

해결: 먼저 코어 시작 메시지를 확인하고, ‘설정’ → ‘매개변수 설정’에서 로컬 리스닝 포트를 확인하세요. 앱에 입력한 주소, 포트, 프록시 유형이 일치하는지도 점검합니다.

오류: bind: address already in use

원인: 코어가 수신 대기하려는 주소와 포트를 다른 프로세스가 이미 사용 중입니다. Windows에서는 ‘각 소켓 주소는 일반적으로 한 번만 사용할 수 있습니다’라는 메시지가 표시될 수도 있습니다.

해결: 해당 포트를 사용하는 프로세스를 확인하고, 중복 실행된 클라이언트를 종료하거나 로컬 포트를 변경한 뒤 앱의 프록시 설정도 함께 업데이트하세요. 출처가 불분명한 시스템 프로세스는 종료하지 마세요.

아래 숫자는 포트 역할을 설명하기 위한 예시이며 모든 버전의 기본값은 아닙니다. 10808은 로컬 리스닝 포트, 443은 노드 포트의 예시입니다. 실제로 확인할 때는 현재 설정에 지정된 값을 사용하세요.

10808
로컬 프록시 리스닝 포트 예시
443
원격 노드 서비스 포트 예시

Windows PowerShell에서 먼저 리스닝 포트를 확인한 다음, 결과에 표시된 PID로 프로세스를 찾을 수 있습니다. 첫 번째 명령에서 리스닝 기록이 나오지 않는다면 노드의 TLS 설정을 바꾸기 전에 코어가 제대로 시작됐는지 확인하세요.

Get-NetTCPConnection -LocalPort 10808 -State Listen |
  Select-Object LocalAddress, LocalPort, OwningProcess

Get-NetTCPConnection -LocalPort 10808 -State Listen |
  ForEach-Object { Get-Process -Id $_.OwningProcess }

이 명령은 로컬 포트를 조회할 뿐 노드가 정상인지 확인하지는 않습니다. 리스닝 주소가 127.0.0.1이면 로컬에서만 접속할 수 있다는 뜻입니다. 문제 해결을 위해 별다른 검토 없이 LAN에 공개되는 주소로 바꾸지 마세요.

i/o timeout: 연결 시도 시간 초과와 읽기 시간 초과 구분하기

i/o timeout은 어떤 작업이 제한 시간 안에 끝나지 않았다는 뜻입니다. 앞에 표시된 dial tcp, read tcp 또는 DNS 관련 내용을 함께 확인해야 합니다. 연결 시도 시간 초과는 연결이 아직 성립되지 않았다는 뜻이고, 읽기 시간 초과는 데이터를 기다리는 동안 응답을 제때 받지 못했다는 뜻입니다. 두 경우는 확인해야 할 대상이 다릅니다.

오류: dial tcp 192.0.2.10:443: i/o timeout

원인: 노드 포트에 연결하는 과정이 제한 시간 안에 끝나지 않았습니다. 주소 오류, 서비스 연결 불가, 경로상 패킷 손실, 방화벽의 패킷 차단 등이 원인일 수 있습니다. 이 주소는 문서용 예시이므로 실제 연결 테스트에 사용하지 마세요.

해결: 구독에 등록된 노드 주소와 포트를 확인한 뒤, 다른 네트워크 또는 정상 작동이 확인된 노드와 비교해 보세요. 한 번 시간 초과가 발생했다고 전송 설정 전체를 바로 변경하지 마세요.

오류: read tcp …: i/o timeout

원인: 연결의 어느 한 구간에서 데이터를 기다리다 시간 초과가 발생했습니다. 핸드셰이크, 원격 응답 또는 유휴 연결과 관련된 문제일 수 있으며, 노드 포트에 연결할 수 없다는 뜻은 아닙니다.

해결: 같은 연결의 앞부분에 기록된 핸드셰이크 내용을 확인해 노드 핸드셰이크 전과 대상 사이트 접속 후 중 어느 단계에서 발생했는지 구분합니다. 이후 노드 설정과 대상 사이트를 각각 확인하세요.

TCP 포트 테스트 성공은 해당 시점에 TCP 연결이 성립했다는 것만 보여 줍니다. VMess, VLESS 또는 TLS 핸드셰이크가 정상이라는 뜻은 아닙니다. 반대로 ICMP 응답이 없다고 해서 프록시 서비스를 사용할 수 없다고 단정할 수도 없습니다.

TLS 핸드셰이크 실패: 인증서, 이름, 전송 설정을 나눠 확인하기

노드 포트에 연결되더라도 TLS 단계에서 실패할 수 있습니다. 먼저 오류가 ‘클라이언트에서 노드로’ 연결할 때 발생했는지, ‘브라우저에서 대상 웹사이트로’ 접속할 때 발생했는지 확인하세요. 브라우저에 표시된 인증서 페이지를 Xray 노드 핸드셰이크 로그로 간주해서는 안 됩니다. 동일한 연결에서 발생한 코어 오류 흐름을 기준으로 판단하세요.

오류: x509: certificate has expired or is not yet valid

원인: 인증서 유효 기간과 현재 시스템 시간이 맞지 않습니다. 노드 인증서가 만료됐거나 로컬 날짜 또는 시간대 설정이 잘못됐을 수 있습니다.

해결: Windows에서 ‘설정’ → ‘시간 및 언어’ → ‘날짜 및 시간’으로 이동해 시간을 확인하고 동기화를 실행하세요. 시간이 정확하다면 노드 관리자에게 인증서 상태를 확인해 달라고 요청합니다.

오류: x509: certificate signed by unknown authority

원인: 현재 환경에서 신뢰하는 루트 인증서로 인증서 체인을 검증할 수 없습니다. 서버 인증서 체인 누락, 자체 서명 인증서 또는 네트워크의 TLS 검사 등이 원인일 수 있습니다.

해결: 먼저 노드 출처, 인증서 설정, 시스템의 신뢰 환경을 확인하세요. 인증서 검증을 끄는 방법을 일반적인 해결책으로 사용하지 마세요.

오류: remote error: tls: handshake failure

원인: 원격 서버가 TLS 핸드셰이크를 중단했습니다. SNI, TLS 설정, 서버 정책이 서로 맞지 않으면 발생할 수 있지만, 이 메시지만으로 정확한 원인을 특정할 수는 없습니다.

해결: 노드 제공자가 안내한 서버 이름과 전송 설정을 대조하세요. 구독을 업데이트한 뒤 다시 연결하고, 서버 로그에서 거부 원인을 확인합니다.

노드 편집 창에서 serverName에 해당하는 서버 이름, TLS 활성화 여부, 선택한 전송 방식을 확인하세요. WebSocket의 Host, 경로, TLS의 SNI는 서로 다른 계층의 설정입니다. 도메인 하나가 보인다고 모든 항목을 같은 값으로 바꾸면 안 됩니다. gRPC 서비스 이름도 서버 설정과 일치해야 합니다.

DNS, EOF, 라우팅 태그: 오류 상황을 함께 확인하기

DNS 오류는 먼저 ‘노드 도메인 조회 실패’와 ‘접속 대상 도메인 조회 실패’를 구분해야 합니다. 전자는 프록시 연결 자체가 성립하지 않을 수 있고, 후자는 일부 웹사이트에만 영향을 줄 수 있습니다. 도메인 규칙, IP 규칙, DNS 아웃바운드에 따라 조회가 이뤄지는 위치도 달라질 수 있습니다. DNS 오류가 보인다고 Windows 네트워크 어댑터 설정만 바꾸지 마세요.

오류: no such host

원인: 도메인 조회 결과로 사용할 수 있는 호스트를 찾지 못했습니다. 철자 오류, 도메인 만료 또는 DNS 서버가 반환한 부정 응답 등이 원인일 수 있습니다.

해결: 오류가 발생한 도메인이 노드인지 접속 대상인지 먼저 확인한 뒤, 철자, DNS 서버, DNS 조회 아웃바운드를 점검하세요. 모든 도메인을 IP 주소로 영구 교체하지 마세요.

오류: unexpected EOF

원인: 프로그램이 더 많은 데이터를 받을 것으로 예상하는 중 상대편에서 연결을 종료했습니다. 프로토콜 불일치, 포워딩 설정 오류, 원격 서버의 연결 중단 등이 원인일 수 있습니다.

해결: TLS, 프록시 프로토콜, 대상 응답 중 어느 단계에서 연결이 끊겼는지 확인하고 전송 방식과 서버 설정을 대조하세요. 이 메시지만으로 인증 정보가 잘못됐다고 단정할 수는 없습니다.

아래는 단순화한 접속 기록 예시이며 실제 속도 측정 결과가 아닙니다. http는 인바운드 태그, proxy는 아웃바운드 태그이며 이름은 설정에 따라 달라집니다. 기록의 accepted는 요청을 접수해 처리했다는 뜻입니다. 노드 인증이 완료됐거나 대상 웹페이지가 응답했다는 뜻은 아닙니다.

from 127.0.0.1:52134 accepted tcp:example.com:443 [http -> proxy]

자주 묻는 질문과 문제 해결 정보 공유 방법

warning 로그가 계속 쌓이는데 노드가 고장 난 건가요?

먼저 일괄 속도 측정을 중지하고 실제 접속을 한 번만 재현하세요. 페이지가 정상적으로 열리고 경고가 취소된 백그라운드 요청과 관련된 것이라면 경고 수만으로 노드를 바꿀 필요는 없습니다. 같은 요청이 계속 실패한다면 오류 흐름 전체를 보관한 뒤 판단하세요.

구독은 업데이트되는데 프록시에 연결되지 않는 이유가 뭔가요?

구독 업데이트는 설정 데이터를 가져오는 작업일 뿐입니다. 메인 화면에서 해당 그룹의 노드가 선택됐는지 확인하고 코어가 정상적으로 시작됐는지 살펴보세요. 이어서 로컬 리스닝과 노드 핸드셰이크 로그를 확인해야 합니다. 어느 것도 구독 업데이트 성공만으로 보장되지는 않습니다.

웹페이지가 열리지 않는데 로그에 오류가 전혀 없으면 어떻게 하나요?

먼저 로그 수준과 로그 표시 영역이 올바른지 확인하세요. 브라우저에서 요청을 한 번 보내고 시스템 프록시가 가리키는 포트를 점검합니다. TUN을 사용 중이라면 네트워크 어댑터 및 권한 관련 메시지를 확인하세요. 요청이 코어에 들어오지 않았다면 해당 아웃바운드 오류도 기록되지 않습니다.

로그 파일 전체를 다른 사람에게 보내야 하나요?

일반적으로 시작 정보, 재현 시간 전후의 간단한 로그, 클라이언트와 코어 버전, TUN 사용 여부를 먼저 공유하면 됩니다. 인증 정보, 전체 구독 링크, 개인적으로 접속한 대상을 가리세요. 스크린샷에 표시된 노드 이름과 주소도 확인해야 합니다.

다른 사람이 확인할 수 있는 문제 설명에는 운영체제, 클라이언트와 코어 버전, 문제가 특정 노드에만 발생하는지 전체 노드에 발생하는지, 정확한 오류 발생 시간, 이미 진행한 단일 변수 테스트가 포함돼야 합니다. 예를 들어 ‘로컬 10808 포트는 리스닝 중이고, 네트워크를 바꿔도 같은 노드에서 TLS 단계 오류가 발생함’이라고 설명하면 ‘프로그램이 작동하지 않음’보다 다음 확인 단계를 찾기 쉽습니다.

v2rayN 다운로드