REJECT는 요청을 처리하는 정책이지 웹페이지 요소를 필터링하는 기능이 아닙니다. Shadowrocket에서 본인의 구성, 서비스 제공업체 및 구독을 이미 사용 중이며, 차단 규칙을 추가하거나 오차단 문제를 확인하려는 사용자를 위한 안내입니다. 먼저 Global Routing이 Config로 설정되어 있는지 확인한 뒤, 매칭된 규칙과 대상 범위, 대체 처리 방식을 살펴보세요. 글을 다 읽으면 ‘규칙이 매칭되지 않은 경우’, ‘매칭된 요청이 거부된 경우’, ‘규칙으로 처리할 수 없는 페이지 콘텐츠’라는 세 가지 상황을 구분할 수 있습니다.
REJECT가 적용되는 위치
Shadowrocket은 구성에 지정된 규칙에 따라 트래픽을 처리합니다. REJECT는 규칙에 매칭된 요청을 거부한다는 뜻입니다. DIRECT, PROXY와 마찬가지로 규칙 끝에 지정하는 정책이지만 처리 결과는 서로 다릅니다. 규칙은 대상을 선택하고 정책은 대상을 처리하는 방식을 정하므로, 둘을 혼동하지 마세요.
위 과정은 Shadowrocket의 처리 범위에 들어온 요청이 REJECT 규칙에 매칭된 경우만 설명합니다. 앱의 연결 스위치가 켜져 있어도 현재 트래픽이 구성 규칙에 따라 분기된다고 단정할 수는 없습니다. 먼저 Home에서 Global Routing을 확인하세요. 현재 구성에 있는 거부 규칙을 테스트하려면 Config를 선택하고, 편집한 구성이 실제로 선택되어 있는지도 확인해야 합니다.
- Global Routing → Config: 현재 구성의 규칙에 따라 요청을 처리합니다. 이 문서에서 규칙을 확인하기 위한 전제 조건입니다.
- Global Routing → Proxy: 모든 트래픽에 전역 프록시 설정을 적용합니다. 이 상태에서는 구성에 있는 특정 REJECT 규칙의 작동 여부를 확인할 수 없습니다.
- Global Routing → Direct: 모든 트래픽을 직접 연결합니다. 이 상태 역시 구성 규칙이 매칭되었음을 증명하지 못합니다.
- Settings → On Demand: 조건에 따라 자동으로 연결하는 동작을 관리합니다. 어떤 도메인에 REJECT를 적용할지는 여기서 설정하지 않습니다.
Global Routing에서 Scene을 사용한다면 스위치 상태만 보고 규칙 처리 경로를 판단하지 말고, 현재 Scene의 실제 설정도 확인하세요. 문제를 확인할 때는 테스트 조건을 Config로 고정하면 자동 전환이나 다른 연결 방식으로 인한 혼선을 줄일 수 있습니다.
규칙은 요청을 어떻게 선택할까
기본 규칙은 매칭 유형, 매칭 대상, 처리 정책으로 구성됩니다. 예를 들어 DOMAIN-SUFFIX,example.com,REJECT에서 매칭 유형은 DOMAIN-SUFFIX, 대상은 example.com 도메인 접미사, 처리 정책은 REJECT입니다. example.com은 규칙 형식을 설명하기 위한 예시 도메인이며, 실제 차단 대상을 뜻하지 않습니다.
[Rule]
DOMAIN,login.example.com,DIRECT
DOMAIN-SUFFIX,example.com,REJECT
FINAL,PROXY아래 예시는 규칙 순서를 설명하기 위한 것이므로 기존 구성을 통째로 바꾸는 데 사용하면 안 됩니다. 구성 규칙은 순서대로 매칭됩니다. login.example.com으로 확인되는 요청은 앞쪽의 정확한 규칙에 따라 먼저 처리되고, 나머지 example.com 접미사에 해당하는 도메인은 거부됩니다. 앞선 규칙에 처리되지 않은 요청만 FINAL로 넘어갑니다. DIRECT는 예외 처리 방식을 보여주는 예시일 뿐이며, 실제 환경에서는 해당 서비스에서 기존에 사용하던 정책을 유지하세요.
도메인 매칭 범위
- DOMAIN
DOMAIN,ads.example.com,REJECT는 이 도메인과 정확히 일치하는 경우에만 매칭됩니다.- DOMAIN-SUFFIX
DOMAIN-SUFFIX,example.com,REJECT는 루트 도메인과 하위 도메인을 모두 포함합니다.- 매칭되지 않는 이름
notexample.com은 example.com의 하위 도메인이 아닙니다.
대상이 호스트 하나라면 거부 범위가 넓어지지 않도록 먼저 DOMAIN을 사용하세요.
주소와 최종 처리 규칙
- IP-CIDR
IP-CIDR,192.0.2.0/24,REJECT는 대상 IPv4 대역을 기준으로 매칭됩니다.- GEOIP
GEOIP,CN,DIRECT는 IP 주소 위치 데이터베이스를 기준으로 매칭됩니다.- FINAL
FINAL,PROXY는 앞선 규칙에 매칭되지 않은 요청을 처리합니다.
192.0.2.0/24는 문서용 예시 대역입니다. 주소 규칙은 도메인 규칙을 그대로 대신할 수 없습니다.
도메인 규칙은 매칭할 도메인 정보가 있어야 하고, 주소 규칙은 대상 주소를 기준으로 합니다. DNS 조회 과정과 캐시, 앱이 IP 주소를 직접 사용하는지 여부에 따라 관찰되는 정보가 달라질 수 있습니다. 브라우저 주소 표시줄만 보고 관련 연결이 모두 같은 도메인 정보를 가지고 규칙 매칭에 들어간다고 단정할 수 없습니다.
차단할 수 있는 콘텐츠
REJECT가 처리하는 대상은 화면의 특정 영역이 아니라 요청입니다. 한 페이지가 기본 문서, 이미지, 글꼴, 통계 API, 로그인 API를 각각 요청할 수 있습니다. 이 중 독립된 도메인 하나가 정확히 매칭되면 해당 요청을 거부할 수 있습니다. 나머지 페이지가 정상적으로 표시되는지는 그 대상에 대한 의존 여부에 따라 달라집니다.
| 상황 | REJECT의 한계 | 확인할 점 |
|---|---|---|
| 추가 리소스가 별도 도메인을 사용하는 경우 | 해당 도메인으로 보내는 요청은 거부할 수 있지만, 페이지의 빈 영역까지 자동으로 사라지는 것은 아닙니다. | 페이지 이름만 보지 말고 실제 리소스 도메인을 확인하세요. |
| 본문과 추가 콘텐츠가 같은 도메인을 사용하는 경우 | DOMAIN-SUFFIX로는 URL 경로에 따라 두 항목을 구분할 수 없습니다. | 도메인 전체를 거부하면 본문, 이미지 또는 상호작용 기능까지 작동하지 않을 수 있습니다. |
| 콘텐츠가 로컬 캐시에 저장된 경우 | 거부 규칙을 새로 추가해도 앱에 이미 저장된 콘텐츠는 삭제되지 않습니다. | 이전 콘텐츠를 규칙이 작동하지 않는 증거로 오해하지 않도록, 새 요청이 실제로 발생했는지 확인하세요. |
| 콘텐츠가 기본 응답에 직접 포함된 경우 | 도메인 거부 정책으로 응답 내용이나 레이아웃 중 일부만 삭제할 수는 없습니다. | 독립된 네트워크 요청인지, 하나의 응답에 포함된 콘텐츠인지 구분하세요. |
| 대상이 IP 주소를 직접 사용하는 경우 | DOMAIN-SUFFIX에 매칭할 도메인이 반드시 존재한다고 가정할 수 없습니다. | 연결 기록에서 실제 대상 주소와 매칭된 규칙을 확인하세요. |
HTTPS는 주로 TCP 443을, HTTP/3은 주로 UDP 443을 사용하지만 포트 번호만으로 요청의 용도를 알 수는 없습니다. 같은 도메인에서 정상 API와 다른 리소스가 모두 443 포트를 사용할 수 있습니다. DOMAIN-SUFFIX에는 포트 조건이 없으며, 대상 포트가 바뀐다고 해서 다른 용도의 트래픽을 식별하는 규칙으로 바뀌지도 않습니다.
요약: 독립된 대상을 확인한 뒤 거부 규칙을 추가하세요
대상과 정상 기능을 분리할 수 있는지 확인한 뒤 가장 좁은 범위의 DOMAIN 규칙을 추가하세요. 같은 도메인을 공유한다면 경로 이름만 보고 접미사 전체에 REJECT를 적용하지 마세요.
오차단이 발생하는 이유
오차단은 대개 문법 오류가 아니라 예상보다 넓은 매칭 범위 때문에 발생합니다. DOMAIN-SUFFIX,example.com,REJECT를 구성에 추가하면 login.example.com, static.example.com, api.example.com이 모두 대상에 포함됩니다. 로그인 페이지는 열리지만 제출이 안 되거나, 본문은 표시되지만 이미지가 로드되지 않는 문제는 하위 도메인마다 서로 다른 기능을 맡기 때문에 발생할 수 있습니다.
- 루트 도메인의 범위가 너무 넓음: ads.example.com만 거부하려던 규칙을 example.com으로 작성하면 계정, 이미지, API까지 영향을 받습니다.
- 공유 주소 전체를 거부함: 여러 도메인이 같은 호스팅 또는 배포 주소를 사용할 수 있습니다. 한 번 확인한 IP를 IP-CIDR 대역 전체로 확장하면 관계없는 서비스까지 거부될 수 있습니다.
- 정상 기능에 필요한 요청을 추가 리소스로 오인함: CAPTCHA, 계정 확인, 결제 페이지 이동, 미디어 인증은 다른 도메인에 의존할 수 있습니다. 페이지는 그대로 보여도 중요한 기능을 완료하지 못할 수 있습니다.
- 예외 규칙의 순서가 잘못됨: 정확한 허용 규칙이 범위가 넓은 거부 규칙 뒤에 있으면, 앞의 규칙에서 이미 처리 방식이 결정되어 뒤의 예외 규칙으로 되돌릴 수 없습니다.
- 편집한 구성과 실제 적용된 구성이 다름: Config에 있는 파일 하나를 수정했지만 실제로는 다른 구성이 선택되어 있으면 문제를 잘못된 방향으로 조사하게 됩니다.
문제가 ‘가끔 작동하는’ 것처럼 보여도 REJECT가 무작위로 실패한다고 바로 판단하지 마세요. 앱이 기존 연결을 재사용하거나 캐시를 읽을 수 있고, 다른 서비스 도메인으로 전환될 수도 있습니다. 같은 작업을 고정해 요청을 다시 보내고, 해당 시점의 기록에서 대상을 확인하세요. 서로 다른 페이지나 계정 상태에서 얻은 결과를 그대로 비교해서는 안 됩니다.
한 번에 한 가지씩 확인하기
거부 규칙을 테스트하기 전에 복구할 수 있도록 구성을 하나 보관한 다음, 대상 하나만 수정하세요. 정책 전환, DNS 조정, 구독 업데이트와 여러 규칙 추가를 한꺼번에 하지 마세요. 기능이 다시 작동해도 어떤 변경이 영향을 줬는지 알 수 없습니다. 아래 단계에서는 기존 서비스 제공업체를 변경하지 않고 로컬 규칙과 실제 요청만 확인합니다.
- 변경 전 상태 기록: ‘로그인 페이지를 연 뒤 양식 제출’처럼 실패한 작업과 발생 시간을 적어 두세요. 수정 전에는 정상적으로 작동했는지도 확인합니다.
- 연결 방식 고정: Home → Global Routing에서 Config를 선택하고 Config에서 현재 구성을 확인하세요. 테스트 도중 연결이 자동으로 바뀌면 Settings → On Demand의 조건도 확인합니다.
- 같은 작업 재현: 같은 작업을 다시 실행하고 앱에서 확인할 수 있는 연결 기록이나 로그에서 해당 시점의 대상 도메인, IP, 매칭 규칙과 정책을 찾으세요. 기록에 표시된 정보만 적고, 없는 내용을 추측해 보완하지 마세요.
- 규칙 범위 축소: 범위가 넓은 DOMAIN-SUFFIX 규칙에 매칭되었다면 테스트용 복사본에서 먼저 해당 규칙을 제거한 다음, 실제 대상에 따라 DOMAIN으로 바꾸세요. 다른 규칙과 기존 최종 처리 정책은 그대로 유지합니다.
- 적용 후 다시 테스트: 구성을 저장하고 변경 내용이 적용되었는지 확인하세요. 필요하다면 네트워크 작업을 중단해도 되는 시점에 다시 연결한 뒤 같은 작업을 실행해 기존 연결이 재사용되지 않도록 합니다.
- 변경 전후 비교: 규칙을 제거한 뒤 문제가 해결되고 다시 적용했을 때 재발해야 해당 규칙이 원인이라는 근거가 강해집니다. 이런 비교 없이 허용 범위를 계속 넓히지 말고, 다른 규칙과 대상을 확인하세요.
로그에 연결 실패가 표시되어도 REJECT 규칙에 매칭되었다고 입증되는 것은 아닙니다. DNS 조회 실패, 연결 시간 초과, 원격 서버 오류도 ‘열리지 않음’으로 나타날 수 있습니다. 먼저 정책과 규칙 관련 항목을 확인하세요. 기록만으로 판단할 정보가 부족하다면 원인은 확인이 필요하다고 남겨 두어야 합니다. 문제 해결 정보를 공유하기 전에 구독 주소에 포함된 인증 정보, 계정 정보와 불필요한 접속 기록을 가리세요.
요약: 기능을 복구한 다음 규칙 범위를 좁히세요
문제를 일으킨 것이 확인된 거부 규칙 하나를 먼저 되돌리고 기존에 작동하던 정책을 복구한 뒤, 더 정확한 대상을 하나씩 확인하세요. 아직 원인을 찾지 못한 오차단을 감추려고 상위 도메인 전체를 계속 허용하지 마세요.
자주 묻는 질문과 해결 방법
규칙을 추가했는데 페이지 콘텐츠가 그대로 보이는 이유는 무엇인가요?
먼저 Home → Global Routing에서 Config를 선택했는지 확인한 다음, Config에서 현재 파일을 확인하세요. 이어서 페이지를 다시 요청하고 실제 대상을 살펴보세요. 콘텐츠가 캐시, 기본 응답 또는 다른 도메인에서 제공된다면 새로 추가한 DOMAIN-SUFFIX 규칙이 해당 요청을 차단하지 못할 수 있습니다. REJECT는 페이지에 남은 빈 영역을 제거하지도 않습니다.
차단 규칙을 적용하자 로그인이 안 됩니다. 무엇을 허용해야 하나요?
먼저 테스트용 복사본에서 최근 추가한 거부 규칙을 취소하고 로그인을 다시 시도하세요. 문제가 해결되면 기록을 확인해 로그인에 필요한 전체 도메인을 찾고, 범위가 넓은 거부 규칙보다 앞에 DOMAIN 규칙을 추가하세요. 해당 서비스에서 기존에 사용하던 정책을 적용하고, 관련된 상위 도메인을 전부 DIRECT로 바꾸지는 마세요.
도메인 대신 IP-CIDR을 쓰면 더 정확하게 차단할 수 있나요?
항상 그런 것은 아닙니다. 주소가 바뀌거나 여러 서비스가 함께 사용할 수 있습니다. 특정 대상 주소나 대역을 처리해야 한다는 점이 분명할 때만 IP-CIDR을 사용하세요. 한 번 조회된 주소를 해당 서비스만 영구적으로 사용하는 식별자로 간주하지 마세요. 먼저 도메인 단위로 테스트한 뒤 주소 규칙이 영향을 넓히는지 확인하세요.
사용 중인 구독을 업데이트한 뒤 REJECT 규칙을 다시 작성해야 하나요?
먼저 실제로 바뀐 항목이 연결 정보인지 구성 파일인지 확인하세요. 구독을 업데이트했다고 로컬 규칙이 바뀌었다고 단정할 수는 없습니다. 현재 구성도 원격으로 업데이트되었다면 규칙 내용과 순서, 선택 상태를 비교하세요. 변경 내용이 사라졌거나 대상이 바뀐 것을 확인한 경우에만 수정하고, 업데이트할 때마다 같은 규칙을 반복해서 추가하지 마세요.
평소 규칙을 관리할 때는 차단한 전체 대상, 추가한 이유, 되돌리는 방법을 기록해 두세요. 정상 기능에 문제가 생기면 최근 변경 사항부터 확인하고 한 번에 한 가지씩 다시 테스트합니다. 규칙의 개수가 효과를 나타내는 것은 아닙니다. 매칭 결과를 설명할 수 있을 만큼 범위가 명확하고 필요할 때 되돌릴 수 있어야 장기적으로 관리하기 쉽습니다.