Shadowrocket 규칙 사용법: DOMAIN·DOMAIN-SUFFIX·GEOIP·IP-CIDR·FINAL 매칭 방식

이 글의 핵심 내용

Shadowrocket의 규칙은 매칭 조건과 처리 정책으로 구성됩니다. 사용할 연결 구성이 있고 Config에서 트래픽 분할 규칙을 수정하려는 사용자를 위해, 먼저 도메인과 IP 매칭을 구분하고 규칙 순서를 확인한 뒤 실제 요청으로 매칭 결과를 검증하는 방법을 설명합니다. 예시 도메인과 주소는 문법 설명용이며, 실제 연결 서비스가 아닙니다.

1. 먼저 규칙이 적용되는 모드 확인하기

Home에서 Global Routing을 확인하세요. 이 글에서는 Config를 선택해 현재 구성의 규칙에 따라 트래픽의 출구를 정하는 경우를 다룹니다. Proxy는 프록시를 우선 사용하고 Direct는 직접 연결을 우선합니다. 이 두 모드에서는 웹페이지가 열리는지만 보고 Config 규칙의 적용 여부를 판단하지 마세요. Scene은 상황별로 선택하는 기능이므로 장면 조건과 실제 라우팅 설정을 따로 확인해야 합니다.

규칙은 “이번 연결을 어디에서 처리할지”를 정할 뿐, “프록시 서버에 연결할 수 있는지”를 보장하지 않습니다. 규칙이 PROXY에 올바르게 매칭되어도 사용 중인 서버를 이용할 수 없다면 요청이 실패할 수 있습니다. DIRECT 역시 직접 연결을 선택하는 것일 뿐, 현재 네트워크에서 대상 웹사이트에 접속할 수 있음을 보장하지 않습니다.

요청이 터널에 진입 대상 정보 확인 규칙을 순서대로 검사 일치한 정책 적용 외부 연결 수립

규칙 한 줄은 세 부분으로 나눠 보면 이해하기 쉽습니다. 두 번째 항목은 매칭 값이고 세 번째 항목은 정책입니다. FINAL은 매칭 값이 필요하지 않아 두 항목만 사용합니다. 필드는 영문 쉼표로 구분하므로 쉼표를 한글 쉼표로 바꾸지 마세요.

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

DOMAIN: 매칭 유형으로, 대상 도메인이 정확히 일치해야 합니다.
api.example.com: 매칭 값입니다. 프로토콜, 포트, URL 경로는 포함하지 않습니다.
PROXY: 프록시 정책으로 처리합니다. 사용할 수 있는 프록시 구성이 있어야 합니다.
FINAL,DIRECT: 앞선 규칙에 하나도 일치하지 않을 때 직접 연결합니다.

2. DOMAIN, DOMAIN-SUFFIX, DOMAIN-KEYWORD의 매칭 범위

이 세 가지 키워드는 모두 도메인을 매칭하지만 적용 범위가 다릅니다. 전체 URL을 받았다면 먼저 호스트명을 확인하세요. 예를 들어 https://api.example.com:8443/v1/status의 호스트명은 api.example.com입니다. 8443은 포트이고 /v1/status는 경로이므로 DOMAIN의 매칭 값에 함께 넣으면 안 됩니다.

키워드	규칙 예시	매칭 범위
DOMAIN	`DOMAIN,api.example.com,PROXY`	api.example.com만 매칭하며 하위 도메인은 포함하지 않습니다.
DOMAIN-SUFFIX	`DOMAIN-SUFFIX,example.com,PROXY`	example.com과 api.example.com을 비롯한 하위 도메인을 매칭합니다.
DOMAIN-KEYWORD	`DOMAIN-KEYWORD,example,PROXY`	도메인에 example 문자열이 포함된 대상을 매칭하므로 범위가 더 넓습니다.

정확한 호스트명, 전체 하위 도메인, 키워드

API 호스트 하나만 프록시로 연결하려면 DOMAIN을 사용하세요. 같은 도메인의 메인 사이트, 이미지 사이트, API 사이트까지 포함하려면 DOMAIN-SUFFIX가 관리하기 편합니다. 접미사는 도메인 단계에 따라 매칭하므로 example.com은 notexample.com이나 example.com.other.test와 일치하지 않습니다.

DOMAIN-KEYWORD는 문자열 포함 여부를 확인합니다. example 키워드는 서로 다른 접미사의 도메인에서 같은 문자열을 매칭할 수 있지만, 관계없는 도메인까지 포함할 수도 있습니다. 웹사이트의 소유자나 브랜드 관계, 페이지 내용을 파악하는 기능은 아닙니다. 정확한 도메인으로 원하는 조건을 표현할 수 있다면 규칙을 줄이려고 범위가 넓은 키워드로 바꿀 필요는 없습니다.

3. IP-CIDR과 GEOIP는 대상 IP를 매칭합니다

IP-CIDR은 대상 IP가 지정된 네트워크 대역에 속하는지 확인하고, GEOIP는 IP 지리 정보 데이터베이스에 등록된 위치를 기준으로 판단합니다. 웹페이지 언어, 도메인 접미사, 계정 지역과는 다른 기준입니다. 도메인으로 접속할 때는 IP 매칭에 필요한 주소를 먼저 확인해야 할 수 있습니다. IP 주소로 직접 접속하는 경우에는 일반 도메인 규칙이 매칭할 호스트명이 없습니다.

[Rule]
IP-CIDR,192.168.50.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

192.168.50.0/24는 IPv4 네트워크 대역을 나타내며, 192.168.50.0부터 192.168.50.255까지의 주소를 포함합니다. “포트 24”라는 뜻이 아닙니다.
no-resolve는 이 IP 규칙만을 위해 도메인을 능동적으로 조회하지 않도록 하는 옵션입니다. 모든 DNS를 끄는 기능도, 직접 연결을 설정하는 스위치도 아닙니다.
GEOIP,CN,DIRECT는 데이터베이스가 대상 IP를 CN으로 분류하면 DIRECT를 적용한다는 뜻입니다. “중국어 웹사이트는 직접 연결”이라는 의미가 아닙니다.
IPv6 네트워크 대역에는 해당하는 IP-CIDR6 문법을 사용하세요. IPv6 주소를 IPv4 대역으로 입력하면 안 됩니다.

위의 로컬 네트워크 대역은 문법 설명용 예시입니다. 실제 라우터는 192.168.1.0/24 또는 다른 주소 대역을 사용할 수 있으므로 현재 네트워크에 맞게 입력하세요. 특정 기기 하나를 포함하려고 지나치게 큰 대역을 추가하면 다른 주소도 같은 정책에 포함될 수 있습니다.

GEOIP 결과는 데이터베이스와 대상 IP에 따라 달라집니다. CDN을 사용하는 웹사이트는 네트워크에 따라 서로 다른 주소로 해석될 수 있고, DNS를 변경한 뒤에는 지역 판정 결과가 달라질 수도 있습니다. 따라서 “어제는 DIRECT였는데 오늘은 PROXY”라는 이유만으로 규칙 파일이 손상됐다고 단정할 수 없습니다. 도메인, DNS 조회 결과, 매칭된 규칙을 함께 확인하세요.

4. 규칙은 위에서부터 검사하고 FINAL은 마지막에 배치하기

이 글에서 다루는 일반 규칙 목록은 위에서 아래 순서로 검사하며, 처음 매칭된 규칙이 처리 정책을 결정합니다. 모든 규칙 중 가장 정밀한 규칙이 자동으로 우선 적용되는 방식이 아닙니다. 범위가 넓은 규칙이 먼저 매칭되면 뒤에 있는 정밀한 규칙은 적용될 기회가 없습니다.

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

위 예시에서 api.example.com은 첫 번째 DOMAIN 규칙에 먼저 매칭되어 PROXY를 적용합니다. www.example.com은 첫 번째 줄에는 매칭되지 않지만 두 번째 줄에 매칭되어 DIRECT를 적용합니다. 앞의 두 줄 순서를 바꾸면 API 호스트도 DOMAIN-SUFFIX 규칙에 먼저 걸립니다. 따라서 “예외를 먼저 쓰고 일반 범위를 나중에 쓰는” 것이 중요합니다.

대상	처음 매칭된 규칙	정책
`api.example.com`	DOMAIN	PROXY
`www.example.com`	DOMAIN-SUFFIX	DIRECT
그 외 도메인, 대상 IP가 CN으로 분류되는 경우	GEOIP	DIRECT
그 외 도메인, GEOIP에 매칭되지 않는 경우	FINAL	PROXY

나열한 도메인만 프록시로 연결하기

“지정한 웹사이트만 프록시로 연결하고 나머지는 직접 연결”하려면 아래의 최소 구성부터 시작할 수 있습니다. 이 조건에는 지역 기준을 추가할 필요가 없으므로 GEOIP를 넣지 않았습니다. 규칙이 적다고 기능이 부족한 것은 아닙니다. 정책이 원하는 동작을 정확히 표현하는지가 중요합니다.

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

5. Config에서 수정한 뒤 새 연결로 확인하기

시작하기 전에 사용할 서비스와 연결 구성을 준비해야 합니다. 규칙을 편집한다고 클라이언트를 다시 구매하거나 프로토콜을 바꿀 필요는 없습니다. Shadowsocks, VMess, VLESS, Trojan 등의 프로토콜은 프록시 연결을 담당하고, 이 절에서 다루는 키워드는 요청을 프록시로 보낼지 결정합니다. 서로 다른 계층의 기능입니다.

기존 구성 보관하기

Config로 이동해 현재 구성의 사본을 보관하거나 백업을 내보내고, 사용 중인 구성을 기록하세요. 원격 구성 업데이트로 로컬 수정 사항이 덮어써질 수 있으니 유일한 사본에서 반복적으로 시험하지 마세요.
규칙 부분 편집하기

Config에서 대상 구성의 편집 화면을 열고 [Rule]을 찾으세요. 기존 규칙 부분을 수정하고, 같은 이름의 구간이 여러 개 생기도록 예시 전체를 파일 끝에 반복해서 붙여 넣지 마세요.
필드 순서 확인하기

영문 쉼표를 사용하고 도메인 필드에서 https://, 포트, 경로를 제외하세요. 정확한 예외를 일반 규칙보다 앞에 두고 FINAL은 마지막에 배치한 뒤 정책 이름의 철자도 확인하세요.
대상 구성 사용하기

수정 내용을 저장하고 방금 편집한 구성을 선택한 다음 Home → Global Routing → Config로 돌아가세요. Home에서 사용할 수 있는 서버가 선택되어 있는지도 확인해 연결 문제를 규칙 문제로 오인하지 않도록 하세요.
새 요청 만들기

연결을 새로 만든 뒤 테스트 대상을 방문하고 Data에서 새 요청의 대상, 정책, 매칭 정보를 확인하세요. 기존 연결은 이전 출구 설정을 계속 사용할 수 있으므로 연결을 재사용하는 페이지를 새로고침하는 것만으로 결론을 내리지 마세요.

매번 조건 하나씩만 수정하세요. 예를 들어 먼저 정확한 DOMAIN을 확인하고, 다음에 DOMAIN-SUFFIX로 범위를 넓힌 뒤, 마지막으로 IP 매칭을 추가합니다. 한 번에 수십 개의 규칙을 넣기보다 예상 정책과 실제 정책을 기록하는 편이 문제를 찾기 쉽습니다. 예시 도메인은 문법 설명용이므로 실제 확인에는 접속이 필요한 대상을 사용하세요.

6. “규칙 매칭 여부”와 “연결 가능 여부”를 나눠 점검하기

문제를 확인할 때는 먼저 Data에서 새 요청이 예상한 정책을 사용하는지 살펴본 뒤 대상에 연결할 수 있는지 확인하세요. 매칭 정책이 잘못됐다면 현재 Config, Global Routing, 앞선 규칙을 다시 점검하세요. 정책은 맞는데 시간 초과가 발생한다면 프록시 연결 상태, DNS, 대상 서버를 확인하고, 곧바로 규칙을 더 광범위한 키워드로 바꾸지 마세요.

다음은 Apple 네트워크 오류에 사용되는 표준 식별자로, 시스템이나 앱의 상세 오류 정보에 표시될 수 있습니다. 요청을 시작한 위치에 따라 표시되는 문구는 다를 수 있습니다. 이 오류는 연결 실패를 나타내며 Shadowrocket 규칙 문법 오류를 뜻하지 않습니다. 오류 코드만으로 DIRECT와 PROXY 중 어느 정책을 써야 하는지도 판단할 수 없습니다.

NSURLErrorDomain Code=-1001

원인: 요청이 제한 시간 안에 완료되지 않았습니다. 프록시 연결 단계나 대상의 응답 단계에서 발생할 수 있습니다.

해결: 먼저 Data에서 적용된 정책을 확인한 다음 현재 서버와 동일한 대상의 연결 가능성을 각각 점검하세요. 규칙 순서만 바꿔 시간 초과 원인을 가리지 않도록 합니다.

NSURLErrorDomain Code=-1003

원인: 지정한 호스트를 찾을 수 없습니다. 도메인 철자와 DNS 조회 조건을 먼저 확인하세요.

해결: 요청의 호스트명이 올바른지 확인한 뒤 현재 DNS 설정을 점검하세요. 도메인에 PROXY 규칙을 추가해도 도메인 조회 문제가 해결되지는 않습니다.

DOMAIN-SUFFIX를 설정했는데 왜 직접 연결되나요?

먼저 Home → Global Routing에서 Config가 선택되어 있는지 확인하고, Config에서 올바른 파일이 선택됐는지도 점검하세요. 둘 다 맞다면 해당 규칙보다 앞에 DOMAIN, 다른 접미사 규칙 또는 FINAL이 있어 먼저 매칭되는지 확인하고, Data에서 실제 요청의 호스트명을 살펴보세요.

웹사이트는 열리는데 이미지가 로드되지 않나요?

웹페이지와 이미지가 서로 다른 도메인에서 제공될 수 있습니다. 다시 불러온 뒤 Data에서 실패한 리소스의 호스트를 확인하고 실제 용도에 맞는 정밀한 규칙을 추가하세요. 페이지 주소만 보고 모든 리소스가 같은 DOMAIN-SUFFIX를 사용한다고 단정하지 마세요.

IP-CIDR에 no-resolve를 추가한 뒤 매칭되지 않는 이유는 무엇인가요?

요청이 도메인으로 시작했고 당시 매칭에 사용할 대상 IP가 없었다면, 이 규칙은 네트워크 대역을 확인하기 위해 도메인을 능동적으로 조회하지 않습니다. 도메인 기준으로 트래픽을 나누려면 도메인 규칙을 사용하세요. 조회된 IP를 기준으로 판단해야 한다면 no-resolve를 유지할지 검토하세요.

규칙을 수정했는데 다시 연결한 뒤 원래 내용으로 돌아간 이유는 무엇인가요?

먼저 현재 사용 중인 파일을 편집했는지 확인한 다음 원격 구성 업데이트가 있었는지 살펴보세요. 연결 구독과 규칙 구성은 같은 내용이 아닙니다. 로컬 수정본을 따로 보관하고 업데이트 후 규칙의 차이를 확인하세요. Settings → On Demand는 요청 시 연결을 제어하는 기능이며 규칙을 저장하거나 복원하지 않습니다.

마지막으로 다음 네 가지를 확인하면 됩니다. Global Routing이 Config인지, 현재 구성에 수정 내용이 있는지, 처음 매칭되는 규칙이 예상과 일치하는지, 해당 출구로 연결할 수 있는지 확인하세요. 이 순서대로 점검해야 문법, 규칙 순서, DNS, 연결 상태가 각각 어떤 영향을 미쳤는지 구분할 수 있습니다.