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

이 글의 핵심 내용

이 글은 iPhone 또는 iPad에서 Shadowrocket을 사용하고, 직접 관리하는 서버 정보나 구독이 있지만 규칙이 왜 적용되거나 적용되지 않는지 궁금한 사용자를 위한 안내입니다. 먼저 Global Routing과 현재 설정을 확인한 뒤 도메인 매칭, IP 매칭, FINAL의 기본 규칙을 구분합니다. 글을 읽고 나면 최소한의 규칙 구문을 작성하고 요청 기록으로 실제 연결 경로를 확인할 수 있습니다. 예시 도메인과 예약 주소는 설명용이며 연결 서비스는 제공하지 않습니다.

1. 규칙 적용 전 확인 사항: Global Routing과 현재 설정

Shadowrocket의 규칙은 서버 목록이 아닙니다. Home에서 선택한 서버는 프록시 연결의 출구를 결정하고, Config의 설정 파일에는 규칙 등의 설정이 담깁니다. 직접 관리하는 구독을 가져오거나 업데이트해도 원하는 규칙 설정으로 전환된 것은 아닙니다. 문제를 확인하기 전에 이 두 항목을 각각 점검하세요.

Home에서 Global Routing을 확인하세요. 이 글에서는 Config를 선택해 현재 설정 파일의 규칙을 차례로 적용하는 경우를 다룹니다. Proxy와 Direct는 전역 라우팅 모드이므로, 이 모드에서의 접속 결과만으로 특정 설정 규칙이 적용됐다고 판단할 수 없습니다. Scene은 선택한 시나리오 설정에 따라 동작하므로 Config와 같은 의미로 보면 안 됩니다.

설정 항목	확인할 내용	이 글의 테스트 방법
`Config`	현재 설정 파일의 규칙에 따라 트래픽을 라우팅합니다.	이 항목을 선택한 다음 현재 설정 파일이 올바른지 확인합니다.
`Proxy`	전역 프록시 라우팅 모드를 사용합니다.	출구 문제를 구분할 때 참고할 수 있지만, 개별 규칙을 검증한 결과로 볼 수는 없습니다.
`Direct`	전역 직접 연결 라우팅 모드를 사용합니다.	직접 연결 결과와 비교할 수 있습니다. 테스트가 끝나면 Config로 되돌리세요.
`Scene`	시나리오 설정에 따라 동작합니다.	먼저 시나리오 설정을 확인하세요. 처음 규칙을 테스트할 때는 Config를 사용합니다.

2. 규칙의 문법과 순서: 먼저 일치하는 규칙 적용

일반적인 규칙은 영문 키워드, 매칭 대상, 정책으로 구성되며 각 필드는 반각 쉼표로 구분합니다. FINAL에는 매칭 대상이 필요 없으므로 주요 필드는 키워드와 정책 두 개입니다. DIRECT는 직접 연결을 뜻합니다. 아래의 PROXY는 프록시를 통해 연결한다는 뜻이며, 사용 전에 현재 프록시 선택이 유효한지 확인해야 합니다. 사용자 지정 정책 그룹 이름을 입력했다면 해당 이름이 설정 파일에 있어야 합니다.

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

아래는 문법 설명을 위한 예시이며, 그대로 연결에 사용할 수 있는 완전한 설정은 아닙니다. Shadowrocket은 위에서 아래로 규칙을 확인하고, 조건에 처음으로 일치하는 규칙의 정책을 적용합니다. 그 뒤에 더 구체적인 규칙이 있어도 계속 검색하지 않습니다. 따라서 구체적인 규칙이라고 해서 자동으로 포괄적인 규칙보다 우선 적용되지는 않습니다.

요청 시작규칙별 매칭첫 규칙 일치정책 적용연결 설정

위의 예시에서 요청에 login.example.com 도메인이 포함되면 첫 번째 줄이 먼저 일치하므로 DIRECT가 적용됩니다. DOMAIN-SUFFIX를 DOMAIN보다 위에 배치하면 login.example.com이 후위 규칙에 먼저 일치해 PROXY로 전달되고, 아래의 정확한 규칙은 해당 요청을 처리할 기회를 얻지 못합니다.

먼저 처리해야 하는 소수의 예외 규칙은 앞에 배치하세요. 예를 들어 특정 로그인 도메인이 이에 해당합니다.
도메인과 하위 도메인 전체에 적용되는 일반 규칙은 예외 규칙 뒤에 배치합니다.
범위가 넓은 키워드와 IP 지역 판정이 뒤의 규칙을 가리는지 확인하세요.
FINAL은 매칭에 사용할 규칙을 모두 배치한 뒤, 유효한 규칙 목록의 마지막에 둡니다.

3. DOMAIN, DOMAIN-SUFFIX, DOMAIN-KEYWORD의 적용 범위

세 키워드는 모두 도메인을 대상으로 하지만 적용 범위가 다릅니다. 규칙에는 호스트명이나 키워드를 입력하며 전체 URL을 입력하지 않습니다. https://, 웹페이지 경로, 쿼리 매개변수, 포트는 붙이지 마세요. login.example.com의 443 포트에 접속하더라도 DOMAIN의 매칭 값은 login.example.com:443이 아닙니다.

규칙 예시	일치하는 대상	일치하지 않는 대상
`DOMAIN,example.com,DIRECT`	example.com	www.example.com、example.com.test
`DOMAIN-SUFFIX,example.com,PROXY`	example.com、www.example.com、a.b.example.com	notexample.com、example.com.test
`DOMAIN-KEYWORD,example,PROXY`	example.com、myexample.test、example.net	example을 포함하지 않는 도메인

DOMAIN: 정확한 호스트명 하나만 처리

api.example.com과 www.example.com을 구분하려면 DOMAIN을 사용하는 편이 가장 명확합니다. DOMAIN은 하위 도메인까지 자동으로 포함하지 않으므로 DOMAIN,example.com,DIRECT는 api.example.com에 적용되지 않습니다. 앱에 규칙을 설정할 때는 로그인, API, 이미지 등에 여러 호스트명을 요청할 수 있다는 점도 고려하세요. 홈페이지 도메인만 보고 모든 요청의 연결 경로를 판단할 수는 없습니다.

DOMAIN-SUFFIX: 도메인 계층 전체에 적용

DOMAIN-SUFFIX,example.com,PROXY는 루트 도메인과 모든 단계의 하위 도메인에 적용됩니다. 와일드카드는 필요하지 않습니다. 임의의 문자열 접미사를 검색하는 규칙은 아닙니다. notexample.com은 끝에 같은 문자가 포함되어 있어도 도메인 계층 경계가 없으므로 example.com의 하위 도메인이 아닙니다.

DOMAIN-KEYWORD: 문자열 포함 여부로 범위 확장

DOMAIN-KEYWORD는 도메인의 특정 계층 경계를 따르지 않습니다. 특정 문자열이 포함된 여러 도메인을 처리해야 할 때 유용하지만, 의도하지 않은 항목까지 일치할 수 있습니다. 예를 들어 example은 myexample.test에도 일치합니다. example.com 도메인만 처리하려면 더 넓은 키워드 대신 DOMAIN-SUFFIX를 우선 사용하세요.

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

GEOIP는 대상 IP가 IP 주소 데이터베이스에서 어느 지역으로 분류되는지 판단합니다. GEOIP,CN,DIRECT는 대상 IP가 데이터베이스에서 CN으로 분류되면 DIRECT를 사용한다는 뜻입니다. 도메인 등록 국가, 사용자의 위치를 확인하는 규칙이 아니며, 특정 브랜드의 모든 서비스가 항상 같은 지역의 IP 주소를 사용하는 것도 아닙니다.

IP-CIDR은 지정된 IPv4 네트워크 대역을 대상으로 합니다. IP-CIDR,192.0.2.0/24,DIRECT는 192.0.2.0부터 192.0.2.255까지 적용됩니다. 여기서 /24는 앞의 24비트가 네트워크 접두사라는 뜻이며 포트 번호가 아닙니다. 192.0.2.0/24는 문서 예시에 사용하도록 예약된 주소 범위이므로 실제 서버 주소로 사용할 수 없습니다.

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

IP 규칙을 적용하기 전에 도메인을 확인해야 하는지는 문제를 진단하는 과정에 영향을 줍니다. 선택적 매개변수 no-resolve는 이 IP 규칙만을 위해 도메인 조회를 먼저 요청하지 않도록 지정합니다. 대상 IP를 이미 알고 있다면 주소를 기준으로 판단할 수 있습니다. 따라서 no-resolve는 DNS를 끄는 옵션도, 웹페이지에 더 이상 도메인 조회가 필요 없다는 뜻도 아닙니다. 대상 IP를 확인할 수 없으면 해당 규칙을 건너뛰고 다음 규칙을 적용할 수 있습니다.

도메인 예외를 먼저 배치: 도메인 기준으로 처리할 서비스는 해당 DOMAIN 또는 DOMAIN-SUFFIX 규칙을 범위가 넓은 GEOIP보다 앞에 두는 것이 일반적입니다.
데이터베이스는 서비스 분류가 아닙니다: CDN 주소, DNS 조회 결과, IP 주소 데이터베이스의 지역 분류에 따라 GEOIP 결과가 달라질 수 있으므로 실제 대상 IP를 확인하세요.
주소 유형을 구분해 확인: IP-CIDR의 IPv4 네트워크 대역은 IPv6에 적용되지 않습니다. IPv6 주소에는 해당하는 IP-CIDR6 규칙을 별도로 사용해야 합니다.
포트와 CIDR은 별개입니다: 대상 포트 443과 네트워크 대역 /24는 서로 다른 정보입니다. IP-CIDR의 주소 필드 뒤에 포트를 붙이지 마세요.

5. FINAL을 마지막에 두어야 하는 이유

FINAL은 기본 규칙입니다. 앞에 있는 규칙이 하나도 일치하지 않을 때 지정된 정책을 적용합니다. 도메인이나 네트워크 대역 제한이 없으므로 중간에 두면 그 줄까지 도달한 모든 요청을 처리해 아래 규칙이 더 이상 적용되지 않습니다. 여기서 마지막이란 편집 창에 보이는 마지막 부분이 아니라, 유효한 규칙 전체의 끝을 뜻합니다.

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

FINAL,PROXY와 FINAL,DIRECT는 각각 명확한 기본 경로를 지정하며 모든 사용자에게 맞는 정답은 없습니다. 전자는 분류되지 않은 요청을 프록시로 보내고, 후자는 직접 연결합니다. 전자를 선택하면 사용할 수 있는 프록시 출구가 필요합니다. 후자를 선택하면 알 수 없는 대상에 직접 연결하게 됩니다. 변경하기 전에 웹페이지 하나가 열리는지만 보지 말고 자신의 사용 목적을 먼저 확인하세요.

“규칙을 더 구체적으로 작성했는데도 왜 일치하지 않나요?”

먼저 해당 규칙 위에 DOMAIN-SUFFIX, DOMAIN-KEYWORD 또는 FINAL이 있는지 확인하세요. 우선 처리할 DOMAIN 예외를 범위가 넓은 규칙 앞으로 옮긴 다음 연결을 새로 시작해 확인합니다.

“FINAL 뒤에 규칙을 추가해도 되나요?”

텍스트를 추가할 수는 있지만, 이미 FINAL이 처리한 요청에는 새 규칙이 적용되지 않습니다. 새 규칙을 FINAL 앞에 배치하고 마지막에는 명확한 기본 규칙을 하나 두세요.

“FINAL을 DIRECT로 바꾸면 문제가 해결되나요?”

항상 그런 것은 아닙니다. 사용할 수 없는 프록시 출구를 우회한 것일 수 있습니다. Home으로 돌아가 현재 서버를 확인한 다음, 해당 도메인에 더 구체적인 규칙을 적용해야 하는지 살펴보세요.

“구독을 업데이트하면 규칙도 함께 바뀌나요?”

서버 구독 업데이트와 규칙 설정 업데이트는 서로 다른 작업입니다. 먼저 Config에서 현재 설정을 확인하고, 업데이트된 항목이 서버 목록인지 설정 파일인지 살펴보세요. 목록이 새로 고쳐졌다는 이유만으로 규칙도 업데이트됐다고 판단하지 마세요.

6. 최소 검증 절차: 한 번에 규칙 하나만 변경

검증할 때는 예상 정책과 실제 요청을 함께 기록해야 합니다. 웹페이지가 열린다는 사실만으로는 요청이 DIRECT와 PROXY 중 어느 쪽을 이용했는지 알 수 없습니다. 아래 절차에는 구독 변경이나 프로토콜 매개변수 조정이 필요하지 않습니다. Shadowsocks, VMess, VLESS 등의 출구 프로토콜과 규칙 키워드는 서로 다른 계층입니다.

원래 설정 보존

Config에서 현재 설정을 확인하고, 수정 전에 복원할 수 있는 사본이나 원본 텍스트를 보관하세요. 기존 FINAL 정책을 기록하고 유일하게 사용할 수 있는 설정을 바로 덮어쓰지 마세요.
라우팅 모드 확인

Home → Global Routing에서 Config를 선택한 다음 Config로 돌아와 테스트하려는 설정이 활성화됐는지 확인하세요. 이름이 같거나 원격에 있는 다른 설정이 선택되지 않았는지도 살펴봅니다.
정확한 예외 추가

현재 설정의 규칙 부분에서 직접 확인할 수 있는 실제 대상에 DOMAIN 규칙 하나를 추가하고, 범위가 넓은 규칙과 FINAL 앞에 배치합니다. 이 글의 example.com은 문법 설명용이며 프록시 연결 테스트 대상으로 사용하지 않습니다.
요청 다시 보내기

설정을 저장하고 적용됐는지 확인한 뒤 대상 앱의 기존 연결을 종료하고 새 요청을 보내세요. Home에서 선택한 서버는 그대로 유지해 연결 재사용이나 출구 변경이 판단에 영향을 주지 않도록 합니다.
요청 기록 확인

요청 기록이나 로그에서 호스트명, 대상 IP, 일치한 규칙, 실제 정책을 확인하세요. 표시되는 항목은 인터페이스에 제공되는 정보를 기준으로 합니다. 기록이 충분하지 않으면 먼저 관련 기록 기능을 활성화하고 같은 요청을 다시 보내세요. 지연 시간만으로 연결 경로를 추측하지 마세요.

7. 규칙이 적용된 뒤에도 연결되지 않을 때: 오류 단계별 확인

규칙은 연결 경로를 선택할 뿐, 대상이나 DNS, 프록시 서버가 항상 사용 가능하다고 보장하지 않습니다. 요청 기록에서 예상한 규칙이 적용된 것으로 확인되면 다음 연결 단계를 점검하세요. 아래 문구는 네트워크 진단 중 나타날 수 있는 오류 원문이며 규칙 문법 오류 메시지가 아닙니다. 표시 형식은 오류가 발생한 계층에 따라 다르므로 한 줄만 보고 규칙 문제라고 단정하지 마세요.

오류: `Connection refused`

원인: 연결하려는 엔드포인트 중 하나가 연결을 거부했습니다. 대상 포트나 프록시 서버 포트에서 해당 서비스를 제공하지 않을 수 있습니다.

해결 방법: 먼저 기록에서 연결 대상 주소와 포트를 확인하세요. 그런 다음 Home에 표시된 서버 포트가 직접 관리하는 서비스 정보와 일치하는지 점검합니다. 대상 측에서 오류가 발생했다면 도메인 규칙의 범위를 넓히지 말고 대상 서비스를 확인하세요.

오류: `Operation timed out`

원인: 작업이 제한 시간 내에 완료되지 않았습니다. 네트워크 경로, 프록시 연결, 대상의 응답 중 어느 단계에서 문제가 발생했는지는 시간 초과만으로 확인할 수 없습니다.

해결 방법: 오류 발생 전후의 연결 기록을 확인해 문제 단계를 파악하세요. Home → Global Routing에서 Proxy 또는 Direct로 잠시 전환해 비교하고, 테스트가 끝나면 Config로 복원합니다. 비교하는 동안 테스트 대상은 동일하게 유지하세요.

오류: `No route to host`

원인: 연결에 사용된 네트워크 경로로 대상 주소에 도달할 수 없다는 뜻이며, DOMAIN 또는 FINAL 필드가 잘못 작성됐다는 의미는 아닙니다.

해결 방법: 현재 네트워크가 사용 가능한지, 실제 대상 IP와 주소 유형이 예상과 일치하는지 확인하세요. 그런 다음 요청이 DIRECT와 프록시 출구 중 어느 쪽으로 연결됐는지 점검하고 해당 경로에 맞게 조치합니다.

도메인 조회 단계에서 실패했다면 먼저 DNS 요청이 성공했는지 확인하세요. 서버 인증에 실패했다면 직접 관리하는 서버의 매개변수를 확인합니다. 이런 문제를 가리기 위해 모든 요청을 DIRECT로 바꾸거나, 오류 하나를 해결하려고 전체 규칙을 다시 작성하지 마세요. 비교 조건을 유지해야 수정이 실제로 적용됐는지 확인할 수 있습니다.

설정 확인: Home → Global Routing에서 Config가 선택되어 있고, Config에서 올바른 파일이 활성화되어 있습니다.
문법 확인: 반각 쉼표를 사용하고, 도메인 필드에 URL 경로가 없으며, 정책 이름이 유효합니다.
순서 확인: 정확한 예외 규칙이 범위가 넓은 규칙보다 앞에 있고, FINAL이 유효한 규칙 목록의 마지막에 있습니다.
결과 확인: 새 요청의 호스트명과 대상 IP, 실제 적용된 정책이 예상과 일치합니다. 웹페이지가 열리는지만 확인하지 마세요.