Shadowrocket 구독 및 서버 관리

01 · Subscribe 메뉴와 첫 가져오기

구독과 단일 서버를 구분하세요

Subscribe는 필요할 때 다시 요청할 수 있는 데이터 주소를 저장하고, Add Server는 직접 입력한 서버 정보를 저장합니다. 두 항목 모두 최종적으로 Home 목록에 서버로 표시될 수 있지만 관리 방법은 다릅니다. 구독 항목은 대개 구독 데이터에 따라 관리되고, 수동 입력 항목은 각 필드를 직접 수정해야 합니다. 시작하기 전에 보유한 정보의 종류를 확인하세요. 클라이언트가 읽고 주기적으로 업데이트하는 링크라면 Subscribe를 사용하고, 주소·포트·인증 정보와 프로토콜 매개변수만 있다면 다음 장의 Add Server를 사용하세요. 둘 다 목록에 표시된다는 이유로 서버 공유 링크를 구독 주소로 입력하지 마세요.

Shadowrocket의 Home에서 추가 메뉴를 열고 구독 추가에 사용하는 Subscribe 유형을 선택한 다음, 보유한 전체 링크를 해당 URL 필드에 입력하세요. 화면 상태에 따라 추가 메뉴의 위치와 필드 배열은 다를 수 있습니다. 입력란에 텍스트를 붙여 넣을 수 있는지만 보지 말고 유형이 Subscribe로 선택되어 있는지 확인하세요. 저장한 뒤 목록으로 돌아가 앱이 데이터를 가져와 파싱할 때까지 기다립니다. 처음 추가하기 전에는 원본 링크를 메모 앱에 임시로 복사해 앞뒤 문자가 빠지지 않았는지, 복사 과정에서 공백이나 줄바꿈이 포함되지 않았는지 확인할 수 있습니다.

저장에 성공해도 파싱에 성공한 것은 아닙니다

가져오기는 URL 저장, 네트워크를 통한 응답 수신, 응답을 Shadowrocket이 인식할 서버 항목으로 변환하는 세 단계 이상으로 이루어집니다. 목록에 구독 이름이 보인다는 사실은 첫 단계만 완료되었음을 뜻합니다. 이름은 있지만 서버가 비어 있다면 나머지 두 단계도 확인해야 합니다. 먼저 같은 네트워크에서 원본 링크가 여전히 유효한지 확인하고, 해당 링크가 로그인 페이지나 오류 페이지, 단일 공유 텍스트가 아니라 앱에 맞는 구독 데이터를 반환하는지 살펴보세요. 링크의 쿼리 매개변수를 임의로 수정하지 마세요. 매개변수도 데이터의 일부일 수 있으며, 한 글자만 지워도 다른 응답을 받을 수 있습니다.

추가 후 항목은 보이지만 이름을 구분하기 어렵다면 먼저 구독에 알아보기 쉬운 이름을 지정한 다음 목록 정렬을 검토하세요. 이름은 이 기기에서 항목을 구분하기 위한 관리용 표식일 뿐, 서버 주소를 수정하거나 서버 측 정보를 확인하는 일을 대신하지 않습니다. 처음 사용하는 경우에는 파악하고 있는 구독 하나만 먼저 가져오세요. 항목이 표시되는지, 출처를 구분할 수 있는지, 필요할 때 업데이트할 수 있는지 확인한 뒤 다음 구독을 추가하면 됩니다. 이렇게 하면 파싱에 실패했을 때 확인할 대상을 명확히 좁힐 수 있어 여러 출처나 중복 항목을 두고 추측할 필요가 없습니다.

구독 데이터는 원격에서 바뀔 수 있으므로 현재 표시된 서버 수를 영구적인 상태로 보면 안 됩니다. 다음 업데이트에서 항목이 추가되거나 사라지거나 이름이 바뀔 수 있습니다. 특정 주소를 별도로 장기간 관리하려면 먼저 원래 구독에서 관리되는 항목인지 확인한 뒤 수동 입력으로 추가할지 결정하세요. 앱 구매와 데이터 가져오기도 서로 다른 단계입니다. App Store에서는 앱을 구매하고, Subscribe에서는 이미 보유한 데이터를 읽어옵니다. 앱의 정체를 먼저 확인하려면 정품 확인을 위한 세 가지 항목에서 개발자, 아이콘, 앱 ID를 확인하세요.

02 · Add Server 필드 직접 입력

보유한 정보에 맞는 프로토콜을 선택하세요

단일 서버 정보를 보유한 경우 Home의 추가 메뉴에서 Add Server를 선택하고, 제공된 정보에 명시된 프로토콜에 맞춰 입력하세요. 프로토콜은 같은 숫자에 다른 이름표를 붙이는 것과 다릅니다. Shadowsocks, VMess, VLESS, Trojan, HTTP, SOCKS5, WireGuard, Hysteria2는 필드 구성과 인증 방식, 전송 요구 사항이 서로 다릅니다. 정보에 프로토콜이 적혀 있지 않다면 제공자에게 확인하세요. 주소나 포트만으로는 정확히 추정하기 어렵습니다. 비밀번호, 식별자, 호스트 이름, 경로와 같은 값은 대소문자와 문장부호, 특수문자를 원본 그대로 입력하세요. 보기 좋게 정리한다며 임의로 바꾸지 마세요.

Address에는 서버의 도메인이나 IP를, Port에는 해당 서비스의 포트를 입력합니다. 두 항목을 한 쌍으로 확인하세요. 일반적으로 주소 필드에 웹 경로를 덧붙일 필요는 없으며, 포트 필드에 프로토콜 접두사를 입력하지 않습니다. 완전한 구조를 갖춘 공유 링크라면 뒤에서 설명하는 링크 가져오기를 이용할 수 있는지 먼저 확인하세요. 인코딩된 텍스트에서 필드를 직접 추측하지 않아도 됩니다. 입력을 마치면 저장한 뒤 목록으로 돌아가 예상한 위치에 기록되었는지 확인하세요. 저장은 입력값을 기록할 수 있다는 뜻일 뿐 서버가 연결을 받아들인다는 보장은 아닙니다.

인증, TLS 및 전송 매개변수

인증 필드는 프로토콜에 따라 다릅니다. Shadowsocks에는 해당 암호화 방식과 비밀번호가 필요하고, VMess와 VLESS에서는 식별자와 전송 옵션을 자주 사용합니다. Trojan은 비밀번호와 TLS 설정이 중요하고, WireGuard는 Interface와 Peer 정보를 한 묶음으로 입력합니다. TLS를 사용하는 경우 SNI의 서버 이름이 Address와 다를 수 있으므로 임의로 바꿔 입력하지 마세요. Allow Insecure는 인증서 검증과 관련된 옵션입니다. 먼저 인증서 이름과 유효 기간, 입력 정보를 확인하고, 연결 실패를 해결하기 위해 검증 방식을 바꾸는 것을 첫 단계로 삼지 마세요.

필드가 많다면 두 차례에 나눠 확인하세요. 첫 번째로 프로토콜, 주소, 포트와 인증 정보가 원본과 한 글자씩 일치하는지 살펴보고, 두 번째로 TLS, 전송 설정과 추가 옵션을 확인합니다. 이렇게 하면 기본 필드 오류와 고급 설정 불일치를 구분할 수 있습니다. 여러 필드를 연달아 수정한 뒤 바로 테스트하지 마세요. 결과가 달라져도 어느 항목이 영향을 미쳤는지 알기 어렵습니다. 키가 포함된 설정은 전체 정보를 공개 게시판에 올리지 마세요. 문제를 설명할 때는 필드 유형과 오류 위치, 발생한 현상만 공유하면 됩니다.

목록에 구독에서 생성된 항목과 수동 입력 항목이 함께 있다면 수동 입력 항목의 용도를 표시해 두세요. 구독을 업데이트해도 수동 입력 정보는 자동으로 수정되지 않습니다. 서버 매개변수가 바뀌면 해당 항목을 다시 편집해야 합니다. 반대로 수동 입력 방식을 구독에서 생성된 항목에 그대로 적용하지 마세요. 구독 항목의 필드는 다음 업데이트에서 구독 데이터에 따라 다시 입력될 수 있습니다. Trojan 매개변수와 WireGuard의 정보 입력 방식은 각각 Trojan 필드 안내와 WireGuard 매개변수 가이드를 참고하세요.

03 · Scan QR Code 및 클립보드로 가져오기

QR 코드를 스캔하기 전에 내용을 확인하세요

QR 코드를 스캔하면 필드를 하나씩 입력하지 않아도 되지만, QR 코드는 텍스트를 전달하는 또 다른 방식일 뿐입니다. 먼저 QR 코드에 단일 서버 공유 링크, 구독 URL 또는 다른 텍스트 중 무엇이 담겼는지 확인한 뒤 가져온 결과를 예상하세요. 정보가 QR 코드로 제공되었다면 추가 메뉴에서 Scan QR Code를 선택하고 카메라 권한을 허용한 다음, 코드 전체가 화면에 들어오도록 비춘 뒤 인식 결과가 나타나면 프로토콜과 주요 필드를 확인하세요. 코드가 흐리거나 가려져 있거나 배경과의 대비가 낮다면 제공자에게 원본을 선명하게 다시 보여 달라고 요청하세요. QR 코드 옆의 설명만 보고 주소를 임의로 조합하지 마세요.

QR 코드를 스캔한 직후 새 항목을 현재 연결에 바로 사용하지 마세요. 가져온 유형, 이름, Address와 Port가 예상한 내용과 일치하는지 먼저 확인하세요. Subscribe를 가져온 경우에는 고정 서버 항목이 아니라 업데이트할 수 있는 구독 항목으로 추가되었는지 살펴봅니다. 앱에서 텍스트를 인식할 수 없다고 표시된다면 카메라 권한뿐 아니라 QR 코드에 담긴 내용에도 원인이 있을 수 있습니다. 이미 이 기기에 저장한 이미지라면 먼저 내용을 읽을 수 있는지 확인한 뒤 실제 인터페이스에서 제공하는 인식 기능을 사용하세요. 브라우저에 보이는 축소 이미지를 원본 전체로 간주하지 마세요.

클립보드에서 가져올 때 앞뒤 문자를 확인하세요

클립보드 가져오기는 완전한 공유 텍스트를 보유한 경우에 적합합니다. 복사할 때는 프로토콜 접두사부터 텍스트의 마지막 문자까지 선택하고, 대화 기록의 따옴표나 번호, 설명 문구는 포함하지 마세요. Shadowrocket으로 돌아가 추가 메뉴에서 클립보드 가져오기를 선택하고 미리보기 내용을 확인합니다. 시스템에서 클립보드 접근 권한을 요청하면 방금 복사한 내용을 읽기 위한 시스템 확인 절차입니다. 직접 가져오기를 시작했는지 확인한 뒤 허용 여부를 결정하세요. 붙여 넣은 뒤 빈 항목이 생긴다면 원본 정보로 돌아가 클립보드에 링크가 실제로 저장되어 있는지 확인하세요.

QR 코드와 클립보드는 입력 수단일 뿐 정보의 진위나 유효 기간을 확인해 주지 않습니다. 같은 코드를 반복해서 스캔하거나 같은 텍스트를 여러 번 붙여 넣으면 목록에 구분하기 어려운 중복 항목이 생길 수 있습니다. 가져오기 전에 기존 이름을 검색하고, 가져온 뒤에는 프로토콜, 주소, 포트 등의 필드를 비교하세요. 텍스트에 인증 정보가 있다면 공용 기기의 다른 입력란에 반복해서 붙여 넣지 마세요. 작업을 마친 뒤에는 개인정보 보호 습관에 따라 클립보드 내용을 일반 텍스트로 덮어쓸 수 있지만, 원본 정보를 보관한 유일한 위치까지 삭제하지 않도록 주의하세요.

QR 코드는 인식되지만 연결되지 않는다면 두 단계를 나눠 확인하세요. 인식에 성공했다는 것은 앱이 텍스트를 읽었다는 뜻이지, 포트가 열려 있거나 인증이 올바르거나 서버에 도달할 수 있다는 뜻은 아닙니다. 먼저 가져온 필드를 확인한 뒤 다음 장의 Connectivity Test로 원인을 좁혀 보세요. 다른 기기에서도 같은 정보가 필요하다면 목록의 스크린샷에서 가려진 필드를 다시 손으로 입력하지 말고, 직접 보관한 원본 정보를 사용하세요. 기기 간에 옮길 때는 구독 URL 전체가 온전한지 특히 주의해야 합니다. 일부 화면에는 읽기 편하도록 잘린 텍스트만 표시될 수 있으므로 이를 백업으로 사용하지 마세요.

04 · 공유 링크와 구성 형식 구분하기

접두사와 데이터 용도를 먼저 확인하세요

공유 링크는 보통 프로토콜 식별자로 시작하며, 뒤에 주소와 인증 정보, 기타 매개변수가 인코딩되어 있습니다. 구독 링크는 일반적으로 클라이언트가 데이터를 요청하는 URL입니다. 두 텍스트 모두 복사할 수 있으므로 붙여 넣을 수 있는지 여부로 구분할 수 없습니다. 먼저 텍스트의 시작 부분을 확인하고, 단일 서버로 가져와야 하는지 Subscribe로 추가해야 하는지 정보에 적힌 용도를 살펴보세요. 공유 텍스트의 본문이 인코딩되어 주소가 눈에 보이지 않을 수도 있습니다. 주소가 없다고 단정하지 말고 Shadowrocket의 알맞은 가져오기 기능으로 파싱하세요. 인코딩을 직접 풀어 필드를 추측하지 마세요.

구조를 보여 주기 위한 아래의 example.com과 your-password는 가상의 값이며, 연결 가능한 서버를 나타내지 않습니다. 예시는 단일 공유 텍스트와 구독 URL의 형식이 어떻게 다른지 설명하기 위한 것이므로 실제 항목으로 저장하지 마세요. 실제 정보에 포함된 프로토콜 접두사, 이스케이프 문자, 쿼리 매개변수와 프래그먼트 표시는 모두 함께 보존해야 합니다. 각 부분이 전송 옵션이나 표시 이름을 담고 있을 수 있어 일부만 복사하면 원본과 다른 결과가 나올 수 있습니다.

trojan://[email protected]:443?sni=example.com#Example
https://example.com/sub?token=xxxx

Config 파일과 서버 공유 텍스트

Config 파일에는 특정 서버뿐 아니라 규칙, DNS, 정책 등의 설정이 포함될 수 있습니다. 단일 공유 링크와는 관리 범위가 다릅니다. Config를 가져온 뒤에는 규칙이 참조하는 정책이 현재 구성에 존재하는지 확인하세요. 서버 항목이 목록에 보인다고 모든 규칙이 올바르게 연결되었다고 단정할 수 없습니다. 아래 내용은 규칙 문법과 쉼표 구분을 보여 주는 예시입니다. PROXY와 DIRECT는 정책 키워드이지 서버 주소가 아닙니다. 규칙은 구성과 매칭 로직에 따라 적용되므로 실제 사용 전에 현재 Config를 함께 확인해야 합니다.

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
GEOIP,CN,DIRECT
FINAL,PROXY

전체 구성 파일을 받았다면 서버처럼 보이는 한 줄만 떼어 구독 URL로 사용하지 마세요. Config의 규칙 부분과 서버 부분은 각각 역할이 다르므로 문맥을 잘라 내면 정책 참조가 연결되지 않을 수 있습니다. 서버 정보는 있지만 언제 사용되는지 모르겠다면 Global Routing에서 Config, Proxy, Direct의 동작을 비교해 보세요. Config는 구성 규칙에 따라 처리하고, Proxy는 현재 연결 조건에 맞는 요청을 프록시로 보내며, Direct는 직접 연결합니다. 모드를 바꾸는 것은 문제 위치를 살펴보는 방법일 뿐 공유 링크의 매개변수 오류를 해결해 주지는 않습니다.

가져오기에 실패하면 먼저 문제를 ‘텍스트가 불완전함’, ‘선택한 메뉴와 형식이 맞지 않음’, ‘읽은 데이터가 예상과 다름’ 중 어디에 해당하는지 확인하세요. 텍스트가 불완전하다면 원본을 다시 확보하고, 메뉴가 맞지 않는다면 정보의 용도를 다시 판단하세요. 읽기는 완료했지만 연결할 수 없다면 인증 정보와 네트워크를 확인합니다. 실제 비밀번호나 키, 구독 매개변수가 포함된 전체 링크를 공개 페이지에 올리지 마세요. 문제를 설명할 때는 서버 주소를 example.com으로 바꾸고 민감한 필드를 가상 값으로 대체하되, 형식을 설명할 수 있도록 프로토콜 이름과 필드 위치는 남겨 두세요.

05 · Subscribe 업데이트 설정 및 문제 해결

수동 업데이트와 자동 업데이트 구분하기

구독은 한 번 가져오면 계속 변하지 않는 로컬 목록이 아닙니다. 수동 업데이트는 최신 데이터를 확인하고 싶을 때 직접 가져오기를 시작하는 방식이고, 자동 업데이트는 설정에 따라 적절한 시점에 데이터를 가져오도록 시도하는 방식입니다. 사용 빈도와 데이터 변경 상황에 맞춰 선택하세요. 업데이트 간격을 짧게 한다고 더 좋은 것은 아닙니다. 자주 요청해도 잘못된 링크가 올바르게 바뀌지는 않으며, 원격 데이터가 매번 달라진다는 보장도 없습니다. 문제를 확인 중이라면 자동 업데이트를 기다리기보다 수동 업데이트를 한 번 실행하고 전후 목록의 차이를 기록하는 편이 원인을 파악하기 쉽습니다.

확인할 때는 ‘구독 상태’와 ‘항목 상태’를 나눠 보세요. 구독 상태에서는 URL 전체가 온전한지, 요청이 성공했는지, 파싱이 가능한지 확인합니다. 항목 상태에서는 업데이트 후 이름과 수량, 필요한 필드가 보유한 정보와 일치하는지 살펴봅니다. 업데이트 실패 알림이 떠도 기존 항목이 Home에 남아 있을 수 있습니다. 이때 화면에 보이는 항목이 이전에 저장한 데이터일 수 있으므로 새 데이터를 가져왔다고 판단하지 마세요. 먼저 실패 알림을 확인한 뒤 현재 네트워크와 원본 URL을 살펴보세요. 기존 항목이 보인다는 이유로 업데이트 결과를 무시하지 마세요.

목록이 비거나 줄거나 중복될 때

목록이 비었다면 업데이트를 연속으로 다시 누르지 마세요. 올바른 Subscribe 항목을 선택했는지 확인하고 링크의 시작 부분과 쿼리, 끝 부분을 다시 살펴보세요. 반환된 내용이 설명문이 아니라 파싱 가능한 데이터인지도 확인해야 합니다. 목록이 줄었다고 해서 앱이 잘못 삭제한 것은 아닙니다. 원격 데이터가 바뀌었을 수도 있습니다. 현재 결과를 보관해 둔 이전 목록과 비교해 어떤 이름이 사라졌는지 확인하고 원본 정보를 살펴보세요. 업데이트 후 중복 항목이 생겼다면 같은 URL을 두 번 가져왔는지, 수동 입력 항목과 구독 항목을 함께 보유하고 있는지 확인하세요.

구독 URL을 수정하려면 기존 Subscribe를 편집할지 새 항목을 만들지 먼저 결정하세요. 편집하면 기존 관리 위치를 유지할 수 있지만, 붙여 넣기 오류가 생겼을 때 복구할 수 있도록 수정 전에 이전 링크 전체를 저장해 두세요. 새 항목을 만들면 서로 다른 두 URL을 나란히 비교할 수 있지만 목록이 중복될 수 있습니다. 비교가 필요한지에 따라 선택하되, 문제를 확인하는 중에 정상 작동하는 유일한 기존 항목까지 삭제하지 마세요. 업데이트 실패가 항상 프로토콜 필드 문제인 것은 아닙니다. 데이터를 가져오기 전에 DNS, 네트워크 상태와 URL 응답이 영향을 줄 수도 있습니다.

특정 구독만 반복해서 실패하고 같은 기기의 다른 구독은 업데이트된다면 해당 URL과 반환 데이터를 먼저 확인하세요. 여러 구독이 동시에 실패한다면 개별 링크 문제로 단정하기 전에 현재 네트워크 상태를 확인하고 각 구독을 한 번씩 수동 업데이트해 보세요. 링크 형식과 인코딩, 업데이트 시점을 단계별로 확인하려면 구독 가져오기 실패 또는 서버 목록이 비어 있을 때를 참고하세요. 문제를 해결한 뒤 자동 업데이트 방식을 정하고 결과를 주기적으로 확인하세요. 자동 설정만으로 실제 목록의 내용을 확인할 수는 없습니다.

06 · 여러 구독과 수동 입력 항목 정리

관리 목적이 드러나도록 이름 지정하기

Home에 여러 Subscribe 항목과 수동 입력 항목이 함께 표시된다면 먼저 각 항목의 출처와 업데이트 담당이 무엇인지 확인해야 합니다. 용도나 정보 유형에 따라 구독마다 구분하기 쉬운 로컬 이름을 지정하고, 서버 이름만 보고 출처를 추측하지 마세요. 서버 이름은 업데이트에 따라 바뀔 수 있지만 구독 이름은 관리할 때 기준으로 삼기 좋습니다. 수동 입력 항목에도 알아보기 쉬운 메모를 붙일 수 있습니다. 다만 스크린샷이나 화면 공유에서 노출되지 않도록 비밀번호나 전체 구독 URL을 표시 이름에 넣지 마세요.

정리의 기본 단위는 목록의 각 서버 이름이 아니라 데이터가 들어온 경로입니다. 하나의 구독에 여러 서버가 포함될 수 있고, 서로 다른 구독에 비슷한 이름의 서버가 있을 수도 있습니다. 중복 여부를 판단할 때는 프로토콜, Address, Port와 주요 전송 매개변수를 비교한 뒤 각각 어떤 경로에 속하는지 확인하세요. 표시 이름이 같다는 이유만으로 삭제하면 필요한 별도 항목을 지울 수 있습니다. 두 항목이 완전히 같아 보인다면 하나를 남겨 테스트하고, 다른 항목의 출처를 기록한 뒤 중복 원인을 확인하고 처리하세요.

변경 과정을 되짚을 수 있도록 순서 정하기

새 구독을 추가한 뒤에는 새 항목에서 데이터를 가져올 수 있는지 먼저 확인한 다음 기존 항목을 정리하세요. 대규모 정리를 하기 전에는 적법하게 보유한 원본 링크와 수동 입력 매개변수를 저장해 둡니다. 이 순서를 지키면 실수로 삭제했을 때 다시 구성하는 부담을 줄일 수 있습니다. 더 이상 필요하지 않은 항목은 ‘목록에서 잠시 선택하지 않음’과 ‘구독 항목 삭제’를 구분하세요. 선택만 해제하면 나중에 계속 확인할 수 있지만, 구독 항목을 삭제하면 해당 URL로 목록 전체를 업데이트하는 경로를 잃을 수 있습니다. 한 번의 Connectivity Test 결과만 보고 결정하지 말고 실제 정보 상태를 기준으로 보관 여부를 정하세요.

구독과 수동 입력을 함께 사용한다면 변경 사항이 어느 쪽에 속하는지 특히 주의하세요. 구독에서 생성된 필드는 다음 업데이트에서 다시 바뀔 수 있으므로 구독 데이터에서 먼저 확인해야 합니다. 수동 입력 항목은 Add Server 편집 화면에서 직접 관리합니다. 구독 안의 특정 서버를 임시로 비교하려면 변경 전 필드와 변경 목적을 기록해 두세요. 그래야 업데이트 후 로컬에서 바꾼 내용과 구독 데이터의 변경을 구분할 수 있습니다. 기록은 복잡하지 않아도 됩니다. 구독 이름, 작업 전 현상, 바꾼 항목과 작업 후 결과만 적으면 됩니다.

여러 구독을 사용하면 목록 개수를 해석하기도 어려워집니다. 항목 수가 늘어난 이유는 새 구독 추가, 구독 내용 변경, 중복 가져오기일 수 있습니다. 줄어든 이유는 구독 삭제, 업데이트 결과 변경, 표시 범위 변경일 수 있습니다. 전체 개수만 보고 원인을 추측하지 말고 구독별로 확인하세요. 현재 한 항목만 사용하려면 출처가 분명한 서버를 선택한 뒤 Global Routing이 Config, Proxy, Direct 중 무엇으로 설정되어 있는지 확인하세요. 라우팅 모드와 서버 선택을 혼동하지 않도록 주의해야 합니다.

여러 기기에서 같은 정보를 사용할 때 이름 규칙을 통일하면 비교하기 편하지만, 각 기기의 로컬 목록이 자동으로 동기화되는 것은 아닙니다. 각 기기에서 Subscribe 항목과 수동 입력 항목, Config 선택 상태를 따로 확인하세요. 특히 한 기기에서 정보를 추가하거나 삭제한 뒤에는 다른 기기도 점검해야 합니다. 기기 호환성과 시스템 요구 사항은 App Store 페이지 표기를 따릅니다. 이 장은 iPhone과 iPad에서 정보를 관리하는 방법을 다루며, 목록 정렬은 기기 간 백업을 대신하지 않습니다. 다음 장에서는 정렬에 의존하지 않고 테스트 결과를 선택에 활용하는 방법을 설명합니다.

07 · Connectivity Test, 지연 시간 및 정렬

테스트 결과로 알 수 있는 것

Connectivity Test는 현재 네트워크 환경에서 클라이언트가 서버 항목에 대한 연결 테스트를 완료했는지 확인하는 데 사용할 수 있습니다. 장기적인 서비스 품질을 보장하거나 모든 앱 요청이 예상한 규칙대로 처리됨을 증명하지는 않습니다. 테스트 전에 대상 항목이 어느 Subscribe 또는 수동 입력 기록에 속하는지, 기기의 현재 네트워크 상태가 어떤지 확인하세요. 네트워크 환경을 바꾸면 결과도 달라질 수 있습니다. 한 번의 성공이나 실패는 당시 테스트 조건에만 해당합니다. 구독 URL을 계속 업데이트할 수 있는지는 Subscribe에서 별도로 확인해야 합니다.

지연 시간 수치는 비교에 도움이 되지만, 먼저 테스트 조건을 최대한 같게 맞춰야 합니다. 서로 다른 시간과 네트워크에서 얻은 결과를 하나의 고정된 순위처럼 비교하지 마세요. 수치가 낮다는 이유만으로 연결 안정성을 무시해서도 안 됩니다. 특정 항목에서 테스트 오류가 표시되면 같은 항목을 다시 테스트한 뒤 정상 여부를 알고 있는 다른 항목과 비교해 보세요. 모든 항목에서 동시에 오류가 발생하면 기기의 네트워크와 현재 설정을 먼저 확인합니다. 한 항목에서만 계속 문제가 생기면 해당 항목의 Address, Port, 인증 정보와 전송 매개변수를 점검하세요.

정렬은 찾기 위한 기능이지 검증을 대신하지 않습니다

지연 시간순 정렬은 항목이 많을 때 현재 테스트 결과가 상대적으로 양호한 항목을 빠르게 찾는 데 유용하지만, 정렬한 뒤에도 각 항목의 출처를 확인해야 합니다. 서버 이름이 비슷할 수 있고 테스트 결과도 네트워크에 따라 달라지므로 순위만 보고 선택하면 잘못 고르기 쉽습니다. 먼저 구독 이름이나 수동 입력 메모로 범위를 좁힌 뒤 테스트 상태와 지연 시간을 확인하세요. 자주 사용하는 항목은 정렬 화면을 한 번 캡처해 두는 것보다 주기적으로 다시 테스트하는 편이 유용합니다. 테스트 시간과 네트워크 조건이 빠진 스크린샷의 수치는 해석에 한계가 있습니다.

서버 테스트는 성공했지만 실제 요청이 예상과 다르면 연결과 라우팅을 나눠 확인하세요. 먼저 Home에서 실제로 선택된 서버와 연결 상태를 확인한 다음 Global Routing을 살펴봅니다. Config는 현재 Config의 규칙에 따라 처리하고, Proxy와 Direct는 서로 다른 라우팅 방식과 비교할 때 사용합니다. Config에서 대상이 DIRECT에 매칭되면 서버 테스트가 성공해도 해당 요청이 선택한 서버를 거친다는 뜻은 아닙니다. 규칙을 더 살펴봐야 한다면 DOMAIN-SUFFIX, GEOIP, IP-CIDR 등의 키워드와 정책을 확인해 요청이 어떤 규칙에 매칭되는지 살펴보세요.

문제를 확인할 때는 한 번에 조건 하나만 바꾸세요. 먼저 서버를 고정하고 라우팅 방식을 비교한 다음, 라우팅 방식을 고정하고 서버를 비교한 뒤, 마지막으로 Config를 확인합니다. 이렇게 하면 문제가 데이터, 연결 또는 규칙 중 어디에 있는지 구분할 수 있습니다. 여러 항목을 연달아 바꾸면 문제가 해결되어도 원인이 무엇인지 알 수 없습니다. 추가 문제는 자주 묻는 질문을 참고하세요. DNS 해석 경로에 관한 내용은 DNS 설정 안내에서 확인할 수 있습니다. 테스트와 정렬은 진단 도구일 뿐이며, 최종적으로는 실제 요청과 현재 규칙을 함께 살펴봐야 합니다.

08 · 삭제, 이전 및 정보 백업

삭제 전에 대상과 영향을 확인하세요

목록을 정리하기 전에 삭제하려는 대상이 수동 입력 서버 하나인지, 구독에서 생성된 항목인지, Subscribe 구독 자체인지 구분하세요. 항목 하나를 삭제하는 것과 구독을 삭제하는 것은 결과가 다릅니다. 구독을 제거하면 이 기기에서 해당 URL로 여러 항목을 업데이트하는 경로를 잃을 수 있습니다. 일시적으로 사용할 수 없는 서버 하나만 정리하려는 경우에도 구독에 속한 항목인지 먼저 확인하세요. 구독에 포함된 항목은 다음 업데이트에서 다시 추가될 수 있어 하나씩 삭제해도 원하는 대로 정리되지 않을 수 있습니다. 먼저 출처를 확인한 뒤 삭제 여부를 결정하세요.

정리는 확인, 저장, 실행, 재확인의 네 단계로 나누는 것이 좋습니다. 확인 단계에서는 이름과 주요 필드를 살펴 비슷한 항목을 잘못 식별하지 않도록 합니다. 저장 단계에서는 직접 보유한 원본 구독 URL과 수동 입력 매개변수, 계속 사용할 Config 텍스트를 보관합니다. 실행 단계에서는 한 번에 한 종류의 대상만 삭제하세요. 재확인 단계에서는 Home으로 돌아가 남겨 둔 구독이 예상대로 업데이트되는지, 선택한 서버가 목록에 남아 있는지 확인합니다. 기록이 아직 필요한지 판단할 수 없다면 유일한 원본 정보를 삭제하지 마세요. 목록을 깔끔하게 관리하는 것도 중요하지만 다시 구성할 정보를 잃어서는 안 됩니다.

다시 구성할 수 있는 정보를 백업하세요

백업은 목록 스크린샷 한 장을 저장하는 것만으로 충분하지 않습니다. 스크린샷에는 전체 URL, 비밀번호, 키, 경로와 다른 필드가 가려질 수 있고, 항목이 수동 입력인지 Subscribe에서 생성되었는지도 알 수 없을 수 있습니다. 더 확실한 방법은 직접 보유한 구독 원본 링크, 수동 입력 서버의 전체 매개변수, 계속 사용할 Config 내용을 각각 저장하고 용도를 함께 기록하는 것입니다. 민감한 정보는 접근 권한을 직접 관리할 수 있는 곳에 보관하세요. 문제 확인용 스크린샷을 공유하기 전에는 인증 정보나 매개변수가 포함된 URL이 화면에 보이는지 확인하세요.

다른 iPhone 또는 iPad에서 다시 설정할 때는 먼저 App Store에서 Shadowrocket을 받아 앱의 정체를 확인하세요. 그런 다음 정보 유형에 따라 복원합니다. 구독 URL은 Subscribe에, 단일 서버 매개변수는 Add Server에, Config 내용은 구성 파일 메뉴에 추가합니다. 복원 후에는 항목 수만 확인하지 말고 구독을 업데이트할 수 있는지, 수동 입력 매개변수가 빠짐없이 들어갔는지, Global Routing과 필요한 Config가 올바르게 선택되었는지도 점검하세요. 이전에 구매한 앱 복원은 App Store 구매 기록 문제이며 서버 정보를 다시 구성할 수 있는지와는 별개입니다. 전자는 구매 항목 복원 안내를 참고하세요.

더 이상 사용하지 않는 정보를 삭제하기 전에는 다른 곳에 해당 설정 참조가 남아 있는지 확인하세요. 예를 들어 Config 규칙이 특정 정책 이름을 계속 참조할 수 있으며, 관련 항목을 삭제해도 규칙 자체가 자동으로 올바르게 바뀌지는 않습니다. 먼저 참조 관계를 확인한 뒤 불필요한 항목을 정리하세요. 반대로 서버만 잠시 바꾸려는 경우라면 기존 항목을 삭제하지 않아도 됩니다. 출처를 명확히 하고 원본 정보를 보관하는 편이 나중에 연결 결과와 구독 변경을 비교하기 쉽습니다.

이 가이드에서는 가져오기부터 정리까지 서버 관리 과정을 모두 다뤘습니다. 처음 설정한다면 시작 가이드의 기본 순서를 따르세요. 목록이 비거나 매개변수가 일치하지 않거나 규칙 결과를 이해하기 어려울 때는 해당 장으로 돌아가 항목별로 확인하면 됩니다. Shadowrocket은 App Store에서 받을 수 있으며 개발자는 Shadow Launch Technology Limited, 앱 ID는 932747118입니다. 기기 호환성과 시스템 요구 사항은 App Store 페이지 표기를 따릅니다. 앱의 일회성 구매는 서버 이용 요금제와 별개이며, 서버 정보는 직접 관리하고 확인해야 합니다.