Shadowrocket
구독 및 서버 관리

구독, 서버, Config 구분하기

구독 주소를 사용하면 서버 정보 목록을 가져올 수 있으며, 클라이언트는 나중에 같은 주소에 다시 요청해 추가·삭제된 항목이나 변경된 매개변수를 반영할 수 있습니다. 개별 서버 정보는 하나의 연결 지점을 나타내며, 일반적으로 프로토콜, 주소, 포트, 인증 정보가 포함됩니다. Config는 설정과 규칙 등을 관리합니다. 세 항목이 같은 서비스 안내에 함께 나올 수 있지만 역할은 서로 다릅니다. 서버 구독 입력란에 Config 주소를 넣어도 사용 가능한 목록을 가져오지 못할 수 있습니다.

시작하기 전에 가지고 있는 정보가 완전한 구독 링크인지 확인하세요. 계정 페이지 주소, 소개 페이지 주소 또는 단일 서버 공유 링크와 혼동하지 않도록 합니다. 구독 링크는 서비스 제공업체에서 받고, 해당 업체가 안내하는 Shadowrocket 형식에 맞춰 사용하세요. 흔한 파일 확장자로 끝나는지만 보고 링크 유형을 판단하지 마세요. 일부 구독은 동적 주소로 응답하므로 실제 해석 결과는 응답 내용에 따라 달라집니다.

Add Server에서 Subscribe 선택하기

Home으로 이동해 Add Server를 열고 Type에서 Subscribe를 선택한 다음, URL에 전체 주소를 입력하세요. 나중에 알아보기 쉽도록 용도나 출처를 이름으로 지정하고, 계정 정보가 포함된 긴 메모는 피하는 것이 좋습니다. 화면 구성은 기기와 앱 표시 상태에 따라 다를 수 있으므로 현재 보이는 필드를 기준으로 조작하세요. 중요한 점은 Type이 단일 서버 프로토콜이 아니라 Subscribe로 설정되어 있는지 확인하는 것입니다.

붙여넣은 뒤 주소를 처음부터 끝까지 확인하세요. 프로토콜 부분, 도메인, 경로, 물음표 뒤의 매개변수를 모두 보존해야 하며 끝에 한글 마침표, 따옴표, 줄바꿈이 섞이지 않아야 합니다. 일부 메신저는 긴 링크를 여러 줄로 표시하지만, 줄이 바뀌어 보인다고 원문이 달라지는 것은 아닙니다. 다만 여러 번 나눠 복사하면 중간 내용이 빠질 수 있습니다. 가능한 한 원본을 그대로 복사하고 화면을 보며 주소를 직접 입력하지 마세요.

1. Type이 Subscribe이고 URL에 전체 구독 주소가 입력됐는지 확인하세요.
2. 저장한 뒤 Home으로 돌아가 해당 구독 항목이나 서버 그룹이 표시되는지 확인하세요.
3. 가져오기가 끝날 때까지 기다린 다음, 서버가 예상한 구독에 포함됐는지 확인하세요. 이름만 나타났는지만 확인해서는 안 됩니다.
4. 항목 하나를 선택해 필드를 확인한 뒤 연결 및 테스트를 진행하세요.

가져오기가 실제로 완료됐는지 확인하는 방법

주소 저장, 구독 요청, 내용 해석, 서버 목록 생성은 각각 다른 단계입니다. 주소가 저장됐다는 것은 로컬 항목이 만들어졌다는 뜻일 뿐, 원격 내용을 가져왔다는 의미는 아닙니다. 구독 이름만 표시되고 서버가 없다면 먼저 업데이트가 끝났는지 확인한 뒤 응답 내용이 비어 있거나 해석할 수 없는 형식인지 살펴보세요. 같은 주소를 계속 다시 추가하지 마세요. 항목이 여러 개 생기면 이후 어느 항목을 업데이트했는지 확인하기 어려워집니다.

목록이 처음 표시되면 항목 하나를 골라 Type, Address, Port, 인증 필드가 보유한 정보와 일치하는지 확인하세요. 이름은 설명용일 뿐 매개변수 확인을 대신할 수 없습니다. 가져온 뒤 서버 수가 안내에 나온 수와 다르더라도 앱에서 데이터가 누락됐다고 단정하지 마세요. 원격 구독은 계정 상태나 이용 범위에 따라 서로 다른 내용을 반환할 수 있습니다. 주소와 계정 상태를 확인한 다음 서비스 제공업체에 해당 주소에서 반환되어야 하는 항목을 문의하세요.

구독은 정상적으로 읽히지만 특정 서버에 연결되지 않는다면 전체 구독을 다시 만들지 말고 매개변수와 테스트 항목을 확인하세요. 서버가 하나도 생성되지 않았다면 링크가 완전한지, 요청 결과가 무엇인지, 내용 형식이 맞는지 순서대로 살펴보세요. 두 문제는 서로 다른 단계에서 발생합니다. 구분해서 기록하면 아직 가져오기가 끝나지 않은 목록을 연결 스위치로 반복해서 시험하는 일을 피할 수 있습니다.

이 장에서는 원격 목록을 로컬에 등록하는 방법을 다룹니다. 이후 업데이트 시점, 업데이트가 로컬 편집 내용에 미치는 영향, 목록이 비어 있을 때 보존할 자료는 업데이트 방식을 확인하세요. 연결 과정을 처음부터 따라가려면 빠른 시작 가이드로 돌아가세요.

연결 지점과 표시 이름 구분하기

명확한 매개변수 정보를 가지고 있으며 서버 항목 하나를 추가하려면 직접 입력할 수 있습니다. Home에서 Add Server를 열고 먼저 Type을 선택하세요. 프로토콜마다 표시되는 필드가 다르므로 모든 내용을 먼저 입력한 뒤 유형을 변경하지 마세요. 유형을 바꾼 뒤에는 인증 및 전송 옵션을 다시 확인해야 합니다. 일부 필드가 지워지거나 기존 입력값이 새 프로토콜에서 다른 의미로 해석될 수 있습니다.

Address에는 서버 주소를 입력하며, 일반적으로 도메인 또는 IP 주소를 사용합니다. Port에는 안내된 포트 번호를 입력해야 합니다. 경로가 포함된 웹 주소를 Address에 넣거나 주소 끝부분을 보고 포트를 추측하지 마세요. 표시 이름은 목록에서 항목을 구분하기 위한 용도이므로 원하는 이름을 붙일 수 있지만, 이름에 프로토콜을 적어도 실제 Type은 바뀌지 않습니다. 이름이 맞아도 유형이 틀리면 예상한 연결을 사용할 수 없습니다.

인증, TLS, 전송 계층을 각각 확인

Shadowsocks는 안내된 암호화 방식과 Password를 확인해야 합니다. VMess와 VLESS에는 UUID 필드가 자주 사용되지만, Type만 바꾼 뒤 나머지 설정을 그대로 사용할 수는 없습니다. Trojan은 Password와 TLS 관련 매개변수를 주의해서 확인하세요. HTTP와 SOCKS5는 인증 요구 사항이 서로 다릅니다. 어떤 필드가 표시되고 필수인지 여부는 선택한 프로토콜과 현재 화면을 기준으로 판단해야 합니다. 모든 유형에 공통으로 적용되는 하나의 입력표는 없습니다.

TLS, SNI, Host, Path는 서로 다른 계층에 속합니다. Address는 연결할 대상을 지정하고, SNI는 TLS 연결에서 서버 이름을 나타내며, Host와 Path는 선택한 전송 방식의 요청에 사용될 수 있습니다. 이 값들이 같은 도메인을 사용하는 경우도 있지만 반드시 같아야 하는 것은 아닙니다. 원본 정보에 특정 항목이 없다면 Address를 모든 빈 필드에 일괄 복사하거나 다른 서버의 설정을 참고해 임의로 채우지 마세요.

인증서 관련 오류가 발생하면 먼저 시스템 시간, SNI, 서버 인증서 설정을 확인하세요. Allow Insecure는 인증서 검증 방식에 영향을 주므로 일반적인 해결 방법처럼 함부로 켜지 마세요. 인증서 검증 실패의 원인을 확인해야지, 오류 메시지만 없애서는 안 됩니다. WireGuard, Hysteria2 같은 유형은 해당 프로토콜에 맞는 매개변수 전체를 사용해야 합니다. Password나 UUID에 단순히 대응시키지 마세요.

저장 후 변경을 최소화해 문제 해결하기

입력을 마친 뒤 편집 화면으로 돌아가 한 번 더 확인하세요. 특히 비밀번호 앞뒤의 공백, UUID에서 빠진 문자, 포트 입력값을 살펴보세요. 입력기가 일반 문장 부호를 전각 문자로 바꿀 수 있어 직접 옮겨 적을 때 오류가 나기 쉽습니다. 복사할 수 있는 정보라면 원본 값을 복사하는 편이 좋습니다. 오류를 발견하면 한 번에 필드 하나만 수정하고 수정 전후의 증상을 기록하세요. 여러 항목을 동시에 바꾸면 원인을 판단하기 어려워집니다.

같은 서버를 공유 링크로 가져오면 연결되지만 직접 입력한 항목은 실패한다면 주소가 잘못됐다고 단정하기 전에 두 항목의 Type, 인증, TLS, 전송 계층을 나란히 비교하세요. 대조할 때 원본 가져오기 항목 하나를 기준으로 보존하고 덮어쓰지 마세요. 반대로 직접 입력은 성공하지만 구독에서 생성된 항목이 실패한다면 구독 내용에 오래된 매개변수가 남아 있는지 확인해야 할 수 있습니다.

저장이 성공했다는 것은 입력한 필드가 받아들여졌다는 뜻이지, 인증이나 원격 서비스 검증까지 통과했다는 뜻은 아닙니다. 다음으로 항목을 선택해 Connectivity Test를 진행하고 Global Routing과 실제 접속 결과를 확인하세요. Trojan 필드 구성은 Address, Port, Password, SNI 매개변수 안내를 참고하세요. 특정 프로토콜의 예시를 다른 프로토콜의 기본 설정으로 사용하지 마세요.

QR 코드를 스캔하기 전에 포함된 내용 확인하기

QR 코드에는 단일 서버 공유 링크나 구독 주소가 들어갈 수 있으므로 겉모양만으로 유형을 알 수 없습니다. 스캔에 성공했다는 것은 이미지의 텍스트를 인식했다는 뜻일 뿐, 주소에 접속할 수 있거나 매개변수가 유효하다는 뜻은 아닙니다. QR 코드가 있다면 원본 안내를 확인해 구독인지 개별 서버 항목인지 판단한 뒤 Shadowrocket에서 보이는 Scan QR Code 기능을 사용하세요.

카메라를 처음 실행할 때 시스템에서 카메라 접근 권한을 요청할 수 있습니다. 용도를 확인한 뒤 허용하세요. 이전에 거부했다면 시스템 설정에서 Shadowrocket의 카메라 권한을 확인할 수 있습니다. 스캔할 때 QR 코드 전체가 화면 안에 들어오도록 하고 가장자리가 잘리거나 화면이 반사되거나 이미지가 지나치게 압축되지 않도록 하세요. QR 코드에 긴 내용이 들어 있으면 무늬가 더 촘촘해집니다. 카메라를 계속 가까이 대기보다는 원본 이미지를 확대하는 편이 나을 수 있습니다.

QR 코드가 현재 기기에 표시되어 있다면 앱에서 제공하는 이미지 인식 기능을 사용할 수 있습니다. 해당 기능이 화면에 없다면 보유한 원본 텍스트 링크를 사용해 가져오세요. 인식 문제를 피하려고 QR 코드를 출처를 알 수 없는 웹사이트에 업로드하지 마세요. 실제 인증 정보가 들어 있는 공개 이미지를 새로 만들지도 마세요. 원본 QR 코드는 복구를 위해 보관해야 하며 공개적으로 배포할 안내 자료로 사용해서는 안 됩니다.

클립보드에는 완전한 내용 하나만 복사하기

클립보드에서 가져오려면 먼저 원본 자료에서 전체 내용을 하나 복사한 다음 Shadowrocket으로 돌아와 현재 표시되는 클립보드 가져오기 기능을 사용하세요. 시스템에서 붙여넣기를 확인하는 창이 나타나면 방금 복사한 자료가 맞는지 확인하세요. 클립보드에 오래전 내용이 남아 있다고 가정하지 마세요. 앱 간 복사로 내용이 바뀌었을 수 있으며, 기기 간 클립보드 동기화로 예상하지 못한 텍스트가 들어올 수도 있습니다.

복사 범위에는 링크만 포함하고 제목, 번호, 코드 블록 표시, 채팅 인용 기호는 넣지 않는 것이 좋습니다. 링크 여러 개를 한꺼번에 가져올 수 있는지는 형식에 따라 다릅니다. 확인하기 쉽도록 처음에는 하나씩 가져오세요. 작업을 마칠 때마다 목록에 어떤 항목이 추가됐는지 확인한 뒤 다음 링크를 처리하면 중복되거나 잘못된 항목을 나중에 구분하기 어려워지는 일을 막을 수 있습니다.

1. 기존 자료로 돌아가 원본 링크를 복사하거나 원본 QR 코드를 여세요.
2. Scan QR Code 또는 앱에서 현재 제공하는 클립보드 가져오기 기능을 선택하세요.
3. 확인 또는 편집 화면에서 Type을 확인하고 Address, Port 등 주요 필드를 검토하세요.
4. 저장 후 항목이 어디에 추가됐는지 확인하고 테스트하세요. 가져오기 완료 메시지만 확인해서는 안 됩니다.

앱이 클립보드 내용을 인식하지 못하면 먼저 해당 내용이 구독 URL인지, 프로토콜 공유 링크인지, 일반 안내문인지 확인하세요. 완전한 구독 주소라면 Add Server로 돌아가 Subscribe를 선택한 뒤 URL을 직접 붙여넣을 수 있습니다. 단일 서버 링크는 해당 프로토콜에 맞춰 처리해야 하며, 입력을 받아들이도록 무조건 Subscribe로 바꾸면 안 됩니다. 전달 수단이 달라도 가져올 항목의 유형을 판단하는 과정은 필요합니다.

인식 실패와 연결 실패는 따로 해결하기

QR 코드를 스캔해도 반응이 없다면 이미지 품질과 권한을 먼저 확인하세요. 인식 후 형식이 맞지 않는다는 메시지가 나오면 텍스트 구조를 살펴보세요. 서버 항목이 생성됐는데 연결되지 않을 때는 필드와 네트워크를 점검해야 합니다. 세 상황을 구분해서 설명하면 문제 해결이 훨씬 빨라집니다. 예를 들어 “카메라에 QR 무늬가 보이지만 항목이 생성되지 않음”과 “Trojan 항목은 생성됐지만 인증 실패”는 확인할 내용이 완전히 다릅니다.

가져온 뒤 이름이 같은 항목이 여러 개 생겨도 바로 하나를 삭제하지 마세요. 서로 다른 구독에서 가져왔는지, 포트나 전송 방식이 다른지 먼저 확인하세요. QR 코드의 제목은 구분을 위한 메모일 뿐이며 제목이 같다고 매개변수도 같은 것은 아닙니다. 중복이 확인되면 출처가 명확하고 복구할 수 있는 항목을 남긴 뒤 이 페이지의 삭제 안내에 따라 정리하세요. 검증 전에 여러 항목을 한꺼번에 삭제하지 마세요.

다른 사람에게 문제를 설명할 때는 가져오기 방법, 인식된 Type, 오류가 발생한 단계, 이미 확인한 항목만 전달하고 전체 내용을 첨부하지 마세요. 가져오기가 끝나면 인증 정보 대신 다른 민감하지 않은 내용을 복사해 클립보드의 값을 바꾸세요. 내용이 유출됐다고 의심되면 로컬 항목 이름만 변경하지 말고 서비스 제공업체에서 교체된 정보를 받으세요.

프로토콜 접두사로 해석 방향 파악하기

단일 서버 공유 링크에는 일반적으로 ss://, vmess://, vless://, trojan:// 같은 프로토콜 접두사가 포함됩니다. 접두사는 어떤 방식으로 해석할지 알려주며, 뒤에는 인코딩된 필드나 쿼리 매개변수가 포함된 주소 구조가 올 수 있습니다. 접두사만으로 대략적인 유형은 알 수 있지만 인증값, TLS, 전송 계층이 모두 올바른지 눈으로 확인할 수는 없습니다.

공유 링크에는 사용자 정보, 호스트, 포트, 쿼리 매개변수, 메모가 함께 들어갈 수 있습니다. 프로토콜과 생성 방식에 따라 구조가 다르므로 하나의 프로토콜을 분해하는 방법을 모든 링크에 적용하면 안 됩니다. 가장 안전한 방법은 원문을 그대로 보존해 Shadowrocket에서 해석한 뒤 편집 화면에 표시된 필드를 확인하는 것입니다. 텍스트 편집기에서 먼저 직접 수정하지 마세요.

https://example.com/sub?token=xxxx
trojan://[email protected]:443?security=tls&sni=example.com#Example

위 예시는 구독 URL과 단일 서버 링크의 겉모양 차이를 보여주는 교육용 가짜 값이며, 연결 정보로 사용할 수 없습니다. 물음표 뒤에는 보통 쿼리 매개변수가, 샵(#) 뒤에는 메모가 들어가지만 구체적인 프로토콜 형식을 따라야 합니다. 링크의 퍼센트 인코딩도 의미가 있습니다. 인코딩 문자를 읽기 쉬운 텍스트로 바꾸면 비밀번호, 경로, 메모의 실제 내용이 달라질 수 있습니다.

인코딩은 암호화가 아니며 구독은 규칙 파일이 아닙니다

일부 링크나 구독 응답은 Base64 같은 인코딩으로 내용을 표현합니다. 인코딩은 데이터를 표현하는 방식일 뿐 인증 정보를 비밀로 보호하지 않습니다. 긴 문자열을 바로 읽을 수 없더라도 전체를 비밀번호 자료처럼 취급하세요. 문제를 확인할 때 내용을 공개 온라인 디코더에 붙여넣지 마세요. 먼저 복사가 완전한지, 응답이 예상한 유형인지, 앱이 정상적으로 해석하는지만 확인하면 됩니다.

구독 응답에는 여러 서버 링크나 다른 지원 형식이 포함될 수 있습니다. 브라우저에서 열었을 때 텍스트로 보이거나 파일 저장이 시작되거나 로그인 페이지가 표시될 수 있습니다. 어느 쪽도 해당 내용이 현재 입력란에 적합하다는 증거는 아닙니다. 실제 응답이 로그인 안내, 오류 메시지, 웹페이지라면 요청이 원격 주소에 도달했더라도 클라이언트가 서버 목록을 만들지 못할 수 있습니다.

Config의 규칙 조각은 또 다른 유형의 내용입니다. 아래에는 규칙이 [Rule] 아래에 배치되는 방식을 보여주는 일반적인 Shadowrocket 설정 구조가 나옵니다. 여기에는 서버 인증 매개변수가 없으며 Subscribe 주소를 대신할 수도 없습니다. 기존 설정 구조를 이해하고 수정할 범위를 확인한 뒤에만 규칙을 자신의 Config에 적용하세요.

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

가져온 항목과 실제 라우팅의 연결 확인하기

서버 항목은 “어떤 연결 지점을 사용할지” 정하고, Global Routing은 “트래픽에 어떤 연결 방식을 적용할지” 정합니다. Config 모드는 현재 설정에 따라 처리하고, Proxy 모드는 프록시 경로를 사용하며, Direct 모드는 직접 연결합니다. 서버를 가져온 직후 Direct 모드로 접속했다면 트래픽이 해당 서버를 거치지 않는다고 해서 가져오기에 실패한 것은 아닙니다. 테스트 결과는 현재 모드와 함께 해석해야 하며, 서버 목록에서 선택 표시만 확인해서는 안 됩니다.

Config 모드에서는 규칙 순서와 현재 활성화된 설정도 중요합니다. 예시의 DOMAIN-SUFFIX는 도메인 접미사를 기준으로 일치 항목을 찾고, GEOIP는 주소의 지리적 위치 정보로 판단하며, FINAL은 앞선 규칙에 일치하지 않을 때 적용되는 기본 항목입니다. FINAL 한 줄만 복사해 완전한 분기 라우팅 정책을 만들었다고 생각하지 마세요. 예시 설정을 모든 네트워크 환경에 맞는 구성으로 간주해서도 안 됩니다.

같은 자료에서 구독과 Config를 모두 제공한다면 각각의 용도, 업데이트 방법, 관리 위치를 확인하세요. 서버 목록을 업데이트해도 규칙 파일이 반드시 업데이트되는 것은 아니며, Config를 전환해도 서버 매개변수가 반드시 바뀌는 것은 아닙니다. 두 항목을 백업 안내에 각각 기록해 두면 “목록은 정상인데 일부 접속 경로가 예상과 다름” 같은 문제를 올바른 단계부터 확인할 수 있습니다.

업데이트가 필요한 경우

서버에서 주소, 인증 정보, 이용 가능 범위를 변경하면 로컬 목록에 이전 내용이 남을 수 있습니다. 이때 해당 구독을 업데이트해야 합니다. 업데이트의 주요 목적은 원격 목록을 동기화하는 것이며 현재 연결 속도를 높이는 것이 아닙니다. 특정 접속이 시간 초과됐다면 먼저 기존 항목과 네트워크 상태를 테스트하세요. 모든 구독을 업데이트하고 Config를 바꾸고 연결을 재시작하는 일을 한꺼번에 하면 어떤 조치가 결과를 바꿨는지 알기 어렵습니다.

앱에서 제공하는 구독 관리 기능으로 대상 구독을 업데이트하고 해당 그룹의 결과를 확인하세요. 현재 화면에 업데이트 주기나 자동 업데이트 옵션이 있다면 필요에 맞게 설정할 수 있습니다. 앱이 항상 백그라운드에서 실행된다고 가정하지 말고 업데이트 메시지가 보이지 않는다고 시스템에서 동기화가 완료됐다고 판단하지 마세요. 중요한 변경 사항은 직접 업데이트한 뒤 결과를 확인하는 편이 시간만으로 추측하는 것보다 확실합니다.

업데이트 전에 현재 사용할 수 있는 서버 이름과 주요 매개변수를 기록하고 필요한 경우 별도로 백업하세요. 구독은 원격 내용에 따라 관리되는 목록이므로 업데이트 후 서버 이름이 바뀌거나 항목이 사라지거나 매개변수가 달라질 수 있습니다. 이전 항목을 보존하면 비교하기 쉽지만, 계속 사용할 수 있는지는 원격 서비스 상태에 달려 있습니다. 백업해도 유효 기간이 연장되는 것은 아닙니다.

요청, 해석, 사용 단계로 나눠 확인하기

요청 단계에서 실패하면 먼저 현재 네트워크가 정상인지 확인하고 URL에 불필요한 공백이 있거나 내용이 잘리지 않았는지 살펴보세요. 구독 주소의 도메인을 찾을 수 없다면 내용 가져오기 이전 단계의 문제입니다. 서버 Password를 반복해서 수정해도 해결되지 않습니다. 기존 목록을 먼저 삭제하지 마세요. 항목을 보존하면 원격 주소에 일시적으로 접속할 수 없는지, 로컬에 저장된 서버도 작동하지 않는지 비교할 수 있습니다.

해석 단계에서 실패하면 어떤 내용이 반환됐는지 확인해야 합니다. 계정 만료 안내, 접근 제한 안내, 일반 웹페이지가 서버 목록 대신 반환될 수 있습니다. 클라이언트가 이런 내용에서 서버를 생성하지 못한다고 임의의 다른 프로토콜 유형을 선택해야 하는 것은 아닙니다. 먼저 계정 상태와 주소의 적용 범위를 확인하고 서비스 제공업체에서 확인된 구독 정보를 받으세요.

목록이 생성됐는데 연결되지 않는다면 특정 서버의 매개변수와 Connectivity Test를 확인하세요. 구독 업데이트 성공이 서버 사용 가능성을 뜻하지는 않습니다. 목록에 있는 연결 지점이 점검 중일 수 있고 인증 정보가 원격 상태와 맞지 않을 수도 있습니다. “업데이트 성공, 항목 존재, 테스트 실패”처럼 전체 증상을 기록하면 막연히 “구독이 고장 났다”고 설명하는 것보다 원인을 찾기 쉽습니다.

반복 업데이트와 수동 수정 덮어쓰기 방지

짧은 간격으로 계속 업데이트해도 잘못된 응답 내용은 바뀌지 않으며 원격 접근 제한이 발생할 수도 있습니다. 한 번 실패하면 현재 요청이 끝날 때까지 기다린 다음 실패 단계를 확인하고 필요한 경우에만 다시 시도하세요. 네트워크를 바꿔 비교할 때는 URL을 동시에 변경하지 말고 네트워크 조건만 한 번에 하나씩 바꾸세요. 변수를 명확히 해야 문제가 로컬 네트워크와 원격 주소 중 어디에 있는지 판단할 수 있습니다.

구독에서 생성된 항목의 이름이나 매개변수를 직접 수정하면 다음 동기화 때 변경 사항이 덮어써질 수 있습니다. 일시적으로 확인할 때는 별도 항목으로 복사해 용도를 표시하세요. 장기적으로 바로잡아야 할 내용이라면 매번 로컬에서 다시 수정하지 말고 원격 구독 정보를 확인해야 합니다. 자동 관리가 제대로 되려면 원본 자료가 정확해야 합니다.

업데이트가 완료되면 현재 선택한 항목이 여전히 있는지 확인하고 다시 테스트하세요. 서버 이름이 바뀌거나 삭제된 뒤에는 이전 이름만 보고 같은 연결 지점이 선택됐다고 판단하지 마세요. 항목별 점검 방법은 구독 업데이트 실패 또는 목록이 비어 있을 때 확인할 내용을 참고하세요. 다른 연결 문제는 자주 묻는 질문에서 확인할 수 있습니다.

관리 단위에 맞춰 구독 정리하기

기존 구독이 여러 개라면 먼저 출처를 명확히 구분하세요. 각 구독 항목에 서로 다른 이름을 붙여 어느 그룹을 업데이트하거나 삭제할지, 각 서버 항목이 어떤 원격 목록에서 생성됐는지 알 수 있어야 합니다. 모든 항목에 “기본”이나 “자주 사용” 같은 이름을 붙이지 말고 전체 구독 URL을 메모에 넣을 필요도 없습니다. URL을 기록하면 화면을 캡처하거나 일상적으로 표시할 때 인증 정보가 유출될 위험이 커집니다.

“일상 연결”, “예비 연결”, “테스트 항목”처럼 용도를 안정적으로 설명하는 이름을 사용하고, 출처와 용도의 대응 관계는 개인적으로 보관하는 관리 메모에 기록하는 것이 좋습니다. 이미 사용 중인 명명 규칙이 있다면 일관성을 유지하고 정렬을 위해 이름을 계속 바꾸지 마세요. 이름에 지역이나 용도가 적혀 있어도 서버의 실제 동작을 증명하지는 않습니다. 보유한 자료와 테스트 결과로 확인하세요.

같은 구독을 중복으로 가져오면 이름이 비슷한 그룹이 여러 개 생길 수 있습니다. 정리하기 전에 그룹 이름만 보지 말고 구독 주소, 서버 필드, 업데이트 상태를 비교하세요. 서로 다른 URL에서 겹치는 목록이 반환될 수도 있고 같은 주소라도 계정 상태에 따라 결과가 달라질 수 있습니다. 정리의 목적은 불필요한 복사본을 줄이는 것이지 비슷해 보이는 항목을 무조건 하나로 합치는 것이 아닙니다.

구독에서 생성된 항목과 수동 항목 따로 관리하기

구독에서 생성된 항목은 원격 변경 사항을 반영하는 데 적합하고, 수동 항목은 별도로 제공된 매개변수를 보관하거나 임시로 확인할 때 적합합니다. 두 종류를 함께 사용해도 되지만 이름이나 그룹으로 차이를 표시하세요. 문제 해결을 위해 구독 항목을 독립 항목으로 복사했다면 로컬 복사본이라는 설명과 복사한 이유를 메모하세요. 그래야 나중에 원래 구독을 업데이트해도 복사본까지 동기화됐다고 착각하지 않습니다.

임시 복사본은 설명하기 어려운 오래된 항목으로 남기 쉽습니다. 문제 해결이 끝나면 계속 보관할지, 설명을 보완할지, 삭제할지 결정하세요. 보관한다면 SNI를 수정했거나 안내된 포트를 사용하도록 바꾼 것처럼 원본과 다른 점을 기록하세요. 단순히 “작동함”이라고만 적으면 당시 네트워크와 매개변수가 무엇이었는지 알 수 없어 나중에 재현하기 어렵습니다.

현재 앱에 구독별 보기, 필터, 목록 접기 기능이 있다면 수정 범위를 먼저 좁히세요. 여러 항목을 한꺼번에 처리하기 전에 필터 조건과 실제 선택 범위를 확인하고, 필터로 숨겨진 항목도 선택 범위에 포함되는지 주의하세요. 확실하지 않다면 중요도가 낮은 항목 하나로 작업 결과를 확인한 뒤 나머지를 처리하세요. 목록 전체를 한 번에 바꾸지 마세요.

선택, 정렬, 규칙 참조는 서로 다른 기능

목록의 위치는 일반적으로 표시 순서만 정하며 현재 연결 선택을 나타내지 않습니다. 서버 항목을 맨 위로 옮겼더라도 Home에서 실제로 선택된 항목을 확인하세요. Config에서 정책이나 그룹을 사용한다면 규칙이 최종적으로 어떤 대상을 사용하는지도 살펴봐야 합니다. 화면에서 “첫 번째 항목”과 라우팅에서 “현재 대상”은 서로 다른 개념이므로 혼동하지 마세요.

설정이 특정 이름을 참조한다면 관련 항목의 이름을 바꾸거나 삭제한 뒤 선택 및 관리 방식에 영향을 줄 수 있습니다. 변경 전에 Config에서 관련 내용을 확인하고 기존 이름과 새 이름의 대응 관계를 기록하세요. 익숙하지 않은 설정에서는 여러 항목의 이름과 규칙을 동시에 바꾸지 마세요. 먼저 서버 목록을 정리하고 확인한 뒤 Config를 따로 살펴보면 문제가 생겼을 때 되돌릴 범위를 줄일 수 있습니다.

iPhone과 iPad에서 같은 자료를 관리한다면 동일한 그룹 설명을 사용할 수 있지만 두 기기의 정렬, 선택, 동기화 상태가 완전히 같다고 가정하지 마세요. 각 기기에서 구독 항목과 현재 선택을 따로 확인해야 합니다. 정리 후에는 어떤 항목이 구독에 따라 관리되고 어떤 항목을 수동으로 관리해야 하는지 간단한 목록으로 남기세요. 서버 목록 화면을 캡처하는 것보다 복원에 더 유용합니다.

무엇을 측정하는지 먼저 이해하기

Connectivity Test는 현재 테스트 조건에서 서버 연결 상태를 확인하는 기능입니다. 구체적인 측정 내용은 앱에서 선택한 테스트 방식과 대상에 따라 달라집니다. 밀리초로 표시된 모든 값을 같은 지표로 해석하지 마세요. 네트워크 경로, 도메인 조회, 원격 연결 지점, 테스트 대상이 결과에 영향을 줄 수 있으므로 서로 다른 시간이나 네트워크에서 나온 숫자를 같은 조건의 결과처럼 비교해서는 안 됩니다.

지연 시간은 주로 특정 테스트 단계에 걸린 시간을 나타냅니다. 지속적인 전송 속도를 직접 나타내지 않으며 모든 웹사이트에 정상적으로 접속할 수 있다는 보장도 아닙니다. 테스트가 빠른 항목도 실제 요청에서는 인증, TLS, 규칙, 대상 사이트 문제를 겪을 수 있습니다. 테스트 시간 초과가 서버 전체를 영구적으로 사용할 수 없다는 뜻도 아닙니다. 먼저 현재 환경에 테스트 방식이 적합한지 확인한 뒤 실제 접속 결과와 함께 판단하세요.

비교를 시작하기 전에 Wi-Fi인지 셀룰러 네트워크인지 기록하고 대량 전송이 진행 중이지 않은지 확인하세요. 테스트 대상과 방식을 동일하게 유지하세요. 서버 차이만 비교하려는 경우 네트워크와 Global Routing을 동시에 바꾸지 마세요. 재현 가능한 테스트는 한 번 나온 이상적인 숫자가 아니라 안정된 조건에 달려 있습니다.

반복 테스트를 몇 차례 진행해 안정성 확인하기

먼저 현재 선택된 항목 하나를 테스트해 작업이 완료되는지 확인한 다음 필요하면 같은 그룹의 다른 항목도 테스트하세요. 결과가 연속해서 달라지면 특정 항목만 바뀌는지 그룹 전체가 함께 바뀌는지 살펴보세요. 그룹 전체가 동시에 느려졌다면 로컬 네트워크나 공통 경로를 확인할 필요가 있습니다. 특정 항목만 계속 실패한다면 해당 연결 지점의 매개변수와 원격 상태를 먼저 살펴보세요. 한 번의 결과만으로 항목을 바로 삭제하지 마세요.

테스트를 마친 뒤 실제 용도에 맞는 접속을 확인하고 트래픽 경로가 예상과 일치하는지 살펴보세요. Global Routing이 Direct라면 접속에 성공해도 서버가 정상 작동한다는 증거가 아닙니다. Config 모드에서는 규칙에 따라 일부 요청이 직접 연결될 수 있습니다. 필요한 경우 앱에 표시되는 기록에서 해당 요청을 확인해 직접 연결 성공을 프록시 연결 검증으로 오해하지 마세요.

실제 접속에 실패했다면 도메인 조회 실패, 연결 대기, TLS 오류, 원격 응답 수신 등 어느 단계에서 문제가 발생했는지 구체적으로 설명하세요. 단계마다 확인할 내용이 다릅니다. 주소 해석 문제는 DNS와 경로를, 인증 문제는 자격 증명을, 규칙 문제는 Config를 먼저 확인해야 합니다. 테스트 버튼을 반복해 누르면 같은 상황을 다시 확인할 뿐 오류 단계 분석을 대신하지 못합니다.

정렬은 선택을 돕지만 판단을 대신하지 않습니다

현재 화면에서 지연 시간순 정렬을 지원한다면 한 차례 전체 테스트를 마친 뒤 사용하세요. 새 결과와 이전 결과가 섞이는 일을 줄일 수 있습니다. 측정되지 않은 항목, 실패한 항목, 유효한 항목은 서로 다르게 정렬될 수 있으므로 정렬 후에도 실제 상태를 확인하세요. 목록 첫 번째 항목은 현재 정렬 기준에서 앞에 있을 뿐 항상 가장 좋은 선택은 아닙니다. 네트워크가 바뀌면 기존 정렬 결과의 참고 가치가 떨어질 수 있습니다.

일상적으로 사용할 때는 검증된 항목 몇 개를 후보로 남기고 나머지는 출처에 따라 접거나 정리할 수 있습니다. 대체 항목을 보존하면서 매번 전체 목록을 테스트하는 부담을 줄일 수 있습니다. 후보를 고를 때는 지연 시간뿐 아니라 연결 안정성, 매개변수 출처의 명확성, 실제 접속 결과도 고려하세요. 테스트는 선택을 돕는 수단이지 서비스 제공업체의 가치를 평가하는 기준이 아닙니다.

특정 서버와 모드 조합이 작동하는 것을 확인했다면 그 상태를 기준으로 유지한 다음 문제가 있는 항목을 하나씩 확인하세요. 기준 상태를 보존하지 않은 채 목록을 한꺼번에 업데이트, 삭제, 변경하면 새 변경 사항과 기존 네트워크 중 어느 쪽이 문제인지 판단하기 어렵습니다. 모드 선택에 관한 자세한 내용은 Global Routing 기능 안내를, 일반적인 연결 문제는 자주 묻는 질문을 확인하세요.

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

서버 항목 하나 삭제, 구독 항목 전체 삭제, Config 제거는 각각 다른 작업입니다. 구독에서 생성된 항목을 삭제해도 다음 업데이트 때 다시 만들어질 수 있습니다. 구독 항목을 삭제하면 해당 그룹의 서버에도 영향을 줄 수 있습니다. 실행 전에 현재 확인 메시지를 읽고 항목 하나를 삭제하는지 그룹 전체를 삭제하는지 파악하세요. 길게 누른 위치나 목록 모양만 보고 작업 범위를 추측하지 마세요.

특정 항목을 잠시 사용하지 않을 뿐이라면 바로 삭제하지 말고 검증된 다른 항목을 선택할 수 있습니다. 실제로 정리해야 한다면 해당 항목이 유일하게 사용할 수 있는 연결이 아닌지, 기존 설정에서 참조하고 있지 않은지 먼저 확인하세요. 출처가 불분명한 로컬 복사본이라면 원본 매개변수를 보관했는지 살펴보세요. 복구 자료가 없으면 삭제 후 비교할 수 있는 상태에서 자료를 다시 모아야 하는 상황으로 바뀝니다.

목록에서 항목을 삭제해도 이미 유출된 자격 증명이 무효화되거나 원격 계정 상태가 바뀌는 것은 아닙니다. 구독 주소나 비밀번호 유출이 의심돼 정리하는 경우 서비스 제공업체에서 교체된 정보를 받고 해당 절차에 따라 이전 자격 증명을 처리하세요. 로컬에서 삭제하면 현재 기기의 기록만 바뀔 뿐 원격 측 자격 증명은 업데이트되지 않습니다.

세 단계로 나눠 백업하기

첫째는 구독 항목과 출처 안내, 둘째는 별도로 추가한 서버 매개변수, 셋째는 Config와 보존할 규칙 설정입니다. 구독 주소만 저장하면 원격 목록은 다시 가져올 수 있지만 수동 항목과 규칙까지 복원된다는 보장은 없습니다. Config만 내보내도 모든 구독 자격 증명과 앱 설정이 포함됐다고 단정할 수 없습니다. 실제로 내보낸 내용이 어디까지 포함하는지 확인하세요.

앱에서 iCloud 동기화나 내보내기를 제공한다면 현재 사용할 수 있는 옵션과 완료 상태를 확인한 뒤 기기 변경에 충분한지 판단하세요. 동기화를 켰다고 모든 내용이 다른 기기에 전송됐다는 뜻은 아니며, 실수로 삭제한 항목을 반드시 되돌릴 수 있다는 의미도 아닙니다. 동기화는 여러 기기의 상태를 맞추는 데 중점을 두고, 백업은 복원할 수 있는 사본을 보존하는 데 중점을 둡니다. 중요한 변경 전에는 별도 저장 위치에 자료를 보관하세요.

백업 파일, QR 코드, 공유 링크에는 인증 정보가 포함될 수 있으므로 필요한 사람만 접근할 수 있는 위치에 보관하세요. 찾기 편하다는 이유로 공개 문서나 공개 앨범에 올리지 마세요. 자료의 용도와 포함 항목을 적어 두면 충분합니다. 비밀번호를 파일 이름에 다시 넣을 필요는 없습니다. 저장 후 파일을 실제로 열 수 있는지, 내용이 완전한지 확인하세요. 기기를 바꿀 때 빈 파일이나 일반 웹페이지를 저장했다는 사실을 뒤늦게 알지 않도록 합니다.

구매, 가져오기, 선택, 검증 순으로 복원하기

새 iPhone 또는 iPad에서 먼저 App Store를 통해 구매한 앱을 확인하고 복원하세요. 구매 적용 범위와 시스템 요구 사항은 App Store 페이지를 기준으로 확인해야 합니다. 앱 구매 내역은 앱을 다시 받을 수 있게 해줄 뿐 서버, 구독, Config까지 자동으로 복원하지는 않습니다. 구매 복원 방법은 구매 항목 복원 안내를 확인하세요. 데이터가 사라졌다고 앱을 다시 구매하지 마세요.

1. 앱이 올바른 App Store 제품 페이지에서 제공되는지 확인하고 처음 실행을 완료하세요.
2. 동기화된 데이터를 복원하거나 백업을 가져온 뒤 구독, 개별 항목, Config가 모두 있는지 확인하세요.
3. 필요한 구독을 업데이트하고 현재 선택된 서버와 Global Routing을 확인하세요.
4. Connectivity Test와 실제 접속을 완료한 뒤 이전 기기의 자료를 정리할지 결정하세요.

복원 후 이름이 같은 항목이 나타나면 동기화, 내보내기, 재가져오기 중 어느 경로에서 생겼는지 먼저 확인하세요. 바로 여러 항목을 한꺼번에 중복 제거하지 마세요. 검증된 데이터 그룹 하나를 기준으로 보존한 뒤 불필요한 복사본을 정리할 수 있습니다. 새 기기와 이전 기기의 동작이 다르다면 현재 네트워크, Config, 서버 필드, 시스템 권한 상태를 하나씩 비교하세요. 목록 이름이 같다는 이유만으로 두 기기의 설정이 완전히 같다고 판단해서는 안 됩니다.

기기 변경 절차를 자세히 알아보려면 Config 백업, iCloud 동기화 및 기기 변경 후 복원 방법을 읽어보세요. 평소에는 업데이트와 삭제를 별개의 작업으로 진행하세요. 먼저 새 데이터가 유효한지 확인한 뒤 이전 항목을 정리하면 명확한 복구 경로를 남기고 이후 문제 해결도 설명하기 쉬운 상태에서 시작할 수 있습니다.