Shadowrocket 구독 및 서버 관리

Subscribe 메뉴와 구독 기록

구독 URL과 서버 주소 구분하기

구독 URL은 서버 목록을 요청하는 주소이고, 서버 주소는 특정 연결 설정에서 실제로 접속하는 호스트입니다. 둘 다 도메인을 포함할 수 있지만 같은 입력란에 넣을 수는 없습니다. 시작하기 전에 보유한 정보가 완전한 구독 URL인지, 단일 서버 공유 링크인지, 아니면 직접 입력할 여러 매개변수인지 확인하세요. 서버 목록을 제공하는 구독 URL을 받은 경우에만 Subscribe를 선택합니다. HTTPS로 시작한다고 해서 구독 URL인 것은 아닙니다. 일반 웹페이지도 같은 형식을 사용합니다.

Home에서 Add Server로 이동한 뒤 Type에서 Subscribe를 선택하고, 현재 화면에 표시되는 URL 등의 항목에 보유한 구독 주소를 입력합니다. 기록에는 알아보기 쉬운 이름을 지정하세요. 화면 구성에 따라 메뉴 위치가 다를 수 있으므로 영문 메뉴명을 기준으로 확인합니다. 붙여넣은 뒤 주소의 시작과 끝, 쿼리 매개변수가 모두 들어 있는지 살펴보세요. 특히 메신저가 자동으로 추가하는 공백과 줄바꿈에 주의해야 합니다. 저장하기 전에 구독 URL을 목록에 포함된 서버 도메인으로 바꾸거나 불필요해 보이는 매개변수를 임의로 삭제하지 마세요.

기록 저장과 목록 가져오기는 별개의 단계입니다

구독 기록이 저장되었다는 것은 클라이언트가 해당 기록을 받아들였다는 뜻일 뿐, 원격 요청이 성공했다는 의미는 아닙니다. 저장 후 구독 기록의 업데이트 기능을 사용해 내용을 가져온 다음 Home으로 돌아가 해당 서버가 표시되는지 확인하세요. 구독 이름만 있고 서버 항목이 없다면 연결을 바로 켜지 말고 업데이트 결과를 확인해야 합니다. 목록에 항목이 있다면 이전에 수동으로 가져온 기록을 업데이트 결과로 착각하지 않도록 이번 구독에서 가져온 항목인지도 살펴보세요.

구독 응답에는 클라이언트가 인식할 수 있는 서버 설명이 포함되어야 합니다. 로그인 페이지, 안내 웹페이지 또는 오류 메시지가 반환된다면 브라우저에서 URL이 열린다고 해서 가져올 수 있는 내용이라는 뜻은 아닙니다. 먼저 클라이언트에 표시된 오류 정보를 확인하고, 해당 주소의 용도와 지원 형식은 이용 중인 서비스의 관리 담당자에게 문의하세요. 인증 정보가 포함된 구독 URL을 공개 조회 도구에 입력하지 말고, 문제를 해결하려고 전체 링크를 여러 곳에 반복해서 붙여넣을 필요도 없습니다.

구독과 Config의 역할 구분하기

서버 목록과 Config의 규칙은 서로 다른 역할을 합니다. 서버 목록은 어디에 어떤 프로토콜과 인증 정보를 사용해 연결할지 정하고, Config는 요청을 PROXY, DIRECT 또는 REJECT 중 어떤 방식으로 처리할지 결정합니다. 구독을 가져왔다고 해서 현재 규칙 파일까지 바뀌었다고 가정해서는 안 됩니다. 마찬가지로 Config를 바꿔도 서버 목록이 다시 가져와지는 것은 아닙니다. 두 작업을 따로 확인하면 목록은 정상인데 규칙 경로가 달라 연결이 실패한 상황을 혼동하지 않을 수 있습니다.

가져오기가 끝나면 구독 이름, 가져온 방식, 현재 선택한 서버를 기록한 뒤 첫 연결 단계에 따라 테스트하세요. 목록이 비어 있으면 먼저 URL, 반환 내용 및 네트워크 연결을 확인합니다. 목록은 정상인데 연결할 수 없다면 매개변수 및 테스트 항목으로 이동하세요. 확인 순서는 ‘목록 가져오기, 매개변수 확인, 연결 설정, 대상에 접근’의 단계별로 진행합니다. 구독, Config, DNS를 동시에 바꾸면 어떤 변경이 결과에 영향을 주었는지 파악하기 어렵습니다.

Add Server 수동 입력 항목

Type에 따라 입력할 매개변수가 달라집니다

수동 추가는 서버 매개변수를 모두 보유하고 있으며 항목별로 확인해야 할 때 적합합니다. Home에서 Add Server로 이동해 Type을 먼저 선택한 다음 나머지 항목을 입력하세요. Shadowsocks, VMess, VLESS, Trojan, HTTP, SOCKS5, WireGuard 및 Hysteria2는 필요한 정보가 서로 다릅니다. Type을 바꿀 때 표시되거나 사라지는 항목은 서로 바꿔 쓸 수 있는 별칭이 아닙니다. 원본 설정에 명시된 프로토콜을 기준으로 선택하고, 누락된 매개변수를 다른 유형을 시도해 보며 보완하려 하지 마세요.

Address에는 보통 서버 호스트 이름이나 IP를 입력하고, Port에는 서버 측에서 제공한 포트를 입력합니다. 해당 항목이 URL을 요구한다고 명시하지 않는 한 프로토콜 접두사, 웹 경로 및 쿼리 문자열을 Address에 함께 넣지 마세요. 도메인과 IP도 언제나 서로 바꿔 쓸 수 있는 것은 아닙니다. 도메인은 이름 확인, 인증서 이름 및 서버 라우팅에 영향을 줄 수 있습니다. 원본 정보에 도메인이 제시되어 있다면 먼저 그대로 입력하고, 변수를 줄이려고 확인된 IP로 임의 변경하지 마세요.

인증, 전송 및 TLS를 나누어 확인

Password, UUID 등의 인증 정보는 문자와 대소문자를 그대로 유지해야 합니다. Shadowsocks의 Method는 서버 측 설정과 일치해야 하며, 모든 암호화 옵션이 서로 호환되는 것은 아닙니다. VMess 또는 VLESS에 전송 방식이 지정되어 있다면 해당 항목도 확인하세요. 전송 계층의 Host와 Path가 요청 일치 여부에 영향을 줄 수도 있습니다. 주소, 포트 및 인증 정보만 정확히 입력했다고 해서 다른 필수 매개변수까지 자동으로 설정되는 것은 아닙니다.

TLS, SNI 및 연결 주소는 서로 관련되어 있지만 같은 개념은 아닙니다. 연결 주소는 접속할 엔드포인트를 지정하고, SNI는 필요한 경우 서버 이름을 전달하며, 인증서 검증은 연결 대상의 신원을 확인합니다. 원본 설정에 이름이 명시되어 있다면 그대로 확인하세요. 인증서 검증을 끄는 방식은 일반적인 해결책이 아닙니다. 인증서 오류가 발생하면 포트만 바꾸지 말고 먼저 기기 시간, 이름 일치 여부 및 서버 측 인증서 상태를 확인한 다음 전송 설정을 점검하세요.

프로토콜별 매개변수를 서로 가져다 쓰지 마세요

WireGuard의 개인 키, 피어 공개 키, Address, Allowed IPs 및 MTU는 별도의 설정 체계에 속합니다. 여기서 Address는 터널 주소를 뜻할 수 있으므로 일반 서버 Address와 같은 의미로 해석해서는 안 됩니다. 피어의 위치는 Endpoint로 지정합니다. Hysteria2의 인증 및 전송 옵션도 원본 정보를 기준으로 각각 입력하세요. WireGuard 항목을 더 알아보려면 WireGuard 매개변수 안내를 참고하고, 다른 프로토콜의 항목을 근거로 누락된 값을 추측하지 마세요.

저장하기 전에 원본 정보를 기준으로 항목을 하나씩 확인하세요. 놓치기 쉬운 앞뒤 공백, 전각 문장 부호 및 자동 줄바꿈을 먼저 살펴보는 것이 좋습니다. 저장 후 편집 화면을 다시 열어 입력한 값이 예상대로 유지되는지 확인한 다음 연결을 테스트하세요. 인증 단계에서 오류가 발생하면 인증 정보를 먼저 확인하고, 엔드포인트에 도달할 수 없다면 네트워크와 주소를 점검합니다. 한 번에 하나의 항목만 바꾸고 변경 전 값을 기록하면 여러 차례 시도한 뒤에도 서버에서 실제로 제공한 설정 조합을 확인할 수 있습니다.

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

Scan QR Code는 QR 코드 안의 내용을 읽습니다

QR 코드는 텍스트를 담는 수단일 뿐, 모양만으로 구독인지 단일 서버인지 일반 웹페이지인지 알 수 없습니다. Scan QR Code를 사용하기 전에 QR 코드가 본인의 설정 자료에서 나온 것인지 확인하고, 가장자리 전체가 보이도록 밝고 선명하게 표시하세요. 카메라를 처음 사용하면 시스템에서 접근 권한을 요청할 수 있습니다. 허용 여부는 필요한 작업을 고려해 직접 결정하세요. 인식에 실패하면 이미지 품질과 권한부터 확인하고, 기존 서버를 바로 수정하거나 ‘공간을 확보하려고’ 기존 기록을 삭제하지 마세요.

인식이 완료되면 가져온 결과가 어떤 종류의 기록인지 먼저 확인하세요. QR 코드에 단일 서버 링크가 담겨 있다면 보통 연결 정보 한 건이 추가됩니다. 구독 주소가 들어 있다면 목록을 가져오는 단계가 추가로 필요합니다. 확인 화면이 표시되면 Type, Address 및 이름이 적절한지 살펴보세요. ‘인식 성공’만으로 매개변수가 모두 갖춰졌다고 판단하면 안 됩니다. QR 코드에 오래된 인증 정보가 포함되어 있을 수도 있으므로 가져온 후 연결을 테스트해야 합니다. 스캔 성공 여부만으로 원격 설정이 아직 유효한지 알 수는 없습니다.

클립보드에서 전체 텍스트 가져오기

클립보드로 가져올 때는 필요한 링크나 설정 텍스트만 복사하세요. 설명 문구, 번호, 코드 블록 표시 및 문장 끝의 문장 부호까지 함께 복사하지 않도록 주의합니다. 현재 화면에 클립보드 가져오기 메뉴가 있다면 안내에 따라 확인하세요. 시스템에서 붙여넣기 권한을 묻는 경우 작업을 시작한 앱이 맞는지 살펴봅니다. 복사한 직후 가져오면 다른 복사 작업으로 내용이 덮어써질 가능성을 줄일 수 있습니다. 클립보드가 비었거나 다른 내용으로 바뀌었다면 기억에 의존해 문자를 조합하지 말고 원본에서 다시 복사하세요.

메신저 창에서는 긴 링크가 화면상 줄바꿈되어 보일 수 있지만 실제 줄바꿈 문자가 포함된 것은 아닐 수 있습니다. 반대로 여러 줄을 복사하면 실제 줄바꿈이 들어갈 수도 있습니다. 형식을 인식할 수 없다는 메시지가 표시되면 먼저 접두사와 끝부분을 확인한 뒤 중간이 잘리지 않았는지 살펴보세요. 모든 공백을 한꺼번에 바꾸면 안 됩니다. 이름 부분과 인코딩된 내용은 처리 방식이 다를 수 있습니다. 가장 안전한 방법은 원본 텍스트에서 한 줄 전체를 다시 복사한 다음 가져온 주요 항목과 대조하는 것입니다.

중복, 일괄 가져오기 및 인식 실패 처리

여러 항목을 한꺼번에 가져오기 전에 현재 메뉴에서 해당 텍스트 형식을 지원하는지 확인하세요. 링크가 여러 줄에 나열되어 있어도 구독으로 처리된다는 보장은 없습니다. 일부 입력 메뉴는 한 번에 한 항목만 받습니다. 먼저 본인이 보유한 유효한 정보 한 건으로 메뉴를 확인한 다음 나머지를 처리할 수 있습니다. 가져온 후에는 개수를 이름만 세지 말고 프로토콜, 주소 및 포트를 기준으로 확인하세요. 이름이 같은 두 기록이 서로 다른 엔드포인트를 가리킬 수 있고, 이름이 달라도 연결 매개변수는 완전히 같을 수 있습니다.

같은 항목을 여러 번 가져왔더라도 이름만 보고 바로 일괄 삭제하지 마세요. 어떤 기록이 구독에서 관리되고 어떤 기록이 직접 가져온 것인지, 현재 어떤 항목을 사용하는지 먼저 확인합니다. QR 코드와 클립보드의 결과가 다르면 원본 두 개가 실제로 같은 내용인지 비교하세요. 특히 QR 코드 옆에 있는 다른 링크를 복사하지 않았는지 살펴보세요. 같은 자료를 두 방식으로 가져와도 인식되지 않는다면 카메라보다는 형식이나 내용이 원인일 가능성이 큽니다. 이때는 공유 링크 항목에서 구조를 확인하세요.

가져오기가 끝나면 Home으로 돌아가 새 기록을 선택하고 다시 확인하세요. 기존에 연결되어 있던 상태가 새 서버로 자동 전환되지는 않을 수 있고, 브라우저의 이전 페이지가 캐시에 남아 있을 수도 있습니다. 테스트할 때는 현재 선택된 항목을 분명히 확인하고 새 요청으로 결과를 판단하세요. 가져오기만 확인하려는 경우에는 매개변수만 살펴보면 됩니다. 테스트를 위해 On Demand까지 동시에 켤 필요는 없습니다. 가져오기와 연결 작업을 분리하면 실패가 어느 단계에서 발생했는지 파악하기 쉽습니다.

공유 링크 형식과 Config의 역할

접두사, 본문, 매개변수 및 이름

서버 공유 링크는 보통 프로토콜 접두사, 연결 정보를 담은 본문, 선택적 쿼리 매개변수 및 표시 이름으로 구성됩니다. 흔한 접두사로는 ss://, vmess://, vless:// 및 trojan://가 있습니다. 접두사를 인식할 수 있다고 해서 나머지 항목까지 완전하다는 뜻은 아닙니다. 본문이 인코딩된 형식도 있고 인증 정보와 주소를 직접 담는 형식도 있습니다. 접두사만 바꿔 서로 다른 형식으로 변환할 수는 없습니다. 가져올 때는 링크 전체를 유지하고, 겉모양만 보고 다른 프로토콜 형식으로 임의 변환하지 마세요.

링크에서 물음표는 보통 쿼리 매개변수의 시작을 나타내고, 해시 기호 뒤에는 표시 이름이 올 수 있으며, 퍼센트 인코딩은 특정 특수 문자를 표현합니다. 각각 문법적인 의미가 있으므로 장식 기호가 아닙니다. 직접 편집할 때 매개변수 구분 기호를 지우거나 인코딩 문자를 디코딩한 뒤 복사하면 클라이언트가 다른 내용을 읽을 수 있습니다. 이름을 바꾸려면 인증 또는 전송 매개변수를 함께 손상하지 않도록 가져온 뒤 편집 화면에서 표시 이름을 수정하세요.

단일 링크와 구독은 서로 다른 항목입니다

단일 공유 링크는 보통 서버 기록 하나를 설명하고, 구독 URL은 원격에서 목록을 가져오는 데 사용됩니다. 구독 응답에는 여러 서버 설명이 포함될 수도 있고 다른 지원 형식이 사용될 수도 있습니다. 이는 응답 내용의 형식이며 구독 주소 자체의 작성 방식과는 다릅니다. 브라우저에 표시된 전체 텍스트를 Address에 임의로 붙여넣거나 단일 서버 링크를 지속적으로 업데이트되는 목록 주소로 취급하지 마세요. 먼저 어떤 유형의 정보인지 확인한 뒤 가져오기 메뉴를 선택해야 이후에도 올바르게 관리할 수 있습니다.

가져온 뒤 주요 항목이 비어 있다면 클라이언트의 기본값이 맞다고 가정하지 말고 형식 불일치, 텍스트 잘림 또는 링크의 매개변수 누락을 먼저 의심하세요. 특히 전송, TLS 및 인증 정보의 기본값은 원본 설정과 다를 수 있습니다. 구조화된 기존 매개변수와 항목별로 대조하되, 읽을 수 있는 이름만 보고 프로토콜을 추측하지 마세요. 이름에 지역이나 용도가 표시되어 있어도 이는 레이블일 뿐 주소, 프로토콜 또는 사용 가능성을 입증하지 않습니다.

Config 파일의 규칙 편집

Shadowrocket의 .conf 파일에는 규칙이 포함될 수 있으며, 규칙 일부를 서버 공유 링크처럼 취급해서는 안 됩니다. 아래 예시는 일치 순서와 동작만 설명하며 서버 매개변수를 포함하지 않습니다. 개인 설정을 그대로 대체할 수 있는 완성된 파일도 아닙니다. 사용하기 전에 기존 파일의 다른 항목과 정책 관계를 확인하세요. 기존 설정을 수정할 때는 먼저 복사본을 백업하고 해당 부분을 찾아 편집해야 합니다. 짧은 예시를 파일 전체에 덮어쓰지 않도록 주의하세요.

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

DOMAIN-SUFFIX는 도메인 접미사로 일치 여부를 판단하고, GEOIP는 관련 IP 지리 정보를 기준으로 처리하며, FINAL은 앞서 일치하지 않은 요청을 처리합니다. 규칙은 순서대로 실행되므로 앞부분에서 일치하면 이후 규칙을 계속 확인할지에 영향을 줍니다. 예시의 PROXY는 해당 요청에 적용되는 프록시 동작을 뜻하며 특정 서버를 지정하지 않습니다. 규칙 문법이 올바르더라도 서버 인증 정보가 만료되었다면 FINAL을 수정해 인증 문제를 해결할 수 없습니다.

공유하기 전에 받는 기기에 전체 인증 정보가 정말 필요한지 확인하고, 본인이 관리할 수 있는 전달 방식을 선택하세요. 문제 해결을 돕는 목적이라면 보통 프로토콜 이름, 오류 유형 및 가린 매개변수 구조만으로 충분하며 링크 전체를 보낼 필요는 없습니다. 인증 정보가 포함된 텍스트를 다른 사람이 확보하면 기기에서 메시지를 삭제해도 기존 인증 정보가 무효화되지는 않습니다. 접근을 차단해야 한다면 본인이 관리하는 서비스에서 해당 인증 정보를 변경한 뒤 클라이언트 기록을 업데이트하세요.

구독 업데이트 방식과 오류 처리

업데이트는 목록을 바꾸지만 모든 설정을 바꾸지는 않습니다

구독 업데이트는 주소에 다시 요청을 보내 반환된 내용을 해석하는 과정입니다. 서버가 추가되거나 기존 항목이 제거되고 매개변수가 바뀔 수 있습니다. 이는 App Store 앱 업데이트나 Config 파일 업데이트와는 별개의 작업입니다. 앱 기능이 업데이트되어도 구독 내용이 동기화되는 것은 아니며, 구독 업데이트에 성공해도 규칙 파일이 바뀌지는 않습니다. 문제를 확인할 때는 어떤 종류의 업데이트인지 각각 구분하세요. 서버 목록이 바뀌었는데도 이전 이름만 보고 현재 설정이 완전한지 판단하는 실수를 피할 수 있습니다.

업데이트 전에 현재 사용 중인 항목을 기록하고 직접 수정한 매개변수가 있는지 확인하세요. 구독으로 관리되는 기록은 내용을 다시 가져올 때 재구성되거나 덮어써질 수 있습니다. 중요한 로컬 변경 사항을 하위 서버 기록에만 저장하지 마세요. 테스트 설정을 보관해야 한다면 먼저 용도를 적은 별도 사본을 저장한 뒤 업데이트하세요. 구독에서 항목을 식별하는 방식과 클라이언트에서 변경 사항을 표시하는 방식은 콘텐츠 형식에 따라 달라질 수 있습니다. 이름이 같다고 해서 같은 내부 기록으로 유지된다고 가정하면 안 됩니다.

수동 업데이트와 자동 업데이트의 역할

수동 업데이트는 처음 가져올 때, 설정 변경 알림을 받았을 때, 또는 문제 해결 후 다시 확인할 때 적합합니다. 현재 설정에서 자동 업데이트를 제공한다면 필요에 따라 선택하고 어떤 항목에 적용되는지 확인하세요. 자동 업데이트는 계속 실행되는 온라인 모니터링이 아닙니다. 기기의 백그라운드 실행도 시스템 상태의 영향을 받을 수 있으므로 중요한 작업을 하기 전에는 목록과 최근에 확인할 수 있는 결과를 직접 확인하세요. 설정이 켜져 있다는 사실만으로 내용이 제때 갱신되었다고 판단하지 마세요.

업데이트에 실패했다고 짧은 간격으로 계속 요청하지 마세요. 같은 요청을 반복해도 주소 오류가 해결되는 경우는 드물고 로그에 같은 현상만 쌓일 수 있습니다. 먼저 오류 메시지를 보관하고 기기의 기본 네트워크가 정상인지 확인한 다음 도메인 확인, 연결, 응답 상태 또는 내용 해석 중 어느 단계에서 실패했는지 살펴보세요. 구독 URL이 바뀌었다면 올바른 기록을 편집하고 전체 매개변수를 확인해야 합니다. 계속 새 구독을 추가하면 출처는 같은데 상태가 서로 다른 목록이 여러 개 생길 수 있습니다.

업데이트에 성공한 뒤 사용 중인 기록 확인

업데이트 성공 메시지가 표시되면 구독에 포함된 항목이 예상대로인지, 특히 현재 선택 항목이 그대로 있는지 확인하세요. 기존 항목이 제거되었다면 유효한 항목을 다시 선택한 뒤 연결을 테스트합니다. 클라이언트가 이전 결과를 유지할 수도 있으므로 ‘목록이 여전히 표시됨’과 ‘이번 요청이 성공함’을 구분해야 합니다. 기존 목록이 있다는 사실만으로는 로컬에 데이터가 남아 있다는 점만 알 수 있습니다. 반대로 목록이 달라지지 않았어도 실패라고 단정할 필요는 없습니다. 원격 내용에 실제 변경이 없었을 수 있으므로 업데이트 결과 메시지와 함께 판단하세요.

기본 네트워크와 프록시 경로의 결과가 다르다면 업데이트 요청이 실제로 어떤 경로를 사용했는지 먼저 확인하세요. 현재 선택된 서버를 반드시 따를 것이라고 가정할 수는 없습니다. 지연 시간은 정상인데 구독 도메인을 확인할 수 없다면 DNS 및 이름 확인 오류 해결을 참고하세요. 원래 값을 기록하지 않은 상태에서 DNS, 라우팅 모드 및 구독 주소를 동시에 바꾸지 마세요. 변수가 늘어나면 성공 또는 실패의 원인을 구분하기 어렵습니다.

관리가 끝나면 이번 요청에서 내용을 가져왔는지, 어떤 항목이 바뀌었는지, 다시 확인했는지만 간단히 기록하면 됩니다. 기록에 구독 인증 정보를 포함하지 마세요. 업데이트 후 현재 연결을 사용할 수 없게 되었다면 유효하다고 확인한 백업 기록과 새 매개변수를 먼저 비교하세요. 이전 목록을 같은 구독에 다시 가져와 계속 유지될 것으로 기대하지 마세요. 장기적으로는 유효한 구독 내용에 따라 관리해야 합니다.

여러 구독 이름 지정 및 서버 정리

연결 상태가 아니라 관리 목적에 따라 이름 지정

구독이 여러 개라면 개인 테스트, 일상 설정 또는 예비 기록처럼 용도를 구분할 수 있는 이름을 먼저 지정하세요. 별도로 직접 가져온 기록에는 출처 유형을 표시합니다. 이름은 찾기 위한 것이므로 인증 정보, 전체 주소 또는 임시 테스트 결과를 넣지 않아도 됩니다. 특정 시점의 지연 시간을 이름에 포함하면 금방 오래된 정보가 되고, ‘사용 가능’을 영구적인 표시처럼 쓰면 이후 관리에 혼란을 줍니다. 꾸준히 쓸 수 있는 이름은 실시간 성능을 약속하는 대신 소속과 용도를 나타내야 합니다.

구독 이름과 그 아래의 서버 이름은 서로 다른 수준의 정보를 담습니다. 관리할 때는 먼저 서버가 어느 구독에 속하는지 확인한 뒤 연결 매개변수를 살펴보세요. 표시 이름만으로 중복 여부를 판단하면 안 됩니다. 서로 다른 구독에서 같은 이름을 반환할 수 있고, 같은 구독에서도 비슷한 이름이 여러 개 나올 수 있습니다. 보관할 로컬 테스트 기록은 별도로 표시해 업데이트나 정리 시 원격에서 관리되는 항목과 직접 관리해야 할 항목을 구분하세요.

중복 여부는 주요 매개변수를 비교해 판단

중복 여부를 판단하려면 최소한 Type, Address, Port 및 관련 전송 매개변수를 비교해야 합니다. 인증이 필요한 프로토콜에서는 인증 정보도 같은지 확인하되 일반 메모에 인증 정보를 복사할 필요는 없습니다. 엔드포인트가 같아도 인증 정보나 전송 옵션이 다르면 용도가 다를 수 있습니다. 반대로 이름은 달라도 모든 연결 항목이 같다면 가져오기 과정에서 중복된 기록일 수 있습니다. 삭제하기 전에 현재 선택 항목인지 확인해 사용 중인 별도 기록을 실수로 지우지 않도록 하세요.

목록을 통일해 보이게 하려고 모든 구독 항목을 수동 기록으로 복사하지 마세요. 업데이트 관계가 사라져 이후 매개변수 변경을 하나씩 반영해야 합니다. 고정된 매개변수로 테스트할 복사본이 꼭 필요한 경우에는 별도 기록으로 보관하고 원래 구독의 변경 사항을 자동으로 따르지 않는다는 점을 명확히 표시하세요. 같은 주소를 구독으로 여러 번 추가했다면 URL이 비슷하다는 이유만으로 모두 제거하지 말고, 필터 또는 관리 목적이 서로 다른지 먼저 확인하세요.

목록 정리와 Global Routing은 별개입니다

서버 정렬은 항목을 찾고 선택하기 위한 기능이고, Global Routing은 요청을 처리하는 방식을 정합니다. 목록 맨 위에 있는 기록이 모든 요청의 출구가 되는 것은 아닙니다. 현재 선택 항목, Config의 정책 관계 및 라우팅 모드를 각각 확인해야 합니다. 정리한 뒤 Home으로 돌아가 현재 선택을 확인하고 사용 중인 Config에서 규칙 동작을 살펴보세요. 이름이나 순서만 바꿨다고 해서 규칙 파일 전체를 다시 작성할 필요는 없습니다.

목록이 길다면 현재 화면에서 제공하는 그룹, 검색 또는 정렬 기능을 이용해 범위를 좁힌 뒤 매개변수를 확인하세요. 메뉴 위치는 실제 화면에 표시된 내용을 기준으로 하며, 특정 화면 배치를 재현하려고 모든 기록을 다시 만들 필요는 없습니다. 한 번에 구독 하나씩 정리하고 해당 항목을 알아볼 수 있는지 확인한 다음 다음 그룹으로 넘어가세요. 나누어 작업하면 문제가 생겼을 때 최근 변경 사항으로 돌아가기 쉽고, 목록 전체가 한꺼번에 바뀐 상황도 피할 수 있습니다.

정리할 때는 민감한 정보도 관리해야 합니다. 용도를 설명하는 메모에 Password, UUID 또는 전체 구독 URL을 넣지 말고, 공개 화면을 캡처하기 전에 구독 이름이 개인 식별 정보를 드러내는지도 확인하세요. 여러 기기에서 같은 정리 방식을 유지해야 한다면 한 기기에서 이름 규칙과 백업 범위를 먼저 정한 뒤 다른 기기에 복원하고 차이를 확인합니다. 여러 기기에서 동시에 수동으로 이름을 바꾸면 혼란이 생길 수 있으므로 이름 자체보다 관리 순서를 명확히 하세요.

Connectivity Test 결과 및 정렬 판단

먼저 테스트 대상이 무엇인지 확인

Connectivity Test 결과는 현재 적용된 테스트 방식에 따라 해석해야 합니다. 방식에 따라 엔드포인트 연결, 프록시를 통한 테스트 대상 접속 또는 특정 단계만 확인할 수 있으므로 숫자 하나로 전체 사용 경험을 판단할 수는 없습니다. 테스트 전에 관련 설정을 확인해 대상, 방식 및 현재 네트워크를 파악한 뒤 결과를 비교하세요. 네트워크, 대상 또는 테스트 방식이 다른 결과를 같은 조건에서 측정한 성능처럼 정렬하지 마세요.

엔드포인트가 응답했다고 해서 인증, TLS, 전송 및 대상 접속까지 모두 성공한 것은 아닙니다. 지연 시간이 표시된 기록도 인증 정보가 잘못되었거나 매개변수가 맞지 않으면 실제 요청을 완료하지 못할 수 있습니다. 반대로 테스트 대상에 일시적으로 접근할 수 없다고 서버 전체를 사용할 수 없는 것은 아닙니다. 테스트 결과는 단서로 활용하고 실제로 접속하려는 정상적인 대상으로 확인하세요. 결과가 다르면 어느 단계에서 실패했는지 찾고, 시간 초과로 표시된 항목을 전부 바로 삭제하지 마세요.

같은 조건에서 비교하고 정렬

정렬하기 전에 기기 네트워크와 테스트 설정을 고정하세요. 테스트 도중 Wi-Fi에서 셀룰러 네트워크로 전환하지 않는 것이 좋습니다. 후보가 많지 않다면 목록 전체를 한 번 측정해 결론을 내리는 것보다 일부 항목을 반복해서 확인하는 편이 결과를 해석하기 쉽습니다. 정렬 결과는 해당 시점과 조건에만 해당하며 이후 대역폭, 안정성 또는 대상 접속 상태가 같다고 보장하지 않습니다. 짧은 시간의 차이를 서비스 품질 변화로 과도하게 해석하거나 한 번 측정한 최저 수치로 이후 모든 요청 경로를 정하지 마세요.

테스트 후 항목을 선택했다면 선택 상태가 실제로 바뀌었는지 확인하세요. 필요한 경우 연결을 다시 설정하고 새 요청을 보냅니다. 브라우저 캐시, 기존 연결 및 다른 앱의 세션 때문에 결과가 늦게 반영될 수 있으므로 이전 페이지가 계속 표시된다는 사실만으로 새 서버가 작동한다고 볼 수 없습니다. 새 작업을 통해 명확히 확인하고 현재 Global Routing 모드도 기억하세요. Direct 모드에서는 직접 접속에 성공해도 프록시 기록이 정상이라고 입증되지 않습니다.

장애를 확인 가능한 단계로 나누기

기본 네트워크, 서버 매개변수, 연결 상태, DNS, 규칙 및 대상 서비스 순서로 확인하는 것이 좋습니다. 기본 네트워크에 문제가 있다면 먼저 기기의 일반 인터넷 연결을 복구하세요. 매개변수에 문제가 있다면 Add Server로 돌아가 항목을 대조합니다. 특정 대상의 도메인만 확인되지 않을 때 DNS를 점검하세요. 모든 후보에서 같은 현상이 나타난다면 서버별 인증 항목을 하나씩 바꾸기보다 현재 네트워크, 테스트 대상 또는 Config 같은 공통 변수를 먼저 확인하세요.

로그와 Data에 표시되는 정보를 통해 요청이 실제로 전송되었는지, 어떤 경로를 거쳤는지 확인할 수 있습니다. 이전 오류를 현재 결과로 착각하지 않도록 이번 작업과 가까운 기록부터 살펴보세요. 문제 해결 자료를 공유할 때는 필요한 오류 유형과 가린 항목만 남기고 전체 인증 정보를 보내지 마세요. 지연 시간은 정상인데 웹페이지가 열리지 않는 경우 DNS 문제 해결을 참고해 이름 확인과 요청 경로를 나누어 확인하세요.

마지막으로 정렬과 장기적인 관리를 구분하세요. 일시적으로 시간 초과가 발생한 기록은 다시 확인할 때까지 남겨 둘 수 있습니다. 원격에서 삭제되었거나 인증 정보가 취소된 것이 확인된 기록은 삭제 절차를 진행하세요. 테스트 한 번으로 대규모 정리를 시작하거나 규칙을 자동으로 바꾸지 마세요. 결과가 안정되면 테스트 조건과 현재 선택 항목을 기록하면 됩니다. 오래된 정렬 결과에 의존하기보다 네트워크 환경이 바뀔 때마다 다시 확인하는 편이 실제 상황을 잘 반영합니다.

삭제, 백업 및 새 기기로 복원

먼저 백업 대상을 구분하세요

백업 전에 구독 기록, 독립 서버, Config 파일 및 관련 설정을 구분하세요. 규칙 파일을 저장했다고 해서 모든 구독 주소와 인증 정보까지 저장된 것은 아닙니다. 서버 공유 링크를 저장해도 현재 규칙과 기기 설정이 모두 보존되는 것은 아닙니다. 현재 내보내기 또는 동기화 기능이 어디까지 지원하는지 확인한 뒤 필요한 항목을 추가로 저장하세요. 직접 입력한 매개변수의 원본 자료를 더 이상 찾을 수 없다면 삭제 전에 복원 가능한 사본이 있는지 반드시 확인해야 합니다.

iCloud 관련 기능을 사용할 때는 현재 기기의 계정과 앱 내 관련 설정을 확인하고 실제 동기화 결과도 살펴보세요. 클라우드에서의 표시 여부, 시스템 여유 공간 및 네트워크 상태가 작업에 영향을 줄 수 있으므로 스위치가 켜져 있다는 이유만으로 백업이 완료되었다고 판단하지 마세요. 동기화는 과거 상태를 보관한다는 뜻도 아닙니다. 한 기기에서 삭제한 내용이 이후 다른 기기에도 반영될 수 있습니다. 삭제 전 상태를 보존하려면 별도 사본을 저장하고 현재 정리 작업에 따라 사본까지 변경되지 않는지 확인하세요.

삭제 전에 소속과 영향을 확인하세요

서버 하나를 삭제하기 전에 구독에 속한 항목인지, 현재 사용 중인지 확인하세요. 구독에 포함된 항목은 기기에서 제거해도 다음 업데이트 때 다시 나타날 수 있습니다. 원격 목록을 영구적으로 바꾸려는 목적이라면 기기에서 항목을 삭제하는 것만으로 구독 응답을 바꿀 수는 없습니다. 구독 전체를 삭제하면 영향 범위가 더 클 수 있으므로 관련 기록과 현재 선택 항목을 확인한 뒤 안내를 살펴보고 진행하세요. 이름이 비슷한 항목 하나를 숨기려다가 전체 그룹을 삭제하지 않도록 주의하세요.

독립 서버를 정리할 때는 필요한 매개변수 사본을 먼저 보관한 다음 Config에서 관련 정책 또는 이름을 참조하는지 확인하세요. 이름과 정책의 관계는 실제 설정을 기준으로 확인해야 합니다. Home 목록이 깔끔해 보인다는 이유만으로 판단하지 마세요. 삭제한 후 현재 선택 항목과 라우팅 경로를 다시 확인하고, 필요한 경우 유효한 기록을 선택해 새 요청을 테스트하세요. 기록을 비활성화하는 것이 목적이라면 완전히 지우기보다 쉽게 복원할 수 있도록 표시한 백업을 남기는 편이 유용합니다.

새 기기에서는 순서대로 복원하고 확인

새 기기로 옮길 때는 먼저 구매 항목 복원 안내에 따라 App Store에서 Shadowrocket을 받은 뒤 본인 데이터를 복원하세요. 앱 구매 기록과 연결 정보는 서로 다른 항목입니다. 앱을 복원해도 구독, 서버 및 Config가 모두 돌아오는 것은 아닙니다. 시스템 요구 사항과 구매 가능 여부는 App Store 페이지에 표시된 내용을 기준으로 합니다. 새 기기에서 처음 연결할 때 시스템에 VPN 구성 승인을 요청하는 메시지가 표시되면 안내에 따라 처리하세요. 승인 팝업을 구독 확인이 완료되었다는 뜻으로 오해하지 마세요.

기존 원본 자료를 기준으로 복원하는 것이 좋습니다. 먼저 구독 주소와 개별 매개변수가 유효한지 확인하고, 서버 기록과 Config를 복원한 다음 Global Routing, DNS 및 On Demand 등 관련 설정을 점검하세요. 각 단계를 복원할 때마다 확인하면 비슷한 백업을 한꺼번에 가져온 뒤 현재 활성화된 항목이 무엇인지 혼동하지 않을 수 있습니다. 이전 기기를 계속 사용할 수 있다면 새 기기에서 목록, 연결 및 대상 접속을 모두 확인할 때까지 기존 상태를 그대로 보관해 비교 기준으로 삼으세요.

복원 후 항목이 빠져 있다면 데이터가 손상되었다고 바로 판단하지 말고 백업 범위와 선택한 파일을 먼저 확인하세요. 항목은 모두 있는데 연결할 수 없다면 매개변수 및 테스트 항목으로 이동합니다. 원격에서 구독 인증 정보가 변경된 경우 오래된 백업에는 이전 값만 복원되므로 현재 유효한 자료에 따라 업데이트해야 합니다. 동기화, 내보내기 및 기기 이전에 대한 자세한 내용은 설정 백업 및 새 기기 이전 안내를 참고하세요. 완료 후 복원한 항목을 기록하고 더 이상 필요하지 않은 임시 사본은 안전하게 정리하세요.