Shadowrocket 사용자 지정 규칙 순서와 설정 방법

이 글 미리보기

이 글은 이미 이용 중인 서비스 제공업체와 구독이 있으며 Shadowrocket 규칙을 수정하려는 사용자를 위한 안내입니다. 먼저 Home에서 Global Routing이 Config로 설정되어 있는지 확인한 다음, Config에서 현재 선택된 구성을 확인하세요. Rule 영역을 ‘정확한 예외, 넓은 범위, FINAL’ 순으로 정리하고 새 요청을 만들어 매칭 기록을 확인합니다. 예제는 매칭 방식만 설명하며 연결 정보는 포함하지 않습니다.

시작 위치 확인: 구성을 선택한 뒤 Config로 트래픽 분기

Shadowrocket의 Home 화면에서 Global Routing을 열고 Config를 선택합니다. Config로 이동해 수정할 구성이 선택되어 있는지 확인한 다음, 해당 구성의 편집 화면에서 Rule 영역을 찾습니다. 텍스트 구성의 섹션 표시는 [Rule]이며 규칙은 한 줄에 하나씩 입력합니다. 수정하기 전에 복구할 수 있도록 사본을 저장해 두고, 현재 정상적으로 작동하는 구성을 바로 덮어쓰지 마세요.

Global Routing의 Proxy, Direct, Config, Scene은 서로 다른 작동 모드입니다. Proxy와 Direct는 전체 트래픽의 출구를 선택하는 설정이므로 개별 사용자 지정 규칙의 정확성을 확인하는 데 사용하지 않습니다. 이 글에서는 요청이 선택한 구성에 따라 분기되도록 Config를 사용합니다. Scene은 상황별로 설정을 적용하므로 테스트할 때는 먼저 작동 조건을 고정해 Scene 변경으로 결과가 달라지지 않도록 합니다.

Home → Global Routing에서 Config를 선택하고 현재 사용하는 프록시 선택을 기록합니다.
Config로 이동해 현재 구성 이름을 확인한 다음 사본에서 Rule 영역을 수정합니다.
구성을 저장하고 여전히 현재 선택된 구성인지 확인한 뒤 테스트 연결을 새로 만듭니다.
테스트할 대상을 정해 접속한 다음 Data의 연결 기록에서 대상, 매칭된 규칙, 출구 정보를 확인합니다. 표시되는 항목은 현재 화면을 기준으로 확인하세요.

구독의 서버 목록과 Config의 트래픽 분기 규칙은 용도가 다릅니다. 기존 구독을 업데이트하면 일반적으로 연결 정보가 갱신되며, 이 사실만으로 Rule 영역이 바뀌었다고 판단할 수는 없습니다. 원격 구성 업데이트는 구성 내용을 대체할 수 있습니다. 문제를 확인하기 전에 어떤 리소스를 업데이트했는지 기록해 연결 매개변수 변경을 규칙 순서 변경으로 오인하지 않도록 하세요.

매칭 순서: 먼저 일치한 규칙이 이번 요청의 정책을 결정합니다

Rule 영역의 규칙은 위에서 아래 순서로 확인합니다. 규칙이 일치해 정책이 결정되면 더 ‘정확한’ 조건을 찾기 위해 아래 규칙을 계속 비교하지 않습니다. 따라서 정확한 규칙이 범위가 넓은 규칙보다 자동으로 우선하는 것은 아닙니다. 먼저 매칭되게 하려면 해당 규칙을 범위 규칙보다 위에 배치해야 합니다.

새 요청 생성 대상 확인 순서대로 매칭 정책 결정 출구로 전송

예를 들어 api.example.com은 PROXY를 사용하고 example.com의 다른 하위 도메인은 DIRECT로 연결하려면 다음 순서로 규칙을 배치할 수 있습니다. 예시 도메인은 문법 설명용입니다. 네트워크 연결을 테스트할 때는 사용 권한이 있고 접속 가능 여부를 확인한 대상을 사용하세요.

[Rule]
DOMAIN,api.example.com,PROXY
DOMAIN-SUFFIX,example.com,DIRECT
FINAL,PROXY

요청 대상이 api.example.com이면 첫 번째 DOMAIN 규칙이 일치합니다. 대상이 www.example.com이면 첫 번째 규칙은 일치하지 않고 두 번째 DOMAIN-SUFFIX 규칙이 적용됩니다. DOMAIN-SUFFIX는 해당 도메인 자체와 하위 도메인에 모두 적용되며, 문자열 일부가 포함된 모든 도메인을 뜻하지는 않습니다.

확인 포인트: 예외 규칙을 범위 규칙보다 먼저 배치

같은 대상이 DOMAIN과 DOMAIN-SUFFIX 조건을 모두 만족한다면 두 규칙의 순서를 바꾼 다음 새 요청으로 테스트하세요. 정확한 규칙을 나중에 추가해도 먼저 일치한 범위 규칙을 덮어쓸 수 없습니다.

정책 설정: PROXY, DIRECT, REJECT는 처리 방식만 결정합니다

규칙은 보통 규칙 유형, 매칭 값, 정책으로 구성되며 영문 쉼표로 구분합니다. 예를 들어 DOMAIN,api.example.com,PROXY에서 DOMAIN은 매칭 유형, 도메인은 매칭 값, PROXY는 일치 후 적용할 정책입니다. 도메인만 입력해야 하는 필드에 전체 URL이나 경로, 전각 쉼표를 넣지 마세요.

3가지

기본 정책: PROXY / DIRECT / REJECT

2가지

도메인 예시: DOMAIN은 정확히 일치, DOMAIN-SUFFIX는 접미사로 매칭

1개

마지막에 두는 공통 대체 규칙 FINAL

정책	규칙 일치 후 동작	확인할 조건
`PROXY`	현재 구성에서 선택한 프록시를 통해 처리	프록시를 사용할 수 있고 연결 설정이 서버 측 설정과 일치하는지 확인
`DIRECT`	프록시 서버를 거치지 않고 대상에 직접 연결	현재 네트워크에서 대상에 직접 접속할 수 있는지 확인
`REJECT`	일치한 요청 거부	차단이 필요한 대상인지, 필요한 종속 요청까지 차단하지 않는지 확인

PROXY 규칙이 일치했다고 원격 연결까지 성공하는 것은 아닙니다. 규칙 판정이 정확해도 프록시 연결 주소, 포트 또는 인증 정보가 잘못되면 연결에 실패할 수 있습니다. DIRECT도 모든 시스템 네트워크 설정을 우회한다는 뜻은 아닙니다. 여기서는 프록시 서버를 거쳐 전달하지 않는다는 의미입니다. REJECT는 명시적인 거부이므로 그로 인한 접속 실패를 연결 시간 초과로 판단하지 마세요.

[Rule]
DOMAIN,blocked.example.com,REJECT
DOMAIN,api.example.com,PROXY
DOMAIN-SUFFIX,example.com,DIRECT
FINAL,PROXY

이 구성에서는 blocked.example.com이 example.com에 속하더라도 첫 번째 규칙에 따라 거부됩니다. REJECT 규칙을 DOMAIN-SUFFIX 뒤로 옮기면 이 대상을 차단할 수 없습니다. 웹사이트는 별도의 로그인, 이미지, API 도메인에도 요청을 보낼 수 있습니다. 테스트할 때는 홈페이지가 열리는지만 보지 말고 연결 기록에서 각 요청을 확인하세요.

FINAL 대체 규칙: 마지막에 배치하고 도메인은 입력하지 않습니다

FINAL은 앞선 규칙과 일치하지 않은 요청을 처리하며 도메인이나 주소 조건을 포함하지 않습니다. 기본 형식은 FINAL,PROXY 또는 FINAL,DIRECT이며 FINAL,example.com,PROXY처럼 작성하지 않습니다. FINAL은 하나만 명확하게 지정해 Rule 영역의 마지막에 둡니다. 중간에 배치하면 그 아래 규칙은 매칭될 기회를 잃습니다.

나머지 요청은 PROXY로 처리

DOMAIN: blocked.example.com,REJECT
DOMAIN-SUFFIX: example.com,DIRECT
FINAL: PROXY

차단 예외와 직접 연결 범위를 먼저 지정하고, 나머지 요청은 PROXY로 보냅니다.

지정한 대상만 PROXY로 처리

DOMAIN: blocked.example.com,REJECT
DOMAIN-SUFFIX: example.com,PROXY
FINAL: DIRECT

차단 예외와 프록시 범위를 먼저 지정하고, 나머지 요청은 DIRECT로 처리합니다.

위 예시는 서로 다른 트래픽 분기 방식입니다. 두 카드의 FINAL 규칙을 하나의 Rule 영역에 모두 추가하지 마세요. 어떤 정책을 대체 규칙으로 쓸지는 현재 네트워크에서 대상에 접속할 수 있는지와 연결 요구 사항에 따라 결정해야 합니다. 도메인 규칙이 없으면 요청은 FINAL로 처리됩니다. 따라서 규칙이 빠졌을 때는 대체 정책이 적용되는 현상부터 나타나는 경우가 많습니다.

IP-CIDR과 GEOIP 추가: 명확한 주소 범위를 먼저 처리

도메인 규칙은 도메인 조건을 처리하고 IP-CIDR은 IP 주소 대역을 처리합니다. 로컬 기기에 접속할 때 알려진 사설 네트워크 대역을 범위가 더 넓은 주소 분류 규칙보다 앞에 배치할 수 있습니다. 아래의 192.168.0.0/16은 192.168.0.0부터 192.168.255.255까지의 주소를 포함합니다. 모든 가정용 네트워크가 이 대역을 사용하는 것은 아니므로 라우터의 실제 주소 계획에 맞게 조정하세요.

[Rule]
DOMAIN,blocked.example.com,REJECT
DOMAIN,api.example.com,PROXY
DOMAIN-SUFFIX,example.com,DIRECT
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

IP-CIDR은 IPv4 대역을 매칭합니다. 이 예시는 알려진 사설 네트워크 주소를 대상으로 하며, 이를 ‘모든 로컬 리소스가 포함됐다’고 확대 해석해서는 안 됩니다.
no-resolve는 이 IP 규칙을 매칭하기 위해 도메인 조회를 별도로 시작하지 말라는 뜻입니다. 전체 요청 과정에서 DNS를 사용하지 않는다는 의미는 아닙니다.
GEOIP,CN,DIRECT는 대상 IP의 지리적 위치 데이터에 따라 매칭합니다. 도메인 접미사와 사용자 위치는 이 판정의 기준이 아닙니다.
도메인이 서로 다른 주소로 해석될 수 있고 주소 위치 데이터도 예상과 다를 수 있습니다. 경로를 고정해야 하는 도메인에는 앞쪽에 명시적인 도메인 규칙을 우선 사용하세요.

요청에 도메인 정보만 있고 주소 규칙에 사용할 대상 IP가 없다면, no-resolve가 붙은 사설 네트워크 규칙은 이 요청을 위해 별도로 DNS 조회를 시작하지 않습니다. 반면 IP 관련 판정에는 이미 존재하는 조회 결과나 조회 과정이 영향을 줄 수 있습니다. 같은 도메인의 연결 경로가 달라지는 경우 실제 대상 IP와 매칭 기록부터 확인한 뒤 DNS나 주소 위치 데이터를 살펴보세요. 규칙 순서가 무작위로 바뀐다고 단정하지 마세요.

저장 후 테스트: 세 가지 요청으로 규칙 오류와 연결 오류 구분

한 번에 한 그룹의 규칙만 수정하고 저장한 뒤 새 요청을 만드세요. 브라우저나 앱은 이미 연결된 세션을 재사용할 수 있으므로 규칙 파일을 저장했다고 기존 연결이 새 매칭 테스트로 바뀌지는 않습니다. 필요한 경우 테스트 앱의 기존 연결을 종료하거나 적절한 시점에 Shadowrocket 연결을 끊었다가 다시 연결한 다음 대상을 다시 방문하세요.

정확한 예외 규칙을 확인합니다. 정확한 조건과 범위 조건을 모두 만족하는 대상을 선택하고, 뒤쪽 DOMAIN-SUFFIX가 아닌 앞쪽 DOMAIN 규칙에 일치하는지 확인하세요.
범위 규칙을 확인합니다. 같은 접미사를 사용하지만 예외 목록에는 없는 대상을 골라 DOMAIN-SUFFIX 규칙이 처리하는지 확인하세요.
FINAL을 확인합니다. 접속 가능 여부가 확인되었으며 앞선 조건에는 해당하지 않는 대상을 선택해 예정된 대체 정책이 적용되는지 확인하세요.
REJECT를 확인합니다. 일시적으로 제어 가능한 테스트 대상을 사용해 거부 규칙이 적용되는지 확인하세요. 테스트가 끝나면 임시 규칙을 삭제해 일상적인 접속에 영향을 주지 않도록 합니다.

테스트 기록에는 대상 도메인, 실제 IP, Global Routing 모드, 일치한 규칙과 결과를 최소한으로 남기세요. ‘접속이 안 됨’이라고만 적지 마세요. 기록에서 예상한 규칙이 일치했지만 연결에 실패했다면 출구 연결을 확인합니다. 다른 규칙이 일치했다면 규칙 순서와 매칭 조건부터 점검하고 프로토콜 매개변수는 동시에 수정하지 마세요.

확인 포인트: 규칙 매칭을 확인한 뒤 출구를 점검

일치한 규칙이 예상과 다르면 구성 선택, 매칭 범위 또는 순서를 조정하세요. 올바른 규칙이 일치했는데 접속에 실패한다면 DIRECT의 네트워크 연결 가능성이나 PROXY의 연결 매개변수를 확인합니다. 한 번에 한 가지 요소만 수정하고 복구할 수 있는 사본을 보관하세요.

규칙 유지 관리: 업데이트 후 예외와 대체 규칙 재확인

원격 구성을 업데이트한 후에는 Rule 영역의 앞부분에 있는 예외 규칙과 마지막의 FINAL을 다시 확인해 사용자 지정 내용이 대체되지 않았는지 점검하세요. 구독을 업데이트한 뒤에는 기존에 사용하던 프록시 선택이 여전히 유효한지 확인합니다. 두 작업은 서로 다른 유지 관리 절차입니다. 구성 내용과 연결 정보를 구분해 기록해야 업데이트 전후의 동작 변화를 설명할 수 있습니다.

현재 정상적으로 작동하는 구성의 사본을 저장하고 사용자 지정 규칙의 목적과 예상 정책을 기록합니다.
DOMAIN-SUFFIX를 추가하기 전에 이미 범위가 더 넓은 규칙이 있는지 검색합니다. 유지해야 하는 정확한 예외는 해당 규칙보다 앞에 배치하세요.
중복되거나 연결할 수 없는 규칙을 삭제하고 FINAL 아래에 계속 적용해야 할 규칙이 남아 있지 않은지 확인합니다.
전체 필드를 확인하려면 구성 필드 안내를, 첫 연결 절차를 다시 확인하려면 사용 가이드를 참조하세요.

규칙은 요청의 트래픽 경로를 결정할 뿐 연결 서비스를 제공하지 않습니다. 클라이언트 앱의 일회성 구매와 연결 회선 이용권은 별개입니다. 이 글은 이미 이용 중인 서비스 제공업체와 구독이 있는 사용자를 전제로 합니다. Shadowrocket은 폐쇄형 상용 앱으로 주로 iPhone과 iPad에서 사용하며, 유일한 구입 경로는 App Store입니다. 시스템 요구 사항은 App Store 페이지를 기준으로 확인하세요.