이 체크리스트는 v2rayN에서 구독 업데이트를 눌렀을 때 시간 초과나 HTTP 오류가 발생하거나, 업데이트가 끝나도 노드가 보이지 않는 경우에 유용합니다. 먼저 요청 실패인지 파싱 실패인지 구분하고, 응답 본문과 업데이트 경로, 클라이언트 식별 정보, 그룹 필터를 확인하세요. 한 번에 한 항목만 변경하고 기존 설정과 민감 정보를 가린 로그를 보관해, 사용 가능한 노드까지 삭제하지 않도록 주의하세요.
먼저 어느 단계에서 실패했는지 확인
구독 링크는 노드 설정 모음에 접근하는 주소이지, 바로 연결할 수 있는 노드가 아닙니다. v2rayN은 먼저 링크에 요청을 보내고, 응답 형식을 판별한 뒤 노드 설정을 해당 그룹에 추가합니다. 노드 연결 여부는 그다음 문제입니다. 구독을 정상적으로 가져왔더라도 원격 서버에 접속할 수 있다는 뜻은 아니며, 기존 노드로 인터넷에 접속할 수 있어도 구독 주소가 여전히 유효하다는 보장은 없습니다.
메인 화면에서 「구독 그룹」 메뉴를 열고, 우선 확인이 필요한 그룹만 업데이트하세요. WPF와 Desktop 인터페이스, 버전에 따라 메뉴 이름은 조금 다를 수 있습니다. 아래에서는 업데이트 경로가 명확히 구분되는 「현재 구독 업데이트(프록시 사용 안 함)」과 「현재 구독 업데이트(프록시 사용)」를 기준으로 안내합니다. 시스템 프록시 설정은 구독 업데이트 경로를 대신하지 않습니다.
| 화면에 나타나는 증상 | 우선 확인할 항목 | 다음 단계 |
|---|---|---|
| 오래 기다린 뒤 시간 초과 | DNS, 네트워크 경로, 프록시 출구 | 직접 연결과 프록시 업데이트 비교 |
| HTTP 401 또는 403 | 토큰, 접근 제한, 요청 헤더 | 계정과 구독 전용 링크 확인 |
| HTTP 200이지만 파싱 결과가 없음 | 응답 본문과 형식 호환성 | 웹페이지나 빈 내용이 반환되는지 확인 |
| 가져오기는 성공했지만 목록이 비어 있음 | 그룹 선택, 검색, 필터 | 대상 그룹으로 전환하고 검색어 지우기 |
| 노드는 있지만 모두 연결 실패 | 노드 설정 또는 실행 중인 코어 | 연결 및 코어 로그 점검으로 전환 |
링크 유효성: 로그인 페이지와 만료된 토큰부터 확인
구독 제공업체 계정 페이지에서 ‘구독 주소’를 다시 복사하세요. 계정 관리 페이지나 요금제 안내 페이지, 브라우저 로그인 후의 주소를 복사하면 안 됩니다. 링크의 쿼리 매개변수에는 접근 토큰이 포함되는 경우가 많으므로 문자 하나만 빠져도 다른 요청이 될 수 있습니다. 「구독 그룹 설정」에 붙여 넣은 뒤 앞뒤에 공백이나 줄바꿈, 한글 따옴표가 섞이지 않았는지 확인하세요. 특히 물음표 뒤의 내용을 직접 지우지 마세요.
-
현재 설정 백업하기
클라이언트에 백업 기능이 있으면 이를 사용하세요. 설정 폴더를 백업하려면 v2rayN을 종료한 뒤 실제 데이터 폴더를 복사하세요. 사용할 수 있는 노드가 남아 있다면 모든 그룹을 먼저 삭제하지 마세요.
-
구독 주소 확인
「구독 그룹」→「구독 그룹 설정」으로 이동해 대상 그룹을 편집하세요. 제공업체 페이지에서 전체 주소를 다시 복사해 붙여 넣고, 오류가 발생한 그룹을 수정하고 있는지도 확인하세요.
-
계정 상태 확인
구독이 만료됐는지, 토큰이 재설정됐는지, 제공업체에서 주소를 갱신하라고 안내했는지 확인하세요. 토큰 재설정 후 기존 링크가 무효가 되는 것은 정상입니다. 계속해서 같은 링크를 재시도하지 마세요.
-
응답 내용 확인
신뢰할 수 있는 로컬 환경에서 응답 상태와 본문 형식을 확인하세요. 로그인 양식이나 인증 문자, 요금제 페이지가 보인다면 웹페이지를 저장해 가져오지 말고, 제공업체에 클라이언트용 구독 API 주소를 문의하세요.
브라우저에서 링크가 열린다는 사실은 참고만 하세요. 브라우저에는 로그인 쿠키가 포함되어 있거나 다른 프록시를 사용하고, 웹페이지 인증을 자동으로 통과했을 수 있습니다. v2rayN의 구독 요청에는 이런 조건이 없을 수 있습니다. HTTP 200은 요청이 성공 응답을 받았다는 뜻일 뿐, 본문에 노드가 포함되어 있다는 보장은 아닙니다.
Base64와 노드 형식: 내용이 있어도 파싱된다는 뜻은 아닙니다
일반적인 구독 본문은 여러 공유 링크를 줄 단위로 나열한 텍스트이며, 전체가 Base64로 인코딩되기도 합니다. 인터페이스에 따라 링크가 평문으로 바로 반환될 수도 있습니다. Base64는 암호화가 아닌 인코딩 방식입니다. 디코딩에 성공하더라도 만료 알림이나 오류 안내, 클라이언트에서 인식하지 못하는 형식일 수 있으므로 디코딩한 내용도 확인해야 합니다.
- 구독 본문 인코딩: 디코딩하면 일반적으로 줄마다 공유 링크가 표시됩니다. 확인 작업은 로컬에서만 하고 전체 결과를 다른 사람에게 보내지 마세요.
- VMess 공유 내용:
vmess://뒤에 오는 기존 형식의 공유 데이터에는 별도의 Base64 인코딩이 적용될 수 있습니다. 이는 구독 본문 전체에 적용된 인코딩과 다른 단계입니다. - VLESS 공유 내용:
vless://는 보통 URI 형식으로 주소와 매개변수를 나타냅니다. 링크 전체를 무조건 Base64로 디코딩하면 안 됩니다. - 형식 불일치: 다른 설정 시스템용 YAML, 웹페이지 HTML, 오류 JSON은 확장자를
.txt로 바꿔도 v2rayN에서 가져올 수 있는 구독이 되지 않습니다.
같은 응답에서 일부 노드만 가져오지 못했다면 실패한 항목의 프로토콜과 전송 매개변수, 클라이언트의 파싱 지원 여부부터 확인하세요. 하나도 가져오지 못했다면 먼저 인터페이스에서 올바른 응답 형식을 선택했는지 확인한 뒤 인코딩 문제를 살펴보세요. 처음부터 코어 설정을 바꾸지 마세요. 클라이언트가 구독 텍스트를 파싱하기도 전에 Xray나 V2Ray 코어를 바꾸는 것으로 웹페이지가 다운로드되는 문제를 해결할 수는 없습니다.
| 본문에서 보이는 특징 | 의미 | 대처 방법 |
|---|---|---|
<!DOCTYPE html> 또는 <html | 웹페이지가 반환됨 | 구독 API 주소와 로그인 요구 사항, 웹 보호 설정 확인 |
| JSON 오류 객체 | API에서 처리 오류를 반환함 | 오류 내용을 확인하고 계정 또는 토큰 점검 |
| 본문이 비어 있거나 공백뿐임 | 파싱할 데이터가 없음 | 제공업체에 구독에 노드가 실제로 할당됐는지 문의 |
| 여러 줄의 프로토콜 공유 링크 | 인식 가능한 평문 구독일 수 있음 | 프로토콜 지원 여부와 항목이 온전한지 확인 |
| 긴 인코딩 문자열 | 구독 본문 전체가 Base64로 인코딩됐을 수 있음 | 로컬에서 디코딩해 확인하고 겉모양만으로 판단하지 않기 |
업데이트 경로: 직접 연결과 프록시 사용을 각각 테스트
‘프록시 없이 업데이트’와 ‘프록시를 사용해 업데이트’는 구독 서버에 연결하는 네트워크 경로를 바꿀 뿐, 서버의 구독 내용을 수정하지 않습니다. 직접 연결로 API에 접속할 수 없다면 프록시 출구를 이용해 요청에 성공할 수 있습니다. 반대로 구독 API가 프록시 출구를 제한하거나 특정 네트워크에서만 접근을 허용한다면 직접 연결이 더 잘될 수 있습니다.
-
먼저 직접 연결로 시도
대상 그룹을 선택한 뒤 「구독 그룹」 메뉴에서 프록시 없이 업데이트하세요. 오류 발생 시간과 상태 코드를 기록하고 버튼을 연속해서 누르지 마세요.
-
기존 노드가 작동하는지 확인
사용 가능한 노드가 남아 있다면 먼저 선택하고 코어가 실행 중인지 확인한 뒤, 실제로 접속할 수 있는 웹페이지를 열어 보세요. 노드가 선택되어 있다는 사실만으로 로컬 프록시가 작동한다고 볼 수는 없습니다.
-
프록시를 사용해 업데이트
프록시를 사용해 업데이트하고 결과를 비교하세요. 이 방법으로만 성공했다면 구독 형식보다 직접 연결 경로에 문제가 있을 가능성이 큽니다.
-
한 번에 한 항목만 변경
두 방법 모두 실패하면 기존 주소를 유지하고 오류가 같은지 비교하세요. DNS와 User-Agent, 노드 매개변수를 동시에 변경하면 어떤 변경이 효과가 있었는지 확인하기 어렵습니다.
프록시를 통한 업데이트에도 로컬 리스닝 포트가 필요합니다. 「설정」→「매개변수 설정」에서 현재 로컬 인바운드 리스닝 설정을 확인하세요. 실제 리스닝 주소가 127.0.0.1:10808이라면 테스트 도구에서도 해당 포트와 지원되는 프록시 프로토콜을 사용해야 합니다. 여기서 10808은 확인을 위한 예시일 뿐, 모든 버전과 설정에 적용되는 고정값이 아닙니다. 원격 노드의 포트로 대체해서도 안 됩니다.
오류: Connection refused
원인 및 해결: 연결 대상이 요청을 거부했습니다. 로그에 127.0.0.1의 로컬 프록시 포트가 표시된다면 코어가 실행 중인지, 포트가 현재 설정과 일치하는지 확인한 뒤 프록시 업데이트를 다시 시도하세요. 원격 주소가 표시된다면 해당 원격 서비스 상태를 확인하세요.
오류: No such host is known.
원인 및 해결: 호스트 이름을 확인하지 못했습니다. 구독 도메인이 빠짐없이 복사됐는지, 현재 요청 경로에서 어떤 DNS를 사용하는지 확인하세요. 노드의 SNI를 바꿔도 구독 도메인 DNS 오류는 해결되지 않습니다.
오류: A task was canceled.
원인 및 해결: 시간 초과 또는 취소로 요청이 종료됐을 수 있습니다. 이 문구만으로 API가 중단됐다고 단정할 수는 없습니다. 앞뒤 로그에서 시간 초과 여부를 확인하고 직접 연결과 프록시 경로를 각각 테스트하세요.
User-Agent와 HTTP 상태 코드: API 요구 사항에 맞게 확인
User-Agent는 요청 헤더에서 클라이언트를 식별하는 값입니다. 일부 구독 API는 이를 기준으로 응답 형식을 선택하거나 접근을 제한합니다. 「구독 그룹」→「구독 그룹 설정」에서 대상 그룹을 편집하고, 현재 버전에 「User-Agent」 항목이 있다면 기본값을 유지하거나 제공업체가 지정한 값을 입력하세요. 해당 항목이 없다면 식별 문자열을 구독 URL 뒤에 덧붙이지 마세요.
User-Agent 변경은 모든 문제에 통하는 해결책이 아닙니다. 브라우저 식별 정보를 사용하면 API가 웹페이지를 반환할 수 있으며, 잘못된 클라이언트 식별 정보로 호환되지 않는 내용이 반환될 수도 있습니다. 한 번에 한 그룹만 수정하고 업데이트 후 상태 코드와 본문 형식을 비교하세요. 개선되지 않으면 원래 값으로 되돌리세요. 웹 인증 페이지가 표시된다면 인증 우회 방법을 찾기보다 클라이언트용 API를 제공해 달라고 업체에 요청하세요.
오류: Response status code does not indicate success: 403 (Forbidden).
원인 및 해결: 서버가 현재 요청을 거부했습니다. 토큰이나 출구 IP, 요청 헤더 제한이 원인일 수 있습니다. 먼저 구독 권한과 주소를 확인하고 제공업체의 안내에 따라 User-Agent를 점검하세요. 403만으로 특정 원인을 단정할 수는 없습니다.
오류: Response status code does not indicate success: 404 (Not Found).
원인 및 해결: 요청한 리소스를 찾지 못했습니다. 서버가 만료된 리소스를 의도적으로 숨기는 경우도 있습니다. 계정 페이지에서 구독 링크를 다시 받아 사용하고, 경로를 추측하거나 매개변수를 직접 수정하지 마세요.
오류: Response status code does not indicate success: 429 (Too Many Requests).
원인 및 해결: 요청 빈도 제한에 걸렸습니다. 버튼을 연속해서 누르거나 자동 업데이트를 지나치게 자주 실행하지 마세요. 응답의 Retry-After 값이나 제공업체 안내에 따라 기다린 뒤 다시 시도하세요.
위 영어 문구는 HTTP 클라이언트에서 자주 보이는 오류 형식입니다. 실제 대소문자나 추가 문구는 버전에 따라 다를 수 있습니다. ‘업데이트 실패’라는 메시지만 잘라서 기록하기보다 숫자로 표시된 상태 코드가 더 유용합니다. 5xx 응답이라면 일반적으로 API나 상위 서비스 상태를 확인해야 합니다. 로컬 프로토콜을 계속 바꿔도 서버 오류를 바로 해결할 수는 없습니다.
그룹 및 필터: 업데이트에 성공했는데 노드가 보이지 않는 이유
요청과 파싱에 모두 성공했는데 목록이 비어 있다면 표시 범위가 잘못된 것일 수 있습니다. 먼저 방금 업데이트한 구독 그룹으로 전환하고 검색창을 비운 뒤 노드 이름 필터가 적용됐는지 확인하세요. 다음으로 「구독 그룹 설정」에서 현재 버전에 있는 「업데이트 사용」, 필터 키워드, 정규식 필터, 중복 제거 관련 옵션을 살펴보세요. 점검 전 원래 값을 기록한 뒤 필터 조건을 잠시 해제하세요.
- 업데이트 대상 확인: 이름이 같은 그룹은 헷갈리기 쉽습니다. 그룹 메모와 구독 주소를 함께 대조해 한 그룹을 수정한 뒤 다른 그룹을 업데이트하는 일이 없도록 하세요.
- 이름 필터 확인: 정규식이 너무 넓은 범위와 일치하거나 예상하지 못한 공백을 포함하면 모든 노드가 제외될 수 있습니다. 먼저 필터를 비우고 가져온 노드 수를 확인하세요.
- 중복 제거와 실패 구분: 중복 제거가 적용되면 새로 추가된 노드 수가 응답 항목 수보다 적을 수 있습니다. 이것만으로 다운로드 실패라고 볼 수는 없습니다. 업데이트 로그와 그룹의 전체 노드 수를 비교하세요.
- 업데이트 대상 포함 여부 확인: 그룹에서 업데이트를 비활성화했다면 모든 구독을 업데이트할 때 건너뛸 수 있습니다. 해당 그룹이 업데이트 대상에 포함되어 있는지 확인하세요.
자주 묻는 질문과 재확인 기준
브라우저에서는 구독을 다운로드할 수 있는데 v2rayN에서는 왜 실패하나요?
먼저 두 환경이 같은 네트워크 출구를 사용하는지 비교하고, 브라우저에서 받은 내용이 실제 노드 텍스트인지 확인하세요. 브라우저에는 로그인 쿠키가 포함될 수 있습니다. 본문이 로그인 페이지나 인증 페이지라면 클라이언트 전용 구독 주소를 사용하세요. 그런 다음에 제공업체가 지정한 User-Agent를 확인하세요.
노드가 모두 사라졌는데 프록시로 업데이트할 수 있나요?
프록시 업데이트를 하려면 작동하는 프록시 연결 경로가 있어야 합니다. 먼저 로컬 백업에서 정상 작동이 확인된 설정을 복원하거나 제공업체가 안내한 다른 합법적인 연결 방법을 사용하세요. 사용할 수 있는 연결 경로가 없다면 직접 연결을 테스트하거나 접근 가능한 구독 API 주소를 제공업체에 요청하세요. 시스템 프록시만 켠다고 연결이 만들어지는 것은 아닙니다.
v2rayNG에서는 가져올 수 있는데 데스크톱 버전에 문제가 있다는 뜻인가요?
바로 그렇게 단정할 수는 없습니다. 두 클라이언트가 같은 URL을 사용했는지가 아니라 실제로 같은 응답을 받았는지 먼저 확인하세요. 네트워크 출구와 User-Agent, API의 응답 분기가 다를 수 있습니다. 응답이 같다면 각 클라이언트가 해당 프로토콜과 전송 매개변수를 지원하는지 비교하세요. v2rayNG는 Xray 코어를, v2flyNG는 v2fly 코어를 사용하지만 구독 파싱 호환성은 클라이언트 버전도 함께 확인해야 합니다.
업데이트 후 노드는 보이지만 연결 테스트가 모두 실패합니다. 구독을 계속 수정해야 하나요?
먼저 구독 설정 변경을 멈추세요. 코어가 정상적으로 시작되는지 확인하고 시스템 시간과 노드 주소, 포트, TLS 매개변수를 점검한 뒤 연결 단계의 코어 로그를 확인하세요. 구독 업데이트와 노드 연결은 서로 다른 단계입니다. 목록이 생성됐다면 이제 특정 노드와 네트워크 경로를 중점적으로 살펴보세요.
문제를 제대로 재확인하려면 업데이트 작업이 끝났는지만 볼 것이 아니라 ‘요청 성공, 본문 형식 인식, 그룹에 노드 표시’를 모두 확인해야 합니다. 그래도 문제가 계속되면 실제 v2rayN 버전과 사용 중인 인터페이스, 운영체제, 업데이트 방식, HTTP 상태 코드, 민감 정보를 가린 오류 내용을 제공하세요. 노드 계정과 구독 토큰, 전체 응답 본문은 로그와 함께 공개하지 마세요.
- 같은 그룹을 반복해서 확인할 때는 주소와 필터 조건을 그대로 유지하고, 검증할 항목 하나만 바꾸세요.
- 업데이트에 성공하면 대상 그룹에서 노드를 확인한 뒤 선택한 노드의 연결 여부를 별도로 테스트하세요.
- 문제가 해결되면 적절한 자동 업데이트 설정으로 되돌리고, 복원할 수 있는 로컬 백업을 보관하세요.