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

이 글의 핵심 내용

Shadowrocket 규칙은 연결을 PROXY, DIRECT, REJECT 중 어떤 방식으로 처리할지 결정합니다. 기존 서비스와 구독을 이용하며 Config를 조정하려는 사용자를 위해 도메인·IP 매칭부터 첫 번째 규칙 적용, FINAL 기본 처리, 수정 후 확인 방법까지 설명합니다. 예시 도메인과 주소는 문법 설명용이며 연결에 사용할 수 있는 리소스가 아닙니다. 글을 읽고 나면 규칙이 적용되는 이유와 예외 규칙을 배치할 위치를 파악할 수 있습니다.

1. 매칭 조건과 연결 동작 구분하기

규칙은 보통 ‘유형, 매칭 값, 동작’으로 구성하며 각 필드는 영문 쉼표로 구분합니다. 예를 들어 DOMAIN,example.com,DIRECT는 매칭 가능한 대상 도메인이 정확히 example.com일 때 DIRECT를 선택한다는 뜻입니다. 규칙 자체가 사용 가능한 프록시 연결을 생성하지는 않습니다. PROXY를 선택해도 기존 연결 항목의 주소, 포트, 프로토콜 매개변수가 올바르게 설정되어 있어야 합니다.

대상 연결 매칭 정보 확인 규칙 순서대로 확인 첫 번째 규칙 적용 연결 동작 실행

PROXY는 프록시를 통해 연결하고, DIRECT는 대상에 직접 연결하며, REJECT는 연결을 거부한다는 뜻입니다. 이는 Shadowsocks, VMess, VLESS, Trojan, Hysteria2, WireGuard 같은 프로토콜명이 아닙니다. 프로토콜은 프록시 연결을 설정하는 방식을 정하고, 규칙은 대상별로 어떤 연결 정책을 적용할지 정합니다. 두 항목은 서로 다른 계층에 속합니다.

6가지

이 글에서 다루는 규칙 키워드

3가지

동작 예시: PROXY / DIRECT / REJECT

1개

한 번 매칭되면 첫 번째로 적용된 규칙의 결과를 따릅니다.

아래 설명은 iPhone / iPad의 Home, Config, Global Routing 화면 용어를 기준으로 합니다. 규칙이 적용되는지 테스트하려면 Home → Global Routing에서 Config를 선택하세요. Proxy 또는 Direct는 전역 라우팅 모드이므로 같은 Config 규칙이 예상대로 적용되는지 확인하는 용도로 사용할 수 없습니다. Scene은 별도의 시나리오 설정이며 Config와 같은 의미로 보면 안 됩니다.

2. DOMAIN, DOMAIN-SUFFIX, DOMAIN-KEYWORD

세 유형 모두 도메인을 대상으로 하지만 매칭 범위가 다릅니다. DOMAIN은 전체 도메인이 정확히 일치할 때, DOMAIN-SUFFIX는 지정한 도메인과 하위 도메인에, DOMAIN-KEYWORD는 도메인에 지정한 문자열이 포함될 때 매칭됩니다. 규칙의 도메인에는 https://, 경로, 쿼리 매개변수, 포트를 쓰지 않습니다.

규칙 형식	매칭되는 항목	매칭되지 않는 항목
`DOMAIN,example.com,DIRECT`	`example.com`	`api.example.com`
`DOMAIN-SUFFIX,example.com,PROXY`	`example.com`、`api.example.com`	`notexample.com`
`DOMAIN-KEYWORD,example,REJECT`	`example.com`、`myexample.net`	`sample.net`

DOMAIN-SUFFIX는 임의의 문자열 끝부분이 아니라 도메인 계층을 기준으로 매칭합니다. 따라서 notexample.com은 example.com의 하위 도메인이 아닙니다. 반면 DOMAIN-KEYWORD에는 이런 계층 경계가 없습니다. ads처럼 짧은 문자열을 사용하면 원치 않는 도메인까지 매칭될 수 있습니다. 이름에 특정 단어가 포함된다는 이유만으로 연결 용도를 단정해서는 안 됩니다.

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

위 예시에서 api.example.com은 DOMAIN 규칙에 먼저 매칭되어 DIRECT로 연결됩니다. www.example.com은 첫 번째 규칙에 매칭되지 않으므로 두 번째 규칙에 따라 PROXY를 선택합니다. 여기서 telemetry는 문자열 매칭을 보여 주는 예시일 뿐, 실제 연결 내용이나 용도를 판별하는 기준이 아닙니다. 확인된 특정 도메인의 연결을 거부하려면 범위가 더 명확한 DOMAIN 또는 DOMAIN-SUFFIX를 우선 사용하세요.

3. GEOIP와 IP-CIDR: 대상 IP 기준 매칭

GEOIP는 IP 데이터베이스에 기록된 할당 정보를 기준으로 대상 주소를 매칭합니다. 흔히 GEOIP,CN,DIRECT처럼 작성합니다. CN은 데이터베이스에서 사용하는 지역 코드이며 도메인 접미사가 아닙니다. 같은 도메인도 DNS가 반환하는 주소에 따라 IP 매칭 결과가 달라질 수 있습니다.

IP-CIDR은 서브넷으로 주소 범위를 지정합니다. /24는 앞의 24비트가 고정된다는 뜻이고, /32는 IPv4 주소 하나를 가리킵니다. 아래는 문서용 예시 서브넷으로 문법을 설명한 것이며, 접속 가능한 서버를 뜻하지 않고 일상적인 설정에 추가할 필요도 없습니다.

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

192.0.2.8/32는 이 IPv4 주소 하나에만 매칭되며 192.0.2.9는 포함하지 않습니다.
198.51.100.0/24는 198.51.100.0부터 198.51.100.255까지의 주소 범위를 나타냅니다. 이 주소들이 모두 호스트 주소로 사용할 수 있다는 뜻은 아닙니다.
no-resolve는 해당 IP 규칙을 매칭하려는 목적만으로 도메인 조회를 실행하지 않도록 합니다. 앱 전체의 DNS를 끄는 스위치는 아닙니다.
현재 도메인만 있고 사용할 수 있는 대상 IP가 없다면 no-resolve가 붙은 IP 규칙은 매칭되지 않을 수 있습니다. 문제를 확인할 때는 연결 시점에 실제로 어떤 정보가 있었는지 살펴보세요.

IP-CIDR은 포트를 확인하지 않습니다. 같은 대상 IP의 TCP 443과 TCP 8443이 동일한 서브넷 규칙에 매칭될 수 있습니다. 443은 연결되지만 8443은 실패한다면 서브넷 마스크만 바꿔서는 해결할 수 없습니다. IPv6 주소에는 해당 IPv6 규칙 유형을 사용하고, IPv6 주소를 이 글의 IPv4 예시에 그대로 적용하지 마세요.

4. 위에서부터 규칙을 확인하고 FINAL은 마지막에 배치

규칙은 키워드의 ‘정확도’를 기준으로 자동 정렬되지 않습니다. DOMAIN이 DOMAIN-SUFFIX보다 항상 먼저 적용되는 것도 아닙니다. 범위가 넓은 접미사 규칙에 먼저 매칭되면 뒤에 있는 정확한 도메인 규칙은 실행되지 않습니다. 우선 처리해야 하는 예외를 앞에, 범위가 넓은 규칙을 뒤에 배치하세요.

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

대상이 download.example.com이면 첫 번째 규칙에 매칭되어 DIRECT를 선택하고, 두 번째 규칙은 확인하지 않습니다.
대상이 docs.example.com이면 첫 번째 규칙에는 매칭되지 않고 두 번째 규칙에 매칭되어 PROXY를 선택합니다. GEOIP 규칙은 더 이상 확인하지 않습니다.
대상이 위 도메인에 해당하지 않지만 데이터베이스에서 대상 IP를 CN으로 분류하면 GEOIP 규칙에서 DIRECT를 선택합니다.
앞선 규칙에 하나도 매칭되지 않으면 FINAL,PROXY를 사용해 나머지 연결을 프록시로 보냅니다.

FINAL에는 도메인이나 서브넷 필드가 없습니다. 형식은 FINAL,동작이며 FINAL,example.com,PROXY가 아닙니다. 앞선 규칙에서 처리되지 않은 연결에 매칭되므로 보통 규칙 맨 마지막에 둡니다. FINAL을 앞에 배치하면 뒤에 있는 일반 규칙이 매칭될 기회를 잃습니다.

5. Config에서 규칙 수정 및 확인하기

규칙 테스트는 사용자가 기존 서비스와 구독을 보유하고 있다는 전제에서 진행합니다. Home의 Subscribe 연결 항목과 Config의 분기 설정은 서로 다른 내용입니다. 연결 구독을 새로 고쳐도 새 규칙이 로드되었다는 뜻은 아니며, Config를 수정해도 잘못된 프로토콜 비밀번호나 서버 포트가 해결되지는 않습니다. 수정 전에 원본 Config를 보관하고 연결 매개변수와 라우팅 규칙을 동시에 변경하지 마세요.

Config 백업

Config를 열고 현재 사용 중인 설정을 찾은 다음, 해당 항목의 작업 메뉴에서 백업을 내보냅니다. 기존에 선택된 설정을 기록해 두고 테스트에는 복사본을 사용하세요. 복구할 수 있도록 원본은 보관합니다.
규칙 편집

Config에서 테스트용 설정의 편집 화면을 열고 [Rule]을 찾습니다. 해당 섹션이 이미 있으면 이름을 중복으로 추가하지 마세요. 명확한 DOMAIN 규칙 하나를 FINAL 앞에 삽입한 뒤 저장합니다.
설정 선택

Config로 돌아가 방금 수정한 설정이 선택되어 있는지 확인합니다. 그런 다음 Home → Global Routing에서 Config를 선택하고 Home에서 현재 사용 중인 연결 항목도 확인합니다.
새 연결로 테스트

대상 페이지를 닫고 다시 접속합니다. 필요한 경우 연결을 끊었다가 다시 연결하세요. 기존의 장시간 연결은 이전 연결 상태를 유지할 수 있으므로 규칙을 저장한 뒤에도 이어진 기존 세션을 새 규칙의 검증 결과로 보면 안 됩니다.
연결 기록 확인

연결 기록이나 로그에서 대상 도메인, 대상 IP, 실제 적용된 정책을 확인합니다. 한 번에 한 곳만 수정하세요. 결과가 예상과 다르면 백업을 복원한 뒤 수정 전후의 규칙 순서를 비교합니다.

확인할 때는 먼저 제어 가능한 전체 도메인으로 DOMAIN 규칙을 테스트한 뒤 DOMAIN-SUFFIX로 범위를 넓히세요. 처음부터 짧은 DOMAIN-KEYWORD를 추가하면 어떤 대상이 영향을 받았는지 파악하기 어렵습니다. 앱 요청에 IP 주소만 표시되는 경우에는 도메인 규칙에 매칭에 필요한 정보가 충분히 있다고 단정할 수 없습니다.

6. 연결 오류와 규칙 오류를 구분해 확인하기

‘웹페이지가 열리지 않는다’는 사실만으로 규칙 문법 오류라고 판단할 수는 없습니다. 먼저 실제로 적용된 연결 방식이 예상과 같은지 확인한 뒤 연결 계층을 점검하세요. 다음은 연결 진단이나 하위 로그에 나타날 수 있는 오류 문구입니다. 플랫폼과 시스템에 따라 전체 메시지는 다를 수 있으며, 특정 규칙 파싱 오류를 뜻하는 고정 문구는 아닙니다.

오류: Connection refused

원인 및 해결 방법: 대상 포트에서 연결을 받지 않거나 연결을 거부했습니다. 로그에서 실패한 대상이 프록시 서버인지 웹사이트인지 먼저 확인한 다음, 기존 연결의 주소와 포트를 서비스 제공업체에 문의하세요. PROXY에 매칭된 것을 프록시 포트가 사용 가능하다는 뜻으로 오해하지 마세요.

오류: Operation timed out

원인 및 해결 방법: 제한 시간 안에 연결이 완료되지 않았습니다. 네트워크 경로, 서버 또는 방화벽이 원인일 수 있습니다. 먼저 현재 규칙에서 같은 대상에 실제 적용된 연결 방식이 예상과 일치하는지 확인한 뒤 네트워크와 기존 연결 매개변수를 점검하세요. 시간 초과만으로 특정 규칙 키워드를 원인으로 지목할 수는 없습니다.

규칙이 매칭되지 않음: Global Routing이 Config로 설정되어 있는지, 올바른 설정을 선택했는지, 위쪽 규칙이 먼저 매칭되어 덮어쓰지 않았는지 확인한 뒤 대상이 도메인인지 IP인지 살펴보세요.
매칭된 뒤 연결 실패: 올바른 규칙은 유지하고 현재 연결의 프로토콜, 포트, 인증 매개변수를 확인하세요. TLS 연결이라면 시스템 시간과 서버 이름 설정도 점검해야 합니다.
저장 후 이상 발생: 영문 쉼표, 필드 개수, [Rule] 섹션 위치와 동작 이름을 확인하세요. 먼저 정상 작동이 확인된 규칙 하나로 복원한 뒤 새 항목을 하나씩 추가합니다.
결과가 간헐적으로 달라짐: DNS가 반환한 주소를 기록하세요. GEOIP와 IP-CIDR은 실제 대상 IP를 기준으로 합니다. CDN이 서로 다른 주소를 반환한다면 브라우저 주소창만으로 결과를 판단할 수 없습니다.

7. Shadowrocket 규칙 작성 FAQ

DOMAIN 규칙을 추가했는데 하위 도메인이 여전히 프록시로 연결되는 이유는 무엇인가요?

DOMAIN은 전체 도메인이 정확히 일치할 때만 매칭됩니다. example.com과 그 하위 도메인 모두 DIRECT로 연결하려면 DOMAIN-SUFFIX,example.com,DIRECT를 사용하고, 이를 먼저 매칭될 수 있는 범위가 넓은 규칙보다 앞에 배치하세요. 수정 후 Home → Global Routing에서 Config를 사용 중인지 확인한 다음 새 연결을 생성합니다.

정확한 규칙을 뒤에 두면 우선 적용되는 것 아닌가요?

자동으로 우선 적용되지는 않습니다. 하위 도메인에 예외를 먼저 적용하려면 DOMAIN,api.example.com,DIRECT를 DOMAIN-SUFFIX,example.com,PROXY 앞에 배치하세요. 저장 후 현재 선택된 설정을 확인해 복사본을 편집하고도 원본 설정을 계속 사용하는 일이 없도록 합니다.

구독을 업데이트하면 직접 작성한 규칙이 사라지나요?

먼저 업데이트 대상이 무엇인지 구분하세요. Home의 연결 구독과 Config의 원격 설정은 서로 다릅니다. 원격 설정을 업데이트하면 해당 Config의 로컬 변경 사항이 덮어써질 수 있습니다. 규칙을 테스트하기 전에 백업하고 별도의 복사본으로 저장하세요. 업데이트 후에는 [Rule] 내용을 다시 확인하고 직접 작성한 항목이 모두 유지된다고 가정하지 마세요.

FINAL은 DIRECT와 PROXY 중 어떤 동작으로 설정해야 하나요?

앞선 규칙에 매칭되지 않은 연결을 어떻게 처리할지에 따라 다릅니다. FINAL,DIRECT는 나머지 연결을 직접 연결하고 FINAL,PROXY는 프록시로 보냅니다. 기본 처리 방식을 먼저 정한 뒤 필요한 예외 규칙이 FINAL 앞에 있는지 확인하세요. 둘 다 사용 가능한 네트워크나 올바른 연결 매개변수를 대신할 수는 없습니다.