본인 구독과 서비스 제공업체를 이미 이용 중인데 Shadowrocket에서 구독을 가져오지 못하거나, 업데이트 후 목록이 비거나 기존 항목만 표시되는 경우에 해당합니다. 먼저 현재 항목을 보존한 뒤 링크 오류, 요청 실패, 응답 형식 비호환, 목록 표시 문제를 차례로 구분하세요. 한 번에 한 가지 조건만 변경하고 원래 오류 메시지를 바탕으로 다음 단계를 판단하면, 연결 테스트 실패를 구독 파싱 실패로 오인하지 않을 수 있습니다.
1. 구독 요청·파싱·연결 테스트 구분하기
Shadowrocket은 iPhone과 iPad를 주요 사용 기기로 하는 Apple 플랫폼 전용 상용 앱이며, App Store에서만 받을 수 있습니다. 앱은 일회성 구매 방식입니다. 앱 구매와 서버 회선 요금제는 별개입니다. 이 글은 이미 구독을 보유한 사용자를 대상으로 합니다. 이 사이트는 노드, 구독, 서비스 제공업체를 제공·판매·추천하지 않습니다. 가격, 시스템 요구 사항 및 일반적인 구매 가능 여부는 App Store 페이지에 표시된 내용을 기준으로 확인하세요.
‘구독 업데이트 성공’과 ‘노드 연결 가능’은 서로 다른 상태입니다. 업데이트 과정에서는 먼저 구독 URL에 요청을 보내고, 응답에 포함된 항목을 파싱합니다. 인식 가능한 항목이 확인된 다음에야 노드 연결, 인증, 트래픽 전달을 점검할 수 있습니다. 목록이 비어 있는데 노드 포트를 바꾸거나 프로토콜을 전환하면 대개 문제 발생 지점을 제대로 짚지 못합니다.
- 요청이 완료되지 않음: 시간 초과, 도메인 확인 실패 또는 인증서 오류가 발생한다면 먼저 접속 경로를 확인하세요.
- 응답을 파싱할 수 없음: 요청은 응답을 받았지만, 그 내용이 로그인 페이지나 인증 페이지이거나 호환되지 않는 구독 형식일 수 있습니다.
- 사용 가능한 항목이 없음: 실제로 빈 응답이 왔을 수도 있고, 그룹이 접혀 있거나 검색 조건이 적용되었거나 업데이트 결과가 기존 항목을 대체했을 수도 있습니다.
- 항목은 있지만 연결 테스트가 실패함: 구독 가져오기는 이미 항목 생성 단계까지 진행된 상태입니다. 다시 가져오기를 반복하기보다 해당 노드의 연결 조건을 확인하세요.
2. 구독 URL 전체 확인하기 — 인증 정보는 수정하지 마세요
서비스 제공업체 계정 페이지로 돌아가 Shadowrocket용 구독 URL을 다시 복사하세요. 채팅에 표시된 잘린 미리보기, 스크린샷의 문자 인식 결과, 브라우저 주소창에 보이는 계정 페이지 URL을 바탕으로 구독 링크를 추정하지 마세요. 구독 URL에는 인증 매개변수가 포함되는 경우가 많아 문자 하나만 빠져도 다른 요청이 될 수 있습니다.
https://example.com/sub?token=xxxx위 내용은 실제 구독에 사용할 수 없는 가상 예시이며 URL 구조를 설명하기 위한 것입니다. 프로토콜은 https, 호스트 이름은 example.com, 경로는 /sub, 쿼리 매개변수에는 token이 포함됩니다. 실제 URL의 경로와 매개변수는 각 사용자의 서비스 제공업체가 정하며, 이 예시와 같을 필요는 없습니다.
- 앞뒤 문자 확인: 잘못 복사된 공백, 줄바꿈, 따옴표, 한국어 마침표를 제거하세요. URL 내부에 원래 있던 기호는 삭제하지 마세요.
- 매개변수 확인:
?,&,=뒤의 값이 빠지지 않았는지 확인하세요.%가 포함된 문자열을 임의로 디코딩한 뒤 다시 조합하지 마세요. - 링크 용도 확인: 계정 로그인 페이지, 구매 내역 페이지, 구독 URL은 서로 다릅니다. 노드 하나를 공유하는 내용도 지속적으로 업데이트할 수 있는 구독 URL과는 다릅니다.
- 초기화 여부 확인: 계정 페이지에서 구독 인증 정보를 초기화했다면 이전 URL이 즉시 무효가 될 수 있습니다. 새로 복사한 URL을 사용하세요.
- 구독 출처 보존: Home에서 해당 구독의 편집 메뉴를 찾아 저장된 URL을 확인하세요. 수정 사항을 저장하기 전에 소속 그룹과 기존 항목 수를 기록해 두면 같은 이름의 구독을 여러 개 추가하는 일을 피할 수 있습니다.
3. 네트워크 실패와 서버 거부 구분하기
한 번 업데이트를 시도한 뒤 전체 오류 메시지를 기록하고, 네트워크를 점검할지 계정 상태를 확인할지 판단하세요. 아래 내용은 응답, 로그 또는 진단 결과에 나타날 수 있는 표준 HTTP 상태 표시줄입니다. Shadowrocket의 모든 화면에 그대로 표시된다는 뜻은 아니므로, 이번 요청 기록을 기준으로 판단하세요.
오류: 401 Unauthorized
원인: 서버가 현재 요청의 인증 정보를 받아들이지 않았습니다. 인증 정보가 만료되었을 수 있습니다. 해결: 본인 계정 페이지에서 구독 권한을 확인하고 URL을 다시 복사하세요. token 값을 추측하며 반복해서 바꾸지 마세요.
오류: 403 Forbidden
원인: 서버에서 접근을 거부했습니다. 권한, 접근 정책 또는 요청 출처 제한이 원인일 수 있습니다. 해결: 발생 시각과 네트워크 유형을 기록한 뒤 본인의 서비스 제공업체에 제한 이유를 문의하세요. 403만으로 계정이 만료되었다고 단정할 수는 없습니다.
오류: 404 Not Found
원인: 요청 경로를 찾을 수 없습니다. 링크가 잘렸거나 접속 주소가 변경되었을 수 있으며, 서버가 유효하지 않은 리소스를 숨기기 위해 이 상태 코드를 사용할 수도 있습니다. 해결: 계정 페이지에서 전체 구독 URL을 다시 받아 저장된 URL과 대조하세요. 경로를 임의로 추측해 덧붙이지 마세요.
오류: 429 Too Many Requests
원인: 서버에서 요청이 지나치게 잦다고 판단했습니다. 해결: 연속 새로고침을 멈추세요. 응답에 Retry-After가 있으면 지정된 시간만큼 기다리고, 표시되지 않으면 서비스 제공업체의 안내에 따라 다시 시도하세요.
요청 시간 초과나 도메인 확인 오류라면 서버에 요청이 도달하지 않았을 수 있습니다. 현재 Wi-Fi에서 웹 인증이 필요한지 먼저 확인한 뒤, 가능하다면 셀룰러 네트워크로 한 번 비교해 보세요. 인증서 오류가 발생하면 기기의 날짜와 시간, 네트워크 인증 상태, 서버 인증서를 확인하세요. 인증서 검증을 끄는 방식으로 문제를 덮어서는 안 됩니다.
결론: 거부 응답을 받았다면 먼저 권한을 확인하세요
401이나 403 등의 응답이 있다면 먼저 구독 권한과 서버의 접근 요건을 확인하세요. 응답을 받지 못했다면 네트워크 경로부터 점검하세요. 두 상황을 모두 노드 프로토콜 변경으로 해결하려고 하지 마세요.
4. 요청이 완료되면 응답 내용의 파싱 가능 여부 확인하기
HTTP 요청 성공은 전송 단계에서 응답을 받았다는 뜻일 뿐, 그 응답이 유효한 구독이라는 보장은 아닙니다. 서버가 200을 반환해도 로그인 페이지, 대화형 인증 페이지, 점검 안내 또는 빈 텍스트가 올 수 있습니다. 브라우저에서 URL이 열린다고 해서 Shadowrocket이 노드 항목을 읽을 수 있다는 뜻도 아닙니다. 브라우저에는 로그인 상태가 남아 있지만 앱의 구독 요청에는 그 상태가 전달되지 않을 수 있습니다.
| 확인된 결과 | 의미 | 다음 단계 |
|---|---|---|
| 로그인 또는 인증 페이지가 표시됨 | 파싱 가능한 구독 내용이 아니라 웹페이지를 받은 상태입니다 | 전용 구독 URL을 사용했는지 확인하고, 서비스 제공업체에 API 응답을 확인해 달라고 요청하세요 |
| 빈 내용이 반환됨 | 이번 응답에 파싱할 본문이 없습니다 | 계정의 구독 상태와 표시 가능한 항목, 서버 생성 결과를 확인하세요 |
| 본문은 있지만 모든 항목의 파싱에 실패함 | 형식 비호환, 내용 잘림 또는 불완전한 데이터 필드가 원인일 수 있습니다 | Shadowrocket용으로 명시된 구독 형식을 사용하고, 오류 정보는 민감한 내용을 가린 뒤 보관하세요 |
| 일부 항목만 표시됨 | 일부 레코드가 유효하지 않거나 현재 화면에 결과가 전부 표시되지 않았을 수 있습니다 | 먼저 검색 조건을 지우고 그룹을 펼친 다음 서버에서 반환해야 하는 항목과 비교하세요 |
Shadowsocks, VMess, VLESS, Trojan, Hysteria2, WireGuard는 프로토콜 이름일 뿐, 구독 텍스트 전체가 유효한지 판단하는 충분한 기준은 아닙니다. 이런 이름이 포함되어 있어도 각 레코드의 인증 정보, 주소, 포트, 전송 매개변수가 완전하다는 뜻은 아닙니다. 가져오기가 ‘성공한 것처럼’ 보이게 하려고 프로토콜 이름을 일괄 변경하거나 포트를 임의로 입력하거나 웹페이지 소스를 노드 텍스트인 것처럼 붙여 넣지 마세요.
- 계정 페이지에서 형식을 선택할 수 있다면 Shadowrocket용이라고 명시된 형식을 고르세요. 파일 확장자만으로 판단하지 마세요.
- 일부 항목만 가져와졌다면 전체 구독 본문을 공개하지 말고, 누락된 항목의 범위를 구체적으로 정리해 본인의 서비스 제공업체에 문의하세요.
- 서버에서 비정상적인 내용이 반환되는 경우, 앱에서 새로고침을 반복해도 서버가 생성하는 데이터가 수정되지는 않습니다.
5. Home으로 돌아가 표시 문제와 업데이트 시점 확인하기
Home에서 검색을 종료하고 구독 그룹을 펼친 다음, 다른 동명 그룹이 아니라 확인하려는 구독이 맞는지 확인하세요. 업데이트 전 항목 수와 아직 사용할 수 있는 기존 항목이 있는지도 기록합니다. 업데이트가 실패한 뒤에도 이전 목록이 남아 있다고 최신 내용을 받은 것은 아닙니다. 목록이 갑자기 비어도 앱이 유효한 데이터를 삭제했다고 단정할 수는 없습니다.
- 현재 상태 보존: 그룹 이름, 업데이트 전 항목 수, 오류 메시지, 작업 시각을 기록하세요. 먼저 그룹 전체를 삭제하거나 앱을 다시 설치하지 마세요.
- 구독 하나만 업데이트: Home에서 대상 구독의 업데이트 기능을 찾아 수동 업데이트를 한 번 실행하세요. 화면 배치에 따라 메뉴가 다르면 현재 구독 항목에 표시된 업데이트 기능을 사용하세요.
- 결과가 나올 때까지 기다리기: 요청이 끝난 뒤 결과를 확인하세요. 연속으로 실행하지 말고, 여러 그룹을 동시에 업데이트해 결과가 섞이지 않도록 하세요.
- 요청 경로 확인: 구독을 프록시를 통해 업데이트하는 설정이 있다면 현재 연결이 정상인지 먼저 확인하세요. 빈 목록에 있는 노드에 의존해 구독을 가져오려고 하면 완료할 수 없는 의존 관계가 됩니다.
- 평소 설정 복원: 문제 해결 중 자동 업데이트를 일시 중지하거나 접속 경로를 변경했다면, 문제가 해결된 뒤 원래 설정으로 되돌리세요. 다음 자동 업데이트에서 같은 문제가 반복되지 않도록 성공한 조건을 기록해 두세요.
Global Routing의 Config, Proxy, Direct, Scene은 트래픽 처리 모드이며 구독 형식을 변환하는 기능이 아닙니다. 구독 요청이 프록시를 통하는지는 앱의 관련 업데이트 설정과 현재 네트워크 경로에 따라 달라집니다. Proxy로 전환했다고 해서 구독이 반드시 프록시를 통해 업데이트된다고 단정할 수 없습니다. Settings → On Demand는 조건에 따라 연결을 시작하는 기능이며, 만료된 링크나 호환되지 않는 응답을 해결하지 않습니다.
결론: 기존 항목을 사용할 수 있다면 먼저 보존한 뒤 확인하세요
먼저 구독 요청이나 응답 내용을 수정한 다음 항목이 복구되는지 확인하세요. 업데이트 기능을 시험하려고 현재 사용할 수 있는 항목을 삭제하면 비교 정보와 사용 가능한 연결 경로를 함께 잃을 수 있습니다.
6. 자주 묻는 질문과 문제 확인 자료 준비
위 순서로 확인해도 원인을 찾지 못했다면 시도를 계속 반복하기보다 한 번의 실패 기록을 정리하는 편이 효과적입니다. 문제를 ‘링크, 요청, 응답, 파싱, 표시’ 중 한 단계로 좁히면 중복 점검을 줄이고 계정 권한 문제를 앱의 연결 설정으로 처리하는 일도 막을 수 있습니다.
브라우저에서는 구독 URL이 열리는데 앱에서 파싱에 실패하는 이유는 무엇인가요?
브라우저에 표시되는 내용이 로그인 페이지나 인증 페이지가 아니라 실제 구독 내용인지 먼저 확인하세요. 브라우저에는 로그인 상태가 남아 있을 수 있습니다. 계정 페이지에서 전용 구독 URL을 다시 복사하고, 로그인하지 않은 요청에서 어떤 응답이 오는지 본인의 서비스 제공업체에 확인해 달라고 요청하세요.
목록에 항목은 있지만 모두 시간 초과됩니다. 다시 가져와야 하나요?
구독은 그대로 보존하고 Home에서 기존 항목의 연결을 테스트한 다음 서버 상태와 노드 인증 정보를 확인하세요. 항목이 표시된다는 것은 적어도 일부 내용은 파싱되었다는 뜻입니다. 연결 시간 초과만으로 구독 URL이 잘못되었다고 볼 수는 없습니다.
업데이트 직후 목록이 비었는데 새로고침을 연속으로 해도 되나요?
먼저 반복 요청을 중단하고 검색 조건을 지운 뒤 그룹을 펼쳐 계정 페이지에 항목이 있어야 하는지 확인하세요. 서버가 실제로 빈 내용을 반환했거나 429가 발생했다면 내용 문제를 해결하거나 제한이 해제될 때까지 기다려야 합니다. 계속 새로고침하지 마세요.
네트워크를 바꾸니 성공했습니다. 모든 노드를 수정해야 하나요?
먼저 일괄 수정할 필요는 없습니다. 성공·실패 당시 사용한 네트워크, 프록시 경유 여부, 오류 메시지를 기록하세요. 특히 구독 도메인 확인, 네트워크 인증, 요청 접근 제한을 점검해야 합니다. 노드 매개변수와 구독 요청은 별개의 점검 대상입니다.
서비스 제공업체에 문의하기 전에 다음 정보를 준비하세요
- 발생 시각: 서버 요청 기록과 대조할 수 있도록 실제 날짜와 시각, 시간대를 적으세요.
- 작업 위치: 처음 가져오기 중이었는지, Home에서 기존 구독을 업데이트했는지와 문제 전후의 항목 수를 적으세요.
- 원래 표시된 메시지: ‘작동하지 않는다’고만 설명하지 말고 전체 오류 문구나 상태 코드를 보관하세요. 스크린샷에서는 인증 정보, QR 코드, 개인 정보를 가리세요.
- 비교 결과: Wi-Fi와 셀룰러 네트워크에서 차이가 있었는지, 기존 구독 중 특정 항목만 실패했는지, 업데이트 경로를 변경했는지 적으세요.
- 앱 환경: 기기, 시스템, 앱에 실제로 표시되는 버전 정보를 제공하세요. 버전을 추측하지 말고 문제 해결을 위해 먼저 로컬 구성을 모두 지우지도 마세요.
문제 해결이 완료되었다고 판단하려면 대상 구독 요청이 끝나고, 응답이 파싱되며, Home에 예상한 항목이 표시된 뒤 노드 연결 결과도 별도로 확인해야 합니다. 오류 메시지가 사라진 것만으로 복구를 판단하지 마세요. 한 번 업데이트에 성공했다고 이후 모든 회선을 사용할 수 있다고 단정해서도 안 됩니다.