Shadowrocket 기능
라우팅 및 설정 안내

Global Routing은 요청을 어떤 방식으로 라우팅할지 결정합니다. 먼저 Home에서 현재 모드를 확인한 다음 Config, Proxy 또는 Direct를 선택하세요. 각 모드의 의미는 구성, 프록시, 직접 연결입니다. 실제 조작 시에는 앱에 표시된 영어 항목을 기준으로 구분하세요. 모드 선택과 연결 스위치는 별개입니다. Proxy를 선택했다고 연결이 성립하는 것은 아니며, Config를 선택했다고 특정 규칙 파일이 올바르게 활성화되는 것도 아닙니다.

일상적으로 규칙에 따라 요청을 나누려면 Config를 사용하세요. 선택한 서버가 특정 요청을 처리할 수 있는지 확인할 때는 Proxy를 임시로 적용해 비교할 수 있습니다. 기존 네트워크에서 직접 접속할 수 있는지 확인하려면 Direct로 비교하세요. 한 번에 조건 하나만 바꾸고, 같은 대상과 네트워크에서 반복 테스트해야 차이가 모드, 규칙 또는 서버 중 어디에서 비롯됐는지 판단할 수 있습니다.

비교를 마친 뒤 평소 사용하던 모드로 되돌리세요. 일부 네트워크 동작은 시스템, DNS, 연결 상태의 영향을 받으므로 Direct가 모든 설정을 끈다는 뜻은 아닙니다. Proxy를 선택해도 모든 앱 요청이 반드시 성공하는 것은 아닙니다. 모드는 라우팅 방향만 정하며, 잘못된 인증 정보나 사용할 수 없는 대상 서비스를 해결해 주지는 않습니다.

규칙 라우팅은 Config 모드에서 요청의 도메인, 주소 또는 기타 확인 가능한 특성에 따라 처리 정책을 정하는 방식입니다. Config에서 현재 파일과 규칙을 확인하고, 먼저 일치 조건을 읽은 뒤 마지막의 정책을 확인하세요. 일치 조건은 ‘어떤 요청인지’를, 정책은 ‘어떻게 처리할지’를 나타냅니다. 둘을 혼동하지 마세요. 일반적으로 더 구체적인 규칙을 앞에 배치해야 포괄적인 조건이 먼저 적용되는 일을 막을 수 있습니다.

도메인 및 주소별 조건 선택

DOMAIN은 지정된 도메인과 일치하고, DOMAIN-SUFFIX는 도메인 접미사를 기준으로 하며, DOMAIN-KEYWORD는 도메인에 포함된 키워드를 기준으로 일치합니다. IP-CIDR과 IP-CIDR6은 각각 주소 대역을 나타내며, GEOIP는 주소의 지리적 위치 데이터로 일치 여부를 판단합니다. USER-AGENT는 요청에서 해당 정보를 확인할 수 있어야 하므로 모든 요청에 이 조건이 있다고 가정할 수 없습니다. 규칙 유형은 실제로 확인할 수 있는 요청 특성에 맞춰 선택하세요.

DIRECT, PROXY, REJECT

DIRECT는 직접 연결, PROXY는 프록시 처리, REJECT는 거부를 뜻합니다. Config에서 사용자 지정 정책 이름을 사용한다면 해당 정책이 실제로 어떤 서버나 정책 그룹을 가리키는지도 확인하세요. FINAL은 앞선 규칙에 일치하지 않은 요청을 마지막으로 처리하는 항목이지, ‘우선순위가 가장 높은’ 규칙이 아닙니다. FINAL을 수정하면 별도로 지정되지 않은 많은 요청의 처리 방식이 달라질 수 있습니다.

DOMAIN,example.com,PROXY
DOMAIN-SUFFIX,example.org,DIRECT
IP-CIDR,192.168.0.0/16,DIRECT
FINAL,DIRECT

위 예시는 문법과 순서만 보여 주며 모든 네트워크에 적합한 완성형 설정은 아닙니다. 규칙을 추가한 뒤에는 명확한 대상을 지정해 일치 결과를 확인하세요. 도메인 규칙이 예상대로 작동하지 않으면 요청이 IP 주소로 시작됐는지, DNS가 예상한 결과를 반환하는지, 앞에서 먼저 일치하는 규칙이 있는지도 확인해야 합니다. 자세한 내용은 DNS 문제 해결 안내를 참고하세요.

Subscribe는 이미 보유한 구독 정보를 불러올 때, Add Server는 서버 하나를 추가할 때 사용합니다. 두 방법 모두 유효한 정보를 이미 가지고 있어야 합니다. 구독 링크는 이용 중인 서비스 제공업체에서 받으세요. 서버 주소, 포트, 비밀번호, 프로토콜, 전송 매개변수를 직접 입력할 때도 서버 측 정보와 일치해야 하며, 이름이나 흔한 기본값만 보고 추측해서 입력하면 안 됩니다.

Home에서 추가 메뉴를 열어 Add Server로 이동한 뒤, 보유한 정보에 맞는 Type을 선택하세요. 구독을 가져오려면 Subscribe 유형과 해당 필드를 사용하고 링크가 완전한지 확인한 후 저장하여 내용을 업데이트하세요. Scan QR Code로 QR 코드를 스캔할 수도 있지만, 먼저 코드의 출처와 내용을 확인해야 합니다. 가져오기가 끝나면 Home으로 돌아가 해당 그룹을 펼치고 사용할 서버를 선택한 다음 Connectivity Test와 실제 접속으로 확인하세요.

서버 목록에 항목이 표시된다는 것은 클라이언트가 내용을 읽었다는 뜻일 뿐, 해당 항목에 반드시 연결할 수 있다는 뜻은 아닙니다. 구독 업데이트에 실패하면 먼저 링크가 만료되거나 잘리지 않았는지, 현재 네트워크에서 구독 주소에 접속할 수 있는지 확인하세요. 서로 다른 매개변수를 시험하려고 그룹을 계속 중복 생성하지 마세요. 기존 항목을 남겨 두면 비교에 도움이 되지만, 테스트 대상이 뒤섞이지 않도록 실제로 선택한 서버를 기록하세요.

구독 가져오기와 Config 파일 가져오기는 서로 다른 작업입니다. 전자는 주로 서버 항목을 관리할 때 사용하고, 후자는 규칙과 기타 설정 내용을 포함합니다. 먼저 받은 자료의 종류를 확인한 뒤 해당 화면에서 작업하세요. 업데이트 오류가 발생하면 Subscribe 오류 해결도 참고하세요.

Shadowrocket은 Shadowsocks, VMess, VLESS, Trojan, HTTP, SOCKS5, WireGuard, Hysteria2 등 여러 프로토콜을 지원합니다. 프로토콜은 클라이언트와 서버가 데이터를 주고받는 방식을 정하며, 이름만 보고 선택하는 ‘속도 등급’이 아닙니다. Add Server에서 먼저 서버와 동일한 Type을 선택하고 해당 유형에 필요한 항목을 입력하세요. 현재 선택할 수 있는 항목은 앱에 표시된 내용을 기준으로 확인하세요.

TLS를 사용하는 연결은 서버 이름, 인증서, 관련 설정을 확인해야 합니다. SNI가 연결 주소와 항상 같은 것은 아니므로 보유한 설정에 따라 입력하세요. VMess, VLESS 등의 식별자와 전송 설정도 항목별로 맞춰야 합니다. WireGuard의 키와 주소 설정은 별도의 구조를 사용하므로 다른 프로토콜의 비밀번호를 그대로 입력할 수 없습니다. 가져온 항목 두 개가 비슷해 보여도 전송 방식이나 인증 필드가 다를 수 있습니다.

설정한 뒤 Connectivity Test를 실행하고 필요한 서비스를 실제로 확인하세요. 테스트에 실패하면 프로토콜을 연달아 바꾸기보다 각 매개변수를 하나씩 대조하세요. 인증서 검사를 완화하는 방법을 일반적인 해결책으로 사용하지 마세요. 서버 인증서나 이름이 일치하지 않으면 먼저 제공받은 정보와 서버 설정을 확인해야 합니다. 프로토콜 매개변수에는 민감한 정보가 포함되므로 문제를 확인할 때 필요한 오류 메시지만 공유하고 인증 필드는 가리세요.

Config는 규칙과 관련 설정 항목을 관리합니다. Config에서 로컬 또는 원격 설정을 열고 사용할 파일이 선택되어 있는지 확인한 다음, Home으로 돌아가 Global Routing을 Config로 설정하세요. 파일을 저장했더라도 활성화하지 않았거나 Proxy 모드에 머물러 있다면 해당 파일의 규칙 라우팅을 검증할 수 없습니다.

수정하기 전에 현재 정상적으로 작동하는 설정의 사본을 보관하고 변경할 항목을 표시하세요. 특정 도메인의 처리 방식만 바꾸려면 해당 규칙과 위치만 수정하고 DNS, 서버, FINAL을 동시에 변경하지 마세요. 저장 후 같은 대상을 다시 테스트해 결과를 확인한 다음 다음 항목을 조정하세요. 이렇게 하면 변경 사항과 결과를 연결해 파악할 수 있고 이전 설정으로 되돌리기도 쉽습니다.

원격 설정을 업데이트하면 규칙이나 다른 설정이 바뀔 수 있습니다. 직접 수정한 내용이 유지되는지는 설정의 출처와 업데이트 방식에 따라 확인해야 합니다. 개인 인증 정보가 포함된 전체 파일을 공개 토론 공간에 올리지 마세요. 파일 이름만으로 내용이 적합한지 판단해서도 안 됩니다. 출처와 역할이 분명하지 않은 항목은 먼저 설정 내용을 살펴본 후 활성화하세요. 규칙 문법 예시는 바로 사용할 수 있는 완성형 파일이 아닙니다.

On Demand는 설정한 네트워크 조건에 따라 연결 동작을 시작합니다. 요청별로 라우팅을 나누는 Config 규칙과는 설정 단계가 다릅니다. 전자는 언제 연결을 시도할지, 후자는 연결 중인 요청을 어떻게 처리할지 결정합니다. Wi-Fi, 셀룰러 네트워크 또는 특정 네트워크 조건에 따라 연결을 관리하려면 Settings의 On Demand에서 설정 가능한 항목을 확인하세요.

On Demand를 설정하기 전에 수동으로 연결을 켰을 때 정상적으로 작동하는지 확인하세요. 앱에서 제공하는 조건에 따라 필요한 네트워크 범위를 설정하고 저장한 뒤 해당 네트워크 환경에서 테스트하세요. 먼저 네트워크를 한 번 전환하는 것처럼 재현 가능한 조건 하나만 설정하고 작동을 확인한 다음 다른 조건을 추가하는 것이 좋습니다. 기본 연결이 성공하지 않은 상태에서 자동 연결에 의존해 문제를 해결하려 하지 마세요.

수동으로 연결을 껐는데 다시 연결이 시작되면 앱을 반복해서 재시작하기보다 먼저 On Demand 조건을 확인하세요. 테스트를 마친 뒤 주문형 연결을 중단하려면 관련 설정과 현재 연결 상태를 모두 확인해야 합니다. 네트워크 전환 후의 동작은 시스템 스케줄링과 네트워크 사용 가능 여부에도 영향을 받으므로, 조건을 설정했다고 해서 모든 환경에서 즉시 연결되는 것은 아닙니다. 연결 상태가 자주 바뀐다면 주문형 조건을 잠시 비활성화하고 수동 연결로 안정적인 비교 기준을 만드세요.

Data에서는 클라이언트가 기록한 데이터 사용량과 연결 활동을 확인할 수 있습니다. Data에서 현재 화면, 통계 범위, 분류 방식을 먼저 확인한 다음 업로드, 다운로드 및 관련 항목을 살펴보세요. 서버나 앱별 분류 항목은 현재 화면에서 제공하는 내용을 기준으로 확인하세요. 통계 수치는 작업 전후의 변화를 비교하는 데 유용하지만 서비스 제공업체의 청구 내역이나 시스템 전체 데이터 사용량과 동일하지는 않습니다.

라우팅을 확인하려면 현재 수치와 선택한 서버를 먼저 기록하고, 명확한 접속 작업을 한 번 수행한 뒤 Data에서 변화를 살펴보세요. 백그라운드 활동, 연결 오버헤드, 캐시 적중 여부, 통계 범위가 결과에 영향을 줄 수 있습니다. 특정 항목의 수치가 뚜렷하게 늘지 않았다고 해서 규칙이 작동하지 않는다고 단정할 수는 없습니다. 현재 Global Routing, 규칙 일치 여부, 실제 접속 상태를 함께 확인하세요.

Data의 누적 수치는 실시간 속도 테스트 결과가 아닙니다. 속도 저하를 점검하려면 네트워크와 대상을 동일하게 유지하면서 서버 테스트, 실제 요청에 걸린 시간, 데이터 사용량 변화를 각각 살펴보세요. 통계를 지우기 전에 비교에 필요한 데이터를 기록하고 삭제 작업의 범위를 확인하세요. 화면을 공유할 때는 서버 주소, 요청 도메인 및 기타 개인정보를 가리세요. 수치에 대한 자세한 설명은 기술 노트에서 확인할 수 있습니다.

Settings에는 앱 전체에 적용되는 설정이 모여 있지만 일부 동작은 현재 Config의 영향을 받을 수 있습니다. 변경 전에 기존 값을 기록하고 설정의 적용 범위를 확인하세요. 한 번에 하나씩만 변경하고 같은 네트워크와 대상을 사용해 다시 테스트하세요. 아래에서는 자주 사용하는 목적에 따른 확인 방법을 안내합니다. 구체적인 메뉴와 선택 항목은 현재 앱에 표시되는 내용을 기준으로 확인하세요.

DNS: 먼저 조회 경로 확인

DNS는 도메인을 주소로 변환하는 연결 전 주요 단계입니다. Settings에서 DNS 관련 항목을 확인하고 현재 Config에 관련 설정이 있는지도 살펴보세요. 도메인 접속만 실패하고 알고 있는 주소를 직접 입력한 테스트 결과는 다르다면, 프로토콜 비밀번호를 먼저 바꾸기보다 DNS 응답과 요청 경로를 중점적으로 확인하세요. 여러 DNS 주소를 무작정 추가하지 마세요. 사용할 조회 방식과 접근 가능 여부, 적용 범위를 명확히 한 뒤 같은 도메인으로 테스트하세요.

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

Test Method는 Connectivity Test에서 사용할 테스트 방식을 결정합니다. Settings에서 현재 선택된 방식과 관련 테스트 대상을 확인하고, 비교하려는 상황에 적합한지 살펴보세요. 방식에 따라 측정하는 단계가 다르므로 결과를 직접 비교하기 어려울 수 있으며, 테스트에 성공해도 모든 서비스를 사용할 수 있다는 뜻은 아닙니다. 서버를 비교할 때는 Test Method, 대상, 로컬 네트워크를 동일하게 유지하고 반복 테스트 결과를 살펴보세요. 테스트 조건의 차이를 서버 성능 변화로 오해하지 않도록 주의하세요.

Today Widget: 바로가기 확인

Today Widget은 시스템에서 제공하는 해당 위젯 바로가기와 함께 사용합니다. 먼저 Settings에서 관련 옵션을 확인한 다음 시스템의 위젯 관리 화면에서 추가할 수 있는 항목을 살펴보세요. 표시 여부와 구체적인 동작은 시스템 및 앱의 현재 지원 상황에 따라 달라지므로 기기에서 제공되는 항목을 기준으로 확인하세요. 바로가기를 사용해도 Global Routing과 Config의 의미는 바뀌지 않습니다. 위젯에서 조작한 뒤에도 Home으로 돌아가 서버와 연결 상태를 확인하세요.

iCloud: 동기화 전 범위 확인

직접 사용하는 기기 간에 동기화하려면 Settings에서 iCloud 관련 옵션을 확인하고 시스템에서 앱의 iCloud 사용을 허용했는지 확인하세요. 현재 동기화할 수 있는 항목의 범위를 먼저 파악한 후 활성화 여부를 결정하세요. 동기화는 구매 내역 복원이나 유일한 백업 수단이 아닙니다. 기기 간 작업을 시작하기 전에 정상 작동하는 설정을 보관하고, 동기화 결과를 확인한 뒤 이전 항목을 삭제하세요. 그래야 여러 기기의 수정 사항이 뒤섞이는 일을 막을 수 있습니다.

Diagnostics: 재현 가능한 단서 기록

Diagnostics는 연결 문제를 진단하는 기능입니다. 해당 메뉴에서 명확한 오류를 재현하고 당시 네트워크 유형, Global Routing, 선택한 서버, 오류 메시지를 기록하세요. 진단 자료에는 주소, 도메인, 인증 정보가 포함될 수 있으므로 공유하기 전에 항목별로 확인하고 개인정보를 가리세요. 도움을 요청할 때는 문제가 발생한 단계와 필요한 부분만 제공하고, 전체 구독 링크나 설정 파일 전체를 공개하지 마세요.