Shadowrocket 기능 및 자주 쓰는 설정

Global Routing: 트래픽 처리 모드 선택

Global Routing은 연결이 활성화된 뒤 트래픽을 설정된 규칙에 따라 처리할지, 주로 Proxy 또는 Direct 경로를 사용할지 결정합니다. 서버 선택이나 Home의 연결 스위치와는 다릅니다. 먼저 Home에서 Global Routing을 찾아 현재 선택 항목을 확인한 다음 목적에 맞게 Config, Proxy 또는 Direct를 선택하세요.

일상적으로 트래픽을 라우팅하려면 일반적으로 Config를 사용합니다. 설정 전에 Config에서 실제로 활성화된 파일을 확인하세요. 파일을 가져오기만 했는지 확인하는 것으로는 충분하지 않습니다. 파일이 존재하는 상태와 실제로 사용 중인 상태는 다릅니다. 활성화되지 않은 파일을 편집해도 현재 연결 동작은 바뀌지 않습니다.

특정 대상에 접근할 수 없다면 기존 설정을 기록해 둔 뒤 Proxy와 Config를 잠시 비교해 볼 수 있습니다. Proxy에서는 접근되지만 Config에서는 되지 않는다면 해당 요청에 적용된 규칙과 정책 경로를 확인하세요. 이는 문제를 좁히기 위한 단서일 뿐, 원인을 확정하는 방법은 아닙니다. 테스트가 끝나면 필요한 모드로 되돌려 임시 점검 설정을 일상 설정으로 남기지 마세요.

규칙과 라우팅: 조건, 순서 및 정책

규칙 라우팅은 요청의 도메인이나 대상 주소 등의 정보를 규칙과 차례로 대조한 뒤 해당 정책으로 처리하는 방식입니다. Config에서 현재 사용 중인 구성을 열어 규칙 목록을 확인하세요. Global Routing에서 Config를 선택했을 때 이 구성이 라우팅 점검의 기준이 됩니다. 수정하기 전에 원본 파일을 보관해 비교 기준을 잃지 않도록 하세요.

규칙은 일반적으로 유형, 일치 조건, 정책으로 구성됩니다. 위에서 아래로 확인하며 첫 번째로 일치하는 규칙이 적용되면 이후 규칙은 확인하지 않습니다. 따라서 특정 도메인에만 적용할 예외는 이를 포함하는 범위 규칙보다 앞에 두고, FINAL은 대개 앞선 규칙에 일치하지 않은 요청을 처리하도록 마지막에 둡니다. 규칙이 많다고 해서 우선순위가 적절한 것은 아닙니다.

PROXY는 프록시 경로로 전달하고, DIRECT는 대상에 직접 연결하며, REJECT는 요청을 거부합니다. 규칙에서 구성에 정의된 정책 그룹 이름을 참조할 수도 있습니다. 이 경우 규칙 끝에 표시된 이름만 보지 말고 그룹에서 현재 선택된 항목도 확인하세요. 아래 예시는 규칙의 배치 관계를 보여 줄 뿐이며, example.com은 설명용 도메인입니다. 전체를 기존 구성으로 그대로 바꾸지 마세요.

DOMAIN,ads.example.com,REJECT
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,10.0.0.0/8,DIRECT
FINAL,PROXY

이 예시는 정확한 예외 규칙을 접미사 규칙보다 앞에 둡니다. 그렇지 않으면 ads.example.com이 먼저 더 넓은 규칙에 일치합니다. 문제를 확인할 때는 실제로 적용된 규칙을 먼저 찾은 뒤 순서를 조정하세요. 마지막에 원하는 규칙을 추가하는 것만으로 해결하려 하지 마세요. 자세한 내용은 규칙 일치 순서 및 FINAL 안내를 참고하세요.

Subscribe 및 서버 관리

서버 기록에는 구체적인 연결 매개변수가 저장되고, Subscribe는 본인이 보유한 구독 정보를 바탕으로 서버 목록을 관리합니다. Config에는 주로 규칙과 관련 설정이 담깁니다. 세 항목은 서로 연관되어 있지만 같은 종류의 데이터는 아닙니다. 기존 링크를 가져올 때는 실제 유형에 맞게 선택하세요. 모두 URL처럼 보여도 구성 주소와 구독 주소를 서로 바꿔 사용할 수는 없습니다.

Home에서 추가 메뉴를 열어 Add Server로 이동한 뒤, 보유한 정보에 맞는 Type을 선택하세요. 직접 추가할 때는 Address, Port 및 프로토콜에 필요한 인증 항목을 하나씩 확인합니다. 예를 들어 Trojan과 Shadowsocks는 필요한 항목이 완전히 같지 않습니다. 입력값은 서버 측 설정과 일치해야 하며, 서로 맞지 않는 매개변수를 Type만 바꿔 해결할 수는 없습니다. 항목의 의미는 프로토콜 기술 참고에서 확인할 수 있습니다.

기존 구독을 가져오려면 Add Server의 Type에서 Subscribe를 선택하고 URL 등 해당 항목에 본인의 구독 정보를 입력하세요. 저장한 다음 Home으로 돌아가 구독 아래에 서버 목록이 표시되는지 확인하고 필요한 항목을 선택합니다. Scan QR Code를 사용하는 경우 먼저 인식된 내용의 유형과 출처를 확인하세요. 저장한 뒤에도 매개변수를 점검해야 하며, QR 코드 인식 성공이 연결 성공을 의미하지는 않습니다.

구독을 업데이트하면 목록을 다시 불러오므로 서비스 제공자가 주소나 매개변수를 변경했을 때 유용합니다. 업데이트한 뒤 현재 선택한 서버가 여전히 목록에 있는지, 이름이 바뀌었는지, 기존 정책이 유효한 항목을 참조하는지 확인하세요. 구독으로 생성된 항목을 임시로 편집하면 다음 업데이트에서 변경 내용이 덮어써질 수 있습니다. 중요한 변경은 먼저 구성이 저장되는 방식을 확인하세요.

Connectivity Test는 현재 테스트 조건에서 각 항목의 응답을 비교하는 데 도움이 됩니다. 결과는 Test Method, 테스트 대상, 네트워크 및 서버 상태의 영향을 함께 받습니다. 목록에 응답이 있다고 해서 모든 대상에 접근할 수 있는 것은 아닙니다. 응답이 없더라도 서버 매개변수를 변경하기 전에 테스트 방식이 현재 서비스에 적합한지 확인하세요.

On Demand: 조건에 따라 연결 시작

On Demand는 설정한 조건이 충족될 때 시스템이 VPN 연결을 시작하도록 합니다. 즉, ‘언제 연결할지’를 정하는 기능이지 특정 도메인에 어떤 정책을 적용할지 결정하는 기능은 아닙니다. 연결이 시작된 뒤 트래픽 처리 방식은 Global Routing과 현재 Config에 따라 달라집니다. On Demand를 별도의 라우팅 규칙으로 간주하지 마세요.

먼저 Home에서 수동으로 한 번 연결해 기존 서버와 구성이 정상인지 확인한 다음 Settings에서 On Demand를 찾으세요. 실제 화면에서 제공하는 네트워크 조건을 하나씩 설정합니다. Wi-Fi 이름 등의 조건을 사용하는 경우 철자를 확인하고 기기가 실제로 해당 네트워크에 연결되어 있는지 확인하세요. 수동 연결이 성공하기 전에 여러 자동 트리거 조건을 추가하면 문제가 발생한 단계를 파악하기 어려워집니다.

설정 후 실제로 사용하는 네트워크 환경을 바꾸어 시스템이 예상대로 연결을 시작하는지 확인하고 Home에서 연결 상태를 점검하세요. 트리거되어야 하는 상황뿐 아니라 트리거되지 않아야 하는 상황도 테스트해야 합니다. 현재 Wi-Fi에서 한 번 확인하는 것만으로는 다른 네트워크 조건까지 올바르게 설정되었다고 볼 수 없습니다.

연결을 중단하려 했는데 다시 시작된다면 On Demand가 활성화되어 있는지, 트리거 조건이 충족되었는지 먼저 확인하세요. 자동 동작을 잠시 중단하려면 관련 트리거를 끈 다음 연결 스위치를 확인합니다. 네트워크 전환과 백그라운드 활동에 대한 시스템의 처리 방식도 관찰 결과에 영향을 줄 수 있으므로 모든 환경에서 같은 시점에 작동한다고 단정할 수 없습니다.

Data: 트래픽 및 요청 정보 확인

Data에서는 앱에 기록된 트래픽 통계와 확인 가능한 요청 정보를 볼 수 있습니다. 연결 중 데이터가 오갔는지, 특정 테스트 전후로 기록이 어떻게 달라졌는지 확인하는 데 적합합니다. 서비스 제공자의 청구 내역이나 완전한 속도 테스트는 아닙니다. 통계 기준, 보관 범위 및 화면 표시는 기기에 실제로 표시되는 옵션을 따르세요.

Data를 열고 통계 범위, 시간 및 사용 가능한 분류를 먼저 확인한 뒤 하나의 대상을 지정해 접속 테스트를 진행하세요. 누적 숫자 하나만 보는 것보다 테스트 전후의 변화를 비교하는 편이 유용합니다. 화면에 연결 세부 정보나 요청 기록이 표시된다면 도메인, 대상 주소 및 정책 정보를 함께 확인해 처리 경로를 살펴보세요. 항목이 표시되지 않는 경우 특정 규칙을 거쳤다고 임의로 판단하지 마세요.

다시 확인하려면 필요한 정보를 먼저 기록한 뒤 화면에서 제공하는 초기화 또는 정리 기능을 사용하세요. 통계를 정리하는 것은 서버 매개변수를 변경하는 것과 다르며 잘못된 규칙을 자동으로 수정하지도 않습니다. 테스트 중에는 다른 앱의 백그라운드 활동을 최소화해 업데이트나 동기화 트래픽이 통계에 섞여 판단에 영향을 주지 않도록 하세요.

Data의 수치가 증가했다는 것은 기록 범위 내에서 데이터 전송이 있었다는 뜻일 뿐, 대상 서비스가 정상적으로 작동했다는 의미는 아닙니다. 앱이 재시도 중이거나 다른 리소스를 내려받고 있을 수 있습니다. 반대로 테스트 중 수치 변화가 뚜렷하지 않은 것은 연결 상태, 현재 모드 또는 통계 범위 때문일 수 있습니다. 통계만으로 결론 내리지 말고 Home, Global Routing 및 실제 접속 결과를 함께 확인하세요.

Settings: 자주 쓰는 옵션의 설정 범위

Settings에는 주로 앱 수준 옵션, 테스트 환경설정, 동기화 및 보조 도구가 있습니다. Config에도 이름 해석이나 연결 관련 설정이 저장될 수 있습니다. 변경 전에 해당 항목이 앱 설정인지 구성 설정인지 구분하고 기존 값을 기록한 뒤 현재 활성화된 파일을 보관하세요. 화면에 표시되지 않는 항목을 다른 안내에서 본 위치에 억지로 찾으려 하지 말고 기기에서 실제 제공하는 메뉴를 기준으로 확인하세요.

DNS: 먼저 해석 설정의 출처 확인

DNS는 도메인을 주소로 변환하며 연결 전에 거치는 중요한 단계입니다. 먼저 Settings에서 관련 메뉴를 확인한 다음 현재 Config에 DNS가 지정되어 있는지 살펴보세요. 한 곳을 변경하면 모든 구성이 덮어써진다고 가정하지 마세요. 직접 사용할 수 있다고 확인한 DNS 서비스와 앱에서 지원하는 형식으로 설정한 뒤 같은 도메인을 다시 테스트하세요. DNS 설정을 방금 변경했다면 캐시의 영향을 고려하고, 필요한 경우 화면에서 제공하는 방법으로 캐시를 정리한 후 다시 확인하세요.

도메인 해석에 성공해도 이후 연결까지 성공한 것은 아닙니다. 도메인 연결은 실패하지만 주소로 연결할 때 결과가 다르다면 DNS를 점검해 볼 수 있습니다. 다만 대상 주소로 직접 바꾸면 TLS 확인과 요청 동작이 달라질 수 있으므로 이러한 비교를 장기적인 해결책으로 사용하지 마세요. 한 번의 테스트에서 DNS, Global Routing 및 프로토콜 항목을 동시에 조정하는 것도 피하는 것이 좋습니다.

Test Method: 동일한 테스트 방식으로 비교

Test Method는 Connectivity Test에서 사용할 테스트 방식을 결정합니다. Settings에서 해당 항목을 찾아 화면에 제공되는 옵션 중 하나를 선택하고 관련 테스트 대상도 확인하세요. 방식마다 확인하는 연결 단계가 다르므로 결과를 같은 기준으로 바로 비교할 수는 없습니다. 방식을 변경한 뒤에는 비교하려는 항목을 다시 테스트하세요. 새 결과와 기존 목록의 결과를 그대로 정렬해 판단하지 마세요.

테스트 대상에서 응답이 왔다는 것은 선택한 방식이 확인하는 연결 단계에 응답이 있었다는 뜻일 뿐, 모든 앱과 웹사이트가 정상이라는 보장은 아닙니다. 문제를 확인할 때는 ‘방식, 대상, 네트워크 환경’ 세 가지 조건을 기록하고 실제 서비스에 접속해 추가로 확인하세요. 특정 응답 수치를 서비스 품질이나 안정성의 보장으로 해석하지 마세요.

Today Widget: 빠른 확인 및 조작

Today Widget은 시스템 위젯과 관련된 빠른 메뉴를 제공합니다. 먼저 Settings에서 앱이 제공하는 관련 옵션을 확인한 다음 시스템의 위젯 편집 화면에서 추가할 수 있는지, 현재 기기에서 어떤 조작을 지원하는지 확인하세요. 시스템 버전과 위젯 지원 여부에 따라 표시가 달라질 수 있으므로 기기 화면을 기준으로 판단하세요.

위젯은 앱을 여는 단계를 줄여 주지만 구성을 점검하는 기능을 대신하지는 않습니다. 위젯에서 연결을 조작한 뒤 상태가 예상과 다르면 Home으로 돌아가 확인하고 On Demand가 연결 트리거에 관여하는지도 점검하세요. 위젯에 마지막으로 표시된 상태만 보고 현재 연결이 설정되었다고 판단하지 마세요.

iCloud: 동기화 전에 구성 사본 보관

iCloud 관련 옵션은 조건을 충족하는 기기 간에 앱에서 지원하는 항목을 동기화하는 기능입니다. Settings에서 iCloud 설정을 확인하고 시스템에서 Shadowrocket의 iCloud 사용이 허용되어 있는지도 살펴보세요. 처음 활성화하기 전에 중요한 Config를 백업하고 현재 선택된 서버와 모드를 기록하세요. 동기화 범위는 화면의 안내를 따르며, 모든 임시 상태와 통계, 인증 정보가 완전히 동기화된다고 가정해서는 안 됩니다.

기기를 바꾼 뒤에는 콘텐츠가 동기화될 때까지 기다린 다음 파일, 서버 및 정책 참조를 하나씩 확인하세요. 동기화는 연결 확인이 아니며 이전 기록이 모두 복원된다는 뜻도 아닙니다. 두 기기에서 같은 구성을 동시에 편집했다면 저장 결과를 확인해 이전 내용이 변경된 규칙을 덮어쓰지 않도록 하세요. 구체적인 이전 순서는 구성 백업 및 이전 안내를 참고하세요.

Diagnostics: 명확한 문제를 재현해 진단 정보 수집

Diagnostics에서는 앱이 제공하는 진단 정보를 확인할 수 있습니다. Settings에서 해당 메뉴를 찾아 실제 화면에 표시되는 진단 방법을 선택하세요. 문제가 발생했을 때의 네트워크, Global Routing, 선택한 서버 및 작업 단계를 먼저 기록한 뒤 한 번 재현하는 편이 오랜 시간 여러 작업을 섞어 수집하는 것보다 원인을 파악하기 쉽습니다.

진단 결과는 분석을 위한 단서이지 자동 복구 기능이 아닙니다. 공유하기 전에 구독 URL, 서버 주소, 계정 정보 또는 접속 대상이 포함되어 있는지 확인하고 민감한 정보는 가리세요. 기록 전체를 그대로 공개하지 마세요. 점검이 끝나면 임시로 변경한 기록 옵션을 복원하고 더 이상 필요하지 않은 진단 자료는 필요한 범위에서 정리하세요.

자주 쓰는 설정 점검 순서

설정이 많을 때는 순서를 정해 확인하면 반복적인 변경을 줄일 수 있습니다. 복구할 수 있는 기준 상태를 먼저 보관하고 한 번에 하나의 변수만 변경하세요. 저장할 때마다 같은 대상을 사용해 확인하고 결과를 기록합니다. 이렇게 하면 매개변수 오류, 규칙 경로 및 자동 트리거 조건의 차이를 구분하기 쉽습니다.

1. 입력 정보 확인. Home에서 현재 서버를 확인하고 기존 구독이 업데이트되었는지, 직접 입력한 Type, Address, Port 및 인증 매개변수가 일치하는지 점검하세요.
2. 처리 모드 확인. Global Routing에서 현재 선택 항목을 확인하세요. Config를 사용한다면 Config로 이동해 실제 활성화된 파일을 확인한 다음 정책 참조와 FINAL을 점검하세요.
3. 수동 연결 테스트. 연결을 켜고 대상을 명확히 지정해 접속하세요. Data 및 확인 가능한 기록을 함께 살펴보고 Connectivity Test만으로 성공 여부를 판단하지 마세요.
4. 보조 설정 조정. 필요한 경우 DNS, Test Method 및 Diagnostics를 하나씩 확인하고 기존 값을 보관하세요. 여러 연결 단계를 동시에 변경하지 마세요.
5. 자동 동작은 마지막에 활성화. 수동 연결 확인을 마친 다음 On Demand, Today Widget 및 iCloud를 설정하고 트리거, 조작 및 동기화 결과를 각각 테스트하세요.

문제가 어느 단계에서 발생하는지 여전히 판단하기 어렵다면 먼저 문제 해결을 확인하세요. 처음 사용하는 중이며 가져오기와 권한 설정을 마치지 않았다면 여러 고급 옵션을 조정하기 전에 빠른 시작 안내부터 진행하세요. 검증을 마친 구성을 보관해 두면 임시 변경을 계속 추가하는 것보다 이후 관리가 쉽습니다.