V2Ray 구독 만료·파싱 실패 자가 점검 체크리스트:링크 형식부터 업데이트 프록시까지 단계별 확인

구독 업데이트는 단순한 한 단계 작업이 아닙니다. 클라이언트는 먼저 링크를 읽고 도메인을 해석한 뒤 HTTPS 연결을 설정합니다. 그런 다음 응답 본문을 가져와 인코딩과 노드 프로토콜을 확인하고, 마지막으로 VMess, VLESS 등의 항목을 현재 구독 그룹에 기록합니다. 어느 한 단계에서든 실패하면 화면에는 “업데이트 실패” 또는 “노드 수 0”으로 표시될 수 있습니다. 따라서 문제 해결의 핵심은 업데이트를 반복해서 누르는 것이 아니라, 먼저 어느 단계에서 실패했는지 확인하는 것입니다.

먼저 문제가 발생한 계층을 확인하세요

작업을 시작하기 전에 업데이트 시각, 클라이언트 버전, 사용한 구독 그룹, 오류 원문을 기록하세요. 기존 그룹을 먼저 삭제하지 마세요. 이전 노드, 그룹 설정, 업데이트 로그가 모두 판단 근거가 됩니다. 클라이언트에서 로그 복사가 가능하다면 업데이트를 누르기 5초 전부터 오류가 나타난 뒤 10초까지의 내용을 보관하세요.

브라우저와 클라이언트 모두 같은 구독 주소를 열 수 없다면 먼저 링크 상태, 도메인 해석, 접근 권한을 확인하세요. 브라우저에서는 텍스트가 표시되지만 클라이언트에서 Base64, JSON 또는 프로토콜 형식 오류가 발생한다면 문제는 콘텐츠 파싱 계층에 더 가깝습니다. 업데이트가 성공하고 노드가 추가되었지만 모든 노드의 지연 시간 테스트가 실패한다면 구독 자체는 읽힌 것입니다. 이후에는 노드 주소, 포트, 전송 계층, 라우팅 설정을 점검해야 합니다.

• 연결 계층: 시간 초과, 연결 거부, TLS 핸드셰이크 실패, 도메인 해석 불가가 흔한 증상입니다.
• 응답 계층: HTTP 401, 403, 404, 429가 표시되거나 구독 본문 대신 로그인 페이지가 반환되는 경우입니다.
• 파싱 계층: Base64 길이 오류, JSON 구조 오류, 인식할 수 없는 프로토콜 접두사가 흔한 증상입니다.
• 기록 계층: 업데이트가 완료되었지만 노드가 0개이거나, 필터 규칙에 의해 모든 노드가 제외되는 경우입니다.
• 연결 테스트 계층: 노드는 표시되지만 TCP 지연 시간이 시간 초과되고 실제 연결도 설정되지 않는 경우입니다.

구독 링크, 응답 상태, 유효 기간 확인

구독 링크에는 접근 토큰, 사용자 식별자, 기기 매개변수 또는 유효 기간 정보가 포함될 수 있습니다. 복사 과정에서 문자 하나가 빠지거나 끝에 공백이 들어가거나, 메신저가 쿼리 매개변수를 잘라 버리면 서버는 오류 페이지를 반환합니다. 원본 관리 페이지에서 완전한 주소를 다시 복사하세요. 직접 조합하거나 여러 주소를 하나의 입력란에 넣지 마세요.

1. 앞뒤 문자 확인

   주소가 https://로 시작하고 첫 문자 앞과 마지막 문자 뒤에 공백, 줄바꿈, 한글 문장 부호가 없는지 확인하세요. 쿼리 매개변수 전체를 복사하고, 특히 물음표 뒤의 토큰 부분을 빠뜨리지 마세요.

2. 브라우저에서 직접 열기

   현재 기기의 브라우저에서 링크를 열고 텍스트가 바로 반환되는지, 파일 다운로드가 시작되는지, 로그인 페이지로 이동하는지, 또는 401, 403, 404, 429 등의 상태가 표시되는지 기록하세요.

3. 유효 기간 확인

   구독 제공처의 관리 페이지에서 계정 상태, 만료 시각, 트래픽 한도, 구독이 새로 생성되었는지를 확인하세요. 주소가 재설정되면 이전 토큰은 대개 더 이상 유효하지 않습니다.

4. 캐시 문제 배제

   60초 간격으로 다시 요청하세요. 첫 요청에서 429가 반환되었다면 계속 클릭할수록 제한 시간이 늘어날 수 있으므로 서버가 다음 요청을 허용할 때까지 기다리세요.

브라우저에서 “열린다”는 사실만으로 응답을 파싱할 수 있다는 뜻은 아닙니다. 정상적인 구독 본문은 긴 인코딩 텍스트, 줄바꿈으로 구분된 프로토콜 링크, 또는 클라이언트가 지원하는 구조화된 콘텐츠인 경우가 많습니다. 페이지에 내비게이션, CAPTCHA, 로그인 양식, 오류 안내가 포함되어 있다면 그것은 웹페이지 응답일 뿐입니다. 이 경우 클라이언트는 HTTP 200을 받더라도 본문 형식이 맞지 않아 파싱 실패를 표시할 수 있습니다.

구독 업데이트에 사용되는 네트워크 경로 확인

“현재 노드로 인터넷에 접속할 수 있다”는 것과 “구독 업데이트 요청이 현재 노드를 거친다”는 것은 별개의 문제입니다. 클라이언트가 브라우저 트래픽은 시스템 프록시로 보내면서 구독 업데이트는 직접 연결로 처리할 수 있습니다. 반대로 코어가 아직 시작되지 않은 상태에서 프록시를 통한 업데이트를 선택하면, 요청이 아무 프로세스도 수신하지 않는 로컬 포트를 가리킬 수도 있습니다.

v2rayN의 이중 경로 테스트

1. 코어 확인

   먼저 아직 사용할 수 있는 이전 노드를 선택하고 코어를 시작한 뒤 메인 화면 하단의 상태를 확인하세요. 일반적인 로컬 SOCKS 포트는 10808, HTTP 포트는 10809이지만 실제 값은 「설정」→「매개변수 설정」의 로컬 수신 설정을 기준으로 해야 합니다.

2. 직접 연결 테스트

   「구독 그룹」을 열고 「모든 구독 업데이트(프록시 사용 안 함)」를 실행한 뒤 소요 시간, HTTP 상태, 노드 수 변화를 기록하세요.

3. 프록시 테스트

   「구독 그룹」을 다시 열고 「모든 구독 업데이트」를 실행하세요. 요청이 현재 프록시 설정에 따라 전송되도록 한 뒤 직접 연결 결과와 비교하세요.

4. 포트 확인

   「설정」→「매개변수 설정」으로 이동해 구독 업데이트에 사용하는 로컬 주소와 실제 수신 포트가 일치하는지 확인하세요. 변경 후 코어를 다시 시작하고 업데이트를 한 번 더 실행하세요.

v2rayNG 및 v2flyNG 네트워크 확인

Android에서는 먼저 메인 화면의 연결 스위치가 켜져 있는지 확인한 뒤 구독을 업데이트하세요. v2rayNG는 Xray 코어를 사용하고 v2flyNG는 v2fly 코어를 사용합니다. 두 앱 모두 구독 요청은 현재 네트워크, 프록시 상태, 시스템의 백그라운드 네트워크 제한에 영향을 받습니다. 일반적인 로컬 SOCKS 수신 포트는 10808이지만 점검할 때는 앱 설정 화면에 표시된 포트를 기준으로 하세요.

• 사이드 메뉴에서 「구독 그룹 설정」으로 들어가 대상 그룹이 활성화되어 있고 주소가 이전 내용으로 덮어쓰이지 않았는지 확인하세요.
• 메인 화면으로 돌아와 오른쪽 상단 메뉴에서 「구독 업데이트」를 실행한 다음 시간 초과, 파싱 실패, 업데이트 완료 중 어떤 안내가 표시되는지 확인하세요.
• 현재 네트워크와 다른 사용 가능한 네트워크에서 각각 한 번씩 테스트하세요. 네트워크 조건만 바꾸고 구독 주소와 코어 설정은 동시에 변경하지 마세요.
• 연결 스위치를 켠 직후 연결이 끊어진다면 먼저 코어 시작 오류를 해결한 뒤 “프록시를 통한 업데이트” 경로를 테스트하세요.

구독 본문의 인코딩 및 프로토콜 형식 점검

연결에 성공하면 클라이언트는 응답 본문이 어떤 형식인지 판단해야 합니다. 흔히 Base64로 인코딩된 여러 줄의 노드 링크이거나 프로토콜 이름으로 시작하는 링크가 직접 포함되어 있을 수 있습니다. 디코딩한 뒤에도 각 레코드는 해당 프로토콜의 필드 요건을 충족해야 합니다. VMess에는 대개 인코딩된 JSON이 포함되며, VLESS는 일반적으로 URI 안에 사용자 식별자, 서버, 포트, 전송 매개변수를 넣습니다.

인식 가능한 항목의 구조 예시:
vmess://인코딩된 노드 설정
vless://사용자 식별자@서버 주소:포트?type=ws&security=tls
trojan://인증 정보@서버 주소:포트?security=tls

확인할 항목:
1. 각 레코드가 한 줄을 온전히 차지하는가
2. 프로토콜 접두사가 반각 문자인가
3. 포트가 1~65535 범위의 정수인가
4. 쿼리 매개변수 사이에 &를 사용하는가
5. 응답에 웹페이지, 오류 안내 또는 빈 내용이 섞여 있지 않은가

표준 Base64는 보통 영문자, 숫자, 더하기 기호, 슬래시, 끝의 등호를 사용합니다. URL 안전 변형에서는 하이픈과 밑줄을 사용할 수도 있습니다. 클라이언트는 대개 일반적인 변형을 지원하지만 복사 중 잘리거나 본문 앞에 안내 문구가 삽입되거나 줄바꿈이 잘못 변환되면 길이가 손상됩니다. “복구”를 위해 임의로 문자를 추가하지 마세요. 디코딩된다고 해서 노드 필드가 완전하다는 뜻은 아닙니다.

노드 이름의 한글, 공백, 특수 기호는 올바르게 인코딩해야 하는 경우가 많습니다. 특정 한 항목만 실패한다면 구독 본문을 줄 단위로 확인하고 항상 같은 항목 주변에서 실패하는지 살펴보세요. 비정상 항목 하나를 삭제한 뒤 나머지를 가져올 수 있다면 네트워크와 전체 인코딩은 대체로 정상이며, 해당 노드의 필드나 이스케이프 방식에 문제가 집중된 것입니다.

• VMess: 디코딩된 JSON이 정상적으로 닫혔는지, 주소·포트·사용자 식별자·전송 유형이 존재하는지 확인하세요.
• VLESS: 사용자 식별자와 서버 사이에 @가 있는지, 포트 뒤 매개변수에 반각 물음표와 연결 기호를 사용하는지 확인하세요.
• TLS 매개변수: 서버 이름, 지문, 보안 유형이 서버 설정과 일치해야 합니다. 필드를 파싱할 수 있다고 해서 핸드셰이크까지 성공하는 것은 아닙니다.
• WebSocket 매개변수: 경로의 슬래시와 특수 문자는 인코딩된 상태를 유지해야 하며 구독 생성 과정에서 다시 변환되어서는 안 됩니다.
• 빈 응답: HTTP 상태는 정상이지만 본문 길이가 0이면 클라이언트에 기록할 항목이 없습니다. 구독 생성 측을 확인하세요.

클라이언트 버전, 코어, 그룹 설정

같은 구독이 이전 버전에서는 실패하고 최신 버전에서는 성공한다면 프로토콜 필드, 공유 링크 형식, 코어 기능 변경과 관련 있을 가능성이 큽니다. v2rayN 7.x와 초기 6.x는 화면과 일부 설정 메뉴가 다릅니다. v2rayNG 1.10.x에는 일부 1.8.x 버전보다 최신 Xray 코어와 가져오기 처리가 포함되어 있습니다. 점검 기록에는 “최신 버전”이라고만 쓰지 말고 전체 버전 번호를 적어야 합니다.

1. 버전 기록

   클라이언트 전체 버전과 코어 버전을 기록하세요. 예를 들어 “7.x”만 적으면 파싱 동작을 비교하기에 부족하므로 정보 화면에 표시된 모든 버전 정보를 남겨야 합니다.

2. 클라이언트 업데이트

   이 사이트의 다운로드 페이지에서 현재 안정 버전을 받고, 기존 프로세스를 종료한 뒤 해당 플랫폼에 맞게 업데이트하세요. 장애 샘플을 잃지 않도록 기존 설정 사본을 보관하세요.

3. 새 그룹 만들기

   기존 그룹을 바로 수정하지 마세요. 「구독 그룹」→「구독 그룹 설정」에서 테스트 그룹을 새로 만들고 같은 주소를 붙여 넣은 뒤 한 번 업데이트하세요.

4. 필터 해제

   포함, 제외, 정규식 필터, 중복 제거 조건을 잠시 모두 비우세요. 노드 수가 0에서 특정 숫자로 회복된다면 문제는 구독 파싱이 아니라 그룹 필터에 있습니다.

5. 개수 비교

   서버에 표시된 노드 수, 클라이언트 가져오기 수, 필터링된 수를 기록하세요. 예를 들어 원본에 24개가 표시되는데 클라이언트 기록이 0개라면 형식 또는 필터를 먼저 확인하고, 23개가 기록되었다면 특정 항목의 오류를 점검하세요.

그룹 필터는 “업데이트 성공인데 목록이 비어 있음”을 일으키는 흔한 원인입니다. 포함 규칙은 이름이 일치하는 노드만 남기고, 제외 규칙은 일치하는 노드를 제거합니다. 정규식에서 너무 넓은 마침표나 와일드카드 범위를 사용하면 모든 항목이 필터링될 수 있습니다. 테스트할 때는 먼저 필터를 모두 비운 다음 규칙을 하나씩 복원하고 매번 노드 수 변화를 기록하세요.

업데이트는 성공했지만 노드를 계속 사용할 수 없음

구독 업데이트가 된다는 것은 클라이언트가 설정을 가져와 파싱했다는 뜻일 뿐, 모든 노드가 온라인이라는 뜻은 아닙니다. 다음 단계에서는 서버 주소 해석, 대상 포트, 전송 방식, TLS 매개변수, 시스템 시간, 라우팅 분기를 확인해야 합니다. 이 단계에서는 이미 링크가 역할을 다했으므로 구독 링크를 계속 수정하지 마세요.

• 먼저 TCP 지연 시간 테스트를 실행하세요. 20개 노드가 모두 비슷한 시점에 시간 초과된다면 로컬 네트워크, DNS 또는 공통 서버 도메인을 우선 확인하세요.
• 특정 노드 하나만 실패한다면 사용 가능한 노드와 주소, 포트, 전송 유형, 보안 매개변수를 비교하세요.
• 시스템 시간의 오차는 TLS 인증서 유효 기간 확인에 영향을 줄 수 있으므로 날짜, 시간, 시간대 자동 동기화를 켜세요.
• 라우팅 모드가 노드 서버 주소를 잘못 프록시 아웃바운드로 다시 보내 순환 연결을 만드는지 확인하세요.
• 시스템 프록시 포트와 클라이언트 수신 포트가 일치하는지 확인하세요. v2rayN의 일반적인 HTTP 포트는 10809이지만 실제 설정이 우선합니다.

지연 시간 테스트 결과도 유형을 나누어 해석해야 합니다. TCP 지연 시간은 대상 포트에 연결을 설정할 수 있는지만 확인하며 VMess, VLESS, TLS, WebSocket 세션 전체를 검증하지는 않습니다. 실제 연결 테스트에는 인증, 전송 계층 캡슐화, 라우팅이 포함됩니다. 따라서 “TCP는 80ms인데 접속할 수 없음”은 대개 포트 이후의 프로토콜 매개변수에 문제가 있다는 뜻입니다.

연결 최소 검증

1. 필드가 완전하고 이름이 명확한 노드 하나를 선택한 뒤 복잡한 라우팅 규칙을 잠시 끄세요.
2. 코어를 시작하고 로컬 SOCKS 또는 HTTP 포트가 수신 중인지 확인하세요.
3. 테스트 앱 하나만 프록시를 통과하도록 하여 다른 트래픽이 로그에 영향을 주지 않게 하세요.
4. 로그에서 이후 반복되는 재시도보다 가장 먼저 나타난 오류를 확인하세요.
5. 라우팅 규칙을 복원한 뒤 다시 테스트하세요. 이때 실패한다면 문제는 분기 조건 또는 아웃바운드 태그에 집중됩니다.

재사용 가능한 10분 자가 점검 순서

복잡한 문제는 계층별로 접근해야 하지만 일상적인 오류 해결에는 고정된 순서가 필요합니다. 다음 절차는 가능성이 높고 비용이 낮은 확인부터 배치하여 처음부터 클라이언트를 재설치하거나 전체 설정을 다시 만들지 않도록 합니다. 각 단계를 마칠 때마다 응답 상태, 소요 시간, 노드 수, 오류 원문을 기록하세요.

1. 현재 상태 저장

   클라이언트와 코어 버전을 기록하고 기존 그룹, 업데이트 시각, 노드 수, 첫 번째 오류 로그를 보관하세요.

2. 링크 다시 복사

   원본 관리 페이지에서 전체 구독 주소를 복사하고 앞뒤 공백, 줄바꿈, 토큰, 유효 기간을 확인하세요.

3. 응답 확인

   로그인 페이지, CAPTCHA, 빈 페이지가 아니라 구독 본문이 반환되는지, 상태가 401, 403, 404, 429가 아닌지 확인하세요.

4. 경로 전환

   직접 연결 업데이트와 프록시를 통한 업데이트를 각각 테스트하고 10808, 10809 등의 로컬 포트가 실제 설정과 일치하는지 확인하세요.

5. 새 그룹 만들기

   빈 테스트 그룹에 같은 주소를 가져오고 포함, 제외, 정규식 필터, 중복 제거 조건을 끄세요.

6. 노드 검증

   업데이트가 성공한 뒤 TCP와 실제 연결을 테스트하고 DNS, 포트, TLS, 전송 계층, 라우팅 순서로 계속 원인을 좁혀 가세요.

절차가 두 번째 단계에서 멈추면 대개 링크 또는 계정 상태 문제입니다. 세 번째 단계에서 멈추면 서버 응답 또는 접근 제한 문제인 경우가 많습니다. 네 번째 단계에서 멈추면 네트워크 경로와 로컬 포트 문제일 가능성이 큽니다. 다섯 번째 단계에서 멈추면 형식, 버전, 필터 문제일 수 있습니다. 앞의 다섯 단계를 모두 통과한 경우에만 노드 프로토콜과 서버 설정을 깊이 확인하세요.

자주 묻는 질문