Shadowrocket 구독 및 서버 관리

정보를 확인한 뒤 가져오기 경로 선택

서버 목록을 반환하는 구독 주소가 있다면 Subscribe를 찾으세요. 단일 서버의 Address, Port, 인증 정보만 있다면 다음 장의 Add Server를 이용하세요. 두 기능의 차이는 연결 성능이 아니라 정보를 관리하는 방식입니다. 구독은 보통 하나의 주소에서 여러 서버 항목을 가져오고, 나중에 목록을 다시 불러올 수 있습니다. 직접 입력한 항목은 각 필드를 직접 저장하며 수정할 때도 하나씩 확인해야 합니다. 단일 서버 공유 링크를 구독 주소란에 넣거나 구독 페이지 주소를 서버의 Address로 입력하면 이후 문제를 파악하기 어려워집니다.

Shadowrocket을 연 뒤 Config 및 서버 관리 관련 메뉴에서 Subscribe를 찾으세요. 화면 크기와 앱 내 배열에 따라 메뉴 위치가 다를 수 있으므로 현재 앱에 표시된 위치를 기준으로 합니다. 작업 전에 복사한 주소가 완전한지 확인하세요. 특히 경로, 쿼리 매개변수, 마지막 문자가 빠지지 않았는지 살펴보세요. 형식 확인용 가상 주소는 아래처럼 쓸 수 있습니다. 이는 예시일 뿐 실제 정보를 제공하지 않습니다. 실제 주소는 민감 정보이므로 공개 게시판, 스크린샷 또는 문의 내용에 올리지 마세요.

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

저장 후 결과를 세 단계로 확인

Subscribe에 보유 중인 주소를 입력하고 현재 화면 안내에 따라 저장하거나 업데이트하세요. 첫째, 구독 항목이 목록에 표시되는지 확인합니다. 둘째, 업데이트 후 서버 항목이 생성되는지 확인합니다. 셋째, 서버 항목을 선택한 뒤 연결이 되는지 확인합니다. 이 세 결과는 서로 대체할 수 없습니다. 구독 이름이 표시되어도 내용이 정상적으로 파싱됐다는 뜻은 아니며, 서버 이름이 표시되어도 매개변수가 유효하다는 뜻은 아닙니다. 처음 가져온 뒤에는 항목 수와 이름이 보유한 정보와 일치하는지 확인하세요. 그런 다음 항목 하나를 열어 Type, Address, Port를 살펴보고 마지막으로 연결을 테스트하세요.

목록이 비어 있다면 먼저 원본 텍스트를 확인해 줄바꿈이나 앞뒤 공백이 들어갔는지, 주소 일부만 복사하지 않았는지 살펴보세요. 앱에 가져오지 못했다는 안내가 표시되면 기기에서 해당 주소에 접근할 수 있는지 확인하고, 보유한 자료를 관리하는 곳에서 주소를 계속 제공하는지도 확인하세요. 같은 이름의 항목이 남아 구분하기 어려워질 수 있으니 곧바로 삭제와 추가를 반복하지 마세요. 내용을 가져왔지만 파싱할 수 없다면 ‘가져오기 실패’와 ‘파싱 실패’를 서로 다른 단서로 기록하세요. 전자는 주소와 네트워크 접근성, 후자는 반환된 내용과 형식에 더 관련이 있습니다. 자세한 확인 순서는 구독 업데이트 실패 자가 점검 목록을 참고하세요.

구독 항목과 서버 항목의 관계

구독은 이후 업데이트를 위한 경로이고, 서버 항목은 선택해 사용할 수 있는 결과입니다. 업데이트 후 항목 이름, 순서, 개수가 바뀌었다고 해서 앱에서 직접 입력한 설정이 변경됐다고 단정할 수는 없습니다. 먼저 변경된 내용이 같은 구독에서 나온 것인지 확인하고, 현재 선택한 서버가 목록에 남아 있는지 살펴보세요. 구독에서 제공하는 내용은 본인이 보유한 자료에 따라 달라지며, Shadowrocket은 전달받은 내용을 표시하고 관리합니다. 장기간 유지할 직접 설정이 다음 구독 업데이트에서 덮어써질 수 있는지 먼저 확인하세요. 업데이트로 생성된 항목을 영구히 고정된 로컬 초안처럼 취급하지 마세요.

처음에는 내용을 알아볼 수 있는 구독 하나만 가져오는 것을 권장합니다. 표시 이름과 업데이트 전후의 항목 변화를 확인하고 테스트 결과를 한 번 기록하세요. 이는 구독 개수를 제한하려는 것이 아니라 문제 발생 시 원인을 추적할 기준을 만들기 위한 것입니다. 여러 구독을 한꺼번에 추가한 뒤 목록이 비어 있으면 어떤 주소나 업데이트가 원인인지 파악하기 어렵습니다. 이미 여러 항목이 있다면 여러 구독 정리로 이동해 이름과 확인 순서를 정리하세요.

보유한 정보를 기준으로 Type 선택

Add Server는 단일 서버의 전체 매개변수를 이미 보유한 경우에 사용합니다. 먼저 자료와 일치하는 Type을 선택하고, 해당 Type에 표시되는 항목을 입력하세요. 프로토콜을 짐작으로 선택한 뒤 서로 다른 프로토콜의 매개변수를 한 양식에 억지로 넣지 마세요. Shadowsocks, VMess, VLESS, Trojan 등은 프로토콜 유형이며, 구체적인 입력 항목은 선택한 Type과 앱 내 옵션에 따라 달라집니다. 가장 확실한 확인 방법은 보유한 자료와 현재 양식을 나란히 놓고 항목 이름, 형식, 스위치 상태를 하나씩 대조하는 것입니다. 자료에 없는 값은 추측해 입력하지 마세요.

기본 항목과 추가 항목 이해하기

Address는 원격 서버를 가리키고 Port는 해당 서버가 제공하는 접속 포트입니다. Remark는 목록에서 항목을 식별하는 데 쓰입니다. Password, UUID, 암호화 방식, TLS, SNI 등의 항목이 표시되는지와 조합 방법은 선택한 Type 양식 및 보유한 자료에 따라 다릅니다. 예를 들어 Trojan 정보는 Password와 TLS 관련 항목을 확인해야 하는 경우가 많고, VMess 및 VLESS 정보에는 보통 UUID와 전송 설정도 포함됩니다. 비슷한 이름의 항목이 보인다고 해서 두 Type 사이에 설정 전체를 그대로 복사할 수 있는 것은 아닙니다. 차이는 Trojan 항목 설명과 VMess와 VLESS 입력 항목의 차이에서 확인하세요.

직접 입력할 때는 인증 정보가 노출되지 않는 항목부터 확인하세요. 먼저 Type, Address의 문자, Port의 숫자를 살펴보고 프로토콜별 항목을 대조한 뒤 Remark를 입력합니다. 저장한 다음 항목을 다시 열어 키보드의 자동 수정, 복사 과정의 공백, 양식 전환으로 내용이 바뀌지 않았는지 확인하세요. 예시에 나온 example.com, 443, your-password는 형식을 보여 주기 위한 가짜 값이며 본인 정보 대신 사용할 수 없습니다. Password, UUID, 개인 키와 같은 정보는 공개 스크린샷에 포함하지 마세요.

저장만으로 검증이 끝나는 것은 아닙니다

Add Server 항목이 저장됐다는 것은 현재 입력값이 양식에 받아들여졌다는 뜻일 뿐입니다. 다음으로 목록에서 항목을 선택해 필요에 따라 연결 상태와 테스트 결과를 확인하세요. 테스트에 실패하면 먼저 Type과 입력 항목의 대응 관계를 살펴보고, 자료에 추가 전송 또는 인증 요구사항이 있는지 확인하세요. 여러 항목을 한꺼번에 바꾸지 마세요. 의심되는 항목 하나만 명확하게 수정하고 저장한 뒤 다시 테스트해야 어떤 변경이 영향을 줬는지 알 수 있습니다. 보유한 자료만으로 판단하기 어렵다면 원본 항목의 스크린샷이나 민감 정보가 아닌 필드 메모를 보관한 뒤 자료 관리 담당자에게 문의하세요. 추측을 장기 설정으로 저장하지 마세요.

직접 입력한 항목은 별도로 관리할 수 있으며 구독에 있는 서버 항목의 매개변수를 대조하는 기준으로도 사용할 수 있습니다. 다만 두 항목이 같은 기록이라고 간주하지 마세요. 구독 업데이트로 구독 아래의 서버 항목이 바뀔 수 있지만, 직접 입력한 항목은 보통 직접 수정해야 합니다. 목록에 이름이 비슷한 구독 항목과 직접 입력 항목이 함께 있다면 출처와 메모를 확인한 뒤 어느 항목을 유지할지 결정하세요. 다음 장에서는 QR 코드와 클립보드 가져오기를 설명합니다. 입력 방식은 달라지지만 이 장의 항목 확인 절차는 여전히 필요합니다.

QR 코드를 스캔하기 전에 담긴 내용 확인

QR 코드 스캔은 보유한 정보를 앱에서 읽도록 전달하는 방법이지, 별도의 서버 프로토콜이 아닙니다. QR 코드에는 단일 서버 공유 링크나 구독 주소가 담길 수 있습니다. 스캔 후 만들어진 결과는 각각 Add Server 또는 Subscribe의 방식으로 확인해야 합니다. Shadowrocket에서 Scan QR Code 등의 스캔 메뉴를 찾을 때는 현재 앱에 표시된 이름과 위치를 기준으로 하세요. 카메라로 스캔하기 전에 가져오려는 정보가 담긴 QR 코드인지 확인하세요. 주변에 표시된 서버 이름만 보고 내용을 판단하지 마세요. 스캔한 뒤 앱이 인식한 Type, 주소 또는 구독 항목을 확인한 다음 저장 여부를 결정하세요.

같은 iPhone에서 확인 중인 QR 코드는 해당 기기의 카메라로 다시 스캔하기 어려울 수 있습니다. 이때는 현재 앱에서 이미지 인식 또는 클립보드 읽기 기능을 제공하는지 확인하세요. 표시되는 옵션은 화면에 따라 다를 수 있으므로 특정 버튼 위치를 고정된 경로로 생각하지 마세요. 다른 기기에 QR 코드가 표시되어 있다면 카메라로 인식할 수 있습니다. 이 기기에 저장된 이미지라면 먼저 이미지가 선명하고 잘리지 않았는지 확인한 뒤 앱에서 제공하는 인식 방법을 사용하세요. 인식에 실패하면 QR 코드 가장자리가 잘리지 않았는지 확인하고, 코드에 앱이 처리할 수 있는 텍스트 형식이 담겼는지 살펴보세요. 웹 페이지로 연결되는 주소만 담겼을 수도 있습니다.

클립보드 입력 시 불필요한 문자 확인

클립보드 가져오기는 완전한 공유 링크나 구독 주소를 이미 복사한 경우에 적합합니다. 복사할 때는 대상 텍스트만 선택하고 설명, 따옴표, 글머리 기호가 함께 복사되지 않도록 하세요. 앱에 클립보드 인식 기능이 있다면 미리 보기를 확인할 수 있습니다. 알맞은 메뉴가 없다면 내용 유형에 따라 Subscribe 또는 해당 Add Server 항목에 직접 붙여 넣으세요. 복사만으로 항목이 자동 생성된다고 생각하지 말고, 붙여 넣은 뒤 확인 없이 바로 연결하지 마세요. 일부 메시지 앱은 화면에 표시되는 링크를 줄여 보여 줄 수 있으므로 클립보드에 전체 내용이 들어 있는지 별도로 확인해야 합니다.

인식에 성공한 뒤에는 ‘무엇을 가져왔는지’를 확인하세요. 서버 항목이 표시되면 Type, Address, Port, 인증 항목, Remark를 확인합니다. 구독 주소가 표시되면 Subscribe 항목으로 저장됐는지 확인하고 업데이트한 뒤 서버 목록을 살펴보세요. QR 코드와 클립보드는 입력 수단일 뿐 정보가 완전한지 판단해 주지 않습니다. 특히 QR 코드에 여러 줄의 텍스트가 담겨 있으면 앱이 처리할 수 있는 일부만 인식할 수 있습니다. 결과가 예상과 다르다면 인식된 일부 항목에 추측으로 정보를 보충하지 말고 원본 텍스트를 다시 확인하세요.

가져오기에 실패했을 때의 대처 방법

QR 코드를 스캔해도 결과가 없으면 화면, 밝기, 카메라 권한을 확인한 다음 코드에 보유 중인 구독 주소나 서버 공유 텍스트가 실제로 담겼는지 살펴보세요. 클립보드에서 결과가 없으면 복사한 내용을 기기의 일반 텍스트 입력란에 붙여 넣어 첫 글자와 마지막 글자를 확인하세요. 공백, 줄바꿈, 설명 문단이 없는지 확인한 뒤 앱으로 돌아가 다시 시도합니다. 텍스트 자체가 불완전하면 입력 경로를 바꿔도 누락된 항목은 채워지지 않습니다. 내용이 완전하지만 인식되지 않는다면 다음 장의 형식 확인을 참고해 구독 URL, 단일 서버 링크, 직접 입력해야 하는 매개변수 목록인지 구분하세요.

가져온 직후 QR 코드를 여러 번 반복해서 스캔하지 마세요. 중복 항목은 같은 Remark로 표시되더라도 입력한 시점이 다를 수 있어 연결할 때 어느 항목을 선택했는지 파악하기 어려워집니다. 새 항목을 열어 출처를 확인하고 같은 주소와 매개변수의 항목이 이미 있는지 살펴보세요. 기존 구독을 업데이트하려는 경우 같은 QR 코드를 계속 스캔하지 말고 해당 구독의 업데이트 기능을 사용하세요. 중복 항목을 정리해야 한다면 마지막 장의 저장 및 삭제 전 확인 절차를 먼저 따르세요. 네 가지 입력 경로의 비교는 서버 추가 방법 네 가지에서 확인할 수 있습니다.

링크가 목록을 가리키는지 단일 항목을 가리키는지 확인

구독 주소는 보통 앱이 요청해 파싱 가능한 서버 목록을 가져오는 웹 형식의 URL입니다. 서버 공유 링크는 대개 단일 서버의 매개변수를 텍스트에 인코딩해 앱에서 항목을 만들도록 합니다. 두 형식 모두 복사하거나 QR 코드에 담을 수 있지만 같은 입력란에 넣어서는 안 됩니다. https://로 시작하는지만 보고 판단하지 마세요. 구독 주소일 수도 있고 설명 페이지일 수도 있습니다. 더 확실한 단서는 보유한 자료에 적힌 용도 설명과 Shadowrocket 가져오기 미리 보기입니다. Subscribe 항목 하나가 표시되는지, 단일 서버의 Type과 매개변수가 표시되는지 확인하세요.

공유 링크에는 프로토콜 식별자와 인코딩된 인증 정보가 포함되는 경우가 많습니다. Shadowsocks, VMess, VLESS, Trojan에 해당하는 링크 형식을 볼 수 있지만 화면에서 모든 항목을 바로 읽을 수 있는 것은 아닙니다. 링크 끝에는 표시 이름을 위한 메모가 붙을 수도 있으며 이를 인증 정보로 착각하지 마세요. 인코딩된 텍스트를 ‘이해하기’ 위해 대소문자, 문장 부호, 퍼센트 문자를 임의로 바꾸지 마세요. 파싱에 영향을 줄 수 있습니다. 가져온 뒤 항목을 확인할 수 있다면 앱에서 결과를 대조하세요. 매개변수를 수정할 때는 잘린 공유 텍스트로 추측하지 말고 보유한 자료에 명시된 값을 사용하세요.

읽기 쉬운 예시로 구독 URL 이해하기

아래 주소는 URL 구조만 보여 줍니다. 호스트 이름, 경로, 쿼리 매개변수는 모두 예시입니다. 경로도 주소의 일부이고 쿼리 매개변수가 반환 내용에 영향을 줄 수 있으므로 복사할 때 전체 문자열을 보존하세요. 실제 구독 주소에는 민감한 식별 정보가 들어 있을 수 있습니다. 다른 사람에게 문제를 설명할 때는 전체 주소를 올리지 말고 ‘주소는 열리지만 파싱 결과가 비어 있다’처럼 현상만 적으세요. 형식 확인용 가짜 값으로 실제 주소의 접근 가능성을 입증하거나 연결을 테스트할 수는 없습니다.

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

보유한 자료에 Address, Port, Password 및 기타 매개변수의 항목별 목록만 있고 공유 링크나 구독 URL이 없다면 Add Server에 직접 입력하세요. 반대로 완전한 구독 URL이 있다면 URL을 Address와 Port로 나눌 필요가 없습니다. 구독 페이지가 있는 호스트는 목록에 포함된 각 서버의 Address가 아닙니다. 두 주소의 차이를 구분하는 것이 중요합니다. 구독 호스트를 서버 항목에 입력하면 겉보기에는 완전하지만 예상대로 작동하지 않는 기록이 만들어질 수 있습니다.

형식 호환성 및 파싱 범위

자료마다 인코딩과 항목 조합이 다를 수 있으므로 실제 인식 가능 형식은 현재 Shadowrocket의 가져오기 결과를 기준으로 판단하세요. 앱이 Type을 인식한 뒤에도 추가 항목이 빠짐없이 들어왔는지 확인하세요. 특히 전송, TLS, 인증 설정을 살펴봐야 합니다. 공유 링크 두 개에 같은 프로토콜이 표시되더라도 전송 매개변수까지 같다는 뜻은 아닙니다. 가져온 뒤 항목이 누락됐다면 원문이 완전한지 먼저 확인하고 자료에 해당 항목이 명시되어 있는지 살펴보세요. 다른 서버의 값을 복사해 억지로 채우지 마세요. 링크 파싱에 실패하면 실패 안내와 민감 정보를 제거한 형식 정보를 보관해 ‘텍스트 누락’, ‘가져오기 경로 오류’, ‘현재 형식에서 지원하지 않는 항목’을 하나씩 확인하세요.

본인 자료를 공유하거나 전달할 때 링크만으로도 서버 항목을 복원할 수 있는 경우가 많다는 점을 기억하세요. QR 코드, 클립보드 기록, 전체 주소가 담긴 스크린샷을 공개하면 인증 정보도 함께 노출될 수 있습니다. 두 항목이 같은지 비교하려면 기기에서 Type, 메모, 인증 정보가 아닌 항목을 확인하세요. 다른 사람에게 문제를 설명할 때는 example.com, your-password처럼 명백한 가짜 값을 사용하세요. 원본 텍스트를 노출하지 않고도 문제가 Subscribe, 공유 링크 파싱, Add Server 직접 입력 중 어디에서 발생했는지 설명할 수 있습니다.

업데이트는 구독 내용을 다시 가져오는 작업

Subscribe에서 업데이트를 실행하면 앱이 해당 주소에서 현재 제공하는 정보를 다시 가져옵니다. 모든 서버를 ‘가속’하거나 잘못된 매개변수를 자동으로 고치는 작업은 아닙니다. 업데이트 후 반환 내용에 따라 목록의 이름, 개수, 항목이 달라질 수 있습니다. 기존 구독에 일시적으로 접근할 수 없다면 앱 안내와 현재 목록 상태를 먼저 확인하고 기존 서버가 영구히 사용할 수 없게 됐다고 단정하지 마세요. 시작 전에 현재 선택한 항목과 구독 이름을 기록하세요. 업데이트 후 예상한 변화와 실제 결과를 비교하고 연결을 테스트해야 콘텐츠가 실제로 바뀐 것인지 기기의 선택 상태만 달라진 것인지 구분할 수 있습니다.

안정적으로 사용 중인 항목이라면 반복 새로 고침을 연결 문제의 첫 해결책으로 삼을 필요가 없습니다. 서버 하나만 연결되지 않는다면 먼저 해당 항목의 테스트 결과와 실제 연결 상태를 확인하세요. 같은 구독의 여러 항목에서 동시에 문제가 발생한다면 구독 주소와 이번에 반환된 내용을 살펴보세요. 보유한 자료의 변경 안내를 받은 경우에만 해당 Subscribe를 업데이트하고 모든 구독을 무심코 업데이트하지 마세요. 그래야 목록이 바뀌었을 때 어떤 항목에서 어떤 작업으로 발생했는지 추적할 수 있습니다.

가져오기 실패와 파싱 실패 구분하기

가져오기에 실패하면 구독 URL이 완전한지, 기기의 현재 네트워크에서 접근할 수 있는지, 기존 주소가 여전히 유효한지 확인하세요. 파싱에 실패했거나 업데이트 후 목록이 비었다면 반환된 내용이 앱에서 인식할 수 있는 서버 정보인지, 웹 페이지 안내 주소를 구독 주소로 착각한 것은 아닌지, 원본에 줄바꿈이 추가되거나 일부가 잘리지 않았는지 살펴보세요. 업데이트 성공으로 표시됐지만 예상한 항목이 없다면 현재 어떤 구독 그룹을 보고 있는지, 이름이 같은 항목이 있는지, 정렬이나 필터 때문에 위치가 달라졌는지도 확인하세요. 원인을 찾기 전에 기존 항목을 삭제하지 말고 한 번에 한 가지 경로씩 점검하세요.

자동 업데이트 옵션이 현재 앱 화면에 표시된다면 사용 목적에 맞게 설정하세요. 모든 구독에 같은 업데이트 주기가 필요하다고 가정하지 마세요. 자주 업데이트하면 목록 변화를 추적하기 어려워지고, 업데이트 결과를 오랫동안 확인하지 않으면 보유한 자료와 일치하지 않는 오래된 항목을 계속 사용할 수 있습니다. 어떤 구독을 정기적으로 확인하고 어떤 구독을 명확한 변경이 있을 때만 수동 업데이트할지 기록하세요. 업데이트 후에는 완료 안내뿐 아니라 항목 수, 이름, 주요 입력 항목도 살펴보세요. 업데이트에는 기기의 네트워크 연결이 필요하므로 오프라인 상태에서는 이전 테스트 결과로 이번 가져오기의 성공 여부를 판단할 수 없습니다.

업데이트 후 연결 결과를 정확히 확인하는 방법

업데이트 전에 사용하던 항목을 먼저 찾으세요. 목록에 남아 있다면 Type, Address, Port, 필요한 추가 항목이 바뀌었는지 확인합니다. 이름이 바뀌었다면 Remark만으로 찾지 말고 속한 구독과 입력 항목을 기준으로 확인하세요. 그런 다음 사용 가능한 연결 또는 테스트 기능을 실행하고, 필요하면 Home에서 현재 선택한 서버와 Global Routing 상태를 확인하세요. Global Routing의 Config, Proxy, Direct는 각각 구성에 따른 처리, 프록시 처리, 직접 연결을 뜻합니다. 라우팅 상태가 다르면 테스트와 실제 사용 결과도 달라질 수 있습니다. 서버 매개변수, 규칙 경로, 대상 서비스 접근성 중 무엇을 확인하는지 분명히 해야 합니다. 이 셋을 모두 ‘업데이트 실패’로 묶어 판단하지 마세요.

업데이트 결과가 예상과 크게 다르면 구독 표시 이름, 업데이트 안내, 항목 수 변화, 특정 항목의 Type 등 변화를 설명할 수 있는 민감 정보가 아닌 내용을 먼저 저장하세요. 현재 상태를 반복해서 덮어쓰거나 원래 주소를 공개해 도움을 요청하지 마세요. 5단계 자가 점검 목록을 따라 원인을 좁혀 보세요. 구체적인 주소나 인증 정보는 해당 자료를 관리하는 곳에만 확인하세요. 구독을 다시 추가하려면 먼저 삭제 및 백업 장에서 기존 정보를 별도로 저장했는지 확인하세요.

용도를 이름으로 표시하고 이름으로 입력 항목을 대신하지 않기

Subscribe, 직접 입력한 서버, QR 코드로 가져온 항목이 함께 있으면 기록이 너무 많은 것보다 항목 간 관계를 알아보기 어려운 것이 문제입니다. 먼저 각 구독을 식별할 수 있는 이름을 정하고 직접 입력한 항목의 Remark는 구독 이름과 구분되게 설정하세요. 이름에 용도나 출처 유형을 표시할 수 있지만 Password, UUID, 전체 구독 주소처럼 민감한 정보는 포함하지 마세요. ‘빠름’, ‘항상 사용 가능’처럼 영구적인 상태를 나타내는 메모도 피하세요. 테스트 결과는 달라질 수 있지만 Remark는 목록에 오래 남아 잘못된 판단을 유발할 수 있습니다.

정리할 때는 구독 항목을 먼저 찾고, 그 아래의 서버 결과를 확인한 다음 직접 입력한 항목을 살펴보세요. 두 항목의 Remark가 같더라도 곧바로 하나를 삭제하지 마세요. 각각 열어 Type, Address, Port, 구독에서 가져온 항목인지 확인해야 합니다. 같은 서버가 서로 다른 입력 방식으로 두 번 표시될 수도 있고, 이름만 같고 매개변수는 다를 수도 있습니다. 특히 구독 업데이트 후에는 목록 순서가 바뀔 수 있으므로 ‘첫 번째 항목이 지난번 항목’이라는 습관은 잘못 선택할 가능성을 높입니다. 특정 정렬이나 필터를 자주 쓴다면 현재 표시 순서가 어떤 기준인지 먼저 확인하세요.

목록에 있는 항목과 현재 사용하는 항목 구분하기

목록에 서버 항목이 저장되어 있다고 해서 Home에서 해당 항목이 선택된 것은 아닙니다. 연결 문제를 확인할 때는 먼저 현재 선택 항목을 확인하고, 어느 구독에 속하는지 또는 직접 입력한 항목인지 확인한 다음 Global Routing을 살펴보세요. Config 상태에서는 구성 규칙에 따라 트래픽을 처리하고, Proxy 상태에서는 해당 프록시 방식으로 처리하며, Direct 상태에서는 직접 연결합니다. 아래 비교는 문제 확인 순서를 정리하기 위한 것이며 실제 트래픽 처리는 현재 구성과 앱 화면을 기준으로 합니다. 라우팅 상태를 기록하면 Direct 상태의 결과를 특정 서버의 문제로 잘못 판단하는 일을 줄일 수 있습니다.

구독 업데이트 후 비슷한 항목이 많이 추가됐다면 정렬을 바꾸기 전에 구독 출처부터 확인하세요. 지연 시간과 이름은 각각 고유 식별자가 아닙니다. 이름이 같은 항목도 서로 다른 Address를 가리킬 수 있고, 지연 시간은 테스트 당시의 네트워크 상태에 따라 달라집니다. ‘구독 표시 이름 → 서버 Type 및 민감 정보가 아닌 주소 정보 → 현재 선택 상태 → 테스트 결과’처럼 일관된 확인 순서를 정하세요. 목록 순서가 바뀌어도 확인할 항목을 다시 찾을 수 있습니다. 더 이상 사용하지 않는 항목은 정리하기 전에 현재 구성에서 선택되어 있는지 확인하세요.

구성 파일과 구독 목록을 구분하기

Config에는 규칙 구성이 저장될 수도 있습니다. 규칙 구성과 Subscribe의 서버 목록은 서로 다른 자료입니다. 규칙의 PROXY, DIRECT 등은 정책 키워드이지 구독 이름이 아닙니다. 아래 예시는 규칙이 도메인, 지리적 위치, 최종 트래픽을 어떻게 매칭하는지 보여 주는 구문 설명일 뿐입니다. 사용 가능한 서버가 포함되어 있지 않으므로 Subscribe 주소란에 붙여 넣지 마세요. 규칙에서 지정한 정책과 현재 사용 가능한 서버가 맞지 않는다면 구독만 반복 업데이트하지 말고 구성과 서버 선택을 각각 확인하세요.

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

여러 구독을 관리하는 목적은 목록을 최대한 짧게 만드는 것이 아니라 매번 업데이트와 테스트 대상을 명확히 찾는 것입니다. 먼저 출처를 알아볼 수 있는 이름을 유지한 뒤 실제 사용 방식에 맞게 정리하세요. DOMAIN-SUFFIX, GEOIP, FINAL을 더 알아보려면 용어집을 확인하세요. 처음 Global Routing을 선택하는 순서는 빠른 시작을 참고하세요.

먼저 테스트 대상 확인

지연 시간 테스트는 보통 현재 네트워크에서 특정 서버가 응답하는 상태를 확인합니다. Connectivity Test 등의 진단 메뉴는 화면에 표시된 설명에 따라 테스트 대상을 판단해야 합니다. 숫자가 표시된다고 해서 모든 웹사이트와 규칙 경로에서 응답이 똑같거나 일상적인 연결 검증이 끝난 것은 아닙니다. 테스트 전에 기기가 인터넷에 연결되어 있는지와 서버 항목을 제대로 가져왔는지 확인하고 현재 네트워크 환경을 기록하세요. 그렇지 않으면 같은 항목에서 다른 시간에 결과가 달라져도 테스트 조건의 변화일 수 있으며 구독 내용이 바뀌었다는 뜻은 아닙니다.

먼저 입력 항목을 확인한 서버 몇 개만 테스트해 앱에 숫자, 실패 안내, 대기 상태 중 무엇이 표시되는지 살펴보세요. 숫자는 같은 조건에서 같은 시점의 참고값입니다. 실패 안내는 Type, Address, Port, 인증 정보, 네트워크 접근성을 함께 확인해야 합니다. 지연 시간이 낮다는 이유만으로 다음 검증을 생략하지 말고 한 번 시간 초과가 발생했다고 항목을 삭제하지 마세요. 테스트 요청과 실제 접속은 대상과 경로가 다를 수 있습니다. 특히 Config 규칙을 사용할 때는 서버 연결을 테스트하는지, 특정 규칙을 통해 대상에 접근하는지 확인하세요.

정렬은 보기 방식이지 자료 변경이 아닙니다

지연 시간이나 다른 조건으로 정렬하면 항목을 더 빨리 찾을 수 있지만 보통 목록의 표시 순서만 바뀝니다. 정렬 결과를 자료의 영구적인 순서로 여기지 마세요. 구독 업데이트, 정렬 조건 변경, 재테스트 후 항목 위치가 달라질 수 있습니다. 문제를 확인할 때는 구독 출처와 입력 항목으로 서버를 식별하세요. ‘세 번째 서버’만을 유일한 단서로 기록하지 마세요. 테스트에 실패한 항목이 목록 끝으로 이동해도 구독에서 사라졌다는 뜻은 아닙니다. 기록이 실제로 누락됐는지 판단하기 전에 필터와 정렬 상태부터 확인하세요.

서버 두 개를 비교할 때는 같은 네트워크에서 비슷한 시간에 테스트하고 각 기록의 Type과 출처를 확인하세요. 한 번의 테스트는 다음에 확인할 대상을 정하는 데 도움을 주지만 입력 항목을 확인하는 절차를 대신하지 않습니다. 테스트에는 도달 가능하다고 표시되는데 실제 접속이 예상과 다르면 Home에서 해당 서버가 실제로 선택됐는지 확인하고 Global Routing이 Config, Proxy, Direct 중 어떤 상태인지 살펴보세요. Config라면 규칙에 매칭된 정책도 확인해야 합니다. 반대로 실제 사용에는 문제가 없는데 단일 테스트에서 숫자가 표시되지 않는다면 테스트 대상과 안내를 먼저 이해하세요. 작동 중인 설정을 바로 수정하지 마세요.

서버 진단에서 규칙 진단으로 넘어가기

서버 매개변수와 연결 상태를 확인한 뒤에 규칙을 점검하세요. 아래 예시는 구성에서 자주 사용하는 매칭 유형을 보여 줍니다. DOMAIN은 지정 도메인을 매칭하고, DOMAIN-SUFFIX는 도메인 접미사를 포함하며, IP-CIDR은 주소 대역을 대상으로 합니다. FINAL은 앞선 규칙에 매칭되지 않은 트래픽을 처리합니다. 예시의 example.com과 주소 대역은 구문 설명용입니다. PROXY가 예상대로 작동하는지는 현재 구성과 서버 선택에 달려 있습니다. 규칙 예시를 지연 시간 테스트 대상 목록으로 사용하지 마세요.

[Rule]
DOMAIN,example.com,PROXY
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.0.2.0/24,DIRECT
FINAL,PROXY

특정 대상에서만 문제가 발생하면 그 대상에 어떤 규칙이 매칭되는지 확인한 뒤 지정된 정책과 현재 서버를 살펴보세요. 여러 대상에서 모두 실패하면 서버 연결, 구독 업데이트, 기기의 네트워크 상태를 다시 확인합니다. 서버를 바꾸고 구독을 업데이트하고 규칙까지 다시 작성하는 것보다 좁은 범위부터 확인하는 편이 원인을 찾기 쉽습니다. 테스트와 정렬은 관리 도구이지 문제를 직접 해결하는 기능이 아닙니다. 어느 계층을 확인할지 알려 줄 뿐 원래 매개변수나 규칙을 대신하지 않습니다. 더 많은 증상은 문제 해결에서 유형별로 확인하세요.

먼저 삭제 대상이 어느 항목인지 확인

목록을 정리하기 전에 구독 항목, 구독으로 생성된 서버 항목, 직접 입력한 서버, Config 규칙 구성을 구분하세요. 항목을 삭제하면 이후 업데이트나 현재 선택 상태에 영향을 줄 수 있으므로 이름이 비슷하다는 이유만으로 여러 항목을 한꺼번에 정리하지 마세요. 구독을 삭제하기 전에는 일부 서버 항목의 업데이트 경로로 계속 사용 중인지 확인하세요. 단일 서버를 삭제하기 전에는 현재 선택되어 있는지, 다음 구독 업데이트에서 다시 표시될 수 있는지 살펴보세요. Config를 삭제하기 전에는 보존할 사용자 규칙이 있는지 확인하세요. 화면에 표시된 삭제 대상과 확인 안내를 빠짐없이 읽으세요.

더 안전하게 정리하려면 먼저 대상 항목의 출처와 민감 정보가 아닌 입력 항목을 확인한 다음 현재 연결에서 해당 항목을 사용하는지 살펴보고 원본 자료를 직접 보관 중인지 확인하세요. 구독 URL, 서버 인증 항목, 규칙 파일은 서로 다른 용도이므로 목록 스크린샷 한 장만으로 구성을 복원할 수 있다고 볼 수 없습니다. 반대로 전체 주소가 보이는 민감한 스크린샷을 공개해서도 안 됩니다. 백업은 본인이 관리할 수 있는 위치에 저장하세요. 이름과 용도를 기록할 때는 민감 정보를 제거한 텍스트를 사용할 수 있지만 복원에 필요한 전체 자료는 민감도에 맞춰 안전하게 보관해야 합니다.

구독, 직접 입력 항목, 규칙을 각각 백업

구독 항목을 복원하려면 본인이 보유한 전체 구독 주소와 식별용 이름을 최소한 보관해야 합니다. 직접 입력한 항목을 복원하려면 Type별 필수 입력 항목과 추가 옵션을 저장해야 합니다. 사용자 규칙 구성은 내용을 별도로 저장하세요. 구독 URL만 보관하면 직접 입력한 서버까지 보존되는 것은 아니며 공유 링크 하나만 보관해도 이전 규칙 파일을 복원할 수는 없습니다. 현재 앱에서 Export, 공유, Import from Cloud JSON 등의 관련 메뉴를 제공한다면 화면 안내를 읽고 어떤 종류의 자료를 내보내거나 가져오는지 확인한 뒤 사용 여부를 결정하세요. 메뉴 이름만으로 처리 범위를 짐작하지 마세요.

백업한 뒤에는 기존 항목을 변경하지 않는 방식으로 확인하세요. 저장된 내용에서 구독과 직접 입력 항목을 구분할 수 있는지, 텍스트가 잘리지 않았는지, 규칙 구문의 줄바꿈과 순서가 유지됐는지 살펴보세요. 인증 정보가 포함된 파일이나 텍스트를 공개 댓글이나 스크린샷에 올려 ‘백업 성공’을 확인하지 마세요. 문제 해결 기록만 필요하다면 구독 표시 이름, 서버 Type, 민감 정보가 아닌 메모, 작업 날짜를 적은 별도의 비식별 목록을 작성할 수 있습니다. 이 메모는 항목을 찾는 데 도움이 되지만 완전한 복원 자료를 대신하지는 않습니다.

삭제 후 다시 가져와야 하는지 확인하기

삭제한 뒤 목록으로 돌아가 대상 항목이 실제로 사라졌는지, 현재 선택 항목이 바뀌었는지, 다른 구독은 기존 방식대로 업데이트되는지 확인하세요. 구독에서 생성된 단일 항목을 삭제했지만 구독은 남아 있다면 다음 업데이트에 해당 항목이 다시 포함될 수 있습니다. 구독 자체를 삭제했다면 해당 구독에 의존하던 업데이트 경로도 다시 확인해야 합니다. 재생성하려면 Subscribe 또는 Add Server 장에서 알맞은 경로를 선택하세요. QR 코드, 클립보드, 직접 입력을 차례로 사용해 같은 항목을 중복 생성하지 마세요.

기기를 바꾸거나 앱을 다시 받으려면 먼저 구매 항목 복원 안내에 따라 App Store 구매 내역을 확인한 뒤 본인의 구독 및 구성 자료를 처리하세요. iPhone과 iPad에서 Shadowrocket을 이용하는 방법과 시스템 요구사항은 App Store 페이지의 안내를 기준으로 합니다. 앱 구매 상태와 서버 정보 저장은 별개의 문제입니다. 앱을 한 번 구매하는 것과 회선 이용 요금제는 별개이며, 구매 항목을 복원해도 직접 저장한 모든 서버 입력 항목이 자동으로 복원되지는 않습니다. 문제가 있다면 앱, 구독 항목, 서버 항목, 규칙 구성 중 무엇이 없는지 먼저 확인한 뒤 해당 항목을 복원하세요.