Shadowrocket 기능 및 설정

Global Routing: Config, Proxy, Direct 설정

무엇인가요: Global Routing은 트래픽을 처리하는 전반적인 방식을 결정합니다. 규칙에 따라 처리하려면 Config, 프록시를 사용하려면 Proxy, 직접 연결하려면 Direct를 선택합니다. 여기서 Config는 라우팅 모드 이름이며, 하단의 구성 파일 관리 메뉴인 Config와는 구분해야 합니다.

어디에서 확인하나요: Home에서 Global Routing을 찾아 현재 선택된 항목을 확인합니다. 변경하기 전에 기존 라우팅 방식, 선택된 서버와 구성 이름을 기록해 두면 문제 해결 후 원래 설정으로 되돌리기 쉽습니다.

어떻게 설정하나요: 규칙에 따라 트래픽을 나누려면 Config를 선택하고 구성 화면에서 사용할 파일이 선택되어 있는지 확인합니다. 특정 대상에만 문제가 있다면 같은 네트워크와 서버를 유지한 채 잠시 Proxy로 전환해 결과를 비교할 수 있습니다. 확인이 끝나면 원래 방식으로 되돌리세요. 한 번에 하나의 조건만 바꿔야 테스트 결과를 비교할 수 있습니다.

주의사항: 라우팅 방식은 서버가 아니며 서버 인증 정보를 채워 주지 않습니다. Proxy를 선택해도 서버가 반드시 작동하는 것은 아닙니다. Direct를 선택한다고 시스템의 VPN 구성이 꺼지는 것도 아닙니다. 시스템이 처리하는 트래픽과 앱이 처리하는 범위에는 차이가 있으므로, ‘전체’를 기기의 모든 시스템 요청이 같은 경로를 사용한다는 뜻으로 해석하지 마세요.

규칙 기반 라우팅: 매칭 조건과 처리 정책

무엇인가요: 규칙은 일반적으로 유형, 매칭 조건, 정책으로 구성됩니다. 유형은 요청을 식별할 조건을, 정책은 조건에 일치한 요청의 처리 방법을 지정합니다. DOMAIN은 도메인 전체와 일치하고, DOMAIN-SUFFIX는 도메인 접미사와 일치하며, DOMAIN-KEYWORD는 도메인에 포함된 키워드로 매칭합니다. IP 관련 규칙에는 IP-CIDR, IP-CIDR6, GEOIP가 있습니다.

어디에서 확인하나요: Config에서 현재 구성을 확인한 다음 규칙을 살펴보거나 편집합니다. 규칙을 확인할 때는 대상 도메인만 검색하지 말고 앞뒤 항목도 함께 확인하세요. 먼저 일치한 규칙이 이미 처리 방식을 결정했을 수 있습니다.

어떻게 설정하나요: 대상에 직접 연결할지, 프록시를 사용할지, 요청을 거부할지 먼저 정한 뒤 가능한 한 정확한 매칭 조건을 선택합니다. DIRECT는 직접 연결, PROXY는 프록시 정책, REJECT는 요청 거부를 의미합니다. 사용자 지정 정책 그룹을 사용하는 경우 구성에 정의된 이름과 일치해야 합니다. 다음은 규칙 문법의 예시이며, 모든 네트워크에 그대로 적용할 수 있는 완성된 구성은 아닙니다.

DOMAIN-SUFFIX,example.com,PROXY
GEOIP,CN,DIRECT
FINAL,PROXY

첫 번째 예시는 example.com과 하위 도메인에 일치하는 요청을 PROXY로 처리합니다. 두 번째 줄은 IP 지리 데이터베이스 결과에 따라 직접 연결 여부를 결정합니다. 마지막 줄의 FINAL은 앞선 규칙에 일치하지 않은 요청을 처리합니다. 도메인 해석 결과와 지리 데이터베이스가 IP 규칙의 판단에 영향을 주므로, 도메인 이름만 보고 전체 결과를 예측할 수는 없습니다.

주의사항: 규칙은 일반적으로 위에서부터 순서대로 적용되므로 구체적인 조건을 포괄적인 조건보다 앞에 두세요. USER-AGENT는 요청 정보를 확인할 수 있어야 적용되며 모든 암호화 요청에 사용할 수 있는 것은 아닙니다. REJECT는 조건에 일치하는 요청을 거부하며 같은 도메인의 모든 콘텐츠 용도를 구별하지는 않습니다. 원치 않는 요청까지 차단되면 방금 추가한 규칙 하나만 비활성화하고 다시 테스트하세요. 구성 전체를 한꺼번에 수정하지 마세요.

구독 및 서버: 가져오기, 업데이트, 정리

무엇인가요: Subscribe는 기존 구독에서 가져온 서버 정보를 관리하는 기능입니다. 서버를 직접 추가할 때는 연결 정보를 항목별로 입력합니다. 구독 업데이트는 원격에서 제공하는 항목을 새로 고치는 것이며, 앱 업데이트와는 다르고 규칙 구성을 포함하지 않을 수도 있습니다. 서버, 구독, 구성 파일은 서로 다른 항목이므로 각각 확인해야 합니다.

어디에서 확인하나요: Home에서 서버 목록을 확인하고 Add Server를 눌러 정보를 추가합니다. 기존 구독을 추가하려면 추가 화면에서 Subscribe 유형을 선택합니다. QR 코드는 Scan QR Code를 사용할 수 있으며, 클립보드에서 가져올 때는 앱에 표시되는 안내나 메뉴를 따르세요.

어떻게 설정하나요: 구독을 추가하기 전에 링크가 완전한지 확인하고 쿼리 매개변수를 빠뜨리지 마세요. 서버를 직접 입력할 때는 유형을 먼저 선택한 뒤 기존 정보를 바탕으로 주소, 포트, 비밀번호 및 기타 인증 항목을 입력합니다. 예를 들어 Trojan과 VMess는 인증 구조가 다르므로 한 유형의 입력 내용을 다른 유형에 그대로 사용하면 안 됩니다. Shadowsocks, VLESS, Hysteria2, WireGuard 등도 각 유형에 맞는 매개변수를 입력해야 합니다.

가져온 뒤에는 항목 이름과 개수가 예상한 대로인지 확인한 다음 하나를 선택해 테스트합니다. 구독이 여러 개라면 용도를 알아보기 쉽게 이름을 붙이고 어느 구독에서 가져왔는지 구분해 두세요. 그래야 구독에서 가져온 항목을 직접 입력한 기록으로 착각하지 않습니다. 업데이트 전후에 항목이 달라졌다면 구독에서 새로 제공된 내용을 기준으로 확인하세요.

주의사항: 구독을 업데이트하면 원격에서 관리하는 항목이 덮어써질 수 있으므로 직접 수정한 내용이 계속 유지되지 않을 수 있습니다. 구독을 삭제하거나 여러 항목을 한꺼번에 정리하기 전에 필요한 내용을 백업하세요. 구독 링크, QR 코드, 공유 링크에는 인증 정보가 포함될 수 있으므로 공개 이미지나 로그에 넣지 마세요. 업데이트, 정렬, 삭제, 백업 방법은 구독 및 서버 관리 매뉴얼을 참고하세요.

On Demand: 조건에 따른 연결

무엇인가요: On Demand는 시스템의 주문형 연결 기능을 사용해 설정된 네트워크 조건에 따라 연결을 제어합니다. ‘언제 연결할지’를 정하는 기능이며, Global Routing은 ‘연결 후 트래픽을 어떻게 처리할지’를 정합니다. 두 설정은 함께 사용할 수 있지만 서로 대체하지는 않습니다.

어디에서 확인하나요: Settings에서 On Demand를 찾아 설정할 수 있는 조건과 동작을 확인합니다. 화면에 시스템 VPN 구성 업데이트를 요청하는 메시지가 표시되면 내용을 읽고 변경을 허용할지 결정하세요.

어떻게 설정하나요: 자동 연결을 끈 상태에서 먼저 수동으로 연결해 현재 서버와 구성이 작동하는지 확인한 뒤, 명확한 조건을 하나 추가합니다. Wi-Fi 환경별로 구분해야 한다면 네트워크 이름과 조건의 매칭 방식을 확인하세요. 조건이 여러 개라면 각 조건의 동작과 매칭 관계를 하나씩 확인합니다. 저장한 뒤 해당 네트워크로 전환해 연결 상태를 살펴보고, 접속 여부를 알고 있는 대상으로 테스트하세요.

주의사항: On Demand를 켜면 수동으로 연결을 끊어도 조건이 다시 작동해 ‘끊었는데 다시 연결되는’ 것처럼 보일 수 있습니다. 이런 현상이 나타나면 서버를 계속 삭제하는 대신 먼저 On Demand 설정을 확인하세요. 주문형 연결은 만료된 인증 정보를 복구하지 않으며, 네트워크가 바뀔 때마다 끊김 없이 전환된다고 보장하지도 않습니다. 기능을 끈 뒤에는 앱 상태와 시스템 VPN 상태가 일치하는지 확인하세요.

Data: 트래픽 확인 및 통계 기준

무엇인가요: Data에서는 클라이언트가 제공하는 트래픽 통계를 확인할 수 있습니다. 작업 중 트래픽이 발생했는지, 요청이 클라이언트를 통과했는지 확인하거나 같은 기준으로 변화를 비교할 때 유용합니다. 연결 서비스의 요금 청구 내역을 보여 주는 화면은 아닙니다.

어디에서 확인하나요: Data를 열고 각 수치 옆의 설명을 읽어 어떤 범위, 방향, 기간을 표시하는지 확인합니다. 기기나 화면에 따라 통계 항목이 다를 수 있으므로 표시되지 않는 항목을 임의로 추정하지 마세요.

어떻게 설정하나요: 문제를 확인하기 전에 현재 수치와 시간을 기록합니다. 백그라운드 활동을 최대한 줄인 상태에서 대상에 한 번 접속한 다음 Data로 돌아와 변화를 비교하세요. 통계를 초기화하려면 필요한 이전 기록을 먼저 저장하고 새 기준점부터 확인합니다. 테스트 중에는 라우팅 방식, 서버, 네트워크를 변경하지 마세요.

주의사항: 업로드와 다운로드 모두 데이터가 발생할 수 있으며, 연결 유지, 백그라운드 앱, 프로토콜 오버헤드로 추가 트래픽이 생길 수도 있습니다. 클라이언트의 기록은 서비스 제공자의 과금 기준이나 기기의 셀룰러 데이터 통계와 다를 수 있습니다. 남은 사용량은 기존 서비스의 관리 화면에서 확인하세요. 수치가 증가했다는 사실만으로 대상 콘텐츠가 정상적으로 도착했다고 판단할 수는 없습니다.

Settings: DNS, 테스트, 바로가기, 동기화

Settings에는 앱 작동과 관련된 옵션이 모여 있습니다. 작동이 확인된 설정을 먼저 유지하고, 한 번에 하나씩 변경하면서 이유를 기록하세요. 현재 구성 파일에도 관련 매개변수가 정의되어 있다면 화면의 값만 확인하지 말고 구성 파일도 함께 살펴보세요.

DNS: 먼저 도메인 해석 경로 확인

무엇이며 어디에서 확인하나요: DNS는 도메인 이름을 IP 주소로 해석합니다. 관련 항목은 Settings와 현재 구성의 DNS 설정에서 확인할 수 있습니다. 도메인 해석 성공과 프록시 연결 성공은 별개의 단계입니다. 도메인을 해석할 수 없다면 서버 지연 시간이 정상이어도 대상 사이트에 접속할 수 없습니다.

설정 방법 및 주의사항: 먼저 현재 사용하는 DNS 설정과 설정 출처를 확인한 뒤 네트워크 요구사항에 맞게 조정합니다. 암호화된 DNS를 사용하더라도 DNS 서비스 자체에 연결할 수 있어야 합니다. 변경 후에는 같은 도메인으로 다시 테스트하고 캐시와 기존 연결이 결과에 영향을 줄 수 있다는 점을 고려하세요. DNS를 무작위로 바꾸는 것을 모든 문제의 해결책으로 삼지 마세요. 일부 도메인에서만 문제가 발생한다면 규칙과 응답 주소도 함께 확인해야 합니다.

Test Method: 테스트 결과 이해하기

무엇이며 어디에서 확인하나요: Test Method는 서버 테스트 방식을 지정합니다. Settings에서 해당 항목을 찾은 다음 서버 목록의 Connectivity Test로 테스트를 실행합니다. 테스트 결과는 선택한 방식의 연결 경로를 보여 주며 모든 앱 요청의 종합적인 상태를 나타내지는 않습니다.

설정 방법 및 주의사항: 서버를 비교할 때는 테스트 방식을 동일하게 유지하세요. 해당 방식에 대상 주소가 필요하다면 그 주소도 동일하게 사용합니다. 한 번 측정한 지연 시간이 낮다고 처리량이 높은 것은 아니며, 시간 초과는 테스트 대상이나 현재 네트워크 때문일 수도 있습니다. 여러 번 테스트한 뒤 실제 사용 요청으로 교차 확인하세요. 한 번 측정한 숫자만으로 연결 품질을 판단하지 마세요.

Today Widget: 시스템 바로가기

무엇이며 어디에서 확인하나요: Today Widget은 시스템의 위젯이나 바로가기 표시 및 조작과 관련된 설정입니다. Settings에서 현재 기기에 해당 항목이 표시되는지 확인하세요. 시스템에서 위젯을 추가할 수 있는지, 어떤 내용이 표시되는지는 현재 시스템과 앱에서 제공하는 기능에 따라 다릅니다.

설정 방법 및 주의사항: 해당 기능을 사용할 수 있다면 먼저 앱에서 서버와 라우팅 방식을 확인한 다음 시스템의 위젯 관리 화면에서 해당 위젯을 추가합니다. 추가한 뒤 한 번 조작해 앱 상태와 일치하는지 확인하세요. 바로가기는 조작 단계를 줄여 주지만 최초 VPN 구성 승인을 대신하지 않으며 서버 인증 정보를 설정해 주지도 않습니다.

iCloud: 동기화 범위와 덮어쓰기

무엇이며 어디에서 확인하나요: iCloud 관련 옵션은 지원되는 범위에서 앱 데이터를 동기화합니다. 먼저 Settings에서 동기화 메뉴와 안내를 확인한 다음 시스템 설정에서 해당 앱의 iCloud 사용 권한을 확인하세요. 실제 동기화 대상은 화면에 표시된 범위를 기준으로 합니다.

설정 방법 및 주의사항: 기기 간에 작업하기 전에 백업하고, 두 기기에서 같은 Apple Account를 사용하는지 확인한 뒤 동기화가 완료될 때까지 기다리세요. 두 기기에서 같은 항목을 동시에 대량으로 삭제하거나 이름을 바꾸지 마세요. 데이터가 보이지 않으면 다시 가져오기를 반복하기 전에 동기화 설정과 네트워크를 확인하세요. 동기화는 전체 백업이 아니며 앱 구입 기록, 구독 상태, 연결 인증 정보는 서로 대체할 수 없습니다.

Diagnostics: 단계별 연결 문제 진단

무엇인가요: Diagnostics는 연결 상태와 오류 단서를 확인하는 데 도움을 줍니다. 목적은 모든 설정을 한꺼번에 ‘수리’하는 것이 아니라 문제가 로컬 네트워크, 도메인 해석, 서버 연결, 규칙 선택, 대상 응답 중 어느 단계에서 발생하는지 구분하는 것입니다.

어디에서 확인하나요: Settings에서 Diagnostics 또는 관련 진단 메뉴를 찾아 화면에 표시되는 도구와 로그 항목을 확인합니다. 기록을 읽을 때 먼저 시간을 맞춰 방금 실행한 테스트에서 발생한 오류인지 확인하세요.

어떻게 설정하나요: 먼저 자동 연결 동작을 잠시 끄고 재현 가능한 테스트 조건을 만듭니다. 그런 다음 아래 순서대로 결과를 확인하세요. 각 단계를 마칠 때마다 결과를 기록하고 정상으로 확인된 단계는 반복해서 설정하지 않아도 됩니다.

1. 기기의 현재 네트워크가 작동하는지 확인하고 시스템 시간이 정확한지 살펴봅니다.
2. 서버 주소, 포트, 인증 항목과 기존 서비스 상태를 확인합니다.
3. Connectivity Test를 실행하고 사용한 Test Method를 기록합니다.
4. 대상을 하나 정해 접속한 뒤 Config와 잠시 Proxy를 사용했을 때의 결과를 비교합니다.
5. 같은 시간대의 진단 정보를 확인해 도메인 해석 실패, 연결 실패, 정책 선택 오류를 구분합니다.
6. 기존 라우팅 방식과 On Demand 설정을 복원한 뒤 평소 사용하는 환경에서 다시 확인합니다.

주의사항: 진단 자료를 공유하기 전에 구독 링크, 인증 정보, QR 코드 및 개인 활동을 추정할 수 있는 내용을 삭제하세요. 구성 파일 전체를 공개하지 마세요. 규칙 라우팅에서만 문제가 발생하면 구성을 먼저 확인하고, 모든 라우팅 방식에서 문제가 발생하면 공통으로 사용하는 네트워크와 서버부터 확인하세요. 구체적인 사례는 자주 묻는 질문을, 익숙하지 않은 키워드는 용어집을 참고하세요.