Shadowrocket 구독 및 서버 관리 매뉴얼

01 / Subscribe

Subscribe 메뉴와 구독 처음 가져오기

구독, 서버, Config를 먼저 구분하기

구독은 서버 목록을 반복해서 가져올 수 있는 주소이고, 서버 항목은 실제 연결에 사용하는 매개변수 모음입니다. Config는 규칙, DNS 등의 설정을 관리합니다. 세 가지는 함께 사용할 수 있지만 같은 종류의 파일은 아닙니다. 구독을 추가해 서버가 여러 개 표시되어도 현재 Config가 바뀐 것은 아닙니다. Config를 가져와 규칙이 변경되어도 구독 주소가 저장된 것은 아닙니다. 시작하기 전에 받은 자료가 어떤 종류인지 확인하면 서버 입력란에 설정 주소를 넣거나 단일 공유 링크를 구독으로 착각하는 일을 막을 수 있습니다.

구독 링크에는 보통 접근 인증 정보가 포함되므로 전체 주소를 민감한 정보로 취급해야 합니다. 복사할 때는 원문만 선택하고 웹페이지 제목, 설명, 따옴표, 줄바꿈이 함께 포함되지 않도록 하세요. 채팅 기록으로 전달된 주소는 잘렸을 수 있습니다. 일부가 생략되어 보인다고 해서 직접 내용을 추측해 채우면 안 됩니다. 전체 주소인지 확신할 수 없다면 매개변수를 추측하며 반복해서 시도하지 말고 원본 링크를 다시 받으세요. 구독 주소는 이용 중인 서비스 제공업체에서 받아야 하며, 이후 절차는 주소를 이미 보유한 경우를 전제로 합니다.

Add Server에서 Subscribe 선택하기

Home으로 이동해 추가 메뉴를 열고, Add Server의 Type에서 Subscribe를 선택한 다음 전체 주소를 URL에 입력합니다. 구독 이름은 알아보기 쉽게 지정하세요. 이름은 로컬 관리용이며 원격 콘텐츠를 바꾸지 않습니다. 저장한 뒤 Home에 해당 구독 그룹과 서버 목록이 표시되는지 확인하세요. 그룹만 보이고 선택할 항목이 없다면 먼저 가져오기가 완료됐는지 확인한 다음, 반환된 내용을 해석할 수 있는지 살펴보세요. 확인 대신 같은 구독을 연달아 새로 만들지 마세요.

처음 가져올 때는 기존 서버와 설정을 그대로 보존하세요. 이미 사용할 수 있는 연결이 있다면 현재 선택 항목과 Global Routing 상태를 기록한 뒤 새 구독을 추가합니다. 저장이 완료되면 새로 가져온 서버 하나를 선택해 별도로 확인하고, 연결 및 웹페이지 접속이 예상대로 되는지 검증한 후 기존 데이터를 정리하세요. 이렇게 하면 새 주소에 문제가 있어도 가져오기, 규칙, 기기 네트워크가 동시에 바뀐 상태에서 문제를 찾을 필요 없이 원래 항목으로 돌아갈 수 있습니다.

결과별로 가져오기 문제 확인하기

저장 실패, 가져오기 실패, 목록 비어 있음은 각각 다르게 확인해야 합니다. 저장에 실패하면 URL 입력란이 완전한지, 공백이 섞이지 않았는지 확인하세요. 가져오기에 실패하면 기기의 현재 네트워크와 주소의 유효성을 확인합니다. 가져오기는 완료됐지만 항목이 없다면 서버가 반환한 콘텐츠 유형을 중점적으로 살펴보세요. 브라우저에 설명 페이지가 표시되는 주소가 클라이언트에서 필요한 구독 주소와 같은 것은 아닙니다. 로그인 페이지나 오류 안내가 나오면 페이지 내용을 URL에 다시 붙여 넣지 말고 주소의 용도를 확인하세요.

항목 수만 보고 가져오기가 제대로 됐다고 판단하지 마세요. 구독에는 프로토콜이나 용도가 서로 다른 항목, 이름이 비슷한 항목이 포함될 수 있으며, 일부 항목은 지원되지 않는 매개변수 때문에 사용할 수 없을 수 있습니다. 먼저 이름, 프로토콜 유형, 서버 주소, 포트가 받은 정보와 일치하는지 몇 개를 확인한 뒤 실제 연결을 테스트하세요. 모든 항목에서 같은 오류가 발생하면 공통된 출처와 가져오기 형식을 우선 점검하고, 하나만 실패한다면 해당 항목의 매개변수와 원격 상태를 확인하세요.

구독을 성공적으로 가져왔다는 것은 로컬 목록이 만들어졌다는 뜻일 뿐, 계정 상태와 원격 서비스, 실제 접속이 모두 확인됐다는 의미는 아닙니다. ‘주소에서 가져오기 가능’, ‘항목 해석 가능’, ‘서버 연결 가능’, ‘대상 웹사이트 접속 가능’을 구분하세요. 서비스 제공업체에 문의할 때 이 네 단계에 따라 상황을 설명하고 링크의 인증 정보는 가리면, 단순히 ‘구독이 안 된다’고 말하는 것보다 문제를 파악하기 쉽습니다.

02 / Add Server

Add Server 수동 입력 항목과 프로토콜 확인

Type을 먼저 정한 뒤 공통 항목 입력하기

수동 추가는 서버 매개변수 전체를 이미 보유했거나, 특정 항목을 확인해야 하거나, 별도의 테스트 복사본을 보관하려는 경우에 적합합니다. Add Server로 이동해 Type을 먼저 선택한 후 서버 주소, 포트, 인증 정보를 입력하세요. 프로토콜 유형에 따라 이후 입력 항목의 의미가 달라지므로, 한 프로토콜 기준으로 전부 입력한 다음 유형을 임의로 바꾸면 안 됩니다. 유형을 바꿨다면 인증 방식, 전송 계층, TLS 설정을 포함해 모든 옵션을 다시 확인하세요. 이전 값이 새 항목에 남아 혼선을 일으킬 수 있습니다.

서버 주소에는 호스트 이름이나 IP를 입력하고 웹페이지 경로와 쿼리 매개변수는 포함하지 마세요. 포트에는 해당 숫자만 입력하고 콜론이나 프로토콜 접두어를 붙이지 않습니다. 이름은 항목을 구분하기 위한 것으로 인증에 사용되지 않습니다. 이름에 특정 프로토콜이나 전송 방식이 적혀 있어도 해당 기능이 자동으로 활성화되지는 않습니다. 받은 정보가 이름, 주소, 포트뿐이고 선택한 프로토콜에 필요한 인증 항목이 없다면 다른 서버의 비밀번호를 복사해 넣지 말고 원래 매개변수를 확인하세요.

프로토콜 입력 항목은 서로 바꿔 쓸 수 있는 메모가 아닙니다

Shadowsocks는 암호화 방식과 비밀번호를 함께 사용해 인증하므로 한쪽만 바꾸면 연결에 실패할 수 있습니다. VMess와 VLESS는 모두 UUID를 사용하더라도 서로 다른 프로토콜이며, 이름만 바꾼다고 변환되지 않습니다. Trojan의 인증 정보도 다른 프로토콜의 입력값으로 추측할 수 없습니다. 서비스 제공업체가 안내한 전체 매개변수를 기준으로 입력하세요. 일부 항목이 제공되지 않았다면 기본값이 있는지 먼저 확인하고, 온라인의 다른 예시를 보고 그럴듯한 설정을 임의로 만들지 마세요.

TLS를 사용할 때는 ‘어디에 연결하는지’와 ‘어떤 이름을 확인하는지’를 구분해야 합니다. 연결 주소는 원격 서버를 찾는 데 사용되고, 서버 이름은 해당 TLS 핸드셰이크 및 인증서 확인에 사용됩니다. 실제 구성에 따라 두 값이 같을 수도, 다를 수도 있습니다. 인증서 오류가 발생하면 이름, 기기 시간, 원격 인증서 상태를 먼저 확인하세요. 확인 절차를 끄는 것을 일반적인 해결책으로 삼지 마세요. 전송 계층의 Host와 경로 등도 각각 해당 값에 맞춰야 하며 대소문자, 슬래시, 인코딩이 결과에 영향을 줄 수 있습니다.

저장 후 확인 및 수정 범위

저장한 뒤 항목을 다시 열어 Type, 주소, 포트, 인증, 전송 옵션이 모두 그대로 유지됐는지 확인한 다음 테스트하세요. 한 번에 한 종류의 매개변수만 바꾸고 변경 전 상태를 기록하는 것이 좋습니다. 예를 들어 먼저 포트를 바로잡아 테스트한 뒤 TLS를 확인하세요. 모든 항목을 한꺼번에 바꾸면 연결이 복구되더라도 실제 원인을 알기 어려워 같은 문제가 생겼을 때 처음부터 다시 확인해야 합니다.

구독에서 생성된 항목과 수동으로 추가한 항목은 관리 방식이 다릅니다. 구독 항목의 이름이나 매개변수를 직접 수정하면 다음 업데이트 때 새로 받은 내용으로 덮어쓰일 수 있습니다. 로컬 변경 사항을 계속 유지해야 한다면 앱에서 허용하는 경우 별도의 복사본을 만들고 수동 관리 항목임을 분명히 표시하세요. 복사본은 구독을 따라 자동 업데이트되지 않으므로 원격 매개변수가 바뀌면 직접 확인해야 합니다. 이 점을 이름과 백업 기록에 명확히 남겨 두세요.

WireGuard 등은 서로 연관된 매개변수가 여러 개 필요하므로 자료가 완전하지 않다면 일반 예시를 조합해 사용하지 않는 것이 좋습니다. 키와 인증 정보가 오류 화면, 공개 메모, 공유 이름에 노출되지 않도록 하세요. 입력 항목에 관해 문의할 때는 항목 이름, 입력 여부, 오류 상황만 설명하세요. 원래 값을 대조해야 한다면 본인과 서비스 제공업체 사이의 신뢰할 수 있는 경로를 사용하고, 공개 페이지에 전체 연결 정보를 올리지 마세요.

03 / Scan QR Code

QR 코드 및 클립보드 가져오기 확인 순서

QR 코드는 텍스트를 전달하는 또 하나의 방식입니다

Scan QR Code는 QR 코드에 인코딩된 텍스트를 읽을 뿐, 그 내용이 현재 용도에 적합한지 자동으로 판단하지 않습니다. QR 코드에는 단일 서버 공유 링크, 구독 주소, 일반 웹 주소가 들어 있을 수 있습니다. 스캔하기 전에 본인이 보유한 서버 자료에서 가져온 것인지 확인하세요. 스캔 후에는 서버 편집 화면, 구독 편집 화면, 기타 안내 중 어디로 이동했는지 살펴봅니다. 코드가 인식됐다고 해서 완전한 연결 매개변수가 포함된 것은 아닙니다.

카메라로 스캔할 때는 시스템 안내에 따라 필요한 권한을 허용하고, QR 코드 전체가 화면에 들어오도록 하세요. 가장자리가 잘리거나 빛이 강하게 반사되거나 화면이 깜박이지 않도록 합니다. 먼저 거리와 선명도를 조정하고 여러 설정을 계속 바꾸지는 마세요. 이미지에서 읽을 때는 선명한 원본 이미지를 사용하세요. 채팅 앱에서 압축된 작은 이미지는 복잡한 코드를 인식하지 못할 수 있습니다. 이미지를 열 수 있다고 해서 QR 코드의 세부 정보를 충분히 읽을 수 있다는 뜻은 아닙니다.

인식 후에도 저장 결과를 확인하세요

스캔에 성공하면 Type, 서버 주소, 포트, 이름이 타당한지 확인한 뒤 저장하고 Home으로 돌아가 항목이 실제로 표시되는지 확인하세요. QR 코드에 구독 주소가 들어 있다면 이름이 같은 서버 항목 하나만 생성된 것이 아니라 해당 그룹이 만들어졌는지 확인합니다. QR 코드 자체는 계속 업데이트되지 않습니다. 업데이트할 수 있는 것은 코드 안에 저장된 구독 주소입니다. 고정된 서버 매개변수를 담은 QR 코드는 원격 정보가 바뀌어도 로컬에 자동 반영되지 않습니다.

같은 QR 코드를 반복해서 스캔하면 항목이 중복될 수 있습니다. 첫 시도 후 결과가 바로 보이지 않으면 다시 시도하기 전에 목록으로 돌아가 관련 그룹을 펼치고 정렬 위치를 확인하세요. 새 항목이 목록 맨 위에 없다는 이유만으로 저장에 실패했다고 판단하지 마세요. 같은 이름의 서버가 이미 있다면 주소, 포트, 프로토콜을 비교하세요. 이름이 같아도 중복 항목일 수도, 서로 다른 항목일 수도 있으므로 매개변수로 확인해야 합니다.

클립보드 가져오기는 원래 형식을 유지하세요

보유한 자료에서 공유 링크를 복사한 뒤 클라이언트로 돌아와 실제 화면에 표시되는 클립보드 가져오기 메뉴를 사용하세요. 시스템에서 붙여넣기 권한을 묻는다면 이번 작업에 따라 허용 여부를 선택합니다. 클라이언트가 내용을 인식하지 못하면 먼저 전체 링크를 복사했는지, 웹페이지에 보이는 제목이나 축약된 표시 문구를 복사한 것은 아닌지 확인하세요. 인증 정보가 포함된 링크 중간에 공백을 직접 넣거나 읽기 쉽게 보이도록 줄을 바꾸지 마세요.

링크 여러 개를 한 번에 복사할 때는 원래의 줄 구분을 유지해야 합니다. 번호, 글머리 기호, 한국어 설명, 코드 블록 표시가 함께 복사되면 일부 내용을 인식하지 못할 수 있습니다. 먼저 한 개를 가져와 형식을 확인한 다음 화면에서 지원하는 방식으로 나머지를 처리하는 것이 안전합니다. 일부만 가져오는 데 성공했다면 성공 및 실패한 범위를 기록하고, 성공한 항목이 중복 추가되지 않도록 전체 텍스트를 반복해서 가져오지 마세요.

QR 코드 스캔 실패와 가져오기 실패는 확인할 부분이 다릅니다. 전자는 권한, 선명도, 코드의 온전한 상태를 먼저 살펴보고, 후자는 인식된 텍스트의 종류와 매개변수가 완전한지 확인하세요. 복사해서 가져오기는 되지만 QR 코드 읽기에 실패한다면 전달 매체의 품질이 원인일 가능성이 큽니다. 두 방식 모두 해석에 실패한다면 원본 자료에서 링크 형식을 확인해야 합니다. 전달 매체를 바꿔도 이미 누락된 문자는 복구되지 않습니다.

인증 정보가 여러 곳으로 퍼지지 않게 관리하기

QR 코드 이미지와 클립보드 텍스트에 전체 인증 정보가 포함될 수 있으므로 일반적인 안내 화면처럼 다루면 안 됩니다. 절차를 보여주기 위해 실제 QR 코드를 공개 앨범이나 게시판에 올리지 마세요. 가져오기를 마친 뒤 민감한 정보가 없는 일반 텍스트로 클립보드 내용을 바꾸고, 이미지도 본인의 자료 관리 방식에 따라 보관하거나 삭제하세요. 한 곳에서 지워도 다른 기기의 동기화 사본까지 삭제됐다고 단정할 수 없습니다. 실제로 사용하는 동기화 범위를 확인하세요.

가져오기 메뉴가 보이지 않으면 먼저 현재 페이지가 Home인지 확인한 다음 기기의 추가 메뉴를 살펴보세요. 다른 곳의 화면 캡처에서 본 버튼 위치를 그대로 찾으려 하지 마세요. 인식할 수 없는 내용은 확인을 위해 원본 사본을 보관하되, 인코딩을 계속 바꿔 가며 시도하지 마세요. 연결 과정을 처음부터 진행해야 한다면 빠른 시작 가이드로 돌아가세요. QR 코드는 정보를 입력하는 방법일 뿐이며, 이후에도 서버 선택, 상태 확인, 접속 검증이 필요합니다.

04 / URI & Config

공유 링크 형식과 Config의 차이

링크에 담긴 내용 확인하기

서버 공유 링크는 보통 프로토콜 식별자로 시작하며 연결 매개변수를 텍스트로 묶어 전달합니다. 구독 주소는 대개 접속 가능한 웹 주소이며, 응답 내용에 서버 목록이 포함됩니다. Config는 별도의 설정 자료이므로 확장자나 웹페이지 제목만 보고 용도를 판단할 수 없습니다. 원본 자료의 설명, 가져온 뒤 표시되는 화면, 최종적으로 생성된 데이터를 함께 확인하세요. 모두 링크라는 이유로 같은 입력란에 넣을 수 있다고 생각하면 안 됩니다.

일반적인 공유 형식은 인증 정보, 호스트, 포트, 전송 옵션, 이름을 각기 다른 위치에 담습니다. 일부 형식은 Base64 인코딩을 사용하고 일부는 URI 매개변수를 사용하며, 같은 프로토콜에도 여러 표현 방식이 있을 수 있습니다. 인코딩은 내용을 표현하는 방법이지 인증 정보를 안전하게 보호하는 수단이 아닙니다. 텍스트에서 비밀번호가 바로 보이지 않더라도 전체 링크는 민감한 자료로 보관하고 공개 예시나 오류 화면에 사용하지 마세요.

인코딩, 이름, 매개변수를 임의로 변경하지 마세요

링크의 퍼센트 인코딩은 특수 문자를 표현하며, 쿼리 매개변수의 구분 기호와 등호는 구조를 나타냅니다. 채팅 앱에서 자동으로 줄이 바뀌는 것은 화면 표시상의 줄바꿈일 수 있지만, 실제 줄바꿈을 직접 넣으면 링크가 끊길 수 있습니다. 주소에 모양이 비슷한 전각 문장부호를 넣거나 단순화한다며 쿼리 매개변수를 삭제하지 마세요. 메모 이름은 대개 화면 표시용이므로 이름을 바꿔도 인증이나 전송 오류가 해결되지는 않습니다.

복사한 링크를 가져올 수 없다면 원문과 비교해 시작과 끝, 문자 수, 따옴표 포함 여부를 먼저 확인한 다음 형식이 지원되는지 살펴보세요. 전체 링크를 먼저 디코딩해 수정하고 다시 인코딩하는 방식은 일반적인 해결 방법이 아닙니다. 인코딩 단계를 잘못 판단하면 문제가 더 생길 수 있습니다. 입력 항목을 확인해야 한다면 편집 화면으로 가져와 항목별로 살펴보세요. 전혀 해석되지 않는다면 서비스 제공업체에 형식과 완전성을 확인하고 인증 부분을 직접 조합하지 마세요.

Config는 규칙을 관리하며 서버 정보를 대신하지 않습니다

Config의 규칙은 어떤 요청이 어떤 정책에 해당하는지 지정합니다. 다음은 순서에 따른 매칭을 설명하는 문법 예시일 뿐이며 연결 가능한 서버 정보는 포함하지 않습니다. 사용 전에 기존 설정을 이해하고, 이 일부 내용을 파일 전체에 그대로 덮어쓰지 마세요. 규칙의 PROXY가 작동하려면 사용할 수 있는 서버나 정책 선택 항목이 있어야 합니다. 키워드를 적는 것만으로 연결이 생성되거나 가져오지 않은 인증 정보가 채워지지 않습니다.

[General]
bypass-system = true
dns-server = system

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

DOMAIN-SUFFIX는 도메인 접미사로, IP-CIDR은 주소 범위로 매칭하며, GEOIP는 해당 지역 데이터를 사용하고 FINAL은 앞선 규칙에 일치하지 않은 요청을 처리합니다. 규칙은 순서대로 확인되며 앞에서 일치한 결과에 따라 이후 규칙의 매칭 여부가 달라집니다. 이 예시의 지역 규칙은 문법을 보여주기 위한 것입니다. 현재 네트워크와 접속 목적에 적합한지는 실제 설정을 기준으로 판단하세요. 이 예시를 모든 사용자가 따라야 하는 고정 답안으로 여기지 마세요.

가져온 뒤 접속 경로가 예상과 다르면 구독이 잘못됐다고 판단하기 전에 Global Routing과 현재 Config를 확인하세요. 서버 목록이 올바르더라도 규칙이 대상을 DIRECT로 보낼 수 있고, 규칙이 올바르더라도 선택한 서버에 연결하지 못할 수 있습니다. 두 부분을 각각 확인해야 합니다. 세 가지 방식의 자세한 차이는 Global Routing의 Config, Proxy, Direct 안내에서 확인할 수 있습니다.

공유하기 전에 전달할 자료가 단일 서버인지, 전체 구독 주소인지, 설정 파일인지 먼저 확인하세요. 세 가지는 권한 범위와 이후 관리 책임이 서로 다릅니다. 규칙 일부를 전달하려고 모든 인증 정보를 함께 내보내지 말고, 규칙만 포함된 파일을 전체 복구 자료라고 설명하지 마세요. 자료의 종류를 명확히 표시해야 받는 사람이 어떤 메뉴를 사용하고 자신의 정보를 무엇을 추가해야 하는지 알 수 있습니다.

05 / Update

구독 업데이트 방식과 실패 시 확인 사항

업데이트는 다시 가져오는 작업이지 항목별 수정이 아닙니다

구독을 업데이트하면 저장된 주소에 다시 요청을 보내고 응답 내용에 따라 해당 서버 목록을 새로 고칩니다. 현재 선택한 서버 하나만 확인하는 작업도 아니고 앱 자체를 업데이트하는 작업도 아닙니다. 원격에서 이름, 매개변수, 순서, 항목 수를 바꿀 수 있으므로 업데이트 후 목록이 달라질 수 있습니다. 앱 업데이트는 App Store에서 관리하고 구독 목록 업데이트는 클라이언트 안에서 진행합니다. 두 작업은 해결하는 문제가 다르므로 혼동하지 마세요.

화면에서 제공하는 구독 메뉴로 업데이트하기 전에 대상이 특정 구독인지 전체 구독인지 확인하세요. 한 출처의 문제를 확인하는 중이라면 다른 그룹을 비교용으로 남겨두고 해당 구독만 업데이트하는 것이 좋습니다. 업데이트 시각, 전후 항목 변화, 표시된 오류를 기록하세요. 이는 작업 결과를 관찰하기 위한 정보이며 전체 주소를 공개할 필요는 없습니다. 업데이트 후에는 현재 선택한 항목이 여전히 있는지도 확인하세요.

수동 새로고침과 자동 업데이트의 역할 구분

처음 가져올 때, 원격 변경 안내를 받았을 때, 목록이 오래됐거나 오류를 확인해야 할 때는 수동 새로고침이 적합합니다. 이미 안정성을 확인했고 원격 목록을 계속 반영하려는 구독에는 자동 업데이트가 적합합니다. 구체적인 설정과 간격은 앱에서 실제로 제공되는 옵션을 따르세요. 간격이 짧을수록 좋은 것은 아닙니다. 자주 가져와도 유효하지 않은 주소가 고쳐지지 않으며 원격 요청이 늘어날 수 있습니다. 명확한 변경이 없다면 연결 유지를 위해 계속 새로고침할 필요는 없습니다.

기기 화면 잠금, 시스템의 백그라운드 작업 예약, 현재 네트워크, 앱 실행 상태에 따라 자동 업데이트 시점이 달라질 수 있습니다. 간격을 설정해도 매번 정확한 시각에 요청이 완료되는 것은 아닙니다. 목록이 바뀌지 않았다면 실제로 가져오기가 실행됐는지 확인한 다음 원격에서 새 내용을 반환했는지 살펴보세요. 필요하다면 앱을 전면에 둔 상태에서 한 번 수동 업데이트해 결과를 확인하세요. 자동 업데이트가 켜져 있다는 이유만으로 결론을 내리지 마세요.

요청, 응답, 해석 단계별로 확인하기

요청이 완료되지 않으면 먼저 기기 네트워크가 정상인지 확인한 다음 주소가 완전하고 유효한지 살펴보세요. 기존에 사용할 수 있는 항목을 먼저 삭제하거나 DNS, Global Routing, 구독 주소를 반복해서 바꾸지 마세요. 현재 설정을 보존한 상태에서 조건을 한 번에 하나씩 바꾸고 결과를 기록하세요. 한 네트워크에서는 실패하고 다른 네트워크에서는 성공한다면 범위를 좁히는 데 도움이 되지만, 오류 안내도 함께 확인해야 합니다. 이 결과만으로 원격 주소가 만료됐다고 단정하지 마세요.

명확한 HTTP 상태 오류가 표시되면 상태 코드와 발생 시각을 기록하세요. 인증 관련 응답은 주소의 인증 정보와 계정 권한을 확인해야 할 수 있고, 요청이 지나치게 잦다면 반복 재시도를 멈춰야 합니다. 원격 서비스 오류는 해당 서비스를 제공하는 측에서 확인해야 합니다. 상태 코드는 한 단계의 결과만 나타내므로 로컬 서버 매개변수가 잘못됐다는 사실을 단독으로 증명하지 않습니다. 문의할 때는 쿼리 매개변수의 민감한 내용을 가리고 오류 상황을 파악할 수 있는 정보만 남기세요.

요청은 성공했지만 해석에 실패한다면 응답이 로그인 페이지, 점검 안내, 빈 내용으로 바뀌지 않았는지 확인하세요. 주소가 열리더라도 응답이 서버 목록이라는 뜻은 아닙니다. 이름이 남아 있지만 항목이 비어 있다고 해서 모든 서버에 동시에 문제가 생긴 것도 아닙니다. 주소의 유효 기간이나 권한 범위가 바뀌었다면 서비스 제공업체의 최신 자료를 기준으로 확인하세요. 이전 페이지 본문을 복사하거나 인코딩을 수정해 형식 문제를 우회하지 마세요.

업데이트 후 확인 및 로컬 수정 사항

업데이트가 끝나면 최소한 현재 선택 항목, 프로토콜 유형, 실제 접속 한 곳을 확인하세요. 사용 중인 서버가 원격에서 제거됐다면 대체 항목을 직접 선택해야 합니다. 앱이 기존 이름으로 같은 항목을 찾아줄 것이라고 가정하지 마세요. 로컬 이름 변경이나 매개변수 수정이 덮어쓰였는지도 확인하세요. 계속 유지할 조정 사항은 수동 복사본에 명확히 표시해 보관하고, 구독을 따라 자동으로 바뀌지 않는 관리 범위를 고려해야 합니다.

한 번 실패했다고 모든 구독을 즉시 다시 만들 필요는 없습니다. 기존에 사용할 수 있는 목록은 보존하고 적절한 시간을 둔 뒤 다시 시도하면서 서비스 제공업체가 안내한 상태를 확인하세요. 구독 가져오기에만 실패하고 기존 서버는 연결할 수 있다면 두 결과를 따로 기록하세요. 목록 업데이트는 정상인데 연결에 실패하면 지연 시간 및 연결 확인을 살펴보세요. 가져오기와 사용을 나눠 설명하면 문제를 잘못된 단계에서 반복해서 조작하는 일을 줄일 수 있습니다.

06 / Groups

여러 구독의 그룹, 이름, 중복 항목 정리

관리 출처별로 그룹화한 다음 용도로 구분하기

여러 구독을 관리할 때는 목록을 짧게 만드는 것보다 ‘이 서버를 누가 업데이트하는가’를 먼저 명확히 해야 합니다. 각 구독을 별도 그룹으로 유지하고, 이름에는 본인이 알아볼 수 있는 용도나 자료명을 사용하되 인증 정보는 넣지 마세요. 수동으로 추가한 항목과 구독에서 생성된 항목도 구분할 수 있어야 합니다. 이렇게 하면 매개변수가 바뀌었을 때 특정 구독만 업데이트하거나 독립 항목만 수정할 수 있어 그룹 전체를 잘못 변경할 가능성이 줄어듭니다.

이름에는 일상 사용, 임시 확인, 수동 복사본처럼 변하지 않는 정보를 담으세요. 네트워크 결과는 바뀔 수 있으므로 한 번의 테스트 수치를 장기 이름에 넣지 않는 것이 좋습니다. 원격 서버 이름은 업데이트 후 원래 값으로 돌아갈 수 있습니다. 로컬 메모가 필요하다면 실제 화면에서 지원하는 메모 기능을 우선 사용하거나 별도의 관리 기록에 적으세요. 구독 내 수동 정렬을 유일한 용도 표시로 삼지 마세요.

이름만 비교해 중복 여부를 판단하지 마세요

이름이 같은 두 항목도 주소, 포트, 인증, 전송 설정이 다를 수 있습니다. 이름이 다른 두 항목이 실제로는 같은 연결 매개변수를 가리킬 수도 있습니다. 정리하기 전에 Type, 주소, 포트, 인증 방식, TLS와 전송 옵션을 대조하세요. 인증 정보가 서로 다른 항목은 같은 호스트에 연결되더라도 권한이 다를 수 있으므로 주소가 같다는 이유만으로 하나를 삭제하지 마세요.

중복 항목은 같은 QR 코드를 여러 번 스캔하거나 같은 공유 링크를 반복해서 붙여넣은 경우, 같은 구독을 중복 추가한 경우, 테스트용 수동 복사본을 만든 경우에 생길 수 있습니다. 처리 방법을 선택하기 전에 중복이 가져오기 작업에서 생겼는지 원격 목록에 원래 포함되어 있는지 확인하세요. 로컬에서 반복 추가한 항목은 정리할 수 있지만, 원격 구독 자체에 비슷한 항목이 포함됐다면 다음 업데이트 때 다시 나타날 수 있습니다. 이 경우 하나씩 삭제해도 장기적으로 유지되지 않습니다.

정렬은 현재 작업에 맞게 사용하기

정리할 때는 먼저 그룹을 유지한 상태에서 현재 범위의 이름이나 테스트 결과를 확인하세요. 지연 시간순 정렬은 이번 테스트 결과를 비교할 때, 이름순 정렬은 특정 항목을 찾을 때, 수동 정렬은 직접 관리하는 소규모 목록에 적합합니다. 정렬을 바꾼 뒤에는 현재 선택한 항목을 확인하세요. 목록의 ‘첫 번째 항목’만 기억하지 마세요. 원격 업데이트나 필터 변경으로 같은 위치가 다른 서버를 가리킬 수 있습니다.

목록이 길다면 현재 사용 중인 구독만 먼저 확인하고 나머지 그룹은 그대로 두세요. 한 그룹의 이름 지정, 확인, 검증을 마친 뒤 다음 그룹을 처리하면 일괄 정리로 모든 단서가 한꺼번에 바뀌는 일을 막을 수 있습니다. 화면에 검색이나 그룹 접기 기능이 있다면 확인 범위를 좁히는 데 사용하세요. 이런 작업은 대개 표시 방식만 바꾸며 항목을 삭제하지는 않습니다. 콘텐츠 제거 작업을 하기 전에 적용 범위를 확인하세요.

최소한의 관리 기록 남기기

구독 표시 이름, 자동 업데이트 여부, 수동 복사본 유무, 마지막 확인 결과를 기록하는 것이 좋습니다. 원래 자료를 어디서 확인할지 알 수 있도록 기록하면 되므로 인증 정보를 그대로 반복해 보관할 필요는 없습니다. 원본 주소를 저장해야 한다면 접근을 관리할 수 있는 개인 자료에 보관하고 일반 작업 기록과 분리하세요. 이름, 업데이트 시각, 테스트 수치는 원본 복구 자료를 대신할 수 없습니다.

정리하기 전에 Config가 서버 이름이나 정책 그룹으로 관련 항목을 참조하는지 확인하세요. 항목을 삭제하거나 이름을 바꾸면 기존 참조가 예상대로 작동하지 않을 수 있습니다. 특히 수동으로 관리하는 정책 선택을 주의하세요. 구독 그룹과 Config의 정책 그룹은 서로 다른 개념입니다. 전자는 출처별 관리에 사용되고 후자는 연결 정책을 결정합니다. 서버를 구독 그룹에 넣어도 규칙이 자동으로 그 서버를 사용하지 않으므로 현재 설정을 확인해야 합니다.

여러 항목을 삭제하기 전에 복구 가능한 자료를 보관하고 중복 여부를 확인한 항목 몇 개로 먼저 시험해 보세요. Home으로 돌아가 나머지 항목과 현재 선택을 확인한 다음 정리 범위를 넓힐지 결정합니다. 작업이 단일 항목에 적용되는지 전체 그룹에 적용되는지 화면에서 확인할 수 없다면 취소하세요. 정리의 목적은 혼란을 줄이는 것이지 출처를 추적할 수 없는 긴 서버 목록으로 모든 구독을 합치는 것이 아닙니다.

여러 구독을 정리하는 구체적인 순서는 여러 구독의 그룹화, 정렬 및 중복 항목 정리에서 확인할 수 있습니다. 정리 후에는 매일 사용할 경로 하나를 명확히 하고 원본 자료를 찾을 수 있는 기록을 남기세요. 고정된 목록 위치에 의존하는 것보다 이후 업데이트와 기기 교체 시 복구하기 쉽습니다.

07 / Connectivity Test

지연 시간 테스트, 정렬 및 실제 연결 확인

먼저 테스트 대상부터 확인하기

Connectivity Test는 선택한 테스트 방식에서 응답이 어떻게 나타나는지 확인합니다. 테스트 방식마다 확인하는 단계가 다릅니다. 일부는 주로 서버 연결 과정을 보여주고, 일부는 지정된 테스트 대상에 대한 요청까지 포함합니다. 결과는 현재 설정에 맞춰 해석해야 하며, 하나의 수치가 모든 웹사이트의 로딩 속도와 같다고 볼 수 없습니다. 테스트 대상, 기기 네트워크, 테스트 시각이 다르면 결과를 직접 비교하기도 어렵습니다.

테스트 전에 기기 자체가 정상적으로 인터넷에 연결되는지 확인하고 현재 연결 방식과 선택한 서버를 점검하세요. 여러 서버를 비교할 때는 같은 네트워크, 같은 테스트 방식, 같은 대상을 사용하고 가능한 한 비슷한 시간대에 테스트합니다. 네트워크를 바꾸면서 수치를 비교하거나 Wi-Fi에서 얻은 결과와 다른 네트워크의 결과를 섞어 안정성을 판단하지 마세요. 테스트 조건이 일정할수록 비교 결과의 의미가 커집니다.

수치, 시간 초과, 변동이 의미하는 것

수치가 낮으면 이번 테스트의 응답이 빨랐다는 뜻이지만 대용량 전송, 장시간 연결, 특정 앱에서도 더 낫다는 보장은 없습니다. 시간 초과는 이번 조건과 대기 시간 안에 테스트가 완료되지 않았다는 의미입니다. 서버, 테스트 대상, 이름 해석, 네트워크 경로가 원인일 수 있습니다. 일부 항목만 실패한다면 성공한 항목과 비교해 확인하고, 모두 실패한다면 서버 매개변수를 하나씩 다시 입력하기 전에 공통 조건부터 점검하세요.

한 번의 비정상 결과는 다시 테스트하되 짧은 간격으로 계속 반복할 필요는 없습니다. 일시적인 네트워크 혼잡, 기기 연결 전환, 원격 부하가 결과에 영향을 줄 수 있습니다. 조건이 안정된 뒤 다시 테스트해 결과가 계속 일관적인지 확인하세요. 일상적인 사용에서는 한 번 나온 최저 수치보다 실제 요청이 안정적으로 완료되는지가 더 유용한 기준입니다. 테스트 결과는 선택 기준 중 하나로 삼고 다른 항목을 자동으로 제외하는 유일한 기준으로 사용하지 마세요.

실제 접속을 단계별로 검증하기

서버를 선택한 뒤 연결 스위치를 켜고, 시스템 안내에 따라 VPN 구성 권한을 처리한 다음 익숙한 일반 웹페이지나 앱으로 접속을 확인하세요. 시스템에 연결됨으로 표시되어도 기기의 해당 연결 상태만 나타낼 뿐 원격 인증, 규칙 일치, 대상 응답까지 모두 정상이라는 뜻은 아닙니다. 클라이언트 연결 상태, 오류 안내, 실제 요청 결과를 각각 확인하세요. 스위치가 켜져 있다는 사실만으로 연결을 완전히 사용할 수 있다고 판단하지 마세요.

Global Routing이 Config인 경우 테스트 대상은 규칙에 따라 DIRECT로 연결될 수 있습니다. 따라서 ‘웹페이지가 열린다’는 사실만으로 선택한 서버가 요청을 처리하고 있다고 볼 수 없습니다. 현재 Config의 관련 규칙과 사용할 수 있는 연결 기록을 확인해 대상에 적용된 정책을 파악하세요. 비교를 위해 연결 방식을 잠시 바꿔야 한다면 먼저 원래 값을 기록하고 테스트 후 복원하세요. 한 가지 문제를 확인하려다가 원래의 라우팅 설정을 계속 바꾼 상태로 두지 마세요.

지연 시간 테스트는 정상인데 웹페이지가 열리지 않는다면 도메인 이름 해석, 서버 인증, 규칙에 따른 경로, 대상 사이트 응답을 각각 확인하세요. 같은 서버로 서로 다른 일반 사이트를 테스트하고 기기 네트워크와 비교하면서 범위를 좁힙니다. DNS 문제는 이름 해석 설정을 살펴봐야 하며 구독을 계속 새로고침해도 해결되지 않습니다. 지연 시간은 정상인데 웹페이지가 열리지 않을 때 DNS 확인 방법을 참고해 구독을 다시 만들거나 Config를 덮어쓰는 일을 피하세요.

정렬 후에도 선택 항목을 직접 확인하기

테스트 결과로 정렬하면 보는 순서만 바뀌며 실제 사용 서버가 반드시 바뀌는 것은 아닙니다. 정렬한 뒤 선택 표시가 어느 항목에 있는지 확인하고 연결하세요. 구독 업데이트, 그룹 전환, 재테스트에 따라 항목 위치가 바뀔 수 있으므로 서버를 ‘첫 번째’나 ‘세 번째’라고만 설명하지 마세요. 문제를 기록할 때는 민감한 정보를 가린 이름과 유형을 사용하면 위치보다 재현하기 쉽습니다.

특정 앱만 실패하면 전체 구독의 문제로 단정하지 말고 해당 앱 관련 규칙, 도메인, 연결 기록을 먼저 확인하세요. 특정 서버 하나만 실패한다면 해당 매개변수와 원격 상태를 살펴보세요. 비교 테스트에서는 한 번에 조건 하나만 바꾸고 시각, 테스트 방식, 오류 유형, 결과를 기록하세요. 이런 기록은 지속적인 오류와 일시적인 변동을 구분하고 이미 확인한 설정을 반복해서 수정하는 일을 줄이는 데 도움이 됩니다.

08 / Backup & Restore

삭제, 백업, 새 기기 복구 순서

삭제 대상과 영향 범위를 먼저 확인하기

서버 항목 하나 삭제, 구독 그룹 삭제, Config 삭제는 서로 다른 작업입니다. 구독에서 서버 항목 하나를 삭제해도 다음 업데이트 때 다시 나타날 수 있습니다. 구독을 삭제하면 목록을 다시 가져오는 데 필요한 주소가 로컬에서 사라질 수 있고, Config를 삭제하면 규칙과 관련 설정에 영향을 줍니다. 실행 전에 확인 안내를 읽고 대상과 범위를 명확히 하세요. 연결 문제를 해결하기 위해 목록부터 비우지 말고 원본 자료가 없을 때 여러 항목을 한꺼번에 삭제하지 마세요.

클라이언트에서 구독을 제거하는 것은 보통 로컬에 저장된 내용을 바꾸는 작업일 뿐 원격 접근 권한을 취소하는 것이 아닙니다. 실제 주소나 인증 정보가 유출됐다면 서비스 제공업체의 관리 방법을 통해 해당 정보를 폐기하거나 변경한 다음 로컬 기록을 업데이트하세요. QR 코드 이미지 하나, 서버 항목 하나, 내보낸 파일 하나만 삭제해도 다른 사람이 이미 얻은 인증 정보는 무효화되지 않습니다. 정보 유출 대응과 목록 정리는 별도로 처리해야 합니다.

서로 다른 종류의 데이터를 각각 백업하기

복구 자료는 최소한 구독 원본 주소, 수동 서버 매개변수, 현재 Config를 구분해야 합니다. 구독으로 당시 원격에서 제공한 목록을 다시 가져올 수는 있지만 이전에 직접 바꾼 이름과 매개변수까지 복원하지 못할 수 있습니다. 설정 파일에 규칙이 보관되어도 모든 서버나 구독 기록이 포함된 것은 아닙니다. 한 종류의 자료를 내보낸 뒤 실제로 무엇이 포함됐는지 확인하고 파일 이름만 보고 백업이 완전하다고 판단하지 마세요.

앱에서 제공하는 내보내기 또는 공유 메뉴로 자료를 저장할 때는 저장 위치와 접근 권한을 확인하세요. 인증 정보가 포함된 내보내기 파일은 본인이 관리하는 보호된 저장 공간에 보관하고 채팅 기록에 일반 첨부 파일로 장기간 남겨두지 마세요. 백업 이름에는 기기와 용도를 기록할 수 있지만 전체 비밀번호는 넣지 마세요. 저장한 뒤 파일을 열 수 있는지, 콘텐츠 유형이 맞는지 확인하고 복구 안내도 함께 보관하세요. 내용을 알 수 없는 파일 하나만 남기지 않도록 합니다.

기기를 바꿀 때는 먼저 앱을 복원한 뒤 자료를 복원하기

새 iPhone 또는 iPad에서 먼저 App Store를 통해 Shadowrocket을 받으세요. 구입 항목, 계정, 구매 적용 범위는 구입 항목 복원 안내를 확인하세요. 시스템 요구 사항은 App Store 페이지에 표시된 내용을 기준으로 확인해야 합니다. 구매 복원은 앱을 다시 받는 작업이며 로컬 서버 매개변수를 모두 자동으로 복원하지는 않습니다. 앱이 실행된 다음 보유한 백업에 따라 구독, 수동 항목, Config를 복원하세요. 세 가지가 반드시 함께 나타날 것이라고 가정하지 마세요.

앱에서 제공하는 iCloud 관련 동기화 기능을 사용한다면 두 기기에서 실제 동기화 범위와 완료 상태를 먼저 확인하세요. 시스템 계정에 로그인되어 있어도 앱 데이터가 모두 동기화됐다는 의미는 아닙니다. Config가 보인다고 해서 수동 서버 항목까지 모두 복원됐다고 판단할 수도 없습니다. 새 기기에서 확인을 마칠 때까지 기존 기기를 유지하세요. 출처와 내용이 일치하는지 확인하기 전에는 수동 가져오기와 동기화를 반복해 중복되거나 구분하기 어려운 복사본을 만들지 마세요.

새 기기에서 기존 구독을 복원해 목록을 가져온 다음 별도로 관리해야 하는 수동 항목을 복원하고, 이어서 Config를 가져와 선택한 뒤 Global Routing을 확인하는 것이 좋습니다. 설정에서 특정 이름이나 정책 그룹을 참조한다면 해당 항목이 실제로 있는지 확인하세요. 연결한 뒤 일반적인 웹 접속을 테스트하고 중요한 앱의 규칙 경로도 점검합니다. 복원 완료의 기준은 목록이 이전 기기와 비슷해 보이는지가 아니라, 기존 설정에 맞게 실제로 사용할 수 있는지입니다.

확인을 마친 뒤 이전 자료 정리하기

기기 이전 후에는 비교를 위해 이전 기기와 원본 백업을 먼저 보관하세요. 새 기기에서 구독 업데이트, 수동 항목 사용, 설정 적용이 정상인지 확인한 뒤 이전 자료의 처리 방법을 결정합니다. 이전 기기도 계속 사용할 예정이라면 정리 전에 동기화 삭제의 영향을 확인해 한 기기에서의 정리가 다른 기기까지 반영되지 않도록 하세요. 이전하는 동안 모든 항목의 이름 변경, 규칙 교체, 구독 주소 변경을 한꺼번에 진행하면 차이가 생긴 원인을 찾기 어렵습니다.

특히 구독 주소 변경, 인증 정보 수동 수정, Config 변경 후에는 백업이 현재 설정과 일치하는지 주기적으로 다시 확인하세요. 테스트할 때마다 복사본을 여러 개 보관할 필요는 없지만, 복구 가능한 기준 백업 하나와 필요한 변경 기록은 유지해야 합니다. 이전 인증 정보가 만료되면 관련 백업도 정리 대상에 포함하세요. 다음에 복구할 때 오래된 매개변수를 잘못 사용해 과거 문제가 다시 기기에 생기는 일을 막을 수 있습니다.

기기 이전 절차를 더 자세히 알아보려면 새 iPhone으로 설정 이전 및 기기 복원을 참고하세요. 연결 과정을 처음부터 다시 진행하려면 빠른 시작 가이드로 돌아가고, 구매 경로를 다시 확인하려면 정품 확인 3가지 항목을 살펴보세요. 자료 출처, 업데이트 대상, 실제 사용 여부를 확인하고 복원 가능한 개인 백업을 보관하면 관리 과정을 빠짐없이 마무리할 수 있습니다.