Shadowrocket에서 사용자 규칙을 설정할 때는 구체적인 예외를 먼저 쓰고, 적용 범위가 넓은 규칙을 그다음에 배치한 뒤 마지막에 FINAL을 둡니다. 기존 설정이 정상적으로 작동하는 상태에서 라우팅을 조정하려는 사용자를 위한 안내입니다. Global Routing과 현재 Config를 확인하고, 예시로 문법을 익힌 다음 새 연결을 만들어 실제 적용 규칙을 점검하세요. PROXY 설정은 이미 본인이 이용 중인 서비스와 구독이 있다는 전제하에 설명합니다.
1. Config 적용 상태를 확인한 뒤 규칙 순서 점검하기
규칙 내용을 저장했다고 해서 현재 연결에 적용되는 것은 아닙니다. Home에서 Global Routing을 확인하고, 이 글처럼 규칙별로 트래픽을 나누려면 Config를 선택하세요. 그런 다음 Config에서 현재 선택된 구성 파일을 확인합니다. 활성화되지 않은 다른 파일을 수정해도 현재 설정의 매칭 결과는 바뀌지 않습니다.
Global Routing의 Proxy, Direct, Config, Scene은 라우팅 모드이며 규칙 키워드 네 가지를 뜻하지 않습니다. Proxy와 Direct는 각각 전체 프록시와 전체 직접 연결에 사용합니다. Config는 현재 설정에 따라 트래픽을 분기하고, Scene은 상황별로 라우팅 동작을 구성합니다. 문제를 확인할 때는 실제 Scene 설정도 살펴보세요. 라우팅 모드와 규칙 행 끝에 지정하는 정책을 혼동하지 않아야 합니다.
- Config에서 현재 파일을 복사해 두고 사용 중인 구성 이름을 기록합니다.
- Home → Global Routing에서 Config를 선택해 다른 라우팅 모드에서 규칙을 확인하고 있는 것은 아닌지 점검합니다.
- Config로 돌아가 선택된 파일을 수정하고 저장한 뒤 테스트 요청을 새로 보냅니다.
- 앱의 연결 기록에서 대상과 적용된 정책을 확인합니다. 이전 연결이 계속 사용되고 있다면 해당 연결을 종료한 뒤 다시 테스트하세요.
2. 위에서 아래로 매칭: 일치한 뒤에는 더 구체적인 규칙을 찾지 않습니다
일반적인 규칙은 목록 순서대로 확인하며, 처음 일치한 규칙이 적용할 정책을 결정합니다. 같은 요청에 대해 뒤의 규칙을 다시 확인하거나 순서를 자동으로 바꾸지 않습니다. 뒤에 있는 도메인 규칙이 더 길어도 Shadowrocket이 앞쪽으로 올려 주지는 않습니다. 예외 규칙은 더 넓은 범위의 규칙보다 앞에 배치해야 합니다.
예를 들어 DOMAIN-SUFFIX,example.com,PROXY를 먼저 쓰고 DOMAIN,api.example.com,DIRECT를 뒤에 쓰면 api.example.com은 앞의 규칙에 먼저 일치합니다. 이 하위 도메인을 직접 연결하려면 DOMAIN 행을 위로 옮기세요. 아래 도메인은 문법 설명을 위한 예시이며 실제로 사용할 수 있는 서비스를 의미하지 않습니다.
[Rule]
DOMAIN,api.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT핵심: 중복 규칙을 추가하기 전에 예외 규칙을 위로 옮기세요
도메인이 예상대로 분기되지 않으면 먼저 그 위에 해당 도메인까지 포함하는 규칙이 있는지 확인하세요. 목록 끝에 같은 대상을 반복해서 추가해도 앞에서 이미 결정된 매칭 결과는 대개 바뀌지 않습니다.
3. 규칙 문법: 매칭 조건과 정책을 구분해 이해하기
대부분의 일반 규칙은 쉼표로 구분된 ‘유형, 매칭 값, 정책’ 구조를 사용합니다. FINAL은 매칭 값이 필요 없는 특수 기본 처리 행입니다. 쉼표는 영문 쉼표를 사용하고, 한 줄에 규칙 하나만 작성하세요. 설정 전체를 하나의 매칭 값 필드에 붙여 넣지 마세요.
| 규칙 예시 | 매칭 대상 | 확인할 점 |
|---|---|---|
DOMAIN,api.example.com,DIRECT | 전체 도메인 | 해당 도메인만 매칭하며 모든 하위 도메인을 포함하지 않습니다. |
DOMAIN-SUFFIX,example.com,PROXY | 도메인 접미사 | example.com과 모든 하위 도메인에 적용됩니다. 임의의 문자열 포함 여부를 검사하는 규칙은 아닙니다. |
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve | IPv4 대역 | 해당 주소 범위에 매칭됩니다. no-resolve는 이 IP 규칙의 매칭을 위해 별도로 도메인 조회를 시작하지 않습니다. |
GEOIP,CN,DIRECT | IP의 지리적 위치 | 사용하는 지리 데이터베이스를 기준으로 판단합니다. 도메인 접미사는 IP의 지리적 위치를 결정하지 않습니다. |
FINAL,PROXY | 앞선 규칙에 일치하지 않은 요청 | 마지막 기본 처리로 사용합니다. PROXY를 선택하려면 이용 가능한 프록시 아웃바운드가 있어야 합니다. |
도메인 규칙에는 프로토콜 접두사, 웹페이지 경로, 포트를 입력하지 않습니다. 예를 들어 대상 주소에 HTTPS, 경로, 443 포트가 포함되어도 DOMAIN의 매칭 값에는 호스트명만 씁니다. 포트에 따라 트래픽을 분기하려면 도메인 뒤에 :443을 붙이지 말고 해당 포트 규칙을 사용하세요.
4. DOMAIN-SUFFIX, IP-CIDR, GEOIP의 배치 방법
모든 설정에 적용되는 고정된 유형별 순서는 없습니다. 중요한 원칙은 예외를 해당 예외까지 포함하는 규칙보다 앞에 두는 것입니다. 일반적으로 정확한 도메인 예외를 먼저 배치하고, 그다음 도메인 접미사와 명시된 IP 대역, 범위가 넓은 GEOIP를 두고, 마지막에 FINAL을 둡니다. 특정 IP 대역을 먼저 처리해야 한다면 더 앞에 배치할 수도 있지만 어떤 요청에 영향을 주는지 확인해야 합니다.
[Rule]
DOMAIN,api.example.com,DIRECT
DOMAIN,metrics.example.com,REJECT
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY이 예시는 순서만 보여 주는 것이므로 전체 설정을 그대로 대체해서는 안 됩니다. api.example.com은 직접 연결 예외로 접미사 규칙보다 앞에 있고, metrics.example.com은 차단 예외로 역시 앞에 있습니다. 나머지 example.com 하위 도메인은 PROXY를 사용합니다. 192.168.0.0/16 행은 지정된 사설 대역에만 적용되며 모든 로컬 네트워크 주소를 뜻하지 않습니다.
- 도메인 조건: 특정 웹사이트나 하위 도메인을 지정할 때 적합합니다. 하위 도메인 하나를 예외로 처리하려고 전체 접미사 규칙의 정책을 바꾸지 마세요.
- IP-CIDR 조건: 알고 있는 IP 주소 범위를 처리할 때 적합합니다. 도메인 요청에서 이 단계에 IP 주소를 확보할 수 있는지는 DNS 조회 흐름과 no-resolve 등의 옵션에 따라 달라집니다.
- GEOIP 조건: 대체로 적용 범위가 넓으며 대상 IP와 데이터베이스에 따라 결과가 달라집니다. 같은 도메인도 다른 주소로 해석되면 매칭 결과가 달라질 수 있습니다.
- FINAL 조건: 구체적인 조건을 모두 배치한 뒤 마지막에 둡니다. 앞선 규칙에 하나도 일치하지 않은 요청에만 이 정책이 적용됩니다.
no-resolve가 앱 전체의 DNS 조회를 중지하거나 도메인 요청이 해당 규칙에 절대 일치하지 않게 한다는 뜻은 아닙니다. 이 옵션은 해당 IP 규칙의 매칭을 위해 별도로 조회를 시작하는 것을 제한합니다. 대상 자체가 IP이거나 처리 과정에서 이미 사용할 수 있는 주소가 있다면 실제 연결 기록을 함께 확인해야 합니다.
5. FINAL에 PROXY, DIRECT, REJECT 중 무엇을 선택할까?
FINAL은 ‘아직 분류되지 않은 요청’을 어떻게 처리할지 정하는 항목이지, 연결 실패 후 다시 시도하게 하는 스위치가 아닙니다. 앞선 규칙이 PROXY에 일치했다면 프록시 연결에 실패해도 FINAL로 넘어가지 않습니다. 대체 아웃바운드가 필요하다면 마지막 기본 처리로 실패한 요청을 넘기려 하지 말고 해당 정책 그룹의 동작을 확인하세요.
| 기본 처리 설정 예시 | 미매칭 요청 처리 | 사용 전 확인 사항 |
|---|---|---|
FINAL,PROXY | 프록시 아웃바운드로 보냅니다. | 이미 이용 중인 프록시를 사용할 수 있고, 직접 연결해야 하는 대상은 앞선 규칙에 명시되어 있습니다. |
FINAL,DIRECT | 대상에 직접 연결합니다. | 프록시가 필요한 대상은 앞선 규칙에 포함되어 있으며, 나머지 대상은 직접 연결해도 됩니다. |
FINAL,REJECT | 나머지 요청을 거부합니다. | 필요한 허용 규칙이 충분히 마련되어 있고 로그인, 이미지, API 요청이 누락됐는지 확인할 수 있습니다. |
DIRECT를 선택해도 시스템에서 만든 VPN 터널을 통해 처리될 수 있지만, 아웃바운드 정책은 프록시 서버를 사용하지 않는 것입니다. Shadowrocket을 종료한다는 뜻은 아닙니다. REJECT는 규칙 단계에서 요청을 거부하며 요청이 ‘유용한지’를 자동으로 구분하지 않습니다. 하나의 도메인에서 여러 기능을 제공한다면 도메인 전체를 거부할 때 정상 기능까지 영향을 받을 수 있습니다.
핵심: 분류되지 않은 트래픽의 처리 방식에 맞춰 기본 정책을 선택하세요
먼저 예외로 처리해야 할 대상을 정리하고, 나머지 요청을 어떻게 처리할지 결정하세요. 오류 하나를 없애려고 FINAL을 세 정책 사이에서 반복해서 바꾸지 마세요.
6. 수정 후 설정 확인 및 되돌리기
대상, 매칭된 규칙, 아웃바운드 정책을 함께 확인해야 합니다. 웹페이지가 열린다는 이유만으로 설정이 올바르다고 판단할 수는 없습니다. 브라우저 캐시, 기존 장기 연결, 페이지에서 사용하는 여러 도메인의 요청 때문에 겉으로 보이는 결과와 새 규칙의 실제 적용 범위가 다를 수 있습니다.
- 수정 전 상태 보관: 원래 설정을 저장하고, 정상적으로 접속되는 대상 하나와 현재 라우팅 모드를 기록합니다.
- 변경 범위 최소화: 한 번에 규칙 하나 또는 순서 하나만 조정합니다. 저장한 뒤 현재 Config에서 해당 파일이 계속 선택되어 있는지 확인하세요.
- 새 연결 만들기: 테스트 페이지를 닫았다가 다시 엽니다. 필요한 경우 관련 앱의 기존 연결을 종료한 뒤 요청을 다시 보냅니다.
- 연결 기록 확인: 앱의 연결 기록에서 실제 호스트명이나 IP를 찾아 매칭된 규칙과 최종 정책을 확인합니다. 웹사이트의 대표 도메인만 확인하지 마세요.
- 수정 전 상태로 복구: 문제가 생기면 방금 추가한 규칙을 되돌리거나 보관해 둔 설정을 다시 선택한 뒤 같은 대상으로 재시험합니다.
설정이 원격 콘텐츠를 기반으로 한다면 업데이트 후 로컬 수정 사항이 덮어써졌는지도 확인하세요. 서비스 주소 목록 업데이트와 Config 규칙 파일 업데이트는 서로 다른 작업이므로 업데이트 대상별로 확인해야 합니다. 사용자 규칙을 계속 보관하려면 직접 관리하고 복구할 수 있는 설정에 저장하세요.
7. Shadowrocket 사용자 규칙 자주 묻는 질문
DIRECT를 설정했는데도 왜 PROXY를 사용하나요?
먼저 Home → Global Routing에서 Config가 선택되어 있는지 확인한 다음, Config에서 현재 사용 중인 파일을 수정했는지 확인하세요. 이어서 DIRECT 위에 같은 대상을 포함하는 DOMAIN-SUFFIX나 다른 규칙이 있는지 점검합니다. 구체적인 예외 규칙을 위로 옮기고 새 연결로 다시 테스트하세요.
FINAL을 맨 앞에 두면 어떻게 되나요?
FINAL이 해당 위치까지 도달한 요청의 기본 처리로 적용되어 뒤에 있는 구체적인 규칙이 예상대로 작동하지 않을 수 있습니다. FINAL을 규칙 목록 끝으로 옮겨 명확한 최종 기본 처리를 하나만 두고, 위쪽 조건이 별도 처리가 필요한 대상을 포함하는지 확인하세요.
REJECT를 추가한 뒤 로그인과 이미지가 함께 안 되는 이유는 무엇인가요?
차단된 도메인에서 로그인, 이미지, API 요청도 처리하는지 확인하세요. 먼저 방금 추가한 REJECT를 되돌려 기존 상태를 복구한 뒤 연결 기록을 확인해 매칭 범위를 좁히세요. DOMAIN-SUFFIX는 특정 웹페이지 경로가 아니라 해당 도메인과 하위 도메인 전체를 차단합니다.
GEOIP가 웹사이트가 속한 지역과 다르게 매칭됩니다. 규칙이 작동하지 않는 건가요?
반드시 그렇지는 않습니다. GEOIP는 운영 주체의 소재지가 아니라 요청 대상 IP가 데이터베이스에 등록된 지역을 기준으로 판단합니다. 먼저 실제로 해석된 주소와 매칭 기록을 확인하세요. 특정 도메인을 항상 같은 방식으로 처리하려면 GEOIP 앞에 명시적인 도메인 규칙을 추가하면 됩니다.