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

규칙에서 REJECT란: 하나의 아웃바운드 정책

Shadowrocket의 규칙 한 줄은 유형,값,정책 세 부분으로 이루어지고, 정책 자리에는 PROXY(현재 선택된 서버로 아웃바운드), DIRECT(로컬 직접 연결, 프록시를 거치지 않음), REJECT(이 연결을 로컬에서 거부 또는 폐기) 세 가지 값만 들어갑니다. REJECT는 Settings에 있는 일괄 스위치가 아니라 특정 규칙 하나의 동작이며, 그 규칙에 매칭된 연결만 차단됩니다.

최소한으로 동작하는 차단 규칙은 다음과 같습니다:

DOMAIN-SUFFIX,ads.example.com,REJECT
DOMAIN-KEYWORD,metrics,REJECT
IP-CIDR,203.0.113.0/24,REJECT,no-resolve
FINAL,PROXY

규칙은 현재 Config 파일에 기록되며(Home → 현재 구성 → 편집), Home의 규칙 목록에서 직접 추가하거나 삭제할 수도 있습니다. 수정한 뒤에는 해당 Config를 다시 선택해야 매칭에 참여합니다. 구독을 업데이트하면 구성 파일을 다시 가져오므로 로컬에서 직접 고친 규칙이 덮어써질 수 있으니, 업데이트 후에는 한 번 확인하는 편이 좋습니다.

매칭 순서: REJECT는 언제 차례를 얻는가

새 연결마다 규칙 매칭은 한 번만 이루어집니다. 목록 첫 줄부터 한 줄씩 비교하고, 처음으로 매칭된 규칙이 그 연결의 방향을 결정하며 뒤의 규칙은 참여하지 않습니다. REJECT가 적용될 수 있는지는 앞쪽에 더 넓은 규칙이 있어 이 연결을 먼저 가져가는지에 달려 있습니다.

순서 문제는 규칙의 넓고 좁음에서 비롯됩니다. DOMAIN-KEYWORD,ads,REJECT가 DOMAIN-SUFFIX,ads.example.com,PROXY보다 앞에 있으면 ads.example.com은 keyword 규칙에 먼저 걸립니다. 반대로 배치하면 좁은 규칙이 먼저 매칭되어 뒤의 keyword 규칙은 이 연결에 적용될 기회를 얻지 못합니다. 좁은 규칙을 앞에, 넓은 규칙을 뒤에 두는 것이 규칙 목록의 기본 배열 방식입니다.

DOMAIN,api.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN-KEYWORD,metrics,REJECT
IP-CIDR,198.51.100.0/24,REJECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

이 여섯 줄은 바로 쓸 수 있는 골격입니다: 정확한 도메인 → 도메인 접미사 → 키워드 → IP 대역 → 지역 정보 → 최종 처리, 구체적인 규칙일수록 앞에 둡니다.

FINAL은 앞에서 매칭되지 않은 모든 연결을 처리하는 최종 규칙으로 반드시 마지막 줄에 있어야 합니다. 중간에 두면 그 뒤에 오는 모든 규칙이 무효가 됩니다. IP 계열 규칙에는 세부 사항이 두 가지 더 있습니다. no-resolve가 붙으면 이 규칙은 DNS 조회를 트리거하지 않고 대상이 IP 리터럴일 때만 매칭됩니다. no-resolve가 없는 IP-CIDR은 도메인을 먼저 IP로 해석한 뒤 비교하므로, 해석 결과에 따라 될 때와 안 될 때가 갈릴 수 있습니다.

• FINAL이 마지막 줄에 있지 않아 그 뒤에 오는 규칙이 모두 무효가 된 경우입니다.
• DOMAIN-KEYWORD가 DOMAIN 또는 DOMAIN-SUFFIX보다 앞에 있어, 정확히 처리해야 할 도메인까지 함께 차단된 경우입니다.
• GEOIP,CN,DIRECT가 구체적인 도메인 규칙보다 앞에 있어 중국 본토 도메인이 모두 DIRECT로 처리되고, 뒤의 규칙은 차례를 얻지 못한 경우입니다.
• 구독에 포함된 규칙이 직접 추가한 규칙보다 앞에 있어, 직접 만든 규칙이 끝내 매칭되지 않는 경우입니다.

차단 경계: HTTPS, 앱 내부 요청, 도메인 프론팅

REJECT는 연결이 맺어지는 단계에서 동작합니다. 연결을 로컬에서 거부하거나 폐기할 뿐, TLS 핸드셰이크 이후의 데이터 교환에는 관여하지 않습니다. 여기서 능력의 상한이 정해집니다. REJECT가 다루는 것은 '이 연결이 통과할 수 있는가'이지 '페이지에 무엇이 표시되는가'가 아닙니다.

경계 1: HTTPS는 연결 계층까지만 차단

https://ads.example.com/x.js 같은 요청에서 REJECT가 막는 것은 ads.example.com:443으로 가는 연결이며, 스크립트는 당연히 받아지지 않습니다. 하지만 광고 콘텐츠가 본문과 같은 도메인에서 온다면(예: example.com 아래의 특정 API) REJECT는 힘을 쓰지 못합니다. 도메인을 통째로 막으면 본문도 함께 열리지 않기 때문입니다. 규칙에는 URL 경로를 매칭하는 키워드가 없고, 클라이언트는 HTTPS 요청의 경로를 볼 수 없습니다.

경계 2: 앱 내부 요청과 하드코딩된 IP

많은 앱이 리포팅 주소를 IP 리터럴로 박아 넣거나, API에서 도메인을 동적으로 내려받습니다. 전자는 도메인 규칙으로 매칭되지 않아 IP-CIDR로 받쳐야 하고, 후자는 실제 도메인이 나타난 뒤에 규칙을 추가해야 합니다. IP로 차단할 때의 대가는 오탐이 나기 쉽다는 점입니다. 같은 대역에 정상 서비스가 함께 있는 경우가 많고, CDN IP를 공유하는 환경에서는 특히 그렇습니다. 도메인 규칙과 IP 규칙은 서로를 보완하는 두 진입점이며, 각각 아래 두 가지 요청 방식에 대응합니다:

DOMAIN-SUFFIX,ads.example.com,REJECT
IP-CIDR,203.0.113.0/24,REJECT,no-resolve

또 하나의 세부 사항은 QUIC입니다. UDP 443으로 가는 연결도 규칙 매칭을 거치지만, no-resolve가 붙은 IP-CIDR을 쓰고 있고 앱이 도메인 형태로 연결을 시작했다면 이 규칙은 조회를 트리거하지 않으므로 매칭되지 않습니다.

경계 3: 도메인 프론팅

도메인 프론팅(domain fronting)은 TLS 핸드셰이크의 SNI와 요청이 실제로 향하는 Host를 서로 다르게 만드는 방식이며, SNI는 보통 '깨끗한' 도메인입니다. Shadowrocket은 연결의 대상 도메인, 즉 SNI를 기준으로 규칙을 매칭하고, DOMAIN-SUFFIX가 막는 것은 SNI에 적힌 도메인입니다. SNI 기준으로 막으면 같은 진입점을 쓰는 정상 서비스까지 영향을 받고, Host 기준 차단은 클라이언트 규칙이 처리할 수 있는 범위 밖입니다.

규칙을 썼는데 적용되지 않을 때: 이 순서로 점검

규칙이 적용되지 않는 이유는 대부분 '현재 적용 중인 구성'과 '매칭 순서' 두 가지에 있습니다. 아래 순서대로 하나씩 확인하는 편이 규칙을 반복해서 다시 쓰는 것보다 빠릅니다.

1. 현재 적용 중인 Config 확인

   Home 상단에 표시된 구성 이름을 확인합니다. 규칙은 A 구성에 썼는데 현재 선택된 것이 B라면 그 규칙은 매칭에 참여하지 않습니다.

2. 목록에서 규칙 위치 확인

   더 앞에 있는 넓은 규칙이 먼저 매칭되지 않는지, 특히 DOMAIN-KEYWORD가 DOMAIN-SUFFIX보다 앞에 있는 경우를 확인합니다.

3. 연결이 도메인으로 시작됐는지 IP로 시작됐는지 확인

   도메인 규칙은 IP 직접 연결에 매칭되지 않고, no-resolve가 붙은 IP-CIDR도 도메인 연결에 대해 조회를 트리거하지 않습니다.

4. Global Routing 상태 확인

   Proxy 또는 Direct에 머무는 동안에는 규칙 목록이 라우팅 판단에 참여하지 않습니다. Config로 돌아와야 규칙을 한 줄씩 매칭합니다.

5. 구독 업데이트 후 규칙 재확인

   구독을 업데이트하면 구성을 다시 가져오므로 로컬에서 직접 고친 규칙이 덮어써질 수 있습니다. 업데이트 후 Home으로 돌아가 규칙이 남아 있는지 확인합니다.

REJECT에 관한 자주 묻는 질문 5가지