Shadowrocket REJECT 규칙 사용법: 도메인 차단 범위와 한계

이 글 한눈에 보기

이 글은 Shadowrocket에서 구성을 활성화했으며 차단 규칙을 추가하거나 문제를 해결하려는 사용자를 위한 안내입니다. 먼저 ‘매칭 조건’과 ‘처리 정책’을 구분하고, 최소 규칙 예시로 매칭 순서를 확인한 다음 같은 도메인의 요청, 암호화된 연결, 캐시가 차단 효과에 미치는 영향을 살펴봅니다. 도메인과 주소는 모두 예시입니다. 연결 테스트는 이미 이용 중인 서비스 제공업체와 구독이 있다는 전제로 진행합니다.

1. REJECT는 처리 정책이며 콘텐츠 식별 규칙이 아닙니다

Shadowrocket의 규칙에는 보통 매칭 조건과 처리 정책이 함께 포함됩니다. 예를 들어 DOMAIN-SUFFIX,example.com,REJECT에서 앞의 두 항목은 어떤 연결이 조건에 해당하는지 정하고, 마지막의 REJECT는 규칙에 매칭된 연결을 거부합니다. 페이지에 특정 단어나 이미지, 레이아웃이 있다는 이유만으로 해당 콘텐츠를 자동으로 찾아 삭제하지는 않습니다.

구성에 따라 트래픽을 분기하는 경우 다음 다섯 단계로 이해할 수 있습니다. 이는 규칙 처리 과정에 관한 설명이며, 클라이언트가 모든 연결에서 완전한 도메인 정보를 얻을 수 있다거나 암호화된 요청의 본문을 읽을 수 있다는 뜻은 아닙니다.

앱에서 연결 시작 터널로 트래픽 전달 매칭 정보 확인 규칙을 순서대로 확인 매칭된 정책 실행

규칙은 일반적으로 위에서 아래로 확인하며, 처음 매칭되는 규칙의 정책을 실행합니다. 따라서 파일 맨 아래에 정확한 차단 규칙을 추가해도 실행되지 않을 수 있습니다. 앞쪽의 포괄적인 규칙에서 이미 DIRECT나 다른 정책에 매칭되었을 수 있기 때문입니다. 문제를 확인할 때는 파일에 REJECT가 있는지만 검색하지 말고, ‘무엇이 매칭되었는지’와 ‘최종적으로 어떤 정책이 실행되었는지’를 함께 살펴봐야 합니다.

항목 3개

DOMAIN-SUFFIX 예시의 필드: 유형, 접미사, 정책

항목 2개

FINAL 예시의 필드: 유형, 기본 정책

규칙 1개

규칙 판정은 처음 매칭된 규칙에 따라 처리 결과가 결정됩니다

2. 최소 규칙으로 DOMAIN과 DOMAIN-SUFFIX 확인하기

먼저 Config에서 현재 구성을 백업한 다음, 테스트용 복사본을 편집합니다. 아래 예시는 [Rule]의 매칭 관계만 보여 주며, 기존 설정을 그대로 대체할 수 있는 전체 구성은 아닙니다. 예시에는 실제 차단 대상과 무관한 테스트용 도메인을 사용했습니다.

[Rule]
DOMAIN,account.example.com,DIRECT
DOMAIN-SUFFIX,example.com,REJECT
FINAL,DIRECT

이 순서에서는 account.example.com이 먼저 정확한 예외 규칙에 매칭됩니다. media.example.com과 루트 도메인 example.com은 뒤의 접미사 규칙에 따라 거부되고, 해당 접미사에 속하지 않는 연결은 FINAL에 전달됩니다. 여기서 DIRECT를 선택한 것은 규칙의 작동 방식을 설명하기 위한 것으로, 실제 사용 시 매칭되지 않은 모든 트래픽을 직접 연결로 바꾸라는 뜻은 아닙니다.

정확한 예외

키워드: DOMAIN
매칭 값: account.example.com
정책: DIRECT
배치 위치: 포괄적인 접미사 규칙보다 앞

해당 호스트 이름만 허용하며 하위 도메인까지 자동으로 허용하지는 않습니다.

접미사 차단

키워드: DOMAIN-SUFFIX
매칭 값: example.com
정책: REJECT
적용 범위: 루트 도메인과 하위 도메인

접미사 필드에는 https://, 경로, 포트를 입력하지 않으며 별표도 필요하지 않습니다.

저장한 뒤에는 이 복사본이 Config에서 현재 구성으로 선택되어 있는지 확인하고, Home → Global Routing에서 Config를 선택해야 합니다. Proxy나 Direct는 구성 규칙을 활성화하는 것과 같은 설정이 아닙니다. Scene을 사용하는 경우에는 해당 Scene이 최종적으로 적용하는 라우팅 동작도 확인하세요. 수정 전부터 연결되어 있던 연결을 재사용하지 않도록 테스트 연결을 새로 만드세요.

결론: 정확한 호스트 이름부터 확인한 다음 범위를 넓히세요

먼저 DOMAIN 규칙을 하나 추가하고 매칭 기록을 확인하세요. 대상과 영향 범위를 확인한 다음 DOMAIN-SUFFIX로 바꿀지 결정합니다. 처음부터 플랫폼 전체의 루트 도메인을 차단하지 마세요.

3. REJECT와 REJECT-DROP의 차이는 거부 방식입니다

REJECT와 REJECT-DROP는 모두 연결을 거부하는 정책이지만, 거부 결과를 전달하는 방식이 다릅니다. 일반적으로 REJECT는 연결 실패를 비교적 빠르게 알리고, REJECT-DROP는 요청을 조용히 버려 요청 측에서 타임아웃될 때까지 기다리게 합니다. 실제 오류 동작은 TCP, UDP, 앱의 재시도 방식과 현재 구현에 따라 달라지므로 모든 앱에서 요청이 즉시 중단된다고 보장할 수는 없습니다. 사용할 수 있는 정책 이름은 현재 클라이언트의 규칙 편집기와 지원 여부를 기준으로 확인하세요.

정책	처리 방식	확인할 현상
`REJECT`	연결을 거부하고 대체로 빠르게 실패를 알립니다	앱에서 즉시 오류가 표시되거나 곧바로 대체 도메인을 시도할 수 있습니다
`REJECT-DROP`	요청을 조용히 버리고 요청 측에서 타임아웃될 때까지 기다립니다	앱에서 로딩이 오래 지속되거나 요청을 반복해서 보낼 수 있습니다

두 정책 모두 거부 결과가 자동으로 ‘페이지에서 콘텐츠가 올바르게 숨겨진 상태’가 되지는 않습니다. 앱은 연결 실패 후 빈 영역을 남기거나 오류 아이콘을 표시하고, 대체 API를 사용할 수 있습니다. REJECT-DROP가 도메인 매칭을 더 강하게 해 준다고 생각해서도 안 됩니다. 연결이 해당 규칙에 매칭되지 않았다면 마지막 정책만 바꿔도 매칭 범위는 넓어지지 않습니다.

규칙이 매칭되는지 확인할 때는 로딩 애니메이션의 지속 시간으로 추측하지 말고 먼저 요청 기록을 확인하세요.
로딩 표시가 계속 돌면 로그인, 인증 또는 초기화 API가 거부되었는지 먼저 확인하세요.
거부 정책을 바꿀 때는 한 번에 변수 하나만 수정하고, 같은 동작을 다시 실행해 차이를 기록하세요.

4. 도메인 차단의 한계: 같은 도메인의 콘텐츠, HTTPS, 공유 주소

차단하려는 리소스가 별도 도메인을 사용한다면 도메인 규칙으로 범위를 구분하기가 비교적 쉽습니다. 하지만 정상 콘텐츠와 대상 리소스가 모두 api.example.com에서 제공되고 경로만 /content와 /promotion으로 다르다면, DOMAIN과 DOMAIN-SUFFIX로 둘을 구별할 수 없습니다. 해당 호스트 이름을 거부하면 본문, 로그인, 계정 상태 확인까지 중단될 수 있습니다.

대상 포트가 443인 일반적인 HTTPS 연결에서 도메인 규칙을 사용한다고 해서 HTTP 요청이 복호화되는 것은 아닙니다. URL 경로, 쿼리 매개변수, 응답 본문은 암호화되어 있으므로 도메인 규칙에 경로를 추가해 콘텐츠 단위로 필터링할 수 없습니다. 이 글의 규칙 예시도 HTTPS 복호화를 다루지 않습니다.

요청 유형	도메인 규칙으로 구분할 수 있는지	주의할 점
`track.example.com`과 `api.example.com`	호스트 이름별로 각각 매칭할 수 있습니다	앞의 호스트가 필수 기능을 담당하는지 확인해야 합니다
같은 호스트 이름에 있는 두 HTTPS 경로	DOMAIN만으로 경로를 구분할 수 없습니다	도메인 필드에 전체 URL을 입력하지 마세요
여러 도메인이 하나의 서비스 주소를 공유	IP로 차단하면 도메인 단위로 구분할 수 없습니다	다른 정상 서비스에도 영향을 줄 수 있습니다
앱이 로컬 캐시를 읽는 경우	새 연결이 없으면 매칭할 요청도 없습니다	페이지가 계속 표시되어도 규칙이 실패했다는 뜻은 아닙니다

도메인 규칙을 IP-CIDR로 바꿔도 같은 도메인에 콘텐츠가 섞여 있는 문제는 해결되지 않습니다. 예를 들어 IP-CIDR,192.0.2.10/32,REJECT는 예시용 IPv4 주소를 거부한다는 뜻이지 특정 웹사이트만 차단한다는 뜻은 아닙니다. 192.0.2.0/24는 더 넓은 범위를 차단합니다. 실제 서비스는 여러 주소나 IPv6를 사용할 수도 있어 주소 범위를 무작정 넓히면 오탐이 생기기 쉽고, 차단 범위를 완전히 포함한다고 보장할 수도 없습니다.

결론: 같은 도메인에 콘텐츠가 섞여 있다면 기능을 유지한 뒤 차단 여부를 판단하세요

정상 기능과 대상 리소스가 같은 호스트 이름을 사용한다면 먼저 포괄적인 거부 규칙을 해제해 기능을 복구하세요. 독립적으로 확인할 수 있는 요청 도메인을 찾은 경우에만 범위가 더 좁은 규칙을 추가하고, 콘텐츠를 구분하는 대신 주소 전체를 차단하지 마세요.

5. 규칙이 효과가 없을 때 근거를 따라 단계별로 확인하기

‘기존 콘텐츠가 계속 보인다’는 사실만으로 규칙이 작동하지 않는다고 단정할 수는 없습니다. 앱이 새 요청을 보내지 않았거나 요청이 대체 호스트 이름으로 전달되었을 수 있고, 현재 연결이 예상한 규칙 경로를 거치지 않았을 수도 있습니다. 변경 전후의 구성 복사본을 보관하고 테스트 시간, 조작 내용, 대상 호스트 이름, 최종 정책을 기록하면 문제를 재현하기 쉽습니다.

현재 구성과 라우팅 모드를 확인합니다. Config에서 활성화된 파일을 확인한 다음 Home → Global Routing → Config를 확인하세요. 파일을 저장하기만 하고 활성화하지 않으면 현재 연결에 영향을 주지 않습니다.
네트워크 요청을 새로 발생시킵니다. 저장한 뒤 연결을 끊었다가 다시 연결하고, 필요한 경우 대상 앱을 종료한 후 다시 실행하세요. 페이지를 새로고침할 때 캐시를 읽는 데 그치지 않고 새 요청이 실제로 발생하는지 확인하세요.
요청 기록을 확인합니다. 클라이언트의 연결 또는 요청 기록에서 테스트 시간에 해당하는 항목을 찾아, 표시되는 호스트 이름과 대상 주소, 매칭 규칙, 최종 정책을 확인하세요. REJECT라는 글자만 보아서는 충분하지 않습니다. 해당 항목이 이번에 확인하려는 요청인지 확인해야 합니다.
규칙 순서와 확인 가능한 정보를 점검합니다. 더 포괄적인 허용 규칙이 먼저 매칭되었는지 확인하세요. 기록에 IP만 표시된다면 DOMAIN-SUFFIX에 필요한 도메인 정보가 반드시 있다고 가정할 수 없습니다. 앱이 암호화 DNS를 직접 사용하거나 주소에 직접 연결하는지도 확인하세요.
한 가지씩 비교 테스트합니다. 방금 추가한 규칙 하나를 임시로 비활성화하고 같은 동작을 반복하세요. 규칙을 다시 활성화했을 때 문제가 발생한다면 해당 규칙이 원인과 관련 있을 수 있습니다. 그다음 거부 규칙을 계속 추가하는 대신 매칭 범위를 좁히세요.

규칙 순서를 확인할 때는 GEOIP, IP-CIDR, FINAL도 함께 살펴봐야 합니다. 이들은 콘텐츠 분류기가 아닙니다. GEOIP는 주소의 위치 정보를 기준으로 매칭하고, IP-CIDR는 주소 범위를 기준으로 매칭하며, FINAL은 앞선 규칙에 매칭되지 않은 연결을 처리합니다. 포괄적인 규칙이 먼저 매칭되면 뒤에 있는 대상 도메인 규칙은 실행되지 않습니다.

6. 자주 묻는 질문: 오탐, 캐시, 구성 업데이트

규칙을 추가한 뒤 로그인이 되지 않으면 어떤 규칙부터 삭제해야 하나요?

먼저 이번에 추가한 REJECT 규칙을 임시로 비활성화하고 로그인을 다시 시도해 복구되는지 확인하세요. 그런 다음 로그인 시점의 요청 기록을 살펴보고 루트 도메인까지 포함하는 DOMAIN-SUFFIX 규칙을 우선 확인합니다. 특정 인증 호스트 이름을 유지해야 한다는 점을 확인했다면 포괄적인 규칙보다 앞에 정확한 예외를 추가하고 기존에 정상 작동하던 정책 경로를 사용하세요. 확인 없이 플랫폼 전체를 허용하지 마세요.

기록에는 REJECT가 표시되는데 페이지에 콘텐츠가 계속 보이는 이유는 무엇인가요?

먼저 해당 기록이 다른 백그라운드 연결이 아니라 그 페이지에서 이번에 발생한 요청인지 확인하세요. 이어서 페이지를 다시 열어 새 연결이 생기는지 살펴봅니다. 이미 캐시된 이미지와 다운로드한 콘텐츠, 앱에 내장된 리소스는 연결이 거부되어도 자동으로 사라지지 않습니다. 규칙은 페이지의 빈 공간을 접어 숨기는 기능도 제공하지 않습니다.

앱에서 다른 도메인으로 요청을 보내기 시작하면 새 도메인을 모두 차단해야 하나요?

나타난 순서대로 규칙을 한꺼번에 추가하지 마세요. 각 호스트 이름이 어떤 동작 중에 나타났는지 비교해 대상 기능과 관련이 있는지 판단한 다음, 한 번에 하나씩 테스트하세요. 대체 API가 정상 콘텐츠도 함께 처리할 수 있습니다. 용도를 확인하지 못한 로그인, 결제, 동기화 요청은 우선 유지해야 합니다.

구독을 업데이트한 뒤 사용자 지정 REJECT 규칙이 사라진 이유는 무엇인가요?

먼저 Home의 연결 항목에서 구독을 업데이트한 것과 Config의 구성 파일을 업데이트한 것을 구분하세요. 둘은 서로 다른 작업입니다. 현재 활성화된 파일이 바뀌었는지, 원격 구성 업데이트가 수동 변경 사항을 덮어썼는지 확인하세요. 로컬 테스트 복사본과 사용자 지정 규칙 목록을 보관하고, 업데이트할 때마다 파일 내용과 규칙 순서를 비교하세요. 연결 항목이 그대로 있다는 이유만으로 규칙도 유지되었다고 판단하지 마세요.

차단이 적절한지 판단할 때는 세 가지를 확인해야 합니다. 요청이 현재 규칙 경로를 거치는지, 클라이언트가 매칭에 필요한 정보를 얻는지, 대상 리소스를 필수 기능과 분리할 수 있는지입니다. 이 조건이 충족되면 정확한 규칙을 사용하고 되돌릴 수 있는 구성 복사본을 보관하세요. 분리할 수 없다면 더 넓은 규칙으로 문제를 가리기보다 도메인 단위 처리의 한계를 받아들여야 합니다.