규칙을 작성할 때는 먼저 매칭 대상을 정하고, 다음으로 아웃바운드 정책을 선택한 뒤, 마지막으로 순서를 확인합니다. 이 글은 Shadowrocket에 이미 보유한 서버를 추가하고 Config를 편집하려는 사용자를 위한 안내입니다. 도메인 규칙과 IP 규칙을 구분하고, FINAL이 포함된 최소 규칙 구성을 작성한 다음 연결 기록에서 예상한 항목이 매칭되었는지 확인할 수 있습니다. 예시 도메인과 예약 주소는 문법 설명용이며 연결 서비스로 사용할 수 없습니다.
1. 규칙 적용 조건과 매칭 순서
규칙은 구성 파일의 [Rule] 섹션에 작성합니다. 이 글에서 다루는 일반 규칙은 위에서 아래 순서로 확인하며, 규칙이 매칭되면 해당 항목에 지정된 정책을 적용하고 뒤에 있는 “더 정확한” 항목을 계속 찾지 않습니다. 따라서 예외 항목은 범위가 넓은 항목보다 앞에, FINAL은 맨 마지막에 배치합니다.
테스트를 시작하기 전에 Home → Global Routing에서 Config를 선택하고, Config에서 현재 활성화된 파일이 방금 수정한 파일인지 확인합니다. Proxy 또는 Direct를 선택하면 이 글의 개별 규칙 결과만으로 모든 요청을 설명할 수 없습니다. Scene은 장면 선택과 관련되어 있으므로 최소 규칙 테스트의 시작점으로 적합하지 않습니다.
규칙은 트래픽 처리 방식을 결정할 뿐, 서버 매개변수를 보완하거나 대상에 연결할 수 있다고 보장하지 않습니다. PROXY에 매칭되더라도 주소, 포트 또는 인증 매개변수가 올바르지 않으면 보유한 서버에 연결하지 못할 수 있습니다. 테스트할 때는 “무엇이 매칭되었는지”와 “연결이 성공했는지”를 따로 기록합니다.
2. DOMAIN, DOMAIN-SUFFIX, DOMAIN-KEYWORD
도메인 규칙의 기본 형식은 규칙 유형,매칭 내용,정책이며, 반각 쉼표로 구분합니다. 매칭 내용은 호스트 이름이며 전체 URL이 아닙니다. 도메인 필드에 https://, 경로, 쿼리 매개변수 또는 :443을 입력하지 마세요. 동일한 호스트에 연결되는 서로 다른 웹 페이지 경로는 이 세 가지 규칙으로 구분할 수 없습니다.
| 규칙 | 매칭 범위 | 매칭되지 않는 예 |
|---|---|---|
DOMAIN,example.com,DIRECT | 전체 호스트 이름이 example.com인 경우에만 해당 | www.example.com |
DOMAIN-SUFFIX,example.com,PROXY | example.com 및 하위 도메인(예: img.example.com) | notexample.com |
DOMAIN-KEYWORD,example,REJECT | 도메인에 example 문자열이 포함된 대상 | sample.test |
DOMAIN-SUFFIX는 도메인 계층에 따라 매칭되며, 일반적으로 “이 도메인과 모든 하위 도메인”을 나타내는 데 적합합니다. *.example.com 형식으로 작성하지 말고, 여기에 example.com을 그대로 입력합니다. DOMAIN-KEYWORD의 범위는 더 넓습니다. 예를 들어 myexample.test도 매칭될 수 있으므로 관련 없는 대상까지 매칭되지 않는지 확인해야 합니다.
[Rule]
DOMAIN,account.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT이 독립 예시에서는 account.example.com이 첫 번째 규칙에 먼저 매칭되어 DIRECT를 사용하고, img.example.com은 두 번째 규칙에 매칭되어 PROXY를 사용합니다. 앞의 두 줄 순서를 바꾸면 계정 하위 도메인이 접미사 규칙에 먼저 매칭되어 뒤에 있는 정확한 규칙이 적용되지 않습니다. 이는 “규칙 순서”의 문제이지, DOMAIN의 우선순위가 DOMAIN-SUFFIX보다 낮다는 뜻이 아닙니다.
요점: 예외를 먼저, 범위가 넓은 규칙은 나중에
같은 도메인 체계에서 서로 다른 정책을 적용해야 한다면 구체적인 호스트의 DOMAIN 규칙을 DOMAIN-SUFFIX보다 앞에 둡니다. 문자열 매칭이 명확히 필요한 경우에만 DOMAIN-KEYWORD를 사용합니다.
3. IP-CIDR, GEOIP, no-resolve
IP-CIDR은 대상 IPv4 주소가 속한 네트워크 범위를 매칭하며 웹사이트 이름은 매칭하지 않습니다. 슬래시 뒤 숫자는 프리픽스 길이입니다. /32는 IPv4 주소 하나를, /24는 주소 256개가 포함된 네트워크 범위를 나타냅니다. 이 주소 수에는 네트워크 주소 등도 포함되므로 사용 가능한 서버 수와 같지 않습니다.
IP-CIDR,192.0.2.8/32,DIRECT,no-resolve
IP-CIDR,198.51.100.0/24,REJECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY위의 192.0.2.8과 198.51.100.0/24는 문서용으로 예약된 주소이며 형식을 보여 주기 위한 예시입니다. no-resolve는 이 IP 규칙의 매칭을 위해 도메인 확인을 추가로 실행하지 않는다는 뜻입니다. 매칭 단계에서 사용할 수 있는 대상 IP가 이미 있다면 이를 기준으로 판단할 수 있습니다. 모든 DNS를 끄거나 “도메인과 IP를 모두 자동으로 매칭”하는 옵션이 아닙니다.
- IP 주소로 직접 접속: 대상 주소를 IP 규칙에 바로 적용할 수 있으므로 먼저 도메인에서 주소를 가져올 필요가 없습니다.
- 도메인으로 접속: IP 규칙이 매칭되는지는 매칭 시점에 사용할 수 있는 IP 정보, DNS 동작,
no-resolve에 따라 달라집니다. 도메인 접미사만으로 판단할 수 없습니다. - GEOIP:
GEOIP,CN,DIRECT는 사용 중인 지리 데이터베이스가 대상 IP를 분류한 결과에 따라 매칭됩니다. 중국어 웹사이트 전체 또는.cn으로 끝나는 모든 도메인을 의미하지 않습니다. - 주소 변경: 하나의 도메인이 서로 다른 주소로 확인될 수 있습니다. 고정된
IP-CIDR을 사용할 때는 네트워크 범위가 실제 대상을 계속 포함하는지 확인해야 합니다.
특정 사이트에 지정한 정책을 적용하려는 목적이라면 명확한 도메인 규칙을 작성하는 편이 일반적으로 확인하기 쉽습니다. 이미 알고 있는 주소나 네트워크 범위를 관리하려는 경우에는 IP 규칙을 사용합니다. 지리 데이터베이스의 분류는 서비스의 실제 배치와 다를 수 있으므로 GEOIP를 웹사이트 신원의 증명으로 간주하지 마세요.
4. PROXY, DIRECT, REJECT, FINAL의 차이
규칙 끝에 적는 정책은 “매칭된 다음 어떻게 처리하는가”를 지정합니다. PROXY는 프록시 아웃바운드를 사용한다는 뜻이며 실제 서버는 현재 선택 및 관련 구성에 따라 달라집니다. DIRECT는 대상에 직접 연결하고, REJECT는 요청을 거부합니다. 이들은 프로토콜 세 종류가 아니며 서버의 Type, 주소 또는 포트를 대체하지 않습니다.
| 작성 예 | 의미 | 확인할 사항 |
|---|---|---|
DOMAIN,example.com,PROXY | 해당 호스트가 프록시 아웃바운드를 사용 | 규칙 매칭 후 실제 사용된 서버 확인 |
DOMAIN,example.com,DIRECT | 해당 호스트에 직접 연결 | 현재 네트워크에서 대상에 직접 접속할 수 있는지 확인 |
DOMAIN,example.com,REJECT | 해당 호스트의 요청을 거부 | 거부가 원래 의도에 맞는지 확인 |
FINAL,PROXY | 앞의 규칙에 매칭되지 않은 요청에 PROXY 적용 | 기본 정책이 예상에 맞는지 확인 |
FINAL에는 “매칭 내용” 필드가 없으며 형식은 FINAL,정책입니다. FINAL,example.com,PROXY처럼 작성하지 마세요. 중간에 두면 남은 요청이 일찍 처리되어 뒤의 일반 항목이 예상대로 작동하지 않습니다. 기본 정책으로 DIRECT와 PROXY 중 무엇을 선택할지는 사용 목적에 따라 달라지며, 모든 구성에 맞는 정답은 없습니다.
5. Config에서 최소 구성 저장 및 확인
먼저 기존 구성의 사본을 보관한 다음 로컬 테스트 파일을 수정합니다. 아래 규칙 섹션을 완전한 구성 파일의 모든 내용과 바꾸지 마세요. 이 예시는 [Rule] 부분만 보여 줍니다. 기존 파일에 해당 섹션이 있다면 그 안에서 조정하고, 여러 개의 [Rule] 섹션을 중복 생성해 혼란을 일으키지 않도록 합니다.
-
사본 보관
Config에서 현재 활성화된 파일을 확인하고 내용을 먼저 백업한 다음, 별도의 로컬 테스트 구성을 준비합니다. 테스트 후 복원할 수 있도록 원래 Global Routing 선택 항목을 기록합니다. -
규칙 편집
Config에서 테스트 파일의 편집 화면을 열고[Rule]을 찾아 아래의 최소 예시를 입력합니다. 쉼표, 필드 수, FINAL의 위치를 확인한 다음 저장합니다. -
구성 활성화
Config에서 저장한 테스트 파일을 선택한 다음Home → Global Routing → Config로 이동합니다. Home에서 선택한 서버가 자신이 보유한 올바른 매개변수의 서버인지 확인합니다. -
새 요청 시작
대상 연결을 새로 시작하고 앱의 연결 기록에서 대상, 매칭된 규칙, 사용된 정책을 확인합니다. 기존 장기 연결은 방금 수정한 규칙을 검증하기에 적합하지 않으므로 필요한 경우 대상 앱을 종료한 뒤 다시 엽니다.
-
한 번에 한 규칙씩 추가
최소 구성의 동작이 예상과 일치하는지 확인한 뒤, 매번 규칙 한 개만 추가하고 다시 검증합니다. 결과가 달라지면 DNS, 서버, 여러 규칙을 동시에 변경하지 말고 방금 추가한 규칙부터 되돌립니다.
[Rule]
DOMAIN,account.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.0.2.8/32,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY이 예시에서 예상되는 순서는 다음과 같습니다. 계정 하위 도메인은 먼저 DIRECT를 사용하고, 나머지 example.com 하위 도메인은 PROXY를 사용합니다. 그 다음 주소 규칙과 GEOIP를 확인하고 마지막으로 FINAL이 처리합니다. 예시 도메인은 매칭 방식을 설명하기 위한 것입니다. 실제 연결 테스트에서는 접근 권한이 있고 호스트 이름을 명확히 알고 있는 대상을 사용하세요.
- 테스트 기록 보관: 대상 호스트, 매칭 항목, 실제 정책, 연결 결과 네 가지를 최소한 기록합니다.
- 호스트 구분: 한 페이지에서 이미지, 로그인, API 등 서로 다른 호스트를 요청할 수 있습니다. 메인 페이지가 예상대로 매칭되어도 모든 하위 요청이 같은 정책을 사용한다는 뜻은 아닙니다.
- 덮어쓰기 확인: 구성이 원격 업데이트를 통해 제공되는 경우 업데이트가 로컬 수정 사항을 대체하는지 확인하고, 사용자 지정 내용을 별도로 보관합니다.
6. 규칙 미적용 및 timeout 문제 해결 순서
“페이지가 열리지 않는다”는 사실만으로 규칙 문법 오류라고 단정할 수 없습니다. 먼저 현재 파일과 Global Routing을 확인하고 실제 대상 및 매칭 규칙을 살펴본 다음 아웃바운드 연결을 점검합니다. 연결이 실패했다고 모든 규칙을 바로 PROXY로 바꾸지 마세요. 그러면 매칭 문제와 연결 문제를 구분할 근거가 사라집니다.
오류: timeout
원인: 연결 테스트 또는 요청이 대기 시간 안에 완료되지 않았습니다. 이 결과만으로는 규칙, 대상 네트워크 또는 사용 중인 서버 중 무엇이 원인인지 판단할 수 없습니다.
해결: 먼저 해당 요청에 실제로 매칭된 정책을 확인합니다. PROXY라면 Home → Connectivity Test로 현재 서버를 확인하고, 보유한 주소, 포트, 인증 매개변수도 점검합니다.
| 증상 | 우선 확인 | 조정 방법 |
|---|---|---|
| 모든 요청이 같은 아웃바운드를 사용 | Home → Global Routing이 Config인지 확인 | Config 모드로 돌아간 다음 현재 활성화된 파일 확인 |
| 정확한 도메인 항목이 매칭되지 않음 | 앞에 접미사 또는 키워드 규칙이 있는지 확인 | 우선 적용할 정확한 항목을 앞으로 이동 |
| 뒤쪽 규칙이 계속 적용되지 않음 | FINAL이 중간에 있는지 확인 | 일반 규칙 뒤로 FINAL 이동 |
| 메인 페이지는 정상이나 이미지 또는 API가 실패 | 실패한 요청이 다른 호스트 이름을 사용하는지 확인 | 주소창만 기준으로 판단하지 말고 실제 대상에 맞춰 규칙 추가 |
| IP 규칙이 예상대로 매칭되지 않음 | 실제 대상 주소, 네트워크 범위, no-resolve 확인 | 매칭 시 사용할 수 있는 주소 정보를 점검하고 도메인 소속을 IP 소속으로 간주하지 않음 |
마지막으로 텍스트 자체를 확인합니다. 반각 쉼표를 사용하고 DOMAIN-SUFFIX 같은 키워드는 원문 그대로 유지하며 설명 문구를 규칙 줄에 붙여 넣지 마세요. DOMAIN 등의 세 필드 규칙과 FINAL은 필드 수가 다릅니다. 이름이 지정된 정책을 추가했다면 참조하는 이름이 현재 구성에 실제로 있는지도 확인합니다. 원래 구성을 복원한 뒤 정상 작동한다면 변경 범위를 좁힐 단서가 될 수 있지만, 구체적인 원인은 한 항목씩 되돌려 확인해야 합니다.