이 체크리스트는 v2rayN, v2rayNG 또는 v2flyNG에서 구독 다운로드 실패, 파싱 오류, 업데이트 후 빈 노드 목록을 점검할 때 유용합니다. 링크, 응답 내용, 인코딩 형식, 업데이트 경로, 프로토콜 호환성, 로컬 환경 순서로 확인하세요. 각 단계를 마칠 때마다 다시 업데이트하고 결과를 기록하면 문제를 클라이언트, 네트워크, 구독 서비스 중 한 계층으로 좁힐 수 있습니다.
먼저 어느 단계에서 실패했는지 확인하기
“구독 만료”는 하나의 고장만을 뜻하지 않습니다. 클라이언트가 구독을 업데이트하려면 주소 읽기, 도메인 확인, 연결 수립, 응답 수신, 콘텐츠 디코딩, 노드 인식의 6단계를 거쳐야 합니다. 앞의 네 단계에서 실패하면 보통 시간 초과, 연결 거부 또는 HTTP 상태 오류가 나타납니다. 뒤의 두 단계에서 실패하면 요청은 성공으로 표시되지만 노드 수가 0개인 경우가 많습니다.
점검을 시작하기 전에 기존 구독 그룹을 유지하고, 노드를 연속해서 삭제·재생성하거나 일괄 수정하지 마세요. v2rayN 7.x에서는 먼저 메인 창의 로그 영역을 연 다음 「구독 그룹」→「모든 구독 업데이트」를 한 번 실행하세요. Android에서는 v2rayNG 또는 v2flyNG의 구독 그룹 화면에서 대상 그룹만 업데이트하고 표시되는 전체 오류 메시지를 기록합니다.
단계를 판단할 때는 두 가지 결과를 확인하세요. 요청이 유효한 응답을 받았는지, 그리고 응답에서 노드가 생성되었는지입니다. 로그가 연결 단계에서 멈췄다면 네 번째 항목인 업데이트 경로와 여섯 번째 항목인 로컬 환경을 먼저 확인하세요. 수천 바이트의 콘텐츠를 받았는데 노드가 없다면 두 번째 항목인 응답 유형, 세 번째 항목인 인코딩 형식, 다섯 번째 항목인 프로토콜 호환성을 우선 점검합니다.
첫 번째 항목: 구독 링크가 완전한지 또는 만료되지 않았는지 확인
구독 주소에서 가장 흔한 문제는 복사가 완전하지 않은 것입니다. 쿼리 매개변수가 있는 링크에는 물음표, 등호, 여러 매개변수가 포함되는 경우가 많습니다. 메신저의 줄바꿈, 브라우저의 축약 표시, 텍스트를 직접 선택하는 과정에서 끝부분의 토큰이 잘릴 수 있습니다. 문자 하나만 빠져도 서버가 권한 없음, 빈 콘텐츠 또는 일반 오류 페이지를 반환할 수 있습니다.
v2rayN 7.x에서 「구독 그룹」→「구독 그룹 설정」으로 이동한 뒤 대상 그룹을 선택하여 주소를 확인하세요. 입력창에 표시된 앞부분과 뒷부분만 보지 말고, 전체 선택 후 다시 복사하여 원본 페이지와 한 글자씩 비교하세요. v2rayNG와 v2flyNG도 구독 그룹 편집 화면에서 주소 앞뒤에 공백, 한국어·중국어 따옴표, 줄바꿈이 없는지 확인해야 합니다.
오류: The remote server returned an error: (401) Unauthorized
원인 및 해결:구독 토큰이 유효하지 않거나 만료되었거나 복사 과정에서 잘렸습니다. 전체 구독 주소를 다시 발급받아 기존 그룹의 주소를 바꾼 다음 업데이트하세요.
오류:unsupported protocol scheme
원인 및 해결:주소에 올바른 네트워크 프로토콜 접두사가 없거나 시작 부분에 공백이 섞여 있습니다. 링크가 유효한 HTTPS 주소로 시작하는지 확인하고 주소 양쪽의 공백을 삭제하세요.
오류:404 Not Found
원인 및 해결:요청 경로가 변경되었거나 주소가 잘렸습니다. 구독 관리 페이지에서 다시 복사하고, 이전 주소를 보고 경로를 직접 덧붙이지 마세요.
- 구독 주소가 한 줄의 텍스트이며 시작과 끝에 공백이 없는지 확인하세요.
- 물음표 뒤의 쿼리 매개변수가 완전한지, 특히 등호 뒤의 토큰 내용이 빠지지 않았는지 확인하세요.
- 현재 구독이 아직 유효한지, 서버에서 새 주소를 발급하지 않았는지 확인하세요.
- 주소만 교체하고 기존 노드는 먼저 삭제하지 마세요. 업데이트에 실패해도 기존 설정을 유지할 수 있습니다.
링크가 QR 코드에서 나온 것이라면 스캔 후 실제 텍스트도 확인하세요. QR 코드에는 구독 주소가 아니라 단일 VMess 또는 VLESS 노드가 들어 있을 수 있습니다. 단일 노드 링크를 구독 입력란에 넣으면 일부 클라이언트는 형식 오류를 표시하고, 다른 클라이언트는 업데이트에 성공한 것처럼 보이지만 구독 그룹을 만들지 못할 수 있습니다.
두 번째 항목: 서버가 구독 콘텐츠를 반환하는지 확인
링크가 열린다고 해서 반환 콘텐츠가 올바른 것은 아닙니다. 구독 서버가 로그인 페이지, 만료 안내 페이지, 접근 빈도 제한 페이지 또는 리디렉션 페이지를 반환할 수 있습니다. 브라우저에서는 정상적으로 보여도 클라이언트가 기대하는 것은 노드 링크 목록이나 약속된 형식의 데이터입니다. HTML을 구독 텍스트로 계속 파싱하면 문자 오류가 발생하거나 노드가 비어 있게 됩니다.
브라우저에서 구독 주소를 열어 결과를 확인할 수 있지만, 주소를 공개하거나 전체 토큰을 공개 페이지에 붙여 넣지는 마세요. 유효한 응답은 보통 연속된 인코딩 텍스트이거나 여러 줄의 프로토콜 링크로 구성됩니다. 페이지에 “로그인”, “요금제 만료”, “요청이 너무 많습니다” 등의 안내가 표시되면 먼저 계정 상태를 처리하거나 제한이 풀릴 때까지 기다리세요.
유효한 여러 줄 구독 구조 예시:
vmess://인코딩된 노드 데이터
vless://사용자 정보@server.example.net:443?security=tls&type=ws
구독 콘텐츠가 아님이 분명한 응답:
<html>
<title>Sign in</title>
</html>| 관찰 결과 | 판단할 수 있는 문제 | 다음 단계 |
|---|---|---|
| 401 또는 403 반환 | 토큰이 유효하지 않거나 권한이 만료되었거나 접근 조건을 충족하지 못함 | 구독 주소를 새로 발급받아 기존 주소로 교체 |
| 404 반환 | 구독 경로가 변경되었거나 링크가 잘림 | 원래 관리 페이지에서 전체 링크를 다시 복사 |
| 429 반환 | 짧은 시간에 업데이트를 너무 많이 수행함 | 반복 새로고침을 중지하고 10~30분 후 다시 시도 |
| HTML 페이지 반환 | 로그인, 만료 또는 차단 페이지로 이동됨 | 페이지 안내를 처리하고 클라이언트 코어 설정은 계속 바꾸지 않기 |
| 텍스트를 반환했지만 크기가 0바이트 | 서버 작업 생성에 문제가 있거나 현재 그룹이 비어 있음 | 서버에서 구독에 유효한 노드가 하나 이상 포함되어 있는지 확인 |
리디렉션도 주의해야 합니다. 일부 구독 주소는 먼저 301 또는 302를 반환한 뒤 임시 다운로드 주소로 이동합니다. 중간 이동에서 추가 인증을 요구하면 클라이언트가 최종 콘텐츠를 받지 못할 수 있습니다. 이때는 브라우저 주소창에서 복사한 임시 링크가 아니라 서버가 직접 제공한 클라이언트용 구독 주소를 사용하세요.
세 번째 항목: 인코딩 방식과 줄바꿈 형식 확인
서버가 콘텐츠를 반환했는데도 파싱에 실패한다면 인코딩을 중점적으로 확인하세요. 일반적인 구독은 여러 줄 노드 목록을 Base64로 인코딩한 형식이며, 줄바꿈으로 구분된 VMess, VLESS 등의 링크를 직접 반환하는 서비스도 있습니다. 클라이언트는 먼저 외부 형식을 식별한 뒤 각 줄의 프로토콜 필드를 파싱해야 합니다. 외부에 웹페이지 표시가 하나만 섞이거나 내부 문자가 하나 빠지거나 줄바꿈 형식이 잘못되어도 전체 목록 가져오기가 실패할 수 있습니다.
텍스트 편집기로 구독 콘텐츠를 수정한 뒤 가져오지 마세요. 따옴표 자동 변환, 문단 기호 삽입, 줄바꿈 변경은 URI를 손상시킵니다. 오프라인 진단이 꼭 필요하다면 UTF-8 일반 텍스트로만 저장하고, 각 노드 링크가 한 줄씩 독립적으로 있으며 줄 시작 부분에 번호, 글머리 기호 또는 공백이 없는지 확인하세요.
오류:illegal base64 data at input byte
원인 및 해결:외부 인코딩이 잘렸거나 공백이 섞였거나 클라이언트가 올바르게 인식하지 못하는 변형 형식입니다. 원본 응답을 다시 받아오고 인코딩 텍스트를 직접 조합하지 마세요.
오류:invalid character '<' looking for beginning of value
원인 및 해결:클라이언트가 HTML 페이지를 JSON 또는 구독 데이터로 읽고 있습니다. 두 번째 항목으로 돌아가 응답 페이지와 HTTP 상태를 확인하세요.
오류:failed to parse subscription content
원인 및 해결:구독 외부 형식 또는 특정 줄이 클라이언트가 인식할 수 있는 구조가 아닙니다. 먼저 유효성이 확인된 노드 하나만 포함한 테스트 구독을 가져와 파서 자체가 작동하는지 확인하세요.
- 응답 시작 부분에
<html또는<!doctype이 나타나면 웹페이지이지 구독 데이터가 아닙니다. - 디코딩 후 각 줄이 프로토콜 이름으로 시작하는지 확인하고, 빈 줄 외에 설명 문구가 섞여 있지 않은지 점검하세요.
- 특정 한 줄만 가져오기에 실패한다면 해당 줄을 따로 제거하고 테스트하세요. 문제는 대개 그 노드의 필드에 있습니다.
- 모든 줄이 실패한다면 외부 인코딩, 문자 집합, 클라이언트가 지원하는 구독 형식을 먼저 확인하세요.
“노드 수가 0개”인 원인은 서버가 클라이언트 유형에 따라 서로 다른 형식을 반환하기 때문일 수도 있습니다. 관리 페이지에 v2rayN, v2rayNG 또는 범용 구독 옵션이 있다면 현재 클라이언트에 맞는 유형을 선택하세요. 다른 소프트웨어용 설정 형식을 V2Ray 클라이언트에 그대로 넘겨 파싱하게 하지 마세요.
네 번째 항목: 구독 업데이트 경로 전환
구독 요청은 현재 프록시를 통해 보낼 수도 있고 직접 연결할 수도 있습니다. 현재 네트워크에서 구독 도메인에 직접 연결할 수 없으면 직접 업데이트가 시간 초과로 끝납니다. 반대로 선택한 노드가 이미 작동하지 않는다면 프록시를 통한 업데이트도 실패합니다. 한 가지 모드만 고정해서 선택하지 말고 현재 연결 상태에 따라 두 방식으로 비교 테스트하세요.
기존 노드 확인
먼저 클라이언트에 실행 가능한 기존 노드가 남아 있는지 확인하세요. 기존 노드가 연결된다면 현재 설정을 유지하고 목록을 먼저 비우지 마세요.
코어 상태 확인
v2rayN 메인 창에서 코어가 실행 중인지 확인하고 로그의 로컬 수신 대기 포트를 점검하세요. 일반적인 SOCKS 인바운드는 10808이지만 현재 설정에 표시된 값을 기준으로 해야 합니다.
먼저 직접 연결로 업데이트
「구독 그룹」→「모든 구독 업데이트」를 실행하고 프록시를 사용하지 않는 업데이트 방식을 선택한 뒤 소요 시간과 오류 원문을 기록하세요.
그다음 프록시로 업데이트
사용 가능한 것으로 확인된 노드에 연결한 다음 프록시를 통한 구독 업데이트를 선택하세요. 두 번째 방식만 성공한다면 문제는 구독 도메인에 직접 연결하는 네트워크 경로에 있습니다.
두 결과 비교
직접 연결과 프록시 모두 실패하면 주소와 서버 응답을 확인하세요. 프록시 방식만 실패한다면 현재 노드, 코어 상태, 10808과 같은 실제 수신 대기 포트를 점검하세요.
v2rayN의 “시스템 프록시” 스위치와 “구독을 프록시로 업데이트할지 여부”는 완전히 같은 판단 항목이 아닙니다. 시스템 프록시는 다른 애플리케이션의 요청 전송 방식을 제어하지만, 구독 업데이트는 클라이언트가 자체 옵션에 따라 실행할 수 있습니다. 브라우저에서 웹페이지가 열리는지만으로 업데이트 경로를 판단하지 말고 클라이언트 로그에 실제로 사용된 연결 방식을 기준으로 확인하세요.
다섯 번째 항목: 클라이언트 버전, 코어, 프로토콜 호환성 확인
구독을 다운로드하고 디코딩할 수 있다고 해서 모든 노드를 현재 코어에서 사용할 수 있는 것은 아닙니다. VMess와 VLESS는 서로 다른 프로토콜이며, 노드에는 TLS, Reality, WebSocket, gRPC 등의 전송 설정이 함께 포함될 수 있습니다. 오래된 클라이언트나 호환되지 않는 코어는 새 필드를 만나 노드를 건너뛰거나, 가져온 뒤 실행하지 못하거나, 코어 로그에 알 수 없는 설정 항목을 기록할 수 있습니다.
데스크톱에서 v2rayN을 사용할 때는 「설정」→「매개변수 설정」→「Core 유형」으로 이동하여 현재 선택을 확인하세요. VLESS, Reality 등이 포함된 Xray 관련 설정이라면 해당 필드를 인식할 수 있는 Xray 코어를 사용하고 v2rayN과 코어를 같은 시기의 안정 버전으로 업데이트하세요. 메인 프로그램만 교체하고 명백히 오래된 코어 파일을 그대로 두지 마세요.
오류:unknown field
원인 및 해결:설정에 현재 코어가 인식하지 못하는 필드가 포함되어 있습니다. 클라이언트와 해당 코어를 업데이트하고 v2rayN의 「설정」→「매개변수 설정」→「Core 유형」에서 선택을 확인하세요.
오류:failed to load config files
원인 및 해결:노드는 가져왔지만 생성된 코어 설정이 검사를 통과하지 못했습니다. 바로 뒤에 표시되는 필드 오류를 확인하여 프로토콜, 전송 방식 또는 보안 매개변수를 특정하세요.
오류:unknown transport protocol
원인 및 해결:노드의 전송 유형이 현재 버전에서 지원되지 않거나 구독 필드의 철자가 잘못되었습니다. 먼저 코어를 업데이트한 다음 구독 제공자에게 해당 노드 템플릿을 확인받으세요.
- v2rayN: 데스크톱에서는 먼저 메인 프로그램 버전을 확인한 다음 실제로 활성화된 Core 유형과 코어 로그를 점검하세요.
- v2rayNG: Android에서는 Xray 코어를 사용하므로 VLESS, Reality 등의 필드가 포함된 구독을 확인하는 데 적합합니다.
- v2flyNG: Android에서는 v2fly 코어를 사용하므로 특정 Xray 확장 필드를 바로 호환할 수 있다고 가정해서는 안 됩니다.
- 하나의 구독에서 일부 노드만 정상이고 일부가 실패한다면 대개 노드의 프로토콜이나 전송 조합이 다른 것이며, 구독 주소 전체가 만료된 것은 아닙니다.
판단할 때는 “구독 파싱”과 “노드 연결”을 분리하세요. 노드가 목록에 이미 표시되었다면 다운로드와 기본 파싱은 대체로 완료된 것입니다. 이후 핸드셰이크 실패, 서버 주소 확인 불가, 연결 시간 초과가 발생하면 노드와 회선 점검으로 전환하고 구독 링크를 계속 수정하지 마세요.
여섯 번째 항목: 로컬 네트워크, 시간, 그룹 캐시 정리
앞의 다섯 항목이 모두 정상이라면 로컬 환경을 확인하세요. 기기 시간이 크게 어긋나면 TLS 인증서 검증이 실패할 수 있고, DNS가 잘못된 주소를 반환하면 구독 도메인에 연결할 수 없습니다. 보안 프로그램이나 방화벽이 클라이언트 코어의 네트워크 접근을 막을 수도 있으며, 오래된 그룹 캐시 때문에 업데이트된 노드가 예상대로 교체되지 않을 수도 있습니다.
먼저 시스템 날짜, 시간, 시간대를 보정한 뒤 클라이언트를 완전히 종료하고 다시 시작하세요. 그다음 현재 네트워크와 다른 사용 가능한 네트워크에서 각각 테스트합니다. 같은 구독이 다른 네트워크에서는 5초 안에 업데이트되지만 원래 네트워크에서는 계속 약 30초 후 시간 초과가 발생한다면 문제는 구독 인코딩보다 DNS, 게이트웨이 또는 네트워크 출구에 있을 가능성이 높습니다.
구독 업데이트가 계속 시간 초과로 끝나나요?
시간 초과가 발생한 시각을 먼저 기록한 다음 직접 연결과 프록시 업데이트를 전환해 보세요. 두 방식 모두 일정한 시간 후 실패한다면 구독 도메인의 DNS 결과, 시스템 시간, 방화벽의 아웃바운드 규칙을 확인하세요.
업데이트는 성공했는데 노드 목록이 여전히 비어 있나요?
대상 구독 그룹을 열어 반환된 노드 수를 확인하고 필터 조건이 활성화되어 있는지 점검하세요. 이름 필터와 프로토콜 필터를 잠시 해제한 뒤 다시 업데이트하여 원본 목록을 확인합니다.
컴퓨터에서는 업데이트되는데 Android에서는 업데이트되지 않나요?
v2rayNG 또는 v2flyNG에서 같은 전체 주소를 다시 붙여 넣고, 네트워크 요청을 변경할 수 있는 비공개 DNS 설정을 끈 상태로 비교 테스트하세요. 기기의 날짜와 시간대도 정확한지 확인합니다.
네트워크를 바꾸자마자 복구된다면 무엇을 의미하나요?
구독 링크와 클라이언트 파싱은 대체로 정상이라는 뜻입니다. 원래 네트워크로 돌아간 뒤 DNS, 게이트웨이 제한, 구독 도메인 연결 경로를 중점적으로 확인하고 모든 노드를 다시 만들 필요는 없습니다.
구독 그룹을 바로 삭제해야 하나요?
먼저 기존 설정을 내보내거나 보존하고, 주소가 유효하며 캐시 이상이 확인된 경우에만 테스트 그룹을 새로 만드세요. 테스트 그룹으로 가져오기가 성공한 뒤 기존 그룹을 삭제할지 결정하면 됩니다.
- 시스템 시간: 표준 시간과의 오차를 1분 이내로 유지하고 시간대도 정확해야 합니다.
- DNS 비교: 네트워크를 바꾼 뒤 구독 도메인을 다시 확인하여 여전히 연결 가능한 주소를 반환하는지 관찰하세요.
- 방화벽 확인: v2rayN 메인 프로그램과 실제 코어 프로세스가 아웃바운드 연결을 시작하도록 허용하세요.
- 포트 확인: 10808 등의 로컬 포트를 다른 프로세스가 사용하고 있지 않은지 확인하고 구체적인 값은 로그를 기준으로 삼으세요.
- 그룹 확인: 필터 조건을 해제하고 새 노드가 이름, 프로토콜 또는 그룹 규칙에 의해 숨겨지지 않았는지 확인하세요.
테스트 그룹을 만들 때 같은 주소를 사용하고 해당 그룹은 한 번만 업데이트하세요. 테스트 그룹은 정상인데 기존 그룹만 비어 있다면 문제는 기존 그룹 설정이나 캐시에 집중되어 있습니다. 두 그룹의 결과가 완전히 같다면 서버 응답과 네트워크 경로 점검으로 돌아가고 그룹을 계속 새로 만들 필요는 없습니다.
수정 후 네 가지 결과로 검증 완료하기
수정 완료 여부는 “팝업이 나타나지 않음”으로 판단하지 말고 구독 요청, 노드 생성, 코어 실행, 실제 연결의 네 계층을 모두 확인해야 합니다. 대상 그룹을 업데이트한 뒤 전체 노드 수를 기록하세요. 노드 하나를 선택해 코어를 시작하고 로컬 수신 대기 포트를 확인합니다. 마지막으로 인터넷 연결이 필요한 애플리케이션에서 요청을 한 번 보내고 코어 로그에 새로운 아웃바운드 기록이 남는지 확인하세요.
| 검증 계층 | 통과 기준 | 실패 시 돌아갈 단계 |
|---|---|---|
| 구독 요청 | 401, 404, 429 또는 시간 초과가 없고 응답 콘텐츠가 비어 있지 않음 | 첫 번째, 두 번째 또는 네 번째 항목 |
| 노드 생성 | 업데이트 후 노드 수가 0보다 많고 이름과 프로토콜이 표시됨 | 세 번째 또는 다섯 번째 항목 |
| 코어 실행 | 로그에 인바운드 포트 수신 대기가 시작되었다고 표시되고 설정 필드 오류가 없음 | 다섯 번째 또는 여섯 번째 항목 |
| 실제 연결 | 애플리케이션 요청으로 아웃바운드 로그가 생성되고 3회 연속 테스트 결과가 안정적임 | 노드, 회선 또는 시스템 프록시 설정 |
구독이 복구되었는데도 개별 노드가 연결되지 않는다면 구독을 계속 새로 고치지 마세요. 같은 그룹의 다른 노드 두 개를 선택해 각각 테스트하세요. 세 노드가 모두 실패하면 로컬 코어와 네트워크를 확인하고, 한 노드만 실패하면 대개 해당 노드의 주소, 포트 또는 회선 상태가 원인입니다.
완전한 점검 기록에는 클라이언트 이름과 버전, 코어 유형, 업데이트 시각, 오류 원문, 직접 연결과 프록시 방식의 결과, 반환된 노드 수가 포함되어야 합니다. 이 정보를 함께 기록해야 “링크 만료”, “서버 오류 응답”, “클라이언트 비호환”, “로컬 네트워크 차단”을 정확히 구분할 수 있으며, “구독 만료”라는 네 단어만 보고 설정을 반복해서 바꾸는 일을 피할 수 있습니다.