2026-08-21 · 규칙과 라우팅 · 약 8분

Shadowrocket 규칙 작성법: DOMAIN, DOMAIN-SUFFIX, GEOIP, IP-CIDR, FINAL 매칭 로직

6가지 규칙 키워드의 매칭 대상과 범위를 설명하고, 규칙은 위에서 아래로 검사해 처음 일치하는 항목에서 멈추는 방식과 FINAL을 마지막에 두어야 하는 이유를 안내합니다.

이 글 미리보기

Shadowrocket 규칙은 요청이 조건에 맞는지 먼저 확인한 뒤 적용할 정책을 결정합니다. 사용할 서비스 정보를 이미 보유하고 있고 Config를 편집하려는 사용자를 위한 글입니다. 먼저 6가지 키워드를 이해하고, 구체적인 예외를 앞에, 넓은 범위의 규칙을 뒤에, FINAL을 맨 마지막에 배치한 다음 새 연결로 결과를 확인하세요. 예시는 문법과 매칭 범위만 설명하며 서비스 정보는 제공하지 않습니다.

1. 규칙 형식: 매칭 유형, 매칭 값, 처리 정책

일반적인 규칙은 구성 파일의 [Rule] 섹션에 작성합니다. FINAL 같은 특수 형식을 제외하면 한 줄은 보통 키워드, 매칭 값, 정책으로 구성되며 각 항목은 영문 쉼표로 구분합니다. 도메인 매칭 값에는 호스트명만 입력하고 프로토콜 접두사, 웹 경로, 포트는 넣지 않습니다.

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

여기서 DIRECT는 직접 연결, PROXY는 프록시 정책으로 전달, REJECT는 일치한 요청을 거부한다는 뜻입니다. 규칙은 요청을 처리할 방향만 정하며 서버를 만들거나 인증 정보를 채워 주지는 않습니다. PROXY를 사용하기 전에 Home에서 보유 중인 서버와 연결 가능 여부를 확인하세요. 사용자 지정 정책 그룹을 사용한다면 규칙 끝의 이름이 구성에 정의된 이름과 일치해야 합니다.

6가지
이 글에서 다루는 규칙 키워드이며, 지원되는 유형 전체를 뜻하지는 않습니다
3개 항목
일반 형식: 키워드, 매칭 값, 정책
2개 항목
기본 처리 형식: FINAL, 정책

핵심: 먼저 매칭 대상을 정확히 지정하세요

호스트명 하나만 처리하려면 DOMAIN을 사용하세요. 도메인 전체와 하위 도메인까지 포함해야 할 때만 DOMAIN-SUFFIX로 범위를 넓히고, 처음부터 범위가 넓은 키워드 매칭을 사용하지 마세요.

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

이 세 가지 규칙은 모두 도메인을 대상으로 하지만 매칭 범위가 다릅니다. DOMAIN은 전체 호스트명이 일치하는지 확인하고, DOMAIN-SUFFIX는 지정한 도메인 자체와 하위 도메인을 매칭합니다. DOMAIN-KEYWORD는 도메인에 지정 문자열이 포함되어 있는지 확인합니다. 웹 주소를 필터링하는 규칙이 아니므로 /video/ 같은 경로로 같은 호스트의 페이지를 구분할 수는 없습니다.

규칙 예시매칭됨매칭되지 않거나 주의할 점
DOMAIN,example.com,PROXYexample.comwww.example.com은 포함하지 않음
DOMAIN-SUFFIX,example.com,PROXYexample.com、www.example.com、a.b.example.comnotexample.com과는 매칭되지 않음
DOMAIN-KEYWORD,example,PROXYexample.com、myexample.net대상 웹사이트와 무관한 도메인까지 포함될 수 있음

예를 들어 로그인 API만 직접 연결하고 같은 도메인의 다른 요청은 프록시로 보내려면 DOMAIN,account.example.com,DIRECT를 DOMAIN-SUFFIX,example.com,PROXY보다 앞에 배치할 수 있습니다. 여기서 중요한 것은 순서이며, 전체 도메인 규칙이 자동으로 더 높은 우선순위를 갖는 것은 아닙니다.

3. GEOIP와 IP-CIDR: 대상 IP의 지역과 주소 대역으로 매칭

GEOIP는 지리 데이터베이스에서 대상 IP가 어느 지역에 속하는지 확인해 매칭합니다. 예를 들어 GEOIP,CN,DIRECT는 데이터베이스에서 CN으로 판정한 대상 주소를 DIRECT로 처리한다는 뜻입니다. 웹페이지 언어나 도메인 접미사, 서버 운영자의 소재지를 기준으로 판단하는 규칙은 아닙니다. 데이터베이스의 정보도 실제 위치를 실시간으로 나타내지는 않습니다.

IP-CIDR은 IPv4 주소 대역을 기준으로 매칭합니다. 192.168.1.0/24는 192.168.1.0부터 192.168.1.255까지 포함하며, 규칙 범위를 설명하는 예시입니다. 실제 로컬 네트워크에서 기기에 할당할 수 있는 주소는 네트워크 설정에 따라 달라집니다. IPv6 주소 대역에는 IP-CIDR6을 사용해야 하며, IPv6 주소를 IPv4 예시에 넣으면 안 됩니다.

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

도메인 규칙과 IP 규칙을 함께 사용할 때는 명확한 도메인 예외를 먼저 쓰고, 범위가 넓은 IP 지역 규칙을 뒤에 배치하세요. 그러면 주소 해석 결과의 지역에 따라 요청이 의도치 않게 다른 정책에 먼저 매칭되는 일을 줄일 수 있습니다. 같은 도메인도 DNS가 반환하는 주소가 달라질 수 있으므로 GEOIP 결과도 대상 주소에 따라 달라질 수 있습니다.

4. 위에서 아래로 검사하고 첫 매칭에서 종료: FINAL을 마지막에 두는 이유

일반적인 선형 규칙 목록에서는 요청을 순서대로 검사하고, 한 규칙에 매칭되면 해당 정책을 적용한 뒤 더 정확한 규칙을 찾아 계속 검사하지 않습니다. FINAL에는 도메인이나 주소 조건이 없습니다. 앞선 규칙에 매칭되지 않은 요청을 처리하므로 규칙 목록의 마지막에 배치해야 합니다.

[Rule]
DOMAIN,account.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.1.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,DIRECT
  1. account.example.com에 접속하면 첫 번째 줄에 매칭되어 DIRECT가 적용되고, 뒤의 접미사 규칙은 더 이상 검사하지 않습니다.
  2. images.example.com에 접속하면 첫 번째 줄은 매칭되지 않고 두 번째 줄에 매칭되어 PROXY가 적용됩니다.
  3. 대상 주소 192.168.1.20에 접속하면 로컬 네트워크 주소 대역에 매칭되어 DIRECT가 적용됩니다.
  4. 그 밖의 요청은 GEOIP 규칙을 먼저 확인합니다. 그래도 매칭되지 않으면 마지막에 지정한 DIRECT가 FINAL로 적용됩니다.

접미사 규칙을 전체 도메인 예외보다 앞에 두면 account.example.com도 먼저 매칭되어 PROXY로 처리됩니다. FINAL,DIRECT를 맨 앞에 두면 일반 요청을 뒤의 규칙이 처리할 기회가 없습니다. 지정한 웹사이트만 프록시로 보내려면 도메인 규칙으로 대상을 나열한 뒤 FINAL,DIRECT로 마무리하세요. 나머지 요청도 프록시로 보내려면 FINAL,PROXY로 지정해야 하며, 두 설정의 적용 범위는 다릅니다.

5. Config에서 규칙을 편집하고 새 연결에 적용하기

규칙을 파일에 작성했다고 해서 해당 파일이 바로 적용되는 것은 아닙니다. 현재 선택한 구성과 Home의 Global Routing을 함께 확인해야 합니다. 구성 파일에 따라 요청을 분류하려면 Config를 선택하세요. Proxy와 Direct는 이 글의 규칙 목록을 하나씩 검증하는 모드가 아닙니다. Scene은 장면 선택과 관련되므로 기본 규칙을 단독으로 테스트하기에는 적합하지 않습니다.

  1. 기존 구성 보존하기

    Config로 이동해 현재 파일의 사본이나 원본 텍스트를 먼저 보관하세요. 편집하려는 파일이 현재 사용 중인 파일인지, 이름만 같은 다른 구성 파일은 아닌지 확인합니다.

  2. 규칙 섹션 편집하기

    Config에서 대상 파일을 선택하고 Edit Plain Text로 들어가 [Rule]을 찾습니다. 구체적인 예외를 앞에 배치하고, 필요한 FINAL 기본 처리 규칙만 마지막에 둡니다. 파일에 있는 다른 필수 구성 섹션은 그대로 유지하세요.

  3. 저장하고 선택하기

    수정 내용을 저장한 뒤 Config로 돌아와 방금 편집한 파일이 선택되어 있는지 확인하세요. 원격 구성을 다시 업데이트하면 로컬 수정 사항이 덮어써질 수 있으므로 테스트 전에 추가한 규칙 텍스트를 보관하세요.

  4. 모드 확인하기

    Home → Global Routing → Config로 이동한 뒤 사용 중인 프록시 서버도 확인하세요. 구독 업데이트는 기존 서비스 정보를 갱신하는 기능이며, 로컬 규칙을 대신 작성하거나 활성화해 주지는 않습니다.

  5. 새 연결로 확인하기

    저장한 뒤 연결을 다시 설정하고 대상 요청을 새로 보내세요. 연결 기록에서 대상 호스트, 대상 IP, 실제 적용된 정책을 확인합니다. 페이지가 열리는지만으로 규칙 매칭 여부를 판단하지 마세요.

검증할 때는 한 번에 조건 하나만 변경하세요. 먼저 전체 도메인 하나에 DIRECT를 적용해 결과를 확인한 뒤 DOMAIN-SUFFIX로 범위를 넓힙니다. 브라우저 캐시, 기존 장시간 연결, 웹사이트의 다른 리소스 도메인이 결과에 영향을 줄 수 있습니다. 새 요청으로 실제 네트워크 연결이 발생해야 하며, 캐시된 페이지가 표시되는 것만으로는 새 규칙의 적용을 확인할 수 없습니다.

6. 규칙 미적용과 네트워크 오류를 구분해 확인하기

웹페이지가 열리지 않는다고 해서 반드시 규칙 문법이 잘못된 것은 아닙니다. 먼저 요청에 실제로 어떤 정책이 적용됐는지 확인한 다음 DNS와 연결 과정을 점검하세요. 아래는 Apple 네트워크 계층에서 반환될 수 있는 영문 오류 설명입니다. 앱이나 시스템에서 현지화된 문구로 표시될 수 있으므로 Shadowrocket에서 매번 같은 문구를 확인할 수 있는 것은 아닙니다.

오류: The request timed out.

원인 및 해결 방법: 제한 시간 안에 요청이 완료되지 않았습니다. 대상에 연결할 수 없거나 선택한 서버의 연결 상태에 문제가 있을 수 있습니다. 먼저 연결 기록에서 DIRECT 또는 PROXY 중 어떤 정책이 적용됐는지 확인하고 해당 연결 경로를 각각 점검하세요. 규칙 범위를 곧바로 넓히지는 마세요.

오류: A server with the specified hostname could not be found.

원인 및 해결 방법: 대상 호스트명을 해석하지 못했습니다. 도메인 철자와 현재 구성의 DNS 설정을 먼저 확인하세요. 도메인 해석이 복구된 뒤 GEOIP 또는 IP-CIDR 매칭에 필요한 대상 주소를 사용할 수 있는지 확인합니다.

확인된 현상우선 확인할 항목다음 단계
모든 요청이 같은 정책을 따름Global Routing이 Config인지, FINAL이 실수로 맨 위에 배치되지는 않았는지 확인모드나 순서를 수정한 뒤 새 연결 설정
기본 사이트는 예상대로지만 이미지 요청은 다르게 처리됨이미지 요청이 다른 호스트명을 사용하는지 확인연결 기록에서 실제 리소스 도메인을 확인해 규칙에 추가하고, 무작정 키워드를 사용하지 않기
전체 도메인 예외가 매칭되지 않음앞에 범위가 더 넓은 DOMAIN-SUFFIX 또는 DOMAIN-KEYWORD가 있는지 확인구체적인 예외를 범위가 넓은 규칙보다 앞에 배치
도메인 요청에서 IP 규칙이 매칭되지 않음대상 IP를 사용할 수 있는지, no-resolve를 사용 중인지 확인DNS 해석 문제와 규칙 조건 불일치를 구분

핵심: 새 요청으로 세 항목 확인하기

변경할 때마다 대상 호스트, 실제 적용된 정책, 해당 규칙의 순서를 기록하세요. 요청이 예상한 정책을 따르는지 확인한 뒤 해당 연결 경로의 문제를 점검합니다. 연결 실패와 규칙 미매칭을 혼동하지 마세요.

App Store 정품 확인