Shadowrocket 구독 및 서버 관리 가이드

먼저 구독, 서버 및 Config를 구분하기

세 가지 관리 대상은 서로 다른 문제를 해결합니다

작업을 시작하기 전에 Shadowrocket에서 자주 함께 등장하는 세 가지 대상을 구분해 이해해야 합니다. 서버 항목은 직접 연결을 설정하는 매개변수 묶음으로, 보통 프로토콜 유형, 서버 주소, 포트, 인증 정보 및 전송 옵션을 포함합니다. 구독은 업데이트 주소이며, 클라이언트가 읽으면 여러 서버 항목을 생성할 수 있습니다. 같은 원본 데이터에서 파생된 여러 서버를 관리할 때 적합합니다. Config는 규칙, 정책 및 DNS 등의 동작을 담당합니다. 요청이 어떤 규칙과 일치하는지, 일치한 뒤 PROXY, DIRECT 또는 다른 정책으로 처리할지를 결정합니다. 서버 연결 여부와 트래픽 분배는 서로 다른 계층입니다. 잘못된 포트를 Config 변경으로 해결할 수 없고, 맞지 않는 규칙을 구독 새로고침 반복으로 고칠 수도 없습니다.

Home에 표시되는 서버 목록은 일상적으로 연결 대상을 선택하는 곳입니다. Subscribe는 구독을 저장하고 업데이트하며, Add Server는 단일 서버를 입력합니다. Config는 규칙 Config를 선택하거나 편집하고, Global Routing은 현재 Config, 프록시 또는 직접 연결 방식을 결정합니다. iPhone과 iPad에서는 화면 배치가 다를 수 있지만 이러한 영어 명칭이 나타내는 기능 관계는 같습니다. 진입 위치가 이 문서와 조금 다르면 화면 좌표를 기계적으로 누르지 말고 현재 앱에서 같은 이름의 항목을 찾으세요.

입력 전에 원본 자료 보관하기

Subscribe를 사용하든 Add Server를 사용하든 먼저 수정하지 않은 원본 자료를 저장해야 합니다. 구독은 최소한 용도, 전체 주소 및 마지막으로 사용 가능함을 확인한 상태를 기록하세요. 단일 서버는 프로토콜 이름, 호스트, 포트, 인증 필드, TLS 상태, 전송 방식 및 메모를 기록하는 것이 좋습니다. 긴 주소, 대소문자, 경로 및 쿼리 매개변수는 스크린샷에서 잘릴 수 있으므로 전체 내용을 공개 메모, 공개 스크린샷 또는 공동 문서에 보관하지 마세요. 입력 전에 불필요해 보이는 문자를 임의로 삭제하지도 마세요. URL의 슬래시, 물음표, 해시 및 퍼센트 기호는 구조적 의미를 가질 수 있으며, 저장된다고 해서 의미가 그대로라는 보장은 없습니다.

먼저 적은 수의 항목으로 검증한 뒤 전체 목록으로 확장하세요. 순서는 기기 시간과 네트워크가 정상인지 확인하고, 서버 하나 또는 구독 하나를 입력한 다음 Connectivity Test를 실행하고, 대상을 선택한 뒤 Global Routing과 Config를 확인하는 방식입니다. 이렇게 하면 변수 수가 적어 오류가 원본 매개변수, 구독 해석, 서버 연결 또는 규칙 분배 계층 중 어디에서 발생했는지 판단하기 쉽습니다. 앱 출처를 아직 확인하지 않았다면 App Store 정품 확인 안내를 먼저 참고하세요. Shadowrocket의 개발자는 Shadow Launch Technology Limited이며 앱 ID는 932747118입니다.

Subscribe 입력 및 업데이트 전략

새 구독을 추가할 때 주소의 완전성부터 확인하기

Shadowrocket에서 Subscribe로 들어가 항목을 추가하면 보통 구독 주소를 입력하고, 화면에 제공되는 필드에서 이름이나 업데이트 동작을 설정할 수 있습니다. 붙여넣기 전에 주소 앞뒤에 공백이나 줄바꿈이 있는지 확인하세요. 메신저, 이메일 및 웹페이지에서는 긴 텍스트를 복사할 때 문장 끝의 구두점이 함께 선택되거나 화면에 생략된 부분만 복사될 수 있습니다. 사용자가 보관한 원본 자료에서 전체 내용을 복사하고, 붙여넣은 뒤 커서를 처음과 끝으로 옮겨 확인하세요. 중간의 도메인만 눈으로 확인해서는 안 됩니다.

이름은 ‘구독 1’이나 ‘새 구독’처럼 나중에 구분하기 어려운 표현보다 용도나 범위를 설명해야 합니다. 이름은 로컬 정리용일 뿐 주소 내용을 복구하지 않습니다. 같은 주소를 반복해서 추가하면 업데이트 후 비슷한 서버 그룹이 생겨 선택과 문제 해결이 어려워질 수 있습니다. 추가 전에 Subscribe 목록을 열어 용도, 도메인 및 경로가 모두 같은 항목이 이미 있는지 확인하세요. 주소의 인증 매개변수가 한 글자만 달라도 서로 다른 데이터로 보고 수동으로 합치지 않는 것이 좋습니다.

이름: 평일 일상
주소: https://example.com/sub?token=xxxx
업데이트 전 확인:
1. https://로 시작
2. 끝에 공백, 마침표 또는 줄바꿈 없음
3. token 매개변수가 완전함
4. 같은 주소를 중복 저장하지 않음

수동 업데이트, 자동 업데이트 및 실패 시 보존

구독 업데이트는 클라이언트가 원격 내용을 다시 읽고 해당 구독에 연결된 서버 항목을 조정하는 과정입니다. 일상적인 관리에서는 먼저 수동 업데이트로 결과를 확인하는 편이 안전합니다. 업데이트 후 서버 수가 비정상적으로 변했는지, 기존 메모가 바뀌었는지, 현재 선택한 항목이 여전히 존재하는지 확인하고 사용할 항목을 다시 테스트하세요. 자동 업데이트는 데이터 관리가 안정된 경우에 적합하지만 빈도를 지나치게 높이지 마세요. 요청을 너무 자주 보낸다고 연결 품질이 좋아지지는 않으며, 오히려 문제를 재현하는 동안 목록이 계속 변해 동일한 조건에서 비교하기 어려워질 수 있습니다.

업데이트가 한 번 실패했다고 구독을 즉시 삭제하거나 계속 반복해서 누르지 마세요. 먼저 어느 계층에서 실패했는지 구분해야 합니다. 브라우저에서 일반 웹페이지도 정상적으로 열리지 않으면 현재 네트워크를 먼저 복구하세요. 해당 구독만 실패한다면 주소가 잘렸는지, 기기 시간이 정확한지, 주소의 인증 정보가 변경되지 않았는지 확인하세요. 업데이트 성공으로 표시되지만 서버 목록이 비어 있다면 원본 자료로 돌아가 반환 내용이 여전히 클라이언트가 해석할 수 있는 형식인지 확인해야 합니다. 한 번의 실패가 로컬 항목 전체가 무효라는 뜻은 아니므로, 삭제하기 전에 기존 항목을 테스트하고 연결할 수 있는지 먼저 확인하세요.

업데이트가 끝난 뒤에는 ‘새로고침 성공’과 ‘서버 사용 가능’을 구분해서 판단해야 합니다. 새로고침 성공은 클라이언트가 데이터를 가져와 처리했다는 뜻일 뿐 모든 서버가 연결된다는 의미는 아닙니다. 반대로 특정 서버의 시간 초과가 구독 주소 오류를 뜻하는 것도 아닙니다. 먼저 Subscribe에서 업데이트 상태를 확인하고, 서버 목록에서 Connectivity Test를 실행한 다음, 항목을 선택해 실제 연결을 검증하세요. 계층별로 확인하면 연결 문제를 구독 문제로 오인하는 일을 줄일 수 있습니다.

업데이트 전후의 통제 가능한 변경

구독 관리에서 흔한 문제는 업데이트가 해당 구독으로 생성된 내용을 덮어쓸 수 있다는 점입니다. 구독 항목 아래의 서버 이름이나 필드를 직접 수정하면 다음 새로고침 때 원격 데이터로 대체될 수 있습니다. 장기간 보관할 개인 메모는 별도 기록에 두고, 실험할 매개변수는 별도의 수동 입력 서버로 복사한 뒤 수정하세요. 이름에는 ‘테스트 복사본’처럼 표시하는 것이 좋습니다. 그러면 구독은 원래 상태를 유지하고 다음 업데이트가 실험 결과를 덮어쓰지 않습니다.

업데이트 후 중복 항목이 많이 생겨도 먼저 하나씩 삭제하지 마세요. 같은 구독이 중복 추가되었는지, 여러 구독에 같은 서버가 포함되었는지, 원격 메모가 바뀌어 시각적으로 비슷해졌는지부터 판단해야 합니다. 앞의 두 경우는 Subscribe 계층에서 정리하고, 마지막 경우는 프로토콜, 호스트, 포트 및 인증 필드를 비교하세요. 중복 항목을 체계적으로 처리하려면 여러 구독 정리 장을 참고하세요. 화면 안내만으로 판단하기 어렵다면 문제 해결에서 ‘구독 및 서버 가져오기’ 분류를 확인하세요.

Add Server 수동 입력 필드 및 확인 순서

프로토콜을 먼저 선택한 뒤 필드에 매핑하기

Add Server는 단일 서버의 전체 매개변수를 이미 보유하고 있으며 항목별로 입력하거나 독립적인 테스트 복사본을 만들고 싶을 때 사용합니다. 첫 단계는 주소 입력이 아니라 올바른 프로토콜 유형을 선택하는 것입니다. Shadowsocks, VMess, VLESS, Trojan, HTTP, SOCKS5, WireGuard 및 Hysteria2는 인증 모델이 서로 다릅니다. 필드 이름이 비슷해도 의미를 서로 바꿔 사용할 수 없습니다. 유형을 잘못 선택해도 저장은 될 수 있지만, 연결 단계에서 핸드셰이크, 인증 또는 전송 구조가 맞지 않아 실패할 수 있습니다.

입력할 때는 프로토콜 유형, 서버 주소, 포트, 인증 필드, TLS 또는 암호화 관련 옵션, 전송 방식, 경로와 Host, 메모 순서를 권장합니다. 각 그룹을 입력할 때마다 원본 자료와 한 글자씩 대조하세요. 서버 주소는 도메인 또는 IP 주소이며 원본 그대로 입력해야 합니다. 프로토콜 접두사를 추가하지 말고 포트를 주소 필드에 다시 붙이지도 마세요. 포트에는 숫자만 입력합니다. 이름이나 메모는 자유롭게 정할 수 있지만 원본 매개변수 기록을 대신하게 해서는 안 됩니다.

인증, TLS 및 전송 필드는 임의로 추측해 설정할 수 없음

인증 필드는 대소문자를 구분하는 경우가 많습니다. UUID의 하이픈, 비밀번호의 기호, 키의 대소문자는 내용 자체이므로 자동으로 바꾸지 마세요. 복사 후 연결에 실패하면 필드를 삭제하고 다시 붙여넣어 보이지 않는 공백을 배제할 수 있습니다. TLS, SNI, Host, Path, Transport 등의 필드는 서로 연관된 하나의 매개변수 그룹으로 보세요. 원본 자료에 명시되어 있으면 항목별로 대응하고, 명시되지 않았다면 다른 서버의 경험을 바탕으로 값을 추가하지 마세요. 특히 Host와 SNI는 일부 Config에서 내용이 같을 수 있지만 역할 계층이 다르므로 문자가 같다는 이유만으로 임의로 바꿀 수 없습니다.

Transport 선택도 원본 자료와 일치해야 합니다. WebSocket과 같은 전송 방식을 선택하면 Path, Host 등의 추가 필드가 나타날 수 있습니다. 이러한 필드는 해당 전송 방식에서만 의미가 있습니다. 원본 자료가 다른 전송을 사용한다면 다른 항목의 Path를 그대로 복사해도 호환되지 않습니다. 기존 항목을 편집할 때는 먼저 프로토콜과 Transport를 확인한 다음 옵션 전환으로 추가 필드가 남아 있는지 점검하세요. 필요하면 테스트 복사본을 새로 만들어 빈 상태에서 입력하면 이전 필드가 남아 생기는 문제를 배제할 수 있습니다.

저장 후 최소 검증 순환

입력을 마치면 먼저 저장하되 나머지 항목을 즉시 일괄 입력하지 마세요. Home으로 돌아가 방금 추가한 서버를 찾은 뒤 Connectivity Test 또는 지연 시간 테스트를 실행하세요. 테스트 응답이 있으면 해당 항목을 눌러 현재 서버로 선택하고 Global Routing을 확인합니다. 최초 검증에는 Config를 사용하고 현재 Config에 이해할 수 있는 규칙이 있는지 확인하세요. 규칙 영향을 배제하려면 명확한 테스트 목적 아래 Proxy와 Direct를 임시로 비교할 수 있지만, 테스트가 끝나면 예상한 방식으로 되돌려야 합니다. Global Routing의 세 가지 방식은 Config, Proxy, Direct입니다.

테스트가 시간 초과되면 한 번에 여러 옵션을 바꾸지 말고 필드 순서대로 역추적하세요. 주소와 포트, 인증 필드, TLS·SNI·Transport, 기기 시간과 현재 네트워크 순서로 확인합니다. 매번 한 항목만 변경하고 다시 테스트해야 어떤 변경이 실제로 영향을 주었는지 알 수 있습니다. 모든 매개변수가 한 글자씩 일치해도 연결되지 않으면 원본 항목과 테스트 기록을 보존하세요. 시도 과정에서 유일하게 정확한 데이터를 덮어쓰지 않도록 주의해야 합니다. 프로토콜 기본 필드에 대한 자세한 내용은 Shadowrocket이 지원하는 프로토콜을 참고하세요.

Scan QR Code, 클립보드 및 공유 링크

QR 코드 가져오기 전에 내용 확인하기

서버 정보가 QR 코드로 인코딩되어 있다면 Scan QR Code를 사용할 수 있습니다. QR 코드는 텍스트를 담는 또 다른 방식일 뿐이며 매개변수의 정확성을 높여 주지는 않습니다. 스캔 전에 해당 QR 코드가 현재 가져오려는 서버 자료인지 확인하고, 인증 정보가 포함된 QR 코드를 공개된 장소에 표시하지 마세요. 인식이 끝난 뒤에는 ‘가져오기 성공’만 믿고 바로 연결하지 말고 새 항목을 열어 프로토콜 유형, 서버 주소, 포트 및 메모가 예상과 맞는지 확인하세요.

다른 개인 기기의 화면에 표시된 QR 코드를 스캔한다면 화면 밝기를 적절히 높이고 카메라를 안정적으로 유지하세요. 인식이 어렵다면 흐릿한 이미지를 반복해서 잘라내기보다 원본 공유 텍스트를 사용하세요. QR 코드 가장자리가 잘렸거나 이미지가 과도하게 압축되었거나 중앙이 가려지면 인식되지 않을 수 있습니다. 스캔할 수 없는 것은 읽기 계층의 문제이며 QR 코드 안의 서버 매개변수가 무효라는 뜻은 아닙니다. 읽기에는 성공했지만 테스트에 실패했다면 매개변수 계층을 확인하고, 특히 프로토콜 유형, 인증 정보 및 Transport 추가 필드를 살펴보세요.

클립보드 가져오기에서 공백과 여러 줄 처리하기

클립보드 가져오기는 단일 공유 링크 또는 앱이 인식할 수 있는 구조화된 텍스트에 적합합니다. 복사할 때는 스킴 식별자부터 마지막 문자까지 선택하고 앞뒤에 설명 문자가 섞이지 않게 하세요. 한 메시지에 제목, 번호 및 여러 링크가 함께 있다면 클라이언트가 유효한 줄을 추측하게 하지 말고 한 줄씩 복사하는 것이 좋습니다. 공유 링크에는 서버 주소와 인증 정보가 포함될 수 있으므로 가져온 뒤 클립보드도 바로 지우는 편이 안전합니다.

일부 텍스트 도구는 긴 링크를 자동으로 줄바꿈합니다. 화면에 보이는 줄바꿈이 실제 줄바꿈은 아닐 수 있지만 서식 있는 텍스트에서 복사하면 공백이나 줄바꿈 문자가 삽입될 수 있습니다. ‘프로토콜은 인식되지만 연결할 수 없는’ 경우 링크를 신뢰할 수 있는 로컬 일반 텍스트 편집 영역에 붙여넣어 구조를 확인하고 원본 자료와 대조하세요. 중간 문자를 삭제하며 시행착오를 반복하지 마세요. 쿼리 매개변수나 인코딩 문자가 빠지면 링크는 인식되더라도 불완전한 서버 항목이 생성될 수 있습니다.

공유 링크는 매개변수 컨테이너이며 장기 백업 형식이 아닙니다

일반적인 공유 텍스트는 접두사로 프로토콜 유형을 표시하고 뒤쪽에 주소, 포트, 인증 정보 및 메모를 담습니다. 프로토콜마다 구조가 다르므로 한 프로토콜의 링크 접두사를 다른 프로토콜로 바꿔 변환할 수 없습니다. 아래 내용은 구조를 구분하는 방법만 보여 주며 모두 사용할 수 없는 예시입니다. 실제 작업에는 사용자가 직접 보유한 전체 자료를 사용해야 합니다.

ss://[email protected]:443#Example
vmess://ENCODED-DEMO-DATA
vless://[email protected]:443?type=ws&security=tls#Example
trojan://[email protected]:443?security=tls#Example
hysteria2://[email protected]:443?insecure=0#Example

링크 끝의 메모는 보통 표시 이름으로 사용되며 퍼센트 인코딩으로 읽기 어려울 수 있습니다. 이는 프로토콜 본문에 영향을 주지 않지만 수동으로 수정할 때 앞쪽 쿼리 매개변수를 손상하지 않도록 주의하세요. 가져온 결과의 메모가 깨져 보이면 연결 매개변수가 완전한지 확인한 뒤 로컬 이름만 수정하고 주소나 인증 필드는 함께 바꾸지 마세요. VMess처럼 전체 인코딩을 사용하는 형식은 수동으로 나눠 다시 조합하지 않는 것이 좋습니다. 원본 링크로 가져온 뒤 서버 상세 화면에서 각 필드를 확인하는 편이 안전합니다.

공유 링크는 관리되는 범위 안에서 한 개인 기기에서 다른 개인 기기로 옮길 때 적합하지만 유일한 백업으로 사용해서는 안 됩니다. 로컬 메모, 정렬, Config 및 기타 관리 정보가 빠질 수 있고 복사 불완전으로 무효가 될 수도 있습니다. 장기 보관 시에는 원본 매개변수 설명, 구독 주소 기록 및 Config 파일을 함께 보관하고 각각의 용도를 적어 두세요. 단일 항목을 다른 개인 기기로 전달해야 한다면 QR 코드를 생성하거나 표시할 때 주변 환경에 주의하고 사용 후 표시 화면을 즉시 닫으세요.

여러 구독의 그룹, 이름 지정 및 중복 항목 정리

먼저 출처 경계로 관리한 뒤 용도에 따라 이름 지정하기

Subscribe에 한두 항목만 있을 때는 기본 이름도 사용할 수 있어 보입니다. 하지만 수가 늘어나면 의미가 불분명한 이름이 업데이트와 문제 해결에 직접 영향을 줍니다. 이름에는 최소한 용도, 기기 상황 또는 데이터 범위를 표시하세요. 예를 들면 ‘일상 주 그룹’, ‘임시 테스트’, ‘이전 Config 확인’과 같이 정할 수 있습니다. 서버 지역, 프로토콜 및 구독 용도를 하나의 지나치게 긴 이름에 모두 넣지 말고 상세 정보는 별도 기록에 보관하세요. 이름의 목적은 업데이트 전에 어떤 서버 그룹에 영향을 주는지 알 수 있게 하는 것입니다.

정리할 때는 구독을 관리 경계로 삼고 혼합 서버 목록에서 항목을 하나씩 먼저 옮기지 마세요. 먼저 Subscribe를 열어 각 항목의 주소, 이름 및 마지막 수동 업데이트 결과를 확인한 다음 서버 목록으로 돌아가 각 그룹이 생성한 항목을 확인하세요. 더 이상 사용하지 않는 구독은 먼저 업데이트 동작을 중지하거나 상태를 기록하고 일정 기간 확인한 뒤 삭제하는 것이 좋습니다. 바로 삭제하면 연결된 항목과 과거 판단 근거가 함께 사라져 ‘정말 필요 없는 항목’과 ‘일시적인 업데이트 실패’를 구분하기 어렵습니다.

중복 항목은 핵심 필드를 비교해야 합니다

표시 이름이 같다고 서버가 완전히 같은 것은 아닙니다. 중복 여부를 판단할 때 최소한 프로토콜, 서버 주소, 포트 및 인증 식별자를 비교하세요. TLS 또는 Transport가 관련되면 SNI, Host, Path 및 관련 옵션도 비교해야 합니다. 이러한 핵심 필드가 모두 같을 때만 연결 관점에서 중복으로 볼 수 있습니다. 반대로 이름은 다르지만 핵심 필드가 같다면 서로 다른 구독이 같은 서버에 다른 메모를 붙인 것일 수 있습니다.

중복을 발견하면 먼저 각각 어느 구독에 속하는지 추적하세요. 같은 구독이 중복 추가한 경우 주소가 정확하고 업데이트가 정상인 항목을 남긴 뒤 중복 Subscribe 기록을 제거합니다. 서로 다른 구독에서 온 경우에는 일상적인 관리 경계에 따라 보존 방식을 결정하고 같은 주소의 모든 항목을 무작정 삭제하지 마세요. 서로 다른 구독의 같은 서버는 이후 업데이트 방향이 달라질 수 있으므로 오늘 중복이라고 미래에도 항상 중복인 것은 아닙니다. Home을 읽기 쉽게 만들고 싶다면 명확한 이름, 정렬 및 만료된 그룹 정리로 개선하면 되며, 중복을 0으로 만들기 위해 구독 구조를 훼손할 필요는 없습니다.

안정적인 정리 주기 만들기

여러 구독을 매일 다시 정렬할 필요는 없습니다. 추가할 때 이름을 정하고 수동 업데이트를 실행하며, 업데이트 후 주요 항목을 표본 확인하고, 이상이 생기면 테스트 기록을 보존한 뒤 무효임을 확인하고 삭제하는 방식이 실용적입니다. 정렬은 일상적인 선택에 도움이 되지만 서버 품질에 대한 영구적인 결론은 아닙니다. 네트워크 환경, 테스트 대상 및 시간에 따라 지연 시간이 달라집니다. 테스트할 때마다 크게 재정렬하면 익숙한 위치가 계속 바뀌어 오히려 불편합니다.

간단한 로컬 목록을 만들어 구독 이름, 용도, 자동 업데이트 여부, 마지막 수동 확인 결과 및 연결된 Config를 기록하는 것이 좋습니다. 전체 인증 정보를 복사할 필요는 없으며 관리 관계를 설명하는 용도로만 사용하세요. 새 구독을 시험할 때는 독립적인 이름으로 두고 업데이트, 표본 확인 및 실제 연결을 완료한 뒤 일상 그룹에 포함하세요. 그러면 실험 데이터에 중복이나 필드 오류가 있어도 안정적인 목록을 바로 흐트러뜨리지 않습니다.

대량으로 정리하기 전에 Config를 동시에 수정하지 않는 것이 좋습니다. 서버 목록과 규칙이 함께 바뀌면 연결 문제가 어느 계층에서 발생했는지 판단하기 어렵습니다. 먼저 구독과 서버 항목을 안정시킨 뒤 Global Routing과 Config를 확인하거나, 서버를 먼저 고정한 뒤 규칙을 별도로 테스트하세요. 여러 구독 정리의 목표는 목록을 가장 짧게 만드는 것이 아니라 각 기록의 출처 경계, 업데이트 방식 및 용도를 다시 이해할 수 있게 하는 것입니다.

Connectivity Test, 지연 시간 정렬 및 문제 진단

테스트 결과는 현재 테스트 조건만 보여 줍니다

Connectivity Test와 서버 목록의 지연 시간 테스트는 현재 기기, 현재 네트워크 및 현재 시점에서 대상과 해당 테스트 연결을 설정할 수 있는지 빠르게 판단하는 데 사용합니다. 결과는 명백히 시간 초과되는 항목을 걸러내고 정렬하는 데 유용하지만 모든 앱 트래픽의 장기적인 성능을 나타내지는 않습니다. 테스트 대상, 프로토콜 핸드셰이크, 네트워크 혼잡 및 무선 신호가 결과에 영향을 주므로 한 번 낮게 나온 수치가 영구적으로 안정적이라는 뜻은 아니며, 한 번의 시간 초과만으로 삭제해서도 안 됩니다.

일괄 테스트 전에 기기가 네트워크 전환 상태가 아닌지 확인하세요. 모바일 네트워크에서 무선 네트워크로 전환 중이거나 무선 네트워크가 막 재연결된 상태라면 일괄 테스트에서 전체 그룹이 시간 초과될 수 있습니다. 네트워크가 안정될 때까지 기다린 뒤 테스트하고 화면은 가능한 한 포그라운드에 유지하세요. 첫 결과가 이상하면 잠시 후 두 번째 테스트를 실행할 수 있습니다. 소수 항목만 계속 시간 초과되면 단일 항목의 매개변수를 확인하세요.

범위에 따라 문제 계층 판단하기

테스트 결과에서 가장 중요한 정보는 단일 숫자가 아니라 실패 범위입니다. 모든 서버가 동시에 시간 초과되면 현재 네트워크, 시스템 시간 및 Shadowrocket 연결 상태를 먼저 확인하세요. 같은 구독의 모든 서버만 시간 초과되고 다른 구독은 정상이라면 해당 구독 업데이트 후의 공통 필드나 데이터 상태를 확인해야 합니다. 단일 서버만 시간 초과되면 해당 항목의 주소, 포트, 인증 및 전송 매개변수를 우선 확인하세요. 테스트에는 응답하지만 대상 콘텐츠가 열리지 않는다면 구독 주소를 반복해서 편집하지 말고 현재 선택한 서버, Global Routing, Config 규칙 및 DNS를 확인하세요.

정렬은 선택을 위한 것이며 검증을 대신하지 않습니다

지연 시간으로 정렬하면 이번 테스트에서 응답이 빠른 항목이 앞에 표시됩니다. 정렬은 많은 서버 중 후보를 좁히는 데 적합하지만 연결하기 전 프로토콜 매개변수와 용도를 확인해야 합니다. 일부 항목은 테스트 응답은 빠르지만 현재 Config의 사용 방식에 맞지 않을 수 있고, 일시적인 변동으로 두 번의 정렬에서 위치가 달라질 수도 있습니다. 먼저 지연 시간으로 후보를 소수로 좁힌 다음 하나씩 실제 연결을 검증하고, 매번 첫 번째 항목을 기본값처럼 선택하지 않는 것이 좋습니다.

여러 구독 목록을 일괄 테스트할 때는 그룹별로 나누어 결과가 너무 많아 관찰하기 어려워지는 일을 피하세요. 계속 시간 초과되는 항목을 기록한 뒤 주소, 프로토콜 또는 구독을 공유하는지 먼저 확인하세요. 공통 특징이 단일 수치보다 문제를 더 잘 설명하는 경우가 많습니다. 장기간 무효라고 판단하기 전에 네트워크가 안정된 상태에서 최소 한 번 재테스트하고 최근 구독 업데이트가 성공했는지도 확인하세요. 삭제는 마지막 단계이며 첫 시간 초과에 대한 즉시 조치가 아닙니다.

연결은 성공했지만 분배 결과가 예상과 다를 때

서버 테스트가 정상이고 전체 스위치도 연결되어 있지만 특정 도메인의 경로가 예상과 다르면 문제는 대개 규칙 계층에 있습니다. 먼저 Global Routing이 Config인지 확인하세요. Proxy 상태에서는 규칙 목록이 Config 방식으로 각 요청을 결정하지 않고, Direct 상태에서는 서버 항목이 현재 트래픽을 처리하지 않습니다. Config 상태에서 규칙을 위에서 아래로 확인하고, 더 구체적인 DOMAIN, DOMAIN-SUFFIX, IP-CIDR 등의 규칙이 앞선 포괄적인 규칙에 가려지지 않았는지, FINAL의 최종 경로가 무엇인지 확인하세요.

모든 도메인의 동작이 이상하다면 Config에서 예상한 파일을 선택했는지, Config 안에서 참조하는 정책 이름이 존재하는지도 확인해야 합니다. 규칙에 PROXY가 적혀 있어도 Config에 해당 정책에서 사용할 서버가 없으면 문법이 올바르더라도 예상한 결과를 얻을 수 없습니다. 연결 실패의 전체 점검 순서는 서버 시간 초과 및 연결 실패 점검 목록을, 최초 연결의 가장 짧은 검증 과정은 최초 연결 튜토리얼을 참고하세요.

삭제, 백업, 복원 및 기기 이전

삭제 전에 대상 계층 확인하기

Shadowrocket에서 삭제할 수 있는 대상은 단일 서버, 전체 Subscribe 기록 또는 Config이며 각각 영향 범위가 다릅니다. 수동 입력 서버 하나를 삭제하면 해당 로컬 기록만 영향을 받습니다. 구독으로 생성된 항목을 삭제해도 다음 업데이트에서 다시 생성될 수 있습니다. Subscribe를 삭제하면 해당 그룹의 업데이트 경로를 잃고, Config를 삭제하면 규칙 선택에 영향을 주지만 서버가 자동으로 삭제되지는 않습니다. 실행 전에 현재 어느 목록에 있는지 확인하고 이름, 주소 및 연결된 용도를 살펴보세요.

일시적으로 시간 초과된 항목은 먼저 표시하거나 기록하고 바로 삭제하지 않는 것이 좋습니다. 제거할 구독은 먼저 전체 주소와 용도 설명을 저장하고 다른 구독이 같은 관리 구성을 참조하지 않는지 확인하세요. 삭제할 Config는 현재 사용 중인지와 로컬 수정 사항이 있는지 먼저 점검해야 합니다. 삭제 후 오판을 발견했을 때 정확히 복원하려면 원본 자료가 보존되어 있어야 합니다. 긴 주소나 복잡한 규칙을 기억에 의존해 다시 입력하면 새로운 오류가 생기기 쉽습니다.

백업은 네 가지 자료를 포함해야 합니다

완전한 관리 백업에는 최소한 구독 주소 기록, 수동 입력 서버 매개변수, Config 파일, 그리고 이 자료들의 관계를 설명하는 간단한 목록이 포함되어야 합니다. 구독 주소만 저장하면 독립적인 수동 입력 항목을 보존할 수 없고, Config만 내보내도 모든 서버 인증 정보가 자동으로 포함되지는 않습니다. 백업 전에 Home, Subscribe, Config 및 Settings에서 이전과 관련해 표시되는 항목을 확인하고 대상별로 처리하세요.

현재 앱 화면에 Data, Import from Cloud JSON 또는 해당 가져오기·내보내기 진입점이 있다면 먼저 화면 안내를 읽고 처리되는 데이터 범위를 확인하세요. 특정 JSON을 가져올 수 있다고 해서 모든 설정이 자동으로 복원된다고 이해해서는 안 됩니다. 내보낸 뒤에는 기존 데이터를 덮어쓰지 않는 상태에서 파일이 생성되었는지, 이름을 알아볼 수 있는지 확인하고 내보낼 당시의 용도를 기록하세요. 백업 파일과 구독 주소에는 민감한 내용이 포함될 수 있으므로 통제된 개인 저장 공간에 보관해야 합니다.

기기를 바꿀 때 순서대로 복원하기

새 iPhone 또는 iPad에서 복원할 때는 먼저 App Store의 구입 항목에서 Shadowrocket을 받은 다음 데이터를 계층별로 복원하세요. 구입 및 구입 항목 복원 방법은 기기 변경 및 구입 복원 안내에서 확인할 수 있습니다. 시스템 요구 사항은 항상 App Store 페이지의 표기를 기준으로 합니다. 앱 준비가 끝나면 먼저 Config 하나를 가져오거나 기본 상태를 유지하고, 구독 하나를 복원해 수동 업데이트한 다음 서버 하나를 테스트하세요. 기본 연결이 정상임을 확인한 뒤 나머지 구독과 수동 입력 항목을 추가합니다.

처음 연 뒤 모든 자료를 한 번에 가져와 기존 내용을 즉시 덮어쓰지 마세요. 나누어 복원하면 오류 범위를 줄일 수 있습니다. 구독 업데이트에 실패하면 해당 구독만 확인하고, 서버 테스트에 실패하면 해당 매개변수만 대조하며, 분배가 예상과 다르면 Config를 확인하면 됩니다. Import from Cloud JSON을 사용한 경우에도 가져오기가 끝난 뒤 항목을 하나씩 표본 확인해야 하며 단순히 항목 수만 보아서는 안 됩니다. 이름, 정렬 및 현재 선택 상태가 이전 기기와 다를 수 있지만 이러한 차이가 반드시 매개변수 손실을 의미하지는 않습니다.

복원이 끝나면 세 차례 점검하세요. 첫 번째는 Subscribe를 수동으로 업데이트할 수 있는지, 두 번째는 주요 서버의 Connectivity Test와 실제 연결, 세 번째는 Global Routing이 Config일 때 자주 사용하는 도메인이 규칙에 따라 예상한 정책으로 들어가는지 확인합니다. 그 뒤 On Demand와 같은 자동 연결 동작을 점검하세요. 기본 연결을 확인하기 전에 변수를 추가하지 않도록 주의해야 합니다. 이전 기기의 자료는 새 기기에서 안정적인 검증을 완료할 때까지 보관한 뒤 개인 데이터 관리 계획에 따라 처리하세요.

단순 보관이 아니라 복원 가능한 기록 만들기

효과적인 백업의 기준은 ‘파일이 존재하는가’가 아니라 복원 방법을 설명할 수 있는가입니다. 각 Config에 용도를 적고, 각 Subscribe 기록에 해당 이름을 적으며, 수동 입력 서버에는 필드 목록을 보관하고 복원 후 검증 절차를 기록하세요. 설명 없이 긴 링크 하나만 보관하면 몇 달 뒤 그것을 Subscribe에 넣어야 하는지 단일 서버로 가져와야 하는지 판단하기 어렵고 현재 사용 범위에 속하는지도 확인하기 어렵습니다.

Config를 크게 조정한 뒤에는 복사본을 다시 저장하되 비슷한 파일을 많이 만들어 저장 공간을 채울 필요는 없습니다. ‘현재 안정 버전’, ‘수정 전’, ‘실험 중’ 세 가지 상태를 보관하고 파일 이름에 인증 정보를 넣지 마세요. 실험이 성공하면 확인된 버전을 현재 안정 버전으로 지정하고, 실패하면 수정 전 복사본으로 돌아갑니다. 이러한 버전 구분은 개인 자료 관리 방식이며 클라이언트가 표시하는 앱 버전에 의존하지 않고 화면이 바뀌어도 의미가 유지됩니다.

Config, Global Routing 및 규칙 분배

세 가지 Global Routing 방식 이해하기

서버 관리는 최종적으로 트래픽 정책과 함께 운영해야 합니다. Global Routing의 Config, Proxy, Direct는 각각 구성, 프록시 및 직접 연결에 해당합니다. Config는 현재 Config 파일의 규칙에 따라 하나씩 판단하고, Proxy는 요청을 현재 프록시 정책에 일괄 전달하며, Direct는 요청을 직접 연결합니다. 일상적으로 규칙 분배를 사용할 때는 Config를 선택하세요. Proxy와 Direct는 문제가 규칙 계층에서 발생하는지 확인하는 등 명확한 목적의 비교 테스트에 적합하며, 테스트가 끝나면 예상한 방식으로 되돌려야 합니다.

규칙은 위에서 아래로 처음 일치한 항목을 사용합니다

Config의 규칙은 보통 작성된 순서대로 처리됩니다. 요청이 어떤 규칙을 만족하면 해당 규칙이 지정한 정책을 실행하고 뒤의 규칙은 계속 찾지 않습니다. 따라서 구체적인 규칙을 더 포괄적인 규칙보다 앞에 배치해야 합니다. 예를 들어 단일 DOMAIN 규칙은 더 넓은 범위를 다루는 DOMAIN-SUFFIX보다 앞에, 로컬 네트워크 IP-CIDR 규칙은 FINAL보다 앞에 배치합니다. FINAL은 앞에서 일치하지 않은 요청을 처리하며 보통 규칙 목록의 마지막에 둡니다.

DOMAIN은 전체 도메인과 정확히 일치하고, DOMAIN-SUFFIX는 도메인 접미사로 매칭하며, DOMAIN-KEYWORD는 도메인에 포함된 키워드로 매칭하므로 보통 범위가 더 넓습니다. GEOIP는 대상 IP의 지리 데이터베이스 결과를 기준으로 판단하고, IP-CIDR과 IP-CIDR6은 각각 주소 대역에 사용합니다. USER-AGENT는 요청 식별자로 매칭합니다. 규칙 오른쪽의 PROXY, DIRECT 또는 REJECT는 처리 정책이며 서버 프로토콜 이름이 아닙니다. PROXY는 사용 가능한 정책 또는 서버로 해석되어야 하고, DIRECT는 직접 연결, REJECT는 요청 거부를 의미합니다.

[Rule]
DOMAIN,api.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN-SUFFIX,apple.com,DIRECT
DOMAIN-KEYWORD,media,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
IP-CIDR6,fe80::/10,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

예시는 문법 관계만 보여 주며 모든 네트워크 환경에 적합하다는 뜻은 아닙니다. 실제 Config는 사용자의 목표와 기존 Config를 기준으로 확인해야 합니다. 수정하기 전에 원본 파일을 복사하고, 수정할 때마다 소수의 규칙만 변경하세요. 많은 규칙을 동시에 이동하고 정책 이름을 바꾸고 DNS까지 변경하면 문제가 생겨도 원인을 찾기 거의 어렵습니다. 먼저 구체적인 DOMAIN 규칙 하나를 추가해 매칭을 확인한 뒤 DOMAIN-SUFFIX 또는 범위가 더 넓은 유형으로 단계적으로 확장할 수 있습니다.

서버 이름, 정책 이름 및 규칙 대상은 서로 맞아야 합니다

규칙 끝에 PROXY를 적었다고 해서 어떤 서버든 자동으로 사용할 수 있는 것은 아닙니다. Config의 정책 이름은 실제로 존재하는 정책 구조와 대응해야 하며, 정책 내부에서 사용 가능한 서버를 선택할 수 있어야 합니다. 구독 업데이트 후 일부 서버 이름이 바뀌면 특정 이름을 직접 참조하는 정책을 다시 확인해야 할 수 있습니다. 규칙이 명확한 정책 이름을 가리키고 정책이 서버 선택을 관리하도록 하는 편이 안정적입니다. 많은 규칙에 특정 서버 이름을 분산해서 직접 입력하는 방식은 피하세요.

‘Connectivity Test는 정상인데 규칙이 적용되지 않을 때’는 다음 순서로 확인하세요. Global Routing이 Config인지, 현재 선택한 Config가 올바른지, 대상 도메인이 앞선 규칙과 먼저 매칭되는지, 규칙 끝의 정책 이름이 존재하는지, 해당 정책에 사용 가능한 서버가 있는지, FINAL이 너무 앞에 나오지 않았는지 확인합니다. 범위가 매우 좁은 DOMAIN 규칙을 임시로 추가해 검증한 뒤 확장 여부를 결정할 수 있습니다. 점검 중에는 모든 구독을 동시에 새로고침하지 말고 서버 목록 변화가 규칙 테스트를 방해하지 않게 하세요.

Config 수정, 가져오기 및 되돌리기

Config를 수정하기 전에 원본 복사본을 보관하고 테스트 복사본에는 구분하기 쉬운 이름을 지정하세요. 새 Config 파일을 가져온 뒤에는 먼저 섹션 이름, 규칙 영역 및 FINAL을 확인하고, 이미 알고 있는 도메인 몇 개를 선택해 테스트하세요. 파일을 가져올 수 있다는 이유만으로 모든 정책 참조가 유효하다고 판단하지 마세요. 문법을 읽을 수 있는 것과 정책을 실행할 수 있는 것은 별도의 확인 사항입니다. 앱에서 특정 정책 이름을 해석할 수 없다고 표시하면 Config로 돌아가 철자와 해당 그룹을 확인하세요.

규칙을 디버깅할 때는 되돌릴 경로를 보존해야 합니다. 수정할 때마다 현재 안정 복사본을 기록하고, 규칙 한 그룹을 수정한 뒤 즉시 테스트하며 수정 목적을 적으세요. 결과가 예상과 다르면 임시 규칙을 계속 추가하지 말고 이전 안정 복사본으로 복원하세요. 출처가 다른 Config 두 개를 그대로 이어 붙이는 것은 권장하지 않습니다. 같은 섹션, 같은 이름의 정책, 중복 FINAL 및 서로 다른 DNS 설정이 서로 덮어쓸 수 있습니다. 병합이 필요하면 각 영역을 이해한 뒤 처리하고 단계마다 검증하세요.

서버와 Config 관리를 마친 뒤 일상적인 유지 관리는 고정된 흐름으로 정리할 수 있습니다. 필요할 때 Subscribe를 업데이트하고, 주요 서버를 표본 확인하고, 이름을 명확하게 유지하며, Config 방식으로 연결하고, 문제가 생기면 네트워크·구독·서버·규칙의 네 계층으로 원인을 찾고, 중요한 변경 전에는 복사본을 저장하세요. 최초 연결 단계만 확인하려면 Shadowrocket 사용 튜토리얼로 돌아가고, 문제 분류를 한곳에서 확인하려면 문제 해결로 이동하세요.