Shadowrocket의 사용자 지정 규칙은 순서대로 검사되며, 먼저 일치한 규칙이 적용됩니다. 구체적인 예외 규칙은 포괄적인 규칙보다 앞에 두고, FINAL은 [Rule] 섹션의 마지막에 배치하세요. 이 글은 iPhone, iPad, Mac, Windows, Android, Linux 사용자가 규칙 파일을 이해하는 데 도움이 됩니다. 화면과 조작 방식은 기기에 따라 다를 수 있습니다. 기본 규칙을 작성하고 PROXY / DIRECT / REJECT를 구분한 뒤, 현재 설정, 연결 상태, 규칙 검사 순서, 아웃바운드 연결을 차례로 확인해 문제를 찾을 수 있습니다.
1. 먼저 Config 상태를 확인한 뒤 규칙 적용 여부를 살펴보세요
연결이 켜져 있다고 해서 사용자 지정 규칙이 트래픽을 분기하고 있다는 뜻은 아닙니다. iPhone / iPad를 예로 들면, 먼저 Config에서 수정하려는 구성이 선택되어 있는지 확인하고 Home으로 돌아가 Global Routing을 살펴보세요. 이 글의 규칙을 확인할 때는 Config를 사용해야 합니다. Proxy 또는 Direct로 먼저 테스트한 결과만으로 규칙에 문제가 있다고 판단하지 마세요.
이 글은 사용자가 이미 작동하는 서비스 설정을 가지고 있다고 가정합니다. 규칙은 요청을 어떻게 처리할지만 정하며, 연결 인증 정보를 만들거나 서버에 연결할 수 없는 문제를 해결하지는 않습니다. 이 사이트는 노드나 구독을 제공·판매·추천하지 않습니다. 설정을 변경하기 전에 기존 구성의 사본을 보관해 두세요. 설정을 한꺼번에 바꾸면 비교하기 어려워질 수 있습니다.
| Global Routing | 문제 해결 시 의미 | 확인할 수 있는 항목 |
|---|---|---|
| Config | 현재 구성의 규칙에 따라 정책 결정 | 규칙 순서, 예외, FINAL |
| Proxy | 이 글의 규칙별 테스트 상태가 아니라 프록시 아웃바운드를 주로 사용 | 선택한 프록시 연결의 작동 여부 |
| Direct | 직접 연결을 주로 사용 | 현재 네트워크에서 직접 연결할 수 있는지 |
| Scene | 설정된 Scene 로직에 따라 작동 | Scene 선택 및 전환 확인. 이 글의 기준 상태는 아님 |
Settings → On Demand에서는 주문형 연결 조건을 관리하며 [Rule]의 규칙 순서는 바꾸지 않습니다. 네트워크를 전환한 뒤 연결 상태가 달라졌다면 먼저 On Demand를 확인하고, 그다음 규칙을 살펴보세요. “터널이 연결되지 않음”과 “규칙이 잘못 일치함”은 서로 다른 문제입니다.
2. 규칙 문법: 유형, 일치 값, 정책을 각각 지정
대부분의 규칙은 쉼표로 구분된 “규칙 유형,일치 값,정책” 형식으로 작성합니다. 키워드와 구분 기호에는 영문 문자를 사용합니다. FINAL에는 일치 값이 없으므로 FINAL,PROXY처럼 작성하면 됩니다. 다음은 [Rule] 섹션의 설명용 예시입니다. 서버, DNS 및 기타 설정을 포함한 완전한 구성 파일이 아니므로, 이미 사용할 수 있는 구성에 추가해 확인하세요. 단독으로 연결할 수 있는 파일로 사용하지 마세요.
[Rule]
DOMAIN,blocked.example.com,REJECT
DOMAIN,local.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXYexample.com과 그 하위 도메인은 일치 관계를 설명하기 위한 예시입니다. 192.0.2.0/24는 문서용 예시 네트워크 대역이며, 실제로 사용할 수 있는 서비스 주소가 아닙니다. 위 규칙은 문법과 순서를 설명할 뿐, 해당 주소에 실제 서비스가 있다는 뜻은 아닙니다. 확인할 때는 접근 권한이 있는 대상을 사용하고, 실제 용도에 따라 직접 연결하거나 차단할지 결정하세요.
- DOMAIN: 도메인 하나와 정확히 일치합니다. 예를 들어
local.example.com은 이름이 비슷하다는 이유만으로 다른 하위 도메인과 일치하지 않습니다. - DOMAIN-SUFFIX: 지정한 도메인과 그 하위 도메인에 일치합니다.
example.com은api.example.com에도 적용되지만, 해당 문자열이 들어간 모든 도메인과 일치하는 것은 아닙니다. - IP-CIDR: IPv4 주소 범위와 일치합니다. 여기서
/24는 네트워크 접두사 길이를 뜻하며 포트 번호가 아닙니다. - GEOIP: 목적지 IP의 지역 데이터베이스상 위치를 기준으로 일치 여부를 판단합니다.
CN은 웹페이지 언어, 도메인 접미사 또는 사용자의 위치를 기준으로 하지 않습니다. - FINAL: 앞선 규칙과 일치하지 않은 요청을 처리합니다. 도메인이나 IP 조건을 추가로 지정하지 않습니다.
3. 위에서 아래로 규칙 검사: 구체적인 예외를 포괄 규칙보다 먼저 배치
모든 일치 항목을 모은 다음 자동으로 가장 “정확한” 규칙을 선택하는 방식이 아닙니다. 하나의 요청은 앞에 있는 규칙부터 검사합니다. 규칙이 일치해 정책이 결정되면 이후의 일반 규칙으로 결과를 덮어쓰지 않습니다. 따라서 정확한 도메인 규칙이 접미사 규칙보다 구체적이어도 뒤에 두면 우선 적용되지 않습니다.
예외 우선: 의도한 대로 적용
- 첫 번째 줄
DOMAIN,local.example.com,DIRECT- 두 번째 줄
DOMAIN-SUFFIX,example.com,PROXY- 마지막 줄
FINAL,PROXY
local.example.com은 먼저 DIRECT와 일치하고, 접미사 규칙에 해당하는 나머지 요청은 PROXY를 사용합니다.
범위 우선: 예외가 가려짐
- 첫 번째 줄
DOMAIN-SUFFIX,example.com,PROXY- 두 번째 줄
DOMAIN,local.example.com,DIRECT- 마지막 줄
FINAL,PROXY
local.example.com은 이미 첫 번째 줄과 일치했으므로, 뒤에 있는 DIRECT 규칙이 결과를 바꾸지 않습니다.
정리: 예외를 먼저, 범위 규칙을 다음에, 기본 처리는 마지막에
추가한 규칙이 “효과가 없는” 것처럼 보인다면 먼저 위쪽에서 같은 대상을 포함하는 기존 규칙을 찾아보세요. 필요한 정확한 예외를 해당 규칙보다 앞에 옮긴 다음 새 연결로 다시 테스트하면, 정책을 계속 바꾸는 것보다 원인을 찾기 쉽습니다.
- 원하는 동작을 먼저 정하세요. 예를 들어
local.example.com만 직접 연결하고 나머지example.com하위 도메인은 프록시를 사용하도록 설정할 수 있습니다. - 정확한 DOMAIN 예외를 먼저 배치하고 DOMAIN-SUFFIX 범위 규칙을 그다음에 두세요. 차단 예외가 있다면 의도한 우선순위에 맞게 배치합니다.
- 기존 구성에 추가된 규칙을 포함해, 대상에 먼저 적용되는 규칙이 있는지 확인하세요.
- 저장한 뒤에도 해당 구성이 선택되어 있는지 확인하세요. 기존 페이지의 연결 상태가 아니라 새 연결로 테스트해야 합니다.
4. FINAL을 마지막에 두는 이유와 기본 처리 정책 선택
FINAL에는 별도의 일치 조건이 없습니다. FINAL,PROXY를 [Rule] 섹션의 첫 줄에 두면 앞서 요청을 걸러낼 규칙이 없어 뒤에 있는 도메인 또는 IP 규칙이 해당 요청을 처리할 기회를 얻지 못합니다. 중간에 배치해도 뒤쪽 규칙을 가립니다. 유지 관리 시 FINAL은 명확하게 한 줄만 두고 [Rule] 섹션의 마지막에 배치하세요. 구성 파일의 아무 위치에나 두면 안 됩니다.
[Rule]
DOMAIN,local.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
GEOIP,CN,DIRECT
FINAL,PROXY이 예시는 명시된 도메인 규칙을 먼저 적용하고, 나머지 목적지 IP에는 GEOIP를 적용한 뒤, 그래도 일치하지 않은 요청을 PROXY로 처리한다는 뜻입니다. FINAL은 연결 실패 후 사용할 예비 경로가 아니며, “앞선 프록시 연결이 실패하면 직접 연결”하는 자동 전환 기능도 아닙니다. 규칙에 따라 PROXY가 선택된 뒤 연결에 실패하더라도, 마지막에 FINAL,DIRECT가 있다는 이유만으로 직접 연결을 재시도하지 않습니다.
| 기본 처리 규칙 | 일치하지 않은 요청의 처리 방식 | 변경 전에 확인할 사항 |
|---|---|---|
FINAL,PROXY | 프록시 정책으로 전달 | 프록시 아웃바운드가 작동하며, 알 수 없는 대상에 사용할 경로가 의도에 맞는지 |
FINAL,DIRECT | 목적지 주소에 직접 연결 | 목록에 없는 대상은 현재 네트워크로 직접 연결해도 되는지 |
FINAL,REJECT | 그 밖의 요청 거부 | 허용할 대상을 빠짐없이 지정했는지. 누락되면 정상적인 요청도 차단될 수 있음 |
웹페이지를 잠시 열기 위해 기본 처리 방식을 자주 바꾸지 마세요. 목록에 없는 대상을 어떤 경로로 보낼지 먼저 정한 다음 필요한 예외 규칙을 추가하세요. FINAL을 명확한 기본 정책으로 두면 규칙이 많아져도 트래픽 분기 결과를 이해하기 쉽습니다.
5. PROXY, DIRECT, REJECT는 연결 프로토콜이 아닙니다
이 세 키워드는 프로토콜 이름이 아니라 처리 정책을 나타냅니다. Shadowsocks, VMess, VLESS, Trojan, Hysteria2, WireGuard는 연결 구성에 사용되는 프로토콜 개념입니다. PROXY라고 작성한다고 해서 현재 연결이 특정 프로토콜로 자동 변경되는 것은 아닙니다. 현재 구성에서 사용자 지정 정책 그룹을 사용한다면 그룹 이름과 실제로 선택된 아웃바운드도 확인하세요. 정의되지 않은 그룹 이름은 사용할 수 있는 정책이 아닙니다.
| 정책 | 기능 | 흔한 오해 |
|---|---|---|
| PROXY | 일치한 요청을 프록시 아웃바운드로 전달합니다. 현재 선택된 연결 또는 관련 정책 설정을 확인해야 합니다. | 가장 빠른 경로를 자동으로 선택하지 않으며 서버 연결을 보장하지 않습니다. |
| DIRECT | 현재 네트워크를 통해 목적지 주소에 직접 연결합니다. | 모든 VPN을 중지하는 것도 아니고, 다른 요청까지 모두 직접 연결하는 것도 아닙니다. |
| REJECT | 일치한 요청을 거부합니다. | 연결을 복구하는 기능이 아니며 우선순위를 낮춘 뒤 재시도하는 것도 아닙니다. |
예를 들어 DOMAIN,blocked.example.com,REJECT는 정확히 일치하는 해당 도메인만 거부하며 모든 example.com 하위 도메인을 함께 차단하지는 않습니다. 전체 도메인 범위를 차단하려면 DOMAIN-SUFFIX,example.com,REJECT로 바꿔야 합니다. 이 경우 영향 범위가 넓어지므로 로그인, API 또는 리소스 도메인까지 잘못 차단하지 않는지 확인하세요.
6. IP-CIDR, GEOIP와 DNS: 도메인 요청을 IP 요청으로 혼동하지 마세요
도메인 규칙은 보통 요청에 포함된 도메인을 기준으로 판단합니다. IP-CIDR과 GEOIP는 목적지 IP 정보가 필요합니다. 하나의 도메인이 여러 주소에 연결될 수 있고, 주소는 네트워크, DNS 응답 또는 서비스 배포 방식에 따라 달라질 수 있습니다. 한 번 확인한 IP를 직접 연결 규칙에 고정해도 다음 접속까지 적용된다고 볼 수 없으며, 해당 도메인 전체가 같은 정책을 사용한다고 단정할 수도 없습니다.
no-resolve는 해당 IP 규칙의 일치 여부만 확인하기 위해 도메인 조회를 새로 시작하지 않도록 하는 옵션입니다. “DNS 사용 안 함”을 뜻하지 않으며, 모든 도메인 요청을 이 IP 규칙으로 판단할 수 있다는 의미도 아닙니다. 판단에 필요한 목적지 IP가 없다면 이 옵션으로 네트워크 대역 일치 결과를 강제로 얻을 수 없습니다.
- 명확한 도메인 조건: DOMAIN 또는 DOMAIN-SUFFIX를 우선 사용하고 GEOIP보다 앞에 배치하세요. 한 번의 DNS 응답 결과에 규칙의 의도를 좌우되지 않게 할 수 있습니다.
- 명확한 주소 범위: IP-CIDR을 사용하고 CIDR 접두사를 확인하세요.
192.0.2.0/24를 포트가 포함된192.0.2.0:443으로 작성하지 마세요. - 지역 판정: GEOIP는 데이터베이스에 기록된 목적지 IP의 지역 정보를 사용하며 실제 서버의 물리적 위치와 일치한다고 보장하지 않습니다. 클라우드 서비스나 콘텐츠 전송 환경에서는 특히 확인이 필요합니다.
- IPv6 대상: IPv4의 IP-CIDR 범위는 IPv6를 포함하지 않습니다. 듀얼 스택 요청을 조사할 때는 실제 주소 유형을 각각 확인하세요. IPv4 규칙 하나만으로 모든 트래픽을 판단할 수 없습니다.
HTTPS에서 흔히 사용하는 목적지 포트는 443이지만, 이 글의 DOMAIN-SUFFIX 규칙에는 포트 조건이 없습니다. 포트와 관계없이 도메인에 일치합니다. 특정 API가 계속 실패한다면 대상 도메인, 실제 주소, 목적지 포트와 연결 오류를 각각 확인하세요. 애플리케이션 서버의 거부 응답을 규칙 불일치로 오해하지 마세요.
7. 저장 후 확인하는 방법: 한 번에 변수 하나만 변경
확인할 때는 “규칙이 올바르게 일치했는지”와 “선택한 아웃바운드로 연결할 수 있는지”를 구분해야 합니다. 전자는 요청이 어떤 정책으로 분기됐는지, 후자는 연결이 성공했는지를 확인합니다. 요청이 PROXY 규칙과 일치했지만 프록시 연결에 실패했더라도 규칙 순서는 올바를 수 있습니다. 반대로 페이지가 열렸다고 해서 의도한 정책이 적용됐다고 단정할 수는 없습니다.
- 기준 상태 보관: 현재 사용할 수 있는 구성을 복사하고, 변경 전 Global Routing, 선택된 연결, 확인할 도메인을 기록합니다.
- 한 가지씩 변경: 먼저 정확한 DOMAIN 규칙 하나를 추가하거나 두 줄의 순서만 바꾸세요. DNS, 연결 프로토콜, FINAL을 동시에 변경하지 마세요.
- 선택 상태 확인: Config로 돌아가 사용 중인 구성을 확인하고, Home에서 Global Routing이 Config이며 연결 상태가 정상인지 확인합니다.
- 새 연결 만들기: 기존 페이지를 닫고 요청을 다시 보내세요. 필요하면 앱에서 이미 열려 있는 연결도 종료합니다. 기존 연결은 생성 당시의 경로를 계속 사용할 수 있습니다.
- 기록 확인: 기기에서 확인할 수 있는 연결 기록이나 로그에서 대상, 일치한 규칙과 정책을 살펴보세요. 기록에 모든 항목이 표시되지 않는다면 임시로 정확한 규칙을 추가해 비교하고 결과를 추측하지 마세요.
- 복원 및 기록: 변경 후 문제가 생기면 먼저 사본을 복원하세요. 변경 효과를 확인한 뒤 일상적으로 사용하는 구성에 반영하고 규칙의 용도를 기록합니다.
DIRECT를 추가했는데도 왜 이 도메인은 PROXY로 연결되나요?
먼저 Global Routing이 Config인지 확인한 다음, 수정한 구성이 현재 사용 중인 구성인지 확인하세요. 해당 DOMAIN 줄 위에서 이를 포함하는 DOMAIN-SUFFIX나 다른 규칙을 찾으세요. 필요한 예외를 범위 규칙보다 앞에 두고 저장한 뒤 새 연결로 다시 테스트합니다.
FINAL을 DIRECT로 설정했는데 프록시 연결 실패 후 왜 직접 연결되지 않나요?
FINAL은 앞선 규칙과 일치하지 않은 요청만 처리합니다. PROXY와 일치한 뒤 발생한 연결 오류는 처리하지 않습니다. 먼저 해당 요청과 일치한 규칙을 확인한 다음 현재 프록시 아웃바운드를 점검하세요. 서비스에서 직접 연결해야 한다면 실패 후 전환에 기대지 말고 범위를 정확히 지정한 DIRECT 규칙을 추가하세요.
구독을 업데이트하면 사용자 지정 규칙이 덮어써지나요?
먼저 Home의 연결 구독 업데이트와 Config의 원격 구성 업데이트를 구분하세요. 전자는 주로 연결 정보를 업데이트하고, 후자는 규칙 내용을 다시 불러올 수 있습니다. 수정하기 전에 로컬 사본을 저장하세요. 원격 구성을 계속 업데이트해야 한다면 먼저 업데이트 범위를 확인하고, 원격 내용에 일회성으로만 수정하지 마세요.
On Demand를 켰는데도 규칙이 적용되지 않는 이유는 무엇인가요?
Settings → On Demand에서 자동 연결 조건을 확인한 다음 Home으로 돌아가 실제 연결 상태와 Global Routing을 확인하세요. On Demand는 연결 시점을 관리할 뿐, 현재 연결 상태를 자동으로 Config라고 판단하거나 규칙 순서를 변경하지 않습니다.
규칙은 일상적으로 관리할 때도 같은 순서를 지키세요. 구체적인 예외를 먼저, 범위 규칙을 그다음에, FINAL을 마지막에 둡니다. 문제가 발생하면 현재 구성과 일치 기록을 먼저 확인하고 아웃바운드 연결 가능 여부를 살펴보세요. 원인을 찾지 못한 연결 문제를 중복 규칙을 쌓아 가리는 것은 피해야 합니다.