V2Ray 로그 보는 법: failed to dial, rejected 등 자주 발생하는 오류의 의미와 원인 파악 방법

클라이언트에 ‘연결됨’으로 표시되어도 코어가 실행되었거나 로컬 프록시 포트가 수신 대기 중이라는 뜻일 뿐, 대상 웹사이트·노드 서버·원격 아웃바운드까지 모두 연결된 것은 아닙니다. 실제 원인 파악에 유용한 정보는 대개 로그 마지막 부분에 있습니다. 요청이 어느 인바운드로 들어왔는지, 어떤 라우팅 규칙이 적용되었는지, 어느 주소로 연결을 시도하다 실패했는지, 그리고 도메인 확인·TCP 연결·TLS 핸드셰이크·사용자 인증 중 어느 단계에서 문제가 발생했는지를 확인해야 합니다.

먼저 액세스 로그, 오류 로그, 클라이언트 출력을 구분하기

V2Ray 또는 Xray 코어가 요청을 처리할 때는 로컬 애플리케이션, 인바운드 프록시, 라우팅 매칭, 아웃바운드 프로토콜, 원격 대상 등 여러 단계를 거칩니다. 로그 유형에 따라 확인할 수 있는 내용도 다릅니다. 빨간색 한 줄만 보고 원인으로 단정하면 결과를 원인으로 착각하기 쉽습니다. 먼저 해당 로그가 어떤 유형인지 확인한 뒤, 같은 시각 전후의 문맥을 함께 읽어야 합니다.

액세스 로그에 대상 도메인이 표시되었다면 요청이 로컬 코어까지 도달했다는 뜻입니다. 이어서 failed to dial이 나타난다면 문제는 여전히 아웃바운드 연결 단계에 있습니다. 반대로 웹페이지를 눌러도 새 액세스 기록이 전혀 추가되지 않는다면 노드 설정을 바로 바꾸기보다 시스템 프록시, 브라우저 프록시 또는 앱별 규칙부터 확인해야 합니다.

v2rayN, v2rayNG, v2flyNG에서 유효한 로그 찾기

점검 전에 상황을 고정하세요. 노드 하나를 선택하고 현재 시간을 기록한 뒤, 계속 네트워크를 사용하는 다운로드 도구를 종료하고 고정된 페이지를 한 번 방문합니다. 이렇게 하면 백그라운드 요청으로 인한 잡음을 줄일 수 있습니다. 로그 수준은 먼저 warning 또는 info를 사용하세요. debug는 연결 세부 정보가 많이 기록되므로 일반 정보만으로 부족할 때 잠시 켜는 편이 좋습니다.

1. 현재 코어 확인

   v2rayN 7.x에서 ‘설정’ → ‘매개변수 설정’ → ‘Core 유형’을 열고 현재 설정이 Xray를 사용하는지 v2fly를 사용하는지 기록합니다. 지원되는 프로토콜과 오류 표현은 코어에 따라 달라질 수 있습니다.

2. 정보 패널 열기

   v2rayN 메인 창으로 돌아가 하단 정보 영역을 확인한 뒤 ‘서비스 다시 시작’을 한 번 실행합니다. 코어 실행, 설정 로드, 로컬 포트 수신 대기 기록이 표시되는지 확인하세요.

3. 요청 한 번 재현하기

   로그 창을 계속 표시한 상태에서 대상 페이지를 한 번만 방문합니다. 로컬 HTTP 포트가 10809라면 로그에 대상 도메인으로 전송되는 요청이 나타나는지 먼저 확인하세요.

4. 안드로이드 로그 확인

   v2rayNG 1.9.x 또는 v2flyNG 메인 화면에서 노드에 연결한 뒤 오른쪽 위 메뉴의 ‘로그’를 엽니다. 기존 내용을 먼저 지우고 대상 애플리케이션으로 돌아가 한 번 재현하세요.

5. 잠시 로그 수준 높이기

   warning만으로 실패 흐름이 보이지 않으면 로그 수준을 info 또는 debug로 바꾸고 코어를 다시 시작한 뒤 재현합니다. 기록이 끝나면 원래 수준으로 되돌려 로그가 계속 빠르게 쌓이지 않도록 하세요.

클라이언트 화면에 간단한 출력만 표시된다면 사용자 지정 설정에서 로그 파일을 명시할 수도 있습니다. 아래는 일반적인 구조 예시이며, 경로는 현재 계정에 쓰기 권한이 있는 디렉터리로 바꿔야 합니다. 수정 후에는 설정을 다시 로드해야 하며, 그렇지 않으면 이전 프로세스의 출력을 계속 보게 됩니다.

{
  "log": {
    "access": "D:/v2ray-logs/access.log",
    "error": "D:/v2ray-logs/error.log",
    "loglevel": "warning"
  }
}

로그 파일이 생성되지 않으면 먼저 디렉터리 존재 여부, 프로세스의 쓰기 권한, 클라이언트가 사용자 지정 log 설정을 덮어쓰는지 확인하세요. 더 많은 정보를 얻겠다고 프로토콜·DNS·라우팅·포트를 한꺼번에 바꾸지는 마세요. 변수가 동시에 바뀌면 연결이 복구되어도 실제로 어느 변경이 효과가 있었는지 판단할 수 없습니다.

오류 한 줄의 구조 이해하기: 마지막 원인부터 거슬러 올라가기

V2Ray와 Xray 오류는 여러 모듈이 단계별로 감싸는 형태로 기록되는 경우가 많습니다. 한 줄에 transport, proxy, common, internet 같은 모듈명이 연속해서 나타나고, 보다 큰 부호로 호출 흐름이 연결되기도 합니다. 읽을 때는 먼저 시간·대상 주소·가장 마지막 원인을 확인한 다음, 어느 프로토콜 또는 전송 단계에 해당하는지 앞쪽으로 거슬러 올라가세요.

2026/06/02 10:18:42 [Warning] transport/internet/websocket:
failed to dial WebSocket > transport/internet:
failed to dial to (wss://node.example:443/path):
dial tcp 203.0.113.20:443: i/o timeout

이 예시에는 이미 숫자 형식의 주소가 표시되어 있으므로 ‘이 컴퓨터가 노드 도메인을 전혀 확인하지 못한다’는 방향은 우선순위가 낮습니다. 마지막 원인은 TCP 연결 타임아웃이며, 아직 VMess 또는 VLESS 사용자 인증 단계에도 진입하지 않았습니다. 이때 UUID를 계속 바꿔도 결과가 달라지지 않는 경우가 많으므로 먼저 443 포트에 도달할 수 있는지 확인해야 합니다.

마지막 원인이 connection reset by peer라면 연결이 성립된 후 원격 장치나 중간 네트워크 장비가 강제로 초기화했다는 뜻입니다. connection refused라면 대개 대상 호스트에는 도달했지만 해당 포트에서 서비스가 수신 대기 중이 아니거나 정책상 명시적으로 거부된 것입니다. timeout, reset, refused는 서로 다른 네트워크 상태이므로 모두 ‘노드가 고장 났다’고 단정할 수 없습니다.

failed to dial, rejected, invalid user는 각각 무엇을 확인해야 할까

빈번한 오류는 가장 바깥쪽의 failed to process outbound traffic만 검색하지 말고 가장 마지막 원인을 기준으로 분류해야 합니다. 바깥쪽 문구는 대개 ‘아웃바운드 처리 실패’라는 요약일 뿐이며, 실제 점검 방향을 결정하는 것은 마지막 몇 개의 오류입니다. 아래에 자주 나오는 원문과 우선 조치를 정리했습니다.

VLESS 자체는 VMess의 시간 인증 방식을 사용하지 않습니다. 따라서 invalid user가 보이면 실제 사용 프로토콜과 해당 로그가 어느 노드에서 나온 것인지 먼저 확인하세요. 구독에는 VMess와 VLESS 등 여러 유형의 노드가 함께 포함될 수 있으며, 현재 클라이언트에서 선택한 항목이 이번 로그의 문맥입니다.

요청 흐름을 단계별로 점검하고 설정을 한꺼번에 바꾸지 않기

브라우저에서 원격 대상까지 하나의 요청은 최소 다섯 단계를 거칩니다. 자신과 가까운 단계부터 확인하고 한 번에 하나의 사실만 검증하는 것이 가장 효과적입니다. 이전 단계가 통과되지 않았다면 다음 단계의 매개변수는 일단 조정하지 마세요.

1. 시스템 프록시 확인. v2rayN을 연 뒤 시스템 프록시가 예상한 모드인지 확인하세요. 웹페이지에 접속해도 로그에 새 기록이 전혀 없다면 요청이 127.0.0.1의 로컬 프록시 포트로 들어오지 않았을 가능성이 있습니다.
2. 로컬 수신 대기 확인. 클라이언트 상태 표시줄에 표시된 값을 기준으로 확인하세요. 일반적인 설정은 SOCKS 10808, HTTP 10809를 사용하지만 사용자가 포트를 변경할 수 있으므로 안내서의 기본값만으로 판단해서는 안 됩니다.
3. 라우팅 결과 확인. 잠시 더 단순한 전역 프록시로 전환해 테스트하세요. 전역 모드에서는 작동하지만 규칙 모드에서 실패한다면 도메인 규칙·IP 규칙·block 아웃바운드·최종 매칭 순서를 중점적으로 확인합니다.
4. 노드 연결 확인. 로그에 대상 노드 주소가 표시된 뒤 DNS·TCP·TLS·WebSocket·gRPC·사용자 인증 중 어느 단계에서 실패하는지 관찰하세요.
5. 대상별 차이 확인. 여러 일반 사이트에서 모두 실패한다면 노드 또는 로컬 경로 문제일 가능성이 큽니다. 특정 도메인 하나만 실패한다면 DNS 결과·라우팅 매칭·대상 사이트 자체의 상태를 먼저 확인하세요.

로컬 포트는 curl로 최소 요청을 보내 테스트할 수 있습니다. 아래 예시는 HTTP 프록시 포트 10809와 SOCKS 포트 10808을 통해 이 사이트에 요청하는 방식입니다. 실제 클라이언트에 표시된 포트로 바꿔 사용하세요. 10초 제한을 두면 즉시 거부되는 경우와 계속 타임아웃되는 경우를 구분하는 데 도움이 됩니다.

curl --proxy http://127.0.0.1:10809 https://v2help.com -I --max-time 10
curl --proxy socks5h://127.0.0.1:10808 https://v2help.com -I --max-time 10

명령 실행 즉시 127.0.0.1에 연결할 수 없다고 나오면 로컬 수신 대기 상태나 포트 입력이 문제입니다. 로컬 포트에는 연결되지만 약 10초 후 타임아웃되면 코어 로그로 돌아가 원격 연결을 확인하세요. HTTP 응답 헤더를 받을 수 있는데도 브라우저가 열리지 않는다면 브라우저 프록시 덮어쓰기, 확장 프로그램 설정 또는 다른 프로그램이 시스템 프록시를 변경했는지를 중점적으로 살펴보세요.

로그에서 DNS·라우팅·시간 문제를 판별하는 대표적인 패턴

DNS 문제는 단순히 ‘도메인이 존재하지 않음’으로만 나타나지 않습니다. 같은 노드 도메인이 IPv4와 IPv6를 모두 반환할 수 있고, 네트워크마다 두 주소 유형에 대한 연결 가능 여부도 다릅니다. 특정 IPv6 주소를 반복해서 시도하다 타임아웃이 발생하지만 IPv4로 전환하면 복구된다면 DNS 확인은 성공했지만 현재 네트워크에서 해당 주소 체계로 가는 경로를 사용할 수 없다는 뜻입니다.

라우팅 오판은 대개 뚜렷한 ‘선택성’을 보입니다. 일부 도메인은 항상 정상인데 다른 도메인은 매번 direct 또는 block으로 들어갑니다. 이때는 오류 로그보다 액세스 로그의 아웃바운드 태그가 더 중요합니다. 규칙을 수정한 뒤에는 설정을 다시 시작하거나 다시 로드하고, 새 요청의 타임스탬프가 변경되었는지 확인하세요.

시간 문제는 주로 시간 검증이 필요한 인증 과정에 영향을 줍니다. 시계 표시뿐 아니라 날짜·시간대·자동 동기화 상태도 확인해야 합니다. 화면의 시각이 맞아 보여도 잘못된 시간대와 수동 설정이 함께 적용되면 실제 시간에 오차가 생길 수 있습니다.

로그를 정리할 때 남길 내용과 숨겨야 할 정보

문제를 다른 사람에게 설명할 때는 failed 한 줄만 보내는 것보다 전체 환경을 제공하는 편이 훨씬 유용합니다. 최소한 클라이언트 이름과 버전, 사용 중인 코어, 노드 프로토콜, 문제가 발생한 시간, 모든 노드에서 실패하는지 여부, 현재 네트워크 유형, 수행한 비교 테스트를 적어 주세요. 이렇게 하면 같은 질문을 반복하지 않아도 되고 오류가 같은 작업에서 발생했는지도 판단할 수 있습니다.

• 보관: 오류 발생 시각, 로그 수준, 모듈명, 오류 흐름, 대상 포트, 전송 유형 및 로컬 수신 대기 포트
• 보관: v2rayN 7.x, v2rayNG 1.9.x 등 클라이언트 버전 범위와 Xray 또는 v2fly 코어 유형
• 숨김: 전체 구독 주소, UUID, 비밀번호, 인증 문자열, 노드 도메인 및 개인 네트워크를 식별할 수 있는 정보
• 안내: 노드 주소는 node.example로 바꿔도 되지만 포트·프로토콜·TLS 활성화 여부·경로가 동일한지는 명확히 적어야 합니다.
• 첨부: 재현 단계와 결과. 예: ‘전역 모드에서는 성공하고 규칙 모드에서는 실패’ 또는 ‘HTTP 10809에는 연결되지만 원격 443은 타임아웃’.

로그 문제 해결의 핵심은 모든 영어 오류를 외우는 것이 아니라 실패가 어느 단계에서 발생했는지 파악하는 데 있습니다. 액세스 기록이 없으면 프록시 진입점부터 확인하고, no such host가 나타나면 DNS를 점검하세요. timeout·refused·reset이면 네트워크와 포트를 확인하고, TLS 또는 전송 핸드셰이크에 진입한 뒤에는 해당 매개변수를 검토합니다. invalid user가 나타날 때만 인증 정보와 시간 동기화로 돌아가세요.

한 가지를 수정한 뒤에는 같은 대상·같은 노드·같은 테스트 방식으로 다시 재현하고 새 로그와 이전 로그를 비교해야 합니다. 변수를 통제해야 문제가 실제로 해결된 것인지, 일시적으로 우회된 것인지, 다른 백그라운드 요청에 가려진 것인지 확인할 수 있습니다.