V2Ray 노드 연결 시간 초과·연결 실패: 시스템 시간, 포트 충돌, TLS, 라우팅 순서대로 점검

노드 테스트가 시간 초과되거나 연결되지 않나요? 시스템 시간, 로컬 포트 충돌, TLS·SNI, 라우팅 규칙, 구독 만료 순으로 점검하고 각 항목의 클라이언트 확인 위치를 안내합니다.

이 글 미리보기

먼저 커널이 시작되지 않는 문제인지, 노드 핸드셰이크 실패인지, 브라우저 트래픽이 프록시로 전달되지 않는 문제인지 구분하세요. 이 글에서는 Windows용 v2rayN을 기준으로 설명하고 Android에서 확인할 위치도 덧붙입니다. 시간, 수신 포트, TLS, 라우팅, 구독 순으로 범위를 좁히고 한 번에 한 항목만 변경한 뒤 같은 대상으로 다시 테스트하세요. 포트 번호는 점검을 위한 예시이며 모든 클라이언트의 기본값을 뜻하지 않습니다.

1. 로그를 보존하고 시간 초과가 발생한 단계 확인하기

‘시간 초과’는 결과일 뿐, 문제 발생 지점은 아닙니다. TCP 포트에 연결된다고 해서 프록시 인증까지 성공한 것은 아닙니다. 실제 연결 테스트가 실패해도 노드가 오프라인이라고 단정할 수 없으며, 테스트 대상에 접근할 수 없는 경우도 있습니다. 먼저 v2rayN 메인 창 하단의 로그 영역에서 이번 시작 기록과 실패한 요청 한 건을 보존하고, 사용한 노드와 테스트 방식, 발생 시각을 기록하세요.

앱 요청로컬 수신라우팅 규칙 적용노드 핸드셰이크대상 응답

진단할 때는 노드 하나와 HTTPS 대상 하나를 고정하세요. 노드, DNS, 커널, 라우팅을 한꺼번에 바꾸면 다음에 연결되더라도 무엇이 효과가 있었는지 알 수 없습니다. v2rayN의 우클릭 테스트는 클라이언트가 직접 시작하지만, 브라우저 접속은 앱의 프록시 설정이나 TUN 가로채기에 의존하므로 로컬 프록시에 도달하기까지의 경로가 다를 수 있습니다.

2. 시스템 시간: 동기화한 뒤 핸드셰이크 재시도

시스템 날짜가 크게 어긋나 있다면 먼저 시간을 맞추세요. TLS 인증서에는 유효 시작일과 만료일이 있으며, VMess 인증도 시간 범위에 영향을 받습니다. 노드가 VLESS를 사용한다고 해서 바깥쪽 TLS의 시간 조건을 무시할 수는 없습니다. 시간대 이름만 맞는 것으로는 부족하니 실제 날짜와 시각도 확인하세요.

  1. 시간 설정 열기

    Windows 11에서 ‘설정’ → ‘시간 및 언어’ → ‘날짜 및 시간’으로 이동해 연도, 날짜, 현재 시각을 확인하세요. Windows 10도 ‘시간 및 언어’에서 설정할 수 있지만 메뉴 이름은 조금 다를 수 있습니다.

  2. 시간 동기화

    ‘자동으로 시간 설정’을 켜고 ‘추가 설정’의 ‘지금 동기화’를 실행하세요. 시간대는 현재 위치에 맞게 선택합니다. 표시되는 시간대가 다르더라도 실제 타임스탬프가 정확하다면 그것만으로 TLS가 실패하지는 않습니다.

  3. 다시 테스트

    동기화가 완료되면 v2rayN에서 기존 노드를 다시 활성화하고 같은 방식으로 테스트하세요. Android에서는 시스템 ‘설정’ → ‘시스템’ → ‘날짜 및 시간’에서 자동 시간 설정을 확인합니다. 일부 기기에서는 해당 메뉴가 ‘추가 설정’에 있습니다.

로그에 인증서 만료가 표시되면 먼저 오류에 나온 현재 시간이 정확한지 확인하세요. 시간을 맞춘 뒤에도 인증서 만료 오류가 계속되면 노드 제공자에게 서버 인증서를 점검해 달라고 요청하세요. ‘인증서 검증 건너뛰기’를 장기적인 해결책으로 삼아서는 안 됩니다.

3. 포트 충돌: 로컬 수신 포트와 원격 포트 구분하기

로컬 포트는 앱의 요청을 받고, 원격 포트는 노드 서버에 연결할 때 사용합니다. 두 포트는 서로 바꿔 쓸 수 없습니다. 예를 들어 PC의 혼합 수신 포트가 10808이고 원격 TLS 포트가 443이라면, 서버 편집 창에 표시된 포트는 브라우저에 입력할 로컬 프록시 포트가 아닙니다.

10808
로컬 수신 포트 예시. 실제 값은 매개변수 설정에서 확인
443
원격 TLS 포트 예시. 실제 값은 노드 설정에서 확인

v2rayN에서 ‘설정’ → ‘매개변수 설정’을 열고 Core 기본 설정 관련 페이지에서 로컬 수신 포트를 확인하세요. 버전에 따라 그룹 이름은 조금씩 다르며 혼합 수신은 보통 ‘로컬 혼합 수신 포트’로 표시됩니다. 예시 값을 그대로 사용하지 마세요. 그런 다음 Windows 터미널에서 아래 읽기 전용 명령을 실행하고, 숫자를 화면에 표시된 실제 포트로 바꾸세요:

netstat -ano | findstr ":10808"

로컬 주소 열에 확인하려는 포트가 있는지, 상태가 LISTENING인지 확인하세요. 원격 주소에 해당 포트가 포함된 연결을 수신 대기 기록으로 착각하지 마세요. 마지막 열은 PID입니다. ‘작업 관리자’ → ‘세부 정보’에서 프로세스와 대조하세요. PID 열이 보이지 않으면 열 제목을 우클릭해 해당 열을 선택합니다.

4. TLS와 SNI: 원본 노드 설정을 항목별로 확인하기

v2rayN 서버 목록에서 대상 노드를 우클릭한 뒤 ‘서버 편집’을 여세요. 먼저 주소, 포트, 프로토콜을 확인하고 TLS 및 전송 설정을 살펴봅니다. 주소는 연결할 대상을 지정하고 SNI는 TLS 핸드셰이크에서 사용할 서비스 이름을 지정하므로 두 값이 항상 같아야 하는 것은 아닙니다. 제공자가 안내한 설정을 기준으로 하며, 주소가 IP라는 이유만으로 SNI까지 IP로 바꾸지 마세요.

항목확인할 내용흔히 잘못 바꾸는 설정
주소 및 포트현재 구독의 노드와 일치하는지, 포트가 서버의 실제 접속 포트인지 확인로컬 포트 10808을 노드 포트에 입력
TLS 및 SNITLS 유형과 서비스 이름이 제공자 설정과 일치하는지 확인인기 웹사이트 도메인을 임의로 입력
전송 설정WebSocket의 Host와 Path 또는 gRPC의 serviceName 확인주소와 UUID만 복사하고 전송 매개변수는 누락
인증 정보UUID, 비밀번호, 프로토콜별 매개변수 확인VMess와 VLESS를 서로 바꿔 쓸 수 있는 프로토콜로 취급
REALITY 매개변수공개 키, shortId, serverName 등 제공자가 지정한 항목 확인일반 TLS 설정처럼 보고 매개변수를 임의로 생략

WebSocket의 Host와 TLS의 SNI는 서로 다른 계층의 값이므로 같은 항목으로 취급해서는 안 됩니다. REALITY를 사용할 때는 선택한 커널이 현재 설정을 지원하는지도 확인하세요. v2rayNG는 Xray 커널을 사용하고 v2flyNG는 V2Fly 커널을 사용하므로 두 커널의 노드 설정 지원 범위가 같다고 볼 수 없습니다. v2rayN에서는 ‘설정’ → ‘매개변수 설정’의 Core 유형 설정 페이지에서 프로토콜별 커널을 확인할 수 있습니다.

x509: certificate has expired or is not yet valid

원인: PC 시간이 맞지 않거나 서버 인증서의 유효 기간에 문제가 있습니다. 해결: 먼저 시스템 시간을 맞추세요. 시간이 정확한데도 오류가 나면 제공자에게 인증서를 확인해 달라고 요청하세요.

tls: handshake failure

원인: TLS 협상이 거부되었습니다. SNI, 서버 정책 또는 접속 지점 설정이 원인일 수 있습니다. 해결: 원본 구독 설정과 TLS·SNI 값을 대조한 뒤, 제공자에게 서버 로그를 바탕으로 확인해 달라고 요청하세요. 이 메시지만으로 원인을 하나로 단정할 수는 없습니다.

5. 라우팅 및 트래픽 처리 방식: 테스트 성공 후 앱 트래픽 확인하기

실제 연결 테스트는 성공했지만 브라우저가 열리지 않는다면 요청이 클라이언트로 들어오는지 먼저 확인하세요. v2rayN 메인 화면 하단의 ‘시스템 프록시’에서 ‘시스템 프록시 자동 설정’을 선택하고, 브라우저에 별도의 고정 프록시가 설정되어 있는지도 확인합니다. 시스템 프록시를 따르지 않는 앱은 시스템 프록시를 켜도 트래픽이 강제로 전달되지 않습니다.

  1. 먼저 트래픽 처리 방식을 고정하세요. 일반 브라우저 문제를 점검할 때는 다른 프록시 프로그램을 종료하고 TUN을 잠시 끈 뒤 시스템 프록시로 다시 테스트하세요. TUN을 확인해야 한다면 메인 화면의 ‘TUN 활성화’ 상태와 시작 로그에 가상 네트워크 어댑터 또는 권한 오류가 있는지 확인합니다.
  2. 그다음 라우팅을 확인하세요. 메인 화면 하단의 ‘라우팅’에서 현재 구성을 확인합니다. 비교를 위해 대상 트래픽을 프록시로 보내는 전역 구성을 잠시 선택하고, 원래 구성을 기록해 둔 뒤 테스트가 끝나면 복원하세요.
  3. 적용되는 규칙을 확인하세요. ‘설정’ → ‘라우팅 설정’에서 현재 구성의 규칙 순서를 확인합니다. 커널은 규칙 순서대로 일치 여부를 판단하므로 예상한 프록시 규칙보다 앞선 직접 연결 또는 차단 규칙이 먼저 적용될 수 있습니다.
  4. 마지막으로 DNS를 확인하세요. 도메인 이름 확인 오류, 특정 도메인 문제 또는 DNS 결과와 라우팅이 맞지 않는 경우에만 DNS를 점검하세요. 브라우저의 보안 DNS, 시스템 DNS, 커널 DNS가 각각 적용될 수 있으므로 한 번에 모두 바꾸지 마세요.

전역 구성을 적용한 뒤 접속이 복구된다면 UUID를 새로 만드는 대신 분할 라우팅 규칙이나 이름 확인 경로를 중점적으로 살펴보세요. 로그에도 요청이 없다면 트래픽 처리 방식부터 다시 확인합니다. 다만 로그 수준이 낮으면 연결별 기록이 표시되지 않을 수 있으므로 기록이 보이지 않는다는 사실만으로 단정하지 마세요. 로그 상세도를 일시적으로 높였다면 방문 내용이 장시간 기록되지 않도록 점검 후 원래대로 되돌리세요.

6. 구독 만료와 서버 장애: 비교 테스트로 확인하기

구독 업데이트에 성공했다는 것은 클라이언트가 내용을 가져왔다는 뜻일 뿐, 계정에 남은 트래픽이 있거나 모든 노드가 온라인이라는 뜻은 아닙니다. v2rayN 상단의 ‘구독 그룹’ 메뉴에서 해당 구독을 업데이트하세요. 현재 프록시가 작동하지 않으면 ‘현재 구독 업데이트(프록시 사용 안 함)’으로 직접 연결을 시도할 수 있습니다. 구독 주소에 직접 연결할 수 없더라도 기존 노드를 반복해서 삭제하지 말고 현재 설정을 보존하세요.

Android용 v2rayNG에서는 메인 화면 오른쪽 위 메뉴의 ‘구독 그룹 설정’에서 구독 주소를 확인하고 ‘구독 업데이트’로 갱신할 수 있습니다. 노드 편집은 해당 노드 카드에서 열 수 있습니다. 버전에 따라 그룹 메뉴에 업데이트 항목이 있을 수 있으며, 업데이트 결과는 로그와 노드 목록의 변화를 함께 확인하세요. 화면을 캡처하기 전에 구독 링크, UUID, 비밀번호, QR 코드를 가리세요. 이런 정보는 연결 권한을 직접 부여할 수 있습니다.

7. 오류 메시지 해석하기: 재현 가능한 점검 기록 남기기

오류 메시지는 앞뒤 로그와 함께 확인하세요. 같은 연결 거부 메시지도 로컬 수신 주소에서 발생했는지 원격 노드 주소에서 발생했는지에 따라 해결 방향이 완전히 달라집니다. 다음 메시지 유형으로 문제 발생 단계를 좁힐 수 있지만, 전체 로그를 대신할 수는 없습니다.

bind: address already in use

원인: 커널이 바인딩하려는 로컬 주소와 포트를 다른 프로세스가 사용 중입니다. 해결: 해당 포트를 수신 중인 프로세스를 찾아 중복 인스턴스를 종료하거나 로컬 수신 포트를 변경하세요. Windows에서는 소켓 주소 사용 중이라는 비슷한 메시지가 표시될 수도 있습니다.

connection refused

원인: 대상에서 연결을 거부했습니다. 수신 서비스가 실행 중이지 않거나 정책에 의해 명시적으로 거부되었을 수 있습니다. 해결: 먼저 대상 주소를 확인하세요. 로컬 주소라면 커널 실행 여부를, 원격 주소라면 노드 포트와 서버 상태를 확인합니다.

context deadline exceeded

원인: 정해진 시간 안에 작업이 완료되지 않았습니다. 연결 시도, 핸드셰이크, 응답 수신 중 어느 단계에서든 발생할 수 있습니다. 해결: 앞부분의 연결 대상과 오류 체인을 함께 확인해 발생 단계를 찾으세요. 문제를 가리기 위해 시간 초과 값을 늘리는 데 그치지 마세요.

no such host

원인: 현재 DNS 경로에서 대상 호스트를 올바르게 확인하지 못했습니다. 해결: 오류에 표시된 도메인이 노드 주소인지 접속 대상인지 먼저 구분한 다음, 철자와 도메인 상태, 해당 DNS 설정을 확인하세요.

한 차례 점검을 마치면 다음 항목을 기록해 두세요. 재테스트가 쉬워지고 제공자와 여러 차례 확인하는 일을 줄일 수 있습니다. 전체 설정 파일이나 바로 가져올 수 있는 노드 공유 링크는 보내지 마세요.

v2rayN 다운로드플랫폼 및 설치 옵션 확인