Shadowrocket 규칙 사용법: DOMAIN, DOMAIN-SUFFIX, DOMAIN-KEYWORD, GEOIP, IP-CIDR, FINAL 매칭 순서

1. 규칙 적용 전 확인: Global Routing과 구성 파일

규칙은 구성 파일의 [Rule] 섹션에 작성합니다. 요청이 구성에 따른 라우팅 경로로 처리될 때만 이 섹션의 순서를 바꾸는 의미가 있습니다. 먼저 Home → Global Routing에서 현재 선택 항목을 확인하세요. 화면 상단의 연결 스위치만 보고 규칙 적용 여부를 판단하지 마세요.

Config에서는 구성 파일을 관리하고, Home에서는 연결 상태와 Global Routing을 확인합니다. Settings → On Demand에서는 조건에 따라 연결을 시작하는 동작을 설정합니다. 이 기능은 DOMAIN을 다른 매칭 유형으로 바꾸거나 규칙 순서를 대신 관리하지 않습니다. 문제를 확인할 때는 ‘연결이 시작되었는지’와 ‘요청이 어떤 규칙에 매칭되었는지’를 따로 기록하세요.

2. DOMAIN, DOMAIN-SUFFIX, DOMAIN-KEYWORD의 매칭 범위

이 세 가지 규칙은 도메인을 확인합니다. 웹페이지의 본문을 검사하거나 URL 경로에 따라 라우팅하지는 않습니다. 규칙의 도메인 필드에는 https://나 /login을 넣지 말고, 포트 번호도 호스트 이름에 포함하지 마세요. https://api.example.com:8443/login에 접속할 때 도메인 매칭 대상은 api.example.com입니다.

DOMAIN은 특정 호스트 이름 하나를 따로 처리할 때 적합합니다. DOMAIN-SUFFIX는 도메인 계층에 따라 루트 도메인과 하위 도메인을 함께 매칭합니다. example.com으로 작성하면 되며 *.example.com으로 쓸 필요는 없습니다. DOMAIN-KEYWORD는 도메인에 포함된 키워드를 확인합니다. 같은 루트 도메인보다 적용 범위가 넓어 이름만 비슷하고 관계없는 도메인까지 함께 매칭될 수 있습니다.

3. GEOIP와 IP-CIDR: 도메인 문자열이 아닌 대상 IP 매칭

GEOIP는 대상 IP가 지리 위치 데이터베이스에서 어느 지역으로 분류되는지에 따라 매칭합니다. 예를 들어 GEOIP,CN,DIRECT는 데이터베이스에서 CN으로 분류된 대상 주소에 DIRECT를 적용한다는 뜻입니다. 웹사이트의 언어, 도메인 접미사 또는 사용자의 위치를 기준으로 판단하지 않으며, 데이터베이스상의 지역이 웹사이트 운영 주체의 소재지를 의미하는 것도 아닙니다.

IP-CIDR은 IPv4 주소 범위를 매칭합니다. 192.0.2.0/24는 앞의 24비트가 고정된 네트워크로, 192.0.2.0부터 192.0.2.255까지 포함합니다. 192.0.2.8/32는 주소 하나만 포함합니다. 이 주소는 문서 예시용 범위이므로 실제 서비스 연결 확인에 사용할 수 없습니다.

IP-CIDR,192.0.2.8/32,REJECT,no-resolve
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

• no-resolve는 이 IP 규칙과 매칭하기 위해 도메인 조회를 새로 수행하지 말라는 뜻입니다. 이미 사용할 수 있는 대상 IP가 있다면 주소 매칭은 계속 가능합니다.
• 도메인 요청이 IP 정보가 필요한 규칙에 도달하면 DNS 조회가 이후 판단에 영향을 줄 수 있습니다. 조회에 실패했다고 해서 규칙 키워드의 철자가 틀렸다는 뜻은 아닙니다.
• 웹사이트가 여러 주소를 반환할 수 있고 주소가 바뀌기도 합니다. 일시적으로 조회된 IP 하나를 규칙에 넣어도 웹사이트 전체를 대상으로 하는 것은 아닙니다.
• IP-CIDR은 IPv4용입니다. IPv6 주소를 이 키워드에 넣고 IPv4 마스크를 그대로 사용하지 마세요.

위 예시에서는 단일 주소 규칙이 전체 네트워크 규칙보다 앞에 있습니다. 따라서 대상이 192.0.2.8이면 먼저 REJECT에 매칭되며, 뒤에 있는 네트워크 규칙의 DIRECT에는 도달하지 않습니다. 이는 작성 순서에 따른 결과이지 시스템이 /32에 자동으로 더 높은 우선순위를 부여해서가 아닙니다.

4. 위에서부터 순서대로 매칭하고 FINAL은 마지막에 배치

여기서 설명하는 일반 규칙은 위에서부터 확인하고, 매칭되면 해당 정책을 적용한 뒤 뒤쪽의 일반 규칙으로 다시 판단하지 않습니다. 더 구체적인 규칙이라고 해서 앞에 있는 포괄적인 규칙을 자동으로 건너뛰지 않습니다. 예외를 적용하려면 해당 규칙을 앞쪽에 배치하세요.

[Rule]
DOMAIN,login.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN-KEYWORD,telemetry,REJECT
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

1. login.example.com 요청은 첫 번째 규칙에 매칭되므로 DIRECT가 적용됩니다.
2. img.example.com 요청은 첫 번째 규칙에는 매칭되지 않고 두 번째 규칙에 매칭되므로 PROXY가 적용됩니다.
3. telemetry.example.com 요청은 두 번째 규칙에 먼저 매칭되므로 세 번째 규칙은 실행되지 않습니다. 이 요청을 거부하려면 해당 거부 규칙을 두 번째 규칙보다 앞에 배치하세요.
4. 앞선 규칙에 매칭되지 않은 요청은 마지막으로 FINAL,PROXY에 적용됩니다. FINAL에는 도메인이나 주소 필드가 없으며 키워드와 정책만 작성합니다.

FINAL을 앞쪽에 두면 뒤에 있는 일반 규칙은 확인되지 않습니다. 구성을 관리할 때는 명확한 최종 기본 규칙 하나만 남기고 마지막에 배치하세요. 순서 문제를 해결하려고 같은 규칙을 계속 추가하지 말고, 앞에서 먼저 매칭된 규칙이 무엇인지 확인하세요.

위 구성은 매칭 순서를 설명하기 위한 것이며 범용 라우팅 규칙 목록이 아닙니다. 기존 구성에 적용하기 전에 각 정책이 필요한 동작과 일치하는지 확인하고 원본 구성을 복사해 두세요.

5. PROXY, DIRECT, REJECT의 역할

규칙에서 마지막 주요 필드는 매칭 후 처리 방식을 결정합니다. 키워드는 ‘무엇을 매칭할지’, 정책은 ‘어떻게 처리할지’를 지정하므로 서로 바꿔 쓸 수 없습니다. 이 글은 사용자가 이미 자신의 서비스 제공업체와 연결 구성을 보유하고 있음을 전제로 합니다. 노드, 구독 또는 기타 연결 서비스는 제공하거나 판매하거나 추천하지 않습니다.

PROXY는 프로토콜 이름이 아닙니다. Shadowsocks, VMess, VLESS, Trojan, Hysteria2, WireGuard는 연결 구성에 사용되는 프로토콜이며, 여기서 설명하는 기본 정책 표기 대신 사용할 수 없습니다. 규칙이 PROXY에 매칭되어도 대상 서비스에 연결할 수 있다는 뜻은 아닙니다. 연결 매개변수, DNS, 원격 서버 상태를 각각 확인해야 합니다.

DIRECT는 Shadowrocket의 규칙 판단을 거치지 않는다는 뜻이 아닙니다. 규칙에 매칭된 뒤 직접 연결을 선택한다는 의미입니다. REJECT로 페이지나 리소스 로드가 실패하는 것은 의도된 동작일 수 있습니다. 로그인 API가 잘못 거부된 경우 페이지 본문이 열려도 사이트 기능 전체가 정상이라는 뜻은 아닙니다.

6. Config에서 수정하고 새 요청으로 확인

한 번에 규칙 하나 또는 순서 한 곳만 수정하고, 결과를 확인한 다음 다음 변경을 진행하세요. 구독 업데이트는 주로 사용자가 보유한 서버 목록과 관련되며, 현재 활성화된 구성의 [Rule] 섹션을 수정하는 것과는 다릅니다. 원격 구성을 다시 업데이트하면 로컬 변경 사항이 덮어써질 수도 있으므로 테스트 전에 복사본을 저장하세요.

1. 원본 구성 보관

   Config로 이동해 현재 활성화된 파일을 확인한 뒤 복원할 수 있는 복사본을 먼저 저장하세요. 원래 Global Routing 설정도 기록해 테스트가 끝난 뒤 되돌리는 것을 잊지 않도록 합니다.

2. 규칙 섹션 편집

   Config에서 대상 파일의 편집 화면을 열고 [Rule]을 찾으세요. 단일 호스트 예외는 도메인 접미사 규칙보다 앞에 두고 FINAL은 마지막에 배치합니다. 필드는 영문 반각 쉼표로 구분하세요.

3. 활성화 여부 확인

   저장한 뒤 Config에서 수정한 파일이 활성화되어 있는지 확인하세요. Home → Global Routing으로 돌아가 Config를 선택하고 Home에서 연결 상태를 확인합니다.

4. 요청 다시 보내기

   테스트 페이지를 닫았다가 다시 열고, 필요하면 연결을 새로 설정해 기존 장시간 연결을 재사용하지 않도록 하세요. 연결 기록에서 확인할 수 있는 대상 도메인, 대상 IP, 매칭 규칙, 정책 정보를 살펴보세요.

5. 매칭 항목 확인

   적용된 정책이 예상과 다르면 매칭된 위치에서 위쪽으로 이동하며 더 포괄적인 규칙을 확인하세요. 규칙은 예상대로 매칭되지만 접속에 실패한다면 DNS, 기존 프록시 매개변수, 대상 서비스를 확인하세요. 순서를 무작정 계속 바꾸지 마세요.

7. 규칙 미적용과 접속 오류를 나누어 확인

먼저 ‘예상한 규칙에 매칭되지 않은 경우’와 ‘규칙에는 매칭됐지만 연결에 실패한 경우’를 구분하세요. 전자는 Global Routing, 현재 파일, 규칙 순서를 우선 확인하고, 후자는 이름 조회와 연결 과정을 확인합니다. Home → Connectivity Test 결과만으로 특정 도메인의 모든 웹 요청이 정상적으로 완료된다고 단정할 수는 없습니다.

이 내용은 Apple 네트워크 오류 코드의 의미를 설명하며, Shadowrocket의 모든 화면에 동일한 고정 문구가 표시된다는 뜻은 아닙니다. 기록에 해당 코드가 없다면 실제 오류 메시지를 기준으로 확인하세요. 페이지가 계속 로딩된다는 이유만으로 같은 오류로 분류하지 마세요.