Shadowrocket 규칙 종류와 작성법: DOMAIN-SUFFIX, GEOIP, IP-CIDR, FINAL

이 글 한눈에 보기

Shadowrocket의 Rule은 가장 정밀한 항목을 자동으로 우선 적용하지 않습니다. Config에 적힌 순서대로 매칭합니다. 직접 사용할 서비스와 연결 설정이 있고 트래픽 분기 규칙을 조정하려는 사용자를 위한 안내입니다. 먼저 Global Routing이 Config로 설정되어 있는지 확인하고, 도메인 규칙과 IP 규칙을 구분한 뒤 FINAL을 마지막에 둡니다. 규칙을 작성하고 하나씩 검증하는 방법과 ‘매칭되지 않은 경우’와 ‘매칭 후 연결에 실패한 경우’를 구별하는 방법을 알아봅니다.

먼저 규칙 적용 조건 확인

Home에서 Global Routing을 확인한 다음 Config를 편집하세요. Config를 사용하면 요청은 현재 활성화된 설정 파일의 규칙에 따라 분기됩니다. Proxy와 Direct는 전역 처리 방식이 서로 다르므로, 이를 선택한 상태에서는 직접 작성한 Rule의 적용 여부를 확인할 수 없습니다. Scene은 설정된 조건에 따라 처리되며 특정 Config 하나만 계속 사용하는 방식과는 다릅니다. 문제를 확인하는 동안에는 Config로 고정해 Scene 변경이 판단에 영향을 주지 않도록 하세요.

6종

이 문서에서 다루는 Rule 유형이며, 전체 유형은 아닙니다

3종

도메인 매칭: DOMAIN, DOMAIN-SUFFIX, DOMAIN-KEYWORD

4가지

Global Routing：Proxy / Direct / Config / Scene

Home에서 사용할 수 있는 연결 설정이 있는지 확인하고 연결을 켭니다. 시스템 VPN 설정을 처음 생성할 때는 시스템 안내에 따라 권한을 허용하세요.
Config로 이동해 현재 활성화된 파일을 확인합니다. 편집하기 전에 복사본을 보관해 원격 파일 업데이트 내용과 로컬 변경 사항이 섞이지 않도록 하세요.
Home으로 돌아가 Global Routing을 Config로 설정합니다. 변경 사항을 저장한 다음 화면 안내에 따라 다시 불러오거나 연결을 새로 설정하세요.
테스트할 앱의 기존 연결을 끊고 새 요청을 보냅니다. 이미 연결된 장시간 연결은 규칙 한 줄을 수정해도 즉시 경로가 바뀌지 않는 경우가 많습니다.

Home에서는 연결과 서비스 항목을 관리하고, Config에는 설정 파일이 있으며, Settings에는 전역 설정이 있습니다. Settings → On Demand는 조건에 따라 연결을 언제 설정할지 제어합니다. 특정 도메인을 어떤 Rule에 지정하는 기능은 아닙니다. 연결을 끊은 뒤 다시 자동으로 연결된다면 FINAL을 반복해서 수정하기보다 여기부터 확인하세요.

먼저 규칙을 매칭한 뒤 정책 실행

일반적인 규칙은 유형, 매칭 값, 정책으로 구성되며 영문 반각 쉼표로 구분합니다. 예를 들어 DOMAIN,api.example.com,DIRECT는 도메인이 정확히 api.example.com일 때 DIRECT를 실행한다는 뜻입니다. FINAL에는 매칭 값이 없으므로 FINAL,PROXY처럼 작성합니다. 세 항목으로 만들지 마세요.

새 요청 전송 대상 정보 확인 규칙 순서대로 매칭 매칭된 정책 실행 아웃바운드 연결 설정

요청이 앞쪽 규칙과 매칭되면 뒤에서 ‘더 정확한’ 규칙을 찾지 않습니다. DOMAIN-SUFFIX,example.com,PROXY가 앞에 있고 DOMAIN,api.example.com,DIRECT가 뒤에 있다면, 뒤의 규칙은 해당 도메인에 예외로 적용되지 않습니다. 예외 규칙을 더 넓은 범위의 규칙보다 앞에 배치하세요.

도메인 규칙 세 가지

도메인 규칙은 전체 URL이 아니라 호스트 이름을 대상으로 합니다. 매칭 필드에 https://, 경로 /login, 쿼리 매개변수 또는 포트 :443를 입력하지 마세요. 아래의 example.com은 문서용 예시이며 실제로 설정해야 하는 서비스가 아닙니다.

유형 및 작성법	매칭 범위	혼동하기 쉬운 점
`DOMAIN,api.example.com,DIRECT`	api.example.com만 매칭	example.com 및 img.api.example.com은 매칭하지 않음
`DOMAIN-SUFFIX,example.com,PROXY`	example.com과 하위 도메인을 매칭	notexample.com은 매칭하지 않음. 도메인 경계가 중요
`DOMAIN-KEYWORD,example,PROXY`	호스트 이름에 example이 포함된 요청을 매칭	example.net과 notexample.com도 매칭될 수 있어 범위가 더 넓음

API 하나의 연결 경로만 바꾸려면 DOMAIN을 우선 사용하세요. 같은 주 도메인의 리소스 도메인까지 적용하려면 DOMAIN-SUFFIX를 사용하고, 부분 문자열 매칭이 꼭 필요한 경우에만 DOMAIN-KEYWORD를 사용하세요. 키워드 규칙은 사이트의 소속 관계를 판단하지 않습니다. 짧은 단어를 사용하면 관련 없는 도메인까지 영향을 받을 수 있어 문제 범위를 파악하기도 어려워집니다.

[Rule]
DOMAIN,api.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN-KEYWORD,media-sample,PROXY
FINAL,DIRECT

이 예시에서는 api.example.com이 먼저 DIRECT와 매칭되고, img.example.com은 접미사 규칙과 매칭됩니다. 앞선 조건에 해당하지 않는 요청에는 마지막의 FINAL인 DIRECT가 적용됩니다. 첫 번째 줄을 접미사 규칙 뒤로 옮기면 API 예외가 적용되지 않습니다. 규칙 순서만 바꿔도 결과가 달라지며 DNS나 연결 매개변수를 함께 변경할 필요는 없습니다.

GEOIP와 IP-CIDR

GEOIP는 대상 IP가 로컬 지리 데이터베이스에 등록된 위치를 기준으로 매칭합니다. GEOIP,CN,DIRECT는 CN으로 분류된 대상 IP에 DIRECT를 적용한다는 뜻입니다. 웹페이지 언어, 도메인 접미사 또는 서비스 제공업체의 등록 지역을 기준으로 판단하지 않습니다. 같은 도메인도 지역이 다른 IP로 해석될 수 있으므로 결과는 IP 해석 결과와 데이터베이스 내용에 따라 달라집니다.

IP-CIDR은 IPv4 주소 범위를 직접 매칭합니다. 192.168.0.0/16은 192.168.0.0부터 192.168.255.255까지를 포함하며, 10.20.30.40/32는 IPv4 주소 하나만 나타냅니다. 마스크는 주소 범위를 지정하는 값이지 포트 범위나 호스트 수를 나타내는 매개변수가 아닙니다.

IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
IP-CIDR,10.20.30.40/32,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

IP 주소로 직접 접속: 192.168.1.20에 접속하면 대상 주소가 명확하므로 네트워크 범위 규칙으로 판단할 수 있습니다. 프로토콜 포트가 80인지 443인지는 해당 네트워크 규칙의 적용 범위를 바꾸지 않습니다.
도메인으로 접속: IP 규칙을 적용하려면 도메인 해석이 필요할 수 있습니다. no-resolve는 해당 IP 규칙을 위해 도메인 해석을 능동적으로 실행하지 않는다는 뜻입니다. 모든 DNS를 차단하거나 이미 확인된 IP의 매칭을 막는다는 의미는 아닙니다.
IPv6 요청: IPv4용 IP-CIDR로 IPv6 주소를 매칭할 수 없습니다. 문제를 확인할 때는 실제 대상 주소의 IP 버전도 기록하세요. IPv4 네트워크 범위를 올바르게 작성했다고 해서 모든 요청이 매칭되는 것은 아닙니다.
로컬 네트워크 예외: 전역 프록시가 로컬 기기 접속에 영향을 준다면, 범위가 명확한 로컬 네트워크 규칙을 넓은 범위의 정책보다 앞에 배치할 수 있습니다. 실제로 필요한 네트워크 범위만 추가하세요.

웹사이트가 특정 지역에 속한다는 이유만으로 GEOIP가 반드시 매칭된다고 판단하지 마세요. 콘텐츠 전송 네트워크는 같은 도메인에도 여러 대상 IP를 반환할 수 있고, 앱이 캐시된 주소를 사용할 수도 있습니다. 새 요청의 대상 주소를 확인한 뒤 지리 규칙이 예상대로 적용되는지 판단하세요.

FINAL과 전체 규칙 순서

FINAL은 앞선 규칙과 매칭되지 않은 요청에 적용되는 기본 규칙이지, 연결 실패 후 다시 시도하는 스위치가 아닙니다. 앞선 규칙이 PROXY를 선택했는데 해당 아웃바운드 연결이 시간 초과되더라도 요청이 규칙을 건너뛰고 FINAL에 따라 DIRECT로 바뀌지는 않습니다. 선택된 아웃바운드 연결이나 규칙 선택을 바로잡아야 하며 마지막 규칙을 추가하는 것으로 해결되지 않습니다.

[Rule]
DOMAIN,api.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN-KEYWORD,media-sample,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

구체적인 예외를 먼저 배치하세요. API 단일 도메인 규칙을 같은 사이트의 도메인 접미사 규칙보다 앞에 두어 예외가 적용되게 합니다.
그다음 도메인 범위를 지정하세요. 먼저 알려진 사이트의 연결 경로를 정한 뒤 IP 범위를 처리하면, 지역 분류가 바뀌어도 지정한 사이트에 미치는 영향을 줄일 수 있습니다.
주소 규칙을 배치하세요. 로컬 네트워크 범위와 GEOIP 규칙에도 순서가 적용됩니다. 규칙의 범위가 겹친다면 우선 적용할 조건을 앞에 두세요.
마지막에는 기본 규칙을 둡니다. FINAL을 맨 마지막에 배치하세요. 분류되지 않은 요청에 DIRECT와 PROXY 중 무엇을 적용할지는 다른 사람의 설정을 그대로 따르지 말고 원하는 처리 방식에 따라 결정하세요.

증상별 규칙 분기 문제 확인

한 번에 하나만 변경하고 같은 대상으로 새 요청을 보내세요. 확인할 수 있는 연결 기록이나 로그에서는 대상 도메인, 실제 IP, 매칭된 규칙, 최종 정책을 우선 기록합니다. 로그에서 일부 정보만 확인할 수 있다면 그 정보를 바탕으로 범위를 좁히세요. 페이지가 열리지 않는다는 이유만으로 규칙 작성 오류라고 단정하지 마세요.

오류: `Connection timed out`

원인 및 해결 방법: 제한 시간 안에 연결이 완료되지 않은 상태로, 대상이나 연결 경로 또는 아웃바운드 서비스가 원인일 수 있습니다. 먼저 매칭된 정책을 확인한 다음 Home의 Connectivity Test로 현재 연결을 점검하고 같은 대상을 향한 다른 요청과 비교하세요. 시간 초과만으로 DOMAIN-SUFFIX 문법이 잘못됐다고 판단할 수는 없습니다.

오류: `Connection refused`

원인 및 해결 방법: 대개 대상 측이나 중간 장치가 연결을 명시적으로 거부했다는 뜻입니다. 요청 대상 포트와 사용 중인 서비스의 포트 설정을 확인하세요. 서비스가 443만 수신 대기하는데 8443으로 연결하려는 경우 연결 매개변수를 수정해야 합니다. FINAL 기본 규칙을 조정해도 해결되지 않습니다.

위의 영문 문구는 네트워크 오류를 나타내며 로그에 따라 실제 표시 방식이 다를 수 있습니다. 오류는 없는데 연결 경로만 예상과 다르다면 먼저 Proxy 또는 Direct가 선택되어 있는지 확인하세요. 다음으로 편집한 파일이 현재 활성화된 Config인지 확인하고, 마지막으로 첫 번째 Rule부터 더 앞에서 매칭된 조건이 있는지 살펴보세요.

“규칙을 추가했는데 왜 연결 경로가 그대로인가요?”

먼저 Home에서 Global Routing을 Config로 고정한 뒤 Config에서 활성화된 파일을 확인하세요. 단일 도메인 예외를 넓은 범위의 접미사 또는 키워드 규칙보다 앞에 배치합니다. 저장한 뒤 기존 연결을 닫고 같은 도메인에 다시 요청하세요. 기존 연결을 재사용하는 페이지를 새로고침하는 것만으로는 확인할 수 없습니다.

“GEOIP에 CN을 설정했는데 왜 중국어 사이트가 DIRECT로 연결되지 않나요?”

웹페이지 언어가 아니라 해당 요청이 실제로 연결한 IP를 확인하세요. 요청이 앞선 도메인 규칙과 이미 매칭됐다면 이후 판단에 GEOIP가 적용되지 않습니다. GEOIP까지 도달했다면 해당 IP의 데이터베이스상 지역 분류와 IP 해석 결과가 바뀌었는지 확인하세요.

“구독을 업데이트하면 사용자 지정 규칙도 함께 업데이트되나요?”

서비스 구독과 Config는 서로 다른 항목입니다. Home에서 기존 서비스 구독을 업데이트하면 주로 연결 항목이 갱신됩니다. 원격 설정을 업데이트하려면 Config에서 해당 파일을 대상으로 작업하세요. 구독 갱신이 완료됐다고 해서 로컬 Rule이 저장되거나 활성화됐다고 볼 수는 없습니다.

“프로토콜을 바꾸면 DOMAIN-SUFFIX도 다시 작성해야 하나요?”

프로토콜을 변경했다고 해서 자동으로 다시 작성할 필요는 없습니다. Shadowsocks, VMess, VLESS, Trojan, Hysteria2, WireGuard는 연결 프로토콜 계층에 속하고 도메인 규칙은 적용할 정책을 선택합니다. 기존 정책이 여전히 유효한 연결 항목을 가리키는지 확인한 다음 사용 중인 서비스의 설정에 맞춰 프로토콜 연결을 점검하세요.

저장 전 항목별 확인

안정적인 규칙 분기 설정이라면 세 가지를 설명할 수 있어야 합니다. 이 규칙이 무엇과 매칭되는지, 왜 이 위치에 배치했는지, 매칭 후 어떤 정책을 적용하는지입니다. 설명하기 어려운 키워드를 한꺼번에 많이 추가하기보다 명확한 규칙 몇 개부터 관리하고 차근차근 늘리는 편이 문제를 찾기 쉽습니다. 이 사이트에서는 클라이언트 설정 방법을 안내하며 노드나 구독 서비스를 제공하거나 판매 또는 추천하지 않습니다.

유형, 쉼표, 정책 이름을 올바른 영문 형식으로 작성했으며 도메인 필드에 프로토콜, 경로, 포트가 없습니다.
DOMAIN 예외를 이를 포함하는 DOMAIN-SUFFIX 또는 DOMAIN-KEYWORD보다 앞에 배치했습니다.
IP-CIDR의 주소 버전과 네트워크 범위가 올바릅니다. no-resolve가 DNS 설정을 대신하지 않는다는 점을 확인했습니다.
FINAL이 마지막에 있으며 분류되지 않은 요청에 DIRECT와 PROXY 중 무엇을 적용할지 정했습니다.
수정한 Config가 현재 활성화되어 있고 Global Routing은 Config로 설정되어 있습니다. 새 연결을 만들어 결과를 확인했습니다.