Shadowrocket
구독 및 서버 관리

01 / SUBSCRIBE

Subscribe 구독 가져오기

구독은 반복해서 접속할 수 있는 서버 정보의 진입점이지, 특정 서버 한 대의 주소가 아닙니다. 구독을 가져오면 Shadowrocket이 해당 주소에 요청을 보내고 지원되는 응답을 서버 항목으로 변환합니다. 이후 같은 구독을 업데이트하면 목록에 항목이 추가·삭제되거나 교체될 수 있습니다. 따라서 구독을 관리할 때는 ‘진입점’과 ‘결과’를 구분해야 합니다. 진입점은 다음 데이터를 가져올 위치를 결정하고, 결과는 Home에서 선택할 수 있는 서버입니다. 표시 이름만으로 진입점이 올바르거나 내용이 완전하다고 판단할 수는 없습니다.

가져오기 전에 정보 유형 확인

사용자가 보유한 구독 링크 전체를 준비하고, 계정 페이지나 안내 페이지 주소 또는 단일 서버 공유 링크가 아닌 본인의 구독 정보에서 복사했는지 확인하세요. 구독 주소에는 쿼리 매개변수가 포함될 수 있으며, 이 역시 주소의 일부입니다. 복사한 뒤 물음표 뒤 내용을 임의로 지우거나 메신저에 포함된 설명, 마침표, 줄바꿈을 함께 붙여 넣지 마세요. 자료에 구독 주소와 계정 로그인 페이지가 따로 있다면 서로 바꿔 사용할 수 없습니다.

Home에서 추가 메뉴를 누르고 Add Server로 이동한 다음 Type을 Subscribe로 설정하고 전체 링크를 URL에 입력하세요. 현재 화면에 구독 전용 메뉴가 있다면 해당 메뉴를 이용해도 됩니다. 구독 주소를 입력하는 방식인지, 서버 포트를 직접 입력하는 방식인지 확인하세요. 용도와 출처를 알아볼 수 있는 메모를 추가한 뒤 저장하고 결과를 기다립니다. 버튼 위치와 선택 항목은 현재 앱 화면을 기준으로 확인하고, 아이콘 위치만 보고 기능을 추측하지 마세요.

첫 가져오기 후 세 단계 확인

첫째, 구독 자체가 저장됐는지 확인하고 편집 화면으로 다시 들어가 주소가 온전한지 살펴봅니다. 둘째, 구독 아래에 서버가 표시되는지 확인하고 성공 알림뿐 아니라 이름, 프로토콜 유형, 그룹 소속도 살펴봅니다. 셋째, 항목 하나를 선택해 연결을 테스트합니다. 구독 저장, 구독 내용 파싱, 서버 실제 연결은 각각 다른 결과이므로 어느 하나로 나머지를 판단하면 안 됩니다.

가져온 뒤 목록이 비어 있다면 기존 항목은 그대로 두고 오류 메시지와 발생 단계를 기록하세요. 브라우저에서 주소가 열린다고 해서 파싱 가능한 구독 데이터가 반환되는 것은 아닙니다. 서버가 로그인 페이지, 접근 제한 안내 또는 빈 응답을 보낼 수 있습니다. 반대로 브라우저에 읽기 어려운 텍스트가 표시된다고 해서 내용이 손상됐다고 단정할 수도 없습니다. 앱의 파싱 결과와 보유 자료에 적힌 형식을 함께 확인하고, 전체 응답을 공개 게시판에 올리지 마세요.

구독 목록과 규칙 설정은 다릅니다

Subscribe는 주로 서버 정보를 가져오고 관리하는 기능입니다. Config에서 활성화한 설정은 규칙, 정책 및 관련 동작을 결정합니다. 구독을 가져왔다고 모든 웹사이트가 새 서버를 사용한다고 가정하지 마세요. Global Routing의 현재 선택, 실제로 선택된 서버, 설정에서 정책이 참조하는 항목도 확인해야 합니다. 첫 연결을 설정하려면 구독과 규칙을 동시에 수정하기보다 빠른 시작 안내에 따라 차례로 확인하는 편이 문제를 찾기 쉽습니다.

같은 링크를 반복해서 가져오면 관리 항목이 중복되어 이후 업데이트, 삭제, 문제 해결이 복잡해질 수 있습니다. 다시 추가하기 전에 목록에서 기존 구독을 찾아 업데이트를 시도하세요. 별도의 테스트 사본이 필요한 경우에만 용도를 분명히 표시합니다. 목록이 비어 있는 경우의 단계별 점검은 구독 가져오기 실패 또는 목록이 비어 있을 때 확인할 사항을 참고하세요. 진단에 사용할 기준을 잃지 않도록 기존 목록은 먼저 보존하세요.

02 / ADD SERVER

Add Server 수동 입력 항목

수동 추가는 사용자가 서버 한 대의 전체 연결 정보를 보유했거나 항목을 하나씩 확인해야 할 때 적합합니다. 먼저 Add Server에서 올바른 Type을 선택한 다음 해당 프로토콜에 표시되는 항목을 입력하세요. 프로토콜 선택은 이름을 붙이는 기능이 아니라 인증 방식, 데이터 캡슐화 및 연결 매개변수를 결정합니다. 두 항목 모두 비밀번호를 사용한다고 해서 Shadowsocks와 Trojan을 서로 바꿔 쓸 수는 없습니다. 포트만 바꿔 한 프로토콜을 다른 프로토콜로 변경할 수도 없습니다.

주소, 포트, 인증 정보를 따로 확인

서버 주소는 일반적으로 도메인 또는 IP 주소입니다. 필드 안내에 따라 호스트 부분을 입력하고 웹 주소의 경로를 함께 넣지 마세요. 포트는 서버에서 연결을 수신하는 포트이며 임의로 선택할 수 있는 숫자가 아닙니다. 메모는 항목을 알아보기 위한 것으로 인증에 사용되지 않습니다. 사용자 이름을 메모에 입력하거나 표시 이름을 호스트 이름으로 사용해도 올바르게 연결되지 않습니다. 입력을 마친 뒤 키보드를 닫고 원본 자료와 항목별로 대조하세요. 특히 앞뒤 공백과 비슷하게 보이는 문자를 주의해야 합니다.

프로토콜 매개변수는 한 묶음으로 확인

Shadowsocks의 암호화 방식과 비밀번호는 모두 일치해야 합니다. 비밀번호가 맞는지만 확인하고 암호화 방식은 건너뛰면 안 됩니다. VMess와 VLESS에서는 UUID가 흔히 식별 정보로 사용되며 자료에 명시된 전송 방식도 확인해야 합니다. Trojan의 비밀번호와 TLS 관련 항목은 각각 역할이 다릅니다. HTTP나 SOCKS5에서 사용자 이름과 비밀번호가 필요하면 각각 입력하세요. 자료에 인증이 명시되지 않았다면 임의로 값을 추가하지 마세요. 사용 가능한 항목은 선택한 프로토콜과 현재 화면에 따라 다르므로 실제 표시 내용을 기준으로 확인하세요.

TLS를 사용하는 경우 연결 주소와 서버 이름이 서로 다를 수 있습니다. SNI는 TLS 핸드셰이크에서 서버 이름을 지정하며, 인증서 검증도 서버 인증서가 적용되는 이름과 관련됩니다. 연결 주소로 IP를 사용한다고 해서 SNI도 해당 IP로 바꿔야 하는 것은 아닙니다. 인증서 오류가 발생하면 검증을 바로 끄기보다 이름, 기기 시간, 원본 자료를 먼저 확인하세요. 검증을 끄면 신뢰 범위가 달라지며, 잘못된 비밀번호나 전송 경로 문제도 해결되지 않습니다.

자료에서 WebSocket 같은 전송 방식을 지정했다면 Host와 Path를 전송 옵션과 함께 확인하세요. 경로는 대소문자와 슬래시가 중요할 수 있습니다. 공백이 하나 더 들어가거나 앞 슬래시가 빠져도 핸드셰이크가 실패할 수 있습니다. Hysteria2와 WireGuard 등은 각각 전용 매개변수가 있으므로 다른 프로토콜의 입력 항목을 대신 사용하면 안 됩니다. 필요한 정보가 없다면 보유 자료에서 먼저 확인하고, 모든 스위치를 하나씩 켜 보는 방식으로 문제를 해결하지 마세요.

저장 후 비교할 원본 항목 보존

기존 서버에 연결할 수 없다면 먼저 현재 입력값을 복사하거나 기록한 다음 의심되는 매개변수 하나만 수정하세요. 주소, 포트, TLS를 동시에 바꾸면 연결 결과가 달라져도 원인을 알기 어렵습니다. 수동 관리 항목에는 별도의 메모를 붙여 구독에 포함된 같은 이름의 항목과 구분하세요. 구독 항목은 업데이트 후 다시 생성될 수 있어 로컬에서 임시로 수정한 내용이 유지되지 않을 수 있습니다. 이를 장기 관리 방법으로 사용하지 마세요.

03 / IMPORT

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

QR 코드와 클립보드는 텍스트를 전달하는 수단일 뿐 서버 정보 자체를 바꾸지 않습니다. QR 코드에는 단일 공유 링크가 들어 있을 수도 있고 구독 주소가 들어 있을 수도 있습니다. 복사한 내용이 안내 문구일 수도 있습니다. 작업 전에 가져올 대상이 무엇인지 확인하고, 앱에서 파싱한 뒤 서버 하나가 표시되는지 아니면 데이터를 가져올 구독 주소인지 살펴보세요. 인식에 성공했다는 것은 텍스트를 읽었다는 뜻일 뿐, 매개변수가 완전하거나 서비스를 사용할 수 있다는 뜻은 아닙니다.

QR 코드 스캔 전에 인식률 높이기

앱에서 Scan QR Code를 실행해 보유 자료의 QR 코드를 비추고 네 모서리가 모두 스캔 영역 안에 들어오게 하세요. 빛 반사와 기울기를 피하고 지나치게 확대하지 마세요. 다른 기기에 표시된 코드를 스캔한다면 화면 밝기를 적절히 높이고 거리를 일정하게 유지하세요. 긴 링크가 담긴 QR 코드는 패턴이 촘촘합니다. 압축된 메신저 미리보기 이미지는 제대로 인식되지 않을 수 있으므로 흐릿한 미리보기를 반복해서 스캔하기보다 원본 고화질 이미지를 사용하세요.

카메라 권한을 허용하지 않았다면 시스템 설정에서 Shadowrocket의 카메라 접근 권한을 확인한 뒤 앱으로 돌아가 다시 시도하세요. 권한 문제와 QR 코드 내용 문제는 구분해서 확인해야 합니다. 카메라 화면을 전혀 열 수 없다면 먼저 권한을 확인하고, 화면은 열리지만 인식되지 않는다면 이미지 품질을 확인하세요. 현재 앱 메뉴에서 사진 보관함의 QR 코드 읽기를 지원하면 화면 안내에 따라 이미지를 선택할 수 있습니다. 해당 메뉴가 보이지 않는다면 모든 스캔 화면에서 같은 기능을 제공한다고 가정하지 마세요.

클립보드에서는 필요한 내용만 복사

복사하기 전에 전체 링크가 선택됐는지 확인하세요. 긴 텍스트가 화면 가장자리에서 줄바꿈되어 보이는 부분도 주의해야 합니다. 화면에서 줄이 바뀌어 보여도 실제 줄바꿈 문자가 아닐 수 있지만, 직접 이어 붙이는 과정에서 공백이 들어갈 수 있습니다. Shadowrocket으로 돌아가 현재 화면의 클립보드 가져오기 기능을 사용하거나 구독 주소를 Subscribe의 URL에 붙여 넣으세요. 시스템에서 붙여넣기 허용 여부를 묻는다면 직접 시작한 작업인지 확인한 뒤 허용하세요. 허용하지 않아 내용이 입력되지 않은 것을 프로토콜 미지원으로 오해하지 마세요.

메모나 메시지에서 복사할 때 링크 앞의 번호, 뒤에 붙은 설명, 링크를 감싼 따옴표까지 함께 복사하는 경우가 많습니다. 앞뒤 경계를 확인한 뒤 다시 복사하세요. 주소를 ‘정리’하려고 퍼센트, 등호, 더하기, 물음표를 삭제하지 마세요. 인코딩이나 매개변수의 일부일 수 있습니다. 플랫폼이 원문을 짧은 요약으로 바꾸거나 일부만 표시한다면 미리보기 내용을 바탕으로 주소를 추측해 완성하지 말고 원본 자료에서 복사하세요.

가져온 항목은 개수가 아니라 필드로 확인

항목이 파싱되면 편집 화면을 열어 Type, 호스트, 포트, 인증 정보가 원본 자료와 일치하는지 확인하세요. QR 코드에 오래된 매개변수가 들어 있을 수 있고 표시 이름이 현재 구독의 이름과 같을 수도 있으므로 ‘목록에 항목이 추가됐다’는 사실만으로 충분히 확인된 것은 아닙니다. 같은 이름의 항목이 중복으로 생겼다면 각각의 소속과 주요 필드를 확인하고 검증된 항목은 남겨 두세요. 중복이 명확해진 뒤 정리하고, 구분하기 전에 여러 항목을 한꺼번에 삭제하지 마세요.

QR 코드에서 구독 주소를 읽었다면 이후 네트워크를 통해 한 번 더 데이터를 가져와야 합니다. 단일 공유 링크를 읽었다면 일반적으로 로컬 서버 항목만 생성됩니다. 전자는 구독 가져오기 오류를, 후자는 필드 파싱 또는 연결 오류를 기준으로 확인하세요. 스캔 후 서버 정보 대신 웹페이지가 열리면 QR 코드에 어떤 유형의 내용이 담겼는지 먼저 확인해야 합니다. 웹페이지에 나온 임의의 주소를 서버 주소로 입력하지 마세요. 진입점 문제를 입력 항목 문제로 바꾸게 됩니다.

가져오기와 연결 사이에는 서버 선택, Global Routing 확인, 시스템 VPN 설정 허용 단계가 더 있습니다. 처음 설정한다면 사용 안내로 돌아가 전체 절차를 마치세요. QR 코드와 수동 입력으로 같은 정보를 가져왔는데 결과가 다르면 네트워크를 반복해서 바꿔 차이를 감추기보다 두 항목의 필드를 비교해 파싱 차이를 확인하세요.

04 / LINK FORMAT

공유 링크 형식과 가져오기 범위

단일 공유 링크에는 일반적으로 프로토콜, 인증 정보, 서버 주소와 일부 추가 매개변수가 포함됩니다. 단일 링크는 연결 대상 하나를 설명하고 구독은 업데이트 가능한 정보 묶음을 가리킨다는 점에서 다릅니다. 링크가 긴지 또는 네트워크 주소가 포함됐는지만 보고 유형을 판단하지 마세요. 프로토콜 접두사가 있는 단일 링크, 목록을 가져오는 주소, 안내용 웹페이지는 서로 다른 데이터이므로 각각에 맞는 가져오기 메뉴를 사용해야 합니다.

구조를 먼저 확인하고 매개변수 살펴보기

일반적인 접두사로는 ss://, vmess://, vless://, trojan:// 등이 있습니다. 접두사는 파싱 방식을 나타내지만 현재 앱이 모든 확장 필드를 인식한다고 보장하지는 않습니다. 프로토콜마다 본문 구조가 다릅니다. 인코딩된 내용이 포함되기도 하고 주소와 쿼리 매개변수와 비슷한 구조를 사용하기도 합니다. 모두 ‘콜론 앞은 사용자 이름, 뒤는 비밀번호’로 나눌 수는 없으며 인코딩된 부분을 직접 수정해서도 안 됩니다.

일부 링크는 끝에 샵 기호로 메모를 붙이고 매개변수에 퍼센트 인코딩을 사용할 수 있습니다. 인코딩은 특수 문자를 처리하거나 비영어 이름을 나타낼 수 있으므로 문자를 직접 바꾸면 파싱 결과가 달라집니다. 메모는 보통 실제 연결에 사용되지 않지만 쿼리 매개변수는 TLS, 전송 방식, 경로를 지정할 수 있습니다. 이름이 깨져 보여도 연결이 된다면 먼저 메모 표시를 확인하세요. 연결에 실패했다면 프로토콜 항목을 점검하고 두 문제를 혼동하지 마세요.

파싱 성공이 모든 매개변수의 일치를 뜻하지는 않습니다

링크 하나에 기본 인증 정보와 추가 전송 옵션이 함께 포함될 수 있습니다. 가져온 뒤 주소와 비밀번호만 보인다고 해서 나머지 옵션까지 모두 적용됐다고 볼 수는 없습니다. 항목을 열어 원본 자료와 비교하고 필요한 전송 방식, 보안 연결, 서버 이름 등을 확인하세요. 링크 형식이 여러 가지라면 현재 앱에서 실제로 파싱한 결과를 기준으로 삼으세요. 인식되지 않은 필드는 보유 자료를 통해 하나씩 확인하고, 알 수 없는 값을 메모나 주소 입력란에 임의로 넣지 마세요.

서버 항목에서 공유 링크를 내보낼 때는 받는 쪽에서 전체 매개변수가 필요한지 확인하세요. 단일 항목 공유만으로 전체 관리 환경을 옮길 수는 없습니다. 구독 업데이트 관계, 현재 Config, 규칙 정책 및 일부 전역 설정은 링크에 포함되지 않을 수 있습니다. 기기를 옮길 때는 이 페이지 마지막 장의 단계별 백업 방법을 사용하세요. 현재 연결되는 링크 하나만 저장한 뒤 모든 설정을 백업했다고 생각하지 마세요.

서버 정보와 규칙 텍스트는 서로 대체할 수 없습니다

아래는 Shadowrocket의 규칙 예시입니다. .conf 설정의 Rule 부분에 해당하며 서버 공유 링크가 아니고 인증 정보도 포함하지 않습니다. 예시 도메인에는 PROXY를 사용하고 나머지 요청에는 DIRECT를 사용하도록 지정합니다. 실제 편집 전에 현재 설정에서 해당 정책이 무엇을 의미하는지 확인하세요. 이 텍스트를 Add Server에 붙여 넣어도 연결 가능한 서버가 만들어지지 않습니다.

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

공유하기 전에 받는 사람이 서버 매개변수, 구독 주소, 규칙 예시 중 무엇을 필요로 하는지 확인하세요. 규칙을 공개적으로 논의할 때는 대개 매칭 조건과 정책 이름만 있으면 되며 서버 인증 정보는 필요하지 않습니다. 링크 오류를 비교해야 한다면 프로토콜 접두사, 매개변수 유무, 오류 현상만 기록하고 전체 인증 정보는 가리세요. 인코딩은 암호화가 아닙니다. 읽기 어려운 링크라고 해서 공개해도 안전한 것은 아닙니다.

목표가 지정한 웹사이트에서 기존 서버를 사용하게 하는 것이라면 목록을 계속 가져오기보다 규칙을 조정하세요. 지정한 웹사이트에 PROXY를 적용하는 설정 예시에서 규칙 순서와 FINAL의 관계를 확인할 수 있습니다. 먼저 데이터가 어느 계층에 속하는지 파악한 뒤 알맞은 메뉴를 선택하면 ‘가져오기는 성공했지만 동작이 바뀌지 않음’을 오해하는 일을 줄일 수 있습니다.

05 / UPDATE

구독 업데이트및 실패 시 복구

구독 업데이트는 해당 주소가 현재 제공하는 서버 정보를 다시 가져오는 기능이지 모든 연결 문제를 해결하는 기능은 아닙니다. 서버에서 주소, 포트, 인증 정보 또는 사용 가능한 항목을 변경했다면 업데이트를 통해 로컬에도 반영할 수 있습니다. 문제가 기기 네트워크, 현재 규칙 또는 시스템 권한에 있다면 구독 업데이트만으로 해결되지 않습니다. 시작 전에 현상을 구분하세요. 가져오기 실패인지, 목록이 바뀐 것인지, 기존 항목의 연결 실패인지에 따라 확인 순서가 다릅니다.

업데이트 과정을 추적할 수 있도록 준비

업데이트 전에 현재 선택된 서버와 소속 구독을 확인하고 주요 이름을 기록하세요. 필요하다면 먼저 백업합니다. 대상 구독만 업데이트하고 모든 그룹을 동시에 업데이트하거나 규칙까지 변경하지 마세요. 작업이 끝나면 먼저 오류 메시지를 확인하고 목록이 바뀌었는지, 기존에 선택한 항목이 남아 있는지 살펴보세요. 이름이 사라졌다면 주소에서 반환하는 내용이 바뀐 것일 수 있으며 로컬에서 잘못 삭제된 것은 아닐 수 있습니다. 이름이 그대로라고 해서 주소나 인증 정보까지 변하지 않았다고 단정할 수도 없습니다.

업데이트에 네트워크 요청이 필요하다면 기기에서 해당 구독 주소에 접속할 수 있는지 먼저 확인하세요. 경우에 따라 현재 연결 경로가 접속 결과에 영향을 줄 수 있으므로 안전하게 확인할 수 있는 범위에서 네트워크 상태를 비교하되 한 번에 조건 하나만 바꾸세요. 업데이트 버튼을 연속해서 누르는 방식으로 확인하지 마세요. 짧은 시간에 반복 요청하면 제한에 걸릴 수 있고 오류 메시지가 서로 덮일 수도 있습니다. 첫 실패의 원인을 기록한 다음 필요한 경우에만 다시 시도하세요.

가져오기, 파싱, 사용 단계별로 점검

가져오기에 실패했다면 주소가 완전한지, 네트워크를 사용할 수 있는지, 진입점이 아직 유효한지 확인하세요. 파싱에 실패했다면 반환 내용이 지원되는 구독 데이터인지, 로그인 페이지나 안내 문구로 바뀌지 않았는지 확인해야 합니다. 업데이트는 성공했지만 연결에 실패했다면 새 서버의 입력값, 선택 상태, 규칙 정책을 점검하세요. 세 가지 상황을 각각 기록해야 합니다. ‘구독 업데이트 성공’은 가져오기와 파싱이 어느 정도 완료됐다는 의미일 뿐 서버마다 실제 접속 테스트를 통과했다는 뜻은 아닙니다.

진입점에서 인증 정보가 바뀌면 이전 목록에 정상적인 이름이 표시되더라도 연결되지 않을 수 있습니다. 반대로 업데이트 요청은 실패했지만 기존 항목은 계속 사용할 수 있습니다. 기존 목록을 보존하면 문제가 어느 단계에서 생겼는지 판단하는 데 도움이 되지만 로컬 캐시를 계속 사용할 수 있다고 보장하지는 않습니다. 업데이트 결과가 이상하다면 이후 일괄 작업을 멈추고 진입점 상태와 원본 자료를 확인하세요. 확인되지 않은 같은 주소로 구독 전체를 바로 삭제하고 다시 만들지 마세요.

업데이트 주기와 로컬 수정의 관계

업데이트는 보유한 구독 자료에 변경 안내가 왔거나 항목이 작동하지 않거나 기기를 옮기기 전처럼 실제 변경이 예상될 때 진행하세요. 현재 화면에서 자동 업데이트를 설정할 수 있다면 기기 네트워크와 사용 습관을 고려해 활성화 여부를 결정합니다. 자동 업데이트가 매번 성공하는 것은 아니며 결과 확인을 대신하지 않습니다. 네트워크가 제한적이거나 데이터를 절약해야 한다면 백그라운드 가져오기도 네트워크 요청이라는 점을 고려하세요. 로컬 새로고침과는 다릅니다.

구독 항목을 로컬에서 수정하기 전에 업데이트로 변경 내용이 덮어써질 수 있다는 점을 확인하세요. 특정 항목을 장기간 별도로 관리해야 한다면 앱에서 지원하는 경우 독립 항목으로 저장하고 관리 방식을 표시하세요. 원래 구독은 기존 주소로 계속 관리합니다. 같은 서버 정보를 자동 관리와 수동 관리 대상으로 동시에 두지 마세요. 업데이트 후 어떤 자료를 기준으로 각 필드를 확인해야 할지 모호해지고 문제를 진단할 때 서로 다른 사본을 테스트할 수 있습니다.

앱 업데이트와 구독 업데이트는 구분해야 합니다. 앱 업데이트는 App Store에서 관리하고 구독 업데이트는 사용자가 보유한 연결 정보를 가져옵니다. 앱을 업데이트해도 없는 구독 정보가 자동으로 추가되지 않으며, 구독을 업데이트해도 앱 자체는 바뀌지 않습니다. 구매, 앱 다시 받기 및 시스템 요구 사항은 구입한 앱 복원 안내를 참고하세요. 연결 및 파싱 문제는 자주 묻는 질문에서 확인할 수 있습니다.

06 / ORGANIZATION

여러 구독 정리및 정책 연결

여러 구독을 관리할 때는 항목을 더 긴 목록 하나로 합치는 것보다 각 항목의 소속을 추적할 수 있게 유지하는 것이 중요합니다. 구독마다 세 가지를 파악할 수 있어야 합니다. 어떤 주소에서 업데이트하는지, 어떤 서버가 포함되는지, 현재 사용하는 항목을 누가 관리하는지입니다. 소속이 분명하지 않으면 같은 이름의 서버가 서로 다른 주소에서 왔을 수 있습니다. 하나를 업데이트하고 다른 하나도 반영됐다고 오해할 수 있으며 이후 테스트, 삭제, 백업에도 판단 오류가 생깁니다.

먼저 그룹 이름을 정하고 예외 항목을 구분

‘일상용 자료 A’, ‘테스트 자료 B’처럼 용도와 직접 정한 식별자를 사용해 짧고 일관된 메모를 붙이세요. 이름에 전체 주소나 인증 정보를 넣지 마세요. 수동 추가한 항목은 로컬에서 관리한다는 점을 분명히 표시합니다. 좁은 화면에서도 이름 앞부분만으로 구분할 수 있도록 하고 모든 항목을 똑같이 긴 접두사로 시작하지 마세요. 프로토콜이나 지역 정보는 필터링에 도움이 될 수 있지만 업데이트에 따라 바뀔 수 있으므로 출처를 구분하는 기준을 대신하지는 못합니다.

이름이 같다고 반드시 중복은 아니며 이름이 다르다고 서로 다른 항목인 것도 아닙니다. 중복 여부를 확인할 때는 표시 이름만 비교하지 말고 프로토콜, 호스트, 포트, 인증 정보, 전송 매개변수를 함께 살펴보세요. 서로 다른 구독에 같은 연결 정보가 들어 있다면 두 주소의 관리 관계를 모두 유지할지 먼저 결정하세요. 진입점을 보존한다고 모든 항목을 동시에 사용할 필요는 없습니다. 로컬 사본 하나를 삭제해도 다른 구독에서 같은 정보가 다시 제공되는 것과는 무관합니다.

목록 관리와 라우팅 선택은 별도로 확인

서버 목록은 ‘선택할 수 있는 연결 대상’을 보여 주고 Global Routing은 ‘요청을 어떤 방식으로 처리할지’를 결정합니다. Config 상태에서는 현재 활성화된 설정의 규칙과 정책도 이해해야 합니다. 그룹을 정리한 뒤 자주 사용하는 정책이 고정 항목, 현재 선택 항목, 또는 다른 설정에서 정의한 대상을 참조하는지 확인하세요. 목록 맨 위에 서버가 있다고 해서 모든 규칙이 자동으로 그 서버를 사용한다고 생각하지 마세요.

위 표는 관리 계층을 구분하기 위한 것으로 개별 설정 점검을 대신하지 않습니다. 특히 Config에서는 특정 요청이 DIRECT 규칙에 일치하면 현재 서버를 사용할 수 없어도 요청이 성공할 수 있습니다. 반대로 목록에서 서버를 바꿔도 특정 정책이 참조하는 대상이 함께 바뀐다는 보장은 없습니다. 정리한 뒤에는 연결 스위치나 목록에서 선택된 위치만 볼 것이 아니라 실제 요청과 확인 가능한 진단 정보를 통해 경로를 확인하세요.

작은 범위로 변경해 관리 편의성 유지

한 번에 구독 하나만 정리하세요. 먼저 메모를 수정하고 소속을 확인한 다음 명확한 중복 항목을 처리하고 자주 사용하는 요청을 다시 테스트합니다. 그룹을 하나씩 정리할 때마다 사용 가능한 상태를 유지하세요. 업데이트, 이름 변경, 삭제, 규칙 수정을 한꺼번에 진행하지 마세요. 용도가 불분명한 항목은 바로 지우지 말고 확인이 필요하다고 표시하세요. 앱에서 필터나 접기 기능을 제공한다면 아직 확인하지 않은 정보를 삭제해 목록을 짧게 만들기보다 이런 표시 기능을 활용하세요.

구독을 업데이트하면 이름과 항목이 새로 생성될 수 있으므로 이름을 기준으로 항목을 찾는 정책도 다시 확인해야 합니다. 이름에 포함된 지역이나 용도를 기준으로 자동 선택하는 조건은 이름이 바뀌면 다른 항목을 선택할 수 있습니다. 설정을 저장하기 전에 정책에 사용할 수 있는 항목이 남아 있는지, 이미 삭제한 항목을 참조하지 않는지 확인하세요. 설정의 참조 방식부터 이해한 뒤 전체 이름 변경을 진행하는 것이 좋습니다. 읽기 편하게 바꾸려는 목적이라면 구독 메모만 수정하는 편이 영향이 적습니다.

구독이 여러 개라고 연결 품질이 보장되는 것도 아니고 모든 항목을 하나씩 테스트해야 하는 것도 아닙니다. 용도가 분명한 후보 몇 개를 골라 다음 장의 방법에 따라 비교 조건을 맞추세요. 자주 사용하는 목록 밖의 항목도 원래 그룹에 보존하고 필요할 때 확인할 수 있습니다. 이런 정리 방식은 업데이트 관계를 유지하면서 연결 전에 많은 이름을 다시 구분해야 하는 부담을 줄여 줍니다. 모두 지운 뒤 다시 만드는 것보다 장기적으로 변경 내역을 확인하기 쉽습니다.

07 / CONNECTIVITY TEST

지연 시간 테스트및 목록 정렬

지연 시간 테스트는 특정 시점에 특정 테스트 방식으로 측정한 응답 결과입니다. 웹페이지 로딩 속도, 지속적인 전송 성능, 모든 대상에 대한 접속 가능 여부와 같지 않습니다. 테스트 방식마다 확인하는 연결 단계가 다르므로 비교 전에 동일한 방식인지 확인해야 합니다. 한 번 측정한 숫자가 낮다는 것은 해당 측정에서 대기 시간이 짧았다는 뜻일 뿐입니다. 실제 요청에 추가 도메인 조회, TLS 핸드셰이크, 대상 서버 처리 과정이 필요하면 체감 속도는 달라질 수 있습니다.

테스트 조건부터 일정하게 유지

같은 네트워크 환경을 선택하고 테스트 도중 Wi-Fi와 셀룰러 네트워크를 바꾸지 마세요. 기기에서 대량 전송이 동시에 진행되지 않는지 확인한 뒤 같은 후보 목록에서 Connectivity Test 또는 현재 화면의 테스트 기능을 실행합니다. 방식이나 대상을 선택할 수 있다면 동일한 설정을 유지하세요. 결과에는 숫자뿐 아니라 테스트 방식과 네트워크 유형도 기록하는 것이 좋습니다. 그래야 다음에 결과가 달라졌을 때 서버가 바뀐 것인지 테스트 조건이 달라진 것인지 구분할 수 있습니다.

TCP 계열 테스트는 일반적으로 연결 포트의 응답을 확인하는 데 가까우며 프로토콜 인증이나 대상 접속까지 완료하는 것은 아닙니다. 실제 요청을 보내는 방식은 더 많은 단계를 확인할 수 있지만 결과는 테스트 대상에 따라 달라집니다. 포트에 접속할 수 있어도 비밀번호가 맞는 것은 아니며 테스트 대상에 접속할 수 있어도 모든 웹사이트에 접속할 수 있는 것은 아닙니다. 현재 앱에서 제공하는 테스트 방식에 따라 결과를 해석하세요. 서로 다른 방식의 수치를 그대로 나열해 안정성을 판단하지 마세요.

시간 초과, 변동, 실제 사용 경험을 따로 판단

시간 초과가 서버를 영구적으로 사용할 수 없다는 뜻은 아닙니다. 현재 네트워크, 이름 조회, 패킷 손실, 테스트 대상 또는 서버 상태가 원인일 수 있습니다. 우선 일부 항목만 다시 테스트하고 사용 가능한 것으로 알려진 항목과 비교하세요. 모든 후보에서 동시에 문제가 생기면 기기 네트워크와 테스트 설정을 먼저 확인하고, 한 항목만 계속 실패하면 해당 항목의 주소, 포트, 인증 정보를 점검합니다. 한 번 시간 초과됐다고 여러 항목을 삭제하거나 한 번 성공했다고 설정에 문제가 없다고 단정하지 마세요.

같은 조건에서 시간을 두고 몇 차례만 테스트해 반복적으로 큰 변동이 있는지 살펴보는 편이 한 번의 최저 수치만 좇는 것보다 유용합니다. 테스트를 너무 자주 실행하면 추가 요청이 발생하므로 끝없이 반복하지 마세요. 이후 후보 항목을 선택해 자주 사용하는 웹사이트에 실제 요청을 보내고 계속 로드되는지, 필요한 상호작용이 가능한지 확인하세요. 실제 사용 검증은 업무와 사용 목적에 맞춰야 합니다. 가벼운 웹페이지 하나만 열어 보고 모든 작업에 문제가 없다고 결론 내리면 안 됩니다.

정렬은 목록 표시 순서만 바꿉니다

지연 시간순으로 정렬하면 후보를 빠르게 찾을 수 있지만 정렬 결과는 일반적으로 측정 당시의 목록일 뿐 영구 우선순위가 아닙니다. 목록 맨 위에 있다고 현재 선택된 항목이거나 Config의 모든 정책이 사용하는 항목이라는 뜻은 아닙니다. 정렬한 뒤에는 선택 표시와 그룹 소속을 다시 확인하세요. 설정의 자동 선택 기능을 사용한다면 테스트 대상과 선택 기준도 별도로 확인해야 합니다. 직접 정렬한 결과를 정책 설정의 대체물로 여기지 마세요.

지역 이름과 프로토콜 유형도 참고 정보일 뿐입니다. 표시된 지역은 관리자가 붙인 이름일 수 있어 실제 요청 경로를 모두 설명하지 못합니다. 특정 네트워크에서 잘 작동한 프로토콜도 다른 환경에서는 결과가 달라질 수 있습니다. 이름만 보고 결론 내리지 말고 실제로 사용하는 네트워크에서 비교하세요. 자세한 선택 방법은 지연 시간, 지역 및 프로토콜 유형 확인 방법을 참고하세요. 핵심은 테스트 조건을 서로 비교할 수 있게 유지하는 것입니다.

진단 정보로 예상한 정책을 적용했는지 확인

테스트 결과는 정상인데 대상에 접속할 수 없다면 Global Routing에서 해당 요청이 실제로 어떤 정책을 사용하는지 먼저 확인하세요. 아래 예시는 예시 도메인에 PROXY를 사용하고 중국 지역 IP와 일치하는 요청에는 DIRECT를, 나머지 요청에는 PROXY를 사용합니다. 규칙은 순서대로 확인됩니다. 이 예시는 동작 설명용이므로 기존 설정을 이해하지 않은 채 전체를 덮어쓰면 안 됩니다. 요청마다 다른 정책이 적용되면 같은 서버를 선택해도 접속 결과가 달라질 수 있습니다.

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

진단할 때는 ‘테스트 응답 여부’, ‘프로토콜 연결 여부’, ‘규칙이 예상한 정책을 선택했는지’, ‘대상에서 정상 응답을 받았는지’를 각각 기록하세요. 그래야 입력값을 바꿀지, 서버를 전환할지, 규칙을 조정할지 판단할 수 있습니다. 모든 문제를 지연 시간만으로 설명하면 인증 오류, 잘못된 규칙 매칭, 대상 자체의 문제를 놓칠 수 있으며 필요하지 않은 설정 변경으로 정상적인 구독 구조를 망가뜨릴 수 있습니다.

08 / BACKUP & REMOVE

삭제, 백업및 복원 확인

삭제하기 전에 대상이 서버 항목 하나인지, 구독 전체인지, Config의 설정 파일인지 명확히 확인하세요. 각각 영향을 미치는 범위가 다릅니다. 서버 항목을 삭제하면 로컬 목록에 영향을 줄 수 있고 구독을 삭제하면 해당 관리 진입점을 잃으며 설정을 삭제하면 라우팅 동작이 바뀔 수 있습니다. 앱에서 로컬 항목을 삭제하는 것과 서버 측 정보를 변경하는 것도 구분해야 합니다. 로컬 삭제만으로 구독 주소가 취소되거나 이미 공유한 인증 정보가 무효화되지는 않습니다. 정보가 유출됐다면 기기 목록을 비우는 데 그치지 말고 원래 인증 정보를 처리해야 합니다.

스크린샷만이 아니라 단계별로 백업

첫 번째 단계에는 구독 주소와 소속 메모, 두 번째 단계에는 독립적으로 관리하는 수동 항목의 필수 필드, 세 번째 단계에는 현재 활성화한 규칙 설정과 필요한 환경 설정을 보관합니다. 현재 앱에서 내보내기나 백업 기능을 제공한다면 결과에 어떤 단계가 포함되는지 먼저 확인한 뒤 직접 관리하는 안전한 위치에 파일을 저장하세요. 내보내기 대상에 따라 서버만 또는 설정만 포함될 수 있습니다. 파일이 정상적으로 만들어졌다고 모든 상태가 들어 있다고 생각하지 마세요.

스크린샷은 선택 위치와 작업 중 발생한 현상을 기록하는 데는 유용하지만 유일한 복구 자료로는 적합하지 않습니다. 긴 주소는 화면에 모두 표시되지 않을 수 있고 숨겨진 인증 정보는 스크린샷에 저장되지 않습니다. 반면 QR 코드, 구독 매개변수, 비밀번호가 스크린샷에 노출될 수 있습니다. 복구 가능한 원본 데이터를 우선 보관하고 접근 범위를 제한하세요. 도움을 요청할 때는 별도의 스크린샷을 만들어 민감한 부분을 가리고, 전체 백업 파일을 다른 사람에게 보내지 마세요.

삭제 전에 참조 여부 확인

삭제할 항목이 현재 선택된 서버가 아닌지, 자주 사용하는 정책에서 고정 참조하고 있지 않은지 확인하세요. 구독에 포함된 항목은 개별 삭제해도 다음 업데이트에서 다시 나타날 수 있습니다. 특정 구독 관리를 중단하려는 경우 반환된 항목을 하나씩 지우지 말고 구독 진입점을 처리하세요. 수동 항목은 원본 매개변수가 백업에 저장됐는지 확인한 뒤 삭제합니다. 이름이 비슷하면 목록 위치만 보고 판단하지 말고 편집 화면을 열어 구분하세요.

Config 파일을 삭제하기 전에 현재 활성화된 파일이 무엇인지 확인하고 필요한 내용을 저장한 뒤 사용할 수 있는 대체 설정을 준비하세요. 서버만 삭제해도 규칙의 참조가 자동으로 수정되지는 않으며 규칙 설정을 삭제해도 구독 주소가 취소되지는 않습니다. 여러 항목을 정리할 때는 ‘백업, 확인, 일부 삭제, 연결 재테스트’ 순서로 진행하세요. 단계마다 확인된 상태로 돌아갈 수 있어야 한꺼번에 모두 지운 뒤 빠진 정보를 찾는 것보다 영향을 관리하기 쉽습니다.

복원 후 단계별로 확인

새 기기를 사용하거나 재설치한 뒤에는 먼저 App Store에서 구입한 앱을 다시 받으세요. 절차는 구입 항목 복원을 참고하세요. 앱 구매 기록과 서버 데이터는 별개이므로 앱을 다시 받아도 모든 연결 정보가 자동으로 복구되는 것은 아닙니다. 시스템 요구 사항과 구매 가능 여부는 App Store 페이지의 안내를 따릅니다. 데이터 복원 시 시스템 백업에 모든 항목이 반드시 포함된다고 가정하지 말고 실제 결과를 확인하세요.

먼저 구독 하나 또는 수동 항목 하나를 복원해 입력값을 확인하고 연결을 테스트한 뒤 다른 그룹을 복원하세요. 구독을 다시 가져온 후에는 예전 스크린샷과 항목 개수만 비교하지 말고 현재 목록을 확인합니다. 그다음 규칙 설정을 복원하고 Global Routing 선택, 현재 서버, 정책 참조를 확인하세요. 마지막으로 필요한 On Demand 설정 등을 점검합니다. 처음 연결할 때는 시스템 안내에 따라 VPN 설정 권한을 허용해야 합니다. 복원 파일로 시스템 권한 확인을 대신할 수 없습니다.

이전 백업에 포함된 주소와 인증 정보가 만료됐을 수 있으므로 복원 실패가 파일 손상을 의미하는 것은 아닙니다. 가져오기 가능 여부, 구독 업데이트 여부, 서버 연결 여부를 각각 따로 확인하세요. 백업의 이름이 새 목록과 다를 수도 있으므로 고정 참조도 다시 점검해야 합니다. 복원에 성공한 뒤 현재 상태를 기록하고 이전 백업과 확인이 끝난 새 백업을 명확히 구분하세요. 그래야 다음에 아직 확인되지 않은 자료를 잘못 사용하지 않습니다.

필요한 사본만 보관하고 더 이상 사용하지 않는다고 확인된 민감 자료는 정기적으로 정리하세요. 수정한 규칙과 수동 항목은 백업에 반영하되 임시 테스트마다 구분하기 어려운 사본을 많이 만들 필요는 없습니다. 복원 중 문제가 계속되면 실패 단계, 수행한 작업, 민감 정보를 가린 오류 내용을 정리해 자주 묻는 질문을 참고하세요. 작업 순서를 처음부터 다시 확인하려면 사용 안내로 돌아가 단계별로 점검하세요.