REJECT는 규칙이 일치했을 때 실행되는 거부 정책이지, 페이지 요소를 선택하는 기능이 아닙니다. Shadowrocket을 사용하며 특정 도메인 연결을 제한하려는 분을 위해 DOMAIN과 DOMAIN-SUFFIX 작성법, Global Routing 선택, 규칙 순서 및 오차단 확인 방법을 설명합니다. 기존에 사용할 수 있는 구성과 서비스가 있다는 전제에서 안내합니다. 먼저 구성을 백업한 뒤 규칙 하나로 확인하고, 출처가 불분명한 대규모 목록은 바로 가져오지 마세요.
REJECT가 적용되는 위치
분기 규칙은 매칭 조건과 일치 시 적용할 정책으로 구성됩니다. DOMAIN,ads.example.com,REJECT를 예로 들면 DOMAIN은 전체 도메인 일치를 지정하고, ads.example.com은 매칭 값이며, REJECT는 거부 처리를 지정합니다. DIRECT와 다른 점은 다음과 같습니다. DIRECT는 대상에 직접 연결을 시도하지만, REJECT는 일치한 연결을 일반 직접 연결이나 프록시 경로로 대상에 전달하지 않습니다.
위 흐름은 Shadowrocket이 처리하고 규칙 판정 단계에 들어간 요청만 설명합니다. 도메인 규칙이 일치하는지는 해당 연결에서 매칭할 도메인 정보를 확인할 수 있는지에 따라서도 달라집니다. 연결 기록에 대상 IP만 있고 연결된 도메인이 없다면, 브라우저 주소창에 표시된 이름만으로 DOMAIN 규칙이 반드시 일치한다고 단정할 수 없습니다.
REJECT는 DNS를 수정하는 기능도 웹페이지를 편집하는 기능도 아닙니다. HTTPS 응답의 페이지 구조를 자동으로 읽거나, 특정 버튼의 문구나 이미지 위치를 기준으로 콘텐츠를 삭제하지 않습니다. 브라우저에는 리소스 로드 실패, 이미지 공백 또는 요청 오류로 나타날 수 있습니다. 표시 방식은 웹사이트의 오류 처리 로직에 따라 다르므로 특정 화면을 REJECT의 고정된 결과로 간주하지 마세요.
도메인 규칙의 기본 작성법
구성 파일의 규칙은 보통 [Rule] 섹션에 작성합니다. 아래 도메인은 문서 예시이며 실제 차단 목록이 아닙니다. 직접 설정할 때는 연결 기록에서 대상 이름을 확인한 뒤, 의도한 범위와 일치하는 규칙만 추가하세요. 도메인 이름에 ads나 track이 포함되어 있다는 이유만으로 안전하게 차단할 수 있다고 단정하지 마세요.
[Rule]
DOMAIN,ads.example.com,REJECT
DOMAIN-SUFFIX,metrics.example.net,REJECT
FINAL,DIRECT첫 번째 줄은 ads.example.com에만 적용되며 img.ads.example.com까지 함께 차단하지 않습니다. 두 번째 줄은 metrics.example.net 자체와 event.metrics.example.net 같은 하위 도메인에 적용됩니다. notmetrics.example.net처럼 문자열 일부가 일치하는 도메인에는 적용되지 않습니다. 도메인 입력란에는 프로토콜 접두사, 경로, 쿼리 매개변수 또는 포트를 입력하지 마세요.
정확한 범위
- 키워드
DOMAIN- 매칭 값
ads.example.com- 정책
REJECT- 적용 조건
- 단일 호스트의 용도를 확인했다면 먼저 좁은 범위로 테스트합니다.
다른 호스트에 영향을 줄 가능성을 줄이려면 먼저 전체 도메인을 사용합니다.
접미사 범위
- 키워드
DOMAIN-SUFFIX- 매칭 값
metrics.example.net- 정책
REJECT- 적용 조건
- 해당 도메인과 하위 호스트를 함께 차단해도 되는지 확인한 경우입니다.
접미사 매칭으로 범위를 넓히기 전에 로그인, 이미지 또는 API 서비스가 포함되어 있는지 확인합니다.
예시의 FINAL,DIRECT는 최소 규칙 섹션 전체를 보여 주기 위한 것으로, 앞선 규칙과 일치하지 않으면 DIRECT를 사용한다는 뜻입니다. 기존 구성은 다른 최종 정책을 사용할 수 있으므로 REJECT를 추가하려고 기존 FINAL을 바꾸지 마세요. 예시 전체를 기존 FINAL 뒤에 붙여서도 안 됩니다. 일반적으로 수정할 부분은 대상 거부 규칙뿐이며 기존 분기 구조는 유지해야 합니다.
- 올바른 예:
DOMAIN,ads.example.com,REJECT. - 도메인을
https://ads.example.com/banner로 작성하지 마세요. DOMAIN은 URL 경로와 일치하지 않습니다. - HTTPS의 일반적인 포트는
443, HTTP의 일반적인 포트는80입니다. 그렇다고 도메인 입력란에:443또는:80을 넣어야 하는 것은 아닙니다. - 해당 도메인 범위 전체를 거부하려는 것이 아니라면 단일 호스트 규칙 대신 상위 도메인
example.com의 접미사 규칙을 사용하지 마세요.
Config 활성화 및 규칙 순서 확인
규칙을 작성했다고 해서 현재 연결에 바로 적용되는 것은 아닙니다. 먼저 Config에서 현재 사용 중인 구성을 편집했는지 확인하고 저장한 다음, Home → Global Routing으로 돌아가 Config를 선택하세요. Proxy와 Direct는 전역 라우팅 선택이므로 구성 파일의 개별 분기 규칙을 확인하는 데 사용하지 마세요. Scene은 장면 구성에 따라 실제 라우팅을 결정합니다. 문제를 확인할 때는 현재 Scene 선택 항목을 확인하고, Scene을 Config와 같은 의미로 취급하지 마세요.
- 백업: Config에 원래 구성의 사본을 보관하고 기존 FINAL 및 대상 도메인 주변의 규칙을 기록합니다.
- 추가: 확인된 DOMAIN 거부 규칙 하나를 먼저 일치할 수 있는 광범위한 규칙보다 앞에 배치하고, FINAL보다 앞에 두세요.
- 선택: Home으로 돌아가 Global Routing을 Config로 설정하고 연결 스위치가 켜져 있는지 확인합니다.
- 재시도: 대상 페이지나 앱을 닫았다가 다시 열어 접속합니다. 필요하면 연결을 다시 설정해 새 연결이 생성되도록 합니다.
- 확인: 이번 요청의 대상, 일치한 규칙 및 최종 정책을 확인합니다. 새 기록이 없으면 규칙이 작동하지 않는다고 섣불리 결론 내리지 마세요.
규칙은 순서대로 평가되며 먼저 일치한 규칙이 처리 정책을 결정합니다. 예를 들어 DOMAIN-SUFFIX,example.com,DIRECT를 먼저 작성하고 DOMAIN,ads.example.com,REJECT를 그 뒤에 작성하면, 대상이 앞의 상위 도메인 규칙에 먼저 일치해 뒤의 규칙이 실행되지 않을 수 있습니다. GEOIP와 IP-CIDR은 각각 IP의 지역 정보와 주소 대역을 기준으로 매칭합니다. 페이지 분류 기능이 아니므로 앞뒤 규칙 순서도 함께 확인해야 합니다.
[Rule]
DOMAIN,ads.example.com,REJECT
DOMAIN-SUFFIX,example.com,DIRECT
FINAL,DIRECT이 순서는 지정된 호스트를 먼저 거부하고, 해당 도메인 범위의 나머지 연결은 허용한 뒤, 마지막에 기본 정책을 적용한다는 뜻입니다. 기존 구성에서 규칙 세트나 정책 그룹을 사용한다면 이것들이 대상보다 먼저 적용되는지도 확인하세요. REJECT 한 줄을 찾았다고 확인을 끝내지 마세요. 현재 구성, 현재 라우팅 상태, 실제 규칙 매칭 기록이 모두 일치해야 판단 근거가 됩니다.
적용 범위와 페이지에 남는 콘텐츠
용도가 확인되었고 주요 기능과 비교적 독립적인 요청 도메인은 개별 차단에 적합할 수 있습니다. 도메인 이름이 통계 서비스처럼 보인다는 것만으로 업무상 의존성이 없다고 판단할 수는 없습니다. 일부 API는 세션 초기화, 기능 설정 또는 리소스 서명도 담당합니다. 이를 거부하면 통계 요청만 줄어드는 것이 아니라 앱이 다음 단계로 넘어가지 못할 수도 있습니다.
| 요청 유형 | REJECT로 처리할 수 있는 항목 | 주의할 점 |
|---|---|---|
| 독립 리소스 호스트 | 해당 호스트로 향하는 연결을 거부합니다. | 필수 리소스를 제공하는 호스트가 아닌지 먼저 확인합니다. |
| 같은 도메인의 서로 다른 경로 | 도메인 규칙은 해당 호스트와 관련된 연결 전체에 영향을 줍니다. | /banner만 거부하고 같은 호스트의 /login은 허용할 수 없습니다. |
| 본문에 포함된 콘텐츠 | 별도의 도메인 규칙으로 동일한 응답의 일부만 제거할 수 없습니다. | 본문에 이미 포함된 이미지 데이터나 텍스트는 자동으로 삭제되지 않습니다. |
| 로컬 캐시 리소스 | 이후 발생하는 요청 중 규칙에 일치하는 요청에만 영향을 줍니다. | 캐시에서 불러오면 대상에 새 연결이 발생하지 않을 수 있습니다. |
| 공유 CDN 주소 | IP 규칙은 해당 주소를 사용하는 연결에 영향을 줄 수 있습니다. | 하나의 IP에서 서로 관련 없는 여러 도메인을 제공할 수 있어 오차단 범위가 더 넓어집니다. |
판단 기준: 호스트부터 범위를 좁힌 뒤 확장 여부 결정
같은 접미사 아래의 호스트를 모두 거부해도 된다고 확인한 경우에만 DOMAIN을 DOMAIN-SUFFIX로 바꾸세요. 대상 콘텐츠가 로그인이나 본문과 같은 호스트를 사용한다면 도메인 범위를 더 넓히지 마세요. 페이지를 완전히 비우려고 더 넓은 IP 대역 규칙으로 바꾸는 것도 피해야 합니다.
HTTPS로 암호화된 콘텐츠는 REJECT를 설정한다고 해서 구간별 필터링이 가능한 평문으로 바뀌지 않습니다. 이 문서의 도메인 규칙을 사용하기 위해 HTTPS Decryption을 활성화하거나 복호화 인증서를 설치할 필요는 없습니다. 페이지의 특정 요소를 삭제하려는 것은 콘텐츠 계층의 문제이므로 연결 계층 규칙의 성공 여부로 대신 판단할 수 없습니다.
새 연결로 확인하고 되돌릴 방법 마련
문서 예시 도메인에 접속해 특정 결과를 기대하는 대신, 실제로 확인된 요청 하나를 기준으로 테스트하세요. 먼저 규칙을 추가하지 않은 상태의 접속 결과를 기록한 뒤 규칙 하나를 추가하고 새 요청을 발생시켜 매칭 여부를 확인합니다. 매번 조건 하나만 바꿔야 규칙 순서, 캐시, 연결 재사용 또는 대상 자체의 변화 중 무엇이 원인인지 구분할 수 있습니다.
- 기준 상태 기록: 기존 구성에서 대상 작업을 한 번 수행하고 시간과 도메인, 로그인·이미지·재생 등 필요한 기능이 정상인지 기록합니다.
- 단일 규칙 테스트: 정확한 DOMAIN 규칙을 추가하고 저장한 뒤 현재 구성을 확인합니다. 서비스, 프로토콜, DNS 설정을 동시에 바꾸지 마세요.
- 새 요청 생성: 대상 앱이나 페이지를 다시 엽니다. 새로고침해도 캐시를 사용할 수 있으며, 이미 열린 장기 연결은 즉시 새로운 분기 판단을 거치지 않을 수 있습니다.
- 기록 확인: 새 연결 기록에 예상한 대상과 REJECT가 표시되는지 확인합니다. 다른 호스트가 기록되면 도메인을 추측해 여러 개 추가하지 말고 먼저 요청 흐름을 확인하세요.
- 되돌리기 테스트: 방금 추가한 규칙을 삭제하거나 주석 처리한 뒤 같은 작업을 다시 시도합니다. 규칙을 추가하거나 취소할 때 오류도 함께 발생하고 사라지는 경우에만 해당 규칙을 주요 원인으로 의심할 수 있습니다.
- 기록 보관: 규칙이 효과가 있으면 차단 이유와 영향 범위를 기록합니다. 구성을 업데이트한 뒤에도 이 로컬 수정 사항이 현재 사용하는 파일에 남아 있는지 다시 확인하세요.
구입 정보와 구성 출처가 혼동된다면 먼저 클라이언트와 연결 서비스를 구분하세요. Shadowrocket은 폐쇄형 상용 앱이며, 클라이언트 일회성 구매와 연결 서비스 요금제는 별개입니다. 이 문서에서는 노드나 구독을 제공·판매·추천하지 않습니다. 기존 구독을 업데이트해도 로컬 REJECT 규칙이 반드시 유지되는 것은 아니므로 서비스 정보와 구성 파일의 업데이트 결과를 각각 확인해야 합니다.
자주 묻는 질문 및 복구 방법
REJECT 규칙을 추가했는데 왜 페이지에 기존 이미지가 계속 보이나요?
먼저 새 연결이 생성됐는지 확인하세요. 페이지에서 로컬 캐시를 사용하거나 같은 리소스를 다른 호스트에서 불러올 수 있습니다. 페이지를 다시 열고 대상 요청 기록을 확인하세요. 대상 요청에 실제로 REJECT가 적용됐는데도 이미지가 보인다면 본문에 포함된 콘텐츠인지 확인하고 접미사 범위를 더 넓히지 마세요.
연결 스위치는 켰는데 왜 규칙이 전혀 적용되지 않나요?
Home → Global Routing이 Config로 설정되어 있는지, Config에서 현재 사용하는 파일에 새 규칙이 포함되어 있는지, 규칙이 FINAL 및 먼저 일치하는 다른 규칙보다 앞에 있는지 순서대로 확인하세요. 그런 다음 새 연결을 발생시킵니다. 파일만 저장하고 다른 구성을 계속 사용하면 새 규칙은 적용되지 않습니다.
차단 후 로그인이 실패하면 구성을 전부 삭제해야 하나요?
먼저 가장 최근에 추가한 규칙만 취소하고 나머지 설정은 그대로 둔 채 다시 연결해 로그인해 보세요. 정상적으로 돌아오면 접미사 규칙을 확인된 단일 호스트로 좁히거나 해당 도메인에 정상적으로 접근할 수 있도록 유지합니다. 인증, 위험 관리 및 API에 공유되는 도메인은 이름만 보고 바로 거부하지 않는 것이 좋습니다.
프로토콜을 바꾸면 REJECT가 더 확실하게 차단하나요?
프로토콜을 바꿔도 페이지 콘텐츠를 필터링하는 기능이 생기지는 않습니다. Shadowsocks, VMess, VLESS, Trojan, Hysteria2, WireGuard는 연결 및 전송 방식을 다룹니다. REJECT의 범위는 매칭 조건, 규칙 순서 및 현재 라우팅에 따라 달라집니다. 차단 범위를 넓히기 위해 프로토콜을 바꾸지 말고 규칙부터 바로잡으세요.
최종적으로 유지할 규칙은 이유를 설명할 수 있고, 검증과 되돌리기가 가능해야 합니다. 기능에 문제가 생기면 최근 변경 사항을 먼저 취소한 뒤 규칙 매칭 기록을 확인하세요. 대상이 독립적인 호스트 범위로 분리되지 않는다면 거부 범위를 계속 넓히기보다 연결 계층 규칙의 한계를 받아들이는 편이 정상적인 접근을 유지하기 쉽습니다.