01 · Subscribe: 업데이트 가능한 구독 등록
구독은 원격 목록을 저장해 반복해서 업데이트할 수 있는 진입점이지, 서버 몇 대를 한 번만 추가하는 기능이 아닙니다. 가져오기에 성공하면 구독 기록과 그 기록에서 펼쳐지는 서버 항목을 모두 확인해야 합니다. 구독 기록에는 주소와 업데이트 관계가 저장되고, 서버 항목은 연결 대상을 선택하는 데 사용됩니다. 목록이 길어졌다고 구독 관계가 올바르다는 뜻은 아니며, 주소만 저장됐다고 원격 콘텐츠를 제대로 읽었다는 뜻도 아닙니다. 두 가지를 구분해야 업데이트 단계와 연결 단계 중 어디서 문제가 생겼는지 판단하기 쉽습니다.
가져오기 전: 입력 내용 확인
기존 구독 주소는 이용 중인 서비스 제공업체에서 받으세요. Shadowrocket에서 사용할 수 있는 구독 주소인지, 계정 관리 페이지나 안내 페이지 또는 개별 서버 공유 링크가 아닌지 먼저 확인해야 합니다. 구독 주소는 개인 자격 증명에 해당할 수 있습니다. 일반 웹 주소처럼 보여도 서버 목록을 읽을 권한이 포함될 수 있습니다. 전체 주소를 공개 메모나 단체 채팅, 문제 화면 캡처에 올리지 마세요. 직접 확인할 때도 화면 녹화나 클립보드 동기화로 접근 매개변수가 노출되지 않도록 주의하세요.
가져오기 전에 원문을 따로 보관하고 처음과 끝, 중간에 공백이나 줄바꿈, 한국어 문장 부호가 섞이지 않았는지 확인하세요. 특히 메시지 앱이 자동으로 붙인 마침표나 복사 버튼 옆의 안내 문구까지 함께 선택하지 않았는지 살펴보세요. 쿼리 매개변수를 임의로 지우거나 낯선 문자를 익숙한 문자로 바꾸지 마세요. 주소의 대소문자, 경로, 매개변수는 식별에 사용될 수 있습니다. 표시 이름을 정리하는 것과 실제 주소를 수정하는 것은 전혀 다른 작업입니다.
Add Server에서 Subscribe 선택
Home에서 추가 메뉴를 열고 Add Server로 이동한 다음 Type을 Subscribe로 설정하세요. 전체 주소를 입력하고 알아보기 쉬운 메모를 붙여 저장합니다. 화면 배치는 기기에 따라 다를 수 있으므로 현재 앱에 표시되는 내용을 기준으로 하세요. 처음에는 구독 하나만 추가하고 저장 후 해당 목록이 생성되는지 확인한 뒤 다음 항목을 진행하세요. 여러 주소를 한꺼번에 가져오면 실패 원인을 구분하기 어렵고, 중복 기록을 업데이트로 새로 생긴 항목으로 착각하기 쉽습니다.
저장한 뒤 Home으로 돌아가 구독 이름, 펼쳐진 항목, 예상한 서버가 일치하는지 확인하세요. 목록의 안내용 항목을 연결 가능한 서버로 단정해서는 안 됩니다. 이름에 상태 안내가 있다면 항목 유형과 상세 정보를 함께 살펴보세요. 그런 다음 필수 매개변수가 모두 입력된 서버 하나를 선택해 연결을 확인합니다. 가져오기와 연결은 별개의 결과입니다. 가져오기는 주소 접근과 콘텐츠 해석에 달려 있고, 연결은 서버 접근성, 인증, 전송 설정에도 좌우됩니다.
실패 시: 접근·콘텐츠·결과를 나눠 확인
저장 후 항목이 나타나지 않으면 먼저 주소가 완전한지 확인하고, 현재 네트워크에서 구독 호스트에 접속할 수 있는지 살펴보세요. 브라우저에서 페이지가 열린다고 해서 가져올 수 있는 목록이 반환된다는 뜻은 아닙니다. 로그인 페이지, 안내 페이지, 접근 오류도 웹페이지 형태로 표시될 수 있습니다. 이런 페이지의 문구를 서버 정보로 간주해 수동 입력하지 마세요. 서비스 제공업체에 문의할 때는 가져오기 경로, 오류 문구, 발생 단계를 설명하면 됩니다. 캡처를 보낼 경우 주소에 포함된 개인 접근 매개변수를 먼저 가리세요.
기존 구독 업데이트에 실패해도 이전 기록을 유지하고 바로 삭제한 뒤 다시 만들지 마세요. 실패 전후 서버가 그대로 있는지, 선택 항목이 바뀌었는지, 특정 기록만 사용할 수 없는지 비교하세요. 구독 주소가 바뀌었다면 새 기록을 먼저 추가하고 확인한 다음 이전 기록을 처리하세요. 이렇게 하면 되돌릴 방법을 남기고 주소 만료와 서버 자체 장애를 구분할 수 있습니다. 최소 연결 절차를 다시 확인하려면 사용 설명서로 돌아가세요. 원인을 파악하기 전에 모든 설정을 반복해서 바꾸지 마세요.
02 · Add Server: 프로토콜별 입력 항목 확인
수동 추가는 단일 서버의 전체 매개변수를 이미 확보한 경우에 적합합니다. Add Server로 이동해 먼저 Type을 정한 뒤 주소, 포트, 인증 정보를 입력하세요. 프로토콜마다 필요한 항목은 이름만 다른 동일한 매개변수가 아닙니다. 같은 ‘비밀번호’처럼 보여도 다른 프로토콜이 요구하는 UUID, 키 또는 인증 문자열을 대신할 수 없습니다. 필수 항목이 빠졌다면 원본 안내를 다시 확인하세요. 이름이 비슷하다는 이유로 추측하거나, 다른 서버에서 사용할 수 있었던 인증 정보를 복사하지 마세요.
공통 항목을 확인한 뒤 프로토콜별 차이 점검
서버 주소에는 호스트 이름이나 주소만 입력하고 전체 웹 링크를 주소란에 붙여 넣지 마세요. 포트는 제공된 정보에 따라 별도로 입력합니다. 메모는 식별에만 쓰이며 연결 인증에는 사용되지 않습니다. ‘용도, 출처, 전송 특성’ 등을 조합해 이름을 정할 수 있지만 비밀번호를 이름에 넣지는 마세요. 주소가 같아 보여도 포트가 다르면 완전히 다른 서비스일 수 있습니다. 반대로 이름이 다른 두 기록이 실제로 같은 연결 매개변수를 사용할 수도 있으므로 중복 여부는 상세 정보를 확인해야 합니다.
인증 항목은 한 글자씩 대조하세요. 복사 과정에서 공백이나 비슷한 문자가 섞이지 않았는지, 긴 문자열이 메시지 앱에서 잘리지 않았는지 특히 주의해야 합니다. 비밀번호가 화면에서 점으로 표시된다고 복사가 완전하다고 볼 수는 없습니다. 의심되면 원본 기록에서 다시 복사해 붙여 넣으세요. UUID도 일반 메모처럼 임의로 줄 바꿈하거나 서식을 바꾸지 마세요. 주소, 포트, 인증 정보를 모두 확인한 뒤 TLS와 전송 계층을 살펴보세요. 한 번에 여러 항목을 바꾸면 문제를 추적하기 어려워집니다.
| Type | 중점 확인 항목 | 자주 헷갈리는 점 |
|---|---|---|
| Shadowsocks | 주소, 포트, 비밀번호, 암호화 방식 | 암호화 방식은 서버 설정과 일치해야 합니다 |
| VMess / VLESS | UUID, 전송 방식, TLS 및 관련 매개변수 | Type만 바꿔서는 프로토콜을 변환할 수 없습니다 |
| Trojan | 비밀번호, TLS, 서버 이름 | 연결 주소와 TLS 검증 이름은 다를 수 있습니다 |
| HTTP / SOCKS5 | 주소, 포트, 인증 요건 | 인증 필요 여부는 서버 설정을 따릅니다 |
| WireGuard | 키, 주소, 피어 및 라우팅 매개변수 | 키는 일반 비밀번호로 대체할 수 없습니다 |
| Hysteria2 | 인증, TLS, UDP 연결 가능 여부 | 로컬 네트워크 제한이 연결에 영향을 줄 수 있습니다 |
TLS와 전송 계층: 이름이 비슷해도 의미는 다릅니다
연결 주소는 서버를 찾는 데 사용되고, TLS의 서버 이름은 핸드셰이크와 인증서 확인에 사용됩니다. HTTP 전송의 Host는 애플리케이션 계층 라우팅에 쓰일 수도 있습니다. 일부 설정에서는 이 값들이 같지만 언제나 서로 바꿔 쓸 수 있는 것은 아닙니다. 서버 정보에 별도 이름, 경로 또는 전송 방식이 지정되어 있다면 각 항목에 맞게 입력하세요. 경로의 앞쪽 슬래시, 대소문자, 쿼리 부분도 서버에서 식별하는 데 영향을 줄 수 있으므로 읽기 편하게 임의로 줄이지 마세요.
인증서 오류가 나타나면 먼저 서버 이름, 기기 시간, 서버 인증서 상태를 확인하세요. 검증 건너뛰기를 일반적인 해결책으로 사용하지 마세요. 인증서 검증 실패와 비밀번호 오류는 해결 방향이 다릅니다. 전자는 주로 핸드셰이크 신원을 확인하고, 후자는 인증 정보를 점검해야 합니다. 현재 네트워크에서 서버 포트에 접속조차 할 수 없다면 인증 항목을 바꿔도 나아지지 않습니다. 네트워크, 핸드셰이크, 인증, 실제 요청 순서로 확인하면 관련 없는 설정을 반복해서 바꾸는 것보다 유효한 정보를 파악하기 쉽습니다.
저장 후 확인 및 수정 범위
저장하기 전에 Type이 원본 자료와 일치하는지 다시 확인하세요. 저장한 뒤에는 이 서버만 선택해 테스트하고 Config 파일이나 로컬 네트워크를 동시에 바꾸지 마세요. 방금 추가한 항목이 구독에서 생성된 것이라면 먼저 구독 업데이트로 수정된 내용을 가져올 수 있는지 확인하세요. 구독에서 생성된 필드를 직접 바꾸면 다음 업데이트에서 변경 사항이 덮어써질 수 있습니다. 비교 테스트가 필요하다면 수동 기록을 별도로 남기고, 임시 확인용임을 메모에 명확히 적어 구독의 원래 매개변수로 착각하지 않도록 하세요.
수동 입력으로 알 수 없는 매개변수가 자동으로 채워지거나 서버가 해당 조합을 받아들이는지 검증되지는 않습니다. 저장에 성공했다는 것은 입력 형식이 앱에서 허용됐다는 뜻일 뿐입니다. 연결에 실패하면 발생 단계와 오류를 기록한 뒤 필요한 항목을 판단하세요. UUID, 전송 계층, TLS의 관계는 VMess와 VLESS 매개변수 안내를 참고하세요. 프로토콜 이름만 확인하려면 용어집을 살펴보면 됩니다. 처음부터 전체 설정을 바꿀 필요는 없습니다.
03 · QR 코드 및 클립보드: 복사 오류 줄이기
QR 코드와 클립보드는 입력 방식일 뿐, 입력 내용이 구독인지 서버인지 Config인지 결정하지 않습니다. QR 코드에는 단일 서버 링크가 들어 있을 수도 있고 일반 웹 주소만 담겨 있을 수도 있습니다. 클립보드 텍스트도 마찬가지입니다. 가져오기 전에 출처와 용도를 확인하고, 가져온 다음 생성된 기록을 점검하세요. 성공 메시지가 표시돼도 매개변수가 현재 네트워크에 적합하다는 뜻은 아니며 주소, 인증, 전송 설정 확인을 대신하지 않습니다.
QR 코드를 스캔하기 전: 포함된 내용 확인
스캔하기 전에 QR 코드가 보유한 서버 자료에서 나온 것이고 관련 안내와 일치하는지 확인하세요. Scan QR Code를 사용할 때 시스템 안내에 따라 카메라 접근을 허용합니다. 카메라가 열리지 않으면 시스템 설정에서 권한을 확인한 다음 앱으로 돌아와 다시 시도하세요. QR 코드가 다른 기기에 표시되어 있다면 테두리 전체가 보이도록 밝기와 거리를 조절하세요. 반사, 잘린 가장자리, 과도한 압축, 흐릿한 확대는 인식에 방해가 됩니다. 이미지 인식 문제를 서버 매개변수 변경으로 해결하려 하지 마세요.
QR 코드가 현재 기기의 사진에 있다면 앱의 현재 가져오기 메뉴에서 이미지 인식 옵션을 제공하는지 확인하세요. 표시되지 않으면 현재 화면과 맞지 않는 고정 버튼을 찾을 필요는 없습니다. 관련 자료에서 제공한 텍스트 링크를 클립보드로 가져온 뒤 저장하고 항목별로 확인할 수 있습니다. 이미지 인식이 어렵다는 이유로 QR 코드를 공개 인식 사이트에 업로드하지 마세요. QR 코드에는 비밀번호, 키 또는 전체 구독 주소가 들어 있을 수 있으며, 이미지 공개도 텍스트 공개와 비슷한 유출 위험이 있습니다.
클립보드 가져오기: 한 번에 한 종류의 내용만 사용
복사할 때는 원본 자료의 전체 복사 기능을 사용해 시작이나 끝부분이 빠지지 않도록 하세요. Shadowrocket으로 돌아와 현재 화면에서 제공하는 클립보드 가져오기 메뉴를 사용하고, 시스템 안내에 따라 읽기 허용 여부를 선택합니다. 예상한 안내가 나타나지 않으면 클립보드에 방금 복사한 내용이 남아 있는지 확인하세요. 앱을 전환한 뒤 다른 텍스트를 복사하거나 기기 간 클립보드를 사용하거나 이미지를 복사하면 원래 텍스트가 바뀔 수 있습니다.
여러 항목이 포함된 텍스트에는 번호, 글머리 기호, 설명 문단이 섞이기 쉽습니다. 처음에는 확인된 링크 하나만 가져오고 필드가 올바른지 확인한 뒤 나머지를 처리하세요. 여러 줄 텍스트가 인식되지 않으면 링크 내부 문자를 바로 고치기보다 코드 블록, 따옴표, 인용 표시가 포함됐는지 먼저 확인하세요. 형식에 따라 줄바꿈을 해석하는 방식이 다를 수 있습니다. 확실하지 않다면 원본 자료에서 단일 링크를 다시 받아 여러 줄을 억지로 하나의 주소로 합치지 마세요.
가져온 뒤 세 차례 확인
첫 번째로 기록 유형을 확인합니다. 구독을 가져오려 했다면 업데이트 가능한 구독 기록이 있는지, 서버 하나를 가져오려 했다면 해당 서버가 나타났는지 확인하세요. 두 번째로 Type, 주소, 포트를 확인한 다음 인증 및 전송 설정이 완전한지 살펴봅니다. 세 번째로 목록 소속을 확인해 다른 구독이나 중복 테스트 기록에 섞이지 않았는지 점검하세요. 이름이 같아도 가져온 결과가 완전히 같다는 뜻은 아니며, 이름이 달라도 서로 다른 서버라는 뜻은 아닙니다.
QR 코드를 반복해서 스캔해 기록이 여러 개 생겼다면, 검증을 마친 항목 하나는 우선 남겨 두고 나머지를 하나씩 대조한 뒤 정리하세요. 확인하기 전에 기존 기록을 모두 삭제하지 마세요. QR 코드로 항목을 만들었지만 연결되지 않는다면 같은 QR 코드를 계속 스캔하기보다 필드와 네트워크를 점검하세요. QR 인식, 링크 해석, 연결 설정은 서로 다른 단계입니다. 첫 단계를 반복해도 세 번째 단계의 문제는 해결되지 않습니다.
권한도 작업별로 관리해야 합니다. 카메라는 QR 코드 스캔에, 클립보드는 직접 복사한 내용을 읽는 데 사용됩니다. 두 권한은 시스템 VPN 설정 권한과 다릅니다. 가져오기를 마친 뒤 권한을 제한하려면 시스템 설정에서 조정할 수 있으며, 다음에 해당 메뉴를 사용할 때 다시 확인하면 됩니다. 첫 연결과 권한 요청 순서는 사용 설명서를 참고하세요. 기록은 생겼지만 사용할 수 없다면 권한을 계속 초기화하지 말고 연결 문제 해결 단계에 따라 원인을 확인하세요.
05 · 업데이트 방법: 변경 전 복구 경로 확보
구독 업데이트는 원격 콘텐츠를 다시 읽어 로컬 목록을 조정하는 작업입니다. 서버 하나하나를 복구하는 기능이 아니며 현재 사용 중인 서버가 계속 유지된다고 보장하지도 않습니다. 업데이트를 시작하기 전에 현재 선택한 기록, 해당 기록의 구독 소속, 그 이름을 참조하는 Config가 있는지 확인하세요. 업데이트를 통제된 데이터 변경으로 다루고 결과를 확인한 뒤 오래된 항목을 정리하면, 연결 문제 중에 연속으로 새로 고치는 것보다 원인을 파악하기 쉽습니다.
수동 업데이트가 필요한 경우
서비스 정보가 바뀌었거나 예상한 기록이 목록에 없거나 구독이 여전히 읽히는지 확인해야 할 때 직접 업데이트할 수 있습니다. 업데이트 전에 구독 이름과 현재 선택 항목을 기록하고, 업데이트 후 목록에 항목이 추가·삭제되었는지 또는 이름이 바뀌었는지 확인하세요. 앱에 자동 업데이트 설정이 있다면 실제 메뉴에 따라 선택하세요. 특정한 업데이트 주기가 모든 사용자에게 적합하다고 단정하지 마세요. 업데이트 빈도는 주소 이용 규칙과 개인 사용 습관도 고려해야 합니다.
자주 업데이트한다고 연결이 더 안정되는 것은 아닙니다. 원격 목록에 변화가 없다면 반복해서 읽어도 같은 내용이 반환됩니다. 특정 서버 포트에 접근할 수 없다면 업데이트해도 달라지지 않을 수 있습니다. 먼저 장애가 오래된 목록과 관련 있는지 판단한 뒤 업데이트 여부를 정하세요. 수동으로 만든 서버에는 구독 관계가 없으므로 다른 구독을 업데이트해도 함께 수정되지 않습니다. 원본 자료의 매개변수가 바뀌었다면 모든 목록을 반복해서 조작하지 말고 해당 자료의 관리 방식에 맞게 처리하세요.
업데이트 실패 시: 오류를 확인한 뒤 접근 경로 선택
업데이트는 현재 네트워크 경로를 통해 구독 호스트에 접근해야 합니다. 로컬 네트워크에서 직접 연결될 때도 있고, 사용 중인 연결 상태가 접근 결과에 영향을 줄 때도 있습니다. 실패하면 이름 해석 오류, 연결 시간 초과, 인증 실패, 콘텐츠 인식 실패 중 무엇인지 먼저 기록하고 해당 단계를 확인하세요. ‘업데이트 실패’라는 문구만 보고 모든 라우팅 설정을 바꾸지 마세요. 접근 경로를 바꿀 때도 한 번에 하나만 변경한 뒤 다시 시도하고 결과를 확인해야 어떤 단계가 영향을 줬는지 파악할 수 있습니다.
주소에 접근할 수 있지만 로그인 안내, 접근 제한 또는 빈 콘텐츠가 반환된다면 앱의 해석 문제가 아닐 수 있습니다. 구독 주소의 개인 접근 매개변수가 바뀌었거나 원격 서버가 일시적으로 오류 페이지를 반환할 수도 있습니다. 이때는 원래 주소의 비공개 사본을 보관하고 이용 중인 서비스 제공업체에 상태를 확인하세요. 오류 페이지를 Config 파일로 저장하거나 그 안에 주소처럼 보이는 문자열로 서버를 만들지 마세요. 콘텐츠 유형이 잘못된 경우 서버 포트를 바꿔도 소용없습니다.
덮어쓰기·이름 변경·목록 비정상 삭제 대응
구독에서 생성된 기록은 가능한 한 원격 목록과 일치하게 유지하세요. 이런 기록의 인증, 전송 설정, 메모를 직접 바꾸면 다음 업데이트에서 덮어쓰이거나 원본과 차이를 알아보기 어려워질 수 있습니다. 장기 보관이 필요한 별도 테스트는 용도를 명확히 표시한 수동 기록으로 만들고 원래 구독과 분리하는 편이 좋습니다. 그러면 업데이트 후 변경 사항을 원격 콘텐츠와 연결해 추적할 수 있으며 로컬의 임시 변경을 서비스 제공업체가 전달한 매개변수로 착각하지 않습니다.
업데이트 후 목록이 크게 줄거나 안내 문구만 남았다면 추가 정리를 멈추세요. 기존 구독이 남아 있는지, 현재 선택 항목이 사라졌는지, 업데이트 결과가 서비스 정보와 맞는지 확인합니다. 목록을 정상처럼 보이게 하려고 구독 전체를 바로 삭제하지 마세요. 주소와 소속을 추적할 단서도 함께 사라집니다. 주소를 바꿔야 한다면 새 기록을 먼저 만들고 목록 표시와 연결을 확인한 뒤 이전 기록을 처리하세요. 기존 인증 정보가 만료됐다면 개인 백업에도 함께 표시하세요.
앱 업데이트, 구독 업데이트, Config 업데이트를 구분하세요. 앱 업데이트는 App Store에서 진행하고, 구독 업데이트는 서버 목록을 읽으며, Config 변경은 규칙과 관련 설정에 영향을 줍니다. 세 가지가 비슷한 시기에 이뤄질 수 있지만, 하나가 다른 작업까지 자동으로 처리한다고 볼 수는 없습니다. 문제를 확인할 때는 막연히 ‘업데이트 후 안 된다’고 하기보다 무엇을 업데이트했고 전후 상태가 어땠는지 기록하세요. 앱 구입 및 업데이트 메뉴는 App Store 다운로드 가이드를 참고하세요.
06 · 여러 구독 정리: 출처를 유지한 뒤 중복 이름 처리
여러 구독을 관리할 때 우선할 일은 목록을 최대한 짧게 만드는 것이 아니라 각 서버의 출처를 분명히 하는 것입니다. 이름이나 지역 안내가 같거나 지연 시간이 비슷하다고 두 기록이 중복이라고 단정할 수 없습니다. 하나의 구독에 포함된 여러 서버도 주소만 같고 포트, 인증, 전송 설정이 다를 수 있습니다. 정리하기 전에 구독별 소속을 살펴보고 연결 매개변수를 대조해 용도가 다른 기록을 잘못 삭제하지 않도록 하세요.
계속 사용하기 좋은 이름 규칙 만들기
구독 메모에는 ‘일상’, ‘예비’, ‘테스트’처럼 꾸준히 사용할 내부 태그를 쓰고, 출처를 알아볼 수 있는 짧은 이름을 덧붙일 수 있습니다. 이름은 용도를 구분하는 데 사용하고 비밀번호, 전체 구독 주소, 개인 신원 정보는 넣지 마세요. 서버 이름은 원격에서 지정되는 경우 업데이트 후 바뀔 수 있으므로 이름만으로 중요한 기록을 기억하지 마세요. 자주 사용하는 서버는 소속 구독과 주요 연결 특성도 따로 기록하면 기기를 옮길 때 확인하기 쉽습니다.
목록을 깔끔하게 보이게 하려고 구독에서 생성된 모든 항목의 이름을 반복해서 바꾸지 마세요. 업데이트로 이름이 덮어써지거나 이름을 참조하는 Config 관계가 깨질 수 있습니다. 구독 계층을 먼저 정리하고 원래 서버 이름은 유지하는 편이 낫습니다. 테스트가 필요하면 별도의 수동 기록에 임시 설명을 남기세요. 이름에 지역이나 회선 표시가 있어도 제공업체가 붙인 표기일 뿐, 실제 서버 위치나 성능, 현재 사용 가능 여부를 뜻하지는 않습니다.
중복 확인 시 비교할 정보
먼저 Type, 주소, 포트를 비교한 다음 인증, TLS 이름, 전송 방식과 관련 매개변수를 확인하세요. 모든 정보가 같은 기록은 중복으로 가져온 것일 수 있지만, 서로 다른 업데이트 관계에 속하는지도 확인해야 합니다. 두 구독에 우연히 같은 서버가 포함되어 있다면 구독 하나를 삭제할 때 해당 출처의 향후 변경 정보도 함께 잃을 수 있습니다. 어떤 기록을 유지할지는 현재 목록의 중복 여부만 보지 말고 자신의 관리 방식에 따라 결정하세요.
이름이 중복되면 기억에 의존해 여러 항목을 먼저 삭제한 뒤 다시 만들지 마세요. 구독 하나씩 선택해 항목 특성을 기록하고 대조를 끝낸 다음 다음 구독으로 넘어갈 수 있습니다. 실패했지만 원인을 추적해야 하는 기록은 비공개 메모를 먼저 남기고 삭제 여부를 결정하세요. 목록의 상태 안내도 별도로 확인해야 합니다. 계정이나 이용 상태를 나타낼 수 있으므로 모두 ‘연결할 수 없는 서버’로 취급하지 말고, 실제 서버 전체를 사용할 수 없다고 추측해서도 안 됩니다.
| 확인된 상황 | 먼저 확인 | 그다음 결정 |
|---|---|---|
| 이름이 완전히 동일함 | 소속, Type, 주소, 포트 | 서로 다른 서버인지 여부 |
| 매개변수가 같아 보임 | 인증, 전송, 업데이트 관계 | 두 출처를 모두 유지할 필요가 있는지 |
| 업데이트 후 이름이 중복됨 | 원격 변경과 기존 수동 기록 | 테스트용 사본을 정리할지 여부 |
| 특정 테스트 실패 | 테스트 방식과 네트워크 조건 | 삭제 대신 임시 보관할지 여부 |
목록 정리는 라우팅 변경과 다릅니다
순서 이동, 메모 수정, 중복 항목 삭제는 주로 관리 방식만 바꿉니다. 실제 요청 처리는 Global Routing과 현재 Config의 영향도 받습니다. 서버가 목록 맨 앞에 있다고 해서 모든 요청이 그 서버를 사용한다는 뜻은 아닙니다. Config를 사용할 때 DIRECT에 일치하는 요청은 규칙에 따라 직접 연결됩니다. Proxy를 선택한 경우에도 현재 선택된 서버가 사용하려는 항목인지 확인해야 합니다. 목록 정리를 마친 뒤에는 선택 상태를 다시 확인하세요.
여러 구독이 함께 있다고 해서 앱이 모든 항목 중에서 자동으로 최적 서버를 선택하는 것은 아닙니다. 자동 선택이나 전환 기능이 있는지는 현재 설정과 관련 기능을 확인해야 하며 목록의 개수만으로 판단할 수 없습니다. 결과를 명확하게 확인하려면 먼저 서버 하나를 분명히 선택해 테스트한 뒤 더 복잡한 선택 방식을 검토하세요. 테스트 실패 항목을 여러 구독에 계속 복사하지 마세요. 중복 기록만 늘고 서버 측 상태는 바뀌지 않습니다.
정리를 마칠 때는 간단히 마무리 점검을 하세요. 구독 주소가 저장되어 있는지, 중요한 서버를 알아볼 수 있는지, 현재 선택 항목이 맞는지, 별도 테스트 기록에 명확한 표시가 있는지 확인합니다. 기기를 바꿀 예정이라면 필요한 Config와 업데이트 관계도 기록하세요. 한꺼번에 모두 비우기보다 적은 양씩 나눠 정리하는 편이 복구하기 쉽습니다. 용어가 헷갈리면 용어집을 먼저 확인하고, 첫 연결 관련 문제는 사용 설명서의 문제 해결 장을 참고하세요. 이해 대신 삭제를 선택하지 마세요.
07 · Connectivity Test: 지연 시간과 정렬 결과 이해
지연 시간 테스트는 서버 응답을 초기에 비교하는 데 유용하지만 실제 처리량, 장기 안정성, 특정 웹사이트 접속 결과를 단독으로 판단하기에는 적합하지 않습니다. 테스트 방식마다 측정 단계가 다릅니다. 주소나 포트의 연결 가능 여부를 주로 확인하는 방식도 있고 더 많은 요청 과정을 포함하는 방식도 있습니다. Connectivity Test의 현재 설정을 확인해 무엇을 측정하는지 파악한 뒤 결과를 해석하세요. 수치가 낮다고 인증이 올바르거나 이후 전송이 계속 완료된다는 보장은 없습니다.
테스트 전 조건을 고정하고, 테스트 후 맥락을 기록
서버 여러 대를 비교할 때는 같은 로컬 네트워크와 같은 테스트 방식, 비슷한 시간대를 사용하세요. 테스트 도중 Wi-Fi에서 셀룰러 네트워크로 바꾸면 접속 네트워크의 변화가 결과에 섞입니다. 기기의 백그라운드 작업, 신호 변동, 네트워크 혼잡도 결과에 영향을 줄 수 있습니다. 처음에는 후보 서버를 몇 개만 골라 반복해서 확인한 뒤 범위를 넓히세요. 순간적인 결과를 영구적인 순위로 간주하거나 낮은 수치를 얻으려고 관계없는 설정을 계속 바꾸지 마세요.
여러 항목을 동시에 테스트하면 요청도 한꺼번에 발생합니다. 로컬 네트워크나 원격 처리 능력이 제한적이면 단일 테스트보다 결과가 불안정해질 수 있습니다. 단일 테스트는 정상인데 일괄 테스트에서 가끔 실패한다면 범위를 줄여 다시 확인하세요. 모든 기록이 동시에 실패하면 서버 전체가 중단됐다고 단정하기보다 기기 네트워크 연결, 테스트 대상의 적합성, 테스트 방식의 제한 여부부터 확인하세요.
시간 초과·인증 실패·실제 요청 오류 구분
시간 초과는 정해진 대기 시간 안에 예상한 결과를 받지 못했다는 뜻이지만, 원인을 직접 알려주지는 않습니다. 주소 해석, 포트 접근, 전송 핸드셰이크, 테스트 대상의 응답 문제일 수 있습니다. 명확한 인증 오류가 있을 때 비밀번호, UUID 또는 다른 인증 정보를 우선 확인하세요. 서버 연결은 성립했지만 특정 웹사이트만 실패한다면 규칙 매칭, 대상 도메인, DNS, TLS를 추가로 살펴봐야 합니다. 지연 시간 수치만 계속 조정해서는 안 됩니다.
실제 사용을 확인하려면 익숙하고 접근이 허용된 일반 페이지를 선택해 페이지가 끝까지 열리는지, 연속 요청이 안정적인지, 문제가 특정 대상에서만 발생하는지 각각 살펴보세요. 시스템에 연결됨으로 표시된다는 이유만으로 점검을 끝내지 마세요. 시스템 상태는 로컬 연결 기능이 활성화됐다는 뜻일 뿐, 모든 원격 요청의 성공을 보장하지 않습니다. 캐시된 페이지 하나만 보고 네트워크가 정상이라고 판단하지 말고 새 요청과 앱에서 확인할 수 있는 연결 정보를 함께 살펴보세요.
정렬은 선별을 돕지만 선택과 검증을 대신하지 않습니다
지연 시간순으로 정렬한 뒤 어떤 목록에 정렬이 적용됐는지, 현재 선택 항목이 바뀌었는지 확인하세요. 목록 순서가 바뀌어도 연결 대상이 바뀌었다는 뜻은 아니며 맨 위 항목이 모든 요청에 적합하다는 보장도 없습니다. 응답이 안정적인 후보 몇 개 중 하나를 선택해 실제로 확인한 다음 예비 항목 하나를 남겨 두세요. 특정 결과를 고정된 성능 등급으로 기억하기보다 당시의 네트워크 조건을 함께 기록하는 편이 유용합니다.
Global Routing도 접속 결과를 해석하는 방식에 영향을 줍니다. Config를 사용하면 대상이 DIRECT에 일치할 수 있으므로 페이지가 정상적으로 열린다고 해서 선택한 서버가 사용 가능하다는 뜻은 아닙니다. 특정 프록시 연결을 확인하려면 테스트 대상에 실제로 적용된 정책도 확인해야 합니다. 라우팅 방식을 전환할 때는 확인 범위를 명확히 하고 테스트가 끝난 뒤 필요한 설정으로 되돌리세요. 임시 설정을 잊으면 이후 모든 요청 처리 방식이 달라질 수 있습니다.
속도 저하와 높은 지연 시간은 관련이 있지만 같은 문제는 아닙니다. 작은 요청에 빠르게 응답해도 지속 전송 중 회선 혼잡, 패킷 손실, 서버 부하, 로컬 네트워크의 영향을 받을 수 있습니다. 먼저 서버 하나를 다시 확인하고 다른 시간대와 접속 네트워크를 비교한 뒤 프로토콜과 전송 설정을 점검하세요. 각 단계의 이전 결과를 남겨 두세요. 자세한 단계별 점검 방법은 Shadowrocket 속도 저하 4단계 문제 해결을 참고하세요. 구독을 계속 새로 고치는 것으로 이 확인 과정을 대신하지 마세요.
08 · 삭제 및 백업: 복구 범위 명확히 하기
삭제하기 전에 대상이 서버 하나인지, 구독 전체인지, Config 파일인지 확인하세요. 세 대상은 영향 범위가 다릅니다. 서버 하나를 삭제하면 현재 목록만 바뀔 수 있고, 구독을 삭제하면 관리 관계까지 사라질 수 있으며, Config를 삭제하면 규칙 선택에 영향을 줄 수 있습니다. 실제 연결 동작은 앱에 표시되는 현재 안내를 기준으로 확인하세요. 백업과 확인 없이 여러 계층을 연달아 삭제하지 말고, 목록 비우기를 모든 연결 문제의 공통 해결책으로 삼지 마세요.
스크린샷 한 장이 아니라 백업 목록을 준비
백업에는 복원해야 하는 구독 주소, 별도로 추가한 서버의 매개변수, 현재 사용하는 Config, 중요한 환경 설정에 대한 설명이 최소한 포함되어야 합니다. 스크린샷은 화면을 알아보는 데 도움이 되지만 전체 비밀번호, 키, 긴 주소가 보이지 않는 경우가 많아 원본 자료를 대신할 수 없습니다. 구독은 목록을 다시 읽을 수 있는 주소를 보관하고, 수동 서버는 인증과 전송 세부 정보까지 빠짐없이 남겨야 합니다. 이름과 포트만 기록하면 복원할 수 없습니다.
앱에 내보내기나 백업 메뉴가 있다면 내보내기 대상과 포함 범위를 확인한 뒤 직접 관리하는 비공개 장소에 저장하세요. 파일 이름에 ‘백업’이라고 적혀 있어도 모든 자료가 포함되는 것은 아니며 기기 백업이 필요한 항목을 모두 보존한다고 단정할 수도 없습니다. 기존에 사용할 수 있는 환경을 손상시키지 않으면서 파일 내용을 확인하거나 통제된 복원 테스트를 진행해 중요한 구독 관계와 별도 기록을 실제로 되찾을 수 있는지 확인하는 편이 확실합니다.
삭제한 항목이 다시 나타나는 이유
구독에서 생성된 서버는 원격 목록으로 관리됩니다. 그중 하나만 삭제한 뒤 다음에 업데이트하면 같은 기록이 다시 만들어질 수 있습니다. 삭제에 실패했다는 뜻이 아니라 원격 콘텐츠가 다시 동기화된 결과일 수 있습니다. 구독이 더 이상 필요하지 않다면 주소가 안전하게 보관되어 있는지, 현재 연결이 그 구독에 의존하지 않는지 확인한 뒤 구독 기록을 처리하세요. 서버를 잠시 사용하지 않으려는 것이라면 선택 항목을 바꾸는 것과 기록을 삭제하는 것은 다르므로 즉시 정리할 필요는 없습니다.
삭제 전에 현재 사용하는 Config가 특정 서버 이름이나 선택 관계를 참조하는지 확인하세요. 기록 하나를 제거해도 기존 규칙이 동등한 대상을 자동으로 찾아 주는 것은 아닙니다. 삭제 후 Global Routing, 현재 Config, 선택 서버를 다시 확인하고 실제 요청을 테스트하세요. 목록에 갑자기 이상이 생기면 추가 작업을 멈추고 로컬 백업이나 원본 구독으로 복구할 수 있는지 확인하세요. 같은 문제 해결 과정에서 남은 단서까지 없애지 않도록 주의하세요.
기기 변경 후 복원: 적은 항목부터 확인하고 나머지 복구
새 iPhone 또는 iPad에서는 먼저 App Store에서 앱을 복원하고 필요한 시스템 권한을 확인하세요. 시스템 요구 사항과 구매 적용 여부는 App Store 페이지에 표시된 내용을 기준으로 합니다. 앱 구입 복원과 구독, 서버, Config 복원은 별개의 작업입니다. 앱을 다시 받았다고 연결 자료까지 모두 나타나는 것은 아닙니다. 구체적인 설치 단계는 구입 항목 복원 안내를 참고하세요. 이전 기기를 먼저 초기화하지 말고 항목을 대조하고 되돌리는 기준으로 보관하세요.
자료를 복원할 때는 구독 하나를 먼저 가져와 목록이 펼쳐지는지 확인하고, 그다음 별도 수동 기록을 복원한 뒤 필요한 Config를 선택해 Global Routing을 확인하세요. 연결 테스트를 한 차례 마친 다음 나머지 구독과 환경 설정을 복원합니다. 이 순서를 따르면 오류가 생겼을 때 어느 단계에서 변화가 들어왔는지 파악하기 쉽습니다. 처음부터 모든 자료를 복원하고 네트워크와 규칙까지 바꾸면 작업은 빠를 수 있지만, 백업 자료와 새 기기 환경 중 무엇이 원인인지 판단하기 어렵습니다.
복원을 마친 뒤 선택 항목, 구독 업데이트, 테스트 방식, 실제 요청을 확인하고 이전 자료의 처리 방법을 결정하세요. 구독 주소나 인증 정보가 공개됐다고 의심되면 이용 중인 서비스 제공업체에서 새 정보를 받아 백업에도 반영하세요. 로컬 사본을 삭제해도 이미 노출된 인증 정보가 무효화되지는 않습니다. 마지막으로 자료 유형과 복원 순서만 적은 간단한 비공개 복구 안내를 보관하고 민감한 값은 공개 메모에 저장하지 마세요. 다음에 빠르게 다시 연결해야 한다면 사용 설명서에 따라 기본 절차를 확인하고, 이 페이지에서 입력 항목과 관리 세부 사항을 찾아보세요.