Shadowrocket REJECT 규칙 가이드: 도메인 차단 방식과 한계

이 글의 핵심 내용

이 글은 Shadowrocket을 사용 중이며 기존 구성을 조정하려는 사용자를 위한 안내입니다. 먼저 규칙 조건과 REJECT 정책을 구분하고, 테스트용 도메인으로 규칙 우선순위를 확인한 뒤 연결 기록에서 오차단 원인을 찾습니다. 이미 이용 중인 서비스와 구독이 있다는 전제로 설명하며, 예시는 문법 안내용으로 일상적인 구성에 그대로 적용할 수 있는 완성된 설정이 아닙니다.

1. REJECT는 처리 정책이지 콘텐츠 식별 기능이 아닙니다

Shadowrocket은 Apple 플랫폼용 유료 앱이며 App Store에서만 받을 수 있습니다. 개발자는 Shadow Launch Technology Limited이고 앱 ID는 932747118이며, 한 번 구매하면 사용할 수 있습니다. 주로 iPhone과 iPad에서 사용하며, 다른 기기와의 호환성 및 시스템 요구 사항은 App Store 페이지를 기준으로 확인하세요. 앱 구매는 연결 서비스 요금제와 별개입니다. 이 글에서는 로컬 구성의 매칭 및 처리 방식을 다루며 연결 서비스를 제공하지 않습니다.

DOMAIN-SUFFIX,example.com,REJECT 규칙에서 DOMAIN-SUFFIX는 매칭 유형, example.com은 조건, REJECT는 조건에 일치했을 때의 정책입니다. 조건에 맞는 요청을 거부하며, 아래 규칙을 이어서 확인하거나 거부된 요청을 자동으로 프록시를 통해 다시 시도하지 않습니다.

요청이 터널에 진입 대상 정보 확인 규칙을 순서대로 확인 거부 정책에 일치 요청 실패 반환

이 흐름은 Shadowrocket의 처리 범위에 새로 들어온 요청만 설명합니다. 이미 연결된 세션, 앱 캐시에 저장된 콘텐츠, 해당 처리 범위에 들어오지 않은 트래픽은 규칙을 추가하는 것만으로 바로 사라지지 않습니다. 따라서 화면에 이전 이미지가 계속 표시된다고 해서 REJECT가 적용되지 않았다고 볼 수는 없습니다. 새로 요청을 보내고 연결 기록을 확인하세요.

2. 규칙 순서를 살펴보기 전에 Global Routing 확인하기

Home → Global Routing에서 현재 라우팅 모드를 확인하세요. 이 글의 일반 구성 규칙을 테스트하려면 먼저 Config를 선택하고, Config에서 실제로 활성화된 구성 파일을 확인합니다. 다른 파일에 규칙을 저장해도 해당 파일을 사용하지 않으면 현재 연결 처리에는 변화가 없습니다.

라우팅 모드	처리 방식	확인 사항
`Config`	현재 구성에 따라 규칙별로 트래픽을 분기합니다.	이 모드에서 규칙 순서와 REJECT 적용 여부를 확인하세요.
`Proxy`	모든 트래픽을 프록시로 라우팅합니다.	일반 Config 규칙을 확인하는 동등한 테스트 환경으로 볼 수 없습니다.
`Direct`	모든 트래픽을 직접 연결합니다.	모드를 바꾼 뒤 접속에 성공해도 프록시 서버에 문제가 있었다는 뜻은 아닙니다.
`Scene`	설정된 Scene에 따라 처리합니다.	테스트 조건이 바뀌지 않도록 현재 Scene의 조건과 라우팅 설정부터 확인하세요.

Settings → On Demand에서는 조건에 따른 자동 연결을 관리합니다. 규칙 목록이 아니며 특정 도메인의 정책을 REJECT 또는 DIRECT로 결정하지도 않습니다. 테스트 중 Wi-Fi나 셀룰러 네트워크를 전환했다면 터널 연결 상태, Global Routing, 현재 구성을 다시 확인하세요. 자동 연결이 실행된 것과 규칙이 일치한 것을 혼동하지 않아야 합니다.

수정 전에 현재 구성을 백업하고 Global Routing 모드와 테스트 대상 도메인을 기록합니다.
Config에서 실제 사용하는 구성을 편집하고, 조건 하나 또는 규칙 하나만 조정합니다.
저장한 뒤 현재 구성 파일이 그대로 선택되어 있는지 확인하고, 대상 페이지를 닫은 다음 요청을 새로 보냅니다.
새 요청의 대상, 일치한 규칙, 최종 정책을 확인한 뒤 추가 수정 여부를 결정합니다.

3. DOMAIN-SUFFIX, IP-CIDR, FINAL 사용법

규칙은 일반적으로 위에서 아래 순서로 확인하며, 먼저 일치한 규칙이 처리 정책을 결정합니다. 더 구체적인 예외를 포괄적인 규칙보다 앞에 두고, FINAL은 마지막에 배치해 나머지 요청을 처리합니다. 포괄적인 REJECT를 앞에 둔 다음 DIRECT를 추가해도 이미 일치한 요청을 되돌릴 수는 없습니다.

4가지

핵심 규칙: DOMAIN-SUFFIX / GEOIP / IP-CIDR / FINAL

32비트

IPv4의 /32 프리픽스는 주소 하나만 일치합니다

443

HTTPS에서 자주 사용하는 포트입니다. 포트만으로 콘텐츠의 용도를 판단할 수는 없습니다

아래는 읽기 쉬운 설명용 예시입니다. 도메인과 192.0.2.10은 문법 설명을 위한 값입니다. 사용자 지정 정책 이름에 의존하지 않도록 기본 정책은 DIRECT로 설정했으며, 일상적인 구성을 모두 직접 연결해야 한다는 뜻은 아닙니다. 기존의 완성된 구성에 이 예시를 덮어쓰지 마세요.

[Rule]
DOMAIN,keep.example.com,DIRECT
DOMAIN-SUFFIX,example.com,REJECT
IP-CIDR,192.0.2.10/32,REJECT,no-resolve
GEOIP,CN,DIRECT
FINAL,DIRECT

도메인 매칭 범위

DOMAIN: keep.example.com,DIRECT: 정확히 일치하는 도메인만 예외로 처리합니다.
DOMAIN-SUFFIX: example.com,REJECT: 루트 도메인과 하위 도메인에 적용합니다.
일치하지 않는 유사 도메인: notexample.com은 example.com의 하위 도메인이 아닙니다.

정확한 예외를 먼저 두고 그다음 접미사 규칙을 배치하세요. 문자열에 특정 글자가 포함됐는지로 판단하는 방식이 아닙니다.

IP 및 기본 처리 범위

IP-CIDR: 192.0.2.10/32,REJECT,no-resolve: 예시 IPv4 주소 하나에 일치합니다.
GEOIP: CN,DIRECT: IP 지리 정보 데이터베이스를 기준으로 판단합니다.
FINAL: DIRECT: 앞선 규칙에 일치하지 않은 요청을 처리합니다.

no-resolve는 해당 IP 규칙을 위해 도메인 조회를 새로 시작하지 않는다는 뜻이며, 모든 DNS 조회를 끈다는 뜻은 아닙니다.

위 순서에서는 keep.example.com이 먼저 정확한 예외에 일치하고, img.example.com은 접미사 REJECT에 일치합니다. IP 규칙의 적용 여부는 당시 대상 주소 정보를 확인할 수 있는지에 따라 달라집니다. GEOIP는 데이터베이스의 지리적 분류를 나타낼 뿐, 서버 위치나 콘텐츠 특성을 보장하지 않습니다. 이 조건들을 모두 같은 종류의 도메인 필터링으로 보지 마세요.

4. 같은 도메인의 콘텐츠와 HTTPS: REJECT의 한계

도메인 규칙으로 확인할 수 있는 것은 대상 도메인을 거부할지 여부이지, 페이지 안의 특정 콘텐츠를 삭제할 수 있는지는 아닙니다. 주요 기능과 차단 대상 콘텐츠가 같은 도메인을 사용한다면 해당 도메인에 REJECT를 적용할 때 로그인, 이미지, 결제 리디렉션 또는 다른 필수 요청까지 중단될 수 있습니다.

대상 상황	도메인 REJECT 적용 결과	이 결과만으로 판단할 수 없는 점
독립된 하위 도메인에서 리소스 제공	대상을 식별할 수 있고 규칙에 일치하면 해당 하위 도메인 요청을 거부할 수 있습니다.	페이지의 빈 자리 표시까지 사라진다고 보장할 수는 없습니다.
같은 도메인에서 HTTPS 경로가 서로 다른 경우	도메인을 거부하면 해당 도메인의 요청에 영향을 줍니다.	도메인 규칙만으로 /content와 /metrics를 구분할 수 없습니다.
여러 도메인이 하나의 IP를 공유하는 경우	IP-CIDR 규칙은 서로 다른 여러 서비스에 영향을 줄 수 있습니다.	IP 하나가 웹사이트 하나를 뜻하지는 않습니다.
요청이 UDP 443을 사용하는 경우	실제 대상과 규칙 일치 여부를 확인해야 합니다.	포트만으로 트래픽 유형이나 차단 여부를 단정할 수 없습니다.

일반 도메인 및 IP 규칙은 트래픽이 터널을 통과한다고 해서 HTTPS의 전체 경로와 본문을 자동으로 확인하지 않습니다. 암호화된 연결의 애플리케이션 계층 콘텐츠를 DOMAIN-SUFFIX 조건 하나로 세부 필터링할 수는 없습니다. Shadowrocket이 지원하는 연결 프로토콜과 로컬 규칙은 서로 다른 계층입니다. 프록시 프로토콜을 바꿔도 도메인 규칙에 페이지 요소를 식별하는 기능이 생기지는 않습니다.

결론: 대상을 분리할 수 없다면 거부 범위를 좁히세요

같은 도메인에서 필수 기능과 차단 대상 요청을 함께 처리한다면 도메인 전체에 적용한 REJECT를 취소하고, 독립적으로 식별할 수 있는 대상을 먼저 찾아보세요. 별도의 조건을 찾을 수 없다면 포괄적인 IP 거부 규칙을 계속 추가하는 것보다 기능을 유지하는 편이 테스트와 관리에 유리합니다.

5. 오차단 확인: 연결을 반복해서 바꾸지 말고 실패한 요청부터 추적하기

규칙 오차단은 메인 페이지는 열리지만 로그인이 계속 대기하거나, 텍스트는 표시되지만 이미지가 로드되지 않거나, 특정 작업이 매번 같은 단계에서 실패하는 식으로 나타날 수 있습니다. 이런 현상은 확인을 위한 단서일 뿐 REJECT가 적용됐다는 증거는 아닙니다. DNS 조회 실패, 원격 연결 실패, 앱 자체 오류도 비슷하게 보일 수 있습니다.

재현 동작을 고정합니다. 실패 시각, 대상 작업, 현재 네트워크와 구성 이름을 기록하세요. 여러 앱을 동시에 테스트하기보다 같은 로그인 페이지를 매번 다시 여는 식으로 진행합니다.
연결 기록을 확인합니다. 실패한 시각을 기준으로 대상 도메인이나 IP를 찾아 실제로 REJECT로 표시되는지, 어떤 규칙에 일치했는지 확인하세요. 기록에 REJECT가 없다면 DNS, 연결 설정 또는 원격 응답을 확인합니다.
최소 변경 사항을 되돌립니다. 방금 추가한 규칙 하나를 임시로 제거하고 구성을 저장한 뒤 같은 동작을 다시 테스트하세요. 어떤 변경이 영향을 줬는지 확인할 수 없으므로 규칙 구간 전체를 한꺼번에 삭제하지 마세요.
필수 대상에 예외를 추가합니다. 특정 도메인이 필수 기능에 필요한 것으로 확인되면 포괄적인 거부 규칙보다 앞에 정확한 DOMAIN 예외를 추가하고 기존 구성에서 해당 대상에 적합한 정책을 사용하세요. 무조건 DIRECT로 바꾸는 것은 아닙니다.
복원 후 확인합니다. 주요 기능과 원래 거부하려던 대상을 모두 다시 테스트하세요. 두 결과가 모두 예상대로일 때에만 예외가 차단 범위 전체를 해제하지 않았다고 판단할 수 있습니다.

새 규칙을 테스트할 때는 대상 연결을 새로 설정하세요. 필요하면 터널 연결을 끊었다가 다시 연결하고 On Demand가 예상 상태를 바꾸지 않았는지 확인합니다. 화면에 남은 캐시 콘텐츠는 새로고침한 다음 판단하세요. 다른 사람에게 문제를 문의할 때는 대상, 규칙, 오류 현상을 식별 정보가 드러나지 않도록 정리해 공유하고 구독 링크 전체, token, 비밀번호 및 기타 인증 정보는 가리세요.

6. 자주 묻는 질문: 콘텐츠가 보여도 규칙이 적용되지 않았다는 뜻은 아닙니다

REJECT를 추가했는데 이전 이미지가 계속 보이는 이유는 무엇인가요?

먼저 페이지를 새로고침하고 새 연결을 확인하세요. 이미지가 앱 캐시에 남아 있거나 규칙 추가 전에 이미 로드되었을 수 있습니다. 새 대상 요청이 계속 성공하고 예상한 REJECT에도 일치하지 않을 때 현재 구성, 도메인 조건, 규칙 순서를 확인하세요.

도메인을 거부한 뒤 로그인이 전부 실패하는 이유는 무엇인가요?

먼저 해당 규칙을 취소한 상태로 다시 시도한 다음 실패 당시 요청의 대상을 확인하세요. 인증과 서비스 리소스가 같은 도메인을 사용할 수 있습니다. 별도로 유지해야 할 하위 도메인만 있다면 포괄적인 DOMAIN-SUFFIX보다 앞에 정확한 DOMAIN 예외를 추가하고 로그인 과정을 다시 테스트하세요.

REJECT를 FINAL 뒤에 두었는데도 바뀌지 않는 이유는 무엇인가요?

FINAL은 앞선 규칙에 일치하지 않은 요청을 처리하는 기본 규칙입니다. 그 뒤에 둔 일반 규칙은 이미 기본 처리된 요청을 처리할 수 없습니다. 구체적인 매칭 규칙을 FINAL보다 앞에 두고, 정확한 예외, 대상 거부, 나머지 트래픽 분기, 최종 기본 처리 순서를 명확하게 유지하세요.

리소스에서 사용한 IP를 전부 거부해도 되나요?

먼저 해당 주소를 다른 필수 서비스와 공유하는지 확인하세요. CDN 주소는 바뀔 수 있으며 IP 하나에서 여러 도메인이 서비스될 수도 있습니다. 특정 도메인만 제한하려면 확인 가능한 도메인 조건을 우선 사용하고, 아직 확인하지 않은 대상을 포괄적인 IP 대역으로 대신하지 마세요.

문제 확인이 끝나면 변경한 규칙, 목적, 재현 방법과 복원 방법을 간단히 기록해 두세요. 이후 문제가 생기면 확인 범위를 넓히기 전에 최근 변경 사항부터 살펴봅니다. Home, Config, Settings의 기본 사용법은 시작하기에서 확인하고, 규칙 용어는 용어집에서 찾아볼 수 있습니다.