v2rayN이나 v2rayNG를 사용하다 노드 연결 시간 초과, 웹페이지 접속 실패, 연결 끊김을 겪는 사용자를 위한 안내입니다. 클라이언트 메시지와 Xray 코어 로그를 구분한 뒤, 로컬 리스너, DNS, 아웃바운드 연결, 보안 핸드셰이크, 프로토콜 인증 순서로 원인을 좁혀 보세요. 오류 문구를 외우기보다 같은 요청에서 가장 근본적인 실패 원인을 찾아, 재현 가능한 테스트로 변경 사항을 검증하는 것이 중요합니다.
로그 출처를 확인한 뒤 요청이 어느 단계에서 멈췄는지 살펴보기
v2rayN은 그래픽 클라이언트이고 Xray는 실제 프록시 트래픽을 처리하는 코어입니다. 구독 다운로드 실패, UI 실행 오류, 프록시 아웃바운드 연결 실패는 서로 다른 로그에 기록될 수 있습니다. '서비스가 시작되었습니다'라는 메시지는 시작 절차가 어느 단계까지 진행됐다는 뜻일 뿐, 노드 인증 성공이나 대상 웹페이지 접속을 보장하지 않습니다.
먼저 시작 로그에서 코어 이름과 버전을 확인하고 현재 노드가 실제로 사용하는 코어를 파악하세요. v2rayNG는 Xray를, v2flyNG는 V2Fly를 사용하므로 두 코어의 지원 필드를 동일하게 볼 수 없습니다. 특히 VLESS나 REALITY 문제는 설치된 클라이언트 버전만 확인하지 말고 현재 실행 중인 코어를 기준으로 살펴보세요.
이 흐름은 로그를 읽는 순서이지, 모든 전송이 반드시 여섯 단계로 나뉜다는 뜻은 아닙니다. 일부 프로토콜은 인증과 핸드셰이크를 함께 처리하고, 대상 도메인도 서버 측에서 확인할 수 있습니다. 원인을 찾을 때는 오류에 나온 주소가 로컬 리스너 주소인지, 노드 주소인지, 최종 대상 주소인지 확인하세요. 같은 443 포트라도 위치에 따라 점검 방향이 달라집니다.
로그 활성화: 재현 가능한 요청 한 번으로 기록 남기기
일상적인 사용에는 warning이면 대체로 충분합니다. 연결 과정을 확인할 때는 먼저 info를 사용하고, 정보가 부족하면 잠시 debug로 바꾸세요. Xray의 loglevel 값은 debug, info, warning, error, none입니다. 이는 오류 로그의 레벨을 제어하며, 액세스 로그 기록 여부는 access 설정에도 달려 있습니다. 로그 레벨을 높여도 연결 문제가 자동으로 해결되지는 않습니다.
-
코어 확인
v2rayN 메인 화면의 실행 정보에서 시작 로그를 확인하고 실제로 호출된 코어 이름과 버전을 기록하세요. 코어 시작 기록조차 없다면 원격 노드가 아니라 먼저 코어 실행 실패부터 해결해야 합니다.
-
로그 레벨 변경
v2rayN에서는 '설정' → '매개변수 설정'으로 이동해 '로그 레벨'을 찾아 info로 변경하세요. v2rayNG에서는 사이드 메뉴의 '설정' → '로그 레벨'에서 바꿀 수 있습니다. 버전에 따라 메뉴 분류나 번역이 다를 수 있으니 항목을 찾지 못하면 클라이언트 버전을 먼저 확인하세요. 다른 코어의 설정을 그대로 적용하지 마세요.
-
재시작 후 오류 재현
설정을 저장한 뒤 프록시 서비스를 재시작하고 새 설정이 적용됐는지 확인하세요. 자동으로 새로고침되는 웹페이지는 닫고, 고정된 테스트 주소 하나만 여세요. 작업한 시각을 기록하고 그 전후 약 10초간의 로그를 보관하세요.
-
로그 레벨 원복
원인을 찾으면 로그 레벨을 warning으로 되돌리세요. 로그를 공유하기 전에 계정 식별 정보, 구독 주소, 노드 주소, 접속 도메인을 가리세요. 시간 순서와 프로토콜 이름, 포트, 오류의 연결 구조는 남겨야 합니다.
사용자 지정 Xray 설정을 사용하는 경우 아래 로그 설정 항목을 확인할 수 있습니다. 이는 설정 파일의 필드 하나일 뿐, 그대로 실행할 수 있는 전체 설정이 아닙니다. 클라이언트가 설정을 생성하는 방식이라면 클라이언트 설정에서 변경하세요. 임시 파일을 직접 편집하면 다음 실행 때 덮어써질 수 있습니다.
{
"log": {
"loglevel": "info"
}
}failed to dial: 오류 연결을 따라 실제 실패 지점 찾기
failed to dial은 연결을 시도하거나 수립하는 과정에서 실패했다는 뜻으로, 대개 상위 단계에서 붙인 포괄적인 오류입니다. 뒤따르는 lookup, connection refused, i/o timeout이 실제 원인에 더 가까운 단서입니다. dial이라는 단어만 보고 UUID를 다시 입력하지 말고, 먼저 오류 전체를 읽은 뒤 DNS, 포트, 라우팅 중 무엇을 점검할지 결정하세요.
failed to dial
원인: 연결 과정에서 발생한 실패를 포괄적으로 나타내며, 주소 확인, TCP 연결 또는 전송 계층 설정과 관련될 수 있습니다.
해결 방법: 뒤에 이어지는 중첩 오류를 확인하고 대상 주소와 아웃바운드 태그를 점검하세요. 해당 문구만 잘라 왔다면 같은 로그 줄의 나머지 부분도 확인해야 합니다.
lookup ...: no such host
원인: 주소 확인에 사용할 수 있는 결과를 얻지 못했습니다. 도메인 오타, 상위 DNS 응답 또는 DNS 라우팅 문제일 수 있으며, 이 오류만으로 DNS 오염이 입증되는 것은 아닙니다.
해결 방법: 확인 대상이 노드 도메인인지 대상 도메인인지 먼저 살펴보세요. 그런 다음 해당 DNS 상위 서버에 연결할 수 있는지, 노드 도메인의 초기 주소 확인 경로가 올바른지 점검하세요.
connect: connection refused
원인: 연결이 명시적으로 거부됐습니다. 해당 포트에서 서비스가 대기 중이지 않거나 주소·포트가 잘못된 경우가 흔하며, 중간 장비가 거부 응답을 보냈을 수도 있습니다.
해결 방법: 구독 정보에 적힌 포트를 확인하세요. 직접 운영하는 서버라면 리스닝 주소와 방화벽도 점검해야 합니다. 같은 설정으로 재시도해도 포트에 서비스가 대기 중이지 않은 문제는 해결되지 않습니다.
i/o timeout
원인: 네트워크 작업이 제한 시간 안에 완료되지 않았습니다. 앞뒤 내용을 확인해 주소 확인, 연결 수립, 데이터 읽기 중 어느 단계에서 발생했는지 파악해야 합니다.
해결 방법: 노드와 설정은 그대로 두고 네트워크만 바꿔 다시 테스트하세요. 특정 네트워크에서만 시간 초과가 발생한다면 노드 설정을 바꾸기 전에 해당 네트워크 경로를 확인하세요.
예를 들어 노드로 연결하는 TCP 443이 시간 초과됐다는 오류가 명확하다면, VLESS 사용자 인증을 원인으로 볼 근거는 아직 부족합니다. 반대로 노드 연결은 성공했지만 그 뒤에 대상 주소를 읽지 못했다면 로컬에서 노드까지의 연결만 점검해서는 안 됩니다. 주소와 단계, 발생 시각을 함께 살펴보세요.
TLS handshake와 invalid user: 보안 계층과 인증 계층을 따로 점검하기
TLS 핸드셰이크 오류는 보통 보안 협상이 시작된 뒤에 발생하지만, 반드시 인증서 문제라는 뜻은 아닙니다. 일반 TLS 노드라면 serverName, 인증서 체인, 시스템 시각, 전송 설정을 확인하세요. VLESS + REALITY 노드는 공개 키, shortId, serverName과 서버 설정도 점검해야 합니다. 두 노드 유형에 '검증 끄기'라는 같은 해결책을 적용할 수는 없습니다.
| 오류 키워드 | 먼저 확인할 항목 | 성급하게 단정하지 말 것 |
|---|---|---|
TLS handshake | 오류에 EOF, 인증서 오류 또는 시간 초과가 함께 있는지, 클라이언트의 보안 유형이 서버와 일치하는지 | 이 두 단어만으로 인증서 만료를 확정할 수 없습니다 |
x509: certificate has expired or is not yet valid | 클라이언트 날짜와 시간대, 인증서 유효기간, 서버 인증서 배포 상태 | 인증서 검증 건너뛰기를 바로 활성화하지 마세요 |
x509: certificate is valid for | 이후 표시되는 인증서 도메인이 검증 대상 serverName과 일치하는지 | 연결 IP와 인증서 도메인이 다른 것이 반드시 설정 오류는 아닙니다 |
invalid user | 로그 출처, 프로토콜 유형, 사용자 식별자, 이에 대응하는 서버 사용자 항목 | 모든 클라이언트가 인증 실패를 이 문구로 표시하는 것은 아닙니다 |
EOF | 상대편이 연결을 끊은 시점과 핸드셰이크·전송·인증 정보가 함께 기록됐는지 | 이 오류만으로 계정이 만료됐다고 단정할 수 없습니다 |
invalid user는 서버 인바운드 인증 로그에서 직접적인 단서를 찾을 가능성이 높지만, 문구는 프로토콜과 버전에 따라 다릅니다. 클라이언트에는 EOF나 연결 종료만 표시될 수도 있습니다. 서버 로그를 볼 수 있다면 양쪽 기록의 시각을 맞춰 UUID가 일치하는지, 해당 사용자가 로드됐는지, 포트가 예상한 인바운드로 연결됐는지 확인하세요. VMess를 사용할 때는 시스템 시각도 점검하세요. VLESS 설정에 VMess의 alterId 설정을 그대로 적용해서는 안 됩니다.
- VLESS + TLS: UUID, 전송 유형, 포트, serverName, 서버에서 요구하는 flow를 확인하세요. WebSocket 방식이라면 경로와 Host도 점검해야 합니다. TCP 노드의 설정값으로 대체할 수 없습니다.
- VLESS + REALITY: UUID, 서버에 설정된 공개 키 정보, shortId, serverName, fingerprint, flow를 확인하세요. 클라이언트마다 필드 이름이 다를 수 있으므로 동일한 노드 설정을 기준으로 대조해야 합니다.
- 시스템 시각: Windows에서는 '설정' → '시간 및 언어' → '날짜 및 시간'으로 이동해 동기화하세요. Android에서는 시스템 '설정'에서 '날짜 및 시간'을 검색하고 자동 설정을 활성화하세요. 제조사마다 메뉴 분류가 다를 수 있습니다.
context canceled: 요청이 취소된 상황인지 먼저 확인하기
context canceled는 해당 작업에 연결된 컨텍스트가 취소됐다는 뜻입니다. 탭 닫기, 브라우저가 먼저 연결한 뒤 해당 연결을 사용하지 않는 경우, 노드 전환, 코어 재시작 등에서도 이런 로그가 남을 수 있습니다. '노드가 반드시 고장 났다'는 뜻도 아니고, 이 문구만으로 DNS나 인증서 이상을 입증할 수도 없습니다.
웹페이지는 열리는데 context canceled가 기록되는 이유는?
새로고침을 멈추고 불필요한 탭을 닫은 뒤 페이지 하나만 열어 보세요. 페이지 로딩이 끝난 뒤나 페이지를 닫은 뒤 취소 로그가 기록되고 계속된 실패가 없다면, 이 부수 로그만을 이유로 노드 설정을 바꿀 필요는 보통 없습니다.
웹페이지를 열자마자 취소 오류가 발생하면 원인을 어떻게 찾나요?
같은 시각 전후의 로그를 확인하고 요청 식별자로 기록을 연결하세요. 해당 버전에서 식별자를 제공하지 않는다면 시각, 대상 주소, 아웃바운드 태그를 함께 살펴보세요. 취소 로그보다 앞서 발생한 주소 확인 실패, 핸드셰이크 오류, 연결 시간 초과를 우선 찾으세요.
노드를 바꾼 뒤 취소 로그가 잔뜩 뜨는데 재설치해야 하나요?
노드를 바꾸면 이전 연결이 종료됩니다. 새 코어가 시작을 마칠 때까지 기다린 뒤 새 요청을 보내세요. 새 시작 시각 이후의 기록만 분석해야 합니다. 이전 연결의 취소 로그로 새 노드의 사용 가능 여부를 판단할 수 없습니다.
구독 업데이트 실패도 이 로그에서 확인해야 하나요?
먼저 클라이언트에서 구독 업데이트 결과를 확인하세요. 업데이트 요청이 현재 프록시를 실제로 통과한 경우에만 코어 로그에서 관련 단서를 찾을 수 있습니다. 요청이 코어에 들어오지 않았다면 아웃바운드 로그만 살펴봐서는 구독 서버가 반환한 구체적인 오류를 찾을 수 없습니다.
로컬 포트와 라우팅: 요청이 실제 프록시로 들어오는지 먼저 확인하기
코어를 시작하자마자 address already in use 또는 Windows의 Only one usage of each socket address가 표시되면 먼저 로컬 리스너 충돌을 해결하세요. 다른 클라이언트 인스턴스가 실행 중이지 않은지 확인한 다음 포트를 점유한 프로세스를 살펴보세요. 프록시 포트를 변경했다면 브라우저의 수동 프록시 설정과 시스템 프록시도 함께 바꿔야 합니다. 클라이언트 설정 한 곳만 변경해서는 안 됩니다.
아래 예시는 Windows의 로컬 포트 10808을 기준으로 합니다. 명령은 포트 점유 여부를 확인하는 용도입니다. 다른 프로그램의 PID를 확인 없이 종료하지 마세요. 포트는 고정된 기본값이 아니므로 현재 설정에서 실제로 대기 중인 포트로 바꿔 사용하세요.
netstat -ano | findstr :10808해당 포트에서 SOCKS 인바운드를 제공한다면 아래 명령으로 프록시를 명시해 요청을 한 번 보낼 수 있습니다. Windows에서는 curl.exe를 사용하면 일부 셸에서 curl 이름이 별칭으로 처리되는 문제를 피할 수 있습니다. socks5h를 쓰면 대상 도메인 확인을 로컬 curl이 아니라 프록시 측에 맡깁니다. 인바운드가 HTTP 프록시만 제공한다면 해당 HTTP 프록시 옵션을 사용해야 하며, SOCKS 명령을 그대로 복사해서는 안 됩니다.
curl.exe --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.com/- 로컬에서 연결 거부: 프록시 서비스가 실행 중인지, 리스닝 포트가 올바른지, 인바운드 프로토콜이 일치하는지 확인하세요. 아직 원격 노드까지 연결하지 않은 상태입니다.
- 요청은 들어왔지만 잘못된 아웃바운드가 선택됨: 라우팅 태그와 일치한 규칙을 살펴보세요. 대상이 직접 연결로 분류되면 노드가 정상이어도 페이지가 열리지 않을 수 있습니다.
- 명령은 성공하지만 브라우저는 실패: 브라우저의 실제 프록시 설정, 확장 프로그램 제어, 별도 DNS 설정을 테스트 명령의 주소 확인 경로와 비교하세요.
- 일부 도메인만 실패: 접속되는 도메인과 실패하는 도메인을 각각 하나씩 골라 도메인 규칙, 주소 확인 결과, 아웃바운드를 비교하세요. 곧바로 전체 설정을 바꾸지 마세요.
문제 해결 기록 정리: 한 번에 변수 하나만 변경하기
문제 해결에 수천 줄의 로그를 붙일 필요는 없습니다. 코어 버전, 오류 발생 시각, 요청을 보낸 경로, 전체 오류 한 건을 기록하면 단순히 '연결이 안 됩니다'라고 하는 것보다 원인을 파악하기 쉽습니다. DNS, flow, 포트, 전송 방식을 한꺼번에 바꾸면 우연히 복구되더라도 어떤 변경이 효과가 있었는지 알기 어렵고, 다음 문제에서 다시 처음부터 살펴봐야 합니다.
- 환경 기록: 운영체제, 클라이언트 버전, 실제 코어 버전과 현재 사용 중인 방식(시스템 프록시, 앱 수동 프록시 또는 TUN)을 적으세요.
- 예상 동작 기록: 단순히 '연결됨'이라고 쓰지 말고, 예를 들어 '요청이 SOCKS 10808로 들어온 뒤 지정한 VLESS 아웃바운드로 테스트 주소에 접속해야 함'처럼 적으세요.
- 관련 로그 보관: 시작 완료 기록, 요청을 보낸 시각, 그 전후 약 10초간의 로그를 남기세요. 마지막 한 줄만 자르지 말고 중첩된 오류 전체를 보관해야 합니다.
- 변경 사항 기록: 한 번에 하나만 변경하고 재시작한 뒤 같은 테스트를 반복하세요. 효과가 없다면 원래 값으로 되돌린 다음 다음 항목을 확인하세요.
- 마무리 확인: 평소 사용하던 로그 레벨로 복원하고 브라우저와 테스트 명령이 모두 예상대로 동작하는지 확인하세요. 기본 사용법은 클라이언트 사용 가이드를 참고할 수 있습니다.
Xray 로그를 읽을 때는 실패 경계를 찾는 것이 핵심입니다. 로컬에서 리스닝하지 않으면 로컬 설정을 먼저 고치고, 노드 주소를 확인하지 못하면 주소 확인을 점검하세요. TCP 연결은 됐지만 핸드셰이크가 실패했다면 보안 및 전송 설정을 살펴보고, 인증 이후 오류가 발생했다면 대상 접속을 확인하세요. 오류를 요청 흐름에 맞춰 살펴보는 편이 특정 키워드만 붙잡고 설정을 반복해서 바꾸는 것보다 확실합니다.