V2Ray 노드 시간 초과로 연결되지 않을 때 해결 방법: 로컬 설정부터 서버까지 점검 순서

“노드 시간 초과”는 하나의 고장만을 뜻하지 않습니다. 도메인 이름 확인, TCP 연결 수립, TLS 핸드셰이크, 프로토콜 인증 또는 로컬 프록시 전달 과정의 어느 단계에서든 발생할 수 있습니다. 노드를 계속 바꾸는 것만으로는 우연히 문제를 피할 수 있을 뿐, 장애가 PC·네트워크·구독·서버 중 어디에 있는지는 알 수 없습니다.

더 효과적인 방법은 장애 범위를 단계적으로 좁히는 것입니다. 먼저 클라이언트 코어가 실행 중인지 확인하고, 로컬 수신 포트가 정상인지 확인한 다음 노드 매개변수를 대조하고, 마지막에 원격 서버를 점검하세요. 각 단계를 마칠 때마다 로그나 연결 결과를 확인하고 여러 필드를 동시에 수정하지 마세요.

먼저 “시간 초과”가 발생한 단계를 구분하세요

클라이언트에 빨간색 지연 시간이 표시되거나 연결 테스트가 실패하고 로그에 timeout이 나타났다고 해서 모두 같은 문제는 아닙니다. 하나의 연결은 최소한 “클라이언트 프로세스 → 로컬 프록시 포트 → 도메인 이름 확인 → 원격 포트 → TLS 또는 REALITY 핸드셰이크 → VMess/VLESS 인증” 단계를 거칩니다. 앞 단계가 완료되지 않으면 다음 단계는 시작되지 않습니다.

먼저 스크롤 로그를 지우거나 일시 중지한 뒤 문제가 있는 노드에 한 번만 다시 연결하고, 이번 연결에서 생성된 내용만 확인하세요. v2rayN은 기본 창 하단의 로그 영역에서 확인할 수 있습니다. 더 자세한 기록이 필요하면 「설정」→「매개변수 설정」→「기본 설정」으로 이동해 로그 수준을 임시로 info로 조정하세요. v2rayNG는 왼쪽 상단 메뉴를 연 다음 「로그」에서 현재 코어 출력을 확인할 수 있습니다.

• 모든 노드가 동시에 실패:시스템 시간, 코어, 시스템 프록시, 로컬 포트 및 현재 네트워크를 우선 확인하세요.
• 노드 하나만 실패:해당 노드의 주소, 포트, 전송 계층 필드 및 서버 상태를 우선 확인하세요.
• 속도 측정은 실패하지만 웹페이지는 열림:속도 측정 대상에 연결할 수 없는 경우일 수 있으므로, 지연 시간 하나만으로 노드 장애를 판단해서는 안 됩니다.
• 클라이언트에는 연결됨으로 표시되지만 웹페이지가 열리지 않음:시스템 프록시가 활성화되어 있는지, 브라우저가 프록시를 우회하는지, DNS 요청이 올바른 아웃바운드로 전달되는지 중점적으로 확인하세요.

1차 점검: 시스템 시간, 코어 및 로컬 프록시 포트

VMess는 인증에 시간 정보를 사용하며 TLS와 REALITY 핸드셰이크도 정확한 시간을 필요로 합니다. 시스템 시간이 몇 분만 어긋나도 겉으로는 도메인을 확인하고 포트에 연결할 수 있지만 인증 단계에서 실패할 수 있습니다. 먼저 시스템 설정에서 자동 시간 설정과 자동 시간대 설정을 켜고 동기화한 뒤 클라이언트를 완전히 종료했다가 다시 시작하세요.

두 번째 점검 항목은 코어 상태입니다. 클라이언트 화면은 설정을 관리할 뿐 실제 연결은 Xray 또는 v2fly 코어가 수립합니다. 버튼에 “시작됨”으로 표시되어도 코어가 계속 실행 중이라는 뜻은 아닙니다. 포트가 이미 사용 중이면 코어가 시작 직후 종료될 수 있으므로 로그에 수신 대기 성공 기록이 있는지 확인해야 합니다.

1. 시간 동기화

   시스템의 날짜 및 시간 설정을 열고 자동 시간과 자동 시간대를 활성화하세요. 동기화가 끝나면 날짜, 시간대, 분 단위 시간이 모두 정확한지 확인하세요.

2. 코어 확인

   v2rayN에서 「설정」→「매개변수 설정」→「Core 유형」을 열고 현재 노드에 해당하는 Xray 또는 v2fly 코어가 선택되어 있는지 확인하세요. 저장한 뒤 「서비스 재시작」을 실행합니다.

3. 포트 확인

   v2rayN에서 「설정」→「매개변수 설정」→「기본 설정」으로 이동해 로컬 수신 포트를 기록하세요. v2rayNG는 왼쪽 상단 메뉴에서 「설정」→「로컬 프록시 포트」로 이동합니다.

4. 포트 점유 제외

   로그에 address already in use 또는 Only one usage of each socket address가 나타나는지 확인하세요. 표시된다면 해당 포트를 사용하는 기존 프로세스를 종료하거나 사용하지 않는 포트로 수신 포트를 변경하세요.

5. 프록시 다시 시작

   v2rayN의 시스템 트레이 메뉴에서 먼저 시스템 프록시를 끈 다음 자동으로 시스템 프록시 구성 옵션을 선택하세요. Android에서는 현재 연결을 끊고 3초 기다린 뒤 다시 시작합니다.

2차 점검: 주소, 포트, 사용자 식별자 및 암호화 필드

로컬 수신이 정상이라면 노드 정보를 하나씩 대조하세요. 기억에 의존해 수정하지 마세요. 노드 이름은 메모일 뿐 연결을 결정하지 않습니다. 실제 인증에 영향을 주는 것은 서버 주소, 포트, 프로토콜, 사용자 식별자 및 전송 설정입니다.

VMess 노드는 id, alterId 및 보안 옵션을 중점적으로 확인하세요. 최신 설정에서는 일반적으로 alterId: 0을 사용하지만 최종적으로는 서버 설정을 따라야 합니다. VLESS 노드는 UUID, 흐름 제어 필드 및 보안 계층을 중점적으로 확인하세요. XTLS Vision을 사용할 때 흔히 쓰는 흐름 제어 값은 xtls-rprx-vision이며, 빈 값과 이 값을 임의로 바꿔서는 안 됩니다.

{
  "address": "node.example.net",
  "port": 443,
  "id": "노드 정보를 한 글자씩 대조",
  "security": "reality",
  "flow": "xtls-rprx-vision"
}

3차 점검: 전송 계층, TLS 및 REALITY 매개변수

주소와 사용자 식별자가 정확하다고 해서 노드가 핸드셰이크를 완료할 수 있는 것은 아닙니다. WebSocket, gRPC, TCP 및 HTTPUpgrade는 필드 구조가 서로 다릅니다. 클라이언트의 전송 방식은 서버와 일치해야 하며 경로, 호스트 이름, 서비스 이름 등의 문자열도 한 글자씩 동일해야 합니다.

TLS를 사용할 때 serverName은 일반적으로 핸드셰이크에 사용하는 도메인입니다. 연결 주소와 같지 않을 수도 있지만 서버 배포 설정에 맞아야 합니다. REALITY를 사용할 때는 publicKey, shortId, serverName 및 지문도 확인해야 합니다. 어느 한 필드라도 일치하지 않으면 연결 직후 끊기거나 핸드셰이크 시간 초과로 나타날 수 있습니다.

4차 점검: 구독 만료 여부와 기존 노드 캐시 확인

구독 링크가 열리더라도 그 안의 모든 노드가 여전히 유효하다는 뜻은 아닙니다. 서버에서 이미 주소, 포트 또는 UUID를 변경했지만 클라이언트 목록에는 이전 업데이트의 캐시가 남아 있을 수 있습니다. 오래된 노드를 수동으로 편집하는 것은 임시 조치일 뿐이며, 이후 구독을 업데이트하면 다시 덮어써질 수 있습니다.

v2rayN에서는 먼저 「구독 그룹」에서 구독 주소를 확인한 뒤 「구독 그룹」→「모든 구독 업데이트」를 실행하세요. 현재 네트워크에서 구독 주소에 직접 접근할 수 없지만 사용 가능한 노드가 있다면 환경에 따라 프록시를 통해 업데이트하세요. v2rayNG에서는 왼쪽 상단 메뉴에서 「구독 그룹 설정」으로 이동해 주소를 저장하고 노드 목록으로 돌아온 다음 「구독 업데이트」를 실행할 수 있습니다.

1. 기존 목록 보존

   업데이트 전에 문제가 있는 노드의 주소, 포트 및 업데이트 시간을 기록하세요. 앞뒤를 비교할 기준을 잃지 않도록 모든 설정을 먼저 삭제하지 마세요.

2. 링크 확인

   구독 그룹 설정으로 이동해 링크에 줄바꿈, 공백 또는 누락된 부분이 없는지 확인하세요. 서비스 제공자가 새 주소를 안내했다면 기존 주소를 교체한 뒤 저장합니다.

3. 구독 업데이트

   모든 구독 업데이트를 실행하고 로그의 HTTP 상태와 소요 시간을 확인하세요. 30초가 지나도 응답이 없으면 직접 연결 업데이트와 프록시를 통한 업데이트를 각각 테스트합니다.

4. 필드 비교

   업데이트된 노드의 세부 정보를 열고 기존 기록의 address, port, id, network 및 security와 비교해 서버 이전이 있었는지 확인하세요.

5. 세 번 재테스트

   업데이트된 노드 하나를 선택해 5초 간격으로 실제 연결 테스트를 세 번 실행하세요. 한 번 성공하고 두 번 시간 초과가 발생한다면 네트워크 패킷 손실과 서버 부하를 계속 확인해야 합니다.

5차 점검: 교차 테스트로 로컬 네트워크와 서버의 경계 확인

클라이언트와 노드 필드를 확인한 뒤에야 네트워크 경계를 판단하세요. 가장 간단한 교차 테스트는 노드 설정을 그대로 유지하고 접속 네트워크만 바꾸는 것입니다. 데스크톱에서는 현재 유선 또는 광대역 네트워크를 모바일 핫스팟으로 바꾸고, Android에서는 현재 Wi-Fi를 모바일 네트워크로 전환하세요. 네트워크를 바꾼 직후 복구된다면 장애는 기존 네트워크의 DNS, 라우팅 또는 포트 접근 경로에 있을 가능성이 큽니다.

반대로 동일한 노드가 서로 다른 두 네트워크에서 모두 시간 초과가 발생하고 같은 클라이언트의 다른 노드는 정상적으로 연결된다면 해당 노드의 서버를 의심해야 합니다. 이때 클라이언트를 계속 재설치하거나 시스템 프록시를 반복해서 바꿔도 결과가 달라지지 않는 경우가 많습니다.

• 원격 도메인을 확인할 수 없다면 먼저 노드 주소가 아직 유효한지 확인한 뒤 DNS 변경을 테스트하세요. 도메인을 확인된 IP로 바로 바꾸면 TLS 또는 REALITY가 여전히 도메인에 의존할 수 있으므로 피해야 합니다.
• 원격 포트가 명확히 연결을 거부한다면 서버 관리자는 프로세스 실행 여부, 수신 주소의 정확성, 인바운드 포트 허용 여부를 확인해야 합니다.
• 원격 포트에는 접근할 수 있지만 프로토콜 핸드셰이크에 실패한다면 클라이언트와 서버의 프로토콜, UUID, 보안 계층 및 전송 필드를 중점적으로 비교하세요.
• 서버 로그에 연결 기록이 전혀 없는데 클라이언트에서 계속 시간 초과가 발생한다면, 문제는 대개 서버에 도달하기 전 네트워크 경로에서 발생합니다.

자주 묻는 문제: 속도 측정, 시스템 프록시 및 업데이트 후 이상

정해진 순서대로 점검하면 대부분의 문제는 로컬 수신, 노드 매개변수, 구독 캐시, 네트워크 경로 또는 서버 상태 중 하나로 분류할 수 있습니다. 다음 현상은 서로 혼동하기 쉬우므로 각각 처리해야 합니다.