Shadowrocket
구독 및 서버 관리 가이드

02 / ADD SERVER

Add Server 수동 입력 항목 및 매개변수 확인

완전한 서버 매개변수를 보유하고 연결 정보를 하나씩 확인해야 하는 경우 수동 추가를 이용할 수 있습니다. 먼저 프로토콜 유형을 선택한 다음 해당 항목을 입력하세요. 주소와 비밀번호를 모두 입력한 뒤 유형을 계속 바꾸는 방식은 피해야 합니다. 프로토콜마다 인증 방식과 전송 설정이 다르며 유형을 바꾸면 일부 항목이 더 이상 적용되지 않을 수 있습니다. 수동 입력의 목적은 이미 받은 정보를 정확하게 옮기는 것이지, 여러 조합을 시도해 양식의 빈칸을 채우는 것이 아닙니다.

주소, 포트, 인증 정보를 각각 입력하세요

서버 주소에는 자료에 기재된 도메인 또는 IP 주소를, 포트에는 제공된 숫자를 입력하세요. 일반적인 주소 항목에는 웹 경로를 덧붙일 필요가 없으며 전체 공유 링크를 주소 입력란에 넣어서도 안 됩니다. 도메인 앞뒤에 공백이 없어야 하고 포트는 유효한 정수여야 합니다. 주소에 콜론이 있다면 포트 구분자인지 IPv6 주소의 일부인지 확인하세요. 마지막 부분을 기준으로 단순히 나누면 안 됩니다.

인증 정보는 선택한 프로토콜에 맞아야 합니다. Shadowsocks는 암호화 방식과 비밀번호가 일치해야 합니다. VMess와 VLESS는 UUID를 사용하는 경우가 많고, Trojan은 일반적으로 비밀번호를 사용합니다. HTTP와 SOCKS5에서는 사용자 이름과 비밀번호를 사용할 수 있습니다. UUID를 서버 도메인으로 입력하거나 ‘메모’를 비밀번호에 넣지 마세요. 비슷한 문자가 많다면 복사해 입력해 오류를 줄이되, 붙여넣은 뒤 앞뒤 공백과 불필요한 줄바꿈을 확인해야 합니다.

TLS, SNI 및 전송 설정은 추측하지 마세요

TLS 관련 이름은 연결 주소와 반드시 같지는 않습니다. 서버 주소는 연결 대상을 지정하고, SNI는 TLS 핸드셰이크에서 이름을 전달하는 데 사용됩니다. 두 항목의 용도는 다릅니다. 자료에 SNI가 명시되어 있다면 그대로 입력하세요. 안내가 없을 때 다른 서버의 값을 임의로 적용하지 마세요. 인증서 오류가 발생하면 이름, 기기 시간, 인증서 상태를 확인해야 합니다. 일상적인 해결 방법으로 인증서 검증을 끄지 마세요.

특정 전송 방식을 사용할 때는 Host, Path 등의 항목이 서버의 연결 처리에 영향을 줄 수 있습니다. 경로의 슬래시, 대소문자, 쿼리 내용은 모두 의미가 있을 수 있으므로 임의로 바꾸지 마세요. 주소와 포트가 같아도 전송 매개변수까지 같다는 보장은 없습니다. 필수 정보가 누락되었다면 서비스 제공업체에 확인하고, 다른 작동하는 기록의 설정을 복사해 운에 맡기지 마세요.

한 번에 한 가지씩 바꿔 수동 기록을 확인하세요

저장하기 전에 수동으로 추가한 기록에 눈에 띄는 메모를 붙여 구독에서 생성된 기록과 구분하세요. 처음 확인할 때는 해당 서버 하나만 선택하고 Config, DNS, 연결 조건은 동시에 바꾸지 마세요. 먼저 현재 네트워크에서 매개변수대로 연결할 수 있는지 확인한 뒤 규칙이 예상대로 작동하는지 살펴보세요. 여러 항목을 동시에 변경하면 연결이 다시 되더라도 어떤 항목이 영향을 줬는지 파악하기 어렵습니다.

수동 기록은 구독을 새로 고쳐도 같은 방식으로 자동 업데이트되지 않는 경우가 많습니다. 서비스 제공업체가 포트, 비밀번호 또는 인증서 요구 사항을 변경했다면 해당 기록을 다시 확인해야 합니다. 매개변수의 출처와 용도를 기록하되 전체 비밀번호를 누구나 볼 수 있는 메모에 적지 마세요. 테스트용 중복 기록은 확인이 끝난 뒤 정리해 오래된 기록을 잘못 선택하거나 만료된 매개변수를 앱 연결 문제로 오인하지 않도록 하세요.

WireGuard와 같은 유형은 키, 주소, 피어 매개변수의 고유한 구조를 사용하므로 일반적인 ‘도메인과 비밀번호’ 방식으로 입력할 수 없습니다. 완전하고 서로 일치하는 자료를 보유한 경우에만 수동으로 설정하세요. 개인 키는 안전하게 관리해야 합니다. 유형별 차이를 먼저 알아보려면 지원 프로토콜 및 항목 개요를 읽고 이 장으로 돌아와 하나씩 확인하세요.

04 / LINK FORMATS

공유 링크 형식과 Config의 범위

공유 링크는 연결 매개변수를 인코딩한 표현이지, 일반 웹 주소를 다른 방식으로 쓴 것이 아닙니다. 프로토콜마다 접두사와 항목 구성 방식이 다르고 매개변수가 인코딩되어 있을 수도 있습니다. 링크가 온전한지 확인할 때는 비밀번호를 눈으로 읽으려 하지 말고 접두사, 본문, 쿼리 매개변수, 메모가 보존되었는지 살펴보세요. 인식되지 않는 링크는 문자를 무작정 바꾸지 말고 형식 안내와 원본 내용을 먼저 확인하세요.

단일 링크와 구독 URL을 구분하세요

ss://, vmess://, vless://, trojan:// 등의 접두사가 붙은 내용은 일반적으로 해당 프로토콜의 서버 정보를 나타냅니다. 일반 HTTPS 구독 URL은 여러 기록을 가져오는 네트워크 경로입니다. 접두사로 유형을 짐작할 수는 있지만 내용이 유효하거나 현재 환경에 맞는다는 보장은 없습니다. 같은 프로토콜에도 서로 다른 인코딩 형식과 추가 매개변수가 있을 수 있으므로 앱이 지원하는 형식으로 파싱할 수 있어야 합니다.

공유 링크를 브라우저 주소로 취급해 직접 확인하지 마세요. 브라우저에서 특정 프로토콜 접두사를 열 수 없다고 서버를 사용할 수 없는 것은 아닙니다. 반대로 HTTPS 주소에서 페이지가 표시되어도 가져올 수 있는 구독이라는 뜻은 아닙니다. 예상한 형식으로 응답이 돌아오는지, 클라이언트가 올바른 기록을 생성하는지 확인해야 합니다. 문제를 해결할 때는 먼저 입력 유형을 구분한 뒤 알맞은 가져오기 메뉴를 선택하세요.

# 구독 URL의 구조만 표시합니다. 실제 서비스 주소가 아닙니다
https://example.com/sub?token=xxxx

# 자주 쓰이는 단일 공유 링크 접두사
ss://
vmess://
vless://
trojan://

인코딩, 쿼리 매개변수, 메모 처리

링크의 퍼센트 인코딩과 Base64 내용에는 필수 항목이 들어 있을 수 있으므로 ‘보기 좋게’ 만들기 위해 직접 변환하지 마세요. 일부 문자열에서 더하기 기호, 슬래시, 등호는 인코딩에 쓰입니다. 복사 과정에서 더하기 기호가 공백으로 바뀌거나 마지막 문자가 빠지면 파싱에 실패할 수 있습니다. 먼저 전체 원문을 다시 받은 뒤 호환 여부를 확인하세요. 한 번의 복사 오류를 프로토콜 자체의 문제로 단정하지 마세요.

물음표 뒤의 매개변수는 TLS, 전송 방식, 경로 또는 다른 프로토콜 옵션을 나타낼 수 있으므로 일괄적으로 추적 정보라고 보고 삭제하면 안 됩니다. 많은 공유 형식에서 샵 기호 뒤의 내용은 메모로 사용되지만 원래 형식대로 앱에 전달해야 합니다. 한국어 이름이 깨져 보이는 것은 메모 인코딩 문제일 수 있으며, 본문 매개변수에는 영향을 주지 않을 수도 있습니다. 표시 이름과 연결 기능을 따로 확인하고 두 문제를 혼동하지 마세요.

서버 링크는 Config를 대신하지 않습니다

서버를 가져오면 보통 연결 대상이 저장될 뿐, 규칙, DNS, Global Routing까지 설정되는 것은 아닙니다. 규칙에 따라 트래픽을 분기하려면 현재 Config와 설정 모드를 확인하세요. Proxy 또는 Direct를 임시로 사용하면 트래픽 처리 방식도 달라집니다. 서버 이름에 특정 용도가 적혀 있어도 그것은 메모일 뿐이며, 클라이언트가 해당 규칙을 자동으로 만들지는 않습니다. 실제 설정을 별도로 확인해야 합니다.

아래는 Shadowrocket .conf의 규칙 구성을 보여 주는 예시로, 규칙 간 적용 관계만 설명하며 완전한 설정 파일은 아닙니다. 규칙은 파일에 적힌 순서대로 위에서 아래로 확인하며, 처음 일치하는 규칙에서 처리가 끝납니다. FINAL은 마지막 기본 처리 규칙으로 두어야 합니다. PROXY, DIRECT, REJECT는 규칙 동작을 나타내는 값이지 임의로 순서를 바꿀 수 있는 세 단계의 우선순위가 아닙니다.

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

형식 문제와 규칙 문제를 따로 확인하세요

링크를 파싱한 뒤 주소, 포트, 프로토콜이 빠져 있다면 원본 내용과 형식 호환성을 먼저 확인하세요. 서버 매개변수는 완전하지만 특정 도메인의 접속 경로가 예상과 다르다면 규칙 적용 여부를 살펴봐야 합니다. 규칙 문제를 해결하려고 공유 링크를 계속 수정하거나, 매개변수 하나가 빠진 문제를 가리려고 낯선 설정을 가져오지 마세요. 한 번에 한 영역씩 확인해야 결과를 해석할 수 있습니다.

문제를 논의할 때 프로토콜 유형, 오류 메시지, 일부 가린 항목 구조를 제공할 수 있지만 인증 정보가 포함된 전체 본문은 보내지 마세요. 표시 이름만 가려서는 충분하지 않습니다. 실제 민감 정보는 인코딩된 본문이나 URL 매개변수에 있을 수 있습니다. 어떻게 가려야 할지 확실하지 않다면 증상과 항목 이름만 설명하고 원본은 신뢰할 수 있는 개인 저장 공간에 보관해 정보 노출을 최소화하세요.

Config, Proxy, Direct 세 가지 선택의 용도는 Global Routing의 Config, Proxy, Direct 안내를 참고하세요. 이 장에서는 데이터 형식과 항목의 범위를 설명하며, 일상적인 연결 절차는 사용 설명서를 기준으로 진행합니다.

06 / ORGANIZE

여러 구독 및 기록 출처 정리

여러 구독을 관리할 때 가장 중요한 것은 이름을 통일하는 일이 아니라 각 기록의 출처와 관리 방법을 구분해 두는 것입니다. 구독에서 생성된 서버, 수동으로 추가한 서버, 임시 테스트 기록을 서로 구별할 수 있어야 합니다. 그렇지 않으면 서버 하나가 작동하지 않을 때 구독을 업데이트해야 하는지, 수동 매개변수를 수정해야 하는지, 임시 기록을 정리해야 하는지 판단하기 어렵습니다. 정리 구조는 나중에 관리하기 쉬워야 하며, 보기 좋게 만들려고 복잡한 계층을 추가할 필요는 없습니다.

변경이 적고 민감 정보가 드러나지 않는 이름 규칙을 사용하세요

구독 이름에는 ‘일상 A’, ‘예비 B’처럼 용도와 출처를 조합할 수 있습니다. 수동 기록에는 ‘수동’, 임시 기록에는 ‘테스트’ 표시를 붙이세요. 이름에 비밀번호, 전체 구독 URL, 인증 토큰을 넣지 마세요. 같은 출처에는 일관된 식별자를 사용하면 나중에 업데이트와 백업을 연결하기 쉽습니다. 메모에 용도를 기록할 수는 있지만 네트워크와 원격 조건에 따라 상태가 바뀔 수 있으므로 특정 서버가 항상 작동한다고 단정하지 마세요.

구독에서 생성된 이름은 새로 고칠 때 원격 내용으로 바뀔 수 있으므로 중요한 관리 정보를 그런 이름에만 기록하지 마세요. 오래 보관해야 하는 내용은 보호된 별도 기록에 구독 식별자와 필요한 구분 정보를 함께 적으세요. 목록에서의 위치만으로 서버를 기억하지 마세요. 업데이트, 그룹 접기, 정렬에 따라 위치가 달라질 수 있습니다. 이름, 프로토콜, 출처를 함께 확인하세요.

중복 항목은 이름이 아니라 식별 정보로 확인하세요

이름이 같은 두 기록이 서로 다른 주소에 연결될 수 있고, 이름이 달라도 같은 대상을 사용할 수 있습니다. 중복 여부를 판단할 때는 프로토콜, 주소, 포트, 주요 인증 정보와 전송 설정을 비교하세요. 민감한 값을 공개한 상태로 비교하지 마세요. 두 기록이 서로 다른 구독에서 왔다면 매개변수가 현재 같더라도 출처를 남겨 두세요. 이후 원격 업데이트 내용이 달라질 수 있습니다.

중복을 발견하면 실수로 가져온 것이 분명한 임시 기록부터 정리하세요. 확인 없이 구독에 속한 항목을 삭제하지 마세요. 일부 로컬 변경 사항은 다음 업데이트 때 다시 생성되거나 덮어써질 수 있으며, 실제 동작은 현재 앱을 기준으로 합니다. 구독을 더 이상 사용하지 않을 예정이라면 삭제 전에 이전과 백업을 완료하세요. 서버 몇 대만 삭제해도 다음 업데이트에서 가져올 목록이 달라지지 않을 수 있습니다.

목록 그룹과 규칙 정책은 서로 다릅니다

Home에서 표시 목적으로 묶은 그룹을 Config의 정책 선택과 같은 것으로 보면 안 됩니다. 같은 구독 아래 표시된다는 것은 서버가 같은 출처에서 왔다는 뜻일 뿐, 규칙에 따라 자동 전환된다는 의미가 아닙니다. 실제 트래픽 처리는 Global Routing, 현재 설정, 해당 설정의 정책 참조에 따라 달라집니다. 목록을 정리한 뒤 기존 선택이 일상적인 용도에 맞는지 확인하세요.

Config에서 이름을 참조하고 있다면 이름 변경으로 연결 대상이 달라질 수 있습니다. 수정 전에 사용자 규칙이나 정책이 해당 이름에 의존하는지 확인하고 이전 이름과 새 이름의 대응 관계를 기록하세요. 이름을 통일하려고 모든 항목을 한꺼번에 바꾼 뒤 구독까지 업데이트하지 마세요. 이름 정리와 원격 동기화를 별도로 진행하면 어느 단계가 연결이나 선택에 영향을 줬는지 명확해집니다.

한 번에 전부 정리하기보다 작은 범위로 나누어 관리하세요

구독별로 하나씩 정리하는 것이 좋습니다. 먼저 구독 경로가 유효한지 확인하고 목록의 출처를 살펴본 뒤 서버 하나를 테스트하고 명백한 임시 중복 항목을 정리하세요. 한 그룹을 마친 다음 다음 그룹으로 넘어가세요. 모든 내용을 한꺼번에 접고, 이름을 바꾸고, 정렬하고, 삭제하지 마세요. 매번 소수의 항목만 변경하면 결과가 예상과 달라도 이전의 정상 상태로 돌아가기 쉬우며 목록 전체를 다시 구성할 필요가 없습니다.

테스트 및 정렬 결과는 정리할 때 참고할 사항이지, 삭제 여부를 바로 결정하는 기준은 아닙니다. 현재 네트워크에서 시간 초과된 서버도 다른 네트워크에서는 다르게 작동할 수 있고, 일시적으로 지연 시간이 높다고 매개변수가 무효인 것은 아닙니다. ‘현재 사용할 수 없음’, ‘매개변수 만료’, ‘더 이상 필요 없음’을 구분해 기록한 뒤 보존, 수정, 삭제 여부를 결정하세요. 일시적인 네트워크 문제로 정보가 사라지지 않도록 주의해야 합니다.

여러 기기에서 사용할 경우 각 기기의 동기화 방식과 관리 책임을 분명히 하세요. 두 기기에 같은 구독이 저장되어 있어도 수동 메모, 정렬 순서, 선택 상태가 자동으로 일치하는 것은 아닙니다. 동기화 방식을 확인하기 전에 한 곳에서의 변경이 모든 기기에 적용된다고 가정하지 마세요. 다른 iPhone 또는 iPad로 옮긴 뒤에도 서버, Config, 시스템 연결 권한을 따로 확인해야 합니다.

08 / BACKUP & REMOVE

삭제, 이전, 백업의 안전한 순서

삭제 전에 대상, 영향 범위, 복구 자료를 확인하세요. 단일 서버, 구독 항목, Config 파일, 시스템 VPN 구성은 서로 다른 항목이므로 하나를 삭제해도 나머지가 정리되는 것은 아닙니다. 연결을 중지하려는 목적이라면 먼저 연결을 끄고 On Demand 조건을 확인하세요. 목록을 정리하려는 목적이라면 해당 기록을 정리하면 됩니다. 일반적인 연결 해제 대신 모든 자료를 삭제하지 마세요.

필요한 자료를 먼저 백업한 다음 삭제하세요

백업에는 유효한 구독 주소, 수동으로 추가한 서버 매개변수, 실제 사용하는 Config, 각 항목의 출처를 파악하는 데 필요한 설명이 포함되어야 합니다. 구독 주소로 원격의 현재 내용을 다시 가져올 수는 있지만 과거의 서버 목록까지 복원된다는 보장은 없습니다. Config 파일에도 수동으로 추가한 서버가 모두 포함되어 있지 않을 수 있습니다. 복구할 항목을 정한 뒤 각각을 다시 구성하는 데 필요한 자료가 있는지 확인하세요. 목록 스크린샷 한 장만 저장해서는 안 됩니다.

현재 앱에 내보내기, 공유, 백업 메뉴가 있다면 어떤 내용이 포함되는지 확인하고 인증 정보와 사용자 설정이 들어가는지도 살펴보세요. 메뉴에 따라 전체 상태가 아니라 기록 하나만 내보낼 수 있습니다. 원본 기록을 삭제하기 전에 신뢰할 수 있는 위치에서 내보낸 파일을 열어 내용과 누락 여부를 확인하세요. 확인 없이 파일이 만들어졌다는 이유만으로 복구할 수 있다고 판단하지 마세요.

민감한 백업은 안전하게 보호하세요

백업에는 구독 토큰, 비밀번호, UUID, 개인 키가 포함될 수 있으므로 직접 관리하는 보호된 위치에 보관하세요. 기기 간 동기화를 사용하는 경우 동기화 계정, 접근 가능한 기기, 공유 범위를 확인하고 기본 공개 폴더에 저장하지 마세요. 백업 파일의 용도와 대상은 알아보기 쉽게 적되 파일명에 전체 인증 정보를 넣지 마세요. 임시로 내보내기를 마친 뒤에는 메시지 첨부 파일, 사진 앨범, 기타 경유 위치에 남은 사본도 정리하세요.

앱을 다시 받는 것과 사용 데이터를 복원하는 것은 별개의 작업입니다. 새 iPhone 또는 iPad에서 구입한 앱을 App Store에서 다시 받는 방법은 구입 항목 복원 안내를 참고하세요. 앱을 다시 설치해도 서버, 구독, 사용자 설정이 모두 복원된다는 보장은 없습니다. 시스템 백업을 막연히 믿지 말고 필요한 자료를 직접 다시 구성할 수 있는지 미리 확인한 뒤 별도의 점검 목록을 보관하세요.

작은 범위부터 차례로 정리하세요

서버를 삭제하기 전에 정상 작동을 확인한 다른 기록으로 전환하고 해당 이름을 참조하는 설정이 있는지 확인하세요. 구독을 삭제할 때는 확인 메시지를 읽고 연결된 항목이 어떻게 처리되는지 확인해야 합니다. 구체적인 연동 동작은 현재 앱의 안내를 기준으로 합니다. 구독에 속한 서버 하나만 삭제하면 다음 업데이트 때 다시 생성될 수 있습니다. 특정 출처를 장기간 사용하지 않으려면 매번 업데이트 후 서버를 지우기보다 구독 수준에서 관리 방법을 계획하세요.

Config를 삭제하기 전에 사용자 지정 내용을 내보내고 대체할 수 있는 설정이 있는지 확인하세요. 삭제 후 접속 동작이 달라지면 서버 비밀번호부터 바꾸지 말고 현재 Global Routing과 선택한 파일을 먼저 확인하세요. 시스템 VPN 구성을 정리하면 다음 연결 때 권한을 다시 요청할 수 있습니다. 이는 시스템 연결 구성을 다시 만드는 과정이지 구독을 다시 구매하거나 서버 인증 정보가 만료된 것이 아닙니다.

복구 후 가져오기, 선택, 확인 순서로 점검하세요

복구할 때는 먼저 구독 또는 수동 서버를 추가하고 목록과 출처를 확인하세요. 그런 다음 필요한 Config를 가져와 선택하고 마지막으로 Global Routing과 시스템 연결 권한을 확인합니다. 오래된 기록을 한꺼번에 복원하고 바로 중복 항목을 삭제하지 마세요. 먼저 전체 절차 하나가 정상적으로 작동하는지 확인하세요. 과거에 저장한 Config 사본이라면 참조된 서버 이름이 현재도 있는지 점검해야 합니다. 자료는 복원됐더라도 이미 사라진 항목을 가리킬 수 있습니다.

새 기기에서 확인을 마칠 때까지 기존 기기와 백업에 있는 유효한 자료를 보존하세요. 일상적인 접속, 업데이트 경로, 사용자 규칙이 모두 정상인지 확인한 뒤 더 이상 필요하지 않은 사본을 정리하면 됩니다. 백업의 구독 토큰이나 비밀번호가 재설정되었다면 서비스 제공업체에서 받은 최신 정보를 사용하세요. 이전 백업은 구조를 파악하는 데 참고할 수 있지만 유효한 인증 정보로 계속 사용할 수는 없습니다.