Shadowrocket 사용자 지정 규칙 설정법: 매칭 순서와 FINAL, PROXY/DIRECT/REJECT

이 글의 핵심 내용

Shadowrocket에 이미 보유한 구독을 추가했고 Config를 수정하려는 사용자를 위한 안내입니다. 먼저 Global Routing이 Config로 설정되어 있는지 확인하고, 규칙 조건과 실행 정책을 구분합니다. 확인 가능한 규칙 예시로 정확한 도메인, 도메인 접미사, IP 대역 및 FINAL의 순서를 살펴본 뒤, '규칙에 일치하지 않음'과 '일치했지만 요청 실패'를 각각 단일 변수 테스트로 진단합니다.

Global Routing을 확인한 다음 Config 수정하기

Shadowrocket에서 Home은 연결 및 기존 서비스를 선택하는 화면이고, Config는 구성 파일을 관리하며, Settings는 앱 설정을 담당합니다. 구독 항목에는 연결에 필요한 정보가 있지만 현재 구성 파일의 규칙이 포함되는 것은 아닙니다. 기존 구독을 업데이트해도 편집한 규칙이 활성화되는 것은 아니며, 구성 파일을 저장했다고 해서 Home의 라우팅에 적용되는 것도 아닙니다.

확인 경로는 Home → Global Routing입니다. 여기서는 Config 모드에서 규칙이 어떻게 판정되는지 다루며, Proxy나 Direct를 규칙으로 간주하지 않습니다. Global Routing에는 Scene도 표시되며, 이는 장면 선택과 관련이 있습니다. 이 글의 정적 규칙을 점검할 때는 먼저 Config로 전환해 장면 변경이라는 변수를 배제하세요.

Config

권장

현재 적용 중인 구성의 규칙에 따라 정책을 선택합니다. 이 글의 DOMAIN-SUFFIX, IP-CIDR, FINAL 예시는 모두 이 설정을 전제로 합니다.

추천 상황: 사용자 지정 규칙과 최종 대체 규칙을 하나씩 확인할 때

Proxy

트래픽을 프록시 방식으로 처리하므로, 이 글에서 설명하는 사용자 지정 규칙에 따라 DIRECT나 REJECT를 하나씩 선택하는 방식과는 다릅니다. 프록시 연결이 가능한지 점검할 때 비교 기준으로 사용할 수 있습니다.

추천 상황: 규칙 라우팅의 영향을 임시로 분리할 때

Direct

트래픽을 직접 연결로 처리합니다. 이 상태에서는 접속 결과만으로 Config의 PROXY 규칙이 유효한지 판단할 수 없습니다.

추천 상황: 로컬 네트워크의 직접 접속 상태를 확인할 때

규칙 행 문법: 조건을 먼저, 정책은 뒤에

일반적인 규칙은 필드를 영문 쉼표로 구분해 구성 파일의 [Rule] 섹션에 입력합니다. 도메인 규칙은 보통 '유형, 매칭 값, 정책' 순서이며, FINAL은 매칭 값 없이 'FINAL, 정책'으로 작성합니다. 규칙 행에 한글 쉼표나 설명을 붙이지 말고, 몇 개의 규칙을 추가하려고 같은 파일에 [Rule] 섹션을 여러 번 만들지 마세요.

[Rule]
DOMAIN,api.example.com,PROXY
DOMAIN-SUFFIX,example.com,DIRECT
IP-CIDR,192.168.50.0/24,DIRECT,no-resolve
FINAL,PROXY

example.com은 문서용 예시 도메인이고, 192.168.50.0/24는 사설 네트워크 대역의 예시입니다. 실제 네트워크에서 이 대역을 사용한다는 뜻은 아닙니다. 이 내용은 필드 구성과 순서를 설명하기 위한 것이며, 기존 설정을 대체해도 되는 범용 규칙 모음이 아닙니다.

키워드	조건 예시	확인 사항
`DOMAIN`	`api.example.com`	전체 도메인과 일치하며, 다른 하위 도메인은 포함하지 않습니다.
`DOMAIN-SUFFIX`	`example.com`	해당 도메인과 하위 도메인에 일치합니다. 와일드카드 별표는 필요하지 않습니다.
`IP-CIDR`	`192.168.50.0/24`	대상 IPv4 주소가 속한 네트워크 대역과 일치합니다. 도메인 문자열로 매칭하지 않습니다.
`GEOIP`	`CN`	대상 IP의 지리적 데이터베이스상 위치를 기준으로 판정하며, 웹페이지 내용을 기준으로 하지 않습니다.
`FINAL`	조건 필드 없음	앞선 규칙에 모두 일치하지 않은 요청을 처리합니다. 규칙 목록의 마지막에 두어야 합니다.

DOMAIN-SUFFIX는 도메인 경계를 기준으로 매칭하며, 임의의 문자열 포함 여부를 확인하지 않습니다. 예를 들어 example.com은 www.example.com에 적용될 수 있지만, notexample.com까지 포함하는 것은 아닙니다. 규칙에는 https://, 페이지 경로, 쿼리 매개변수를 입력하지 마세요. 도메인 필드에 해당하지 않는 값입니다.

매칭 순서: 예외를 먼저, 넓은 범위는 나중에

규칙은 '나중에 작성한 항목이 앞선 항목을 덮어쓰는' 방식이 아니며, 가장 길거나 구체적인 항목을 자동으로 우선 적용하지도 않습니다. 규칙 판정이 필요한 요청은 Shadowrocket이 위에서 아래로 확인하고, 처음 일치한 규칙의 정책을 적용합니다. 따라서 정확한 예외 규칙은 해당 예외를 포함할 수 있는 넓은 범위의 규칙보다 앞에 두어야 합니다.

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

api.example.com: 첫 번째 도메인 규칙에 일치해 PROXY가 적용됩니다. 뒤의 접미사 규칙이 이를 DIRECT로 바꾸지 않습니다.
www.example.com: 첫 번째 규칙에는 일치하지 않고 두 번째 규칙에 일치해 DIRECT가 적용됩니다.
그 외 대상: GEOIP 규칙을 계속 확인하며, 조건에 맞지 않으면 마지막으로 FINAL의 PROXY가 적용됩니다.

DOMAIN-SUFFIX를 DOMAIN보다 앞에 두면 api.example.com이 먼저 접미사 규칙에 일치해, 뒤에 있는 정확한 예외 규칙은 적용되지 않습니다. 마찬가지로 넓은 범위의 대상에 적용되는 규칙 모음을 로컬 예외보다 앞에 두면 예외가 무시될 수 있습니다. 문제를 점검할 때는 앞선 규칙도 함께 확인해야 합니다. 대상 규칙이 '있다'는 것만 확인해서는 부족합니다.

1개

한 번의 규칙 판정에는 처음 일치한 규칙의 결과가 적용됩니다

3가지

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

/32

IPv4 CIDR에서 단일 주소를 나타내는 프리픽스 길이

PROXY, DIRECT, REJECT와 FINAL의 역할

규칙 유형은 '무엇을 매칭할지', 정책은 '매칭된 뒤 어떻게 처리할지'를 결정합니다. 여기서 PROXY, DIRECT, REJECT는 정책이고, FINAL은 별도 매칭 조건이 없는 대체 규칙 유형입니다. 두 개념을 구분하면 FINAL을 새로운 전송 프로토콜로 오해하지 않을 수 있습니다.

PROXY: 일치한 요청을 프록시 경로로 처리합니다. 실제 연결 대상은 현재 선택한 항목과 구성 내 정책의 관계도 확인해야 합니다. PROXY를 적는다고 사용할 수 있는 서비스가 자동으로 생기거나 잘못된 인증 정보가 수정되는 것은 아닙니다.
DIRECT: 요청을 프록시 경로로 보내지 않고 현재 네트워크에서 대상에 직접 접속합니다. 직접 연결도 로컬 네트워크, DNS, 대상 서비스의 연결 가능 여부에 영향을 받으며, 모든 네트워크 제한을 우회하는 것은 아닙니다.
REJECT: 일치한 요청을 거부합니다. 명확히 필요하지 않은 대상을 차단하는 테스트에 사용할 수 있지만, 범위가 너무 넓으면 로그인, 이미지, 앱 인터페이스까지 영향을 받을 수 있으므로 되돌리는 방법을 마련해야 합니다.

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

이 예시는 먼저 blocked.example.com을 거부하고, 같은 접미사에 속하는 나머지 도메인은 직접 연결하며, 그 외 요청은 PROXY로 처리합니다. FINAL을 첫 번째 줄로 옮기면 이 규칙 목록까지 도달하는 요청이 모두 먼저 FINAL에 처리되어 뒤의 도메인 규칙은 판정에 참여하지 못합니다.

IP-CIDR, GEOIP, DNS: 주소 정보의 출처 구분하기

도메인 조건과 IP 조건은 서로 다른 정보를 사용합니다. DOMAIN-SUFFIX는 도메인을, IP-CIDR과 GEOIP는 대상 주소를 확인합니다. 도메인만 있고 사용할 수 있는 대상 IP가 아직 없는 요청은 IP 규칙을 적용할 때 DNS 조회가 필요할 수 있습니다. 도메인 규칙이 일치하지 않았다고 해서 곧바로 네트워크 대역을 잘못 작성했다고 판단하지 마세요.

IP-CIDR,192.168.50.0/24,DIRECT,no-resolve
IP-CIDR,192.168.50.10/32,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

위의 두 IP-CIDR 규칙은 네트워크 대역과 단일 주소의 차이를 보여줍니다. 첫 번째 규칙이 이미 192.168.50.10을 포함하므로 정책이 같다면 두 번째 규칙은 대개 필요하지 않습니다. 해당 단일 주소에 다른 정책을 적용하려면 /32 예외를 /24 규칙 뒤에 추가하지 말고 앞에 배치하세요.

no-resolve는 이 IP 규칙만을 위해 도메인 조회를 추가로 실행하지 말라는 뜻입니다. 앱 전체의 DNS를 끄거나 요청에 대상 IP가 더 이상 없다는 뜻은 아닙니다.
요청에 사용할 수 있는 대상 IP가 이미 있다면 해당 주소로 네트워크 대역을 판정할 수 있습니다. 아직 주소가 없고 규칙이 DNS 조회를 유발하지 않는다면, 도메인만으로 이 규칙이 IP 매칭을 할 것이라고 기대할 수 없습니다.
GEOIP,CN,DIRECT는 IP 지리 정보 데이터베이스를 기준으로 판정합니다. CDN 라우팅, DNS 응답, 데이터베이스상의 위치가 판정에 영향을 미칠 수 있으며, 페이지가 중국어인지 여부는 매칭 조건이 아닙니다.
도메인에 접속할 때는 IPv6도 확인해야 합니다. IPv4용 IP-CIDR 규칙은 IPv6 주소에 자동으로 적용되지 않습니다. 대상이 IPv6를 사용한다면 해당 IPv6 규칙도 따로 점검하세요.

규칙은 요청에서 실제로 확인할 수 있는 정보만 사용합니다. 앱이 IP에 직접 연결되고 연결할 도메인 정보가 없다면 도메인 규칙이 일치하지 않을 수 있습니다. 넓은 DOMAIN-SUFFIX 규칙을 계속 추가하기보다 실제 대상 도메인이나 주소를 기록해 확인하세요.

수정 및 테스트: 한 번에 조건 하나만 변경하기

현재 정상 작동하는 구성을 보존한 뒤 작은 범위부터 수정하세요. 원격 구성과 로컬 사본을 구분해야 합니다. 원격 콘텐츠를 업데이트하면 로컬 수정 사항이 덮어써질 수 있으며, 기존 구독을 업데이트하는 것은 보통 연결 항목을 갱신하는 작업이므로 사용자 지정 규칙이 적용됐다는 증거가 되지 않습니다. 테스트 전에 기존 프록시 연결 자체가 정상인지도 확인하세요.

원본 파일 보존

Config로 이동해 현재 사용하는 구성을 확인하고 복구할 수 있는 사본을 보관하세요. 원격에서 가져온 콘텐츠를 수정하려면 편집 가능한 로컬 사본을 먼저 만들고, 다음 업데이트에서 테스트 규칙이 덮어써지지 않도록 하세요.
규칙 섹션 편집

Config에서 테스트할 파일의 편집 화면을 열고 [Rule]을 찾으세요. 단일 도메인의 정확한 예외를 해당 접미사 규칙 앞에 두고, FINAL이 마지막에 있는지 확인한 다음 저장하고 해당 구성을 선택하세요.
라우팅 설정 확인

Home → Global Routing → Config로 돌아가세요. 현재 프록시 선택을 확인하고, 이번 규칙 테스트에 Proxy, Direct, Scene의 다른 동작이 섞이지 않도록 하세요.
요청 다시 생성

대상 페이지를 닫았다가 다시 열고, 필요한 경우 연결을 다시 설정해 기존 장기 연결 재사용으로 인한 영향을 줄이세요. 매 테스트마다 규칙 순서나 정책 하나만 변경하고, DNS와 프록시 매개변수를 동시에 바꾸지 마세요.
기록하고 복구

대상, 일치한 규칙, 적용된 정책, 접속 상태를 기록하세요. 현재 확인할 수 있는 요청 기록과 대조하고, 예상과 다르면 원래 구성으로 복구한 뒤 같은 대상으로 다시 테스트하세요.

테스트 기록에는 '실제 관찰 결과'와 '예상 동작'을 구분해 적어야 합니다. 예를 들어 직접 관리하는 테스트 도메인에 임시로 REJECT를 설정했다면 관련 요청이 거부되는 것이 예상 결과입니다. 페이지에 콘텐츠가 계속 표시되면 규칙 시스템 전체가 작동하지 않는다고 단정하지 말고 캐시, 다른 도메인, 이미 연결된 세션부터 확인하세요. 이 글의 규칙 예시는 실제 네트워크에서 테스트를 마친 결과가 아닙니다.

자주 묻는 질문: 매칭 결과로 원인 찾기

DOMAIN을 추가했는데도 DIRECT로 연결됩니다. 무엇이 잘못됐나요?

먼저 Home → Global Routing에서 Config가 선택되어 있는지 확인한 다음, Config에서 실제로 적용 중인 파일을 확인하세요. 이어서 위쪽에 더 먼저 일치하는 DOMAIN-SUFFIX, IP 규칙 또는 규칙 모음이 있는지 살펴보세요. 정확한 예외 규칙을 해당 규칙보다 앞에 배치하고 저장한 뒤 요청을 다시 보내세요.

FINAL을 PROXY로 설정했는데 일부 요청은 왜 계속 직접 연결되나요?

FINAL은 앞선 규칙에 일치하지 않은 요청만 처리합니다. 먼저 대상이 DOMAIN-SUFFIX나 GEOIP 같은 DIRECT 항목에 이미 일치했는지 확인하고, FINAL을 맨 앞으로 옮기지 마세요. 실제로 일치한 항목을 수정하거나 그 앞에 범위가 더 좁은 예외 규칙을 추가해야 합니다.

PROXY에 일치했는데 접속할 수 없습니다. 규칙 순서도 바꿔야 하나요?

결과가 PROXY로 확인됐다면 현재 선택된 프록시, 인증 정보, 대상 포트, DNS를 먼저 점검하세요. 비교를 위해 Home → Global Routing → Proxy를 임시로 사용할 수 있으며, 테스트가 끝나면 Config로 되돌리세요. 정책 실행 실패와 규칙 미일치는 서로 다른 진단 경로입니다.

REJECT 하나를 추가한 뒤 앱 전체에 문제가 생겼습니다. 어떻게 복구하나요?

Config에서 방금 추가한 항목을 삭제하거나 백업을 복원한 다음 연결을 다시 설정하세요. 이어서 실제 요청 도메인에 맞춰 매칭 범위를 좁히고, 먼저 DOMAIN으로 단일 대상을 확인하세요. 여러 서비스가 공유하는 접미사나 넓은 네트워크 대역 전체를 바로 차단하지 마세요.

최종 점검 순서는 일정하게 유지하세요. 현재 구성이 올바른지, Global Routing이 Config인지, 실제로 처음 일치한 규칙이 무엇인지, 해당 정책을 실행할 수 있는지 확인합니다. 이 네 가지를 먼저 확인한 뒤 규칙 범위를 넓히세요. 이렇게 하면 명확한 복구 지점을 유지하고, 중복 규칙을 대량으로 추가해 구성 선택이나 연결 매개변수 문제를 가리는 일을 방지할 수 있습니다.