· 문제 해결 · 약 10분

V2Ray 로그 확인 방법: access·error 로그와 주요 오류 메시지

loglevel별 용도와 연결 시간 초과, 핸드셰이크 실패, DNS 조회 실패 등 주요 로그를 설명하고, 로그로 문제 발생 지점을 찾는 방법을 안내합니다.

핵심 내용

로그를 살펴볼 때는 먼저 실행 중인 코어를 확인한 뒤, 접속 기록과 진단 정보를 구분하세요. v2rayN에서 웹페이지가 열리지 않거나 v2rayNG 연결이 시간 초과되고 v2flyNG에서 이름 조회가 실패하는 경우, 재현 가능한 요청 하나를 기준으로 로컬 인바운드, 라우팅·아웃바운드, DNS, TCP, TLS 순서로 확인하면 됩니다. error 한 줄만 보고 구독 설정 전체를 반복해서 바꾸지 마세요.

1. access 로그와 error 로그에는 무엇이 기록될까

v2rayN은 클라이언트 인터페이스이고, V2Ray와 Xray는 연결을 처리하는 코어입니다. 로그 형식은 실제로 실행된 코어와 버전에 따라 달라집니다. v2rayNG는 Xray 코어를, v2flyNG는 v2fly 코어를 사용합니다. 문제를 확인하기 전에 시작 로그에서 코어 이름과 버전을 기록하세요. 클라이언트 이름만 적어서는 부족합니다.

로그 유형주요 내용이 로그만으로 판단할 수 없는 것
access연결의 출발지와 대상 주소, 일부 형식에서는 인바운드·아웃바운드 태그를 기록합니다.accepted가 표시되어도 대상 웹페이지가 정상적으로 응답했다는 뜻은 아닙니다.
error코어 시작, 연결 수립, 이름 조회 및 데이터 전송 과정의 진단 정보입니다.파일 이름에 error가 들어가도 모든 행이 오류 수준이라는 의미는 아닙니다.
클라이언트 실행 로그코어 표준 출력, 클라이언트 이벤트, 구독 요청 정보가 함께 표시될 수 있습니다.구독 업데이트 실패가 프록시 아웃바운드 연결 실패를 뜻하는 것은 아닙니다.

예를 들어 access 로그에 accepted tcp:example.com:443가 표시되면, 일반적으로 로컬 인바운드가 해당 요청을 받았다는 뜻입니다. 이후에도 노드 연결 시간 초과, TLS 인증 실패, 원격 측 연결 종료가 발생할 수 있습니다. 로그에 [인바운드 태그 -> 아웃바운드 태그]가 있으면 라우팅 분기를 확인할 수 있습니다. 태그 이름은 현재 설정에 따라 달라집니다.

2. loglevel 선택: 평소에는 warning, 재현할 때만 debug

V2Ray와 Xray에서 흔히 사용하는 로그 수준은 debug, info, warning, error, none입니다. debug에서 error로 갈수록 출력 범위가 좁아집니다. none은 진단 로그 출력을 끌 때 사용합니다. access 로그는 별도로 출력 설정을 관리하므로 loglevel만 보고 access 로그 활성화 여부를 판단할 수 없습니다.

v2rayN에서 ‘설정’ → ‘매개변수 설정’으로 이동해 현재 버전의 로그 수준 옵션을 찾고, 저장한 뒤 코어를 다시 시작하세요. 메뉴 구성과 이름은 버전에 따라 달라질 수 있으니 현재 화면을 기준으로 확인해야 합니다. v2rayNG나 v2flyNG에서도 설정에서 로그 옵션을 찾은 다음 로그 화면을 여세요. 구독 목록을 코어 실행 로그와 혼동하지 마세요.

아래는 코어 설정의 log 필드 예시이며, 그대로 실행할 수 있는 전체 설정 파일은 아닙니다. 필드 간 관계를 설명하기 위한 예시입니다. 클라이언트가 관리하는 설정은 인터페이스에서 수정하는 것이 좋습니다. 생성된 파일을 직접 수정하면 다음 실행 때 변경 내용이 덮어써질 수 있습니다.

{
  "log": {
    "access": "C:/Temp/v2ray-logs/access.log",
    "error": "C:/Temp/v2ray-logs/error.log",
    "loglevel": "debug"
  }
}

Windows 절대 경로를 사용하는 예시입니다. 먼저 C:\Temp\v2ray-logs 폴더를 만들고, 코어를 실행하는 계정에 쓰기 권한이 있는지 확인하세요. 파일 출력을 켜면 일부 내용이 기존 콘솔 창에 표시되지 않을 수 있으므로 지정한 파일도 확인해야 합니다. 재현이 끝나면 로그가 계속 쌓이지 않도록 warning으로 되돌리세요.

3. 연결 시간 초과와 연결 거부: 실패한 주소부터 확인

아래 카드에는 로그에서 흔히 볼 수 있는 오류 일부를 적었습니다. 모든 로그에 그대로 나타나는 고정된 형식은 아닙니다. 모듈 접두사, 패키지 경로, 오류 포장 단계는 코어 버전에 따라 달라집니다. 가장 안쪽의 원인을 먼저 찾은 다음, 해당 주소가 노드 서버인지 DNS 서버인지 대상 웹사이트인지 확인하세요.

오류: dial tcp …: i/o timeout

원인: 로그에 표시된 주소로 TCP 연결을 시도했지만 제한 시간 안에 연결되지 않았습니다.

해결 방법: 실패한 주소가 노드 엔드포인트인지 먼저 확인하세요. 노드 주소라면 포트, 현재 네트워크, 서버 인바운드 설정을 점검합니다. 대상 웹사이트 주소라면 원격 출구에서 대상까지 연결되는지 확인하세요.

오류: connect: connection refused

원인: 연결이 명시적으로 거부되었습니다. 대상 포트에서 서비스가 대기 중이지 않거나 네트워크 장비가 연결을 차단한 경우가 흔합니다.

해결 방법: 오류에 나온 IP와 포트를 확인하세요. 127.0.0.1:10808이라면 원격 노드를 바꾸기 전에 로컬 코어가 실행 중인지, 수신 포트가 일치하는지 확인합니다.

오류: context deadline exceeded

원인: 작업이 제한 시간을 초과했습니다. 이 메시지만으로는 DNS, 연결 시도, 핸드셰이크 중 어느 단계에서 지연됐는지 알 수 없습니다.

해결 방법: 오류 전후 로그를 남기고, 같은 연결의 모듈 이름과 더 안쪽에 기록된 오류를 찾아 구체적인 단계를 확인하세요.

Windows에서는 연결 거부가 위와 같은 영문 문구 대신 connectex가 포함된 시스템 오류로 표시될 수 있습니다. 확인 방법은 같습니다. 시간 초과는 제한 시간 내에 연결되지 않았다는 뜻이고, 거부는 연결이 명시적으로 거절됐다는 뜻입니다. 어느 쪽도 VMess 또는 VLESS 설정에 반드시 문제가 있다는 근거는 아닙니다.

10808
이 문서에서 테스트에 사용하는 로컬 프록시 포트입니다. 실제 수신 포트와 일치해야 합니다.
443
HTTPS에서 흔히 쓰는 포트이며, 모든 노드가 이 포트를 사용하는 것은 아닙니다.
53
일반 DNS에서 흔히 쓰는 포트입니다. 암호화 DNS는 별도로 확인하세요.

판단 기준: ‘시간 초과’라는 문구보다 오류에 나온 주소가 더 중요합니다

오류 주소를 로컬 수신 포트, 노드 엔드포인트, 대상 서비스 중 하나로 구분한 다음 해당 구간만 점검하세요. 노드가 다른 포트를 사용한다면 구독 설정을 기준으로 확인하고, 모두 443으로 바꾸지 마세요.

4. TLS 핸드셰이크 실패: 인증서, 도메인, 시스템 시간을 각각 확인

TLS 핸드셰이크는 하위 연결이 수립된 뒤 진행되지만, 실패 원인이 인증서에만 있는 것은 아닙니다. TCP 연결이 됐다고 노드를 완전히 사용할 수 있는 것은 아닙니다. SNI, 전송 경로, 서버 설정 불일치도 확인해야 합니다. VLESS 노드라고 해서 모두 같은 보안 계층을 사용하는 것은 아니므로 실제 설정이 TLS, REALITY 또는 다른 조합 중 무엇인지 먼저 확인하세요.

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

원인: 인증서 유효 기간과 현재 시스템 시간이 맞지 않습니다. PC의 시간이 잘못됐거나 서버 인증서가 만료됐을 수 있습니다.

해결 방법: 먼저 시스템 날짜, 시간대, 시간 동기화를 확인하세요. 시간이 정상이라면 서비스 제공자에게 인증서 갱신과 전체 인증서 체인을 점검해 달라고 요청하세요.

오류: x509: certificate signed by unknown authority

원인: 현재 환경에서 신뢰할 수 있는 인증서 체인을 구성하지 못했습니다. 중간 인증서 누락, 로컬 신뢰 저장소 문제, 네트워크에서 발생한 인증서 교체 등이 원인일 수 있습니다.

해결 방법: 서버 인증서 체인과 PC의 인증서 신뢰 환경을 확인하세요. 인증서 검증을 끄는 방법은 일반적인 해결책으로 사용하지 마세요.

오류: tls: handshake failure

원인: TLS 협상이 거부됐습니다. 이 로그 일부만으로는 구체적인 설정 오류를 알 수 없습니다.

해결 방법: 서비스 제공자가 안내한 서버 이름, TLS 설정, 전송 방식을 확인한 뒤 같은 시간대의 서버 로그와 대조하세요.

5. DNS 조회 실패: 노드 도메인과 대상 도메인을 구분

‘DNS 문제’라는 말만으로는 원인을 좁힐 수 없습니다. 클라이언트는 먼저 노드 서버 도메인을 조회해야 할 수 있습니다. 프록시 연결이 수립된 뒤에는 대상 웹사이트 도메인을 로컬이나 원격에서 조회할 수 있습니다. 라우팅의 domainStrategy는 IP 규칙에 맞추기 위해 이름 조회를 실행할 수도 있습니다. 이는 아웃바운드의 도메인 조회 정책과는 다릅니다.

로그 메시지메시지만으로 판단할 수 있는 범위다음 확인 단계
lookup …: no such host이번 조회에서 사용할 수 있는 이름 결과를 얻지 못했습니다. 존재하지 않는 도메인이나 부정 응답이 원인일 수 있습니다.오류에 표시된 도메인 철자가 맞는지, 노드 주소인지 웹사이트 주소인지 확인한 뒤 실제로 사용 중인 DNS 리졸버를 점검하세요.
failed to lookup ip상위 단계에서 IP 조회 실패를 보고한 상태입니다. 구체적인 원인은 보통 뒤따르는 로그나 안쪽 오류에 있습니다.시간 초과, 결과 없음, 리졸버 연결 오류를 추가로 찾으세요. 이 요약 메시지만 보고 멈추지 마세요.
read udp …: i/o timeout해당 주소가 DNS 서버라면 DNS 응답이 제때 도착하지 않았을 수 있습니다.리졸버까지의 네트워크 경로, UDP 연결 가능 여부, 관련 라우팅을 확인하세요.

Windows에서는 다음 명령으로 시스템의 이름 조회 결과를 확인할 수 있습니다. 여기의 example.com은 명령 예시일 뿐입니다. 실제로 문제를 확인할 때는 로그에 나온 도메인으로 바꾸세요. 시스템 명령이 성공해도 시스템 리졸버만 정상이라는 뜻입니다. 코어 내장 DNS, 암호화 DNS, 프록시를 통한 조회 경로까지 정상이라는 의미는 아닙니다.

Resolve-DnsName example.com

6. 요청 하나로 로그 따라가기: 로컬 수신 → 라우팅 → 원격 연결

재현하기 전에 백그라운드 연결을 많이 만드는 앱을 잠시 끄고, 노드 하나와 프록시 연결 방식 하나만 사용하세요. 아래 예시는 Windows에서 HTTP 또는 혼합 인바운드 127.0.0.1:10808를 사용하는 경우입니다. 현재 포트가 SOCKS만 지원한다면 해당 SOCKS 테스트 명령을 사용하세요. 프로토콜 불일치를 노드 장애로 오해하지 마세요.

  1. 수신 포트 확인: PowerShell에서 로컬 포트가 대기 중인지 확인하세요. 수신 중인 포트가 없다면 원격 인증서를 점검하기 전에 코어 실행 상태나 포트 설정부터 해결합니다.
  2. 상세 로그를 잠시 활성화: 시작 시간을 기록하고 테스트 요청을 한 번만 보낸 다음, 해당 시간대의 access 및 error 로그를 확인하세요.
  3. 인바운드 확인: 접속 기록이 없다면 access 로그가 활성화되어 있고 올바른 위치에서 확인 중인지 점검하세요. 앱이 실제로 프록시를 사용하는지도 확인해야 합니다.
  4. 라우팅 확인: 로그에 아웃바운드 태그가 있으면 요청이 의도한 프록시 아웃바운드로 전달됐는지 확인하세요. 직접 연결, 차단, 프록시 아웃바운드를 각각 구분해 판단해야 합니다.
  5. 가장 안쪽의 오류까지 추적: DNS, TCP, TLS, 프로토콜 인증, 대상 서비스 순서로 확인하세요. 관련 설정은 한 번에 하나씩만 바꾸고 같은 요청을 다시 테스트합니다.
Get-NetTCPConnection -LocalPort 10808 -State Listen
curl.exe --proxy http://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.com/

이 curl 명령은 프록시를 명시적으로 지정하므로 브라우저나 시스템 프록시 설정에 의존하지 않습니다. 10초는 연결 단계 제한 시간이고 20초는 명령 전체의 제한 시간입니다. 둘 다 이번 테스트에만 사용하는 값이지 코어 성능 지표가 아닙니다. HTTP 프록시 출력에서 터널 연결에 성공해도 이후 TLS 핸드셰이크와 웹페이지 응답까지 성공했다는 뜻은 아니므로 전체 결과를 확인하세요.

curl.exe --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.com/

두 번째 명령은 SOCKS를 지원하는 인바운드에서만 사용하세요. socks5h는 대상 도메인 조회를 SOCKS 프록시에 맡기지만, 일반적인 socks5는 curl이 로컬에서 대상 도메인을 조회합니다. 두 방식을 비교할 때는 조회 위치가 달라진다는 점을 고려해야 하며, 결과 차이를 모두 노드 속도 탓으로 돌릴 수는 없습니다.

판단 기준: 프록시를 지정하면 연결되지만 브라우저에서는 안 될 때는 트래픽이 들어오는 경로부터 확인하세요

같은 노드와 대상에서 프록시를 명시한 요청은 성공했는데 브라우저 요청에 해당하는 access 로그가 없다면 시스템 프록시, 브라우저 확장 프로그램, 우회 목록을 먼저 확인하세요. 이 경우 VMess 또는 VLESS 설정을 계속 바꾸는 것은 문제의 원인과 거리가 멀 수 있습니다.

7. 로그 문제 해결 FAQ와 문의 시 필요한 정보

웹페이지는 열리는데 warning 로그가 계속 쌓이는 이유는 무엇인가요?

먼저 시간과 대상 정보를 기준으로 warning이 어느 요청에서 발생했는지 확인하세요. 백그라운드 앱, 취소된 연결, 연결할 수 없는 부가 리소스에서도 로그가 남을 수 있습니다. 경고 한 건만으로 모든 트래픽이 실패했다고 볼 수는 없습니다. 대상을 하나 정해 재현하고 해당 요청이 실제로 실패했는지 확인하세요.

debug를 켰는데도 로그 창이 비어 있으면 어떻게 하나요?

설정을 저장한 뒤 코어를 다시 시작했는지 먼저 확인하세요. 다음으로 파일 출력이 설정되어 있는지 점검합니다. 로그가 파일에 기록된다면 절대 경로와 폴더 권한을 확인하세요. 현재 보고 있는 화면이 구독 업데이트 기록이 아니라 코어 출력인지도 확인해야 합니다.

accepted가 표시되면 노드 연결에 성공한 건가요?

아닙니다. 일반적으로 요청이 인바운드에서 수락됐다는 뜻일 뿐입니다. 같은 연결의 아웃바운드 연결 시도와 핸드셰이크 로그를 따라가고, curl의 최종 응답으로 대상에 접속했는지 확인하세요. accepted 한 줄만 잘라서 결론 내리지 마세요.

구독 업데이트가 시간 초과되면 노드 연결 시간 초과와 같은 방식으로 해결해야 하나요?

먼저 구독 주소 요청과 프록시 데이터 연결을 구분하세요. 구독 업데이트가 프록시를 사용하는지, 현재 프록시가 정상인지, 구독 서버에 연결할 수 있는지 확인해야 합니다. 문의 내용을 공유할 때는 구독 주소의 토큰을 숨기고 전체 구독 링크를 공개하지 마세요.

추가 지원이 필요하다면 화면 전체를 캡처하는 것보다 같은 실패를 추적할 수 있는 최소한의 정보를 제공하는 편이 효과적입니다. 로그에는 접속 도메인, 서버 주소, 로컬 경로가 포함될 수 있습니다. 공유하기 전에 내용을 확인하고 오류 유형과 연결 관계는 유지하되 계정 식별 정보, UUID, 비밀번호, 개인 키, 구독 토큰은 삭제하세요.

v2rayN 다운로드플랫폼 및 설치 파일 선택