Shadowrocket 기능 및 설정

01 / ROUTING

Global Routing: Config, Proxy, Direct

Global Routing은 요청에 적용할 라우팅 방식을 결정하며, 보통 Home에서 열 수 있습니다. 이 설정은 연결 스위치나 현재 선택한 서버와는 별개입니다. 스위치는 시스템 VPN 연결을 켜고 끄며, 서버는 연결 대상을 제공하고, 라우팅 방식은 트래픽을 해당 대상으로 어떻게 보낼지 정합니다. 스위치를 켰다는 사실만으로 규칙이 적용되거나 서버에 연결할 수 있다고 볼 수는 없습니다.

Global Routing을 열고 현재 선택된 Config, Proxy, Direct 중 무엇인지 확인한 뒤, 아래 표를 참고해 테스트 목적에 맞는지 살펴보세요. 한국어로 설정, 프록시, 직접 연결이라고 부르는 항목은 각각 이 세 가지 영어 메뉴이며, 별도의 설정 파일을 뜻하지 않습니다.

같은 대상에 Proxy로는 접속되지만 Config로는 접속되지 않는다면, 일치하는 규칙과 해당 규칙이 참조하는 정책을 먼저 확인하세요. 두 모드에서 모두 실패한다면 서버 설정과 기본 네트워크를 먼저 점검하세요. 이런 비교는 문제 범위를 좁히는 데 도움이 되지만, 한 번의 결과만으로 원인을 단정할 수는 없습니다. 테스트가 끝나면 원래 사용하던 모드로 되돌려 임시 변경이 이후 트래픽에 계속 영향을 주지 않도록 하세요.

02 / RULES

규칙 기반 라우팅: 매칭 조건과 적용 정책

규칙 기반 라우팅은 요청마다 서로 다른 정책을 적용하는 기능입니다. Config에서 현재 사용하는 Config 파일을 확인한 다음, 파일의 [Rule] 내용을 살펴보세요. Global Routing → Config에서는 규칙을 위에서부터 순서대로 확인하고, 일반적으로 일치하는 규칙을 찾으면 해당 정책을 적용합니다. 따라서 구체적인 조건을 포괄적인 조건보다 앞에 두고, 마지막에는 기본 처리 규칙인 FINAL을 배치하세요.

규칙은 일반적으로 매칭 유형, 매칭할 값, 정책으로 구성됩니다. DOMAIN은 정확한 도메인과 일치하고, DOMAIN-SUFFIX는 도메인 접미사와 일치하며, DOMAIN-KEYWORD는 도메인에 포함된 키워드와 일치합니다. IP-CIDR과 IP-CIDR6은 IP 주소 대역을 지정하고, GEOIP는 IP 주소의 국가·지역 데이터베이스를 기준으로 판단합니다. USER-AGENT는 요청 정보를 확인할 수 있어야 하므로 암호화된 트래픽을 모두 식별한다고 가정해서는 안 됩니다.

[Rule]
DOMAIN,ads.example.com,REJECT
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT
FINAL,PROXY

이 예시는 문법과 규칙 순서만 보여 주며, 기존 Config를 그대로 대체할 수 있는 완성된 파일은 아닙니다. 첫 번째 규칙이 두 번째 규칙보다 구체적이므로 ads.example.com에 접속하면 먼저 REJECT와 일치하고, 뒤에 있는 접미사 규칙까지 내려가지 않습니다. DIRECT는 직접 연결, REJECT는 차단, PROXY는 프록시 경로를 뜻합니다. 규칙에서 사용자 지정 정책 이름을 참조한다면 해당 이름이 실제로 존재하고 현재 선택할 수 있는지 먼저 확인하세요.

규칙을 추가하기 전에 기존 파일을 보관하고, 명확한 테스트 대상 하나만 수정하세요. 요청을 다시 보낸 뒤 연결 기록에서 실제로 일치한 규칙과 정책을 확인하세요. 페이지가 열리는지만 확인해서는 충분하지 않습니다. 캐시, 여러 도메인 요청, 기존 연결이 결과에 영향을 줄 수 있습니다. 새로운 매칭 결과를 시험하려면 대상 요청을 새로 시작하세요. 도메인 규칙 하나를 확인하기 위해 DNS, 라우팅 모드, 서버를 동시에 변경하지 마세요.

03 / SERVERS

Subscribe 및 서버 관리

서버 정보에는 연결 대상과 인증 정보가 저장되고, Subscribe에서는 사용자가 이미 보유한 서버 목록을 가져오거나 업데이트할 수 있습니다. 서버 정보와 규칙 Config는 서로 다릅니다. 서버를 가져왔다고 올바른 Config가 선택되는 것은 아니며, 규칙 Config를 가져왔다고 사용할 수 있는 서버 정보가 준비되는 것도 아닙니다. 작업을 시작하기 전에 보유한 정보가 구독 주소인지, 개별 서버 정보인지, Config 파일인지 구분하세요.

Subscribe: 기존 구독 가져오기

이미 사용 중인 구독이 있다면 현재 화면에서 Config 페이지의 Subscribe 메뉴를 열어 사용할 수 있는 작업을 확인하고, 기존 주소를 입력해 가져오거나 업데이트하세요. 가져온 다음 Home으로 돌아가 서버 목록, 그룹, 이름이 예상대로 표시되는지 확인하고 서버 하나를 선택해 연결을 테스트하세요. 구독 업데이트 성공은 내용이 가져와 처리되었다는 뜻일 뿐, 모든 서버에 연결할 수 있다는 의미는 아닙니다.

업데이트에 실패하면 주소 전체가 올바른지, 구독이 여전히 유효한지, 현재 네트워크에서 해당 주소에 접속할 수 있는지부터 확인한 다음 구체적인 오류를 살펴보세요. 기존 그룹과 문제 해결에 필요한 정보를 잃지 않도록 항목을 반복해서 삭제하고 다시 추가하지 마세요. 구독을 업데이트하면 구독에서 관리하는 항목이 덮어써질 수 있습니다. 로컬에서 수정해야 한다면 먼저 변경 사항을 기록하고 다음 업데이트에 미칠 영향을 확인하세요.

Add Server: 항목별 설정 확인

개별 서버 정보를 가지고 있다면 Home의 추가 메뉴에서 Add Server를 열고, 프로토콜 유형을 선택한 뒤 원본 정보에 따라 주소, 포트, 인증 항목을 입력하세요. Shadowsocks, VMess, VLESS, Trojan, Hysteria2, WireGuard는 프로토콜마다 입력 항목이 다르므로 한 프로토콜의 정보를 다른 프로토콜 양식에 그대로 입력하지 마세요. TLS, SNI, 전송 방식도 서버 측 설정과 일치해야 합니다.

QR 코드나 인식 가능한 링크가 있다면 화면의 Scan QR Code 또는 클립보드 가져오기 메뉴를 사용할 수 있습니다. 가져온 뒤에도 유형, 주소, 주요 항목을 확인하세요. 인증 정보가 포함된 QR 코드, 구독 주소, 전체 서버 정보를 공개하지 마세요. Connectivity Test는 다시 확인할 서버를 추리는 데 도움이 되지만, 테스트 통과가 실제 서비스 접속을 보장하지는 않습니다.

04 / ON DEMAND

On Demand: 조건에 따른 연결

On Demand는 시스템 VPN의 주문형 연결 기능을 사용해 설정된 조건이 충족되면 연결을 시작합니다. 서버 오류를 해결하는 만능 스위치도 아니며, 모든 앱의 트래픽이 반드시 프록시를 통과하도록 보장하지도 않습니다. 실제 요청 처리는 Global Routing, 규칙, 선택한 서버에 따라 달라집니다.

Settings에서 On Demand를 찾아 현재 사용할 수 있는 네트워크 조건을 확인한 뒤 활성화 여부를 결정하세요. 먼저 수동 연결을 테스트해 시스템 VPN 설정이 승인되었는지, 선택한 서버를 사용할 수 있는지, 현재 Config가 예상대로인지 확인해야 합니다. 수동 연결이 정상임을 확인해야 자동 연결 결과도 판단하기 쉽습니다.

활성화한 뒤 실제로 사용하는 Wi-Fi와 셀룰러 네트워크를 전환하며 연결 동작을 확인하세요. 어떤 조건에서 연결되고 어떤 조건에서는 연결 상태가 유지되는지 기록합니다. 연결을 끈 직후 다시 켜진다면 스위치 고장으로 단정하기 전에 On Demand와 시스템의 VPN 주문형 설정을 확인하세요. 기본 네트워크 테스트를 위해 연결을 잠시 중단하려면 관련 주문형 조건도 함께 일시 중지한 뒤 테스트 후 복원하세요.

iPhone과 iPad에서 사용할 수 있는 네트워크 조건은 기기 기능, 시스템, 현재 화면에 따라 다를 수 있습니다. 한 기기의 조건을 다른 기기에 그대로 적용하지 말고, VPN 아이콘만으로 연결이 올바르게 시작되었는지 판단하지 마세요. 연결 상태, 접속 결과, 사용된 정책을 함께 확인하세요.

05 / DATA

Data: 트래픽 기록 및 변화 확인

Data에서는 앱에 기록된 트래픽과 연결 관련 정보를 확인할 수 있습니다. Data를 열고 현재 표시되는 통계 범위, 기록 대상, 시작 및 종료 조건을 확인한 다음 업로드와 다운로드 변화를 살펴보세요. 화면마다 총량 계산 기준이 다를 수 있으므로 앱의 누적 수치를 서버 계정의 요금 잔액이나 남은 데이터로 간주해서는 안 됩니다.

문제를 확인할 때는 현재 데이터를 먼저 기록한 다음 특정 웹페이지 열기처럼 명확한 작업 하나만 실행하고, 돌아와 새 기록과 트래픽 변화를 살펴보세요. 기록에 대상, 정책, 연결 상태가 표시된다면 현재 Global Routing 및 규칙과 함께 확인하세요. 테스트 중에는 여러 백그라운드 전송을 동시에 실행하지 마세요. 추가 트래픽을 테스트 요청과 구분하기 어려워집니다.

현재 화면에서 통계 삭제 또는 초기화 기능을 제공한다면 필요한 문제 해결 정보를 먼저 보관한 뒤 실행하세요. 로컬 기록을 삭제해도 서버 측 요금 계산에는 영향을 주지 않습니다. 앱이 백그라운드로 전환되거나 연결이 다시 설정되거나 기기가 다른 네트워크로 바뀌면 통계가 연속해서 기록되는지도 다시 확인해야 합니다. 트래픽이 한 번 늘거나 줄었다는 사실만으로 속도, 배터리 소모, 서버 안정성을 단정할 수는 없습니다.

06 / SETTINGS

Settings: DNS, 테스트 및 동기화

DNS: 도메인 해석과 연결 문제 구분

DNS는 도메인을 IP 주소로 변환하며, 변환 결과는 이후 연결과 일부 주소 기반 규칙에 영향을 줍니다. Settings에서 DNS 항목을 확인할 때는 현재 Config에 별도의 DNS 설정이 있는지도 확인하세요. 한 곳만 변경하고 다른 설정 출처를 놓치지 않도록 주의해야 합니다. 기존 값을 기록한 뒤 문제가 도메인 해석에만 있는지, 해석 이후 연결도 실패하는지 구분하세요.

변경하기 전에 입력한 주소와 형식이 현재 화면에서 지원되는지, 현재 네트워크에서 DNS 서버에 연결할 수 있는지 확인하세요. 출처를 알 수 없는 설정을 여러 개 한꺼번에 입력하지 말고, DNS 변경을 모든 시간 초과 문제의 만능 해결책으로 여기지 마세요. 변경 후 같은 도메인으로 요청을 다시 보내고 해석 결과와 연결 기록을 함께 확인하세요. 캐시가 남아 있으면 한 번의 테스트만으로 변경 사항이 반영되지 않을 수 있습니다.

Test Method: 테스트 기준 통일

Test Method는 연결 테스트 방식을 결정합니다. Settings에서 이 항목을 확인한 뒤 Connectivity Test를 실행하세요. 테스트 방식과 대상이 다르면 측정값의 의미도 달라질 수 있습니다. 특정 테스트에 실패했다고 해서 모든 실제 요청이 실패한다고 단정할 수는 없습니다. 서버나 네트워크를 비교할 때는 테스트 방식, 대상, 네트워크 조건을 가능한 한 동일하게 유지하세요.

연결 테스트는 문제 범위를 좁히는 데 쓰이며, 종합적인 전송 속도 테스트는 아닙니다. 테스트 시간이 짧아도 대용량 파일 전송이 더 빠르다고 보장할 수 없고, 시간 초과도 실제 접속 결과, 프로토콜 설정, 서버 상태와 함께 판단해야 합니다. Test Method를 변경했다면 이전과 이후의 설정을 기록해 테스트 기준의 차이를 서버 성능 변화로 오해하지 않도록 하세요.

Today Widget: 빠른 접근 및 상태 확인

Today Widget은 시스템 위젯에서 앱 정보를 빠르게 확인하거나 조작할 수 있도록 합니다. 먼저 Settings에서 관련 설정을 확인한 뒤 현재 시스템에서 제공하는 방법으로 사용할 수 있는 위젯을 추가하세요. 해당 메뉴의 제공 여부와 위젯에서 실행할 수 있는 작업은 기기 화면에서 확인해야 하며, 모든 시스템 화면이 동일하다고 가정해서는 안 됩니다.

위젯에서 작업을 실행한 뒤 Home으로 돌아가 연결 결과를 확인하세요. 위젯 표시, 시스템 VPN 상태, 앱 내 기록은 동시에 갱신되지 않을 수 있습니다. 표시가 바뀌지 않으면 버튼을 반복해서 누르기 전에 앱에서 실제 연결 상태를 확인하고 위젯 설정을 점검하세요.

iCloud: 동기화 전 로컬 데이터와 클라우드 데이터 구분

Settings에서 iCloud 동기화 또는 백업 관련 항목을 확인하고, 현재 화면에서 실제로 포함되는 데이터 범위를 살펴보세요. 사용 전에 시스템의 iCloud 로그인 상태, 앱의 iCloud 사용 권한, 사용 가능한 저장 공간을 확인하세요. 처음 동기화하기 전에 로컬 Config를 보관하고, 클라우드와 로컬 내용이 다르면 가져오기, 복원, 덮어쓰기를 실행하기 전에 어느 쪽을 보존할지 먼저 결정하세요.

모든 민감 정보, 시스템 VPN 승인, 로컬 기록이 동기화와 함께 옮겨진다고 가정하지 마세요. 다른 기기로 바꾼 뒤에도 서버 정보, 현재 Config, Global Routing, 최초 VPN 승인을 확인해야 합니다. App Store에서 구입 항목을 복원해 앱을 다시 받는 과정과 Config 동기화는 별개의 절차입니다. 구입 관련 안내는 구입 항목 복원을 참고하세요.

07 / DIAGNOSTICS

Diagnostics: 재현 가능한 문제 해결 정보 보관

Diagnostics에서는 진단 정보를 수집하고 확인할 수 있습니다. Settings에서 해당 메뉴를 찾아 현재 화면에서 사용할 수 있는 검사 또는 기록 기능을 선택하세요. 문제가 발생한 네트워크, 대상, 시간대, 재현 절차를 먼저 기록해야 결과를 맥락에 맞게 해석할 수 있습니다. 진단 기능은 문제를 자동으로 해결하는 버튼이 아니며, 오류 한 줄만으로 다른 원인을 모두 배제할 수도 없습니다.

1. 테스트 조건을 고정하세요. 현재 서버, Config, Global Routing을 기록하고 안정적으로 재현할 수 있는 요청 하나를 선택합니다.
2. 기본 네트워크부터 확인하세요. 현재 Wi-Fi 또는 셀룰러 네트워크가 정상적으로 작동하는지 확인한 다음 시스템 VPN 승인과 연결 상태를 살펴봅니다.
3. 항목을 하나씩 분리해 확인하세요. 서버 설정, 규칙 매칭, DNS, 연결 테스트를 각각 점검하고 모든 설정을 한꺼번에 바꾸지 마세요.
4. 다시 테스트한 뒤 설정을 복원하세요. 한 항목을 변경한 뒤 같은 요청을 다시 실행하고 결과를 기록하세요. 임시로 변경한 라우팅 방식과 진단 설정은 사용 후 원래대로 되돌립니다.

진단 결과를 보관하거나 공유하기 전에 구독 주소, 인증 정보, 서버 주소, 접속 도메인 등 개인 정보가 포함되어 있는지 확인하고 문제 파악에 꼭 필요한 부분만 공유하세요. 로그에 뚜렷한 오류가 없다고 해서 연결 경로의 모든 구간이 정상적으로 검증된 것은 아닙니다. 실제 증상과 함께 문제 해결 매뉴얼의 관련 항목을 확인하세요.

기능을 설정할 때는 현재 값을 확인하고, 한 번에 한 항목만 변경한 뒤 결과를 재현해 보는 것이 좋습니다. 영어 메뉴의 의미만 확인하려면 용어 설명을 참고하세요. 가져오기부터 첫 연결까지 전체 순서가 필요하다면 시작하기로 돌아가세요. 이 페이지의 모든 기능을 한꺼번에 활성화할 필요는 없습니다.