v2rayNG에 노드를 가져왔지만 연결 시간 초과가 발생하거나, 실제 연결 테스트에 실패하거나, 브라우저에서 웹사이트를 열 수 없는 경우에 적용할 수 있습니다. 기존 설정은 그대로 둔 채 같은 노드로 네트워크별 차이를 비교하고, 시간·구독·전송 설정·인증서를 차례로 확인한 뒤 서버의 리스닝 상태와 로그를 살펴보세요. 한 번에 하나씩만 변경해야 포트 연결 불가, 인증 실패, DNS 문제를 같은 원인으로 혼동하지 않습니다.
1. 시간 초과가 발생하는 단계부터 확인
v2rayNG는 Android 클라이언트입니다. 이 글에서는 Xray 코어를 사용하는 설정을 기준으로 문제를 점검합니다. 화면의 연결 아이콘은 로컬 서비스가 실행 중이라는 뜻이지, 원격 노드와의 핸드셰이크까지 완료됐다는 뜻은 아닙니다. 노드 목록의 TCP 테스트, 실제 연결 테스트, 브라우저 접속은 각각 확인하는 단계가 다르므로 서로 대신할 수 없습니다.
먼저 메인 화면에서 대상 노드를 선택하고 서비스를 시작한 다음, 메뉴에서 ‘로그’를 열어 실패 상황을 한 번 재현하고 발생 시간을 기록하세요. 메뉴 이름은 버전에 따라 다를 수 있으며, 테스트 항목은 보통 메인 화면 메뉴에 있습니다. 오류가 표시되면 앞뒤 로그도 함께 저장하되 구독 주소, 사용자 식별 정보, 비밀번호는 가려야 합니다.
| 확인 결과 | 알 수 있는 점 | 다음 단계 |
|---|---|---|
| TCP 테스트 실패 | 대상 주소와 TCP 포트에 연결할 수 없는 상태입니다. UDP 전용 전송을 판단하는 데는 사용할 수 없습니다. | 네트워크, 도메인 조회, 포트를 확인하세요. |
| TCP 성공, 실제 연결 실패 | 포트는 응답하지만 프록시 핸드셰이크 또는 테스트 요청이 완료되지 않았습니다. | 프로토콜, TLS, 전송 설정을 확인하세요. |
| 실제 연결 성공, 특정 앱만 실패 | 테스트 대상에 접속할 수 있어도 모든 앱의 트래픽이 프록시를 통과하는 것은 아닙니다. | 앱별 프록시 설정, 라우팅, 앱 자체 설정을 확인하세요. |
| 구독 업데이트 실패 | 구독 내용을 가져오는 요청이 실패했습니다. | 구독 주소를 별도로 점검하세요. 노드가 사용할 수 없다고 단정하지 마세요. |
2. 로컬 네트워크: 같은 노드로 Wi-Fi와 모바일 데이터를 비교
먼저 v2rayNG를 중지하고 브라우저에서 평소 직접 접속하는 웹사이트가 열리는지 확인하세요. 공용 Wi-Fi는 시스템에 표시되는 인증 페이지에서 먼저 로그인해야 할 수 있습니다. 인증을 마치지 않으면 프록시 연결도 대개 설정되지 않습니다. 그다음 노드와 설정은 그대로 둔 채 Wi-Fi와 모바일 데이터에서 각각 서비스를 시작해 보세요.
- Wi-Fi에서만 실패하는 경우: 라우터의 인터넷 연결 상태, 인증 페이지, 해당 네트워크의 DNS를 확인하세요. 모바일 데이터에서는 정상이라면 노드의 UUID, 비밀번호, 전송 경로는 당장 변경하지 마세요.
- 두 네트워크 모두 실패하는 경우: 정상 작동이 확인된 다른 노드와 비교해 보세요. 모든 노드가 동시에 실패하면 우선 로컬 VPN 상태, 시간, DNS를 확인하세요. 특정 노드만 실패한다면 해당 노드 설정을 계속 점검하세요.
- 시작 직후 중지되는 경우: Android의 VPN 권한 요청을 확인하고, 시스템 VPN 슬롯을 사용하는 다른 서비스를 중지하세요. 서비스 시작 실패와 원격 연결 시간 초과는 서로 다른 문제입니다.
- 화면을 잠근 뒤에만 연결이 끊기는 경우: 시스템의 ‘설정’ → ‘앱’ → ‘v2rayNG’에서 배터리 관련 옵션을 찾아 백그라운드 실행을 허용하세요. 제조사마다 메뉴 경로가 다르므로 실제 화면을 기준으로 확인해야 합니다.
시스템의 ‘설정’ → ‘네트워크 및 인터넷’ → ‘VPN’에서 항상 사용 및 VPN 없이 연결 차단 옵션도 확인하세요. 이전 VPN 설정이 남아 있으면 비교를 위한 직접 연결 요청까지 차단될 수 있습니다. 테스트가 끝나면 원래 보안 설정을 복원하고, 점검을 위해 필요한 보호 기능을 계속 꺼 두지 마세요.
3. 시스템 시간과 구독: 만료된 설정부터 확인
Android의 ‘설정’ → ‘시스템’ → ‘날짜 및 시간’에서 자동 시간 및 시간대 설정을 켜세요. 일부 기기에서는 ‘추가 설정’에 메뉴가 있습니다. 표시된 날짜와 시간이 정확한지 확인한 다음 v2rayNG를 중지했다가 다시 시작하세요. 시간이 어긋나면 인증서 유효 기간 확인에 영향을 줄 수 있으며 VMess 인증이 실패할 수도 있습니다.
구독 링크가 열리더라도 노드가 여전히 유효하다는 뜻은 아닙니다. 구독 제공업체의 관리 페이지에 로그인해 이용 기간, 트래픽 한도, 노드 변경 공지를 확인하세요. v2rayNG의 ‘구독 그룹 설정’에서 구독 주소를 확인한 뒤 메인 화면으로 돌아와 구독을 업데이트합니다. 버전에 따라 명령이 ‘구독 업데이트’ 또는 ‘현재 그룹 구독 업데이트’로 표시될 수 있습니다.
- 업데이트 전에 기존 설정을 기록해 두고, 업데이트 후에는 노드를 다시 선택하세요. 교체된 이전 항목을 계속 테스트하지 않도록 주의해야 합니다.
- 구독 요청에 프록시가 필요한 경우, 실제로 작동하는 다른 노드를 통해서만 업데이트할 수 있습니다. 문제가 있는 노드로 같은 구독 주소를 업데이트하면 순환 문제가 생길 수 있습니다.
- 가져온 설정에 서버 주소, 포트, 프로토콜, 인증 정보가 포함됐는지 확인하세요. 로그인 페이지나 오류 페이지로 연결되는 주소는 유효한 구독 내용이 아닙니다.
- 전체 구독 주소를 낯선 온라인 변환 서비스에 입력하지 마세요. 구독 링크에는 보통 접근 정보가 포함되므로 문제를 점검할 때도 비밀번호처럼 취급해야 합니다.
4. 전송 설정: 주소, 포트, Host, 경로를 각각 확인
노드 목록에서 대상 항목의 수정 아이콘을 누르고 서버 또는 제공업체가 안내한 원본 설정과 항목별로 비교하세요. 노드 이름에 전송 방식이 적혀 있다고 해서 편집 화면의 설정까지 일치한다고 단정하면 안 됩니다. 서버 주소는 접속 대상을, 포트는 연결할 진입점을, 전송 유형은 이후 채널을 설정하는 방식을 결정합니다.
이는 프로토콜 포트에 관한 기본 정보이지 권장 설정이 아닙니다. 노드가 원래 다른 포트를 사용한다면 클라이언트만 443으로 바꿔서는 안 됩니다. 서버 리스닝, 방화벽, 포워딩 진입점이 모두 맞아야 합니다. DNS에서 주소를 받아도 노드 포트에 연결할 수 있다는 뜻은 아닙니다.
- WebSocket: 전송 유형, Host, 경로를 확인하세요. 경로의 대소문자, 앞에 붙는 슬래시, 쿼리 매개변수는 모두 서버 요구 사항과 일치해야 합니다. 리버스 프록시의 전달 설정이 잘못돼도 핸드셰이크가 실패할 수 있습니다.
- gRPC: 서비스 이름과 제공업체가 요구하는 관련 옵션을 확인하세요. WebSocket 경로를 서비스 이름 필드에 그대로 입력하지 마세요.
- 프로토콜 인증: VMess와 VLESS의 사용자 식별 정보, Trojan과 Shadowsocks의 비밀번호가 서버 설정과 일치해야 합니다. 전송 방식을 바꿔도 잘못된 인증 정보는 해결되지 않습니다.
- 도메인 조회: 로그에 노드 도메인 조회 실패가 표시되면 먼저 로컬 DNS 경로를 확인하세요. 비교를 위해 서버에서 확인한 IP를 임시로 사용하더라도 올바른 TLS 서버 이름은 유지해야 합니다.
정리: TCP 연결을 확인한 다음 핸드셰이크 설정을 점검하세요
같은 주소와 포트에 두 네트워크 모두 TCP로 연결할 수 없다면 먼저 서버 리스닝 상태와 네트워크 경로를 확인하세요. TCP 연결은 성공했지만 프록시 요청이 실패하면 인증, 전송, TLS 설정을 차례로 확인합니다. DNS, 포트, 경로를 한꺼번에 바꾸지 마세요.
5. TLS와 로그: 오류 메시지로 연결 단계를 파악
TLS 서버 이름은 보통 SNI 및 인증서 이름 검증에 사용됩니다. 이는 WebSocket의 Host와 같지 않으며 실제 접속 주소와도 다를 수 있습니다. 세 값이 같을 수는 있지만 이름이 비슷하다는 이유만으로 서로 바꾸면 안 됩니다. REALITY 노드는 서버에서 제공한 공개 키, short ID, 서버 이름도 확인해야 하며 일반 TLS 노드처럼 임의로 수정해서는 안 됩니다.
오류: i/o timeout
원인 및 해결: 네트워크 읽기 또는 쓰기 작업이 대기 시간을 초과한 상태입니다. 이 한 줄만으로는 문제가 발생한 계층을 판단할 수 없습니다. 앞부분에서 대상 주소와 작업 단계를 확인한 다음 네트워크 상태와 같은 시각의 서버 로그를 비교하세요.
오류: connection refused
원인 및 해결: 대상 호스트 또는 중간 장치가 연결을 거부했습니다. 포트를 확인하고 서버 프로세스가 해당 포트에서 리스닝 중인지, 연결을 거부하는 규칙이 있는지 살펴보세요.
오류: no such host
원인 및 해결: 도메인 조회에서 사용할 수 있는 결과를 얻지 못했습니다. 오류 대상이 노드 도메인인지 접속하려는 도메인인지 확인한 뒤 철자, DNS 설정, 해당 도메인의 레코드를 점검하세요.
오류: x509: certificate has expired or is not yet valid
원인 및 해결: 인증서 유효 기간과 현재 시간이 맞지 않습니다. 먼저 휴대전화 시간을 올바르게 설정하세요. 그래도 해결되지 않으면 서버 관리자에게 인증서 갱신 여부와 실제로 불러온 인증서를 확인해 달라고 요청하세요.
오류: websocket: bad handshake
원인 및 해결: 서버가 예상한 WebSocket 업그레이드 응답을 반환하지 않았습니다. 경로, Host, 리버스 프록시 전달 규칙을 확인하고 응답 상태 코드도 함께 살펴보세요.
6. 서버: 리스닝, 허용 규칙, 전달 경로 확인
다른 사람이 제공한 노드라면 실패 시간, 네트워크 유형, 클라이언트 버전, 민감 정보를 가린 오류 메시지를 운영자에게 전달하세요. 서버를 직접 관리한다면 실행 상태부터 확인한 뒤 시스템 방화벽, 클라우드 보안 그룹, 컨테이너 포트 매핑, 리버스 프록시를 점검하세요. 클라이언트에서 시간 초과가 발생해도 서버 애플리케이션 로그에 기록이 남지 않을 수 있습니다. 트래픽이 프로세스에 도달하지 않았다면 애플리케이션에 기록이 생기지 않습니다.
다음은 Linux 서버에서 확인만 수행하는 점검 명령입니다. 먼저 실제 서비스 유닛을 확인하세요. 배포 환경에서 xray라는 이름의 systemd 서비스가 사용된다고 확인된 경우에만 뒤의 두 명령을 실행하세요. 컨테이너나 다른 서비스 이름을 사용하는 환경에서는 해당 프로세스와 컨테이너 로그를 확인해야 합니다.
ss -lntp
ss -lnup
systemctl list-units --type=service --all
systemctl status xray --no-pager
journalctl -u xray --since "10 minutes ago" --no-pager- 실제 리스닝 포트와 주소를 확인하세요. 백엔드가
127.0.0.1에서만 리스닝하고 같은 서버의 리버스 프록시가 연결하는 구성은 정상일 수 있습니다. 클라이언트가 백엔드에 직접 연결한다면 이에 맞는 외부 진입점이 필요합니다. - 클라우드 보안 그룹과 호스트 방화벽을 단계별로 확인하세요. 허용 규칙은 실제 프로토콜 및 대상 포트와 일치해야 합니다. 규칙 이름만 보고 판단하면 안 됩니다.
- 도메인의 A 및 AAAA 레코드를 확인하세요. 이전 주소나 설정이 끝나지 않은 IPv6 진입점으로 연결된다면 클라이언트를 반복해서 재설치하지 말고 해당 레코드 또는 네트워크를 수정하세요.
- 휴대전화에서 테스트를 한 번 실행하면서 진입점과 백엔드 로그를 함께 살펴보세요. 진입점에는 요청이 있지만 백엔드에는 없다면 리버스 프록시를 중점적으로 확인하세요. 백엔드가 요청을 받았지만 인증에 실패했다면 사용자 인증 정보를 점검하세요.
7. 자주 묻는 질문과 점검 마무리
지연 시간이 정상으로 나오는데 웹페이지가 열리지 않는 이유는 무엇인가요?
먼저 표시된 수치가 TCP 테스트 결과인지 실제 연결 테스트 결과인지 확인하세요. TCP 테스트는 포트가 응답한다는 것만 확인합니다. 실제 연결 테스트도 지정된 테스트 대상에 대한 확인일 뿐입니다. 서비스를 시작한 뒤 브라우저 요청 로그를 확인하고, 브라우저가 앱별 프록시에서 제외됐는지, 라우팅이 대상 트래픽을 예상한 아웃바운드로 보내는지 살펴보세요.
구독 업데이트가 계속 시간 초과되는데 노드를 전부 삭제해야 하나요?
기존 설정을 유지한 채 구독 주소와 이용 기간부터 확인하세요. 직접 연결로 구독을 가져올 수 없다면 작동하는 다른 노드로 업데이트를 시도하세요. 제공업체가 주소를 변경했다면 해당 그룹의 주소만 수정하면 됩니다. 노드를 모두 삭제해도 구독 서버에 연결할 수 없는 문제는 해결되지 않습니다.
같은 노드가 PC에서는 작동하지만 휴대전화에서는 안 되는 이유는 무엇인가요?
먼저 두 기기를 같은 네트워크에 연결한 다음 v2rayN과 v2rayNG의 서버 주소, 포트, 전송 설정, SNI, 인증 정보를 비교하세요. 두 기기에서 이름만 같은 이전 노드가 아니라 동일한 설정을 테스트하는지 확인하고 각 코어 버전도 기록하세요. 설정 항목의 호환성 문제는 구체적인 오류 메시지를 기준으로 점검해야 합니다.
연결 시간 초과 시간을 늘리면 해결될까요?
실제로 핸드셰이크가 완료되는 연결의 대기 시간만 긴 경우에는 대기 시간을 늘리는 것이 도움이 될 수 있습니다. 상대 서버가 리스닝하지 않거나 인증서가 잘못됐거나 인증 정보가 맞지 않는 문제는 해결되지 않습니다. 로그에서 실패 단계를 먼저 확인하고 대기 시간 증가를 문제 해결로 착각하지 마세요.
마지막으로 클라이언트 및 코어 버전, 테스트 시간, 네트워크 유형, 노드 업데이트 여부, 최초 오류, 변경한 설정을 점검 기록으로 남기세요. 효과가 없었던 변경 사항은 원래대로 되돌린 뒤 다시 테스트합니다. 이 기록을 운영자에게 전달하면 문제를 파악하기 쉽고, 다음에 문제가 발생했을 때 처음부터 원인을 추측하지 않아도 됩니다. 기본 연결 및 라우팅 개념은 문제 해결과 고급 설정에서 더 확인할 수 있습니다.