이 글의 핵심

REJECT는 매칭된 연결을 거부하는 정책이지, 웹페이지 요소를 숨기는 필터가 아닙니다. Config를 사용 중이며 차단 규칙을 추가하려는 사용자를 위해, 먼저 연결이 규칙 판정을 거치는지 확인하고 정확한 규칙 하나만 테스트한 뒤 요청 기록에서 오차단 원인을 찾고 기존 설정으로 복구하는 방법을 설명합니다. 예시는 문법 설명용이며 그대로 사용할 차단 목록이 아닙니다.

REJECT의 역할: 연결 거부, 페이지 콘텐츠 삭제가 아님

Shadowrocket의 규칙은 매칭 조건과 처리 정책으로 구성됩니다. 조건은 “어떤 연결이 해당되는가”를, 정책은 “매칭된 연결을 어떻게 처리하는가”를 정합니다. 예를 들어 DOMAIN,blocked.example.com,REJECT는 규칙 판정 결과 대상 도메인이 해당 이름과 일치하면 그 연결에 REJECT를 적용하고, 뒤에 있는 규칙으로 출구를 선택하지 않는다는 뜻입니다.

앱 요청 터널 처리 규칙 판정 REJECT 매칭 연결 거부

이 흐름이 성립하려면 해당 트래픽이 Shadowrocket의 처리 범위에 들어오고, 현재 라우팅 모드에서 해당 규칙을 사용해야 합니다. 기기의 모든 통신을 빠짐없이 보장하는 것은 아니며, 웹페이지에서 원하지 않는 모든 콘텐츠가 사라진다는 뜻도 아닙니다. 앱에 로딩 표시가 남거나 오류가 표시될 수 있고, 요청 실패 후 재시도가 이어질 수도 있습니다.

따라서 규칙이 적용됐는지는 연결이 매칭되어 거부됐는지 확인해야 합니다. 페이지에 빈 영역이 남았는지만으로 판단할 수는 없습니다. 빈 화면, 로딩 표시, 오류 메시지는 리소스를 가져오지 못해 나타날 수 있으며, REJECT가 페이지 레이아웃을 자동으로 조정했다는 증거는 아닙니다.

먼저 Global Routing을 확인한 뒤 규칙 순서를 점검하세요

Home에서 Global Routing을 확인합니다. 현재 설정의 규칙을 검증하려면 Config를 사용하고, Config에서 방금 편집한 설정이 활성화되어 있는지 확인하세요. Proxy와 Direct는 전체 라우팅 모드이므로, 그 결과만으로 현재 설정의 REJECT가 올바른지 판단하면 안 됩니다. Scene을 사용하는 경우에는 해당 Scene에서 실제로 선택된 설정과 라우팅 옵션도 확인해야 합니다.

3가지
이 글에서 다루는 정책: PROXY, DIRECT, REJECT
4줄
아래 예시: 정확한 도메인, 도메인 접미사, GEOIP, FINAL
1개
테스트할 때마다 차단 규칙은 하나만 추가하거나 수정하세요

판단 기준: 설정이 적용되는지 먼저 확인한 뒤 매칭 범위를 넓히세요

현재 활성화된 설정을 확인할 수 없다면 규칙 추가를 멈추세요. Config와 요청 기록이 일치하는지 확인한 뒤 도메인 하나만 테스트해야 라우팅 모드 문제를 문법 문제로 오해하지 않습니다.

규칙은 순서대로 판정하며, 매칭되면 해당 정책을 적용합니다. “더 구체적인” 규칙을 찾아 뒤로 넘어가지 않으므로 정확한 예외는 포괄적인 규칙보다 앞에 두고 FINAL은 마지막에 배치하세요. 아래는 문법을 보여 주기 위한 독립 예시이며, 도메인은 모두 설명용입니다. 이 예시를 근거로 기존 설정의 전체 출구 정책을 바꾸지 마세요.

[Rule]
DOMAIN,allowed.example.com,DIRECT
DOMAIN-SUFFIX,example.com,REJECT
GEOIP,CN,DIRECT
FINAL,PROXY

이 순서에서는 allowed.example.com이 첫 번째 줄에 먼저 매칭되므로 두 번째 줄에서 거부되지 않습니다. blocked.example.com은 두 번째 줄에 매칭될 수 있습니다. 첫 번째 줄을 두 번째 줄 뒤로 옮기면 정확한 예외가 적용되지 않습니다. GEOIP는 대상 IP의 지역 정보를 기준으로 판정하며, 페이지 언어나 웹사이트 운영자의 소재지를 뜻하지 않습니다.

DOMAIN, DOMAIN-SUFFIX, IP-CIDR의 적용 범위

문제가 있는 도메인 하나를 알고 있다면 먼저 DOMAIN으로 최소 범위만 테스트하세요. 해당 도메인의 모든 하위 도메인을 거부해야 한다고 확인된 경우에만 DOMAIN-SUFFIX를 고려합니다. 이 규칙은 지정한 도메인과 하위 도메인에 적용되며, 이름에 우연히 특정 문자열이 포함된 도메인만 매칭하는 것은 아닙니다. 기본 도메인을 넣으면 로그인, 이미지, API 요청까지 영향을 받을 수 있습니다.

도메인 범위 예시

정확히 일치
DOMAIN,blocked.example.com,REJECT
접미사 일치
DOMAIN-SUFFIX,example.com,REJECT
정확한 예외
DOMAIN,allowed.example.com,DIRECT

예외를 포괄 규칙보다 앞에 둡니다. DIRECT는 문법을 보여 주는 예시일 뿐이며, 실제 설정에서는 해당 대상에 원래 필요한 정책을 유지하세요.

IP 범위 예시

단일 IPv4 주소
IP-CIDR,192.0.2.8/32,REJECT
IPv4 주소 범위
IP-CIDR,192.0.2.0/24,REJECT
주소 설명
192.0.2.0/24는 문서 예시용 주소 범위입니다

문법만 보여 주는 예시입니다. 실제 주소는 본인의 연결 기록을 확인해야 하며, 그대로 복사해 유효한 차단 대상으로 사용하면 안 됩니다.

도메인 규칙은 규칙 판정에 사용할 수 있는 대상 도메인 정보에 의존합니다. 앱이 IP 주소로 직접 연결하거나 도메인 정보가 완전하지 않거나 실제 요청의 대상이 바뀌면 기존 도메인 규칙이 매칭되지 않을 수 있습니다. 이때는 연결 기록에서 실제 대상을 먼저 확인하세요. “도메인이 차단되지 않았다”는 이유만으로 넓은 IP 대역을 바로 거부하지 마세요.

REJECT로 차단할 수 있는 것과 차단할 수 없는 것

원하지 않는 리소스가 별도 도메인에서 제공되고 그 도메인이 필수 기능을 담당하지 않는다면, 도메인 단위로 비교적 좁은 범위에서 거부할 수 있습니다. 반대로 같은 도메인에서 본문, 로그인 인증, 기타 리소스를 모두 제공하면 도메인 규칙만으로 URL 경로에 따라 용도를 구분할 수 없습니다. HTTPS 연결의 구체적인 페이지 콘텐츠도 DOMAIN 규칙을 추가했다고 자동으로 매칭 기준이 되지는 않습니다.

요청 상황REJECT의 한계확인 방법
독립 리소스 도메인해당 도메인으로 향하는 매칭 연결을 거부할 수 있습니다해당 도메인이 로그인이나 서비스 API도 제공하는지 확인하세요
같은 도메인의 서로 다른 경로DOMAIN만으로 특정 경로 하나만 거부할 수는 없습니다문제가 있는 요청과 필수 요청의 호스트 이름이 같은지 비교하세요
캐시된 콘텐츠새 네트워크 요청이 없으면 새로운 규칙 판정도 발생하지 않습니다새로고침한 뒤 새 연결 기록이 생겼는지 확인하세요
기존 장기 연결규칙을 수정해도 기존 연결이 즉시 다시 매칭되는 것은 아닙니다설정을 저장하고 연결을 다시 만든 뒤 같은 동작을 재현하세요
공유 서비스 주소해당 주소를 거부하면 다른 서비스까지 영향을 받을 수 있습니다IP 대역 전체로 범위를 넓히기 전에 도메인과 용도를 먼저 확인하세요

페이지에 특정 영역이 계속 표시되는 것은 콘텐츠가 기본 문서에 이미 포함됐거나 앱에 캐시되어 있기 때문일 수 있습니다. 요청이 거부된 뒤에도 화면에 고정 높이의 컨테이너가 남을 수 있습니다. 이런 시각적 잔여물을 없애려고 기본 도메인이나 정적 리소스 도메인까지 차단하는 규칙을 계속 추가하지 마세요. 규칙은 연결 경로를 처리할 뿐, 페이지 요소를 숨기지는 않습니다.

규칙 추가부터 검증까지: 한 번에 하나만 테스트

수정하기 전에 Config에서 복구할 수 있도록 원본 설정을 보관하고, 기존 Global Routing, 선택된 출구, 테스트할 페이지를 기록하세요. 설정이 원격으로 관리되거나 업데이트되는 경우 이후 업데이트가 로컬 수정을 덮어쓸 수 있는지도 확인합니다. 사용 중인 서비스와 구독은 각자 제공하는 콘텐츠에 관한 것이며, 이 글에서는 로컬 규칙을 테스트하는 방법만 설명합니다.

  1. 기준 상태를 기록합니다. REJECT를 추가하지 않은 상태에서 대상 페이지를 열고 로그인, 이미지, API가 정상 작동하는지 기록하세요. 기존 오류를 새 규칙의 영향으로 간주하지 마세요.
  2. 설정을 수정합니다. Config에서 현재 사용 중인 설정을 열어 편집하고, 규칙 섹션에 정확한 DOMAIN 규칙 하나를 추가하세요. 먼저 매칭될 수 있는 포괄 규칙보다 앞에 배치합니다.
  3. 활성 상태를 확인합니다. 수정 내용을 저장하고 현재 설정을 확인한 뒤 Home으로 돌아가 Global Routing → Config인지 확인하세요. 활성화되지 않은 사본만 저장하지 않도록 주의합니다.
  4. 연결을 다시 만듭니다. 필요한 경우 Home의 연결 스위치를 껐다가 다시 켠 다음 대상 앱에서 요청을 다시 보내세요. 현재 연결이 일시적으로 끊기므로 진행 중인 작업이 없을 때 수행해야 합니다.
  5. 근거를 확인합니다. 앱에서 확인할 수 있는 연결 또는 요청 기록을 열어 같은 시각의 대상 도메인과 처리 정책을 찾으세요. 상세 정보에 매칭된 규칙이 표시되면 함께 기록합니다. 대상 요청 기록이 없다면 성급하게 결론을 내려서는 안 됩니다.
  6. 기능을 다시 테스트합니다. 일반 페이지 표시, 로그인, 검색, 이미지 로딩 등 관련 기능을 확인하세요. 대상 연결은 거부되고 필수 기능은 정상 작동하는 경우에만 규칙을 유지합니다.

응답 속도가 빨라진 것만을 유일한 근거로 삼지 말고, 한 번의 시간 초과를 규칙 매칭과 동일시하지 마세요. 같은 페이지의 리소스도 캐시, 로그인 상태, 서버 응답에 따라 달라집니다. 대상 요청과 실제 정책을 함께 확인하고 규칙을 되돌린 결과까지 비교해야 신뢰할 수 있습니다.

페이지에 문제가 생기면 최소 범위부터 되돌리세요

오차단은 로그인 인증 도메인, 이미지 서비스, 공유 API, 앱 시작에 필요한 설정 요청에서 자주 발생합니다. 버튼이 반응하지 않거나 콘텐츠가 계속 로딩되거나 로그인이 반복해서 이동하는 정도로 보일 수 있지만, 실제로는 백그라운드에서 필요한 연결이 거부됐을 수 있습니다. 원인을 확인하려면 “수정 규칙”을 더 추가하기보다 가장 최근에 추가한 규칙부터 되돌리세요.

규칙 추가 후 로그인 화면에서 계속 로딩됩니다. 먼저 무엇을 확인해야 하나요?

Config에서 가장 최근에 추가한 REJECT 규칙을 되돌리고 저장한 다음 연결을 다시 만든 뒤 로그인을 반복해 보세요. 정상으로 돌아오면 로그인 중 요청된 도메인을 확인하세요. 지나치게 넓은 DOMAIN-SUFFIX 규칙을 확인된 도메인 하나에 대한 DOMAIN 규칙으로 좁히고, 모든 요청을 무조건 허용하지는 마세요.

규칙을 추가했는데도 대상에 계속 접속할 수 있나요?

먼저 Home의 Global Routing이 Config인지, Config에서 올바른 파일이 활성화되어 있는지, 앞선 DIRECT 또는 PROXY 규칙이 먼저 매칭되는지 차례로 확인하세요. 그런 다음 대상 페이지를 새로고침해 캐시와 기존 연결의 영향을 배제하고 실제 요청의 도메인이 달라졌는지 확인합니다.

요청이 거부됐는데 페이지에 빈 영역이 남는 이유는 무엇인가요?

빈 영역은 페이지 레이아웃에 원래 포함된 컨테이너일 수 있습니다. 연결 기록에서 REJECT를 확인했다면 차단 범위를 더 넓히지 마세요. 기본 페이지 도메인까지 거부하면 정상적인 본문도 로드되지 않을 수 있습니다.

FINAL을 REJECT로 바꿔 규칙을 하나씩 작성하지 않아도 되나요?

FINAL,REJECT는 특정 불필요 리소스만이 아니라 앞선 규칙에 매칭되지 않은 모든 연결을 거부합니다. 검증을 마친 허용 목록을 완전하게 관리하는 경우가 아니라면 기존 FINAL을 유지하세요. 문제를 확인할 때는 기본 정책을 임시로 바꾸기보다 원본 설정을 복구하는 편이 안전합니다.

규칙을 되돌려도 문제가 계속되면 수정 전 보관한 설정 전체를 복구하고, 현재 활성화된 파일과 연결 상태, 대상 서비스 자체의 정상 작동 여부를 확인하세요. 특정 규칙이 있을 때만 문제가 재현되는 것이 확인되면 해당 규칙의 범위를 더 좁히세요. 예외가 필요하다면 정확한 규칙을 포괄적인 REJECT보다 앞에 두고, 해당 대상에 원래 필요한 DIRECT 또는 PROXY를 사용하세요. 모든 예외를 무조건 DIRECT로 바꾸지 마세요.