Shadowrocket
구독 및 서버 관리

Subscribe 메뉴와 구독 항목

구독 주소는 단일 서버의 주소가 아니라 연결 정보 묶음을 가져오는 경로입니다. 가져오면 앱은 일반적으로 구독 출처와 그 내용을 바탕으로 구성된 서버 항목을 함께 보관합니다. 구독 출처는 다음 업데이트 요청을 보낼 위치를 결정하고, 서버 항목은 현재 연결에 사용할 매개변수를 결정합니다. 서버 하나를 수정해도 구독 출처가 바뀌는 것은 아니며, 반대로 구독 주소를 바꿔도 기존 항목이 즉시 모두 교체되는 것은 아닙니다. 먼저 두 대상을 구분해야 요청, 파싱, 연결 중 어느 단계에서 문제가 생겼는지 판단할 수 있습니다.

기존 링크로 가져오기 메뉴 구분하기

먼저 보유한 자료가 서버 구독인지, 규칙이 포함된 구성 파일인지 확인하세요. 주소가 HTTPS로 시작한다는 사실만으로는 둘을 구분할 수 없습니다. 일반 웹페이지, 구독 응답, 구성 파일 모두 같은 형식의 주소를 사용할 수 있습니다. 파일명으로 짐작하지 말고 기존 자료에 적힌 용도를 확인하세요. Home에서 Add Server를 열고 Subscribe를 선택하면 서버 구독을 추가할 수 있습니다. Config의 Subscribe는 구성 파일 구독에 사용합니다. 메뉴 이름은 비슷하지만 서버 목록과 규칙 구성을 같은 종류의 자료로 취급해서는 안 됩니다. 실제 화면에 표시되는 메뉴 구조를 기준으로 확인하세요.

1. 기존 구독 주소 전체를 복사하고 처음과 끝, 쿼리 매개변수가 끊기지 않았는지 확인하세요. 메시지에 포함된 따옴표나 줄바꿈이 함께 복사되지 않도록 주의합니다.
2. Home에서 Add Server를 열고 Type에서 Subscribe를 선택하세요. 주소를 해당 URL 입력란에 붙여 넣고 구분하기 쉬운 이름을 입력합니다.
3. 저장한 뒤 Home으로 돌아가 구독 그룹과 서버 항목이 표시되는지 확인하세요. 먼저 내용을 살펴본 다음 항목 하나를 선택해 연결을 테스트합니다.
4. 보유한 자료가 규칙 구성 구독임을 확인했다면 Config에서 Subscribe를 선택하세요. 완료 후 실제로 선택된 구성 파일도 확인해야 합니다.

저장 성공과 가져오기 성공을 각각 확인하기

양식이 저장됐다는 것은 입력값을 앱이 받아들였다는 뜻일 뿐, 원격 서버가 파싱 가능한 내용을 반환했다는 의미는 아닙니다. 저장 후 서버 항목이 보이지 않으면 요청 오류가 있는지 확인하고 링크가 완전한지 점검하세요. 계정 로그인 화면, 안내 웹페이지 또는 접근 오류 문구가 반환됐다면 브라우저에서 열리더라도 유효한 구독이라고 판단할 수 없습니다. 웹페이지 내용을 서버 주소 입력란에 붙여 넣지 마세요. 기존 자료에서 정확한 주소를 확인하고 현재 계정으로 해당 내용을 읽을 수 있는지도 살펴보세요.

가져온 뒤에는 간단히 항목을 점검하세요. 항목 유형이 기존 자료와 일치하는지 확인하고, 항목 하나를 무작위로 열어 주소와 포트가 타당한지 살펴본 다음 수동으로 연결합니다. 예상보다 항목 수가 적거나 많다고 해서 반드시 가져오기 실패는 아닙니다. 구독에서 현재 반환하는 내용, 앱이 지원하는 입력 항목, 필터 조건 때문일 수 있습니다. 다른 출처의 항목 수가 아니라 같은 출처의 안내를 기준으로 비교하세요. 처음 테스트할 때는 서버 하나만 명확하게 선택해 자동 선택 방식이 실제 연결 대상을 가리지 않도록 합니다.

서버를 가져왔는데 접속할 수 없다면 같은 구독을 반복해서 추가하지 마세요. Home에서 선택된 서버, Global Routing, 연결 스위치를 확인한 뒤 연결 스위치를 켰는데 인터넷이 되지 않을 때 확인할 순서에 따라 원인을 좁혀 보세요. 구독 가져오기는 자료를 앱에 추가하는 단계일 뿐, 인증, 원격 서비스, DNS, 규칙 설정이 모두 올바르다는 뜻은 아닙니다.

Add Server 입력 항목 확인

Add Server는 이미 서버 한 대의 전체 매개변수를 알고 있어 항목별로 입력하고 확인하려는 경우에 적합합니다. 모든 항목을 채우는 것이 중요한 게 아니라, 정확한 Type을 먼저 고른 뒤 해당 프로토콜에 필요한 정보만 입력하는 것이 중요합니다. Type에 따라 같은 이름의 입력 항목도 의미가 다를 수 있으며, 화면에 없는 옵션을 경험만으로 추가해서는 안 됩니다. 주소, 포트, 인증, 전송 설정은 서로 다른 항목입니다. 이 모든 항목이 기존 서버 정보와 일치해야 연결 테스트 결과를 올바르게 해석할 수 있습니다.

Type을 먼저 선택한 뒤 기본 정보 입력

1. Home에서 Add Server를 열고 Type을 먼저 확인하세요. 유형을 바꾸면 양식을 다시 살펴 이전 유형의 인증 정보가 그대로 남지 않았는지 확인합니다.
2. 서버 주소 입력란에는 도메인이나 IP를 입력하고 Port에는 해당 포트 번호를 입력하세요. 전체 공유 링크, 경로 또는 포트 접미사를 주소 입력란에 넣지 마세요.
3. 유형에 맞는 Password, UUID, 암호화 방식 또는 기타 인증 매개변수를 입력하세요. 대소문자, 하이픈, 필수 기호를 원문 그대로 유지합니다.
4. 기존 정보를 참고해 TLS, SNI, 전송 방식, 경로를 확인하세요. 저장한 뒤 다시 열어 실제 저장된 값을 확인합니다.

서버 주소는 연결할 대상을 지정하고 TLS의 SNI는 핸드셰이크에서 이름을 전달합니다. 두 값이 반드시 같지는 않습니다. 기존 정보에 IP 주소와 별도의 도메인이 있다면 도메인을 모든 입력 항목에 임의로 넣지 마세요. Port는 원격 서버가 연결을 기다리는 포트이며 구독 링크의 웹 포트가 아닙니다. TLS를 사용한다는 이유만으로 포트 번호를 짐작해서도 안 됩니다. 직접 입력할 때는 각 값의 출처를 확인하세요. 누락된 매개변수는 흔히 쓰는 숫자를 하나씩 시험할 게 아니라 먼저 정확한 정보를 확인해야 합니다.

인증과 전송을 나눠 확인

인증 실패와 전송 핸드셰이크 실패는 확인할 항목이 다릅니다. 인증이 실패하면 먼저 정보가 빠짐없이 입력됐는지, 아직 유효한지, 프로토콜을 잘못 선택하지 않았는지 확인하세요. 전송 단계에서 실패하면 전송 유형, TLS 이름, 경로를 점검합니다. 일부 인증 정보에는 키보드가 자동으로 바꿀 수 있는 기호가 들어 있습니다. 복사한 뒤 전각 문자가 섞이지 않았는지, 앞뒤에 공백이 없는지 확인하세요. UUID는 원래의 구분 형식을 유지하고, Password가 인코딩된 문자열처럼 보여도 임의로 디코딩하지 마세요. 앱에는 사람이 읽기 쉽게 바꾼 값이 아니라 해당 입력 항목에 필요한 원래 값이 필요합니다.

WebSocket 같은 전송을 사용할 때 Host와 Path는 요청을 구성하는 데 각각 쓰일 수 있습니다. 전체 주소를 Path에 넣거나 경로 앞의 슬래시를 임의로 지우지 마세요. TLS 스위치, SNI, 인증서 검증은 서로 연관되어 있으므로 인증서 검증을 끄는 방법을 일반적인 해결책으로 삼지 마세요. 인증서 오류가 발생하면 먼저 이름, 기기의 시간, 기존 서버 설정이 서로 일치하는지 확인합니다. 매개변수가 확실하지 않다면 오류 정보를 보관하고 기존 자료를 다시 확인하세요. 여러 보안 설정을 한꺼번에 바꾸는 것보다 원인을 찾기 쉽습니다.

이름에는 용도와 출처를 기록하되 Password나 전체 접근 토큰은 적지 마세요. 예를 들어 “개인 테스트 / 직접 입력 / Trojan”처럼 적으면 같은 주소를 서로 다른 매개변수로 구성한 항목을 구분하기 쉽습니다. 수정 전에는 알아보기 쉬운 테스트 항목을 복사해 두고 기존 항목은 그대로 보관하세요. 한 번에 한 종류의 매개변수만 바꾸고 같은 방식으로 다시 확인합니다. 연결에 성공하면 어떤 변경이 효과가 있었는지 확인하고, 시도했던 변경 사항을 전부 정식 항목에 남기지 마세요. 프로토콜 의미와 규칙 용어는 용어 빠른 참조에서 확인할 수 있습니다.

직접 입력한 항목은 일반적으로 사용자가 직접 관리해야 합니다. 구독을 업데이트해도 해당 항목의 Password나 Port가 함께 갱신된다고 가정하지 마세요. 주소가 구독 항목과 같더라도 서로 독립된 기록일 수 있습니다. 원격 매개변수가 바뀌면 출처와 로컬에 직접 입력한 항목을 따로 확인하세요. 직접 입력한 오래된 항목의 실패를 구독 전체의 문제로 오해하지 않도록 합니다.

Scan QR Code와 클립보드 가져오기

QR 코드와 클립보드는 정보를 전달하는 수단이지 별도의 연결 프로토콜이 아닙니다. QR 코드 하나에 서버 한 대의 공유 링크가 들어 있을 수도 있고 구독 URL이 들어 있을 수도 있습니다. 클립보드에는 이름, 설명, 웹페이지 주소만 들어 있는 경우도 있습니다. 앱이 내용을 인식한 뒤에도 어떤 유형의 항목을 가져올지 확인해야 합니다. QR 코드 인식 성공 메시지가 떴다고 바로 연결 스위치를 켜지 마세요. 내용을 읽고 유형을 확인한 다음 저장하고 입력 항목을 점검한 뒤 네트워크 연결을 테스트하는 순서로 진행합니다.

QR 코드 읽기와 저장 후 확인

1. 앱에서 제공하는 Scan QR Code 메뉴를 열어 스캔하세요. 카메라로 읽을 때 필요한 권한만 허용합니다.
2. QR 코드 전체가 화면 안에 들어오도록 하고 화면을 안정적으로 유지하세요. 코드 가장자리가 잘리거나 빛이 반사되지 않게 하고 다른 QR 코드가 함께 비치지 않도록 합니다.
3. 인식한 뒤 Add Server, 구독 입력 화면 또는 다른 확인 화면 중 어디로 이동했는지 살펴보세요. 이름, Type, 주소, Port도 확인합니다.
4. 저장 후 Home으로 돌아와 새 항목이 어느 출처에 속하는지 확인하세요. 같은 항목이 이미 있다면 어느 쪽을 유지할지 결정하기 전에 먼저 비교합니다.

QR 코드가 같은 기기 화면에 표시되어 있다면 현재 스캔 메뉴가 사진 읽기를 지원하는 경우 사진에서 읽을 수 있습니다. 해당 메뉴가 없다면 원본 텍스트 링크로 가져오세요. 반복해서 스크린샷을 만들 필요는 없습니다. 사진을 읽는 것은 입력 방법만 바꾸며 내용 확인 절차는 달라지지 않습니다. 이미지를 축소·압축·자르거나 표시를 덧붙이면 내용을 온전히 복원하지 못할 수 있습니다. 선명한 원본을 사용하거나 기존 자료에서 텍스트 형식으로 다시 확인하세요. QR 코드가 촘촘할수록 화면이 선명해야 하고 가장자리 여백도 충분해야 합니다.

클립보드에서 읽을 때 주의할 점

링크를 복사할 때는 프로토콜 접두사부터 마지막 매개변수까지 전체를 선택하세요. 제목, 글머리 기호, 설명 문구가 함께 복사되지 않도록 합니다. 앱으로 돌아온 뒤 실제로 표시되는 클립보드 인식 알림이나 가져오기 메뉴에 따라 진행하세요. 붙여넣기 권한을 묻는다면 이번 작업을 위해 읽는 것인지 확인합니다. 시스템 설정에 따라 알림이 표시되는 시점은 다를 수 있습니다. 자동 알림이 나타나지 않는다고 링크가 유효하지 않은 것은 아닙니다. 해당 입력 화면에서 붙여넣기를 지원하는지 확인한 다음 텍스트 형식을 점검하세요.

채팅 기록이나 웹페이지에서 복사할 때 흔한 문제는 실제 내용과 화면에 표시되는 내용이 다르다는 점입니다. 페이지가 줄여 쓴 주소만 보여 주거나 텍스트에 줄바꿈이 삽입될 수 있고, 끝에 문장부호가 붙을 수도 있습니다. 숨겨진 문자를 짐작해 입력하지 마세요. 화면을 보고 다시 타이핑하는 대신 원본 링크를 복사해야 합니다. 여러 줄의 텍스트에 설명과 서버 정보가 함께 들어 있다면 앱이 모두 인식하는지는 형식에 따라 다릅니다. 먼저 완전한 항목 하나만 가져와 해석 결과가 올바른지 확인한 뒤 나머지를 처리하세요.

QR 코드를 읽은 뒤 표시된 Type이 원본 자료와 다르면 저장을 취소하고 QR 코드가 다른 항목에 해당하는지 확인하세요. 인식 후 입력 항목이 누락됐다면 원본 자료를 보관하고 Add Server에서 직접 입력해 비교합니다. 잘못된 유형의 입력 화면에 비슷해 보이는 값을 억지로 채우지 마세요. 이미 있는 항목이라면 이름에 “QR 테스트”라고 표시해 원본과 구분할 수 있습니다. 비교를 마친 뒤 임시 항목을 삭제해 다음 테스트에서 잘못 선택하지 않도록 하세요. 단, 삭제 전에 해당 항목이 복원 가능한 유일한 사본은 아닌지 확인합니다.

가져오기를 마쳐도 클립보드와 사진에는 내용이 남아 있습니다. 실제 인증 정보가 포함된 QR 코드는 공개 문제 화면에 사용하지 마세요. 민감한 링크를 클립보드에 오래 보관하는 것도 피해야 합니다. 작업 후 일반 텍스트를 복사해 현재 클립보드 내용을 덮어쓰고 임시 사진은 개인 자료 관리 방식에 따라 정리할 수 있습니다. 구독과 서버를 가져오는 방법은 구독 및 서버를 가져오는 네 가지 방법을 참고하세요. 여기서 설명한 보안 원칙은 모든 입력 방법에 적용됩니다.

문제 기록에는 “QR 코드 인식 안 됨”, “인식 후 유형이 잘못됨”, “저장 후 연결 실패”처럼 적으면 충분합니다. 각각 입력, 파싱, 연결 단계에 해당하므로 문제를 구분해 처리하세요. 이미지 선명도 문제를 서버 장애로 오해하지 않도록 합니다.

공유 링크와 Config 형식

공유 링크는 서버 매개변수를 전달할 수 있는 텍스트로 인코딩한 것입니다. 구독은 이런 항목을 여러 개 반환할 수 있습니다. 프로토콜 접두사를 보면 먼저 서버 한 대를 설명하는 링크인지, 자료를 가져오는 경로인지 판단한 뒤 입력 방법을 선택하세요. 흔히 쓰이는 접두사에는 ss://, vmess://, vless://, trojan://, hysteria2://가 있지만 접두사가 같다고 모든 매개변수 조합이 같은 것은 아닙니다. 프로토콜, 전송 방식, 보안 설정, 이름 인코딩을 함께 확인해야 합니다. 링크를 인식할 수 있다는 사실만으로 입력 항목을 모두 확인했다고 볼 수 없습니다.

접두사, 쿼리 매개변수, 이름을 각각 확인하기

일부 형식은 인증 정보와 주소를 본문에 인코딩하고, 다른 형식은 주소, 포트, 쿼리 매개변수를 그대로 표시합니다. 물음표 뒤에는 TLS, SNI, 전송 방식 등의 설정이 올 수 있고, 샵 기호 뒤에는 일반적으로 메모용 이름이 붙습니다. 이름이 깨져 보여도 연결 매개변수까지 손상됐다는 뜻은 아닙니다. 반대로 이름이 정상이라고 모든 쿼리 매개변수가 올바른 것도 아닙니다. 링크가 읽기 쉬운지만으로 판단하지 말고 앱에서 파싱된 결과를 확인하세요. 이름은 알아보기 쉬운 텍스트로 바꿔도 되지만 원본 연결 정보는 별도로 보관해야 합니다.

링크의 퍼센트 인코딩은 예약 문자를 표현하는 데 사용되며, 일부 본문은 Base64로 인코딩됩니다. 두 방식을 혼용하거나 링크 전체를 반복해서 디코딩하지 마세요. 비밀번호, 경로, 이름에 원래 포함된 유효한 기호를 잘못 디코딩하면 구분자로 바뀌어 항목의 경계가 달라질 수 있습니다. 복사할 때는 원문을 그대로 유지하세요. 문제를 확인할 때는 앱에 표시된 입력 항목과 기존 자료를 비교하고, 디코딩한 전체 인증 정보를 공개 텍스트 처리 도구에 보내지 마세요. 인코딩은 텍스트를 전달하기 쉽게 만들 뿐, 기밀성을 보장하지 않습니다.

서버 정보와 규칙 파일의 역할 구분

서버 항목은 “어디에 연결하고 어떻게 인증할지”를 정하고, Config는 “요청별로 어떤 정책을 적용할지”를 정합니다. 함께 사용할 수 있지만 서로 대신할 수는 없습니다. 규칙 파일만 가져온다고 필요한 서버 인증 정보가 생기는 것은 아닙니다. 서버만 가져왔다고 기존 규칙이 적용됐다고 볼 수도 없습니다. 트래픽 분기 동작을 확인할 때는 Home에서 선택한 서버, Global Routing의 현재 모드, Config에서 실제로 활성화한 파일을 모두 확인하세요. 편집기에서 특정 사본을 열어 봤다는 사실만으로는 충분하지 않습니다.

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

위 내용은 규칙 문법의 예시이며 모든 네트워크에 적합한 완성된 구성은 아닙니다. DOMAIN-SUFFIX는 도메인 접미사를 기준으로 매칭하고, IP-CIDR은 주소 범위를 지정하며, GEOIP는 해당 주소의 위치 정보에 따라 판단합니다. FINAL은 마지막 기본 규칙으로 사용됩니다. 규칙 순서에 따라 매칭 결과가 달라집니다. 범위가 넓은 항목을 앞에 두면 뒤의 구체적인 조건이 적용되지 않을 수 있습니다. PROXY와 DIRECT는 정책 키워드이므로 한국어로 바꾸지 마세요. 복사할 때 쉼표를 바꾸거나 설명 문구를 덧붙이지도 마세요.

Global Routing에서 Config 모드를 사용하면 선택된 구성 파일과 규칙을 함께 확인해야 합니다. Proxy 모드와 Direct 모드는 전체 라우팅을 다르게 선택합니다. 세 모드는 서버 정보 세 묶음이나 구독 출처 세 곳이 아닙니다. 특정 규칙의 영향을 비교하려면 먼저 현재 모드를 기록하고 같은 대상을 한 번 테스트한 뒤 원래 모드로 되돌리세요. 구독 내용을 확인하는 중에 Config 전체를 교체하지 마세요. 접속 결과가 달라져도 서버와 라우팅 정책 중 무엇이 원인인지 판단하기 어려워집니다.

확장 매개변수가 지원되는지 확실하지 않다면 현재 앱에 해당 입력 항목이 있는지, 원본 자료에서 무엇을 안내하는지 먼저 확인하세요. 모르는 매개변수를 전부 삭제한 뒤 저장하지 마세요. 가져오기는 되더라도 필요한 설정이 사라질 수 있습니다. 형식 문제는 가져오기 전후를 비교하고, 규칙 문제는 Config에서 확인해 두 경로를 분리해서 점검하세요.

구독 업데이트 방식과 실패 유형

구독 업데이트는 기존 출처에 다시 요청해 현재 반환되는 내용을 파싱하는 작업이지, 기존 서버가 작동하는지 단순히 테스트하는 기능이 아닙니다. 업데이트 후 항목이 추가, 삭제, 이름 변경 또는 매개변수 수정될 수 있습니다. 실제 변화는 원격 자료와 앱의 처리 방식에 따라 달라집니다. 업데이트 전에는 어떤 항목이 구독에 속하는지, 어떤 항목이 직접 입력한 독립 항목인지, 현재 어떤 항목을 사용 중인지 확인하세요. 구독 항목을 직접 수정했다면 이후 업데이트에서 덮어써질 수 있는 변경으로 취급해야 합니다. 유일한 장기 보관 수단으로 간주하지 마세요.

결과를 확인할 수 있도록 수동으로 한 번 업데이트하기

1. 현재 출처 이름, 선택한 서버, 중요한 로컬 변경 사항을 기록하세요. 중요한 내용은 복원 가능한 방식으로 먼저 백업합니다.
2. 해당 구독이 제공하는 업데이트 메뉴를 사용해 출처 하나만 업데이트하고 결과와 오류 메시지를 확인하세요.
3. 업데이트 전후의 그룹, 이름, 매개변수를 비교해 현재 사용하는 항목이 남아 있는지 확인합니다.
4. 확인된 서버 하나를 선택해 다시 연결하고 같은 접속 대상으로 결과를 확인한 뒤 다른 출처를 처리하세요.

변경이 드물고 내용을 먼저 확인하고 싶다면 필요할 때 수동으로 업데이트하세요. 앱에 자동 업데이트 설정이 있다면 수동 업데이트가 성공한 뒤 관리 방식에 맞춰 활성화할 수 있습니다. 자동 업데이트 주기가 원격 자료의 변경 주기와 같은 것은 아닙니다. 요청을 자주 보내도 이미 만료된 인증 정보가 복구되지는 않습니다. 시스템의 백그라운드 실행 조건, 로컬 네트워크, 당시 앱 상태에 따라 실행 시점이 달라질 수 있으므로 예약 시각마다 반드시 실행된다고 보장할 수 없습니다. 문제가 생기면 먼저 앱을 열어 수동 업데이트를 실행하고 명확한 결과를 확인하세요.

요청 실패와 연결 실패를 구분하기

구독 주소에 접근할 수 없다면 현재 로컬 네트워크, DNS 조회, 주소의 완전성을 먼저 확인하세요. 현재 연결 상태가 요청 경로에 영향을 줄 수 있다면 상태를 기록한 뒤 통제된 조건에서 한 번 더 비교합니다. 기록 없이 설정을 반복해서 바꾸면 재현이 어려워집니다. 인증 관련 응답이 오면 기존 링크가 아직 유효한지 확인하세요. 내용을 파싱할 수 없다면 반환된 것이 구독 자료인지 웹페이지인지 살펴봅니다. 인식할 수 있는 내용을 성공적으로 받은 다음에야 서버 매개변수와 연결 가능성을 확인할 수 있습니다.

업데이트 성공이 모든 서버의 사용 가능성을 뜻하지는 않습니다. 구독에서 자료를 정상적으로 반환해도 서버 하나는 일시적으로 접근할 수 없을 수 있습니다. 반대로 기존 항목으로 연결되더라도 구독 주소가 정상이라고 볼 수는 없습니다. 두 결과를 따로 기록하세요. 업데이트 후 일부 항목만 남았다면 원격 자료가 변경됐는지, 필터 조건이 있는지, 앱이 해당 유형을 파싱할 수 있는지 확인합니다. 먼저 첫 업데이트에서 달라진 점을 살펴보고 오류 내용을 보관하세요. 반복해서 새로고침하면 중요한 문제 해결 단서가 덮일 수 있습니다.

기존 구독 주소를 바꿔야 한다면 먼저 이전 출처를 백업하고 새 주소의 용도를 확인하세요. 별도의 이름으로 새 출처를 테스트하고 항목과 연결이 정상인지 확인한 뒤 이전 기록을 정리합니다. 교체 과정에서 이전 출처 삭제, 구성을 모두 지우기, 설정 초기화를 한꺼번에 하지 마세요. 문제가 생기면 비교할 대상이 없어집니다. 업데이트 후에는 Global Routing과 Config가 예상대로 유지됐는지도 확인하세요. 이번 작업에 명확한 구성 변경이 포함되지 않았다면 구독 관리가 라우팅 동작까지 바꾸어서는 안 됩니다.

유지 관리 기록에는 업데이트한 출처, 변경 내용, 확인한 항목, 결과만 적으면 됩니다. 전체 구독 주소를 로그에 남길 필요는 없습니다. 나중에 과정을 되짚을 수 있고 민감한 정보가 스크린샷이나 메모에 흩어질 위험도 줄어듭니다.

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

여러 구독을 함께 사용할 때 중요한 것은 이름을 보기 좋게 정리하는 것보다 “각 항목이 어디서 왔는지” 파악하는 것입니다. 이름이 같은 두 항목도 주소, 포트, 인증 정보가 다를 수 있고, 이름이 달라도 같은 원격 서버를 가리킬 수 있습니다. 정리 전에 구독 출처, 출처에 속한 서버, 직접 입력한 독립 항목, 테스트용 임시 사본으로 계층을 나누세요. 각 유형을 구분할 수 있어야 업데이트할 때 그룹을 잘못 선택하거나 테스트 항목을 정리하다 실제 사용하는 항목을 삭제하는 일을 막을 수 있습니다.

이름에는 용도를 적고 인증 정보는 넣지 않기

구독 이름에는 개인이 알아보기 쉬운 용도와 자료 출처 표시를, 서버 메모에는 프로토콜이나 테스트 목적을 적는 것이 좋습니다. 예를 들어 “업무용 자료 / 기본”이나 “개인 테스트 / 직접 입력”이라고 표시하면 구분하기 쉽습니다. Password, 접근 토큰, 전체 계정 식별 정보를 이름에 포함하지 마세요. 원격 서버와 로컬 네트워크 상태는 바뀔 수 있으므로 이름에 측정 결과를 적는 것도 적절하지 않습니다. 한 번의 테스트 결과를 영구적인 이름으로 남기면 그 결과가 이미 바뀌었는데도 현재 상태를 다시 확인하지 않고 오래된 판단에 의존할 수 있습니다.

1. 출처별로 확인하고 출처 표시와 소속 항목을 먼저 살펴보세요. 전체 목록 화면에서 바로 여러 항목을 삭제하지 마세요.
2. 독립적으로 직접 입력한 항목과 임시 사본에는 명확한 메모를 붙이고 원본 자료를 안전하게 보관한 위치를 기록하세요.
3. 중복이 의심되는 항목은 표시 이름만 비교하지 말고 Type, 주소, Port, 인증, 전송 설정을 확인하세요.
4. 유지할 항목을 정한 뒤 Config나 정책이 기존 이름을 참조하는지 확인하세요. 소량씩 정리하고 결과를 검증합니다.

구독 안의 이름은 원격에서 관리될 수 있으므로 업데이트 후 로컬에서 바꾼 이름이 유지되지 않을 수 있습니다. 개인 분류를 오래 유지하려면 원격에서 관리하는 항목을 대량으로 바꾸기보다 앱에 실제로 제공되는 출처 그룹이나 메모 기능을 활용하세요. 별도 사본을 저장한다면 원래 출처의 업데이트에 더 이상 연동되지 않아 직접 관리해야 한다는 점도 기록합니다. 사본이 많을수록 이후 동기화에 드는 수고가 커집니다. 문제 해결이나 복구에 필요한 사본만 보관하고 업데이트할 때마다 전체를 복제하지 마세요.

매개변수를 비교해 중복 여부 판단하기

표시 이름이 완전히 같다는 사실은 이름이 겹친다는 것만 보여 줍니다. 인증 정보가 다르면 접근 권한이 다를 수 있고 전송 경로가 다르면 서비스 설정도 다를 수 있습니다. 삭제 전 항목을 열어 주소, 포트, 프로토콜, 보안 설정을 최소한 확인하세요. 인증 정보는 안전한 비공개 환경에서만 비교합니다. 주소만 같고 다른 항목이 다르면 각각 테스트하고 차이를 설명해 보관하세요. 목록이 비슷해 보인다는 이유만으로 하나가 불필요하다고 판단하거나 한 번 측정한 지연 시간이 비슷하다는 이유로 중복이라고 단정해서는 안 됩니다.

구성 파일에서 특정 서버 이름이나 정책 그룹 구성원 이름을 사용한다면 이름 변경이나 삭제가 참조 관계에 영향을 줄 수 있습니다. 정리 전에 Home만 보는 것이 아니라 해당 Config도 확인하세요. PROXY 같은 정책 키워드를 사용할 때는 현재 선택과의 관계를 이해해야 합니다. 표시 이름이 같다고 참조가 계속 유지된다고 볼 수는 없습니다. 정리한 뒤에는 예상한 서버를 선택하고 Config에서 활성화된 파일을 확인한 다음 같은 대상으로 테스트하세요. 문제가 생기면 변경 범위를 더 넓히지 말고 방금 변경한 이름이나 항목부터 복원합니다.

출처가 여러 개라고 해서 자주 전환해야 하는 것은 아닙니다. 관리할 때는 검증을 마친 항목 하나를 기준으로 두고 나머지는 필요할 때 테스트할 수 있습니다. 이름순으로만 정리하는 것보다 “현재 사용”, “예비 확인”, “확인 대기”처럼 상태를 기록하면 나중에 과정을 파악하기 쉽습니다. 기록은 안전한 곳에 보관하고 상태 문구와 실제 인증 정보를 함께 적지 마세요. 매번 출처 하나만 정리하고 업데이트, 확인, 검증을 마친 다음 다음 그룹으로 넘어가면 매개변수 혼동과 누락을 줄일 수 있습니다.

당장 사용하지 않더라도 복원 여부를 아직 확인하지 않은 항목은 즉시 삭제하지 말고 보관하는 편이 안전합니다. 원본 자료가 사용 가능한지, 백업을 복원할 수 있는지, Config 참조를 정리했는지 확인한 다음 최종 삭제하세요. 목록이 깔끔해지는 것은 정리의 결과일 뿐입니다. 출처를 추적할 수 있고 복원 방법이 분명해야 정리가 완료된 것입니다.

Connectivity Test, 지연 시간, 정렬

Connectivity Test는 특정 조건에서 테스트 결과를 확인하는 기능이지 서버 품질을 영구적으로 평가하는 기준이 아닙니다. 테스트에서 연결이 수립되는지, 프로토콜 핸드셰이크가 완료되는지, 테스트 대상에 접속하는지는 실제 테스트 방식에 따라 다릅니다. 시간 값이 표시되면 무엇을 측정했는지 먼저 파악한 뒤 비교하세요. 주소에 연결할 수 있다고 인증에 성공한 것은 아니며, 인증에 성공했다고 모든 웹사이트에 접속할 수 있는 것도 아닙니다. 단계를 구분해야 “테스트는 통과했는데 실제 접속은 실패”하는 상황을 설명할 수 있습니다.

조건을 고정한 뒤 결과 비교하기

1. 기기가 현재 Wi-Fi를 사용하는지 셀룰러 네트워크를 사용하는지 확인하고 로컬 네트워크가 정상인지 먼저 점검합니다.
2. 테스트 방식과 대상을 하나로 정하고 Global Routing, 선택한 서버, 관련 구성을 기록하세요.
3. 같은 조건에서 후보 항목 몇 개만 테스트하고 이상한 결과는 한 번 더 확인합니다. 여러 매개변수를 동시에 바꾸지 마세요.
4. 후보 서버를 선택해 실제 연결하고 자주 사용하는 작업을 테스트한 뒤 사용 순서를 조정할지 결정하세요.

TCP 계열 테스트는 주로 대상 포트에 연결할 수 있는지를 보여 줍니다. 이것만으로 프록시 인증과 이후 데이터 전송이 모두 정상이라고 입증할 수는 없습니다. 기반 전송 방식이 다른 프로토콜에서는 같은 테스트 결과를 같은 의미로 해석하지 못할 수도 있습니다. 앱에서 프록시를 통해 대상에 접속하는 테스트를 제공한다면 대상 자체의 응답 상태도 함께 고려하세요. 대상에 접속할 수 없거나 DNS 조회가 비정상적이거나 일시적으로 요청이 거부되면 결과가 달라질 수 있습니다. 측정 방식이 다른 시간 값을 한데 섞어 결론을 내리지 말고 먼저 측정 기준을 통일하세요.

정렬이 자동 선택을 뜻하지는 않음

테스트 결과로 정렬하면 일반적으로 목록 표시 순서가 바뀔 뿐 앱이 첫 번째 항목으로 자동 전환되는 것은 아닙니다. 실제 연결 대상은 현재 선택된 서버와 구성의 정책에 따라 달라집니다. 정렬 후 선택 상태를 다시 확인하세요. Config에서 정책 그룹을 사용한다면 해당 그룹의 선택 방식도 점검해야 합니다. 한 번 측정한 최소 시간 값은 당시 해당 대상에서 관찰한 결과일 뿐입니다. 지속적인 전송 속도가 더 빠르다는 뜻도, 모든 작업에 더 적합하다는 뜻도 아닙니다. 목록의 위치를 연결 상태를 나타내는 정보처럼 취급하지 마세요.

여러 항목을 동시에 테스트하면 기기, 로컬 네트워크, 원격 서버에 순간적인 부하가 커질 수 있고 일시적인 변동도 결과에 더 크게 반영됩니다. 후보 서버 몇 개씩 나눠 테스트하면 조건을 비교하기 쉽습니다. 한 항목이 한 번 시간 초과되면 같은 조건에서 다시 테스트하세요. 계속 실패한다면 매개변수를 확인하고 주소 접근 실패, 인증 오류, 대상 요청 실패를 구분합니다. 특히 로컬 네트워크도 불안정한 상황에서는 상태가 한 번 빨간색으로 표시되거나 결과가 비어 있다는 이유만으로 항목을 삭제하지 마세요.

같은 서버가 Wi-Fi와 셀룰러 네트워크에서 크게 다르게 동작하면 서버 매개변수는 그대로 두고 네트워크 조건을 각각 기록해 로컬 접속 환경과 관련이 있는지 살펴보세요. 같은 네트워크에서 모든 서버가 실패한다면 인증 정보를 하나씩 다시 입력하기보다 로컬 네트워크와 DNS를 먼저 확인하세요. 한 항목만 계속 문제가 생기면 Type, Port, TLS, 전송 입력 항목을 비교합니다. 단계적으로 확인하면 불필요한 반복 작업을 줄일 수 있습니다. 구체적인 방법은 속도가 느릴 때 단계별로 확인하는 방법을 참고하세요.

최종 기록에는 테스트 방식, 대상, 네트워크 조건, 결과를 포함하세요. 시간 값 하나만 저장할 필요는 없습니다. 정렬 후에도 출처 그룹과 알아보기 쉬운 이름을 유지하면 다음 업데이트 후 다시 확인하기 쉽습니다. 같은 작업을 반복해 재현할 수 있는 테스트 결과만 유지 관리 판단의 근거로 삼으세요. 설명하기 어려운 차이는 특정 프로토콜이나 서버가 영구적으로 사용할 수 없다고 단정하지 말고 확인 대기 상태로 표시합니다.

삭제, 백업, 기기 변경 후 복원

서버 관리의 마지막 단계는 삭제가 아니라 삭제 후에도 복원 경로가 있는지 확인하는 것입니다. 앱, 구독 출처, 서버 항목, Config 파일은 서로 다른 대상입니다. 하나를 복원해도 나머지가 자동으로 복원되는 것은 아닙니다. App Store의 구입 내역은 앱을 다시 받는 데 사용됩니다. 사용자의 서버 인증 정보, 구독 주소, 로컬 구성은 각각 따로 보관해야 합니다. 기기를 바꾸기 전에 대상을 점검하는 편이 교체 후 자료가 없다는 사실을 뒤늦게 알아내는 것보다 안전합니다. 시스템 요구 사항과 구입 적용 범위는 App Store 페이지의 안내를 확인하세요.

대상별 백업 목록 만들기

구독 출처는 전체 주소와 용도 안내를 보관하세요. 직접 입력한 독립 항목은 프로토콜, 주소, 포트, 인증 정보, 필요한 전송 설정을 보관하고 Config는 전체 파일과 활성화 관계를 저장합니다. 앱에서 내보내기 또는 백업 기능을 제공한다면 어떤 내용이 실제로 포함되는지 먼저 확인하세요. 파일 이름만으로 포함 범위를 판단해서는 안 됩니다. 구성 텍스트 전체를 내보내는 기능도 있고 현재 서버 하나만 공유하는 메뉴도 있을 수 있습니다. 복원 전에 각각 무엇이 포함되는지 확인해야 합니다. 원본 자료를 안전하게 보관하면 내보내기 과정에서 확장 매개변수가 누락됐는지도 확인하기 쉽습니다.

1. 출처, 직접 입력한 항목, Config, 주요 설정을 정리하고 각 복원 자료를 보관한 위치를 기록하세요.
2. 앱에서 실제로 제공하는 메뉴로 내보내세요. 예상한 항목이 파일에 포함됐는지 확인하고 접근이 제한된 위치에 보관합니다.
3. 가능하다면 별도의 테스트 항목이나 대상 기기에서 복원을 확인하세요. 아직 사용할 수 있는 유일한 원본 기록을 덮어쓰지 마세요.
4. 복원 후 입력 항목, 선택된 서버, Global Routing, Config를 확인하고 연결 및 접속 테스트를 마칩니다.

QR 코드 공유, 서버 하나의 공유 링크, 전체 백업은 포함 범위가 서로 다릅니다. 서버 하나의 QR 코드만 보관해서는 일반적으로 구독 출처와 업데이트 관계까지 복원할 수 없습니다. 구독 URL만 보관해도 로컬에서 변경한 메모, 독립 항목, 규칙 파일은 복원되지 않습니다. 반대로 전체 백업에는 민감한 정보가 많이 포함될 수 있으므로 접근 범위를 제한하고 공개 스크린샷과 함께 보관하지 마세요. 암호화 여부, 잠금 해제 방법, 대상 기기에서 읽는 방법은 원본 자료를 삭제하기 전에 확인해야 합니다. 복원에 실패한 뒤에 고민하지 마세요.

항목 삭제, 출처 삭제, 구성 비활성화 구분하기

구독 안의 항목 하나를 삭제해도 원격 자료에서 삭제되는 것은 아니므로 다음 업데이트 때 다시 나타날 수 있습니다. 구독 출처 전체를 삭제하면 그 출처에 속한 항목에도 영향을 줄 수 있으니 실행 전에 앱의 확인 메시지를 읽으세요. Config를 비활성화하거나 전환하는 것은 서버 삭제와 다르지만 요청 처리 방식은 바꿉니다. 한 번에 한 종류의 대상만 정리하고 작업 후 현재 선택을 확인하세요. 서버가 삭제됐는데도 이전 이름만 보고 실제 연결 대상을 판단하는 일이 없도록 합니다. 정책 참조가 있다면 구성에 해당 구성원이 남아 있는지도 확인해야 합니다.

복원 후에도 연결 스위치, 시스템 권한, 앱 내 선택이 이전 기기와 모두 같을 것이라고 가정하지 마세요. 먼저 Shadowrocket을 열어 가져온 내용을 확인하고 검토한 서버와 Global Routing을 선택한 뒤 시스템 안내에 따라 VPN 구성 권한을 설정합니다. 시스템 팝업은 기기에 네트워크 구성을 설정하는 절차일 뿐 서버 정보를 대신 채워 주지 않습니다. 앱을 다시 받거나 구입 내역을 확인하는 방법은 기기 변경 및 재설치 안내를 참고하세요. 앱 구입 비용의 범위는 일회성 구매와 회선 비용 안내에서 확인할 수 있습니다.

잘못 삭제했다면 추가 정리를 멈추고 기존 백업, 원본 자료, 아직 변경하지 않은 다른 기기를 확인하세요. 로컬 독립 항목이 돌아올지 알아보려고 업데이트를 반복하거나 온전한 사본을 덮어쓰지 마세요. 복원한 뒤에는 먼저 포함 범위를 확인하고 연결을 테스트합니다. 사용할 수 있다고 확인할 때까지 기존 백업을 보관하세요. 불완전한 새 파일이 유일한 기존 파일을 덮어쓰는 일을 막을 수 있습니다. 정리가 끝나면 최종 보관 항목과 복원 자료의 위치를 기록하고 중요한 매개변수를 변경할 때마다 백업을 갱신하세요.