Shadowrocket 규칙 문법 기초: DOMAIN·DOMAIN-SUFFIX·GEOIP·FINAL 매칭 범위

이 글의 핵심 내용

Shadowrocket의 규칙 라우팅은 Global Routing에서 Config를 선택해야 작동합니다. 직접 보유한 서비스 연결 정보를 바탕으로 Config를 편집하려는 사용자를 위해 규칙 필드를 구분하고, 도메인과 IP 매칭의 차이를 살펴본 뒤 순서에 따라 매칭 결과를 확인합니다. 예시 도메인과 주소는 문법 설명용이며 실제 연결 정보가 아닙니다. 수정하기 전에 현재 Config를 보관하세요.

1. 규칙 적용 조건과 매칭 순서

먼저 핵심부터 살펴보겠습니다. 규칙은 Config에 작성된 순서대로 위에서 아래로 확인하며, 적용되는 규칙과 일치하면 해당 규칙의 정책을 사용합니다. 뒤에 더 구체적인 규칙이 있더라도 자동으로 다시 선택하지 않습니다. 예외는 앞에, 범위가 넓은 규칙은 뒤에 배치하고, 나머지 요청은 FINAL로 처리하세요. 규칙을 편집하기 전에 현재 사용 중인 Config 파일을 확인해야 변경 사항이 적용될 대상을 명확히 알 수 있습니다.

Home → Global Routing에서 Config를 선택해야 현재 Config에 따라 라우팅됩니다. Proxy와 Direct는 전체 라우팅 모드이므로 이 글의 예시로 규칙 순서를 검증할 수 없습니다. Scene은 장면별 설정에 따라 작동하므로 확인할 때 해당 장면의 라우팅도 점검해야 합니다. 규칙 파일 하나를 테스트할 때는 Config를 선택해 라우팅 모드의 영향을 문법 문제로 오인하지 않도록 하세요.

요청 전송 대상 확인 순서대로 매칭 정책 선택 연결 설정

이 흐름은 규칙이 요청 처리 방식을 결정하는 과정을 설명하며, 모든 요청이 반드시 먼저 DNS 조회를 거친다는 뜻은 아닙니다. 도메인 규칙은 확인된 대상 도메인을, IP 규칙은 대상 주소를 사용합니다. 도메인을 확인할 수 있는지, DNS 조회가 필요한지, Config의 DNS 설정이 어떻게 되어 있는지에 따라 매칭에 사용할 수 있는 정보가 달라집니다. PROXY에 매칭되더라도 프록시 정책이 선택되었다는 뜻일 뿐, 이후 연결 성공을 보장하지는 않습니다.

2. 규칙 행 형식: 키워드, 조건, 정책

일반적인 규칙 행은 영문 쉼표로 항목을 구분합니다. DOMAIN, DOMAIN-SUFFIX, DOMAIN-KEYWORD, GEOIP, IP-CIDR에는 매칭 조건과 정책이 필요하고, FINAL에는 매칭 조건 없이 정책만 지정합니다. 규칙은 Config의 [Rule] 섹션에 작성하고 [General]이나 [Host]에는 넣지 마세요.

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

위 Config에서는 login.example.com을 우선 적용할 예외로 지정하고, 나머지 example.com 범위는 PROXY로 처리합니다. DOMAIN-KEYWORD 규칙은 더 넓은 범위를 매칭하지만 여기서는 형식을 보여 주기 위한 예시입니다. 실제 Config에 모든 유형을 한꺼번에 작성할 필요는 없습니다. PROXY와 DIRECT는 정책이지 프로토콜 이름이 아닙니다. Shadowsocks, VMess, VLESS, Trojan, Hysteria2, WireGuard 등의 연결 매개변수는 기존 연결 Config에서 확인해야 하며, 규칙 행의 정책 자리에 입력할 수 없습니다.

DIRECT: 대상 요청을 직접 연결 정책으로 처리합니다. 실제 결과는 현재 네트워크, 대상 서비스, DNS 상태의 영향을 받습니다.
PROXY: 요청을 프록시 정책으로 전달합니다. 테스트할 때는 해당 정책에 연결된 기존 연결을 사용할 수 있는지 확인하세요.
REJECT: 매칭된 요청을 거부합니다. Config에 이런 규칙이 있다면 규칙 순서를 확인할 때 함께 살펴보세요.
사용자 지정 정책: 정책 그룹 이름을 참조한다면 Config에 실제로 정의된 이름과 일치해야 합니다. 설명용 문구를 이미 존재하는 정책처럼 사용할 수는 없습니다.

조건에는 규칙에 필요한 값만 입력합니다. 도메인 규칙에는 도메인만 쓰고 https://, 경로, 쿼리 매개변수, :443은 붙이지 않습니다. 예를 들어 https://example.com/account의 도메인 조건은 example.com입니다. 이 여섯 가지 규칙 유형으로는 URL 경로를 기준으로 같은 사이트의 서로 다른 페이지를 구분할 수 없습니다.

3. DOMAIN, DOMAIN-SUFFIX, DOMAIN-KEYWORD

DOMAIN은 완전한 도메인 하나와 정확히 일치합니다. DOMAIN-SUFFIX는 지정한 도메인과 그 하위 도메인을 매칭하고, DOMAIN-KEYWORD는 도메인에 지정된 문자열이 포함되어 있는지 확인합니다. 세 규칙의 매칭 범위는 서로 다르므로 단순히 모두 example을 포함하는 규칙으로 이해하면 안 됩니다. 특히 DOMAIN-SUFFIX는 도메인 경계를 고려하지만 DOMAIN-KEYWORD는 접미사 경계로 매칭하지 않습니다.

규칙 조건	매칭됨	매칭되지 않음
`DOMAIN,example.com`	`example.com`	`www.example.com`
`DOMAIN-SUFFIX,example.com`	`example.com`、`api.example.com`	`notexample.com`、`example.com.other.test`
`DOMAIN-KEYWORD,example`	`example.com`、`myexample.test`	`sample.test`

사이트의 특정 호스트 하나만 지정하려면 DOMAIN을 사용하고, 최상위 도메인과 여러 단계의 하위 도메인을 모두 포함하려면 DOMAIN-SUFFIX를 사용하세요. 문자열을 폭넓게 매칭해야 할 때는 DOMAIN-KEYWORD가 적합하지만, 관계없는 도메인까지 포함할 수 있으므로 규칙 행을 줄이려고 접미사 규칙 대신 사용하는 것은 권장하지 않습니다. DOMAIN-SUFFIX 조건은 *.example.com으로 쓰지 말고 example.com으로 입력하세요.

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

이 예시에서는 api.example.com이 첫 번째 DOMAIN 규칙에 매칭되어 DIRECT로 처리되고, www.example.com은 두 번째 행에 매칭되어 PROXY로 처리됩니다. 앞의 두 행 순서를 바꾸면 접미사 규칙이 api.example.com을 먼저 처리하므로 정확한 도메인 규칙을 예외로 적용할 수 없습니다. 웹페이지는 이미지, 로그인, API에 별도의 도메인을 사용할 수도 있습니다. 각 요청을 따로 확인하고 주소 표시줄의 기본 도메인만으로 페이지 전체 트래픽을 판단하지 마세요.

4. GEOIP와 IP-CIDR: 대상 IP로 매칭

GEOIP는 앱에서 사용하는 지리 정보 데이터베이스를 기준으로 대상 IP의 국가 또는 지역을 매칭합니다. 예를 들어 GEOIP,CN,DIRECT와 같이 작성합니다. 여기서 CN은 국가 코드이며 도메인 접미사 또는 콘텐츠의 지역을 뜻하지 않습니다. 데이터베이스의 분류 결과가 실제 물리적 위치를 실시간으로 증명하는 것도 아니므로, 페이지가 중국어로 표시된다는 이유만으로 CN에 매칭될 것이라고 예상해서는 안 됩니다.

IP-CIDR은 대상 IPv4 주소가 지정된 네트워크 대역에 속하는지 확인합니다. 192.168.0.0/16은 192.168.0.0부터 192.168.255.255까지의 범위를 나타내며, /32는 IPv4 주소 하나를 뜻합니다. 아래 주소는 문법 설명을 위한 예시이며 서버 주소 추천이 아닙니다.

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

IP 주소를 이미 알고 있는 경우: 요청 대상이 이미 IP라면 도메인 매칭으로 처리하지 않고 바로 네트워크 대역이나 데이터베이스 분류를 확인할 수 있습니다.
도메인 대상인 경우: IP 규칙은 주소를 조회한 뒤에야 매칭할 수 있으므로 DNS 결과가 영향을 미칠 수 있습니다. 도메인이 앞쪽의 도메인 규칙에 먼저 매칭되면 뒤에 있는 IP 규칙은 결과를 바꾸지 않습니다.
no-resolve: 이 IP 규칙을 적용하기 위해 도메인을 직접 조회하지 않도록 지정합니다. 모든 DNS 조회를 끄거나 이미 사용할 수 있는 대상 IP를 무시한다는 뜻은 아닙니다.
주소 체계: IP-CIDR은 IPv4에 사용하고 IPv6 네트워크 대역에는 IP-CIDR6을 사용합니다. IPv4 대역만 지정해도 대상의 IPv6 주소까지 자동으로 포함되지는 않습니다.

예시의 마지막 행은 FINAL,PROXY로, 앞서 살펴본 FINAL,DIRECT와 목적이 다릅니다. 매칭되지 않은 요청을 프록시로 보내는 설정입니다. 어떤 기본 정책을 사용할지는 라우팅 목적에 따라 선택하세요. 실제로 확인할 때는 요청 도메인, 대상 주소, 최종 정책을 함께 기록해 DNS가 다른 주소를 반환한 현상을 CIDR 작성 문제로 오인하지 않도록 하세요.

5. FINAL 기본 처리와 Config 확인 단계

FINAL은 앞선 규칙에 매칭되지 않은 나머지 요청을 처리하며 규칙 맨 끝에 배치해야 합니다. FINAL은 자동으로 가장 낮은 우선순위를 갖는 기본 설정이 아니라 규칙 순서에 포함된 한 행입니다. 앞쪽에 두면 뒤의 규칙은 요청을 처리할 기회를 얻지 못합니다. 지정한 도메인만 프록시로 보내려면 도메인 규칙과 FINAL,DIRECT를 사용할 수 있고, 나머지 요청도 프록시로 보내려면 FINAL,PROXY를 사용하세요.

기존 Config 보관

Config로 이동해 현재 활성화된 파일을 확인하고 수정 전에 복사본을 보관하세요. 기존 [Rule]의 순서를 기록해 두어 테스트 규칙만 남기고 기존 예외가 사라지지 않도록 합니다.
테스트 규칙 입력

해당 Config의 편집 화면을 열고 [Rule]에 필요한 규칙을 추가합니다. DOMAIN 예외를 DOMAIN-SUFFIX 앞에 배치하고, 목적에 맞는 FINAL을 맨 끝에 둔 다음 저장하세요.
라우팅 확인

Home → Global Routing → Config로 돌아가 Config에서 선택된 파일을 확인하세요. Home에서 사용하는 프록시 정책이 직접 보유한 연결 가능한 서버를 가리키는지도 점검합니다.
새 요청 보내기

연결을 다시 설정한 뒤 테스트 대상에 접속해 수정 전에 만들어진 장기 연결을 재사용하지 않도록 합니다. 앱의 요청 기록에서 대상과 실제 적용된 정책을 확인하세요. 캐시된 웹페이지가 표시되는 것만으로는 새 규칙이 적용되었다고 볼 수 없습니다.
기본 처리 확인

도메인 목록에 없는 다른 대상에도 접속해 FINAL에서 지정한 정책이 적용되는지 확인하세요. 예상과 다르면 더 넓은 키워드 규칙을 바로 추가하지 말고 앞선 규칙, 대상 IP, 현재 Config 순으로 점검합니다.

세 번째 절의 세 행 예시에서는 api.example.com에 DIRECT, www.example.com에 PROXY, 그 밖의 미매칭 대상에 DIRECT가 적용됩니다. 이는 규칙을 바탕으로 도출한 결과이지 예시 도메인에 실제 접속해 테스트한 결과가 아닙니다. 직접 설정할 도메인으로 바꾼 뒤 요청 기록으로 확인하세요. 지연 시간 테스트 한 번으로는 연결 가능성만 확인할 수 있으며 특정 웹페이지가 어떤 규칙에 매칭되었는지는 알 수 없습니다.

6. 규칙 미적용과 연결 오류 구분

먼저 두 가지 문제를 구분하세요. 요청에 잘못된 정책이 적용된다면 라우팅 모드, Config 선택, 규칙 조건이나 순서를 확인해야 합니다. 요청에 예상한 정책이 적용됐는데도 연결에 실패한다면 대상 서비스와 기존 서버의 연결 매개변수를 점검해야 합니다. 규칙은 요청 처리 방식을 결정할 뿐, 서버 포트 오류나 연결 불가 문제를 해결하지 않습니다.

오류: Connection refused

원인과 해결: 연결 과정에서 발생할 수 있는 거부 오류로, 일반적으로 대상 포트에서 연결을 수신하지 않거나 연결을 명시적으로 거부할 때 나타납니다. 먼저 요청에 실제로 적용된 정책을 확인하세요. PROXY를 사용했다면 보유한 서비스 제공업체의 정보를 대조해 서버 주소와 Port를 확인합니다. 안내에 443이라고 명시되어 있다면 일반적으로 쓰이는 포트를 추측하지 말고 443을 입력하세요.

오류: Operation timed out

원인과 해결: 작업이 제한 시간 안에 완료되지 않았다는 뜻으로, 연결 과정에서 발생할 수 있는 시간 초과 오류입니다. 규칙 문법 오류를 의미하지는 않습니다. 먼저 Home에서 기존 연결을 테스트한 다음 요청 대상과 정책을 확인하고 현재 네트워크, 대상에 연결 가능한지, 서버가 작동하는지를 각각 점검하세요. 앱 기록에 표시되는 전체 문구는 오류 발생 지점에 따라 달라질 수 있습니다.

DOMAIN-SUFFIX를 설정했는데 왜 직접 연결되나요?

먼저 Home → Global Routing에서 Config를 선택한 다음 Config에서 방금 저장한 파일이 활성화되어 있는지 확인하세요. 이어서 [Rule] 맨 위부터 먼저 매칭되는 DIRECT 또는 FINAL이 있는지 살펴봅니다. 조건에는 도메인만 남기고 프로토콜, 경로, 포트는 넣지 마세요.

특정 하위 도메인만 직접 연결하고 다른 하위 도메인에는 영향을 주지 않으려면 어떻게 하나요?

DOMAIN,api.example.com,DIRECT를 DOMAIN-SUFFIX,example.com,PROXY보다 앞에 배치하세요. 저장한 뒤 새 요청을 보내 api.example.com과 다른 하위 도메인에 적용되는 정책을 각각 확인합니다. 한쪽만 테스트하지 마세요.

웹페이지는 열리는데 이미지 일부가 로드되지 않는 이유는 무엇인가요?

페이지 주소만 보지 말고 실패한 요청의 실제 도메인을 확인하세요. 이미지는 별도 도메인에서 제공될 수 있으며, PROXY에 매칭됐지만 연결이 실패했을 수도 있습니다. 요청 기록을 확인한 다음 DOMAIN이나 DOMAIN-SUFFIX를 추가할지 결정하고, 관계없는 대상까지 포함할 수 있는 DOMAIN-KEYWORD는 피하세요.

구독을 업데이트하면 직접 작성한 규칙도 함께 바뀌나요?

먼저 Home의 연결 정보 구독과 Config의 규칙 파일 업데이트를 구분하세요. 기존 연결 구독을 업데이트해도 현재 [Rule]이 편집되는 것은 아닙니다. 현재 Config 파일 자체가 원격 업데이트되는 파일이라면 업데이트 후 내용을 다시 확인하고, 사용자 지정 변경 사항은 직접 관리할 수 있는 복사본에 보관하세요.

문제를 확인할 때는 한 번에 조건 하나만 수정하고 변경 전후의 규칙 행과 요청 결과를 보관하세요. 현재 Config, Global Routing, 매칭 순서, 도메인 또는 IP, 연결 매개변수 순으로 확인하면 라우팅 판단과 네트워크 연결 문제를 구분할 수 있습니다. 설정 메뉴에 대한 전체 안내는 사이트의 사용 튜토리얼을 참고하세요. 프로토콜 매개변수 확인 위치는 프로토콜 참조에서 확인할 수 있습니다.