Shadowrocket 서버 관리

01Subscribe: 기존 구독 가져오기

구독 주소와 규칙 설정을 구분하세요

Subscribe는 이미 보유한 구독 주소에서 서버 정보를 가져오는 기능입니다. 하나의 구독에는 여러 서버 항목이 포함될 수 있으며, 가져오면 보통 출처별 그룹으로 정리됩니다. 이후 업데이트에도 원래 주소가 필요합니다. 서버 항목은 연결에 필요한 주소, 포트, 인증 정보를 저장하고, 구독은 해당 항목을 가져오는 경로를 저장합니다. 먼저 보유한 정보가 어느 쪽인지 확인한 뒤 가져오기 방법을 선택하세요. 웹 안내 페이지 주소를 구독 주소로 착각하지 않도록 주의해야 합니다.

Config에서 관리하는 설정 파일은 주로 규칙과 관련 설정을 담으며, 주소를 사용한다는 이유만으로 서버 구독과 같은 것으로 취급하면 안 됩니다. 일부 통합 설정에는 서버나 원격 리소스가 포함될 수도 있으므로 파일의 실제 용도를 확인하세요. 서버 구독 주소라면 Type이 Subscribe인 추가 방식을 선택하고, 규칙 설정 파일이라면 Config에서 용도를 확인하세요. 메뉴를 바꿔 가며 임의로 시도하지 마세요.

항목을 입력해 구독 가져오기

Home에서 추가 메뉴를 열고 Add Server로 이동한 다음, Type을 Subscribe로 설정하세요. 보유한 구독 주소를 입력하고 출처를 알아보기 쉬운 이름을 지정합니다. 화면 구성은 기기나 앱 업데이트에 따라 달라질 수 있으므로 Type과 항목 이름을 기준으로 메뉴를 찾으세요. 주소를 복사할 때는 전체 내용이 선택되었는지 확인하세요. 특히 채팅 앱의 줄바꿈, 끝에 붙은 문장 부호, 선택 범위 때문에 쿼리 매개변수가 잘리지 않도록 주의합니다. 화면에서 두 줄로 보인다고 실제 주소에 줄바꿈이 들어간 것은 아닐 수 있습니다.

저장한 뒤 구독 그룹이 나타나는지, 그룹 안에 서버 항목이 표시되는지 확인하세요. 가져오기 과정에서는 먼저 구독 주소에 접속해 응답 내용을 해석하므로, ‘주소가 저장됨’과 ‘서버를 가져옴’은 서로 다른 결과입니다. 그룹은 있지만 내용이 비어 있다면 업데이트 안내와 응답 내용을 확인하세요. 곧바로 서버 연결에 문제가 있다고 단정하지 마세요. 서버 인증과 연결 상태는 항목이 실제로 가져와진 뒤 별도로 확인해야 합니다.

1. 계정 페이지나 안내 페이지가 아닌 본인의 구독 주소를 복사했는지 확인하세요.
2. Subscribe를 선택하고 주소와 알아보기 쉬운 이름을 입력한 뒤 저장하세요.
3. 구독 그룹과 서버 항목이 생성되었는지 확인하고, 서버 하나의 설정을 점검하세요.
4. 서버를 선택한 다음 사용 튜토리얼에 따라 모드를 설정하고 실제 연결을 확인하세요.

가져오기에 문제가 있으면 가져오기, 해석, 연결을 나눠 확인하세요

구독을 가져오지 못했다면 먼저 현재 네트워크에서 주소에 접속할 수 있는지, 주소가 여전히 유효한지 확인하세요. 로그인 페이지, 인증 페이지, 오류 안내가 응답으로 돌아오는 경우에는 주소만 저장한다고 그 내용이 서버 목록으로 바뀌지 않습니다. 관련 없는 항목에 계정 비밀번호를 입력하지 말고, 테스트를 위해 구독 주소를 낯선 웹사이트에 제출하지 마세요. 구독 주소에는 접근 권한 정보가 포함될 수 있으므로 비공개로 관리하세요. 문제를 설명할 때는 오류 유형만 공유하고 전체 주소는 공개하지 마세요.

가져오기는 성공했지만 사용할 항목이 없다면 콘텐츠 형식과 온전성을 확인하세요. 주소의 접미사만 보고 판단하지 말고, 원래 안내를 참고해 Shadowrocket에서 지원하는 구독 콘텐츠인지 확인하세요. 일부 항목만 빠졌다면 전체 그룹을 지우지 말고 해당 항목의 프로토콜과 설정을 먼저 비교하세요. 필요하면 현재 사용 가능한 내용을 보존한 뒤 수동 업데이트를 한 번 진행하고, 전후 차이를 기록하세요. 연속으로 작업하면 처음 발생한 문제를 파악하기 어려울 수 있습니다.

가져온 뒤 Home으로 돌아가 현재 선택된 서버가 방금 가져온 그룹에 속하는지 확인하세요. 구독 내용을 살펴봤다고 해서 앱이 그중 한 항목을 자동으로 현재 연결 대상으로 선택하는 것은 아닙니다. 처음에는 확인된 서버 하나만 테스트해 주소, 모드, 인증 절차가 모두 올바른지 확인한 다음 그룹 전체를 정리하세요. 그러면 가져오기 실패, 잘못된 항목 선택, 연결 실패를 구분하기 쉽습니다.

02Add Server: 서버 설정 직접 입력

프로토콜에 맞는 항목 입력하기

Add Server는 서버 설정을 모두 보유하고 있거나 자동으로 가져온 서버의 세부 항목을 확인할 때 사용합니다. 먼저 Type을 선택한 다음 해당 유형에 표시되는 항목을 입력하세요. 한 프로토콜의 항목을 모두 입력한 뒤 Type 이름만 바꾸면 안 됩니다. 프로토콜마다 인증 방식과 전송 설정이 다르므로 Type을 바꾸면 새 항목이 나타나거나 기존 값의 재확인이 필요할 수 있습니다. 입력하기 전에 원본 정보를 보관해 대조하세요.

Address에는 보통 서버 도메인이나 IP 주소를 입력하고, Port에는 서버에서 실제로 연결을 수신하는 포트를 입력합니다. 도메인에 웹 페이지 경로를 임의로 추가하지 말고, TLS를 사용한다는 이유만으로 흔히 쓰이는 포트를 입력해서도 안 됩니다. 서버 주소, TLS의 Server Name, 전송 계층의 Host는 같을 수도 있고 각각 다른 용도로 쓰일 수도 있습니다. 원본 정보에 각각 따로 적혀 있다면 해당 항목에 맞춰 입력하고, ‘값을 통일한다’며 임의로 같은 이름을 넣지 마세요.

인증, TLS, 전송은 서로 다른 계층입니다

Shadowsocks에서는 서버 측과 같은 암호화 방식과 비밀번호를 사용해야 합니다. VMess와 VLESS는 일반적으로 UUID와 해당 설정에 필요한 추가 항목을 확인해야 하고, Trojan은 비밀번호와 TLS 관련 정보를 점검해야 합니다. 이 정보들은 서로 바꿔 쓸 수 없습니다. 화면에 저장되었다고 표시되는 것은 항목이 기본 입력 검사를 통과했다는 뜻일 뿐, 서버가 인증을 받아들인다는 보장은 아닙니다. 연결이 성립된 직후 끊긴다면 암호화나 전송 옵션을 임의로 바꾸기보다 원본 설정을 다시 대조하세요.

TLS는 프록시 프로토콜의 인증과 다른 역할을 합니다. Server Name은 보통 인증서 이름 확인과 서버 이름 표시 과정에 사용되므로 메모처럼 입력하면 안 됩니다. 인증서 오류가 발생하면 이름, 기기 시간, 원본 설정이 일치하는지 확인한 뒤 서버 인증서 상태를 점검하세요. 인증서 확인을 끄면 연결의 신뢰 범위가 달라지므로 일반적인 문제 해결 방법으로 사용해서는 안 됩니다. 원본에서 요구하지 않는 항목은 앱 기본값을 유지하거나 먼저 의미를 확인해 또 다른 문제가 생기지 않도록 하세요.

WebSocket 같은 전송 방식을 사용하는 경우 Host와 Path는 전송 설정의 일부입니다. Path의 슬래시, 대소문자, 쿼리 내용이 서버 라우팅에 영향을 줄 수 있으므로 일반 메모처럼 수정하면 안 됩니다. 원본 정보에 TLS, 전송 방식, 경로가 모두 있다면 각각 어떤 항목에 해당하는지 확인하세요. Hysteria2와 WireGuard 등은 각자 별도의 키나 연결 매개변수를 사용하므로 다른 프로토콜의 입력 절차를 적용할 수 없습니다. 해당 Type에서 실제로 요구하고 원본 정보에 명시된 값만 입력하세요.

저장한 뒤 확인하고 항목별로 테스트하세요

직접 입력한 항목에는 용도를 알아볼 수 있는 메모를 붙이세요. 예를 들어 ‘수동 테스트’처럼 지정하고 이름에 비밀번호나 전체 키를 넣지 마세요. 저장 후 편집 화면을 다시 열어 Type, 주소, 포트가 올바른지 확인하고, 복사한 내용 앞뒤에 공백이 들어가지 않았는지도 살펴보세요. 수정할 때는 한 번에 한 종류의 설정만 바꾸고 이유를 기록하세요. 포트, TLS, 전송 방식을 한꺼번에 바꾸면 연결이 성공해도 어떤 변경이 문제를 해결했는지 알기 어렵습니다.

자동으로 가져온 서버도 편집 화면에서 설정을 확인할 수 있지만, 구독 항목을 직접 수정한 내용은 이후 업데이트에서 덮어써질 수 있습니다. 로컬 변경을 장기간 유지해야 한다면 앱에서 독립 항목으로 복사할 수 있는지 먼저 확인하고, 이름으로 원본과 테스트 사본을 구분하세요. 확인하기 전에는 유일하게 사용할 수 있는 서버를 직접 수정하지 마세요. 기존 정보를 가져오는 다른 방법은 서버 추가를 위한 네 가지 가져오기 방법을 참고하세요.

03QR 코드 및 클립보드로 가져오기

QR 코드는 정보를 담는 방식일 뿐, 별도의 서버 설정 방식이 아닙니다

Scan QR Code는 QR 코드에 인코딩된 텍스트를 읽습니다. 서버 공유 링크일 수도 있고 구독 주소일 수도 있으며, 일반 웹 페이지 주소일 수도 있습니다. 스캔 후 인식 결과와 가져온 항목을 확인하세요. QR 코드가 인식되었다고 서버 설정까지 올바른 것은 아닙니다. QR 코드에 담긴 프로토콜, 주소, 인증 정보는 Add Server에서 직접 입력해 저장하는 항목과 대응합니다. 두 방식의 차이는 주로 입력 과정에 있으며 연결 원리는 같습니다.

스캔 전에 QR 코드가 본인이 보유한 서버나 구독 정보에서 나온 것인지 확인하고, 인증 정보가 포함된 화면을 공공장소에 표시하지 마세요. 카메라로 스캔할 때는 시스템 안내에 따라 필요한 권한을 허용하세요. 권한이 없으면 스캔 버튼을 반복해서 누르지 말고 시스템 설정에서 확인하세요. 앱에서 사진 보관함의 QR 코드를 읽을 수 있다면 저장된 이미지를 선택하되, 코드 전체가 선명하게 보이도록 하세요. 위치 표시를 자르거나 지나치게 압축된 미리보기 이미지를 사용하지 마세요.

QR 코드를 인식하지 못하면 먼저 읽기 환경을 개선하세요. 코드 전체가 보이고 밝기가 적당하며 반사나 흐림이 없는지 확인한 뒤 거리를 조정해 보세요. 같은 QR 코드가 계속 인식되지 않지만 원본 텍스트가 남아 있다면 텍스트로 가져오거나 항목을 직접 입력하세요. 스크린샷을 반복해서 만들면 정보가 더 손상될 수 있습니다. 여러 QR 코드가 한 이미지에 있다면 한 번에 하나씩 인식하세요. 가져온 뒤 이름과 출처를 확인해 중복 추가를 업데이트로 착각하지 않도록 하세요.

클립보드에서 가져오기 전에 복사 범위를 확인하세요

클립보드 가져오기는 완전한 서버 공유 텍스트를 보유한 경우에 적합합니다. 필요한 링크만 복사한 다음 Shadowrocket으로 돌아가 현재 화면에 있는 클립보드 가져오기 메뉴를 사용하세요. 시스템에서 붙여넣기 권한을 요청하면 실제 작업에 따라 허용하세요. 일반 안내 문구, 채팅에 붙은 따옴표, 링크 끝의 마침표는 프로토콜 내용이 아니며 함께 복사하면 인식에 영향을 줄 수 있습니다. 편하다는 이유로 채팅 전체를 복사하지 말고, 앱이 부가 설명까지 모두 자동으로 판별할 것이라고 기대하지 마세요.

여러 항목을 가져올 때는 원본 문자를 유지하고 링크를 한 줄에 하나씩 배치하세요. 화면에서 자동으로 줄이 바뀌어 보이는 것과 실제 줄바꿈은 다릅니다. 긴 링크가 화면에서 자동 줄바꿈되는 것은 대개 문제가 없지만, 직접 줄바꿈을 넣으면 하나의 항목이 둘로 나뉠 수 있습니다. 첫 번째 항목만 가져와진다면 나머지 항목도 지원되는 같은 형식인지, 항목 사이에 불필요한 구분자가 있는지 확인하세요. 실패하면 항목 하나씩 먼저 검증한 뒤 전체 내용을 처리하세요.

가져온 뒤 확인하는 절차도 빠뜨리지 마세요

QR 코드와 클립보드 중 어떤 방법을 사용했든 가져온 뒤 항목 하나의 편집 화면을 열어 Type, Address, Port, 필수 인증 항목을 원본과 대조하세요. 이름은 메모일 뿐 내용이 올바르다는 증거가 아닙니다. 이름이 같은 서버도 주소가 다를 수 있고, 이름이 달라도 같은 주소를 가리킬 수 있습니다. 인식 결과가 구독이라면 일회성 서버 목록만 생성된 것이 아니라 업데이트 가능한 출처 그룹이 만들어졌는지 확인하세요. 지속적으로 업데이트해야 하는 정보라면 구독 관계를 올바르게 유지해야 합니다.

가져오기가 끝나면 민감한 정보가 없는 일반 텍스트로 클립보드 내용을 바꿔 실수로 다시 붙여넣을 가능성을 줄일 수 있습니다. 다만 다른 기기나 기록에 복사본이 남아 있지 않다는 보장은 없습니다. 여러 기기에서 클립보드를 공유한다면 동기화 범위도 확인하세요. 사진 보관함에 저장한 QR 코드도 개인정보 관리 대상입니다. 특히 공개 공유 앨범에 포함되지 않도록 주의하세요. 스크린샷을 삭제하면 추가 확산을 줄일 수 있지만, 이미 노출된 인증 정보는 기존 관리 절차에 따라 처리해야 합니다.

이번 작업이 보유한 정보를 본인의 다른 기기로 옮기는 것뿐이라면, 새 기기에서 설정을 확인하고 연결을 테스트한 뒤 중간에 사용한 텍스트와 이미지를 정리하세요. 새 기기에서 사용할 수 있는지 확인하기 전에 기존 기기에 남은 유일한 기록을 삭제하지 마세요. 완전한 이전에는 Config, 현재 선택된 항목, On Demand 설정도 포함됩니다. ‘QR 가져오기 성공’만으로 이전이 끝났다고 판단할 수 없습니다. 구체적인 확인 순서는 삭제 및 백업을 참고하세요.

04공유 링크 형식과 설정의 범위

접두사를 먼저 확인하고 처리 방법을 판단하세요

서버 공유 링크에는 보통 프로토콜별 접두사가 사용되고, 구독 주소는 대개 HTTPS 주소입니다. 접두사는 콘텐츠 유형을 판단하는 단서일 뿐 링크 전체가 유효하다는 증거는 아닙니다. 올바른 접두사가 있어도 인증 정보, 포트, 필수 전송 설정이 빠져 있을 수 있습니다. 반대로 HTTPS 주소라고 해서 반드시 구독인 것도 아닙니다. 계정 페이지나 일반 파일을 가리킬 수 있습니다. 가져오기 전에 기존 안내를 참고해 서버, 서버 목록, 설정 파일 중 무엇을 나타내는지 확인하세요.

이러한 접두사는 흔한 콘텐츠 유형을 구분하기 위한 것이며, 전체 호환성 목록은 아닙니다. 프로토콜별 공유 형식에는 여러 방식이 있을 수 있고, 같은 프로토콜도 인코딩 방식이 다를 수 있습니다. 앱에서 가져올 수 있는지는 전체 콘텐츠와 현재 앱이 지원하는 매개변수 조합에 따라 달라지므로 프로토콜 이름만 보고 판단하면 안 됩니다. 익숙하지 않은 형식은 원문을 보존하고 기존 자료의 항목 설명을 확인한 뒤 Add Server에서 하나씩 대조하세요. 임의로 수정하면 원본과 비교하기 어려워집니다.

인코딩, 쿼리 매개변수, 메모는 각각 의미가 있습니다

공유 링크의 인증 정보는 인코딩된 형태로 저장될 수 있습니다. 인코딩은 암호화가 아니며 공개해도 안전하다는 뜻도 아닙니다. 링크를 읽을 수 있는 사람은 서버 인증 정보를 알아낼 수 있습니다. 읽기 어려운 문자열을 임의로 띄어 쓰거나 대소문자를 바꾸거나 끝 문자를 삭제하지 마세요. 일부 형식은 문자 하나에도 민감하며 텍스트 편집기의 자동 변환으로 내용이 달라질 수 있습니다. 비교가 필요하면 스크린샷을 보고 다시 입력하지 말고 원본 일반 텍스트를 사용하세요.

물음표 뒤의 쿼리 매개변수는 전송 방식, TLS 또는 다른 연결 동작을 결정할 수 있습니다. 해시 기호 뒤에는 보통 메모가 오지만, 구체적인 해석은 형식 규칙에 따라 다릅니다. 퍼센트 인코딩은 특정 특수 문자를 표현하는 방식이므로 깨진 문자처럼 보인다고 삭제하지 마세요. 한글 이름이 잘못 표시되면 먼저 문제가 메모에만 있는지 확인하세요. 주소와 인증 정보가 올바르다면 이름을 고치려고 인코딩된 링크 전체를 다시 편집하지 말고 가져온 뒤 표시 이름만 따로 수정하세요.

서버 정보를 가져와도 규칙 설정이 자동으로 끝나지는 않습니다

서버를 가져오면 주로 ‘어디에 연결하고 어떻게 인증할지’를 설정합니다. 규칙 설정은 ‘요청별로 어떤 정책을 적용할지’를 다룹니다. 두 요소는 함께 사용되지만 서로 대체할 수 없습니다. Config의 규칙은 보통 위에서 아래 순서로 일치 여부를 확인하고, 규칙에 맞으면 지정된 정책을 적용합니다. 앞선 규칙에 일치하지 않을 때는 FINAL이 사용됩니다. 다음은 규칙 구조를 이해하기 위한 예시입니다. 서버 인증 정보는 포함하지 않으며 기존 설정을 그대로 덮어쓸 수 있는 완전한 설정도 아닙니다.

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN-KEYWORD,ads,REJECT
DOMAIN,api.example.org,DIRECT
IP-CIDR,192.168.0.0/16,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXY

예시의 PROXY, DIRECT, REJECT는 정책 키워드입니다. DOMAIN-SUFFIX와 DOMAIN은 일치 범위가 다르므로 단어 모양만 보고 서로 바꾸면 안 됩니다. GEOIP는 IP 주소의 지역을 판단하는 방식으로, 웹 페이지 언어를 기준으로 분류하는 것과 다릅니다. 규칙은 Config의 올바른 구역에 입력하고 현재 Global Routing 선택과 함께 확인해야 합니다. Proxy 또는 Direct 모드를 사용 중이라면 Config의 특정 규칙 하나로 모든 접속 결과를 설명할 수 없습니다.

규칙을 더 자세히 조정하려면 규칙 매칭 순서, FINAL 및 정책 안내를 참고하세요. 이 장에서는 정보를 용도별로 나누어 관리하는 것이 중요합니다. 원본 공유 텍스트는 서버 설정 확인에, 구독 주소는 업데이트에, Config 파일은 규칙과 관련 설정에 사용됩니다. 세 종류의 자료에 각각 이름을 지정하면 하나의 ‘공용 링크’로 합치는 것보다 문제를 찾기 쉽고, 기기를 옮길 때 중요한 항목을 빠뜨릴 가능성도 줄어듭니다.

05구독 업데이트 방법과 결과 확인

업데이트는 시간 표시만이 아니라 원격 콘텐츠를 새로 가져옵니다

구독 업데이트는 저장된 주소에 다시 요청을 보내고 응답 내용에 따라 관련 서버 항목을 갱신합니다. 주소, 포트, 인증 정보, 이름이 바뀌거나 항목이 추가 또는 삭제될 수 있으므로 단순히 화면을 새로고침하는 기능으로 생각하면 안 됩니다. 업데이트 전에 사용 중인 그룹과 서버를 확인하고, 필요하다면 알아볼 수 있는 정보를 기록하세요. 연결 문제를 확인 중이라면 ‘업데이트를 눌렀다’고만 적기보다 전후 차이를 남기는 편이 유용합니다.

정보 변경 사실을 알았거나 기존 항목에 문제가 생겼거나 가져오기 결과를 확인해야 할 때는 수동 업데이트가 적합합니다. 자동 업데이트는 일상적인 관리에 활용할 수 있지만, 사용 여부와 업데이트 간격은 현재 Subscribe 설정 화면을 확인하세요. 모든 기기에서 백그라운드 요청이 정해진 시간에 정확히 완료된다고 가정하지 마세요. 시스템 스케줄, 네트워크 상태, 앱 실행 상태가 실행 시점에 영향을 줄 수 있습니다. 최신 결과를 확인하려면 해당 업데이트의 실제 결과를 살펴봐야 합니다.

요청, 해석, 교체의 세 단계로 결과를 확인하세요

요청에 실패했다면 먼저 주소가 완전한지, 접근 권한이 여전히 유효한지, 현재 네트워크에서 주소에 접속할 수 있는지 확인하세요. 서버 연결 실패와 구독 주소 접속 실패는 서로 다른 문제이며 같은 네트워크 경로를 사용하지 않을 수도 있습니다. 기존에 사용 가능한 서버가 있다면 보존하세요. 요청이 한 번 실패했다고 그룹을 삭제하고 다시 만들지 마세요. 그룹을 다시 만들어도 주소가 만료된 문제는 해결되지 않으며, 기존에 사용할 수 있었던 기록과 문제 해결 단서만 잃을 수 있습니다.

요청에 성공했더라도 응답 내용을 해석할 수 있는지 확인해야 합니다. 오류 페이지도 정상적인 웹 응답으로 돌아올 수 있지만 서버 목록은 아닙니다. 따라서 ‘주소를 열 수 있음’이 구독이 유효하다는 뜻은 아닙니다. 업데이트 뒤 그룹이 갑자기 비었거나 내용이 예상과 크게 다르면 연속으로 새로고침하지 말고 원래 주소와 용도를 다시 확인하세요. 응답 전체를 공개할 필요는 없습니다. 서버 콘텐츠인지, 웹 안내인지, 빈 응답인지 정도만 설명해 접근 정보를 보호하세요.

항목 교체가 끝나면 현재 선택된 항목을 다시 확인하세요. 항목 이름이 바뀌거나 삭제되었다면 이전 선택이 같은 서버를 가리킨다고 볼 수 없습니다. 이름이 같아도 내부 설정이 달라졌을 수 있습니다. 자주 사용하는 항목 하나의 주소와 프로토콜을 확인한 뒤 테스트와 실제 접속을 진행하세요. 한 항목만 비정상적으로 바뀌었다면 해당 항목에 집중하고, 그룹 전체에 문제가 있다면 구독 가져오기, 계정 상태, 공통 설정을 추가로 살펴보세요.

로컬 수정과 구독 관리는 분리하세요

구독 항목에서 직접 수정한 이름이나 연결 설정은 원격 콘텐츠에 덮어써질 수 있습니다. 실제 유지 여부는 업데이트 결과를 기준으로 확인하세요. 로컬 수정을 계속 보존해야 한다면 기억에만 의존하지 말고 수정한 항목과 이유를 기록해 로컬 예외임을 명확히 하세요. 앱에서 지원한다면 독립 사본을 만들어 테스트할 수 있지만, 구독 원본 항목과 이름을 구분해야 합니다. 그래야 다음 업데이트 뒤 테스트 사본을 잘못 선택하거나 오래된 설정을 최신 설정으로 착각하지 않습니다.

업데이트 빈도는 실제 변경 필요에 맞추세요. 짧은 시간 동안 요청을 반복해도 잘못된 콘텐츠가 정상으로 바뀌지는 않으며, 결과를 비교하기만 더 어려워질 수 있습니다. 업데이트가 실패하면 안내를 확인하고 네트워크와 주소를 점검한 다음 재시도 여부를 결정하세요. 문제를 살펴보려고 자동 업데이트를 잠시 끄는 경우에는 기록에 남기고 원인을 확인한 뒤 원래 설정으로 되돌리세요. 임시 문제 해결 설정이 계속 남으면 이후에도 콘텐츠가 정상적으로 갱신되고 있다고 오해할 수 있습니다.

업데이트된 서버 목록은 규칙 설정의 업데이트 기록이 아닙니다. Config가 별도의 원격 규칙이나 리소스를 참조한다면 각각 해당 메뉴에서 관리해야 합니다. Subscribe를 업데이트해도 해당 리소스까지 동기화되는 것은 아닙니다. 최종 점검은 서버 콘텐츠가 예상과 맞는지, 현재 선택된 항목이 유효한지, Global Routing과 설정이 사용 목적에 맞는지 확인하는 세 가지 단계로 진행하세요. 모두 확인해야 구독 관리 완료와 현재 연결 가능 상태를 정확히 구분할 수 있습니다.

06여러 구독 그룹과 이름 정리

출처별로 그룹화하고 용도에 맞게 이름을 지정하세요

여러 구독을 관리할 때는 먼저 출처별 구분을 명확하게 유지하세요. 각 구독에 알아보기 쉬운 이름을 지정해 어디에서 업데이트되는지 구분하고, 모든 서버를 출처 없는 하나의 목록으로 합치지 마세요. 이름에 기기 용도나 사용자 지정 분류를 포함할 수 있지만 비밀번호, 접근 토큰, 전체 구독 주소는 넣지 마세요. 좋은 출처 이름은 가져온 직후뿐 아니라 며칠이 지나도 관리 메뉴를 식별할 수 있어야 합니다.

서버 메모와 구독 이름은 용도가 다릅니다. 구독 이름은 콘텐츠 그룹의 업데이트 출처를 나타내고, 서버 메모는 개별 항목을 식별합니다. 예를 들어 사용자 지정 용도를 앞에 쓰고 원래 알아보기 쉬운 태그를 유지하는 식으로 간단하고 일관된 이름을 사용하세요. 네트워크 상태는 바뀔 수 있으므로 일시적인 테스트 결과를 계속 사용할 이름에 넣지 마세요. 원격에서 생성된 메모는 다음 업데이트 때 원래 이름으로 돌아갈 수 있으므로 로컬 이름만으로 항목을 구분하지 않는 것이 좋습니다.

중복 항목은 이름만 비교하지 말고 실제 설정을 확인하세요

이름이 같은 서버 두 개가 꼭 중복인 것은 아니며, 이름이 다르다고 연결 방식도 다른 것은 아닙니다. 정리 여부를 판단할 때는 프로토콜, 주소, 포트, 주요 전송 설정을 비교하되 인증 정보는 비공개로 유지하세요. 구독에서 가져온 항목과 직접 입력한 항목은 현재 설정이 같아도 관리 방식이 다릅니다. 구독 항목은 계속 업데이트될 수 있지만 직접 입력한 항목은 저장된 로컬 값을 유지합니다. 삭제하기 전에 어떤 이름을 남길지만 보지 말고 어떤 관리 관계를 유지할지 결정하세요.

오랫동안 사용하지 않은 그룹이 있다면 현재 선택된 항목이 포함되어 있는지, Config의 정책 그룹에서 이름으로 참조하는지 먼저 확인하세요. 이름 일치에 의존하는 설정은 이름을 바꾸거나 삭제하면 이후 선택에 영향을 줄 수 있습니다. 화면 목록의 정렬은 찾기 편하게 순서를 바꿀 뿐 규칙 우선순위를 바꾸지 않습니다. 위에서 아래로 적용되는 규칙 순서는 Config의 내용에 달려 있으며 Home에서 서버가 앞이나 뒤에 표시되는 것과는 별개의 개념입니다.

여러 기기를 정리할 때는 설명 가능한 상태를 유지하고 겉모습을 똑같이 만드는 데 집착하지 마세요

iPhone과 iPad에서 같은 정보를 관리한다면 기기 간 비교가 쉽도록 출처 이름을 통일할 수 있습니다. 다만 한 기기의 서버 목록, 선택 상태, Config가 다른 기기에 모두 자동으로 나타난다고 가정하지 마세요. 동기화 여부와 범위는 앱의 실제 설정을 기준으로 확인해야 합니다. 두 기기에 같은 이름이 표시되어도 가져온 내용과 현재 설정을 각각 확인하세요. 메모가 같다는 사실만으로 설정이나 연결 상태가 같다고 볼 수 없습니다.

구독 정리는 한 번에 적은 범위씩 진행하세요. 출처 하나를 먼저 정리하고 이름 지정, 중복 확인, 테스트, 백업을 마친 다음 다음 항목으로 넘어가세요. 여러 그룹을 한꺼번에 삭제하고 메모를 수정하면서 설정까지 바꾸면 이후 연결 문제의 시작점을 찾기 어렵습니다. 사용을 중단할 항목은 출처와 용도를 먼저 기록하고 현재 연결에 사용되지 않는지 확인한 뒤 삭제하세요. 잠시 사용하지 않는 항목과 완전히 폐기한 항목은 관리 기록에서 구분해야 합니다.

관리 기록에 모든 비밀 정보를 저장할 필요는 없습니다. 일반적으로 그룹 이름, 가져오기 방식, 설정 용도, 수정 이유, 테스트 결과를 기록하면 문제 해결에 충분합니다. 서버 인증 정보와 전체 구독 주소는 보호된 위치에 보관하고 공개 메모와 섞지 마세요. 다른 사람에게 문제를 설명할 때는 ‘구독을 업데이트한 뒤 이름이 같은 항목이 생김’ 또는 ‘직접 만든 사본은 연결됨’처럼 설명하고 전체 내보내기 파일을 보내지 마세요.

정리가 끝난 뒤에는 목록이 보기 좋은지만 확인하지 말고 실제 사용 상태를 점검하세요. 예상한 서버를 선택하고 Global Routing을 확인한 뒤 필요한 웹 페이지를 열고, 필요하면 연결 기록도 살펴보세요. 목록 정리 후 문제가 생기면 먼저 가장 최근 변경 사항을 되돌리세요. DNS나 전체 규칙부터 바꾸지 마세요. 각 관리 작업을 추적하고 검증할 수 있어야 일상적인 정리가 범위가 끝없이 커지는 연결 문제 해결로 번지지 않습니다.

07Connectivity Test, 지연 시간 및 정렬

테스트 결과는 실제로 측정한 항목만 알려줍니다

Connectivity Test는 서버 연결 상태를 판단하는 데 참고할 수 있지만, 현재 선택한 테스트 방식에 맞춰 결과를 해석해야 합니다. 방식에 따라 연결 성립 여부, 프록시를 통한 요청 처리 여부, 지정된 테스트 대상에 대한 접속 여부 등 서로 다른 계층을 확인할 수 있습니다. 테스트 항목과 옵션은 앱 화면에서 확인하세요. 표시된 시간이 의미하는 것은 해당 테스트가 필요한 과정을 완료했다는 것뿐입니다. 모든 웹사이트, 프로토콜, 지속적인 데이터 전송이 정상이라고 단정할 수 없습니다.

테스트 결과는 현재 네트워크, 대상 주소, 서버 상태, 측정 시점의 영향을 받습니다. 서버를 비교할 때는 가능한 한 테스트 방식과 네트워크 조건을 통일하고, 다른 기기나 시간, 테스트 대상에서 얻은 결과를 한데 섞어 정렬하지 마세요. 한 번의 이상 결과가 지속적인 장애를 의미하지는 않습니다. 잠시 후 다시 테스트하고 실제 사용 결과와 비교해 보세요. 반대로 한 번 성공했다고 자주 끊기는 문제가 없어지는 것도 아닙니다. 문제가 재현되는지 기록하세요.

연결, 인증, DNS, 규칙 순서로 원인을 확인하세요

기본 연결도 성립하지 않는다면 먼저 주소와 포트를 확인하고 현재 네트워크에서 서버에 접근할 수 있는지 점검하세요. 전송 연결은 성립하지만 프록시 요청이 실패하면 인증, TLS, 전송 설정을 확인합니다. 프록시 요청은 정상인데 일부 도메인이 열리지 않는다면 구독 전체를 바꾸기보다 DNS와 규칙을 확인하세요. 이런 순서로 점검하면 한 번에 한 계층씩 확인할 수 있어 서버 문제, 도메인 해석 문제, 라우팅 선택을 서로 혼동하지 않습니다.

테스트는 정상이지만 웹 페이지가 열리지 않는다면 실제 요청에 어떤 정책이 적용되는지 확인하세요. Global Routing이 Config이면 규칙이 위에서 아래로 적용되어 요청에 사용할 정책을 결정합니다. Proxy와 Direct는 전체 라우팅 방식을 지정하며, 서버 테스트 결과만으로 웹 요청의 경로를 알 수는 없습니다. 먼저 현재 모드를 확인한 다음 요청이 예상한 서버를 사용하는지 살펴보세요. 연결 기록이 있다면 도메인, 정책, 오류 내용을 함께 확인하고 지연 시간 하나만 보지 마세요.

정렬은 항목을 찾기 쉽게 할 뿐, 지속적인 품질 평가가 아닙니다

테스트 결과로 정렬하면 이번에 응답이 빨랐던 항목을 선택하기 편한 위치에 둘 수 있지만, 이를 안정적인 품질 순위로 해석해서는 안 됩니다. 응답 시간, 지속적인 처리량, 연결 안정성은 서로 다른 지표이며 적절한 테스트 대상도 다를 수 있습니다. 테스트에 실패한 항목은 설정 누락이나 일시적인 접속 불가 여부를 먼저 확인하세요. 곧바로 삭제할 필요는 없습니다. 구독 항목이라면 다음 업데이트에서 실제 연결 정보가 바뀔 수도 있습니다.

서버 항목 하나를 확인하려면 해당 항목을 선택한 뒤 실제 접속까지 완료하세요. 시스템 연결 상태를 확인하고 대상 웹 페이지를 연 다음 결과가 예상과 맞는지 살펴보세요. 일부 페이지만 문제가 있다면 접속되는 도메인과 접속되지 않는 도메인을 비교하고 서버와 모드는 그대로 유지하세요. 한 번에 조건 하나만 바꿔야 서버 변경이 효과가 있었는지, 규칙이나 DNS 또는 대상 차이가 원인이었는지 판단할 수 있습니다.

테스트 기록에는 필요한 조건을 함께 남기세요. 사용한 네트워크, 테스트 방식, 현재 서버, Global Routing, 재현 가능한 증상을 기록하면 됩니다. 오류 안내의 도메인과 매개변수에 비공개 정보가 포함될 수 있으므로 다른 사람에게 보여주기 전에 가리세요. 특정 대상 하나만 문제라면 전체 테스트 결과로 대신하지 말고 해당 대상을 직접 확인하세요. 네트워크 전체가 작동하지 않는다면 먼저 기기의 기본 인터넷 연결을 확인한 뒤 Shadowrocket의 서버와 설정을 점검하세요.

정렬한 뒤에도 현재 선택된 항목을 확인하세요. 목록 위치를 바꿨다고 앱이 첫 번째 항목으로 자동 전환되는 것은 아닙니다. 관리를 마칠 때 현재 상태를 명확히 기록하세요. 어떤 출처의 항목을 사용 중인지, 어떤 모드인지, 임시 변경을 되돌렸는지 확인합니다. 그래야 다음에 문제가 생겼을 때 이전 테스트에서 무엇이 바뀌었는지 추측하지 않고 확인된 조건에서 시작할 수 있습니다. 첫 연결의 전체 절차는 사용 튜토리얼을 기준으로 진행하세요.

08삭제, 백업 및 기기 변경 후 복원

삭제할 항목의 범위를 먼저 확인하세요

서버 하나, Subscribe 그룹 하나, Config 파일 하나를 삭제할 때의 영향 범위는 서로 다릅니다. 서버 항목은 특정 연결에, 구독 그룹은 콘텐츠 묶음과 업데이트 경로에, 설정 파일은 규칙과 관련 설정에 영향을 줍니다. 작업 전에 확인 메시지를 주의 깊게 읽고 현재 연결이 해당 항목에 의존하는지 판단하세요. 모두 삭제 버튼을 사용한다는 이유만으로 결과도 같다고 생각하면 안 됩니다. 특히 문제 해결 중에 규칙 설정까지 함께 삭제하지 않도록 주의하세요.

구독에 포함된 항목은 원격 목록에 남아 있으면 다음 업데이트에서 다시 나타날 수 있습니다. 독립적으로 저장한 로컬 항목은 같은 방식으로 복원되지 않습니다. 특정 항목을 계속 제외하려는 경우 반복해서 삭제하지 말고 앱에서 제공하는 필터링이나 관리 옵션을 먼저 확인하세요. 그룹을 삭제한 뒤 복원하려면 대체로 원래 구독 주소와 유효한 접근 권한이 필요합니다. 서버 이름만 기억해서는 원래 구독 관계 전체를 복원할 수 없습니다.

출처, 설정, Config별로 백업을 확인하세요

백업에는 실제로 복원해야 하는 항목이 포함되어야 합니다. 구독 주소는 서버를 다시 가져오는 데 필요하고, 독립 서버는 전체 설정을 보존해야 하며, Config는 관련 참조 자료와 함께 파일을 보관해야 합니다. 현재 선택된 항목, Global Routing, On Demand 등의 설정도 필요에 따라 기록하세요. 앱의 내보내기, 공유, 백업 기능이 어디까지 포함하는지는 현재 화면 안내와 내보낸 내용을 기준으로 확인해야 합니다. 어떤 기능이든 모든 상태를 포함한다고 가정하면 안 됩니다.

1. 보유한 구독 출처를 목록으로 정리하고 보호된 기록에서 원래 주소를 다시 찾을 수 있는지 확인하세요.
2. 직접 입력한 서버의 전체 설정을 별도로 보관했는지 확인하고 구독에서 가져온 사본과 구분하세요.
3. 이전할 Config를 저장하고 원격 리소스에 계속 접근할 수 있는지 확인하세요.
4. 현재 모드, 선택된 항목, 필요한 On Demand 설정을 기록하세요.
5. 새 기기에서 복원을 확인한 뒤 기존 기기와 임시 내보내기 자료를 정리할지 결정하세요.

내보낸 파일에는 비밀번호, UUID, 개인 키, 구독 접근 정보가 포함될 수 있습니다. 보호된 위치에 저장하고 접근 범위를 제한하세요. 공개 클라우드 링크, 그룹 채팅 파일, 공개 메모는 전체 연결 정보를 보관하기에 적합하지 않습니다. 시스템 파일 저장 공간이나 기기 백업을 사용하는 경우에도 계정과 기기의 접근 보호가 제대로 설정되어 있는지 확인하세요. 백업의 목적은 복원 가능성을 확보하는 것이지 파일을 여러 개 복사하는 것이 아닙니다. 여러 위치에 흩어져 최신본을 구분할 수 없는 파일은 오용과 유출 위험을 높입니다.

앱 복원과 연결 정보 복원은 별개의 작업입니다

기기를 바꾸거나 앱을 다시 설치했다면 App Store에서 구매한 Shadowrocket을 복원한 다음 구독과 설정을 복원하세요. 앱 구매 기록과 서버 정보는 서로 다른 항목이므로 앱을 다시 받았다고 모든 연결 정보까지 복원되는 것은 아닙니다. 구매 항목을 복원하고 다시 다운로드하는 방법은 구매 항목 복원 안내를 참고하세요. 운영체제 요구 사항, 구매 적용 여부, 호환성은 App Store 페이지에 표시된 내용을 기준으로 확인해야 하며 다른 기기의 상태만으로 판단해서는 안 됩니다.

새 기기에서 복원할 때는 먼저 출처 하나나 서버 하나를 가져와 설정을 확인하고 연결을 테스트한 뒤 나머지를 복원하세요. Config를 복원한 다음 현재 선택된 설정인지 확인하고, 규칙이 참조하는 이름과 리소스, 서버 관계가 여전히 유효한지 점검하세요. 기존 기기에서 로컬 예외 설정을 변경했다면 관리 기록을 기준으로 하나씩 복원하세요. 테스트 사본을 전부 가져온 뒤 어떤 것이 최종본인지 추측하지 마세요. 소량씩 복원하면 누락을 찾기 쉽습니다.

삭제하기 전에 복원과 검증을 먼저 마치세요

기기 이전 완료 여부는 가져온 항목 수가 같아 보이는지가 아니라 실제로 사용할 수 있는지를 기준으로 판단해야 합니다. 최소한 현재 서버에 연결할 수 있는지, 자주 사용하는 서비스에 접속되는지, Global Routing이 의도한 대로 설정되어 있는지 확인하고 On Demand도 사용 목적에 맞는지 살펴보세요. 새 기기에서는 연결 권한을 다시 승인해야 할 수 있으니 시스템 안내를 확인한 뒤 진행하세요. 검증을 마치기 전에 기존 기기에 있는 유일한 독립 설정을 삭제하지 말고, 스크린샷 속 이름을 백업으로 간주하지 마세요.

전체 구독 주소나 서버 인증 정보를 잘못 전송했다면 메시지나 로컬 파일을 삭제하는 것만으로 이미 전달된 사본을 무효화할 수 없습니다. 원래 계정이나 서버 관리 절차를 통해 해당 인증 정보를 처리하고 기기에 저장된 정보도 갱신한 뒤 연결을 다시 확인하세요. 필요한 변경 기록은 남기되 이전 비밀 정보는 문제 해결 메모에 계속 적지 마세요. 이후 백업도 다시 정리해 복원 과정에서 만료되었거나 노출된 정보가 다시 가져와지지 않도록 하세요.