Shadowrocket REJECT 규칙 사용법: 차단 범위와 한계

이 글의 핵심

Shadowrocket의 REJECT는 연결을 거부하는 정책이지, 페이지 요소를 삭제하는 도구가 아닙니다. 먼저 Config에서 대상 규칙이 포함된 구성을 선택한 다음 Home → Global Routing에서 Config를 선택하세요. 사용할 서버 정보와 구독을 이미 보유하고 있으며 로컬 규칙을 조정하려는 사용자를 위해, 도메인 매칭부터 URL 확인 가능 여부, 규칙 순서, 캐시 영향을 살펴보고 작은 범위에서 검증해 오차단 위험을 줄이는 방법을 설명합니다.

1. REJECT는 어디에 적용될까: 페이지 수정이 아닌 요청 매칭

앱이 네트워크 요청을 보내더라도 Shadowrocket이 처리하는 트래픽에 포함되어야 현재 구성의 규칙으로 판단할 수 있습니다. 규칙은 확인 가능한 도메인, 대상 IP, URL 등의 정보를 조건으로 사용합니다. REJECT 규칙에 일치하면 해당 연결은 거부되며 DIRECT나 프록시 정책으로 전달되지 않습니다. 앱에는 로딩 실패나 재시도 안내가 표시될 수 있고, 앱이 다른 주소로 다시 요청할 수도 있습니다.

앱 요청 트래픽 처리 조건 확인 규칙 매칭 연결 거부

이 과정은 페이지 레이아웃을 해석하거나 이미지와 텍스트가 광고인지 판별하지 않습니다. 대상 콘텐츠가 별도 도메인에서 로드된다면 그 도메인의 연결을 거부해 콘텐츠 표시를 막을 수 있습니다. 반면 콘텐츠가 메인 페이지 응답에 포함되어 있다면 REJECT로 일부만 삭제할 수 없습니다. 빈 영역, 로딩 아이콘, 앱 자체 안내 문구도 연결 규칙으로 직접 지울 수 있는 대상이 아닙니다.

먼저 차단하려는 콘텐츠에 별도의 네트워크 요청이 있는지 확인한 뒤 매칭 조건을 선택하세요. 화면에 빈 영역이 남아 있어도 요청이 거부되지 않았다는 뜻은 아닙니다. 콘텐츠가 잠시 표시되지 않는다고 해서 규칙이 적용된 것도 아닙니다.

2. DOMAIN-SUFFIX 작성법: 독립 도메인부터 좁은 범위로 차단하기

DOMAIN-SUFFIX는 지정한 도메인과 하위 도메인에 매칭됩니다. 아래의 ads.example.com은 문법 설명을 위한 예시일 뿐, 실제 차단 목록이 아닙니다. 이 규칙은 ads.example.com과 img.ads.example.com에는 적용되지만 notads.example.com에는 적용되지 않습니다. 하위 도메인 하나를 매칭하려고 메인 도메인 전체를 REJECT로 설정하지 마세요.

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

위 예시는 대상 도메인은 거부하고 나머지는 직접 연결하는 방식을 설명합니다. 모든 네트워크 환경에 적합한 완성형 구성은 아닙니다. 기존 구성에서 FINAL이 다른 정책을 가리킨다면 원래의 기본 처리 의도를 유지하고, 무조건 DIRECT로 바꾸지 마세요. 기존 구성에 [Rule]이 있다면 해당 영역에 규칙을 추가하고, 같은 이름의 영역을 중복해서 만들지 마세요.

Config에서 현재 구성을 백업하고, 편집 중인 파일이 실제로 적용하려는 파일인지 확인하세요.
대상 도메인의 REJECT 규칙은 먼저 적용될 수 있는 포괄적인 허용 규칙보다 앞에 두고, FINAL은 규칙 맨 끝에 유지하세요.
구성을 저장하고 선택한 뒤 Home → Global Routing으로 돌아가 Config를 선택하세요.
연결이 켜져 있는지 확인한 다음 대상 요청을 다시 보내세요. 로그인, 이미지, 본문 등 정상 기능에 영향이 없는지도 살펴보세요.

일반적인 순차 매칭에서는 앞에서 일치한 규칙이 정책을 결정합니다. 예를 들어 DOMAIN-SUFFIX,example.com,DIRECT을 먼저 작성하고 ads.example.com에 대한 REJECT를 뒤에 두면, 뒤의 규칙은 적용되지 않을 수 있습니다. 구체적인 조건을 먼저 배치하고 포괄적인 조건은 뒤에 두세요. FINAL은 앞선 규칙 중 어느 것에도 일치하지 않을 때 마지막으로 적용됩니다.

3. Global Routing과 매칭 조건: 연결 트리거를 차단 규칙과 혼동하지 않기

규칙이 적용되지 않을 때는 먼저 Home → Global Routing을 확인하세요. Proxy, Direct, Config, Scene은 서로 다른 라우팅 모드이므로 연결 스위치가 켜져 있다는 이유만으로 구성의 규칙이 적용 중이라고 판단할 수 없습니다. 이 문서의 기본 검증 조건은 Config입니다. 선택한 구성의 규칙이 트래픽 분류에 사용되도록 설정하세요. Scene은 해당 모드의 설정을 별도로 확인해야 하며, 이 최소 테스트의 전제 조건은 아닙니다.

최소 도메인 테스트

구성 메뉴: Config → 테스트 구성 선택
라우팅 메뉴: Home → Global Routing → Config
대상 규칙: DOMAIN-SUFFIX,ads.example.com,REJECT
기본 처리 예시: FINAL,DIRECT

예시는 문법 설명용입니다. 테스트할 때는 실제 대상 도메인임을 확인한 주소를 사용하세요.

연결과 매칭의 범위

자동 연결 메뉴: Settings → On Demand
On Demand의 기능: 조건에 따라 연결을 시작하며 REJECT 규칙을 대신하지 않습니다
IP-CIDR 조건: 대상 IP가 속한 네트워크 대역으로 매칭
GEOIP 조건: 대상 IP의 지리적 위치 정보로 매칭

먼저 연결과 Config를 확인한 뒤 요청에서 실제로 어떤 매칭 정보를 얻을 수 있는지 살펴보세요.

도메인 규칙을 적용하려면 요청에 해당하는 도메인 정보를 확인할 수 있어야 합니다. 앱이 IP 주소로 직접 접속하거나 다른 DNS 조회 경로를 사용하거나 요청에서 확인할 수 있는 정보가 제한되면 도메인 조건이 반드시 매칭된다고 볼 수 없습니다. IP-CIDR은 네트워크 대역 조건을, GEOIP는 지리적 위치 조건을 나타낼 수 있지만, 둘 다 IP의 콘텐츠 용도를 판별하지는 못합니다. 여러 서비스가 공유하는 서버나 콘텐츠 전송 주소는 특히 오차단이 발생하기 쉽습니다.

Shadowsocks, VMess, VLESS, Trojan, Hysteria2, WireGuard는 연결 프로토콜 이름이지 페이지 콘텐츠를 식별하는 규칙 조건이 아닙니다. REJECT에 일치한 요청은 프로토콜을 바꿔도 허용되지 않습니다. 먼저 일치한 규칙과 정책을 확인한 뒤 별도의 연결 문제가 있는지 살펴보세요.

4. URL-REGEX 작성법: URL을 확인할 수 있어야 경로를 매칭할 수 있습니다

URL-REGEX는 정규식으로 URL을 매칭하므로 도메인 규칙보다 구체적인 경로 조건을 지정할 수 있습니다. 아래 예시는 샘플 호스트에서 /banner/로 시작하는 경로만 매칭합니다. ^는 URL의 시작을, \.는 마침표 자체를, https?는 HTTP 또는 HTTPS를 나타냅니다. 정규식으로 조건을 표현할 수 있다고 해서 모든 연결에서 클라이언트가 전체 URL을 확인할 수 있는 것은 아닙니다.

URL-REGEX,^https?://ads\.example\.com/banner/,REJECT

조건	필요한 정보	주요 한계
`DOMAIN-SUFFIX`	대상 도메인	같은 도메인의 서로 다른 경로는 구분할 수 없습니다.
`URL-REGEX`	매칭할 URL	HTTPS로 암호화된 경로는 보통 직접 확인할 수 없습니다.
`IP-CIDR`	대상 IP 및 네트워크 대역	같은 IP를 사용하는 여러 서비스에 함께 영향을 줄 수 있습니다.

HTTPS는 경로와 쿼리 매개변수를 포함한 HTTP 요청 내용을 암호화합니다. 연결에 흔히 쓰이는 443 포트를 사용하더라도 호스트 이름을 확인할 수 있다는 사실만으로 /banner/를 읽을 수 있는 것은 아닙니다. HTTPS 경로를 매칭하려면 일반적으로 해당 트래픽에 MITM 처리가 가능해야 하며, 대상 호스트 범위와 인증서 신뢰, 앱 호환성 등의 조건도 충족해야 합니다. URL-REGEX 규칙만으로 별도 설정 없이 암호화된 경로를 확인할 수 있다고 생각하지 마세요.

일부 앱은 인증서 고정이나 다른 검증 방식을 사용해 MITM 처리된 연결을 거부할 수 있습니다. 이런 경우 해당 범위의 처리를 중단하고 원래 설정으로 되돌리세요. 앱 오류를 정규식 작성 오류로 단정해서는 안 됩니다. 클라이언트가 지원하는 처리 경로에서 평문 HTTP는 URL 정보를 제공할 수 있지만, 실제 매칭 여부는 요청과 로그를 기준으로 확인해야 합니다.

요약: 도메인이 분리되어 있다면 먼저 도메인 규칙 사용

대상 콘텐츠가 별도 도메인에서 로드되는지 확인한 뒤 DOMAIN-SUFFIX 규칙 하나부터 테스트하세요. 같은 도메인의 경로를 구분해야 하고 URL 확인 가능 여부도 검증할 수 있을 때만 URL-REGEX를 고려하세요.

5. 차단 가능한 경우와 한계: 같은 도메인의 콘텐츠, 캐시, 앱 내장 요청

REJECT는 명확히 식별할 수 있고 거부해도 필수 기능에 문제가 없는 독립 연결을 처리하는 데 적합합니다. 앱 내장 요청이라고 해서 자동으로 규칙을 우회하는 것은 아닙니다. 트래픽 처리 범위에 들어오고 매칭 조건을 충족하면 해당 요청도 거부될 수 있습니다. 다만 이런 요청은 메인 서비스 도메인을 공유하거나 주소를 바꾸거나 기존 연결을 사용하거나 네트워크에 새로 접속하지 않을 수 있어 다루기 어렵습니다.

독립된 리소스 도메인: 해당 도메인을 거부하면 새 연결을 막을 수 있지만, 인증 코드·이미지·로그인 기능에도 사용되는지 확인해야 합니다.
같은 도메인의 서로 다른 경로: DOMAIN-SUFFIX는 도메인 전체에 영향을 주므로 페이지의 특정 영역만 구분할 수 없습니다. URL-REGEX는 URL을 확인할 수 있는지에 따라 적용 여부가 달라집니다.
같은 응답에 포함된 콘텐츠: 본문과 추가 콘텐츠가 하나의 응답으로 전송되면 연결을 거부할 때 둘 다 차단됩니다. 본문만 남길 수는 없습니다.
로컬 캐시 및 내장 리소스: 앱이 새 연결 없이 표시할 수 있는 콘텐츠는 REJECT 규칙을 추가해도 자동으로 사라지지 않습니다.
대체 주소와 반복 요청: 주소 하나가 거부되면 앱이 다른 주소로 요청할 수 있습니다. 메인 도메인의 차단 범위를 계속 넓히기보다 이후 요청을 확인하세요.
기존 연결: 새 규칙이 이미 설정된 모든 연결을 즉시 정리하는 명령이라고 생각해서는 안 됩니다. 검증할 때는 대상 앱에서 연결을 다시 시작하세요.

예를 들어 로그인 API와 차단하려는 리소스가 모두 api.example.com에 있다면, 해당 도메인에 REJECT를 적용했을 때 로그인도 실패할 수 있습니다. 여러 도메인이 같은 IP를 공유한다면 네트워크 대역을 거부하는 방식이 더 정확하다고 할 수도 없습니다. 규칙의 범위는 요청 구조에 따라 정해야 하며, 근거가 부족하다고 차단 범위를 넓혀서는 안 됩니다.

6. 검증 및 되돌리기: 한 번에 하나씩 변경하기

제대로 검증하려면 대상 요청이 거부됐는지와 필수 기능을 계속 사용할 수 있는지를 모두 확인해야 합니다. Connectivity Test는 선택한 연결의 도달 가능성을 진단하는 기능이지, REJECT 규칙의 적용 여부를 확인하는 테스트가 아닙니다. 테스트 결과가 정상이어도 차단 규칙이 적용됐다는 뜻은 아니며, 결과가 비정상이어도 대상 도메인이 거부됐다고 단정할 수 없습니다.

기준 상태 기록: 원래 구성을 보관하고 대상 콘텐츠가 표시되는 위치, 확인된 요청 도메인, 로그인 등 정상 기능을 기록하세요.
규칙 하나만 수정: 구체적인 도메인 규칙 하나만 추가하세요. 프로토콜, 기본 처리 정책, DNS 설정을 동시에 바꾸지 마세요.
상태 확인: Config에서 선택한 파일, Home → Global Routing → Config, 연결 스위치 상태를 확인하세요.
요청 다시 보내기: 대상 페이지를 새로고침하거나 앱을 다시 열어 기존 연결과 캐시의 영향을 줄이세요.
근거 확인: 이용할 수 있는 요청 기록이나 로그에서 대상 도메인, 일치한 규칙, 최종 정책을 확인하세요. 화면에 보이는 결과만 살펴보지 마세요.
변경 전후 비교 및 복원: 해당 규칙을 삭제하거나 백업을 복원한 뒤 같은 절차를 반복하세요. 필수 기능에 문제가 생기면 먼저 정상적으로 사용할 수 있는 상태로 되돌리세요.

REJECT를 설정했는데 콘텐츠가 계속 표시되는 이유는 무엇인가요?

먼저 Home → Global Routing에서 Config를 선택했는지 확인한 다음 Config에서 실제로 선택된 파일을 확인하세요. 요청을 다시 보내고 새 대상 요청 기록이 없다면 포괄적인 규칙을 더 추가하기보다 캐시, 내장 리소스, 기존 연결을 먼저 살펴보세요.

차단했더니 로그인이 안 됩니다. 어떻게 복구하나요?

Config에서 방금 추가한 REJECT 규칙을 삭제하거나 백업을 복원한 뒤 저장하고 다시 선택하세요. 대상 도메인을 로그인 API와 공유하는지 확인하세요. 검증 없이 메인 도메인 전체나 공유 IP 대역을 차단하지 마세요.

URL-REGEX를 올바르게 작성했는데 HTTPS 경로가 매칭되지 않는 이유는 무엇인가요?

먼저 실제 요청 URL이 정규식과 일치하는지 확인한 다음 해당 트래픽에서 전체 URL을 확인할 수 있는지 살펴보세요. 도메인만 확인할 수 있다면 경로 규칙에 필요한 정보가 부족합니다. 443 포트 사용이나 연결 성공만으로 MITM이 적용됐다고 판단하지 마세요.

구성을 업데이트한 뒤 직접 추가한 규칙이 사라진 이유는 무엇인가요?

서버 정보 구독과 원격 구성 업데이트를 구분하세요. 전자는 주로 서버 정보를 갱신하고, 후자는 구성 내용을 덮어쓸 수 있습니다. 수정 전에 별도 백업을 보관하고 업데이트 후 Config에서 규칙과 순서, 선택 상태를 다시 확인하세요. Home의 서버 목록만 확인해서는 안 됩니다.

트래픽 분류 조건을 더 자세히 알아보려면 기술 참고 자료를 확인하세요. 첫 연결과 라우팅 모드 설정은 시작하기의 Global Routing 설명에서 볼 수 있습니다. 이 사이트는 노드나 구독을 제공·판매·추천하지 않습니다. 클라이언트 구매와 사용자가 보유한 회선 서비스는 별개의 항목입니다.