Shadowrocket 사용자 규칙 및 우선순위: 위에서 아래로 매칭, FINAL 폴백과 PROXY/DIRECT/REJECT 정책

이 글 한눈에 보기

이 글은 Shadowrocket에서 자체 Config를 가져와 트래픽 분기 결과를 조정하려는 사용자를 위한 안내입니다. 요청이 어떤 규칙에 매칭되는지, 구체적인 규칙과 포괄적인 규칙의 순서를 어떻게 정할지, PROXY·DIRECT·REJECT와 FINAL을 언제 사용할지 설명합니다.

규칙 우선순위의 핵심: 첫 번째 매칭에서 중지

Shadowrocket의 규칙 목록은 모든 규칙을 동시에 계산한 뒤 가장 정확한 항목을 고르는 방식이 아닙니다. Config에 작성된 순서대로 위에서 아래로 하나씩 확인하며, 현재 요청이 어느 한 규칙과 매칭되면 이후 규칙은 해당 판단에 참여하지 않습니다. 따라서 우선순위는 위치로 결정되며, 규칙 이름이나 문자열 길이, 정책 유형이 자동으로 결정하지 않습니다.

예를 들어 같은 도메인이 정확한 DOMAIN 규칙과 전체 접미사를 포괄하는 DOMAIN-SUFFIX 규칙에 모두 매칭될 수 있습니다. DOMAIN-SUFFIX를 앞에 작성하면 더 구체적인 DOMAIN도 적용되지 않습니다. Config를 작성할 때는 예외 항목을 포괄적인 규칙보다 앞에 두고, 범위가 가장 넓은 폴백 항목은 마지막에 배치해야 합니다.

요청 시작도메인 확인규칙별 매칭첫 매칭정책 실행

일반적인 판단 과정은 다섯 단계로 나눌 수 있습니다. 앱이 연결을 시작하고, Shadowrocket이 대상 도메인 또는 IP를 확인한 뒤, [Rule]의 첫 줄부터 검사합니다. 첫 번째 매칭 규칙을 찾으면 검사를 멈추고 해당 줄 끝의 정책에 따라 처리합니다. 구체적인 규칙이 모두 매칭되지 않으면 FINAL로 이동합니다.

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

api.example.com에 접속하면 첫 번째 줄에 먼저 매칭되어 DIRECT를 사용합니다. www.example.com은 첫 줄과 매칭되지 않으므로 이후 DOMAIN-SUFFIX에 매칭되어 PROXY를 사용합니다. 대상이 사설 주소 대역 192.168.0.0/16에 있으면 DIRECT를 사용하고, 나머지 요청은 GEOIP 판단 후에도 매칭되지 않은 부분을 FINAL에 전달합니다.

DOMAIN, DOMAIN-SUFFIX, IP-CIDR와 GEOIP의 정렬 순서

규칙은 ‘범위가 좁고 의도가 명확한 항목’에서 ‘범위가 넓고 포괄적인 항목’ 순서로 배치해야 합니다. DOMAIN은 완전한 단일 도메인에만 매칭되므로 개별 예외에 적합합니다. DOMAIN-SUFFIX는 지정한 도메인과 하위 도메인을 포괄하고, IP-CIDR은 주소 대역으로 매칭되며, GEOIP는 대상 IP를 지리 데이터베이스 기준으로 분류합니다. FINAL은 특정 대상을 검사하지 않고 앞에서 매칭되지 않은 모든 요청을 받습니다.

1개

각 요청은 처음 매칭된 규칙 하나만 사용

4가지 상태

Global Routing：Config / Proxy / Direct / Scene

3가지 정책

이 글에서 사용하는 PROXY / DIRECT / REJECT

마지막 1줄

FINAL은 보통 하나만 남겨 마지막에 배치

권장 배치 계층

로컬 및 예약 주소: 먼저 LAN 주소와 명확하게 DIRECT가 필요한 대상을 처리하여 내부 장치 요청이 다른 정책으로 넘어가지 않도록 합니다.
정확한 도메인: DOMAIN으로 단일 호스트의 예외 처리를 지정합니다. 예를 들어 하나의 API 도메인이 뒤에 있는 접미사 규칙보다 우선하도록 할 수 있습니다.
도메인 접미사: DOMAIN-SUFFIX로 주 도메인과 모든 하위 도메인을 처리합니다.
주소 대역: IP-CIDR로 명확한 IPv4 네트워크 대역을 매칭합니다. 접두사 길이가 클수록 일반적으로 범위가 좁습니다.
지리 분류: GEOIP는 구체적인 도메인 및 주소 규칙 뒤에 배치하여 포괄적인 분류가 예외 요청을 먼저 가로채지 않도록 합니다.
최종 폴백: FINAL을 마지막에 두고 남은 모든 트래픽의 처리 방식을 명확히 지정합니다.

구체적인 규칙

DOMAIN: api.example.com,DIRECT
DOMAIN-SUFFIX: example.com,PROXY
IP-CIDR: 192.168.0.0/16,DIRECT

예외 항목은 적용 범위가 더 큰 규칙보다 앞에 작성합니다.

포괄적인 규칙

GEOIP: CN,DIRECT
FINAL: PROXY
위치: [Rule] 마지막 부분

구체적인 매칭을 먼저 완료한 뒤 지리 판단과 최종 폴백으로 넘어갑니다.

DOMAIN-SUFFIX의 값에는 도메인 자체만 작성하고 https://, 경로 또는 쿼리 매개변수는 포함하지 않습니다. 규칙은 전체 웹 주소가 아니라 호스트 이름에 매칭됩니다. cdn.example.com을 처리하려면 DOMAIN,cdn.example.com,DIRECT로 작성할 수 있습니다. example.com과 모든 하위 도메인을 포괄하려면 DOMAIN-SUFFIX,example.com,PROXY를 사용합니다.

IP-CIDR의 접두사 길이는 대상 네트워크 대역과 일치해야 합니다. 예를 들어 192.168.0.0/16은 192.168.0.0부터 192.168.255.255까지의 주소를 포함합니다. 이를 실수로 /24로 작성하면 하나의 하위 네트워크로 범위가 줄어들어 같은 종류의 다른 LAN 주소는 매칭되지 않습니다.

결론: 예외가 구체적일수록 앞에 배치

일반 규칙보다 우선해야 하는 단일 도메인, 단일 주소 대역 또는 LAN 예외는 DOMAIN-SUFFIX, GEOIP, FINAL보다 앞에 배치해야 합니다. 규칙을 더 구체적으로 작성하는 것만으로 자동으로 우선순위가 높아지지는 않습니다.

PROXY, DIRECT와 REJECT의 처리 차이

규칙 끝의 정책은 요청이 매칭된 후 처리되는 방식을 결정합니다. PROXY는 현재 Config가 지정한 프록시 정책으로 전달하고, DIRECT는 대상에 직접 연결하며, REJECT는 해당 요청을 거부합니다. 세 가지는 처리 동작이지 규칙 키워드가 아닙니다. 앞의 DOMAIN-SUFFIX, GEOIP, IP-CIDR 등은 ‘무엇을 매칭할지’를 판단하고, 끝의 정책은 ‘어떻게 처리할지’를 결정합니다.

정책	처리 결과	적합한 규칙 의도	확인할 핵심 사항
PROXY	Config의 프록시 정책으로 처리	프록시 경로로 접속해야 하는 도메인 또는 FINAL 폴백	현재 선택한 정책이 작동하며 Global Routing이 Config인지 확인
DIRECT	현재 네트워크에서 대상에 직접 연결	LAN 주소, 명확한 직접 연결 도메인 또는 GEOIP 분류	로컬 네트워크 자체에서 대상에 접근할 수 있는지 확인
REJECT	매칭된 요청을 즉시 거부	차단해야 하는 도메인 또는 주소 범위	너무 넓은 접미사를 REJECT로 잘못 지정하지 않기

PROXY가 모든 요청의 성공을 보장하는 것은 아닙니다. 현재 선택한 프록시 정책으로 요청을 전달할 뿐이며, 최종 결과는 사용자가 보유한 Config, 해당 프로토콜 매개변수와 네트워크 상태에 따라 달라집니다. Shadowrocket의 Config에는 Shadowsocks, VMess, VLESS, Trojan, Hysteria2, WireGuard 등의 프로토콜이 포함될 수 있지만, 규칙 순서와 특정 프로토콜은 서로 독립적입니다. 프로토콜을 변경해도 [Rule]의 위에서 아래로 매칭되는 방식은 바뀌지 않습니다.

DIRECT는 ‘Shadowrocket을 무시한다’는 뜻도 아닙니다. 요청은 먼저 규칙 판단을 거치고, 매칭된 뒤 직접 연결로 나갑니다. 따라서 LAN 장치에 접근할 수 없을 때는 사설 주소 규칙이 FINAL보다 앞에 있는지 확인하고, Global Routing이 Proxy에 머물러 있지 않은지도 확인해야 합니다.

REJECT는 범위가 명확한 대상에만 사용해야 합니다. DOMAIN-SUFFIX,example.com,REJECT를 앞에 작성하면 해당 주 도메인과 모든 하위 도메인이 거부됩니다. 뒤에 DOMAIN,api.example.com,DIRECT가 있어도 적용되지 않습니다. 올바른 방법은 허용할 예외를 먼저 작성한 다음 범위가 더 넓은 거부 규칙을 작성하는 것입니다.

허용 예외

첫 번째 줄: DOMAIN,api.example.com,DIRECT
두 번째 줄: DOMAIN-SUFFIX,example.com,REJECT
결과: API는 직접 연결하고 나머지 접미사는 거부

정확한 DOMAIN이 먼저 매칭되어 뒤의 접미사 규칙보다 우선합니다.

라우팅 상태

Config: 규칙 목록에 따라 분기
Proxy: 전역 프록시 상태 사용
Direct: 전역 직접 연결 상태 사용
Scene: 설정된 Scene에 따라 상태 선택

사용자 규칙을 점검할 때는 먼저 Home에서 Global Routing을 확인합니다.

FINAL을 반드시 규칙 마지막에 두는 이유

FINAL은 매칭되지 않은 요청의 통합 출구입니다. 도메인, IP 또는 주소 범위를 제한하지 않으므로 중간에 배치하면 앞에서 매칭되지 않은 모든 요청을 가로채고 이후 규칙은 실행 기회를 잃습니다. Config에서 다른 줄을 계속 작성할 수 있더라도 FINAL 뒤에 있는 줄은 이미 완료된 첫 번째 매칭 결과를 바꿀 수 없습니다.

# 권장 순서
DOMAIN,internal.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
GEOIP,CN,DIRECT
FINAL,PROXY

# 잘못된 순서
FINAL,PROXY
DOMAIN,internal.example.com,DIRECT

첫 번째 순서는 정확한 도메인, 접미사와 GEOIP를 먼저 검사하고 마지막에 PROXY로 남은 요청을 처리합니다. 두 번째 순서는 첫 줄에서 이미 모든 요청이 FINAL에 매칭되므로 두 번째 줄이 적용될 기회가 없습니다. ‘새 규칙이 전혀 반응하지 않는’ 경우에는 먼저 해당 규칙이 FINAL 뒤에 작성되었는지 확인하세요.

FINAL의 정책은 특정 값으로 기계적으로 고정하지 말고 Config의 목적에 따라 정해야 합니다. ‘직접 연결 예외만 나열하고 나머지는 프록시로 보내는’ 구조라면 FINAL,PROXY를 사용할 수 있습니다. ‘프록시가 필요한 대상만 나열하고 나머지는 직접 연결하는’ 구조라면 FINAL,DIRECT를 사용할 수 있습니다. 두 구조 모두 가능하지만 앞의 규칙이 폴백 방향과 일치해야 합니다.

결론: 기본 동작을 먼저 정한 뒤 예외 규칙 작성

매칭되지 않은 요청에 최종적으로 PROXY와 DIRECT 중 어느 것을 적용할지 먼저 정한 다음, 기본 동작과 반대되는 예외를 FINAL 앞에 배치합니다. 이렇게 하면 중복 규칙을 계속 추가하는 것보다 확인하기 쉽고, 같은 도메인에 서로 충돌하는 처리 방식이 생기는 것도 막을 수 있습니다.

수정 후 정해진 단계로 확인

Config에서 현재 사용하는 Config를 열고, 다른 동명의 Config나 예비 Config가 아니라 실제 활성 Config를 수정했는지 확인합니다.
[Rule]에 최종 폴백을 담당하는 FINAL이 하나만 있는지 확인하고, 규칙 목록의 마지막에 있는지 확인합니다.
Home으로 돌아가 Global Routing을 Config로 설정합니다. Proxy 또는 Direct 상태에서는 사용자 규칙의 예상 분기 결과를 Config 상태로 검증할 수 없습니다.
DIRECT에 매칭되어야 하는 대상과 PROXY에 매칭되어야 하는 대상을 각각 테스트합니다. 모든 규칙을 하나의 웹사이트만으로 판단하지 마세요.
결과가 예상과 다르면 새로 추가한 줄만 확인하지 말고, 규칙 상단부터 매칭될 가능성이 있는 첫 번째 DOMAIN, DOMAIN-SUFFIX, IP-CIDR 또는 GEOIP를 찾습니다.

Config 업데이트, On Demand와 규칙이 적용되지 않는 일반적인 원인

사용자가 자체 서비스 제공업체와 구독을 이용하는 경우 Config 업데이트로 원격에서 제공된 규칙 내용이 다시 기록될 수 있습니다. 업데이트로 덮어써지는 Config에 사용자 규칙을 직접 수정했다면 새로고침 후 원격 내용으로 돌아갈 수 있습니다. 수정하기 전에 현재 Config이 수동 관리되는지 구독에 따라 업데이트되는지 구분하고, 업데이트 후 [Rule] 순서와 FINAL 위치를 다시 확인해야 합니다.

On Demand와 규칙 우선순위는 서로 다른 단계를 처리합니다. 진입 경로는 Settings → On Demand이며, 설정된 네트워크 조건에 따라 언제 연결을 만들지 결정합니다. 연결이 만들어진 뒤 요청의 분기는 Global Routing과 현재 Config 규칙에 따라 결정됩니다. On Demand가 연결을 만들지 못한 경우 [Rule]만 조정해서는 연결 조건을 대신 확인할 수 없습니다.

규칙 실행

진입 경로 확인: Home → Global Routing
테스트 상태: Config
Config 위치: 현재 Config의 [Rule]
끝점: FINAL은 마지막 줄에 배치

먼저 활성 대상을 확인한 다음 규칙 텍스트가 올바른지 판단합니다.

자동 연결

진입 경로: Settings → On Demand
기능: 네트워크 조건에 따라 연결 제어
규칙과의 관계: [Rule]의 순서를 변경하지 않음
점검: 연결과 분기를 각각 확인

연결 시점과 요청 정책은 두 단계로 나누어 확인해야 합니다.

또 다른 일반적인 원인은 규칙 내용에 URL이 포함된 경우입니다. DOMAIN과 DOMAIN-SUFFIX는 도메인 부분만 허용합니다. 프로토콜, 포트 또는 경로까지 함께 작성하면 매칭 대상이 올바르지 않게 됩니다. 예를 들어 https://api.example.com:443/v1/status에 접속할 때 호스트를 매칭하려면 DOMAIN 값은 api.example.com으로 작성해야 하며, 포트 443과 경로 /v1/status는 해당 도메인 규칙의 값에 포함되지 않습니다.

규칙 이름과 정책 이름도 영어 원문을 사용하고 필드는 영문 쉼표로 구분해야 합니다. 전각 쉼표, 필드 누락, 불필요한 공백으로 인한 보이지 않는 차이 때문에 한 줄의 Config가 예상대로 해석되지 않을 수 있습니다. 규칙을 복사한 뒤에는 먼저 세 부분 구조를 유지하고 키워드, 매칭 값과 정책을 하나씩 확인하세요.

DOMAIN을 추가했는데도 왜 PROXY로 연결되나요?

위에 이미 매칭될 수 있는 DOMAIN-SUFFIX가 있는지 먼저 확인하고, 해당 규칙이 FINAL 뒤에 작성되지 않았는지도 확인하세요. 예외로 사용할 정확한 DOMAIN은 포괄적인 접미사 규칙보다 앞으로 옮긴 뒤 Home에서 Global Routing을 Config로 설정하고 다시 테스트해야 합니다.

DIRECT를 작성했는데도 LAN 장치가 열리지 않나요?

대상의 실제 IP가 작성한 IP-CIDR 범위에 포함되는지 확인하세요. 예를 들어 192.168.1.20은 192.168.0.0/16에 매칭되지만 192.168.2.0/24에는 매칭되지 않습니다. 그런 다음 로컬 Wi-Fi 자체에서 해당 장치에 접근할 수 있는지 확인하세요.

구독 업데이트 후 사용자 규칙이 사라졌나요?

업데이트 과정에서 현재 Config의 내용이 다시 기록될 수 있습니다. 먼저 Config에서 현재 활성 Config와 출처를 확인한 다음 [Rule]이 업데이트된 내용으로 돌아갔는지 확인하세요. 장기간 유지해야 하는 수정은 해당 Config의 관리 방식에 맞는 규칙 관리 방법을 사용해야 합니다.

On Demand를 켜면 FINAL이 바뀌나요?

아니요. On Demand는 Settings → On Demand에 있으며 연결 시점을 담당합니다. FINAL은 여전히 [Rule]의 마지막 폴백입니다. 먼저 연결이 수립되었는지 확인한 다음 요청이 Config 상태에서 규칙에 매칭되는지 확인해야 합니다.

REJECT가 너무 넓게 작성되었는지 빠르게 확인하는 방법은 무엇인가요?

REJECT 앞의 매칭 키워드를 확인하세요. DOMAIN은 하나의 완전한 도메인에만 영향을 주고 DOMAIN-SUFFIX는 주 도메인과 모든 하위 도메인에 영향을 줍니다. 단일 호스트만 거부해야 한다면 정확한 DOMAIN을 사용하고, 포괄적인 REJECT가 필요한 예외보다 앞에 오지 않도록 하세요.

저장 전 규칙 점검 목록

관리하기 쉬운 Config는 일반적으로 계층이 명확합니다. LAN과 정확한 예외를 앞에 두고, 도메인 접미사와 주소 대역을 중간에 배치하며, GEOIP를 뒤에 두고 FINAL로 마무리합니다. 같은 대상에 충돌하는 정책을 여러 위치에 반복해서 작성해서는 안 됩니다. 예외가 필요하다면 ‘구체적인 규칙을 앞에, 일반적인 규칙을 뒤에’ 배치해 표현해야 하며, 뒤의 규칙이 앞의 규칙을 덮어쓰기를 기대해서는 안 됩니다.

현재 사용 중인 Config를 수정했으며, 다른 비활성 Config가 아님
Home → Global Routing이 Config로 설정되어 있고 테스트 중 Proxy 또는 Direct 상태가 아님
DOMAIN과 DOMAIN-SUFFIX 값에 프로토콜, 포트, 경로와 쿼리 매개변수가 없음
규칙 필드는 영문 쉼표로 구분하고 키워드와 정책은 영어 원문을 유지함
정확한 DOMAIN이 이를 덮어쓸 수 있는 DOMAIN-SUFFIX보다 앞에 있음
IP-CIDR의 접두사 길이를 명확히 하여 /16과 /24의 적용 범위를 혼동하지 않음
GEOIP가 우선 처리해야 하는 도메인과 주소 규칙 뒤에 있음
FINAL은 폴백만 담당하며 [Rule]의 마지막에 있음
구독 업데이트 후 사용자 지정 내용이 여전히 남아 있는지 다시 확인함
Settings → On Demand는 연결 시점만 제어하며 Global Routing과 규칙 확인을 대신하지 않음

점검을 마친 뒤에는 서로 반대되는 방향의 샘플을 최소 두 개 사용해 확인해야 합니다. 하나는 DIRECT, 다른 하나는 PROXY가 예상되는 대상으로 테스트하고, Config에 REJECT가 있다면 명확히 거부되어야 하는 대상도 추가합니다. 각 샘플을 규칙 상단부터 따라가며 첫 매칭 항목을 확인하는 것이 연결 스위치나 한 번의 로딩 속도만 관찰하는 것보다 문제를 찾는 데 효과적입니다.

Shadowrocket은 Apple 플랫폼의 폐쇄형 상용 앱입니다. iPhone과 iPad가 주요 사용 기기이며, Mac, Apple TV와 Apple Vision의 호환성 및 시스템 요구 사항은 App Store 페이지의 표기를 기준으로 합니다. 유일한获取入口은 App Store이고 개발자는 Shadow Launch Technology Limited로 표시되며 앱 ID는 932747118입니다. 구매 방식은 일회성 구매입니다. 앱 구매와 회선 서비스는 별개의 사항이며, Config과 구독은 사용자가 직접 준비하고 관리해야 합니다.