Shadowrocket 규칙 설정 방법: DOMAIN-SUFFIX, GEOIP, FINAL 등 키워드 매칭

규칙이 라우팅에 적용되는지 먼저 확인

규칙은 연결에 적용할 정책을 결정하며, 사용할 수 있는 프록시 서비스를 만들어 주지는 않습니다. DOMAIN-SUFFIX,example.com,PROXY를 올바르게 작성해도 이미 사용 가능한 프록시 설정이 있어야 합니다. 이 글은 사용자가 이미 서비스 제공업체와 구독을 보유하고 있다고 전제하며, 설정의 [Rule] 부분을 확인하는 데 중점을 둡니다.

Home → Global Routing에서 Proxy, Direct, Config, Scene은 각각 다른 작동 방식입니다. Proxy와 Direct는 임시 비교 테스트에 적합하며, 현재 설정의 규칙을 확인하려면 Config를 선택해야 합니다. Scene은 상황에 따라 라우팅 동작을 전환하는 기능이므로, Scene이 표시된다는 이유만으로 특정 규칙이 적용 중이라고 판단할 수는 없습니다.

1. 설정 백업

   Config로 이동해 현재 사용 중인 설정 파일을 확인하고 먼저 사본을 저장합니다. 테스트 후 원래 상태로 되돌릴 수 있도록 기존 Global Routing 선택 항목도 기록해 둡니다.

2. 규칙 모드 선택

   Home → Global Routing → Config로 이동합니다. 그런 다음 Config에서 활성화된 파일이 수정하려는 파일과 같은지 확인합니다.

3. 규칙 하나 수정

   Config에서 해당 파일의 편집 기능을 열고 [Rule]을 찾아 규칙을 한 번에 하나씩 추가하거나 수정합니다. 다른 설정 섹션은 그대로 유지합니다.

4. 저장 후 검증

   설정을 저장하고 테스트 연결을 새로 만든 다음, 연결 기록에서 대상, 매칭된 규칙, 적용된 정책을 확인합니다. 기존 연결이 재사용되고 있다면 해당 페이지를 닫은 뒤 다시 접속합니다.

도메인 규칙: 정확히 일치, 접미사 일치, 부분 문자열 일치

일반적인 규칙은 ‘유형, 매칭 값, 정책’ 순서로 작성하며 필드 사이에는 영문 쉼표를 사용합니다. 도메인 매칭 값에는 호스트 이름만 입력하고 https://, 경로, 쿼리 매개변수, 포트는 포함하지 않습니다. https://api.example.com:443/v1에 접속할 때 도메인 규칙이 처리하는 값은 전체 주소가 아니라 api.example.com입니다.

DOMAIN-SUFFIX 앞에 점을 붙이거나 *.example.com처럼 작성할 필요는 없습니다. 접미사 매칭은 해당 도메인 자체와 하위 도메인을 이미 포함합니다. 일반 접미사 필드에 별표를 입력해도 의도한 와일드카드 표현식이 만들어지지 않습니다.

DOMAIN-KEYWORD는 부분 문자열 매칭이 꼭 필요한 경우에 적합하며, 정확한 도메인 규칙의 줄임말처럼 사용하면 안 됩니다. 예를 들어 example이라는 키워드는 example-news.test도 매칭할 수 있습니다. 특정 사이트와 그 하위 도메인만 대상으로 하려면 DOMAIN-SUFFIX를, 호스트 하나만 처리하려면 DOMAIN을 우선 사용하세요.

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

위 예시에서 api.example.com에는 PROXY가 적용되고 www.example.com에는 DIRECT가 적용됩니다. example-news.test만 키워드 규칙에 매칭됩니다. 이 예시 도메인은 문법 설명용이며 해당 웹페이지에 접속할 수 있다는 뜻은 아닙니다.

IP-CIDR와 GEOIP: 주소를 매칭하며 URL은 매칭하지 않음

IP-CIDR은 IPv4 주소 대역을 기준으로 매칭합니다. 192.168.0.0/16은 192.168.0.0부터 192.168.255.255까지의 주소 범위를 뜻합니다. 단일 IPv4 주소는 /32로 표시할 수 있습니다. 여기서 접두사 길이는 네트워크 범위를 나타내며 포트 번호가 아닙니다.

IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
IP-CIDR,203.0.113.8/32,PROXY,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

예시의 203.0.113.8은 문서에 사용하는 예시 주소이지, 실제 서비스 주소가 아닙니다. no-resolve는 이 IP 규칙을 매칭하기 위해서만 도메인 이름을 별도로 조회하지 말라는 뜻입니다. 앱 전체에서 DNS를 중단하거나 이 규칙에 해당하는 모든 요청에서 조회가 필요 없다는 의미는 아닙니다. 대상 주소를 이미 알고 있다면 주소 매칭에 사용할 수 있습니다.

GEOIP의 결과는 IP 지리 데이터베이스에 따라 달라집니다. CDN, DNS 응답 또는 네트워크 환경의 변화로 도메인이 서로 다른 주소를 가리킬 수 있으므로 같은 도메인도 GEOIP 결과가 바뀔 수 있습니다. 대상에 항상 특정 정책을 적용해야 한다면 주소의 지역 분류에만 의존하지 말고 GEOIP보다 앞에 도메인 규칙을 명확하게 작성하세요.

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

이 글에서 다루는 일반 규칙은 연결마다 작성 순서대로 확인합니다. 규칙이 매칭되면 해당 정책을 적용하고, ‘더 정확해 보이는’ 다음 규칙을 계속 찾지 않습니다. 규칙 유형 자체에 자동 우선순위는 없습니다. 범위가 넓은 DOMAIN-SUFFIX 뒤에 정확한 DOMAIN을 배치하면 해당 규칙이 적용될 기회를 얻지 못할 수 있습니다.

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

• 예외를 먼저 작성:api.example.com은 example.com 아래에서 별도로 처리해야 하는 호스트이므로 접미사 규칙보다 앞에 배치합니다.
• 그다음 범위를 지정: 나머지 example.com 및 하위 도메인에는 DIRECT를 적용합니다. 이후의 IP 판단 규칙은 확인하지 않습니다.
• 마지막에 기본 규칙 작성:FINAL,PROXY가 아직 매칭되지 않은 연결을 처리합니다. 첫 번째 줄로 옮기면 이후 일반 규칙이 매칭될 기회를 잃습니다.

DIRECT는 대상에 직접 연결한다는 뜻이지, 모든 시스템 네트워크 조건을 우회한다는 뜻은 아닙니다. PROXY는 프록시 경로로 전달한다는 뜻이지, 연결 성공을 보장하지 않습니다. 정책 필드에 사용자 지정 정책 그룹 이름을 입력한다면 설정에 정의된 이름과 정확히 일치해야 합니다. 이 글에서는 정의되지 않은 그룹 이름을 만들지 않도록 DIRECT와 PROXY만 사용합니다.

규칙이 적용되지 않을 때는 매칭과 연결을 나눠서 확인

‘웹페이지를 열 수 없음’만으로 규칙을 잘못 작성했다고 단정할 수는 없습니다. 먼저 요청이 예상한 규칙에 매칭되었는지 확인하고, 다음으로 해당 정책으로 연결할 수 있는지 확인합니다. 매칭 기록에 PROXY가 표시되는데도 요청이 실패한다면 기존 프록시 서비스와 연결 매개변수를 점검하세요. 같은 유형의 도메인 규칙을 더 추가해도 전송 문제가 해결되는 경우는 드뭅니다.

1. Home → Global Routing → Config가 선택되어 있고, 편집 중인 파일이 Config에서 현재 활성화된 파일과 같은지 확인합니다.
2. 동일한 전체 주소로 새 요청을 보내고 실제 호스트 이름을 기록합니다. 웹페이지 리디렉션, 이미지, API는 서로 다른 도메인을 사용할 수 있으므로 각각 확인해야 합니다.
3. 더 앞에 있는 DOMAIN-SUFFIX, DOMAIN-KEYWORD 또는 FINAL이 해당 규칙보다 먼저 매칭되어 요청을 처리하지 않았는지 확인합니다.
4. 올바른 규칙에 매칭되었다면 Proxy와 Direct의 접속 결과를 임시로 비교한 뒤 테스트 후 Config로 되돌립니다. 한 번에 조건 하나만 변경하세요.

아래 오류 표기는 Apple 네트워크 오류 체계에서 가져온 것입니다. 진단 정보에 해당 문구가 실제로 표시되는 경우에만 참고하세요. 네트워크 요청이 실패한 유형을 나타내며 Shadowrocket 규칙 파서의 문법 오류는 아닙니다. 오류 코드만으로 문제 발생 지점을 단정할 수도 없습니다.

그 밖에 자주 하는 입력 실수로는 한글 쉼표 사용, FINAL,PROXY를 세 필드 형식으로 작성하는 경우, https://example.com을 DOMAIN-SUFFIX에 입력하는 경우, 존재하지 않는 정책 그룹 이름을 사용하는 경우가 있습니다. 저장하기 전에 필드를 한 줄씩 확인하고 설정 전체를 한꺼번에 바꾸지 마세요. 원격에서 관리하는 설정이라면 이후 업데이트가 로컬 변경 사항을 덮어쓰는지 확인하고 복원할 수 있는 사본을 보관하세요.

자주 묻는 질문: 규칙을 하나 수정한 뒤 결과 확인하기

최종 확인에서는 요청의 실제 호스트 이름, 매칭된 규칙 행, 적용된 정책이 각각 올바른지 확인해야 합니다. 그런 다음 페이지와 API 요청이 완료되는지 검증하세요. 이렇게 하면 ‘규칙 선택 오류’와 ‘선택된 경로의 연결 불가’를 구분해 처리할 수 있어, 여러 설정을 반복해서 바꾸며 운에 맡기는 일을 줄일 수 있습니다.