Shadowrocket 규칙 문법 입문: DOMAIN-SUFFIX, GEOIP, IP-CIDR, FINAL 매칭 방법

이 글 한눈에 보기

이 글은 Shadowrocket에 직접 보유한 구성을 가져온 뒤 라우팅 규칙을 조정하려는 사용자를 위한 안내입니다. 먼저 Global Routing이 Config로 설정되어 있는지 확인하고, 도메인 조건과 IP 조건을 구분하세요. 마지막으로 ‘구체적인 예외를 먼저, 넓은 범위는 다음에, FINAL은 끝에’ 배치합니다. 아래 예시는 문법 설명용이며 실제 연결에 사용할 수 있는 매개변수는 포함하지 않습니다. 테스트할 때는 접근 권한이 있는 대상으로 바꾸세요.

규칙이 적용되는 조건부터 확인

규칙은 연결에 적용할 정책을 결정하지만 서버를 만들거나 서버 자체의 사용 가능 여부를 결정하지는 않습니다. Home에서는 서버를 선택하고 연결을 관리하며, Config에서는 구성 파일을 관리하고, Settings에서는 앱 설정을 변경합니다. 파일을 편집한 뒤에는 해당 파일이 현재 선택된 구성인지도 확인해야 합니다. 저장만 하고 활성화하지 않은 파일은 현재 적용 중인 규칙을 바꾸지 않습니다.

Home → Global Routing에서 Config를 선택해야 현재 구성을 기준으로 이 글에서 설명하는 라우팅이 적용됩니다. Proxy는 전체 연결에 프록시를 사용하는 모드이고, Direct는 전체 연결을 직접 연결하는 모드입니다. Scene은 설정된 장면 조건에 따라 확인해야 합니다. 메뉴에 Scene이 표시된다는 이유만으로 특정 규칙이 적용 중이라고 판단할 수는 없습니다. 문제를 확인할 때는 먼저 Config로 고정해 장면 전환으로 생기는 변수를 줄이세요.

6가지

이 글에서 다루는 규칙: DOMAIN, DOMAIN-SUFFIX, DOMAIN-KEYWORD, GEOIP, IP-CIDR, FINAL

3개 항목

일반 조건 규칙은 유형, 매칭 값, 정책으로 구성됩니다

1개

최소 예시에서는 FINAL 한 줄로 앞선 규칙에 매칭되지 않은 연결을 처리합니다

요점: 적용 중인 구성을 먼저 고정

테스트 전에 현재 구성 이름과 Global Routing 선택 항목을 기록하세요. 둘 중 하나라도 확실하지 않다면 규칙을 추가하지 마세요. 구성이 바뀐 것인지 매칭 조건이 달라진 것인지 판단할 수 없습니다.

규칙 작성법과 정책 이름

구성 텍스트의 [Rule] 섹션에서 일반 조건 규칙은 보통 쉼표로 구분된 세 항목, 즉 규칙 유형, 매칭 값, 정책으로 작성합니다. 도메인 필드에 웹 주소 전체를 입력하지 마세요. 도메인 조건에는 https://, 경로, 쿼리 매개변수 또는 포트가 포함되지 않습니다. 아래 두 줄은 각각 ‘지정한 도메인에 직접 연결’과 ‘나머지 연결에는 프록시 사용’을 뜻합니다.

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

필드 또는 정책	의미	확인할 점
`DOMAIN`	전체 도메인을 기준으로 매칭하는 규칙 유형입니다.	프로토콜 유형이나 서버 이름이 아닙니다.
`example.com`	해당 규칙에서 사용하는 매칭 값입니다.	경로가 포함된 웹 주소를 입력하면 안 됩니다.
`DIRECT`	대상에 직접 연결합니다.	현재 네트워크, DNS, 대상의 연결 가능 여부에 따라 결과가 달라질 수 있습니다.
`PROXY`	프록시 정책을 사용합니다.	Home에서 현재 선택된 기본 서버를 확인하세요.
`REJECT`	매칭된 연결을 거부합니다.	규칙에 매칭된 뒤 접속이 실패하는 것이 의도된 결과일 수 있습니다.

기존 구성에서 사용자 지정 정책 그룹 이름을 사용한다면 규칙 끝에 구성에 실제로 존재하는 이름을 지정해야 합니다. 처음 테스트할 때는 DIRECT와 PROXY를 사용하고, 한 번에 정책 그룹 추가, DNS 변경, 규칙 순서 변경을 함께 하지 마세요. 이 글의 예시는 일부 규칙만 보여주는 조각입니다. 기존 구성에 [Rule] 섹션이 있다면 그 안을 편집하고, 같은 이름의 섹션을 반복해서 추가하지 마세요.

도메인 조건 세 가지 구분하기

DOMAIN은 단일 호스트 예외에, DOMAIN-SUFFIX는 도메인과 그 하위 도메인에 적합합니다. DOMAIN-KEYWORD는 도메인에 지정한 문자열이 포함되어 있는지 확인합니다. 세 조건 모두 도메인 정보를 기준으로 매칭하며 웹페이지 제목이나 내용, URL 경로를 확인하지 않습니다.

규칙 예시	매칭됨	매칭되지 않음
`DOMAIN,example.com,DIRECT`	`example.com`	`api.example.com`
`DOMAIN-SUFFIX,example.com,DIRECT`	`example.com`、`api.example.com`	`notexample.com`、`example.com.test`
`DOMAIN-KEYWORD,example,DIRECT`	`api.example.com`、`notexample.com`	`example.org` 및 이 문자열이 포함되지 않은 도메인(예: `sample.test`)은 매칭되지 않습니다.

DOMAIN-SUFFIX를 선택하면 example.com만 입력하면 됩니다. *.를 덧붙일 필요가 없습니다. 이 규칙은 도메인 경계를 기준으로 접미사를 인식하며 단순히 문자열 끝부분만 비교하지 않습니다. 반면 DOMAIN-KEYWORD,example,DIRECT는 훨씬 넓은 범위를 매칭해 대상 사이트와 관련 없는 도메인까지 포함할 수 있습니다. 특정 사이트 계열만 매칭하려면 범위가 명확한 접미사 조건을 우선 사용하세요.

같은 도메인의 /news와 /account 경로는 위 세 가지 조건으로 구분할 수 없습니다.
example.com:443에 접속하더라도 도메인 필드에는 example.com만 입력하세요. :443은 붙이지 않습니다.
IP 주소로 직접 접속할 때는 도메인 규칙이 반드시 매칭된다고 기대하지 마세요. 요청에 매칭 가능한 도메인 정보가 있는지 확인해야 합니다.

GEOIP와 IP-CIDR의 매칭 대상

GEOIP는 대상 IP가 지리 데이터베이스에서 어느 지역으로 분류되는지 기준으로 판단합니다. 예를 들어 GEOIP,CN,DIRECT는 데이터베이스에서 CN으로 식별한 대상 IP에 DIRECT를 적용한다는 뜻입니다. 도메인 접미사나 웹페이지 언어, 회사 등록 국가를 기준으로 판단하지 않으며, 특정 도메인의 모든 DNS 응답이 같은 지역에 속한다고 보장하지도 않습니다.

IP-CIDR는 IPv4 주소 범위를 직접 지정합니다. 슬래시 뒤의 숫자는 프리픽스 길이입니다. /32는 IPv4 주소 하나를, /24는 주소 256개를 가리킵니다. 아래에서는 문서 예시 전용 주소 대역으로 문법을 설명하며, 실제 서비스 주소는 아닙니다.

IP-CIDR,192.0.2.7/32,DIRECT
IP-CIDR,198.51.100.0/24,PROXY
GEOIP,CN,DIRECT
FINAL,PROXY

192.0.2.7/32는 192.0.2.7만 포함하며 192.0.2.8은 포함하지 않습니다.
198.51.100.0/24의 주소 범위는 198.51.100.0부터 198.51.100.255까지입니다.
IPv6 범위에는 해당하는 IP-CIDR6 유형을 사용해야 합니다. IPv6 주소를 IPv4용 IP-CIDR 예시에 그대로 적용할 수 없습니다.
도메인 요청에서 IP 조건을 판단하기 전에 DNS 조회가 필요한지는 구성의 해석 방식에 따라 달라집니다. DNS 조회 실패와 규칙 미매칭은 서로 다른 문제입니다.

일부 IP 조건에는 no-resolve를 지정할 수 있습니다. 예: IP-CIDR,192.0.2.0/24,DIRECT,no-resolve. 이 옵션은 해당 규칙을 평가하기 위해서만 도메인 조회를 시작하지 않도록 합니다. 전역 DNS를 끄는 설정은 아닙니다. 당시 사용할 수 있는 대상 IP가 없다면 도메인을 조회해 이 규칙에 매칭되기를 기대할 수 없습니다. 문제를 확인할 때는 기존 구성의 관련 옵션을 유지하고 한꺼번에 추가하거나 삭제하지 마세요.

위에서 아래로 순서대로 매칭하고 FINAL은 마지막에 배치

이 글에서 다루는 일반 규칙은 위에서 아래로 확인합니다. 규칙에 매칭되면 해당 줄의 정책을 적용하며, 뒤에 더 ‘정확한’ 조건이 있더라도 자동으로 바뀌지 않습니다. 따라서 규칙 유형 이름이 우선순위를 정하지는 않습니다. DOMAIN이 앞에 있는 DOMAIN-SUFFIX보다 자동으로 우선 적용되는 것은 아닙니다.

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

api.example.com 요청은 첫 번째 줄에 매칭되어 PROXY를 사용합니다.
www.example.com 요청은 첫 번째 줄에 매칭되지 않고 두 번째 줄에 매칭되어 DIRECT를 사용합니다.
대상 IP가 192.0.2.8이고 앞선 도메인 규칙에 매칭되지 않았다면 예시의 IP 대역 규칙에 매칭될 수 있습니다.
다른 연결은 계속 GEOIP 규칙을 확인합니다. 여전히 매칭되지 않으면 FINAL,PROXY로 처리합니다.

앞의 두 줄 순서를 바꾸면 api.example.com이 먼저 접미사 규칙에 매칭되어, 유지하려던 단일 도메인 예외가 적용되지 않습니다. 마찬가지로 FINAL은 조건 없이 적용되는 기본 규칙이므로 맨 끝에 두세요. 그 뒤에 일반 규칙을 배치해도 이미 결정된 결과는 바뀌지 않습니다. 앞선 규칙 순서 오류를 FINAL을 하나 더 추가하는 방식으로 해결하지 마세요.

요점: 예외를 먼저, 넓은 범위는 다음에

특정 하위 도메인에 다른 정책을 적용하려면 해당 DOMAIN 조건을 관련 DOMAIN-SUFFIX보다 앞에 배치하세요. 저장한 뒤 그 하위 도메인과 다른 일반 하위 도메인을 각각 테스트해 두 경로가 실제로 분리되는지 확인합니다.

다섯 단계로 수정 및 확인

다음 절차는 사용자가 직접 보유한 서버 또는 구독이 있고 기본 연결을 설정할 수 있다는 전제입니다. 규칙 파일과 Home의 서버 목록은 용도가 다릅니다. 서버 정보를 업데이트해도 편집 중인 규칙 파일이 전환되는 것은 아닙니다. 마찬가지로 라우팅을 수정해도 유효하지 않은 연결 인증 정보가 복구되지는 않습니다.

구성 백업

Config로 이동해 현재 구성의 사본을 먼저 보관하고 사용 중인 파일 이름을 기록하세요. 원격 구성을 사용하는 경우 이후 업데이트가 로컬 수정 사항을 덮어쓰는지도 확인합니다.
모드 확인

Home → Global Routing에서 Config를 선택하고 Config에서 선택된 파일이 테스트하려는 파일인지 확인하세요. Home에서 기본 서버 선택도 확인합니다.
한 번에 하나만 변경

Config에서 대상 구성의 편집 기능을 열고 텍스트 편집으로 이동해 [Rule]을 찾습니다. 확인된 대상의 DOMAIN 규칙 한 줄만 추가하거나 순서 한 곳만 조정한 다음 변경 내용을 저장하세요.
연결 다시 설정

저장한 뒤 VPN 연결을 다시 설정하고 테스트 앱에서 새 요청을 보냅니다. 기존의 장시간 연결은 이전 경로를 계속 사용할 수 있으므로 같은 페이지를 반복해서 새로고침해도 새 연결이 만들어지지 않을 수 있습니다.
결과 비교

연결 기록에 표시되는 대상, 정책, 오류 정보를 확인해 실제 결과를 비교하세요. Connectivity Test는 기본 연결 상태를 확인하는 데 도움이 되지만 특정 웹사이트 요청이 어느 규칙에 매칭됐는지 단독으로 증명하지는 못합니다.

규칙은 맞게 매칭되는데 접속에 실패할 때

규칙에 매칭되었다는 것은 연결 경로가 선택되었다는 뜻일 뿐, 해당 경로로 대상에 성공적으로 도달할 수 있다는 뜻은 아닙니다. ‘정책이 올바르게 선택되었는지’를 먼저 확인한 다음 ‘선택된 경로를 사용할 수 있는지’를 살펴보세요. 아래 오류는 연결 진단 중 나타날 수 있는 시스템 오류 원문이며, 규칙 파서가 항상 표시하는 고정 오류는 아닙니다. 표시 위치와 전체 설명은 연결 유형에 따라 다를 수 있습니다.

오류: Connection refused

원인: 대상 또는 중간 장비가 연결을 적극적으로 거부했습니다. 서비스가 포트를 열어 두지 않았거나 포트 입력이 잘못되었을 수 있습니다. 이 오류만으로 DOMAIN 문법이 잘못되었다고 볼 수는 없습니다.

해결: 먼저 기록에 표시된 실제 연결 대상을 확인하세요. PROXY를 사용한다면 직접 보유한 서버의 주소와 포트를 확인하고, DIRECT를 사용한다면 대상 서비스가 해당 포트의 접속을 허용하는지 확인합니다.

오류: Operation timed out

원인: 제한 시간 안에 연결이 완료되지 않았습니다. 서버에 연결할 수 없거나 대상이 응답하지 않거나 네트워크에서 데이터가 차단되었을 수 있습니다. 시간 초과만으로 원인이 된 규칙을 판단할 수는 없습니다.

해결: 먼저 최종 적용 정책을 확인하고 같은 네트워크에서 기본 연결 상태를 테스트하세요. 구성을 그대로 유지한 채 항목별로 확인하고 DNS, 서버, 규칙 순서를 동시에 바꾸지 마세요.

오류는 없지만 정책이 예상과 다를 때

모든 요청이 같은 경로를 사용함: Home → Global Routing으로 돌아가 Proxy나 Direct가 선택된 것은 아닌지 확인하고 현재 사용 중인 구성도 확인하세요.
단일 도메인 예외가 적용되지 않음: 해당 규칙보다 앞에서 더 넓은 DOMAIN-SUFFIX, DOMAIN-KEYWORD 또는 FINAL이 먼저 매칭되는지 확인하세요.
IP 규칙이 매칭되지 않음: 실제 대상이 IPv6인지, DNS 응답이 바뀌었는지, 해당 규칙에 no-resolve가 지정되어 있는지 확인하세요.
한 페이지에 여러 정책이 적용됨: 페이지가 메인 사이트, 이미지, API 등 여러 도메인에 동시에 연결할 수 있습니다. 페이지 전체를 하나의 연결로 보지 말고 요청별로 확인하세요.
저장 후에도 결과가 달라지지 않음: 수정한 파일이 선택되어 있는지 확인한 뒤 테스트 연결을 다시 설정하세요. 이전 연결의 결과를 새 규칙의 검증 결과로 간주하지 마세요.

테스트가 끝나면 임시 규칙을 삭제하거나 필요한 범위로 명확히 조정한 뒤 백업을 저장하세요. 최소한의 확인 기록에는 대상 도메인, 실제 대상 IP, 예상 정책, 실제 정책, 오류 원문이 포함되어야 합니다. 이 정보가 있어야 매칭 범위, 규칙 순서, 네트워크 연결 상태 중 어떤 문제가 원인인지 구분할 수 있습니다.