이미 이용 중인 서비스 제공업체와 구독이 있지만 Shadowrocket에서 업데이트되지 않거나 노드가 보이지 않는 경우를 위한 안내입니다. 기존 설정은 유지한 채 요청 실패, 응답 파싱 실패, 빈 목록을 구분한 다음 URL, 계정 상태, 업데이트에 사용하는 네트워크를 확인하세요. 한 번에 한 가지 조건만 바꾸면 구독을 반복해서 삭제하거나 새로 고쳐 원인을 놓치는 일을 줄일 수 있습니다.
구독 업데이트 오류와 노드 연결 오류 구분하기
구독 업데이트는 특정 주소에서 서버 설정을 가져오는 작업이고, 연결 테스트는 이미 가져온 서버를 사용해 네트워크에 접속하는 작업입니다. 두 작업은 서로 다른 경로를 이용합니다. 기존 노드에 연결할 수 있어도 구독 URL이 유효하다는 뜻은 아니며, 구독 업데이트에 성공해도 모든 서버에 연결할 수 있다는 뜻은 아닙니다. 먼저 Home에서 문제가 발생한 구독 그룹을 확인하고 현재 시각, 노드 수, 표시된 안내 문구를 기록하세요.
‘목록이 비어 있음’은 기존 항목이 실제로 사라진 경우와 현재 화면에 표시되지 않는 경우로 나눠 확인해야 합니다. 먼저 Home의 검색 조건을 지우고 구독 그룹을 펼친 뒤, 다른 그룹을 보고 있지는 않은지 확인하세요. 노드 존재 여부를 Config의 규칙 파일 목록으로 판단하지 마세요. 규칙 설정과 서버 구독은 서로 다른 역할을 합니다.
- 업데이트 전 노드 수를 기록하세요. 사용할 수 있는 노드가 있다면 구독 그룹을 삭제하지 말고 유지하세요.
- Home에서 대상 구독을 한 번 업데이트하세요. 아래로 당겨 업데이트하는 인터페이스라면 새로 고침한 뒤 대상 그룹의 결과를 확인하세요.
- 결과를 요청 실패, 파싱 실패, 업데이트 성공 후 빈 목록, 노드 표시 후 연결 실패로 구분한 다음 해당 문제 해결 절차를 진행하세요.
구독 URL 확인: 전체 URL인지 웹페이지 주소인지 구분하기
이용 중인 서비스 제공업체의 계정 페이지로 돌아가 Shadowrocket에서 사용할 수 있다고 명시된 구독 URL을 다시 복사하세요. 채팅 미리보기, 잘린 알림, 스크린샷 인식 결과에서 URL을 복원하지 마세요. 웹페이지에 표시된 생략 부호는 URL의 일부가 아닙니다. 계정 로그인 페이지나 요금제 안내 페이지도 구독 API가 아닙니다.
구독 URL에는 쿼리 매개변수가 포함되는 경우가 많으며, 대개 사용자 식별이나 형식 선택에 사용됩니다. 붙여 넣은 뒤 따옴표, 공백, 줄바꿈, 한글 문장부호가 추가되지 않았는지 확인하세요. 특히 ?, &, = 뒤의 내용이 모두 복사되었는지 살펴보세요. 매개변수 값은 대소문자를 구분할 수 있으므로 임의로 수정하거나 ‘간단하게’ 만들겠다고 끝부분의 매개변수를 삭제하지 마세요.
https://example.com/sub?token=xxxx위 주소는 실제 구독에 사용할 수 없는 예시이며 URL 구조만 설명합니다. 실제 token은 계정 접근 정보로 취급해야 하므로 공개 댓글, 스크린샷, 온라인 변환 사이트에 올리지 마세요. 일부 구독은 token 매개변수 대신 경로에 인증 정보를 포함합니다. 따라서 해당 매개변수가 없다고 URL이 잘못된 것은 아니며, 서비스 제공업체가 발급한 원본 주소를 기준으로 확인해야 합니다.
https://주소는 구독 URL일 수도 있고 일반 웹페이지 주소일 수도 있으므로, 응답 내용을 확인해야 합니다.ss://,vmess://,vless://,trojan://은 일반적으로 개별 서버 설정을 나타내므로 주기적으로 새로 고칠 HTTP 구독 URL로 사용하면 안 됩니다.- QR 코드를 복사한 경우 먼저 내용이 구독인지 개별 설정인지 확인하세요. ‘스캔 성공’만으로 전체 목록을 업데이트할 수 있다고 판단할 수는 없습니다.
- 서비스 제공업체에서 구독 인증 정보를 재설정했다면 기존 구독에 새 URL을 입력한 뒤 한 번 업데이트하세요. 클라이언트를 다시 설치해도 이전 URL이 다시 유효해지지는 않습니다.
오류 유형별로 링크 만료, 요청 제한, 응답 내용 확인
아래는 네트워크 또는 HTTP 계층에서 흔히 볼 수 있는 오류 식별자입니다. 모든 플랫폼에 같은 문구가 표시되는 것은 아닙니다. 기록할 때는 실제 안내 문구를 그대로 남기고, ‘실패’라는 메시지만으로 계정이 만료됐다고 판단하지 마세요. 일반적인 실패 메시지만 보인다면 업데이트 시각과 서비스 제공업체의 접속 기록을 함께 확인하세요.
HTTP 401 Unauthorized
원인 및 해결: 인증에 실패한 요청입니다. 인증 정보가 누락되었거나 재설정 또는 만료되었을 수 있습니다. 계정에서 현재 유효한 구독 URL을 다시 복사하고 서비스 제공업체에 인증 정보 상태를 문의하세요.
HTTP 403 Forbidden
원인 및 해결: 서버가 이번 요청을 거부했습니다. 계정 권한, 접속 출처 또는 접근 정책이 원인일 수 있습니다. 사용할 수 있는 구독이 계정에 있는지 확인하고, 현재 네트워크나 요청 방식이 제한되는지 서비스 제공업체에 문의하세요.
HTTP 429 Too Many Requests
원인 및 해결: 요청 빈도가 서버 제한을 초과했습니다. 연속으로 새로 고치지 마세요. 응답에 Retry-After가 있다면 안내된 시간만큼 기다리고, 없다면 서비스 제공업체가 안내한 간격에 따라 다시 시도하세요.
HTTP 200 OK인데 파싱에 실패하거나 항목이 없는 경우
원인 및 해결: HTTP 요청이 성공해도 응답 내용이 유효한 구독이라는 뜻은 아닙니다. 로그인 페이지, 인증 페이지 또는 빈 내용이 반환될 수 있습니다. 해당 URL의 실제 응답 데이터와 Shadowrocket 호환성을 서비스 제공업체에 확인하세요.
구독은 인코딩된 텍스트나 지원되는 다른 구조로 반환될 수 있으므로, 브라우저에서 ‘깨진 글자처럼 보인다’는 이유만으로 손상됐다고 판단하지 마세요. 반대로 제대로 구성된 웹페이지가 열린다고 구독이 유효한 것도 아닙니다. 확인해야 할 것은 웹페이지가 정상적으로 표시되는지가 아니라 응답에 클라이언트가 인식할 수 있는 서버 설정이 포함되어 있는지입니다.
요약: 상태 코드가 표시되면 먼저 서버가 거부한 이유를 확인하세요
기록에 401, 403 또는 429가 명시되어 있다면 먼저 인증 정보, 권한 또는 새로 고침 간격을 확인하세요. Global Routing을 반복해서 바꿔도 만료된 token이 복구되거나 서버 접근 제한이 해제되지는 않습니다.
업데이트에 사용하는 네트워크와 Update via Proxy 확인
HTTP 응답이 오지 않고 시간 초과나 도메인 이름 확인 오류만 발생한다면 네트워크 경로를 확인하세요. 먼저 시스템 네트워크가 연결되어 있는지 확인하고, 웹 인증이 필요한 Wi-Fi라면 인증을 완료하세요. 그런 다음 같은 구독 URL로 한 번만 조건을 통제해 테스트하세요. DNS, 라우팅 방식, 구독 매개변수를 동시에 바꾸지 마세요.
해당 옵션이 있는 인터페이스에서는 Settings → Subscribe → Update via Proxy로 이동해 구독을 프록시를 통해 업데이트하는지 확인할 수 있습니다. 이 옵션을 켜기 전에 Home에서 선택한 기존 서버에 연결할 수 있는지 확인한 다음 대상 구독을 업데이트하세요. 메뉴 위치와 문구는 현재 플랫폼의 실제 인터페이스를 기준으로 확인하고, 모든 플랫폼의 화면 구성이 같다고 가정하지 마세요.
| 확인 결과 | 다음 단계 | 판단 기준 |
|---|---|---|
| 일반 웹페이지도 열리지 않음 | 먼저 Wi-Fi 또는 모바일 네트워크를 복구하고 네트워크 인증을 완료하세요 | 구독 URL이나 규칙은 아직 변경하지 마세요 |
| 직접 업데이트는 시간 초과지만 기존 서버에는 연결 가능 | Update via Proxy를 켜고 한 번만 다시 시도하세요 | 성공하더라도 두 네트워크 경로의 연결 가능성이 서로 다르다는 점만 확인된 것입니다 |
| 옵션을 켜면 실패하지만 직접 업데이트는 성공 | 성공하는 업데이트 방식을 사용하고 프록시 경로를 확인하세요 | 업데이트 방식과 일상적인 트래픽 분할 설정을 혼동하지 마세요 |
| 두 방식 모두 403 응답 | 발생 시각과 상태 코드를 기록한 뒤 이용 중인 서비스 제공업체에 문의하세요 | 서버의 접근 제한을 우선 확인하세요 |
Home → Global Routing의 Proxy, Direct, Config, Scene은 라우팅 방식을 선택하는 기능이며 구독 API가 유효한지 확인하는 기능은 아닙니다. Config의 DOMAIN-SUFFIX, IP-CIDR, GEOIP, FINAL은 해당 트래픽에 규칙을 적용하지만, 규칙에 FINAL,PROXY를 추가해도 비어 있는 구독 응답을 복구할 수는 없습니다.
- 연결 가능한 기존 서버가 하나도 없다면 ‘프록시를 통한 업데이트’가 반드시 문제를 해결한다고 생각하지 마세요.
- 연결 상태가 저절로 바뀐다면 Settings → On Demand에서 필요 시 연결 조건을 확인하고 테스트 당시 실제로 연결되어 있었는지 기록하세요.
- Wi-Fi와 모바일 네트워크를 전환했다면 네트워크가 안정될 때까지 기다린 뒤 업데이트하세요. 전환하는 순간 요청을 연속으로 보내지 마세요.
업데이트는 성공했지만 노드가 비어 있음: 계정, 형식, 그룹 확인
클라이언트에서 업데이트 완료로 표시되는데 목록이 비어 있다면 먼저 화면 표시를 확인한 다음 서버에서 실제로 서버를 할당했는지 확인하세요. 계정에 로그인할 수 있고 과거 주문 내역이 있다는 사실은 현재 사용 가능한 구독이 있다는 뜻과 다릅니다. 이용 중인 서비스 제공업체 계정에서 유효 기간, 트래픽 상태, 구독 권한을 확인하세요. 구체적인 비활성화 기준은 해당 서비스 제공업체의 안내를 따르세요.
- 화면 표시 확인: 검색어를 지우고 대상 그룹을 펼친 다음 다른 구독이나 페이지를 보고 있지는 않은지 확인하세요.
- 출력 형식 확인: 계정 페이지에서 형식을 선택할 수 있다면 Shadowrocket을 지원한다고 명시된 형식을 선택하세요. 규칙 파일 URL을 서버 구독에 입력하지 마세요.
- 응답 목록 확인: 상태 코드가 200인지에 그치지 말고, 해당 URL이 이번 요청에서 비어 있지 않은 서버 목록을 반환했는지 서비스 제공업체에 문의하세요.
- 파싱 가능한 내용 확인: 응답에 내용이 있는데도 항목이 0개라면 민감 정보를 가린 오류 메시지를 제공하고 필드와 형식의 호환성을 서비스 제공업체에 확인하세요. 공개 채널에 전체 설정을 보내지 마세요.
모든 프로토콜을 같은 유형으로 수동 변경하지 마세요. Shadowsocks, VMess, VLESS, Trojan, Hysteria2, WireGuard는 필드와 연결 방식이 서로 다릅니다. 프로토콜 이름만 바꿔서는 형식이 변환되지 않습니다. 일부 항목만 누락됐다면 전체 설정을 삭제하기 전에 누락된 항목 유형과 서비스 제공업체의 출력 내용을 비교하세요.
요약: 빈 목록과 파싱 실패는 각각 따로 확인해야 합니다
‘응답이 비어 있지 않은지, 유효한 서버 설정이 포함되어 있는지’를 서비스 제공업체에 확인하는 편이 ‘링크가 열리는지’를 반복해서 묻는 것보다 구체적입니다. 먼저 확인 결과를 받은 뒤 계정 할당 문제인지 구독 형식 문제인지 판단하세요.
업데이트 시점과 복구 순서
갱신, 인증 정보 재설정 또는 계정 설정 변경 직후에는 클라이언트가 가져오는 내용에 서버의 최종 상태가 아직 반영되지 않았을 수 있습니다. 임의로 고정 대기 시간을 정하지 말고 서비스 제공업체가 안내한 적용 시점이나 새로 고침 간격을 확인한 뒤, 적용 여부가 확인되면 업데이트하세요. 특히 429가 발생했다면 짧은 시간 동안 반복 요청하지 마세요.
아직 사용할 수 있는 기존 항목은 네트워크 테스트를 위한 비교 기준으로 남겨 두세요. 복구하기 전에 앱을 삭제하고 Config를 지우고 구독을 초기화하는 작업을 한꺼번에 하지 마세요. 비교에 필요한 정보가 줄어들고 원격 서버의 빈 응답도 해결할 수 없습니다. 내보낸 설정에는 서버 인증 정보가 포함될 수 있으므로 기존 백업은 안전하게 보관하세요.
- 현재 구독 이름, 기존 항목 수, 민감 정보를 가린 오류 기록을 저장하세요.
- 계정 페이지에서 유효한 URL을 가져와 대상 구독 설정 한 곳만 변경하세요.
- 네트워크가 안정된 상태에서 확인된 업데이트 방식으로 한 번 실행하고 결과를 기록하세요.
- 항목이 복구되면 Home에서 서버를 선택해 Connectivity Test를 실행한 뒤 실제로 접속해야 하는 페이지도 테스트하세요.
- 항목은 복구됐지만 연결에 실패한다면 연결 문제 해결 절차로 넘어가세요. 구독 목록이 비어 있는 문제로 계속 다루지 마세요.
구독 업데이트 FAQ 및 문의 시 필요한 정보
기존 노드는 작동하는데 구독 업데이트는 왜 실패하나요?
기존 항목은 로컬에 저장되어 있지만 업데이트할 때는 구독 API에 새로 요청을 보냅니다. 기존 항목은 유지하고 구독 인증 정보가 재설정되었는지 확인한 다음 업데이트 요청의 상태 코드를 확인하세요. 연결 테스트 성공을 구독 유효성 확인으로 대신하지 마세요.
새로 고침을 많이 할수록 더 빨리 복구되나요?
아니요. 반복해서 새로 고치면 요청 제한에 걸릴 수 있습니다. 429가 발생하면 Retry-After 또는 서비스 제공업체의 안내에 따라 기다리세요. 간격이 안내되지 않았다면 먼저 서비스 제공업체에 문의하고 자동으로 계속 재시도하지 마세요.
브라우저에서 링크를 열면 로그인을 요구합니다. 클라이언트에서는 어떻게 해야 하나요?
먼저 복사한 주소가 계정 페이지가 아니라 구독 API인지 확인하세요. 브라우저에 로그인되어 있어도 클라이언트가 같은 세션을 자동으로 사용하는 것은 아닙니다. 계정에서 전용 구독 URL을 다시 복사하고, 여전히 로그인 페이지가 반환되면 서비스 제공업체에 API를 확인해 달라고 요청하세요.
업데이트 후 노드 몇 개만 없어졌는데 앱을 다시 설치해야 하나요?
먼저 서비스 제공업체가 반환하는 목록을 변경했는지 확인한 다음 누락된 항목의 형식과 프로토콜 필드를 살펴보세요. 다른 항목이 정상이라면 앱 재설치는 우선 조치가 아닙니다. 누락된 범위를 기록하면 서버 측 변경과 파싱 문제를 구분하는 데 도움이 됩니다.
문제를 문의할 때 전체 구독 URL을 제공해야 하나요?
공개 문의에는 플랫폼, 발생 시각, 오류 원문, 업데이트 전후 항목 수, 네트워크 유형, Update via Proxy 상태만 제공하세요. token, 비밀번호, QR 코드, 인증 정보가 포함된 전체 URL은 공개하지 마세요. 계정 확인이 필요하다면 이용 중인 서비스 제공업체의 비공개 지원 채널을 이용하세요.
클라이언트 연결과 규칙을 더 확인하려면 문제 해결을 참고하세요. 이 문서의 구독 관련 절차는 사용자가 이미 서비스 제공업체와 구독을 보유하고 있다는 전제에 따릅니다.