Shadowrocket은 규칙 목록을 위에서 아래로 확인하며, 처음 일치하는 규칙이 요청의 경로를 결정하고 앞선 규칙에 해당하지 않는 요청은 FINAL이 처리합니다. 이 글은 iPhone / iPad에서 Shadowrocket을 사용하고, 본인이 보유한 서비스와 구성이 있으며 Config를 편집하려는 사용자를 위한 안내입니다. Mac, Windows, Android, Linux 사용자도 매칭 원리는 참고할 수 있지만, 구체적인 편집 경로는 각 플랫폼의 현재 화면을 확인하세요. 글을 읽고 나면 여섯 가지 조건을 구분하고, 예외와 기본 규칙을 포함한 규칙을 작성한 뒤 새 연결로 결과를 검증할 수 있습니다.
1. 규칙 구조와 Global Routing 설정
규칙은 연결 매개변수도, 앱 이름을 기준으로 용도를 자동 판별하는 목록도 아닙니다. 현재 요청에서 확인할 수 있는 도메인과 대상 IP 등의 정보를 바탕으로 적용할 정책을 선택합니다. 구성 파일의 규칙을 분기에 적용하려면 iPhone / iPad의 Home → Global Routing에서 Config를 선택하세요. Config 파일만 수정하고 Proxy 또는 Direct를 유지하면 이 글에서 설명하는 방식으로 규칙을 확인할 수 없습니다.
[Rule]
DOMAIN,example.com,DIRECT
DOMAIN-SUFFIX,example.org,PROXY
FINAL,DIRECT대부분의 조건 규칙은 ‘유형, 매칭 값, 정책’의 세 부분으로 구성되며 영문 쉼표로 구분합니다. FINAL은 매칭 값이 없으므로 두 부분으로 작성합니다. DIRECT는 직접 연결, PROXY는 프록시 경로를 사용하는 정책입니다. 이 칸에 본인이 보유한 서버의 주소나 비밀번호를 입력하는 것은 아닙니다. 구성에서 사용자 지정 정책 이름을 참조할 때는 실제로 정의한 이름과 일치해야 합니다.
요약: 기본 경로를 정한 뒤 예외를 추가하세요
매칭되지 않은 요청을 DIRECT와 PROXY 중 어느 쪽으로 보낼지 먼저 정하고, 해당 FINAL을 맨 마지막에 배치하세요. 그런 다음 범위가 명확한 예외 규칙을 위쪽에 추가합니다. 기본 정책을 명확히 정하는 대신 키워드 규칙을 지나치게 많이 사용하지 마세요.
- Config: 현재 활성화된 구성의 규칙에 따라 경로를 선택합니다. 이 글의 절차를 따라 하려면 Config를 선택해야 합니다.
- Proxy: 전역 프록시 모드입니다. 개별 DIRECT 규칙의 적용 여부를 확인하는 데 사용할 수 없습니다.
- Direct: 전역 직접 연결 모드입니다. 개별 PROXY 규칙의 적용 여부를 확인하는 데 사용할 수 없습니다.
- Scene: 설정된 시나리오 조건에 따라 전환합니다. 문제를 확인할 때는 해당 시나리오에서 실제로 사용하는 구성과 정책도 확인해야 합니다.
2. DOMAIN, DOMAIN-SUFFIX, DOMAIN-KEYWORD
세 도메인 규칙의 차이는 매칭 범위입니다. DOMAIN은 도메인 전체가 정확히 일치해야 합니다. DOMAIN-SUFFIX는 지정한 도메인 자체와 하위 도메인을 매칭합니다. DOMAIN-KEYWORD는 도메인에 지정한 문자열이 포함되어 있는지 확인합니다. 이 규칙들은 URL 경로를 매칭하지 않으므로 /video/를 추가해 같은 도메인의 특정 웹 페이지를 구분할 수는 없습니다.
| 작성 예 | 매칭되는 대상 | 매칭되지 않는 대상 |
|---|---|---|
DOMAIN,example.com,DIRECT |
example.com |
www.example.com |
DOMAIN-SUFFIX,example.com,PROXY |
example.com、cdn.example.com |
notexample.com、example.com.other.test |
DOMAIN-KEYWORD,example,PROXY |
example.com、notexample.net |
sample.test |
예를 들어 example.com 전체에는 프록시를 적용하되 로그인 호스트는 직접 연결하려면, 정확한 도메인 예외를 먼저 작성하고 그다음 접미사 규칙을 추가합니다. DOMAIN-SUFFIX는 *.example.com으로 작성할 필요가 없습니다. 여기서 하위 도메인 범위를 지정하는 데 별표는 필요하지 않습니다.
[Rule]
DOMAIN,login.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT이 구성에서는 login.example.com이 첫 번째 줄에 먼저 매칭되므로 두 번째 줄까지 확인하지 않습니다. img.example.com은 첫 번째 줄에는 해당하지 않지만 두 번째 줄에는 매칭됩니다. 두 줄의 순서를 바꾸면 접미사 규칙이 먼저 요청을 처리하여 정확한 도메인 예외가 적용되지 않습니다. ‘정확한 규칙 우선’은 편집자가 규칙 순서를 지정한다는 뜻이지, 시스템이 모든 규칙을 자동으로 정렬한다는 뜻이 아닙니다.
3. GEOIP와 IP-CIDR: 대상 주소 조건
GEOIP는 사용 중인 지리 데이터베이스에 기록된 대상 IP 정보를 기준으로 매칭합니다. GEOIP,CN,DIRECT는 데이터베이스에서 CN으로 분류한 대상 IP에 DIRECT를 적용한다는 뜻입니다. 기기의 위치나 도메인 접미사를 기준으로 판단하는 것은 아닙니다. 도메인이 여러 지역에 분산 배치된 경우 DNS 응답에 따라 다른 지역의 주소가 반환될 수 있어 규칙 결과도 달라질 수 있습니다.
[Rule]
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXYIP-CIDR은 주소 대역을 기준으로 매칭합니다. 192.168.0.0/16은 192.168.0.0부터 192.168.255.255까지 포함합니다. 10.0.0.0/8은 10.0.0.0부터 10.255.255.255까지 포함합니다. 두 줄은 일부 사설 IPv4 대역을 보여 주는 예시일 뿐, 전체 로컬 네트워크 규칙 모음은 아닙니다.
| 조건 | 필요한 정보 | 확인할 점 |
|---|---|---|
GEOIP,CN,DIRECT | 대상 IP와 지리 데이터베이스 기록 | 데이터베이스 기록은 실시간 물리적 위치를 증명하지 않습니다. |
IP-CIDR,192.168.0.0/16,DIRECT | IPv4 대상 주소 | 실제 대상 주소가 지정한 프리픽스 범위에 포함되는지 확인합니다. |
no-resolve | 매칭 시점에 사용할 수 있는 대상 IP | 이 IP 규칙만을 위해 도메인을 추가로 조회하지 않도록 합니다. |
no-resolve는 ‘모든 DNS 조회 금지’나 ‘항상 직접 연결’을 뜻하는 옵션이 아닙니다. 요청에 도메인만 있고 사용할 수 있는 IP가 아직 없으면 이 옵션이 붙은 IP 규칙은 매칭을 위해 도메인을 능동적으로 조회하지 않으며, 요청은 다음 규칙으로 넘어갈 수 있습니다. IPv6 주소 대역에는 해당하는 IP-CIDR6 규칙을 사용해야 합니다. IPv6 프리픽스를 위의 IPv4 예시와 같은 매칭 대상으로 사용할 수는 없습니다.
- 특정 사설 네트워크 주소를 직접 연결하려면 실제 주소를 확인한 뒤 적절한 IP-CIDR 범위를 사용하세요.
- 특정 도메인에 지정된 정책을 적용하려면 현재 어떤 지역의 IP로 해석되는지에 의존하지 말고 도메인 규칙을 우선 사용하세요.
- IP 규칙이 매칭되지 않으면 대상 주소, 주소 체계, DNS 조회 시점, 앞선 규칙의 매칭 여부를 함께 확인하세요.
4. FINAL 위치와 전체 규칙 예시
FINAL은 조건 없이 적용되는 기본 규칙이므로 규칙 목록의 맨 마지막에 두어야 합니다. 중간에 배치하면 이후 조건을 올바르게 작성했더라도 FINAL이 먼저 처리한 요청에는 적용될 기회가 없습니다. FINAL에서 DIRECT와 PROXY 중 무엇을 선택할지는 기본 경로 정책의 차이이며, 모든 구성에 공통으로 적용되는 정답은 없습니다.
[Rule]
DOMAIN,login.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN-KEYWORD,example-cdn,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY아래는 이 글에서 다룬 여섯 가지 유형의 문법 예시입니다. 서버와 정책 그룹 정의는 포함하지 않으며, 그대로 연결에 사용할 수 있는 완전한 구성도 아닙니다. 예시 도메인은 문법 설명용이므로 테스트할 때는 용도와 실제 주소를 확실히 알고 있는 도메인으로 바꾸세요. PROXY 연결 여부는 본인이 보유한 프록시 구성이 유효한지에 달려 있습니다.
login.example.com: 첫 번째 규칙에 매칭되어 DIRECT를 선택합니다.static.example.com: 두 번째 규칙에 매칭되어 PROXY를 선택하며 GEOIP는 확인하지 않습니다.192.168.1.20: 앞서 도메인 규칙에 매칭되지 않았다면 사설 네트워크 대역 규칙에 따라 DIRECT를 선택합니다.- 그 외 요청: 나머지 조건을 차례로 확인하고, 모두 매칭되지 않으면 FINAL에 따라 PROXY를 선택합니다.
5. Config에서 규칙 수정 및 확인
다음 단계는 iPhone / iPad의 Home 및 Config 화면을 기준으로 설명합니다. 작업 전에 현재 구성을 복사해 보관하세요. 전체 구성을 [Rule]만 있는 내용으로 바꾸지 마세요. 기존 구성에 해당 섹션이 있다면 그 안에서 수정하고, 같은 이름의 섹션을 중복으로 추가하지 않습니다. 원격 구성을 다시 업데이트하면 로컬 수정 사항이 덮어써질 수 있으므로, 편집 중인 항목이 로컬 복사본인지 업데이트 원본인지 먼저 확인하세요.
-
복사본 저장
Config로 이동해 현재 사용하는 구성을 찾고 원본 내용을 먼저 저장합니다. 파일 이름을 기록해 두면 이후에도 같은 파일을 활성화하고 편집했는지 확인할 수 있습니다.
-
규칙 편집
Config에서 대상 구성의 편집 화면을 열고
[Rule]섹션을 찾습니다. 범위가 명확한 도메인 규칙을 추가하고 FINAL이 여전히 목록의 맨 마지막에 있는지 확인하세요. -
구성 활성화
저장한 뒤 Config에서 수정한 구성이 선택되어 있는지 확인합니다. 그런 다음 Home → Global Routing → Config로 이동해 Proxy, Direct 또는 다른 Scene 상태가 계속 선택되어 있지 않은지 확인하세요.
-
새 요청으로 테스트
연결을 끊었다가 다시 연결하고, 테스트 페이지의 기존 연결을 종료한 뒤 대상 도메인에 접속합니다. 연결 기록에서 대상, 매칭된 규칙, 최종 정책을 확인하세요. 웹페이지가 열리는지만 확인해서는 안 됩니다.
-
항목별 재확인
정확한 도메인, 같은 도메인의 하위 도메인, 매칭되지 않는 도메인을 각각 테스트하세요. 한 번에 조건이나 순서 하나만 바꾸고 결과 차이를 기록합니다. 문제가 발생하면 복사본으로 되돌린 뒤 테스트 범위를 좁혀 확인하세요.
기존 TCP 장기 연결이나 재사용 연결은 연결 당시의 경로를 계속 사용할 수 있으므로, 규칙을 저장해도 즉시 새 경로로 전환되지 않을 수 있습니다. 브라우저 페이지가 캐시에서 표시되는 경우도 있습니다. 따라서 ‘페이지를 한 번 새로고침했는데 달라진 점이 없다’는 것만으로 규칙이 적용되지 않았다고 판단할 수 없습니다. 새로 연결된 요청의 기록도 함께 확인하세요.
- 구독과 규칙은 따로 확인: Home에서 기존 Subscribe 내용을 업데이트하면 보통 서버 정보를 새로고침합니다. 이를 현재 Config의 규칙도 업데이트되었다는 의미로 해석해서는 안 됩니다.
- 자동 연결과 분기는 따로 확인: Settings → On Demand는 자동 연결 조건을 관리하며, Config 분기 모드를 선택하는 기능은 아닙니다.
- 프로토콜과 매칭은 따로 확인: Shadowsocks, VMess, VLESS, Trojan, Hysteria2, WireGuard는 서로 다른 연결 프로토콜입니다. 도메인 규칙이 특정 프로토콜을 다른 프로토콜로 자동 변환하지는 않습니다.
6. 규칙 미매칭 및 연결 오류 확인 순서
먼저 ‘규칙이 잘못된 경로를 선택한 경우’와 ‘경로는 맞게 선택했지만 연결에 실패한 경우’를 구분하세요. 웹페이지는 기본 도메인 외에도 이미지, 로그인, API 등에 여러 도메인을 요청할 수 있습니다. 기본 도메인에 DOMAIN 규칙을 하나 작성해도 리소스 도메인까지 같은 정책이 적용된다고 보장할 수 없습니다. 일부 콘텐츠가 로드되지 않으면 키워드 매칭 범위를 곧바로 넓히지 말고, 실패한 연결의 실제 대상 도메인부터 확인하세요.
오류: connection refused
원인 및 해결: 이 저수준 연결 오류는 연결이 거부되었음을 뜻합니다. 대상 포트에서 수신 대기 중인 서비스가 없거나 경로상의 장치가 연결을 거부했을 수 있습니다. 먼저 실패한 연결의 실제 주소, 포트, 선택된 정책을 확인하세요. PROXY 규칙에 올바르게 매칭되었다면 본인이 보유한 서버의 연결 매개변수를 확인하고 DOMAIN 규칙만 수정하지 마세요.
오류: i/o timeout
원인 및 해결: 이 저수준 시간 초과 오류는 해당 네트워크 작업이 제한 시간 안에 완료되지 않았다는 뜻이며, 이것만으로 규칙 문법이 잘못되었다고 판단할 수는 없습니다. 먼저 연결 기록에서 DIRECT와 PROXY 중 어느 경로를 사용했는지 확인한 뒤 DNS, 대상에 대한 연결 가능 여부, 선택한 프록시 경로를 각각 점검하세요. 로그에 표시되는 정확한 문구는 프로토콜과 플랫폼에 따라 다를 수 있습니다.
위 오류는 실제 연결 기록에 나타난 경우에만 해당 상황을 점검하는 데 사용하세요. 규칙 미매칭을 전용으로 알리는 메시지는 아닙니다. 기록에 FINAL이 표시되면 앞선 조건이 요청을 처리하지 않았다는 뜻입니다. 실제 도메인이 규칙과 일치하는지, 요청이 IP를 직접 사용하는지, IP 조건이 DNS 조회 시점의 영향을 받는지, 구성이 실제로 활성화되어 있는지 확인하세요.
| 확인된 증상 | 우선 확인할 항목 | 수정 방법 |
|---|---|---|
| 모든 요청이 프록시를 사용함 | Home → Global Routing이 Proxy로 설정되어 있는지 | Config로 전환한 뒤 새 연결로 확인하세요. |
| 로그인 도메인 예외가 적용되지 않음 | DOMAIN-SUFFIX가 예외 규칙보다 앞에 있는지 | 정확한 DOMAIN 규칙을 접미사 규칙 위로 옮기세요. |
| 모든 요청에 FINAL이 표시됨 | 실제 대상, 활성화된 파일, FINAL 위치 | 대상 파일이 선택되어 있는지 확인하고, 앞쪽에 있는 FINAL을 옮긴 뒤 대상 정보를 점검하세요. |
| 도메인은 매칭되지만 IP 규칙은 매칭되지 않음 | DNS 응답, 주소 체계, no-resolve | 실제 대상 IP를 확인하고 IPv6를 IPv4 테스트 대상으로 취급하지 마세요. |
| 수정 후에도 잠시 동안 이전 경로를 사용함 | 기존 연결 재사용 및 페이지 캐시 | 연결을 새로 만든 뒤 새로운 매칭 기록을 확인하세요. |
규칙을 더 확장해야 한다면 규칙 참고 자료를 확인하세요. 먼저 작고 이해하기 쉬운 규칙 목록을 유지하는 것이 좋습니다. 규칙을 추가할 때마다 매칭 대상, 예상 정책, 배치 이유를 분명히 기록하면 출처를 확인하기 어려운 규칙을 한꺼번에 추가하는 것보다 문제를 찾기 쉽습니다.