Shadowrocket
구독 및 서버 관리 가이드

01 / Subscribe

Subscribe 메뉴와 첫 가져오기

먼저 보유한 자료의 유형을 확인하세요

구독은 다시 요청할 수 있는 주소이며, 클라이언트가 접속하면 서버 정보 목록을 가져옵니다. 개별 서버 링크는 보통 하나의 연결 정보를 담고, Config는 트래픽이 규칙과 일치하는 방식을 정합니다. 모두 링크나 파일 형태일 수 있지만 관리 대상은 서로 다릅니다. 가져오기 전에 자료 설명을 읽고 서버 구독인지, 단일 공유 링크인지, 구성 파일인지 확인하세요. 브라우저에서 열리는 내용이라고 해서 반드시 Subscribe에 입력할 수 있는 것은 아닙니다. 로그인 페이지나 안내 페이지와 구독 응답은 서로 다른 데이터입니다.

구독 주소는 이용 중인 서비스 제공업체에서 확인하세요. 복사할 때는 물음표 뒤의 쿼리 매개변수를 포함해 한 줄 전체를 가져와야 합니다. 이 매개변수는 사용자 식별에 쓰일 수 있으므로 삭제하면 도메인이 맞더라도 빈 목록이나 오류 페이지가 표시될 수 있습니다. 메신저를 거쳐 복사했다면 끝부분이 잘리지 않았는지, 마침표가 붙지 않았는지, 줄바꿈이 실제 문자로 들어가지 않았는지 확인하세요. 실제 주소를 검색창이나 공개 게시판에 붙여 넣지 마세요. 문의할 때는 오류 유형과 일부를 가린 도메인만 공유하면 됩니다.

Add Server에서 Subscribe 선택

1. Home을 열고 추가 메뉴로 이동해 Add Server를 연 다음 Type에서 Subscribe를 선택합니다.
2. 전체 구독 주소를 URL에 입력하고, 출처를 알아보기 쉬운 메모를 설정한 뒤 저장합니다.
3. 첫 요청이 완료될 때까지 기다린 다음 Home으로 돌아가 해당 그룹을 확인하고 서버가 목록에 표시되는지 확인합니다.
4. 서버 하나를 선택한 뒤 빠른 시작 단계에 따라 Global Routing과 연결을 확인합니다.

구독 항목을 저장하는 것과 콘텐츠를 성공적으로 가져오는 것은 별개의 단계입니다. Home에 구독 이름이 보인다는 사실만으로는 로컬에 항목이 저장되었을 뿐, 원격 콘텐츠가 정상적으로 해석되었는지 알 수 없습니다. 처음 가져온 뒤에는 그룹이 펼쳐지는지, 서버 이름이 온전히 표시되는지, 항목 수가 자료 설명과 일치하는지 확인하세요. 목록이 비어 있으면 먼저 요청 메시지를 확인하고 주소를 점검하세요. 같은 이름의 구독을 바로 여러 개 만들면 어느 항목에 올바른 주소가 저장됐고 어느 항목이 실패한 것인지 나중에 구분하기 어렵습니다.

요청 실패, 콘텐츠 처리 실패, 연결 실패 구분하기

요청 실패는 구독 응답을 가져오지 못한 상태입니다. 현재 네트워크, 도메인 확인, 주소 유효성 또는 접근 권한이 원인일 수 있습니다. 콘텐츠 처리 실패는 응답을 받았지만 인식 가능한 서버 목록이 아닌 경우입니다. 연결 실패는 서버 정보를 가져온 다음 발생합니다. 문제를 확인할 때는 이 세 단계를 차례로 점검하고, 개별 서버의 시간 초과를 구독 해석 문제와 혼동하지 마세요. 응답이 웹페이지 안내문이라면 그 내용을 구성으로 가져오지 말고 계정 상태나 주소를 확인하세요. 공개적으로 문제를 설명할 때는 구독 주소 전체를 가려야 합니다.

처음 가져올 때는 구독 주소에 정상적으로 접속할 수 있는 네트워크를 이용하세요. 업데이트 요청이 이미 사용할 수 없는 서버를 거치게 되면 ‘연결을 복구하려면 먼저 업데이트해야 하지만, 업데이트하려면 먼저 연결해야 하는’ 상황에 빠질 수 있습니다. 이때는 사용할 수 없는 연결을 비활성화하고 로컬 네트워크가 정상인지 확인한 뒤 구독을 다시 요청하세요. 서비스 제공업체가 접속 조건을 안내했다면 해당 자료를 확인하면 됩니다. 설정을 한꺼번에 바꾸지 말고 실패 당시의 메시지를 기록해 두어야 환경 문제와 자료 문제를 구분할 수 있습니다.

02 / Add Server

Add Server 수동 입력 필드와 프로토콜 설정

Type을 선택한 다음 항목별로 입력하세요

수동 추가는 서버 매개변수를 모두 보유하고 있고 개별 항목으로 관리해야 할 때 사용합니다. Add Server를 연 뒤 먼저 Type을 선택하세요. 프로토콜 유형에 따라 표시되는 필드와 각 필드의 의미가 달라집니다. 비슷해 보이는 유형을 선택한 뒤 포트를 바꿔 가며 연결을 시도하지 마세요. Shadowsocks, VMess, VLESS, Trojan, HTTP, SOCKS5, WireGuard, Hysteria2는 인증 및 전송 방식이 서로 다릅니다. 주소와 포트가 같아도 서로 바꿔 쓸 수 있는 것은 아닙니다.

Address에는 보통 호스트 이름이나 주소만 입력하며 웹 경로는 붙이지 않습니다. Port에는 자료에 적힌 서버 포트를 입력하고, 호스트 이름에 콜론과 포트를 함께 넣지 마세요. 원본이 완전한 공유 링크라면 가져오기 기능을 우선 사용하세요. 직접 분해하면 쿼리 매개변수에 숨겨진 전송 설정을 놓칠 수 있습니다. 메모는 로컬에서 구분하기 위한 용도이며 연결 설정을 고쳐 주지 않습니다. 비밀번호나 사용자 식별 정보 대신 출처, 용도, 프로토콜을 조합해 이름을 정하세요.

인증, TLS, 전송 설정을 따로 확인

Shadowsocks에서는 암호화 방식과 비밀번호를 확인해야 합니다. VMess와 VLESS는 UUID를 사용자 식별 정보로 사용하는 경우가 많습니다. Trojan에는 비밀번호가 필요하며 TLS와 SNI는 자료에 따라 확인해야 합니다. HTTP와 SOCKS5의 사용자 이름 및 비밀번호 필요 여부는 서버 설정에 따라 다릅니다. 인터페이스에서 비워 둘 수 있다고 해서 임의로 생략하지 마세요. WireGuard의 키, 인터페이스 주소, 피어 정보는 별도의 구조이므로 구독 비밀번호를 개인 키 필드에 입력하면 안 됩니다. 생소한 매개변수는 프로토콜을 바꿔 가며 입력하지 말고 원본 자료를 다시 확인하세요.

TLS 스위치는 해당 암호화 세션을 설정할지 결정하고, SNI는 세션에서 사용할 서버 이름입니다. 연결 주소는 별도의 진입 도메인일 수도 있습니다. 자료에 두 항목이 각각 표시되어 있다면 해당 필드에 따로 입력하세요. 인증서 이름이 일치하지 않거나 핸드셰이크에 실패하면 SNI, 시스템 시간, 원본 자료를 먼저 확인하세요. 인증서 확인을 끄는 방법을 일반적인 해결책으로 사용하지 마세요. 한 번에 매개변수 하나만 바꾸고 결과를 기록해야 원래 올바른 설정까지 망가뜨리지 않습니다.

전송 유형과 Host, Path 등의 설정도 서로 맞는 조합으로 입력해야 합니다. 경로 앞의 슬래시, 끝부분 문자, 쿼리는 임의로 추가하거나 삭제하지 마세요. 입력기에서 생성된 전각 기호, 스마트 따옴표, 공백도 매개변수를 바꿀 수 있습니다. 저장 전에 필드를 원본 자료와 한 줄씩 대조하고, 특히 이미지에서 인식한 숫자, 문자, 하이픈을 확인하세요. 자료에 선택 항목이 없다면 해당 프로토콜의 기본값을 유지하고 다른 서버의 값을 가져와 채우지 마세요.

개별 항목으로 저장하고 수정 범위를 구분하세요

수동 항목과 구독에서 생성된 서버는 따로 관리해야 합니다. 구독에 포함된 서버를 직접 수정하면 다음 업데이트에서 원격 콘텐츠로 덮어써질 수 있습니다. 로컬 변경 사항을 계속 보존하려면 복사하거나 별도로 추가한 항목이 구독 관리에서 분리되었는지 확인하세요. 저장 후 먼저 테스트하고, 이어서 연결을 설정해 실제 요청을 확인합니다. 같은 매개변수가 네트워크에 따라 다르게 작동한다면 비밀번호 오류로 단정하지 말고 네트워크 조건을 각각 기록하세요.

문제 해결을 위해 보관할 정보는 프로토콜 유형, 일부를 가린 주소, 포트, 전송 유형, 오류 메시지면 충분합니다. 인증 값은 공개하지 마세요. Trojan의 필드 관계는 Trojan 비밀번호, SNI 및 TLS 설정 안내에서 확인할 수 있습니다. 서버 설정 관련 사항은 원본 자료와 하나씩 대조하세요. 클라이언트는 메모를 바꾼다고 누락된 필드를 자동으로 추론하지 않습니다.

03 / Import

QR 코드 및 클립보드 가져오기의 범위

Scan QR Code는 내용만 읽습니다

QR 코드는 텍스트를 담는 방식일 뿐, 그 안에 반드시 서버 정보가 들어 있다는 뜻은 아닙니다. Scan QR Code로 읽은 내용은 단일 서버 공유 링크, 구독 주소 또는 일반 웹페이지일 수 있습니다. 스캔한 뒤 클라이언트가 만들려는 항목을 확인하고 저장 여부를 결정하세요. 웹페이지가 열리기만 한다면 자료 안내를 다시 확인하고, 웹 주소를 임의의 프로토콜 필드에 입력하지 마세요. QR 코드에 완전한 인증 정보가 들어 있을 수도 있으므로 촬영, 전달, 사진 동기화는 정보가 저장되는 범위를 넓힐 수 있습니다.

Home의 추가 메뉴에서 Scan QR Code를 선택하고 시스템 안내에 따라 카메라 접근을 허용한 다음 QR 코드 전체가 화면에 들어오도록 하세요. 스캔할 때는 코드가 온전히 보이도록 하고 반사광, 심한 기울기, 화면 확대에 따른 흐림을 피하세요. 같은 기기에서 QR 코드를 표시하는 경우에는 스캔 메뉴에 사진 가져오기가 명시적으로 제공될 때만 이미지로 가져오세요. 해당 메뉴가 없다면 자료에 함께 제공된 텍스트 링크를 이용하세요. 인증 정보가 포함된 이미지를 외부 인식 페이지에 제출하지 마세요.

클립보드로 가져오기 전에 원본 텍스트를 정리하세요

공유 링크 전체를 복사한 뒤 Shadowrocket으로 돌아와 인터페이스의 클립보드 가져오기 메뉴를 사용하세요. 시스템에서 붙여넣기를 허용할지 묻는 경우 이번 작업에 필요한지 확인한 뒤 선택하면 됩니다. 복사한 내용에 제목, 설명, 여러 링크가 함께 있다면 클라이언트가 어떤 내용을 인식하는지 먼저 확인하세요. 일괄 가져오기에 실패하면 완전한 링크 하나만 복사해 테스트하여 형식 미지원인지 설명 문구가 섞인 문제인지 구분할 수 있습니다. 실제 복사 내용을 확인하는 대신 권한을 반복해서 허용하지 마세요.

1. 자신의 자료에서 링크 하나를 복사하고 프로토콜로 시작하는 부분과 끝의 메모가 모두 포함됐는지 확인합니다.
2. 클립보드 가져오기 메뉴를 열고 미리보기나 결과 메시지를 확인해 생성될 항목의 유형을 확인합니다.
3. 저장한 뒤 Home에서 새 항목을 찾아 프로토콜, 주소, 소속 그룹을 확인합니다.
4. 작업을 마친 뒤 임시로 옮겨 둔 내용을 삭제해 다음에 붙여넣을 때 인증 정보를 잘못 보내지 않도록 합니다.

메신저에서는 긴 링크가 접힌 텍스트로 표시될 수 있으므로 화면에 한 줄로 보인다고 전체 내용이 복사된 것은 아닙니다. 일부 편집기는 일반 따옴표를 스마트 따옴표로 바꾸거나 링크 중간에 줄바꿈을 넣기도 합니다. 이 경우 원본 텍스트로 돌아가 링크 복사 또는 원문 복사 기능을 사용하세요. 텍스트를 다른 곳으로 옮겨야 한다면 순수 텍스트를 유지할 수 있는 로컬 도구를 이용하고 자동 공개 공유 기능은 끄세요. 자신의 자료만 다루고 다른 사람의 인증 정보는 저장하지 마세요.

인식된 뒤에도 필드를 확인하세요

가져오기에 성공했다는 것은 파서가 인식 가능한 구조를 찾았다는 뜻이지, 모든 필드가 서버 요구 사항에 맞다는 뜻은 아닙니다. 저장 후에는 최소한 Type, 주소, 포트, TLS 또는 전송 관련 설정을 확인하세요. 메모에 적힌 용도와 실제 필드가 일치하는지도 살펴보세요. 이미지 자르기, 문자 인식, 여러 차례 전달을 거친 QR 코드는 원본 매개변수와 더욱 꼼꼼히 대조해야 합니다. 스캔 결과와 텍스트 링크로 만든 항목이 다르면 연결을 시도하지 말고 두 자료가 실제로 같은 대상을 가리키는지 먼저 확인하세요.

QR 코드를 반복해서 스캔하거나 링크를 여러 번 붙여 넣으면 별도 항목이 여러 개 생기거나 기존 항목이 업데이트될 수 있습니다. 동작은 메뉴와 내용에 따라 다릅니다. 이름만 보고 덮어쓰기가 완료됐다고 판단하지 말고 목록에서 출처, 그룹, 항목 세부 정보를 확인하세요. 일괄 가져오기 전에는 기존 그룹을 기록해 두고, 가져온 뒤 새 항목을 먼저 확인한 다음 실패한 중간 항목을 삭제하세요. 이미 정상적으로 사용하는 항목이 있다면 새 항목이 실제로 검증될 때까지 남겨 두어 비교 기준을 잃지 않도록 하세요.

카메라 권한 실패, 붙여넣기 권한 거부, 콘텐츠 해석 실패는 서로 다른 문제입니다. 앞의 두 문제는 시스템 권한에서 처리하고, 콘텐츠 해석 실패는 링크 유형, 인코딩, 내용의 완전성을 확인해야 합니다. 권한을 더 허용해도 잘못된 형식이 유효한 서버 정보로 바뀌지는 않습니다. 스캔 메뉴는 정상인데 코드를 계속 읽지 못한다면 화면 반사를 줄이거나 원본 QR 코드를 확대하거나 텍스트 자료를 이용하세요. QR 코드에서 빠진 인증 문자를 임의로 추측해 채우지 말고 자신의 완전한 자료를 다시 받으세요.

04 / URI

공유 링크 형식과 Config의 차이

링크 길이가 아니라 구조를 보고 구분하세요

공유 링크는 보통 프로토콜 접두사, 인증 정보, 대상 주소, 포트, 쿼리 매개변수, 메모로 구성됩니다. 프로토콜마다 포장 방식이 다릅니다. 어떤 필드는 바로 읽을 수 있고, 어떤 필드는 인코딩되어 있으며, 여러 매개변수가 하나로 묶여 인코딩될 수도 있습니다. 한 프로토콜 링크의 사용자 이름 위치를 다른 프로토콜에 그대로 적용하지 말고, 내용이 알아보기 어렵다고 인코딩된 부분을 임의로 삭제하지 마세요. 먼저 프로토콜 접두사를 확인하고 해당 가져오기 메뉴로 처리하세요. 구조를 직접 분석하는 것은 자료를 대조할 때만 활용합니다.

구독 URL은 보통 HTTP 또는 HTTPS를 사용하며 요청 시 서버가 목록을 반환합니다. URL이 웹 링크처럼 보인다고 해서 구성 파일인 것은 아닙니다. 응답 유형과 자료의 용도로 판단해야 합니다. 구독 주소를 일반 HTTP 프록시로 추가하면 서버 목록을 내려받을 위치가 아니라 연결 대상 정보를 지정하게 되어 잘못된 항목이 만들어집니다. 마찬가지로 Config 파일을 Subscribe에 넣어도 그 안의 규칙이 서버로 자동 변환되지는 않습니다.

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

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

위 예시는 구조만 보여 줍니다. 도메인, 비밀번호, 구독 매개변수는 모두 교육용 가짜 값이며 연결에 사용할 수 없습니다. 첫 번째 예시는 목록을 가져오는 주소를, 두 번째 예시는 단일 Trojan 공유 링크의 구성 방식을 나타냅니다. 실제 자료에는 추가 매개변수가 있을 수 있으므로 예시와 같게 만들려고 내용을 삭제하거나 수정하지 마세요. 링크의 샵 기호 뒤에는 보통 메모가 오고 물음표 뒤에는 매개변수가 오지만, 지원 범위는 해당 프로토콜과 클라이언트의 해석 결과를 기준으로 합니다.

인코딩은 암호화가 아니며 메모는 인증 정보가 아닙니다

퍼센트 인코딩은 일부 특수 문자를 표현하는 데 사용하며, 공유 형식에 따라 Base64 인코딩을 쓰기도 합니다. 인코딩된 텍스트에서도 비밀번호와 서버 정보를 복원할 수 있으므로 익명화한 자료처럼 공개하면 안 됩니다. 비밀번호에 특수 기호가 있으면 올바른 내보내기 또는 인코딩 절차가 필요합니다. 구분 문자가 포함된 비밀번호를 링크에 바로 이어 붙이면 해석 경계가 달라질 수 있습니다. 가져온 뒤 필드가 어긋난다면 이스케이프 문자를 계속 추가하지 말고 원본 공유 링크로 다시 가져오세요.

메모와 서버 식별 정보도 서로 구분해야 합니다. 링크 두 개가 같은 메모를 사용해도 주소나 인증 정보가 다를 수 있고, 같은 서버가 메모만 달리해 목록에 여러 번 표시될 수도 있습니다. 비교할 때는 샵 기호 뒤의 이름만 보지 말고 실제 필드를 확인하세요. 형식 문제를 다른 사람에게 설명해야 한다면 가짜 도메인과 가짜 비밀번호로 구조 예시를 새로 만드세요. 메모를 ‘테스트’로 바꾼다고 민감한 정보가 삭제되는 것은 아닙니다.

Config는 규칙을 관리하며 서버 정보를 대신하지 않습니다

Config는 요청이 어떤 순서로 정책과 일치할지 결정합니다. Global Routing에서 Config 방식은 규칙을 사용하고, Proxy와 Direct는 전체 요청을 처리하는 서로 다른 방식입니다. 서버를 정상적으로 가져왔는데도 예상한 경로로 접근되지 않으면 현재 방식과 적용 중인 구성을 확인하세요. 같은 서버를 다시 가져오지는 마세요. 아래 규칙 조각은 순서를 이해하기 위한 예시입니다. 지정 도메인을 먼저 확인하고, 다음으로 지역 규칙을 적용한 뒤, 어느 규칙에도 해당하지 않는 요청은 FINAL이 처리합니다.

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

이 내용은 구독도 아니고 단독으로 연결을 설정할 수 있는 서버 자료도 아닙니다. PROXY는 해당 프록시 정책을 뜻하며 실제 사용 가능 여부는 선택한 서버와 구성에 따라 달라집니다. DIRECT는 해당 요청이 직접 연결된다는 뜻입니다. 규칙은 순서대로 확인되며 앞선 규칙에 일치하면 보통 뒤에서 더 적합한 결과를 계속 찾지 않습니다. 따라서 서버와 규칙은 따로 백업하고 따로 테스트하세요. 한 번에 한 종류만 바꿔야 문제가 연결 대상에서 생겼는지 트래픽 선택에서 생겼는지 확인할 수 있습니다.

DOMAIN-SUFFIX, GEOIP, FINAL 또는 다른 인터페이스 용어는 용어집을 참고하세요. 링크 오류가 발생하면 먼저 항목 유형을 확인하고, 다음으로 구조와 필드를 점검하세요. 형식 오류를 해결하려고 관계없는 규칙을 바꾸지 말고, 가져온 항목 이름이 정상적으로 표시된다는 이유만으로 인증 정보도 올바르다고 판단하지 마세요.

05 / Update

구독 업데이트 방법과 실패 시 대처

업데이트는 지연 시간 수치가 아니라 출처 콘텐츠를 새로 가져오는 작업입니다

구독을 업데이트하면 출처에 다시 요청을 보내고, 반환된 내용에 따라 해당 구독이 관리하는 서버를 갱신합니다. 주소, 포트, 인증 정보, 전송 설정, 이름이 바뀔 수 있습니다. 목록의 지연 시간을 다시 테스트하는 것과는 다른 작업입니다. 테스트는 현재 저장된 항목만 확인하므로 원격에서 변경된 새 매개변수를 가져오지 못합니다. 여러 서버가 한꺼번에 작동하지 않으면 오래된 항목만 반복 테스트하지 말고 먼저 자료 업데이트가 필요한지, 그다음 네트워크 문제인지 확인하세요.

업데이트 절차를 정할 때는 먼저 결과를 확인할 수 있는 상태에서 수동으로 한 번 진행하세요. 업데이트 전에는 어떤 구독과 서버를 사용 중인지, 로컬 변경 사항이 있는지 확인합니다. 업데이트 후에는 출처 그룹, 현재 선택된 항목, 실제 연결을 점검하세요. 인터페이스에 자동 업데이트 옵션이 있다면 관리 방식에 맞게 설정하되, 모든 플랫폼이 같은 시간에 백그라운드 업데이트를 한다고 가정하지 마세요. 시스템 백그라운드 제한, 네트워크 상태, 클라이언트 실행 여부가 실제 요청 시점에 영향을 줄 수 있습니다.

사용 패턴에 맞춰 업데이트 주기를 정하세요

적절한 업데이트 주기는 자료의 변경 빈도와 사용 환경에 따라 정해야 하며, 잦을수록 좋은 것은 아닙니다. 오랫동안 안정적인 출처라면 사용 전에 확인하거나 변경 알림을 받은 뒤 점검하면 됩니다. 이동 중이거나 네트워크를 바꾸거나 기기를 옮길 때는 미리 업데이트하고 확인하세요. 짧은 시간에 반복 요청해도 잘못된 주소가 고쳐지지 않으며 출처 측 요청 제한에 걸릴 수 있습니다. 인터페이스에서 백그라운드 동작을 명확히 보여 주지 않는다면 확인되지 않은 자동 갱신을 기대하기보다 수동으로 확인하고 결과를 검증하는 편이 안전합니다.

1. 업데이트 전에 사용 중인 출처와 항목을 기록하고, 필요한 경우 로컬에서 독립 관리하는 구성을 백업합니다.
2. 구독 하나만 업데이트하면서 요청 메시지와 그룹 변화를 확인하고, 규칙은 동시에 변경하지 않습니다.
3. 기존에 선택한 항목이 남아 있는지 확인하고 새 매개변수를 살펴본 뒤 테스트합니다.
4. 연결을 다시 설정해 실제 요청을 확인합니다. 정상적으로 작동하면 다음 출처를 처리합니다.

구독에서 생성된 항목을 직접 수정하면 이후 업데이트에서 덮어써질 수 있습니다. 이름, 정렬 순서, 그룹이 유지되는지도 실제 결과를 확인하세요. 오래 보존해야 하는 변경 사항은 별도로 관리하는 항목에 기록하고, 업데이트할 때마다 로컬 필드가 유지되리라 기대하지 마세요. 출처에서 서버를 삭제했더라도 로컬 캐시에 표시된다는 이유만으로 계속 유효한 것은 아닙니다. 익숙한 이름을 남기려고 인증 정보나 연결 대상이 바뀐 사실을 무시하지 마세요.

문제를 네 단계로 나눠 확인하세요

첫 번째로 로컬 네트워크에서 요청을 정상적으로 보낼 수 있는지 확인합니다. 두 번째로 구독 도메인을 확인하고 연결할 수 있는지 점검합니다. 세 번째로 출처가 유효한 내용을 반환하는지 살펴봅니다. 네 번째로 현재 가져오기 메뉴가 그 내용을 해석할 수 있는지 확인합니다. 각 단계에서 필요한 증거는 다릅니다. 연결 오류와 인증 정보가 잘못됐다는 안내를 혼동하지 마세요. 권한 관련 메시지가 표시되면 자신의 구독 주소와 계정 상태를 다시 확인하세요. 일반 웹페이지가 반환되면 서버 구독 주소가 아니라 관리 페이지를 잘못 복사한 것은 아닌지 살펴보세요.

업데이트 뒤 목록이 갑자기 비어도 먼저 삭제하지 마세요. 그룹이 접혀 있는지, 필터가 내용을 숨겼는지 확인한 다음 업데이트가 완료됐는지, 출처가 실제로 빈 결과를 반환했는지 살펴보세요. 표시 문제라면 다시 가져올 경우 중복 항목이 생깁니다. 출처의 내용 자체가 바뀐 경우에는 이전 캐시를 복구해도 다시 사용할 수 있다는 보장이 없습니다. 업데이트 전 필요한 기록을 남겨 두면 비교에 도움이 됩니다. 원본 응답에는 모든 서버의 비밀번호와 접근 토큰이 포함될 수 있으므로 공개 채널에 올리지 마세요.

업데이트는 성공했지만 연결되지 않는다면 서버와 네트워크 단계에서 문제를 확인하세요. 업데이트된 항목 하나를 선택해 프로토콜 매개변수를 확인한 다음 같은 출처의 다른 항목도 테스트합니다. 한 항목만 영향을 받았다면 구독 전체를 다시 만들 필요는 없습니다. 모든 출처가 동시에 실패한다면 현재 네트워크와 시스템 시간도 확인하세요. 서버 시간 초과 및 연결 실패 문제 해결을 참고해 정해진 순서로 정보를 수집하면 여러 화면에서 설정을 반복 초기화하는 일을 줄일 수 있습니다.

06 / Organization

여러 구독의 그룹·이름·중복 항목 정리

출처별로 그룹을 나누고 용도에 맞게 이름을 정하세요

여러 구독을 관리한다면 모든 항목을 긴 목록 하나에 섞기보다 먼저 출처별 경계를 유지하세요. 출처마다 안정적이고 이해하기 쉬운 로컬 이름을 지정하고, 수동으로 입력한 항목도 따로 표시해야 합니다. 그래야 업데이트 실패, 매개변수 변경, 삭제 시 영향을 받는 범위를 명확히 알 수 있습니다. 이름에는 용도와 관리 방식을 적을 수 있지만 전체 구독 주소, 계정 식별 정보, 비밀번호는 넣지 마세요. 목록 스크린샷에 담기면 일반적인 문제 해결 자료와 함께 외부로 유출될 수 있습니다.

그룹 이름에는 비교적 오래 유지되는 정보를 사용하세요. 순간적인 지연 시간을 이름에 넣으면 네트워크가 바뀔 때 정보가 오래되고, 현재 순번을 적어도 업데이트 후 혼란이 생깁니다. 짧은 출처 코드, 용도, 프로토콜을 사용해 구분하면서 원본 자료와의 대응 관계를 유지하는 편이 낫습니다. 클라이언트에서 일부 표시 정보만 변경할 수 있다면 그 범위를 따르세요. 화면을 통일하려고 서버 인증 필드를 변경하지 마세요.

중복 여부를 확인한 뒤 보관할 항목을 결정하세요

이름이 같다고 중복은 아니며 주소가 같다고 반드시 중복인 것도 아닙니다. 같은 대상이라도 포트, 프로토콜, 인증 정보, 전송 방식, SNI가 다를 수 있습니다. 같은 출처에서도 서로 다른 네트워크 환경에 적합한 진입점을 제공할 수 있습니다. 정리할 때는 주요 필드와 출처 관계를 비교한 뒤 삭제 여부를 결정하세요. 메모만 다른 두 항목이라도 하나는 구독에서 관리하고 다른 하나는 독립 복사본일 수 있습니다. 구독 항목과 독립 항목은 삭제 후 관리 결과가 다르므로 먼저 확인해야 합니다.

일괄 정리는 두 차례로 나눠 진행하세요. 첫 번째에는 중복이 의심되는 항목을 기록하고 표시만 하며 바로 삭제하지 않습니다. 두 번째에는 각 항목의 현재 연결 상태, 대체 항목, 백업 여부를 확인한 뒤 삭제합니다. 구독에서 가져온 서버는 다음에 원격 콘텐츠를 받으면 다시 생성될 수 있으므로 로컬에서 반복 삭제해도 계속 남을 수 있습니다. 인터페이스에 필터나 표시 정리 기능이 있다면 실제 데이터를 바꾸는지 화면 표시만 바꾸는지 먼저 확인하세요.

구독 관리와 규칙 정책을 분리하세요

출처 그룹은 서버를 어디에서 가져왔는지 나타내고, 규칙 정책은 요청을 어떻게 처리할지 결정합니다. 두 항목이 반드시 일대일로 연결되는 것은 아닙니다. 구독 두 개를 서로 다른 목록 그룹에 두어도 각기 다른 도메인 트래픽이 자동 할당되지는 않습니다. 규칙을 적용하려면 Config와 해당 정책 설정에서 구성을 확인하세요. 그룹 이름만 보고 라우팅 방식을 추측하지 마세요. 서버 정보를 먼저 올바르게 정리한 다음 규칙을 조정하면 ‘목록을 정리한 뒤 접속 방식이 바뀌는’ 문제를 줄일 수 있습니다.

출처를 업데이트한 뒤 사용 중인 항목이 예상한 그룹에 속해 있는지 다시 확인하세요. 원격에서 같은 이름을 재사용했다면 세부 정보를 확인한 뒤 전환해야 합니다. 익숙한 이름을 안정적인 식별자로 간주하지 마세요. 잠시 남겨 둘 이전 항목에는 용도와 확인할 내용을 기록할 수 있지만, 오래된 복사본을 현재 출처 항목과 계속 섞어 두지 마세요. 관리 기록에는 왜 보관하는지, 어떤 조건에서 다시 확인할지 적으세요. 의미가 불분명한 별표 하나만 표시해 두는 것으로는 부족합니다.

구독이 여러 개라고 모든 항목을 동시에 테스트할 필요는 없습니다. 각 출처에서 대표 항목 몇 개를 먼저 확인해 가져오기와 업데이트 관계가 정상인지 점검한 다음 용도에 따라 나머지를 살펴보세요. 출처가 많아질수록 작업 이력을 추적할 수 있어야 합니다. 어떤 구독을 방금 업데이트했는지, 어떤 항목을 수정했는지, 어느 그룹을 삭제할 예정인지 기록하세요. 한 번에 한 그룹씩 처리하고 확인한 뒤 다음으로 넘어가면 일괄 작업 중 실수로 대량 삭제하는 일을 방지하고 문제가 생겼을 때 이전에 검증된 상태로 돌아가기 쉽습니다.

구독 그룹과 정리 절차는 여러 구독 관리 안내에서 확인할 수 있습니다. 정리의 목표는 목록을 최대한 짧게 만드는 것이 아니라 구분 비용과 관리상 혼란을 줄이는 것입니다. 용도가 불분명한 항목은 바로 지우고 다시 가져오기보다 먼저 기록하고 확인해야 맥락을 더 잘 보존할 수 있습니다.

07 / Connectivity Test

지연 시간 테스트, 정렬, 실제 연결 확인

테스트 결과는 해당 테스트가 확인하는 내용만 보여 줍니다

지연 시간 테스트 결과는 당시 네트워크와 테스트 방식이 함께 만들어 낸 값이며 서버의 영구적인 성능을 나타내지 않습니다. TCP 연결 설정, 프록시를 통한 요청, 실제 서비스 접속 테스트는 확인하는 단계가 다르므로 수치를 서로 직접 비교할 수 없습니다. 시작하기 전에 클라이언트의 현재 테스트 설정을 확인하고 같은 네트워크에서 비슷한 시간대에 같은 방식으로 항목을 비교하세요. 목록에 작은 숫자가 표시되더라도 인증, TLS, 도메인 확인, 대상 웹사이트 접속이 모두 성공했다는 뜻은 아닙니다.

Connectivity Test를 실행하기 전에 구독 자료가 확인된 상태인지 먼저 살펴보세요. 만료된 매개변수를 테스트해도 현재 출처의 사용 가능 여부를 판단할 수 없습니다. 업데이트에 실패했다고 이전 목록의 시간 초과를 새 자료가 잘못됐다는 증거로 삼지 마세요. 먼저 항목 하나만 테스트한 뒤 전체 그룹을 테스트할지 결정하면 대량 요청으로 인한 대기와 결과 혼선을 줄일 수 있습니다. 테스트하는 동안 대용량 파일 전송 등 네트워크를 크게 사용하는 작업은 잠시 멈춰 항목마다 비슷한 측정 조건을 유지하세요.

테스트 범위로 문제 발생 단계를 파악하세요

서버 하나만 시간 초과되면 해당 항목의 주소, 포트, 프로토콜 매개변수를 확인하세요. 같은 출처의 여러 항목이 실패하면 자료 업데이트 여부와 출처 변경 여부를 살펴봅니다. 서로 다른 출처의 항목이 모두 실패한다면 먼저 로컬 네트워크, 시스템 시간, 현재 연결 상태를 확인하세요. 네트워크를 바꾼 뒤 복구된다면 두 환경의 차이를 기록하고 인증 정보를 모두 다시 작성하지 마세요. 단일 지연 시간 수치보다 장애 범위가 더 유용합니다. 다음 단계에서 클라이언트 필드, 원격 자료, 로컬 환경 중 무엇을 확인할지 결정하는 데 도움이 됩니다.

정렬은 항목을 찾는 시간을 줄이는 데 유용하지만 선택 기준을 대신할 수는 없습니다. 테스트 후 현재 측정 결과에 따라 같은 유형의 항목을 정렬하고 앞쪽 후보부터 확인할 수 있습니다. 아직 테스트하지 않은 항목, 실패한 항목, 수치가 있는 항목은 서로 구분해 해석해야 합니다. 프로토콜, 테스트 방법, 시간이 다르면 결과를 한데 섞어 특정 항목이 언제나 더 낫다고 결론 내리지 마세요. 안정적으로 기록하려면 맥락 없는 숫자 스크린샷만 남기지 말고 네트워크 조건과 테스트 방식도 적으세요.

테스트를 통과한 뒤에도 라우팅과 실제 요청을 확인하세요

서버를 선택해 연결한 다음 현재 Global Routing 방식이 무엇인지 확인하세요. Config 방식은 규칙에 따라 요청을 처리하고, Proxy 방식은 프록시 경로를 확인하는 데 적합하며, Direct 방식은 서버 프록시가 작동한다는 증거로 사용할 수 없습니다. Config에서 특정 대상의 규칙이 DIRECT로 지정됐다면 해당 사이트가 열린다고 해서 서버가 정상 작동한다고 볼 수 없습니다. 평소 필요한 요청을 이용해 연결 기록에서 실제로 적용된 경로를 확인하세요. 화면 상단의 스위치만 보지 마세요.

실제 요청이 실패하면 연결 기록의 오류 유형과 적용된 정책을 확인한 뒤 다음 단계로 넘어가세요. 도메인 확인 오류, TLS 핸드셰이크 실패, 인증 실패, 대상의 접근 거부는 해결 방법이 서로 다릅니다. 브라우저가 로딩 중이라는 이유만으로 서버 시간 초과라고 단정하지 말고, 특정 대상 하나가 실패했다고 구독 전체를 삭제하지도 마세요. 먼저 정상적으로 사용하는 다른 요청과 비교한 다음 특정 도메인, 프로토콜, 네트워크에만 영향을 주는지 살펴보며 범위를 좁히세요.

간헐적인 문제는 테스트 버튼을 계속 누르는 것보다 비교 가능한 기록을 몇 건 남기는 편이 효과적입니다. 네트워크, 서버, Global Routing 방식처럼 한 번에 한 요소만 바꾸고 결과를 확인하세요. DNS, 규칙, 인증 정보를 한꺼번에 수정하면 무엇이 문제를 해결했는지 알 수 없습니다. 테스트 화면의 시간 초과가 서버가 영구적으로 제거됐다는 뜻은 아니므로 삭제 전에 업데이트 상태와 다른 네트워크에서의 결과를 확인하세요. 오랫동안 사용하지 않은 의심 항목은 바로 지우지 말고 확인 대기 목록으로 옮겨 정리 일정을 잡으세요.

오류별 자세한 확인 절차는 서버 시간 초과, 프로토콜 매개변수 및 시스템 시간 문제 해결을 참고하세요. 연결을 확인한 다음 필요한 On Demand 조건을 설정합니다. 자동 연결은 연결 시점만 바꾸며 잘못된 매개변수를 고쳐 주지 않습니다. 수동으로 전체 연결을 한 번 확인하는 절차도 대신할 수 없습니다.

08 / Backup

삭제, 백업, 기기 교체 후 복원 순서

삭제 전에 대상과 영향을 받는 범위를 확인하세요

개별 서버, 전체 구독, Config는 서로 다른 항목입니다. 독립 서버를 삭제하면 보통 해당 로컬 항목만 영향을 받습니다. 구독 메뉴를 삭제하면 구독이 관리하는 서버에도 영향을 줄 수 있고, Config를 삭제하면 규칙 및 정책 설정이 사라집니다. 작업 전에 확인 메시지를 읽고 현재 연결이 삭제할 항목에 의존하는지 살펴보세요. 서버 하나의 실패를 해결하려고 구독을 삭제하거나 목록 표시 문제를 해결하려고 구성을 먼저 비우지 마세요. 이렇게 하면 국소적인 문제를 확인할 기준을 잃을 수 있습니다.

구독 안의 서버를 삭제해도 다음 업데이트 후 다시 나타날 수 있습니다. 출처에 해당 서버가 계속 포함되어 있기 때문입니다. 반드시 삭제 실패라는 뜻은 아니며, 로컬 항목이 출처에 따라 다시 생성된 것일 수 있습니다. 출처 전체를 더 이상 사용하지 않으려면 백업과 대체 연결을 먼저 확인한 뒤 해당 메뉴를 삭제하세요. 일부 항목만 잠시 숨기고 싶다면 인터페이스에서 표시 방식만 정리할 수 있는지 확인하세요. 삭제 전에 관리 관계를 기록해 두는 편이 삭제 후 이름만 보고 원래 어느 그룹에 속했는지 추측하는 것보다 안전합니다.

복원할 항목에 맞춰 백업을 준비하세요

백업을 준비할 때는 적어도 세 가지를 확인해야 합니다. 구독을 다시 가져올 수 있는지, 독립 서버를 복원할 수 있는지, 규칙을 복원할 수 있는지입니다. 구독 주소만 저장하면 수동 서버 항목과 로컬 Config를 복원하지 못할 수 있습니다. 규칙 파일만 내보내도 서버 인증 정보가 포함되지 않을 수 있습니다. 내보내기 기능을 사용할 때는 실제로 어떤 항목이 포함되는지 확인하세요. 파일이 생성됐다는 사실만으로 모든 자료가 저장된 것은 아닙니다. 백업 파일에는 민감한 정보가 들어갈 수 있으므로 본인이 관리하는 보호된 위치에 보관하고 공개적으로 공유하거나 함부로 전달하지 마세요.

1. 사용 중인 구독 출처와 필요한 관리 메모를 기록하고, 전체 인증 정보는 보호된 위치에 보관합니다.
2. 독립 서버와 Config를 백업하고 내보낸 항목의 범위와 파일을 정상적으로 읽을 수 있는지 확인합니다.
3. 현재 Global Routing 방식과 다시 확인해야 할 On Demand 조건을 기록합니다.
4. 기존 기기를 계속 사용할 수 있을 때 복원 절차를 검증하고, 성공한 뒤에 이전 자료를 정리합니다.

iCloud 동기화를 사용하는 경우 기기, 계정, 실제 동기화 대상이 조건을 충족하는지 먼저 확인하세요. 모든 로컬 자료가 자동으로 동기화된다고 가정하지 마세요. 동기화는 기기 간 상태 전달을 위한 기능이고 백업은 되돌릴 수 있는 사본을 보관하는 기능이므로 목적이 다릅니다. 실수로 삭제한 내용이 동기화로 다른 기기에도 반영될 수 있습니다. 따라서 대량 정리, 그룹 재구성, 기기 교체 전에 별도의 독립 백업을 보관하고 포함된 항목을 기록해 두세요. 복원할 때 잘못된 파일을 선택하는 일을 방지할 수 있습니다.

자료를 복원한 뒤 규칙과 자동 연결을 확인하세요

새 기기에서는 먼저 클라이언트를 설치한 다음 구독 하나 또는 독립 서버 몇 개를 복원해 기본 연결을 확인하세요. 그 후 Config를 복원하고 마지막으로 On Demand를 확인합니다. 모든 자료를 한꺼번에 가져와 바로 자동 연결을 켜면 잘못된 규칙, 만료된 인증 정보, 시스템 트리거 조건이 한꺼번에 얽힐 수 있습니다. VPN 관련 시스템 권한은 새 기기의 안내에 따라 설정해야 합니다. 이전 기기에서 연결이 정상이라고 해서 권한 상태도 그대로 이전되는 것은 아닙니다. 기기를 옮기는 동안 이전 기기를 남겨 두면 항목별로 비교할 수 있습니다.

복원한 구독은 다시 업데이트하고, 독립 항목은 매개변수를 다시 확인하며, 규칙은 참조하는 정책이 여전히 존재하는지 검증하세요. 이름이 같아도 같은 항목이라는 보장은 없습니다. 이전한 Config가 이미 사라진 그룹을 참조한다면 실제 요청을 테스트하기 전에 관계를 바로잡으세요. 백업이 성공했는지는 파일 수가 아니라 정해진 순서에 따라 사용 가능한 상태를 재구성할 수 있는지로 판단해야 합니다. 실제 복원 결과를 한 번 기록해 두면 다음 기기 교체 때 같은 과정을 다시 찾아볼 필요가 줄어듭니다.

클라이언트를 설치할 때 iPhone / iPad 버전은 App Store에서 $2.99에 한 번 구매하며, Mac(Apple 칩 및 Intel), Windows, Android, Linux 버전은 무료입니다. 설치와 시스템 허용 방법은 다운로드 페이지 안내를 따르세요. 다른 플랫폼의 설치 파일은 사이트의 /dl/shadowrocket/ 경로에서 제공합니다. iPhone / iPad의 구매 항목 복원 및 시스템 요구 사항은 다운로드 페이지의 해당 항목을 참고하고, 계정의 구매 기록과 구독 인증 정보는 따로 관리하세요.

새 기기에서 검증을 마친 뒤 기기 관리 절차에 따라 이전 기기의 구독, 서버, 내보낸 파일, QR 코드 이미지, 클립보드 임시 항목을 정리하세요. 인증 정보가 노출된 적이 있다면 자료를 관리하는 제공업체의 안내에 따라 변경해야 합니다. 로컬 파일만 삭제해도 이미 노출된 주소나 키가 무효화되지는 않습니다. 자세한 기기 이전 점검은 구성 백업 및 기기 이전 안내를 참고하고, 일반적인 사용 절차는 사용법 안내로 돌아가 연결 과정을 다시 확인하세요.