2026-11-03 · 문제 해결 · 약 12분

V2Ray 로그 확인 방법: 자주 나오는 오류와 원인별 해결법

로그 레벨과 형식을 알아보고 연결 시간 초과, 인증서 검증 실패, 포트 충돌, 규칙 파일 누락 등 주요 오류의 원인과 설정 확인 방법을 살펴봅니다.

이 글의 핵심 내용

“클라이언트는 실행되지만 연결되지 않는 경우”와 “코어가 시작 직후 종료되는 경우”에 적합합니다. 먼저 로그를 출력한 코어를 확인한 뒤 시간, 인바운드, 라우팅, 가장 안쪽의 오류 순서로 원인을 찾습니다. 검색 가능한 실제 오류 문구와 포트 확인 명령, 한 번에 설정 하나만 바꾸어 재검증하는 방법을 안내합니다. 인증서 문제를 DNS 문제로 잘못 진단하지 않도록 주의하세요.

1. 로그부터 확인하기: 클라이언트 메시지와 코어 오류 구분

v2rayN은 데스크톱 GUI 클라이언트이며, 실제 연결 처리는 선택한 코어가 담당합니다. 창에 표시되는 구독 업데이트, 속도 측정 작업, 시스템 프록시 설정 안내와 Xray 연결 로그는 비슷한 위치에 나타날 수 있지만 서로 다른 계층의 이벤트입니다. 문제를 확인하기 전에 현재 노드, 사용 중인 코어, 프록시 인바운드, 작업 시간을 기록하세요. Xray가 출력한 로그임을 확인한 경우에만 Xray 설정 항목을 기준으로 해석해야 합니다. 클라이언트 이름에 V2Ray가 들어간다고 해서 내부에서 반드시 같은 코어를 사용하는 것은 아닙니다.

데스크톱에서는 먼저 v2rayN 기본 창의 로그 또는 정보 영역에서 시작 로그를 확인하고, 이어서 ‘설정’ → ‘매개변수 설정’에서 로그 관련 옵션을 찾아보세요. 화면 구성에 따라 옵션 이름이 다를 수 있으므로 현재 클라이언트에 표시된 항목을 기준으로 확인해야 합니다. Android에서는 v2rayNG가 Xray 코어를, v2flyNG가 V2Fly 코어를 사용합니다. 각 앱의 로그 메뉴에서 출력을 확인하고, 다른 클라이언트의 설정 경로를 그대로 적용하지 마세요.

  1. 시작 로그부터 확인: 설정을 읽었는지, 규칙 리소스를 불러왔는지, 로컬 포트를 정상적으로 수신 대기하는지 확인하세요. 시작 단계에서 이미 실패했다면 원격 웹사이트 접속 테스트는 잠시 미뤄 두세요.
  2. 확인 범위 정리: 현재 시간을 기록하고 반복적인 속도 측정과 백그라운드 일괄 요청을 중지한 뒤, 안정적으로 재현할 수 있는 접속을 한 번만 시도하세요.
  3. 전후 로그 보관: 처음 실패한 시점 전후의 관련 로그를 복사하세요. 로그에 연결 식별자가 있다면 여러 연결의 로그를 섞지 말고 같은 식별자를 따라가세요.
  4. 원인 흐름 확인: failed to가 여러 겹으로 나타나면 가장 바깥쪽 문구만 잘라내지 말고 뒤따르는 근본 원인까지 함께 확인하세요.

2. 로그 레벨과 로그 형식: 시간과 연결 단계부터 확인

Xray 오류 로그에서 흔히 사용하는 레벨은 debug, info, warning, error이며, 설정의 none은 해당 로그 출력을 끄는 값입니다. 문제를 확인할 때는 일시적으로 info로 높이고, 정보가 부족하면 잠시 debug를 사용하세요. 확인을 마치면 원래 설정으로 되돌려 연결 세부 정보가 장시간 대량으로 기록되지 않도록 합니다. 액세스 로그와 오류 로그는 용도가 다르므로 오류 로그 레벨을 높여도 액세스 로그가 자동으로 켜지지는 않습니다.

2026/11/03 10:15:20 [Info] [123456789] proxy/socks: TCP Connect request to tcp:example.com:443

다음은 민감 정보를 가린 형식 예시이며, 이 사이트에서 실제로 측정한 결과가 아닙니다. 시간은 작업 시점을 맞추는 데 쓰이고, [Info]는 로그 레벨을 나타냅니다. 숫자는 같은 연결을 추적하는 단서가 될 수 있으며, proxy/socks는 처리 모듈, 마지막 주소는 해당 메시지와 관련된 대상을 가리킵니다. 실제 형식은 코어와 출력 설정에 따라 달라지므로 모든 로그 행에 같은 필드가 있어야 하는 것은 아닙니다.

앱 요청로컬 인바운드라우팅 매칭아웃바운드 연결핸드셰이크 및 전송

이 흐름을 따라 단계별로 증거를 확인하세요. 로컬 인바운드 로그가 있다는 것은 앱의 요청이 코어에 전달되었다는 뜻일 뿐입니다. 특정 아웃바운드가 라우팅 대상으로 선택되었다고 해서 원격 핸드셰이크까지 성공한 것은 아닙니다. 액세스 로그의 accepted는 대개 요청을 처리하도록 접수했다는 의미이지 웹페이지가 완전히 로드되었다는 뜻은 아닙니다. EOF 또는 context canceled는 브라우저가 요청을 취소해 발생할 수도 있으므로 매번 실패하는지, 어느 단계에서 발생하는지, 주변 상황은 어떤지 함께 확인하세요.

3. 연결 시간 초과와 연결 거부: timeout만 보지 마세요

오류: i/o timeout

원인과 해결: 네트워크 읽기 또는 쓰기 작업이 제한 시간 안에 완료되지 않았다는 뜻입니다. 앞부분의 주소와 모듈을 보고 도메인 확인, 연결 시도, 핸드셰이크 중 어느 단계에서 발생했는지 파악한 다음 해당 구간의 네트워크 경로를 점검하세요.

오류: connection refused

원인과 해결: 대상 서버나 중간 장비가 연결을 거부했다는 뜻입니다. 원격 포트, 서비스의 수신 대기 상태, 방화벽 규칙을 확인하세요. 대기 시간만 늘려서는 대개 해결되지 않습니다.

오류: failed to find an available destination

원인과 해결: 사용할 수 있는 대상을 선택하거나 연결하려는 시도가 실패했다는 뜻입니다. 내부 원인을 더 확인하고 도메인 확인 결과, 대상 주소, 연결 실패 정보를 각각 점검하세요. 이 문구만 보고 DNS 문제라고 단정할 수는 없습니다.

오류에 표시된 주소가 노드 서버인지 최종 접속 사이트인지 먼저 구분하세요. 프록시 아웃바운드가 서버에 연결하지 못했다면 노드 주소와 포트를 확인하고, 직접 연결 아웃바운드가 대상에 접속하지 못했다면 직접 연결 네트워크나 분할 라우팅 규칙을 점검해야 합니다. 호스트 이름에 여러 주소 레코드가 있다면 실제로 IPv4와 IPv6 중 어느 쪽을 시도했는지도 확인하세요. 도달할 수 없는 경로 하나를 모든 연결의 문제로 오해하지 않도록 주의해야 합니다.

Windows에서는 다음 명령으로 TCP 연결 가능 여부를 확인할 수 있습니다. 도메인과 포트는 문서용 예시이므로 실제로 사용할 때는 사용 권한이 있는 노드 주소와 포트로 바꾸세요. 테스트는 기기에서 허용된 네트워크 환경에서 진행해야 합니다. 결과는 TCP 계층의 연결 여부만 보여 주며 VMess, VLESS 또는 TLS 매개변수를 검증하지는 않습니다.

Test-NetConnection -ComputerName example.com -Port 443

4. 인증서 검증 실패: 시간, 이름, 인증서 체인 확인

TLS 오류는 연결이 해당 핸드셰이크 단계에 진입했음을 의미하지만, 인증서 오류의 종류에 따라 해결 방법은 다릅니다. 일반적인 TLS 인증서 검증을 사용하는 연결에서는 서버 주소와 인증서 이름 검증에 쓰이는 serverName이 달라도 되지만, 서버 설정과 일치해야 합니다. 접속 가능한 도메인이라면 무엇이든 이 항목에 입력해도 되는 것은 아닙니다. 다른 보안 모드의 매개변수를 TLS 설정에 그대로 복사하지 마세요.

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

원인과 해결: 기기 시간이 인증서 유효 기간에 맞지 않거나 서버 인증서가 만료되었을 수 있습니다. 먼저 시스템의 날짜, 시간, 시간대를 맞춘 다음 서버 관리자에게 인증서를 갱신해야 하는지 확인하세요.

오류: x509: certificate signed by unknown authority

원인과 해결: 인증서 체인을 신뢰할 수 있는 인증 기관까지 연결할 수 없다는 뜻입니다. 서버가 중간 인증서를 포함한 전체 체인을 전송하는지, 기기의 신뢰 저장소와 네트워크 검사 정책에 문제가 없는지 확인하세요.

오류: certificate is valid for

원인과 해결: 인증서 이름이 일치하지 않을 때 자주 나타나는 문구입니다. 로그에 표시된 이름과 실제 검증에 사용된 이름을 비교하고, 노드 편집 화면에서 TLS 호스트 이름 또는 SNI 설정을 확인하세요.

시스템 날짜가 정확하고 설정도 바뀌지 않았는데 알 수 없는 발급 기관 오류가 갑자기 나타난다면, 현재 네트워크에서 HTTPS 검사 기능을 사용 중인지 또는 서버 인증서 체인이 최근 변경되었는지 확인하세요. 조직의 네트워크 정책에 따라 인증서 신뢰를 관리하고, 오류를 없애려고 출처를 모르는 루트 인증서를 함부로 가져오지 마세요.

5. 포트 충돌: 로컬 인바운드가 정상적으로 수신 대기하도록 설정

address already in use가 나타나면 먼저 로컬 수신 대기 포트 충돌을 해결해야 합니다. 클라이언트가 중복 실행되었거나 이전 코어 프로세스가 종료되지 않았거나 다른 프로그램이 같은 주소와 포트를 사용 중일 수 있습니다. Windows에서는 비슷한 문제가 Only one usage of each socket address로 표시되기도 합니다. 이 경우 원격 노드를 바꿔도 로컬 포트 충돌은 해결되지 않습니다.

10808
로컬 프록시 인바운드 예시 포트
443
자주 사용하는 TLS 서버 포트
53
기존 DNS에서 자주 사용하는 포트

이 숫자는 포트가 어느 계층에 속하는지 구분하기 위한 예시이지, 설정을 일괄 변경하라는 뜻이 아닙니다. 로컬 프록시 포트는 클라이언트 설정에 따라 달라지고, 노드 포트는 서버 배포 방식에 따라 달라집니다. DNS도 기존 포트 대신 암호화된 전송을 사용할 수 있습니다. 로그에 실제로 표시된 수신 대기 주소와 포트를 기준으로 확인하세요. 127.0.0.1에 바인딩하는 경우와 모든 네트워크 인터페이스에서 접근 가능하도록 바인딩하는 경우의 범위는 다릅니다. 문제를 해결하려고 수신 범위를 무작정 넓히지 마세요.

# Windows PowerShell: 예시 포트를 수신 대기 중인 프로세스 확인
Get-NetTCPConnection -LocalPort 10808 -State Listen |
  Select-Object LocalAddress, LocalPort, OwningProcess

# Linux: TCP 수신 대기 항목과 프로세스 정보 확인
ss -ltnp 'sport = :10808'

# macOS: 예시 포트의 TCP 수신 대기 상태 확인
lsof -nP -iTCP:10808 -sTCP:LISTEN

결론: 프로세스를 확인한 뒤 종료할지 포트를 바꿀지 결정

점유 프로세스가 중복 실행된 인스턴스인지 확인한 다음 정상적으로 종료하세요. 다른 서비스가 해당 포트를 계속 사용해야 한다면 클라이언트의 로컬 인바운드 포트를 바꾸고 앱의 프록시 설정도 함께 업데이트해야 합니다. 클라이언트 포트만 바꾸고 앱이 가리키는 주소를 그대로 두면 새로운 “연결 거부” 오류가 발생합니다.

6. 규칙 파일과 DNS: 시작 실패와 이름 확인 실패 구분

로그에 failed to load geosite, failed to load geoip가 포함되어 있거나 geosite.dat, geoip.dat를 가리키는 파일 오류가 있다면 노드를 계속 바꾸기보다 규칙 리소스를 먼저 확인하세요. geosite: 또는 geoip:를 참조하는 규칙은 해당 데이터가 필요합니다. 파일 누락, 읽기 권한 부족, 호환되지 않는 데이터 형식, 존재하지 않는 분류 참조로 인해 설정을 불러오지 못할 수 있습니다.

  1. 실패한 경로 확인: 로그에 표시된 실제 경로에서 파일을 찾으세요. 클라이언트와 설치 방식에 따라 데이터 디렉터리가 다르므로 리소스가 실행 파일 옆에 있다고 단정하지 마세요.
  2. 리소스 출처 확인: 클라이언트에 내장된 규칙 리소스 업데이트 기능을 우선 사용하고, 다운로드 결과가 오류 페이지가 아닌지 확인하세요. 되돌릴 수 없도록 원본 파일을 덮어쓰지 말고 보관하세요.
  3. 분류 이름 확인: 파일이 있다고 해서 모든 분류가 포함되어 있는 것은 아닙니다. 라우팅 규칙에서 참조하는 분류가 현재 리소스에 실제로 있는지 확인하세요.
  4. 재시작 후 시작 로그 확인: 리소스 로드가 성공하고 코어가 수신 대기를 시작한 뒤에 접속 테스트를 진행하세요. 생성된 설정을 직접 편집하면 다음 시작 때 클라이언트가 변경 사항을 덮어쓸 수 있습니다.

오류: no such host

원인과 해결: 현재 DNS 확인 경로에서 사용할 수 있는 호스트 정보를 얻지 못했다는 뜻입니다. 도메인 철자, DNS 서버 선택, 규칙을 확인하고 지금 확인 중인 도메인이 노드인지 접속 대상 웹사이트인지 구분하세요.

오류: no such file or directory

원인과 해결: 프로그램이 접근하려는 경로가 존재하지 않습니다. 앞부분에 표시된 파일 이름을 보고 규칙 리소스, 인증서, 로그 디렉터리 중 무엇인지 확인한 뒤 경로를 수정하세요. 이 문구만 보고 모든 구성 요소를 다시 설치하지 마세요.

시스템 DNS와 코어 내장 DNS는 서로 다른 경로를 사용할 수 있습니다. 시스템 명령으로 도메인을 확인할 수 있더라도 코어가 선택한 DNS 아웃바운드가 작동한다는 뜻은 아닙니다. 반대로 브라우저가 자체적으로 사용하는 DNS 확인 방식은 코어의 DNS를 거치지 않을 수도 있습니다. 우선 시스템 DNS 명령으로 노드 도메인을 확인하고, 코어 로그에서 DNS 서버, 요청 도메인, 실패 단계를 살펴보세요. 특히 노드 주소 확인에 아직 연결되지 않은 프록시 경로가 필요해 시작 단계에서 의존성 순환이 발생하지 않는지 주의하세요.

7. 재검증과 도움 요청: 한 번에 변수 하나만 바꾸고 관련 로그를 함께 제공

문제 해결의 목표는 로그에서 경고를 완전히 없애는 것이 아니라 장애 원인을 안정적으로 설명하는 것입니다. 매번 설정 하나만 바꾸세요. 예를 들어 TLS 이름을 바로잡은 뒤 코어를 재시작하고 같은 요청을 다시 실행합니다. 노드, DNS, 라우팅 모드, 전송 방식을 한꺼번에 바꾸면 연결이 복구되어도 무엇이 효과가 있었는지 알기 어렵습니다.

계속 도움을 받아야 한다면 운영체제와 플랫폼, 클라이언트 및 코어의 실제 버전, 실패 시각, 재현 단계, 같은 연결에서 실패 전후로 나온 로그를 제공하세요. 버전은 현재 클라이언트나 코어의 시작 로그에서 확인하고 설치 파일 이름으로 추측하지 마세요. 제출 전에 구독 주소, 인증 식별자, 비밀번호, 개인 키 및 기타 민감한 매개변수를 가리세요. 오류 유형, 포트, 발생 단계, 일관된 방식으로 가린 주소 간 관계는 알아볼 수 있도록 남겨야 합니다.

v2rayN 다운로드플랫폼에 맞는 클라이언트 선택