Shadowrocket REJECT 규칙 설정 및 차단 범위: 차단 가능한 항목과 한계

이 글의 핵심

Shadowrocket의 REJECT는 연결 처리 정책이지, 웹페이지 요소를 걸러내는 기능이 아닙니다. 연결이 정상적으로 작동하고 Config를 직접 조정하려는 사용자를 위해 도메인 및 IP 규칙의 매칭 범위를 설명하고, 일부 규칙 수정·매칭 확인·설정 복원 방법을 안내합니다. 마지막으로 규칙이 적용되지 않는 경우와 리소스를 개별 차단할 수 없는 경우를 구분합니다.

REJECT의 대상은 연결입니다. 페이지의 특정 요소가 아닙니다

규칙 하나에는 매칭 조건과 처리 정책이 포함됩니다. 클라이언트는 대상 도메인이나 IP 등의 정보를 확인할 수 있을 때 현재 설정에 따라 연결 처리 방식을 결정합니다. REJECT 규칙에 매칭되면 해당 연결을 거부합니다. 웹페이지를 읽어 특정 이미지가 홍보 콘텐츠인지 판단한 뒤 그 이미지만 삭제하는 방식은 아닙니다. 따라서 규칙을 적용할 수 있는지는 우선 대상 리소스를 연결 단계에서 필수 리소스와 분리할 수 있는지에 달려 있습니다.

예를 들어 페이지 본문은 www.example.com에서, 부가 리소스는 별도의 metrics.example.com에서 제공된다면 후자에 도메인 규칙을 적용할 수 있습니다. 로그인, 본문, 부가 리소스가 모두 같은 도메인을 사용하고 경로만 다르면 해당 도메인을 거부할 때 여러 기능이 함께 영향을 받을 수 있습니다.

필드 3개

자주 쓰는 도메인 규칙: 유형, 매칭 값, 정책

TCP 443

HTTPS에서 흔히 사용하는 포트이며, 리소스 종류를 뜻하지 않습니다

UDP 443

HTTP/3에서 흔히 사용하는 포트이며, 별도 도메인을 뜻하지 않습니다

포트는 연결 정보의 일부일 뿐입니다. 연결에 443이 사용된다는 이유만으로 차단 대상 리소스라고 단정할 수 없습니다. 관련 포트를 모두 거부하면 정상적인 접속에도 큰 영향을 줍니다. 아래에 나오는 도메인과 IP는 문서용 예시이며 실제 차단 목록이 아닙니다.

자주 쓰는 규칙: 먼저 DOMAIN을 사용하고, 필요할 때 DOMAIN-SUFFIX와 IP-CIDR을 검토합니다

다음은 설정의 [Rule] 섹션에 추가할 수 있는 일부 예시입니다. 각 행은 독립적인 조건 하나를 나타냅니다. 이 행들을 전체 설정으로 그대로 바꾸거나, 예시를 따라 하려고 기존 정책 그룹과 기본 규칙을 삭제하지 마세요.

[Rule]
DOMAIN,metrics.example.com,REJECT
DOMAIN-SUFFIX,telemetry.example.com,REJECT
IP-CIDR,192.0.2.0/24,REJECT,no-resolve

규칙 유형	예시 범위	사용 전 확인 사항
`DOMAIN`	`metrics.example.com`이라는 도메인만 매칭합니다.	단일 호스트를 먼저 시험하고 필수 기능을 담당하지 않는지 확인할 때 적합합니다.
`DOMAIN-SUFFIX`	`telemetry.example.com`과 그 하위 도메인을 매칭합니다.	`a.telemetry.example.com`도 포함하므로 정확히 일치시키는 규칙보다 범위가 넓습니다.
`IP-CIDR`	`192.0.2.0/24`는 IPv4 네트워크 하나를 나타냅니다.	같은 네트워크에서 여러 도메인이 제공될 수 있으므로, 주소만 보고 콘텐츠 용도를 추정하는 것은 적절하지 않습니다.

DOMAIN-SUFFIX,example.com,REJECT는 기본 도메인과 모든 하위 도메인을 함께 매칭합니다. 특정 웹사이트의 일부 부가 리소스만 차단하는 규칙이 아닙니다. 도메인 필드에는 https://, 경로, 쿼리 매개변수를 넣지 않습니다. DOMAIN과 DOMAIN-SUFFIX는 URL의 /banner/ 같은 경로를 매칭하지 않습니다.

no-resolve는 이 IP 규칙을 위해 도메인 조회를 추가로 실행하지 않는다는 뜻입니다. 그렇다고 도메인 연결에 규칙이 반드시 적용되지 않는다는 의미는 아닙니다. 클라이언트가 해당 IP를 이미 알고 있다면 실제 연결 정보를 함께 확인해야 합니다. IPv4 네트워크 규칙만으로 같은 서비스의 IPv6 주소까지 차단되는 것도 아닙니다. 대상이 IPv6를 사용하는 경우 IPv4 범위를 무작정 넓히지 말고 실제 주소를 확인하세요.

요점: 명확한 도메인 하나부터 시작합니다

먼저 DOMAIN 규칙 하나로 대상과 부작용을 확인하세요. 같은 하위 도메인 영역을 모두 거부해야 한다고 확인한 경우에만 DOMAIN-SUFFIX로 범위를 넓히세요. 한 번 관찰한 IP를 근거로 공유 주소 전체를 바로 거부하지 마세요.

규칙 순서와 Global Routing: 문법을 올바르게 쓰는 것만으로는 충분하지 않습니다

Config 규칙에 따라 처리하는 경우 규칙은 일반적으로 순서대로 확인되며, 먼저 매칭된 규칙이 정책을 결정합니다. 앞에 대상과 매칭되는 허용 규칙이 있으면 뒤에 있는 REJECT는 해당 연결을 처리할 수 없습니다. FINAL은 앞선 규칙이 하나도 매칭되지 않을 때 적용되는 기본 규칙이므로, 계속 매칭되어야 하는 일반 규칙보다 앞에 두지 마세요.

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

위 예시는 먼저 특정 도메인을 거부한 뒤, 같은 기본 도메인의 다른 연결은 DIRECT로 처리합니다. 앞의 두 행 순서를 바꾸면 metrics.example.com이 범위가 더 넓은 DIRECT 규칙에 먼저 매칭됩니다. 마지막의 FINAL,DIRECT는 매칭 순서 설명을 위한 예시일 뿐입니다. 실제 설정에서는 필요한 기본 정책을 유지하고, 이를 근거로 미매칭 트래픽의 처리 방식을 모두 바꾸지 마세요.

Config

권장

현재 활성화된 설정의 규칙에 따라 정책을 결정합니다. 사용자 지정 REJECT 규칙을 확인하려면 먼저 Home → Global Routing → Config에서 이 방식을 선택했는지 확인하세요.

적합한 용도: 일상적인 규칙 라우팅, 사용자 지정 규칙의 매칭 여부 확인

Proxy

트래픽을 프록시 경로로 처리하며 Config의 일반 라우팅 규칙을 하나씩 적용해 경로를 결정하지 않습니다. 이 모드에서는 웹페이지가 거부되는지 확인하는 방식으로 방금 수정한 Config 규칙을 검증할 수 없습니다.

적합한 용도: 프록시 연결을 임시로 확인하고 일반 라우팅 규칙의 영향을 분리

Direct

트래픽을 직접 연결 경로로 처리하므로 사용자 지정 Config 규칙의 매칭 테스트에도 적합하지 않습니다. 직접 연결로 웹페이지가 열린다고 해서 REJECT 문법에 문제가 있는 것은 아닙니다.

적합한 용도: 직접 연결 상태와 비교해 네트워크 환경 차이를 확인

Scene을 사용 중이라면 해당 Scene에서 최종적으로 어떤 설정과 처리 방식을 사용하는지도 확인해야 합니다. 문제를 해결하는 동안 Config로 고정하면 Scene 전환으로 생기는 변수를 줄일 수 있습니다. 여기서는 자주 사용하는 세 가지 테스트 방식을 비교했으며, Global Routing의 전체 선택 항목을 나열한 것은 아닙니다.

일부 규칙 수정 및 확인: 한 번에 규칙 하나만 추가합니다

다음 단계는 이미 작동하는 설정이 있다는 전제입니다. Home의 서버 항목, Config의 설정 파일, Settings의 일반 설정은 용도가 서로 다릅니다. 활성화되지 않은 설정을 편집해도 현재 연결에 적용되는 규칙은 자동으로 바뀌지 않습니다.

기존 설정 보관

Config에서 현재 활성화된 설정을 확인하고, 먼저 복사본을 만들거나 백업을 내보내세요. 기존 Global Routing 방식을 기록해 수정 전 상태로 돌아갈 수 있도록 합니다.
처리 방식 고정

Home → Global Routing → Config에서 설정에 따른 처리를 선택합니다. Home의 연결 스위치가 켜져 있는지 확인하세요. 클라이언트가 연결을 처리하지 않는 상태에서 규칙을 시험하는 일을 방지할 수 있습니다.
정확한 규칙 추가

Config에서 현재 설정의 편집 화면을 열고 [Rule] 섹션을 찾습니다. 대상을 포괄하는 광범위한 규칙과 FINAL보다 앞에, 확인된 대상에 적용할 DOMAIN 규칙 하나를 추가한 뒤 저장합니다.
새 연결 생성

수정한 설정이 계속 활성화되어 있는지 확인하고, 필요하면 다시 연결합니다. 대상 페이지나 앱을 닫았다가 다시 연 다음 클라이언트의 연결 기록에서 해당 도메인에 적용된 정책과 매칭 정보를 확인하세요.
확인 후 되돌리기

로그인, 본문, 이미지, 재생 등 필요한 기능을 각각 시험하세요. 문제가 생기면 방금 추가한 행을 삭제하고 저장한 뒤 다시 연결합니다. DNS, 서버, 여러 규칙 그룹을 한꺼번에 바꾸지 마세요.

검증할 때는 ‘대상 연결이 REJECT에 매칭되는지’와 ‘필요한 기능을 계속 사용할 수 있는지’를 모두 확인해야 합니다. 페이지의 일부 영역이 사라지는 현상만으로 규칙이 올바르게 작동한다고 단정할 수 없습니다. 서버의 일시적인 문제, 앱 캐시, 리소스 로딩 시간 초과도 비슷한 증상을 일으킬 수 있습니다. 반대로 페이지에 예전 이미지가 계속 표시된다면 로컬 캐시가 갱신되지 않은 것일 수 있으며, 새 요청이 정상 처리되었다는 뜻은 아닙니다.

차단의 한계: 동일 도메인 콘텐츠, 암호화된 경로, 앱 내장 리소스

일반적인 도메인 및 IP 규칙은 웹페이지 본문 전체를 읽을 필요가 없습니다. 하지만 본문 내용을 기준으로 선택적으로 차단할 수도 없습니다. HTTPS는 요청 경로, 쿼리 매개변수, 본문 등의 정보를 암호화합니다. 따라서 도메인 규칙을 암호화된 전체 URL을 식별하는 필터로 볼 수 없습니다. 클라이언트가 대상 도메인을 확인할 수 있는지는 연결 방식, 조회 경로, 사용 가능한 연결 메타데이터에도 달려 있습니다.

같은 도메인의 서로 다른 경로:example.com/article과 example.com/promo가 같은 호스트를 사용하면 DOMAIN으로 뒤쪽 경로만 거부할 수 없습니다. IP 규칙으로 범위를 넓혀도 경로를 식별할 수는 없습니다.
하나의 연결 재사용:HTTP/2와 HTTP/3는 하나의 연결에서 여러 요청을 처리할 수 있습니다. REJECT는 같은 연결에서 페이지 모듈 하나만 골라내는 도구가 아닙니다. 연결을 거부하면 함께 전송되는 정상 리소스에도 영향을 줄 수 있습니다.
앱에 포함된 리소스:앱에 이미 저장된 이미지, 화면, 텍스트는 원격 연결을 새로 만들 필요가 없으므로 네트워크 규칙으로 이러한 로컬 콘텐츠를 삭제할 수 없습니다.
서버에서 합쳐서 제공하는 콘텐츠:본문과 다른 콘텐츠가 같은 API 응답에 포함되어 있다면 API를 거부할 때 본문도 함께 사라질 수 있습니다. 일부만 남길 수 있다고 보장할 수 없습니다.
공유 인프라:여러 서비스가 같은 CDN이나 IP를 사용할 수 있습니다. 주소 범위를 거부한 뒤 다른 사이트도 열리지 않는다면 차단 범위를 계속 넓히지 말고 먼저 주소 규칙을 좁히거나 취소하세요.

REJECT에 매칭되어도 앱에는 빈 영역, 오류 메시지, 캐시된 콘텐츠가 표시되거나 다른 도메인으로 재시도할 수 있습니다. 연결 거부와 화면 재배치는 별개의 문제입니다. 대상이 결제, 계정 인증, 미디어 API와 인프라를 공유한다면 모든 이상 요청을 없애려 하기보다 필수 기능을 유지하는 것이 우선입니다.

자주 묻는 문제: 규칙이 매칭되지 않는 경우와 대상을 따로 처리할 수 없는 경우

REJECT를 설정했는데도 왜 계속 열리나요?

먼저 Home → Global Routing → Config를 확인한 다음 Config에서 실제로 활성화된 파일을 확인하세요. 대상과 매칭되는 DIRECT, 정책 그룹 규칙, FINAL 뒤에 규칙이 있지는 않은지 살펴봅니다. 다시 연결한 뒤 기록을 확인하고, 화면에 남아 있는 캐시 콘텐츠만으로 판단하지 마세요.

같은 도메인의 다른 페이지에 영향을 주지 않고 URL 하나만 차단할 수 있나요?

DOMAIN과 DOMAIN-SUFFIX는 도메인으로만 매칭합니다. 경로를 필터링하려고 전체 URL을 도메인 필드에 붙여 넣을 수 없습니다. 먼저 리소스가 별도의 호스트를 사용하는지 확인하세요. 경로만 다르다면 같은 도메인의 정상 접속까지 거부하지 않도록 도메인 규칙의 범위를 더 넓히지 마세요.

규칙을 추가한 뒤 로그인과 이미지가 함께 작동하지 않으면 어떻게 하나요?

먼저 마지막으로 추가한 규칙을 되돌리고 다시 연결해 기능이 복구되는지 확인하세요. DOMAIN-SUFFIX 또는 IP-CIDR을 사용했다면 공유 호스트나 주소까지 포함하지 않았는지 살펴봅니다. 연결 기록에서 대상이 분리되어 있음을 확인할 수 있을 때만 더 좁은 DOMAIN 규칙으로 바꾸세요.

구독을 업데이트하면 로컬 규칙도 자동으로 업데이트되나요?

Home의 Subscribe 서버 구독과 Config 설정 파일은 서로 다른 항목입니다. 서버 목록을 새로 고쳐도 로컬 규칙은 업데이트되지 않습니다. 원격 설정을 업데이트하면 수동 변경 사항이 덮어쓰일 수 있습니다. 업데이트 대상과 현재 활성화된 설정을 각각 확인하고 로컬 변경 사항은 복사본으로 보관하세요.

규칙이 매칭되는지 확인할 때 Settings → On Demand를 사용하지 마세요. On Demand는 조건을 충족할 때 연결을 언제 요청할지 처리하고, REJECT는 연결이 규칙 판단 단계에 들어온 뒤 어떤 정책을 적용할지 처리합니다. 문제를 해결하는 동안 연결 상태가 저절로 바뀐다면 On Demand 조건도 확인하되, 이를 차단 규칙의 편집 메뉴로 사용하지는 마세요.

규칙을 유지하는 기준: 명확한 매칭, 감당할 수 있는 부작용, 복원 가능성

규칙은 많을수록 좋은 것이 아닙니다. 새 규칙마다 명확한 대상, 재현 가능한 현상, 취소 방법이 있어야 합니다. 출처가 불분명한 광범위한 규칙, 특히 IP 전체 대역이나 기본 도메인을 폭넓게 거부하는 규칙은 용도를 설명할 수 없다면 일상 설정에 바로 추가하지 마세요.

수정 전 설정을 보관하고 새 규칙의 대상 도메인과 추가 이유를 기록하세요.
규칙을 추가한 뒤 새 연결 기록을 확인하고 계정, 결제, 재생 등 실제로 사용하는 기능을 시험하세요.
앱이나 웹사이트에서 리소스 도메인이 변경되면 다시 검증하세요. 과거에 작동했던 규칙이 계속 유효하다고 가정하지 마세요.
원격 설정을 업데이트해야 한다면 먼저 로컬 변경 사항이 덮어쓰이는지 확인하고, 업데이트 후 활성화 상태를 다시 점검하세요.

Shadowrocket은 App Store에서 제공되는 클로즈드 소스 상용 앱이며, 주로 iPhone과 iPad에서 사용합니다. 개발자는 Shadow Launch Technology Limited입니다. 클라이언트의 일회성 구매는 연결 서비스 구독과 별개입니다. 이 글은 연결 서비스를 제공하지 않으며, 기존 구독 링크는 서비스 제공업체에서 확인하세요. 가격, 시스템 요구 사항, 구매 가능 범위는 App Store 페이지를 기준으로 확인하세요.