Shadowrocket 규칙 문법 가이드: DOMAIN-SUFFIX·GEOIP·IP-CIDR·FINAL 매칭

1. 규칙을 확인하기 전에 Config 선택하기

Shadowrocket 규칙은 연결을 켜면 반드시 한 줄씩 적용되는 것이 아닙니다. 먼저 Home에서 Global Routing을 확인하세요. 현재 구성 파일의 규칙을 사용하려면 Config를 선택해야 합니다. Config에서도 방금 수정한 파일이 실제로 활성화되어 있는지 확인하세요. 이름이 같은 다른 파일이 선택되어 있을 수도 있습니다.

Home에서는 서버를 선택하고 연결하며, Config에서는 구성 파일을 관리합니다. Settings에서는 앱 설정을 조정할 수 있습니다. Settings → On Demand는 조건에 따라 연결을 시작하는 방식에 영향을 주지만, DOMAIN-SUFFIX 규칙의 정책을 다른 것으로 자동 변경하지는 않습니다. 문제를 확인할 때는 ‘연결이 시작되는지’와 ‘연결 후 어떤 규칙이 적용되는지’를 구분하고 두 설정을 한꺼번에 바꾸지 마세요.

2. 규칙은 위에서 아래로 확인하며, 처음 일치한 항목이 정책을 결정합니다

일반적인 규칙은 영문 쉼표로 항목을 구분하며 기본 형식은 ‘규칙 유형, 매칭 값, 정책’입니다. FINAL은 매칭 값 없이 ‘FINAL, 정책’으로 작성합니다. 규칙은 순서대로 확인되고 처음 일치하는 항목의 정책이 적용됩니다. 따라서 뒤에 더 구체적인 규칙이 있더라도 계속 확인하지 않습니다. 구성에서는 ‘구체적인 예외를 먼저, 넓은 범위 규칙을 나중에, FINAL은 마지막에’ 배치하는 것이 중요합니다.

DOMAIN,api.example.com,PROXY
DOMAIN-SUFFIX,example.com,DIRECT
FINAL,PROXY

이 세 줄에서 api.example.com은 첫 번째 줄에 매칭되어 PROXY를 선택합니다. www.example.com은 첫 번째 줄에는 맞지 않지만 두 번째 줄에는 맞으므로 DIRECT를 선택합니다. 두 번째 줄을 첫 번째 줄 위로 옮기면 api.example.com도 먼저 접미사 규칙에 매칭되어 원래의 정확한 예외가 적용되지 않습니다. 순서가 잘못되어도 문법 오류가 반드시 발생하는 것은 아니지만 결과는 달라집니다.

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

도메인 규칙은 연결에서 사용할 수 있는 도메인 정보를 기준으로 매칭하며, 웹페이지의 전체 주소를 기준으로 하지는 않습니다. 매칭 값에는 프로토콜, 포트, 경로, 쿼리 매개변수를 넣지 마세요. 예를 들어 /account 경로가 포함된 페이지에 접속해도 DOMAIN은 호스트 이름만 확인하므로 같은 호스트의 서로 다른 페이지를 구분할 수 없습니다.

api.example.com만 프록시를 사용하게 하려면 api를 DOMAIN-KEYWORD로 지정하기보다 DOMAIN을 우선 사용하세요. DOMAIN-KEYWORD는 관련 없는 다른 도메인까지 매칭할 수 있습니다. 한 도메인과 그 모든 하위 도메인까지 포함하려면 DOMAIN-SUFFIX를 사용하세요. 이 접미사 문법 대신 와일드카드 *.example.com을 쓰지 마세요.

• 호스트 이름 하나를 정확히 매칭하려면 DOMAIN을 사용하세요.
• 기본 도메인과 하위 도메인을 매칭하려면 DOMAIN-SUFFIX를 사용하세요.
• 문자열을 기준으로 매칭 범위를 넓혀야 한다면 DOMAIN-KEYWORD를 사용하고, 원치 않는 매칭이 생길 가능성을 확인하세요.
• 대상 IP만 알고 사용할 수 있는 도메인 정보가 없다면 IP 규칙을 확인하세요. 도메인 규칙이 반드시 매칭된다고 가정하지 마세요.

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

IP-CIDR은 IP 주소 대역을 기준으로 매칭하고, GEOIP는 IP 지리 정보 데이터베이스의 분류 결과를 기준으로 매칭합니다. 두 규칙 모두 주소 정보를 확인하며 웹페이지 언어, 계정 지역, 도메인 끝의 국가·지역 접미사를 기준으로 하지 않습니다. 도메인 접미사만으로 해당 도메인이 GEOIP의 어떤 지역 코드에 매칭될지 단정할 수 없습니다.

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

192.0.2.0/24는 문서 예시용 네트워크 대역입니다. /24는 앞의 24비트가 네트워크 접두사라는 뜻이며, 192.0.2.0부터 192.0.2.255까지 포함합니다. 실제로 사용할 수 있는 서버 주소가 아닙니다. IP-CIDR은 주소 범위 전체를 매칭하며, 텍스트에 나온 192.0.2.0만 매칭하지 않습니다. IPv6 대역에는 해당하는 IP-CIDR6 규칙 유형을 사용하세요. IPv6 주소를 IPv4 예시에 그대로 넣으면 안 됩니다.

도메인 규칙이 매칭되지 않고 뒤의 IP 규칙에 주소 정보가 필요한 경우 DNS 상태가 매칭 과정에 영향을 줄 수 있습니다. GEOIP 결과는 실제 대상 주소와 데이터베이스 내용에 따라 달라지므로 특정 사이트의 모든 리소스를 빠짐없이 처리한다고 보장할 수 없습니다. 문제를 확인할 때는 ‘앱이 열리지 않는다’고만 기록하지 말고 구체적인 도메인, 실제 주소, 매칭된 정책을 기록하세요.

5. 간단한 규칙 집합으로 FINAL과 정책 결과 이해하기

아래 규칙은 읽고 실험하기 위한 완전한 규칙 예시이며 모든 네트워크에 권장하는 구성은 아닙니다. 사용하기 전에 기존 구성과 서버 설정 전체를 보관하고 복사본에서만 규칙을 수정하세요. [Rule]만 있는 일부 규칙을 모든 연결 매개변수가 포함된 새 구성으로 간주하지 마세요.

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

• blocked.example.com은 먼저 REJECT에 매칭되므로 뒤에 있는 example.com 접미사 규칙까지 확인하지 않습니다.
• api.example.com은 두 번째 줄에 매칭되어 PROXY를 사용합니다. 실제 연결 가능 여부는 프록시 서버 상태에도 달려 있습니다.
• metrics.example.com은 먼저 DOMAIN-SUFFIX에 매칭되므로 뒤의 REJECT가 아닌 DIRECT를 사용합니다.
• 다른 도메인에 metrics가 포함되어 있더라도 앞선 규칙에 매칭되지 않은 경우에만 DOMAIN-KEYWORD 규칙에 매칭됩니다.
• 앞선 규칙에 매칭되지 않은 연결은 FINAL,PROXY가 처리합니다. 아직 확인해야 할 규칙보다 FINAL을 앞에 두지 마세요.

metrics.example.com도 거부하려면 접미사 규칙 앞에 정확한 DOMAIN 예외를 추가할 수 있습니다. 키워드 규칙 전체를 위로 옮기면 metrics가 포함된 모든 도메인이 먼저 거부될 수 있습니다. 수정하기 전에 원하는 범위를 명확히 정한 뒤 ‘정확한 예외 추가’와 ‘넓은 범위 규칙 이동’ 중 하나를 선택해 한 도메인을 고치려다 영향을 넓히지 않도록 하세요.

6. 현재 구성에서 수정하고 확인하기

1. 기존 구성 보관

   Config로 이동해 현재 사용할 수 있는 구성의 복사본을 먼저 보관한 뒤 수정할 파일의 편집 메뉴를 여세요. 되돌릴 수 있도록 파일 이름과 기존 Global Routing 설정을 기록해 두세요.

2. 규칙 부분 확인

   구성 텍스트에서 [Rule]을 찾아 영문 쉼표로 구분된 규칙을 한 줄씩 수정하세요. 정확한 예외는 해당하는 넓은 범위 규칙보다 앞에 두고 FINAL은 마지막에 배치하세요. 순서를 정리하는 대신 [Rule] 구간을 여러 번 붙여 넣지 마세요.

3. 활성화하고 모드 선택

   저장한 뒤 Config에서 이 파일이 사용 중인지 확인하세요. Home → Global Routing → Config로 이동합니다. 파일만 저장하고 선택하지 않았다면 방금 수정한 내용을 확인할 수 없습니다.

4. 트래픽 출구 확인

   Home에서 기존 서버를 선택하고 Connectivity Test를 실행해 프록시 연결에 필요한 조건이 충족되는지 먼저 확인하세요. 서버와 구독 정보는 서비스 제공업체에서 받아야 합니다. 규칙 텍스트만으로 이러한 매개변수를 대신할 수 없습니다.

5. 새 연결로 확인

   대상 요청을 다시 보내고 앱의 연결 기록에서 대상, 매칭 규칙, 트래픽 출구 정책을 확인하세요. 한 번에 하나씩만 수정하세요. 기존 연결이 계속 재사용될 수 있으므로 필요한 경우 이전 요청을 중지한 뒤 새로 연결해 테스트하세요.

Connectivity Test는 연결 가능 여부를 확인하는 기능이며 특정 웹사이트가 지정한 규칙에 매칭되었음을 단독으로 증명하지는 않습니다. 규칙은 구체적인 요청의 기록을 기준으로 확인하세요. 서버 구독과 규칙 구성도 구분해야 합니다. Home의 서버 목록을 업데이트해도 현재 Config의 규칙이 함께 업데이트되는 것은 아닙니다. 원격 구성을 다시 업데이트한 뒤에는 로컬 수정 사항이 유지되었는지도 다시 확인하세요.

7. 규칙 오류와 트래픽 출구 오류 구분하기

규칙이 PROXY에 매칭되었는데도 웹페이지가 열리지 않는다고 해서 반드시 문법 오류인 것은 아닙니다. 아래는 연결 기록에 자주 표시되는 네트워크 오류 문구입니다. 전체 오류 메시지에는 주소, 포트, 하위 계층 설명이 포함될 수 있습니다. 오류가 발생한 단계가 대상 연결인지 프록시 서버 연결인지 먼저 확인하세요.

예를 들어 서비스 제공업체가 서버 포트로 443을 안내했다면 서버 설정의 포트도 실제로 443인지 확인해야 합니다. 규칙 예시에 443이 나온다는 이유로 기존 포트를 임의로 바꾸지 마세요. DOMAIN-SUFFIX에는 포트 필드가 없습니다. 서버의 수신 포트와 도메인 매칭 조건은 서로 다른 계층입니다.

8. 규칙 구성 관련 자주 묻는 질문