Shadowrocket의 규칙은 ‘더 구체적’이라는 이유만으로 자동 정렬되지 않습니다. 현재 요청에서 확인할 수 있는 정보를 바탕으로 위에서 아래로 검사하며, 처음 일치하는 규칙의 정책을 적용한 뒤 검사를 멈춥니다. 기존 설정에 도메인 예외를 추가하거나 분기 결과를 확인하려는 경우, 먼저 Global Routing이 Config로 설정되어 있는지 확인하세요. 구체적인 예외 규칙을 포괄적인 규칙보다 앞에 두고, FINAL은 맨 마지막에 배치한 다음 새 연결로 실제 적용 결과를 확인하면 됩니다.
먼저 Config인지 확인한 뒤 규칙 적용 여부 점검
[Rule] 섹션에서는 요청에 적용할 정책을 지정합니다. 사용자 규칙이 적용되지 않을 때는 규칙을 더 추가하기 전에 앱에서 어떤 구성을 사용 중인지, 현재 Global Routing 상태가 무엇인지 먼저 확인하세요. Proxy 또는 Direct를 사용 중이라면 Config에서 규칙을 순서대로 검사한 결과라고 볼 수 없습니다.
- Home → Global Routing을 열어 현재 Config가 선택되어 있는지 확인한 다음 Home으로 돌아갑니다.
- Config으로 이동해 현재 선택된 구성을 확인합니다. 구성이 여러 개라면 편집하려는 구성과 실제 사용하는 구성이 일치하는지 먼저 확인하세요.
- 해당 구성의 편집 화면에서
[Rule]섹션을 확인하고 변경 사항을 저장한 뒤, 수정한 구성이 계속 선택되어 있는지 확인합니다. - Home으로 돌아가 필요하면 연결을 다시 설정한 다음 대상 도메인에 새 요청을 보냅니다. 기존 연결을 재사용하는 페이지를 새로고침하는 것만으로는 확인하지 마세요.
이 글에서는 Config의 규칙 순서만 다루며 Scene 설정은 설명하지 않습니다. Settings → On Demand에서는 조건에 따른 연결 동작을 관리합니다. 이는 규칙 우선순위 설정과 다릅니다. 자동 연결이 성공했다는 사실만으로 특정 도메인 규칙이 적용되었다고 볼 수는 없습니다.
수정하기 전에 기존 구성의 사본을 보관하세요. 아래 코드는 규칙 문법과 순서를 설명하기 위한 것으로, 연결에 필요한 전체 매개변수를 포함하지 않으며 기존 구성을 대체하지 않습니다. 기존 서비스와 구독은 사용자가 직접 관리해야 하며, 이 사이트에서는 노드나 구독을 제공·판매·추천하지 않습니다.
위에서 아래로 매칭: 구체적인 규칙이 자동으로 앞에 오지 않습니다
규칙의 매칭 조건과 정책은 서로 다른 요소입니다. DOMAIN-SUFFIX,example.com,PROXY를 예로 들면 DOMAIN-SUFFIX는 규칙 유형, example.com은 매칭 대상, PROXY는 일치했을 때 적용할 정책입니다. 도메인 접미사 규칙은 해당 도메인과 하위 도메인까지 매칭할 수 있으므로, 뒤에 있는 특정 하위 도메인 예외는 검사 기회조차 얻지 못할 수 있습니다.
아래는 순서를 잘못 판단하기 쉬운 예입니다. docs.example.com에 접속하면 앞에 있는 접미사 규칙도 이미 일치하므로 요청에 PROXY가 적용됩니다. 뒤에 있는 정확한 도메인 규칙이 ‘더 구체적’이라고 해서 앞선 규칙을 덮어쓰지는 않습니다.
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN,docs.example.com,DIRECT
FINAL,PROXYdocs.example.com만 DIRECT를 사용하고 같은 접미사에 해당하는 다른 도메인은 PROXY를 사용하게 하려면 정확한 예외 규칙을 앞에 배치해야 합니다. 우선순위는 키워드 이름이나 규칙을 추가한 시점이 아니라 규칙의 위치에 따라 결정됩니다.
[Rule]
DOMAIN,docs.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
FINAL,PROXY요점: 더 위에 있는 규칙이 먼저 적용되는지 확인하세요
추가한 예외가 적용되지 않으면 먼저 같은 도메인이나 상위 접미사를 검색하세요. 해당 예외를 적용할 수 있는 첫 번째 규칙보다 앞에 배치해야 합니다. 같은 규칙을 반복해서 추가해도 우선순위는 높아지지 않습니다.
PROXY, DIRECT, REJECT: 일치한 뒤 적용되는 세 가지 결과
정책은 ‘일치한 뒤 어떻게 처리할지’를 정하며, ‘어느 줄을 먼저 검사할지’를 정하지 않습니다. PROXY를 DIRECT로 바꿔도 해당 규칙의 우선순위가 자동으로 높아지지는 않습니다. 포괄적인 허용 규칙 뒤에 REJECT 규칙을 두면 앞선 규칙이 이미 처리한 요청을 차단할 수 없습니다.
| 정책 | 처리 방식 | 확인할 사항 |
|---|---|---|
PROXY | 선택한 프록시 정책에 해당하는 아웃바운드 연결로 처리합니다. | 현재 프록시 선택과 사용 가능 여부를 확인하세요. 규칙에 일치해도 원격 대상에 반드시 연결되는 것은 아닙니다. |
DIRECT | 프록시 서버를 거치지 않고 대상에 직접 연결합니다. | 현재 네트워크에서 대상에 직접 접속할 수 있는지 확인하세요. ‘VPN 전체 연결 해제’를 뜻하는 명령은 아닙니다. |
REJECT | 이 규칙에 일치하는 연결을 거부합니다. | 차단 대상 도메인이 페이지에 필요한 리소스인지 확인해 포괄적인 조건이 정상 기능에 영향을 주지 않도록 하세요. |
규칙의 정책에는 구성에 이미 정의된 정책 그룹을 지정할 수도 있습니다. 규칙 조각을 복사하기 전에 참조 이름이 현재 구성에서 무엇을 뜻하는지 확인해야 하며, 임의의 문자열을 이미 존재하는 정책으로 간주해서는 안 됩니다. 이 글에서는 기본 동작 설명에 PROXY, DIRECT, REJECT만 사용하며, 추가 정책 그룹을 만들거나 특정 서비스를 지정하지 않습니다.
- 특정 도메인을 직접 연결하려면: 정확한 규칙
DOMAIN,docs.example.com,DIRECT을 추가하고 해당 도메인을 포함할 수 있는 접미사 규칙보다 앞에 배치합니다. - 특정 접미사를 프록시로 연결하려면:
DOMAIN-SUFFIX,example.com,PROXY를 사용하고, 위에 더 포괄적인 매칭 조건이 있는지 확인합니다. - 특정 도메인을 차단하려면: 먼저 범위가 명확한
DOMAIN,blocked.example.com,REJECT로 확인한 뒤 매칭 범위를 넓힐 필요가 있는지 판단합니다.
FINAL의 역할: 기본 처리, 자동 재시도 아님
FINAL,PROXY는 앞선 규칙에 일치하지 않은 요청에 PROXY를 적용한다는 뜻입니다. 도메인이나 IP 대역 조건이 없으므로 규칙 섹션의 맨 마지막에 배치해야 합니다. FINAL을 앞에 두면 뒤에 있는 일반 규칙은 아직 일치하지 않은 요청을 처리할 기회를 얻지 못합니다.
프록시를 기본 처리로 지정한 규칙 배치
- 정확한 예외
- DOMAIN,docs.example.com,DIRECT
- 접미사 정책
- DOMAIN-SUFFIX,example.com,PROXY
- 최종 기본 처리
- FINAL,PROXY
앞의 두 규칙에 일치하지 않은 요청은 PROXY로 처리합니다. 연결 가능 여부는 별도로 확인해야 합니다.
직접 연결을 기본 처리로 지정한 규칙 배치
- 정확한 차단
- DOMAIN,blocked.example.com,REJECT
- 접미사 정책
- DOMAIN-SUFFIX,example.com,PROXY
- 최종 기본 처리
- FINAL,DIRECT
앞의 두 규칙에 일치하지 않은 요청은 직접 연결합니다. 직접 연결에 실패해도 이전 규칙으로 돌아가지 않습니다.
FINAL은 ‘앞선 프록시 연결이 실패하면 다른 방식으로 다시 시도’하는 기능이 아닙니다. 규칙 하나에 일치하면 연결이 나중에 시간 초과되더라도 매칭 과정이 자동으로 다음 규칙으로 넘어가지는 않습니다. 요청이 이미 PROXY 규칙에 일치했다면 해당 정책의 연결 상태를 확인하세요. 오류 복구를 기대하며 마지막에 두 번째 FINAL을 추가해서는 안 됩니다.
- 분류되지 않은 트래픽을 PROXY와 DIRECT 중 어느 쪽으로 처리할지 먼저 결정합니다.
- 현재 구성에 FINAL이 이미 있는지 확인하고, 무작정 추가하는 대신 기존 기본 처리 정책을 수정합니다.
- 유지할 규칙을 FINAL 앞에 정리하고, 그 뒤에 남아 있는 유효한 규칙이 없는지 확인합니다.
도메인, IP 대역, GEOIP를 하나의 예시에 배치
아래 예시는 차단 항목, 정확한 도메인 예외, 도메인 접미사, 지정된 IP 대역, GEOIP, 마지막으로 FINAL을 배치한 구성을 보여 줍니다. 이는 읽기 쉬운 예시일 뿐, 규칙 유형의 고정 우선순위가 아닙니다. 예를 들어 특정 IP 대역은 항상 직접 연결해야 한다면 위치와 요청에 매칭 가능한 IP 정보가 있는지 다시 검토해야 합니다.
[Rule]
DOMAIN,blocked.example.com,REJECT
DOMAIN,docs.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXYexample.com과 하위 도메인은 도메인 관계를 설명하기 위한 예시입니다. 192.0.2.0/24는 문서용 IP 대역이므로 실제 서비스 주소로 사용하면 안 됩니다. GEOIP,CN,DIRECT는 대상 IP를 지리 데이터베이스로 분류하는 방법을 보여 주는 예시이며, 모든 사용자가 이 정책을 적용해야 한다는 뜻은 아닙니다.
| 규칙 키워드 | 매칭 대상 | 이 예시에서 주의할 점 |
|---|---|---|
DOMAIN | 전체 도메인. | 명확하게 지정한 단일 도메인에만 예외를 적용하며, 모든 하위 도메인에 자동 적용되지는 않습니다. |
DOMAIN-SUFFIX | 도메인과 그 하위 도메인. | 이 규칙을 먼저 작성하면 뒤에 있는 같은 접미사의 정확한 예외가 적용되지 않을 수 있습니다. |
IP-CIDR | 대상 IPv4 주소가 속한 대역. | no-resolve는 이 규칙의 매칭을 위해 도메인 조회를 강제로 시작하지 않는다는 뜻입니다. 모든 DNS를 끄는 설정은 아닙니다. |
GEOIP | 대상 IP의 지리 데이터베이스 분류. | 판단 기준은 웹페이지 언어, 도메인 접미사, 웹사이트 운영 회사의 주소가 아닙니다. |
FINAL | 앞선 규칙에 일치하지 않은 요청. | 맨 마지막에 배치해 기본 처리만 담당하게 합니다. 대상에 연결할 수 있는지는 확인하지 않습니다. |
도메인 규칙은 사용 가능한 도메인 정보에, IP 규칙은 대상 IP에 의존합니다. 웹사이트가 같아 보인다는 이유만으로 두 규칙을 서로 대체할 수는 없습니다. 한 페이지가 여러 리소스 도메인에 요청을 보낼 수도 있습니다. 기본 페이지가 DIRECT에 일치해도 이미지, 동영상, 로그인 API까지 DIRECT를 사용한다고 단정할 수 없습니다. 문제를 확인할 때는 브라우저 주소창만 기록하지 말고 각 요청의 실제 대상을 기록하세요.
요점: 한 번에 매칭 조건 하나씩 조정
먼저 명확한 도메인 하나로 규칙 위치와 정책을 확인한 뒤 접미사, IP 대역, GEOIP를 차례로 추가하세요. DNS, Global Routing, 여러 규칙을 동시에 바꾸면 결과가 달라져도 어떤 변경이 영향을 주었는지 판단하기 어렵습니다.
수정 후 확인 순서와 자주 묻는 문제
규칙을 확인할 때는 ‘규칙에 일치했는지’와 ‘일치한 뒤 연결할 수 있는지’를 나누어 살펴봐야 합니다. 전자는 구성, 순서, 대상 정보를 확인하고 후자는 DIRECT의 네트워크 연결 가능성이나 PROXY 연결 상태를 확인합니다. 웹페이지의 로딩 속도만으로 정책을 판단하면 캐시, 기존 연결 재사용, 서버 응답 차이를 규칙의 효과로 오인하기 쉽습니다.
- 기준 상태 기록: 현재 구성, Global Routing 상태, 대상 도메인, 예상 정책을 기록합니다. 수정 전에 기존 규칙의 위치도 보관하세요.
- 저장 후 적용: 수정한 구성을 사용 중인지 확인하고 필요하면 다시 연결합니다. 선택되지 않은 파일만 편집하지 않도록 주의하세요.
- 새 연결 시작: 기존 접속을 종료한 뒤 다시 요청해 장시간 연결이 처음 설정될 때의 처리 결과를 계속 사용하는 상황을 피합니다.
- 연결 기록 확인: 앱에서 제공하는 요청 또는 연결 기록에서 대상, 정책, 확인 가능한 매칭 정보를 점검합니다. 기록이 없다면 먼저 요청이 현재 연결에 들어왔는지 확인하세요.
- 한 번에 하나만 변경: 먼저 규칙 위치를 확인한 다음 정책을 점검합니다. 실패하면 사본을 복원해 다시 테스트하고, 확인되지 않은 예외를 계속 추가하지 마세요.
규칙을 맨 아래에 추가했는데 왜 기존 정책이 적용되나요?
추가한 규칙이 FINAL 뒤에 있는지 먼저 확인한 다음, 위쪽에서 대상을 포함할 수 있는 DOMAIN-SUFFIX나 다른 규칙을 검색합니다. 새 규칙을 대상을 포함하는 첫 번째 규칙보다 앞에 옮기고 저장한 뒤 새 연결로 테스트하세요. 같은 규칙을 반복해서 추가해 결과를 바꾸려 하지 마세요.
DIRECT로 설정했는데 왜 접속할 수 없나요?
먼저 연결 기록에서 요청에 실제로 DIRECT가 적용되었는지 확인하세요. 적용되었다면 현재 네트워크에서 대상에 직접 연결할 수 있는지, 도메인 조회가 정상인지 확인합니다. DIRECT는 아웃바운드 연결 방식을 지정할 뿐, 현재 네트워크에서 대상에 접속할 수 있음을 보장하지 않습니다.
REJECT 설정 후 페이지 전체에 문제가 생기면 어떻게 하나요?
방금 추가한 REJECT 규칙을 일시적으로 제거하고 다시 요청해 문제가 사라지는지 확인하세요. 관련이 있다면 포괄적인 DOMAIN-SUFFIX를 차단하려는 정확한 DOMAIN으로 범위를 좁힌 뒤 페이지에 필요한 다른 리소스 도메인도 확인합니다.
구성을 업데이트한 뒤 직접 작성한 규칙이 사라졌나요?
먼저 업데이트한 항목이 Home에 있는 기존 구독의 서버 목록인지, Config의 원격 구성인지 확인하세요. 원격 구성을 다시 가져오면 로컬에서 편집한 내용이 덮어써질 수 있습니다. 업데이트 전에 사본을 보관하고, 업데이트 후 [Rule] 섹션을 비교한 다음 현재 선택된 구성도 다시 확인하세요.
기본 설정을 다시 확인하려면 사용 안내를 참고하세요. Global Routing 상태를 확인하려면 기능 안내의 Global Routing 설명을 참고할 수 있습니다. 확인이 끝나면 필요한 예외만 남기고 중복 규칙을 삭제해 다음에도 전체 구성을 위에서 아래로 쉽게 점검할 수 있도록 정리하세요.