Shadowrocket REJECT 규칙 사용법: 차단 원리와 적용 범위

Home과 Config 확인하기: REJECT가 적용되는 위치

Home에서 Global Routing을 확인하고, 이 글의 규칙을 시험할 때는 Config를 선택한 뒤 현재 사용 중인 구성 파일을 Config에서 확인하세요. 구성 편집 화면을 열어 [Rule] 섹션을 살펴봅니다. 규칙을 파일에 작성해도 해당 파일을 활성화하지 않으면 현재 연결 처리 방식은 바뀌지 않습니다. Home의 연결 스위치가 꺼져 있을 때도 검색 결과만으로 규칙 적용 여부를 판단할 수 없습니다.

REJECT는 규칙이 일치했을 때 적용하는 정책이지, 규칙 유형이나 서버 이름이 아닙니다. 먼저 요청이 조건에 맞는지 판단한 뒤, 일치하면 요청을 거부합니다. 특정 프록시 서버로 요청을 보낸 다음 거부하는 방식이 아니며, 기기에 이미 저장된 웹 콘텐츠를 삭제하지도 않습니다.

Settings → On Demand에서는 조건에 따라 연결을 설정하거나 끊는 동작을 관리합니다. [Rule]의 도메인 매칭을 대신하지는 않습니다. 테스트 중 연결 상태가 계속 바뀐다면 먼저 On Demand 조건을 확인하세요. 연결이 유지되지 않는 문제를 해결하려고 REJECT 규칙을 반복해서 추가하지 마세요.

매칭 순서 이해하기: 앞선 규칙에 일치하면 검색 중단

일반적인 규칙 라우팅에서는 위에서 아래 순서로 규칙을 확인합니다. 요청이 규칙 하나와 일치하면 해당 규칙의 정책을 적용하며, 더 적합한 정책을 찾기 위해 다음 규칙을 계속 확인하지 않습니다. 따라서 정확한 허용 규칙은 보통 범위가 넓은 차단 규칙보다 앞에 둡니다. FINAL은 앞선 규칙과 일치하지 않은 요청에 적용됩니다.

[Rule]
# 먼저 이 도메인만 직결 허용
DOMAIN,help.example.com,DIRECT
# 다음으로 example.com과 하위 도메인 거부
DOMAIN-SUFFIX,example.com,REJECT
# 이 예시의 나머지 요청은 직결 처리, 문법 설명용
FINAL,DIRECT

이 세 규칙에서는 help.example.com이 첫 번째 규칙과 먼저 일치해 DIRECT가 적용됩니다. media.example.com은 두 번째 규칙과 일치해 REJECT가 적용되고, 나머지 미일치 도메인은 FINAL에서 처리됩니다. 두 번째 규칙을 첫 번째 규칙보다 위로 옮기면 도움말 페이지도 거부됩니다. 이 페이지 역시 example.com의 하위 도메인이기 때문입니다.

규칙 범위 선택하기: DOMAIN과 DOMAIN-SUFFIX 작성법

특정 호스트 이름 하나만 차단하려면 DOMAIN을 우선 사용하세요. 기본 도메인과 모든 하위 도메인을 차단하려면 DOMAIN-SUFFIX를 사용합니다. 두 규칙 모두 대상 필드에는 도메인만 입력해야 하며 프로토콜, 포트, 경로 또는 쿼리 매개변수는 포함하지 않습니다. 예를 들어 https://ads.example.com/banner 전체를 도메인 필드에 입력할 수 없습니다.

IP-CIDR은 IP 주소 범위를 기준으로 매칭하고, GEOIP는 IP의 지리적 위치 정보를 기준으로 매칭합니다. 둘 다 도메인 접미사 매칭과는 다릅니다. 예시의 no-resolve는 이 IP 규칙을 위해 별도로 도메인 조회를 하지 않는다는 뜻입니다. 따라서 요청에 도메인만 있는 경우 이 주소 규칙과 반드시 일치한다고 볼 수 없습니다. 공유 IP에 REJECT를 적용하면 같은 주소를 사용하는 다른 사이트에도 영향을 줄 수 있습니다.

적용 범위 확인하기: REJECT는 웹페이지 요소별로 필터링할 수 없음

REJECT는 페이지에서 별도로 요청하는 특정 도메인처럼 독립적으로 식별할 수 있는 네트워크 대상을 거부하는 데 적합합니다. 웹페이지 요소를 걸러내는 기능은 아닙니다. 본문, 이미지, 차단하려는 콘텐츠가 같은 호스트 이름을 사용한다면 간단한 도메인 규칙으로 특정 경로만 구분할 수 없습니다. 해당 도메인을 거부하면 본문 API, 로그인 확인 또는 정적 리소스 로드까지 실패할 수 있습니다.

• 같은 도메인의 서로 다른 경로:example.com/news와 example.com/banner는 DOMAIN 규칙으로 따로 처리할 수 없습니다. 경로는 이 규칙의 매칭 필드가 아닙니다.
• 이미 캐시된 콘텐츠: REJECT 규칙과 일치한 뒤에도 이전에 캐시된 이미지나 텍스트가 페이지에 표시될 수 있습니다. 기존 페이지의 내용이 사라졌는지만 보지 말고 새 요청의 처리 기록을 확인하세요.
• 대상 도메인 변경: 페이지가 다른 호스트 이름으로 콘텐츠를 다시 요청할 수 있습니다. 새 요청의 실제 대상을 확인하고, 이름이 비슷하다는 이유만으로 접미사 범위를 계속 넓히지 마세요.
• 대상 IP만 표시: 매칭 단계에서 사용할 수 있는 도메인 정보가 없다면 DOMAIN-SUFFIX가 일치한다고 가정할 수 없습니다. 먼저 기록에 표시된 대상 유형을 확인하세요.
• 공유 인프라: 하나의 IP에서 여러 도메인이 운영될 수 있습니다. IP-CIDR로 바꾼다고 정확도가 자동으로 높아지는 것은 아니며, 넓은 네트워크 대역을 차단할 때는 특히 주의해야 합니다.

HTTPS가 암호화된다고 해서 모든 도메인 규칙이 무효가 되는 것은 아닙니다. 그렇다고 REJECT가 웹페이지 내용을 복호화해 검사하는 것도 아닙니다. 네트워크 대상을 차단하려고 HTTPS 복호화를 먼저 켜거나 인증서를 설치하지 마세요. 이 글의 규칙 검증에는 그런 작업이 필요하지 않습니다. 웹페이지에 빈 공간이 남아 있어도 규칙이 실패한 것은 아닙니다. 네트워크 요청을 거부해도 페이지 레이아웃에서 해당 영역이 자동으로 제거되지 않을 수 있습니다.

검증 및 되돌리기: 실제 요청으로 오차단 확인

Config에서 변경 사항을 저장한 뒤 해당 구성이 활성화되어 있는지 다시 확인하세요. Home으로 돌아가 Global Routing이 Config인지 확인하고, 필요하면 연결을 다시 설정한 다음 대상 페이지를 새로 열어 요청을 발생시키세요. 앱 내 요청 기록에서 대상 도메인이나 IP, 적용된 정책, 확인 가능한 규칙 정보를 살펴보세요. 기록 메뉴와 표시 항목은 현재 화면을 기준으로 확인하면 됩니다.

1. 원본 구성을 먼저 보관: 수정 전에 복구할 수 있는 사본을 보관하고 추가한 규칙의 위치를 기록하세요. 나중에 변경을 되돌릴 수 있어야 합니다.
2. 한 번에 한 항목만 변경: 먼저 정확한 규칙 하나를 추가하고 저장한 뒤 검증하세요. Global Routing, DNS, 여러 IP 규칙을 동시에 바꾸면 원인을 파악하기 어렵습니다.
3. 새 요청이 발생했는지 확인: 기록에 대상 요청이 없다면 페이지를 새로고침하거나 관련 기능을 다시 여세요. 캐시된 결과나 기존 연결을 새 규칙의 결과로 오해하지 않도록 합니다.
4. 실제 적용 정책 확인: 기록에 DIRECT 또는 다른 정책이 표시되면 더 앞에 있는 규칙과 일치했는지 확인하세요. REJECT가 표시되는데도 페이지에 콘텐츠가 남아 있다면 캐시와 다른 요청 도메인을 살펴보세요.
5. 최소 범위로 되돌리기: 가장 최근에 추가한 규칙부터 취소하세요. 접미사 차단을 유지해야 한다고 확인되면 정확한 예외를 그보다 위에 두고 기존 구성에서 필요한 허용 정책을 사용하세요.

허용한다고 해서 반드시 DIRECT를 사용해야 하는 것은 아닙니다. DIRECT는 직접 연결을 뜻합니다. 기존 구성에서 프록시를 사용해야 하는 서비스라면 원래 적용되던 정책을 복원하세요. 앞서 나온 DIRECT는 예외 규칙의 순서를 보여주는 예시일 뿐, 모든 서비스에 그대로 적용하면 안 됩니다. 복원할 정책 이름이 정책 그룹을 참조한다면 해당 이름이 현재 구성에 있는지도 확인하세요.

최종 확인에서는 두 가지를 모두 만족해야 합니다. 대상의 새 요청에 예상한 REJECT가 적용되고, 유지해야 하는 로그인·이미지·API 요청에는 올바른 정책이 적용되어야 합니다. 특정 페이지가 열리지 않는지만으로 규칙이 정확하다고 판단할 수 없습니다. 재현 가능한 대상, 명확한 매칭 범위, 복구 가능한 구성이 이후 관리의 기준입니다.