Shadowrocket 사용자 규칙 작성법: 위에서 아래로 매칭, FINAL 기본 처리와 PROXY/DIRECT/REJECT 정책

1. 규칙 우선순위: 먼저 매칭되는 규칙을 적용합니다

Shadowrocket은 설정에 적힌 순서대로 규칙을 확인합니다. 연결이 특정 규칙과 일치하면 해당 규칙의 정책을 적용하고, 뒤에 있는 ‘더 구체적인’ 규칙은 확인하지 않습니다. 도메인 규칙이 IP 규칙보다 항상 우선하는 것도 아니고, 단일 도메인 규칙이 접미사 규칙보다 자동으로 앞서는 것도 아닙니다. 예외를 적용하려면 해당 규칙을 앞쪽에 배치하세요.

예를 들어 login.example.com은 DIRECT로 연결하고 example.com 및 나머지 하위 도메인은 PROXY로 연결하려면 아래 순서로 배치해야 합니다. 앞의 두 줄을 바꾸면 로그인 도메인에 접속할 때 DOMAIN-SUFFIX가 먼저 적용됩니다. 뒤에 있는 DOMAIN 규칙은 이미 결정된 연결 방식을 바꿀 수 없습니다.

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

2. PROXY, DIRECT, REJECT: 연결 처리 방식

규칙 앞부분은 ‘무엇과 일치하는지’를, 마지막 정책은 ‘어떻게 처리할지’를 정합니다. PROXY는 프록시 경로를 통해 연결한다는 뜻이며, 실제 연결 경로는 현재 선택한 서버나 구성의 정책 설정에 따라 달라집니다. DIRECT는 프록시 출구를 거치지 않고 대상에 직접 연결합니다. REJECT는 일치한 연결을 차단합니다. 이들은 Shadowsocks, VMess, VLESS, Trojan 같은 프로토콜 이름도 아니고 연결 품질 등급도 아닙니다.

DIRECT라고 해서 연결에 반드시 성공하는 것은 아닙니다. 대상이 접속을 거부하거나, 로컬 네트워크에 문제가 있거나, DNS가 잘못된 주소를 반환하면 직접 연결도 실패합니다. 마찬가지로 PROXY 규칙이 적용되었다는 것은 프록시 경로를 선택했다는 뜻일 뿐, 원격 서비스에 접속할 수 있다는 보장은 아닙니다. 문제를 해결할 때는 ‘규칙이 올바른 경로를 선택했는지’와 ‘해당 경로를 실제로 사용할 수 있는지’를 따로 확인하세요.

3. Global Routing: Config에서 사용자 규칙 확인하기

먼저 Home → Global Routing에서 현재 모드를 확인한 뒤 규칙 적용 여부를 살펴보세요. Config는 현재 구성에 설정된 규칙에 따라 트래픽을 분기합니다. Proxy와 Direct는 경로를 비교하는 데 사용할 수 있지만, 특정 사용자 규칙이 적용되었는지 확인하는 방법은 아닙니다. Scene은 상황별 모드 선택과 관련되어 있습니다. 처음 문제를 확인할 때는 Scene 전환까지 함께 사용하지 마세요. 테스트 조건이 바뀔 수 있습니다.

비교를 마친 뒤에는 Config로 다시 전환하세요. Settings → On Demand에서는 필요 시 연결 조건을 관리하며 규칙 순서를 바꾸지는 않습니다. 이를 활성화해도 FINAL 뒤에 있는 규칙이 다시 적용되는 것은 아닙니다. 테스트 중에는 네트워크와 연결 상태를 일정하게 유지하고 자동 연결, 네트워크 전환, 규칙 편집을 동시에 하지 마세요.

4. 자주 쓰는 규칙 문법: 도메인, 주소 대역, FINAL

일반적인 규칙의 필드는 영문 쉼표로 구분하며, 한글 쉼표를 사용하지 않습니다. 도메인 매칭 필드에는 도메인만 입력하고 https://, 포트, URL 경로는 포함하지 않습니다. 예를 들어 https://api.example.com:443/v1에 접속할 때 DOMAIN의 대상은 전체 주소가 아니라 api.example.com입니다. 443은 이 연결 예시의 포트이며 도메인 필드에 포함되지 않습니다.

IP-CIDR 뒤의 no-resolve는 이 규칙을 적용하기 위해 도메인 해석을 별도로 실행하지 않는다는 뜻입니다. 따라서 ‘모든 도메인을 먼저 해석한 다음 이 주소 대역을 확인한다’고 이해하면 안 됩니다. 로컬 네트워크 기기를 테스트할 때는 IP 주소로 직접 접속하는 경우와 기기 도메인 이름을 사용하는 경우를 각각 확인하고, DNS가 공인 주소와 사설 주소 중 무엇을 반환하는지도 살펴보세요.

GEOIP는 IP 주소의 지리적 위치 정보에 의존합니다. 웹사이트의 언어, 도메인 접미사 또는 운영 주체의 소재지를 기준으로 판단하는 것은 아닙니다. 특정 서비스가 반드시 고정 경로를 사용해야 한다면 IP 위치 정보로 간접 판단하기보다 명확한 도메인 규칙을 GEOIP보다 앞에 두는 편이 확인하기 쉽습니다.

• 문자 확인: 키워드, 영문 쉼표, 정책 필드를 빠짐없이 입력하고 복사 과정에서 전각 문자가 섞이지 않았는지 확인하세요.
• 범위 확인: DOMAIN-SUFFIX,example.com은 notexample.com과 일치하지 않으며, URL의 특정 하위 경로를 의미하지도 않습니다.
• 주소 확인: 192.168.0.0/16은 사설 주소 대역의 예시이며, 현재 로컬 네트워크가 반드시 이 대역을 사용한다는 뜻은 아닙니다.
• 기본 처리 확인: 일반적으로 유효한 FINAL 규칙을 하나 두고 유효한 규칙 목록의 마지막에 배치합니다.

5. 권장 배치 순서: 구체적인 예외는 앞에, FINAL은 뒤에

아래는 규칙 순서를 이해하기 위한 예시입니다. 지정한 로그인 도메인을 먼저 직접 연결하고, 특정 도메인을 차단한 다음, 전체 도메인 접미사에 규칙을 적용합니다. 이어서 사설 주소 대역과 지역 규칙을 처리하고 마지막으로 FINAL에 넘깁니다. 이 예시는 배치 방법을 보여주는 것이며 모든 네트워크에 적용할 수 있는 범용 구성은 아닙니다. 실제 대상에 맞춰 불필요한 규칙은 삭제하세요.

[Rule]
DOMAIN,login.example.com,DIRECT
DOMAIN,blocked.example.com,REJECT
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

이 순서는 ‘구체적인 예외 우선’을 보여주지만, 도메인 규칙을 항상 주소 대역보다 앞에 둬야 한다는 뜻은 아닙니다. 모든 로컬 네트워크 대상에 직접 연결해야 한다면 도메인 규칙이 로컬 네트워크 주소로 해석된 대상을 먼저 PROXY로 보내지 않는지 함께 확인하고 DNS 동작에 맞춰 순서를 조정하세요. 규칙 순서는 실제 목적에 맞춰야 하며 하나의 예시를 고정된 우선순위로 받아들이면 안 됩니다.

1. login.example.com에 접속: 첫 번째 DOMAIN 규칙과 일치해 DIRECT로 연결하고, 뒤에 있는 접미사 규칙은 적용하지 않습니다.
2. blocked.example.com에 접속: 두 번째 규칙과 일치해 REJECT로 처리합니다. 이 규칙을 접미사 규칙 뒤로 옮기면 결과가 달라집니다.
3. api.example.com에 접속: 앞의 두 규칙과 일치하지 않은 뒤 DOMAIN-SUFFIX 규칙에 일치해 PROXY로 연결합니다.
4. 192.168.1.1에 직접 접속: 앞의 도메인 규칙과 일치하지 않으면 해당 사설 주소 대역 규칙에 일치해 직접 연결합니다.
5. 다른 대상에 접속: GEOIP 규칙을 확인하고, 여전히 일치하지 않으면 FINAL로 넘어갑니다.

FINAL,PROXY와 FINAL,DIRECT는 모두 유효한 기본 처리 설정이며, 알 수 없는 대상의 기본 연결 경로가 다릅니다. FINAL은 연결 실패 후 다시 시도하는 기능이 아닙니다. 앞선 규칙에 PROXY가 적용된 뒤 프록시 연결이 실패해도 해당 규칙을 건너뛰고 FINAL을 적용하지 않습니다. 실패한 연결의 경로를 바꾸려면 해당 규칙을 수정하거나 선택한 연결을 복구해야 합니다.

6. 규칙 편집 및 확인: 한 번에 조건 하나씩 변경하기

아래 단계는 iPhone / iPad 인터페이스를 기준으로 설명합니다. 규칙은 Config에서 활성화된 구성 파일에 속합니다. Home의 서버 목록이 바뀌어도 규칙 파일이 업데이트되는 것은 아닙니다. 편집 전에 원본 구성을 보관하고, 직접 수정한 로컬 파일인지 원격 업데이트로 덮어쓸 수 있는 파일인지 확인하세요.

1. 모드 확인

   Home → Global Routing으로 이동해 Config를 선택하세요. 현재 선택된 서버를 기록하고 테스트 중에는 연결 경로를 바꾸지 마세요.

2. 파일 확인

   Config로 이동해 현재 활성화된 구성 파일을 확인하세요. 원본 내용을 보관한 뒤 편집합니다. 활성화되지 않은 다른 파일을 수정해도 현재 연결의 트래픽 분기에는 영향을 주지 않습니다.

3. 순서 조정

   구성의 규칙에서 [Rule]을 찾아 구체적인 예외를 해당 규칙을 포함하는 규칙보다 앞에 배치하고 FINAL이 마지막에 있는지 확인하세요. 규칙 줄만 복사할 때는 이미 있는 [Rule] 섹션 안에 섹션 제목을 중복해서 넣지 마세요.

4. 저장 후 다시 연결

   저장한 뒤 수정한 구성이 활성화되어 있는지 확인하고, 필요하면 다시 연결하세요. 편집 전에 열어 둔 테스트 페이지를 닫거나 기존 연결을 종료한 다음 새 요청을 보내세요. 편집 전 연결이 재사용되는 일을 방지할 수 있습니다.

5. 결과 확인

   연결 기록이나 로그에서 대상 도메인, 대상 IP, 실제 적용된 정책을 찾으세요. 테스트 대상, 매칭 결과, 접속 상태를 기록한 뒤 추가 수정 여부를 결정하세요.

세 가지 대상으로 간단한 테스트를 구성할 수 있습니다. 하나는 DIRECT, 하나는 PROXY, 나머지 하나는 전용 규칙 없이 FINAL에 도달해야 합니다. REJECT를 시험하려면 명확히 차단해야 하는 대상을 하나 더 추가하세요. 웹페이지가 열리는지만으로 규칙이 올바른지 판단하지 마세요. DIRECT와 PROXY 모두 연결에 성공할 수 있고 페이지에서 캐시를 재사용할 수도 있습니다.

7. 규칙이 적용되지 않을 때: 증상별 확인 방법

규칙 문제는 규칙이 부족해서라기보다 테스트 조건이 고정되지 않아 발생하는 경우가 많습니다. 반복해서 테스트할 수 있는 대상을 하나 정한 뒤 아래 증상에 따라 확인하세요. 네트워크 문제를 더 자세히 살펴보려면 문제 해결도 참고하세요.

마지막으로 세 가지를 확인하세요. Config를 사용하고 있는지, 올바른 파일이 활성화되어 있는지, 예외 규칙이 범위가 넓은 규칙보다 앞에 있는지 살펴봅니다. 세 가지를 확인한 뒤 새 연결로 최종 정책을 테스트하세요. 규칙은 연결 경로를 선택할 뿐 사용자가 이미 보유한 서비스의 가용성을 확인하거나 잘못된 연결 설정을 자동으로 복구하지 않습니다.