노드 연결 시간 초과는 어느 한 단계가 제때 완료되지 않았다는 뜻일 뿐, 서버가 오프라인이라고 단정할 수는 없습니다. v2rayN이나 v2rayNG에서 속도 측정 시간 초과, 연결 오류, 웹페이지 접속 불가를 겪는 사용자를 위한 안내입니다. ‘문제 범위 확인 → 시간 동기화 및 구독 업데이트 → 로그 확인 → 전송·TLS 설정 점검 → 서버 확인’ 순서로 진행하고, 한 번에 한 가지 조건만 바꾸세요. 마지막으로 운영자에게 전달할 문제 해결 기록을 정리합니다.
1. 먼저 확인할 것: 노드 시간 초과인가요, 앱 트래픽이 프록시를 거치지 않는 건가요?
오류가 어느 단계에서 발생하는지 먼저 확인한 뒤 조치 방법을 정하세요. 목록에서 실행하는 지연 시간 테스트, 커널의 서버 연결, 브라우저의 웹사이트 접속은 서로 다른 작업입니다. 테스트 대상 주소에 접속할 수 없어도 정상 노드가 시간 초과로 표시될 수 있습니다. 반대로 TCP 포트 연결에 성공해도 인증, TLS 핸드셰이크, 프록시 전달까지 정상이라는 뜻은 아닙니다.
| 확인된 증상 | 우선 점검 항목 | 아직 단정할 수 없는 내용 |
|---|---|---|
| 지연 시간 테스트만 시간 초과되고 웹페이지는 열림 | 테스트 URL, 테스트 방식, 해당 URL의 라우팅 | 이 결과만으로 노드가 작동하지 않는다고 단정할 수 없음 |
| 모든 노드가 동시에 실패 | 로컬 네트워크, 시스템 시간, 커널 실행 여부 | 모든 서버에 동시에 문제가 생겼다고 단정할 수 없음 |
| 노드 하나만 실패 | 해당 노드 설정, 원격 포트, 계정 상태 | 한 번의 실패만으로 계속 사용할 수 없다고 판단할 수 없음 |
| 브라우저에서는 되지만 터미널에서는 안 됨 | 터미널의 프록시 환경 변수 또는 명시적 프록시 설정 | 대개 노드 시간 초과가 원인은 아님 |
최소한의 재현 조건을 만들면 관련 없는 변수를 줄일 수 있습니다. 클라이언트는 하나만 실행하고, 노드 하나와 실제로 접속할 수 있는 테스트 URL 하나를 정한 뒤 테스트 시간을 기록하세요. 라우팅, DNS, TUN, 전송 프로토콜을 한꺼번에 바꾸지는 마세요. v2rayNG는 Android VPN 서비스를 사용해 트래픽을 처리하므로 연결 스위치가 켜져 있는지, 다른 VPN 서비스가 연결을 사용 중인지 확인해야 합니다.
2. 시스템 시간을 확인한 다음 구독 업데이트
인증이나 인증서 오류를 판단하기 전에 시스템 시간부터 정확하게 맞추세요. VMess 인증에는 시간이 사용되므로 시스템 시간이 크게 어긋나면 연결 오류가 발생할 수 있습니다. TLS 인증서의 유효 기간도 기기 시계를 기준으로 확인합니다. VLESS에 VMess의 시간 인증 방식을 그대로 적용해서는 안 되지만, TLS를 사용하는 경우에는 여전히 시간이 정확해야 합니다. 시간대 표시만 바꿔서는 잘못된 시스템 시간을 바로잡을 수 없습니다.
-
시스템 시간 동기화
Windows에서 ‘설정’ → ‘시간 및 언어’ → ‘날짜 및 시간’을 열고 자동 시간 설정을 켠 뒤 ‘지금 동기화’를 선택하세요. Android에서는 시스템 설정에서 ‘날짜 및 시간’을 검색하고 자동 시간 설정을 켭니다. 기기에 따라 메뉴 위치가 다를 수 있습니다.
-
현재 구독 업데이트
v2rayN에서는 ‘구독 그룹’ 메뉴에서 현재 구독을 업데이트하세요. 먼저 ‘현재 구독 업데이트(프록시 사용 안 함)’를 시도할 수 있습니다. v2rayNG에서는 메인 화면 오른쪽 위 메뉴에서 ‘현재 그룹 구독 업데이트’를 선택합니다. 버전에 따라 메뉴 문구가 조금씩 다를 수 있으므로, 업데이트 버튼을 눌렀는지만 보지 말고 결과를 확인하세요.
-
노드 다시 선택
업데이트한 뒤 대상 노드를 다시 선택해 연결하고 서버 주소와 포트가 바뀌었는지 확인하세요. 구독 업데이트 성공이 노드 연결 성공을 뜻하지는 않습니다. 구독 서버와 노드 서버는 주소와 네트워크 경로가 완전히 다를 수 있습니다.
-
한 번의 실패 기록
현재 시간을 기록하고 한 번 접속을 시도한 직후 로그를 확인하세요. 해당 작업 전후의 기록만 남기면 대량 속도 측정으로 쌓인 오류가 실제 연결 문제를 가리는 일을 줄일 수 있습니다.
3. 커널 로그 확인: 의미 있는 첫 오류 찾기
마지막 timeout만 검색하지 말고 로컬 실행 오류부터 원격 연결 오류까지 로그를 확인하세요. v2rayN에서는 먼저 메인 화면 하단의 로그 또는 정보 영역을 살펴보세요. 자세한 내용이 필요하면 ‘설정’ → ‘매개변수 설정’에서 로그 레벨 관련 항목을 찾습니다. v2rayNG에서는 메인 화면 오른쪽 위 메뉴에서 ‘로그’를 열 수 있습니다. 버전에 따라 메뉴 위치와 로그 레벨 이름이 다르므로 클라이언트 버전과 로그에 표시된 커널 버전을 함께 기록하세요.
로그 레벨을 잠시 높인 뒤 연결을 다시 시작하고 한 번 재현하면 됩니다. 디버그 로그에는 접속 도메인이나 서버 주소 등이 포함될 수 있으므로 점검을 마친 뒤 평소 로그 레벨로 되돌리세요. 아래는 자주 나타나는 오류 예시입니다. 커널에 따라 연결 ID, 대상 주소 또는 더 자세한 문맥이 추가될 수 있습니다.
오류: address already in use
원인: 로컬 수신 주소나 포트가 이미 사용 중이어서 커널이 제대로 시작되지 않았을 수 있습니다.
해결: 중복 실행된 클라이언트를 종료하고 포트를 사용 중인 프로세스를 확인하세요. 로컬 포트를 변경했다면 앱에 설정한 프록시 포트도 함께 바꿔야 합니다.
오류: no such host
원인: 도메인 이름 확인에 실패했습니다. 노드 도메인일 수도 있고 접속 대상 도메인일 수도 있습니다.
해결: 오류에 표시된 도메인을 먼저 확인하고 철자와 실제 DNS 경로를 점검하세요. 노드 도메인을 확인할 수 없다면 연결을 시작하기 전에 DNS 문제부터 해결해야 합니다.
오류: i/o timeout
원인: 연결 또는 읽기·쓰기 작업이 시간 초과된 상태입니다. 이 메시지만으로는 패킷 손실, 원격 차단, 핸드셰이크 단계의 무응답을 구분할 수 없습니다.
해결: 전후 로그에 표시된 대상 주소와 핸드셰이크 기록을 살펴 발생 단계를 파악한 뒤 원격 포트, 전송 설정, 서버 상태를 각각 확인하세요.
오류: x509: certificate has expired or is not yet valid
원인: 로컬 시간이 잘못되었거나 원격 인증서의 유효 기간이 실제로 만료되었거나 아직 시작되지 않았습니다.
해결: 먼저 로컬 시간을 동기화하세요. 시간이 정상인데도 오류가 계속되면 운영자가 인증서 유효 기간과 리버스 프록시에 실제로 적용된 인증서를 확인해야 합니다.
정리: 로컬 실행 오류를 먼저 해결한 뒤 원격을 확인하세요
로그에 수신 포트 충돌이 표시되고 커널이 정상적으로 시작된 기록이 없다면 충돌부터 해결해야 합니다. 이때 서버 주소, TLS, 구독 설정을 계속 바꿔도 로컬 수신 오류는 해결되지 않습니다.
4. 로컬 수신 포트와 원격 포트를 따로 확인
로컬 프록시 포트와 서버 포트는 구분해야 합니다. 앱이 먼저 로컬 프록시에 연결하고, 커널이 이어서 원격 서버에 연결합니다. 아래 숫자는 두 연결 구간을 설명하기 위한 예시이며 모든 설치의 기본값을 뜻하지 않습니다. 특히 v2rayN의 HTTP, SOCKS, 혼합 수신 방식은 현재 매개변수 설정을 기준으로 확인하세요.
Windows PowerShell에서는 아래 대화형 명령으로 원격 TCP 포트를 테스트할 수 있습니다. 노드 편집 화면에 표시된 서버 주소와 원격 포트를 입력하세요. 구독 URL이나 로컬 프록시 포트가 아닙니다. TcpTestSucceeded가 true라면 TCP 연결이 성립했다는 뜻일 뿐, 프록시 프로토콜 인증까지 통과했다는 뜻은 아닙니다. UDP 전송은 이 테스트만으로 전체 상태를 판단할 수 없습니다.
$nodeHost = Read-Host "노드 서버 도메인 또는 IP를 입력하세요"
$nodePort = [int](Read-Host "노드 원격 포트를 입력하세요")
Test-NetConnection -ComputerName $nodeHost -Port $nodePort터미널 트래픽이 실제로 로컬 SOCKS 진입점을 거치는지 확인하려면 로컬 수신 주소가 127.0.0.1:10808인지 확인한 뒤 아래 명령을 실행하세요. 테스트 URL은 직접 입력합니다. socks5h는 대상 도메인 처리를 프록시 측에 맡긴다는 뜻이며, 로컬 DNS가 정상인지 직접 확인하는 방법은 아닙니다. 명령의 15초는 이번 테스트의 제한 시간일 뿐 노드 성능 기준이 아닙니다.
$testUrl = Read-Host "테스트에 사용할 전체 HTTPS URL을 입력하세요"
curl.exe --proxy socks5h://127.0.0.1:10808 --connect-timeout 15 --max-time 30 -I $testUrl- 로컬 포트 연결이 거부됨: 커널이 실행 중인지, SOCKS 포트가 명령에 지정된 값과 일치하는지 확인하세요.
- 원격 TCP 연결은 성공했지만 프록시 요청은 실패함: 인증, TLS, 전송 설정, 아웃바운드 라우팅을 계속 확인하세요. 포트 테스트만으로 점검을 끝내면 안 됩니다.
- 같은 노드가 다른 네트워크에서는 작동함: 클라이언트를 바로 재설치하지 말고 현재 네트워크의 DNS, IPv4·IPv6 연결 상태, 외부 연결 제한을 먼저 비교하세요.
5. 전송, TLS, REALITY 설정을 하나씩 확인
서버 주소와 UUID만 비교하지 말고 설정을 한 묶음으로 확인해야 합니다. 구독에는 보통 프로토콜, 전송, 보안 계층 정보가 포함됩니다. 수동으로 수정하거나 다른 커널로 옮긴 뒤 한 항목이라도 호환되지 않으면 핸드셰이크가 실패할 수 있습니다. v2rayNG는 Xray 커널을, v2flyNG는 v2fly 커널을 사용하므로 두 커널이 같은 프로토콜 확장과 설정 항목을 모두 지원한다고 가정해서는 안 됩니다.
| 설정 그룹 | 확인할 항목 | 혼동하기 쉬운 점 |
|---|---|---|
| 프로토콜 및 인증 | VMess 또는 VLESS, UUID, 서버에서 허용하는 설정 | 프로토콜 이름만 바꾸고 나머지 항목을 그대로 사용해서는 안 됩니다 |
| WebSocket | 전송 유형, 경로, Host, 리버스 프록시 전달 위치 | 경로의 대소문자와 슬래시까지 확인하세요. Host는 서버 주소와 다릅니다. |
| gRPC | serviceName, TLS, 리버스 프록시의 HTTP/2 지원 여부 | serviceName은 WebSocket 경로 항목이 아닙니다 |
| TLS | serverName／SNI, 인증서 도메인, 유효 기간, ALPN 요구 사항 | IP 주소로 연결해도 인증서 이름은 예상한 도메인과 일치해야 합니다 |
| REALITY 및 Vision | 서버에서 제공한 공개 키, shortId, serverName, 지문, flow | Vision을 사용하는 설정의 flow는 서버 요구 사항에 맞춰야 합니다. 임의로 입력하지 마세요. |
설정을 변경한 뒤 다시 불러오고 로그가 새 연결에 해당하는지 확인하세요. v2rayN에서는 현재 서비스를 중지한 뒤 다시 시작하고, v2rayNG에서는 연결 스위치를 껐다가 다시 켭니다. 구독을 새로고침하면 수동 변경 사항이 덮어써질 수 있으므로 변경 내용을 기록해 두고, 매번 업데이트 후 다시 수정하기보다 제공자에게 구독 설정 수정을 요청하세요.
6. 마지막으로 서버 상태와 네트워크 경로 확인
로컬 실행, 구독 설정, 핸드셰이크 조건을 모두 확인한 뒤라야 서버 관련 증거를 해석하기 쉽습니다. 서버 관리 권한이 없다면 제공자에게 발생 시각, 노드 식별 정보, 네트워크 유형, 민감 정보를 가린 로그를 전달하고 서비스 수신 상태, 계정 만료일, 진입점 변경 여부를 문의하세요. 전체 구독 URL이 보이는 오류 화면을 공개하지 마세요.
- 수신 상태 확인: 관리자는
ss -lntp로 TCP 수신을,ss -lnup로 UDP 수신을 확인하고 실제 프로세스와 바인딩 주소, 설정 포트가 일치하는지 점검할 수 있습니다. - 허용 규칙 확인: 클라우드 플랫폼의 보안 그룹과 시스템 방화벽은 별도의 제어 계층입니다. 필요한 포트와 전송 유형만 허용하고, 문제를 해결하기 위해 방화벽 전체를 장기간 꺼 두지 마세요.
- 리버스 프록시 확인: 리버스 프록시가 연결을 받는 구조라면 업스트림 주소, 경로, 서비스 이름을 확인하고 액세스 로그와 커널 로그의 시간을 대조하세요.
- 듀얼 스택 차이 확인: 도메인에 A 및 AAAA 레코드가 있다면 IPv4와 IPv6 모두 접속 가능한지 각각 확인하세요. 한 주소 체계만 작동하지 않는다면 해당 진입점이나 DNS 레코드를 먼저 수정해야 합니다.
- 리소스 및 정책 확인: 프로세스가 반복해서 종료되지 않는지, 디스크와 메모리가 부족하지 않은지 확인하고 계정 트래픽 한도, 만료 상태, 서버 연결 제한도 점검하세요.
정리: 네트워크를 바꿔 교차 테스트해 범위를 좁히세요
같은 설정이 가정용 네트워크에서는 실패하고 모바일 네트워크에서는 성공한다면 네트워크 경로부터 비교하세요. 같은 네트워크에서 다른 노드는 정상인데 특정 노드만 실패한다면 해당 진입점을 우선 확인해야 합니다. 두 가지 비교 모두 클라이언트를 계속 재설치하는 것보다 진단에 도움이 됩니다.
7. 계속 시간 초과되나요? 아래 질문으로 확인 내용을 보완하세요
지연 시간 테스트는 계속 시간 초과되는데 웹페이지는 열립니다. 노드를 바꿔야 하나요?
우선 바꾸지 마세요. 속도 측정에 사용된 URL과 테스트 방식을 확인하고 같은 URL에 실제로 접속해 보세요. 테스트 대상만 별도로 라우팅되거나 요청이 거부되거나 일시적으로 접속 불가 상태라면 테스트 결과와 평소 접속 결과가 다를 수 있습니다.
v2rayNG에 연결됨으로 표시되는데 왜 웹페이지가 열리지 않나요?
연결됨 표시는 대개 로컬 VPN 서비스가 시작되었다는 뜻이지 모든 원격 요청이 성공했다는 뜻은 아닙니다. 오른쪽 위 메뉴에서 ‘로그’를 열고 요청을 한 번 실행한 뒤 원격 연결 또는 핸드셰이크 오류가 있는지 확인하세요. 분할 터널링 설정에서 대상 앱이 제외되었는지도 확인해야 합니다.
컴퓨터에서는 되는데 휴대폰에서 같은 노드가 시간 초과됩니다. 어떤 설정을 비교해야 하나요?
먼저 두 기기가 같은 최신 구독과 같은 네트워크를 사용하는지 확인한 뒤 전송 유형, SNI, 경로 또는 serviceName, REALITY 설정, flow를 하나씩 비교하세요. 두 기기의 커널 버전도 기록해야 합니다. 로컬 인바운드와 시스템 트래픽 처리 방식이 다르므로 데스크톱 설정 전체를 그대로 복사하지 마세요.
시간 초과 대기 시간을 늘리면 해결되나요?
응답이 느린 경우와 계속 실패하는 경우를 구분하는 데는 도움이 되지만, 잘못된 포트, 인증 실패, 인증서 문제를 해결하지는 못합니다. 기존 설정을 보존하고 고정된 테스트 제한 시간으로 재현하세요. 로그에 핸드셰이크 오류가 계속 표시된다면 대기 시간만 늘리지 말고 해당 설정을 수정해야 합니다.
도움을 요청할 때는 재현 가능한 절차를 정리하는 것이 가장 유용합니다. 클라이언트 및 커널 버전, 발생 시각과 시간대, Wi-Fi 또는 모바일 네트워크 사용 여부, 모든 노드 또는 특정 노드의 실패 여부, 원격 포트 테스트 결과, 단일 연결 실패 전후의 로그를 적어 주세요. 공유 전 UUID, 구독 토큰, 기타 인증 정보를 가리세요. 서버 주소를 전달해야 한다면 신뢰할 수 있는 비공개 채널을 사용하세요.