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

이 글의 핵심

REJECT는 규칙에 일치하는 연결을 처리하며 웹페이지의 개별 요소를 제거하지는 않습니다. Shadowrocket에서 이미 사용 중인 구성을 점검하려는 사용자를 위해 Config 모드와 규칙 순서를 확인하고, 정확한 도메인으로 차단을 시험한 뒤 도메인 정보 비노출, 연결 재사용, 같은 도메인의 콘텐츠라는 세 가지 한계를 구분하는 방법을 안내합니다.

REJECT의 적용 범위

REJECT는 규칙의 처리 정책이지 매칭 키워드가 아닙니다. DOMAIN,ads.example.com,REJECT는 세 부분으로 나뉩니다. DOMAIN은 매칭 방식을 지정하고, ads.example.com은 매칭할 값이며, REJECT는 규칙이 일치하면 해당 연결을 거부한다는 뜻입니다. DIRECT나 프록시 정책으로 연결을 계속 전달하지 않습니다.

앱 요청 터널 처리 규칙 매칭 REJECT 일치 연결 거부

이 흐름은 요청이 Shadowrocket의 처리 범위에 들어왔다는 전제에서 성립합니다. 연결이 꺼져 있거나 예상한 구성이 활성화되지 않았거나 현재 라우팅 모드에서 해당 규칙을 사용하지 않는다면, REJECT 한 줄을 추가하는 것만으로 차단이 적용되지는 않습니다. 연결이 거부되면 앱에 빈 화면이나 로딩 오류가 표시되거나 재시도가 이어질 수 있습니다. 화면에 나타나는 현상은 앱 자체의 오류 처리 방식에 따라 달라집니다.

REJECT는 콘텐츠를 지우는 기능도 아닙니다. 이미 다운로드된 이미지, 로컬 캐시 데이터, 앱에 미리 저장된 프로모션 화면은 규칙을 추가해도 바로 사라지지 않습니다. 효과를 확인할 때는 화면에 무엇이 남았는지만 보지 말고 새 요청이 거부됐는지 확인하세요.

Config와 규칙 순서 먼저 확인하기

Home에서 Global Routing을 Config로 설정한 다음 Config에서 현재 활성화된 구성을 확인합니다. Proxy 또는 Direct 모드에서 보이는 화면만으로 Config의 규칙이 적용되는지 판단하지 마세요. 기존에 Scene을 사용했다면 먼저 장면 설정을 기록한 뒤, 자동 전환의 영향을 줄이도록 Config를 지정한 상태에서 시험합니다.

Config에서 기존 구성의 사본을 보관하고, 활성화할 파일을 편집하고 있는지 확인합니다.
해당 구성의 [Rule] 부분에 테스트 규칙을 추가하고, 먼저 일치할 수 있는 포괄적인 규칙과 FINAL보다 앞에 배치합니다.
구성을 저장하고 활성화한 다음 Home으로 돌아와 Global Routing → Config인지 확인하고 연결 상태도 점검합니다.
대상 앱에서 새 연결을 생성한 뒤 연결 기록에서 대상, 일치한 규칙, 처리 정책을 확인합니다. 페이지를 한 번 새로 고친 것만으로 결론을 내리지 마세요.

일반 규칙은 나열된 순서대로 확인하며, 먼저 일치한 규칙이 처리 결과를 결정합니다. 아래는 구조를 보여 주기 위한 예시일 뿐이며 example.com 계열 도메인은 실제 차단 목록이 아닙니다. FINAL,DIRECT도 기본 처리 방식을 설명하는 예시이므로 기존 구성의 최종 정책을 덮어쓰지 마세요.

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

DOMAIN-SUFFIX,example.com,DIRECT를 첫 번째 줄에 두면 ads.example.com 요청이 이 규칙에 먼저 일치해 뒤에 있는 정확한 거부 규칙이 처리하지 못합니다. 유지할 예외, 차단할 구체적인 대상, 포괄적인 규칙을 실제 우선순위에 맞게 배치하세요. 마지막에 추가한 규칙이 우선한다고 생각하면 안 됩니다.

정확한 도메인과 접미사 매칭 중 선택하기

단일 대상을 점검할 때는 DOMAIN부터 시작하면 적용 범위를 쉽게 통제할 수 있습니다. 하위 도메인 분기 전체가 같은 용도로 쓰이는 것을 확인한 뒤에만 DOMAIN-SUFFIX로 바꾸세요. 하위 도메인 하나에서 원치 않는 요청이 발생했다고 해서 주 도메인 전체를 바로 차단하지 마세요.

정확한 매칭

키워드: DOMAIN
매칭 값: ads.example.com
정책: REJECT
범위: ads.example.com만

img.ads.example.com에는 적용되지 않으므로 특정 대상을 먼저 확인할 때 적합합니다.

접미사 매칭

키워드: DOMAIN-SUFFIX
매칭 값: metrics.example.com
정책: REJECT
범위: 해당 도메인과 하위 도메인

metrics.example.com과 api.metrics.example.com을 모두 포함하므로 사용 목적을 먼저 확인해야 합니다.

DOMAIN-KEYWORD는 도메인에 포함된 키워드로 매칭하므로, 특정 접미사 하나를 지정하는 것보다 범위를 제어하기 어렵습니다. 예를 들어 ad만 키워드로 사용하면 대상 서비스가 아닌 여러 도메인까지 걸릴 수 있습니다. IP-CIDR은 IP 대역을 기준으로, GEOIP는 IP의 지역 정보를 기준으로 처리합니다. 둘 다 “웹페이지의 특정 영역”을 지정할 수는 없습니다. 여러 도메인이 서버나 IP를 공유하는 경우 IP를 차단하면 다른 도메인에도 영향을 줄 수 있습니다.

정리: 매칭 범위를 좁게 시작한 뒤 확장하기

먼저 DOMAIN 규칙 하나로 대상의 용도와 매칭 결과를 확인하세요. 하위 도메인 분기를 모두 차단해도 된다고 확인한 다음 DOMAIN-SUFFIX로 바꾸고, 첫 시험부터 주 도메인 전체를 대상으로 삼지 마세요.

같은 도메인의 콘텐츠는 페이지 위치별로 분리할 수 없습니다

본문 API가 api.example.com/content에, 프로모션 API가 api.example.com/promo에 있다고 가정해 보겠습니다. 두 요청은 도메인을 공유하므로 일반적인 DOMAIN 및 DOMAIN-SUFFIX 규칙은 URL 경로를 기준으로 구분하지 않습니다. api.example.com을 차단하면 프로모션 요청만이 아니라 두 종류의 연결이 모두 영향을 받습니다.

도메인이 다른 경우: 콘텐츠는 api.example.com, 추가 요청은 ads.example.com으로 전송된다면 정확한 도메인 규칙으로 분리할 수 있습니다. 다만 두 요청 사이에 기능상 의존성이 있는지 확인해야 합니다.
같은 도메인, 다른 경로: 도메인 규칙으로 /content와 /promo를 따로 처리할 수 없습니다.
하나의 응답에 여러 종류의 콘텐츠가 포함된 경우: 본문과 프로모션 데이터가 한 응답으로 전달되면 연결을 거부할 때 둘 다 차단됩니다. 특정 필드만 제거할 수는 없습니다.
앱 로컬 콘텐츠: 오프라인 리소스나 이미 캐시된 화면은 새 연결을 만들 필요가 없으므로 새로운 네트워크 규칙 매칭이 발생하지 않습니다.

HTTPS에서 일반적으로 사용하는 목적지 포트는 443이지만, 포트만으로 요청의 용도를 알 수는 없습니다. 일반적인 도메인 규칙으로 암호화된 요청의 경로나 본문을 확인할 수 있는 것도 아닙니다. 앱 내 웹페이지도 마찬가지입니다. 브라우저에 표시되는지 앱 안에 표시되는지가 아니라, 대상 연결이 별도로 생성되는지와 매칭에 쓸 도메인 정보가 있는지가 중요합니다.

암호화 DNS와 도메인 표시 범위

도메인 규칙을 적용하려면 매칭에 사용할 도메인 정보가 있어야 합니다. 앱이 시스템 DNS를 사용하면 DNS 조회와 연결을 연관 지을 수 있는 경우가 있습니다. 앱이 자체적으로 DoH나 DoT를 사용하면 DNS 조회 내용은 별도의 암호화된 연결로 전송되므로, 목적지 IP만으로 Shadowrocket이 조회된 도메인을 알아낼 수 있다고 단정할 수 없습니다. 다른 연결 메타데이터를 활용할 수 있는지도 실제 트래픽과 설정에 따라 달라집니다.

상황	확인할 내용	단정할 수 없는 내용
일반 DNS	DNS 조회와 연결의 연관성, 대상 도메인, 실제로 일치한 규칙	DNS 조회가 한 번 보였다고 해서 이후 연결이 REJECT 규칙에 일치한다고 볼 수는 없습니다.
앱 내 DoH	별도의 DNS 서버에 연결하는지, 대상 연결에 도메인 정보가 남아 있는지	DoH는 보통 443을 사용하지만, 443 연결이 모두 DNS인 것은 아닙니다.
앱 내 DoT	목적지 포트 853 연결이 있는지와 그 용도	포트 정보만으로 조회 내용을 알아낼 수는 없습니다.
IP에 직접 연결	연결 기록에 IP만 표시되는지, 연관된 다른 도메인 정보가 있는지	DOMAIN 규칙이 해당 연결과 반드시 일치한다고 볼 수는 없습니다.

이런 경우에는 먼저 Settings의 DNS 설정과 앱 자체의 DNS 옵션을 확인하세요. 자세한 내용은 DNS 설정 참고를 참조하세요. 알고 있는 DNS 서버를 차단하면 앱의 DNS 조회가 실패하거나 예비 서버를 사용하게 될 수 있습니다. 그렇다고 대상 콘텐츠가 차단된 것은 아닙니다. 특히 “모든 443 연결 차단”으로 도메인 문제를 해결하려고 하지 마세요. 일반 HTTPS 접속까지 영향을 받습니다.

다시 확인할 수 있는 차단 테스트 진행하기

테스트에서는 한 번에 변수 하나만 바꾸세요. 페이지의 빈 영역, 로딩 시간, 오류 메시지는 간접적인 현상입니다. 더 유용한 근거는 대상이 무엇인지, 어떤 규칙이 먼저 일치했는지, 최종적으로 어떤 정책이 적용됐는지입니다. 아래 절차는 이미 보유한 구성을 점검하기 위한 것으로, 연결 서비스를 구하는 방법은 다루지 않습니다.

기준 상태 기록: 현재 구성을 저장하고 Global Routing 모드, 대상 도메인, 규칙을 추가하지 않았을 때의 화면 상태를 기록합니다.
규칙 하나만 추가: 확인한 대상을 DOMAIN,ads.example.com,REJECT와 같은 완전한 규칙으로 추가합니다. 실제 테스트에는 직접 기록한 도메인을 사용하고 예시 도메인을 유효한 목록으로 여기지 마세요.
연결 다시 만들기: 대상 앱을 종료했다가 다시 열고, 필요한 경우 Shadowrocket 연결도 다시 설정합니다. 이미 열린 장기 연결이 재사용될 수 있으므로 한 번 새로 고치는 것만으로 새 규칙 판정이 발생하지 않을 수 있습니다.
매칭 결과 확인: 새 연결의 대상, 규칙, 정책을 확인합니다. 여전히 DIRECT 또는 프록시 정책이 적용됐다면 구성이 활성화됐는지, 앞에 더 먼저 일치하는 규칙이 있는지 점검합니다.
다른 기능에 미치는 영향 확인: 로그인, 본문 로딩, 이미지 표시, 제출 작업을 차례로 테스트합니다. 문제가 생기면 추가한 규칙을 되돌리고 같은 작업을 다시 수행해 결과를 비교합니다.

자동 연결 상태도 기록해야 합니다. Settings → On Demand는 조건에 따른 연결 동작을 관리하며 REJECT 규칙을 대체하지 않습니다. 테스트 중 네트워크에 따라 연결 상태가 바뀐다면 요청이 발생한 시점에 트래픽이 터널을 통과했는지 먼저 확인하세요. On Demand, DNS, 규칙 목록을 동시에 변경하면 어떤 변경이 결과에 영향을 줬는지 파악하기 어렵습니다.

자주 발생하는 상황과 해결 방법

REJECT를 추가했는데 페이지의 콘텐츠가 계속 보이는 이유는 무엇인가요?

먼저 대상 앱을 다시 열고 REJECT에 일치하는 새 연결이 생성됐는지 확인하세요. 기록에 거부된 연결이 있는데도 화면이 그대로라면 캐시, 로컬 리소스 또는 한 응답에 여러 콘텐츠가 포함됐을 가능성을 점검하세요. 주 도메인 전체로 차단 범위를 바로 넓히지는 마세요.

차단하자마자 로그인이 안 되는 이유는 무엇인가요?

추가한 규칙을 먼저 되돌린 뒤 로그인을 다시 시험하세요. 기능이 복구된다면 DOMAIN-SUFFIX를 확인된 DOMAIN으로 범위를 좁히고, 인증 API와 추가 요청을 각각 확인합니다. 같은 도메인에 여러 용도가 있다면 필요한 연결은 유지해야 합니다.

연결 기록에 IP만 표시되고 도메인이 보이지 않는 이유는 무엇인가요?

앱이 IP에 직접 연결하는지, 자체 암호화 DNS를 사용하는지 확인하고 Settings의 DNS 설정도 살펴보세요. 해당 IP를 무작정 전체 대역으로 확대해 차단하지 마세요. 여러 서비스가 같은 주소를 사용할 수 있으므로 대상과 오차단 범위를 먼저 확인해야 합니다.

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

Config에서 현재 활성화된 파일과 규칙 내용을 다시 확인하세요. 원격 구성 업데이트는 Home에 등록된 구독 서버 목록을 업데이트하는 것과 별개의 작업입니다. 구성을 교체하기 전에 로컬 사본을 보관하고 업데이트 후 사용자 지정 규칙이 예상한 위치에 남아 있는지 확인하세요.

최종 판단 기준은 “지정한 연결이 의도대로 거부되고 필요한 기능은 계속 사용할 수 있는가”입니다. 모든 앱에서 특정 콘텐츠가 사라진다고 보장할 수는 없습니다. REJECT는 독립적으로 식별할 수 있는 대상 연결을 처리하는 데 적합합니다. 콘텐츠와 필수 기능이 같은 도메인, 연결, 응답을 공유한다면 차단 범위를 계속 넓히기보다 도메인 규칙의 한계를 고려해야 합니다.