Shadowrocket 규칙 설정 입문: DOMAIN, DOMAIN-SUFFIX, DOMAIN-KEYWORD, GEOIP, IP-CIDR, FINAL 매칭 기준

이 글의 핵심 내용

Shadowrocket은 규칙을 순서대로 확인하고, 일치하는 항목이 있으면 지정된 전략을 적용합니다. 사용 가능한 구성을 이미 갖추고 트래픽 라우팅을 조정하려는 사용자를 위한 안내입니다. iPhone/iPad의 Home 및 Config 화면을 기준으로 설명하며, 규칙 개념은 Mac, Windows, Android, Linux 버전에도 적용됩니다. 편집 메뉴는 플랫폼별 화면을 확인하세요. 읽고 나면 도메인과 IP 매칭의 차이를 이해하고, 최소한의 Rule 섹션을 작성한 뒤 연결 기록으로 매칭 결과를 확인할 수 있습니다.

1. 먼저 Global Routing이 Config인지 확인

규칙이 구성에 있어도 현재 연결이 규칙에 따라 라우팅된다는 뜻은 아닙니다. Home에서 Global Routing을 확인하세요. 현재 구성의 Rule을 적용하려면 Config를 선택합니다. Proxy는 모든 연결에 프록시 전략을 적용하고, Direct는 모든 연결을 직접 연결합니다. Scene은 상황별 선택 기능이며, 별도의 규칙 키워드가 아닙니다. 문제를 확인할 때는 먼저 Config로 설정해 Scene 전환이 판단에 영향을 주지 않도록 하세요.

Config로 이동해 현재 구성을 백업한 다음, 편집하려는 파일이 현재 선택된 구성인지 확인하세요. 이름이 같은 다른 파일이 아닌지 살펴보세요.
Home으로 돌아가 Global Routing을 Config로 설정하고, 기존 프록시 연결이 정상적으로 작동하는지 확인하세요.
규칙을 편집한 뒤 구성을 저장하세요. 필요하면 연결을 다시 설정한 다음 새 테스트 요청을 보내세요.
연결 기록에서 대상 도메인 또는 IP, 매칭된 규칙과 최종 전략을 확인하세요. 웹페이지가 열리는지만으로 판단하지 마세요.

Settings → On Demand에서는 연결을 자동으로 설정할 조건을 관리합니다. 특정 도메인에 PROXY와 DIRECT 중 어떤 전략을 적용할지는 여기서 결정하지 않습니다. 규칙을 테스트하는 동안 연결을 직접 끊어야 한다면 On Demand가 다시 연결을 시작하는지 먼저 확인하세요. 저장한 규칙 때문에 연결 상태가 저절로 바뀐 것으로 오해하지 않도록 주의하세요.

앱 요청터널 진입순서대로 매칭전략 적용결과 기록

2. 규칙의 세 가지 요소: 유형, 매칭 값, 전략

기본 규칙 대부분은 쉼표로 구분된 세 필드로 구성됩니다. 규칙 유형, 매칭 값, 전략입니다. 예를 들어 DOMAIN,example.com,DIRECT는 대상 도메인이 정확히 example.com일 때 직접 연결한다는 뜻입니다. FINAL에는 매칭 값이 없으므로 FINAL,PROXY로 작성하세요. 세 필드 형식에 빈 필드를 추가하지 마세요.

6가지

이 글에서 다루는 기본 규칙 키워드

3가지

기본 전략: PROXY / DIRECT / REJECT

첫 번째로 매칭된 규칙

규칙 이름순으로 자동 정렬되지 않음

전략	처리 방식	적용 시 유의 사항
`PROXY`	프록시 전략으로 처리합니다.	사용 가능한 기존 프록시와 그 설정값이 필요합니다. 규칙 자체가 연결 서비스를 만들지는 않습니다.
`DIRECT`	대상에 직접 연결합니다.	시스템 터널을 우회한다는 뜻이 아니며, 현재 네트워크에서 대상에 접속할 수 있다고 보장하지도 않습니다.
`REJECT`	매칭된 연결을 거부합니다.	매칭 후 요청이 실패하는 것은 예상된 결과입니다. 차단할 대상이 명확한 경우에만 사용하세요.

규칙 끝에는 구성에 정의된 정책 그룹을 지정할 수도 있습니다. 처음에는 위의 기본 전략을 사용하고, 존재하지 않는 그룹 이름을 임의로 입력하지 마세요. PROXY는 전략 식별자이고 Global Routing의 Proxy는 실행 모드입니다. 위치와 역할이 다르므로 서로 바꿔 쓸 수 없습니다.

3. DOMAIN, DOMAIN-SUFFIX, DOMAIN-KEYWORD의 차이

세 규칙은 모두 도메인을 대상으로 하지만 매칭 범위가 다릅니다. DOMAIN은 도메인 전체가 정확히 일치하는지 확인합니다. DOMAIN-SUFFIX는 지정한 도메인 자체와 하위 도메인을 매칭합니다. DOMAIN-KEYWORD는 도메인에 지정한 문자열이 포함되어 있는지 확인합니다. 웹페이지 본문을 확인하거나 URL 경로에 따라 같은 사이트의 페이지를 구분하지는 않습니다.

규칙 예시	매칭되는 항목	매칭되지 않는 항목
`DOMAIN,example.com,DIRECT`	`example.com`	`www.example.com`
`DOMAIN-SUFFIX,example.com,DIRECT`	`example.com`、`img.example.com`	`notexample.com`
`DOMAIN-KEYWORD,example,PROXY`	`example.com`、`myexample.net`	`sample.net`

프로토콜을 붙이지 마세요: 매칭 값에는 example.com을 입력하고 https://example.com은 입력하지 마세요.
페이지 경로를 입력하지 마세요: /login, 쿼리 매개변수, URL fragment는 이 세 규칙의 매칭 값이 아닙니다.
와일드카드를 넣지 마세요: 도메인 전체와 하위 도메인을 대상으로 하려면 DOMAIN-SUFFIX,example.com,DIRECT를 사용하세요. *.를 추가할 필요는 없습니다.
짧은 키워드는 신중하게 사용하세요: DOMAIN-KEYWORD,ad,REJECT는 해당 두 문자가 포함된 정상 도메인까지 잘못 차단할 수 있습니다. 정확한 광고 도메인 목록과 같은 기능으로 보면 안 됩니다.

api.example.com만 프록시로 연결하고 같은 도메인의 나머지 연결은 직접 연결하려면, 정확히 일치하는 DOMAIN 규칙을 범위가 넓은 DOMAIN-SUFFIX보다 앞에 두세요. 연결에서 도메인 정보를 확인할 수 있다면 규칙 순서로 예외를 처리할 수 있습니다. 앱이 IP 주소에 직접 연결하는 경우에는 IP 규칙을 확인해야 합니다.

4. GEOIP와 IP-CIDR: 대상 IP를 기준으로 매칭

GEOIP,CN,DIRECT는 IP 위치 데이터베이스에 등록된 지역 정보를 기준으로 대상 주소를 판단합니다. 도메인 접미사나 서비스 제공업체 본사의 위치를 기준으로 하지 않습니다. 도메인 요청이 IP 규칙에 도달하기 전에 주소를 확인해야 할 수 있습니다. DNS 응답과 데이터베이스 정보의 영향도 받으므로 같은 서비스라도 접속 지점에 따라 GEOIP 규칙 매칭 결과가 달라질 수 있습니다.

GEOIP,CN,DIRECT
IP-CIDR,192.168.0.0/16,DIRECT
IP-CIDR,192.0.2.0/24,REJECT

IP-CIDR에는 네트워크 주소와 프리픽스 길이를 사용합니다. 192.168.0.0/16은 192.168.0.0부터 192.168.255.255까지의 주소를 포함합니다. IPv4의 /32는 단일 주소만 매칭합니다. 위의 192.0.2.0/24는 문서 예시용 네트워크 대역이며 실제 서비스 주소가 아닙니다. 실제 웹사이트에 연결되는지 확인하는 용도로 사용할 수 없습니다.

192.168.0.0/16만 입력해서는 모든 사설 IPv4 주소를 처리할 수 없습니다. 다른 사설 네트워크 대역이 있다면 실제 네트워크에 맞게 별도로 설정하세요.
IPv6 네트워크 대역에는 해당하는 IP-CIDR6 유형을 사용하세요. IPv6 주소를 IPv4 예시에 넣고 동일하게 매칭되리라 기대하면 안 됩니다.
선택 매개변수 no-resolve를 사용하면 해당 IP 규칙 때문에 도메인 조회가 추가로 발생하는 것을 방지할 수 있습니다. 예: IP-CIDR,192.168.0.0/16,DIRECT,no-resolve. 이 설정은 DNS를 전역으로 끄는 기능이 아닙니다.
도메인 요청이 조회된 뒤 특정 IP 대역에 매칭되길 원한다면 조회 동작을 이해한 후 no-resolve 사용 여부를 결정하세요. 모든 규칙에 반드시 붙여야 하는 접미사로 취급하면 안 됩니다.

정리: 도메인 범위를 명확히 알 수 있다면 먼저 도메인 규칙을 사용하세요

먼저 DOMAIN 또는 DOMAIN-SUFFIX로 구체적인 요구를 표현하고, GEOIP와 IP-CIDR은 지역 및 네트워크 대역 정책에 사용하세요. 주소 조회 결과가 바뀌어 생기는 판단 오류를 줄이고, 연결 기록에서 매칭 결과를 더 쉽게 확인할 수 있습니다.

5. FINAL은 마지막에: 구체적인 예외부터 기본 전략까지

Shadowrocket은 규칙을 순서대로 확인하고 먼저 매칭된 규칙의 전략을 적용합니다. 아래쪽 규칙이 더 정확하더라도 자동으로 그 규칙을 선택하지 않습니다. FINAL은 앞서 매칭되지 않은 연결을 처리하므로 규칙 섹션의 마지막에 두세요. FINAL을 맨 앞에 놓으면 아래에 작성한 특정 도메인 규칙이 적용되지 않습니다.

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

이 내용은 학습용 Rule 섹션이며, 프록시 매개변수와 DNS 등을 포함한 전체 구성 파일이 아닙니다. 기존 구성에 [Rule] 섹션이 있다면 그 안의 항목을 편집하고, 이름이 같은 섹션을 여러 개 추가하지 마세요. 예시 도메인은 매칭 방식을 설명하기 위한 것입니다. 실제로 사용할 때는 처리하려는 대상에 맞게 바꾸세요.

api.example.com을 요청하면 첫 번째 DOMAIN 규칙이 매칭되어 PROXY가 적용되고, 뒤에 있는 도메인 접미사 규칙은 더 이상 확인하지 않습니다.
img.example.com을 요청하면 첫 번째 규칙은 매칭되지 않지만 두 번째 DOMAIN-SUFFIX 규칙이 매칭되어 DIRECT가 적용됩니다.
도메인에 blocked-demo가 포함되어 있고 앞의 두 규칙에 매칭되지 않으면 REJECT가 적용됩니다. 이 규칙을 다른 도메인으로 테스트하지 마세요.
나머지 연결은 지정된 네트워크 대역과 GEOIP 규칙을 차례로 확인합니다. 이 조건에도 매칭되지 않을 때 FINAL이 PROXY로 전달합니다.

기본적으로 직접 연결하려면 마지막 규칙을 FINAL,DIRECT로 바꿀 수 있습니다. 단, 현재 테스트 중인 웹사이트뿐 아니라 매칭되지 않은 모든 연결에 영향을 줍니다. 변경하기 전에 프록시를 사용해야 하는 도메인을 먼저 정리하고 FINAL보다 앞에 배치하세요.

6. 규칙이 적용되지 않을 때: 매칭 오류와 연결 오류 구분하기

웹페이지가 열리지 않는다고 해서 규칙을 잘못 작성한 것은 아닙니다. 먼저 연결 기록에서 대상이 예상한 것과 일치하는지, 어떤 규칙에 매칭됐는지, 최종적으로 어떤 전략을 사용했는지 확인하세요. 매칭이나 전략이 예상과 다를 때는 구성 선택, 규칙 범위와 순서를 먼저 살펴보세요. 규칙이 올바르게 매칭됐지만 연결이 실패한다면 네트워크와 기존 프록시 설정을 확인해야 합니다.

Connection timed out

원인: 제한 시간 내에 연결이 완료되지 않았을 수 있습니다. 직접 연결 대상이나 프록시의 아웃바운드 단계에서 발생할 수 있으며, 규칙 구문 오류만을 나타내는 메시지는 아닙니다.

해결 방법: 먼저 기록에서 DIRECT 또는 PROXY가 적용됐는지 확인한 다음, 현재 네트워크에서 해당 대상이나 기존 프록시를 테스트하세요. 문제를 가리기 위해 FINAL의 위치만 바꾸지 마세요.

Connection refused

원인: 대상 연결이 거부됐습니다. 해당 주소의 포트에서 서비스가 실행 중이지 않거나 상대 측에서 연결을 거부했을 수 있습니다.

해결 방법: 기록에 표시된 대상 주소와 포트를 확인하세요. PROXY 아웃바운드 연결이 실패했다면 기존 프록시의 주소, 포트와 서비스 상태도 확인하세요.

HTTPS의 일반적인 대상 포트는 443이지만 DOMAIN 규칙은 ‘443 포트만 매칭’하는 규칙이 아닙니다. 프록시 서버 포트도 무조건 443으로 입력하면 안 됩니다. 사용 중인 서비스의 실제 설정값을 확인하세요. PROXY가 올바르게 매칭됐는데도 연결되지 않는다면 도메인 키워드를 바꾸기보다 사용 중인 프로토콜의 설정을 확인해야 합니다.

항상 FINAL에 매칭됨: 매칭 값에 프로토콜이나 경로가 잘못 포함되지 않았는지, 연결 기록에 실제로 도메인 정보가 있는지 확인하세요.
예외 규칙이 적용되지 않음: 위쪽에 더 넓은 범위의 DOMAIN-SUFFIX나 DOMAIN-KEYWORD 규칙 또는 앞에 배치된 FINAL이 있는지 확인하세요.
변경했는데도 예전 결과가 나옴: 현재 선택된 구성을 저장했는지 확인한 뒤 새 연결을 설정하세요. 브라우저가 재사용하는 연결에는 기존 경로가 계속 적용될 수 있습니다.
시간이 지나면 원래대로 돌아옴: 구성이 원격 업데이트로 관리되는지 확인하세요. 구독의 프록시 목록과 Config의 규칙 설정은 서로 다른 항목입니다. 프록시 목록을 업데이트해도 규칙이 함께 업데이트된다고 단정하지 마세요.

7. 자주 묻는 질문: 도메인, 프로토콜, 구독의 차이

DOMAIN을 작성했는데 하위 도메인에는 왜 적용되지 않나요?

DOMAIN은 도메인 전체가 정확히 일치할 때만 매칭됩니다. 기본 도메인과 모든 하위 도메인을 함께 적용하려면 해당 규칙을 DOMAIN-SUFFIX로 바꾸세요. 특정 하위 도메인 하나만 예외로 처리하려면 그 도메인의 DOMAIN 규칙을 접미사 규칙보다 앞에 두세요.

GEOIP,CN,DIRECT를 설정했는데 왜 중국어 웹사이트가 전부 직접 연결되지 않나요?

GEOIP는 IP의 지역을 판단하며 페이지 언어를 확인하지 않습니다. 대상의 조회 주소와 연결 기록을 먼저 확인하세요. 특정 사이트를 직접 연결하려는 경우에는 실제 도메인으로 DOMAIN-SUFFIX 규칙을 작성하고 GEOIP보다 앞에 배치하세요.

FINAL을 PROXY로 바꾸면 프로토콜 설정이 수정되나요?

아니요. Shadowsocks, VMess, VLESS, Trojan, Hysteria2, WireGuard는 프록시 프로토콜이지 규칙 유형이 아닙니다. FINAL은 매칭되지 않은 연결에 적용할 전략만 결정하며 비밀번호, 인증 정보, TLS 또는 전송 설정을 수정하지 않습니다.

구독을 업데이트하면 수동으로 작성한 규칙이 유지되나요?

먼저 업데이트 대상이 Home의 프록시 구독인지 Config의 원격 구성인지 확인하세요. 원격 구성을 업데이트하면 파일 내용이 교체될 수 있습니다. 수정하기 전에 Config에서 백업하고 업데이트 후 Rule 섹션을 확인하세요. 모든 업데이트 메뉴가 같은 방식으로 내용을 병합한다고 가정하지 마세요.

평소에는 ‘백업, 규칙 하나 수정, 새 요청 보내기, 매칭 결과 확인’ 순서로 관리하세요. DNS, Global Routing, 여러 규칙을 한꺼번에 바꾸는 것보다 변수를 하나씩 조정하는 편이 원인을 찾기 쉽습니다. 이 글은 사용자가 자신의 서비스와 구독을 보유하고 있다는 전제로 작성했습니다. 사이트에서는 프록시 노드나 구독을 제공·판매·추천하지 않습니다. 클라이언트 다운로드와 회선 서비스는 별개입니다.