Shadowrocket 규칙 우선순위와 FINAL 설정 방법

먼저 Config 확인: 규칙 순서가 적용되는 조건

규칙을 수정하기 전에 Home → Global Routing에서 현재 라우팅 모드를 확인하세요. 이 글에서는 Config를 선택했을 때 현재 설정의 [Rule] 목록에 적용되는 매칭 순서를 설명합니다. 파일만 수정하고 Global Routing이 Proxy 또는 Direct에 머물러 있다면, 이 규칙들이 예상대로 적용되는지 확인할 수 없습니다.

Global Routing의 모드 이름과 규칙 행의 정책 이름은 서로 다른 설정입니다. 예를 들어 Proxy는 라우팅 모드이고 PROXY는 규칙 행의 대상 정책입니다. 이름이 비슷하지만 ‘Proxy를 선택하면 PROXY 규칙만 적용된다’는 뜻은 아닙니다.

위에서 아래로 매칭: 더 구체적이라고 자동으로 우선하지 않습니다

일반 규칙 목록에서 Shadowrocket은 위에서 아래로 규칙을 확인합니다. 규칙이 매칭되어 처리 정책이 정해지면 아래에 있는 ‘더 정확해 보이는’ 규칙은 더 이상 확인하지 않습니다. 우선순위는 주로 배치 순서로 결정되며, 도메인 길이나 DIRECT, PROXY, REJECT라는 이름으로 정해지지 않습니다.

아래에서는 예약된 예시 도메인으로 규칙 간 충돌을 설명합니다. 실제 접속 가능한 테스트 서비스가 아닙니다. example.com 전체에는 PROXY를 적용하되 api.example.com은 DIRECT로 처리해야 하는 예외라고 가정해 보겠습니다. 예외 규칙은 범위 규칙보다 앞에 두어야 합니다.

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

• api.example.com: 첫 번째 줄에 먼저 매칭되어 DIRECT로 처리됩니다. 다음 DOMAIN-SUFFIX 규칙은 확인하지 않습니다.
• www.example.com: 첫 번째 줄에는 매칭되지 않고 두 번째 줄에 매칭되어 PROXY로 처리됩니다.
• 앞의 두 규칙에 해당하지 않는 요청은 FINAL까지 내려가 DIRECT로 처리됩니다.

두 번째 줄을 첫 번째 줄보다 앞에 두면 api.example.com이 DOMAIN-SUFFIX에 먼저 매칭되어 이후의 DIRECT 예외가 적용되지 않습니다. 같은 이유로 범위 규칙 뒤에 둔 REJECT도 자동으로 우선 적용되지 않습니다.

DOMAIN-SUFFIX,example.com,PROXY는 URL의 임의의 문자열을 검색하는 규칙이 아닙니다. 주소의 경로에 example.com이 포함되어 있어도 매칭되지 않습니다. 규칙 매개변수에는 도메인을 입력하고 https://, 페이지 경로 또는 쿼리 매개변수는 넣지 마세요. 특정 호스트 이름 하나만 처리하려면 DOMAIN으로 예외를 지정하는 것이 좋습니다.

FINAL 설정: 매칭되지 않은 요청의 경로 지정

FINAL은 도메인이나 IP 조건이 없는 최종 규칙입니다. 일반적으로 FINAL,DIRECT 또는 FINAL,PROXY로 작성합니다. ‘식별할 수 없는 웹사이트만 매칭’하는 규칙이 아니라, 앞선 규칙에 처리되지 않고 이 줄까지 도달한 모든 요청을 처리합니다.

따라서 FINAL은 전체 설정 파일의 맨 끝이 아니라 [Rule] 목록의 마지막에 두어야 합니다. 설정 파일에는 다른 섹션도 있을 수 있으므로 FINAL을 옮기려고 다른 섹션으로 이동하지 마세요. FINAL이 앞쪽에 있으면 뒤에 있는 일반 규칙은 매칭될 기회를 잃습니다.

아래는 도메인 규칙, IP 규칙 및 최종 규칙의 위치를 설명하는 독립적인 최소 구성 예시입니다. 일상적으로 사용하는 완성된 설정은 아닙니다. 사설 주소 범위 하나만 포함하며 모든 로컬 네트워크 상황을 다루지는 않습니다. 기존 설정의 사본에 필요한 행을 합쳐 사용하고 [Rule] 섹션을 추가로 만들지 마세요.

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

IP-CIDR은 주소 범위를 확인하고, GEOIP는 IP 지리 데이터베이스를 기준으로 분류합니다. 웹사이트의 언어나 운영 주체를 식별하는 기능은 아닙니다. 예시의 no-resolve는 이 IP 규칙을 위해 도메인을 별도로 해석하지 말라는 뜻입니다. 설정 전체에서 DNS 조회를 하지 않는다는 의미는 아닙니다. IP 규칙이 매칭되는지는 해당 요청에서 사용할 수 있는 대상 주소 정보에도 영향을 받습니다.

PROXY, DIRECT, REJECT: 매칭 조건과 처리 동작을 나누어 확인

규칙의 앞부분은 ‘무엇을 매칭하는지’를, 마지막 정책은 ‘매칭 후 어떻게 처리하는지’를 지정합니다. 같은 DOMAIN-SUFFIX에도 서로 다른 정책을 적용할 수 있습니다. 정책은 매칭 범위를 바꾸거나 규칙의 우선순위를 높이지 않습니다.

PROXY

요청을 프록시 경로로 전달합니다. 실제 사용할 연결은 현재 선택 상태와 설정된 정책에 따라 달라집니다. PROXY에 매칭되었다고 해서 서버 연결, 인증 또는 대상 사이트 접속이 반드시 성공하는 것은 아닙니다.

DIRECT

로컬 네트워크를 통해 대상에 직접 연결합니다. 직접 연결해야 한다고 확인된 도메인이나 주소 범위에 적합합니다. DIRECT가 DNS 오류, 로컬 네트워크 차단 또는 대상 서비스 장애를 자동으로 해결하지는 않습니다.

REJECT

매칭된 요청을 거부합니다. 명확히 차단해야 하는 개별 도메인이나 주소에 사용하세요. 매칭 범위를 먼저 확인해 로그인, 인증 또는 페이지 리소스까지 함께 차단하지 않도록 주의해야 합니다.

예를 들어 DOMAIN,metrics.example.com,REJECT는 이 예시 호스트 이름에 대한 처리만 지정합니다. 정상 콘텐츠와 차단하려는 요청이 같은 도메인을 사용하면 DOMAIN 또는 DOMAIN-SUFFIX로 웹페이지 경로에 따라 둘을 구분할 수 없습니다. 도메인 전체에 REJECT를 적용하면 이미지가 표시되지 않거나 버튼이 작동하지 않고 페이지 로딩이 중단될 수 있습니다.

• 예외를 직접 연결해야 하는 경우: 구체적인 DOMAIN의 DIRECT 규칙을 더 넓은 PROXY 범위 규칙보다 앞에 둡니다.
• 특정 도메인을 차단해야 하는 경우: 요청 기록에서 실제 호스트 이름을 확인한 다음 REJECT를 추가합니다. 페이지에 표시된 문구만 보고 도메인을 추측하지 마세요.
• IP 기준으로 분류해야 하는 경우: 대상 주소, 마스크와 데이터베이스 분류를 확인하세요. GEOIP가 도메인 소속 지역을 보장한다고 간주하지 마세요.

규칙은 요청의 경로를 결정하고 프로토콜은 프록시 연결 방식을 결정합니다. PROXY에서 사용하는 연결 프로토콜을 바꾸더라도 DOMAIN-SUFFIX의 매칭 범위는 달라지지 않습니다. 문제를 확인할 때는 먼저 ‘올바른 경로를 선택했는지’를 확인하고 그 다음 해당 경로에서 연결이 정상적으로 완료되는지 살펴보세요.

수정 및 확인: 사본을 저장하고 매칭 규칙을 하나씩 검증

아래 절차는 사용할 수 있는 연결과 설정이 이미 있는 경우를 전제로 합니다. 구독과 설정 파일은 서로 다른 항목입니다. Home에서 구독을 업데이트해도 현재 Config의 규칙이 원하는 순서로 자동 변경되지는 않습니다. 수정하기 전에 실제로 선택된 파일을 편집하는지 확인하고 복구할 수 있는 사본을 보관하세요.

1. 사본 저장

   Config에서 현재 선택된 파일을 확인하고 원본을 복사하거나 백업 파일로 내보내세요. 원격 업데이트에서 가져온 파일이라면 업데이트로 수정 내용이 덮어쓰이지 않도록 별도의 로컬 사본을 만들어 편집하세요.

2. 라우팅 모드 고정

   Home → Global Routing → Config로 이동하고 현재 선택된 연결은 그대로 유지하세요. 한 번의 검증 과정에서 라우팅 모드, 연결 및 규칙 파일을 동시에 바꾸지 마세요.

3. 규칙 편집

   Config → 현재 파일 오른쪽의 ⓘ → Edit Plain Text로 이동해 [Rule] 섹션을 찾습니다. 구체적인 예외를 범위 규칙 앞에 배치하고 FINAL은 목록 마지막에 한 번만 있는지 확인한 후 저장하세요.

4. 요청 새로 생성

   수정된 설정이 선택되어 있는지 확인하고 연결을 다시 설정한 다음 실제 테스트 페이지를 새로 여세요. 기존 연결을 계속 사용하는 장시간 연결이 있을 수 있으므로, 이전 연결을 재사용하는 페이지를 새로고침하는 것만으로 결론을 내리지 마세요.

5. 기록 확인

   이번 요청의 연결 기록에서 대상 도메인 또는 IP, 매칭된 규칙 및 처리 정책을 확인하세요. 경로가 잘못되었다면 규칙 순서를 조정합니다. 경로가 맞는데도 접속할 수 없다면 연결 자체와 대상 서비스를 확인하세요.

테스트는 최소 세 가지 대상을 포함해야 합니다. 구체적인 예외 규칙에 매칭되어야 하는 도메인 하나, 범위 규칙에 매칭되어야 하는 도메인 하나, FINAL로 넘어가야 하는 대상 하나입니다. 실제로 접속 권한이 있고 예상 경로를 알고 있는 대상을 사용하세요. example.com 계열 이름은 문법 설명용이며 연결 테스트 결과를 나타내지 않습니다.

자주 묻는 질문: 규칙이 적용되지 않을 때 먼저 확인할 곳

기록에 표시된 대상이 예상한 도메인과 다르면 페이지 이동, 리소스 도메인 및 이번 연결에서 실제로 사용한 주소를 확인하세요. 한 페이지에서도 여러 요청이 발생할 수 있습니다. 페이지 진입 도메인에 DIRECT를 추가해도 페이지에서 불러오는 모든 리소스가 같은 규칙에 매칭되는 것은 아닙니다. DOMAIN-SUFFIX 범위를 계속 넓히기보다 기록을 하나씩 확인하는 편이 영향을 관리하기 쉽습니다.

• 저장 전: 규칙 문법, 섹션 위치, 예외 순서 및 FINAL이 한 번만 있는지 확인합니다.
• 테스트 전: 선택한 파일, Config 모드 및 연결을 확인해 여러 조건을 동시에 바꾸지 않도록 합니다.
• 검증 후: 정상 작동하는 사본을 보관한 뒤 규칙을 추가하고, 문제가 생기면 검증이 끝난 이전 설정을 복원합니다.