· 고급 규칙 · 약 8분

Shadowrocket REJECT 규칙 작성법: 도메인 차단 원리와 한계

Shadowrocket에서 REJECT와 DOMAIN-SUFFIX 규칙을 작성하고 적용 순서를 확인하는 방법, 모든 콘텐츠를 차단할 수 없는 이유를 설명합니다.

이 글 미리보기

REJECT 정책은 일치하는 연결을 차단하는 기능이지, 웹페이지 요소를 필터링하는 기능은 아닙니다. Shadowrocket을 사용하며 Config 설정을 수정하려는 분들을 위해 도메인 매칭 원리를 살펴보고, 되돌릴 수 있는 규칙을 추가한 뒤 새 요청으로 적용 여부를 확인하는 방법을 안내합니다. 규칙이 적용되지 않는 경우, 캐시가 남아 있는 경우, 특정 콘텐츠만 차단할 수 없는 경우를 구분해 보세요.

REJECT의 역할: 연결 차단, 페이지 편집은 아님

규칙은 매칭 조건과 처리 정책으로 구성됩니다. DOMAIN-SUFFIX,example.com,REJECT는 규칙 판단에 사용되는 대상 도메인이 example.com 또는 그 하위 도메인일 때 REJECT 정책으로 연결을 차단한다는 뜻입니다. 페이지를 먼저 내려받아 특정 요소를 삭제하거나, 페이지의 문구를 보고 콘텐츠 유형을 판별하는 기능은 아닙니다.

새 요청 발생 연결 처리 시작 매칭 정보 확인 규칙을 순서대로 매칭 차단 정책 실행

이 과정에는 두 가지 전제가 있습니다. 요청이 실제로 Shadowrocket에서 처리되어야 하고, 현재 라우팅 모드가 해당 Config의 규칙을 적용해야 합니다. 규칙을 어떤 파일에 저장했다는 사실만으로 연결 처리에 사용된다고 볼 수는 없습니다. 앱에 이미 표시된 캐시 콘텐츠는 새 네트워크 요청을 발생시키지 않을 수도 있습니다.

REJECT, DIRECT, PROXY는 각각 다른 역할을 합니다. DIRECT는 연결을 시작하되 프록시를 거치지 않고 직접 연결하며, PROXY는 프록시 경로를 사용합니다. REJECT는 해당 연결을 차단합니다. REJECT를 DIRECT로 바꾸는 것은 다른 방식으로 차단하는 게 아니라 직접 연결을 시도하도록 허용하는 것입니다.

DOMAIN-SUFFIX 작성법: 프로토콜과 경로는 제외

Config 파일의 [Rule] 규칙 섹션에서는 규칙 하나를 한 줄에 작성하고, 필드는 영문 쉼표로 구분합니다. 아래는 문법을 보여 주는 독립된 예시이며 기존 파일을 덮어쓸 완성된 설정이 아닙니다. 파일에 이미 [Rule] 섹션이 있다면 그 안에 규칙을 추가하고, 섹션을 중복해서 만들지 마세요.

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

단일 도메인 매칭

키워드
DOMAIN
매칭 값
metrics.example.com
처리 정책
REJECT
매칭 범위
해당 도메인만 해당하며 하위 도메인은 포함하지 않음

확인된 호스트 이름 하나만 차단하려면 먼저 정확히 일치하는 규칙을 사용하세요.

도메인 접미사 매칭

키워드
DOMAIN-SUFFIX
매칭 값
ads.example.com
처리 정책
REJECT
매칭 범위
ads.example.com 및 그 하위 도메인

범위를 넓히기 전에 하위 도메인이 로그인, 이미지 또는 API 요청에도 사용되는지 확인하세요.

DOMAIN-SUFFIX,example.com,REJECT는 example.com과 a.example.com에 적용되지만, 문자열에 같은 글자가 포함되어 있다는 이유만으로 notexample.com에 매칭되지는 않습니다. 임의의 문자열을 검색하는 방식이 아니라 도메인 계층의 접미사를 기준으로 판단하며, *.example.com으로 작성할 필요도 없습니다.

규칙 순서: 먼저 일치한 규칙이 처리 결과를 결정

이 글에서 다루는 일반 규칙은 Config에 적힌 순서대로 위에서 아래로 검사하며, 먼저 일치한 규칙의 정책이 적용됩니다. 뒤에 있는 REJECT 규칙은 이미 일치한 허용 규칙을 뒤집지 않습니다. 따라서 문제를 확인할 때는 파일에 REJECT가 있는지만 보지 말고 대상 규칙과 그 앞에 있는 규칙도 함께 살펴보세요.

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

이 예시에서는 먼저 account.example.com을 DIRECT로 허용하고, 해당 도메인 접미사에 속하는 나머지 요청을 차단합니다. 접미사 차단 규칙을 첫 줄로 옮기면 계정 하위 도메인도 먼저 REJECT에 일치해, 뒤에 있는 정확한 예외 규칙이 적용되지 않습니다. 실제 Config를 수정할 때는 기존 아웃바운드 정책을 유지하세요. 예시에 나온 DIRECT 대체 규칙을 근거로 자신의 FINAL 규칙까지 DIRECT로 바꾸면 안 됩니다.

규칙 유형판단 기준확인할 사항
DOMAIN-SUFFIX대상 도메인과 하위 도메인의 접미사앞에 있는 도메인 허용 규칙이 먼저 매칭되는지
IP-CIDR대상 IP가 지정된 네트워크 대역에 속하는지하나의 주소를 여러 도메인이 공유할 수 있음
GEOIP대상 IP의 지리적 분류지리적 분류로 특정 콘텐츠를 판별할 수는 없음
FINAL앞선 규칙이 모두 일치하지 않을 때 적용되는 기본 규칙일반 매칭 규칙 뒤에 배치

도메인 규칙과 IP 규칙은 서로 다른 정보를 사용합니다. 도메인을 판단할 수 없는 경우에도 접미사 규칙이 적용될 것이라고 단정하지 마세요. 앞에 대상 IP와 일치하는 허용 규칙이 있다면 그 규칙이 뒤의 도메인 규칙에 미치는 영향도 확인해야 합니다. 요청이 특정 IP에 연결됐다는 이유만으로 해당 네트워크 대역 전체를 차단하면 안 됩니다. 같은 주소를 공유하는 다른 서비스에도 영향을 줄 수 있습니다.

Config에 적용하기: 한 번에 대상 하나만 수정

수정과 검증은 따로 진행하세요. 먼저 현재 Config와 라우팅 모드를 확인하고, 규칙을 하나 추가한 뒤 새 요청을 살펴봅니다. Global Routing의 Config 모드는 Config 규칙에 따라 트래픽을 분기합니다. Proxy 모드나 Direct 모드에서는 해당 Config의 REJECT 규칙이 적용되는지 검증할 수 없습니다. Scene 모드에서는 현재 Scene의 설정도 확인해야 하므로, 처음 테스트할 때는 Config 모드로 전환하는 편이 좋습니다.

4개 항목
Global Routing：Proxy / Direct / Config / Scene
443
HTTPS에서 흔히 사용하는 포트이며, 도메인 매칭 값에는 입력하지 않음
규칙 1개
각 테스트마다 규칙을 하나씩 추가하면 원인을 찾고 되돌리기 쉽습니다.

판단 기준: 먼저 Config를 확인한 뒤 차단 범위를 넓히기

알려진 도메인 하나로 REJECT가 적용되는지 확인한 뒤 DOMAIN-SUFFIX로 범위를 넓힐지 결정하세요. Config 변경, 아웃바운드 전환, 규칙 일괄 추가를 동시에 하지 마세요. 어떤 변경이 결과를 바꿨는지 판단하기 어려워집니다.

  1. 파일 확인. Config 화면에서 현재 선택된 Config를 확인하고, 먼저 백업한 다음 편집 기능을 여세요. 선택되지 않은 동명의 파일을 수정하지 않도록 주의하세요.
  2. 규칙 추가. [Rule] 섹션에 대상이 명확한 REJECT 규칙 하나를 추가하세요. 이를 먼저 허용할 수 있는 포괄적인 규칙보다 앞에 배치하고 필요한 정확한 허용 예외는 유지합니다.
  3. 저장 후 적용. 홈 화면으로 돌아가 Global Routing에서 Config 모드를 선택하고 연결 스위치가 켜져 있는지 확인하세요. 필요하면 연결을 다시 설정해 이후 테스트에 저장된 Config가 사용되도록 합니다.
  4. 새 요청 생성. 테스트 중인 페이지를 닫았다가 대상에 다시 접속하고, 요청 기록에서 대상 도메인, 매칭된 규칙, 처리 정책을 확인하세요. 이미 연결된 장시간 연결만으로 테스트하면 정확하지 않을 수 있습니다.
  5. 되돌리기 확인. 방금 추가한 규칙을 삭제하고 저장한 뒤 다시 적용하고, 같은 대상에 새 요청을 보내세요. 차단 전후와 규칙을 되돌린 후의 결과가 달라져야 변경과 결과 사이의 관계를 명확히 확인할 수 있습니다.

Settings → On Demand는 자동 연결 동작을 제어하며 도메인 차단 목록과는 관계가 없습니다. 테스트 중 연결을 수동으로 껐는데도 자동으로 다시 연결된다면 On Demand 설정을 먼저 확인하세요. 자동 재연결을 규칙을 되돌릴 수 없는 문제로 오해하지 않도록 주의해야 합니다. Config가 원격 업데이트로 덮어써질 수 있다면 직접 수정한 내용을 기록해 두고 업데이트 후에도 규칙이 유지되는지 확인하세요.

차단의 한계: 접미사만으로 같은 도메인의 콘텐츠를 구분할 수 없음

도메인 단위 차단은 해당 대상과의 연결을 전부 차단해도 괜찮은 경우에 적합합니다. 정상 콘텐츠와 차단하려는 콘텐츠가 같은 도메인에서 제공되면 DOMAIN-SUFFIX는 동일한 매칭 값으로 판단하므로 특정 경로만 허용할 수 없습니다. HTTPS 요청에서 이 규칙은 암호화된 페이지 내용을 읽고 분석하는 도구가 아닙니다.

연결을 차단해도 페이지에 남은 빈 공간이 사라지는 것은 아닙니다. 페이지 레이아웃은 앱이나 웹사이트에서 결정합니다. 리소스 로딩에 실패해도 원래 확보해 둔 영역이 그대로 남거나 오류 메시지가 표시될 수 있습니다. REJECT는 연결을 계속할지 결정하는 기능이지 레이아웃을 수정하는 기능이 아닙니다.

자주 발생하는 상황: 매칭 기록을 보고 다음 단계 결정

아래 문제 해결 절차는 이미 사용 가능한 Config를 보유한 경우를 전제로 합니다. 구독 문제가 있다면 구독 링크는 서비스 제공업체에서 확인하세요. 클라이언트 구매와 회선 요금제는 별개의 사안입니다. REJECT 규칙 하나를 해결하려고 구독 전체와 라우팅 설정을 모두 바꾸지 마세요.

규칙을 작성했는데 웹페이지가 계속 열리는 이유는?

먼저 홈 화면에서 Global Routing이 Config 모드인지 확인한 다음 Config 화면에서 현재 선택된 파일을 확인하세요. 대상을 다시 열고 새 요청을 살펴봅니다. 페이지가 다른 리소스 도메인을 사용했거나 캐시를 표시하고 있을 수 있으므로, 페이지가 보이는지만으로 판단하지 마세요.

기록에 REJECT가 표시되는데 콘텐츠가 계속 보이는 이유는?

기록에 표시된 도메인과 실제 콘텐츠를 불러오는 요청을 하나씩 대조하세요. 통계 도메인을 차단해도 콘텐츠 리소스까지 차단되는 것은 아닙니다. 테스트 페이지를 닫고 관련 캐시의 영향을 배제한 뒤 다시 요청하고, 대체 도메인이 사용되는지도 확인하세요. 여러 번의 재시도를 REJECT 정책이 적용되지 않은 것으로 오해하지 마세요.

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

이번에 추가한 규칙을 먼저 삭제하고 Config를 다시 적용해 기능이 복구되는지 확인하세요. 그런 다음 DOMAIN-SUFFIX 접미사 매칭을 DOMAIN 정확히 일치하는 규칙으로 좁히세요. 허용 예외가 필요하다면 포괄적인 차단 규칙보다 앞에 배치합니다. 같은 도메인에서 여러 기능을 제공한다면 차단 범위를 더 넓히지 마세요.

Config 업데이트 후 기존 규칙이 사라졌다면?

Config 화면에서 업데이트된 파일 내용을 확인하고 백업과 비교해 로컬 수정 사항이 덮어써졌는지, 다른 Config로 바뀌었는지 살펴보세요. 원래 위치에 규칙 하나를 복원한 다음 새 요청 테스트를 다시 진행하세요. 중복된 규칙 섹션을 여러 개 그대로 붙여 넣지 마세요.

최종 판단은 확인할 수 있는 세 가지 사실에 근거해야 합니다. 어떤 Config를 사용했는지, 새 요청이 어떤 규칙에 매칭됐는지, 변경 사항을 되돌린 뒤 문제가 복구됐는지 확인하세요. 세 가지를 안정적으로 재현할 수 있다면 규칙을 유지하고, 결과가 맞지 않는다면 차단 규칙을 더 추가하기보다 테스트 대상을 좁히세요.

App Store 정품 확인