공식 매뉴얼 · 기능 및 설정

Shadowrocket
프록시 모드 및 설정 방법

평소에는 Config를 선택한 다음 규칙 설정과 현재 서버를 확인합니다. 문제를 임시로 진단할 때만 Proxy 또는 Direct로 전환하고, 설정은 한 번에 하나씩 변경하세요.

iPhone / iPad / Mac / Windows / Android / Linux에서 사용할 수 있습니다. 아래 조작 경로는 iPhone / iPad를 기준으로 하며, 다른 플랫폼에서는 해당 화면에서 같은 이름의 기능을 찾으세요. 옵션의 위치와 지원 범위는 사용 중인 클라이언트에 따라 다를 수 있습니다.

모드, 규칙, 서버의 역할 구분

Shadowrocket의 연결 결과는 하나의 스위치만으로 결정되지 않습니다. Global Routing은 전체 트래픽 처리 방식을 정하고, Config의 규칙은 각 요청에 적용할 정책을 정합니다. Home에서 선택한 서버는 프록시가 필요한 연결의 실제 출구가 됩니다. 세 기능의 역할은 서로 다릅니다. 서버를 바꿔도 잘못된 규칙이 자동으로 수정되지 않으며, 구독을 업데이트해도 현재 Config가 바뀌는 것은 아닙니다.

시작하기 전에 사용할 구독이나 서버 정보를 준비해야 합니다. 이 사이트는 노드나 구독을 제공·판매·추천하지 않습니다. 클라이언트의 일회성 구매와 회선 요금제는 별개이며, 클라이언트 구매 비용이 기존 회선의 이용 가능 여부를 보장하지도 않습니다.

Global Routing의 세 가지 모드

구성은 Config, 프록시는 Proxy, 직접 연결은 Direct입니다. 설명은 한국어로 제공하지만, 조작할 때는 화면에 표시된 영문 옵션을 확인하세요.

무엇인가요: Global Routing은 전체 라우팅 방식을 선택하는 기능이며, 서버 프로토콜 설정이 아닙니다. 어디에서 설정하나요: Home에서 Global Routing을 찾으세요. 어떻게 설정하나요: 평소 규칙에 따라 트래픽을 처리하려면 Config를 선택하세요. 프록시와 원래 네트워크의 동작을 비교할 때만 Proxy 또는 Direct를 잠시 사용하세요.

옵션처리 방식사용 상황확인할 점
Config현재 Config의 규칙에 따라 연결 정책을 결정합니다.평소 규칙 분기에 사용합니다. 도메인이나 주소별로 연결 방식을 나눌 수 있습니다.현재 Config가 올바른지, 규칙 순서가 적절한지, 정책 대상이 사용 가능한지 확인하세요.
Proxy클라이언트가 처리하는 트래픽을 프록시 모드로 연결합니다.규칙 분기 때문에 문제가 생겼는지 잠시 확인할 때 사용합니다.현재 서버에 연결할 수 있는지 확인하세요. 이 모드가 기기의 모든 트래픽을 처리한다고 생각하지 마세요.
Direct클라이언트가 처리하는 트래픽을 직접 연결 모드로 처리합니다.원래 네트워크와 프록시 경로를 잠시 비교할 때 사용합니다.원래 네트워크에서 대상에 접속할 수 있는지 확인하세요. 이 모드는 연결 스위치를 끄는 것과 다릅니다.

주의할 점: 어떤 웹사이트가 Proxy에서는 정상 작동하지만 Config에서는 문제가 생긴다면, 먼저 적용된 규칙과 정책을 확인해 보세요. 이는 문제를 좁히기 위한 단서일 뿐, Config 오류로 단정할 수는 없습니다. DNS 조회나 이미 연결된 세션도 결과에 영향을 줄 수 있습니다. 모드를 바꾼 뒤 요청을 새로 보내고, 필요하면 기존 연결을 종료한 다음 같은 조건에서 비교하세요.

문제 확인이 끝나면 원래 사용하던 모드로 되돌리세요. Proxy를 계속 사용하면 기존 규칙 분기 동작이 달라집니다. Direct를 계속 사용하면 프록시가 필요한 요청도 직접 연결될 수 있습니다. 모드를 바꿔도 누락된 서버 정보가 채워지지는 않습니다. TLS, 전송 방식, 인증 정보도 올바르게 설정해야 합니다.

규칙 분기: 매칭 조건과 실행 정책

먼저 요청에 어떤 규칙이 적용되는지 확인한 다음, 해당 규칙이 지정한 정책을 살펴보세요.

규칙 유형에 따라 매칭 대상이 달라집니다

DOMAIN은 지정된 도메인과 매칭되고, DOMAIN-SUFFIX는 도메인과 하위 도메인에 매칭됩니다. DOMAIN-KEYWORD는 도메인에 포함된 키워드로 매칭합니다. IP-CIDR과 IP-CIDR6은 각각 IPv4 및 IPv6 주소 범위를 나타내며, GEOIP는 주소가 속한 지역을 기준으로 매칭합니다. USER-AGENT는 요청의 해당 필드를 사용합니다. 적용 범위는 트래픽을 식별할 수 있는지에 따라 달라지므로, 모든 암호화 연결을 식별하는 범용 방식으로 사용할 수는 없습니다.

정책에 따라 연결 처리 방식이 결정됩니다

DIRECT는 직접 연결, PROXY는 해당 프록시 정책에 따른 처리, REJECT는 연결 거부를 뜻합니다. 규칙에서 Config에 정의된 정책 그룹을 참조할 수도 있으므로 그룹 이름과 그룹 내 선택 항목도 확인하세요. FINAL은 앞선 규칙에 매칭되지 않은 요청을 처리합니다. 우선순위가 더 높은 강제 규칙은 아니므로 보통 규칙 목록의 마지막에 둡니다.

어디에서 설정하나요: Config로 이동해 현재 사용 중인 Config를 확인한 다음, 규칙을 살펴보거나 편집하세요. 어떻게 설정하나요: 먼저 Config를 복사해 두고, 적용 범위가 좁고 목적이 분명한 규칙을 일반 규칙보다 앞에 배치하세요. 규칙은 보통 위에서 아래로 확인하며, 매칭된 규칙의 정책을 적용합니다. 따라서 특정 도메인 규칙보다 앞에 범위가 넓은 규칙이 있으면 해당 규칙이 먼저 적용되어 원하는 결과를 얻지 못할 수 있습니다.

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

위 예시는 문법과 순서만 설명합니다. example.com과 하위 도메인에는 PROXY를 적용하고, 이어서 GEOIP 규칙으로 판단한 뒤, 나머지 요청은 FINAL로 처리합니다. 모든 네트워크에 맞는 완성된 Config는 아닙니다. 수정 후 대상 도메인에 새 요청을 보내고 연결 기록에서 적용된 정책을 확인하세요. Home에 연결됨으로 표시되는지만 확인해서는 안 됩니다.

주의할 점: 주소 기반 규칙 중에는 DNS 조회 결과에 의존하는 규칙이 있어 DNS 설정이 매칭 결과에 영향을 줄 수 있습니다. 문제가 생겼다고 비슷한 규칙을 연달아 추가하지 마세요. 먼저 도메인 이름이 정확한지, 대상 정책이 존재하는지 확인한 다음 규칙 순서와 캐시를 점검하세요. 자세한 키워드는 용어 빠른 참조에서 확인할 수 있습니다.

구독 및 서버 관리

Subscribe에서 여러 항목이 포함된 구독 소스를 관리하고, Add Server에서 개별 서버 정보를 관리합니다.

무엇인가요: 구독은 서버 목록을 가져오고 업데이트하는 소스입니다. 개별 서버에는 프로토콜, 주소, 포트, 인증 등의 연결 정보가 포함됩니다. 구독을 업데이트하면 해당 소스의 항목이 갱신되지만, 서버가 반드시 사용 가능해지는 것은 아니며 Config의 규칙이 업데이트되는 것도 아닙니다.

어디에서 설정하나요: Home의 추가 메뉴에서 Subscribe를 찾으세요. 서버를 직접 추가하려면 Add Server, QR 코드를 가져오려면 Scan QR Code를 사용합니다. 어떻게 설정하나요: 서비스 제공자가 전달한 전체 구독 URL을 해당 입력란에 붙여 넣고 저장한 다음, 목록을 업데이트하고 사용할 서버를 선택하세요. 서버를 직접 추가할 때는 먼저 프로토콜을 선택한 뒤, 보유한 정보에 따라 주소와 인증 정보를 입력합니다. VLESS, VMess, Trojan 등은 프로토콜마다 입력 항목이 다르므로 서로 바꿔 적용할 수 없습니다.

  1. 가져오기 전에 정보가 모두 있는지 확인하세요. 특히 복사한 내용에 공백, 줄바꿈, 설명 문구가 섞이지 않았는지 살펴보세요.
  2. 가져온 뒤 그룹과 항목 이름을 확인해 의도한 소스의 내용인지 살펴보고, 같은 구독을 중복으로 가져오지 않도록 주의하세요.
  3. 업데이트가 필요하면 해당 구독을 업데이트하세요. 클라이언트에 자동 업데이트 옵션이 있으면 필요에 따라 설정할 수 있습니다.
  4. 서버를 선택한 뒤 Connectivity Test를 실행하고 실제 요청으로 확인하세요. 테스트를 통과해도 모든 대상에 접속할 수 있다는 뜻은 아닙니다.

주의할 점: 구독 링크에는 개인 인증 정보가 포함될 수 있습니다. 공개 스크린샷, 로그, 게시물에 노출하지 마세요. 구독으로 생성된 항목은 업데이트 과정에서 덮어써질 수 있습니다. 설정을 계속 유지해야 한다면 먼저 별도 사본을 저장하고, 이후 관리 방식과 호환되는지 확인하세요. 구독을 삭제하기 전에는 서버를 따로 보관해야 하는지 확인해 ‘업데이트’를 ‘삭제’로 잘못 처리하지 않도록 주의하세요.

목록이 비어 있다면 먼저 구독 소스 URL과 응답 내용을 확인하고, 그다음 사용 중인 서비스 상태를 살펴보세요. 목록은 있지만 연결에 실패한다면 서버 정보와 네트워크를 점검하세요. 두 문제는 발생 지점이 다르므로, 구독을 반복해서 가져오는 방식으로 한꺼번에 해결하려 하지 마세요. 자세한 가져오기 순서는 시작하기를 확인하세요.

On Demand: 필요할 때 연결

연결을 시도할 시점을 제어하는 기능으로, 요청의 연결 경로를 정하는 규칙과는 별개의 설정입니다.

먼저 수동 연결이 정상인지 확인하세요

무엇인가요: On Demand는 시스템이 지원하는 조건에 따라 연결 동작을 시작합니다. 어디에서 설정하나요: Settings에서 On Demand를 찾으세요. 설정할 수 있는 조건은 사용 중인 시스템과 클라이언트 화면에 따라 다릅니다. 어떻게 설정하나요: 먼저 자동 실행을 끄고 서버, Config, 연결 권한이 정상인지 수동으로 확인한 다음, 필요한 조건을 하나씩 추가하세요.

그다음 실행 및 중지 조건을 확인하세요

주의할 점: On Demand가 활성화된 상태에서 수동으로 연결을 끊어도 조건이 계속 충족되면 다시 연결될 수 있습니다. 스위치가 작동하지 않는다는 뜻은 아닙니다. 테스트할 때는 현재 네트워크 조건을 기록하고, 조건에 진입했을 때와 벗어났을 때의 결과를 각각 확인하세요. 자동 연결을 잠시 중지하려면 먼저 On Demand 조건을 수정하거나 기능을 끈 다음 연결 스위치를 조작하세요. 그래야 반복 실행을 서버 문제로 오해하지 않습니다.

네트워크가 바뀌어도 기존 연결이 그대로 유지된다고 보장할 수는 없습니다. Wi-Fi와 셀룰러 네트워크 사이를 전환하면 연결을 다시 설정할 수 있으며, 백그라운드 동작은 시스템 스케줄링의 영향을 받습니다. On Demand는 만료된 구독이나 서버를 복구하지 않으며 규칙 설정을 대신하지도 않습니다. 실행 조건을 테스트한 뒤에도 실제 요청에 예상한 정책이 적용되는지 확인하세요.

Data: 트래픽 통계

무엇인가요: Data에서는 클라이언트가 기록한 트래픽을 확인할 수 있습니다. 일정 시간 동안 요청이 발생했는지, 트래픽 분포가 예상과 맞는지 살펴보는 데 도움이 됩니다. 어디에서 확인하나요: Data를 열어 현재 화면에서 제공하는 통계 항목을 확인하세요. 세부 항목과 집계 기간은 플랫폼마다 다를 수 있습니다.

어떻게 확인하나요: 먼저 화면에 누적값이 표시되는지, 현재 기간의 값이 표시되는지 확인하세요. 재현할 수 있는 요청을 한 번 보내고 전후 변화를 비교합니다. 통계를 초기화하려면 보관할 수치를 먼저 기록해 두세요. 초기화 후에는 문제가 발생했을 때의 기준값을 확인할 수 없습니다. 다운로드와 업로드 방향을 구분하고, 순간 속도와 누적 트래픽을 혼동하지 마세요.

주의할 점: 클라이언트, 기기 운영체제, 서비스 제공자의 기록은 집계 범위가 서로 다를 수 있습니다. 프로토콜 오버헤드, 연결 시간, 집계 기간도 다를 수 있으므로 Data를 회선 요금 청구서처럼 해석해서는 안 됩니다. 트래픽이 늘었다면 활동이 있었다는 뜻일 뿐, 특정 웹 요청이 성공했다는 증거는 아닙니다. 트래픽이 늘지 않았다면 올바른 기간과 기록 범위를 보고 있는지 먼저 확인하세요.

Settings 주요 항목

변경 전 값을 기록하고 한 번에 하나씩 수정하세요. Config 내부 설정과 전체 설정을 함께 확인해야 합니다.

DNS: 도메인 조회

무엇인가요: DNS는 도메인 이름을 주소로 변환하며 연결과 일부 규칙 판단의 전제 단계입니다. 어디에서 설정하나요: Settings에서 DNS를 찾고, 현재 Config에 관련 설정이 있는지도 확인하세요. 어떻게 설정하나요: 실제로 적용되는 설정 출처를 먼저 확인한 다음, 네트워크 환경에서 접속 가능한 DNS 서비스를 입력하세요. 되돌릴 수 있도록 기존 값도 기록해 두세요.

주의할 점: ‘연결 실패’만으로 DNS를 바꾸지 마세요. 도메인 조회 성공과 대상 연결 성공은 서로 다른 단계입니다. 설정을 바꾼 뒤에도 캐시나 기존 연결이 영향을 줄 수 있습니다. IPv6 문제라면 주소와 연결 경로가 맞는지 확인하고 DNS, 프로토콜, 규칙을 한꺼번에 변경하지 마세요.

Test Method: 테스트 방식

무엇인가요: Test Method는 해당 연결 테스트의 방식을 정합니다. 어디에서 설정하나요: Settings에서 Test Method를 찾고 Home의 Connectivity Test와 함께 사용하세요. 어떻게 설정하나요: 현재 화면에서 제공하는 방식을 선택한 다음, 같은 네트워크와 서버에서 비슷한 시간대에 결과를 비교하세요.

주의할 점: 테스트 방식마다 측정 대상이 다를 수 있으므로 수치를 직접 비교할 수 없습니다. 테스트 시간 초과는 테스트 대상의 영향을 받을 수 있으며, 테스트 성공이 모든 웹사이트나 앱의 정상 작동을 보장하지는 않습니다. 최종 판단은 실제 대상에 보낸 요청과 진단 기록을 기준으로 하세요.

Today Widget: 빠른 실행

무엇인가요: Today Widget은 시스템에서 지원하는 경우 빠르게 조작할 수 있는 기능입니다. 어디에서 설정하나요: Settings에서 Today Widget을 찾고, 시스템에서 허용하는 위젯 관리 화면에서 추가할 수 있는지 확인하세요. 어떻게 설정하나요: 현재 화면에 표시된 옵션에 따라 설정하고, 먼저 앱에서 연결을 확인한 뒤 위젯 동작을 테스트하세요.

주의할 점: 위젯을 추가하거나 새로 고칠 수 있는지, 어떤 정보가 표시되는지는 시스템 버전에 따라 다릅니다. 현재 시스템에 해당 메뉴가 없다면 존재하지 않는 스위치를 찾을 필요가 없습니다. Home에서 연결을 조작하면 됩니다. 위젯 표시가 늦을 수 있으므로 연결 상태를 확인할 때는 앱으로 돌아가 확인하세요.

iCloud: Config 동기화

무엇인가요: iCloud 기능은 지원되는 Apple 기기 사이에서 클라이언트가 허용한 데이터를 저장하거나 동기화합니다. 어디에서 설정하나요: Settings에서 iCloud를 찾고 시스템의 iCloud 권한과 계정 상태를 확인하세요. 어떻게 설정하나요: 작업 전에 로컬 사본을 보관하고, 업로드·복원·동기화 중 어떤 작업을 할지 확인한 다음 화면 안내에 따라 진행하세요.

주의할 점: 동기화 범위는 화면의 안내를 확인하세요. 모든 서버 인증 정보와 실행 상태가 동기화된다고 가정하지 마세요. 여러 기기에서 편집하면 내용이 덮어써지거나 충돌할 수 있으므로, 먼저 유지할 사본을 정하세요. 여기서 말하는 iCloud 기능은 모든 플랫폼 간 Config 공유 기능이 아니며 App Store 구매 내역을 복원하는 메뉴도 아닙니다.

Diagnostics: 문제 발생 단계 확인

무엇인가요: Diagnostics는 현재 클라이언트가 지원하는 진단 정보를 제공해 DNS 조회, 연결, 인증, 규칙 처리 등의 어느 단계에서 문제가 발생했는지 확인하는 데 도움을 줍니다. 어디에서 확인하나요: Settings에서 Diagnostics를 찾으세요. 현재 플랫폼에서 다른 위치에 표시된다면 실제 화면을 기준으로 확인하세요. 어떻게 사용하나요: 필요한 진단 기능을 켜거나 실행하고 문제를 한 번 재현한 뒤, 해당 시간대의 결과를 확인하세요.

  1. 문제가 발생한 네트워크 환경, Global Routing 옵션, 현재 Config와 서버를 기록해 비교할 조건을 먼저 정하세요.
  2. 명확한 대상 하나에만 접속하고 오류가 발생한 시간과 메시지를 기록하세요. 여러 테스트를 동시에 실행하면 확인을 방해할 수 있습니다.
  3. 먼저 도메인이 조회되는지 확인한 다음 연결이 설정되는지 살펴보세요. 인증 또는 TLS 오류가 표시되면 서버 정보와 기기 시간을 확인하세요.
  4. Config에서만 문제가 발생한다면 규칙과 정책을 확인하세요. Proxy에서도 문제가 발생한다면 서버와 네트워크 경로를 점검하세요.

주의할 점: 진단 결과는 문제를 좁히기 위한 단서이지 자동 복구 결과가 아닙니다. 단일 시간 초과 메시지만으로 네트워크 전체를 사용할 수 없다고 판단하지 마세요. 기록을 보관하기 전 구독 링크, 서버 주소, 인증 정보가 포함되어 있는지 확인하고, 공유하기 전에 민감한 내용을 삭제하세요. 점검이 끝나면 임시로 추가한 기록 옵션을 적절한 설정으로 되돌리세요.

자주 쓰는 설정 점검 순서

설정을 여러 개 한꺼번에 초기화하기보다 단계별로 확인하면 문제를 재현하고 원래대로 되돌리기 쉽습니다.

  1. 소스를 확인하세요. 기존 구독을 업데이트할 수 있는지, 서버 정보가 모두 입력되었는지, 오래된 항목을 잘못 선택하지 않았는지 확인합니다.
  2. 모드를 확인하세요. 평소에 Config를 사용하고 있는지, 임시 테스트 후 원래 모드로 되돌리는 것을 잊지 않았는지 확인합니다.
  3. Config를 확인하세요. 현재 활성화된 Config가 방금 수정한 파일인지, 정책 이름이 실제로 존재하는지 확인합니다.
  4. DNS 조회와 경로를 확인하세요. DNS, 서버 연결 상태, 실제 대상에 보낸 요청을 각각 점검하세요. 테스트 수치 하나만으로 모든 결과를 판단하지 마세요.
  5. 자동 동작을 확인하세요. On Demand가 다시 연결을 시작하는지, iCloud나 구독 업데이트가 로컬 변경 사항을 덮어쓰지 않았는지 확인합니다.
  6. 기록하고 되돌리세요. 설정을 하나 변경할 때마다 다시 테스트하고 효과가 있었는지 기록하세요. 개선되지 않았다면 기존 값으로 되돌린 다음 다음 단계를 점검합니다.

처음 가져오기를 완료하지 않았다면 시작하기를 먼저 확인하세요. 규칙 키워드를 알아보려면 용어 빠른 참조를 참고하세요. 스토어에서 앱을 받거나 시스템에 설치하거나 구매 항목을 복원하는 데 문제가 있다면 전체 플랫폼 다운로드 안내와 자주 묻는 질문을 확인하세요. 이러한 문제는 Global Routing의 역할과 다르므로 규칙을 다시 작성해 해결할 필요가 없습니다.