먼저 다운로드 실패와 콘텐츠 파싱 실패를 구분한 뒤 구독 주소, HTTP 응답, 인코딩 형식, 프록시 경로와 클라이언트 버전을 차례로 확인하세요. v2rayN, v2rayNG, v2flyNG 업데이트 후 목록이 비거나 일부 노드가 누락되고 형식 오류가 발생할 때 유용합니다.
먼저 실패가 발생한 단계를 판단하세요
구독 업데이트는 하나의 동작이 아니라 연속된 처리 과정입니다. 클라이언트가 저장된 URL을 읽고, 직접 연결 또는 로컬 프록시를 통해 HTTPS 요청을 보냅니다. 서버가 본문을 반환하면 클라이언트는 Base64, 공유 링크 목록 또는 구조화된 설정을 식별한 뒤 VMess, VLESS 등의 항목을 해당 구독 그룹에 기록합니다. 어느 한 단계라도 실패하면 화면에는 ‘업데이트 실패’ 또는 노드 0개만 표시될 수 있습니다.
처음부터 모든 설정을 삭제하지 마세요. 업데이트 시간, 응답 상태와 로그의 핵심 단어를 먼저 확인해 ‘요청이 콘텐츠를 받지 못한 문제’인지 ‘콘텐츠는 받았지만 파싱하지 못한 문제’인지 판단해야 합니다. 전자는 DNS, 프록시, 인증서, 접근 권한과 HTTP 상태가 원인인 경우가 많고, 후자는 웹 페이지 응답, 손상된 인코딩 또는 현재 버전에서 지원하지 않는 프로토콜 필드가 원인인 경우가 많습니다.
| 화면에 나타난 현상 | 우선 확인할 항목 | 일반적인 판단 |
|---|---|---|
| 즉시 연결 실패 표시 | DNS, 프록시 경로, 포트 | 아직 구독 본문을 받지 못함 |
| 몇 초 후 403 또는 404 표시 | 링크 유효 기간과 접근 권한 | 서버가 거부했거나 리소스가 만료됨 |
| 업데이트는 성공했지만 노드가 0개 | 응답 콘텐츠와 인코딩 | 본문이 비었거나 웹 페이지이거나 인식 가능한 항목이 없음 |
| 일부 노드만 가져오기 | 클라이언트 버전과 필드 지원 여부 | 현재 클라이언트가 일부 프로토콜 매개변수를 인식하지 못함 |
결론: 요청 오류와 파싱 오류를 먼저 구분하세요
로그에 HTTP 상태 코드, 시간 초과 또는 도메인 확인 관련 메시지가 나타나면 먼저 네트워크 요청을 해결하세요. Base64, JSON, URI 또는 필드 오류가 나타날 때는 본문 형식을 확인해야 합니다. 순서를 거꾸로 하면 불필요한 작업이 늘어납니다.
순서대로 6단계 점검하기
아래 순서는 위험이 낮은 확인부터 시작하며 기존 노드를 먼저 덮어쓰지 않습니다. v2rayN 7.14.3의 메뉴 구성을 기준으로 했으며 세부 버전에 따라 문구 위치는 달라질 수 있지만 구독 그룹, 로그, 매개변수 설정의 세 가지 진입점은 동일합니다. Android에서는 v2rayNG 또는 v2flyNG의 구독 설정과 로그 화면에서 같은 방식으로 확인할 수 있습니다.
현재 설정 백업하기
기존 구독 그룹과 사용 가능한 노드를 유지하고 목록을 먼저 비우지 마세요. 실패한 그룹 이름, 마지막 성공 업데이트 시간과 이번 오류 원문을 기록하면 수정 전후 변화를 비교하기 쉽습니다.
전체 링크 확인하기
v2rayN에서 「구독 그룹」→「구독 그룹 설정」을 열고 URL의 시작 부분, 도메인, 경로, 쿼리 매개변수가 제공자가 안내한 내용과 완전히 일치하는지 확인하세요. 특히 물음표 뒤의 토큰을 빠뜨리지 않아야 합니다.
먼저 직접 연결로 업데이트하기
「구독 그룹」→「모든 구독 업데이트(프록시 사용 안 함)」를 선택하세요. 직접 연결이 성공하면 구독 형식은 인식할 수 있다는 뜻이며, 문제는 로컬 프록시 포트, 현재 노드 또는 라우팅 규칙에 집중됩니다.
그다음 프록시로 업데이트하기
일반 업데이트 방식으로 전환하세요. 프록시를 통해서만 성공한다면 시스템 네트워크가 구독 도메인에 직접 연결되는지 확인하고, 직접 연결만 성공한다면 프록시 출구와 구독 도메인의 분기 설정을 확인하세요.
로그 원문 확인하기
주 창 하단의 로그 영역을 열고 업데이트를 실행한 시점에서 403, 404, timeout, Base64, JSON, URI 등의 키워드를 찾으세요. 상단에 표시되는 짧은 안내만으로 판단하지 마세요.
클라이언트 업데이트 후 재테스트하기
그룹 설정은 유지한 채 다운로드 페이지에서 제공하는 최신 버전으로 업그레이드하세요. 클라이언트를 다시 시작한 뒤 문제가 발생한 그룹만 업데이트하고 노드 수와 로그가 변했는지 비교합니다.
한 그룹만 실패하고 다른 그룹은 정상이라면 전체 네트워크를 조정할 필요가 없는 경우가 많습니다. 먼저 해당 URL의 유효 기간, 권한과 응답 형식을 확인하세요. 모든 그룹이 동시에 실패한다면 네트워크, 시스템 시간, 로컬 프록시 포트와 클라이언트의 네트워크 접근이 방화벽에 차단되지 않았는지부터 확인해야 합니다.
구독 링크와 HTTP 응답 확인하기
구독 URL에는 계정 식별에 사용하는 경로 또는 쿼리 매개변수가 포함되는 경우가 많습니다. 복사할 때 문자 하나를 빠뜨리거나 끝의 공백까지 저장하거나 줄바꿈 지점까지만 복사하면 서버의 응답이 달라집니다. 일부 주소에는 유효 기간이나 기기 제한도 있으므로 도메인에 여전히 접속되더라도 오래된 링크가 401, 403, 404 또는 안내 페이지를 반환할 수 있습니다.
브라우저에서 링크가 열린다고 해서 클라이언트에서도 반드시 업데이트되는 것은 아닙니다. 브라우저는 로그인 상태를 저장했거나 다른 시스템 프록시를 사용할 수 있지만, 클라이언트는 대개 URL에 직접 요청을 보내고 본문을 구독 형식으로 파싱합니다. 반대로 브라우저에 긴 문자열이 표시된다고 해서 콘텐츠가 올바른 것도 아닙니다. 서버가 텍스트를 반환했다는 사실만 알 수 있습니다.
오류: Response status code does not indicate success: 403 (Forbidden)
원인 및 해결 방법: 서버가 유효하지 않은 토큰, 변경된 접근 권한 또는 규칙에 맞지 않는 요청 출처를 감지했습니다. 최신 구독 주소를 다시 발급받아 기존 URL 전체를 교체하세요. 일부 문자만 수정하지 마세요.
오류: Response status code does not indicate success: 404 (Not Found)
원인 및 해결 방법: 구독 경로가 폐기되었거나 이전되었거나 불완전하게 복사되었습니다. 구독 제공 페이지에서 주소를 다시 복사하고 경로 끝부분과 쿼리 매개변수가 모두 포함되었는지 확인하세요.
오류: The operation has timed out
원인 및 해결 방법: 정해진 시간 안에 완전한 응답을 받지 못했습니다. 직접 연결과 프록시 연결로 각각 업데이트를 테스트한 뒤 DNS, 현재 출구와 서버 연결 상태를 확인하세요.
오류: The remote name could not be resolved
원인 및 해결 방법: 구독 도메인에서 유효한 DNS 결과를 얻지 못했습니다. 도메인 철자를 확인하고 사용 가능한 DNS로 전환한 뒤 네트워크에 다시 연결하여 해당 그룹만 한 번 더 업데이트하세요.
추가 확인이 필요하다면 신뢰할 수 있는 환경에서 응답 상태, 본문 시작 부분과 바이트 수를 확인할 수 있습니다. 정상적인 구독은 대개 상태 200을 반환하며, 본문에는 디코딩 가능한 텍스트, 프로토콜 접두사로 시작하는 여러 줄의 링크 또는 클라이언트가 명확히 지원하는 구조화된 콘텐츠가 있어야 합니다. 본문이 HTML 태그, 로그인 안내, 인증 코드 안내 또는 게이트웨이 오류 텍스트로 시작한다면 문제는 VMess, VLESS 노드 매개변수가 아니라 서버가 반환한 콘텐츠에 있습니다.
- 상태 200인데 본문 길이가 수십 바이트뿐인 경우: ‘링크가 만료되었습니다’와 같은 일반 텍스트 안내가 반환되었는지 확인하세요.
- 상태 200이고 본문이 웹 페이지 태그로 시작하는 경우: 클라이언트가 웹 페이지를 구독으로 파싱하므로 JSON 또는 Base64 오류가 자주 발생합니다.
- 상태 301 또는 302: 리디렉션된 주소에도 인증 매개변수가 유지되는지, 클라이언트 버전이 해당 리디렉션을 올바르게 처리하는지 확인하세요.
- 상태 429: 짧은 시간에 요청이 너무 많이 발생한 것입니다. 연속 새로 고침을 중지하고 서버 제한이 해제된 뒤 다시 테스트하세요.
Base64, 공유 링크와 형식 불일치 구분하기
기존 구독은 여러 줄의 공유 링크 전체를 Base64로 인코딩하는 경우가 많습니다. 클라이언트는 본문을 받은 뒤 먼저 디코딩하고 줄마다 vmess://, vless:// 등의 항목을 식별합니다. 인코딩하지 않은 공유 링크 목록을 직접 반환하는 구독도 있으므로 ‘Base64가 아님’ 자체가 오류는 아닙니다. 중요한 것은 클라이언트가 반환된 실제 형식을 인식할 수 있는지입니다.
VMess 단일 노드 링크와 전체 구독에는 각각 별도의 인코딩 계층이 포함될 수 있습니다. 구형 VMess 링크는 프로토콜 접두사 뒤에 인코딩된 JSON을 넣는 경우가 많고, VLESS는 일반적으로 URI 쿼리 매개변수로 전송 방식, 암호화 계층과 서버 이름을 표현합니다. 제공자가 불완전한 이스케이프나 잘린 인코딩 문자열 또는 현재 클라이언트가 지원하지 않는 새 필드를 생성하면 일부 노드만 누락되거나 전체 구독의 파싱이 중단될 수 있습니다.
dmxlc3M6Ly9leGFtcGxl
vless://[email protected]:443?type=ws&security=tls
<html>Access denied</html>위의 세 가지 시작 형태는 각각 Base64로 인코딩된 텍스트, 일반 텍스트 공유 링크와 오류 웹 페이지일 가능성을 나타냅니다. 실제 점검에서는 형식의 특징만 확인하고, 접근 토큰이 포함된 전체 구독 본문을 공개 디코딩 페이지에 제출하지 마세요. 구독 주소 자체에 노드 목록을 읽을 권한이 있는 경우가 많으므로 계정 인증 정보처럼 취급해야 합니다.
| 본문 특징 | 가능한 형식 | 처리 방법 |
|---|---|---|
| 연속된 문자와 숫자, 소량의 등호 | 전체 Base64 인코딩 | 잘렸거나 공백이 섞였거나 호환되지 않는 문자가 사용되었는지 확인 |
| 각 줄이 프로토콜 접두사로 시작 | 일반 텍스트 공유 링크 목록 | 클라이언트 버전이 해당 프로토콜과 쿼리 필드를 지원하는지 확인 |
| 왼쪽 중괄호 또는 대괄호로 시작 | JSON 또는 구조화된 목록 | 해당 구조가 클라이언트에서 지원하는 구독 형식인지 확인 |
| html, title, Access denied가 나타남 | 웹 페이지 또는 게이트웨이 오류 | 링크 권한, 네트워크 진입 경로 또는 서버 응답 수정 |
| 본문이 비어 있음 | 빈 응답 | 구독을 다시 생성하고 계정에 사용 가능한 항목이 있는지 확인 |
오류: The input is not a valid Base-64 string
원인 및 해결 방법: 본문이 Base64로 처리되었지만 웹 안내 문구, 공백, 잘못된 문자 또는 잘린 콘텐츠가 섞여 있습니다. 먼저 HTTP 응답의 실제 본문을 확인한 뒤 완전한 구독을 다시 받으세요.
오류: Unexpected character encountered while parsing value: <
원인 및 해결 방법: 파서는 JSON을 예상했지만 첫 위치에서 웹 페이지 태그를 읽었습니다. 로그인 페이지, 접근 제한, 게이트웨이 오류와 리디렉션 결과를 확인하고 노드 필드를 계속 수정하지 마세요.
오류: Invalid URI: The format of the URI could not be determined
원인 및 해결 방법: 디코딩된 줄 중 하나가 완전한 공유 링크가 아닙니다. 줄바꿈 오류, 프로토콜 접두사 누락 또는 매개변수 이스케이프 오류가 흔한 원인입니다. 구독을 다시 생성한 뒤 최신 클라이언트로 가져오세요.
결론: 먼저 본문 형식을 확인한 뒤 노드 매개변수를 살펴보세요
응답이 실제로 웹 페이지, 빈 텍스트 또는 접근 안내라면 UUID, 포트와 전송 매개변수를 조정해도 구독은 복구되지 않습니다. 먼저 클라이언트가 올바른 목록을 받도록 해야 합니다.
프록시, DNS와 로컬 포트 점검하기
구독 요청은 직접 연결하거나 현재 프록시 출구를 통해 보낼 수 있습니다. 프록시로 업데이트하려면 클라이언트에 먼저 실행 가능하고 네트워크에 연결되는 기존 노드가 있어야 합니다. 현재 노드가 이미 만료되었다면 구독 요청도 함께 막혀 ‘연결하려면 업데이트가 필요하지만 업데이트하려면 현재 연결이 필요하다’는 순환이 생깁니다. 이때 프록시를 사용하지 않는 업데이트 메뉴로 문제를 확인하는 것이 가장 쉽습니다.
로컬 포트는 클라이언트의 실제 설정을 기준으로 확인해야 합니다. v2rayN에서 흔히 보이는 로컬 포트 예시는 10808이지만, 매개변수 변경, 설정 이전 또는 여러 인스턴스 동시 실행 후에는 포트가 달라질 수 있습니다. 시스템 프록시에 여전히 127.0.0.1:10808이 적혀 있다고 해서 클라이언트가 현재도 해당 포트를 수신 중이라고 단정하지 마세요.
- 「설정」→「매개변수 설정」에서 로컬 수신 포트를 확인하고 해당 포트를 다른 프로세스가 사용하고 있지 않은지 확인하세요.
- 중복 실행 중인 v2rayN 인스턴스를 잠시 종료한 뒤 주 프로그램 하나만 실행하여 테스트하세요.
- 만료된 노드에 의존하는 프록시 업데이트 방식을 먼저 끄고 「모든 구독 업데이트(프록시 사용 안 함)」를 한 번 실행하세요.
- 직접 연결은 실패하고 프록시는 성공한다면 구독 도메인의 DNS 조회 결과와 직접 연결 경로를 확인하세요.
- 프록시는 실패하고 직접 연결은 성공한다면 현재 노드 상태, 프록시 아웃바운드와 구독 도메인이 잘못 분기되지 않았는지 확인하세요.
- 시스템 날짜, 시간과 시간대를 바로잡으세요. 시스템 시간이 크게 어긋나면 HTTPS 인증서 유효 기간 판단에 영향을 줍니다.
라우팅 규칙이 구독 도메인을 사용할 수 없는 출구로 보낼 수도 있습니다. 예를 들어 도메인 매칭 규칙이 삭제된 아웃바운드 태그를 지정하면 일반 웹 페이지는 열리지만 해당 도메인 요청은 계속 실패할 수 있습니다. 직접 연결 업데이트가 임시로 성공했다면 라우팅 설정으로 돌아가 도메인 규칙, 규칙 순서와 출구 태그를 확인하세요. 계속 전환하는 방식에 의존하지 마세요.
Android에서도 점검 방식은 같습니다. v2rayNG는 Xray 코어를 사용하고 v2flyNG는 v2fly 코어를 사용합니다. 구독 다운로드는 클라이언트가 담당하며 노드 연결 단계에서 해당 코어가 처리합니다. 구독 다운로드 단계에서 이미 403 또는 오류 웹 페이지가 반환되었다면 Core 유형을 바꿔도 서버 응답은 달라지지 않습니다.
클라이언트 버전과 코어 유형 판단하기
클라이언트 버전이 오래되면 모든 구독이 실패하기보다 새 형식의 노드가 누락되거나 일부 쿼리 매개변수가 무시되거나 가져온 뒤 유효한 설정을 생성하지 못하는 경우가 많습니다. 구독 제공자가 필드 이름, 전송 조합 또는 출력 구조를 변경하면 구버전 파서는 호환되지 않을 수 있습니다. 클라이언트를 업그레이드한 뒤 기존 그룹은 유지하고 같은 URL을 다시 업데이트하여 노드 수와 로그 변화를 기준으로 판단하세요.
| 현상 | 가능성이 높은 단계 | 권장 조치 |
|---|---|---|
| 모든 URL을 다운로드할 수 없음 | 네트워크 또는 클라이언트 요청 단계 | 직접 연결, 프록시, DNS, 시스템 시간과 방화벽 확인 |
| 같은 구독을 최신 버전에서는 가져올 수 있음 | 구버전 파서 호환성 | 클라이언트를 업그레이드하고 해당 그룹을 다시 업데이트 |
| 가져오기는 되지만 코어 시작 실패 | 노드 필드 또는 코어 지원 여부 | 코어 로그를 확인하고 Core 유형 점검 |
| 일부 VLESS 항목만 실패 | 전송, 보안 매개변수 또는 필드 조합 | 실패한 항목과 정상 항목의 쿼리 매개변수 비교 |
| 노드 수는 정상인데 인터넷에 연결되지 않음 | 구독 단계가 아닌 연결 단계 | 서버 주소, 포트, 라우팅과 현재 출구 확인 |
v2rayN에서 「설정」→「매개변수 설정」→「Core 유형」은 특정 프로토콜 설정을 어떤 코어로 실행할지 결정합니다. 이 설정은 노드 시작과 설정 생성에 영향을 주지만 모든 구독 파싱 오류를 해결하는 범용 스위치는 아닙니다. 로그에 응답 상태, 다운로드 시간 초과 또는 Base64 실패가 명확히 표시되면 먼저 상위 단계의 문제를 처리하세요.
Android에서는 v2rayNG와 v2flyNG의 코어 경로를 구분해야 합니다. 둘 다 일반적인 공유 링크를 읽을 수 있지만 새로 추가된 특정 필드의 지원 시점은 다를 수 있습니다. 구독을 이전할 때는 목록에 포함된 프로토콜과 전송 매개변수를 먼저 확인한 뒤 알맞은 클라이언트를 선택하세요. 앱이 URL을 저장할 수 있는지만으로 호환성을 판단하지 마세요.
오류: Failed to parse subscription content
원인 및 해결 방법: 클라이언트는 본문을 받았지만 유효한 구독 항목을 인식하지 못했습니다. 본문 형식을 확인하고 클라이언트를 업그레이드하세요. 최신 버전에서도 실패한다면 구독 제공자에게 호환 가능한 형식으로 다시 생성해 달라고 요청해야 합니다.
오류: Unsupported protocol
원인 및 해결 방법: 구독에 현재 클라이언트 또는 코어가 지원하지 않는 프로토콜 식별자가 포함되어 있습니다. 항목이 VMess, VLESS 등 지원되는 유형인지 확인하고 해당 형식에 맞는 클라이언트 버전으로 업데이트하세요.
수정 후 결과를 확인하는 방법
한 번의 업데이트에서 ‘성공’이 표시되었다고 문제가 완전히 해결된 것은 아닙니다. 그룹 업데이트 시간, 노드 수, 노드 필드와 실제 연결을 함께 확인해야 합니다. 기존에 24개였던 노드가 업데이트 후 3개만 남았다면 구독 서버가 목록을 변경했거나 파서가 나머지 21개를 건너뛴 것일 수 있습니다. 이때는 성공 안내보다 로그의 개별 경고가 더 중요합니다.
- 대상 구독 그룹의 업데이트 시간이 실제로 변경되었는지 확인하세요. 이름이 같은 다른 그룹을 업데이트한 것이 아닌지 주의해야 합니다.
- 업데이트 전후 노드 수를 기록하세요. 예를 들어 0개에서 24개로 복구되었는지, 24개에서 비정상적으로 3개로 줄었는지 확인합니다.
- VMess 항목 하나와 VLESS 항목 하나를 무작위로 확인하여 주소, 포트, 전송 유형과 서버 이름 필드를 점검하세요.
- 노드 하나를 실행하여 코어 로그에 설정 생성 오류나 지원되지 않는 필드 오류가 없는지 확인하세요.
- 클라이언트를 종료하고 다시 시작한 뒤 특정 그룹만 한 번 더 업데이트하여 같은 결과가 재현되는지 확인하세요.
네트워크를 바꾼 직후 복구되고 기존 네트워크에서는 계속 실패한다면 DNS, 접근 정책과 출구 라우팅을 중점적으로 확인하세요. URL을 다시 생성한 뒤 복구되었다면 기존 토큰이나 경로가 만료된 것입니다. 클라이언트 업그레이드 후에만 복구되었다면 새 버전을 유지하고 다른 구독 그룹에도 구버전 파서가 건너뛴 항목이 없는지 확인하세요.
업데이트는 성공했지만 목록이 여전히 비어 있으면 어떻게 하나요?
현재 화면에 표시된 구독 그룹을 업데이트했는지 먼저 확인한 뒤 응답 본문이 비어 있는지, 웹 페이지인지, 그룹 필터가 새 항목을 숨기고 있는지 점검하세요. 로그에서 프로토콜 링크가 하나도 파싱되지 않았다면 구독을 다시 받으세요.
브라우저에서는 열리는데 왜 v2rayN에서는 계속 실패하나요?
브라우저와 클라이언트가 서로 다른 프록시 경로, DNS와 로그인 상태를 사용할 수 있습니다. 페이지가 열리는지만 보지 말고 클라이언트 로그의 HTTP 상태와 브라우저의 최종 응답을 비교하세요.
성공할 때까지 업데이트를 계속 눌러도 되나요?
연속해서 요청하는 것은 권장하지 않습니다. 서버가 429를 반환하거나 요청 빈도 제한이 있다면 반복 새로 고침으로 대기 시간이 늘어날 수 있습니다. 한 번의 전체 오류를 기록하고 네트워크나 링크를 수정한 뒤 다시 테스트하는 편이 효과적입니다.
코어를 바꾸면 Base64 오류를 해결할 수 있나요?
대개 해결되지 않습니다. Base64 오류는 노드가 코어에 전달되어 실행되기 전인 구독 본문 파싱 단계에서 발생합니다. 응답 콘텐츠가 완전한지, 웹 텍스트가 섞이지 않았는지와 클라이언트 파서 버전을 먼저 확인하세요.
최종 판단: 재현 가능한 결과로 점검을 마무리하세요
같은 그룹을 연속 두 번 업데이트했을 때 노드 수가 일치하고, 재시작 후에도 업데이트되며, 노드 하나 이상이 정상적으로 설정을 생성해야 링크, 파싱과 실행 경로가 모두 복구되었다고 볼 수 있습니다.