Shadowrocket 사용법
구독 가져오기 및 연결 확인
iPhone / iPad 화면을 기준으로 정보를 추가하고 모드를 선택한 뒤 연결을 켜고 요청을 확인하며 문제 지점을 점검합니다. 먼저 연결을 확인한 다음 규칙을 조정하세요.
기존 구성은 보존하고 한꺼번에 수정하지 않는 것이 좋습니다. 확인 대상으로 자주 사용하는 페이지 주소를 준비하세요. 문제가 발생하면 어느 단계에서 멈췄는지와 표시된 안내를 기록하면 반복해서 재설치하는 것보다 원인을 찾기 쉽습니다. 버전에 따라 화면 배치가 조금 다를 수 있으므로 영어 UI 용어를 기준으로 해당 메뉴를 찾으세요.
Add Server: 서버 추가 또는 Subscribe 가져오기
먼저 받은 정보의 유형을 확인하세요. 구독 링크, 단일 서버 매개변수 및 구성 파일은 서로 다른 입력입니다.
Shadowrocket을 열고 Home 아래의 SERVER 그룹에서 Add Server를 누릅니다. 추가 화면에서 먼저 Type을 확인하세요. 이후 입력할 필드가 Type에 따라 달라집니다. 오른쪽 공식 스크린샷은 한 가지 서버 유형을 보여 줍니다. Type을 변경하면 표시되는 필드가 달라지는 것은 정상이며, 스크린샷의 필드 조합을 모든 프로토콜에 공통으로 적용되는 입력 양식으로 보면 안 됩니다.
기존 구독 링크: Subscribe 선택
받은 정보가 구독 주소라면 Type에서 Subscribe를 선택하고 전체 주소를 URL 필드에 붙여 넣은 다음 알아보기 쉬운 메모를 입력합니다. 붙여 넣은 뒤 처음부터 끝까지 확인하세요. 앞부분의 프로토콜, 경로, 물음표 뒤의 매개변수를 모두 유지하고 줄바꿈, 따옴표 또는 설명 문구가 함께 들어가지 않도록 합니다. 예시 https://example.com/sub?token=xxxx는 형식을 설명하기 위한 것이며 실제 구독 링크가 아니므로 열 필요가 없습니다.
저장한 뒤 Home으로 돌아가 구독을 가져올 때까지 기다린 다음 그룹에 서버 항목이 표시되는지 확인합니다. 저장 성공은 앱이 주소를 기억했다는 뜻일 뿐 원격 콘텐츠 다운로드가 성공했다는 뜻은 아닙니다. 그룹이 비어 있다면 먼저 구독 가져오기 안내를 확인한 뒤 주소의 만료 여부, 추가 인증 필요 여부 및 현재 네트워크에서 주소에 접근할 수 있는지 확인하세요. 일반 웹페이지 주소를 구독 주소 대신 넣어 테스트하지 마세요. 웹페이지 콘텐츠는 서버 목록과 다릅니다.
기존 단일 서버 정보: Type에 맞춰 입력
받은 정보가 단일 서버 정보라면 Shadowsocks 또는 Trojan처럼 정보와 일치하는 프로토콜을 먼저 선택한 다음 Host와 Port를 입력합니다. Host에는 일반적으로 호스트 이름이나 IP만 입력하고 웹 경로는 추가하지 않습니다. Port에는 제공된 포트를 입력합니다. 이어서 해당 유형에서 요구하는 Password, Method, UUID 또는 TLS 관련 필드를 확인하세요. 일부 필드는 특정 프로토콜에서만 사용되므로 이름이 비슷하다는 이유로 서로 바꾸어 입력하면 안 됩니다.
직접 입력하면 비밀번호에 공백이나 줄바꿈이 포함될 수 있으므로 복사한 뒤 앞뒤를 확인하세요. 정보에 QR 코드가 포함되어 있다면 Scan QR Code에서 스캔하고 시스템 안내에 따라 카메라 사용을 허용한 다음, 해석된 Type, Host 및 Port를 확인하고 저장합니다. Import from Cloud JSON은 보유한 정보가 실제로 해당 형식을 사용할 때만 이용하세요. 임의의 구독 링크나 일반 텍스트를 입력하지 마세요.
추가가 끝나면 SERVER 그룹으로 돌아가 사용할 서버를 눌러 선택 표시가 원하는 항목에 있는지 확인합니다. 여기까지는 정보 준비 단계이며 시스템 연결과 규칙 적용 여부는 확인되지 않았습니다. 구독에 항목이 여러 개라면 하나를 선택해 다음 단계에서 확인하세요. 선택은 그대로 유지하고 다음 단계에서 요청에 사용할 Global Routing 모드를 정합니다.
Global Routing: Config / Proxy / Direct
서버는 연결 매개변수를 결정하고 Global Routing은 요청을 처리하는 방식을 결정합니다.
Home으로 돌아가 Global Routing을 눌러 현재 모드를 확인합니다. 처음 사용할 때 흔히 혼동하는 점은 “서버를 선택했다”는 사실을 “모든 요청이 해당 서버를 사용한다”는 뜻으로 이해하는 것입니다. 실제 요청 경로는 Global Routing 선택과 현재 구성의 규칙에 따라 결정됩니다. 먼저 이번에 확인할 대상이 서버 자체인지, 기존 트래픽 분기 구성인지 정한 뒤 선택하세요.
Config: 현재 구성의 Rule에 따라 처리
Config를 선택하면 요청은 현재 구성의 규칙과 순서에 따라 일치 여부를 확인하고, 일치한 규칙이 지정하는 정책을 사용합니다. Config로 들어가 실제로 활성화된 구성 파일을 확인한 다음 편집 화면에서 Rule을 살펴보세요. 스크린샷의 General, Rule, Hosts, URL Rewrite 및 HTTPS Decryption은 서로 다른 설정 구간입니다. 처음 연결할 때는 관련 규칙과 정책이 있는지만 확인하면 되며, 모든 구간을 하나씩 켜거나 수정할 필요는 없습니다.
예를 들어 DOMAIN-SUFFIX,example.com,PROXY는 지정한 도메인 접미사와 일치하는 요청이 PROXY라는 정책을 사용하도록 합니다. 이 정책 이름은 현재 구성에서 유효한 대상으로 해석되어야 합니다. 규칙 문구가 있다는 사실만으로 정책 참조가 올바르다고 볼 수는 없습니다. 규칙은 일반적으로 순서대로 확인하므로 더 구체적인 일치 조건이 적절한 위치에 있는지와 마지막의 FINAL 대체 규칙을 확인하세요. Add Rule로 수정하기 전에 기존 구성의 복사본을 보관하는 것이 좋습니다.
Proxy: 확인 범위를 임시로 줄이기
선택한 서버가 요청을 처리할 수 있는지 먼저 확인하려면 Proxy를 임시로 선택해 트래픽 분기 규칙이 판단에 미치는 영향을 줄일 수 있습니다. 여기서 Proxy는 Global Routing 모드이고, 규칙 텍스트의 PROXY는 정책 이름이므로 혼동하지 마세요. Proxy 모드에서도 시스템 라우팅, 앱 동작 및 기존 설정의 영향을 받으므로 기기의 모든 트래픽이 반드시 같은 경로를 사용한다고 단정할 수는 없습니다.
Direct: 프록시 서버를 거치지 않고 연결
Direct는 대상에 직접 연결하며 SERVER에서 서버를 선택했다고 해서 해당 서버를 자동으로 사용하지 않습니다. 프록시 서버를 테스트하려는 목적이라면 Direct가 선택되어 있지 않은지 확인하세요. 기기의 기본 네트워크를 비교하려면 Direct를 대조군으로 사용할 수 있습니다. 기본 네트워크에서 접근할 수 없는 대상을 Direct로 전환하는 것만으로 서버 고장 여부를 판단할 수는 없습니다.
이번 단계에서 선택한 모드를 기록해 두세요. 신뢰할 수 있고 용도를 이해하는 구성이 있다면 Config부터 시작할 수 있습니다. 구성을 아직 이해하지 못했다면 먼저 Proxy로 서버를 확인한 다음 Config로 돌아가 트래픽 분기를 점검하세요. 복잡한 규칙 순서, 프로토콜 필드 및 선택 기준은기술 참고 자료에서 설명합니다. 여기서는 처음 연결할 때 알 수 없는 변수가 동시에 늘어나지 않도록 수정 범위를 넓히지 않습니다.
Home: 연결 스위치를 켜고 시스템 구성 허용
선택을 확인한 뒤 연결을 켭니다. 시스템 권한 승인과 원격 서버 사용 가능 여부는 별개의 문제입니다.
앞의 두 단계를 마친 뒤 Home으로 돌아가 SERVER의 대상 서버, Global Routing의 모드 및 Config에서 사용하는 구성을 차례로 확인합니다. 확인 중 구독을 업데이트하거나 여러 서버를 한꺼번에 전환하지 마세요. 그래야 나중에 연결이 복구되어도 어떤 변경이 영향을 주었는지 알기 어렵습니다. 기기에 다른 활성 VPN 연결이 있으면 먼저 종료한 뒤 Shadowrocket을 테스트하세요.
Home 상단의 연결 스위치를 누릅니다. 시스템 구성을 처음 만들 때 iPhone / iPad에 VPN 구성 추가 권한 안내가 표시될 수 있습니다. 안내를 읽고 방금 직접 시작한 작업이 맞는지 확인한 뒤 허용하고, 시스템이 요구하는 기기 인증을 완료하세요. 이 단계에서 필요한 것은 기기 네트워크 구성에 대한 시스템 권한이며 구독 비밀번호가 아닙니다. 기기 인증 정보를 Add Server에 입력할 필요도 없습니다.
권한을 승인한 뒤 Shadowrocket으로 돌아가 상단의 기존 Not Connected 상태가 바뀌었는지, 스위치가 켜진 상태를 유지하는지 확인합니다. 공식 스크린샷은 연결 전 Home 화면을 보여 주므로 이미지 속 상태를 완료 기준으로 삼지 마세요. 상태 변경은 기기의 연결 절차가 진행되었다는 뜻일 뿐입니다. 다음 단계에서 실제 요청으로 원격 연결과 규칙 처리 결과를 확인해야 합니다.
스위치를 켜자마자 자동으로 꺼진다면 권한 안내, 시스템 구성 오류 또는 앱 내 오류 기록이 나타났는지 확인하세요. 이전에 권한을 거부했다면 다시 연결을 시작하고 시스템 안내를 확인할 수 있습니다. 기기가 조직에서 관리되는 경우 관리 정책이 권한을 제한할 수 있으므로 기기 관리자에게 확인하세요. 알 수 없는 관리 구성을 임의로 삭제하지 마세요. 스위치를 반복해서 누르는 것으로 누락된 매개변수를 해결할 수는 없으며 안내와 기록을 서로 연결하기 더 어려워질 수 있습니다.
테스트 중에는 On Demand를 잠시 비활성화해 스위치 변경이 명시적인 수동 조작에서 비롯되도록 할 수 있습니다. 그렇지 않으면 조건이 충족될 때 시스템이 다시 연결해 스위치가 오작동하는 것처럼 보일 수 있습니다. 먼저 앱을 전면에 둔 상태에서 기본 확인을 마친 뒤 브라우저 전환, 화면 잠금 또는 네트워크 변경 후의 동작을 살펴보세요. 처음부터 모든 상황을 한꺼번에 테스트하지 마세요.
여기까지 정보가 저장되고 모드가 선택되었으며 시스템 연결이 시작되었습니다. 이제 서버와 모드를 그대로 유지한 채 Connectivity Test와 페이지 요청을 확인하세요. 이 결과들이 서로 일치하는지 확인한 다음 일상적인 트래픽 분기 또는 필요 시 연결 설정을 조정하는 것이 좋습니다.
Connectivity Test: 테스트 결과와 실제 요청 확인
Home에서 Connectivity Test를 사용해 서버를 확인합니다. 테스트 결과는 선택한 테스트 방법, 대상 및 현재 네트워크의 영향을 받으므로 문제 해결을 위한 단서로만 활용하세요. 모든 웹사이트와 앱에서 사용할 수 있다는 보장은 아닙니다. 테스트가 실패하면 대상 서버와 오류 내용을 기록하고 항목을 바로 삭제하지 마세요. 테스트가 성공해도 실제 요청을 한 번 더 보내야 합니다.
요청을 보낸 뒤 기록 확인
브라우저를 열어 평소 정상적으로 사용하는 페이지에 접속하고 새 요청이 완료될 때까지 기다립니다. 캐시된 페이지만 확인하지 말고, 앱에 예전 내용이 표시된다는 이유만으로 연결이 성공했다고 판단하지 마세요. 페이지가 바뀌지 않으면 새로고침하거나 다시 연 뒤 Shadowrocket으로 돌아가 Data 또는 현재 버전에서 제공하는 연결 기록을 확인합니다.
기록에서는 이번 요청의 대상, 처리 정책 및 시간이 방금 수행한 작업과 일치하는지 확인하세요. Config 모드에서는 특히 일치한 Rule과 최종 처리 결과가 DIRECT, PROXY 또는 다른 정의된 정책인지 확인해야 합니다. DIRECT도 유효한 트래픽 분기 결과이며 반드시 연결 실패를 의미하지는 않습니다. 반대로 프록시 정책 이름이 기록에 표시되어도 원격에서 콘텐츠를 성공적으로 받았다는 뜻은 아니므로 오류 기록과 실제 응답도 함께 확인해야 합니다.
모드를 비교해 문제 위치 구분
Proxy에서는 실제 요청이 성공하고 Config에서는 같은 새 요청이 실패한다면 현재 구성의 일치 규칙, 정책 참조 및 DNS 관련 설정을 먼저 확인하세요. 이미 검증한 서버 비밀번호를 우선 다시 입력하지 마세요. 두 모드 모두 실패한다면 서버 매개변수와 기본 네트워크를 다시 확인합니다. 비교할 때는 Global Routing만 변경하고 서버, 대상 페이지 및 네트워크는 유지하세요. 테스트 후 필요한 모드로 복원합니다.
한 요청에서 여러 도메인을 사용할 수 있습니다. 페이지 본문은 열리지만 이미지, 로그인 또는 동영상이 실패한다면 주소창의 도메인만 확인하지 말고 실패한 리소스의 연결 기록을 살펴보세요. 앱 캐시, 기존 장기 연결 및 시스템 네트워크 설정도 결과에 영향을 줄 수 있으므로 규칙을 변경한 뒤에는 새 요청을 보내야 합니다. 기록이 예상과 다르면 대상과 일치한 정책을 먼저 정리한 뒤질문과 답변의 규칙 및 문제 해결 안내를 확인하세요.
Settings: 처음부터 다시 하기보다 실패 단계 확인
마지막으로 정상 작동한 단계를 찾고 바로 다음 입력, 권한 또는 요청을 확인합니다.
가져오기 실패: 입력 및 콘텐츠 형식 확인
Subscribe에서 콘텐츠를 가져오지 못하면 전체 URL, 유효 기간 및 인증 조건을 먼저 확인하세요. 콘텐츠는 가져왔지만 항목이 없다면 반환된 콘텐츠가 지원되는 구독 형식인지 확인합니다. 수동 추가에 실패했다면 Add Server로 돌아가 원래 정보를 기준으로 Type과 필수 필드를 확인하세요. QR 코드 스캔 성공은 내용을 읽어 냈다는 뜻일 뿐이므로 저장 전에 매개변수를 확인해야 합니다. 전체 구독 링크를 공개해 도움을 요청하지 마세요. 링크의 매개변수가 접근 권한을 직접 나타낼 수 있습니다.
서버 테스트 실패: 매개변수 및 네트워크 확인
Settings에서 Test Method를 확인하고 현재 테스트 대상과 방법을 살펴봅니다. 단일 테스트의 시간 초과가 모든 실제 요청을 대표하지는 않으므로 이전 절의 페이지 확인 결과와 함께 판단하세요. 그런 다음 Host, Port, 인증 필드 및 기기 시간을 확인합니다. TLS를 사용하는 경우 정보에 지정된 서버 이름과 인증서 조건도 확인하세요. 인증서 확인을 끄는 방식으로 이름이나 시간 오류를 감추지 마세요.
기존 설정을 보존한 채 Wi-Fi와 셀룰러 네트워크에서 동일한 요청을 각각 보내 문제가 한쪽 기본 네트워크에서만 발생하는지 확인할 수 있습니다. 네트워크를 전환한 뒤에는 안정될 때까지 기다렸다가 테스트해 전환 순간의 시간 초과를 지속적인 서버 장애로 오인하지 마세요. 여러 항목에서 문제가 발생하면 먼저 기기 자체가 정상적으로 연결되는 것으로 확인된 직접 연결 대상에 접근할 수 있는지 점검합니다.
스위치 이상 또는 일부 요청 실패: Diagnostics 확인
연결 스위치가 켜진 상태를 유지하지 못하면 시스템 권한과 VPN 구성을 다시 확인합니다. 스위치는 정상인데 일부 요청이 실패한다면 Settings에서 Diagnostics를 찾아 현재 버전에서 제공하는 기록으로 구체적인 오류를 확인하세요. 스크린샷의 Proxy, TCP 및 UDP는 서로 다른 설정 메뉴이므로 모두 변경해야 하는 항목으로 보면 안 됩니다. 먼저 오류를 읽고 해당 메뉴를 열 필요가 있는지 판단하세요.
문제를 정리할 때는 사용한 Global Routing, 실패 단계, 특정 대상에만 영향을 미치는지, 기본 네트워크 변경 후 결과가 달라지는지를 기록하세요. 기록을 공유하기 전에 구독 주소, 비밀번호, 키 및 개인 네트워크 정보를 가립니다. 프로토콜 매개변수의 의미는기술 참고 자료에서 확인할 수 있습니다. 가져오기, 권한 또는 규칙 순서와 관련된 일반적인 문제라면질문과 답변을 먼저 확인하세요. 이 페이지의 모든 단계를 처음부터 반복할 필요는 없습니다.
기본 확인을 마친 뒤 On Demand 설정
수동 연결이 안정적으로 작동하는지 확인한 다음 On Demand에서 필요한 실행 조건을 설정합니다. 이 기능은 조건이 충족되었을 때 연결을 시작할지 관리하며 Global Routing의 트래픽 분기 규칙을 대체하지 않고, 작동하지 않는 서버의 매개변수를 보완하지도 않습니다. 설정 후에는 연결 대상 네트워크, 해당 네트워크에서 벗어날 때 및 수동으로 끌 때의 동작을 각각 확인하세요. 예상과 다르면 On Demand를 비활성화하고 수동 테스트로 돌아간 뒤 실행 조건만 따로 조정합니다.
마지막으로 일상 사용에 필요한 모드로 복원하고 검증이 끝난 구성을 보관합니다. 이후 구독을 업데이트하거나 규칙을 변경할 때는 한 번에 한 종류만 수정하고 같은 페이지로 다시 확인하세요. 이렇게 하면 변경 후 문제가 생겨도 모든 매개변수를 다시 추측하지 않고 가장 최근에 정상 작동한 상태로 돌아갈 수 있습니다.
