공식 매뉴얼 · 기능 및 설정
Shadowrocket
프록시 모드와 주요 설정
먼저 Global Routing을 확인한 다음 서버와 구성을 점검하세요. 연결 스위치, 라우팅 모드, 규칙 정책은 각각 다른 기능을 담당하며 서로 대체할 수 없습니다.
- Home
- Config
- Data
- Settings
Global Routing의 세 가지 모드
구성 / 프록시 / 직접 연결은 인터페이스의 Config / Proxy / Direct에 해당합니다.
Global Routing은 클라이언트가 처리하는 연결의 출구 경로를 선택합니다. Home에서 Global Routing을 열고 목적에 따라 Config, Proxy 또는 Direct를 선택한 다음 Home으로 돌아가 연결 상태를 확인하세요. 이 설정은 연결 스위치나 서버 목록이 아닙니다. Proxy를 선택해도 터널이 활성화되는 것은 아니며, 서버를 바꿔도 모드가 함께 변경되지는 않습니다.
일상적으로 목적지별로 다르게 처리하려면 보통 Config를 선택합니다. 규칙 정책의 영향을 잠시 제외해 비교하려면 Proxy를 사용하고, 직접 연결 상태를 확인하려면 Direct를 사용할 수 있습니다. 이러한 비교는 문제를 진단하기 위한 방법이지, 모드의 우열을 평가하는 기준이 아닙니다. 테스트를 마치면 원래 사용하려던 모드로 되돌려 임시 설정이 계속 남지 않도록 하세요.
| 화면 옵션 | 처리 방식 | 사용 상황 | 확인할 점 |
|---|---|---|---|
| Config | 현재 활성화된 구성의 규칙에 따라 정책을 선택합니다. | 도메인, IP 또는 지역 등의 조건으로 트래픽을 분기할 때 사용합니다. | 활성화된 구성과 규칙 순서를 확인하세요. |
| Proxy | 클라이언트가 처리하는 연결을 프록시 경로로 보냅니다. | 선택한 서버를 임시로 테스트해 규칙 문제의 범위를 좁힐 때 사용합니다. | 서버 사용 가능 여부와 필수 매개변수가 모두 입력되었는지 확인하세요. |
| Direct | 직접 연결 경로를 사용합니다. | 프록시 서버를 거치지 않을 때의 연결 상태를 확인합니다. | 시스템의 VPN 연결을 끄는 것과는 다릅니다. |
Config 모드에서는 활성화된 구성을 먼저 확인하세요
Config는 구성 관리 화면의 항목이면서 Global Routing의 옵션이기도 하지만, 두 곳에서 맡는 역할은 다릅니다. Config 페이지에서 파일을 저장해도 해당 파일이 현재 구성으로 활성화되는 것은 아닙니다. 현재 활성 상태를 확인해야 합니다. 규칙의 PROXY는 프록시 정책을, DIRECT는 직접 연결을, REJECT는 연결 거부를 뜻합니다. 구성에 정책 그룹이 있다면 해당 그룹에서 현재 선택된 대상도 확인하세요.
모드를 바꾼 뒤 테스트 연결을 새로 시작하세요
기존 연결은 이전 처리 상태를 유지할 수 있으므로, 같은 화면이 그대로라는 이유만으로 모드 전환이 실패했다고 판단해서는 안 됩니다. 원래 모드를 기록한 뒤 모드를 바꾸고 요청을 새로 보낸 다음 연결 기록과 규칙 일치 여부를 확인하세요. 서버, DNS, 모드를 동시에 변경하면 결과를 해석하기 어렵습니다. 한 번에 한 가지 조건만 바꾸면 확인하기 쉽습니다.
규칙 유형과 정책
규칙은 “무엇을 일치시킬지”, 정책은 “어떻게 처리할지”를 정합니다.
규칙 분기는 대상마다 다른 연결 경로를 지정하는 기능입니다. Config 페이지에서 현재 구성을 선택하고, 규칙을 수정한 뒤 저장한 다음 Global Routing에서 Config 모드를 사용하도록 설정하세요. 규칙은 일반적으로 위에서 아래로 평가되며, 처음 일치한 규칙의 정책이 적용됩니다. 따라서 구체적인 조건은 범위가 넓은 조건보다 앞에 두고, FINAL은 일치하지 않은 연결을 처리하도록 마지막에 배치하는 것이 좋습니다. 규칙을 파일에 작성했다는 이유만으로 실제 실행된다고 볼 수는 없습니다.
DOMAIN은 전체 도메인을 일치시키고, DOMAIN-SUFFIX는 도메인과 하위 도메인 범위를 일치시킵니다. DOMAIN-KEYWORD는 도메인에 포함된 키워드를 기준으로 일치시킵니다. IP-CIDR과 IP-CIDR6은 각각 IPv4와 IPv6 주소 대역을 지정하며, GEOIP는 IP의 지리적 위치 데이터에 따라 일치시킵니다. USER-AGENT는 요청에서 확인할 수 있는 User-Agent 정보에 의존하므로 모든 연결에 적용되는 조건은 아닙니다. 앱 이름만 보고 추측하지 말고 실제로 확인할 수 있는 정보에 맞춰 규칙 유형을 선택하세요.
[Rule]
DOMAIN,example.com,PROXY
DOMAIN-SUFFIX,example.org,DIRECT
IP-CIDR,192.168.0.0/16,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXY
위 도메인은 문법 설명용일 뿐, 그대로 활성화하라는 완성된 구성은 아닙니다. 첫 번째 규칙은 example.com만 처리하고, 두 번째 규칙은 example.org와 그 하위 도메인을 포함합니다. IP-CIDR 예시는 해당 사설 주소 범위에 적용되며, FINAL은 앞선 규칙에 일치하지 않은 연결을 처리합니다. FINAL을 앞쪽에 두면 뒤에 있는 규칙은 일치 여부를 확인할 기회를 얻지 못합니다.
- PROXY / DIRECT
- 프록시 정책과 직접 연결을 각각 사용합니다. PROXY의 최종 출구는 현재 선택된 서버나 정책 그룹도 함께 확인해야 합니다.
- REJECT
- 일치한 연결을 거부합니다. 범위가 지나치게 넓으면 정상 요청에 영향을 줄 수 있으므로 대상을 먼저 확인하세요. 모든 페이지 콘텐츠를 처리한다고 단정할 수는 없습니다.
규칙이 예상대로 적용되지 않으면 먼저 현재 모드를 확인하고, 다음으로 활성화된 구성을 확인한 뒤, 앞쪽 규칙이 먼저 일치했는지 살펴보세요. 도메인 규칙과 IP 규칙은 서로 다른 정보를 기준으로 일치하며, DNS 조회 결과도 IP 규칙에 영향을 줄 수 있습니다. 각 유형의 적용 범위와 구성 구문, 추가 작성 방법은 규칙 매뉴얼에서 확인하세요. 같은 유형의 규칙을 반복해서 추가하기보다 원인을 먼저 찾아보세요.
구독 및 서버 관리
서버 정보와 구성 파일을 구분한 다음 적절한 가져오기 메뉴를 선택하세요.
서버 항목에는 연결에 필요한 주소, 포트, 프로토콜, 인증 정보가 저장됩니다. 구독은 이러한 항목을 한꺼번에 가져오거나 업데이트하는 데 사용하고, 구성 파일에는 규칙과 기타 연결 설정이 저장됩니다. 서로 관련은 있지만 동일한 항목은 아닙니다. 이미 구독을 보유하고 있다면 앱의 Subscribe 메뉴를 사용하세요. 서버 매개변수가 하나뿐이라면 Home의 Add Server에서 항목을 직접 추가할 수 있습니다. 가져온 뒤에는 목록에서 세부 정보를 확인하세요. 이름이 표시된다는 것만으로 연결 성공을 판단할 수는 없습니다.
Add Server: 보유한 매개변수 입력
Add Server를 열고 서버에 맞는 프로토콜을 선택한 뒤 주소, 포트, 인증 정보를 입력하세요. Shadowsocks, VMess, VLESS, Trojan, WireGuard, Hysteria2 등은 프로토콜마다 필요한 항목이 다르므로 한 프로토콜의 매개변수를 다른 프로토콜에 그대로 적용하면 안 됩니다. 기존 정보에 TLS, 서버 이름 또는 전송 방식이 포함되어 있다면 각 항목을 확인하세요. 표시 이름은 항목을 구분하기 위한 이름일 뿐, 실제 연결 주소를 대신하지 않습니다.
Scan QR Code나 클립보드를 사용해 기존 공유 정보를 가져온 경우에도 항목을 열어 주요 정보를 확인하세요. QR 코드 스캔은 정보를 입력하는 방법일 뿐, 원격 서버가 온라인인지 확인하지는 않습니다. QR 코드 이미지, 공유 링크, 인증 정보가 포함된 페이지는 안전하게 보관하세요. 문제를 설명할 때는 필요한 항목 이름과 증상만 전달하고 전체 내용을 공개하지 마세요.
Subscribe: 가져온 뒤 업데이트 관계 유지
보유한 구독 주소를 사용할 때는 주소가 완전한지, 접근 권한이 있는지, 응답 내용이 앱에서 지원하는 형식인지 확인하세요. 구독을 업데이트하면 보통 원격 목록을 다시 불러오므로, 장기간 유지할 로컬 변경 내용을 구독으로 생성된 항목에만 의존하지 않는 것이 좋습니다. 업데이트 전에 현재 선택 항목을 기록하고, 업데이트 후 목록이 바뀌었는지 확인한 다음 선택한 서버가 여전히 있는지 살펴보세요.
업데이트 후 목록이 비어 있다면 구독이 여전히 유효한지, 현재 네트워크에서 주소를 읽을 수 있는지, 일반 웹페이지 주소를 구독 주소로 잘못 입력하지 않았는지 먼저 확인하세요. 복구를 위해 모든 구성을 반복해서 삭제하지 마세요. Config 페이지에서 관리하는 규칙 파일의 활성 상태도 별도로 확인해야 합니다. 구독 업데이트에 성공했다고 해서 규칙 구성이 전환된 것은 아닙니다. 자세한 가져오기 방법은 시작 안내를 참고하세요.
On Demand 자동 연결
조건에 따라 연결을 시작하며 라우팅 규칙을 대신하지는 않습니다.
On Demand는 설정한 조건에 따라 시스템에 VPN 연결을 요청하므로 수동 조작을 줄이고 싶을 때 유용합니다. “언제 연결할지”를 정하는 기능이며, Global Routing은 “연결 후 어떤 경로로 보낼지”를 정합니다. Settings에서 On Demand 관련 설정을 확인하고 현재 조건을 먼저 읽은 다음 필요한 동작을 활성화하세요. 네트워크 조건이나 Wi-Fi 규칙에서 선택할 수 있는 항목은 현재 앱 화면을 기준으로 확인하세요.
처음 설정할 때는 수동 연결이 정상 작동하는지 먼저 확인한 뒤 On Demand를 활성화하세요. 테스트는 두 단계로 진행할 수 있습니다. 연결이 시작되어야 하는 네트워크 환경에서 연결 여부를 확인하고, 시작되지 않아야 하는 환경으로 전환해 동작을 확인하세요. 이렇게 하면 트리거 조건 문제와 서버 자체의 문제를 구분할 수 있습니다.
연결을 일시 중지하려면 On Demand가 다시 연결을 시작하지 않는지도 확인하세요. Home의 스위치만 끈 뒤 연결이 다시 나타나더라도 스위치가 작동하지 않는다고 단정할 수 없습니다. 시스템이 On Demand 조건을 다시 충족했을 수 있습니다. 같은 기기에 VPN 구성이 여러 개 있다면 시스템에서 현재 사용하는 구성을 확인해 다른 구성의 상태를 Shadowrocket의 결과로 오인하지 않도록 하세요.
Data 트래픽 통계
클라이언트에 기록된 트래픽을 확인하는 기능이며 요금 청구 기준을 대신하지 않습니다.
Data에서는 클라이언트에 기록된 트래픽을 확인할 수 있습니다. Data 화면을 열고 통계 범위와 집계 기준, 단위를 먼저 확인한 다음 업로드와 다운로드 수치를 살펴보세요. 업로드와 다운로드는 트래픽 방향을 뜻하며 서버 품질 점수가 아닙니다. 특정 시간대의 데이터가 적더라도 새 요청이 없었을 수 있으므로 연결 이상이라고 단정할 수 없습니다.
한 번의 작업으로 발생한 변화를 비교하려면 현재 수치를 기록하고, 명확한 작업 하나를 실행한 다음 Data로 돌아와 증가량을 확인하세요. 화면에 초기화 기능이 있다면 어떤 기록이 삭제되는지 먼저 확인하고, 필요한 통계는 따로 저장하세요. 문제를 점검하면서 통계를 계속 초기화하면 같은 시간대의 변화를 되돌아보기 어려워집니다.
클라이언트 통계, 시스템의 셀룰러 데이터 사용량, 사용 중인 서비스의 사용량은 집계 방식이 다를 수 있습니다. 포함되는 연결 범위와 프로토콜 오버헤드, 집계 기간도 일치하지 않을 수 있습니다. 따라서 Data는 사용 추세를 살펴보는 보조 수단으로 활용하세요. 셀룰러 요금이나 원격 사용량을 확인할 때는 각각 해당하는 출처를 확인해야 합니다. 트래픽이 증가했다는 사실만으로 규칙이 예상대로 일치했다고 볼 수는 없으며, 연결 기록을 통해 출구 경로도 확인해야 합니다.
Settings 주요 항목
구체적인 목적에 따라 조정하고, 변경 이유와 이전 값을 기록하세요.
DNS: 조회 경로 확인
DNS는 도메인 이름을 연결에 필요한 주소로 변환합니다. 관련 동작을 확인할 때는 Settings의 DNS 설정과 현재 구성 파일을 함께 살펴봐야 하며, 입력란 하나만 확인해서는 충분하지 않습니다. 변경 전에 현재 DNS 설정을 기록하고, 사용 중인 구성이 이를 지정하는지 확인한 다음 현재 네트워크 환경에 맞게 조정하세요. 특정 IP 주소에는 연결되지만 도메인으로 접속하지 못한다면 DNS도 점검할 항목입니다. 그렇다고 모든 문제가 DNS에서 비롯되었다고 단정할 수는 없습니다.
출처를 알 수 없는 DNS 주소를 여러 개 임의로 추가하지 마세요. 변경 후 테스트 연결을 새로 시작하고 같은 대상을 사용해 결과를 확인하세요. IPv4와 IPv6 관련 동작도 예상대로인지 살펴보세요. DNS 변경은 도메인 조회 결과와 이후 IP 규칙의 일치 여부에 영향을 줄 수 있으므로 규칙을 점검할 때 DNS 설정을 기록해 테스트 조건이 계속 바뀌지 않도록 하세요.
Test Method: 같은 방식으로 테스트
Test Method는 연결 테스트 방식을 정합니다. Settings에서 해당 항목을 확인한 다음 Home에서 Connectivity Test를 실행하세요. 여러 서버를 비교할 때는 같은 방식을 유지해야 결과를 동일한 유형의 과정끼리 비교할 수 있습니다. 테스트에 걸린 시간은 해당 시점과 방식에서의 응답 상태만 보여주며, 웹페이지 로딩 속도나 지속적인 전송 성능과 같다고 볼 수 없습니다.
특정 항목의 테스트가 실패하면 현재 환경에서 테스트 대상에 접근할 수 있는지 먼저 확인하고, 서버 주소와 포트, 인증 정보를 점검하세요. 특정 앱에서만 접속 문제가 발생한다면 실제 대상의 연결 기록을 확인하세요. 목록에 표시된 테스트 결과 하나만 보고 구성을 계속 바꾸지 마세요.
Today Widget: 빠른 조작 대상 확인
Today Widget은 시스템에서 제공하는 빠른 정보 표시 및 조작 메뉴입니다. Settings에서 관련 설정을 확인하고 시스템이 제공하는 위젯 메뉴에서 추가하거나 표시 상태를 점검할 수 있습니다. 표시 방식은 시스템과 앱에서 현재 지원하는 기능에 따라 달라지므로 기기마다 위치가 같다고 가정하지 마세요.
빠른 조작을 사용한 뒤 Home으로 돌아가 실제 연결 상태와 선택된 서버, Global Routing을 확인하세요. 위젯은 조작을 위한 진입점이지 별도의 구성이 아닙니다. 상태 표시가 아직 갱신되지 않았다면 앱 내부 상태와 시스템 VPN 상태를 함께 확인하고, 빠르게 연속해서 전환해 잘못 판단하지 않도록 하세요.
iCloud 동기화: 범위를 확인한 뒤 동기화
iCloud 관련 옵션은 앱에서 지원하는 범위 내의 콘텐츠를 동기화합니다. 먼저 기기에서 본인의 Apple 계정에 로그인되어 있는지, 시스템에서 해당 iCloud 사용을 허용했는지 확인한 다음 Settings에서 실제로 제공되는 동기화 범위를 살펴보세요. 모든 연결 기록과 통계, 민감한 정보가 동기화된다고 가정하지 마세요. 앱 구매 기록과 구성 동기화도 서로 다른 항목입니다.
다른 기기에서 수정하기 전에 양쪽 기기의 콘텐츠와 동기화 상태를 확인하고, 필요한 경우 복구할 수 있도록 구성 사본을 보관하세요. 내용이 일치하지 않으면 네트워크와 계정, 동기화 권한을 먼저 확인한 뒤 어느 쪽을 유지할지 판단하세요. App Store에서 구매한 앱을 복원해도 구성 파일과 서버 정보까지 반드시 복원되는 것은 아닙니다.
Diagnostics 및 연결 문제 해결
증상으로 문제 구간을 찾은 뒤 필요한 진단 정보를 선택하세요.
Diagnostics는 연결 문제를 점검하는 데 도움을 줍니다. Settings에서 Diagnostics 관련 메뉴를 찾아 현재 화면에서 제공하는 도구로 확인하세요. 진단 결과는 발생 시각과 네트워크 환경, Global Routing 모드, 대상 정보를 함께 고려해야 합니다. 오류 한 건만으로 전체 원인을 파악할 수는 없으며, 이를 근거로 고급 설정을 임의로 바꾸어서도 안 됩니다.
- 증상을 기록하세요. 연결을 시작할 수 없는 경우, 연결 후 모든 대상에 접근할 수 없는 경우, 일부 도메인만 실패하는 경우, 구독 업데이트가 실패하는 경우를 구분하세요. 각각 문제가 발생한 단계가 다릅니다.
- 기본 정보를 확인하세요. 현재 서버와 인증 정보, 활성화된 구성 및 라우팅 모드를 확인하고 기기 네트워크가 정상인지 살펴본 다음 Connectivity Test를 실행하세요.
- 변수를 줄이세요. 서버는 그대로 둔 채 Config와 Proxy에서 차이가 있는지 비교하세요. 차이가 뚜렷하다면 규칙과 정책 그룹, DNS를 확인하고 테스트가 끝나면 원래 모드로 되돌리세요.
- 다시 테스트하고 기록하세요. 설정 하나만 변경한 뒤 연결을 새로 시작하고 변화를 기록하세요. 개선되지 않으면 이전 값으로 되돌려 여러 임시 변경 사항이 누적되지 않도록 하세요.
진단 정보에는 방문한 도메인과 서버 주소, 인증 관련 정보가 포함될 수 있습니다. 저장하거나 공유하기 전에 민감한 부분을 확인하고 가리세요. 문제 설명에 필요한 오류 유형과 시각, 조작 단계만 남기면 됩니다. 전체 구독 주소는 공개 문제 해결 자료로 적합하지 않습니다. 주소 형식을 설명할 때는 실제 주소 대신 example.com과 같은 예시 도메인을 사용하세요.
설정 점검 및 자주 묻는 질문
설정 화면을 나가기 전에 현재 상태가 예상한 대로인지 확인하세요.
전체 점검에서는 네 가지를 확인해야 합니다. Home의 연결 상태, 현재 Global Routing 옵션, 실제로 선택된 서버, Config에서 활성화된 구성입니다. On Demand를 사용한다면 트리거 조건도 확인하세요. 이 정보를 기록해 두면 이후 문제가 생겼을 때 안정적으로 비교할 수 있고, 매번 모든 옵션을 처음부터 바꿀 필요가 없습니다.
Config를 선택했는데 왜 프록시로 연결되나요?
Config는 규칙에 따라 처리한다는 뜻이지, 모든 연결을 직접 접속시킨다는 뜻은 아닙니다. 일치한 규칙이 PROXY를 사용하는지, 또는 최종적으로 FINAL,PROXY에 연결되는지 확인하세요. 파일이 목록에 저장되어 있기만 한 것이 아니라 의도한 구성이 활성화되어 있는지도 확인해야 합니다.
Direct로 바꾸면 연결 스위치도 꺼야 하나요?
Direct 선택과 연결 종료는 서로 다른 동작입니다. Direct는 처리 경로를 변경하고, 연결 스위치는 현재 연결을 중단합니다. 클라이언트 연결을 완전히 일시 중지하려면 On Demand가 다시 연결을 시작하는지도 확인하고 시스템의 실제 VPN 상태도 점검하세요.
Connectivity Test에 성공하면 모든 앱에 정상적으로 접속할 수 있나요?
그렇게 단정할 수 없습니다. 테스트는 선택한 Test Method에 해당하는 과정만 확인합니다. 실제 접속에는 대상 사이트와 DNS, 규칙, 원격 서버의 응답도 영향을 줍니다. 해당 요청을 새로 보내고 연결이 어떤 경로로 처리되는지 확인하세요.
서버 구독을 업데이트하면 규칙도 함께 바뀌나요?
가져온 콘텐츠에 따라 각각 확인해야 합니다. 서버 목록과 규칙 구성은 역할이 다르므로 서버 구독 업데이트가 규칙 파일의 업데이트나 활성화를 뜻하지는 않습니다. 먼저 업데이트된 목록을 확인한 다음 Config에서 현재 파일과 규칙을 살펴보세요.