Shadowrocket
라우팅 모드와 설정

Global Routing은 Home에 있습니다. 도메인이나 주소에 따라 요청을 분기하려면 Config를 선택하세요. 선택한 서버가 요청을 처리할 수 있는지 임시로 확인할 때는 Proxy를, 현재 네트워크에서 대상에 직접 접속할 수 있는지 확인할 때는 Direct를 사용할 수 있습니다. 변경 후에는 테스트 요청을 다시 보내세요. 기존 연결은 이전 세션 상태를 유지할 수 있습니다.

모드 이름은 Config, Proxy, Direct입니다. 화면의 Proxy는 모드 이름이고 규칙의 PROXY는 정책 키워드입니다. 서로 관련은 있지만 Proxy를 선택했다고 특정 규칙이 활성화되는 것은 아닙니다.

Config: 규칙 설정에 따라 정책 결정

먼저 Config에서 사용할 설정 파일을 확인한 다음 Home으로 돌아가 Global Routing을 Config로 설정하세요. 파일을 가져오기만 해서는 해당 파일이 선택된 것이 아닙니다. 규칙을 올바르게 작성했더라도 규칙을 사용하는 모드여야 적용됩니다. 테스트할 때는 PROXY로 처리될 것으로 예상하는 대상 하나와 DIRECT로 처리될 것으로 예상하는 대상 하나를 각각 확인하세요. 웹페이지 하나가 열린다는 이유만으로 설정 전체가 올바르다고 판단하지 마세요.

Proxy: 프록시 경로 임시 확인

Home의 SERVER 목록에서 현재 선택 항목을 확인한 다음 Proxy를 선택하고 연결을 켜세요. 여기서 '전체 모드'는 앱이 처리하는 범위의 요청을 프록시로 일괄 처리한다는 뜻이며, 기기의 모든 시스템 동작을 포괄적으로 설명하는 표현은 아닙니다. Proxy는 작동하지만 Config가 작동하지 않는다면 규칙 일치 여부와 현재 설정을 중점적으로 확인하세요. 문제 해결이 끝나면 원래 사용하려던 모드로 되돌리세요.

Direct: 현재 네트워크 경로 확인

Home에서 Global Routing을 Direct로 설정한 뒤 대상에 다시 접속하세요. Direct는 직접 연결할 수 없는 대상에 접속할 수 있게 해 주지 않으며, 연결 스위치를 끄는 것과도 다릅니다. 바뀌는 것은 처리 정책입니다. 현재 VPN 연결을 완전히 중지하려면 Home의 연결 스위치를 조작하세요. 로컬 네트워크 기기에 접속할 수 없다면 먼저 Direct로 비교해 본 다음 Config에서 해당 주소 규칙을 확인하세요.

규칙은 보통 Config의 설정 파일에서 Rule 섹션을 확인하고 편집합니다. DOMAIN은 전체 도메인과 일치하고, DOMAIN-SUFFIX는 도메인 접미사와 하위 도메인에 일치하며, DOMAIN-KEYWORD는 도메인에 포함된 키워드로 일치 여부를 판단합니다. 주소 조건에는 IP-CIDR와 IP-CIDR6를 사용할 수 있습니다. GEOIP는 IP 주소의 지역 정보를 바탕으로 하며, 콘텐츠에 사용된 언어나 사용자의 실제 위치를 판별하지는 않습니다.

주요 정책은 PROXY, DIRECT, REJECT이며 각각 프록시 처리, 직접 연결, 요청 거부에 사용됩니다. 규칙은 일반적으로 위에서 아래 순서로 확인되며, 먼저 유효하게 일치하는 규칙이 결과를 결정합니다. 따라서 구체적인 예외를 포괄적인 조건보다 앞에 두고 FINAL은 마지막 기본 규칙으로 남겨 두세요. 아래 예시는 구문 설명용이며, 예시 도메인은 실제로 접속해야 하는 서비스를 뜻하지 않습니다.

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

수정하기 전에 원래 설정을 저장하고, 수정 후 파일이 정상적으로 불러와지는지 확인하세요. 확인하지 않은 규칙을 한꺼번에 많이 추가하지 마세요. 예를 들어 너무 짧은 DOMAIN-KEYWORD는 관련 없는 도메인과 일치할 수 있고, 지나치게 넓은 주소 범위는 로컬 네트워크 접속에 영향을 줄 수 있습니다. USER-AGENT는 요청에서 실제로 확인할 수 있는 관련 정보가 있어야 하므로 모든 트래픽에 적용되는 일반 조건으로 적합하지 않습니다.

DNS, Host 또는 URL Rewrite를 수정할 때는 각 설정 섹션의 역할을 구분하고 Rule에 섞어 넣지 마세요. 전체 구문과 우선순위, 섹션별 설명은 규칙 참고 가이드에서 확인할 수 있습니다. 여기서는 먼저 Config가 적용되는지 확인한 뒤 규칙 일치 결과를 검증하는 것이 중요합니다.

Subscribe에서는 기존 구독 주소를 사용해 서버 목록을 가져오고 업데이트할 수 있으며, SERVER에는 선택 가능한 서버가 표시됩니다. 기존 구독은 보통 Home의 추가 메뉴에서 Add Server로 이동한 뒤 Subscribe를 선택하고 주소를 입력해 저장하면 됩니다. 서버 정보를 직접 입력할 때는 기존 서버 정보와 일치하는 프로토콜 유형을 선택하세요. 필요한 항목은 프로토콜 유형에 따라 다르므로 서로 다른 프로토콜의 매개변수를 바꿔 사용할 수 없습니다.

저장한 뒤 Home으로 돌아가 목록에 원하는 항목이 표시되는지 확인하고 사용할 서버를 선택하세요. 이름은 항목을 구분하기 위한 것이며 프로토콜, 인증 정보 또는 대상 주소가 올바르다는 뜻은 아닙니다. Connectivity Test를 실행한 다음 연결을 켜고 실제 요청을 확인하세요. 테스트 하나에 응답이 왔다고 해서 모든 대상에 접속할 수 있는 것은 아닙니다.

구독 업데이트: 그룹을 확인한 뒤 새로 고침

해당 구독의 업데이트 기능을 찾아 필요한 그룹만 새로 고친 뒤 성공 결과가 표시되는지 확인하세요. 구독 업데이트로 서버가 추가·삭제되거나 이름이 바뀔 수 있으므로 업데이트 후 현재 선택 항목이 남아 있는지도 확인해야 합니다. 그룹이 비어 있거나 항목 수가 예상과 다르게 바뀌었다면 주소 유효성과 네트워크 상태부터 확인하세요. 기존 선택 사항과 직접 입력한 메모가 사라질 수 있으므로 모든 설정을 바로 삭제하고 다시 가져오지 마세요.

구독 주소에는 접속 인증 정보가 포함될 수 있으므로 민감한 정보로 취급해야 합니다. 전체 주소가 공개 스크린샷, 웹페이지 또는 진단 기록에 노출되지 않도록 하세요. 기존 구독과 Config 파일은 서로 다른 개념입니다. 구독은 주로 서버 항목을 관리하고 Config는 규칙과 기타 설정을 담습니다. 구독을 업데이트해도 현재 규칙 파일 확인을 대신할 수 없습니다.

프로토콜 항목: 기존 서버 매개변수 확인

Shadowsocks, VMess, VLESS, Trojan, Hysteria2 등의 프로토콜은 연결 및 인증 항목이 서로 다릅니다. 추가할 때 프로토콜을 먼저 확인한 다음 주소, 포트, 인증 정보와 관련 전송 설정을 하나씩 점검하세요. 테스트를 통과시키려고 검증 옵션을 임의로 끄지 마세요. 필수 매개변수가 없다면 항목을 임의로 조합하지 말고 원래 서버 정보를 다시 확인하세요.

On Demand는 설정한 조건에 따라 VPN 연결을 시작하며, 각 요청에 적용할 정책을 판단하는 Rule을 대신하지 않습니다. Global Routing과는 설정 범위가 다릅니다. On Demand는 언제 연결할지를, Global Routing은 연결된 뒤 요청을 어떻게 처리할지를 결정합니다. On Demand를 설정해도 서버 매개변수 오류나 잘못된 규칙 설정은 해결되지 않습니다.

Home에서 On Demand로 이동해 현재 스위치 상태와 조건 목록을 확인한 뒤 앱에 표시되는 네트워크 조건을 설정하세요. 조건은 한 번에 하나씩 추가하고 저장한 다음 해당 네트워크에 연결해 트리거 결과를 확인하세요. 이어 조건에 해당하지 않는 네트워크에서도 동작을 확인합니다. 화면 구성은 현재 앱에 표시되는 내용에 따르며, 특정 네트워크에만 적용되는 조건을 모든 네트워크에 공통으로 적용된다고 생각하지 마세요.

수동으로 연결을 끊은 뒤 다시 연결된다면 On Demand가 켜져 있는지, 현재 환경이 트리거 조건에 맞는지 먼저 확인하세요. 자동 연결을 일시 중지하려면 Home 스위치만 반복해서 조작하지 말고 On Demand 설정도 함께 확인해야 합니다. 네트워크 전환, 기기 깨우기, 기존 세션이 관찰 결과에 영향을 줄 수 있으므로 시스템 상태가 전환될 때까지 기다린 뒤 요청을 다시 보내 검증하세요.

Data 페이지에서 앱에 기록된 트래픽 정보를 확인할 수 있습니다. 먼저 어떤 항목과 통계 범위가 표시되는지 확인한 다음 업로드와 다운로드 데이터를 비교하세요. 초기화 기능이 있다면 필요한 기록을 초기화 전에 보관하세요. 클라이언트 통계를 초기화해도 기존 구독의 원격 계정 상태는 바뀌지 않습니다.

특정 작업에서 트래픽이 발생했는지 확인하려면 작업 전 수치를 기록하고 명확한 접속을 한 번 수행한 뒤 Data로 돌아와 변화를 비교하세요. 백그라운드 작업, 다른 앱의 요청, 연결 유지 활동도 동시에 트래픽을 만들 수 있으므로 두 수치의 차이를 특정 웹페이지의 정확한 사용량으로 간주하지 마세요. 통계가 증가했다는 것은 데이터 전송이 있었다는 뜻일 뿐, 대상 콘텐츠가 완전히 로드되었다는 것을 단독으로 증명하지는 않습니다.

트래픽 방향과 규칙 적용 결과를 확인할 때는 Data를 현재 Global Routing, Config 및 요청 기록과 함께 살펴보세요. 클라이언트 통계를 잔여 사용량이나 청구서의 기준으로 삼지 마세요. 사용 중인 서비스의 이용 내역을 확인해야 한다면 해당 계정 기록을 확인하고, 통계 기간과 계산 방식이 다를 수 있다는 점에 유의하세요.

DNS: 현재 이름 해석 설정의 출처부터 확인

DNS는 도메인 이름을 주소로 변환하며, 변환 결과는 주소 기반 규칙의 일치 여부에도 영향을 줄 수 있습니다. Settings의 DNS 관련 설정과 현재 Config를 확인해 어떤 설정이 실제로 적용되는지 먼저 파악한 뒤 이름 해석 방식이나 서버를 변경하세요. 도메인 접속에 실패하지만 주소로 접속할 때 동작이 다르다면 DNS도 점검할 수 있습니다. 다만 이것만으로 DNS 장애가 확정되는 것은 아닙니다.

수정 전에 기존 값을 기록하고, 수정 후 요청을 다시 보내세요. 필요한 경우 앱에서 제공하는 방법으로 캐시를 처리하세요. DNS, 규칙, 서버를 동시에 바꾸면 원인을 파악하기 어렵습니다. 일부 설정은 특정 네트워크 경로에 따라 달라지므로 다른 주소로 바꿔도 개선되지 않을 수 있고, 로컬 네트워크 이름 해석에 영향을 줄 수도 있습니다.

Test Method: 같은 테스트 방법으로 비교

Test Method는 연결 테스트에 사용할 방법을 정하며 Settings의 관련 테스트 설정에서 확인할 수 있습니다. 먼저 방법 하나를 정하고 같은 서버 목록에서 Connectivity Test를 실행하세요. 테스트 방법마다 확인하는 연결 단계가 다르므로 결과를 한데 섞어 순위를 매기면 안 됩니다. 테스트 응답이 빠르다고 지속 전송 속도가 높은 것은 아니며, 모든 앱 요청이 성공한다는 뜻도 아닙니다.

테스트 항목에 대상 주소가 포함된다면 의미를 분명히 알고 있는 주소를 사용하고, 비교 테스트 중에는 주소를 바꾸지 마세요. 특정 테스트가 실패하면 실제 요청으로 교차 확인하고 프로토콜과 테스트 방법이 적절한지 살펴보세요. 수치 하나만 보고 서버를 삭제하지 마세요.

Today Widget: 빠른 조작 전에 현재 선택 확인

Today Widget은 빠르게 확인하거나 조작할 수 있는 진입점을 제공합니다. 먼저 Settings에서 관련 옵션을 확인한 다음 시스템에서 지원하는 방법으로 해당 영역에 추가하세요. 이 항목이 표시되는지, 어떤 조작을 사용할 수 있는지는 현재 시스템과 앱 화면에 따라 달라집니다. 빠른 메뉴를 사용하기 전에도 Home에서 선택한 서버와 Global Routing을 확인해야 합니다.

빠른 메뉴는 조작 단계를 줄여 주지만 현재 네트워크에 적합한 설정을 자동으로 판단하지는 않습니다. 표시 상태가 예상과 다르면 빠른 메뉴의 한 번의 표시만으로 연결에 성공했다고 판단하지 말고 앱을 열어 연결 상태를 확인하세요.

iCloud: 동기화 범위 확인

iCloud 관련 동기화는 Settings에서 확인해야 하며 기기 시스템에서도 앱의 iCloud 사용을 허용해야 합니다. 켜기 전에 앱에 표시되는 동기화 항목을 확인하세요. 구독, 설정, 인증 정보, 기록이 모두 같은 방식으로 동기화된다고 가정하면 안 됩니다. 두 기기에서 각각 동기화 상태를 확인하고 중요한 설정은 복구할 수 있는 사본으로 보관하세요.

같은 데이터를 수정하기 전에는 다른 기기의 동기화가 완료될 때까지 기다리세요. 여러 기기에서 동시에 편집하면 충돌이 발생할 수 있습니다. iCloud 동기화는 App Store 구매 복원과 다릅니다. 앱 구매와 재다운로드는 App Store에서 관리하며, 설정 동기화 여부는 앱 설정과 계정 상태에 따라 달라집니다. 인증 정보가 포함된 설정은 계속 주의해서 다루세요.

Diagnostics는 연결 문제를 진단하는 도구이며 Settings에서 찾을 수 있습니다. 화면에 표시되는 진단 항목을 실행하고 결과를 확인해 현재 네트워크, 도메인 이름 해석, 서버 연결, 대상 요청의 각 단계를 구분하세요. 진단 결과는 테스트 당시의 상태를 나타내므로 장기적인 가용성을 보장하지 않습니다. 오류 메시지 하나만으로 모든 대상에 접속할 수 없다고 판단해서도 안 됩니다.

1. 기본 네트워크 확인. 현재 Wi-Fi 또는 셀룰러 네트워크가 작동하는지 확인하세요. 필요하면 같은 대상을 Direct로도 접속해 두 경로의 차이를 기록하세요.
2. SERVER 확인. 선택한 항목, 프로토콜, 포트, 인증 정보를 점검하세요. 기존 구독을 업데이트했다면 선택 항목이 바뀌지 않았는지도 확인하세요.
3. Connectivity Test 실행. 동일한 Test Method를 유지하고 실제 접속 결과와 함께 판단하세요. 테스트 수치를 속도 보장으로 받아들이지 마세요.
4. Proxy로 전환해 비교. Proxy는 작동하지만 Config가 제대로 작동하지 않는다면 Config에서 규칙 순서, 정책, FINAL을 확인하세요. 둘 다 작동하지 않으면 서버와 네트워크 조건을 더 살펴보세요.
5. 마지막으로 자동 연결 및 보조 설정 확인. On Demand, DNS, 동기화 상태를 확인하고 한 번에 변수 하나만 바꾸세요. 검증한 뒤 변경 사항을 유지할지 되돌릴지 결정하세요.

진단 정보를 저장하거나 공유하기 전에 구독 전체 주소, 서버 인증 정보 및 기타 개인 정보를 삭제하세요. 재현 단계와 사용한 모드, 필요한 오류 설명만 남기면 문제를 파악하는 데 도움이 됩니다. 가져오기부터 연결까지 전체 과정을 다시 확인하려면 시작하기를 참고하세요. 규칙을 하나씩 수정하려면 규칙 참고 가이드로 이동하세요.