Subscribe: 구독과 서버의 연결 관계 설정
구독은 다시 요청할 수 있는 원격 리소스 주소이고, 서버 항목은 클라이언트가 실제로 연결할 때 사용하는 매개변수 모음입니다. 겉모습이 비슷하다고 같은 것으로 취급해서는 안 됩니다. 구독을 업데이트하면 여러 서버 정보가 반환될 수 있지만, 단일 공유 링크는 보통 서버 하나를 설명합니다. 가져오기 전에 어떤 유형의 정보인지 확인하면 구독 주소를 서버 주소 입력란에 넣는 실수를 막을 수 있고, 업데이트 후 일부 항목이 다시 나타나는 이유도 이해할 수 있습니다.
정보 유형을 먼저 확인한 뒤 Subscribe로 이동
서비스 제공업체에서 구독을 받은 뒤에는 원본 문자열을 보관하고 쿼리 매개변수를 임의로 수정하지 마세요. 구독은 보통 웹 주소 형태지만, 브라우저에서 열린다는 이유만으로 구독 주소라고 판단할 수는 없습니다. 로그인 페이지, 도움말 페이지, 구독 리소스가 같은 도메인을 사용할 수도 있습니다. 제공업체의 안내를 확인해 해당 주소가 계정 관리나 일반 안내 페이지가 아닌 Shadowrocket 구독용인지 확인하세요.
Home의 추가 메뉴에서 Subscribe에 해당하는 구독 유형을 선택하세요. 일부 인터페이스에서는 Add Server의 Type 목록에서 Subscribe를 선택할 수 있습니다. 화면이 열리면 전체 주소를 URL에 붙여 넣고 알아보기 쉬운 메모를 입력한 뒤 저장하고 업데이트하세요. 플랫폼마다 메뉴 배치가 다를 수 있으므로, 버튼이 화면의 특정 위치에 있는지가 아니라 Subscribe와 URL이 해당 용도에 맞는지 확인해야 합니다.
메모에는 리소스의 출처와 용도를 기록하는 것이 좋습니다. 예: ‘개인 구독 / 일상’, ‘개인 구독 / 예비’. 구독 주소 전체, 계정 비밀번호, 접근 자격 증명은 메모에 적지 마세요. 메모는 목록을 정리하기 위한 것으로 서버 매개변수를 대신하지 않습니다. 메모를 바꿔도 실제 서버 주소가 달라지거나 만료된 자격 증명이 다시 유효해지지는 않습니다.
항목과 업데이트 결과로 가져오기가 완료됐는지 확인
구독을 저장한 뒤 하위에 서버 항목이 표시되는지 확인하고 업데이트 오류가 있는지 살펴보세요. 구독 이름이 하나 표시된다고 해서 유효한 서버를 가져온 것은 아닙니다. 목록이 비어 있다면 주소가 완전한지, 현재 네트워크에서 리소스를 요청할 수 있는지, 서버가 클라이언트에서 인식할 수 있는 내용을 반환하는지 순서대로 확인하세요. 오류 내용을 먼저 기록하고 다시 추가할지 결정해 같은 구독을 여러 개 만들지 않도록 하세요.
구독에 포함된 서버 이름은 대개 원격 데이터에 따라 정해집니다. 업데이트 후 이름, 개수, 순서 또는 연결 매개변수가 바뀌더라도 반드시 클라이언트가 정보를 잃었다는 뜻은 아닙니다. 원격에서 이전 항목을 삭제하거나 설정을 변경했을 수도 있습니다. 변경 내역을 추적하려면 업데이트 전후의 구독 이름과 항목 이름을 기록하고 출처를 비교하세요. 목록 전체 개수만으로 업데이트의 정상 여부를 판단해서는 안 됩니다.
구독을 가져온 뒤에는 사용할 서버를 선택하고 연결을 확인해야 합니다. 구독은 서버 정보를 제공하고, Config의 규칙은 트래픽 처리 방식을 결정하므로 서로 다른 계층입니다. 서버 정보만 있고 적절한 Global Routing 설정이 없으면 실제 접속 경로가 예상과 다를 수 있습니다. 반대로 규칙 파일만 있고 연결 가능한 서버가 없다면 PROXY 연결을 완료할 수 없습니다.
| 정보 유형 | 가져온 후 생성되는 항목 | 이후 관리 방법 |
|---|---|---|
| Subscribe URL | 구독과 구독 내 서버 목록 | 원래 주소로 다시 요청해 업데이트 |
| 단일 공유 링크 | 독립 서버 항목 | 다시 가져오거나 직접 편집 |
| Shadowrocket .conf | Config 설정 파일 | 규칙 및 설정 내용 관리 |
구독 주소는 자격 증명처럼 보호
구독 주소에는 계정을 식별할 수 있는 매개변수가 포함될 수 있으므로 민감한 정보로 취급하세요. 채팅, 스크린샷 또는 문의 내용에 복사하기 전에는 전체 경로의 자격 증명과 쿼리 매개변수를 가려야 합니다. 도메인만 숨기는 것은 대개 의미가 없습니다. 리소스에 접근할 수 있게 해 주는 정보가 주소 뒷부분에 있을 수 있기 때문입니다. 도움을 요청할 때는 프로토콜 유형, 오류 종류와 발생 단계를 공유하면 되며, 실제로 접근 가능한 구독 주소를 공개할 필요는 없습니다.
주소가 유출된 것으로 의심되면 서비스 제공업체에 구독 자격 증명을 재설정할 수 있는지 문의한 뒤 클라이언트에 저장된 URL을 교체하세요. 로컬 메모를 수정하거나 서버 항목 하나를 삭제해도 이전 주소는 무효화되지 않습니다. 교체 후에는 업데이트하고 항목 하나를 테스트해 새 리소스가 작동하는지 확인한 다음 이전 구독을 정리하세요. 새 설정을 확인하기 전에 기존에 사용하던 구성을 잃지 않도록 주의하세요.
Add Server: 프로토콜에 맞게 서버 매개변수 입력
서버 정보를 모두 알고 있거나 특정 필드를 확인해야 할 때는 수동 추가를 사용하세요. Add Server로 이동해 Type을 먼저 선택하고 해당 필드를 입력합니다. 기본 양식에 정보를 모두 입력한 뒤 프로토콜 유형을 바꾸지 마세요. 프로토콜마다 필수 항목과 사용할 수 있는 옵션이 다릅니다. 유형을 바꾼 뒤에는 기존 입력 내용이 계속 적용되는지 다시 확인해야 합니다.
주소, 포트, 인증 정보를 따로 확인
Address에는 일반적으로 서버 도메인이나 IP 주소를 입력합니다. 웹 경로를 포함하지 말고 프로토콜 접두사도 함께 붙여 넣지 마세요. Port는 서버에서 수신하는 포트와 일치해야 하며, 관리 웹 페이지의 포트를 프록시 포트로 입력해서는 안 됩니다. IPv6 주소와 포트를 위한 별도 필드가 있다면 해당 필드를 사용하고 웹 주소 형식으로 임의로 조합하지 마세요. 원본 정보가 전체 링크로만 제공된 경우에는 링크 가져오기를 우선 사용하세요.
인증 정보는 프로토콜에 맞는 항목인지 확인해야 합니다. Shadowsocks는 보통 암호화 방식과 비밀번호를 사용하고, VMess와 VLESS는 각 프로토콜의 사용자 식별자를 사용하며, Trojan은 인증 정보를 사용합니다. 긴 문자열이라는 이유만으로 어느 필드에 넣어야 하는지 판단할 수는 없습니다. 복사 후 앞뒤 공백, 줄바꿈, 대소문자를 확인하세요. 특히 인터페이스에서 자동으로 줄이 바뀐 것을 원본 자격 증명에 줄바꿈이 포함된 것으로 오해하지 않도록 주의하세요.
매개변수 안내에 ‘비밀번호’와 ‘주소’만 적혀 있어도 연결에 필요한 정보가 모두 갖춰지지 않았을 수 있습니다. 서버에 특정 전송 방식, TLS, SNI, 경로 또는 기타 옵션이 필요할 수 있습니다. 이때는 스위치를 하나씩 바꿔 저장되는 조합을 찾기보다 서비스 제공업체에서 전체 정보를 받으세요. 양식이 저장된다는 것은 입력 형식이 허용됐다는 뜻일 뿐, 서버가 해당 매개변수를 인정한다는 의미는 아닙니다.
| 매개변수 그룹 | 확인할 내용 | 자주 혼동하는 부분 |
|---|---|---|
| Address / Port | 연결 대상 및 수신 포트 | 웹 주소를 서버 주소로 입력 |
| 인증 매개변수 | 비밀번호, 사용자 식별자 또는 키 | 다른 프로토콜의 자격 증명을 입력 |
| TLS / SNI | 활성화 여부 및 검증 이름 | SNI를 Address로 입력 |
| 전송 매개변수 | 전송 방식, Host, 경로 | 경로 누락 또는 대소문자 변경 |
TLS와 전송 매개변수는 별개의 설정
TLS는 연결 암호화와 관련 검증을 담당하고, 전송 매개변수는 프로토콜 데이터가 어떤 방식으로 전달되는지 설명합니다. TLS를 활성화해도 전송 경로를 생략할 수 있는 것은 아닙니다. Host를 입력했다고 SNI가 올바르게 설정된 것도 아닙니다. 제공된 정보에서 Address, Host, SNI가 서로 다르면 각 값을 해당 필드에 입력하세요. ‘통일’하려고 세 필드에 같은 도메인을 넣어서는 안 됩니다.
인증서 검증에 실패하면 먼저 기기 시간, SNI, 서버 인증서 상태와 정보 변경 여부를 확인하세요. 인증서 검증을 끄는 것을 일반적인 해결책으로 삼지 마세요. 검증을 우회하면 연결 대상 오류를 놓칠 수 있고 서버 신원을 확인하는 능력도 낮아집니다. 특정 테스트 환경을 분석하기 위해 설정을 바꿔야 한다면 변경 내용을 기록하고 테스트가 끝난 뒤 원래 검증 설정으로 되돌리세요.
WireGuard 같은 프로토콜은 다른 키와 인터페이스 매개변수를 사용하므로 일반적인 사용자 이름·비밀번호 양식에 맞춰 입력할 수 없습니다. 개인 키는 민감한 자격 증명이므로 스크린샷이나 일반 메모에 넣지 마세요. 로컬 주소, 피어 공개 키, 라우팅 범위 필드는 한 묶음으로 확인해야 합니다. 값 하나만 바꾸면 핸드셰이크는 성공해도 트래픽이 예상한 대상에 도달하지 않을 수 있습니다.
저장 후 최소한의 연결 확인부터 진행
수동 입력 항목에는 ‘수동’과 용도를 표시하는 알아보기 쉬운 메모를 붙여 구독 항목과 구분하는 것이 좋습니다. 저장한 뒤 해당 서버를 선택하고 동일한 네트워크에서 연결과 접속을 한 번 테스트하세요. 이때 규칙 파일, DNS, 여러 전송 옵션을 동시에 바꾸지 마세요. 실패하면 원본 정보를 기준으로 항목별로 비교해 ‘매개변수 오류’와 ‘현재 네트워크에서 연결 불가’를 별도로 점검하세요.
구독에 포함된 서버를 수정해야 한다면 먼저 독립 항목으로 복사해 테스트하는 방법을 고려하세요. 원격에서 관리하는 항목을 직접 편집하면 다음 업데이트 때 원래 매개변수가 다시 적용되어 로컬 변경 사항이 사라질 수 있습니다. 독립 복사본은 테스트에 편리하지만 구독의 새 매개변수를 자동으로 받지 않습니다. 테스트가 끝난 뒤에도 관리 방법을 기록하고, 복사본을 자동 업데이트되는 항목으로 오해하지 않도록 하세요.
플랫폼과 인터페이스 언어에 따라 필드 이름이 조금씩 다를 수 있습니다. 다른 프로토콜의 스크린샷을 그대로 따라 입력하지 말고, 각 필드의 용도를 프로토콜 정보와 대조하세요. 자주 쓰는 인터페이스 용어는 인터페이스 영어 용어에서 확인할 수 있습니다. 원본 정보를 보관하고 한 번에 하나의 매개변수만 바꾼 뒤 매번 테스트하면, 반복해서 삭제하고 다시 만드는 것보다 문제를 찾기 쉽습니다.
QR 코드 및 클립보드: 내용 확인 후 가져오기
QR 코드, 클립보드, 수동 입력은 정보 입력 방식만 다를 뿐 서버의 권한이나 기능을 바꾸지 않습니다. QR 코드에는 단일 공유 링크, 구독 주소 또는 일반 텍스트가 들어갈 수 있으며 클립보드에도 어떤 내용이든 저장될 수 있습니다. 가져오기 전에 서버 하나, 구독 하나, Config 파일 중 무엇을 가져올 것인지 확인하고, 가져온 뒤 예상한 결과인지 대조하세요.
Scan QR Code 인식 및 권한
Scan QR Code를 열면 시스템에서 카메라 권한을 요청할 수 있습니다. 본인이 보유한 정보를 스캔할 때만 필요한 권한을 허용하세요. 이전에 권한을 거부한 기기라면 시스템의 해당 앱 설정에서 카메라 접근 권한을 확인할 수 있습니다. 카메라가 실행되지 않는 것은 권한이나 기기 문제일 수 있으며 QR 코드의 서버가 만료됐다는 뜻은 아닙니다. 그렇다고 구독을 다시 만들 필요도 없습니다.
스캔 전에 QR 코드 전체가 화면에 보이도록 하고 인식에 필요한 주변 여백을 남기세요. 반사, 가림, 심한 흐림은 피해야 합니다. 긴 매개변수가 포함된 QR 코드는 무늬가 촘촘하므로 너무 작게 표시하면 인식에 실패할 수 있습니다. 다른 화면에 표시된 자료라면 적당히 확대하세요. QR 코드만 남도록 주변을 잘라내지는 마세요.
QR 코드가 현재 기기의 이미지에 있다면 인터페이스에 사진 보관함에서 가져오는 기능이 제공되는 경우에만 해당 메뉴를 사용하세요. 옵션이 없다면 원본 텍스트로 돌아가 링크를 복사해 가져올 수 있습니다. 사진 보관함에서 이미지를 볼 수 있다는 것과 앱에서 이미지를 인식할 수 있다는 것은 다릅니다. 가져오기와 관련 없는 시스템 권한을 반복해서 허용하지 마세요.
클립보드에는 완전한 정보 하나만 복사
서비스 제공업체에서 링크를 복사할 때는 앞이나 끝이 잘리지 않도록 제공업체의 복사 기능을 사용하세요. 복사한 뒤 바로 Shadowrocket으로 돌아와 해당 클립보드 가져오기 메뉴를 사용합니다. 시스템에서 붙여넣기 접근을 묻는다면 실제로 가져오려는 상황인지 확인한 뒤 허용하세요. 거부해서 내용을 읽지 못한 것은 원본 링크 형식이 잘못됐다는 뜻이 아닙니다.
채팅 앱, 이메일, 문서에서는 링크 앞뒤에 따옴표, 글머리 기호, 설명 문구가 붙을 수 있습니다. 가져오기 전에 ‘여기를 클릭’ 같은 제목은 빼고 실제 링크만 남기세요. 긴 주소가 화면에서 여러 줄로 보이는 것은 표시상의 줄바꿈일 수 있어 복사하면 한 줄로 유지됩니다. 원본 텍스트에 실제 공백이나 줄바꿈이 들어갔다면 문자를 임의로 지우지 말고 원본에서 다시 복사하세요.
문제 해결 중에는 특히 한 번에 인식 가능한 정보 하나만 가져오세요. 여러 구독 주소, 단일 링크 여러 개, 설명 문단을 한데 붙여 넣으면 일부만 처리되거나 예상과 다른 항목이 만들어질 수 있습니다. 일괄 처리 전에 항목 하나로 형식을 확인한 뒤, 가져온 항목의 개수와 출처를 확인하세요. 성공 알림이 떴는지만으로 판단해서는 안 됩니다.
가져온 뒤 세 단계로 확인
첫째, 예상한 항목이 맞는지 확인합니다. 구독 하나를 가져오려 했다면 비슷한 주소의 서버 항목 하나가 아니라 업데이트할 수 있는 구독 항목이 보여야 합니다. 둘째, 매개변수가 완전한지 확인합니다. 항목을 열어 Type, Address, Port와 필요한 전송 설정을 살펴보세요. 셋째, 연결을 확인합니다. 해당 항목을 선택해 테스트하고 본인이 이용 권한을 가진 서비스에 접속해 보세요.
같은 정보로 수동 입력하면 연결되는데 QR 코드 가져오기는 실패한다면 QR 코드가 ‘만료됐다’고 단정하지 말고 두 항목의 필드를 비교하세요. 인코딩 과정에서 전송 매개변수가 빠졌거나 공유 형식이 현재 가져오기 기능에서 지원하는 범위와 다를 수 있습니다. 비교를 위해 두 항목을 남겨 두되, 메모를 다르게 붙여 이후 테스트에서 잘못 선택하지 않도록 하세요.
반대로 QR 코드 가져오기는 작동하지만 수동 입력이 실패한다면 수동으로 입력할 때 빠뜨린 필드와 특수문자를 먼저 확인하세요. 공유 링크에는 TLS나 경로 옵션이 눈에 띄지 않게 포함돼 있을 수 있으며, 화면에는 서버 이름만 표시되기도 합니다. 이름과 포트만 비교해 두 설정이 같다고 판단하지 마세요. 전체 설정을 펼쳐 항목별로 확인한 뒤 중복을 정리하세요.
가져오기가 끝나면 더 이상 필요하지 않은 클립보드 내용을 지우고 자격 증명이 담긴 임시 스크린샷을 삭제할 수 있습니다. 자료가 다른 기기나 클라우드에도 동기화됐다면 현재 기기에서 지워도 모든 복사본이 삭제되는 것은 아닙니다. 인식 문제를 설명할 때는 오류 메시지, 정보 유형, 사용한 메뉴를 알려주면 됩니다. 아직 유효한 QR 코드나 전체 링크를 보내지 마세요.
업데이트 방법: 시점을 관리하고 되돌릴 상태 보존
구독 업데이트는 원격 정보를 다시 요청하는 작업이지 로컬 목록이 그대로 있는지 확인하는 작업이 아닙니다. 원격 내용이 바뀌면 서버가 추가·삭제·수정되거나 메모와 순서가 달라질 수 있습니다. 적절한 업데이트 방법은 정보 변경 빈도, 현재 네트워크에서 구독 리소스에 접근할 수 있는지, 보존해야 할 로컬 수정 사항이 있는지를 함께 고려해야 합니다. 업데이트 횟수가 많을수록 더 안전한 것은 아닙니다.
첫 업데이트는 결과를 확인할 수 있도록 수동으로 진행
구독을 처음 추가한 뒤에는 수동 업데이트를 실행해 요청이 성공하는지, 반환된 내용을 파싱할 수 있는지, 항목이 예상대로 표시되는지 확인하세요. 과정이 정상임을 확인한 다음 인터페이스에서 실제 제공하는 옵션에 따라 자동 업데이트를 설정합니다. 처음 가져오기가 끝나기도 전에 자동 동작을 여러 개 켜면 목록 변화가 직접 한 조작 때문인지 백그라운드 업데이트 때문인지 판단하기 어렵습니다.
업데이트 전에 현재 사용할 수 있는 서버의 이름, 소속 구독, 사용 중인 Config 파일을 기록하세요. 중요한 수동 변경 사항은 독립 복사본으로 저장하거나 로컬에 백업할 수 있습니다. 구독 항목은 원격 정보가 관리하므로 로컬에서 수정한 내용이 새로고침 후에도 유지된다는 보장이 없습니다. 특정 매개변수를 구독의 원래 값과 다르게 계속 사용해야 한다면 우연히 덮어써지지 않기를 기대하기보다 독립 항목으로 관리하세요.
자동 업데이트 간격은 실제 필요에 따라 정하세요. 정보가 오랫동안 안정적이라면 짧은 간격으로 계속 요청할 필요가 없습니다. 서버 변경을 처리 중이라면 정보가 수정된 것을 확인한 뒤 한 번 수동 업데이트하면 됩니다. 너무 자주 재시도하면 원격에서 요청을 제한할 수 있고 오류 기록만 쌓일 뿐, 주소 만료, 인증 실패, 응답 형식 불일치는 해결되지 않습니다.
네트워크 요청 실패와 콘텐츠 처리 실패를 구분
요청 시간 초과라면 현재 네트워크와 구독 주소에 접근할 수 있는지 확인하세요. 내용은 반환됐지만 파싱할 수 없다면 리소스가 로그인 페이지, 오류 페이지 또는 다른 형식으로 바뀌었는지 살펴보세요. 인터페이스에 인증 오류가 표시되면 서비스 제공업체에 주소와 자격 증명이 아직 유효한지 문의하세요. 이 경우 로컬 서버 메모를 바꿔도 구독 요청 결과에는 대개 영향이 없습니다.
구독 리소스에 접근하는 경로와 서버 연결 경로는 다를 수 있습니다. 서버에 연결할 수 있어도 구독 주소에 접근할 수 있다는 보장은 없고, 구독 업데이트가 성공해도 그 안의 모든 서버에 연결할 수 있는 것은 아닙니다. 업데이트 결과와 연결 테스트 결과를 따로 기록하세요. 한쪽이 성공했다고 다른 쪽의 문제까지 없다고 판단해서는 안 됩니다.
문제를 확인할 때는 한 번에 조건 하나만 바꾸세요. 예를 들어 같은 구독 주소를 유지하고, 본인이 사용할 수 있는 다른 네트워크에서 다시 시도할 수 있습니다. URL, DNS, Global Routing, 여러 서버 매개변수를 동시에 수정하면 복구되더라도 원인을 알기 어렵습니다. 업데이트가 기존 목록을 대체할 수 있다면 여러 항목에 영향을 주는 작업 전에 이전 정보를 백업했는지 확인하세요.
| 증상 | 먼저 확인할 항목 | 미루어야 할 작업 |
|---|---|---|
| 요청 시간 초과 | 현재 네트워크 및 리소스 접근성 | 구독을 반복해서 삭제 |
| 내용을 파싱할 수 없음 | 응답 형식 및 오류 페이지 여부 | 인코딩된 본문 수정 |
| 업데이트 후 항목 감소 | 원격 변경 및 구독 소속 | 남은 목록을 즉시 비우기 |
| 로컬 매개변수가 원래 값으로 돌아감 | 구독 데이터로 덮어써졌는지 확인 | 같은 원격 항목을 계속 편집 |
업데이트 후 소규모 점검
성공 알림이 표시되면 자주 쓰는 항목 하나와 예비 항목 하나 이상을 확인해 프로토콜, 주소, 연결 상태에 이상이 없는지 살펴보세요. 서버 이름이 바뀌었다면 규칙이나 선택 기록이 해당 이름에 의존하는지도 확인해야 합니다. 목록에 표시된다고 해서 이전에 고정해 사용하던 항목이 그대로 남아 있다는 뜻은 아닙니다. 원격에서 이름을 바꾸거나 항목을 합친 경우 특히 주의하세요.
업데이트가 실패했지만 기존 항목으로 계속 연결할 수 있다면 기존 상태를 유지하고 구독 요청 문제부터 해결하세요. 오류 알림을 없애려고 전체 목록을 비우지 마세요. 업데이트는 성공했지만 연결이 되지 않으면 업데이트 전후의 매개변수를 비교하고 서비스 제공업체에 변경 사항을 확인하세요. 이전 이름으로 되돌리는 것만으로 이미 바뀐 서버 인증 정보가 복구되지는 않습니다.
마지막으로 앱 업데이트와 구독 업데이트를 구분하세요. 전자는 Shadowrocket 프로그램을 변경하고, 후자는 원격 서버 정보를 변경합니다. 앱 업데이트와 설치 안내는 다운로드 페이지에서 확인하세요. 구독을 업데이트해도 클라이언트가 자동으로 업그레이드되지는 않으며, 클라이언트를 다시 설치해도 만료된 구독 주소가 자동으로 복구되지는 않습니다. 두 관리 절차를 각각 확인하고 기록하세요.
여러 구독 정리: 이름과 출처를 관리해 중복 줄이기
여러 구독 관리의 핵심은 모든 서버를 더 긴 목록 하나로 합치는 것이 아니라, 각 항목의 출처와 업데이트 방식, 독립 복사본 여부를 파악하는 것입니다. 정렬이나 삭제를 고민하기 전에 먼저 출처 관계를 정리하세요. 이름만 보고 중복을 제거하면 용도가 다른 서버를 잘못 지울 수 있고, 개수만으로 정리 결과를 판단하면 아직 사용하는 독립 설정까지 삭제할 수 있습니다.
구독과 독립 항목에 각각 이름을 붙이기
구독 이름은 정보의 출처와 용도를 나타내고 서버 메모는 구체적인 연결 항목을 구분합니다. 두 이름은 서로를 대신해서는 안 됩니다. 모든 서버를 같은 구독 이름으로 바꾸면 항목별 차이를 알기 어렵고, 원격 서버 이름만 남기고 구독 출처를 기록하지 않으면 여러 목록에 같은 이름이 있을 때 어느 그룹을 업데이트하거나 삭제해야 할지 판단하기 어렵습니다.
‘일상 / 개인’, ‘테스트 / 개인’처럼 용도와 리소스 그룹을 짧은 구독 이름으로 사용할 수 있습니다. 수동 복사본에는 ‘수동’ 표시를 붙이고 원래 구독 이름을 기록하세요. 각 항목에 전체 날짜나 긴 설명을 쓸 필요는 없으며 비밀번호나 구독 자격 증명을 이름에 넣지 마세요. 이름은 식별을 돕기 위한 것이지 민감한 정보 목록이 되어서는 안 됩니다.
한 구독의 업데이트와 확인을 마친 뒤 다음 구독을 처리하세요. 구독을 추가할 때마다 같은 URL이 이미 있는지, 그 안의 서버를 단일 링크로 따로 가져온 적이 있는지 확인합니다. 출처가 중복돼도 이름이 같다는 보장은 없습니다. 같은 구독을 여러 번 추가하고 메모를 다르게 붙일 수도 있으므로 구독 항목 자체의 출처와 주소를 비교해야 합니다.
서버 이름만으로 중복 여부를 판단하지 마세요
이름이 같은 두 항목도 주소, 포트, 인증 정보, 전송 매개변수가 다를 수 있습니다. 이름이 달라도 실제 연결 매개변수는 같을 수 있습니다. 중복을 정리하려면 프로토콜 유형과 대상 주소를 먼저 비교하고 포트, 인증 정보, 주요 전송 설정을 확인하세요. 자격 증명 비교는 이 기기에서 진행하고, 대조를 위해 공개 스프레드시트나 웹 도구에 올리지 마세요.
연결 매개변수가 같더라도 관리 방식이 다른지 고려해야 합니다. 하나는 구독에서 온 항목이고 다른 하나는 독립 수동 복사본이라면 전자는 원격 업데이트를 받고 후자는 그렇지 않습니다. 삭제 전에 어떤 관리 방식을 유지할지 결정하세요. 수동 복사본에 필요한 로컬 수정이 포함돼 있다면 주소가 같다는 이유만으로 삭제할 수 없습니다. 오래된 임시 테스트 기록에 불과하다면 구독 항목을 확인한 뒤 정리할 수 있습니다.
구독 안의 서버를 삭제해도 다음 업데이트 때 원격 목록에 해당 항목이 남아 있으면 다시 나타날 수 있습니다. 이는 중복 제거 실패가 아니라 로컬 삭제와 원격 관리의 범위가 다르기 때문입니다. 인터페이스에 구독별 필터나 관리 옵션이 있다면 실제 기능에 맞게 설정하세요. 해당 옵션이 없다면 업데이트로 원격 항목이 복원될 수 있음을 감안하고, 목록 모양을 유지하려고 계속 삭제하지 마세요.
한 번의 테스트 결과가 아니라 사용 흐름에 따라 분류
일상, 예비, 테스트처럼 실제 용도에 따라 분류하는 것이 안정적입니다. 한 번 측정한 지연 시간은 당시 네트워크 상태를 반영할 뿐 영구적인 분류 기준이 되지 않습니다. 테스트가 한 번 느렸다고 해당 항목을 모두 일상 목록에서 옮기면 네트워크를 바꾼 뒤 다시 정리해야 합니다. 목록 전체를 자주 다시 만드는 것보다 확인된 예비 항목을 몇 개 유지하는 편이 관리하기 쉽습니다.
인터페이스에서 정렬이나 이동을 지원한다면 자주 쓰는 구독과 서버를 쉽게 찾을 수 있는 위치에 둘 수 있습니다. 현재 인터페이스가 원하는 순서를 지원하지 않는다면 알아보기 쉬운 메모와 그룹 보기로 관리하세요. 모든 플랫폼에서 표시 순서를 완전히 똑같이 맞출 필요는 없습니다. 원격 업데이트로 순서가 바뀔 수도 있으므로 ‘세 번째 줄에 있다’는 점을 서버 식별 기준으로 삼지 마세요.
정리할 때는 명백한 중복 구독, 임시 복사본, 장기간 사용하지 않지만 복구가 필요할 수 있는 정보 순으로 처리하세요. 한 번에 한 종류의 항목만 정리하고 현재 선택된 서버가 영향을 받는지 확인합니다. 연결이 특정 정보에 의존하는 동안 해당 그룹을 바로 삭제하지 마세요. 보존할 항목으로 먼저 전환해 확인한 뒤 정리하는 편이 안전합니다.
정리를 마친 뒤 남긴 구독마다 업데이트가 되는지, 자주 쓰는 그룹마다 사용할 수 있는 항목이 하나 이상 있는지 확인하고 새 관리 상태를 저장하세요. 그룹을 정리하고 중복 항목을 다루는 방법은 여러 구독 관리 가이드에서 확인할 수 있습니다. 장기 관리에서는 목록을 가장 짧게 만드는 것보다 출처를 명확히 하고 변경 사항을 추적하는 것이 중요합니다.
지연 시간 테스트와 정렬: 실제 연결 상황을 고려해 결과 해석
지연 시간 테스트는 특정 테스트 방식으로 응답을 확인하는 것으로, 앱을 실제로 사용할 때의 전체 체감과 같지 않습니다. 수치가 낮더라도 대역폭, 패킷 손실, 인증, TLS, 대상 서비스 응답의 영향을 받을 수 있습니다. 시간 초과가 표시된 항목도 테스트 대상과 방식에 따라 해석해야 합니다. 무엇을 측정했는지 먼저 확인한 뒤 결과를 서버 선택에 반영할지 결정하세요.
네트워크, 테스트 방식, 비교 범위를 일정하게 유지
Home 또는 관련 테스트 메뉴에서 Connectivity Test를 사용할 때는 인터페이스에 실제로 어떤 테스트 방식이 제공되는지 확인하세요. 방식에 따라 서버까지의 특정 단계만 확인하거나 프록시를 통해 특정 대상에 요청할 수 있습니다. 같은 방식, 같은 네트워크, 비슷한 시간대에 얻은 결과만 직접 비교할 수 있습니다. 조건이 다른 이전 테스트 결과를 한데 섞어 정렬하지 마세요.
먼저 자주 쓰는 서버 몇 개를 테스트해 대상이 정상인지 확인한 뒤 범위를 넓히세요. 목록이 길 때 한꺼번에 테스트하면 기기 네트워크와 동시 연결의 영향을 받을 수 있습니다. 모든 항목이 거의 동시에 시간 초과되면 서버가 모두 만료됐다고 판단하기보다 기기 네트워크, 테스트 대상, 현재 설정부터 확인하세요. 사용 가능한 것으로 확인된 항목 하나를 기준으로 삼으면 원인을 찾기 쉽습니다.
한 번의 결과는 순간적인 변동에 영향을 받기 쉽습니다. 후보 항목을 여러 번 테스트해 결과가 안정적인지, 시간 초과가 자주 발생하는지 살펴보세요. 가장 낮은 수치 한 번만 고르지 마세요. Wi-Fi나 모바일 네트워크를 바꾸면 이전 정렬이 더는 적합하지 않을 수 있으므로 현재 실제로 사용할 환경에서 다시 확인하세요. 한 번의 테스트 결과를 서버의 고정된 특성으로 취급해서는 안 됩니다.
서버 연결과 대상 접속을 구분
서버에 연결을 맺었다고 프록시 프로토콜 인증까지 성공한 것은 아닙니다. 프로토콜 인증이 성공해도 대상 웹사이트가 정상적으로 응답한다는 보장은 없습니다. 문제를 찾을 때는 네트워크 접근, 프로토콜 핸드셰이크, 대상 요청의 세 단계로 나눠 기록할 수 있습니다. 특정 단계에서 실패한다면 해당 단계와 관련된 매개변수를 먼저 확인하고 모든 실패를 ‘지연 시간이 너무 높음’으로 단정하지 마세요.
실제 접속을 확인할 때는 Global Routing도 살펴봐야 합니다. Config 모드는 활성화된 규칙에 따라 정책을 결정하고, Proxy 모드는 프록시 트래픽을 직접 확인하는 데 쓰이며, Direct 모드로는 서버 프록시가 정상인지 증명할 수 없습니다. 여기서 모드 이름은 인터페이스의 Config, Proxy, Direct를 가리킵니다. 테스트가 끝나면 임시 설정을 계속 남겨 두지 말고 평소 사용하는 모드로 되돌리세요.
| Global Routing | 진단 목적 | 주의할 점 |
|---|---|---|
| Config | 실제 규칙에 따른 트래픽 분기 확인 | 대상이 DIRECT 또는 REJECT 규칙에 매칭될 수 있음 |
| Proxy | 프록시 연결 경로를 집중적으로 확인 | 시스템 및 Config 예외의 영향을 받을 수 있음 |
| Direct | 직접 연결 상태의 동작 확인 | 선택한 서버의 사용 가능 여부를 증명하지 못함 |
Config 모드에서 대상이 DIRECT에 매칭되면 접속에 성공해도 선택한 서버가 작동한다는 뜻은 아닙니다. REJECT에 매칭되어 실패해도 서버 자체에 접근할 수 없다는 뜻은 아닙니다. 현재 규칙, 연결 기록, 대상 도메인을 함께 확인해 실제 적용된 정책을 판단하세요. 관련 규칙 키워드는 용어 매뉴얼에서 확인할 수 있습니다. 대상 하나의 테스트 결과만으로 전체 구독을 바로 교체하지 마세요.
정렬은 후보 범위를 좁히는 데만 사용
테스트 결과로 정렬한 뒤 안정적인 항목 몇 개를 골라 실제로 사용할 서비스에 연결해 확인하세요. 상호작용이 많은 요청, 장시간 전송, 지속 연결은 네트워크 요구 사항이 서로 다릅니다. 짧은 요청 한 번으로 모든 사용 상황을 판단할 수 없습니다. 서버 메모에 직접 적은 속도나 용도를 클라이언트가 측정해 확인한 결과처럼 취급해서도 안 됩니다.
안정적인 후보 하나와 확인된 예비 항목 하나만 유지해도 일상적인 관리에 충분한 경우가 많습니다. 예비 항목으로 전환할 때는 비교하기 쉽도록 같은 Config와 같은 대상 서비스를 유지하세요. 규칙, 네트워크, 서버를 동시에 바꾸면 접속은 복구될 수 있지만 원인을 파악할 수 없습니다. 이후 같은 문제가 생기면 다시 처음부터 점검해야 합니다.
테스트는 정상인데 연결 후 일부 앱이 작동하지 않는다면 계속 정렬을 반복하기보다 DNS, 규칙 매칭, 앱의 기존 연결, 대상 서비스 제한을 확인하세요. 일부 앱은 이전에 맺은 연결을 재사용하므로 설정 변경 후 새 요청을 보내야 새 경로를 확인할 수 있습니다. 비교 전에 테스트 대상의 이전 요청을 종료해 캐시된 동작을 현재 설정 결과로 오해하지 않도록 하세요.
이번에 사용한 네트워크 환경, 테스트 방식, 선택한 항목, 최종 접속 결과를 기록하세요. 모든 수치를 매번 저장할 필요는 없습니다. 유용한 기록은 ‘어떤 조건에서 작동하고 어떤 조건에서 실패하는지’입니다. 처음 연결할 때 자주 막히는 지점은 초보자 자주 묻는 질문에서 확인한 뒤 이 장의 단계별 방법으로 더 살펴보세요.
삭제 및 백업: 복원 범위를 확인한 뒤 정리
삭제할 때는 가장 작은 항목부터 처리하고, 백업할 때는 먼저 어떤 범위가 포함되는지 확인하세요. 서버 하나, 구독 하나, Config 파일은 서로 다른 항목이며 하나를 삭제해도 나머지 관리가 대신 되지는 않습니다. 정리 전에 화면에 보이는 항목만 제거할지, 원격 정보 전체를 삭제할지, 더는 사용하지 않는 규칙을 지울지 명확히 하세요. 일부 문제를 해결하려고 ‘전부 다시 시작’하지 않도록 주의하세요.
삭제 전에 현재 연결의 의존 항목 확인
현재 선택한 서버를 삭제하려면 먼저 확인된 다른 항목으로 전환해 연결이 정상인지 확인하세요. 구독 전체를 삭제하려면 그 안에 아직 사용하는 예비 항목이 있는지, 규칙이나 선택 기록이 특정 이름에 의존하는지 확인해야 합니다. 삭제는 목록을 줄이는 데 그치지 않고 이후 선택할 수 있는 연결 항목에도 영향을 줄 수 있습니다. 의존 관계를 먼저 정리한 뒤 삭제하세요.
구독 내 서버 하나를 삭제해도 다음 업데이트에서 다시 나타날 수 있습니다. 구독 항목 자체를 삭제하면 해당 서버들도 함께 제거될 수 있으므로 정확한 범위는 인터페이스의 확인 메시지를 따르세요. 실행 전에 확인 문구를 꼼꼼히 읽고 버튼 문구 길이로 영향 범위를 추측하지 마세요. 잠시 사용하지 않으려는 것뿐이라면 전체 정보를 바로 삭제하기보다 선택을 바꾸거나 인터페이스에서 제공하는 비활성화 방법을 우선 고려하세요.
Config 파일 삭제와 서버 삭제도 따로 관리해야 합니다. 현재 사용하는 규칙 파일은 DIRECT, PROXY, REJECT 매칭을 결정할 수 있으므로 서버 매개변수를 바꾸지 않아도 삭제하거나 교체하면 접속 방식이 달라질 수 있습니다. 규칙 파일을 정리하기 전에 일상적으로 사용할 Config를 확인하고, 직접 추가한 로컬 네트워크 또는 도메인 규칙이 있는지 기록하세요.
파일 하나가 있다는 것보다 백업 항목을 확인하는 것이 중요
백업에는 구독 주소, 독립 서버, 현재 Config, 중요한 로컬 수정 사항, 다시 설정해야 할 연결 옵션을 포함할지 검토해야 합니다. 내보내기 메뉴마다 포함하는 항목이 다를 수 있습니다. 서버 하나를 공유하는 것으로 전체 Config를 백업할 수는 없고, 규칙만 담긴 .conf로 모든 서버를 자동 복원할 수도 없습니다. 내보낸 뒤에는 파일이나 내용의 유형을 확인하세요. 저장됐다는 이유만으로 복원 정보가 모두 갖춰졌다고 판단하지 마세요.
Settings 또는 해당 항목의 관리 메뉴에서 인터페이스가 실제로 제공하는 내보내기, 백업, 공유 기능만 사용하세요. 전체 백업 메뉴가 없다면 복원할 항목을 각각 저장하고 간단한 목록을 작성하세요. 각 자료의 용도와 복원 순서를 기록하면 충분합니다. 모든 비밀번호를 일반 메모에 평문으로 다시 적어 불필요한 노출 위험을 늘리지 마세요.
백업에는 구독 자격 증명, 서버 비밀번호, 사용자 식별자, 개인 키가 포함될 수 있습니다. 접근 보호가 설정된 본인이 관리하는 위치에 저장하세요. 시스템 클라우드 저장소와 동기화한다면 계정 보호와 로그인된 다른 기기도 고려해야 합니다. 백업을 채팅에 일반 첨부 파일처럼 장기간 남겨 두지 말고, 형식 확인을 위해 유효한 설정 전체를 다른 사람에게 보내지 마세요.
순서대로 복원한 뒤 연결 확인
복원할 때는 먼저 올바른 경로에서 받은 클라이언트인지 확인하고, 구독과 독립 서버를 가져온 다음 Config를 복원하고 마지막으로 Global Routing 및 기타 연결 옵션을 설정하세요. iPhone / iPad 정품 확인 항목은 개발자 Shadow Launch Technology Limited, 공식 아이콘, 앱 ID 932747118입니다. 다른 플랫폼의 이용 안내와 이 사이트의 설치 파일은 정품 확인 섹션에서 확인할 수 있습니다.
구독 주소를 복원한 뒤 업데이트를 실행해 원격 정보가 바뀌었는지 확인하세요. 이전 백업의 서버를 가져올 수 있더라도 인증 정보나 대상 주소가 더 이상 유효하지 않을 수 있습니다. 따라서 예전 항목이 보인다는 것만으로 복원이 끝났다고 볼 수 없습니다. 독립 서버는 각 매개변수가 여전히 유효한지 확인해야 하며, 구독 관리에서 분리된 복사본이 구독 업데이트로 자동 수정되리라 기대해서는 안 됩니다.
복원이 끝나면 자주 쓰는 항목, 예비 항목, 현재 규칙, 실제 대상 접속을 차례로 확인하세요. On Demand를 사용하는 경우 자동 연결 동작도 예상대로인지 확인하되 기본 연결을 검증하기 전에 자동 동작까지 함께 켜지 마세요. 문제가 발견되면 원본 백업을 보존한 채 복원한 정보에서 작은 범위로 조정하세요. 비교할 마지막 상태를 덮어쓰지 않도록 주의하세요.
기기를 바꾼 뒤에도 과거 자료를 모두 계속 보관할 필요는 없습니다. 새 기기에서 업데이트와 연결이 되는지, 일상 규칙을 사용할 수 있는지 확인한 다음 이전 기기의 자격 증명과 임시 내보내기 파일을 정리하세요. 이전 기기를 더 이상 직접 관리하지 않는다면 서비스 제공업체에 문의해 취소하거나 갱신해야 할 자격 증명이 있는지도 확인하세요. 기기에서 앱만 삭제해도 이전에 복사한 주소와 백업까지 무효화되는 것은 아닙니다.
일상적인 관리는 다음 순서로 진행하세요. 변경 전 백업하고, 변경 중에는 한 종류의 항목만 수정하며, 변경 후 테스트하고 안정성을 확인한 다음 정리합니다. 연결 과정을 처음부터 다시 진행해야 한다면 빠른 시작 가이드로 돌아가세요. 여러 리소스를 정리하려면 이 페이지의 여러 구독 정리 섹션을 확인하세요. 복원 경로를 명확히 남겨 두면 다음 업데이트와 문제 해결도 관리할 수 있습니다.