Shadowrocket
완벽 사용 가이드

02 / 첫 실행

첫 실행 및 시스템 권한

연결을 시작하기 전에 각 항목의 역할부터 확인

Shadowrocket을 처음 열면 먼저 Home에 서버 항목이 있는지 확인하고, 현재 Global Routing 및 Config를 살펴보세요. 서버 항목은 연결할 대상을 정하고, Global Routing은 트래픽 처리 방식을 정하며, Config는 구성 모드에서 사용할 세부 규칙을 제공합니다. 기본 스위치는 연결을 시작하거나 중지할 뿐, 필요한 전제 조건을 대신 채우지 않습니다. 목록이 비어 있거나 항목이 선택되지 않았거나 가져오기에 실패했다면 먼저 추가 단계로 돌아가세요. 이때 기본 스위치를 계속 전환해도 누락된 연결 정보가 자동으로 나타나지는 않습니다.

시작하기 전에 시스템 네트워크를 제어하는 다른 연결을 잠시 중지하면 설정 간 영향을 줄일 수 있습니다. 기존 설정을 삭제하려는 것이 아니라, 어떤 구성이 작동 중인지, 언제 연결을 시작했는지, 연결을 끈 뒤 네트워크가 복구되는지를 명확히 확인하기 위한 조치입니다. 학교나 조직에서 관리하는 기기는 시스템에서 네트워크 설정 추가 또는 변경을 제한할 수 있습니다. 기기 관리 정책을 따르세요. 용도를 모르는 상태에서 조직이 제공한 설정을 제거하지 말고, 관리 제한을 서버 매개변수 오류로 오해하지 마세요.

VPN 구성 추가 시 시스템 확인 절차

처음 연결을 시작하면 시스템에서 Shadowrocket이 VPN 구성을 추가하도록 허용하고 기기 암호나 시스템 인증으로 확인하라는 메시지가 표시될 수 있습니다. 이 구성은 Apple이 제공하는 네트워크 기능을 통해 앱이 트래픽을 처리할 수 있게 해 주며, 연결 기능의 일부입니다. 서비스 제공업체에서 연결 권한을 구매했다는 뜻도 아니고 서버 인증이 완료됐다는 의미도 아닙니다. 현재 사용자가 직접 시작한 작업에서 확인 창이 나타났고 앱의 정체가 올바른지 확인한 다음 시스템 절차에 따라 허용하세요. 권한을 허용한 뒤에도 서버에 연결할 수 있는지 별도로 테스트해야 합니다.

이전에 취소를 선택했다면 앱으로 돌아가 현재 항목이 완전한지 확인한 뒤 연결을 다시 시작해 필요한 권한 요청을 표시하세요. 필요한 경우 시스템 Settings에서 VPN 관련 항목을 확인할 수 있습니다. 이름과 경로는 기기 시스템에 따라 달라질 수 있으므로 실제 화면을 기준으로 하세요. 해당 구성이 있는지, 활성화가 허용되는지, 다른 연결이 함께 작동 중인지 확인하세요. 권한 창을 다시 표시하려고 모든 네트워크 설정을 한꺼번에 삭제하지 마세요. 변경 범위만 넓어지고 처음 실패한 지점을 파악하기 어려워집니다.

시스템에 VPN 상태가 표시된다는 것은 네트워크 구성이 작동 중이라는 뜻일 뿐, 서버 인증이 성공했거나 특정 웹사이트가 예상한 경로로 연결된다는 의미는 아닙니다. 구성이 시작되었더라도 선택한 서버에 연결할 수 없을 수 있고, 서버가 정상이어도 현재 규칙에 따라 대상이 DIRECT로 전달될 수 있습니다. 문제를 판단할 때는 시스템 상태, 앱 테스트 결과 및 실제 접속 결과를 따로 기록하세요. 그래야 나중에 “스위치는 켜졌지만 접속할 수 없음” 문제가 권한, 전송 또는 트래픽 분배 중 어느 단계에서 발생했는지 확인할 수 있습니다.

실제 기능에 필요한 권한만 허용

Scan QR Code를 사용하면 앱이 사용자가 보유한 구성 QR 코드를 읽기 위해 카메라에 접근해야 합니다. 카메라를 사용하지 않으려면 현재 자료에 적합한 다른 가져오기 방법을 선택하세요. 이미 권한을 거부했다면 시스템 Settings에서 카메라 권한을 확인할 수 있습니다. 링크를 복사해 가져올 때는 클립보드 접근 권한을 묻는 메시지가 표시될 수도 있으므로, 클립보드에 가져오려는 내용이 있는지 확인하세요. 카메라 권한과 연결 권한을 혼동하지 마세요. 카메라 권한은 QR 코드 입력에 영향을 줄 뿐 서버 연결 가능 여부와는 직접적인 관련이 없습니다.

QR 코드, 클립보드 및 구성 텍스트에는 인증 정보가 포함될 수 있습니다. 스캔하기 전에 출처와 용도를 확인하고, 가져온 후 항목 유형, 주소 및 포트를 살펴보세요. 내용을 읽었다고 해서 매개변수가 올바르다고 단정할 수는 없습니다. QR 코드가 본인의 다른 기기에서 생성된 것이라면 단일 서버, 구독 주소 또는 전체 구성 중 무엇을 담고 있는지도 확인하세요. 가져온 대상에 따라 이후 관리 방법이 달라집니다. 잘못된 가져오기 경로를 선택하면 내용을 인식하지 못하거나 예상과 다른 위치에 저장될 수 있지만, 그렇다고 모든 정보가 사용할 수 없게 된 것은 아닙니다.

첫 설정의 목표는 “모든 권한을 켜는 것”이 아니라 현재 작업에 필요한 권한만 허용하고 각 권한의 용도를 설명할 수 있는 상태입니다. 시스템 네트워크 권한을 허용한 뒤 테스트할 서버 항목 하나를 선택해 연결과 종료를 각각 한 번 수동으로 진행하세요. 상태 변화를 관찰하기 쉽도록 자동 연결 조건은 당분간 활성화하지 마세요. 수동 절차가 반복해서 정상 작동하는 것을 확인한 뒤 Settings 장에서 On Demand를 설정하세요. 그러면 자동 실행으로 수동 연결에 이미 존재하는 문제가 가려지는 일을 막을 수 있습니다.

03 / 연결 정보 입력

서버 추가 및 기존 구독 가져오기

Add Server: 연결 매개변수를 항목별로 확인

추가하기 전에 준비된 자료가 무엇인지 구분하세요. 단일 공유 링크는 서버 하나를 나타내고, 구독 주소는 업데이트할 수 있는 여러 항목을 가져올 때 사용하며, 구성 파일에는 규칙과 기타 설정이 함께 들어 있을 수 있습니다. 모두 텍스트 형태라고 해서 서로 바꿔 사용할 수 있는 것은 아닙니다. 자료는 본인이 이용 중인 서비스 제공업체나 기존 구성에서 가져와야 합니다. 도메인과 비밀번호만 있고 프로토콜, 포트 또는 전송 방식은 모른다면 전체 매개변수를 먼저 확인하세요. 여러 유형을 시험해 저장 가능한 항목을 만드는 것만으로는 연결 가능성을 입증할 수 없습니다.

Home에서 Add Server를 선택한 다음 원본 정보에 맞는 유형을 고르고 주소, 포트 및 인증 항목을 입력하세요. 주소 칸에는 일반적으로 호스트 이름이나 IP를 입력하며, 웹페이지 경로가 포함된 주소를 넣지 않습니다. 포트는 서버에서 수신 대기 중인 포트와 일치해야 합니다. 표시 이름은 항목을 구분하기 위한 것이며 인증에는 사용되지 않습니다. 입력을 마친 뒤 항목별로 다시 확인하고, 특히 복사한 내용의 앞뒤 공백, 전각 문장 부호 및 잘린 문자열에 주의하세요. 저장에 성공했다는 것은 입력값이 로컬 검사를 통과했다는 뜻일 뿐, 사용 가능 여부는 연결 테스트로 확인해야 합니다.

Shadowsocks, VMess, VLESS, Trojan 등의 항목은 프로토콜마다 완전히 같지 않으므로 한 프로토콜의 입력 방식을 다른 프로토콜에 그대로 적용할 수 없습니다. 원본 정보에 TLS, Server Name, Host 또는 Path가 포함되어 있다면 해당 항목에 맞게 유지하세요. Server Name과 연결 주소는 다를 수 있으며 Path는 대소문자를 구분할 수 있습니다. 인증서 확인을 끄는 방법을 일반적인 해결책으로 사용하지 마세요. 인증서 이름이 일치하지 않으면 먼저 시간, 이름 및 원본 매개변수를 확인해 실제로 해결해야 할 설정 문제를 우회하지 않도록 하세요.

Subscribe: 가져오기와 업데이트는 별도 단계

기존 구독은 구독 유형에 맞는 방식으로 가져와야 합니다. 구독 주소는 일반적으로 서버 목록을 요청하는 데 쓰이며 단일 서버의 호스트 이름으로 사용하는 주소가 아닙니다. 가져오기 전에 주소 전체를 복사하고 물음표 뒤의 매개변수가 유지됐는지 특히 주의하세요. 여기에 사용자를 식별하는 민감한 정보가 포함될 수 있습니다. 가져온 후 예상한 항목이 생성됐는지, 그룹이 잘 구분됐는지, 항목 수가 적절한지 확인한 다음 서버 하나를 선택해 테스트하세요. 구독 요청이 성공했다는 것은 목록을 가져왔다는 뜻일 뿐, 목록의 모든 서버가 현재 네트워크에서 연결 가능하다는 의미는 아닙니다.

업데이트하면 구독 서버에서 제공하는 내용을 다시 읽으므로 구독으로 관리되는 항목을 장기간 수동 편집한 복사본처럼 다루지 마세요. 항목 하나를 임시로 조정해야 한다면 원본 정보를 보관하고, 필요하면 별도의 테스트 항목으로 저장한 다음 이후 업데이트가 변경 사항을 덮어쓰는지 확인하세요. 중복 항목이 발견되면 같은 구독을 여러 번 가져온 것인지, 수동 복사본과 구독 항목이 함께 있는 것인지 먼저 확인하세요. 출처를 확인하지 않고 여러 항목을 한꺼번에 삭제하면 유일하게 보관된 유효한 구성을 함께 제거할 수 있습니다.

업데이트 실패 시 요청 경로를 따라 확인

구독 업데이트에 실패하면 먼저 기기의 기본 네트워크가 정상인지 확인한 뒤 주소가 완전한지, 현재 어떤 경로로 접속 중인지, 서버가 어떤 상태를 반환했는지 살펴보세요. 현재 서버를 사용할 수 없다면 해당 서버를 통해 구독을 요청해도 실패할 수 있습니다. 영향을 이해한 상태에서 구독 주소에 접속할 수 있는 경로로 전환한 뒤 한 번 더 시도하세요. 인증 또는 권한 오류가 표시되면 기존 주소가 바뀌었는지 확인하세요. 내용을 가져왔지만 해석할 수 없다면 반환된 내용이 지원되는 구독 데이터인지, 로그인 페이지나 오류 페이지 또는 일반 안내 웹페이지가 아닌지 확인하세요.

가져오기가 끝나면 항목의 출처, 현재 선택 상태 및 업데이트 결과를 각각 파악해 두세요. 단일 링크와 구독의 차이는 공유 링크와 구독 주소 안내를 참고하세요. 이후 테스트는 명확히 선택한 항목 하나만 대상으로 진행하세요. 구독 전체를 업데이트하면서 규칙과 DNS까지 동시에 변경하지 마세요. 입력 정보를 일정하게 유지해야 다음에 Global Routing을 변경했을 때 무엇이 달라졌는지 판단할 수 있습니다.

04 / 트래픽 경로 결정

Global Routing의 세 가지 모드와 규칙 매칭

Config, Proxy, Direct의 역할

Global Routing은 연결 테스트 전에 반드시 확인해야 할 상태입니다. Config는 현재 활성화된 구성의 규칙에 따라 요청을 처리하고, Proxy는 해당 트래픽을 프록시 경로로 보내며, Direct는 직접 연결 경로를 사용합니다. 세 모드는 경로를 선택하며 서버 자체의 인증 정보는 변경하지 않습니다. 같은 대상이 모드에 따라 다르게 작동한다면 서버를 바로 다시 만들기보다 먼저 트래픽 경로를 확인하세요. 모드 이름과 규칙에 사용하는 대문자 정책 키워드도 구분해야 합니다. 전자는 인터페이스 옵션이고 후자는 구성 텍스트입니다.

문제 해결 중에는 선택한 서버를 확인하기 위해 Proxy를 잠시 사용할 수 있지만, 테스트가 끝나면 원래 사용하려던 모드로 되돌리세요. Proxy에서는 접속되지만 Config에서는 되지 않는다면 적어도 규칙 차이를 확인할 필요가 있습니다. 구독이 손상됐다고 바로 단정할 수는 없습니다. Direct는 현재 네트워크에서 직접 접속할 수 있는지 비교할 때 사용할 수 있지만 모든 대상에 직접 접속할 수 있어야 하는 것은 아닙니다. 테스트 결과에는 대상과 모드를 함께 기록하세요. 범위 없이 “된다” 또는 “안 된다”라고만 적으면 다음 설정을 판단하는 데 도움이 되지 않습니다.

규칙은 위에서 아래로 매칭되므로 구체적인 조건을 먼저 배치

Config의 규칙은 일반적으로 위에서 아래 순서로 확인되며, 규칙이 일치하면 해당 정책을 적용합니다. DOMAIN은 전체 도메인을 매칭하고, DOMAIN-SUFFIX는 지정한 도메인과 하위 도메인을 매칭하며, DOMAIN-KEYWORD는 도메인에 포함된 키워드로 매칭합니다. IP-CIDR과 IP-CIDR6은 IP 주소 대역을 대상으로 하고, GEOIP는 주소 지역 데이터에 따라 판단합니다. FINAL은 앞서 일치하지 않은 요청을 처리합니다. 조건의 범위가 넓을수록 뒤에 있는 요청을 먼저 가로챌 가능성이 높으므로 구체적인 조건을 앞에 두고, 범위가 넓은 조건과 기본 처리 규칙은 뒤에 배치하세요.

아래는 학습용 .conf 규칙 예시이며 기존 설정을 대체할 수 있는 완전한 구성 파일이 아닙니다. 도메인은 예시 값이고 PROXY를 사용하려면 현재 이용 가능한 프록시 경로가 있어야 합니다. 예시를 적용하기 전에 기존 구성을 복사하고 복사본에서 해당 부분을 수정한 뒤, 선택한 구성이 활성화되어 있는지 확인하세요. 텍스트를 파일에 저장하는 것만으로 현재 연결에 적용되지는 않습니다. 구성을 전환한 뒤 새 요청을 만들어 규칙 결과를 확인하세요.

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

이 예시에서는 example.com과 그 하위 도메인이 먼저 PROXY로 전달됩니다. 도메인에 example이 포함된 다른 요청은 두 번째 규칙에 매칭될 수 있습니다. 두 규칙은 같은 의미가 아니며 두 번째 규칙의 매칭 범위가 더 넓습니다. 사설 네트워크 대역과 GEOIP 조건을 순서대로 확인하고 나머지 트래픽은 FINAL,DIRECT로 처리합니다. FINAL을 맨 앞에 두면 뒤에 있는 구체적인 조건이 의도대로 작동하지 않습니다. 기본 처리 규칙을 FINAL,PROXY로 바꾸면 목록에 없는 트래픽 경로도 달라집니다. 단순한 형식 변경으로 취급해서는 안 됩니다.

변경을 최소화해 트래픽 분배 방식 확인

지정한 웹사이트에만 프록시를 사용하려면 대상 DOMAIN-SUFFIX 규칙을 유지하고 FINAL,DIRECT로 마무리할 수 있습니다. 다만 웹페이지 하나가 여러 도메인에 요청을 보낼 수 있으므로 주 도메인이 일치하더라도 이미지, 로그인 또는 API 요청이 같은 경로를 사용한다고 볼 수는 없습니다. 페이지 일부만 로드된다면 실제로 실패한 요청을 확인한 뒤 명확한 도메인 조건을 추가할지 판단하세요. 범위가 지나치게 넓은 키워드 규칙으로 문제를 덮지 마세요. 원래 직접 연결하려던 다른 요청까지 함께 바뀔 수 있습니다.

규칙을 확인하려면 새 요청을 사용하고, 이전 경로를 유지하는 기존 연결 때문에 잘못 판단하지 않도록 필요한 경우 연결을 다시 설정하세요. IP 관련 조건은 DNS 결과의 영향을 받을 수 있으며 GEOIP로 특정 웹사이트의 서비스 지역을 정확히 나타낼 수 있다고 보장할 수 없습니다. 세부 매칭 방법은 규칙 키워드 안내를 참고하세요. 특정 사이트의 설정 절차는 허용 목록 기반 트래픽 분배 예시를 확인하세요. 변경할 때마다 “대상, 매칭된 규칙, 최종 정책”을 기록하면 연결 아이콘만 보는 것보다 정확히 판단할 수 있습니다.

05 / 연결 테스트

연결 확인 및 문제 해결 순서

재현 가능한 테스트 조건 설정

연결을 시작하기 전에 기기 자체에서 정상 작동하는 웹페이지에 접속할 수 있는지, 서버 항목이 명확하게 선택되어 있는지, Global Routing이 테스트할 모드로 설정되어 있는지 확인하세요. 첫 테스트는 같은 Wi-Fi 또는 셀룰러 네트워크에서 진행하고, 테스트 중에 네트워크 전환, 구독 업데이트 및 규칙 변경을 동시에 하지 마세요. 테스트 대상도 기록해야 합니다. 웹페이지 첫 화면, 로그인 API 및 앱 내부 요청은 서로 다른 도메인을 사용할 수 있으므로 하나에 접속됐다고 모든 네트워크 요청이 정상이라고 판단하지 마세요.

서버를 선택한 뒤 Connectivity Test를 실행하고 기본 연결을 켠 다음 실제 요청을 보내세요. 테스트 결과는 해당 테스트 방법에서의 연결 가능 여부와 소요 시간만 보여 주며 모든 프로토콜, 대상 또는 장시간 연결 상황을 나타내지는 않습니다. 일부 네트워크는 테스트용 요청과 실제 서비스 요청을 다르게 처리할 수 있으므로 테스트 실패가 서비스 전체의 사용 불가를 뜻하지 않을 수 있습니다. 반대로 테스트 응답이 있다고 해서 인증, TLS 또는 대상 사이트 접속까지 성공했다고 볼 수도 없습니다. 두 가지 근거를 함께 판단하세요.

‘연결 시작’과 ‘접속 가능’을 따로 확인

기본 스위치를 켠 뒤 시스템 연결 상태가 유지되는지 확인하고 브라우저에서 새 요청을 한 번 보내세요. 스위치가 곧바로 꺼지면 시스템 권한, 구성 로드 여부 및 오류 메시지를 먼저 확인하세요. 상태는 유지되지만 대상에 접속할 수 없다면 서버, 경로, DNS 및 요청 세부 정보를 계속 점검하세요. 시스템 VPN 표시를 최종 확인 기준으로 삼지 마세요. 이 표시는 로컬 네트워크 구성 상태를 나타낼 뿐, 실제 요청은 DNS 확인, 연결, 인증 및 대상 응답 등의 단계를 거쳐야 합니다.

페이지가 열려도 의도한 경로를 사용했는지 확인해야 합니다. Config 모드에서는 해당 요청에 적용된 규칙과 정책을 살펴보세요. Proxy 모드에서는 현재 선택한 서버가 확인하려던 서버인지 확인하세요. 페이지 내용이 캐시에서 로드됐다면 새 경로가 작동하는지 새로고침만으로는 알기 어려울 수 있습니다. 명확한 새 요청을 보내거나 대상 페이지를 다시 여세요. 테스트가 끝나면 일상적으로 사용할 모드로 되돌리고 다시 테스트하세요. 문제 해결 중 사용한 임시 전체 설정을 그대로 두지 않도록 주의하세요.

실패 단계에 따라 다음 조치 선택

첫 번째 단계는 현재 네트워크입니다. 연결을 끈 뒤에도 정상적인 대상에 접속할 수 없다면 Wi-Fi, 셀룰러 데이터, 포털 인증 또는 기기 네트워크 제한부터 확인하세요. 두 번째 단계는 서버입니다. 주소, 포트, 인증 정보 및 서비스 상태를 확인하세요. 같은 조건에서 본인이 보유한 다른 항목으로 바꿔 보면 특정 서버만 실패하는지 파악하는 데 도움이 됩니다. 세 번째 단계는 경로입니다. Proxy에서는 접속되지만 Config에서 실패하면 현재 활성 구성, 대상 규칙 및 기본 처리 정책을 확인하세요. 각 단계의 결론을 먼저 내린 뒤 다음 단계로 넘어가세요.

네 번째 단계는 DNS와 대상 요청입니다. 호스트 이름 확인에 실패했다면 예상한 서버 통신 단계에 아직 도달하지 않은 것입니다. 주소 확인은 됐지만 시간 초과가 발생했다면 연결 설정, 인증 또는 응답 대기 중 어느 단계인지 구분해야 합니다. 인증서 오류가 발생하면 기기 시간, Server Name과 인증서의 일치 여부를 확인하고 확인 기능을 바로 끄지 마세요. 한 웹사이트에서만 문제가 발생한다면 대상 서비스 상태, 로그인 상태 및 연관 도메인도 고려하세요. 구성 전체를 바로 사용할 수 없다고 판단하지 마세요.

한 번에 하나씩 변경하고 되돌릴 지점 보관

문제 해결 과정에서 단서를 잃기 쉬운 경우는 매개변수를 여러 개 바꾼 뒤 “이제 된다”고만 확인하고 어떤 변경이 영향을 주었는지 모르는 상황입니다. 변경 전 값, 변경 내용 및 결과를 시간순으로 기록하고 매번 설명 가능한 조건 하나만 조정하세요. 도움이 되지 않으면 원래 값으로 되돌린 뒤 다음 단계를 진행하세요. 결과가 개선되면 같은 테스트를 반복해 확인하세요. 이렇게 하면 일시적인 네트워크 변동을 관련 없는 스위치의 효과로 잘못 판단하는 일도 줄일 수 있습니다.

추가 확인이 필요하면 연결은 켜졌지만 접속할 수 없을 때 확인할 항목을 순서대로 살펴보세요. 문제를 설명할 때는 기기 네트워크 유형, Global Routing, 오류 유형 및 재현 순서를 기록하면 충분합니다. 전체 인증 정보를 첨부할 필요는 없습니다. 재현 가능한 설명에는 “어떤 네트워크에서 어떤 모드로 어떤 대상을 테스트했으며 무슨 결과가 나타났는지”가 포함되어야 합니다. 스위치 화면만으로는 부족합니다. 이러한 기록은 다음 장에서 Data를 해석하는 데도 도움이 됩니다.

06 / 진단 정보 확인

Data 트래픽 및 요청 결과 확인

집계 범위와 확인 시간대부터 파악

Data에서는 앱이 제공하는 트래픽 및 연결 정보를 확인할 수 있으며 구체적으로 표시되는 항목은 현재 화면을 기준으로 합니다. 정보를 읽을 때는 통계가 현재 세션, 특정 시간대 또는 누적 기록 중 어느 범위에 해당하는지 먼저 확인한 다음 무엇을 알 수 있는지 판단하세요. 서로 다른 화면의 숫자는 집계 범위가 다를 수 있으므로 바로 빼거나 비교하면 안 됩니다. 앱의 로컬 기록과 서비스 제공업체의 과금 기준도 다를 수 있으므로 이를 근거로 서비스 용량이 같은 수치만큼 증가하거나 감소했다고 단정하지 마세요. 용량은 사용 중인 서비스의 해당 기록을 확인해야 합니다.

변화를 해석할 수 있도록 먼저 관찰 시작점을 기록한 다음 확인할 대상 하나만 열고 새 기록과 트래픽 변화를 살펴보세요. 기기의 백그라운드 동기화, 알림, 이미지 사전 로드 및 다른 앱의 요청도 연결이 켜져 있을 때 트래픽을 발생시킬 수 있습니다. 업로드나 다운로드 수치가 증가했다는 사실만으로 테스트한 웹페이지가 정상적으로 열렸다고 입증할 수는 없습니다. 반대로 페이지 접속에 실패해도 DNS 확인, 핸드셰이크, 재시도 또는 오류 응답에 통신이 필요하므로 소량의 트래픽이 발생할 수 있습니다.

도메인, 정책 및 오류를 함께 확인

현재 화면에서 요청 세부 정보를 제공한다면 합계만 보지 말고 대상 도메인, 적용된 정책 및 결과를 먼저 확인하세요. Config 모드에서 요청이 DIRECT를 사용하는 이유는 직접 연결 규칙과 일치했거나 마지막 FINAL 규칙에 매칭됐기 때문일 수 있습니다. 구체적인 매칭 정보를 함께 확인해야 합니다. 현재 기록에 매칭된 규칙이 표시되지 않는다면 구성 순서와 통제된 테스트를 통해 범위를 좁혀 보세요. 특정 IP 주소만 보고 어떤 도메인 규칙에 매칭됐는지 추측하지 마세요.

DNS 확인 오류가 나타나면 먼저 DNS 경로와 대상 이름을 확인하세요. 연결 시간 초과가 발생하면 서버에 연결할 수 없는지, 대상에 연결할 수 없는지, 응답을 기다리는 중인지 구분해야 합니다. 인증 실패는 서버 항목으로 돌아가 인증 정보를 확인하세요. 비슷한 현상도 원인은 다를 수 있습니다. 예를 들어 페이지가 계속 로딩되는 것은 API 도메인이 잘못된 경로로 분배된 결과일 수도 있고 서버 응답이 지연되는 상황일 수도 있습니다. 오류 정보는 문제 단계를 좁히는 데 도움이 되지만 특정 단어만 보고 정해진 변경 방법을 바로 적용해서는 안 됩니다.

통제된 비교로 이상 변화 확인

특정 페이지에서 지속적인 트래픽이 발생하는지 의심된다면 먼저 해당 페이지와 관련 앱을 닫고 비슷한 요청이 계속되는지 확인한 다음, 페이지를 단독으로 열어 새 기록을 비교하세요. 테스트 중에는 서버, Global Routing 및 네트워크 유형을 그대로 유지해 다른 요인을 줄이세요. 페이지를 닫은 뒤에도 트래픽이 계속된다면 백그라운드 작업이나 즉시 종료되지 않은 장시간 연결일 수 있습니다. 앱 동작이 비정상이라고 바로 판단하지 마세요. 모든 데이터를 지우고 다시 추측하기보다 잠시 기다린 뒤 반복해서 관찰하는 편이 유용한 단서를 보존하기 쉽습니다.

규칙이 적용되지 않는다고 의심되면 변경 후 새로 만들어진 요청을 관찰하고 있는지 먼저 확인하세요. 이미 연결된 요청은 이전 경로를 계속 사용할 수 있어 Data에 서로 다른 시점의 결과가 함께 표시될 수 있습니다. 확인할 페이지의 연결을 종료한 뒤 같은 방법으로 다시 접속하고, 영향을 이해한 경우 클라이언트 연결을 새로 설정하세요. 비교할 때 이전 기록과 새 기록을 구분하세요. 목록에 이전 정책이 남아 있다는 이유만으로 저장한 규칙이 전혀 작동하지 않는다고 단정하지 마세요.

트래픽이 갑자기 증가하면 먼저 사진 동기화, 미디어 재생, 앱 업데이트 등 실제 사용을 확인한 뒤 실패 요청이 반복되는지 살펴보세요. 같은 대상에서 오류가 계속 나타난다면 콘텐츠를 성공적으로 많이 다운로드한 것이 아니라 앱이 재시도하고 있을 수 있습니다. 실패 시간과 오류 유형을 확인하고 연결 장으로 돌아가 원인을 파악하세요. 모든 이상을 서버 속도 문제로 돌리지 말고 짧은 관찰 한 번만으로 전체 구성을 조정하지 마세요. 어떤 요청이 어떤 조건에서 달라졌는지 먼저 확인해야 합니다.

유용한 기록은 보관하고 민감한 내용의 외부 공유는 줄이기

진단 정보를 보관할 때는 발생 시간, 모드, 대상 유형 및 오류 요약을 기록하면 일상적인 유지 관리에 충분한 경우가 많습니다. 도메인, 요청 경로 및 접속 시간도 개인 정보와 관련될 수 있으므로 스크린샷을 공유하기 전에 구독 주소, 인증 매개변수 또는 비공개 접속 내용이 보이는지 확인하세요. 문제를 설명하는 자료에는 필요한 내용만 남기세요. 기술 로그라는 이유만으로 민감한 정보가 없다고 가정해서는 안 됩니다.

기록을 삭제하기 전에 현재 문제를 확인하는 데 필요한 최소한의 증거를 저장하고 화면에서 삭제 작업이 적용되는 범위를 확인하세요. 진단 기록을 지워도 서버가 삭제되는 것은 아니며, 항목을 삭제해도 시스템 권한이 초기화되는 것은 아닙니다. 작업 전에 대상을 확인하세요. Data는 검증과 비교에 가장 적합합니다. “예상한 작동 방식”과 “실제로 발생한 결과”를 연결해 줍니다. 서비스 상태 확인을 대신할 수 없으며 요약 수치 하나만으로 모든 요청이 같은 경로를 사용했다고 입증할 수도 없습니다.

07 / 자주 쓰는 항목 조정

Settings, DNS 및 On Demand

설정이 적용되는 범위부터 구분

Settings를 조정하기 전에 문제가 앱 수준 동작, 현재 Config, 개별 서버 매개변수 또는 시스템 네트워크 권한 중 어느 것과 관련됐는지 확인하세요. 이름이 비슷한 옵션도 서로 다른 단계에 있을 수 있으므로 키워드만 보고 같은 기능을 제어한다고 생각하면 안 됩니다. 예를 들어 서버의 TLS 항목은 해당 서버 연결에 영향을 주고, 구성의 DNS 조건은 이름 확인 경로에 영향을 주며, On Demand는 자동 실행을 관리합니다. 현재 인터페이스와 활성 구성이 실제 동작을 결정하므로 변경 전에 원래 위치와 값을 기록해 잘못된 단계에서 반복적으로 설정을 바꾸지 않도록 하세요.

안정적으로 작동하는 구성은 수동 연결 단계를 줄이거나, 특정 도메인의 DNS 확인 실패를 해결하거나, 특정 네트워크에서 동작을 확인하는 등 분명한 목표에 따라 조정하세요. 온라인에서 찾은 설정 조합을 보편적인 최적값으로 간주하지 마세요. 서버 조건, 네트워크 환경 및 규칙의 목적은 다를 수 있습니다. 인터페이스의 옵션이 안내 자료와 다르면 현재 앱 화면을 기준으로 하세요. 용도를 모르는 항목은 원래 값으로 유지하고 영향 범위를 이해할 수 있도록 작은 범위에서 테스트한 다음 적용 여부를 결정하세요.

DNS: 확인 결과는 이후 연결과 규칙 매칭에 영향을 줌

DNS는 도메인 이름을 IP 주소로 변환하지만 주소를 얻었다는 것만으로 문제가 해결된 것은 아닙니다. DNS 요청이 어떤 경로로 전송되는지, 반환된 결과가 현재 네트워크에 적합한지, 이후 요청이 어떻게 연결되는지가 접속 결과에 영향을 줄 수 있습니다. 시스템 DNS, 사용자 지정 DNS 및 DNS over HTTPS의 차이는 우선 DNS 요청을 어떻게 보내고 누가 응답하는지에 있습니다. 이름만으로 어떤 방식이 반드시 더 빠르다고 판단하지 마세요. 사용자 지정 DNS를 추가하기 전에 기존 문제가 DNS 확인 실패인지, 확인 후 연결 실패인지 파악해야 합니다.

DNS over HTTPS를 사용하려면 해당 DNS 엔드포인트에 접속할 수 있어야 합니다. 엔드포인트 접속에 아직 정상 작동하지 않는 프록시 경로가 필요하면 시작 단계에서 의존성 문제가 생길 수 있습니다. 서버 주소가 도메인 이름인 경우에도 연결을 설정하려면 사용 가능한 DNS 확인 결과가 필요합니다. 변경 후 서버 연결과 대상 도메인 접속을 각각 테스트하세요. 캐시된 페이지 하나만 열어 보고 모든 문제가 해결됐다고 판단하지 마세요. 변경이 도움이 되지 않으면 원래 설정으로 되돌린 다음 다른 단계를 확인하세요.

DNS 결과는 IP-CIDR 및 GEOIP와 같은 주소 기반 규칙에도 영향을 줄 수 있지만 도메인 규칙과 주소 규칙의 사용 조건은 서로 다릅니다. 웹사이트 하나가 여러 주소를 반환할 수 있고 요청마다 서로 다른 DNS 결과를 사용할 수도 있으므로 한 번의 확인 결과가 전체 트래픽을 대표하지는 않습니다. 구체적인 선택 및 확인 방법은 DNS 설정 안내를 참고하세요. 문제를 확인할 때 변경 전후의 대상, DNS 결과 및 접속 상태를 기록해 캐시 변화와 설정 개선을 혼동하지 않도록 하세요.

On Demand: 수동 연결이 정상인 뒤 자동 실행 설정

On Demand는 설정한 조건에 따라 연결을 자동으로 시작하는 기능이지 잘못된 서버 매개변수를 수정하는 기능은 아닙니다. 사용하기 전에 수동 연결, 연결 종료 및 재연결이 모두 정상적으로 작동하는지 확인한 뒤 자동 실행 조건을 하나씩 설정하세요. 현재 화면에서 네트워크 환경별 규칙을 설정할 수 있다면 해당 환경에 진입하거나 벗어날 때 또는 환경을 전환할 때 어떻게 작동하는지 각각 테스트하세요. 한 번에 조건 유형 하나만 추가하고 예상한 시점에 연결이 시작되는지 관찰하세요. 여러 조건이 겹쳐 자동 재연결의 원인을 알기 어려워지는 일을 막을 수 있습니다.

기능을 켠 뒤 수동으로 연결을 종료해도 곧 다시 시작된다면 자동 실행 조건이 여전히 충족되는 것일 수 있습니다. VPN 구성을 반복해서 삭제하기보다 On Demand 설정을 먼저 확인하세요. 직접 연결 상태를 기준으로 테스트해야 한다면 자동 실행 조건을 잠시 중지한 다음 연결을 종료하세요. 그렇지 않으면 테스트 중 연결이 자동으로 다시 시작될 수 있습니다. 문제 해결이 끝나면 원래 조건을 복원하고 일상적으로 필요한 연결 동작에 영향을 주지 않는지 확인하세요. 자동화 설정은 확인된 절차를 확장하는 기능이어야 하며 불안정한 연결을 숨기는 방법이 아닙니다.

고급 옵션은 신중하게 검증

로컬 네트워크 리소스, UDP 서비스 또는 특정 전송 방식에 문제가 있다면 관련 설정을 찾기 전에 서버와 현재 프로토콜이 해당 기능을 지원하는지 확인하세요. 옵션 하나를 켠다고 서버에 원래 없던 기능이 추가되지는 않습니다. 일반 웹페이지 문제를 해결하려고 여러 하위 설정을 한꺼번에 조정하지도 마세요. 변수가 늘어나 처음의 문제를 재현하기 어려워집니다. 기존 구성에 특수 DNS 또는 경로 설정이 있다면 먼저 목적을 파악하고 원본을 보관한 다음 복사본에서 테스트하세요.

연결이 작동하기 시작한 뒤에는 설정을 계속 추가하기보다 구성을 이해할 수 있고 변경 사항을 되돌릴 수 있는지 확인하는 것이 중요합니다. 서버, Config 및 앱 수준 설정의 경계를 유지하면 네트워크가 바뀌어도 실제로 관련된 단계만 조정할 수 있습니다. 일상적으로 사용하기 전에 Global Routing과 On Demand의 최종 상태를 확인해 테스트 설정이 기기에 남지 않도록 하세요. 다음 장에서는 이러한 확인을 반복 가능한 유지 관리 절차로 정리합니다.

08 / 설정 복구 가능하게 유지

백업, 업데이트 및 유지 관리

서로 다른 항목을 각각 백업

앱, 서버 항목, 구독 주소, Config 및 시스템 권한은 서로 다른 항목이므로 하나만 저장해도 전체 환경을 복구할 수 있다고 가정하지 마세요. 관리 작업 전에 필요한 내용을 정리하세요. 구독으로 생성된 항목과 수동으로 추가한 항목, 현재 활성화된 구성 및 직접 수정한 규칙이 있는지 확인합니다. 현재 인터페이스에서 저장 또는 내보내기를 사용할 때 실제로 무엇이 포함되는지 확인하세요. 일부 내용만 저장할 수 있다면 필요한 정보를 따로 보관하세요. 파일 이름만으로 전체 복구가 가능하다고 판단하지 마세요.

백업 파일에는 서버 인증 정보나 구독 자격 증명이 포함될 수 있으므로 본인 또는 명확히 권한을 받은 사람만 접근할 수 있는 위치에 보관하세요. 공개 메모, 공유 앨범 및 공개된 파일 디렉터리는 원본 정보를 보관하기에 적합하지 않습니다. 쉽게 구분할 수 있도록 개인 기록에 용도, 출처 및 로컬 관리 날짜를 적을 수 있지만 비밀번호를 파일 이름에 직접 넣지 마세요. 백업의 유용성은 저장 버튼을 눌렀는지가 아니라 필요한 항목을 이해하고 복원할 수 있는지로 판단해야 합니다.

변경 전 복사하고 변경 후 결과 기록

Config를 편집하기 전에 현재 정상 작동하는 복사본을 보관하고 이번에 해결하려는 문제를 적어 두세요. 한 번의 변경은 도메인 규칙 하나 추가와 같이 같은 목적에만 적용하세요. 전체 규칙 순서를 바꾸거나 DNS를 교체하고 서버까지 함께 바꾸지 마세요. 저장한 뒤 새 복사본이 활성화되어 있는지 확인하고 연결 장의 방법에 따라 새 요청을 보내세요. 결과가 예상과 다르면 이전 구성으로 전환해 다시 테스트하세요. 같은 조건에서 이전 복사본은 정상이라면 외부 네트워크보다 이번 변경을 우선 확인할 근거가 됩니다.

관리 기록은 복잡할 필요가 없습니다. 문제, 원래 값, 변경 위치, 테스트 대상 및 결과를 순서대로 적으면 됩니다. 규칙은 예상 정책과 실제로 관찰한 결과를 기록하세요. 서버 매개변수는 다시 확인할 출처를 적되 공개될 수 있는 문서에 정보를 저장하지 마세요. 이렇게 하면 다음에 같은 현상이 생겼을 때 이미 검증한 해결 방법을 확인할 수 있습니다. 기록이 쌓이면 우연히 한 번 복구된 경우와 같은 조건에서 반복해서 해결되는 변경을 구분할 수 있어 불필요한 시행착오가 줄어듭니다.

앱 업데이트와 구독 업데이트는 따로 진행

Shadowrocket 앱 업데이트는 App Store에서 진행하며 현재 버전 정보와 업데이트 내용은 스토어 페이지를 기준으로 합니다. Subscribe 업데이트는 사용자가 보유한 기존 구독의 내용을 다시 가져오는 작업입니다. 두 작업은 서로 다릅니다. 문제를 쉽게 파악하려면 한 번의 테스트에서 앱 업데이트, 구독 업데이트 및 전체 구성 교체를 동시에 하지 마세요. 업데이트한 뒤 기존 연결과 자주 쓰는 대상이 정상인지 확인한 다음 다른 변경을 진행하세요. 인터페이스 위치가 달라졌다면 해당 항목을 찾아 확인하고 항목이 뒤섞이지 않도록 즉시 다시 가져오지 마세요.

구독 업데이트 후에는 전에 선택했던 서버가 아직 있는지, 이름이나 그룹이 바뀌었는지, 수동 변경 내용이 덮어쓰였는지 확인하세요. 이전 항목이 사라졌다면 구독 서버의 내용이 변경된 것일 수 있으며 로컬 저장에 실패했다는 뜻은 아닙니다. 먼저 업데이트 결과와 항목의 출처를 확인한 뒤 다시 서버를 선택할지 결정하세요. 업데이트에 실패했지만 이전 목록이 남아 있다면 테스트에서 사용 중인 데이터가 이전에 저장된 내용인지 확인해야 합니다. 기존 항목에 연결됐다고 이번 업데이트가 성공한 것으로 판단해서는 안 됩니다.

기기 교체 또는 재설치 후 복구 순서

기기를 교체할 때는 먼저 App Store에서 앱 구매 기록과 호환성을 확인한 뒤 본인이 보유한 서버와 Config를 복구하고 시스템 권한 및 자동 실행 조건을 다시 확인하세요. 앱을 다시 받을 수 있다고 로컬 항목까지 자동으로 나타나는 것은 아닙니다. 시스템 네트워크 권한도 새 기기에 표시되는 안내에 따라 설정해야 합니다. 복구 후 명확한 항목 하나를 선택해 수동으로 테스트하고 규칙과 DNS를 확인한 다음 On Demand를 설정하세요. 이 순서를 따르면 구성이 유효한지 확인하기도 전에 자동 연결이 반복 실행되는 일을 막을 수 있습니다.

복구 후 중복 항목이 보여도 즉시 모두 삭제하지 마세요. 백업에서 복원된 항목과 구독을 다시 가져오면서 생성된 항목을 구분한 뒤 보관할 출처를 선택하세요. 구독 그룹을 삭제하기 전에 해당 그룹이 관리하는 항목까지 함께 제거되는지 확인해야 합니다. 여러 항목에 영향을 주는 정리 작업은 복구에 필요한 정보를 먼저 보관한 다음 단계적으로 진행하세요. 구매 복원 방법은 구매 항목 복원 안내를 참고하세요. 구매 기록과 설정 백업의 역할은 서로 다르므로 대체할 수 없습니다.

간단하고 일관된 일상 점검 절차 만들기

일상적인 문제가 발생하면 정해진 순서로 확인하세요. 현재 네트워크가 정상인지, 서버가 올바르게 선택됐는지, Global Routing이 용도에 맞는지, 예상한 Config 복사본이 활성화됐는지, 최근 구독 업데이트가 성공했는지 살펴봅니다. 그다음 DNS, 규칙 및 개별 요청을 자세히 확인하세요. 더 이상 사용하지 않는 테스트 항목은 출처를 확인한 뒤 정리하고 계속 사용할 구성은 알기 쉬운 이름으로 보관하세요. 문제 해결이 끝나면 임시 설정을 복원하고 자주 쓰는 대상에 다시 접속해 보세요. 하나의 상황을 해결한 뒤 새로운 경로 문제가 남지 않도록 하기 위한 절차입니다.

처음 사용할 때는 빠른 시작으로 돌아가 기본 순서에 따라 진행할 수 있습니다. 상황을 이해하려면 이 페이지의 목차에서 해당 단계를 찾아보세요. 전체 유지 관리 절차의 목표는 모든 변경의 출처를 파악하고, 각 테스트의 범위를 명확히 하며, 모든 수정 사항을 되돌릴 수 있게 하는 것입니다. 한 번 연결에 성공했다고 모든 상황에서 계속 작동한다고 여기지 마세요. 안정적으로 사용하는 중이라면 전체 구성을 자주 다시 만들 필요도 없습니다. 필요한 기록을 보관하고 단계별로 확인하면 설정을 계속 추가하는 것보다 명확하고 재현 가능한 결과를 얻기 쉽습니다.