Shadowrocket 기능 및 설정

Global Routing은 요청에 적용할 라우팅 방식을 결정하며, 보통 Home에서 설정합니다. 현재 선택한 서버와는 별개의 설정입니다. 서버를 선택했다고 모든 요청이 해당 서버를 이용하는 것은 아니며, 프록시 경로를 이용하는지는 현재 모드와 규칙 적용 결과에 따라 달라집니다. 규칙에 따라 트래픽을 분기하려면 Config를 사용하고, 선택한 서버의 기본 접속 상태를 확인하려면 Proxy를 잠시 사용하세요. 현재 네트워크에서 직접 접속되는지 확인할 때는 Direct를 선택할 수 있습니다.

설정 변경 전에는 현재 모드를 기록해 두세요. 필요한 모드를 선택한 다음 Home으로 돌아가 서버 선택과 연결 스위치를 확인합니다. 테스트가 끝나면 원래 설정으로 복원하세요. 모드를 바꾸면 이후 요청에 적용되며, 이미 연결된 세션은 이전 상태를 유지할 수 있습니다. 새 요청을 보내 확인하고, 필요하면 연결을 다시 설정하세요. 계속 열려 있던 페이지 하나만 보고 판단하지 마세요.

규칙은 '무엇을 매칭할지' 정하고, 정책은 '매칭된 요청을 어떻게 처리할지' 정합니다. Config에서 사용할 설정 파일을 선택한 뒤 규칙을 확인하거나 편집하세요. 일반적으로 위에서 아래 순서로 매칭하며, 적용되는 첫 번째 규칙의 정책을 사용합니다. 앞선 규칙에 매칭되지 않은 요청은 FINAL이 최종 처리 방식을 지정합니다. 따라서 구체적인 규칙은 더 포괄적인 규칙보다 앞에 두는 것이 좋습니다. 파일에 특정 도메인이 있는지만 확인해서는 충분하지 않습니다.

주요 규칙 유형

DOMAIN은 도메인 전체를 매칭합니다. DOMAIN-SUFFIX는 지정한 도메인과 하위 도메인을 매칭하고, DOMAIN-KEYWORD는 도메인에 포함된 키워드로 매칭합니다. IP-CIDR과 IP-CIDR6은 각각 IPv4와 IPv6 주소 대역을 지정하며, GEOIP은 IP 주소의 위치 정보에 따라 매칭합니다. USER-AGENT는 요청에서 해당 정보를 확인할 수 있어야 하며, 모든 암호화 트래픽에 적용되는 범용 조건은 아닙니다.

PROXY, DIRECT 및 REJECT

PROXY는 프록시를 통한 처리를, DIRECT는 직접 연결을 지정하고, REJECT는 매칭된 요청을 거부합니다. 설정에서 이름이 지정된 정책이나 정책 그룹을 참조할 수도 있습니다. 이 경우 대상이 존재하는지, 이름이 일치하는지, 현재 선택이 의도한 대로인지 확인하세요. 화면의 Proxy는 모드 이름이고 규칙의 PROXY는 정책 키워드입니다. 편집할 때 각각의 표기를 그대로 유지하세요.

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

위 내용은 규칙 순서 예시이며, 일상적으로 사용하는 설정 파일 전체를 대체할 수 없습니다. 여기의 DOMAIN-KEYWORD,ads는 키워드 매칭을 보여 주기 위한 예시일 뿐이며 의도하지 않은 도메인까지 매칭할 수 있습니다. 변경하기 전에 매칭 범위를 확인하세요. 기존 설정을 복사해 보관하고 한 번에 한 종류의 규칙만 수정한 뒤 새 요청으로 검증하세요. 규칙과 DNS, 서버를 동시에 바꾸면 원인을 파악하기 어렵습니다.

서버 기록에는 연결 주소, 포트, 프로토콜, 인증 등의 매개변수가 저장됩니다. 구독은 여러 서버 기록을 한곳에서 관리하는 데 사용합니다. 아래 안내는 이미 본인 소유의 구독 또는 서버 정보를 가지고 있다는 전제하에 작성되었습니다. Home에서 서버를 확인하고 선택하거나 관리할 수 있으며, Add Server로 서버 기록을 추가할 수 있습니다. Scan QR Code는 지원되는 QR 코드 내용을 읽습니다. 가져오기 전에 내용이 구독 링크인지, 단일 서버 URI인지, 규칙이 포함된 설정 파일인지 먼저 확인하세요. 링크 모양만으로 서로 바꿔 사용할 수는 없습니다.

직접 추가할 때는 먼저 Type을 확인하고 주소, 포트, 프로토콜에 필요한 매개변수를 하나씩 입력하세요. 예를 들어 Shadowsocks, VMess, VLESS, Trojan은 인증과 전송 설정이 서로 다릅니다. HTTP, SOCKS5 등의 유형도 서버 정보와 일치해야 합니다. 이름만 보고 매개변수를 추측하거나 저장을 위해 TLS, 전송 또는 인증서 관련 항목을 임의로 삭제하지 마세요.

Subscribe와 설정 파일의 차이

Config 화면의 Subscribe는 해당 설정 구독 작업에 사용됩니다. 서버 구독을 관리할 때는 서버 구독용 가져오기 메뉴나 지원되는 가져오기 방식을 사용하세요. 가져온 결과를 확인하면 구분할 수 있습니다. 서버 기록은 Home에 표시되고, 규칙 설정은 Config에 표시되며 필요에 따라 활성화할 수 있습니다. 파싱에 실패하면 먼저 입력 유형과 링크가 완전한지 확인하세요. 같은 내용을 여러 메뉴에 반복해서 가져오지 마세요.

구독을 새로 고치면 주로 제공처의 서버 기록이 업데이트되며, 현재 설정된 규칙까지 변경되는 것은 아닙니다. 업데이트 후에는 선택한 서버가 여전히 있는지, 중복 기록이 생겼는지, 직접 입력한 메모로 서버를 구분할 수 있는지 확인하세요. 이전 구독을 삭제하기 전에는 소유 관계를 확인해 사용 중인 수동 입력 서버를 실수로 지우지 않도록 주의하세요. 인증 정보가 포함된 구독 링크, QR 코드, 서버 세부 정보는 민감한 정보로 취급하고 공개된 게시판에 붙여 넣지 마세요.

On Demand는 설정한 조건에 따라 연결 동작을 실행합니다. 규칙 정책을 선택하거나 서버의 작동 여부를 확인하는 기능은 아닙니다. Settings에서 On Demand 관련 항목을 찾아 현재 화면에서 사용할 수 있는 네트워크 조건을 확인하세요. 설정하기 전에 수동으로 연결해 서버와 규칙이 정상인지 확인한 다음 자동 실행 조건을 추가하면, 문제가 생겼을 때 서버 자체의 문제인지 연결 조건이 충족되지 않은 것인지 구분하기 쉽습니다.

연결할 Wi-Fi 또는 셀룰러 네트워크를 명확히 정한 뒤 조건, 적용 범위, 저장 결과를 하나씩 확인하세요. 설정 후에는 대상 네트워크와 다른 네트워크 환경에서 각각 다시 테스트해 시스템의 연결 상태가 예상과 일치하는지 살펴봅니다. iPhone과 iPad에서 사용할 수 있는 네트워크 기능은 다를 수 있으므로 기기에서 실제로 제공되는 항목을 기준으로 설정하세요. 다른 기기의 조건을 그대로 적용하지 마세요.

On Demand를 켠 상태에서는 수동으로 연결을 끊어도 계속 연결 해제 상태가 유지되지 않을 수 있습니다. 시스템이 조건을 다시 충족하면 연결이 다시 시작될 수 있습니다. 자동 연결을 잠시 중단하려면 Home의 스위치를 반복해서 누르기보다 먼저 On Demand 설정을 확인하세요. 배터리 소모는 이 옵션만으로 판단할 수 없으며, 실제 트래픽, 서버 재연결, 신호 상태, 백그라운드 활동도 함께 확인해야 합니다. 규칙을 수정하거나 연결 문제를 해결하는 동안 자동 실행을 잠시 끄고, 검증을 마친 뒤 다시 켤 수 있습니다.

Data에서 앱에 기록된 트래픽 정보를 확인할 수 있습니다. Data 화면에 표시되는 통계 범위와 집계 기준을 먼저 확인한 다음 송신 및 수신 기록을 살펴보세요. 통계값은 연결 후 데이터가 오갔는지 확인하는 데 도움이 되지만, 특정 요청이 예상한 정책을 따랐다는 사실을 단독으로 입증하지는 못합니다. 실제 접속 경로를 확인하려면 규칙 매칭 정보나 사용 가능한 연결 기록도 함께 살펴보세요.

검증할 때는 현재 수치를 기록하고 명확한 요청을 한 번 보낸 뒤 다시 확인해 변화량을 살펴볼 수 있습니다. 백그라운드 앱, 시스템 서비스, 기존 연결에서도 트래픽이 발생할 수 있으므로 짧은 시간 동안 증가한 전체 수치를 방금 연 웹페이지 하나의 사용량으로 간주하지 마세요. 카운터를 초기화하려면 필요한 기록을 먼저 보관하고 초기화 범위를 확인하세요. 통계 기간이 다른 수치는 직접 빼서 비교하기 어렵습니다.

Data는 서버 계정 잔액도 통신사 요금 청구 내역도 아닙니다. 서버 통계에는 다른 과금 방식, 집계 기간 또는 추가 오버헤드가 포함될 수 있으므로 수치가 다르면 먼저 집계 기준을 맞추세요. 연결 상태는 정상인데 예상한 트래픽이 보이지 않는다면 현재 서버, Global Routing, 대상 요청을 다시 보냈는지, 그리고 DIRECT 규칙에 매칭되어 프록시 경로를 사용하지 않았는지 차례로 확인하세요.

Settings에서 앱 동작과 도구 관련 옵션을 설정할 수 있습니다. 변경하기 전에 현재 설정 파일에도 관련 매개변수가 있는지 확인해 전역 설정만 바꾸고 실제로 사용하는 설정 내용을 놓치지 않도록 하세요. 아래 항목은 용도별 안내입니다. 세부 메뉴 위치와 선택 항목은 기기에 표시되는 화면을 기준으로 확인하세요. 값을 변경할 때마다 저장 후 테스트하고, 문제가 생기면 되돌릴 수 있도록 기존 값을 기록해 두세요.

DNS: 도메인 이름 확인

DNS는 도메인 이름을 연결 가능한 주소로 변환합니다. Settings의 DNS 메뉴에서 설정을 확인하고 Config에서 현재 설정 파일에 포함된 DNS 내용도 살펴보세요. 문제를 해결할 때는 '도메인 이름 확인 실패'와 '주소를 확인한 뒤 연결 실패'를 구분해야 합니다. 서버 주소가 도메인 이름인 경우에는 해당 도메인의 확인 결과가 연결에도 영향을 줄 수 있습니다. 사용자 지정 DNS 주소를 입력하기 전에 형식과 연결 가능 여부, 사용 목적을 확인하세요. 모든 문제를 DNS 변경으로 해결하려고 하지 마세요.

IPv6, 로컬 네트워크 도메인 또는 네트워크 환경이 달라지는 경우에는 확인된 주소가 현재 네트워크에 적합한지도 살펴보세요. DNS를 변경한 뒤에는 요청을 다시 보내고, 필요하면 연결을 재설정해 캐시의 영향을 확인하세요. 도메인 확인 문제를 해결하려고 인증서 검증을 끄지 마세요. 인증서 오류, 도메인 오류, 라우팅 오류는 각각 따로 해결해야 합니다.

Test Method: 연결 테스트 방식

Test Method에서 연결 테스트에 사용할 방식을 선택할 수 있으며, Settings에서 확인할 수 있습니다. 설정 후 Home으로 돌아가 Connectivity Test를 실행하고 선택한 방식에 맞춰 결과를 살펴보세요. 방식마다 확인하는 연결 단계가 다르므로 소요 시간을 서로 직접 비교하기는 어렵습니다. 테스트 대상, 현재 네트워크, 서버 상태도 결과에 영향을 줍니다.

테스트에 한 번 성공했다고 해서 모든 대상 사이트, DNS, 규칙이 올바르다는 뜻은 아닙니다. 실패했다면 먼저 선택한 방식과 테스트 대상이 적절한지 확인한 다음 서버 매개변수와 네트워크 상태를 살펴보세요. 결과를 비교하려면 같은 네트워크와 같은 방식으로 테스트하세요. 여러 설정을 연달아 바꾼 뒤 마지막 결과만 기록하지 마세요.

Today Widget: 빠른 확인 및 조작

Today Widget 설정에서 시스템 위젯에 표시하거나 조작할 수 있는 항목을 관리합니다. Settings에서 관련 옵션을 확인한 뒤 시스템에서 위젯을 추가할 수 있는 위치로 이동해 설정하세요. 위젯 추가 가능 여부와 표시 방식, 새로 고침 동작은 시스템 및 기기에서 지원하는 기능에 따라 달라집니다. 위젯은 빠른 조작에 적합하며, 전체 설정은 앱 안에서 진행하세요.

위젯 표시는 시스템의 새로 고침 주기에 영향을 받을 수 있으므로 위젯에 남아 있는 이전 상태만으로 현재 연결을 판단하지 마세요. 상태가 일치하지 않으면 Home을 열어 연결과 서버를 확인하세요. 잠금 화면에 표시할 내용은 개인 정보 보호 필요에 맞춰 선택하세요.

iCloud: 동기화 및 기기 변경 준비

Settings에서 iCloud 관련 옵션을 확인하고 시스템의 iCloud 권한 설정에서 앱이 해당 기능을 사용할 수 있도록 허용했는지 살펴보세요. 동기화하기 전에 현재 화면에 명시된 동기화 대상을 확인하세요. 서버, 설정, 모든 옵션과 사용 기록이 한꺼번에 동기화된다고 가정하지 마세요. 기기를 바꾸기 전에는 중요한 내용이 새 기기에 실제로 표시되는지 확인하고 필요한 백업을 보관하세요.

iCloud 동기화와 App Store 구입 항목 복원은 서로 다른 작업입니다. 전자는 앱 데이터를 다루고, 후자는 앱을 다시 받을 수 있는 권한을 복원합니다. 기기를 바꾼 뒤에도 서버 정보, 활성화된 설정, 시스템 연결 권한을 확인해야 합니다. 구입 내역과 복원 순서는 구입 항목 복원 안내에서 확인하세요.

Diagnostics는 문제 원인을 파악하는 데 도움이 되는 진단 메뉴이며, Settings에서 찾을 수 있습니다. 실행하기 전에 문제가 발생한 네트워크 환경, 현재 서버, Global Routing, 설정 이름을 기록한 다음 실제로 사용할 수 있는 검사를 실행하세요. 진단 결과는 원인을 좁히는 데 도움을 주지만 자동으로 문제를 해결해 주지는 않습니다. 한 줄의 메시지만 보고 모든 설정이 정상이라고 판단하지 말고 실제 접속 상황과 함께 살펴보세요.

다음 순서에 따라 최소한의 검증 절차를 진행할 수 있습니다. 단계마다 한 가지 요소만 바꾸고 변경 전후 결과를 기록하세요. Proxy로 잠시 전환하면 접속되지만 Config에서 실패한다면 규칙, 정책 대상, 설정 내용을 먼저 확인하세요. 두 모드 모두 실패하면 서버 정보, 이름 확인, 현재 네트워크를 추가로 점검합니다. Direct의 결과는 직접 접속 조건만 보여 주며 프록시 서버가 정상이라는 뜻은 아닙니다.

1. 기본 상태 확인.현재 네트워크에서 정상적으로 연결할 수 있는지, 시스템 권한 설정이 완료되었는지, Home에서 의도한 서버를 선택했는지 확인합니다.
2. 서버 테스트.동일한 Test Method로 Connectivity Test를 실행하고 주소, 포트, 인증, 프로토콜 매개변수를 확인합니다.
3. 라우팅 확인.Global Routing 모드를 확인하고 Config에서 활성화된 파일, 규칙 순서, FINAL 대상을 점검합니다.
4. DNS 확인.이름 확인 실패와 연결 실패를 구분하고 현재 DNS 설정을 기록한 다음 필요한 항목 하나만 조정합니다.
5. 요청 다시 보내기.Data와 사용 가능한 기록을 함께 확인해 기존 연결이나 캐시로 인한 오판을 방지합니다.

진단 정보를 외부에 전달하기 전에 구독 주소, 인증 정보, 서버 세부 정보, 접속 기록이 포함되어 있는지 확인하고 민감한 내용은 제거하세요. 문제를 설명할 때 '사전 조건, 수행 단계, 실제 결과, 예상 결과'를 함께 적으면 단순히 '연결되지 않음'이라고만 쓰는 것보다 재현하고 원인을 찾기 쉽습니다.