이 글의 핵심

연결이 정상적으로 작동하고 Config에 도메인 차단 규칙을 추가하려는 사용자를 위한 안내입니다. 매칭 조건과 REJECT 정책을 구분하고, 정확한 규칙을 순서대로 추가한 뒤 연결 기록을 확인하는 방법을 설명합니다. 같은 도메인의 리소스, 캐시, 앱 내장 콘텐츠가 도메인 규칙의 처리 범위를 벗어나는 경우도 살펴봅니다. 글에 나오는 도메인과 주소는 문법 설명을 위한 예시이며 실제 차단 목록으로 사용할 수 없습니다.

1. REJECT는 매칭 후 적용되는 정책이며 콘텐츠 판별 기능이 아닙니다

Shadowrocket의 규칙은 두 가지를 각각 판단합니다. 연결이 어떤 조건에 해당하는지, 조건에 해당한 연결을 어떻게 처리할지입니다. DOMAIN-SUFFIX, DOMAIN, IP-CIDR는 매칭 조건이고 REJECT는 처리 정책입니다. 도메인을 규칙에 추가해도 웹페이지의 광고, 분석 코드, 동영상 일부를 식별하는 것은 아닙니다. 해당 조건에 맞는 연결을 거부할 뿐입니다.

앱에서 연결 시작 트래픽이 터널로 진입 규칙을 순서대로 확인 거부 정책과 일치 대상 연결 실패

위 흐름은 Shadowrocket을 실제로 거치며 현재 규칙 설정으로 처리되는 트래픽에 해당합니다. 트래픽이 터널을 거치지 않으면 규칙이 개입할 수 없습니다. 터널에 진입하더라도 전체 직접 연결이나 전체 프록시 모드라면 Config 규칙이 적용되는지 판단할 수 없습니다. 문제를 확인할 때는 먼저 Home에서 연결 상태를 확인한 다음 Global Routing을 살펴보세요.

거부된 연결이 어떻게 보이는지는 앱에 따라 다릅니다. 리소스 로드 오류나 빈 자리 표시가 나타날 수도 있고, 반복해서 다시 요청할 수도 있습니다. REJECT는 페이지 레이아웃을 삭제하지 않으며 로딩 속도를 높인다고 보장하지도 않습니다. 원격 콘텐츠를 다른 내용으로 바꾸는 기능도 아닙니다.

2. DOMAIN과 DOMAIN-SUFFIX 작성법 및 적용 범위

도메인 규칙에는 호스트명만 입력합니다. https://, 포트, 경로, 쿼리 매개변수는 넣지 않습니다. 예를 들어 대상 요청이 https://ads.example.com:443/banner?id=1이라면 확인할 호스트명은 ads.example.com입니다. 443은 연결 포트이고 /banner는 경로이므로 둘 다 DOMAIN-SUFFIX의 도메인 매개변수가 아닙니다.

DOMAIN,ads.example.com,REJECT
DOMAIN-SUFFIX,metrics.example.com,REJECT

정확한 호스트 매칭

키워드
DOMAIN
매개변수
ads.example.com
정책
REJECT
매칭 범위
ads.example.com만 해당하며 img.ads.example.com은 포함하지 않음

처음 확인할 때는 영향을 제한하기 쉽도록 정확한 호스트명을 사용하세요.

도메인 접미사 매칭

키워드
DOMAIN-SUFFIX
매개변수
metrics.example.com
정책
REJECT
매칭 범위
metrics.example.com 및 그 하위 도메인

해당 도메인 분기 전체의 용도가 같다는 것을 확인한 뒤 접미사 매칭으로 범위를 넓히세요.

DOMAIN-SUFFIX,example.com,REJECT는 example.com과 api.example.com 같은 하위 도메인에 적용됩니다. 문자열에 해당 텍스트가 포함되기만 하면 매칭되는 방식은 아니므로 notexample.com은 대상이 아닙니다. 접미사 매개변수 대신 *.example.com을 쓰지 마세요. 규칙 문법에 맞게 도메인만 입력하면 됩니다.

3. 규칙은 위에서 아래로 매칭됩니다: 예외는 앞에, FINAL은 뒤에

규칙 순서에 따라 결과가 달라집니다. 동일한 연결에서는 먼저 매칭되는 유효 규칙이 처리 정책을 결정합니다. 뒤에 있는 더 구체적인 규칙이 자동으로 우선 적용되지는 않습니다. 따라서 허용할 예외는 이를 포함하는 거부 규칙보다 앞에 배치하고, 범위가 넓은 IP·지역 규칙과 FINAL은 일반적으로 관련 도메인 규칙 뒤에 둡니다.

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

아래 예시는 순서만 설명합니다. keep.metrics.example.com은 먼저 정확한 예외 규칙과 매칭되고, 나머지 metrics.example.com 도메인 분기는 거부됩니다. FINAL,DIRECT는 예시를 완결된 형태로 보여주기 위한 것입니다. 실제 구성에서는 기존 기본 처리 정책을 유지하세요. 차단 규칙을 추가하려고 매칭되지 않은 모든 트래픽을 직접 연결로 바꾸지 마세요.

규칙 위치일반적인 문제수정 방법
FINAL 뒤에 있는 거부 규칙연결이 이미 기본 규칙으로 처리됨거부 규칙을 FINAL 앞으로 이동
접미사 거부 규칙 뒤에 있는 예외예외 호스트가 먼저 REJECT와 매칭됨정확한 예외를 접미사 규칙 앞으로 이동
범위가 넓은 허용 규칙이 거부 규칙보다 앞에 있음대상이 먼저 허용 정책과 매칭됨매칭 기록을 확인하고 겹치는 규칙의 순서를 조정

요점: 새 규칙을 추가하기 전에 처음 매칭된 규칙부터 확인하세요

대상 연결이 앞선 규칙으로 이미 처리됐다면 같은 REJECT 규칙을 반복해서 추가해도 결과는 달라지지 않습니다. 현재 구성과 매칭 위치를 확인한 다음 규칙을 옮기거나 조건을 좁히세요.

대상이 IP 주소라면 IP-CIDR,192.0.2.0/24,REJECT,no-resolve 같은 문법으로 주소 범위 매칭을 이해할 수 있습니다. 주소 범위는 문서의 예시입니다. no-resolve는 해당 IP 규칙을 위해 도메인 조회를 능동적으로 요청하지 않는다는 뜻이지, 기기의 DNS를 끄는 옵션이 아닙니다. 하나의 공인 IP를 여러 관련 없는 도메인이 공유할 수 있으므로 도메인 차단이 효과가 없다는 이유만으로 IP 범위 전체를 거부하지 마세요.

4. 도메인 차단으로는 같은 호스트의 경로와 앱 내 레이아웃을 구분할 수 없습니다

본문 API가 api.example.com/article이고 홍보 API가 api.example.com/promotion이라고 가정해 보겠습니다. 두 요청은 호스트명이 같으므로 DOMAIN이나 DOMAIN-SUFFIX로 뒤의 경로만 거부할 수 없습니다. api.example.com을 REJECT로 설정하면 본문, 로그인 상태, 댓글 API까지 차단될 수 있습니다.

콘텐츠 제공 방식도메인 규칙으로 처리할 수 있는 것보장할 수 없는 것
별도 호스트에서 불러오는 리소스해당 호스트의 새 연결 거부앱에서 빈 자리 표시를 없앤다고 보장할 수 없음
같은 호스트의 서로 다른 경로호스트 전체를 대상으로 처리도메인 규칙으로 특정 경로만 선택할 수 없음
하나의 응답에 함께 들어 있는 홍보 콘텐츠와 본문연결 전체를 거부응답 내용 중 일부만 골라낼 수 없음
로컬 캐시 또는 앱 내장 리소스새 연결이 없으면 매칭할 수 없음이미 표시된 콘텐츠가 즉시 사라진다고 보장할 수 없음

HTTPS에서는 URL 경로와 응답 본문이 일반적으로 숨겨집니다. 규칙에서 대상 도메인을 확인할 수 있다고 해서 암호화된 연결의 모든 리소스를 읽을 수 있는 것은 아닙니다. 호스트 연결을 거부하는 데 콘텐츠 복호화가 필요하지는 않지만, 도메인 단위 REJECT의 적용 범위 역시 해당 연결에 한정됩니다. 이 글에서는 경로 처리, 응답 수정, 페이지 요소 숨기기를 도메인 규칙의 기능과 혼동하지 않습니다.

5. 규칙 추가 및 확인: 한 번에 하나씩 변경하고 복구 방법을 남겨 두세요

정상적으로 사용할 수 있는 구성을 기준으로 테스트하세요. 이 글은 사용자가 이미 자신의 서비스 제공업체와 구독을 보유하고 있음을 전제로 하며, 연결 서비스를 제공하거나 추천하지 않습니다. 원래 직접 접속할 수 있는 리소스를 테스트한다면 기존 연결 방식을 그대로 유지하고 새 규칙이 가져오는 차이만 확인하면 됩니다.

  1. 현재 구성을 백업하세요. Config에서 현재 선택된 파일을 확인하고 사본을 저장하거나 원본 내용을 기록하세요. 예시 전체를 기존 파일에 덮어쓰지 마세요.
  2. 라우팅 모드를 고정하세요. Home에서 연결이 활성화되어 있는지 확인하고 Global Routing을 Config로 설정한 뒤, 방금 편집한 구성이 사용 중인지 확인하세요.
  3. 정확한 규칙을 추가하세요. 해당 구성의 [Rule] 섹션에 DOMAIN,ads.example.com,REJECT 형식의 규칙을 하나 추가합니다. 예시 호스트를 직접 기록한 대상 호스트로 바꾸고, 관련된 광범위 규칙과 FINAL보다 앞에 배치하세요.
  4. 저장한 뒤 요청을 다시 보내세요. 대상 페이지나 앱을 다시 열고, 필요하면 연결을 다시 설정해 새 구성으로 요청을 판단하게 하세요. 이미 유지 중인 장시간 연결이나 로컬 캐시만으로는 검증하기 어렵습니다.
  5. 연결 기록을 확인하세요. 대상 호스트의 새 요청을 찾아 실제 정책이 REJECT인지 확인합니다. 로그인, 본문, 이미지, 재생 등 필요한 기능도 함께 점검하세요.
  6. 기능에 문제가 생기면 먼저 되돌리세요. 방금 추가한 규칙을 삭제하거나 비활성화한 뒤 다시 테스트하세요. 기능이 복구되면 정확한 예외를 추가할지, DOMAIN으로 범위를 좁힐지, 해당 도메인 전체 차단을 포기할지 결정하세요.

기기에서 자동 연결을 사용한다면 Settings → On Demand도 확인하세요. 테스트 중 연결이 자동으로 복구되거나 상태가 바뀌었는데 알아차리지 못하는 일을 방지할 수 있습니다. On Demand는 연결을 시작할 시점을 결정하며 REJECT의 매칭 우선순위에는 영향을 주지 않습니다. 두 항목은 따로 확인해야 합니다.

6. 자주 묻는 질문: 규칙 미매칭, 콘텐츠 표시, 잘못된 차단 복구

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

먼저 차단 대상이 웹페이지의 호스트인지 부가 리소스 호스트인지 확인하세요. 리소스 도메인만 차단했다면 본문이 계속 열리는 것이 정상일 수 있습니다. 그런 다음 Home의 Global Routing이 Config인지, 올바른 구성이 선택됐는지, 규칙이 FINAL 앞에 있는지 확인하세요. 마지막으로 페이지 전체가 열리는지만 보지 말고 새 연결에 실제로 적용된 정책을 확인하세요.

기록에는 REJECT로 나오는데 앱에 기존 콘텐츠가 계속 표시되는 이유는 무엇인가요?

대상 페이지를 다시 열고 새 요청이 발생하는지 확인하세요. 이미 다운로드한 이미지, 미리 불러온 콘텐츠, 앱 내장 리소스는 계속 표시될 수 있습니다. 앱이 다른 호스트를 사용할 수도 있습니다. 화면에 콘텐츠가 남아 있다는 이유만으로 차단 범위를 넓히지 말고 요청 시각과 대상 도메인을 대조하세요.

규칙을 추가한 뒤 로그인이 되지 않으면 어떻게 복구하나요?

최근에 추가한 규칙을 먼저 취소하고 로그인을 다시 시도하세요. 로그인이 복구된다면 해당 규칙이 필요한 API까지 포함했을 수 있습니다. 로그인 전후의 호스트 기록을 비교하고 접미사 규칙을 정확한 호스트 규칙으로 좁히세요. 특정 호스트를 허용해야 한다고 확인된 경우에만 해당 정확한 예외를 거부 규칙 앞에 추가하세요.

다른 프록시 프로토콜로 바꾸면 REJECT가 더 정확해지나요?

Shadowsocks, VMess, VLESS, Trojan, Hysteria2, WireGuard로 바꾼다고 콘텐츠를 식별하는 기능이 생기지는 않습니다. REJECT 매칭은 규칙 처리에 들어오는 트래픽, 확인 가능한 대상 정보, 규칙 순서에 따라 달라집니다. 원인을 구분할 수 있도록 연결 방식은 그대로 둔 채 규칙부터 확인하세요.

규칙을 유지할 가치가 있는지 판단하려면 세 가지 조건을 모두 확인해야 합니다. 대상의 새 요청이 실제로 매칭되는지, 의도한 리소스가 제한되는지, 필요한 기능이 잘못 차단되지 않는지입니다. 도메인 단위로는 유지할 콘텐츠와 거부할 콘텐츠를 구분할 수 없다면 그 한계를 인정하고 더 광범위한 거부 규칙을 계속 추가하지 마세요.