Subscribe: 구독과 항목의 관계 설정
구독은 서버 정보를 가져오기 위한 원격 주소이며, 서버 자체가 아닙니다. Shadowrocket은 해당 주소에 요청을 보내고 응답 내용을 읽은 뒤 인식할 수 있는 항목을 서버 목록에 표시합니다. 따라서 구독 주소 접속, 목록 표시, 서버 연결은 각각 별도로 확인해야 합니다. 원격 콘텐츠는 바뀔 수 있으므로 오늘 가져온 이름과 개수, 정렬 상태만으로 다음 업데이트 결과를 예상할 수 없습니다. 시작하기 전에 받은 정보가 Shadowrocket용 구독 주소인지 확인하세요. 안내 페이지나 계정 페이지, 단일 서버 공유 링크와는 다릅니다.
Home에서 Subscribe 추가하기
Home의 추가 메뉴를 눌러 Add Server로 이동한 다음, Type에서 Subscribe를 선택하고 구독 URL과 알아보기 쉬운 이름을 입력합니다. 메뉴 이름이나 배치는 앱 업데이트에 따라 달라질 수 있으므로 실제 화면을 기준으로 하되, Subscribe 유형 항목을 추가해야 한다는 점은 같습니다. 전체 주소는 URL 필드에 입력하고 서버 Address에는 넣지 마세요. 저장 전에 주소의 시작과 끝, 쿼리 매개변수를 확인하고 복사 과정에서 공백이나 줄바꿈, 한글 문장부호, 채팅 안내 문구가 섞이지 않았는지 살펴보세요.
이름은 기기에서 항목을 구분하기 위한 용도입니다. 예를 들어 ‘개인용 구독’처럼 목적이나 출처를 적고 전체 주소는 넣지 마세요. 인증 매개변수가 포함된 URL은 접근 자격 증명과 같으므로 다른 사람이 알게 되면 서버 정보를 읽을 수 있습니다. 입력 후 저장하고 구독을 읽은 결과를 확인하세요. 연결된 항목이 표시되는지, 오류가 안내되는지, 항목 유형이 예상과 맞는지 살펴봅니다. 최초 가져오기는 현재 네트워크, 구독 주소의 유효성, 원격 서버 응답에 영향을 받습니다. 저장했다고 해서 읽기가 완료된 것은 아닙니다.
추가 위치, 응답, 콘텐츠를 각각 확인
목록이 비어 있다면 먼저 구독 항목으로 돌아가 URL이 온전한지 확인한 다음 요청 실패와 파싱 실패를 구분하세요. 요청 실패라면 로컬 네트워크, 도메인 해석, 원격 서버 접속 가능 여부, 인증 상태를 확인해야 합니다. 파싱 실패는 웹페이지나 로그인 안내, 오류 문구가 반환됐거나 현재 가져오기 방식과 형식이 맞지 않는 경우일 수 있습니다. 목록이 비었다고 프로토콜 필드를 무작정 바꾸거나 기존 항목을 전부 삭제하지 마세요. 확인 중에도 복구할 수 있도록 현재 사용할 수 있는 항목은 남겨 두세요.
주소에 긴 쿼리 매개변수가 있다면 도메인만 보지 말고 원본 자료와 구간별로 비교하세요. 원격 주소의 매개변수는 계정, 형식, 접근 권한을 구분할 수 있으며 문자 하나만 빠져도 응답이 달라질 수 있습니다. 서비스 제공자에게 문의할 때는 오류 유형과 발생 단계, 네트워크 환경을 설명하면 됩니다. 스크린샷을 보낼 때는 URL, 인증 매개변수, 서버 자격 증명을 가리세요. 가져오기 실패를 설명하기 위해 구독 내용을 전부 공개할 필요는 없습니다.
구독은 Config가 아닙니다
Subscribe는 서버 항목을 어디서 가져올지 관리하고, Config는 규칙과 관련 설정을 구성합니다. 서버 목록만 있다고 현재 용도에 맞는 트래픽 분기 규칙까지 준비된 것은 아닙니다. 규칙 파일이 있어도 사용할 서버가 입력되어 있다는 뜻은 아닙니다. 가져오기가 끝나면 Home으로 돌아가 실제 선택된 서버를 확인하고 Global Routing도 살펴보세요. 규칙에 따라 트래픽을 처리하려면 Config 모드를 사용하되, 실제 요청 경로는 현재 활성화된 설정 내용으로 확인해야 합니다. 모드 이름만으로 요청 경로를 판단하지 마세요.
마지막으로 목록에 나타나는지만 보지 말고 실제 웹 요청을 보내 연결을 확인하세요. 연결 스위치, 서버 선택, 요청 경로 설정 방법은 시작하기에서 확인할 수 있습니다. 구독을 정상적으로 읽었는데도 접속할 수 없다면 테스트 및 정렬 항목에서 단계별로 점검해 Subscribe 가져오기 문제와 서버 연결 문제를 구분하세요.
Add Server: 수동 입력 필드 하나씩 확인하기
Add Server는 보유한 단일 서버 정보를 입력하거나 구독과 별도로 관리할 소수의 항목을 저장할 때 유용합니다. 수동 입력 전에 주소와 포트만이 아니라 필요한 매개변수 전체를 준비하세요. 프로토콜마다 인증, 암호화, 전송, TLS 요구 사항이 다릅니다. 필드 이름이 비슷하다고 이전 항목의 값을 그대로 사용하지 마세요. 먼저 올바른 Type을 선택하고 제공받은 매개변수를 하나씩 입력하는 편이 좋습니다. 주소부터 입력한 뒤 프로토콜을 바꾸는 것보다 확인하기 쉽고, 프로토콜 변경으로 추가된 필드를 놓칠 가능성도 줄어듭니다.
기본 필드와 인증 정보
Address에는 연결 대상인 도메인 또는 IP 주소를 입력하고, Port에는 서비스가 수신 대기하는 포트 번호를 따로 입력합니다. 필드에서 URL을 명시적으로 요구하지 않는 한 웹페이지 경로나 전체 공유 링크를 Address에 붙이지 마세요. Password, UUID 등 인증 필드는 원래 값 그대로 입력해야 합니다. 대소문자와 하이픈, 끝에 붙은 공백도 확인하세요. Remarks는 로컬에서 항목을 구분하는 이름이며 인증에는 사용되지 않습니다. 나중에 비슷한 항목을 구별할 수 있도록 ‘용도-프로토콜-표시’ 형식으로 작성할 수 있습니다.
| 매개변수 유형 | 확인할 내용 | 자주 혼동하는 점 |
|---|---|---|
| Type | 보유 자료와 프로토콜 일치 | 이름만 보고 프로토콜 추측 |
| Address / Port | 연결 대상과 수신 포트 | 전체 URL을 Address에 입력 |
| Password / UUID | 인증 정보 전체 | 문자 누락 또는 불필요한 공백 |
| TLS / SNI | 서버에서 요구하는 암호화 및 이름 매개변수 | 연결 주소를 SNI로 간주 |
| 전송 매개변수 | 전송 유형, 경로 및 관련 필드 | 경로 앞의 슬래시 누락 |
프로토콜 필드는 서로 대체할 수 없습니다
Shadowsocks에서는 인증 정보와 암호화 방식을 일치시켜야 합니다. VMess와 VLESS는 보통 식별자와 해당 전송 설정을 함께 확인해야 하며, Trojan은 인증 및 TLS 요구 사항을 점검해야 합니다. Hysteria2는 고유한 인증 및 연결 매개변수를 확인하고, WireGuard는 키, 주소, 피어 등 별도의 설정 구조를 사용합니다. 프로토콜 이름은 유형을 나타낼 뿐이며, 같은 프로토콜을 사용하는 두 항목의 추가 필드까지 같다는 뜻은 아닙니다. 정보가 빠졌다면 원래 매개변수를 확인하세요. 옵션을 계속 바꾸며 작동하는 조합을 추측하지 마세요.
TLS 이름, HTTP Host, 서버 Address는 같을 수도 다를 수도 있습니다. 모두 도메인처럼 보인다고 하나로 취급하면 안 됩니다. Address는 연결 대상을 찾는 데 사용되고, SNI는 인증서의 서버 이름 확인과 관련이 있습니다. 일부 전송 방식에서 Host나 경로는 서버 측 진입점과 일치해야 합니다. 서버에서 해당 값을 제공했다면 그대로 사용하세요. 연결에 실패해도 이름 오류를 감추려고 인증서 확인을 완화하지 마세요. 매개변수 오류와 인증서 문제는 따로 확인해야 합니다.
저장 후 기본 확인부터 진행
항목을 저장한 뒤 Home으로 돌아가 실제로 추가됐는지, 선택 표시가 해당 항목에 있는지 확인하세요. 이름이 비슷한 서버를 여러 개 보관한다면 화면의 이름만 보고 혼동하기 쉽습니다. 세부 정보에서 주소 뒷부분, 프로토콜, 메모를 다시 확인하세요. 먼저 새 항목을 테스트한 다음 실제 요청을 해 보세요. 비슷한 항목을 한꺼번에 많이 추가한 뒤 몰아서 문제를 찾지 마세요. 한 번에 필드 하나만 바꾸고 변경 이유를 기록해야 인증, 전송, 로컬 네트워크 중 무엇이 결과에 영향을 줬는지 판단할 수 있습니다.
수동으로 추가한 항목은 일반적으로 사용자가 직접 관리해야 하며 구독 업데이트가 매개변수를 자동으로 수정한다고 볼 수 없습니다. 반대로 구독에서 만들어진 항목을 편집할 수 있더라도 다음 업데이트 때 원격 내용에 따라 다시 구성되어 변경 사항이 유지되지 않을 수 있습니다. 별도로 조정해야 한다면 저장 방식을 확인한 뒤 구독과의 관계를 알아볼 수 있도록 수동 항목으로 따로 저장하세요. 이름이 같은 항목을 백업으로 간주하지 마세요. 백업에는 전체 매개변수와 복구 방법이 있어야 하며 목록의 제목만 하나 더 있다고 충분한 것이 아닙니다.
한 항목만 계속 실패하고 같은 네트워크에서 다른 항목은 정상이라면 해당 항목의 프로토콜과 인증 정보를 먼저 확인하세요. 모든 항목이 동시에 실패한다면 네트워크 환경, 연결 상태, 실제 요청 경로를 점검해야 합니다. 문제 범위를 좁히는 것이 서버를 계속 추가하거나 삭제하는 것보다 효과적입니다.
QR 코드 및 클립보드: 가져오기 전 내용 확인
Scan QR Code와 클립보드 가져오기는 입력 경로일 뿐, 내용의 종류를 결정하지 않습니다. QR 코드에는 단일 서버 공유 링크나 구독 URL, 일반 안내 문구가 들어 있을 수 있습니다. 클립보드에도 제목, 안내 문구, 여러 주소가 함께 들어갈 수 있습니다. 가져오기 전에 내용이 지속적으로 업데이트되는 구독인지 독립 서버 항목인지 확인한 뒤 알맞은 메뉴를 선택하세요. 일반 웹 주소를 서버로 가져오거나 서버 링크를 Subscribe URL로 넣으면 이후 동작이 예상과 달라집니다.
Scan QR Code 확인 순서
Home에서 스캔 메뉴를 찾아 Scan QR Code를 실행하세요. 카메라를 처음 사용할 때는 시스템 안내에 따라 접근 허용 여부를 선택합니다. 카메라 권한은 QR 코드를 읽기 위한 것이며 네트워크 연결을 허용하는 권한과는 다릅니다. QR 코드 전체가 화면에 들어오도록 하고 빛 반사, 큰 기울기, 흐릿한 이미지를 피하세요. 내용을 인식한 뒤 서버 세부 정보인지 구독 정보인지 다른 안내인지 확인합니다. 확인 단계가 나타나면 저장 전에 프로토콜, 메모, 주소가 본인 자료와 일치하는지 살펴보세요.
QR 코드가 같은 기기의 사진에 있다면 현재 스캔 메뉴에서 사진 가져오기를 지원하는지 확인하고, 지원한다면 해당 이미지를 선택하세요. 그런 메뉴가 없다면 화면을 반복해서 촬영하지 말고 원본 자료에서 텍스트를 복사하세요. 읽기에 실패하면 서버가 작동하지 않는다고 단정하기 전에 이미지 선명도와 가장자리 잘림, 압축, 내용 길이를 확인합니다. QR 코드는 광학 인식 단계에서 아직 매개변수로 변환되지 않았으므로 이 과정에는 네트워크 연결이 관여하지 않습니다. 두 문제를 나누어 점검하세요.
클립보드에는 필요한 전체 텍스트만 복사
복사할 때 링크 하나를 처음부터 끝까지 선택하고 항목 번호나 따옴표, 끝 문장부호가 함께 들어가지 않도록 하세요. Shadowrocket으로 돌아왔을 때 클립보드 접근 또는 가져오기 안내가 표시되면 출처를 확인한 뒤 진행하세요. 현재 화면에 가져오기 메뉴가 있다면 이를 사용해도 됩니다. 시스템에서 붙여넣기 허용 여부를 물으면 이번 작업에 필요한 범위에서 선택하세요. 안내가 나타나지 않는다고 해서 앱 오류는 아닙니다. 클립보드 내용이 불완전하거나 형식을 인식하지 못했을 수 있고, 시스템 권한이나 작업 경로가 다를 수도 있습니다.
가져온 뒤 새 항목이 없다면 같은 항목이 이미 있는지 확인하고, 텍스트에 안내 문구만 들어 있는지도 살펴보세요. 안내를 띄우려고 다른 내용을 연이어 복사하면 원본 자료가 덮어써질 수 있습니다. 여러 공유 링크가 포함된 텍스트라면 원본 사본을 먼저 보관한 다음 나누어 가져오고 결과를 확인하세요. 일괄 가져오기에 성공했다고 모든 매개변수가 올바른 것은 아닙니다. 프로토콜 유형과 이름, 소속 그룹을 표본 점검하고 중요한 항목은 각각 확인하세요.
권한 허용, 저장, 연결은 별개의 단계
카메라·사진·클립보드 권한과 VPN 구성을 처음 추가할 때 필요한 시스템 승인은 각각 목적이 다릅니다. 가져오기는 기기에 매개변수를 추가하는 작업입니다. 연결을 실제로 켤 때 시스템에서 VPN 구성 추가를 허용할지 물을 수 있습니다. 시스템 상단 상태 표시나 Home 스위치만 보고 가져오기 완료 여부를 판단하지 마세요. 저장 후 항목이 어디에 있는지 확인하고 서버를 선택한 다음 Global Routing을 점검하고 실제 요청을 보내세요. 이렇게 하면 오류가 어느 단계에서 생겼는지 구분할 수 있습니다.
가져오기가 끝나면 클립보드에 민감한 내용이 남아 있는지 확인하고, QR 코드 이미지도 본인의 자료 관리 방식에 따라 정리하세요. 복구 자료를 보관할 때는 보호되는 위치를 사용하고 공개 앨범이나 공유 메모, 채팅방에 장기간 두지 마세요. 클립보드 사본을 지워도 이미 노출된 자격 증명이 무효화되지는 않습니다. 유출이 의심되면 해당 서비스 관리 화면에서 자격 증명을 변경한 뒤 클라이언트 항목을 업데이트하세요.
같은 자료를 입력 방식에 따라 다르게 가져왔다면 QR 코드의 모양이 아니라 실제로 인식된 텍스트를 비교하세요. 줄바꿈과 인코딩, 문자 누락은 복사나 인식 과정에서 발생할 수 있습니다. 문제를 ‘텍스트를 읽을 수 있는가’, ‘항목을 파싱할 수 있는가’, ‘연결할 수 있는가’의 세 단계로 나누어 확인하세요.
구독 업데이트: 결과 확인 후 설정 조정
구독 업데이트는 원격 주소에 다시 요청을 보내 응답 내용을 처리하는 기능이며 앱 업데이트와는 다릅니다. 앱은 App Store에서 업데이트하고, 서버 목록은 Subscribe 항목 및 원격 콘텐츠에 따라 갱신됩니다. 업데이트 대상과 실패 원인, 복구 방법도 서로 다릅니다. 구독 업데이트로 이름이 바뀌거나 항목이 추가되고 매개변수가 조정되거나 기존 항목이 삭제될 수 있습니다. 업데이트 전에 현재 사용하는 서버와 해당 서버가 속한 구독을 알아 두면 변경 사항을 정확하게 확인할 수 있습니다.
수동 업데이트로 기준 만들기
구독을 처음 설정할 때는 결과를 확인할 수 있도록 수동 업데이트를 한 번 실행하세요. Home에서 해당 구독 항목이나 관련 작업 메뉴를 통해 업데이트한 뒤 결과를 기다리고 소속 서버 목록을 확인합니다. 메뉴 위치는 현재 앱 화면을 기준으로 하세요. 서버 하나를 테스트하는 작업을 구독 업데이트로 혼동하지 마세요. 요청 오류가 표시되지 않고 목록이 파싱되며 중요한 항목의 필드가 예상과 맞아야 업데이트 기준이 마련된 것입니다. 업데이트 작업이 끝났다는 표시만으로 모든 서버에 연결할 수 있다고 판단할 수는 없습니다.
화면에 업데이트 상태나 시간이 표시되면 이번 확인의 참고 자료로 활용할 수 있지만, 그것만으로 원격 콘텐츠 변경 여부를 판단하지 마세요. 이미 알고 있는 항목 한두 개의 이름과 프로토콜, 주소가 현재 자료와 일치하는지 확인하세요. 원격 목록은 내용이 바뀌지 않아도 정상 응답할 수 있습니다. 반대로 웹 오류가 반환됐다면 유효한 서버 목록을 받은 것이 아닙니다. 문제가 생기면 처음 표시된 상황을 파악할 수 있도록 안내를 남겨 두고, 첫 실패를 덮어쓸 수 있으니 업데이트를 연속으로 누르지 마세요.
복구 가능성을 고려해 자동 업데이트 설정
현재 Subscribe 설정에 자동 업데이트나 간격 옵션이 있다면 사용 빈도와 네트워크 환경에 맞춰 설정하되, 수동 업데이트가 정상적으로 되는지 먼저 확인하세요. 자동화로 잘못된 주소나 인증 정보, 호환되지 않는 형식을 바로잡을 수는 없습니다. 조건에 따라 요청을 다시 실행할 뿐입니다. 설정된 간격이 정확한 백그라운드 실행 시점을 보장하는 것도 아닙니다. 기기 상태와 시스템 스케줄, 앱 실행 조건에 따라 실제 실행 시점이 달라질 수 있습니다. 중요한 작업 전에는 원격 변경이 이미 반영됐다고 가정하지 말고 결과를 직접 확인하세요.
모바일 네트워크와 Wi-Fi의 접속 가능 여부는 다를 수 있습니다. 업데이트에 실패하면 사용한 네트워크와 연결 스위치 상태, 오류 유형을 기록하세요. 업데이트 요청이 선택한 서버를 반드시 거친다고 단정하지 마세요. 실제 경로는 앱 설정과 네트워크 상태에 영향을 받으므로 확인 가능한 결과를 기준으로 점검해야 합니다. 네트워크를 바꾼 뒤 성공했다면 원래 네트워크의 이름 해석이나 접속 조건을 추가로 확인하세요. 구독 전체를 바로 다시 만들 필요는 없습니다. 한 번에 조건 하나만 바꾸면 원인과 결과를 파악하기 쉽습니다.
업데이트 후 이름 변경과 로컬 편집
원격 구독은 보통 생성된 항목의 매개변수 원본입니다. 이름이나 필드를 로컬에서 수정해도 이후 업데이트에서 덮어쓸 수 있습니다. 특별한 용도의 독립 항목을 보존해야 한다면 별도로 관리하고 원격에서 자동으로 수정되지 않는다는 점을 명확히 하세요. 원격 목록에서 서버가 삭제되면 로컬 목록에서도 사라질 수 있으며, 이는 직접 삭제한 경우와 원인이 다릅니다. 업데이트 후 선택했던 항목이 보이지 않으면 실제 선택 항목을 다시 확인하세요. Home 스위치가 켜져 있다고 해서 이전 대상이 계속 사용 중인 것은 아닙니다.
구독 주소 문제와 서버 연결 문제도 따로 판단해야 합니다. 구독 요청은 실패해도 저장된 서버에 연결할 수 있다면 목록 진입점에 문제가 있을 수 있습니다. 목록 업데이트는 성공했지만 모든 서버 연결이 실패한다면 인증 상태와 서버 변경 여부, 로컬 네트워크를 확인하세요. 원격에서 구독 주소를 바꿨다면 올바른 Subscribe 항목을 수정하고 새 결과를 확인한 뒤 안정성을 점검하세요. 이름이 같다는 이유만으로 두 항목이 완전히 동일하다고 판단하지 마세요.
업데이트 후 웹페이지 접속에 문제가 있지만 응답 시간은 표시된다면 DNS 해석 실패 문제 해결을 참고해 추가로 점검하세요. ‘목록 가져오기’, ‘연결 수립’, ‘도메인 해석’, ‘웹 요청’을 나누어 기록하면 잘못된 단계에서 업데이트를 반복하는 일을 막을 수 있습니다. 자동 업데이트는 잦은 새로고침보다 안정적으로 관리하고 결과를 확인할 수 있도록 설정해야 합니다.
여러 구독 정리: 출처와 용도 구분하기
이미 보유한 구독을 여러 개 관리한다면 서버 항목마다 어떤 구독에서 생성됐는지, 자동 업데이트되는지, 현재 선택한 이유가 무엇인지 파악하는 것이 중요합니다. 항목이 늘어나면 비슷한 이름과 중복 가져오기, 로컬 편집 때문에 출처가 불분명해지기 쉽습니다. 정리의 목적은 목록을 짧게 만드는 것이 아니라 업데이트와 테스트, 복구 대상을 명확히 하는 것입니다. 정리 전에 원본 자료를 보관하고 현재 사용 중인 항목을 확인하세요. 출처를 구분할 수 없는 상태에서 이름이 비슷한 항목을 일괄 삭제하지 마세요.
이름은 용도를 나타내고 자격 증명은 담지 않기
구독 이름에는 ‘개인용’, ‘임시 확인’처럼 안정적으로 알아볼 수 있는 용도 태그를 사용하세요. 수동으로 입력한 독립 항목에는 ‘수동’ 표시를 추가할 수 있습니다. 서버 메모에는 프로토콜이나 개인 용도를 덧붙이되 전체 인증 정보는 적지 말고 특정 시점의 응답 시간도 이름에 넣지 마세요. 응답 시간은 시각과 네트워크, 테스트 방식에 따라 달라져 금방 오래된 정보가 됩니다. 이름은 항목을 식별하는 데 사용하고 실시간 성능 판단을 맡기지 마세요. 같은 용도라면 복잡한 번호 체계 없이 일관된 이름만 사용해도 충분합니다.
구독의 원격 이름이 자주 바뀌면 로컬에서 수정한 이름이 업데이트 후 덮어써질 수 있으므로 저장 동작을 먼저 확인하세요. 간단한 관리 메모에 구독 용도와 주요 항목의 식별 방법, 관리 절차를 적어 두는 편이 안전합니다. 비밀번호를 복사할 필요 없이 보호된 원본 자료의 위치를 찾을 수 있으면 됩니다. 민감한 URL이 포함된 스크린샷을 유일한 출처 설명으로 사용하지 마세요. 복구에도 도움이 되지 않고 문제 해결 정보를 공유할 때 유출될 위험도 있습니다.
중복 가져오기와 비슷해 보이는 정상 항목 구분
이름이 같아도 같은 서버라는 보장은 없고 주소가 같아도 같은 서비스라는 뜻은 아닙니다. 포트와 프로토콜, 인증, TLS, 전송 경로가 다를 수 있습니다. 반대로 같은 공유 링크를 QR 코드와 클립보드에서 각각 가져와 구분하기 어려운 중복 항목이 생길 수도 있습니다. 정리할 때는 표시 이름에만 의존하지 말고 프로토콜과 연결 매개변수, 소속 구독을 함께 비교하세요. 확신할 수 없다면 먼저 표시해 두고 테스트와 백업을 완료한 뒤 삭제하는 편이 바로 병합하는 것보다 복구하기 쉽습니다.
같은 주소에 연결하는 여러 항목도 서로 다른 네트워크 조건에 맞춰 설정됐을 수 있습니다. 지역 이름이나 태그로 추측하지 말고 실제 용도에 맞게 테스트하세요. 이름에 적힌 지리 정보가 실제 요청의 출구나 고정 회선 정보를 보장하지 않으며, 이 가이드에서는 이를 근거로 서버를 평가하지 않습니다. 사용 여부는 본인의 요구와 매개변수 완전성, 테스트 결과를 기준으로 결정하세요. 검증 가능한 사실과 태그 문구를 구분하면 원격에서 이름이 바뀔 때 로컬 목록을 불필요하게 다시 만들지 않아도 됩니다.
목록 정리는 규칙 선택을 바꾸지 않습니다
목록 위치를 옮기거나 메모를 수정하고 표시 순서를 바꾸는 것은 대개 관리 화면의 변경일 뿐, 규칙이 달라졌다는 뜻은 아닙니다. 실제 요청은 현재 서버 선택과 Global Routing, Config를 함께 확인해야 합니다. Config가 특정 이름이나 정책 참조를 사용한다면 이름을 바꾸기 전에 참조가 기존 이름에 의존하는지 확인하세요. 서버 목록 정리와 설정 관리는 두 단계로 나누세요. 먼저 목록의 항목을 확인하고 규칙 연결을 점검해야 이름과 규칙, 연결 매개변수를 한 번에 바꾸는 상황을 피할 수 있습니다.
| 기록 항목 | 기록 권장 | 기록하지 말아야 할 내용 |
|---|---|---|
| 구독 용도 | 개인 용도 태그 | 전체 인증 URL |
| 항목 출처 | Subscribe 또는 수동 입력 | 이름만 보고 출처 추측 |
| 관리 작업 | 변경한 필드와 확인 결과 | ‘갑자기 안 됨’이라고만 기록 |
| 복구 자료 위치 | 보호된 자료의 위치 설명 | 공개 문서에 자격 증명 기록 |
구독마다 테스트를 통과한 대표 항목 하나를 남겨 두면 업데이트 후 소규모로 확인하기 쉽습니다. 다만 이는 확인용 표본일 뿐 목록 전체가 검증됐다는 뜻은 아닙니다. 모든 구독에서 자동 업데이트를 켤 필요도 없습니다. 먼저 각 구독의 용도를 정하고 관리 주기를 결정하세요. 임시 테스트가 끝나면 바로 정리해 몇 달 뒤 어떤 항목이 실제 사용 중이고 어떤 항목이 문제 해결용 사본인지 헷갈리지 않게 하세요.
목록을 정리한 뒤 실제 요청을 한 번 보내 현재 선택 항목이 이전과 같은지 확인하고 관리 기록도 업데이트하세요. 화면 용어가 헷갈린다면 Home, Config, Data, Settings 화면 안내를 참고하세요. 기억에 의존해 이름이 비슷한 서버를 길게 관리하기보다 각 작업의 대상을 명확히 하는 편이 더 안정적입니다.
응답 시간 테스트와 정렬: 수치의 의미와 한계
Connectivity Test는 특정 테스트 조건에서 응답 상태를 확인하는 기능이며 전체적인 사용 가능성을 증명하지는 않습니다. 테스트 방식에 따라 연결 수립이나 특정 요청의 응답을 확인할 수 있고, 테스트 주소와 시간 초과 설정, 네트워크 상태가 결과에 영향을 줍니다. 수치가 낮다고 다운로드 속도가 빠르거나 모든 웹페이지가 열린다는 뜻은 아닙니다. 서버를 비교할 때는 먼저 같은 방식과 환경에서 테스트했는지 확인하세요. 시간과 네트워크가 다른 결과를 직접 순위로 비교하기는 어렵습니다.
적은 수부터 테스트한 뒤 실제 요청 확인
Home에서 지금 사용할 소수의 항목을 테스트해 정상 결과와 시간 초과, 명확한 오류를 확인하세요. 테스트 후 하나를 선택하고 Global Routing과 현재 Config를 확인한 다음 용도를 잘 아는 웹페이지를 열어 보세요. 실제 연결 확인에는 도메인 해석과 연결 수립, 페이지 콘텐츠 로드가 포함되어야 합니다. 웹페이지 제목이 나타나는지만 확인해서는 충분하지 않습니다. 목록을 테스트했더라도 실제 선택 항목을 확인하지 않으면 다른 항목을 테스트하고 다른 항목을 사용했을 수 있습니다.
일괄 테스트는 뚜렷한 문제를 빠르게 찾는 데 유용하지만 요청을 많이 동시에 보내면 로컬 네트워크와 원격 서버에 순간적으로 부담을 주고 결과에 서로 영향을 미칠 수 있습니다. 목록이 크다면 구독이나 용도별로 나누어 테스트하고 결과가 안정된 뒤 다음 차례로 진행하세요. 한 번의 일괄 시간 초과로 모든 서버가 영구적으로 사용할 수 없다고 판단하지 마세요. 알려진 항목 하나를 개별 재테스트한 다음 다른 네트워크 환경과 비교하세요. 서버와 DNS, 규칙을 동시에 바꾸거나 다시 가져오는 대신 변수를 통제해 재테스트해야 합니다.
정렬은 표시 방식일 뿐 선택을 대신하지 않습니다
현재 화면에서 테스트 결과에 따라 정렬할 수 있다면 이번 결과를 살펴보는 데 활용하세요. 정렬한 뒤에도 선택 표시를 확인해야 합니다. 실제 설정과 화면 상태가 명확히 그렇게 나타나는 경우가 아니라면 표시 순서가 바뀌었다고 첫 번째 항목으로 자동 전환된 것은 아닙니다. 테스트 수치는 시간이 지나면 오래된 정보가 됩니다. Wi-Fi에서 모바일 네트워크로 바뀌면 기존 정렬 결과가 현재 상태를 반영하지 않을 수도 있습니다. 한 번의 정렬 결과에 계속 의존하지 말고 현재 테스트와 실제 요청, 용도를 함께 고려해 선택하세요.
이름과 응답 시간, 안정성은 서로 다른 정보를 나타냅니다. 이름은 자료 제공자나 사용자가 정하고, 응답 시간은 한 번의 테스트 결과이며, 안정성은 여러 사용 시점에 걸쳐 판단해야 합니다. 우연히 가장 낮은 수치를 고정 메모에 적어 장기 기준으로 삼지 마세요. 특정 항목이 될 때도 있고 안 될 때도 있다면 ‘느림’이라고만 기록하기보다 연결 시작, 웹페이지 해석, 데이터 전송 중 어느 단계에서 실패했는지 남기세요. 이후 서버 부하와 네트워크 변동, 설정 차이를 구분하는 데 도움이 됩니다.
실패 단계별로 나누어 문제 해결
구독 업데이트는 정상이지만 테스트가 전반적으로 실패한다면 서버 선택과 인증 정보, 네트워크 접속 가능 여부를 먼저 확인하세요. 테스트 결과는 있는데 웹페이지가 열리지 않으면 DNS와 규칙 경로, 앱의 실제 요청을 점검합니다. 웹페이지는 열리지만 대용량 파일 전송이 느릴 때는 지속적인 전송과 네트워크 조건을 추가로 확인하세요. 테스트 결과 하나로 다른 단계의 문제까지 배제할 수는 없습니다. 실패 단계를 나누어 기록하면 모든 현상을 서버 문제 하나로 돌리는 일을 피할 수 있습니다.
| 관찰된 현상 | 우선 확인할 내용 | 바로 단정할 수 없는 사항 |
|---|---|---|
| 목록을 가져오지 못함 | 구독 URL 및 응답 내용 | 저장된 서버가 모두 작동하지 않음 |
| 단일 항목 테스트 실패 | 해당 항목의 매개변수와 현재 네트워크 | 구독 전체를 사용할 수 없음 |
| 응답 시간은 있지만 웹페이지 접속 실패 | DNS, 규칙, 실제 요청 | 인증 정보와 요청 경로가 모두 올바름 |
| 웹페이지는 정상이지만 전송 속도가 느림 | 지속적인 전송과 네트워크 조건 | 응답 시간이 가장 짧은 항목이 반드시 가장 빠름 |
문제 해결을 위해 일시적으로 명확한 Global Routing 모드를 선택하면 요청 경로를 구분하는 데 도움이 됩니다. 테스트가 끝나면 평소 사용하던 설정으로 되돌리고 복원 후 요청이 예상대로 동작하는지 확인하세요. 임시 검증 설정을 장기간 유지하지 마세요. 모드 설명은 기능 안내에서, 자주 발생하는 문제는 문제 해결에서 확인할 수 있습니다.
속도를 비교할 때는 가능한 한 같은 대상과 비슷한 시간대, 같은 로컬 네트워크를 사용하고 대량 전송 작업을 동시에 실행하지 마세요. 결과가 계속 크게 달라지면 변동 범위와 조건을 기록하면 됩니다. 고정된 수치를 찾으려고 할 필요는 없습니다. 단계별 점검은 속도 저하 단계별 문제 해결을 참고하세요. 테스트의 목적은 문제 범위를 좁히는 것이지 서버에 영구적으로 정상 또는 불량이라는 표시를 붙이는 것이 아닙니다.
삭제와 백업: 로컬 정리와 자격 증명 폐기 구분
삭제 전에 대상이 무엇인지 먼저 확인하세요. 독립 서버 하나인지, 구독에서 생성된 항목인지, Subscribe 전체인지, 현재 Config인지에 따라 복구 방법이 다릅니다. 잘못 삭제한 항목을 모두 다시 업데이트해서 복구할 수 있는 것은 아닙니다. 로컬 항목을 삭제해도 원격 접근 자격 증명이 자동으로 무효화되지는 않습니다. 유출 문제를 처리하려면 해당 서비스 관리 화면에서 자격 증명을 변경하거나 폐기해야 합니다. 기기에서 제거하는 작업과 기존 자격 증명을 무효화하는 작업을 나눠야 정리가 완료됐는지 확인할 수 있습니다.
데이터의 관리 주체부터 확인
독립적으로 수동 입력한 항목은 보통 원본 매개변수나 미리 보관한 유효한 내보내기 자료가 있어야 복구할 수 있습니다. 이름만 기억해서는 인증 및 전송 설정을 재구성할 수 없습니다. 구독에서 생성된 항목은 단독 삭제 후 다시 나타날지 이후 업데이트와 목록 처리 동작에 따라 달라집니다. 원격 목록에 해당 항목이 남아 있다면 다시 목록에 들어올 수 있습니다. 원격 목록을 장기간 변경하려면 같은 서버를 로컬에서 반복 삭제하지 말고 관련 구독 관리 관계를 확인하세요.
Subscribe 전체를 삭제하기 전에 소속 항목이 더는 필요 없는지 확인하고 본인의 원본 URL을 보관하세요. 삭제 후 관련된 로컬 데이터가 정해진 방식으로 모두 남거나 삭제된다고 단정하지 마세요. 현재 확인 메시지를 읽고 Home으로 돌아가 실제 결과를 살펴봅니다. 삭제할 구독의 서버를 사용 중이라면 먼저 명확히 사용할 수 있는 다른 항목으로 전환하고 실제 요청을 확인하세요. 결과가 예상과 달라도 연결과 복구 경로를 동시에 잃지 않을 수 있습니다.
필드와 관계를 복구할 수 있도록 백업
백업에는 구독 원본 자료와 독립 서버 매개변수, 보관할 Config, 각 항목의 용도와 관계가 포함되어야 합니다. 현재 화면에서 공유나 내보내기, 백업 기능을 제공한다면 실제 지원 범위를 확인해 사용하세요. 기능 이름만 보고 모든 데이터가 포함된다고 가정하지 마세요. 내보낸 파일이나 텍스트를 열어 필요한 항목이 실제로 들어 있는지 확인하세요. 특히 서버 공유 링크 하나와 전체 백업을 구분해야 합니다. Config 파일에 모든 서버 인증 정보가 자동으로 포함되는 것도 아닙니다.
백업은 적절한 접근 보호가 적용된 위치에 보관하고 공개 공유 폴더나 단체 채팅, 통제되지 않는 메모에 두지 마세요. 백업 파일에는 구독 URL, Password, UUID, 키가 포함될 수 있으므로 자격 증명처럼 취급해야 합니다. 문제 설명용으로 민감한 필드를 지운 사본은 만들 수 있지만 정식 복구 자료를 대신할 수는 없습니다. 두 자료는 따로 보관하고 용도를 명확히 표시하세요. 기기를 바꿀 때 중요한 매개변수가 빠진 텍스트를 전체 백업으로 착각하지 않도록 주의해야 합니다.
기기 변경 및 재설치: 앱을 받은 뒤 자료 복원
기기를 바꾼 뒤에는 먼저 App Store의 구입 내역에서 Shadowrocket을 확인하고 받은 다음 본인의 구독 및 서버 자료를 복원하세요. 앱 구입 내역과 앱 내부 설정 데이터는 서로 다른 것이므로 앱을 다시 받는 것만으로 각 항목이 자동 복구되지는 않습니다. 구매 적용 범위와 기기 호환성, 시스템 요구 사항은 App Store 페이지 표기를 기준으로 합니다. 앱을 다시 받는 절차는 구입 항목 복원 안내를 참고하세요. 자료 복원 후 서버 선택과 현재 설정, 시스템 연결 허용 여부를 다시 확인해야 합니다.
복원을 확인할 때는 먼저 대표 자료 일부만 가져와 매개변수를 확인하고 실제 연결을 테스트한 다음 나머지를 복원하세요. 백업을 읽을 수 있는지 확인하기 전에 이전 기기의 항목을 삭제하지 마세요. 구독을 다시 읽을 수 있어도 로컬 메모와 독립 항목, 설정 변경까지 복구된 것은 아닙니다. 미리 작성한 복구 목록에 따라 하나씩 확인하세요. 원본 자료가 있고 형식을 읽을 수 있으며 필드가 완전하고 테스트까지 마쳐야 백업이 실제 복구 가치를 갖습니다.
정리 후 현재 연결과 기본 선택 항목, Config가 예상과 맞는지 확인하고 오래된 백업을 처리하세요. 새 백업의 복구 가능성을 확인하기 전에는 복구할 수 있는 이전 사본을 하나 보관하세요. 기존 자격 증명이 무효화됐거나 더는 필요하지 않다는 점을 확인한 뒤 개인 보안 관리 기준에 따라 제거합니다. 정리한 날짜만 기록하기보다 ‘무엇을 삭제했고 무엇을 보관했는지, 어떻게 복구하는지’를 적어 두면 다음 기기 변경이나 문제 해결 때 자료를 빠르게 찾을 수 있습니다.
이 페이지에서는 관리 작업별로 절차를 설명합니다. 처음부터 연결을 설정하려면 시작하기로 돌아가세요. 분류하기 어려운 문제가 생기면 민감한 내용을 가린 오류 안내와 발생 절차를 먼저 저장한 뒤 문제 해결을 확인하세요. 문제 원인을 찾는 대신 항목을 일괄 삭제하지 마세요.