Shadowrocket
구독 및 서버 관리

01 / Subscribe

Subscribe: 업데이트 가능한 구독 추가

구독은 반복해서 요청할 수 있는 원격 주소이며, 응답 내용으로 서버 항목을 만듭니다. 개별 서버 공유 링크와는 다르며, 연결 경로를 정하는 Config의 구성 파일과도 다릅니다. 가져오기 전에 보유한 정보가 어떤 유형인지 확인하세요. 서버 여러 개를 가져오는 주소라면 Subscribe를 사용하고, 프로토콜 이름으로 시작하는 단일 공유 링크라면 서버 가져오기로 처리합니다. 웹페이지 주소, 계정 페이지 또는 안내 페이지를 Subscribe에 입력해도 주소가 열린다는 이유만으로 응답 내용을 파싱할 수 있는 것은 아닙니다.

저장 전에 URL과 메모 확인

Home에서 추가 메뉴를 열고 Add Server로 이동한 다음 Type을 Subscribe로 설정하고 구독 URL을 입력하세요. 화면 구성에 따라 목록에서 유형을 선택할 수 있습니다. 저장되는 항목이 임의의 서버 프로토콜이 아니라 Subscribe인지 확인하세요. 메모에는 ‘개인용’이나 ‘예비 테스트’처럼 구독의 용도를 적고, 전체 인증 정보를 기록하지 마세요. 붙여넣은 뒤 URL의 시작과 끝, 물음표와 구분 기호를 확인해 채팅 인용 부호, 줄바꿈 또는 문장 끝 문장 부호가 들어가지 않았는지 살펴보세요. 저장한 뒤 첫 가져오기가 끝날 때까지 기다립니다.

https://example.com/sub?token=xxxx

위 주소는 구조만 보여 주는 예시이며 실제 서비스 주소가 아닙니다. 경로는 리소스를 가리키고, 물음표 뒤에는 쿼리 매개변수가 옵니다. 매개변수 이름과 값은 빠짐없이 유지하고 예시를 보고 실제 주소를 임의로 바꾸지 마세요. 구독 URL은 접근 인증 정보 역할을 하는 경우가 많아, 이를 확인할 수 있는 사람이 관련 서버 정보를 가져갈 수 있습니다. 전체 주소를 공개 스크린샷, 메모 제목 또는 문의 내용에 넣지 마세요. 주소 구조를 설명할 때는 예시 도메인과 가짜 값을 사용하고 문장 부호 위치만 유지하세요.

첫 가져오기 후 확인할 항목

저장 성공과 가져오기 성공은 서로 다른 상태입니다. 먼저 구독 아래에 서버가 표시되는지 확인하고, 항목 유형과 메모, 수량 변화가 예상과 맞는지 살펴보세요. 수량은 로컬 확인용일 뿐 품질을 의미하지 않습니다. 오류가 표시되면 같은 구독을 반복해서 새로 만들지 말고 오류 원문을 기록하세요. 서버가 표시된다고 연결까지 완료된 것은 아닙니다. Home에서 기본 서버를 선택하고 Global Routing을 확인한 뒤 실제 요청으로 검증하세요. 첫 연결의 전체 순서는 시작하기에서 확인할 수 있습니다.

가져오기에 실패하면 주소, 네트워크, 응답 내용 순으로 확인하세요. 먼저 원래 주소와 다시 대조해 인증 정보가 만료되거나 바뀌지 않았는지 확인합니다. 이어 현재 네트워크에서 구독 주소에 접근할 수 있는지 살펴보고, 마지막으로 서버 데이터가 아닌 로그인 페이지나 오류 페이지가 반환된 것은 아닌지 확인하세요. 주소를 확인하려고 낯선 온라인 파싱 도구에 제출하지 마세요. 이 구독만 실패한다면 오류 문구와 발생 조건을 기록하세요. 모든 네트워크 요청에 문제가 있다면 먼저 기기 네트워크를 점검해 같은 네트워크 문제를 여러 구독의 동시 만료로 오해하지 않도록 합니다.

구독 상태와 연결 상태를 따로 관리

구독을 업데이트하면 서버 정보를 다시 가져오지만, 현재 서버가 계속 작동한다는 보장은 없으며 모든 연결 문제를 해결하는 버튼도 아닙니다. 특정 서버가 작동하지 않으면 먼저 같은 구독의 다른 서버와 비교한 뒤 업데이트 여부를 결정하세요. 구독은 원격 목록으로 이어지는 주소를 저장하고, 서버는 연결 매개변수를 저장하며, Global Routing은 요청에서 이 매개변수를 사용하는 방식을 정합니다. 이 세 가지를 구분해야 주소를 수정할지, 서버를 바꿀지, 규칙을 확인할지 판단할 수 있습니다.

02 / Add Server

Add Server: 입력 항목을 하나씩 확인

수동 입력은 완전한 서버 매개변수를 이미 보유했거나, 가져온 결과를 확인해야 하거나, 개별 항목 몇 개만 관리할 때 적합합니다. 먼저 Add Server에서 올바른 Type을 선택한 뒤 해당 유형에 표시되는 항목을 입력하세요. 유형에 따라 매개변수의 의미가 달라집니다. 아무 양식에나 정보를 입력한 뒤 이름을 바꾼다고 프로토콜이 바뀌지는 않습니다. 시작하기 전에 주소, 포트, 인증 정보, TLS와 전송 요구사항을 나눠 기록하세요. 정보가 빠져 있다면 먼저 확인해야 합니다. ‘일반적인 기본값’으로 누락된 항목을 대신하면 저장은 되더라도 핸드셰이크가 완료되지 않을 수 있습니다.

공통 항목 및 인증 항목

Address에는 호스트 이름 또는 IP 주소를 입력하고 Port에는 해당 포트를 입력하세요. 전체 공유 링크를 Address에 넣거나 호스트 이름 뒤에 포트를 중복해서 붙이지 마세요. 프로토콜 접두사가 포함된 URL을 받았다면 먼저 공유 링크인지 항목 안내인지 확인해야 합니다. 메모는 항목을 식별하기 위한 것으로 연결에는 사용되지 않습니다. 인증 항목은 Type에 따라 다릅니다. Password를 사용하는 유형도 있고 UUID를 사용하는 유형도 있으며, 사용자 이름이나 키가 필요한 경우도 있습니다. 인증 값을 복사할 때 대소문자와 구분 기호를 유지하고 앞뒤 공백을 확인하세요. 값을 줄여 가며 시험하지 마세요.

TLS와 전송 방식은 각각 확인

TLS는 해당 연결 계층의 암호화와 인증을 담당하고, 전송 방식은 데이터를 전달하는 방법을 설명합니다. 서로 대체할 수 없습니다. 보유한 정보에서 TLS를 요구한다면 스위치만 켜지 말고 서버 이름 등 관련 항목도 확인하세요. WebSocket 같은 전송을 사용하는 경우 Path와 Host도 확인해야 합니다. Path의 앞쪽 슬래시와 Host의 철자도 요청에 영향을 줄 수 있습니다. 일부 매개변수는 해당 유형을 선택해야 표시됩니다. 표시되지 않은 항목을 메모, 주소 또는 비밀번호 입력란에 임의로 넣지 마세요.

Address, TLS 서버 이름, 전송 계층 Host는 각각 네트워크 연결, 인증서 확인, 요청 라우팅을 담당할 수 있으며, 세 항목의 텍스트가 같다는 보장은 없습니다. 가져온 뒤 값이 서로 달라도 곧바로 같은 도메인으로 통일하지 마세요. 기존 정보에서 명확히 요구하는 경우에만 수정하고, 한 번에 한 항목씩 바꾸세요. 인증서 오류가 발생하면 이름, 기기 시간, 매개변수 누락 여부부터 확인하세요. 검증을 느슨하게 하는 방법을 일반적인 해결책으로 삼지 마세요. 입력 오류를 숨기고 인증의 의미를 약화할 수 있습니다.

저장 후 검증 순서

먼저 알아보기 쉬운 메모를 붙여 테스트 항목 하나를 저장한 뒤 선택하여 연결하는 것이 좋습니다. 저장은 양식이 접수되었다는 뜻일 뿐 주소에 접근할 수 있거나 인증이 통과되거나 전송 방식이 맞는다는 뜻은 아닙니다. Connectivity Test를 확인한 다음 실제 요청을 보내고 일부 대상에서만 실패하는지 살펴보세요. 기본 연결은 정상인데 특정 웹사이트에서 실패한다면 인증 정보를 계속 바꾸지 말고 규칙, DNS 또는 대상의 접근 조건을 확인하세요. 같은 유형의 다른 항목이 정상이라면 항목을 하나씩 비교하되, 공개 문의에 전체 비밀번호나 UUID를 올리지 마세요.

VMess와 VLESS의 항목 차이는 UUID, 암호화 및 전송 방식 안내에서 확인할 수 있습니다. WireGuard에는 매개변수가 많으므로 Private Key, Endpoint 및 MTU 안내도 참고하세요. 직접 입력한 항목은 보통 독립된 대상으로 관리해야 하며 특정 구독과 함께 동기화된다고 기대해서는 안 됩니다. 수동 입력 기록을 오래 보관해야 한다면 검증 후 바로 백업하고, 어떤 항목이 원본 정보에서 왔고 어떤 항목이 이후 로컬에서 수정되었는지 기록하세요.

03 / Scan QR Code

QR 코드 및 클립보드: 내용을 확인한 뒤 가져오기

QR 코드와 클립보드는 텍스트를 전달하는 방식일 뿐, 별도의 서버 프로토콜이 아닙니다. 같은 QR 코드에 단일 서버 공유 링크, 구독 URL 또는 일반 웹 주소가 담길 수 있습니다. Scan QR Code 또는 클립보드 가져오기를 사용하기 전에 가져올 대상의 유형을 파악하고 결과를 확인하세요. 수동 입력을 생략할 수 있어도 내용 식별, 권한 확인, 연결 테스트까지 생략해도 되는 것은 아닙니다. 출처를 알고 내용이 완전한 경우에만 클라이언트에서 바로 파싱하도록 하세요.

Scan QR Code 사용 시 확인 사항

앱 안의 Scan QR Code 메뉴에서 카메라를 실행하고 시스템 안내에 따라 카메라 권한을 허용한 뒤 QR 코드 전체를 화면에 맞추세요. 가장자리가 잘리지 않도록 하고 초점을 선명하게 맞추며 반사를 피하세요. 인식에 실패하면 먼저 거리를 조절하고 QR 코드가 무효라고 단정하지 마세요. 이전에 카메라 권한을 거부했다면 기기의 시스템 설정에서 Shadowrocket의 카메라 접근 상태를 확인한 뒤 다시 시도하세요. 시스템 카메라가 일반 텍스트나 웹페이지 안내를 인식했더라도 Shadowrocket에 서버 항목이 만들어진 것은 아닙니다.

QR 코드가 다른 기기에 표시되어 있다면 바로 스캔할 수 있습니다. 현재 기기에 저장되어 있다면 현재 메뉴에 이미지 인식 기능이 명시적으로 제공되는 경우에만 이미지에서 가져오세요. 다른 시스템 기능의 동작을 앱의 기능으로 간주하지 마세요. QR 코드가 너무 복잡하거나 압축되었거나 가장자리가 잘리면 인식되지 않을 수 있습니다. 원본의 선명한 이미지를 사용하거나 원본 텍스트를 직접 복사하세요. 개인 인증 정보가 포함된 QR 코드를 공개 인식 사이트에 올리지 말고, 인식률을 높이려고 관련 없는 사람에게 반복해서 전달하지 마세요.

클립보드로 가져올 때의 내용 범위

복사할 때는 ‘서버 주소:’ 같은 설명, 코드 블록, 안내 문단을 포함하지 말고 링크만 선택하세요. 앱으로 돌아와 해당 가져오기 메뉴를 사용하고, 시스템에서 붙여넣기 허용 여부를 묻는다면 이번에 직접 시작한 작업인지 확인한 뒤 허용하세요. 항목이 나타나지 않으면 원본 텍스트로 돌아가 전체가 복사되었는지 확인합니다. 이후에 다른 내용을 복사해 클립보드가 바뀌었거나 시스템 권한이 허용되지 않아 읽기에 실패했을 수도 있습니다. 복사 완료 알림만 보고 가져오기가 끝났다고 판단하지 마세요.

여러 줄 텍스트는 각 줄이 완전한 객체인지, 현재 가져오기 방식이 일괄 처리를 지원하는지 먼저 확인하세요. 화면 표시만 자동 줄바꿈된 경우 직접 줄바꿈을 넣을 필요가 없는 경우가 많습니다. 실제 공백이나 줄바꿈을 삽입하면 URI가 손상될 수 있습니다. 여러 항목 중 일부만 성공했다면 실패한 항목의 원문을 먼저 보관하고 로컬에서 구조를 하나씩 확인하세요. 누락된 항목을 찾으려고 전체를 반복해서 가져오지 마세요. 그러면 성공한 항목이 계속 쌓여 새로 가져온 기록과 기존 기록을 구분하기 어려워질 수 있습니다.

가져온 뒤 대상과 항목 확인

가져오기가 끝나면 먼저 결과가 어디에 표시되는지 확인하세요. Subscribe가 추가되었다면 구독 주소와 이후 업데이트를 관리할 수 있어야 합니다. 단일 SERVER가 추가되었다면 해당 프로토콜 매개변수를 열 수 있어야 합니다. 이어 Type, Address, Port, 메모, TLS 및 전송 관련 항목을 확인하세요. 메모는 링크의 일부에서 만들어졌을 수 있으며 식별용 텍스트일 뿐 테스트를 통과했다는 뜻은 아닙니다. 이름이 같은 항목은 목록 제목만 보고 기존 항목을 덮지 말고 필드 차이를 확인하세요. 기존에 작동하던 항목은 새 항목의 검증이 끝날 때까지 그대로 두는 것이 좋습니다.

인식에 실패하면 문제를 세 가지로 나눠 확인하세요. 카메라 또는 붙여넣기 권한을 사용할 수 있는지, 원본 텍스트가 완전한지, 현재 메뉴가 해당 형식을 지원하는지 살펴봅니다. 텍스트를 확인할 수 있지만 파싱되지 않는다면 다음 장의 공유 링크 구조를 참고하세요. 파싱은 되지만 연결할 수 없다면 Add Server의 항목을 확인하세요. 문의할 때는 사용한 메뉴, 시스템 권한 요청 표시 여부, 가져오기 결과, 오류 문구만 기록하세요. QR 코드 원본과 전체 URI는 민감한 정보로 취급하고 문의 내용과 함께 공개하지 마세요.

04 / URI & Config

공유 링크: 프로토콜, 구독, Config 구분

서버 공유 링크는 보통 프로토콜 접두사로 유형을 표시한 뒤 연결에 필요한 정보를 담습니다. 구독 주소는 보통 여러 항목을 가져오는 데 사용하고, Config 파일은 규칙과 정책, 기타 연결 동작을 정의할 수 있습니다. 모두 복사 가능한 텍스트처럼 보일 수 있지만 가져오기 위치와 업데이트 방식은 서로 다릅니다. 먼저 대상 유형을 파악해야 서버 가져오기, Subscribe, Config 중 무엇을 사용할지 판단할 수 있습니다. 브라우저에서 열린다는 이유만으로 형식이 올바르다고 볼 수 없으며 파일 이름만 보고 응답 내용을 추측해서도 안 됩니다.

접두사, 매개변수, 메모의 역할

공유 링크에는 프로토콜 접두사, 인증 정보, 주소, 포트, 쿼리 매개변수, 메모 조각이 포함되는 경우가 많지만 프로토콜마다 인코딩 방식이 완전히 같지는 않습니다. 일부 링크는 내용을 인코딩하고, 다른 링크는 전송 및 TLS 옵션을 매개변수로 직접 표시합니다. 한 프로토콜의 분해 방식을 다른 프로토콜에 그대로 적용하거나 비슷해 보이는 항목을 공통 항목으로 취급하지 마세요. URI를 직접 수정하기 전에 원문을 보관하고, 실험 후 원래 자료에서 다시 가져올 수 있는지 확인하세요.

일반적인 URI 구조에서 물음표 뒤에는 쿼리 매개변수가 오고, 구분 기호는 매개변수를 나누며, 샵 기호 뒤에는 메모 조각이 오는 경우가 많습니다. 퍼센트 인코딩은 공백, 한글 또는 다른 특수 문자를 나타낼 수 있으므로 복사할 때 원래 형태를 유지하고 인코딩을 보고 직접 삭제하지 마세요. 메모가 깨져 보여도 연결 매개변수에 문제가 있다는 뜻은 아닙니다. 반대로 메모가 정상적으로 보여도 인증 정보가 완전하다는 보장은 없습니다. 이름 표시와 연결 테스트는 따로 판단하세요. 먼저 항목을 검증한 뒤 식별하기 쉽도록 메모를 수정하세요.

링크 모양이 아니라 가져오기 결과 확인

같은 프로토콜에도 공유 형식이 여러 가지일 수 있으며, 사용하는 전송 방식에 따라 항목도 달라집니다. 파싱 후 TLS, Path 또는 Host가 누락되었다면 기존 매개변수와 대조해 가져오기가 완전했는지 확인하세요. 프로토콜 접두사만 보고 기본값을 임의로 채우지 마세요. 인식되지 않는 텍스트는 필요한 정보가 완전한 경우 Add Server에서 직접 입력할 수 있습니다. 원본에 파싱되지 않는 링크만 있고 필요한 매개변수가 없다면 형식 안내를 먼저 확인하세요. 추측으로 겉보기만 완전하고 실제로는 잘못된 항목을 만들지 마세요.

구독 URL의 응답 내용도 접근 권한, 주소 유효성, 서버 측 설정에 따라 달라질 수 있습니다. 웹페이지, 인증 안내 또는 빈 내용이 반환된다면 ‘서버를 가져온 수가 너무 적은’ 문제가 아니라 파싱 가능한 데이터를 아직 받지 못한 것입니다. 웹페이지의 임의 버튼 주소를 Subscribe에 넣어 시험하지 마세요. 원래 구독 안내, 오류 문구, 현재 네트워크 조건을 확인하고 응답 유형을 파악한 뒤 주소를 수정할지 파싱 호환성을 확인할지 결정하세요.

Config와 서버 목록의 역할 구분

Config의 규칙은 연결을 어떻게 분기할지 정하고 서버 항목은 프록시 연결 매개변수를 제공합니다. 아래는 Shadowrocket Config의 규칙 일부로, 규칙 순서와 정책 키워드만 보여 줍니다. 구독 주소가 아니며 서버 인증 정보도 포함하지 않습니다. 예시의 PROXY와 DIRECT는 규칙 정책 이름이며, 서버 목록의 메모로 대신할 수 없습니다. 완전한 Config에는 다른 부분도 포함될 수 있습니다. 이 예시를 붙여넣기 전에 기존 파일을 백업하고 해당 규칙 영역에 삽입하는지 확인하세요.

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

첫 번째 도메인 규칙을 먼저 판단하고, 뒤따르는 GEOIP 규칙은 해당 IP 위치 조건을 처리하며, FINAL은 앞선 규칙에 일치하지 않을 때 적용되는 최종 정책입니다. 규칙에는 순서가 있지만 서버 목록 정렬은 주로 관리와 선택을 위한 것으로 서로 다른 체계입니다. Global Routing이 Config일 때 현재 Config 규칙에 따라 요청이 처리됩니다. Proxy 또는 Direct를 선택하면 전체 처리 방식이 바뀝니다. 따라서 서버를 가져온 뒤 접속 결과가 예상과 다르면 공유 링크만 다시 만들지 말고 선택된 서버와 Global Routing을 함께 확인하세요.

05 / Update

업데이트 방식: 변경을 관리하고 작동 상태 유지

구독 업데이트는 기존 원격 주소에 다시 요청하고 응답에 따라 로컬 구독 항목을 조정합니다. 서버를 추가하거나 기존 항목을 제거하고, 이름이 같은 항목의 연결 매개변수를 바꿀 수도 있습니다. 이름만 새로고침하는 작업이 아닙니다. 업데이트하기 전에 어떤 구독을 사용하는지, 어떤 서버를 선택했는지, 구독 항목을 로컬에서 수정했는지 확인하세요. 독립적으로 조정한 내용을 계속 보관해야 한다면 앱의 내보내기 또는 백업 기능으로 먼저 저장하세요. 원격 업데이트가 로컬 편집 내용을 반드시 유지한다고 가정하지 마세요.

수동 업데이트로 점검 기준 만들기

처음 사용할 때, 주소 변경 후, 또는 내용이 오래되었다고 의심될 때는 확인 가능한 수동 업데이트를 한 번 실행하세요. 시작 전에 연결 상태, 네트워크, 현재 항목 상태를 기록하고 완료 후 명확한 오류가 있는지, 서버가 바뀌었는지, 기존에 선택한 항목이 남아 있는지 확인하세요. 주소 수정, 네트워크 변경, 반복 업데이트를 동시에 하지 마세요. 문제가 해결되더라도 원인을 판단할 수 없습니다. 한 번의 작업에 한 번의 관찰을 대응해야 가져오기 성공, 파싱 성공, 연결 성공의 세 단계를 구분할 수 있습니다.

자동 업데이트는 안정적으로 가져오는 것을 확인한 구독에 적합합니다. 현재 화면에 업데이트 스위치나 주기 설정이 있다면 실제 사용 빈도에 맞게 선택하세요. 더 자주 업데이트하는 것이 항상 좋은 것은 아닙니다. 업데이트 동작은 기기 네트워크, 시스템의 백그라운드 일정, 앱 상태에 영향을 받을 수 있으므로 정확한 시각을 보장할 수 없습니다. 앱을 오랫동안 열지 않아 로컬 내용이 오래된 것 같다면 직접 확인하고 수동 업데이트를 한 번 실행한 다음 연결을 검증하세요. 자동 업데이트가 켜져 있다는 이유만으로 목록이 최신이라고 판단하지 마세요.

주소 오류와 가져오기 경로 문제 구분

업데이트에 실패하면 먼저 URL이 여전히 본인이 사용하는 유효한 주소인지 확인하세요. 특히 인증 정보가 초기화된 뒤 이전 주소를 계속 사용하고 있지 않은지 살펴봅니다. 다음으로 현재 네트워크에서 구독 응답을 받을 수 있는지 확인하세요. 연결을 켰을 때만 또는 껐을 때만 실패한다면 두 조건을 각각 기록하고 가져오기 경로에 의존성이 있는지 확인하세요. 항상 특정 방식으로 업데이트해야 한다고 단정하지 마세요. Config 규칙과 현재 서버 상태 모두 요청 경로에 영향을 줄 수 있으므로 정해진 스위치 조합을 적용하지 말고 실제 결과를 기준으로 점검하세요.

오류 응답도 유형별로 이해해야 합니다. 연결 시간 초과는 주어진 조건에서 요청을 완료하지 못했다는 뜻이고, 인증 실패는 보통 접근 인증 정보를 확인해야 한다는 뜻입니다. 파싱 실패는 받은 내용이 예상 형식과 맞지 않는다는 의미입니다. 한 번 실패했다고 저장된 서버가 모두 작동하지 않는 것은 아니며 구독 전체를 바로 삭제할 필요도 없습니다. 기존 항목이 정상적으로 연결된다면 그대로 보관하고 업데이트 문제를 별도로 처리하세요. 오류 페이지에 개인 정보가 포함되어 있다면 오류 유형만 기록하고 전체 응답을 게시하지 마세요.

업데이트 후 선택 항목과 규칙 다시 확인

업데이트가 끝나면 기존에 선택한 서버의 이름이 바뀌거나, 교체되거나, 삭제되었을 수 있습니다. Home으로 돌아가 기본 선택을 확인하고 자주 사용하는 항목을 다시 테스트한 뒤 실제 요청을 확인하세요. 이름이 같다고 매개변수도 같다는 뜻은 아니며, 지연 시간이 정상이라고 모든 대상에 접근할 수 있는 것도 아닙니다. 로컬 설정에서 특정 이름을 참조한다면 이름 변경이 참조에 영향을 주는지도 확인하세요. 중요한 용도로 사용할 직전에 항목을 대량으로 조정하지 마세요. 먼저 검증 시간을 확보한 뒤 이전 기록을 정리하세요.

구독 업데이트와 앱 업데이트도 구분해야 합니다. 전자는 기존 구독에서 서버 정보를 다시 가져오는 작업이고, 후자는 App Store에서 앱 자체를 관리하는 작업입니다. 구매, 복원 및 호환성 안내는 정품 확인을 참고하세요. 시스템 요구 사항은 App Store 페이지에 표시된 내용을 기준으로 합니다. 모든 연결 오류를 앱 업데이트 필요로 돌리거나 구독 업데이트 한 번으로 앱 동작이 바뀌었다고 단정하지 마세요. 먼저 무엇이 바뀌었는지 확인한 뒤 업데이트 전후의 항목과 요청 결과를 비교하세요.

06 / Organize

여러 구독 정리: 이름, 중복 항목, 사용 범위

여러 구독을 함께 사용할 때 관리 목표는 목록을 최대한 짧게 만드는 것이 아니라 각 항목의 출처, 용도, 관리 방법을 알아볼 수 있게 하는 것입니다. 먼저 구독에서 생성된 항목과 직접 입력한 항목을 구분하고 구독 자체에 일관된 메모를 붙이세요. ‘일상용’, ‘임시 테스트’, ‘개인 기기’처럼 용도를 기준으로 이름을 정하고 비밀번호, 전체 도메인 목록, 구독 인증 정보는 제목에 넣지 마세요. 메모는 선택을 돕지만 항목 기록을 대신하지 않습니다. 이름이 중복되거나 업데이트된 경우에도 구체적인 구독을 찾을 수 있어야 합니다.

두 단계로 이름 정하기

첫 번째 단계는 구독 메모입니다. ‘이 서버 목록은 저장된 어느 주소에서 관리되는가?’를 확인하는 데 씁니다. 두 번째 단계는 서버 메모로 ‘현재 어느 항목을 선택했는가?’를 확인합니다. 원격 목록에는 자체 이름 규칙이 있을 수 있으므로 로컬에서 이름을 대량으로 바꾸기 전에 다음 업데이트에서 이름이 다시 생성되는지 고려하세요. 설명을 유지해야 한다면 비공개 메모에 용도와 항목의 대응 관계를 기록하거나 현재 화면에서 명시적으로 제공하는 메모 기능을 사용하세요. 원격 필드에 문구를 덧붙여 관리 정보를 계속 보존하려 하지 마세요.

임시 테스트용 독립 항목에는 ‘테스트’와 용도를 명확히 적고 검증 후 보관 여부를 결정하세요. 모든 항목을 ‘자주 사용’으로 이름 짓거나 숫자만 연속으로 붙이지 마세요. 업데이트 중 새 항목이 들어오면 번호가 실제 관계를 나타내기 어려워집니다. 정리할 때는 현재 작동 중인 서버를 유지하면서 구독을 하나씩 확인하세요. 한 번에 모든 항목의 이름을 바꾸고, 중복을 삭제하고, 기본 선택까지 바꾸지 마세요. 나누어 처리하면 오류가 발생했을 때 어느 단계로 되돌아가야 하는지 분명해집니다.

이름만으로 중복 여부를 판단하지 마세요

이름이 같은 두 항목도 포트, 인증 정보, 전송 매개변수가 다를 수 있습니다. 이름이 달라도 연결 설정이 완전히 같을 수 있습니다. 중복 여부를 판단할 때는 로컬에서 Type, Address, Port, 인증, TLS, 전송 항목을 비교하세요. 비교 중 민감한 값을 공개 표에 복사하지 마세요. 필드가 같더라도 서로 다른 구독에서 가져온 항목이라면 업데이트 관리 출처가 다를 수 있습니다. 한 항목을 삭제해도 다음 업데이트 때 다시 나타나지 않는다는 보장은 없으므로 어느 구독의 관리 관계를 유지할지 먼저 결정하세요.

구독 내부에서 중복 항목이 보이면 먼저 응답 내용에서 생성된 항목인지 확인하세요. 업데이트할 때마다 다시 나타난다면 로컬에서 삭제해도 목록이 일시적으로만 바뀝니다. 같은 구독을 중복으로 가져왔다면 메모가 같다는 이유만으로 삭제하지 말고 전체 주소와 관리 용도를 확인한 뒤 보관할 구독을 결정하세요. 정리 전에 기본 서버가 삭제 대상에 포함되지 않았는지 확인하고, 테스트를 마친 대체 항목을 준비하세요. 현재 화면에 명확한 일괄 정리 기능이 없다면 의미가 불분명한 일괄 작업보다 하나씩 처리하는 편이 안전합니다.

표시 순서와 실제 라우팅은 별개

정렬은 항목을 더 쉽게 찾기 위한 것으로, 첫 번째 서버가 자동으로 기본값이 되거나 오류 시 앱이 자동으로 전환된다는 뜻은 아닙니다. 표시 순서를 바꾼 뒤에도 Home에서 실제 선택 상태를 확인하세요. Config의 정책 그룹을 사용한다면 해당 그룹의 선택 규칙도 이해해야 합니다. 서버 목록 순서를 정책 그룹의 동작으로 간주하지 마세요. 자주 사용하는 안정적인 항목은 찾기 쉬운 곳에 두고 임시 테스트 항목은 따로 구분해 연결 전에 검증되지 않은 기록을 급히 선택하지 않도록 하세요.

인증 정보가 없는 비공개 관리 목록을 만들어 구독 메모, 용도, 로컬 수정 여부, 최근 작업 결과만 기록할 수 있습니다. ‘결과’에는 ‘실제 요청 확인 완료’, ‘전송 항목 확인 필요’처럼 직접 관찰한 사실을 적고 이름만으로 사용 가능 여부를 추측하지 마세요. 자세한 작업 순서는 여러 구독의 그룹화, 정렬 및 중복 항목 정리를 참고하세요. 정리를 마친 뒤 자주 사용하는 상황에서 다시 테스트해 목록은 더 명확해지고 연결 상태도 설명할 수 있는지 확인하세요.

07 / Connectivity Test

지연 시간 테스트 및 정렬: 결과가 의미하는 범위

지연 시간 테스트는 현재 네트워크와 테스트 방식에서 특정 연결 작업이 완료되었는지, 얼마나 걸렸는지 확인하는 방법입니다. 지속적인 전송 속도와 같지 않으며 특정 웹사이트나 앱의 사용 가능 여부를 직접 증명하지도 않습니다. 결과를 판단하기 전에 테스트 방식, 대상, 현재 네트워크 조건을 확인하세요. 방식이 다른 테스트의 수치를 직접 비교해 순위를 매기지 마세요. 테스트 시간 초과도 한 번의 관찰일 뿐 서버가 영구적으로 작동하지 않는다는 증거는 아닙니다. 반복 테스트, 실제 요청, 다른 항목과의 비교를 함께 고려하세요.

조건을 맞춘 뒤 비교

서버 몇 개를 비교할 때는 가능한 한 같은 네트워크와 테스트 방식, 비슷한 시간대를 유지하세요. 한 항목은 모바일 네트워크에서, 다른 항목은 Wi-Fi에서 테스트하지 마세요. 테스트 중에는 대용량 파일 전송처럼 네트워크를 뚜렷하게 점유하는 작업을 줄이고, 자주 쓰는 항목을 먼저 테스트한 뒤 대체 항목을 확인하세요. 화면에 테스트 방식이 여러 가지 표시된다면 각각 검사하는 연결 단계가 다를 수 있습니다. 기본 연결이 된다고 인증, TLS, 전송 계층, 대상 요청까지 모두 완료된 것은 아닙니다. 실제 요청에 가까운 방식은 보통 더 많은 단계를 확인하지만 테스트 대상의 영향도 더 많이 받을 수 있습니다.

Connectivity Test와 실제 접속 결과를 함께 확인

서버를 선택하고 연결을 켠 뒤 Connectivity Test로 연결 상태를 확인하고 실제로 사용하려는 페이지나 앱을 열어 보세요. 테스트는 성공했지만 대상에 접근할 수 없다면 Global Routing이 예상대로 설정되었는지, 대상에 해당 규칙이 적용되었는지, DNS가 정상적으로 해석되는지 확인하세요. 근거 없이 모든 문제를 서버 탓으로 돌리지 마세요. 반대로 대상에 접근할 수 있지만 특정 테스트가 실패한다면 테스트 대상의 응답 조건도 고려하세요. 테스트 하나만으로 정상 작동하는 항목을 삭제하지 마세요.

Global Routing에서 Config는 현재 Config에 따라 요청을 처리하고, Proxy는 프록시 방식으로, Direct는 직접 연결 방식으로 처리합니다. 조건을 비교하기 전에 기존 상태를 기록하고 한 번에 한 가지 조건만 바꾸세요. 테스트가 끝나면 필요한 설정으로 되돌립니다. 모드를 바꾸면 결과의 의미도 달라집니다. Direct에서 페이지가 열린다고 현재 선택한 서버가 사용 가능하다는 뜻은 아닙니다. Config에서 접속이 정상이어도 해당 요청이 DIRECT 규칙에 일치했을 수 있습니다. 서버를 검증할 때는 테스트 요청이 예상한 경로를 거치는지 확인하세요.

정렬 후 결과 다시 확인

지연 시간으로 정렬하면 이번 테스트 결과에 따라 항목 순서만 바뀝니다. 수치가 낮은 항목이 오래 사용해도 더 안정적이거나 처리량이 더 높다는 뜻은 아닙니다. 한 번 가장 낮은 값을 확인했다고 자주 전환하지 마세요. 반복 테스트에서 결과가 일관되고 실제 사용에도 문제가 없는 항목을 우선 선택한 뒤 검증된 대체 항목을 하나 남겨 둘 수 있습니다. 정렬 후 기본 선택 상태를 다시 확인하세요. 목록이 길거나 이름이 같은 항목이 있을 때 화면의 첫 번째 항목을 앱이 선택해 사용 중인 항목으로 착각하지 마세요.

같은 서버가 네트워크에 따라 크게 달라진다면 비밀번호를 계속 바꾸지 말고 네트워크 조건을 기록하세요. 업데이트 후 일부 항목만 갑자기 실패한다면 필드가 바뀌었는지 확인하세요. 모든 항목에 동시에 문제가 생기면 공통 조건부터 점검합니다. 오류 기록에는 테스트 방식, 네트워크 유형, Global Routing, 오류 원문, 실제 대상에서의 결과를 포함할 수 있지만 전체 구독 URL은 넣지 마세요. 첫 연결 확인 순서는 기본 서버, 연결 스위치 및 Connectivity Test 확인표에서 참고해 기본 단계를 빠뜨리지 않도록 하세요.

08 / Backup & Remove

삭제 및 백업: 범위를 확인한 뒤 실행

삭제하기 전에 대상을 확인하세요. 개별 서버, Subscribe 전체, Config 파일, 앱 자체는 서로 다른 범위의 작업이며 복구에 필요한 자료도 다릅니다. 서버 하나를 삭제해도 구독 접근 인증 정보가 폐기되는 것은 아니며, 구독을 삭제해도 원격 리소스가 취소되는 것은 아닙니다. 백업은 필요한 로컬 상태를 복원할 수 있도록 하면서 인증 정보를 안전하게 보호하는 것이 목적입니다. 모든 내용을 공개되기 쉬운 곳에 무작정 복사하지 마세요.

복원 대상에 맞는 백업 만들기

구독으로 생성된 목록만 복원하려면 유효한 구독 주소와 필요한 안내를 저장하는 편이 항목을 하나씩 기록하는 것보다 간단할 수 있습니다. 다만 주소가 나중에 바뀔 가능성도 고려하세요. 직접 입력한 서버를 복원하려면 완전한 프로토콜 매개변수를 보관하거나 앱의 서버 공유·내보내기 기능을 사용해야 합니다. 분기 동작까지 복원하려면 해당 Config도 별도로 저장해야 합니다. 서버 링크만으로는 규칙이 자동 복원되지 않습니다. 현재 화면의 백업 기능을 사용할 때는 포함 범위 안내를 읽고, 한 메뉴가 모든 설정을 담는다고 가정하지 마세요.

백업에는 구독 인증 정보, 비밀번호, UUID 또는 키가 포함될 수 있으므로 원본 정보와 같은 수준으로 보호해야 합니다. 접근 보호가 적용되고 본인이 관리하는 저장 위치에 보관하세요. ‘메모만 있는 목록’과 ‘전체 인증 정보를 포함한 백업’은 명확히 구분하는 것이 좋습니다. 공개 공유 링크를 장기 백업으로 대신하거나 문의 내용에 전체 서버 정보를 첨부하지 마세요. 구조 설명용 사본은 예시 값으로 바꾸고 실제 복원용 사본은 완전한 상태로 유지해야 합니다. 두 사본을 혼용하지 마세요.

단일 항목 삭제와 구독 전체 삭제의 차이

구독에서 생성된 서버 항목 하나를 삭제하기 전에 다음 업데이트에서 다시 생성될지 고려하세요. 로컬 서버 목록 전체를 제거하려는 경우에는 구독 전체의 삭제 범위를 확인해야 합니다. 구독 전체를 삭제할 때는 확인 안내를 꼼꼼히 읽고 관련 항목도 함께 제거되는지 판단하세요. 각 작업은 서로 대체할 수 없습니다. 표시 항목 하나를 삭제해도 구독 업데이트가 중단되는 것은 아니며, 로컬 데이터를 지워도 이미 노출된 원격 접근 인증 정보의 효력이 사라지지는 않습니다.

현재 선택된 서버를 삭제하기 전에 검증된 다른 항목으로 전환하고 필요한 연결이 계속 작동하는지 확인한 뒤 이전 항목을 처리하세요. 목록에 서버가 하나뿐이라면 복원 자료부터 준비하고 ‘삭제한 다음 방법을 찾기’ 순서로 진행하지 마세요. 여러 항목을 정리할 때는 범위를 작게 시험하고 결과를 확인한 뒤 계속하세요. 이름은 같지만 매개변수가 다른 항목을 함께 지울 수 있습니다. 서버가 남아 있어도 기존 규칙과 정책 설정을 대신할 수 없으므로 Config 삭제도 별도로 백업해야 합니다.

복원 순서와 백업 확인

복원하기 전에 앱이 App Store에서 받아진 상태인지 확인하세요. 구입 항목을 되찾는 방법은 기기 변경 및 재설치 후 복원 안내를 참고하세요. 구매 기록은 앱을 받을 수 있는 자격을 복원할 뿐 서버와 Config까지 자동 복원된다는 보장은 아닙니다. 이어 구독 또는 직접 입력한 항목을 복원하고 필드와 기본 선택을 확인한 다음 필요한 Config를 복원하고 마지막으로 Global Routing을 점검하세요. 이 순서대로 진행하면 연결에 문제가 생겼을 때 원인이 어느 단계인지 파악할 수 있어 모든 백업을 한꺼번에 가져와 충돌을 구분하지 못하는 상황을 피할 수 있습니다.

백업을 마친 뒤에는 실제로 읽을 수 있는지 확인하세요. 내보낸 내용이 비어 있지 않은지, 구독 주소가 완전한지, 독립 항목에 필요한 필드가 들어 있는지, Config가 보관하려던 파일인지 살펴봅니다. 원본 데이터를 삭제하지 않아도 범위 확인, 항목 대조, 제한된 가져오기로 검증할 수 있습니다. 제한된 가져오기로 중복 기록이 생겼다면 복원 자료가 유효한지 확인한 뒤 테스트 사본을 정리하세요. 예전에 백업했다는 기억에 의존하기보다 저장 위치에 여전히 접근할 수 있는지 주기적으로 확인하는 편이 안전합니다.

인증 정보가 공개된 적이 있다면 스크린샷, 링크 또는 로컬 기록만 삭제해서는 접근 위험을 해결할 수 없습니다. 현재 사용 중인 서비스의 관리 방법에 따라 관련 인증 정보를 변경하거나 폐기한 뒤 앱의 주소와 백업도 업데이트하세요. 평소에는 수정 전 기준 상태를 저장하고, 수정 후 연결을 검증하고, 검증 후 중복 항목을 정리한 다음 마지막으로 백업을 업데이트하는 순서를 유지할 수 있습니다. 연결 절차를 다시 확인하려면 시작하기로 돌아가세요. 자주 묻는 작업 관련 질문은 연결 스위치, Global Routing, 구독 업데이트 및 구입 항목 복원 FAQ에서 확인할 수 있습니다. 일부 문제 하나 때문에 모든 데이터를 다시 구성할 필요는 없습니다.