노드 연결 시간 초과 문제 해결 순서: 구독, 시간, 포트 및 프로토콜 매개변수 점검

노드에 시간 초과가 표시된다고 해서 프로토콜 자체가 작동하지 않는 것은 아닙니다. 같은 빨간색 지연 결과라도 구독에 이전 주소가 남아 있거나, 시스템 시간 오차, 도메인 조회 실패, 로컬 수신 포트 충돌, 전송 계층 설정과 서버 설정의 불일치가 원인일 수 있습니다. 노드를 계속 바꾸기만 하면 원인이 뒤섞이고 로그도 반복 요청으로 덮어쓰기 쉽습니다.

보다 안정적인 방법은 점검 순서를 고정하고, 매번 변수 하나만 바꾸며 클라이언트 버전, 테스트 시간, 네트워크 유형, 핵심 로그를 기록하는 것입니다. 이 글은 데스크톱 v2rayN과 Android에서 Xray 코어를 사용하는 v2rayNG, v2fly 코어를 사용하는 v2flyNG에 적용됩니다. 메뉴 이름은 소버전에 따라 달라질 수 있지만 구독, 시간, 포트, 네트워크, 프로토콜의 다섯 단계 판단은 동일합니다.

먼저 시간 초과가 발생한 구간을 확인하세요

프록시 연결은 최소한 애플리케이션, 로컬 프록시 수신, 라우팅 규칙, 원격 네트워크 연결, 프로토콜 핸드셰이크를 거칩니다. 브라우저에 ‘연결 시간 초과’만 표시되면 어느 구간에서 실패했는지 알 수 없습니다. 먼저 클라이언트 로그를 열고 재현 가능한 요청을 한 번 실행하세요. 예를 들어 다른 다운로드를 종료하고 고정된 웹페이지 하나만 방문한 뒤 요청 전후 30초의 로그를 보관합니다.

지연 테스트도 유형을 구분해야 합니다. TCP 탐지는 원격 주소와 포트에 연결을 설정할 수 있는지만 보여 주며 VLESS 또는 VMess 핸드셰이크 성공을 의미하지 않습니다. 실제 지연은 전체 프록시 경로를 거치므로 실제 접속에 더 가깝습니다. TCP 지연이 86ms인데 실제 지연이 계속 시간 초과라면 로컬 DNS보다 프로토콜, 보안 계층, 전송 설정을 먼저 점검하세요.

1단계: 구독을 업데이트하고 노드가 유효한지 확인하세요

구독은 노드 설정의 출처입니다. 서버에서 도메인, 진입 포트, UUID, 전송 경로 또는 보안 계층을 변경하면 로컬 목록에 이전 노드가 남아 연결이 계속 시간 초과될 수 있습니다. 점검할 때는 노드 이름이 같은지만 보지 말고 구독의 마지막 업데이트 시간과 업데이트 후 노드 수, 주소, 포트의 변경 여부를 확인하세요.

v2rayN에서 먼저 「구독 그룹」→「구독 그룹 설정」으로 이동해 구독 주소가 완전하고 그룹이 활성화되어 있는지 확인하세요. 주 화면으로 돌아온 뒤 「구독 그룹」→「모든 구독 업데이트(프록시 사용 안 함)」를 선택합니다. 현재 네트워크에서 구독을 직접 가져올 수 없다면 이미 사용 가능한 노드에 연결한 후 「모든 구독 업데이트(프록시 사용)」를 이용하세요. 두 방법 중 하나만 선택해 테스트를 완료하고, 연속으로 실행해 오류 상황을 덮어쓰지 않도록 합니다.

1. 이전 상태 기록

   노드 수, 구독 업데이트 시간, 현재 선택된 노드를 기록하세요. 예를 들어 노드 24개, 마지막 업데이트 2026-05-27 21:10으로 남겨 두면 업데이트가 실제로 이루어졌는지 판단하기 쉽습니다.

2. 구독 업데이트

   「구독 그룹」→「모든 구독 업데이트(프록시 사용 안 함)」를 엽니다. 완료 안내가 표시될 때까지 기다리고 업데이트 중에는 클라이언트를 종료하거나 네트워크를 전환하지 마세요.

3. 변경 사항 확인

   업데이트 전후의 주소, 포트, 전체 노드 수를 비교하세요. 노드 수가 24개에서 21개로 줄었다면 새 목록을 사용하고, 이전 백업에서 삭제된 노드를 복원하지 마세요.

4. 단일 노드 재테스트

   새 노드 하나를 선택하고 코어를 재시작한 뒤 세 번 테스트하세요. 각 테스트 사이에는 5초를 두고, 세 번 모두 시간 초과라면 시간과 네트워크를 계속 점검하되 프로토콜을 일괄 변경하지 마세요.

2단계: 시스템 시간을 보정하고 도메인 조회를 확인하세요

VMess 인증은 시간 창에 의존하고 TLS 인증서 검증도 시스템 날짜에 의존합니다. 기기 시간이 몇 분 어긋나도 일반 웹페이지는 열릴 수 있지만 프록시 핸드셰이크는 실패합니다. 먼저 시스템의 날짜, 시간, 시간대 자동 설정을 켜고 즉시 동기화를 실행하세요. 오차는 30초 이내로 유지하는 것이 좋으며, 90초를 넘으면 노드 설정을 조정하지 말고 먼저 시간을 맞추세요.

시간을 정확히 맞춘 뒤 DNS를 확인하세요. 노드 주소가 도메인이라면 로컬에서 먼저 연결 가능한 IP로 조회해야 합니다. 터미널에서 운영체제에 기본 제공되는 조회 명령을 실행하고 주소 반환 여부와 응답 시간을 확인하세요. 세 번 연속 조회가 모두 2000ms를 넘거나 조회 실패가 번갈아 나타난다면 문제는 프로토콜 핸드셰이크 전에 발생한 것입니다.

• 시스템 날짜, 시간대, 서머타임 규칙이 현재 위치와 일치하는지 확인하세요. 작업 표시줄의 시와 분만 확인해서는 안 됩니다.
• 절전 후 복귀한 컴퓨터는 시간을 다시 동기화해야 합니다. 장시간 절전 뒤에는 시간 서비스가 아직 보정을 완료하지 않았을 수 있습니다.
• 네트워크를 바꾼 뒤 노드 도메인을 다시 조회하여 만료된 로컬 캐시 결과를 계속 사용하지 않도록 하세요.
• 구독 주소는 열리지만 노드 도메인이 조회되지 않는다면 두 도메인의 조회 결과를 각각 기록하고 동일한 문제로 취급하지 마세요.

nslookup node.example.net

확인할 내용:
Address: 203.0.113.20
첫 응답: 42ms
연속 조회: 모두 동일한 유효 주소 반환

3단계: 로컬 포트, 코어 상태, 방화벽을 확인하세요

노드 설정이 올바르더라도 로컬 코어가 먼저 프록시 포트를 정상적으로 수신해야 합니다. v2rayN의 일반적인 설정은 SOCKS 포트 10808을 사용하고 여기서 HTTP 포트 10809를 파생하지만, 실제 값은 「설정」→「매개변수 설정」의 로컬 수신 설정을 기준으로 합니다. 브라우저에 10809를 입력했는데 클라이언트가 이미 20809로 변경되어 있다면 요청은 현재 코어로 들어가지 않습니다.

포트 충돌은 이전 코어가 종료되지 않았거나 다른 클라이언트가 실행 중일 때, 또는 시스템이 절전에서 복귀한 뒤 남은 프로세스 때문에 발생하는 경우가 많습니다. v2rayN 창을 닫았다고 백그라운드 프로세스까지 종료된 것은 아닙니다. 트레이에서 종료한 뒤 다시 시작하세요. 점검 중에는 클라이언트 하나와 코어 인스턴스 하나만 유지하여 여러 프로그램이 시스템 프록시를 동시에 변경하지 않도록 합니다.

1. 코어 실행 확인

   주 화면 하단의 상태와 로그를 확인하세요. 시작 후에는 수신 성공 메시지가 표시되어야 하며, 로그가 1초 안에 종료된다면 먼저 코어 시작 오류를 처리하세요.

2. 수신 포트 확인

   「설정」→「매개변수 설정」으로 이동하여 SOCKS 포트 10808과 HTTP 포트 10809를 기록하세요. 브라우저나 다른 애플리케이션은 유형에 맞는 포트를 입력해야 합니다.

3. 충돌 포트 해제

   다른 프록시 클라이언트와 남아 있는 코어를 완전히 종료한 후 v2rayN을 다시 시작하세요. 10808이 계속 사용 중이면 20808로 변경하고 HTTP 포트와 애플리케이션 설정도 함께 조정하세요.

4. 방화벽 확인

   현재 코어 프로그램이 사용 중인 네트워크 유형에서 통신을 허용받았는지 확인하세요. 테스트가 끝나면 기존 보안 정책을 복원하고 관련 없는 프로그램의 인바운드 권한을 장기간 완화하지 마세요.

정상 수신 예시:
SOCKS listening on 127.0.0.1:10808
HTTP listening on 127.0.0.1:10809

충돌 예시:
failed to listen TCP on 127.0.0.1:10808
bind: address already in use

4단계: 다른 네트워크로 회선 문제와 노드 문제를 구분하세요

구독, 시간, 로컬 포트가 모두 정상이라면 노드 설정을 바꾸지 않은 상태에서 네트워크를 전환하세요. 가정용 인터넷과 모바일 핫스팟을 두 대조군으로 삼아 동일한 노드, 클라이언트, 테스트 주소로 실제 지연 테스트를 각각 세 번 실행할 수 있습니다. 네트워크 진입점만 바꿔야 문제가 현재 회선에 집중되어 있는지 판단할 수 있습니다.

예를 들어 가정용 네트워크에서 세 번 모두 시간 초과이고 모바일 핫스팟에서 118ms, 126ms, 121ms가 나왔다면 노드 설정은 적어도 핸드셰이크를 완료할 수 있다는 뜻입니다. 점검 초점은 가정용 네트워크의 DNS, 라우팅 또는 방화벽으로 옮겨야 합니다. 두 네트워크 모두 약 10초 후 시간 초과라면 원격 포트에 접근할 수 없거나 프로토콜 설정이 일치하지 않을 가능성이 큽니다.

5단계: 프로토콜과 전송 설정을 항목별로 확인하세요

앞의 네 단계가 모두 통과한 경우에만 노드 편집 화면으로 들어가세요. 먼저 프로토콜 유형이 VLESS인지 VMess인지 확인한 다음 서버에서 제공한 설정을 항목별로 비교합니다. UUID는 인증 식별자이므로 경험에 따라 임의로 바꾸면 안 됩니다. 포트는 진입점의 수신 포트와 일치해야 하며 TCP, WebSocket, gRPC 전송 방식은 서로 바꿔 쓸 수 없습니다. TLS, REALITY 같은 보안 계층도 서버 설정과 일치해야 합니다.

WebSocket 환경에서는 Host와 경로를 확인하세요. 경로의 슬래시와 대소문자도 라우팅에 영향을 줄 수 있습니다. gRPC에서는 서비스명을 확인합니다. TLS 환경에서는 서버 이름, 즉 SNI도 확인해야 합니다. 연결 주소가 IP여도 인증서 검증에 사용하는 이름은 서버 요구 사항과 일치해야 합니다. REALITY 설정에서는 서버 이름, 공개 키, 짧은 ID를 확인해야 하며 일반 TLS 필드를 그대로 적용해서는 안 됩니다.

클라이언트별 재테스트 핵심

데스크톱 v2rayN은 코어 시작, 수신, 아웃바운드 로그를 직접 확인하기에 적합합니다. 점검 전에 「도움말」→「정보」에서 클라이언트 버전을 기록하고 로그 시작 부분에 코어 버전도 남기세요. 예: 클라이언트 7.x, Xray-core 25.x. 버전 번호가 곧 원인을 뜻하지는 않지만 동일한 설정이 서로 다른 코어 환경에서 재현되는지 판단하는 데 도움이 됩니다.

Android의 v2rayNG는 Xray 코어를, v2flyNG는 v2fly 코어를 사용합니다. 동일한 구독을 서로 다른 두 코어 클라이언트에 각각 가져오는 방법은 설정 호환성을 확인할 때만 사용하고, 같은 테스트에서 전송 설정까지 동시에 변경하지 마세요. 모바일 네트워크와 Wi-Fi를 전환한 뒤에는 시스템이 할당한 DNS와 외부 경로가 바뀌었을 수 있으므로 연결 테스트를 다시 실행해야 합니다.

수정 완료 후 검증 순서

원인을 찾았더라도 한 번만 확인하지 마세요. 먼저 코어를 재시작하여 로컬 포트 수신 성공을 확인하고, 실제 지연 테스트를 세 번 실행하세요. 이어서 일반 웹페이지와 프록시가 필요한 대상 주소를 열고, 마지막으로 10분 후 다시 테스트합니다. 짧은 시간 동안 우연히 성공한 것일 수 있으며 DNS 캐시나 회선 전환이 아직 안정되지 않았을 가능성이 있습니다.

최종 결과는 ‘클라이언트 및 코어 버전, 네트워크 유형, 노드 프로토콜, 수정 항목, 세 번의 지연 시간’으로 기록하는 것이 좋습니다. 예: v2rayN 7.x, Xray-core 25.x, 가정용 인터넷, VLESS over WebSocket with TLS, SNI 수정, 결과 92ms·95ms·91ms. 이런 기록이 ‘재설치하니 됐다’보다 다음 문제에 재사용하기 좋습니다.

1. 코어 재시작

   로그에서 10808과 10809가 모두 정상적으로 수신 중인지, 시작 후 포트 충돌이나 설정 구문 분석 오류가 없는지 확인하세요.

2. 세 번 테스트 실행

   각 테스트 사이에는 5초를 두세요. 실제 지연 세 번의 편차가 50ms보다 작다면 현재 연결 상태가 비교적 안정적이라는 뜻입니다.

3. 애플리케이션 트래픽 확인

   브라우저, 시스템 프록시, 별도로 설정한 애플리케이션을 점검하여 프록시 유형과 포트가 클라이언트 설정과 일치하는지 확인하세요.

4. 유효한 기록 보관

   오류 발생 시간, 핵심 로그, 수정 항목을 저장하고 이미 만료된 구독 설정을 장기 구성으로 보관하지 마세요.