Shadowrocket REJECT 규칙 작성법: 차단 원리, 규칙 매칭 순서와 한계

1. REJECT가 적용되는 위치: 대상 매칭 후 정책 실행

규칙은 두 가지를 판단합니다. 요청이 매칭 조건에 해당하는지, 해당한다면 어떤 정책을 적용할지입니다. 예를 들어 DOMAIN-SUFFIX,example.com,REJECT에서 DOMAIN-SUFFIX는 매칭 유형, example.com은 매칭 값, REJECT는 실행할 정책입니다. 규칙에 일치하면 해당 연결은 거부되며, 연결이 실패했다고 다음 규칙으로 넘어가지는 않습니다.

이 흐름은 대상 트래픽이 Shadowrocket의 처리 범위에 들어온다는 전제에서 성립합니다. 연결이 꺼져 있거나 트래픽이 터널을 우회하거나 현재 라우팅 모드가 해당 규칙을 사용하지 않는다면, REJECT를 수정해도 요청의 경로가 바로 바뀌지는 않습니다. 따라서 여러 차단 규칙을 먼저 추가하기보다 연결 상태, 라우팅 모드, Config 파일, 매칭된 규칙 순서로 확인하세요.

REJECT는 주로 네트워크 요청에 영향을 주며, 페이지에 이미 표시된 텍스트나 이미지 자리 표시자, 앱의 로컬 콘텐츠를 삭제하지 않습니다. 요청이 거부되면 리소스 로딩 실패, 빈 이미지, 앱의 재시도 또는 오류 메시지로 나타날 수 있습니다. 실제 현상은 앱의 오류 처리 방식에 따라 다르므로, 특정 화면 변화가 모든 앱에서 발생한다고 단정할 수 없습니다.

2. REJECT 규칙 문법: 도메인을 우선하고 IP 범위는 신중하게

호스트 이름 하나만 차단하려면 DOMAIN을 사용하고, 도메인과 하위 도메인까지 포함하려면 DOMAIN-SUFFIX를 사용합니다. 매칭 값에는 호스트 이름만 입력하고 https://, 포트, 경로, 쿼리 매개변수는 넣지 않습니다. 예를 들어 https://ads.example.com/banner의 호스트를 매칭하려면 전체 주소가 아니라 ads.example.com을 입력하세요.

DOMAIN-SUFFIX,example.com,REJECT는 example.com과 img.example.com에 적용되지만, 이 문자열이 포함된 모든 도메인에 적용되는 것은 아닙니다. 리소스 호스트 하나만 차단하려는 경우 루트 도메인 전체로 범위를 넓히지 마세요. 로그인, 이미지, API가 같은 루트 도메인의 서로 다른 하위 도메인에 있을 수 있습니다.

IP-CIDR은 IPv4 주소 또는 네트워크 대역을 매칭합니다. /32는 IPv4 주소 하나, /24는 256개 주소를 포함하는 네트워크 대역을 뜻합니다. 공유 인프라에 넓은 대역의 REJECT를 적용하면 관련 없는 여러 도메인에도 영향을 줄 수 있습니다. 도메인이 사용하는 IP는 바뀔 수 있으므로, 한 번 조회한 IP를 계속 차단해도 해당 도메인을 안정적으로 차단하는 것과 같지 않습니다.

3. 규칙 매칭 순서: 정확한 예외를 앞에, FINAL은 뒤에

Config 규칙을 기준으로 처리할 때는 위에서 아래로 확인하며, 처음 일치한 규칙이 적용 정책을 결정합니다. 뒤에 있는 더 구체적인 규칙이 앞에서 이미 매칭된 넓은 규칙을 자동으로 덮어쓰지는 않습니다. 흔한 실수는 도메인 전체를 대상으로 하는 REJECT를 먼저 쓰고, 유지해야 할 하위 도메인 예외를 뒤에 두는 것입니다. 이 경우 예외 규칙은 적용되지 않습니다.

[Rule]
DOMAIN,account.example.com,DIRECT
DOMAIN-SUFFIX,example.com,REJECT
IP-CIDR,192.0.2.8/32,REJECT,no-resolve
GEOIP,CN,DIRECT
FINAL,DIRECT

아래 순서 예시에서 account.example.com은 첫 번째 규칙에 먼저 매칭되므로 두 번째 규칙까지 확인하지 않습니다. img.example.com은 하위 도메인 규칙에 의해 거부됩니다. GEOIP,CN,DIRECT는 웹페이지 언어가 아니라 대상 IP의 지리 위치 데이터베이스를 기준으로 매칭합니다. 이 규칙을 REJECT 앞에 두면 조건에 맞는 요청이 먼저 허용될 수 있습니다.

FINAL은 도메인 매칭 값이 없는 기본 규칙입니다. 여기서 FINAL,DIRECT를 사용한 것은 예시를 완성하기 위해서일 뿐, 기존 Config의 최종 정책을 DIRECT로 바꾸라는 뜻이 아닙니다. 실제로 적용할 때는 기존 최종 정책을 유지하고 검증을 마친 정확한 규칙만 적절한 위치에 추가하세요. 차단 항목을 더하려고 같은 Config에 FINAL을 중복해서 추가하지 마세요.

4. Config에서 수정하고 확인하기: 한 번에 하나씩 추가

아래에서는 Home, Config, Settings 화면 구성을 기준으로 확인 위치를 설명합니다. 실제 편집 메뉴는 현재 앱 화면을 기준으로 확인하세요. 먼저 정상 작동하는 현재 Config의 사본을 보관한 뒤 선택된 Config를 수정합니다. 파일 이름만으로 현재 사용 중인 파일을 판단하지 말고, 구독 목록 업데이트를 Config 규칙 업데이트와 혼동하지 마세요.

1. 사용 모드를 확인합니다. Home에서 연결 상태와 Global Routing을 확인하세요. Config 규칙을 검증하려면 Config를 선택합니다. Proxy와 Direct는 이 글의 규칙 매칭을 확인하는 모드가 아닙니다. Scene을 사용하는 경우 현재 Scene에 설정된 라우팅 방식도 먼저 확인하세요.
2. 대상 Config를 확인합니다. Config로 이동해 현재 선택된 파일을 확인하고, 사본을 보관한 뒤 [Rule] 섹션을 찾습니다. 해당 섹션이 이미 있다면 그 안의 규칙을 편집하세요. 파일 끝에 같은 구조를 새로 중복해서 추가하지 마세요.
3. 최소한의 규칙을 추가합니다. 차단이 확실히 필요한 호스트 이름 하나를 선택하고, DOMAIN 규칙을 관련된 넓은 범위의 규칙보다 앞에 배치합니다. 다른 기존 정책은 그대로 유지하세요.
4. 저장하고 적용합니다. 저장한 파일이 현재 선택된 Config인지 확인한 뒤 화면의 안내에 따라 적용하세요. 연결을 다시 설정해야 한다면 진행 중인 다른 네트워크 작업에 영향을 줄 수 있다는 점에 유의하세요.
5. 요청을 다시 보냅니다. 대상 페이지나 관련 앱을 닫았다가 다시 열어 새 연결을 시도하세요. 대상 도메인, 매칭된 규칙, 적용 정책을 기록합니다. 로그에 정보가 충분히 표시되지 않는다면 화면이 비어 있다는 이유만으로 REJECT에 매칭됐다고 판단하지 마세요.
6. 한 가지 변경만 되돌려 확인합니다. 방금 추가한 규칙 하나를 삭제하고 저장한 다음 같은 작업을 다시 테스트하세요. 변경 전후를 비교해 규칙을 유지할지, 범위를 좁힐지, 추가로 확인할지 결정합니다.

이미 연결된 세션, 브라우저 캐시, 앱의 로컬 캐시 때문에 규칙을 수정해도 화면이 예상과 다르게 보일 수 있습니다. 설정을 여러 개 연달아 바꾸기보다 대상 요청을 새로 보내세요. 기록할 때는 ‘새 요청이 거부됨’, ‘새 요청이 발생하지 않음’, ‘요청은 성공했지만 화면이 바뀌지 않음’을 구분해야 합니다. 각각 다음 단계가 다릅니다.

5. 차단 기능의 한계: 같은 도메인의 콘텐츠, 캐시, 공유 IP

도메인 규칙은 인식 가능한 대상 정보에 따라 트래픽을 분기합니다. 정상 API와 차단하려는 콘텐츠가 같은 호스트 이름을 사용하고 URL 경로만 다르면 DOMAIN과 DOMAIN-SUFFIX로 둘을 구분할 수 없습니다. 해당 호스트 이름에 REJECT를 적용하면 정상 API 요청까지 함께 거부될 수 있습니다.

• HTTPS 경로는 도메인 조건이 아닙니다.https://api.example.net/feed와 https://api.example.net/banner는 호스트 이름이 같습니다. DOMAIN-SUFFIX 뒤에 /banner를 붙여 경로별로 차단할 수 없으며, 443 포트만으로 두 종류의 요청을 구분할 수도 없습니다.
• 로컬 콘텐츠는 차단할 요청을 만들지 않습니다. 이미 다운로드한 리소스, 오프라인 페이지, 앱에 포함된 콘텐츠는 네트워크 규칙을 추가해도 바로 사라지지 않습니다.
• 공유 IP만으로 특정 사이트를 정확히 지정할 수 없습니다. 하나의 IP에서 여러 도메인을 호스팅할 수 있습니다. 식별 가능한 도메인 규칙을 먼저 확인하고, 특정 리소스를 차단하려고 주소 대역 전체를 거부하지 마세요.
• 연결 정보가 항상 완전한 것은 아닙니다. IP를 직접 사용하는 요청은 도메인 규칙만으로 매칭할 수 없습니다. 도메인 정보를 사용할 수 있는지는 실제 DNS 조회와 연결 경로에 따라 달라지므로 연결 기록과 함께 확인해야 합니다.
• 서버 측 리소스 위치는 바뀔 수 있습니다. 대상의 도메인, 주소 또는 요청 방식이 변경될 수 있습니다. 기존 규칙이 매칭되지 않으면 요청 대상을 다시 확인하고, 무작정 루트 도메인 전체로 범위를 넓히지 마세요.

따라서 REJECT는 특정 대상 연결을 거부하는 데 사용할 수 있지만, 모든 홍보 콘텐츠를 제거하거나 차단 후에도 페이지 레이아웃이 온전하게 유지된다고 보장하지는 않습니다. Shadowsocks, VMess, VLESS, Trojan, Hysteria2, WireGuard 등의 프로토콜로 바꿔도 DOMAIN-SUFFIX가 웹페이지 내용을 읽고 필터링할 수 있게 되는 것은 아닙니다. 아웃바운드 프로토콜과 규칙 매칭은 서로 다른 역할을 합니다.

6. 자주 묻는 질문: 적용되지 않음, 오차단, 업데이트 후 변경

장기적으로 관리할 때는 수정할 때마다 대상 호스트, 추가 이유, 되돌리는 방법을 기록하세요. 오차단이 발생하면 먼저 정상 사용이 가능한 상태로 복구한 뒤 대상 요청을 분석합니다. DNS, 아웃바운드 프로토콜, 전체 규칙을 한꺼번에 바꾸면 결과가 달라진 원인을 파악하기 어렵습니다. 추가로 확인하려면 문제 해결 가이드에서 현재 Config와 연결 기록을 점검하세요.

이 글은 사용자가 자체 서비스와 구독을 보유하고 있다는 전제하에 로컬 규칙 관리 방법만 설명합니다. 이 사이트는 노드, 구독, 연결 서비스를 제공하거나 판매 또는 추천하지 않습니다. 앱의 일회성 구매와 네트워크 서비스 요금제는 별개이며, REJECT를 추가해도 새로운 연결 설정이 만들어지지 않습니다.