공식 매뉴얼 / 구독 및 서버 관리

Shadowrocket 구독 및 서버 관리 안내서

가져올 항목의 종류를 먼저 확인한 뒤 필드를 점검하고 업데이트와 백업을 관리하세요. 목록에 항목이 표시된다고 연결까지 정상인 것은 아닙니다.

처음 사용한다면 시작 가이드를 따라 가져오기, 선택, 연결의 기본 흐름을 먼저 완료하세요. 이 페이지에서는 기본 흐름만으로 해결되지 않는 필드 차이, 중복 항목, 업데이트 실패와 복구 문제를 다룹니다. 문제가 발생한 단계를 알고 있다면 목차에서 해당 장으로 바로 이동할 수 있습니다.

1. Subscribe 구독 추가 및 첫 가져오기

구독은 원격 주소에서 서버 목록을 가져오고 이후 업데이트를 이어서 관리하는 기능입니다. 서버 항목 하나는 연결 대상 하나의 정보를 담으므로, 둘 다 ‘추가’할 수 있다고 해서 같은 방식으로 다루면 안 됩니다. 가져오기 전에 받은 정보가 구독 주소인지, 단일 서버 공유 링크인지, 전체 설정 텍스트인지 확인하세요. 웹페이지 제목이나 파일 확장자는 참고만 하고, 용도는 서비스 제공업체의 안내를 기준으로 판단해야 합니다.

구독·서버·설정의 차이부터 확인

구독은 서버 목록을 관리하고, 서버 항목은 연결 매개변수를 저장하며, Config(설정)는 규칙 등의 설정 내용을 관리합니다. 구독을 가져왔다고 해서 Config(설정)의 규칙까지 교체되는 것은 아닙니다. 설정 파일을 가져왔다고 서버 인증 정보가 모두 준비된 것도 아닙니다. 먼저 변경하려는 대상이 어느 계층인지 기록하고, 작업 후 해당 계층만 확인하면 매개변수 누락을 라우팅 문제로 오해하는 일을 줄일 수 있습니다.

가져오기를 준비할 때는 서비스 제공업체에서 전체 구독 링크를 받으세요. 안내 페이지나 로그인 페이지 주소, 브라우저 주소창에서 리디렉션된 페이지를 구독 주소로 사용하지 마세요. 링크에는 물음표 뒤에 인증 매개변수가 포함될 수 있으므로 전체 주소를 복사해야 합니다. 채팅 앱에서 일부만 표시된다고 해서 복사된 내용도 완전하다고 볼 수는 없습니다. 보호된 로컬 텍스트에 붙여넣어 시작과 끝이 맞는지, 줄바꿈이 섞이지 않았는지 확인하는 것이 좋습니다.

Add Server에서 Subscribe 선택

Home(홈)으로 이동해 추가 버튼을 눌러 Add Server(서버 추가)를 여세요.
Type(유형)에서 Subscribe(구독)를 선택하세요. 일반 프로토콜 유형에 구독 주소 전체를 붙여넣지 마세요.
전체 주소를 URL(주소) 필드에 입력하고, 인증 정보가 들어가지 않은 알아보기 쉬운 메모를 설정한 뒤 저장하세요.
요청과 파싱이 끝날 때까지 기다린 다음 Home(홈)으로 돌아가 구독 그룹과 그 안의 서버가 표시되는지 확인하세요.

화면 배치에 따라 추가 버튼의 위치는 다를 수 있지만, Type(유형)이 Subscribe(구독)로 설정되고 주소가 전용 구독 필드에 입력됐는지 확인하는 기준은 같습니다. 저장하기 전에 불필요한 따옴표, 공백, 설명 문구가 포함되지 않았는지 확인하세요. 형식을 ‘수정’한다며 물음표 뒤 매개변수를 임의로 지우거나 주소를 보기 좋게 바꾸지 마세요.

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

위 예시는 ‘주소와 쿼리 매개변수’의 구조만 보여줍니다. 실제로 사용할 때는 경로, 매개변수 이름, 인증 정보를 받은 그대로 온전히 유지해야 합니다. 이 주소는 구독 목록을 가져오는 데 쓰이며, 구독에서 반환된 서버 주소와는 다릅니다. 후자는 실제 연결 대상입니다. 따라서 구독 요청 실패와 서버 연결 실패는 따로 점검해야 하며, 한쪽 테스트로 다른 쪽을 판단할 수 없습니다.

첫 가져오기 확인 및 실패 시 점검

가져온 뒤에는 최소한 세 가지를 확인하세요. 그룹 메모가 올바른지, 목록에 예상한 항목이 있는지, 항목 하나를 골랐을 때 프로토콜과 주소가 적절한지 점검합니다. 서버 수는 뚜렷한 이상을 찾는 데 참고할 수 있지만, 수만으로 구독의 품질이나 연결 상태를 판단할 수는 없습니다. 먼저 항목 하나를 선택해 연결을 확인한 다음 규칙을 조정할지 결정하세요. 실제 사용 중인 대상을 구별하기 어려워지지 않도록 이 단계에서 자동 연결 옵션을 여러 개 동시에 켜지 마세요.

저장 후 목록이 비어 있다면 오류 메시지를 보관하고 원래 주소부터 다시 확인하세요. 로그인 페이지로 돌아가거나 인증 정보가 만료됐다는 메시지가 나오거나 파싱할 수 없는 본문이 반환된다면 구독 응답 문제입니다. 항목은 표시되지만 연결에 실패한다면 이후 연결 단계의 문제입니다. 새로고침하려고 같은 구독을 계속 추가하지 마세요. 중복 그룹만 늘어납니다. 구독 업데이트 실패 및 빈 목록 점검표를 따라 원인을 확인하고, 문제 계층을 구분한 뒤 다시 시도하세요.

이미 다른 구독을 사용 중인 기기라면 첫 가져오기 전에 현재 선택된 서버와 라우팅 상태도 기록해 두세요. 새 목록을 추가한다고 기존 목록을 삭제할 필요는 없습니다. 새 목록이 검증된 뒤에 정리 작업을 진행하세요. 가져오기 결과가 예상과 달라도 기존 상태를 기준으로 되돌아가 확인할 수 있어 전체 설정을 처음부터 다시 만들 필요가 없습니다.

2. Add Server 필드 직접 입력 및 프로토콜 확인

전체 매개변수를 알고 있고 서버를 몇 개만 추가하면 되거나, 공유 링크 가져오기 결과의 차이를 필드별로 확인해야 할 때 직접 입력을 사용할 수 있습니다. Add Server(서버 추가)를 연 뒤 올바른 Type(유형)을 선택하고 해당 유형에 표시되는 필드만 입력하세요. 프로토콜을 잘못 선택하면 이름이 같은 필드라도 의미가 다를 수 있습니다. 주소와 비밀번호부터 입력한 뒤 경험에 따라 유형을 바꾸지 마세요.

공통 필드부터 정확히 입력

Address(주소)에는 서버 도메인이나 지정된 주소를 입력하세요. 구독 링크나 로그인 경로가 포함된 웹페이지 주소가 아닙니다. Port(포트)는 서버가 수신 대기하는 포트입니다. TLS를 켰다고 특정 포트라고 단정할 수 없습니다. Remarks(메모)는 기기에서 항목을 구분하기 위한 것으로 인증에는 쓰이지 않습니다. 직접 입력하기 전에 원래 매개변수와 화면을 나란히 놓고 비교하세요. 숫자 0과 문자, 반각 기호, 복사할 때 붙은 공백을 특히 주의해야 합니다.

필드 종류	확인할 내용	흔한 입력 오류
Address / Port	연결 대상 및 수신 포트	구독 주소나 웹페이지 경로 입력
Password / UUID	선택한 프로토콜에 필요한 인증 매개변수	문자 누락, 앞뒤 공백, 필드 혼용
TLS / Server Name	암호화 설정 및 인증서 이름 요건	연결 주소를 인증서 이름으로 입력
Transport / Host / Path	전송 방식 및 추가 매개변수	경로 누락 또는 대소문자 임의 변경

위 표는 필드의 종류를 설명하며, 모든 프로토콜에 같은 옵션이 표시된다는 뜻은 아닙니다. 항목이 보이지 않으면 비슷한 이름의 입력란에 대신 값을 넣지 말고 Type(유형)과 전송 방식을 먼저 확인하세요. 서비스 제공업체가 제공하지 않은 매개변수가 필요해 보이면 먼저 확인하고, 온라인의 일반적인 예시를 가져와 그럴듯한 설정으로 채우지 마세요.

인증·전송·TLS를 나누어 입력

Shadowsocks는 암호화 방식과 비밀번호를 확인해야 합니다. VMess는 UUID와 매개변수에 명시된 관련 옵션을 확인하세요. VLESS는 UUID, 전송 방식, 보안 설정을 확인해야 합니다. Trojan은 비밀번호와 TLS 관련 매개변수를 확인하세요. 이름이 비슷하다고 서로 바꿔 쓸 수 있는 것은 아닙니다. VMess와 VLESS 필드 차이는 직접 입력 필드 비교 안내를 먼저 읽은 뒤 실제 매개변수를 하나씩 점검하세요.

전송 방식과 프로토콜 유형은 서로 다른 계층입니다. 예를 들어 WebSocket을 사용한다면 Host(호스트)와 Path(경로)가 모두 필요할 수 있습니다. 경로의 슬래시, 대소문자, 쿼리 부분은 원래 값 그대로 유지하세요. TLS의 Server Name(서버 이름)은 관련 이름 검증에 사용되며 Address(주소)와 다를 수 있습니다. 연결 대상, 전송 요청의 호스트 정보, 인증서 이름은 각각 용도가 다르므로 모두 도메인처럼 보인다는 이유로 같은 값으로 바꾸면 안 됩니다.

인증서 오류가 발생해도 검증을 건너뛰는 방식으로 해결하려 하지 마세요. 먼저 기기 시간, 인증서 이름, 서비스 제공업체의 요건을 확인하고 매개변수가 바뀌지 않았는지 점검하세요. 서버 인증서 설정이 원인이라면 클라이언트 비밀번호를 계속 바꿔도 해결되지 않습니다. 문제를 점검할 때는 단순히 ‘연결 안 됨’이라고 기록하기보다 오류가 발생한 단계를 남기세요. 관련 없는 필드를 번갈아 시험하는 일을 줄일 수 있습니다.

특수 프로토콜 및 저장 후 확인

WireGuard는 키, 피어 정보, 주소, 라우팅 매개변수를 한 묶음으로 이해해야 합니다. ‘주소와 비밀번호’로 단순화할 수 없습니다. Hysteria2는 UDP 기반 전송 조건도 관련되므로 일반적인 연결 테스트 한 번으로 모든 요건을 확인할 수 없습니다. 이런 프로토콜은 받은 전체 매개변수 안내에 따라 입력하세요. 근거가 없다면 속도를 높이려고 대역폭, 라우팅, 하위 전송 옵션을 바꾸지 마세요.

저장한 뒤 방금 추가한 항목을 다시 열어 유형, 주소, 포트, 전송 옵션이 원래 내용과 일치하는지 확인하세요. 비밀번호 필드는 가려져 있을 수 있습니다. 스크린샷을 찍기 편하게 민감한 내용을 모두 표시하지 마세요. 공유 링크로 가져온 항목이 있다면 필드 매핑을 비교하는 데 참고할 수 있지만, 가져오기 결과가 자동으로 정확하다고 가정하지 마세요. 최종 기준은 서버에서 받은 전체 매개변수입니다.

직접 입력한 항목을 점검할 때는 한 번에 필드 하나만 바꾸고, 변경 전 값을 기록한 뒤 같은 방식으로 다시 테스트하세요. 주소, 포트, TLS 설정을 연달아 바꾸면 연결이 복구되어도 원인을 알 수 없습니다. 해결 후에는 필요한 차이만 비공개 기록에 남기고 용도는 메모에 적으세요. 목록 스크린샷에서 유출될 수 있으므로 비밀번호, UUID, 전체 키를 메모에 넣지 마세요.

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

QR 코드와 클립보드는 텍스트를 클라이언트로 전달하는 방법이 다를 뿐, 텍스트의 용도를 바꾸지는 않습니다. QR 코드에는 단일 서버 공유 링크나 구독 주소가 들어갈 수 있습니다. 클립보드에도 URL, 설정 조각, 여러 줄 텍스트가 들어갈 수 있습니다. 가져오기 전에 항목 하나를 받으려는 것인지 여러 항목을 받으려는 것인지 확인하고, 인식 결과에 맞는 방법을 선택하세요. 인식에 성공했다고 올바른 대상을 가져왔다는 뜻은 아닙니다.

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

Scan QR Code(QR 코드 스캔)를 사용할 때 QR 코드 전체가 화면에 들어오도록 하고, 가장자리를 선명하게 유지하며 빛 반사나 과도한 확대를 피하세요. 시스템에서 카메라 권한을 요청하면 이번 스캔에 필요한지 판단해 허용하세요. 이전에 거부했다면 시스템의 해당 권한 설정을 확인할 수 있습니다. 카메라 권한은 스캔 기능에만 관련되며 VPN 구성 승인이나 연결 가능 여부를 뜻하지 않습니다.

QR 코드가 다른 기기에 표시되어 있다면 바로 스캔할 수 있습니다. 현재 기기의 사진에 저장된 경우에는 스캔 화면에서 이미지 인식을 실제로 지원할 때만 해당 기능을 사용하세요. 그런 옵션이 없다면 서비스 제공업체가 함께 제공한 원본 텍스트를 사용하세요. 화면을 반복해서 촬영하거나 출처가 불분명한 변환 페이지를 이용하지 마세요. QR 코드 이미지에 인증 정보가 포함될 수 있으므로 저장, 전송, 표시할 때 민감 정보로 취급해야 합니다.

인식 후 결과 요약부터 확인하세요. Add Server(서버 추가)가 열리는지, Subscribe(구독) 주소로 인식됐는지, 주소와 메모가 예상과 일치하는지, 무관한 페이지로 이동하라는 안내가 없는지 살펴보세요. 예상과 다른 대상으로 인식됐다면 취소하고 원래 안내를 다시 확인하세요. 문자를 해독할 수 있다는 것은 이미지에서 문자를 읽어냈다는 뜻일 뿐, 해당 문자가 현재 가져오기 경로에 적합하다는 뜻은 아닙니다.

클립보드에서 가져올 때는 내용이 온전한지 확인

공유 텍스트를 복사한 뒤 클라이언트에 실제로 제공되는 클립보드 가져오기 기능을 사용하세요. 시스템에서 붙여넣기를 허용할지 묻는다면 이번 작업에 맞게 승인하세요. 복사 완료와 붙여넣기 성공은 별개의 단계입니다. 클립보드 내용은 이후 다른 내용을 복사하면서 바뀔 수 있고, 보이는 제목만 복사되어 실제 링크는 포함되지 않을 수도 있습니다. 가져오기 반응이 없다면 클라이언트를 바로 다시 설치하지 말고 클립보드에 어떤 종류의 내용이 있는지 먼저 확인하세요.

여러 줄 텍스트는 시작과 끝을 잘못 처리하기 쉽습니다. 공유 링크 하나는 전체를 온전히 유지해야 하며, 화면에 자동으로 줄이 바뀌어 보이는 것과 실제 줄바꿈 문자가 들어 있는 것은 다릅니다. 복사한 내용에 설명 문단, 목록 번호, 따옴표가 섞여 있다면 명확한 링크 본문만 분리하세요. 내용이 통째로 가져와야 하는 설정이라면 문단을 임의로 삭제하면 안 됩니다. 대상에 따라 정리 방법이 다르므로 모든 텍스트를 같은 방식으로 잘라내지 마세요.

원본 안내를 확인해 구독, 단일 서버 공유 링크, 설정 중 무엇인지 구분합니다.
설명 문구가 섞이지 않도록 본문 전체를 복사합니다.
해당하는 가져오기 기능을 사용하고 인식 결과를 확인한 뒤 저장합니다.
목록으로 돌아가 새 항목을 확인하고 기존 항목이 중복으로 추가되지 않았는지 살펴봅니다.

인식 실패와 권한 문제는 따로 점검

QR 코드 스캔은 실패했지만 원본 텍스트는 가져올 수 있다면 이미지 선명도와 QR 코드 전체가 들어갔는지부터 확인하세요. 원본 텍스트도 인식되지 않으면 링크 접두사, 문자 누락, 프로토콜 지원 여부를 점검합니다. QR 코드의 모서리를 잘라낸 채 계속 시도하지 마세요. 여백과 위치 탐지 패턴도 인식에 필요합니다. 이미지 조건이나 텍스트 내용 중 한 번에 하나만 바꿔야 어느 단계가 달라졌는지 알 수 있습니다.

붙여넣기 기능이 내용을 읽지 못하면 시스템 권한을 허용했는지, 복사한 뒤 클립보드를 바꾸는 다른 작업을 했는지 확인하세요. 내용을 인식했지만 저장에 실패했다면 권한이 아니라 매개변수와 응답을 점검해야 합니다. 권한은 ‘읽을 수 있는지’를 해결하고 매개변수는 ‘읽은 내용을 사용할 수 있는지’를 결정하므로 각각 확인해야 합니다.

가져오기가 끝난 뒤 일반 텍스트를 복사해 현재 클립보드 내용을 덮어쓰면 이후 잘못 붙여넣을 가능성을 줄일 수 있습니다. 하지만 이는 모든 기록이나 기기 간 복사본을 삭제하는 방법은 아닙니다. 임시 이미지, 채팅 첨부 파일, 다른 기기에 저장된 복사본은 각각 관리해야 합니다. 내용이 이미 공개됐다면 클립보드를 비우는 것만으로 접근을 막을 수 없습니다. 서비스 제공업체에 인증 정보 처리 방법을 문의하고 기존 인증 정보의 상태를 확인하세요.

4. 공유 링크 형식과 설정 구문 구분

공유 링크는 서버 매개변수를 텍스트로 인코딩한 것이며, 가져오기 기능이 이를 해당 필드에 매핑합니다. 프로토콜마다 구조가 다르므로 긴 문자열처럼 보인다는 이유로 내부 형식까지 같다고 보면 안 됩니다. 문제를 점검할 때는 접두사, 본문, 매개변수 순으로 확인하세요. 모든 링크를 일괄 디코딩하거나 다시 인코딩하고 기호를 바꾸면 원래 유효한 내용이 손상될 수 있습니다.

길이가 아니라 구조를 기준으로 읽기

vless://[email protected]:443?security=tls&type=ws&host=example.com&path=%2Fws#Example

이 예시는 필드 구조를 설명하기 위한 것입니다. 접두사는 VLESS를 나타내고, 사용자 정보 위치에는 예시 UUID가 들어 있습니다. 도메인과 포트는 연결 대상을 나타내며, 물음표 뒤에는 보안 및 전송 매개변수가, 샵 기호 뒤에는 보통 메모로 표시할 문자열이 들어갑니다. 이 가상 값은 실제 인증 정보가 아닙니다. 구조를 읽으면 누락된 항목을 찾는 데 도움이 되지만, 임의의 서버 정보를 조합해 사용할 수 있는 링크를 만들 수 있는 것은 아닙니다.

구조상 위치	예시 내용	확인할 점
프로토콜 접두사	`vless://`	실제 프로토콜 유형과 일치하는지
인증 정보	`your-uuid`	문자가 빠짐없이 들어 있고 공백이 붙지 않았는지
연결 대상	`example.com:443`	주소와 포트가 각각 올바르게 매핑되는지
쿼리 매개변수	`security=tls&type=ws`	매개변수 이름, 값, 인코딩이 온전한지
표시용 메모	`#Example`	항목 식별에만 사용하며 연결 매개변수를 대체하지 않음

예시의 %2F는 인코딩된 슬래시를 뜻합니다. 링크를 전달할 때 일부 문자는 구분 기호로 잘못 처리되지 않도록 인코딩해야 합니다. 반면 Add Server(서버 추가)의 개별 필드에는 보통 해당 필드에 사용할 실제 값이 들어가야 합니다. 링크의 매개변수 전체를 경로 필드에 그대로 넣지 말고, 이미 올바르게 디코딩된 값을 다시 디코딩하지 마세요. 확인할 때는 링크 텍스트가 비슷한지만 보지 말고 최종 필드 값을 살펴보세요.

접두사에 따라 읽는 방식이 다름

Shadowsocks 공유 형식에는 인코딩된 인증 정보가 포함될 수 있습니다. VMess는 내부 필드를 확인하려면 인코딩 내용을 먼저 파싱해야 하는 경우가 많습니다. Trojan과 VLESS는 겉모양이 비슷할 수 있지만 인증 필드와 보안 요건은 다릅니다. 접두사만 바꿔 한 프로토콜을 다른 프로토콜로 변환할 수는 없습니다. 내용을 인식할 수 없다면 임의로 변환 규칙을 추측하지 말고 원본 형식과 클라이언트 지원 여부부터 확인하세요.

구독 주소는 보통 서버 목록을 요청하는 데 사용됩니다. 일반 웹 주소처럼 보일 수 있지만 응답 내용은 클라이언트가 인식할 수 있는 구독 형식이어야 합니다. 주소가 보안 연결로 시작한다고 해서 반환 내용이 반드시 구독인 것은 아닙니다. 로그인 페이지나 오류 페이지도 정상적으로 반환될 수 있습니다. 가져오기 결과와 오류 메시지를 함께 확인하고, 형식을 문의하려고 공개된 장소에 전체 요청 주소를 올리지 마세요.

공유 링크와 Config 규칙 텍스트는 다름

Config(설정)의 규칙은 트래픽이 어떤 조건과 정책에 따라 처리되는지 설명하며, 개별 서버의 공유 링크가 아닙니다. 아래 조각은 특정 도메인과 주소 범위를 먼저 매칭한 뒤, 나머지 트래픽은 마지막 기본 규칙으로 처리하는 구조를 보여줍니다. 이는 설정의 규칙 부분일 뿐 완전한 설정을 대체할 수 없으며, PROXY라는 이름의 실제 연결 대상을 자동으로 제공하지도 않습니다.

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXY

규칙은 순서대로 매칭됩니다. 먼저 일치한 규칙이 적용되면 뒤에 개인적인 기대에 더 부합하는 규칙이 있어도 다시 선택되지 않습니다. PROXY와 DIRECT는 정책 키워드이므로 임의로 다른 말로 바꾸면 안 됩니다. 설정에서 정책이 무엇을 가리키는지, 현재 어떤 서버를 선택했는지, Global Routing(전역 라우팅)이 어떤 상태인지 각각 확인하세요. 목록을 가져온 것만으로 해결되는 것은 이 중 일부뿐입니다.

‘서버 응답 테스트는 되지만 특정 웹페이지의 연결 경로가 잘못됐다’면 공유 링크를 다시 만들기 전에 어떤 설정과 규칙이 적용되는지 확인하세요. REJECT 관련 문제는 REJECT 규칙과 매칭 범위를 참고하세요. 링크 파싱 문제와 규칙 매칭 문제를 분리해야 유효한 인증 매개변수를 불필요하게 바꾸지 않을 수 있습니다.

원본 링크를 보관할 때는 단일 서버인지 구독 주소인지, 용도와 받은 경로도 함께 기록하세요. 메모만으로 판단하지 마세요. 메모는 중복될 수 있고 업데이트 과정에서 바뀔 수도 있습니다. 링크 두 개를 비교할 때는 로컬에서 차이를 확인하고 민감한 필드를 가린 뒤 결과를 기록하세요. 원문을 일반 메모처럼 공유하지 마세요.

5. 구독 업데이트 방식 및 실패 복구

구독을 업데이트하면 원래 주소에 다시 요청을 보내고, 반환 내용에 따라 해당 구독에 연결된 서버 목록을 조정합니다. 클라이언트 전체를 새로고침하거나 App Store의 앱을 업데이트하는 기능은 아닙니다. 먼저 업데이트하려는 대상이 서버 목록인지, Config(설정) 내용인지, 앱 자체인지 구분한 뒤 해당 기능을 이용하세요. 세 대상은 업데이트 시점과 실패 원인이 서로 다릅니다.

업데이트 전 비교할 상태를 기록

수동 업데이트 전에는 현재 구독 메모, 선택된 항목, 목록의 대략적인 구성을 기록하세요. 서버를 사용 중이라면 업데이트로 항목이 삭제되거나 이름이 바뀌어 기존 선택이 같은 대상을 가리키지 않을 수 있다는 점도 유의해야 합니다. 중요한 작업 전에는 유효한 정보를 비공개로 복사해 두는 것이 실패 후 기억에 의존해 다시 만드는 것보다 안전합니다. 다만 전체 필드가 보이지 않는 목록 스크린샷만 백업으로 남기지는 마세요.

업데이트 기능은 기존 구독을 대상으로 사용하세요. 매번 같은 URL(주소)을 다시 추가할 필요는 없습니다. 완료 후에는 오류 메시지, 항목 변화, 현재 선택을 확인하세요. 잠깐 표시되는 새로고침 애니메이션만 보고 판단하면 안 됩니다. 목록이 그대로여도 원격 내용에 변화가 없었을 수 있으므로 요청 실패를 단정할 수 없습니다. 반대로 항목 수가 바뀌었다고 해서 모든 매개변수가 예상대로 맞는 것도 아닙니다.

요청·응답·파싱의 세 단계로 점검

첫 번째 단계에서는 현재 네트워크, 도메인 확인, 연결 상태 등 구독 주소에 요청이 도달할 수 있는지 확인합니다. 두 번째 단계에서는 반환 내용이 예상한 내용인지, 로그인 안내나 접근 오류 또는 인증 만료 안내가 아닌지 살펴봅니다. 세 번째로 파싱을 점검합니다. 내용이 비어 있는지, 형식이 지원되는지, 텍스트가 잘리지 않았는지 확인하세요. 단계를 나누면 ‘업데이트 실패’ 메시지만 보고 구독 요청과 보통 무관한 서버 비밀번호를 바꾸는 일을 피할 수 있습니다.

특정 네트워크에서만 실패한다면 가능할 때 다른 기존 네트워크로 확인한 뒤 오류가 발생한 단계를 비교하세요. 전체 구독 주소를 공개 테스트 도구에 붙여넣지 마세요. 쿼리 매개변수가 접근 인증 정보일 수 있습니다. 브라우저에서 본문이 표시되어도 이는 브라우저가 이번에 내용을 받았다는 뜻일 뿐, 클라이언트 요청이 같은 네트워크 조건과 응답 형식을 사용한다는 보장은 아닙니다.

계정 상태나 인증 정보 관련 메시지가 나오면 서비스 제공업체에서 현재 유효한 정보를 받고 구독 주소를 교체해야 하는지 확인하세요. 쿼리 매개변수를 지우거나 경로를 짧게 줄이고 대소문자를 바꾸며 시험하지 마세요. 주소를 바꿔야 한다면 기존 그룹과 현재 선택을 먼저 기록하고, 변경 후 새 목록을 확인한 다음 중복 항목을 정리하세요. 기존 주소가 만료된 것과 새 주소가 작동하는 것은 각각 따로 확인해야 합니다.

추적 가능한 방식으로 자동 업데이트 관리

Settings(설정)에 구독 자동 업데이트 옵션이 있다면 먼저 실행 조건을 읽고 실제 필요에 따라 활성화하세요. 시스템의 백그라운드 실행은 기기 상태와 시스템 스케줄에 영향을 받으므로 정해진 시간에 반드시 실행되는 작업으로 보면 안 됩니다. 앱을 오랫동안 열지 않았거나 네트워크가 바뀌었거나 백그라운드 실행이 제한된 경우에는 실제 목록과 수동 확인 결과를 기준으로 판단하세요. 설정한 시간만 보고 업데이트 성공을 추측하지 마세요.

‘최신 상태 유지’를 위해 짧은 간격으로 반복 요청할 필요도 없습니다. 지나치게 자주 시도하면 이전과 이후 상태를 비교하기 어려워지고 원격 요청 제한에 걸릴 수도 있습니다. 문제를 점검할 때는 반복 시도를 멈추고, 오류 정보를 한 번 온전히 기록한 뒤 확인을 마치고 다시 추적 가능한 방식으로 시도하세요. 복구되면 항목 하나를 골라 연결을 확인해 업데이트가 기존 매개변수나 선택 관계를 바꾸지 않았는지 점검하세요.

업데이트 후 목록이 비었다면 정리와 삭제를 멈추고 기존에 사용 가능한 정보를 보관하세요. 원격에서 실제로 빈 내용을 반환했을 수도 있고 형식이나 인증 정보 문제일 수도 있으므로 화면이 비었다는 이유만으로 원인을 단정할 수 없습니다. 5단계 점검표를 따라 확인한 뒤 복구되면 이전과 이후의 항목을 비교하세요. 오류 유형에 대한 자세한 내용은 자주 묻는 질문에서 살펴볼 수 있습니다.

업데이트 후에는 실행 이유, 성공 여부, 목록 변화 여부, 연결을 다시 테스트했는지 간단히 기록하세요. 인증 정보를 기록하거나 고정된 업데이트 주기를 임의로 정할 필요는 없습니다. 다음에 문제가 생겼을 때 비교할 출발점을 남기는 것이 목적이며, 모든 변화를 클라이언트 설정 탓으로 돌리기 위한 기록이 아닙니다.

6. 여러 구독 정리 및 설정 관계

여러 구독을 관리할 때 중요한 것은 모든 항목을 하나의 긴 목록으로 합치는 것이 아닙니다. 출처를 구분하고 현재 선택을 명확히 하며 업데이트와 삭제가 어디에 속하는지 추적할 수 있어야 합니다. 정리 전에 구독으로 관리되는 항목과 직접 추가한 항목을 구분하세요. 이름이 같다고 같은 목록에 속하는 것은 아니며, 주소가 같다는 이유만으로 두 기록이 완전히 동일하다고 볼 수도 없습니다.

메모에는 용도를 적고 비밀은 기록하지 않기

구독 메모에는 ‘일상 연결 A’, ‘예비 테스트 B’처럼 본인이 알아볼 수 있는 용도와 번호를 사용하세요. 모든 프로토콜 필드를 메모에 늘어놓거나 비밀번호, 전체 구독 주소, 인증 매개변수를 넣지 마세요. 서버 표시 이름은 원격 내용에서 정해져 업데이트 중에 바뀔 수 있습니다. 따라서 로컬 관리 기록에는 항목 이름만 적기보다 ‘어느 구독에 속하는지, 어떤 용도로 쓰는지’를 남기는 것이 좋습니다.

중복 항목은 대개 같은 내용을 반복해서 가져왔거나, 직접 추가한 항목과 구독 항목을 모두 보관했거나, 서로 다른 목록에 같은 연결 대상이 들어 있어 생깁니다. 중복인지 판단할 때는 프로토콜, 주소, 포트, 인증 정보, 전송 설정을 비교하세요. 두 기록은 경로나 인증서 이름 하나만 달라도 연결 가능 여부가 달라질 수 있습니다. 목록 이름이 같다는 이유로 한꺼번에 삭제하지 말고, 목록을 깔끔하게 만들려고 원격에서 제공한 매개변수를 바꾸지도 마세요.

직접 추가한 항목을 남길 필요가 있다면 용도를 분명히 표시하고 원래 구독의 변경 사항을 자동으로 반영하지 않는다는 점을 기록하세요. 중복 구독을 정리해야 한다면 어느 그룹에 유효한 업데이트 주소가 있는지, 현재 선택이 어느 그룹에 속하는지, 다른 그룹에만 있는 항목이 있는지 먼저 확인하세요. 확인한 뒤 불필요한 대상을 삭제하고 다음 업데이트 후 다시 점검하세요. 중복 항목이 실제로 삭제되지 않고 일시적으로 숨겨졌을 수도 있습니다.

서버 목록과 Global Routing을 따로 관리

Global Routing(전역 라우팅)은 트래픽을 전반적으로 처리할 방식을 정하며 구독 관리를 대신하지 않습니다. 구독을 추가해도 해당 구독이 자동으로 현재 연결 대상이 되거나 규칙이 자동으로 바뀌지는 않습니다. 문제를 점검할 때는 라우팅 상태, 선택된 서버와 설정, 구체적인 규칙 순서로 확인하세요. 이 계층들을 한데 섞으면 ‘구독을 바꿨는데 달라진 게 없다’고 잘못 판단하기 쉽습니다.

화면 상태	설명	관리 시 확인할 점
Config	Config: 현재 설정과 규칙에 따라 처리	실제로 활성화된 설정과 정책 참조 확인
Proxy	Proxy: 프록시 상태로 처리	현재 선택된 유효한 서버 확인
Direct	Direct: 직접 연결 상태로 처리	이 상태로 프록시 서버가 정상인지 테스트하지 않기

표는 라우팅 상태를 설명하며 모든 시스템 트래픽의 세부 동작을 절대적으로 보장하지 않습니다. 실제 처리는 시스템과 관련 설정에도 영향을 받습니다. Direct(직접 연결) 상태에서 접속이 된다고 방금 가져온 서버를 사용할 수 있다는 뜻은 아닙니다. Config(설정) 상태에서 특정 대상에 DIRECT가 적용되는 경우에도 해당 접속을 프록시 연결 테스트로 볼 수 없습니다. 검증할 때는 트래픽에 실제로 어떤 정책이 적용되는지 확인해야 합니다.

설정 참조와 자동 연결도 확인

설정에서 서버나 정책 그룹을 이름으로 참조하는 경우, 업데이트로 이름이 바뀌면 참조 관계를 다시 확인해야 합니다. 새 항목이 기존 이름이 담당하던 모든 역할을 자동으로 이어받는다고 가정하지 마세요. 설정을 수정하기 전에 백업하고 참조, 규칙 순서, 기본 정책을 확인하세요. 설정과 구독을 한꺼번에 바꾸면 결과를 비교하기 어려우므로 한 번에 한 곳만 조정해야 합니다.

On Demand(요청 시 연결)는 시스템 조건에 따라 연결을 시작하는 관련 설정이지 구독 새로고침 기능이 아닙니다. 정리하거나 전환하는 중에 연결이 자동으로 다시 시작된다면 목록 저장 실패 탓으로 돌리지 말고 이 기능이 켜져 있는지도 확인하세요. 반복 가능한 테스트를 하려면 자동 연결 상태를 먼저 확인하고, 테스트가 끝난 뒤 원래 설정으로 돌려 일상 사용과 다른 동작이 남지 않도록 하세요.

먼저 이름을 정리하고, 소속을 확인한 뒤 현재 선택을 검증하고, 마지막으로 실제로 필요 없는 대상을 삭제하는 순서가 좋습니다. 각 단계를 마칠 때마다 Home(홈)으로 돌아가 결과를 확인하세요. 이렇게 하면 특정 그룹이 작동하지 않아도 해당 목록만 처리할 수 있어 한 번의 정리 작업으로 모든 직접 입력 기록과 설정 참조가 손상되는 일을 막을 수 있습니다.

여러 기기에서도 용도 설명을 일관되게 사용하되 목록, 선택 항목, 설정이 이미 동기화됐다고 가정하지 마세요. iPhone과 iPad에서 같은 결과를 재현해야 한다면 각 기기의 구독, 현재 항목, 라우팅 상태를 따로 확인하세요. 시스템 요구 사항과 기기 호환성은 App Store 페이지를 기준으로 확인하세요. 설치 안내는 iPad 다운로드 및 첫 실행을 참고하세요.

7. Connectivity Test 지연 시간 테스트 및 정렬

Connectivity Test(연결 테스트) 결과는 특정 조건에서 특정 테스트 방법으로 확인한 결과일 뿐입니다. 모든 웹사이트, 프로토콜 트래픽, 지속적인 전송이 정상이라는 뜻은 아닙니다. 테스트 전에 대상, 방법, 현재 네트워크를 확인하고 테스트 후 실제 접속도 확인하세요. 목록의 수치는 참고용 선별 기준으로 활용할 수 있지만 장기적인 안정성이나 전송 속도를 보장하지는 않습니다.

테스트가 확인한 계층부터 파악

연결 대상이 응답한다면 네트워크 경로 일부에 도달할 수 있다는 뜻입니다. 프록시를 통해 요청을 완료하려면 인증, 암호화, 전송, 대상 접근 여부까지 관련됩니다. 테스트 방법마다 확인하는 계층이 다르므로 한 방법의 성공을 다른 조건에도 그대로 적용하지 마세요. 테스트 화면에서 방법을 선택할 수 있다면 현재 방법을 확인하고, 같은 방법으로 같은 항목들을 비교하세요. 조건이 다른 결과를 한 번의 정렬에 섞지 마세요.

항목 하나가 시간 초과됐다고 바로 삭제할 필요는 없습니다. 대상이 일시적으로 응답하지 않거나, 현재 네트워크가 해당 전송을 제한하거나, 이름 확인에 실패했거나, 테스트 요청이 실제 사용을 제대로 반영하지 못했을 수 있습니다. 같은 네트워크에서 상태를 알고 있는 항목 하나를 기준으로 다시 테스트한 뒤 특정 프로토콜에 실패가 집중되는지 확인하세요. 공통 조건이 분명해진 뒤 Add Server(서버 추가)에서 매개변수를 하나씩 점검하는 것이 좋습니다.

반복 가능한 비교 절차 만들기

현재 네트워크와 Global Routing(전역 라우팅) 상태를 기록하고 목록이 동시에 업데이트되고 있지 않은지 확인합니다.
비교할 항목을 같은 테스트 방법으로 확인하고, 테스트 도중 네트워크를 바꾸지 않습니다.
이상 결과는 한 번만 기록하지 말고 다시 테스트해 반복되는지 확인합니다.
항목 하나를 선택해 연결한 뒤 실제 작업으로 이름 확인과 접속 결과를 검증합니다.

비교할 때는 변수를 최대한 줄이세요. 대량의 콘텐츠를 다운로드하면서 수치 변화를 서버 탓으로 돌리지 말고, Wi-Fi와 셀룰러 네트워크를 오간 뒤 같은 비교표를 이어서 사용하지도 마세요. 수치는 시간대, 혼잡도, 대상에 따라 바뀝니다. 단일 수치보다 테스트 조건을 기록하는 편이 유용합니다. 문제 해결을 위한 테스트는 가장 낮은 결과를 찾기보다 설명 가능한 결과를 얻는 것이 중요합니다.

Hysteria2처럼 UDP를 사용하는 프로토콜은 일반적인 연결 응답만으로 전송 조건을 모두 확인할 수 없습니다. 전송 방식이 다른 항목도 단순 테스트 하나만으로 우열을 판단할 수 없습니다. 프로토콜 설계와 적용 범위는 Hysteria2 및 QUIC 기초 안내를 참고하세요. 관리 결정을 내릴 때는 실제 작업과 반복 관찰을 고려하고 프로토콜 이름만으로 미리 결론짓지 마세요.

정렬은 표시 순서만 바꿈

테스트 결과로 정렬하는 기능이 있다면 현재 그룹만 정렬하는지 전체 항목을 정렬하는지 먼저 확인하세요. 정렬 후에는 선택 표시를 다시 살펴보고 목록의 첫 항목이 현재 연결 대상이라고 가정하지 마세요. 구독을 다시 업데이트하면 순서나 표시 이름이 바뀔 수 있으므로, 평소에는 ‘지난번에 맨 위에 있던 항목’이 아니라 명확히 선택된 항목을 기준으로 사용하세요.

수치가 낮다는 것은 해당 테스트가 그때 더 빨리 끝났다는 뜻일 뿐, 대용량 파일 전송이 더 빠르거나 장시간 연결이 더 안정적이라는 뜻은 아닙니다. 특정 작업을 해야 한다면 실제 접속이 되는지 먼저 확인한 뒤 지속적인 끊김이 있는지 살펴보세요. 항목을 자주 바꾸면 경로와 연결 상태가 함께 달라져 원인을 찾기 어려워집니다. 전체 목록을 계속 정렬하기보다 후보 몇 개를 골라 하나씩 검증하는 편이 더 정확합니다.

지연 시간은 정상인데 웹페이지가 열리지 않음

먼저 테스트한 항목이 실제로 선택됐는지, Global Routing(전역 라우팅)이 테스트 목적에 맞는지, 해당 대상이 Config(설정)에서 다른 정책에 매칭되는지 확인하세요. 그런 다음 도메인 확인 실패, 연결 시간 초과, 인증서 오류를 구분합니다. 오류 단계에 따라 해결 방향도 달라집니다. 목록에 수치가 표시된다는 이유로 DNS와 규칙을 건너뛰고 모든 인증 매개변수를 다시 입력하지 마세요.

도메인으로 접속할 때만 실패한다면 DNS 설정 및 웹페이지가 열리지 않을 때의 점검 순서를 따라 확인할 수 있습니다. 다만 임시 주소로 접속하는 것을 장기적인 해결책으로 삼지는 마세요. 인증서, 대상 분배, 앱 요청에는 여전히 도메인이 필요할 수 있습니다. 실제 접속이 모두 실패한다면 근거 없이 라우팅 규칙을 계속 바꾸지 말고 프로토콜, 전송, 네트워크 조건을 단계별로 확인하세요.

다른 사람에게 문제를 설명할 때는 테스트 방법, 발생 조건, 오류 단계, 이미 확인한 항목을 알려주면 됩니다. 주소와 인증 정보를 가려도 ‘구독 업데이트는 가능하고 항목 테스트도 되지만 특정 유형의 접속은 실패한다’는 확인 과정을 설명할 수 있습니다. 지연 시간 수치만 있는 스크린샷보다 이런 기록이 원인 범위를 좁히는 데 도움이 됩니다.

8. 삭제·백업·재가져오기 확인

삭제 전에는 대상의 계층부터 확인하세요. 서버 하나 삭제, 구독 그룹 삭제, Config(설정) 제거, 앱 삭제는 서로 다른 작업입니다. 확인 화면에서 어떤 대상과 범위를 설명하는지 먼저 읽은 뒤 진행하세요. ‘금방 다시 추가하면 된다’는 이유로 백업을 생략하지 마세요. 원격 주소가 만료될 수 있고 직접 수정한 내용은 구독에서 다시 가져오지 못할 수도 있습니다.

복구할 대상에 맞춰 백업 준비

서버 목록만 복구하려면 보통 유효한 구독 주소나 전체 서버 매개변수가 필요합니다. 규칙 동작까지 복구하려면 현재 사용 중인 설정과 관련 참조 정보도 필요합니다. 직접 수정한 내용을 복구하려면 원래 값, 변경 값, 변경 이유가 있어야 합니다. 목록 스크린샷은 이름을 확인하는 데만 도움이 되며 복구 가능한 필드를 대신할 수 없습니다. 백업할 때는 먼저 복구하려는 상태를 정하고 필요한 내용을 수집하세요. 완전해 보이는 파일 하나만 저장하지 마세요.

클라이언트에서 해당 항목을 내보내거나 공유하는 기능을 제공한다면 먼저 내보내기에 포함되는 범위를 확인한 뒤 본인이 관리하는 안전한 위치에 저장하세요. 서버 내보내기에 규칙이 포함되지 않을 수 있고, 설정 내보내기에 모든 로컬 설정이 포함되지 않을 수도 있습니다. 범위를 확인하기 어려운 옵션은 현재 설정 이름, Global Routing(전역 라우팅) 상태, On Demand(요청 시 연결) 활성화 여부처럼 필요한 상태를 별도로 기록하세요.

백업에는 전체 접근 인증 정보가 포함될 수 있으므로 열람할 수 있는 사람을 제한하고 공개 메모, 공유 앨범, 공개 첨부 파일에 저장하지 마세요. 구독 주소만 포함되어도 비밀 정보로 취급해야 합니다. 파일 이름과 메모에는 용도를 표시하고 비밀번호를 직접 넣지 마세요. 백업을 업데이트한 뒤 저장 위치와 접근 권한을 확인하세요. 주 파일은 보호했지만 임시 복사본이 다른 곳에 남는 일을 방지할 수 있습니다.

삭제 전에 참조와 현재 선택 확인

서버 하나를 삭제하려면 먼저 구독에서 관리되는 항목인지 확인하세요. 구독 항목이라면 다음 업데이트 때 다시 추가될 수 있습니다. 구독 전체를 삭제하려면 현재 연결 중인 대상, 고유한 직접 수정 사항, 설정에서 참조하는 항목이 포함되어 있는지 확인하세요. 삭제가 모든 참조 관계를 자동으로 바로잡는다고 가정하지 마세요. 작업 후 목록과 설정을 각각 다시 확인해야 합니다.

목록을 잠시 사용하지 않으려는 것이라면 꼭 삭제해야 하는지 먼저 생각하세요. 메모를 명확히 남기고 유효한 백업을 보관하면 바로 비우는 것보다 되돌리기 편할 수 있습니다. 실제로 삭제할 때는 대상을 하나씩 처리하고 범위를 확인하지 않은 채 연속으로 일괄 삭제하지 마세요. 예상과 다른 결과가 나오면 추가 정리를 즉시 중단하고 방금 저장한 정보를 이용해 복구하세요. 복구할 수 있는 문제를 전체 상태 손실로 키우지 않아야 합니다.

다시 가져오기만으로 복구가 끝나는 것은 아님

구독이나 직접 추가한 서버를 복구한 뒤 유형, 주소, 전송 필드를 확인합니다.
필요한 Config(설정)를 복구하고 정책 참조와 규칙 순서를 점검합니다.
Global Routing(전역 라우팅) 상태를 확인하고 유효한 항목 하나를 명확히 선택합니다.
연결 테스트와 실제 접속을 확인한 뒤 자동 연결 관련 설정을 복구합니다.

이 순서의 목적은 각 단계의 결과를 따로 확인하는 것입니다. 자동 연결을 먼저 켠 뒤 설정과 구독을 한꺼번에 가져오면 작업 중 연결 상태가 바뀌고 오류 원인을 구분하기 어려울 수 있습니다. 복구 과정에서는 원래 백업을 보관하고, 첫 가져오기에 성공했다고 바로 덮어쓰지 마세요. 일상적인 작업이 정상인지 확인한 뒤 새로운 정상 상태를 다음 복구 기준으로 별도 저장하세요.

기기를 바꾸거나 앱을 다시 받는 경우 App Store의 구입 내역은 앱을 다시 찾는 데 사용되며 구독, 서버, 규칙까지 반드시 복원해 주는 것은 아닙니다. 앱을 받는 것과 데이터를 복구하는 것은 별개의 작업입니다. 구매 및 기기 조건은 App Store 페이지를 기준으로 확인하세요. 먼저 구입 항목 복원 안내를 읽고, 검증되지 않은 동기화를 가정하지 말고 본인이 보관한 백업을 복원하세요.

인증 정보 변경 및 이전 복사본 관리

링크나 인증 정보가 바뀌어 다시 가져온 경우에는 새 내용이 실제로 적용됐는지 확인하고 이전 항목이 다른 그룹에 남아 있는지 살펴보세요. 로컬 복사본을 삭제해도 원격 인증 정보가 폐기되지는 않으며, 원격 인증 정보가 만료돼도 모든 백업이 자동으로 삭제되지는 않습니다. 두 작업은 따로 처리해야 합니다. 접근 가능 여부는 서비스 제공업체에 확인하고, 로컬 복사본은 복구를 마친 뒤 보관 필요에 따라 정리하세요.

마무리할 때 세 가지를 확인하세요. 현재 연결 대상을 분명히 알 수 있는지, 사용 중인 설정과 라우팅 상태가 예상과 맞는지, 백업에 복구에 필요한 정보가 모두 있는지 살펴봅니다. 임시 클립보드 내용, QR 코드 이미지, 더 이상 필요 없는 내보내기 복사본도 정리하되 유일한 유효 백업을 실수로 삭제하지 마세요. 관리의 목표는 목록을 최대한 짧게 만드는 것이 아니라 다음 업데이트, 문제 해결, 복구를 시작할 지점을 명확히 남기는 것입니다.

정리가 끝나면 시작 가이드로 돌아가 전체 흐름을 다시 확인해 보세요. 문제가 계속되면 자주 묻는 질문에서 ‘가져오기, 업데이트, 연결’ 중 해당 단계의 안내를 확인하세요. 이미 확인한 사실과 아직 확인되지 않은 조건을 기록해 올바른 것으로 확인된 설정을 반복해서 바꾸지 않도록 합니다.