Shadowrocket 서버 관리: 기존 구독 가져오기, 업데이트 및 백업

Subscribe 가져오기: 주소와 응답 내용을 구분하세요

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

구독 주소는 반복해서 요청할 수 있는 원격 리소스의 진입점이고, 서버 항목은 앱이 해석한 구체적인 연결 대상입니다. 구독 하나에서 여러 항목을 가져올 수 있지만 구독 이름, 항목 이름, 현재 선택한 서버는 서로 다른 설정입니다. 관리할 때는 먼저 항목이 어느 구독에 속하는지 확인한 뒤 각 항목의 프로토콜과 매개변수를 살펴보세요. 주소가 저장되어 있어도 원격 내용을 정상적으로 가져왔다는 뜻은 아닙니다. 목록에 이름이 표시되어도 실제 연결 테스트를 통과했다는 뜻은 아닙니다.

시작하기 전에 원본 정보에서 구독 업데이트에 사용하는 전체 주소인지 확인하세요. 계정 페이지나 안내 페이지, 단일 서버 공유 링크와 혼동하지 마세요. 특히 주소의 물음표 뒤에 있는 쿼리 매개변수는 인증이나 콘텐츠 선택에 필요할 수 있으므로 그대로 유지해야 합니다. 복사할 때 따옴표, 줄바꿈, 채팅 앱의 앞부분 문구, 끝의 문장부호가 붙지 않도록 확인하세요. 보기 좋게 정리하려고 매개변수를 임의로 삭제해서도 안 됩니다. 구독 주소는 민감한 정보로 취급하고 공개 스크린샷에 포함하지 마세요.

Add Server에서 Subscribe 기록 만들기

Home에서 Add Server를 열고 Type 선택 화면에서 Subscribe를 선택한 뒤, 현재 양식에 맞춰 주소와 알아보기 쉬운 메모를 입력하세요. 표시 언어에 따라 메뉴 위치가 다를 수 있으므로 앱에 실제로 표시되는 Subscribe 항목과 입력란 안내를 기준으로 진행하세요. 저장하기 전에 프로토콜 접두사, 호스트 이름, 경로와 매개변수를 하나씩 확인하세요. 저장한 뒤 해당 구독 그룹이 표시되는지, 서버 항목이 생성되는지, 요청 또는 해석 오류가 표시되는지를 각각 확인하고 기록하세요.

처음 가져올 때는 구독 하나만 처리하는 것이 좋습니다. 반환된 내용을 정상적으로 해석하는지, 항목이 올바른 구독에 속하는지 확인한 다음 다른 구독을 추가하면 문제가 생겼을 때 원인을 찾기 쉽습니다. 가져온 뒤 Home에서 사용할 서버를 선택하고 선택 표시가 해당 항목에 있는지 확인하세요. 구독 그룹을 펼친 것을 서버 선택으로 착각하지 마세요. 이어서 빠른 시작 절차에 따라 연결하고 Connectivity Test를 실행해 가져온 항목이 실제 연결에 사용되는지 확인하세요.

목록이 비어 있거나 요청이 실패할 때 확인할 순서

저장한 뒤 서버가 표시되지 않으면 앱의 오류가 접근 실패인지, 콘텐츠 해석 실패인지 먼저 확인하세요. 접근 실패라면 현재 네트워크에서 요청을 보낼 수 있는지, 주소가 완전한지, 인증 정보가 유효한지 확인합니다. 콘텐츠 해석 실패라면 원격에서 서버 정보가 반환되는지 확인하세요. 로그인해야 하는 웹페이지, 오류 안내문 또는 빈 응답이 반환되었을 수도 있습니다. 브라우저에 텍스트가 표시되는 것은 브라우저가 내용을 가져왔다는 뜻일 뿐, 그 내용이 Subscribe에 적합하다는 증거는 아닙니다. 앱에서 실제로 가져온 결과도 따로 확인해야 합니다.

목록이 비어 있다고 같은 기록을 계속 추가하지 마세요. 중복 가져오기는 이후 업데이트와 삭제를 더 복잡하게 만들 뿐, 잘못된 주소를 고쳐 주지 않습니다. 구독 기록 하나만 남기고 입력 내용을 다시 확인한 뒤 한 번 업데이트하세요. 원격 정보가 바뀌었다면 본인이 이용 중인 서비스에서 제공하는 최신 주소를 사용하세요. 문제를 확인할 때는 어느 단계에서 실패했는지만 기록하고, 전체 주소를 관계없는 사람에게 전달하지 마세요. 도움을 요청할 때는 오류 유형, 현재 네트워크, 항목 생성 여부만 설명하면 됩니다.

이전에 작동하던 주소가 이제 실패한다면 원인을 파악하기 전에 기존 서버 목록부터 지우지 마세요. 마지막으로 업데이트에 성공했을 때 표시된 항목과 이번 오류 메시지를 기록한 뒤, 원격 서버에 일시적으로 접근할 수 없는 경우, 반환 내용이 바뀐 경우, 로컬 입력이 변경된 경우를 구분하세요. 관리의 목적은 목록에 이름 몇 개를 잠시 표시하는 것이 아니라, 반복해서 업데이트할 수 있는 원본 관계를 복구하는 것입니다.

Add Server 수동 입력 항목: 이름으로 추측하지 말고 프로토콜에 맞춰 확인하세요

먼저 Type을 선택한 다음 연결 정보를 입력하세요

수동 추가는 완전한 서버 매개변수를 이미 보유하고 있고 각 항목을 직접 확인해야 할 때 적합합니다. Home에서 Add Server를 연 뒤 실제 프로토콜에 맞는 Type을 먼저 선택하고 Address, Port 및 해당 인증 항목을 입력하세요. Type을 선택하면 필요한 입력 항목이 달라지므로, 한 프로토콜의 양식에 모든 내용을 입력한 뒤 이름만 바꾸고 변환되었다고 생각해서는 안 됩니다. 메모는 항목을 알아보기 위한 것으로 인증에 쓰이지 않습니다. 이름에 특정 프로토콜이 들어 있어도 실제 항목이 그 프로토콜을 사용한다는 뜻은 아닙니다.

Address에는 보통 호스트 이름이나 주소를 입력하고, Port에는 포트 번호만 따로 입력합니다. 현재 입력란에서 전체 주소를 요구하지 않는 한 웹 주소 전체, 경로와 포트를 함께 Address에 넣지 마세요. 복사한 뒤 앞뒤 공백이 없는지, 숫자가 입력기 때문에 전각 문자로 바뀌지 않았는지 확인하세요. 주소, 포트, 인증 및 전송 매개변수는 모두 동일한 기존 서버 정보에서 가져와야 합니다. 서로 비슷해 보이는 여러 항목을 조합하지 마세요. 항목 하나라도 다른 서버에 해당하면 연결이 실패할 수 있습니다.

인증 항목은 서로 대신 사용할 수 없습니다

Shadowsocks의 Method와 Password는 서버 설정과 일치해야 합니다. VMess와 VLESS의 UUID는 임의로 정하는 메모가 아니며 계정 로그인 비밀번호로 대신할 수도 없습니다. Trojan과 Hysteria2는 각각의 입력 양식과 기존 정보를 기준으로 인증 값을 확인하세요. WireGuard에서는 로컬 개인 키와 피어 공개 키의 역할을 이해하고 서로 바꿔 입력하지 않아야 합니다. 표는 확인 항목을 안내하기 위한 것이며 모든 서버에 공통으로 쓸 수 있는 매개변수 템플릿이 아닙니다. 실제 필수 항목은 선택한 Type의 입력 양식을 따르세요.

비밀번호와 키는 대소문자를 구분하는 경우가 많으므로 복사할 때 자동 수정 기능을 사용하지 마세요. 비어 있는 것처럼 보이는 인증란은 연결 결과를 보며 추측하기 전에 실제로 비워 두어야 하는지 원본 정보에서 확인하세요. 매개변수가 공유 링크에 들어 있다면 먼저 별도의 항목으로 가져온 뒤 편집 화면의 값과 원본 정보를 비교할 수 있습니다. 이렇게 하면 원래 해석된 결과를 보존하면서 수동 입력에서 빠진 전송 옵션도 확인할 수 있습니다. 단, 링크가 동일한 서버에 해당하는지 반드시 확인해야 합니다.

TLS, 서버 이름, 전송 경로를 각각 확인하세요

TLS를 사용하면 연결 주소와 인증서 검증에 쓰는 서버 이름이 서로 다를 수 있습니다. 전송에 사용하는 Host와 Path, TLS 서버 이름도 각각 용도가 다르므로 도메인이나 문자열이라는 이유만으로 서로 복사해서는 안 됩니다. 기존 정보를 기준으로 전송 유형, 경로의 슬래시, 대소문자와 서버 이름을 확인하세요. 필드가 맞지 않는 문제를 가리기 위해 인증서 검증을 끄지 마세요. 인증서 오류가 발생하면 기기의 날짜와 시간이 정확한지, 정보에 기록된 도메인이 여전히 유효한지도 함께 확인하세요.

저장한 뒤 편집 화면을 다시 열어 입력이 빠졌거나 잘못된 필드에 들어가지 않았는지 확인하세요. 변경할 때는 범위를 분명하게 나누세요. 근거가 있는 항목 하나만 바꾸고 결과를 테스트한 뒤 다음 항목을 수정합니다. 프로토콜, 포트, 인증 및 TLS를 한꺼번에 변경하지 마세요. 작동하는 전체 매개변수를 알고 있다면 별도의 테스트 복사본을 만들어 비교할 수 있습니다. 원본과 테스트 항목을 구분하고, 검증하지 않은 복사본을 일상적으로 사용할 기본 서버로 설정하지 않도록 주의하세요.

수동으로 입력한 항목은 보통 직접 관리해야 하며 Subscribe 업데이트가 매개변수를 자동으로 수정한다고 가정해서는 안 됩니다. 구독에서 생성된 항목은 다음 새로 고침 때 필드가 다시 생성될 수 있으므로 원본 정보부터 확인하는 것이 좋습니다. 영어 UI 용어가 낯설다면 인터페이스 용어 안내를 참고해 연결 매개변수와 Global Routing의 정책 옵션을 혼동하지 않도록 하세요.

QR 코드 및 클립보드로 가져오기: 내용을 확인한 다음 저장하세요

Scan QR Code는 입력 방식만 바꿉니다

QR 코드는 텍스트를 담는 수단이지 별도의 서버 프로토콜이 아닙니다. 단일 서버 공유 링크나 구독 주소, 일반 웹페이지가 들어 있을 수 있습니다. Scan QR Code를 사용하기 전에 본인이 보유한 서버 정보에서 나온 내용인지 확인하세요. 인식한 뒤에는 앱에 표시되는 유형과 가져올 대상을 살펴본 다음 저장 여부를 결정합니다. ‘스캔 성공’이 서버 사용 가능을 뜻하지는 않습니다. 스캔은 이미지의 텍스트를 읽었다는 의미일 뿐이며, 이후 형식 해석과 연결 검증을 별도로 거쳐야 합니다.

앱의 스캔 메뉴에서 Scan QR Code를 열고 시스템 안내에 따라 카메라 접근을 허용할지 결정한 다음, QR 코드 전체가 화면에 들어오도록 맞추세요. 당장 카메라 사용을 허용할 생각이 없다면 이미 보유한 텍스트를 가져오면 됩니다. 계속 진행하려고 관련 없는 시스템 권한을 변경할 필요는 없습니다. 반사광, 잘린 모서리, 낮은 해상도, 화면 확대는 인식에 영향을 줄 수 있습니다. 작은 부분을 반복해서 캡처하기보다는 원본 QR 코드를 선명하게 확보하세요.

인식 결과는 세 단계로 확인하세요

첫째, 대상 유형을 확인합니다. Add Server의 편집 정보인지 Subscribe 주소 기록인지 살펴보세요. 둘째, 연결 항목을 확인합니다. 주소, 포트, 프로토콜과 인증 정보가 완전한지 확인하세요. 셋째, 관리상 소속을 확인합니다. 새 항목이 예상한 구독에 속하는지, 별도의 수동 항목으로 저장되는지 살펴보세요. 스캔한 뒤 일반 웹페이지로 이동한다면 QR 코드에 웹페이지 주소가 들어 있을 수 있습니다. 웹 주소 전체를 서버 매개변수로 입력하려고 계속 시도하지 마세요.

같은 기기에 저장된 QR 코드 이미지를 사진 앱에서 바로 인식할 수 있는지는 현재 스캔 화면에 실제로 해당 기능이 있는지에 따라 달라집니다. 관련 메뉴가 없다면 숨겨진 동작이 있다고 가정할 필요는 없습니다. 직접 저장한 원본 텍스트를 사용하거나, 관리 중인 다른 기기에 기존 QR 코드를 표시한 뒤 스캔할 수 있습니다. 인증 정보가 담긴 이미지가 공개 공유 앨범, 단체 채팅이나 화면 녹화에 포함되지 않도록 주의하세요. 특히 메모만 가리고 코드 영역 전체를 그대로 노출해서는 안 됩니다.

클립보드로 가져오기 전에 관련 없는 문구를 제거하세요

복사할 때는 채팅 기록 전체가 아니라 공유 링크나 구독 주소 하나를 완전히 선택하세요. 시스템에서 붙여넣기 권한을 물으면 현재 작업을 본인이 시작한 것이 맞는지 확인한 뒤 앱의 읽기를 허용하세요. 가져오기 안내가 표시되면 해석된 항목 수와 유형을 먼저 확인합니다. 안내가 나타나지 않으면 화면에 실제로 있는 가져오기 메뉴를 사용하세요. 표시되지 않은 안내를 프로토콜 미지원으로 오해하지 마세요. 클립보드를 여러 번 덮어쓰기보다 한 번 복사하고 결과를 확인하는 편이 문제를 추적하기 쉽습니다.

서식 있는 텍스트에는 글머리표, 따옴표, 보이지 않는 공백과 임의의 줄바꿈이 포함될 수 있습니다. 관리되는 일반 텍스트 환경에서 앞뒤를 확인할 수 있지만, 인증 정보를 온라인 변환 페이지에 붙여넣어서는 안 됩니다. 여러 항목을 한꺼번에 가져올 때는 각 항목의 경계를 확인해 두 링크가 한 줄로 합쳐지거나 한 덩어리의 인코딩 문자열이 둘로 나뉘지 않도록 하세요. 앱이 예상과 다른 수의 항목을 표시하면 불완전한 결과를 목록에 남겨 연결을 시도하기보다 원본 텍스트부터 다시 확인하세요.

QR 코드와 텍스트를 가져온 결과가 다르면 두 자료가 정말 같은 내용인지 비교하세요. QR 코드는 예전에 저장한 정보일 수 있지만 클립보드에는 새 주소가 복사되어 있을 수 있습니다. 텍스트에 추가 이스케이프가 포함되었을 수도 있습니다. 원본 정보를 보존하고 이름이 같은지만으로 판단하지 말고 대상 유형, 주소와 포트를 비교하세요. 가져오기가 끝나면 클립보드를 일반 텍스트로 바꾸고 더는 필요하지 않은 민감한 스크린샷을 삭제해 실수로 공유될 가능성을 줄이세요.

공유 링크 형식: 프로토콜, 인코딩 및 필드 경계를 유지하세요

단일 링크와 구독 주소의 관리 방식 차이

단일 서버 공유 링크는 보통 연결에 필요한 정보를 텍스트에 담으며, 가져오면 명확한 서버 항목 하나 또는 여러 개가 생성됩니다. 구독 주소는 원격 콘텐츠를 가리키며 나중에 다시 요청해 업데이트할 수 있습니다. 둘 다 클립보드나 QR 코드로 전달할 수 있지만 관리 방식은 다릅니다. 단일 링크의 매개변수는 원격 구독이 바뀌어도 자동으로 수정되지 않습니다. 구독 항목은 새로 고칠 때 추가, 교체 또는 삭제될 수 있습니다. 원본을 저장하기 전에 어떤 유형의 자료인지 먼저 확인하세요.

일반적인 단일 공유 텍스트에는 ss, vmess, vless, trojan 같은 프로토콜 접두사가 포함될 수 있습니다. 인식 여부와 확장 필드는 현재 Shadowrocket의 해석 결과를 기준으로 확인하세요. 접두사는 첫 번째 확인 항목일 뿐, 전체 매개변수를 점검하는 과정을 대신하지 않습니다. 익숙하지 않은 형식은 접두사를 바꿔 억지로 가져오지 마세요. 겉모양이 비슷한 텍스트도 인코딩 방식이 다를 수 있으며, 문자를 몇 개 바꾼다고 다른 프로토콜로 변환되지는 않습니다.

인코딩된 텍스트는 직접 손보지 않는 것이 좋습니다

일부 공유 형식은 Base64로 매개변수를 저장하고, 다른 형식은 URI와 비슷한 필드 구조를 사용합니다. Base64는 텍스트 인코딩일 뿐 인증 정보를 보호하는 방법이 아닙니다. 인코딩된 내용을 볼 수 있는 사람은 그 안의 정보를 복원할 수 있습니다. 형식마다 문자 집합, 패딩 문자와 매개변수 위치를 다르게 처리할 수 있으므로 링크를 짧게 만들려고 끝 문자를 삭제하거나 긴 문자열의 더하기 기호와 슬래시를 서식 문자처럼 제거하지 마세요. 원본 텍스트를 유지하고 앱이 직접 해석하도록 하는 것이 좋습니다.

URI 형식의 내용에서 물음표는 쿼리 매개변수의 시작을, 구분자는 매개변수 사이를 나타내며, 해시 기호 뒤에는 메모가 들어갈 수 있습니다. 하지만 인증 값에도 퍼센트 인코딩이 필요한 문자가 들어갈 수 있으므로 눈으로만 보고 나누거나 다시 조합하지 마세요. 특히 복사 과정에서 달라진 문자와 원래부터 그랬던 문자를 구별해야 합니다. 반복해서 디코딩하면 예약 문자가 손상될 수 있고, 인코딩하지 않은 구분자는 인증 값을 여러 필드로 잘라 버릴 수 있습니다. 명확한 형식 근거가 없다면 본인의 원본 공유 텍스트를 다시 받으세요.

해석된 항목과 이름이 아니라 필드를 기준으로 확인하세요

링크의 메모는 보통 서버를 알아보기 위한 것이며 연결 동작을 결정하지 않습니다. 이름이 같은 두 항목도 포트, UUID, 전송 경로 또는 TLS 서버 이름이 다를 수 있고, 이름이 달라도 매개변수는 동일할 수 있습니다. 중복 여부를 확인하려면 편집 화면에서 프로토콜, 주소, 포트와 주요 옵션을 비교하세요. 인증 정보가 들어 있는 전체 링크를 일반 메모로 저장하지 마세요. 목록 표시, 검색 또는 스크린샷에서 민감한 정보가 더 많이 노출될 수 있습니다.

본인이 관리하는 기기 사이에서 정보를 옮기기 위해 공유 기능을 사용할 때도 내보내는 범위를 확인해야 합니다. 단일 서버 공유는 일반적으로 구독 원본 기록을 대신하지 않으며, 구독 공유도 Config 전체 백업으로 간주해서는 안 됩니다. 옮기기 전에 대상 기기에 필요한 것이 서버 하나인지, 구독 업데이트 주소인지, 규칙 구성 파일인지 확인한 뒤 각각 내보내고 검증하세요. 항목 하나를 가져올 수 있다는 것은 그 항목의 형식을 인식했다는 뜻일 뿐, 다른 설정까지 함께 옮겨졌다는 뜻은 아닙니다.

규칙 구성의 구문도 원래 형태 그대로 유지해야 합니다. 다음 내용은 Shadowrocket 규칙 형식의 예시일 뿐 서버 인증 정보는 포함하지 않으며, 이것만으로 연결할 수 없습니다. 실제로 사용할 때는 현재 Config와 정책 참조를 확인하세요. 규칙은 순서대로 적용됩니다. FINAL은 앞선 규칙에 일치하지 않은 요청을 처리하도록 마지막에 두며, 모든 구체적인 규칙보다 앞에 배치해서는 안 됩니다.

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

서버 정보와 이러한 규칙 조각은 별도로 보관하세요. 규칙 텍스트를 Subscribe에 붙여넣거나 구독 주소를 전체 구성 파일로 사용하면 입력을 받아들일 수는 있어도 실제 해석 대상은 다릅니다. 용도를 판단하기 어렵다면 먼저 원본 자료의 설명을 확인한 다음 용어집에서 Subscribe, Config와 관련 규칙 키워드를 구분하세요. 잘못된 가져오기를 반복해 나중에 알아보기 어려운 기록이 쌓이지 않도록 하세요.

구독 업데이트 방법: 요청 성공과 콘텐츠 변경을 구분하세요

수동 업데이트는 전체 확인 절차를 거치세요

구독 업데이트는 저장된 주소에 다시 접속해 반환된 내용을 처리하는 기능이지, 기존 서버의 연결 상태를 테스트하는 기능이 아닙니다. 실행 전 어떤 구독을 업데이트할지 확인하고 현재 선택한 서버와 그룹 상태를 기록하세요. 실행 후에는 앱 안내, 항목 변경 여부, 기본 선택이 여전히 예상과 맞는지를 각각 확인합니다. 요청에 성공했지만 항목이 바뀌지 않았다면 원격 콘텐츠가 기존과 같을 수 있습니다. 목록이 바뀌어도 새 항목의 연결 검증이 끝난 것은 아닙니다. 두 경우 모두 추가 확인이 필요합니다.

구독 기록에서 화면에 제공되는 업데이트 기능을 실행한 뒤 결과가 나올 때까지 기다리세요. 요청이 끝나기 전에 반복해서 누르지 마세요. 자주 새로 고쳐도 잘못된 주소가 올바르게 바뀌지는 않으며, 여러 요청의 순서를 구분하기 어려워질 수 있습니다. 한 번 실패하면 안내에 따라 네트워크 접근 실패, 인증 문제, 콘텐츠 해석 문제를 구분한 뒤 다음 단계를 결정하세요. 주소를 업데이트해야 한다면 구독 기록 자체를 확인하세요. 생성된 서버 항목에서 주소만 바꾸지 마세요.

자동 업데이트가 즉시 실행된다는 보장은 없습니다

현재 Settings 또는 구독 편집 화면에 자동 업데이트 옵션이 있다면 실제로 어떤 동작을 하는지와 설정 범위를 읽고 필요한 경우에만 켜세요. 앱이 어떤 백그라운드 상태에서도 정확한 시각에 요청을 완료한다고 가정하지 마세요. 기기 네트워크, 시스템 스케줄링, 앱 상태가 실행 조건에 영향을 줍니다. 새 매개변수에 의존해 연결해야 한다면 최근 업데이트 결과를 앱이 실행 중일 때 확인하고, 필요하면 직접 업데이트한 뒤 연결을 검증하세요.

업데이트 빈도는 정보가 바뀌는 상황에 맞춰야 하며 짧을수록 좋은 것은 아닙니다. 오랫동안 안정적인 구독이라면 연결이 한 번 실패했다고 연이어 새로 고칠 필요가 없습니다. 이용 중인 서비스에서 매개변수가 변경되었다고 명시한 경우에는 업데이트한 뒤 바뀐 필드를 확인하세요. 자동 업데이트와 서버 자동 선택도 서로 다른 기능입니다. 전자는 데이터를 관리하고 후자는 실제 연결 대상을 선택합니다. 목록을 방금 새로 고쳤다는 이유만으로 앱이 더 적합한 항목으로 전환했다고 생각하지 마세요.

로컬 편집과 원격 콘텐츠의 경계

구독에서 생성된 필드는 다음 업데이트 때 다시 기록될 수 있으므로 메모, 포트 또는 다른 매개변수를 로컬에서 바꾸었다면 해당 변경 사항이 덮어써질 수 있는지 고려해야 합니다. 변경 사항의 유지 여부는 현재 화면과 실제 업데이트 결과를 기준으로 확인하세요. 사용자 지정 매개변수를 계속 유지해야 한다면 기능이 허용하는 경우 별도의 수동 항목을 만들고 관리 책임이 누구에게 있는지 명확히 표시하세요. 구독 항목이 계속 변하지 않는 로컬 기록이라고 생각하거나 검증하지 않은 덮어쓰기 동작에 의존하지 마세요.

업데이트 뒤 항목이 추가되거나 줄어들거나 이름이 중복되면 원격 정보가 실제로 바뀌었는지 먼저 확인한 뒤 현재 선택 상태를 살펴보세요. 기존 서버가 삭제되었거나 새 이름이 다른 매개변수를 가리킬 수 있습니다. 연결 중 혼동을 피하려면 중요한 데이터 전송을 하지 않을 때 업데이트하는 것이 좋습니다. 업데이트가 끝나면 선택 표시를 다시 확인한 뒤 테스트하세요. 기존 항목에 대한 의존성은 목록의 위치가 아니라 매개변수와 소속을 기준으로 파악해야 합니다.

업데이트 실패를 확인할 때는 주소와 앱 설정을 그대로 두고 본인이 관리하는 다른 네트워크에서 비교해 볼 수 있습니다. 네트워크를 바꾼 뒤 성공하면 요청 경로부터 살펴보세요. 계속 실패한다면 주소와 반환 형식을 확인합니다. 구독 업데이트 문제를 특정 서버의 지연 시간 탓으로 바로 돌리지 마세요. 목록을 모두 지우거나 주소를 바꾸고 여러 네트워크 설정을 한꺼번에 전환해서도 안 됩니다. 한 번에 조건 하나만 바꿔야 결과를 비교할 수 있습니다.

간단한 관리 기록은 기억에 의존하는 것보다 믿을 수 있습니다. 대상, 작업 이유, 항목 변경 여부와 검증 결과만 적고 전체 인증 정보는 저장하지 않아도 됩니다. 다음에 같은 안내가 나타나면 구독 접속, 콘텐츠 해석, 서버 연결 중 어느 단계에서 문제가 생겼는지 파악하기 쉽습니다. 기록을 남기면 정상적인 목록을 반복해서 가져오거나 삭제하는 실수도 줄일 수 있습니다.

여러 구독 정리: 소속과 선택 기준을 명확히 하세요

주소를 노출하지 말고 구독에 이름을 붙이세요

여러 구독을 관리할 때 가장 먼저 답할 수 있어야 하는 질문은 ‘이 항목은 어느 기록에서 업데이트되었는가’입니다. 개인 기기의 용도나 관리 범위를 기준으로 짧고 일관되며 알아보기 쉬운 메모를 사용하세요. 전체 구독 주소, 계정 식별 정보, 키를 이름에 넣지 마세요. 메모는 항목을 구분하기 위한 것이지 매개변수를 저장하는 용도가 아닙니다. 서버 이름은 구분에 필요한 정보를 남기되 모두 같은 짧은 이름으로 바꾸지 마세요. 나중에 비교하기 어려워질 수 있습니다.

두 번째 구독을 만들기 전에 첫 번째 구독을 정상적으로 가져왔고 실제 연결 테스트까지 마쳤는지 확인하세요. 그런 다음 하나씩 추가하며 새 그룹과 항목 범위를 살펴보세요. 앱에서 그룹을 접을 수 있다면 당장 사용하지 않는 그룹을 접어 화면을 정리할 수 있습니다. 하지만 접기는 표시 방식만 바꾸며 비활성화, 삭제 또는 현재 연결 변경을 의미하지 않습니다. 목록을 살펴볼 때 그룹이 펼쳐졌는지와 항목이 선택되었는지를 구분하세요. 실제 연결 대상은 앱의 선택 표시로 확인해야 합니다.

중복 항목은 매개변수와 관리 출처를 비교하세요

이름이 같다고 반드시 중복인 것은 아니며, 이름이 다르다고 서로 별개의 항목인 것도 아닙니다. 판단하기 전에 Type, Address, Port, 주요 인증 및 전송 필드를 비교하고 각 항목이 서로 다른 구독에서 왔는지 살펴보세요. 두 구독이 비슷한 서버를 반환하더라도 각각의 업데이트 관계를 유지하려면 출처를 구분해 두는 것이 좋습니다. 구독에서 생성된 항목을 바로 삭제하면 다음 업데이트 때 다시 나타날 수 있습니다. 정리 전에 목록의 중복 표시를 줄이려는 것인지, 특정 출처의 관리를 중단하려는 것인지 먼저 결정하세요.

목록 정리가 라우팅 변경을 의미하지는 않습니다

Global Routing에서 Config를 사용하면 현재 구성의 규칙에 따라 요청이 처리됩니다. Proxy를 사용하면 현재 프록시 서버나 관련 정책을 확인해야 하며, Direct를 사용하면 해당 모드에서 트래픽이 직접 처리됩니다. 구독 수가 몇 개인지는 요청이 어느 서버를 거칠지 결정하지 않습니다. Config에서 이름으로 정책을 참조한다면 해당 참조가 유효한지도 확인하세요. Home에서 서버 하나를 선택했다는 이유만으로 모든 요청이 그 서버를 사용한다고 단정해서는 안 됩니다.

메모를 바꾸기 전에 구성에서 이름을 참조하는지 특히 주의하세요. 규칙이나 정책이 특정 이름에 의존한다면 이름을 바꾼 뒤 참조 관계도 함께 확인해야 할 수 있습니다. 화면을 보기 좋게 하려고 한꺼번에 이름을 바꾸면 오히려 관리가 복잡해질 수 있습니다. 먼저 현재 Config가 특정 이름을 참조하는지 파악한 다음 변경 범위를 정하세요. 익숙하지 않은 구성은 원본 파일을 보존하고 작은 범위에서 검증하는 편이 모든 항목의 이름을 한꺼번에 바꾸는 것보다 되돌리기 쉽고 오류 지점도 찾기 쉽습니다.

반복해서 적용할 수 있는 관리 순서 만들기

정기적으로 정리할 때는 순서를 고정해 보세요. 구독 하나를 업데이트하고 변경 내용을 확인한 다음 사용할 항목을 테스트하고 마지막으로 중복 또는 작동하지 않는 기록을 처리합니다. 한 그룹을 마친 뒤 다음 그룹으로 넘어가면 여러 구독이 동시에 새로 고쳐져 변경 출처를 알기 어려운 상황을 피할 수 있습니다. 구독 하나가 일시적으로 실패해도 정상적인 다른 기록까지 바로 삭제하고 다시 만들지 마세요. 확인된 상태는 보존하고 문제가 생긴 기록만 점검하세요.

항목이 많으면 먼저 소속으로 범위를 좁힌 뒤 화면에서 실제 제공하는 검색 또는 정렬 기능으로 찾으세요. 검색되지 않는다고 기록이 삭제된 것은 아닙니다. 이름 변경, 접힌 그룹 또는 필터 조건이 원인일 수 있습니다. 테스트 대상을 바꾸기 전에는 현재 사용할 수 있는 항목을 기록하고, 테스트가 끝나면 예상한 항목을 다시 선택하세요. 여러 구독 관리의 핵심은 출처, 매개변수, 라우팅과 현재 선택을 명확히 유지하는 것이지 목록을 최대한 줄이거나 이름을 모두 통일하는 것이 아닙니다.

화면 용어를 확인하려면 용어집을 참고하고, 처음부터 연결하려면 빠른 시작으로 돌아가세요. 이 페이지의 정리 방법은 관리 과정의 혼동을 줄일 뿐, 기존 서비스의 권한, 매개변수 유효 기간이나 사용 범위를 바꾸지 않습니다.

지연 시간 테스트 및 정렬: 응답, 핸드셰이크와 요청을 구분하세요

테스트 값 하나로 모든 사용 결과를 판단할 수 없습니다

테스트 결과는 먼저 어떤 검사 방식을 사용했는지에 따라 달라집니다. 포트 검사, 프로토콜이 필요한 검사, 실제 웹 요청은 각각 확인하는 범위가 다릅니다. 특정 검사에서 응답이 있다는 것은 해당 경로로 연결을 시도할 수 있다는 뜻일 수 있지만, 인증, TLS, 규칙과 대상 서비스까지 이어지는 전체 경로가 검증된 것은 아닙니다. 값을 비교하기 전에 현재 테스트 설정과 설명을 확인해 같은 방식에서 나온 결과끼리 비교하세요. 범위가 다른 검사 값을 그대로 나열해서는 안 됩니다.

여러 항목을 한꺼번에 테스트하면 확인 범위를 좁히는 데 도움이 되지만, 첫 번째 항목이 언제나 가장 좋다고 결론 내릴 수는 없습니다. 현재 네트워크, 테스트 대상, 기기 부하와 테스트 시점이 모두 결과에 영향을 줍니다. 같은 네트워크 조건에서 한 번 테스트한 뒤 실제로 사용할 소수 항목을 다시 검증하세요. 네트워크를 바꾼 직후 화면에 보이는 이전 결과는 이전 조건에서 나온 값이므로 다시 테스트하지 않은 상태에서 선택 기준으로 사용하지 마세요.

Connectivity Test는 현재 연결과 함께 확인하세요

Home에서 사용할 서버를 선택하고 선택 표시를 확인한 다음 연결 스위치를 켜세요. 시스템에서 VPN 구성을 추가하라는 메시지가 표시되면 내용을 읽고 본인의 작업 의도에 따라 승인합니다. 이어서 Connectivity Test를 실행하고 Global Routing도 함께 확인하세요. Direct를 사용하는 중이라면 테스트 성공으로 프록시 서버 인증이 올바르다고 판단할 수 없습니다. Config를 사용한다면 테스트 대상에 적용될 수 있는 규칙과 해당 규칙이 선택하는 정책도 고려해야 합니다.

실제 검증에는 본인이 사용해야 하는 대상에 대한 요청이 포함되어야 합니다. Connectivity Test는 성공하지만 특정 앱이 작동하지 않는다면 해당 앱의 요청이 다른 규칙에 일치하는지, 도메인 해석이 정상인지, 대상 서비스 자체에 별도의 문제가 있는지 계속 확인하세요. 시스템에 VPN 상태가 표시된다고 검증을 멈추지 마세요. 시스템 상태는 연결 구성이 작동 중이라는 뜻이지 모든 대상에 요청이 성공했다는 뜻은 아닙니다. 첫 연결의 자세한 순서는 첫 연결 확인 안내를 참고하세요.

시간 초과는 단계별로 원인을 찾으세요

시간 초과가 발생하면 먼저 기본 네트워크를 확인하고, 다음으로 서버 주소와 포트를 확인한 뒤 인증, 전송 및 TLS를 살펴보세요. 도메인 관련 오류가 있다면 이름 해석과 서버 이름도 확인합니다. 포트에 접근할 수 없는 문제와 인증 거부는 서로 다른 단계에서 발생하므로 실제 안내에 따라 구분해야 합니다. 오류 정보가 충분하지 않다면 나머지 매개변수를 유지한 채 관리 가능한 다른 네트워크에서 비교해 볼 수 있습니다. 근거 없이 여러 항목을 연이어 바꾸면 테스트 결과를 원인과 연결할 수 없습니다.

기기의 시스템 날짜와 시간은 인증서 및 일부 인증 절차에도 영향을 줍니다. 날짜, 시간대와 자동 설정이 실제 상황에 맞는지 확인하고 오류를 우회하려고 검증 기능을 계속 꺼 두지 마세요. 같은 네트워크에서 확인된 다른 항목은 정상인데 서버 하나만 실패한다면 그 항목의 매개변수와 원격 상태를 집중적으로 살펴보세요. 서로 다른 여러 기록이 동시에 실패하면 공통 조건부터 확인합니다. 자세한 단계는 시간 초과 및 연결 실패 문제 해결을 참고하세요.

정렬은 표시 순서만 바꾸며 선택을 대신하지 않습니다

지연 시간순 정렬은 목록을 살펴보기 쉽게 해 주지만, 그 자체로 현재 연결을 자동 전환하지는 않습니다. 정렬한 뒤에도 사용할 항목을 직접 선택하고 선택 표시를 확인한 다음 다시 검증해야 합니다. 빈 결과, 미테스트 결과와 실패 결과를 같은 값처럼 비교해서도 안 됩니다. 현재 화면에서 각 상태를 어떻게 표시하는지 확인하세요. 여러 구독을 사용하는 경우 정렬이 현재 그룹에만 적용되는지 전체 목록에 적용되는지도 살펴봐야 항목이 사라졌다고 오해하지 않습니다.

테스트가 끝나면 필요한 내용만 기록하세요. 사용한 방식, 테스트 네트워크, 실제 요청의 성공 여부면 충분합니다. 문제 해결 정보를 공유할 때는 서버 인증 정보, 구독 주소와 개인 데이터를 가리세요. 기록의 가치는 재현할 수 없는 숫자를 나열하는 데 있는 것이 아니라 조건과 현상을 설명하는 데 있습니다. 조건이 같아야 네트워크, 매개변수 또는 규칙의 변화 전후를 비교할 수 있습니다.

삭제 및 백업: 범위를 먼저 확인하고 복원 결과를 검증하세요

삭제 전에 대상 항목을 확인하세요

서버 하나, 구독 기록, Config 파일은 삭제할 때 각각 영향이 다릅니다. 작업 전에 현재 어떤 페이지에 있는지, 어떤 항목을 선택했는지, 확인 메시지가 설명하는 범위가 무엇인지 살펴보세요. 서버 하나를 목록에서 삭제해도 원격 구독 내용은 바뀌지 않습니다. 구독 기록을 삭제해도 외부 서비스 권한이 처리되는 것은 아닙니다. 버튼 주변의 이름만 보고 영향을 판단하지 말고 페이지 위치와 실제 확인 메시지를 함께 살펴 삭제 대상이 항목인지, 그룹인지, 구성인지 확인하세요.

현재 선택한 서버를 삭제하려면 먼저 대체 항목을 정하고 연결을 검증한 다음 기존 기록을 처리하세요. 구성 정책이 삭제할 이름을 참조한다면 해당 참조가 여전히 유효한지도 확인해야 합니다. 삭제한 뒤 Home으로 돌아가 선택 상태를 확인하고 Global Routing과 현재 Config를 살펴보세요. 앱이 예상한 다음 항목을 자동으로 선택한다고 가정하지 마세요. 시스템에 연결 상태가 표시되더라도 실제 요청을 다시 검증해야 합니다.

구독 항목은 업데이트 후 다시 나타날 수 있습니다

구독에서 생성된 서버를 로컬에서 삭제해도 다음 새로 고침 때 원격 콘텐츠에 따라 다시 생성될 수 있습니다. 이런 현상은 반드시 삭제 실패를 뜻하는 것은 아닙니다. 로컬 목록이 원본 내용과 다시 동기화된 것일 수 있습니다. 구독 전체의 관리를 중단하려면 해당 구독 기록을 처리하고 확인 메시지에서 연결된 항목의 범위를 살펴보세요. 서버 하나를 일시적으로 사용하지 않을 뿐이라면 반복해서 삭제하고 새로 고치는 것보다 선택 상태와 그룹 표시를 명확하게 유지하는 편이 관리하기 쉽습니다.

여러 항목을 삭제하기 전에 목록의 위치에 의존하지 마세요. 정렬, 그룹 펼치기와 업데이트에 따라 위치가 바뀔 수 있습니다. 이름과 출처를 하나씩 확인하고 필요하면 한 그룹으로 범위를 좁혀 작업하세요. 항목이 규칙에서 참조되는지 확실하지 않다면 삭제 후 연결 실패로 관계를 추측하지 말고 먼저 보존한 채 참조를 확인하세요. 삭제는 관리 작업이지 일반적인 문제 해결의 첫 단계가 아닙니다. 기존 상태를 비교할 수 있게 남겨 두면 원인을 찾는 데 도움이 됩니다.

서로 다른 유형의 데이터를 고려해 백업하세요

완전히 복원하려면 원본 구독 주소, 직접 입력한 서버 매개변수, Config 파일과 다시 설정해야 하는 앱 옵션이 필요할 수 있습니다. 서버 공유 링크 하나만 백업해서는 구독 업데이트 주소를 대신할 수 없는 경우가 많습니다. Config를 백업해도 서버 인증 정보까지 포함되었다는 뜻은 아닙니다. 앱에서 실제로 제공하는 내보내기 또는 백업 기능을 사용할 때는 항목 설명을 읽고 범위를 확인하세요. 파일 이름이나 크기만으로 내용이 완전하다고 판단하지 마세요.

백업 파일에는 비밀번호, UUID, 키 또는 구독 인증 정보가 포함될 수 있으므로 본인이 관리하고 접근 보호가 적용되는 위치에 보관하세요. 일반 문서처럼 공개적으로 공유하지 말고 알아보기 쉽도록 인증 값을 파일 이름에 적지도 마세요. 기기를 수리 맡기거나 넘기거나 교체하기 전에 로컬 파일, 사진에 저장한 QR 코드와 클립보드에 관련 정보가 남아 있는지 확인하세요. 백업을 보호한다는 것은 사본을 보관하는 것뿐 아니라 어떤 계정과 기기가 그 사본에 접근할 수 있는지도 제한하는 것입니다.

복원 검증과 앱 재설치는 별도로 진행하세요

기기를 바꾸거나 앱을 다시 설치하기 전에 복원에 필요한 자료를 보유했는지 확인한 뒤 기존 기기를 처리하세요. 앱은 App Store에서 다시 받으세요. 구입 항목 복원과 구매 적용 범위는 구입 항목 복원 안내를 참고하고, 시스템 요구사항은 App Store 페이지에 표시된 내용을 기준으로 확인하세요. 앱 재설치와 서버 데이터 복원은 별개의 작업입니다. 구매 기록이 모든 로컬 설정을 함께 복원한다고 가정하지 말고, 시스템 백업이 있다는 이유만으로 실제 복원이 성공했다고 판단하지 마세요.

대상 기기에 복원한 뒤 데이터 유형별로 하나씩 확인하세요. 구독 주소가 있고 업데이트할 수 있는지, 직접 입력한 항목의 필드가 완전한지, Config가 선택되어 있는지, 관련 정책 이름이 유효한지 살펴보세요. 마지막으로 사용할 서버를 선택하고 Global Routing을 확인한 다음 Connectivity Test를 실행하고 실제 대상에 요청해 보세요. 전체 절차를 마쳐야 현재 필요에 백업을 사용할 수 있다고 판단할 수 있습니다. 백업 파일이 열리거나 몇 개의 이름이 표시되는 것은 복원 과정의 중간 단계일 뿐입니다.

백업이나 공유 자료가 유출되었다고 의심되면 본인이 관리하는 기존 서비스에서 해당 인증 정보를 처리하고 앱의 기록을 업데이트하세요. 로컬 사본만 삭제해도 이미 노출된 인증 값은 바뀌지 않습니다. 복원 검증이 끝나면 필요에 따라 오래된 사본을 정리하되, 범위와 용도를 확인한 백업 하나는 보관하세요. 일상적인 관리에서는 ‘근거를 먼저 보존하고, 상태를 변경한 뒤, 결과를 확인하는’ 순서를 따르는 것이 문제가 생긴 뒤 정보를 다시 조합하는 것보다 안전합니다.