Shadowrocket
구독 및 서버 관리

Subscribe: 구독 저장 및 최초 가져오기

먼저 보유한 정보의 종류를 확인하세요

구독은 서버 목록을 가져오는 데 사용하는 업데이트 주소입니다. 개별 서버 주소나 Config의 규칙 파일과는 다릅니다. 작업을 시작하기 전에 가지고 있는 정보가 구독 주소인지, 단일 공유 링크인지, 별도의 서버 매개변수인지 확인하세요. https://로 시작한다고 해서 반드시 구독 주소인 것은 아닙니다. 안내 페이지 주소일 수도 있으므로, 정보와 함께 제공된 용도 설명을 기준으로 판단하세요. 구독 주소에는 계정을 식별하는 매개변수가 포함될 수 있습니다. 복사할 때는 전체 경로와 쿼리 문자열을 보존하고, 공개 게시판에는 공유하지 마세요.

Home에서 추가 메뉴를 열어 Subscribe를 찾으세요. 일부 화면에서는 먼저 Add Server를 연 다음 Type에서 Subscribe를 선택해야 합니다. 보유한 구독 주소 전체를 URL 입력란에 붙여 넣고 알아보기 쉬운 메모를 입력한 뒤 저장하세요. 메모는 출처를 구분하기 위한 것으로, 원격 서버 이름이나 인증 정보, 업데이트 권한에는 영향을 주지 않습니다. 추가 옵션이 표시되더라도 용도를 알고 있는 경우가 아니라면 최초 가져오기 시에는 기본값을 유지하세요. 구독 주소를 보기 좋게 만들려고 끝부분의 매개변수를 임의로 바꾸지 마세요.

주소 저장과 목록 가져오기를 따로 확인하세요

저장에 성공했다는 것은 구독 항목이 로컬에 기록되었다는 뜻일 뿐, 사용할 수 있는 목록을 가져왔다는 의미는 아닙니다. 저장한 뒤 Home에서 해당 구독에 속한 서버가 표시되는지 확인하세요. 자동으로 가져오지 않았다면 해당 항목의 업데이트 기능을 사용하세요. 결과를 확인할 때는 구독 항목이 남아 있는지, 업데이트 오류가 표시되는지, 목록에 서버가 추가되었는지 차례로 살펴보세요. 메모는 보이는데 목록이 비어 있다면 주소는 저장됐지만 네트워크 요청, 계정 권한 또는 응답 내용을 확인해야 할 가능성이 큽니다. 이때 같은 구독을 다시 추가하면 중복 항목만 생기고 기존 요청 문제는 해결되지 않는 경우가 많습니다.

복사 과정의 오류는 최초 가져오기가 실패하는 흔한 원인입니다. 링크 앞뒤의 공백, 채팅 앱이 삽입한 줄바꿈, 전각 문장 부호, 화면에 보이는 일부만 선택한 경우 모두 요청 결과에 영향을 줄 수 있습니다. 다시 복사할 때는 잘려서 표시된 문자를 보고 주소를 직접 보완하지 말고 원본 텍스트에서 전체 주소를 가져오세요. 주소에 &, ? 또는 퍼센트 인코딩이 포함되어도 불필요한 기호로 보고 삭제하지 마세요. 문제를 기록할 때는 요청 결과와 발생 단계를 적으면 충분합니다. 스크린샷을 공유해야 한다면 구독 주소 전체와 계정 식별 정보를 먼저 가리세요.

목록을 가져온 다음 연결 상태를 확인하세요

서버가 표시되면 항목 하나를 선택하고 Global Routing 및 현재 Config를 확인하세요. 서버 목록은 ‘어디에 연결할지’를 정하고, 규칙 설정은 ‘어떤 트래픽이 그 연결을 사용할지’를 정하므로 각각 확인해야 합니다. 첫 연결을 확인할 때는 이미 알고 있는 항목 하나와 명확하게 선택된 Config 하나만 사용하고, 여러 설정을 동시에 변경하지 마세요. Subscribe 업데이트는 성공했는데 웹페이지에 접근할 수 없다면 서버 연결과 규칙을 추가로 확인하세요. 곧바로 구독 주소의 문제라고 단정해서는 안 됩니다. 반대로 업데이트는 실패했지만 기존 서버에 연결할 수 있다면 업데이트 주소에 일시적으로 접근할 수 없는 상황일 수도 있습니다.

구독을 가져왔다고 해서 모든 항목이 현재 네트워크에 적합하거나 매개변수가 동일하다는 뜻은 아닙니다. 먼저 목록을 가져오고 연결 테스트를 한 뒤 정기 업데이트를 사용할지 결정하세요. 이렇게 하면 ‘구독 요청 실패’, ‘서버 핸드셰이크 실패’, ‘규칙이 적용되지 않음’을 별개의 문제로 나눠 확인할 수 있습니다. 첫 연결을 완료하지 못했다면 사용 가이드로 돌아가 단계별로 확인하세요. 연결은 되지만 Global Routing을 조정해야 한다면 설정 안내를 참고해 규칙 문제를 다시 가져오기 문제로 처리하지 않도록 하세요.

Add Server: 서버 필드 직접 입력

먼저 Type을 선택한 다음 주소와 인증 정보를 입력하세요

Add Server는 서버 항목 하나를 추가하는 기능입니다. 화면을 열면 먼저 Type을 선택하고 해당 프로토콜에 필요한 필드를 입력하세요. 같은 이름의 필드라도 프로토콜에 따라 의미가 다를 수 있으므로 다른 항목을 참고해 먼저 입력한 뒤 Type을 임의로 바꾸면 안 됩니다. Address에는 일반적으로 호스트 이름이나 IP 주소를 입력하며 웹페이지 경로는 포함하지 않습니다. Port에는 해당 포트를 입력하고, 주소와 포트를 함께 Address에 넣지 마세요. 메모에는 식별하기 쉬운 문구를 사용할 수 있지만, 연결 매개변수는 대소문자와 구분 기호, 특수 문자를 포함해 보유한 정보 그대로 입력해야 합니다.

인증 필드는 해당 프로토콜의 구성에 맞춰 이해해야 합니다. Shadowsocks에서는 Method와 Password가 서로 맞아야 합니다. VMess와 VLESS에서는 UUID를 사용하는 경우가 많습니다. Trojan의 Password는 다른 식별자처럼 보여도 UUID 필드에 입력하면 안 됩니다. WireGuard는 키, 주소와 피어 매개변수가 필요하므로 서버 도메인만으로 입력을 완료할 수 없습니다. 필요한 정보가 없다면 먼저 원래 서버 정보를 확인하세요. 다른 프로토콜에서 흔히 사용하는 기본값으로 대신 입력해서는 안 됩니다. 화면에 어떤 필드가 비어 있다고 해서 현재 서버에서도 해당 값을 생략해도 된다는 뜻은 아닙니다.

연결 주소, TLS와 전송 매개변수를 구분하세요

TLS의 서버 이름, 전송 계층의 Host, 실제 연결 Address는 서로 같을 수도 다를 수도 있습니다. 각 필드는 서로 다른 단계에서 사용됩니다. Address는 연결 대상을 찾고, SNI는 TLS 핸드셰이크에 사용되며, Host와 Path는 애플리케이션 계층 전송에 사용될 수 있습니다. 세 곳 모두 도메인을 입력할 수 있다고 해서 하나로 합치지 마세요. Path의 슬래시와 끝 문자, 대소문자도 서버 측 라우팅에 영향을 줄 수 있습니다. 자료에 전체 공유 링크가 있다면 다음 장의 방법으로 먼저 가져온 뒤 해석된 필드를 확인하세요. 링크 모양만 보고 매개변수를 추측하는 것보다 정확합니다.

인증서 또는 핸드셰이크 오류가 발생하면 시스템 시간, SNI, TLS 설정과 서버 포트를 먼저 확인한 다음 원본 정보가 변경되었는지 살펴보세요. 인증서 검증을 건너뛰는 방법을 일반적인 해결책으로 사용하지 마세요. 이 설정은 서버 신원 확인 조건을 바꾸므로, 일시적으로 연결에 성공하더라도 입력 오류가 해결됐다는 뜻은 아닙니다. 전송 방식도 서버 측 설정과 일치해야 합니다. TLS를 켠다고 잘못된 Host, Path 또는 Type이 자동으로 해결되지는 않습니다. 확인된 필드 하나씩만 수정하고 변경 전 값을 기록해야 어떤 항목이 결과에 영향을 주었는지 알 수 있습니다.

저장한 뒤 항목 하나씩 검증하세요

항목을 저장한 뒤 Home으로 돌아가 방금 만든 서버가 선택되었는지 확인하세요. 목록에 이름이 같은 이전 항목이 있을 수 있습니다. 다음으로 연결을 테스트하고 결과를 이름 해석 실패, 연결 설정 실패, 인증 실패, 연결 후 접근 문제로 나눠 기록하세요. 오류에 따라 확인 순서가 달라집니다. 도메인을 확인할 수 없다면 Address를, 연결 시간 초과라면 포트와 네트워크 접근성을, 인증 실패라면 비밀번호나 UUID를 중점적으로 확인하세요. 연결은 됐지만 일부 접근에 문제가 있다면 Config, DNS와 대상 서비스를 살펴보세요. 실패 결과 하나만 보고 모든 매개변수를 다시 입력하지 마세요.

수동으로 추가한 항목은 일반적으로 구독 업데이트와 함께 자동으로 동기화되지 않습니다. 원격 비밀번호나 주소가 바뀌었다면 원본 정보를 바탕으로 직접 관리하거나 기존 구독 주소를 다시 가져오세요. 메모에 ‘수동’ 또는 ‘구독’이라고 표시해 구분하면 좋지만, 비밀번호, UUID 또는 개인 키는 목록 스크린샷에 노출될 수 있으므로 메모에 쓰지 마세요. VMess와 VLESS의 개념적 차이는 프로토콜 필드 안내를 참고하세요. 차이를 이해하는 목적은 정확히 입력하기 위한 것이며, 프로토콜 이름만으로 서버의 실제 사용 가능 여부를 추측하기 위한 것이 아닙니다.

QR 코드 및 클립보드: 가져올 항목 확인

Scan QR Code는 내용을 읽는 기능입니다

QR 코드는 텍스트를 전달하는 방식이지 새로운 프록시 프로토콜이 아닙니다. Scan QR Code로 읽은 내용은 단일 서버 공유 링크일 수도 있고 구독 주소나 일반 웹 주소일 수도 있습니다. 스캔하기 전에 QR 코드가 보유한 서버 정보에서 나온 것인지 확인하고, 서버 하나를 추가하려는지 업데이트 가능한 구독을 추가하려는지 파악하세요. 스캔 후 확인 화면이 나타나면 Type, Address 또는 URL 등 주요 정보를 살펴본 다음 저장 여부를 결정하세요. 카메라로 QR 코드를 읽을 수 있다는 이유만으로 Shadowrocket에서 바로 가져올 수 있는 내용이라고 단정하지 마세요.

스캔 기능을 처음 사용할 때 시스템에서 카메라 권한을 요청할 수 있습니다. 권한을 거부하면 카메라로 스캔할 수 없지만 QR 코드 자체가 손상된 것은 아닙니다. 필요하다면 시스템 설정에서 권한을 변경하세요. QR 코드가 현재 기기 화면에 있다면 사진에서 읽는 기능을 지원하는지 먼저 확인하세요. 해당 옵션이 없다면 같은 자료에 포함된 텍스트 링크를 사용하는 편이 간편합니다. 읽기 문제를 해결하려고 구독 인증 정보가 포함된 이미지를 출처를 알 수 없는 인식 서비스에 업로드하지 마세요. QR 코드 스크린샷도 인식하면 전체 주소나 인증 정보가 복원될 수 있으므로 민감한 정보로 관리해야 합니다.

클립보드에서 가져오기 전에 주변 문구를 제거하세요

클립보드에서 가져올 때는 링크 자체만 복사하고 ‘여기를 클릭하세요’, ‘서버 정보’ 같은 안내 문구는 함께 복사하지 마세요. 채팅 기록의 링크에는 마침표, 괄호 또는 줄바꿈이 덧붙을 수 있습니다. 일부 앱에서는 링크가 축약되어 보이고, 길게 눌러 복사하면 안내 페이지 주소가 복사될 수도 있습니다. 가져오기에 반응이 없다면 복사한 내용의 시작 부분이 예상한 형식과 일치하는지, 불필요한 문구가 섞이지 않았는지 확인하세요. 시스템에서 붙여넣기를 허용할지 묻는다면 본인의 작업 의도에 맞게 선택하세요. 거부한 뒤 다시 시도할 때는 시스템 권한 상태도 확인해야 합니다.

여러 줄의 내용이 한 번에 여러 서버로 인식되는 것은 아닙니다. 가져온 결과가 하나뿐이라면 원본 텍스트에 독립된 공유 링크가 여러 개 있는지, 아니면 하나의 긴 링크가 화면에서 여러 줄로 표시된 것인지 확인하세요. 먼저 링크 하나를 가져와 올바르게 해석되는지 확인한 다음 나머지를 처리할 수 있습니다. 여러 줄의 텍스트를 임의로 한 줄로 이어 붙이거나 각 줄에 프로토콜 접두사를 추가하지 마세요. 일괄 가져오기 후에는 항목의 소속과 메모를 하나씩 확인하세요. 같은 내용을 여러 번 복사하면 중복 항목이 생겨 이후 테스트에서 서로 다른 서버로 오인할 수 있습니다.

‘읽기, 해석, 저장’ 단계별로 문제를 확인하세요

스캔했지만 내용을 읽지 못했다면 읽기 단계의 문제입니다. 화면의 선명도, QR 코드가 온전한지, 권한을 우선 확인하세요. 텍스트는 읽었지만 형식이 지원되지 않는다고 표시된다면 해석 단계의 문제이므로 링크 유형과 현재 가져오기 기능을 확인해야 합니다. 항목이 만들어졌지만 연결에 실패했다면 매개변수와 서버 접근성을 확인하세요. 이 세 단계를 구분하면 매개변수는 확인하지 않은 채 스캔 방법만 반복해서 바꾸는 일을 줄일 수 있습니다. QR 코드 가장자리가 잘렸거나 이미지 압축으로 모듈이 흐려져도 인식에 문제가 생깁니다. 저화질 스크린샷을 반복 촬영하기보다 원본 이미지를 확대해 보세요.

가져온 뒤에는 필드를 다시 확인해야 합니다. 서버 유형, 호스트 이름, 포트와 전송 설정이 기존 정보와 일치하는지, 항목이 예상한 위치에 표시되는지 확인하세요. 구독을 가져오려 했는데 서버 하나만 생성되었다면 QR 코드에 단일 공유 링크가 담겨 있지는 않았는지 확인하세요. Subscribe 항목이 생성됐는데 목록이 비어 있다면 계속 스캔하지 말고 구독 업데이트 문제를 확인하세요. 단일 링크와 구독 주소의 차이는 공유 링크와 구독 링크 안내에서도 확인할 수 있습니다.

같은 정보를 QR 코드와 클립보드로 각각 가져왔다면 원칙적으로 동일한 매개변수가 생성되어야 합니다. 결과가 다르면 원본 텍스트가 같은지 먼저 비교한 다음 이전 클립보드 내용이 섞였는지 확인하세요. 메모만 보고 두 항목이 같은지 판단하지 마세요. 메모는 바뀔 수 있지만 연결을 결정하는 것은 프로토콜 필드입니다. 확인이 끝날 때까지 항목 하나를 보류 상태로 남겨 두고 검증 후 중복 항목을 정리하는 편이, 사용 중인 항목을 곧바로 덮어쓰는 것보다 안전합니다.

공유 링크: 접두사, 인코딩 및 Config 구분

접두사는 형식 식별에 도움을 주지만 매개변수 확인을 대신하지 않습니다

ss://, vmess://, vless://, trojan://은 일반적으로 서버 하나의 정보를 나타냅니다. 각 형식은 주소, 인증 정보와 전송 설정을 서로 다른 구조로 담으므로 접두사만 바꿔 프로토콜을 변환할 수 없습니다. HTTP 또는 HTTPS 주소는 구독 내용이나 일반 웹페이지를 가리킬 수 있습니다. 링크를 클릭할 수 있다는 이유만으로 Subscribe로 저장하지 말고, 원본 자료의 설명과 실제 응답 내용을 함께 확인하세요. 형식에 따라 구현 규칙이 다를 수 있으므로 접두사를 인식한다고 모든 확장 필드까지 보존되는 것은 아닙니다.

Shadowsocks 공유 링크는 인증 정보 일부 또는 더 넓은 범위의 내용을 인코딩할 수 있습니다. VMess는 인코딩된 JSON 설명을 사용하는 경우가 많고, VLESS와 Trojan은 쿼리 매개변수가 포함된 URI 구조를 사용하는 경우가 많습니다. 일반 사용자가 직접 디코딩하는 것보다 전체 내용을 복사하고 맞는 기능으로 가져온 다음 해석 결과를 확인하는 것이 중요합니다. 직접 디코딩했다가 다시 인코딩하면 특수 문자가 바뀌거나 패딩이 누락되고 퍼센트 인코딩이 중복 적용될 수 있습니다. 특정 필드를 확인해야 한다면 기기에서 직접 열어 기존 정보와 비교하세요. 전체 링크를 출처를 알 수 없는 온라인 도구에 입력하지 마세요.

메모, 쿼리 매개변수와 인코딩 문자에는 각각 용도가 있습니다

URI의 쿼리 매개변수에는 전송 방식, Path, Host 또는 다른 연결 설정이 포함될 수 있습니다. 조각 부분은 메모로 사용되는 경우가 많지만 구체적인 용도는 해당 형식의 규칙을 따릅니다. 메모에 한국어가 있으면 원본 링크에서 퍼센트 인코딩되어 있을 수 있으며, 가져온 뒤 읽을 수 있는 문자로 표시되는 것은 정상입니다. 문제를 확인할 때 퍼센트 인코딩된 부분을 모두 한국어로 바꿔 붙여 넣지 마세요. 매개변수 안의 연결 기호도 서식 기호로 보고 바꾸면 안 됩니다. 문서 편집기나 채팅 앱을 통해 링크를 전달했다면 반각 따옴표가 바뀌었는지, 끝에 문장 부호가 붙었는지, 한 줄이 실제 줄바꿈으로 나뉘었는지 특히 확인하세요.

공유 링크에는 민감한 정보가 포함될 수 있습니다. 화면에는 짧은 메모만 보이더라도 전체 링크에 비밀번호, UUID 또는 다른 인증 정보가 들어 있을 수 있습니다. QR 코드와 공유 기능도 이러한 내용을 다른 방식으로 전달할 뿐입니다. 본인의 다른 기기로 링크를 복사하기 전에 전달 경로와 수신 대상을 확인하고, 완료 후 임시 파일을 필요에 따라 삭제하세요. 형식 문제를 알릴 때는 주소와 인증 정보를 예시 값으로 바꾸고 프로토콜 접두사, 필드 이름과 오류 메시지만 제공할 수 있습니다. 메모 일부를 가려도 실제 연결 인증 정보까지 숨겨지는 것은 아닙니다.

서버 링크와 Config 규칙 파일은 다릅니다

서버를 가져온 뒤 Global Routing에서 Config를 선택하면 현재 규칙에 따라 트래픽 경로가 결정됩니다. 아래는 매칭 순서를 설명하기 위한 실제 규칙 문법이며, 연결 가능한 서버 매개변수나 구독을 생성하지 않습니다. 규칙은 일반적으로 위에서 아래 순서로 매칭되며, 마지막의 FINAL은 앞에서 일치하지 않은 트래픽을 처리합니다. PROXY와 DIRECT는 정책을 뜻하므로 서버 도메인으로 오인하지 마세요. Config를 편집하기 전에 원본 파일을 저장하고 현재 설정에서 사용하는 정책 이름을 확인하세요.

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

규칙을 Subscribe의 URL 입력란에 붙여 넣어도 구독이 되지 않습니다. 서버 공유 링크를 규칙 행에 직접 입력해도 해당 정책이 자동으로 생성되지 않습니다. 서버, 구독과 규칙은 각각 따로 관리해야 하며, 문제를 해결할 때 이 경계를 지키는 것이 중요합니다. Config, Proxy, Direct가 실제 트래픽에 미치는 영향을 알아보려면 Global Routing의 세 가지 모드 안내를 읽은 다음 현재 서버를 다시 확인하세요.

업데이트 설정: 요청 결과와 목록 변경

구독 업데이트는 앱 업데이트도 갱신도 아닙니다

Subscribe 업데이트는 기존 주소에 다시 요청을 보내고 응답 내용에 따라 서버 목록을 새로 고칩니다. 앱을 업데이트하거나 서비스 계정의 유효 상태를 변경하는 기능은 아닙니다. 앱의 다운로드 및 업데이트 경로는 다운로드 안내를 확인하세요. 구독 내용을 계속 가져올 수 있는지는 기존 주소, 계정 권한과 네트워크 상태에 따라 달라집니다. 이 차이를 이해하면 업데이트 실패 시 앱 재설치를 먼저 시도하지 않게 됩니다. 현재 구독을 요청할 수 있는지, 기존 서버에 연결할 수 있는지 기록한 다음 확인할 항목을 정하세요.

업데이트 습관을 만들 때는 먼저 수동 업데이트를 한 번 실행해 주소에서 목록을 정상적으로 받을 수 있는지 확인하세요. 그다음 현재 화면에서 제공하는 설정을 살펴보고 자동 업데이트를 사용할지 결정합니다. 업데이트 빈도만 높이는 것이 항상 좋은 것은 아닙니다. 서버 목록이 바뀌지 않았다면 잦은 요청이 연결을 개선하지 않으면서 문제 확인만 복잡하게 만들 수 있습니다. 오랫동안 사용하지 않았거나 기존 정보가 변경된 것을 알고 있거나 여러 항목이 작동하지 않을 때는 먼저 수동 업데이트를 한 번 실행하세요. 기기 절전, 백그라운드 제한과 네트워크 전환은 예약 작업에 영향을 줄 수 있으므로 자동 업데이트를 설정했다고 해서 언제나 정확한 시각에 실행되는 것은 아닙니다.

오류가 발생한 단계에 따라 확인 순서를 정하세요

요청이 시간 초과되면 현재 네트워크와 구독 도메인에 접근할 수 있는지 먼저 확인하세요. 인증 또는 접근 권한 오류가 나면 전체 URL과 계정 상태를 확인하세요. 응답을 해석할 수 없다면 서버 목록을 받은 것인지, 안내 페이지·로그인 페이지 또는 다른 응답을 받은 것인지 판단해야 합니다. 응답에 내용이 있다는 것만으로 충분하지 않습니다. 브라우저에서 웹페이지가 열린다고 해서 Shadowrocket이 해석할 수 있는 구독 형식이라는 뜻은 아닙니다. 가져온 뒤 첫 업데이트에서 오류가 발생했다면 선택 옵션을 계속 변경하기보다 원본 자료에서 전체 주소를 다시 복사하는 편이 효과적입니다.

업데이트 요청은 기존 프록시 연결에 영향을 받을 수도 있습니다. 현재 네트워크에서 특정 구독 주소에 접근할 수 없지만 기존 서버 연결은 가능한 경우, 통제된 조건에서 연결 전후의 요청 결과를 비교할 수 있습니다. 하지만 모든 플랫폼의 구독 요청이 반드시 같은 경로를 거친다고 가정하지 마세요. 비교하려면 당시 연결 여부, Global Routing 모드와 선택된 서버를 기록해야 합니다. 여러 설정을 기록 없이 계속 전환하면 우연히 문제가 해결된 것을 관련 없는 설정의 효과로 오해하기 쉽습니다.

업데이트 후 소속, 개수 및 선택 상태를 확인하세요

업데이트 후 서버 목록에 항목이 추가되거나 줄고 이름이 바뀌어도 반드시 로컬 데이터가 손상된 것은 아닙니다. 응답 내용이 변경되었을 수 있습니다. 먼저 해당 구독 그룹에서만 변경이 발생했는지 확인한 다음 현재 선택된 서버가 여전히 있는지 살펴보세요. 이전 항목이 교체됐다면 기억해 둔 이름만으로 같은 대상을 찾기 어려울 수 있습니다. 중요한 작업 전에 선택 항목의 이름과 프로토콜 유형을 기록할 수 있지만 전체 매개변수를 공개하지 마세요. 정렬이나 업데이트로 위치가 바뀔 수 있으므로 목록의 순서만 기억해 서버를 찾지 마세요.

업데이트 후 목록이 비어 있다면 연속해서 다시 시도하지 말고 오류 메시지를 보존한 뒤 기존 연결에도 영향을 주었는지 확인하세요. 가져오기 및 업데이트 방식에 따라 이전 내용의 처리 방법이 다를 수 있으므로 실패하면 모든 항목이 반드시 남는다고 가정하거나 빈 목록이 원격에 서버가 없다는 뜻이라고 단정하지 마세요. 먼저 응답이 유효했는지 확인한 뒤 백업을 복원하거나 다시 가져올지 결정하세요. 다른 구독은 정상인데 하나만 문제가 있다면 해당 구독과 요청 조건으로 문제 범위를 좁히고 모든 출처를 한꺼번에 삭제하지 마세요.

구독으로 생성된 항목을 직접 수정할 때는 다음 업데이트에서 변경 사항이 덮어써질 수 있다는 점을 고려해야 합니다. 임시 수정이 꼭 필요하다면 화면에서 지원하는 경우 이유를 기록한 별도 복사본을 명확히 표시해 사용하세요. 임시 값을 구독 주소에 입력하지 마세요. 원본 정보가 복구되면 임시 복사본을 정리해 나중에 오래된 매개변수를 정식 관리 정보로 오인하지 않도록 하세요. 다음 장에서 복사본과 여러 구독의 이름을 정리하는 방법을 안내합니다.

여러 구독 정리: 소속, 이름 및 규칙 관계

먼저 출처별로 나눈 뒤 그룹 안에서 항목을 구분하세요

구독이 여러 개라면 모든 서버를 한데 모으기보다 각 항목의 출처를 추적할 수 있게 정리하는 것이 우선입니다. 용도나 자체 번호를 기준으로 구독에 짧고 일관된 메모를 지정하고, 업데이트 후에도 대조할 수 있도록 서버 이름은 가급적 원래대로 유지하세요. 두 구독에서 같은 이름의 서버가 생성되면 이름만 보고 하나를 삭제하지 말고 그룹 소속과 실제 매개변수를 확인하세요. 서로 다른 출처에 같은 이름이 있다고 해서 연결 주소나 인증 정보까지 같다는 뜻은 아닙니다.

정리할 때는 구독 항목, 구독에 속한 서버, 수동으로 추가한 항목 순서로 살펴보세요. 업데이트로 관리되는 항목과 직접 만든 독립 항목을 구분한 뒤 이름을 바꾸거나 삭제할지 결정하세요. 이름에는 용도와 관리 방식을 표시하고 민감한 정보는 넣지 않는 것이 좋습니다. 예를 들어 ‘수동 테스트’라고 표시하면 항목의 성격을 알 수 있지만, 전체 비밀번호, UUID 또는 구독 매개변수를 목록 메모에 써서는 안 됩니다. 화면에서 사용자 지정 그룹을 지원하지 않더라도 구독 메모와 별도 기록을 이용해 소속을 관리할 수 있습니다. 모든 플랫폼에 같은 정리 메뉴가 있다고 가정하지 마세요.

표시 이름이 아닌 매개변수를 기준으로 중복을 확인하세요

중복 여부는 프로토콜 유형, 주소, 포트, 인증 정보와 전송 설정을 함께 비교해야 합니다. 같은 도메인에 연결되더라도 포트나 전송 방식이 다를 수 있고, 메모가 서로 다른 두 항목도 같은 정보를 두 번 가져온 결과일 수 있습니다. 먼저 주요 필드를 비교한 뒤 남길 항목을 정하세요. 구독에서 생성된 항목이라면 서버 항목 하나만 삭제해도 다음 업데이트 때 다시 생길 수 있으므로 중복 구독 출처를 먼저 정리하세요. 그러면 업데이트할 때마다 같은 항목을 직접 삭제하지 않아도 됩니다.

목록을 깔끔하게 만들려고 오래된 항목을 한꺼번에 모두 삭제하지 마세요. 중복이 확인된 항목을 먼저 표시하고 현재 사용 가능한 서버를 남겨 두세요. 구독 업데이트와 연결 검증을 한 번 마친 뒤 정리해도 됩니다. 중복 여부를 확신할 수 없는 항목은 바로 삭제하기보다 하나씩 테스트하는 편이 좋습니다. 같은 구독을 두 번 가져왔다면 메모만 다른 것인지 판단하기 전에 두 URL이 완전히 같은지 확인하세요. 구독 주소의 쿼리 매개변수에 따라 반환 내용이 달라질 수 있으므로 도메인과 경로만 비교해 같다고 판단해서는 안 됩니다.

서버 선택과 규칙 정책을 별도로 관리하세요

Home에서 선택한 서버는 Config의 정책 참조와 관련이 있지만, 목록 정리가 규칙 조정을 뜻하지는 않습니다. Global Routing이 Proxy이면 테스트 결과가 선택된 프록시 연결을 더 직접적으로 반영합니다. Config에서는 대상 트래픽이 규칙에 따라 DIRECT로 연결될 수 있으므로 웹페이지가 열렸다는 사실만으로 현재 서버가 해당 연결에 사용되었다고 볼 수 없습니다. 정리 후 서버 하나를 검증하려면 명확한 테스트 절차를 따르고, 작업을 마친 뒤 일상적인 모드로 복원하세요. 문제 확인을 위한 임시 상태를 계속 유지하지 마세요.

Config에서 특정 서버나 정책 그룹 이름을 참조한다면 이름을 바꾸기 전에 관련 참조를 확인하고, 변경 후 다시 테스트하세요. 목록에서 이름을 바꿔도 Config의 문자열 참조가 함께 바뀌지 않을 수 있습니다. 정리할 항목이 많다면 ‘구독 하나, 변경 한 묶음, 검증 한 번’ 순서로 진행하세요. 현재 그룹을 완료한 뒤 다음 그룹을 처리하면 문제가 생겼을 때 범위를 좁히기 쉽습니다. Config 규칙 설정은 설정 페이지에서 확인할 수 있습니다. 목록을 정리하기 위해 Config 전체를 다시 만들 필요는 없습니다.

여러 기기에서 사용할 때는 구독 메모의 작성 방식을 통일하되 목록 순서가 같을 것이라고 기대하지 마세요. 각 기기의 정렬, 캐시된 테스트 결과와 마지막 선택 항목은 서로 다를 수 있으므로 기기를 옮긴 뒤 소속과 선택 항목을 다시 확인해야 합니다. 관리용 간단한 목록에는 구독 이름, 관리 방식과 용도만 기록하고 전체 주소는 접근이 제한된 백업에 보관하세요. 이렇게 하면 목록 구성을 설명할 수 있고 특정 기기에서 문제가 생겼을 때 복원할 부분을 찾기 쉽습니다.

지연 시간 테스트 및 정렬: 결과를 확인한 뒤 선택하세요

Connectivity Test로 확인할 수 있는 것은 제한적입니다

Connectivity Test는 현재 테스트 조건에서 연결 상태를 확인하는 기능입니다. 결과는 기기 네트워크, 테스트 방식, 대상 주소, 서버 핸드셰이크와 순간 부하의 영향을 받습니다. 다운로드 속도와 동일한 수치가 아니며 모든 앱의 접근 가능성을 보장하지도 않습니다. 테스트 방식에 따라 측정 단계가 다를 수 있습니다. 연결 설정 단계만 확인하는 방식도 있고 실제 요청까지 포함하는 방식도 있습니다. 비교하기 전에 모든 항목이 같은 테스트 방식과 비슷한 네트워크 조건을 사용하는지 확인하세요. 시간과 네트워크가 다른 결과를 안정적인 성능 순위처럼 직접 비교하지 마세요.

테스트 전에 평소 사용 환경을 대표하는 네트워크를 선택하고 대량 전송 작업을 잠시 멈춰 간섭을 줄이세요. 모바일 네트워크에서 Wi-Fi로 막 전환했다면 시스템의 네트워크 상태가 안정될 때까지 기다린 뒤 테스트를 시작하세요. 일괄 테스트는 짧은 시간에 많은 연결을 만들 수 있습니다. 항목이 많다면 나누어 실행해 한꺼번에 너무 많은 요청이 로컬 네트워크나 원격 응답에 영향을 주지 않도록 하세요. 항목 하나가 처음 시간 초과되었다고 곧바로 삭제하지 말고 다시 테스트해 같은 그룹의 다른 항목과 비교하세요.

실패 결과를 단일 항목, 그룹 및 전체 문제로 나눠 확인하세요

항목 하나만 실패하면 해당 항목의 프로토콜, 포트, 인증과 전송 필드를 먼저 확인하세요. 한 구독에 속한 여러 항목이 동시에 실패하면 구독이 업데이트되었는지, 계정 상태가 바뀌었는지, 항목들이 같은 네트워크 조건을 공유하는지 확인하세요. 모든 항목이 실패하면 기기 네트워크 연결, DNS, 연결 권한과 현재 테스트 설정을 살펴보세요. 이렇게 단계적으로 확인하는 편이 서버를 계속 바꿔 선택하는 것보다 효과적입니다. 테스트는 실패했지만 실제로는 정상 접근된다면 모든 서버 매개변수를 바꾸기보다 테스트 대상에 접근할 수 있는지 확인하세요.

테스트에 성공했는데 실제 접근이 실패한다면 트래픽이 선택한 서버를 실제로 거치는지 추가로 확인해야 합니다. Config의 특정 규칙이 대상 트래픽을 직접 연결하도록 설정했거나 DNS 해석에 별도 문제가 있을 수 있습니다. 현재 설정을 기록한 다음 Proxy와 Direct의 결과를 비교하고 Config로 복원할 수 있습니다. 비교의 목적은 문제 범위를 좁히는 것이지 라우팅 방식을 영구적으로 바꾸는 것이 아닙니다. 연결 스위치가 켜져 있다는 것도 실행 상태의 일부일 뿐입니다. 핸드셰이크가 완료됐는지, 대상 요청이 성공했는지는 실제 접근 결과로 판단해야 합니다.

정렬은 상태를 확인하는 도구이지 자동 관리의 결론이 아닙니다

테스트 결과로 정렬하면 추가로 확인할 만한 항목을 찾는 데 도움이 되지만 목록 상단에 있다고 모든 작업에 적합한 것은 아닙니다. 지연 시간이 낮다는 것은 특정 응답 구간이 짧다는 뜻이며, 지속적인 전송에는 대역폭, 혼잡도와 대상 서비스도 영향을 줍니다. 한 번 측정한 최솟값만 쫓기보다 반복 테스트의 안정성, 실제 접근 결과와 평소 사용 경험을 함께 고려하세요. 정렬한 뒤에는 선택 상태를 확인하세요. 일부 목록은 표시 순서만 바꾸며 클라이언트가 첫 번째 항목으로 자동 전환하지 않습니다.

빈 값, 시간 초과 또는 실패로 표시된 결과도 모두 같은 고정값처럼 처리하면 안 됩니다. 빈 값은 아직 테스트하지 않았다는 뜻일 수 있고, 실패는 일시적인 네트워크 문제일 수 있습니다. 오래된 결과는 다른 네트워크에서 만들어졌을 수도 있습니다. 비교하려면 같은 테스트를 다시 실행하고 환경을 기록하세요. 오래된 결과에 장기적인 의미를 부여하지 마세요. 구독 업데이트 후 추가된 항목도 다시 테스트해야 합니다. 익숙한 그룹에 표시된다는 이유만으로 이전 검증을 통과했다고 생각하지 마세요.

테스트 기록에는 수치를 쌓기보다 실제 증상을 남기는 것이 중요합니다. 예를 들어 ‘같은 네트워크에서 핸드셰이크 오류가 연속 발생’, ‘구독 업데이트는 성공했지만 특정 항목 연결 시간 초과’, ‘Direct는 정상, Proxy는 실패’와 같은 기록은 다음 점검 방향을 알려줍니다. 공개적으로 문제를 알릴 때는 주소, 인증 필드와 계정 식별 정보를 지우고 모드, 프로토콜 유형과 오류가 발생한 단계만 제공하세요. 첫 연결을 확인하는 전체 절차가 필요하면 사용 가이드의 검증 단계로 돌아가 서버 항목 하나를 기본 상태부터 확인하세요.

삭제 및 백업: 복원 가능한 관리 상태 유지

서버, 구독 및 Config 삭제를 구분하세요

삭제하기 전에 대상을 확인하세요. 서버 하나를 삭제하면 일반적으로 연결 매개변수 하나가 제거됩니다. 구독 항목을 삭제하면 이후 업데이트 관계에 영향을 주고 해당 항목으로 생성된 내용도 함께 처리될 수 있습니다. Config를 삭제하면 규칙과 관련 구성이 제거되며 서버 삭제와는 다릅니다. 플랫폼에 따라 확인 대화상자와 연결 항목 처리 방식이 다를 수 있으므로 기억에 의존해 확인하지 말고 실제 안내를 읽으세요. 특히 여러 구독에 같은 이름의 항목이 있다면 사용 중인 출처를 지우지 않도록 소속을 먼저 확인하세요.

구독에서 생성된 서버는 다음 업데이트 때 다시 나타날 수 있습니다. 따라서 ‘항목을 계속 제거하기’와 ‘잠시 목록을 간단하게 만들기’는 서로 다른 목적입니다. 잠시 사용하지 않을 항목이라면 구독 전체를 삭제할 필요가 없을 수 있습니다. 중복 구독을 더 이상 유지하지 않기로 했다면 다른 구독이 계속 업데이트되는지 먼저 확인한 뒤 중복 출처를 처리하세요. 수동 항목을 삭제하기 전에 원래 매개변수를 다시 찾을 수 있는지 확인하세요. 다시 가져올 수 있는 구독 주소가 없을 수도 있습니다. 정리를 마친 뒤 연결 테스트를 해 현재 선택 항목이 삭제된 서버를 가리키지 않는지 확인하세요.

정보 유형별 백업 목록을 만드세요

목록 스크린샷만으로는 전체 상태를 복원할 수 없습니다. 적어도 구독 주소, 수동 서버 매개변수, Config 파일과 필요한 사용자 지정 설정을 구분해 백업해야 합니다. 구독 주소로 서버 목록을 다시 가져올 수는 있지만 로컬에서 바꾼 메모와 정렬은 보존되지 않을 수 있습니다. 규칙 파일은 트래픽 분할 설정을 복원할 수 있지만 모든 서버의 인증 정보가 포함되어 있다고 볼 수 없습니다. 스크린샷은 화면을 구분하는 데 도움이 되지만 긴 비밀번호, 키 또는 숨겨진 필드를 정확하게 복원할 수 없습니다. 각 백업이 무엇을 포함하는지 먼저 확인한 뒤 기기 이전에 충분한지 판단하세요.

현재 화면에서 내보내기나 백업 기능을 제공한다면 실제 내보내기 범위를 확인하고 생성된 파일에 민감한 정보가 포함되는지 살펴보세요. 파일 이름에 ‘백업’이 있다고 모든 데이터가 저장되었다고 생각해서는 안 됩니다. 비밀번호, UUID, 구독 토큰 또는 WireGuard 개인 키가 포함된 정보는 접근이 제한되고 암호화해 보관할 수 있는 위치에 저장하세요. 공개 앨범, 공유 다운로드 폴더 또는 다른 사람이 읽을 수 있는 문서에는 두지 마세요. 일상적인 관리 목록과 전체 인증 정보 백업은 별도로 보관하는 것이 좋습니다.

복원할 때는 의존 순서에 따라 단계별로 확인하세요

다른 기기로 옮길 때는 먼저 해당 플랫폼의 배포 경로를 통해 Shadowrocket을 설치했는지 확인하세요. 이어서 구독과 수동 서버를 복원하고 Config를 불러온 다음 Global Routing, DNS와 On Demand 등 설정을 확인하세요. 가져온 직후 모든 자동 기능을 켜지 말고, 먼저 확인된 항목 하나에 수동으로 연결한 뒤 규칙을 검증하세요. iPhone / iPad의 시스템 요구 사항은 App Store 페이지에 표시된 내용을 따릅니다. 다른 플랫폼의 다운로드와 설치 허용 절차는 설치 안내에서 확인하세요. 백업 복원 과정에서 설치 문제를 해결하려고 반복 시도하지 마세요.

구독을 복원한 뒤에는 업데이트를 다시 실행하고, 서버를 복원한 뒤에는 연결 테스트를 다시 하며, Config를 복원한 뒤에는 현재 선택 상태를 확인하세요. 이전 기기의 지연 시간 캐시, 정렬과 최근 사용 항목은 새 기기에서 유효한 테스트 결과가 아닙니다. 복원 후 일부 내용만 나타나면 모든 원인을 앱 오류로 돌리지 말고 백업 범위와 가져오기 유형부터 확인하세요. 인증 정보가 변경된 경우에는 현재 정보를 기준으로 삼으세요. 오래된 백업은 이전 상태를 파악하는 데 도움을 줄 뿐, 현재도 연결 권한이 유효하다는 보장은 없습니다.

구독 주소나 인증 정보가 실수로 공개되었다면 로컬 항목만 삭제해도 유출된 정보가 무효화되지는 않습니다. 기존 계정 관리 방법에 따라 해당 인증 정보를 취소하거나 변경한 뒤 클라이언트에 저장된 내용을 업데이트하고, 오래된 백업과 임시 복사본도 정리하세요. 평소 관리 작업을 마치면 어떤 구독을 처리했는지, 어떤 수동 항목을 유지했는지, 어떤 모드로 검증했는지 간단히 기록해 두세요. 기록에 인증 정보를 넣을 필요는 없습니다. 복잡한 로그가 아니더라도 다음 업데이트나 기기 이전 때 현재 상태의 변경 경위를 파악하는 데 도움이 됩니다.

이 페이지에서 안내한 관리 절차는 여기까지입니다. 먼저 정보의 종류를 확인하고 알맞은 기능으로 가져온 뒤 연결을 검증하세요. 필요한 범위에서 업데이트해 목록을 관리하고, 소속과 이름을 정리해 혼동을 줄인 다음 검증을 마친 백업으로 복원 가능성을 확보하세요. 처음부터 진행하려면 빠른 시작 가이드를, 규칙이 연결에 미치는 영향을 확인하려면 설정 안내를 참고하세요. 단일 공유 링크 형식이 궁금하다면 링크 형식 문서에서 확인할 수 있습니다.