Shadowrocket 규칙 설정 방법: 매칭 순서, FINAL 기본 규칙과 PROXY/DIRECT/REJECT 정책

이 글의 핵심

이 글은 Shadowrocket에 본인의 연결 정보를 가져온 뒤 라우팅 규칙을 수정하려는 사용자를 위한 안내입니다. 먼저 Home → Global Routing에서 Config를 선택하고, 현재 적용 중인 Config의 [Rule] 섹션에 예외 규칙, 범위 규칙, FINAL을 배치하는 방법을 살펴봅니다. 연결 기록을 바탕으로 규칙 순서 오류, 정책 선택 오류, 연결 자체의 문제를 구분하는 방법도 확인할 수 있어, Config를 계속 바꿔 가며 시험할 필요가 없습니다.

1. 먼저 Global Routing 확인하기: 규칙이 적용되는 조건

규칙을 추가했다고 해서 연결 처리에 바로 적용되는 것은 아닙니다. Shadowrocket에서 Home은 연결과 전체 라우팅 방식을 관리하고, Config는 구성 파일을 관리하며, Settings는 앱 설정을 조정합니다. 이 글의 사용자 지정 규칙을 확인하려면 먼저 Home → Global Routing에서 Config를 선택하고, Config에서 선택된 파일이 방금 수정한 파일인지 확인하세요.

Config

현재 Config의 규칙에 따라 정책을 선택합니다. 요청에 따라 PROXY, DIRECT 또는 REJECT가 적용될 수 있으므로, Config를 ‘나머지는 모두 직접 연결’하는 방식으로 이해해서는 안 됩니다.

적합한 경우: 일상적인 라우팅, 사용자 지정 규칙 확인

Proxy

프록시를 전체 라우팅 방향으로 사용합니다. 글에 나온 개별 규칙에 따라 라우팅하지는 않습니다. 연결 결과를 비교할 때 잠시 사용할 수 있지만, 특정 DOMAIN-SUFFIX 규칙이 일치하는지 확인하는 용도로는 적합하지 않습니다.

적합한 경우: 프록시 연결이 가능한지 비교 확인

Direct

직접 연결을 전체 라우팅 방향으로 사용합니다. 이 설정에서는 Config에 PROXY 규칙이 있어도 해당 규칙에 따라 라우팅될 것으로 기대할 수 없습니다.

적합한 경우: 직접 연결 결과를 비교 확인

Global Routing의 Scene은 상황별 선택에 사용하며, 개별 규칙의 정책 필드와 혼동해서는 안 됩니다. 문제를 확인할 때는 먼저 Config로 고정하면 Scene 전환으로 생기는 변수를 줄일 수 있습니다. Settings → On Demand는 조건에 따라 연결을 시작할지를 제어합니다. 특정 도메인에 PROXY와 DIRECT 중 어느 정책을 적용할지는 결정하지 않습니다. 자동 연결 시작과 연결 후의 라우팅은 서로 다른 기능입니다.

2. 위에서 아래로 매칭: 범위 규칙보다 먼저 배치할 예외 규칙

규칙 목록은 ‘더 구체적인 규칙이 자동으로 우선하는’ 집합이 아니라, 순서대로 판단하는 목록입니다. Shadowrocket은 위에서 아래로 규칙을 확인하며, 처음 조건에 맞는 규칙의 정책이 적용되고 이후 규칙은 이번 요청의 결과를 보완하거나 덮어쓰지 않습니다. 더 구체적인 규칙을 아래쪽에 추가해도 위쪽 규칙이 먼저 일치한 결과는 바뀌지 않습니다.

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

이 규칙에서는 account.example.com이 먼저 DOMAIN에 일치해 DIRECT가 적용됩니다. media.example.com은 첫 번째 줄에 일치하지 않아 다음 DOMAIN-SUFFIX 규칙에 일치하고 PROXY가 적용됩니다. 앞의 두 규칙 순서를 바꾸면 더 넓은 범위를 다루는 접미사 규칙이 먼저 account 예외를 처리하게 됩니다. example.com은 문법 설명을 위한 예시이며, 사용할 수 있는 프록시 서비스를 뜻하지 않습니다.

1개

처음 일치한 규칙이 이번 요청의 정책을 결정합니다

3가지

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

목록 끝

구체적인 매칭 규칙 뒤에 FINAL 배치

규칙을 정리할 때 ‘차단해야 할 특정 대상, 직접 연결해야 할 특정 예외, 넓은 도메인 범위, IP 주소 범위, 기본 규칙’ 순서로 점검할 수 있지만, 반드시 따라야 하는 고정 템플릿은 아닙니다. 특정 도메인을 우선 직접 연결해야 한다면 해당 도메인을 포함할 수 있는 규칙보다 예외 규칙을 앞에 배치하세요. 중요한 것은 키워드 이름순 정렬이 아니라 규칙 간 적용 범위입니다.

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

도메인 규칙은 요청의 호스트 이름을, IP 주소 규칙은 대상 IP를 기준으로 판단합니다. 같은 서비스를 가리키더라도 매칭 기준은 다를 수 있습니다. 도메인을 IP-CIDR에 입력하거나, 프로토콜·경로·쿼리 매개변수를 포함한 전체 웹 주소를 DOMAIN-SUFFIX에 입력하지 마세요.

키워드	문법 예시	매칭 범위 및 주의 사항
`DOMAIN`	`DOMAIN,account.example.com,DIRECT`	전체 도메인과 일치하며, 다른 하위 도메인은 자동으로 포함하지 않습니다.
`DOMAIN-SUFFIX`	`DOMAIN-SUFFIX,example.com,PROXY`	example.com과 하위 도메인에 일치합니다. 와일드카드 별표는 쓰지 않습니다.
`IP-CIDR`	`IP-CIDR,192.168.0.0/16,DIRECT,no-resolve`	IPv4 주소 범위에 일치합니다. 마스크 길이도 주소 범위의 일부입니다.
`GEOIP`	`GEOIP,CN,DIRECT`	대상 IP의 지리 데이터베이스 분류를 기준으로 합니다. 웹페이지 언어나 도메인 접미사를 기준으로 하지 않습니다.
`FINAL`	`FINAL,PROXY`	매칭 대상을 지정하지 않고, 앞선 규칙에 일치하지 않은 요청을 처리합니다.

192.168.0.0/16은 192.168.0.0부터 192.168.255.255까지의 주소 범위를 의미하며, 단일 기기를 가리키지 않습니다. 특정 IPv4 기기 한 대만 매칭하려면 해당 주소에 /32 규칙을 사용할 수 있습니다. LAN 직접 연결 규칙을 사용하면 조건에 맞는 로컬 대상이 프록시로 전달되는 것을 방지할 수 있지만, 실제 연결 가능 여부는 현재 네트워크, 시스템 권한, 대상 서비스에 따라 달라집니다.

GEOIP 결과는 실제 대상 주소와 데이터베이스 내용에 따라 달라집니다. .com으로 끝나는 도메인이 서로 다른 지역의 주소로 변환될 수 있고, 같은 도메인도 네트워크에 따라 다른 콘텐츠 전송 주소를 사용할 수 있습니다. 특정 도메인에 항상 같은 정책을 적용하려면 GEOIP 결과를 추측해 사용하기보다 조건이 명확한 도메인 규칙을 우선 사용하세요.

4. PROXY, DIRECT, REJECT와 FINAL의 관계

키워드는 ‘무엇을 매칭할지’를, 정책 필드는 ‘매칭 후 어떻게 처리할지’를 정합니다. 예를 들어 DOMAIN-SUFFIX,example.com,PROXY에서 앞의 두 항목은 매칭 범위를 정하고, 마지막 항목은 처리 방식을 정합니다. FINAL은 별도의 기본 매칭 규칙이며, 네 번째 연결 정책이 아닙니다.

PROXY: 프록시 경로로 처리합니다. 사용자가 보유한 유효한 연결 정보와 사용 가능한 프록시 선택 항목이 필요합니다. 규칙 자체가 서비스를 만들어 내지는 않습니다.
DIRECT: 대상에 직접 연결합니다. ‘직접 연결을 우선 시도하고 실패하면 프록시로 자동 전환한다’는 의미가 아닙니다. 연결에 실패해도 다음 규칙을 이어서 확인하지 않습니다.
REJECT: 일치한 요청을 거부합니다. 차단할 대상이 명확한 경우에 사용하세요. 로그인, 인증 또는 리소스 도메인에 잘못 적용하면 페이지 기능이 제대로 작동하지 않을 수 있습니다.
FINAL: 다른 규칙에 일치하지 않은 요청에 정책을 지정합니다. 예를 들면 FINAL,DIRECT 또는 FINAL,PROXY입니다.

FINAL은 도메인이나 주소 조건이 없어 여기까지 도달한 나머지 요청을 처리하므로 규칙 목록의 맨 끝에 배치해야 합니다. 목록 맨 위에 두면 뒤에 있는 구체적인 규칙이 매칭될 기회를 잃습니다. 일반적인 규칙 목록에는 역할이 분명한 FINAL 하나만 두면 충분하며, 여러 FINAL을 쌓아 장애 조치를 구현하려고 하지 마세요.

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

위 예시는 특정 호스트 차단, 로그인 예외 유지, 나머지 example.com 요청을 프록시로 전달, LAN 및 GEOIP 조건 처리, 마지막으로 나머지 요청을 PROXY로 전달하는 교육용 규칙을 보여 줍니다. 모든 네트워크에 적용할 수 있는 범용 Config는 아닙니다. 목록에 없는 대상을 직접 연결하려면 마지막 줄을 FINAL,DIRECT로 바꾸세요. 프록시 규칙에 포함되지 않은 대상도 직접 연결된다는 점을 고려해야 합니다.

5. 현재 Config 수정하기: 백업, 저장, 재확인

시작하기 전에 본인의 서비스와 연결 정보를 준비하고, 선택한 연결을 사용할 수 있는지 확인하세요. 클라이언트 앱 구매는 회선 요금제와 별개입니다. 이 사이트는 노드나 구독을 제공·판매·추천하지 않습니다. 규칙을 수정하면 기존 연결의 선택 방식만 달라질 뿐, 만료된 인증 정보나 연결할 수 없는 서버와 같은 기본 문제는 해결되지 않습니다.

현재 Config 백업하기

Config에 들어가 현재 선택된 구성 파일을 확인한 뒤 복사본을 보관하거나 백업을 내보내세요. 원래의 [Rule] 내용과 FINAL 정책도 기록해 두면 수정에 문제가 생겼을 때 규칙을 처음부터 다시 정리하지 않아도 됩니다.
라우팅 방식 고정하기

Home → Global Routing → Config로 이동합니다. 현재 사용 중인 프록시 선택 항목을 기록하세요. 테스트하는 동안에는 Settings → On Demand를 수정하거나 네트워크를 전환하지 마세요.
규칙 수정하기

Config로 돌아가 현재 구성 파일의 편집 화면을 열고 [Rule]을 찾습니다. 범위 규칙이 덮어쓸 수 있는 예외 규칙은 그 범위 규칙보다 앞에 배치하세요. 기존 섹션을 수정하고 [Rule] 섹션을 중복해서 추가하지 마세요.
저장하고 적용하기

수정 사항을 저장하고 Config에서 해당 파일이 계속 선택되어 있는지 확인하세요. 복사본을 수정했다면 먼저 복사본으로 전환한 다음 Home으로 돌아가 연결 상태를 확인합니다. 적용되지 않은 파일만 수정하는 일이 없도록 주의하세요.
새 요청 시작하기

테스트 연결을 새로 시작해 특정 예외, 범위 규칙, 기본 규칙에 해당하는 대상을 각각 확인하세요. 필요한 경우 작업을 저장한 뒤 연결을 끊었다가 다시 연결해 이전 연결의 재사용이 판단에 미치는 영향을 줄입니다.

구독 가져오기와 Config 관리는 서로 다른 작업입니다. 기존 서버 구독을 업데이트하면 주로 연결 항목이 바뀌고, 원격 Config를 업데이트하면 규칙 내용이 교체될 수 있습니다. 로컬 수정 사항이 사라졌다면 어떤 항목을 업데이트했는지 확인하세요. 사용자 지정 규칙을 오래 유지하려면 관리 가능한 로컬 Config 복사본에 저장하고, 원격 Config를 적용할 때마다 변경된 부분을 다시 확인해야 합니다.

6. 매칭 결과 확인하기: 웹페이지보다 규칙을 먼저 살펴보세요

웹페이지가 열리는지는 한 번의 접속 결과만 보여 줄 뿐, 규칙이 올바른지는 그 자체로 증명하지 않습니다. 보통 페이지 하나가 여러 도메인에 연결되므로, 메인 페이지는 직접 연결되더라도 이미지, 인증 인터페이스, 미디어 리소스에는 다른 정책이 적용될 수 있습니다. 문제를 확인할 때는 페이지 제목이나 로딩 속도만 보지 말고 연결 기록에서 대상 호스트, 일치한 규칙, 최종 정책을 확인하세요.

확인 대상	위 예시에서 예상되는 결과	예상과 다를 때 먼저 확인할 항목
`account.example.com`	DOMAIN에 일치, DIRECT 적용	정확한 도메인 규칙이 DOMAIN-SUFFIX보다 앞에 있는지
`media.example.com`	DOMAIN-SUFFIX에 일치, PROXY 적용	수정한 Config가 선택되어 있는지, 앞에 결과를 덮어쓰는 규칙이 있는지
`192.168.1.20`	LAN IP-CIDR에 일치, DIRECT 적용	주소 범위 마스크, 규칙 순서, 실제 대상 IP
앞선 규칙에 일치하지 않은 대상	FINAL에 일치, PROXY 적용	FINAL 정책과 앞선 규칙에 이미 일치했는지 여부

표의 도메인은 동작을 설명하기 위한 예시이며 실제 접속 가능한 테스트 서비스가 아닙니다. 실제 확인에는 본인이 접근 권한을 가진 대상을 예시 대신 사용하고, 동일한 적용 범위 관계를 기준으로 결과를 예상하세요. 한 번에 하나의 변수만 수정해야 합니다. 먼저 규칙 순서를 바꾸고 결과를 확인하세요. DNS, 프록시 프로토콜, FINAL, 네트워크 환경을 동시에 바꾸면 어떤 변경으로 결과가 달라졌는지 판단하기 어렵습니다.

7. 자주 묻는 질문: 규칙이 있는데 예상대로 적용되지 않을 때

DIRECT 규칙을 추가했는데 왜 PROXY로 연결되나요?

먼저 Home → Global Routing이 Config로 설정되어 있는지 확인한 다음, Config에서 방금 수정한 파일이 선택되어 있는지 확인하세요. 이어서 [Rule]의 맨 위부터 처음 일치하는 규칙을 찾습니다. DOMAIN-SUFFIX가 정확한 DOMAIN보다 앞에 있다면 예외 규칙을 위로 옮겨 저장하고, 새 연결을 시작해 결과를 확인하세요.

FINAL,PROXY는 프록시 연결에 실패하면 자동으로 직접 연결하나요?

아니요. FINAL은 앞선 규칙에 일치하지 않은 요청을 매칭하고, PROXY는 처리 방향을 지정합니다. 프록시 연결이 실패해도 규칙 엔진이 DIRECT로 바꿔 다시 시도하지 않습니다. 선택한 연결을 사용할 수 있는지 확인하거나 본인의 접속 요구에 맞게 정책을 명시적으로 수정하세요.

REJECT를 설정했는데 왜 페이지에 이전 내용이 계속 표시되나요?

기존 페이지가 캐시되어 있다고 해서 새 요청이 발생한 것은 아닙니다. 먼저 대상 호스트가 규칙과 정확히 일치하는지 확인한 다음 페이지를 새로고침하고 새 연결 기록을 살펴보세요. 페이지가 다른 도메인을 사용할 수도 있습니다. 이전 페이지가 계속 보인다는 이유만으로 REJECT가 적용되지 않았다고 판단하지 마세요.

IP-CIDR로 설정했는데 도메인 접속이 왜 규칙에 일치하지 않나요?

실제 대상 IP가 해당 주소 범위에 포함되는지 먼저 확인하세요. no-resolve가 있으면 이 규칙만을 위해 도메인을 직접 조회하지 않습니다. 특정 도메인에 고정된 정책을 적용하려면 DOMAIN 또는 DOMAIN-SUFFIX를 추가하고, 해당 규칙을 덮어쓸 수 있는 규칙보다 앞에 배치하세요.

어제는 적용되던 규칙이 업데이트 후 달라진 이유는 무엇인가요?

Config에서 현재 선택된 파일, 원격 Config 업데이트 후의 [Rule] 내용, Home → Global Routing 설정이 바뀌었는지 확인하세요. 규칙이 그대로라면 대상 도메인, 해석된 주소, 연결 기록을 살펴보세요. GEOIP 또는 IP-CIDR를 사용한다면 주소가 바뀌는 것만으로도 매칭 결과가 달라질 수 있습니다.

최종적으로는 각 규칙의 역할을 설명할 수 있는 목록을 유지하세요. 모든 예외 규칙에는 분명한 목적이 있어야 하고, 각 범위 규칙은 적용 경계가 명확해야 하며, FINAL은 나머지 트래픽이 어디로 향하는지 명시해야 합니다. 규칙이 많다고 반드시 더 정확해지는 것은 아닙니다. 대상 요청에서 시작해 어느 줄에 일치하는지 차례대로 추적할 수 있어야 이후 관리와 문제 해결이 쉬워집니다. 프로토콜 매개변수는 기술 참고 자료에서, 연결 및 설정 문제는 문제 해결에서 확인하세요.