Shadowrocket 사용자 규칙 우선순위: 위에서부터 매칭되는 순서, FINAL 기본 처리와 PROXY/DIRECT/REJECT

이 글의 핵심

이 글은 Shadowrocket에서 연결을 설정하고 트래픽 분배 방식을 조정하려는 사용자를 위한 안내입니다. 먼저 Global Routing이 Config로 설정되어 있는지 확인한 다음, 규칙은 처음 일치하는 항목의 정책을 적용한다는 점을 살펴봅니다. 구체적인 도메인 예외, IP 대역, FINAL을 조합해 확인하기 쉬운 규칙 목록을 구성하는 방법도 소개합니다. 예시는 설명용 주소만 사용하며 연결 서비스는 제공하지 않습니다. 구독 링크는 이용 중인 서비스 제공업체에서 받으세요.

1. 사용자 규칙 우선순위: 먼저 일치하는 규칙이 적용됩니다

Config에 따라 트래픽을 분배하는 경우 [Rule]의 규칙을 위에서부터 차례로 확인합니다. 조건에 맞는 규칙을 찾으면 해당 규칙에 지정된 정책을 요청에 적용하고, 더 구체적이거나 뒤에 있는 규칙을 계속 찾지 않습니다. 따라서 규칙 우선순위는 도메인 길이나 규칙 유형에 따라 자동으로 정해지는 것이 아니라 목록에서의 위치에 따라 결정됩니다.

요청이 터널에 들어갑니다 현재 Config를 읽습니다 규칙을 순서대로 확인합니다 일치한 정책을 적용합니다 아웃바운드 연결을 설정합니다

예를 들어 DOMAIN-SUFFIX,example.com,PROXY는 example.com과 그 하위 도메인에 매칭됩니다. 이 중 files.example.com만 직접 연결하려면 DOMAIN,files.example.com,DIRECT를 접미사 규칙보다 앞에 두어야 합니다. 반대로 배치하면 접미사 규칙이 하위 도메인에도 먼저 적용되어, 뒤에 있는 예외 규칙은 해당 요청의 처리에 참여하지 못합니다.

범위가 좁은 예외를 먼저: 단일 도메인, 특정 대상 IP, 명확히 차단해야 하는 대상은 이를 포함하는 더 넓은 규칙보다 앞에 둡니다.
범위가 넓은 분류 규칙은 뒤에: 도메인 접미사, IP 대역, 지역 분류 등은 나머지 요청을 처리하는 데 사용합니다. 단, 이 규칙들 사이의 우선순위도 실제 목록 위치에 따라 결정됩니다.
FINAL은 맨 마지막에: 앞선 규칙과 일치하지 않은 요청을 처리합니다. FINAL 뒤에는 적용되기를 기대하는 일반 규칙을 두지 마세요.

2. Global Routing과 PROXY, DIRECT, REJECT의 차이

먼저 Home → Global Routing에서 현재 라우팅 모드를 확인하세요. 현재 Config의 규칙을 검증하려면 Config를 선택해야 합니다. Proxy와 Direct는 전역 라우팅 선택 항목이므로 사용자 규칙이 매칭되었는지 확인하는 기준으로 사용할 수 없습니다. Scene을 사용한다면 해당 장면에 실제로 적용된 설정도 확인해야 합니다. Config 편집기의 규칙만으로 현재 결과를 단정하지 마세요.

3가지

이 글에서 다루는 규칙 정책: PROXY / DIRECT / REJECT

4개

Global Routing：Proxy / Direct / Config / Scene

1개

예시 규칙의 맨 끝에는 FINAL을 하나만 둡니다

규칙 정책	매칭 후 처리	확인할 점
`PROXY`	해당 요청을 프록시를 통해 아웃바운드로 처리합니다.	현재 선택된 프록시를 확인하세요. Config에서 정책 그룹을 사용한다면 그룹 안에서 실제로 선택된 아웃바운드도 확인해야 합니다.
`DIRECT`	현재 네트워크를 통해 대상에 직접 연결합니다.	직접 연결도 로컬 네트워크, 대상에 대한 연결 가능 여부, DNS 결과에 좌우됩니다. 연결 성공을 보장하는 것은 아닙니다.
`REJECT`	매칭된 요청을 거부합니다.	대상과 관련된 기능이 로드되지 않을 수 있습니다. 차단 범위를 넓히기 전에 어떤 요청이 매칭되는지 확인하세요.

확인 순서: 라우팅 모드를 먼저 확인한 다음 규칙을 점검합니다

규칙을 바꿨는데도 효과가 없다면 먼저 Home에서 Global Routing이 Config인지 확인한 다음, Config에서 방금 편집한 파일이 선택되어 있는지 확인하세요. 규칙 순서를 판단하려고 프록시를 반복해서 바꾸지는 마세요.

PROXY는 규칙에 사용하는 정책 식별자이고, Proxy는 Global Routing의 화면 옵션입니다. 둘은 서로 다른 단계에 있습니다. 규칙은 어떤 요청에 특정 아웃바운드를 사용할지 결정하고, Shadowsocks, VMess, VLESS, Trojan, Hysteria2, WireGuard 등의 프로토콜은 해당 연결을 설정하는 방식을 결정합니다. 규칙 순서를 바꿔도 프로토콜 설정의 포트, 키 또는 인증 오류는 해결되지 않습니다.

3. DOMAIN-SUFFIX, GEOIP, IP-CIDR와 FINAL 작성법

일반적인 규칙은 ‘규칙 유형, 매칭할 내용, 정책’ 순으로 작성합니다. FINAL에는 매칭할 내용이 필요하지 않아 규칙 키워드와 정책만 사용합니다. 아래 표는 문법을 이해하기 위한 자료입니다. example.com과 192.0.2.0/24는 문서용 예시이며 실제 서비스 주소가 아닙니다.

규칙 예시	매칭 기준	순서 관련 참고 사항
`DOMAIN,files.example.com,DIRECT`	이 도메인 전체와 매칭됩니다.	이를 포함하는 DOMAIN-SUFFIX 규칙보다 앞에 둡니다.
`DOMAIN-SUFFIX,example.com,PROXY`	해당 도메인과 하위 도메인에 매칭됩니다. 임의의 문자열 포함 여부를 확인하는 규칙은 아닙니다.	앞에 있는 단일 도메인 예외를 제외한 나머지 하위 도메인에 적용할 수 있습니다.
`IP-CIDR,192.0.2.0/24,DIRECT,no-resolve`	예시 IPv4 대역에 매칭됩니다. no-resolve는 이 IP 규칙만을 위해 도메인을 별도로 조회하지 않도록 합니다.	Config 전체의 DNS를 끄는 옵션이 아니며, 이미 확인된 대상 IP의 매칭 조건도 바꾸지 않습니다.
`GEOIP,CN,DIRECT`	대상 IP의 지역 데이터베이스 분류를 기준으로 매칭합니다.	도메인 접미사를 기준으로 판단하지 않습니다. 결과는 대상 IP와 데이터베이스에 따라 달라집니다.
`FINAL,PROXY`	앞선 규칙과 일치하지 않은 요청을 PROXY로 보냅니다.	규칙 목록의 맨 마지막에 둡니다.

도메인 규칙이 매칭되려면 해당 연결에서 사용할 수 있는 대상 도메인 정보도 있어야 합니다. IP 주소로 직접 요청하는 경우 특정 DOMAIN-SUFFIX 규칙에 자동으로 매칭될 것이라고 기대해서는 안 됩니다. 또한 웹페이지 하나가 메인 도메인, 이미지, 인증 API, 콘텐츠 전송 도메인에 각각 요청을 보낼 수 있습니다. 메인 도메인이 직접 연결로 매칭되더라도 페이지의 모든 연결에 같은 정책이 적용된다는 뜻은 아닙니다.

4. 규칙 순서 조정 예시: 하위 도메인 예외와 FINAL 기본 처리

다음과 같은 상황을 가정해 보겠습니다. files.example.com은 직접 연결하고, ads.example.com은 거부하며, 나머지 example.com 도메인은 프록시로 보냅니다. 아래 설정 카드 두 개는 규칙 내용은 같고 순서만 다릅니다. 예외 규칙을 작성했다고 해서 반드시 적용되는 것은 아니라는 점을 확인할 수 있습니다.

조정 전: 넓은 범위 규칙이 먼저

규칙 1: DOMAIN-SUFFIX,example.com,PROXY
규칙 2: DOMAIN,files.example.com,DIRECT
규칙 3: DOMAIN,ads.example.com,REJECT
규칙 4: FINAL,PROXY

두 하위 도메인 모두 먼저 1번 규칙에 매칭되므로 뒤에 있는 예외 규칙이 의도대로 적용되지 않습니다.

조정 후: 구체적인 예외가 먼저

규칙 1: DOMAIN,files.example.com,DIRECT
규칙 2: DOMAIN,ads.example.com,REJECT
규칙 3: DOMAIN-SUFFIX,example.com,PROXY
규칙 4: FINAL,PROXY

단일 도메인 예외를 먼저 처리하고, 전체 도메인 범위를 처리한 다음, 나머지 요청을 처리합니다.

IP 대역과 지역에 따라 트래픽을 분배해야 한다면 아래처럼 규칙을 구성할 수 있습니다. 여기서 GEOIP,CN,DIRECT는 지역 규칙의 배치 방법을 보여주는 예시일 뿐, 모든 사용자에게 적합한 설정이라는 뜻은 아닙니다. 실제 정책은 현재 네트워크와 접속 요구사항에 맞춰 정하세요.

[Rule]
DOMAIN,files.example.com,DIRECT
DOMAIN,ads.example.com,REJECT
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

이 예시에서는 example.com 범위의 도메인을 먼저 도메인 규칙으로 처리하므로, GEOIP 데이터베이스에서 IP가 CN으로 분류되더라도 DIRECT로 바뀌지 않습니다. 위 도메인 규칙과 일치하지 않은 나머지 요청에 대해서만 뒤에 있는 IP 규칙이 처리에 참여합니다. 규칙이 더 구체적으로 보이는지보다 목록에서의 위치가 중요한 이유입니다.

규칙 조정 원칙: 서비스별 예외를 먼저, 분류 규칙은 나중에

직접 연결하거나 반드시 거부해야 하는 구체적인 대상은 이를 포함하는 규칙보다 앞에 배치하세요. 관련 규칙은 한 번에 한 묶음씩만 이동하고 맨 끝의 FINAL은 유지하세요. 그러면 각 변경으로 동작이 달라진 이유를 파악하기 쉽습니다.

5. Config 편집부터 새 연결 확인까지의 순서

규칙을 확인할 때는 ‘편집 완료’, ‘현재 Config 선택’, ‘새 요청에 새 설정 적용’의 세 단계를 구분해야 합니다. 브라우저나 앱이 기존 연결을 재사용할 수 있으므로 페이지를 새로고침하는 것만으로 새 아웃바운드 연결이 생기는 것은 아닙니다. 테스트할 때는 규칙 판단은 올바르지만 연결에 실패한 경우와 요청이 대상 규칙에 아예 매칭되지 않은 경우도 구별해야 합니다.

기존 Config를 보관하세요. Config를 편집하기 전에 복구할 수 있는 사본을 저장하고 현재 선택된 파일을 기록해 두세요. 예시 전체를 기존 Config의 다른 부분까지 포함해 통째로 교체하지 마세요.
[Rule]을 확인하세요. 조정하려는 규칙을 찾아 같은 도메인, 상위 접미사, IP 대역 규칙 또는 앞에 배치된 FINAL이 있는지 확인하세요. 맨 끝의 기본 처리 규칙은 명확하게 하나만 둡니다.
저장한 뒤 파일을 선택하세요. 편집이 끝나면 저장되었는지 확인하고, Config에서 실제로 선택된 파일이 방금 편집한 파일인지 확인하세요. 이름이 비슷한 다른 파일이 선택되어 있지 않은지 살펴보세요.
라우팅 모드를 확인하세요. Home → Global Routing → Config으로 이동하세요. 테스트 중에는 현재 프록시 선택을 그대로 유지해 아웃바운드와 규칙을 동시에 바꾸면서 생기는 혼선을 피하세요.
연결을 다시 설정하세요. 중요한 작업이 중단되지 않는 상황에서 연결을 끊었다가 다시 켜고 대상 요청을 새로 보내세요. 필요하다면 대상 앱을 완전히 종료한 뒤 다시 열어 기존 연결이 재사용될 가능성을 줄이세요.
새 요청 기록을 확인하세요. 연결 기록이나 로그에서 대상 도메인, 대상 IP, 적용된 정책을 확인하세요. 매칭된 규칙 정보가 기록에 표시된다면 함께 확인합니다. 웹페이지가 열리는지만 보고 규칙이 제대로 적용되었다고 판단하지 마세요.

이 글의 예시 도메인은 실제 테스트 서비스를 제공하지 않습니다. 검증할 때는 자신에게 접근 권한이 있고 요청 대상을 확인할 수 있는 주소를 사용하고 테스트 조건을 기록하세요. 예를 들어 페이지의 글자는 보이는데 이미지가 계속 로드되지 않는다면, 메인 도메인의 정책을 바로 바꾸기보다 이미지 요청에 실제 사용된 도메인을 확인하세요.

6. FINAL 및 사용자 규칙 관련 자주 묻는 질문

FINAL을 첫 줄에 두면 아래 규칙이 왜 적용되지 않나요?

FINAL은 해당 위치까지 도달한 모든 미매칭 요청을 처리합니다. FINAL을 [Rule] 맨 끝으로 옮긴 다음 앞쪽의 구체적인 규칙을 확인하세요. FINAL 뒤에 적용을 기대하는 도메인 예외를 추가하지 마세요. 첫 번째 FINAL을 덮어쓰려고 두 번째 FINAL을 추가해서도 안 됩니다.

DIRECT를 설정했는데 웹사이트가 왜 열리지 않나요?

먼저 새 요청 기록에서 실제로 DIRECT가 적용되었는지 확인하세요. DIRECT가 적용됐다면 규칙에 따른 직접 연결 결정은 완료된 것입니다. 이어서 현재 네트워크에서 대상에 접속할 수 있는지, DNS가 적절한 주소를 반환하는지, 대상 서비스가 응답하는지 확인하세요. DIRECT는 연결 경로만 지정하며 네트워크나 서버 측 문제를 해결하지는 않습니다.

FINAL,DIRECT로 바꾸면 기존 규칙이 전부 영향을 받나요?

앞에서 이미 매칭된 규칙은 바뀌지 않지만, 나머지 모든 요청의 기본 아웃바운드는 달라집니다. 수정하기 전에 현재 기본 처리에 의존하는 요청이 무엇인지 확인하세요. 특정 도메인 하나만 직접 연결하려면 기본 처리 범위를 넓히지 말고 DOMAIN 또는 DOMAIN-SUFFIX 예외를 앞쪽에 추가하세요.

구독을 업데이트하면 사용자 규칙이 덮어써지나요?

먼저 Home에서 업데이트하는 연결 구독과 Config에서 업데이트하는 원격 Config를 구분하세요. 둘은 같은 항목이 아닙니다. 원격 Config를 업데이트하면 해당 Config의 내용이 교체될 수 있습니다. 업데이트 전에 사본을 보관하고, 업데이트 후에는 현재 선택된 파일과 [Rule]을 확인하세요. 로컬 수정 사항이 반드시 유지된다고 가정하지 마세요. 구독 링크는 이용 중인 서비스 제공업체에서 받으세요.

REJECT 후 페이지의 일부 버튼이 작동하지 않으면 어떻게 확인하나요?

버튼을 클릭했을 때 새로 추가된 요청을 확인하고 인증, API 또는 리소스 도메인이 거부되었는지 살펴보세요. 의심되는 규칙을 잠시 비활성화하고 다시 테스트하세요. 관련 요청을 확인한 뒤에는 REJECT 범위를 줄이거나 해당 규칙 앞에 명확한 예외를 추가하세요. 모든 요청을 무조건 허용하지 마세요.