노드 속도 테스트 시간 초과, 실행 후 연결 실패, 네트워크 변경 뒤 갑자기 연결되지 않는 경우에 참고하세요. 먼저 로컬 리스닝, 서버 포트, 프로토콜 핸드셰이크 문제를 구분하고 시간·전송·TLS 설정을 확인한 다음, 한 번의 요청에 해당하는 로그로 원인을 좁힙니다. macOS는 v2rayN, Android는 v2rayNG를 예로 들었습니다. 포트 번호는 예시이므로 실행 전 실제 클라이언트 설정에 맞게 바꾸세요.
1. 먼저 시간 초과가 발생하는 단계 확인하기
‘노드 연결 시간 초과’는 한 가지 원인만을 뜻하지 않습니다. TCP 포트 연결 실패, TLS 핸드셰이크 오류, 프록시 인증 실패, 테스트 사이트의 응답 지연도 모두 화면에 시간 초과로 표시될 수 있습니다. 어떤 작업에서 문제가 발생하는지 먼저 기록하세요. 구독 업데이트인지, 서버의 실제 연결 지연 시간 테스트인지, 브라우저에서 웹페이지를 여는 작업인지 확인합니다. 구독 다운로드 실패가 구독에 포함된 모든 노드의 오류를 의미하지는 않습니다.
점검할 때는 노드 하나, 테스트 주소 하나, 연결 방식 하나로 조건을 고정하세요. 데스크톱에서는 먼저 TUN을 끄고 명시적 프록시로 로컬 진입점을 테스트합니다. Android에서는 다른 VPN 서비스가 연결을 가로채지 않도록 v2rayNG만 실행하세요. DNS, 라우팅, 노드, 코어를 한꺼번에 바꾸면 연결이 복구되어도 어떤 설정이 원인이었는지 확인하기 어렵습니다.
| 증상 | 우선 확인할 항목 | 이 증상만으로 단정할 수 없는 내용 |
|---|---|---|
| 로컬 프록시 포트 연결 거부 | 코어 실행 여부와 리스닝 주소·포트 | 원격 노드가 작동하지 않음 |
| 서버 TCP 포트 연결 시간 초과 | 주소 확인, 포트, 네트워크 경로, 방화벽 | UUID 또는 비밀번호 오류 |
| 포트 연결은 되지만 실제 요청 실패 | TLS, 전송 방식, 인증, 서버 측 연결 | 전체 연결 경로가 정상 |
| 테스트 사이트 하나만 접속 실패 | 테스트 주소, 대상 사이트, 라우팅 규칙 | 모든 프록시 요청 실패 |
2. 기기 시간과 기본 네트워크 확인하기
먼저 시간을 맞춘 다음 인증서를 확인하세요. macOS에서 ‘시스템 설정’ → ‘일반’ → ‘날짜 및 시간’을 열고 자동 시간 설정을 켠 뒤 날짜, 연도, 시간대가 올바른지 확인합니다. Android에서는 일반적으로 ‘설정’ → ‘시스템’ → ‘날짜 및 시간’에서 설정할 수 있으며, 기기에 따라 ‘추가 설정’에 있을 수 있습니다. 자동 시간과 시간대 설정을 켜세요. 시간을 맞춘 뒤 클라이언트를 다시 실행하고 연결을 테스트합니다.
시스템 시간이 잘못되면 인증서 유효 기간 판정에 문제가 생기고 VMess 인증에도 영향을 줄 수 있습니다. 시간대만 바꾸고 실제 시간이 틀린 상태라면 문제가 해결되지 않습니다. 자동 시간 설정을 켜도 시간이 계속 크게 어긋난다면 먼저 시스템 시간 동기화가 인터넷에 연결되는지 확인하세요. 시간 오류를 가리기 위해 인증서 검증을 끄지 마세요.
-
테스트 조건 고정하기
노드 하나를 선택하고 현재 네트워크, 테스트 주소, 오류 발생 시간을 기록하세요. 요청이 다른 경로로 전환되지 않도록 다른 프록시나 VPN 서비스는 중지합니다.
-
시스템 시간 맞추기
시스템의 ‘날짜 및 시간’ 화면에서 자동 설정을 켜세요. 날짜와 시간이 올바른지 확인한 다음 v2rayN 또는 v2rayNG를 종료했다가 다시 실행합니다.
-
직접 연결 네트워크 확인하기
프록시를 일시 중지하고 현재 네트워크에서 직접 접속할 수 있는 사이트를 엽니다. 공용 Wi-Fi에 인증 페이지가 표시되면 먼저 인증을 완료하세요. 기본 네트워크가 연결되지 않는 동안에는 노드 설정을 바꾸지 마세요.
-
네트워크를 바꿔 다시 테스트하기
노드와 설정은 그대로 둔 채 휴대폰 핫스팟으로 바꿔 테스트합니다. 네트워크를 바꾼 뒤에만 연결된다면 기존 네트워크의 포트 제한, DNS 또는 외부 연결 정책을 우선 확인하세요.
3. 로컬 리스닝과 원격 포트를 나눠 테스트하기
로컬 리스닝 포트와 노드 서버 포트는 서로 다릅니다. 로컬 포트는 브라우저나 명령줄 도구가 클라이언트에 연결할 때 사용하고, 원격 포트는 클라이언트가 서버에 연결할 때 사용합니다. 아래에서는 로컬 SOCKS 포트 10808과 원격 TLS 포트 443을 예로 듭니다. 모든 설치 환경의 기본값이 같다는 뜻은 아닙니다.
v2rayN의 ‘설정’ → ‘매개변수 설정’에서 로컬 리스닝 관련 항목을 확인하세요. 항목의 그룹명은 버전에 따라 다를 수 있으므로 실제 화면을 기준으로 확인합니다. 코어를 실행한 다음 macOS의 ‘터미널’에서 아래 명령을 실행하세요. 두 번째 명령은 실제 포트에서 SOCKS 서비스를 제공하는 경우에만 사용합니다. HTTP 전용 포트를 SOCKS 매개변수에 입력하지 마세요.
# 예시 로컬 포트에서 프로세스가 리스닝 중인지 확인
lsof -nP -iTCP:10808 -sTCP:LISTEN
# 로컬 SOCKS를 명시해 HTTPS 요청 보내기
curl --proxy socks5h://127.0.0.1:10808 \
--connect-timeout 5 --max-time 10 \
--output /dev/null --show-error --verbose https://example.com/socks5h는 대상 도메인의 확인을 SOCKS 프록시에 맡겨, 이번 요청에서 앱이 도메인을 확인하는 방식의 차이를 배제하는 데 유용합니다. 그렇다고 모든 DNS 요청이 원격에서 처리된다는 뜻은 아닙니다. 노드 서버 주소의 확인 방식은 여전히 코어와 시스템 설정에 따라 달라집니다. 테스트 주소는 접속하려는 HTTPS 사이트로 바꿔도 됩니다.
- 리스닝 결과가 없음: 먼저 코어 시작 로그를 확인하세요. 설정을 불러오지 못했거나 포트가 이미 사용 중이면 로컬 진입점이 만들어지지 않았을 수 있습니다.
- 로컬 진입점에는 연결되지만 프록시 요청 시간 초과: 원격 주소와 포트를 확인한 다음 핸드셰이크 설정을 점검하세요.
- 명시적 프록시는 되지만 브라우저에서는 실패: 시스템 프록시, 브라우저 프록시 확장 프로그램, 라우팅을 확인하세요. 곧바로 노드를 다시 만들 필요는 없습니다.
- 원격 포트 확인: macOS에서는
nc -vz -G 5뒤에 실제 서버 도메인과 포트를 입력해 실행할 수 있습니다. TCP 연결에 성공해도 포트에 도달할 수 있다는 뜻일 뿐, 프로토콜이나 계정이 유효하다는 의미는 아닙니다.
정리: 명시적 프록시로 문제 구간 나누기
같은 노드로 위의 curl 요청이 성공하면 노드 설정은 그대로 두세요. 서버 설정까지 한꺼번에 바꾸기보다 앱 트래픽이 클라이언트에 들어오는 경로만 수정해야 결과를 검증하기 쉽습니다.
4. 전송·TLS·SNI 설정을 항목별로 대조하기
포트에는 연결되지만 요청이 실패한다면 노드 편집 화면을 열어 서비스 제공업체가 안내한 원래 설정과 항목별로 대조하세요. v2rayN에서는 보통 노드를 더블클릭해 편집할 수 있고, v2rayNG에서는 구성 목록의 노드 옆 편집 메뉴를 사용합니다. 구독 노드는 먼저 구독을 업데이트한 뒤 설정을 확인하세요. 직접 수정하기 전에는 원래 설정을 보관해 다음 업데이트에서 변경 사항이 덮어써지지 않도록 합니다.
| 점검 항목 | 확인할 내용 | 자주 하는 실수 |
|---|---|---|
| 프로토콜 및 인증 정보 | VMess, VLESS, Trojan 또는 Shadowsocks 유형과 해당 UUID, 비밀번호 또는 암호화 방식 | 주소와 포트가 같다는 이유로 같은 유형의 노드라고 판단 |
| 전송 유형 | TCP, WebSocket, gRPC 등. 서버 설정과 일치해야 함 | 전송 유형을 속도 향상 옵션처럼 임의로 변경 |
| WebSocket | 경로, Host, TLS 설정 | 경로 앞의 슬래시를 빠뜨리거나 경로 매개변수를 임의로 삭제 |
| gRPC | 서비스 이름, TLS 및 서버에서 요구하는 ALPN | WebSocket 경로를 서비스 이름에 그대로 입력 |
| TLS | 서버 이름 SNI, 인증서 체인, 유효 기간 | 연결 주소를 IP로 바꾸면서 SNI도 IP로 변경 |
| REALITY | 공개 키, shortId, serverName, 지문 및 해당되는 flow | UUID만 복사하고 보안 계층 설정은 빠뜨림 |
SNI는 TLS 핸드셰이크에 사용되는 서버 이름이며 연결 주소와 같을 필요는 없습니다. 연결 주소가 IP여도 SNI에는 서버가 지정한 도메인을 사용해야 할 수 있습니다. WebSocket의 Host는 HTTP 계층에 속합니다. SNI와 값이 같은 경우가 많더라도 두 항목을 같은 설정으로 취급해서는 안 됩니다.
5. 같은 요청의 연결 로그로 원인 찾기
먼저 v2rayN 기본 화면의 로그 영역이나 v2rayNG 메뉴의 ‘로그’를 엽니다. 이전 기록을 지우거나 현재 시각을 적어 둔 뒤 테스트를 한 번만 실행하세요. 일반 로그에서 원인을 찾기 어렵다면 잠시 디버그 수준으로 바꾸고 문제를 재현한 다음 원래 수준으로 되돌립니다. 메뉴 이름은 버전에 따라 다를 수 있으므로 로그 수준 항목을 확인하고 다른 버전의 화면 안내를 그대로 따르지 마세요.
오류: connection refused
원인: 대상 포트에서 연결을 받지 않거나 중간 장비가 연결을 거부한 경우입니다. 오류에 표시된 주소가 로컬인지 원격인지 먼저 확인해야 합니다.
해결: 로컬 주소에서 오류가 나면 코어와 리스닝 포트를 확인하세요. 원격 주소에서 오류가 나면 서버 포트를 확인하고 서비스 제공업체에 리스닝 서비스와 방화벽 점검을 요청합니다.
오류: i/o timeout
원인: 제한 시간 내에 어떤 단계의 읽기 또는 쓰기가 완료되지 않았다는 뜻입니다. 이 메시지만으로는 패킷 손실, 포트 연결 불가, 핸드셰이크 무응답을 구분할 수 없습니다.
해결: 직전 로그에서 대상 주소와 작업 단계를 확인하세요. 먼저 포트를 테스트한 뒤 설정은 그대로 둔 채 네트워크를 바꿔 다시 재현합니다.
오류: x509: certificate has expired or is not yet valid
원인: 인증서 유효 기간과 현재 시스템 시간이 일치하지 않습니다. 기기 시간이 잘못됐거나 원격 인증서가 만료됐을 수 있습니다.
해결: 먼저 시스템 시간을 맞추세요. 시간이 올바른데도 오류가 계속되면 오류 발생 시각을 서비스 제공업체에 전달해 인증서 배포 상태를 확인합니다.
오류: tls: handshake failure
원인: 상대편에서 TLS 협상을 거부했습니다. SNI, 프로토콜 협상 또는 잘못된 서비스에 연결했을 가능성이 있습니다.
해결: 원래 설정과 포트, TLS 사용 여부, SNI, ALPN을 대조하세요. 시간 초과 값만 늘려서는 해결되지 않습니다.
오류: no such host
원인: 로그에 표시된 도메인을 확인하지 못했습니다. 노드 서버 주소일 수도 있고 대상 사이트 주소일 수도 있습니다.
해결: 먼저 어떤 도메인인지 확인한 다음 철자, DNS 확인 서버 연결 여부, 해당 DNS 분기 설정을 점검하세요. 모든 도메인의 확인 경로를 하나로 바꾸지 마세요.
로그의 EOF는 연결이 종료됐다는 뜻일 뿐 계정이 유효하지 않다는 증거는 아닙니다. 앞서 나온 핸드셰이크 정보와 특정 노드에서만 실패하는지도 함께 확인하세요. 로그를 공유할 때는 구독 링크, UUID, 비밀번호, 토큰, 개인 네트워크 정보를 숨기고 필요한 오류 단계, 시각, 설정 유형만 남기세요.
6. 코어 호환성과 Android 백그라운드 제한 확인하기
v2rayN과 v2rayNG는 클라이언트이며 실제 프로토콜 처리는 코어가 담당합니다. 화면에서 어떤 항목을 가져올 수 있다고 해서 현재 코어가 반드시 지원하는 것은 아닙니다. v2rayNG는 Xray 코어를 사용하고 v2flyNG는 v2fly 코어를 사용하므로 두 코어가 확장 설정을 똑같이 지원한다고 가정할 수 없습니다. 특히 REALITY나 최신 전송 항목을 사용하는 경우 클라이언트와 코어 버전을 모두 확인하세요.
- 두 버전 모두 기록: ‘정보’에서 클라이언트 버전을 확인하고 시작 로그에서 코어 버전을 확인하세요. 기기마다 설치 경로와 업데이트 시점이 다를 수 있으므로 ‘최신 버전’이라고만 적지 마세요.
- 시작 단계 확인: 알 수 없는 필드, 전송 구성 실패, 설정 분석 오류가 나타나면 반복해서 속도를 측정하지 말고 호환성과 설정 문제부터 해결하세요.
- 함께 업데이트: 설정을 보관한 뒤 클라이언트와 함께 제공되는 코어를 업데이트하세요. 호환되지 않는 코어 파일을 구버전 디렉터리에 직접 덮어쓰지 마세요.
- Android 배터리 설정 확인: v2rayNG 아이콘을 길게 눌러 ‘앱 정보’ → ‘배터리’로 이동하고 기기에서 제공하는 옵션에 따라 필요한 백그라운드 실행을 허용하세요. 화면을 잠그거나 앱을 백그라운드로 전환한 뒤에만 연결이 끊길 때 우선 확인할 항목입니다.
- 백그라운드 종료와 핸드셰이크 실패 구분: VPN 표시가 사라지거나 서비스가 중지되면 프로세스 또는 시스템 관리 문제입니다. 서비스가 계속 실행 중인데 로그에 핸드셰이크 오류가 반복된다면 노드 설정을 확인하세요.
정리: 확인된 호환성 문제에 맞춰 업데이트하기
포트에 연결할 수 없다면 먼저 네트워크 경로를 복구하세요. 로그에 설정 미지원이 명확히 표시된 경우에만 클라이언트와 함께 제공되는 코어를 업데이트합니다. 근거가 확인된 단계에서 업데이트하면 새로운 변수가 생기는 일을 줄일 수 있습니다.
7. 한 번에 한 항목씩 재테스트하고 결과 기록하기
매번 한 항목만 수정하고 코어를 다시 시작한 뒤 같은 테스트 주소를 사용하세요. 연속 세 번 성공하면 이번 수정이 효과가 있었을 가능성을 확인할 수 있지만 장기적인 안정성을 보장하지는 않습니다. 원래 네트워크와 앱을 사용해 평소 이용 시간대에도 상태를 확인하세요. 시간 제한을 늘리면 응답이 느린 경우 더 오래 기다릴 뿐, 잘못된 SNI, 유효하지 않은 인증 정보, 열리지 않은 포트는 해결되지 않습니다.
| 확인 결과 | 다음 조치 |
|---|---|
| 같은 노드가 핫스팟에서는 정상이고 기존 네트워크에서는 실패 | 노드 설정은 유지하고 기존 네트워크의 외부 연결, DNS 확인, 포트 정책 점검 |
| 같은 네트워크의 다른 노드는 정상이고 특정 노드 하나만 실패 | 해당 구독을 업데이트하고 서비스 제공업체에 노드 상태와 설정 확인 요청 |
| 명시적 프록시는 정상이고 시스템 프록시를 통한 접속은 실패 | 시스템 프록시 포트, 앱 프록시 설정, 브라우저 확장 프로그램 확인 |
| 여러 네트워크에서 모두 실패하고 설정도 확인 완료 | 민감 정보를 가린 로그와 버전 정보를 전달해 서비스 제공업체에 서버 로그 확인 요청 |
문제를 문의할 때 발생 시각과 시간대, 시스템 버전, 클라이언트 버전, 코어 버전, 프로토콜과 전송 유형, ‘기존 네트워크에서는 실패하고 핫스팟에서는 성공’ 같은 비교 결과를 적으세요. 전체 구독 링크를 보내거나 공개 토론 공간에 노드 비밀번호를 게시하지 마세요. 한 번의 요청을 재현한 결과와 해당 로그가 ‘시간 초과’만 표시된 스크린샷보다 원인 파악에 도움이 됩니다.