Shadowrocket REJECT 규칙 설정법: 차단 원리, 규칙 우선순위와 한계

이 글 한눈에 보기

이 글은 Shadowrocket에서 이미 보유한 설정을 사용하며 차단 규칙을 몇 개 추가하려는 사용자를 대상으로 합니다. 규칙 조건과 REJECT 정책을 구분한 뒤, 설정 백업, 정확한 규칙 추가, 순서 확인, 새 요청 검증 순서로 진행합니다. 예시에는 문서용 예약 도메인과 주소를 사용해 문법을 설명하며, 기존 설정을 통째로 대체할 차단 목록은 아닙니다.

1. REJECT는 정책이며 도메인 매칭 조건이 아닙니다

규칙은 일반적으로 매칭 유형, 매칭 대상, 처리 정책으로 구성됩니다. 예를 들어 DOMAIN-SUFFIX,ads.example.com,REJECT에서 DOMAIN-SUFFIX는 매칭 방식을, ads.example.com은 매칭할 도메인 접미사를, REJECT는 규칙에 일치한 뒤 적용할 처리 정책을 뜻합니다. REJECT만 적어서는 어떤 도메인을 차단할지 지정할 수 없습니다.

요청이 Shadowrocket의 처리 대상에 들어오고 현재 설정에 따라 규칙 매칭이 진행될 때, REJECT 규칙에 일치한 연결은 거부됩니다. 해당 요청에 적용될 수 있었던 DIRECT 또는 프록시 정책으로 전달되지 않습니다. 웹페이지 요소를 삭제하거나 빈 공간을 다시 배치하는 기능은 아니므로, 앱에는 로드 실패나 자리 표시 영역, 재시도 안내가 표시될 수 있습니다.

앱에서 요청 시작 처리 대상에 진입 설정 규칙 매칭 거부 정책과 일치 이번 연결 거부

규칙 매칭은 연결을 처리하는 과정에서 이루어지지만, 이를 근거로 “REJECT 규칙에 일치하면 DNS 조회가 절대 발생하지 않는다”고 단정해서는 안 됩니다. 도메인 해석, 캐시, IP 규칙에 사용할 주소를 확보하는 과정에 따라 실제 동작은 달라질 수 있습니다. REJECT는 매칭된 연결을 거부하는 정책이지, 별도의 DNS 개인정보 보호 설정이 아닙니다.

2. 자주 쓰는 규칙: 정확한 도메인, 접미사, IP 대역

먼저 정확한 도메인으로 시작하고, 하위 도메인 전체를 차단해야 한다고 확인된 경우에만 DOMAIN-SUFFIX로 범위를 넓히세요. 규칙의 도메인에는 https://, 경로, 쿼리 매개변수, 끝의 슬래시를 넣지 않습니다. 아래 규칙은 문법을 각각 설명하기 위한 예시이며, 모두 같은 설정에 추가할 필요는 없습니다.

[Rule]
DOMAIN,ads.example.com,REJECT
DOMAIN-SUFFIX,metrics.example.com,REJECT
IP-CIDR,192.0.2.0/24,REJECT,no-resolve
IP-CIDR6,2001:db8::/32,REJECT,no-resolve

규칙 유형	매칭 범위	사용 시 주의사항
`DOMAIN`	지정한 전체 도메인입니다.	확인된 호스트 이름 하나만 거부할 때 적합합니다.
`DOMAIN-SUFFIX`	지정한 도메인과 그 하위 도메인입니다.	`metrics.example.com`은 `a.metrics.example.com`에도 적용되지만, `othermetrics.example.com`에는 적용되지 않습니다.
`IP-CIDR`	IPv4 주소 대역입니다.	공유 주소에는 정상적인 서비스도 함께 호스팅될 수 있으므로, 도메인이 해석된 IP 주소를 전용 주소로 간주해서는 안 됩니다.
`IP-CIDR6`	IPv6 주소 대역입니다.	IPv4 규칙만으로는 IPv6 대상 주소를 차단할 수 없습니다.

no-resolve는 이 IP 규칙을 위해 도메인을 IP로 직접 해석하지 않도록 합니다. 모든 DNS 조회를 끈다는 뜻은 아니며, 대상이 처음부터 IP 주소인 요청의 매칭을 막지도 않습니다. 예시의 192.0.2.0/24와 2001:db8::/32는 문서용 주소이므로 실제 서비스가 차단될 것으로 기대해서는 안 됩니다.

4가지 유형

위 표는 도메인 매칭 2종류와 IP 대역 매칭 2종류를 구분합니다.

/32

IPv4 단일 주소의 프리픽스 길이입니다. 예: 192.0.2.8/32

/128

IPv6 단일 주소의 프리픽스 길이입니다. 예: 2001:db8::8/128

판단 기준: 매칭 범위를 좁게 시작하고 차단 범위를 단계적으로 확대하세요

불필요한 요청을 보내는 호스트 이름 하나만 확인됐다면 먼저 DOMAIN 규칙을 추가하세요. 하위 도메인별 용도를 하나씩 확인한 뒤에만 DOMAIN-SUFFIX로 바꾸고, 공유 IP 대역 전체를 먼저 차단하지 마세요.

3. 규칙 순서: 예외는 앞에, FINAL은 뒤에

일반 규칙 목록은 위에서부터 순서대로 매칭되며, 먼저 일치한 규칙이 처리 정책을 결정합니다. REJECT를 목록 끝에 둔다고 해서 앞서 적용된 허용 규칙을 덮어쓰는 것은 아닙니다. 마찬가지로 앞의 광범위한 차단 규칙이 먼저 일치하면 뒤의 예외 규칙으로 취소할 수 없습니다.

[Rule]
DOMAIN,assets.ads.example.com,DIRECT
DOMAIN-SUFFIX,ads.example.com,REJECT
IP-CIDR,192.0.2.0/24,REJECT,no-resolve
GEOIP,CN,DIRECT
FINAL,DIRECT

이 예시에서는 assets.ads.example.com이 먼저 정확한 예외 규칙에 일치하고, video.ads.example.com은 다음 접미사 차단 규칙에 일치합니다. GEOIP는 대상 IP의 지리적 위치를 기준으로 매칭하며 콘텐츠 용도를 판별하지 않습니다. 이를 차단 규칙보다 앞에 두면 조건에 맞는 요청이 먼저 DIRECT로 처리될 수 있습니다. FINAL은 앞선 규칙이 하나도 일치하지 않을 때 적용되는 기본 규칙이므로 목록 끝에 두세요.

정확한 예외

유형: DOMAIN
대상: assets.ads.example.com
정책: DIRECT
위치: 이 도메인을 포함하는 접미사 차단 규칙보다 앞에 둡니다.

DIRECT는 직접 연결을 뜻할 뿐입니다. 실제 예외에는 해당 서비스에 필요한 정책을 사용하세요.

접미사 차단

유형: DOMAIN-SUFFIX
대상: ads.example.com
정책: REJECT
위치: 정확한 예외 뒤, 광범위한 허용 규칙과 FINAL 앞에 둡니다.

이 글의 FINAL,DIRECT는 기본 처리 방식을 설명하기 위한 예시이며, 기존 트래픽 분기 정책을 대체하라는 의미가 아닙니다.

규칙을 병합할 때는 기존 [Rule] 섹션에 해당 행을 추가하세요. 섹션 전체를 중복해서 붙여 넣거나 기존 프록시 정책, 규칙 참조, 기본 처리 설정을 바로 삭제해서는 안 됩니다. 설정에 외부 규칙 참조가 있다면 참조가 들어간 위치를 포함해 전체 순서를 확인하세요. 새로 추가한 몇 줄만 확인해서는 부족합니다.

4. Config에서 수정하고 적용 여부 확인하기

규칙은 설정 파일에 저장되며, 기존 노드 구독은 주로 연결 정보를 제공합니다. 구독을 업데이트해도 규칙을 편집한 것이 되지는 않습니다. 작업 전 현재 정상적으로 작동하는 설정을 따로 보관한 뒤 Config에서 편집 중인 파일과 실제 사용 중인 파일이 같은지 확인하세요. 원격 설정을 업데이트하면 로컬 수정 내용이 덮어써질 수 있으므로 사용자 규칙의 사본을 보관해야 합니다.

기존 상태를 기록합니다. Home → Global Routing의 현재 선택 항목과 Config에서 활성화된 설정을 기록하고 원본 파일을 보관해 복구할 수 있도록 합니다.
테스트 규칙 하나만 추가합니다. Config에서 대상 설정의 편집 화면을 열고 [Rule] 안에 확인된 대상의 DOMAIN 규칙을 추가합니다. 먼저 일치할 수 있는 광범위한 규칙보다 앞에 배치한 다음 저장하고 해당 설정을 활성화합니다.
규칙 모드를 사용합니다. Home → Global Routing에서 Config를 선택합니다. Proxy와 Direct는 서로 다른 전역 처리 방식이므로 같은 Config 규칙의 일치 여부를 확인하는 용도로 서로 바꿔 사용할 수 없습니다. Scene을 사용한다면 해당 장면에서 실제로 선택된 설정과 라우팅 상태를 먼저 확인하세요.
요청을 새로 보냅니다. 연결이 활성화되어 있는지 확인한 다음 대상 페이지를 닫았다가 다시 엽니다. 필요하면 연결을 끊었다가 다시 연결해 새 연결을 만드세요. 기존 장시간 연결의 화면만 새로 고치면 규칙 변경이 반영되지 않을 수 있습니다.
기록을 확인합니다. 연결 기록이나 로그에서 대상 도메인, 대상 주소, 매칭된 규칙, 처리 정책을 확인하세요. 새 요청이 REJECT에 일치했는지를 근거로 판단하고, 페이지의 특정 영역이 잠시 사라진 것만으로 결론 내리지 마세요.

5. 도메인 차단의 한계와 오차단 원인

DOMAIN과 DOMAIN-SUFFIX는 호스트 이름을 기준으로 처리하며, 페이지의 특정 콘텐츠만 대상으로 삼지는 않습니다. HTTPS 요청에서 https://example.com/news와 https://example.com/promo처럼 한 호스트의 서로 다른 경로를 이 두 도메인 규칙만으로 구분할 수 없습니다. example.com을 거부하면 두 경로에 해당하는 연결이 모두 영향을 받습니다.

정상 콘텐츠와 차단 대상이 같은 도메인을 사용합니다. 이미지, 로그인, 결제 인증, 통계 요청이 같은 인프라를 사용할 수 있습니다. 로그인이 실패하거나 이미지가 표시되지 않으면 최근 추가한 규칙부터 되돌린 다음 호스트 이름을 하나씩 확인하세요.
요청에 IP 주소만 표시됩니다. 규칙 엔진에서 연결된 도메인을 확인할 수 없다면 DOMAIN-SUFFIX 규칙만으로는 IP를 보고 어떤 도메인에 속하는지 판단할 수 없습니다. 매칭되지 않은 원인을 모두 규칙 순서 탓으로 돌리지 마세요.
콘텐츠가 캐시되었거나 기존 연결을 사용합니다. 오프라인 데이터, 로컬 캐시, 재사용 중인 연결 때문에 규칙을 수정한 뒤에도 페이지가 달라지지 않은 것처럼 보일 수 있습니다. 이전 화면만 살피지 말고 규칙을 활성화한 뒤 새 요청을 확인하세요.
호스트 이름이나 네트워크 주소가 바뀝니다. 도메인이 대체 호스트로 전환될 수 있고 주소도 바뀔 수 있습니다. 일시적으로 확인된 IP에 IP-CIDR 규칙을 추가하면 금방 적용되지 않게 되거나 같은 주소를 공유하는 다른 사이트까지 오차단할 수 있습니다.
요청이 대상 설정에 따라 처리되지 않습니다. 연결이 활성화되지 않았거나 다른 설정을 선택했거나 Global Routing 상태가 맞지 않으면 검증 결과가 부정확해집니다. 먼저 요청의 처리 경로를 확인한 다음 차단 범위를 넓히세요.

도메인 차단을 위해 보통 HTTPS 복호화를 켤 필요는 없습니다. 인증서를 추가하거나 관계없는 설정을 변경해도 “한 도메인에서 여러 콘텐츠를 제공하는” 문제의 매칭 범위가 달라지지는 않습니다. 별도로 구분할 수 없는 리소스는 기능상 한계를 고려해야 하며, REJECT 규칙 하나로 특정 페이지 콘텐츠를 완전히 제거할 수 있다고 보장할 수 없습니다.

6. 자주 묻는 질문: 규칙 미일치, 오차단, 업데이트 후 복구

REJECT를 추가했는데도 페이지가 열리는 이유는 무엇인가요?

먼저 차단하려는 대상이 페이지 전체의 호스트인지, 페이지 안의 리소스 호스트인지 확인하세요. Home → Global Routing에서 Config를 선택했는지 확인한 다음 Config에서 활성화된 파일을 점검합니다. 요청을 새로 보낸 뒤 기록을 확인하세요. 실제 요청에서 다른 호스트 이름을 사용한다면 같은 규칙을 반복해서 추가하지 말고 기록에 나온 이름을 바탕으로 정확한 규칙을 추가하세요.

규칙에 일치한 뒤 정상 이미지까지 사라지면 어떻게 하나요?

먼저 백업을 복원하거나 최근 추가한 차단 행을 제거해 이미지가 다시 표시되는지 확인하세요. 이후 DOMAIN-SUFFIX를 확인된 DOMAIN 규칙으로 범위를 좁힙니다. 별도의 정상 호스트가 확인됐다면 정확한 예외 규칙을 차단 행보다 앞에 둡니다. 이미지와 차단하려는 콘텐츠가 같은 호스트를 사용한다면 도메인 규칙만으로는 분리할 수 없습니다.

기존 구독을 업데이트했는데 규칙이 바뀌지 않는 이유는 무엇인가요?

먼저 업데이트한 대상이 Home의 노드 구독인지 Config의 원격 설정인지 구분하세요. 전자는 규칙 업데이트와 같지 않으며, 후자는 로컬 편집 내용을 덮어쓸 수 있습니다. Config에서 실제 파일의 [Rule] 내용을 확인하고 직접 관리하는 규칙과 원본 설정을 각각 백업한 뒤 업데이트 후 항목별로 다시 점검하세요.

FINAL을 REJECT로 바꾸면 규칙을 하나씩 추가하지 않아도 되나요?

FINAL,REJECT는 앞선 규칙에 일치하지 않은 모든 연결을 거부하므로 도메인 하나를 차단하는 것보다 훨씬 범위가 넓습니다. 명확한 허용 목록을 관리하는 경우가 아니라면 이를 개별 차단 규칙 대신 사용하지 마세요. 먼저 FINAL의 기존 정책을 복원한 뒤 범위가 명확한 DOMAIN 또는 DOMAIN-SUFFIX 규칙을 추가하세요.

7. 저장 전 최소 점검 목록

관리하기 쉬운 REJECT 설정이라면 “어떤 대상을 거부하는지, 왜 이 매칭 방식을 선택했는지, 예외는 어디에 있는지, 어떻게 복구할 수 있는지”를 설명할 수 있어야 합니다. 확인되지 않은 규칙을 한꺼번에 많이 가져오기보다 매번 매칭 조건 하나만 바꾸고 변경 전후 기록을 남기면 문제 원인을 찾기 쉽습니다.

실제로 활성화된 설정의 [Rule] 안에 규칙이 있으며, 도메인 항목에 프로토콜이나 경로가 들어 있지 않습니다.
정확한 예외 규칙은 해당 차단 규칙보다 앞에 있고, 차단 규칙은 먼저 일치할 수 있는 광범위한 규칙보다 앞에 있습니다.
FINAL은 기존 기본 처리 용도를 유지하며 차단 규칙을 추가했다는 이유로 임의 변경하지 않습니다.
Home → Global Routing에서 Config를 선택했으며 새 연결 기록으로 실제 규칙 일치 결과를 확인했습니다.
로그인, 이미지와 그 밖의 필수 기능을 확인했고 복구할 수 있는 원본 설정을 보관했습니다.