Shadowrocket REJECT 규칙 가이드: 차단 범위와 한계

이 글의 핵심

Shadowrocket의 REJECT는 연결 라우팅 정책이지 웹페이지 콘텐츠 필터가 아닙니다. 연결이 정상적으로 작동하고 규칙 편집을 시작하려는 사용자를 위해, Global Routing이 Config로 설정되었는지 확인하고 도메인 또는 IP에 최소 범위의 규칙을 추가한 뒤 요청 로그에서 적용 여부를 확인하는 방법을 설명합니다. 규칙 누락, 캐시, 동일 도메인에서 제공되는 콘텐츠로 인한 한계도 함께 살펴봅니다.

REJECT가 거부하는 것은 연결이지 페이지의 특정 요소가 아닙니다

앱이 네트워크에 접속하면 Shadowrocket은 처리 경로로 들어온 연결에 규칙을 적용합니다. REJECT 규칙에 일치하면 해당 요청에 대해 DIRECT 또는 PROXY 방식으로 대상 서버에 정상적인 아웃바운드 연결을 설정하지 않습니다. 여기서 ‘연결 설정 전’은 대상 서버로 나가는 단계에 관한 설명입니다. 앱이 요청을 보내기 전이라는 뜻도, 규칙 매칭 전에 DNS 조회가 전혀 일어나지 않는다는 뜻도 아닙니다.

앱 요청 터널 수신 규칙 매칭 요청 거부 앱 오류 표시

앱에서 오류를 처리하는 방식에 따라 이미지 로드가 실패하거나, 별도의 통계 요청이 종료되거나, 재시도 또는 시간 초과 알림이 표시될 수 있습니다. REJECT는 정상 페이지를 대신 만들어 주지 않으며, 웹페이지의 빈 영역을 자동으로 접어 주지도 않습니다. 따라서 요청이 거부되었는데도 페이지가 달라 보이지 않는 상황이 함께 발생할 수 있습니다.

DIRECT: 대상 주소에 직접 연결합니다. 해당 요청의 네트워크 접속은 허용됩니다.
PROXY: 선택한 프록시 정책을 통해 연결합니다. 요청을 차단하는 방식은 아닙니다.
REJECT: 규칙에 일치하는 요청을 거부합니다. 콘텐츠를 대체하거나 페이지 레이아웃을 수정하지 않습니다.

이러한 정책은 사용하는 프록시 프로토콜과는 다른 계층에 해당합니다. Shadowsocks, VMess, VLESS, Trojan, Hysteria2, WireGuard는 프록시 전송 또는 터널 방식을 설명합니다. 프록시 프로토콜을 바꾸더라도 REJECT가 HTTPS 페이지 내부 콘텐츠를 식별할 수 있게 되는 것은 아닙니다.

도메인 규칙과 IP 규칙의 식별 범위

매칭 단계에서 대상 도메인을 확인할 수 있다면 DOMAIN 또는 DOMAIN-SUFFIX를 사용할 수 있습니다. DOMAIN은 완전한 호스트명을 매칭하고, DOMAIN-SUFFIX는 지정한 도메인과 그 하위 도메인을 매칭합니다. 독립된 요청 엔드포인트만 거부하려면 최상위 도메인 전체로 범위를 넓히기보다 완전한 호스트명부터 적용하는 것이 좋습니다.

도메인 매칭 범위

DOMAIN: metrics.example.com,REJECT
DOMAIN-SUFFIX: example.com,REJECT
매칭 기준: 대상 호스트명(URL 경로 아님)

example.com과 그 하위 도메인은 문법 설명을 위한 예시이며, 그대로 사용할 수 있는 차단 목록이 아닙니다.

IP 매칭 범위

IP-CIDR: 192.0.2.10/32,REJECT,no-resolve
GEOIP: CN,DIRECT
매칭 기준: 대상 IP, IP 대역 또는 IP 지리 정보 데이터베이스

192.0.2.10은 문서용 예시 주소입니다. GEOIP 예시는 직접 허용하는 설정을 설명하기 위한 것으로, 차단을 권장하는 내용이 아닙니다.

/32는 IPv4 주소 하나를 뜻하며, 모호한 범위를 의미하지 않습니다. no-resolve는 이 IP 규칙만을 위해 별도의 도메인 조회를 시작하지 않도록 하는 옵션입니다. 이를 ‘모든 요청에서 DNS를 사용하지 않는다’는 뜻으로 이해해서는 안 됩니다. 앱이 IP에 직접 접속하고 사용할 수 있는 도메인 연관 정보가 없다면 도메인 규칙 하나만으로는 매칭되지 않을 수 있습니다.

IP 규칙에도 한계가 있습니다. 여러 도메인이 같은 CDN 주소를 공유할 수 있고, 같은 도메인도 지역·네트워크·시간에 따라 다른 주소를 반환할 수 있습니다. 한 번 조회된 IP를 모두 거부하면 이후 새 주소를 놓칠 수 있으며, 같은 주소를 공유하는 다른 서비스에 영향을 줄 수도 있습니다. GEOIP는 IP 주소 정보 데이터베이스를 기준으로 판단하므로 웹사이트의 실제 콘텐츠나 운영 주체를 식별하는 기능도 아닙니다.

범위를 넓히기 전에 필요한 연결을 확인하세요. 로그인, 인증 코드, 이미지, 본문이 같은 최상위 도메인의 서로 다른 하위 도메인을 사용할 수 있습니다. DOMAIN 규칙을 DOMAIN-SUFFIX로 바꾸면 특정 엔드포인트 하나를 차단하는 데서 그치지 않고 필요한 요청 전체를 차단할 수 있습니다.

규칙은 순서대로 매칭되며 REJECT에 별도 우선순위는 없습니다

Config 라우팅에서는 위에서 아래 순서로 규칙을 검사하고, 처음 일치한 규칙의 정책을 적용합니다. REJECT라고 해서 거부 정책이라는 이유만으로 앞에 있는 DIRECT 또는 PROXY 규칙을 자동으로 덮어쓰지는 않습니다. 더 구체적인 예외는 범위가 넓은 규칙보다 앞에 배치하고, FINAL은 아직 매칭되지 않은 연결을 처리하도록 규칙 목록의 마지막에 둡니다.

[Rule]
DOMAIN,login.example.com,DIRECT
DOMAIN,metrics.example.com,REJECT
DOMAIN-SUFFIX,example.com,PROXY
GEOIP,CN,DIRECT
FINAL,PROXY

순서 설명을 위한 이 예시에서는 login.example.com이 먼저 DIRECT에 매칭되고, metrics.example.com은 먼저 REJECT에 매칭됩니다. 그 외 example.com에 속하는 요청은 PROXY에 매칭됩니다. DOMAIN-SUFFIX를 맨 위로 옮기면 앞의 두 호스트명도 해당 규칙에 먼저 매칭되어, 뒤에 있는 세부 규칙이 작동하지 않습니다.

설정 상태	결과	수정 방법
범위가 넓은 허용 규칙이 REJECT보다 앞에 있음	대상이 먼저 허용 규칙에 매칭됨	정확한 REJECT 규칙을 관련된 범위 넓은 규칙보다 앞에 배치
REJECT가 FINAL 뒤에 있음	요청이 이미 FINAL에 처리됨	FINAL을 규칙 목록의 마지막에 배치
같은 호스트명에 여러 정책이 설정됨	먼저 매칭된 규칙이 적용됨	REJECT만 검색하지 말고 전체 규칙 순서를 확인

판단 기준: 실제로 매칭된 규칙을 먼저 찾고, 그다음 차단 범위를 넓히세요

요청 로그에 DIRECT 또는 PROXY가 표시된다면 먼저 앞에 있는 규칙이나 현재 라우팅 설정을 수정해야 합니다. 비슷한 REJECT 항목을 계속 추가해도 이미 앞선 규칙에 매칭된 동일 요청은 해결되지 않습니다.

Config가 적용되는지 확인한 뒤 최소한으로 테스트하세요

규칙 파일이 Config에 들어 있어도 현재 요청에 반드시 해당 파일이 적용되는 것은 아닙니다. 먼저 Home에서 Global Routing을 확인하세요. Proxy와 Direct는 전체 아웃바운드 라우팅 설정이며, 규칙을 테스트할 때는 Config를 명시적으로 선택해야 합니다. Scene은 상황별 라우팅 설정이므로, Scene이 표시된다는 이유만으로 현재 구성의 규칙 결과와 같다고 단정할 수 없습니다.

복사본을 저장하세요. Config에서 현재 사용 중인 설정을 확인하고, 편집하기 전에 복구 가능한 사본을 보관하세요. 내용을 파악하지 못한 전체 규칙을 그대로 덮어쓰지 마세요.
정확한 규칙 하나만 추가하세요. 요청 로그에 실제로 표시된 호스트명을 사용해 DOMAIN,호스트명,REJECT 형식으로 작성합니다. 여기서 ‘호스트명’은 입력 위치를 설명하는 표현이지, 그대로 붙여 넣을 수 있는 규칙이 아닙니다.
적용 상태를 확인하세요. 변경 사항을 저장하고 방금 편집한 설정을 사용 중인지 확인하세요. Home에서 Global Routing을 Config로 설정하고 연결 스위치도 켜져 있는지 확인합니다.
새 요청을 발생시키세요. 대상 페이지를 닫았다가 다시 열고, 필요한 경우 대상 앱을 종료한 뒤 다시 실행하세요. 이미 로드된 이미지나 기존 탭만 살펴보지 마세요.
로그를 확인하세요. 요청 로그에서 대상 호스트명 또는 IP를 찾아 실제로 매칭된 규칙과 정책을 확인합니다. 새 요청에 REJECT가 표시되어야 이번 테스트에서 거부 규칙이 적용된 것입니다.
규칙을 되돌려 확인하세요. 방금 추가한 규칙을 잠시 제거한 뒤 같은 방법으로 요청을 다시 발생시키세요. 규칙을 제거하기 전후의 연결 결과와 기능을 비교해 영향이 해당 규칙에서 비롯되었는지 확인합니다.

Settings → On Demand는 조건에 따라 자동 연결할지 제어하는 기능이며 REJECT 스위치가 아닙니다. 테스트 중 터널 연결이 끊기면 이후 요청은 같은 처리 경로를 거치지 않을 수 있으므로, ‘규칙이 작동하지 않는다’고 판단하기 전에 연결 상태를 확인하세요. 연결을 유지하는 세션은 규칙을 수정해도 모두 끊기는 것이 아니므로, 테스트하려면 새 연결을 만들어야 합니다.

기록할 것은 테스트 조건이지 속도 결과가 아닙니다. 대상 호스트명, Global Routing 설정, 매칭된 정책, 앱을 다시 실행했는지 여부를 기록해 두는 것이 좋습니다. 이 조건이 없으면 ‘페이지가 여전히 열린다’는 사실만으로 REJECT 적용 여부를 판단할 수 없습니다.

HTTPS, 캐시, 동일 도메인 콘텐츠로 인한 한계

도메인 및 IP 규칙은 연결 대상을 처리합니다. 예를 들어 정상 콘텐츠가 https://example.com/article에 있고 다른 콘텐츠가 https://example.com/promo에 있더라도 두 URL의 호스트명은 같습니다. DOMAIN이나 DOMAIN-SUFFIX만으로는 두 경로를 구분할 수 없습니다. 해당 호스트명을 차단하면 정상적인 글까지 함께 차단될 수 있습니다.

443

HTTPS에서 흔히 사용하는 기본 포트이며 콘텐츠 분류 표시는 아닙니다

기존 DNS에서 흔히 사용하는 포트이며 모든 DNS 전송 방식을 포괄하지 않습니다

4개 항목

Global Routing：Proxy / Direct / Config / Scene

포트는 전송 용도를 가늠하는 단서일 뿐입니다. 일반 웹페이지와 다른 HTTPS 요청 모두 443을 사용할 수 있으므로 포트 전체를 거부해 세밀하게 필터링할 수는 없습니다. 대상 도메인을 확인할 수 있더라도 암호화된 연결 안의 URL 경로, 요청 본문 또는 응답 콘텐츠를 읽을 수 있다는 뜻은 아닙니다. REJECT는 복호화를 수행하지 않습니다.

콘텐츠가 캐시됨: 앱이 디스크나 메모리에 저장된 데이터를 바로 표시하면 거부할 새 네트워크 요청이 없습니다. 페이지를 다시 열어도 캐시를 계속 사용할 수 있습니다.
콘텐츠가 주 응답에 포함됨: 정상 본문과 다른 콘텐츠가 하나의 요청으로 함께 반환되면 연결 수준의 거부로 일부만 남길 수 없습니다.
페이지 구조가 그대로 남음: 원격 이미지 요청이 실패해도 웹페이지에서 미리 만들어 둔 컨테이너, 제목 또는 버튼은 계속 표시될 수 있습니다.
요청이 다른 엔드포인트로 전환됨: 요청이 실패하면 앱이 다른 도메인에 접속할 수 있습니다. 기존 규칙은 매칭된 대상에만 적용되며 새 엔드포인트의 용도를 자동으로 판단하지 않습니다.
요청이 처리 경로에 들어오지 않음: 연결이 꺼져 있거나 제외 경로가 설정되어 있다면 규칙을 더 추가해도 해결되지 않습니다. 먼저 트래픽이 현재 설정을 통과하는지 확인하세요.

URL Rewrite는 별도의 요청 재작성 기능이며, 그 기능을 REJECT의 역할로 간주해서는 안 됩니다. 연결 규칙만으로 특정 콘텐츠를 분리할 수 없다면 필요한 기능은 유지하고 대상 범위를 좁히세요. 페이지 요소를 없애기 위해 IP 대역을 계속 넓히는 방식은 피해야 합니다.

자주 발생하는 문제와 복구 방법

REJECT를 추가했는데 페이지가 계속 표시되는 이유는 무엇인가요?

먼저 Home에서 Global Routing이 Config인지 확인한 다음 새 요청을 발생시키고 로그를 확인하세요. 새 요청에 REJECT가 표시되는데 이전 이미지가 계속 보인다면 앱 캐시를 확인하세요. 새 로그가 전혀 없다면 현재 페이지가 보인다는 사실만으로 규칙 적용 결과를 판단할 수 없습니다.

차단한 뒤 로그인이 되지 않는 이유는 무엇인가요?

최근 추가한 DOMAIN-SUFFIX 또는 IP-CIDR 규칙을 먼저 되돌린 뒤 앱을 다시 열어 로그인을 확인하세요. 정상적으로 로그인되면 로그인 요청과 차단 대상 콘텐츠가 같은 도메인 또는 주소를 공유하는지 확인합니다. 구분할 수 있다면 정확한 DOMAIN 규칙을 사용하고, 구분할 수 없다면 로그인에 필요한 연결을 허용하세요.

구독을 업데이트한 뒤 작성한 규칙이 적용되지 않는 이유는 무엇인가요?

Config로 돌아가 현재 활성화된 파일과 Rule 섹션에 로컬 수정 사항이 남아 있는지 확인하세요. 서버 구독을 업데이트하는 것과 원격 설정 파일을 교체하는 것은 서로 다른 작업입니다. 업데이트 과정에서 설정 파일 전체가 교체됐다면 로컬 규칙이 덮어써졌을 수 있으므로 사본에서 복원한 뒤 순서를 다시 확인하세요.

IP를 대량으로 복사해 한꺼번에 차단해도 되나요?

먼저 대량으로 추가하지 마세요. 실제 대상 하나를 기록하고 CDN 주소를 공유하는지, 다른 주소도 반환되는지 확인한 뒤 IP-CIDR 사용 여부를 결정하세요. 한 번에 관련 규칙 한 묶음만 수정하고 복구용 사본을 보관해야 어떤 규칙이 기능 오류를 일으켰는지 파악하기 쉽습니다.

이 글은 사용자가 이미 자신의 서비스 제공업체와 구독을 보유하고 있다는 전제에서 설명합니다. 구독은 이용 중인 서비스 제공업체에서 받으세요. 제공업체가 전달하는 연결 매개변수는 서비스 접속을 위한 것이고, REJECT는 현재 설정에서 규칙을 매칭하고 요청을 거부하는 기능이므로 서로 대체할 수 없습니다. 테스트를 마친 뒤에는 용도를 확인하기 어려운 항목을 계속 추가하기보다 정확하고 설명 가능하며 되돌릴 수 있는 규칙을 유지하는 편이 관리하기 쉽습니다.

Shadowrocket 다운로드 및 기본 설정 가이드

iPhone/iPad 버전은 App Store에서 미화 $2.99에 한 번 구매하면 됩니다. Mac(Apple 실리콘/Intel), Windows, Android, Linux 버전은 무료입니다. iPhone/iPad의 시스템 요구 사항은 App Store 페이지에 표시된 내용을 기준으로 확인하세요. 앱 구매는 회선 요금제가 아니며, 앱을 받은 뒤에는 본인의 연결 설정을 사용해야 합니다.

다운로드 페이지 사용 가이드 보기