Config로 라우팅을 설정하고 특정 대상에 대한 연결을 차단하려는 사용자를 위한 안내입니다. 먼저 REJECT가 적용되는 위치를 확인한 다음, 정확한 도메인·도메인 접미사·대상 IP를 기준으로 규칙을 작성하세요. 마지막으로 연결 기록에서 규칙이 매칭됐는지와 오차단 여부를 확인합니다. 예시 도메인은 문법 설명용이며, 실제 대상은 본인의 요청 기록을 바탕으로 정해야 합니다.
REJECT의 역할: 매칭된 연결 차단
REJECT는 정책이지 독립적인 매칭 조건이 아닙니다. 규칙 앞부분에서 대상이 조건에 맞는지 판단하고, 끝의 REJECT가 매칭된 요청의 처리 방식을 지정합니다. 예를 들어 DOMAIN,metrics.example.com,REJECT는 전체 도메인을 기준으로 매칭한 뒤 해당 요청을 거부한다는 뜻입니다. 모든 통계 서비스를 자동으로 식별하거나 도메인 목록을 자동 생성하지는 않습니다.
이 흐름은 요청이 Shadowrocket의 처리 범위에 들어오고 현재 규칙 라우팅을 사용한다는 전제입니다. REJECT는 대상에 전체 내용을 보낸 뒤 응답 페이지를 숨기는 방식이 아니라, 연결 처리 단계에서 이후 통신을 차단합니다. 요청을 보낸 앱에는 연결 실패, 재시도 또는 시간 초과가 표시될 수 있습니다. 구체적인 동작은 앱의 처리 방식에 따라 다르므로 화면에 나타난 안내만으로 어떤 규칙이 적용됐는지 판단할 수는 없습니다.
규칙은 일반적으로 위에서 아래로 매칭되며, 처음 매칭된 규칙의 정책이 적용됩니다. 따라서 “REJECT를 작성했다”는 것과 “요청에 실제로 REJECT가 적용됐다”는 것은 다릅니다. 앞에서 더 넓은 허용 규칙이 먼저 매칭되면 뒤의 차단 규칙은 해당 요청을 처리할 기회가 없습니다. 문제를 확인할 때는 대상, 규칙 순서, 현재 적용 중인 설정을 함께 살펴보세요.
먼저 Config를 확인한 뒤 범위를 좁혀 규칙 추가
Home의 Global Routing에서 Config를 선택하고, Config에서 현재 사용 중인 설정 파일을 확인합니다. Proxy와 Direct는 이 단계를 대신할 수 없습니다. Scene을 사용 중이라면 현재 장면에서 실제로 어떤 설정과 라우팅 방식이 적용되는지도 확인해야 합니다. 설정 파일에 REJECT가 있다는 이유만으로 실제 적용 중이라고 단정하지 마세요.
- Config에서 현재 설정의 사본을 보관하고 기존 규칙 순서와
FINAL정책을 기록해 두면 필요할 때 복원하기 쉽습니다. - 사용 중인 설정을 열고 편집 메뉴에서
[Rule]구역을 찾습니다. 먼저 전체 도메인을 대상으로 하는 규칙 하나를 추가하고, 처음부터 도메인 그룹 전체로 범위를 넓히지는 마세요. - 더 넓은 규칙이 먼저 매칭될 수 있는 위치보다 앞에 이 규칙을 배치하되, 서비스에 필요한 정확한 예외는 유지하세요.
- 설정을 저장하고 계속 사용 중인지 확인합니다. 대상 앱의 기존 연결을 종료한 뒤 같은 동작을 다시 실행하세요.
- 이번 연결의 대상과 적용된 정책을 확인합니다. 새 요청에 실제로
REJECT가 적용된 경우에만 차단 경로가 올바르게 작동한다고 볼 수 있습니다.
설정이 원격 소스에서 업데이트된다면 이후 업데이트로 로컬 수정 사항이 덮어써질 수 있는지 먼저 확인하세요. 구독과 노드는 이용 중인 서비스 제공업체에서 받습니다. 서버 구독 업데이트와 Config 규칙 수정은 서로 다른 작업이며, 서버 목록을 새로고침했다고 새 규칙이 적용됐다는 뜻은 아닙니다.
DOMAIN, DOMAIN-SUFFIX, IP-CIDR 작성법
대상을 포함하는 조건 중 범위가 가장 좁은 것을 우선 선택하세요. 전체 도메인은 단일 호스트에, 도메인 접미사는 함께 처리해야 하는 특정 도메인과 하위 도메인에 적합합니다. IP 대역은 주소 범위를 확인한 대상에 사용하세요. 도메인 필드에는 https://, 경로, 쿼리 매개변수 또는 포트를 입력하지 않습니다.
도메인 기준 매칭
- 전체 도메인
DOMAIN,metrics.example.com,REJECT- 도메인 접미사
DOMAIN-SUFFIX,metrics.example.com,REJECT- 매칭 범위 비교
- 전자는 지정된 호스트만 매칭하고, 후자는 해당 호스트의 하위 도메인도 매칭합니다.
접미사는 도메인 계층을 기준으로 매칭하며, 임의의 문자열 포함 여부를 검사하지 않습니다.
대상 IP 기준 매칭
- 단일 IPv4 주소
IP-CIDR,192.0.2.8/32,REJECT- IPv4 대역
IP-CIDR,192.0.2.0/24,REJECT- 예시 용도
- 여기에는 문서용 예시 주소를 사용했으며 실제 차단 대상을 나타내지 않습니다.
실제 연결 주소를 확인해 범위를 판단하고, 공유 주소를 하나의 서비스 전용 주소로 오인하지 마세요.
DOMAIN-SUFFIX,metrics.example.com,REJECT는 metrics.example.com과 img.metrics.example.com에 매칭되지만 othermetrics.example.com에는 매칭되지 않습니다. *.metrics.example.com으로 작성할 필요도 없습니다. 와일드카드는 이 규칙의 접미사 매개변수 문법이 아닙니다.
IP 규칙과 도메인 규칙은 같은 의미가 아닙니다. 하나의 도메인이 여러 주소로 해석될 수 있고, 하나의 주소에서 여러 도메인이 서비스될 수도 있습니다. 클라이언트가 다른 주소나 IPv6를 사용할 수도 있습니다. 특정 IPv4 주소만 거부했다고 해서 관련 도메인의 모든 연결이 차단됐다고 볼 수는 없습니다. GEOIP는 주소의 지역 정보를 기준으로 매칭하므로 범위가 더 넓으며, 특정 도메인을 정밀하게 차단하는 용도로 대신 사용하기에는 적합하지 않습니다.
규칙 순서: 예외를 먼저, 차단은 다음, FINAL은 맨 끝에
아래 예시에서는 예외를 의도적으로 유지합니다. 지정한 호스트 하나는 직접 연결을 허용하고, 같은 접미사에 속한 나머지 호스트는 거부합니다. 예시의 PROXY는 설정에서 사용할 수 있는 정책 또는 정책 그룹 이름이어야 합니다. 현재 설정에서 다른 이름을 사용한다면 예시의 대체 규칙을 그대로 복사하지 말고 기존 FINAL 행을 유지하세요.
[Rule]
DOMAIN,health.metrics.example.com,DIRECT
DOMAIN-SUFFIX,metrics.example.com,REJECT
FINAL,PROXY| 요청 대상 | 먼저 매칭된 규칙 | 결과 |
|---|---|---|
health.metrics.example.com | 첫 번째 DOMAIN 규칙 | DIRECT 적용 |
img.metrics.example.com | 두 번째 DOMAIN-SUFFIX 규칙 | REJECT 적용 |
www.example.com | 마지막 FINAL 규칙 | 예시의 PROXY 적용 |
접미사 차단 규칙을 첫 번째 줄에 두면 상태 확인용 호스트에도 REJECT가 먼저 적용되어 뒤의 DOMAIN 예외로 허용할 수 없습니다. 반대로 차단 규칙보다 앞에 DOMAIN-SUFFIX,example.com,DIRECT를 추가하면 해당 대상이 먼저 허용됩니다. FINAL은 나머지 요청을 처리하므로 차단 규칙보다 앞에 두면 뒤의 규칙이 매칭될 기회를 잃습니다.
판단 기준: 예외가 필요하면 규칙 범위를 먼저 좁히기
필수 호스트의 정확한 규칙을 더 넓은 차단 규칙보다 앞으로 옮긴 뒤 다시 확인하세요. 오차단 하나를 해결하려고 모든 REJECT 규칙을 삭제하지 말고, 더 넓은 DIRECT 규칙으로 순서 문제를 덮지도 마세요.
차단 적용 범위와 한계
REJECT는 사용자가 더 이상 필요하지 않다고 확인한 독립 리소스 호스트처럼 도메인이나 주소로 구분할 수 있는 대상을 차단하는 데 적합합니다. 판단 대상은 연결 대상이지 페이지의 모든 시각 요소가 아니며, 모든 콘텐츠를 의미적으로 분석하는 기능도 아닙니다.
- 같은 도메인의 콘텐츠는 경로별로 구분할 수 없습니다: 필요한 요청과 원치 않는 리소스가 모두
api.example.com에서 제공된다면 DOMAIN 규칙은 둘 다 처리합니다. 이 규칙으로/metrics경로만 거부할 수는 없습니다. - HTTPS가 복호화되는 것은 아닙니다: REJECT는 암호화된 본문을 읽지 않으며 페이지 구조를 자동으로 파악하지도 않습니다. 리소스 연결을 차단해도 페이지 레이아웃에 해당 리소스를 위해 마련된 빈 공간까지 없어지는 것은 아닙니다.
- 캐시가 결과를 가릴 수 있습니다: 앱이 캐시된 이미지나 콘텐츠를 표시할 수 있으며, 이것만으로 방금 요청이 정상적으로 통과했다고 볼 수는 없습니다. 화면 변화만 보지 말고 새 연결 기록도 함께 확인하세요.
- 기존 연결은 별도로 확인해야 합니다: 규칙을 수정해도 이미 생성되어 재사용 중인 연결에는 새 규칙의 매칭 절차가 즉시 적용되지 않을 수 있습니다. 테스트할 때는 앱이 연결을 다시 만들도록 하세요.
- 대상이 달라질 수 있습니다: 대체 도메인으로 재시도하거나 주소가 바뀌고 공유 인프라를 사용하는 경우 차단 범위에 영향을 줄 수 있습니다. 전체 공유 네트워크를 바로 차단하지 말고 실제 기록을 근거로 확인하세요.
DNS 해석 실패와 REJECT 매칭은 구분해야 합니다. 전자는 대상 주소를 얻기 전에 발생할 수 있지만, 후자는 해당 규칙의 정책이 적용됐다는 근거가 있어야 합니다. 도메인에 접속할 수 없다는 이유만으로 REJECT가 원인이라고 단정하지 마세요. 또한 도메인 정보로 매칭할 수 있는지는 실제 요청과 해석 경로에 따라 달라집니다. 주소 정보만 있다면 연결 기록과 IP 관련 규칙을 함께 확인하고, 도메인 조건이 반드시 존재한다고 가정하지 마세요.
규칙이 적용되지 않거나 오차단될 때의 점검과 복원
확인할 때는 한 번에 변수 하나만 바꾸세요. 같은 앱, 같은 동작, 같은 네트워크 환경에서 변경 전후의 새 연결을 비교합니다. 아래 항목은 설정 사용 여부, 규칙 매칭 여부, 캐시가 결과를 가리고 있는지 순서대로 확인합니다.
규칙을 저장했는데도 대상에 접속할 수 있는 이유는 무엇인가요?
먼저 Home → Global Routing이 Config로 설정되어 있는지 확인한 다음, Config에서 실제로 사용 중인 파일을 살펴보세요. 이어서 대상의 새 연결이 앞에 있는 DIRECT, PROXY 또는 더 넓은 규칙에 먼저 매칭됐는지 확인합니다. 파일에 REJECT 행이 있는지만 확인해서는 안 됩니다.
REJECT에 매칭됐는데도 페이지에 기존 콘텐츠가 표시되는 이유는 무엇인가요?
대상 앱을 종료한 뒤 다시 열어 캐시된 화면과 새 요청을 구분하세요. 페이지가 다른 도메인에서 리소스를 다시 가져오는지 확인하고 해당 연결을 기록합니다. 캐시된 콘텐츠가 계속 표시된다고 해서 매칭된 요청이 허용됐다는 뜻은 아닙니다.
접미사 규칙을 추가한 뒤 로그인이나 이미지도 작동하지 않으면 어떻게 해야 하나요?
먼저 방금 추가한 규칙 하나를 비활성화한 뒤 다시 시도해 관련 여부를 확인하세요. 그런 다음 실패 기록에서 필요한 호스트를 찾아 더 좁은 DOMAIN 규칙으로 차단하거나, 접미사 규칙보다 앞에 정확한 허용 예외를 추가합니다. 상위 도메인 전체를 바로 허용하지 마세요.
설정을 업데이트한 뒤 기존 차단 규칙이 사라진 이유는 무엇인가요?
보관한 사본과 현재 설정의 [Rule] 구역을 비교해 로컬 수정 사항이 원격 내용으로 덮어써졌는지 확인하세요. 검증을 마친 최소한의 규칙을 다시 추가하고 기존 FINAL을 유지합니다. 서버 구독 새로고침을 규칙 복원 작업으로 간주하지 마세요.
되돌려야 한다면 마지막에 추가한 차단 행을 먼저 제거하고 저장한 뒤 대상에 새로 연결하세요. 여러 곳을 수정해 순서를 확인할 수 없다면 이전에 보관한 설정 사본을 복원합니다. 테스트 대상, 매칭된 규칙, 복원 결과를 기록해 두면 모든 설정을 반복해서 바꾸는 것보다 원인을 쉽게 찾을 수 있습니다.