01 / SUBSCRIBE
Subscribe 메뉴와 데이터의 차이
구독, 서버, Config 구분하기
구독은 서버 목록을 가져오는 주소이고, 서버 항목은 연결에 필요한 구체적인 설정이며, Config는 규칙과 관련 설정을 저장합니다. 서로 함께 사용할 수 있지만 서로를 대신할 수는 없습니다. 일반 웹페이지 주소를 Subscribe에 입력해도 연결 가능한 서버가 자동으로 만들어지지 않습니다. 서버 공유 링크를 규칙 파일로 가져와도 기대한 트래픽 분리 동작을 얻을 수 없습니다. 여러 메뉴를 무작정 시도하기보다 먼저 보유한 정보의 용도를 확인하세요.
구독을 업데이트하면 일반적으로 주소를 통해 서버 정보 목록을 가져옵니다. 목록에는 주소, 포트, 프로토콜 및 인증 정보가 포함될 수 있습니다. 구독은 ‘목록을 어디에서 업데이트할지’를 정하는 것이며, 목록 중 특정 서버가 선택되었거나 연결이 켜졌다는 뜻은 아닙니다. 서버 이름이 표시된 뒤에도 항목을 확인하고 서버를 선택한 다음, 필요에 따라 Global Routing을 설정해야 합니다. 가져오기 성공, 연결 성공, 대상 서비스 사용 가능 여부는 각각 따로 확인해야 합니다.
이 장은 사용자가 자신의 구독을 보유하고 있다는 전제로 설명합니다. 준비할 때 구독 주소 원문과 기존 서비스 안내에 기재된 형식, 인증 방식, 업데이트 조건을 보관하세요. 관리 페이지, 로그인 페이지 또는 결제 내역 페이지의 주소를 구독 주소로 사용하지 마세요. 같은 도메인의 주소라도 반환하는 데이터는 다를 수 있습니다. 브라우저에서 페이지가 열린다고 해서 Subscribe가 해당 주소를 해석할 수 있는 것은 아닙니다.
Add Server에서 구독 항목 만들기
Home에서 추가 메뉴를 찾아 Add Server로 이동한 뒤 Type을 확인합니다. 구독을 추가하려면 Subscribe를 선택하고 전체 구독 주소를 입력하세요. 용도를 알아볼 수 있도록 이름이나 메모를 지정한 다음 저장합니다. 기기에 따라 메뉴 배치가 다를 수 있으므로 실제 화면을 기준으로 하세요. 중요한 점은 구독 항목을 만들고 있는지 확인하는 것입니다. 특정 프로토콜의 서버 주소 입력란에 전체 URL을 붙여 넣지 마세요. 저장하기 전에 주소를 처음부터 끝까지 다시 확인하세요.
구독 주소의 경로와 쿼리 매개변수는 대개 주소를 식별하는 데 사용되므로 도메인만 남겨서는 안 됩니다. 복사할 때 마침표, 따옴표, 줄바꿈 또는 앞쪽 공백이 포함되었는지 특히 확인하세요. 줄바꿈될 수 있는 메시지에서 복사한 주소는 화면에서 줄이 바뀌어 보여도 실제 줄바꿈이 아닐 수 있습니다. 보이는 모양만 보고 손으로 이어 붙이지 마세요. 원문을 복사한 뒤 처음과 끝, 주요 매개변수를 확인하는 편이 긴 주소를 다시 입력하는 것보다 안전합니다.
저장한 뒤 한 번 업데이트하고 구독 아래에 서버 항목이 나타나는지 확인하세요. 목록 개수가 기존 서비스 안내와 맞는지, 이름을 알아보기 쉬운지, 프로토콜 항목이 온전한지 살펴봅니다. 계정 권한과 원격 목록에 따라 내용이 달라지므로 특정 개수를 기대할 필요는 없습니다. 결과가 비어 있다면 기존 목록을 바로 삭제하지 말고 먼저 업데이트 오류나 반환된 콘텐츠 유형을 확인하세요. 원래 기록을 남겨 두면 주소가 변경되었는지 비교하는 데 도움이 됩니다.
반복 확인을 위한 첫 기준 만들기
첫 업데이트가 끝나면 설정이 명확한 서버 하나를 골라 확인 대상으로 삼고, 당시의 로컬 네트워크, Global Routing 상태 및 테스트 대상을 기록하세요. 구독 주소, 규칙 파일, 네트워크 환경을 동시에 바꾸면 실패 원인을 찾기 어렵습니다. 이전에 작동하는 설정이 있었다면 그대로 둔 채 구독만 가져와 목록을 확인하세요. 그러면 가져오기 문제와 규칙 문제를 구분할 수 있습니다.
일부 구독에는 데이터 사용량이나 유효 기간 등의 추가 정보가 표시될 수 있습니다. 이 정보는 원격에서 반환되는 데이터이며 클라이언트는 이를 표시할 뿐입니다. 표시된 상태만으로 실제 연결 가능 여부를 판단할 수는 없습니다. 반대로 추가 정보가 표시되지 않아도 구독이 유효하지 않다는 뜻은 아닙니다. 업데이트 완료 여부, 항목 해석 가능 여부, 선택한 서버가 기대한 연결을 설정하는지를 기준으로 판단하고, 필요하면 기존 서비스의 계정 상태도 확인하세요.
| 항목 | 담당하는 기능 | 이 정보만으로 판단할 수 없는 내용 |
|---|---|---|
| Subscribe | 서버 목록 가져오기 및 업데이트 | 현재 연결이 반드시 사용 가능함 |
| 서버 항목 | 프로토콜, 주소, 포트 및 인증 | 규칙이 올바르게 적용됨 |
| Config | 규칙 및 관련 설정 | 구독 인증 정보가 여전히 유효함 |
처음 가져오기에 성공했을 때 간단히 기록해 두는 것이 좋습니다. 구독 용도, 추가 방법, 마지막으로 성공을 확인한 환경, 별도의 수동 서버가 있는지 등을 적어 두세요. 인증 정보를 그대로 기록할 필요는 없으며, 안전하게 저장한 위치를 적어 두면 됩니다. 나중에 업데이트가 실패하면 이 기준을 바탕으로 확인하고 모든 설정을 초기화하지 마세요. 연결 절차는 사용 설명서를 참고하세요.
02 / ADD SERVER
Add Server 수동 입력 항목과 프로토콜 확인
먼저 Type을 선택한 뒤 공통 항목 입력하기
수동 추가는 완전한 서버 설정 정보를 이미 보유하고 있거나, 단일 항목을 확인해야 하거나, 별도의 테스트 기록을 남기려는 경우에 적합합니다. Add Server로 이동해 먼저 Type을 선택한 다음 나머지 항목을 입력하세요. 프로토콜마다 항목의 의미가 다르므로 주소와 포트를 사용한다고 해서 유형을 서로 바꿔 선택할 수는 없습니다. Type을 변경한 뒤에는 입력한 내용도 다시 확인하세요. 이전 항목이 남아 있거나 인증 방식이 맞지 않거나 선택 항목이 기본값으로 바뀌었을 수 있습니다.
서버 주소에는 일반적으로 도메인이나 IP 주소를 입력합니다. 주소 입력란에는 웹 프로토콜 접두사, 경로, 전체 쿼리 매개변수를 넣지 않습니다. 포트는 별도의 포트 입력란에 입력하세요. 보유한 정보가 전체 공유 링크라면 일부만 임의로 떼어 입력하지 말고 가져오기 기능을 우선 사용하세요. IPv6 주소에는 콜론이 포함되므로 직접 입력할 때 주소 본문과 포트를 구분해야 합니다. 눈에 보이는 마지막 구분 기호만 보고 판단하지 마세요.
이름이나 메모는 로컬에서 항목을 식별하기 위한 것으로 인증 정보가 아닙니다. 용도와 출처를 기준으로 이름을 정하되 비밀번호, 전체 구독 주소, 개인 키는 입력하지 마세요. 저장한 뒤 항목을 다시 열어 Type, 주소, 포트, 인증 정보가 원본과 일치하는지 확인하세요. 입력 내용이 마스킹되어 보여도 올바르다는 뜻은 아닙니다. 복사·붙여넣기 시 앞뒤 공백이 들어갈 수도 있으므로 원본 자료와 항목별로 대조하세요.
프로토콜별 매개변수는 한 세트로 일치해야 합니다
Shadowsocks에서는 암호화 방식과 비밀번호를 확인해야 하며 둘 다 서버 측 설정과 일치해야 합니다. VMess, VLESS 등은 각각의 식별 정보와 전송 설정을 확인해야 합니다. 한 프로토콜의 비밀번호 개념을 다른 프로토콜에 그대로 적용하지 마세요. Trojan에서는 인증 정보와 TLS 관련 설정도 확인해야 합니다. 목표는 어디서나 통하는 공통 설정을 찾는 것이 아니라 기존 서비스가 제공한 설정을 정확히 재현하는 것입니다.
TLS 서버 이름, 연결 주소, 전송 계층의 Host는 서로 같을 수도 있고 의도적으로 다를 수도 있습니다. 연결 주소는 처음 연결할 대상을 정하고, 서버 이름은 TLS 신원 확인에 사용되며, Host나 경로는 상위 전송 설정에 속할 수 있습니다. 세 항목을 보기 좋게 통일하려고 모두 서버 IP로 바꾸지 마세요. 특히 연결 주소가 IP여도 올바른 서버 이름은 도메인일 수 있으므로 원본 정보를 그대로 유지해야 합니다.
WireGuard의 개인 키, 공개 키, 인터페이스 주소, 피어 주소는 각각 용도가 다릅니다. 전체 설정을 특정 입력란 하나에 임의로 넣지 마세요. Hysteria2의 인증 및 TLS 항목도 서버 설정에 맞춰야 하며, 로컬 네트워크에서 UDP를 사용할 수 있는지는 별도로 확인해야 합니다. 전송 특성은 Hysteria2 및 QUIC 안내에서 확인할 수 있지만, 이를 근거로 설정 확인을 생략해서는 안 됩니다.
| 항목 그룹 | 확인할 내용 | 자주 발생하는 오류 |
|---|---|---|
| 주소 및 포트 | 연결 대상 및 포트 번호 | 전체 URL을 주소 입력란에 입력함 |
| 인증 | 비밀번호, 식별자 또는 키 | 문자 누락, 여분의 공백, 항목 위치 오류 |
| TLS | 활성화 상태 및 서버 이름 | 연결 IP를 인증용 도메인 대신 사용함 |
| 전송 | 유형, 경로 및 Host | 임의로 슬래시를 추가하거나 대소문자를 변경함 |
저장한 뒤 항목을 한꺼번에 바꾸지 말고 단계별로 확인하기
수동 입력을 처음 마친 뒤 서버 도메인이 해석되는지 확인하고, 다음으로 전송 연결이 설정되는지, 마지막으로 대상 요청이 예상한 경로를 거치는지 확인하세요. 인증 실패, TLS 확인 실패, 연결 시간 초과는 서로 다른 문제입니다. 시간 초과가 발생했다고 바로 비밀번호를 바꾸거나 인증 오류가 발생했다고 먼저 규칙을 변경하지 마세요. 화면에 구체적인 오류가 표시되면 오류 유형과 발생 단계를 기록하세요. 단순히 ‘작동하지 않음’이라고 적는 것보다 진단에 도움이 됩니다.
인증서 확인을 끄는 것을 일반적인 해결책으로 사용하지 마세요. 서버 이름 오류, 기기 시간 문제, 원격 인증서 이상 같은 실제 원인을 가릴 수 있습니다. 먼저 원본 정보, 기기 시간, 연결 대상을 확인한 다음 전송 설정을 살펴보세요. 특정 옵션의 의미와 적용 범위, 위험을 이해한 경우에만 변경하고 테스트 기록에 남기세요. 그래야 임시 진단 설정을 정상 설정으로 오인하지 않습니다.
구독에서 생성된 서버를 직접 수정하면 다음 업데이트에서 원격 정보로 덮어써질 수 있습니다. 테스트가 필요하다면 화면에서 지원하는 경우 독립 복사본을 만들고 용도를 표시해 구독 원본과 이름이 겹치지 않도록 하세요. 매번 하나의 항목만 변경하고 테스트한 뒤 유지할지 원래대로 복원할지 결정합니다. 수동 기록이 유효한지 확인한 다음 기존 서비스 설정을 점검하는 과정에 차이를 반영하세요. 출처가 불분명한 복사본을 여러 개 장기간 유지해 문제를 해결하려 하지 마세요.
03 / IMPORT
QR 코드 및 클립보드 가져오기 순서
Scan QR Code는 입력 방식만 바꿉니다
QR 코드는 텍스트를 담는 형식입니다. 단일 서버 링크, 구독 주소 또는 일반 웹페이지가 들어 있을 수 있습니다. Scan QR Code를 사용하기 전에 QR 코드가 자신의 구독 또는 서버 정보를 가리키는지 확인하세요. 인식 성공은 텍스트를 읽었다는 뜻일 뿐, 현재 메뉴에서 사용할 수 있는 형식이거나 서버 연결 확인까지 완료되었다는 뜻은 아닙니다. 스캔 후 인식된 항목의 종류를 확인하고 저장 여부를 결정하세요.
카메라로 스캔하면 시스템에서 카메라 권한을 요청할 수 있습니다. 이전에 권한을 거부했다면 목록을 계속 다시 가져오는 대신 시스템의 앱 권한 설정을 확인하세요. 촬영 거리를 조절하고 반사를 피하며 QR 코드 전체가 보이도록 하면 인식 문제와 형식 문제를 구분하는 데 도움이 됩니다. QR 코드 가장자리가 잘렸거나 너무 작게 표시되거나 다른 그림에 가려져 있으면 전체 내용을 읽지 못할 수 있습니다. 이는 서버 설정의 정확성과는 별개입니다.
QR 코드와 앱이 같은 기기에 있다면 실제 화면에서 제공하는 이미지 인식 기능을 사용할 수 있습니다. 해당 기능이 없다면 원본 링크를 복사해 클립보드로 가져오세요. 인증 정보가 포함된 이미지를 공개 인식 사이트에 올려 스캔을 완료하려 하지 마세요. 보관해야 하는 QR 코드 이미지도 인증 정보 파일처럼 관리해야 합니다. 단순한 안내용 화면처럼 생각해 무심코 전달하지 마세요.
클립보드로 가져올 때는 원문을 확인한 뒤 결과를 검증하세요
복사할 때는 전체 링크만 선택하고 설명 문구, 번호, 글머리 기호, 문장 끝의 문장 부호는 함께 복사하지 마세요. 붙여넣은 내용을 읽을지 시스템에서 물으면 직접 시작한 작업인지 확인한 후 허용하세요. 앱에서 예상한 내용을 읽지 못했다면 텍스트 출처로 돌아가 다시 복사하고, 인증 코드나 검색어 등 다른 내용을 복사해 클립보드가 바뀌지 않았는지 확인하세요. 곧바로 가져오기 기능이 고장 났다고 판단하지 마세요.
여러 링크가 포함된 텍스트도 있지만 출처에 따라 구분 방식이 다릅니다. 줄바꿈이 있는 모든 텍스트를 한 번에 가져올 수 있다고 가정하지 마세요. 먼저 완전한 링크 하나로 형식과 항목이 올바른지 확인한 다음 나머지를 처리하세요. 결과가 예상보다 적으면 빈 줄, 줄바꿈, 설명 문구를 확인하고 비교를 위해 원문을 보관하세요. 가져오기 버튼을 반복해서 누르면 중복 항목만 늘어날 수 있으며 잘린 링크가 복구되지는 않습니다.
구독 주소를 가져오면 일반적으로 업데이트 가능한 기록이 생성되고, 단일 서버 링크를 가져오면 보통 독립 항목 하나가 생성됩니다. 나중에 목록을 자동으로 업데이트하려고 했는데 일반 서버 하나만 보인다면 어떤 유형의 정보를 복사했는지 다시 확인하세요. 반대로 구독 QR 코드를 스캔한 뒤 여러 항목이 나타나는 것은 자연스러운 결과입니다. 그래도 구독 기록이 함께 저장되었는지 확인하세요. 목록 개수만으로 가져오기 방식을 판단해서는 안 됩니다.
‘인식, 해석, 연결’을 나눠 문제 해결하기
첫 단계는 인식입니다. 카메라나 이미지 인식 기능이 텍스트 전체를 추출하는지 확인합니다. 두 번째는 해석입니다. 추출한 프로토콜 형식을 앱이 인식하고 필요한 항목을 찾는지 확인합니다. 세 번째가 연결입니다. 서버에 접근할 수 있는지, 인증이 통과하는지, 요청이 예상한 규칙에 일치하는지 살펴봅니다. QR 코드가 전혀 반응하지 않는다면 첫 단계부터 확인하세요. 항목은 나타났지만 연결에 실패했다면 스캔 자세를 바꾸는 것은 대개 도움이 되지 않습니다.
가져온 직후 새 항목의 편집 화면을 열어 Type, 주소, 포트, 인증 및 TLS 설정을 중점적으로 확인하세요. 링크의 확장 매개변수가 서로 다른 해석 방식에서 모두 동일하게 처리된다고 보장할 수는 없습니다. 따라서 ‘저장됨’이 수동 확인을 대신하지 않습니다. 기존 자료에서 경로, 서버 이름 또는 전송 방식이 명시되어 있는데 화면에 나타나지 않는다면 해당 항목을 추가하거나 올바른 형식의 자료를 다시 받은 뒤 연결을 테스트하세요.
‘지원하지 않는 형식’과 같은 결과가 표시되면 먼저 원본 링크를 복사했는지, 메신저에서 감싼 리디렉션 페이지를 복사했는지 확인하세요. 가져오기를 강제로 진행하려고 프로토콜 접두사를 바꾸거나 이해하지 못한 쿼리 매개변수를 삭제하지 마세요. 매개변수는 TLS 또는 전송 동작을 결정할 수 있습니다. 삭제 후 저장되더라도 의미가 달라진 기록이 될 수 있습니다. 형식 확인은 다음 장을 참고하고 연결 단계 문제는 문제 해결을 확인하세요.
가져오기가 끝나면 새 항목의 출처를 확인하고, 실수로 생성된 중복 기록을 삭제한 뒤 더 이상 필요하지 않은 인증 정보 이미지를 정리하세요. 클립보드의 민감한 텍스트를 관계없는 일반 텍스트로 바꿀 수 있지만, 다른 기기나 앱에 이미 저장된 복사본까지 삭제되는 것은 아닙니다. 전체 링크를 통제할 수 없는 곳에 보냈다면 기기에서 가져온 항목만 삭제하지 말고 기존 서비스의 관리 절차에 따라 관련 인증 정보를 변경하세요.
05 / UPDATE POLICY
구독 업데이트 방법과 실패 시 복구
업데이트는 목록을 바꾸므로 단순히 화면만 새로 고치는 것이 아닙니다
구독 업데이트는 기존 주소에 다시 요청을 보내고 반환된 데이터로 관련 서버 기록을 갱신하는 작업입니다. 원격에서 항목이 추가, 삭제 또는 수정될 수 있으므로 단순히 ‘다시 연결 테스트’하는 것과 다릅니다. 업데이트 전에 목록 변경과 연결 상태 변경을 구분하세요. 주소에서 데이터를 성공적으로 가져와도 목록의 모든 서버를 사용할 수 있다는 뜻은 아닙니다. 기존 서버에 연결되더라도 구독 주소의 인증이 유효하다는 보장은 없습니다. 두 연결은 별도로 바뀔 수 있습니다.
직접 수정한 구독 항목이 반드시 유지된다고 가정하지 마세요. 원격 기록과 로컬 기록의 연결 방식은 이름, 식별자, 앱 처리 방식의 영향을 받을 수 있습니다. 장기간 보존해야 할 수동 변경 사항은 별도의 기록이나 지원되는 로컬 관리 방식으로 보관하고 원격 원본과 다르다는 점을 표시하세요. 그렇지 않으면 업데이트 후 항목이 덮어써졌는지, 다시 만들어졌는지, 같은 이름의 다른 서버를 선택했는지 파악하기 어렵습니다.
업데이트하기 전에 현재 사용 중인 구독과 서버, 복원 가능한 백업이 있는지 확인하세요. 안정적으로 작동하는 환경이라면 모든 기기에서 동시에 업데이트할 필요는 없습니다. 먼저 한 기기에서 업데이트해 변화를 확인하고 테스트한 뒤 다른 기기를 처리하세요. 이렇게 하면 새 목록의 실제 영향을 확인할 수 있고 문제가 생겼을 때 비교할 원래 상태도 보존할 수 있습니다. 모든 기기에서 기준 상태를 한꺼번에 잃는 일을 방지할 수 있습니다.
변경 빈도에 맞춰 업데이트 주기 정하기
업데이트 빈도는 기존 서비스의 요구 사항과 목록 변경 주기에 맞춰야 하며 자주 할수록 좋은 것은 아닙니다. 같은 주소에 연속으로 요청하면 원격 요청 제한에 걸릴 수 있고 문제 기록의 시간 순서도 흐려집니다. 화면에 자동 업데이트 옵션이 있다면 실제 의미를 먼저 읽고 실행 조건과 네트워크 요구 사항을 확인하세요. 모바일 시스템의 백그라운드 예약은 기기 상태의 영향을 받으므로 특정 간격을 설정했다고 정확한 시간에 실행된다고 보장할 수 없습니다.
수동 업데이트는 처음 추가할 때, 기존 서비스의 변경 안내를 받았을 때, 목록이 오래되었다고 의심될 때 또는 유지 관리 시간에 변경을 관리하려는 경우에 적합합니다. 업데이트한 뒤 항목 변화, 현재 선택 항목, 실제 연결을 확인하세요. 새로 고침이 끝났는지만 보지 마세요. 기존 항목이 제거되었다면 목록에 남아 있는 항목을 다시 선택하고 테스트해야 합니다. 이름이 비슷하다는 이유로 새 항목이 기존 설정을 모두 유지한다고 가정하지 마세요.
구독 데이터를 가져오는 네트워크 경로도 업데이트 결과에 영향을 줄 수 있습니다. 서버 연결은 되지만 구독 업데이트가 실패한다면 현재 로컬 네트워크에서 구독 리소스에 접근할 수 있는지, 도메인 해석이 정상인지, 주소에 별도 인증이 필요한지 확인하세요. 네트워크 전환은 비교 테스트로 사용할 수 있지만 한 번에 조건 하나만 바꾸고 결과를 기록하세요. 목록을 가져오려고 Config 전체를 임의로 변경하지 마세요. 업데이트 경로와 실제 연결 문제를 뒤섞게 됩니다.
실패 유형을 먼저 구분한 뒤 복구 여부를 결정하세요
연결 시간 초과는 보통 요청이 제한 시간 안에 완료되지 않았다는 의미지만, 원인은 도메인 해석, 네트워크 경로, 원격 응답 등 다양합니다. 시간 초과만으로 원인을 단정할 수는 없습니다. 인증 관련 오류가 반환되면 전체 주소가 변경되었는지, 인증 정보가 여전히 유효한지, 기존 서비스에서 링크를 다시 생성해야 하는지 확인하세요. 웹페이지나 인증 페이지가 반환되면 네트워크 요청 자체는 성공했더라도 앱이 서버 목록으로 해석하지 못할 수 있습니다.
해석 오류와 빈 목록도 구분해 처리하세요. 해석 오류는 형식 변경, 내용 잘림, 지원되지 않는 항목에서 발생할 수 있습니다. 빈 목록은 원격에서 사용할 수 있는 항목을 반환하지 않았을 수 있습니다. 원래 주소와 오류 정보를 보관하고 기존 서비스 안내를 확인하세요. 필요하다면 인증 정보를 보호하면서 반환된 콘텐츠 유형을 확인합니다. 빈 결과를 여러 구독 그룹에 반복해서 가져오거나 백업 없이 기존 기록 전체를 덮어쓰지 마세요.
업데이트 후 일부 서버만 작동하지 않는다면 해당 항목의 프로토콜, 주소, 전송 방식이 바뀌었는지 먼저 비교한 뒤 목록의 다른 알려진 항목을 테스트하세요. 하나가 실패했다고 구독 전체를 삭제하거나 대량으로 재시도하지 마세요. 새 항목이 현재 네트워크 조건과 맞지 않는다면 사용 가능한 항목을 유지하면서 원인을 확인하는 편이 같은 구독을 반복해서 가져오는 것보다 분명한 결과를 얻기 쉽습니다. 자세한 분류 방법은 문제 해결을 참고하세요.
업데이트는 새로 고침 애니메이션이 멈췄을 때가 아니라 목록 확인과 주요 용도 테스트를 마쳤을 때 완료된 것으로 봐야 합니다. 성공 또는 실패 단계, 필요한 복구 자료를 기록하고 다음 자동 업데이트가 임시 수정을 바로 덮어쓰지 않는지 확인하세요. 인증 정보를 변경했다면 다른 기기에서 이전 주소를 계속 사용하는지도 점검하고 기기별로 업데이트하세요. 그래야 서로 다른 기기의 결과를 같은 업데이트의 결과로 오해하지 않습니다.
06 / ORGANIZE
여러 구독 정리와 규칙 참조
먼저 출처를 구분하고 표시 순서를 정하세요
이미 보유한 여러 구독을 함께 관리할 때는 서버를 긴 목록 하나로 합치는 것보다 각 서버가 어느 구독에서 생성되었는지 파악하는 것이 중요합니다. 구독에는 용도를 구분할 수 있는 간결하고 안정적인 이름을 사용하세요. 출처와 용도는 구독 이름에, 개별 차이는 서버 메모에 기록합니다. 테스트 결과에 따라 계속 바뀌는 이름을 쓰면 다음 업데이트나 정렬 후 같은 항목을 찾기 어려워집니다.
이름은 ‘용도—출처 코드—추가 설명’ 형식으로 정할 수 있습니다. 출처 코드는 직접 정하면 되며 전체 도메인이나 계정 정보까지 포함할 필요는 없습니다. 두 구독에서 같은 이름의 항목이 반환되면 먼저 각 출처를 유지하고 실제 중복인지 판단하세요. 이름이 같다고 주소, 인증, 전송 설정까지 같은 것은 아닙니다. 반대로 이름이 달라도 실제 연결 대상이 같을 수 있습니다. 표시 이름만 비교하지 말고 주요 설정을 기준으로 중복을 판단하세요.
수동 서버는 구독에서 생성된 기록과 명확히 구분해야 합니다. 메모에 독립 기록, 테스트 복사본, 장기 보관 항목 중 무엇인지 표시하고 설정을 다시 확인해야 하는 시점을 기록할 수 있습니다. 임시 수정 복사본을 유일하게 사용할 서버처럼 장기간 유지하면서 원래 구독도 계속 업데이트된다는 사실을 잊지 마세요. 출처를 명확히 해야 원격에서 관리할 변경과 직접 관리할 변경을 구분해 서로 덮어쓰는 일을 줄일 수 있습니다.
서버 목록과 Global Routing은 서로 다른 역할을 합니다
목록을 정리해도 트래픽의 규칙 적용 방식이 자동으로 바뀌지는 않습니다. Global Routing의 Config, Proxy, Direct는 서로 다른 작동 방식입니다. Config는 현재 설정에 따라 요청 경로를 결정하고, Proxy는 일반적인 트래픽을 선택한 프록시 경로로 전달하며, Direct는 직접 연결합니다. 실제 요청에는 시스템 제한이나 관련 설정도 영향을 줄 수 있으므로 문제를 확인할 때 이 상태를 완전히 같은 스위치로 취급하지 마세요.
현재 Direct 상태라면 서버를 선택하고 목록을 정리했더라도 요청이 해당 서버를 거친다고 단정할 수 없습니다. Config 상태라면 규칙이 테스트 대상에 PROXY를 적용하는지 확인해야 합니다. 상태 전환은 비교 테스트에 사용할 수 있지만 테스트 후에는 일상적으로 사용하는 설정으로 되돌리세요. 특정 대상에 임시로 연결하려다가 기존 규칙 기반 분기 방식에서 벗어난 상태를 잊으면 이후 판단이 혼란스러워질 수 있습니다.
아래는 Shadowrocket .conf 규칙 구문 예시로, 순서와 경로를 설명하기 위한 것이며 서버 인증 정보는 포함하지 않습니다. 규칙은 일반적으로 위에서부터 순서대로 적용됩니다. 앞선 규칙과 일치한 요청을 마지막 행이 다시 결정하지는 않습니다. 예시 도메인은 실제 테스트용이 아닙니다. 자신의 설정에 추가하기 전에 기존 규칙의 위치와 정책 참조를 확인해 중복된 최종 규칙이 이후 내용을 가리지 않도록 하세요.
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
GEOIP,CN,DIRECT
FINAL,PROXY정리할 때도 변경 범위를 관리하세요
Config의 정책 그룹이 특정 서버 이름이나 필터 조건을 참조한다면 항목 이름 변경, 이동, 삭제가 선택 가능한 구성원에 영향을 줄 수 있습니다. 이름을 통일하기 전에 Config에 관련 참조가 있는지 확인하세요. 구독 업데이트 후 정책 그룹이 비어 있다면 원격에서 이름이 바뀌어 필터 조건이 더 이상 일치하지 않는 것일 수 있습니다. 구독에 항목이 있는지, 조건이 일치하는지, 정책에서 무엇을 선택했는지 단계별로 확인하세요.
| Global Routing | 문제 확인 시 점검할 항목 | 정리만으로 해결되지 않는 작업 |
|---|---|---|
| Config 설정 | 규칙 순서 및 정책 참조 | 요청에 실제 적용된 규칙 확인 |
| Proxy | 현재 선택된 프록시 경로 | 프로토콜 및 대상의 사용 가능 여부 확인 |
| Direct | 로컬 네트워크 직접 연결 결과 | 특정 서버를 사용했다는 증거 |
화면이 복잡해 보이는 항목은 삭제하기 전에 필터나 접기 같은 표시 기능이 있는지 확인하세요. 원격 구독에서 계속 제공하는 서버를 삭제해도 다음 업데이트 후 다시 나타날 수 있습니다. 계속 수동 삭제하는 방식은 안정적인 관리 방법이 아닙니다. 이름 필터를 사용한다면 적용 범위를 확인해 비슷한 이름의 사용 가능한 항목까지 제외하지 않도록 하고 원격 이름이 바뀐 후 결과를 다시 확인하세요.
여러 기기의 목록을 정리할 때 ‘배열이 같다’는 것을 ‘설정이 완전히 같다’는 의미로 받아들이지 마세요. 기기마다 네트워크가 다르거나 다른 Config를 선택했을 수 있으며, 한 기기에만 수동 항목이 남아 있을 수도 있습니다. 옮기기 전에 구독 주소, 중요한 규칙, 기본 선택 항목 등 실제로 일치시켜야 하는 내용을 정하세요. 로컬 테스트 결과나 임시 정렬 순서는 복사할 필요가 없을 수 있습니다. 불필요한 데이터와 오래된 상태를 다른 기기로 옮기는 일을 줄일 수 있습니다.
정리를 마칠 때마다 세 가지를 확인하세요. 주요 용도에 사용할 항목을 선택할 수 있는지, 정책 참조에서 구성원이 누락되지 않았는지, 백업 설명으로 새 이름 규칙을 이해할 수 있는지 확인합니다. 여러 구독 병합, 이름 변경, 중복 제거, 규칙 교체를 한꺼번에 한 뒤 테스트하지 마세요. 구독별로 처리하고 각 그룹을 확인한 다음 다음 단계로 넘어가세요. 결과를 설명하고 복원할 수 있어야 긴 목록보다 관리하기 쉬워집니다. 겉으로만 깔끔한 것은 충분하지 않습니다.
07 / CONNECTIVITY TEST
지연 시간 테스트, 정렬 및 실제 사용 가능 여부
먼저 무엇을 테스트하는지 확인하세요
Connectivity Test 결과는 구체적인 테스트 방식, 대상, 현재 네트워크 환경에 따라 달라집니다. 일부 테스트는 연결 설정 시간을 주로 확인하고, 다른 테스트는 프록시를 통한 대상 접근 응답도 포함할 수 있습니다. 숫자를 비교하기 전에 현재 사용 중인 방식을 확인하세요. 서로 다른 방식의 결과를 같은 기준으로 비교하지 마세요. 낮은 시간 값은 해당 테스트의 특정 단계만 설명할 뿐 지속적인 전송 속도나 전체 앱 사용 경험을 직접 나타내지 않습니다.
지연 시간, 처리량, 안정성은 서로 다른 기준입니다. 웹페이지를 처음 열 때는 이름 해석과 연결 설정이 영향을 주고, 대용량 파일 전송은 지속적인 처리량의 영향을 더 많이 받습니다. 통화나 상호작용에는 지터와 패킷 손실이 중요할 수 있습니다. 테스트 결과를 정렬하면 문제 범위를 좁히는 데 도움이 되지만 실제 용도 확인을 대신하지는 못합니다. 후보 항목을 고른 뒤에는 자신의 실제 작업에서 연결이 안정적인지 확인하세요. 목록 맨 위에 있다는 이유만으로 다른 문제를 무시하지 마세요.
테스트 시간 초과도 원인을 하나로 단정할 수 없습니다. 서버에 접근할 수 없거나 테스트 대상이 응답하지 않거나 현재 네트워크가 특정 전송을 제한하거나 앱의 테스트 방식이 해당 경로에 맞지 않을 수 있습니다. 테스트는 실패했지만 실제 요청은 정상이라면 테스트 대상과 방식을 확인하세요. 테스트와 실제 요청이 모두 실패하면 프로토콜, 인증, 네트워크 경로를 점검합니다. 두 결과를 따로 기록하면 테스트 대상의 문제를 서버 전체의 장애로 오해하지 않을 수 있습니다.
비교 가능한 테스트 조건 만들기
서버를 비교할 때는 같은 기기, 네트워크, 테스트 방법, 테스트 대상을 사용하고 백그라운드에서 대량 전송이 진행되지 않도록 하세요. 후보 항목을 몇 개 골라 먼저 테스트한 다음 잠시 후 다시 측정해 결과가 대체로 일치하는지 살펴봅니다. 우연히 낮게 나온 값이나 한 번의 시간 초과만으로 장기적인 품질을 판단할 수는 없습니다. 특히 모바일 네트워크 전환이나 기기 절전 모드에서 복귀한 뒤에는 결과를 해석하기 전에 현재 네트워크 상태를 확인하세요.
전체 목록 테스트는 많은 요청을 동시에 보낼 수 있으며 테스트 자체도 리소스를 사용합니다. 항목이 많다면 전부 반복해서 테스트하는 대신 용도나 프로토콜별로 필터링해 나눠 테스트하세요. 회의, 다운로드 또는 중요한 작업이 진행 중일 때 대량 테스트와 실제 사용을 함께 하지 않는 것이 좋습니다. 테스트 후 잠시 상태가 흔들리면 반복 테스트를 멈추고 기존 연결을 살펴보세요. 테스트 부하를 원격의 지속적인 문제로 오해하지 않도록 합니다.
로컬 네트워크의 영향을 확인하려면 Wi-Fi와 셀룰러 네트워크를 통제된 조건에서 비교할 수 있습니다. 단, 서버와 규칙을 동시에 바꾸지 마세요. 특정 프로토콜이 한 네트워크에서만 문제가 생긴다면 해당 프로토콜 항목을 전부 삭제하기보다 네트워크 조건을 확인해야 합니다. Hysteria2처럼 UDP를 사용하는 전송은 특히 로컬 네트워크 조건과 서버 설정을 구분해야 합니다. 구체적인 방법은 속도 저하 단계별 점검을 참고하세요.
정렬은 표시 방식일 뿐 연결을 보장하지 않습니다
지연 시간 순으로 정렬한 뒤 현재 선택된 서버가 바뀌었는지 확인하세요. 목록의 맨 위에 표시되는 항목, 선택된 항목, 정책에서 실제로 사용하는 항목은 서로 다를 수 있습니다. 목록 위치만 보고 연결 대상을 판단하지 마세요. Config의 정책 그룹을 사용한다면 그룹에서 다른 항목을 참조하는지도 확인해야 합니다. 정렬 후 실제 요청을 테스트하고 관련 기록을 확인해야 트래픽 경로가 예상과 일치하는지 알 수 있습니다.
테스트 결과는 환경에 따라 바뀌며 오래 보관한 숫자는 참고 가치가 떨어질 수 있습니다. 기기 네트워크가 바뀌거나 구독에서 주소를 업데이트하거나 서버 전송 설정이 변경되면 중요한 후보 항목을 다시 테스트하세요. 이전 정렬을 영구 우선순위로 취급하거나 원격에서 지정한 이름을 성능 보장으로 해석하지 마세요. 관리 기록에는 테스트 조건을 적고 맥락 없는 숫자 하나만 캡처하지 마세요.
모든 항목에서 동시에 시간 초과가 발생하면 서버를 하나씩 바꾸기 전에 잠시 멈추고 로컬 네트워크, 시스템 연결 상태, 테스트 대상의 접근 가능 여부를 확인하세요. 특정 구독의 항목만 실패한다면 업데이트 상태와 공통 설정을 비교하고, 여러 구독에서 같은 프로토콜이 실패한다면 로컬 네트워크와 해당 프로토콜 설정을 살펴보세요. 공통 특성을 기준으로 분류하면 항목을 하나씩 다시 만들기보다 빠르게 범위를 좁힐 수 있고 원래 증거도 보존할 수 있습니다.
최종 선택은 하나의 최소값이 아니라 구체적인 용도를 기준으로 해야 합니다. 현재 네트워크에서 확인한 후보 항목을 몇 개 유지하고 각각 어느 구독에 속하는지 기록한 뒤 연결에 문제가 생기면 같은 조건으로 다시 확인하세요. 한 번의 테스트 결과로 항목을 대량 삭제하지 마세요. 먼저 문제가 반복되는지 확인한 후 정리하거나 업데이트할지 결정하세요. 반복 가능한 비교 결과가 있어야 장기적인 관리 결정을 내릴 수 있습니다.
08 / BACKUP & RESTORE
삭제, 백업 및 복원 확인
삭제하기 전에 대상과 영향 범위를 확인하세요
서버 하나, 구독 전체, Config를 삭제하면 각각 다른 대상에 영향을 줍니다. 구독에서 제공하는 서버 하나를 삭제해도 다음 업데이트 때 다시 나타날 수 있습니다. 구독 기록을 삭제하면 작업 범위에 따라 관련 목록도 함께 제거될 수 있습니다. Config를 삭제하면 규칙과 다른 설정에 영향을 줄 수 있습니다. 실행 전에 확인 메시지를 읽고 현재 선택 항목이 해당 자료에 의존하는지 살펴보세요. 이름이 비슷하다는 이유만으로 여러 항목을 한꺼번에 처리하지 마세요.
중복 항목을 정리하기 전에 무엇을 중복의 기준으로 삼을지 정하세요. 주소가 같아도 포트, 인증, 전송 설정이 다를 수 있습니다. 서로 다른 구독에서 같은 이름의 항목이 반환되더라도 용도가 다를 수 있습니다. 확신이 들지 않는 항목은 바로 삭제하기보다 남겨 두고 메모를 추가하는 편이 안전합니다. 항목이 정책 그룹에서 참조된다면 목록을 줄이기 전에 참조를 수정하거나 대체 항목을 확인하세요. 그렇지 않으면 설정에서 선택 가능한 항목이 사라질 수 있습니다.
기기에서 삭제해도 원격 접근 권한이 취소되는 것은 아닙니다. 구독 주소가 유출된 경우 앱에서 기록을 삭제해도 다른 사람이 가진 복사본은 계속 유효할 수 있습니다. 서버 비밀번호와 개인 키도 마찬가지입니다. 권한을 취소하려면 기존 서비스의 인증 정보 관리 절차를 이용한 뒤 모든 기기의 기록을 업데이트하세요. 로컬 정리는 저장 범위 문제를 해결하고 원격 인증 정보 변경은 접근 권한 문제를 해결합니다. 서로 대신할 수 없습니다.
백업에는 데이터와 함께 범위에 대한 설명도 필요합니다
백업 전에 복원이 필요한 대상을 정리하세요. 구독 주소, 수동 입력한 독립 서버, Config 파일, 정책 선택, 다시 기억하기 어려운 로컬 설정 등이 포함될 수 있습니다. 앱에서 제공하는 내보내기나 백업 기능마다 포함 범위가 다를 수 있으므로 파일 하나에 모든 내용이 들어 있다고 가정하지 마세요. 실제 옵션과 설명을 확인하고 백업을 관리 가능한 위치에 저장한 뒤, 포함된 항목과 수동으로 다시 설정해야 할 내용을 기록하세요.
구독 주소로 목록을 다시 가져올 수는 있지만 수동 서버와 규칙 설정의 백업을 대신하지는 않습니다. 반대로 서버 설정이 포함된 오래된 목록도 앞으로 원격 변경 사항을 계속 업데이트할 수 있다고 보장하지 않습니다. 완전한 복원 계획에는 다시 가져올 수 있는 데이터와 로컬에서만 복원 가능한 데이터를 모두 고려해야 합니다. 원래 구독에서 생성된 항목의 표시 순서를 보존하려고 독립 복사본을 대량으로 만들 필요는 없습니다. 관리 출처를 잃을 수 있습니다.
백업 파일, 내보낸 공유 링크, QR 코드는 모두 민감한 자료로 취급하세요. 직접 관리할 수 있는 저장 위치를 선택하고 접근 범위를 제한하며 전체 파일을 공개적인 도움 요청에 첨부하지 마세요. 내보내기 기능에 암호화 또는 비밀번호 보호 옵션이 있다면 실제 보호 범위를 먼저 이해하고 복원에 필요한 비밀번호는 다른 안전한 위치에 저장하세요. 초기화하거나 교체할 기기에만 유일한 복원 비밀번호를 보관하지 마세요.
| 자료 | 복원 목적 | 추가 확인 사항 |
|---|---|---|
| 구독 기록 | 원격 목록 다시 가져오기 | 주소와 인증 정보가 유효한지 |
| 독립 서버 | 수동 설정 복원 | 프로토콜 및 인증 항목이 모두 있는지 |
| Config 파일 | 규칙 및 설정 복원 | 정책 참조에 해당 항목이 여전히 있는지 |
| 관리 안내 | 이름 및 임시 변경 사항 설명 | 유지하거나 되돌려야 할 변경 사항 |
복원이 끝났는지는 실제 테스트로 확인하세요
기기를 교체하거나 앱을 다시 설치한 뒤에는 먼저 앱을 설치하고 백업 범위에 따라 데이터를 복원하세요. iPhone / iPad에서 앱을 다시 받는 과정과 구독을 복원하는 과정은 별개입니다. 구입한 앱을 복원해도 서버 정보가 모두 자동으로 복원되는 것은 아닙니다. 다른 플랫폼은 전체 플랫폼 다운로드 페이지에서 앱을 받은 뒤 백업 형식과 대상 플랫폼에서 지원하는 가져오기 방법을 확인하세요. 한 플랫폼의 전체 백업이 다른 플랫폼의 설정을 그대로 대체한다고 가정하지 마세요.
복원할 때는 먼저 Config와 기존 자료를 가져와 대상이 모두 있는지 확인한 뒤 실제 의존 순서에 따라 정책 참조와 현재 선택 항목을 처리하는 것이 좋습니다. 대상 기기에 이미 일부 기록이 있다면 새 자료와 기존 자료를 계획 없이 합치지 않도록 현재 상태를 먼저 백업하세요. 이름이 같은 항목이 있어도 바로 일괄 삭제하지 말고 출처와 설정을 비교하세요. 한 그룹의 내용을 확인한 뒤 다음으로 진행하면 복원 중 원인을 알 수 없는 중복과 덮어쓰기를 줄일 수 있습니다.
처음 복원한 뒤 기존 기기의 자료를 모두 바로 삭제하지 마세요. 구독 업데이트가 가능한지, 수동 서버의 편집 화면을 열 수 있는지, 주요 규칙이 있는지, Global Routing이 예상한 상태인지 확인한 다음 실제 용도로 연결을 테스트하세요. 시스템에서 연결 권한을 다시 요청할 수 있습니다. 이 권한 상태는 일반 백업 항목으로 취급하지 말고 현재 기기의 안내에 따라 허용한 뒤 실제 연결 상태를 확인하세요.
복원 테스트에는 실패 상황도 포함해야 합니다. 구독 업데이트에 실패하면 원본 자료의 위치를 알고 있는지, 서버 항목이 제거되면 확인된 다른 선택 항목이 있는지, 설정 참조가 깨지면 관련 규칙과 정책을 찾을 수 있는지 점검하세요. 백업은 파일을 가져올 수 있다는 사실만으로 가치가 있는 것이 아닙니다. 변경이 발생했을 때 필요한 기능을 복구할 방법을 알고 있어야 합니다. 무엇이 들어 있는지 모르는 파일 하나만 저장해서는 신뢰할 수 있는 복구 계획이 되지 않습니다.
마지막으로 임시 내보내기 파일, 오래된 QR 코드, 더 이상 필요하지 않은 복사본을 정리하고 현재 상태를 설명할 수 있는 관리 기록 하나를 남기세요. 인증 정보를 변경했다면 이전 백업에 더 이상 공유해서는 안 되는 정보가 남아 있는지 확인하고 보관 정책에 따라 처리하세요. 일반적인 사용 절차는 빠른 시작 사용 설명서를, 구체적인 오류는 문제 해결을 참고하세요. 다음에 대규모 업데이트, 정리 또는 기기 이전을 하기 전에 이 장을 다시 확인해 백업 범위와 복원 절차를 점검하세요.