Shadowrocket
구독 및 서버 관리

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

구독, 서버 항목, Config 구분하기

구독은 서버 정보를 반환하는 원격 주소이고, 서버 항목은 이를 가져와 로컬에 표시한 연결 정보입니다. Config는 규칙과 관련 연결 설정을 담당합니다. 서로 연관되어 있지만 대체할 수는 없습니다. 구독을 가져온 뒤 서버 목록이 보인다고 해서 현재 규칙이 해당 서버로 요청을 전달하거나 원격 계정 이용 권한이 유효하다는 뜻은 아닙니다. 시작하기 전에 가지고 있는 정보가 구독 주소인지, 단일 공유 링크인지, Config 주소인지 확인하세요.

이 장은 이미 본인의 구독을 보유하고 있다는 전제로 설명합니다. 준비할 때는 전체 링크와 서비스 제공자가 안내한 형식 설명을 보관하세요. 계정 상태 페이지가 있다면 구독이 아직 유효한지도 확인할 수 있습니다. 링크에 포함된 영어 단어만 보고 용도를 판단하지 마세요. 구독 경로에 뚜렷한 확장자가 없는 경우도 있습니다. 구독 주소에는 보통 접근 정보가 포함되므로 비밀번호처럼 안전하게 보관하세요. 아래 주소는 설명을 위한 예시일 뿐 실제 연결에 사용할 수 없으며, 이용 가능한 서비스를 의미하지 않습니다.

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

Add Server에서 Subscribe 저장하기

1. Home에서 추가 메뉴를 열고 Add Server로 이동한 다음, Type에서 Subscribe를 선택합니다.
2. 전체 구독 주소를 URL에 입력하고, 알아보기 쉬운 이름을 Remarks에 적은 뒤 저장합니다. 실제로 표시되는 입력란은 현재 앱 화면을 기준으로 확인하세요.
3. 처음 가져오기가 끝날 때까지 기다린 다음 목록으로 돌아가 해당 구독에 속한 서버 항목이 표시되는지 확인합니다. 다시 가져오려면 해당 구독의 업데이트 기능을 사용하세요.

이름은 ‘개인 구독·일상용’처럼 용도를 알아보기 쉽게 정하고, 전체 링크를 이름에 반복해서 넣지 않아도 됩니다. 저장하기 전에 주소의 시작 부분, 물음표 뒤의 쿼리 매개변수, 끝부분이 모두 포함됐는지 확인하세요. 채팅 메시지에서 복사할 때 공백, 줄바꿈 또는 한글 문장 부호가 섞이지 않았는지도 살펴보세요. QR 코드, 브라우저 페이지 제목, 구독 주소는 서로 다른 정보입니다. 안내 페이지의 URL을 입력하면 서버 정보가 아니라 웹페이지 내용만 가져올 수 있습니다.

첫 가져오기 후 확인 순서

먼저 그룹 이름을 확인한 다음 서버 하나를 골라 Type, Address, Port가 보유한 정보와 일치하는지 확인합니다. 구독 항목 수는 원격 관리에 따라 달라질 수 있으므로 항목이 많다는 이유만으로 가져오기가 올바르다고 판단하지 마세요. 이름은 표시되지만 목록이 비어 있다면 요청 실패, 빈 응답, 형식 해석 실패를 구분해야 합니다. 이때 기존 구독은 그대로 두고 오류 메시지를 기록하세요. 상황을 덮어쓸 수 있으니 삭제와 재추가를 반복하지 마세요.

첫 요청이 실패했다고 해서 반드시 링크가 만료된 것은 아닙니다. 현재 네트워크에서 구독 주소에 접근할 수 없거나 원격 서버가 일시적으로 응답하지 않거나 로그인 페이지가 반환됐을 수도 있습니다. 이미 사용할 수 있는 항목이 있다면 우선 그대로 유지하세요. 서버가 하나도 없다면 현재 네트워크와 신뢰할 수 있는 다른 네트워크에서 각각 한 번씩 확인해 보세요. 여러 설정을 계속 바꾸면 비교 기준을 잃을 수 있습니다. 자세한 내용은 구독을 가져오지 못하거나 서버 목록이 비어 있을 때 확인할 사항을 참고하세요.

이 장을 마치면 구독 상위 항목, 해당 구독이 관리하는 서버, 현재 선택된 연결 항목을 구분할 수 있어야 합니다. 독립 서버만 보이고 업데이트 가능한 구독 관계가 없다면 단일 공유 링크를 가져왔을 수 있습니다. 표시 이름만으로 자동 업데이트 여부를 판단하지 마세요. 다음에 관리하기 전에 해당 항목이 실제로 Subscribe에 속하는지 확인하세요.

02 Add Server: 입력란별로 직접 확인하기

이름으로 설정을 추측하지 말고 프로토콜에 맞는 양식을 선택하세요

직접 입력은 서버 매개변수를 정확히 알고 있을 때 사용합니다. Add Server에서 먼저 Type을 선택한 다음 해당 프로토콜에 필요한 항목을 입력하세요. Type마다 인증 방식, 전송 옵션, 암호화 설정이 다릅니다. 유형을 바꾼 뒤에도 기존 입력란의 의미가 그대로라고 가정하지 마세요. 서버 이름은 식별용 라벨일 뿐입니다. 이름에 Trojan 등 프로토콜 이름이 들어 있어도 자료에 명시된 프로토콜 유형을 대신할 수 없습니다.

Address에는 일반적으로 호스트 이름이나 IP 주소를 입력하고 Port에는 서버가 수신 대기하는 포트를 입력합니다. 호스트 이름과 포트가 따로 제공됐다면 프로토콜 접두사, 웹페이지 경로, 쿼리 매개변수를 Address에 함께 넣지 마세요. IPv6 주소는 현재 입력란의 형식에 맞춰 입력하세요. 공유 링크의 대괄호와 포트 표기를 모든 양식에 그대로 옮기면 안 됩니다. 포트는 서버 설정과 일치해야 하며, 예시에서 자주 사용하는 번호를 임의로 적용하지 마세요.

인증, TLS, 전송 계층을 각각 확인하기

Shadowsocks는 비밀번호와 암호화 방식이 서로 맞아야 합니다. VMess와 VLESS는 UUID 인증을 사용하는 경우가 많고, Trojan은 해당 프로토콜에 맞는 비밀번호 인증을 사용합니다. WireGuard는 키, 주소, 피어 설정으로 구성되므로 주소와 비밀번호만 입력하는 양식처럼 다루면 안 됩니다. Hysteria2도 서버 자료에 따라 인증 및 전송 매개변수를 입력해야 합니다. 여기서는 확인 절차를 안내할 뿐, 모든 프로토콜의 옵션을 서로 바꿔 쓸 수 있다는 뜻은 아닙니다.

TLS 관련 입력란은 제공된 자료에 맞춰 입력하세요. SNI는 TLS 핸드셰이크에서 사용하는 서버 이름입니다. 연결 대상인 Address와 인증서에 지정된 이름은 다를 수 있으므로 도메인 두 개가 보인다고 중복이라고 판단하지 마세요. 인증서 오류가 발생하면 도메인, 기기 시간, 서버 인증서, 전송 설정부터 확인하세요. 인증서 검증 건너뛰기를 일반적인 해결책으로 사용하지 마세요. 실제 주소나 인증서 문제를 가릴 수 있으며 연결 검증 범위도 달라집니다.

WebSocket 같은 전송 방식을 사용할 때는 Host와 Path가 서버 라우팅에 영향을 줄 수 있습니다. Path의 슬래시, 대소문자, 쿼리 매개변수는 의미가 있을 수 있으므로 보기 좋게 임의로 줄이지 마세요. Host가 Address와 반드시 같아야 하는 것도 아닙니다. 제공되지 않은 입력란은 예시 매개변수를 임의로 채우기보다 적절한 기본값으로 두는 편이 낫습니다. 자료에 명시된 경우에만 변경하고, 변경 사항과 결과를 함께 기록하세요.

저장 후 한 번에 하나씩 검증하기

처음 저장할 때는 알아보기 쉬운 Remarks를 사용하고, 직접 입력한 항목과 구독 항목을 구분하세요. 먼저 저장과 선택이 되는지 확인한 뒤 테스트와 실제 접속을 진행합니다. 실패하면 근거가 있는 매개변수 한 종류씩 조정하세요. 예를 들어 포트를 바로잡은 다음 인증을 확인하고, 마지막으로 전송 설정을 살펴봅니다. Type, TLS, Path, DNS를 한꺼번에 바꾸면 우연히 연결이 복구돼도 어떤 변경이 효과가 있었는지 알 수 없습니다.

같은 서버의 공유 링크는 가져올 수 있지만 직접 입력한 항목은 사용할 수 없다면 두 항목의 입력값을 나란히 비교하세요. 단, 전체 인증 정보를 공개하지 마세요. 이름만 비교하지 말고 인증 문자열, TLS 상태, SNI, 전송 매개변수를 확인하세요. 자료가 충분하지 않다면 본인의 서비스 제공자에게 누락된 항목을 문의해야 합니다. 호스트 이름만으로 올바른 비밀번호, UUID 또는 서버 수신 방식을 알아낼 수는 없습니다.

직접 입력한 항목은 일반적으로 원래 구독을 업데이트해도 자동으로 수정되지 않습니다. 구독에서 복사해 변경한 항목이라면 비고에 ‘수동’이라고 표시하고 변경 이유를 남겨 두세요. 원격에서 포트나 인증 정보가 바뀌면 직접 입력한 복사본도 따로 확인해야 합니다. 목록에 이전 매개변수가 남아 있는데 이름이 같아 잘못 선택하는 일을 방지할 수 있습니다.

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

내용을 확인한 뒤 가져오기 방법 선택하기

QR 코드와 클립보드는 텍스트를 전달하는 수단일 뿐, 그 내용의 용도를 결정하지 않습니다. QR 코드에는 단일 서버 공유 링크, Subscribe 주소, 일반 웹페이지 주소가 들어 있을 수 있습니다. 스캔에 성공했다는 것은 QR 코드 내용을 읽었다는 뜻일 뿐, 서버 매개변수가 완전하거나 구독이 유효하거나 정보가 신뢰할 수 있다는 뜻은 아닙니다. 가져오기 전에 보유한 자료 중 무엇인지 확인하고, 가져온 뒤에는 어느 그룹에 들어갔는지도 살펴보세요.

Scan QR Code를 사용할 때는 QR 코드 전체가 화면에 들어오도록 맞추고 가장자리 잘림, 화면 반사, 지나친 이미지 압축을 피하세요. 카메라 기능을 처음 사용하면 시스템에서 카메라 접근 권한을 요청할 수 있습니다. 직접 스캔할 때 필요한 경우에만 허용하세요. QR 코드 이미지가 기기에 저장되어 있다면 이미지에서 바로 읽을 수 있는지와 메뉴 위치는 현재 앱 화면을 확인하세요. 인증 정보가 포함된 이미지를 디코딩을 위해 외부 인식 페이지에 올리지 마세요.

스캔 후 확인 절차를 생략하지 마세요

1. 인식된 내용이 예상한 자료인지 확인하세요. 특히 단일 서버인지 구독인지 구분합니다.
2. 편집 또는 확인 화면이 표시되면 Type, Address, Port, Remarks를 확인한 뒤 저장합니다.
3. Home으로 돌아가 새 항목과 소속 그룹을 확인한 다음 테스트하고 선택합니다.

카메라 초점 문제와 서버 연결 실패는 서로 다른 단계의 문제입니다. 전자는 조명, 거리, 이미지 선명도를 조정해야 하고, 후자는 매개변수와 네트워크를 점검해야 합니다. 스캔 후 지원하지 않는 내용이라는 메시지가 표시되면 먼저 데이터 형식을 확인하세요. 선명한 QR 코드를 반복해서 촬영할 필요는 없습니다. 서비스 제공자가 준 QR 코드가 안내 페이지로 연결되는 경우도 있습니다. 그 안에 명시된 앱용 자료를 사용하고, 웹페이지로 이동한 것을 서버 가져오기로 착각하지 마세요.

클립보드에는 완전한 자료 하나만 복사하기

본인 자료에서 링크를 복사할 때는 전용 복사 기능을 사용해 설명 문구, 따옴표, 문장 끝의 문장 부호가 함께 선택되지 않도록 하세요. Shadowrocket으로 돌아와 현재 화면에서 제공하는 클립보드 가져오기 기능을 사용합니다. 붙여넣기 허용 여부를 묻는다면 방금 직접 복사한 내용인지 확인한 뒤 진행하세요. 클립보드 내용을 확인하지 않은 상태에서 여러 팝업을 연이어 승인하면 이전에 복사한 오래된 항목을 가져올 수 있습니다.

여러 줄의 자료를 가져오려면 먼저 앱이 해당 일괄 형식을 지원하는지 확인하세요. 서로 다른 프로토콜의 링크 여러 개와 설명 문구, 구독 주소를 한꺼번에 섞어도 예상한 묶음으로 처리된다고 볼 수 없습니다. 먼저 단일 항목으로 절차를 확인한 다음 명시적으로 지원되는 일괄 자료를 처리하세요. 일부만 가져왔다면 모든 내용을 다시 붙여넣어 사용 가능한 항목이 중복되지 않도록, 원본 텍스트를 항목별로 비교하세요.

내용이 잘렸다면 링크 끝부분의 이름과 쿼리 매개변수가 남아 있는지 확인하세요. 일부 편집기는 긴 줄을 화면에서만 줄바꿈해 표시하므로 실제 줄바꿈이 아닐 수 있습니다. 반면 전달 방식에 따라 원문이 실제로 바뀌기도 합니다. 기기에서 텍스트의 시작과 끝을 확인하되 전체 인증 정보를 여러 메모나 공유 문서에 복사하지 마세요. 비교가 필요하면 복사본을 여기저기 저장하기보다 문자 위치와 필드의 유무를 확인하세요.

같은 자료를 이미 Subscribe로 가져온 뒤 QR 코드로 단일 항목을 가져오면 대개 구독에 자동으로 합쳐지지 않고 별도의 기록이 만들어집니다. 해당 기록은 구독 업데이트를 따라가지 않을 수 있습니다. 가져오기 전에 목록에 같은 항목이 있는지 확인하세요. 임시 확인용으로 가져왔다면 복사본에 구분되는 비고를 추가하고, 테스트를 마친 뒤 백업 및 삭제 장의 안내에 따라 처리하세요.

마지막으로 ‘자료 가져오기 성공’과 ‘시스템 연결 완료’를 따로 확인하세요. 목록에 새 항목이 생겼다고 연결이 켜진 것은 아닙니다. 시스템 VPN 구성 권한은 카메라나 붙여넣기 권한과도 다릅니다. 연결을 직접 시작할 때 필요한 시스템 권한을 처리한 뒤 실제 접속으로 결과를 확인하세요. 서로 다른 권한 단계를 하나의 가져오기 실패로 혼동하지 마세요.

04 공유 링크: 형식, 인코딩, Config의 차이

링크 접두사에 따라 해석 방식이 달라집니다

서버 공유 링크는 보통 프로토콜에 따라 ss://, vmess://, vless://, trojan:// 같은 URI 접두사로 시작합니다. 접두사 뒤에는 인증 정보, 주소, 매개변수가 바로 이어질 수도 있고 인코딩된 구조화 데이터가 올 수도 있습니다. 따라서 프로토콜마다 링크를 분해하는 방법이 다릅니다. 접두사만 바꾸면 한 프로토콜이 다른 프로토콜로 변환될 것이라고 기대해서는 안 됩니다.

아래 내용은 입력란의 위치를 확인하기 위한 예시입니다. 비밀번호와 도메인은 설명용 가짜 값이므로 실제 연결에 사용할 수 없습니다. Trojan 예시에서는 인증 정보가 주소 앞에 있고 물음표 뒤에는 매개변수, 샵 기호 뒤에는 비고가 옵니다. VLESS 예시는 예시용 UUID를 사용합니다. 실제로 사용할 때는 본인의 원문 전체를 보존하고 서버가 요구하는 전송 매개변수를 확인하세요. 링크 구조가 완전해 보여도 서버가 해당 설정을 받아들인다는 뜻은 아닙니다.

trojan://[email protected]:443?security=tls&sni=example.com#example-trojan

vless://[email protected]:443?encryption=none&security=tls&type=tcp&sni=example.com#example-vless

반복해서 디코딩하거나 직접 조합하지 마세요

URI의 일부 문자는 구분자 역할을 합니다. 인증 정보나 이름에 특수 문자가 있으면 퍼센트 인코딩이 필요할 수 있습니다. 인코딩된 퍼센트 문자열은 임의로 지워도 되는 불필요한 문자가 아닙니다. 반복해서 디코딩하면 원래 필드 내용이 새로운 구분자로 바뀔 수도 있습니다. 서비스 제공자가 준 링크라면 원본을 그대로 복사해 사용하세요. ‘짧아 보이게’ 만들려고 매개변수를 지우거나 공백을 넣거나 대소문자를 바꾸지 마세요.

VMess 등의 공유 형식에는 Base64로 인코딩된 내용이 포함될 수 있지만, Base64는 암호화가 아니라 인코딩 방식입니다. 문자열을 디코딩할 수 있다고 해서 결과를 공개 페이지에 붙여넣어도 되는 것은 아닙니다. 디코딩한 인증 정보도 민감한 자료입니다. 내용을 해석할 수 없다면 접두사, 원문 전체 여부, 형식 지원 여부부터 확인하세요. 여러 인코딩 변환을 연달아 시도하기보다 입력란을 하나씩 확인하는 편이 좋습니다.

비고는 대개 링크 끝에 있으며 보통 인증 기능을 담당하지 않습니다. 그렇다고 끝부분을 모두 삭제해도 된다는 뜻은 아닙니다. 샵 기호 앞의 쿼리 매개변수는 TLS, SNI, 전송 유형, 경로를 지정할 수 있습니다. 이를 지워도 가져오기는 될 수 있지만 원래 방식대로 연결되지 않을 수 있습니다. 가져온 양식이 예상과 다르면 원본 링크와 앱이 해석한 입력란을 비교하고, 해당 매개변수가 잘리거나 무시됐는지 확인하세요.

서버 공유 링크와 .conf는 서로 다른 종류의 자료입니다

단일 공유 링크는 주로 하나의 서버 연결 정보를 설명하고, Shadowrocket의 .conf 파일에는 규칙 등의 설정을 담을 수 있습니다. 아래는 규칙 장의 교육용 예시로, 순서에 따라 일치하는 기본 구조를 보여줄 뿐 완전한 연결 정보가 아닙니다. 이 내용을 복사해도 서버가 만들어지지 않으며 구독을 대신할 수도 없습니다. 사용하기 전에 필요한 정책이 본인의 Config와 연결 환경에서 올바른 의미인지 확인하세요.

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

DOMAIN-SUFFIX는 도메인 접미사와 일치하고 GEOIP는 대상 IP의 위치 정보를 기준으로 판단하며 FINAL은 앞선 규칙에 일치하지 않은 요청을 처리합니다. 규칙은 위에서 아래 순서로 적용되므로 앞의 포괄적인 규칙이 뒤의 세부 규칙을 가로막을 수 있습니다. 서버를 확인하는 동안 요청이 DIRECT로 처리됐다면 해당 접속 결과로 프록시 서버의 정상 여부를 판단할 수 없습니다. 가져오기와 트래픽 분리 설정을 따로 확인해야 하는 이유입니다.

공유 링크를 제대로 가져왔는지는 붙여넣을 수 있는지가 아니라, 가져온 뒤의 프로토콜·인증·전송 입력란이 원본 자료와 일치하는지로 판단해야 합니다. 입력란이 빠져 있다면 공유 형식에 해당 정보가 포함되어 있는지, 현재 해석 기능이 이를 지원하는지 확인한 뒤 자료에 따라 직접 보완하세요. 입력란의 역할을 모른 채 다른 서버의 값을 가져다 쓰면 재현 가능한 문제를 새로운 혼합 설정으로 바꿀 수 있습니다.

본인의 자료를 옮기려면 먼저 공유 대상이 단일 서버인지, 구독 주소인지, 전체 Config인지 확인하세요. 각 자료에 포함되는 범위가 다릅니다. 단일 항목에는 구독 업데이트 관계 전체가 포함되지 않으며, 규칙 일부만으로는 참조 대상이 모두 포함되지 않을 수도 있습니다. 설명 없이 긴 문자열만 보내기보다 자료의 종류와 용도를 명시하면 누락을 확인하기 쉽습니다.

05 업데이트 방법: 기존 상태를 보존하고 변경 사항 확인하기

구독 업데이트와 앱 업데이트는 별개입니다

구독 업데이트는 원격 서버 정보를 다시 요청하는 작업이고, 앱 업데이트는 App Store에서 진행합니다. 구독 업데이트가 실패했다고 바로 앱을 업데이트할 필요는 없으며, 앱이 최신이라고 구독도 새로고침됐다고 볼 수 없습니다. 정기적으로 관리할 때는 원격 정보 변경, 연결 오류, 앱 조작 문제 중 무엇을 해결하려는지 먼저 확인한 뒤 해당 작업을 선택하세요. 불필요한 변수를 줄일 수 있습니다.

업데이트 전에 현재 네트워크에서 구독 주소에 접근할 수 있는지 확인하고, 선택된 서버와 현재 작동 상태를 기록하세요. 원격에서 이름, 주소, 포트, 인증 정보, 항목 수가 바뀌면 로컬 목록도 달라질 수 있습니다. 업데이트가 항상 새 항목만 추가한다고 가정하거나 이전 항목이 반드시 유지된다고 생각하지 마세요. 직접 수정한 중요한 항목은 먼저 백업하세요. 새로고침 과정에서 구독 관리 데이터가 원격 결과로 덮어써질 수 있습니다.

업데이트 시점과 범위 선택하기

본인의 서비스 제공자가 변경 사항을 안내했거나 항목이 작동하지 않거나 정보를 확인해야 할 때는 수동 업데이트가 적합합니다. 현재 화면에 자동 업데이트 관련 설정이 있다면 네트워크 환경과 사용 빈도에 맞춰 설정하고 일정 시간이 지난 뒤 실제 결과를 확인하세요. 자동 업데이트도 확인 절차를 대신하지는 않습니다. 네트워크 연결 불가, 계정 상태 변경, 응답 형식 오류로 업데이트가 완료되지 않을 수 있습니다.

한 번의 연결 실패를 해결하려고 모든 구독을 연이어 업데이트하는 것은 권장하지 않습니다. 여러 요청이 동시에 실패하면 공통 네트워크 문제와 특정 구독 문제를 구분하기 어렵고, 원격 서비스에서 잦은 요청을 제한할 수도 있습니다. 관련된 구독 하나부터 업데이트하고 오류와 목록 변화를 확인한 뒤 나머지를 처리하세요. 특정 연결을 중요한 작업에 사용 중이라면 현재 상태를 유지하고 적절한 시점에 관리하세요.

버튼 상태가 아니라 결과로 성공 여부 판단하기

업데이트가 끝나면 변경될 것으로 예상되는 항목을 하나 이상 확인해 실제로 입력값이 갱신됐는지 살펴보세요. 버튼이 다시 눌리거나 로딩 표시가 사라졌다는 것은 작업이 끝났다는 뜻일 뿐, 응답 내용이 올바르다는 증거는 아닙니다. 서비스 제공자가 포트를 변경했다고 안내했는데도 이전 값이 남아 있다면 올바른 구독을 업데이트했는지, 링크가 정확한 자료를 가리키는지, 원격에서 변경 사항을 게시했는지 확인하세요. 모든 항목을 곧바로 다시 만들지 마세요.

일부 구독은 사용량이나 만료 정보를 함께 제공할 수 있습니다. 이 정보는 원격에서 전달되며 앱이 사용 가능량을 독립적으로 검증했다는 뜻은 아닙니다. 정보가 표시되지 않거나 서비스 제공자의 기록과 다르면 응답 헤더 또는 자료 내용과 계정 상태를 각각 확인하세요. 이름에 포함된 날짜만 보고 이용 권한을 판단하지 말고, 이전에 표시된 정보를 갱신된 권한의 증거로 여기지도 마세요.

업데이트 후에는 기존에 선택한 항목의 이름이 바뀌거나 교체되거나 삭제될 수 있으므로 다시 선택 상태를 확인하고 실제로 접속해 보세요. Config에서 사용자 지정 이름이나 정책을 참조한다면 해당 참조도 유효한지 확인해야 합니다. 데이터 새로고침은 성공했지만 접속 경로가 바뀌었다면 구독 요청보다 참조와 선택 설정의 문제일 수 있습니다. 트래픽 분리 설정은 Global Routing 세 가지 모드의 차이를 참고하세요.

원격 자료에 문제가 있는 것으로 확인됐다면 앱에서 매개변수를 하나씩 추측하기보다 서비스 제공자가 수정할 때까지 기다리세요. 임시로 직접 입력해 사용 중인 항목은 별도로 표시해 다음 업데이트 때 구독 관리 항목으로 착각하지 않도록 합니다. 문제가 해결되면 임시 복사본을 정리하고, 장기 관리 대상을 명확한 구독과 필요한 수동 항목으로 정돈하세요.

06 여러 구독 정리: 이름, 소속, 규칙 참조

구독 소속을 기준으로 항목을 정리하세요

여러 구독을 관리할 때는 목록을 최대한 길게 만드는 것이 아니라, 각 항목의 업데이트 출처와 보관 이유, 현재 사용 여부를 파악하는 것이 중요합니다. 각 Subscribe 상위 항목에 바뀌지 않는 별칭을 지정하고 원격 항목의 식별 정보는 유지하세요. 별칭에는 개인 용도나 자료 종류를 표시할 수 있지만 전체 인증 정보를 넣으면 안 됩니다. 두 구독에서 같은 서버 이름이 반환되더라도 소속 그룹으로 구분할 수 있어야 합니다.

구독 별칭과 서버 Remarks의 역할은 다릅니다. 상위 항목 이름은 업데이트 출처를 식별하고 하위 항목 이름은 연결 대상을 식별합니다. 직접 입력한 복사본에는 관리 방식을 별도로 표시하세요. ‘개인 구독·일상용’, ‘개인 구독·예비용’, ‘수동·테스트’처럼 이름을 붙일 수 있습니다. 다만 ‘예비용’이라는 이름만으로 자동 장애 전환이 설정된 것은 아닙니다. 이름은 관리용 표시일 뿐 실제 선택은 현재 설정에 따라 달라집니다.

표시 이름만 보고 중복 항목을 삭제하지 마세요

이름이 같은 두 항목이라도 서로 다른 서버를 가리킬 수 있으며, 주소가 같아도 포트, 인증, 전송 설정이 다를 수 있습니다. 중복인지 판단할 때는 소속 구독, Type, Address, Port, 주요 전송 입력란을 차례로 비교하세요. 인증 정보는 기기에서 직접 확인하고 공개 표로 내보내지 않아도 됩니다. 두 구독이 같은 대상을 각각 관리한다면 로컬 하위 항목을 삭제해도 다음 업데이트 때 다시 나타날 수 있습니다.

따라서 관리 대상인 하위 항목을 계속 삭제하기보다 해당 구독을 유지해야 하는지 먼저 결정하세요. 같은 구독을 중복 추가했다면 현재 사용 중인 관계가 어느 상위 항목에 있는지 확인하고 백업한 뒤 불필요한 상위 항목을 제거합니다. 테스트 중 만든 독립 복사본이라면 현재 규칙이나 선택 항목에서 참조하지 않는지 확인한 다음 삭제하세요. 한 번에 조금씩 정리하고 각 단계 후 접속을 확인하면 관계를 복구할 수 없는 상황을 피할 수 있습니다.

목록 순서를 트래픽 분리 정책으로 혼동하지 마세요

서버 목록의 표시 순서는 주로 항목을 찾기 위한 것입니다. 항목을 맨 위로 옮겨도 모든 요청이 해당 항목을 사용한다고 볼 수 없으며, 이름순 정렬이 우선순위나 장애 전환을 설정하지도 않습니다. 실제 요청 경로에는 Global Routing, 현재 선택한 서버, Config의 규칙과 정책 참조가 모두 영향을 줍니다. 목록을 정리한 뒤에는 실제 설정을 확인하고 첫 번째 항목 이름만으로 연결 경로를 판단하지 마세요.

사용자 지정 Config가 특정 이름을 참조한다면 이름을 바꾸기 전에 참조 방식을 확인하세요. 일부 Config는 명시적인 이름으로 대상을 지정하고, 다른 Config는 필터 표현식으로 대상을 구성하므로 이름 변경의 영향이 다릅니다. 원격 업데이트로 기존 이름이 바뀔 수도 있습니다. 관리할 때는 이름 규칙과 Config 참조를 일치시키세요. 이름을 바꾼 뒤 목록에 항목이 남아 있다고 해서 모든 규칙 관계가 자동으로 동기화됐다고 판단하지 마세요.

이름 필터는 가능한 한 구체적으로 설정해 관련 없는 항목이 포함되지 않도록 하세요. 원격에서 정한 이름은 항상 유지되는 값이 아닙니다. 이름의 지역명, 기호, 번호에 의존한다면 업데이트 후 필터 결과를 확인하세요. 결과 항목이 하나도 없거나 예상보다 늘어나면 정책 선택에 영향을 줄 수 있으며, 서버 자체가 연결되더라도 문제가 발생할 수 있습니다. 이때는 인증 정보를 다시 바꾸기보다 항목 모음과 참조를 확인하세요.

오랫동안 사용하지 않은 구독은 보관할 필요가 있는지 검토하고, 정리하기 전에 필요한 복구 자료를 저장하세요. 사용할 수 없는 상태, 일시적인 연결 불가, 더 이상 필요하지 않은 상태를 같은 의미로 취급하면 안 됩니다. 앞의 두 가지는 문제 진단이고 마지막은 관리 결정입니다. 용도를 확인한 뒤 삭제하면 목록을 깔끔하게 정리하려다 여전히 필요한 예비 자료를 제거하는 일을 막을 수 있습니다.

07 Connectivity Test: 지연 시간, 정렬, 실제 접속

테스트가 확인하는 단계부터 파악하기

Connectivity Test 결과는 어떤 방식으로 검사했는지에 따라 해석해야 합니다. TCP 유형 테스트는 주로 서버 포트와의 연결 수립을 확인하고, HTTP 유형 테스트는 지정된 대상과 요청 과정까지 포함합니다. 서로 다른 방식을 직접 비교할 수는 없습니다. 포트가 응답한다고 인증, TLS, 프록시 전달, 대상 웹사이트가 모두 정상이라는 뜻은 아닙니다. 테스트가 실패해도 서버를 영구적으로 사용할 수 없다는 의미는 아닙니다. 먼저 어느 단계에서 실패했는지 확인하세요.

테스트 전에 Settings에서 현재 테스트 방식과 대상을 확인하세요. 실제로 표시되는 설정은 앱 화면을 기준으로 확인합니다. 여러 서버를 비교할 때는 네트워크, 대상, 테스트 방식을 가능한 한 동일하게 유지하세요. 이동통신망과 Wi-Fi, 시간대, 기기의 신호 상태에 따라 결과가 달라질 수 있습니다. 항목마다 다른 조건에서 테스트하면 숫자가 보기 좋게 정리되어도 신뢰할 수 있는 비교가 아닙니다.

한 번의 테스트 결과로 장기 품질을 판단하지 마세요

지연 시간은 특정 조건에서 한 번 또는 여러 번 측정한 왕복 시간입니다. 다운로드 속도, 지속적인 처리량, 장시간 연결의 안정성을 뜻하지는 않습니다. 가장 낮은 수치는 가까운 진입점 때문에 나올 수 있지만, 이후 대상에 접속할 때는 다른 경로와 부하가 영향을 줍니다. 관리할 때는 테스트 결과로 후보를 추린 뒤 실제 사용 환경에서 확인하세요. 숫자가 가장 낮은 항목만 남기고 용도가 있는 나머지 항목을 곧바로 삭제하지 마세요.

시간 초과가 발생하면 전체 항목에 일괄 테스트를 반복하기 전에 한두 개를 골라 다시 확인하세요. 여러 항목을 동시에 테스트하면 연결 요청이 많이 발생하며 현재 네트워크나 원격 서비스의 제한을 받을 수 있습니다. 같은 시각에 모든 항목이 실패하면 공통 네트워크, 테스트 대상, 현재 설정부터 확인하세요. 특정 항목만 계속 실패한다면 해당 항목의 Address, Port, 인증, 전송 설정을 집중적으로 확인하면 문제 범위를 좁힐 수 있습니다.

정렬은 찾기 위한 기능이고 실제 접속은 검증 절차입니다

지연 시간순으로 정렬한 뒤 표시된 값이 방금 측정한 결과인지, 테스트하지 않았거나 실패한 항목이 있는지 확인하세요. 상태에 따라 항목 순서가 다르게 표시될 수 있으므로 빈 값을 지연 시간 0으로 해석하지 마세요. 정렬은 항목 선택과 다릅니다. 정렬을 마친 뒤 원하는 항목을 직접 선택하고 시스템 연결 상태를 확인하세요. Config에서 정책 그룹을 사용한다면 실제 요청이 해당 항목을 거치는지, 그룹의 다른 선택 항목이 대신 처리하는지도 확인해야 합니다.

1. 현재 네트워크와 테스트 방식을 일정하게 유지하고 관련 서버를 테스트해 오류가 발생한 범위를 기록합니다.
2. 확인할 서버 항목을 선택하고 Global Routing 및 현재 Config를 점검해 대상이 DIRECT로 처리되지 않도록 합니다.
3. 연결한 뒤 실제로 사용하려던 대상에 접속해 정상 요청이 완료되는지 확인합니다. 홈페이지가 나타나는지만 보지 마세요.
4. 실패 메시지를 정확히 기록하고 이름 해석, 연결 수립, 인증, TLS, 대상 접속을 각각 확인하세요. 여러 설정을 동시에 바꾸지 마세요.

테스트에는 성공했지만 실제 접속에 실패한다면 규칙이 다른 정책을 적용했는지, DNS가 예상한 주소를 반환했는지, TLS 설정이 맞는지, 대상 자체가 사용 가능한지 확인하세요. 반대로 테스트 대상에 연결할 수 없는데 실제 서비스는 정상이라면 테스트 조건이 맞지 않을 수도 있습니다. 단일 테스트 결과만으로 실제 관찰을 무시하지 마세요. 두 결과를 함께 사용해 문제를 찾고 하나만 정답이라고 강요하지 마세요.

일시적인 문제 해결을 위해 Global Routing을 바꿨다면 확인이 끝난 뒤 기존의 평소 설정으로 되돌리세요. Proxy는 프록시 경로를 확인하는 데 도움이 되지만 모든 문제의 해결책은 아닙니다. Direct는 직접 연결과 비교할 수 있지만 프록시 경로가 정상이라는 증거는 아닙니다. Config를 선택했다면 실제로 일치한 규칙을 확인하세요. 대상이 REJECT로 차단됐다면 서버를 바꿔도 해결되지 않을 수 있으므로 규칙과 잘못된 일치 여부를 확인하세요. 자세한 내용은 REJECT 정책과 규칙 일치 범위를 참고하세요.

최종적으로 유지할 항목은 용도가 분명하고 매개변수를 관리할 수 있으며 실제 테스트에서 요구 사항을 충족한 기록이어야 합니다. 특정 정렬에서 맨 위에 놓인 이름만으로 결정하지 마세요. 테스트는 문제 범위를 좁히는 데 쓰이며 계정 상태 확인이나 백업을 대신하지 않습니다. 장기간 비교할 때는 같은 방식과 적은 수의 항목을 사용하면 변화 원인을 파악하기 쉽습니다.

08 삭제 및 백업: 데이터 범위에 맞춰 복구하기

삭제할 대상을 먼저 구분하기

서버 항목 하나를 삭제하는 것, Subscribe 상위 항목을 삭제하는 것, Config를 삭제하는 것, 시스템 VPN 구성을 삭제하는 것은 서로 다른 대상을 처리합니다. 개별 항목에는 연결 매개변수가, 구독 상위 항목에는 원격 업데이트 관계가, Config에는 규칙 등의 설정이 들어 있습니다. 시스템 VPN 구성은 기기 권한과 연결 설정에 해당합니다. 실행 전에 대상의 계층을 확인하세요. 모든 삭제를 ‘처음부터 다시 시작’하는 일로 생각하면 잘못된 자료는 남기고 필요한 규칙을 지울 수 있습니다.

구독에서 관리하는 하위 항목을 삭제하면 원격에서 해당 항목을 계속 반환하기 때문에 다음 업데이트 때 다시 나타날 수 있습니다. 상위 항목을 삭제하면 관리 대상 항목도 함께 제거될 수 있으므로 현재 확인 메시지에서 적용 범위를 읽으세요. 어느 경우든 로컬에서 삭제했다고 원격 이용 권한이 취소되는 것은 아니며, 이미 유출된 구독 주소도 자동으로 폐기되지 않습니다. 원격 계정과 인증 정보는 본인의 서비스 제공자 계정 절차를 통해 관리하세요.

실제로 필요한 자료가 백업에 포함되는지 확인하기

공유 링크 하나만 저장하면 보통 연결 하나만 복구할 수 있습니다. 구독 주소만 저장해도 로컬에서 변경한 이름, 직접 입력한 복사본, 규칙 파일, 개인 설정까지 복구된다고 보장할 수는 없습니다. 백업 전에 필요한 범위를 정리하세요. 구독 URL, 중요한 직접 입력 항목, 사용 중인 Config, 연결에 영향을 주는 필수 설정 등이 포함될 수 있습니다. 이름에 ‘백업’이라고 적힌 파일이 모든 항목을 자동으로 담는다고 가정하지 말고 현재 내보내기 기능의 설명에서 범위를 확인하세요.

앱에서 제공하는 백업 또는 내보내기 기능을 사용한다면 생성되는 자료의 내용, 인증 정보 포함 여부, 복원할 때 기존 데이터를 덮어쓰는지 확인하세요. 자료를 항목별로 저장한다면 ‘규칙 Config’, ‘개인 구독 주소’, ‘수동 테스트 항목’처럼 용도와 범위를 표시하세요. 실제 서버 비밀번호를 이름에 넣을 필요는 없습니다. 백업 파일에는 민감한 인증 정보가 포함될 수 있으므로 접근이 제한된 위치에 보관하고 기기의 보안 설정에 따라 보호하세요.

전체를 덮어쓰지 말고 일부를 먼저 복원해 확인하기

1. 현재 기기의 항목 중 보존해야 할 것이 있는지 확인하고, 필요하면 현재 상태를 별도로 백업합니다.
2. 자료 유형에 맞춰 구독, 직접 입력 항목, Config를 복원하고 결과를 확인하세요. 같은 자료가 여러 그룹에 중복으로 들어가지 않도록 합니다.
3. 현재 선택된 서버, Global Routing, Config, 관련 설정을 확인하세요. 목록에 항목이 표시되는 것만으로 복원이 끝났다고 판단하지 마세요.
4. 테스트와 실제 접속을 확인한 뒤 중복 항목과 임시 파일을 정리하고, 범위가 명확한 유효한 백업 하나를 보관합니다.

새 기기로 바꿀 때는 앱 자체와 앱 내부 자료를 각각 확인해야 합니다. App Store에서 구입한 앱을 다시 받더라도 모든 구독과 로컬 Config가 예상대로 복원된다는 뜻은 아닙니다. 기기 데이터가 옮겨지는지는 실제 이전 방식과 복원 결과를 기준으로 확인하세요. 구입 및 구입 항목 복원 절차는 새 기기로 변경하거나 앱을 다시 설치할 때를 참고하세요. 앱 개발자는 Shadow Launch Technology Limited이며, 제품 페이지의 앱 ID는 932747118입니다.

다른 iPhone 또는 iPad로 복원한 뒤 시스템에서 VPN 구성 권한을 다시 확인할 수 있습니다. 이전 기기에서 허용했다는 사실만으로 새 기기에서도 허용됐다고 볼 수 없습니다. 서버에서 기기 수나 동시 연결을 제한하는지도 확인해 원격 제한을 백업 손상으로 오인하지 마세요. 매개변수가 확인된 항목 하나로 먼저 검증한 다음 나머지 자료를 단계적으로 복원하면 기기 권한, 데이터 이전, 서버 상태를 빠르게 구분할 수 있습니다.

백업도 지속해서 관리해야 합니다. 원격에서 인증 정보를 재설정하거나 주소를 변경하거나 로컬 규칙을 수정했다면 이전 백업이 더 이상 유효하지 않을 수 있습니다. 전체 검증에 성공한 뒤 유효한 백업을 갱신하고 포함된 자료의 범위를 표시하세요. 알아보기 어려운 민감한 복사본을 계속 쌓아두지 말고, 새 백업의 복원 가능성을 확인하기 전에 유일한 이전 복사본을 서둘러 삭제하지 마세요. 삭제와 보관은 복구 가능성을 기준으로 결정해야 합니다.

이 페이지의 관리 절차는 자료의 출처 확인, 가져온 뒤 입력값 검토, 업데이트 전 현재 상태 보존, 정리 후 참조 확인, 테스트 후 실제 접속 검증, 삭제 전 백업 확인 순서입니다. 구체적인 오류가 계속되면 자주 묻는 질문에서 증상에 맞는 내용을 확인하세요. 처음부터 다시 연결해야 한다면 시작하기로 돌아가 한 가지 절차를 차례대로 확인하세요. 모든 구독과 Config를 한꺼번에 다시 만들 필요는 없습니다.