Shadowrocket 규칙을 설정할 때는 매칭 대상과 순서, 실행 정책을 함께 확인해야 합니다. 서비스 제공업체와 설정을 이미 보유하고 있으며 분류 규칙을 수정하려는 사용자를 위한 안내입니다. 먼저 Config에서 규칙 기반 분류를 활성화하고, 도메인 규칙과 IP 규칙을 구분한 다음, 매칭되지 않은 연결을 FINAL로 처리합니다. 예시는 문법 설명용이며 실제 연결에 사용할 인증 정보는 포함하지 않습니다.
먼저 Config 확인: 규칙 적용을 위한 조건
설정에 따라 트래픽을 분류하려면 Home → Global Routing에서 Config를 선택하고, Config 화면에서 수정하려는 설정이 선택되어 있는지 확인합니다. 파일을 저장하기만 하고 선택하지 않았거나 Global Routing이 Proxy 또는 Direct로 설정되어 있으면 해당 설정의 분류 결과를 검증할 수 없습니다.
- Config로 이동해 현재 사용 중인 설정을 확인합니다. 기존 설정을 덮어쓰지 않도록 편집 전에 복사본을 만들어 두세요.
- 해당 설정의 편집 화면을 열고
[Rule]을 찾습니다. 이 글의 코드는 규칙 섹션에 넣어야 하며, Home의 서버 주소 입력란에 붙여 넣으면 안 됩니다. - Home → Global Routing으로 돌아가 Config를 선택한 뒤, 기존 프록시 연결이 정상적으로 작동하는지 확인합니다.
- 수정 사항을 저장하고 대상 요청을 다시 보냅니다. 연결 기록에서 대상, 매칭된 규칙, 최종 정책을 확인하세요. Home의 연결 스위치만 확인해서는 안 됩니다.
Proxy는 연결을 프록시로 전달하고, Direct는 대상에 직접 연결합니다. Scene을 사용하는 경우에는 현재 Scene에 적용된 설정도 확인해야 합니다. 이 글의 검증 단계에서는 Scene 전환과 규칙 수정을 혼동하지 않도록 Config를 사용합니다. Settings → On Demand는 조건에 따라 연결을 설정하며, 특정 도메인이 어떤 규칙에 매칭되는지를 결정하지 않습니다.
규칙 문법 이해하기: 매칭 조건과 실행 정책 구분
일반적인 규칙은 규칙 유형, 매칭 값, 실행 정책으로 구성되며 각 항목은 영문 쉼표로 구분합니다. 규칙 유형은 “무엇을 확인하는지”, 실행 정책은 “매칭된 뒤 어떻게 연결하는지”를 나타냅니다. 같은 도메인 조건에도 서로 다른 정책을 지정할 수 있으므로 DOMAIN-SUFFIX 자체가 “자동으로 프록시를 사용한다”고 이해하면 안 됩니다.
[Rule]
DOMAIN,example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN-KEYWORD,example,REJECT
GEOIP,CN,DIRECT
IP-CIDR,192.0.2.0/24,DIRECT
FINAL,PROXY위 예시는 여섯 가지 문법을 보여 주기 위한 것으로, 그대로 활성화할 수 있는 완성된 설정은 아닙니다. 예를 들어 첫 번째 규칙은 example.com을 DIRECT에 매칭하므로 뒤에 나오는 PROXY 규칙까지 진행하지 않습니다. FINAL에는 도메인이나 네트워크 범위 매개변수가 없으므로 FINAL,PROXY로 작성해야 합니다. 항목을 세 개로 맞추려고 빈 필드를 추가하면 안 됩니다.
| 정책 | 매칭된 연결의 처리 방식 | 확인할 사항 |
|---|---|---|
PROXY | 프록시 정책을 사용해 연결합니다. | 현재 선택된 프록시와 연결 매개변수가 정상적으로 작동하는지 확인합니다. |
DIRECT | 대상에 직접 연결합니다. | 현재 네트워크에서 대상에 직접 접속할 수 있는지 확인합니다. |
REJECT | 매칭된 연결을 거부합니다. | 매칭 범위가 지나치게 넓거나 페이지에 필요한 리소스까지 차단하는지 확인합니다. |
규칙에서 사용자 지정 정책 그룹을 참조한다면 이름이 설정에 정의된 이름과 일치하는지 확인하고, 그룹 안에서 실제로 선택된 항목도 점검해야 합니다. PROXY는 특정 프로토콜을 뜻하지 않습니다. Shadowsocks, VMess, VLESS, Trojan, Hysteria2, WireGuard는 연결 설정 단계에서 선택하는 프로토콜이며 규칙의 매칭 조건을 대신하지 않습니다.
DOMAIN, DOMAIN-SUFFIX, DOMAIN-KEYWORD의 차이
도메인 하나만 정확히 매칭하려면 DOMAIN, 기본 도메인과 하위 도메인을 매칭하려면 DOMAIN-SUFFIX를 사용합니다. 도메인에 포함된 문자열을 기준으로 찾아야 할 때만 DOMAIN-KEYWORD를 사용하세요. 흔한 실수는 도메인 필드에 전체 URL을 입력하거나, 접미사 매칭이 마지막 몇 글자만 확인한다고 생각하는 것입니다.
| 규칙 | 매칭되는 항목 | 매칭되지 않는 항목 |
|---|---|---|
DOMAIN,example.com,DIRECT | example.com | www.example.com |
DOMAIN-SUFFIX,example.com,PROXY | example.com、img.example.com | notexample.com、example.com.test |
DOMAIN-KEYWORD,example,REJECT | example.com、myexample.com | sample.test |
DOMAIN-SUFFIX는 도메인 계층 경계를 기준으로 매칭합니다. 예시 필드에는 example.com만 쓰면 되며 *.를 붙일 필요가 없습니다. DOMAIN-KEYWORD는 이런 경계를 따지지 않으므로 example은 소유자가 다른 도메인에도 포함될 수 있습니다. REJECT와 함께 사용할 때는 특히 범위를 좁혀야 합니다.
- 도메인 필드에는
https://를 쓰지 않으며 웹페이지 경로나 쿼리 매개변수도 입력하지 않습니다. https://example.com/docs와https://example.com/account에 접속할 때 세 가지 도메인 규칙은 모두 같은 도메인을 확인합니다. 따라서 경로별로 두 요청을 따로 분류할 수 없습니다.- 일반 도메인 규칙은 대상 포트가 80인지 443인지에 따라 매칭 범위가 달라지지 않습니다. 포트는 DOMAIN-SUFFIX의 세 번째 필드가 아닙니다.
- 요청에 대상 IP만 있고 사용할 수 있는 도메인 정보가 없다면 도메인 규칙이 웹사이트 이름을 알아서 찾아낼 것이라고 기대할 수 없습니다.
GEOIP와 IP-CIDR: 웹사이트 이름이 아닌 대상 IP 기준으로 판단
GEOIP는 IP의 지리적 위치 데이터를 사용해 대상 주소를 판단하고, IP-CIDR은 지정된 주소 범위를 기준으로 판단합니다. 둘 다 웹페이지의 문구나 사이트 등록 정보, 도메인 접미사를 확인하는 규칙이 아닙니다. 중국어로 서비스를 제공하는 웹사이트라고 해서 연결 주소가 반드시 GEOIP에서 CN으로 판정되는 것은 아닙니다. 같은 도메인도 네트워크에 따라 서로 다른 주소로 해석될 수 있습니다.
GEOIP,CN,DIRECT
IP-CIDR,192.0.2.0/24,DIRECT
IP-CIDR,198.51.100.8/32,REJECT
FINAL,PROXY여기서 사용하는 192.0.2.0/24와 198.51.100.8/32는 문서용 예시 주소이며 실제로 사용할 수 있는 서버 주소가 아닙니다. /24는 네트워크 접두부가 앞 24비트라는 뜻으로, 이 예시는 192.0.2.0부터 192.0.2.255까지를 포함합니다. IPv4의 /32는 주소 하나만 가리킵니다. IPv6 대역에는 해당하는 IP-CIDR6 유형을 사용해야 하며 IPv4 예시를 그대로 적용할 수 없습니다.
IP 규칙 끝에 no-resolve를 사용하면 해당 IP 규칙을 위해 도메인을 별도로 조회하지 않도록 합니다. 모든 DNS를 끄는 옵션은 아닙니다. 도메인만 있고 사용할 수 있는 대상 IP가 없는 연결은 이 규칙을 건너뛰고 다음 규칙에서 매칭될 수 있습니다. 처음 최소 설정을 시험할 때는 이 옵션을 함께 추가하지 마세요. 매칭 조건을 혼동할 수 있습니다.
FINAL과 규칙 순서: 먼저 매칭된 규칙을 실행하며, 가장 구체적인 규칙이 자동으로 우선하지 않습니다
이 글에서 다루는 일반 규칙은 위에서 아래로 확인하며, 처음 매칭된 규칙의 정책을 실행하는 방식으로 이해해야 합니다. DOMAIN이 DOMAIN-SUFFIX보다 구체적이라고 해서 앞에 있는 규칙을 자동으로 건너뛰지는 않습니다. FINAL은 앞선 조건에 하나도 매칭되지 않을 때 적용되는 기본 규칙이므로 목록의 맨 끝에 두어야 합니다.
[Rule]
DOMAIN,account.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT이 최소 예시에서는 account.example.com에 직접 연결하고, example.com과 그 하위 도메인에는 PROXY를 사용하며, 나머지 매칭되지 않은 대상에는 DIRECT를 적용합니다. 앞의 두 규칙 순서를 바꾸면 account.example.com이 먼저 접미사 규칙에 매칭되므로 아래의 DOMAIN 예외가 해당 연결의 방향을 결정하지 못합니다.
FINAL은 “프록시 연결 실패 후 직접 연결로 전환”하는 장애 조치 규칙도 아닙니다. 앞의 PROXY 규칙에 매칭된 연결이 시간 초과되더라도 목록으로 돌아가 FINAL을 실행하지 않습니다. 매칭되지 않은 트래픽의 기본 경로를 바꾸려면 FINAL의 정책을 수정하세요. 프록시를 사용할 수 없는 경우에는 연결 매개변수나 기존 정책 그룹의 선택을 확인해야 합니다.
- 특정 도메인에 적용할 예외 규칙은 해당 도메인을 포함하는 접미사 규칙보다 앞에 둡니다.
- 범위가 넓은 DOMAIN-KEYWORD 및 GEOIP 규칙은 뒤에 있는 특정 규칙보다 먼저 매칭되어 원치 않는 결과를 내지 않는지 확인해야 합니다.
- REJECT 규칙은 해당 위치에서 매칭된 연결을 차단할 수 있습니다. 범위가 넓은 키워드를 정확한 차단 규칙처럼 사용하지 마세요.
- FINAL 뒤에 추가한 일반 규칙은 적용되지 않습니다. 규칙을 추가하기 전에 기본 처리 행이 어디 있는지 확인하세요.
저장 후 검증하는 방법: 한 번에 조건 하나만 변경
검증할 때는 먼저 “매칭되었는가”를 확인하고, 그다음 “매칭 후 연결이 성공하는가”를 살펴봅니다. 브라우저에서 페이지가 열리지 않는다고 규칙 문법이 틀렸다고 단정할 수 없고, 페이지가 열려도 모든 리소스가 같은 정책을 사용했다는 뜻은 아닙니다. 하나의 페이지가 기본 도메인, 이미지 도메인, API 도메인에 각각 요청을 보낼 수 있으므로 항목별로 확인해야 합니다.
- Config에서 위의 최소 예시를 저장하고 해당 설정이 선택되어 있는지 확인한 다음, Home → Global Routing에서 Config가 선택되었는지 확인합니다.
- 먼저 기존 설정으로 프록시 연결이 가능한지 확인합니다. 기본 연결부터 실패한다면 주소, 포트, 인증 정보, 프로토콜 관련 매개변수를 먼저 수정하세요.
- 기존 요청을 종료한 뒤 테스트 대상에 다시 접속합니다. 재사용 중인 연결로 새 규칙을 판단하지 않도록 하세요.
- 앱의 연결 기록에서 실제 대상, 매칭된 규칙, 정책을 확인합니다. 테스트 도메인은 실제로 접속해야 하는 대상이어야 합니다. 이 글에 나온 도메인은 문법 설명용입니다.
- 기본 페이지는 정상인데 이미지가 표시되지 않는다면 해당 이미지 요청의 도메인을 확인한 뒤 DOMAIN 또는 DOMAIN-SUFFIX를 추가할지 결정하세요. 범위가 불분명한 키워드 규칙부터 추가하지 마세요.
- 수정 전후 결과를 기록하고 한 번에 규칙 하나만 변경합니다. 확인을 마친 뒤 수정 사항을 전체 설정에 차례로 반영하세요.
아래 두 오류는 특정 규칙에만 나타나는 문법 오류가 아니라 연결 단계에서 발생하는 오류입니다. 구체적인 표시 문구는 시스템이나 프로토콜 정보에 따라 달라질 수 있습니다. 먼저 기록에서 실제로 사용된 아웃바운드 정책을 확인한 뒤 해당 연결을 따라 문제를 찾아보세요. 오류가 보인다고 FINAL을 삭제해서는 안 됩니다.
오류: Connection refused
원인 및 해결: 대상 포트에서 연결을 거부한 상태입니다. 해당 서비스가 포트를 열어 두지 않았거나 포트 설정이 맞지 않을 수 있습니다. 먼저 기록에서 DIRECT인지 PROXY인지 확인하세요. DIRECT라면 대상 서비스의 포트를, PROXY라면 기존 프록시의 주소와 포트 및 서비스 상태를 점검합니다.
오류: Connection timed out
원인 및 해결: 제한 시간 내에 연결이 완료되지 않았습니다. 네트워크 연결 가능성이나 아웃바운드 연결에 문제가 있을 수 있습니다. 같은 설정으로 다른 대상에 연결되는지 먼저 확인한 다음, 해당 연결에 매칭된 규칙과 정책을 점검하세요. 시간 초과만으로 도메인 규칙을 IP 규칙으로 바꾸지 마세요.
자주 묻는 질문: 규칙이 맞는데 예상한 결과가 나오지 않는 경우
DOMAIN-SUFFIX를 추가했는데 왜 여전히 직접 연결되나요?
먼저 Home → Global Routing에서 Config가 선택되어 있는지 확인하고, Config에서 편집한 항목이 현재 선택된 설정인지 확인합니다. 그런 다음 접미사 규칙 앞에 이미 DOMAIN, DOMAIN-KEYWORD 또는 다른 매칭 가능한 규칙이 있는지 살펴보고, 연결을 다시 시도한 뒤 기록을 확인하세요.
특정 웹사이트만 프록시를 사용하려면 FINAL을 어떻게 설정해야 하나요?
프록시를 사용할 도메인은 DOMAIN-SUFFIX,example.com,PROXY로 작성하고, 마지막에는 FINAL,DIRECT를 둡니다. 실제로 사용할 때는 예시 도메인을 대상 도메인으로 바꾸고 페이지에 필요한 다른 도메인도 추가하세요. 이 규칙만으로 모든 페이지 리소스의 규칙이 자동 생성되지는 않습니다.
GEOIP,CN,DIRECT를 맨 앞에 두어도 되나요?
문법상 가능하지만 GEOIP 규칙이 먼저 매칭되어 PROXY를 사용하려던 대상을 가로챌 수 있습니다. 특정 도메인에 PROXY를 반드시 적용해야 한다면 보통 해당 도메인의 명확한 규칙을 먼저 두고, GEOIP를 그다음에, FINAL을 마지막에 둡니다. 실제 연결 기록으로 결과를 확인하세요.
Home에서 기존 구독을 업데이트하면 분류 규칙도 함께 바뀌나요?
서버 구독과 Config의 설정 파일은 구분해야 합니다. 서버 구독을 업데이트하면 주로 연결 항목이 갱신되며, 현재 설정의 규칙도 함께 동기화된다고 볼 수 없습니다. 업데이트한 뒤 Home에서 연결 선택을, Config에서 규칙 내용을 각각 확인하고 직접 수정한 내용은 복사본으로 보관하세요.
REJECT 규칙 뒤에 페이지가 빈 화면으로 나오면 프록시가 고장 난 건가요?
먼저 실패한 리소스가 REJECT에 매칭되었는지 확인하세요. API나 스크립트가 잘못 차단되었다면 필요한 도메인의 예외를 광범위한 차단 규칙보다 앞에 두거나 차단 범위를 좁힙니다. REJECT는 연결을 명시적으로 거부합니다. “연결 실패”만으로 프록시가 사용 가능한지 판단해서는 안 됩니다.
규칙의 역할과 한계: 아웃바운드 경로를 선택하며 연결 서비스를 제공하지는 않습니다
규칙은 연결에 DIRECT, PROXY, REJECT 중 어떤 정책을 적용할지 결정하지만, 사용할 수 있는 프록시 서비스를 만들어 주거나 서로 맞지 않는 프로토콜 매개변수를 수정하지는 않습니다. PROXY에 매칭되면 기존 연결 설정이 필요하며, DIRECT에 매칭되면 현재 네트워크와 대상 서비스 상태의 영향을 받습니다. “규칙이 올바르게 매칭되는지”와 “연결에 성공하는지”를 따로 확인해야 합니다.
- 매칭 단계: 도메인 또는 IP가 조건에 맞는지, 규칙 순서가 올바른지 확인합니다.
- 정책 단계: 규칙에서 참조하는 정책과 정책 그룹, 현재 선택된 항목을 확인합니다.
- 연결 단계: 실제 아웃바운드 연결에 필요한 주소, 포트, 인증 정보, 프로토콜 매개변수를 확인합니다.
- 유지 관리 단계: 구독이나 원격 설정을 업데이트한 뒤 선택 상태를 다시 확인합니다. 설정이 바뀌었다면 이전 검증 결과를 그대로 적용하지 마세요.
Shadowrocket은 주로 iPhone과 iPad에서 사용하며, App Store에서만 받을 수 있습니다. 시스템 요구 사항은 App Store 페이지의 안내를 확인하세요. 앱을 한 번 구매하는 것과 회선 요금제를 구매하는 것은 별개입니다. 이 글은 사용자에게 서비스 제공업체와 설정이 이미 있다는 전제로 작성했습니다. 규칙 구조는 규칙 매뉴얼에서 확인할 수 있으며, 처음 설정한다면 안내에 따라 단계별로 진행하세요.