Shadowrocket
구독 및 서버 관리

1. Subscribe: 보유한 구독 가져오기

입력한 주소가 구독 주소인지 확인하세요

구독 주소는 서버 목록을 다시 가져올 수 있는 주소이며, 목록에 포함된 개별 서버 주소와는 다릅니다. 가져오면 Shadowrocket이 응답 내용을 해석해 해당 항목을 만들고, 이후 갱신할 때 같은 주소에서 목록을 다시 읽습니다. 따라서 가져오기 전에 보유한 정보가 구독 링크인지, 단일 공유 링크인지, 직접 입력해야 하는 서버 정보인지 확인하세요. 주소 길이만으로 용도를 판단하거나 브라우저에서 열린 계정 페이지를 구독 주소로 간주하지 마세요. 이 문서의 절차는 본인이 이미 구독을 보유한 경우를 전제로 합니다.

구독 링크에는 접근 자격 정보가 포함될 수 있는 쿼리 매개변수가 들어가는 경우가 많습니다. 복사할 때 프로토콜, 경로, 매개변수를 모두 포함하고 따옴표, 줄바꿈, 한국어 마침표 또는 채팅 앱이 덧붙인 설명이 섞이지 않도록 하세요. 아래 주소는 형식을 알아보는 용도일 뿐 실제 연결에는 사용할 수 없습니다. 실제 주소를 공개 스크린샷, 공유 메모 또는 문의 내용에 노출하지 마세요. 평범한 URL 한 줄처럼 보여도 민감한 정보로 취급해야 합니다.

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

Home에서 Subscribe 항목 만들기

Home에서 추가 메뉴를 열어 Add Server를 실행하고, 구독용 Subscribe 유형을 선택한 다음 전체 주소를 URL에 입력하세요. 메모에는 알아보기 쉬운 이름을 적습니다. 저장하기 전에 특히 끝부분의 매개변수를 포함해 주소가 온전히 입력되었는지 확인하세요. 화면 구성에 따라 메뉴 위치는 다를 수 있으므로 실제로 표시되는 유형과 입력 항목을 기준으로 작업하세요. 일반 서버의 Address 칸을 구독 URL 입력란으로 사용하지 마세요. 저장한 뒤 가져오기가 끝날 때까지 기다리고 목록에서 결과를 확인하세요.

먼저 구독 그룹이 생겼는지 확인하고, 그룹 안에 서버 항목이 있는지 살펴본 다음, 항목 하나를 골라 프로토콜, 주소, 포트가 보유한 설명과 일치하는지 확인하세요. 이 세 가지는 각각 구독 객체 생성, 응답 해석, 내용의 정확성을 확인하는 단계이므로 서로 대체할 수 없습니다. 구독 이름이 보인다는 사실은 로컬 객체가 저장되었다는 뜻일 뿐입니다. 목록에 내용이 있어도 모든 서버에 연결할 수 있다는 의미는 아닙니다. 처음 가져온 뒤에는 기존에 사용할 수 있던 항목을 유지하고 연결을 확인한 다음 정리하세요.

가져오기 실패와 연결 실패를 구분하세요

저장 후 서버가 보이지 않으면 먼저 주소를 빠짐없이 복사했는지 확인하고, 현재 네트워크에서 구독 주소에 접속할 수 있는지 살펴보세요. 브라우저에 로그인 페이지, 안내 페이지 또는 오류 메시지가 표시된다면 서버 목록으로 해석할 수 없는 내용이 반환된 것일 수 있습니다. 브라우저에 글자가 표시된다는 사실만으로 형식이 올바르다고 볼 수는 없습니다. 문제가 있으면 본인의 구독 안내를 확인하고, 웹페이지 내용을 서버 항목으로 바꾸려고 프로토콜 유형을 반복해서 변경하지 마세요. 가져오기 단계에서 오류가 발생했다면 서버 암호화 설정은 건드리지 말고 주소와 응답부터 확인하세요.

항목은 나타났지만 연결되지 않는다면 서버 입력 항목과 네트워크 연결 가능성을 점검하세요. 구독 응답에 만료된 항목이 포함되었거나 일부 항목에 필수 매개변수가 빠져 있을 수 있습니다. 이때는 구독 그룹 이름, 실패한 항목의 프로토콜, 오류가 발생한 단계를 기록하면 됩니다. 전체 링크를 공개할 필요는 없습니다. 여러 항목이 모두 실패하는 경우와 하나만 실패하는 경우의 점검 순서는 다릅니다. 전자는 공통 네트워크와 목록 내용을 먼저 보고, 후자는 해당 항목에만 있는 설정을 우선 비교하세요.

관리할 때는 구독마다 로컬 기록을 남기고 용도, 원본 주소를 안전하게 보관한 위치, 수동 변경 사항을 적어 두세요. 공개 메모에 주소를 기록하지 마세요. 기록을 남겨두면 나중에 갱신하거나 기기를 바꿀 때 항목이 구독에서 생성되었는지 직접 만들었는지 구분할 수 있습니다. 중복 구독이 발견되어도 바로 한 그룹을 삭제하지 마세요. 두 그룹의 주소와 내용을 먼저 비교해 메모만 다른 것인지 확인한 후 8장의 순서에 따라 처리하세요.

2. Add Server: 직접 입력하는 항목과 프로토콜 매개변수

먼저 Type을 선택한 다음 공통 항목을 입력하세요

직접 추가하는 방식은 완전한 서버 정보를 보유하고 있고 각 항목을 하나씩 확인해야 할 때 적합합니다. Add Server에서 먼저 Type을 선택하세요. 프로토콜에 따라 표시되는 매개변수가 다르기 때문입니다. 유형을 잘못 선택하면 주소와 비밀번호가 맞아 보여도 유효한 연결을 구성할 수 없습니다. 포트 번호만 보고 프로토콜을 추측하지 마세요. 포트는 프로토콜의 식별자가 아닙니다. 같은 주소에서도 서로 다른 서비스를 제공할 수 있으므로 보유한 서버 설정에 따라 프로토콜, 포트, 인증 방식, 전송 설정을 한 묶음으로 확인하세요.

공통 항목에서 Address에는 보통 서버 도메인 또는 주소를 입력하고, Port에는 서버가 실제로 수신 대기하는 포트를 입력합니다. 메모는 항목을 알아보기 쉽게 표시하는 용도입니다. 전체 URL을 요구하는 항목이 아니라면 Address에 웹페이지 경로나 공유 링크 전체를 넣지 마세요. 붙여넣은 뒤 앞뒤 공백을 확인하고 포트에 콜론이 섞이지 않았는지 살펴보세요. 비밀번호와 식별자 같은 자격 정보는 대소문자, 하이픈, 특수 문자를 포함해 원문 그대로 유지해야 인증에 영향을 줄 수 있습니다. 읽기 쉽게 만든다는 이유로 임의로 바꾸거나 보충하지 마세요.

프로토콜에 맞춰 인증과 전송을 확인하세요

Shadowsocks에서는 암호화 방식과 비밀번호가 서로 일치해야 합니다. 다른 프로토콜의 인증 정보를 그대로 입력할 수 없습니다. VMess와 VLESS의 식별자 항목은 비슷해 보일 수 있지만 의미는 서로 다릅니다. 보유한 설정을 기준으로 인증, 전송, 보안 설정을 각각 확인하세요. Trojan은 TLS 설정과 함께 사용하는 경우가 많으므로 비밀번호만 입력하고 인증서 이름 관련 요구 사항을 놓치지 마세요. Hysteria2도 보유한 정보를 기준으로 인증 및 TLS 매개변수를 확인하고, 프로토콜 이름만으로 서버 설정을 추측하지 마세요.

WireGuard 설정에는 키, 피어, 네트워크 범위 등 의미가 서로 다른 매개변수가 포함되므로 일반적인 ‘주소와 비밀번호’ 방식으로 이해하면 안 됩니다. 가져오거나 입력할 때 로컬 개인 키와 피어 공개 키를 구분하고 개인 키를 공개적인 문제 해결 과정에 올리지 마세요. HTTP와 SOCKS5를 사용하는 경우에도 서버에서 사용자 이름과 비밀번호를 요구하는지, 어떤 프로토콜을 선택했는지 확인해야 합니다. 여기에 나열한 프로토콜은 입력 항목을 구분하기 위한 것이며, 같은 매개변수 세트를 사용해 유형을 서로 바꿀 수 있다는 뜻은 아닙니다.

보안 확인을 유지하고 항목별로 변경한 뒤 테스트하세요

TLS에서 인증서 확인에 사용하는 이름은 서버 연결 주소와 다를 수 있습니다. SNI, Host, Path도 하나의 ‘도메인 설정’으로 묶어 이해하면 안 됩니다. 인증 오류가 발생하면 연결 대상, 전송 진입점, 인증서 신원을 각각 확인하세요. 인증서 확인을 끄는 방법을 일반적인 해결책으로 사용하지 말고, 용도를 모르는 전송 매개변수를 추가하지 마세요. 보유한 서버 안내에 선택 항목이 없다면 우선 적절한 기본값을 유지하고, 해당 항목을 입력해야 하는지 확인하세요.

저장한 뒤 직접 추가한 항목만 선택해 먼저 테스트하세요. 조정이 필요하면 한 번에 한 종류의 항목만 변경하고 변경 전후 결과를 기록하는 것이 좋습니다. 비밀번호, 포트, 전송, 규칙을 한꺼번에 바꾸면 실패 원인을 찾기 어렵습니다. 구독에서 생성된 항목을 수정하기 전에는 갱신 시 변경 사항이 덮어써질지 확인하세요. 로컬 테스트 내용을 계속 보관해야 한다면 화면에서 복제 기능을 제공할 때 별도 항목을 만들고 알아보기 쉬운 메모를 붙이세요. 구독 항목을 임시로 수정한 상태에 장기적으로 의존하지 마세요.

직접 입력한 항목이 연결되더라도 이전에 사용하던 연결이 계속 작동한 것이 아닌지 확인하세요. 연결을 끊고 해당 항목을 다시 선택한 다음 연결하여, 본인이 사용할 권한이 있는 대상 서비스에 접속해 확인할 수 있습니다. 입력 항목에 의문이 남으면 원본 서버 정보를 다시 열어 하나씩 비교하세요. 자주 발생하는 문제의 분류는 FAQ를 참고하고, 매개변수를 무작위로 조합해 확인 절차를 대신하지 마세요.

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

QR 코드는 입력 방법일 뿐 설정 유형이 아닙니다

QR 코드에는 단일 공유 링크, 구독 주소 또는 일반 텍스트가 들어갈 수 있습니다. Scan QR Code를 사용하기 전에 QR 코드가 본인이 보유한 설정에 해당하는지 확인하고, 서버 하나를 가져올지 구독 그룹을 가져올지 판단하세요. 스캔 성공은 텍스트를 인식했다는 뜻일 뿐 프로토콜 항목이 완전하다거나 서버 연결이 확인되었다는 뜻은 아닙니다. 인식 결과가 예상과 다르면 바로 저장하고 연결 스위치를 켜기보다 먼저 내용 유형을 확인하세요.

앱에서 Scan QR Code를 열고 시스템 안내에 따라 카메라 접근을 허용할지 선택하세요. QR 코드 전체가 화면에 들어오도록 하고 가장자리가 잘리거나 반사되거나 지나치게 확대되지 않게 하세요. 현재 기기에 저장된 QR 코드는 실제 화면에 사진 보관함 인식 메뉴가 있을 때만 해당 메뉴를 사용하세요. 모든 화면에서 같은 위치에 동일한 기능을 제공한다고 가정하면 안 됩니다. 이미지에는 직접 보관한 원본 자료를 사용하고, 여러 번 전달하거나 압축 또는 합성해 흐릿해진 사본은 되도록 피하세요.

인식 후 매개변수 미리보기 화면이 나오면 Type, 주소, 포트, 메모를 확인한 다음 저장하세요. QR 코드에는 여러 정보가 함께 인코딩될 수 있으므로 익숙한 메모만 보고 내용이 올바르다고 판단해서는 안 됩니다. 메모는 항목을 알아보기 쉽게 표시하는 라벨이지 서버 신원을 확인하는 수단이 아닙니다. 구독 URL이 인식되면 구독 절차에 따라 목록을 만들고 가져오세요. 단일 프로토콜 링크가 인식되면 서버 가져오기 절차를 따르세요. 두 방식은 이후 갱신 가능 여부가 크게 다릅니다.

클립보드에서 가져오기 전에 텍스트 앞뒤를 정리하세요

공유 링크를 복사할 때는 링크만 선택하고 설명, 번호, 목록 기호, 따옴표가 함께 복사되지 않도록 하세요. Shadowrocket을 열었을 때 클립보드 읽기 또는 내용 가져오기 안내가 나오면 출처와 예상 결과를 확인한 다음 진행하세요. 안내가 나타나지 않는다면 현재 화면에 제공되는 가져오기 메뉴를 이용할 수 있습니다. 시스템의 클립보드 권한이 읽기 절차에 영향을 줄 수 있으므로 가져오기 안내가 나오지 않았다고 해서 링크가 만료되었다고 단정하지 마세요. 확인을 위해 다른 민감한 내용을 반복해서 복사하는 것도 피하세요.

클립보드에 여러 줄이 있으면 특히 주의해서 확인하세요. 구독 응답에는 인코딩된 여러 서버 항목이 들어갈 수 있고, 채팅 기록에는 여러 링크가 이어 붙어 있을 수 있습니다. 두 내용은 같은 메뉴로 처리되지 않을 수 있습니다. 여러 항목을 가져오지 못했다면 완전하고 명확한 공유 링크 하나를 먼저 가져와 해석 결과를 확인하고 원본 형식을 살펴보세요. 인코딩 단계를 모르는 상태에서 반복해서 디코딩하거나 줄바꿈을 넣거나 특수 문자를 바꾸지 마세요. 원래 유효한 내용이 손상될 수 있습니다.

저장 후 가져온 내용을 확인하세요

가져온 내용은 최소 세 단계로 확인하세요. Home에서 새 객체가 생겼는지 확인하고, 상세 화면에서 주요 항목을 살펴본 다음 연결을 테스트합니다. QR 코드 인식은 성공했는데 새 객체가 없다면 아직 저장하지 않은 편집 화면에 있는지, 또는 단일 서버가 아니라 구독 그룹으로 가져왔는지 확인하세요. 목록이 길다면 방금 설정한 메모를 이용해 찾고, 구분하기 어려운 복사본을 만들지 않도록 스캔을 연속해서 반복하지 마세요. 같은 내용을 다시 가져와도 매개변수 문제가 해결되지는 않습니다.

저장하기 전에 인식에 실패했다면 이미지가 온전한지, 프로토콜 접두사와 텍스트 형식이 올바른지 확인하세요. 저장은 성공했지만 연결에 실패했다면 인증, 전송, 서버 연결 가능성을 살펴보세요. 이 구분은 점검 범위를 좁히는 데 도움이 됩니다. 다른 사람이 다시 편집한 링크라면 안전하게 보관한 원본과 비교하고, 특히 전각 문자, 자동 줄바꿈, 끝부분이 잘렸는지 확인하세요. 복사 화면에 짧게 표시된 텍스트가 전체 대상 내용을 복사했다는 뜻은 아닐 수 있습니다.

가져오기를 마치면 임시 스크린샷과 클립보드 기록을 안전하게 처리하세요. QR 코드나 링크가 통제할 수 없는 곳에 노출되었다면 기존 서비스의 자격 정보 관리 절차에 따라 해당 정보를 변경하세요. 기기에서 가져온 항목만 삭제해도 이미 노출된 자격 정보가 자동으로 무효화되지는 않습니다. 다음 장에서 형식을 더 살펴볼 수 있습니다. 시스템 권한 문제라면 첫 연결 가이드에 따라 권한 설정부터 확인하고, 권한 문제와 가져오기 문제를 혼동하지 마세요.

4. 공유 링크: 형식과 설정 범위

먼저 접두사를 보고 내용이 무엇인지 확인하세요

공유 링크는 프로토콜 매개변수를 복사 가능한 텍스트에 담아 직접 입력할 때 생기는 오류를 줄여 줍니다. 자주 보이는 접두사로는 ss://, vmess://, vless://, trojan://, hysteria2://가 있습니다. 접두사는 앱이 해석 방식을 선택하는 데 도움이 되지만, 전송 및 인증 세부 사항 전체를 알려 주지는 않습니다. 단일 공유 링크는 보통 서버 하나를 나타내고, 구독 URL은 여러 항목을 다시 가져오는 데 사용됩니다. 단일 공유 링크를 저장해도 구독 목록이 계속 갱신되지는 않습니다.

형식에 따라 인코딩된 인증 정보, 쿼리 매개변수, 해시 기호 뒤의 메모가 포함될 수 있습니다. 인코딩은 표현 방식이지 보안 조치가 아닙니다. 링크 전체를 가진 사람은 보통 포함된 매개변수도 확인할 수 있습니다. 일부 링크에는 퍼센트 인코딩이 사용되며 메모의 한국어도 인코딩될 수 있습니다. 문제를 확인할 때 원본 텍스트를 그대로 보관하세요. 문자열을 ‘정상적으로 보이게’ 하려고 등호, 퍼센트 기호, 연결 기호를 임의로 지우거나 끝의 메모를 비밀번호 일부로 오해하지 마세요.

매개변수 호환성이 내용의 완전한 일치를 뜻하지는 않습니다

같은 프로토콜의 링크라도 항목을 표현하는 방식이 다를 수 있고 가져오기 기능이 모든 선택 매개변수 조합을 지원하지 않을 수도 있습니다. 가져오기가 완전한지 확인하려면 성공 안내가 떴는지만 보지 말고 가져온 항목을 살펴보세요. 특히 전송 유형, TLS, SNI, Host, Path 설정이 빠지면 서버 항목은 만들어져도 예상한 연결을 하지 못할 수 있습니다. 원본 링크에 추가 매개변수가 있다면 앱이 각 항목을 인식하는지 확인하고, 낯선 항목을 이름이 비슷한 옵션에 임의로 대응시키지 마세요.

공유 링크로 항목 하나를 가져와도 전체 Config가 함께 바뀌는 것은 아닙니다. 서버는 연결 대상을 결정하고 규칙은 요청별로 사용할 정책을 결정하므로 둘은 함께 작동해야 합니다. Global Routing의 Config 모드는 현재 규칙에 따라 요청을 처리합니다. Proxy 모드와 Direct 모드의 동작은 서로 다릅니다. 문제를 확인할 때는 먼저 현재 모드를 살펴보고 규칙을 확인할지 판단하세요. 규칙 때문에 직접 연결된 요청을 서버 공유 링크가 적용되지 않은 것으로 오해하지 않도록 주의하세요.

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

위 예시는 규칙과 서버 항목의 역할을 설명하는 것이며 완성된 설정을 권장하는 내용은 아닙니다. DOMAIN-SUFFIX는 도메인 접미사를 기준으로 일치시키고, GEOIP는 주소가 속한 지역을 기준으로 판단하며, FINAL은 마지막 기본 규칙으로 사용됩니다. 규칙 순서는 일치 결과에 영향을 줍니다. PROXY와 DIRECT는 정책 키워드이지 서버 비밀번호가 아니므로 Add Server의 인증 입력란에 넣지 마세요. 실제로 사용하기 전에 규칙의 적용 범위를 이해하고 기존 Config에서 해당 위치를 확인하세요.

공유할 때 내보내는 범위를 명확히 하세요

자료를 공유하거나 저장하기 전에 내보내는 것이 단일 서버인지, 구독 주소인지, 규칙 설정인지 확인하세요. 각 항목은 복원했을 때 결과가 다릅니다. 서버 링크는 연결 매개변수를 다시 만들고, 구독 주소는 목록을 다시 가져오며, 규칙 파일은 요청 처리 방식을 복원합니다. 이 중 하나만 백업해도 전체 사용 환경이 복원된다고 볼 수는 없습니다. 상대방이 규칙 문제만 확인하면 된다면 연결 자격 정보 전체를 넘기지 말고 관련 규칙 부분만 민감한 정보를 가려 제공하세요.

형식이 궁금하다면 공유 링크와 구독 링크의 차이를 읽은 다음 원본 자료를 확인하세요. 공유 링크를 일반 웹 주소로 바꾸거나 HTTPS 구독 URL에 특정 프로토콜 접두사를 억지로 붙이지 마세요. 형식 변환은 각 항목의 의미를 알고 대상 형식이 해당 항목을 지원할 때만 의미가 있습니다. 접두사만 수동으로 바꿔서는 프로토콜이 변환되지 않으며, 오히려 알아차리기 어려운 매개변수 누락이 생길 수 있습니다.

5. 갱신 방식: 새로고침과 오류 처리

구독을 새로고침하면 무엇이 바뀌는지 먼저 확인하세요

구독 새로고침은 서버 목록을 다시 가져오는 작업이지 현재 연결 속도를 높이거나 앱 자체를 업데이트하는 작업이 아닙니다. 원격 목록이 바뀌면 새로고침으로 항목이 추가 또는 삭제되고 이름이나 매개변수가 바뀔 수 있습니다. 구독과 연결된 로컬 수정 사항도 원격 내용에 덮어써질 수 있습니다. 중요한 항목의 메모, 포트, 전송 설정을 수정했다면 그 변경을 영구 저장된 것으로 간주하지 마세요. 갱신 전에 필요한 차이를 기록한 다음 원본 설정을 수정할지 별도의 수동 항목으로 보관할지 결정하세요.

평소에는 수동으로 한 번 새로고침하고 명확한 오류가 나타나는지 확인한 뒤 목록의 변화를 살펴보세요. 구독 작업은 목록 제스처나 편집 메뉴에서 제공될 수 있으므로 현재 화면을 기준으로 진행하세요. 새로고침이 끝나면 안내가 사라졌는지만 보지 말고 구독 그룹과 이전에 선택한 항목도 확인하세요. 현재 서버가 삭제되었거나 이름이 바뀌었다면 유효한 항목을 다시 선택한 후 연결 상태를 확인하세요. 목록 새로고침과 사용 중인 연결 전환은 서로 다른 작업이므로 항상 함께 완료된다고 가정하지 마세요.

자동 갱신은 실제 사용 빈도에 맞게 설정하세요

자동 갱신 옵션은 앱에서 실제로 제공하는 구독 설정에서 확인하세요. 앱을 열 때 실행되는 갱신이 모든 백그라운드 상태에서 정확한 간격으로 작동한다는 뜻은 아닙니다. 시스템 예약, 네트워크 상태, 앱 실행 상태에 따라 실행 시점이 달라질 수 있습니다. 중요한 작업 전에 목록이 유효한지 확인해야 한다면 백그라운드에서 갱신되었을지 추측하기보다 직접 확인하세요. 구독 이름에 날짜가 들어 있어도 마지막 가져오기가 성공했다는 뜻은 아닙니다. 이름은 고정된 텍스트일 수 있습니다.

자주 새로고침한다고 신뢰성이 높아지는 것은 아닙니다. 같은 주소에 짧은 시간 동안 반복 요청하면 네트워크 변동, 원격 서버의 접근 제한, 캐시된 응답이 발생할 수 있습니다. 한 번 가져온 뒤 실패하면 오류 내용과 발생 단계를 확인하세요. 다른 결과가 나올 때까지 계속 누르는 것은 바람직하지 않습니다. 자동 갱신 후 문제가 생기면 ‘가져오기 실패’, ‘목록 변경’, ‘연결 실패’ 중 무엇인지 기록하세요. 각각 처리 방법이 다릅니다. 중요한 로컬 항목은 새로고침 간격을 줄이는 것보다 안전하게 백업하는 편이 유용합니다.

주소, 네트워크, 내용의 세 단계로 점검하세요

첫 번째는 주소입니다. 원본 링크가 잘리지 않았는지, 쿼리 매개변수가 온전한지, 구독 주소를 웹페이지 주소로 바꾸지 않았는지 확인하세요. 민감한 매개변수가 포함된 링크를 공개 온라인 도구로 검사하지 마세요. 로컬에서 원본 텍스트와 비교할 수 있습니다. 자격 정보가 변경되었다면 이전 주소가 로컬에 남아 있을 수 있으며 앱을 다시 열어도 새 주소로 자동 변경되지는 않습니다. 새 주소와 이전 주소의 관계를 확인한 다음 기존 구독 객체를 수정하여 용도가 다른 구독이 섞이지 않도록 하세요.

두 번째는 네트워크입니다. 현재 연결에서 구독 서버에 접속할 수 있는지와 가져온 서버에 연결할 수 있는지는 별개의 문제입니다. 시간 초과 또는 도메인 이름 확인 오류가 발생하면 본인이 사용할 수 있는 다른 네트워크에서 주소를 바꾸지 않은 채 다시 테스트해 비교하세요. 네트워크와 링크, 규칙을 동시에 변경하면 어느 변화가 영향을 주었는지 알기 어렵습니다. 현재 라우팅이 가져오기에 영향을 준다고 의심된다면 기존 설정을 먼저 기록한 뒤 신중하게 확인하세요. 임시 전환을 장기 설정으로 간주하지 마세요.

세 번째는 내용입니다. 요청이 성공적으로 반환되었다고 해서 유효한 목록이 반환되었다는 뜻은 아닙니다. 원격 서버가 오류 안내, 로그인 페이지, 빈 내용, 지원되지 않는 형식을 반환할 수 있습니다. 이때 기존에 사용할 수 있던 목록을 유지하고 ‘처음부터 다시’ 하려고 모든 항목을 먼저 삭제하지 마세요. 기존 서비스 안내에서 형식 요구 사항을 확인하고 민감한 정보를 가린 오류 유형을 기록하세요. 한 구독 그룹만 문제라면 해당 그룹의 주소와 응답을 우선 확인하고, 모든 그룹에서 동시에 문제가 발생한다면 공통 네트워크 조건과 앱 상태를 살펴보세요.

갱신은 성공했는데 사용 결과가 달라졌다면 서버가 교체되었는지 확인하고, 선택 항목과 Global Routing을 살펴본 다음 규칙과 대상 요청을 확인하세요. 문제 발생 전후를 간단히 기록하면 같은 테스트를 반복하지 않아도 됩니다. 수동 새로고침과 앱을 열 때 자동 갱신되는 방식은 구독 갱신 방법을 참고하세요. 매개변수를 다시 확인하려면 2장의 순서를 따르세요.

6. 여러 구독 정리: 그룹과 이름 관리

출처와 사용 목적을 따로 기록하세요

보유한 구독이 여러 개라면 목록을 짧게 만드는 것보다 각 항목이 어디서 생성되었는지, 갱신하면 어떻게 바뀌는지, 현재 연결에 어떤 항목이 선택되었는지 파악하는 것이 중요합니다. 구독 그룹은 출처를 나타내고 서버 메모는 항목을 구분하며 로컬 기록은 수정 내역을 설명합니다. 이 세 가지를 길고 복잡한 이름 하나에 모두 넣거나 모든 그룹의 모양을 통일하려고 같은 이름으로 바꾸지 마세요. 이름이 같으면 잘못 선택할 위험이 커지고 주소가 같으면 중복 객체일 수 있습니다. 두 경우를 따로 확인하세요.

구독에는 용도를 나타내는 짧고 일관된 이름을 붙이고 원본 주소와 변경 내역은 본인의 안전한 기록에 보관하는 것이 좋습니다. 서버 이름은 기존 라벨을 유지하고 별도로 만든 수동 항목에는 쉽게 알아볼 수 있는 로컬 표시를 추가하세요. 메모에 전체 비밀번호, 개인 키, 구독 토큰을 넣지 마세요. 메모는 목록, 스크린샷, 내보낸 내용에 표시될 수 있으므로 자격 정보를 저장하는 용도로 적합하지 않습니다. 특정 성능을 보장하는 듯한 이름도 피하세요. 한 번 측정한 속도가 계속 유지되는 것은 아닙니다.

중복 항목은 먼저 확인한 다음 정리하세요

두 항목이 같은 도메인과 포트를 사용하더라도 인증, 전송, 보안 또는 라우팅 용도가 다를 수 있으므로 완전히 같은 항목이라고 단정할 수 없습니다. 반대로 이름이 다른 두 항목도 같은 매개변수를 가리킬 수 있습니다. 정리할 때는 먼저 프로토콜과 주소를 비교하고 인증 및 전송 항목을 살펴본 뒤 소속된 구독을 확인하세요. 자격 정보는 로컬에서 비교하고 공개 텍스트에 복사하지 마세요. 항목의 의미가 같고 이후 갱신 관계도 명확한 경우에만 하나를 남기세요.

같은 구독을 여러 번 가져와 중복이 생겼다면 서버 항목을 하나씩 삭제하기보다 구독 URL을 먼저 비교하세요. 중복으로 만든 구독 그룹은 다음 새로고침 후에도 비슷한 목록을 다시 만들 수 있습니다. 처리 전에 현재 사용하는 그룹을 확인하고 필요한 자료를 백업한 다음 불필요한 그룹을 삭제하세요. 같은 그룹 안에서 이름만 비슷한 항목이라면 원격 목록을 확인하세요. 화면을 깔끔하게 만들기 위해 다른 매개변수를 가진 항목을 삭제하지 마세요.

선택 항목, 정렬, 정책을 따로 확인

목록 순서가 바뀌어도 현재 연결이 전환되었다는 뜻은 아닙니다. 수동 정렬, 테스트 후 정렬, 다시 가져오기는 항목 표시 위치를 바꿀 수 있지만 실제 선택 항목은 직접 확인해야 합니다. 긴 목록을 정리할 때는 현재 구독 그룹과 서버 이름을 기록한 뒤 정리 후 다시 확인하세요. 원격 갱신으로 이름이 바뀌었다면 기억해 둔 위치만 보고 선택하지 말고 프로토콜과 주소도 함께 확인하세요. 위치는 목록을 살펴보는 데 유용하지만 항목을 안정적으로 식별하는 기준은 아닙니다.

Global Routing의 Config 모드, Proxy 모드, Direct 모드도 구독 그룹과 혼동하지 마세요. 그룹은 목록을 관리하고 라우팅 모드는 요청 처리 방식을 결정합니다. 한 구독 그룹에 항목이 많다고 해서 앱이 용도에 맞게 자동 선택하는 것은 아닙니다. 그룹 이름을 용도에 맞게 지어도 규칙 동작은 바뀌지 않습니다. 요청 처리 방식을 지정하려면 메모 이름에 의존하지 말고 현재 Config의 규칙과 정책을 확인하세요.

임시 테스트 항목에는 정리 기준을 정해 두세요. 문제 재현을 마치고 안전한 기록을 남긴 뒤 삭제하고, 지연 시간이 한 번 높게 나왔다는 이유만으로 계속 사용할 수 없는 항목이라고 판단하지 마세요. 오래 사용하지 않은 구독도 복구 자료가 온전한지 먼저 확인해야 합니다. 정리는 여러 차례로 나누어 진행하고 각 단계가 끝날 때마다 현재 연결과 남은 그룹을 확인하세요. 한꺼번에 너무 많은 항목을 삭제, 이름 변경, 재가져오기하면 문제가 발생했을 때 원인을 찾기 어려워집니다.

iPhone과 iPad에서 같은 이름 규칙을 사용할 수 있지만 두 기기의 로컬 선택, 정렬, 테스트 결과는 각각 확인하세요. 이름이 같다고 작동 상태까지 같다고 볼 수 없습니다. 앱 구입 및 기기 안내는 iPad 구입 안내를 참고하고 설정 이전은 8장의 절차에 따라 따로 확인하세요. 이렇게 하면 이름을 알아보기 쉽게 유지하면서 기기별 네트워크 조건과 로컬 상태가 다를 수 있다는 점도 고려할 수 있습니다.

7. Connectivity Test: 지연 시간 및 정렬

테스트 수치가 어떤 구간을 나타내는지 먼저 확인하세요

Connectivity Test는 연결 테스트 결과를 살펴보는 기능이며 수치는 사용된 테스트 방식에 맞춰 해석해야 합니다. 테스트 방식에 따라 대상에 연결할 수 있는지, 연결이 수립되는지, 서버를 거쳐 테스트 대상에 접속하는 데 얼마나 걸리는지 등을 나타낼 수 있습니다. 모든 수치를 실제 서비스 요청의 전체 응답 시간으로 해석하지 마세요. 실행 전에 실제 테스트 방식과 대상을 확인하고 비교할 때는 같은 방법을 사용하세요. 한 번 낮은 수치가 나왔다고 다운로드 속도가 더 빠르거나 모든 웹사이트에서 같은 성능을 보인다는 뜻은 아닙니다.

테스트 결과는 현재 네트워크, 도메인 이름 확인, 서버 부하, 테스트 대상의 응답, 시간 초과 설정에도 영향을 받습니다. 같은 항목도 네트워크에 따라 결과가 다를 수 있으므로 조건이 바뀌었는지 고려하지 않은 채 두 수치만 비교하지 마세요. 여러 항목을 한꺼번에 테스트하면 동시 요청이 발생해 단일 테스트와 결과가 다를 수 있습니다. 안정된 네트워크에서 먼저 한 차례 확인하고 실제로 사용할 소수의 항목을 각각 다시 테스트한 다음 실제 사용 조건으로 확인하는 것이 좋습니다.

조건을 통일해 테스트한 뒤 정렬하세요

테스트 도중 목록이 갱신되지 않도록 먼저 구독 새로고침을 마치세요. 사용 중인 네트워크와 테스트 방식을 확인한 뒤 비교할 범위를 선택합니다. 목록이 길다면 그룹별로 테스트할 수 있으며 매번 모든 항목을 확인할 필요는 없습니다. 테스트가 끝나면 유효한 결과와 시간 초과 결과를 구분한 뒤 정렬 여부를 결정하세요. 앱에서 테스트 결과순 정렬을 제공한다면 임시로 후보를 추리는 데 활용할 수 있습니다. 정렬 후 위치만으로 항목을 찾지 않도록 이름을 알아보기 쉽게 유지하세요.

지연 시간 정렬은 후보를 줄이는 데 유용하지만 연결 선택을 대신하지는 않습니다. 테스트 대상에 빠르게 응답한 항목도 실제로 필요한 서비스에서는 다르게 작동할 수 있습니다. 후보를 정한 뒤 해당 항목을 명확히 선택하고 Global Routing을 확인한 다음 연결해 본인의 대상 서비스에 접속하세요. 테스트는 통과했지만 서비스 이용이 안 된다면 목록에서 숫자가 가장 낮은 항목을 계속 바꾸지 말고 규칙, 도메인 이름 확인, 대상의 응답을 살펴보세요.

실패를 단일 항목, 전체 그룹, 대상 차이로 나누세요

항목 하나만 실패하면 해당 항목의 주소, 포트, 인증, 전송 설정을 확인하고 같은 그룹에서 정상 작동하는 항목과 공통점 및 차이점을 비교하세요. 그룹 전체가 실패하면 현재 네트워크에서 관련 주소에 접속할 수 있는지 확인하고 구독 내용이 바뀌었는지 살펴보세요. 모든 그룹이 실패한다면 테스트 방식과 대상이 현재 환경에 적합한지도 확인해야 합니다. 이 순서를 따르면 잘못 삭제할 위험을 줄일 수 있습니다. 공통 조건을 확인하기 전에는 각 항목의 매개변수가 손상되었다고 단정하지 마세요.

테스트 대상은 응답하지만 실제 대상에 접속할 수 없다면 요청이 예상한 경로를 거치는지 확인하세요. Config의 DOMAIN, DOMAIN-SUFFIX, GEOIP, FINAL 규칙은 일치 결과에 영향을 줍니다. 현재 Direct 모드라면 서버 테스트가 성공해도 일반 요청이 자동으로 Proxy로 바뀌지 않습니다. 앱에서 제공하는 연결 정보나 로그를 활용해 정책을 확인할 수 있습니다. 이때 도메인, 주소, 자격 정보를 가린 뒤 문제와 관련된 최소한의 내용만 보관하세요.

비교할 항목은 비슷한 시간대, 같은 네트워크, 같은 테스트 방식으로 몇 차례만 테스트하고 여러 결과 중 가장 좋아 보이는 수치 하나만 고르지 말고 결과가 안정적인지 살펴보세요. 연결이 수립된 뒤에는 실제 작업이 완료되는지 확인하세요. 여러 항목을 계속 일괄 테스트해 일상적인 사용 확인을 대신하지 말고 테스트로 발생하는 트래픽과 백그라운드 활동도 고려하세요. 배터리 소모가 걱정된다면 백그라운드 배터리 소모와 On Demand의 장단점을 참고하세요.

마지막으로 남겨야 할 것은 설명 가능한 선택 근거입니다. 어떤 네트워크에서 어떤 테스트 방식으로 어떤 대상을 확인했고 어떤 결과가 나왔는지 기록하세요. 조건을 알 수 없는 정렬 스크린샷보다 문제 해결에 더 도움이 됩니다. 일시적으로 시간 초과가 난 항목은 우선 유지하며 관찰하세요. 더 이상 필요하지 않고 복구 방법도 확인한 뒤 삭제 절차를 진행하세요. 테스트는 판단 근거를 제공하는 것이고 삭제는 설정 관리 작업이므로 한 번의 실패만으로 자동 결정해서는 안 됩니다.

8. 삭제 및 백업: 복구 자료와 기기 이전 확인

삭제 전에 대상 범위를 확인하세요

삭제하기 전에 대상이 독립 서버인지, 구독에서 생성된 항목인지, 구독 그룹 전체인지, Config인지 확인하세요. 독립 항목을 삭제하면 로컬 매개변수가 제거됩니다. 구독 그룹을 삭제하면 해당 그룹과 연결된 목록에도 영향을 줄 수 있습니다. 확인 안내가 나오면 문구를 주의 깊게 읽고 익숙한 제스처만 믿고 빠르게 확인하지 마세요. 구독에서 생성된 서버 하나만 삭제하면 다음 새로고침 때 원격에서 다시 만들어질 수 있습니다. 구독 객체 전체를 삭제하는 것과는 본질적으로 다르므로 실제로 정리할 범위를 먼저 확실히 하세요.

현재 연결에 사용 중인 항목을 삭제한 뒤 연결 상태나 다음 선택 항목이 예상대로 유지된다고 가정하지 마세요. 정리 전에 현재 항목을 기록하고 연결을 끊은 다음 삭제를 완료하고 다시 선택해 확인할 수 있습니다. 당분간 사용하지 않는 항목을 목록에서 숨기려는 목적이라면 현재 화면에 적절한 관리 기능이 있는지 먼저 살펴보세요. 복구할 수 없는 삭제를 유일한 정리 방법으로 여기지 마세요. 결과가 불확실한 그룹은 백업을 마칠 때까지 유지하세요.

복구 자료를 종류별로 준비하세요

신뢰할 수 있는 백업은 구독 주소, 수동 서버 매개변수, 규칙 설정을 각각 고려해야 합니다. 구독 주소로 목록을 다시 가져올 수 있지만 원격 내용이 현재와 같다고 보장되지는 않습니다. 단일 공유 링크로 서버를 다시 만들 수 있어도 앱 설정 전체가 포함되지는 않을 수 있습니다. Config에 규칙 로직을 저장해도 연결 자격 정보까지 모두 보관되는 것은 아닙니다. 백업 전에 실제 사용하는 객체를 목록으로 정리하고 각 유형마다 복구 가능한 자료가 있는지 확인하세요. 내보낸 파일 하나가 있다고 해서 모든 내용이 온전하다고 간주하지 마세요.

현재 화면에 공유, 내보내기, 백업 메뉴가 있다면 먼저 포함 범위를 읽고 필요한 자료를 저장하세요. 특정 항목이 포함되는지 확실하지 않다면 원본 객체를 유지한 채 내보낸 결과를 로컬에서 확인하거나 복원 테스트를 해볼 수 있습니다. 수동 기록은 인증, TLS, 전송, 특수 매개변수가 모두 포함되었는지 특히 확인해야 합니다. 알아보기 위한 메모나 테스트 스크린샷을 매개변수 백업으로 간주하지 말고 주소와 포트만 기록한 채 인증 정보를 빠뜨리지 마세요.

백업을 저장할 때 자격 정보가 없는 설명을 덧붙여 객체의 용도, 내보낸 범위, 현재 규칙 선택, 필요한 수동 변경 사항을 적어둘 수 있습니다. 자료를 알아보기 쉽게 관리하되 파일 이름에 비밀번호나 토큰을 넣지 마세요. 신뢰할 수 있는 저장 방식을 사용하더라도 기기 분실, 접근 권한, 오래된 사본 정리도 고려해야 합니다. 암호화해 저장하면 내용을 보호하는 데 도움이 되지만 복원에 필요한 접근 방법도 안전하게 보관해야 합니다. 백업이 있어도 열 수 없는 상황을 피하세요.

기기를 바꾸거나 다시 설치한 뒤 단계별로 복원하세요

앱은 App Store에서 구입합니다. 구입 항목 및 계정 안내는 구입 항목 복원 가이드를 참고하세요. 시스템 요구 사항과 통합 구입 지원 여부는 App Store 페이지를 기준으로 합니다. 앱을 다시 받을 수 있다고 해서 구독, 수동 서버 항목, Config까지 자동으로 복원되는 것은 아닙니다. 새 기기를 열면 먼저 현재 상태를 확인한 다음 필요한 자료를 가져오세요. 일부 데이터가 이미 복원된 상태에서 그룹 전체를 다시 가져와 중복되지 않도록 주의하세요.

구독, 독립 서버, Config, 연결 확인 순서로 복원하는 것이 좋습니다. 각 유형을 복원할 때마다 항목과 입력값을 확인한 뒤 다음 단계로 진행하세요. 구독을 다시 가져오면 목록이 바뀌었을 수 있으므로 선택 항목을 확인해야 합니다. 독립 항목을 복원한 뒤 주요 매개변수를 확인하고 규칙을 복원한 뒤에는 현재 사용 중인 Config와 Global Routing을 확인하세요. 이어서 시스템 안내에 따라 VPN 구성 권한을 처리하고 실제 연결을 테스트하세요. 목록이 나타났다는 사실만으로 기기 이전이 끝난 것은 아닙니다.

새 기기에서 정상 작동하는지 확인할 때까지 기존 기기의 자료와 백업을 보관하세요. 두 기기의 결과가 다르면 모든 데이터를 바로 덮어쓰지 말고 네트워크 조건, 선택 항목, 라우팅 모드를 먼저 비교한 다음 매개변수를 확인하세요. 이전 상태로 되돌려야 한다면 기존 기록에 따라 객체 범위를 확인해 복구하세요. 이전 Config가 새 변경 사항을 덮어쓰거나 기존 구독이 목록을 중복 생성하지 않도록 주의하세요. 이전 과정에서는 한 번에 한 계층씩 변경해 각 단계를 설명하고 재현할 수 있도록 하세요.

마지막으로 백업이 현재 상태에도 유효한지 확인하세요. 자격 정보가 바뀌면 이전 사본이 무효가 될 수 있고 규칙을 수정하면 예전 파일이 더 이상 의도한 용도를 나타내지 않을 수 있습니다. 갱신이 끝나면 더 이상 필요하지 않은 민감한 사본을 안전하게 정리하세요. 로컬 기록이나 파일을 삭제해도 본인의 사본만 제거될 뿐 이미 노출된 자격 정보가 자동으로 취소되지는 않습니다. 정보가 노출되었다면 기존 서비스의 자격 정보 관리 절차에 따라 조치하세요. 이후 기본 사용법은 빠른 시작 가이드를, 구체적인 오류는 FAQ 분류를 참고하세요.