구독 및 서버 관리

구독에 저장되는 정보

Subscribe에는 다시 요청할 수 있는 주소가 저장됩니다. 클라이언트가 해당 주소에 접속해 서버 목록을 가져오면, 인식 가능한 항목이 로컬에 표시됩니다. 목록의 각 서버에는 주소, 포트, 프로토콜, 인증 정보가 포함됩니다. 구독 주소는 이러한 항목을 한데 묶는 역할을 합니다. 둘은 서로 다른 항목입니다. 서버에 연결할 수 있어도 구독 주소가 더 이상 유효하지 않을 수 있고, 구독을 업데이트할 수 있어도 목록의 모든 서버에 지금 연결할 수 있다는 뜻은 아닙니다.

가져오기 전에 보유한 정보가 본인 소유의 구독 주소인지 확인하세요. 계정 관리 웹페이지, 단일 공유 링크 또는 규칙 파일 주소와 혼동하면 안 됩니다. 브라우저에서 웹페이지가 열린다고 해서 구독 주소로 사용할 수 있는 것은 아닙니다. 클라이언트에는 로그인 양식이나 오류 메시지, 웹페이지 레이아웃이 아니라 해석 가능한 목록이 필요합니다. 인증 정보가 포함된 주소를 공개 게시판에 붙여 넣지 말고, 본인의 기기에서 확인하세요.

순서대로 구독 추가하기

1. Home의 추가 메뉴에서 Subscribe를 찾으세요. 현재 화면에서 먼저 Add Server로 이동한다면 유형 선택 메뉴에 Subscribe가 있는지 확인하세요. 메뉴 위치는 기기에 표시되는 실제 화면을 기준으로 합니다.
2. 주소 필드에 구독 주소 전체를 붙여 넣고 앞뒤와 쿼리 매개변수가 빠짐없이 포함되었는지 확인하세요. ‘일상 사용’처럼 용도를 구분할 수 있는 이름을 지정하고, 날짜만 이름으로 사용하지 않는 것이 좋습니다.
3. 저장한 다음 처음으로 가져오기를 실행하세요. 목록이 표시되면 소속 그룹과 서버 메모를 확인하고, 같은 주소를 연달아 추가하지 마세요.
4. 사용 권한이 있는 항목 하나를 선택해 연결을 확인하세요. 첫 연결과 시스템 권한 처리 방법은 빠른 시작 가이드에서 이어서 확인할 수 있습니다.

예시는 구조를 파악하기 위한 것으로 실제 연결에는 사용할 수 없습니다. 아래 주소의 도메인, 경로, 매개변수는 모두 가상의 교육용 값입니다. 실제 주소에는 쿼리 매개변수가 없거나 다른 경로가 사용될 수 있습니다. 복사할 때는 원문을 그대로 유지하고, 예시를 보고 본인의 주소에 필드를 임의로 추가하지 마세요.

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

저장 성공이 가져오기 성공을 뜻하지는 않습니다

기록이 저장되었다는 것은 입력한 내용이 로컬에 저장되었다는 뜻일 뿐입니다. 첫 요청은 네트워크 문제, 만료된 주소, 인증 실패 또는 지원되지 않는 형식으로 인해 실패할 수 있습니다. 구독 이름만 있고 서버가 표시되지 않는다면 먼저 오류 메시지를 확인한 뒤 ‘요청 자체가 완료되지 않음’과 ‘요청은 완료됐지만 내용을 해석하지 못함’을 구분하세요. 전자는 로컬 네트워크와 주소 접근성을, 후자는 응답이 웹페이지나 빈 목록인지 또는 현재 메뉴와 맞지 않는 구성 형식인지 확인하세요.

인증 실패 메시지가 표시되면 기존 구독 관리 페이지로 돌아가 접근 권한과 전체 주소를 확인하세요. 매개변수를 무작정 삭제하거나 수정하지 마세요. 인증서 오류가 발생하면 기기 시간과 주소 철자를 확인하세요. 인증서 검증을 끄는 방법을 기본 해결책으로 사용하면 안 됩니다. 네트워크에서 웹 로그인이 필요한 경우 먼저 해당 네트워크의 정상적인 연결 절차를 완료한 다음 Subscribe를 다시 시도하세요. 공용 네트워크의 로그인 페이지를 구독 응답으로 오인하지 않도록 주의하세요.

가져온 뒤 확인할 세 가지

첫째, 서버가 예상한 구독에 속하는지 확인해 직접 입력한 항목과 혼동하지 않도록 하세요. 둘째, 항목을 열어 프로토콜과 주소가 온전한지 확인하되 인증 정보는 다른 사람에게 보이지 않도록 하세요. 셋째, 가져오기 작업으로 현재 Config가 의도치 않게 바뀌지 않았는지 확인하세요. 구독 목록은 ‘선택할 수 있는 서버’를, Config는 ‘대상에 접근할 때 처리하는 방식’을 결정합니다. 두 항목은 각각 확인해야 하며, 목록에 서버가 표시된다고 규칙 설정까지 올바르다고 판단할 수는 없습니다.

같은 주소를 여러 기기에 가져와도 로컬 메모, 현재 선택 항목, 직접 수정한 내용이 자동으로 일치하지는 않습니다. 각 기기를 별도의 관리 사본으로 보고 처음 가져온 결과와 연결 상태를 각각 확인하세요. 서버 정보가 하나뿐이라면 해당 항목을 구독으로 가공할 필요 없이 다음 장으로 이동하면 됩니다.

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

Add Server는 독립된 서버 항목을 만드는 메뉴입니다. 시작하기 전에 기존 서버의 전체 매개변수를 준비하고 Type을 선택한 다음 해당 필드를 입력하세요. 유형에 따라 인증 및 전송 옵션이 달라집니다. 주소를 먼저 입력하고 Type을 임의로 바꾸면 일부 필드가 초기화되거나 새 유형과 맞지 않는 값이 남을 수 있습니다. 정보가 부족하다면 본인의 서버 자료를 다시 확인하세요. 다른 항목의 화면 모양만 보고 추측하지 마세요.

주소 필드에는 일반적으로 호스트 이름이나 IP를 입력하며, 웹페이지 전체 주소를 넣는 것은 아닙니다. 포트는 별도의 숫자 필드이므로 경로, 쿼리 매개변수, 메모를 입력하지 마세요. 자료에 도메인이 있다면 임의로 IP로 바꾸지 말고 도메인을 그대로 사용하는 편이 좋습니다. TLS 신원 확인과 서버 라우팅이 도메인에 의존할 수 있습니다. IPv6를 사용할 때는 화면의 주소 필드와 공유 링크의 대괄호 표기를 특히 구분하세요.

인증, TLS, 전송은 각각 어떤 역할을 하나요?

Shadowsocks에는 서버와 일치하는 암호화 방식과 비밀번호가 필요합니다. 이름이 비슷한 방식을 선택해도 같은 방식으로 간주할 수 없습니다. VMess와 VLESS에서 흔히 사용하는 신원 정보는 UUID이지만, 두 유형을 서로 바꿔 쓸 수 있다는 뜻은 아닙니다. Trojan에는 일반적으로 비밀번호와 TLS 매개변수가 필요합니다. HTTP와 SOCKS5에서 사용자 이름과 비밀번호를 요구하는지는 기존 서버 설정에 따라 다릅니다. 모든 인증 정보를 Password 필드에 넣지 말고 항목별로 입력하세요.

TLS는 연결을 암호화하고 신원을 확인하며, SNI는 핸드셰이크 중 서버 이름을 전달합니다. 연결 주소, SNI, 전송 계층의 Host 값은 같을 수도 다를 수도 있으므로 실제 서버 요구 사항을 따르세요. Path는 특정 전송 방식에서 사용하는 경로이며 구독 주소의 경로가 아닙니다. 핸드셰이크 실패 시 포트만 반복해서 바꾸지 말고 이 항목들이 서로 맞는지 확인하세요. 인증서 검증 설정은 실제 인증서 요구 사항에 맞게 유지해야 합니다.

WireGuard, Hysteria2 등의 유형에는 각각 전용 매개변수가 있으므로 일반적인 사용자 이름과 비밀번호 방식으로 입력하면 안 됩니다. 현재 유형에 필요한 필드만 입력하고, 자료에서 요구하지 않는 고급 옵션은 우선 기본값으로 두세요. 자료에 분명히 표시된 항목을 화면에서 찾을 수 없다면 먼저 Type과 메뉴가 올바른지 확인한 다음 용어집에서 필드의 의미를 살펴보세요. 이름이 비슷하더라도 역할이 다른 필드에 값을 옮기지 마세요.

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

저장하기 전에 공백과 줄바꿈을 확인하세요. 비밀번호는 대소문자를 구분할 수 있고, 복사할 때 눈에 보이지 않는 문자가 함께 들어갈 수도 있습니다. UUID의 하이픈과 문자 순서는 그대로 유지하세요. 메모는 알아보기 쉬운 이름으로 바꿔도 되지만 인증 값을 임의로 ‘정리’하는 것은 적절하지 않습니다. 저장한 뒤 해당 항목을 선택해 테스트하고, 접근 권한이 있는 정상적인 HTTPS 페이지를 열어 연결 단계와 실제 요청 결과를 각각 확인하세요.

문제를 해결할 때는 한 번에 한 종류의 필드만 변경하세요. 예를 들어 주소와 포트를 먼저 수정해 다시 테스트하고, 그다음 인증, 마지막으로 TLS와 전송을 확인합니다. 여러 항목을 한꺼번에 바꾸면 정상으로 돌아와도 원인을 알 수 없어 이후 업데이트 때 같은 문제가 생길 수 있습니다. 기존 기록을 계속 사용할 수 있다면 먼저 ‘확인 중’ 메모가 있는 별도 사본을 만들어 테스트한 다음 어느 항목을 남길지 결정하세요. 사용 중인 매개변수를 바로 덮어쓰지 마세요.

직접 입력은 개별 서버 매개변수를 설정하는 방법이며 규칙 기반 트래픽 분할을 자동으로 구성하지 않습니다. 항목이 정상적으로 작동해도 Global Routing과 현재 Config를 확인해야 합니다. 일부 웹사이트에서만 문제가 발생한다면 규칙과 DNS 문제를 점검하고, 이미 유효성이 확인된 인증 정보를 계속 수정하지 마세요.

QR 코드는 내용을 담는 수단입니다

QR 코드에는 단일 공유 링크나 구독 주소가 담길 수도 있고 일반 웹페이지 주소만 담길 수도 있습니다. Scan QR Code로 코드를 인식했다고 해서 반드시 서버 정보가 들어 있는 것은 아닙니다. 스캔하기 전에 QR 코드가 본인의 서버 또는 구독 관리 환경에서 제공되었는지 확인하고, 출처를 모르는 내용을 바로 저장하지 마세요. 인식 결과가 웹페이지 주소라면 스캔할 수 있다는 이유만으로 올바른 구독 주소라고 판단하지 말고 실제 구독 메뉴에 맞는지 확인하세요.

다른 화면에 QR 코드를 표시할 때는 코드가 잘리지 않도록 선명하게 띄우고 가장자리에 여백을 두세요. 화면 반사나 모서리 잘림에 주의하세요. 카메라가 너무 가까우면 가장자리가 한 번에 잡히지 않고, 너무 멀면 작은 점이 흐려질 수 있습니다. 먼저 거리와 밝기를 조정한 다음 다시 인식해 보세요. QR 코드를 공개 채널에 올려 다른 사람에게 스캔을 부탁하지 마세요. 그 안의 인증 정보는 평문 공유 링크와 같은 접근 권한을 줄 수 있습니다.

카메라 권한 및 이미지 인식

Scan QR Code를 사용할 때 시스템에서 카메라 권한을 요청하면 허용해야 실시간 스캔을 할 수 있습니다. 이전에 권한을 거부했다면 시스템 설정에서 Shadowrocket의 카메라 권한을 찾아 변경하세요. 현재 스캔 화면에 이미지 인식 메뉴가 있다면 직접 저장한 원본 이미지를 선택할 수 있습니다. 해당 메뉴가 없다면 다른 플랫폼 화면에 나온 버튼을 찾으려 하지 말고 원문을 직접 가져오세요.

QR 코드를 스캔한 뒤에는 저장하기 전에 클라이언트가 인식한 유형, 이름, 주소를 확인하세요. 결과가 서버 하나뿐이고 구독 전체를 예상했다면 QR 코드에 단일 링크가 들어 있을 수 있습니다. 반대로 구독 QR 코드라도 저장하고 처음 가져오기를 완료해야 서버 목록이 표시될 수 있습니다. 이때는 반복해서 스캔해 중복 항목을 만들지 말고 대상 유형을 확인하세요.

클립보드에서 가져오는 전체 과정

1. 본인의 자료에서 원문 전체를 복사하세요. ‘링크 복사’처럼 원본 내용을 가져오는 방법을 사용하고, 설명 문장이나 목록 기호, 따옴표가 함께 복사되지 않도록 하세요.
2. Shadowrocket으로 돌아와 화면에 제공되는 클립보드 가져오기를 사용하세요. 시스템에서 붙여넣기를 허용할지 묻는 경우 가져올 준비가 되었을 때만 승인하세요.
3. 인식 결과를 확인하세요. 단일 공유 링크는 독립 서버로, 구독 주소는 구독 항목으로 인식되어야 합니다. 인식할 수 없다면 원문을 보존하고 무작정 반복해서 저장하지 마세요.
4. 저장한 뒤 항목이 속한 위치를 확인한 다음 연결을 테스트하거나 구독을 가져오세요. 작업이 끝나면 민감한 정보가 없는 일반 텍스트를 복사해 클립보드 내용을 덮어쓸 수 있습니다.

클립보드가 비어 있거나 붙여넣기 권한이 거부되었거나 복사한 내용에 서식이 함께 포함된 경우 가져오기에 실패할 수 있습니다. 기기의 비공개 텍스트 편집 환경에서 첫 부분의 프로토콜과 끝부분이 온전한지 확인하고, 불필요한 설명이나 전각 문장 부호, 중간에 끊긴 줄바꿈이 없는지 살펴보세요. 실제 비밀번호를 웹 검색창이나 공개 온라인 분석 페이지에 붙여 넣지 마세요.

여러 항목과 중복 항목 처리하기

공유 링크가 여러 개라면 보통 한 줄에 하나씩 입력합니다. 한 번에 여러 개를 가져올 수 있는지는 현재 메뉴의 인식 결과를 기준으로 하세요. 먼저 하나로 절차를 확인한 뒤 나머지를 처리하면 문제 범위를 좁힐 수 있습니다. 전체 텍스트가 이상한 이름 하나로 인식되거나 일부 항목만 나타났다면 저장 성공을 일괄 가져오기 완료로 간주하지 마세요. 원문으로 돌아가 구분 방식을 확인하고 결과를 항목별로 점검하세요.

같은 서버를 QR 코드와 클립보드로 각각 가져오면 자동으로 합쳐지지 않고 로컬 항목 두 개가 생기는 경우가 많습니다. 이름이 같아도 매개변수가 같다고 단정할 수 없습니다. 한쪽의 포트나 전송 필드가 업데이트되었을 수 있습니다. 정리하기 전에 Type, 주소, 포트, 출처를 비교하고 현재 유효성이 확인된 항목을 남기세요. 인증 필드는 본인의 기기에서만 확인하고, 비교를 위해 전체 정보를 채팅 기록으로 보내지 마세요.

인식은 성공했지만 연결에 실패했다면 2장에서 매개변수를 확인하세요. 구독은 저장되었지만 서버가 표시되지 않는다면 1장으로 돌아가 첫 가져오기를 확인하세요. ‘인식, 저장, 가져오기, 연결’을 네 단계로 나누면 가져오기 방식을 계속 바꾸는 것보다 문제를 쉽게 찾을 수 있습니다. 권한 문제는 FAQ의 설치 및 첫 실행 항목에서 더 확인할 수 있습니다.

단일 공유 링크는 자동 업데이트 주소가 아닙니다

단일 공유 링크에는 일반적으로 서버 한 대의 정보가 담기며, 프로토콜 유형, 인증 정보, 주소, 포트, 선택적 전송 매개변수가 포함됩니다. 가져오면 특정 시점의 매개변수 사본이 만들어집니다. 나중에 서버 비밀번호나 포트가 바뀌어도 공유 링크에서 가져왔다는 이유만으로 자동 동기화되지는 않습니다. 구독 주소는 일반적으로 다시 가져올 수 있는 목록을 가리키며, 업데이트는 해당 목록과 그에 속한 항목에 적용됩니다. 두 형식의 수명 주기는 서로 다릅니다.

일반적인 접두어로는 ss://, vmess://, vless://, trojan://가 있습니다. 접두어는 뒤에 오는 내용을 어떤 방식으로 해석할지 알려주는 것이며 임의로 바꿀 수 있는 태그가 아닙니다. 다른 프로토콜의 접두어로 바꿔도 인증 방식, 데이터 구조, 전송 의미가 서로 다를 수 있으므로 변환되지 않습니다. 지원하지 않는 구조라면 원래 내보내기 형식을 확인하세요.

인코딩, 쿼리 매개변수 및 메모

일부 형식은 인증 정보나 전체 구조를 인코딩해 링크에 넣습니다. 인코딩은 표현 방식만 바꾸는 것으로 암호화 보호를 뜻하지 않으며 공개해도 된다는 의미도 아닙니다. 복잡해 보이는 문자열을 해독하면 비밀번호, UUID, 서버 주소가 드러날 수 있습니다. 링크를 ‘깔끔하게’ 만들기 위해 등호, 하이픈, 밑줄을 직접 제거하지 마세요. 해당 문자는 인코딩 형식의 일부일 수 있습니다.

쿼리 매개변수는 일반적으로 물음표로 시작해 앰퍼샌드로 구분되며 전송 유형, TLS, Host, Path 등의 정보가 포함될 수 있습니다. 링크 끝의 해시 기호 뒤에는 흔히 메모가 붙습니다. 메모의 한글, 공백, 특수 문자는 퍼센트 인코딩되어 있을 수 있습니다. 클라이언트가 해석하도록 두고 이미 디코딩된 텍스트를 다시 인코딩하지 마세요. 메모를 바꾸는 것은 보통 연결에 영향을 주지 않지만, 해시 기호 앞의 매개변수를 잘못 삭제하면 실제 연결 방식이 달라질 수 있습니다.

웹페이지 코드나 이메일에서 복사할 때 원래의 앰퍼샌드가 HTML 엔티티로 바뀌거나 반각 문자가 편집 과정에서 치환될 수 있습니다. 이 경우 링크는 얼핏 맞아 보여도 해석 결과에서 필드가 누락될 수 있습니다. 문자를 하나씩 추측해 복구하기보다 원문을 다시 확보하세요. 긴 링크가 화면에서 줄바꿈되어 보여도 원문에 줄바꿈이 있다는 뜻은 아닐 수 있으므로 실제 문자를 로컬에서 확인하세요.

인코딩된 문자열을 직접 수정하지 말고 해석 결과로 확인하세요

이름이 표시되는지만 확인하는 것보다 가져온 뒤 Type, 주소, 포트, 인증, 전송 필드를 하나씩 점검하는 편이 확실합니다. 형식에 따라 선택적 매개변수 지원이 다를 수 있습니다. 접두어를 인식해도 현재 메뉴에서 일부 필드를 적용하지 못할 수 있습니다. 자료에 명시된 항목이 해석 결과에서 빠졌다면 2장을 참고해 별도 항목에서 보완하고 원본 자료를 남겨 되돌릴 수 있도록 하세요.

아래는 읽기 쉬운 구조 예시일 뿐이며 도메인과 비밀번호는 가상의 값이므로 연결할 수 없습니다. 인증 정보, 호스트, 포트, 쿼리 매개변수, 메모의 상대적인 위치를 보여줍니다. 모든 프로토콜이 같은 배치를 사용하거나 모든 고급 옵션을 이 위치에 입력할 수 있다는 뜻은 아닙니다.

trojan://[email protected]:443?security=tls&sni=example.com#Manual-Example

HTTPS 주소가 서버 목록이 아닌 전체 구성을 반환한다면 해당 내용에 맞는 구성 가져오기 메뉴를 사용하세요. Subscribe에 억지로 넣고 자동으로 호환되기를 기대하지 마세요. 전체 구성에는 규칙, DNS, 서버 정의가 함께 포함되어 바뀔 수 있으므로 단일 공유 링크보다 영향 범위가 큽니다. 가져오기 전에 현재 구성을 백업하고 내용을 확인하세요. 덮어쓴 뒤 원본 파일을 찾으려 하지 마세요.

필드 배치를 더 알아보려면 공유 링크 형식과 구독 링크의 차이를 확인하세요. 어떤 형식을 사용하든 원본 링크는 민감한 자료로 취급해야 합니다. 외부에 문제를 설명할 때는 프로토콜과 오류 단계만 알리고 인증 정보, 전체 주소 매개변수, 해당 정보를 복원할 수 있는 QR 코드는 공개하지 마세요.

업데이트로 바뀔 수 있는 항목

구독을 업데이트하면 원격 콘텐츠를 다시 요청하고 응답에 따라 로컬의 구독 서버 항목이 조정됩니다. 이름, 주소, 포트, 인증 정보, 목록 구성원이 바뀔 수 있으므로 업데이트는 단순히 ‘화면 새로고침’하는 작업이 아닙니다. 업데이트 전에 현재 사용하는 서버 이름과 용도를 기록할 수 있으며, 로컬 수정 내용에 의존한다면 먼저 백업하세요. 원격 목록에서 항목이 삭제되면 업데이트 중 해당 항목이 사라질 수 있습니다. 예전 항목이 아직 보인다고 해서 계속 유지된다고 보장할 수는 없습니다.

이미 연결된 상태와 다음에 새로 연결할 때의 상태도 구분해야 합니다. 목록 업데이트가 완료되어도 기존 연결이 모두 즉시 새 매개변수를 사용하는 것은 아닙니다. 필요하면 저장을 확인한 뒤 다시 연결하고 실제 접속을 테스트하세요. 중요한 업로드, 회의, 원격 작업 중에는 연결이 재수립되면서 진행 중인 작업에 영향을 줄 수 있으므로 업데이트와 전환을 반복하지 마세요. 잠시 끊겨도 괜찮은 시간에 진행하세요.

수동 업데이트와 자동 업데이트의 선택

변경 사항을 살펴보고 하나씩 확인해야 한다면 수동 업데이트가 적합합니다. 먼저 백업하고 한 번 가져온 다음 목록 차이를 확인하고 현재 용도로 테스트하세요. 화면에서 자동 업데이트와 주기를 설정할 수 있다면 실제 사용 빈도에 맞춰 활성화하되, 짧은 주기가 안정성을 보장한다고 생각하지 마세요. 잦은 업데이트는 요청 횟수를 늘리고 원격 측의 요청 제한을 유발할 수 있습니다. 백그라운드 실행도 시스템 예약과 네트워크 상태의 영향을 받습니다.

자동 업데이트를 켜더라도 가끔 결과를 직접 확인해야 합니다. 기기가 오랫동안 오프라인 상태이거나 시스템에서 백그라운드 활동을 제한하거나 구독 접근 권한이 바뀌면 업데이트가 오래된 상태로 남을 수 있습니다. 자동 업데이트 스위치만 보지 말고 요청이 명확히 완료되었는지와 실제 목록 내용을 확인하세요. 플랫폼마다 예약 실행 방식이 다를 수 있으므로 여러 기기가 같은 시점에 완전히 같은 목록을 가져온다고 가정하지 마세요.

오류 단계에 맞춰 해결 방법 선택하기

요청 시간이 초과되면 로컬 네트워크, 도메인 확인, 대상 주소에 접근할 수 있는지 먼저 점검하세요. 인증 실패라면 본인의 접근 권한과 원본 링크를 확인하세요. 해석에 실패했다면 응답이 웹페이지나 안내 메시지, 다른 형식으로 바뀌지 않았는지 확인하세요. 목록 업데이트는 성공했지만 서버 연결이 실패했다면 현재 선택 항목과 프로토콜 매개변수를 살펴보세요. 구독 주소에 요청을 계속 반복해서 보내지 마세요. 오류가 발생한 단계에 따라 다음 조치가 달라집니다.

현재 네트워크에서 업데이트 주소에 접속할 수 없다면 본인이 사용할 권한이 있는 다른 네트워크에서 기기 결과를 비교해 로컬 네트워크 문제인지 원격 문제인지 확인하세요. 기존에 사용 가능한 연결이 있더라도 이번 요청이 실제로 어떤 네트워크 경로를 이용하는지 확인해야 합니다. 라우팅, DNS, 구독 주소를 동시에 바꾸지 마세요. 여러 차례 실패한 뒤에는 재시도를 멈추고 오류 문구와 발생 조건을 기록해 필요한 부분만 확인하세요.

구독 업데이트는 Config 업데이트와 다릅니다

서버 구독과 규칙 구성에는 각각 별도의 업데이트 메뉴가 있을 수 있습니다. 서버에 연결할 수 있지만 일부 대상에 접근할 수 없다면 모든 문제를 서버 탓으로 돌리지 말고 Global Routing과 Config를 확인하세요. 아래는 규칙 순서를 이해하기 위한 조각입니다. 먼저 지정한 도메인과 일치시키고, 다음으로 지정한 지역 IP를 확인한 뒤 마지막으로 기본 처리를 적용합니다. 완전한 구성 파일이 아니므로 기존 파일을 그대로 대체하지 마세요.

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
GEOIP,CN,DIRECT
FINAL,PROXY

규칙은 위에서 아래 순서로 적용되며 먼저 일치하는 규칙이 처리 방식을 결정합니다. 앞의 어떤 규칙에도 일치하지 않는 경우 FINAL이 사용됩니다. 예시의 PROXY는 해당 프록시 처리를 의미합니다. 실제로 사용하기 전에 구성의 정책과 서버 선택이 어떻게 연결되는지 확인하세요. DNS 결과, 규칙 순서, 현재 모드가 최종 경로에 영향을 줍니다. 목록에 항목이 있다고 해서 모든 요청이 해당 항목을 통과하는 것은 아닙니다.

업데이트로 서버와 구성이 함께 바뀌었다면 두 단계로 나눠 확인하는 편이 좋습니다. 먼저 서버 연결을 확인하고 그다음 규칙 작동을 점검하세요. 변경한 항목을 기록하되 인증 정보는 문제 해결 메모에 적지 마세요. 스위치를 켠 뒤 인터넷에 연결할 수 없다면 서버, Global Routing, DNS 및 규칙 단계별 점검을 이어서 확인하고 한 번에 변수 하나만 바꾸세요.

알아보기 쉬운 이름 규칙 만들기

여러 기존 구독을 함께 관리한다면 먼저 ‘구독 이름’과 ‘서버 이름’을 구분하세요. 구독 이름은 업데이트 주소를 추적하는 데 쓰이고, 서버 이름은 구체적인 연결 항목을 선택하는 데 쓰입니다. 구독 이름에는 ‘일상 사용’, ‘테스트 환경’처럼 본인이 용도를 알아볼 수 있는 이름을 사용하세요. 서버 메모에는 용도와 출처를 덧붙일 수 있습니다. ‘새 항목’, ‘예비’처럼 맥락이 부족한 이름만 쓰면 시간이 지난 뒤 어떤 항목을 남겨야 할지 판단하기 어렵습니다.

이름에 비밀번호, 전체 구독 토큰, 기타 인증 정보를 넣지 마세요. 목록이 본인 기기에만 표시되더라도 화면 캡처, 화면 공유, 백업 파일 이름을 통해 노출될 수 있습니다. 원격에서 자동 생성된 서버 이름은 다음 업데이트 때 원래대로 돌아올 수 있다고 예상해야 합니다. 메모를 계속 유지해야 한다면 현재 화면에서 로컬 이름 변경을 어떻게 보존하는지 확인하세요. 한 번 저장됐다고 이후에도 계속 유지된다고 단정하지 마세요.

먼저 출처를 구분한 다음 중복을 정리하세요

이름이 같은 항목도 다른 구독에 속할 수 있고 프로토콜, 포트, 전송 설정이 다를 수 있습니다. 주소가 같다고 완전히 중복된 것은 아닙니다. 중복을 정리하기 전에 최소한 소속 구독, Type, 주소, 포트를 확인하고 인증 및 전송 설정도 로컬에서 비교하세요. 이름만 보고 목록의 절반을 삭제하지 마세요. 확신이 서지 않는 항목은 우선 메모를 남기고 사용을 중단한 뒤 검증을 마치고 정리할 수 있습니다.

같은 주소를 구독 두 개로 중복 추가했다면 서로 다른 시점에 업데이트되어 내용이 달라 보일 수 있습니다. 남길 구독을 먼저 선택해 업데이트가 완료된 것을 확인하고 현재 사용하는 서버 항목을 테스트하세요. 필요한 내용이 모두 있는지 확인한 뒤에 다른 구독을 삭제할지 결정하세요. 삭제 전에는 현재 서버와 구성이 해당 구독을 참조하는지도 확인해 아직 사용 중인 그룹을 단순 중복으로 처리하지 않도록 하세요.

서버, 정책, 모드는 별도로 관리하세요

목록을 정리해도 모든 트래픽 처리 방식이 자동으로 바뀌지는 않습니다. Global Routing의 Config, Proxy, Direct는 각각 구성에 따른 처리, 프록시 사용, 직접 연결이라는 기본 처리 방식을 뜻합니다. 화면에 Scene이 있다면 실제 사용 장면에 맞춰 설정을 이해하세요. 서버 선택과 모드 선택은 별개의 작업입니다. 서버를 선택했더라도 모드가 Direct라면 해당 접속이 프록시를 통과한다고 판단할 수 없습니다.

구성에서 서버나 정책을 이름으로 참조하는 경우 이름 변경이나 삭제가 참조 관계에 영향을 줄 수 있습니다. 정리하기 전에 현재 구성에 이런 의존성이 있는지 확인하고, 정리 후에는 정책 선택과 규칙 적용 결과를 점검하세요. 이름을 바꾸고 목록이 깔끔해졌다고 끝내지 말고 일상적인 용도와 같은 실제 접속을 한 번 이상 테스트해 요청이 예상한 방식으로 처리되는지 확인하세요.

되돌릴 수 있도록 작은 단위로 나눠 정리하세요

한 번에 구독 하나만 처리하세요. 현재 상태를 백업하고 중복 항목을 확인한 뒤 이름을 정리하고 업데이트와 테스트를 마친 다음 다음 그룹으로 넘어갑니다. 이렇게 하면 문제가 생겼을 때 최근 변경 작업과 연관 지을 수 있습니다. ‘전체 업데이트, 전체 이름 변경, 이전 항목 삭제, Config 교체’를 한꺼번에 수행하면 문제가 서로 얽힙니다. 백업이 있어도 어느 부분을 복원해야 하는지 판단하기 어렵습니다.

여러 기기도 기기별로 확인하세요. 휴대폰에서 항목을 삭제해도 컴퓨터의 독립 사본에서 자동으로 사라진다고 생각하면 안 됩니다. 구독 사용을 중단했다면 해당 구독을 저장한 각 기기에서 따로 확인하세요. 반대로 서버 측에서 접근 권한을 취소해도 로컬 기록이 자동으로 사라지는 것은 아닙니다. 사용할 수 없는 항목이 목록에 남아 있을 수 있으므로 직접 정리해야 합니다.

인증 정보가 없는 관리 메모를 남기는 것이 좋습니다. 구독 용도, 로컬 독립 항목, 의존하는 Config, 마지막 확인 결과만 기록하세요. 실제 자격 증명은 보호된 백업에 보관하고 공개 문제 해결 안내에 함께 넣지 마세요. 삭제와 내보내기의 구체적인 범위는 8장에서, 테스트 및 정렬 방법은 다음 장에서 확인하세요.

Connectivity Test로 알 수 있는 내용

Connectivity Test는 특정 조건에서 연결 상태를 확인합니다. 테스트 방식에 따라 연결 설정 단계만 확인할 수도 있고 프록시를 통해 요청을 보내는 과정까지 포함할 수도 있습니다. 테스트 전에 Settings에서 실제로 선택된 방식과 대상을 확인하세요. 시간이 짧게 나왔다고 처리량이 더 크거나 장시간 연결이 안정적이라는 뜻은 아닙니다. 한 번의 시간 초과만으로 서버가 영구적으로 작동하지 않는다고 판단할 수도 없습니다. 결과는 테스트 조건과 함께 해석하세요.

측정 결과에는 로컬 Wi-Fi, 모바일 네트워크, DNS, 기기 부하, 서버 상태, 테스트 대상의 응답이 함께 영향을 줍니다. 네트워크를 바꾸면 기존 정렬이 더 이상 적절하지 않을 수 있습니다. 서로 다른 네트워크, 시간, 테스트 방식에서 나온 값을 섞어 비교하지 마세요. 실제 사용과 거리가 있는 테스트 대상을 기준으로 모든 접속 경험을 추정하지도 마세요.

비교 가능한 테스트 절차 만들기

1. 기기 자체가 정상적으로 인터넷에 연결되는지 확인하고 대역폭을 많이 사용하는 작업을 잠시 멈추세요. 같은 네트워크와 비슷한 테스트 조건을 유지합니다.
2. Settings에서 현재 테스트 방식과 대상을 확인하고 비교할 항목마다 같은 설정을 사용하세요.
3. 테스트를 한 번 실행한 뒤 이번 테스트가 끝날 때까지 기다리고 실패 항목을 확인하세요. 완료되기 전에 연속해서 여러 차례 실행하지 마세요.
4. 후보 항목을 몇 차례만 다시 테스트한 다음 하나를 선택해 실제로 접속하세요. 인증, TLS, 대상 응답 오류가 나타나는지도 기록하세요.

목록이 길면 전체 테스트는 많은 연결 요청을 발생시키고 짧은 시간 동안의 경쟁 상태가 결과에 영향을 줄 수 있습니다. 현재 용도와 관련 있는 항목부터 골라 범위를 좁히세요. 모든 항목에서 동시에 실패한다면 개별 매개변수보다 로컬 네트워크와 테스트 대상처럼 공통 조건을 먼저 확인하세요. 한 항목만 계속 실패한다면 해당 항목의 매개변수를 점검하세요. 공통 원인을 먼저 찾는 것이 각 항목의 비밀번호를 바꾸는 것보다 효과적입니다.

정렬과 자동 선택은 서로 다른 기능입니다

지연 시간순 정렬은 일반적으로 목록 표시 순서만 바꿉니다. 현재 서버가 자동으로 교체되거나 정렬 후 첫 번째 항목이 실제 사용 중인 항목이 된다고 가정하지 마세요. 정렬 후 선택 표시를 확인하고 Global Routing과 Config의 정책 선택도 점검하세요. 구성 자체에 선택 로직이 있다면 목록 순서와 실제 사용 항목이 다를 수 있습니다.

이름 정렬은 고정 항목을 찾을 때, 출처별 그룹은 업데이트 관리에, 지연 시간 정렬은 같은 테스트 조건에서 후보를 비교할 때 유용합니다. 각각 목적이 다르므로 한 가지 순서로 모든 문제를 해결하려 하지 않아도 됩니다. 현재 클라이언트 화면에 특정 정렬 메뉴가 없다면 모든 서버 이름을 바꿔 흉내 낼 필요는 없습니다. 겉으로 보이는 순서보다 출처를 추적할 수 있는 이름을 유지하는 편이 중요합니다.

지연 시간은 낮지만 접속에 실패할 때

기본 테스트는 성공했는데 웹페이지가 열리지 않는다면 단계별로 확인하세요. 실제 요청이 선택한 서버를 통과하는지 먼저 확인한 뒤 Global Routing, 규칙, DNS를 살펴보고 마지막으로 대상 사이트의 응답을 확인하세요. 포트 연결이 성립했다는 것은 연결 단계 중 일부가 완료되었다는 뜻일 뿐입니다. 대상 서비스가 요청을 거부하거나 이후 단계에서 TLS가 실패할 수 있습니다. 모든 오류를 ‘지연 시간이 충분히 낮지 않다’고 결론 내리지 마세요.

일부 도메인만 실패한다면 REJECT, DIRECT 또는 적절하지 않은 정책이 적용되었는지 확인하세요. 모든 도메인에서 DNS 오류가 발생한다면 DNS와 기본 네트워크 연결을 먼저 살펴보세요. 업데이트 후 한 항목만 문제가 생겼다면 2장으로 돌아가 인증과 전송을 확인하세요. 목록 옆의 숫자보다 로그에 표시된 오류 단계가 진단에 더 도움이 됩니다. 다른 사람에게 설명할 때는 필요한 오류 문구만 남기고 주소와 자격 증명은 숨기세요.

실제 접속을 확인한 뒤 일상적으로 사용할 항목을 결정하고, 전환 시 진행 중인 연결을 다시 설정해야 할 수 있다는 점에 유의하세요. 문제가 계속되면 스위치를 켰는데 인터넷에 연결할 수 없을 때 점검 순서에 따라 확인하세요. 시스템 권한 문제는 VPN 구성 추가 안내를 참고하세요. 테스트의 목적은 사용 조건과 무관한 최저값을 찾는 것이 아니라 문제 범위를 좁히는 것입니다.

삭제 전에 항목의 범위를 구분하세요

서버 하나 삭제, 구독 전체 삭제, Config 삭제, 시스템 VPN 구성 제거는 서로 다른 범위의 작업입니다. 서버 항목 하나가 사라져도 구독 주소가 삭제되는 것은 아니며 이후 업데이트로 다시 나타날 수 있습니다. 구독을 삭제하면 해당 목록 전체가 제거될 수 있습니다. 작업 전에 확인 창을 읽고 이름과 대상 범위를 확인하세요. 목록에서 보이는 위치만 보고 삭제할 항목을 판단하지 마세요.

현재 사용 중인 항목과 구성 참조를 먼저 확인하세요. 삭제하려는 항목이 현재 서버라면 유효성이 확인된 다른 항목으로 전환하거나 연결이 잠시 끊겨도 괜찮은 시간에 작업하세요. 구성에서 이름으로 참조하는 항목을 삭제하면 원래 의도한 방식으로 트래픽을 처리하지 못할 수 있습니다. 삭제 후에는 목록이 깔끔해졌는지만 보지 말고 현재 선택, 정책, 실제 접속이 예상대로 유지되는지도 확인하세요.

백업은 규칙 파일 하나를 저장하는 것만으로 충분하지 않습니다

Config 내보내기에 구독 주소, 독립 서버, 인증 정보, 로컬 설정이 모두 포함되는 것은 아닙니다. 목록 화면을 캡처해도 연결 매개변수를 복구할 수 없습니다. 백업하기 전에 현재 내보내기 기능 설명을 읽고 실제 범위를 확인하세요. 복구에 필요한 자료를 기존 구독 주소, 직접 입력하거나 별도로 가져온 서버, 규칙 및 DNS 구성, 로컬 관리 설정의 네 가지로 나눌 수 있습니다. 각 항목을 어디서 복구할지 알아 두세요.

현재 화면에 Data 또는 다른 데이터 내보내기 메뉴가 있다면 실제 옵션에서 포함 항목을 확인하세요. 단일 공유 링크만 제공된다면 해당 서버 항목의 내보내기로 이해하고 기기 전체 백업으로 취급하지 마세요. 플랫폼이나 데이터 형식이 다르면 완전히 호환된다고 가정할 수 없습니다. 정리하기 전에 내보낸 파일이 예정된 메뉴에서 인식되는지, 필요한 항목이 포함되어 있는지 확인하세요.

민감한 백업의 저장과 복구

구독 주소, 공유 링크, 데이터 파일에는 접근 자격 증명이 포함될 수 있습니다. 접근 보호가 적용되고 본인이 관리하는 위치에 보관하세요. 파일 이름에는 용도와 기기를 적고 토큰이나 비밀번호를 직접 넣지 마세요. 개인 저장소를 통해 파일을 전송한 뒤에도 이전 사본과 공유 권한을 확인하세요. 다른 사람에게 문제 해결을 요청할 때는 일부를 가린 구조 정보만 제공하고 전체 백업을 일반 첨부 파일처럼 보내지 마세요.

복구는 범위를 최소화하는 순서로 진행하는 것이 좋습니다. 먼저 구독을 복구하거나 다시 추가해 가져오기를 완료하세요. 다음으로 독립 서버를 복구하고 테스트한 뒤 필요한 Config를 가져오세요. 마지막으로 Global Routing, 로컬 선택 항목, 시스템 권한을 확인하세요. 각 단계의 결과를 확인한 뒤 다음 단계로 넘어가세요. 이전 파일을 한꺼번에 모두 가져오면 중복 항목이 생기거나 오래된 구성이 새 설정을 덮어써 문제 해결이 어려워질 수 있습니다.

기기를 바꾸면 시스템 VPN 권한을 다시 확인해야 할 수 있으며 이전 기기의 권한이 자동으로 이전된다고 볼 수는 없습니다. VPN 구성 추가 안내가 나타나면 시스템 화면에 따라 권한을 허용하세요. 거부한 뒤 연결이 필요해지면 클라이언트에서 다시 요청을 표시한 다음 시스템 설정을 확인하세요. 서버 데이터 복구와 시스템 권한 복구는 별개의 절차입니다. 권한 문제를 해결하려고 구독을 반복해서 가져오지 마세요.

실수로 삭제했거나 사용할 수 없거나 접근 권한이 취소된 경우

구독을 실수로 삭제했더라도 유효한 주소를 보유하고 있다면 다시 추가해 현재 원격 목록을 가져올 수 있습니다. 하지만 이전 로컬 메모나 원격에서 이미 삭제된 항목까지 복구된다는 보장은 없습니다. 직접 입력한 독립 항목은 원본 자료나 내보낸 사본이 없다면 구독 업데이트로 다시 찾을 수 없습니다. 먼저 본인의 백업 범위를 확인하고 복구 방법을 선택하세요. 앱 데이터 초기화를 일반적인 문제 해결의 첫 단계로 사용하지 마세요.

로컬 항목을 삭제해도 해당 기기의 데이터만 바뀌며 서버 접근 권한이 취소되는 것은 아닙니다. 구독 주소, 비밀번호, QR 코드가 노출되었다고 의심되면 권한이 있는 서비스 관리 화면에서 해당 자격 증명을 갱신하거나 취소한 다음 각 기기에서 다시 가져오세요. 목록에서 이전 항목을 삭제하는 것만으로 자격 증명을 보유한 다른 사본의 접속 시도를 막을 수는 없습니다.

이 페이지의 작업을 마쳤다면 빠른 시작 가이드로 돌아가 연결 흐름을 확인하거나 FAQ에서 증상별 안내를 찾아보세요. 규칙과 화면 필드의 의미는 용어집에서 확인하고, 앱 다운로드와 시스템 설치 안내는 앱 다운로드 페이지를 참고하세요. 서버 정보, 규칙 구성, 시스템 권한을 각각 관리하면 이후 업데이트와 기기 변경 시 확인 순서가 명확해집니다.