사용자 규칙을 설정하려면 먼저 Global Routing을 Config로 선택한 뒤, ‘구체적인 예외를 앞에, 포괄적인 조건은 뒤에, FINAL은 마지막에’ 배치합니다. 자체 서비스와 접속 정보를 이미 보유하고 있으며 Shadowrocket의 라우팅 동작을 조정하려는 사용자를 위한 안내입니다. 확인 가능한 규칙 문법, 편집 절차와 검증 방법을 소개하며 서비스 접속 정보를 제공하지 않습니다.
먼저 Config를 확인하고 규칙 적용 여부 판단하기
규칙 내용이 올바르더라도 현재 연결에 해당 규칙이 적용 중이라는 뜻은 아닙니다. 문제를 확인하기 전에 Home → Global Routing에서 현재 모드를 살펴보고, Config에서 선택된 구성 파일을 확인하세요. 이 글에서는 구성 파일의 [Rule] 섹션에서 위에서부터 규칙을 확인하는 방식을 다룹니다. 서비스 목록의 정렬 순서나 지연 시간 테스트 결과 순서와는 다릅니다.
Config
권장현재 구성의 규칙에 따라 연결 정책을 결정합니다. 이 글의 DOMAIN-SUFFIX, IP-CIDR 및 FINAL 예시는 모두 이 설정을 전제로 검증합니다.
적합한 경우: 사용자 라우팅 규칙을 작성하고 검증해 꾸준히 사용하는 경우.
Proxy
연결을 프록시로 처리하며, 이 글에서 다루는 구성 규칙을 하나씩 적용해 정책을 선택하지 않습니다. 잠시 전환한 뒤 접속이 복구되더라도 라우팅 경로를 더 확인해야 한다는 뜻일 뿐, 특정 규칙이 잘못됐다는 증거는 아닙니다.
적합한 경우: 짧은 시간 동안 프록시 경로의 사용 가능 여부를 비교할 때.
Direct
연결을 직접 연결 방식으로 처리합니다. 이 상태에서 구성의 PROXY 규칙을 수정해도 규칙 적용 효과를 검증할 수 없습니다.
적합한 경우: 현재 네트워크의 직접 연결 상태를 비교할 때.
Global Routing에는 상황별로 사용 방식을 설정하는 Scene도 있습니다. Scene을 선택했다면 실제 적용 중인 장면 설정을 먼저 확인하세요. 테스트 조건을 단순하게 하려면 이 글의 예시를 검증하는 동안 Config로 전환한 뒤, 완료 후 기존 선택으로 되돌릴 수 있습니다. Settings → On Demand는 필요에 따라 연결하는 기능이며, 대상 연결에 적용할 정책을 규칙으로 선택하는 기능을 대신하지 않습니다.
규칙 문법: 유형, 매칭 값, 정책 작성하기
일반적인 규칙은 ‘규칙 유형, 매칭 값, 정책’ 순서로 작성하며, 각 필드는 영문 쉼표로 구분합니다. FINAL은 매칭 값이 없으므로 예외적으로 FINAL,DIRECT 또는 FINAL,PROXY로 작성합니다. 도메인 매칭 값에 한글 쉼표를 쓰거나 웹 주소의 경로와 포트를 함께 넣지 마세요.
| 규칙 유형 | 문법 예시 | 매칭 범위 |
|---|---|---|
DOMAIN | DOMAIN,api.example.com,PROXY | 이 도메인과 정확히 일치하는 경우만 매칭합니다. |
DOMAIN-SUFFIX | DOMAIN-SUFFIX,example.com,DIRECT | example.com과 하위 도메인에 매칭하며, notexample.com에는 매칭하지 않습니다. |
IP-CIDR | IP-CIDR,192.168.0.0/16,DIRECT,no-resolve | 지정한 IPv4 대역에 매칭합니다. 이 예시의 범위는 192.168.0.0부터 192.168.255.255까지입니다. |
GEOIP | GEOIP,CN,DIRECT | 대상 IP의 지리 데이터베이스상 지역을 기준으로 매칭합니다. 웹 페이지의 언어나 도메인 접미사를 기준으로 판단하지 않습니다. |
FINAL | FINAL,PROXY | 앞선 규칙이 모두 매칭되지 않을 때 여기서 지정한 정책을 적용합니다. |
예를 들어 대상 도메인이 api.example.com이라면 DOMAIN 규칙의 매칭 값에는 도메인만 입력하고, https://, /login 또는 :443은 붙이지 않습니다. 같은 도메인의 HTTPS 연결에는 TCP 443이 자주 사용되지만, DOMAIN-SUFFIX 자체는 포트를 확인하지 않습니다. 포트를 구분해야 한다면 도메인 문자열만 바꿔서는 처리할 수 없습니다.
no-resolve는 IP 유형 규칙에서 선택적으로 사용하는 매개변수로, 해당 규칙만을 위해 도메인을 조회하지 않도록 합니다. 앱 전체의 DNS를 끄는 기능은 아닙니다. 연결에 도메인만 있고 매칭 가능한 대상 IP가 아직 없다면 이 매개변수가 있는 규칙은 매칭되지 않을 수 있습니다. 도메인 기준으로 처리하려면 IP 규칙이 항상 적용되기를 기대하기보다 도메인 규칙을 사용하세요.
위에서 아래로 매칭: 구체적인 예외를 포괄적인 규칙보다 앞에 배치
이 글에서 다루는 기본 규칙은 순서대로 확인하며, 매칭된 규칙의 정책을 실행합니다. 더 구체적으로 작성한 규칙이라고 해서 자동으로 앞에 배치되지는 않으며, 여러 규칙이 동시에 매칭되더라도 정책을 합치지 않습니다. 가장 흔한 문제는 앞선 규칙이 도메인 접미사 전체에 이미 매칭되어 뒤에 둔 특정 하위 도메인 예외가 실행되지 않는 경우입니다.
[Rule]
DOMAIN,api.example.com,PROXY
DOMAIN,blocked.example.com,REJECT
DOMAIN-SUFFIX,example.com,DIRECT
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
FINAL,PROXY다음은 순서를 설명하기 위한 [Rule] 예시이며, 연결에 필요한 모든 매개변수를 포함한 완전한 구성은 아닙니다. 도메인은 예시용입니다. 접속 매개변수에는 사용자가 이미 보유한 정보를 입력해야 합니다. 기존 파일에 [Rule] 섹션이 있다면 해당 섹션을 편집하고, 같은 섹션을 중복해서 추가하지 마세요.
api.example.com은 첫 번째 규칙에 먼저 매칭되어 PROXY를 사용합니다. 뒤의 도메인 접미사 규칙에도 해당하더라도 DIRECT로 바뀌지 않습니다.blocked.example.com은 두 번째 규칙에 매칭되어 REJECT가 적용됩니다. 이 규칙을 DOMAIN-SUFFIX 뒤로 옮기면 예외로서 작동하지 않습니다.www.example.com은 앞의 두 규칙에 매칭되지 않아 세 번째 규칙에 따라 DIRECT를 사용합니다.- 대상이
192.168.1.20인 연결은 네 번째 규칙에 매칭될 수 있습니다. 앞선 조건에 매칭되지 않은 나머지 연결에만 FINAL이 적용됩니다.
요약: 예외 규칙을 먼저 옮기고, 그다음 규칙을 추가하세요
특정 하위 도메인의 라우팅이 예상과 다르면 먼저 위쪽에 전체 접미사를 포괄하는 규칙이 있는지 확인하세요. 같은 규칙을 반복해서 추가하기보다 구체적인 예외를 포괄적인 조건보다 앞에 배치하는 편이 효과적입니다.
같은 원칙은 IP 대역에도 적용됩니다. 특정 대상 IP 하나에 다른 정책을 적용하려면 해당 주소의 /32 규칙을 그 주소를 포함하는 /24 또는 /16 규칙보다 앞에 배치하세요. GEOIP처럼 범위가 넓은 조건은 구체적인 도메인 및 대역 규칙 뒤에 두어, 별도로 처리해야 하는 연결이 먼저 포괄되지 않도록 합니다.
PROXY, DIRECT, REJECT와 FINAL의 조합
규칙 유형은 ‘무엇을 매칭할지’를, 정책은 ‘매칭 후 어떻게 처리할지’를 지정합니다. PROXY는 프록시 경로로 연결하고, DIRECT는 직접 연결하며, REJECT는 연결을 거부합니다. PROXY 요청의 성공 여부는 현재 선택한 프록시와 연결 상태에 따라 달라집니다. 규칙에 매칭되더라도 원격 서비스에 반드시 접속할 수 있는 것은 아닙니다.
- PROXY
- 매칭된 연결을 프록시 경로로 보냅니다. 검증할 때는 Home에서 현재 선택된 서비스와 해당 서비스의 연결 상태를 함께 확인하세요.
- DIRECT
- 현재 네트워크를 통해 대상에 직접 연결합니다. ‘더 빠른 경로를 자동으로 선택’하는 기능이 아니며, 현재 네트워크에서 해당 대상에 접속할 수 있다고 보장하지 않습니다.
- REJECT
- 매칭된 연결을 거부합니다. 범위가 지나치게 넓은 도메인 접미사나 대역 규칙에 적용하면 관련 페이지와 리소스에도 영향을 줄 수 있습니다.
- FINAL
- 앞선 규칙에 매칭되지 않았을 때 적용하는 마지막 규칙입니다. 자체가 프록시 서비스인 것은 아니며, 나머지 연결을 지정한 정책으로 처리합니다.
FINAL,DIRECT는 ‘명시한 대상만 프록시로 보내고 나머지는 직접 연결’하는 규칙 구성에 적합합니다. FINAL,PROXY는 ‘명시한 대상은 직접 연결하거나 거부하고 나머지는 프록시로 보내는’ 구성에 적합합니다. 사용 목적을 고려하지 않고 어느 한쪽이 항상 옳다고 할 수는 없습니다. 특정 웹사이트가 잠시 열리지 않는다는 이유만으로 기본 정책을 반복해서 바꾸지 마세요.
또한 웹 페이지는 여러 도메인에 동시에 연결될 수 있습니다. 기본 페이지, 이미지, 로그인 API와 미디어 리소스가 각각 다른 규칙에 매칭될 수 있습니다. 기본 도메인에 DIRECT를 설정했다고 해서 페이지의 모든 연결에 DIRECT가 적용되는 것은 아닙니다. 실제 요청 도메인을 확인해 필요한 예외를 추가하고, 확인되지 않은 대상을 모두 REJECT로 처리하지 마세요.
편집 및 검증: 한 번에 조건 하나씩 변경하기
편집하기 전에 현재 구성의 사본을 보관하고 Home → Global Routing에서 기존 선택을 기록하세요. Config에 있는 구독 구성, 원격 구성, 로컬 사본을 구분해야 합니다. 서비스 목록을 업데이트해도 규칙이 업데이트되는 것은 아니며, 원격 구성을 업데이트하면 원본 파일을 직접 수정한 내용이 덮어써질 수 있습니다. 개인 설정을 계속 유지하려면 직접 관리할 수 있는 구성 사본에 적용하고, 업데이트할 때마다 변경 사항을 확인하세요.
-
모드 확인
Home → Global Routing → Config로 이동해 이번 검증에서 구성 규칙을 사용하도록 설정하세요. 현재 선택된 프록시도 기록하고 테스트하는 동안에는 변경하지 마세요.
-
파일 찾기
Config로 이동해 현재 선택된 구성 파일을 확인하세요. 먼저 사본을 보관한 다음 해당 파일의 편집 화면을 여세요. 텍스트 편집기를 사용한다면
[Rule]을 찾아 기존 FINAL의 위치를 확인합니다. -
예외 추가
테스트할 DOMAIN 또는 DOMAIN-SUFFIX 규칙을 관련 포괄 규칙보다 앞에, FINAL보다 위에 배치하세요. 한 번에 한 규칙만 추가하거나 조정하고 DNS와 연결 매개변수는 동시에 변경하지 마세요.
-
새 연결 만들기
저장한 뒤 해당 구성 파일이 계속 선택되어 있는지 확인하고 Home으로 돌아가 연결을 새로 만드세요. 대상 페이지를 닫았다가 다시 열어 테스트 요청이 새 연결을 사용하도록 합니다. 기존에 계속 유지 중인 연결을 기준으로 판단하지 마세요.
-
결과 확인
앱 내 연결 기록에서 실제 요청 도메인, 대상 주소 및 적용된 정책을 확인하세요. 결과가 예상과 다르면 매칭 값 수정 여부를 결정하기 전에 해당 규칙보다 앞에서 매칭됐을 가능성이 있는 규칙을 찾으세요.
‘대상, 예상, 실제 결과, 변경 사항’ 네 가지 항목으로 테스트 기록을 남길 수 있습니다. 예를 들어 대상은 직접 관리하는 API 도메인, 예상 정책은 PROXY, 실제 정책은 DIRECT이며 이번에는 해당 DOMAIN 규칙을 DOMAIN-SUFFIX 앞으로 옮겼다고 기록합니다. 이렇게 하면 ‘규칙이 매칭되지 않은 경우’와 ‘규칙은 매칭됐지만 연결에 실패한 경우’를 구분할 수 있고, 검증 후 임시 설정을 되돌리기도 쉽습니다.
- 잘못된 규칙에 매칭됨: 실제 정책이 예상과 다르면 Global Routing, 선택된 구성 파일 및 규칙 순서를 먼저 확인하세요.
- 올바른 규칙에 매칭됐지만 연결 실패: PROXY가 적용됐는데 시간 초과가 발생한다면 기존 서비스의 사용 가능 여부와 프로토콜 매개변수를 확인하세요. 규칙 전체를 바로 다시 작성할 필요는 없습니다.
- 일부 리소스만 실패: 기본 페이지는 열리지만 이미지나 로그인이 실패한다면 주소창의 도메인만 볼 것이 아니라 실패한 리소스의 도메인을 확인하세요.
자주 묻는 질문: 규칙이 적용되지 않을 때 확인할 항목
규칙을 작성했는데 왜 모든 연결이 프록시로 처리되나요?
먼저 Home → Global Routing에서 Proxy가 선택된 상태가 아닌지 확인한 다음 Config에서 선택된 파일을 확인하세요. Config를 사용 중이라면 앞쪽에 더 넓은 범위의 PROXY 규칙이 있는지, FINAL이 사용자 규칙보다 앞에 잘못 배치되어 있는지 살펴보세요.
DOMAIN-SUFFIX에 별표를 넣어야 하나요?
example.com과 하위 도메인을 매칭하려면 DOMAIN-SUFFIX,example.com,DIRECT로 작성하세요. *.example.com이나 프로토콜 접두사는 쓰지 않습니다. 특정 도메인 하나만 정확히 매칭하려면 DOMAIN을 사용하세요.
IP-CIDR에 no-resolve를 추가했더니 왜 매칭되지 않나요?
먼저 연결 기록에 매칭 가능한 대상 IP가 있는지 확인하세요. no-resolve는 이 규칙을 위해 도메인을 직접 조회하지 않습니다. 특정 도메인을 기준으로 라우팅하려는 경우에는 이 매개변수가 주소 정보를 채워 줄 것이라고 가정하지 말고 도메인 규칙을 추가하세요.
업데이트 후 사용자 규칙이 사라졌습니다. 어떻게 해야 하나요?
먼저 Config에서 현재 파일이 원격 콘텐츠로 대체되었는지, 다른 구성 파일로 전환되었는지 확인한 뒤 저장해 둔 사본과 비교해 복원하세요. Home의 서비스 구독 업데이트와 Config의 구성 업데이트는 서로 다른 작업이므로 문제를 확인할 때 각각 기록해야 합니다.
하나씩 확인하는 대신 FINAL,REJECT를 사용해도 되나요?
허용 목록 방식으로 명확하게 운영하고 필요한 대상을 모두 관리할 준비가 된 경우에만 고려하세요. 이 방식은 앞선 규칙에 처리되지 않은 모든 연결을 거부합니다. 일반적인 문제 해결에서는 기존 기본 정책을 유지하고 구체적인 DOMAIN 예외로 검증해 한 번에 많은 리소스가 차단되지 않도록 하세요.
검증이 끝나면 임시로 변경한 모드를 원래대로 복원하고 테스트 규칙을 삭제한 뒤 FINAL이 여전히 마지막인지 확인하세요. 규칙 유지 관리에서 중요한 것은 규칙 수가 아니라 각 예외의 목적이 명확한지, 업데이트마다 변경 사항을 확인할 수 있는지, 연결 실패가 매칭 문제인지 연결 문제인지 구분할 수 있는지입니다.