2026-10-14 · 규칙 심화 · 약 12분

Shadowrocket 규칙 작성법: DOMAIN-SUFFIX·GEOIP·IP-CIDR·FINAL 매칭 이해하기

DOMAIN, DOMAIN-SUFFIX, DOMAIN-KEYWORD, GEOIP, IP-CIDR, FINAL의 매칭 대상과 규칙 적용 순서, 자주 하는 작성 실수를 알아봅니다.

이 글 미리 보기

이 글은 Shadowrocket에 사용할 연결 구성을 저장해 두었고, 트래픽 분기 결과를 확인하려는 사용자를 위한 안내입니다. 먼저 Home → Global Routing에서 Config를 선택했는지 확인한 다음, 도메인 규칙과 주소 규칙을 구분하고 연결 기록을 살펴보세요. example.com과 문서용 예약 주소는 문법 설명을 위한 예시일 뿐, 연결 서비스가 아닙니다. 글을 읽고 규칙 필드를 파악해 순서를 정리하면 규칙을 작성했는데도 적용되지 않는 원인을 찾는 데 도움이 됩니다.

1. 규칙 매칭을 살피기 전에 Global Routing 확인하기

규칙 파일이 있다고 해서 현재 연결이 그 파일에 따라 트래픽을 분기하는 것은 아닙니다. Home에서는 연결과 선택한 아웃바운드를 관리하고, Config에서는 구성 파일을, Settings에서는 앱 설정을 관리합니다. 문제를 살피기 전에 Home → Global Routing에서 현재 선택된 항목을 기록하고 Config에서 사용 중인 파일을 확인하세요. 파일을 받아 둔 것과 활성화한 것을 같은 단계로 보지 마세요.

Global Routing 선택 항목확인할 점규칙을 점검할 때
Proxy트래픽을 프록시 라우팅으로 처리하며 Config의 일반 분기 규칙에 따라 경로를 선택하지 않음특정 DOMAIN-SUFFIX 규칙이 매칭됐다는 근거로 볼 수 없음
Direct트래픽을 직접 연결 방식으로 처리함테스트를 위해 임시로 변경한 뒤 Config로 되돌리지 않았는지 확인
Config현재 구성 파일을 기준으로 규칙을 매칭함이 글의 규칙 테스트에서 사용할 선택 항목
Scene설정된 Scene 조건에 따라 라우팅 동작을 결정함파일 내용만 보지 말고 Scene 조건과 실제 적용된 라우팅을 함께 확인

Settings → On Demand에서는 조건에 따라 연결을 설정하는 동작을 관리하며, 규칙 목록의 우선순위를 바꾸지 않습니다. 시스템에 VPN 연결됨으로 표시되더라도 터널이 연결된 상태라는 뜻일 뿐입니다. 특정 요청이 프록시를 거쳤는지는 라우팅 방식, 매칭된 규칙, 최종 정책을 함께 확인해야 합니다.

2. 규칙 한 줄 읽기: 유형, 매칭 값, 정책

일반적으로 규칙의 각 항목은 영문 쉼표로 구분합니다. DOMAIN-SUFFIX,example.com,DIRECT를 예로 들면 첫 번째 항목은 매칭 방식을, 두 번째 항목은 대상을, 세 번째 항목은 매칭 후 처리 방식을 나타냅니다. 구성 파일의 일반 규칙은 [Rule] 섹션에 작성합니다. 파일의 섹션을 확인하지 않고 규칙 한 줄을 맨 끝에 임의로 붙이지 마세요.

[Rule]
DOMAIN,login.example.com,DIRECT
DOMAIN-SUFFIX,example.com,DIRECT
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
FINAL,DIRECT

이 예시는 문법을 보여 주기 위한 것이며 모든 사용 사례를 충족하는 완전한 구성은 아닙니다. 192.0.2.0/24는 문서용 예시 네트워크입니다. 모든 규칙을 DIRECT로 지정한 것은 프록시 정책을 따로 정의하지 않고 매칭 동작을 먼저 살펴보기 위해서입니다. 기존 구성을 이 내용으로 덮어쓰지 마세요.

예를 들어 브라우저에서 https://docs.example.com:443/help에 접속할 때 도메인 규칙이 확인하는 값은 docs.example.com입니다. 여기서 443은 연결 포트이고 /help는 URL 경로입니다. 둘 다 DOMAIN-SUFFIX의 매칭 값이 아닙니다. 프로토콜 연결 매개변수와 트래픽 분기 규칙은 서로 다른 계층이므로 도메인 필드에 프로토콜 이름을 입력하지 마세요.

3. DOMAIN, DOMAIN-SUFFIX, DOMAIN-KEYWORD의 차이

세 키워드는 모두 도메인을 기준으로 매칭하지만 범위가 다릅니다. 특정 도메인만 예외 처리하려면 DOMAIN을 먼저 고려하고, 해당 도메인과 하위 도메인 전체를 포함하려면 DOMAIN-SUFFIX를 사용하세요. DOMAIN-KEYWORD는 범위가 더 넓으므로 같은 문자열이 들어간 다른 도메인까지 포함되지 않는지 확인해야 합니다.

규칙 예시매칭되는 항목매칭되지 않는 항목
DOMAIN,example.com,DIRECTexample.comwww.example.com
DOMAIN-SUFFIX,example.com,DIRECTexample.com、www.example.comnotexample.com、example.com.other.test
DOMAIN-KEYWORD,example,DIRECTexample.com、myexample.testsample.test

DOMAIN-SUFFIX는 도메인 단계의 경계를 기준으로 매칭하며, 문자열의 임의의 끝부분을 찾는 방식이 아닙니다. 보통 example.com을 그대로 입력하면 되며 *.를 붙일 필요가 없습니다. 대상이 api.example.com 하나뿐이라면 DOMAIN을 사용해 같은 도메인에 속한 다른 호스트까지 포함되지 않도록 할 수 있습니다.

4. IP-CIDR, GEOIP와 DNS의 관계

IP-CIDR은 대상 IP 주소가 지정된 네트워크 범위에 속하는지 매칭하며, 도메인 문자열을 매칭하지 않습니다. 192.0.2.0/24는 해당 IPv4 네트워크를, 192.0.2.18/32는 단일 IPv4 주소를 나타냅니다. 접두사 숫자는 포트도 우선순위도 아닙니다. 숫자가 클수록 일반적으로 네트워크 범위가 작지만, 목록에서 자동으로 앞에 배치되는 것은 아닙니다.

IP-CIDR,192.0.2.18/32,DIRECT,no-resolve
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,DIRECT

GEOIP는 주소 데이터베이스에 기록된 대상 IP의 위치 정보를 기준으로 매칭합니다. 예를 들어 GEOIP,CN,DIRECT는 데이터베이스에서 CN으로 분류된 주소를 대상으로 합니다. 중국어 웹페이지를 매칭하는 것도, 도메인이 .cn으로 끝나는지 확인하는 것도 아닙니다. 콘텐츠 전송 방식, 주소 변경, 데이터베이스 정보에 따라 실제 결과는 웹사이트 이름만 보고 예상한 것과 다를 수 있습니다.

따라서 도메인이 특정 지역에 속해 보인다고 해서 GEOIP 규칙이 매칭된다고 단정할 수는 없습니다. 먼저 실제 대상을 확인한 뒤 DNS 조회 결과와 데이터베이스 판정을 살펴보세요. 아직 판정에 필요한 주소를 얻지 못했다면 no-resolve가 붙은 IP 규칙은 매칭되지 않고, 트래픽이 다음 규칙으로 넘어갈 수 있습니다.

5. 위에서 아래로 매칭: 구체적인 예외를 먼저, FINAL은 마지막에

일반 규칙은 구성에 적힌 순서대로 확인하며, 매칭되면 해당 정책을 적용하고 더 구체적인 규칙을 찾으려고 아래로 계속 진행하지 않습니다. DOMAIN이 DOMAIN-SUFFIX보다 자동으로 우선하는 것도 아니고, 단일 주소 규칙이 넓은 네트워크 규칙보다 자동으로 우선하는 것도 아닙니다. 예외를 먼저 적용하려면 적용 범위가 넓은 규칙보다 위에 작성해야 합니다.

요청 진입대상 확인규칙 순차 매칭정책 결정연결 설정 
[Rule]
DOMAIN,login.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
GEOIP,CN,DIRECT
FINAL,PROXY

이 예시는 현재 구성에 사용할 수 있는 PROXY 정책이 있다는 전제입니다. login.example.com에 접속하면 첫 번째 규칙이 매칭되어 직접 연결됩니다. img.example.com에 접속하면 첫 번째 규칙은 매칭되지 않고 두 번째 규칙이 매칭되어 PROXY로 전달됩니다. 두 번째 규칙을 첫 번째 규칙보다 위로 옮기면 로그인 도메인도 먼저 접미사 규칙에 매칭되므로, 뒤에 있는 구체적인 예외가 적용되지 않습니다.

  1. 로그인 도메인 하나처럼 명확한 호스트 예외를 먼저 배치하세요.
  2. 그다음 도메인 접미사, 키워드 또는 필요에 따라 정리한 다른 규칙을 배치하고, 규칙끼리 적용 범위가 겹치는지 살펴보세요.
  3. 주소 규칙을 배치할 때는 매칭을 위해 주소 조회를 허용할지, 뒤에 오는 규칙의 적용 범위를 덮어쓰지 않는지 확인하세요.
  4. 앞선 규칙이 모두 매칭되지 않을 때의 최종 처리 방식으로 FINAL을 맨 뒤에 배치하세요.

FINAL은 연결 실패 시 사용하는 대체 연결이 아닙니다. 규칙이 PROXY에 매칭된 뒤 해당 연결이 시간 초과되더라도 FINAL로 넘어가지 않습니다. 연결 실패 후 전환 방식은 사용하는 정책 그룹과 설정에 따라 달라지며, FINAL 뒤에 규칙을 추가해 구현할 수 없습니다.

6. 백업부터 확인까지: 규칙을 한 번에 하나씩 수정하기

아래 단계는 사용자가 자신의 연결 구성을 이미 가지고 있다는 전제입니다. 수정 전에 원본 파일을 보관하고, 대상이 분명한 도메인 규칙 하나부터 확인한 뒤 여러 규칙을 정리하세요. 원격 구성 업데이트로 로컬 변경 사항이 덮어써질 수 있으므로 직접 편집한 사본과 나중에 다시 가져올 파일을 구분해야 합니다.

  1. 원본 구성 보관

    Config에서 현재 사용 중인 구성 파일을 확인하고 복원할 수 있는 사본을 보관하세요. 기존 Global Routing 선택 항목과 대상 규칙의 순서를 기록하고, 규칙 섹션 전체를 먼저 삭제하지 마세요.

  2. 규칙 섹션 수정

    Config에서 수정할 파일의 편집 기능을 열고 [Rule]을 찾아 직접 테스트할 도메인에 대한 DOMAIN 규칙을 하나 추가하세요. 저장한 뒤 수정한 파일이 현재 활성화되어 있는지 확인합니다. 편집 메뉴의 표시는 앱 내 화면을 기준으로 확인하세요.

  3. 라우팅 확인

    Home → Global Routing → Config로 돌아가세요. 연결이 켜져 있고 연결된 프록시 정책에 사용 가능한 아웃바운드가 있는지 확인합니다. Scene을 사용한다면 Scene 설정도 기록해 두어, Scene 전환을 규칙 변경으로 잘못 판단하지 않도록 하세요.

  4. 새 요청 보내기

    대상 앱에서 새 연결을 만들고 연결 기록의 대상 도메인, 주소, 매칭된 규칙, 정책을 확인하세요. 기존에 오래 유지된 연결은 원래 경로를 계속 사용할 수 있으므로 파일을 저장했다고 기존 연결이 즉시 다시 만들어지는 것은 아닙니다.

  5. 결과를 대조한 뒤 복원

    실제 결과를 예상과 항목별로 비교하세요. 먼저 어떤 규칙이 매칭됐는지 확인한 다음 연결 성공 여부를 살펴봅니다. 테스트가 끝나면 임시 규칙을 삭제하거나 원본 파일을 복원하고, Global Routing도 원래 선택으로 되돌리세요.

Home의 지연 시간 테스트만으로 규칙이 올바르다고 판단해서는 안 됩니다. 지연 시간 테스트는 선택한 아웃바운드의 테스트 대상을 확인하지만, 브라우저 요청은 다른 도메인과 주소, 포트를 사용할 수 있습니다. 설정을 계속 바꾸기보다 대상 도메인, 대상 포트, 매칭 규칙, 최종 정책, 오류 현상을 기록해 두면 문제를 재현하기 쉽습니다.

7. 연결 오류와 규칙 오류를 나누어 확인하기

아래는 네트워크 진단에서 자주 볼 수 있는 영문 오류 메시지입니다. 실제 화면에는 더 자세한 맥락이 표시될 수 있으며, 매번 같은 문구가 나온다고 단정할 수 없습니다. 먼저 요청에 어떤 규칙이 매칭됐는지 확인한 다음 선택된 경로를 따라 문제를 살펴보세요. 시간 초과가 발생했다고 모든 요청의 정책을 곧바로 하나로 바꾸지 마세요.

오류: Connection refused

원인과 해결 방법: 일반적으로 대상 포트나 연결 경로에서 연결을 거부한 경우입니다. 먼저 DIRECT와 프록시 정책 중 무엇이 매칭됐는지 확인한 다음 해당 대상 주소와 포트, 기존 연결 구성을 살펴보세요. DOMAIN-SUFFIX를 추가해도 포트에서 서비스가 제공되지 않는 문제는 해결되지 않습니다.

오류: Operation timed out

원인과 해결 방법: 제한 시간 안에 작업을 완료하지 못했다는 뜻이며, 주소 조회나 연결 설정, 이후 통신 단계에서 문제가 생겼을 수 있습니다. 연결 기록을 통해 어느 단계에서 실패했는지 먼저 확인한 다음 DNS, 아웃바운드 연결 가능 여부, 대상 포트를 각각 점검하세요. 모든 시간 초과를 규칙 문법 문제로 단정하지 마세요.

파일을 정상적으로 저장하거나 불러올 수 없다면 섹션 이름, 영문 쉼표, 정책 이름, 필드 개수를 먼저 확인하세요. 파일은 사용할 수 있지만 잘못된 규칙이 매칭된다면 순서와 매칭 범위를 살펴보세요. 올바른 규칙이 매칭됐는데도 접속할 수 없을 때 연결 경로를 확인하면 됩니다. 각 단계의 해결 방향은 서로 다릅니다.

DOMAIN-SUFFIX를 추가했는데 왜 기존 경로로 연결되나요?

먼저 Home → Global Routing → Config를 확인하고 Config에서 수정한 파일이 활성화되어 있는지 확인하세요. 그다음 해당 규칙 위에 같은 도메인에 적용되는 규칙이 있는지 살펴보고, 이전 연결이 아닌 새 연결로 테스트하세요.

FINAL을 맨 위에 두면 어떻게 되나요?

FINAL은 해당 규칙까지 도달한 요청을 최종 처리하므로, 뒤에 있는 일반 규칙은 그 요청을 판정할 기회가 없습니다. FINAL을 규칙 섹션 맨 아래로 옮긴 다음 DOMAIN 예외가 명확한 요청으로 다시 확인하세요.

규칙에 웹페이지 전체 주소를 그대로 입력해도 되나요?

DOMAIN과 DOMAIN-SUFFIX에는 전체 URL이 아닌 도메인을 입력합니다. https://docs.example.com/help를 호스트 docs.example.com으로 분리한 뒤 하위 도메인까지 포함할지에 따라 규칙 유형을 선택하세요. URL 경로는 이 규칙들의 매칭 대상이 아닙니다.

구성을 업데이트한 뒤 직접 추가한 규칙이 사라졌다면 어떻게 하나요?

Config에서 원격 파일을 다시 가져왔는지, 다른 파일로 전환했는지 확인하세요. 수정 전에 보관한 사본과 대조해 필요한 규칙을 복원한 다음 활성화된 파일을 확인합니다. Home의 연결 항목 업데이트와 Config의 규칙 파일 업데이트는 서로 다른 작업입니다.

App Store에서 정품 확인 →