Add Server 및 구독 가져오기
Shadowrocket을 열고 먼저 Home으로 이동합니다. 가져오기의 목적은 본인의 서버 정보가 목록에 표시되도록 하는 것이며, 바로 연결 스위치를 켜는 것이 아닙니다. 먼저 보유한 정보의 유형을 확인하세요. 구독 링크는 보통 여러 서버 항목을 가져올 때 사용하고, 개별 서버 정보에는 프로토콜, 주소, 포트, 인증 정보가 포함됩니다. 둘 중 한 가지 방법만 사용하면 되며, 가이드를 따라 하기 위해 같은 정보를 중복으로 추가할 필요는 없습니다.
구독 링크가 있는 경우: Subscribe 사용
Home 오른쪽 위의 추가 버튼을 눌러 Add Server로 이동합니다. Type에서 Subscribe를 선택하고 본인의 전체 구독 주소를 URL에 입력합니다. 나중에 알아보기 쉽도록 용도를 설명하는 메모를 입력한 뒤 저장하고 Home으로 돌아갑니다. 붙여넣기 전후에 주소가 완전한지 확인하세요. 특히 끝부분의 매개변수가 빠지지 않았는지, 앞뒤에 공백이 붙지 않았는지, 웹페이지 제목이나 안내 문구까지 함께 복사하지 않았는지 살펴봅니다.
저장한 뒤 구독 그룹과 그 안의 서버 항목을 확인합니다. 구독은 원격 콘텐츠를 가져와 해석해야 하므로 구독 이름이 표시되는 것과 서버 목록이 생성되는 것은 서로 다른 결과입니다. 그룹만 있고 항목이 없다면 먼저 해당 구독 항목의 업데이트 기능을 사용하고, 요청이 끝날 때까지 기다린 다음 목록을 확인하세요. 같은 링크를 반복해서 추가하지 마세요. 그룹만 구분하기 어려워질 뿐, 주소가 만료되었거나 예상과 다른 내용이 반환되는 문제는 해결되지 않습니다.
구독 주소에는 개인 접근 정보가 포함될 수 있으므로 민감한 정보로 취급하세요. 내용을 확인해야 한다면 먼저 본인의 서비스 제공업체에 주소가 유효한지, Shadowrocket에서 사용할 수 있는지, 추가 조건이 있는지 문의하세요. 전체 주소를 공개 댓글, 스크린샷 설명, 문제 해결 기록에 올리지 마세요. 문제를 기록할 때는 오류 메시지와 발생 위치만 남기면 됩니다.
개별 서버 정보가 있는 경우: Type 및 매개변수 확인
개별 서버 정보를 받은 경우에도 Add Server에서 시작하되, Type은 제공된 프로토콜에 맞게 선택합니다. 예를 들어 Shadowsocks, VMess, VLESS 또는 Trojan을 선택할 수 있습니다. 화면에 표시되는 주소, 포트, 해당 인증 정보를 입력하세요. 프로토콜마다 필요한 항목이 다르므로 한 프로토콜의 비밀번호, UUID, 전송 매개변수를 다른 프로토콜의 양식에 그대로 입력하면 안 됩니다.
TLS, Server Name 또는 기타 전송 설정은 보유한 정보에 따라 입력하고 서버 주소만 보고 임의로 추측하지 마세요. 주소는 도메인일 수도 있고 IP일 수도 있습니다. 포트는 별도 항목이므로 안내 문구 전체를 붙여넣지 마세요. 입력을 마치면 저장한 뒤 Home으로 돌아와 사용할 항목을 선택합니다. 이 단계에서는 항목이 존재하고 원본 정보와 일치하는지만 확인하고, 접속 여부는 다음 연결 확인 단계에서 점검합니다.
Global Routing 방식 선택
서버를 선택한 다음 Home에서 Global Routing을 찾아 엽니다. 여기서는 요청 전반의 처리 방식을 정하며, 서버 목록을 다른 이름으로 부르는 것이 아닙니다. 처음 사용할 때는 서버를 선택하면 모든 요청이 반드시 그 서버를 거칠 것이라고 오해하기 쉽습니다. 실제 동작은 여기서 선택한 방식과 Config에서 활성화한 규칙에 따라서도 달라집니다.
Config: 활성화된 규칙에 따라 처리
Config를 선택하면 현재 구성의 규칙에 따라 요청에 사용할 정책이 결정됩니다. 이어서 Config 화면으로 이동해 어떤 구성이 활성화되어 있는지 확인하고, 규칙과 정책 참조를 살펴봅니다. 서버를 가져왔다고 관련 구성이 함께 가져와지거나 활성화된 것은 아닙니다. 구독은 서버 항목을 제공하고 구성 파일은 규칙과 기타 설정을 정의하므로 각각 확인해야 합니다.
직접 확인한 구성이 있다면 활성화한 다음 Config를 선택해 일상적으로 사용할 수 있습니다. 규칙은 일반적으로 구성에 적힌 순서대로 매칭되므로, 앞쪽의 범위가 넓은 규칙이 뒤쪽의 구체적인 규칙보다 먼저 적용될 수 있습니다. 마지막에 매칭되지 않은 요청을 어떻게 처리하는지는 끝부분의 규칙도 확인해야 합니다. DOMAIN-SUFFIX 규칙이 파일에 있다는 사실만으로 실제 요청이 반드시 해당 규칙에 매칭된다고 단정하지 마세요. 규칙 키워드의 자세한 설명은 용어집에서 확인할 수 있습니다. 우선 활성화된 구성과 예상한 구성이 일치하는지 확인하세요.
Proxy: 전체 프록시 및 비교 점검
Proxy를 선택하면 Config의 규칙별 분기 대신 해당 방식에 따라 요청을 선택한 프록시로 처리합니다. 문제를 좁힐 때 명확한 비교 조건으로 활용할 수 있습니다. 같은 서버가 Proxy에서는 작동하지만 Config에서는 특정 대상에 접속할 수 없다면 구성의 매칭, 정책 참조, 관련 설정을 먼저 확인하세요. 바로 서버가 작동하지 않는다고 판단해서는 안 됩니다.
이 비교는 원인을 좁히기 위한 방법일 뿐, Proxy가 모든 일상적인 상황에 Config보다 적합하다는 뜻은 아닙니다. 전환하면 요청 처리 방식이 달라지므로 테스트가 끝난 뒤 필요한 방식으로 되돌리세요. 접속 결과는 도메인 해석, 대상 서비스 자체, 앱 캐시의 영향도 받을 수 있으므로 한 번의 비교 결과만으로 판단하지 말고 다른 점검 결과와 함께 확인하세요.
Direct: 요청을 직접 접속
Direct를 선택하면 요청은 직접 접속 방식으로 처리됩니다. Home에서 서버를 선택한 상태라도 해당 서버가 요청을 처리하고 있다고 볼 수 없습니다. Direct는 기본 네트워크가 정상인지 확인하는 데 사용할 수 있지만, 직접 접속에 성공했다는 사실은 현재 네트워크에서 해당 대상에 접속할 수 있다는 의미일 뿐입니다. 프록시 연결이나 규칙 분기가 작동한다는 증거는 아닙니다.
이 단계를 마친 뒤 현재 선택한 방식을 기억해 두세요. 이후 확인은 현재 방식이 무엇인지 분명히 알고 진행해야 합니다. 문제 해결을 위해 임시로 전환했다면 원래 선택을 기록해 두고, 테스트가 끝난 뒤 임시 설정을 일상 설정으로 착각하지 않도록 되돌리세요.
연결 스위치 켜기
Home으로 돌아가 선택한 서버, Global Routing 방식, Config를 사용하는 경우 활성화된 구성 파일을 차례로 확인합니다. 이 항목을 확인한 다음 기본 연결 스위치를 켭니다. 구성을 전환하거나 구독 업데이트가 끝나지 않았거나 매개변수를 저장하지 않은 상태에서 연결을 반복해서 켜고 끄지 마세요. 현재 테스트에 어떤 설정이 적용되었는지 판단하기 어려워집니다.
처음 연결할 때 시스템에서 VPN 구성을 추가하라는 안내가 표시될 수 있습니다. 이는 Shadowrocket이 시스템 네트워크 처리를 이용하는 데 필요한 권한 절차이며, 앱이 사용할 수 있는 연결 서비스를 자동으로 얻었다는 뜻은 아닙니다. 안내를 읽고 계속 진행해도 괜찮다면 시스템 안내에 따라 허용하고 기기에서 요구하는 인증을 완료하세요. 그런 다음 Shadowrocket으로 돌아와 스위치와 앱에 표시되는 연결 상태를 확인합니다.
권한 요청을 취소했다면 앱으로 돌아가 연결을 다시 시작하고 실제로 표시되는 안내에 따라 진행하세요. 기기가 관리 대상이거나 시스템 설정에 제한이 있다면 해당 제한을 확인합니다. 승인 여부를 확인하는 대신 버튼을 반복해서 누르지 마세요. 시스템 설정의 VPN 항목 이름과 위치는 화면 구성에 따라 달라질 수 있으므로 기기에 현재 표시되는 내용을 기준으로 찾으세요. 이 가이드와 관련 없는 설정까지 변경할 필요는 없습니다.
연결이 설정되면 시스템에 VPN 표시가 나타날 수 있습니다. 이 표시는 시스템 네트워크 연결 상태를 뜻할 뿐, 실제 접속으로 원격 서버를 확인했다거나 모든 요청이 프록시를 거친다는 뜻은 아닙니다. 특히 Config 또는 Direct에서는 VPN 표시만으로 트래픽 분기가 올바르다고 판단할 수 없습니다. 현재 설정을 유지한 채 다음 확인 단계로 진행하세요. 스위치가 켜졌다는 이유만으로 점검을 끝내지 마세요.
연결 및 규칙 확인
확인은 세 가지 질문으로 나누어 진행합니다. 서버가 테스트에 응답하는지, 필요한 서비스를 정상적으로 사용할 수 있는지, 요청이 예상한 정책에 따라 처리되는지 확인하세요. 세 결과는 서로 관련되어 있지만 서로를 대신할 수는 없습니다. 아래 순서대로 점검하면 기본 네트워크, 대상 서비스, 규칙 문제를 혼동하지 않을 수 있습니다.
먼저 Connectivity Test 실행
Home에서 Connectivity Test를 실행하고 현재 선택한 서버의 테스트 결과를 확인합니다. 이 기능은 테스트 경로에 연결할 수 있는지 초기 판단하는 데 도움이 됩니다. 다만 테스트의 대상과 방식은 앱에서 실제로 발생하는 모든 요청과 같지 않습니다. 테스트에 성공해도 모든 웹사이트나 앱이 작동한다고 보장할 수 없으며, 실패한 경우에도 테스트 방식, 현재 네트워크, 서버 정보와 함께 점검해야 합니다.
결과를 기록할 때는 성공 여부나 오류 표시만 적으면 됩니다. 테스트에 걸린 시간만으로 서비스 품질을 판단하지 마세요. 모든 항목이 실패한다면 먼저 기기의 기본 네트워크로 접속할 수 있는지 확인한 뒤 구독과 연결 매개변수를 점검합니다. 한 항목만 실패한다면 해당 항목의 매개변수와 서버 상태부터 확인하세요.
다음으로 실제 접속 확인
연결을 켠 상태로 브라우저를 열어 실제로 이용하려는 서비스에 접속하고 페이지가 로드되는지, 필요한 작업을 수행할 수 있는지 확인합니다. 이미 열려 있던 페이지를 확인하는 대신 새 요청을 보내세요. 페이지 캐시 때문에 새로운 네트워크 요청 없이도 접속된 것처럼 보일 수 있습니다. 특정 앱에서만 실패한다면 앱 자체의 로그인, 권한 또는 서비스 상태 문제인지도 구분해야 합니다.
전후 결과를 비교해야 한다면 같은 기기, 같은 네트워크, 같은 대상을 사용하고 연결 상태나 라우팅 방식 중 한 번에 한 가지만 바꾸세요. 네트워크와 서버를 바꾸면서 규칙까지 수정하면 비교가 의미 없어집니다. 접속에 성공한 뒤에는 트래픽 분기가 의도한 대로인지도 확인해야 합니다. 페이지가 열린 것은 서비스를 사용할 수 있다는 증거이지, 예상한 정책에 매칭되었다는 완전한 증거는 아닙니다.
마지막으로 Data 및 매칭 정책 확인
Data로 이동해 현재 표시되는 요청 정보를 확인하고 요청 대상, 시간, 정책을 바탕으로 이번 접속이 어떤 경로로 처리되었는지 살펴봅니다. 표시되는 정보는 앱이 현재 제공하는 기록을 기준으로 확인하세요. 방금 보낸 요청을 찾아 Config의 규칙과 대조합니다. 해당 기록이 없다면 규칙을 즉시 수정하지 말고 요청을 새로 보냈는지부터 확인하세요.
DIRECT로 처리될 것으로 예상한 대상은 실제로 해당 정책이 사용되었는지 확인합니다. PROXY로 처리될 것으로 예상한 대상은 현재 서버와 정책 참조를 함께 점검하세요. REJECT는 매칭된 요청을 차단한다는 뜻이며 앱에서 비슷한 콘텐츠가 모두 사라진다는 보장은 없습니다. 규칙이 정상적인 기능에 영향을 준다면 해당 요청과 매칭된 항목을 확인한 뒤 범위를 최소화해 수정하세요. 구성 파일 전체를 삭제하지 마세요.
요청 기록에는 도메인 등 개인 사용 정보가 포함될 수 있습니다. 문제 해결 자료를 저장할 때는 원인을 파악하는 데 꼭 필요한 정보만 남기고, 공유하기 전에 개인 인증 정보와 관련 없는 요청을 삭제하세요. 세 가지 확인을 마친 뒤에는 실제 서비스가 작동하고, 라우팅 방식이 목적에 맞으며, 대표 요청에 적용된 정책이 예상과 일치해야 합니다.
자주 발생하는 문제 해결
문제가 생기면 오류가 발생한 단계부터 점검하고 모든 정보를 처음부터 삭제하지 마세요. 아래에 작업 순서에 따른 확인 방법을 정리했습니다. 항목을 하나 변경할 때마다 다시 테스트하고 이전에 작동했던 설정을 보존하세요. 그래야 어떤 변경이 결과에 영향을 주었는지 알 수 있습니다.
구독을 저장했지만 목록이 비어 있음
구독 항목으로 돌아가 URL이 완전한지, 로그인해야 하는 안내 페이지가 아니라 구독 콘텐츠 주소인지 확인합니다. 그런 다음 한 번 업데이트하고 앱에 표시되는 안내를 기록하세요. 웹페이지나 접속 오류, 예상과 다른 내용이 반환되면 목록이 생성되지 않을 수 있습니다. 이 경우 Subscribe를 임의로 서버 프로토콜로 바꾸지 말고 본인의 서비스 제공업체에 주소 유효성과 반환 형식을 문의하세요.
업데이트 실패와 기존 항목이 사라지는 것은 서로 다른 문제입니다. 기존 항목이 남아 있다면 그대로 보존하고 실패한 시점을 기록하세요. 다시 시도하려고 모든 내용을 바로 지우지 마세요. 구독 내용이 바뀐 뒤에는 현재 선택된 항목이 여전히 사용할 항목인지도 확인해야 합니다. 그룹 이름이 그대로라는 이유만으로 판단하지 마세요.
서버 항목은 있지만 테스트에 실패함
먼저 기기의 현재 네트워크가 정상인지 확인한 다음 Type, 주소, 포트, 인증 항목이 원본 정보와 일치하는지 점검합니다. 정보에 특정 TLS 또는 전송 매개변수가 지정되어 있다면 항목별로 확인하세요. 모든 스위치를 반복해서 전환하며 해결을 기대하지 마세요. 명확한 매개변수 오류가 여러 미확인 변수로 바뀔 수 있습니다.
사용할 수 있는 다른 기존 항목이 있다면 하나를 선택해 비교해 보세요. 같은 항목이 특정 네트워크에서만 실패한다면 네트워크 환경과 오류 메시지를 기록하고 네트워크 제한이나 이름 해석 차이가 있는지 확인합니다. Connectivity Test의 한 번의 결과는 단서일 뿐이며 최종적으로는 실제 서비스 접속도 확인해야 합니다.
연결 스위치는 켜져 있지만 대상에 접속할 수 없음
먼저 시스템 권한 승인이 완료되었는지, 앱 연결이 바로 끊기지 않았는지 확인한 다음 Global Routing이 테스트에 필요한 방식으로 설정되어 있는지 살펴봅니다. Direct라면 서버를 선택했더라도 요청이 서버를 거친다는 의미가 아닙니다. Config라면 이름이 같은 파일의 내용만 확인하지 말고 실제로 활성화된 구성을 점검하세요. 필요하면 Proxy로 잠시 비교 테스트한 뒤 원래 방식으로 되돌립니다.
Proxy에서는 작동하지만 Config에서는 작동하지 않는다면 규칙 순서, 정책 참조, 대상과 관련된 설정을 중점적으로 확인하세요. 둘 다 실패한다면 서버, 기본 네트워크, 대상 서비스 자체를 다시 점검합니다. VPN 표시가 나타난다는 이유만으로 이러한 요인을 배제하지 마세요.
업데이트 후 동작이 달라지거나 연결 해제 후에도 변화가 있음
구독 업데이트는 서버 항목을 바꿀 수 있고 구성 업데이트는 규칙을 바꿀 수 있으므로 각각 기록해야 합니다. 먼저 어떤 항목이 업데이트되었는지 확인한 뒤 현재 선택이 이전과 같은지 살펴봅니다. 수동으로 연결을 해제한 뒤 다시 연결되면 On Demand 활성화 상태와 트리거 조건을 확인하세요. 페이지 표시만 바뀌지 않는다면 새 요청을 보내고 캐시를 확인합니다. 이전 페이지의 내용을 새 연결 결과로 판단하지 마세요.
문제를 계속 확인하려면 네 가지 정보만 정리하면 됩니다. 실패한 단계, 현재 Global Routing 방식, 특정 대상에만 발생하는지 여부, 방금 변경한 한 가지 항목입니다. 전체 구독 주소, 비밀번호, 기타 인증 정보는 포함하지 마세요. 구매, App Store 지역, 구입 항목 복원 문제는 App Store 구매 및 설치 안내에서 확인할 수 있습니다. 프로토콜과 규칙 키워드에 대한 자세한 설명은 용어집을 참고하세요. 첫 연결을 완료하기 위해 모든 설정을 한꺼번에 바꿀 필요는 없습니다.