Shadowrocket의 REJECT는 연결 처리 정책이지 페이지 요소 필터가 아닙니다. 직접 구성한 설정을 사용하며 도메인 차단 규칙을 확인하려는 사용자를 위한 안내입니다. 먼저 Global Routing이 Config로 설정되어 있는지 확인하고, 규칙 순서와 도메인 정보, 새 연결 기록을 점검하세요. 대상 도메인 전체에 접속할 필요가 없다고 확신할 때만 DOMAIN-SUFFIX의 차단 범위를 넓히세요.
REJECT의 위치: 규칙은 대상을 찾고, 정책은 연결을 처리합니다
일반적으로 규칙은 규칙 유형, 일치 조건, 처리 정책으로 구성됩니다. DOMAIN-SUFFIX,example.com,REJECT를 예로 들면 DOMAIN-SUFFIX는 도메인 접미사로 일치 대상을 찾고, example.com은 일치 조건이며, REJECT는 규칙에 일치한 연결을 거부하는 정책입니다. REJECT를 도메인 목록으로 보면 안 되며, 설정에 이 단어가 있다는 이유만으로 대상 연결이 반드시 거부된다고 판단할 수도 없습니다.
일반적인 규칙 분류 과정에서는 위에서부터 규칙을 확인하고, 일치하는 규칙이 있으면 해당 정책을 적용합니다. 따라서 앞에 배치된 범위가 넓은 허용 규칙이 뒤에 있는 거부 규칙보다 먼저 일치할 수 있습니다. FINAL은 앞의 규칙이 모두 일치하지 않을 때 적용하는 기본 규칙이므로 목록의 맨 아래에 두어야 합니다. 추가로 규칙을 확인하는 항목이 아니며, 앞선 규칙에 일치한 연결의 결과를 다시 덮어쓰지도 않습니다.
DIRECT: 일치한 연결을 직접 연결로 처리합니다.REJECT: 일치한 연결을 거부합니다. 앱에서는 실패, 재시도 또는 시간 초과로 표시될 수 있으며, 구체적인 동작은 앱에 따라 다릅니다.- 프록시 정책 또는 정책 그룹: 일치한 연결에 설정에서 지정한 아웃바운드를 사용합니다. 정책 이름은 현재 설정에 정의된 유효한 이름이어야 하며, 정의되지 않은 이름을 임의로 입력해서는 안 됩니다.
규칙이 판단에 적용되는지는 현재 실행 모드에도 달려 있습니다. Home → Global Routing에서 선택된 항목을 확인하세요. 이 글의 점검은 Config를 사용하는 경우를 전제로 합니다. Proxy와 Direct는 설정 규칙의 일치 여부를 확인하는 동일한 테스트 조건이 아닙니다. Scene을 사용하는 경우에는 해당 Scene에서 실제로 어떤 분류 설정을 사용하는지 먼저 확인하세요.
DOMAIN-SUFFIX의 범위: 웹페이지 경로가 아닌 도메인 접미사 전체
DOMAIN-SUFFIX,example.com,REJECT는 example.com과 img.example.com 같은 하위 도메인에 일치하지만, 글자가 비슷하다는 이유로 notexample.com에 일치하지는 않습니다. 특정 호스트 이름 하나만 처리하려면 DOMAIN으로 정확히 일치시켜 같은 접미사를 사용하는 다른 서비스까지 함께 거부하지 않도록 하세요.
| 규칙 또는 대상 | 일치 결과 | 확인할 점 |
|---|---|---|
example.com | 접미사 규칙에 일치 | 루트 도메인도 포함 |
img.example.com | 접미사 규칙에 일치 | 하위 도메인도 포함 |
notexample.com | 이 접미사 규칙에는 일치하지 않음 | 도메인 레이블 경계가 다름 |
example.com/assets/banner.jpg | 경로별로 구분할 수 없음 | 접미사 일치는 URL 경로를 확인하지 않음 |
다음은 ‘정확한 예외를 먼저, 접미사 거부 규칙은 다음에, 기본 규칙은 마지막에’ 배치하는 순서를 보여 주는 규칙 예시입니다. 예시 도메인은 문법 설명용이며 실제로 차단할 서비스나 그대로 교체해 사용할 완성 설정이 아닙니다. 기존 설정에 적용하기 전에 직접 연결 예외가 실제 사용 목적에 맞는지 확인하세요.
[Rule]
DOMAIN,keep.example.com,DIRECT
DOMAIN-SUFFIX,example.com,REJECT
FINAL,DIRECT여기서는 keep.example.com이 먼저 정확한 직접 연결 규칙에 일치합니다. 그 밖의 example.com에 속하는 대상만 다음 거부 규칙에 해당합니다. 두 규칙의 순서를 바꾸면 앞에 있는 접미사 규칙이 예외를 먼저 처리합니다. 페이지 문제 하나를 해결하려고 공개 도메인의 접미사 전체를 거부하지 마세요. 용도가 확인된 최소 범위의 대상부터 점검하세요.
검증 시작: 실행 모드와 현재 설정 고정하기
문제를 점검할 때는 한 번에 조건 하나만 바꾸세요. 먼저 현재 설정의 사본을 저장하고 테스트 전후의 규칙 순서를 기록한 다음, 수정 중인 파일이 현재 실제로 사용 중인 설정인지 확인하세요. Config 목록의 다른 파일만 수정하고 적용하지 않았다면 규칙 문법에 문제가 있다는 근거가 되지 않습니다.
실행 조건
- 분류 설정 위치
- Home → Global Routing
- 테스트 모드
- Config
- 설정 확인
- Config에서 현재 사용 중인 파일 확인
- 연결 전제 조건
- VPN이 연결되었는지 확인한 뒤 새 요청 보내기
먼저 실행 조건을 고정한 다음 규칙이 일치 여부 판단에 적용되는지 확인하세요.
규칙 조건
- 정확히 일치
DOMAIN,ads.example.com,REJECT- 접미사 일치
DOMAIN-SUFFIX,example.com,REJECT- 기본 규칙 위치
FINAL을 규칙 목록 맨 아래에 배치- 기록 항목
- 대상 호스트, 대상 IP, 일치한 규칙 및 처리 정책
앱에 실제로 표시되는 연결 기록을 확인하고, 페이지의 겉모습을 규칙 일치의 증거로 삼지 마세요.
- 용도를 직접 확인할 수 있는 도메인 하나를 정하고, 영향 범위를 넓히지 않도록 정확한 일치 규칙부터 테스트하세요.
- 테스트 규칙을 먼저 일치할 가능성이 있는 넓은 범위의 규칙보다 위에 두고, 설정을 저장한 뒤 현재 사용 중인지 확인하세요.
- 기존 요청을 종료한 다음 대상 페이지를 다시 열거나 기능을 다시 실행해 앱이 새 연결을 만들도록 하세요.
- 연결 기록에서 테스트 시각, 대상 정보, 일치한 정책을 확인하세요. 필요한 경우 설정은 유지한 채 VPN에 다시 연결한 후 테스트하세요.
- 테스트 규칙을 제거하고 같은 작업을 다시 수행해 새 연결 결과를 비교하세요. 해당 규칙이 실제로 영향을 주었는지 확인할 수 있습니다.
On Demand는 자동 연결 조건을 관리하는 기능이지, 도메인 거부 규칙의 우선순위를 바꾸는 기능이 아닙니다. 테스트 도중 VPN이 자동으로 연결되거나 끊긴다면 Settings → On Demand에서 관련 조건을 확인하세요. 터널 상태 변화와 REJECT의 간헐적 미작동을 혼동하지 않도록 해야 합니다.
같은 도메인에 있는 콘텐츠의 한계: 연결은 거부할 수 있지만 페이지 일부만 삭제할 수는 없습니다
본문, 이미지, 로그인 API, 차단하려는 콘텐츠가 모두 같은 호스트 이름에서 제공되는 경우 도메인 규칙만으로는 요청의 용도를 구분할 수 없습니다. HTTPS 요청 경로와 응답 본문, 페이지 요소는 DOMAIN-SUFFIX의 일치 조건에 포함되지 않습니다. 해당 도메인을 거부하면 로그인, 인증 코드, 이미지 로딩 또는 재생 기능에도 영향을 줄 수 있습니다.
HTTP/3은 보통 UDP 443을 사용하고, 일반적인 HTTPS 연결은 TCP 443을 사용할 수도 있습니다. 포트 443만 보고 해당 연결이 본문, 통계 데이터, 동영상 요청 중 무엇인지 판단할 수 없습니다. 따라서 거부 규칙 하나가 특정 종류의 콘텐츠에만 영향을 준다고 단정할 수도 없습니다. 연결을 거부한 뒤 앱이 다른 도메인이나 대체 API를 사용하거나 기존 캐시를 표시하면 콘텐츠가 그대로 남아 있는 것처럼 보일 수도 있습니다.
결론: 요청 용도를 구분할 수 없다면 일치 범위부터 좁히세요
접미사 거부 규칙을 추가한 뒤 로그인이나 본문 표시에도 문제가 생기면 먼저 규칙을 제거하세요. 연결 기록으로 별도의 대상 호스트가 확인된 경우에만 DOMAIN으로 해당 호스트를 따로 테스트하고, 도메인이나 IP 범위를 더 넓히지 마세요.
- 페이지에 빈 공간이 생김: 리소스 연결 실패일 수 있습니다. REJECT는 페이지 레이아웃을 다시 구성하지 않습니다.
- 콘텐츠가 계속 표시됨: 규칙이 일치하지 않았다고 단정하기 전에 로컬 캐시, 기존 연결, 대체 도메인을 확인하세요.
- 페이지 전체가 열리지 않음: 메인 사이트, 인증 API 또는 공용 리소스 도메인을 잘못 거부했는지 확인하세요.
암호화 DNS와 IP 규칙: 일치 시점에 어떤 대상 정보를 사용할 수 있는지가 핵심입니다
도메인 규칙이 적용되려면 규칙을 확인하는 시점에 사용할 수 있는 도메인 정보가 필요합니다. DNS 조회 방식과 캐시, 앱의 IP 직접 연결 여부, 설정의 DNS 처리 방식에 따라 연결 기록에 표시되는 정보가 달라집니다. ‘암호화 DNS를 사용한다’는 사실만으로 모든 도메인 규칙이 작동하지 않는다고 볼 수는 없습니다. 반대로 모든 IP 연결의 원래 도메인을 반드시 알아낼 수 있다고 가정해서도 안 됩니다.
DoH를 사용하는 앱은 HTTPS로 DNS 조회 서버와 통신할 수 있습니다. 이 요청만으로 앱이 이후 조회할 도메인이 모두 드러나는 것은 아닙니다. 이후 서비스 연결에 IP만 표시되고 사용할 수 있는 도메인 연관 정보가 없다면 도메인 규칙이 일치하지 않을 수 있습니다. 반대로 Shadowrocket에서 사용할 수 있는 도메인 매핑이나 다른 대상 정보가 확인된다면 도메인 기준으로 처리될 수도 있으므로 해당 연결 기록을 기준으로 판단하세요.
| 기록 또는 현상 | 우선 확인할 사항 | 바로 해서는 안 되는 조치 |
|---|---|---|
| 대상 도메인은 보이지만 다른 정책이 적용됨 | 규칙 순서, 현재 설정, 철자 | 일단 DNS부터 바꿔 보기 |
| 대상 IP만 표시됨 | DNS 조회 경로, 도메인 연관 정보, 앱의 연결 방식 | 도메인 규칙이 반드시 일치한다고 가정하기 |
| IP 거부 후 여러 기능에 문제가 생김 | 공유 IP, CDN, 다른 서비스의 연결 | 거부하는 IP 대역을 더 넓히기 |
IP-CIDR은 주소나 네트워크 대역에 일치하고, GEOIP는 IP 지리 정보 데이터베이스를 기준으로 분류합니다. 둘 다 페이지 콘텐츠를 기준으로 분류하지 않습니다. 문법 예시 IP-CIDR,192.0.2.1/32,REJECT,no-resolve에는 문서 예시용으로 예약된 주소가 사용되었습니다. 여기서 /32는 IPv4 주소 하나를 뜻하고, no-resolve는 이 IP 규칙을 위해 도메인 조회를 능동적으로 실행하지 않는다는 의미입니다. 누락된 도메인 정보를 모두 보완하는 옵션이 아니며, 실제 차단에 그대로 사용해서도 안 됩니다.
문제 해결 결론: 새 연결의 규칙 일치 기록을 기준으로 확인하세요
REJECT 규칙의 작동 여부를 판단하려면 최소한 ‘설정이 활성화되었는지’, ‘대상이 규칙에 일치했는지’, ‘결과가 예상과 맞는지’를 나누어 확인해야 합니다. 페이지에 콘텐츠가 계속 표시된다는 사실만으로 거부가 발생하지 않았다고 증명할 수 없습니다. 연결 하나가 실패했다고 해서 REJECT가 원인이라고 단정할 수도 없습니다. 기록에 표시된 대상과 시각, 일치한 규칙을 앱 동작과 함께 확인하세요.
- REJECT에 일치하지 않음: Home → Global Routing이 Config로 설정되어 있는지 확인한 다음, 현재 설정과 규칙 위치, 도메인 경계, 사용할 수 있는 대상 정보를 점검하세요.
- 규칙에 일치했지만 콘텐츠가 계속 표시됨: 요청을 새로 보내고 캐시, 기존 연결, 대체 도메인을 확인한 뒤 콘텐츠를 실제로 제공하는 연결을 기록하세요.
- 규칙에 일치한 뒤 기능에 문제가 생김: 해당 규칙을 제거하고 범위를 더 좁혀 검증하세요. 여러 기능이 같은 도메인을 사용한다면 접미사 규칙으로 페이지 콘텐츠를 구분하려고 하지 마세요.
- 규칙을 계속 유지해야 함: 대상의 용도와 규칙 추가 이유, 되돌리는 방법을 기록하세요. 설정을 업데이트한 뒤에도 규칙이 남아 있는지, 순서가 바뀌지 않았는지 다시 확인하세요.
기존 구독은 보통 연결 정보를 업데이트하는 데 사용하고, Config의 규칙 설정은 별도로 확인해야 합니다. 구독을 한 번 업데이트했다고 거부 규칙까지 업데이트되는 것은 아닙니다. 설정 파일을 업데이트하면 직접 수정한 내용이 달라질 수도 있습니다. 이미 본인의 서비스와 구독을 사용하는 경우에는 연결 정보와 규칙 파일 상태를 각각 확인하세요. REJECT를 테스트하기 위해 연결 서비스를 바꿀 필요는 없습니다.