Shadowrocket 구독 및 서버 관리

01 / 업데이트 가능한 목록 가져오기

Subscribe 메뉴와 항목 간 관계

구독, 서버, Config 파일 구분하기

구독은 반복해서 가져올 수 있는 서버 목록이고, 서버는 개별 연결 정보이며, Config 파일은 요청이 규칙에 어떻게 매칭되고 어떤 정책으로 처리될지 정합니다. 서로 관련은 있지만 같은 항목은 아닙니다. 구독 업데이트에 성공했다는 것은 목록을 가져와 해석했다는 뜻일 뿐, 선택한 서버에 연결할 수 있다는 의미는 아닙니다. 서버 연결이 되더라도 현재 Config가 예상대로 트래픽을 분기한다는 보장은 없습니다. 문제를 살펴보기 전에 어떤 항목을 다루는지 먼저 확인하면 규칙 문제를 구독 문제로 오해하지 않을 수 있습니다.

Home에서 현재 서버와 소속 구독을 확인하고, Config에서 설정 관련 항목을 관리합니다. 이 매뉴얼의 기본 흐름에 따라 Config에서 Subscribe 메뉴를 찾으세요. 사용하는 플랫폼에서 구독 추가가 Home의 플러스 메뉴에 통합되어 있다면 Add Server에서 Subscribe 유형을 선택하면 됩니다. 플랫폼마다 메뉴 단계가 다를 수 있으므로, 다른 기기의 버튼 위치를 무작정 따라가기보다 양식의 유형과 URL 입력란을 기준으로 판단하세요.

추가하기 전에 링크의 용도 확인하기

구독 URL은 이용 중인 서비스 제공업체에서 받아야 합니다. 링크와 함께 제공된 안내를 먼저 읽고, Shadowrocket 서버 구독용인지 계정 관리 페이지나 안내 페이지 또는 전체 규칙 설정인지 확인하세요. 브라우저에서 URL이 열린다고 해서 클라이언트가 응답 내용을 서버 목록으로 해석할 수 있다는 뜻은 아닙니다. 링크에 계정 식별 정보가 포함되어 있다면 물음표 뒤의 내용까지 빠짐없이 복사하고, 채팅 앱에서 붙은 문장 부호는 포함하지 마세요.

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

Subscribe 양식에 알아보기 쉬운 이름과 전체 URL을 입력하고 저장한 뒤 업데이트를 실행합니다. 처음 가져오는 동안 네트워크 연결을 안정적으로 유지하고, 결과가 나오면 Home으로 돌아가 서버 항목이 표시되는지, 기존 정보에 비해 항목 수가 적절한지, 이름을 읽을 수 있는지 확인하세요. 성공 여부를 특정 개수로 판단하지 마세요. 서버 측에서 목록을 조정하면 결과도 달라질 수 있으므로 본인의 이용 권한과 서비스 제공업체의 안내를 기준으로 확인해야 합니다.

결과를 보고 실패 단계 구분하기

저장 후 서버가 보이지 않는다면 클라이언트가 실제로 URL을 요청했는지부터 확인하세요. 이름은 표시되지만 목록이 비어 있다면 가져오기 실패, 응답 내용 없음 또는 형식 해석 실패일 수 있습니다. 인증 오류가 표시되면 링크가 변경되거나 만료되었는지, 전체 내용이 복사되었는지 확인하세요. 웹페이지 내용이 반환되었다면 구독 API가 아니라 로그인 페이지에 접속한 것은 아닌지 살펴보세요. 같은 실패 URL을 구독으로 여러 번 추가하지 마세요. 빈 그룹만 늘어날 뿐 요청 결과는 달라지지 않습니다.

일부 항목만 나타나고 나머지가 누락되었다면 누락된 항목의 프로토콜과 매개변수가 현재 플랫폼에서 지원되는지, 구독이 원래 일부 내용만 반환하는지 확인하세요. 우선 정상적으로 읽힌 결과는 유지하고 실패 현상을 기록한 뒤 기존 서버 정보와 대조합니다. 목록을 완전하게 보이게 하려고 알 수 없는 비밀번호, 포트 또는 전송 매개변수를 임의로 채우지 마세요. 서버 측 정보와 일치해야 하는 값입니다. 추측으로 만든 항목은 저장되더라도 연결되지 않을 수 있습니다.

서버 항목은 있지만 연결 결과가 이상하다고 해서 바로 구독을 삭제하고 다시 만들 필요는 없습니다. 먼저 서버 하나를 선택해 다음 장의 개별 테스트를 진행한 뒤 Global Routing을 확인하세요. 이렇게 하면 목록 가져오기와 트래픽 사용을 따로 검증할 수 있습니다. 처음부터 순서대로 따라 해야 한다면 사용 가이드를 참고하세요. 이 페이지의 다음 장에서는 입력란, 업데이트, 정리 방법을 각각 설명하므로 구체적인 문제를 확인할 때 유용합니다.

02 / 개별 서버 항목 확인하기

Add Server 수동 입력란 및 프로토콜 매개변수

먼저 Type을 선택한 다음 원본 정보 입력하기

수동 입력은 서버 정보를 모두 알고 있고 문제 확인을 위해 항목 하나를 따로 관리할 때 적합합니다. Home에서 Add Server를 열고 먼저 Type을 선택한 다음 표시되는 입력란을 채우세요. 프로토콜을 선택하면 뒤이어 표시되는 양식이 달라지므로, 기본 양식에 모든 정보를 입력한 뒤 마지막에 유형을 바꾸지 마세요. 저장하기 전에 원본 정보와 항목별로 대조하세요. 특히 복사한 내용에 공백, 줄바꿈, 전각 콜론이 포함되었는지, 포트가 주소란에 잘못 입력되었는지 확인하세요.

Address에는 보통 서버 도메인이나 주소를 입력하고, Port에는 포트 번호를 따로 입력합니다. Address 앞에 웹 주소의 프로토콜 접두사를 붙이지 마세요. 도메인과 웹페이지에 접속할 때 사용하는 경로는 서로 다릅니다. 경로는 해당 전송 설정란에 입력해야 합니다. IPv6 주소는 공유 링크의 대괄호 표기와 양식에서 요구하는 형식을 구분하세요. 양식에서 주소와 포트를 따로 입력하도록 되어 있다면 주소와 포트가 합쳐진 전체 문자열을 붙여 넣지 마세요. 이름은 항목을 구분하기 위한 용도일 뿐, 연결 매개변수를 수정해 주지 않습니다.

비슷한 이름의 입력란이라도 서로 바꿔 쓸 수 있는 것은 아닙니다.

Shadowsocks는 암호화 방식과 비밀번호가 모두 일치해야 합니다. 비밀번호만 같다고 설정이 올바른 것은 아닙니다. VMess와 VLESS에는 UUID가 사용되는 경우가 많지만 UUID가 같다고 두 프로토콜을 서로 바꿔 쓸 수 있는 것은 아닙니다. 전송 방식과 관련 추가 입력란도 정확히 맞아야 합니다. Trojan 인증 정보는 해당 비밀번호 입력란에 넣고, HTTP와 SOCKS5는 계정 인증이 활성화되어 있는지 확인하세요. 제공되지 않은 선택 항목은 우선 기본값을 유지하세요. 다른 서버 항목의 설정을 복사해 그럴듯한 값으로 채우지 마세요.

TLS 스위치, SNI, Host, Path는 각각 역할이 다릅니다. Address는 연결할 대상을 지정하고, SNI는 암호화 핸드셰이크에 사용할 서버 이름이며, Host는 애플리케이션 계층 요청에 사용될 수 있고, Path는 해당 전송 경로를 지정합니다. 값이 서로 같아 보일 수 있지만, 그렇다고 항상 같아야 하는 것은 아닙니다. 원본 정보에 서로 다른 값이 있다면 각각 그대로 입력하세요. 양식을 깔끔하게 보이게 하려고 억지로 통일하거나 웹페이지에 표시된 리디렉션 도메인을 SNI로 입력하지 마세요.

Hysteria2, WireGuard 등의 유형은 별도의 인증 정보나 키가 필요할 수 있습니다. 구독에서 해당 매개변수를 정확히 제공했거나 서버 설정 전체를 보유한 경우에만 추가하세요. 뜻을 알 수 없는 입력란이 있다면 원본 정보로 돌아가 의미를 확인하세요. 저장을 위해 임의의 문자를 입력해도 겉보기만 완전한 항목이 만들어질 뿐, 프로토콜 설정이 올바르다는 증거는 되지 않습니다. 프로토콜별 기본 차이는 프로토콜 개요에서 확인하세요.

최소한의 변경으로 입력 오류 찾기

저장한 뒤 해당 서버 하나를 선택해 테스트하세요. DNS, 규칙, 연결 모드를 동시에 변경하지 마세요. 테스트에 실패하면 주소 확인, 포트 연결, 인증, 전송 매개변수 순서로 살펴봅니다. 주소 오류는 이름 확인 실패로 나타나는 경우가 많고, 포트나 네트워크 문제는 연결 시간 초과로 나타날 수 있습니다. 인증이나 핸드셰이크 실패는 구체적인 오류 안내를 확인해야 합니다. 오류 메시지는 범위를 좁히는 데 도움이 되지만 입력란을 하나씩 대조하는 일을 대신하지는 않습니다. 예를 들어 연결이 거부되었다면 포트가 잘못되었거나 서버가 해당 포트를 수신 대기하지 않는 것일 수 있습니다.

매개변수를 수정해야 한다면 원인을 설명할 수 있는 항목 하나만 바꾸고, 변경 전후 값과 결과를 기록하세요. 수동 입력 항목은 ‘수동’처럼 알아보기 쉬운 이름을 붙여 구독에서 생성된 항목과 구분하는 것이 좋습니다. 특정 매개변수만 확인하려면 먼저 항목을 복사한 뒤 복사본을 수정하세요. 효과가 확인되면 원본에 반영할지 결정하면 됩니다. 업데이트 동작을 모르는 상태에서 구독 항목을 바로 수정하지 마세요. 다음 목록 새로고침 때 원래 값으로 돌아가 이미 진행한 문제 확인의 비교 기준이 사라질 수 있습니다.

03 / 기존 정보로 항목 만들기

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

QR 코드에 실제로 무엇이 담겼는지 확인하기

QR 코드는 텍스트를 담는 방식이지 독립적인 프로토콜이 아닙니다. 서버 하나의 공유 링크일 수도 있고, 구독 URL이나 일반 웹 주소일 수도 있습니다. Scan QR Code를 연 뒤 인식 결과와 저장 대상부터 확인하고, 본인의 정보와 일치하는지 살펴보세요. 스캔에 성공했다는 것은 이미지의 텍스트를 읽었다는 뜻일 뿐, 대상 주소가 작동하거나 인증 정보가 여전히 유효하다는 보장은 아닙니다. 스캔 안내가 나타났다고 서버 연결까지 완료된 것으로 여기지 마세요.

다른 화면에 표시된 코드를 스캔할 때는 QR 코드 전체가 촬영 영역에 들어오도록 하고 반사광, 가림, 과도한 확대를 피하세요. 카메라 권한이 필요하다면 스캔 메뉴를 사용할 때 시스템 안내에 따라 허용하면 됩니다. 권한을 거부했다면 시스템 설정에서 해당 앱의 권한을 확인하세요. QR 코드 이미지 파일을 이미 가지고 있다면 현재 화면에서 제공하는 이미지 인식 메뉴를 우선 사용하세요. 해당 플랫폼에 이미지 인식 메뉴가 없다면 이미지를 계속 조정하는 것보다 원본 텍스트를 가져오는 편이 보통 더 간단합니다.

인식 결과가 구독 URL이라면 서버 Address에 넣지 말고 Subscribe 출처로 저장하세요. 서버 하나를 인식했다면 저장 후 Type, Address, Port, 인증 입력란을 확인하세요. QR 코드에는 보통 그 안에 인코딩된 내용만 들어 있습니다. 화면에 다른 설명이 함께 보인다고 해서 클라이언트가 그 내용까지 모두 읽었다고 생각하지 마세요. 특히 QR 코드 아래 별도로 적힌 비밀번호, 메모 또는 전송 요구 사항은 코드에 포함되지 않았을 수 있습니다.

클립보드 가져오기에서 텍스트 경계와 인코딩 유지하기

클립보드 가져오기는 전체 공유 링크를 복사해 둔 경우에 적합합니다. 먼저 원본 메시지에서 링크만 복사한 다음 Home 또는 추가 메뉴에서 표시되는 클립보드 가져오기 메뉴를 사용하세요. 시스템에서 붙여넣기를 허용할지 물으면 방금 복사한 내용인지 확인한 뒤 허용합니다. 예상한 항목이 나타나지 않으면 다른 복사 작업으로 클립보드 내용이 바뀌지 않았는지 먼저 확인하세요. 가져오기에 실패했다고 곧바로 프로토콜이 지원되지 않는다고 단정하지 마세요. 클립보드에 제목이나 설명만 남아 있을 수 있습니다.

채팅 앱에서는 긴 링크가 여러 줄로 표시될 수 있지만 화면에서 줄이 바뀌어 보인다고 실제 줄바꿈이 들어간 것은 아닙니다. 복사한 뒤 두 경우를 구분하세요. 텍스트에 실제 줄바꿈이나 공백이 삽입되면 중간에서 프로토콜 해석이 끊길 수 있습니다. 시작 부분의 프로토콜 접두사가 빠졌는지, 끝에 한국어 문장 부호가 붙었는지, 링크가 서식 있는 텍스트의 표시 이름으로 바뀌었는지도 확인하세요. 복사 결과를 확신할 수 없다면 잘린 부분을 추측해 보완하지 말고 원본 텍스트에서 다시 가져오세요.

여러 항목을 텍스트로 한꺼번에 가져올 때는 현재 메뉴가 여러 항목을 지원하는지 확인한 다음 구조가 명확한 내용을 사용하세요. 제목, 설명, 여러 링크가 들어 있는 메시지 전체를 복사하면 잘못 인식되거나 첫 번째 항목만 처리될 수 있습니다. 처음에는 하나만 가져와 입력란을 확인한 뒤 나머지를 처리하세요. 같은 정보를 이미 가져왔다면 다시 실행하기 전에 목록을 살펴 중복 항목이 생기지 않게 하세요. 그래야 구독 업데이트로 서버가 늘어난 것으로 오해하지 않고 테스트와 정렬도 쉽게 할 수 있습니다.

가져온 뒤 세 가지 확인하기

첫째, 항목 유형을 확인하세요. Subscribe가 서버 하나로 저장되거나 서버 하나가 일반 URL로 저장되지 않았는지 살펴봅니다. 둘째, 비밀번호, UUID, SNI, 전송 경로 등 주요 입력값을 확인하세요. 셋째, 항목이 예상한 그룹에 저장되었는지 확인해 다른 구독에 섞이지 않도록 합니다. 이 세 가지를 확인한 뒤 연결을 테스트하면 텍스트 인식과 실제 통신을 별도로 점검할 수 있어 문제가 가져오기 과정에 있는지 서버에 있는지 파악하기 쉽습니다.

스캔 후 알 수 없는 도메인이 나타나거나 매개변수가 원본 정보와 다르면 저장하지 말고 내용을 다시 확인하세요. 기존 구독 링크는 접근 권한 정보의 일부이므로 공개 그룹에 전달하거나 공개 인식 페이지에 입력하지 않는 것이 좋습니다. 문제를 확인할 때는 ‘QR 코드는 인식되지만 저장된 항목이 비어 있음’처럼 증상을 설명하면 됩니다. 전체 내용을 다른 사람에게 보여 줄 필요는 없습니다. 이미지를 공유해야 한다면 QR 코드 자체를 가리세요. 주변 문구만 가려도 코드에 담긴 링크는 숨겨지지 않습니다.

네 가지 가져오기 방법과 적합한 메뉴는 구독 가져오기 방법 안내에서 확인할 수 있습니다. 가져온 뒤 항목 수가 맞지 않으면 이 페이지 첫 번째 장으로 돌아가 구독 항목을 확인하세요. 특정 항목 하나만 실패한다면 두 번째 장에서 매개변수를 하나씩 살펴보세요. 같은 이미지를 계속 스캔해 중복 항목을 만들지 않도록 합니다.

04 / 텍스트 구조 파악하기

공유 링크 형식과 Config의 차이

프로토콜 접두사는 시작 형식만 알려 줍니다

공유 링크는 보통 프로토콜 접두사로 시작하며, 뒤에 주소, 인증 정보, 전송 매개변수, 메모가 들어갑니다. 프로토콜마다 인코딩 방식이 다르므로 접두사가 같더라도 매개변수 표현 방식은 다를 수 있습니다. 접두사를 확인하면 사용할 메뉴를 고르는 데 도움이 되지만, 앞부분만 보고 링크 전체가 올바르다고 판단할 수는 없습니다. 가져온 뒤 입력란을 다시 확인해 클라이언트가 해석한 내용이 기존 정보와 일치하는지 살펴보세요. 일부 매개변수가 무시되면 항목은 표시되더라도 예상대로 연결되지 않을 수 있습니다.

링크의 쿼리 매개변수는 전송 방식, 암호화 연결 또는 추가 설정을 나타내는 경우가 많고, 샵 기호 뒤의 부분은 보통 메모입니다. 메모의 한국어, 공백, 특수 문자는 퍼센트 인코딩되었을 수 있으며 인증 정보가 Base64로 인코딩되기도 합니다. 텍스트를 읽기 쉽게 만들려고 직접 디코딩한 뒤 다시 붙여 넣거나 이미 인코딩된 부분을 또 인코딩하지 마세요. 문자마다 위치에 따라 의미가 다를 수 있으므로 불필요하게 한 번만 바꿔도 전체 링크 구조가 달라질 수 있습니다.

구독, 공유 링크, 규칙은 서로 대체할 수 없습니다

구독 URL은 업데이트 가능한 내용을 가리키고, 서버 하나의 공유 링크는 대개 개별 서버 정보를 나타냅니다. Config는 연결 외의 동작을 정의합니다. HTTPS로 시작하는 주소를 받았다면 무조건 Subscribe로 추가하지 말고 원본 안내를 참고해 무엇을 반환하는지 확인하세요. 섹션 이름과 규칙 행이 포함된 텍스트도 서버 링크 여러 개로 가져오면 안 됩니다. 서로 함께 사용할 수 있지만 저장 위치와 업데이트 방식은 다릅니다. 잘못된 메뉴를 사용한다고 해서 내용이 다른 유형의 항목으로 자동 변환되지는 않습니다.

[General]
bypass-system = true

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

이 내용은 문법을 설명하기 위한 규칙 예시이며 서버 인증 정보는 포함하지 않습니다. DOMAIN-SUFFIX는 도메인 접미사와 일치하고, IP-CIDR은 주소 범위와 일치하며, FINAL은 앞에서 일치하지 않은 요청을 처리합니다. 규칙은 보통 위에서 아래로 확인하며 먼저 일치하는 규칙이 처리 방식을 결정합니다. 따라서 더 구체적인 규칙을 포괄적인 기본 규칙보다 앞에 두어야 합니다. 예시의 PROXY를 사용하려면 이용 가능한 프록시 선택 항목이 있어야 합니다. 이 정책 이름을 적었다고 서버가 자동으로 추가되는 것은 아닙니다.

Global Routing의 Config, Proxy, Direct는 각각 Config, Proxy, Direct에 해당합니다. Config를 사용한다면 현재 설정의 규칙을 중심으로 확인하세요. Proxy를 사용한다면 선택한 서버가 작동하는지 먼저 점검합니다. Direct를 사용하면 목록에 서버가 있어도 요청이 자동으로 해당 서버를 통과하지 않습니다. 구독을 사용할 수 있는지 테스트할 때는 현재 모드도 함께 기록하세요. 같은 목록이라도 모드에 따라 접속 결과가 완전히 달라질 수 있습니다.

공유 전에 인증 정보 노출 범위 확인하기

서버 공유 링크에는 전체 비밀번호나 UUID가 포함될 수 있고, 구독 URL은 계속해서 목록을 가져올 권한을 제공할 수 있습니다. 내용을 QR 코드로 만들거나 표시 이름을 줄이거나 인코딩해도 민감한 정보라는 점은 달라지지 않습니다. 본인 기기 간에 옮길 때는 통제된 전달 방식을 사용하고 수신 기기를 신뢰할 수 있는지 확인하세요. 도움을 요청할 때는 프로토콜 유형, 오류 안내, 민감 정보를 가린 입력값을 우선 제공하고 연결에 사용할 수 있는 전체 항목을 공개 스크린샷에 올리지 마세요.

같은 링크를 서로 다른 메뉴로 가져온 뒤 입력값이 다르면 원본 텍스트와 두 가지 해석 결과를 함께 보관해 비교하세요. 먼저 잘림, 이스케이프 처리, 인코딩 변경이 있었는지 확인한 다음 해당 매개변수가 현재 플랫폼에서 인식되는지 살펴봅니다. 누락된 입력값이 모두 링크 만료 때문이라고 단정하거나 모르는 쿼리 매개변수를 임의로 삭제하지 마세요. 저장 가능한 긴 링크를 만드는 것보다 각 변경의 이유를 설명할 수 있는 것이 중요합니다. 확실하지 않으면 원본 정보에서 형식을 다시 확인하세요.

05 / 목록 변경 관리하기

구독 업데이트 방식 및 실패 복구

업데이트를 범위가 정해진 교체 작업으로 이해하기

구독 업데이트는 클라이언트가 출처에 다시 요청하고 응답 내용을 해석해 관련 항목을 새로 고치는 과정입니다. 모든 항목을 다시 테스트하거나 Shadowrocket 앱을 업데이트하는 작업이 아닙니다. 서버 측에서 서버를 추가, 삭제, 이름 변경할 수 있으며 클라이언트는 자체 매칭 방식에 따라 기존 항목을 처리합니다. 시작 전에 어떤 정보가 구독에서 온 것인지, 어떤 정보가 직접 수정한 것인지 파악하세요. 특히 메모, 현재 선택 항목, 규칙에서 참조하는 이름을 확인해 업데이트 후 변경 사항이 정상인지 판단할 수 있도록 합니다.

처음에는 수동 업데이트를 실행해 내용이 안정적으로 가져와지는지 확인한 뒤 현재 플랫폼에서 제공하는 자동 업데이트 설정을 고려하세요. 자동 업데이트 간격을 무조건 짧게 설정할 필요는 없습니다. 요청을 자주 보낸다고 잘못된 주소가 수정되는 것은 아니며, 출처 측 요청 제한이 적용될 수도 있습니다. 자동 업데이트 메뉴가 없다면 필요할 때 수동으로 새로고침하면 됩니다. 어떤 방법을 사용하든 중요한 작업 전에 확인할 시간을 확보하세요. 연결을 유지해야 하는 동안 출처를 바꾸거나 대량 업데이트를 함께 진행하지 마세요.

업데이트 전후 네 가지 확인 사항

업데이트 전에는 출처 이름, 현재 선택한 서버, 수동 수정 여부, 현재 네트워크 상태를 기록하세요. 업데이트한 뒤에는 성공 안내가 표시되는지 확인하고, 목록에 눈에 띄는 변화가 있는지 살펴본 다음 선택 항목이 남아 있는지 확인하고 마지막으로 서버 하나의 연결을 테스트합니다. 항목 수 변화가 반드시 오류인 것은 아니지만 목록이 갑자기 비거나 이름이 대량으로 이상해지면 추가 작업을 멈추세요. 원본 출처와 기존 백업을 유지하는 편이 바로 삭제하고 다시 만드는 것보다 서버 측과 로컬 중 어디서 변화가 생겼는지 판단하기 쉽습니다.

구독 항목을 직접 수정했다면 업데이트 과정에서 변경 내용이 덮어써질 수 있습니다. 오래 유지해야 하는 수정 사항은 별도의 수동 항목으로 만들고 용도를 기록한 뒤 원본 구독을 비교용으로 남겨 두는 것이 좋습니다. 한 번 업데이트했을 때 메모가 덮어써지지 않았다고 해서 모든 입력값이 영구적으로 유지된다고 판단하지 마세요. 입력란과 플랫폼에 따라 처리 방식이 다를 수 있으므로 많은 항목을 동시에 시험하지 말고 통제된 업데이트 한 번으로 실제 결과를 확인하세요.

가져오기, 인증, 해석 단계별로 문제 확인하기

업데이트 시간 초과가 발생하면 먼저 기기의 현재 네트워크가 작동하는지 확인한 뒤 구독 요청이 이미 사용할 수 없는 프록시 경로에 의존하는지 살펴보세요. 구독을 가져오는 경로가 일반 웹페이지 접속 경로와 다를 수 있으므로 현재 플랫폼에서 제공하는 관련 설정을 확인해야 합니다. 통제된 환경에서 네트워크를 바꿔 다시 시도할 수 있지만 네트워크, 규칙, 출처 링크를 한꺼번에 변경하지 마세요. 업데이트에 성공해도 어떤 요인이 결과를 바꿨는지 알 수 없고 다음 실패를 재현하기 어려워집니다.

인증 실패나 접근 거부가 나타나면 주소 전체가 복사되었는지, 식별 매개변수가 초기화되었는지, 해당 출처가 여전히 계정에 유효한지 확인하세요. 요청이 너무 많다는 안내가 나타나면 반복 새로고침을 중단하고 적절한 시간 동안 기다린 뒤 출처의 안내에 따라 진행합니다. 로그인 페이지, 안내 페이지 또는 빈 내용이 반환되면 클라이언트에서 해석 실패로 나타날 수 있습니다. 이는 서버 목록에 있는 항목 하나의 시간 초과와는 다른 문제이므로 구독 요청을 확인해야 합니다. 개별 서버의 포트를 수정해 해결할 수 없습니다.

이전에 업데이트되던 출처를 이제 해석할 수 없다면 응답 형식이 바뀌었는지, 새로 복사한 링크가 다른 용도의 API를 가리키는지 확인하세요. 웹페이지를 로컬 파일로 저장했다고 유효한 목록이 되는 것은 아닙니다. 다른 형식의 정보를 임의로 조합하지 마세요. 오류 원문, 발생 당시 네트워크 환경, 모든 출처에서 실패하는지 여부를 기록하면 반복해서 재설치하는 것보다 문제를 파악하는 데 도움이 됩니다. 출처 하나만 실패한다면 그 출처부터 확인하세요. 모든 구독을 비울 필요는 없습니다.

업데이트 후 Config 참조 확인하기

서버 이름이 바뀌면 이름을 기준으로 항목을 찾거나 선택하는 방식에 영향을 줄 수 있습니다. 사용자 지정 정책을 사용한다면 참조 관계도 확인하세요. 항목이 표시되는데 접속이 갑자기 다른 경로로 연결된다면 목록 첫 줄만 보지 말고 현재 선택한 항목과 Config를 함께 점검합니다. 장기간 사용하는 규칙은 참조 관계를 명확하게 작성하고 복구할 수 있는 Config 사본을 보관하세요. 구독 관리와 규칙 관리를 분리하면 한 번의 업데이트가 여러 곳에 변화를 일으킬 위험을 줄일 수 있습니다.

06 / 소속 관계 명확히 유지하기

여러 구독 정리 및 로컬 수정 범위

이름에는 위치뿐 아니라 소속도 드러나야 합니다

기존 구독을 여러 개 관리할 때는 우선 출처마다 안정적이고 구분하기 쉬운 이름을 지정하세요. 개인적인 용도나 정보의 소속에 따라 정리할 수 있습니다. 제목에 전체 URL을 넣을 필요는 없으며 메모에 비밀번호나 식별 매개변수를 적지 마세요. 서버 메모는 개별 항목을 구분하는 용도로 사용하고, 원래 이름을 유지하면서 짧은 설명을 덧붙일 수 있습니다. 출처 이름과 서버 이름은 서로 다른 단계의 역할을 합니다. 이를 구분하면 실패 범위 확인, 중복 처리, 그룹 전체 삭제를 더 정확하게 할 수 있습니다.

처음 정리할 때 모든 출처를 바로 합치지 마세요. 먼저 출처별 업데이트 가능 여부, 목록의 대략적인 범위, 별도로 만든 수동 항목이 있는지 확인한 다음 표시 순서를 정합니다. 여러 출처에서 이름이 같아도 같은 서버라는 뜻은 아니며, 이름이 달라도 주소와 인증 정보가 같다는 보장은 없습니다. 중복 여부는 출처, 프로토콜, 주소, 포트, 주요 매개변수를 함께 비교해 판단하세요. 목록에 표시된 한 줄만 보고 여러 항목을 삭제하거나 이름을 통일하려고 인증 정보를 수정하지 마세요.

원격에서 관리되는 내용과 로컬에서 관리하는 내용 구분하기

구독으로 생성된 항목은 출처를 통해 업데이트하고, 수동으로 만든 항목은 명확히 알고 있는 독립 정보를 관리하는 데 적합합니다. 테스트를 위해 구독 항목을 임시로 변경해야 한다면 먼저 복사하거나 용도를 명확히 표시한 사본을 만들고 변경 이유를 기록하세요. 원본을 비교 대상으로 남기면서 다음 업데이트에 테스트 매개변수가 덮어써지는 것도 막을 수 있습니다. 테스트가 끝나면 유효하지 않은 사본을 정리하세요. 실제로 사용할 수 있는 항목과 섞이면 목록만 많아지고 관리하기 어려워집니다.

그룹, 즐겨찾기, 정렬 기능은 현재 플랫폼에서 실제로 제공하는 옵션에 따라 사용하세요. 별도의 즐겨찾기 기능이 없다면 명확한 메모와 출처 소속 정보로 기본 정리를 할 수 있습니다. 없는 관리 기능을 임의로 가정할 필요는 없습니다. 목록의 표시 순서를 정책 우선순위로 여기지도 마세요. 서버 항목을 맨 위로 옮겨도 Config가 자동으로 그 항목을 선택하는 것은 아닙니다. 실제 요청 경로는 현재 선택 항목, Global Routing, Config의 정책 간 관계에 따라 결정되므로 각각 확인해야 합니다.

중복을 정리하기 전에 차이 확인하기

주소와 포트가 같아도 프로토콜, 인증 정보, 전송 매개변수가 다를 수 있으므로 완전히 같은 항목이라고 단정할 수 없습니다. 반대로 동일한 공유 링크를 여러 번 가져오면 메모가 달라 항목이 여러 개 생길 수도 있습니다. 정리할 때는 먼저 주요 입력값을 비교하고 같은 출처에 속하는지 살펴보세요. 중복으로 확인되면 정상적으로 업데이트되고 소속이 명확한 항목을 우선 유지합니다. 수동 수정 내용이 있다면 먼저 관리 기록에 이유를 적고 어느 항목을 삭제할지 결정하세요.

출처를 일시적으로 업데이트할 수 없더라도 기존 서버가 작동한다면 바로 삭제하지 말고 현재 상태를 표시해 보관할 수 있습니다. 더 이상 사용할 출처라면 Config에서 해당 이름을 참조하는지, 현재 연결이 그 그룹에 의존하는지 먼저 확인하세요. 복구할 방법을 마련한 상태에서 정리해야 합니다. ‘일시적인 실패’, ‘중복’, ‘더 이상 필요하지 않음’을 같은 상황으로 취급하지 마세요. 한 번에 전부 선택하는 것보다 그룹별로 처리하는 편이 조금 느리더라도 변경 이유를 설명하기 쉽습니다.

기기 간 규칙을 유지하고 목록 모양을 같게 만드는 데 집착하지 않기

같은 구독이라도 플랫폼 기능, 표시 방식, 로컬 수동 항목에 따라 기기별 목록이 다르게 보일 수 있습니다. 목표는 출처가 올바르고 주요 매개변수가 일치하며 선택 방식이 명확한 상태를 만드는 것입니다. 모든 기기의 항목 수와 순서를 똑같이 맞출 필요는 없습니다. 다른 기기로 옮긴 뒤에는 원본 출처, 개별 서버 항목, Config 순으로 확인하세요. 대상 플랫폼에서 프로토콜 입력란이 다르게 보인다면 현재 화면과 원본 정보를 대조하세요. 다른 기기의 스크린샷을 유일한 양식 기준으로 삼지 마세요.

07 / 테스트 결과 이해하기

Connectivity Test, 지연 시간 및 정렬

테스트가 어느 단계까지 확인하는지 먼저 파악하기

지연 시간은 특정 시점의 테스트 결과이지 서버 전체 품질을 영구적으로 평가하는 값이 아닙니다. 테스트에 따라 포트 연결만 확인할 수도 있고 프록시를 통해 특정 대상에 접속할 수도 있습니다. 테스트 프로토콜, 대상 주소, 현재 네트워크, 동시 테스트 수가 모두 결과에 영향을 줍니다. Connectivity Test 또는 목록 테스트 기능을 사용하기 전에 현재 플랫폼에서 제공하는 테스트 방식과 설정을 확인하세요. 측정 조건이 비슷해야 결과를 비교할 수 있습니다. 서로 다른 테스트의 값을 한데 놓고 정렬하면 잘못된 결론을 내릴 수 있습니다.

포트에 연결할 수 있다고 인증에 성공하거나 웹사이트가 프록시를 통해 열리는 것은 아닙니다. 반대로 테스트 대상이 응답하지 않아도 모든 접속이 불가능하다는 뜻은 아닙니다. 테스트 결과는 있지만 웹페이지가 열리지 않는다면 인증, TLS, 전송 설정, DNS, 규칙을 확인하세요. 테스트는 실패했지만 실제 접속은 정상이라면 먼저 테스트 대상과 접속 경로를 확인합니다. 기호 하나만 보고 항목을 삭제하지 말고 테스트가 어느 단계까지 확인했는지 살펴보세요.

반복 가능한 비교 조건 만들기

작동이 확인된 항목 하나를 비교 대상으로 정하고 같은 네트워크에서 비슷한 시간대에 나머지 후보를 테스트하세요. 테스트하는 동안 다운로드나 동기화처럼 트래픽을 많이 쓰는 작업은 가급적 중지해 결과에 영향을 주지 않도록 합니다. 여러 항목을 한꺼번에 테스트하면 범위를 좁힐 수 있지만 동시 요청이 많으면 로컬 네트워크와 서버 측 부하가 커질 수 있습니다. 결과에 뚜렷한 이상이 있다면 후보 몇 개만 따로 다시 테스트하세요. 한 번 측정한 지연 시간이 낮다는 것은 당시 해당 테스트 대상의 응답이 빨랐다는 뜻일 뿐 지속적인 전송 속도가 더 높다는 의미는 아닙니다.

Wi-Fi와 모바일 네트워크를 바꾸면 연결 경로와 이름 확인 환경도 달라지므로 이전 정렬 결과가 더는 유효하지 않을 수 있습니다. 매일 고정된 ‘가장 빠른 서버’ 목록을 저장하기보다 용도가 분명한 후보 몇 개를 남겨 두고 실제 환경이 바뀔 때 다시 확인하세요. 테스트 조건을 기록할 때는 네트워크 유형, 테스트 방식, 대략적인 결과를 적으면 됩니다. 공개 기록에 전체 주소와 인증 정보를 포함하지 마세요. 한 번의 단편적인 결과보다 재현 가능한 상황이 문제 확인에 더 유용합니다.

정렬과 실제 선택은 서로 다른 작업입니다

지연 시간순 정렬은 표시 순서만 바꾸며 현재 서버가 바뀌었다고 가정해서는 안 됩니다. 정렬 후 Home으로 돌아가 현재 선택된 항목을 확인한 다음 접속을 테스트하세요. Config에서 정책 그룹이나 다른 선택 방식을 사용한다면 해당 정책이 최종적으로 어느 항목을 가리키는지도 확인해야 합니다. 목록의 첫 번째 줄, 현재 선택 항목, 특정 규칙이 사용하는 정책은 서로 다른 대상일 수 있습니다. 이를 구분하지 않으면 ‘빠른 서버를 선택했는데 왜 바뀌지 않았지?’라고 잘못 판단할 수 있습니다.

규칙에 따른 트래픽 분기를 테스트할 때는 먼저 Proxy로 선택한 서버의 기본 연결을 확인한 다음 Config로 돌아가 규칙이 어떻게 매칭되는지 살펴볼 수 있습니다. Direct는 직접 연결 환경과 프록시 환경을 구분할 때 사용하지만, 직접 연결에 성공했다고 서버가 작동한다는 뜻은 아닙니다. 모드를 바꿀 때마다 현재 상태를 확인해 테스트 후 원래 설정으로 되돌리는 것을 잊지 마세요. Global Routing 및 진단 항목에 대한 자세한 내용은 기능 안내를 참고하세요. 처음 연결에 실패했다면 가이드의 문제 해결 단계도 확인할 수 있습니다.

필요한 정보만 기록해 진단 단서 남기기

문제를 더 확인해야 한다면 모든 항목에서 발생하는지 일부 항목에서만 발생하는지, 업데이트 중인지 연결 중인지, 특정 네트워크에서만 나타나는지 기록하고 민감 정보를 가린 오류 원문을 보관하세요. ‘연결 안 됨’이라고만 적거나 문제를 증명하려고 전체 공유 링크를 공개하지 마세요. 같은 항목이 다른 기기에서는 정상이라면 설정을 모두 초기화하기보다 양쪽에 저장된 매개변수와 현재 모드를 비교하세요. 차이를 먼저 확인한 다음 항목 하나씩 수정하면 결과를 이해하기 쉽습니다.

08 / 복구 가능한 관리 절차

삭제, 백업 및 기기 간 복구

삭제 전에 대상과 영향 범위 확인하기

서버 하나를 삭제하는 것, 구독 출처 하나를 삭제하는 것, Config를 삭제하는 것은 각각 결과가 다릅니다. 서버 항목을 삭제하더라도 구독에서 관리되는 항목이라면 다음 업데이트 때 다시 나타날 수 있습니다. 출처를 삭제한 뒤 관련 항목도 함께 삭제되는지는 확인 안내를 기준으로 판단하세요. Config를 삭제하면 서버 목록이 남아 있어도 규칙 동작이 달라질 수 있습니다. 작업 전에 대상 이름과 확인 내용을 주의 깊게 읽으세요. 모든 정리 버튼을 같은 ‘삭제’로 여기지 말고, 현재 연결에 필요한 항목을 바로 삭제하지 않도록 특히 주의하세요.

출처를 잠시 사용하지 않으려는 경우 현재 플랫폼에 적절한 비활성화 또는 표시 관리 메뉴가 있는지 먼저 확인하세요. 없다면 목록을 짧게 만들려고 바로 삭제하지 말고 출처를 유지하면서 용도를 명확히 표시할 수 있습니다. 실제로 삭제해야 한다면 원본 정보와 복구 방법을 여전히 보유하고 있는지 확인하세요. 삭제한다고 인증 권한이 취소되는 것은 아닙니다. 링크가 유출되었다면 기기에서 지워도 다른 기기에서 계속 사용할 수 있으므로 기존 서비스의 관리 방법을 통해 관련 인증 정보를 재설정해야 합니다.

백업은 최소 세 단계로 준비하기

첫째는 다시 가져올 수 있는 구독 출처, 둘째는 개별 수동 입력 항목과 전체 매개변수, 셋째는 Config, 규칙 및 필요한 선택 관계입니다. 구독 URL만 저장하면 수동 항목과 규칙을 복구하지 못할 수 있고, 규칙만 내보내면 서버 비밀번호를 복구할 수 없습니다. 현재 플랫폼에서 제공하는 내보내기나 백업 기능을 사용할 때는 안내를 읽고 어떤 항목이 포함되는지 확인하세요. 내보내기가 끝나면 파일이 실제로 생성되었는지, 이름을 알아볼 수 있는지, 대상 플랫폼의 해당 메뉴에서 읽을 수 있는지 점검합니다.

백업 파일에는 비밀번호, UUID, 키 또는 구독 식별 정보가 들어 있을 수 있습니다. 접근 보호가 적절하고 직접 관리하는 위치에 보관하세요. 파일 확장자가 일반 문서처럼 보인다고 공개해도 되는 안내 파일로 취급하지 마세요. 백업을 공개 스크린샷, 업무 자료, 임시 전송 파일과 함께 보관하는 것도 피해야 합니다. 본인 기기 사이에 전달할 때는 수신 대상을 확인하고 전달 후 내용이 온전한지 살펴보세요. 더 이상 필요하지 않은 임시 사본은 삭제해 인증 정보가 오래 흩어져 남지 않도록 합니다.

출처, 항목, Config 순서로 복구하기

다른 기기로 옮길 때는 먼저 앱을 설치하고 처음 실행한 다음 백업을 가져오세요. iPhone/iPad 버전은 App Store에서 $2.99에 한 번 구매하며, Mac/Windows/Android/Linux 버전은 무료입니다. 플랫폼 선택과 설치 단계는 다운로드 가이드에서 확인할 수 있습니다. 구독을 복구하려고 설정 전체를 바로 덮어쓸 필요는 없습니다. 먼저 새 기기의 기존 데이터를 보존해야 하는지 확인해 별도의 수동 입력 항목을 덮어써 정보가 사라지지 않도록 하세요.

복구한 뒤 출처 이름부터 확인하고 하나씩 수동 업데이트를 실행해 URL이 여전히 유효한지 확인합니다. 다음으로 독립 서버 항목의 주요 매개변수를 점검하고 마지막으로 Config와 정책 선택을 살펴보세요. 오래된 백업으로 과거의 로컬 상태를 복원할 수는 있지만 원격 서비스가 이전 인증 정보를 여전히 받아들인다는 보장은 없습니다. 변경된 서버가 계속 존재한다는 보장도 없습니다. 복구 성공 여부는 ‘목록이 예전처럼 보이는지’가 아니라 출처를 업데이트할 수 있는지, 필요한 항목에 연결할 수 있는지, 규칙 동작이 현재 요구 사항에 맞는지로 판단해야 합니다.

일부만 복구해 백업 검증하기

중요한 설정을 변경하기 전에 용도를 알아볼 수 있는 이름으로 백업을 저장하고 한 번에 한 그룹만 수정하세요. 가능하다면 기존 작업에 영향을 주지 않는 방법으로 가져오기 결과를 확인하세요. 기기를 잃은 뒤 처음 복구를 시도하지 마세요. 현재 플랫폼에서 별도 검증을 쉽게 할 수 없다면 최소한 내보내기 범위, 파일을 읽을 수 있는지, 원본 정보가 빠짐없이 있는지 확인하고 이해할 수 있는 복구 순서를 기록하세요. 백업은 필요한 항목을 복원할 수 있어야 가치가 있습니다. 파일 수가 많다고 더 좋은 것은 아닙니다.

장기적인 관리는 ‘백업, 수정, 업데이트, 테스트, 기록’ 순서로 진행할 수 있습니다. 목적이 명확한 문제 하나만 처리하고 성공하면 짧게 기록을 남기며, 실패하면 마지막으로 확인된 상태로 복구하세요. 클라이언트의 일회성 구매와 회선 요금제는 별개이며 앱 구매 내역이 서버 정보 백업을 대신하지는 않습니다. 이 페이지 목차로 돌아가 현재 문제에 해당하는 장을 선택하세요. 출처 문제는 Subscribe와 업데이트, 개별 연결 문제는 입력값과 테스트, 이전과 정리는 이 장의 항목별 확인 절차를 참고하면 됩니다.

매뉴얼 처음으로 ↑ 빠른 시작 가이드 보기 →