Shadowrocket 규칙 우선순위 설정: 위에서 아래로 매칭하고 FINAL로 마무리

이 글 미리보기

Shadowrocket 규칙 우선순위는 규칙의 위치로 결정되며, 도메인 길이나 정책 이름으로 정해지지 않습니다. 자체 서버와 구독을 보유하고 트래픽 분기를 조정하려는 사용자를 위한 안내입니다. 먼저 Home에서 Global Routing을 확인하고, Config에서 현재 설정을 점검하세요. 구체적인 예외는 포괄적인 규칙보다 앞에 두고, 새 연결을 만들어 FINAL이 올바르게 처리하는지 확인합니다.

먼저 Global Routing이 Config인지 확인

규칙을 수정하기 전에 연결 여부와 트래픽 분기 방식을 구분하세요. Home의 연결 스위치는 연결을 활성화하고, Global Routing은 요청을 처리할 방식을 결정합니다. 설정 파일의 규칙을 확인하려면 먼저 Global Routing을 Config로 설정한 다음 Config에서 현재 사용 중인 설정 파일을 확인하세요. 활성화되지 않은 파일만 수정해도 적용 중인 트래픽 분기에는 변화가 없습니다.

1개

한 번의 규칙 판정에서는 처음 일치한 규칙이 정책을 결정합니다

3가지

이 글에서 다루는 기본 정책: PROXY / DIRECT / REJECT

마지막 규칙

FINAL을 규칙 구간의 맨 끝에 두어 일치하지 않은 요청을 처리합니다

Global Routing의 Proxy는 전체 요청을 프록시로 처리하고, Direct는 전체 요청을 직접 연결한다는 의미입니다. 둘 다 특정 설정 규칙이 일치했음을 보여 주지는 않습니다. Scene은 상황에 따라 해당 설정을 적용하는 기능이므로, 고정된 Config 상태로 간주하지 마세요. 개별 규칙을 점검할 때는 먼저 Config를 선택해 Scene 전환으로 인한 변수를 줄이세요.

결론: 먼저 모드를 고정한 다음 규칙을 수정하세요

규칙을 조정한 뒤에도 접속 경로가 달라지지 않는다면 규칙을 더 추가하기 전에 Home에서 Global Routing을 확인하고, Config에서 실제 적용 중인 파일을 점검하세요.

위에서 아래로 매칭되며, 더 구체적인 규칙이 자동으로 우선하지 않습니다

규칙 구간은 순서가 있는 조건 목록으로 이해할 수 있습니다. 요청이 트래픽 분기 과정에 들어오면 프로그램이 규칙을 차례로 확인합니다. 조건에 일치하면 해당 규칙의 정책이 적용되고, 뒤에 있는 규칙 중 더 적합해 보이는 항목을 찾지 않습니다. 따라서 구체적인 예외는 보통 일반 규칙보다 앞에 배치해야 하며, 프로그램이 조건의 세밀함을 자동으로 비교한다고 기대해서는 안 됩니다.

요청 입력 대상 확인 순서대로 매칭 정책 결정 아웃바운드 처리

아래 예시는 흔히 발생하는 순서 문제를 보여 줍니다. DOMAIN-SUFFIX,example.com,PROXY는 example.com 자체와 모든 하위 도메인에 적용됩니다. 요청 대상이 api.example.com이면 첫 번째 줄에서 이미 일치하므로, 뒤에 있는 정확한 도메인 규칙은 이번 판정에 적용될 기회가 없습니다.

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

해당 하위 도메인만 직접 연결하고 같은 접미사를 사용하는 나머지 도메인은 프록시로 보내려면 예외 규칙을 앞에 배치해야 합니다. 여기서 사용하는 도메인은 문법 설명용이며, 연결 서비스나 이용 가능 여부 테스트에 쓰이는 주소가 아닙니다.

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

차단 예외도 같은 원칙이 적용됩니다. 특정 하위 도메인만 거부하고 같은 접미사를 사용하는 다른 요청은 프록시로 계속 처리하려면, 정확한 REJECT 규칙을 포괄적인 접미사 규칙보다 앞에 두어야 합니다. REJECT 정책이 더 강해 보인다는 이유만으로 우선순위가 높다고 생각하지 마세요.

DOMAIN-SUFFIX, IP-CIDR, GEOIP의 배치 순서

이 키워드들은 서로 다른 매칭 조건을 나타낼 뿐, 고정된 우선순위 등급을 뜻하지 않습니다. DOMAIN-SUFFIX는 도메인 접미사를 확인하고, IP-CIDR은 대상 IP가 지정된 네트워크 범위에 속하는지 확인합니다. GEOIP는 IP 위치 데이터에 따라 지역 코드를 매칭합니다. 규칙은 구체적인 예외를 먼저 두고, 더 넓은 주소 또는 지역 범위를 뒤에 배치하세요.

도메인 조건

DOMAIN: api.example.com,DIRECT
DOMAIN-SUFFIX: example.com,PROXY
매칭 기준: 요청에 해당하는 도메인 정보

정확한 예외를 먼저, 접미사 전체에 적용되는 규칙은 나중에 둡니다.

주소 조건

IP-CIDR: 192.168.0.0/16,DIRECT,no-resolve
GEOIP: CN,DIRECT
매칭 기준: 대상 IP와 로컬 위치 데이터

특정 네트워크 범위를 포괄적인 지역 규칙보다 먼저 두는 것이 일반적입니다.

IP 규칙이 적용되려면 판정에 사용할 대상 IP가 있어야 합니다. 요청에 처음부터 도메인만 있는 경우, 이름 확인 과정에 따라 IP-CIDR 또는 GEOIP 규칙이 적용될 수 있는지가 달라집니다. 예시의 no-resolve는 이 규칙만을 위해 도메인 확인을 적극적으로 수행하지 말라는 뜻입니다. 앱 전체의 DNS를 끄거나, 모든 도메인 요청이 해당 네트워크 범위에 바로 일치한다는 의미는 아닙니다.

도메인에 명확한 예외가 있는 경우: DOMAIN 또는 DOMAIN-SUFFIX를 먼저 두어 요청이 포괄적인 IP 조건에 도달하기 전에 정책을 결정하세요.
로컬 네트워크 범위를 지정하는 경우: 실제 네트워크에 맞춰 IP-CIDR을 작성하세요. 192.168.0.0/16은 사설 주소 범위 중 하나이며, 모든 로컬 네트워크를 나타내지는 않습니다.
지역별 일반 정책을 설정하는 경우: 특정 예외 뒤에 GEOIP를 배치하세요. 위치 데이터베이스는 IP의 할당 지역을 나타내며, 웹사이트의 언어나 도메인 접미사를 나타내지 않습니다.
어떤 조건에도 일치하지 않는 경우: 앞에 무조건 규칙을 추가하지 말고 규칙 구간 맨 끝의 FINAL로 처리하세요.

GEOIP 결과는 앱이 사용하는 IP 위치 데이터에 따라 달라지며, 웹사이트 운영자의 소재지와 일치한다고 보장할 수 없습니다. CDN을 사용하는 웹사이트는 시간에 따라 서로 다른 주소로 확인될 수도 있습니다. 특정 도메인에 항상 같은 정책을 적용해야 한다면 GEOIP만으로 접속 경로를 추정하기보다 해당 도메인에 별도 규칙을 작성하는 것이 일반적입니다.

PROXY, DIRECT, REJECT는 동작 방식이지 우선순위가 아닙니다

규칙은 보통 키워드, 매칭 값, 정책으로 구성됩니다. 예를 들어 DOMAIN-SUFFIX,example.com,PROXY에서 앞의 두 부분은 “무엇을 매칭할지”, 마지막 부분은 “일치하면 어떻게 처리할지”를 나타냅니다. FINAL은 도메인이나 네트워크 범위를 지정할 필요가 없는 특수한 기본 처리 규칙이므로 FINAL,PROXY로 작성합니다.

정책	일치한 후 처리 방식	점검할 항목
`PROXY`	현재 설정에 지정된 프록시 경로를 통해 처리	선택한 서버 또는 정책 그룹과 서비스의 작동 여부를 확인하세요
`DIRECT`	프록시 서버를 거치지 않고 대상에 직접 연결	현재 네트워크에서 대상에 직접 연결할 수 있는지 확인하세요
`REJECT`	일치한 요청을 거부	로그인, 이미지 또는 API 도메인이 잘못 차단되지 않았는지 확인하세요

PROXY 규칙에 일치했다는 것은 프록시 처리가 선택되었다는 뜻일 뿐, 대상에 반드시 연결할 수 있다는 뜻은 아닙니다. 서버가 작동하지 않거나 대상 서비스에 문제가 있거나 이름 확인에 실패하면 접속이 되지 않을 수 있습니다. DIRECT에 일치해도 모든 규칙 확인을 우회한다는 의미는 아닙니다. 규칙 판정이 끝난 뒤 직접 연결 동작을 선택한다는 뜻입니다.

설정에서 사용자 지정 정책 그룹 이름을 사용하는 경우, 규칙 끝의 이름이 기존 그룹 이름과 정확히 일치해야 합니다. 임의의 설명 문구를 정책 이름으로 입력하거나 규칙에 PROXY라고 적혀 있다는 이유만으로 현재 연결 경로가 올바르다고 판단하지 마세요. Home에서 선택한 항목과 설정에 등록된 관련 정책 그룹의 실제 상태도 확인해야 합니다.

FINAL을 마지막에 두는 이유와 PROXY 또는 DIRECT 선택 방법

FINAL은 특정 도메인, 네트워크 범위, 지역을 지정하지 않고 해당 위치까지 도달한 나머지 요청을 처리합니다. 규칙 구간 앞쪽에 두면 뒤에 있는 규칙이 매칭될 기회를 잃습니다. 따라서 설정을 관리할 때는 규칙 끝의 기본 처리 규칙을 확인하고, 문제가 생길 때마다 FINAL을 반복해서 추가하지 마세요.

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

이 예시는 규칙 순서를 이해하기 위한 것으로 완전한 설정 파일이 아닙니다. 기존 설정에 필요한 다른 구간을 유지하면서 실제 요구에 맞춰 규칙을 합치세요. 이 몇 줄로 파일 전체를 덮어쓰지 마세요. 예시에서는 첫 번째 하위 도메인을 DIRECT로, 두 번째 하위 도메인을 REJECT로 처리하고, 같은 접미사의 다른 도메인은 PROXY를 사용합니다. 나머지 요청은 주소, 지역, 최종 기본 처리 순서로 판정합니다.

FINAL,PROXY 선택: 특정 예외에 일치하지 않는 요청도 프록시로 처리합니다. 분류되지 않은 요청을 모두 프록시 경로로 보내려는 설정에 적합합니다.
FINAL,DIRECT 선택: 앞에서 프록시로 명시한 요청만 프록시를 사용하고 나머지는 직접 연결합니다. 규칙에 포함되지 않은 대상은 직접 연결에 실패할 수 있다는 점을 고려해야 합니다.
변경 전에 백업: 현재 정상적으로 작동하는 설정을 보관하고 기존 FINAL 정책을 기록하세요. 영향을 받는 범위가 넓어지면 예외를 계속 추가하기보다 원본 파일로 복원할 수 있습니다.

결론: 분류되지 않은 요청의 경로부터 정하세요

FINAL을 확인할 때는 “알려진 규칙에 하나도 일치하지 않는 대상은 어디로 보내야 할까?”를 먼저 결정한 다음 PROXY 또는 DIRECT를 선택하세요. 기본 처리 규칙이 모든 연결 문제를 해결하는 스위치라고 생각해서는 안 됩니다.

수정 후 캐시된 결과와 구분해 확인하는 방법

규칙 수정은 저장, 적용 여부 확인, 새 연결 생성, 기록 점검까지 한 과정으로 진행해야 합니다. 브라우저나 앱은 이미 만들어진 연결을 재사용할 수 있으므로, 페이지로 돌아가는 것만으로 같은 규칙 판정이 다시 이뤄지지는 않을 수 있습니다. 테스트할 때는 기존 연결의 유지와 새 요청의 결과를 구분하세요.

현재 파일 백업: Config에서 사용 중인 설정을 확인하고 수정 전 사본을 보관하세요. 이번에 조정할 대상 도메인이나 네트워크 범위도 기록합니다.
한 번에 한 항목만 변경: 예를 들어 DOMAIN 예외를 DOMAIN-SUFFIX 앞에 옮기는 것만 먼저 진행하고, DNS, 서버, FINAL은 동시에 변경하지 마세요.
저장 후 적용 여부 확인: 편집을 마친 뒤 현재 설정이 대상 파일인지 확인하세요. Home으로 돌아가 Global Routing이 Config이고 연결 상태가 정상인지 점검합니다.
새 연결 시작: 대상 페이지나 관련 앱의 기존 연결을 종료한 뒤 다시 시도하세요. 필요한 경우 잠시 연결이 끊겨도 괜찮은 상황에서 다시 연결한 다음 대상에 접속합니다.
연결 기록 확인: Data에서 확인 가능한 연결 기록이나 로그를 살펴보고 대상 도메인, 대상 IP, 정책을 점검하세요. 기록에 규칙 정보가 제공되는 경우 구체적으로 어떤 규칙에 일치했는지도 확인합니다.

예를 들어 api.example.com이 DIRECT에 일치해야 하는데 기록에는 같은 접미사 규칙에 따라 PROXY를 사용한 것으로 표시된다면, 먼저 규칙 순서와 파일 적용 여부를 확인하세요. 기록에 DIRECT가 표시되는데도 접속할 수 없다면 같은 규칙을 위로 복사하는 대신 직접 연결이 가능한지 점검해야 합니다.

사용자가 보유한 서버 구독 업데이트와 설정 파일 업데이트도 구분해야 합니다. 서버 목록이 바뀌어도 Config의 규칙은 그대로일 수 있습니다. 반면 원격 설정 업데이트는 로컬에서 편집한 내용을 덮어쓸 수 있습니다. 수정 전에 편집 대상이 무엇인지 확인하고, 업데이트 후 규칙 순서와 FINAL을 다시 점검해야 매칭 문제인지 내용이 업데이트로 교체된 것인지 판단할 수 있습니다.

규칙 우선순위 자주 묻는 질문

규칙을 더 구체적으로 작성했는데도 왜 적용되지 않나요?

Shadowrocket은 더 구체적인 규칙을 자동으로 앞으로 옮기지 않습니다. Config에서 실제 규칙 순서를 확인하고 해당 규칙을 덮어쓰는 DOMAIN-SUFFIX보다 DOMAIN 예외를 앞에 배치한 뒤 저장하고 새 연결을 만드세요. 해당 파일이 실제로 사용 중인지, Global Routing이 Config인지도 확인해야 합니다.

FINAL을 PROXY로 바꿨는데도 왜 일부 요청은 직접 연결되나요?

FINAL은 앞에 있는 규칙에 일치하지 않은 요청만 처리합니다. 먼저 해당 대상이 DOMAIN, IP-CIDR, GEOIP 같은 앞쪽 DIRECT 규칙에 이미 일치했는지 확인하세요. 이미 일치한 요청은 FINAL이 정책을 다시 결정하지 않습니다.

GEOIP,CN,DIRECT가 앞에 있는 도메인 프록시 규칙보다 우선 적용되나요?

아니요. 요청이 앞에 있는 DOMAIN-SUFFIX 프록시 규칙에 일치하면 판정은 종료됩니다. 아직 어떤 규칙에도 일치하지 않은 요청만 GEOIP까지 내려갑니다. 결과가 예상과 다르면 요청의 실제 도메인, 현재 사용 중인 파일, 기록에 표시된 매칭 정보를 확인하세요.

REJECT를 추가한 뒤 페이지가 일부만 로드되면 어떻게 복구하나요?

방금 추가한 REJECT 규칙을 먼저 복원하고 페이지를 다시 열어 문제가 해결됐는지 확인하세요. 페이지 하나가 로그인, API, 이미지 등 여러 도메인에 동시에 요청을 보낼 수 있습니다. 잘못 차단한 대상을 확인한 다음 조건 범위를 좁히고, 필요한 경우 명시적으로 허용할 정확한 예외를 포괄적인 거부 규칙보다 앞에 배치하세요.

설정을 업데이트할 때마다 사용자 지정 규칙이 사라지면 어떻게 해야 하나요?

먼저 업데이트된 항목이 서버 구독인지 원격 설정 파일인지 확인하세요. 원격 파일이 로컬 변경 사항을 덮어썼다면 별도로 관리할 설정 사본을 보관하고, 이후 업데이트 전에 유지해야 할 규칙을 비교하세요. 규칙을 반복해서 붙여 넣는 것만으로 해결하려 하지 말고 중복 항목이 실제 순서를 바꾸지 않도록 주의하세요.