Shadowrocket REJECT 규칙 설정 방법: 차단 원리와 매칭 순서

이 글의 핵심

Shadowrocket의 REJECT는 요청 처리 정책이지 웹페이지 요소 필터가 아닙니다. 사용 가능한 구성이 있고 로컬 차단 규칙을 추가하려는 사용자를 위해, 먼저 매칭 조건과 처리 정책의 차이를 설명합니다. Config 모드에서 규칙 순서를 확인한 다음, 규칙을 하나씩 켜고 끄며 의도치 않은 차단 여부를 점검합니다. 예시는 설명용 도메인과 문서용 IP 주소를 사용하므로 실제 요청에 맞게 바꿔야 하며, 그대로 사용할 수 있는 차단 목록이 아닙니다.

REJECT란? 일치한 요청 차단

REJECT는 해당 정책에 일치하는 요청을 차단하며, 요청에 사용할 프록시 서버를 선택하는 기능은 아닙니다. 규칙의 앞부분에는 매칭 조건을, 끝부분에는 처리 정책을 지정합니다. 예를 들어 DOMAIN,ads.example.com,REJECT에서 DOMAIN은 규칙 유형, ads.example.com은 매칭 값이며, 요청이 일치했을 때 실행되는 동작은 REJECT입니다. REJECT를 서버 주소나 포트 입력란에 넣지 마세요.

요청이 터널에 진입 매칭 정보 확인 규칙을 순서대로 검사 차단 정책에 일치 요청 전달 중단

규칙은 해당 라우팅 처리 과정을 거치는 트래픽에만 적용됩니다. Home → Global Routing에서 Config를 선택하면 현재 구성의 규칙을 확인하는 일반적인 테스트 방법이 됩니다. Proxy와 Direct는 전역 처리 모드이므로 구성에 설정된 REJECT를 테스트하는 것과 같지 않습니다. Scene은 선택한 장면의 설정에 따라 확인해야 합니다. 요청이 Shadowrocket의 처리 경로를 거치지 않으면 구성에서 REJECT를 수정해도 영향을 주지 않습니다.

DIRECT: 요청을 직접 연결합니다. 연결을 거부한다는 뜻은 아닙니다.
PROXY: 요청을 해당 프록시 정책으로 전달합니다. 사용 가능 여부는 현재 구성과 서버에 따라 달라집니다.
REJECT: 요청을 차단합니다. 이 차단 규칙에 프록시 아웃바운드를 설정할 필요는 없습니다.

규칙 작성법: 정확한 도메인부터 시작

먼저 DOMAIN으로 정확히 일치시키고, 필요할 때 DOMAIN-SUFFIX 또는 DOMAIN-KEYWORD로 범위를 넓히세요. 아래는 구성 파일의 [Rule] 섹션에 작성하는 문법 예시입니다. 세 규칙은 매칭 범위를 비교하기 위한 것으로, 실제 문제를 확인할 때는 필요한 규칙 하나만 켜세요. 여러 조건의 범위가 겹치면 어떤 규칙이 적용됐는지 구분하기 어려울 수 있습니다.

[Rule]
DOMAIN,ads.example.com,REJECT
DOMAIN-SUFFIX,tracker.example.net,REJECT
DOMAIN-KEYWORD,telemetry,REJECT
FINAL,DIRECT

도메인 조건과 매칭 범위

DOMAIN: ads.example.com,REJECT: 해당 도메인과 정확히 일치하는 경우만 차단합니다.
DOMAIN-SUFFIX: tracker.example.net,REJECT: 해당 도메인과 그 하위 도메인에 일치합니다.
DOMAIN-KEYWORD: telemetry,REJECT: 도메인에 이 키워드가 포함된 요청에 일치합니다.

도메인 조건에는 https://, 페이지 경로, 쿼리 매개변수를 입력하지 않습니다.

IP 주소 조건과 기본 처리

IP-CIDR: 192.0.2.7/32,REJECT: 단일 IPv4 주소에 일치합니다.
GEOIP: CN,DIRECT: IP 지리 데이터베이스의 지역 판정 결과에 따라 일치합니다.
FINAL: DIRECT: 앞선 규칙에 일치하지 않은 요청을 처리합니다.

IP 주소 규칙은 사용 가능한 대상 IP 정보에 의존하므로 정확한 도메인 규칙을 대신할 수 없습니다.

도메인 규칙은 호스트 이름에 일치하며 전체 URL에는 적용되지 않습니다. 대상 주소가 https://ads.example.com/banner?id=1이라면 도메인 규칙에서 확인하는 값은 ads.example.com입니다. /banner나 id=1은 매칭 대상이 아닙니다. 전체 URL을 DOMAIN-SUFFIX에 입력해도 해당 페이지 하나만 차단되지는 않습니다.

예시의 FINAL,DIRECT는 규칙의 끝부분을 보여주기 위한 것입니다. 일치하지 않은 트래픽을 직접 연결하므로 기존 FINAL 정책을 덮어쓰는 용도로 사용하면 안 됩니다. 예시를 기존 구성에 추가할 때는 필요한 차단 규칙만 넣고, 기존 기본 처리 방식과 유효한 정책 이름을 유지하세요.

매칭 순서 정하기: 예외는 위에, 넓은 조건은 아래에

일반 규칙은 위에서 아래로 검사하며, 요청은 처음 일치한 규칙의 정책을 따릅니다. 같은 도메인이 정확한 도메인 조건과 접미사 조건에 모두 일치할 수 있지만, 더 정확해 보이는 규칙이 자동으로 선택되지는 않습니다. 따라서 허용할 예외는 범위가 넓은 차단 규칙보다 위에 두고, FINAL은 일반 규칙의 마지막에 배치하세요.

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

login.example.com에 접속: 첫 번째 규칙에 먼저 일치해 DIRECT가 적용되므로, 뒤에 있는 접미사 차단 규칙까지 진행하지 않습니다.
ads.example.com에 접속: 첫 번째 규칙에는 일치하지 않지만 두 번째 규칙에 일치해 REJECT가 적용됩니다.
example.com에 접속: 도메인 자체도 두 번째 규칙의 매칭 범위에 포함되므로 차단됩니다.
example.org에 접속: 앞의 두 규칙에 일치하지 않아 마지막의 FINAL,DIRECT가 적용됩니다.

정리: 예외를 먼저 배치하고 차단 범위는 나중에 넓히기

로그인 도메인을 허용하려면 해당 허용 규칙을 접미사 차단 규칙 위에 놓고 로그인과 서비스 페이지를 테스트하세요. 두 규칙의 순서를 바꾸면 정확한 예외 규칙이 구성에 남아 있어도 요청이 넓은 조건에 먼저 일치해 작동하지 않습니다.

규칙을 추가했는데도 적용되지 않는다면 먼저 위쪽 규칙의 매칭 조건을 확인하세요. 예를 들어 위에 DOMAIN-SUFFIX,example.com,DIRECT가 있고 아래에 DOMAIN,ads.example.com,REJECT를 추가했다면, 해당 요청은 먼저 직접 연결됩니다. 같은 REJECT 행을 반복해서 추가하기보다 순서를 조정하거나 위쪽 조건의 범위를 좁히세요.

추가 및 확인 방법: 한 번에 규칙 하나만 수정

현재 구성을 먼저 복사한 뒤 복사본을 수정해 사용하세요. 아래 단계는 iPhone/iPad의 Home 및 Config 화면을 기준으로 하며, 다른 플랫폼에서는 실제 메뉴를 확인하세요. 기존에 보유한 구성과 서비스를 바탕으로 진행해야 합니다. 이 문서에서는 노드나 구독을 제공·판매·추천하지 않습니다.

Config에서 현재 사용 중인 구성 파일을 확인하고, 복구할 수 있도록 수정 전 복사본을 보관하세요.
수정할 구성의 편집 화면을 열고 규칙 섹션을 찾으세요. 텍스트로 편집한다면 기존 [Rule] 섹션에 규칙을 추가하고, 같은 이름의 섹션을 나누어 중복 생성하지 마세요.
먼저 DOMAIN,ads.example.com,REJECT와 같은 정확한 규칙 하나를 추가하세요. 해당 도메인에 일치할 수 있는 넓은 규칙보다 위에 배치하고 기존 FINAL은 그대로 유지하세요.
수정한 구성을 저장해 선택한 다음 Home → Global Routing으로 돌아가 Config를 사용하는지 확인하세요. 연결 스위치가 켜져 있는지도 확인합니다.
대상 앱이나 페이지의 기존 연결을 종료한 뒤 요청을 새로 보내세요. 차단할 기능과 유지해야 할 기능의 동작을 각각 기록합니다.
추가한 규칙을 잠시 삭제하거나 비활성화한 뒤 같은 요청을 다시 보내세요. 규칙을 켜고 끌 때 기능이 달라진다면 규칙의 매칭 범위가 적절한지 이어서 확인합니다.

기존 연결과 로컬 캐시 때문에 테스트 결과가 늦게 반영될 수 있습니다. 이미 불러온 페이지의 이미지가 REJECT를 추가했다고 사라지는 것은 아니며, 앱이 기존 연결을 재사용할 수도 있습니다. 새 요청을 만든 뒤 규칙을 켰을 때와 껐을 때의 차이를 비교하세요. 캐시에 이전 내용이 보인다고 규칙이 작동하지 않는다고 단정하지 말고, 한 번의 네트워크 시간 초과를 REJECT 탓으로 돌리지도 마세요.

차단의 한계: 도메인 차단은 콘텐츠 필터링과 다릅니다

REJECT는 독립적으로 식별할 수 있는 요청 대상을 차단하는 데 적합하며, 페이지의 텍스트나 요소를 세밀하게 필터링하는 기능은 아닙니다. 광고와 로그인, 본문이 같은 도메인을 사용한다면 해당 도메인을 차단했을 때 관련 기능도 함께 중단될 수 있습니다. HTTPS 요청에서 DOMAIN 규칙만으로 특정 URL 경로를 식별할 수는 없습니다. 이 문서의 도메인 차단에는 HTTPS 복호화를 켤 필요도 없습니다.

3가지

비교한 도메인 조건: DOMAIN, DOMAIN-SUFFIX, DOMAIN-KEYWORD

/32

IPv4 단일 주소 접두사입니다. /24는 주소 256개를 포함합니다.

443

HTTPS 기본 포트입니다. 도메인 규칙은 포트로 페이지 경로를 구분하지 않습니다.

같은 도메인의 리소스: 서비스 도메인 전체를 차단하면 본문 이미지, 계정 인증, 결제 콜백까지 함께 막힐 수 있습니다. 독립적으로 식별할 수 있는 대상을 먼저 찾아보세요.
키워드 범위가 지나치게 넓음: DOMAIN-KEYWORD,ad,REJECT는 특정 광고 도메인보다 훨씬 넓은 범위에 적용됩니다. 일반 서비스 도메인에도 이 문자열이 들어 있으면 일치할 수 있으므로 첫 테스트 규칙으로 적합하지 않습니다.
공유 IP: 여러 웹사이트가 같은 CDN 주소를 사용할 수 있습니다. IP-CIDR로 주소 하나를 차단해도 영향 범위가 처음 확인한 사이트에만 한정된다고 보장할 수 없습니다.
변경되는 주소: 서버 주소가 바뀌면 수동으로 기록한 IP가 대상 주소를 더 이상 포함하지 않을 수 있습니다. 반대로 이전 주소를 다른 서비스가 사용할 수도 있습니다.
매칭 정보 부족: 처리 과정에서 대상 IP만 확인되고 도메인 매칭 정보가 없으면 도메인 규칙이 적용되지 않을 수 있습니다. 키워드 범위를 계속 넓히기보다 실제 요청 기록을 확인하세요.

정리: 리소스를 구분할 수 없다면 서비스 사용 가능성을 우선하세요

차단하려는 콘텐츠가 필수 서비스와 도메인을 공유하고 독립적인 요청 대상을 찾을 수 없다면 DOMAIN-SUFFIX나 IP-CIDR의 범위를 더 넓히지 마세요. 지나치게 넓은 조건을 예외 규칙으로 계속 보완하는 것보다 의도치 않은 차단 규칙을 되돌리는 편이 관리하기 쉽습니다.

자주 묻는 질문: 오차단, 업데이트로 인한 변경, 자동 연결

대부분의 문제는 현재 구성, 라우팅 모드, 최근 변경 사항부터 확인하면 원인을 찾을 수 있습니다. 규칙 목록을 더 늘리는 것은 잠시 멈추고, 재현 가능한 단일 테스트 조건을 유지한 다음 아래 순서대로 점검하세요. 앱 화면의 연결 상태는 터널 상태만 보여줄 뿐, 특정 REJECT 규칙이 적용됐다는 증거는 아닙니다.

REJECT를 추가했는데도 대상에 접속할 수 있는 이유는 무엇인가요?

먼저 Home → Global Routing에서 Config가 선택되어 있는지 확인하고, Config에서 수정한 파일이 선택되어 있는지도 확인하세요. 차단 규칙보다 위에 먼저 일치하는 DIRECT 또는 다른 조건이 있는지 살펴보세요. 마지막으로 기존 연결을 종료하고 새 요청을 보내 캐시와 연결 재사용 가능성을 제외합니다.

차단 후 로그인이 실패하면 어떤 예외 규칙을 추가해야 하나요?

최근 추가한 차단 규칙을 먼저 되돌려 로그인이 복구되는지 확인한 뒤, 로그인 과정에서 실제 사용하는 도메인을 확인하세요. 해당 도메인이 차단 대상과 다르면 정확한 허용 규칙을 넓은 차단 규칙보다 위에 배치합니다. 같은 도메인을 공유한다면 도메인 규칙만으로 두 요청을 안정적으로 구분할 수 없습니다.

업데이트 후 로컬에서 추가한 규칙이 사라진 이유는 무엇인가요?

먼저 Home의 서버 구독을 업데이트했는지, Config의 원격 구성 파일을 업데이트했는지 구분하세요. 서버 목록 업데이트와 규칙 파일 업데이트는 서로 다른 작업입니다. 원격 구성을 새로고침하면 로컬에서 편집한 내용이 대체될 수 있습니다. 업데이트 전에 복사본을 저장하고, 업데이트 후 규칙 섹션과 순서를 확인한 다음 필요한 구성을 선택하세요.

Settings → On Demand로 규칙을 켜고 끄는 기능을 대신할 수 있나요?

아니요. On Demand는 설정한 조건에 따라 연결을 시작하는 기능이며, 특정 도메인에 DIRECT와 REJECT 중 어느 정책을 적용할지 지정하지 않습니다. 테스트할 때는 먼저 터널이 연결되어 있는지 확인한 다음 Global Routing과 현재 구성을 점검하세요. 특정 차단을 해제하려면 해당 규칙을 수정해야 합니다.

규칙을 관리할 때는 수정 이유와 되돌리는 방법을 기록해 두세요. 매번 대상 하나만 처리하고 실제 도메인, 사용한 규칙 유형, 유지해야 할 서비스 기능을 기록합니다. 원격 구성에서 규칙을 가져온다면 새로고침 후 로컬 변경 사항도 다시 확인하세요. 이렇게 하면 차단 범위가 적절한지와 현재 연결이 정상인지 따로 판단할 수 있어, 모든 네트워크 문제를 차단 규칙 탓으로 돌리는 일을 줄일 수 있습니다.