v2rayN, v2rayNG, v2flyNG에서 구독이 업데이트되지 않거나 업데이트 후 노드 수가 0개가 되거나 웹페이지 내용만 내려오는 경우에 적용됩니다. 기록, 링크 확인, 응답 형식 점검, 접근 제한 확인, 네트워크 분리, 클라이언트 설정 재검토의 순서로 점검하면 문제를 구독 소스, 전송 경로 또는 로컬 클라이언트로 분류할 수 있습니다.
오류를 먼저 기록한 뒤 6단계 순서로 점검하세요
업데이트 실패를 확인했다고 바로 구독을 삭제하거나 클라이언트를 재설치하거나 노드를 연속해서 바꾸지 마세요. 구독 주소에는 보통 계정 토큰이 포함되어 있으며, 링크 접근 가능 여부, 서버가 반환한 내용, 클라이언트의 요청 방식이 결과를 함께 결정합니다. 오류 원문, 발생 시각, 현재 네트워크와 클라이언트 버전을 먼저 보존해야 이후 비교가 가능합니다.
효과적인 점검을 위해서는 재현 가능한 조건을 만들어야 합니다. 동일한 구독 링크를 현재 네트워크와 신뢰할 수 있는 다른 네트워크에서 각각 테스트하고, 같은 네트워크에서는 클라이언트 요청과 브라우저 요청을 비교하세요. 매번 변수 하나만 바꿔야 문제가 서버, DNS, 프록시 경로 또는 클라이언트 파서에서 비롯되었는지 판단할 수 있습니다.
현상 기록
전체 오류 메시지를 복사하고 클라이언트 이름, 버전, 발생 시각, 노드 수 변화와 사용 중인 네트워크를 기록하세요. 당분간 기존 설정은 덮어쓰지 마세요.
링크 확인
주소가 완전한지, 만료되지 않았는지, 301 또는 302 리디렉션이 발생하는지 확인하고 최종 응답 상태가 200인지 확인하세요.
본문 확인
반환된 내용이 공유 링크 목록, Base64 텍스트 또는 지원되는 구조화 설정인지 확인하세요. 로그인 페이지, 인증 페이지 또는 오류 페이지라면 안 됩니다.
제한 사항 확인
구독 소스가 User-Agent, 접근 횟수, 계정 상태, 진입 주소 또는 접속 네트워크를 제한하는지 확인하세요.
네트워크 분리
DNS와 접속 네트워크를 바꾸고 잘못된 시스템 프록시를 비활성화하여 도메인 오염, 투명 리디렉션과 로컬 프록시 루프를 배제하세요.
클라이언트 재검토
구독 그룹을 다시 편집하고 링크에 공백이 섞이지 않았는지 확인한 뒤 클라이언트를 업데이트하고 코어 유형과 로컬 포트 점유 상태를 확인하세요.
1·2단계: 오류 현상과 링크 유효성 확인
먼저 ‘다운로드할 수 없음’과 ‘다운로드했지만 파싱할 수 없음’을 구분하세요. 시간 초과, 도메인 확인 실패와 연결 거부는 대개 다운로드 단계에서 발생하며, 노드 수 0개, 형식 오류와 잘못된 문자는 파싱 단계에서 주로 발생합니다. 두 문제의 해결 경로는 다르므로 모두 ‘구독 만료’라고 뭉뚱그릴 수 없습니다.
구독 주소를 확인할 때는 시작 프로토콜, 도메인, 경로와 쿼리 매개변수를 중점적으로 보세요. 복사 과정에서 가장 흔한 문제는 끝부분 토큰 누락, 메신저의 자동 줄바꿈, 주소 앞뒤 공백 또는 표시 문구와 실제 링크를 함께 붙여 넣는 경우입니다. 구독 토큰은 접근 자격 증명과 같으므로 공개 파싱 사이트, 공개 로그나 스크린샷에 올리면 안 됩니다.
브라우저에서 링크가 열린다고 해서 클라이언트에서도 반드시 업데이트되는 것은 아닙니다. 브라우저는 Cookie를 자동으로 전송하거나 리디렉션을 처리하고 서버의 안내 페이지를 표시할 수 있지만, 클라이언트는 응답 본문을 받아 파서에 전달할 뿐입니다. 다운로드 동작이 나타나는지만 보지 말고 최종 상태 코드, 응답 유형과 본문 앞부분을 함께 기록하세요.
오류: The operation has timed out
원인 및 해결: 설정된 시간 안에 연결이 완료되지 않았습니다. DNS 무응답, 네트워크 연결 불가 또는 서버 차단이 원인일 수 있습니다. 먼저 시간 초과 기준을 10초로 설정하고 다른 네트워크에서 재시도한 뒤 시스템 시간이 정확한지 확인하세요.
오류: Response status code does not indicate success: 404 (Not Found)
원인 및 해결: 구독 경로가 존재하지 않습니다. 진입 주소 변경, 토큰 재설정 또는 불완전한 복사에서 흔히 발생합니다. 구독 서비스 페이지로 돌아가 주소를 다시 생성하고 경로를 임의로 추측하지 마세요.
오류: Response status code does not indicate success: 410 (Gone)
원인 및 해결: 서버가 해당 리소스가 취소되었음을 명확히 알린 상태입니다. 구독 링크를 다시 생성하거나 계정 상태를 확인하세요. 로컬 클라이언트에서 반복 업데이트해도 이 주소는 복구되지 않습니다.
| 관찰 결과 | 우선 판단 | 다음 작업 |
|---|---|---|
| 상태 코드 200, 본문은 노드 데이터 | 다운로드 성공, 형식과 클라이언트 파싱을 확인 | 본문 첫 줄, 인코딩과 공유 링크 접두사를 확인 |
| 상태 코드 301 또는 302 | 진입 주소에서 리디렉션 발생 | 최종 주소가 예상 도메인에 있고 토큰이 누락되지 않았는지 확인 |
| 상태 코드 401 또는 403 | 자격 증명, UA 또는 접근 정책 제한 | 토큰을 확인하고 구독 소스의 클라이언트 요구 사항을 점검 |
| 상태 코드 404 또는 410 | 경로 만료 또는 리소스 취소 | 서버에서 구독 주소를 다시 발급받기 |
| 상태 코드 200, 본문은 HTML | 로그인 페이지, 인증 페이지 또는 오류 페이지가 반환됨 | 리디렉션, 계정 상태와 네트워크 리디렉션을 확인 |
3단계: 반환 내용과 Base64 인코딩 상태 확인
구독 다운로드가 완료되면 클라이언트는 본문 특성에 따라 형식을 식별합니다. 일반적으로 여러 줄의 vmess://, vless://, trojan:// 또는 ss:// 공유 링크가 반환되거나, 전체 텍스트를 Base64로 인코딩한 내용이 반환됩니다. 일부 서비스는 구조화된 설정을 반환하지만 클라이언트의 지원 여부는 버전과 가져오기 경로에 따라 다릅니다.
Base64 실패가 항상 노드 매개변수 오류를 의미하는 것은 아닙니다. 전송 중 삽입된 공백, 변경된 줄바꿈 규칙, 누락된 끝 패딩 문자가 특정 바이트에서 디코더를 멈추게 할 수 있습니다. 또 다른 흔한 경우는 본문이 실제로 HTML이라 처음에 <!doctype html>이 나오는데도 클라이언트가 구독 데이터로 해석하려는 상황입니다. 이때 인코딩과 관련 있어 보이는 오류가 발생합니다.
정상적인 평문 구독 시작 예시:
vless://사용자 식별자@node.example.net:443?type=tcp&security=tls#예시 노드
trojan://접속 비밀번호@edge.example.net:443?security=tls#보조 노드
추가 확인이 필요한 응답 시작 부분:
<!doctype html>
{"error":"token expired"}
Access denied- 공백을 제거한 본문도 비어 있음: 서버가 빈 구독을 반환했을 수 있으므로 먼저 계정에 사용 가능한 노드가 있는지 확인하세요.
- 디코딩 후 일반 안내 문구만 표시됨: 구독 서비스가 업무 오류를 반환한 것이며 클라이언트 프로토콜 파싱 문제는 아닙니다.
- 공유 링크 접두사는 올바르지만 단일 항목 가져오기에 실패함: 포트, 사용자 식별자, 전송 유형, TLS 매개변수와 URL 인코딩을 계속 확인하세요.
- 일부 노드만 사라짐: 서버의 배포 정책이 바뀌었거나 구버전 클라이언트가 새 필드를 인식하지 못하는 경우일 수 있습니다.
오류: base64: illegal data at input byte
원인 및 해결: 응답에 잘못된 문자가 포함되었거나 내용이 잘렸거나 애초에 Base64 텍스트가 아닙니다. 먼저 본문 앞부분을 확인한 다음 구독 소스에서 전체 링크를 다시 복사하세요. 토큰이 포함된 원문은 온라인 도구에 업로드하지 마세요.
오류: invalid character '<' looking for beginning of value
원인 및 해결: 파서는 구조화된 데이터를 예상했지만 HTML 태그로 시작하는 웹페이지를 받았습니다. 최종 리디렉션 주소, 로그인 상태와 서버 인증 페이지를 확인하세요.
오류: failed to parse subscription content
원인 및 해결: 본문은 다운로드되었지만 클라이언트가 지원하는 구독 형식과 일치하지 않습니다. 웹페이지 안내문이 아닌지 확인하고 클라이언트를 현재 안정 버전으로 업데이트한 뒤 다시 시도하세요.
결론: 먼저 본문 앞 100자를 확인하세요
상태 코드가 200인데도 파싱에 실패한다면 본문 시작 부분을 확인하는 것이 반복 업데이트보다 진단에 더 유용합니다. HTML, 오류 객체 또는 접근 안내가 보이면 바로 구독 소스를 확인하세요. 먼저 라우팅과 노드 매개변수를 바꿀 필요는 없습니다.
4단계: UA, 인증과 요청 빈도 제한 확인
User-Agent의 약칭은 UA이며 요청을 보낸 클라이언트를 식별하는 데 사용됩니다. 일부 구독 소스는 UA에 따라 다른 형식을 반환하거나 등록된 클라이언트 식별자만 허용합니다. 브라우저에서는 정상적으로 열리지만 v2rayN 또는 v2rayNG 업데이트에서 403이 발생한다면 UA 정책을 확인해야 합니다.
v2rayN에서는 ‘구독 그룹’ → ‘구독 그룹 설정’으로 들어가 해당 그룹을 선택한 뒤 구독 주소와 User-Agent 항목을 확인하세요. 구독 서비스가 명확한 요구 사항을 제시한 경우에만 값을 변경해야 합니다. 브라우저 식별자를 임의로 입력하면 서버가 웹페이지 버전을 반환하여 파서가 HTML을 받게 될 수 있습니다.
인증 오류는 토큰 만료, 계정 상태 변경, 과도한 동시 요청 또는 짧은 시간 내 업데이트 횟수 제한 때문에 발생할 수도 있습니다. ‘모든 구독 업데이트’를 연속해서 클릭하면 429 응답이 더 많이 발생합니다. 빈도 제한이 나타나면 로컬 포트를 바꾸지 말고 재시도를 중단한 뒤 서버가 정한 대기 시간이 지나기를 기다리세요.
오류: Response status code does not indicate success: 403 (Forbidden)
원인 및 해결: 서버가 권한 없는 요청으로 판단했습니다. 토큰, UA, 접속 네트워크 또는 계정 정책이 관련되었을 수 있습니다. 구독 서비스 안내를 확인하고 구독 그룹에서 지정된 UA를 사용하세요.
오류: Response status code does not indicate success: 429 (Too Many Requests)
원인 및 해결: 짧은 시간에 요청 횟수 제한을 초과했습니다. 자동 업데이트와 수동 연속 클릭을 중단하고 10~30분 후 요청을 한 번만 보내세요.
오류: token expired
원인 및 해결: 구독 토큰이 만료되었거나 서버에서 재설정되었습니다. 구독 주소를 다시 생성하고 클라이언트에 저장된 이전 링크를 삭제하여 백그라운드 작업이 만료된 주소에 계속 요청하지 않도록 하세요.
5단계: DNS, 시스템 프록시와 로컬 네트워크 문제 분리
같은 구독이 모바일 네트워크에서는 업데이트되지만 가정용 인터넷에서는 시간 초과가 발생한다면 먼저 DNS와 접속 경로를 확인해야 합니다. 도메인이 잘못된 주소로 해석되거나 네트워크 장비가 이전 기록을 캐시하거나 투명 리디렉션으로 안내 페이지에 연결될 수 있습니다. 이 경우 노드 목록을 다운로드하기 전에 문제가 발생하므로 VMess, VLESS 또는 Trojan 노드 매개변수를 바꿔도 소용이 없습니다.
시스템 프록시가 로컬 127.0.0.1:10809을 가리키는데 해당 코어가 아직 시작되지 않았다면 구독 요청이 바로 실패할 수 있습니다. 현재 프록시를 거쳐야만 구독을 업데이트할 수 있지만 활성 노드 자체가 이미 만료된 경우에는 ‘노드가 있어야 구독을 받고, 구독을 받아야 노드를 얻는’ 의존 관계가 생깁니다. 일시적으로 직접 연결로 업데이트하거나 연결이 확인된 보조 설정을 사용하세요.
- 먼저 현재 구독 도메인의 DNS 해석 결과를 기록한 다음 신뢰할 수 있는 다른 DNS로 전환하세요. 여러 네트워크 매개변수를 동시에 바꾸지 않는 것이 좋습니다.
- 시스템 날짜, 시간과 시간대가 올바른지 확인하세요. 오차가 크면 TLS 인증서 유효 기간 확인에 실패할 수 있습니다.
- 로컬 포트를 다른 프로세스가 사용 중인지 확인하세요. v2rayN의 일반적인 SOCKS 포트는 10808, HTTP 포트는 10809이지만 실제 값은 ‘설정’ → ‘매개변수 설정’의 로컬 수신 설정을 따릅니다.
- 브라우저 확장 프로그램을 제외한 시스템 수준 프록시 설정을 일시적으로 비활성화한 뒤 구독 직접 연결 요청을 테스트하여 프록시 루프를 배제하세요.
- 현재 가정용 인터넷과 Android 모바일 네트워크에서 각각 한 번씩 테스트하세요. 한 네트워크에서만 실패한다면 DNS, 게이트웨이와 네트워크 측 제한을 우선 확인하세요.
| 비교 테스트 | 결과 | 가능성이 높은 문제 지점 |
|---|---|---|
| 같은 링크가 가정용 인터넷에서는 실패하고 모바일 네트워크에서는 성공 | 구독 소스 자체는 정상 | 가정용 인터넷의 DNS, 게이트웨이 캐시 또는 접속 네트워크 제한 |
| 같은 네트워크에서 브라우저는 성공하고 클라이언트는 403 | 전송 경로는 대체로 연결 가능 | UA, Cookie, 리디렉션 또는 클라이언트 요청 정책 |
| 모든 네트워크에서 410 반환 | 서버에서 명시적으로 취소 | 구독 주소 만료 |
| 시스템 프록시를 끄면 복구 | 직접 연결 경로 정상 | 로컬 포트, 프록시 루프 또는 활성 노드 만료 |
결론: DNS를 계속 바꾸기보다 네트워크 간 비교가 빠릅니다
동일한 링크를 두 네트워크에서 비교하면 서버 문제와 로컬 경로 문제를 바로 나눌 수 있습니다. 양쪽 모두 실패하면 구독 소스를 확인하고, 한쪽만 실패하면 클라이언트 설정은 유지한 채 해당 네트워크를 집중적으로 점검하세요.
6단계: 클라이언트 설정, 버전과 코어 상태 재확인
앞의 5단계에서 구독 주소가 유효하고 본문 형식이 올바르며 네트워크에 연결할 수 있음을 확인한 뒤 클라이언트의 로컬 상태를 점검하세요. 먼저 구독 편집 화면을 다시 열어 링크 앞뒤의 공백, 그룹 활성화 여부와 자동 업데이트 작업이 이전 주소를 참조하는지 확인하세요. 표시 이름만 덮어쓰지 마세요. 이전 토큰이 기존 그룹에 남아 있을 수 있습니다.
v2rayN에서는 ‘구독 그룹’ → ‘구독 그룹 설정’ → 그룹 선택 → 주소 편집 순서로 작업할 수 있습니다. 저장한 뒤 ‘현재 구독 업데이트’로 한 번만 테스트하세요. 코어 관련 설정은 ‘설정’ → ‘매개변수 설정’ → ‘Core 유형’에 있지만 구독 다운로드에서 401, 403, 404가 발생할 때는 코어를 바꿀 필요가 없습니다. 해당 상태는 구독 서버가 반환한 값입니다.
v2rayNG에서는 사이드 메뉴에서 ‘구독 그룹 설정’으로 들어가 현재 항목을 편집하고 활성화 상태를 확인한 뒤 메인 화면으로 돌아와 구독을 업데이트하세요. v2flyNG는 v2fly 코어를 사용하므로 해당 코어 동작이 필요한 Android 설정에 적합합니다. 같은 구독이 특정 구버전에서만 인식되지 않는다면 먼저 클라이언트를 업데이트한 뒤 서버가 새 프로토콜 필드를 내려보내는지 비교하세요.
기존 항목 백업
현재 사용 가능한 노드 이름, 구독 그룹과 라우팅 설정을 기록하여 점검 중에도 연결 가능한 보조 설정을 덮어쓰지 않도록 하세요.
그룹 재생성
임시 구독 그룹을 새로 만들고 다시 발급받은 전체 주소를 붙여 넣은 뒤 이 항목만 활성화하여 테스트하세요.
한 번만 업데이트
현재 그룹을 한 번만 업데이트하고 상태 코드, 소요 시간과 업데이트 전후의 노드 수를 기록하세요.
포트 확인
10808, 10809 또는 사용자 지정 수신 포트가 사용 중이지 않은지 확인하고 시스템 프록시가 가리키는 포트와 클라이언트의 실제 수신 포트가 일치하는지 확인하세요.
클라이언트 업데이트
최신 안정 버전의 v2rayN, v2rayNG 또는 v2flyNG로 다시 테스트하여 구버전 파서가 새 필드를 인식하지 못하는 경우를 배제하세요.
오류: address already in use
원인 및 해결: 로컬 수신 포트를 다른 프로세스가 사용 중입니다. 중복 실행된 클라이언트를 종료하거나 ‘설정’ → ‘매개변수 설정’에서 사용하지 않는 포트로 바꾸고 시스템 프록시 설정도 함께 변경하세요.
오류: no valid profile found
원인 및 해결: 구독 업데이트 후 사용할 수 있는 설정이 생성되지 않았습니다. 반환 본문이 비어 있지 않은지 확인하고 공유 링크에 서버, 포트와 인증 정보가 모두 포함되어 있는지 확인하세요.
결과로 문제의 원인 범위 확정하기
여러 네트워크와 여러 클라이언트에서 401, 403, 404, 410 또는 429가 동일하게 발생한다면 문제는 대개 구독 소스나 계정 정책에 있습니다. 구독 서비스 운영자에게 문의할 때는 발생 시각, 상태 코드, 클라이언트 이름과 네트워크 유형만 제공하고 전체 토큰은 보내지 마세요.
브라우저와 다른 클라이언트에서 동일한 본문을 가져오는데 특정 구버전 클라이언트만 파싱에 실패한다면 클라이언트 버전, 구독 형식 호환성과 개별 공유 링크 필드를 중점적으로 확인하세요. 네트워크를 바꾸자마자 복구된다면 전체 노드를 다시 만들 필요 없이 DNS, 시스템 프록시와 접속 네트워크를 점검하면 됩니다.
마지막으로 노드 연결을 확인하세요. 구독 업데이트 성공은 노드 목록이 클라이언트에 기록되었다는 뜻일 뿐 모든 서버에 연결할 수 있다는 의미는 아닙니다. 노드 하나를 선택해 주소 확인, 포트 연결 가능 여부, TLS 도메인, 전송 방식과 라우팅 분할을 점검하세요. 이는 연결 단계의 문제이므로 구독 다운로드 단계와 나누어 기록해야 합니다.
최종 판단: 상태 코드, 본문과 네트워크 비교로 원인을 분류하세요
상태 코드는 서버가 요청을 수락했는지 확인하고, 본문은 파서가 실제로 받은 내용을 보여 주며, 네트워크 비교는 문제가 로컬 경로에 국한되는지 알려 줍니다. 세 가지 증거가 일치한 뒤 설정을 변경해야 유효한 구독을 삭제하거나 클라이언트를 반복 재설치하는 일을 피할 수 있습니다.