공식 설명서 · 첫 연결

Shadowrocket 사용법

기존 구독 가져오기, Global Routing 선택, 연결 확인을 안내합니다. 5단계에 따라 처음으로 점검한 뒤 규칙 세부 설정을 조정하세요.

시작 전 확인: 앱 설치 및 본인 연결 정보 준비
이 튜토리얼은 App Store에서 Shadowrocket을 설치했고 본인의 구독 링크 또는 서버 정보를 보유한 경우를 전제로 합니다. 이 사이트는 서버나 구독을 제공·판매·추천하지 않습니다. 클라이언트 앱의 일회성 구매와 연결 서비스 요금제는 별개이며, 앱 구매와 연결 정보 준비는 서로 다른 과정입니다.

아직 설치하지 않았다면 먼저 App Store 정품 확인 및 구입 안내를 읽어 보세요. iPhone과 iPad의 시스템 요구 사항은 App Store 페이지의 표기를 기준으로 합니다. 아래에서는 인터페이스 용어를 영어로 표기합니다. 실제 위치는 레이아웃에 따라 달라질 수 있으니 해당 이름을 확인하세요.

먼저 입력 정보 확인
다음으로 트래픽 정책 선택
마지막으로 실제 요청 확인

01 / INPUT

서버 추가 또는 구독 가져오기

먼저 보유한 정보가 서버 매개변수 하나인지, 서버 공유 정보 하나인지, 여러 서버를 업데이트하는 구독 링크인지 확인하세요. 이 세 가지는 겉모양만 보고 서로 바꿔 사용할 수 없습니다. 구독은 보통 주소 형태이며, 서버 목록을 가져오려면 클라이언트가 해당 주소에 요청을 보내야 합니다. 서버 매개변수는 연결 대상을 직접 설명합니다. 시작하기 전에 원본 정보를 보관하고, 주소의 매개변수를 미리 삭제하거나 구성 파일 주소를 서버 주소 필드에 입력하지 마세요.

Add Server: 기존 정보 직접 입력

Shadowrocket의 Home을 열고 SERVER 영역에서 Add Server를 선택해 추가 화면으로 이동합니다. 먼저 Type을 선택한 뒤 해당 프로토콜에 맞는 필드를 입력하세요. 오른쪽 공식 스크린샷에는 Host, Port, Password, Method가 있는 양식이 표시되어 있지만 모든 Type에 같은 필드가 필요한 것은 아닙니다. 예를 들어 Shadowsocks를 선택했다면 기존 주소, 포트, 비밀번호, Method에 해당하는 항목을 각각 입력하세요. 다른 프로토콜은 현재 화면의 양식과 원본 정보를 대조해야 하며, 스크린샷의 필드 구성을 그대로 적용하면 안 됩니다.

Host에는 서버 주소 또는 도메인을 입력합니다. 전체 경로가 포함된 구독 링크를 이 필드에 넣지 마세요. Port에는 포트 번호를 입력하고 복사하는 과정에서 공백이 포함되지 않았는지 확인합니다. 비밀번호, 식별 정보, 암호화 옵션은 대소문자를 포함해 원본 그대로 입력하세요. 입력을 마친 뒤 화면의 저장 기능을 사용하고 Home으로 돌아가 SERVER에 방금 추가한 항목이 표시되는지 확인합니다. 목록에 이름이 보이는 것은 정보가 저장되었다는 뜻일 뿐, 서버 연결이 가능하다는 의미는 아닙니다.

Scan QR Code 및 Subscribe: 콘텐츠 유형에 맞게 가져오기

QR 코드를 보유한 경우 Add Server에서 Scan QR Code를 사용하세요. 시스템에서 카메라 권한을 요청하면 필요한 권한을 허용합니다. 스캔한 뒤 인식된 Type과 서버 필드를 확인하고 저장하세요. QR 코드는 정보를 전달하는 방식일 뿐, 반드시 단일 서버 정보가 들어 있거나 주소가 여전히 유효하다는 보장은 없습니다. 결과가 예상과 다르면 원본 정보를 다시 확인하고, 중복 항목이 생기도록 반복해서 저장하지 마세요.

구독 링크가 있다면 콘텐츠 유형에 맞는 Subscribe 메뉴를 사용하세요. Config 페이지의 Subscribe는 해당 원격 구성 구독에 사용합니다. SERVER 목록을 만드는 서버 구독은 추가 메뉴에서 구독 유형에 맞게 가져와야 합니다. 둘 다 URL로 시작한다고 해서 같은 메뉴를 사용하면 안 됩니다. 붙여넣을 때 전체 쿼리 매개변수를 유지하고 앞뒤 공백을 제거한 뒤, 설명 문구까지 함께 복사하지 않았는지 확인하세요. 가져온 후 Home으로 돌아가 서버 목록을 확인하고, 구성을 가져왔다면 Config에서 파일이 저장되었는지 확인합니다.

클립보드에서 공유 정보를 인식한 경우에도 가져오기를 승인하기 전에 유형을 확인하세요. Import from Cloud JSON은 해당 형식의 데이터를 위한 기능이며, 모든 구독 링크에 사용할 수 있는 일반 가져오기 메뉴가 아닙니다. 이 단계를 마치면 이번 테스트에 사용할 항목만 명확히 남기고, 여러 서버나 규칙을 한꺼번에 조정하지 마세요. 메뉴별 차이는 구독 가져오기 메뉴 4가지 안내에서 자세히 확인할 수 있습니다.

Shadowrocket의 Add Server 페이지. Type, Host, Port, Password, Method와 Scan QR Code 및 Import from Cloud JSON 메뉴가 표시됩니다. — Add Server: 먼저 Type을 선택한 다음 해당 필드를 확인하세요. 스크린샷의 필드가 모든 프로토콜에 적용되는 것은 아닙니다.

02 / ROUTING

Global Routing 선택

서버를 저장한 다음에는 바로 규칙을 수정하지 말고, 먼저 트래픽에 적용할 정책을 정합니다. Home으로 돌아가 Global Routing을 열고 현재 선택된 방식을 확인하세요. 여기에는 Config, Proxy, Direct 세 가지 옵션이 있습니다. 이 옵션은 SERVER에서 선택한 서버와는 별개의 설정입니다. 전자는 요청을 어떻게 분배할지 정하고, 후자는 연결에 사용할 대상을 제공합니다.

Config: 현재 규칙에 따라 처리

특정 사이트는 프록시를 거치고 나머지 요청은 직접 연결해야 한다면 Config를 선택한 뒤 Config에서 현재 사용 중인 구성 파일을 확인하세요. 파일을 열면 General, Rule, Hosts, URL Rewrite 등의 섹션이 표시됩니다. 먼저 Rule을 확인하고 첫 연결과 관계없는 기능은 임의로 활성화하지 마세요. 규칙은 일반적으로 위에서 아래로 검사되며 먼저 일치한 항목이 정책을 결정합니다. 따라서 같은 도메인과 관련된 규칙의 위치가 결과에 영향을 줍니다.

아래 내용은 규칙 구조를 보여 주기 위한 예시이며 모든 환경에 그대로 적용할 수 있는 완성된 구성은 아닙니다. example.com은 설명용 도메인이므로 사용 전에 실제로 처리할 대상 도메인으로 바꾸세요. PROXY를 사용하려면 현재 구성에 해당하는 사용 가능한 정책도 있어야 합니다. 첫 번째 줄은 해당 도메인과 하위 도메인을 처리하고, 마지막 줄은 일치하지 않은 요청에 DIRECT를 지정합니다. 편집하기 전에 기존 구성을 백업하고, Add Rule을 사용할 때도 키워드 철자뿐 아니라 삽입 위치를 확인하세요.

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

Proxy와 Direct: 트래픽 방향을 명확히 지정

Proxy는 해당 트래픽을 프록시 정책으로 전달하며, 선택한 서버가 요청을 처리할 수 있는지 임시로 비교할 때 유용합니다. Direct는 해당 트래픽을 직접 연결하므로 프록시가 적용되었다는 증거로 볼 수 없습니다. 비교 테스트를 할 때는 기존 선택 항목을 기록하고 Global Routing만 변경한 뒤 같은 대상을 방문하세요. 테스트가 끝나면 장기적으로 사용할 방식으로 되돌려 두어 규칙이 작동하지 않는다고 잘못 판단하지 않도록 합니다.

처음에는 ‘모드’와 ‘서버’를 구분하는 것만으로 충분하며, 복잡한 구성을 바로 작성할 필요는 없습니다. 신뢰할 수 있고 용도에 맞는 구성이 이미 있다면 먼저 적용하고 선택 상태를 확인하세요. DOMAIN, GEOIP, IP-CIDR, FINAL의 적용 범위를 더 알아보려면 규칙 설명서를 참조하세요. 이 단계가 끝나면 현재 선택한 방식과 Config에서 사용 중인 파일을 설명할 수 있어야 합니다.

Shadowrocket의 Config 구성 파일 편집 화면. General, Rule, Hosts, URL Rewrite, HTTPS Decryption 섹션과 Add Rule 메뉴가 표시됩니다. — Config: 구성 파일 내용을 확인하는 곳입니다. Global Routing을 선택하는 메뉴는 Home에 있습니다. 처음에는 Rule을 확인하세요.

03 / CONNECT

서버 선택 및 연결 권한 허용

모드를 확인한 뒤 Home으로 돌아가 SERVER 목록에서 이번에 사용할 서버를 선택합니다. 목록이 구독에서 가져온 것이라면 그룹 제목만 보이는 것이 아니라 필요한 매개변수가 모두 포함된 실제 항목을 선택했는지 확인하세요. 첫 연결 테스트에서는 서버 하나를 고정해 사용하는 것이 좋습니다. 연결 중 항목을 자주 바꾸면 문제가 서버, 규칙, 현재 네트워크 중 어디에서 발생했는지 구분하기 어려워집니다.

Home에서 Global Routing이 앞 단계에서 선택한 설정과 같은지 확인한 뒤 상단의 연결 스위치를 조작합니다. 연결 전에는 Not Connected가 표시될 수 있습니다. 연결 상태는 현재 화면의 표시를 기준으로 확인하세요. 처음 연결할 때 시스템에서 VPN 구성을 추가하라는 메시지가 나타납니다. 이는 Shadowrocket이 기기의 네트워크 트래픽을 처리하는 데 필요한 시스템 권한이며, 양식에 구독 비밀번호를 입력하라는 뜻이 아닙니다. 팝업에서 앱 출처를 확인한 후 허용하고 시스템 안내에 따라 기기 인증을 완료하세요.

이전에 권한을 거부했다면 앱으로 돌아가 다시 연결을 시도하고 시스템 안내에 따라 관련 VPN 설정을 확인하세요. 팝업을 반복해서 취소한 뒤 스위치 위치만 보고 성공 여부를 판단하지 마세요. 권한 설정을 마친 뒤 Home으로 돌아와 연결 상태가 유지되는지 확인합니다. 스위치를 켜자마자 연결이 해제된다면 여기서 멈추고 원인을 점검하세요. 규칙을 추가해 해결하려고 할 필요는 없습니다. 연결이 유지되면 다음 단계로 진행해 실제 요청 전달 결과를 확인합니다.

서로 다른 두 가지를 구분해야 합니다. 시스템에서 VPN 구성을 허용했다는 것은 기기가 클라이언트의 관련 트래픽 처리를 허용한다는 뜻입니다. 원격 서버에 연결할 수 있는지는 주소, 포트, 인증 정보, 프로토콜 매개변수와 현재 네트워크에도 달려 있습니다. 스위치가 켜져 있어도 직접 연결 요청만 정상이고 프록시 요청은 실패할 수 있습니다. 따라서 시스템에 VPN 표시가 나타난다고 해서 모든 대상에 예상한 방식으로 접속된다고 볼 수는 없습니다.

첫 연결 과정에서는 On Demand 등 자동 연결 조건을 그대로 둔 채 수동으로 연결과 연결 해제를 한 번 완료하세요. 다른 VPN 구성이 동시에 연결 상태를 차지하지 않도록 합니다. 연결을 해제하려면 Home으로 돌아가 상단 스위치를 끄고 상태가 변경되었는지 확인합니다. 이렇게 하면 어떤 구성이 현재 요청을 처리하는지 파악할 수 있고, 다음 단계에서 연결 전후를 명확히 비교할 수 있습니다.

이 단계의 완료 기준
Home에서 서버가 선택되어 있고 Global Routing이 의도한 설정과 일치하며 시스템 권한 설정이 완료되고 연결 상태가 유지되어야 합니다. 그다음 요청을 확인하세요. 스위치가 켜졌다는 사실만으로 최종 결론을 내리지 마세요.

Shadowrocket의 Home 화면. 상단에 Not Connected 스위치가 있고, 아래에 Global Routing의 Config, Connectivity Test, SERVER 그룹, Add Server가 표시됩니다. — Home: 같은 화면에서 서버, Global Routing, 연결 상태를 확인한 다음 Connectivity Test로 이동합니다.

04 / CHECK

Connectivity Test로 확인

연결이 유지되면 Home에서 Connectivity Test를 실행합니다. 테스트 전에 방금 사용한 서버가 계속 선택되어 있는지 확인하고 Settings의 Test Method도 살펴보세요. 테스트 방법마다 확인하는 범위가 다릅니다. 특정 테스트에서 응답이 있었다면 당시 조건에서 해당 테스트에 응답했다는 뜻일 뿐, 모든 사이트와 프로토콜, 규칙이 정상이라는 의미는 아닙니다. 테스트에 실패해도 실제 요청이 모두 실패한다고 단정할 수 없습니다.

이어서 브라우저에서 프록시를 거칠 것으로 예상되는 대상과 직접 연결될 것으로 예상되는 대상을 각각 방문합니다. 이미 열어 둔 페이지의 표시만 보지 말고 새 요청을 보내세요. 캐시된 콘텐츠가 현재 연결 변화를 가릴 수 있습니다. Config를 사용한다면 대상에 대한 실제 요청이 예상한 규칙과 일치하는지, 최종 정책이 PROXY 또는 DIRECT인지 확인합니다. Proxy를 임시로 사용 중이라면 선택한 프록시 정책을 거친 요청이 완료되는지 먼저 확인하세요.

아래 세 항목을 최소 확인 기록으로 활용할 수 있습니다. 이번에 실제로 관찰한 결과만 기록하면 됩니다. 전체 인증 정보를 적거나 수많은 테스트 수치를 모을 필요는 없습니다. 세 가지 결과는 서로 보완하는 것이므로 어느 하나로 나머지를 대신할 수 없습니다.

확인 항목	작업	확인 내용
연결 상태	Home으로 돌아가 스위치와 상태 확인	시스템 권한 허용 후 연결이 유지됨
실제 요청	프록시를 거칠 것으로 예상되는 대상 방문	캐시 표시만이 아니라 새 요청이 완료됨
규칙 결과	해당 요청 기록 확인	일치한 규칙과 최종 정책이 예상과 일치함

페이지는 열리지만 정책이 예상과 다르면 서버를 바로 바꾸지 말고 먼저 Global Routing과 Rule 순서를 확인하세요. 예를 들어 더 위에 있는 포괄적인 규칙이 먼저 일치하면 뒤에 있는 구체적인 규칙은 해당 요청의 정책을 결정하지 않습니다. 반대로 정책이 이미 PROXY인데 연결이 실패한다면 해당 정책에 연결된 서버와 프로토콜 매개변수를 확인하세요. 연결 문제를 도메인 규칙 문제로 잘못 판단하지 않도록 합니다.

완료 후 연결을 해제했다가 다시 연결하고 같은 대상을 재검증해 이전 연결에 우연히 의존한 결과가 아닌지 확인하세요. 네트워크 환경을 바꾼 경우에도 다시 점검해야 하며, 특히 구독을 업데이트했거나 서버 매개변수가 바뀌었다면 확인이 필요합니다. 도메인 해석, 정책 참조, 규칙 우선순위를 더 자세히 확인하려면 규칙 및 구성 참고서를 읽어 보세요. 이 시작 안내서에서는 우선 재현 가능한 검증 절차를 만드는 것을 목표로 합니다.

05 / REVIEW

자주 발생하는 실패와 점검 순서

문제가 생기면 먼저 가져오기, 연결 설정, 실제 요청 중 어느 단계에서 실패했는지 확인하세요. Settings에는 Test Method, On Demand, Diagnostics와 Proxy, TCP, UDP 관련 메뉴가 있습니다. 각각 용도가 다르며 모두 켜야 하는 ‘복구 스위치’가 아닙니다. 기존 설정을 유지하고 한 번에 한 항목만 변경한 뒤 같은 대상을 다시 테스트하고 변경 사항을 유지할지 결정하세요.

구독 실패: 주소와 응답 내용부터 확인

업데이트에 실패하거나 가져온 뒤 서버가 나타나지 않으면 먼저 원본 정보로 돌아가 링크가 완전한지, 줄바꿈·공백·채팅 문구가 섞이지 않았는지 확인하세요. 링크의 쿼리 매개변수는 구독을 식별하는 데 쓰일 수 있으므로 임의로 삭제하면 콘텐츠를 가져오지 못할 수 있습니다. 현재 네트워크에서 구독 주소에 접근할 수 있는지, 응답이 클라이언트가 지원하는 데이터인지도 확인하세요. 로그인 페이지, 오류 안내, 일반 웹페이지 본문이 반환되는 경우는 해당하지 않습니다. 구성 구독과 서버 구독에 잘못된 메뉴를 사용하면 ‘저장했지만 목록에 변화가 없는’ 상황이 생길 수 있습니다.

문제를 해결하려고 정상 작동하는 기존 항목을 반복해서 삭제하지 마세요. 먼저 오류 메시지를 기록한 뒤, 현재 연결 정보를 제공한 곳에 주소 상태, 콘텐츠 형식, 이용 조건을 확인하세요. 구독 링크에는 개인 접근 정보가 포함되는 경우가 많으므로 공개 토론에 올리지 말고, 장애 화면에도 전체 주소를 표시하지 마세요. 가져오기 문제를 해결한 뒤 첫 단계로 돌아가 저장 결과를 확인하세요. 바로 DNS 설정을 변경하지 마세요.

스위치가 꺼지거나 요청이 실패함: 시스템과 서버를 나누어 점검

연결 스위치가 켜진 상태로 유지되지 않으면 VPN 권한 설정이 완료되었는지, 다른 VPN 구성이 현재 연결에 영향을 주는지 확인하고 앱에 표시된 오류도 살펴보세요. 스위치는 유지되지만 요청이 실패한다면 Host, Port, Type 및 해당 인증 정보를 확인합니다. 일부 프로토콜에는 추가 전송 또는 TLS 매개변수가 필요하므로 기존 정보와 일치해야 합니다. 주소와 포트가 같다는 것만으로 구성이 완전하다고 볼 수 없습니다. 네트워크와 매개변수를 동시에 바꾸지 말고 같은 서버와 네트워크로 먼저 다시 시도하세요.

특정 도메인만 실패하고 다른 대상은 정상이라면 해당 규칙과 해석 결과를 확인하세요. 범위가 지나치게 넓은 규칙으로 문제를 덮거나 이유를 알 수 없는 상태에서 HTTPS Decryption을 켜지 마세요. 첫 연결에는 보통 암호화 트래픽 복호화가 필요하지 않습니다. 관련 설정을 잘못 변경하면 변수가 늘어나 단순한 서버 연결 문제도 더 찾기 어려워집니다.

테스트는 실패하지만 접속 가능함: Test Method 확인

Connectivity Test와 브라우저 접속은 요청 방식이 완전히 같지 않을 수 있습니다. 실제 접속은 정상인데 테스트가 실패한다면 Test Method와 테스트 조건부터 확인하세요. 테스트 결과 하나만 보고 서버를 삭제하지 마세요. 웹페이지는 정상인데 특정 유형의 앱 요청이 실패한다면 TCP, UDP, 도메인 해석, 서버 측 기능을 구분해 점검하세요. 한 종류의 요청이 성공했다고 해서 다른 유형도 모두 지원된다는 뜻은 아닙니다.

추가 진단이 필요하면 Diagnostics를 사용하세요. 공유하기 전에 서버 주소, 구독 매개변수, 계정 정보 등 민감한 내용을 삭제해야 합니다. On Demand는 조건에 따라 연결을 시작하는 기능이지, 잘못된 인증 정보를 해결하지 않습니다. 먼저 수동 연결과 검증이 정상적으로 되는지 확인한 다음 사용 환경에 맞게 자동 동작을 설정하세요. Settings의 각 메뉴가 여전히 궁금하다면 기능 및 설정 안내를 확인하세요.

정상 작동한 상태를 보관하세요
가져오기, 연결, 검증이 모두 완료되면 현재 구성의 백업을 보관하고 Global Routing 및 사용한 서버를 기록하세요. 이후 규칙을 수정할 때 재현 가능한 이 상태를 비교 기준으로 삼으세요. 규칙 구조와 백업 시 주의 사항은 규칙 설명서에서 확인할 수 있습니다.