Shadowrocket REJECT 규칙 사용법: 차단 가능한 요청과 한계

1. 규칙 체인에서 REJECT의 위치

구성에 따라 라우팅하는 경우 Shadowrocket은 연결에서 확인할 수 있는 정보를 바탕으로 규칙을 검사합니다. 매칭 조건과 실행 정책은 별개입니다. DOMAIN, DOMAIN-SUFFIX, IP-CIDR 등은 일치 여부를 결정하고, 마지막의 REJECT는 일치한 요청을 거부합니다. REJECT는 프로토콜이 아니며, 실행을 위해 별도의 프록시 경로를 선택할 필요도 없습니다.

여기서는 REJECT 규칙이 일치한 경우를 설명합니다. DIRECT가 일치하면 연결은 직접 연결되고, 구성에서 유효한 프록시 정책이 일치하면 해당 아웃바운드로 연결됩니다. 규칙은 위에서 아래로 검사되며, 일치하는 즉시 해당 정책이 적용됩니다. 더 아래에서 더 적합한 결과를 찾지는 않습니다. 따라서 문제를 확인할 때는 REJECT가 있는지만 볼 것이 아니라, 앞선 규칙이 요청을 먼저 처리하지 않았는지도 확인해야 합니다.

• 먼저 라우팅 모드를 확인하세요: Home에서 Global Routing → Config를 확인해 이번 테스트에 현재 구성의 규칙이 적용되도록 하세요. Proxy나 Direct의 전역 테스트 결과로 Config 규칙이 올바른지 판단하지 마세요.
• 다음으로 구성을 확인하세요: Config에서 현재 활성화된 구성 파일을 확인하세요. 활성화되지 않은 다른 파일을 편집해도 사용 중인 규칙은 바뀌지 않습니다.
• 마지막으로 새 연결을 확인하세요: 이미 연결된 세션은 계속 재사용될 수 있습니다. 수정 후 연결을 새로 만든 다음 대상 페이지를 다시 열어 보세요. 기존 페이지에서 새로고침만 하는 것보다 결과를 판단하기 쉽습니다.

2. 정확한 도메인부터 규칙 작성하기

먼저 DOMAIN으로 호스트 이름 하나를 지정하고, 범위를 넓힐 필요가 있을 때 DOMAIN-SUFFIX를 사용하세요. 예를 들어 metrics.example.com만 거부하려는 경우 정확한 도메인 규칙은 www.example.com까지 거부하지 않습니다. 반면 DOMAIN-SUFFIX,example.com,REJECT는 루트 도메인과 하위 도메인 전체에 적용되어 로그인, 이미지, API까지 차단할 수 있습니다. 아래 도메인은 문법을 설명하기 위한 예시이며 실제 차단 대상을 뜻하지 않습니다.

[Rule]
DOMAIN,metrics.example.com,REJECT
DOMAIN-SUFFIX,blocked.example.org,REJECT
FINAL,DIRECT

이 내용은 규칙 구조의 예시이며 기존 파일을 대체할 완성된 구성은 아닙니다. 필요한 규칙을 기존 [Rule] 섹션에 추가하고, 같은 섹션을 중복해서 만들지 마세요. 기존 구성에 필요한 다른 규칙과 기본 처리 정책도 유지하세요. 예시의 FINAL,DIRECT는 마지막에 배치하는 모습을 보여 줄 뿐, 모든 사용자가 자신의 FINAL을 DIRECT로 바꿔야 한다는 뜻은 아닙니다.

전체 URL을 DOMAIN 조건에 넣지 마세요. 페이지 주소의 /banner/image는 경로이지 도메인의 일부가 아닙니다. :443은 포트이며 호스트 이름에 포함되지 않습니다. 이런 도메인 규칙을 사용하면 같은 호스트에서 HTTPS 443과 HTTP 80 서비스를 모두 제공하는 경우에도 DOMAIN 조건만으로 둘 중 한 포트만 구분할 수 없습니다.

3. 규칙 순서로 ‘작성했는데도 차단되지 않는’ 원인 찾기

규칙은 ‘더 구체적인 규칙이 우선’하도록 자동으로 재정렬되지 않습니다. 예를 들어 구성에 DOMAIN-SUFFIX,example.com,DIRECT가 먼저 있고 그 아래에 DOMAIN,metrics.example.com,REJECT가 있으면 해당 하위 도메인에 접속할 때 앞의 DIRECT 규칙이 먼저 일치합니다. 뒤의 정확한 규칙은 범위가 더 좁아도 실행되지 않습니다.

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

위 예시는 명확한 차단 대상을 포괄적인 직접 연결 규칙보다 앞에 둡니다. 특정 하위 도메인은 허용해야 한다면 해당 하위 도메인의 허용 규칙을 관련 도메인 접미사 거부 규칙보다 앞에 배치하세요. 서로 범위가 겹치는 규칙을 여러 개 추가하고 페이지 모양만으로 판단하지 마세요. 대상 연결에 실제로 일치한 규칙과 최종 정책을 먼저 확인하세요.

GEOIP와 IP-CIDR는 대상 IP를 기준으로 하는 매칭 조건이므로, 이미 확인한 정확한 도메인 조건을 대신해서 사용하면 안 됩니다. 여러 웹사이트가 같은 IP를 공유할 수 있어 IP 대역을 거부하면 더 넓은 범위에 영향을 줍니다. 도메인 규칙이 일치하는지는 해당 연결에서 사용할 수 있는 도메인 정보가 있는지에 따라 달라집니다. IP만 확인할 수 있는 연결이 반드시 어떤 DOMAIN 규칙과 일치한다고 볼 수는 없습니다.

4. 같은 도메인의 콘텐츠, 캐시, 페이지 여백에 대한 한계

REJECT는 규칙과 일치하는 연결을 거부할 수 있지만 웹페이지의 특정 영역이 본문인지, 광고인지, 동영상 플레이어인지는 판별하지 않습니다. 예를 들어 같은 www.example.com에서 기사 API와 광고 API를 모두 제공하는 경우 DOMAIN이나 DOMAIN-SUFFIX로 둘 중 하나의 경로만 거부할 수는 없습니다. 도메인 전체를 거부하면 정상 콘텐츠도 영향을 받습니다. ‘같은 도메인의 콘텐츠를 차단할 수 없다’는 것은 이런 도메인 규칙만으로는 각 요청을 골라 구분할 수 없다는 뜻입니다.

HTTPS에서는 경로와 응답 본문이 암호화되므로 일반 도메인 규칙의 매칭 기준이 아닙니다. DOMAIN-SUFFIX 규칙을 더 추가해도 페이지 요소를 식별하는 기능이 생기지는 않습니다. 브라우저 메모리나 로컬 캐시에 리소스가 남아 있다면 새 요청을 거부해도 기존 이미지가 계속 표시될 수 있습니다.

5. 한 번에 하나씩 검증하고 되돌릴 방법 마련하기

테스트 전에 현재 정상적으로 작동하는 구성의 복사본을 저장하고, 추가할 규칙과 기존 순서를 기록하세요. 네트워크 변경, 프록시 전환, 구독 갱신, 여러 차단 규칙 추가를 한꺼번에 진행하지 마세요. 페이지 동작이 바뀌어도 원인을 특정할 수 없습니다. 다음 단계는 연결이 정상적으로 작동하는 상태에서 차단 대상 하나만 검증하는 경우에 적합합니다.

1. 기준 상태 기록: 네트워크와 구성을 그대로 유지한 채 대상 페이지를 열고 로그인 여부, 이미지 로딩, 동영상 재생 등 구체적인 동작을 기록하세요.
2. 대상 확인: 연결 기록에서 관련 요청을 찾아 대상 호스트 이름, 일치한 규칙, 실행 정책을 확인하세요. 페이지 하나가 여러 도메인에 접속할 수 있으므로, 통계 서비스처럼 보이는 도메인이라는 이유만으로 차단해도 된다고 판단하지 마세요.
3. 규칙 하나만 수정: Config에서 현재 활성화된 구성의 [Rule] 섹션에 정확한 DOMAIN 규칙 하나를 추가하세요. 해당 규칙보다 먼저 적용될 수 있는 포괄적인 규칙과 FINAL보다 위에 배치한 다음 저장하고 구성이 적용됐는지 확인하세요.
4. 연결 새로 만들기: 다시 연결한 후 대상 페이지를 다시 여세요. 필요하면 기존 탭을 닫고 새 세션으로 테스트하세요. REJECT가 일치했는지와 로그인, 이미지, 동영상 등의 기능이 영향을 받았는지를 각각 기록하세요.
5. 규칙을 되돌려 비교: 방금 추가한 규칙을 잠시 제거한 뒤 연결을 새로 만들고 다시 테스트하세요. 문제가 규칙을 추가했을 때 발생하고 제거했을 때 사라진다면 우선 해당 규칙으로 인한 오작동으로 판단하세요.
6. 필요한 범위만 유지: 규칙이 제대로 작동하고 필요한 기능에 영향이 없음을 확인한 후에 유지하세요. 더 많은 하위 도메인을 포함해야 한다면 단계적으로 범위를 넓히고, 공유 도메인이나 IP 대역 전체를 바로 거부하지 마세요.

구독의 서버 정보와 현재 Config의 라우팅 규칙은 서로 다른 항목입니다. 구독을 갱신한 뒤 동작이 바뀌었다면 선택된 연결과 현재 구성을 각각 확인하세요. 갱신이 로컬 규칙을 반드시 덮어쓰거나 유지한다고 단정해서는 안 됩니다. 원격 주소에서 구성 파일을 업데이트할 때도 로컬 수정 사항이 남아 있는지 확인하세요. 되돌리기용 복사본은 복원에 사용하고, 차이를 확인하지 않은 채 반복해서 덮어쓰지 마세요.

6. 자주 발생하는 상황과 해결 순서

규칙을 유지하려면 대상에 대한 새 연결이 실제로 REJECT와 일치하고, 필요한 기능은 계속 사용할 수 있으며, 규칙을 되돌렸을 때 원래 동작을 복구할 수 있어야 합니다. REJECT는 범위가 명확한 요청을 거부하는 데 적합합니다. 페이지 콘텐츠 정리, 응답 내용 필터링, 레이아웃 조정은 이러한 도메인 규칙으로 보장할 수 없습니다. 기본 조작은 사용 설명서에서, 규칙 용어는 용어 설명에서 확인하세요.