SHADOWROCKET / OFFICIAL MANUAL

Shadowrocket 프록시 모드와 주요 설정

먼저 Global Routing을 확인한 다음 규칙, 서버, DNS를 점검하세요. 연결 스위치가 켜져 있어도 모든 요청에 같은 정책이 적용되는 것은 아닙니다.

이 페이지는 ‘무엇인지, 어디에서 찾는지, 어떻게 설정하는지, 무엇을 주의해야 하는지’ 순서로 구성되어 있습니다. 아래 경로는 iPhone / iPad의 화면 용어를 기준으로 합니다. Mac, Windows, Android, Linux에서도 라우팅 개념은 동일하게 적용되지만, 구체적인 메뉴와 사용 가능한 옵션은 플랫폼의 현재 화면을 기준으로 확인하세요.

01 / GLOBAL ROUTING

Config, Proxy, Direct세 가지 모드의 차이

Global Routing은 트래픽을 처리할 방식을 결정하고, 서버 선택은 프록시가 필요할 때 사용할 출구를 정합니다. 두 설정은 서로 다릅니다.

무엇인가요: 세 가지 모드는 화면의 Config, Proxy, Direct에 해당합니다. Config는 현재 구성의 규칙에 따라 트래픽을 분기하고, Proxy는 요청을 모두 프록시 경로로 보내는 점검에 사용하며, Direct는 모두 직접 연결하는 방식으로 비교할 때 사용합니다. 평소에는 대상별로 다르게 처리해야 한다면 Config를 선택한 뒤 해당 규칙을 확인하세요.

어디서 어떻게 설정하나요: Home에서 Global Routing을 찾아 원하는 모드를 선택한 다음 Home으로 돌아와 서버 선택과 연결 스위치를 확인합니다. Config를 선택하기 전에 Config 화면에서 필요한 파일이 활성화되어 있는지 확인하세요. 파일을 가져오기만 하고 활성화하지 않았다면 규칙이 적용된다고 볼 수 없습니다.

Global Routing 세 가지 모드의 사용 상황과 점검 항목
한국어 설명 / 화면 용어처리 방식사용 상황점검 항목
구성 / Config현재 구성의 규칙에 따라 정책을 결정합니다.도메인이나 주소별로 다르게 처리해야 하는 일상적인 트래픽 분기에 적합합니다.활성화된 구성, 규칙 순서, 정책 대상.
프록시 / Proxy가로채는 요청을 모두 프록시 경로로 보냅니다.선택한 서버가 대상 요청을 처리할 수 있는지 잠시 확인할 때 사용합니다.서버 설정값, 연결 가능 여부, DNS, 대상 서비스.
직접 연결 / Direct가로채는 요청을 현재 네트워크로 직접 보냅니다.현재 네트워크에서 연결할 수 있는지 비교해 문제 범위를 좁힙니다.현재 Wi-Fi 또는 모바일 네트워크의 연결 상태.

주의사항: 여기서 ‘모두’란 클라이언트가 실제로 가로채는 트래픽을 뜻하며, 기기의 모든 시스템 활동을 보장하는 것은 아닙니다. Direct를 선택해도 연결 스위치가 꺼지는 것은 아니며, 클라이언트가 요청 처리와 기록에 계속 관여할 수 있습니다. 테스트가 끝나면 원래 모드로 되돌려 일시적인 변경이 이후 판단에 영향을 주지 않도록 하세요. Proxy에서는 접속되지만 Config에서는 접속되지 않는다면 서버 정보를 전부 다시 만들기보다 먼저 매칭 규칙과 정책을 확인하세요.

02 / RULES & POLICIES

규칙은 매칭 조건을 정하고, 정책은 처리 방식을 정합니다

무엇인가요: 규칙은 매칭 유형, 매칭할 내용, 정책으로 구성됩니다. DOMAIN은 도메인 전체와 일치하고, DOMAIN-SUFFIX는 도메인 접미사와 하위 도메인에 일치하며, DOMAIN-KEYWORD는 도메인에 포함된 키워드로 매칭합니다. 접미사 규칙은 범위가 넓은 키워드 규칙보다 검토하기 쉬운 경우가 많습니다. 입력할 때는 도메인 부분만 쓰고 프로토콜 접두사나 웹 경로는 넣지 마세요.

IP-CIDR과 IP-CIDR6은 각각 IPv4 및 IPv6 네트워크 대역에 사용합니다. GEOIP는 IP 주소의 지역 데이터베이스를 기준으로 매칭하므로 데이터베이스와 주소 확인 결과에 따라 달라질 수 있습니다. USER-AGENT는 요청에서 해당 필드를 읽을 수 있어야 하며 모든 연결이 이 조건을 충족하는 것은 아닙니다. 따라서 일반적인 앱 식별 방법으로 간주해서는 안 됩니다.

어디서 어떻게 설정하나요: Config에서 현재 사용하는 구성을 열고 규칙 내용과 순서를 확인합니다. 규칙은 일반적으로 위에서 아래로 매칭되며, 먼저 일치한 규칙의 정책이 적용됩니다. 따라서 구체적인 예외 규칙은 범위가 넓은 규칙보다 위에 두고, 최종 기본 규칙은 맨 아래에 배치하세요. 수정 전에는 원본 파일을 보관하고 한 번에 한 종류의 조건만 변경하세요. 저장한 뒤에도 해당 구성이 계속 활성화되어 있는지 확인합니다.

규칙 구문 예시

아래 예시는 순서와 정책을 설명하기 위한 것으로, 완전한 구성 파일이 아니며 실제 서버나 연결 정보를 나타내지 않습니다.

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

주의사항: PROXY는 프록시 정책으로 전달, DIRECT는 직접 연결, REJECT는 요청 거부를 뜻합니다. 구성에서 사용자 지정 정책 그룹 이름을 참조할 수도 있으므로 해당 이름이 실제로 존재하는지 확인해야 합니다. FINAL은 앞선 규칙에 매칭되지 않은 요청에 적용되는 기본 처리이며, ‘모든 규칙을 다시 테스트’한다는 뜻이 아닙니다. 키워드 매칭 범위가 너무 넓으면 관계없는 대상에 영향을 줄 수 있습니다. 문제가 생기면 규칙에 대상 이름이 있는지만 확인하지 말고 요청이 실제로 어떤 규칙에 매칭됐는지 살펴보세요.

03 / SUBSCRIBE & SERVER

구독 업데이트와 서버 설정분리해서 관리하기

무엇인가요: 서버 항목에는 연결에 필요한 프로토콜, 주소, 포트, 인증 정보가 저장됩니다. Subscribe는 사용자가 보유한 구독 주소에서 서버 목록을 업데이트하는 기능이고, Config는 규칙 등의 구성 내용을 관리합니다. 구독을 가져오는 데 성공해도 구성이 선택된 것은 아닙니다. 구성을 활성화했더라도 해당 구성에서 참조하는 서버가 반드시 존재하는 것은 아닙니다.

어디서 어떻게 설정하나요: Home에서 추가 메뉴를 열고 Add Server로 이동합니다. 기존 구독을 가져오려면 Subscribe를 선택하고 서비스 제공자가 안내한 주소를 빠짐없이 붙여 넣은 다음 구분하기 쉬운 이름을 입력해 저장합니다. 업데이트가 끝나면 Home으로 돌아와 그룹이 표시되는지 확인하고 사용할 서버를 선택하세요. 이미 단일 서버의 설정값이 있다면 해당 Type을 선택한 뒤 제공된 정보를 그대로 입력합니다. Scan QR Code를 사용하는 경우에도 저장 전에 인식된 유형과 주소를 확인하세요.

Shadowsocks, VMess, VLESS, Trojan, HTTP, SOCKS5, WireGuard, Hysteria2 등은 프로토콜마다 필요한 입력 항목이 다릅니다. 현재 플랫폼에 표시된 Type과 보유한 설정값을 기준으로 입력하고, 서버 주소가 같다는 이유만으로 프로토콜을 바꾸지 마세요. TLS, SNI, 전송 경로 등의 추가 항목은 제공된 원래 값을 그대로 사용하고 이름만 보고 추측하지 마세요.

주의사항: 구독은 업데이트 수단이지 연결 성공을 보장하지 않습니다. 업데이트에 실패하면 먼저 주소에 접속할 수 없는지, 인증이 만료되었는지, 응답 내용을 해석하지 못하는지 확인하세요. 업데이트는 성공했지만 연결되지 않는다면 선택한 항목과 설정값을 점검합니다. 구독을 업데이트하면 그룹 내 항목을 직접 수정한 내용이 덮어써질 수 있으므로 계속 유지할 변경 사항은 미리 기록하거나 별도로 저장하세요. 구독 주소, QR 코드, 내보낸 파일에는 인증 정보가 포함될 수 있으니 문제를 공유할 때 민감한 내용을 가리세요.

04 / ON DEMAND

On Demand네트워크 조건에 따라 연결 실행

무엇인가요: On Demand는 네트워크 조건에 따라 연결 동작을 실행하는 기능입니다. ‘언제 연결할지’는 On Demand가 정하고, ‘연결 후 트래픽을 어떻게 분기할지’는 Global Routing이 정합니다. On Demand를 켜도 서버나 구성이 자동으로 추가되지는 않으며 현재 연결이 정상인지 확인해 주지도 않습니다.

어디서 어떻게 설정하나요: Settings에서 On Demand를 찾아 현재 화면에 표시된 조건을 먼저 확인한 뒤 Wi-Fi, 모바일 네트워크 또는 특정 네트워크 조건을 필요에 따라 설정합니다. 처음에는 조건 하나만 추가하고 원하는 동작을 기록하는 것이 좋습니다. 먼저 특정 Wi-Fi 조건이 예상대로 실행되는지 확인한 다음 다른 네트워크 조건을 추가하면, 여러 조건이 겹쳐 문제 원인을 찾기 어려워지는 일을 줄일 수 있습니다.

저장한 뒤 실제로 네트워크를 한 번 전환해 시스템 연결 상태와 Shadowrocket의 상태가 일치하는지 확인하세요. 테스트 전에 수동 연결이 정상적으로 작동하는지 먼저 확인합니다. 수동 연결부터 실패한다면 자동 실행 조건을 더 추가해도 문제만 뒤섞일 수 있습니다. 플랫폼마다 백그라운드 동작과 사용할 수 있는 조건이 다를 수 있으므로 기기에 표시된 옵션에 맞춰 설정하세요.

주의사항: 수동으로 연결을 끊어도 조건이 여전히 충족되면 시스템이 다시 연결할 수 있습니다. 이는 스위치가 작동하지 않는다는 뜻이 아닙니다. 일시 중지하려면 먼저 On Demand를 끈 다음 연결을 끊으세요. 공용 Wi-Fi에서 로그인 인증이 필요한 경우에는 네트워크 로그인을 먼저 마친 뒤 자동 연결을 테스트합니다. 라우팅 모드, DNS, 실행 조건을 한꺼번에 변경하지 마세요.

05 / DATA

Data 트래픽 통계상태 확인용이며 요청 기록을 대체하지 않습니다

무엇인가요: Data에는 클라이언트가 기록한 트래픽 수치가 표시되며 업로드, 다운로드, 누적량의 변화를 확인할 수 있습니다. 현재 플랫폼에서 서버별 또는 앱별 보기를 제공한다면 출구 사용량과 트래픽 출처를 각각 확인할 수 있습니다. 앱 분류 범위는 시스템 기능에 따라 달라지므로 기기의 모든 활동이 완벽하게 식별된다고 볼 수는 없습니다.

어디서 어떻게 설정하나요: Data를 열어 현재 보기, 통계 범위, 단위를 확인한 뒤 수치를 살펴봅니다. 업로드는 기기에서 전송한 데이터이고 다운로드는 기기가 받은 데이터입니다. 순간 전송 속도와 누적 트래픽은 서로 다른 지표이므로 직접 비교할 수 없습니다. 규칙을 테스트할 때는 먼저 현재 수치를 기록하고 대상에 한 번 접속한 뒤 관련 항목이 증가했는지 확인하세요. 정책은 요청 기록과 함께 살펴봅니다.

새 관찰 구간을 시작하려면 화면의 초기화 기능을 사용하기 전에 필요한 수치를 저장하고 초기화 대상과 범위를 확인하세요. 모든 통계가 설치한 날부터 계산된다고 가정하거나 연결할 때마다 초기화된다고 생각하지 마세요. 시작 시점은 현재 화면과 초기화 동작을 기준으로 확인해야 합니다. 구독에 표시되는 사용량과 유효 기간은 구독 응답에서 제공된 정보이며 Data의 로컬 통계와는 별개입니다.

주의사항: 프로토콜 오버헤드, 재시도, 통계 기준, 측정 시간의 차이로 인해 Data, 시스템 설정, 서비스 제공자의 수치가 서로 다를 수 있습니다. 트래픽이 증가했다는 사실만으로 특정 도메인 규칙이 매칭됐다고 단정할 수 없습니다. 캐시된 콘텐츠를 불러온 경우 페이지가 정상적으로 열려도 트래픽이 거의 늘지 않을 수 있습니다. 자세한 수치 확인 방법은 Data 트래픽 통계 안내를 참고하세요.

06 / SETTINGS

Settings 주요 항목용도에 따라 하나씩 조정하기

처음에는 현재 설정을 그대로 유지하세요. 분명한 필요가 있을 때만 항목을 하나씩 변경하고 원래 값을 기록합니다. 모든 네트워크에 공통으로 맞는 고정 설정은 없습니다.

DNS: 먼저 이름 확인 경로 점검

무엇이며 어디에서 설정하나요: DNS는 도메인 이름을 IP 주소로 변환합니다. Settings의 DNS 설정과 Config 안의 DNS 내용을 함께 확인해야 하며, 한쪽만 보고 최종 이름 확인 경로를 판단해서는 안 됩니다. 도메인 규칙, IP 규칙, 서로 다른 DNS 응답 결과도 상호 영향을 줄 수 있습니다.

어떻게 설정하나요: 연결이 정상이라면 현재 이름 확인 방식을 기준값으로 유지하세요. 이름 확인에 실패하거나 예상과 다른 주소가 나오면 대상 도메인, 현재 네트워크, 오류 내용을 기록한 다음 DNS 주소에 접속할 수 있는지 확인합니다. DNS over HTTPS를 사용할 때는 유효한 전체 엔드포인트 주소를 입력해야 합니다. 엔드포인트 자체의 접속도 네트워크와 구성에 좌우되므로 입력만으로 반드시 개선되는 것은 아닙니다.

주의사항: 도메인 이름 확인에 성공해도 대상 서비스가 작동한다는 뜻은 아닙니다. DNS를 바꾼 뒤에도 기존 연결이나 캐시 때문에 변경 사항이 바로 나타나지 않을 수 있으므로 새 요청으로 확인하세요. 이름 확인 방식의 차이는 DNS 설정 안내를 참고하세요.

Test Method: 테스트 기준 통일하기

무엇이며 어디에 있나요: Test Method는 Settings의 테스트 관련 설정에서 Connectivity Test에 사용할 방식을 선택하는 항목입니다. 테스트 방식마다 확인하는 연결 단계가 다를 수 있으므로 목록의 결과를 실제 웹페이지 속도로 간주해서는 안 됩니다.

어떻게 설정하나요: 현재 화면에서 사용할 수 있는 테스트 방식을 선택하고, 결과를 비교할 때는 같은 방식, 같은 대상, 같은 네트워크 환경을 유지하세요. 테스트 대상은 접속 가능한 것으로 알려져 있고 응답이 비교적 안정적인 주소여야 합니다. 먼저 정상 작동이 확인된 항목을 테스트한 다음 다른 항목과 비교해 대상 자체의 문제를 오판하지 않도록 하세요.

주의사항: 특정 방식에서 응답이 없다고 해서 실제 요청도 연결할 수 없는 것은 아닙니다. 테스트에 응답했다고 모든 프로토콜과 대상이 정상이라는 뜻도 아닙니다. 실제 접속과 요청 기록으로 최종 확인하고, 한 번의 테스트 결과만 보고 서버를 자주 바꾸지 마세요.

Today Widget: 빠른 상태와 바로 가기 확인

무엇이며 어디에서 설정하나요: Today Widget은 시스템에서 지원하는 위젯 영역과 상태 표시에 사용됩니다. 관련 옵션은 Settings에서 확인할 수 있습니다. 위젯을 추가하는 위치와 표시 방식, 새로 고침 시점은 시스템 버전에 따라 다르므로 기기에서 실제로 제공하는 기능을 기준으로 하세요.

어떻게 설정하고 무엇을 주의해야 하나요: 먼저 앱에서 연결이 정상인지 확인한 다음 시스템의 위젯 편집 화면에서 해당 위젯을 추가하세요. 연결을 조작할 때 시스템에서 잠금 해제나 앱으로 돌아가기를 요구하는지 확인합니다. 위젯 갱신에는 지연이 있을 수 있습니다. 앱과 표시 내용이 다르면 Home과 시스템 연결 상태를 비교하고 오래된 수치를 현재 상태로 오인하지 마세요.

iCloud 동기화: 범위를 확인한 뒤 충돌 처리

무엇이며 어디에서 설정하나요: iCloud 동기화를 지원하는 Apple 기기에서는 Settings에서 관련 옵션을 확인할 수 있습니다. 동기화는 기기 백업과 같은 의미가 아니며 모든 실행 상태, 로그, 통계가 기기 간에 복사된다는 뜻도 아닙니다.

어떻게 설정하나요: 먼저 기기에서 예상한 iCloud 계정을 사용 중인지, 시스템에서 앱의 관련 서비스 접근을 허용했는지 확인한 뒤 클라이언트에 표시된 동기화 범위를 살펴봅니다. 여러 기기에서 처음 동기화하기 전에는 중요한 구성을 각각 복구할 수 있도록 보관하세요. 한 기기에서 작은 변경을 적용하고 다른 기기에서 반영된 것을 확인한 다음 편집을 이어가세요.

주의사항: 여러 기기에서 같은 내용을 동시에 수정하거나 동기화가 끝나기 전에 기능을 반복해서 켜고 끄지 마세요. 내보낸 파일에는 서버 인증 정보가 포함될 수 있으므로 민감한 파일로 취급해 보관해야 합니다. 다른 플랫폼에 같은 이름의 설정이 있다고 해서 iCloud 동작 방식도 같다고 가정해서는 안 됩니다. 다른 옵션은 Settings 설정 참고를 확인하세요.

07 / DIAGNOSTICS

Diagnostics와 Log요청 흐름을 따라 문제 찾기

무엇이며 어디에 있나요: Diagnostics는 진단 도구로 이동하는 메뉴이고, Log에서는 확인 가능한 실행 및 요청 정보를 볼 수 있습니다. Settings에서 현재 플랫폼이 제공하는 관련 도구를 찾아보세요. 진단의 목적은 오류가 발생한 단계를 확인하는 것이며, 오류가 보인다고 모든 옵션을 한꺼번에 바꾸는 것이 아닙니다.

어떻게 설정하나요: 네트워크 유형, Global Routing 모드, 선택한 서버, 대상 도메인을 기록하세요. 화면에서 로그 수준을 선택할 수 있다면 문제를 재현하는 동안에만 필요한 상세 수준으로 설정합니다. 그런 다음 새 요청을 한 번 보내고 ‘가로채기 여부, 매칭된 규칙, 적용된 정책, DNS 확인 및 연결 완료 여부’ 순서로 기록을 살펴보세요.

모든 대상에서 실패하면 현재 네트워크와 서버 연결 상태부터 확인하세요. 한 대상에서만 실패한다면 매칭 규칙, 대상 주소, DNS를 중점적으로 점검합니다. Proxy로 바꾼 뒤 복구된다면 Config에서 정책이 어디로 연결되는지 비교하세요. 연결을 끈 뒤에도 실패한다면 로컬 네트워크나 대상 서비스부터 확인해야 합니다. 변경의 영향을 판단하려면 매번 같은 대상으로 다시 테스트하세요.

주의사항: 요청 기록에 특정 항목이 없다고 해서 규칙이 빠졌다는 뜻은 아닙니다. 연결이 가로채지지 않았거나, 캐시로 인해 새 요청이 발생하지 않았거나, 현재 기록 범위에 해당 이벤트가 포함되지 않았을 수도 있습니다. 진단 자료를 공유하기 전에 구독 주소, 비밀번호, 인증 정보, 개인적인 접속 내용을 가리세요. 점검을 마친 뒤 평소 로그 설정으로 되돌리고 ‘원래 설정, 변경 항목, 재현 결과’를 기록해 다음에 비교할 수 있도록 하세요.