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

이 글의 핵심

이 글은 Shadowrocket에서 직접 구성한 설정을 사용하며 도메인별로 특정 연결을 거부하려는 사용자를 위한 안내입니다. 먼저 매칭 조건과 REJECT 정책을 구분하고, 예시용 예약 도메인으로 규칙 순서와 예외 설정, 확인 방법을 설명합니다. 마지막으로 차단이 적용되지 않거나 페이지에 문제가 생길 때 확인할 사항을 살펴봅니다. 예시는 실제 이용 가능한 서비스 정보를 포함하지 않으며, 기존 설정 전체를 대체하는 용도로 사용할 수 없습니다.

1. REJECT는 정책이며, 대상을 식별하는 조건이 아닙니다

규칙은 보통 '무엇을 매칭할지'를 지정한 다음 '매칭되면 어떻게 처리할지'를 정합니다. DOMAIN-SUFFIX는 도메인 접미사를 매칭하는 조건이고, REJECT는 연결을 거부하는 정책입니다. 두 항목을 조합하면 조건에 맞는 도메인으로 연결을 설정하지 않습니다. 페이지를 분석해 특정 요소를 삭제하는 기능은 아닙니다.

요청이 터널에 진입 대상 정보 식별 규칙 순서대로 매칭 정책 적용

이 글의 규칙을 확인하려면 Home → Global Routing → Config에서 설정 기반 라우팅을 사용하고, 방금 수정한 설정이 활성화되어 있는지 확인하세요. Proxy, Direct, Scene의 라우팅 동작은 여기서 설명하는 Config 테스트 조건과 같지 않습니다. 연결 스위치가 켜져 있어도 지정한 규칙 파일이 판정에 사용된다는 뜻은 아닙니다.

Settings → On Demand에서는 조건에 따라 시스템이 VPN을 연결하거나 끊는 동작을 설정합니다. 특정 도메인의 정책을 REJECT로 바꾸는 기능은 아닙니다. 문제를 확인할 때는 '터널 연결 여부', '설정 활성화 여부', '요청이 매칭된 규칙'을 각각 확인하세요. 자동 연결 설정을 도메인 차단 스위치로 여기지 마세요.

3개 항목

DOMAIN-SUFFIX 예시: 키워드, 도메인, 정책으로 구성

2개 항목

FINAL 예시: 키워드와 기본 정책으로 구성

1개 규칙

일반적인 순차 매칭에서는 처음 매칭된 규칙이 정책을 결정합니다

2. DOMAIN과 DOMAIN-SUFFIX를 정확하게 작성하는 방법

아래 예시는 예약된 예시용 도메인을 사용하며 문법 설명만을 위한 것입니다. 규칙은 설정의 [Rule] 섹션에 작성하세요. 해당 섹션이 이미 있다면 기존 섹션을 편집하고, 규칙을 추가하려고 섹션을 중복해서 만들지 마세요. 도메인 필드에는 프로토콜, 경로, 포트, 쿼리 매개변수를 넣지 말고 쉼표는 영문 쉼표를 사용합니다.

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

이 간단한 예시에서 account.example.com은 먼저 정확히 일치하는 예외 규칙에 매칭되어 DIRECT로 처리됩니다. example.com과 img.example.com은 접미사 규칙에 매칭되어 REJECT로 처리됩니다. notexample.com은 해당 도메인의 접미사가 아니므로 문자열 끝부분이 비슷하다는 이유만으로 매칭되지 않습니다. 마지막 줄은 기본 정책의 위치를 보여줄 뿐, 기존 FINAL 정책을 DIRECT로 바꾸라는 뜻은 아닙니다.

정확한 도메인 규칙

키워드: DOMAIN
대상: metrics.example.com
정책: REJECT
전체 규칙: DOMAIN,metrics.example.com,REJECT

해당 도메인만 매칭하며 하위 도메인은 자동으로 포함하지 않습니다.

도메인 접미사 규칙

키워드: DOMAIN-SUFFIX
대상: metrics.example.com
정책: REJECT
전체 규칙: DOMAIN-SUFFIX,metrics.example.com,REJECT

해당 도메인과 하위 도메인을 매칭하며, 비슷한 이름의 별도 도메인은 포함하지 않습니다.

metrics.example.com만 거부하려는 경우 범위를 example.com 전체로 넓히지 마세요. 같은 루트 도메인에 로그인, 이미지, 결제 콜백, 통계 요청이 함께 있을 수 있습니다. 접미사 범위가 넓을수록 오차단 가능성도 커집니다. 먼저 DOMAIN으로 대상을 확인한 뒤 실제 요청을 살펴보고 DOMAIN-SUFFIX로 범위를 넓힐 필요가 있는지 판단하세요.

3. 규칙 순서: 구체적인 예외를 먼저, FINAL은 마지막에

일반적인 순차 매칭에서는 가장 먼저 매칭된 규칙이 처리 정책을 결정합니다. 뒤에 있는 구체적인 규칙이 앞의 포괄적인 규칙을 자동으로 덮어쓰지는 않습니다. 따라서 REJECT 규칙은 '파일에 한 줄 추가했다'는 것만으로 적용되지 않습니다. 요청이 해당 줄에 도달하기 전에 다른 조건에 매칭되지 않았는지 확인해야 합니다.

위치 또는 조건	가능한 판정	확인할 사항
정확한 DOMAIN 예외가 접미사 규칙보다 뒤에 있음	지정한 호스트가 먼저 예외 정책에 매칭됨	예외가 필요한지 확인하고, 유지할 호스트만 포함하도록 범위를 제한합니다
포괄적인 DOMAIN-SUFFIX가 정확한 규칙보다 앞에 있음	뒤에 있는 정확한 규칙은 이미 매칭된 요청을 처리하지 못함	규칙 순서를 조정하고 같은 규칙을 반복해서 추가하지 않습니다
앞에 있는 IP-CIDR 또는 GEOIP 규칙이 이미 매칭됨	요청이 먼저 IP 조건에 따라 처리될 수 있음	기록에서 실제 대상 정보와 매칭된 항목을 확인합니다
새 규칙보다 FINAL이 앞에 있음	요청이 기본 정책에 매칭되어 뒤의 규칙이 의도한 역할을 하지 못함	판정에 포함할 규칙을 FINAL 앞에 배치합니다

정리: 처음 매칭된 항목을 찾은 뒤 차단 범위를 조정하세요

요청 기록에 앞쪽 DIRECT 또는 PROXY 규칙이 매칭된 것으로 표시된다면 먼저 순서를 조정하세요. 접미사 규칙을 반복해서 추가해도 이미 끝난 판정은 달라지지 않습니다.

GEOIP는 IP의 지역 정보를 기준으로 매칭하고, IP-CIDR은 IP 주소 대역을 기준으로 매칭합니다. 둘 다 도메인 유형을 식별하는 규칙은 아닙니다. 도메인 규칙 하나를 고치려고 공유 IP 대역 전체를 차단하면 같은 인프라를 사용하는 다른 사이트에도 영향을 줄 수 있습니다. 주소 단위로 처리해야 할 명확한 이유가 없다면 IP 범위를 넓혀 도메인과 규칙 순서 확인을 대신하지 마세요.

4. 규칙 추가 및 결과 확인 단계

페이지 변화와 규칙의 관계를 확인하려면 한 번에 조건 하나만 수정하세요. 아래 절차는 사용자가 자신의 설정을 이미 보유하고 있다는 전제입니다. 프록시 연결이 필요하다면 본인이 사용하는 서비스 설정을 계속 사용하면 됩니다. 이 글에서는 서비스의 확보나 추천을 다루지 않습니다.

복구할 수 있는 사본을 보관하세요. Config에서 현재 사용 중인 설정을 확인하고, 먼저 복사본을 저장하거나 원래 내용을 기록해 두세요. 특히 기존 정책 이름, DNS 설정, FINAL을 보존해야 합니다. 이 글의 간단한 예시를 완성된 사용 가능 설정으로 가져오지 마세요.
실제 대상을 확인하세요. 연결 기록이나 요청 기록에서 문제가 발생한 요청의 대상 도메인을 확인합니다. 웹페이지 제목으로 추측하지 말고 호스트 이름 전체를 기록하세요. 페이지 주소와 이미지 또는 API 요청의 실제 호스트가 다를 수 있습니다.
최소 규칙을 추가하세요. 현재 설정의 [Rule] 섹션에 DOMAIN,metrics.example.com,REJECT 형식으로 규칙을 한 줄 추가하고, 예시 도메인을 확인된 대상으로 바꾸세요. 관련된 포괄 매칭 규칙과 FINAL보다 앞에 배치합니다.
테스트 조건을 확인하세요. 설정을 저장한 뒤 Home에서 현재 설정과 Global Routing → Config를 확인하고 연결 상태도 점검하세요. 현재 연결 상태가 불안정하다면 먼저 기본 연결 문제를 해결한 다음 규칙을 테스트합니다.
요청을 다시 발생시키세요. 페이지를 새로 열거나 대상 앱을 종료한 뒤 다시 실행해 새로운 연결을 발생시키세요. 해당 기록에서 대상, 매칭 항목, 정책을 확인하고, 페이지의 특정 요소가 사라졌는지만으로 판단하지 마세요.
한 번에 하나씩 되돌려 확인하세요. 방금 추가한 규칙 하나만 제거하고 저장한 뒤 같은 동작을 다시 수행합니다. 기능이 복구되는지 비교하세요. 변화가 없다면 다른 요청을 점검하고, 규칙 묶음 전체를 한꺼번에 삭제하지 마세요.

대상 사이트가 HTTPS에 사용하는 일반적인 포트는 443이지만, DOMAIN,metrics.example.com,REJECT는 포트를 443으로 제한하지 않습니다. 이 규칙은 도메인 조건을 지정하며 URL, 요청 방식 또는 포트 조건을 지정하지 않습니다. :443이 포함된 전체 주소를 도메인 필드에 입력하지 마세요.

5. 규칙의 적용 범위를 벗어나는 요청과 페이지 콘텐츠

도메인 규칙은 매칭 가능한 연결 대상을 처리할 뿐, 페이지 콘텐츠를 분류하지 않습니다. 하나의 도메인에서 본문, 이미지, 추천 콘텐츠, 로그인 API를 모두 제공할 수 있고, 하나의 연결이 여러 요청을 처리할 수도 있습니다. DOMAIN-SUFFIX만으로는 그중 어떤 콘텐츠를 유지해야 하는지 판단할 수 없습니다.

같은 도메인에서는 경로별로 구분할 수 없습니다.example.com/news와 example.com/banner는 도메인이 같습니다. 이 규칙으로는 뒤쪽 경로만 기준으로 둘 중 하나를 거부할 수 없습니다.
앱에 이미 캐시된 콘텐츠는 삭제되지 않습니다. 이전에 불러온 이미지나 로컬 캐시가 계속 표시될 수 있습니다. 콘텐츠가 남아 있다는 사실만으로 새 요청이 규칙을 우회했다고 단정할 수 없습니다. 실제 연결이 발생했는지 확인하세요.
기존의 장시간 연결은 즉시 다시 판정된다고 보장할 수 없습니다. 규칙을 저장한 뒤에도 이미 설정된 연결이 계속 사용될 수 있습니다. 기존 페이지가 저절로 바뀌기를 기다리지 말고 연결을 새로 시작한 다음 결과를 확인하세요.
IP로 직접 연결하면 도메인 조건을 확인할 수 없을 수도 있습니다. 클라이언트가 확인할 수 있는 대상이 IP뿐이라면 DOMAIN-SUFFIX 규칙이 반드시 매칭된다고 가정하지 마세요. 먼저 기록에 표시된 대상 정보를 확인하세요.
현재 터널을 통과하지 않는 트래픽은 해당 규칙의 판정을 받지 않습니다. 터널 연결이 끊겼거나 시스템 라우팅 또는 기타 우회 조건이 적용되었는지는 규칙 내용과 별도로 확인해야 합니다.

DNS 조회 기록이 최종 연결 처리 기록과 같은 것은 아닙니다. 도메인 조회에 성공한 뒤에도 연결이 REJECT될 수 있고, 반대로 DNS 조회가 실패하면 연결이 예상한 규칙 확인 단계에 도달하지 못할 수 있습니다. 판정할 때는 조회, 규칙 매칭, 연결 결과를 각각 기록하세요.

6. 페이지 오류 및 차단이 적용되지 않을 때 자주 묻는 질문

오차단은 로그인 반복 이동, 빈 이미지, 계속 대기하는 버튼, 완료되지 않는 인증 절차 등으로 나타날 수 있습니다. 이런 현상은 의존 요청이 실패했을 가능성을 보여줄 뿐, 해당 요청을 허용해야 한다는 증거는 아닙니다. 추가한 규칙과 실제 매칭 기록을 대조하고 범위를 하나씩 좁히세요.

REJECT를 추가했는데도 페이지가 왜 정상적으로 열리나요?

먼저 대상이 실제로 차단 도메인에 요청을 보내는지 확인한 다음 Home → Global Routing → Config와 현재 설정을 점검하세요. 페이지의 주요 부분이 정상적으로 표시된다고 규칙이 실패한 것은 아닙니다. 대상 요청이 부가 리소스일 수 있으므로 새 연결의 매칭 정책을 확인하세요.

통계 도메인을 차단한 뒤 로그인이 되지 않는 이유는 무엇인가요?

루트 도메인 전체를 대상으로 하는 DOMAIN-SUFFIX를 잘못 사용했는지 확인하세요. 방금 추가한 규칙을 되돌리고 다시 로그인해 보세요. 기능이 복구되면 확인된 정확한 도메인에 DOMAIN을 사용하세요. 유지해야 할 로그인 호스트가 있다면 명확한 예외 규칙을 더 앞에 두고, 정책은 기존 설정의 정상적인 접속 경로를 따르세요.

기록에는 REJECT가 표시되는데 DNS 요청이 계속 보이는 이유는 무엇인가요?

DNS 조회와 연결은 서로 다른 단계입니다. 조회 기록이 있다고 해서 앱이 대상에 성공적으로 접속했다는 뜻은 아닙니다. 해당 연결이 거부되었는지 추가로 확인하세요. DNS 기록 하나를 없애려고 도메인이나 IP 차단 범위를 넓히지 마세요.

설정을 업데이트한 뒤 직접 추가한 규칙이 사라진 이유는 무엇인가요?

업데이트한 항목이 노드 구독인지 전체 설정 파일인지 확인하세요. 두 항목은 서로 다릅니다. 원격 설정을 업데이트하면 로컬에서 편집한 내용이 대체될 수 있습니다. 업데이트 전후의 사본을 비교하고 현재 활성화된 파일을 확인한 뒤, 검증된 필수 규칙을 복원하세요.

규칙 하나를 삭제한 뒤에도 문제가 계속되면 네트워크, DNS, 서버 응답을 추가로 확인하세요. 모든 오류를 REJECT 탓으로 돌리지 마세요. 기본 연결 상태 확인은 문제 해결 안내를 참고하세요. Config와 Home의 역할이 익숙하지 않다면 먼저 시작 안내에서 설정을 활성화하는 방법을 확인하세요.