Shadowrocket REJECT 규칙 설정 방법: 차단 원리와 적용 범위

1. REJECT의 작동 위치: 연결을 거부할 뿐 페이지를 편집하지 않습니다

Shadowrocket의 규칙은 매칭 조건과 대상 정책으로 구성됩니다. REJECT는 정책 위치에 지정해 일치한 요청을 거부합니다. 프로토콜이 아니며 별도의 서버를 추가해야 하는 것도 아닙니다. 규칙이 적용되려면 해당 트래픽이 Shadowrocket의 처리 경로를 거치고 현재 구성의 규칙에 따라 판정되어야 합니다.

도메인 규칙은 대상 도메인을 기준으로 판단하며, 웹페이지의 문구나 이미지 내용, 버튼 위치를 구분하지 않습니다. 페이지에서 통계 리소스를 별도의 도메인으로 불러온다면 해당 도메인을 거부해 리소스 요청을 막을 수 있습니다. 반면 본문과 로그인, 이미지가 같은 도메인에 의존한다면 해당 도메인을 거부했을 때 이 기능들이 함께 중단될 수도 있습니다. 규칙이 응답 중 어떤 콘텐츠가 사용자에게 필요한지 자동으로 구분하지는 않습니다.

요청이 거부된 뒤 어떻게 보이는지는 요청을 보낸 앱에 따라 달라집니다. 빈 영역이나 로딩 실패, 재시도 안내가 표시될 수도 있고 기존 콘텐츠가 남을 수도 있습니다. 페이지가 계속 표시된다는 이유만으로 규칙이 적용되지 않았다고 단정할 수 없으며, 로딩 실패를 곧바로 REJECT 탓으로 돌릴 수도 없습니다. 네트워크 연결 중단, DNS 이상, 서버 오류도 비슷한 현상을 일으킬 수 있습니다.

2. 기본 문법: DOMAIN부터 적용하고 범위는 필요할 때 넓히기

일반 도메인 규칙은 ‘규칙 키워드, 매칭 대상, 정책’ 순서로 작성하며 각 항목은 영문 쉼표로 구분합니다. 아래는 문법을 설명하기 위한 독립 예시입니다. 첫 번째 규칙은 지정한 호스트만 거부하고, 두 번째 규칙은 지정한 접미사와 하위 도메인을 거부하며, 마지막 규칙은 나머지 요청을 직접 연결합니다. 실제로는 필요한 규칙을 기존 구성에 추가하세요. 이 예시로 기존 라우팅 설정 전체를 대체해서는 안 됩니다.

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

DOMAIN 또는 DOMAIN-SUFFIX의 매칭 대상에는 https://, 포트, 경로, 쿼리 매개변수를 입력하지 마세요. https://example.com/banner?id=1은 URL이지 도메인이 아닙니다. 전체 URL을 도메인 규칙에 넣어도 경로별 차단 기능을 사용할 수는 없습니다.

3. 규칙 순서와 Global Routing: 규칙을 올바르게 작성해도 사용 중이 아닐 수 있습니다

Home에서 Global Routing을 확인하세요. 로컬 구성에 설정한 일반 라우팅 규칙을 확인하려면 Config를 선택해야 합니다. Proxy와 Direct는 전체 라우팅 모드이므로, 이를 사용한 결과로 Config의 REJECT 규칙이 작동한다고 판단할 수 없습니다. Scene은 실제 설정을 함께 확인해야 하며 Config와 같은 의미로 볼 수 없습니다. 그런 다음 Config에서 방금 수정한 구성이 선택되어 활성화되어 있는지 확인하세요.

1. Config에서 현재 구성의 사본을 저장한 뒤 수정할 로컬 구성을 여세요.
2. [Rule] 안에 범위가 명확한 REJECT 규칙을 추가하세요. 이름이 같은 섹션을 여러 개 만들지 마세요.
3. 예외 규칙은 이를 덮어쓸 수 있는 광범위한 규칙보다 앞에 두고, FINAL은 규칙의 마지막에 유지하세요.
4. 저장한 뒤 수정된 구성이 현재 사용 중인지 확인하고 Home으로 돌아가 Global Routing이 Config인지 확인하세요.
5. 대상 요청을 다시 발생시킨 뒤 요청 기록에서 대상, 정책, 적용된 규칙을 확인하세요.

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

이 예시는 먼저 account.example.com에 DIRECT 예외를 설정한 뒤, example.com 접미사에 일치하는 나머지 요청을 거부합니다. 일반 규칙은 위에서 아래로 평가되며 처음 일치한 규칙의 정책이 적용됩니다. 광범위한 접미사 규칙을 앞에 두면 이미 내려진 판단을 뒤의 예외 규칙으로 되돌릴 수 없습니다.

4. DOMAIN-SUFFIX와 URL Rewrite의 적용 범위

DOMAIN-SUFFIX는 HTTP 경로를 확인하지 않습니다. 같은 호스트에서 /article/과 /banner/를 모두 제공한다고 가정해도, 도메인 규칙으로 후자만 차단할 수는 없습니다. URL Rewrite는 확인할 수 있는 HTTP 요청 URL을 대상으로 하며 지원되는 매칭 및 처리 방식에 따라 작동합니다. 그렇다고 모든 HTTPS 경로를 바로 읽을 수 있는 것은 아닙니다.

HTTPS의 경로와 쿼리 매개변수는 TLS로 보호됩니다. 이 내용을 확인하려면 일반적으로 해당 호스트에 맞는 HTTPS 복호화 설정과 인증서 설치 및 신뢰 설정이 필요합니다. URL Rewrite 규칙 하나만 추가한다고 이런 조건이 자동으로 갖춰지지는 않습니다. 일부 앱은 인증서 고정 등의 방식을 사용하므로 이러한 처리를 허용하지 않을 수 있습니다. HTTP/3 등 전송 방식의 지원 여부도 별도로 확인해야 하며, 포트만으로 수정 가능 여부를 추측할 수 없습니다.

인증서와 HTTPS 복호화는 신뢰 경계에 영향을 줍니다. 차단 규칙 하나를 시험하기 위해 모든 호스트로 범위를 넓혀서는 안 됩니다. 이 글에서는 모든 호스트에 적용하는 복호화 구성을 안내하지 않습니다. 적용 범위를 확인할 수 없다면 정확한 도메인 규칙을 유지하거나 대상 앱에서 제공하는 콘텐츠 설정을 사용하세요.

5. IP-CIDR와 GEOIP: 주소 매칭은 콘텐츠 분류가 아닙니다

대상에 IP 주소를 직접 사용하거나 여러 서비스가 공유하는 콘텐츠 전송 인프라를 사용할 수 있습니다. 이때 ‘도메인 규칙에 매칭할 호스트 이름이 없음’과 ‘IP 규칙 범위가 너무 넓음’은 서로 다른 문제입니다. GEOIP는 주소가 속한 지역을 판단하고, IP-CIDR은 주소가 지정된 네트워크 대역에 포함되는지 판단합니다. 둘 다 응답이 광고인지 통계 데이터인지 구분하지 못합니다.

[Rule]
IP-CIDR,192.0.2.0/24,REJECT,no-resolve
FINAL,DIRECT

192.0.2.0/24는 문서용 예시 네트워크 대역이며 실제 차단 대상으로 권장하는 주소가 아닙니다. no-resolve는 이 IP 규칙을 위해 도메인 조회를 능동적으로 시작하지 않는다는 뜻입니다. 사용 가능한 대상 주소가 이미 있으면 주소를 기준으로 매칭될 수 있습니다. 모든 DNS를 비활성화한다거나 IP 규칙을 도메인 규칙처럼 사용할 수 있다는 뜻은 아닙니다.

• 하나의 IP를 여러 도메인이 공유할 수 있으므로 이를 거부하면 정상 이미지, 로그인 API 또는 다른 웹사이트에도 영향을 줄 수 있습니다.
• 하나의 도메인이 여러 IPv4 및 IPv6 주소에 연결될 수 있습니다. IPv4 주소 하나만 처리해도 해당 도메인을 모두 차단하는 것은 아닙니다.
• GEOIP의 지역 정보는 콘텐츠의 용도를 나타내지 않으므로 ‘이 유형의 콘텐츠는 전부 필요 없다’는 판단을 대신하는 태그로 적합하지 않습니다.
• DNS, 캐시, 연결 재사용은 관찰 결과에 영향을 줍니다. 한 번의 조회 결과만 보지 말고 새 요청 기록과 함께 확인하세요.

6. 확인과 되돌리기: 요청 기록으로 재현 가능한 판단하기

테스트에서는 한 번에 조건 하나만 변경하세요. 먼저 규칙을 수정하기 전 페이지 상태를 기록한 다음 규칙 하나를 추가하고 대상 페이지를 다시 열거나 해당 작업을 다시 실행하세요. 앱이 기존 연결을 재사용하면 새 규칙이 기존 연결에 반영되지 않을 수 있습니다. 콘텐츠가 캐시된 경우 새 요청이 아예 발생하지 않을 수도 있습니다. 필요하면 대상 앱을 종료한 뒤 다시 열고, 새로 생성된 요청 기록을 기준으로 판단하세요.

1. 대상 확인: 실제 요청 호스트를 확인하세요. 리디렉션 후에는 호스트가 바뀔 수 있으므로 브라우저 주소창의 주소만 그대로 사용하지 마세요.
2. 트래픽 처리 확인: 연결 상태와 Global Routing을 확인해 테스트 요청이 현재 Config의 처리 경로를 거치는지 살펴보세요.
3. 규칙 적용 확인: 새 요청에 REJECT가 적용됐는지 확인하세요. 적용되지 않았다면 먼저 규칙 순서, 도메인 철자, 현재 구성을 확인하세요.
4. 영향 확인: 대상 영역이 사라졌는지만 보지 말고 로그인, 이미지, 재생, 결제 등 정상 기능도 점검하세요.
5. 되돌리기 확인: 방금 추가한 규칙을 삭제하거나 비활성화한 뒤 요청을 다시 보내세요. 문제가 해결되면 매칭 범위를 더 좁히세요.

콘텐츠 요청 확인을 한 번의 지연 시간 테스트로 대신하지 마세요. 연결 테스트 성공은 해당 테스트 대상에서 연결 결과가 확인됐다는 뜻일 뿐입니다. 대상 도메인이 REJECT에 일치했다는 증거도, 특정 페이지 경로가 처리됐다는 증거도 아닙니다. 문제 해결 기록을 정리할 때는 대상 호스트, 적용된 정책, 작업 순서만 남기세요. 공유 전에 구독 주소, 토큰과 기타 인증 정보를 삭제하세요.

7. 자주 묻는 질문: 규칙이 적용된 뒤에도 콘텐츠가 보이는 경우

최종적으로 유지할 규칙은 세 가지 조건을 충족해야 합니다. 대상이 명확하고, 요청 기록으로 적용 여부를 확인할 수 있으며, 정상 기능을 복구할 수 있어야 합니다. 규칙 수가 많다고 매칭이 더 정확해지는 것은 아닙니다. 따로 구분할 수 없는 콘텐츠라면 추측에 기반한 접미사 규칙을 늘리기보다 범위 확장을 멈추는 편이 관리하기 쉽습니다.