Shadowrocket의 REJECT는 요청의 라우팅 정책이지, 웹페이지 요소를 걸러내는 기능이 아닙니다. 사용할 수 있는 구성이 이미 있고 규칙을 직접 관리하려는 사용자를 대상으로 합니다. 먼저 Global Routing이 Config로 설정되어 있는지 확인하고, 필요한 범위만 최소화해 차단 규칙을 적용한 뒤 연결 기록으로 매칭 결과를 확인하세요. 오차단이 발생하면 이번에 변경한 규칙만 되돌리면 됩니다. 예시의 도메인과 주소는 문법 설명용이며 차단 목록이 아닙니다.
1. 규칙 매칭에서 REJECT가 하는 일
요청이 Shadowrocket의 규칙 처리 과정에 들어와 REJECT 정책이 지정된 규칙과 매칭되면 요청이 거부되며, 프록시나 직접 연결로 대상에 접속하지 않습니다. 앱에서는 리소스 로드 실패, 연결 오류 또는 반복 재시도로 나타날 수 있으며, 구체적인 표시는 요청을 보낸 앱에 따라 다릅니다. 페이지가 비어 있다는 이유만으로 REJECT가 적용됐다고 단정할 수는 없습니다.
규칙은 일반적으로 구성에 적힌 순서대로 매칭됩니다. 적용 가능한 규칙이 정책을 결정하면 뒤에 있는 규칙은 해당 요청의 결과를 바꾸지 않습니다. 따라서 규칙을 작성했다는 것과 요청에 그 규칙이 적용됐다는 것은 별개의 문제입니다. 앞쪽의 광범위한 허용 규칙, 실제로 적용 중인 구성 파일, 현재 라우팅 모드가 모두 최종 결과에 영향을 줍니다.
- DOMAIN: 지정한 전체 도메인과 매칭합니다. 먼저 범위를 좁혀 확인할 때 적합합니다.
- DOMAIN-SUFFIX: 지정한 도메인과 하위 도메인까지 매칭하며, 단일 전체 도메인보다 범위가 넓습니다.
- IP-CIDR: IPv4 주소 또는 주소 대역과 매칭합니다. 웹페이지 경로나 페이지 요소를 나타내지는 않습니다.
- FINAL: 최종 기본 규칙으로 사용하며 규칙 맨 끝에 둡니다. 정책은 기존 구성의 설계를 따르세요.
예를 들어 같은 도메인에서 본문, 이미지, 통계 요청이 같은 연결 대상을 사용할 수 있습니다. 도메인 규칙만으로는 각 요청의 용도를 구별할 수 없습니다. 도메인 전체를 REJECT로 설정하면 페이지에 필요한 리소스까지 차단될 수 있습니다.
2. Config 및 Global Routing 먼저 확인하기
작업 전에 현재 구성의 사본을 보관하세요. Config(구성)에서 현재 선택된 파일을 확인하고 해당 파일의 편집 화면으로 이동해 규칙 섹션을 점검합니다. 편집 화면의 구체적인 표시 방식은 현재 앱에서 확인하세요. 활성화되지 않은 파일만 수정한 뒤 웹페이지 표시만 보고 규칙이 올바르게 작동한다고 판단하지 마세요.
| 화면 항목 | 의미 및 기본 상태 | 이 글의 테스트 권장 사항 |
|---|---|---|
| Home → Global Routing → Config | 현재 구성에 따라 라우팅합니다. 기본 선택 항목은 현재 앱에 표시되는 내용을 기준으로 확인하세요. | Config를 사용해 구성에 있는 REJECT 규칙을 확인합니다. |
| Global Routing → Proxy | 전역 프록시 모드입니다. 이 글의 규칙 테스트를 위한 기본 설정이 아닙니다. | 테스트 전에 Config로 전환하세요. 이 모드로 규칙 섹션의 매칭 여부를 판단하지 마세요. |
| Global Routing → Direct | 전역 직접 연결 모드입니다. 이 글의 규칙 테스트를 위한 기본 설정이 아닙니다. | 테스트 전에 Config로 전환하세요. |
| Global Routing → Scene | 설정한 Scene에 따라 해당 라우팅 동작을 사용합니다. 실제 결과는 Scene 설정에 따라 달라집니다. | 현재 상태를 먼저 기록하고 테스트할 때는 Config를 사용하세요. 완료 후 필요하면 원래 상태로 되돌립니다. |
| Settings → On Demand | 필요 시 연결 설정입니다. 기본 스위치 상태와 조건은 현재 앱에 표시되는 내용을 기준으로 확인하세요. | 자동 연결 조건이 재현에 영향을 주지 않도록 테스트 중에는 연결 상태가 확인된 상태로 유지하세요. |
- 현재 선택된 구성, Global Routing 상태, 대상 앱의 정상 동작을 기록합니다.
- Config에서 사본을 보관한 다음 실제 적용 중인 파일의 규칙 섹션을 수정합니다.
- Home으로 돌아가 연결이 켜져 있는지 확인하고 Global Routing을 Config로 설정합니다.
- 저장 후 수정 사항이 적용됐는지 확인한 다음 대상 앱에서 새 요청을 한 번 보냅니다.
Home에 있는 연결 항목과 Config의 규칙 파일은 서로 다른 설정 영역입니다. 연결 구독을 업데이트해도 방금 편집한 규칙이 반드시 적용되는 것은 아닙니다. 구성 자체가 원격으로 업데이트되는 경우에는 업데이트 후에도 로컬 수정 사항이 남아 있는지 확인하세요.
3. DOMAIN-SUFFIX 및 IP-CIDR 올바르게 작성하기
텍스트 규칙의 필드는 영문 쉼표로 구분하며, 한국어 쉼표는 사용하지 않습니다. 아래는 각각 독립된 문법 예시 네 개이며, 통째로 교체해 사용할 수 있는 완성된 구성은 아닙니다. 도메인은 예시용 예약 도메인을 사용하며 192.0.2.0/24는 문서 예시용 주소 대역입니다. 실제로 차단해야 하는 대상과는 관계가 없습니다.
DOMAIN,metrics.example.com,REJECT
DOMAIN-SUFFIX,example.com,REJECT
IP-CIDR,192.0.2.18/32,REJECT,no-resolve
IP-CIDR,192.0.2.0/24,REJECT,no-resolve도메인 규칙 필드
- 규칙 유형
- DOMAIN 또는 DOMAIN-SUFFIX
- 매칭 값
- metrics.example.com 또는 example.com
- 대상 정책
- REJECT, 매칭된 요청 거부
- 기본값 및 권장 사항
- 매칭 값에는 공통 기본값이 없습니다. 먼저 DOMAIN으로 확인하는 것을 권장합니다.
도메인 필드에는 호스트 이름만 입력하고 https://, 경로, 포트는 입력하지 않습니다.
주소 규칙 필드
- 규칙 유형
- IP-CIDR, IPv4 주소 범위와 매칭
- 매칭 값
- 192.0.2.18/32, 단일 주소를 나타냅니다
- 대상 정책
- REJECT, 매칭된 요청 거부
- 선택적 매개변수
- no-resolve, 이 IP 규칙의 매칭을 위해 도메인을 능동적으로 조회하지 않도록 합니다
- 기본값 및 권장 사항
- 주소 범위에는 공통 기본값이 없습니다. 먼저 단일 주소를 확인한 뒤 필요할 때 주소 대역을 검토하세요.
no-resolve는 전역 DNS를 끄거나 모든 DNS 조회를 거부하는 스위치가 아닙니다.
DOMAIN-SUFFIX,example.com,REJECT는 example.com과 img.example.com 같은 하위 도메인에 매칭됩니다. 문자열이 포함된 모든 도메인과 매칭된다는 뜻은 아닙니다. metrics.example.com만 차단하려는 경우 먼저 DOMAIN을 사용하고 최상위 도메인 전체로 범위를 넓히지 마세요.
요점: 단일 도메인이나 단일 주소부터 시작하세요
DOMAIN 또는 /32로 대상을 지정할 수 있다면 도메인 접미사나 전체 주소 대역으로 범위를 넓히지 마세요. 연결 기록으로 대상 범위를 넓힐 필요가 확인된 경우에만 매칭 범위를 확장하세요.
4. 규칙 순서, 예외 및 FINAL 기본 규칙
특정 하위 도메인을 유지해야 한다면 예외 규칙을 광범위한 거부 규칙보다 앞에 두세요. 아래는 순서만 보여 주는 예시입니다. account.example.com은 직접 연결하고 나머지 example.com 요청은 거부한 뒤, 매칭되지 않은 요청은 직접 연결합니다. 여기서 DIRECT는 설명을 위한 명시적 선택이며, 모든 사용자가 기본 규칙을 직접 연결로 바꿔야 한다는 뜻은 아닙니다.
[Rule]
DOMAIN,account.example.com,DIRECT
DOMAIN-SUFFIX,example.com,REJECT
FINAL,DIRECT실제 사용 시에는 기존 구성에 필요한 정책을 유지하세요. 예외 도메인에 프록시 연결이 필요하다면 DIRECT를 그대로 복사하지 말고 구성에 이미 있는 올바른 정책을 사용하세요. 또한 두 번째 [Rule] 섹션을 파일 맨 끝에 그대로 추가하지 마세요. 기존 규칙 섹션을 편집하고 최종 순서를 확인해야 합니다.
- 거부 규칙을 FINAL 뒤에 배치: 앞의 기본 규칙이 이미 요청을 처리하므로 뒤에 있는 거부 규칙은 의도한 대로 적용되지 않습니다.
- 광범위한 허용 규칙이 앞에 있음: 대상이 앞쪽의 다른 DOMAIN-SUFFIX, IP-CIDR 또는 GEOIP 규칙과 먼저 매칭되면 뒤의 REJECT는 적용되지 않습니다.
- 예외를 거부 규칙 뒤에 배치: 대상이 이미 거부된 뒤라면 뒤에 있는 허용 예외로 되돌릴 수 없습니다.
- FINAL을 REJECT로 설정: 매칭되지 않은 모든 요청이 거부됩니다. 이는 기본 거부 구성에 해당하며 특정 대상만 차단하는 일반적인 방법은 아닙니다.
GEOIP는 IP 주소의 지역 정보를 바탕으로 매칭하며, 특정 웹사이트를 차단해야 하는지 분류하는 기능은 아닙니다. 도메인 하나를 처리하려고 광범위한 GEOIP 정책을 바꾸면 불필요한 영향이 생길 수 있습니다. 대상과 직접 관련된 규칙을 우선 이동하거나 범위를 좁히세요.
5. 규칙 차단으로 처리할 수 없는 상황
REJECT는 연결 대상을 기준으로 결정하며 페이지 레이아웃을 분석하지 않습니다. HTTPS 요청의 웹 경로, 매개변수, 본문은 DOMAIN-SUFFIX의 매칭 값으로 직접 사용할 수 없습니다. 같은 도메인에 여러 콘텐츠가 섞여 있거나 콘텐츠가 캐시된 경우, 또는 인프라를 공유하는 경우에는 먼저 차단 범위를 확인한 다음 거부 정책을 사용할지 결정하세요.
| 상황 | 나타날 수 있는 현상 | 권장 조치 |
|---|---|---|
| 하나의 도메인에서 서로 다른 콘텐츠 제공 | 대상을 차단했더니 본문, 로그인 또는 이미지에도 영향이 생깁니다. | 별도의 하위 도메인이 있는지 확인하세요. 구분할 수 없다면 필요한 기능은 유지하세요. |
| 여러 사이트가 같은 주소를 공유 | IP-CIDR로 거부하면 다른 도메인도 연결되지 않습니다. | 공유 주소 대역을 직접 차단하지 말고 도메인 규칙을 우선 사용하세요. |
| 페이지 콘텐츠가 캐시됨 | 규칙이 적용된 뒤에도 이전 콘텐츠가 계속 보입니다. | 새 요청을 보내고 연결 기록으로 확인하세요. 이미 열린 페이지의 표시만 확인하지 마세요. |
| 대상이 IPv4와 IPv6를 함께 사용 | IPv4 규칙만 설정하면 다른 주소로 연결이 계속될 수 있습니다. | 실제 대상 주소를 확인하세요. IP-CIDR은 IPv6를 포함하지 않으므로 관련 문법은 별도로 확인해야 합니다. |
| 앱이 자동으로 재시도하거나 도메인을 전환 | 한 대상이 거부된 뒤에도 새로운 대상이 계속 나타납니다. | 각 요청의 용도를 하나씩 확인하세요. 재시도가 있다는 이유로 전체 주소 대역을 거부하지 마세요. |
연결이 이미 성립된 경우 이후 페이지 동작에 새 규칙이 즉시 반영되지 않을 수 있습니다. 규칙 테스트는 수정한 뒤 새로 생성된 연결을 대상으로 해야 합니다. 대상 페이지를 닫았다가 다시 열고, 필요한 경우 대상 앱을 종료한 뒤 재시도하세요. 기존 연결이 재사용될 수도 있으므로 이전 연결의 전송을 새 규칙이 적용되지 않은 증거로 오해하지 않도록 주의하세요.
6. 연결 기록으로 미적용 및 오차단 문제 확인하기
문제를 확인할 때는 한 번에 한 항목만 변경하세요. 먼저 실패한 요청을 재현한 다음 앱의 연결 기록과 Log(로그)를 확인합니다. 관련 메뉴와 표시되는 필드는 현재 앱에서 확인하세요. 대상 도메인 또는 IP, 요청 시각, 최종 정책, 확인 가능한 매칭 규칙을 중점적으로 기록합니다. 기록을 공유하기 전에 구독 주소, 토큰 및 계정 정보를 가리세요.
- 요청이 처리 범위에 들어왔는지 확인: Home의 연결 상태와 Global Routing을 점검하세요. 기록에 새 요청이 없다면 먼저 연결 상태, 캐시, 대상에서 실제로 요청을 보냈는지 확인하세요.
- 대상 확인: 페이지에 표시된 사이트 이름이 실패한 리소스의 도메인과 일치하지 않을 수 있습니다. 해당 시각의 연결 기록을 바탕으로 실제 호스트 이름과 주소를 확인하세요.
- 적용 중인 파일 확인: Config로 돌아가 현재 구성을 편집했는지 확인하고, 저장 및 로드 후에도 규칙이 남아 있는지 확인하세요.
- 순서 확인: 위에서 아래로 살펴보며 먼저 매칭될 수 있는 허용 규칙과 FINAL의 위치를 확인하세요.
- 이번 수정 되돌리기: 새로 추가한 REJECT만 제거한 뒤 같은 작업을 다시 재현하세요. 기능이 복구되면 이번 규칙을 중점적으로 확인할 필요가 있지만, 실제 의존 관계는 기록을 함께 살펴봐야 합니다.
- 범위를 좁혀 다시 테스트: 접미사 규칙을 단일 도메인으로 바꾸거나 주소 대역을 단일 주소로 줄이세요. 로그인, 이미지, 검색, 재생 등 실제 영향을 받는 기능을 각각 테스트합니다.
규칙을 저장했는데도 대상에 접속할 수 있는 이유는 무엇인가요?
먼저 Home → Global Routing에서 Config를 선택한 다음 Config의 현재 파일을 확인하세요. 새 요청을 보내 대상이 규칙과 일치하는지, 규칙이 FINAL 앞에 있는지 확인합니다. 캐시된 페이지는 규칙 매칭의 증거가 될 수 없습니다.
DOMAIN-SUFFIX를 추가한 뒤 로그인이 실패하면 어떻게 수정해야 하나요?
먼저 새 규칙을 되돌리고 로그인 동작을 다시 확인하세요. 실패 시점의 연결 기록에서 필요한 도메인을 확인한 다음 거부 범위를 실제 대상까지 좁힙니다. 예외를 유지해야 한다면 거부 규칙 앞에 두고 해당 도메인에 원래 필요한 라우팅 정책을 사용하세요.
no-resolve를 추가하면 DNS 요청이 발생하지 않나요?
아닙니다. 이 옵션은 해당 IP 규칙을 매칭하기 위해 능동적으로 조회하는 동작을 제한할 뿐, 다른 DNS 동작을 비활성화하지 않습니다. 도메인 기준으로 거부하려면 먼저 DOMAIN 또는 DOMAIN-SUFFIX를 사용하세요. 이 옵션을 도메인 규칙 대신 사용하지 마세요.
구성을 업데이트한 뒤 차단 규칙이 사라졌습니다. 구독을 다시 가져와야 하나요?
먼저 Config에서 적용 중인 파일의 규칙 섹션에 로컬 수정 사항이 남아 있는지 확인하세요. 원격 구성 업데이트로 파일 내용이 대체될 수 있습니다. 사본을 보관하고 업데이트 전후의 차이를 확인한 뒤 필요한 규칙을 복원하세요. 연결 구독을 다시 가져오는 것으로 이 과정을 대신할 수는 없습니다.
검증을 마친 뒤에는 최소한의 수정 사항과 용도를 기록해 두세요. 임시 문제 해결에 사용한 전역 모드, 전체 주소 대역 거부, 광범위한 접미사 규칙을 장기 구성에 남겨 두지 마세요. 같은 문제가 다시 발생했을 때 출처를 알 수 없는 대규모 목록보다 규칙 하나를 정확히 되돌리는 편이 원인을 찾기 쉽습니다.