Shadowrocket 규칙 작성법: DOMAIN-SUFFIX·DOMAIN-KEYWORD·GEOIP·IP-CIDR·FINAL 매칭 범위

1. 규칙의 기본 형식: 유형, 매칭 값, 정책

일반 매칭 규칙은 보통 규칙 유형, 매칭 값, 정책의 세 필드로 구성하며 영문 반각 쉼표로 구분합니다. 규칙은 설정 파일의 [Rule] 섹션에 넣습니다. FINAL은 매칭 값이 필요하지 않으므로 필드는 두 개만 작성합니다. 규칙을 계속 추가하기보다 먼저 형식을 확인한 다음 매칭 범위를 점검하면 문제를 더 쉽게 찾을 수 있습니다.

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

DIRECT는 직접 연결, PROXY는 프록시 정책 사용, REJECT는 매칭된 연결 거부를 뜻합니다. 정책 필드에는 설정에 실제로 등록된 정책 이름을 사용할 수도 있지만, 이름이 정확히 일치해야 합니다. 이 글에서는 정의되지 않은 정책 이름이 예시에 들어가지 않도록 내장 정책 키워드만 사용합니다.

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

이 세 가지 규칙은 웹페이지 전체 주소가 아니라 도메인을 확인합니다. https://, 포트, 경로가 포함된 URL이 아니라 example.com처럼 도메인만 입력해야 합니다. 웹페이지의 메인 화면, 이미지, API가 서로 다른 도메인에 접속할 수 있으므로 같은 페이지에 표시된다는 이유만으로 하나의 도메인 규칙이 모든 연결에 적용되지는 않습니다.

DOMAIN-SUFFIX는 도메인 계층의 경계를 기준으로 매칭하며, 임의 문자열의 끝부분을 찾는 방식이 아닙니다. 보통 example.com처럼 입력하고 *.example.com은 사용하지 않습니다. api.example.com만 따로 처리하려면 DOMAIN을 사용하면 범위를 명확히 지정할 수 있고 하위 도메인까지 함께 매칭되는 것도 방지할 수 있습니다.

DOMAIN-KEYWORD는 더 넓은 범위를 매칭합니다. example을 입력하면 대상 사이트뿐 아니라 같은 문자열이 포함된 다른 도메인도 매칭될 수 있습니다. 정규식은 아니므로 정규식 기호를 매칭 문법처럼 사용하지 마세요. 특정 도메인과 그 하위 도메인만 처리하려면 원하는 범위를 정확히 표현하는 접미사 규칙을 우선 사용하세요.

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

여기서는 api.example.com이 첫 번째 행에 매칭되고, 나머지 example.com 하위 도메인은 두 번째 행에 매칭됩니다. 세 번째 행은 아직 매칭되지 않은 요청의 도메인에 telemetry가 포함되어 있는지만 확인합니다. 이미 앞의 두 행에서 정책이 결정된 요청을 다시 처리하지 않습니다.

3. IP-CIDR와 GEOIP: URL 문자열이 아닌 대상 IP 확인

IP-CIDR는 IPv4 네트워크 대역을 기준으로 매칭합니다. 슬래시 뒤의 숫자는 포트가 아니라 네트워크 프리픽스 길이입니다. 192.168.1.0/24는 192.168.1.0부터 192.168.1.255까지의 주소 범위를 포함하며, /32는 IPv4 주소 하나만 나타냅니다. IPv6 대역에는 해당하는 IP-CIDR6 유형을 사용합니다.

[Rule]
IP-CIDR,192.168.1.0/24,DIRECT,no-resolve
IP-CIDR,192.0.2.8/32,DIRECT,no-resolve
IP-CIDR6,2001:db8::/32,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

192.0.2.8과 2001:db8::/32는 문서 예시용 주소이며 실제 서비스 주소가 아닙니다. 192.168.1.20:8080에 접속할 때 네트워크 대역 규칙은 192.168.1.20을 확인하며 포트 8080만 매칭하지 않습니다. CIDR 매칭 값에 포트 번호를 넣으면 서로 다른 조건을 혼동하게 됩니다.

도메인 요청을 IP 유형 규칙에 매칭하려면 확인할 대상 주소가 있어야 합니다. 규칙 매칭을 위해 DNS 조회가 실행되는지는 규칙 옵션과 요청 상황에 따라 달라집니다. no-resolve를 추가했을 때 사용할 수 있는 대상 IP가 없다면 해당 네트워크 대역 규칙을 도메인 전체에 적용되는 규칙으로 볼 수 없습니다. 특정 도메인에 안정적으로 적용하려면 명시적인 도메인 규칙을 추가하는 편이 확인하기 쉽습니다.

GEOIP의 결과는 사용 중인 IP 지리 데이터베이스에 따라 달라집니다. 한 도메인이 여러 주소로 해석될 수 있고 각 주소의 지역 정보도 바뀔 수 있으므로 DOMAIN-SUFFIX와는 용도가 다릅니다. 특정 도메인에 항상 같은 정책을 적용하려면 해당 도메인의 예외 규칙을 일반적인 GEOIP 규칙보다 앞에 배치하세요.

4. 위에서 아래로 매칭: FINAL을 마지막에 두는 이유

일반 규칙은 순서대로 확인하며 먼저 매칭된 규칙이 정책을 결정합니다. ‘더 구체적인 규칙이 자동으로 우선 적용되는’ 정렬 기능은 없습니다. 구체적인 예외를 먼저 두고 범위가 넓은 규칙을 뒤에 배치한 다음, 앞에서 매칭되지 않은 요청을 처리하도록 FINAL을 마지막에 둡니다.

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

• api.example.com: 먼저 DOMAIN에 매칭되어 DIRECT를 사용합니다. 다음 행에서 PROXY로 바뀌지 않습니다.
• www.example.com: 첫 번째 행에는 매칭되지 않고 두 번째 행에 매칭되어 PROXY를 사용합니다.
• 192.168.1.20에 직접 접속: 앞의 도메인 규칙 두 개에는 매칭되지 않고 로컬 네트워크 대역 규칙이 처리합니다.
• 그 밖의 대상: GEOIP 규칙을 계속 확인하고, 여전히 매칭되지 않으면 FINAL,PROXY가 처리합니다.

접미사 규칙을 첫 번째 행으로 옮기면 api.example.com이 먼저 매칭되어 아래에 있는 정확한 도메인 예외가 적용되지 않습니다. 마찬가지로 FINAL,DIRECT를 맨 위에 두면 뒤의 규칙은 정상적으로 매칭될 기회를 얻지 못합니다. 순서를 바꾼 뒤에는 이미 열린 페이지를 새로고침하는 데 그치지 말고 새 연결로 다시 확인하세요.

5. Config 수정 후 네 단계로 결과 확인

문제를 확인할 때는 한 번에 조건 하나만 바꾸세요. 현재 사용 중인 설정을 수정했는지 확인하고, Home의 라우팅 모드를 확인한 다음, 새 연결의 대상과 적용 정책을 살펴보세요. 상단의 연결 스위치가 켜져 있다는 사실만으로 지정한 규칙이 매칭되었다고 볼 수는 없습니다.

1. 기존 설정 저장

   Config에서 현재 사용 중인 파일을 확인하고 먼저 사본을 저장하세요. 해당 파일의 텍스트 편집 화면을 열어 [Rule] 섹션을 수정합니다. 규칙을 [Host]나 다른 섹션에 추가하지 마세요.

2. 정확한 규칙 추가

   필요한 DOMAIN 예외를 해당 DOMAIN-SUFFIX보다 앞에 두고, 파일 마지막의 FINAL은 그대로 유지하세요. 저장 후 Config에서 수정한 파일이 사용 중인지 확인합니다.

3. Config 선택

   Home → Global Routing → Config로 돌아가 연결 상태를 확인하세요. PROXY를 사용해야 한다면 먼저 Home → Connectivity Test에서 기존 서비스의 연결 상태를 확인합니다. 테스트 결과만으로 규칙이 매칭되었다고 증명할 수는 없습니다.

4. 새 연결 확인

   대상 요청을 다시 보내고 앱 내 연결 기록에서 실제 도메인, 대상 IP, 적용된 정책을 비교하세요. 페이지에서 여러 도메인에 접속한다면 각각 확인해야 합니다. 이미지 요청의 결과를 메인 페이지 요청의 결과로 판단하지 마세요.

기록에 표시된 대상이 예상한 도메인과 다르면 규칙 범위를 바로 넓히지 말고 리디렉션, API 도메인 또는 IP 직접 접속 여부부터 확인하세요. 요청이 기존 연결을 계속 사용한다면 관련 페이지나 앱을 닫은 뒤 다시 요청하고, 필요하면 Shadowrocket 연결을 다시 설정하세요. 같은 방식으로 재현할 수 있는 새 요청으로 확인해야 규칙 미매칭과 기존 연결이 아직 바뀌지 않은 상황을 구분할 수 있습니다.

6. 자주 하는 규칙 작성 실수와 규칙 외 오류

문법 오류, 매칭 범위 오류, 서비스 사용 불가는 서로 다른 문제입니다. 규칙은 적용할 정책을 결정할 뿐 구독 주소나 프록시 연결 설정을 수정하지 않습니다. 먼저 텍스트만으로 확인할 수 있는 문제를 살펴보고, 규칙과 무관한 가져오기 실패 안내는 별도로 처리하세요.

원격에서 관리되는 설정을 수정했다면 다시 업데이트할 때 로컬 변경 사항이 덮어써질 수 있습니다. 파일의 출처와 업데이트 방식을 확인하고 로컬 사본을 보관해, 규칙을 확인한 직후 업데이트 내용으로 다시 교체되지 않도록 하세요. 구독 항목 업데이트와 [Rule] 섹션 수정은 별개의 작업입니다. 규칙을 확인하는 대신 구독을 반복해서 업데이트하지 마세요.

7. 규칙 매칭 자주 묻는 질문