V2Ray 로그 확인 방법: 자주 발생하는 오류와 해결 순서

먼저 로그가 어느 단계에서 나온 것인지 확인하세요

v2rayN, v2rayNG, v2flyNG는 클라이언트이고 V2Ray와 Xray는 연결을 처리하는 코어입니다. 구독 다운로드 실패는 클라이언트 업데이트 기능에서 발생할 수 있으며, 이때 코어에는 아직 요청이 전달되지 않았습니다. 반대로 로그에 proxy/vless/outbound, transport/internet 같은 모듈 경로가 표시되면 대개 코어가 요청을 처리 중인 단계입니다. 두 문제는 점검을 시작할 위치가 다릅니다.

v2rayN은 먼저 메인 창의 로그 영역을 확인한 다음 ‘설정’ → ‘매개변수 설정’에서 로그 관련 옵션을 찾아보세요. v2rayNG는 메인 화면 메뉴에서 ‘로그’를 열고, ‘설정’에서 로그 레벨을 확인하면 됩니다. 버전에 따라 메뉴 위치와 번역된 이름이 달라질 수 있습니다. 클라이언트 버전과 시작 로그에 표시된 코어 이름 및 버전을 기록하세요. ‘V2Ray 사용 중’이라고만 적어서는 부족합니다. v2rayNG는 Xray 코어를, v2flyNG는 v2fly 코어를 사용하므로 앱 이름만으로 오류 형식을 짐작할 수 없습니다.

로그 레벨과 오류 흐름 읽는 법

V2Ray/Xray에서 흔히 사용하는 loglevel 값은 debug, info, warning, error, none입니다. 문제를 찾을 때는 잠시 info를 사용하고, 정보가 부족하면 debug로 올려 보세요. error만 표시하면 경고와 일반 정보는 필터링됩니다. none으로 설정한 경우 로그가 없다는 사실만으로 연결이 정상이라고 판단할 수 없습니다.

{
  "log": {
    "loglevel": "info"
  }
}

위 내용은 핵심 설정에 포함되는 로그 부분일 뿐, 설정 파일 전체를 그대로 바꿔 넣으라는 뜻은 아닙니다. 클라이언트에서 설정을 생성한다면 화면의 옵션을 우선 수정하세요. 생성된 파일을 임시로 편집하면 노드를 바꿀 때 덮어써질 수 있습니다. 액세스 로그와 오류 로그의 출력 위치는 access, error 같은 필드와 클라이언트 실행 방식에 따라 달라집니다. 로그 레벨을 높여도 디스크에 파일이 반드시 생성되는 것은 아닙니다.

1. 먼저 시간을 확인하세요. 테스트를 누르거나 웹페이지를 새로 고친 시각을 기억해 두고, 전후 약 10초의 기록을 찾으세요. 백그라운드 앱의 요청이 섞이지 않도록 합니다.
2. 연결 정보를 비교하세요. 대괄호 안에 연결 번호가 있으면 같은 번호로 여러 줄을 연결해 보세요. 번호가 없다면 대상 주소, 포트, 시간을 함께 비교하세요.
3. 바깥쪽부터 안쪽으로 읽으세요. failed to process outbound traffic는 대개 전체 상황을 요약한 메시지입니다. 뒤에 나오는 connection refused나 lookup ...이 직접적인 원인에 더 가깝습니다.
4. 처음 발생한 이상 징후를 확인하세요. 프로세스 시작에 실패하면 이후 테스트가 모두 시간 초과될 수 있습니다. 먼저 시작 오류를 해결한 뒤 실제 요청의 실패 원인을 살펴보세요.

이 흐름은 어느 단계부터 점검할지 정하는 데 쓰이며, 모든 프로토콜이 반드시 같은 순서로 동작한다는 뜻은 아닙니다. 예를 들어 서버 주소가 이미 IP라면 주소 조회가 필요하지 않습니다. 라우팅 규칙에 따라 별도의 도메인 조회가 발생할 수도 있습니다. 현재 설정과 로그를 기준으로 판단하세요.

연결 시간 초과, 연결 거부, DNS 조회 실패

‘시간 초과’는 대기 시간이 제한을 넘었다는 뜻일 뿐, 로컬 DNS, 원격 포트, 핸드셰이크 응답 중 어디에 문제가 있는지는 알려주지 않습니다. 먼저 오류에 표시된 대상이 프록시 서버인지, 직접 연결하려는 웹사이트인지, 구독 서버인지 확인하세요. timeout이 보인다고 DNS와 라우팅 규칙을 모두 바꾸지 마세요.

Windows에서 DNS 조회와 포트를 따로 확인하기

아래 명령은 예약된 예시 도메인을 사용해 점검 방법을 보여줍니다. 실행 전에 도메인과 포트를 현재 노드의 실제 서버 주소와 포트로 바꾸세요. 브라우저에서 접속할 웹사이트나 TLS의 serverName을 입력하지 마세요. 단, 해당 값이 실제 서버 주소와 같은 경우는 예외입니다.

Resolve-DnsName server.example.com
Test-NetConnection server.example.com -Port 443

• Resolve-DnsName은 시스템의 DNS 조회 경로를 확인하는 명령이며, 코어 내장 DNS의 조회 결과와는 다를 수 있습니다. 시스템에서는 조회되지만 코어에서 실패한다면 코어 DNS 서버와 라우팅을 추가로 점검하세요.
• TcpTestSucceeded : True는 해당 TCP 연결이 성공했다는 뜻일 뿐, UUID, TLS, WebSocket 경로 또는 원격 전달이 올바르다는 의미는 아닙니다.
• TCP 테스트에 실패했다고 해서 UDP 기반 전송까지 판단할 수는 없습니다. 먼저 실제 전송 유형을 확인한 다음 적절한 진단 방법을 선택하세요.

TLS 핸드셰이크 실패와 시간 불일치

핸드셰이크 실패는 보안 협상이나 프로토콜 초기화 단계에서 연결이 중단됐다는 뜻이지만, 항상 인증서가 원인은 아닙니다. TCP 연결이 되는 것을 확인한 뒤 보안 유형, 서버 이름, 인증서, 전송 매개변수, 인증 필드 순으로 점검하세요. VLESS의 UUID 검증과 TLS 인증서 검증은 서로 다른 단계입니다. 인증서 이름을 바로잡아도 UUID가 올바르다는 보장은 없습니다.

먼저 시간을 동기화한 뒤 노드 설정을 확인하세요

1. Windows에서 ‘설정’ → ‘시간 및 언어’ → ‘날짜 및 시간’으로 이동해 자동 시간 설정을 켜고 동기화를 실행하세요. w32tm /query /status 명령으로 시간 서비스 상태를 확인할 수 있습니다. 명령이 오류를 반환해도 시간 서비스가 아직 실행되지 않은 경우일 수 있습니다.
2. Android에서 시스템 ‘설정’을 열고 ‘날짜 및 시간’을 검색한 다음 자동 설정을 켜세요. 실제 날짜와 시간을 확인해야 합니다. 표시 시간대를 바꾸는 것만으로 시스템 시계가 보정되지는 않습니다.
3. VMess를 사용할 때는 클라이언트와 서버의 시계 차이가 인증 실패로 이어질 수 있습니다. 양쪽 모두 시간을 동기화하세요. 휴대폰의 표시 시간대만 바꾸는 것으로는 해결되지 않습니다. VLESS에는 VMess와 같은 시간 기반 인증 설명을 적용할 수 없지만, TLS 연결에서 인증서를 검증하려면 정확한 시간이 필요합니다.
4. 서버 주소, 포트, UUID, 보안 유형, serverName, WebSocket의 path와 Host 또는 gRPC의 serviceName을 하나씩 대조하세요. 각 값은 서버에서 제공한 그대로 입력하고, 무작정 바꿔 가며 맞추려 하지 마세요.

포트 충돌: 코어가 정상적으로 시작되도록 먼저 해결하세요

로그에 bind, address already in use 또는 Windows의 Only one usage of each socket address가 표시되면 먼저 로컬 리스닝 주소를 확인하세요. 로컬 인바운드 생성에 실패하면 시스템 프록시가 켜져 있어도 브라우저가 연결할 진입점이 없습니다. 원격 서버 포트의 개방 여부와는 별개의 문제입니다.

로그에 127.0.0.1:10808 바인딩 실패가 표시된 경우를 예로 들어 PowerShell에서 해당 포트를 수신 대기하는 프로세스를 확인합니다. 실제 오류에 다른 포트가 표시되면 명령의 포트도 함께 바꾸세요.

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

Get-Process -Id 1234

두 번째 명령의 1234는 예시 프로세스 ID이므로 첫 번째 명령 결과의 OwningProcess 값으로 바꿔야 합니다. 결과가 나오지 않으면 로그가 UDP 리스닝을 가리키는지, 프로세스가 이미 종료됐는지, 이전 시작 기록에서 나온 오류인지도 확인하세요.

1. 수신 대기 프로세스가 중복 실행된 클라이언트라면 시스템 트레이에서 불필요한 인스턴스를 정상 종료한 뒤 하나만 실행해 확인하세요.
2. 수신 대기 프로세스가 유지해야 하는 다른 프로그램이라면 클라이언트의 매개변수 설정에서 로컬 리스닝 포트를 바꾸세요. 수동 프록시를 사용하는 앱도 새 포트에 맞춰 설정해야 합니다.
3. 수정한 뒤 코어를 다시 시작하고 정상 시작 로그가 표시되는지 확인한 다음 웹페이지를 테스트하세요. 정체를 모르는 시스템 프로세스를 강제로 종료하지 마세요.
4. 오류가 permission denied 또는 access permissions라면 시스템의 포트 예약이나 보안 정책이 원인일 수도 있습니다. 모두 중복 프로세스 탓으로 돌리지 말고, 관리자 권한으로 계속 실행해 문제를 덮으려 하지 마세요.

재현 가능한 문제 해결 기록 남기기

노드를 바꾸고, DNS를 수정하고, TUN을 켜고, 라우팅까지 조정하면 연결이 복구되어도 어떤 변경이 효과가 있었는지 알 수 없습니다. 대상 하나, 노드 하나, 접속 방식 하나를 고정하고 각 테스트 시각을 로그와 맞추는 편이 낫습니다. 아래 순서는 데스크톱과 Android에서 발생하는 유사한 문제에 모두 적용할 수 있습니다.

1. 기준 정보 기록: 클라이언트 버전, 코어 버전, 현재 네트워크, 프록시 연결 방식, 대상 주소를 적고 불필요한 백그라운드 다운로드를 중지하세요.
2. 시작 상태 확인: 연결을 다시 시작하고 설정 파싱 실패, 리스닝 실패, 리소스 누락 등 시작 단계의 오류부터 해결하세요.
3. 요청 한 번 발생시키기: 시각을 기록한 뒤 페이지 하나만 한 번 새로 고치고, 요청 전후 약 10초의 로그를 보관하세요.
4. 가장 안쪽의 오류 찾기: 로컬 리스닝, 도메인 조회, 원격 연결, TLS, 프로토콜 인증 중 어느 단계인지 구분한 뒤 해당 항목을 점검하세요.
5. 한 번에 한 항목만 변경: 예를 들어 시간만 동기화하거나 잘못된 포트만 수정하세요. 같은 대상으로 다시 테스트하고 구체적인 오류가 사라졌는지, 다음 단계로 옮겨 갔는지 비교하세요.
6. 로그 설정 원복: 점검이 끝나면 디버그 레벨을 해제하고 효과가 있었던 변경 사항을 기록하세요. 로그를 공유하기 전 UUID, 구독 토큰, 전체 구독 주소, 개인 접속 기록을 삭제하고 모듈 이름과 오류 흐름은 남기세요.

아웃바운드 태그와 규칙의 관계를 더 알아보려면 설정 항목 안내를 확인하세요. 로그에 요청이 직접 연결 아웃바운드로 전송됐다고 표시되면 라우팅 규칙을 확인해야 합니다. 직접 연결 대상의 실패를 프록시 서버 연결 실패로 혼동하지 마세요.

자주 묻는 질문: 로그만으로 단정할 수 없는 경우