Shadowrocket 기능 및 설정

Global Routing: Config, Proxy, Direct

Global Routing은 현재 연결에 적용할 라우팅 방식을 결정합니다. Home에서 Global Routing을 열고 Config, Proxy, Direct 중 하나를 선택할 수 있습니다. 이는 전체 연결 처리 방식을 제어하며, 서버 프로토콜이나 연결 품질 등급을 뜻하지 않습니다. 서버를 바꾼 뒤에도 여기서 선택한 모드를 별도로 확인해야 합니다.

일상적으로 도메인이나 IP에 따라 트래픽을 나누려면 먼저 Config에서 선택된 설정 파일을 확인하고 Config 모드를 사용하세요. 문제가 규칙에서 비롯되는지 잠시 확인할 때는 Proxy 또는 Direct로 전환해 같은 대상을 다시 테스트할 수 있습니다. 테스트가 끝나면 원래 모드로 되돌려 임시 점검 설정이 일상 설정으로 남지 않게 하세요.

Direct는 연결 스위치를 끄는 것과 다르며, 시스템에서 VPN 구성이 제거되는 것도 아닙니다. Proxy를 선택해도 모든 앱의 요청이 반드시 성공하는 것은 아닙니다. 서버의 출구, 대상 서비스, 현재 네트워크도 결과에 영향을 줍니다. 문제를 확인할 때는 ‘연결 스위치 상태’, ‘Global Routing 모드’, ‘대상 접속 가능 여부’를 각각 기록하고 하나의 결론으로 뭉뚱그리지 마세요.

규칙 기반 라우팅: 조건, 순서와 정책

규칙은 ‘어떤 연결을 어떤 정책으로 처리할지’를 지정합니다. Config에서 사용 중인 설정을 열고 규칙과 정책 정의를 확인하세요. 규칙을 추가하거나 수정한 뒤 저장하고 해당 파일이 선택되어 있는지 확인합니다. 파일을 목록에 가져오기만 해서는 현재 연결에 적용되지 않습니다. 현재 설정의 규칙을 적용하려면 Global Routing도 Config로 지정해야 합니다.

매칭 조건과 정책은 서로 다른 요소입니다. DOMAIN, DOMAIN-SUFFIX 같은 키워드는 대상을 지정하고, DIRECT, REJECT 또는 Config에 정의된 프록시 정책 이름은 처리 방식을 나타냅니다. 정책 이름은 실제 설정과 일치해야 합니다. 이름만 보고 어느 서버를 가리키는지 추측하지 마세요. 규칙은 대체로 위에서 아래 순서로 적용되므로, 더 구체적인 예외 규칙을 포괄적인 조건보다 앞에 배치하세요.

다음은 규칙 문법의 예시이며 Config 전체를 그대로 대체하기 위한 파일이 아닙니다. PROXY는 프록시 정책을 뜻하므로 사용 전에 현재 Config에 정의된 정책을 확인하세요. example.com은 예시 도메인입니다.

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

DIRECT는 직접 연결, REJECT는 매칭된 연결을 거부한다는 뜻입니다. REJECT를 사용하기 전에 대상의 용도를 확인하세요. 로그인, 콘텐츠 로딩, 백그라운드 요청까지 실패할 수 있습니다. Proxy에서는 접속되지만 Config에서는 실패하는 대상이 있다면 포괄적인 규칙을 더 추가하기보다 먼저 적용된 규칙과 최종 정책을 확인하세요.

Config에는 DNS, 정책 그룹과 기타 설정이 포함될 수도 있습니다. 규칙을 조정할 때는 관련 부분만 수정하고 원본 파일을 보관하세요. 연결 중인 기존 세션은 이전 경로를 계속 사용할 수 있으므로 확인할 때는 요청을 새로 보내고, 필요한 경우 다시 연결하세요. 규칙의 기본 개념은 용어 설명에서 함께 확인할 수 있습니다.

다양한 프로토콜: 기존 서버 매개변수에 맞춰 입력하기

Shadowrocket은 Shadowsocks, VMess, VLESS, Trojan, Hysteria2, WireGuard, HTTP, SOCKS5 등 다양한 연결 프로토콜을 지원합니다. 프로토콜은 클라이언트와 서버가 데이터를 주고받는 방식을 정하며, 임의로 바꿔 쓸 수 있는 속도 설정이 아닙니다. 본인이 보유한 서버의 실제 설정을 기준으로 Home의 Add Server에서 해당 유형을 선택하거나, 필요한 매개변수가 포함된 기존 링크를 가져오세요.

먼저 주소와 포트를 확인한 다음 인증 정보, 전송 방식, TLS 관련 항목을 확인하세요. 프로토콜마다 필요한 항목이 다릅니다. 일부는 비밀번호를 사용하고 일부는 UUID를 사용하며, WireGuard에는 키, 주소, 피어 설정이 필요합니다. 한 프로토콜의 값을 다른 유형에 적용하지 말고, 연결을 임시로 성사시키려고 인증서 검증을 함부로 끄지 마세요.

VMess, VLESS 등의 연결은 관련 전송 매개변수도 필요할 수 있습니다. 주소가 같다고 해서 경로, Host, Server Name을 생략할 수 있는 것은 아닙니다. 가져온 뒤 시간 초과가 발생하면 원본 정보를 항목별로 대조해 추가 매개변수가 빠지지 않았는지 확인하세요. 서버 측에서도 동일한 조합을 지원해야 합니다. 클라이언트에서 프로토콜 이름만 바꿔서는 서버 프로토콜이 바뀌지 않습니다.

구독 및 서버 관리: 가져오기, 선택과 업데이트

Home에서 서버와 구독 그룹을 확인하고 현재 사용할 서버를 선택할 수 있습니다. 서버 정보를 직접 보유하고 있다면 Add Server에서 유형을 선택해 입력하세요. QR 코드가 있다면 Scan QR Code로 가져온 뒤 인식된 내용을 확인할 수 있습니다. 구독 링크가 있다면 Add Server에서 Subscribe를 선택하고 화면 안내에 따라 링크와 메모를 입력한 다음 저장하고 목록을 업데이트하세요.

구독은 여러 서버 항목을 가져오는 경로이며 Config 규칙 파일과는 다릅니다. 구독을 업데이트하면 일반적으로 서버 목록이 새로 고쳐질 뿐, 활성 Config, DNS, Global Routing까지 예상대로 함께 바뀌는 것은 아닙니다. 가져온 뒤 그룹이 표시되는지, 항목이 모두 입력되었는지 확인하고 사용할 서버를 직접 선택한 다음 연결을 테스트하세요.

관리하기 쉽도록 직접 추가한 항목과 구독 그룹에 알아보기 쉬운 메모를 붙이세요. 구독으로 생성된 항목을 직접 수정하면 다음 업데이트 때 변경 사항이 덮어써질 수 있으므로, 오래 유지할 내용을 조정하기 전에 해당 항목의 관리 주체를 확인하세요. 업데이트에 실패하면 현재 네트워크에서 구독 주소에 접속할 수 있는지, 링크가 유효한지 확인한 뒤 본인의 서비스 제공자에게 문의하세요. 비교에 필요한 이전 정보를 잃지 않도록 그룹을 반복해서 삭제하지 마세요.

구독 주소, QR 코드, 서버 인증 정보는 접근 권한을 제공할 수 있습니다. 전체 링크가 공개 스크린샷, 로그, 문의 글에 노출되지 않도록 하세요. 그룹을 삭제하기 전에 필요한 원본 정보를 보관하세요. 서버를 여러 개 바꾼 뒤에는 동일한 Test Method로 다시 테스트해 서로 다른 기준의 결과를 비교하지 않도록 합니다.

On Demand: 네트워크 조건에 따라 연결하기

On Demand를 사용하면 설정된 조건에 따라 시스템이 VPN 연결 요청을 처리하므로 매번 수동으로 전환할 필요가 줄어듭니다. 서버 상태를 확인하거나 유효하지 않은 인증 정보를 복구하는 기능은 아닙니다. 앱의 Settings에서 On Demand를 찾아 현재 화면에 표시되는 네트워크 조건을 설정하세요. 먼저 수동 연결이 정상적으로 작동하는지 확인한 다음 On Demand를 활성화하세요.

설정하기 전에 어떤 네트워크에서 연결할지, 어떤 조건에서는 연결하지 않을지 정한 뒤 조건 하나부터 테스트하세요. Wi-Fi 조건을 지정할 때는 네트워크 이름과 매칭 범위를 꼼꼼히 확인합니다. 저장한 뒤 테스트 네트워크를 차례로 전환하고 요청을 새로 보내 시스템의 VPN 상태와 앱 표시가 예상대로인지 살펴보세요. 스위치 색상만 보고 조건이 제대로 작동한다고 판단하지 마세요.

연결이 ‘끊겼다가 다시 연결되는’ 현상이 나타나면 먼저 On Demand가 활성화되어 있는지 확인하세요. 연결을 일시 중지하려면 관련 조건도 함께 확인해야 합니다. Wi-Fi와 셀룰러 네트워크를 전환하면 현재 네트워크, 시스템 권한, 기존 VPN 구성에 따라 동작이 달라질 수 있습니다. 한 번에 조건 하나만 조정하고 재현 가능한 테스트 기록을 남기세요.

Data: 트래픽과 활동 변화 확인

Data에는 클라이언트가 기록한 트래픽 통계가 표시됩니다. 연결 중 업로드, 다운로드와 관련 통계 항목의 변화를 살펴볼 때 유용합니다. 먼저 Data 화면에서 통계 범위, 시간 기준, 단위를 확인한 다음 같은 웹페이지를 여는 등 분명한 동작을 한 번 수행해 전후 수치를 비교하세요. 세부 항목은 현재 화면에 표시되는 내용을 기준으로 합니다.

트래픽이 증가했다는 것은 해당 통계 범위에서 데이터가 오갔다는 뜻입니다. 대상 페이지가 완전히 로드되었다거나 특정 규칙이 올바르게 매칭되었다는 뜻은 아닙니다. 백그라운드 동기화, 미디어 사전 로드, 앱의 재시도도 트래픽을 발생시킬 수 있습니다. 앱을 열지 않았는데도 통계가 계속 증가한다면 서버 이상이라고 단정하지 말고 먼저 백그라운드 활동을 확인하세요.

클라이언트 통계와 서비스 제공자의 청구 내역은 측정 범위, 초기화 시각, 단위가 다를 수 있으므로 수치가 정확히 일치하지 않을 수 있습니다. 문제 해결을 위한 기록이 필요하다면 통계 시간과 연결 상태를 먼저 적어 두고 화면의 초기화 기능을 사용하세요. Data는 기기의 모든 네트워크 트래픽을 기록하는 유일한 장부가 아니며, 서버 속도를 단독으로 판단하는 용도로도 적합하지 않습니다.

Settings: DNS, 테스트, 빠른 실행과 동기화

Settings에는 자주 사용하는 동작 설정이 모여 있습니다. 항목을 열어 기능을 확인한 뒤 변경 여부를 결정하세요. 일부 동작은 활성 Config의 영향을 받을 수 있으므로 문제를 점검할 때는 Settings와 Config의 관련 설정을 함께 기록해야 합니다. DNS, 테스트 방식, 서버를 한꺼번에 바꾸면 결과가 달라졌을 때 원인을 찾기 어렵습니다.

DNS: 이름 해석 경로와 설정 출처 확인

DNS는 도메인 이름을 IP 주소로 변환합니다. 이름 해석에 실패하면 서버가 연결된 것처럼 보여도 대상에 접속하지 못할 수 있습니다. Settings의 DNS 관련 항목과 활성 Config에서 해석 설정을 확인하고, 먼저 실제로 사용 중인 설정 출처를 파악한 뒤 해당 항목을 수정하세요. DNS 서버 주소도 현재 네트워크 경로를 통해 접속할 수 있어야 하므로 이름이 익숙하다는 이유만으로 바꾸지 마세요.

테스트할 때는 도메인 이름 해석 실패와 대상 연결 실패를 구분하고 IPv4와 IPv6 결과가 다른지도 확인하세요. 암호화된 전송을 사용하는 DNS 설정이라면 도메인, 인증서 검증, 연결 경로도 살펴봐야 합니다. 원래 설정을 보관하고 변경할 때마다 같은 요청을 다시 보내세요. 모든 DNS 설정을 지우는 것을 정해진 해결 방법처럼 사용하지 마세요.

Test Method와 Connectivity Test: 일관된 기준으로 비교하기

Test Method는 연결 테스트 방식을 결정합니다. Settings에서 현재 화면에 제공되는 테스트 방식을 선택한 다음 Home으로 돌아가 Connectivity Test를 실행하세요. 방식마다 측정하는 단계가 다르므로 결과를 직접 비교할 수 없습니다. 테스트에 실패해도 서버를 전혀 사용할 수 없다는 뜻은 아니므로 실제 접속과 로그를 함께 확인하세요.

서버를 비교할 때는 네트워크, 테스트 방식, 테스트 대상을 동일하게 유지하고 가능한 한 비슷한 시간대에 반복해서 테스트하세요. 지연 시간이 짧다고 지속적인 전송 속도까지 빠른 것은 아니며, 테스트에 성공해도 모든 대상 서비스가 정상 작동한다는 뜻은 아닙니다. 시간 초과가 발생하면 서버 시간 초과 문제 해결 절차에 따라 계속 점검하세요.

Today Widget: 빠른 상태 확인과 작업 설정

Today Widget은 관련 상태를 빠르게 확인하거나 조작할 때 사용합니다. Settings에서 Today Widget 관련 설정을 확인한 다음 시스템 위젯 화면에서 기기에서 제공하는 항목을 추가하세요. 위젯의 형태와 사용할 수 있는 기능은 시스템 및 앱 지원 여부에 따라 달라집니다. 실제 이름과 표시 방식은 기기 화면을 기준으로 확인하세요.

빠른 실행은 전체 설정 확인을 대신하지 않습니다. 위젯에서 조작한 뒤에도 앱에서 현재 서버, Global Routing, 연결 상태를 확인하세요. 규칙을 수정하거나 실패 원인을 확인하려면 같은 작업을 반복하기보다 Home, Config 또는 Diagnostics로 돌아가세요.

iCloud 동기화: 로컬 사본을 먼저 보관하세요

iCloud 동기화는 조건을 충족하는 기기 간에 앱이 지원하는 데이터를 동기화합니다. Settings의 iCloud 관련 항목에서 설정을 확인하고 시스템에서 앱의 iCloud 사용을 허용했는지도 살펴보세요. 두 기기 모두 적절한 iCloud 계정과 권한을 사용해야 합니다. App Store 구매 계정과 iCloud 동기화 계정은 용도가 다르므로 혼동하지 마세요.

활성화하기 전에 중요한 Config와 필요한 정보를 저장하고 현재 화면에 표시된 동기화 범위를 확인하세요. 모든 설정, 통계, 연결 상태가 동기화된다고 가정하지 마세요. 동기화는 과거 데이터를 보관하는 백업이 아니며, 삭제하거나 덮어쓴 변경 사항이 다른 기기에도 적용될 수 있습니다. 기기를 바꾼 뒤에는 데이터가 온전히 있는지 먼저 확인한 다음 연결하고, 두 기기에서 같은 설정을 동시에 대량으로 편집하지 마세요.

Diagnostics: 최소 재현 기록으로 문제 찾기

Diagnostics는 연결 문제와 관련된 진단 정보를 수집합니다. Settings에서 해당 메뉴를 열고 화면에 표시되는 항목을 확인하세요. 문제를 재현해야 한다면 네트워크 유형, 서버, Global Routing, 활성 Config, 오류가 발생한 시간을 기록한 뒤 실패한 작업을 한 번 더 수행합니다. 수집되는 로그 범위는 현재 화면을 기준으로 확인하세요.

정보를 확인할 때는 이름 해석 오류, 연결 시간 초과, 인증 실패, 대상 서버가 반환한 오류를 먼저 구분한 다음 관련 설정을 점검하세요. 진단 정보를 다른 사람에게 전달하기 전에는 구독 주소, 비밀번호, 키와 개인을 식별할 수 있는 정보를 삭제하고 문제 해결에 필요한 부분만 남기세요. 문제가 해결되면 임시로 활성화한 추가 기록 설정을 원래대로 되돌리세요.

설정 확인 순서: 연결부터 규칙 적용까지

설정 과정을 세 단계로 나누세요. 먼저 서버를 확인하고, 다음으로 트래픽 분할 규칙을 확인한 뒤, 마지막으로 자동화와 동기화를 추가합니다. 각 단계에서 같은 테스트 대상을 사용하고 결과를 확인한 다음 다음 단계로 넘어가세요. 이렇게 하면 한 번의 실패를 두고 프로토콜, DNS, 규칙, On Demand를 동시에 의심하는 일을 줄일 수 있습니다.

1. 기본 네트워크를 확인합니다. 먼저 기기의 네트워크가 정상적으로 작동하는지 확인하고 현재 Wi-Fi인지 셀룰러 네트워크인지 기록하세요. 로그인이 필요한 네트워크라면 먼저 해당 네트워크에서 요구하는 절차를 완료합니다.
2. 사용할 서버를 확인합니다. Home에서 확인할 서버 항목을 선택하고 프로토콜 매개변수를 점검하세요. 동일한 Test Method로 Connectivity Test를 실행한 다음 실제 대상에 접속할 수 있는지 확인합니다.
3. 활성 설정을 확인합니다. Config에서 사용할 파일을 선택하고 Global Routing을 Config로 설정한 뒤, 대상에 적용되는 규칙과 정책을 확인하세요. 정상 작동하는 설정 파일의 사본을 보관합니다.
4. 설정을 하나씩 추가합니다. 필요한 경우 DNS, On Demand, Today Widget 또는 iCloud 동기화를 조정하세요. 설정을 하나 바꿀 때마다 테스트를 반복하고 이전 결과와 달라진 점을 기록합니다.
5. 데이터로 결과를 확인합니다. Data에서 활동 변화를 살펴보고 필요한 경우 Diagnostics로 오류를 재현하세요. 새 설정으로 문제가 생기면 직전 변경을 먼저 되돌린 다음 추가로 수정할지 판단합니다.

처음 설정한다면 튜토리얼을 따라 단계별로 진행하세요. 연결은 되었지만 대상에 접속할 수 없다면 문제 해결 가이드에서 증상별로 확인할 수 있습니다. 구매, 재다운로드, 기기 호환성은 App Store 정품 확인 페이지에서 확인하세요. 연결 문제를 해결하기 위해 앱을 다시 구매할 필요는 없습니다.