구독 업데이트 실패가 모든 노드의 만료를 의미하는 것은 아닙니다. 클라이언트가 구독을 업데이트하려면 도메인 확인, 서버 연결, HTTP 응답 수신, 본문 읽기, 인코딩 확인, 공유 링크 파싱, 로컬 설정 저장을 모두 완료해야 합니다. 어느 한 단계라도 중단되면 화면에는 “업데이트 실패”, “파싱 오류” 또는 “사용 가능한 서버를 찾을 수 없음”만 표시될 수 있습니다.

문제를 확인할 때 기존 노드를 먼저 삭제하거나 클라이언트를 반복해서 재설치하지 마세요. 현재 설정과 로그를 보존한 뒤, 실패 지점이 네트워크 요청 단계인지 콘텐츠 파싱 단계인지부터 확인하세요. 이 구분만으로 점검 범위를 수십 가지에서 두세 가지로 줄일 수 있습니다.

이 글 한눈에 보기

이 글은 v2rayN, v2rayNG 또는 v2flyNG에서 VMess, VLESS 등의 구독을 업데이트할 때 시간 초과, 빈 목록, 형식 오류 또는 HTTP 상태 이상을 겪는 사용자를 위한 안내입니다. “링크 유효성 → 주소 완전성 → 응답 형식 → 클라이언트 버전 → 네트워크 경로 → 응답 본문” 순서로 확인하면 기존 노드를 변경하지 않고도 대개 문제 지점을 찾을 수 있습니다.

먼저 실패 단계 확인: 요청, 응답, 파싱 중 어디인가

구독 업데이트는 세 단계로 나눌 수 있습니다. 첫 번째는 요청 단계로, 클라이언트가 구독 도메인을 확인하고 서버에 연결합니다. 두 번째는 응답 단계로, 서버가 상태 코드와 응답 헤더, 본문을 반환합니다. 세 번째는 파싱 단계로, 클라이언트가 본문에서 VMess, VLESS 등의 공유 링크를 인식한 뒤 유효한 항목을 구독 그룹에 저장합니다.

“시간 초과”, “호스트 이름을 확인할 수 없음”, “연결이 거부됨”은 대개 요청 단계에 해당합니다. “401”, “403”, “404”, “500”은 응답 단계입니다. “유효한 서버 없음”, “지원하지 않는 형식”, “Base64 디코딩 실패”는 파싱 단계에 해당합니다. 팝업 제목만 기억하지 말고 원문 메시지를 먼저 기록하세요.

  • 요청 단계: DNS, 네트워크 연결 가능 여부, 시스템 시간, 현재 프록시를 통해 업데이트해야 하는지 확인합니다.
  • 응답 단계: 링크 만료 여부, 접근 권한 변경 여부, 서버 리디렉션 또는 일시적 장애 여부를 확인합니다.
  • 파싱 단계: 반환된 본문이 대상 구독 형식인지, 클라이언트가 포함된 프로토콜 필드를 지원하는지 확인합니다.
  • 저장 단계: 구독 그룹 활성화 여부, 동일한 이름의 노드 필터링 여부, 업데이트 후 올바른 그룹으로 전환했는지 확인합니다.
200
정상 HTTP 상태 코드
10초
첫 연결 관찰 시간
10808
일반적인 로컬 SOCKS 포트
10809
일반적인 로컬 HTTP 포트

원인 1·2: 링크 만료 또는 주소 오입력

가장 흔한 원인은 링크 자체가 이미 만료된 경우입니다. 구독 주소에는 계정이나 설정 모음을 식별하는 긴 문자열이 포함되는 경우가 많습니다. 서버가 주소를 변경하거나 기존 링크를 폐기하거나 접근 기간을 조정하면 이전 주소가 401, 403, 404를 반환하거나 안내 페이지로 리디렉션될 수 있습니다. 이때 클라이언트는 연결에는 성공하지만 파싱할 노드 데이터를 받지 못합니다.

두 번째 원인은 주소가 완전히 복사되지 않은 경우입니다. 채팅 창의 자동 줄바꿈, 브라우저에서 일부만 선택된 경우, 끝에 붙은 마침표, 매개변수의 & 이스케이프 처리만으로도 실제 요청 주소가 달라집니다. 특히 ?token=, &type= 또는 퍼센트 인코딩이 포함된 긴 링크는 문자 하나만 빠져도 전혀 다른 응답을 반환할 수 있습니다.

오류: Response status code does not indicate success: 401

원인 및 해결: 서버가 현재 인증 정보를 거부했습니다. 구독이 아직 유효한지 확인하고 원본 관리 페이지에서 전체 주소를 다시 복사하세요.

오류: The remote server returned an error: 403 Forbidden

원인 및 해결: 주소는 유효하지만 접근 조건을 충족하지 못했습니다. 링크가 교체되지 않았는지 확인하고 브라우저 방문 기록에 남은 이전 주소를 계속 사용하지 마세요.

오류: Response status code does not indicate success: 404

원인 및 해결: 요청 경로가 존재하지 않습니다. 도메인 뒤의 경로, 슬래시, 쿼리 매개변수, 복사 과정에서 빠진 마지막 문자를 중점적으로 확인하세요.

  1. 구독 설정에서 편집 화면을 열고 원본과 대조하면서 주소의 시작 부분, 도메인, 경로, 쿼리 매개변수를 문자 단위로 확인하세요.
  2. 링크 앞뒤의 공백, 줄바꿈, 한글 문장 부호를 삭제하되 링크 중간에 이미 포함된 퍼센트 인코딩은 수정하지 마세요.
  3. 원본에서 새 구독 주소를 제공했다면 새 구독 그룹을 만들어 테스트하세요. 되돌릴 수 있는 기존 그룹을 바로 덮어쓰지 마세요.
  4. 401, 403 또는 404가 표시될 때 DNS, 포트 또는 코어를 계속 바꾸는 것은 대개 도움이 되지 않습니다. 먼저 주소와 접근 권한을 확인하세요.

원인 3: 응답 콘텐츠 인코딩이 클라이언트의 예상과 다름

구독은 하나의 표준 파일 형식으로만 이루어지지 않습니다. 흔히 Base64로 감싼 여러 줄 공유 링크, 그대로 반환되는 일반 텍스트 링크 목록, 클라이언트 유형에 따라 서버가 생성하는 전용 구조가 사용됩니다. VMess 공유 항목에는 인코딩된 JSON 데이터가 포함되는 경우가 많고, VLESS는 일반적으로 URI 형식을 사용하며 쿼리 매개변수로 전송 방식, 보안 계층, 서비스 이름 등을 지정합니다.

문제는 “요청에는 성공했지만 콘텐츠 유형이 다른” 경우에 자주 발생합니다. 예를 들어 서버가 요청 매개변수에 따라 다른 클라이언트 설정을 반환하거나, 링크가 실제로 로그인 페이지를 가리키거나, 리버스 프록시가 오류 페이지를 HTTP 200으로 반환하거나, 본문에 안내 문구만 들어 있을 수 있습니다. 정상 상태 코드는 서버가 응답했다는 뜻일 뿐, 그 응답이 사용 가능한 구독이라는 뜻은 아닙니다.

응답 콘텐츠 특징 클라이언트 동작 우선 확인할 항목
여러 줄의 vmess://, vless:// 대개 바로 인식 가능 링크가 완전한지, 프로토콜 필드를 현재 코어가 지원하는지
연속된 긴 문자·숫자 및 인코딩 문자 클라이언트가 Base64 디코딩을 시도함 본문이 잘리지 않았는지, 앞뒤에 안내 문구가 섞이지 않았는지
<html 또는 웹 페이지 제목으로 시작 파싱 실패 또는 유효한 노드 없음 표시 로그인 페이지, 오류 페이지 또는 접근 안내 페이지로 이동했는지
공유 링크가 없는 구조화된 설정 목록이 비어 있거나 형식을 지원하지 않음 구독 유형 매개변수를 잘못 선택했는지, 반환 형식이 현재 클라이언트에 맞는지
본문 길이가 0 업데이트는 완료됐지만 노드 수가 0 서버의 생성 작업, 캐시 및 상위 데이터 소스

결론: HTTP 200은 구독 유효성을 증명하지 않음

요청에는 성공했지만 추가된 노드 수가 0이라면 로컬 수신 포트를 계속 바꾸기보다 본문 유형과 앞부분 수십 글자를 먼저 확인하세요.

원인 4: 오래된 클라이언트 버전 또는 코어 기능 불일치

구독 파싱은 클라이언트가 담당하고, 노드 연결은 V2Ray 또는 Xray 코어가 수행합니다. 클라이언트 버전이 오래되면 새 쿼리 매개변수, 전송 조합 또는 구독 필드를 인식하지 못할 수 있습니다. 코어 버전이 낮으면 노드가 목록에 가져와지더라도 시작 시 알 수 없는 필드, 잘못된 설정 또는 지원되지 않는 전송 설정 오류가 발생할 수 있습니다.

v2rayN은 데스크톱 환경에서 사용하며 다양한 코어와 구독 그룹을 관리할 수 있습니다. v2rayNG는 Xray 코어를 사용하고, v2flyNG는 v2fly 코어를 사용합니다. 세 클라이언트의 인터페이스, 기본값, 프로토콜 지원 범위는 완전히 같지 않습니다. 한 클라이언트에서 같은 구독을 가져올 수 있다고 해서 모든 노드가 다른 코어에서도 시작된다는 뜻은 아닙니다.

v2rayN 7.x
데스크톱 인터페이스 점검 기준
v2rayNG 1.10.x
Android Xray 클라이언트 점검 기준
2개 계층
클라이언트 파싱 및 코어 실행
  • 가져오기가 전혀 되지 않음: 먼저 클라이언트 본체를 업데이트한 뒤 구독 그룹을 다시 만드세요.
  • 가져오기는 되지만 시작되지 않음: 코어 로그를 열고 unknown field, invalid config 등의 키워드를 확인하세요.
  • 일부 노드만 사라짐: 사라진 노드의 프로토콜, 전송 방식, 보안 매개변수를 비교하고 클라이언트에서 필터링된 것인지 확인하세요.
  • 업데이트 후에도 이전 목록이 표시됨: 현재 구독 그룹을 업데이트했는지 확인하고, 이름 기준 중복 제거 또는 필터 규칙이 활성화되어 있는지 점검하세요.

업그레이드 전에 현재 버전 번호와 구독 그룹 이름을 기록하세요. 업그레이드 후에는 먼저 테스트 그룹 하나만 업데이트해 노드 수, 이름, 프로토콜 유형이 예상과 일치하는지 확인한 다음 주 그룹을 처리하세요. 이렇게 하면 버전 변경과 구독 소스 변경을 구분할 수 있습니다.

원인 5: 현재 네트워크에서 구독 서버에 직접 연결할 수 없음

구독 서버와 노드 서버는 서로 다른 대상입니다. 기존 노드에 연결할 수 있다고 해서 구독 도메인에도 직접 연결된다는 뜻은 아닙니다. 반대로 구독 업데이트에 성공해도 모든 노드를 사용할 수 있다는 뜻은 아닙니다. DNS 오염, 도메인 확인 실패, 네트워크 출구 제한, 인증서 시간 오류, 연결 시간 초과로 인해 구독 요청이 확인 또는 핸드셰이크 단계에서 멈출 수 있습니다.

로컬에 사용 가능한 노드가 있다면 “직접 연결 업데이트”와 “프록시를 통한 업데이트” 결과를 비교해 보세요. v2rayN의 구독 그룹 메뉴에는 보통 두 가지 업데이트 방식이 있습니다. 프록시를 통한 업데이트만 성공한다면 문제는 구독 형식보다 현재 직접 연결 네트워크 경로에 있을 가능성이 큽니다.

  1. 기존 연결 유지

    서버 목록을 먼저 비우지 마세요. 연결이 확인된 노드를 선택하고 코어가 실행 중인지 확인한 뒤 로컬 포트를 기록하세요.

  2. 직접 연결로 업데이트 테스트

    v2rayN 메인 화면에서 「구독 그룹」→「모든 구독 업데이트(프록시 사용 안 함)」를 열고 10초 안에 처음 기록되는 로그와 HTTP 상태를 확인하세요.

  3. 프록시를 사용해 업데이트

    사용 가능한 노드 연결을 유지한 상태에서 「구독 그룹」→「모든 구독 업데이트(프록시 사용)」를 실행하세요. 이때 성공한다면 로컬 DNS와 직접 연결 경로를 계속 확인하세요.

  4. 프록시 포트 확인

    「설정」→「매개변수 설정」으로 이동해 로컬 수신 포트가 현재 코어와 일치하는지 확인하세요. 일반적인 SOCKS 포트는 10808, HTTP 포트는 10809이지만 실제 값은 화면에 표시된 설정을 기준으로 해야 합니다.

  5. 시스템 시간 확인

    날짜, 시간대, 자동 시간 동기화를 올바르게 설정하세요. 시스템 시간의 오차가 크면 TLS 인증서 검증이 실패할 수 있으며, 로그에 인증서가 아직 유효하지 않거나 이미 만료되었다는 메시지가 표시됩니다.

오류: The operation has timed out

원인 및 해결: 제한 시간 안에 요청이 완료되지 않았습니다. 직접 연결 업데이트와 프록시를 통한 업데이트를 비교하고 DNS, 라우팅, 구독 서버 연결 가능 여부를 확인하세요.

오류: No such host is known

원인 및 해결: 구독 도메인을 확인하지 못했습니다. 시스템 DNS 캐시를 비우고 신뢰할 수 있는 DNS로 변경한 뒤 클라이언트를 다시 시작해 테스트하세요.

오류: The SSL connection could not be established

원인 및 해결: TLS 핸드셰이크가 완료되지 않았습니다. 먼저 시스템 시간을 보정한 뒤 네트워크 중간 장비가 인증서를 교체하거나 연결을 중단하는지 확인하세요.

원인 6: 서버가 빈 본문 또는 빈 노드 목록을 반환함

빈 응답과 형식 오류는 다릅니다. 형식 오류는 클라이언트가 콘텐츠를 받았지만 이해하지 못한 경우이고, 빈 응답은 본문 길이가 0이거나 서버가 생성한 노드 목록 자체에 항목이 없는 경우입니다. 클라이언트에 “업데이트 완료”가 표시되지만 새 노드가 추가되지 않을 수도 있고, “유효한 서버를 찾을 수 없음”이라는 오류가 명확히 표시될 수도 있습니다.

빈 목록이 만들어지는 흔한 원인으로는 구독 생성 작업 미완료, 계정에 사용 가능한 노드가 없음, 서버 필터 조건이 모든 항목을 제외함, 상위 데이터 소스가 일시적으로 비어 있음, 캐시가 이전의 빈 결과를 반환함 등이 있습니다. 이때 로컬 코어를 반복해서 바꿔도 누락된 데이터가 생성되지는 않습니다.

오류: Failed to parse subscription content

원인 및 해결: 본문은 존재하지만 클라이언트가 인식할 수 있는 형식이 아닙니다. 웹 페이지, 안내 문구 또는 일치하지 않는 설정 유형이 반환되었는지 확인하세요.

오류: No valid server was found

원인 및 해결: 파싱이 끝난 뒤 유효한 노드를 얻지 못했습니다. 응답이 비어 있는지, 노드 프로토콜을 지원하는지, 필터 규칙이 모든 항목을 제외했는지 확인하세요.

오류: Subscription content is empty

원인 및 해결: 서버가 빈 본문을 반환했습니다. 서버가 구독을 다시 생성할 때까지 기다리거나 원본에서 계정에 아직 사용 가능한 설정이 있는지 확인하세요.

  • 업데이트 전후의 노드 수를 기록하세요. 계속 0이라면 서버의 생성 결과를 우선 확인하세요.
  • 메모 키워드 필터, 프로토콜 필터, 중복 제거 규칙을 잠시 비활성화한 뒤 테스트 그룹을 업데이트하세요.
  • 안내 문구가 반환되었다면 그 안의 상태 정보에 따라 처리하세요. 안내 페이지를 계속 구독으로 가져오려고 하지 마세요.
  • 같은 주소가 서로 다른 네트워크에서도 계속 빈 콘텐츠를 반환한다면 문제는 로컬 DNS보다 서버 측에 있을 가능성이 큽니다.

결론: 빈 목록이면 먼저 데이터 소스를 확인하고 코어는 나중에 변경

노드 수가 정상 값에서 갑자기 0이 되었고 요청 상태가 여전히 200이라면 먼저 테스트 그룹을 만들고 응답 본문을 확인하세요. 빈 결과가 아직 사용할 수 있는 로컬 목록을 덮어쓰지 않도록 해야 합니다.

전체 점검 순서: 비용이 적은 항목부터 시작

효율적인 점검은 가장 흔하고 확인하기 쉬우며 로컬 상태를 가장 적게 변경하는 항목부터 처리해야 합니다. 구독 주소, 클라이언트 버전, DNS, 코어를 동시에 바꾸지 마세요. 문제가 해결되더라도 실제 원인을 확인할 수 없게 됩니다.

  1. 원본 오류 기록

    업데이트 로그를 열고 첫 번째 실패에 해당하는 오류 원문, 시간, HTTP 상태 코드, 업데이트 방식을 기록하세요. 시간 초과, 접근 거부, 파싱 실패를 구분해야 합니다.

  2. 전체 주소 확인

    「구독 그룹」→「구독 그룹 설정」으로 이동해 주소 앞뒤의 공백, 도메인, 경로, 매개변수를 확인하고 원본과 항목별로 대조하세요.

  3. 테스트 그룹 만들기

    독립된 그룹을 하나 추가해 주소를 붙여넣고 필터 규칙은 일단 활성화하지 마세요. 업데이트 후 전체 노드 수와 VMess, VLESS 등의 프로토콜 분포를 기록하세요.

  4. 네트워크 경로 비교

    직접 연결 업데이트와 프록시를 통한 업데이트를 각각 실행하세요. 후자만 성공한다면 DNS, 시스템 시간, 직접 연결 라우팅을 확인하세요.

  5. 클라이언트 업데이트

    현재 유지 관리 중인 v2rayN, v2rayNG 또는 v2flyNG 버전을 사용하고 있는지 확인한 뒤 해당 코어가 구독에 포함된 프로토콜과 전송 필드를 인식하는지 점검하세요.

  6. 응답 콘텐츠 확인

    서버가 공유 링크 목록이나 클라이언트가 인식할 수 있는 인코딩 콘텐츠를 반환하는지 확인하세요. 로그인 페이지, 오류 페이지, 안내 문구 또는 빈 본문이어서는 안 됩니다.

구독 업데이트 실패가 시간 초과로 표시되면 먼저 클라이언트를 재설치해야 하나요?

그럴 필요는 없습니다. 먼저 로그에서 시간 초과가 도메인 확인, TCP 연결, TLS 핸드셰이크 중 어디에서 발생했는지 확인한 다음 「모든 구독 업데이트(프록시 사용 안 함)」와 「모든 구독 업데이트(프록시 사용)」 결과를 비교하세요.

브라우저에서는 구독 링크가 열리는데 클라이언트는 왜 계속 파싱 실패라고 하나요?

브라우저에서 열린다는 것은 서버가 콘텐츠를 반환했다는 뜻일 뿐입니다. 페이지 본문이 로그인 페이지, 오류 안내 또는 다른 설정 형식인지 확인하세요. HTTP 200만으로는 v2rayN, v2rayNG 또는 v2flyNG가 해당 콘텐츠를 인식할 수 있다는 것을 증명할 수 없습니다.

업데이트 후 노드 수가 0이 되었습니다. 기존 노드를 유지할 수 있나요?

기존 그룹을 먼저 덮어쓰지 마세요. 테스트 그룹을 만들어 업데이트하고 필터 규칙을 끄세요. 테스트 그룹도 0개라면 응답 본문과 서버의 노드 목록을 확인한 뒤 기존 설정을 교체할지 결정하세요.

같은 구독이 v2rayNG에서는 가져와지는데 v2flyNG에서는 일부 노드가 사라집니다. 왜 그런가요?

사라진 노드가 사용하는 프로토콜 필드, 전송 방식, 보안 매개변수를 비교하세요. 두 클라이언트는 서로 다른 코어를 사용하므로 지원 범위와 기본 처리 방식이 다를 수 있습니다. 해당 코어의 로그를 기준으로 판단해야 합니다.

프록시를 사용하면 업데이트되지만 프록시를 끄면 실패합니다. 구독을 변경해야 하나요?

대개 구독을 먼저 변경할 필요는 없습니다. 이 결과는 주소와 형식이 대체로 유효하다는 뜻이므로 직접 연결 DNS, 시스템 시간, 네트워크 라우팅, 현재 네트워크에서 구독 도메인에 연결 가능한지를 확인하세요.

마지막으로 최소 검증을 한 번 더 진행하세요. 기존 그룹은 유지하고 테스트 그룹을 새로 만드세요. 전체 주소를 사용하고 필터를 끈 뒤 직접 연결로 업데이트하고, 이어서 프록시를 통해 업데이트하세요. 첫 로그와 노드 수를 기록하면 문제를 링크, 네트워크, 형식, 버전, 서버 데이터 중 하나로 좁힐 수 있습니다.

구독이 복구되면 만료된 그룹을 삭제하고 현재 활성 노드를 다시 선택하세요. 점검 중 라우팅 모드, 시스템 프록시 또는 TUN 설정을 변경했다면 원래 설정으로 되돌리고 다시 연결해 현재 코어 프로세스가 최종 규칙을 불러오도록 하세요.